Let's see how keys are aggregated:
Then, the aggregated hash is 9309c24c2bc0162de694d5f3a80e35cd17e7db4afd1994b86a1470dc4ea5bf57, if those three keys are sorted. Because SHA-256 is executed in 512-bit chunks, it is aligned in this way:
So, I guess by providing some in-between hashes, it could be possible to prove, that the aggregated hash contained a specific public key. For example, for the last key:
Of course, public keys are not-so-well-aligned, because they take 33 bytes, instead of 32, but still, picking any other keys will change the initialization vector from e4408850f10bfbab723cc28807ec49e0491d6a6750fff49c2b6358ec0ac4bc1a to something else. And picking any other data, would very likely not hash into 9309c24c2bc0162de694d5f3a80e35cd17e7db4afd1994b86a1470dc4ea5bf57. But: I still have to dig deeper into the code, to produce more detailed logs.

I assume at least some of my assumptions about SHA-256 are correct, because I found the same constants in the code:
https://github.com/bitcoin-core/secp256k1/blob/master/src/modules/musig/keyagg_impl.h#L64

Can you derive it? If you can, then it is half of the job done, because if people cannot pick any R-values they want, then you can split the signature, by using derived R-value.

Aggregated public key has to be public, because you have to verify, that the whole multisig is correct. So, you may not know P1, P2, P3, ..., P100, but you have to know "P=P1+P2+P3+...+P100", because this P-value is used to generate a Taproot address for the whole group.

A signature is just a multiplication and addition between the aggregated public key of all participants (P-value), and aggregated signature nonce (R-value). If you can split the joined signature into "P=AliceP+TailP" and "R=AliceR+TailR", then, there is only one matching s-value, meeting the equation "s=sAlice+sTail".

I guess you need both R and s, because "R=AliceR+TailR", and "s=sAlice+sTail". And then, if "AliceR" is deterministic, and you can derive it, then you can avoid the attack, described by Garlo Nicon.

You only have to verify two signatures: the full 100-of-100 multisig, and Alice's signature. The tail signature of 99-of-99 multisig will be correct, if those two will also be, and if joining those two parts will lead you to identical signature, as in 100-of-100 multisig.

