summaryrefslogtreecommitdiff
path: root/b6/522b2d117b799f176716fd9228e6914e9cb222
blob: a7842d0e29aaecf71b3f3e354a4117f2b3ff930b (plain)
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
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
Return-Path: <junderwood@bitcoinbank.co.jp>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5B667C9E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 29 Jun 2019 00:19:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw1-f50.google.com (mail-yw1-f50.google.com
	[209.85.161.50])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1820A2C6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 29 Jun 2019 00:19:54 +0000 (UTC)
Received: by mail-yw1-f50.google.com with SMTP id t2so5224896ywe.10
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 28 Jun 2019 17:19:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=bitcoinbank.co.jp; s=google;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=+re3TxeDp7i1F0HCXHRWt3lZ7IJvPnfj6CYdCm5G6xQ=;
	b=UVsY+GUIykFOi2CEOdABRz4ksvK5LsD1cRlB6gtQ+i44fH/eldlb/ZofcOFhWrkNq6
	7A+Bgfj0ChMBkUgbbWhqDH1oDpY3Aql9TKudH1KSV2qS1S4cGWZdhSq88L/zF6cv3rG+
	gISeZ6m9TVy2jsk7Ko8SMwoMMp2mT2aK79p3Bhv+ksctP5LJUHp0p9FjJBt1wSixOolT
	7IXWofd6j53vb8i2vaun5jfnAOU1KI2WhNa7kObKsIG7+cqrXAgaCwiWkLk6U94OoPdj
	AZK/YZs9WemnTxMR6rIovWIHHD/TjDIzfNpOQDH0sFL6URI2ZACexLnx63KzIg4QAhZh
	GgHg==
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=+re3TxeDp7i1F0HCXHRWt3lZ7IJvPnfj6CYdCm5G6xQ=;
	b=iuv/MzoH6dCpWR+z/E4qpuvXN+zPjRjvcHC2cYivTPhvwKxXWeOCt1cdBi+QyTgx+V
	PBUhHUIPbVCk9vOhfOWKNMPCYWrKNBqLIkNwe80l6SOMa2sGAk8K0fz0C/F+Zn859W73
	3qR9OG4zRwdiJVIrkO25LpV/Go0V1eCqEG+oIbFtE0zjjLVpydGkPIFGppMb6/F6AVGU
	iFHcOkNPZNBwnfwMu+rsXJLGxynDPc5fVNJ/2Rfi50MXouNPTlx4j8CI79CVyuWZ3s9x
	DNsENcUs3WnB1XUCCgXLe9Frv7497ssGJfQsWL3OWv3KTXSTn5gVrcRIB8hhBBJnWuHm
	Z2EA==
X-Gm-Message-State: APjAAAWqWNMjgMv7n6RdPeDOs2G76pC4YS4ilb5LyYrctanQxZyaZLOy
	H3RGZLEcpwJACUBZw4aqmc4/tCss+FAQatAIy5V8
X-Google-Smtp-Source: APXvYqycxJ3qOsPTVcndpsaNd7cLgP51AYpAp0qdCo0eUBXcmxY8374G2Jnq7LSGU6LZ2JcIXK1xaV+rdWXGuWTQt+A=
X-Received: by 2002:a81:23d6:: with SMTP id j205mr8215310ywj.333.1561767593959;
	Fri, 28 Jun 2019 17:19:53 -0700 (PDT)
MIME-Version: 1.0
References: <CAMpN3mLvY+kuUGqzMW6SAMZ=h46_g=XLhDPhSY=X6xhLxvi15Q@mail.gmail.com>
	<20190627095031.4d5817b8@simplexum.com>
	<CAMpN3mKPkCPtYkN-JVku1r217-aBK=Rh3UEhvRPS_Y6DixJ9Dw@mail.gmail.com>
	<20190627122916.3b6c2c32@simplexum.com>
	<CAMpN3mL8tyP-6-nwn6dorcq7-dad6wYz8_pXinqHhgzUnrr_tg@mail.gmail.com>
	<20190627181429.15dda570@simplexum.com>
	<20190627202932.1cb4d727@simplexum.com>
	<20190629024816.2193363e@simplexum.com>
In-Reply-To: <20190629024816.2193363e@simplexum.com>
From: Jonathan Underwood <junderwood@bitcoinbank.co.jp>
Date: Sat, 29 Jun 2019 09:19:41 +0900
Message-ID: <CAMpN3m+Oa6oPzAmhoioOkuf8__NSPPNoSEMHJwo9PhjXosMwhg@mail.gmail.com>
To: Dmitry Petukhov <dp@simplexum.com>
Content-Type: multipart/alternative; boundary="000000000000a90c50058c6b5af1"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, 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: Sat, 29 Jun 2019 06:20:23 +0000
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP174 extension proposal (Global Type:
	PSBT_GLOBAL_XPUB_SIGNATURE)
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: Sat, 29 Jun 2019 00:19:57 -0000

--000000000000a90c50058c6b5af1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

