Reading view

There are new articles available, click to refresh the page.

Bitcoin is NOT Changed by Proof Of Node

Bitcoin Magazine

Bitcoin is NOT Changed by Proof Of Node

You might have heard about BIP-110; here’s why this fork is not just bad for Bitcoin, but it is built on a misunderstanding of what a Bitcoin node is and what it is good for. As well as why, because of this misunderstanding, BIP-110 will fail. 

This article is a Take. Opinions expressed are entirely the author’s and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

BIP-110 is a Bitcoin Improvement Proposal titled as a Reduced Data Temporary Softfork. The BIP proposes a consensus change to Bitcoin, which attempts to limit the types and amounts of arbitrary data that can be added to consensus-valid transactions by limiting a wide range of Bitcoin’s scripting capabilities. BIP-110 is led by a pseudonymous developer known as Dathon Ohm and is widely supported by the Knots community, an alternative implementation of Bitcoin led by one of Bitcoin Core’s earliest contributors, Luke Dashjr and its supporters.

The BIP-110 consensus change is headed towards a mandatory signaling period in the coming weeks and thus a potential fork with the main consensus rules as implemented in Bitcoin Core. The proposal needs to gain a great deal of support from miners within the coming weeks to change Bitcoin consensus. As of the time of writing, miner signaling for BIP-110 stands at less than one percent


The Knots community, widely made up of Bitcoiners running nodes on machines like Start9 and Umbrel, has rallied around Knots in protest of a series of development decisions made by Bitcoin Core, the primary open source development community and reference implementation of Bitcoin. While a majority of senior Bitcoin developers are either opposed or apathetic to the changes proposed by BIP-110, the movement has gained enough steam to become an ongoing topic of discussion on social media. 

Supporters of BIP-110 believe that by running Bitcoin full nodes that signal for the consensus change, they alone can change Bitcoin. Here are the main concepts being debated, the biggest misconceptions about Bitcoin consensus, what a Bitcoin node is, and why BIP-110 is almost certain to fail. 

The Power and Limits of a Bitcoin Node

Many of the disagreements and misconceptions in this recent cultural conflict within Bitcoin revolve around the idea of a Bitcoin full node. Influencers like Knut Svanholm, author and podcaster, have elevated the role of the full node to heights perhaps too close to the sun. 

Knut recently tweeted: “Every person on Earth is a node in the Bitcoin network. Most to a minuscule extent, of course, but every node is first and foremost a person, not a machine. Which tools we use to interact with the network (and, by extension, to which extent they influence the network) is entirely dependent on the choices we make.”

Statements of this sort are poetically beautiful, philosophically grand, romantic even, but nevertheless technically incoherent and fundamentally meaningless. Knut’s tweet attempts to redefine what a ‘Bitcoin node’ means and fails at it, instead diluting the value of the term entirely. He might as well have said that every atom in the universe is a Bitcoin node, since apparently to him the term is all-encompassing. 

Knut,  though well-intentioned, is wrong. A Bitcoin node is something very specific. It is a full copy of all of Bitcoin’s transaction history, block headers and transaction-related data. Its purpose is very specific: to let users verify the integrity of Bitcoin’s supply and transaction history in relation to Bitcoin’s consensus rules. 

Bitcoin nodes grant users a variety of benefits, such as privacy. Third-party wallet providers query their copy of the Bitcoin blockchain for the user’s balance and serve it back to the user via the wallet app. Most mobile wallets function this way, with users asking a third-party server for their balances. Some, very few, can connect to a user-run Bitcoin node, in which case the user’s public addresses and balances are not shared with any third-party wallet company. 

Another benefit Bitcoin nodes grant users is the ability to check whether they are in consensus with the rest of the network, staying in sync. If the user mines Bitcoin or contributes any significant amount of hashing power to Bitcoin’s proof-of-work network, the node also provides the opportunity to assemble a block, choosing which transactions go into it. This is only possible if the user manages to mine a Bitcoin block, which is quite an achievement today, given the difficulty and steep competition. 

Even new kinds of mining pools like Ocean, which attempt to decentralize block template production, letting retail miners have more influence over which transactions enter the chain, still need enough hashing power to win the proof-of-work race, resulting in sporadic blocks being mined and thus limited influence over the blockchain. 

