From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9404CC013A for ; Sat, 2 Jan 2021 06:34:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 6AF3A203D0 for ; Sat, 2 Jan 2021 06:34:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eW7QZzu6H9i for ; Sat, 2 Jan 2021 06:34:15 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by silver.osuosl.org (Postfix) with ESMTPS id 064032033E for ; Sat, 2 Jan 2021 06:34:14 +0000 (UTC) Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1026YCCF017123 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 2 Jan 2021 01:34:13 -0500 Received: by mail-il1-f169.google.com with SMTP id x15so20669144ilq.1 for ; Fri, 01 Jan 2021 22:34:13 -0800 (PST) X-Gm-Message-State: AOAM530VjhMYgKTo2r4EVfEkJBhFPR3DdwcCdomh7D86Tg8meysoR9sr ktcLW6Z+30S8482Dka+XujVfYHtJMGJxxwCZBbs= X-Google-Smtp-Source: ABdhPJyF/HesBl+VppKMb6lJWgoLVQUX2O7e91NLksBrgYywfyBeldqYC3m0ZZf0GAtMtaDqe6npvh8ioEqGwY4+l+o= X-Received: by 2002:a92:8404:: with SMTP id l4mr62156119ild.49.1609569252263; Fri, 01 Jan 2021 22:34:12 -0800 (PST) MIME-Version: 1.0 References: <1dd8c285-e3f4-4f03-d608-103a5026146d@achow101.com> <5a4697cb-b9cb-b925-e78f-d5b53f025704@achow101.com> <1768da5c6f0.f63a34dc413157.2741477427673569054@alhur.es> In-Reply-To: From: Jeremy Date: Fri, 1 Jan 2021 22:34:00 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Andrew Chow , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000085cbec05b7e50b0a" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 06:34:19 -0000 --00000000000085cbec05b7e50b0a Content-Type: text/plain; charset="UTF-8" One thing I think should be added in V2 is the ability to specify sighash flags per-key as opposed to per-input. The per-key restriction is unfitting given that there are circumstances where multisig signers may validate heterogenous logic. -- @JeremyRubin On Wed, Dec 23, 2020 at 1:37 PM Andrew Chow via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi, > > On 12/22/20 10:30 PM, fiatjaf wrote: > > Hi Andrew. > > > > I'm just a lurker here and I have not much experience with PSBTs, but > still let me pose this very obvious question and concern: isn't this change > going to create a compatibility nightmare, with some software supporting > version 1, others supporting version 2, and the ones that care enough about > UX and are still maintained being forced to support both versions -- and > for no very important reason except some improvements in the way data is > structured? > No, it is not just "improvements in the way data is structured." > > The primary reason for these changes is to allow PSBT to properly > support adding inputs and outputs. This is a feature that many people > have requested, and the ways that people have been doing it are honestly > just hacks and not really the right way to be doing that. These changes > allow for that feature to be supported well. > > Furthermore, it is possible to downgrade and upgrade PSBTs between the > two versions, once all inputs and outputs have been decided. Since > PSBTv2 is essentially just taking all of the normal transaction fields > and grouping them all with the rest of the data for those inputs and > outputs, it is easy to reconstruct a global unsigned transaction and > turn a PSBTv2 into a PSBTv0. It is likewise just as easy to go the other > way and break apart the global unsigned tx to turn a PSBTv0 into a > PSBTv2. Originally, I had considered requiring that once a transaction > was fully constructed it must be downgraded to a PSBTv0, but the > structure changes that were made do make it easier to work with PSBT so > I decided not to add this requirement. > > Perhaps to maintain compatibility PSBT_GLOBAL_UNSIGNED_TX shouldn't be > disallowed in PSBTv2 once the transaction is constructed? It would make > things much more confusing though as it would no longer be a clean break. > > > Andrew Chow > > > Ultimately I don't think it should matter if some data is structured in > not-the-best-possible way, as long as it is clear enough for the computer > and for the libraries already written to deal with it. > Backwards-compatibility and general interoperability is worth much more > than anything else in these cases. > > > > Also let me leave this article here, which I find very important (even > if for some reason it ends up not being relevant to this specific case): > http://scripting.com/2017/05/09/rulesForStandardsmakers.html > > > > ---- On Tue, 22 Dec 2020 17:12:22 -0300 Andrew Chow via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> 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 PSBT_IN_REQUIRED_LOCKTIME field, > > > 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 = 0x10 > > > * Key: empty > > > * 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 = 0x11 > > > * Key: empty > > > * Value: 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. 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 added. > > > > > > 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 = 0x05 > > > * Key: empty > > > * 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 = 0x02 > > > > * Key: empty > > > > * Value: 32-bit little endian unsigned integer for the > transaction > > > > version number. Must be provided in PSBT v1 and omitted in v0. > > > > * PSBT_GLOBAL_PREFERRED_LOCKTIME = 0x03 > > > > * Key: empty > > > > * Value: 32 bit little endian unsigned integer for the > preferred > > > > 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 = 0x04 > > > > * Key: empty > > > > * 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 = 0x05 > > > > * Key: empty > > > > * 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 = 0x0e > > > > * Key: empty > > > > * Value: 32 byte txid of the previous transaction whose output > at > > > > PSBT_IN_OUTPUT_INDEX is being spent. Must be provided in PSBT v1 > and > > > > omitted in v0. > > > > * PSBT_IN_OUTPUT_INDEX = 0x0f > > > > * Key: empty > > > > * 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 = 0x0f > > > > * Key: empty > > > > * Value: 32 bit unsigned little endian integer for the sequence > > > > 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 = 0x10 > > > > * Key: empty > > > > * 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 PSBT > > > > v1, assumed to be 0 if not provided. > > > > > > > > Output: > > > > * PSBT_OUT_VALUE = 0x03 > > > > * Key: empty > > > > * Value: 64-bit unsigned little endian integer for the output's > > > > amount in satoshis. Must be provided in PSBT v1 and omitted in v0. > > > > * PSBT_OUT_OUTPUT_SCRIPT = 0x04 > > > > * Key: empty > > > > * 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 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 > could > > > > be "downgraded" back to v0 by creating the unsigned transaction > from the > > > > 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 > > > > > > > > > _______________________________________________ > > > bitcoin-dev mailing list > > > bitcoin-dev@lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000085cbec05b7e50b0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One thing I think should = be added in V2 is the ability to specify sighash flags per-key as opposed t= o per-input.

