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 (23)

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 mark tyler
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 Luke Dashjr
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.