Why Are Miners Involved in Bitcoin Code Changes Anyway?

Jul 28, 2017 at 15:05 UTC by Alyssa Hertig

Developers, startups, miners ... all have played a role in bitcoin's technical debates. But if you've been following, you may have noticed the attention being paid to whether miners are "signaling" for various proposals.

Before we dive into what that means, it helps to understand that the term "miners" actually relates to a diverse group of people.

First, all miners develop, build or deploy the specialized computers designed to compete (or help others compete) for network rewards, and in the process, help move bitcoins from person to person. The role may sound mundane, but there are concerns that miners have, or may one day have, too much power over network decision-making.

Since some argue that it was originally envisioned that every bitcoin user would help secure the network – as opposed to massive companies – miners have long been the subject of the less-than-trusting imaginations of the network's users and security-conscious developers.

With just about 20 mining pools out there, some controlling large chunks of the underlying computer power, there are long-held fears that they could potentially conspire to attack the network and, as a result, reduce confidence in bitcoin as a secure and stable online currency.

Complicating matters is that, over time, miners have also developed a secondary role: helping bitcoin add new technical features. And, similarly, users have grown to worry that this position could be abused.

Indeed, you could argue that the group contributed to recent uncertainty about bitcoin's future. With several competing proposals on the table, there were many different ways this summer's code changes could have unfolded, and miners were integral to each.

At points, it even felt like their approval of the change was the sole thing keeping bitcoin from splitting into two competing blockchains. (It's worth noting that some miners might even end up doing just that).

This game was on full display last week when mining pools began signaling support for an upgrade earlier than expected. One mining pool began embedding information in blocks indicating it would follow through on an action, then a flood of others joined. It wasn't long before all miners were on board.

Users cheered on social media while keeping track of the blocks left to upgrade by refreshing tracker pages – at least, until the page stopped loading due to overwhelming traffic.

It was a relief. It looked like a split had been all but avoided following a long period of uncertainty.

Explaining upgrades

Like all software, bitcoin needs to make upgrades to fix problems or to add new features. However, in bitcoin's case, the entire distributed network needs to stay in sync.

One way to upgrade the software is what's known as a "soft fork," one way to change the rules that keep all the nodes in the network in agreement.

Soft forks are backwards-compatible changes that don't require all nodes to upgrade. As such, users can "opt-in" to the new rules. Node versions from years ago can be used to send money to upgraded nodes, even though they don't follow these new rules.

Now, nodes might not need to upgrade, but at least some mining pools do.

Think of it this way: Mining pools are the ones who mine new blocks of transactions, so they need to accept and follow the new rules in order that the new types of blocks and transactions can actually be added to the blockchain.

Supporting the change

Here, there are a couple of points to keep in mind:

For the soft fork to avoid splitting bitcoin into two assets, at least 51 percent of bitcoin's mining hashrate needs to support the change. Otherwise it will be the "shortest" chain with less computing power and its blocks will be rejected by the rest of the mining pools.
It’s hard to know how many mining pools have upgraded to support the change, since it’s not information.
The more miners that support the soft fork, the better. This diminishes the likelihood of certain attacks and network disruption as mining pools shift to the new rules.
In some cases, such as the code change P2SH, this shift to the new soft fork rules occurred via a "flag day," also known as a "user-activated soft fork" (UASF).

A UASF works like this: Developers, nodes and businesses, set a "day" (actually a block number) that's, say, six months or a year into the future. At that time, upgraded nodes will enforce the new rules and reject blocks that don't support them.

In theory, mining pools will generally opt to upgrade for fear of losing the block rewards that come with enforcing the rules and adding blocks (worth about $33,000 today).

However, this process hasn't been trouble-free. Some miners haven't been properly prepared in the past, and have lost block rewards in the process.

Because of this, developers developed a system that requires 95 percent of bitcoin's miners to "signal" that they are prepared for the change. (The second iteration of this idea, which allows for multiple soft forks to be deployed at once, is Bitcoin Improvement Proposal (BIP) 9.)

That's why bitcoin mining pools have signaled for soft fork upgrades for the past several years.

Clash of code

A few recent competing scaling proposals have involved mining pools.

Most take the form of what's called a Bitcoin Improvement Proposal (BIP), and there are many that have been in a state of flux of late. Some even rely on each other in order to bring about changes.

BIP 141, created by developers for users and miners seeks to introduce Segregated Witness (SegWit), uses BIP 9. BIP 141's rules require 95 percent of mining pools to signal support for SegWit before activating the change.

But, unlike older changes, most mining pools didn’t signal support for BIP 141. It stalled at 30 percent of miner support for a while. Some mining pools indicated they did so to negotiate for a 2MB block size parameter increase. Others suggested that some mining pools had an incentive to "block" the change to make more money.

(Interestingly, this "veto power" is a possibility that some developers raised much earlier.)

Some in the community were not happy that SegWit stalled, believing that BIP 141 would improve bitcoin and that mining pools were overstepping their job description. So, in the hopes of pushing SegWit through, many users and developers rallied around the older "flag day" concept, since it doesn't require the "approval" of mining pools.

The proposal, BIP 148, is slated for August 1. A majority of mining pools would need to support the change, for the reasons described above.

BIP 91 was ultimately perceived as a sort of compromise between those two changes, one that kept miners in the driver's seat.

The BIP 9 dilemma

While BIP 9 is a recently-introduced mechanism for making upgrades to bitcoin, some developers already want to get rid of it.

Some claim it was intended as a way of protecting miners – so they wouldn't lose their block rewards if a soft fork went through and their blocks were rejected by the rest of miners.

Like some users, some developers don't like that mining pools used the signaling mechanism as a way to stop code changes that otherwise had broad agreement from bitcoin users.

Blockstream developer Rusty Russell, a former Linux kernel developer and one of the creators of BIP 9, went as far as to publicly apologize for his role in creating this possibility.

"I hadn't expected that this checkpoint would be used as a chokepoint to ransom the network," he added before advocating for a UASF.

Future outlook

Given this controversy, what role will miners play in upgrading bitcoin down the road?

It's unclear. BIP 9 had wide support from developers before it prompted political disagreements.

Some developers still seem to favor so-called "miner-activated soft forks" as a less disruptive option, but now some developers, such as Russell, seem more inclined to advocate for UASFs.

So, perhaps both options will be on the table for future upgrades.

Whatever the case, miners are important players who will continue to have some influence in future bitcoin code changes.

Source: https://www.coindesk.com/miners-involved-bitcoin-code-changes-anyway/