Good morning vjudeu, > > Perhaps the only things that cannot be usefully changed in a softfork is > > the block header format and how proof-of-work is computed from the block > > header. > > Why not? I can imagine a soft fork where the block header would contain > SHA-256 and SHA-3 hashes in the same place. The SHA-256 would be calculated > as-is, but the SHA-3 would be truncated only to cover zero bits in SHA-256 > hashes. In this way, if SHA-256 would be totally broken, old nodes would see > zero hashes in the previous block hash and the merkle tree hash, but the new > nodes would see correct SHA-3 hashes in the same place. So, for example if we > have 1d00ffff difficulty, the first 32-bits would be zeroes for all old > nodes, but all new nodes would see SHA-3 truncated to 32-bits in the same > place. The difficulty could tell us how many zero bits we should truncate our > SHA-3 result to. Also, in the same way we could introduce SHA-4 in the future > as a soft-fork if SHA-3 would be broken and we would see many zero bits in > our mixed SHA-256 plus SHA-3 consensus.
I do not think I follow. The block header has a Merkle tree root that is a SHA-256 of some Merkle tree node, is that what you refer to? Do you mean the same Merkle tree node has to hash to some common value in both SHA-2 and SHA-3? Or do you refer to the `prevBlockHash`? Do you mean the same `prevBlockHash` has to somehow be the same, for some number of bits, in both SHA-2 and SHA-3? More specifically: * `nVersion`: 4 bytes * `prevBlockHash`: 32 bytes, SHA2 of previous block. * `merkleTreeRoot`: 32 bytes, SHA2 of topmost Merkle tree node. * `nTime`: 4 bytes, miner-imagined time. * `nBits`: 4 bytes, encoded difficulty target * `nonce`: 4 bytes, random number with no other meaning. What do you refer to? Because the above block header format is hashed to generate the `prevBlockHash` for the *next* block, it is almost impossible to change the format without a hardfork. Regaards, ZmnSCPxj > > On 2021-05-23 13:01:32 user ZmnSCPxj via bitcoin-dev > bitcoin-dev@lists.linuxfoundation.org wrote: > > > Good morning Jorge, et al, > > > > > Hardforks can be useful too. > > > But, yes, I agree softforks are preferable whenever possible. > > > > I think in principle the space of possible softforks is very much wider > > than can be trivially expected. > > For instance, maaku7 once proposed a softfork that could potentially change > > the block discovery rate as a softfork. > > Although this required exploiting a consensus bug that has since been > > closed. > > The example of SegWit shows us that we can in fact create massive changes > > to the transaction and block formats with a softfork. > > For example, it is possible to change the Merkle Tree to use SHA3 instead, > > in a softfork, by requiring that miners no longer use the "normal" existing > > Merkle Tree, but instead to require miners to embed a commitment to the > > SHA3-Merkle-Tree on the coinbase of the "original" block format, and to > > build "empty" SHA2-Merkle-Trees containing only the coinbase. > > To unupgraded nodes it looks as if there is a denial-of-service attack > > permanently, while upgraded nodes will seek blocks that conform to the > > SHA3-Merkle-Tree embedded in the coinbase. > > (Do note that this definition of "softfork" is the "> 50% of miners is > > enough to pull everyone to the fork". > > Some thinkers have a stricter definition of "softfork" as "non-upgraded > > nodes can still associate addresses to values in the UTXO set but might not > > be able to detect consensus rules violations in new address types", which > > fits SegWit and Taproot.) > > (In addition, presumably the reason to switch to SHA3 is to avoid potential > > preimage attacks on SHA2, and the coinbase is still in a SHA2-Merkle-Tree, > > so... this is a bad example) > > Perhaps the only things that cannot be usefully changed in a softfork is > > the block header format and how proof-of-work is computed from the block > > header. > > But the flexibility of the coinbase allows us to hook new commitments to > > new Merkle Trees to it, which allows transactions to be annotated with > > additional information that is invisible to unupgraded nodes (similar to > > the `witness` field of SegWit transactions). > > > > Even if you do have a softfork, we should be reminded to look at the > > histories of SegWit and Taproot. > > SegWit became controversial later on, which delayed its activation. > > On the other hand, Taproot had no significant controversy and it was widely > > accepted as being a definite improvement to the network. > > Yet its implementation and deployment still took a long time, and there was > > still controversy on how to properly implement the activation code. > > Any hardforks would not only have to go through the hurdles that Taproot > > and SegWit had to go through, but will also have to pass through the much > > higher hurdle of being a hardfork. > > Thus, anyone contemplating a hardfork, for any reason, must be prepared to > > work on it for several years before anyone even frowns and says "hmm maybe" > > instead of everyone just outright dismissing it with a simple "hardfork = > > hard pass". > > As a simple estimate, I would assume that any hardfork would require twice > > the average amount of engeineering-manpower involved in SegWit and Taproot. > > (this assumes that hardforks are only twice as hard as softforks --- this > > estimate may be wrong, and this might provide only a minimum rather than an > > expected average) > > There are no quick solutions in this space. > > Either we work with what we have and figure out how to get around issues > > with no real capability to fix them at the base layer, or we have insight > > on future problems and start working on future solutions today. > > For example, I know at least one individual was maintaining an "emergency" > > branch to add some kind of post-quantum signature scheme to Bitcoin, in > > case of a quantum break. > > Regards, > > ZmnSCPxj > > > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
