At this point BIP444 proponents are either:
A) Nefarious
B) Bots
C) Willfully ignorant
D) Just plain ignorant
There is no longer a reason to engage with them any longer.
Joining team filter has been a massive engagement boon for D level #Bitcoin influencers.
nostr:nprofile1qqsx8lnrrrw9skpulctgzruxm5y7rzlaw64tcf9qpqww9pt0xvzsfmgppemhxue69uhkummn9ekx7mp0qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qg4waehxw309aex2mrp0yhxgctdw4eju6t09u47mdqx - I'm seeing this error when trying to zap with snort.social:
webln.enable() failed (rejecting further window.webln calls until the next reload)
This used to be a problem with btcpay:
https://github.com/v0l/snort/issues/332
Has something broken with Snort and btcpay?
Got the payment. I will check on my zap receiving. I just updated Core Lightning so maybe something broke.
lnbc2u1p50vgxcsp5kh5glh8x7gmwwdqeeh9pdy4y3ex6xhkf6utsc6ahddykuwyfqf7qpp5r25s70kg94k68agp024r9dg20h69cyuy3yk5q5jemrxmyrx7s87qdqqcqpjrzjq0cmvy4crt7ppussv3sfq24xu8rj4wkwsthgl2aprfly06emtneevrdmsvqqy8qqqyqqqqlgqqqqzzsqvs9qxpqysgqgmafstwt4f2qjg84raywazd0qxz2tjw72wuutc4u5hwzkeax272syhgypt5tpzk3rgt97tdza59yadm3tummkr4pg475827l6mhtmggp3uyhyd
I sent 100 sats to you LN Address and 100 sat zap to this post which hasn't shown up as a zap. Both payments were successful.
They said during the postgame that the Dodgers pay more in luxury tax than the #Brewers entire salary!
The Cubs are very good defensively. I think more of those line drives will drop for hits against the Dodgers.
The Miz settled down and ate some innings going through the heart of the order a couple times. That was huge.
The #Brewers were able to play enough "homer ball" to get the win. Exciting game!
There are a lot of Kaspa reply guys on X. I wonder if they are gone for good now.
#Bitcoin Core 30 is malware!
I started it up and my CPU usage jumped!
Knots node runners were right!
If he can get through his first inning he should be okay.
It's got to be difficult as a hitter to stand in there when the guy throws 104 mph and there is a very real possiblility that he is going to let one loose that is coming right at your head!
I believe that somehow or another it will come down to The Miz. He is either going to be the reason they win or the reason they lose.
PSA for Core 30 node runners. If you have coinstatsindex enabled (not default) a re-indexing will occur upon first startup which will cause a notable increase in CPU and disk activity until the re-indexing is complete.
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:
You should understand that while you may not be relaying these transactions, running Knots does litterally nothing to stop them from being mined and they will ultimatly end up on your node anyway:
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 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.
I believe this push to divide was born in the aftermath of the Occupy Wall Street movement. It has been highly effective. I wonder how the perpetrators that inorganically caused this division feel now seeing the effects. They probably feel fine because their interests were protected and the are complete sociopaths.
Tucker is 100% controlled opposition.
I loath that site. True freedom is being able to delete my profile. I'm not there yet unfortunately.
Thank you nostr:nprofile1qqsg6r2jrh0f9j925yxryahu2aswmfm9gw853pdhp5yk5j0ed93gljsppemhxue69uhkummn9ekx7mp0syw7uq!
That is fair and he is providing noncontroversial educational content that should not be banned. I suspect someone within YouTube with a #Bitcoin axe to grind is pushing the ban button. Thankfully nostr:nprofile1qqspnzgrfett3asxcuj0gksje6z2zxzpvgd27uvz58m9vsuqh8zzw6cpr9mhxw309a382emdv9hzumt8w4ujumn9wsargwp58qq3vamnwvaz7tmzv46xztnwdaehgunfdshxxctdqydhwumn8ghj7en9v4j8xtnwdaehgu3wvfskuep0w3hku7gpewmsc has a large enough social media following to get the ban reversed.