Date: Thu, 21 Jan 2021 19:50:45 +0000
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: <16f16c05-c3b3-57c2-5070-9e70c1823b40@achow101.com>
In-Reply-To: <e87f1e08-4bf2-8bf5-d408-3c0b603b8a7f@achow101.com>
References: <1dd8c285-e3f4-4f03-d608-103a5026146d@achow101.com>
 <5a4697cb-b9cb-b925-e78f-d5b53f025704@achow101.com>
 <40089cb5-8d68-1868-c87b-241f2bd747fb@achow101.com>
 <e87f1e08-4bf2-8bf5-d408-3c0b603b8a7f@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
Precedence: list

While working on the reference implementation for this, it occurred to=20
me that the Inputs Modifiable flag needs to be more than just a boolean.

If there are existing signatures in the PSBT, then any added inputs=20
cannot change the transaction's locktime as all signatures, regardless=20
of sighash type, commit to the locktime. Additionally if an input with a=20
signature is being added, it also needs to set the locktime for the=20
transaction.

It also seems like the SIGHASH_SINGLE bitmap is unnecessary. Signers can=20
instead iterate all inputs, check for existing signatures, and extract=20
the sighash byte from those signatures to determine whether any are=20
SIGHASH_SINGLE. This bitmap doesn't seem to provide much benefit and=20
also causes headaches for implementation. So I've decided to remove it.

But it is still useful to know that there are SIGHASH_SINGLE inputs and=20
that iteration of the inputs vector will be necessary. It is also useful=20
to know that there are already some signatures in the transaction so the=20
locktime must be preserved. Thus I would like to change=20
PSBT_GLOBAL_TX_MODIFIABLE to include those. I propose making=20
PSBT_GLOBAL_TX_MODIFIABLE an 8 bit unsigned little endian integer that=20
is treated as a bit field. If bit 0 is set, inputs may be added. This=20
will be the Inputs Modifiable flag. If bit 1 is set, outputs may be=20
added. This will be the Outputs Modifiable flag. If bit 2 is set, the=20
transaction contains signatures and locktime must be preserved. This=20
will be the Has Signatures flag. If bit 3 is set, the transaction=20
contains SIGHASH_SINGLE inputs and their index pairings must be=20
preserved. This will be the Has SIGHASH_SINGLE flag.

Changing PSBT_GLOBAL_TX_MODIFIABLE to a bitfield like this allows us to=20
include more conditions that need to be considered when adding inputs=20
and outputs. I think these are all of the conditions for now, but with 8=20
bits, there is still some space for additional conditions in the future.=20
Perhaps it should be changed to be larger if we think there will be more=20
conditions, but I think that is unlikely.


Andrew

