What's the essence of running knot if all nodes must accept valid blocks

[Ambatman]

I really didn't want to create another topic on this debate since I believe we already have too much.
But I believe this would bring quicker response to my question.


I'm quite confused about something, I'm aware from the current update core nodes would allow larger OP_RETURN transactions while knot is enforcing stricter limit.
And that mempool policy is different from consensus rules. And every node still has to accept valid blocks no matter what's inside.

1. If all nodes must accept valid blocks, what difference does running knots make except rejecting OP_RETURN larger than the previous limit in the mempool?

2. Is this why luke wanted  a fork? Because only through changing consensus rule can they really prevent 'spam'.

Before responding to my first question, I'm aware that nodes have to broadcast the transaction
But at the end of the day miners decides which transactions are included in blocks
And profit wise, I doubt miners would choose knot well keeping CSAM constant.



Mod can combine it with existing thread if they believe is better. Thank you.  

[stwenhao]

If all nodes must accept valid blocks, what difference does running knots make except rejecting OP_RETURN larger than the previous limit in the mempool?

It makes your node a little slower than usual. Because first, you reject some transaction when it is relayed, and later, you have to download and verify it again, even though you had a chance to do that earlier. Which means, that nodes, which accept more things on relay mode, are just faster.

Also note, that there is a difference between relay policy, and block template inclusion policy. You can accept free transactions, but it doesn't mean, that you have to include them in your mined blocks. Which allows making some optimizations on relay level, where you can have less restrictive relay, to allow P2P batching, and including only final transaction version in a mined block.

One example of that "less restrictive relay" is where you have signet faucet, which constantly uses full-RBF, to replace the transaction over and over again, until the final version, with the highest fees, is included.

Is this why luke wanted  a fork?

It doesn't matter, because using hard-fork to solve a problem, which can be solved without any forks, is stupid. If Knots' supporters would want to discard some transactions, then they would do just that: by sending "I don't have it" P2P message, when asked about given transaction ID, or block hash. And then, to make an actual improvement, they could create a new P2P message, to provide ZK proofs, or other kind of improvements, in a separate P2P messages, to make Initial Blockchain Download trustless, and possible, without getting all spammy transactions in plaintext.

Also, if nodes would stop sending transactions in plaintext, then it would really solve the spamming problem, by forcing users to store their own transactions. Because now, spammers simply abuse the fact, that node operators can do it for them. But there is no consensus rule, which would force anyone, to store everything forever. The only thing, which is needed, is to make sure, that the chain is valid. Otherwise, chains like Monero wouldn't exist.

[Cookdata]

1. If all nodes must accept valid blocks, what difference does running knots make except rejecting OP_RETURN larger than the previous limit in the mempool?

Bitcoin knot doesn't reject only OP_RETURN transactions, they do also filter transactions that are suspicious to have fake pubkeys, inscription like ordinals that are embedded on witness field, they don't relay such type of transaction. While this may looks like it's their fight alone, but it's not, the fake pubkeys in particular is bloating the UTXO set, and hence why the need for OP_RETURN limit increase.
 

2. Is this why luke wanted  a fork? Because only through changing consensus rule can they really prevent 'spam'.

I respect whatever he smoke with the boldness of trying to fork Bitcoin, anytime I see Knot supporters trying to convince others to run knot, they sound like kids who are been fed with what to say than what they actually want to do. They see it like competition than what knot can actually achieve.

The version 30 is out and I'm yet to see any reported anomalies like maybe some people will want to prove us wrong about the upgrade but I don't have the version yet, still active and running v28. I'm already tired of this debate.

Before responding to my first question, I'm aware that nodes have to broadcast the transaction
But at the end of the day miners decides which transactions are included in blocks
And profit wise, I doubt miners would choose knot well keeping CSAM constant.

If it get to a stage where the network becomes a place to spam CSAM, I'm very confident this OP limit will be reverse. Not the first time it was increase and later decrease. It's one thing to make money and it's another to look at decency of the network.

However, I have the feelings that there someone somewhere with a plan that want to prove us wrong that this step is wrong, if I see CSAM embedded on the network tomorrow I wouldn't be surprised.

[Mia Chloe]

~snip

