{"id":24270,"date":"2025-05-26T12:14:34","date_gmt":"2025-05-26T09:14:34","guid":{"rendered":"https:\/\/forklog.com\/en\/core-vs-knots-the-83-byte-row-that-split-the-bitcoin-community\/"},"modified":"2025-05-26T12:14:34","modified_gmt":"2025-05-26T09:14:34","slug":"core-vs-knots-the-83-byte-row-that-split-the-bitcoin-community","status":"publish","type":"post","link":"https:\/\/forklog.com\/en\/core-vs-knots-the-83-byte-row-that-split-the-bitcoin-community\/","title":{"rendered":"Core vs Knots: the 83-byte row that split the bitcoin community"},"content":{"rendered":"

In spring 2025, one of the biggest rows in years erupted in the bitcoin community. A technical proposal<\/a> to lift the OP_RETURN data cap snowballed into a broad dispute between developers and users.<\/p>\n

Bitcoin Core backed scrapping the 83-byte limit, while opponents rallied around the alternative client Bitcoin Knots. Together with the bitcoin mixer Mixer.Money<\/a> we examine the technical issues and the potential impact on the future of the first cryptocurrency.<\/p>\n

What is OP_RETURN<\/h2>\n

OP_RETURN is an opcode (a command) in bitcoin\u2019s stack-based Script language that renders a transaction output unspendable while allowing up to 83 bytes of arbitrary data to be recorded. It is the standard way to add metadata to the blockchain without increasing the size of the UTXO<\/a> set \u2014 the database of all unspent transaction outputs.<\/p>\n

OP_RETURN was introduced in 2014 with Bitcoin Core 0.9.0. It was not intended to promote on-chain data storage; it was a compromise to prevent more harmful practices.<\/p>\n

\n

\u201cThis change is not an endorsement of data storage in the block chain. OP_RETURN creates a provably prunable output to avoid data storage schemes where arbitrary data such as images would be stored as permanently unspent transaction outputs<\/span>, bloating the UTXO database. Storing arbitrary data on the block chain is still a bad idea; it is much cheaper and more efficient to store non-financial data elsewhere,\u201d the Bitcoin Core documentation<\/a> said.<\/p>\n<\/blockquote>\n

According to Bitcoin Core developer Gregory Maxwell<\/a>, before OP_RETURN users found ways to embed data by sending bitcoins to \u201cfake\u201d<\/span> addresses. They created outputs that looked spendable but were not, causing permanent bloat in the UTXO set.<\/p>\n

\n

\u201cWhile OP_RETURN outputs do add to bitcoin\u2019s overall blockchain size, they are not included in the UTXO set, so nodes do not need to track them indefinitely. Nodes can ignore and prune these data after initial verification,\u201d comment the team at Mixer.Money<\/a>.<\/p>\n<\/blockquote>\n

The initial cap was<\/a> 40 bytes, raised to 80 in 2015 and to 83 in 2016. The limits were deliberate, nudging users towards storing hashes rather than raw data and underscoring that bitcoin\u2019s blockchain should primarily serve financial transactions.<\/p>\n

Importantly, the OP_RETURN cap is<\/a> a standardness rule<\/span> (mempool policy), not a consensus rule. By default, Bitcoin Core nodes do not relay transactions with OP_RETURN data above 83 bytes, but the bitcoin protocol does not forbid them.<\/p>\n

Miners may include \u201cnon-standard\u201d transactions in blocks, especially if fees make them profitable. If such a transaction lands in a valid block, all nodes will accept it regardless of their OP_RETURN policies.<\/p>\n

Todd\u2019s proposal<\/h2>\n

On April 27, 2025 Peter Todd filed<\/a> Pull Request (PR) #32359 to the Bitcoin Core repository. The proposal would remove the cap on OP_RETURN output size entirely, formalising an initiative by Antoine Poinsot of Chaincode Labs.<\/p>\n

The idea arose after Poinsot learned<\/a> that the bitcoin ZK-rollup Citrea, constrained by OP_RETURN policy, chose to publish data on-chain using one OP_RETURN and two UTXOs. Those two unspent outputs would accumulate, even though limiting UTXO-set growth is a core Bitcoin Core aim.<\/p>\n

\u201cTheoretically, lifting the OP_RETURN cap would let projects like Citrea implement technical solutions without increasing the UTXO set. It could also affect miners that accept transactions via private mempools rather than organically through the node network,\u201d comment the team at Mixer.Money<\/a>.<\/p>\n

Todd\u2019s proposal required neither a soft fork nor a hard fork \u2014 it merely broadened the types of transactions that the network would relay.<\/p>\n

Some welcomed the deletion of what they saw as redundant code. Others, while acknowledging the cap\u2019s limited effectiveness, opposed removal, arguing it would encourage spam.<\/p>\n

In particular, developer Luke Dashjr urged keeping the restriction and either staying on older Core versions or switching to his Bitcoin Knots client, which has<\/a> a stricter 42-byte OP_RETURN limit.<\/p>\n

On May 5, Bitcoin Core developer Greg Sanders said he intended to include the change in the next release, further inflaming debate. Many users publicly announced a move to Bitcoin Knots, and several bloggers (BTC Sessions<\/a>, Southern Bitcoiner<\/a>) posted how-to videos on YouTube.<\/p>\n

\"Core
Data: Coin Dance<\/a>.<\/figcaption><\/figure>\n

By May 2025 Bitcoin Knots\u2019 share of nodes had neared 10%. In January 2023 its share was<\/a> just 0.3%.<\/p>\n

Bitcoin Core\u2019s case<\/h2>\n

Proponents make several points:<\/p>\n