Author: Troy Benjegerdes 2014-03-23 22:37:52
Published on: 2014-03-23T22:37:52+00:00
On March 22, 2014, a discussion took place on the bitcoin-dev mailing list regarding proof-of-publication and the OP_RETURN length. A security flaw was found in that OP_CHECKMULTISIG sigops weren't taken into account, making it possible to broadcast unminable transactions and bloat mempools. Peter Todd suggested ditching bare OP_CHECKMULTISIG outputs as they were hard to do fee calculations for and could potentially bloat the UTXO set. Counterparty was the only entity currently using them. Troy Benjegerdes proposed adding an explicit 'data' field with something like 169 bytes to each transaction if unused, which would provide a small, but usable data field for proof of publication. He believed this would prove to be a much more reliable infrastructure for proof of publication than various hacks to overcome 40 byte limits with Bitcoin. Peter Todd replied by disclosing that he was working on tree chains, which just improve the scalability of blockchains directly. Soft-fork tree chains with reasonable data/memo/annotation storage would be extremely interesting. The important question, however, is how does one build a business around such a thing, including getting paid as a developer. Discussions about how to motivate the people who own the hashrate and bulk of the coins to pay developers were deemed relevant to the bitcoin-dev list. It was suggested that it was good marketing for Bitcoin developers to remind the people who profit from their efforts they need to make it profitable for developers to work on Bitcoin. Otherwise, innovative developers might choose to premine and release a new coin-blockchain instead of working on the Bitcoin-blockchain, leading to disruption by venture capitalists.
Updated on: 2023-06-08T15:34:26.262579+00:00