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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 41EF7F22
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 03:45:47 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
[185.70.40.133])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0666E5D0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 03:45:45 +0000 (UTC)
Date: Thu, 23 May 2019 03:45:39 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1558583143;
bh=8aNYDKIMxpTzvD5nRmJyevsq+mpCAXZfCMgVl/hMQbY=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=s27eU7QO8V1nIX5epW7GDyfn05Ygg/PxiqOrLrkDEYtwF+2JG/lvj84inGRphzozg
NaMZrKZPljg1B2F7572GWKlTzdgNou8iE1/BTzRYuAUDMQakS8gV4OfY3c763Q825z
I/0/qQhb3WUAqVRnt1+cCjTuoCllwTHJSsgjOtf8=
To: Jeremy <jlrubin@mit.edu>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <vbL4Nj9knpm6GMzS3wfTOcDPz9F6RoStna3mDwgJmmvYa1mPWa62x_atF3kBXjajlTDIxerTsYRr5pzI3xC3eSM_ssffsrXESqoNqMSg2h4=@protonmail.com>
In-Reply-To: <CAD5xwhiHHemzaRLC7WMeXQ5hgu0rwMKMUym34xTxWO81qqf-oQ@mail.gmail.com>
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>
<CAD5xwhiHHemzaRLC7WMeXQ5hgu0rwMKMUym34xTxWO81qqf-oQ@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW, URI_NOVOWEL 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: Thu, 23 May 2019 13:31:42 +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: Thu, 23 May 2019 03:45:47 -0000
Good morning Jeremy,
Sent with ProtonMail Secure Email.
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Wednesday, May 22, 2019 4:10 PM, Jeremy <jlrubin@mit.edu> wrote:
> > * I do not think CoinJoin is much improved by this opcode.
> > =C2=A0 Typically, you would sign off only if one of the outputs of the =
CoinJoin transaction is yours, and this does not really improve this situat=
ion.
>
> 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. Ideal=
ly a coinjoin creates a lot of outputs so that the ownership is smeared mor=
e, but this has a cost at the time of the coinjoin.
But the separate outputs still need to be published at some point in the fu=
ture.
Further, ideally CoinJoin should be as indistinguishable from normal transa=
ctions as possible.
(admittedly, the equal-sized outputs often recommended for CoinJoin tend to=
blatantly signal "this is a CoinJoin!!", but in any case that "should" be =
fixed with some kind of future Confidential Transactions)
>
> 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 nee=
d 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.
The same technique of congestion control can still be used with only an "or=
dinary" MuSig of all participant keys on the output of the "funding" transa=
ction, forming a sort of very tiny CoinJoinXT.
This has the advantage that the MuSig is indistinguishable from 1-of-1 spen=
ds, which is important for a privacy technique like CoinJoin.
Even in the future and we have published the output-side transaction of the=
CoinJoin, the transaction chain *could* be interpreted as "one person cons=
olidated all his coins in an ordinary 1-of-1 UTXO, then spent on several th=
ings at once" whereas use of the `OP_CHECKOUTPUTSHASHVERIFY` is a blatant "=
several people agreed to put in their coins provided these outputs were on =
the second transaction, i.e. some kind of attempt at hiding their coins".
>
> 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 spendabl=
e 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.
This is already *technically* possible, though no software exists to do so =
(sorry, we have bugs between interop of c-lightning and lnd that take up ou=
r debugging time already, we cannot spare it for this *yet*).
SegWit by itself already allows child transactions to be signed before pare=
nt transactions are signed.
This safety underlies *all* offchain protocols.
See: https://zmnscpxj.github.io/offchain/generalized.html
This is sufficient to ensure that channels can be opened from whatever tran=
sactions you want, though having to interop with other software that *also*=
has to coordinate with other participants in a different protocol is much =
more difficult than having to interop with other software using the same pr=
otocol.
Finally, `SIGHASH_ANYPREVOUT` can *also* do this, since the txid becomes mo=
oted.
And `SIGHASH_ANYPREVOUT` *also* enables a better offchain update mechanism =
(Decker-Russell-Osuntokun, more commonly known as "eltoo") whereas I am una=
ble to derive a similar offchain update mechanism using `OP_CHECKOUTPUTSHAS=
HVERIFY` (though possibly for lack of trying).
>
> > * Using this for congestion control increases blockchain usage by one T=
XO and one input, ending up with *more* bytes onchain, and a UTXO that will=
be removed later in (we hope) short time.
> > =C2=A0 I do not know if this is a good idea, to increase congestion by =
making unnecessary intermediate transaction outputs, at times when congesti=
on 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. certifi=
ed checks) is superior to having unconfirmed funds.
>
> For sending money, being able to clear all liabilities in a single txn de=
creases 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 lat=
e. If I have 10,000 employees this might be painful if fees are currently u=
p.
>
> It also helps to have a backlog of low priority txns to support the fee m=
arket.
>
> Overall block bandwidth utilization is fairly spikey, so having long term=
well known outputs that are not time sensitive can be used to better utili=
ze bandwidth.
>
> The total extra bandwidth btw is really small given the expansion factor =
optimizations available.
Okay, you have convinced me regarding this point, at least.
> > * Channel factories created by this opcode do not, by themselves, suppo=
rt updates to the channel structure.
> > =C2=A0 But such simple "close only" channel factories can be done using=
n-of-n and a pre-signed offchain transaction (especially since the entitie=
s interested in the factory are known and enumerable, and thus can be induc=
ed to sign in order to enter the factory).
>
> I'm not really an expert at Bitcoin Lightning, but this basic mechanism s=
hould 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(P=
ay alice 2 coins))>)
>
> Cooperative closing skips the extra transactions. Updates are signed agai=
nst the uncooperative script with repudation. E.g.:
>
> =C2=A0 =C2=A0 HASH160 <revokehash> EQUAL
> =C2=A0 =C2=A0 IF
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <Bob's pubkey>
> =C2=A0 =C2=A0 ELSE
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "1 week" CHECKSEQUENCEVERIFY DROP
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <Alice's pubkey>
> =C2=A0 =C2=A0 ENDIF
> =C2=A0 =C2=A0 CHECKSIG
>
> It can even be optimized by letting the uncooperative script branches in =
the leaf be blaming Alice or Bob.
>
> Does that not work?
Possibly, but the point is that an n-of-n MuSig will work just as well and =
we would not need to reveal the Taproot key (33 bytes) and the specific scr=
ipt containing the output hash (1+32 bytes) we want, we just have to reveal=
a single 64-byte signature.
My objection here is simply that n-of-n already exists, it will work alread=
y using that (and it is much more likely to be assured of getting into base=
layer).
Again, we only need to use SegWit and sign transactions in reverse order to=
ensure proper operation.
This is already what is done for normal channel opens (the initial commitme=
nt transactions are signed first, then the funding transaction is signed an=
d confirmed onchain).
Regards,
ZmnSCPxj
|
