📅 Original date posted:2020-12-23
📝 Original message: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?
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
fiatjaf [ARCHIVE] /
npub1v2…pmakl
2023-06-07 18:27:45
in reply to nevent1q…c72a
Author Public Key
npub1v2xa40strmvauf2gr5gjj5c3yqlytar7p3v64nfg0ke6e0vkvvkqxpmaklPublished at
2023-06-07 18:27:45Event JSON
{
"id": "ae5e9f1bab2d97aa69cdfcdec0b50fd695ca00f30e10467e9d6a6291f63914f1",
"pubkey": "628ddabe0b1ed9de25481d11295311203e45f47e0c59aacd287db3acbd96632c",
"created_at": 1686162465,
"kind": 1,
"tags": [
[
"e",
"2792f361b774511026389d2e288e952fe665c1e4f3aafdef74b1d12c14183adc",
"",
"root"
],
[
"e",
"30241b91266cb557e24539209fd94d9c7e3ab6ece49971f4ef67daf96d20ee1e",
"",
"reply"
],
[
"p",
"4a273da3c9ab85c096f859e6ca066d2fdfe762406cadc2f4d58aa75468aca8d0"
]
],
"content": "📅 Original date posted:2020-12-23\n📝 Original message:Hi Andrew.\n\nI'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?\n\nUltimately 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.\n\nAlso 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\n\n ---- On Tue, 22 Dec 2020 17:12:22 -0300 Andrew Chow via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote ----\n \u003e Hi All,\n \u003e \n \u003e I have some updates on this after speaking with some people off-list.\n \u003e \n \u003e Firstly, the version number will be set to 2. In most discussions, this \n \u003e proposal was being referred to as PSBT version 2, so it'll be easier and \n \u003e clearer to set the version number to 2.\n \u003e \n \u003e For lock times, instead of a single PSBT_IN_REQUIRED_LOCKTIME field, \n \u003e there will be 2 of them, one for a time based lock time, and the other \n \u003e for height based. These will be:\n \u003e * PSBT_IN_REQUIRED_TIME_LOCKTIME = 0x10\n \u003e * Key: empty\n \u003e * Value: 32 bit unsigned little endian integer greater than or equal \n \u003e to 500000000 representing the minimum Unix timestamp that this input \n \u003e requires to be set as the transaction's lock time. Must be omitted in \n \u003e PSBTv0, and may be omitted in PSBTv2\n \u003e * PSBT_IN_REQUIRED_HEIGHT_LOCKTIME = 0x11\n \u003e * Key: empty\n \u003e * Value: 32 bit unsigned little endian integer less than 500000000 \n \u003e representing the minimum block height that this input requires to be set \n \u003e as the transaction's lock time. Must be omitted in PSBTv0, and may be \n \u003e omitted in PSBTv2.\n \u003e \n \u003e Having two lock time fields is necessary due to the behavior where all \n \u003e inputs must use the same type of lock time (height or time). Thus if an \n \u003e input requires a particular type of lock time, it must set the requisite \n \u003e field. Any new inputs being added must be able to accommodate all \n \u003e existing inputs' lock time type. This means they either must not have a \n \u003e lock time specified (i.e. no OP_CLTV involved), or have branches that \n \u003e allow the acceptance of either type. If an input has a lock time type \n \u003e that is incompatible with the rest of the transaction, it must not be added.\n \u003e \n \u003e PSBT_GLOBAL_PREFERRED_LOCKTIME is changed to purely be the fallback \n \u003e option if no input lock time fields are present. If there are input lock \n \u003e times, all lock time calculations must ignore it.\n \u003e \n \u003e Any role which does lock time calculation will first check if there are \n \u003e input lock time fields. If there are not, it must then check for a \n \u003e PSBT_GLOBAL_PREFERRED_LOCKTIME. If this field exists, its value is the \n \u003e transaction's lock time. If it does not, the lock time is 0. If there \n \u003e are input lock time fields, it must choose the type which does not \n \u003e invalidate any inputs. The lock time is then determined to be the \n \u003e maximum value of all of the lock time fields for the chosen type.\n \u003e \n \u003e \n \u003e Additionally, I would like to add a new global field:\n \u003e * PSBT_GLOBAL_UNDER_CONSTRUCTION = 0x05\n \u003e * Key: empty\n \u003e * Value: A single byte as a boolean. 0 for False, 1 for True. All \n \u003e other values ore prohibited. Must be omitted for PSBTv0, may be omitted \n \u003e in PSBTv2.\n \u003e \n \u003e PSBT_GLOBAL_UNDER_CONSTRUCTION is used to signal whether inputs and \n \u003e outputs can be added to the PSBT. This flag may be set to True when \n \u003e inputs and outputs are being updated, signed, and finalized. However \n \u003e care must be taken when there are existing signatures. If this field is \n \u003e omitted or set to False, no further inputs and outputs may be added to \n \u003e the PSBT.\n \u003e \n \u003e Several rules must be followed to ensure that adding additional inputs \n \u003e and outputs will not invalidate existing signatures. First, an input or \n \u003e output adder must check for any existing signatures in all of the other \n \u003e inputs. If there are none, the input or output may be added in any \n \u003e position. If there are one or more signatures, each signature's sighash \n \u003e type must be examined. Inputs may only be added if all existing \n \u003e signatures use SIGHASH_ANYONECANPAY. Outputs may only be added if all \n \u003e existing signatures use SIGHASH_NONE. If an input has a signature using \n \u003e SIGHASH_SINGLE, the same number of inputs and outputs must be added \n \u003e before that input and it's corresponding output. For all other sighash \n \u003e types (i.e. SIGHASH_ALL and any future sighash types), no inputs or \n \u003e outputs may be added to the PSBT. Specific exceptions can be made in the \n \u003e future for additional sighash types.\n \u003e \n \u003e Furthermore, these newly added inputs must follow additional lock time \n \u003e rules. Because all signatures, regardless of sighash type, sign the \n \u003e transaction lock time, newly added inputs when there are existing \n \u003e signatures must have the same type of lock time used in the transaction, \n \u003e and must be less than or equal to the transaction lock time. It must not \n \u003e cause the transaction lock time to change, otherwise the signatures will \n \u003e be invalidated.\n \u003e \n \u003e \n \u003e Lastly, to uniquely identify transactions for combiners, a txid can be \n \u003e computed from the information present in the PSBT. Internally, combiners \n \u003e can create an unsigned transaction given the transaction version, the \n \u003e input prevouts, the outputs, and the computed locktime. This can then be \n \u003e used to calculate a txid and thus used as a way to identify PSBTs. \n \u003e Combiners will need to do this for all version 2 PSBTs in order to avoid \n \u003e combining distinct transactions.\n \u003e \n \u003e \n \u003e Andrew Chow\n \u003e \n \u003e On 12/9/20 5:25 PM, Andrew Chow wrote:\n \u003e \u003e Hi All,\n \u003e \u003e\n \u003e \u003e I would like to propose a new PSBT version that addresses a few\n \u003e \u003e deficiencies in the current PSBT v0. As this will be backwards\n \u003e \u003e incompatible, a new PSBT version will be used, v1.\n \u003e \u003e\n \u003e \u003e The primary change is to truly have all input and output data for each\n \u003e \u003e in their respective maps. Instead of having to parse an unsigned\n \u003e \u003e transaction and lookup some data from there, and other data from the\n \u003e \u003e correct map, all of the data for an input will be contained in its map.\n \u003e \u003e Doing so also disallows PSBT_GLOBAL_UNSIGNED_TX in this new version.\n \u003e \u003e Thus I propose that the following fields be added:\n \u003e \u003e\n \u003e \u003e Global:\n \u003e \u003e * PSBT_GLOBAL_TX_VERSION = 0x02\n \u003e \u003e * Key: empty\n \u003e \u003e * Value: 32-bit little endian unsigned integer for the transaction\n \u003e \u003e version number. Must be provided in PSBT v1 and omitted in v0.\n \u003e \u003e * PSBT_GLOBAL_PREFERRED_LOCKTIME = 0x03\n \u003e \u003e * Key: empty\n \u003e \u003e * Value: 32 bit little endian unsigned integer for the preferred\n \u003e \u003e transaction lock time. Must be omitted in PSBT v0. May be provided in\n \u003e \u003e PSBT v1, assumed to be 0 if not provided.\n \u003e \u003e * PSBT_GLOBAL_INPUT_COUNT = 0x04\n \u003e \u003e * Key: empty\n \u003e \u003e * Value: Compact size unsigned integer. Number of inputs in this\n \u003e \u003e PSBT. Must be provided in PSBT v1 and omitted in v0.\n \u003e \u003e * PSBT_GLOBAL_OUTPUT_COUNT = 0x05\n \u003e \u003e * Key: empty\n \u003e \u003e * Value: Compact size unsigned integer. Number of outputs in this\n \u003e \u003e PSBT. Must be provided in PSBT v1 and omitted in v0.\n \u003e \u003e\n \u003e \u003e Input:\n \u003e \u003e * PSBT_IN_PREVIOUS_TXID = 0x0e\n \u003e \u003e * Key: empty\n \u003e \u003e * Value: 32 byte txid of the previous transaction whose output at\n \u003e \u003e PSBT_IN_OUTPUT_INDEX is being spent. Must be provided in PSBT v1 and\n \u003e \u003e omitted in v0.\n \u003e \u003e * PSBT_IN_OUTPUT_INDEX = 0x0f\n \u003e \u003e * Key: empty\n \u003e \u003e * Value: 32 bit little endian integer for the index of the output\n \u003e \u003e being spent. Must be provided in PSBT v1 and omitted in v0.\n \u003e \u003e * PSBT_IN_SEQUENCE = 0x0f\n \u003e \u003e * Key: empty\n \u003e \u003e * Value: 32 bit unsigned little endian integer for the sequence\n \u003e \u003e number. Must be omitted in PSBT v0. May be provided in PSBT v1 assumed\n \u003e \u003e to be max sequence (0xffffffff) if not provided.\n \u003e \u003e * PSBT_IN_REQUIRED_LOCKTIME = 0x10\n \u003e \u003e * Key: empty\n \u003e \u003e * Value: 32 bit unsigned little endian integer for the lock time that\n \u003e \u003e this input requires. Must be omitted in PSBT v0. May be provided in PSBT\n \u003e \u003e v1, assumed to be 0 if not provided.\n \u003e \u003e\n \u003e \u003e Output:\n \u003e \u003e * PSBT_OUT_VALUE = 0x03\n \u003e \u003e * Key: empty\n \u003e \u003e * Value: 64-bit unsigned little endian integer for the output's\n \u003e \u003e amount in satoshis. Must be provided in PSBT v1 and omitted in v0.\n \u003e \u003e * PSBT_OUT_OUTPUT_SCRIPT = 0x04\n \u003e \u003e * Key: empty\n \u003e \u003e * Value: The script for this output. Otherwise known as the\n \u003e \u003e scriptPubKey. Must be provided in PSBT v1 and omitted in v0.\n \u003e \u003e\n \u003e \u003e This change allows for PSBT to be used in the construction of\n \u003e \u003e transactions. With these new fields, inputs and outputs can be added as\n \u003e \u003e needed. One caveat is that there is no longer a unique transaction\n \u003e \u003e identifier so more care must be taken when combining PSBTs.\n \u003e \u003e Additionally, adding new inputs and outputs must be done such that\n \u003e \u003e signatures are not invalidated. This may be harder to specify.\n \u003e \u003e\n \u003e \u003e An important thing to note in this proposal are the fields\n \u003e \u003e PSBT_GLOBAL_PREFERRED_LOCKTIME and PSBT_IN_REQUIRED_LOCKTIME. A Bitcoin\n \u003e \u003e transaction only has a single locktime yet a PSBT may have multiple\n \u003e \u003e locktimes. To choose the locktime for the transaction, finalizers must\n \u003e \u003e choose the maximum of all of the *_LOCKTIME fields.\n \u003e \u003e PSBT_IN_REQUIRED_LOCKTIME is added because some inputs, such as those\n \u003e \u003e involving OP_CHECKLOCKTIMEVERIFY, require a specific minimum locktime to\n \u003e \u003e be set. This field allows finalizers to choose a locktime that is high\n \u003e \u003e enough for all inputs without needing to understand the scripts\n \u003e \u003e involved. The PSBT_GLOBAL_PREFERRED_LOCKTIME is the locktime to use if\n \u003e \u003e no inputs require a particular locktime.\n \u003e \u003e\n \u003e \u003e As these changes disallow the PSBT_GLOBAL_UNSIGNED_TX field, PSBT v1\n \u003e \u003e needs the version number bump to enforce backwards incompatibility.\n \u003e \u003e However once the inputs and outputs of a PSBT are decided, a PSBT could\n \u003e \u003e be \"downgraded\" back to v0 by creating the unsigned transaction from the\n \u003e \u003e above fields, and then dropping these new fields.\n \u003e \u003e\n \u003e \u003e If the list finds that these changes are reasonable, I will write a PR\n \u003e \u003e to modify BIP 174 to incorporate them.\n \u003e \u003e\n \u003e \u003e Thanks,\n \u003e \u003e Andrew Chow\n \u003e \n \u003e \n \u003e _______________________________________________\n \u003e bitcoin-dev mailing list\n \u003e bitcoin-dev at lists.linuxfoundation.org\n \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n \u003e",
"sig": "b701be4633a5beb577ab6342f6ba08e53245e6cecf098109423174ba379867dcd86e605f0448662e6e4a2527f2e4039dc538a34a248b76f0a029b21fcaf7479d"
}