replies in-line. Thanks!

2019=E5=B9=B46=E6=9C=8829=E6=97=A5(=E5=9C=9F) 6:46 Dmitry Petukhov <dp@simp=
lexum.com>:

> In your proposed field key format,
>
> {0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}
>
> I think you can replace the signing pubkey with just a fingerprint of
> the master key, that would save 29 bytes per 0x02 field.
>

Good point.


> If the only entity that is concerned about the validity of the
> signature is those that possess the signing_privkey, it will check the
> signature when it sees the 0x02 field starting with its own key
> fingerprint, and will ignore the field if the signature does not match.
>
> If someone other than the signer needs to check that this xpub-package
> was signed by certain cold key, it will need to know signing_pubkey
> anyway, before it parses PSBT, as it won't have the means to check if
> certain pubkey found in 0x02 field in PSBT is related to certain
> signer, without knowing anything about the pubkey beforehand.
>
> I'm not sure if the ability of unrelated parties to verify that
> xpub-package matches its signature is useful in practice. 29 bytes per
> 0x02 field is not a big saving of space, and if this ability is actually
> useful, the saving may not be worh loosing this ability.
>

All good points, I think we'll just use the first 4 bytes of the hash160 of
the pubkey, aka fingerprint.


> Other note: you have 'unused' value of 1 for `m` in your scheme, why
> not require m=3D1 for single-sig case, and use 0 as indicator that there
> are a serlal number following it?
>

0x00 is single sig, aka, OP_CHECKSIG

0x01 is multisig, aka, 1-of-3, 1-of-2 OP_CHECKMULTISIG


> The key for the field would be encoded as
>
> {0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}
>
> for usual case, and
>
> {0x02}|{signing_pubkey}|0x00|{serial}|{m}|{xpub}|...|{xpub}
>
> for the case when the signing scheme actually cares about different
> versions of xpub packages signed by certain cold key
>

since OP_CHECKMULTISIG only supports at most 15-of-15 due to stack item
size limitations, we could make 0xff into this serial marker.


> Going back to the idea of moving 'complex' usecases outside of BIP174:
> maybe we could have a 'BIP-specific' field, that would have the key as
>
> {0x0?}|{BIP-number}|{bip-specific-suffix-data}
>
> so that the different usecases that are not general enough to be
> included in BIP174 itself, may have their own BIPs. Vendor-specific
> fields may also be done as a separate BIP.
>

Definitely sounds good, but the currently proposed 0x01 global type is
being added to BIP174 directly under the assumption that it is useful for
all users of PSBT, and I would argue that 0x01 being an HD change verifying
method, it only seems logical to add a similar method of "verifying"
non-self keys, aka whitelisting for security purposes, and such a feature
would require this data be included into the PSBT sent into the device.

If the consensus is that this data is unneeded, 0x01 should probably also
be a separate BIP.

Though outside the scope of this BIP, one difficulty of a whitelist feature
would be revocation of signatures. If we pre-sign a revocation cert and
somehow make the wallet blacklist if seen... then the question is "if your
signer has a trustworthy store of state, why not store the whitelist
pubkeys?"

But that feature itself should be a separate BIP.

Also, POR_COMMITMENT being in BIP174 kind of set a precedent... :-/


> =D0=92 Thu, 27 Jun 2019 20:29:32 +0500
> Dmitry Petukhov <dp@simplexum.com> wrote:
>
> > Oh, I saw that you covered it in another mail:
> >
> > > The expire / revoke problem is a larger problem than this feature
> > > can handle.
> >
> > > In general, if one of the cold keys is stolen, there is rarely a
> > > situation where you are completely sure the other cold keys haven't
> > > been compromised... so the best practice would be all signers
> > > generate new keys and all funds are moved to a completely new
> > > multisig wallet (no common xpubs).
> >
> > The setup might not be 'all cold keys', but the keys with different
> > levels of exposure to possible theft. In this config, compromise of
> > one of the 'warm' keys might not necessary require changing the
> > 'cold' key.
> >
> > I'm not sure whether this usecase warrants adding extra 'serial'
> > field, but on the other hand it is rather simple change, and those who
> > does not care can always set 0.
> >
> > =D0=92 Thu, 27 Jun 2019 18:14:29 +0500
> > Dmitry Petukhov <dp@simplexum.com> wrote:
> >
> > > What do you think about adding serial number to the xpub package ?
> > >
> > > The key would be
> > >
> > > {0x02}|{signing_pubkey}|{serial}|{m}|{xpub}|...|{xpub}
> > >
> > > and if the signer have the ability to store a counter, it can reject
> > > 'outdated' xpub packages, and only accept those that was signed
> > > using the serial number that it deems recent. This would allow a
> > > limited mechanism to 'revoke' previously signed packages that have
> > > compromized keys in them.
> > >
> > > =D0=92 Thu, 27 Jun 2019 17:16:14 +0900
> > > Jonathan Underwood <junderwood@bitcoinbank.co.jp> wrote:
> > >
> > > > I see what you mean.
> > > >
> > > > What about this?
> > > >
> https://github.com/junderw/bips/commit/57a57b4fae1ae14b77a2eebd99cd719148=
e3027e?short_path=3D82656c8#diff-82656c833e31e6751a412ce5e5c70920
> > > >
> > > > Plus side: for single sig case, the key only increases by one byte
> > > > (0x00 for the {m} value)
> > > >
> > > > This way if it was 2 of 3 like before, you sign the whole "packet"
> > > > so each key only signs the packet once. Way better than n!
> > > >
> > > > Anywho. Please send your feedback. Thanks.
> > > > Jonathan
> > > >
> > > > 2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 16:27 Dmitry Petukhov=
 <dp@simplexum.com>:
