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
|
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 719F9E7A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Dec 2018 15:37:25 +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 CB9AD177
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Dec 2018 15:37:24 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1545406632; cv=none; d=zoho.com; s=zohoarc;
b=jvW2ni5BfSCvlYxacasyT7g+cIGHBFCboKDt6cyniP/9jgsNOAVQYYETT8ry12OjJvHcIRTgApVe6xZvDagXIgTnmGXKKBV1FjdUPKGWtT/belbZ1r+D5c5SU1fyNu/VjrDaTU3oR4v0Bc9U/EXfpy5c+vRPagHopDZWTgXgGlo=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc; t=1545406632;
h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
bh=Z7ZmYzRIH7rN64Vktjyq+kC/C8q33ymPoNw1vh6y9OY=;
b=ZBZIcmGCaDe30EdNUVzQPPmt2rRWZPXDciTPbg9/lvVaV08kw7ki4awn8QEEZH56zYdI6gMwfTg5yfBzcfzZJGFfaHbQ6z4ECmIU7wiKTgiYyniHm1InVYHA9F+r5sDfzNST8K8srqDCU4bKM2ma5KxcTI9VxkLH6A0qOdhfCUc=
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] (n218103234118.netvigator.com [218.103.234.118])
by mx.zohomail.com with SMTPS id 1545406631564256.77185132031;
Fri, 21 Dec 2018 07:37:11 -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: <8z5NQkaOUo9z-wdBphQtZrxIf7OCtVQFvK3neMWvcRsngld5XJs-vt7CLuY46ZOp_pX8gEd92pMdkEkp8CUOMH9lUTw5ocWsbDPiaKdSa2I=@protonmail.com>
Date: Fri, 21 Dec 2018 23:37:05 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <34B38940-524D-42B9-8A67-6A62DCE04665@xbt.hk>
References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk>
<8z5NQkaOUo9z-wdBphQtZrxIf7OCtVQFvK3neMWvcRsngld5XJs-vt7CLuY46ZOp_pX8gEd92pMdkEkp8CUOMH9lUTw5ocWsbDPiaKdSa2I=@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.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,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: Fri, 21 Dec 2018 23:30:36 +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: Fri, 21 Dec 2018 15:37:25 -0000
> On 21 Dec 2018, at 7:40 PM, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>=20
> Good morning Johnson,
>=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
> First off, this is a very good idea I think.
>=20
>=20
>> While this seems fully compatible with eltoo, is there any other =
proposals require NOINPUT, and is adversely affected by either way of =
tagging?
>=20
>=20
> It prevents use of SIGHASH_NOINPUT to support walletless offchain =
protocols.
> =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015925.ht=
ml
> =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015926.ht=
ml
>=20
> In brief, this idea of "walletless offchain software" is motivated by =
the fact, that various onchain wallets exist with many features.
> For instance, privacy-enhancement as in Samourai/Wasabi/etc.
> And so on.
> There are requests to include such features in e.g. Lightning =
software, for example: =
https://github.com/ElementsProject/lightning/issues/2105
> But it is enough of a challenge to implement Lightning, without the =
additional burden of implementing nice onchain features like coin =
control and change labelling.
>=20
> It would be best if we can retain features from an onchain wallet, =
while using our coin on an offchain system.
> Further, it would allow onchain wallet developers to focus and gain =
expertise on onchain wallet features, and, vice versa, for offchain =
walletless software developers to focus on offchain software features.
>=20
> The core idea comes from the way that offchain systems need to be set =
up:
>=20
> 1. First we agree on a (currently unconfirmed) txid and output number =
on which to anchor our offchain system (the funding transaction).
> 2. Then we sign a backout transaction (the initial commitment =
transactions under Poon-Dryja, or the timelock branches for CoinSwapCS, =
or the initial kickoff-settlement transactions for =
Decker-Russell-Osuntokun) spending the agreed TXO, to return the money =
back to the owner(s) in case some participant aborts the setting up of =
the offchain system.
> 3. Then we sign and broadcast the funding transaction.
>=20
> Unfortunately, the typical onchain wallet has a very simple and atomic =
(uncuttable) process for making transactions:
>=20
> 1. Make, sign, and broadcast transaction with an output paying to the =
desired address.
>=20
> Thus a typical onchain wallet cannot be used to set up a funding =
transaction for an offchain system.
>=20
> Now suppose we take advantage of `SIGHASH_NOINPUT`, and modify our =
offchain system setup as below:
>=20
> 1. First we agree on a N-of-N pubkey on which to anchor our offchain =
system (the funding address).
> 2. Then we sign (with SIGHASH_NOINPUT) a backout transaction (the =
initial commitment transactions under Poon-Dryja, or the timelock =
branches for CoinSwapCS, or the initial kickoff-settlement transactions =
for Decker-Russell-Osuntokun), spending the agreed funding address, to =
return the money back to the owner(s) in case some participant aborts =
the setting up of the offchain system.
> 3. Make, sign, and broadcast transaction with an output paying to the =
funding address. This step can be done by any typical onchain wallet.
>=20
> Note that only the starting backout transaction is *required* to sign =
with `SIGHASH_NOINPUT`.
> For instance, a Poon-Dryja channel may sign succeeding commitment =
transactions with `SIGHASH_ALL`.
> Finally, only in case of disaster (some participant aborts before the =
offchain system is set up) is the `SIGHASH_NOINPUT` backoff transaction =
broadcasted.
> A "normal close" of the offchain system can be signed with typical =
`SIGHASH_ALL` for no fungibility problems.
>=20
> With this, an offchain system need not require its implementing =
software to implement its own wallet.
> Further, onchain wallets can directly put its funds into an offchain =
system, without requiring an onchain transfer to an offchain software =
wallet.
>=20
> This can be helpful when building overall software.
> We might take any commodity onchain wallet and any commodity offchain =
software, and we can integrate them easily to create a seamless wallet =
experience that allows spending and receiving onchain and offchain.
> Further, improvements in one software component do not require =
re-building of the other software component.
>=20
> --
>=20
> That said:
>=20
> 1. For Lightning and similar systems, the fact that the Lightning =
node will give you an address that, when paid using any commodity =
onchain wallet, opens a channel, means that people will make wrong =
assumptions.
> In particular, they are likely to assume that address reuse is safe =
and will attempt to "refill" their channel by paying to the same address =
again in the future.
> =46rom this alone, we can immediately see that this idea is =
pointless.
> 2. Dual-funding, which for some reason is asked for as a feature, =
cannot be done with this anyway.
> 3. It may be better to provide some standard way of signing =
transactions without broadcasting them.
> This would still allow similar separation of concerns between =
onchain and offchain software components.
>=20
> So output tagging still seems fine to me, even if this particular use =
cannot be supported.
>=20
> Regards,
> ZmnSCPxj
>=20
>=20
Generally speaking, I think walletless protocol is needed only when you =
want to rely a third party to open a offchain smart contract. It could =
be coinswap, eltoo, or anything similar.
However, since NOINPUT still commits to the input value, if the third =
party paid an unexpected value, even off by 1 satoshi, the smart =
contract is toast. It is not uncommon as some exchanges would deduct =
fees from withdrawal amount. Since we don=E2=80=99t have a social norm =
to require the payer to always pay the exact requested amount, the =
exchange might not be liable for the loss.
It is of course possible to have a NOINPUT_NOAMOUNT, but I can=E2=80=99t =
see any chance for this being accepted.
So, unless the payer is liable for paying a wrong amount, walletless =
contract opening is unreliable.
Johnson=
|
