Bitcoin Core will be used as a mule for free, unstoppable CP/CSAM by sickos or state actors, in order to attack Bitcoin and prosecute those who knowingly allow it.

This is the attack...

Once op_return is removed, plain JPEG images (not part of multiple fragments inside scripts that need to be pieced together and decoded, but plain JPEG/GIF/MP4) will be sent through your Bitcoin HardCore node version 30+, from one paedophile to others, possibly sold (Knots runners won't touch them, ever). Your Core node will happily pass it along, providing anonymity to the criminals (or state attackers, or Epstein's old clients).

They will pay a well below market rate initially (eventually zero), and never even need to get the transaction mined - key point. The original filter that Satoshi introduced, FEES, will be effectively bypassed...

After some time, these low-fee CP/CSAM txs will be dropped by Bitcoin Core nodes, but if they don't, the sicko(s) can do an RBF of the transaction (or if they have chained them, an RBF of a single low-fee unconfirmed parent), to cancel and invalidate the transaction so they don't have to actually pay for any of the downstream higher fee large transactions.

They will have successfully used your computer to transfer and potentially sell horrible images, without paying (so forget "filters don't work, they'll get on chain anyway"), thanks you being complicit, and thanks to all the Core devs who allowed this in. And those gaslighting against us saying this is wrong.

Then public opinion will turn heavily against Bitcoiners, if it isn't bad enough now. We already know it's going to get worse as most miss out.

@adam3us has pointed out, incorrectly (I'll explain), that this attack can't work, because of some "package relay". Sounds like this is a filter to stop RBFs of a parent if there is a long chain of transactions dependent on it.

A clever idea, but it can't work, Adam. Do you know why? Because your resistance itself is a form of FILTER, and FILTERS DON'T WORK, remember? You can not use an argument against us if that same argument is used to defend yourself.

An attacker can get their cancelling RBF transaction mined by going directly to a miner. Then the scumbags get away with using your Bictoin Core node for CP/CSAM transmission - it's irrelevant whether it gets on a block or not, it doesn't need to, the paying paedophile got his images.

Ironically, filters not working is the very reason we need filters.

There are 3 solutions.

1) Bitcoin Core reverses this STUPID rushed decision, introducing completely unnecessary risk to Bitcoin.

2) We all run Knots, and it becomes the reference client.

3) We move away from Core to Knots, and maybe others will pop up, and there is no reference client, meaning fewer meaningful changes to Bitcoin become likely.

Bitcoin doesn't need changes; it needs general light maintenance, so just maintain it, don't change it!

x.com/adam3us/status…

Honest question, as I understand it OP_RETURN isn't being removed, the OP_RETURN size limit is being removed (is that true?). If so, wasn't OP_RETURN was specifically designed to be easily pruneable? So why wouldn't people just choose to prune OP_RETURNs from their nodes? Then they wouldn't be "hosting" anything that may get in from this change, right?

nostr:nevent1qqsdujhk59km4uy0k9tgkmpt8g7hm94jfsznnjdjtk9y4ty5xhpcreqzyradv4qv3uha9gt2yhgdstwet5a667ys6s6az6ggfzs2wlfgswjywqcyqqqqqqgprv8k0

Reply to this note

Please Login to reply.

Discussion

its not the only place to store it, its not even the most economical place to store it

Right, so why would removing the limit matter so much?

It doesn’t, its all lies by knots people to stir up drama.

The only point I agree with them on so far is that I like keeping things configurable for the people who care, even if they change the default. For the record, I run Core and Knots, but I configured my Knots instance to basically allow anything through 😂

In order to validate the block, any node needs to compute the hash of the block and that means you need to download the whole block and compute the hash

That can't be avoided by any node that wishes to validate blocks

After validating a block, you're right that the OP_RETURNs don't need to be stored any more, and you could therefore delete or overwrite that particular data

But, if you want to keep the whole transaction history, in order to be able to see everything, then your options are limited. I guess you can write node software which, after validating the block, will overwrite or delete some data (e.g. OP_RETURNs) that you don't want to keep around

But the more you delete, the more difficult it is to call yourself a full node. For example, you can't help other nodes to join the network

So if I prune unspendable UTXOs I can't help other nodes to join the network? Do you mean during the initial block download?

Correct you'll only be able to send new nodes doing their IBD the complete blocks you have on your node.

Makes sense. I hadn't thought of that.

It isn't about storing/pruning unlimited op_returns, it's about relaying that data through the mempool.

Knots:

If I don't want to relay large op_returns I shouldn't have to.

Core:

Relay everything consensus valid