path: root/c4/1f96c8b69dea51781a529e55a3dc8755d43e25

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