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
|
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 01385955
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Sep 2017 17:06:47 +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 6D1D73D4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Sep 2017 17:06:46 +0000 (UTC)
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=suredbits.com;
q=dns/txt;
s=mailo; t=1504631205; h=Content-Type: To: Subject: Message-ID: Date:
From: References: In-Reply-To: MIME-Version: Sender;
bh=twq/03GEVRDLDxZEas8JsnshCtlfhKCSqgAj+zPyjRI=;
b=hYSwY3+k09aFekS8YKvI+QsF0ZUos2QGENL3BPKQPDtyfHqXbMrqNqzqv2HD/oKz5nNwARfv
doXiHBd9dcRYq2SIqZ7Pz3ykmoEN1om9+8WeA4qrt29p1l7P8IwuhOcW0+i9LETwjnkSU/gA
J7T5rzlPMqDp9byxy9zBd/yoKS0=
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=Zoq5RZvqETth+w0OwsBfN60I0bP7cWSn10zw0QYHFGEd96q0pKYVWNu6fCA1zpP91EkDf6
GKnv8pjBlI92qKLS8+xK5xNHo3ruYbKEjVMZc9nS6QYknx3VFG0mTjUcUKp7xsXdYHEAu17A
UvqzWzVDFZgxkFtfT30U2PPZ+GFW8=
Sender: chris@suredbits.com
X-Mailgun-Sending-Ip: 198.61.254.16
X-Mailgun-Sid: WyI5MGYzNyIsICJiaXRjb2luLWRldkBsaXN0cy5saW51eGZvdW5kYXRpb24ub3JnIiwgIjJjMTQxIl0=
Received: from mail-io0-f181.google.com (mail-io0-f181.google.com
[209.85.223.181])
by mxa.mailgun.org with ESMTP id 59aed999.7f3ae4506970-smtp-out-n02;
Tue, 05 Sep 2017 17:06:33 -0000 (UTC)
Received: by mail-io0-f181.google.com with SMTP id z67so18871146iof.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 05 Sep 2017 10:06:33 -0700 (PDT)
X-Gm-Message-State: AHPjjUg8Q4Gq9SKHsnmf+sKqJ6Tz3z5TWYPKSM7fm37YkQLKAW4afn/z
iJKSqNHYZj41ZQjD5QLNh9EZfdlUNg==
X-Google-Smtp-Source: ADKCNb5K6bwhK07Pkq+2/2qZ1lD/6B9x9Ma6mG5UyJL8FAKUjLfY0rtUvsQocJkTPumlaglF3u2CPv8wNplRlBNqacc=
X-Received: by 10.107.147.9 with SMTP id v9mr4981313iod.92.1504631193026; Tue,
05 Sep 2017 10:06:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.10.20 with HTTP; Tue, 5 Sep 2017 10:06:32 -0700 (PDT)
In-Reply-To: <H7RPmZGfkVC8opGMMCW7Orav6yD05-AVB9bNtNU8C0hKYokiXL32VSmn0wkjn77qh4MvacPOePdVQ5gQZuAMF6q2oEuvKDSu6crNcEoXx_0=@protonmail.com>
References: <H7RPmZGfkVC8opGMMCW7Orav6yD05-AVB9bNtNU8C0hKYokiXL32VSmn0wkjn77qh4MvacPOePdVQ5gQZuAMF6q2oEuvKDSu6crNcEoXx_0=@protonmail.com>
From: Chris Stewart <chris@suredbits.com>
Date: Tue, 5 Sep 2017 12:06:32 -0500
X-Gmail-Original-Message-ID: <CAGL6+mFHe_SfMea1oMZ3n-G3ey9yToAvTMTcfdxJ5qDD1dTXyQ@mail.gmail.com>
Message-ID: <CAGL6+mFHe_SfMea1oMZ3n-G3ey9yToAvTMTcfdxJ5qDD1dTXyQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c056162c74caa0558743fad"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM
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, 05 Sep 2017 17:08:37 +0000
Subject: Re: [bitcoin-dev] Sidechain headers on mainchain (unification of
drivechains and spv proofs)
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, 05 Sep 2017 17:06:47 -0000
--94eb2c056162c74caa0558743fad
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi ZmnSCPxj,
Basically, in case of a sidechain fork, the mainchain considers the longest
> chain to be valid if it is longer by the SPV proof required length. In t=
he
> above, at mainchain block 10, the sidechain H is now 4 blocks (H,G,F,E)
> longer than the other sidechain fork that ended at d.
>
> Mainchain nodes can validate this rule because the sidechain headers are
> embedded in the mainchain block's coinbase. Thus, mainchain fullnodes ca=
n
> validate this part of the sidechain rule of "longest work chain".
>
What happens in the case that the provided merkle tree hash has a invalid
transaction in it? Wouldn't this mean that the mainchain nodes would think
the longest work chain is the valid chain, and it would kill off any
consensus valid chain that sidechain miners are trying to construct? It
seems that a malicious miner could extend the chain to whatever the SPV
proof block height is and make it impossible for the chain to reorg after
that. I guess if that is a sufficiently long block waiting period it may
not be a realistic concern, but something to think about any way.
Just a side note -- I think it should be highly recommended that the
coinbase maturity period on the sidechain to be longer than 288 (or
whatever we decide on the parameter). This incentivizes the s:miners to
work together to extend the chain by working with other s:miners (otherwise
they won't be able to claim their bribes). If they do not work together
they will not be able to spend their s:coinbase_tx outputs until they
extend their own sidechain by 288 blocks meaning they need to tie up a
large amount of capital to go rogue on their fork.
Another interesting thing might be to use the OP_WITHDRAWPROOFVERIFY op cod=
e
<https://github.com/ElementsProject/elements/blob/elements-0.14.1/src/scrip=
t/interpreter.cpp#L1420>
used in the elements project. Since the cannonical merkle root hashes are
included in the mainchain, we can provide a merkle proof to the bitcoin
blockchain to initiate a withdrawl from the sidechain. I wrote up a blog
post on how OP_WPV works here
<https://medium.com/@Chris_Stewart_5/what-can-go-wrong-when-transferring-co=
ins-into-a-sidechain-with-op-withdrawproofverify-b2f49b02ab60>.
This allows us to prove that a transaction occurred on the sidechain to
lock up those funds.
-Chris
=E2=80=8B
--94eb2c056162c74caa0558743fad
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div>Hi ZmnSCPxj,<br></div><div><br></=
div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Basically, =
in case of a sidechain fork, the mainchain considers the
longest chain to be valid if it is longer by the SPV proof required=20
length.=C2=A0 In the above, at mainchain block 10, the sidechain H is now 4=
=20
blocks (H,G,F,E) longer than the other sidechain fork that ended at d.<br><=
/div><div><br></div>Mainchain
nodes can validate this rule because the sidechain headers are embedded
in the mainchain block's coinbase.=C2=A0 Thus, mainchain fullnodes can=
=20
validate this part of the sidechain rule of "longest work chain".=
<br></blockquote><br></div>What happens in the case that the provided merkl=
e tree hash has a invalid transaction in it? Wouldn't this mean that th=
e mainchain nodes would think the longest work chain is the valid chain, an=
d it would kill off any consensus valid chain that sidechain miners are try=
ing to construct? It seems that a malicious miner could extend the chain to=
whatever the SPV proof block height is and make it impossible for the chai=
n to reorg after that. I guess if that is a sufficiently long block waiting=
period it may not be a realistic concern, but something to think about any=
way. <br></div><br></div>Just a side note -- I think it should be highly r=
ecommended that the coinbase maturity period on the sidechain to be longer =
than 288 (or whatever we decide on the parameter). This incentivizes the s:=
miners to work together to extend the chain by working with other s:miners =
(otherwise they won't be able to claim their bribes). If they do not wo=
rk together they will not be able to spend their s:coinbase_tx outputs unti=
l they extend their own sidechain by 288 blocks meaning they need to tie up=
a large amount of capital to go rogue on their fork.<br><br></div>Another =
interesting thing might be to use the <a href=3D"https://github.com/Element=
sProject/elements/blob/elements-0.14.1/src/script/interpreter.cpp#L1420">OP=
_WITHDRAWPROOFVERIFY op code</a> used in the elements project. Since the ca=
nnonical merkle root hashes are included in the mainchain, we can provide a=
merkle proof to the bitcoin blockchain to initiate a withdrawl from the si=
dechain. I wrote up a blog post on how OP_WPV works <a href=3D"https://medi=
um.com/@Chris_Stewart_5/what-can-go-wrong-when-transferring-coins-into-a-si=
dechain-with-op-withdrawproofverify-b2f49b02ab60">here</a>. This allows us =
to prove that a transaction occurred on the sidechain to lock up those fund=
s.<br><br></div>-Chris<br><div><div>=E2=80=8B</div></div></div>
--94eb2c056162c74caa0558743fad--
|
