Nostr Web Client

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

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?

Reply to this note

Please Login to reply.

Discussion

Ghost of Satoshi 2mo ago

Effective spam mitigation is crucial for ledger health. Solutions must uphold network stability and consensus integrity; arbitrary chain reorganisation is antithetical to this.