> > > >
> > > > > How would signer know that there _should_ be at least 3
> > > > > signatures signed by the key owned by this signer ?
> > > > >
> > > > > If it does not know that it should enforce 2of3 multisig, for
> > > > > example, the attacker that control only one key A can fool
> > > > > signer B by sending to 1of1 single-sig that is derived from A's
> > > > > xpub, and providing only sBxA in PSBT.
> > > > >
> > > > > If the signer does not have a hardcoded configuration that
> > > > > will mandate a particular multisig scheme, it will allow sending
> > > > > to any scheme.
> > > > >
> > > > > If the signer has a rich enough state to store updatable
> > > > > configuration, it can just store the trusted xpubs directly.
> > > > >
> > > > > Alternatively, signer can sign not individual xpubs, but whole
> > > > > xpub packages that correspond to particular multisig
> > > > > configuration, and enforce that destination addresses correspond
> > > > > to this configuration.
> > > > >
> > > > > But this would not be possible with your PSBT scheme that uses
> > > > > individual key-xpub pairs.
> > > > >
> > > > > =D0=92 Thu, 27 Jun 2019 14:07:47 +0900
> > > > > Jonathan Underwood <junderwood@bitcoinbank.co.jp> wrote:
> > > > >
> > > > > > Thanks for the reply.
> > > > > >
> > > > > > The way we would do it is:
> > > > > >
> > > > > > Let's say we have 3 cold keys for multisig: A B and C
> > > > > >
> > > > > > Whose xpubs are: xA xB and xC
> > > > > >
> > > > > > We all sign each other's xpubs, whose signatures are:
> > > > > > sAxB
> > > > > > sAxC
> > > > > > sBxA
> > > > > > sBxC
> > > > > > sCxA
> > > > > > sCxB
> > > > > >
> > > > > > We can then create a wallet that says "when verifying change
> > > > > > with 0x01 global type proposed by Andrew Chow, if the change
> > > > > > is multisig, we MUST require the other pubkeys to have
> > > > > > signatures via my 0x02 proposal"
> > > > > >
> > > > > > This way, all my PSBTs for my cold will have:
> > > > > > 1. an 0x01 entry to tell me how to get my change.
> > > > > > 2. All 6 of the signatures above.
> > > > > >
> > > > > > And the signer will then look at the change, check my pubkey
> > > > > > by deriving the xpub and checking equality to the
> > > > > > BIP_DERIVATION of the output... it will then check the OTHER
> > > > > > pubkeys via BIP32_DERIVATION to master fingerprint, then link
> > > > > > that fingerprint to a 0x02 sig from MY key, verifying all
> > > > > > pubkeys.
> > > > > >
> > > > > > So this proposal of mine would not only fix the "send to
> > > > > > address verification" problem for HD, but also the multisig
> > > > > > change problem with 0x01.
> > > > > >
> > > > > > Cool.
> > > > > >
> > > > > > Only thing that is kind of sad is having to include n! (of
> > > > > > m-of-n) signatures in every PSBT... but tbh, the PSBT size is
> > > > > > not of much concern.
> > > > > >
> > > > > > Thanks for the reply.
> > > > > > - Jonathan
> > > > > >
> > > > > >
> > > > > > 2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 13:49 Dmitry Petu=
khov <dp@simplexum.com>:
> > > > > >
> > > > > > > Hi!
> > > > > > >
> > > > > > > I wonder how your scheme handles multisig ?
> > > > > > >
> > > > > > > As I understand, you sign individual xpubs with cold keys,
> > > > > > > so that cold keys can check destination addresses are
> > > > > > > trusted.
> > > > > > >
> > > > > > > I seems to me that if you sign individual xpubs of a
> > > > > > > multisig warm wallet, and one key from that multisig is
> > > > > > > compromized, attackers can then create a single-sig
> > > > > > > destination address that they control, and move the coins
> > > > > > > in a chain of two transactions, first to this single-sig
> > > > > > > address, and then to an address that they independently
> > > > > > > control.
> > > > > > >
> > > > > > > My idea to prevent this [1] is to sign the whole 'xpub
> > > > > > > package' of the multisig wallet, but there is also an issue
> > > > > > > of 'partial compromize', where some of the keys in a
> > > > > > > multisig warm wallet is compromized, and you do not want to
> > > > > > > regard a particular 'xpub package' as trusted. My idea was
> > > > > > > [2] to use an auxiliary message that would be signed along
> > > > > > > with the 'xpub package', and that message can include
> > > > > > > specific 'epoch' word that hardware wallet can show
> > > > > > > prominently before signing, or have 'serial number' for
> > > > > > > xpub packages (but that will require to store last known
> > > > > > > serial inside hw wallet, making it stateful).
> > > > > > >
> > > > > > > I like the idea to extend PSBT to accomodate these schemes,
> > > > > > > but given that the huge number of possible schemes that each
> > > > > > > may probably require its own PSBT field type, I think that
> > > > > > > this is better dealt with outside of PSBT, as 'PSBT
> > > > > > > metainformation', or using some form of 'vendor-specific',
> > > > > > > or 'metainformation-specific' PSBT field. This way each
> > > > > > > usecase can be independently described in its own
> > > > > > > documentation, that would include the particulars of the
> > > > > > > format for the metainformation. This would also make it
> > > > > > > easier to implement PSBT for simple cases, because the
> > > > > > > 'core specification' would not grow that big.
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > > >
> > > > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016917.h=
tml
>
> > > > > > >
> > > > > > > [2]
> > > > > > >
> > > > > > >
> > > > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016926.h=
tml
>
> > > > > > >
> > > > > > >
> > > > > > > =D0=92 Thu, 27 Jun 2019 11:11:23 +0900 Jonathan Underwood via
> > > > > > > bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > > Hello all,
> > > > > > > >
> > > > > > > > Just wanted to pick your brains about an idea for PSBT
> > > > > > > > extension.
> > > > > > > >
> > > > > > > > One problem we try to solve with cold -> warm and warm ->
> > > > > > > > hot sends for our exchange wallet is "How do I know that
> > > > > > > > the address I am sending to is not a hacker's address
> > > > > > > > that was swapped in between unsigned tx creation and first
> > > > > > > > signature?"
> > > > > > > >
> > > > > > > > We have a proprietary JSON based encoding system which we
> > > > > > > > are looking to move towards PSBT, but PSBT is missing this
> > > > > > > > key functionality.
> > > > > > > >
> > > > > > > > BIP32_DERIVATION does allow us to verify the address is
> > > > > > > > from a certain XPUB, but, for example, it can not allow us
> > > > > > > > to verify a signature of that xpub.
> > > > > > > >
> > > > > > > > I have made a rough draft of the proposed key value
> > > > > > > > specification.
> > > > > > >
> > > > >
> https://github.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specif=
ication
> > > > >
> > > > > > > >
> > > > > > > > The signing key path used in the spec is just randomly
> > > > > > > > chosen 31 x 4 bits shown as numbers with hardened paths.
> > > > > > > >
> > > > > > > > Since this issue seems similar to the change address
> > > > > > > > issue, I started from that as a base. With the HW wallet
> > > > > > > > case, I can verify the xpub by just deriving it locally
> > > > > > > > and comparing equality, however, in our case, we need to
> > > > > > > > verify an xpub that we do not have access to via
> > > > > > > > derivation from our cold key(s) (since we don't want to
> > > > > > > > import our warm private key into our cold signer)
> > > > > > > >
> > > > > > > > So the flow would be:
> > > > > > > > 1. Securely verify the xpub of the warm / hot wallet.
> > > > > > > > 2. Using the airgap signing tool, sign the xpub with all
> > > > > > > > cold keys. 3. Upload the signature/xpub pairs to the
> > > > > > > > online unsigned transaction generator.
> > > > > > > > 4. Include one keyval pair per coldkey/xpub pairing.
> > > > > > > > 5. When offline signing, if the wallet detects there is a
> > > > > > > > global keyval XPUB_SIGNATURE with its pubkey in the key,
> > > > > > > > it must verify that all outputs have BIP32_DERIVATION and
> > > > > > > > that it can verify the outputs through the derivation, to
> > > > > > > > the xpub, and to the signature.
> > > > > > > >
> > > > > > > > In my attempt to fitting this into PSBT, I am slightly
> > > > > > > > altering our current system, so don't take this as an
> > > > > > > > indication 100% of how we work in the backend.
> > > > > > > >
> > > > > > > > However, I would like to hear any feedback on this
> > > > > > > > proposal.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Jonathan
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
>

