path: root/1c/b600bbd00d652bfcf2c5e3bd0254e7a87dfed5

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