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
|
Return-Path: <a.ranchalpedrosa@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A3675CA66
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 9 Feb 2019 10:01:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com
[209.85.128.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7ADA0F4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 9 Feb 2019 10:01:24 +0000 (UTC)
Received: by mail-wm1-f44.google.com with SMTP id q21so7547099wmc.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 09 Feb 2019 02:01:24 -0800 (PST)
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-transfer-encoding:content-language;
bh=johchYb7P84m22QYRBu8fUyI7yyjYzjcI7PxXdv/U80=;
b=sVwk9KSlp210UyJiA6w5ZK9m5OgMTvlCj8vcFeDmoV7bOH/oyeNUUsETfZbCUhe84e
xWmTClpdwIHWOOr/YvfP+2Q7pdePapNUKU4bDSVFgUikCbqmWQEZ8Qm1Hw32BUQLjLBk
hWVyRrvUZo5vQKDA+Q4FfWZaggBHwDTIBA0UxumO5qfSIb+xTB9rO1mN4ZHfHMIbIo08
BnDv60iZbVqaoj87eMhfhrLcdRHf3rrpKc3jq5D2hO1njpFZYm28OcJ3l5fHhyNvGToP
4Y+bpa7U1LzuzDAzqWBjbjpzsbKTNuac49ZRArctpfIiuiMa8UqSv4zW7VnMyzqJe+qq
Fs+Q==
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-transfer-encoding
:content-language;
bh=johchYb7P84m22QYRBu8fUyI7yyjYzjcI7PxXdv/U80=;
b=QyJyppsGfm6D7LgdKgS+jQKXR6N+LD7vFUEx+UbA/vqgNHpAYdtpgyhA8VgygvAD3H
tLtuASQwXjCvjNTF/e1NHmVh0cuZJ93kH+xX4MbC8t69qtW6OdlskZ91yhwY1iLWH9RZ
p7XsuII0qwSMksJTkeVZc3mm+hrtvwwyp+eIhz4Nps7Ni2tByDfAekk6gUkBT0ib1+0e
slQoj5gCsqYqrOEssQX1jNz6gEYxFSK5H4d2fj3fqTv5heZZmNAJ4kdQKTyZuRNQycoh
ogtaFEghG6ESV5rsv+w9hsrT/Sc/ISfq5k/sE06Sd5OSRd4AeXHZanSRlKK2mXFIPlvq
B30w==
X-Gm-Message-State: AHQUAua8h1A8mSB482mlWe9BxZI362WdCzVFfHK53K9oHQe6FTL4nJBI
JBp7UhG1Oy5WnAcQIEqB5j8dPFAsgs8=
X-Google-Smtp-Source: AHgI3Ib3cJvjN5TGqPfGswanZF6DYUXzy5CVvOK1KtYSyN3uJKdRBH656rYEYxf+a80ifv4gF5VMog==
X-Received: by 2002:a1c:7f0c:: with SMTP id a12mr2107499wmd.89.1549706482434;
Sat, 09 Feb 2019 02:01:22 -0800 (PST)
Received: from [192.168.1.71] (119.red-79-150-227.dynamicip.rima-tde.net.
[79.150.227.119]) by smtp.googlemail.com with ESMTPSA id
f130sm9140701wme.41.2019.02.09.02.01.21
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 09 Feb 2019 02:01:21 -0800 (PST)
To: bitcoin-dev@lists.linuxfoundation.org
References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk>
<9bae18fa-3266-61ce-0b62-6ee429198260@gmail.com>
From: Alejandro Ranchal Pedrosa <a.ranchalpedrosa@gmail.com>
Message-ID: <dceb1831-9bc7-eae7-fdf2-c907701c0efe@gmail.com>
Date: Sat, 9 Feb 2019 11:01:20 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <9bae18fa-3266-61ce-0b62-6ee429198260@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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 14:48:51 +0000
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 10:01:25 -0000
Hi all,
>
> 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.
>
An eltoo-like protocol that works (without going on-chain) if you can't
predict in advance who will become absent would be a childchain. If the
off-chain protocol can continue updating in the abscence of other
parties, it means that other parties' signatures must not be required
when they are not involved in the off-chain state update. If other
parties' signatures must not be required, there must be a way of having
a common verifiable 'last state' to prevent a party to simultaneously
'fork' the state with two different parties, and double-spend. A
solution for this is a childchain for Bitcoin. An example of this is
what is known as a 'Broken Factory' attack [1]
(https://bitcoin.stackexchange.com/questions/77434/how-does-channel-factory-act/81005#81005)
> 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.
I believe that in many cases other parties won't be able to continue
until the unresponsive parties go back online. That might be true in
particular scenarios, but generally speaking, the party might have gone
unresponsive during a factory-level update (i.e. off-chain closing and
opening of channels), while some parties might have given out their
signature for the update without receiving a fully signed transaction.
In this case they do not even know which channel they have open (the one
of the old state that they have fully signed, or the one for the new
state that they have given out their signature for). This is known as a
'Stale Factory', and can be exploited by an adversary in a 'Stale
Factory' attack [1]. Even if they knew which state they are in (i.e. the
party went unresponsive but not during a factory-level update), some of
them might have run out of funds in some of their channels of the
factory, and might want to update, while they will not be willing to
wait for a party to go back online (something for which they also have
zero guarantees of).
An eltoo-like protocol that works (allowing going on-chain) if you can't
in advance who will become absent, then this is precisely why
'Transaction Fragments' have been suggested. They allow an eltoo-like
protocol even when one cannot predict in advance who will become absent,
or malicious (by publishing invalid states), cause the non-absent
parties can unite their fragments and create a valid spendable
factory-level transaction that effectively kicks out the malicious
parties, while leaving the rest of the factory as it was. To the best of
my understanding, the eltoo original proposal also allows this though.
Best,
Alejandro.
[1]: Scalable Lightning Factories for Bitcoin,
https://eprint.iacr.org/2018/918.pdf
On 08/02/2019 20:01, Jonas Nick via bitcoin-dev wrote:
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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’t see any hope to change this norm any time soon, if possible at all.
>>
>> 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, “smart” and “dumb” are non-technical judgement. The DAO contract has always been faithfully executed. It’s dumb only for those invested in the project. For me, it was just a comedy show.
>>
>> 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.
>>
>> 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)
>>
>> The proposed solution is that an output must be “tagged” for it to be spendable with NOINPUT, and the “tag” must be made explicitly by the payer. There are 2 possible ways to do the tagging:
>>
>> 1. A certain bit in the tx version must be set
>> 2. A certain bit in the scriptPubKey must be set
>>
>> I will analyse the pros and cons later.
>>
>> 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.
>>
>> In payer’s perspective, tagging means “I believe this address is for one-time-use only” Since we can’t control how other people manage their addresses, we should never do tagging when paying to other people.
>>
>> 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.
>>
>> 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 “risky” for payers) This should be ok for eltoo, since it has no reason to use P2SH-segwit in intermediate txs, which is more expensive.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
