Nostr Web Client

This 2679 byte op_return containing a png file was confirmed on chain. I broadcast it using Core version 29.1 to the regular Bitcoin relay network (no out of band service needed). Core 30 makes no difference in the ability of a "spammer" to confirm transactions with large op_returns.

Here is the TXID: 0d5f273d09c1a4665634fd25d5a17b879d8843de5edc40b8b7d8671500dd16b6

It took a little while to be mined, I must have gained a new peer that would relay it to a miner. I broadcast it block height 916259 and it was confirmed at 619343.

I paid less than 1 Sat/vB. Knots users didn't have this transaction in their mempool but now they store it on their node. Filters won't keep these transactions off your node. Filters do not work.

You can view it for yourself with this command (Thank you nostr:nprofile1qqsdnpcgf3yrjz3fpawj5drq8tny74gn0kd54l7wmrqw4cpsav3z5fgpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3jamnwvaz7tmjv4kxz7fwwdhx7un59eek7cmfv9kz74rw7n6):

bitcoin-cli getrawtransaction 0d5f273d09c1a4665634fd25d5a17b879d8843de5edc40b8b7d8671500dd16b6 true | jq -r '.vout[0].scriptPubKey.asm' | cut -d ' ' -f2 | xxd -r -ps | base64 -d > filters.png

Here are my node settings that allowed me to send this transaction and get it relayed (and mined):

minrelaytxfee=0.00000100

mempoolminfee=0.00000100

incrementalrelayfee=0.00000100

datacarriersize=100000

If you are running Knots because you believe it will prevent "spam", you are being fooled by Mechanic. The only way to keep this type of transaction off your node it to fork #Bitcoin consensus rules.

Wizdumb 3mo ago

Mempool node policy is extremely important for private node runners as good mempool hygiene (filters) reduces the transactional burden on the node, and by extension the #bitcoin network.

Nodes are to remain simple with very low overhead in order to assure that there are more numerous voluntary node operators world wide. Keeping the network decentralized.

Filters do work at the node level, your little bullshit transaction ended up in the time chain, sure. But nodes with good policy didn’t have to relay it to each other, thus increasing the burden to operate them.

Additionally, the more spam like this that ends up needing storage on the time chain, the more memory will be required over time, increasing the burden on nodes even more. When individuals stop running nodes because of this and it’s left to the big cloud and server farms, #bitcoin losses. Why tf can’t people see this shit, it’s baffling.

Reply to this note

Please Login to reply.

Discussion

BitcoinLizard 3mo ago

You are wrong about so much here. You end up downloading the transactions twice. Potentially many transactions will need to be downloaded and validated a second time when a block is found which puts you at a disadvantage if you are mining with Datum. You are in no way reducing resource requirements by running Knots.

More transactions using op_return is likely to actually reduce the UTXO set and disk storage requirements. See here if you are interested:

https://bitcoin.stackexchange.com/questions/127912/if-op-return-uncapping-doesn-t-increase-the-utxo-set-how-does-it-still-contribu