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 454CFA84 for ; Mon, 6 Nov 2017 20:30:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f67.google.com (mail-lf0-f67.google.com [209.85.215.67]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6C5251AD for ; Mon, 6 Nov 2017 20:30:32 +0000 (UTC) Received: by mail-lf0-f67.google.com with SMTP id 75so11969045lfx.1 for ; Mon, 06 Nov 2017 12:30:32 -0800 (PST) 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 :cc; bh=wHCB2ojTc1VsNXvFBYoljfMkmn4GoRM6UAl4RNiITNA=; b=Tw3ufg219zy6hlgzyH2OY35hlFf90WC9KIbDUe+BlhVMVLtnggPn/p1rWL/9q3N2LV 6f8mFertPBpO7BHuUlcerwj8jujkVerNPN31QGS+eMocwrxaobuU0kLGPPpFQtOxa+L3 8rDB0ndRdi5oqxF7OtUqSiOxc4pdq0JQZOO5InYBKfANxtktdAscAEGaiquun8iMf8hV +ajxscKeRz2pWFDWbGrQYbIt8ADMnuNQgI8tTKhj1UdB69pJ4ckWFlVs8W0x48BF1Ny0 SmPnJbp64hd9rKka6ZKjYQRa/ekFZKQqKl7AFCakTIJNldkQoUQu+hcyWkcsCaMNDlFb br4w== 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:cc; bh=wHCB2ojTc1VsNXvFBYoljfMkmn4GoRM6UAl4RNiITNA=; b=dew+iCHSB2H85RNVu77FUdCCJBFnguS3xlLwdRKWogh8cqqCETt8ULTMAQzCcuArK1 Ct1o50VqTv/6Cj/nHHoDmiI/zz3i5QUABm5RMlfNkxC8554WRx6lwVIlLltBz/+0uNOo rGhke4UMJM7FiVdK9ddI/3IeJdNNpCr3dB0Gq6NwR55Svda3IGA83y8PaNfQtMf5xnW+ H38GZEXlwI3+7V3+T9g/ucEYMFWnktHIxAdNV/1dqha4qRJY+0FBPi+IVP4ba99/84B4 j2qVDOPVzdmtMdEjc89YcJ42lHxIyN8YISgQQx1yPjkUI4k0ch7qwWpxb5dCFKxdyrTa 53Tg== X-Gm-Message-State: AJaThX7XGMPnX0eSbXDx5x68BrOkGPSZjeOz/Bnkfe9Db1/kIo/zNgPr JQoIK9yGH7Ato4ySGMR+CqTNbjcAlExuYDfxtdo= X-Google-Smtp-Source: ABhQp+R+JPTBwy11SoIsYFy2wKUxyixNs1o+kVyXoMXSOXsVAAJuhaZgMzJbiCP1I+OyMfjHDPdu6MnjzrJYa2F5NTY= X-Received: by 10.25.148.216 with SMTP id o85mr5671674lfk.190.1510000230650; Mon, 06 Nov 2017 12:30:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.15.160 with HTTP; Mon, 6 Nov 2017 12:30:30 -0800 (PST) Received: by 10.25.15.160 with HTTP; Mon, 6 Nov 2017 12:30:30 -0800 (PST) In-Reply-To: <20171106195000.GA7245@fedora-23-dvm> References: <20171106195000.GA7245@fedora-23-dvm> From: Paul Sztorc Date: Mon, 6 Nov 2017 15:30:30 -0500 Message-ID: To: Peter Todd , Bitcoin Dev Content-Type: multipart/alternative; boundary="001a114369025bd699055d565361" 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] 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:30:33 -0000 --001a114369025bd699055d565361 Content-Type: text/plain; charset="UTF-8" +1 to all of Peter Todd's comments On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 see if > > there is interest in further development of the idea and also interested > 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 > > First of all, I don't think you can really call this a soft-fork; I'd call > it a > "pseudo-soft-fork" > > My reasoning being that after implementation, a chain with less total work > 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-fork, > but it's security model is definitely different. > > > ### Aux POW intermediate block > > > > Auxiliary POW blocks are introduced between normal blocks - i.e. the > chain > > 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, > 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 > wrong > > 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.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a114369025bd699055d565361 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to all of Peter Todd's comments

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

Some quick thoughts...

> Hi all,
>
> Feedback is welcome on the draft below.=C2=A0 In particular, I want to= see if
> there is interest in further development of the idea and also interest= ed 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

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

My reasoning being that after implementation, a chain with less total work = than
the main chain - but more total SHA256^2 work than the main chain - might b= e
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 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 contai= n all
> transactions from the aux-POW block.

Note how you're basically proposing for the block interval to be decrea= sed,
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 = wrong
> chain in case of attack.=C2=A0 However,

Exactly! Not really a soft-fork.

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

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--001a114369025bd699055d565361--