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
|
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 2CFD88EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Dec 2018 11:40:14 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
[185.70.40.136])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 327B1177
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Dec 2018 11:40:12 +0000 (UTC)
Date: Fri, 21 Dec 2018 11:40:06 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1545392410;
bh=T1fQ6aiOJiiYfe9q5SHdPXh3e+7YeYpHWBCJBJIdCLo=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=D/TPV7PPLsOeqv2v3BmSvI0JTL4Ee4SiL35HYiZyuZPpzz/muC1W2e7UL6e5YPpa3
bzGXRjDTPWMzGqmHp2K34cHe/117Y0yf5wOiDuijTxCP55xojqp4ahW0BeSS7iSQs5
/8NK6uEe8BhUFTRmUDrYx7hKEaDC1zzISFlEF8i8=
To: Johnson Lau <jl2012@xbt.hk>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <8z5NQkaOUo9z-wdBphQtZrxIf7OCtVQFvK3neMWvcRsngld5XJs-vt7CLuY46ZOp_pX8gEd92pMdkEkp8CUOMH9lUTw5ocWsbDPiaKdSa2I=@protonmail.com>
In-Reply-To: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk>
References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk>
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=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW 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:29:55 +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: Fri, 21 Dec 2018 11:40:14 -0000
Good morning Johnson,
> 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 taggi=
ng:
First off, this is a very good idea I think.
> While this seems fully compatible with eltoo, is there any other prop=
osals require NOINPUT, and is adversely affected by either way of tagging?
It prevents use of SIGHASH_NOINPUT to support walletless offchain protocols=
.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015925.htm=
l
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015926.htm=
l
In brief, this idea of "walletless offchain software" is motivated by the f=
act, 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 additio=
nal burden of implementing nice onchain features like coin control and chan=
ge labelling.
It would be best if we can retain features from an onchain wallet, while us=
ing our coin on an offchain system.
Further, it would allow onchain wallet developers to focus and gain experti=
se on onchain wallet features, and, vice versa, for offchain walletless sof=
tware developers to focus on offchain software features.
The core idea comes from the way that offchain systems need to be set up:
1. First we agree on a (currently unconfirmed) txid and output number on w=
hich 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 participa=
nt aborts the setting up of the offchain system.
3. Then we sign and broadcast the funding transaction.
Unfortunately, the typical onchain wallet has a very simple and atomic (unc=
uttable) process for making transactions:
1. Make, sign, and broadcast transaction with an output paying to the desi=
red address.
Thus a typical onchain wallet cannot be used to set up a funding transactio=
n for an offchain system.
Now suppose we take advantage of `SIGHASH_NOINPUT`, and modify our offchain=
system setup as below:
1. First we agree on a N-of-N pubkey on which to anchor our offchain syste=
m (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 Coin=
SwapCS, or the initial kickoff-settlement transactions for Decker-Russell-O=
suntokun), spending the agreed funding address, to return the money back to=
the owner(s) in case some participant aborts the setting up of the offchai=
n system.
3. Make, sign, and broadcast transaction with an output paying to the fund=
ing address. This step can be done by any typical onchain wallet.
Note that only the starting backout transaction is *required* to sign with =
`SIGHASH_NOINPUT`.
For instance, a Poon-Dryja channel may sign succeeding commitment transacti=
ons with `SIGHASH_ALL`.
Finally, only in case of disaster (some participant aborts before the offch=
ain system is set up) is the `SIGHASH_NOINPUT` backoff transaction broadcas=
ted.
A "normal close" of the offchain system can be signed with typical `SIGHASH=
_ALL` for no fungibility problems.
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.
This can be helpful when building overall software.
We might take any commodity onchain wallet and any commodity offchain softw=
are, and we can integrate them easily to create a seamless wallet experienc=
e that allows spending and receiving onchain and offchain.
Further, improvements in one software component do not require re-building =
of the other software component.
--
That said:
1. For Lightning and similar systems, the fact that the Lightning node wil=
l give you an address that, when paid using any commodity onchain wallet, o=
pens 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.
From 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 b=
e done with this anyway.
3. It may be better to provide some standard way of signing transactions w=
ithout broadcasting them.
This would still allow similar separation of concerns between onchain a=
nd offchain software components.
So output tagging still seems fine to me, even if this particular use canno=
t be supported.
Regards,
ZmnSCPxj
|
