summaryrefslogtreecommitdiff
path: root/c4/1f96c8b69dea51781a529e55a3dc8755d43e25
blob: 4c08676b4f572726624bd1396d40224b09bf19da (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
Return-Path: <achow101-lists@achow101.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 45C2FC013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 15 Jan 2021 17:28:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 0273186B34
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 15 Jan 2021 17:28:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id hp1Y-H3txPFw
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 15 Jan 2021 17:28:31 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-41104.protonmail.ch (mail-41104.protonmail.ch
 [185.70.41.104])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id E695A86B04
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 15 Jan 2021 17:28:30 +0000 (UTC)
Received: from mail-02.mail-europe.com (mail-02.mail-europe.com
 [51.89.119.103])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits))
 (No client certificate requested)
 by mail-41104.protonmail.ch (Postfix) with ESMTPS id AF4A223F17C5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 15 Jan 2021 17:28:28 +0000 (UTC)
Authentication-Results: mail-41104.protonmail.ch;
 dkim=pass (2048-bit key) header.d=achow101.com header.i=@achow101.com
 header.b="tvUzcnkA"
Date: Fri, 15 Jan 2021 17:28:09 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com;
 s=protonmail3; t=1610731697;
 bh=fa46cazu9xk56Tmg8CLTquEzm5x6V4UB90to4LmJ2Xk=;
 h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
 b=tvUzcnkAXB1usqzmS8b3duXd79re/GJXPBiwTw4CCKRuriBD7yfclFXKcb8277ig5
 RIBm47HMFj3jlQup/ODSaXJOniq+uf+wULVPcCeCS4ZwDGNm8vlURN5lrFxmW+yGni
 j/vYj4VblzehNHWKn2RfdnYfezmm/CKal2xzB/0Q+8ABn/EtfUyI6WAfVjHnXMsqv9
 uXUE7Z9oq635D61IY7n9loLdL8bmRlOSlolPZ/QCc3pCC2HytAs2BVShbhhvKBBEuh
 q+XKdK9Bh8BxL3C5f3PUua8QDKMTjBjOz5OHoDn/wl89KT/pYw54KplPL8qG9VITAq
 bc/OWWVi2fMKQ==
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Andrew Chow <achow101-lists@achow101.com>
Reply-To: Andrew Chow <achow101-lists@achow101.com>
Message-ID: <e87f1e08-4bf2-8bf5-d408-3c0b603b8a7f@achow101.com>
In-Reply-To: <40089cb5-8d68-1868-c87b-241f2bd747fb@achow101.com>
References: <1dd8c285-e3f4-4f03-d608-103a5026146d@achow101.com>
 <5a4697cb-b9cb-b925-e78f-d5b53f025704@achow101.com>
 <40089cb5-8d68-1868-c87b-241f2bd747fb@achow101.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] New PSBT version proposal
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jan 2021 17:28:35 -0000

Hi All,

