summaryrefslogtreecommitdiff
path: root/7b/b4432939f6ff03bce046f63ed87c71601773a0
blob: 36ec7cc44dab3f1944f184d66bf639644e0319c2 (plain)
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
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 785EDCDDE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  9 Feb 2019 17:44:18 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 67A82F4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  9 Feb 2019 17:44:16 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1549734255; cv=none; d=zoho.com; s=zohoarc; 
	b=CPhQ9R7MSfZdKSQBaKA68oDM9CbK8uEF5KLL0XRMAfSIUDkv8ol+vO3cJl3yTPokBP0VqkNzvYbZLkoyOY9xw9AsgagIH5UXL7TYkrncQydo0dNjXJGwaPEcdrbg/xFDg9TZjK8/WtjtcmYMi8nfl46NBeB+waeIHEoZJNyr2tc=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
	s=zohoarc; t=1549734255;
	h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
	bh=8YonJKITK67jS+nNn8kSxPTXEn2LDz9yb0kesCIXBFo=; 
	b=YttmMNEsrgA9gxiZBnouxFnxdxLnonukrNcvcjCnJwBGRnog+8uBqYppquzAHSISkIvnenMyXd3HaiyFxd9bOfj7rPhDYbBHP6+nC7P3MAClv77HQD7oip8V59UfrdWGLWvmL3+bf0qtrm6b5XaOxe02AnVDGFcsfs2Q6jnV98M=
ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass  header.i=xbt.hk;
	spf=pass  smtp.mailfrom=jl2012@xbt.hk;
	dmarc=pass header.from=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk>
Received: from [10.8.0.105] (pcd687179.netvigator.com [218.102.219.179]) by
	mx.zohomail.com with SMTPS id 1549734252609906.235060406095;
	Sat, 9 Feb 2019 09:44:12 -0800 (PST)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <3567673f-e12b-c107-2a33-0b23b5518c96@gmail.com>
Date: Sun, 10 Feb 2019 01:43:50 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <BF34D0BD-A0EF-4F9F-81B7-66965BDC81E4@xbt.hk>
References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk>
	<9bae18fa-3266-61ce-0b62-6ee429198260@gmail.com>
	<FB1FBB2C-D202-4583-B596-F746E20AFD3E@xbt.hk>
	<3567673f-e12b-c107-2a33-0b23b5518c96@gmail.com>
To: Jonas Nick <jonasdnick@gmail.com>
X-Mailer: Apple Mail (2.3445.100.39)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,MIME_QP_LONG_LINE,
	RCVD_IN_DNSWL_NONE 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: Sat, 09 Feb 2019 18:49:52 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer NOINPUT with output tagging
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: Sat, 09 Feb 2019 17:44:18 -0000

And this scheme could be generalised to the combinatorial settlement =
model in my earlier post.

Let=E2=80=99s say the settlement tx has 3 outputs: (A&B),(B&C),(A&C). =
There will be 4 versions of this tx:

tx-X: all 3 outputs are tagged, signed by all 3 parties
tx-Y-AB: output (A&B) is untagged, the other 2 outputs are tagged. =
Signed only by C
tx-Y-AC: output (A&C) is untagged, the other 2 outputs are tagged. =
Signed only by B
tx-Y-BC: =E2=80=A6=E2=80=A6=E2=80=A6

All 4 txs will have the same relative-lock-time

If C is missing at the time of settlement, A and B will settle upon =
tx-Y-AB with a simple signature

If B and C are missing, A will settle upon tx-X

However, I think this is just an overkill, and hardly improves =
fungibility. It is very clear that this is an uncooperative eltoo =
closing (due to the update tx of the main channel), and this is a =
multi-party channel (due to multiple settlement outputs). There is =
little doubt that the remaining parties would like to continue trading. =
So there is actually no secret to hide, and it might be easier to just =
tag all outputs

Nonetheless, this example shows that the fungibility impact of output =
tagging is quite manageable. Most likely you just need to prepare more =
versions of intermediate txs, and only use the tagged one when things go =
against you.

> On 10 Feb 2019, at 12:52 AM, Jonas Nick <jonasdnick@gmail.com> wrote:
>=20
> Johnson's modification solves the issue I pointed out.
>=20
> Moreover, as Johnson and I discussed in private, using different =
locktimes for
> X and Y is not necessary. They can have the same relative locktime. If =
A and B
> would only sign Y as soon as the update tx is confirmed, there is no =
risk of Y
> changing its txid and therefore invalidating updates built on it.
>=20
>=20
> On 2/9/19 10:15 AM, Johnson Lau wrote:
>> This is really interesting. If I get it correctly, I think the =
fungibility hit could be avoided, just by making one more signature, and =
not affecting the blockchain space usage.
>>=20
>> Just some terminology first. In a 3-party channel, =E2=80=9Cmain =
channel=E2=80=9D means the one requires all parties to update, and =
=E2=80=9Cbranch channel=E2=80=9D requires only 2 parties to update.
>>=20
>> By what you describe, I think the most realistic scenario is =E2=80=9CC=
 is going to offline soon, and may or may not return. So the group wants =
