Return-Path: <jlrubin@mit.edu> Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9404CC013A for <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; Sat, 2 Jan 2021 01:34:13 -0500 Received: by mail-il1-f169.google.com with SMTP id x15so20669144ilq.1 for <bitcoin-dev@lists.linuxfoundation.org>; 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> <a0b996d1-049c-1c7a-e8c1-a6bc3834b0bd@achow101.com> In-Reply-To: <a0b996d1-049c-1c7a-e8c1-a6bc3834b0bd@achow101.com> From: Jeremy <jlrubin@mit.edu> Date: Fri, 1 Jan 2021 22:34:00 -0800 X-Gmail-Original-Message-ID: <CAD5xwhhz=cdS78KaigLycOWznv6RHWHAmn+STrpxhyT6SZzJ9Q@mail.gmail.com> Message-ID: <CAD5xwhhz=cdS78KaigLycOWznv6RHWHAmn+STrpxhyT6SZzJ9Q@mail.gmail.com> To: Andrew Chow <achow101-lists@achow101.com>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> 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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Sat, 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 <https://twitter.com/JeremyRubin> <https://twitter.com/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 <div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he= lvetica,sans-serif;font-size:small;color:#000000">One thing I think should = be added in V2 is the ability to specify sighash flags per-key as opposed t= o per-input.</div><div class=3D"gmail_default" style=3D"font-family:arial,h= elvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"= gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm= all;color:#000000">The per-key restriction is unfitting given that there ar= e circumstances where multisig signers may validate heterogenous logic.<br = clear=3D"all"></div><div><div dir=3D"ltr" class=3D"gmail_signature" data-sm= artmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitt= er.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://tw= itter.com/JeremyRubin" target=3D"_blank"></a></div></div></div><br></div><b= r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, = Dec 23, 2020 at 1:37 PM Andrew Chow via bitcoin-dev <<a href=3D"mailto:b= itcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org= </a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:= 0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">= Hi,<br> <br> On 12/22/20 10:30 PM, fiatjaf wrote:<br> > Hi Andrew.<br> ><br> > 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?<br> No, it is not just "improvements in the way data is structured."<= br> <br> The primary reason for these changes is to allow PSBT to properly <br> support adding inputs and outputs. This is a feature that many people <br> have requested, and the ways that people have been doing it are honestly <b= r> just hacks and not really the right way to be doing that. These changes <br= > allow for that feature to be supported well.<br> <br> Furthermore, it is possible to downgrade and upgrade PSBTs between the <br> two versions, once all inputs and outputs have been decided. Since <br> PSBTv2 is essentially just taking all of the normal transaction fields <br> and grouping them all with the rest of the data for those inputs and <br> outputs, it is easy to reconstruct a global unsigned transaction and <br> turn a PSBTv2 into a PSBTv0. It is likewise just as easy to go the other <b= r> way and break apart the global unsigned tx to turn a PSBTv0 into a <br> PSBTv2. Originally, I had considered requiring that once a transaction <br> was fully constructed it must be downgraded to a PSBTv0, but the <br> structure changes that were made do make it easier to work with PSBT so <br= > I decided not to add this requirement.<br> <br> Perhaps to maintain compatibility PSBT_GLOBAL_UNSIGNED_TX shouldn't be = <br> disallowed in PSBTv2 once the transaction is constructed? It would make <br= > things much more confusing though as it would no longer be a clean break.<b= r> <br> <br> Andrew Chow<br> <br> > 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.<br> ><br> > 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</a><br> ><br> >=C2=A0 =C2=A0---- On Tue, 22 Dec 2020 17:12:22 -0300 Andrew Chow via bi= tcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ= et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote ----<br> >=C2=A0 =C2=A0> Hi All,<br> >=C2=A0 =C2=A0><br> >=C2=A0 =C2=A0> I have some updates on this after speaking with some = people off-list.<br> >=C2=A0 =C2=A0><br> >=C2=A0 =C2=A0> Firstly, the version number will be set to 2. In most= discussions, this<br> >=C2=A0 =C2=A0> proposal was being referred to as PSBT version 2, so = it'll be easier and<br> >=C2=A0 =C2=A0> clearer to set the version number to 2.<br> >=C2=A0 =C2=A0><br> >=C2=A0 =C2=A0> For lock times, instead of a single=C2=A0 PSBT_IN_REQ= UIRED_LOCKTIME field,<br> >=C2=A0 =C2=A0> there will be 2 of them, one for a time based lock ti= me, and the other<br> >=C2=A0 =C2=A0> for height based. These will be:<br> >=C2=A0 =C2=A0> * PSBT_IN_REQUIRED_TIME_LOCKTIME =3D 0x10<br> >=C2=A0 =C2=A0>=C2=A0 =C2=A0 * Key: empty<br> >=C2=A0 =C2=A0>=C2=A0 =C2=A0 * Value: 32 bit unsigned little endian i= nteger greater than or equal<br> >=C2=A0 =C2=A0> to 500000000 representing the minimum Unix timestamp = that this input<br> >=C2=A0 =C2=A0> requires to be set as the transaction's lock time= . Must be omitted in<br> >=C2=A0 =C2=A0> PSBTv0, and may be omitted in PSBTv2<br> >=C2=A0 =C2=A0> * PSBT_IN_REQUIRED_HEIGHT_LOCKTIME =3D 0x11<br> >=C2=A0 =C2=A0>=C2=A0 =C2=A0 * Key: empty<br> >=C2=A0 =C2=A0>=C2=A0 =C2=A0 * Value: 32 bit unsigned little endian i= nteger less than 500000000<br> >=C2=A0 =C2=A0> representing the minimum block height that this input= requires to be set<br> >=C2=A0 =C2=A0> as the transaction's lock time. Must be omitted i= n PSBTv0, and may be<br> >=C2=A0 =C2=A0> omitted in PSBTv2.<br> >=C2=A0 =C2=A0><br> >=C2=A0 =C2=A0> Having two lock time fields is necessary due to the b= ehavior where all<br> >=C2=A0 =C2=A0> inputs must use the same type of lock time (height or= time). Thus if an<br> >=C2=A0 =C2=A0> input requires a particular type of lock time, it mus= t set the requisite<br> >=C2=A0 =C2=A0> field. Any new inputs being added must be able to acc= ommodate all<br> >=C2=A0 =C2=A0> existing inputs' lock time type. This means they = either must not have a<br> >=C2=A0 =C2=A0> lock time specified (i.e. no OP_CLTV involved), or ha= ve branches that<br> >=C2=A0 =C2=A0> allow the acceptance of either type. If an input has = a lock time type<br> >=C2=A0 =C2=A0> that is incompatible with the rest of the transaction= , it must not be added.<br> >=C2=A0 =C2=A0><br> >=C2=A0 =C2=A0> PSBT_GLOBAL_PREFERRED_LOCKTIME is changed to purely b= e the fallback<br> >=C2=A0 =C2=A0> option if no input lock time fields are present. If t= here are input lock<br> >=C2=A0 =C2=A0> times, all lock time calculations must ignore it.<br> >=C2=A0 =C2=A0><br> >=C2=A0 =C2=A0> Any role which does lock time calculation will first = check if there are<br> >=C2=A0 =C2=A0> input lock time fields. If there are not, it must the= n check for a<br> >=C2=A0 =C2=A0> PSBT_GLOBAL_PREFERRED_LOCKTIME. If this field exists,= its value is the<br> >=C2=A0 =C2=A0> transaction's lock time. If it does not, the lock= time is 0. If there<br> >=C2=A0 =C2=A0> are input lock time fields, it must choose the type w= hich does not<br> >=C2=A0 =C2=A0> invalidate any inputs. The lock time is then determin= ed to be the<br> >=C2=A0 =C2=A0> maximum value of all of the lock time fields for the = chosen type.<br> >=C2=A0 =C2=A0><br> >=C2=A0 =C2=A0><br> >=C2=A0 =C2=A0> Additionally, I would like to add a new global field:= <br> >=C2=A0 =C2=A0> * PSBT_GLOBAL_UNDER_CONSTRUCTION =3D 0x05<br> >=C2=A0 =C2=A0>=C2=A0 =C2=A0 * Key: empty<br> >=C2=A0 =C2=A0>=C2=A0 =C2=A0 * Value: A single byte as a boolean. 0 f= or False, 1 for True. All<br> >=C2=A0 =C2=A0> other values ore prohibited. Must be omitted for PSBT= v0, may be omitted<br> >=C2=A0 =C2=A0> in PSBTv2.<br> >=C2=A0 =C2=A0><br> >=C2=A0 =C2=A0> PSBT_GLOBAL_UNDER_CONSTRUCTION is used to signal whet= her inputs and<br> >=C2=A0 =C2=A0> outputs can be added to the PSBT. This flag may be se= t to True when<br> >=C2=A0 =C2=A0> inputs and outputs are being updated, signed, and fin= alized. However<br> >=C2=A0 =C2=A0> care must be taken when there are existing signatures= . If this field is<br> >=C2=A0 =C2=A0> omitted or set to False, no further inputs and output= s may be added to<br> >=C2=A0 =C2=A0> the PSBT.<br> >=C2=A0 =C2=A0><br> >=C2=A0 =C2=A0> Several rules must be followed to ensure that adding = additional inputs<br> >=C2=A0 =C2=A0> and outputs will not invalidate existing signatures. = First, an input or<br> >=C2=A0 =C2=A0> output adder must check for any existing signatures i= n all of the other<br> >=C2=A0 =C2=A0> inputs. If there are none, the input or output may be= added in any<br> >=C2=A0 =C2=A0> position. If there are one or more signatures, each s= ignature's sighash<br> >=C2=A0 =C2=A0> type must be examined. Inputs may only be added if al= l existing<br> >=C2=A0 =C2=A0> signatures use SIGHASH_ANYONECANPAY. Outputs may only= be added if all<br> >=C2=A0 =C2=A0> existing signatures use SIGHASH_NONE. If an input has= a signature using<br> >=C2=A0 =C2=A0> SIGHASH_SINGLE, the same number of inputs and outputs= must be added<br> >=C2=A0 =C2=A0> before that input and it's corresponding output. = For all other sighash<br> >=C2=A0 =C2=A0> types (i.e. SIGHASH_ALL and any future sighash types)= , no inputs or<br> >=C2=A0 =C2=A0> outputs may be added to the PSBT. Specific exceptions= can be made in the<br> >=C2=A0 =C2=A0> future for additional sighash types.<br> >=C2=A0 =C2=A0><br> >=C2=A0 =C2=A0> Furthermore, these newly added inputs must follow add= itional lock time<br> >=C2=A0 =C2=A0> rules. Because all signatures, regardless of sighash = type, sign the<br> >=C2=A0 =C2=A0> transaction lock time, newly added inputs when there = are existing<br> >=C2=A0 =C2=A0> signatures must have the same type of lock time used = in the transaction,<br> >=C2=A0 =C2=A0> and must be less than or equal to the transaction loc= k time. It must not<br> >=C2=A0 =C2=A0> cause the transaction lock time to change, otherwise = the signatures will<br> >=C2=A0 =C2=A0> be invalidated.<br> >=C2=A0 =C2=A0><br> >=C2=A0 =C2=A0><br> >=C2=A0 =C2=A0> Lastly, to uniquely identify transactions for combine= rs, a txid can be<br> >=C2=A0 =C2=A0> computed from the information present in the PSBT. In= ternally, combiners<br> >=C2=A0 =C2=A0> can create an unsigned transaction given the transact= ion version, the<br> >=C2=A0 =C2=A0> input prevouts, the outputs, and the computed locktim= e. This can then be<br> >=C2=A0 =C2=A0> used to calculate a txid and thus used as a way to id= entify PSBTs.<br> >=C2=A0 =C2=A0> Combiners will need to do this for all version 2 PSBT= s in order to avoid<br> >=C2=A0 =C2=A0> combining distinct transactions.<br> >=C2=A0 =C2=A0><br> >=C2=A0 =C2=A0><br> >=C2=A0 =C2=A0> Andrew Chow<br> >=C2=A0 =C2=A0><br> >=C2=A0 =C2=A0> On 12/9/20 5:25 PM, Andrew Chow wrote:<br> >=C2=A0 =C2=A0> > Hi All,<br> >=C2=A0 =C2=A0> ><br> >=C2=A0 =C2=A0> > I would like to propose a new PSBT version that = addresses a few<br> >=C2=A0 =C2=A0> > deficiencies in the current PSBT v0. As this wil= l be backwards<br> >=C2=A0 =C2=A0> > incompatible, a new PSBT version will be used, v= 1.<br> >=C2=A0 =C2=A0> ><br> >=C2=A0 =C2=A0> > The primary change is to truly have all input an= d output data for each<br> >=C2=A0 =C2=A0> > in their respective maps. Instead of having to p= arse an unsigned<br> >=C2=A0 =C2=A0> > transaction and lookup some data from there, and= other data from the<br> >=C2=A0 =C2=A0> > correct map, all of the data for an input will b= e contained in its map.<br> >=C2=A0 =C2=A0> > Doing so also disallows PSBT_GLOBAL_UNSIGNED_TX = in this new version.<br> >=C2=A0 =C2=A0> > Thus I propose that the following fields be adde= d:<br> >=C2=A0 =C2=A0> ><br> >=C2=A0 =C2=A0> > Global:<br> >=C2=A0 =C2=A0> > * PSBT_GLOBAL_TX_VERSION =3D 0x02<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: 32-bit little endian= unsigned integer for the transaction<br> >=C2=A0 =C2=A0> > version number. Must be provided in PSBT v1 and = omitted in v0.<br> >=C2=A0 =C2=A0> > * PSBT_GLOBAL_PREFERRED_LOCKTIME =3D 0x03<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: 32 bit little endian= unsigned integer for the preferred<br> >=C2=A0 =C2=A0> > transaction lock time. Must be omitted in PSBT v= 0. May be provided in<br> >=C2=A0 =C2=A0> > PSBT v1, assumed to be 0 if not provided.<br> >=C2=A0 =C2=A0> > * PSBT_GLOBAL_INPUT_COUNT =3D 0x04<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: Compact size unsigne= d integer. Number of inputs in this<br> >=C2=A0 =C2=A0> > PSBT. Must be provided in PSBT v1 and omitted in= v0.<br> >=C2=A0 =C2=A0> > * PSBT_GLOBAL_OUTPUT_COUNT =3D 0x05<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: Compact size unsigne= d integer. Number of outputs in this<br> >=C2=A0 =C2=A0> > PSBT. Must be provided in PSBT v1 and omitted in= v0.<br> >=C2=A0 =C2=A0> ><br> >=C2=A0 =C2=A0> > Input:<br> >=C2=A0 =C2=A0> > * PSBT_IN_PREVIOUS_TXID =3D 0x0e<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: 32 byte txid of the = previous transaction whose output at<br> >=C2=A0 =C2=A0> > PSBT_IN_OUTPUT_INDEX is being spent. Must be pro= vided in PSBT v1 and<br> >=C2=A0 =C2=A0> > omitted in v0.<br> >=C2=A0 =C2=A0> > * PSBT_IN_OUTPUT_INDEX =3D 0x0f<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: 32 bit little endian= integer for the index of the output<br> >=C2=A0 =C2=A0> > being spent. Must be provided in PSBT v1 and omi= tted in v0.<br> >=C2=A0 =C2=A0> > * PSBT_IN_SEQUENCE =3D 0x0f<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: 32 bit unsigned litt= le endian integer for the sequence<br> >=C2=A0 =C2=A0> > number. Must be omitted in PSBT v0. May be provi= ded in PSBT v1 assumed<br> >=C2=A0 =C2=A0> > to be max sequence (0xffffffff) if not provided.= <br> >=C2=A0 =C2=A0> > * PSBT_IN_REQUIRED_LOCKTIME =3D 0x10<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: 32 bit unsigned litt= le endian integer for the lock time that<br> >=C2=A0 =C2=A0> > this input requires. Must be omitted in PSBT v0.= May be provided in PSBT<br> >=C2=A0 =C2=A0> > v1, assumed to be 0 if not provided.<br> >=C2=A0 =C2=A0> ><br> >=C2=A0 =C2=A0> > Output:<br> >=C2=A0 =C2=A0> > * PSBT_OUT_VALUE =3D 0x03<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: 64-bit unsigned litt= le endian integer for the output's<br> >=C2=A0 =C2=A0> > amount in satoshis. Must be provided in PSBT v1 = and omitted in v0.<br> >=C2=A0 =C2=A0> > * PSBT_OUT_OUTPUT_SCRIPT =3D 0x04<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Key: empty<br> >=C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0* Value: The script for this = output. Otherwise known as the<br> >=C2=A0 =C2=A0> > scriptPubKey. Must be provided in PSBT v1 and om= itted in v0.<br> >=C2=A0 =C2=A0> ><br> >=C2=A0 =C2=A0> > This change allows for PSBT to be used in the co= nstruction of<br> >=C2=A0 =C2=A0> > transactions. With these new fields, inputs and = outputs can be added as<br> >=C2=A0 =C2=A0> > needed. One caveat is that there is no longer a = unique transaction<br> >=C2=A0 =C2=A0> > identifier so more care must be taken when combi= ning PSBTs.<br> >=C2=A0 =C2=A0> > Additionally, adding new inputs and outputs must= be done such that<br> >=C2=A0 =C2=A0> > signatures are not invalidated. This may be hard= er to specify.<br> >=C2=A0 =C2=A0> ><br> >=C2=A0 =C2=A0> > An important thing to note in this proposal are = the fields<br> >=C2=A0 =C2=A0> > PSBT_GLOBAL_PREFERRED_LOCKTIME and PSBT_IN_REQUI= RED_LOCKTIME. A Bitcoin<br> >=C2=A0 =C2=A0> > transaction only has a single locktime yet a PSB= T may have multiple<br> >=C2=A0 =C2=A0> > locktimes. To choose the locktime for the transa= ction, finalizers must<br> >=C2=A0 =C2=A0> > choose the maximum of all of the *_LOCKTIME fiel= ds.<br> >=C2=A0 =C2=A0> > PSBT_IN_REQUIRED_LOCKTIME is added because some = inputs, such as those<br> >=C2=A0 =C2=A0> > involving OP_CHECKLOCKTIMEVERIFY, require a spec= ific minimum locktime to<br> >=C2=A0 =C2=A0> > be set. This field allows finalizers to choose a= locktime that is high<br> >=C2=A0 =C2=A0> > enough for all inputs without needing to underst= and the scripts<br> >=C2=A0 =C2=A0> > involved. The PSBT_GLOBAL_PREFERRED_LOCKTIME is = the locktime to use if<br> >=C2=A0 =C2=A0> > no inputs require a particular locktime.<br> >=C2=A0 =C2=A0> ><br> >=C2=A0 =C2=A0> > As these changes disallow the PSBT_GLOBAL_UNSIGN= ED_TX field, PSBT v1<br> >=C2=A0 =C2=A0> > needs the version number bump to enforce backwar= ds incompatibility.<br> >=C2=A0 =C2=A0> > However once the inputs and outputs of a PSBT ar= e decided, a PSBT could<br> >=C2=A0 =C2=A0> > be "downgraded" back to v0 by creating= the unsigned transaction from the<br> >=C2=A0 =C2=A0> > above fields, and then dropping these new fields= .<br> >=C2=A0 =C2=A0> ><br> >=C2=A0 =C2=A0> > If the list finds that these changes are reasona= ble, I will write a PR<br> >=C2=A0 =C2=A0> > to modify BIP 174 to incorporate them.<br> >=C2=A0 =C2=A0> ><br> >=C2=A0 =C2=A0> > Thanks,<br> >=C2=A0 =C2=A0> > Andrew Chow<br> >=C2=A0 =C2=A0><br> >=C2=A0 =C2=A0><br> >=C2=A0 =C2=A0> _______________________________________________<br> >=C2=A0 =C2=A0> bitcoin-dev mailing list<br> >=C2=A0 =C2=A0> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o= rg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br> >=C2=A0 =C2=A0> <a href=3D"https://lists.linuxfoundation.org/mailman/= listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.li= nuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br> >=C2=A0 =C2=A0><br> <br> <br> _______________________________________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev</a><br> </blockquote></div> --00000000000085cbec05b7e50b0a--