<blockquote>
  <p>Who does make the decision which feature of bitcoin to include?</p>
</blockquote>

<p>The Bitcoin Core developers, particularly the ones with commit access, make the ultimate decision about what features to add to Bitcoin Core---but they do listen to community feedback, particularly polite and knowledgeable comments left on GitHub pull requests.</p>

<blockquote>
  <p>What will be the procedure of voting (who and how) would decide whether or not to include Sidechains?</p>
</blockquote>

<p>Sidechains will initially be introduced as federated sidechains, which is described in Appendix A of the <a href="http://blockstream.com/sidechains.pdf" rel="nofollow">sidechains paper</a>.  Federated sidechains don't require any changes to Bitcoin Core or the protocol, so there will be no voting.</p>

<p>Merged-mined (DMMS) side chains can be added as a <a href="https://bitcoin.org/en/developer-guide#term-soft-fork" rel="nofollow">soft fork</a>.  If this is done the same way as the <a href="https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki" rel="nofollow">BIP34 soft fork</a> or the upcoming <a href="https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki" rel="nofollow">BIP66 soft fork</a>, it'll be miners that vote.  They'll cast their vote by upgrading to the version of Bitcoin Core that includes the new SPV-proof redesignated op code.</p>

<p>However, the only-let-miners-vote method is mainly intended for non-controversial forks.  (We need miners to vote, because only they can enforce a consensus rule change (fork) in a minimally-disruptive way.)  If adding the SPV proof op code is controversial, we'll probably need to do something different to ensure minimal disruption.  (See point below.)</p>

<blockquote>
  <p>Does the participant nodes (roughly more than 6300) vote as well?</p>
</blockquote>

<p>They <em>can</em>.  Each node <em>independently</em> verifies each block on the block chain, giving them the power to enforce or not enforce any rule they want.  For example, if you don't like the upcoming BIP66 soft fork, you can modify the code of your node to reject all version 3 blocks.</p>

<p>If you do this by yourself, it'll likely mean that your node will never accept another block again since everyone else is on a chain that includes version 3 blocks.  It'll also mean that people won't want to connect to your node because your node looks like it has fallen behind everyone else.</p>

<p>But if a lot of node operators make that same decision to reject version 3 blocks, it'll become confusing about what's going on.  And if a few miners join you, you'll have a forked block chain, which will create more confusion.</p>

<p>During the confusion, it'll be hard to tell who controls what bitcoins, and double spends may become easy.  This makes Bitcoin unreliable, and nobody wants to use an unreliable financial system---which is why we work very hard to avoid creating such confusion.  That's why the only-miners-vote system is only used for non-controversial forks.</p>

<p>It's my guess that Greg, Adam, and the rest of the Blockstream co-founders plan to use federated sidechains to introduce us all to two-way pegs so that we can see what they do.  Then, as we become comfortable with them and begin want the additional benefit of distributed trust from merged mining, we can work through any controversy surrounding adding an SPV proof op code.</p>

CC BY-SA 3.0
2015-02-05T03:47:38.573Z
2015-02-05T03:47:38.573Z
David A. Harding
<p>The actual stated development process can be found <a href="https://en.bitcoin.it/wiki/Development_process" rel="nofollow">here</a>. That said, there's become a rule where enough core developers need to "ACK" it like seen in this <a href="https://github.com/bitcoin/bitcoin/pull/5286" rel="nofollow">pull request</a>.</p>

<p>Will there be a procedure for voting? If core devs feel it is <code>safe, tested, useful, well written, match coding style, etc.</code> then it gets merged into bitcoin. This is usually not easy and the <a href="http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/" rel="nofollow">bitcoin development archives</a> and the <a href="https://github.com/bitcoin/bitcoin/pulls?q=is%3Apr+is%3Aclosed" rel="nofollow">numerous pull requests</a> that haven't made any headway should make this obvious.</p>

<p>Will Sidechains get in? The big thing to note about sidechains is that at least a few of the core developers are actively working on it. This means they're going to try their hardest to get it in. So there's a better chance than most features people usually propose.</p>

<p>Do nodes vote? They can, of course, refuse to upgrade their bitcoin client to the new version that has sidechains, for example. That's entirely their choice. But actual getting into the bitcoind code, they do not vote on. People can and do, fork bitcoin and use that as their node (Luke-Jr and Eligius being the most prominent example)</p>

CC BY-SA 3.0
2015-02-05T01:30:07.100Z
2015-02-05T01:30:07.100Z
Jimmy Song
<p>I'm just watching <a href="https://www.youtube.com/watch?v=jE_elgnIw3M" rel="nofollow">Adam Back &amp; Gregory Maxwell: Blockstream and Sidechains</a> interview, and wondering how the decision of further Bitcoin core development are made. I know about Bitcoin Foundation, but I do not think that board members represent majority of voting power, when it comes to decision making for bitcoin core development, altough there are some core development members.</p>

