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

Good morning vjudeu,

> > Perhaps the only things that cannot be usefully changed in a softfork i=
s 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 S=
HA-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 se=
e 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 sa=
me place. The difficulty could tell us how many zero bits we should truncat=
e our SHA-3 result to. Also, in the same way we could introduce SHA-4 in th=
e 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 tr=
ee node, is that what you refer to?
Do you mean the same Merkle tree node has to hash to some common value in b=
oth 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 n=
umber 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 `prevBlockH=
ash` for the *next* block, it is almost impossible to change the format wit=
hout a hardfork.

Regaards,
ZmnSCPxj

>
> On 2021-05-23 13:01:32 user ZmnSCPxj via bitcoin-dev bitcoin-dev@lists.li=
nuxfoundation.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 ch=
ange the block discovery rate as a softfork.
> > Although this required exploiting a consensus bug that has since been c=
losed.
> > The example of SegWit shows us that we can in fact create massive chang=
es to the transaction and block formats with a softfork.
> > For example, it is possible to change the Merkle Tree to use SHA3 inste=
ad, in a softfork, by requiring that miners no longer use the "normal" exis=
ting Merkle Tree, but instead to require miners to embed a commitment to th=
e SHA3-Merkle-Tree on the coinbase of the "original" block format, and to b=
uild "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 no=
t 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 poten=
tial preimage attacks on SHA2, and the coinbase is still in a SHA2-Merkle-T=
ree, so... this is a bad example)
> > Perhaps the only things that cannot be usefully changed in a softfork i=
s 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 t=
o new Merkle Trees to it, which allows transactions to be annotated with ad=
ditional 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 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 wi=
dely 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 Taproo=
t 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 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 tw=
ice the average amount of engeineering-manpower involved in SegWit and Tapr=
oot.
> > (this assumes that hardforks are only twice as hard as softforks --- th=
is 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 issue=
s 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 "emergen=
cy" 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