BitcoinLizard

Yeah, this is from years ago. Ethereum is irrelevant now.

But I think the people he said it to really had it coming! Especially @Luke Dashjr and @Bitcoin Mechanic. 🖕those guys!

And now you are the lead for the best #Bitcoin Lightning implementation. I'm grateful for your efforts!

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.

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.

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.

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-…

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.

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 @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.

They posted to the RSS feed a couple weeks ago but have barely been posting lately. I assume they have something else going on now and can't keep up with what I assume is a significant time commitment.

What I really need is a dumb pipe of #Bitcoin news and related news like what @No Bullshit Bitcoin was. I feel like social media has gone the way of cable news, drama for drama's sake requiring major time and effort to get anything of substance.

I would try your social media but A) I suspect that due to minimal network effect there is no one there I'd be interested in following. B) Since I logged out of X six months ago and am only sporadically on #Nostr I realize my life is better. What I really need is a dumb pipe of #Bitcoin news and related news like what @No Bullshit Bitcoin was. I feel like social media has gone the way of cable news, drama for drama's sake requiring major time and effort to get anything of substance.