<p>Who does make the decision which feature of bitcoin to include?</p>

<p>What will be the procedure of voting (who and how) would decide whether or not to include Sidechains?</p>

<p>Does the participant nodes (roughly more than 6300) vote as well?</p>

<nodes><bitcoin-core-development><sidechains><bitcoin-foundation><voting>
Bitcoin nodes voting
Marek
# Bitcoin nodes voting

(Asked by: username_0 on 2015-02-05)

I'm just watching [Adam Back & Gregory Maxwell: Blockstream and Sidechains](https://www.youtube.com/watch?v=jE_elgnIw3M) interview, and wondering how the decision of further Bitcoin core development are made. I know about Bitcoin Foundation, but I do not think that board members represent majority of voting power, when it comes to decision making for bitcoin core development, altough there are some core development members.

Who does make the decision which feature of bitcoin to include?

What will be the procedure of voting (who and how) would decide whether or not to include Sidechains?

Does the participant nodes (roughly more than 6300) vote as well?

**Tags:** nodes, bitcoin-core-development, sidechains, bitcoin-foundation, voting


---

## 2 answers

### Answer by username_1 on 2015-02-05. Score: 2 | Accepted answer

> Who does make the decision which feature of bitcoin to include?

The Bitcoin Core developers, particularly the ones with commit access, make the ultimate decision about what features to add to Bitcoin Core---but they do listen to community feedback, particularly polite and knowledgeable comments left on GitHub pull requests.

> What will be the procedure of voting (who and how) would decide whether or not to include Sidechains?

Sidechains will initially be introduced as federated sidechains, which is described in Appendix A of the [sidechains paper](http://blockstream.com/sidechains.pdf). Federated sidechains don't require any changes to Bitcoin Core or the protocol, so there will be no voting.

Merged-mined (DMMS) side chains can be added as a [soft fork](https://bitcoin.org/en/developer-guide#term-soft-fork). If this is done the same way as the [BIP34 soft fork](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki) or the upcoming [BIP66 soft fork](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki), it'll be miners that vote. They'll cast their vote by upgrading to the version of Bitcoin Core that includes the new SPV-proof redesignated op code.

However, the only-let-miners-vote method is mainly intended for non-controversial forks. (We need miners to vote, because only they can enforce a consensus rule change (fork) in a minimally-disruptive way.) If adding the SPV proof op code is controversial, we'll probably need to do something different to ensure minimal disruption. (See point below.)

> Does the participant nodes (roughly more than 6300) vote as well?

They *can*. Each node *independently* verifies each block on the block chain, giving them the power to enforce or not enforce any rule they want. For example, if you don't like the upcoming BIP66 soft fork, you can modify the code of your node to reject all version 3 blocks.

If you do this by yourself, it'll likely mean that your node will never accept another block again since everyone else is on a chain that includes version 3 blocks. It'll also mean that people won't want to connect to your node because your node looks like it has fallen behind everyone else.

But if a lot of node operators make that same decision to reject version 3 blocks, it'll become confusing about what's going on. And if a few miners join you, you'll have a forked block chain, which will create more confusion.

During the confusion, it'll be hard to tell who controls what bitcoins, and double spends may become easy. This makes Bitcoin unreliable, and nobody wants to use an unreliable financial system---which is why we work very hard to avoid creating such confusion. That's why the only-miners-vote system is only used for non-controversial forks.

It's my guess that Greg, Adam, and the rest of the Blockstream co-founders plan to use federated sidechains to introduce us all to two-way pegs so that we can see what they do. Then, as we become comfortable with them and begin want the additional benefit of distributed trust from merged mining, we can work through any controversy surrounding adding an SPV proof op code.


---

### Answer by username_2 on 2015-02-05. Score: 2

The actual stated development process can be found [here](https://en.bitcoin.it/wiki/Development_process). That said, there's become a rule where enough core developers need to "ACK" it like seen in this [pull request](https://github.com/bitcoin/bitcoin/pull/5286).

Will there be a procedure for voting? If core devs feel it is `safe, tested, useful, well written, match coding style, etc.` then it gets merged into bitcoin. This is usually not easy and the [bitcoin development archives](http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/) and the [numerous pull requests](https://github.com/bitcoin/bitcoin/pulls?q=is%3Apr+is%3Aclosed) that haven't made any headway should make this obvious.

Will Sidechains get in? The big thing to note about sidechains is that at least a few of the core developers are actively working on it. This means they're going to try their hardest to get it in. So there's a better chance than most features people usually propose.

Do nodes vote? They can, of course, refuse to upgrade their bitcoin client to the new version that has sidechains, for example. That's entirely their choice. But actual getting into the bitcoind code, they do not vote on. People can and do, fork bitcoin and use that as their node (Luke-Jr and Eligius being the most prominent example)


---

