From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A007E97A for ; 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 ; Fri, 15 Sep 2017 09:14:14 +0000 (UTC) Received: by mail-qt0-f178.google.com with SMTP id i13so1583269qtc.11 for ; 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: References: <9e212eae-08d5-d083-80d9-a8e29679fcdc@osc.co.cr> From: Adam Back Date: Fri, 15 Sep 2017 10:14:13 +0100 Message-ID: To: Bitcoin Dev , ZmnSCPxj 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > > OP_TRUE > > So is the below: > > OP_SIZE OP_EQUAL > > Or: > > OP_1ADD 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 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 > > 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
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.

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.

Adam

On Sep 15, 2017 08:12, "ZmnSCPxj via bitcoin-dev" <bitcoin-dev@lists.linuxf= oundation.org> wrote:
Good morning Dan,

My understandi= ng is that it is impossible for soft forks to be prevented.
<= br>
1.=C2=A0 Anyone-can-spend

There = are a very large number of anyone-can-spend scripts, and it would be very i= mpractical to ban them all.

For example, the b= elow output script is anyone-can-spend

=C2=A0&= lt;random number> OP_TRUE

So is the below:<= br>

=C2=A0 OP_SIZE <random small number> OP_= EQUAL

Or:

=C2=A0 = OP_1ADD <random number> OP_EQUAL

Or:
=

=C2=A0 OP_BOOLAND

Or= :

=C2=A0 OP_BOOLOR

And so on.

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.

It is even poss= ible to have an output that requires a proof-of-work, like so:

=C2=A0OP_HASH256 <difficulty target> OP_LESSTHAN
=

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.

2.=C2=A0 Soft fork =3D restrict

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.

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.

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

Thus the only way to pre= vent soft fork is to hard fork against the new soft fork, like Bcash did.

Regards,
ZmnSCPxj
<= br>
-------- Original Message --------
Subject: [bi= tcoin-dev] hypothetical: Could soft-forks be prevented?
Local= Time: September 13, 2017 5:50 PM
UTC Time: September 13, 201= 7 9:50 AM

Hi, I am intereste= d in the possibility of a cryptocurrency software
(future bit= coin or a future altcoin) that strives to have immutable
cons= ensus rules.

The goal of such a cryptocurrency= would not be to have the latest and
greatest tech, but rathe= r to be a long-term store of value and to offer
investors gre= at certainty and predictability... something that markets
ten= d to like. And of course, zero consensus rule changes also means
=
less chance of new bugs and attack surface remains the same, which is<= br>
good for security.

Of course, ha= rd-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
<= div>soft-forks sort of drag people along with them, even those who oppose
the changes and never upgrade. In my view, that is problemati= c,
especially for a coin with permanent consensus rule immuta= bility as a
goal/ethic.

As I und= erstand 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 mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--001a113ef3ba091614055936d176--