Pindar Wong [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-25 📝 Original message:Thank you very much Mark ...
📅 Original date posted:2015-06-25
📝 Original message:Thank you very much Mark and Warren this is most helpful.
Regards,
p.
On Thu, Jun 25, 2015 at 2:16 PM, Warren Togami Jr. <wtogami at gmail.com>
wrote:
> https://github.com/pstratem/bitcoin/commits/testnet4
>
> See these two commits for an example of changing all the testnet chain
> parameters to create an entirely separate testnet network. This example
> "testnet4" changed to different port numbers, pchMessageStart magic, and
> with stupid large block sizes.
>
> http://rusty.ozlabs.org/?p=509
> Rusty used this to test block propagation latency.
>
> On Wed, Jun 24, 2015 at 11:06 PM, Pindar Wong <pindar.wong at gmail.com>
> wrote:
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/51c533b1/attachment-0001.html>;
📝 Original message:Thank you very much Mark and Warren this is most helpful.
Regards,
p.
On Thu, Jun 25, 2015 at 2:16 PM, Warren Togami Jr. <wtogami at gmail.com>
wrote:
> https://github.com/pstratem/bitcoin/commits/testnet4
>
> See these two commits for an example of changing all the testnet chain
> parameters to create an entirely separate testnet network. This example
> "testnet4" changed to different port numbers, pchMessageStart magic, and
> with stupid large block sizes.
>
> http://rusty.ozlabs.org/?p=509
> Rusty used this to test block propagation latency.
>
> On Wed, Jun 24, 2015 at 11:06 PM, Pindar Wong <pindar.wong at gmail.com>
> wrote:
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/51c533b1/attachment-0001.html>;