--000000000000a90c50058c6b5af1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>replies in-line. Thanks!<br><br><div class=3D"gmail_=
quote"><div dir=3D"ltr" class=3D"gmail_attr">2019=E5=B9=B46=E6=9C=8829=E6=
=97=A5(=E5=9C=9F) 6:46 Dmitry Petukhov &lt;<a href=3D"mailto:dp@simplexum.c=
om">dp@simplexum.com</a>&gt;:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In yo=
ur proposed field key format,<br>
<br>
{0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}<br>
<br>
I think you can replace the signing pubkey with just a fingerprint of<br>
the master key, that would save 29 bytes per 0x02 field.<br></blockquote></=
div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Good point.</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><br></blockquote><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If the only entity that is concerned about the validity of the<br>
signature is those that possess the signing_privkey, it will check the<br>
signature when it sees the 0x02 field starting with its own key<br>
fingerprint, and will ignore the field if the signature does not match.<br>
<br>
If someone other than the signer needs to check that this xpub-package<br>
was signed by certain cold key, it will need to know signing_pubkey<br>
anyway, before it parses PSBT, as it won&#39;t have the means to check if<b=
r>
certain pubkey found in 0x02 field in PSBT is related to certain<br>
signer, without knowing anything about the pubkey beforehand.<br>
<br>
I&#39;m not sure if the ability of unrelated parties to verify that<br>
xpub-package matches its signature is useful in practice. 29 bytes per<br>
0x02 field is not a big saving of space, and if this ability is actually<br=
>
useful, the saving may not be worh loosing this ability.<br></blockquote></=
div></div><div dir=3D"auto"><br></div><div dir=3D"auto">All good points, I =
think we&#39;ll just use the first 4 bytes of the hash160 of the pubkey, ak=
a fingerprint.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div clas=
s=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Other note: you have &#39;unused&#39; value of 1 for `m` in your scheme, wh=
y<br>
not require m=3D1 for single-sig case, and use 0 as indicator that there<br=
>
are a serlal number following it?<br></blockquote></div></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">0x00 is single sig, aka, OP_CHECKSIG</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">0x01 is multisig, aka, 1-of-3=
, 1-of-2 OP_CHECKMULTISIG</div><div dir=3D"auto"><br></div><div dir=3D"auto=
"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The key for the field would be encoded as<br>
<br>
{0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}<br>
<br>
for usual case, and<br>
<br>
{0x02}|{signing_pubkey}|0x00|{serial}|{m}|{xpub}|...|{xpub}<br>
<br>
for the case when the signing scheme actually cares about different<br>
versions of xpub packages signed by certain cold key<br></blockquote></div>=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">since OP_CHECKMULTISIG =
only supports at most 15-of-15 due to stack item size limitations, we could=
 make 0xff into this serial marker.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Going back to the idea of moving &#39;complex&#39; usecases outside of BIP1=
