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
|
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 7C6609EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Jul 2017 20:22:30 +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 4E6DA16B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Jul 2017 20:22:29 +0000 (UTC)
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=suredbits.com;
q=dns/txt;
s=mailo; t=1499977348; h=Content-Type: Cc: To: Subject: Message-ID:
Date: From: References: In-Reply-To: MIME-Version: Sender;
bh=1tknFRjm1LwHmjf8h1hfTPLAo2M1EE0d8nBXYRd4uJ4=;
b=m+lZo/6LY3BguMrSd6Q0A/CUfR2KWp9CtsHHG1pmTkGTtEC+11sSlAgH+A/J4G+/yzHHGsL9
vde9AuVsHdDDUX47h6k9CLEQinynAI5KypZ/KMfSgwxZSAuL2yDn8abmq3pCU4mars4144WT
e+S3afmcxdLVca2kjlfJ94CmN6w=
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: Cc: Content-Type;
b=Lgs27zmdANgt34cnxVRAynnrBmEgclX0NkWDS3/kMItgyZC424EKHLn/oDn+mSBValGsgV
nsrffFok4pqum9FOVX6KimDdWSD64oOqaJEMreMOvJaHKNlr4fkXEemBIeXdvn3d0omL+vFv
THqBfKNEBewvtFq1lBU49UTdTJ+4U=
Sender: chris@suredbits.com
X-Mailgun-Sending-Ip: 198.61.254.16
X-Mailgun-Sid: WyI5MGYzNyIsICJiaXRjb2luLWRldkBsaXN0cy5saW51eGZvdW5kYXRpb24ub3JnIiwgIjJjMTQxIl0=
Received: from mail-it0-f48.google.com (mail-it0-f48.google.com
[209.85.214.48])
by mxa.mailgun.org with ESMTP id 5967d66b.7f99b4657270-smtp-out-n01;
Thu, 13 Jul 2017 20:22:03 -0000 (UTC)
Received: by mail-it0-f48.google.com with SMTP id v202so3807255itb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Jul 2017 13:22:03 -0700 (PDT)
X-Gm-Message-State: AIVw110Mk/7oQy/ruW6uv3ZYfjut4NKZgiTsBeA6gD6toZlJ5BA6iXLq
VMDfXl9WhE4sO7P90LpdmFBE0+qIyg==
X-Received: by 10.107.134.141 with SMTP id q13mr4960132ioi.191.1499977323137;
Thu, 13 Jul 2017 13:22:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.174.131 with HTTP; Thu, 13 Jul 2017 13:22:02 -0700 (PDT)
In-Reply-To: <7fc82c47-c03a-f489-55c2-b7d6830c1a74@gmail.com>
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>
<7fc82c47-c03a-f489-55c2-b7d6830c1a74@gmail.com>
From: Chris Stewart <chris@suredbits.com>
Date: Thu, 13 Jul 2017 15:22:02 -0500
X-Gmail-Original-Message-ID: <CAGL6+mEepScU-ZjrprQZo4hN5J05pGd63CapHWc3XNVAf43s1g@mail.gmail.com>
Message-ID: <CAGL6+mEepScU-ZjrprQZo4hN5J05pGd63CapHWc3XNVAf43s1g@mail.gmail.com>
To: Paul Sztorc <truthcoin@gmail.com>
Content-Type: multipart/alternative; boundary="001a113eacde8486e2055438afcb"
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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 20:46:13 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 20:22:30 -0000
--001a113eacde8486e2055438afcb
Content-Type: text/plain; charset="UTF-8"
I'm interested in hearing a reply from Russell/ZmnSCPxj in what they think
about lightning bribes. I hadn't given much thought about those while
writing my original BIP, but it does seem like my original BIP (minus the
fixed indexes in the coinbase output) fits this pretty well. If I
understand Paul correctly the OP_BV output will never hit the blockchain
then -- only the commitment in the coinbase transaction. This means no
extra data (if use lightning) has to be added to the blockchain *except*
the drivechain commitment (34 bytes in the coinbase tx vout). If this is
used for the vast majority bribes it may make the op code worth it.
In general though, I'm still unclear of what purpose the 'Ratchet' serves.
Can you either link to documentation about it or write something up quick?
-Chris
On Wed, Jul 12, 2017 at 7:00 PM, Paul Sztorc <truthcoin@gmail.com> wrote:
> 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.
>
--001a113eacde8486e2055438afcb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>I'm interested in hearing a reply from Russe=
ll/ZmnSCPxj in what they think about lightning bribes. I hadn't given m=
uch thought about those while writing my original BIP, but it does seem lik=
e my original BIP (minus the fixed indexes in the coinbase output) fits thi=
s pretty well. If I understand Paul correctly the OP_BV output will never h=
it the blockchain then -- only the commitment in the coinbase transaction. =
This means no extra data (if use lightning) has to be added to the blockcha=
in *except* the drivechain commitment (34 bytes in the coinbase tx vout). I=
f this is used for the vast majority bribes it may make the op code worth i=
t. <br><br></div>In general though, I'm still unclear of what purpose t=
he 'Ratchet' serves. Can you either link to documentation about it =
or write something up quick? <br><br></div>-Chris<br></div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Wed, Jul 12, 2017 at 7:00 PM, =
Paul Sztorc <span dir=3D"ltr"><<a href=3D"mailto:truthcoin@gmail.com" ta=
rget=3D"_blank">truthcoin@gmail.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"m_-8183879938683949194moz-cite-prefix">I still think it m=
ay 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" ch=
ain.<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'), wher=
eas
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?<span class=3D""><br>
<br>
<br>
On 7/12/2017 2:02 PM, Chris Stewart via bitcoin-dev wrote:<br>
</span></div><span class=3D"">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"m_-8183879938683949194gmail-ajy"><img class=3D"m_-818=
3879938683949194gmail-ajz" id=3D"m_-8183879938683949194gmail-:25p" src=3D"h=
ttps://mail.google.com/mail/u/0/images/cleardot.gif" alt=3D""></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 cl=
ear to me
what the best way to replace/remove it is. <br>
</div>
</div>
</div>
</div>
</blockquote>
<br></span>
I think that that is the purpose of Rusty's soft fork rule about
only including one per sidechain -- miners would have one "slot&qu=
ot; 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>
</div>
</blockquote></div><br></div>
--001a113eacde8486e2055438afcb--
|
