Published on: 2017-01-26T12:57:32+00:00
In January 2017, Tom Zander put forward a proposal to introduce a new transaction format for Bitcoin. The proposal suggested labeling bytes 2, 3, and 4 of the current transaction format as unused from a specific block height. It also recommended interpreting the first byte as varint, and only allowing transactions with a version number of 1 to be valid. However, there were some concerns raised about this proposal.One major issue was that implementing this change would require a hardfork, as existing nodes would not be able to deserialize the transaction. Additionally, it was pointed out that non-version 1 transactions have been permitted since v0.1, and version 2 transactions are already in use due to BIP68. Furthermore, if the proposal only affects network transfer, it would be considered a p2p protocol upgrade rather than a softfork or hardfork.The author of the proposal discusses three ways to introduce new transaction formats: through a softfork, which makes old clients unaware of the new format; through a hardfork, which requires new clients to understand the new format and leaves old clients behind; or p2p only, which has no impact on consensus. Regardless of the chosen method, the proposal states that one can introduce any new format they desire.The author also addresses the current structure of transactions, noting that the version field is always 4 bytes while the rest of the integer encoding is variable-sized. This means that bytes 2, 3, and 4 are typically set to zero. By changing the serialization of the version number to varint, each transaction would save three bytes. These bytes could then be used differently in version 1 transactions or may not be needed at all for newer formats. Another benefit of this change is that all integers in the transaction would follow the same var-int encoding, at least for FlexTrans.At present, there is no consensus rule that rejects transactions which provide false information about their version. Therefore, the proposed rule could only be implemented from a certain block height and would not apply retroactively. The suggested implementation involves labeling bytes 2, 3, and 4 as unused from the specified block height, while interpreting the first byte as varint. Additionally, a new rule would be added to only accept transactions with a version number of 1. This change could be made as a softfork.The author seeks feedback on any potential issues with this proposal. It is also worth noting that although most transactions have bytes 2, 3, and 4 set to zero, there is no transaction version defined that sets them to non-zero.
Updated on: 2023-08-01T19:25:33.384629+00:00