The per-key restriction is unfitting given that there ar= e circumstances where multisig signers may validate heterogenous logic.

On Wed, = Dec 23, 2020 at 1:37 PM Andrew Chow via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org= > wrote:
= Hi,

On 12/22/20 10:30 PM, fiatjaf wrote:
> Hi Andrew.
>
> I'm just a lurker here and I have not much experience with PSBTs, = but still let me pose this very obvious question and concern: isn't thi= s change going to create a compatibility nightmare, with some software supp= orting version 1, others supporting version 2, and the ones that care enoug= h about UX and are still maintained being forced to support both versions -= - and for no very important reason except some improvements in the way data= is structured?
No, it is not just "improvements in the way data is structured."<= br>
The primary reason for these changes is to allow PSBT to properly
support adding inputs and outputs. This is a feature that many people
have requested, and the ways that people have been doing it are honestly just hacks and not really the right way to be doing that. These changes allow for that feature to be supported well.

Furthermore, it is possible to downgrade and upgrade PSBTs between the
two versions, once all inputs and outputs have been decided. Since
PSBTv2 is essentially just taking all of the normal transaction fields
and grouping them all with the rest of the data for those inputs and
outputs, it is easy to reconstruct a global unsigned transaction and
turn a PSBTv2 into a PSBTv0. It is likewise just as easy to go the other way and break apart the global unsigned tx to turn a PSBTv0 into a
PSBTv2. Originally, I had considered requiring that once a transaction
was fully constructed it must be downgraded to a PSBTv0, but the
structure changes that were made do make it easier to work with PSBT so I decided not to add this requirement.