Bitcoin nodes also relay transactions across the network, with tens of thousands of them communicating via a flood network; this results in a censorship-resistant system where a small number of nodes can get controversial transactions to miners, bypassing any kind of filters, as demonstrated by Peter Todd’s relay libre. Thus, Bitcoin nodes can not easily filter which transactions enter the blockchain.

Even a large majority of Bitcoin nodes alone cannot alone change Bitcoin consensus. Not without having a large amount of economic activity entering the Bitcoin network through them, as exchanges do on behalf of millions of users. Not without having the protocol and application developer community behind them. Not without having the investor community behind them. Bitcoin is not a node democracy, contrary to popular memes today. 

Bitcoin nodes do not grant you ‘citizenship’ in the ‘Bitcoin nation’. Satoshi Nakamoto was quite clear about this in the Bitcoin white paper. Bitcoin’s ultimate security and governance structure is: one CPU cycle, one vote, not one node, one vote. And miners, who run the CPU cycles over Bitcoin’s proof-of-work, are very sensitive to investor sentiment and the broader developer community, resulting in a distributed global protocol for money that is very difficult to change. 

Bitcoin nodes ultimately let you know if you are connected to the network with the most accumulated proof-of-work and that its consensus rules are being followed, but a node alone does not let you change the consensus rules. Users who change the consensus rules of their Bitcoin node are, by definition, no longer running Bitcoin. As a result, changing Bitcoin consensus as a node runner is very difficult, and that’s a feature, not a bug. Bitcoin is money for enemies. 

History and Bitcoin Consensus Games

Deep work has been done, trying to understand Bitcoin consensus, its various pillars and interest groups. Ren Crypto Fish, Steve Lee and Lyn Alden identified six of them in BCAP, an open-source effort to analyze Bitcoin consensus and risks in protocol upgrades. BCAP identified stakeholders such as Economic Nodes, Investors, Media Influencers, Miners and Protocol Developers, and Users and Application Developers

Historically, in the case of a consensus crisis, it is true that Bitcoin nodes have been used to signal support for one version of Bitcoin over another. Fork events like 2017’s Bitcoin Cash fork are often cited as examples of economic nodes winning against opposition by miners. 2017’s legendary User Activated Soft Fork (UASF) faced major opposition in theory; a large majority of mining pools and their corresponding collective hashrate supported the Segwit2x version of Bitcoin, with many exchanges and corporations having signed the infamous New York Agreement in support of it. 

The Bitcoin node-supported soft fork against it won nonetheless, bluffing the Segwit2x version from a contested blockchain altogether. But that’s the thing: while the Bitcoin nodes technically won, they did so by having massive support from protocol developers, investors and media influencers: these nodes really had economic weight and rough consensus. BIP-110, on the other hand, does not have the protocol developers, nor does it have enough investors behind it. Michael Saylor has come out against it, with many industry leaders also openly opposing it or staying out of the matter entirely. 

In fact, during the Bitcoin Cash fork, the limits of retail Bitcoin nodes were clearly understood. A Bitcoin node run by an exchange is orders of magnitude more influential than that of a retail user, as it introduces large amounts of new transactions into the Bitcoin network. The Bitcoin node of a major mining pool is far more influential than that of a hobbyist solo miner, as it more often assembles blocks and chooses which transactions settle to the blockchain. 

Most Bitcoiners outside of exchanges use mobile wallets to access their Bitcoin. Such users and investors can ‘vote’ with their money, so to speak, by moving their bitcoins and economic activity elsewhere, be it to a wallet that supports their vision of Bitcoin, or their own full node. But while users remain on mobile wallets that talk to third-party nodes, those users have little individual influence over Bitcoin consensus. And the vast majority of mobile wallets are using a Bitcoin core-compatible back end. 

The same goes for exchanges; their users effectively delegate consensus decisions to the exchange operators. In some cases, exchanges have put consensus issues to a user vote, weighed by their total holdings, returning that decision to end users weighed by capital; we may see this happen again with BIP-110. 

Votes of the sort have started happening with Foundry today. One of the biggest Bitcoin mining pools in the world, Foundry, recently emailed its miners informing them that they can vote on the proposal with their hashrate. A high enough support could result in Foundry signaling for BIP-110, though that remains unlikely. Users who do not vote will effectively signal against BIP-110, defending the status quo. Thus apathy about the topic of BIP-110 would be a win for Bitcoin Core by default. BIP-110 supporters need to culturally win over a majority of the Foundry hash rate, who then must act to vote against the Bitcoin Core developer consensus, the most popular Bitcoin implementation and best supported codebase.

