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
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
|
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 C707C8A5
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 30 Jun 2017 14:12:35 +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 DA6CA1E2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 30 Jun 2017 14:12:33 +0000 (UTC)
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=suredbits.com;
q=dns/txt;
s=mailo; t=1498831953; h=Content-Type: Cc: To: Subject: Message-ID:
Date: From: References: In-Reply-To: MIME-Version: Sender;
bh=3S9+dAk+BnMlgYXbl9IibWlunfGtKriiie8mmy1eVdw=;
b=ltyy3KUOzN2nl84RtwbNuau8oYZ0T9J0QI7JnpGA5Y7n+AVaK3dgPLPkylzM4P8XiBWCU2ET
szJp/tzHVxwhhTujYvGXzF7pU70KMWHkaY09bNKboLtW5O1GtZaI+qqN2Jp/8Eym3lro9Mq/
J5yHldzcNKNHphq3JHOvVvAu34s=
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: Cc: Content-Type;
b=QjT7DnXnp473gUJEJctXr9b0W56JKErxrXh9EyUbT5ufGnNaYpfPvdPDSYxRVUkqRbQb0O
avPDFDmsvB726fLoLu67zh/pUvSXbYIiXjApmYHphWBz1GZNmIZEfcM8VB6lzDVeWZ2AQw7G
4iEn8GlLmbsZPk0ZgW8sQt2Y8JgW4=
Sender: chris@suredbits.com
X-Mailgun-Sending-Ip: 198.61.254.16
X-Mailgun-Sid: WyI5MGYzNyIsICJiaXRjb2luLWRldkBsaXN0cy5saW51eGZvdW5kYXRpb24ub3JnIiwgIjJjMTQxIl0=
Received: from mail-it0-f42.google.com (mail-it0-f42.google.com
[209.85.214.42])
by mxa.mailgun.org with ESMTP id 59565c50.7f5f50096730-smtp-out-n03;
Fri, 30 Jun 2017 14:12:32 -0000 (UTC)
Received: by mail-it0-f42.google.com with SMTP id v202so61371264itb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 30 Jun 2017 07:12:31 -0700 (PDT)
X-Gm-Message-State: AKS2vOzh+PacTpJZZlQ9OONT6r40qtumndCZtdH0BIZ61bxZhnDxvnCM
GK5UZ+JLj8h2z1820BMFTuio3VMyhw==
X-Received: by 10.36.60.150 with SMTP id m144mr7834198ita.105.1498831951333;
Fri, 30 Jun 2017 07:12:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.185.3 with HTTP; Fri, 30 Jun 2017 07:12:30 -0700 (PDT)
In-Reply-To: <lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com>
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
<OozQK1_gWeExd5578AYH_dHnSKSvx63FJc2rIBBcaJF4f07qzsR8rr-ka5epwMFCjqDuidAWZiZqqlvn4xvSuUpDY0KkV014VQs6_E3Rp_A=@protonmail.com>
<2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com>
<lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com>
From: Chris Stewart <chris@suredbits.com>
Date: Fri, 30 Jun 2017 09:12:30 -0500
X-Gmail-Original-Message-ID: <CAGL6+mF8Jh2qFYX=yDx=w7G83YX0eYhKXyRckDSvLH2v0OTJTA@mail.gmail.com>
Message-ID: <CAGL6+mF8Jh2qFYX=yDx=w7G83YX0eYhKXyRckDSvLH2v0OTJTA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="001a114a96940991c705532e02ff"
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 30 Jun 2017 16:57:13 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
Merge Mined drivechains
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: Fri, 30 Jun 2017 14:12:35 -0000
--001a114a96940991c705532e02ff
Content-Type: text/plain; charset="UTF-8"
>I don't understand this part. In my scheme, a sidechain cannot reorganize
unless the mainchain reorganizes, since the consensus loop only cares about
matching the current block; it ignores splits and does not consider them
valid.
Maybe I am misunderstanding you, but isn't this a flaw not a feature? What
if a attacker pays a large fee to have his *invalid* block hash included in
the bitcoin mainchain? Would this block *have* to be included in the
sidechain's blockchain forever since *it was* included in bitcoin
blockchain?
>Do you not provide a single sidechain's h* twice in the block? Once in
the coinbase and once in the briber's separate transaction?
Yes, my BIP proposal does this.
>In my scheme at least there is no indicator byte -- the "previous block"
hash is the indicator of which sidechain it is extending. From your other
emails on this list, it seems the ratchet is for withdrawals from sidechain
to mainchain? If so, should it not only appear in only some of the
sidechains (the ones which are currently doing some withdrawal?)?
Maybe I am missing something here, but why we do *explicitly* commit to the
previous block hash? Isn't it implicitly committed to via SHA256(SHA256())?
If a drivechain node tries to sync the drivechain from bitcoin's commitment
headers, it will invalidate that block since
the block hash does not correctly reference the previous block hash. AFAICT
there is no need to explicitly specify the previous block hash in the OP_BV
output. In general, I don't think we should assume these commitment headers
dictate the strict ordering of blocks on the sidechain -- only potential
blocks that
*might* be valid. To guarantee full validity drivechain nodes will have to
download the full block and figure out if they follow all of the consensus
rules.
This is sort of like headers first sync in bitcoin core:
https://bitcoin.org/en/developer-guide#headers-first
-Chris
On Thu, Jun 29, 2017 at 11:00 PM, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> Good Morning Paul,
>
> >It seems that, in your version, the "bribers" would react to the scheme
> >in inefficient ways, particularly when the mainchain"s tx-fee-rate (ie
> >fee per Kb) is low.
> >
> >In short, there would be many bribe-attempts (each of which would take
> >up space in mainchain blocks), almost all of which would be unsuccessful.
> >
> >In turn, miners would likely react to this, and try to improve the state
> >of affairs by offering users the privilege of occupying transaction slot
> >#2 (ie, the one right after the coinbase). Users would need to trust
> >miners for this, which introduces a cost friction which is pure
> >deadweight loss. And, it might be easier for larger/older miners to be
> >trustworthy than smaller/newer ones.
>
> I understand.
>
> >Your way is actually very similar to mine. Mine _forces_ the bribe to be
> >in the earliest txn (the coinbase) and to only occur once. Yours doesn"t
> >do anything to refund the briber, if the sidechain (but not the
> >mainchain) reorganizes (as it can easily do, if an older sidechain
> >parent is extended while the mainchain proceeds normally). This creates
> >additional risk.
>
> I don't understand this part. In my scheme, a sidechain cannot reorganize
> unless the mainchain reorganizes, since the consensus loop only cares about
> matching the current block; it ignores splits and does not consider them
> valid.
>
> But I suppose you are considering something like the Ethereum mutability
> feature, which I do not think is something you would want in a sidechain.
>
> >I think mine is also much more space-efficient. Even if ours each had
> >exactly one h* per sidechain per block, it seems that I only require one
> >hash to be communicated (plus an indicator byte, and a ~2 byte counter
> >for the ratchet), whereas you require two. Since its overhead per
> >sidechain per block, it actually might really add up.
>
> Do you not provide a single sidechain's h* twice in the block? Once in
> the coinbase and once in the briber's separate transaction?
>
> In my scheme at least there is no indicator byte -- the "previous block"
> hash is the indicator of which sidechain it is extending. From your other
> emails on this list, it seems the ratchet is for withdrawals from sidechain
> to mainchain? If so, should it not only appear in only some of the
> sidechains (the ones which are currently doing some withdrawal?)?
>
>
> Regards,
> ZmnSCPxj
>
--001a114a96940991c705532e02ff
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><span class=3D"gmail-im"><div>>=
;I don't understand this part.=C2=A0 In my scheme, a sidechain cannot=
=20
reorganize unless the mainchain reorganizes, since the consensus loop=20
only cares about matching the current block; it ignores splits and does=20
not consider them valid.<br><br></div></span>Maybe I am misunderstanding
you, but isn't this a flaw not a feature? What if a attacker pays a=20
large fee to have his *invalid* block hash included in the bitcoin=20
mainchain? Would this block *have* to be included in the sidechain's=20
blockchain forever since *it was* included in bitcoin blockchain? <br><span=
class=3D"gmail-im"><br>>Do you not provide a single sidechain's h* =
twice in the block?=C2=A0 Once in=20
the coinbase and once in the briber's separate transaction?<br><br></sp=
an></div>Yes, my BIP proposal does this. <br><span class=3D"gmail-im"><br>&=
gt;In my scheme at least there is no indicator byte -- the "previous b=
lock"
hash is the indicator of which sidechain it is extending.=C2=A0 From your=
=20
other emails on this list, it seems the ratchet is for withdrawals from=20
sidechain to mainchain?=C2=A0 If so, should it not only appear in only some=
=20
of the sidechains (the ones which are currently doing some withdrawal?)?<br=
><br></span></div>Maybe
I am missing something here, but why we do *explicitly* commit to the=20
previous block hash? Isn't it implicitly committed to via=20
SHA256(SHA256())? If a drivechain node tries to sync the drivechain from
bitcoin's commitment headers, it will invalidate that block since<br><=
/div>the
block hash does not correctly reference the previous block hash. AFAICT
there is no need to explicitly specify the previous block hash in the=20
OP_BV output. In general, I don't think we should assume these=20
commitment headers dictate the strict ordering of blocks on the=20
sidechain -- only potential blocks that<br></div>*might* be valid. To=20
guarantee full validity drivechain nodes will have to download the full=20
block and figure out if they follow all of the consensus rules.<br><br></di=
v>This is sort of like headers first sync in bitcoin core:<br><br><a href=
=3D"https://bitcoin.org/en/developer-guide#headers-first" target=3D"_blank"=
>https://bitcoin.org/en/<wbr>developer-guide#headers-first</a><div class=3D=
"gmail-yj6qo gmail-ajU"><div id=3D"gmail-:1ym" class=3D"gmail-ajR" tabindex=
=3D"0"><img class=3D"gmail-ajT" src=3D"https://ssl.gstatic.com/ui/v1/icons/=
mail/images/cleardot.gif"><br></div><div id=3D"gmail-:1ym" class=3D"gmail-a=
jR" tabindex=3D"0">-Chris<br></div></div></div><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">On Thu, Jun 29, 2017 at 11:00 PM, ZmnSCPxj <s=
pan dir=3D"ltr"><<a href=3D"mailto:ZmnSCPxj@protonmail.com" target=3D"_b=
lank">ZmnSCPxj@protonmail.com</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 Paul,<br></div><span class=3D""><div><br></div=
><div>>It seems that, in your version, the "bribers" would rea=
ct to the scheme<br></div><div>>in inefficient ways, particularly when t=
he mainchain"s tx-fee-rate (ie<br></div><div>>fee per Kb) is low.<b=
r></div><div>><br></div><div>>In short, there would be many bribe-att=
empts (each of which would take<br></div><div>>up space in mainchain blo=
cks), almost all of which would be unsuccessful.<br></div><div>><br></di=
v><div>>In turn, miners would likely react to this, and try to improve t=
he state<br></div><div>>of affairs by offering users the privilege of oc=
cupying transaction slot<br></div><div>>#2 (ie, the one right after the =
coinbase). Users would need to trust<br></div><div>>miners for this, whi=
ch introduces a cost friction which is pure<br></div><div>>deadweight lo=
ss. And, it might be easier for larger/older miners to be<br></div><div>>=
;trustworthy than smaller/newer ones.<br></div><div><br></div></span><div>I=
understand.<br></div><span class=3D""><div><br></div><div>>Your way is =
actually very similar to mine. Mine _forces_ the bribe to be<br></div><div>=
>in the earliest txn (the coinbase) and to only occur once. Yours doesn&=
quot;t<br></div><div>>do anything to refund the briber, if the sidechain=
(but not the<br></div><div>>mainchain) reorganizes (as it can easily do=
, if an older sidechain<br></div><div>>parent is extended while the main=
chain proceeds normally). This creates<br></div><div>>additional risk.<b=
r></div><div><br></div></span><div>I don't understand this part.=C2=A0 =
In my scheme, a sidechain cannot reorganize unless the mainchain reorganize=
s, since the consensus loop only cares about matching the current block; it=
ignores splits and does not consider them valid.<br></div><div><br></div><=
div>But I suppose you are considering something like the Ethereum mutabilit=
y feature, which I do not think is something you would want in a sidechain.=
<br></div><span class=3D""><div><br></div><div>>I think mine is also muc=
h more space-efficient. Even if ours each had<br></div><div>>exactly one=
h* per sidechain per block, it seems that I only require one<br></div><div=
>>hash to be communicated (plus an indicator byte, and a ~2 byte counter=
<br></div><div>>for the ratchet), whereas you require two. Since its ove=
rhead per<br></div><div>>sidechain per block, it actually might really a=
dd up.<br></div><div><br></div></span><div>Do you not provide a single side=
chain's h* twice in the block?=C2=A0 Once in the coinbase and once in t=
he briber's separate transaction?<br></div><div><br></div><div>In my sc=
heme at least there is no indicator byte -- the "previous block" =
hash is the indicator of which sidechain it is extending.=C2=A0 From your o=
ther emails on this list, it seems the ratchet is for withdrawals from side=
chain to mainchain?=C2=A0 If so, should it not only appear in only some of =
the sidechains (the ones which are currently doing some withdrawal?)?<br></=
div><div><br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br><=
/div></blockquote></div><br></div>
--001a114a96940991c705532e02ff--
|