public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Pindar Wong <pindar.wong@gmail.com>
To: Milly Bitcoin <milly@bitcoins.info>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Process and Votes
Date: Thu, 25 Jun 2015 14:06:09 +0800	[thread overview]
Message-ID: <CAM7BtUqpmELVnQh9JycjxK0dOn4hqsg6Csz7za55BgYyw+FG7g@mail.gmail.com> (raw)
In-Reply-To: <558B9484.1030803@bitcoins.info>

[-- Attachment #1: Type: text/plain, Size: 8900 bytes --]

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@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@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@bitcoins.info>
>> milly@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@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> _______________________________________________
> bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 18321 bytes --]

  reply	other threads:[~2015-06-25  6:06 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-24 23:41 [bitcoin-dev] BIP Process and Votes Raystonn
2015-06-24 23:49 ` Jeff Garzik
2015-06-25  0:11   ` Bryan Bishop
2015-06-25  0:21   ` Milly Bitcoin
2015-06-25  0:07 ` Milly Bitcoin
2015-06-25  1:50   ` Mark Friedenbach
2015-06-25  2:30     ` Alex Morcos
2015-06-25  2:34     ` Milly Bitcoin
2015-06-25  5:07       ` Jeff Garzik
2015-06-25  5:41         ` Milly Bitcoin
2015-06-25  6:06           ` Pindar Wong [this message]
2015-06-25  6:15             ` Mark Friedenbach
2015-06-25  6:16             ` Warren Togami Jr.
2015-06-25  6:27               ` Pindar Wong
2015-06-25  7:51         ` cipher anthem
2015-06-25 10:09           ` nxtchg
2015-06-25 12:42           ` Milly Bitcoin
2015-06-25 20:05     ` Tier Nolan
2015-06-26  0:42       ` Milly Bitcoin
2015-07-01 22:34         ` odinn
2015-06-25  3:42   ` Gareth Williams
2015-06-25  4:10     ` Milly Bitcoin
2015-06-25 13:36   ` s7r
2015-06-25 13:41     ` Eric Lombrozo
2015-06-25 13:51       ` s7r
2015-06-25 14:08       ` Milly Bitcoin
2015-06-25 17:03       ` Jeff Garzik
2015-06-25 17:29         ` Milly Bitcoin
2015-06-25  0:18 Raystonn
2015-06-25  3:00 Raystonn
2015-06-25  3:19 ` Milly Bitcoin
2015-06-26 11:13   ` Jorge Timón
2015-06-26 12:34     ` Milly Bitcoin
2015-06-27 11:28       ` Jorge Timón
2015-06-27 12:50         ` Milly Bitcoin
2015-06-28 12:30           ` Jorge Timón
2015-06-28 13:13             ` Milly Bitcoin
2015-06-28 15:35               ` Jorge Timón
2015-06-28 16:23                 ` Milly Bitcoin
2015-06-28 19:05                   ` Patrick Murck
2015-06-28 20:10                     ` Milly Bitcoin
2015-06-28 20:16                       ` Mark Friedenbach
2015-06-28 20:26                         ` Ricardo Filipe
2015-06-28 21:00                           ` Adam Back
2015-06-29  0:13                             ` Milly Bitcoin
2015-06-29  0:23                               ` Andrew Lapp
2015-06-29  1:11                                 ` Milly Bitcoin
2015-06-28 23:52                         ` Milly Bitcoin
2015-06-28 20:21                     ` NxtChg
2015-06-25 19:03 ` Tom Harding
2015-06-25  3:53 Raystonn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAM7BtUqpmELVnQh9JycjxK0dOn4hqsg6Csz7za55BgYyw+FG7g@mail.gmail.com \
    --to=pindar.wong@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=milly@bitcoins.info \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox