A Power Struggle to Control Bitcoin is Happening

🪓 What Is BIP-110?

The Bitcoin community has always debated what Bitcoin should be.

Should Bitcoin's base layer remain a general-purpose transaction system where users are free to invent entirely new ways of using the network?

Or should Bitcoin evolve into a minimal settlement layer whose sole purpose is to securely settle financial transactions, leaving everything else to Layer 2 protocols?

BIP-110 answers that question very clearly.

Its supporters argue that Bitcoin's blockchain should remain focused on financial settlement rather than becoming a general-purpose data layer. Under this philosophy, applications such as NFTs, tokenization, Real World Assets (RWAs), and other systems requiring significant on-chain data should be built on Layer 2 networks instead of directly on Bitcoin.

To achieve that goal, BIP-110 proposes introducing new consensus rules that would invalidate certain classes of transactions that are considered valid today.

Supporters describe this as protecting Bitcoin's role as a settlement layer.

I see it differently.

I see it as the first serious attempt to redefine what kinds of transactions Bitcoin users are permitted to create.

That distinction matters.

Because once Bitcoin begins rejecting transactions not because they violate the protocol, but because they violate a particular philosophy about how Bitcoin should be used, Bitcoin stops validating transactions based solely on their correctness and begins judging them based on their intended purpose.

It becomes a transaction system with approved and unapproved uses.

🧱Satoshi Designed Bitcoin for Something Different

The historical record is not subtle.

In 2010, Gavin Andresen asked Satoshi about bitcoin scripting.

Why did Bitcoin need a scripting language at all? Wouldn't a simple payment system have been enough?

And if Script existed, did that mean developers could create entirely new kinds of transactions- even transactions anyone could spend, or entirely new forms of digital assets?

First: it make me a little nervous that bitcoin has a scripting language in it, even though it is a really simple scripting language (no loops, no pointers, nothing but math and crypto). It makes me nervous because it is more complicated, and complication is the enemy of security. It also makes it harder to create a second, compatible implementation. But I think I can get over that.

Looking at the code, new transactions are verified by pushing the signature an then public key on the interpreter's stack and then running the TxOut script (did I get that right?).

Could I write code to create transactions with any valid script in the TxOut?

E.g. could I create a TxOut with a script of:  OP_2DROP OP_TRUE

... to create a coin that could be spent by anybody?

And is flexibility in the types of coins created the reason it is coded this way?

-- https://bitcointalk.org/index.php?topic=195.msg1606#msg1606

Satoshi's answer reveals exactly how he viewed Bitcoin's architecture.

The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.

-- https://bitcointalk.org/index.php?topic=195.msg1611#msg1611

He did not answer, “Because every transaction must look financial.”

He did not answer, “Because developers should decide which uses are acceptable.”

He answered the opposite.

Satoshi explained that Bitcoin’s core design had to be set early, and because of that, he wanted Bitcoin to support every possible transaction type he could think of.

The entire reason Script existed was to avoid the need for an integrated “explosion of special cases” and instead allow transacting parties to define their own conditions while nodes merely evaluated whether those conditions were satisfied.

Satoshi did not say the nodes should evaluate why a transaction exists.

He did not say they should determine whether it was "financial."

He did not say they should reject transactions because developers disliked their purpose.

He said they should evaluate whether the sender's conditions had been satisfied.

That is the philosophical heart of Bitcoin Script.

Not permission.

Not pre-approval.

Not developer-approved transaction categories.

A predicate.

True or false.

Valid or invalid.

Satoshi was clear that nodes did not need to understand the purpose of every transaction. They only needed to validate whether the sender’s conditions were met. He even listed examples of future transaction types: escrow transactions, bonded contracts, third-party arbitration, multi-party signatures, and more.

That history matters because BIP-110 walks in the opposite direction.

BIP-110 does not merely say, “This transaction is invalid because it fails Bitcoin’s existing rules.”

It says, in effect:

“This transaction is invalid because we do not approve of what users are doing with Bitcoin.”

That is not validation.

That is censorship dressed in protocol language.

🔥 BIP-110 Is Not Defending Bitcoin. It Is Narrowing Bitcoin.

BIP-110 openly states:

Temporarily limit the size of data fields at the consensus level, in order to correct distorted incentives caused by standardizing support for arbitrary data, and to refocus priorities on improving Bitcoin as money.

This sounds good in theory, but what they are supporting doesn't push bitcoin towards being money. It pushes bitcoin towards being a censored rails system that only allows bitcoin to be a settlement layer where the true money must exist as a layer 2 on top of bitcoin.

It is not about:

• miner preference.
• fee-market choice.
• consensus

That means BIP-110 is not merely about what one node chooses to relay. It is about what the entire network is allowed to consider valid.

That is a massive philosophical escalation.

Bitcoin was designed so users could create transactions and the network could evaluate whether those transactions satisfied the rules. BIP-110 attempts to redefine the rules around an acceptable political vision of what Bitcoin “should” be.

That is not ossification.

That is revision.

🧨 The “Financial Only” Myth

The modern “Bitcoin is a financial settlement layer” crowd wants to pretend Bitcoin was born as a sterile financial rail.

It was not.

Bitcoin was electronic cash, yes. But the system Satoshi released was not a simple balance-transfer database. It had Script. It had programmable spending conditions. It had transaction predicates. It had room for future transaction types that nodes could validate even when they did not understand their higher-level meaning.

That is not an accident.

That is architecture.

So when BIP-110 supporters say they are protecting Bitcoin’s purpose, the obvious question is:

Whose purpose?

Because the purpose described by Satoshi was not “only allow transactions developers personally consider monetary.”

The purpose was broader, stranger, more flexible, and more powerful.

