Yes, it's a simple check for OP_FALSE OP_IF: https://github.com/bitcoinknots/bitcoin/blob/271fd206893a164b2d1c2d1c44c3696d23dd10e9/src/script/script.cpp#L357
Note: I found out after posting this that one pool has even lower fees than Ocean. But I don't think it tries to fairly distribute tx fees, so it's "effective" feerate may be higher.
SBI Crypto offers lower fees than Ocean. Their starting feerate is 1.5% and if you contribute more hashrate it falls lower -- to as low as 0.13%. https://sbicrypto.com/
Definition of Chain Spam
Chain spam is a tx on the blockchain containing data such as text, pics, audio, or video. A tx on the blockchain is not spam if, in as few bytes as possible, it does one of only two things, and nothing else: (1) transfers value on L1 or (2) sweeps funds from an HTLC or similar address created while trying to transfer value on an L2. The term "value" means the "value" field in L1 BTC utxos, and "transferring" it means reducing the amount in that field in the sender's utxos and increasing it in the recipient's utxos.
I don't want them to be eliminated. If they continue to lose marketshare, perhaps they will change course.
That's really cool! I wonder how they afford such low rates? https://wilsonmining.io/pages/pool
True! But keep in mind, all versions of Core since taproot was activated allow inscription spam, and the limit on inscription spam is just under 400kb. Knots, by contrast, has a limit of about 40 bytes on inscription spam. Something to consider.
It is neat to look at the reasons why Bitcoin Core sometimes loses users. Notably, outside of the Crowdstrike outage, we are in the midst of the largest ever downswing in Bitcoin Core usage.
Sources:
Ocean fees: https://ocean.xyz (see also attached screenshot)
Binance fees: https://binance.com/en/square/post/502257
Braiins fees: https://academy.braiins.com/ru/braiins-pool/rewards-and-payouts/
F2pool fees: https://blog.mexc.com/f2pool-mining/
Antpool fees: https://antpoolsupport-hc.zendesk.com/hc/en-us/articles/5983010227993-Miners-Settings-Fees
There are two reasons to consider switching to Ocean Mining. One is that you can help fight the spam there. Another is that you make more money.
> It turns node runners into network police
It doesn't turn them into "network police" because they aren't policing "the network" (other people's computers) but only their own. I run spam filters because I don't want spam in *my* mempool. If other people want it, great, their computer is *their* responsibility.
> constantly define and redefine what constitutes spam
It doesn't constantly need redefinition. Spam is a transaction on the blockchain containing data such as literature, pictures, audio, or video. A tx on the blockchain is not spam if, in as few bytes as possible, it does one of only two things, and nothing else: (1) transfers value on L1 or (2) sweeps funds from an HTLC created while trying to transfer value on an L2. By "value" I mean the "value" field in L1 BTC utxos, and by "transferring" it I mean reducing the amount in that field in the sender's utxos and increasing it in the recipient's utxos.
> Data-embedding techniques will simply evolve to bypass the latest filters
And filters will simply evolve to neutralize the latest bypass. They cannot withdraw this race if the filtered are more diligent than the spammers.
> [What if they] make their transactions technically indistinguishable from "normal" financial ones
Then we win, because data which is technically indecipherable cannot be used in a metaprotocol. The spammers lose if their software clients cannot automatically decipher the spam.
If the spammers develop some technique for embedding spam that can be automatically deciphered, we add that method to our filters, and now they cannot use that technique in the filtering mempools. If they make a two-stage technique where they have to publish a deciphering key, then they either have to publish that key on chain -- which allows us to detect and filter it -- or they have to publish it off-chain, which is precisely what we want: now their protocol requires an off-chain database, and all of their incentives call for using that database to store more and more data.
It is easy to fake the upswing in Knots nodes
But the downswing in Core nodes? That's hard to fake. You have to *convince* people to stop running it so that they stop showing up in the charts.
Looks like a lot of people are getting convinced!
New Core propaganda just dropped! They're learning to meme after all 
Thanks for clarifying. I understand that the fee estimation uses past block data and there is an ability to self-correct with RBF/CPFP.
If the concern is not about the initial estimate failing there is still a worse reaction time. If a node is blind to a large segment of the real mempool, wouldn't it be slower to detect a sudden spike in the fee market, potentially causing it to fall behind in a fee-bumping war?
On the other points we are also left with the problem that the network communication is breaking down because more nodes are rejecting the very transactions that miners are confirming in blocks.
Here is the problem visualized:
"In early June we were requesting less than 10kB per block were we needed to request something (about 40-50% of blocks) on average. Currently, we are requesting close to 800kB of transactions on average for 70% (30% of the blocks need no requests) of the blocks."
from this research thread: https://delvingbitcoin.org/t/stats-on-compact-block-reconstructions/1052/34
> If a node is blind to a large segment of the real mempool, wouldn't it be slower to detect a sudden spike in the fee market, potentially causing it to fall behind in a fee-bumping war?
A fee-bumping war? I think I need more context. I am not aware of any real-world software that requires users to competitively bump their fees. Are you saying there *is* such a protocol? Are you perhaps referring to the LN attack where the perp repeatedly RBF's an input to a tx that creates old state?
Even there, the would-be victim doesn't have to repeatedly RBF anything. Instead, he is expected to repeatedly modify his justice tx to use the txid of whatever transaction the perp creates after *he* (the perp) performs an RBF. The victim *does* have to set feerate each time, but his feerate does not compete with his opponent's, as his opponent is RBF'ing the input to the justice transaction's *parent,* whereas the victim simply sets the feerate of the justice transaction *itself,* and he is expected to simply set it to whatever the going rates are.
Moreover, as mentioned above, I think it's absurd to expect a real-world scenario where Knots reports a too-low feerate for 2016 blocks in a row, despite getting information about the current rates from each of those blocks *as well as* its mempool. For that to happen, spam transactions would have to be broadcast at a completely absurd, constantly-increasing rate, for 2016 blocks in a row, with bursts of *yet further* increased speed right after each block gets mined (otherwise the fee estimator would know the new rate because it shows up in the most recent block), and the mempool would *also* have to go practically unused by anything else (otherwise the fee estimator would know the new rate when it shows up in the non-spam transactions that compete for blockspace with the spam transactions).
> On the other points we are also left with the problem that the network communication is breaking down because more nodes are rejecting the very transactions that miners are confirming in blocks.
This communication problem can be summarized as, "compact blocks are delayed when users have to download more transactions." I think driving down that delay is a worthwhile goal, but Core's strategy to achieve that goal is, I think, worse than the disease: Core's users opt to relay spam transactions as if they were normal transactions, that way they don't have to download them when they show up in blocks. If you want to do that, have at it, but it looks to me like a huge number of former Core users are saying "This isn't worth it," and they are opting for software that simply doesn't do that. I expect this trend to continue.
> Less valid transactions in my mempool will make my node unreliable in predicting the next block and estimate fees, especially in extreme cases where it could be critical
I do not understand this criticism. Neither Knots nor Core looks *only* at the mempool to estimate fees. Partly as a result of this, the scenario where a wallet based on Knots would give a fee estimate that "wouldn't work" seems absurd: (1) the total weight of spam transactions in the mempool would have to *suddenly* increase (2) without a corresponding, similar increase in competition from "normal" (non-spammy) transactions (3) to a point where the non-spammy transactions only show fees at level X (4) but the real feerate is actually at level Y (5) and Y is so much larger than X that X won't work. But even that's not enough, for the following reason:
As an example of a wallet with a critical need to get a transaction confirmed in a certain time frame, consider a lightning node. These have to be prepared to use RBF or CPFP to bump their transactions if a justice transaction is called for, because they must "go through" in a certain time frame. (E.g. see here: https://docs.lightning.engineering/lightning-network-tools/lnd/sweeper). Since Knots and Core both look at "recent blocks" to figure out what the current feerates are, and not just the mempool, this means the above scenario -- with the sudden increase in spam fees with several other conditions attached -- will only cause the wallet to fail to get its transaction confirmed if the scenario *repeats* as each subsequent block comes out, such that the additional fee information provided by block K+1 is already out of date when Knots tries to estimate fees again at the prompting of whatever wallet wants to use RBF or CPFP to get its transaction confirmed.
Given the absurdity of such a situation playing out in the real world, it seems equally absurd to use this as a legitimate criticism of Knots. Even in critical applications, your fee estimator does not need a *precisely accurate* mempool. If bitcoin required that, it would be a broken system, because the mempool is intentionally not consensus critical.
social signaling is good for a sense of community among bitcoiners but I don't think it has merits in a purely technical sense
if you shift 1 bit, we add that to the filter
if you xor by some value, we add it to the filter
it's not possible to stop filters
I think there is a way to fix it without breaking real p2tr scripts. Create a filter that checks if a control block, when parsed as a single hexadecimal string, contains a valid image format. If so, filter that transaction. Done.
If it is useless, why are you quoting it as evidence?
