path: root/43/f210b1393c8d33087a40c91a3711d818505b61

Return-Path: <mappum@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 59AA43B09
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 21 Jan 2019 18:47:26 +0000 (UTC)
Received: by mail-qk1-f175.google.com with SMTP id o8so12796492qkk.11
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CACV3+OU1ynRuR2SioW+O+CAp5M7ZQA6af_hEY5JZCVrXpqjtKQ@mail.gmail.com>
	<BTyUDt_7oOQmFj_V61w2eUJ7rfi-eOuNphy5nN0xNAhY4sUHnR2-0U9m-ZEKip4YjFi2-hGBtucvFv7nCTVo3aBxZ94VQCa1Kx2pP_zgdxU=@protonmail.com>
	<CACV3+OWjszx6istHo7yaNxiS22kyhHQhcPxGT3QLDx3KPUMU6g@mail.gmail.com>
	<nq9NDv6z-EJuJ9jGMWdlIZbpVM6Rm8QyuWL3nRYtXWF90I-cErA_WS1ib28kt950bZYyfF1_eP153aDjhUy523wYSM9TVaeHqeZdp3xJpsk=@protonmail.com>
In-Reply-To: <nq9NDv6z-EJuJ9jGMWdlIZbpVM6Rm8QyuWL3nRYtXWF90I-cErA_WS1ib28kt950bZYyfF1_eP153aDjhUy523wYSM9TVaeHqeZdp3xJpsk=@protonmail.com>
From: Matt Bell <mappum@gmail.com>
Date: Mon, 21 Jan 2019 10:47:13 -0800
Message-ID: <CACV3+OXQsUsgquJWZ9o8tTtak=axnbsdiNgLzF-j6yz1dDv4bA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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
> 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 <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 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 <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 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:
> > >
> > > <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 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

<div dir=3D"ltr"><div dir=3D"ltr"><h3 class=3D"gmail-iw" style=3D"overflow:=
hidden;white-space:nowrap;font-size:0.75rem;margin:inherit;text-overflow:el=
lipsis;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;letter-spa=
cing:0.3px;color:rgb(95,99,104);line-height:20px"><span style=3D"font-weigh=
t:400">ZmnSCPxj,</span></h3><div><span style=3D"font-weight:400"><br></span=
></div><div><span style=3D"font-weight:400">I&#39;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?</span></div><div><span s=
tyle=3D"font-weight:400"><br></span></div><div><span style=3D"font-weight:4=
00">Thanks,</span></div><div><span style=3D"font-weight:400">Matt</span></d=
iv></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att=
r">On Sat, Jan 19, 2019 at 6:06 PM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@=
protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">Good Morning Matt,<br>
<br>
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.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
<br>
Sent with ProtonMail Secure Email.<br>
<br>
=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<br>
On Saturday, January 19, 2019 1:35 PM, Matt Bell &lt;<a href=3D"mailto:mapp=
um@gmail.com" target=3D"_blank">mappum@gmail.com</a>&gt; wrote:<br>
<br>
&gt; Hi ZmnSCPxj,<br>
&gt;<br>
&gt; 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.<br>
&gt;<br>
&gt; Your idea of timelocking Bitcoin is interesting, I am eager to find a =
solution where holding Bitcoin is enough to get voting power. It&#39;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.<br>
&gt;<br>
&gt; Our current thinking for the source of stake is to pay out stake to Bi=
tcoin merged-miners although=C2=A0I&#39;ll definitely do some more thinking=
 about timelocked Bitcoin as stake.<br>
&gt;<br>
&gt; On Fri, Jan 18, 2019, 5:42 PM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@=
protonmail.com" target=3D"_blank">ZmnSCPxj@protonmail.com</a> wrote:<br>
&gt;<br>
&gt; &gt; Good morning Matt,<br>
&gt; &gt;<br>
&gt; &gt; It seems to me much more interesting if the stakes used to weigh =
voting power are UTXOs on the Bitcoin blockchain.<br>
&gt; &gt; This idea is what I call &quot;mainstake&quot;; rather than a blo=
ckchain having its own token that is self-attesting (which is insecure).<br=
>
&gt; &gt; It seems to me, naively, that the same script you propose here ca=
n be used for mainstake.<br>
&gt; &gt;<br>
&gt; &gt; 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:<br>
&gt; &gt;<br>
&gt; &gt; &lt;sidechain identifier&gt; OP_DROP<br>
&gt; &gt; &quot;1 year&quot; OP_CHECKSEQUENCEVERIFY OP_DROP<br>
&gt; &gt; &lt;pubkey&gt; OP_CHECKSIG<br>
&gt; &gt;<br>
&gt; &gt; The sidechain network could accept this and use the value of the =
output as the weight of the vote of that stake.<br>
&gt; &gt;<br>
&gt; &gt; Regards,<br>
&gt; &gt; ZmnSCPxj<br>
&gt; &gt;<br>
&gt; &gt; Sent with ProtonMail Secure Email.<br>
&gt; &gt;<br>
&gt; &gt; =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<br>
&gt; &gt; On Saturday, January 19, 2019 6:59 AM, Matt Bell via bitcoin-dev =
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt; 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).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The design ends up being very similar to Blockstream&#39;s L=
iquid sidechain, since Tendermint consensus is not far off from Liquid&#39;=
s &quot;strong federation&quot; consensus.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Any feedback about improvements or critical flaws would be g=
reatly appreciated. The design document is here: <a href=3D"https://github.=
com/mappum/bitcoin-peg/blob/master/bitcoinPeg.md" rel=3D"noreferrer" target=
=3D"_blank">https://github.com/mappum/bitcoin-peg/blob/master/bitcoinPeg.md=
</a> (that repo also contains a simplified implementation of this sidechain=
 design).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Thanks for your feedback,<br>
&gt; &gt; &gt; Matt Bell<br>
<br>
<br>
</blockquote></div></div>

--000000000000b23452057ffc4af7--