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
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
|
Return-Path: <jlrubin@mit.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4C21BA70
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 May 2019 08:10:39 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 103CA6C5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 May 2019 08:10:37 +0000 (UTC)
Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com
[209.85.208.48]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4M8AZjv032581
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 May 2019 04:10:36 -0400
Received: by mail-ed1-f48.google.com with SMTP id e24so2506724edq.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 May 2019 01:10:36 -0700 (PDT)
X-Gm-Message-State: APjAAAXsQ1KTGpwJKxGZIrBXCu0C1RBEgk7xrZxPrTB6QI//TwMlouLl
NIRrQcGnUlmWBB6zeSHt+vzYhe47ydStFak7yqE=
X-Google-Smtp-Source: APXvYqzelPMS5plN0MATMp9KNCrVtAnw7aRCaFFk2oT2hpXvbcT9ys6MzYn9ic2hV0arz4ri2KAxUXkMCVkyzjxHyug=
X-Received: by 2002:a17:906:66c9:: with SMTP id
k9mr20878945ejp.21.1558512635039;
Wed, 22 May 2019 01:10:35 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
<VU6YVz_dc9U4BhGd6WWNvYLS-DI1lBE14tpYdXEyIufTZ2OvqQfcWh6RVelCLWTQMWqiNsSf_AM3Pq2hzn3G62RIQwceLx54rRmD-zHCdNU=@protonmail.com>
<CAD5xwhixyvAA0zak86BwG3ZjinUJ37266K_wn_NCa-ECrVmouw@mail.gmail.com>
<CljXxJhTEILR7KZxgZ3o_yJm66XeySWzUY3abCm01blY9yX3AmMczvu41CAm9dr4ZQTDCTQqEM1D4MhEaGASuM54l51DaJmZSKv0eqtPjEo=@protonmail.com>
In-Reply-To: <CljXxJhTEILR7KZxgZ3o_yJm66XeySWzUY3abCm01blY9yX3AmMczvu41CAm9dr4ZQTDCTQqEM1D4MhEaGASuM54l51DaJmZSKv0eqtPjEo=@protonmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Wed, 22 May 2019 01:10:23 -0700
X-Gmail-Original-Message-ID: <CAD5xwhiHHemzaRLC7WMeXQ5hgu0rwMKMUym34xTxWO81qqf-oQ@mail.gmail.com>
Message-ID: <CAD5xwhiHHemzaRLC7WMeXQ5hgu0rwMKMUym34xTxWO81qqf-oQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000fd54560589757fe4"
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 22 May 2019 13:30:30 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY
proposal
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, 22 May 2019 08:10:39 -0000
--000000000000fd54560589757fe4
Content-Type: text/plain; charset="UTF-8"
> * I do not think CoinJoin is much improved by this opcode.
> Typically, you would sign off only if one of the outputs of the
CoinJoin transaction is yours, and this does not really improve this
situation.
Coinjoin benefits a lot I think.
Coinjoin is improved because you can fit more users into the protocol and
create many more outputs at lower cost or include more participants.
Ideally a coinjoin creates a lot of outputs so that the ownership is
smeared more, but this has a cost at the time of the coinjoin.
Coinjoin is also improved because you don't reveal the outputs created by
the coinjoin until some time, perhaps very far in the future, when you need
the coin. In fact, you only need to reveal where you're moving the coins to
participants in your subtree because participants need only verify their
branch.
It also makes the protocol more stable with respect to input choice. This
is because, similar to how NOINPUT may work, OP_COSHV outputs are spendable
without knowing what the TXID will be. Therefore if someone changes their
input or non segwit spend script, it won't break the presigned txns. This
also means that all the inputs can be ANYONECANPAY, so there is no need to
reveal your inputs before anyone else.
This culminates in being able to open channels from a coinjoin safely, I
believe this is difficult/impossible to do currently.
> * Using this for congestion control increases blockchain usage by one TXO
and one input, ending up with *more* bytes onchain, and a UTXO that will be
removed later in (we hope) short time.
> I do not know if this is a good idea, to increase congestion by making
unnecessary intermediate transaction outputs, at times when congestion is a
problem.
This is a good idea because it improves QoS for most users.
For receiving money pending spendable but confirmed payment (i.e. certified
checks) is superior to having unconfirmed funds.
For sending money, being able to clear all liabilities in a single txn
decreases business exposure to fee variance and confirmation time variance.
E.g., if I'm doing payroll in Bitcoin I will pay big fines if I am a day
late. If I have 10,000 employees this might be painful if fees are
currently up.
It also helps to have a backlog of low priority txns to support the fee
market.
Overall block bandwidth utilization is fairly spikey, so having long term
well known outputs that are not time sensitive can be used to better
utilize bandwidth.
The total extra bandwidth btw is really small given the expansion factor
optimizations available.
> * I cannot find a way to implement Decker-Russell-Osuntokun (or any
offchain update mechanism) on top of this opcode, so I cannot support
replacing `SIGHASH_NOINPUT` with this opcode.
> In particular, while the finite loop support by this opcode appears (at
first glance) to be useable as the "stepper" for an offchain update
mechanism, I cannot find a good way to short-circuit the transaction chain
without `SIGHASH_NOINPUT` anyway.
I'm not deeply familiar with DRO channels. This opcode isn't a replacement
for SIGHASH_NOINPUT -- SIGHASH_NOINPUT is mentioned merely to contrast
using SIGHASH_NOINPUT for the uses presented in this BIP.
Lastly there's no 'replacing'. Neither NOINPUT nor COSHV are accepted by
the community at large yet, and they do different things.
> * Channel factories created by this opcode do not, by themselves, support
updates to the channel structure.
> But such simple "close only" channel factories can be done using n-of-n
and a pre-signed offchain transaction (especially since the entities
interested in the factory are known and enumerable, and thus can be induced
to sign in order to enter the factory).
I'm not really an expert at Bitcoin Lightning, but this basic mechanism
should work.
Imagine the script at a leaf node:
Taproot([Alice, Bob], [OP_COSHV <H(H(2 coins to uncooperative script))>]
where uncooperative script is:
Taproot([Alice, Bob], ["1 week" CHECKSEQUENCEVERIFY DROP OP_COSHV <H(H(Pay
alice 2 coins))>)
Cooperative closing skips the extra transactions. Updates are signed
against the uncooperative script with repudation. E.g.:
HASH160 <revokehash> EQUAL
IF
<Bob's pubkey>
ELSE
"1 week" CHECKSEQUENCEVERIFY DROP
<Alice's pubkey>
ENDIF
CHECKSIG
It can even be optimized by letting the uncooperative script branches in
the leaf be blaming Alice or Bob.
Does that not work?
--000000000000fd54560589757fe4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)" class=3D"gmail_default"></div><br><br>> * I=
do not think CoinJoin is much improved by this opcode.<br><div>> =C2=A0=
Typically, you would sign off only if one of the outputs of the CoinJoin t=
ransaction is yours, and this does not really improve this situation.</div>=
<div><br></div><div><div style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Coinjoin benefits a=
lot I think.</div><br></div><br><div style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Coinjo=
in is improved because you can fit more users into the protocol and create =
many more outputs at lower cost or include more participants. Ideally a coi=
njoin creates a lot of outputs so that the ownership is smeared more, but t=
his has a cost at the time of the coinjoin.<br></div><div style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"g=
mail_default"><br></div><div style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Coinjoin is als=
o improved because you don't reveal the outputs created by the coinjoin=
until some time, perhaps very far in the future, when you need the coin. I=
n fact, you only need to reveal where you're moving the coins to partic=
ipants in your subtree because participants need only verify their branch.<=
br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D=
"gmail_default">It also makes the protocol more stable with respect to inpu=
t choice. This is because, similar to how NOINPUT may work, OP_COSHV output=
s are spendable without knowing what the TXID will be. Therefore if someone=
changes their input or non segwit spend script, it won't break the pre=
signed txns. This also means that all the inputs can be ANYONECANPAY, so th=
ere is no need to reveal your inputs before anyone else.</div><div style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" c=
lass=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">This c=
ulminates in being able to open channels from a coinjoin safely, I believe =
this is difficult/impossible to do currently.</div><div style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gma=
il_default"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div><b=
r></div><br>> * Using this for congestion control increases blockchain u=
sage by one TXO and one input, ending up with *more* bytes onchain, and a U=
TXO that will be removed later in (we hope) short time.<br><div>> =C2=A0=
I do not know if this is a good idea, to increase congestion by making unn=
ecessary intermediate transaction outputs, at times when congestion is a pr=
oblem.</div><div><br></div><div><div style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">This is=
a good idea because it improves QoS for most users.<br></div><div style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" c=
lass=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">For re=
ceiving money pending spendable but confirmed payment (i.e. certified check=
s) is superior to having unconfirmed funds.</div><div style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail=
_default"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)" class=3D"gmail_default">For sending money, =
being able to clear all liabilities in a single txn decreases business expo=
sure to fee variance and confirmation time variance. E.g., if I'm doing=
payroll in Bitcoin I will pay big fines if I am a day late. If I have 10,0=
00 employees this might be painful if fees are currently up.<br></div><div =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0=
,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default=
">It also helps to have a backlog of low priority txns to support the fee m=
arket.</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:=
small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default">Overall block bandwidth utilization is fairly spikey, so=
having long term well known outputs that are not time sensitive can be use=
d to better utilize bandwidth.<br></div></div><div><br></div><div><div styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)" class=3D"gmail_default">The total extra bandwidth btw is really small gi=
ven the expansion factor optimizations available.</div><br></div><br>> *=
I cannot find a way to implement Decker-Russell-Osuntokun (or any offchain=
update mechanism) on top of this opcode, so I cannot support replacing `SI=
GHASH_NOINPUT` with this opcode.<br><div>> =C2=A0 In particular, while t=
he finite loop support by this opcode appears (at first glance) to be useab=
le as the "stepper" for an offchain update mechanism, I cannot fi=
nd a good way to short-circuit the transaction chain without `SIGHASH_NOINP=
UT` anyway.</div><div><br></div><div><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">I&=
#39;m not deeply familiar with DRO channels. This opcode isn't a replac=
ement for SIGHASH_NOINPUT -- SIGHASH_NOINPUT is mentioned merely to contras=
t using SIGHASH_NOINPUT for the uses presented in this BIP. </div><div styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">La=
stly there's no 'replacing'. Neither NOINPUT nor COSHV are acce=
pted by the community at large yet, and they do different things.<br></div>=
<br></div><div><br></div>> * Channel factories created by this opcode do=
not, by themselves, support updates to the channel structure.<br><div>>=
=C2=A0 But such simple "close only" channel factories can be don=
e using n-of-n and a pre-signed offchain transaction (especially since the =
entities interested in the factory are known and enumerable, and thus can b=
e induced to sign in order to enter the factory).</div><div><br></div><div>=
<div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)" class=3D"gmail_default">I'm not really an expert at Bitcoin=
Lightning, but this basic mechanism should work. </div><br></div><div><div=
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(=
0,0,0)" class=3D"gmail_default">Imagine the script at a leaf node:<br></div=
></div><div><br></div><div><div style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Taproot([Ali=
ce, Bob], [OP_COSHV <H(H(2 coins to uncooperative script))>]<br></div=
></div><div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:=
small;color:rgb(0,0,0)" class=3D"gmail_default"></div><div style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"=
gmail_default">where uncooperative script is:</div><br><span class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)"></span>Taproot([Alice, Bob], ["<span class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:rgb(0,0,0)">1 week</span>" CHECKSEQUENCEVERIFY DROP<span class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)"> </span>OP_COSHV <H(H(Pay alice <span class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)">2 coins</span>))><span class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">)</span></div><div><br></div><div><div style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Coo=
perative closing skips the extra transactions. Updates are signed against t=
he uncooperative script with repudation. E.g.:</div><div style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gm=
ail_default"><br></div>=C2=A0 =C2=A0 HASH160 <revokehash> EQUAL<br>=
=C2=A0 =C2=A0 IF<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <Bob's pubkey><br=
>=C2=A0 =C2=A0 ELSE<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "<span class=3D"gma=
il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)">1 week</span><span class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"></span=
>" CHECKSEQUENCEVERIFY DROP<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <Alice&#=
39;s pubkey><br>=C2=A0 =C2=A0 ENDIF<br>=C2=A0 =C2=A0 CHECKSIG<div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">It =
can even be optimized by letting the uncooperative script branches in the l=
eaf be blaming Alice or Bob.<br></div><div style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><=
br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)" class=3D"gmail_default">Does that not work?<br></div><=
br></div></div>
--000000000000fd54560589757fe4--
|