1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
|
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 4560E3235
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Jan 2019 05:35:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com
[209.85.160.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 65B1CE6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Jan 2019 05:35:57 +0000 (UTC)
Received: by mail-qt1-f179.google.com with SMTP id i7so17634549qtj.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Jan 2019 21:35:57 -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=HfEQjb0yOLooFOREsyAJSFCQRa4Ac267btYrBhhBpdc=;
b=g9MntNAstlxuaSGiHdTlnhWAO7bs15Z1fFUlxwoiWyXqMkO/aUTSLbiu14v1CLeac8
Oq7mrVQ7oS5ZcBEw3ufoynqlnEDWlmw379aPu1ZPwy1VUaT76LALGISIRwLPWEt8BkVU
gVLhx8kq5yO/Hr+vDAWp71DLBzU64RKE3CgpmCWmubBpjER8RO9X5V+U0ZQxzkH9Kn5T
PsfIpsWZHZXicQl9sBDFI6RngwZURSaZXqFmfaDJTkLRXnvyyUM3Y/RYFD41CGDxWCmP
uGQpOC1ZHgBz7NQjw5SN1runCbNfkeeyMHfl0MTZZkNycbVd1qKnSZGWEGc9qLhAFsQw
2+Pg==
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=HfEQjb0yOLooFOREsyAJSFCQRa4Ac267btYrBhhBpdc=;
b=a5TKUIcAduvNmMkJzTHWOD7RoJhSnPp7loJhKr+Sg++S+ndNTB+v0RDBrCkk5929O8
nda6Ykasie4tGA8VNEAwOE7imCf3DW4I6UmdzDaTRHoHSoA9edE3Q6LQYkEIBJyS/Xcx
8c5/1JPmmOzl4BaqS8VV6zPOVKN1hWYDrhV0632TRWwZAOOO3ZtQ3Edslhvc3F1AVRur
UnfI1N24M2+dcOng3WPm3tayc6VF0/LM+tEJO/zoWM5nnkAGmbhh5hbGRwhlg5biVfho
g/+fLTlsHXfgpK7WfZj4SIEeyEqMApR61mB5jFgS0zXL3eRIxs826R0gVKCNDlcFMep3
JJPg==
X-Gm-Message-State: AJcUukc74LJ+rQ3fVpSDD5ODqjQ3tK63UWL3FTxv8OFWoRxnq4GeirHh
LJHXiqqKngXex+bfM6LXKXW82C0ohuz1KmwXgY8=
X-Google-Smtp-Source: ALg8bN5LP5LWrNGjR6OsY8sPMNE5mylCz7n5QJp8K2WjHgBBPJeaLSTIiFbcubhWjxGcuAiTCm1je/h5Eb4VIV8HIR8=
X-Received: by 2002:ac8:1779:: with SMTP id u54mr18587364qtk.285.1547876156318;
Fri, 18 Jan 2019 21:35:56 -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>
In-Reply-To: <BTyUDt_7oOQmFj_V61w2eUJ7rfi-eOuNphy5nN0xNAhY4sUHnR2-0U9m-ZEKip4YjFi2-hGBtucvFv7nCTVo3aBxZ94VQCa1Kx2pP_zgdxU=@protonmail.com>
From: Matt Bell <mappum@gmail.com>
Date: Fri, 18 Jan 2019 21:35:43 -0800
Message-ID: <CACV3+OWjszx6istHo7yaNxiS22kyhHQhcPxGT3QLDx3KPUMU6g@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000007428df057fc900e4"
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: Sat, 19 Jan 2019 15:43:58 +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: Sat, 19 Jan 2019 05:35:58 -0000
--0000000000007428df057fc900e4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 valdiator 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 possible
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 the
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 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 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 use=
d
> 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 a=
s
> 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 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 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 "strong federatio=
n"
> 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
>
--0000000000007428df057fc900e4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div>Hi ZmnSCPxj,<div dir=3D"auto"><br></div><div dir=3D"=
auto">Just to clarify, my design does not specify the source of voting powe=
r, so it is agnostic to whatever system you want to derive stake or valdiat=
or set membership from.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
Your idea of timelocking Bitcoin is interesting, I am eager to find a solut=
ion where holding Bitcoin is enough to get voting power. It's possible =
there may be an issue with the fact that the Bitcoin is not slashable (alth=
ough their voting power is), meaning a validator who double-signs cannot ha=
ve their Bitcoin removed from them. However their UTXO can be blacklisted w=
hich does make their attack costly since they lose out on the time-value of=
their stake.</div><br>Our current thinking for the source of stake is to p=
ay out stake to Bitcoin merged-miners although=C2=A0<span style=3D"font-fam=
ily:sans-serif">I'll definitely do some more thinking about timelocked =
Bitcoin as stake.</span><br><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
>On Fri, Jan 18, 2019, 5:42 PM ZmnSCPxj <<a href=3D"mailto:ZmnSCPxj@prot=
onmail.com">ZmnSCPxj@protonmail.com</a> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">Good morning Matt,<br>
<br>
It seems to me much more interesting if the stakes used to weigh voting pow=
er are UTXOs on the Bitcoin blockchain.<br>
This idea is what I call "mainstake"; rather than a blockchain ha=
ving its own token that is self-attesting (which is insecure).<br>
It seems to me, naively, that the same script you propose here can be used =
for mainstake.<br>
<br>
For instance, the sidechain network might accept potential stakers on the m=
ainchain, if the staker proves the existence of a mainchain transaction who=
se output is for example:<br>
<br>
<sidechain identifier> OP_DROP<br>
"1 year" OP_CHECKSEQUENCEVERIFY OP_DROP<br>
<pubkey> OP_CHECKSIG<br>
<br>
The sidechain network could accept this and use the value of the output as =
the weight of the vote of that stake.<br>
<br>
Regards,<br>
ZmnSCPxj<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 6:59 AM, Matt Bell via bitcoin-dev <<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D=
"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
<br>
> I have been working on a design for Bitcoin sidechains using the Tende=
rmint BFT consensus protocol, which is commonly used to build proof-of-stak=
e networks (Cosmos is the notable one).<br>
><br>
> The design ends up being very similar to Blockstream's Liquid side=
chain, since Tendermint consensus is not far off from Liquid's "st=
rong federation" consensus.<br>
><br>
> Any feedback about improvements or critical flaws would be greatly app=
reciated. The design document is here: <a href=3D"https://github.com/mappum=
/bitcoin-peg/blob/master/bitcoinPeg.md" rel=3D"noreferrer noreferrer" targe=
t=3D"_blank">https://github.com/mappum/bitcoin-peg/blob/master/bitcoinPeg.m=
d</a> (that repo also contains a simplified implementation of this sidechai=
n design).<br>
><br>
> Thanks for your feedback,<br>
> Matt Bell<br>
</blockquote></div></div></div>
--0000000000007428df057fc900e4--
|