to keep the main channel open, and create a branch channel for A and B, =
during the absence of C=E2=80=9D. I guess this is what you mean by being =
able to "predict in advance who will become absent=E2=80=9D
>>=20
>> I call this process as =E2=80=9Csemi-cooperative channel closing=E2=80=9D=
 (SCCC). During a SCCC, the settlement tx will have 2 outputs: one as (A =
& B), one as (C). Therefore, a branch channel could be opened with the =
(A & B) output. The channel opening must use NOINPUT signature, since we =
don=E2=80=99t know the txid of the settlement tx. With the output =
tagging requirement, (A & B) must be tagged, and lead to the fungibility =
loss you described.
>>=20
>> However, it is possible to make 2 settlement txs during SCCC. Outputs =
of the settlement tx X are tagged(A&B) and C. Outputs of the settlement =
tx Y are untagged(A&B) and C. Both X and Y are BIP68 =
relative-time-locked, but Y has a longer time lock.
>>=20
>> The branch channel is opened on top of the tagged output of tx X. If =
A and B want to close the channel without C, they need to publish the =
last update tx of the main channel. Once the update tx is confirmed, its =
txid becomes permanent, so are the txids of X and Y. If A and B decide =
to close the channel cooperatively, they could do it on top of the =
untagged output of tx Y, without using NOINPUT. There won=E2=80=99t be =
any fungibility loss. Other people will only see the uncooperative =
closing of the main channel, and couldn=E2=80=99t even tell the number =
of parties in the main channel. Unfortunately, the unusual long lock =
time of Y might still tell something.
>>=20
>> If anything goes wrong, A or B could publish X before the lock time =
of Y, and settle it through the usual eltoo style. Since this is an =
uncooperative closing anyway, the extra fungibility loss due to tagging =
is next to nothing. However, it may suggest that the main channel was a =
multi-party one.
>>=20
>> For C, the last update tx of the main channel and the settlement tx Y =
are the only things he needs to get the money back. C has to sign tx X, =
but he shouldn=E2=80=99t get the complete tx X. Otherwise, C might have =
an incentive to publish X in order to get the money back earlier, at the =
cost of fungibility loss of the branch channel.
>>=20
>> To minimise the fungibility loss, we=E2=80=99d better make it a =
social norm: if you sign your tx with NOINPUT, always try to make all =
outputs tagged to be NOINPUT-spendable. (NOTE: you can still spend =
tagged outputs with normal signatures, so this won=E2=80=99t permanently =
taint your coins as NOINPUT-spendable) It makes sense because the use of =
NOINPUT signature strongly suggests that you don=E2=80=99t know the txid =
of the parent tx, so you may most likely want your outputs to be =
NOINPUT-spendable as well. I thought of making this a policy or =
consensus rule, but may be it=E2=80=99s just overkill.
>>=20
>>=20
>>=20
>>> On 9 Feb 2019, at 3:01 AM, Jonas Nick <jonasdnick@gmail.com> wrote:
>>>=20
>>> Output tagging may result in reduced fungibility in multiparty eltoo =
channels.
>>> If one party is unresponsive, the remaining participants want to =
remove
>>> the party from the channel without downtime. This is possible by =
creating
>>> settlement transactions which pay off the unresponsive party and =
fund a new
>>> channel with the remaining participants.
>>>=20
>>> When the party becomes unresponsive, the channel is closed by =
broadcasting the
>>> update transaction as usual. As soon as that happens the remaining
>>> participants can start to update their new channel. Their update =
signatures
>>> must use SIGHASH_NOINPUT. This is because in eltoo the settlement =
txid is not
>>> final (because update tx is not confirmed and may have to rebind to =
another
>>> output). Therefore, the funding output of the new channel must be =
NOINPUT
>>> tagged. Assuming the remaining parties later settle cooperatively, =
this loss
>>> of fungibility would not have happened without output tagging.
>>>=20
>>> funding output          update output                                =
    settlement outputs              update output
