op_return-notes.md

Remove OP_RETURN limit:

• Pros

  • Citrea's current construction of 1 OP_RETURN and 2 unspendable Taproots is bad, single large OP_RETURN or multiple OP_RETURNs would be better
  • "the restrictions on the usage of OP_RETURN outputs encourage harmful practices while being ineffective in deterring unwanted usage"
  • Payloads >= 135 bytes are more efficent to do the inscriptions thing
    • Or maybe it's 155 bytes
  • "they could always be easily bypassed in more or less harmful ways with only a small loss of data encoding efficiency (the most harmful being adding many unspendable outputs to a transaction, which some protocols do even today)."
  • "While multiple OP_Return outputs are more expensive than a single one for the same amount of total data. In some cases they're necessary for technical reasons, e.g. if signing with SIGHASH_SINGLE. "
  • "they were not useful in general, because they rely too heavily on having standardness rules go against financial incentives"
  • Harm reduction
    • Avoids UTXO set bloating with fake pubkeys
    • makes compact block relay fail less often
      • Reconstruction time with tx fetch is ~10x of no fetching
    • less incentive for mining centralization
      • "Part of the puzzle to make that permissionlessness of mining work is access to fee-paying transactions from the public"
  • 'these arguments do not apply to OP_RETURN limits, which don't serve an objective harm reduction beyond a subjective "that isn't what you should be using the chain for". "
  • "Next, I think it's obvious that an attacker seeking to harm bitcoin users would choose an any image format he likes. So for this example I'm picking BMP. If you encode the image above to BMP, which is uncompressed, the red pixels turn into bytes 253, 7, 2 which happen to encode witness element length 519"
  • "Encoding data into random protocols is a standard exercise, and doing so in ways that are undetectable to third parties is also standard, "
  • "If they use OP_RETURN instead of putting data into the witness, they will exhaust their funds four times faster and store four times less data on the blockchain."
  • "Delays in block propagation can have a disproportionate effect on mining centralization because they cause larger miners to have improved profitability over smaller ones. This happens regardless of which party was on which side of the delay,"
  • "more restrictive relay policy makes fee estimation less accurate/complete"

• Cons

  • "we could have reserved multi-output as some sort of signaling mechanism since it's previously not relayable on Bitcoin Core, even with knob fiddling, though I can't imagine what that would be"
  • Bitcoin will die
  • "miners using the fixed and improved spam filters have in fact earned significantly more than miners using Core. " (Dubious, doesn't actually follow logical sense)
  • "There's little to no incentive to use OP_RETURN for data storage when using the 'inscriptions' exploit costs 4x less in transactions."
  • "the inscriptions exploit currently requires chunking the data between PUSH opcodes, meaning an on-disk analysis doesn't actually directly reveal the underlying data the injector intended."
  • "Everyone running a node will now be guaranteed to "posses and distribute" content that is likely illegal in their jurisdiction. Not only are you storing this as a full node runner, you're serving it to others."
  • "let's say I want to distribute malware. Well, might as well just store it in an OP_RETURN. Then, any time I compromise a system with a Bitcoin node I know my malware is directly on their system in a mostly predetermined spot already"
  • "At that point, funding for altcoin Ponzis built on bitcoin would have shriveled up or moved to other chains, just as it did in 2014."

Imposing stricter filters:

• Requiring pubkeys to be spendable (sjors)
  • a lot more data on chain with a signature requirement on outputs
  • key grinding to shove data a couple bits at a time in a pubkey