Today, Luke Dashjr posted a tweet：

“‘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.”

Somebody commented as follows:

“So if this ‘bug/vulnerability’ is fixed, does it mean ordinals and brc-20 token would stop being a thing?”

Luke Dashjr replied:”Correct.”

It is known that in September of this year, Luke submitted a pull request (PR) to the Bitcoin Core Github repository: “Updates -datacarriersize to be effective with newer datacarrying styles.” Devs’ opinions vary, with opponents stating it may impact miner income and incentivize private memory pools, which miners may not adopt. Supporters believe that this will effectively ease the node burden. Notably, one of the Bitcoin Core code maintainers, Gloria Zhao (glozow), seems not to oppose but suggested, “Maybe add some tests?” The PR is still open, and it remains uncertain whether it will be merged into master. Luke’s stated desire to incorporate this change in Bitcoin Core v27 next year is only a personal expectation, and Bitcoin Knots v25.1, which has already incorporated this change, can be understood as an early experimental version of Bitcoin Core with community maintenance development.

We compiled some analyses of relevant KOLs, as follows:

● @wooooer analysis indicates that Luke set two main parameter limits in Knots to filter so-called Bitcoin fraud transactions: “datacarriersize” primarily limits the size of data carried by op-return, i.e., data written in the UTXO’s output section; “maxscriptsize” limits the size of the Memo Protocol based on TaprootScript, with its data engraved in the UTXO’s witness field. If Luke’s vision makes it into the core, default limits on these two parameters may result in only taprootassets and RGB, occupying the smallest on-chain footprint, remaining in the Bitcoin ecosystem.

● @tmel0211 states that Bitcoin Core v25.1 gives miners a switch to choose whether to include transactions exceeding the SIZE limit. However, since miners benefit from it, none would choose to disable it.

● @nake13 points out that a more accurate title for Luke Dashjr is Bitcoin Core client developer, as he contributes code to both Core and Knots. The update documentation for Bitcoin Knots 25.1 was mainly written by Luke himself. Luke is also the CTO of OCEAN mining pool, which uses this client, recently supported by Jack Dorsey. In Bitcoin Knots 25.1, the description of -datacarriersize was modified, changing the default value from 83 to 42. Newly added parameters like -datacarriercost, -datacarrierfullcount, and -maxscriptsize provide miners with additional control over the scale of carried data, offering them freedom of choice.

Bitcoin developers have previously discussed this issue on the Bitcoin-dev mailing list, and WuBlockchain has compiled it into an article. Learn More

Follow us
Twitter: https://twitter.com/WuBlockchain
Telegram: https://t.me/wublockchainenglish