ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2021-05-23 📝 Original message:Good morning Jorge, et al, ...
📅 Original date posted:2021-05-23
📝 Original message: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
📝 Original message: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