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 03CAE927 for ; Sat, 11 Nov 2017 19:51:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f45.google.com (mail-pg0-f45.google.com [74.125.83.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CCD69196 for ; Sat, 11 Nov 2017 19:51:07 +0000 (UTC) Received: by mail-pg0-f45.google.com with SMTP id s75so9856916pgs.0 for ; Sat, 11 Nov 2017 11:51:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IlA4Fdhppu4wP8xMgeVxSpAI4R5JiUQJIWIbpPskGpc=; b=jrjr2wQnwuPqosOzTLiL0qbfDSL3dQd50jLOuBsTmW27B62xfErHhEJtRJWL51Shy2 ufjGUN/ypUSJwiIFwbXHxsU8xhbkSojymFPnLUjUY76Hem6910Gh08oPq+EJiXo2o04l AnL32msFfn1dVJpR1gtaeCXkkjpISNzzYulwKIOv5kjd/Ii8/wbiDqaQ8fbbQv04U8vE 901Sutzku3WW+mmABcSSBmLk07bjcsxdbJDuwvqOGeEJ5qMjnP3Nt1ARjOQYFOoeNirG 3OsglfKLDAHvy0YR/yk3ev8UTyovPWkxZxgMDIX1fqYUSfHJo75O+ksLjsAJd/V37p3N QJeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IlA4Fdhppu4wP8xMgeVxSpAI4R5JiUQJIWIbpPskGpc=; b=e4yos6w1SVdT+dogn91OWrrCfeK5SBAaFrZfUQ4aDQ3n+OFi//OjEysVzY6wVcA7v+ 3YG5lX7Z6QTeqcZQscvLTwaeD1QmMLvO+pr6Ufl3fZA3CYfjmk4694/x4biY3h/B4cbl FnhoBjuq7OjqxsK23UziAGwKR6uTiKFFPao5SiQpu5o8rp3g58cOb1w0pqMvzt7YsgyC 3ry7iUcOexjPp5N+yN/E7ancOXdrQHm86EYkAyAOMRNuKAPALrquE2SuAQBV8wXMErto dVNZi+vJMEv/xwAhtE/ar17py6JszhHw1DgZKwC/uYJLZZzP3TxS5fxOMV7GVYDKOA0b Hjlg== X-Gm-Message-State: AJaThX7irmAOdOlmTS6ngTFvTxJZlg6QeTFQa4eSLnpg3f1bmZrcNFoq worzt8d96UF8NNQO9LS66r4bxw== X-Google-Smtp-Source: AGs4zMaYEoeUPmUhv2GZlnfr7TWpPo1tHFmG+X/V+zjHCy8h0ZrrdcIQFWHZMHQEI/Pje8jrrVHpZw== X-Received: by 10.98.29.211 with SMTP id d202mr4632059pfd.49.1510429867296; Sat, 11 Nov 2017 11:51:07 -0800 (PST) Received: from ?IPv6:2600:380:7764:47f:49a3:91a1:6239:38d3? ([2600:380:7764:47f:49a3:91a1:6239:38d3]) by smtp.gmail.com with ESMTPSA id g7sm25551255pfj.13.2017.11.11.11.51.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Nov 2017 11:51:06 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-2FF6A11F-75CD-431C-A0FB-CDA13D688580 Mime-Version: 1.0 (1.0) From: Eric Voskuil X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Sat, 11 Nov 2017 11:51:04 -0800 Content-Transfer-Encoding: 7bit Message-Id: <795D69CA-1591-4B69-96EE-BAF14CAAD71B@voskuil.org> References: <20171106195000.GA7245@fedora-23-dvm> <61253DDB-A045-4346-A39C-F5C4E07396C7@voskuil.org> To: Devrandom X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 11 Nov 2017 19:53:02 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Introducing a POW through a soft-fork 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: Sat, 11 Nov 2017 19:51:09 -0000 --Apple-Mail-2FF6A11F-75CD-431C-A0FB-CDA13D688580 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Nov 6, 2017, at 20:38, Devrandom wrote: >=20 > A hard-fork is a situation where non-upgraded nodes reject a block mined a= nd relayed by upgraded nodes. As Peter pointed out, that is the case here. > This creates a fork that cannot heal regardless of what follows. That is not a condition of the hard fork concept. https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki Softfork A consensus fork wherein everything that was previously invalid remains inva= lid while blocks that would have previously considered valid become invalid.= A hashrate majority of miners can impose the new rules. They have some depl= oyment advantages like backward compatibility. Hardfork A consensus fork that makes previously invalid blocks valid. Hardforks requi= re all users to upgrade. The essential element of a hard fork is that the new rule may cause rejectio= n of blocks that are not rejected by old rules (thereby requiring that all u= sers adopt the new rule in order to avoid a split). The reason a hard fork i= s interesting is that it can create a chain split even if it is enforced by m= ajority hash power. That is not the case with a soft fork and it is not the case here. A split c= an occur. The fact that it is possible for the split to also eventually orph= an the old nodes does not make it a soft fork. A soft fork requires that a h= ash power majority can impose the rule. However, under the proposed new rule= the hash power majority (according to the new rule) cannot impose the rule o= n existing nodes. > This proposal is not a hard-fork, because the non-upgraded node *will heal= * if the attack has less than 1/2 of the original-POW power in the long term= . Nothing about this proposal implies an attack. =46rom the Motivation section= : Mitigate centralization pressures by introducing a POW that does not have ec= onomies of scale Introduce an intermediary confirmation point, reducing the impact of mining p= ower fluctuations > The cost of such an attack is the cost of a normal "51%" attack, multiplie= d by the fractional weight of the original POW (e.g. 0.75 or 0.5). >=20 > So rather than saying this is a hard-fork, I would say that this is a soft= -fork with reduced security for non-upgraded nodes. Presumably this preference exists because it implies the new rule would not c= ause a chain split, making it more acceptable to a risk-averse economy. This= is precisely why it should be described correctly. > I would also say that the reduction in security is proportional to the red= uction in weight of the original POW at the time of attack. >=20 > As mentioned before, the original-POW weight starts at 1.0 and is reduced o= ver a long period of time. I would set up the transition curve so that all n= odes upgrade by the time the weight is, say, 0.75. In reality, nodes protec= ting high economic value would upgrade early. In reality you have no way to know if/when people would adopt this rule. Wha= t matters in the proposal is that people who do adopt it are well aware of i= ts ability to split them from the existing economy. e >> On Mon, Nov 6, 2017 at 3:55 PM Eric Voskuil via bitcoin-dev wrote: >> If a block that would be discarded under previous rules becomes accepted a= fter a rule addition, there is no reason to not simply call the new rule a h= ard fork. IOW it's perfectly rational to consider a weaker block as "invalid= " relative to the strong chain. As such I don't see any reason to qualify th= e term, it's a hard fork. But Peter's observation (the specific behavior) is= ultimately what matters. >>=20 >> e >>=20 >>> On Nov 6, 2017, at 12:30, Paul Sztorc via bitcoin-dev wrote: >>>=20 >>> +1 to all of Peter Todd's comments >>>=20 >>>> On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" wrote: >>>> On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wro= te: >>>>=20 >>>> Some quick thoughts... >>>>=20 >>>> > Hi all, >>>> > >>>> > Feedback is welcome on the draft below. In particular, I want to see= if >>>> > there is interest in further development of the idea and also interes= ted in >>>> > any attack vectors or undesirable dynamics. >>>> > >>>> > (Formatted version available here: >>>> > https://github.com/devrandom/btc-papers/blob/master/aux-pow.md ) >>>> > >>>> > # Soft-fork Introduction of a New POW >>>>=20 >>>> First of all, I don't think you can really call this a soft-fork; I'd c= all it a >>>> "pseudo-soft-fork" >>>>=20 >>>> My reasoning being that after implementation, a chain with less total w= ork than >>>> the main chain - but more total SHA256^2 work than the main chain - mig= ht be >>>> followed by non-supporting clients. It's got some properties of a soft-= fork, >>>> but it's security model is definitely different. >>>>=20 >>>> > ### Aux POW intermediate block >>>> > >>>> > Auxiliary POW blocks are introduced between normal blocks - i.e. the c= hain >>>> > alternates between the two POWs. >>>> > Each aux-POW block points to the previous normal block and contains >>>> > transactions just like a normal block. >>>> > Each normal block points to the previous aux-POW block and must conta= in all >>>> > transactions from the aux-POW block. >>>>=20 >>>> Note how you're basically proposing for the block interval to be decrea= sed, >>>> which has security implications due to increased orphan rates. >>>>=20 >>>> > ### Heaviest chain rule change >>>> > >>>> > This is a semi-hard change, because non-upgraded nodes can get on the= wrong >>>> > chain in case of attack. However, >>>>=20 >>>> Exactly! Not really a soft-fork. >>>>=20 >>>> -- >>>> https://petertodd.org 'peter'[:-1]@petertodd.org >>>>=20 >>>> _______________________________________________ >>>> 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 --Apple-Mail-2FF6A11F-75CD-431C-A0FB-CDA13D688580 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= br>
On Nov 6, 2017, at 20:38, Devrandom <c1.bitcoin@niftybox.net> wrote:

A hard-fork is a situation wher= e non-upgraded nodes reject a block mined and relayed by upgraded nodes.

As Peter pointed out, that is the c= ase here.

This crea= tes a fork that cannot heal regardless of what follows.

That is not a condition of the hard fork concept.

Softfork
=
A c= onsensus fork wherein everything that was previously invalid remains invalid= while blocks that would have previously considered valid become invalid. A h= ashrate majority of miners can impose the new rules. They have some deployme= nt advantages like backward compatibility.
Hardfork
A consensus fork that makes previously inv= alid blocks valid. Hardforks require all users to upgrade.
<= /div>

The essential element of a hard fork is that the ne= w rule may cause rejection of blocks that are not rejected by old rules (the= reby requiring that all users adopt the new rule in order to avoid a split).= The reason a hard fork is interesting is that it can create a chain split e= ven if it is enforced by majority hash power.

That i= s not the case with a soft fork and it is not the case here. A split can occ= ur. The fact that it is possible for the split to also eventually orphan the= old nodes does not make it a soft fork. A soft fork requires that a hash po= wer majority can impose the rule. However, under the proposed new rule the h= ash power majority (according to the new rule) cannot impose the rule on exi= sting nodes.

T= his proposal is not a hard-fork, because the non-upgraded node *will heal* i= f the attack has less than 1/2 of the original-POW power in the long term.

Nothing about this proposal= implies an attack. =46rom the Motivation section:

=
  • Mitigate centralization pressures by i= ntroducing a POW that does not have economies of scale
  • Introduce an intermediary confirmation point, re= ducing the impact of mining power fluctuations
The cost of suc= h an attack is the cost of a normal "51%" attack, multiplied by the fraction= al weight of the original POW (e.g. 0.75 or 0.5).

So rather than saying this is a hard-fork, I would say that this is a sof= t-fork with reduced security for non-upgraded nodes.

Presumably this preference exists because it impl= ies the new rule would not cause a chain split, making it more acceptable to= a risk-averse economy. This is precisely why it should be described correct= ly.

I would a= lso say that the reduction in security is proportional to the reduction in w= eight of the original POW at the time of attack.

As mentioned before, the original-POW weight starts at 1.0 and is reduced o= ver a long period of time.  I would set up the transition curve so that= all nodes upgrade by the time the weight is, say, 0.75.  In reality, n= odes protecting high economic value would upgrade early.

In reality you have no way to know if/when pe= ople would adopt this rule. What matters in the proposal is that people who d= o adopt it are well aware of its ability to split them from the existing eco= nomy.

e

On= Mon, Nov 6, 2017 at 3:55 PM Eric Voskuil via bitcoin-dev <bitcoin-dev@lists.linuxfoundation= .org> wrote:
If a block that would be discarded under previous rules bec= omes accepted after a rule addition, there is no reason to not simply call t= he new rule a hard fork. IOW it's perfectly rational to consider a weaker bl= ock as "invalid" relative to the strong chain. As such I don't see any reaso= n to qualify the term, it's a hard fork. But Peter's observation (the specif= ic behavior) is ultimately what matters.
<= br>
e

On Nov 6, 2017, at 12:= 30, Paul Sztorc via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org= > wrote:

+1= to all of Peter Todd's comments

On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" &l= t;bitcoin-dev@lists.linuxfoundation.org> wrote:
On Wed, Nov 01, 2017 at 05:48:27AM +0000, De= vrandom via bitcoin-dev wrote:

Some quick thoughts...

> Hi all,
>
> Feedback is welcome on the draft below.  In particular, I want to s= ee if
> there is interest in further development of the idea and also intereste= d in
> any attack vectors or undesirable dynamics.
>
> (Formatted version available here:
> https://github.com/devrandom/btc-pa= pers/blob/master/aux-pow.md )
>
> # Soft-fork Introduction of a New POW

First of all, I don't think you can really call this a soft-fork; I'd call i= t a
"pseudo-soft-fork"

My reasoning being that after implementation, a chain with less total work t= han
the main chain - but more total SHA256^2 work than the main chain - might be=
followed by non-supporting clients. It's got some properties of a soft-fork,=
but it's security model is definitely different.

> ### Aux POW intermediate block
>
> Auxiliary POW blocks are introduced between normal blocks - i.e. the ch= ain
> alternates between the two POWs.
> Each aux-POW block points to the previous normal block and contains
= > transactions just like a normal block.
> Each normal block points to the previous aux-POW block and must contain= all
> transactions from the aux-POW block.

Note how you're basically proposing for the block interval to be decreased,<= br> which has security implications due to increased orphan rates.

> ### Heaviest chain rule change
>
> This is a semi-hard change, because non-upgraded nodes can get on the w= rong
> chain in case of attack.  However,

Exactly! Not really a soft-fork.

--
https= ://petertodd.org 'peter'[:-1]@petertodd.org

_______________________________________________
bitcoin-dev mailing list
b= itcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailma= n/listinfo/bitcoin-dev

____________________= ___________________________
bitcoin-dev mailing list<= br>bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___________________________________________= ____
bitcoin-dev mailing list
b= itcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailma= n/listinfo/bitcoin-dev
= --Apple-Mail-2FF6A11F-75CD-431C-A0FB-CDA13D688580--