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 E3C439BA for ; Mon, 6 Nov 2017 20:55:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f65.google.com (mail-pg0-f65.google.com [74.125.83.65]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4F3CA4F5 for ; Mon, 6 Nov 2017 20:55:32 +0000 (UTC) Received: by mail-pg0-f65.google.com with SMTP id s2so9176798pge.10 for ; Mon, 06 Nov 2017 12:55:32 -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=Md1aSjcGDTSmw8dMD/tKq8974lHrfnP6LS+WozmbZfk=; b=fo47FcZmJRybKk/7cOYLjefRWvBBAobD9cNmXMlzfSsQTt/oQ3Kk3PQIDtbE8eLxQX DSH66kQ+w367iXCjz1/IVcSvV5tSS8Js3z+TCEZJdQofqcaSmPA05FbuzL6p/eaASYn9 Jeroy+4qjyj+mUgOqouAljBXjtisF7/VZqaHbOTxIdUOsJ27nYhpafBtOs1H622A/osw Iw0rulNTvJtwlGT0Lgavc412I6p+Y1AffXZHpJIf/Nqx7sDZR4C8LyaNEpBZHGLiETx8 AkgKJLANgEEg+MGOex2ekGfj0U+j5pniZ1TG742kMyuVqCeyb2vTyGcyQeuPRxwuV0ut M/MQ== 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=Md1aSjcGDTSmw8dMD/tKq8974lHrfnP6LS+WozmbZfk=; b=XjFhxmchJxV++nbntS0Xe7sAxP9LJTC5DtF++0j2bwuGI8CA/AhF5uuMQ+6nJPdw0d NuRaKipyZvo5aOr36pfI6kzkLXNOGd7mVyz5uYhhoL5s4IHDpnLATAJA1zVMi/TnbALW JIP/+VV8yszTx87+/G+VkENcsRvYbj26f+TQkgDDiL4VB6sKZESPnZqM/2wNZZqzp8cr 5Us1gKrL/iigwPsCuQskhu6V2y0MVeGM/eFNEZ8RfAkbd79m1tJDxCJi+w8G+yY+OdOL 0qo5VXOtQXIbzai1rLfZN4T1SgzPpxOr6TEvWaF+2ux+xxzW2k8weSHAAzmr9V6VNuPt FgEw== X-Gm-Message-State: AMCzsaXcPvUXZkQdWCNFz6Y7B/KIuIKrJcflIj5EeBSiPG3pkHkM7HLh f5hiITQmB4YnK8JfKScuDq7jMRqoz6E= X-Google-Smtp-Source: ABhQp+RXuGbtDiF3/+Sri0atsTnaqq3R0b1tWoHdGDzeZ8JkyBXun15CMWW1zOoDR/IpuD0UZCWkgA== X-Received: by 10.84.173.195 with SMTP id p61mr16088806plb.138.1510001731892; Mon, 06 Nov 2017 12:55:31 -0800 (PST) Received: from ?IPv6:2600:380:8554:5445:59dc:e765:ef93:cb5e? ([2600:380:8554:5445:59dc:e765:ef93:cb5e]) by smtp.gmail.com with ESMTPSA id a19sm25648417pfh.30.2017.11.06.12.55.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Nov 2017 12:55:30 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-1A38FFB1-0409-4D5B-96FD-0BF06AE27860 Mime-Version: 1.0 (1.0) From: Eric Voskuil X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Mon, 6 Nov 2017 12:55:29 -0800 Content-Transfer-Encoding: 7bit Message-Id: <61253DDB-A045-4346-A39C-F5C4E07396C7@voskuil.org> References: <20171106195000.GA7245@fedora-23-dvm> To: Paul Sztorc , Bitcoin Protocol Discussion X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MIME_QP_LONG_LINE,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 X-Mailman-Approved-At: Mon, 06 Nov 2017 23:54:11 +0000 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: Mon, 06 Nov 2017 20:55:33 -0000 --Apple-Mail-1A38FFB1-0409-4D5B-96FD-0BF06AE27860 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable If a block that would be discarded under previous rules becomes accepted aft= er a rule addition, there is no reason to not simply call the new rule a har= d fork. IOW it's perfectly rational to consider a weaker block as "invalid" r= elative to the strong chain. As such I don't see any reason to qualify the t= erm, it's a hard fork. But Peter's observation (the specific behavior) is ul= timately what matters. e > 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 wrote= : >>=20 >> Some quick thoughts... >>=20 >> > Hi all, >> > >> > Feedback is welcome on the draft below. In particular, I want to see i= f >> > 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-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 cal= l it a >> "pseudo-soft-fork" >>=20 >> My reasoning being that after implementation, a chain with less total wor= k than >> 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-fo= rk, >> but it's security model is definitely different. >>=20 >> > ### 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. >>=20 >> Note how you're basically proposing for the block interval to be decrease= d, >> 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 w= rong >> > 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 >>=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-1A38FFB1-0409-4D5B-96FD-0BF06AE27860 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If a block that would be di= scarded under previous rules becomes accepted after a rule addition, there i= s no reason to not simply call the new rule a hard fork. IOW it's perfectly r= ational to consider a weaker block as "invalid" relative to the strong chain= . As such I don't see any reason to qualify the term, it's a hard fork. But P= eter's observation (the specific behavior) is ultimately what matters.
=

e

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

+1 to all of Peter Todd's comments

On Nov 6, 2017 1= 1:50 AM, "Peter Todd via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:<= br type=3D"attribution">
On Wed, Nov 01, 2017 at= 05:48:27AM +0000, Devrandom 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/b= tc-papers/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
bitcoin-dev@lists.<= wbr>linuxfoundation.org
https://lists.linuxfoundation.org/m= ailman/listinfo/bitcoin-dev

____________________= ___________________________
bitcoin-dev mailing list<= br>bitcoin-de= v@lists.linuxfoundation.org
https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-1A38FFB1-0409-4D5B-96FD-0BF06AE27860--