Milly Bitcoin [ARCHIVE] on Nostr: ð Original date posted:2015-06-25 ð Original message:The more specific answer ...
ð
Original date posted:2015-06-25
ð Original message: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 <mark at friedenbach.org> 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
> <milly at bitcoins.info <mailto:milly at bitcoins.info>> 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
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150624/db6e451a/attachment-0001.html>;
ð Original message: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 <mark at friedenbach.org> 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
> <milly at bitcoins.info <mailto:milly at bitcoins.info>> 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
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150624/db6e451a/attachment-0001.html>;