in

A study on Bitcoin governance

Hey redditors,

we’d like to paste here a recent d.center article on **Bitcoin governance**, hope you might find it useful !

​

***Every software needs upgrades, but how do you implement them within a headless and decentralized system that is Bitcoin?***

Blockchain governance is the process by which its operating rules (transaction and block verification, signatures techniques etc) are decided upon, implemented, and improved. In Bitcoin blockchain the governance is implemented through consensus between community members. It is considered an off-chain governance, as the process itself is not inscribed into the blockchain *(see* [*Blockchain governance*](https://d.center/fr/explore/blockchain-governance)*)*.

The original Bitcoin implementation (also called *Satoshi client*) was the first version of Bitcoin protocol, integrating a wallet. First supervised by Satoshi Nakamoto himself, the protocol was then entrusted to a team of developers led by Gavin Andersen, then Wladimir J. van der Laan; since the version 0.9.0 it took the name of **Bitcoin core**. As of today, Bitcoin core is by far the most popular “client”, even if other clients exist and in the past some of them could compete with Bitcoin Core.

## Who finances Bitcoin?

Bitcoin development is finance in a decentralised manner by any person interested in its security and evolution: tech companies (Blockstream), crypto exchanges (Kraken, Coinbase), personalities of the crypto world (Meltem Demirors of CoinShares, Jack Dorsey of Twitter, Michael Saylor of MicroStrategy), asset management companies (Fidelity Digital Assets)… Donations can be sent directly to the developers or to associations, such as MIT Media Lab’s Digital Currency initiative or Bitcoin Core Sponsorship Program.

## BIP

When a person thinks that a certain protocol issue should be addressed, whether it’s correcting  a bug, adding or a new functionality or improving an existing one, they submit the idea or solution to the community. It can be a white paper or an email to *bitcoin-dev @ lists.linuxfoundation.org**.* The ideas that make sense become Bitcoin Improvement Proposals, or **BIP**s; they are assigned a number and published on Github forum. The full list of BIPs can be consulted [here](https://github.com/bitcoin/bips)*.* 

BIPs implementation can take various forms and be really complex, even in cases when the majority of the community agrees on it.

## Implementing updates

If the codebase update is incompatible with the existing protocol (not forward-compatible), all nodes have to accept it at a certain point of time. Usually it happens when there’s a need to eliminate certain security risks or add a new functionality. Those who wish to continue implementing old rules will find themselves isolated from the rest of the network and will be de facto working on another blockchain. Such implementation is called a **hard fork** and it is a way to bring important changes to the protocol, as well as to give birth to new blockchains.

When a suggested update is compatible with the existing validation rules (forward-compatible), each node can choose for itself whether it adopts the update or not (even if after some time they would have to accept the update to better perform their task). Such implementation is called a **soft fork**. 

Even if the majority of actors agree on a soft fork update, its implementation can be very complex, taking into account Bitcoin‘s decentralized nature. In the past several methods were used:

* **Miner Activated Soft Fork** (BIP9), which measures miner support for soft forks on a rolling basis. Miners “signal” their support for a protocol by leaving extra information in the block header of the blocks they submit. If more than 95% of the successfully submitted blocks show support for the new rules over a period of time, the new protocol is activated. If not, it is rejected.
* **User Activated Soft Fork** (UASF), by which a majority of the Bitcoin network signals that at a specified date (flag day) it will reject non-updated blocks by running a UASF full node. UASF contributed to a successful SegWit implementation in 2017, showing that the Bitcoin governance system is sufficiently decentralized to be able to adopt decisions that miners do not particularly support. *Learn more on different actors of the network* [*here*](https://d.center/en/explore/bitcoin-network)*.*

Even with different methods, implementation is still a complicated task, as shown by the debates around Taproot – a much expected protocol update desired by the majority of the Bitcoin community. At the time of writing the way of implementing it is still a subject of discussions, so in order to speed it up a proposal called [**Speedy Trial**](https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg09604.html) was submitted on March 5, 2021. The idea of Speedy Trial is to start early (the nodes start to count blocks that implement the update soon after its release) and end early (if the threshold of 90% is not achieved within 3 months, the activation fails). If adopted, Speedy Trial method could be used for upcoming implementations.

It is difficult to develop a decentralized protocol. Every update takes a lot of time, which potentially could have negative consequences. However it is paramount that every actor can participate in decision-making, ensuring Bitcoin independence and decentralization.

​

The original aritcle appeared here [https://d.center/explore/bitcoin-governance](https://d.center/explore/bitcoin-governance)



View Reddit by D_CenterView Source

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

GIPHY App Key not set. Please check settings

3 Comments

Loading…

0

What do you think?

MakiSwap Raises $1.4M to Build AMM Platform on Huobi Eco Chain

MakiSwap Raises $1.4M to Build AMM Platform on Huobi Eco Chain

Coinbase CEO expects 50% of the firm's revenues to come from non-trading businesses.

Coinbase CEO expects 50% of the firm’s revenues to come from non-trading businesses.