Published on: 2021-08-29T14:56:16+00:00
On August 29th, 2021, a user named Prayank initiated a discussion on the bitcoin-dev forum regarding whether more numbers should be permitted in transaction version. They presented an example illustrating how transaction version could be utilized for betting on events with two possible outcomes. However, another user named Pieter expressed confusion regarding the relevance of this suggestion to transaction version numbers.Pieter argued that Bitcoin transactions should solely contain essential information for validation purposes. Currently, there are no consensus rules or relay policies that consider the version number, except for it being 1 or 2 (due to BIP68). Therefore, utilizing any numbers beyond these two would be futile and compromise privacy. Additionally, unused version numbers may be employed for future consensus rules, so employing them for non-protocol-defined purposes could disrupt these rules.To support their viewpoint, Pieter referenced a code snippet of "Hello, world!" shared by the original poster. The snippet included a link to a question on Bitcoin Stackexchange related to Bitcoin transaction version. In the question, the author provided an example demonstrating how transaction version can be used for betting on events involving two outcomes, without relying on centralized servers or trusting third parties. The approach involved creating a multisig address using two public keys, one entered by the user and the other from mempool. A funding transaction was then executed, utilizing version bits to indicate whether Alice wanted to bet on India or Australia. The author sought confirmation on the correctness of their approach until the funding transaction and asked for opinions on whether more numbers should be allowed in transaction version.The original poster also shared a link to a Github repository containing the complete example for reference. Despite this detailed example, Pieter remained unconvinced and emphasized that version numbers lacking protocol-defined significance should not become standard, but rather be reserved for future extensions.
Updated on: 2023-08-02T04:38:59.600303+00:00