Published on: 2016-09-23T13:17:52+00:00
There are ongoing discussions in the Bitcoin community about options for serializing transactions. Two options being considered are Protocol Buffers (protobuf) and Compact Message Format (CMF). CMF is already used in Bitcoin Classic transactions and offers advantages such as reusing var-int parsing and better error reporting. Additionally, CMF is more compact and requires less tool support than protobuf.There is a suggestion to use Protobuf based on a BIP (Bitcoin Improvement Proposal), as it is compact, binary, and flexible. The payment protocol already uses Protobuf, making it an attractive option for further implementation. Protobuf also has good tool support.In an email exchange between Peter Todd and Tom, the issue of serializing transactions in a certain order is discussed. Tom believes that if the order of tokens is not fixed, it could lead to multiple interpretations of data, which is not allowed. Peter Todd suggests using a "Some/None" flag to mark whether optional data has been omitted, instead of fixed token orders. This suggestion is already addressed in the spec, which uses a generic concept where each field is given a name. Peter Todd also suggests extending the merkle tree down into transaction inputs and outputs.Tom, a member of the bitcoin-dev mailing list, requests a BIP number for his Flexible Transactions (FT) specification. He is advised to open a pull request on the bitcoin/bips repository after further discussion. The new version of 'script' (version 2) simplifies the data signed to be equivalent to the transaction-id. However, some functionality is lost, leading to questions about replacing SIGHASH_SINGLE and SIGHASH_ANYONECANPAY. It is suggested to add the ability to use only a hash of the prevout's scriptPubKey in the input. The token ScriptVersion is currently not allowed, but addressing block-malleability by extending the merkle tree to include the hash of v4 transactions alone is proposed.In another bitcoin-dev email thread, Tom discusses the serialization order of tokens in transactions and the need for a fixed order to avoid multiple interpretations. He suggests using a flag for optional data. Compatibility with existing software and extending the merkle tree into transaction inputs and outputs are also discussed.Tom formally requests the assignment of a BIP number for his FT spec, titled "Flexible Transactions." The proposal aims to make Bitcoin's transactions more flexible and easier to extend while fixing malleability issues and resolving technical debt. It introduces a new version number (4) and defines the use of Compact Message Format (CMF) for data following the version bytes. The proposal allows for new features to be added more cleanly in the future and shows that signatures can be removed from transactions with minimal software upgrades. The proposal specifies the serialization order for well-formatted transactions and includes changes to Bitcoin-script. The reference implementation can be found in Bitcoin Classic beta releases, but the deployment process is yet to be determined.
Updated on: 2023-08-01T19:02:14.906564+00:00