Today, miners are not signaling support for BIP-110 in any significant way. In fact, according to some data, this is one of the least supported soft fork attempts by miner signaling in Bitcoin’s history. Less than one percent of the blocks mined in the current difficulty adjustment period are signaling for BIP110. 

Concluding Thoughts

BIP-110 has so far failed to gain consensus across major interest groups within Bitcoin; neither developers, investors, miners, nor large economic nodes support the consensus change. The result is likely to be a chain split in the coming weeks, which could have significant consequences for lightning wallets running on BIP-110-compliant nodes, ultimately resulting in a new, yet small blockchain that would probably have to change the proof-of-work used to stay alive. 

This post Bitcoin is NOT Changed by Proof Of Node first appeared on Bitcoin Magazine and is written by Juan Galt.

Why Is BIP-110 Creating So Much Controversy, and What Could It Mean for Bitcoin’s Future?

Bitcoin Improvement Proposal 110 (BIP-110) has become one of the most discussed proposals in the Bitcoin ecosystem in 2026. The proposal aims to limit the amount of arbitrary data that can be embedded in Bitcoin transactions, primarily targeting inscription-based protocols such as Ordinals, BRC-20, and Runes. Supporters believe the proposal will help reduce blockchain bloat, lower node operating costs, and preserve Bitcoin’s role as a peer-to-peer payment network. Critics, however, argue that it could restrict legitimate use cases, impact Layer-2 development, and introduce protocol-level censorship.

With the miner signaling window approaching, the discussion around BIP-110 has expanded beyond technical implementation to broader questions about Bitcoin’s governance, decentralization, and future development. This article examines why the proposal was introduced, the changes it proposes, the arguments from both sides, and what the outcome could mean for the Bitcoin network.

What Is BIP-110?

BIP-110 is a proposed temporary soft fork that introduces stricter limits on how arbitrary data can be stored within Bitcoin transactions. The proposal was first introduced in October 2025 under the placeholder draft name BIP-444 by pseudonymous Bitcoin developer Dathon Ohm.

Its primary objective is to reduce non-financial data stored on the Bitcoin blockchain by restricting the transaction structures commonly used by Ordinals, BRC-20 tokens, and Runes. The proposal also aims to reduce blockchain growth, lower node hardware requirements, and improve accessibility for individuals running full Bitcoin nodes.

Although the proposal’s technical specification has been marked as complete, it still requires ecosystem support before any activation can occur.

BIP 110 Time Line Chart

Why Was BIP-110 Proposed?

The proposal was introduced in response to the rapid growth of inscription-based protocols that use Bitcoin block space to store images, tokens, and other forms of arbitrary data. Supporters argue that these applications have significantly increased blockchain storage requirements while driving higher transaction fees for standard Bitcoin users.

According to the proposal, four major issues have emerged:

Proponents also argue that recent policy changes in Bitcoin Core made it easier for data-heavy transactions to enter the network, accelerating blockchain growth and increasing pressure on node operators.

What Changes Would BIP-110 Introduce?

Rather than banning inscription protocols directly, BIP-110 modifies transaction validation rules to make storing large amounts of arbitrary data significantly more difficult.

These restrictions would significantly impact protocols that rely on embedding large amounts of data on-chain.

Potential Impact Across the Ecosystem

Why Has the Proposal Become So Controversial?

BIP-110 has divided the Bitcoin community over a fundamental question: Should Bitcoin prioritize its role as a monetary network, or remain completely permissionless regardless of how block space is used?

Supporters argue that inscription-based protocols are consuming valuable block space, increasing node costs, and making it more expensive for users to participate in the network.

Luke Dashjr, one of Bitcoin’s long-time developers and a supporter of the proposal, has described BIP-110 as “a temporary measure designed to keep validation accessible and protect node operators from unnecessary storage costs.”

Jason Hughes, Vice President of Development and Engineering at OCEAN, echoed a similar view, saying:

“We need to maintain the purity of the blockchain’s base layer to keep it decentralized. BIP-110 restores historical policy caps that should never have been bypassed.”

