Published on: 2014-02-28T20:10:32+00:00
On February 28th, 2014, Warren Togami Jr. emailed the Bitcoin developers mailing list to discuss the issue of transaction fees per kilobyte not accurately reflecting the actual cost to the network. He pointed out that this oversight was a flaw in the original Bitcoin design and shared a link to a GitHub commit by the Litecoin project for more information on the matter.In another email on the same day, Mark Friedenbach brought up the topic of transaction fees not compensating those who validate the blockchain. He argued that this was an externality and suggested that the existing network layer needed to be fixed. Friedenbach also encouraged users to support online privacy by implementing email encryption whenever possible.One of the emails highlighted concerns about transaction fees not covering the costs incurred by full nodes in validating the blockchain. The writer expressed worries about storing large amounts of data in the blockchain without providing compensation for full nodes. A link to a GitHub commit discussing Bitcoin's transaction fees was included in the email.An email conversation between Troy Benjegerdes and Warren Togami further explored the issue of transaction fees. Benjegerdes suggested that either transaction fees should cover any data added to the blockchain or the fee structure needed to be rethought. Togami agreed that transaction fees did not account for the actual cost to the network and identified an economic design flaw in the original Bitcoin design.The Bitcoin-development mailing list also featured suggestions from Mark Friedenbach to reduce the standard line length for regular transactions from 80 to 40 to prevent graffiti messages. He believed that no crypto-related data payload would require more than 40 bytes. Jeff Garzik supported reducing the size but proposed that regular transactions should still have the ability to include some metadata.Andreas Petersson expressed his views on using OP_RETURN and multisig transactions in the blockchain, suggesting that if users wanted to add extra data, they should use OP_RETURN as a better alternative. Petersson believed that block propagation times would have a greater impact on effective fees than dust-limit rules.An email exchange between Jeff Garzik and Jeremy Spilman discussed reducing the size of a max-sized operation push to 40 bytes. Spilman noted that the code did not enforce the most efficient encoding and suggested modifying it to strictly require no PUSHDATA.Gavin Andresen and Pavol Rusnak exchanged emails focusing on the technical aspects of Bitcoin transaction data, specifically related to reducing the standard line length to 40 bytes.The conversation between Pieter Wuille and Jeff Garzik centered around the inclusion of metadata in regular transactions. While Garzik suggested allowing some metadata, Wuille disagreed and pointed out contradictions in Garzik's statements regarding chain data storage endorsement.These emails and conversations collectively touched upon various topics such as transaction fees, data storage in the blockchain, reducing line lengths for transactions, and the inclusion of metadata in regular transactions.The forthcoming 0.9 release of Bitcoin will introduce a change making OP_RETURN standard, enabling the attachment of small amounts of metadata to transactions. However, this change has generated controversy due to concerns about the 80-byte limit on data storage. Supporters argue that this limit is based on 2x SHA256 or 1x SHA512, along with a small amount of metadata.While there are ongoing debates about the size of data storage, it is deemed important for regular transactions to be able to include some metadata. Nevertheless, there are concerns regarding the endorsement of chain data storage. It is crucial to clarify that this change does not endorse storing data in the chain but rather aims to make data less damaging.It should be noted that storing data in forever-unspendable TX outputs can lead to perpetual bloating of the UTXO. To address these concerns and ensure transparency, it is recommended that the release notes for the 0.9 release provide an explanation of this change. By offering clear communication and avoiding contradictory statements, the community can gain a better understanding of the rationale behind this update.
Updated on: 2023-08-01T07:43:43.095545+00:00