public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mark Friedenbach <mark@friedenbach.org>
To: Pindar Wong <pindar.wong@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Process and Votes
Date: Wed, 24 Jun 2015 23:15:38 -0700	[thread overview]
Message-ID: <CAOG=w-vRSkY_tDHQhwbcSC8P5EJZn4Xpj+dKqV9GL26v-p5DQw@mail.gmail.com> (raw)
In-Reply-To: <CAM7BtUqpmELVnQh9JycjxK0dOn4hqsg6Csz7za55BgYyw+FG7g@mail.gmail.com>

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

You don't need to ask permission for testnet. Here is one with 100MB blocks:

https://github.com/pstratem/bitcoin/tree/testnet4
On Jun 24, 2015 11:06 PM, "Pindar Wong" <pindar.wong@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@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
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

  reply	other threads:[~2015-06-25  6:15 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
2015-06-25  6:15             ` Mark Friedenbach [this message]
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='CAOG=w-vRSkY_tDHQhwbcSC8P5EJZn4Xpj+dKqV9GL26v-p5DQw@mail.gmail.com' \
    --to=mark@friedenbach.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pindar.wong@gmail.com \
    /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