Independent Bitcoin researcher Robert Allen also believes action is necessary, stating:

“BIP-110 is imperfect, but it is highly preferable to leaving the issue of blockchain spam completely unaddressed.”

Veteran Bitcoin investor Fred Krueger took a broader perspective on the debate, saying:

“Eventually we will figure out some way to deal with spam, quantum, and other issues… Bitcoin will make it through.”

Despite these arguments, opposition to BIP-110 remains significant.

Adam Back, CEO of Blockstream, dismissed the proposal as an unnecessary attempt to regulate how users interact with the network, describing it as a “quest to police other people,” which he believes conflicts with Bitcoin’s permissionless design.

Bitcoin security expert Jameson Lopp has also criticized the proposal, arguing that its architectural priorities are misplaced and warning against introducing consensus changes that could affect broader ecosystem development.

Developer Peter Todd questioned the proposal’s effectiveness, arguing that determined users could bypass many of the proposed restrictions, limiting its practical impact.

Community criticism extends beyond developers. Crypto analyst Javier Hermosa compared the proposal’s supporters to overly restrictive policy advocates, while Ki Young Ju, CEO of CryptoQuant, remarked:

“BIP-110 is like amending the constitution to ban littering in the park.”

Similarly, Samson Mow questioned the proposal’s chances of success, stating:

“It doesn’t have consensus… especially amongst technical development experts… and there are a lot of ordinary people using Bitcoin that don’t agree with it either.”

Supporters vs Critics

What Happens Next?

The next stage for BIP-110 is the miner signaling period scheduled to begin in August 2026. According to the available proposal details, miner support currently remains extremely limited, with signaling reported at approximately 0.31%.

If sufficient support is not achieved during the activation window, the proposal is unlikely to move forward in its current form. However, the broader discussion around inscription protocols, node costs, and Bitcoin’s long-term scalability is expected to continue regardless of BIP-110’s outcome.

Conclusion

BIP-110 has evolved beyond a technical proposal into a broader discussion about Bitcoin’s future. While supporters view it as a way to reduce blockchain bloat and improve node accessibility, critics believe it could limit innovation and alter Bitcoin’s permissionless nature. Regardless of its outcome, the proposal is likely to influence future discussions on Bitcoin governance and protocol development.


Why Is BIP-110 Creating So Much Controversy, and What Could It Mean for Bitcoin’s Future? was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ocean Mining VP Jason Hughes: BIP-110 on Track to Fail as Miner Signaling Stays Below 1%

Bitcoin Magazine

Ocean Mining VP Jason Hughes: BIP-110 on Track to Fail as Miner Signaling Stays Below 1%

BIP-110 – My Notes to Miners

This is a guest post by Jason Hughes, VP of Development and Engineering at Ocean Mining. Opinions expressed are entirely his own and do not necessarily reflect those of BTC Inc. or Bitcoin Magazine. The article originally appeared on X.com and has been published with the permission of the author. 

Let me start off by saying I’m not pro BIP110, and I’m not anti-BIP110. If it actually succeeds as something that gains true consensus within the network and ends up being enforced by a majority of the network… cool. If so, then we’ll go with it because the network has spoken and accepted it, and all nodes, including non-BIP110 nodes, will be pulled along for the ride. Unfortunately for proponents of the proposal, that simply isn’t currently the case by any measurable metric, nor does it appear to have a trajectory suggesting that will change, either. 

There’s been a lot of misleading information about this whole thing, especially in the context of mining. A few quick key bullet points to briefly counter some hyperbole from proponents: BIP110 is NOT inevitable. It CAN fail. BIP110 can and will cause a chain split/fork in a minority hashrate situation. BIP110 is NOT without risk to miners choosing to adopt it. Miners not supporting BIP110 are not suddenly mining “invalid” blocks just because a proposal that isn’t yet adopted simply exists. You’re not a bad person or evil simply because you don’t like or support BIP110. (The fact that I feel the need to point out that last part is actually kind of sad…)

I was going to write a long post to help keep miners informed about things they need to remain aware of as this all plays out… before realizing I already did so months ago, as a document I authored that I had hoped could be put out as a miner education piece at OCEAN. Sadly, it never got published. So I went ahead and updated it, and well, here it is.

