The more specific answer (from a user's perspective) is that there is
unanimous approval within the constraints of the Bitcoin system. The
constraint is that your software must be compatible with merchants and
exchanges for your coins to have value. Stating "unanimous approval"
without identifying the constraint is misstating the issue.
As for developers, the consensus on code changes are almost never 100%
and someone has to make the decision about what is an a acceptable
consensus. Most of the cultish answers completely overlook this issue
even though it is main point of the question.
Russ
On 6/24/2015 11:00 PM, Raystonn wrote:
> Consensus-code changes are unanimous. They must be.
Excellent. Now we are getting to some actual written rules. How about
updating the BIP process documentation with this? Everyone should be
able to read the rules of the coin they are buying.
One moment though. Can you tell me how this particular rule came to
be? The creator of Bitcoin violated this rule many times. So it must
have been adopted after his departure. What process was followed to
adopt this new rule? Was there consensus for it at the time? A huge
portion of the user community is under the impression that Satoshi's
written plans, some of which violate this new rule, will be
implemented. So there certainly would not be consensus for this rule
today.
On 24 Jun 2015 6:51 pm, Mark Friedenbach <[email protected]> wrote:
I'm sorry but this is absolutely not the case, Milly. The reason
that people get defensive is that we have a carefully constructed
process that does work (thank you very much!) and is well
documented. We talk about it quite often in fact as it is a
defining characteristic of how bitcoin is developed which differs
in some ways from how other open source software is developed --
although it remains the same in most other ways.
Changes to the non-consensus sections of Bitcoin Core tend to get
merged when there are a few reviews, tests, and ACKs from
recognized developers, there are no outstanding objections, and
the maintainer doing the merge makes a subjective judgement that
the code is ready.
Consensus-changes, on the other hand, get merged into Bitcoin Core
only after the above criteria are met AND an extremely long
discussion period that has given all the relevant stakeholders a
chance to comment, and no significant objections remain.
Consensus-code changes are unanimous. They must be.
The sort of process that exists in standards bodies for example,
with working groups and formal voting procedures, has no place
where changes define the nature and validity of other people's
money. Who has the right to reach into your pocket and define how
you can or cannot spend your coins? The premise of bitcoin is that
no one has that right, yet that is very much what we do when
consensus code changes are made. That is why when we make a change
to the rules governing the nature of bitcoin, we must make sure
that everyone is made aware of the change and consents to it.
Everyone. Does this work? Does this scale? So far, it does.
Uncontroversial changes, such as BIP 66, are deployed without
issue. Every indication is that BIP 66 will complete deployment in
the very near future, and we intend to repeat this process for
more interesting changes such as BIP65: CHECKLOCKTIMEVERIFY.
This isn't about no one stepping forward to be the "decider." This
is about no one having the right to decide these things on the
behalf of others. If a contentious change is proposed and not
accepted by the process of consensus, that is because the process
is doing its job at rejecting controversial changes. It has
nothing to do with personality, and everything to do with the
nature of bitcoin itself.
On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin
<[email protected] <mailto:[email protected]>> wrote:
I have seen this question asked many times. Most developers
become defensive and they usually give a very vague 1-sentence
answer when this question is asked. It seems to be it is
based on personalities rather than any kind of definable
process. To have that discussion the personalities must be
separated out and answers like "such-and-such wouldn't do
that" don't really do much to advance the discussion. Also,
the incentive for new developers to come in is that they will
be paid by companies who want to influence the code and this
should be considered (some developers take this statement as
an insult when it is just a statement of the incentive process).
The other problem you are having is the lead developer does
not want to be a "decider" when, in fact, he is a very
significant decider. While the users have the ultimate choice
in a practical sense the chief developer is the "decider."
Now people don't want to get him upset so nobody wants to push
the issue or fully define the process. Now you are left with
a broken, unwritten/unspoken process. While this type of
thing may work with a small group of developers
businesses/investors looking in from the outside will see this
as a risk.
Until you get passed all the personality-based arguments you
are going to have a tough time defining a real process.
Russ
On 6/24/2015 7:41 PM, Raystonn wrote:
I would like to start a civil discussion on an undefined,
or at least unwritten, portion of the BIP process. Who
should get to vote on approval to commit a BIP
implementation into Bitcoin Core? Is a simple majority of
these voters sufficient for approval? If not, then what is?
Raystonn
_______________________________________________
bitcoin-dev mailing list
[email protected]
<mailto:[email protected]>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
[email protected]
<mailto:[email protected]>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
