Thread

PSA: β€œInscriptions” are exploiting a vulnerability in #Bitcoin Core to spam the blockchain. Bitcoin Core has, since 2013, allowed users to set a limit on the size of extra data in transactions they relay or mine (`-datacarriersize`). By obfuscating their data as program code, Inscriptions bypass this limit. This bug was recently fixed in Bitcoin Knots v25.1. It took longer than usual due to my workflow being severely disrupted at the end of last year (v24 was skipped entirely). Bitcoin Core is still vulnerable in the upcoming v26 release. I can only hope it will finally get fixed before v27 next year.

Replies (58)

We are happy to announce testing of Bitcoin Knots v25.1 has completed successfully, and is now deployed to production. Among other improvements, this upgrade fixes this long-standing vulnerability exploited by modern spammers. As a result, our blocks will now include many more real transactions and help to bring an end to the DoS attack being performed on the #Bitcoin network. So, in addition to our already-established benefits (transparency, non-custodial, and permissionless), we now also offer honest miners the first easy option to contribute toward blocks full of real transactions, effectively a several times larger block size in terms of transaction confirmations, without actually making the blocks any larger. View quoted note β†’
If the purpose was to allow more functionality, and it did, isn't this a personal opinion ? Demand is not a bug or spam. It's one thing to opt in to Knots, it's another for core to continue to decide changes like this. This and Future changes that exclude large segments of use that otherwise follow the rules of supply, ect are vulnerable to politics. Political money is fiat money. Today, you consider this spam. Tomorrow what ese will be considered spam. To the death of bitcoin. One mans free speech is anothers hate speech. Who are you or core , to decide ?
↩ replying to npub1nwhd...409r
yes. It comes down to what one person or faction feel is a bug and what others do not. These opinions hampered by the limits to that one individual or groups values and life experience, attempting to speak for millions of others. The real bug is in how we arrive at the definition of what a bug is, in the first place. On a private project, a team lead decides. On a public project, it becomes political. There is a third option, market choice. People who subscribe to Luke's worldview and vision for Bitcoin can download and run Knots. Another way to let the market decide is to reduce the scope and importance of core, and move features to a layer 2, where consumers choose. Some bugs and upgrades are not political of course. Things such as a flaw in SHA that requires emergency fork. Other bugs are maintenance or efficiency types, as languages and procedures backing the project improve. These can keep being pushed to core, but the surface area can be further reduced, along with ossification. The history of projects shows that when political and technical become confused, the project will eventually alienate so many people, despite the best of intentions and logic, it dies.
↩ replying to npub1lh27...a9nk
Unless i'm missing something however, what you are trying to get core to adopt is not an optional toggle, but a hard size limit, where legacy or non-complient nodes cannot participate or are shunned going forward ? Thus the blocking of "spam" network wide. The wording leads me to believe that's your intention. Or would it still be optional to inscribe if you want ? It's one thing to run Knots/Ocean and gather/market support for it. It's another to frame it as a bug and push it to core as a new defacto standard. By the way, unlike the blocksize debate, this change affects proven profits by motivated network participants. Since adoption and use appear to be increasing unabated despite the "spam", are you fully cognizant of the down stream impact such a change would have ? The second order effects and blowback ?
Ok, let me try to understand this. So Bitcoin core has an option to set a data limit for extra data in each transaction but since inscription obfuscate 'extra data' as program code, ie, putting data elsewhere, like in the signature, for example, they were able to bypass this limit. So this 'fix' is not about limiting or blocking inscriptions, but rather, to give a choice to node runners to choose wether they wanted to relay transaction with large 'extra data' or not as they should have always been able to (well, at least 2013) by making -datacarriersize to also apply to inscription data. Is that correct?
Program code is data. You cannot control how people interpret it. Isn't the fundamental issue here, the witness discount? Apart from that i can't see anything else worthy of discussion. If people are prepared to pay for data encoded in txs, they will always be able to - even in the most disruptive way - see 'Stamps'. I can't see any ethical basis to tell them they can't, nor any technical way to prevent it.
↩ replying to npub18rpu...tfzc
The bitcoin blockchain is not a payment system. It’s a base layer which secures the basic rules. It’s great in doing this. It’s not good for day to day payments. Not to forget that when luke forces his ideology maybe we are becoming a security budget problem in the future when side chains are ready to use and lightning support grows even more. Inscription is not a vulnerability or a bug. It’s a valid transaction and as long as transactions are valid people can do whatever they want with bitcoin.
Decentralisation in Bitcoin's codebase comes from the ability of anyone to release their own reference client, that enforces the consensus rules, as they see fit. Users are divided, at this time, over the legitimacy of 'inscription' transactions. All Bitcoin Knots is doing, is giving users a simple way to vote with their feet. This is the free market, in action. If you do not agree with the consensus implementation, don't run the code. This applies equally to all Bitcoin reference clients. Be it Core, Knots, or otherwise...