Again, keep in mind this was written months ago, intended to be as agnostic as possible in an effort to make it acceptable as a corporate post. That effort failed, so I’m posting it as a personal document today instead. As a miner making important decisions about your operations, you need to be aware of all of this without the sugarcoating and, frankly, outright misleading information coming from some of the BIP110 proponents.  You must be vigilant and decide what’s right for you. 

While there is certainly some misleading information from the opposition as well, nothing I’ve seen is nearly as egregious as the extremely premature claims of victory and accompanying hyperbole pushed by the BIP110 side. Summarizing my doc a bit, my personal suggestion to miners is this: Signal if you support BIP110. Do not signal if you don’t support BIP110 or don’t care. Either way, monitor the network on/around/before block 961632. 

If you continue to see non-signaling blocks from major pools, you can be reasonably certain they’re not going to suddenly decide later to throw away millions of dollars’ worth of revenue to backtrack and signal for BIP110. If they do, by some chance, start to signal for BIP110, you should monitor that and consider switching as required to stay on the heaviest chain. The key point is that, realistically, only one side can win. It’s either BIP110 succeeds, and miners not on the BIP110 side fail, or BIP110 fails, and miners on the non-BIP110 side succeed. 

Moving on, let’s dive into a small fraction of my rationale. 

QUICK FACT: Between 7 and 15% of Bitcoin Nodes are signaling support for BIP110.

Depending on which centralized crawler you look at… no way to know for sure [how many BIP110 nodes are signaling support]. My personal private crawler puts this number much lower, but that’s a discussion for another day. Suffice it to say, I think it’s logical and correct to say that even 15% is not a majority. 

“But Jason! UASF got Segwit activated with fewer nodes!” 

Yep, because many miners, merchants, users, etc., all actually wanted Segwit. There was tremendous economic and community weight behind it. Without rehashing that whole thing, as plenty of resources on the topic from before BIP110 are worth a read, suffice it to say that BIP110 and Segwit activations are not quite comparable, as many have already pointed out. Segwit, for example, went into its UASF territory with around 1/3rd of the network’s hashrate already signaling support. With that kind of backing, the UASF to help push the MASF over the tipping point made a lot of sense. It doesn’t make sense here for BIP110.

QUICK FACT: 0.6% of blocks over the past 60 days have signaled support for BIP110.

[0.6% is a] pretty stark contrast to even Segwit’s low baseline support. Yes, I know it’s increased slightly in the past couple of weeks, but no new entrants. Just more clearly rented hashrate from one of the same small proponents.

Something to keep in mind is that mining BIP110 signaling blocks via DATUM on OCEAN carries virtually no risk to the miner up until the fork point at block 961632. The cost is negligible, as you’re effectively guaranteed to recoup rental costs, etc.

It’s awesome that the ability to do so exists, and I wouldn’t have it any other way… but just something to keep in mind when weighing signaling from such blocks in the grand scheme of things from a risk-reward, money-on-the-table perspective.

“But Jason! Miners have no incentive to signal until the last minute!”

I also see no evidence to suggest that this could be the case. Subjectively, I disagree with the premise, as it’s not in a mining pool’s best interest to destabilize the network in such a way.  Part of the reason for early signaling and lock-in periods is to help coordinate upgrades in a smooth fashion. Waiting until the last minute negates that benefit entirely. I see no compelling rationale or upside to doing so.

Continuing on this, as part of my personal node monitoring setup, I specifically monitor nodes known to belong to various entities, such as other mining pools, exchanges, large lightning nodes, merchants, etc. A supermajority of which are monitored with explicit permission and confirmation/coordination.

QUICK FACT: All major mining pools I monitor are currently running some variant of Bitcoin Core v30 or v31 (except OCEAN). 

Expanding on that, most [mining pools] have updated their nodes since the proliferation of BIP110’s release, even since the release of Knots 29.3. Additionally, it is known that many mining pools run modified versions of their node software to facilitate various requirements of their specific infrastructure. Such changes would need to be ported to a BIP110-compatible client, tested, evaluated, and deployed ahead of time. I currently see no evidence that this is the case currently.

As far as I can tell, the pools are aware but ignoring. 

“But Jason! Miners don’t determine consensus! Nodes do! Otherwise, they’ll just cancel halvings!”

