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.
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.
Here, there are a couple of points to keep in mind:
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.
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.
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.
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.
Disclosure: CoinDesk is a subsidiary of Digital Currency Group, which acted as organizer for the SegWit2x proposal and has an ownership stake in Blockstream.Â
Bitcoins on computer chips image via Shutterstock