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
|
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 E2E721184
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Sep 2018 09:34:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com
[209.85.221.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CC450762
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Sep 2018 09:34:44 +0000 (UTC)
Received: by mail-wr1-f52.google.com with SMTP id z3-v6so14416095wrr.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Sep 2018 02:34:44 -0700 (PDT)
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=t04wKvfitIUljS2lyOWqcoQllcbeJsp9Ppox8wr9PZg=;
b=oSyYekf5Zf2xY5bd9DpUHBNDlTeFKnmry6+/0BHGmz4mCALmffPloACMd+5BHeyHXR
Q74ONmrlvypWR+ApjyEKfQN4pdkF1kdsBbxqN9VfOC9OOqVLLt4OrTHtG6AmVzU3XWmh
AtefiAaRfpy9O1wGzl0/MTByHFdekCCjGbgdpI7Ll5B7RmRp8BkNrHvm6rLIU59f7eh4
IxpTAs9DBbUOubceRSdXC5vG4GmahpqQn09m9WNFrk7JP74/nyBiB+R8nvzDotHFyyar
JfsroD7y/J3DrZ0oC2+0iaT4FbkWS7RKkhchptF2OuL4Nu9+wBH5hFrU6P/SVKnpWDY6
9Ggg==
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=t04wKvfitIUljS2lyOWqcoQllcbeJsp9Ppox8wr9PZg=;
b=Zh4HTXuuMnLrHKcoHPFY8p0xz3Kro9cXqPjhZGDacQDPGTUo/+8SEBexearV1blwQh
7JkDF82DM0mKnt8qANAcugeMjJxF/BjXqbmOWs5lfhAdphvfCl3b3Kqy48ihH0PeaB90
UztYigFg21mIt8Zy+m0fljDVrBaNdp0Zwb8S9xE/EuDk6ZZ6mizhFZZIqbhzPqBWAU87
fUKjp8w19M5rwsK7QqUGd4xjiD6KXe1bl6UnEH81kYrGPqfEYkLeWcjkjnn0LXayTUmB
snCtMjKO/71toh3dQar0Idr0OKtE1AU6E9elhvRscNYC9LzJ/Hy4dMQjih26ZheIpVeZ
L1bA==
X-Gm-Message-State: ABuFfojsh0LdORpuZ+fgDVhIe0sCWA2zds+EYaPGuUsi9rmZUKisf4sU
1H9Lx2pJfm1Zc+5Ydw96wT8=
X-Google-Smtp-Source: ACcGV63TWH4/s/bcfGGURCYv7BWpBH6ixuQbr2mc1RUdFPDg5q+y92GSZhdQyRSZU41ni38WToAr/A==
X-Received: by 2002:adf:8447:: with SMTP id
65-v6mr3991643wrf.251.1537954483079;
Wed, 26 Sep 2018 02:34:43 -0700 (PDT)
Received: from [192.168.1.21] (194-166-164-159.adsl.highway.telekom.at.
[194.166.164.159]) by smtp.googlemail.com with ESMTPSA id
k63-v6sm8214123wmd.46.2018.09.26.02.34.41
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 26 Sep 2018 02:34:42 -0700 (PDT)
From: Jonas Nick <jonasdnick@gmail.com>
X-Google-Original-From: Jonas Nick <jonasd.nick@gmail.com>
To: Russell O'Connor <roconnor@blockstream.io>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Christian Decker <decker.christian@gmail.com>
References: <871sewirni.fsf@gmail.com>
<CAMZUoK=V9Dii7ja6n6mpW_tWt00PuT=-9Z8XoyKOY3y0_AwK5w@mail.gmail.com>
Openpgp: preference=signencrypt
Autocrypt: addr=jonasd.nick@gmail.com; prefer-encrypt=mutual; keydata=
xsFNBFQ2o3oBEACv5N5WajlYk+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
N6b3pjhkG7wVG17HqCqeVeHz1ZAQJUPcqDQAPaelBf38RXPbeQARAQABzSJKb25hcyBOaWNr
IDxqb25hc2Qubmlja0BnbWFpbC5jb20+wsF/BBMBAgApAhsDBwsJCAcDAgEGFQgCCQoLBBYC
AwECHgECF4AFAlYEdT0FCQdxbEMACgkQsacOT43NA2azdhAAkylnTYtnOrXbd0IPfbTSOQN7
fBaur/z3/CvO3H26J78tyKncZ6ZTbGWjkBHbbC0Hcer00Mz+XxJnKW9tEQBPdjZ+eWpgAoNp
mHyUDaeyy71H+zd+JGZwAIsg/e27TMymTrFPZc7Bc7b8CjK+iYjE2p+Q1bEDsAODqd2gAKT+
DhV36NThpllDnJAmJZuF4Vh/otMn7BTBqw9WiHBPymMPyfC/f185+XSopN7za0gPN1Fc8xBd
3JGrHTB7hi+49w3IVPs1dBLl+B46SzerlkMIpQPZ0y5WIEXae3uz8enLOI9jGIl7TQtFVFow
KAZMO77advua/ih1rq1Or41oM1HJ+VovO4cI4uhCPYUAJWrSb99VzL78hl64sEu3IOTvX1p3
S1RhJkaF9cAF2Domc9SA9s22J5yKx4dqk7uqCmelnm5vPEc59fdpRjb+DhYq+5eNRBxypSXh
1ZfUzvszh20TOIgU+s3eDyJMI7G3MqZr8pKiDzmOdHYwICJP4VH/lguuwg5NT147OSorYk41
pTBhM9gT0jJl3fsqfW4axeguqfHrwyVS9bD3ZdlveA+yg+MRJkNjw6yofCYuw9iTskqXJ/7S
wjPhxd4gqLxmGNUyeqXQSytQc08gHMX6w91wVXjs3oFUHiBvaXqAis2pFA7528LI46WlZ3pf
h/OZDthBG7bOwU0EWVEx3gEQAMH7dVvWR+idYEe3OVDY/SVV80wjfOe1zTDTOQ+qB8D5Fin8
7v3Rpt8y0RxW3Y4Fbljoi635jhJo3/MoTHvZSes61LbnPzUjReYmIqMYprJ5HSF+IkskW9E5
P078G6wI2hxwjRXXg4y+Z+oYk3C8GBH1Ejjs2i3lmYIPACMUKDba26ZIuxkjK5OB3tZHmTOu
YRJ9eP5KltSD4P6Y6ZTgDlvUpQeJa0w52A4dOQARmyKDiGJ5z+x8gSeCK3IrYWyt79et364R
SWZG4pFj34fnHIcHPebwOMX6gMZdPIyKNxaTwA62gnQp5loJoJJUTsgSTSOW1Dzvjjxm/4iW
M2HlS6NT0f80fSw1GnfIxSSPrx2F4Iwg8ckAWzy/EYcGr7+pHJ28AVVN4q0EG/9WvTsL9iM9
Zqbw9cI9faDTDuJfYtcxIorMgkmDF4u14GFdzSsx5loTO+/7VFZhFDLLCC1eHCzOvLjHFg+9
XpR0N7eArpDiYBWPFWBVthHtb6JuXqAWyZ+0LZZw2JGM4/gzUdFr+1FznJX1MqtlwtrAggM4
xrPlnIf4qwL6B074tr00vzr4YIzl0FUGti9Qx+xozqeO2NmKltXmfBYfBJZdnfanVHp8XMDS
+z7CVKCzMkmnuyJ0QrY0jJVAxOvlwLQy363Nk5pRprrHna2R2+ZsTqf8Cw3dABEBAAHCwXwE
GAEIACYWIQQ2xxo3ydmIveglCNmxpw5Pjc0DZgUCWVEx3gIbDAUJA8JnAAAKCRCxpw5Pjc0D
ZgeWEACfP52WfyPUWMg8mZax834TW/RGBaUi9KQZc0tRX8lDrsD42aunTF+8va8t4/vw4Cfy
kloL+5mcz9orWzp+9YVO98U0O2s76zDTxBIJC5pp8ZRoqCZbRhD2w7DBNxgazeChCmsSmADn
/3ktkAztTI99I/xa/i7/PhVKn/MQJZ/vzFOwdvxaVar8W7jsWnzw43DFMVIVyWrwXeBaKVFe
vBwvnltvbmNyvx8L+3W0dPP4biVsCbT6Fteki++c3XoAooCut7ld9wP0oNiYUUFMSd2rEErd
QHPnaTGil/KAO2BMQEbcCXbDX7L9PX6rjonPwQIbaP3zNbuRfZj8LRKzz7ih+gOJRMPGGYX1
eMUVXwoi8EQeofLM7wmOQikXlDbVR0a3+kKj/g6yKsBFvRbtSx73DeLg2Zp4EodoUnF/0W3V
JqZCWeI794kfk6NFvKKn1GLfxdyj82wiqzzCNFnYe6H4l78kGCZ7E0yg0u0M0kCjtDfBlxHJ
r1FDbWf3e4yX76QwxsQwR5yiY9mpWWo6Z6XFDT2Jz6HQX7y9oJhV/cLyAMzVz3Y7BSLm9tX5
/pX1TjOC7jsEBBPYFk1XyLQ+Ip6ZT0TZx7nXNoF08GhTXFLLx7tSNzx1IE+Go0FXcA0vmYUy
Ex981QeJInExpznDYCvx7pHU1PzImXcSLzWzqR8Anw==
Message-ID: <feff454d-2cc2-2104-5c6c-69630506bd56@gmail.com>
Date: Wed, 26 Sep 2018 09:36:57 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <CAMZUoK=V9Dii7ja6n6mpW_tWt00PuT=-9Z8XoyKOY3y0_AwK5w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US-large
Content-Transfer-Encoding: 7bit
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: Wed, 26 Sep 2018 10:42:40 +0000
Subject: Re: [bitcoin-dev] BIP sighash_noinput
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: Wed, 26 Sep 2018 09:34:46 -0000
> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
> hashSequence so that its behaviour is consistent with ANYONECANPAY?
There is a good reason for not doing that. If NOINPUT would sign the
hashSequence then it would be possible to get rid of OP_CSV in eltoo update
scripts. As a result update scripts could be taprootified because the more
common branch (settlement) would be just a 2-of-2 multisig. Applying taproot
would then make unilateral settlement look like a single pubkey spend and avoid
having to reveal the unexecuted (update) branch.
Eltoo update transaction outputs consist of two branches, update and
settlement, where the update branch can be spend by a more recent update
transaction if an obsolete update transaction ends up spending the funding
output. The settlement branch is a 2-of-2 multisig with a relative timelock
using OP_CSV. Removing OP_CSV is possible because both parties signature is
required to spend the update transaction. They will only sign if the input has
the right sequence numbers which is sufficient to enforce the timeout (BIP68) -
assuming they are covered by the signature.
There's a catch: hashSequence includes the sequence numbers of all transaction
inputs. That's not a problem for eltoo because settlement transactions only
have one input. The update mechanism with update transactions relies on being
able to bump the fee by unilaterally adding inputs and and change outputs to
the transaction. That's also not a problem because update spends do not use
relative timelocks and they are signed with SINGLE. So whenever NOINPUT is
combined SINGLE the hashSequence should be zeroed. This is in fact what a
minimal change to the current NOINPUT implementation would naturally do (see
below). However, that's error-prone when using NOINPUT in other contexts so in
general it would be better if NOINPUT would only sign the sequence number of
the corresponding input.
Another downside of this approach is that you can never rebind to an output
with an OP_CSV that requires a larger sequence number, unless you also sign
with SIGHASH_SINGLE. It's difficult to imagine application where this would be
an issue.
This is the modification to the NOINPUT implementation
(https://github.com/cdecker/bitcoin/commits/noinput) which makes eltoo
unilateral closes taprootifiable:
+++ b/src/script/interpreter.cpp
@@ -1223,7 +1223,7 @@ uint256 SignatureHash(const CScript& scriptCode, const CTransaction& txTo, unsig
hashPrevouts = cacheready ? cache->hashPrevouts : GetPrevoutHash(txTo);
}
- if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE && !noinput) {
+ if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
hashSequence = cacheready ? cache->hashSequence : GetSequenceHash(txTo);
}
On 5/1/18 4:58 PM, Russell O'Connor via bitcoin-dev wrote:
> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
> hashSequence so that its behaviour is consistent with ANYONECANPAY?
>
> On Mon, Apr 30, 2018 at 12:29 PM, Christian Decker via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> I'd like to pick up the discussion from a few months ago, and propose a new
>> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the
>> previous
>> output. This was previously mentioned on the list by Joseph Poon [1], but
>> was
>> never formally proposed, so I wrote a proposal [2].
>>
>> We have long known that `SIGHASH_NOINPUT` would be a great fit for
>> Lightning.
>> They enable simple watch-towers, i.e., outsource the need to watch the
>> blockchain for channel closures, and react appropriately if our
>> counterparty
>> misbehaves. In addition to this we just released the eltoo [3,4] paper
>> which
>> describes a simplified update mechanism that can be used in Lightning, and
>> other
>> off-chain contracts, with any number of participants.
>>
>> By not committing to the previous output being spent by the transaction,
>> we can
>> rebind an input to point to any outpoint with a matching output script and
>> value. The binding therefore is no longer explicit through a reference, but
>> through script compatibility, and the transaction ID reference in the
>> input is a
>> hint to validators. The sighash flag is meant to enable some off-chain
>> use-cases
>> and should not be used unless the tradeoffs are well-known. In particular
>> we
>> suggest using contract specific key-pairs, in order to avoid having any
>> unwanted
>> rebinding opportunities.
>>
>> The proposal is very minimalistic, and simple. However, there are a few
>> things
>> where we'd like to hear the input of the wider community with regards to
>> the
>> implementation details though. We had some discussions internally on
>> whether to
>> use a separate opcode or a sighash flag, some feeling that the sighash flag
>> could lead to some confusion with existing wallets, but given that we have
>> `SIGHASH_NONE`, and that existing wallets will not sign things with unknown
>> flags, we decided to go the sighash way. Another thing is that we still
>> commit
>> to the amount of the outpoint being spent. The rationale behind this is
>> that,
>> while rebinding to outpoints with the same value maintains the value
>> relationship between input and output, we will probably not want to bind to
>> something with a different value and suddenly pay a gigantic fee.
>>
>> The deployment part of the proposal is left vague on purpose in order not
>> to
>> collide with any other proposals. It should be possible to introduce it by
>> bumping the segwit script version and adding the new behavior.
>>
>> I hope the proposal is well received, and I'm looking forward to discussing
>> variants and tradeoffs here. I think the applications we proposed so far
>> are
>> quite interesting, and I'm sure there are many more we can enable with this
>> change.
>>
>> Cheers,
>> Christian
>>
>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
>> 2016-February/012460.html
>> [2] https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki
>> [3] https://blockstream.com/2018/04/30/eltoo-next-lightning.html
>> [4] https://blockstream.com/eltoo.pdf
>> _______________________________________________
>> 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
>
|