This is one of the funniest and most ridiculous arguments I’ve heard from the pro-BIP110 crowd.  Comparing a consensus change that can be unilaterally enforced upon the network by miners and accepted by 100% of existing nodes (a soft fork), with a hard fork which no existing node will accept… is disingenuous at best. T

ightening rules (like BIP110): Soft fork, can be enforced by miners if they choose to do so. Loosening rules (like canceling a halving): Hard fork, can not be enforced by miners without effectively 100% buy-in from the entire network… which isn’t likely to happen. Comparing the two is, bluntly, just stupid.

“But Jason! If you don’t upgrade to the latest consensus rules, you’re insecure! You’ll lose funds! You’ll mine invalid blocks! You’ll [insert additional hyperbole here]!”

This would be true of a consensus change that has, well, consensus. While BIP110 has made a valiant effort to gain that consensus, it has yet to have any measurable majority at what is now arguably the 11th hour. Not in nodes, not in hashrate, not in the social layers (consensus.health has a cool visual there where you’ll find me in the middle).

If somehow BIP110 gains 51%+ of the network hashrate on/before block 961632… then, alright. It’s enforced, since as a soft fork a majority of miners can unilaterally enforce it in the absence of a fully adopted URSF (effectively a misnomer, as this would kind of be a hard fork).

“But Jason! It can’t gain consensus by already having consensus! You have to give it a chance!”

Firstly… no I don’t, even though I have.  Second, it’s a rushed proposal that never had the time to even try and gain real consensus. It’s been 7 months since the release of the first BIP110 client. There’s ~3 weeks to go before “mandatory” signaling starts as of now (less by the time you read this). 90% of the time available has passed with no change in overall sentiment from any relevant players. If it hasn’t gained sufficient adoption in the past 7 months, it’s not likely to do so in the next 3 weeks.

“But Jason! CSAM! CSAM! Pedophiles! CSAM!”

I’ll be the first to say, even I personally overstated the risk here early on when Core proposed its OP_RETURN change. I personally expected something particularly egregious to hit the chain almost immediately, and to the best of my knowledge, that’s not yet happened. Could it still happen? Yeah, I suppose.

But considering from a technical perspective, byte-for-byte the same contiguous arbitrary data can provably end up stored in the current chain or the BIP-110 chain without much issue… this particular argument for BIP-110 falls pretty flat to me at this point.

Do I want CSAM in the chain? Of course not. Am I a pedophile if I don’t support BIP110? Also not.

Concluding Thoughts

I could continue to go on and on and on, but I’ll stop here. I’ve wasted enough time on this. I’m sure I’ve done plenty to annoy both sides of the BIP110 debate at this point, as I don’t adopt either stance. I’m sure I’ll catch flak from all angles simply for daring to speak my mind on it.

Overall, I mostly think it was silly to approach addressing a real problem (the OP_RETURN default change in Bitcoin Core) with the maximum anti-spam manifesto based soft fork proposal… which provably cannot stop spam, arbitrary data, etc. 🤦‍♂️ (Yes, I know, proponents will claim it’s not about spam… and will also make semantic arguments that it does stop data as well… neither of which appears to be correct.)

I’ll close with the concession that I could be wrong. I’m not Nostradamus, and I can’t accurately predict the outcome with 100% certainty.  I can only go by what the data tells me, and so I give BIP110’s success less than a 5% chance of actually succeeding… and I consider that generous. You can take my opinions on this however you wish, but I highly recommend you don’t discount the actual data points, remain vigilant, and do what’s best for you and your mining revenue. Don’t be gaslit by either side of the debate, and make your own decisions.

Here’s a link to the same document linked above for ease of access.

This post Ocean Mining VP Jason Hughes: BIP-110 on Track to Fail as Miner Signaling Stays Below 1% first appeared on Bitcoin Magazine and is written by Jason Hughes.

Bitcoin Mining Giant Foundry Asks Miners To Vote on BIP-110 Soft Fork

Bitcoin Magazine

Bitcoin Mining Giant Foundry Asks Miners To Vote on BIP-110 Soft Fork

Foundry Digital, the world’s leading Bitcoin mining pool operator, has said it will allow mining clients how the pool should signal on the BIP-110.

The Rochester, New York-based firm said Friday in an email to miners that they will be able to vote by using their hashrate — literally computing power — to vote either for or against the proposal. 