74:<br>
maybe we could have a &#39;BIP-specific&#39; field, that would have the key=
 as<br>
<br>
{0x0?}|{BIP-number}|{bip-specific-suffix-data}<br>
<br>
so that the different usecases that are not general enough to be<br>
included in BIP174 itself, may have their own BIPs. Vendor-specific<br>
fields may also be done as a separate BIP.<br></blockquote></div></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">Definitely sounds good, but the c=
urrently proposed 0x01 global type is being added to BIP174 directly under =
the assumption that it is useful for all users of PSBT, and I would argue t=
hat 0x01 being an HD change verifying method, it only seems logical to add =
a similar method of &quot;verifying&quot; non-self keys, aka whitelisting f=
or security purposes, and such a feature would require this data be include=
d into the PSBT sent into the device.</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">If the consensus is that this data is unneeded, 0x01 should p=
robably also be a separate BIP.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Though outside the scope of this BIP, one difficulty of a whiteli=
st feature would be revocation of signatures. If we pre-sign a revocation c=
ert and somehow make the wallet blacklist if seen... then the question is &=
quot;if your signer has a trustworthy store of state, why not store the whi=
telist pubkeys?&quot;</div><div dir=3D"auto"><br></div><div dir=3D"auto">Bu=
t that feature itself should be a separate BIP.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Also, POR_COMMITMENT being in BIP174 kind of set a =
precedent... :-/</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
=D0=92 Thu, 27 Jun 2019 20:29:32 +0500<br>
Dmitry Petukhov &lt;<a href=3D"mailto:dp@simplexum.com" target=3D"_blank" r=
el=3D"noreferrer">dp@simplexum.com</a>&gt; wrote:<br>
<br>
&gt; Oh, I saw that you covered it in another mail:<br>
&gt; <br>
&gt; &gt; The expire / revoke problem is a larger problem than this feature=
<br>
&gt; &gt; can handle.=C2=A0 <br>
&gt; <br>
&gt; &gt; In general, if one of the cold keys is stolen, there is rarely a<=
br>
&gt; &gt; situation where you are completely sure the other cold keys haven=
&#39;t<br>
&gt; &gt; been compromised... so the best practice would be all signers<br>
&gt; &gt; generate new keys and all funds are moved to a completely new<br>
&gt; &gt; multisig wallet (no common xpubs).=C2=A0 <br>
&gt; <br>
&gt; The setup might not be &#39;all cold keys&#39;, but the keys with diff=
erent<br>
&gt; levels of exposure to possible theft. In this config, compromise of<br=
>
&gt; one of the &#39;warm&#39; keys might not necessary require changing th=
e<br>
&gt; &#39;cold&#39; key.<br>
&gt; <br>
&gt; I&#39;m not sure whether this usecase warrants adding extra &#39;seria=
l&#39;<br>
&gt; field, but on the other hand it is rather simple change, and those who=
<br>
&gt; does not care can always set 0. <br>
&gt; <br>
&gt; =D0=92 Thu, 27 Jun 2019 18:14:29 +0500<br>
&gt; Dmitry Petukhov &lt;<a href=3D"mailto:dp@simplexum.com" target=3D"_bla=
nk" rel=3D"noreferrer">dp@simplexum.com</a>&gt; wrote:<br>
&gt; <br>
&gt; &gt; What do you think about adding serial number to the xpub package =
?<br>
&gt; &gt; <br>
&gt; &gt; The key would be <br>
&gt; &gt; <br>
&gt; &gt; {0x02}|{signing_pubkey}|{serial}|{m}|{xpub}|...|{xpub}<br>
&gt; &gt; <br>
&gt; &gt; and if the signer have the ability to store a counter, it can rej=
ect<br>
&gt; &gt; &#39;outdated&#39; xpub packages, and only accept those that was =
signed<br>
&gt; &gt; using the serial number that it deems recent. This would allow a<=
br>
&gt; &gt; limited mechanism to &#39;revoke&#39; previously signed packages =
that have<br>
&gt; &gt; compromized keys in them.<br>
&gt; &gt; <br>
&gt; &gt; =D0=92 Thu, 27 Jun 2019 17:16:14 +0900<br>
&gt; &gt; Jonathan Underwood &lt;<a href=3D"mailto:junderwood@bitcoinbank.c=
o.jp" target=3D"_blank" rel=3D"noreferrer">junderwood@bitcoinbank.co.jp</a>=
&gt; wrote:<br>
&gt; &gt;=C2=A0 =C2=A0<br>
&gt; &gt; &gt; I see what you mean.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; What about this?<br>
&gt; &gt; &gt; <a href=3D"https://github.com/junderw/bips/commit/57a57b4fae=
1ae14b77a2eebd99cd719148e3027e?short_path=3D82656c8#diff-82656c833e31e6751a=
412ce5e5c70920" rel=3D"noreferrer noreferrer" target=3D"_blank">https://git=
hub.com/junderw/bips/commit/57a57b4fae1ae14b77a2eebd99cd719148e3027e?short_=
path=3D82656c8#diff-82656c833e31e6751a412ce5e5c70920</a><br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Plus side: for single sig case, the key only increases by on=
e byte<br>
&gt; &gt; &gt; (0x00 for the {m} value)<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; This way if it was 2 of 3 like before, you sign the whole &q=
uot;packet&quot;<br>
&gt; &gt; &gt; so each key only signs the packet once. Way better than n!<b=
r>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Anywho. Please send your feedback. Thanks.<br>
&gt; &gt; &gt; Jonathan<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; 2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 16:27 Dmitry P=
etukhov &lt;<a href=3D"mailto:dp@simplexum.com" target=3D"_blank" rel=3D"no=
referrer">dp@simplexum.com</a>&gt;:<br>
&gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0<br>
&gt; &gt; &gt; &gt; How would signer know that there _should_ be at least 3=
<br>
&gt; &gt; &gt; &gt; signatures signed by the key owned by this signer ?<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; If it does not know that it should enforce 2of3 multisi=
g, for<br>
&gt; &gt; &gt; &gt; example, the attacker that control only one key A can f=
ool<br>
&gt; &gt; &gt; &gt; signer B by sending to 1of1 single-sig that is derived =
from A&#39;s<br>
&gt; &gt; &gt; &gt; xpub, and providing only sBxA in PSBT.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; If the signer does not have a hardcoded configuration t=
hat<br>
&gt; &gt; &gt; &gt; will mandate a particular multisig scheme, it will allo=
w sending<br>
&gt; &gt; &gt; &gt; to any scheme.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; If the signer has a rich enough state to store updatabl=
e<br>
&gt; &gt; &gt; &gt; configuration, it can just store the trusted xpubs dire=
ctly.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Alternatively, signer can sign not individual xpubs, bu=
t whole<br>
&gt; &gt; &gt; &gt; xpub packages that correspond to particular multisig<br=
>
&gt; &gt; &gt; &gt; configuration, and enforce that destination addresses c=
orrespond<br>
&gt; &gt; &gt; &gt; to this configuration.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; But this would not be possible with your PSBT scheme th=
at uses<br>
&gt; &gt; &gt; &gt; individual key-xpub pairs.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; =D0=92 Thu, 27 Jun 2019 14:07:47 +0900<br>
&gt; &gt; &gt; &gt; Jonathan Underwood &lt;<a href=3D"mailto:junderwood@bit=
coinbank.co.jp" target=3D"_blank" rel=3D"noreferrer">junderwood@bitcoinbank=
.co.jp</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; &gt; Thanks for the reply.<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; The way we would do it is:<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; Let&#39;s say we have 3 cold keys for multisig: A =
B and C<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; Whose xpubs are: xA xB and xC<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; We all sign each other&#39;s xpubs, whose signatur=
es are:<br>
&gt; &gt; &gt; &gt; &gt; sAxB<br>
&gt; &gt; &gt; &gt; &gt; sAxC<br>
&gt; &gt; &gt; &gt; &gt; sBxA<br>
&gt; &gt; &gt; &gt; &gt; sBxC<br>
&gt; &gt; &gt; &gt; &gt; sCxA<br>
&gt; &gt; &gt; &gt; &gt; sCxB<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; We can then create a wallet that says &quot;when v=
erifying change<br>
&gt; &gt; &gt; &gt; &gt; with 0x01 global type proposed by Andrew Chow, if =
the change<br>
&gt; &gt; &gt; &gt; &gt; is multisig, we MUST require the other pubkeys to =
have<br>
&gt; &gt; &gt; &gt; &gt; signatures via my 0x02 proposal&quot;<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; This way, all my PSBTs for my cold will have:<br>
&gt; &gt; &gt; &gt; &gt; 1. an 0x01 entry to tell me how to get my change.<=
br>
&gt; &gt; &gt; &gt; &gt; 2. All 6 of the signatures above.<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; And the signer will then look at the change, check=
 my pubkey<br>