It depends on the exact multisig implementation (because there is more than one way to do that, and I don't know, which one you will want to observe). It is technically possible to make proofs, that "Alice took part in this 100-of-100 multisig". But: if your model does not reveal any kind of proofs, and you can only see some Taproot address, spent by key, and you see only things, which are seen by all on-chain observers, then you cannot do that.

Because in general, it works in this way: you have a regular signature, where you don't know, if it is 100-of-100 multisig, or 2-of-2 multisig. And then, someone can give you some data, to reveal, that it is "at least 2-of-2 multisig" (or "exactly 100-of-100 multisig" in some models), and that Alice was there. But: if you don't have this additional data, then you don't know that.

Yes, it is possible. If you can join signatures, then you can split them as well.

https://en.bitcoin.it/wiki/Schnorr
https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki

For example, let's assume, that you have some message:
And then, you have this signature:
Then, you have some public key, and you want to prove, that it contributed to the joined signature:
Now, you know, that the key "P1" also signed the message "e" with some "(R1,s1)" signature. And you also know, that there are other signers, if you subtract signatures:
And you can verify, that the subtracted part is also valid, if you try to check it in the same way:
But of course, you don't know, if "P1" or "P2" belongs to a single person. It can be a part of some larger group, which could be splitted further.

Then, just take version 0.1.0, and remove things, which you don't need. For example: instead of "scriptSig" and "scriptPubKey", you only need "sig" and "pubKey", and ECDSA implementation. I guess the bare minimum is hashing, so you can start from SHA-256 implementation (because then, you can form a chain). The next thing is public key cryptography, which means secp256k1 implementation. If you have those two, then you can form the basic chain. If you ignore everything else, then you will have "downgraded soft-fork", where your version will only check P2PK, and accept everything else as valid.

I was trying to do something like that, but it is not yet ready.

I guess it is about recreating the process of making Bitcoin from scratch. Because between empty main function, and the first released version, there are definitely more points, where you have "half-baked coin", and where you can learn, why things are set, the way they are. For example: the bare minimum doesn't need any Script. The bare minimum doesn't need versioning. And there are many other things, which you can remove, and still cover everything, what is described in the whitepaper.

So, to sum up: start from SHA-256 implementation, which will give you just "something mineable, without any public keys". Then, add public keys support. And then, you will have the bare minimum.

And if you want to test some basic concepts, then you can even downgrade it into SHA-1 with secp160k1, or even CRC-32 with some 32-bit elliptic curve, if you want some weaker test network.

Because if you start a new coin from scratch, then you naturally start from zero coins in circulation. The first version had no "Genesis Block" at all. But: if you have no such block, then you can always erase the full chain, by mining in the past. Then, you don't have to start from 2009. You can start from 1970 as well, and create a chain of blocks for 39 years.

So, you start from a version without any Genesis Block, produce some chains, and notice, that it is needed, to block any incentive, to mine blocks in the past, and constantly rewrite the chain. To make the system honest, it is also needed to prove somehow, that you also didn't mine the chain in advance, and everyone had the chance to mine it, after being released.

Then, you use some information from the outside, like a text from the newspaper (or the mainnet block hash, as it is in testnet4). You make this block special, which also allows you, to reset the chain, if needed. And during testing, you can check different scenarios, by starting from different genesis blocks.

For example: this is prenet Genesis Block: https://bitcointalk.org/index.php?topic=5355610.0

Those coins are locked forever. Coins could be locked into OP_RETURN as well (or rather: OP_FALSE, because the meaning of OP_RETURN was different at that time), or the amount could be set to zero. It doesn't matter, nobody can access them, because you start from an empty database, and then add new coins, on top of that. Of course, it was more natural, to use a regular OP_CHECKSIG, with a regular key, to have the ability to prove, that you started the chain, if that would ever be needed.

Well, you can mine anything you want. Transaction ID is just SHA-256 of some data. And everything can be mined: you can mine block headers, you can mine addresses (then you get vanity addresses), and you can mine transaction IDs.

https://bitcointalk.org/index.php?topic=5282911.msg56567378#msg56567378

I guess this thing will not happen. Because it will allow more spamming, and will not increase the number of transactions significantly enough. I think we will rather see single UTXOs, handling more than one person, and transaction joining. And of course, Ordinals blocked any block size increase for a while, and this argument will always be raised, if anyone will attempt to do so in the future.

And also with much less nodes than today, where you cannot download historical data, because there are not enough non-pruned peers, which will serve you that data.

You assume, that other people make their transactions in a proper way. But very often, it is not the case. For example: if you don't reuse addresses, but 99% other people do so, then by taking a set of transactions, and excluding address reuse, it is possible to find you.

Which means, that if you want to hide properly, then you have to get some statistics first, and see, what is the most popular way of using a given coin, and do it in a similar way. And then, the question is: if other people significantly degraded their privacy, does it really matter, if there are millions of transactions, if all of them passed through KYC?

Then just run a full node, and observe some traffic. There are many cases of address reuse, KYC, SPV nodes connected directly to you (so you can get their IPs, and connect them with their transactions), and so on. And for example Ordinals make it even easier, when people first publish some data on-chain, and then post on social media, that they own some monkeys.

Not to mention, that you can also group people by used amounts, address types, or even client versions. And many nodes, running 24/7, have some static IPs, so you can even check that kind of data.

Yes. The main limitation is difficulty adjustment: you cannot make "stronger" block, than your difficulty says (because then, everyone would just work on top of the Genesis Block, all the time, and would be guaranteed to throw away the whole chain in the future, with constantly increasing probability).

For example: the Genesis Block has the "real" difficulty of 2536, but it is declared as "1d00ffff", so it is only counted as 1. And the chainwork is then counted as 0x100010001, not 0x9e8770a5c23.

Yes. But they don't do that, because most miners just run the default settings, without thinking about profitability, and without coding their own implementations. I guess most people would not even enable CPU mining, if Garlo Nicon would not share those changes publicly. It is not that easy to come up with a better algorithm, and most people are not programmers, and they simply stick to what they can find, instead of writing their own code.

However, if ASIC miners would want to maximize their profits (and lower the network difficulty), then they would ignore hundreds of CPU-mined blocks, and only consider ASIC-mined blocks as "real", and reorg all CPU-mined blocks, just by mining on top of the latest ASIC-mined block.

But of course, as long as this change is not implemented, then this miner can happily rule testnet4, and make it de-facto signet for a while. Because each ASIC block, which will confirm all previous blocks, basically sets the attack in stone, so the chain will not be reorged in the future.

And also, because testnet4 coins got some value anyway, and are actively traded, then another network should be used for real testing. And of course, testnet5 should have completely different rules, because in other case, Bitcoin Core developers would participate just in altcoin pump and dump, if they will keep making test networks, without preventing those coins from being traded.

No. For example, let's assume, that you make a transaction like this one: https://mempool.space/tx/000000000fdf0c619cd8e0d512c7e2c0da5a5808e60f12f1e0d01522d2986a51

Then, does it matter, how many transactions are there? In practice, not really, because for example making a transaction with a lot of leading zero bits is something, where you have to write some code, to achieve that. Which means, that a typical user won't do that, and it is crystal clear, that someone who did it, had some coding skills. And that information alone can be used to narrow down the possible set of coin owners.

If you have a lot of small transactions, and some huge CoinJoins, then CoinJoin participants are only hidden inside the CoinJoin traffic. That's why, it is possible to sometimes achieve better results, just by doing a regular one-input-two-outputs transaction, than being a part of some huge CoinJoin.

The same with address types. Some people use only addresses starting with '1'. If you increase Segwit traffic, it won't change their situation (and vice versa).

And the same with coin amounts. If you send 0.01 BTC, then you can hide in a group of people, which also use round amounts. And seeing more transactions, sending 0.01234567 BTC, won't change your situation.

If you want to get there, then you need transaction joining. And then, things which can be seen on-chain, are loosely connected with actually performed transactions, because then, a single on-chain transaction can handle a lot of users. Which means, that you have "Alice -> Bob -> Charlie -> ... -> Zack" seen in wallets, but "Alice -> Zack" is what you can actually see on-chain. The 4 MB witness limit won't let you push hundreds of millions distinct transactions on-chain, where every user would have its own UTXO. Instead, you would have multiple users per UTXO, to fit all of that in a block.

Difficult, but still possible, because the traffic of unconfirmed "to-be-batched" transactions, can still be observed. For example: if you have Lightning Network, then on-chain, you have just some channel opening, and channel closing transaction. But: if you run some LN node, then you can observe, how coins are flying through your node, and you can get some statistics, out of that. And then, on-chain, after getting a lot of confirmations, you can only see a few transactions here and there, to set up, and close channels, but if you had a node, running 24/7, then you can have a clue, what happened in-between. And the same is true with transaction joining: nodes would still need to broadcast to-be-batched transactions in unconfirmed state, and they could be traced in a similar way, as LN transactions are traced today.

Yes, they both have unlimited integers.

It is hard to graphically express enormously big curves. Here are all of them, meeting y^2=x^3+7 equation, up to 1000: https://github.com/vjudeu/curves1000/tree/master/png

For example, if you have p=967 from Garlo Nicon's examples, then you have this: https://raw.githubusercontent.com/vjudeu/curves1000/refs/heads/master/png/967.png

You can pick any language you want. Also, if you just want to explore basic things, then curves up to 32-bit should be sufficient, so you can use any language, even C/C++, because it will take some time, to know enough, to work with bigger curves correctly.

Example 32-bit curve: p=0xfffff9af, n=0xfffe390b, base=(0x1,0x3cad5d2d)

Also, Sage is your friend: https://sagecell.sagemath.org/
And then, you have two points, for example (0x1,0x3cad5d2d) and (0x3,0x43f09f34). If you can't get the private key here, then you won't succeed with bigger curves, so you should start with this 32-bit curve, or smaller, and get familiar with them first.

See? Even in the sources you linked, there is still some doubt, if Satoshi=Patoshi. And I think it is not the case, for example because the Genesis Block does not match some patterns.

Also, each time, when extraNonce was resetted to zero, then you can have this miner, or that miner. And the way of mining also changed over time.

1 MB legacy transaction size is a threshold. If you have 1400 UTXOs, then you have 70k coins. That will give you a transaction of slightly below 100 kvB. So, for 14,000 UTXOs, you can potentially move 700k coins, maybe 750k coins, if they are all P2WPKH inputs. But: because of legacy P2PK or P2PKH, it will take much more space than that.

Note that you will need a regular DER signature, for each individual input. And note that you cannot use a Segwit discount, because it didn't exist at that time, and you had only P2PK or P2PKH. So, you will need at least a few blocks, to even combine all of those coins, even if you solve everything at once.

Well, 20k inputs in a single 1 MB legacy block space, would mean something around 50 bytes per input. It is hard to get DER signatures that small. The smallest valid ones take 9 bytes, and you would need the private key for x-value pubkey below 0x80 (which is very hard), and around 2^249 s-value grinding (which is also extremely hard). Even exploiting SIGHASH_SINGLE bug will force you to grind a lot of SHA-256 transaction data, to get 9-byte signatures, because for around 128 valid s-values, and around 64 valid r-values, you will get around 8192 matching keys, so even if you prepare non-random pubkeys upfront, it will be hard to get there.

Nothing. The default action is "do nothing, keep the status quo".

Yes. But: if it will be possible to make a valid signature, without knowing the real private key, then it may be still possible, to require some stronger proof.

For example: nobody knows the private key to 032baf163f5e27261ab3228e61fb86dc98054abd514751fce93d7444e8fbc6a293, but coins from this P2PK were moved, because of SIGHASH_SINGLE bug: https://mempool.space/testnet/tx/3952b35bde53eb3f4871824f0b6b8c5ad25ca84ce83f04eb1c1d69b83ad6e448

And if for example this particular way of spending coins will turn out to allow "fake signatures", targeting real keys, then it is possible to block only that single path, without blocking anything else.

1. I doubt, that Patoshi=Satoshi.
2. Coins are splitted. You don't have a single UTXO with 1M coins. You have 20k different keys, holding 50 BTC on each UTXO.
3. Moving 1M coins will not happen in a single block, because if you have 20k inputs, then it will be too huge transaction, to get everything at once.

1. All transactions flying in mempools, have their public keys already exposed.
2. A lot of hash-based address types, have also their public keys exposed. They are then weaker, because you can break them by valid signature, and also by a different public key, giving the same 160-bit hash.
3. You cannot use a coin today in a meaningful way, without having OP_CHECKSIG, or its equivalent.
4. Breaking SHA-256 will also break OP_CHECKSIG, because then, it is possible to make a random valid signature, and then make a transaction, matching a given 256-bit preimage.

In case of a browser, you can use Internet Explorer, or Mozilla Firefox. Or Google Chrome. Or Safari. You have a choice. And if you create a website, then you don't have to change your hosting provider, if you want to switch your browser.

When it comes to cryptocurrencies, then you cannot hold both BTC and LTC, at the same time, with the same amount. You cannot have $1000 in "crypto", and decide, that "today, it is $500 in BTC, and $500 in LTC". And tomorrow, if you change your mind, then you cannot instantly say "now I signed this message, so now I pick $700 in BTC, and $300 in LTC, and want to use it in that way". You have to make a transaction, and pay some fees. Which means, that changing your choices, creates additional costs, which can very easily become a bottleneck, because you don't have "just $1000 in crypto". You have to pick something, and stick with that choice. And as long as it is the case, and as long as altcoins create completely separate monetary bases, you have to pick only "this coin or that coin". You cannot have both BTC and LTC, on the same UTXO.

So, it is more similar to the situation, where you have some EXE file, and you want to switch from Windows to Linux or MacOS. Of course, there is Wine project. But: it took many years for people, to get there. And still, there are many cases, where a particular EXE file works only under Windows, and nowhere else. And then, you are forced to use Windows, even if you don't want to.

And then, the comparison is even more fair, if you pick "x86 vs ARM vs M1 vs AVR", and so on. Because then, if you have your EXE, and you want to run it somewhere else, then you still need a compatibility layer, like a virtual machine, or a transcompiler, which will translate all of that, opcode by opcode. Then, you really have to "abandon EXE, to have ELF", just like you have to "abandon BTC, to have LTC". You cannot use both, at the same time, just like you can visit bitcointalk from two different browsers.

I think people need more features on existing coins, and not just more coins. If your strategy is "please sell your BTCs, and buy my product", then many people will not do that, because they know the history. I guess a lot of BCH users would really want to have 1:1 peg with BTC today. Now, after 7 years, it is clear, that those, who stayed with BTC, simply won.

And also, this "1000x" stick has two ends: there is of course a chance for 1000x gains, but there is also a chance for 1000x losses. And if you are not an altcoin creator, then you usually are on the losing side, when altcoin makers simply cash out into BTCs, and leave naive investors behind. It happened too many times in the crypto world, so wise people have many reasons, to worry about that kind of scenario (and not that many examples of 1000x gains, to really believe, that this particular altcoin is the unicorn).

It wouldn't change anything now, because we are still before the first halving. And I don't know, if testnet4 will live long enough, to even approach the first halving.

It will only increase the price on centralized exchanges, and make testnets even more similar to the mainnet. Then, a different Genesis Block, would be the only major difference.

Yes, I guess X=1 should work quite well.

The real difficulty is around 6x bigger, than it should be, because of CPU miners.

Once per two weeks, there is a difficulty adjustment, and then, only ASICs can mine a single block. Recently, it took one hour. And before that, there was a time, when it took around 4 hours. And ASIC miners could simply block all CPU miners, once per two weeks, if they would just stop mining.

If no CPU solves the block for 20 minutes, then the difficulty drops to the minimum for everyone. Then, even if you have some ASIC, you have no other choice, than to mine at the minimum difficulty. Of course, you can mine in the past, but Median Time Past rule forces timestamps to move forward, so it is quite limited by the timestamps of the previous blocks (which is why sometimes you have no other option, than to put a timestamp from the future, when MTP rule forces you to do so).

Well, it just makes much more sense to mine mainnet blocks, or pick some other altcoin in that case. Many people expected to sell testnet4 coins at 7000 satoshis per unit, and they were quite surprised, when CPU miners dumped 100k coins, and dumped the price into 20 satoshis (which is now slowly recovering, but testnet3 is worth much more than testnet4, so many people just don't have any reason to switch; also because testnet3 is much faster chain, and allows much more bloat).

Then, instead of a single 256-bit number, you would have only the transaction counter in the block message, and all transactions after that.

If you use a hash function like SHA-256, which is based on Merkle–Damgård construction, then things can be optimized, and then done in SPV way. For example: you can give someone the initialization vector, just before the latest SHA-256 internal block, and the last 512-bit chunk. It would be sufficient to verify, that the hash of the whole block was mined correctly.

The same about proving transaction inclusion: even if you hash all data, as a single SHA-256 call, then still: you can prove, that a chunk "X" is included, by giving the initialization vector, some chunks in-between, and a final SHA-256 result, for that specific chunk.

So, SPV would be of course harder, but still possible, because SHA-256 splits data into 512-bit chunks by definition.

Yes. But it is costly, if you have to put all of that on-chain. It is much better to just have some external proof, and only commit to it on-chain. For example: something like this sudoku puzzle: https://github.com/zcash-hackworks/pay-to-sudoku

Imagine how more complex everything would be, if you would push the whole NxN sudoku puzzle inside the input script.

No matter what you pick, it should be deployed on some kind of test network first anyway. So, no matter if it would be a soft-fork, or a long Script, the way of deployment is similar.

If you have some external proof, then in most cases, you cannot spend the coin on-chain, if you don't know the solution.

And if some different elliptic curve is used, then you can use a DLEQ proof: https://groups.google.com/g/bitcoindev/c/MezoKV5md7s

I guess not, because if you have to put a lot of data on-chain, then it is an equivalent to shrinking the maximum block size. And those limits will not be lifted in the nearest future, because it would only open a wide door for some spam, and the amount of real coin usage will be left unchanged (or even some users will switch into other networks, as a result).

It is better to make a regular soft-fork in that case: https://groups.google.com/g/bitcoindev/c/p8xz08YTvkw

It shouldn't matter, because you shouldn't put everything on-chain. See: https://bitcointalk.org/index.php?topic=277389.0 (this topic contains the word "witness", but it is not about Segwit).

Even if ECDSA will be broken, then still, there are scripts you can do, which could be safely used, even in that kind of scenarios. For example: "OP_SHA256 OP_CHECKSIG" is one of those Scripts, where you have to put a message, which will hash perfectly into x-value of the public key, and will pass Schnorr signature verification.

Another example is "Pay to Proof of Work", when you require a DER signature below N bytes.

So, even if OP_CHECKSIG will lose its original meaning, then still, it will then be just a calculator, working on 256-bit numbers. But: it will be possible to mount another challenge, where you would need many OP_CHECKSIGs, to move the coins. And they can be wired in a way, where knowing the private key will give you no advantage, because the challenge will require solving dependencies between keys, and not the keys alone.

Well, there are some posts. Here is another one: https://groups.google.com/g/bitcoindev/c/SPmrzARLMFU

You call "getblocktemplate", and Bitcoin Core gives you everything you need, to form a full block.

There were in the past, but they are now deprecated. Now, you pass the whole block template into your mining software, which then constructs it, based on that. But: if you explore a block template, then you notice, that it contains everything you need.

Then, you just try a different block header, until you hit it. In case of ASIC-mined blocks, checking all 2^32 nonces takes them just some seconds, and most of the time, they use something called "extraNonce", which is just a value, pushed on the stack. Which is why when you explore their coinbase transactions, you can see this extraNonce, set to some 32-bit value (which will then give you a block with 64 leading zero bits).

Also, for the same reason, ASIC miners grind their timestamps, and block versions, which was called in the past "ASIC boost", because it is faster to modify a block header, than the coinbase transaction, and recalculate the merkle root. And also, some people wanted to fix it, by allowing to put non-zero bits in places, like "previous block hash", where you will always have some zeroes, and based on difficulty, this space could be potentially used for additional bits.

No problem. Testnets are created mainly to test mining, because everything else can be easily tested from a user perspective, if you have other networks like signet. So, it is natural to ask about mining in testnets.

Yes, try "bitcoin-util grind". It will allow you to CPU-mine absolutely any block headers, you just put some 80 bytes there, and you will get some 80 bytes back, with the right nonce (if it exists).

Yes, because you first mine a block with future timestamp, and then you broadcast it, at the right time. If you would mine it with earlier timestamp than that, then you would need to meet the real network difficulty. Which is also, why ASIC miners increase inflation, when they put the current time in their blocks (because then, the current time can be rolled back, according to the MTP rule, and the same timestamp can be reached again by CPU miners).

Of course. For example: you have a lot of bad altcoins, which are terrible, when it comes to preserving any value, but they are great, when it comes to transacting. Also, that's why Bitcoin domination is decreasing over time.

Then, you can compare Bitcoin with Lightning Network or with sidechains.

What about test coins, like testnet3 or testnet4? If you check https://altquick.com/exchange/ and look at "Weekly BTC volume", then testnet3 is usually at the top. And if you look at https://mempool.space/testnet then you will see, that the network is so congested, that you can get around 40 tBTC from fees alone, and 2 GB of block data, worth 2500 tBTC, is waiting for confirmation.

Also, there is a way, to wrap BTCs, and make an altcoin out of that, while maintaining 1:1 peg, and while having peg-ins and peg-outs, in a form of real BTC transactions. So, there is definitely more than "one possible manifestation", because you can always "sign coins, to peg them in", and then "move coins, to peg them out".

If you send a block to your own node, which already has it, then it does nothing.

Let's see the code: https://github.com/bitcoin/bitcoin/blob/master/src/rpc/mining.cpp#L1057

I guess your block is then "valid", but there is some other block, at the same height. And then, your block may be correct, but the other block may be also correct. The next block will tell the truth. And the next ASIC block will pick the right chain, and destroy all alternative chains.

Or: maybe you are trying to submit a block too early to the node, when it is "not yet valid". Because you have a valid block, some CPU miners have a valid block, some ASIC miners have a valid block, and first-seen-safe rule is applied. And because the block difficulty is equal to one in "86% cases", then the final winner is announced, when the block with the real difficulty appears.