BIP-110, or the Bitcoin Improvement Proposal 110, is a proposal aimed at temporarily restricting spam on the blockchain. If it goes through, a soft fork — a backward-compatible rule change — would take effect, restricting the amount of non-monetary data on the network.

“As miners, it’s important for you to have a voice and participate in the governance of the network,” Foundry said in its announcement. 

“It’s one of the more actively debated proposals in Bitcoin right now, and miners play a direct role in whether it activates,” the company added. 

Also known as the “reduced data temporary soft fork,” the proposal would cap the amount of arbitrary, non-monetary data that transactions can carry. 

Its rules limit most new outputs to 34 bytes, restore an 83-byte limit on OP_RETURN outputs, and reject data pushes above 256 bytes. 

Those for the proposal say that the soft fork would allow Bitcoin to function as pure peer-to-peer money. 

But opponents, including Strategy founder Michael Saylor and Blockstream co-founder Adam Back, argue it converts a policy dispute into a consensus change that could invalidate fee-paying transactions.

Foundry’s process

Under Foundry’s process, each vote carries weight based on an account’s average 10-day hashrate on the pool between July 6 and July 15. Foundry said it will signal based on the majority of hashrate-weighted votes across the signaling period, which it expects to run through early August at block 961,632. 

The company’s starting position is no. It said that until “Yes” votes cross 51% of voting hashrate, Foundry signals “No” with all of its blocks. A crossing of that threshold switches the pool to “Yes” with all of its blocks.

Foundry controls about a third of network hashrate, a share that makes its position consequential for the outcome. Analysts at BGeometrics identified decisions by Foundry and Antpool as capable of moving daily signaling into a meaningful range. A mandatory signaling window near block 961,632, projected for early August, will force the question before the activation timeline closes.

Accounts that do not respond count as “No” votes. Foundry said owners can change their choice while the window remains open, and that individual votes stay confidential, though aggregate results may be shared.

This post Bitcoin Mining Giant Foundry Asks Miners To Vote on BIP-110 Soft Fork first appeared on Bitcoin Magazine and is written by Mathew Di Salvo and Micah Zimmerman.

The Bitcoin Softfork That Tried to Police “Junk Data” — And Why It’s Already Failing

Bitcoin Magazine

The Bitcoin Softfork That Tried to Police “Junk Data” — And Why It’s Already Failing

This is a guest post by Brandon Black. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc. or Bitcoin Magazine.

Within the tiny internet bubble of Bitcoin X (formerly Bitcoin Twitter or Crypto Twitter), there has been a lot of noise in the past year about @dathon_ohm’s proposal for a Reduced Data Temporary Softfork, otherwise known as BIP110. Underlying this proposal is the idea that certain Bitcoin transactions have been violating the principles of the network by including in their locking or unlocking scripts data that can be interpreted in one or more additional ways besides their plain Bitcoin script interpretation. According to BIP110’s supporters, reducing the use of these transactions is sufficient justification for the most confiscatory Bitcoin softfork to date, on a deployment timeline that is dramatically faster than the two most recent softforks, and with a lower activation readiness threshold.

Bitcoin is an open-access, censorship-resistant ledger to which anyone can write entries if they are willing to pay fees sufficient to convince block template creators and miners to include their transaction. The fundamental value of Bitcoin vs. all other ledger systems is the aforementioned open access. Without it, Bitcoin’s ledger has no more value than the bowling alley scoreboard. Because of this fundamentally open access, we all know that Bitcoin will be used by those we hate. Much like the principle of free speech, which is meaningless unless it applies to speech that we don’t like, Bitcoin’s open access would be meaningless if it only applied to transactions of which you or I approve. I will therefore assume that we do not want to be in the business of inspecting how other people structure their ledger entries any more than we want them inspecting our entries.

BIP110 proponents might say, “Sure, but that only applies to monetary entries! What about these non-monetary entries?”, but the reality is that there simply is no such distinction. Every transaction made on Bitcoin is made by satisfying the conditions of some locking script to make an entry in the ledger, which consumes input coins and creates output coins. The fact that one transaction’s scripts are larger or smaller than another is of no relevance to me as a Bitcoin node operator or user. First, I simply do not look at other people’s transactions. They’re no more my business than other people’s orders at the local café. Second, my node makes no such distinction. Transactions are either valid or invalid, and they are either costly to validate (like a large multisig) or cheap to validate (like one of these Ordinals or OP_RETURNs).

