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
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
|
Return-Path: <chris@suredbits.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8349A1365
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Oct 2019 12:24:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com
[209.85.222.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B6B5F735
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Oct 2019 12:23:59 +0000 (UTC)
Received: by mail-qk1-f175.google.com with SMTP id 4so10950382qki.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 01 Oct 2019 05:23:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=suredbits-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=V9/qmJ7RR0TXNcMiHXKZUsnhNXQ8RczPXyv/8qjYYU0=;
b=Ch/nD/zuTF8CJ2vAj5yU+U3epZeJfhwUa7gBD25gcTBHjOOaZQ2ohKCuwHUAG9YpP2
QtWohJk+Up460ZBLsie0LfBnCZ51oFLDtgunXnL8Cfqn3Q3BbMjDjD1ibQos+Ki0XKMB
KCrvmrjRY4mSHWYEkk9v4PmlqSAvuataDkLQiFsJYN1bwhkCdIl8TUb6CpVMrW5QRfnH
7RDxdD5W/juvwgI1V3GM1yjWVjcYMeydg62tsD6RZX44zd6DSDucgOABUvhZcdCUP7Qu
qyqKkVSA3hiU9+GaQc2BbDRrkidKHyRPxAJkdjfrS30lziZXw90oLCgRpfohj20ZnWOp
FLuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=V9/qmJ7RR0TXNcMiHXKZUsnhNXQ8RczPXyv/8qjYYU0=;
b=phXlzswUs0TbSl5pX1xKIs1UQS1zmKd1Y+t4hxpQ/ZZuNsCtEmMNffrzbgttzfVkEV
IAwyLkP4uUUfjObg5lSJ3jbaoUX/w/JjXBE565D6d5cxI8ZIe2o3glP3aMgE2LNKSNLX
dTw8gHAC9/Kf3+snGPVFcjqHOOo/nTS+uU24YxJkPs4BZ7gKz1MHyhEpA4bC/s+gdAq4
13SvSuC4beaLjmVsijjxvatrR43FARuCsVKxaJNq7rMtgXwiM43YI1okJjNimYO/clnd
MPRSXEPww8+2lbCls3wVFXIbh2wfcjqSamPlGzSj2XuB9f9WmAMc8Yq0i+2Pwe2MItEB
jssg==
X-Gm-Message-State: APjAAAXw13MLi1Kl92A1FpnukKak4IiO/sEQ4xhsNHWw/1/A0ukUwjN3
Qf66W26/Ampl48P8rs5Gm46FLaP4/UGguZomDNLkKwxrIpU=
X-Google-Smtp-Source: APXvYqxGhzzHYZ2Wjdz0Pk17guAFXgh+9S9b/sginSDsvlmay2QRbqKVP7dZ6mjIdY/+KwmuUSOrw297jiICB8pqEWI=
X-Received: by 2002:a05:620a:7c8:: with SMTP id
8mr5351204qkb.299.1569932638402;
Tue, 01 Oct 2019 05:23:58 -0700 (PDT)
MIME-Version: 1.0
References: <87wodp7w9f.fsf@gmail.com>
In-Reply-To: <87wodp7w9f.fsf@gmail.com>
From: Chris Stewart <chris@suredbits.com>
Date: Tue, 1 Oct 2019 07:23:47 -0500
Message-ID: <CAFQwNuxdfMNBGyM5Y4nMb46GNigxFTFCv3X09jZd4fjNPckw4Q@mail.gmail.com>
To: Christian Decker via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003bcec10593d86db6"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DOS_RCVD_IP_TWICE_B, HTML_MESSAGE,
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: Tue, 01 Oct 2019 14:42:31 +0000
Cc: lightning-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Continuing the discussion about noinput /
anyprevout
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: Tue, 01 Oct 2019 12:24:03 -0000
--0000000000003bcec10593d86db6
Content-Type: text/plain; charset="UTF-8"
I do have some concerns about SIGHASH_NOINPUT, mainly that it does
introduce another footgun into the bitcoin protocol with address reuse.
It's common practice for bitcoin businesses to re-use addresses. Many
exchanges [1] reuse addresses for cold storage with very large sums of
money that is stored in these addreses.
It is my understanding with this part of BIP118
>Using NOINPUT the input containing the signature no longer references a
specific output. Any participant can take a transaction and rewrite it by
changing the hash reference to the previous output, without invalidating
the signatures. This allows transactions to be bound to any output that
matches the value committed to in the witness and whose witnessProgram,
combined with the spending transaction's witness returns true.
if an exchange were to once produce a digital signature from that cold
storage address with a SIGHASH_NOINPUT signature, that signature can be
replayed again and again on the blockchain until their wallet is drained.
This might be able to mitigated since the signatures commit to outputs,
which may be small in value for the transaction that SIGHASH_NOINPUT was
used. This means that an exchange could move coins from the address with a
larger transaction that spends money to a new output (and presumably pays a
higher fee than the smaller transactions).
### Why does this matter?
It seems that SIGHASH_NOINPUT will be an extremely useful tool for offchain
protocols like Lightning. This gives us the building blocks for enforcing
specific offchain states to end up onchain [2].
Since this tool is useful, we can presume that it will be integrated into
the signing path of large economic entities in bitcoin -- namely exchanges.
Many exchanges have specific signing procedures for transactions that are
leaving an exchange that is custom software. Now -- presuming wide adoption
of off chain protocols -- they will need to have a _second unique signing
path that uses SIGHASH_NOINPUT_.
It is imperative that this second signing path -- which uses
SIGHASH_NOINPUT -- does NOT get mixed up with the first signing path that
controls an exchanges onchain funds. If this were to happen, fund lost
could occur if the exchange is reusing address, which seems to be common
practice.
This is stated here in BIP118:
>This also means that particular care has to be taken in order to avoid
unintentionally enabling this rebinding mechanism. NOINPUT MUST NOT be
used, unless it is explicitly needed for the application, e.g., it MUST NOT
be a default signing flag in a wallet implementation. Rebinding is only
possible when the outputs the transaction may bind to all use the same
public keys. Any public key that is used in a NOINPUT signature MUST only
be used for outputs that the input may bind to, and they MUST NOT be used
for transactions that the input may not bind to. For example an application
SHOULD generate a new key-pair for the application instance using NOINPUT
signatures and MUST NOT reuse them afterwards.
This means we need to encourage onchain hot wallet signing procedures to be
kept separate from offchain hot wallet signing procedures, which introduces
more complexity for key management (two keychains).
One (of the few) upsides of the current Lightning penalty mechanism is that
fund loss can be contained to balance of the channel. You cannot do
something in the current protocol that will effect your funds outside of
that channel. With SIGHASH_NOINPUT, that property changes.
### A side note
In general, i think we should start disallowing uses of the SIGHASH
protocols that have unexpected behavior. The classic example of this is
SIGHASH_SINGLE [3]. I get uneasy about adding more footguns to the
protocol, which with current network behavior (address re-use)
SIGHASH_NOINPUT would be a big one.
[1] - https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
[2] -
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002136.html
[3] -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016048.html
On Mon, Sep 30, 2019 at 9:24 AM Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> With the recently renewed interest in eltoo, a proof-of-concept
> implementation
> [1], and the discussions regarding clean abstractions for off-chain
> protocols
> [2,3], I thought it might be time to revisit the `sighash_noinput` proposal
> (BIP-118 [4]), and AJ's `bip-anyprevout` proposal [5].
>
> (sorry for the long e-mail. I wanted to give enough context and describe
> the
> various tradeoffs so people don't have to stitch them together from
> memory. If
> you're impatient there are a couple of open questions at the bottom)
>
> Both proposals are ways to allow rebinding of transactions to new outputs,
> by
> adding a sighash flag that excludes the output when signing. This allows
> the
> transaction to be bound to any output, without needing a new signature, as
> long as output script and input script are compatible, e.g., the signature
> matches the public key specified in the output.
>
> BIP-118 is limited to explaining the details of signature verification, and
> omits anything related to deployment and dependency on other proposals.
> This
> was done in order not to depend on bip-taproot which is also in draft-phase
> currently, and to allow deployment alongside the next version of segwit
> script. `bip-anyprevout` builds on top of BIP-118, adding integration with
> `bip-taproot`, chaperone signatures, limits the use of the sighash flag to
> script path spends, as well as a new pubkey serialization which uses the
> first
> byte to signal opt-in.
>
> I'd like to stress that both proposals are complementary and not competing,
> which is something that I've heard a couple of times.
>
> There remain a couple of unclear points which I hope we can address in the
> coming days, to get this thing moving again, and hopefully get a new tool
> in
> our toolbox soon(ish).
>
> In the following I will quote a couple of things that were discussed during
> the CoreDev meeting earlier this year, but not everybody could join, and
> it is
> important that we engage the wider community, to get a better picture, and
> I
> think not everybody is up-to-date about the current state.
>
>
> ## Dangers of `sighash_noinput`
>
> An argument I have heard against noinput is that it is slightly less
> complex
> or compute intensive than `sighash_all` signatures, which may encourage
> wallet
> creators to only implement the noinput variant, and use it indiscrimi-
> nately. This is certainly a good argument, and indeed we have seen at least
> one developer proposing to use noinput for all transactions to discourage
> address reuse.
>
> This was also mentioned at CoreDev [6]:
>
> > When [...] said he wanted to write a wallet that only used
> SIGHASH\_NOINPUT,
> > that was pause for concern. Some people might want to use
> SIGHASH\_NOINPUT as a
> > way to cheapen or reduce the complexity of making a wallet
> > implementation. SIGHASH\_NOINPUT is from a purely procedural point of
> view
> > easier than doing a SIGHASH\_ALL, that's all I'm saying. So you're
> hashing
> > less. It's way faster. That concern has been brought to my attention and
> it's
> > something I can see. Do we want to avoid people being stupid and shooting
> > themselves and their customers in the foot? Or do we treat this as a
> special
> > case where you mark we're aware of how it should be used and we just try
> to
> > get that awareness out?
>
> Another issue that is sometimes brought up is that an external user may
> attempt to send funds to a script that was really part of a higher-level
> protocol. This leads to those funds becoming inaccessible unless you gather
> all the participants and sign off on those funds. I don't believe this is
> anything new, and if users really want to shoot themselves in the foot and
> send funds to random addresses they fish out of a blockexplorer there's
> little
> we can do. What we could do is make the scripts used internally in our
> protocols unaddressable (see output tagging below), removing this issue
> altogether.
>
>
> ## Chaperone signatures
>
> Chaperone signatures are signatures that ensure that there is no
> third-party
> malleability of transactions. The idea is to have an additional signature,
> that doesn't use noinput, or any of its variants, and therefore needs to be
> authored by one of the pubkeys in the output script, i.e., one or more of
> the
> participants of the contract the transaction belongs to. Concretely in
> eltoo
> we'd be using a shared key known to all participants in the eltoo
> instance, so
> any participant can sign an update to rebind it to the desired output.
>
> Chaperone signatures have a number of downsides however:
>
> - Additional size: both the public key and the signature actually need
> to be
> stored along with the real noinput signature, resulting in transfer,
> computational and storage overhead. We can't reuse the same pubkey
> from the
> noinput signature since that'd require access to the matching privkey
> which
> is what we want to get rid of using noinput in the first place.
> - Protocols can still simply use a globally known privkey, voiding the
> benefit of chaperone signatures, since third-parties can sign again. I
> argue that third-party malleability is a subset of first-party
> malleability, and we should protect against first-party malleability
> first
> and foremost. My counterparty has the incentive to trick me, a
> third-party
> may not.
>
> On the plus side chaperone signatures certainly address the lazy-wallet-dev
> scenario, and as AJ points out in [bip-anyprevout] we get back the same
> security guarantees as we had without noinput.
>
> From what I remember and the transcript (thanks Kanzure for your awesome
> work
> by the way), there was no strong support for chaperone signatures during
> the
> meeting [6], but feedback from people that were not present is needed:
>
> > if everyone who wanted to use NOINPUT was convinced there was a problem,
> then
> > they would pick the right thing, but clearly people aren't. It's not a
> > foot-gun defense mechanism because it's easily bypassed, and it's easier
> to
> > bypass it than to use it. Whereas for tagged outputs, it's that if you
> want
> > any NOINPUT then you must tag.
>
>
> ## Output tagging
>
> One proposal that I found rather fascinating during the discussion in
> Amsterdam was that we could achieve the same disincentive to use on
> non-smart-contract cases by simply making the output scripts
> unaddressable. This can be done by specifying a version of taproot outputs
> for
> which the bech32 addressing scheme simply doesn't have a representation
> [6]:
>
> > The tagged outputs idea is that we don't have NOINPUT ANYPREVOUT
> supported for
> > taproot v1 outputs, instead we have a segwit version 16 v16 that supports
> > taproot. The reason for v16 is that we redefine bech32 to not cover
> > v16. There's no addresses for this type of output. If you're an exchange
> and
> > receive a bech32 address, you declare it invalid. You make it less user
> > friendly here; and there shouldn't be an address anyway. You might want
> to see
> > it on a block explorer, but you don't want to pass it around to anyone.
>
> We don't need addresses in our contract constructions because we deal
> directly
> with the scripts. This would also have the desired effect of no allowing
> generic wallets to send to these addresses, or users accidentally sending
> funds to what was supposed to be a one-off script used internally in the
> off-chain contract.
>
> Notice that this idea was already used by Russell O'Connor when performing
> a
> transaction on elements using his new scripting language simplicity
> [7]:
>
> > For this experimental development, we created an improper segwit version,
> > "version 31" for Simplicity addresses. The payload of this segwit
> version 31
> > address contains a commitment Merkle root of a Simplicity program to
> control
> > the UTXO.
>
> The concern with output tagging is that it hurts fungibility, marking
> outputs
> used in a contract as such and making them identifiable. But maybe it
> would be
> a good idea to create two domains anyway: one for user-addressable
> destinations which users can use with their general purpose wallets, and
> one
> domain for contracts, which users cannot send to directly.
>
> This also came up during the CoreDev meeting [ams-coredev]:
>
> > these sort of NOINPUT signatures are only things that are within some
> > application or within some protocol that gets negotiated between
> participants,
> > but they don't cross-independent domains where you see a wallet or a
> protocol
> > as a kind of domain. You can't tell the difference, is this an address I
> can
> > give to someone else or not? It's all scripts, no real addresses. There
> are
> > types of outputs that are completely insecure unconditionally; there are
> > things that are protected and I can give to anyone, you don't want to
> reuse
> > it, but there's no security issue from doing so. This is an additional
> class
> > that is secure perfectly but only when used in the right way.
>
>
> ## Open questions
>
> The questions that remain to be addressed are the following:
>
> 1. General agreement on the usefulness of noinput / anyprevoutanyscript /
> anyprevout. While at the CoreDev meeting I think everybody agreed that
> these proposals a useful, also beyond eltoo, not everybody could be
> there. I'd therefore like to elicit some feedback from the wider
> community.
> 2. Is there strong support or opposition to the chaperone signatures
> introduced in anyprevout / anyprevoutanyscript? I think it'd be best to
> formulate a concrete set of pros and contras, rather than talk about
> abstract dangers or advantages.
> 3. The same for output tagging / explicit opt-in. What are the advantages
> and
> disadvantages?
> 4. Shall we merge BIP-118 and bip-anyprevout. This would likely reduce the
> confusion and make for simpler discussions in the end.
> 5. Anything I forgot to mention :-)
>
> Cheers,
> Christian
>
> [1] <
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002131.html
> >
> [2] <
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017285.html
> >
> [3] <
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001383.html
> >
> [4] <https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki>
> [5] <
> https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-anyprevout.mediawiki
> >
> [6] <
> http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-noinput-etc/
> >
> [7] <https://lists.ozlabs.org/pipermail/simplicity/2019/000018.html>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000003bcec10593d86db6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I do have some concerns about SIGHASH_NOINPUT, mainly=
that it does introduce another footgun into the bitcoin protocol with addr=
ess reuse. It's common practice for bitcoin businesses to re-use addres=
ses. Many exchanges [1] reuse addresses for cold storage with very large su=
ms of money that is stored in these addreses. <br></div><div><br></div><div=
>It is my understanding with this part of BIP118 <br></div><div><br></div><=
div>>Using <tt>NOINPUT</tt> the input containing the signature no longer
references a specific output.
Any participant can take a transaction and rewrite it by changing the
hash reference to the previous output, without invalidating the
signatures.
This allows transactions to be bound to any output that matches the
value committed to in the <tt>witness</tt> and whose <tt>witnessProgram</tt=
>,
combined with the spending transaction's <tt>witness</tt> returns <tt>t=
rue</tt>. <br></div><div><br></div><div>if an exchange were to once produce=
a digital signature from that cold storage address with a SIGHASH_NOINPUT =
signature, that signature can be replayed again and again on the blockchain=
until their wallet is drained. This might be able to mitigated since the s=
ignatures commit to outputs, which may be small in value for the transactio=
n that SIGHASH_NOINPUT was used. This means that an exchange could move coi=
ns from the address with a larger transaction that spends money to a new ou=
tput (and presumably pays a higher fee than the smaller transactions). <br>=
</div><div><br></div><div>### Why does this matter?=C2=A0</div><div><br></d=
iv><div>It seems that SIGHASH_NOINPUT will be an extremely useful tool for =
offchain protocols like Lightning. This gives us the building blocks for en=
forcing specific offchain states to end up onchain [2]. <br></div><div><br>=
</div><div>Since this tool is useful, we can presume that it will be integr=
ated into the signing path of large economic entities in bitcoin -- namely =
exchanges. Many exchanges have specific signing procedures for transactions=
that are leaving an exchange that is custom software. Now -- presuming wid=
e adoption of off chain protocols -- they will need to have a _second uniqu=
e signing path that uses SIGHASH_NOINPUT_. <br></div><div><br></div><div>It=
is imperative that this second signing path -- which uses SIGHASH_NOINPUT =
-- does NOT get mixed up with the first signing path that controls an excha=
nges onchain funds. If this were to happen, fund lost could occur if the ex=
change is reusing address, which seems to be common practice. <br></div><di=
v><br></div><div>This is stated here in BIP118:<br></div><div><br></div><di=
v>>This also means that particular care has to be taken in order to avoi=
d
unintentionally enabling this rebinding mechanism. <tt>NOINPUT</tt> MUST NO=
T
be used, unless it is explicitly needed for the application, e.g., it
MUST NOT be a default signing flag in a wallet
implementation. Rebinding is only possible when the outputs the
transaction may bind to all use the same public keys. Any public key
that is used in a <tt>NOINPUT</tt> signature MUST only be used for outputs
that the input may bind to, and they MUST NOT be used for transactions
that the input may not bind to. For example an application SHOULD
generate a new key-pair for the application instance using <tt>NOINPUT</tt>
signatures and MUST NOT reuse them afterwards.
</div><div><br></div><div>This means we need to encourage onchain hot walle=
t signing procedures to be kept separate from offchain hot wallet signing p=
rocedures, which introduces more complexity for key management (two keychai=
ns).<br></div><div><br></div><div>One (of the few) upsides of the current L=
ightning penalty mechanism is that fund loss can be contained to balance of=
the channel. You cannot do something in the current protocol that will eff=
ect your funds outside of that channel. With SIGHASH_NOINPUT, that property=
changes. <br></div><div><br></div><div>### A side note<br></div><div>In ge=
neral, i think we should start disallowing uses of the SIGHASH protocols th=
at have unexpected behavior. The classic example of this is SIGHASH_SINGLE =
[3]. I get uneasy about adding more footguns to the protocol, which with cu=
rrent network behavior (address re-use) SIGHASH_NOINPUT would be a big one.=
<br></div><div><br></div><div><br></div><div>[1] - <a href=3D"https://biti=
nfocharts.com/top-100-richest-bitcoin-addresses.html">https://bitinfocharts=
.com/top-100-richest-bitcoin-addresses.html</a></div><div>[2] - <a href=3D"=
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/00=
2136.html">https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-S=
eptember/002136.html</a></div><div>[3] - <a href=3D"https://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2018-May/016048.html">https://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2018-May/016048.html</a></div></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, S=
ep 30, 2019 at 9:24 AM Christian Decker via bitcoin-dev <<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation=
.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">With the recently renewed interest in eltoo, a proof-of-concept impleme=
ntation<br>
[1], and the discussions regarding clean abstractions for off-chain protoco=
ls<br>
[2,3], I thought it might be time to revisit the `sighash_noinput` proposal=
<br>
(BIP-118 [4]), and AJ's `bip-anyprevout` proposal [5].<br>
<br>
(sorry for the long e-mail. I wanted to give enough context and describe th=
e<br>
various tradeoffs so people don't have to stitch them together from mem=
ory. If<br>
you're impatient there are a couple of open questions at the bottom)<br=
>
<br>
Both proposals are ways to allow rebinding of transactions to new outputs, =
by<br>
adding a sighash flag that excludes the output when signing. This allows th=
e<br>
transaction to be bound to any output, without needing a new signature, as<=
br>
long as output script and input script are compatible, e.g., the signature<=
br>
matches the public key specified in the output.<br>
<br>
BIP-118 is limited to explaining the details of signature verification, and=
<br>
omits anything related to deployment and dependency on other proposals. Thi=
s<br>
was done in order not to depend on bip-taproot which is also in draft-phase=
<br>
currently, and to allow deployment alongside the next version of segwit<br>
script. `bip-anyprevout` builds on top of BIP-118, adding integration with<=
br>
`bip-taproot`, chaperone signatures, limits the use of the sighash flag to<=
br>
script path spends, as well as a new pubkey serialization which uses the fi=
rst<br>
byte to signal opt-in.<br>
<br>
I'd like to stress that both proposals are complementary and not compet=
ing,<br>
which is something that I've heard a couple of times.<br>
<br>
There remain a couple of unclear points which I hope we can address in the<=
br>
coming days, to get this thing moving again, and hopefully get a new tool i=
n<br>
our toolbox soon(ish).<br>
<br>
In the following I will quote a couple of things that were discussed during=
<br>
the CoreDev meeting earlier this year, but not everybody could join, and it=
is<br>
important that we engage the wider community, to get a better picture, and =
I<br>
think not everybody is up-to-date about the current state.<br>
<br>
<br>
## Dangers of `sighash_noinput`<br>
<br>
An argument I have heard against noinput is that it is slightly less comple=
x<br>
or compute intensive than `sighash_all` signatures, which may encourage wal=
let<br>
creators to only implement the noinput variant, and use it indiscrimi-<br>
nately. This is certainly a good argument, and indeed we have seen at least=
<br>
one developer proposing to use noinput for all transactions to discourage<b=
r>
address reuse.<br>
<br>
This was also mentioned at CoreDev [6]:<br>
<br>
> When [...] said he wanted to write a wallet that only used SIGHASH\_NO=
INPUT,<br>
> that was pause for concern. Some people might want to use SIGHASH\_NOI=
NPUT as a<br>
> way to cheapen or reduce the complexity of making a wallet<br>
> implementation. SIGHASH\_NOINPUT is from a purely procedural point of =
view<br>
> easier than doing a SIGHASH\_ALL, that's all I'm saying. So yo=
u're hashing<br>
> less. It's way faster. That concern has been brought to my attenti=
on and it's<br>
> something I can see. Do we want to avoid people being stupid and shoot=
ing<br>
> themselves and their customers in the foot? Or do we treat this as a s=
pecial<br>
> case where you mark we're aware of how it should be used and we ju=
st try to<br>
> get that awareness out?<br>
<br>
Another issue that is sometimes brought up is that an external user may<br>
attempt to send funds to a script that was really part of a higher-level<br=
>
protocol. This leads to those funds becoming inaccessible unless you gather=
<br>
all the participants and sign off on those funds. I don't believe this =
is<br>
anything new, and if users really want to shoot themselves in the foot and<=
br>
send funds to random addresses they fish out of a blockexplorer there's=
little<br>
we can do. What we could do is make the scripts used internally in our<br>
protocols unaddressable (see output tagging below), removing this issue<br>
altogether.<br>
<br>
<br>
## Chaperone signatures<br>
<br>
Chaperone signatures are signatures that ensure that there is no third-part=
y<br>
malleability of transactions. The idea is to have an additional signature,<=
br>
that doesn't use noinput, or any of its variants, and therefore needs t=
o be<br>
authored by one of the pubkeys in the output script, i.e., one or more of t=
he<br>
participants of the contract the transaction belongs to. Concretely in elto=
o<br>
we'd be using a shared key known to all participants in the eltoo insta=
nce, so<br>
any participant can sign an update to rebind it to the desired output.<br>
<br>
Chaperone signatures have a number of downsides however:<br>
<br>
-=C2=A0 =C2=A0Additional size: both the public key and the signature actual=
ly need to be<br>
=C2=A0 =C2=A0 stored along with the real noinput signature, resulting in tr=
ansfer,<br>
=C2=A0 =C2=A0 computational and storage overhead. We can't reuse the sa=
me pubkey from the<br>
=C2=A0 =C2=A0 noinput signature since that'd require access to the matc=
hing privkey which<br>
=C2=A0 =C2=A0 is what we want to get rid of using noinput in the first plac=
e.<br>
-=C2=A0 =C2=A0Protocols can still simply use a globally known privkey, void=
ing the<br>
=C2=A0 =C2=A0 benefit of chaperone signatures, since third-parties can sign=
again. I<br>
=C2=A0 =C2=A0 argue that third-party malleability is a subset of first-part=
y<br>
=C2=A0 =C2=A0 malleability, and we should protect against first-party malle=
ability first<br>
=C2=A0 =C2=A0 and foremost. My counterparty has the incentive to trick me, =
a third-party<br>
=C2=A0 =C2=A0 may not.<br>
<br>
On the plus side chaperone signatures certainly address the lazy-wallet-dev=
<br>
scenario, and as AJ points out in [bip-anyprevout] we get back the same<br>
security guarantees as we had without noinput.<br>
<br>
From what I remember and the transcript (thanks Kanzure for your awesome wo=
rk<br>
by the way), there was no strong support for chaperone signatures during th=
e<br>
meeting [6], but feedback from people that were not present is needed:<br>
<br>
> if everyone who wanted to use NOINPUT was convinced there was a proble=
m, then<br>
> they would pick the right thing, but clearly people aren't. It'=
;s not a<br>
> foot-gun defense mechanism because it's easily bypassed, and it=
9;s easier to<br>
> bypass it than to use it. Whereas for tagged outputs, it's that if=
you want<br>
> any NOINPUT then you must tag.<br>
<br>
<br>
## Output tagging<br>
<br>
One proposal that I found rather fascinating during the discussion in<br>
Amsterdam was that we could achieve the same disincentive to use on<br>
non-smart-contract cases by simply making the output scripts<br>
unaddressable. This can be done by specifying a version of taproot outputs =
for<br>
which the bech32 addressing scheme simply doesn't have a representation=
[6]:<br>
<br>
> The tagged outputs idea is that we don't have NOINPUT ANYPREVOUT s=
upported for<br>
> taproot v1 outputs, instead we have a segwit version 16 v16 that suppo=
rts<br>
> taproot. The reason for v16 is that we redefine bech32 to not cover<br=
>
> v16. There's no addresses for this type of output. If you're a=
n exchange and<br>
> receive a bech32 address, you declare it invalid. You make it less use=
r<br>
> friendly here; and there shouldn't be an address anyway. You might=
want to see<br>
> it on a block explorer, but you don't want to pass it around to an=
yone.<br>
<br>
We don't need addresses in our contract constructions because we deal d=
irectly<br>
with the scripts. This would also have the desired effect of no allowing<br=
>
generic wallets to send to these addresses, or users accidentally sending<b=
r>
funds to what was supposed to be a one-off script used internally in the<br=
>
off-chain contract.<br>
<br>
Notice that this idea was already used by Russell O'Connor when perform=
ing a<br>
transaction on elements using his new scripting language simplicity<br>
[7]:<br>
<br>
> For this experimental development, we created an improper segwit versi=
on,<br>
> "version 31" for Simplicity addresses. The payload of this s=
egwit version 31<br>
> address contains a commitment Merkle root of a Simplicity program to c=
ontrol<br>
> the UTXO.<br>
<br>
The concern with output tagging is that it hurts fungibility, marking outpu=
ts<br>
used in a contract as such and making them identifiable. But maybe it would=
be<br>
a good idea to create two domains anyway: one for user-addressable<br>
destinations which users can use with their general purpose wallets, and on=
e<br>
domain for contracts, which users cannot send to directly.<br>
<br>
This also came up during the CoreDev meeting [ams-coredev]:<br>
<br>
> these sort of NOINPUT signatures are only things that are within some<=
br>
> application or within some protocol that gets negotiated between parti=
cipants,<br>
> but they don't cross-independent domains where you see a wallet or=
a protocol<br>
> as a kind of domain. You can't tell the difference, is this an add=
ress I can<br>
> give to someone else or not? It's all scripts, no real addresses. =
There are<br>
> types of outputs that are completely insecure unconditionally; there a=
re<br>
> things that are protected and I can give to anyone, you don't want=
to reuse<br>
> it, but there's no security issue from doing so. This is an additi=
onal class<br>
> that is secure perfectly but only when used in the right way.<br>
<br>
<br>
## Open questions<br>
<br>
The questions that remain to be addressed are the following:<br>
<br>
1.=C2=A0 General agreement on the usefulness of noinput / anyprevoutanyscri=
pt /<br>
=C2=A0 =C2=A0 anyprevout. While at the CoreDev meeting I think everybody ag=
reed that<br>
=C2=A0 =C2=A0 these proposals a useful, also beyond eltoo, not everybody co=
uld be<br>
=C2=A0 =C2=A0 there. I'd therefore like to elicit some feedback from th=
e wider community.<br>
2.=C2=A0 Is there strong support or opposition to the chaperone signatures<=
br>
=C2=A0 =C2=A0 introduced in anyprevout / anyprevoutanyscript? I think it=
9;d be best to<br>
=C2=A0 =C2=A0 formulate a concrete set of pros and contras, rather than tal=
k about<br>
=C2=A0 =C2=A0 abstract dangers or advantages.<br>
3.=C2=A0 The same for output tagging / explicit opt-in. What are the advant=
ages and<br>
=C2=A0 =C2=A0 disadvantages?<br>
4.=C2=A0 Shall we merge BIP-118 and bip-anyprevout. This would likely reduc=
e the<br>
=C2=A0 =C2=A0 confusion and make for simpler discussions in the end.<br>
5.=C2=A0 Anything I forgot to mention :-)<br>
<br>
Cheers,<br>
Christian<br>
<br>
[1] <<a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-de=
v/2019-September/002131.html" rel=3D"noreferrer" target=3D"_blank">https://=
lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002131.htm=
l</a>><br>
[2] <<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
2019-September/017285.html" rel=3D"noreferrer" target=3D"_blank">https://li=
sts.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017285.html</a=
>><br>
[3] <<a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-de=
v/2018-August/001383.html" rel=3D"noreferrer" target=3D"_blank">https://lis=
ts.linuxfoundation.org/pipermail/lightning-dev/2018-August/001383.html</a>&=
gt;<br>
[4] <<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0118.med=
iawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bip=
s/blob/master/bip-0118.mediawiki</a>><br>
[5] <<a href=3D"https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-=
anyprevout.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.c=
om/ajtowns/bips/blob/bip-anyprevout/bip-anyprevout.mediawiki</a>><br>
[6] <<a href=3D"http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/=
2019-06-06-noinput-etc/" rel=3D"noreferrer" target=3D"_blank">http://diyhpl=
.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-noinput-etc/</a>><=
br>
[7] <<a href=3D"https://lists.ozlabs.org/pipermail/simplicity/2019/00001=
8.html" rel=3D"noreferrer" target=3D"_blank">https://lists.ozlabs.org/piper=
mail/simplicity/2019/000018.html</a>><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--0000000000003bcec10593d86db6--
|