Date: Sun, 23 May 2021 11:01:32 +0000
To: =?utf-8?Q?Jorge_Tim=C3=B3n?= <jtimon@jtimon.cc>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Pe0KEu5sh80-Bz1nMjOCVhi_tA48kDEFTE5YFob61ADSD_2G9AIFwdJ8VLZnaG6He-elxnFaysFt4588vTWepc4H7xrgESZEav16LECw68I=@protonmail.com>
In-Reply-To: <CABm2gDq5hMN+-BUfY07KEDca0wCjN4G=iWptenBhzjZ3X9Mn7w@mail.gmail.com>
References: <DM6PR02MB6187B30D0941044E24699FF8CD299@DM6PR02MB6187.namprd02.prod.outlook.com>
 <CABm2gDpSWEA+AU1OKGBatuFT8biSO2S8MxfvRH8wHbF7=OEetQ@mail.gmail.com>
 <DM6PR02MB6187F5E2A74950211F3934C9CD289@DM6PR02MB6187.namprd02.prod.outlook.com>
 <CABm2gDq5hMN+-BUfY07KEDca0wCjN4G=iWptenBhzjZ3X9Mn7w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Consensus protocol immutability is a feature
Precedence: list

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 tha=
n 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 close=
d.

The example of SegWit shows us that we can in fact create massive changes t=
o 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 SH=
A3-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 perm=
anently, while upgraded nodes will seek blocks that conform to the SHA3-Mer=
kle-Tree embedded in the coinbase.

(Do note that this definition of "softfork" is the "> 50% of miners is enou=
gh to pull everyone to the fork".
Some thinkers have a stricter definition of "softfork" as "non-upgraded nod=
es 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 fit=
s 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 th=
e block header format and how proof-of-work is computed from the block head=
er.
But the flexibility of the coinbase allows us to hook new commitments to ne=
w Merkle Trees to it, which allows transactions to be annotated with additi=
onal information that is invisible to unupgraded nodes (similar to the `wit=
ness` field of SegWit transactions).


------------


Even if you *do* have a softfork, we should be reminded to look at the hist=
ories 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 an=
d SegWit had to go through, but will *also* have to pass through the much h=
igher 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 ma=
ybe" instead of everyone just outright dismissing it with a simple "hardfor=
k =3D 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 e=
stimate 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 wi=
th 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 cas=
e of a quantum break.

Regards,
ZmnSCPxj