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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 53504491
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Jan 2019 02:06:17 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
[185.70.40.133])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 58FAC318
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Jan 2019 02:06:16 +0000 (UTC)
Date: Sun, 20 Jan 2019 02:06:08 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1547949973;
bh=+pbdUqjEn7DdNWu9F3fYIAabbfy+091aX4QJ6uc3BvU=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=yOj6CSHdONTgdeIMc4VxEKYmIMYi8/A+DF8W9OexyrQSNUzM8vZiPqIKE1raXXPIM
g2eATazepO72s1pHCk38vxxOs48i99E8jSRx8pbuiwhn6+zaACoJ4zB5zD2/UfPBv9
Z4uXelOq4qs9mHNm3F2k8d5D8Z4G7ML+aYXwFjEw=
To: Matt Bell <mappum@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <nq9NDv6z-EJuJ9jGMWdlIZbpVM6Rm8QyuWL3nRYtXWF90I-cErA_WS1ib28kt950bZYyfF1_eP153aDjhUy523wYSM9TVaeHqeZdp3xJpsk=@protonmail.com>
In-Reply-To: <CACV3+OWjszx6istHo7yaNxiS22kyhHQhcPxGT3QLDx3KPUMU6g@mail.gmail.com>
References: <CACV3+OU1ynRuR2SioW+O+CAp5M7ZQA6af_hEY5JZCVrXpqjtKQ@mail.gmail.com>
<BTyUDt_7oOQmFj_V61w2eUJ7rfi-eOuNphy5nN0xNAhY4sUHnR2-0U9m-ZEKip4YjFi2-hGBtucvFv7nCTVo3aBxZ94VQCa1Kx2pP_zgdxU=@protonmail.com>
<CACV3+OWjszx6istHo7yaNxiS22kyhHQhcPxGT3QLDx3KPUMU6g@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW 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: Sun, 20 Jan 2019 03:35:08 +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: Sun, 20 Jan 2019 02:06:17 -0000
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, s=
o it is agnostic to whatever system you want to derive stake or valdiator s=
et membership from.
>
> Your idea of timelocking Bitcoin is interesting, I am eager to find a sol=
ution where holding Bitcoin is enough to get voting power. It's possible th=
ere may be an issue with the fact that the Bitcoin is not slashable (althou=
gh their voting power is), meaning a validator who double-signs cannot have=
their Bitcoin removed from them. However their UTXO can be blacklisted whi=
ch does make their attack costly since they lose out on the time-value of t=
heir stake.
>
> Our current thinking for the source of stake is to pay out stake to Bitco=
in 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 blockchain having i=
ts own token that is self-attesting (which is insecure).
> > It seems to me, naively, that the same script you propose here can be u=
sed for mainstake.
> >
> > For instance, the sidechain network might accept potential stakers on t=
he 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 Origina=
l 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 <bitco=
in-dev@lists.linuxfoundation.org> wrote:
> >
> > > I have been working on a design for Bitcoin sidechains using the Tend=
ermint BFT consensus protocol, which is commonly used to build proof-of-sta=
ke networks (Cosmos is the notable one).
> > >
> > > The design ends up being very similar to Blockstream's Liquid sidecha=
in, since Tendermint consensus is not far off from Liquid's "strong federat=
ion" consensus.
> > >
> > > Any feedback about improvements or critical flaws would be greatly ap=
preciated. The design document is here: https://github.com/mappum/bitcoin-p=
eg/blob/master/bitcoinPeg.md (that repo also contains a simplified implemen=
tation of this sidechain design).
> > >
> > > Thanks for your feedback,
> > > Matt Bell
|
