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 B366DB62 for ; Mon, 22 May 2017 15:30:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5F2F91A8 for ; Mon, 22 May 2017 15:30:49 +0000 (UTC) Received: by mail-lf0-f41.google.com with SMTP id a5so19810767lfh.2 for ; Mon, 22 May 2017 08:30:49 -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 :cc; bh=iovvb3qJYYvf7CIk3SZNEsrOxyKEOpyesnmLMoWJ7UQ=; b=Nh5R2gNvdGnPxAWeRHV42LKOgtaSw8vHaye70hTjLXWx6a2ASD09zTTS3eWDMJ0UG9 y+t25xB9DHNZs3hTTy+Wkip9Rbm/1FFJMXfemgyoU5/N+MzZoOR5apU7KG3a8wNFoZCW SdudTqm1p1zXKuOzUvb+j50RXmpyr/3RQmOOWYHKDadxtj69gNCrGesllgOQgvTElnwf hf23Q0mJi04Rp2T/fguwLZgYv16vLI7uFYC6wr1JUnrU4zvsmDewCmihhLXMyzmlunZy xIB+4e2YMmlV9vdnkGS6yLHlkMz4hZ0j6B+09ZQG9YJmpIZR16HaJRfC2V/dvLDkxm26 L8Kg== 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=iovvb3qJYYvf7CIk3SZNEsrOxyKEOpyesnmLMoWJ7UQ=; b=jjUGEk78LT85mpZc+AInYo4gBHBJjppBSNrNdCavFtEbI2SxgPjbGWoJuLpPQbq0JB K60QDC/2tl1NRD10MIqX/stbfIt7/pxvUlPqjkW3Sl0BzI+rU4Mw7GF3BzcqeflUAem4 jXTz348V1cVhRRILF/h2uufgBm4C/tyNqjGxCIVTAydoIT/oW+U2E75nNMgkhEXJgjPM bky2eJP9qRZ87Xc1+DjLaZE2R5WOvukYji/eHPhmF4As6/m/6XEjYR4WtI2h9ZhyOY57 NTAipIoZpoQ875H1tf1+pF3nEzA7WqMWzw3T2f8ManLxAc+LKycjHizCfIj7zQ/1bZRl UjTQ== X-Gm-Message-State: AODbwcBdnspsDBDBwC9C5hPLBhK8yBpvdtsTj8lrkeTZ3s522cDecYqE wXWjO+WTlZ449RK4tSg0d5zQl2vR4w== X-Received: by 10.46.20.14 with SMTP id u14mr6874965ljd.101.1495467047548; Mon, 22 May 2017 08:30:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.17.222 with HTTP; Mon, 22 May 2017 08:30:46 -0700 (PDT) Received: by 10.25.17.222 with HTTP; Mon, 22 May 2017 08:30:46 -0700 (PDT) In-Reply-To: <20170522133335.GA17194@fedora-23-dvm> References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com> <20170522133335.GA17194@fedora-23-dvm> From: Paul Sztorc Date: Mon, 22 May 2017 17:30:46 +0200 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary="f403045fbe8c247a5405501e8ea6" X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Drivechain -- Request for Discussion 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, 22 May 2017 15:30:50 -0000 --f403045fbe8c247a5405501e8ea6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Charlie, I'll be mostly in the tech track, of course. And I've already planned to meet RSK guys after their event tomorrow. Ryan, the more review the better. We aren't in any direct rush, other than the natural desire to have cool things as early as possible. Peter, responses below: On May 22, 2017 9:33 AM, "Peter Todd" wrote: On Mon, May 22, 2017 at 02:17:07AM -0400, Paul Sztorc via bitcoin-dev wrote= : > This work includes the relatively new concept of "Blind Merged Mining" > [2] which I developed in January to allow SHA256^2 miners to merge-mine > these "drivechains", even if these miners aren't running the actual > sidechain software. The goal is to prevent sidechains from affecting the > levelness of the mining "playing field". BMM is conceptually similar to > ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not > required for drivechain, but it would address some of the last remaining > concerns. Thanks for the credit, although I think the security properties of what you're proposing are very different - and much weaker - than what I proposed in Zookeyv. As you state in [2] "if miners never validate sidechains at all, whoever bids the most for the chain (on a continuous basis), can spam a 3-month long stream of invalid headers, and then withdraw all of the coins deposited to the sidechain." and "Since the mining is blind, and the sidechain-withdrawal security-level is SPV, miners who remain blind forever have no way of telling who =E2=80=9Cshould=E2=80=9D really get the funds." Finally, you suggest that in this event, miners *do* have to upgrade to a full node, an expensive and time-consuming operation (and one that may be impossible for some miners if necessary data isn't available). Surprisingly, this requirement (or, more precisely, this incentive) does not effect miners relative to each other. The incentive to upgrade is only for the purpose of preventing a "theft" -- defined as: an improper withdrawal from a sidechain. It is not about miner revenues or the ability to mine generally (or conduct BMM specifically). The costs of such a theft (decrease in market price, decrease in future transaction fee levels) would be shared collectively by all future miners. Therefore, it would have no effect on miners relative to each other. Moreover, miners have other recourse if they are unable to run the node. They can adopt a policy of simply rejecting ("downvoting") any withdrawals that they don't understand. This would pause the withdraw process until enough miners understand enough of what is going on to proceed with it. Finally, the point in dispute is a single, infrequent, true/false question. So miners may resort to semi-trusted methods to supplement their decision. In other words, they can just ask people they trust, if the withdrawal is correct or not. It is up to users to decide if they are comfortable with these risks, if/when they decide to deposit to a sidechain. It's unclear to me what the incentive is for miners to do any of this. Coul= d you explain in more detail what that incentive is? It is a matter of comparing the costs and benefits. Ignoring theft, the costs are near-zero, and the benefits are >0. Specifically, they are: a higher BTC price and greater transaction fees. Theft is discouraged by attempting to tie a theft to a loss of confidence in the miners, as described in the spec/website. In general the incentives are very similar to those of Bitcoin itself. Paul > [2] http://www.truthcoin.info/blog/blind-merged-mining/ > [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log -- https://petertodd.org 'peter'[:-1]@petertodd.org --f403045fbe8c247a5405501e8ea6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Charlie, I'll be mostly in the tech track, of co= urse. And I've already planned to meet RSK guys after their event tomor= row.

