a017d7022c52238aea2c021c6f6c441439a32f
1 Return-Path: <earonesty@gmail.com> 2 Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) 3 by lists.linuxfoundation.org (Postfix) with ESMTP id 657E2C0001 4 for <bitcoin-dev@lists.linuxfoundation.org>; 5 Fri, 21 May 2021 20:55:11 +0000 (UTC) 6 Received: from localhost (localhost [127.0.0.1]) 7 by smtp3.osuosl.org (Postfix) with ESMTP id 4729B615BD 8 for <bitcoin-dev@lists.linuxfoundation.org>; 9 Fri, 21 May 2021 20:55:11 +0000 (UTC) 10 X-Virus-Scanned: amavisd-new at osuosl.org 11 X-Spam-Flag: NO 12 X-Spam-Score: 1.299 13 X-Spam-Level: * 14 X-Spam-Status: No, score=1.299 tagged_above=-999 required=5 15 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 16 FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, 17 HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, 18 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 19 Authentication-Results: smtp3.osuosl.org (amavisd-new); 20 dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com 21 Received: from smtp3.osuosl.org ([127.0.0.1]) 22 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) 23 with ESMTP id DpvPszElGChd 24 for <bitcoin-dev@lists.linuxfoundation.org>; 25 Fri, 21 May 2021 20:55:10 +0000 (UTC) 26 X-Greylist: whitelisted by SQLgrey-1.8.0 27 Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com 28 [IPv6:2607:f8b0:4864:20::52c]) 29 by smtp3.osuosl.org (Postfix) with ESMTPS id 44289606C5 30 for <bitcoin-dev@lists.linuxfoundation.org>; 31 Fri, 21 May 2021 20:55:10 +0000 (UTC) 32 Received: by mail-pg1-x52c.google.com with SMTP id v14so12457696pgi.6 33 for <bitcoin-dev@lists.linuxfoundation.org>; 34 Fri, 21 May 2021 13:55:10 -0700 (PDT) 35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 36 d=q32-com.20150623.gappssmtp.com; s=20150623; 37 h=mime-version:references:in-reply-to:from:date:message-id:subject:to 38 :cc:content-transfer-encoding; 39 bh=hrRmkd9fdHnSJ5KShxp9QpKTDkW3v4bo1DF4dzDJu/M=; 40 b=O9wFWnxio2vtq+YrMVvdzvD/byW8BmZef/+W01TREVlq0mnqh4AXWTInE3z/soc2tZ 41 x8xqdIVpoJnDobdAA1nmuABAOSaHFHrwgaJC4GJN3/nBNENvG6rRwUYhlTlwmEZC/qYn 42 DTenuxshXFi+aJs+aH+f9cRza+DIYzO96COlCd9RpQXA5F+Yf4vrw2nSG7NQtdiSW+Ll 43 0tZcfLZNXE/u8LVjPX/3giR1LKKVjA+J6/6TaJGmQqZ3wRtmJUI1KB8jCbT5yHZHKNSC 44 pbGaBBtTIOEIKksy7A1oIlyBwYfq2atFrbhWcz9BcTVS/WBUQOiZOsYFp5LvfcZHPlKu 45 QUlw== 46 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 47 d=1e100.net; s=20161025; 48 h=x-gm-message-state:mime-version:references:in-reply-to:from:date 49 :message-id:subject:to:cc:content-transfer-encoding; 50 bh=hrRmkd9fdHnSJ5KShxp9QpKTDkW3v4bo1DF4dzDJu/M=; 51 b=Rzpt6dYYvSYVhmg+8AygdHp8U5XoM0ZkO7iK26NaY62sqauBTZszouG9/iqeALQWh5 52 UH5pbIBzZhi9kzr7Sgz/kA070rxA2bNnch0q1Pg8L09PSv61wzH6vQhoYTBk0tVnO9h0 53 6b+zTF+N3DM5VJnbMd7fiMY2LPk18q/Nm/oAfFS/kC66gKuvRD4BVVdKikSQQBfrKvOK 54 DvYXkSkSkz7Ydx2Re+N1rPGf7EkTRTljgHJXqZiV5oLlUl+lV6Brw/h05HnQeEWj51PG 55 f2aZv7hIXIjNN6JtVVOfva/n/USm/CFqHfv9+31l7CQ+uFT3FJX9Lccwknwvl1onZKYa 56 0O/w== 57 X-Gm-Message-State: AOAM530ghyG+unCgezsTmzGc8AeDCLsK1zB4v3Y7pKVA7fak2qFavdxC 58 fjD0Fxj/b3mFw+lUw0u7OX1SPL9FQzdHHbktyjaekY0= 59 X-Google-Smtp-Source: ABdhPJzMuddoc9B82SyNFETzK6CVhsK4P58aMwv+yEb1CZa2w0Fsnt7k1EYf4/ryLu34lN8kRP+5Jinvzm7L3OAAt8c= 60 X-Received: by 2002:a63:416:: with SMTP id 22mr605341pge.363.1621630509542; 61 Fri, 21 May 2021 13:55:09 -0700 (PDT) 62 MIME-Version: 1.0 63 References: <CAJowKgJNefXZTCJk_EK4JC7uPKsTrGv=yUROpjL_7GGbfNrrvA@mail.gmail.com> 64 <20210417114717.GA8079@erisian.com.au> 65 <CAGpPWDbCJKUpd=ufDXrSNwgm7DhQwDiGqfL-+2yqyviFhGDpvA@mail.gmail.com> 66 In-Reply-To: <CAGpPWDbCJKUpd=ufDXrSNwgm7DhQwDiGqfL-+2yqyviFhGDpvA@mail.gmail.com> 67 From: Erik Aronesty <erik@q32.com> 68 Date: Fri, 21 May 2021 16:54:57 -0400 69 Message-ID: <CAJowKg+xG+7T+CcuCJ6cQpuW+BxhL-710YU-kNZVyU_p1XYjDQ@mail.gmail.com> 70 To: Billy Tetrud <billy.tetrud@gmail.com> 71 Content-Type: text/plain; charset="UTF-8" 72 Content-Transfer-Encoding: quoted-printable 73 X-Mailman-Approved-At: Fri, 21 May 2021 21:53:42 +0000 74 Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 75 Anthony Towns <aj@erisian.com.au> 76 Subject: Re: [bitcoin-dev] Gradual transition to an alternate proof without 77 a hard fork. 78 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org 79 X-Mailman-Version: 2.1.15 80 Precedence: list 81 List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> 82 List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 83 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> 84 List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> 85 List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> 86 List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> 87 List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 88 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> 89 X-List-Received-Date: Fri, 21 May 2021 20:55:11 -0000 90 91 the original argument was correct: has to be a hard fork. 92 93 otherwise there's nothing to prevent a miner with leftover asics from 94 "tricking" old nodes to following another chain. 95 96 a hard fork is a really, really high bar - there would have to be 97 something very broken to justify it. 98 99 quantum-hashing or whatever (proof-of burn of course is as 100 quantum-safe as the underlying chain is... so it's nice to switch to, 101 should it be necessary) 102 103 On Fri, May 21, 2021 at 4:11 PM Billy Tetrud <billy.tetrud@gmail.com> wrote= 104 : 105 > 106 > The way I would think of doing this kind of thing (switching consensus pr= 107 otocol), which includes switching to a different hash function for proof of= 108 work, is to have a transitionary period where both consensus mechanisms ar= 109 e used to mine. This transitionary period should be long (perhaps years) to= 110 give miners time to manage the logistics of switching over. However, becau= 111 se there would be no trustless mechanism to automatically relate the amount= 112 of work (or burn, or whatever) done between the two consensus mechanisms, = 113 there would need to be some manually determined estimate of equivalence har= 114 d coded into the software. Eg, if we're talking about a different hash func= 115 tion, we could define in software that 100 current hashes is about equal to= 116 10 hashes using the new algorithm. This could even be set such that its ma= 117 rginally (but significantly) favorable to use the new hash function, to giv= 118 e additional incentive to miners to switch. The risk with that is that hard= 119 ware that processes that new hash function might innovate arbitrarily more = 120 quickly than the old hash function (which is likely to have somewhat platea= 121 ued), and this might make the manually estimated equivalence become inaccur= 122 ate in a way that could significantly reduce the security of the network. a= 123 change like this could be fraught with perils if the miners using each mec= 124 hanism don't end up cooperating to ensure that equivalence is set fairly, a= 125 nd instead make efforts to attempt to unfairly increase their share. 126 > 127 > In any case, the idea is that you'd have a smooth switch over from (block= 128 s the old mechanism creates / blocks the new mechanism creates) 100%/0% -> = 129 75%/25% -> 50/50 -> eventually 0%/100%. Or at some fraction of total hashpo= 130 wer, (eg 95%) the old consensus mechanism could simply be shut off - which = 131 would give additional incentive for miners to switch sooner rather than lat= 132 er. However, it would probably be best to make this cut off more like 99% t= 133 han 95%, since screwing over 5% of the hashpower for a few months is probab= 134 ly not necessary or ideal. It might actually just be better to have a time-= 135 based cutoff. Or have the final switch over lock in at 95% with a few month= 136 s to give the other 5% time to switch over (and if they don't then its on t= 137 hem). 138 > 139 > I would think this could work for switch between any consensus mechanism.= 140 However, how to do this in a soft fork is another story. It sounds like it= 141 s doable from other people's comments. 142 > 143 > On Sat, Apr 17, 2021 at 1:47 AM Anthony Towns via bitcoin-dev <bitcoin-de= 144 v@lists.linuxfoundation.org> wrote: 145 >> 146 >> On Fri, Apr 16, 2021 at 04:48:35PM -0400, Erik Aronesty via bitcoin-dev = 147 wrote: 148 >> > The transition *could* look like this: 149 >> > - validating nodes begin to require proof-of-burn, in addition to 150 >> > proof-of-work (soft fork) 151 >> > - the extra expense makes it more expensive for miners, so POW slowly= 152 drops 153 >> > - on a predefined schedule, POB required is increased to 100% of the 154 >> > "required work" to mine 155 >> > Given all of that, am I correct in thinking that a hard fork would not 156 >> > be necessary? 157 >> 158 >> It depends what you mean by a "hard fork". By the definition that 159 >> "the old software will consider the chain followed by new versions of 160 >> the software as valid" it's a soft fork. But it doesn't maintain the 161 >> property "old software continues to follow the same chain as new softwar= 162 e, 163 >> provided the economic majority has adopted the new software" -- because 164 >> after the PoW part has dropped its difficulty substantitally, people can 165 >> easily/cheaply make a new chain that doesn't include proof-of-burn, and 166 >> has weak proof-of-work that's nevertheless higher than the proof-of-burn 167 >> chain, so old nodes will switch to it, while new nodes will continue to 168 >> follow the proof-of-burn chain. 169 >> 170 >> So I think that means it needs to be treated as a hard fork: everyone 171 >> needs to be running the new software by some date to ensure they follow 172 >> the same chain. 173 >> 174 >> (The same argument applies to trying to switch to a different PoW 175 >> algorithm via a soft fork; I forget who explained this to me) 176 >> 177 >> Jeremy wrote: 178 >> > I think you need to hard deprecate the PoW for this to work, otherwise 179 >> > all old miners are like "toxic waste". 180 >> > 181 >> > Imagine one miner turns on a S9 and then ramps up difficulty for 182 >> > everyone else. 183 >> 184 >> If it's a soft-fork, you could only ramp up the PoW difficulty by mining 185 >> more than one block every ten minutes, but presumably the proof-of-burn 186 >> scheme would have its own way of preventing burners from mining blocks 187 >> too fast (it was assumption 2). 188 >> 189 >> Cheers, 190 >> aj 191 >> 192 >> _______________________________________________ 193 >> bitcoin-dev mailing list 194 >> bitcoin-dev@lists.linuxfoundation.org 195 >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 196