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
|
Return-Path: <truthcoin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 56ADA414
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Jul 2017 00:00:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f177.google.com (mail-qt0-f177.google.com
[209.85.216.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D8310AC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Jul 2017 00:00:28 +0000 (UTC)
Received: by mail-qt0-f177.google.com with SMTP id i2so25789882qta.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Jul 2017 17:00:28 -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=rldDsvQWkRipqHsAF+51TsvAT1qlcxx7v9NEitI5clw=;
b=c9eN8TeVIXq0mxBQZZUiDAwtVvJ/7byIzIT3604qyWj0CkNg4xH1ty57JeApJRmRms
6UjhIUdZHDo1isfeGVko0f5vnygjcgwTxoOqNW/D/oIZLrdKS7RI0ZzmQSLUuVT0dSUV
m4o38T4yxg0OnCtThliz+38WXZy6IQ+yv7QV7QN4ut2Rmjn15+aDnrltRe3kEx86IqBR
1LRSdpEnrmzitkLaK/SbaXuXkPqnXu2HfkfhQJU661sun6mMZ87RNhyyaQe6IUnMaeDi
YMaq0udTUZuWmq36CKcSxCxFsCNZdZlPOjYZCujh+3rZ8JBvI8AVMwwAHzhL8spSZzkM
IB3Q==
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=rldDsvQWkRipqHsAF+51TsvAT1qlcxx7v9NEitI5clw=;
b=DJl9ZF6EI2rsMtx25S3RYiIWWuvvbYb5zEpIRsBZvOFORxR1VLlIhMl9T3nVriVLf+
RcIQhnsFFGMzwxtpLp2MFpQUYxSONVX+x8QyiHSUgC3us4Yawxoa827045VhdMq5AN0L
JHyMka7Kaum9aEFV5WPZv7QQJRqYqfq2TDENAXPch6LiFpHfr6azhb0Fbx+Rwfuk3fMY
OuxMv4ZlcuqjFXhGfmytSnEi15uZdkyzuuu5TEZSELjdxa55P3TRAwAaQJOR9cNVxAdG
Gu2lGOt5MXW0gM52O27af9T6mGGDOf7kaC7gwcEVGzL3ekSbpin0qRh1ulMpp+tN0Cq5
MxHQ==
X-Gm-Message-State: AIVw112QOEfRq94jj10/HBTWx6cx1gbDUvZx0cSE8RMWamtPhzbMr5mB
4KlWGaclwryKNQ==
X-Received: by 10.200.9.55 with SMTP id t52mr1444111qth.107.1499904027498;
Wed, 12 Jul 2017 17:00:27 -0700 (PDT)
Received: from [192.168.1.104] (ool-45726efb.dyn.optonline.net.
[69.114.110.251]) by smtp.googlemail.com with ESMTPSA id
q40sm3213022qtf.42.2017.07.12.17.00.26
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 12 Jul 2017 17:00:26 -0700 (PDT)
To: Chris Stewart <chris@suredbits.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Russell O'Connor <roconnor@blockstream.io>
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>
<98d35291-5948-cb06-c46a-9d209276cee2@gmail.com>
<GDZ42AMqaETJGYZovJzkVZkxZE3UmCQ8q5fFTAajV6sX2LHFol6iEYahkY_sMrPv5m11lHZvuKXmD_PwXa5_S7x18vcP1FkQr0ZBROxj6HE=@protonmail.com>
<CAGL6+mEeuhQp3TiLFOOAWO_wcRZXsfASKNT4364SSNzER6_xgw@mail.gmail.com>
<hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com>
<CAMZUoK==7OATOJ=46CYJWkq=WAXnJ8-JjvL25E1ijhnRbqj_Jg@mail.gmail.com>
<CAGL6+mHErvPbvKxrQkJ=DdTuzH-4Fsxh8JnnzVY16m2x6zeJFQ@mail.gmail.com>
<CAGL6+mE9TF=LeNwN2a6Ky+B=jqmW=1HqGOj6bPq2G3Aq8+FZAw@mail.gmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <7fc82c47-c03a-f489-55c2-b7d6830c1a74@gmail.com>
Date: Wed, 12 Jul 2017 20:00:29 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAGL6+mE9TF=LeNwN2a6Ky+B=jqmW=1HqGOj6bPq2G3Aq8+FZAw@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------7706548FCFD2FF1F5F7FE708"
Content-Language: en-US
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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: Thu, 13 Jul 2017 00:05:18 +0000
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: Thu, 13 Jul 2017 00:00:29 -0000
This is a multi-part message in MIME format.
--------------7706548FCFD2FF1F5F7FE708
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
I still think it may be more inefficient, in equilibrium. (In other
words, in the future steady state of Bitcoin that includes LN or
something LN-like).
Assume there are N sidechains.
In the coinbase version:
1. There is some single event, per N, that causes nodes to notice that a
new sidechain has been created.
2. Per block, there are N hash commitments (32 bytes) and N instances of
the ratchet's block counter (2 bytes).
3. Per block, some node operator _may_ have BMMed the block, and a miner
therefore might want redeem an OP Bribe that pays BTC from a sidechain
node operator to the miner. But they are likely to negotiate the payment
through the Lightning Network (when this is possible).
4. Sidechains running in SPV mode know exactly where to find the
information they need in order to discover the "longest" chain.
In the OP RETURN version:
1. [same] There is some single event, per N, that causes nodes to notice
that a new sidechain has been created.
2. [+30 bytes (+more?)] Per block, there are N hash commitments (32
bytes) and also N prevBlockHashes (32 bytes). Also, to make this
transaction, someone needs to spend something in the UTXO set (or select
no inputs in a kind of 'hollow transaction'), whereas one coinbase will
always exist per block.
3. [same] No need for a new transaction.
4. [same?] Due to Rusty's soft fork rule of only one h* per sidechain
per block, sidechains need just a merkle tree path, but they don't
necessarily know where it is. They must store extra [?] data to help
them find the data's location?
On 7/12/2017 2:02 PM, Chris Stewart via bitcoin-dev wrote:
> Hi Russell/ZmnSCPxj,
>
> I think you guys are right. The only problem I can see with it is
> replaceability of the bribe transaction. If the 'Bribe' is the fee on
> the transaction it isn't clear to me what the best way to
> replace/remove it is.
I think that that is the purpose of Rusty's soft fork rule about only
including one per sidechain -- miners would have one "slot" per
sidechain, and they would therefore have an incentive to make the slot
count, and would be only selecting the highest fee txn to fill each slot.=
--------------7706548FCFD2FF1F5F7FE708
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">
<div class="moz-cite-prefix">I still think it may be more
inefficient, in equilibrium. (In other words, in the future steady
state of Bitcoin that includes LN or something LN-like).<br>
<br>
Assume there are N sidechains.<br>
<br>
In the coinbase version:<br>
1. There is some single event, per N, that causes nodes to notice
that a new sidechain has been created.<br>
2. Per block, there are N hash commitments (32 bytes) and N
instances of the ratchet's block counter (2 bytes).<br>
3. Per block, some node operator _may_ have BMMed the block, and a
miner therefore might want redeem an OP Bribe that pays BTC from a
sidechain node operator to the miner. But they are likely to
negotiate the payment through the Lightning Network (when this is
possible).<br>
4. Sidechains running in SPV mode know exactly where to find the
information they need in order to discover the "longest" chain.<br>
<br>
In the OP RETURN version:<br>
1. [same] There is some single event, per N, that causes nodes to
notice that a new sidechain has been created.<br>
2. [+30 bytes (+more?)] Per block, there are N hash commitments
(32 bytes) and also N prevBlockHashes (32 bytes). Also, to make
this transaction, someone needs to spend something in the UTXO set
(or select no inputs in a kind of 'hollow transaction'), whereas
one coinbase will always exist per block.<br>
3. [same] No need for a new transaction.<br>
4. [same?] Due to Rusty's soft fork rule of only one h* per
sidechain per block, sidechains need just a merkle tree path, but
they don't necessarily know where it is. They must store extra [?]
data to help them find the data's location?<br>
<br>
<br>
On 7/12/2017 2:02 PM, Chris Stewart via bitcoin-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGL6+mE9TF=LeNwN2a6Ky+B=jqmW=1HqGOj6bPq2G3Aq8+FZAw@mail.gmail.com">
<div dir="ltr">
<div class="gmail-ajy" tabindex="0"><img class="gmail-ajz"
id="gmail-:25p"
src="https://mail.google.com/mail/u/0/images/cleardot.gif"
alt="" moz-do-not-send="true"></div>
<div>
<div>
<div>Hi Russell/ZmnSCPxj,<br>
<br>
</div>
<div>I think you guys are right. The only problem I can see
with it is replaceability of the bribe transaction. If the
'Bribe' is the fee on the transaction it isn't clear to me
what the best way to replace/remove it is. <br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
I think that that is the purpose of Rusty's soft fork rule about
only including one per sidechain -- miners would have one "slot" per
sidechain, and they would therefore have an incentive to make the
slot count, and would be only selecting the highest fee txn to fill
each slot.<br>
</body>
</html>
--------------7706548FCFD2FF1F5F7FE708--
|