&gt; &gt; &gt; &gt; &gt; by deriving the xpub and checking equality to the<=
br>
&gt; &gt; &gt; &gt; &gt; BIP_DERIVATION of the output... it will then check=
 the OTHER<br>
&gt; &gt; &gt; &gt; &gt; pubkeys via BIP32_DERIVATION to master fingerprint=
, then link<br>
&gt; &gt; &gt; &gt; &gt; that fingerprint to a 0x02 sig from MY key, verify=
ing all<br>
&gt; &gt; &gt; &gt; &gt; pubkeys.<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; So this proposal of mine would not only fix the &q=
uot;send to<br>
&gt; &gt; &gt; &gt; &gt; address verification&quot; problem for HD, but als=
o the multisig<br>
&gt; &gt; &gt; &gt; &gt; change problem with 0x01.<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; Cool.<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; Only thing that is kind of sad is having to includ=
e n! (of<br>
&gt; &gt; &gt; &gt; &gt; m-of-n) signatures in every PSBT... but tbh, the P=
SBT size is<br>
&gt; &gt; &gt; &gt; &gt; not of much concern.<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; Thanks for the reply.<br>
&gt; &gt; &gt; &gt; &gt; - Jonathan<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; 2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 13:4=
9 Dmitry Petukhov &lt;<a href=3D"mailto:dp@simplexum.com" target=3D"_blank"=
 rel=3D"noreferrer">dp@simplexum.com</a>&gt;:<br>
