So, OP_RETURN is fine, as is annex data which don't increase validation burden? And cutting off OP_RETURN and driving those uses to fake pubkeys, which does increase future validation costs, is a threat?
Login to reply
Replies (8)
OP_RETURN and taproot annex both expand the data burden on future nodes so I'm not really sure what you're talking about. (A pruned node can't be used for an IBD.)
Fake pubkey outputs are still pubkey length and therefore not any harder on validation than a normal transaction. They are also a pro rata donation to the rest of us because they will never be spent. Also you are not " driving those uses to fake pubkeys." I'm not driving the thieves to my neighbor's house by locking my own doors.
Steganography is not the issue here. If it looks like a normal transaction, the whys and wherefores are not up for debate.
You only have to download and hash: you don't have to check extra signatures (our most expensive operation) or put them in the UTXO set (our most constrained memory resource).
Initial block download you check:
Block-
Syntax, PoW, timestamp, blocksize, and
Txn-
Syntax, signatures, inputs, and outputs
So, I am not sure what you mean by "download and hash"
To check the signature, you hash the transaction. So the only cost that OP_RETURN is doing is the cost to download and hash it.
If it's data in the annex you don't even need fi hash it, just download it.
I feel like we have gotten off on the wrong exit. OP_RETURN is a testing code that should have never been made standard in 2014. The sole problem of OP_RETURN and Annex are data storage burden. I admit with Moore's Law, it is likely not a storage issue. My contention is that processing, bandwidth and RAM do not adhere to Moore's.
Both OP_RETURN and Annex increase the bandwidth necessary for expedient download. Especially with future low end hardware.
To be clear, I find BIP 110 wanting.
- My approach would be to modularize the reference code into about 5-6 manageable chunks instead of the monolithic codebase it is today. With node policy, consensus, the Bitcoin spec, and peer logic, so on as separate modules independent but adhering to the same spec.
- Remove OP_RETURN standardness
- Remove the witness discount
- Review the BIP 341 OP_codes
With that, spam would simply pay for their data usage and ACTUALLY compete on level ground with simple transactions. (Instead of at a 1/4 weight discount)
You don't understand. There are no rulers. You cannot prevent people doing stupid things. This is fundamental, and hardest to emotionally grasp.
You can, however, use existing incentives to minimize the damage to the system. That's why OP_RETURN is standard: people used to embed data in outputs, which have to be stored forever and be available for fast lookup. OP_RETURN is straight harm prevention. Luke used the coinbase input to embed prayers, which has the same effect, but you have to be a miner.
The only strong incentive is fees. That's unvarnished capitalism, which has the benefit of being *simple* and *distributed*, but it's not *fair*. Assholes with more money than me are a real problem! But not one we know how to solve in a decentralized system.
I do understand that. If there is one thing an anarchist understands is that. I just don't see output embedded data (steganographic) as the problem everyone else seems to. I think the upper limit of 2.1 quadrillion UTXOs should have been accounted for. If not, that's just bad accounting. What you cannot account for os the data whims of a system that allows data pushes with every transaction.
I believe the market sorts out resources most efficiently but an arbitrary weighting discount for witness data is a thumb on that scale.
You need to hash the annex to calculate the wtxid, which goes into the witness merkle root in the coinbase, which you check when validating a block though. You also hash it as part of taproot witness signature valuation, which is different from other witness data (eg inscriptions).