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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 27914904
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2017 08:50:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com
[209.85.218.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 143CE1A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2017 08:50:23 +0000 (UTC)
Received: by mail-oi0-f53.google.com with SMTP id l18so232969961oig.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2017 01:50:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:cc;
bh=dnCNKeIYURkXIlnp+pmeA3zYcxj78gggeH+gy7R2LEc=;
b=P+MewZ8d96dsJ0i0e2CzYu8DBsBdcNYh5EhCCaEcp+ZZmdt2LryovbPOjOhVqMM7WW
x54nkHi8Nr5cCn7gSyO7drETJOswT2SQ2UBAGEKPIjHOzpSsoCqiOe/0vS1MRUq2Ut6D
EVscPZ2RuWq6y0Tg6iSnATyTrKd8mNo63tckFhxCsLN0JiawROAP7jaws/TfY+WeZqND
2EwYJyxOSY04k0lvDNm5RI6shqb5zacfS+H51akY3tuVevrTSAJk9Oq+kmTPUbB0BSwY
Wiah5jen84cZEhOBZQJQ5v1tcuCUay9+3Cw6SrDbVUJI0KqXmE8pN9qZAsVVkBNUnL3L
xaBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:cc;
bh=dnCNKeIYURkXIlnp+pmeA3zYcxj78gggeH+gy7R2LEc=;
b=NSrWIlCwQNa1Wgq6qfuykmPDA45A5WqHJ6Z0kQAdFDG3dx+7X2yhgfl30ua2C5PeAy
Ld4ggdh/Cr8+cVizeCC7pQdYFqNkd/yLTU5kPGNXPWmZ+37+rKu2TSh+MSzWyK4jy8x3
a63AZD7Y8N8N4vR1kZCs4h19H7EwDd1Y7CDEKZPNZRhm+0xNBUhxTIHS4h/Nn5+e9eje
R1j+tuu7jlAxV4OTVNq92YF2K5UBIRzpF+zTNxZAG5+aoeo2iLPHVPv4CUHcCFfO00Qh
ejCRolYiUSOLLFYCv0MMnUs2n8VHhSEt3GauyIR2WV4UGLG3rg3UqEN0mlUacUFstT16
7ScQ==
X-Gm-Message-State: AODbwcARBRijL6clISfOMFWInNSX/3tM8RfBIljaH9PVuvBHYLsamCl3
G6C5bBX6bmlBlRLKIIRUCYj95frh/o/f
X-Received: by 10.157.46.234 with SMTP id w97mr3602709ota.78.1495615823259;
Wed, 24 May 2017 01:50:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.100.89 with HTTP; Wed, 24 May 2017 01:50:22 -0700 (PDT)
In-Reply-To: <141a0cd1-9d4f-c137-a349-17248f9cafd4@gmail.com>
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>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Wed, 24 May 2017 09:50:22 +0100
Message-ID: <CAE-z3OXY2YiQ5fzxZBw4FooRsUzXricHmpv_+t+HbTf0MxP0kg@mail.gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a114639d0ddafe605504131a3"
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
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
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 08:50:25 -0000
--001a114639d0ddafe605504131a3
Content-Type: text/plain; charset="UTF-8"
On Tue, May 23, 2017 at 3:22 PM, Paul Sztorc <truthcoin@gmail.com> wrote:
>
> If you haven't seen http://www.truthcoin.info/blog/drivechain/ , that is
> probably the most human-readable description.
>
I guess I was looking for the detail you get in the code, but without
having to read the code.
My quick reading gives that the sidechain codes (critical hashes) are added
when a coinbase is processed.
Any coinbase output that has the form "OP_RETURN <32 byte push>" counts as
a potential critical hash.
When the block is processed, the key value pair (hash, block_height) is
added to a hash map.
The OP_BRIBE opcode checks that the given hash is in the hash map and
replaces the top element on the stack with the pass/fail result.
It doesn't even check that the height matches the current block, though
there is a comment that that is a TODO.
I agree with ZmnSCPxj, when updating a nop, you can't change the stack. It
has to fail the script or do nothing.
OP_BRIBE_VERIFY would cause the script to fail if the hash wasn't in the
coinbase, or cause a script failure otherwise.
Another concern is that you could have multiple bribes for the same chain
in a single coinbase. That isn't fair and arguably what the sidechain
miner is paying for is to get his hash exclusively into the block.
I would suggest that the output is
OP_RETURN <sidechain_id> <critical hash>
Then add the rule that only the first hash with a particular sidechain id
actually counts.
This forces the miner to only accept the bribe from 1 miner for each
sidechain for each block. If he tries to accept 2, then only the first one
counts.
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
If you want reduce the number of drops, you could serialize the info into a
single push.
This has the advantage that a sidechain miner only has to pay if his block
is accepted in the next bitcoin block. Since he is the only miner for that
sidechain that gets into the main bitcoin block, he is pretty much
guaranteed to form the longest chain.
Without that rule, sidechain miners could end up having to pay even though
it doesn't make their chain the longest.
How are these transactions propagated over the network? For relaying, you
could have the rule that the opcode passes as long as <block height> is
near the current block height. Maybe require that they are in the future.
They should be removed from the memory pool once the block height has
arrived, so losing miners can re-spend those outputs.
This opcode can be validated without needing to look at other blocks, which
is good for validating historical blocks.
I am still looking at the deposit/withdrawal code.
--001a114639d0ddafe605504131a3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, May 23, 2017 at 3:22 PM, Paul Sztorc <span dir=3D"ltr"><<a href=3D"m=
ailto:truthcoin@gmail.com" target=3D"_blank">truthcoin@gmail.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span clas=
s=3D"gmail-m_-1252449154618151496gmail-"></span><span class=3D"gmail-m_-125=
2449154618151496gmail-"><br>
</span>If you haven't seen <a href=3D"http://www.truthcoin.info/blog/dr=
ivechain/" rel=3D"noreferrer" target=3D"_blank">http://www.truthcoin.info/b=
log<wbr>/drivechain/</a> , that is<br>
probably the most human-readable description.<br></blockquote><div><br></di=
v><div>I guess I was looking for the detail you get in the code, but withou=
t having to read the code.<br><br></div>My quick reading gives that the sid=
echain codes (critical hashes) are added when a coinbase is processed.<br><=
br></div><div class=3D"gmail_quote">Any coinbase output that has the form &=
quot;OP_RETURN <32 byte push>" counts as a potential critical ha=
sh.<br><br></div><div class=3D"gmail_quote">When the block is processed, th=
e key value pair (hash, block_height) is added to a hash map.<br><br></div>=
<div class=3D"gmail_quote">The OP_BRIBE opcode checks that the given hash i=
s in the hash map and replaces the top element on the stack with the pass/f=
ail result.<br><br></div><div class=3D"gmail_quote">It doesn't even che=
ck that the height matches the current block, though there is a comment tha=
t that is a TODO.<br></div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">I agree with ZmnSCPxj, when updating a nop, you can't =
change the stack.=C2=A0 It has to fail the script or do nothing.<br><br></d=
iv><div class=3D"gmail_quote">OP_BRIBE_VERIFY would cause the script to fai=
l if the hash wasn't in the coinbase, or cause a script failure otherwi=
se.<br><br></div><div class=3D"gmail_quote">Another concern is that you cou=
ld have multiple bribes for the same chain in a single coinbase.=C2=A0 That=
isn't fair and arguably what the sidechain miner is paying for is to g=
et his hash exclusively into the block.<br><br></div><div class=3D"gmail_qu=
ote">I would suggest that the output is<br><br></div><div class=3D"gmail_qu=
ote">OP_RETURN <sidechain_id> <critical hash><br><br></div><div=
class=3D"gmail_quote">Then add the rule that only the first hash with a pa=
rticular sidechain id actually counts.<br><br></div><div class=3D"gmail_quo=
te">This forces the miner to only accept the bribe from 1 miner for each si=
dechain for each block.=C2=A0 If he tries to accept 2, then only the first =
one counts.<br><br></div><div class=3D"gmail_quote">OP_BRIBE_VERIFY could t=
hen operate as follows<br><br></div><div class=3D"gmail_quote"><block he=
ight> <sidechain_id> <critical hash> OP_BRIBE_VERIFY<br><br>=
</div><div class=3D"gmail_quote">This causes the script to fail if<br></div=
><div class=3D"gmail_quote">=C2=A0 <block height> does not match the =
block height, or<br></div><div class=3D"gmail_quote">=C2=A0 <critical ha=
sh> is not the hash for the sidechain with <sidechain_id>, or<br><=
/div><div class=3D"gmail_quote">=C2=A0 there is no hash for that sidechain =
in the block's coinbase<br><br></div><div class=3D"gmail_quote">If you =
want reduce the number of drops, you could serialize the info into a single=
push.=C2=A0 <br><br></div><div class=3D"gmail_quote">This has the advantag=
e that a sidechain miner only has to pay if his block is accepted in the ne=
xt bitcoin block.=C2=A0 Since he is the only miner for that sidechain that =
gets into the main bitcoin block, he is pretty much guaranteed to form the =
longest chain.<br><br></div><div class=3D"gmail_quote">Without that rule, s=
idechain miners could end up having to pay even though it doesn't make =
their chain the longest.<br></div><div class=3D"gmail_quote"><br></div><div=
class=3D"gmail_quote">How are these transactions propagated over the netwo=
rk?=C2=A0 For relaying, you could have the rule that the opcode passes as l=
ong as <block height> is near the current block height.=C2=A0 Maybe r=
equire that they are in the future.=C2=A0 They should be removed from the m=
emory pool once the block height has arrived, so losing miners can re-spend=
those outputs.<br><br><div class=3D"gmail_quote">This opcode can be valida=
ted without needing to look at other blocks, which is good for validating h=
istorical blocks.<br></div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">I am still looking at the deposit/withdrawal code.<br></di=
v></div></div></div>
--001a114639d0ddafe605504131a3--
|