&gt; &gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; &gt; &gt; Hi!<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; I wonder how your scheme handles multisig ?<b=
r>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; As I understand, you sign individual xpubs wi=
th cold keys,<br>
&gt; &gt; &gt; &gt; &gt; &gt; so that cold keys can check destination addre=
sses are<br>
&gt; &gt; &gt; &gt; &gt; &gt; trusted.<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; I seems to me that if you sign individual xpu=
bs of a<br>
&gt; &gt; &gt; &gt; &gt; &gt; multisig warm wallet, and one key from that m=
ultisig is<br>
&gt; &gt; &gt; &gt; &gt; &gt; compromized, attackers can then create a sing=
le-sig<br>
&gt; &gt; &gt; &gt; &gt; &gt; destination address that they control, and mo=
ve the coins<br>
&gt; &gt; &gt; &gt; &gt; &gt; in a chain of two transactions, first to this=
 single-sig<br>
&gt; &gt; &gt; &gt; &gt; &gt; address, and then to an address that they ind=
ependently<br>
&gt; &gt; &gt; &gt; &gt; &gt; control.<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; My idea to prevent this [1] is to sign the wh=
ole &#39;xpub<br>
&gt; &gt; &gt; &gt; &gt; &gt; package&#39; of the multisig wallet, but ther=
e is also an issue<br>
&gt; &gt; &gt; &gt; &gt; &gt; of &#39;partial compromize&#39;, where some o=
f the keys in a<br>
&gt; &gt; &gt; &gt; &gt; &gt; multisig warm wallet is compromized, and you =
do not want to<br>
&gt; &gt; &gt; &gt; &gt; &gt; regard a particular &#39;xpub package&#39; as=
 trusted. My idea was<br>
&gt; &gt; &gt; &gt; &gt; &gt; [2] to use an auxiliary message that would be=
 signed along<br>