Perhaps to maintain compatibility PSBT_GLOBAL_UNSIGNED_TX shouldn't be =
disallowed in PSBTv2 once the transaction is constructed? It would make things much more confusing though as it would no longer be a clean break.

Andrew Chow

> Ultimately I don't think it should matter if some data is structur= ed in not-the-best-possible way, as long as it is clear enough for the comp= uter and for the libraries already written to deal with it. Backwards-compa= tibility and general interoperability is worth much more than anything else= in these cases.
>
> Also let me leave this article here, which I find very important (even= if for some reason it ends up not being relevant to this specific case): <= a href=3D"http://scripting.com/2017/05/09/rulesForStandardsmakers.html" rel= =3D"noreferrer" target=3D"_blank">http://scripting.com/2017/05/09/rulesForS= tandardsmakers.html
>
>=C2=A0 =C2=A0---- On Tue, 22 Dec 2020 17:12:22 -0300 Andrew Chow via bi= tcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote ----
>=C2=A0 =C2=A0> Hi All,
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0> I have some updates on this after speaking with some = people off-list.
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0> Firstly, the version number will be set to 2. In most= discussions, this
>=C2=A0 =C2=A0> proposal was being referred to as PSBT version 2, so = it'll be easier and
>=C2=A0 =C2=A0> clearer to set the version number to 2.
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0> For lock times, instead of a single=C2=A0 PSBT_IN_REQ= UIRED_LOCKTIME field,
>=C2=A0 =C2=A0> there will be 2 of them, one for a time based lock ti= me, and the other
>=C2=A0 =C2=A0> for height based. These will be:
>=C2=A0 =C2=A0> * PSBT_IN_REQUIRED_TIME_LOCKTIME =3D 0x10
>=C2=A0 =C2=A0>=C2=A0 =C2=A0 * Key: empty
>=C2=A0 =C2=A0>=C2=A0 =C2=A0 * Value: 32 bit unsigned little endian i= nteger greater than or equal
>=C2=A0 =C2=A0> to 500000000 representing the minimum Unix timestamp = that this input
>=C2=A0 =C2=A0> requires to be set as the transaction's lock time= . Must be omitted in
>=C2=A0 =C2=A0> PSBTv0, and may be omitted in PSBTv2
>=C2=A0 =C2=A0> * PSBT_IN_REQUIRED_HEIGHT_LOCKTIME =3D 0x11
>=C2=A0 =C2=A0>=C2=A0 =C2=A0 * Key: empty
>=C2=A0 =C2=A0>=C2=A0 =C2=A0 * Value: 32 bit unsigned little endian i= nteger less than 500000000
>=C2=A0 =C2=A0> representing the minimum block height that this input= requires to be set
>=C2=A0 =C2=A0> as the transaction's lock time. Must be omitted i= n PSBTv0, and may be
>=C2=A0 =C2=A0> omitted in PSBTv2.
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0> Having two lock time fields is necessary due to the b= ehavior where all
>=C2=A0 =C2=A0> inputs must use the same type of lock time (height or= time). Thus if an
>=C2=A0 =C2=A0> input requires a particular type of lock time, it mus= t set the requisite
>=C2=A0 =C2=A0> field. Any new inputs being added must be able to acc= ommodate all
>=C2=A0 =C2=A0> existing inputs' lock time type. This means they = either must not have a
>=C2=A0 =C2=A0> lock time specified (i.e. no OP_CLTV involved), or ha= ve branches that
>=C2=A0 =C2=A0> allow the acceptance of either type. If an input has = a lock time type
>=C2=A0 =C2=A0> that is incompatible with the rest of the transaction= , it must not be added.
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0> PSBT_GLOBAL_PREFERRED_LOCKTIME is changed to purely b= e the fallback
>=C2=A0 =C2=A0> option if no input lock time fields are present. If t= here are input lock
>=C2=A0 =C2=A0> times, all lock time calculations must ignore it.
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0> Any role which does lock time calculation will first = check if there are
>=C2=A0 =C2=A0> input lock time fields. If there are not, it must the= n check for a
>=C2=A0 =C2=A0> PSBT_GLOBAL_PREFERRED_LOCKTIME. If this field exists,= its value is the
>=C2=A0 =C2=A0> transaction's lock time. If it does not, the lock= time is 0. If there
>=C2=A0 =C2=A0> are input lock time fields, it must choose the type w= hich does not
>=C2=A0 =C2=A0> invalidate any inputs. The lock time is then determin= ed to be the
>=C2=A0 =C2=A0> maximum value of all of the lock time fields for the = chosen type.
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0> Additionally, I would like to add a new global field:=
>=C2=A0 =C2=A0> * PSBT_GLOBAL_UNDER_CONSTRUCTION =3D 0x05
>=C2=A0 =C2=A0>=C2=A0 =C2=A0 * Key: empty
>=C2=A0 =C2=A0>=C2=A0 =C2=A0 * Value: A single byte as a boolean. 0 f= or False, 1 for True. All
>=C2=A0 =C2=A0> other values ore prohibited. Must be omitted for PSBT= v0, may be omitted
>=C2=A0 =C2=A0> in PSBTv2.
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0> PSBT_GLOBAL_UNDER_CONSTRUCTION is used to signal whet= her inputs and
>=C2=A0 =C2=A0> outputs can be added to the PSBT. This flag may be se= t to True when
>=C2=A0 =C2=A0> inputs and outputs are being updated, signed, and fin= alized. However
>=C2=A0 =C2=A0> care must be taken when there are existing signatures= . If this field is
>=C2=A0 =C2=A0> omitted or set to False, no further inputs and output= s may be added to
>=C2=A0 =C2=A0> the PSBT.
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0> Several rules must be followed to ensure that adding = additional inputs
>=C2=A0 =C2=A0> and outputs will not invalidate existing signatures. = First, an input or
>=C2=A0 =C2=A0> output adder must check for any existing signatures i= n all of the other
>=C2=A0 =C2=A0> inputs. If there are none, the input or output may be= added in any
>=C2=A0 =C2=A0> position. If there are one or more signatures, each s= ignature's sighash
>=C2=A0 =C2=A0> type must be examined. Inputs may only be added if al= l existing
>=C2=A0 =C2=A0> signatures use SIGHASH_ANYONECANPAY. Outputs may only= be added if all
>=C2=A0 =C2=A0> existing signatures use SIGHASH_NONE. If an input has= a signature using
>=C2=A0 =C2=A0> SIGHASH_SINGLE, the same number of inputs and outputs= must be added
>=C2=A0 =C2=A0> before that input and it's corresponding output. = For all other sighash
>=C2=A0 =C2=A0> types (i.e. SIGHASH_ALL and any future sighash types)= , no inputs or
>=C2=A0 =C2=A0> outputs may be added to the PSBT. Specific exceptions= can be made in the
>=C2=A0 =C2=A0> future for additional sighash types.
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0> Furthermore, these newly added inputs must follow add= itional lock time
>=C2=A0 =C2=A0> rules. Because all signatures, regardless of sighash = type, sign the
>=C2=A0 =C2=A0> transaction lock time, newly added inputs when there = are existing
>=C2=A0 =C2=A0> signatures must have the same type of lock time used = in the transaction,
>=C2=A0 =C2=A0> and must be less than or equal to the transaction loc= k time. It must not
>=C2=A0 =C2=A0> cause the transaction lock time to change, otherwise = the signatures will
>=C2=A0 =C2=A0> be invalidated.
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0> Lastly, to uniquely identify transactions for combine= rs, a txid can be
>=C2=A0 =C2=A0> computed from the information present in the PSBT. In= ternally, combiners
>=C2=A0 =C2=A0> can create an unsigned transaction given the transact= ion version, the
>=C2=A0 =C2=A0> input prevouts, the outputs, and the computed locktim= e. This can then be
>=C2=A0 =C2=A0> used to calculate a txid and thus used as a way to id= entify PSBTs.
>=C2=A0 =C2=A0> Combiners will need to do this for all version 2 PSBT= s in order to avoid
>=C2=A0 =C2=A0> combining distinct transactions.
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0> Andrew Chow
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0> On 12/9/20 5:25 PM, Andrew Chow wrote:
>=C2=A0 =C2=A0> > Hi All,
>=C2=A0 =C2=A0> >
>=C2=A0 =C2=A0> > I would like to propose a new PSBT version that = addresses a few
>=C2=A0 =C2=A0> > deficiencies in the current PSBT v0. As this wil= l be backwards
>=C2=A0 =C2=A0> > incompatible, a new PSBT version will be used, v= 1.
>=C2=A0 =C2=A0> >
>=C2=A0 =C2=A0> > The primary change is to truly have all input an= d output data for each
>=C2=A0 =C2=A0> > in their respective maps. Instead of having to p= arse an unsigned
>=C2=A0 =C2=A0> > transaction and lookup some data from there, and= other data from the
>=C2=A0 =C2=A0> > correct map, all of the data for an input will b= e contained in its map.
>=C2=A0 =C2=A0> > Doing so also disallows PSBT_GLOBAL_UNSIGNED_TX = in this new version.
>=C2=A0 =C2=A0> > Thus I propose that the following fields be adde= d:
>=C2=A0 =C2=A0> >
>=C2=A0 =C2=A0> > Global:
>=C2=A0 =C2=A0> > * PSBT_GLOBAL_TX_VERSION =3D 0x02
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: 32-bit little endian= unsigned integer for the transaction
>=C2=A0 =C2=A0> > version number. Must be provided in PSBT v1 and = omitted in v0.
>=C2=A0 =C2=A0> > * PSBT_GLOBAL_PREFERRED_LOCKTIME =3D 0x03
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: 32 bit little endian= unsigned integer for the preferred
>=C2=A0 =C2=A0> > transaction lock time. Must be omitted in PSBT v= 0. May be provided in
>=C2=A0 =C2=A0> > PSBT v1, assumed to be 0 if not provided.
>=C2=A0 =C2=A0> > * PSBT_GLOBAL_INPUT_COUNT =3D 0x04
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: Compact size unsigne= d integer. Number of inputs in this
>=C2=A0 =C2=A0> > PSBT. Must be provided in PSBT v1 and omitted in= v0.
>=C2=A0 =C2=A0> > * PSBT_GLOBAL_OUTPUT_COUNT =3D 0x05
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: Compact size unsigne= d integer. Number of outputs in this
>=C2=A0 =C2=A0> > PSBT. Must be provided in PSBT v1 and omitted in= v0.
>=C2=A0 =C2=A0> >
>=C2=A0 =C2=A0> > Input:
>=C2=A0 =C2=A0> > * PSBT_IN_PREVIOUS_TXID =3D 0x0e
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: 32 byte txid of the = previous transaction whose output at
>=C2=A0 =C2=A0> > PSBT_IN_OUTPUT_INDEX is being spent. Must be pro= vided in PSBT v1 and
>=C2=A0 =C2=A0> > omitted in v0.
>=C2=A0 =C2=A0> > * PSBT_IN_OUTPUT_INDEX =3D 0x0f
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: 32 bit little endian= integer for the index of the output
>=C2=A0 =C2=A0> > being spent. Must be provided in PSBT v1 and omi= tted in v0.
>=C2=A0 =C2=A0> > * PSBT_IN_SEQUENCE =3D 0x0f
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: 32 bit unsigned litt= le endian integer for the sequence
>=C2=A0 =C2=A0> > number. Must be omitted in PSBT v0. May be provi= ded in PSBT v1 assumed
>=C2=A0 =C2=A0> > to be max sequence (0xffffffff) if not provided.=
>=C2=A0 =C2=A0> > * PSBT_IN_REQUIRED_LOCKTIME =3D 0x10
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: 32 bit unsigned litt= le endian integer for the lock time that
>=C2=A0 =C2=A0> > this input requires. Must be omitted in PSBT v0.= May be provided in PSBT
>=C2=A0 =C2=A0> > v1, assumed to be 0 if not provided.
>=C2=A0 =C2=A0> >
>=C2=A0 =C2=A0> > Output:
>=C2=A0 =C2=A0> > * PSBT_OUT_VALUE =3D 0x03
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: 64-bit unsigned litt= le endian integer for the output's
>=C2=A0 =C2=A0> > amount in satoshis. Must be provided in PSBT v1 = and omitted in v0.
>=C2=A0 =C2=A0> > * PSBT_OUT_OUTPUT_SCRIPT =3D 0x04
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty
>=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: The script for this = output. Otherwise known as the
>=C2=A0 =C2=A0> > scriptPubKey. Must be provided in PSBT v1 and om= itted in v0.
>=C2=A0 =C2=A0> >
>=C2=A0 =C2=A0> > This change allows for PSBT to be used in the co= nstruction of
>=C2=A0 =C2=A0> > transactions. With these new fields, inputs and = outputs can be added as
>=C2=A0 =C2=A0> > needed. One caveat is that there is no longer a = unique transaction
>=C2=A0 =C2=A0> > identifier so more care must be taken when combi= ning PSBTs.
>=C2=A0 =C2=A0> > Additionally, adding new inputs and outputs must= be done such that
>=C2=A0 =C2=A0> > signatures are not invalidated. This may be hard= er to specify.
>=C2=A0 =C2=A0> >
>=C2=A0 =C2=A0> > An important thing to note in this proposal are = the fields
>=C2=A0 =C2=A0> > PSBT_GLOBAL_PREFERRED_LOCKTIME and PSBT_IN_REQUI= RED_LOCKTIME. A Bitcoin
>=C2=A0 =C2=A0> > transaction only has a single locktime yet a PSB= T may have multiple
>=C2=A0 =C2=A0> > locktimes. To choose the locktime for the transa= ction, finalizers must
>=C2=A0 =C2=A0> > choose the maximum of all of the *_LOCKTIME fiel= ds.
>=C2=A0 =C2=A0> > PSBT_IN_REQUIRED_LOCKTIME is added because some = inputs, such as those
>=C2=A0 =C2=A0> > involving OP_CHECKLOCKTIMEVERIFY, require a spec= ific minimum locktime to
>=C2=A0 =C2=A0> > be set. This field allows finalizers to choose a= locktime that is high
>=C2=A0 =C2=A0> > enough for all inputs without needing to underst= and the scripts
>=C2=A0 =C2=A0> > involved. The PSBT_GLOBAL_PREFERRED_LOCKTIME is = the locktime to use if
>=C2=A0 =C2=A0> > no inputs require a particular locktime.
>=C2=A0 =C2=A0> >
>=C2=A0 =C2=A0> > As these changes disallow the PSBT_GLOBAL_UNSIGN= ED_TX field, PSBT v1
>=C2=A0 =C2=A0> > needs the version number bump to enforce backwar= ds incompatibility.
>=C2=A0 =C2=A0> > However once the inputs and outputs of a PSBT ar= e decided, a PSBT could
>=C2=A0 =C2=A0> > be "downgraded" back to v0 by creating= the unsigned transaction from the
>=C2=A0 =C2=A0> > above fields, and then dropping these new fields= .
>=C2=A0 =C2=A0> >
>=C2=A0 =C2=A0> > If the list finds that these changes are reasona= ble, I will write a PR
>=C2=A0 =C2=A0> > to modify BIP 174 to incorporate them.
>=C2=A0 =C2=A0> >
>=C2=A0 =C2=A0> > Thanks,
>=C2=A0 =C2=A0> > Andrew Chow
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0> _______________________________________________
>=C2=A0 =C2=A0> bitcoin-dev mailing list
>=C2=A0 =C2=A0> bitcoin-dev@lists.linuxfoundation.org
>=C2=A0 =C2=A0> https://lists.li= nuxfoundation.org/mailman/listinfo/bitcoin-dev
>=C2=A0 =C2=A0>


_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000085cbec05b7e50b0a--