From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 53FD9C0001 for ; Sun, 23 May 2021 11:01:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 303D360684 for ; Sun, 23 May 2021 11:01:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwJa_Q17_DWl for ; Sun, 23 May 2021 11:01:39 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by smtp3.osuosl.org (Postfix) with ESMTPS id 0679D605B2 for ; Sun, 23 May 2021 11:01:38 +0000 (UTC) Date: Sun, 23 May 2021 11:01:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1621767695; bh=L5n97p11855pqDpcywpLzxmpQNTgtcqyTgJ7Z5EcUME=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=XCltUVVHfwCnfoORUOnbvXIzIYV+IpFUFEtxYmYzVLTeJ8mAyDACz4exJH4xhUrB/ B0B9gTQUpFJivdPDv7TBG2DPvIB5JGe8WXTMt2tsx28N5bYPJOziVgeYrLb7RnPk9U PXM+ArvGNJmetQ0TuRJdZ1AX+XgiXm8WRQYpIJ/I= To: =?utf-8?Q?Jorge_Tim=C3=B3n?= , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 11:01:40 -0000 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 tha= n 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 close= d. The example of SegWit shows us that we can in fact create massive changes t= o 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" existing= Merkle Tree, but instead to require miners to embed a commitment to the SH= A3-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 attack perm= anently, while upgraded nodes will seek blocks that conform to the SHA3-Mer= kle-Tree embedded in the coinbase. (Do note that this definition of "softfork" is the "> 50% of miners is enou= gh to pull everyone to the fork". Some thinkers have a stricter definition of "softfork" as "non-upgraded nod= es 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 fit= s SegWit and Taproot.) (In addition, presumably the reason to switch to SHA3 is to avoid potential= 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 th= e block header format and how proof-of-work is computed from the block head= er. But the flexibility of the coinbase allows us to hook new commitments to ne= w Merkle Trees to it, which allows transactions to be annotated with additi= onal information that is invisible to unupgraded nodes (similar to the `wit= ness` field of SegWit transactions). ------------ Even if you *do* have a softfork, we should be reminded to look at the hist= ories 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 there was= still controversy on how to properly implement the activation code. Any hardforks would not only have to go through the hurdles that Taproot an= d SegWit had to go through, but will *also* have to pass through the much h= igher 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 twice = the average amount of engeineering-manpower involved in SegWit and Taproot. (this assumes that hardforks are only twice as hard as softforks --- this e= stimate 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 issues wi= th 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 "emergency" = branch to add some kind of post-quantum signature scheme to Bitcoin, in cas= e of a quantum break. Regards, ZmnSCPxj