Published on: 2016-02-02T19:22:10+00:00
In a discussion between Toby Padilla and Luke Dashjr, the use of OP_RETURN values in Bitcoin transactions is debated. Toby argues that PaymentRequests limit the use of OP_RETURN values, as they must be greater than zero, creating a pre-OP_RETURN environment. Luke counters, suggesting that coins should be burned instead of allowing zero value OP_RETURNs. However, Toby believes there is a better alternative.The conversation revolves around the limitations of PaymentRequests regarding OP_RETURN values. Toby explains that PaymentRequests allow for similar transactions as non-PaymentRequest based transactions, but with the limitation that OP_RETURN values must be greater than zero. In contrast, Luke believes that OP_RETURN can be used, but coins would need to be burned, and he sees no benefit in changing that.Toby clarifies his point by mentioning BIP70, where the key for redeeming inputs can be in the user's wallet, allowing transaction construction on another machine without needing a key. However, currently, transaction construction on another machine with zero value OP_RETURNs is not possible. Despite their disagreement, both parties acknowledge that a key is always necessary for redeeming inputs in Bitcoin transactions.On January 26, 2016, Toby sent a message to Luke discussing the encoding of data on the blockchain. Luke suggests that supporting OP_RETURN in PaymentRequests is unnecessary, but Toby argues that it is important because people may use worse methods for encoding data. Toby also mentions the difficulty of constructing a transaction with a zero value OP_RETURN without keys in an environment without keys. Luke does not understand Toby's statement.The discussion focuses on a draft proposal that has not been approved by the mailing list yet. The draft suggests accepting zero value OP_RETURN outputs in BIP70 payment requests, which were previously ignored. The author argues that this feature would be useful for encoding data on the blockchain using PaymentRequests. However, Luke strongly advises against publishing or implementing this BIP, as he sees no benefit to the network and believes it could encourage spam. He also argues that the proposed changes are detrimental and would make users unwilling participants in spam.The author responds by giving an example of how merchants can add the hash of a plain text invoice to the checkout transaction by constructing the PaymentRequest with the invoice hash in an OP_RETURN. Toby argues that merchants and Bitcoin application developers would benefit from this BIP because they can construct transactions with OP_RETURN data without needing keys. Prior to this BIP, such transactions needed to be executed within the same software. Luke questions the relevance to keys and argues that the proposed changes are not compatible with existing and future software. He concludes that implementing either BIP 70 or this draft would have severe consequences, emphasizing that losing burned bitcoins is better than having a way to avoid them.The author of a Bitcoin Improvement Proposal (BIP) warns against publishing or implementing it due to potential spam and user unwillingness. The BIP suggests allowing merchants to add plain text invoice hashes to checkout transactions using PaymentRequests with zero value OP_RETURN outputs. However, the proposal lacks wallet support for checking upfront, may encourage spam, and does not consider the relevance to keys. The proposed changes are also not backward nor forward compatible, resulting in severe consequences.The author has submitted a new BIP draft that alters the Payment Protocol to allow for zero value OP_RETURN outputs in serialized PaymentRequests. This allows wallets to participate in current and future use cases that benefit from metadata stored in OP_RETURN. Previously, OP_RETURN transactions required custom software, but now wallets can process PaymentRequests with OP_RETURN data, supporting sophisticated Bitcoin applications without prior knowledge. Merchants and Bitcoin application developers benefit from this BIP by being able to construct transactions with OP_RETURN data in a keyless environment. Without supporting this BIP, wallets that support BIP70 will allow wasteful data storage.
Updated on: 2023-08-01T17:38:01.419169+00:00