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
|
Return-Path: <bounce+33760e.2c141-bitcoin-dev=lists.linuxfoundation.org@suredbits.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8BFCC94B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Sep 2017 17:51:56 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from so254-16.mailgun.net (so254-16.mailgun.net [198.61.254.16])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B5BA23D4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Sep 2017 17:51:55 +0000 (UTC)
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=suredbits.com;
q=dns/txt;
s=mailo; t=1506448315; h=Content-Type: To: Subject: Message-ID: Date:
From: References: In-Reply-To: MIME-Version: Sender;
bh=uJUzqk2jUdgzRgNeqATe9gt5TezH19BZ9KnUZlQ92xw=;
b=c9h2NzaGkk325V7MVUxGt/pvI9J4mmPkVZc2+JUPMQiboMvYezIuMSsGcRqToTdErVD/3J93
7RgIICZsaI2iufWVD9kINDsyWwE2rWDMtfKRC6GurgBlsDn0SkOV4KU+53T5in4w/i2wuNxB
wVByaSeN0KcuS326jBvCLgLSzx0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=suredbits.com; s=mailo;
q=dns; h=Sender: MIME-Version: In-Reply-To: References: From: Date:
Message-ID: Subject: To: Content-Type;
b=BvTuctUzsFPrwOOle9WksUlKjFcIIFWKqYSV3F3m7FKQK6BWKONnxi2gm+II+cnD+xxK2c
l0Xgg9jzxzck1AO40LvTcOsorWDW77ojUoceVce1M0LvPUyGxD/RldGZvVct5cf51zJO0Bds
Q518Ky0HQXW5nWO6soTK0v+BCMLEE=
Sender: chris@suredbits.com
X-Mailgun-Sending-Ip: 198.61.254.16
X-Mailgun-Sid: WyI5MGYzNyIsICJiaXRjb2luLWRldkBsaXN0cy5saW51eGZvdW5kYXRpb24ub3JnIiwgIjJjMTQxIl0=
Received: from mail-it0-f44.google.com (mail-it0-f44.google.com
[209.85.214.44])
by mxa.mailgun.org with ESMTP id 59ca93b8.7f5dc41f0030-smtp-out-n02;
Tue, 26 Sep 2017 17:51:52 -0000 (UTC)
Received: by mail-it0-f44.google.com with SMTP id 85so3801132ith.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Sep 2017 10:51:51 -0700 (PDT)
X-Gm-Message-State: AHPjjUi/iPLscbE3jJGOuCYmASuyL4456m5c9b2g4nkBZAhCh6dp40/w
Z2Z9PDYnWJkDZgww3Iiq0alrzjeY/9FiNm6Zfw4=
X-Google-Smtp-Source: AOwi7QDpTqZAhSLa/o5AH095ZhrUupbqSzmTGzNqtKAgtfg6DycRlSSnabmGK7KDXNF09jtK3ZMrEg87vn/nVAFbMUo=
X-Received: by 10.36.6.3 with SMTP id 3mr7372319itv.36.1506448311280; Tue, 26
Sep 2017 10:51:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.10.224 with HTTP; Tue, 26 Sep 2017 10:51:50 -0700 (PDT)
In-Reply-To: <rRLvSIAs4ZyW4YTai9d_ON_xV2HH6NlhRIsU2C9mzTKiGuXmtJjafTtmK9lJIgBYVNVRGcfKAWON_l2ZE9bKuqON11NXGoKKn1SOGXi8Dbs=@protonmail.com>
References: <rRLvSIAs4ZyW4YTai9d_ON_xV2HH6NlhRIsU2C9mzTKiGuXmtJjafTtmK9lJIgBYVNVRGcfKAWON_l2ZE9bKuqON11NXGoKKn1SOGXi8Dbs=@protonmail.com>
From: Chris Stewart <chris@suredbits.com>
Date: Tue, 26 Sep 2017 12:51:50 -0500
X-Gmail-Original-Message-ID: <CAGL6+mEXEzrWK0w58tXEzHWvMQLdUJVEcJ5wBiFO0ye0yrKaig@mail.gmail.com>
Message-ID: <CAGL6+mEXEzrWK0w58tXEzHWvMQLdUJVEcJ5wBiFO0ye0yrKaig@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a1143df88777902055a1b542e"
X-Spam-Status: No, score=0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM,
URI_NOVOWEL autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 26 Sep 2017 22:46:22 +0000
Subject: Re: [bitcoin-dev] Sidechains: Mainstake
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: Tue, 26 Sep 2017 17:51:56 -0000
--001a1143df88777902055a1b542e
Content-Type: text/plain; charset="UTF-8"
>For each sidechain ID, for each mainchain block, at most one sidechain
block header may be published. In addition, the sidechain block header
published on the mainchain blocks may only be published by the stake
lottery winner from the end of the previous block.
What happens if the stake winner disappears? It seems, in your scheme, that
this would cause progress to come to a screeching halt.
Our weak mitigation against a mainchain miner >50% attack is weakened
> further; now the mainchain miner with 51% hashpower need only block the
> creation of sidechain mainstake UTXOs except its own, and eventually the
> other mainstake UTXOs will time out and the miner can outright steal
> costlessly
Can we not nest mainstake outputs in p2wsh/p2sh scripts to mitigate this?
This means that they cannot block the creation of mainstake utxos -- but I
guess they would still be able to block the spends of this utxo.
Another thing that is problematic with using a p2sh output is 'relocking'
the stake. Unfortunately if the p2sh script hash's aren't identical I don't
think we can guarantee they didn't spend the stake to a non stake output.
If the script hash's *are* identical then the miner can censor the
transaction that re-locks the output.
Perhaps there is a hybrid that would work, however it depends on what you
mean by 'creation'. If it is just the *initial* creation of the utxo -- and
not subsequent OP_STAKEVERIFY change outputs -- I think this strategy might
work. You just won't be able to participate in the lottery while the utxo
is nested inside the p2sh output initially.
This also brings back the problem above -- what if a stake winner
disappears -- or a miners creates the illusion they disappeared via
censorship? I guess a miner would be losing out on transaction fees.
-Chris
On Fri, Sep 22, 2017 at 8:49 PM, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Good morning bitcoin-dev,
>
> I have yet another sidechain proposal: https://zmnscpxj.github.io/
> sidechain/mainstake/index.html
>
> I make the below outlandish claims in the above link:
>
> 1. While a 51% mainchain miner theft is still possible, it will take even
> longer than in drivechains (either months of broadcasting intent to steal
> before the theft, or locking funds that are likely to remain locked after a
> week-long theft).
> 2. A 26% anti-sidechain miner cannot completely block all sidechain
> withdrawals as they could in drivechains.
> 3. Outside of attacks and censorship, the economic majority controls
> sidechains, without going through miners as "representatives of the
> economic majority".
> 4. With sufficient cleverness (stupidity?), proof-of-stake can be made to
> work.
>
> I hope for your consideration. I suspect that I have not thought things
> out completely, and probably missed some significant flaw.
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a1143df88777902055a1b542e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>>For each sidechain ID, for each mainchain block, =
at most
one sidechain block header may be published. In addition, the
sidechain block header published on the mainchain blocks may
only be published by the stake lottery winner from the end of
the previous block.<br><br></div>What happens if the stake winner disappear=
s? It seems, in your scheme, that this would cause progress to come to a sc=
reeching halt. <br><br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ou=
r weak mitigation against a mainchain miner >50% attack
is weakened further; now the mainchain miner with 51% hashpower
need only block the creation of sidechain mainstake UTXOs except
its own, and eventually the other mainstake UTXOs will time out
and the miner can outright steal costlessly</blockquote><div><br></div=
><div>Can we not nest mainstake outputs in p2wsh/p2sh scripts to mitigate t=
his? This means that they cannot block the creation of mainstake utxos -- b=
ut I guess they would still be able to block the spends of this utxo.<br></=
div><div><br> </div><div>Another thing that is problematic with using a p2s=
h output is 'relocking' the stake. Unfortunately if the p2sh script=
hash's aren't identical I don't think we can guarantee they di=
dn't spend the stake to a non stake output. If the script hash's *a=
re* identical then the miner can censor the transaction that re-locks the o=
utput.</div><div><br></div><div>Perhaps there is a hybrid that would work, =
however it depends on what you mean by 'creation'. If it is=20
just the *initial* creation of the utxo -- and not subsequent=20
OP_STAKEVERIFY change outputs -- I think this strategy might work. You=20
just won't be able to participate in the lottery while the utxo is=20
nested inside the p2sh output initially.<div><br></div></div><div>This also=
brings back the problem above -- what if a stake winner disappears -- or a=
miners creates the illusion they disappeared via censorship? I guess a min=
er would be losing out on transaction fees.</div><div><br></div><div>-Chris=
<br></div><div><br></div><div><br></div></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On Fri, Sep 22, 2017 at 8:49 PM, ZmnSCPxj via =
bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Good morning bitc=
oin-dev,<br></div><div><br></div><div>I have yet another sidechain proposal=
: <a href=3D"https://zmnscpxj.github.io/sidechain/mainstake/index.html" tar=
get=3D"_blank">https://zmnscpxj.github.io/<wbr>sidechain/mainstake/index.ht=
ml</a><br></div><div><br></div><div>I make the below outlandish claims in t=
he above link:<br></div><div><br></div><div>1. While a 51% mainchain miner =
theft is still possible, it will take even longer than in drivechains (eith=
er months of broadcasting intent to steal before the theft, or locking fund=
s that are likely to remain locked after a week-long theft).<br></div><div>=
2. A 26% anti-sidechain miner cannot completely block all sidechain withdra=
wals as they could in drivechains.<br></div><div>3. Outside of attacks and =
censorship, the economic majority controls sidechains, without going throug=
h miners as "representatives of the economic majority".<br></div>=
<div>4. With sufficient cleverness (stupidity?), proof-of-stake can be made=
to work.<br></div><div><br></div><div>I hope for your consideration.=C2=A0=
I suspect that I have not thought things out completely, and probably miss=
ed some significant flaw.<br></div><div><br></div><div>Regards,<br></div><d=
iv>ZmnSCPxj<br></div><br>______________________________<wbr>_______________=
__<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>
--001a1143df88777902055a1b542e--
|
