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
|
Return-Path: <jonasdnick@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 95859C73C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Feb 2019 19:01:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com
[209.85.128.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 93C3C1FB
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Feb 2019 19:01:43 +0000 (UTC)
Received: by mail-wm1-f47.google.com with SMTP id h22so7552188wmb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 08 Feb 2019 11:01:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:subject:to:references:openpgp:autocrypt:message-id:date
:user-agent:mime-version:in-reply-to:content-language
:content-transfer-encoding;
bh=hLV/DU5oR/Lkguijyns3/nuAhaMpNuvUqDu2JuK35t4=;
b=kztDP93nht5EKlUrPL+MBp83+yPnF+0WUUTaWHHUWxyUYPSwEWjjoisU94J0o09yam
eZtp5QkKXHpi3AkeoLnunsIjn9BR73ozSZxGTZW5Awqtp26MO+qdGrDr4EE5WKd894Oj
QMXsOMPDCCwotg77V4pbq2ilrVpKl5UeeWyzf4+do1nm5h1tt+s86F69rsk9zysyD4u8
1H2QGkKzqnU8X5YFzqsWX+ICFEYYCp4pt5nbF0S/gL3daHRUdwT0+rN72se0IhaT0fMx
rvznf8RHnNMxsNYoyD3jbGSyI9xkyxVlD+z+KKg5GAhaKMZrqq/a6MD237a50Ci2gB5P
fBBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:subject:to:references:openpgp:autocrypt
:message-id:date:user-agent:mime-version:in-reply-to
:content-language:content-transfer-encoding;
bh=hLV/DU5oR/Lkguijyns3/nuAhaMpNuvUqDu2JuK35t4=;
b=uTMbEnM+aJqIxoAPjBHDDUWRqiUljJuR1+e7MvLJWhKcRmvAiGZryLIxe8iy3ki7Aj
5dmRMBXci+5CXVkZwhrFVNNf5Hc3dLyVwzwvahuN9F6UdliNt3zOIkcqnMQx4C1LEtQV
a/duUcX+dzoeRY3rOgfR0wOj1NwCcCzdU3ksUnvwfCwzp2DEL9+43pQNuyWoguga0CaI
eyFREV15HYYgJDvTUwMy5r91dgJVRaDX4k6o/fadyamqIC/0VTe01NT25ltFu+DWyPzX
68XFf3Eb98sDM8/cYIdUl5NtKdkc4mQGl3jiFPoWFiIp8YL1u20WYfipTl9DygbnsUQk
RkLg==
X-Gm-Message-State: AHQUAuYo/zjAo4TV7/dkhqygCbUEFDcXv6TRwobvKgr3jlMdVeszTis7
g5jtZLv6rJxN2ONbanLyYg3ZW/20EIQ=
X-Google-Smtp-Source: AHgI3IbKnMGMpQNhcC5zhWIYkv8cqxfEWdHCi2XxyIjTep4TG6TqSe+ek39sgIYLxnJuGXb2QRx5Dw==
X-Received: by 2002:adf:e290:: with SMTP id v16mr3243644wri.100.1549652501521;
Fri, 08 Feb 2019 11:01:41 -0800 (PST)
Received: from [10.12.10.3] ([62.112.9.165])
by smtp.googlemail.com with ESMTPSA id
g123sm7448969wmd.1.2019.02.08.11.01.40
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 08 Feb 2019 11:01:40 -0800 (PST)
From: Jonas Nick <jonasdnick@gmail.com>
X-Google-Original-From: Jonas Nick <jonasd.nick@gmail.com>
To: Johnson Lau <jl2012@xbt.hk>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk>
Openpgp: preference=signencrypt
Autocrypt: addr=jonasd.nick@gmail.com; prefer-encrypt=mutual; keydata=
mQINBFQ2o3oBEACv5N5WajlYk+i/4B8FmniipCB4biIKg38spMNt1EYM6RzTu+hbOrVOlJW8
fq/ih+dvlpreGxRPQlX4jr75kwoJCykd3geywTUl3KPLeJ/JRQJ8fVkine4Wr5qB5Jwo3+wt
inDVooaaF32Y0HolNacXVzT1x9uwn83Bz/ifg+iGATn/e1Si3ga/ytY5wYDzFz6aUDRW8ulu
DcG8ARMAgtzmi66EuyQyIWwSyoWFU8wJ98slU9LKuTu23r6HdxFuV+P2H1omJm+z8cd4QBMj
I23uHst0Wx1MyTeVhZCnQAghyasA3oopwzqRf5wwECAui1oZhr59R4R1DHJjn0PeWZXBSnOo
XPQ1ERjz4nQrODiIDEabD5DClPHZ1bte0tswm1aYBtD8/me9ck+SJdoH5r0DJrXCTtNl1XG1
9TTUINQe0eaQUOTakZmVaneCeSrw/pKOknkzudOCNCbmngKa2oJQOynrdsBuoigIYY+NQdot
fk1nJljrBzyTh4sFktbHyA24x/hCykMX6FnIQxDnsGR+S3I+vzADBLBBMQQtZsUA+xnvPu4l
6You5SZMVhgprQy38bKybeIGxSZtmPNtBf8ouKhAUpbIfOaq6BoP4EtueXk/vyieFxXiIkbF
N6b3pjhkG7wVG17HqCqeVeHz1ZAQJUPcqDQAPaelBf38RXPbeQARAQABtCJKb25hcyBOaWNr
IDxqb25hc2Qubmlja0BnbWFpbC5jb20+iQI/BBMBAgApAhsDBwsJCAcDAgEGFQgCCQoLBBYC
AwECHgECF4AFAlu1I0QFCQtA5soACgkQsacOT43NA2Y5zA/9G1kt1ECa6zPhpEBV5iqD1omt
ABdrZSxD8gBsZOMt2nLE1f4J0Oqy9LfMzKFzC8Kyd7usu6HVA8XM3fjVgqi+cDlEhaE+RqFi
FVJjai7Fo1EqQGoD8QKTHDpGMNAmkfiQI7yc7OOxJ7X/nRpI8EnUsHG0slw3ieG6krrwLMfi
rdJz5xA3P0tjdz/gRsG1IkwaB1bWnrIyh4oS9MiTSO1GZzHdRrhYZPFnJa7XiQsDWTvtTf4o
fkbDAxqsKSqJhh99Gl79dXjJ1X9c6YfmxdOWuHZwtpJRgTFXSavaojkjPdnx4/f8lsgQg0tI
BEaZnfroAvJCkYCqxNAPS5pSCaRaZbm+eoBl9848eFQztds/xfG3xIpn6VaOSdDNCD0+kSiO
LrqghKLN3nPWOfCU0zPlkFuNsWX0ALvAJj6UKGbvMRfR6uj5NPZuHbA2FK9/1pOfKLjm6bHI
2HtXeS5B0+eoAjHzoF9w/2DM4+DLU8Qbn63CpDZ3dodqK3Z7PHLv9oiiCVUFxia0J9YUZJru
1jFHc3BA/Ado4LSxjyUbG0kDQjddvBEmQIkW5c2VrkczYv8gCOLwiUF+RPqc8PxGRs5I5SqJ
RzcEN9nIaFcP5MTPrabbkXKLw6ZhHqc3J85qMOLoxThP5SCWM7I1SwLYIGgcWGFtL27U9IXe
/wzNH4aerKe5Ag0EWVExqgEQAL1iVOraDIRX7bI1bres6PsbkNwz56OqIRbfSACch82x4NAK
Jd9Gdabhv7mjX9bUGBwH79YUjpxOo2nh8Sp48SYThe9lWOmU6wo2T1ZyzuhoQp8jRtcll59Q
o2zbfQdWt8DdRhCNzma/qjhDaAOveKa13jtXasVVqR4UdK2ZG/nIRQhPDslYq+hutV/7kTrd
sk12GETBOrUQDh5WLbG5AbKGK/CQ3kXZWvyhSVD2I20ze18qsMrL88shgx+Tf0S9H+snQNQi
WsB8DVe/VQj7nfam+LTVoIWpYOgTW+Y7/bU+UylMyFNUlFBykAguSCZ1JTSCxM2W9Q6zOf8u
v9N+ht5TpTPiXvbx4mTA9UWu4Mksa7deqwy59MViuqRgBQwcH6WYgT202PYbMQzpxQSPBO4v
N7e/ScVpAlfTT52ygwURb89+A4LQzF0tKWsRC5ZON5FfVbLg1NMplECOr1gPpruUNlbNbLOY
nVd6nu1j/vLKvYiQL/BzoHJ4X5EvRm7BhktgdCuE5ce7eaNUGZKd9kUHNqhznKV+PeYCI78E
ARAYNORbD09V+40wBtv5+VYPv9XMBBVYqofMOFIPbt0pT4ssbhH8UMnQcZbrtzOPxE6405Hy
pT3gA85CSSpZXm3ziFdKodNyaYtb+eHwIGUQaC3pl3AdP8IpgVQL8K8CYNNhABEBAAGJBHIE
GAEIACYWIQQ2xxo3ydmIveglCNmxpw5Pjc0DZgUCWVExqgIbAgUJA8JnAAJACRCxpw5Pjc0D
ZsF0IAQZAQgAHRYhBEu7hFpvWmWmnfrsI0hh2/JiEjYFBQJZUTGqAAoJEEhh2/JiEjYFLUYP
/2nglwU8kOJqf97M8y/apivcw8D7X1KRK6PfEf3pAUwmJ58RBL9oNmPDky3D3NYi9iVmOJHz
mwVGVujO/PqnMxBfxjUwZDlYHM01q6De1PI+CHF6XLqo8DLZS++hMxpiNQwGulHDq/5QLTrD
ma3MTdfZBrQW6J41Oj3ma806jLo8QkqEebbeIHTJNtOHevuQZiV3AerrK/OS+AwwFxpq1F0c
nJlzIGU9fvMs5oSBHKRAesnLaKkUIMBdJxgqria8bpraTINT50b4fWyWtb/ipinwjSabVzyY
ec5qeLVcweltEnZCsRJaIsuyv1AzlXjrXYSNhXKLowv4EY201NFE0ltDD7jOCPmfpXzwmc8J
WFiwIMm3yC/RSneYVRdV3M+x6JpqncdLzd02J6ACG8Q1foKpM1VR0Ty5OgQCuzcJeuAYk8fc
GWACsH+I15et9iQ8RR/MqzX5508GDpmh4LMRlselnj1br0A71horFajMt7rzZvPuP/ITKiNR
Y07QS3zOEZDExGyMyZ6oP4j3bsyCn/TyMUfMJ2K9Y/FicaunRrjM0SN99lJlhTkZIG7PkmZ2
dmcHsdGmnkIWT9f2b8J41L3VbcZveoQFGVnjdd1uqZRBdeJu02M5An4XlhABLZ0ioci8fs4J
Xl45RZzJwjDwYz721P8ScWLpHYNg7XL9AqAa1fUQAJjuBn22R4YPrsn+60c/MnSB7h6xCTnO
irSZhqbMMg6YsTzLgN5WKqJuSsUqDPjsTbm9FJRGJLaZIeTWYbCV1i7J5ftdATHY0TTxx2/R
pbBNVkTyrYbsSdxzzGQhNcTFnH3PJde2mzXE+im60ab7RMdtryCNQKdoJSRQ9T1+bkloyLcl
XeTh55D261nGfxo/KhI54BQCgn0tS3raz9Yd2EOKHUKiCwq70+drBTMgunbWZ07b4zOLItTq
CRTdXceNjZVBV7YAYd/qeu5sLSCpAhQeRzQby49ILkKuU7pPba0QGy8mD5m5kmXOVmDj9LKK
8Q0jAd+eROcplK8B72hA6wYfzctwFxofu4oPKZZ54z1Drm5k17bZM2FO+6Oxk5iqWzB/lAKJ
nVGq+T/2yMWnY/2BPBljp4ks3uf7Ozxx2cfa4h/V3++HDPntA20RAuDR5eFhsHOGX+Z7dfei
zCB/skqCW9T37S0w564pvPx9py5OvwEd48sV9UQsL8W6IUb1OfMP+x2pkJicMs1TmBhMZI8/
Sxoi6lRdHrYabU1GJ4sN550wO+JLtxav0T3gGm0/JxTX18V7GKaGOrcbriVhImQkC2VQVcqk
MpciyF95IGc7lvxTpof5ZDbwO2z8U7RcYcJHjj7KwImefQC8agNUhPSBVwsvTjeuR1/F+7d3
oDqduQINBFlRMd4BEADB+3Vb1kfonWBHtzlQ2P0lVfNMI3zntc0w0zkPqgfA+RYp/O790abf
MtEcVt2OBW5Y6Iut+Y4SaN/zKEx72UnrOtS25z81I0XmJiKjGKayeR0hfiJLJFvROT9O/Bus
CNoccI0V14OMvmfqGJNwvBgR9RI47Not5ZmCDwAjFCg22tumSLsZIyuTgd7WR5kzrmESfXj+
SpbUg+D+mOmU4A5b1KUHiWtMOdgOHTkAEZsig4hiec/sfIEngityK2Fsre/Xrd+uEUlmRuKR
Y9+H5xyHBz3m8DjF+oDGXTyMijcWk8AOtoJ0KeZaCaCSVE7IEk0jltQ87448Zv+IljNh5Uuj
U9H/NH0sNRp3yMUkj68dheCMIPHJAFs8vxGHBq+/qRydvAFVTeKtBBv/Vr07C/YjPWam8PXC
PX2g0w7iX2LXMSKKzIJJgxeLteBhXc0rMeZaEzvv+1RWYRQyywgtXhwszry4xxYPvV6UdDe3
gK6Q4mAVjxVgVbYR7W+ibl6gFsmftC2WcNiRjOP4M1HRa/tRc5yV9TKrZcLawIIDOMaz5ZyH
+KsC+gdO+La9NL86+GCM5dBVBrYvUMfsaM6njtjZipbV5nwWHwSWXZ32p1R6fFzA0vs+wlSg
szJJp7sidEK2NIyVQMTr5cC0Mt+tzZOaUaa6x52tkdvmbE6n/AsN3QARAQABiQI8BBgBCAAm
FiEENscaN8nZiL3oJQjZsacOT43NA2YFAllRMd4CGwwFCQPCZwAACgkQsacOT43NA2YHlhAA
nz+dln8j1FjIPJmWsfN+E1v0RgWlIvSkGXNLUV/JQ67A+Nmrp0xfvL2vLeP78OAn8pJaC/uZ
nM/aK1s6fvWFTvfFNDtrO+sw08QSCQuaafGUaKgmW0YQ9sOwwTcYGs3goQprEpgA5/95LZAM
7UyPfSP8Wv4u/z4VSp/zECWf78xTsHb8WlWq/Fu47Fp88ONwxTFSFclq8F3gWilRXrwcL55b
b25jcr8fC/t1tHTz+G4lbAm0+hbXpIvvnN16AKKArre5XfcD9KDYmFFBTEndqxBK3UBz52kx
opfygDtgTEBG3Al2w1+y/T1+q46Jz8ECG2j98zW7kX2Y/C0Ss8+4ofoDiUTDxhmF9XjFFV8K
IvBEHqHyzO8JjkIpF5Q21UdGt/pCo/4OsirARb0W7Use9w3i4NmaeBKHaFJxf9Ft1SamQlni
O/eJH5OjRbyip9Ri38Xco/NsIqs8wjRZ2Huh+Je/JBgmexNMoNLtDNJAo7Q3wZcRya9RQ21n
93uMl++kMMbEMEecomPZqVlqOmelxQ09ic+h0F+8vaCYVf3C8gDM1c92OwUi5vbV+f6V9U4z
gu47BAQT2BZNV8i0PiKemU9E2ce51zaBdPBoU1xSy8e7Ujc8dSBPhqNBV3ANL5mFMhMffNUH
iSJxMac5w2Ar8e6R1NT8yJl3Ei81s6kfAJ8=
Message-ID: <9bae18fa-3266-61ce-0b62-6ee429198260@gmail.com>
Date: Fri, 8 Feb 2019 19:01:40 +0000
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: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US-large
Content-Transfer-Encoding: 8bit
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: Fri, 08 Feb 2019 20:16:50 +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, 08 Feb 2019 19:01:44 -0000
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
>
|
