The customer fight over the inclusion of arbitrary data in Bitcoin transactions has taken on a new attack.
The dispute, widely reported by CriptoNoticias, is between people seeking Bitcoin purely for financial reasons and Anyone who allows their space to be used to register non-economic information.
The controversial version 30 of Bitcoin Core, the network’s main software, expanded the space limit for embedding data in text form from 83 bytes to 100,000 bytes (1 megabyte, the maximum size of a Bitcoin block).
Bitcoin Core bug sparks controversy
The discussion started after a programming error was found (bug) Core v.30, discovered on January 5th, eliminates wallets for users attempting to perform file migration processes.
As a result, this failure could result in a loss of funds for those operating those versions of nodes.
However, Wicked, a developer close to Bitcoin Core, published a post on January 7 stating that Bitcoin Core version 29 (v.29) Bitcoin Knots also maintains the same error. Knots is the version maintained by Luke Dashjr, a leading opponent of Core’s data inclusion policy. So the problem may extend beyond your core customers.
The danger behind the Bitcoin Core v.30 glitch
A maximalist Bitcoin analyst known as “Barakomaba” on X (who advocates Bitcoin’s technical and ethical superiority over other cryptocurrencies) warned about the seriousness of version 30’s bugs.
As he explained in X on January 6, people are “underestimating the impact” of that major failure.
“In version 30, we stopped loading or creating ‘legacy’ type wallets (old wallets),” he noted.
Users using older wallets will need to migrate their files. If the migration fails, the same software will force the migration process to run. Can remove access to Bitcoin If you don’t have the security backup you need.
The bitcoiner also pointed out that the risk increases with pruned nodes, which save disk space by removing historical data from the network.
If the user attempts to migrate without loading the wallet, the software will attempt to search for old information to rebuild the balance. Since there is no historical data in the pruned node’s storage, Migration process fails It then activates a flawed cleanup pass that ends up deleting all files in the wallet folder.
For him, It would be irresponsible to call this error irrelevant.. In his view, this is evidence that the review process within Bitcoin Core is becoming increasingly centralized and ignored.
Luke Dashjr drives “anti-spam” node running
Luke Dashjr again pointed out on January 6th that the most accurate options for running node are: «BIP-110 Bitcoin Knot».
As reported by CriptoNoticias, Bitcoin Improvement Proposal 110 (BIP-110, now BIP-444) aims to automatically invalidate blocks containing transactions that contain arbitrary data that is considered garbage.
By running this software combination, users will be using the next version of Bitcoin. Does not recognize or process embedded non-financial information Trading in progress.
The node will continue to view and verify blocks mined by others to stay in sync with the network, but will not store this additional “data” embedded in the OP_RETURN function.
Suggestion by taking a step back
Finally, Ben Sigman, an engineer active in ecosystem development, proposed reversing the expansion of the data space.
For the authors of BIP-360 (a proposal aimed at quantum-proofing Bitcoin), the solution is to restore the historical limit of 80 bytes for the OP_RETURN command.
Sigman argues that reverting to this default provides a compromise that respects the choices of node operators.
To his suggestion, Mr. Wicked replied sarcastically: “It won’t stop anyone from restricting their own nodes if they want, but the people who are most upset are no longer using Core and shouldn’t be offered it. They can keep using Knots.”