>>> [ A & B & C ] -> ... -> [ (A & B & C & state CLTV) | (As & Bs & Cs) =
] -> [ NOINPUT tagged: (A' & B'), -> ...
>>>                                                                      =
    C' ]
>>> If the expectation is that the unresponsive party returns, =
fungibility is
>>> not reduced due to output tagging because the above scheme can be =
used
>>> off-chain until the original channel can be continued.
>>>=20
>>> Side note: I was not able to come up with an similar, eltoo-like =
protocol that works
>>> if you can't predict in advance who will become absent.
>>>=20
>>> On 12/13/18 12:32 PM, Johnson Lau via bitcoin-dev wrote:
>>>> NOINPUT is very powerful, but the tradeoff is the risks of =
signature replay. While the key holders are expected not to reuse key =
pair, little could be done to stop payers to reuse an address. =
Unfortunately, key-pair reuse has been a social and technical norm since =
the creation of Bitcoin (the first tx made in block 170 reused the =
previous public key). I don=E2=80=99t see any hope to change this norm =
any time soon, if possible at all.
>>>>=20
>>>> As the people who are designing the layer-1 protocol, we could =
always blame the payer and/or payee for their stupidity, just like those =
people laughed at victims of Ethereum dumb contracts (DAO, Parity =
multisig, etc). The existing bitcoin script language is so restrictive. =
It disallows many useful smart contracts, but at the same time prevented =
many dumb contracts. After all, =E2=80=9Csmart=E2=80=9D and =E2=80=9Cdumb=E2=
=80=9D are non-technical judgement. The DAO contract has always been =
faithfully executed. It=E2=80=99s dumb only for those invested in the =
project. For me, it was just a comedy show.
>>>>=20
>>>> So NOINPUT brings us more smart contract capacity, and at the same =
time we are one step closer to dumb contracts. The target is to find a =
design that exactly enables the smart contracts we want, while =
minimising the risks of misuse.
>>>>=20
>>>> The risk I am trying to mitigate is a payer mistakenly pay to a =
previous address with the exactly same amount, and the previous UTXO has =
been spent using NOINPUT. Accidental double payment is not uncommon. =
Even if the payee was honest and willing to refund, the money might have =
been spent with a replayed NOINPUT signature. Once people lost a =
significant amount of money this way, payers (mostly exchanges) may =
refuse to send money to anything other than P2PKH, native-P2WPKH and =
native-P2WSH (as the only 3 types without possibility of NOINPUT)
>>>>=20
>>>> The proposed solution is that an output must be =E2=80=9Ctagged=E2=80=
=9D for it to be spendable with NOINPUT, and the =E2=80=9Ctag=E2=80=9D =
must be made explicitly by the payer. There are 2 possible ways to do =
the tagging:
>>>>=20
>>>> 1. A certain bit in the tx version must be set
>>>> 2. A certain bit in the scriptPubKey must be set
>>>>=20
>>>> I will analyse the pros and cons later.
>>>>=20
>>>> Using eltoo as example. The setup utxo is a simple 2-of-2 multisig, =
and should not be tagged. This makes it indistinguishable from normal =
1-of-1 utxo. The trigger tx, which spends the setup utxo, should be =
tagged, so the update txs could spend the trigger utxo with NOINPUT. =
Similarly, all update txs should be tagged, so they could be spent by =
other update txs and settlement tx with NOINPUT. As the final =
destination, there is no need to tag in the settlement tx.
>>>>=20
>>>> In payer=E2=80=99s perspective, tagging means =E2=80=9CI believe =
this address is for one-time-use only=E2=80=9D Since we can=E2=80=99t =
control how other people manage their addresses, we should never do =
tagging when paying to other people.
>>>>=20
>>>> I mentioned 2 ways of tagging, and they have pros and cons. First =
of all, tagging in either way should not complicate the eltoo protocol =
in anyway, nor bring extra block space overhead.
>>>>=20
>>>> A clear advantage of tagging with scriptPubKey is we could tag on a =
per-output basis. However, scriptPubKey tagging is only possible with =
native-segwit, not P2SH. That means we have to disallow NOINPUT in =
P2SH-segwit (Otherwise, *all* P2SH addresses would become =E2=80=9Crisky=E2=
=80=9D for payers) This should be ok for eltoo, since it has no reason =
to use P2SH-segwit in intermediate txs, which is more expensive.
>>>>=20
>>>> Another problem with scriptPubKey tagging is all the existing =
bech32 implementations will not understand the special tag, and will pay =
to a tagged address as usual. An upgrade would be needed for them to =
refuse sending to tagged addresses by default.
>>>>=20
>>>> On the other hand, tagging with tx version will also protect =
P2SH-segwit, and all existing wallets are protected by default. However, =
it is somewhat a layer violation and you could only tag all or none =
output in the same tx. Also, as Bitcoin Core has just removed the tx =
version from the UTXO database, adding it back could be a little bit =
annoying, but doable.
>>>>=20
>>>> There is an extension to the version tagging, which could make =
NOINPUT even safer. In addition to tagging requirement, NOINPUT will =
also sign the version of the previous tx. If the wallet always uses a =
randomised tx version, it makes accidental replay very unlikely. =
However, that will burn a few more bits in the tx version field.
>>>>=20
>>>> While this seems fully compatible with eltoo, is there any other =
proposals require NOINPUT, and is adversely affected by either way of =
tagging?
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>=20
>>=20
>>=20