Author: fiatjaf 2020-12-23 03:30:20
Published on: 2020-12-23T03:30:20+00:00
A new version of PSBT (v1) has been proposed by Andrew Chow to address deficiencies in the current PSBT v0. The primary change is to have all input and output data for each in their respective maps with additional fields added for Global, Input, and Output. These changes allow for PSBT to be used in the construction of transactions, with inputs and outputs being added as needed. However, there is no longer a unique transaction identifier so more care must be taken when combining PSBTs, and adding new inputs and outputs must be done such that signatures are not invalidated.An important thing to note in this proposal are the fields PSBT_GLOBAL_PREFERRED_LOCKTIME and PSBT_IN_REQUIRED_LOCKTIME. 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.Additionally, there will be 2 PSBT_IN_REQUIRED_LOCKTIME fields for lock times - one for a time-based lock time and the other for a height-based lock time. 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.Moreover, a new global field, PSBT_GLOBAL_UNDER_CONSTRUCTION, will be added, which is used to signal whether inputs and outputs can be added to the PSBT. If this field is omitted or set to False, no further inputs and outputs may be added to the PSBT. Care must be taken when there are existing signatures, and rules must be followed to ensure that adding additional inputs and outputs will not invalidate existing signatures.Lastly, to uniquely identify transactions for combiners, a txid can be computed from the information present in the PSBT. 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.The given context is an email list for bitcoin developers hosted on the Linux Foundation's website. This mailing list serves as a platform for developers to discuss and collaborate on various aspects of the Bitcoin network and its underlying technology. It provides a space for developers to share ideas, raise concerns, and propose solutions related to Bitcoin development.The bitcoin-dev mailing list is open to anyone interested in contributing to the development of the Bitcoin network. The list is moderated to ensure that discussions remain focused on technical topics related to Bitcoin development. Subscribers are encouraged to follow the code of conduct outlined by the Linux Foundation and to be respectful towards other members of the community.To subscribe to the bitcoin-dev mailing list, users can visit the Linux Foundation's website and sign up using their email address. Once subscribed, users can participate in ongoing discussions or start new threads related to Bitcoin development. The list also archives previous discussions, making it a valuable resource for developers looking to learn more about Bitcoin development.In conclusion, the bitcoin-dev mailing list is an important platform for developers working on the Bitcoin network. It provides a space for collaboration and discussion, helping to drive innovation and improve the functionality of the Bitcoin network. Anyone interested in contributing to Bitcoin development is encouraged to join the list and participate in the ongoing conversations.
Updated on: 2023-06-14T16:28:19.452811+00:00