Actually, running Bitcoin Knots mainly affects mempool policy and not really consensus which meas it filters which unconfirmed transactions your node relays (for example, rejecting large OP_RETURN data) but it must still accept any valid block once mined. Which basically makes Knots a form of soft resistance that slows or discourages certain transactions without splitting the network in reality.
However, since miners ultimately decide what goes into blocks based on fees, and because consensus rules still permit large OP_RETURN outputs  only a consensus level change (which is basically a fork) could actually prevent such transactions from being valid on chain.

[PostQuantumBTC]

1. If all nodes must accept valid blocks, what difference does running knots make except rejecting OP_RETURN larger than the previous limit in the mempool?

2. Is this why luke wanted  a fork? Because only through changing consensus rule can they really prevent 'spam'.

Before responding to my first question, I'm aware that nodes have to broadcast the transaction
But at the end of the day miners decides which transactions are included in blocks
And profit wise, I doubt miners would choose knot well keeping CSAM constant.

Luke Dashjr is the only one that is behind Bitcoin Knot, that is an enough reason people should avoid it, unlike Bitcoin Core that has many developers.

There is no much difference than wanting to make the bitcoin network to become centralized.

He can not win because Bitcoin Core favours miners. Miners will go for what that favour them.

[ABCbits]

1. If all nodes must accept valid blocks, what difference does running knots make except rejecting OP_RETURN larger than the previous limit in the mempool?

On theory, it can prevent TX (that deemed as spam) from reaching miner/mining pool node if most nodes run Knots. It's just like how people unable to relay TX with fee lower than 1 sat/vB in past. Although people could use miner/mining pool service to include their valid TX directly.

2. Is this why luke wanted  a fork? Because only through changing consensus rule can they really prevent 'spam'.

If you mean plan of hard fork leaked, it doesn't fully prevent on protocol level. If i understand it correctly, other part of the TX and ZKP data still exist on the block.

By Dashjr’s description, the trusted multisig committee would review transactions and replace any data it identifies as CSAM with a zero-knowledge proof. Node operators could then remove said data from their nodes – altering their version of the blockchain – while continuing to be able to prove that the transaction that contained the affected data is valid.

But FYI Luke have deny such accusation, see https://www.coindesk.com/tech/2025/09/27/luke-dashjr-denies-hard-fork-claims-as-bitcoin-governance-debate-heats-up,

He can not win because Bitcoin Core favours miners. Miners will go for what that favour them.

Miner/mining pool doesn't exactly favor Bitcoin Core either. Some mining pool known to include non-standard TX on their block due to various reason.

[d5000]

1. If all nodes must accept valid blocks, what difference does running knots make except rejecting OP_RETURN larger than the previous limit in the mempool?

My take on it is that it is basically similar to the UASF he published in 2017. Technically, it doesn't make much of a difference, even if 50% of all nodes were Knots, the rest would be more than okay to relay your OP_RETURN >80byte NFT masterpieces.

But if Knots sustained the growth it had in the last months, then they could have hoped to pressure Core to revert the limit, or at least to not deprecate datacarriersize, i.e. the possibility of node owners to limit the size of data in OP_RETURN outputs. That could also have been a sign to miners to join the Ocean pool for example, although this is more difficult because miners are much more dependant on revenue and thus would not lose coins just to "be on the good guys' side".

Now Knots growth has been stagnant somewhat at 5000 nodes and around 21-22% of open reachable nodes since September, even around the 30.0 release date. It's too early to draw conclusions, but it is likely that their strategy won't have a lasting effect.

Nevertheless it will be interesting how things develop in the next few weeks. Bitnodes does still not show the proportion of Bitcoin 30 user agents, so it's likely it's still in the "Other" category, which is growing about 0.5 percentage points per day (which is probably the BTC 30 growth).

2. Is this why luke wanted  a fork? Because only through changing consensus rule can they really prevent 'spam'.

They can't even prevent spam with a consensus change, because if the spammers use fake public keys, they could integrate a check to ensure the keys are "valid" (even if they are fake). This would be a bit more difficult computation wise but in the end I don't think they would lose much data capacity.

There are "harder" consensus-based filters which could be discussed, such as requiring signatures in outputs, which would however increase data consumption per transaction and spamming would still be possible, although with more overhead.

The most extreme measure would be a change to a protocol like Grin's. That would be effective but basically would close the door to Lightning Network and other L2 techniques.

[Ambatman]

