Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 59AA43B09 for ; Mon, 21 Jan 2019 18:47:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4B474603 for ; Mon, 21 Jan 2019 18:47:26 +0000 (UTC) Received: by mail-qk1-f175.google.com with SMTP id o8so12796492qkk.11 for ; Mon, 21 Jan 2019 10:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pHkFRnWf5L9HiNJdSEhvLSv08JKUyh9DeNPWXRLlyss=; b=n2rrNpbuRIckiBz+AtQBjh5DO3mGQ6+BpYhUdBkXqFNPLZ+AtjYSUH5tiLyn/9vHOe ow2SDyJbQClj7yDF9veMFRU1LTS3VVgMXrHBHjQsexJ8ZVF2VCNQFrIizso2AKgasqpT SzTlf47ecTJIbSDuWWeWSZLxTKME64PqMnyHmp+EbgyOsIlE8U86Jg1z0LG28h401r+O +QgMa7slEhnJbU0DFbCAVaoEod2lxOvgEa4kntZkE7nJWKZvHaUIxPpWYyhMKvXDlPJh 6oSpUqkS09QPdVxU8QuoEukESESP5YCYUYrRm1suNcFTT61aYUzAsBaq51KUvvivbqkB JPBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pHkFRnWf5L9HiNJdSEhvLSv08JKUyh9DeNPWXRLlyss=; b=uhpJEuxYXOkav4DmSjqjpO1ZtL7gzHTwwTXmTE7VMmfM31vaPtZqTEEpoAx6N0FM8/ +A9qA6d+3Sk82a3QMiHdtZ922JsHInuPtqp/iRcHmZqB6EhFfim0oYp+jsen53zkcMxt kSkeFBkd7Tns8h7p0+yFHu7rZ6Sgzk98NIa5oO6R02/BF7EdU3ZC1Et7DGzkwqHYOfxK GkOWgeik5Fh0cFvv5VlhMOZZqXAziFaGabw+F1vbHQdTyh5GRVlOBcw3iKd8WVU4w56f cLONQ9gVCI19uMn7fJ4KMoilpyNV3sIUubCKaFm75slcy9uZRJ4jYKF72HCaXXAVtBzQ xyqw== X-Gm-Message-State: AJcUukdPWRpoUuZOlKYM/a4vCre6s2+yNSP+6ihy3BSo7TXXETCito1l 8ZHq11JHaM61pg3v2dA/eQrgJUXSuYpRNIZ4ntw= X-Google-Smtp-Source: ALg8bN7X123MKWa8urUJIODrgza/nUEnD/SGeSju65NUXJSRdF3ZlkhNEcHnVm/b3pbqwJfkq3Kf4YWxdHLdWLrAeVM= X-Received: by 2002:a37:d204:: with SMTP id f4mr25486289qkj.311.1548096445230; Mon, 21 Jan 2019 10:47:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Matt Bell Date: Mon, 21 Jan 2019 10:47:13 -0800 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="000000000000b23452057ffc4af7" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham 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, 21 Jan 2019 21:28:26 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains 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, 21 Jan 2019 18:47:27 -0000 --000000000000b23452057ffc4af7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ZmnSCPxj, I'm intrigued by this mechanism of using fixed R values to prevent multiple signatures, but how do we derive the R values in a way where they are unique for each blockheight but still can be used to create signatures or verify? Thanks, Matt On Sat, Jan 19, 2019 at 6:06 PM ZmnSCPxj wrote: > Good Morning Matt, > > It seems to me that double signing can be punished by requiring that R be > a trivial function on the blockheight of the block being signed on the > sidechain network. Then a validator who signs multiple versions of histor= y > at a particular blockheight reveals their privkey. Since the privkey also > protects their Bitcoin stake UTXO, they risk loss of their Bitcoin stake.= A > similar idea is used by Discrete Log Contracts to ensure Oracles do not > sign multiple values at a particular time. > > Regards, > ZmnSCPxj > > > Sent with ProtonMail Secure Email. > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original = Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 > On Saturday, January 19, 2019 1:35 PM, Matt Bell wrote= : > > > Hi ZmnSCPxj, > > > > Just to clarify, my design does not specify the source of voting power, > so it is agnostic to whatever system you want to derive stake or valdiato= r > set membership from. > > > > Your idea of timelocking Bitcoin is interesting, I am eager to find a > solution where holding Bitcoin is enough to get voting power. It's possib= le > there may be an issue with the fact that the Bitcoin is not slashable > (although their voting power is), meaning a validator who double-signs > cannot have their Bitcoin removed from them. However their UTXO can be > blacklisted which does make their attack costly since they lose out on th= e > time-value of their stake. > > > > Our current thinking for the source of stake is to pay out stake to > Bitcoin merged-miners although I'll definitely do some more thinking abou= t > timelocked Bitcoin as stake. > > > > On Fri, Jan 18, 2019, 5:42 PM ZmnSCPxj > > > > Good morning Matt, > > > > > > It seems to me much more interesting if the stakes used to weigh > voting power are UTXOs on the Bitcoin blockchain. > > > This idea is what I call "mainstake"; rather than a blockchain having > its own token that is self-attesting (which is insecure). > > > It seems to me, naively, that the same script you propose here can be > used for mainstake. > > > > > > For instance, the sidechain network might accept potential stakers on > the mainchain, if the staker proves the existence of a mainchain > transaction whose output is for example: > > > > > > OP_DROP > > > "1 year" OP_CHECKSEQUENCEVERIFY OP_DROP > > > OP_CHECKSIG > > > > > > The sidechain network could accept this and use the value of the > output as the weight of the vote of that stake. > > > > > > Regards, > > > ZmnSCPxj > > > > > > Sent with ProtonMail Secure Email. > > > > > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origi= nal Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 > > > On Saturday, January 19, 2019 6:59 AM, Matt Bell via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > > > I have been working on a design for Bitcoin sidechains using the > Tendermint BFT consensus protocol, which is commonly used to build > proof-of-stake networks (Cosmos is the notable one). > > > > > > > > The design ends up being very similar to Blockstream's Liquid > sidechain, since Tendermint consensus is not far off from Liquid's "stron= g > federation" consensus. > > > > > > > > Any feedback about improvements or critical flaws would be greatly > appreciated. The design document is here: > https://github.com/mappum/bitcoin-peg/blob/master/bitcoinPeg.md (that > repo also contains a simplified implementation of this sidechain design). > > > > > > > > Thanks for your feedback, > > > > Matt Bell > > > --000000000000b23452057ffc4af7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

