path: root/d2/4fd9fd2b8eb746ba66f2d778098519ed03a38e

Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6CB829EE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 15 Sep 2017 11:48:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f174.google.com (mail-io0-f174.google.com
	[209.85.223.174])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9B3AAA1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 15 Sep 2017 11:48:13 +0000 (UTC)
Received: by mail-io0-f174.google.com with SMTP id m103so7636942iod.13
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 15 Sep 2017 04:48:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=KWJ7XV37mmqX2/5YpyjAhyn2p7JEE5t8UlcFdbH3pug=;
	b=G33QcXAXXn5uLCRw+VNee+eCnWzwJfPs2FxUq/Lm7j+YgJdefanDDsQW1ygrS1w7Mv
	VOwLdYMI4BIfqT0FeADS77eCX4jxqe5GqNvaZoMUujMZ7McWMMfJpXubkEOCrZb5v3zr
	7Ie6teIDEyTZBWBQozDwXgfPM/gY1ZlUh8mPO4zkLV2lm7sfnovHmFwB8HFhSetSCeCP
	knTxepfpEYzDphj1gAmjOvCEfnLqkFsaKgSu1ibX+4X3+1N7ZCr7BD4IJnrPiC0hFpxi
	cOJNcA5ZmQ5DyyVYmb5IELNsuAdGMNBexrhgCfutP+ipZNQz51r28rcCHjPpP3UKBiDG
	cMkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=KWJ7XV37mmqX2/5YpyjAhyn2p7JEE5t8UlcFdbH3pug=;
	b=dKPdLF1m7TetansX39FLpcyKRoZBEeBcF+CgWqSAhnAPxrGhb+Lv3Iy8yN6xEtxh2o
	KGffSdwj4Yy3bcriCdm1qUepUouNmFm8BbuKDNS9UP+VPbh8oLkECh+53b+cYZ95M1AR
	0tLAM0UgYwknH3jrAopUn/EDe70f15nMVHu1tDWMA3VONYVW77dL5mqmgayuG4SVk5fN
	tlM2VcVqa2QPTzyVNOaQYZOKzapBk0fTWu4hn1xCd3ZvcnFDi4+3ipO8D6u9yhN4C2KX
	84bvCIWGfZQqklG6eMLN5NJM8v69qOjRiTn6zvhsc7K6S85q1GiMTYaEqFGdpLQtvAWz
	edmg==
X-Gm-Message-State: AHPjjUiT77oQMI7xHFBA5mshbXz8E3qcx0C1yYPLkB/nYGqrChw4Kopz
	h9/o4IYdsc/MT97BwMdSdreTgRThubpgiAr8eCgPYw==
X-Google-Smtp-Source: AOwi7QAhuItf5QLh8JfQv7ecH5jtlccC/ipDJJhgqgJAUqdmbHFrM8tQRu/15bVQ711R3QWiZPeFHT3gPpseHYeWW30=
X-Received: by 10.202.179.137 with SMTP id c131mr16069200oif.175.1505476092728;
	Fri, 15 Sep 2017 04:48:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.155.136 with HTTP; Fri, 15 Sep 2017 04:47:32 -0700 (PDT)
In-Reply-To: <CALqxMTFEA2X0GJwF8rO=8twsgW=brrzScpDD=owiK9otocdjoA@mail.gmail.com>
References: <9e212eae-08d5-d083-80d9-a8e29679fcdc@osc.co.cr>
	<SU02clg--S4TtIK4TZIytgdnHE8SzXBwSEb_FN5edtPAaojLwCEd6OTNkBUrDiH1FwHPuD4D5yByE7r4Fz_-CVzzU9KK0xvmDGlWNxTp3aU=@protonmail.com>
	<CALqxMTFEA2X0GJwF8rO=8twsgW=brrzScpDD=owiK9otocdjoA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Fri, 15 Sep 2017 12:47:32 +0100
Message-ID: <CAE-z3OWJo07mpsyZEqfBV_T55jbB+2Ur0JeO2hSqOb2g_19F4Q@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a113ce08cb999d4055938f75a"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,
	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 11:48:14 -0000

--001a113ce08cb999d4055938f75a
Content-Type: text/plain; charset="UTF-8"

On Fri, Sep 15, 2017 at 10:14 AM, Adam Back via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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.
>

It depends on what software that the general user-base is using (especially
exchanges).  If a majority of miners have deployed a hidden soft fork, then
the soft fork will only last as long as they can maintain their majority.

If they drop below 50%, then the majority of miners will eventually make
and then build on a block that is invalid according to their hidden soft
fork rules.

If the userbase doesn't support a censorship soft fork, then it will only
last as long as a majority of miners support it.  Once the cartel loses its
majority, there is a strong incentive for members to disable their soft
fork rule.  Any that don't will end up mining a lower POW, but valid, chain.

Users updating their nodes to enforce the soft fork is what makes the soft
fork irreversible (without a hard fork).


> A censorship soft-fork is harder, that's a standard hard-fork to bypass
> with current fungibility mechanisms.
>

It's only a hard fork to reverse if the community is enforcing the soft
fork.  Forking off a minority of miners doesn't make it a hard fork.


>
> 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
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--001a113ce08cb999d4055938f75a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Sep 15, 2017 at 10:14 AM, Adam Back via bitcoin-dev <span dir=3D"ltr">&=
lt;<a target=3D"_blank" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquo=
te style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex" class=3D"gmail_quote"><div dir=3D"auto">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 f=
irst by opt-in adoption. </div></blockquote><div><br></div><div>It depends =
on what software that the general user-base is using (especially exchanges)=
.=C2=A0 If a majority of miners have deployed a hidden soft fork, then the =
soft fork will only last as long as they can maintain their majority.<br><b=
r></div><div>If they drop below 50%, then the majority of miners will event=
ually make and then build on a block that is invalid according to their hid=
den soft fork rules.<br><br></div><div></div><div>If the userbase doesn&#39=
;t support a censorship soft fork, then it will only last as long as a majo=
rity of miners support it.=C2=A0 Once the cartel loses its majority, there =
is a strong incentive for members to disable their soft fork rule.=C2=A0 An=
y that don&#39;t will end up mining a lower POW, but valid, chain.<br></div=
><div><br>Users updating their nodes to enforce the soft fork is what makes=
 the soft fork irreversible (without a hard fork).<br>=C2=A0</div><blockquo=
te style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex" class=3D"gmail_quote"><div dir=3D"auto">A censorship sof=
t-fork is harder, that&#39;s a standard hard-fork to bypass with current fu=
ngibility mechanisms.</div></blockquote><div><br></div><div>It&#39;s only a=
 hard fork to reverse if the community is enforcing the soft fork.=C2=A0 Fo=
rking off a minority of miners doesn&#39;t make it a hard fork.<br></div><d=
iv>=C2=A0</div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><div dir=
=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">Adam</div></div><di=
v class=3D"gmail-HOEnZb"><div class=3D"gmail-h5"><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Sep 15, 2017 08:12, &quot;ZmnSCPxj via b=
itcoin-dev&quot; &lt;<a target=3D"_blank" href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt; wro=
te:<br type=3D"attribution"><blockquote style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quot=
e"><div>Good morning Dan,<br></div><div><br></div><div>My understanding is =
that it is impossible for soft forks to be prevented.<br></div><div><br></d=
iv><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 impract=
ical to ban them all.<br></div><div><br></div><div>For example, the below o=
utput script is anyone-can-spend<br></div><div><br></div><div>=C2=A0&lt;ran=
dom number&gt; OP_TRUE<br></div><div><br></div><div>So is the below:<br></d=
iv><div><br></div><div>=C2=A0 OP_SIZE &lt;random small number&gt; OP_EQUAL<=
br></div><div><br></div><div>Or:<br></div><div><br></div><div>=C2=A0 OP_1AD=
D &lt;random number&gt; 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><div>And =
so on.<br></div><div><br></div><div>So no, it is not practically possible t=
o ban anyone-can-spend outputs, as there are too many potential scriptPubKe=
y that anyone can spend.<br></div><div><br></div><div>It is even possible t=
o have an output that requires a proof-of-work, like so:<br></div><div><br>=
</div><div>=C2=A0OP_HASH256 &lt;difficulty target&gt; OP_LESSTHAN<br></div>=
<div><br></div><div>All the above outputs are disallowed from propagation b=
y IsStandard, but a miner can put them validly in a block, and IsStandard i=
s not consensus code and can be modified.<br></div><div><br></div><div>2.=
=C2=A0 Soft fork =3D restrict<br></div><div><br></div><div>It is possible (=
although unlikely) for a majority of miners to run soft forking code which =
the rest of us are not privy to.<br></div><div><br></div><div>For example, =
for all we know, miners are already blacklisting spends on Satoshi&#39;s co=
ins.=C2=A0 We would not be able to detect this at all, since no transaction=
 that spends Satoshi&#39;s coins have been broadcast, ever.=C2=A0 It is thu=
s 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 bl=
acklisting Satoshi&#39;s coins, is more complex than the world where Satosh=
i never spent his coins, so it is more likely that miners are not blacklist=
ing.<br></div><div><br></div><div>But the principle is there.=C2=A0 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.=C2=A0 It is im=
possible 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 ob=
livious, we do not even know about it.=C2=A0 Whereas, if everyone else is e=
ntering a hard fork, we will immediately see (and reject) invalid transacti=
ons and blocks.<br></div><div><br></div><div>Thus the only way to prevent s=
oft fork is to hard fork against the new soft fork, like Bcash did.<br></di=
v><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div><div><br></d=
iv><div>-------- Original Message --------<br></div><div>Subject: [bitcoin-=
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, 2017 9:50=
 AM<br></div><div>From: <a target=3D"_blank" href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br><=
/div><div>To: Bitcoin Protocol Discussion &lt;<a target=3D"_blank" href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfounda=
<wbr>tion.org</a>&gt;<br></div><div><br></div><div>Hi, I am interested in t=
he possibility of a cryptocurrency software<br></div><div>(future bitcoin o=
r a future altcoin) that strives to have immutable<br></div><div>consensus =
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 rather to b=
e a long-term store of value and to offer<br></div><div>investors great cer=
tainty and predictability... something that markets<br></div><div>tend to l=
ike.  And of course, zero consensus rule changes also means<br></div><div>l=
ess chance of new bugs and attack surface remains the same, which is<br></d=
iv><div>good for security.<br></div><div><br></div><div>Of course, hard-for=
ks are always possible.  But that is a clear split<br></div><div>and someth=
ing that people must opt into.  Each party has to make a<br></div><div>choi=
ce, and inertia is on the side of the status quo.  Whereas<br></div><div>so=
ft-forks sort of drag people along with them, even those who oppose<br></di=
v><div>the changes and never upgrade.  In my view, that is problematic,<br>=
</div><div>especially for a coin with permanent consensus rule immutability=
 as a<br></div><div>goal/ethic.<br></div><div><br></div><div>As I understan=
d it, bitcoin soft-forks always rely on anyone-can-spend<br></div><div>tran=
sactions.  If those were removed, would it effectively prevent<br></div><di=
v>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><d=
iv>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><div>bit=
coin-dev mailing list<br></div><div><a target=3D"_blank" href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundat<wbr>ion.=
org</a><br></div><div><a target=3D"_blank" href=3D"https://lists.linuxfound=
ation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.<wbr>=
org/mailman/listinfo/bitcoin-d<wbr>ev</a><br></div><br>____________________=
__________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a target=3D"_blank" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a target=3D"_blank" rel=3D"noreferrer" href=3D"https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br></blockquote></div></div>
</div></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 target=3D"_blank" rel=3D"noreferrer" href=3D"https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div></div>

--001a113ce08cb999d4055938f75a--