Ryan, the more revi= ew the better. We aren't in any direct rush, other than the natural des= ire to have cool things as early as possible.

Peter, responses below:

On May 22, 2017 9:33 AM, "Peter Todd" <pete@petertodd.org> wrote:
On Mon, M= ay 22, 2017 at 02:17:07AM -0400, Paul Sztorc via bitcoin-dev wrote:
> This work includes the relatively new concept of "Blind Merged Mi= ning"
> [2] which I developed in January to allow SHA256^2 miners to merge-min= e
> these "drivechains", even if these miners aren't running= the actual
> sidechain software. The goal is to prevent sidechains from affecting t= he
> levelness of the mining "playing field". BMM is conceptually= similar to
> ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
> required for drivechain, but it would address some of the last remaini= ng
> concerns.

Thanks for the credit, although I think the security properties of wh= at you're
proposing are very different - and much weaker - than what I proposed in Zookeyv.

As you state in [2] "if miners never validate sidechains at all, whoev= er bids
the most for the chain (on a continuous basis), can spam a 3-month long str= eam
of invalid headers, and then withdraw all of the coins deposited to the
sidechain." and "Since the mining is blind, and the sidechain-wit= hdrawal
security-level is SPV, miners who remain blind forever have no way of telli= ng
who =E2=80=9Cshould=E2=80=9D really get the funds."

Finally, you suggest that in this event, miners *do* have to upgrade to a f= ull
node, an expensive and time-consuming operation (and one that may be imposs= ible
for some miners if necessary data isn't available).

Surprisingly, = this requirement (or, more precisely, this incentive) does not effect miner= s relative to each other. The incentive to upgrade is only for the purpose = of preventing a "theft" -- defined as: an improper withdrawal fro= m a sidechain. It is not about miner revenues or the ability to mine genera= lly (or conduct BMM specifically). The costs of such a theft (decrease in m= arket price, decrease in future transaction fee levels) would be shared col= lectively by all future miners. Therefore, it would have no effect on miner= s relative to each other.

Moreover, miners have other recourse if they are unable to run the node. = They can adopt a policy of simply rejecting ("downvoting") any wi= thdrawals that they don't understand. This would pause the withdraw pro= cess until enough miners understand enough of what is going on to proceed w= ith it.=C2=A0

Finally, t= he point in dispute is a single, infrequent, true/false question. So miners= may resort to semi-trusted methods to supplement their decision. In other = words, they can just ask people they trust, if the withdrawal is correct or= not. It is up to users to decide if they are comfortable with these risks,= if/when they decide to deposit to a sidechain.

It's unclear to me what the incentive is for miners to do any of this. = Could
you explain in more detail what that incentive is?

It is a matter of c= omparing the costs and benefits. Ignoring theft, the costs are near-zero, a= nd the benefits are >0. Specifically, they are: a higher BTC price and g= reater transaction fees. Theft is discouraged by attempting to tie a theft = to a loss of confidence in the miners, as described in the spec/website.
In general the incentives are very similar to those of= Bitcoin itself.

--f403045fbe8c247a5405501e8ea6--