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.

If OTS ever implements sign to contract, it could just be an ordinary 1in 1out payment, which would be less than a tx with a 40 byte opreturn.

GitHub

Add OpSignToContract with tag `0x09` by apoelstra · Pull Request #14 · opentimestamps/python-opentimestamps

Contribute to opentimestamps/python-opentimestamps development by creating an account on GitHub.

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).