Default avatar
npub1k6f0...tryn 2 months ago
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. image 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 @Rijndael): 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.

Replies (10)

Default avatar
npub1k6f0...tryn 2 months ago
The point is Core 29.1 (and older) can already be configured to relay transactions with op_return larger than 80 bytes and there are nodes on the network that will get them relayed to miners that will mine them. Slipsteam or another out of band service isn't required. Core version 30 doesn't really change anything except that there will be many more nodes relaying these transactions but it is already happening today.
Wizdumb's avatar
Wizdumb 2 months 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.
1 replies ↓
scottie's avatar
scottie scottie@rizful.com 2 months ago
I think you are confused as to the purpose of the filters. You said yourself that knots runners didn’t have this transaction in their mempool, so sounds like the filter worked. You just got a node that had a higher limit filter or no filter to put it in a mempool.
1 replies ↓
Default avatar
npub1k6f0...tryn 2 months 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:
Bitcoin Stack Exchange
If OP_RETURN uncapping doesn’t increase the UTXO set, how does it still contribute to blockchain bloat and centralization pressure?
OP_RETURN outputs are provably unspendable, so they don’t add to the UTXO set. This is sometimes used to argue that uncapping OP_RETURN is &...
Default avatar
npub1k6f0...tryn 2 months ago
And you potentially downloaded and validated the transaction twice if it happened to be relayed to you. Sounds like an ineffective filter. I guess Luke could build in the option to only peer with other Knots nodes but some Knots nodes would still have to peer with Core nodes.
1 replies ↓
Default avatar
npub1k6f0...tryn 2 months ago
If my node happened to relay a transaction with a large OP_RETURN to your node, you would download the transaction from me, validate the transaction, and then determine that it violated your mempool policy and drop the transaction. Your node wouldn't relay the transaction to any other nodes. Then if the transaction were to be mined into a block (because it is consensus valid) your node would download and validate the transaction a second time. If you happened to be peered with several #Bitcoin Core 30 nodes it is possible that multiple nodes would relay the transaction to you. I'm not sure if the Bitcoin software has an efficient mechanism in place to drop a transaction it has previously seen and determined to violate the mempool policy or if it will repeat step 1 again of downloading, validating, and dropping. If you were peers with mostly Knots nodes you would likely not see the transaction at all until it ended up in a block. To answer your main question, my transaction with a large OP_RETURN would never be in your mempool.
Default avatar
npub1k6f0...tryn 2 months ago
Every node runner should decide the correct OP_RETURN size for their node. I have configured my node with datacarriersize=100000 because I want to get the most complete picture of the mempool possible so that when I create a transaction my fee estimation is as accurate as possible. I would argue that datacarriersize=0 is a poor choice because it breaks Lightning and Samourai Whirlpool but that is a choice for every node runner to make.
↑