From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 959E2C0001 for ; Sun, 23 May 2021 16:27:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 7F4CB4027F for ; Sun, 23 May 2021 16:27:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=gazeta.pl Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0dpANeCZWrd for ; Sun, 23 May 2021 16:27:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from smtpo114.poczta.onet.pl (smtpo114.poczta.onet.pl [213.180.149.167]) by smtp2.osuosl.org (Postfix) with ESMTPS id EBF9E400D0 for ; Sun, 23 May 2021 16:27:57 +0000 (UTC) Received: from pmq3v.m5r2.onet (pmq3v.m5r2.onet [10.174.32.69]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4Fp5Nk0XvWz2K26; Sun, 23 May 2021 18:27:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1621787270; bh=0WdsnsLS8ua1Ok/sk31gUl1bCYL2yht6VwiRXoHDLZQ=; h=From:To:Date:Subject:From; b=jow/lvXKMI9008WCk1NkdX1puX6kddkyqpCSTwh3gEKlLdV+s5ccWxwHoIEkO/kNv 2NxN0FkYIem5LLv48FhaQiyOk0uaZEUSIBPMd66j6ECu4MEw/MLc+vhU1cOFDVA96t QhyyaG3iMlfVR4w3HIJdjJF7nQLSJSeYVvOZi7D4= 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 202105231826224592010001; Sun, 23 May 2021 18:27:50 +0200 From: vjudeu X-Priority: 3 To: ZmnSCPxj , "bitcoin-dev@lists.linuxfoundation.org" Date: Sun, 23 May 2021 18:27:47 +0200 Message-Id: <132915149-33e6cd5749dc76930de03704c89b4399@pmq3v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.226.233;PL;2 X-Mailman-Approved-At: Sun, 23 May 2021 17:17:17 +0000 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 16:27:59 -0000 > 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 block he= ader. 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 calculated as= -is, but the SHA-3 would be truncated only to cover zero bits in SHA-256 ha= shes. 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 the ne= w nodes would see correct SHA-3 hashes in the same place. So, for example i= f we have 1d00ffff difficulty, the first 32-bits would be zeroes for all ol= d 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 truncate = 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 zero b= its in our mixed SHA-256 plus SHA-3 consensus. On 2021-05-23 13:01:32 user ZmnSCPxj via bitcoin-dev 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 t= han can be trivially expected. > = > For instance, maaku7 once proposed a softfork that could potentially chan= ge the block discovery rate as a softfork. > Although this required exploiting a consensus bug that has since been clo= sed. > = > The example of SegWit shows us that we can in fact create massive changes= to the transaction and block formats with a softfork. > = > For example, it is possible to change the Merkle Tree to use SHA3 instead= , in a softfork, by requiring that miners no longer use the "normal" existi= ng 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 bui= ld "empty" SHA2-Merkle-Trees containing only the coinbase. > To unupgraded nodes it looks as if there is a denial-of-service attack pe= rmanently, while upgraded nodes will seek blocks that conform to the SHA3-M= erkle-Tree embedded in the coinbase. > = > (Do note that this definition of "softfork" is the "> 50% of miners is en= ough to pull everyone to the fork". > Some thinkers have a stricter definition of "softfork" as "non-upgraded n= odes can still associate addresses to values in the UTXO set but might not = be able to detect consensus rules violations in new address types", which f= its SegWit and Taproot.) > = > (In addition, presumably the reason to switch to SHA3 is to avoid potenti= al preimage attacks on SHA2, and the coinbase is still in a SHA2-Merkle-Tre= e, 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 block he= ader. > 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 addi= tional information that is invisible to unupgraded nodes (similar to the `w= itness` 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 wide= ly accepted as being a definite improvement to the network. > Yet its implementation and deployment still took a long time, and there w= as still controversy on how to properly implement the activation code. > = > Any hardforks would not only have to go through the hurdles that Taproot = 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 t= o 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 twic= e the average amount of engeineering-manpower involved in SegWit and Taproo= t. > (this assumes that hardforks are only twice as hard as softforks --- this= estimate may be wrong, and this might provide only a minimum rather than a= n expected average) > = > There are no quick solutions in this space. > Either we work with what we have and figure out how to get around issues = with no real capability to fix them at the base layer, or we have insight o= n future problems and start working on future solutions today. > For example, I know at least one individual was maintaining an "emergency= " branch to add some kind of post-quantum signature scheme to Bitcoin, in c= ase of a quantum break. > = > Regards, > ZmnSCPxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > =