path: root/67/ba5df1e12bd931934ecbfaeabc62917b2fe870

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&#39;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&#39;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, &quot;ZmnSCPxj via bitcoin-dev&quot; &lt;<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxf=
oundation.org</a>&gt; 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&gt; OP_TRUE<br></div><div><br></div><div>So is the below:<=
br></div><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_1ADD &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><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 &lt;difficulty target&gt; 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&#39;=
s coins.=C2=A0 We would not be able to detect this at all, since no transac=
tion that spends Satoshi&#39;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&#39;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 &lt;<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>=
linuxfoundation.org</a>&gt;<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--