If Knots' supporters would want to discard some transactions, then they would do just that: by sending "I don't have it" P2P message, when asked about given transaction ID, or block hash.

This would really hold true and easily executed if knots holds majority of running nodes
But according to coindance they currently at 21% and I believe majority of nodes running core should be from previous update likely 29.

The most extreme measure would be a change to a protocol like Grin's

And make the created coin more like monero. It wouldn't survive. The trade off isn't worth it.

Now Knots growth has been stagnant somewhat at 5000 nodes and around 21-22% of open reachable nodes since September, even around the 30.0 release date.

I think what they need is an exploit of the new no limit on OP return from core 30
And this would be harder to implement
Since I'm sure that nodes running core 30 are lower than knots.
So currently majority still have a relay limit.

then they could have hoped to pressure Core to revert the limit, or at least to not deprecate datacarriersize

From what I read the datacarriersize wasn't deprecated and can be adjusted.

-datacarriersize is increased to 100,000 by default, which effectively uncaps
the limit (as the maximum transaction size limit will be hit first). It can be
overridden with -datacarriersize=83 to revert to the limit enforced in previous
versions.

[stwenhao]

This would really hold true and easily executed if knots holds majority of running nodes

But why would you need majority of running nodes? Some nodes can have all transactions, other nodes can have only some transactions, and you can also find nodes, that share no transactions at all, and no historical blocks, beyond 288 last blocks, or something like that.

If you connect to a node, and it is pruned, then you can ask that node about block 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 or transaction 0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098, and that node can say "I don't have it". The only needed thing, would be to enable pruning, and prune the first block after Genesis.

So, even if you run Bitcoin Core, any node, at any time, can always send you "I don't have it" P2P message, when asked about any block or transaction. Because no consensus rule forces anyone to store everything. Otherwise, pruning would be impossible, and everyone would store the full chain.

And now, if you know, that nodes can lack some blocks or transactions, and still exist in the same network, then you should also notice, that it is possible to use exactly the same method for more things, than just pruning. In exactly the same way, any transaction can be "censored". If Knots' supporters would want to "hide" any transaction, or make its propagation worse, then this is the direction they would choose.

The main problem with Knots is not that they want to filter their own transactions (because as you saw, they can, and anyone can, even when running Core). The problem is that they want to filter it globally. And that is something different.

Also, if someone thinks, that "spam is bad", then that person should think about doing Initial Blockchain Download in a way, where sharing the transaction in plaintext is not needed. Because that would be much more effective in practice, than playing cat-and-mouse games, and losing it, when seeing, that one, single mining pool, with 0.05% global hashrate, can confirm any unwanted transactions once per two weeks, and bypass all of these filters, enforced by 99.95% majority (as long as they don't 51% attack that small mining pool).

[BlackHatCoiner]

2. Is this why luke wanted  a fork? Because only through changing consensus rule can they really prevent 'spam'.

He's not in favor of a fork. He just mentioned it once, to get attention. Luke is an attention whore who lost 216 BTC in a hack, and has since fought to draw attention and capital into his Ocean mining pool project. With this not-so-recent drama, he has achieved creating just another Bitcoin Core hysteric episode, where he's portraying himself as the arbitrator of truth, and steps on the emotions of bitcoin node runners who've got sick of the latest spam waves (Ordinals), and who think it is possible to stop this by reconfiguring their mempool policy.

It's a pretty smart strategy to get funded by portraying you're "defending evil" and you're the good guy, while others are "sold out".

[gmaxwell]

They can't even prevent spam with a consensus change, because if the spammers use fake public keys, they could integrate a check to ensure the keys are "valid" (even if they are fake). This would be a bit more difficult computation wise but in the end I don't think they would lose much data capacity.

Making a key valid costs only ~1 bit of storage, takes a significant fraction of the time of a signature validation to check.. and some script types are hashes and all byte sequences of the right length are valid hashes.  Also, clamping down on this would break further upgrades that would use other kinds of keys (like if bitcoin were updated with a new more secure curve or some PQ signature scheme).

Also if you reduce the capacity, the parties using it will just use even MORE blockchain capacity.  It's important to keep in mind that virtually 100% of the price sensitive data embedding traffic is already gone due to market competition for limited capacity. All the data embedding stuff that remains is not price sensitive or it's even inverse price sensitive (like NFTs liking high fees as a mechanism of making NFTs more scarce.)