I've made some reorganization changes to the way that new PSBT versions=20
should be handled in BIP 174 (see=20
https://github.com/bitcoin/bips/pull/1055) so PSBTv2 will be submitted=20
as a separate BIP. The full document can be read at=20
https://github.com/achow101/bips/blob/psbt2/bip-psbt2.mediawiki and I=20
have also included it in this email.

I've included Rusty's suggestion for PSBT_GLOBAL_UNDER_CONSTRUCTION and=20
made a few modifications. First, the field will be named=20
PSBT_GLOBAL_TX_MODIFIABLE and only include the inputs modifiable and=20
outputs modifiable flags. The SIGHASH_SINGLE bitmap will be included as=20
a separate field PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS. This allows most=20
PSBTs to not have to carry around a useless bitmap.

Andrew

***

<pre>
 =C2=A0 BIP: PSBTv2
 =C2=A0 Layer: Applications
 =C2=A0 Title: PSBT Version 2
 =C2=A0 Author: Andrew Chow <achow101@gmail.com>
 =C2=A0 Comments-Summary: No comments yet.
 =C2=A0 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-PSB=
T2
 =C2=A0 Status: Draft
 =C2=A0 Type: Standards Track
 =C2=A0 Created: 2021-01-14
 =C2=A0 License: BSD-2-Clause
</pre>

=3D=3DIntroduction=3D=3D

=3D=3D=3DAbstract=3D=3D=3D

This document proposes a second version of the Partially Signed Bitcoin=20
Transaction format
described in BIP 174 which allows for inputs and outputs to be added to=20
the PSBT after creation.

=3D=3D=3DCopyright=3D=3D=3D

This BIP is licensed under the 2-clause BSD license.

=3D=3D=3DMotivation=3D=3D=3D

Partially Signed Bitcoin Transaction Version 0 as described in BIP 174=20
is unable to have new
inputs and outputs be added to the transaction. The fixed global=20
unsigned transaction
cannot be changed which prevents any additional inputs or outputs to be=20
added.
PSBT Version 2 is intended to rectify this problem.

An additional benficial side effect is that all information for a given=20
input or output will be
provided by its <tt><input-map></tt> or <tt><output-map></tt>. With=20
Version 0, to retrieve
all of the information for an input or output, data would need to be=20
found in two locations:
the <tt><input-map></tt>/<tt><output-map></tt> and the global unsigned=20
transaction. PSBT
Version 2 now moves all related information to one place.

=3D=3DSpecification=3D=3D

PSBT Version 2 (PSBTv2) only specifies new fields and field=20
inclusion/exclusion requirements.

<tt>PSBT_GLOBAL_UNSIGNED_TX</tt> must be excluded in PSBTv2.
<tt>PSBT_GLOBAL_VERSION</tt> must be included in PSBTv2 and set to=20
version number 2<ref>'''What happened to version number 1?'''
Version number 1 is skipped because PSBT Version 0 has been colloquially=20
referred to as version 1. Originally this BIP was to be
version 1, but because it has been colloquially referred to as version 2=20
during its design phrase, it was decided to change the
version number to 2 so that there would not be any confusion</ref>.

The new global types for PSBT Version 2 are as follows:

{|
! Name
! <tt><keytype></tt>
! <tt><keydata></tt>
! <tt><keydata></tt> Description
! <tt><valuedata></tt>
! <tt><valuedata></tt> Description
! Versions Requiring Inclusion
! Versions Requiring Exclusion
! Versions Allowing Inclusion
|-
| Transaction Version
| <tt>PSBT_GLOBAL_TX_VERSION =3D 0x02</tt>
| None
| No key data
| <tt><32-bit uint></tt>
| The 32-bit little endian signed integer representing the version=20
number of the transaction being created. Note that this is not the same=20
as the PSBT version number specified by the PSBT_GLOBAL_VERSION field.
| 2
| 0
| 2
|-
| Fallback Locktime
| <tt>PSBT_GLOBAL_FALLBACK_LOCKTIME =3D 0x03</tt>
| None
| No key data
| <tt><32-bit uint></tt>
| The 32-bit little endian unsigned integer representing the transaction=20
locktime to use if no inputs specify a required locktime.
|
| 0
| 2
|-
| Input Count
| <tt>PSBT_GLOBAL_INPUT_COUNT =3D 0x04</tt>
| None
| No key data
| <tt><compact size uint></tt>
| Compact size unsigned integer representing the number of inputs in=20
this PSBT.
| 2
| 0
| 2
|-
| Output Count
| <tt>PSBT_GLOBAL_OUTPUT_COUNT =3D 0x05</tt>
| None
| No key data
| <tt><compact size uint></tt>
| Compact size unsigned integer representing the number of outputs in=20
this PSBT.
| 2
| 0
| 2
|-
| Transaction Modifiable Flags
| <tt>PSBT_GLOBAL_TX_MODIFIABLE =3D 0x06</tt>
| None
| No key data
| <tt><single byte boolean> <single byte boolean></tt>
| A single byte boolean (0 for False, 1 for True) representing whether=20
inputs can be modified, referred to as the Inputs Modifiable Flag. This=20
is followed by a single byte boolean representing whether outputs can be=20
modified, referred to as the Outputs Modifiable Flag.
|
| 0
| 2
|-
| SIGHASH_SINGLE Inputs
| <tt>PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS =3D 0x07</tt>
| None
| No key data
| <tt><bit vector></tt>
| A bit vector representing which input indexes use SIGHASH_SINGLE. If=20
the bit for an index is set to 1, then the input and output pair at that=20
index are tied together with SIGHASH_SINGLE and must be moved together.
|
| 0
| 2
|}

The new per-input types for PSBT Version 2 are defined as follows:

{|
! Name
! <tt><keytype></tt>
! <tt><keydata></tt>
! <tt><keydata></tt> Description
! <tt><valuedata></tt>
! <tt><valuedata></tt> Description
! Versions Requiring Inclusion
! Versions Requiring Exclusion
! Versions Allowing Inclusion
|-
| Previous TXID
| <tt>PSBT_IN_PREVIOUS_TXID =3D 0x0e</tt>
| None
| No key data
| <tt><txid></tt>
| 32 byte txid of the previous transaction whose output at=20
PSBT_IN_OUTPUT_INDEX is being spent.
| 2
| 0
| 2
|-
| Spent Output Index
| <tt>PSBT_IN_OUTPUT_INDEX =3D 0x0f</tt>
| None
| No key data
| <tt><32-bit uint></tt>
| 32 bit little endian integer representing the index of the output=20
being spent in the transaction with the txid of PSBT_IN_PREVIOUS_TXID.
| 2
| 0
| 2
|-
| Sequence Number
| <tt>PSBT_IN_SEQUENCE =3D 0x10</tt>
| None
| No key data
| <tt><32-bit uint></tt>
| The 32 bit unsigned little endian integer for the sequence number of=20
this input. If omitted, the sequence number is assumed to be the final=20
sequence number (0xffffffff).
|
| 0
| 2
|-
| Required Time-based Locktime
| <tt>PSBT_IN_REQUIRED_TIME_LOCKTIME =3D 0x11</tt>
| None
| No key data
| <tt><32-bit uint></tt>
| 32 bit unsigned little endian integer greater than or equal to=20
500000000 representing the minimum Unix timestamp that this input=20
requires to be set as the transaction's lock time.
|
| 0
| 2
|-
| Required Height-based Locktime
| <tt>PSBT_IN_REQUIRED_HEIGHT_LOCKTIME =3D 0x12</tt>
| None
| No key data
| <tt><32-bit uiht></tt>
| 32 bit unsigned little endian integer less than 500000000 representing=20
the minimum block height that this input requires to be set as the=20
transaction's lock time.
|
| 0
| 2
|}

The new per-output types for PSBT Version 2 are defined as follows:

{|
! Name
! <tt><keytype></tt>
! <tt><keydata></tt>
! <tt><keydata></tt> Description
! <tt><valuedata></tt>
! <tt><valuedata></tt> Description
! Versions Requiring Inclusion
! Versions Requiring Exclusion
! Versions Allowing Inclusion
|-
| Output Amount
| <tt>PSBT_OUT_AMOUNT =3D 0x03</tt>
| None
| No key data
| <tt><64-bit uint></tt>
| 64 bit signed little endian integer representing the output's amount=20
in satoshis.
| 2
| 0
| 2
|-
| Output Script
| <tt>PSBT_OUT_SCRIPT =3D 0x03</tt>
| None
| No key data
| <tt><script></tt>
| The script for this output, also known as the scriptPubKey. Must be=20
omitted in PSBTv0. Must be provided in PSBTv2.
| 2
| 0
| 2
|}

=3D=3D=3DDetermining Lock Time=3D=3D=3D

The nLockTime field of a transaction is determined by inspecting the=20
PSBT_GLOBAL_PREFERRED_LOCKTIME and each input's=20
PSBT_IN_REQUIRED_TIME_LOCKTIME and PSBT_IN_REQUIRED_HEIGHT_LOCKTIME fields.
If none of the inputs have a PSBT_IN_REQUIRED_TIME_LOCKTIME and=20
PSBT_IN_REQUIRED_HEIGHT_LOCKTIME, then PSBT_GLOBAL_PREFERRED_LOCKTIME=20
must be used.
If PSBT_GLOBAL_PREFERRED_LOCKTIME is not provided, then it is assumed to=20
be 0.

If one or more inuts have a PSBT_IN_REQUIRED_TIME_LOCKTIME or=20
PSBT_IN_REQUIRED_HEIGHT_LOCKTIME, then the field chosen is the one which=20
is supported by all of the inputs.
This can be determined by looking at all of the inputs which specify a=20
locktime in either of those fields, and choosing the field which is=20
present in all of those inputs.
Inputs not specifying a lock time field can take both types of lock=20
times, as can those that specify both.
The lock time chosen is then the maximum value of the chosen type of=20
lock time.

=3D=3D=3DUnique Identification=3D=3D=3D

PSBTv2s can be uniquely identified by constructing an unsigned=20
transaction given the information provided in the PSBT and computing the=20
transaction ID of that transaction.
Since PSBT_IN_SEQUENCE can be changed by Updaters and Combiners, the=20
sequence number in this unsigned transaction must be set to 0 (not=20
final, nor the sequence in PSBT_IN_SEQUENCE).
The lock time in this unsigned transaction must be computed as described=20
previously.

=3D=3DRoles=3D=3D

PSBTv2 introduces new roles and modifies some existing roles.

=3D=3D=3DCreator=3D=3D=3D

In PSBTv2, the Creator initializes the PSBT with 0 inputs and 0 outputs.
The PSBT version number is set to 2. The transaction version number must=20
be set to at least 2. <ref>'''Why does the transaction version number=20
need to be at least 2?''' The transaction version number is part of the=20
validation rules for some features such as OP_CHECKSEQUENCEVERIFY. Since=20
it is backwards compatible, and there are other ways to disable those=20
features (e.g. through sequence numbers), it is easier to require=20
transactions be able to support these features than to try to negotiate=20
the transaction version number.</ref>
The Creator should also PSBT_GLOBAL_PREFERRED_LOCKTIME.
If the Creator is not also a Constructor and will be giving the PSBT to=20
others to add inputs and outputs, the PSBT_GLOBAL_TX_MODIFIABLE field=20
must be present and and the Inputs Modifiable and Outputs Modifiable=20
flags set appropriately.
If the Creator is a Constructor and no inputs and outputs will be added=20
by other entities, PSBT_GLOBAL_TX_MODIFIABLE may be omitted.

=3D=3D=3DConstructor=3D=3D=3D

This Constructor is only present for PSBTv2.
Once a Creator initializes the PSBT, a constructor will add inputs and=20
outputs.
Before any input or output may be added, the constructor must check the=20
PSBT_GLOBAL_TX_MODIFIABLE field.
Inputs may only be added if the Inputs Modifiable flag (first boolean)=20
is True.
Outputs may only be added if the Outputs Modifiable flag (second=20
boolean) is True.
If PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS is present and its bitvector=20
indicates any inputs use SIGHASH_SINGLE, then the same number of inputs=20
and outputs must be added before that input and its corresponding outputs.

When an input or output is added, the corresponding=20
PSBT_GLOBAL_INPUT_COUNT or PSBT_GLOBAL_OUTPUT_COUNT must be incremeted=20
to reflect the number of inputs and outputs in the PSBT.
When an input is added, it must have PSBT_IN_PREVIOUS_TXID and=20
PSBT_IN_OUTPUT_INDEX set.
When an output is added, it must have PSBT_OUT_VALUE and=20
PSBT_OUT_OUTPUT_SCRIPT set.
If the input has a required timelock, Constructors must set the=20
requisite timelock field.
If the input has a required time based timelock, then=20
PSBT_IN_REQUIRED_TIME_TIMELOCK.
If the input has a required height based timelock, then=20
PSBT_IN_REQUIRED_HEIGHT_TIMELOCK.
If an input has both types of timelocks, then both may be set.
In some cases, an input that can allow both types, but a particular=20
branch supporting only one type of timelock will be taken, then the type=20
of timelock that will be used can be the only one set.

When adding a new input, the new input must be compatible with the=20
timelock types of all existing inputs.
Since Bitcoin requires that a transaction uses only one type of=20
timelock, all of the inputs must be able to support the same type of=20
timelock.
If the type of timelock is incompatible with the timelock type of the=20
other inputs, then the input must not be added.

Since a Constructor may be adding inputs to a PSBT that has inputs with=20
existing signatures, the Constructor must be careful to not invalidate=20
any existing signatures.
The PSBT_GLOBAL_TX_MODIFIABLE and PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS=20
fields caches this information so that constructors do not need to=20
inspect every input.
If the PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS bit vector indicates an input=20
index uses SIGHASH_SINGLE, the same number of inputs and outputs must be=20
added before that input and its corresponding output.
When an input is added, the bit vector, if present, must be expanded to=20
include a bit for this input in the correct position.
When there are signatures, in addition to respecting the lock time rules=20
described previously, the newly added inputs must not change the lock=20
time used by the transaction.
It cannot cause the lock time to change as that will invalidate all=20
signatures since they all include the lock time regardless of the=20
sighash type.

A Constructor may choose to declare that no further inputs and outputs=20
can be added to the transaction by setting the booleans in=20
PSBT_GLOBAL_TX_MODIFIABLE to False or by removing this field entirely.

A single entity is likely to be both a Creator and Constructor.

=3D=3D=3DUpdater=3D=3D=3D

For PSBTv2, an Updater can set the sequence number.

=3D=3D=3DSigner=3D=3D=3D

For PSBTv2s, a signer must update the PSBT_GLOBAL_TX_MODIFIABLE and=20
PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS fields after signing inputs so
that these fields accurately reflects the state of the PSBT.
If the Signer added a signature that does not use SIGHASH_ANYONECANPAY,=20
the Input Modifiable flag must be set to False.
If the Signer added a signature that does not use SIGHASH_NONE, the=20
Outputs Modifiable flag must be set to False.
If the Signer added a signature that uses SIGHASH_SINGLE, a=20
PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS field must be added if not present,=20
and the corresponding bit in its bit vector must be set to 1.

=3D=3D=3DTransaction Extractor=3D=3D=3D

For PSBTv2s, the transaction is constructed using the PSBTv2 fields.
The lock time for this transaction is determined as described in the=20
Determining Lock Time section.
The Extractor should produce a fully valid, network serialized=20
transaction if all inputs are complete.

=3D=3DCompatibility=3D=3D

PSBTv2 shares the same gemeric format as PSBTv0 as defined in BIP 174.=20
Parsers for PSBTv0 should
be able to deserialize PSBTv2 with only changes to support the new fields.

However PSBTv2 is incompatible with PSBTv0, and vice versa due to the=20
use of the PSBT_GLOBAL_VERSION.
This incompatibility is intentional so that PSBT_GLOBAL_UNSIGNED_TX=20
could be removed in PSBTv2.
However it is possible to convert a PSBTv2 to a PSBTv0 by creating an=20
unsigned
transaction from the PSBTv2 fields.

=3D=3DTest Vectors=3D=3D

TBD

=3D=3DRationale=3D=3D

<references/>

=3D=3DReference implementation=3D=3D

The reference implementation of the PSBT format is available at=20
https://github.com/achow101/bitcoin/tree/psbt2.


On 12/23/20 4:32 PM, Andrew Chow wrote:
> Hi All,
>
> The full modified BIP can be read at
> https://github.com/achow101/bips/blob/psbt2/bip-0174.mediawiki.
>
> I will open a PR to the BIPs repo soon after further discussion on this.
>
>
> Andrew
>
> On 12/22/20 3:12 PM, Andrew Chow wrote:
>> Hi All,
>>
>> I have some updates on this after speaking with some people off-list.
>>
>> Firstly, the version number will be set to 2. In most discussions, this
>> proposal was being referred to as PSBT version 2, so it'll be easier and
>> clearer to set the version number to 2.
>>
>> For lock times, instead of a single=C2=A0 PSBT_IN_REQUIRED_LOCKTIME fiel=
d,
>> there will be 2 of them, one for a time based lock time, and the other
>> for height based. These will be:
>> * PSBT_IN_REQUIRED_TIME_LOCKTIME =3D 0x10
>>    =C2=A0 * Key: empty
>>    =C2=A0 * Value: 32 bit unsigned little endian integer greater than or=
 equal
>> to 500000000 representing the minimum Unix timestamp that this input
>> requires to be set as the transaction's lock time. Must be omitted in
>> PSBTv0, and may be omitted in PSBTv2
>> * PSBT_IN_REQUIRED_HEIGHT_LOCKTIME =3D 0x11
>>    =C2=A0 * Key: empty
>>    =C2=A0 * Value: 32 bit unsigned little endian integer less than 50000=
0000
>> representing the minimum block height that this input requires to be set
>> as the transaction's lock time. Must be omitted in PSBTv0, and may be
>> omitted in PSBTv2.
>>
>> Having two lock time fields is necessary due to the behavior where all
>> inputs must use the same type of lock time (height or time). Thus if an
>> input requires a particular type of lock time, it must set the requisite
>> field. Any new inputs being added must be able to accommodate all
>> existing inputs' lock time type. This means they either must not have a
>> lock time specified (i.e. no OP_CLTV involved), or have branches that
>> allow the acceptance of either type. If an input has a lock time type
>> that is incompatible with the rest of the transaction, it must not be ad=
ded.
>>
>> PSBT_GLOBAL_PREFERRED_LOCKTIME is changed to purely be the fallback
>> option if no input lock time fields are present. If there are input lock
>> times, all lock time calculations must ignore it.
>>
>> Any role which does lock time calculation will first check if there are
>> input lock time fields. If there are not, it must then check for a
>> PSBT_GLOBAL_PREFERRED_LOCKTIME. If this field exists, its value is the
>> transaction's lock time. If it does not, the lock time is 0. If there
>> are input lock time fields, it must choose the type which does not
>> invalidate any inputs. The lock time is then determined to be the
>> maximum value of all of the lock time fields for the chosen type.
>>
>>
>> Additionally, I would like to add a new global field:
>> * PSBT_GLOBAL_UNDER_CONSTRUCTION =3D 0x05
>>    =C2=A0 * Key: empty
>>    =C2=A0 * Value: A single byte as a boolean. 0 for False, 1 for True. =
All
>> other values ore prohibited. Must be omitted for PSBTv0, may be omitted
>> in PSBTv2.
>>
>> PSBT_GLOBAL_UNDER_CONSTRUCTION is used to signal whether inputs and
>> outputs can be added to the PSBT. This flag may be set to True when
>> inputs and outputs are being updated, signed, and finalized. However
>> care must be taken when there are existing signatures. If this field is
>> omitted or set to False, no further inputs and outputs may be added to
>> the PSBT.
>>
>> Several rules must be followed to ensure that adding additional inputs
>> and outputs will not invalidate existing signatures. First, an input or
>> output adder must check for any existing signatures in all of the other
>> inputs. If there are none, the input or output may be added in any
>> position. If there are one or more signatures, each signature's sighash
>> type must be examined. Inputs may only be added if all existing
>> signatures use SIGHASH_ANYONECANPAY. Outputs may only be added if all
>> existing signatures use SIGHASH_NONE. If an input has a signature using
>> SIGHASH_SINGLE, the same number of inputs and outputs must be added
>> before that input and it's corresponding output. For all other sighash
>> types (i.e. SIGHASH_ALL and any future sighash types), no inputs or
>> outputs may be added to the PSBT. Specific exceptions can be made in the
>> future for additional sighash types.
>>
>> Furthermore, these newly added inputs must follow additional lock time
>> rules. Because all signatures, regardless of sighash type, sign the
>> transaction lock time, newly added inputs when there are existing
>> signatures must have the same type of lock time used in the transaction,
>> and must be less than or equal to the transaction lock time. It must not
>> cause the transaction lock time to change, otherwise the signatures will
>> be invalidated.
>>
>>
>> Lastly, to uniquely identify transactions for combiners, a txid can be
>> computed from the information present in the PSBT. Internally, combiners
>> can create an unsigned transaction given the transaction version, the
>> input prevouts, the outputs, and the computed locktime. This can then be
>> used to calculate a txid and thus used as a way to identify PSBTs.
>> Combiners will need to do this for all version 2 PSBTs in order to avoid
>> combining distinct transactions.
>>
>>
>> Andrew Chow
>>
>> On 12/9/20 5:25 PM, Andrew Chow wrote:
>>> Hi All,
>>>
>>> I would like to propose a new PSBT version that addresses a few
>>> deficiencies in the current PSBT v0. As this will be backwards
>>> incompatible, a new PSBT version will be used, v1.
>>>
>>> The primary change is to truly have all input and output data for each
>>> in their respective maps. Instead of having to parse an unsigned
>>> transaction and lookup some data from there, and other data from the
>>> correct map, all of the data for an input will be contained in its map.
>>> Doing so also disallows PSBT_GLOBAL_UNSIGNED_TX in this new version.
>>> Thus I propose that the following fields be added:
>>>
>>> Global:
>>> * PSBT_GLOBAL_TX_VERSION =3D 0x02
>>>     =C2=A0 * Key: empty
>>>     =C2=A0 * Value: 32-bit little endian unsigned integer for the trans=
action
>>> version number. Must be provided in PSBT v1 and omitted in v0.
>>> * PSBT_GLOBAL_PREFERRED_LOCKTIME =3D 0x03
>>>     =C2=A0 * Key: empty
>>>     =C2=A0 * Value: 32 bit little endian unsigned integer for the prefe=
rred
>>> transaction lock time. Must be omitted in PSBT v0. May be provided in
>>> PSBT v1, assumed to be 0 if not provided.
>>> * PSBT_GLOBAL_INPUT_COUNT =3D 0x04
>>>     =C2=A0 * Key: empty
>>>     =C2=A0 * Value: Compact size unsigned integer. Number of inputs in =
this
>>> PSBT. Must be provided in PSBT v1 and omitted in v0.
>>> * PSBT_GLOBAL_OUTPUT_COUNT =3D 0x05
>>>     =C2=A0 * Key: empty
>>>     =C2=A0 * Value: Compact size unsigned integer. Number of outputs in=
 this
>>> PSBT. Must be provided in PSBT v1 and omitted in v0.
>>>
>>> Input:
>>> * PSBT_IN_PREVIOUS_TXID =3D 0x0e
>>>     =C2=A0 * Key: empty
>>>     =C2=A0 * Value: 32 byte txid of the previous transaction whose outp=
ut at
>>> PSBT_IN_OUTPUT_INDEX is being spent. Must be provided in PSBT v1 and
>>> omitted in v0.
>>> * PSBT_IN_OUTPUT_INDEX =3D 0x0f
>>>     =C2=A0 * Key: empty
>>>     =C2=A0 * Value: 32 bit little endian integer for the index of the o=
utput
>>> being spent. Must be provided in PSBT v1 and omitted in v0.
>>> * PSBT_IN_SEQUENCE =3D 0x0f
>>>     =C2=A0 * Key: empty
>>>     =C2=A0 * Value: 32 bit unsigned little endian integer for the seque=
nce
>>> number. Must be omitted in PSBT v0. May be provided in PSBT v1 assumed
>>> to be max sequence (0xffffffff) if not provided.
>>> * PSBT_IN_REQUIRED_LOCKTIME =3D 0x10
>>>     =C2=A0 * Key: empty
>>>     =C2=A0 * Value: 32 bit unsigned little endian integer for the lock =
time that
>>> this input requires. Must be omitted in PSBT v0. May be provided in PSB=
T
>>> v1, assumed to be 0 if not provided.
>>>
>>> Output:
>>> * PSBT_OUT_VALUE =3D 0x03
>>>     =C2=A0 * Key: empty
>>>     =C2=A0 * Value: 64-bit unsigned little endian integer for the outpu=
t's
>>> amount in satoshis. Must be provided in PSBT v1 and omitted in v0.
>>> * PSBT_OUT_OUTPUT_SCRIPT =3D 0x04
>>>     =C2=A0 * Key: empty
>>>     =C2=A0 * Value: The script for this output. Otherwise known as the
>>> scriptPubKey. Must be provided in PSBT v1 and omitted in v0.
>>>
>>> This change allows for PSBT to be used in the construction of
>>> transactions. With these new fields, inputs and outputs can be added as
>>> needed. One caveat is that there is no longer a unique transaction
>>> identifier so more care must be taken when combining PSBTs.
>>> Additionally, adding new inputs and outputs must be done such that
>>> signatures are not invalidated. This may be harder to specify.
>>>
>>> An important thing to note in this proposal are the fields
>>> PSBT_GLOBAL_PREFERRED_LOCKTIME and PSBT_IN_REQUIRED_LOCKTIME. A Bitcoin
>>> transaction only has a single locktime yet a PSBT may have multiple
>>> locktimes. To choose the locktime for the transaction, finalizers must
>>> choose the maximum of all of the *_LOCKTIME fields.
>>> PSBT_IN_REQUIRED_LOCKTIME is added because some inputs, such as those
>>> involving OP_CHECKLOCKTIMEVERIFY, require a specific minimum locktime t=
o
>>> be set. This field allows finalizers to choose a locktime that is high
>>> enough for all inputs without needing to understand the scripts
>>> involved. The PSBT_GLOBAL_PREFERRED_LOCKTIME is the locktime to use if
>>> no inputs require a particular locktime.
>>>
>>> As these changes disallow the PSBT_GLOBAL_UNSIGNED_TX field, PSBT v1
>>> needs the version number bump to enforce backwards incompatibility.
>>> However once the inputs and outputs of a PSBT are decided, a PSBT could
>>> be "downgraded" back to v0 by creating the unsigned transaction from th=
e
>>> above fields, and then dropping these new fields.
>>>
>>> If the list finds that these changes are reasonable, I will write a PR
>>> to modify BIP 174 to incorporate them.
>>>
>>> Thanks,
>>> Andrew Chow