diff options
| author | Adam Back <adam.back@gmail.com> | 2017-09-15 10:14:13 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-09-15 09:14:15 +0000 |
| commit | abb0937da3cc6093bae247e20e03fed409705f8e (patch) | |
| tree | 11079ab9c6df95c4fea3eda93cabb45d2d789423 | |
| parent | 4fd7422724db593f921c5b36306cb12888e9bbf9 (diff) | |
| download | pi-bitcoindev-abb0937da3cc6093bae247e20e03fed409705f8e.tar.gz pi-bitcoindev-abb0937da3cc6093bae247e20e03fed409705f8e.zip | |
Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?
| -rw-r--r-- | 67/ba5df1e12bd931934ecbfaeabc62917b2fe870 | 321 |
1 files changed, 321 insertions, 0 deletions
diff --git a/67/ba5df1e12bd931934ecbfaeabc62917b2fe870 b/67/ba5df1e12bd931934ecbfaeabc62917b2fe870 new file mode 100644 index 000000000..839751662 --- /dev/null +++ b/67/ba5df1e12bd931934ecbfaeabc62917b2fe870 @@ -0,0 +1,321 @@ +Return-Path: <adam.back@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id A007E97A + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 15 Sep 2017 09:14:15 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-qt0-f178.google.com (mail-qt0-f178.google.com + [209.85.216.178]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D2578203 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 15 Sep 2017 09:14:14 +0000 (UTC) +Received: by mail-qt0-f178.google.com with SMTP id i13so1583269qtc.11 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 15 Sep 2017 02:14:14 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:reply-to:in-reply-to:references:from:date:message-id + :subject:to:cc; + bh=1T8tIMO1iqRgnuJwiz4wdaLnP+m+Aa1pKuVTQxUN2JY=; + b=DII+RhlpZyERzu4TyhdISryKNhCsXJHXePkQUtHOtKk/qk/uqO096IFWCJ9V8CuOtb + 0BYbx1iCWyoaG44hUZoUf9rXg/2ZvrLEUxpL8Z0WOSTEC/gsNuTPhGBF8psBaYdjcSAD + fZD2tax5OFnqCaShK6WK4f2GgXqKyNnnfcNZPBvbxlhiCjJodPq48ML9WsF2f/tRPuVe + ase75wR57jVT3aFGZcuxhY6RQkgkOSX4mEAkrkhgOK8f+aRKdEW3EFspIG+gNGJ3fUYD + 6/AOLJVZGlaAIl7NXWy0LsxEDzfd/RZscPOOqOvkloEPpPydIww4pls5IVBhcVGdCuzq + v+PQ== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:reply-to:in-reply-to:references + :from:date:message-id:subject:to:cc; + bh=1T8tIMO1iqRgnuJwiz4wdaLnP+m+Aa1pKuVTQxUN2JY=; + b=VX4/kuzPpgnTnZBNmo5dn0KRGiNi8p2aflAtzd2f/rFLHYKIZrWv3ntEfN0ANsUo/a + wqlqnUfM23F05IlYE1WK0Q/m0TytWMg1HNebAUzpIAZeq0qbU66pJfbwz1PT+l+BoYPn + X74EPXlc9X3tXh3LQHUdDbe955lEDKImQasRvhzPylScZ7kzkcrC5hy7K4vucmShCB9C + LbluwJpVpHIlfrY1aBfUiJk0Pi2ltLCCHvOZxIN7L9kA6ECQuPuEIUdnRaF1hEBCKG1a + Ib4PW8TDpk0hPnZjVdhDQQ4ynSMX0x2JRFmFTfWRNarQZ3mKYeC7pZYpZ6SvMfaQ6cZP + zzuw== +X-Gm-Message-State: AHPjjUhuIMfQ2PcnlbT6EmcqZDRvmZvyuq5Jm5i7Wp5XQTVFdx74TVDi + ON/0ssGgsQ8Xr1Nyqlzhno8oPuszwKG3M0usjwg= +X-Google-Smtp-Source: AOwi7QC+4NX3zWgaymz+qRR3Pf7IbEWIyM71XxUcjjlR3PtoZcM8TeNbsLYFfHQLz2qMkBxodX1o2UsUXRr8ocNAFLk= +X-Received: by 10.237.33.199 with SMTP id m7mr37248379qtc.328.1505466853691; + Fri, 15 Sep 2017 02:14:13 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.12.132.100 with HTTP; Fri, 15 Sep 2017 02:14:13 -0700 (PDT) +Received: by 10.12.132.100 with HTTP; Fri, 15 Sep 2017 02:14:13 -0700 (PDT) +Reply-To: adam@cypherspace.org +In-Reply-To: <SU02clg--S4TtIK4TZIytgdnHE8SzXBwSEb_FN5edtPAaojLwCEd6OTNkBUrDiH1FwHPuD4D5yByE7r4Fz_-CVzzU9KK0xvmDGlWNxTp3aU=@protonmail.com> +References: <9e212eae-08d5-d083-80d9-a8e29679fcdc@osc.co.cr> + <SU02clg--S4TtIK4TZIytgdnHE8SzXBwSEb_FN5edtPAaojLwCEd6OTNkBUrDiH1FwHPuD4D5yByE7r4Fz_-CVzzU9KK0xvmDGlWNxTp3aU=@protonmail.com> +From: Adam Back <adam.back@gmail.com> +Date: Fri, 15 Sep 2017 10:14:13 +0100 +Message-ID: <CALqxMTFEA2X0GJwF8rO=8twsgW=brrzScpDD=owiK9otocdjoA@mail.gmail.com> +To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>, + ZmnSCPxj <ZmnSCPxj@protonmail.com> +Content-Type: multipart/alternative; boundary="001a113ef3ba091614055936d176" +X-Spam-Status: No, score=-0.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, + DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, + RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Subject: Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented? +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Fri, 15 Sep 2017 09:14:15 -0000 + +--001a113ef3ba091614055936d176 +Content-Type: text/plain; charset="UTF-8" + +True however in principle a soft-fork can also be soft-forked out. Eg say a +publicly known soft-fork done by miners only that user node software did +not upgrade for first by opt-in adoption. If there was consensus against by +users and ecosystem a node/user flag day soft fork could block it's +effects. Or if a soft fork was determined to have a major bug. + +However most types of soft fork are opt-in and so mostly that situation +seems unlikely. A censorship soft-fork is harder, that's a standard +hard-fork to bypass with current fungibility mechanisms. + +Adam + +On Sep 15, 2017 08:12, "ZmnSCPxj via bitcoin-dev" < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> Good morning Dan, +> +> My understanding is that it is impossible for soft forks to be prevented. +> +> 1. Anyone-can-spend +> +> There are a very large number of anyone-can-spend scripts, and it would be +> very impractical to ban them all. +> +> For example, the below output script is anyone-can-spend +> +> <random number> OP_TRUE +> +> So is the below: +> +> OP_SIZE <random small number> OP_EQUAL +> +> Or: +> +> OP_1ADD <random number> OP_EQUAL +> +> Or: +> +> OP_BOOLAND +> +> Or: +> +> OP_BOOLOR +> +> And so on. +> +> So no, it is not practically possible to ban anyone-can-spend outputs, as +> there are too many potential scriptPubKey that anyone can spend. +> +> It is even possible to have an output that requires a proof-of-work, like +> so: +> +> OP_HASH256 <difficulty target> OP_LESSTHAN +> +> All the above outputs are disallowed from propagation by IsStandard, but a +> miner can put them validly in a block, and IsStandard is not consensus code +> and can be modified. +> +> 2. Soft fork = restrict +> +> It is possible (although unlikely) for a majority of miners to run soft +> forking code which the rest of us are not privy to. +> +> For example, for all we know, miners are already blacklisting spends on +> Satoshi's coins. We would not be able to detect this at all, since no +> transaction that spends Satoshi's coins have been broadcast, ever. It is +> thus indistinguishable from a world where Satoshi lost his private keys. +> Of course, the world where Satoshi never spent his coins and miners are +> blacklisting Satoshi's coins, is more complex than the world where Satoshi +> never spent his coins, so it is more likely that miners are not +> blacklisting. +> +> But the principle is there. We may already be in a softfork whose rules +> we do not know, and it just so happens that all our transactions today do +> not violate those rules. It is impossible for us to know this, but it is +> very unlikely. +> +> Soft forks apply further restrictions on Bitcoin. Hard forks do not. +> Thus, if everyone else is entering a soft fork and we are oblivious, we do +> not even know about it. Whereas, if everyone else is entering a hard fork, +> we will immediately see (and reject) invalid transactions and blocks. +> +> Thus the only way to prevent soft fork is to hard fork against the new +> soft fork, like Bcash did. +> +> Regards, +> ZmnSCPxj +> +> -------- Original Message -------- +> Subject: [bitcoin-dev] hypothetical: Could soft-forks be prevented? +> Local Time: September 13, 2017 5:50 PM +> UTC Time: September 13, 2017 9:50 AM +> From: bitcoin-dev@lists.linuxfoundation.org +> To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +> +> Hi, I am interested in the possibility of a cryptocurrency software +> (future bitcoin or a future altcoin) that strives to have immutable +> consensus rules. +> +> The goal of such a cryptocurrency would not be to have the latest and +> greatest tech, but rather to be a long-term store of value and to offer +> investors great certainty and predictability... something that markets +> tend to like. And of course, zero consensus rule changes also means +> less chance of new bugs and attack surface remains the same, which is +> good for security. +> +> Of course, hard-forks are always possible. But that is a clear split +> and something that people must opt into. Each party has to make a +> choice, and inertia is on the side of the status quo. Whereas +> soft-forks sort of drag people along with them, even those who oppose +> the changes and never upgrade. In my view, that is problematic, +> especially for a coin with permanent consensus rule immutability as a +> goal/ethic. +> +> As I understand it, bitcoin soft-forks always rely on anyone-can-spend +> transactions. If those were removed, would it effectively prevent +> soft-forks, or are there other possible mechanisms? How important are +> any-one-can spend tx for other uses? +> +> More generally, do you think it is possible to programmatically +> avoid/ban soft-forks, and if so, how would you go about it? +> +> +> +> +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> +> + +--001a113ef3ba091614055936d176 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"auto">True however in principle a soft-fork can also be soft-fo= +rked out. Eg say a publicly known soft-fork done by miners only that user n= +ode software did not upgrade for first by opt-in adoption. If there was con= +sensus against by users and ecosystem a node/user flag day soft fork could = +block it's effects. Or if a soft fork was determined to have a major bu= +g.<div dir=3D"auto"><br></div><div dir=3D"auto">However most types of soft = +fork are opt-in and so mostly that situation seems unlikely.=C2=A0 A censor= +ship soft-fork is harder, that's a standard hard-fork to bypass with cu= +rrent fungibility mechanisms.</div><div dir=3D"auto"><br></div><div dir=3D"= +auto">Adam</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu= +ote">On Sep 15, 2017 08:12, "ZmnSCPxj via bitcoin-dev" <<a hre= +f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxf= +oundation.org</a>> wrote:<br type=3D"attribution"><blockquote class=3D"g= +mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l= +eft:1ex"><div>Good morning Dan,<br></div><div><br></div><div>My understandi= +ng is that it is impossible for soft forks to be prevented.<br></div><div><= +br></div><div>1.=C2=A0 Anyone-can-spend<br></div><div><br></div><div>There = +are a very large number of anyone-can-spend scripts, and it would be very i= +mpractical to ban them all.<br></div><div><br></div><div>For example, the b= +elow output script is anyone-can-spend<br></div><div><br></div><div>=C2=A0&= +lt;random number> OP_TRUE<br></div><div><br></div><div>So is the below:<= +br></div><div><br></div><div>=C2=A0 OP_SIZE <random small number> OP_= +EQUAL<br></div><div><br></div><div>Or:<br></div><div><br></div><div>=C2=A0 = +OP_1ADD <random number> OP_EQUAL<br></div><div><br></div><div>Or:<br>= +</div><div><br></div><div>=C2=A0 OP_BOOLAND<br></div><div><br></div><div>Or= +:<br></div><div><br></div><div>=C2=A0 OP_BOOLOR<br></div><div><br></div><di= +v>And so on.<br></div><div><br></div><div>So no, it is not practically poss= +ible to ban anyone-can-spend outputs, as there are too many potential scrip= +tPubKey that anyone can spend.<br></div><div><br></div><div>It is even poss= +ible to have an output that requires a proof-of-work, like so:<br></div><di= +v><br></div><div>=C2=A0OP_HASH256 <difficulty target> OP_LESSTHAN<br>= +</div><div><br></div><div>All the above outputs are disallowed from propaga= +tion by IsStandard, but a miner can put them validly in a block, and IsStan= +dard is not consensus code and can be modified.<br></div><div><br></div><di= +v>2.=C2=A0 Soft fork =3D restrict<br></div><div><br></div><div>It is possib= +le (although unlikely) for a majority of miners to run soft forking code wh= +ich the rest of us are not privy to.<br></div><div><br></div><div>For examp= +le, for all we know, miners are already blacklisting spends on Satoshi'= +s coins.=C2=A0 We would not be able to detect this at all, since no transac= +tion that spends Satoshi's coins have been broadcast, ever.=C2=A0 It is= + thus indistinguishable from a world where Satoshi lost his private keys.= +=C2=A0 Of course, the world where Satoshi never spent his coins and miners = +are blacklisting Satoshi's coins, is more complex than the world where = +Satoshi never spent his coins, so it is more likely that miners are not bla= +cklisting.<br></div><div><br></div><div>But the principle is there.=C2=A0 W= +e may already be in a softfork whose rules we do not know, and it just so h= +appens that all our transactions today do not violate those rules.=C2=A0 It= + is impossible for us to know this, but it is very unlikely.<br></div><div>= +<br></div><div>Soft forks apply further restrictions on Bitcoin.=C2=A0 Hard= + forks do not.=C2=A0 Thus, if everyone else is entering a soft fork and we = +are oblivious, we do not even know about it.=C2=A0 Whereas, if everyone els= +e is entering a hard fork, we will immediately see (and reject) invalid tra= +nsactions and blocks.<br></div><div><br></div><div>Thus the only way to pre= +vent soft fork is to hard fork against the new soft fork, like Bcash did.<b= +r></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div><div><= +br></div><div>-------- Original Message --------<br></div><div>Subject: [bi= +tcoin-dev] hypothetical: Could soft-forks be prevented?<br></div><div>Local= + Time: September 13, 2017 5:50 PM<br></div><div>UTC Time: September 13, 201= +7 9:50 AM<br></div><div>From: <a href=3D"mailto:bitcoin-dev@lists.linuxfoun= +dation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a= +><br></div><div>To: Bitcoin Protocol Discussion <<a href=3D"mailto:bitco= +in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>= +linuxfoundation.org</a>><br></div><div><br></div><div>Hi, I am intereste= +d in the possibility of a cryptocurrency software<br></div><div>(future bit= +coin or a future altcoin) that strives to have immutable<br></div><div>cons= +ensus rules.<br></div><div><br></div><div>The goal of such a cryptocurrency= + would not be to have the latest and<br></div><div>greatest tech, but rathe= +r to be a long-term store of value and to offer<br></div><div>investors gre= +at certainty and predictability... something that markets<br></div><div>ten= +d to like. And of course, zero consensus rule changes also means<br></div>= +<div>less chance of new bugs and attack surface remains the same, which is<= +br></div><div>good for security.<br></div><div><br></div><div>Of course, ha= +rd-forks are always possible. But that is a clear split<br></div><div>and = +something that people must opt into. Each party has to make a<br></div><di= +v>choice, and inertia is on the side of the status quo. Whereas<br></div><= +div>soft-forks sort of drag people along with them, even those who oppose<b= +r></div><div>the changes and never upgrade. In my view, that is problemati= +c,<br></div><div>especially for a coin with permanent consensus rule immuta= +bility as a<br></div><div>goal/ethic.<br></div><div><br></div><div>As I und= +erstand it, bitcoin soft-forks always rely on anyone-can-spend<br></div><di= +v>transactions. If those were removed, would it effectively prevent<br></d= +iv><div>soft-forks, or are there other possible mechanisms? How important = +are<br></div><div>any-one-can spend tx for other uses?<br></div><div><br></= +div><div>More generally, do you think it is possible to programmatically<br= +></div><div>avoid/ban soft-forks, and if so, how would you go about it?<br>= +</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br>= +</div><div>______________________________<wbr>_________________<br></div><d= +iv>bitcoin-dev mailing list<br></div><div><a href=3D"mailto:bitcoin-dev@lis= +ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfound= +ation.org</a><br></div><div><a href=3D"https://lists.linuxfoundation.org/ma= +ilman/listinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundation= +.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br></div><br>______________= +________________<wbr>_________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +<wbr>linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= +/mailman/listinfo/bitcoin-<wbr>dev</a><br> +<br></blockquote></div></div> + +--001a113ef3ba091614055936d176-- + |