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
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
|
Return-Path: <cryptaxe@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CF452B7A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2017 17:35:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f45.google.com (mail-pg0-f45.google.com [74.125.83.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2089916D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2017 17:35:23 +0000 (UTC)
Received: by mail-pg0-f45.google.com with SMTP id u187so68931581pgb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2017 10:35:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-language;
bh=AryL7kW9AevQ8k4BSIL6WSx3du2dq2WjbQowSlJkZcU=;
b=nnFiROJJ04X4h29bz8GOWw9YkRqdFJGccaixrnQwZBF14Uo5T4+VhTzsNst/I/NgMs
7/QGaCMp1vogDR5todzcT9aFeSTeYiOIGIeEs3T5thJXhy/O66c2pFAAymW2IlBfEscn
HPaeNufWB5oEpbkvqjxhruGiLPJwESaDI92o7zZPAkhgglueO42EHsipWNw06lunrpax
8Bn8CnA0wAFpRdYMZHrksjgyKWvC0nmMzFD5kAyFDLJo8T9qnaIXt9m0YSnCrLhF6EqH
6ESOIBRGOoyQbj7GoEFdzruIYk6AoMNo3nmlS2bvazpF91NbpfCIzMQ12ANy+b6QkVza
MkCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-language;
bh=AryL7kW9AevQ8k4BSIL6WSx3du2dq2WjbQowSlJkZcU=;
b=azW643UG4njIdu1y8WIsNLh1ihgSBhYawzCeS36WAwQZHsP76m9MYWmKLlAKDYJWt8
ZbKk11fDg80pVKkHtflAJvBQswNOeus+oySlBnJT31RdJuLZn1hXnAMhH4SWhbMZhY2u
MErYH4JnshPn4pv/EMr3hw4Pg7xNosDwb6T8yx8POBOzOBRG2WvVo3vs5sUEQ6lggLl7
uhROB8PK/cHrO5Rd7XtDSZDhy/S4mlN6hV8enOgb/6QvNGu+nrNIMJTdSmgVvgxkrMwa
rV7dM7/+8kIkFJMmdfQQRy0q+jKln9p3Aex5ZGkZ7ZR+Ul1kVH86OMmjcEcyKHo1WtDO
KScQ==
X-Gm-Message-State: AODbwcB6rZ2ZfVppxFVzT/7smWekxsCjgiHuu10oJ204EI1EXJhZA0WY
yIwsdCNd+GpgQej7JjU=
X-Received: by 10.84.176.3 with SMTP id u3mr28219638plb.119.1495647322343;
Wed, 24 May 2017 10:35:22 -0700 (PDT)
Received: from [192.168.1.109] (c-73-240-45-119.hsd1.or.comcast.net.
[73.240.45.119])
by smtp.gmail.com with ESMTPSA id 80sm9076695pfx.80.2017.05.24.10.35.20
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 24 May 2017 10:35:21 -0700 (PDT)
To: bitcoin-dev@lists.linuxfoundation.org
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
<dhstGQudLBiwjDlaRrmMfy-ixwvXcwMr1CzCkPKh285RLICGZixkbdwpTDc2Sgz8eYIqSem8lwxW6QeJCD7aFfwQjLDnZ2NmOw0Zzd-KgSs=@protonmail.com>
<CA+XQW1jZpJ9wnEg47fouyywL09=_vU8dMP3owkkuNqRvzTZUDg@mail.gmail.com>
<CAE-z3OUYuAXE2+h60A=r4UyGU4CSQuF98oFgHnD7iaj-=Z=yOw@mail.gmail.com>
<CA+XQW1hRhcxJBoOJ57YG0t5y5j1Qm3RO4wr2eXV5V-UzDaiPPw@mail.gmail.com>
<CAE-z3OVWXN58X-+nAFTm61G1=v_1xrniyrBy8x=VRG4N149aXQ@mail.gmail.com>
<141a0cd1-9d4f-c137-a349-17248f9cafd4@gmail.com>
<CAE-z3OXY2YiQ5fzxZBw4FooRsUzXricHmpv_+t+HbTf0MxP0kg@mail.gmail.com>
<CAE-z3OXLb0QOjACfvToxf9TfLJhBHiboAaieLA4V9gx6V4CjoQ@mail.gmail.com>
From: CryptAxe <cryptaxe@gmail.com>
Message-ID: <2b5567e1-2b6d-db4a-0f44-c66a24fe28ea@gmail.com>
Date: Wed, 24 May 2017 10:32:22 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CAE-z3OXLb0QOjACfvToxf9TfLJhBHiboAaieLA4V9gx6V4CjoQ@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------28869D4A0AC941D5998AB3B2"
Content-Language: en-US
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLY,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: Wed, 24 May 2017 17:38:00 +0000
Subject: Re: [bitcoin-dev] Drivechain -- Request for Discussion
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: Wed, 24 May 2017 17:35:23 -0000
This is a multi-part message in MIME format.
--------------28869D4A0AC941D5998AB3B2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Your assumptions of the bribe process are indeed correct you seem to
have a pretty good handle on all of that.
Hopefully I can clear up a few things. BMM among other things is still a
work in progress so you'll have to wait a
bit longer before any reorg code is on github. The "ratchet" system on
github right now just has the block hash
part of the critical hash script. The completed version needs to check
the sidechain number (ID) and the sidechain
block number in the script. Also the block number can only change by +1
or -1, so when a new h* is added to the
queue it must be compared to the most recent h* in the queue.
std::abs(queue.back().nHeight - ToAdd.nHeight) must equal 1.
Here's what the script looks like on github:
Note that the h* is just a block hash.
script << OP_RETURN << ToByteVector(h*);
Here's what I'm testing right now as I'm working on BMM:
script << OP_RETURN << CScriptNum::serialize(nSidechain) <<
CScriptNum(nSidechainHeight) << ToByteVector(sidechain blinded block
hash h*)
One other thing I want to make sure is clear enough is that the block
number in the critical hash script is
a sidechain block number, not a mainchain block number. That might mess
up the new format you have
suggested for bribes. And the reason a sidechain miner would want to
refund their bribe is if the h* doesn't
end up in a coinbase after a number of blocks, making their blinded
block on the sidechain invalid as tx's
will be spent in other blocks that do get their h* in a coinbase.
We were thinking about making bribe outputs have a maturity period like
generated coins. You
think that they should be locked for >100 blocks by having OP_BRIBE also
check the lock time?
I like all of your suggestions so far, thank you for taking a look!
On 05/24/2017 03:05 AM, Tier Nolan via bitcoin-dev wrote:
> On Wed, May 24, 2017 at 9:50 AM, Tier Nolan <tier.nolan@gmail.com
> <mailto:tier.nolan@gmail.com>> wrote:
>
> OP_BRIBE_VERIFY could then operate as follows
>
> <block height> <sidechain_id> <critical hash> OP_BRIBE_VERIFY
>
> This causes the script to fail if
> <block height> does not match the block height, or
> <critical hash> is not the hash for the sidechain with
> <sidechain_id>, or
> there is no hash for that sidechain in the block's coinbase
>
>
> I was thinking more on the process for these transactions.
>
> I assume that the process is
>
> - sidechain miner broadcasts transaction with OP_BRIBE output
> - this transaction ends up in the memory pool of miners
> - Miners add the transaction to their next block
> - Miners add a transaction which spends the output to one of their own
> addresses
>
> I think you need an additional rule that OP_BRIBE checks fails unless
> the output is locked 100 or more blocks.
>
> The output script would end up something like
>
> IF
> <block height> <chain_id> <critical hash> OP_BRIBE_VERIFY
> ELSE
> <public key> OP_CHECKSIG
> ENDIF
>
> This output acts like "anyone can spend" for the one block height.
> Otherwise, only the sidechain miner can spend the output.
>
> This allows the sidechain miner to reclaim their coins if the
> transaction ends up in a different block.
>
> OP_BRIBE_VERIFY would have an additional rule
>
> The script to fails if
> one or more of the transaction outputs start with something other
> than the template
> <block height> does not match the block height, or
> <critical hash> is not the hash for the sidechain with
> <sidechain_id>, or
> there is no hash for that sidechain in the block's coinbase
>
> The template is
> <100> OP_CHECKSEQUENCE_VERIFY
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--------------28869D4A0AC941D5998AB3B2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Your assumptions of the bribe process are indeed correct you seem
to have a pretty good handle on all of that. <br>
<br>
Hopefully I can clear up a few things. BMM among other things is
still a work in progress so you'll have to wait a <br>
bit longer before any reorg code is on github. The "ratchet"
system on github right now just has the block hash <br>
part of the critical hash script. The completed version needs to
check the sidechain number (ID) and the sidechain<br>
block number in the script. Also the block number can only change
by +1 or -1, so when a new h* is added to the <br>
queue it must be compared to the most recent h* in the queue.
std::abs(queue.back().nHeight - ToAdd.nHeight) must equal 1.<br>
<br>
Here's what the script looks like on github:<br>
Note that the h* is just a block hash.<br>
<br>
script << OP_RETURN << ToByteVector(h*);<br>
<br>
Here's what I'm testing right now as I'm working on BMM:<br>
<br>
script << OP_RETURN <<
CScriptNum::serialize(nSidechain) <<
CScriptNum(nSidechainHeight) << ToByteVector(sidechain
blinded block hash h*)<br>
<br>
One other thing I want to make sure is clear enough is that the
block number in the critical hash script is <br>
a sidechain block number, not a mainchain block number. That might
mess up the new format you have <br>
suggested for bribes. And the reason a sidechain miner would want
to refund their bribe is if the h* doesn't<br>
end up in a coinbase after a number of blocks, making their
blinded block on the sidechain invalid as tx's <br>
will be spent in other blocks that do get their h* in a coinbase.
<br>
<br>
We were thinking about making bribe outputs have a maturity period
like generated coins. You<br>
think that they should be locked for >100 blocks by having
OP_BRIBE also check the lock time?<br>
<br>
I like all of your suggestions so far, thank you for taking a
look!</p>
<br>
<div class="moz-cite-prefix">On 05/24/2017 03:05 AM, Tier Nolan via
bitcoin-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAE-z3OXLb0QOjACfvToxf9TfLJhBHiboAaieLA4V9gx6V4CjoQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Wed, May 24, 2017 at 9:50 AM, Tier
Nolan <span dir="ltr"><<a
href="mailto:tier.nolan@gmail.com" target="_blank"
moz-do-not-send="true">tier.nolan@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">OP_BRIBE_VERIFY could then
operate as follows<br>
<br>
</div>
<div class="gmail_quote"><block height>
<sidechain_id> <critical hash>
OP_BRIBE_VERIFY<br>
<br>
</div>
<div class="gmail_quote">This causes the script to
fail if<br>
</div>
<div class="gmail_quote"> <block height> does
not match the block height, or<br>
</div>
<div class="gmail_quote"> <critical hash> is
not the hash for the sidechain with
<sidechain_id>, or<br>
</div>
<div class="gmail_quote"> there is no hash for that
sidechain in the block's coinbase<br>
<br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div>
I was thinking more on the process for these transactions.<br>
<br>
</div>
<div class="gmail_extra">I assume that the process is<br>
<br>
</div>
<div class="gmail_extra">- sidechain miner broadcasts
transaction with OP_BRIBE output<br>
</div>
<div class="gmail_extra">- this transaction ends up in the
memory pool of miners<br>
</div>
<div class="gmail_extra">- Miners add the transaction to their
next block<br>
</div>
<div class="gmail_extra">- Miners add a transaction which spends
the output to one of their own addresses<br>
<br>
</div>
<div class="gmail_extra">I think you need an additional rule
that OP_BRIBE checks fails unless the output is locked 100 or
more blocks.<br>
<br>
</div>
<div class="gmail_extra">The output script would end up
something like<br>
<br>
</div>
<div class="gmail_extra">IF<br>
</div>
<div class="gmail_extra"> <block height>
<chain_id> <critical hash> OP_BRIBE_VERIFY<br>
</div>
<div class="gmail_extra">ELSE<br>
</div>
<div class="gmail_extra"> <public key> OP_CHECKSIG<br>
</div>
<div class="gmail_extra">ENDIF<br>
<br>
</div>
<div class="gmail_extra">This output acts like "anyone can
spend" for the one block height. Otherwise, only the
sidechain miner can spend the output.<br>
</div>
<div class="gmail_extra"><br>
This allows the sidechain miner to reclaim their coins if the
transaction ends up in a different block.<br>
<br>
</div>
<div class="gmail_extra">OP_BRIBE_VERIFY would have an
additional rule<br>
<br>
<div class="gmail_quote">The script to fails if<br>
</div>
<div class="gmail_quote"> one or more of the transaction
outputs start with something other than the template<br>
</div>
<div class="gmail_quote"> <block height> does not match
the block height, or<br>
</div>
<div class="gmail_quote"> <critical hash> is not the
hash for the sidechain with <sidechain_id>, or<br>
</div>
there is no hash for that sidechain in the block's coinbase<br>
<br>
</div>
<div class="gmail_extra">The template is<br>
</div>
<div class="gmail_extra"> <100> OP_CHECKSEQUENCE_VERIFY<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------28869D4A0AC941D5998AB3B2--
|
