From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id D7D2BC0001 for ; 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 ; 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 ; 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 ; 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 From: ZmnSCPxj Reply-To: ZmnSCPxj 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" 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 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