Bitcoin was not designed to ask developers what a transaction means before allowing the network to validate it.

⚠️ Policy Is One Thing. Consensus Censorship Is Another.

OP_RETURN policy limits have changed over time. That alone proves the point.

Originally OP_RETURN created by satoshi had not return limit. In 2014 a 40 byte limit was imposed, then later again raised to an 80 byte limit, and in 2025 that limit was removed entirely back to Satoshis original no limit.

A relay policy is a local choice. A node may choose what it wants to forward. Miners may choose what they want to mine. Users may route around hostile policy by finding miners willing to include their transactions.

That is messy.

That is Bitcoin.

But BIP-110 attempts to move the fight from policy into consensus. It aims to make certain data-heavy transaction forms invalid at the network-rule level, with limits such as capping officially supported data-storage methods to 256 bytes or less.

That is not the same category of action.

Policy says:

“I will not relay this.”

Consensus says:

“No one is allowed to mine this.”

Those are worlds apart.

🎨 Bitcoin's First On-Chain Artwork

One of the biggest myths surrounding the modern Bitcoin debate is that using Bitcoin for anything other than financial transfers is somehow a recent invention.

It isn't.

By 2011—just two years after Bitcoin launched—users were already embedding ASCII artwork directly into the blockchain.

These pieces of art predate Ordinals, NFTs, and virtually every modern debate over arbitrary data by more than a decade.

Whether someone believes art belongs on Bitcoin is a matter of opinion.

Whether people were already using Bitcoin this way in its earliest years is a matter of history.

🚩An attack on Satoshi's Process

BIP-110 is not only an attack on the transaction freedom Bitcoin was designed for. It is also becoming an attack on the process Satoshi warned was necessary to keep Bitcoin coherent.

Satoshi did not merely design Bitcoin’s rules. He warned that Bitcoin depends on nodes producing identical results in lockstep.

“I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.”

That warning matters here.

BIP-110 supporters are not merely debating an idea. Many are encouraging users to abandon Bitcoin Core and switch to Bitcoin Knots as a political signal against transactions they consider spam.

That matters because this is not just a branding dispute. Knots applies different non-consensus behavior around transaction relay and filtering. It treats some transactions that are valid under Bitcoin consensus as transactions that should not be propagated through that node’s mempool policy.

That is precisely the kind of network-level fragmentation Satoshi warned against.

No, relay policy is not consensus.

But pretending relay policy does not matter is dishonest.

Relay policy affects what transactions move through the network. It affects what miners see. It affects what wallets can reliably broadcast. It affects whether valid transactions are treated as normal network activity or routed around hostile nodes.

So when BIP-110 supporters encourage a split between software distributions in order to suppress otherwise-valid transactions, they are not defending Satoshi’s process.

They are undermining it.

They are creating a Bitcoin where two nodes can follow the same consensus rules but still participate in materially different networks.

One network relays valid transactions.

The other filters them based on an ideological definition of spam.

That may not be a consensus split yet.

But it is absolutely a philosophical split.

And Satoshi warned what happens when Bitcoin stops behaving as one coherent system:

“So much of the design depends on all nodes getting exactly identical results in lockstep...”

BIP-110 supporters should read that sentence again.

💥 The Real Attack Is Against Transaction Freedom

BIP-110 is sold as an anti-spam measure.

But fees already exist.

Block space already has a price.

Miners already choose transactions.

Users already compete.

That is the market mechanism Bitcoin actually has.

What BIP-110 adds is not a fee market. It adds ideological filtering. It declares that some valid transactions should become invalid because their purpose offends a particular vision of Bitcoin.

That is the dangerous precedent.

Today it is inscriptions.

Tomorrow it is tokens.

Then it is covenants.

Then it is mixers.

Then it is anything someone powerful enough decides is “not money.”

Once Bitcoin accepts the principle that consensus rules should be used to enforce acceptable transaction purposes, the war is no longer about spam.

It is about who gets to define Bitcoin.

And the answer was never supposed to be: node operators running a second implementation with a blacklist.

❓What does this have to do with Contractless blockchain?

Bitcoin's design left room for future disagreement over what kinds of transactions should exist.

I wanted to eliminate that disagreement entirely.

Bitcoin's architecture left questions unanswered that were always going to become political once the network became valuable.

One of the main things I did differently with Contractless was creating something called txtypes. Txtypes are structures that define different types of uses instead of using a scripting language.

Contractless has txtypes for:

• mining rewards
• transfer of tokens/coins
• creation of tokens
• issuing more tokens to existing token pools
• nft and rwa creations (both single nfts and series/collections)
• creating marketing records
• performing swaps through dual signatures
• creating collateral based loans through dual signatures
• making loan payments
• conditionally claiming collateral used in loans
• burning tokens
• vanity address creations

Each of these txtypes is validated in a different way specific to the data that must be included.

Every txtype in Contractless is defined by consensus from day one.

There is no need for future debates over whether NFTs should exist.

There is no debate over whether token creation belongs on the chain.

There is no debate over whether marketing records are "spam."

If the transaction type exists, every node validates it exactly the same way.

If it doesn't exist, it isn't valid.

There is no middle ground where node implementations begin deciding which valid transactions they personally approve of.

I am also working to expand those txtypes to include data storage types to allow storing of data:

• boolean true/false storage
• 8-bit number storage
• 16-bit number storage
• 32-bit number storage
• 64-bit number storage
• 128-bit number storage
• 180 byte string storage

Just like other transaction types each of these data storage types will have a validation process. In this way, there is never an issue of later users wanting to change what type of storage can exist or how users must use the chain.

These are just some of the things I have done differently with Contractless.

Check out the source code, docs and whitepaper link for contractless at:
https://contractless.dev/contractless/Contractless