path: root/8d/7620ddfb7db343b67396461ffa79781579be41

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D7D2BC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 23 May 2021 18:12:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id AFCC84039F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 23 May 2021 18:12:09 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level: 
X-Spam-Status: No, score=-1.602 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,
 FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_NONE=-0.0001,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ofAF-1KdBZWi
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 23 May 2021 18:12:07 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
 [185.70.40.135])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 41FFC40313
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 23 May 2021 18:12:07 +0000 (UTC)
Date: Sun, 23 May 2021 18:12:00 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1621793523;
 bh=JEdygDNuqXK93gWEzEMpDIvM5WTZTrKchhWEz1hGEzs=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
 b=trs3cDeNcaqI7b8Lin/88g1kFH3yly1f0M7ch9ZPAhYcquM4Nxa+OZn2L2j3m7M/K
 y0TdMYwRul15a4SYoG5zoq9b1l2ak3fY845uu2M1IsvA1LtSopiYoA5hRD++zQZREU
 nESw4Ov8iEAaeJpxkNxYFIUNXmrVBLEJCNzb8OOs=
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
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 18:12:10 -0000

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