(Headline article below video) It would appear that October will be an interesting time for Bitcoin Core, as with v30 they’re going to extend the data that can be held in OP_RETURN. This will allow for some new technologies to be experimented upon with Bitcoin without changing the fundamental transactional code, but it’s really just going to limit transactions per block with spam transactions and raise transaction fees. Looking at the second article below, they’re doing this in a deceptive way, which kind of shows to me that they’re representing commercial interests over the community and driven by getting it into the codebase by any means necessary, instead of abiding by the community wishes. The beauty with Bitcoin is it is consensus based, so the users running nodes and the miners decide based on what software they choose to run, and node runners are not without power over miners. And we’re talking about a $1.5 trillion blockchain, so fights for control and coercion are to be expected. And you have to wonder if the extra data is for recording identifying information like the IMF and US government want to require to erase your financial privacy?
I was running Bitcoin Core v29 which I recently compiled, but after the video below I decided to send a message by cloning the Bitcoin Knots Github repo and compiling it. Then you just need to replace the Bitcoin Core executables, and restart via systemd. On the positive, Luke Dashjr‘s version is the old school way of compiling with autogen.sh, configure, make, which is easier than the newer way Bitcoin Core is doing it, and I like the older, simpler way. Consequently, Bitcoin Knots is at 17.21% of nodes (4404 nodes and about doubled from before this contentious issue), but even with Bitcoin Core at 82%, only 4472 nodes were running v29 (19.36%), as most are running older versions. So what they’re doing with v30 might not have an impact as they may be forced to retreat if not many node operators will run it, which I believe will be the case. And since I’ve switched to Bitcoin Knots, my node is now filtering the spam transactions and not forwarding them. And the Bitcoin Core group working with the spammers can’t try to flood my node for the full blockchain as I have limitations on how much of the blockchain my node will upload, and I don’t have a data cap either. Time to watch the numbers and how many others switch to Bitcoin Knots.
https://bitnewsbot.com/bitcoin-core-v30-debate-heats-up-as-hypothetical-dos-attack-mocked/
Bitcoin Core v30 Sparks Controversy as Knots Nodes Oppose Mempool Policy Changes and Discuss DoS Attack Scenarios
By Pavlos Giorkas
- Debate over Bitcoin Core v30 intensifies as Knots nodes protest upcoming changes to mempool policy.
- A pro-v30 mining pool consultant discussed, but did not actually carry out, a potential Denial of Service (DoS) attack against Knots nodes.
- Knots opposes Bitcoin Core v30’s plan to increase default limits for OP_RETURN data in the mempool.
- Developers explained that no real attack took place after a mischaracterization spread on social media.
- Knots lead developer Luke Dashjr shared advice for node operators to defend against possible future attacks.
The ongoing disagreement between supporters of Bitcoin Core version 30 and users of Knots software has escalated, with Knots node operators actively protesting proposed mempool policy changes. The current stable Bitcoin Core release is version 29.0, while 30.0 is scheduled for release in October 2025. Knots, a fork of Bitcoin Core, is the primary tool for those objecting to the v30 changes regarding data handling.
Over the weekend, a consultant advising pro-v30 mining pools described a hypothetical Denial of Service (DoS) attack strategy against Knots nodes during an online discussion. The scenario involved identifying Knots node operators using residential internet and repeatedly requesting Initial Block Downloads (IBD) from their nodes. This type of attack can slow down or disrupt node operations by overloading their data connections. Several developers associated with v30 found the hypothetical situation amusing, with some discussing the details publicly on X.
A misinterpretation about the event later gained traction on social media. However, a co-host of the discussion later clarified that no actual DoS attack was performed. The clarification emphasized that the described attack was not real and no Knots nodes reported disruption.
The core of the disagreement is how each software version treats OP_RETURN, a Bitcoin transaction feature that allows attaching data to the blockchain. Bitcoin Core v30 plans to accept larger data sizes—up to 1 megabyte—by default in its mempool, which is the pool of unconfirmed transactions. In contrast, Knots keeps the traditional, much lower limits, only allowing OP_RETURN data to take up about 0.01% of that size. Supporters of v30 argue that the mempool should match the underlying technical protocol, while Knots users caution that relaying more arbitrary data increases burdens for ordinary node operators.
Luke Dashjr, lead developer for Knots, shared a recording of the discussion and offered instructions for protecting nodes from future hypothetical attacks. He recommended that operators using residential internet should limit their daily data uploads to avoid exceeding their internet service provider’s limits.
The public exchange illustrates the ongoing tension between the two camps, with both sides preparing for the formal release of Bitcoin Core v30 later this year. For now, Knots node operators are urged to follow Dashjr’s advice as the debate over mempool filtering and network resilience continues.
Three sneaky changes in Bitcoin Core v30 are confusing node operators
By Protos Staff
A vocal community of node operators who prefer traditional limits on the amount of arbitrary data that can accompany a bitcoin (BTC) transaction is infuriated with an upcoming software release for at least three reasons.
Bitcoin Core version 30 (v30) is the upcoming version of the network’s most popular full node software. It will drastically increase the amount of data unrelated to the on-chain movement of BTC that nodes will accept by default into their mempool.
However, the release is also confusing Bitcoin Core users who’ve grown accustomed to a data filter on OP_RETURN outputs which has operated since 2011.
Specifically, users who want to limit the amount of data unrelated to the on-chain movement of BTC will have to jump through confusing hoops, including a rewritten config option that changes the effect of a simple number that has done the same thing for more than a decade.
In v30, Core devs will suddenly nerf “datacarriersize=” by about 88%.
In all, there are three major changes from Bitcoin Core version 29.0, and the upcoming v30 scheduled for release in October 2025.
Bitcoin Core v30: More data, more confusion about how to limit it
Three changes will come into effect with Bitcoin Core v30 in October.
First, v30 will, for the first time in more than a decade, allow transactions into a node’s default mempool with more than one OP_RETURN output.
New standardness rules in v30 accept multiple OP_RETURN outputs within transactions into the default mempool of Core nodes.
Second, Core developers have rewritten the v30 configurability setting “datacarriersize=” from signifying what it has meant for years.
This user-configurable number used to specify the number of allowable bytes of data that a node’s mempool would accept within one OP_RETURN output.
In v30, this same number and setting will now permit nine times more data than that same number would have allowed in v29 and prior versions.
Knots developer Luke Dashjr, whose software has displaced Core on about 16% of the reachable nodes across Bitcoin’s network, illustrated this confusing change with an example of datacarriersize=83.
In v29 and prior, any Core node operator specifying the number 83 here would have limited OP_RETURN arbitrary data to 92 bytes per transaction.
In v30, however, any user specifying the same figure will suddenly allow 830 bytes of arbitrary data.
This is because Core developers have rewritten the configurability setting “datacarriersize=” entirely to accommodate v30’s new standardness rules to allow multiple OP_RETURN outputs instead of just one.
He calls the slick change a “trick” by “bad actors.”
Deprecating user configurability of OP_RETURN storage limits
Finally, Core developers are resetting the default filter from a few bytes to nearly 4MB. They’re also marking this user-configurable filter for deprecation entirely as a way to advise users to not rely on the configurability setting “datacarriersize=” in upcoming releases.
Although Core developers will technically allow v30 node operators users to lower the data storage number via the setting “datacarriersize=”, they’ve not only changed the meaning of datacarriersize but also told users that this rejiggered configurability option will be deprecated soon anyway.
As a result of these changes, Knots leaders are complaining about Bitcoin Core v30 having “malicious code” because it will deprecate the user configurability of datacarriersize and permanently enshrine a new default that accommodates arbitrary data into mempools at a scale never before seen in Bitcoin’s history.
Read more: Knots ‘warning’ escalates Bitcoin OP_RETURN war
A GitHub post by Instagibbs attempts to clarify that Bitcoin Core developers still retained datacarrier arguments, although they are marked as deprecated.
As a result, Bitcoin Core developers haven’t promised to keep these variables forever.
Bitcoin Core developers at Chaincode Labs seem intent on pushing all of these changes through with v30 despite their drastic impact and confusing implementation for average node operators.