From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id B9495C0001 for ; 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 ; 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 ; 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 ; 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 X-Priority: 3 To: ZmnSCPxj Date: Sun, 23 May 2021 22:41:32 +0200 Message-Id: <132931587-8b83bea7167e21d9e00510989ca34463@pmq3v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.226.233;PL;2 X-Mailman-Approved-At: Mon, 24 May 2021 00:09:13 +0000 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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