On 1/15/21 12:28 PM, Andrew Chow wrote:
> Hi All,
>
> I've made some reorganization changes to the way that new PSBT versions
> should be handled in BIP 174 (see
> https://github.com/bitcoin/bips/pull/1055) so PSBTv2 will be submitted
> as a separate BIP. The full document can be read at
> https://github.com/achow101/bips/blob/psbt2/bip-psbt2.mediawiki and I
> have also included it in this email.
>
> I've included Rusty's suggestion for PSBT_GLOBAL_UNDER_CONSTRUCTION and
> made a few modifications. First, the field will be named
> PSBT_GLOBAL_TX_MODIFIABLE and only include the inputs modifiable and
> outputs modifiable flags. The SIGHASH_SINGLE bitmap will be included as
> a separate field PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS. This allows most
> 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-=
PSBT2
>   =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
> Transaction format
> described in BIP 174 which allows for inputs and outputs to be added to
> 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
> is unable to have new
> inputs and outputs be added to the transaction. The fixed global
> unsigned transaction
> cannot be changed which prevents any additional inputs or outputs to be
> added.
> PSBT Version 2 is intended to rectify this problem.
>
> An additional benficial side effect is that all information for a given
> input or output will be
> provided by its <tt><input-map></tt> or <tt><output-map></tt>. With
> Version 0, to retrieve
> all of the information for an input or output, data would need to be
> found in two locations:
> the <tt><input-map></tt>/<tt><output-map></tt> and the global unsigned
> 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
> 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
> version number 2<ref>'''What happened to version number 1?'''
> Version number 1 is skipped because PSBT Version 0 has been colloquially
> referred to as version 1. Originally this BIP was to be
> version 1, but because it has been colloquially referred to as version 2
> 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
> number of the transaction being created. Note that this is not the same
> 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
> 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
> 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
> 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
> inputs can be modified, referred to as the Inputs Modifiable Flag. This
> is followed by a single byte boolean representing whether outputs can be
> 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
> the bit for an index is set to 1, then the input and output pair at that
> 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
> 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
> 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
> this input. If omitted, the sequence number is assumed to be the final
> 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
> 500000000 representing the minimum Unix timestamp that this input
> 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
> the minimum block height that this input requires to be set as the
> 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
> 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
> 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
> PSBT_GLOBAL_PREFERRED_LOCKTIME and each input's
> PSBT_IN_REQUIRED_TIME_LOCKTIME and PSBT_IN_REQUIRED_HEIGHT_LOCKTIME field=
s.
> If none of the inputs have a PSBT_IN_REQUIRED_TIME_LOCKTIME and
> PSBT_IN_REQUIRED_HEIGHT_LOCKTIME, then PSBT_GLOBAL_PREFERRED_LOCKTIME
> must be used.
> If PSBT_GLOBAL_PREFERRED_LOCKTIME is not provided, then it is assumed to
> be 0.
>
> If one or more inuts have a PSBT_IN_REQUIRED_TIME_LOCKTIME or
> PSBT_IN_REQUIRED_HEIGHT_LOCKTIME, then the field chosen is the one which
> is supported by all of the inputs.
> This can be determined by looking at all of the inputs which specify a
> locktime in either of those fields, and choosing the field which is
> present in all of those inputs.
> Inputs not specifying a lock time field can take both types of lock
> times, as can those that specify both.
> The lock time chosen is then the maximum value of the chosen type of
> lock time.
>
> =3D=3D=3DUnique Identification=3D=3D=3D
>
> PSBTv2s can be uniquely identified by constructing an unsigned
> transaction given the information provided in the PSBT and computing the
> transaction ID of that transaction.
> Since PSBT_IN_SEQUENCE can be changed by Updaters and Combiners, the
> sequence number in this unsigned transaction must be set to 0 (not
> final, nor the sequence in PSBT_IN_SEQUENCE).
> The lock time in this unsigned transaction must be computed as described
> 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
> be set to at least 2. <ref>'''Why does the transaction version number
> need to be at least 2?''' The transaction version number is part of the
> validation rules for some features such as OP_CHECKSEQUENCEVERIFY. Since
> it is backwards compatible, and there are other ways to disable those
> features (e.g. through sequence numbers), it is easier to require
> transactions be able to support these features than to try to negotiate
> 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
> others to add inputs and outputs, the PSBT_GLOBAL_TX_MODIFIABLE field
> must be present and and the Inputs Modifiable and Outputs Modifiable
> flags set appropriately.
> If the Creator is a Constructor and no inputs and outputs will be added
> 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
> outputs.
> Before any input or output may be added, the constructor must check the
> PSBT_GLOBAL_TX_MODIFIABLE field.
> Inputs may only be added if the Inputs Modifiable flag (first boolean)
> is True.
> Outputs may only be added if the Outputs Modifiable flag (second
> boolean) is True.
> If PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS is present and its bitvector
> indicates any inputs use SIGHASH_SINGLE, then the same number of inputs
> and outputs must be added before that input and its corresponding outputs=
.
>
> When an input or output is added, the corresponding
> PSBT_GLOBAL_INPUT_COUNT or PSBT_GLOBAL_OUTPUT_COUNT must be incremeted
> to reflect the number of inputs and outputs in the PSBT.
> When an input is added, it must have PSBT_IN_PREVIOUS_TXID and
> PSBT_IN_OUTPUT_INDEX set.
> When an output is added, it must have PSBT_OUT_VALUE and
> PSBT_OUT_OUTPUT_SCRIPT set.
> If the input has a required timelock, Constructors must set the
> requisite timelock field.
> If the input has a required time based timelock, then
> PSBT_IN_REQUIRED_TIME_TIMELOCK.
> If the input has a required height based timelock, then
> 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
> branch supporting only one type of timelock will be taken, then the type
> 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
> timelock types of all existing inputs.
> Since Bitcoin requires that a transaction uses only one type of
> timelock, all of the inputs must be able to support the same type of
> timelock.
> If the type of timelock is incompatible with the timelock type of the
> other inputs, then the input must not be added.
>
> Since a Constructor may be adding inputs to a PSBT that has inputs with
> existing signatures, the Constructor must be careful to not invalidate
> any existing signatures.
> The PSBT_GLOBAL_TX_MODIFIABLE and PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS
> fields caches this information so that constructors do not need to
> inspect every input.
> If the PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS bit vector indicates an input
> index uses SIGHASH_SINGLE, the same number of inputs and outputs must be
> added before that input and its corresponding output.
> When an input is added, the bit vector, if present, must be expanded to
> include a bit for this input in the correct position.
> When there are signatures, in addition to respecting the lock time rules
> described previously, the newly added inputs must not change the lock
> time used by the transaction.
> It cannot cause the lock time to change as that will invalidate all
> signatures since they all include the lock time regardless of the
> sighash type.
>
> A Constructor may choose to declare that no further inputs and outputs
> can be added to the transaction by setting the booleans in
> 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
> 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,
> the Input Modifiable flag must be set to False.
> If the Signer added a signature that does not use SIGHASH_NONE, the
> Outputs Modifiable flag must be set to False.
> If the Signer added a signature that uses SIGHASH_SINGLE, a
> PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS field must be added if not present,
> 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
> Determining Lock Time section.
> The Extractor should produce a fully valid, network serialized
> transaction if all inputs are complete.
>
> =3D=3DCompatibility=3D=3D
>
> PSBTv2 shares the same gemeric format as PSBTv0 as defined in BIP 174.
> 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
> use of the PSBT_GLOBAL_VERSION.
> This incompatibility is intentional so that PSBT_GLOBAL_UNSIGNED_TX
> could be removed in PSBTv2.
> However it is possible to convert a PSBTv2 to a PSBTv0 by creating an
> 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
> 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 an=
d
>>> clearer to set the version number to 2.
>>>
>>> For lock times, instead of a single=C2=A0 PSBT_IN_REQUIRED_LOCKTIME fie=
ld,
>>> 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 500=
000000
>>> representing the minimum block height that this input requires to be se=
t
>>> 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 requisit=
e
>>> 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 a=
dded.
>>>
>>> PSBT_GLOBAL_PREFERRED_LOCKTIME is changed to purely be the fallback
>>> option if no input lock time fields are present. If there are input loc=
k
>>> 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 th=
e
>>> 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 no=
t
>>> cause the transaction lock time to change, otherwise the signatures wil=
l
>>> be invalidated.
>>>
>>>
>>> Lastly, to uniquely identify transactions for combiners, a txid can be
>>> computed from the information present in the PSBT. Internally, combiner=
s
>>> can create an unsigned transaction given the transaction version, the
>>> input prevouts, the outputs, and the computed locktime. This can then b=
e
>>> 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 avoi=
d
>>> 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 tra=
nsaction
>>>> 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 pre=
ferred
>>>> 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 i=
n 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 ou=
tput 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=
 output
>>>> 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 seq=
uence
>>>> 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 loc=
k time that
>>>> this input requires. Must be omitted in PSBT v0. May be provided in PS=
BT
>>>> 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 out=
put'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 th=
e
>>>> 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 a=
s
>>>> 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 Bitcoi=
n
>>>> 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 =
to
>>>> 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 coul=
d
>>>> be "downgraded" back to v0 by creating the unsigned transaction from t=
he
>>>> 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