> 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. 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
