Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: vjudeu <vjudeu@gazeta.pl>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
Date: Sun, 23 May 2021 18:27:47 +0200
Message-Id: <132915149-33e6cd5749dc76930de03704c89b4399@pmq3v.m5r2.onet>
Subject: Re: [bitcoin-dev] Consensus protocol immutability is a feature
Precedence: list

> 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 he=
ader.

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 ha=
shes. 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 ne=
w nodes would see correct SHA-3 hashes in the same place. So, for example i=
f we have 1d00ffff difficulty, the first 32-bits would be zeroes for all ol=
d 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 b=
its in our mixed SHA-256 plus SHA-3 consensus.

On 2021-05-23 13:01:32 user ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.lin=
uxfoundation.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 t=
han can be trivially expected.
> =

> For instance, maaku7 once proposed a softfork that could potentially chan=
ge the block discovery rate as a softfork.
> Although this required exploiting a consensus bug that has since been clo=
sed.
> =

> 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" existi=
ng 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 bui=
ld "empty" SHA2-Merkle-Trees containing only the coinbase.
> To unupgraded nodes it looks as if there is a denial-of-service attack pe=
rmanently, while upgraded nodes will seek blocks that conform to the SHA3-M=
erkle-Tree embedded in the coinbase.
> =

> (Do note that this definition of "softfork" is the "> 50% of miners is en=
ough to pull everyone to the fork".
> Some thinkers have a stricter definition of "softfork" as "non-upgraded n=
odes 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 f=
its SegWit and Taproot.)
> =

> (In addition, presumably the reason to switch to SHA3 is to avoid potenti=
al preimage attacks on SHA2, and the coinbase is still in a SHA2-Merkle-Tre=
e, 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 he=
ader.
> 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 addi=
tional information that is invisible to unupgraded nodes (similar to the `w=
itness` field of SegWit transactions).
> =

> =

> ------------
> =

> =

> Even if you *do* have a softfork, we should be reminded to look at the hi=
stories 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 wide=
ly accepted as being a definite improvement to the network.
> Yet its implementation and deployment still took a long time, and there w=
as 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 t=
o work on it for several **years** before anyone even frowns and says "hmm =
maybe" instead of everyone just outright dismissing it with a simple "hardf=
ork =3D hard pass".
> As a simple estimate, I would assume that any hardfork would require twic=
e the average amount of engeineering-manpower involved in SegWit and Taproo=
t.
> (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 a=
n 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 o=
n 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 c=
ase of a quantum break.
> =

> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> =