Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6CB829EE for ; 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 ; Fri, 15 Sep 2017 11:48:13 +0000 (UTC) Received: by mail-io0-f174.google.com with SMTP id m103so7636942iod.13 for ; 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: References: <9e212eae-08d5-d083-80d9-a8e29679fcdc@osc.co.cr> From: Tier Nolan Date: Fri, 15 Sep 2017 12:47:32 +0100 Message-ID: To: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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 >> >> > _______________________________________________ > 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
On F= ri, Sep 15, 2017 at 10:14 AM, Adam Back via bitcoin-dev &= lt;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 f= irst by opt-in adoption.

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

If the userbase doesn'= ;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'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).
=C2=A0
A censorship sof= t-fork is harder, that's a standard hard-fork to bypass with current fu= ngibility mechanisms.

It'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't make it a hard fork.
=C2=A0

Adam

On Sep 15, 2017 08:12, "ZmnSCPxj via b= itcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wro= te:
Good morning Dan,

My understanding is = that it is impossible for soft forks to be prevented.

1.=C2=A0 Anyone-can-spend

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

For example, the below o= utput script is anyone-can-spend

=C2=A0<ran= dom number> OP_TRUE

So is the below:

=C2=A0 OP_SIZE <random small number> OP_EQUAL<= br>

Or:

=C2=A0 OP_1AD= D <random number> OP_EQUAL

Or:
=

=C2=A0 OP_BOOLAND

Or:
<= /div>

=C2=A0 OP_BOOLOR

And = so on.

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.

It is even possible t= o 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 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.

2.= =C2=A0 Soft fork =3D 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 co= ins.=C2=A0 We would not be able to detect this at all, since no transaction= that spends Satoshi'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'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.

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.

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.

Thus the only way to prevent s= oft 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
<= /div>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfounda= tion.org>

Hi, I am interested in t= he possibility of a cryptocurrency software
(future bitcoin o= r 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 b= e a long-term store of value and to offer
investors great cer= tainty and predictability... something that markets
tend to l= ike. And of course, zero consensus rule changes also means
l= ess chance of new bugs and attack surface remains the same, which is
good for security.

Of course, hard-for= ks are always possible. But that is a clear split
and someth= ing that people must opt into. Each party has to make a
choi= ce, and inertia is on the side of the status quo. Whereas
so= ft-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 understan= d it, bitcoin soft-forks always rely on anyone-can-spend
tran= sactions. 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?
=





=
_______________________________________________
bit= coin-dev mailing list

____________________= ___________________________
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--