path: root/c0/a4935bf6cfff58e08cdeb731d0391e65de31dc

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B9495C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 23 May 2021 20:42:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 92A31832E6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 23 May 2021 20:42:13 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=gazeta.pl
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id jEd0rhtSLYCS
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 23 May 2021 20:42:12 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo81.poczta.onet.pl (smtpo81.poczta.onet.pl
 [213.180.149.134])
 by smtp1.osuosl.org (Postfix) with ESMTPS id D1DE8832C6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 23 May 2021 20:42:11 +0000 (UTC)
Received: from pmq3v.m5r2.onet (pmq3v.m5r2.onet [10.174.32.69])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4FpC1S3Wymz1kr0;
 Sun, 23 May 2021 22:41:32 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1621802492; bh=Bcm8TOjE8/YgFdepielc94dVxtFs/SsF4x8y4kbMxHw=;
 h=From:Cc:To:Date:Subject:From;
 b=tziBhJPu4iZ6rEmI3MMuDuQzlmsUBpmJuWHv8gcBbEu4Lla9iEQDcU4WekgvRsISx
 CdrJxv1pbOV8jFt4AdFXrmDyqNO7s9w4+rBIpMy54d3OXkzJllzp16eYYPL/vtKWq/
 T5xxoP6utm1nPybRe1BAqL64lcVVjIsyxRQsdsQU=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.226.233] by pmq3v.m5r2.onet via HTTP id
 202105232240076278010001; Sun, 23 May 2021 22:41:32 +0200
From: vjudeu <vjudeu@gazeta.pl>
X-Priority: 3
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Date: Sun, 23 May 2021 22:41:32 +0200
Message-Id: <132931587-8b83bea7167e21d9e00510989ca34463@pmq3v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.226.233;PL;2
X-Mailman-Approved-At: Mon, 24 May 2021 00:09:13 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Consensus protocol immutability is a feature
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 23 May 2021 20:42:13 -0000

> Because the above block header format is hashed to generate the `prevBloc=
kHash` for the *next* block, it is almost impossible to change the format w=
ithout a hardfork.

First, assume that everything should be validated as today to be backward-c=
ompatible. For that reason, removing SHA-256 is impossible. Then, notice th=
at breaking SHA-256 would mean that there would be more and more leading ze=
roes in "prevBlockHash". Breaking SHA-256 fully would mean reaching all zer=
oes hash. So, the old client would see "prevBlockHash" with all zeroes.

Soft-fork means that previously valid blocks could be invalid, so rules sho=
uld be more strict. And that means we could have two headers, one for SHA-2=
56 and one for SHA-3. Normally, it would mean that our 80-byte headers woul=
d take 160 bytes instead. But we could compress it a little bit if we share=
 some data.

> * `nVersion`: 4 bytes

Version would be some higher number than today and validated as today. It c=
ould be shared for both headers.

> * `prevBlockHash`: 32 bytes, SHA2 of previous block.

Previous block hash in SHA-256 would have more and more leading zeroes, so =
we could reuse them and fill with SHA-3 truncated to N bits. In this way, a=
fter fully breaking SHA-256 it would be fully replaced by SHA-3. Until then=
, first N bits could refer to truncated SHA-3 and the rest to SHA-256. When=
 passing that to old nodes, that bits could be zeroed, but all new nodes sh=
ould see them and perform SHA-3 validation.

Example:

SHA-2 of some block: 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1=
b60a8ce26f
SHA-3 of the same data: 95587d55da5108290c46bac70b622715ae380ef7a313febcc27=
aeb1c51a28d90
32 bytes stored for that block: 95587d550019d6689c085ae165831e934ff763ae46a=
2a6c172b3f1b60a8ce26f

Of course, we should perform SHA-3 on a different data than used for SHA-2,=
 at least merkle root should be recalculated, but it is just an example sho=
wing how single 32-byte string could store data for both hash functions.

> * `merkleTreeRoot`: 32 bytes, SHA2 of topmost Merkle tree node.

If SHA-256 would be broken, then we could use single coinbase transaction t=
o prevent doing transactions in the old way. That transaction would contain=
 SHA-3 of the new merkle root, as you mentioned. New nodes could treat that=
 transaction as some kind of annex to the block header, but still doing SHA=
-2 is needed for backward compatibility. For that reason, storing 32 bytes =
for SHA-2 and 32 bytes for SHA-3 is needed, unless we have some fast way to=
 get hash with all zeroes, then we can save that 32 bytes.

> * `nTime`: 4 bytes, miner-imagined time.

Time should be the same in both headers, so there is no need to duplicate i=
t.

> * `nBits`: 4 bytes, encoded difficulty target

Difficulty should be different for SHA-2 and SHA-3. Finally when SHA-256 wo=
uld be broken, we could reach 03000000 for SHA-256 and store only SHA-3 dif=
ficulty.

> * `nonce`: 4 bytes, random number with no other meaning.

Nonce should be also different for SHA-2 and SHA-3. If SHA-256 would be ful=
ly broken, it could be set to zero for SHA-2 and stored only for SHA-3.

On 2021-05-23 20:12:00 user ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> Good morning vjudeu,
> =

> > > 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 bloc=
k 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 calculate=
d as-is, but the SHA-3 would be truncated only to cover zero bits in SHA-25=
6 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 th=
e new nodes would see correct SHA-3 hashes in the same place. So, for examp=
le if we have 1d00ffff difficulty, the first 32-bits would be zeroes for al=
l 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 trunc=
ate 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 ze=
ro 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 =
tree node, is that what you refer to?
> Do you mean the same Merkle tree node has to hash to some common value in=
 both 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=
 number 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 `prevBloc=
kHash` for the *next* block, it is almost impossible to change the format w=
ithout a hardfork.
> =

> Regaards,
> ZmnSCPxj
> =

> >
> > 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 wid=
er 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 cha=
nges to the transaction and block formats with a softfork.
> > > For example, it is possible to change the Merkle Tree to use SHA3 ins=
tead, in a softfork, by requiring that miners no longer use the "normal" ex=
isting 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 attac=
k permanently, while upgraded nodes will seek blocks that conform to the SH=
A3-Merkle-Tree embedded in the coinbase.
> > > (Do note that this definition of "softfork" is the "> 50% of miners i=
s enough to pull everyone to the fork".
> > > Some thinkers have a stricter definition of "softfork" as "non-upgrad=
ed 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", whi=
ch fits SegWit and Taproot.)
> > > (In addition, presumably the reason to switch to SHA3 is to avoid pot=
ential 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 bloc=
k 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 th=
e `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 the=
re was still controversy on how to properly implement the activation code.
> > > Any hardforks would not only have to go through the hurdles that Tapr=
oot and SegWit had to go through, but will also have to pass through the mu=
ch higher hurdle of being a hardfork.
> > > Thus, anyone contemplating a hardfork, for any reason, must be prepar=
ed 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 "hardf=
ork =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 Ta=
proot.
> > > (this assumes that hardforks are only twice as hard as softforks --- =
this estimate may be wrong, and this might provide only a minimum rather th=
an 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 iss=
ues with no real capability to fix them at the base layer, or we have insig=
ht on future problems and start working on future solutions today.
> > > For example, I know at least one individual was maintaining an "emerg=
ency" 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
> =

> =

>=20