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
|
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 90BE694B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2017 10:05:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com
[209.85.218.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3B54F1FC
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2017 10:05:40 +0000 (UTC)
Received: by mail-oi0-f50.google.com with SMTP id w10so235566492oif.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2017 03:05:40 -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=0xKNJFfDr6aqNvHIQGYUZxI4QK7vydAI/4wiyFI/oXY=;
b=Y0H5BXO16kSHxzvMTMvPi9OCr326xFgXMrO8JYC16/rShu5S686X1xyR3tycHyZbXU
MXsJGhIwu4eAqTjM9R8x8qZTQTzi0gIJK3Oc4rv48y0JPdl+oiSprtOshbrddBZJ9UDC
4/XJg7lqPcTST4pYIXkWyWKHAkqu/mpDTnWYpVloY0LF4cAzQkBmE9OkzLxEVjKeuxem
qs8wUM2tCi6cACTYew0URKI4/NQ5YnbIBO3gWYP5eY8uABrh330KbcP4+ciM0FeX1rjF
kOvZfJZqmNX6HOIiDE99wPN8JUUfJQbYIpepLtWJS4WBKFj/jfgjLFIYJncO7Oth1lo2
Dhnw==
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=0xKNJFfDr6aqNvHIQGYUZxI4QK7vydAI/4wiyFI/oXY=;
b=ZhfYgXvssBsIZGRZ6B1XLhPTdaBhtXJACOoEyMegdjvKUz+LfIpivxtfC06YX0U0Qj
1jHnn4z0c4owRnrH4f/q2A638Z0Pma23BHPeMtFrY1+q2SVbcA/XRFjVd73h4IY8+Abf
Qs1p9EgXKPBDSC5f2XlwlHVkNkdZHJimSWS4qln8oIfgMpyRhOZjwEpqYmXI4Z7u0iii
HRjzXLkgBSUF5/xcwpYOlyEPi7HzBLH2zpLt8GZXWU7UPQn31M33DeQEM7esahEgp13w
NBV7YuHrljAg8KyJG+5e3M/tDgdv5pEcrrmLMpbmaiUbPif1AKDkmte4uwAie6QLcHUt
supA==
X-Gm-Message-State: AODbwcALLnnc68pkFAsdYHAV8jR8NzplU+Q57189xOm+5XbIcb+we99j
6V0YtkvjYvXh+QL6fIFhUmmmud8BmQRQ
X-Received: by 10.202.214.133 with SMTP id n127mr17511096oig.205.1495620339406;
Wed, 24 May 2017 03:05:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.100.89 with HTTP; Wed, 24 May 2017 03:05:38 -0700 (PDT)
In-Reply-To: <CAE-z3OXY2YiQ5fzxZBw4FooRsUzXricHmpv_+t+HbTf0MxP0kg@mail.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>
<CAE-z3OXY2YiQ5fzxZBw4FooRsUzXricHmpv_+t+HbTf0MxP0kg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Wed, 24 May 2017 11:05:38 +0100
Message-ID: <CAE-z3OXLb0QOjACfvToxf9TfLJhBHiboAaieLA4V9gx6V4CjoQ@mail.gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a113de2160c9de80550423f35"
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 10:05:40 -0000
--001a113de2160c9de80550423f35
Content-Type: text/plain; charset="UTF-8"
On Wed, May 24, 2017 at 9:50 AM, Tier Nolan <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
--001a113de2160c9de80550423f35
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 W=
ed, May 24, 2017 at 9:50 AM, Tier Nolan <span dir=3D"ltr"><<a href=3D"ma=
ilto:tier.nolan@gmail.com" target=3D"_blank">tier.nolan@gmail.com</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">OP_BRIBE_VER=
IFY could then operate as follows<br><br></div><div class=3D"gmail_quote">&=
lt;block height> <sidechain_id> <critical hash> OP_BRIBE_VER=
IFY<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 hash> is not the hash for the sidechain with <sidechain_id&g=
t;, 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></div></blockquot=
e><div><br></div></div>I was thinking more on the process for these transac=
tions.<br><br></div><div class=3D"gmail_extra">I assume that the process is=
<br><br></div><div class=3D"gmail_extra">- sidechain miner broadcasts trans=
action with OP_BRIBE output<br></div><div class=3D"gmail_extra">- this tran=
saction ends up in the memory pool of miners<br></div><div class=3D"gmail_e=
xtra">- Miners add the transaction to their next block<br></div><div class=
=3D"gmail_extra">- Miners add a transaction which spends the output to one =
of their own addresses<br><br></div><div class=3D"gmail_extra">I think you =
need an additional rule that OP_BRIBE checks fails unless the output is loc=
ked 100 or more blocks.<br><br></div><div class=3D"gmail_extra">The output =
script would end up something like<br><br></div><div class=3D"gmail_extra">=
IF<br></div><div class=3D"gmail_extra">=C2=A0=C2=A0 <block height> &l=
t;chain_id> <critical hash> OP_BRIBE_VERIFY<br></div><div class=3D=
"gmail_extra">ELSE<br></div><div class=3D"gmail_extra">=C2=A0 <public ke=
y> OP_CHECKSIG<br></div><div class=3D"gmail_extra">ENDIF<br><br></div><d=
iv class=3D"gmail_extra">This output acts like "anyone can spend"=
for the one block height.=C2=A0 Otherwise, only the sidechain miner can sp=
end the output.<br></div><div class=3D"gmail_extra"><br>This allows the sid=
echain miner to reclaim their coins if the transaction ends up in a differe=
nt block.<br><br></div><div class=3D"gmail_extra">OP_BRIBE_VERIFY would hav=
e an additional rule<br><br><div class=3D"gmail_quote">The script to fails =
if<br></div><div class=3D"gmail_quote">=C2=A0 one or more of the transactio=
n outputs start with something other than the template<br></div><div class=
=3D"gmail_quote">=C2=A0 <block height> does not match the block heigh=
t, or<br></div><div class=3D"gmail_quote">=C2=A0 <critical hash> is n=
ot the hash for the sidechain with <sidechain_id>, or<br></div>=C2=A0=
there is no hash for that sidechain in the block's coinbase<br><br></d=
iv><div class=3D"gmail_extra">The template is<br></div><div class=3D"gmail_=
extra">=C2=A0 <100> OP_CHECKSEQUENCE_VERIFY<br></div></div>
--001a113de2160c9de80550423f35--
|