&gt; &gt; &gt; &gt; &gt; &gt; with the &#39;xpub package&#39;, and that mes=
sage can include<br>
&gt; &gt; &gt; &gt; &gt; &gt; specific &#39;epoch&#39; word that hardware w=
allet can show<br>
&gt; &gt; &gt; &gt; &gt; &gt; prominently before signing, or have &#39;seri=
al number&#39; for<br>
&gt; &gt; &gt; &gt; &gt; &gt; xpub packages (but that will require to store=
 last known<br>
&gt; &gt; &gt; &gt; &gt; &gt; serial inside hw wallet, making it stateful).=
<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; I like the idea to extend PSBT to accomodate =
these schemes,<br>
&gt; &gt; &gt; &gt; &gt; &gt; but given that the huge number of possible sc=
hemes that each<br>
&gt; &gt; &gt; &gt; &gt; &gt; may probably require its own PSBT field type,=
 I think that<br>
&gt; &gt; &gt; &gt; &gt; &gt; this is better dealt with outside of PSBT, as=
 &#39;PSBT<br>
&gt; &gt; &gt; &gt; &gt; &gt; metainformation&#39;, or using some form of &=
#39;vendor-specific&#39;,<br>
&gt; &gt; &gt; &gt; &gt; &gt; or &#39;metainformation-specific&#39; PSBT fi=
eld. This way each<br>
&gt; &gt; &gt; &gt; &gt; &gt; usecase can be independently described in its=
 own<br>
&gt; &gt; &gt; &gt; &gt; &gt; documentation, that would include the particu=
lars of the<br>
&gt; &gt; &gt; &gt; &gt; &gt; format for the metainformation. This would al=
so make it<br>
&gt; &gt; &gt; &gt; &gt; &gt; easier to implement PSBT for simple cases, be=
cause the<br>
&gt; &gt; &gt; &gt; &gt; &gt; &#39;core specification&#39; would not grow t=
hat big.<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; [1]<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/=
bitcoin-dev/2019-May/016917.html" rel=3D"noreferrer noreferrer" target=3D"_=
blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016=
917.html</a>=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; [2]<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/=
bitcoin-dev/2019-May/016926.html" rel=3D"noreferrer noreferrer" target=3D"_=
blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016=
926.html</a>=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; =D0=92 Thu, 27 Jun 2019 11:11:23 +0900 Jonath=
an Underwood via<br>
&gt; &gt; &gt; &gt; &gt; &gt; bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-de=
v@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; Hello all,<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; Just wanted to pick your brains about an=
 idea for PSBT<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; extension.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; One problem we try to solve with cold -&=
gt; warm and warm -&gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; hot sends for our exchange wallet is &qu=
ot;How do I know that<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; the address I am sending to is not a hac=
ker&#39;s address<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; that was swapped in between unsigned tx =
creation and first<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; signature?&quot;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; We have a proprietary JSON based encodin=
g system which we<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; are looking to move towards PSBT, but PS=
BT is missing this<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; key functionality.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; BIP32_DERIVATION does allow us to verify=
 the address is<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; from a certain XPUB, but, for example, i=
t can not allow us<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; to verify a signature of that xpub.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; I have made a rough draft of the propose=
d key value<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; specification.=C2=A0 =C2=A0 =C2=A0<br>
&gt; &gt; &gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; <a href=3D"https://github.com/junderw/bips/blob/addXpub=
Sig/bip-0174.mediawiki#specification" rel=3D"noreferrer noreferrer" target=
=3D"_blank">https://github.com/junderw/bips/blob/addXpubSig/bip-0174.mediaw=
iki#specification</a><br>
&gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; The signing key path used in the spec is=
 just randomly<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; chosen 31 x 4 bits shown as numbers with=
 hardened paths.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; Since this issue seems similar to the ch=
ange address<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; issue, I started from that as a base. Wi=
th the HW wallet<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; case, I can verify the xpub by just deri=
ving it locally<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; and comparing equality, however, in our =
case, we need to<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; verify an xpub that we do not have acces=
s to via<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; derivation from our cold key(s) (since w=
e don&#39;t want to<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; import our warm private key into our col=
d signer)<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; So the flow would be:<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; 1. Securely verify the xpub of the warm =
/ hot wallet.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; 2. Using the airgap signing tool, sign t=
he xpub with all<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; cold keys. 3. Upload the signature/xpub =
pairs to the<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; online unsigned transaction generator.<b=
r>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; 4. Include one keyval pair per coldkey/x=
pub pairing.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; 5. When offline signing, if the wallet d=
etects there is a<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; global keyval XPUB_SIGNATURE with its pu=
bkey in the key,<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; it must verify that all outputs have BIP=
32_DERIVATION and<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; that it can verify the outputs through t=
he derivation, to<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; the xpub, and to the signature.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; In my attempt to fitting this into PSBT,=
 I am slightly<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; altering our current system, so don&#39;=
t take this as an<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; indication 100% of how we work in the ba=
ckend.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; However, I would like to hear any feedba=
ck on this<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; proposal.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; Thanks,<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; Jonathan<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0<br>
&gt; &gt;=C2=A0 =C2=A0<br>
&gt; <br>
<br>
</blockquote></div></div></div>

--000000000000a90c50058c6b5af1--