Replying to ihsotas

If it’s cheaper to other methods for some types of spam op return size is irrelevant.

If some types of spam is going to pollute the utxo set if it can’t use op return because of its size it is preferable to increase the op_return size than to encourage utxo bloat.
Avatar
BitcoinIsFuture 2mo ago

That is why there is this soft fork bip that fixes a lot of weaknesses that are exploited from spammers 🤙

New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid.

OP_PUSHDATA* with payloads larger than 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs.

Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141 nor Taproot/BIP 341) is invalid.

Witness stacks with a Taproot annex are invalid.

Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid.

Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid.

Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid.

https://github.com/bitcoin/bips/pull/2017/files?short_path=e677ced#diff-e677ced2127c111bef00d95fd3bbd4a2850f4ba951df4e53a34a17de900de3a3

Reply to this note

Please Login to reply.

Discussion

f7
ihsotas 2mo ago

It doesn’t fix all spam vectors so all this means is more transactions and more utxo pollution. To fix all spam vectors you will have to destroy any hope of bitcoin scaling and multisig….and even then spam will find a way.

The reactive activation chaotic chain reorg portion is the most retarded thing I have read in a bip. Anyone supporting this will be outed as a glowie or a useful idiot. Which one are you?