Pindar Wong [ARCHIVE] on Nostr: š Original date posted:2015-06-25 š Original message:In the process of 'mining ...
š
Original date posted:2015-06-25
š Original message:In the process of 'mining consensus', perhaps before voting there should be
robust system testing and telemetry.
May I ask a questions w.r.t. Process BIPs, what is the process for
establishing a new testnet (e.g. for testing with 8MB blocks)?
p.
On Thu, Jun 25, 2015 at 1:41 PM, Milly Bitcoin <milly at bitcoins.info> wrote:
> These are the kind of silly responses you often get when this subject
> comes up. Mr. Garzik knows how to ignore messages he doesn't want so I see
> no need for him to use the list to attack people he doesn't agree with
> and/or try to interfere with discussions of others on the list.
> He turns it into a personality discussion rather than a discussion of
> Systems Engineering. He also tries to intimate anyone who brings up the
> discussion and "punish" them as a lesson to anyone else who may raise the
> issue.
>
> It is interesting that people like that are attracted to a decentralized
> system. The reply is simply an attempt at protecting turf which is why
> Mr. Garzik's vague replies are never taken seriously on the subject of
> decision-making process for the software.
>
> Russ
>
>
>
> On 6/25/2015 1:07 AM, Jeff Garzik wrote:
>
> Ladies & gents, please do not feed the troll. This has been explained to
> Milly multiple times in the past, on previous mailing list & github with no
> impact.
>
>
> On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly at bitcoins.info>
> wrote:
>
>> I'm sorry but that is the kind of defensive, cultish response everyone
>> gets when they ask that question. If you had a well constructed documented
>> process then you would be able to point to it ... but you can't. While
>> there are a few bits and pieces scattered about in different places there
>> is no coherent plan or process.
>>
>> It is easy to make statements like "consensus must be unanimous" but the
>> issue is that you never have true 100% consensus yet you have to move
>> forward in some fashion and everyone has to run software with the same
>> consensus rules. The issue is how you move forward is the question that
>> nobody wants to answer because (a) it is a hard question to answer and (b)
>> developers see it as a threat to their authority/position. If people just
>> keep shutting down the discussion with a bunch of cultish stock answers
>> then you are never going to move forward with developing some kind of
>> process.
>>
>> From what I can see much of the discussion is personality-driven and not
>> based on Computer Science or and defined process. The issue is that a
>> personality has changed so the process is perceived to be different and
>> some people want to hard fork. Previously, the cultish answer is that
>> Bitcoin development is decentralized because people can fork the code. Now
>> that some developers want to fork the code suddenly it is a big problem.
>> Is forking the code part of the consensus process or is it the work of the
>> devil? The fact that there is so much diverse opinion on this shows a
>> defined process has never been fully vetted or understood.
>>
>> I have worked on these processes for many years for projects orders of
>> magnitudes larger than Bitcoin. I can absolutely assure you the current
>> mishmash does not scale and huge amounts of time are wasted. That should
>> be readily apparent from the recent discussions and the recent concern it
>> has caused from people outside the developer's inner circle.
>>
>> Lack of defined process = high risk and wasted effort.
>>
>> Russ
>>
>>
>>
>>
>>
>> On 6/24/2015 9:50 PM, Mark Friedenbach 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>
>> 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
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> _______________________________________________
> bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> 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/20150625/1f890e9e/attachment-0001.html>;
š Original message:In the process of 'mining consensus', perhaps before voting there should be
robust system testing and telemetry.
May I ask a questions w.r.t. Process BIPs, what is the process for
establishing a new testnet (e.g. for testing with 8MB blocks)?
p.
On Thu, Jun 25, 2015 at 1:41 PM, Milly Bitcoin <milly at bitcoins.info> wrote:
> These are the kind of silly responses you often get when this subject
> comes up. Mr. Garzik knows how to ignore messages he doesn't want so I see
> no need for him to use the list to attack people he doesn't agree with
> and/or try to interfere with discussions of others on the list.
> He turns it into a personality discussion rather than a discussion of
> Systems Engineering. He also tries to intimate anyone who brings up the
> discussion and "punish" them as a lesson to anyone else who may raise the
> issue.
>
> It is interesting that people like that are attracted to a decentralized
> system. The reply is simply an attempt at protecting turf which is why
> Mr. Garzik's vague replies are never taken seriously on the subject of
> decision-making process for the software.
>
> Russ
>
>
>
> On 6/25/2015 1:07 AM, Jeff Garzik wrote:
>
> Ladies & gents, please do not feed the troll. This has been explained to
> Milly multiple times in the past, on previous mailing list & github with no
> impact.
>
>
> On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly at bitcoins.info>
> wrote:
>
>> I'm sorry but that is the kind of defensive, cultish response everyone
>> gets when they ask that question. If you had a well constructed documented
>> process then you would be able to point to it ... but you can't. While
>> there are a few bits and pieces scattered about in different places there
>> is no coherent plan or process.
>>
>> It is easy to make statements like "consensus must be unanimous" but the
>> issue is that you never have true 100% consensus yet you have to move
>> forward in some fashion and everyone has to run software with the same
>> consensus rules. The issue is how you move forward is the question that
>> nobody wants to answer because (a) it is a hard question to answer and (b)
>> developers see it as a threat to their authority/position. If people just
>> keep shutting down the discussion with a bunch of cultish stock answers
>> then you are never going to move forward with developing some kind of
>> process.
>>
>> From what I can see much of the discussion is personality-driven and not
>> based on Computer Science or and defined process. The issue is that a
>> personality has changed so the process is perceived to be different and
>> some people want to hard fork. Previously, the cultish answer is that
>> Bitcoin development is decentralized because people can fork the code. Now
>> that some developers want to fork the code suddenly it is a big problem.
>> Is forking the code part of the consensus process or is it the work of the
>> devil? The fact that there is so much diverse opinion on this shows a
>> defined process has never been fully vetted or understood.
>>
>> I have worked on these processes for many years for projects orders of
>> magnitudes larger than Bitcoin. I can absolutely assure you the current
>> mishmash does not scale and huge amounts of time are wasted. That should
>> be readily apparent from the recent discussions and the recent concern it
>> has caused from people outside the developer's inner circle.
>>
>> Lack of defined process = high risk and wasted effort.
>>
>> Russ
>>
>>
>>
>>
>>
>> On 6/24/2015 9:50 PM, Mark Friedenbach 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>
>> 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
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> _______________________________________________
> bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> 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/20150625/1f890e9e/attachment-0001.html>;