Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 85E33C0019 for ; Sat, 17 Apr 2021 11:47:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 7543D60599 for ; Sat, 17 Apr 2021 11:47:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no 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 gcow7SBgOggW for ; Sat, 17 Apr 2021 11:47:25 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp3.osuosl.org (Postfix) with ESMTPS id 9E69F600BB for ; Sat, 17 Apr 2021 11:47:25 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1lXjQ1-0007WE-PG; Sat, 17 Apr 2021 21:47:23 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Sat, 17 Apr 2021 21:47:17 +1000 Date: Sat, 17 Apr 2021 21:47:17 +1000 From: Anthony Towns To: Erik Aronesty , Bitcoin Protocol Discussion Message-ID: <20210417114717.GA8079@erisian.com.au> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Score-int: -18 X-Spam-Bar: - Subject: Re: [bitcoin-dev] Gradual transition to an alternate proof without a hard fork. 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: Sat, 17 Apr 2021 11:47:30 -0000 On Fri, Apr 16, 2021 at 04:48:35PM -0400, Erik Aronesty via bitcoin-dev wrote: > The transition *could* look like this: > - validating nodes begin to require proof-of-burn, in addition to > proof-of-work (soft fork) > - the extra expense makes it more expensive for miners, so POW slowly drops > - on a predefined schedule, POB required is increased to 100% of the > "required work" to mine > Given all of that, am I correct in thinking that a hard fork would not > be necessary? It depends what you mean by a "hard fork". By the definition that "the old software will consider the chain followed by new versions of the software as valid" it's a soft fork. But it doesn't maintain the property "old software continues to follow the same chain as new software, provided the economic majority has adopted the new software" -- because after the PoW part has dropped its difficulty substantitally, people can easily/cheaply make a new chain that doesn't include proof-of-burn, and has weak proof-of-work that's nevertheless higher than the proof-of-burn chain, so old nodes will switch to it, while new nodes will continue to follow the proof-of-burn chain. So I think that means it needs to be treated as a hard fork: everyone needs to be running the new software by some date to ensure they follow the same chain. (The same argument applies to trying to switch to a different PoW algorithm via a soft fork; I forget who explained this to me) Jeremy wrote: > I think you need to hard deprecate the PoW for this to work, otherwise > all old miners are like "toxic waste". > > Imagine one miner turns on a S9 and then ramps up difficulty for > everyone else. If it's a soft-fork, you could only ramp up the PoW difficulty by mining more than one block every ten minutes, but presumably the proof-of-burn scheme would have its own way of preventing burners from mining blocks too fast (it was assumption 2). Cheers, aj