ZmnSCPxj,


I'm intrigued by this mecha= nism of using fixed R values to prevent multiple signatures, but how do we = derive the R values in a way where they are unique for each blockheight but= still can be used to create signatures or verify?

Thanks,
Matt

On Sat, Jan 19, 2019 at 6:06 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
Good Morning Matt,

It seems to me that double signing can be punished by requiring that R be a= trivial function on the blockheight of the block being signed on the sidec= hain network. Then a validator who signs multiple versions of history at a = particular blockheight reveals their privkey. Since the privkey also protec= ts their Bitcoin stake UTXO, they risk loss of their Bitcoin stake. A simil= ar idea is used by Discrete Log Contracts to ensure Oracles do not sign mul= tiple values at a particular time.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Saturday, January 19, 2019 1:35 PM, Matt Bell <mappum@gmail.com> wrote:

> Hi ZmnSCPxj,
>
> Just to clarify, my design does not specify the source of voting power= , so it is agnostic to whatever system you want to derive stake or valdiato= r set membership from.
>
> Your idea of timelocking Bitcoin is interesting, I am eager to find a = solution where holding Bitcoin is enough to get voting power. It's poss= ible there may be an issue with the fact that the Bitcoin is not slashable = (although their voting power is), meaning a validator who double-signs cann= ot have their Bitcoin removed from them. However their UTXO can be blacklis= ted which does make their attack costly since they lose out on the time-val= ue of their stake.
>
> Our current thinking for the source of stake is to pay out stake to Bi= tcoin merged-miners although=C2=A0I'll definitely do some more thinking= about timelocked Bitcoin as stake.
>
> On Fri, Jan 18, 2019, 5:42 PM ZmnSCPxj <ZmnSCPxj@protonmail.com wrote:
>
> > Good morning Matt,
> >
> > It seems to me much more interesting if the stakes used to weigh = voting power are UTXOs on the Bitcoin blockchain.
> > This idea is what I call "mainstake"; rather than a blo= ckchain having its own token that is self-attesting (which is insecure). > > It seems to me, naively, that the same script you propose here ca= n be used for mainstake.
> >
> > For instance, the sidechain network might accept potential staker= s on the mainchain, if the staker proves the existence of a mainchain trans= action whose output is for example:
> >
> > <sidechain identifier> OP_DROP
> > "1 year" OP_CHECKSEQUENCEVERIFY OP_DROP
> > <pubkey> OP_CHECKSIG
> >
> > The sidechain network could accept this and use the value of the = output as the weight of the vote of that stake.
> >
> > Regards,
> > ZmnSCPxj
> >
> > Sent with ProtonMail Secure Email.
> >
> > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 O= riginal Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2= =80=90
> > On Saturday, January 19, 2019 6:59 AM, Matt Bell via bitcoin-dev = <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > I have been working on a design for Bitcoin sidechains using= the Tendermint BFT consensus protocol, which is commonly used to build pro= of-of-stake networks (Cosmos is the notable one).
> > >
> > > The design ends up being very similar to Blockstream's L= iquid sidechain, since Tendermint consensus is not far off from Liquid'= s "strong federation" consensus.
> > >
> > > Any feedback about improvements or critical flaws would be g= reatly appreciated. The design document is here: https://github.com/mappum/bitcoin-peg/blob/master/bitcoinPeg.md= (that repo also contains a simplified implementation of this sidechain= design).
> > >
> > > Thanks for your feedback,
> > > Matt Bell


--000000000000b23452057ffc4af7--