Published on: 2014-05-05T17:30:02+00:00
In a Bitcoin-development mailing list, Jeff Garzik clarified that the pushed-data size is limited to the standard format of OP_RETURN. He pointed out that the code does not implement the "standard format" and any opcode after OP_RETURN is accepted. The email thread discussed the standard format of OP_RETURN and was started by Peter Todd. Mark Friedenbach replied, stating that the email was correct but unintentional. Jeff Garzik's name and job title are mentioned in the email signature, along with his association with BitPay, Inc. The email also featured a sponsored message from SauceLabs promoting their Selenium testing platform.In an email conversation, Mark Friedenbach compared the complexity of the current implementation using template matching to an alternative method involving a conditional statement. The discussion focused on the scripting language used in Bitcoin transactions. Friedenbach questioned whether the current implementation is more complex than using a simple 'if' statement with an OP_RETURN condition. The email exchange includes technical terms such as 'script.vch[0]' and 'OP_RETURN', highlighting the importance of considering complexity in software development.Mark Friedenbach responded to Peter Todd's message regarding the "standard format" of OP_RETURN, noting that the code did not actually implement this standard format. Any opcode after OP_RETURN is accepted, such as "OP_RETURN OP_CHECKSIG".Flavien Charlon expressed confusion about a rejected Bitcoin transaction in an email conversation with Jeff Garzik. Flavien noted that the outputs were above dust and inputs were not spent, and the carried data was well below 40 bytes. Jeff Garzik explained that all of the carried data must be contained within one pushdata.Flavien Charlon questioned why a particular transaction was being rejected despite meeting the stated guidelines. The issue seemed to be with the inputs not being spent properly. Jeff Garzik responded explaining that the data needed to be contained within one pushdata to meet the required standards.The discussion revolves around a pull request aiming to minimize the impact on the blockchain. Mark Friedenbach doubts whether such a pull request would be accepted, as each extra txout adds 9 bytes minimum without benefiting from serializing the data together in a single OP_RETURN. The concern is not extra txouts but additional pushes, which may add complexity to the IsStandard rule. The writer questions why this matters if the application already defines the meaning of the data and argues against making hash commitment less uniform with the rest of the network.In an email conversation, Mark Friedenbach expresses doubts about accepting a pull request that would add additional transaction outputs to the blockchain. He argues that each extra transaction output adds nine bytes minimum without providing any benefit over serializing the data together in a single OP_RETURN. The issue at hand is additional pushes, and Friedenbach questions the purpose of making hash commitment less uniform with the rest of the network if the application already defines the meaning of the data.A pull request may not be accepted due to its potential impact on the blockchain. Each additional transaction output adds at least 9 bytes, with no benefit gained from serializing the data together in a single OP_RETURN. Peter Todd noted that the standard format should be a single OP_RETURN, but it appears that the pull request was accepted despite this deviation.Flavien Charlon asked the Bitcoin development mailing list for help regarding a rejected transaction by Bitcoind 0.9.1 on Mainnet. The decoded transaction showed lock_time, inputs (with one prev_out), vout_sz, vin_sz, and out. The script_string included "OP_RETURN 4f41010001 753d," which is supposed to be standard in 0.9.1. However, the data was split across two PUSHDATA's, causing the rejection. The issue remains unresolved.
Updated on: 2023-08-01T09:10:59.391097+00:00