One could argue that Bitcoin, like gold, would be a superior monetary asset if it could not also be looked at in other ways. Imagine if gold could not be used in industry or jewelry! It might be true that that would make it better as money. But of course, the very same properties that make gold good money also make it desirable in jewelry and industry. The same applies to Bitcoin. The very fact that Bitcoin allows anyone to make an entry if they are willing to pay the fees means that we must give up the idea that we can control how they will look at that entry. No matter what restrictions we put on the structure of the entries, it will always be possible to make entries that can be interpreted in other ways by non-Bitcoin software. So, both with Bitcoin and with gold, we accept that other use is inevitable. In gold, this leads to distortions in the market when non-monetary demand increases or decreases. In Bitcoin, this can lead to periods of higher transaction fees when there’s greater demand for its limited blockspace.

In Bitcoin, we have two advantages that gold does not have. First, making Bitcoin transactions that can be viewed in alternative ways does not affect the market for Bitcoin itself. Unlike gold, very little Bitcoin is allocated to these uses. Second, in Bitcoin, we have a protocol that is already designed to minimize cost to the validation network from such other interpretations. Bitcoin limits both the size of blocks and the number of signatures that can be used in transactions. These are the greatest costs to validating nodes, and the protocol limits on them have been in place since the very early days of Bitcoin, precisely to prevent abuse by any high-frequency or high-volume use of the ledger. These limits have already spurred innovations such as the Lightning Network, Ark, Spark, Cashu, and many more. Even the boom in demand for blockspace caused by these “non-monetary” ledger entries (yes, that does sound ridiculous) has increased the use of these scaling solutions, which require fewer entries on the main ledger.

With the justification for BIP110 thus explored, and hopefully shown to be woefully lacking, let’s look at the proposed change itself. BIP110 restricts the size of locking scripts, restricts the number of alternative scripts in taproot, makes the taproot annex invalid, removes all upgradable witness and tapscript versions, removes all tapscript upgradable opcodes, and makes OP_IF and OP_NOTIF invalid in tapscript. All of these restrictions apply to UTXOs created during the 52414 blocks (approximately 1 year) after its activation. BIP110 also proposes a miner readiness signaling threshold of 55% instead of the threshold used in prior miner signaled softforks of 90% or more. If 55% of blocks do not signal readiness before block 961632, nodes enforcing BIP110 will treat blocks not signaling readiness as invalid to force the change to lock in by block 963648 and activate by block 965664.

BIP110 would be the most sweeping restriction of Bitcoin script since Satoshi’s well-known deactivation of many opcodes in response to a critical vulnerability (CVE-2010-5137) back in 2010. It proposes miner signaled activation with an unprecedentedly low threshold and node-forced activation after less than 9 months from the date the BIP was assigned a number. It does all of this because (as discussed above) other people are viewing certain ledger entries in ways which the BIP110 supporters do not approve of. Worse yet, the folks who use such disapproved ledger entries have already updated their software to continue making such entries even if BIP110 were to become Bitcoin’s consensus rule set. This was, of course, a predictable outcome (many of us explicitly predicted it) because it is fundamentally impossible to restrict how other people use external software to analyze entries on an open-access public ledger.

In summary, BIP110 is a proposal to do something impossible (limit how users of an open access ledger use that ledger) in response to a problem that is already fully addressed through Bitcoin’s existing protocol limits. It proposes to do this impossible thing on an irresponsibly short activation timeline, with incredibly limited code review, and regardless of whether the change reaches any type of ecosystem consensus. Fortunately, Bitcoin is not such a delicate flower of a system that such a foolhardy attempt at modifying it will succeed. Not only have miners soundly rejected BIP110, but other voices throughout the developer, investor, influencer, and corporate landscape have spoken out against the changes.  In August, this particular attack against Bitcoin’s consensus rules will have made Bitcoin stronger through its failure, and the network will continue its steady rhythm of tick-tock, next block.

This post The Bitcoin Softfork That Tried to Police “Junk Data” — And Why It’s Already Failing first appeared on Bitcoin Magazine and is written by Brandon Black.

❌