public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev]  BIP Process and Votes
@ 2015-06-24 23:41 Raystonn
  2015-06-24 23:49 ` Jeff Garzik
  2015-06-25  0:07 ` Milly Bitcoin
  0 siblings, 2 replies; 51+ messages in thread
From: Raystonn @ 2015-06-24 23:41 UTC (permalink / raw)
  To: bitcoin-dev

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

^ permalink raw reply	[flat|nested] 51+ messages in thread

• * Re: [bitcoin-dev] BIP Process and Votes
    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
    1 sibling, 2 replies; 51+ messages in thread
  From: Jeff Garzik @ 2015-06-24 23:49 UTC (permalink / raw)
    To: Raystonn; +Cc: bitcoin-dev
  
  [-- Attachment #1: Type: text/plain, Size: 923 bytes --]
  
  BIPs  are accepted into BIP repo with a low "reasonable" threshold.
  
  Code is accepted into the Bitcoin Core repo when it is likely that the
  community will accept a change.
  
  There is no voting in the way you think. Devs commit changes the users will
  accept and use. Users "fire" developers by choosing different devs or
  different software.
  
  Standard open source method.
   On Jun 24, 2015 4:41 PM, "Raystonn" <raystonn@hotmail•com> 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
  >
  
  [-- Attachment #2: Type: text/html, Size: 1431 bytes --]
  
  ^ permalink raw reply	[flat|nested] 51+ messages in thread

• • * Re: [bitcoin-dev] BIP Process and Votes
      2015-06-24 23:49 ` Jeff Garzik
    @ 2015-06-25  0:11   ` Bryan Bishop
      2015-06-25  0:21   ` Milly Bitcoin
      1 sibling, 0 replies; 51+ messages in thread
    From: Bryan Bishop @ 2015-06-25  0:11 UTC (permalink / raw)
      To: Jeff Garzik, Bryan Bishop; +Cc: bitcoin-dev
    
    [-- Attachment #1: Type: text/plain, Size: 799 bytes --]
    
    On Wed, Jun 24, 2015 at 6:49 PM, Jeff Garzik <jgarzik@gmail•com> wrote:
    
    > There is no voting in the way you think. Devs commit changes the users
    > will accept and use. Users "fire" developers by choosing different devs or
    > different software.
    
    
    I think that statement is too weak. Users are all personally responsible
    for evaluating all rules for themselves. Many have chosen and will continue
    to choose to just keep an ear out for rule changes that they may be
    interested in using. Ever user should be educated on this topic...
    otherwise there are too many principal agent problems, even with the
    ability to "fire" developers (a.k.a "use different software"). It's similar
    to the reasons why it's important to see all the transactions on the
    network.
    
    - Bryan
    http://heybryan.org/
    1 512 203 0507
    
    [-- Attachment #2: Type: text/html, Size: 1228 bytes --]
    
    ^ permalink raw reply	[flat|nested] 51+ messages in thread

  • * Re: [bitcoin-dev] BIP Process and Votes
      2015-06-24 23:49 ` Jeff Garzik
      2015-06-25  0:11   ` Bryan Bishop
    @ 2015-06-25  0:21   ` Milly Bitcoin
      1 sibling, 0 replies; 51+ messages in thread
    From: Milly Bitcoin @ 2015-06-25  0:21 UTC (permalink / raw)
      To: Jeff Garzik, bitcoin-dev
    
     >There is no voting in the way you think. Devs commit changes the users 
    will accept and use. Users "fire" developers by choosing different devs 
    or different software.
    
     >Standard open source method.
    
    Most open source projects do not require 100% user adoption in order for 
    other users to be compatible.  Very different than most open source 
    projects.  Repeating "stock" answers does nothing to advanced the 
    discussion.
    
    Russ
    
    
    
    ^ permalink raw reply	[flat|nested] 51+ messages in thread

• * Re: [bitcoin-dev] BIP Process and Votes
    2015-06-24 23:41 [bitcoin-dev] BIP Process and Votes Raystonn
    2015-06-24 23:49 ` Jeff Garzik
  @ 2015-06-25  0:07 ` Milly Bitcoin
    2015-06-25  1:50   ` Mark Friedenbach
                       ` (2 more replies)
    1 sibling, 3 replies; 51+ messages in thread
  From: Milly Bitcoin @ 2015-06-25  0:07 UTC (permalink / raw)
    To: bitcoin-dev
  
  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
  >
  
  
  
  
  ^ permalink raw reply	[flat|nested] 51+ messages in thread

• • * Re: [bitcoin-dev] BIP Process and Votes
      2015-06-25  0:07 ` Milly Bitcoin
    @ 2015-06-25  1:50   ` Mark Friedenbach
      2015-06-25  2:30     ` Alex Morcos
                           ` (2 more replies)
      2015-06-25  3:42   ` Gareth Williams
      2015-06-25 13:36   ` s7r
      2 siblings, 3 replies; 51+ messages in thread
    From: Mark Friedenbach @ 2015-06-25  1:50 UTC (permalink / raw)
      To: Milly Bitcoin; +Cc: bitcoin-dev
    
    [-- Attachment #1: Type: text/plain, Size: 4503 bytes --]
    
    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> 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
    >
    
    [-- Attachment #2: Type: text/html, Size: 5613 bytes --]
    
    ^ permalink raw reply	[flat|nested] 51+ messages in thread

  • • * Re: [bitcoin-dev] BIP Process and Votes
        2015-06-25  1:50   ` Mark Friedenbach
      @ 2015-06-25  2:30     ` Alex Morcos
        2015-06-25  2:34     ` Milly Bitcoin
        2015-06-25 20:05     ` Tier Nolan
        2 siblings, 0 replies; 51+ messages in thread
      From: Alex Morcos @ 2015-06-25  2:30 UTC (permalink / raw)
        To: Mark Friedenbach; +Cc: bitcoin-dev
      
      [-- Attachment #1: Type: text/plain, Size: 4915 bytes --]
      
      +1 Mark!
      
      
      On Wed, Jun 24, 2015 at 9:50 PM, Mark Friedenbach <mark@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@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
      >
      >
      
      [-- Attachment #2: Type: text/html, Size: 6392 bytes --]
      
      ^ permalink raw reply	[flat|nested] 51+ messages in thread

    • * Re: [bitcoin-dev] BIP Process and Votes
        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 20:05     ` Tier Nolan
        2 siblings, 1 reply; 51+ messages in thread
      From: Milly Bitcoin @ 2015-06-25  2:34 UTC (permalink / raw)
        To: bitcoin-dev
      
      [-- Attachment #1: Type: text/plain, Size: 6993 bytes --]
      
      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 
      > <mailto: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
      >         <mailto:bitcoin-dev@lists•linuxfoundation.org>
      >         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      >
      >
      >
      >     _______________________________________________
      >     bitcoin-dev mailing list
      >     bitcoin-dev@lists•linuxfoundation.org
      >     <mailto:bitcoin-dev@lists•linuxfoundation.org>
      >     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      >
      >
      
      
      [-- Attachment #2: Type: text/html, Size: 11259 bytes --]
      
      ^ permalink raw reply	[flat|nested] 51+ messages in thread

    • • * Re: [bitcoin-dev] BIP Process and Votes
          2015-06-25  2:34     ` Milly Bitcoin
        @ 2015-06-25  5:07       ` Jeff Garzik
          2015-06-25  5:41         ` Milly Bitcoin
          2015-06-25  7:51         ` cipher anthem
          0 siblings, 2 replies; 51+ messages in thread
        From: Jeff Garzik @ 2015-06-25  5:07 UTC (permalink / raw)
          To: bitcoin-dev
        
        [-- Attachment #1: Type: text/plain, Size: 7192 bytes --]
        
        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
        >
        >
        
        [-- Attachment #2: Type: text/html, Size: 11792 bytes --]
        
        ^ permalink raw reply	[flat|nested] 51+ messages in thread

      • • * Re: [bitcoin-dev] BIP Process and Votes
            2015-06-25  5:07       ` Jeff Garzik
          @ 2015-06-25  5:41         ` Milly Bitcoin
            2015-06-25  6:06           ` Pindar Wong
            2015-06-25  7:51         ` cipher anthem
            1 sibling, 1 reply; 51+ messages in thread
          From: Milly Bitcoin @ 2015-06-25  5:41 UTC (permalink / raw)
            To: bitcoin-dev
          
          [-- Attachment #1: Type: text/plain, Size: 9174 bytes --]
          
          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 
          > <mailto: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 <mailto: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
          >>             <mailto:bitcoin-dev@lists•linuxfoundation.org>
          >>             https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
          >>
          >>
          >>
          >>         _______________________________________________
          >>         bitcoin-dev mailing list
          >>         bitcoin-dev@lists•linuxfoundation.org
          >>         <mailto:bitcoin-dev@lists•linuxfoundation.org>
          >>         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
          >>
          >>
          >
          >
          >     _______________________________________________
          >     bitcoin-dev mailing list
          >     bitcoin-dev@lists•linuxfoundation.org
          >     <mailto: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: 18162 bytes --]
          
          ^ permalink raw reply	[flat|nested] 51+ messages in thread

        • • * Re: [bitcoin-dev] BIP Process and Votes
              2015-06-25  5:41         ` Milly Bitcoin
            @ 2015-06-25  6:06           ` Pindar Wong
              2015-06-25  6:15             ` Mark Friedenbach
              2015-06-25  6:16             ` Warren Togami Jr.
              0 siblings, 2 replies; 51+ messages in thread
            From: Pindar Wong @ 2015-06-25  6:06 UTC (permalink / raw)
              To: Milly Bitcoin; +Cc: bitcoin-dev
            
            [-- 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 --]
            
            ^ permalink raw reply	[flat|nested] 51+ messages in thread

          • • * Re: [bitcoin-dev] BIP Process and Votes
                2015-06-25  6:06           ` Pindar Wong
              @ 2015-06-25  6:15             ` Mark Friedenbach
                2015-06-25  6:16             ` Warren Togami Jr.
                1 sibling, 0 replies; 51+ messages in thread
              From: Mark Friedenbach @ 2015-06-25  6:15 UTC (permalink / raw)
                To: Pindar Wong; +Cc: bitcoin-dev
              
              [-- 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 --]
              
              ^ permalink raw reply	[flat|nested] 51+ messages in thread

            • * Re: [bitcoin-dev] BIP Process and Votes
                2015-06-25  6:06           ` Pindar Wong
                2015-06-25  6:15             ` Mark Friedenbach
              @ 2015-06-25  6:16             ` Warren Togami Jr.
                2015-06-25  6:27               ` Pindar Wong
                1 sibling, 1 reply; 51+ messages in thread
              From: Warren Togami Jr. @ 2015-06-25  6:16 UTC (permalink / raw)
                To: Pindar Wong; +Cc: bitcoin-dev
              
              [-- Attachment #1: Type: text/plain, Size: 9757 bytes --]
              
              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@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: 19798 bytes --]
              
              ^ permalink raw reply	[flat|nested] 51+ messages in thread

            • • * Re: [bitcoin-dev] BIP Process and Votes
                  2015-06-25  6:16             ` Warren Togami Jr.
                @ 2015-06-25  6:27               ` Pindar Wong
                  0 siblings, 0 replies; 51+ messages in thread
                From: Pindar Wong @ 2015-06-25  6:27 UTC (permalink / raw)
                  To: Warren Togami Jr.; +Cc: bitcoin-dev
                
                [-- Attachment #1: Type: text/plain, Size: 10139 bytes --]
                
                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@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@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: 20324 bytes --]
                
                ^ permalink raw reply	[flat|nested] 51+ messages in thread

        • * Re: [bitcoin-dev] BIP Process and Votes
            2015-06-25  5:07       ` Jeff Garzik
            2015-06-25  5:41         ` Milly Bitcoin
          @ 2015-06-25  7:51         ` cipher anthem
            2015-06-25 10:09           ` nxtchg
            2015-06-25 12:42           ` Milly Bitcoin
            1 sibling, 2 replies; 51+ messages in thread
          From: cipher anthem @ 2015-06-25  7:51 UTC (permalink / raw)
            To: bitcoin-dev
          
          [-- Attachment #1: Type: text/html, Size: 10062 bytes --]
          
          ^ permalink raw reply	[flat|nested] 51+ messages in thread

        • • * Re: [bitcoin-dev] BIP Process and Votes
              2015-06-25  7:51         ` cipher anthem
            @ 2015-06-25 10:09           ` nxtchg
              2015-06-25 12:42           ` Milly Bitcoin
              1 sibling, 0 replies; 51+ messages in thread
            From: nxtchg @ 2015-06-25 10:09 UTC (permalink / raw)
              To: cipher anthem, bitcoin-dev
            
            [-- Attachment #1: Type: text/plain, Size: 359 bytes --]
            
            You just proved his point once again with yet another ad hominem :)
            
            Good job.
            
            On 6/25/2015 at 10:56 AM, "cipher anthem"  wrote:+1 on this!
             I have come across Milly a couple of times on reddit and disqus and
            she basically dismisses anyone who doesn't agree with her opinions.
            always labeling them "cultish". Please ignore her so you can stay
            productive.    
            
            [-- Attachment #2: Type: text/html, Size: 660 bytes --]
            
            ^ permalink raw reply	[flat|nested] 51+ messages in thread

          • * Re: [bitcoin-dev] BIP Process and Votes
              2015-06-25  7:51         ` cipher anthem
              2015-06-25 10:09           ` nxtchg
            @ 2015-06-25 12:42           ` Milly Bitcoin
              1 sibling, 0 replies; 51+ messages in thread
            From: Milly Bitcoin @ 2015-06-25 12:42 UTC (permalink / raw)
              To: bitcoin-dev
            
            [-- Attachment #1: Type: text/plain, Size: 9664 bytes --]
            
            "Cultish" means making claims without any supporting facts.  Labeling 
            Open Source software as being "decentralized" just because people can 
            choose which version to run is a "cultish" claim.  Just because Bitcoin 
            uses the mining process to come to consensus over the state of the 
            ledger that does not mean the software versions have the same level of 
            decentralization because users can decide which version to run. I am in 
            the USA and I can vote in elections but I would not call the US 
            government "decentralized."  It is a very complicated issue and cannot 
            be explained in one or two sentences of hand-waiving arguments like you 
            often see here.
            
            Russ
            
            
            
            
            On 6/25/2015 3:51 AM, cipher anthem wrote:
            > +1 on this!
            >
            > I have come across Milly a couple of times on reddit and disqus and 
            > she basically dismisses anyone who doesn't agree with her opinions. 
            > always labeling them "cultish". Please ignore her so you can stay 
            > productive.
            > *Sent:* Thursday, June 25, 2015 at 5:07 AM
            > *From:* "Jeff Garzik" <jgarzik@gmail•com>
            > *To:* bitcoin-dev@lists•linuxfoundation.org
            > *Subject:* Re: [bitcoin-dev] BIP Process and Votes
            > 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> 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 
            > 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: 24495 bytes --]
            
            ^ permalink raw reply	[flat|nested] 51+ messages in thread

    • * Re: [bitcoin-dev] BIP Process and Votes
        2015-06-25  1:50   ` Mark Friedenbach
        2015-06-25  2:30     ` Alex Morcos
        2015-06-25  2:34     ` Milly Bitcoin
      @ 2015-06-25 20:05     ` Tier Nolan
        2015-06-26  0:42       ` Milly Bitcoin
        2 siblings, 1 reply; 51+ messages in thread
      From: Tier Nolan @ 2015-06-25 20:05 UTC (permalink / raw)
        Cc: bitcoin-dev
      
      [-- Attachment #1: Type: text/plain, Size: 2888 bytes --]
      
      On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach <mark@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.
      >
      
      There is no process for handling hard forks, which aren't bug fixes.
      
      Soft forks have a defined process of something like
      
      - BIP proposal + discussion
      - Proposed code
      - Dev acceptance
      - Release
      - Miner vote/acceptance
      
      The devs have a weak veto.  If they refuse to move forward with changes,
      miners could perform a soft fork on their own.  They don't want to do that,
      as it would be controversial and the devs know the software better.
      
      The miner veto is stronger (for soft forks) but not absolute.  The devs
      could checkpoint/blacklist a chain if miners implemented a fork that wasn't
      acceptable (assuming the community backed them).
      
      When ASICs arrived, it was pointed out by some that the devs could hit back
      if ASICs weren't made publicly available.  If they slightly tweaked the
      hashing algorithm, then current generation of ASICs would be useless.   The
      potential threat may have acted as a disincentive for ASIC manufacturers to
      use the ASICs themselves.
      
      Moving forward with agreement between all involved is the recommended and
      desirable approach.
      
      Consensus between all parties is the goal but isn't absolutely required.
      This escape valve is partly what makes consensus work.  If you dig your
      heels in, then the other side can bypass you, but they have an incentive to
      try to convince you to compromise first.  The outcome is better if a middle
      ground can be found.
      
      Hard forks are different.  The "checks and balances" of weak vetoes are not
      present.  This means that things can devolve from consensus to mutual
      veto.  Consensus ceases to be a goal and becomes a requirement.
      
      This is partly a reflection of the nature of hard forks.  Everyone needs to
      upgrade.  On the other hand, if most of the various groups upgrade, then
      users of the legacy software would have to upgrade or get left behind.  If
      5% of the users decided not to upgrade, should they be allowed to demand
      that nobody else does?
      
      There is clearly some kind of threshold that is reasonable.
      
      The fundamental problem is that there isn't agreement on what the block
      size is.  Is it equal in status to the 21 million BTC limit?
      
      If Satoshi had said that 1MB was part of the definition of Bitcoin, then I
      think people would accept it to the same extent as they accept the 21
      million coin limit.  It might cause people to leave the coin though.
      
      It was intended to be temporary, but people have realized that it might be
      a good idea to keep it.  In effect both sides could argue that they should
      be considered the status quo.
      
      I wonder if a coin toss would be acceptable :).  "Come to an agreement or
      we decide by coin toss"
      
      [-- Attachment #2: Type: text/html, Size: 3632 bytes --]
      
      ^ permalink raw reply	[flat|nested] 51+ messages in thread

    • • * Re: [bitcoin-dev] BIP Process and Votes
          2015-06-25 20:05     ` Tier Nolan
        @ 2015-06-26  0:42       ` Milly Bitcoin
          2015-07-01 22:34         ` odinn
          0 siblings, 1 reply; 51+ messages in thread
        From: Milly Bitcoin @ 2015-06-26  0:42 UTC (permalink / raw)
          To: bitcoin-dev
        
        [-- Attachment #1: Type: text/plain, Size: 4605 bytes --]
        
        That description makes sense.  It also makes sense to separate out the 
        hard fork from the soft fork process.   Right now some people want to 
        use the soft fork procedure for a hard fork simply because there is no 
        other way to do it.
        
        I am under the impression that most users expect changes/improvements 
        that would require a hard fork so I think some kind of process needs to 
        be developed.  Taking the responsibility off the shoulder of the core 
        maintainer also makes sense.  The hard fork issue is too much of a 
        distraction for people trying to maintain the nuts and bolts of the 
        underlying system.
        
        I saw a suggestion that regularly scheduled hard forks should be 
        planned.  That seems to make sense so you would have some sort of 
        schedule where you would have cut off dates for hard-fork BIP 
        submissions.  That way you avoid the debates over whether there should 
        be hard forks to what should be contained within the hard fork (if 
        needed).  It makes sense to follow the BIP process as close as 
        possible.  Possibly adding another step after "Dev acceptance" to 
        include input from others such as merchants/exchanges/miners/users.  It 
        will only be an approximation of "decentralization" and the process 
        won't be perfect but if you want to move forward then you need some way 
        to do it.
        
        Russ
        
        
        On 6/25/2015 4:05 PM, Tier Nolan wrote:
        > On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach 
        > <mark@friedenbach•org <mailto:mark@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.
        >
        >
        > There is no process for handling hard forks, which aren't bug fixes.
        >
        > Soft forks have a defined process of something like
        >
        > - BIP proposal + discussion
        > - Proposed code
        > - Dev acceptance
        > - Release
        > - Miner vote/acceptance
        >
        > The devs have a weak veto.  If they refuse to move forward with 
        > changes, miners could perform a soft fork on their own.  They don't 
        > want to do that, as it would be controversial and the devs know the 
        > software better.
        >
        > The miner veto is stronger (for soft forks) but not absolute.  The 
        > devs could checkpoint/blacklist a chain if miners implemented a fork 
        > that wasn't acceptable (assuming the community backed them).
        >
        > When ASICs arrived, it was pointed out by some that the devs could hit 
        > back if ASICs weren't made publicly available.  If they slightly 
        > tweaked the hashing algorithm, then current generation of ASICs would 
        > be useless.   The potential threat may have acted as a disincentive 
        > for ASIC manufacturers to use the ASICs themselves.
        >
        > Moving forward with agreement between all involved is the recommended 
        > and desirable approach.
        >
        > Consensus between all parties is the goal but isn't absolutely 
        > required.  This escape valve is partly what makes consensus work.  If 
        > you dig your heels in, then the other side can bypass you, but they 
        > have an incentive to try to convince you to compromise first.  The 
        > outcome is better if a middle ground can be found.
        >
        > Hard forks are different.  The "checks and balances" of weak vetoes 
        > are not present.  This means that things can devolve from consensus to 
        > mutual veto.  Consensus ceases to be a goal and becomes a requirement.
        >
        > This is partly a reflection of the nature of hard forks.  Everyone 
        > needs to upgrade.  On the other hand, if most of the various groups 
        > upgrade, then users of the legacy software would have to upgrade or 
        > get left behind. If 5% of the users decided not to upgrade, should 
        > they be allowed to demand that nobody else does?
        >
        > There is clearly some kind of threshold that is reasonable.
        >
        > The fundamental problem is that there isn't agreement on what the 
        > block size is.  Is it equal in status to the 21 million BTC limit?
        >
        > If Satoshi had said that 1MB was part of the definition of Bitcoin, 
        > then I think people would accept it to the same extent as they accept 
        > the 21 million coin limit.  It might cause people to leave the coin 
        > though.
        >
        > It was intended to be temporary, but people have realized that it 
        > might be a good idea to keep it.  In effect both sides could argue 
        > that they should be considered the status quo.
        >
        > I wonder if a coin toss would be acceptable :).  "Come to an agreement 
        > or we decide by coin toss"
        >
        >
        > _______________________________________________
        > bitcoin-dev mailing list
        > bitcoin-dev@lists•linuxfoundation.org
        > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        
        
        [-- Attachment #2: Type: text/html, Size: 7579 bytes --]
        
        ^ permalink raw reply	[flat|nested] 51+ messages in thread

      • • * Re: [bitcoin-dev] BIP Process and Votes
            2015-06-26  0:42       ` Milly Bitcoin
          @ 2015-07-01 22:34         ` odinn
            0 siblings, 0 replies; 51+ messages in thread
          From: odinn @ 2015-07-01 22:34 UTC (permalink / raw)
            To: Milly Bitcoin, bitcoin-dev
          
          -----BEGIN PGP SIGNED MESSAGE-----
          Hash: SHA1
          
          Possibly relevant to this discussion (though old)
          
          https://gist.github.com/gavinandresen/2355445 (last changed in 2012 I
          think?)
          
          and
          
          https://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork
          (which cites gavin's gist shown above)
          
          
          
          
          
          On 06/25/2015 05:42 PM, Milly Bitcoin wrote:
          > That description makes sense.  It also makes sense to separate out
          > the hard fork from the soft fork process.   Right now some people
          > want to use the soft fork procedure for a hard fork simply because
          > there is no other way to do it.
          > 
          > I am under the impression that most users expect
          > changes/improvements that would require a hard fork so I think some
          > kind of process needs to be developed.  Taking the responsibility
          > off the shoulder of the core maintainer also makes sense.  The hard
          > fork issue is too much of a distraction for people trying to
          > maintain the nuts and bolts of the underlying system.
          > 
          > I saw a suggestion that regularly scheduled hard forks should be 
          > planned.  That seems to make sense so you would have some sort of 
          > schedule where you would have cut off dates for hard-fork BIP 
          > submissions.  That way you avoid the debates over whether there
          > should be hard forks to what should be contained within the hard
          > fork (if needed).  It makes sense to follow the BIP process as
          > close as possible.  Possibly adding another step after "Dev
          > acceptance" to include input from others such as
          > merchants/exchanges/miners/users.  It will only be an approximation
          > of "decentralization" and the process won't be perfect but if you
          > want to move forward then you need some way to do it.
          > 
          > Russ
          > 
          > 
          > On 6/25/2015 4:05 PM, Tier Nolan wrote:
          >> On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach 
          >> <mark@friedenbach•org <mailto:mark@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.
          >> 
          >> 
          >> There is no process for handling hard forks, which aren't bug
          >> fixes.
          >> 
          >> Soft forks have a defined process of something like
          >> 
          >> - BIP proposal + discussion - Proposed code - Dev acceptance -
          >> Release - Miner vote/acceptance
          >> 
          >> The devs have a weak veto.  If they refuse to move forward with 
          >> changes, miners could perform a soft fork on their own.  They
          >> don't want to do that, as it would be controversial and the devs
          >> know the software better.
          >> 
          >> The miner veto is stronger (for soft forks) but not absolute.
          >> The devs could checkpoint/blacklist a chain if miners implemented
          >> a fork that wasn't acceptable (assuming the community backed
          >> them).
          >> 
          >> When ASICs arrived, it was pointed out by some that the devs
          >> could hit back if ASICs weren't made publicly available.  If they
          >> slightly tweaked the hashing algorithm, then current generation
          >> of ASICs would be useless.   The potential threat may have acted
          >> as a disincentive for ASIC manufacturers to use the ASICs
          >> themselves.
          >> 
          >> Moving forward with agreement between all involved is the
          >> recommended and desirable approach.
          >> 
          >> Consensus between all parties is the goal but isn't absolutely 
          >> required.  This escape valve is partly what makes consensus work.
          >> If you dig your heels in, then the other side can bypass you, but
          >> they have an incentive to try to convince you to compromise
          >> first.  The outcome is better if a middle ground can be found.
          >> 
          >> Hard forks are different.  The "checks and balances" of weak
          >> vetoes are not present.  This means that things can devolve from
          >> consensus to mutual veto.  Consensus ceases to be a goal and
          >> becomes a requirement.
          >> 
          >> This is partly a reflection of the nature of hard forks.
          >> Everyone needs to upgrade.  On the other hand, if most of the
          >> various groups upgrade, then users of the legacy software would
          >> have to upgrade or get left behind.  If 5% of the users decided
          >> not to upgrade, should they be allowed to demand that nobody else
          >> does?
          >> 
          >> There is clearly some kind of threshold that is reasonable.
          >> 
          >> The fundamental problem is that there isn't agreement on what
          >> the block size is.  Is it equal in status to the 21 million BTC
          >> limit?
          >> 
          >> If Satoshi had said that 1MB was part of the definition of
          >> Bitcoin, then I think people would accept it to the same extent
          >> as they accept the 21 million coin limit.  It might cause people
          >> to leave the coin though.
          >> 
          >> It was intended to be temporary, but people have realized that
          >> it might be a good idea to keep it.  In effect both sides could
          >> argue that they should be considered the status quo.
          >> 
          >> I wonder if a coin toss would be acceptable :).  "Come to an
          >> agreement or we decide by coin toss"
          >> 
          >> 
          >> _______________________________________________ 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
          > 
          
          - -- 
          http://abis.io ~
          "a protocol concept to enable decentralization
          and expansion of a giving economy, and a new social good"
          https://keybase.io/odinn
          -----BEGIN PGP SIGNATURE-----
          Version: GnuPG v1
          
          iQEcBAEBAgAGBQJVlGrZAAoJEGxwq/inSG8C2wYH/3VZgzpbJrgprqNMDwWsMoxx
          DFbgjQfOrHbVvAQebSlcH1FXPnzVZZSbxMlQAbDXr4lpREvMPQiomixCmkTTepob
          zKhJu/bGYgLVqcXSDYuJTwCKgHfzTj02Q8D8ViFZdsPOHLIuhcAAq+KgioUHH+Ps
          v2kWA48ePTHVxqNd79S2CKjk5Gyo99YIMAjbQOuC6DbW/y1hNmQP7iQPn6UUe4pY
          qyLLDa6ccKvJslq3chXGK/alhGHZ5lyEYZY43qiL9cBEgqEn6kHC5gveqQxvXMvj
          rOoZbAKCAc9GdlhUplRt5MhF35FTFvbaBTAq07/95Xo4C8DIhmXesHgmPtc1OqI=
          =n7Pa
          -----END PGP SIGNATURE-----
          
          
          ^ permalink raw reply	[flat|nested] 51+ messages in thread

  • * Re: [bitcoin-dev] BIP Process and Votes
      2015-06-25  0:07 ` Milly Bitcoin
      2015-06-25  1:50   ` Mark Friedenbach
    @ 2015-06-25  3:42   ` Gareth Williams
      2015-06-25  4:10     ` Milly Bitcoin
      2015-06-25 13:36   ` s7r
      2 siblings, 1 reply; 51+ messages in thread
    From: Gareth Williams @ 2015-06-25  3:42 UTC (permalink / raw)
      To: Milly Bitcoin; +Cc: bitcoin-dev
    
    On Thu, Jun 25, 2015 at 10:07 AM, Milly Bitcoin <milly@bitcoins•info>
    wrote:
    <snip>
    > 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
    <snip>
    > Now you are left with a broken, unwritten/unspoken process.
    
    Your former statement is a great example of why "rough consensus and
    running code" is superior to design by committee.
    An argument should be assessed on its technical merit alone, not on
    the number of people advancing it -- a process that would be open to
    exactly the type of external manipulation you say you are concerned
    about.
    
    
    ^ permalink raw reply	[flat|nested] 51+ messages in thread

  • • * Re: [bitcoin-dev] BIP Process and Votes
        2015-06-25  3:42   ` Gareth Williams
      @ 2015-06-25  4:10     ` Milly Bitcoin
        0 siblings, 0 replies; 51+ messages in thread
      From: Milly Bitcoin @ 2015-06-25  4:10 UTC (permalink / raw)
        To: bitcoin-dev
      
      I am not giving an opinion on the incentive process for developers.  I 
      am just saying it exists and it needs to be taken into account when 
      developing a process. Pretending it doesn't exist or taking it as some 
      kind of personal insult does not do anything to advance the process.  
      The developer incentives feeds into the consensus process.
      
      Depending on some kind of "rough consensus" with unstated 
      personality-based rules of the game works fine with small projects.  As 
      the project gets larger that does not scale as can be seen with the 
      recent events.  That is just a taste of what will happen in the future 
      as new issue arise.  Developers will end up spending all day tweeting 
      and making videos instead of writing code.
      
      The current process does not guarantee changes are approved on technical 
      merit alone and that is part of the problem.  Since there is no defined 
      process people make claims of all sorts of motives that may or may not 
      exist.  The idea is to get a defined process that gives a certain level 
      of assurance to outsiders that the process is based on things like 
      technical merit.
      
      Russ
      
      
      On 6/24/2015 11:42 PM, Gareth Williams wrote:
      > On Thu, Jun 25, 2015 at 10:07 AM, Milly Bitcoin <milly@bitcoins•info>
      > wrote:
      > <snip>
      >> 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
      > <snip>
      >> Now you are left with a broken, unwritten/unspoken process.
      > Your former statement is a great example of why "rough consensus and
      > running code" is superior to design by committee.
      > An argument should be assessed on its technical merit alone, not on
      > the number of people advancing it -- a process that would be open to
      > exactly the type of external manipulation you say you are concerned
      > about.
      >
      
      
      
      
      ^ permalink raw reply	[flat|nested] 51+ messages in thread

  • * Re: [bitcoin-dev] BIP Process and Votes
      2015-06-25  0:07 ` Milly Bitcoin
      2015-06-25  1:50   ` Mark Friedenbach
      2015-06-25  3:42   ` Gareth Williams
    @ 2015-06-25 13:36   ` s7r
      2015-06-25 13:41     ` Eric Lombrozo
      2 siblings, 1 reply; 51+ messages in thread
    From: s7r @ 2015-06-25 13:36 UTC (permalink / raw)
      To: Milly Bitcoin, bitcoin-dev
    
    I guess you mean Wladimir here. You are wrong, Wladimir does decide and
    if you look at the commit history on github.com for bitcoin core you
    will see, that he does actually decide and does it really good.
    
    He just does not want to decide (and he really should not) on CONSENSUS
    changes or protocol changes. This is totally different.
    
    Stop the analogy with "other open source projects". This is an open
    source project (the code part) but unlike any other open source projects
    which can just be forked, without affecting the other users, in bitcoin
    we need all the users to trust a single blockchain, so it'll have value.
    If some users fork the blockchain and change consensus rules, they are
    not just harming themselves, they are affecting ALL the users, since
    such a thing would have strong impact over the BTC/FIAT rate, affecting
    everyone in the ecosystem. There is economics involved here and human
    element, things which are hard to fix via code, even if the code is
    developed in open source style.
    
    It's one thing to decide to merge some patches, improve the code, etc.
    and another thing to decide for consensus rules when you literary play
    with 4 billion united states dollars of other people's money. This
    shouldn't be Wladimir's responsibility, it's just unfair for people to
    throw this on his shoulders.
    
    I do not under any circumstances suggest that the consensus should
    remain as it is now forever. We need to improve it, but this should not
    be on the maintainer. I've seen smart suggestions on this mail list
    where consensus changes can be made during a long period of time,
    through soft forks, where all users/miners/exchangers/merchants get the
    chance to choose / take action.
    
    On 6/25/2015 3:07 AM, Milly Bitcoin 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
    
    
    ^ permalink raw reply	[flat|nested] 51+ messages in thread

  • • * Re: [bitcoin-dev] BIP Process and Votes
        2015-06-25 13:36   ` s7r
      @ 2015-06-25 13:41     ` Eric Lombrozo
        2015-06-25 13:51       ` s7r
                               ` (2 more replies)
        0 siblings, 3 replies; 51+ messages in thread
      From: Eric Lombrozo @ 2015-06-25 13:41 UTC (permalink / raw)
        To: s7r; +Cc: bitcoin-dev
      
      [-- Attachment #1: Type: text/plain, Size: 4423 bytes --]
      
      Wladimir is doing an amazing job under difficult circumstances. Give the guy a break, please.
      
      - Eric Lombrozo
      
      > On Jun 25, 2015, at 6:36 AM, s7r <s7r@sky-ip•org> wrote:
      > 
      > I guess you mean Wladimir here. You are wrong, Wladimir does decide and
      > if you look at the commit history on github.com for bitcoin core you
      > will see, that he does actually decide and does it really good.
      > 
      > He just does not want to decide (and he really should not) on CONSENSUS
      > changes or protocol changes. This is totally different.
      > 
      > Stop the analogy with "other open source projects". This is an open
      > source project (the code part) but unlike any other open source projects
      > which can just be forked, without affecting the other users, in bitcoin
      > we need all the users to trust a single blockchain, so it'll have value.
      > If some users fork the blockchain and change consensus rules, they are
      > not just harming themselves, they are affecting ALL the users, since
      > such a thing would have strong impact over the BTC/FIAT rate, affecting
      > everyone in the ecosystem. There is economics involved here and human
      > element, things which are hard to fix via code, even if the code is
      > developed in open source style.
      > 
      > It's one thing to decide to merge some patches, improve the code, etc.
      > and another thing to decide for consensus rules when you literary play
      > with 4 billion united states dollars of other people's money. This
      > shouldn't be Wladimir's responsibility, it's just unfair for people to
      > throw this on his shoulders.
      > 
      > I do not under any circumstances suggest that the consensus should
      > remain as it is now forever. We need to improve it, but this should not
      > be on the maintainer. I've seen smart suggestions on this mail list
      > where consensus changes can be made during a long period of time,
      > through soft forks, where all users/miners/exchangers/merchants get the
      > chance to choose / take action.
      > 
      > On 6/25/2015 3:07 AM, Milly Bitcoin 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
      
      
      [-- Attachment #2: Message signed with OpenPGP using GPGMail --]
      [-- Type: application/pgp-signature, Size: 842 bytes --]
      
      ^ permalink raw reply	[flat|nested] 51+ messages in thread

    • • * Re: [bitcoin-dev] BIP Process and Votes
          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
          2 siblings, 0 replies; 51+ messages in thread
        From: s7r @ 2015-06-25 13:51 UTC (permalink / raw)
          To: Eric Lombrozo; +Cc: bitcoin-dev
        
        +1 for Wladimir, as I said. Anyone who checks the commit history on
        github can see that he decides quite well all the time for code changes.
        These fake arguments are thrown by people who hope they will force him
        into deciding for consensus / protocol changes. This won't happen.
        
        On 6/25/2015 4:41 PM, Eric Lombrozo wrote:
        > Wladimir is doing an amazing job under difficult circumstances. Give the guy a break, please.
        > 
        > - Eric Lombrozo
        > 
        >> On Jun 25, 2015, at 6:36 AM, s7r <s7r@sky-ip•org> wrote:
        >>
        >> I guess you mean Wladimir here. You are wrong, Wladimir does decide and
        >> if you look at the commit history on github.com for bitcoin core you
        >> will see, that he does actually decide and does it really good.
        >>
        >> He just does not want to decide (and he really should not) on CONSENSUS
        >> changes or protocol changes. This is totally different.
        >>
        >> Stop the analogy with "other open source projects". This is an open
        >> source project (the code part) but unlike any other open source projects
        >> which can just be forked, without affecting the other users, in bitcoin
        >> we need all the users to trust a single blockchain, so it'll have value.
        >> If some users fork the blockchain and change consensus rules, they are
        >> not just harming themselves, they are affecting ALL the users, since
        >> such a thing would have strong impact over the BTC/FIAT rate, affecting
        >> everyone in the ecosystem. There is economics involved here and human
        >> element, things which are hard to fix via code, even if the code is
        >> developed in open source style.
        >>
        >> It's one thing to decide to merge some patches, improve the code, etc.
        >> and another thing to decide for consensus rules when you literary play
        >> with 4 billion united states dollars of other people's money. This
        >> shouldn't be Wladimir's responsibility, it's just unfair for people to
        >> throw this on his shoulders.
        >>
        >> I do not under any circumstances suggest that the consensus should
        >> remain as it is now forever. We need to improve it, but this should not
        >> be on the maintainer. I've seen smart suggestions on this mail list
        >> where consensus changes can be made during a long period of time,
        >> through soft forks, where all users/miners/exchangers/merchants get the
        >> chance to choose / take action.
        >>
        >> On 6/25/2015 3:07 AM, Milly Bitcoin 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
        > 
        
        
        ^ permalink raw reply	[flat|nested] 51+ messages in thread

      • * Re: [bitcoin-dev] BIP Process and Votes
          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
          2 siblings, 0 replies; 51+ messages in thread
        From: Milly Bitcoin @ 2015-06-25 14:08 UTC (permalink / raw)
          To: bitcoin-dev
        
        I agree with all this.  However, as a practical matter the consensus 
        rules are not separated out so one person decides whether the "rough 
        consensus" has been reached and if the consensus rules should be 
        changed.  It really has nothing to do with any personality involved or 
        whether they do a good or bad job.  The final decision should probably 
        not fall into the lap of one person but it does for now and that is just 
        the way it is because there is no better way to do it if you want to get 
        things done.
        
        I am also not saying any specific process is good or bad, I am saying 
        the lack of a defined process causes wasted time and effort.  Once you 
        define the process you have now (the baseline) then you can evaluate 
        whether parts of it are good or bad.
        
        As the developer system transitions into a paid system where commercial 
        entities hire developers then there is no incentive for them to do that 
        if changes can never be made.  A defined process will give more 
        assurance for commercial entities to bring more developers on board.
        
        Russ
        
        
        On 6/25/2015 9:41 AM, Eric Lombrozo wrote:
        > Wladimir is doing an amazing job under difficult circumstances. Give the guy a break, please.
        >
        > - Eric Lombrozo
        >
        >> On Jun 25, 2015, at 6:36 AM, s7r <s7r@sky-ip•org> wrote:
        >>
        >> I guess you mean Wladimir here. You are wrong, Wladimir does decide and
        >> if you look at the commit history on github.com for bitcoin core you
        >> will see, that he does actually decide and does it really good.
        >>
        >> He just does not want to decide (and he really should not) on CONSENSUS
        >> changes or protocol changes. This is totally different.
        >>
        >> Stop the analogy with "other open source projects". This is an open
        >> source project (the code part) but unlike any other open source projects
        >> which can just be forked, without affecting the other users, in bitcoin
        >> we need all the users to trust a single blockchain, so it'll have value.
        >> If some users fork the blockchain and change consensus rules, they are
        >> not just harming themselves, they are affecting ALL the users, since
        >> such a thing would have strong impact over the BTC/FIAT rate, affecting
        >> everyone in the ecosystem. There is economics involved here and human
        >> element, things which are hard to fix via code, even if the code is
        >> developed in open source style.
        >>
        >> It's one thing to decide to merge some patches, improve the code, etc.
        >> and another thing to decide for consensus rules when you literary play
        >> with 4 billion united states dollars of other people's money. This
        >> shouldn't be Wladimir's responsibility, it's just unfair for people to
        >> throw this on his shoulders.
        >>
        >> I do not under any circumstances suggest that the consensus should
        >> remain as it is now forever. We need to improve it, but this should not
        >> be on the maintainer. I've seen smart suggestions on this mail list
        >> where consensus changes can be made during a long period of time,
        >> through soft forks, where all users/miners/exchangers/merchants get the
        >> chance to choose / take action.
        >>
        >> On 6/25/2015 3:07 AM, Milly Bitcoin 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
        
        
        
        
        ^ permalink raw reply	[flat|nested] 51+ messages in thread

      • * Re: [bitcoin-dev] BIP Process and Votes
          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
          2 siblings, 1 reply; 51+ messages in thread
        From: Jeff Garzik @ 2015-06-25 17:03 UTC (permalink / raw)
          To: Eric Lombrozo; +Cc: bitcoin-dev
        
        [-- Attachment #1: Type: text/plain, Size: 295 bytes --]
        
        On Thu, Jun 25, 2015 at 6:41 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
        
        > Wladimir is doing an amazing job under difficult circumstances. Give the
        > guy a break, please
        
        
        A+ agreed.  He is not an elected decider - he is the Bitcoin Core release
        manager, and has been doing a damn fine job.
        
        [-- Attachment #2: Type: text/html, Size: 617 bytes --]
        
        ^ permalink raw reply	[flat|nested] 51+ messages in thread

      • • * Re: [bitcoin-dev] BIP Process and Votes
            2015-06-25 17:03       ` Jeff Garzik
          @ 2015-06-25 17:29         ` Milly Bitcoin
            0 siblings, 0 replies; 51+ messages in thread
          From: Milly Bitcoin @ 2015-06-25 17:29 UTC (permalink / raw)
            Cc: bitcoin-dev
          
          [-- Attachment #1: Type: text/plain, Size: 1117 bytes --]
          
          In the context of this discussion the Bitcoin Core release manager is 
          the "decider" of what goes into the release.  Nobody said he was 
          elected.  The discussion also has nothing to do with any specific person 
          and nobody said anyone did anything wrong.  One of the reason why a 
          process needs to be developed so issues are not sidetracked into a 
          dramatized discussion over personalities which is a big waste of time.  
          Some of the developers are now essentially full time drama queens who 
          write a little bit of code on the side.
          
          Russ
          
          
          
          
          On 6/25/2015 1:03 PM, Jeff Garzik wrote:
          > On Thu, Jun 25, 2015 at 6:41 AM, Eric Lombrozo <elombrozo@gmail•com 
          > <mailto:elombrozo@gmail•com>> wrote:
          >
          >     Wladimir is doing an amazing job under difficult circumstances.
          >     Give the guy a break, please
          >
          >
          > A+ agreed.  He is not an elected decider - he is the Bitcoin Core 
          > release manager, and has been doing a damn fine job.
          >
          >
          >
          > _______________________________________________
          > bitcoin-dev mailing list
          > bitcoin-dev@lists•linuxfoundation.org
          > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
          
          
          [-- Attachment #2: Type: text/html, Size: 2401 bytes --]
          
          ^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [bitcoin-dev] BIP Process and Votes
@ 2015-06-25  0:18 Raystonn
  0 siblings, 0 replies; 51+ messages in thread
From: Raystonn @ 2015-06-25  0:18 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: bitcoin-dev

[-- Attachment #1: Type: text/html, Size: 2164 bytes --]

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [bitcoin-dev] BIP Process and Votes
@ 2015-06-25  3:00 Raystonn
  2015-06-25  3:19 ` Milly Bitcoin
  2015-06-25 19:03 ` Tom Harding
  0 siblings, 2 replies; 51+ messages in thread
From: Raystonn @ 2015-06-25  3:00 UTC (permalink / raw)
  To: Mark Friedenbach; +Cc: bitcoin-dev

[-- Attachment #1: Type: text/html, Size: 6546 bytes --]

^ permalink raw reply	[flat|nested] 51+ messages in thread

• * Re: [bitcoin-dev] BIP Process and Votes
    2015-06-25  3:00 Raystonn
  @ 2015-06-25  3:19 ` Milly Bitcoin
    2015-06-26 11:13   ` Jorge Timón
    2015-06-25 19:03 ` Tom Harding
    1 sibling, 1 reply; 51+ messages in thread
  From: Milly Bitcoin @ 2015-06-25  3:19 UTC (permalink / raw)
    To: bitcoin-dev
  
  [-- Attachment #1: Type: text/plain, Size: 6743 bytes --]
  
  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@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@bitcoins•info <mailto: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
  >             <mailto:bitcoin-dev@lists•linuxfoundation.org>
  >             https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
  >
  >
  >
  >         _______________________________________________
  >         bitcoin-dev mailing list
  >         bitcoin-dev@lists•linuxfoundation.org
  >         <mailto:bitcoin-dev@lists•linuxfoundation.org>
  >         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
  >
  >
  
  
  [-- Attachment #2: Type: text/html, Size: 11380 bytes --]
  
  ^ permalink raw reply	[flat|nested] 51+ messages in thread

• • * Re: [bitcoin-dev] BIP Process and Votes
      2015-06-25  3:19 ` Milly Bitcoin
    @ 2015-06-26 11:13   ` Jorge Timón
      2015-06-26 12:34     ` Milly Bitcoin
      0 siblings, 1 reply; 51+ messages in thread
    From: Jorge Timón @ 2015-06-26 11:13 UTC (permalink / raw)
      To: Milly Bitcoin; +Cc: bitcoin-dev
    
    On Thu, Jun 25, 2015 at 2:42 PM, Milly Bitcoin <milly@bitcoins•info> wrote:
    > "Cultish" means making claims without any supporting facts.
    
    On Thu, Jun 25, 2015 at 5:19 AM, Milly Bitcoin <milly@bitcoins•info> wrote:
    > 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.
    
    This statement seems "cultish" by your own definition.
    I'm going to make the opposite statement:  the consensus on code
    changes is almost always 100%.
    Mark has already given a couple examples of changes to consensus rules
    (the most risky type of change), here's a few thousand other examples
    of changes to the bitcoin core's code that had no opposition:
    
    https://github.com/bitcoin/bitcoin/commits/master
    
    Can you please point us to a few examples were changes were made with
    opposition to them?
    In those cases (which you assure is what happens almost always), would
    you say that the result of letting a decider decide instead of fixing
    or addressing all the concerns (either by changing the proposed code
    or explaining it) better in restrospective?
    
    
    ^ permalink raw reply	[flat|nested] 51+ messages in thread

  • • * Re: [bitcoin-dev] BIP Process and Votes
        2015-06-26 11:13   ` Jorge Timón
      @ 2015-06-26 12:34     ` Milly Bitcoin
        2015-06-27 11:28       ` Jorge Timón
        0 siblings, 1 reply; 51+ messages in thread
      From: Milly Bitcoin @ 2015-06-26 12:34 UTC (permalink / raw)
        To: bitcoin-dev
      
      Without looking up specific links I am confident people like Mircea 
      Popescu will oppose just about any change.  Maybe they don't post their 
      objection to Github but the point I am making is that no matter what 
      change you make someone, somewhere will be against it.  Some of the 
      developers think that Github is the only place that matters and that the 
      only opinions that matter is a tiny group of insiders.  I don't think 
      that way which is the reasoning behind my statement.
      
      I am saying that after all the concerns are addressed as far as 
      reasonably possible someone, somewhere has to decide whether or not to 
      commit the changes to the official release.  Right now the only person 
      who makes that decision if the version manager.  I agree it should not 
      fall onto the shoulders of one person who is also very busy doing other 
      things.  I am saying there should be some process to move forward and 
      make decisions when needed.
      
      Also, you already saw one of the Core developers calling me a "troll" 
      and telling others to ignore my messages.  I have heard of several 
      people who just drop out of the github discussions because of stuff like 
      that.  They also delete message from Gihub discussions so that archive 
      is not 100% credible.  I have seen things like a Github discussion 
      between 3 or 4 people and then Garzik send out a tweet that there is 
      near universal approval for the proposed change as it nobody is allowed 
      to question it.  After watching the github process for a couple years I 
      simply don't trust it because the developers in charge have a 
      dictatorial style and they shut out many stakeholders instead of 
      soliciting their opinions.  I view the Github system as the biggest 
      centralized choke-point in Bitcoin and probably its biggest threat to 
      its continued survival.  Anyone can come in and hire a couple core 
      developers and veto any change they don't want.
      
      Russ
      
      
      
      
      
      
      
      
      On 6/26/2015 7:13 AM, Jorge Timón wrote:
      > On Thu, Jun 25, 2015 at 2:42 PM, Milly Bitcoin <milly@bitcoins•info> wrote:
      >> "Cultish" means making claims without any supporting facts.
      > On Thu, Jun 25, 2015 at 5:19 AM, Milly Bitcoin <milly@bitcoins•info> wrote:
      >> 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.
      > This statement seems "cultish" by your own definition.
      > I'm going to make the opposite statement:  the consensus on code
      > changes is almost always 100%.
      > Mark has already given a couple examples of changes to consensus rules
      > (the most risky type of change), here's a few thousand other examples
      > of changes to the bitcoin core's code that had no opposition:
      >
      > https://github.com/bitcoin/bitcoin/commits/master
      >
      > Can you please point us to a few examples were changes were made with
      > opposition to them?
      > In those cases (which you assure is what happens almost always), would
      > you say that the result of letting a decider decide instead of fixing
      > or addressing all the concerns (either by changing the proposed code
      > or explaining it) better in restrospective?
      >
      
      
      
      
      ^ permalink raw reply	[flat|nested] 51+ messages in thread

    • • * Re: [bitcoin-dev] BIP Process and Votes
          2015-06-26 12:34     ` Milly Bitcoin
        @ 2015-06-27 11:28       ` Jorge Timón
          2015-06-27 12:50         ` Milly Bitcoin
          0 siblings, 1 reply; 51+ messages in thread
        From: Jorge Timón @ 2015-06-27 11:28 UTC (permalink / raw)
          To: Milly Bitcoin; +Cc: bitcoin-dev
        
        On Fri, Jun 26, 2015 at 2:34 PM, Milly Bitcoin <milly@bitcoins•info> wrote:
        > Without looking up specific links I am confident people like Mircea Popescu
        > will oppose just about any change.  Maybe they don't post their objection to
        > Github but the point I am making is that no matter what change you make
        > someone, somewhere will be against it.  Some of the developers think that
        > Github is the only place that matters and that the only opinions that matter
        > is a tiny group of insiders.  I don't think that way which is the reasoning
        > behind my statement.
        
        Yes, I understand that it may be difficult to define
        "uncontroversial", as I explain in
        http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html
        
        > I have seen things like a Github discussion between 3 or 4 people
        > and then Garzik send out a tweet that there is near universal approval for
        > the proposed change as it nobody is allowed to question it.  After watching
        > the github process for a couple years I simply don't trust it because the
        > developers in charge have a dictatorial style and they shut out many
        > stakeholders instead of soliciting their opinions.
        
        Can you provide anything to back your claim?
        Note that even if that's true, still, Bitcoin core != Bitcoin consensus rules.
        
        > I view the Github system
        > as the biggest centralized choke-point in Bitcoin and probably its biggest
        > threat to its continued survival.  Anyone can come in and hire a couple core
        > developers and veto any change they don't want.
        
        Well, yes, github is centralized and so it is bitcoin core development.
        But bitcoin core developers don't decide hardfork changes.
        So far, softfork changes have been made because they have been
        considered "uncontroversial", not because there's any centralized
        negotiating table or voting process to decide when to force every user
        to adapt their software to new consensus rules.
        
        
        ^ permalink raw reply	[flat|nested] 51+ messages in thread

      • • * Re: [bitcoin-dev] BIP Process and Votes
            2015-06-27 11:28       ` Jorge Timón
          @ 2015-06-27 12:50         ` Milly Bitcoin
            2015-06-28 12:30           ` Jorge Timón
            0 siblings, 1 reply; 51+ messages in thread
          From: Milly Bitcoin @ 2015-06-27 12:50 UTC (permalink / raw)
            To: bitcoin-dev
          
          [-- Attachment #1: Type: text/plain, Size: 4875 bytes --]
          
          On 6/27/2015 7:28 AM, Jorge Timón wrote:
          > On Fri, Jun 26, 2015 at 2:34 PM, Milly Bitcoin <milly@bitcoins•info> wrote:
          >> Without looking up specific links I am confident people like Mircea Popescu
          >> will oppose just about any change.  Maybe they don't post their objection to
          >> Github but the point I am making is that no matter what change you make
          >> someone, somewhere will be against it.  Some of the developers think that
          >> Github is the only place that matters and that the only opinions that matter
          >> is a tiny group of insiders.  I don't think that way which is the reasoning
          >> behind my statement.
          > Yes, I understand that it may be difficult to define
          > "uncontroversial", as I explain in
          > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html
          >
          >> I have seen things like a Github discussion between 3 or 4 people
          >> and then Garzik send out a tweet that there is near universal approval for
          >> the proposed change as it nobody is allowed to question it.  After watching
          >> the github process for a couple years I simply don't trust it because the
          >> developers in charge have a dictatorial style and they shut out many
          >> stakeholders instead of soliciting their opinions.
          > Can you provide anything to back your claim?
          > Note that even if that's true, still, Bitcoin core != Bitcoin consensus rules.
          I saw this problem first hand when Andreas Antonopolis got into a big 
          dispute with some of the core developers over the press contacts.  The 
          github made up their rules as they went along and simply ignored input 
          from anyone outside their inner circle.  Since that time several people 
          have told me they dropped out of participating in the github process.  
          The maintainers deleted some of my messages and I have been told I am 
          banned form github. Further, as you can see on here Jeff Garzik, a guy 
          who claims only to hold a few hundred Bitcoin, told people on this list 
          to ignore my messages.  There is also the incident where Gavin lambasted 
          someone for "hiding behind anonymity" when the whole project is based on 
          an anonymous contributor.  I find it interesting that many developers 
          who work on a decentralized system.  I don't like the general attitude 
          of the developers that they are the protectors of the system and that 
          everyone else is trying to exploit or do damage. they often characterize 
          different users/businesses/miners as abusers, spammers, people trying to 
          game the system, etc. while they characterize the developers as pure and 
          good.  When the issue comes up about authority over the code (which 
          includes the consensus rules) they spout all kinds of nonsense about how 
          they don't have significant control and are not deciders yet they never 
          point to who does decide.  If they weren't the deciders then people 
          would not be spending all that time lobbying them.  just because there 
          are some checks and balances does not mean it is "decentralized" or they 
          are not deciders.
          
          As for your proclamation**at Bitcoin core != Bitcoin consensus rules, 
          that is simply not true in practice.  There is one piece of software 
          with one maintainer.  If you want it changed you have to convince that 
          one person to approve the change.
          
          >> I view the Github system
          >> as the biggest centralized choke-point in Bitcoin and probably its biggest
          >> threat to its continued survival.  Anyone can come in and hire a couple core
          >> developers and veto any change they don't want.
          > Well, yes, github is centralized and so it is bitcoin core development.
          > But bitcoin core developers don't decide hardfork changes.
          > So far, softfork changes have been made because they have been
          > considered "uncontroversial", not because there's any centralized
          > negotiating table or voting process to decide when to force every user
          > to adapt their software to new consensus rules.
          >
          The core developers have the biggest influence by far to decide hard 
          fork changes.  There is no other place to go.  While anyone can fork the 
          code someone compare it to the river Thames.  if you don't like where 
          the river runs you can dig a new one ... here is a spoon.  I can vote in 
          elections but that does not mean the US government is "decentralized."  
          The core maintainer has decided on a hard fork change, he has decided 
          not to do it.
          
          In any case what happened in the past does not matter.  What is going to 
          happen now is the question.  If nothing happens and everybody sits 
          around saying they are not in charge of the consensus rules and nothing 
          ever gets done I see Bitcoin just fading away into oblivion.  I am under 
          the impression that at least some of the developers (such as Garzik) 
          don't actually hold that many bitcoins and don't have a large stake in 
          the system yet they have significant control.  Anyone can attack the 
          system by simply hiring a couple core developers and creating the 
          gridlock we see now.
          
          Russ
          
          [-- Attachment #2: Type: text/html, Size: 6044 bytes --]
          
          ^ permalink raw reply	[flat|nested] 51+ messages in thread

        • • * Re: [bitcoin-dev] BIP Process and Votes
              2015-06-27 12:50         ` Milly Bitcoin
            @ 2015-06-28 12:30           ` Jorge Timón
              2015-06-28 13:13             ` Milly Bitcoin
              0 siblings, 1 reply; 51+ messages in thread
            From: Jorge Timón @ 2015-06-28 12:30 UTC (permalink / raw)
              To: Milly Bitcoin; +Cc: bitcoin-dev
            
            On Sat, Jun 27, 2015 at 2:50 PM, Milly Bitcoin <milly@bitcoins•info> wrote:
            > On 6/27/2015 7:28 AM, Jorge Timón wrote:
            > I have seen things like a Github discussion between 3 or 4 people
            > and then Garzik send out a tweet that there is near universal approval for
            > the proposed change as it nobody is allowed to question it.  After watching
            > the github process for a couple years I simply don't trust it because the
            > developers in charge have a dictatorial style and they shut out many
            > stakeholders instead of soliciting their opinions.
            > [...]
            >
            > I saw this problem first hand when Andreas Antonopolis got into a big
            > dispute with some of the core developers over the press contacts.  The
            > github made up their rules as they went along and simply ignored input from
            > anyone outside their inner circle.  Since that time several people have told
            > me they dropped out of participating in the github process.  The maintainers
            > deleted some of my messages and I have been told I am banned form github.
            
            I wasn't asking for an example of something that was rejected, there's
            plenty of those.
            You were saying people were opposing a change and jgarzik unilaterally added it.
            When did that happen?
            
            > As for your proclamation at Bitcoin core != Bitcoin consensus rules, that is
            > simply not true in practice.  There is one piece of software with one
            > maintainer.  If you want it changed you have to convince that one person to
            > approve the change.
            
            There are many pieces of software and many maintainers, libbitcoin,
            for example, is another full node implementation different from
            Bitcoin core.
            Also, to change Bitcoin core I don't need to convince anyone, I do it
            all the time here https://github.com/jtimon/bitcoin
            
            > The core developers have the biggest influence by far to decide hard fork
            > changes.  There is no other place to go.  While anyone can fork the code
            > someone compare it to the river Thames.  if you don't like where the river
            > runs you can dig a new one ... here is a spoon.  I can vote in elections but
            > that does not mean the US government is "decentralized."  The core
            > maintainer has decided on a hard fork change, he has decided not to do it.
            
            Maybe Bitcoin core devs have more influence, but still, they don't
            have the power to decide for everyone else what the consensus rules
            are.
            Your analogy is ridiculous, it literally takes seconds to fork bitcoin
            and is as simple as clicking a button.
            Wladimir has explained many times that he hasn't decided anything
            because he can't decide that.
            You keep insisting that he has control over consensus rules. Are you
            doing it because you want him to be threaten, tortured, kidnapped or
            killed?
            If you don't, please stop making false claims about powers he doesn't
            have because some bad guy could believe you.
            
            > I am under the
            > impression that at least some of the developers (such as Garzik) don't
            > actually hold that many bitcoins and don't have a large stake in the system
            > yet they have significant control.
            
            For the last time, they may have control over Bitcoin core (one
            implementation of the Bitcoin protocol), not the consensus rules.
            Why are anyone's bitcoin holdings relevant in any technical discussion?
            Please, keep this kind of offtopic comments out.
            
            >  Anyone can attack the system by simply
            > hiring a couple core developers and creating the gridlock we see now.
            
            As said several times, yes, it is hard to define "uncontroversial"
            without giving veto powers to any random guy on the internet.
            But this is clearly not what is happening now. Most Bitcoin core devs
            are against the current proposals, that cannot be considered
            uncontroversial for any sane definition of it.
            
            
            ^ permalink raw reply	[flat|nested] 51+ messages in thread

          • • * Re: [bitcoin-dev] BIP Process and Votes
                2015-06-28 12:30           ` Jorge Timón
              @ 2015-06-28 13:13             ` Milly Bitcoin
                2015-06-28 15:35               ` Jorge Timón
                0 siblings, 1 reply; 51+ messages in thread
              From: Milly Bitcoin @ 2015-06-28 13:13 UTC (permalink / raw)
                Cc: bitcoin-dev
              
              I never said something was approved by garzik added something after it 
              was opposed.  What I said was a proposal was made and 4 people commented 
              on the Github.  He then tweeted there was near universal approval before 
              most people even heard about the subject.  It was not controversial but 
              i was pointing out the arrogance of some of the developers.  He 
              considers the entire universe of Bitcoin stakeholders to be a very small 
              group of insiders, not the entire universe of Bitcoin users.  Another 
              thing I have seen on Github for bitcoin.org is how some the maintainers 
              change the rules on the fly.  Sometimes they say a proposal had no 
              objections so it is approved.  Other times they say a proposal has no 
              support so it is rejected.
              
              You are also trying to say that the core developers actually have little 
              influence and are not "deciders" because anyone can fork the code.  That 
              has already been discussed at length and such an argument is faulty 
              because there is a constraint that your software is incompatible with 
              everyone else.  The issue is that there is no way right now to change 
              the consensus rules except to go through the core maintainer unless you 
              get everybody on the network to switch to your fork.  People who keep 
              repeating that the software development is "decentralized because you 
              fork the code" without explaining the constraints are just cultists.
              
              The discussion has nothing to do with who has the position now and I 
              never said he has "control over the consensus rules."  The maintainer 
              has a very large influence way beyond anyone else.  As for your claim 
              that I want someone hurt because I am explaining the process, that is 
              ridiculous.  If the Core maintainers did not have significant influence 
              to change the consensus rules then everybody would not be spending all 
              this time lobbying them to have them changed.
              
              The outside influences and stake of the developer is a relevant topic.  
              The same types of things are discussed on this list all the time in the 
              context of miners, users, merchants, and exchanges.  Again, the 
              developers try to place themselves on some kind of pedestal where they 
              are the protectors and pure and everyone else (miners, users, merchants) 
              are abusers, spammers, attackers, scammers, cheaters, etc.  It is Garzik 
              who voluntarily made an issue of how many bitcoins he holds and he made 
              that issue in the same place where he announces many of the technical 
              issues.  It is very relevant that he has a minimal stake in Bitcoin 
              holdings yet he goes around making major decisions about Bitcoin and 
              trying to dictate who is allowed to participate in discussions.  If a 
              core developer has minimal stake in Bitcoin yet has major veto power 
              over code change that is a problem.
              
              You are correct that you cannot give power to any person over the 
              Internet which is why some kind of process needs to be developed that 
              does not involve trying to convince one person to make the changes or a 
              system that depends on unwritten, ever-changing rules maintained by a 
              handful of people.
              
              Russ
              
              
              
              
              On 6/28/2015 8:30 AM, Jorge Timón wrote:
              > On Sat, Jun 27, 2015 at 2:50 PM, Milly Bitcoin <milly@bitcoins•info> wrote:
              >> On 6/27/2015 7:28 AM, Jorge Timón wrote:
              >> I have seen things like a Github discussion between 3 or 4 people
              >> and then Garzik send out a tweet that there is near universal approval for
              >> the proposed change as it nobody is allowed to question it.  After watching
              >> the github process for a couple years I simply don't trust it because the
              >> developers in charge have a dictatorial style and they shut out many
              >> stakeholders instead of soliciting their opinions.
              >> [...]
              >>
              >> I saw this problem first hand when Andreas Antonopolis got into a big
              >> dispute with some of the core developers over the press contacts.  The
              >> github made up their rules as they went along and simply ignored input from
              >> anyone outside their inner circle.  Since that time several people have told
              >> me they dropped out of participating in the github process.  The maintainers
              >> deleted some of my messages and I have been told I am banned form github.
              > I wasn't asking for an example of something that was rejected, there's
              > plenty of those.
              > You were saying people were opposing a change and jgarzik unilaterally added it.
              > When did that happen?
              >
              >> As for your proclamation at Bitcoin core != Bitcoin consensus rules, that is
              >> simply not true in practice.  There is one piece of software with one
              >> maintainer.  If you want it changed you have to convince that one person to
              >> approve the change.
              > There are many pieces of software and many maintainers, libbitcoin,
              > for example, is another full node implementation different from
              > Bitcoin core.
              > Also, to change Bitcoin core I don't need to convince anyone, I do it
              > all the time here https://github.com/jtimon/bitcoin
              >
              >> The core developers have the biggest influence by far to decide hard fork
              >> changes.  There is no other place to go.  While anyone can fork the code
              >> someone compare it to the river Thames.  if you don't like where the river
              >> runs you can dig a new one ... here is a spoon.  I can vote in elections but
              >> that does not mean the US government is "decentralized."  The core
              >> maintainer has decided on a hard fork change, he has decided not to do it.
              > Maybe Bitcoin core devs have more influence, but still, they don't
              > have the power to decide for everyone else what the consensus rules
              > are.
              > Your analogy is ridiculous, it literally takes seconds to fork bitcoin
              > and is as simple as clicking a button.
              > Wladimir has explained many times that he hasn't decided anything
              > because he can't decide that.
              > You keep insisting that he has control over consensus rules. Are you
              > doing it because you want him to be threaten, tortured, kidnapped or
              > killed?
              > If you don't, please stop making false claims about powers he doesn't
              > have because some bad guy could believe you.
              >
              >> I am under the
              >> impression that at least some of the developers (such as Garzik) don't
              >> actually hold that many bitcoins and don't have a large stake in the system
              >> yet they have significant control.
              > For the last time, they may have control over Bitcoin core (one
              > implementation of the Bitcoin protocol), not the consensus rules.
              > Why are anyone's bitcoin holdings relevant in any technical discussion?
              > Please, keep this kind of offtopic comments out.
              >
              >>   Anyone can attack the system by simply
              >> hiring a couple core developers and creating the gridlock we see now.
              > As said several times, yes, it is hard to define "uncontroversial"
              > without giving veto powers to any random guy on the internet.
              > But this is clearly not what is happening now. Most Bitcoin core devs
              > are against the current proposals, that cannot be considered
              > uncontroversial for any sane definition of it.
              >
              
              
              
              
              ^ permalink raw reply	[flat|nested] 51+ messages in thread

            • • * Re: [bitcoin-dev] BIP Process and Votes
                  2015-06-28 13:13             ` Milly Bitcoin
                @ 2015-06-28 15:35               ` Jorge Timón
                  2015-06-28 16:23                 ` Milly Bitcoin
                  0 siblings, 1 reply; 51+ messages in thread
                From: Jorge Timón @ 2015-06-28 15:35 UTC (permalink / raw)
                  To: Milly Bitcoin; +Cc: bitcoin-dev
                
                On Sun, Jun 28, 2015 at 3:13 PM, Milly Bitcoin <milly@bitcoins•info> wrote:
                > I never said something was approved by garzik added something after it was
                > opposed.  What I said was a proposal was made and 4 people commented on the
                > Github.  He then tweeted there was near universal approval before most
                > people even heard about the subject.  It was not controversial but i was
                > pointing out the arrogance of some of the developers.  He considers the
                > entire universe of Bitcoin stakeholders to be a very small group of
                > insiders, not the entire universe of Bitcoin users.  Another thing I have
                > seen on Github for bitcoin.org is how some the maintainers change the rules
                > on the fly.  Sometimes they say a proposal had no objections so it is
                > approved.  Other times they say a proposal has no support so it is rejected.
                
                Ok, I misunderstood.
                Well, the fact is that the number of capable reviewers is quite small.
                If more companies hired and trained more developers to become bitcoin
                core developers that situation could change, but that's where we are
                now.
                
                > You are also trying to say that the core developers actually have little
                > influence and are not "deciders" because anyone can fork the code.  That has
                > already been discussed at length and such an argument is faulty because
                > there is a constraint that your software is incompatible with everyone else.
                
                Only if you change the consensus rules (which are, in fact, a
                relatively small part of the code).
                Mike mantains Bitcoin XT and that's fine, Peter Todd maintains patches
                with the replace by fee policy, libbitcoin also changes many
                non-consensus things, there's code written in other languages...
                There's multiple counter-examples to your claim of that argument being faulty.
                Seriously, forking the project is just one click. You should try it
                out like at least 9627 other people have done.
                From there, you can pay your own developers (if you don't know how to
                code yourself) and maybe they're also fine being insulted by you as
                part of the job.
                What you still can't do is unilaterally change the consensus rules of
                a running p2p consensus system, because you cannot force the current
                users to run any software they don't want to run.
                
                > The issue is that there is no way right now to change the consensus rules
                > except to go through the core maintainer unless you get everybody on the
                > network to switch to your fork.  People who keep repeating that the software
                > development is "decentralized because you fork the code" without explaining
                > the constraints are just cultists.
                
                Please, stop the cultist crap. Maybe insulting people like that is how
                you got people to call you a troll.
                But, yes, you are right: there's no known mechanism for safely
                deploying controversial changes to the consensus rules
                
                > The discussion has nothing to do with who has the position now and I never
                > said he has "control over the consensus rules."  The maintainer has a very
                > large influence way beyond anyone else.  As for your claim that I want
                > someone hurt because I am explaining the process, that is ridiculous.  If
                > the Core maintainers did not have significant influence to change the
                > consensus rules then everybody would not be spending all this time lobbying
                > them to have them changed.
                
                Well, if you don't think he has control over the consensus rules we're
                advancing.
                I think that was implied from some of your previous claims. He is no
                "decider" on consensus changes.
                Insisting on it can indeed get him hurt, so I'm happy that you're
                taking that back (or clarifying that really wasn't your position).
                Influence is very relative and not only core devs have "influence".
                Maybe Andreas Antonopolous has more "influence" than I have because he
                is a more public figure?
                Well, that's fine I think. I don't see the point in discussing who has
                how much influence.
                
                > The outside influences and stake of the developer is a relevant topic.  The
                > same types of things are discussed on this list all the time in the context
                > of miners, users, merchants, and exchanges.  Again, the developers try to
                > place themselves on some kind of pedestal where they are the protectors and
                > pure and everyone else (miners, users, merchants) are abusers, spammers,
                > attackers, scammers, cheaters, etc.  It is Garzik who voluntarily made an
                > issue of how many bitcoins he holds and he made that issue in the same place
                > where he announces many of the technical issues.  It is very relevant that
                > he has a minimal stake in Bitcoin holdings yet he goes around making major
                > decisions about Bitcoin and trying to dictate who is allowed to participate
                > in discussions.  If a core developer has minimal stake in Bitcoin yet has
                > major veto power over code change that is a problem.
                
                Please, don't generalize. I don't think I put myself in any kind of pedestal.
                That is insulting to me and many others (you may not even know and
                you're insulting them).
                And I think my Bitcoin holdings are completely irrelevant when judging
                my contributions to the software: either they're good or not, and who
                I am or how many Bitcoins I have at any given time shouldn't matter.
                Again, nobody forces you to use our software, as said there's
                alternatives (including forking the project right now).
                
                > You are correct that you cannot give power to any person over the Internet
                > which is why some kind of process needs to be developed that does not
                > involve trying to convince one person to make the changes or a system that
                > depends on unwritten, ever-changing rules maintained by a handful of people.
                
                Well, for now the process we have is seeking consensus, and although
                our definition of "uncontroversial" is very vague, I think it is quite
                obvious when a proposed change is not "uncontroversial" (like in the
                block size debate).
                It seems to me that any other "formal process" would imply
                centralization in the decision making of the consensus rules (and from
                there you only have to corrupt that centralized organization to
                destroy Bitcoin).
                
                
                ^ permalink raw reply	[flat|nested] 51+ messages in thread

              • • * Re: [bitcoin-dev] BIP Process and Votes
                    2015-06-28 15:35               ` Jorge Timón
                  @ 2015-06-28 16:23                 ` Milly Bitcoin
                    2015-06-28 19:05                   ` Patrick Murck
                    0 siblings, 1 reply; 51+ messages in thread
                  From: Milly Bitcoin @ 2015-06-28 16:23 UTC (permalink / raw)
                    To: bitcoin-dev
                  
                  The core maintainer has always been in control of the consensus rules.  
                  Satoshi came up with the rules and put them in there.  Since then any 
                  changes to any part of the code go through the core maintainer.  It 
                  looks to me as if people are saying it somehow changed along the way 
                  because they don't want to hurt people's feeling, upset up, get them to 
                  quit, etc. Sure there are checks and balances and people don't have to 
                  use the main code base but if they change the consensus rules they are 
                  incompatible.
                  
                  The notion that because people can download different rules and run them 
                  is interesting from a theoretical perspective but that is constrained by 
                  the network effect.  I can say the US government is not the "decider" of 
                  laws because I can vote them out, recall them, challenge things in 
                  court, or secede and start my own country.  You can also say the 
                  judge/jury in a criminal court case is not a "decider" because the 
                  president can always issue a pardon.  But those points are generally not 
                  useful in a practical sense.
                  
                  The issue about the developers is the tremendous influence they have to 
                  veto any changes.  I don't have veto power yet I have more bitcoins than 
                  garzik says he has.  The whole Bitcoin software development system is 
                  subject to attack from just a couple of people who have this veto 
                  power.  With all the crying and moaning about centralization on this 
                  list I would think that would be a concern.
                  
                  Russ
                  
                  
                  
                  On 6/28/2015 11:35 AM, Jorge Timón wrote:
                  > On Sun, Jun 28, 2015 at 3:13 PM, Milly Bitcoin <milly@bitcoins•info> wrote:
                  >> I never said something was approved by garzik added something after it was
                  >> opposed.  What I said was a proposal was made and 4 people commented on the
                  >> Github.  He then tweeted there was near universal approval before most
                  >> people even heard about the subject.  It was not controversial but i was
                  >> pointing out the arrogance of some of the developers.  He considers the
                  >> entire universe of Bitcoin stakeholders to be a very small group of
                  >> insiders, not the entire universe of Bitcoin users.  Another thing I have
                  >> seen on Github for bitcoin.org is how some the maintainers change the rules
                  >> on the fly.  Sometimes they say a proposal had no objections so it is
                  >> approved.  Other times they say a proposal has no support so it is rejected.
                  > Ok, I misunderstood.
                  > Well, the fact is that the number of capable reviewers is quite small.
                  > If more companies hired and trained more developers to become bitcoin
                  > core developers that situation could change, but that's where we are
                  > now.
                  >
                  >> You are also trying to say that the core developers actually have little
                  >> influence and are not "deciders" because anyone can fork the code.  That has
                  >> already been discussed at length and such an argument is faulty because
                  >> there is a constraint that your software is incompatible with everyone else.
                  > Only if you change the consensus rules (which are, in fact, a
                  > relatively small part of the code).
                  > Mike mantains Bitcoin XT and that's fine, Peter Todd maintains patches
                  > with the replace by fee policy, libbitcoin also changes many
                  > non-consensus things, there's code written in other languages...
                  > There's multiple counter-examples to your claim of that argument being faulty.
                  > Seriously, forking the project is just one click. You should try it
                  > out like at least 9627 other people have done.
                  > >From there, you can pay your own developers (if you don't know how to
                  > code yourself) and maybe they're also fine being insulted by you as
                  > part of the job.
                  > What you still can't do is unilaterally change the consensus rules of
                  > a running p2p consensus system, because you cannot force the current
                  > users to run any software they don't want to run.
                  >
                  >> The issue is that there is no way right now to change the consensus rules
                  >> except to go through the core maintainer unless you get everybody on the
                  >> network to switch to your fork.  People who keep repeating that the software
                  >> development is "decentralized because you fork the code" without explaining
                  >> the constraints are just cultists.
                  > Please, stop the cultist crap. Maybe insulting people like that is how
                  > you got people to call you a troll.
                  > But, yes, you are right: there's no known mechanism for safely
                  > deploying controversial changes to the consensus rules
                  >
                  >> The discussion has nothing to do with who has the position now and I never
                  >> said he has "control over the consensus rules."  The maintainer has a very
                  >> large influence way beyond anyone else.  As for your claim that I want
                  >> someone hurt because I am explaining the process, that is ridiculous.  If
                  >> the Core maintainers did not have significant influence to change the
                  >> consensus rules then everybody would not be spending all this time lobbying
                  >> them to have them changed.
                  > Well, if you don't think he has control over the consensus rules we're
                  > advancing.
                  > I think that was implied from some of your previous claims. He is no
                  > "decider" on consensus changes.
                  > Insisting on it can indeed get him hurt, so I'm happy that you're
                  > taking that back (or clarifying that really wasn't your position).
                  > Influence is very relative and not only core devs have "influence".
                  > Maybe Andreas Antonopolous has more "influence" than I have because he
                  > is a more public figure?
                  > Well, that's fine I think. I don't see the point in discussing who has
                  > how much influence.
                  >
                  >> The outside influences and stake of the developer is a relevant topic.  The
                  >> same types of things are discussed on this list all the time in the context
                  >> of miners, users, merchants, and exchanges.  Again, the developers try to
                  >> place themselves on some kind of pedestal where they are the protectors and
                  >> pure and everyone else (miners, users, merchants) are abusers, spammers,
                  >> attackers, scammers, cheaters, etc.  It is Garzik who voluntarily made an
                  >> issue of how many bitcoins he holds and he made that issue in the same place
                  >> where he announces many of the technical issues.  It is very relevant that
                  >> he has a minimal stake in Bitcoin holdings yet he goes around making major
                  >> decisions about Bitcoin and trying to dictate who is allowed to participate
                  >> in discussions.  If a core developer has minimal stake in Bitcoin yet has
                  >> major veto power over code change that is a problem.
                  > Please, don't generalize. I don't think I put myself in any kind of pedestal.
                  > That is insulting to me and many others (you may not even know and
                  > you're insulting them).
                  > And I think my Bitcoin holdings are completely irrelevant when judging
                  > my contributions to the software: either they're good or not, and who
                  > I am or how many Bitcoins I have at any given time shouldn't matter.
                  > Again, nobody forces you to use our software, as said there's
                  > alternatives (including forking the project right now).
                  >
                  >> You are correct that you cannot give power to any person over the Internet
                  >> which is why some kind of process needs to be developed that does not
                  >> involve trying to convince one person to make the changes or a system that
                  >> depends on unwritten, ever-changing rules maintained by a handful of people.
                  > Well, for now the process we have is seeking consensus, and although
                  > our definition of "uncontroversial" is very vague, I think it is quite
                  > obvious when a proposed change is not "uncontroversial" (like in the
                  > block size debate).
                  > It seems to me that any other "formal process" would imply
                  > centralization in the decision making of the consensus rules (and from
                  > there you only have to corrupt that centralized organization to
                  > destroy Bitcoin).
                  >
                  
                  
                  
                  
                  ^ permalink raw reply	[flat|nested] 51+ messages in thread

                • • * Re: [bitcoin-dev] BIP Process and Votes
                      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:21                     ` NxtChg
                      0 siblings, 2 replies; 51+ messages in thread
                    From: Patrick Murck @ 2015-06-28 19:05 UTC (permalink / raw)
                      To: bitcoin-dev, Milly Bitcoin
                    
                    [-- Attachment #1: Type: text/plain, Size: 9559 bytes --]
                    
                    Wladimir has no more or less “power” to push change to the Bitcoin Core codebase than any other person with commit privileges to the GitHub repo. If I’m not mistaken there are 7 people with commit privileges and five of them are active. If Wladimir committed a change it could be reverted by any of the others. This is by design and ensures that changes will have reached some level of technical consensus before they are merged, among other things.
                    
                    Furthermore even assuming the Core Maintainer commits a change to Bitcoin Core (that isn’t reverted and that gets packaged up into the next code release) that still doesn’t push a change to the bitcoin network. There is no auto-update on Bitcoin Core so individuals and companies running Bitcoin Core software have to choose to upgrade. Further still, developers that maintain alternative implementations would have to decide to merge those changes to the codebase they are indepently maintaining (and their users would need to update, etc.).
                    
                    I understand why it might *seem* to be the case that the Core Maintainer is empowered to make changes to "teh Bitcoin" but the reality is that the Core Maintainer role is really about cat herding and project management of Bitcoin Core the open-source software project and not the bitcoin network. We’re lucky Wladimir has agreed to take on so much of the scut work to keep the project moving forward.
                    
                    The process might get ugly and inefficient but that’s the cost of having no wizard behind the curtain.
                    
                    -pm
                    
                    -- 
                    Patrick Murck
                    
                    On June 28, 2015 at 9:23:47 AM, Milly Bitcoin (milly@bitcoins•info) wrote:
                    
                    The core maintainer has always been in control of the consensus rules.  
                    Satoshi came up with the rules and put them in there. Since then any  
                    changes to any part of the code go through the core maintainer. It  
                    looks to me as if people are saying it somehow changed along the way  
                    because they don't want to hurt people's feeling, upset up, get them to  
                    quit, etc. Sure there are checks and balances and people don't have to  
                    use the main code base but if they change the consensus rules they are  
                    incompatible.
                    
                    The notion that because people can download different rules and run them  
                    is interesting from a theoretical perspective but that is constrained by  
                    the network effect. I can say the US government is not the "decider" of  
                    laws because I can vote them out, recall them, challenge things in  
                    court, or secede and start my own country. You can also say the  
                    judge/jury in a criminal court case is not a "decider" because the  
                    president can always issue a pardon. But those points are generally not  
                    useful in a practical sense.
                    
                    The issue about the developers is the tremendous influence they have to  
                    veto any changes. I don't have veto power yet I have more bitcoins than  
                    garzik says he has. The whole Bitcoin software development system is  
                    subject to attack from just a couple of people who have this veto  
                    power. With all the crying and moaning about centralization on this  
                    list I would think that would be a concern.
                    
                    Russ
                    
                    
                    
                    On 6/28/2015 11:35 AM, Jorge Timón wrote:
                    > On Sun, Jun 28, 2015 at 3:13 PM, Milly Bitcoin <milly@bitcoins•info> wrote:
                    >> I never said something was approved by garzik added something after it was
                    >> opposed. What I said was a proposal was made and 4 people commented on the
                    >> Github. He then tweeted there was near universal approval before most
                    >> people even heard about the subject. It was not controversial but i was
                    >> pointing out the arrogance of some of the developers. He considers the
                    >> entire universe of Bitcoin stakeholders to be a very small group of
                    >> insiders, not the entire universe of Bitcoin users. Another thing I have
                    >> seen on Github for bitcoin.org is how some the maintainers change the rules
                    >> on the fly. Sometimes they say a proposal had no objections so it is
                    >> approved. Other times they say a proposal has no support so it is rejected.
                    > Ok, I misunderstood.
                    > Well, the fact is that the number of capable reviewers is quite small.
                    > If more companies hired and trained more developers to become bitcoin
                    > core developers that situation could change, but that's where we are
                    > now.
                    >
                    >> You are also trying to say that the core developers actually have little
                    >> influence and are not "deciders" because anyone can fork the code. That has
                    >> already been discussed at length and such an argument is faulty because
                    >> there is a constraint that your software is incompatible with everyone else.
                    > Only if you change the consensus rules (which are, in fact, a
                    > relatively small part of the code).
                    > Mike mantains Bitcoin XT and that's fine, Peter Todd maintains patches
                    > with the replace by fee policy, libbitcoin also changes many
                    > non-consensus things, there's code written in other languages...
                    > There's multiple counter-examples to your claim of that argument being faulty.
                    > Seriously, forking the project is just one click. You should try it
                    > out like at least 9627 other people have done.
                    > >From there, you can pay your own developers (if you don't know how to
                    > code yourself) and maybe they're also fine being insulted by you as
                    > part of the job.
                    > What you still can't do is unilaterally change the consensus rules of
                    > a running p2p consensus system, because you cannot force the current
                    > users to run any software they don't want to run.
                    >
                    >> The issue is that there is no way right now to change the consensus rules
                    >> except to go through the core maintainer unless you get everybody on the
                    >> network to switch to your fork. People who keep repeating that the software
                    >> development is "decentralized because you fork the code" without explaining
                    >> the constraints are just cultists.
                    > Please, stop the cultist crap. Maybe insulting people like that is how
                    > you got people to call you a troll.
                    > But, yes, you are right: there's no known mechanism for safely
                    > deploying controversial changes to the consensus rules
                    >
                    >> The discussion has nothing to do with who has the position now and I never
                    >> said he has "control over the consensus rules." The maintainer has a very
                    >> large influence way beyond anyone else. As for your claim that I want
                    >> someone hurt because I am explaining the process, that is ridiculous. If
                    >> the Core maintainers did not have significant influence to change the
                    >> consensus rules then everybody would not be spending all this time lobbying
                    >> them to have them changed.
                    > Well, if you don't think he has control over the consensus rules we're
                    > advancing.
                    > I think that was implied from some of your previous claims. He is no
                    > "decider" on consensus changes.
                    > Insisting on it can indeed get him hurt, so I'm happy that you're
                    > taking that back (or clarifying that really wasn't your position).
                    > Influence is very relative and not only core devs have "influence".
                    > Maybe Andreas Antonopolous has more "influence" than I have because he
                    > is a more public figure?
                    > Well, that's fine I think. I don't see the point in discussing who has
                    > how much influence.
                    >
                    >> The outside influences and stake of the developer is a relevant topic. The
                    >> same types of things are discussed on this list all the time in the context
                    >> of miners, users, merchants, and exchanges. Again, the developers try to
                    >> place themselves on some kind of pedestal where they are the protectors and
                    >> pure and everyone else (miners, users, merchants) are abusers, spammers,
                    >> attackers, scammers, cheaters, etc. It is Garzik who voluntarily made an
                    >> issue of how many bitcoins he holds and he made that issue in the same place
                    >> where he announces many of the technical issues. It is very relevant that
                    >> he has a minimal stake in Bitcoin holdings yet he goes around making major
                    >> decisions about Bitcoin and trying to dictate who is allowed to participate
                    >> in discussions. If a core developer has minimal stake in Bitcoin yet has
                    >> major veto power over code change that is a problem.
                    > Please, don't generalize. I don't think I put myself in any kind of pedestal.
                    > That is insulting to me and many others (you may not even know and
                    > you're insulting them).
                    > And I think my Bitcoin holdings are completely irrelevant when judging
                    > my contributions to the software: either they're good or not, and who
                    > I am or how many Bitcoins I have at any given time shouldn't matter.
                    > Again, nobody forces you to use our software, as said there's
                    > alternatives (including forking the project right now).
                    >
                    >> You are correct that you cannot give power to any person over the Internet
                    >> which is why some kind of process needs to be developed that does not
                    >> involve trying to convince one person to make the changes or a system that
                    >> depends on unwritten, ever-changing rules maintained by a handful of people.
                    > Well, for now the process we have is seeking consensus, and although
                    > our definition of "uncontroversial" is very vague, I think it is quite
                    > obvious when a proposed change is not "uncontroversial" (like in the
                    > block size debate).
                    > It seems to me that any other "formal process" would imply
                    > centralization in the decision making of the consensus rules (and from
                    > there you only have to corrupt that centralized organization to
                    > destroy Bitcoin).
                    >
                    
                    
                    _______________________________________________
                    bitcoin-dev mailing list
                    bitcoin-dev@lists•linuxfoundation.org
                    https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                    
                    [-- Attachment #2: Type: text/html, Size: 12062 bytes --]
                    
                    ^ permalink raw reply	[flat|nested] 51+ messages in thread

                  • • * Re: [bitcoin-dev] BIP Process and Votes
                        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:21                     ` NxtChg
                        1 sibling, 1 reply; 51+ messages in thread
                      From: Milly Bitcoin @ 2015-06-28 20:10 UTC (permalink / raw)
                        To: bitcoin-dev
                      
                      [-- Attachment #1: Type: text/plain, Size: 11318 bytes --]
                      
                      I really don't know who has power to do what behind the scenes.  From 
                      what i understand, if push comes to shove, it is under the ultimate 
                      control of one person who can revoke commit privileges.  Maybe I am 
                      wrong about that but the point is most people don't know for sure.
                      
                      You are correct about the people having the choice to download but the 
                      influence of the official release is way beyond the influence of any 
                      forked release.  What that means in the real world is an open question 
                      and would be different depending upon the specific circumstances and 
                      difficult to predict.  It is significant power to have control over the 
                      official release at the present time.  If they did not have significant 
                      power people would not spend significant efforts lobbying them to make 
                      changes.  Any new developers hired by companies will do so because they 
                      can influence over the official release since that is the only incentive.
                      
                      It seems to me that this block size fork is only the beginning of the 
                      issues that will arise over the coming years.  Whatever powers the core 
                      maintainers have it is going to be exploited one way or another as time 
                      goes on.  Maybe there are enough feedback mechanisms to protect against 
                      that, I don't really know.
                      
                      Russ
                      
                      
                      
                      
                      
                      On 6/28/2015 3:05 PM, Patrick Murck wrote:
                      > Wladimir has no more or less “power” to push change to the Bitcoin 
                      > Core codebase than any other person with commit privileges to the 
                      > GitHub repo. If I’m not mistaken there are 7 people with commit 
                      > privileges and five of them are active. If Wladimir committed a change 
                      > it could be reverted by any of the others. This is by design and 
                      > ensures that changes will have reached some level of technical 
                      > consensus before they are merged, among other things.
                      >
                      > Furthermore even assuming the Core Maintainer commits a change to 
                      > Bitcoin Core (that isn’t reverted and that gets packaged up into the 
                      > next code release) that still doesn’t push a change to the bitcoin 
                      > network. There is no auto-update on Bitcoin Core so individuals and 
                      > companies running Bitcoin Core software have to choose to upgrade. 
                      > Further still, developers that maintain alternative implementations 
                      > would have to decide to merge those changes to the codebase they are 
                      > indepently maintaining (and their users would need to update, etc.).
                      >
                      > I understand why it might *seem* to be the case that the Core 
                      > Maintainer is empowered to make changes to "teh Bitcoin" but the 
                      > reality is that the Core Maintainer role is really about cat herding 
                      > and project management of Bitcoin Core the open-source software 
                      > project and not the bitcoin network. We’re lucky Wladimir has agreed 
                      > to take on so much of the scut work to keep the project moving forward.
                      >
                      > The process might get ugly and inefficient but that’s the cost of 
                      > having no wizard behind the curtain.
                      >
                      > -pm
                      >
                      > -- 
                      > Patrick Murck
                      >
                      > On June 28, 2015 at 9:23:47 AM, Milly Bitcoin (milly@bitcoins•info 
                      > <mailto:milly@bitcoins•info>) wrote:
                      >
                      >> The core maintainer has always been in control of the consensus rules.
                      >> Satoshi came up with the rules and put them in there. Since then any
                      >> changes to any part of the code go through the core maintainer. It
                      >> looks to me as if people are saying it somehow changed along the way
                      >> because they don't want to hurt people's feeling, upset up, get them to
                      >> quit, etc. Sure there are checks and balances and people don't have to
                      >> use the main code base but if they change the consensus rules they are
                      >> incompatible.
                      >>
                      >> The notion that because people can download different rules and run them
                      >> is interesting from a theoretical perspective but that is constrained by
                      >> the network effect. I can say the US government is not the "decider" of
                      >> laws because I can vote them out, recall them, challenge things in
                      >> court, or secede and start my own country. You can also say the
                      >> judge/jury in a criminal court case is not a "decider" because the
                      >> president can always issue a pardon. But those points are generally not
                      >> useful in a practical sense.
                      >>
                      >> The issue about the developers is the tremendous influence they have to
                      >> veto any changes. I don't have veto power yet I have more bitcoins than
                      >> garzik says he has. The whole Bitcoin software development system is
                      >> subject to attack from just a couple of people who have this veto
                      >> power. With all the crying and moaning about centralization on this
                      >> list I would think that would be a concern.
                      >>
                      >> Russ
                      >>
                      >>
                      >>
                      >> On 6/28/2015 11:35 AM, Jorge Timón wrote:
                      >> > On Sun, Jun 28, 2015 at 3:13 PM, Milly Bitcoin 
                      >> <milly@bitcoins•info> wrote:
                      >> >> I never said something was approved by garzik added something 
                      >> after it was
                      >> >> opposed. What I said was a proposal was made and 4 people 
                      >> commented on the
                      >> >> Github. He then tweeted there was near universal approval before most
                      >> >> people even heard about the subject. It was not controversial but 
                      >> i was
                      >> >> pointing out the arrogance of some of the developers. He considers the
                      >> >> entire universe of Bitcoin stakeholders to be a very small group of
                      >> >> insiders, not the entire universe of Bitcoin users. Another thing 
                      >> I have
                      >> >> seen on Github for bitcoin.org is how some the maintainers change 
                      >> the rules
                      >> >> on the fly. Sometimes they say a proposal had no objections so it is
                      >> >> approved. Other times they say a proposal has no support so it is 
                      >> rejected.
                      >> > Ok, I misunderstood.
                      >> > Well, the fact is that the number of capable reviewers is quite small.
                      >> > If more companies hired and trained more developers to become bitcoin
                      >> > core developers that situation could change, but that's where we are
                      >> > now.
                      >> >
                      >> >> You are also trying to say that the core developers actually have 
                      >> little
                      >> >> influence and are not "deciders" because anyone can fork the code. 
                      >> That has
                      >> >> already been discussed at length and such an argument is faulty 
                      >> because
                      >> >> there is a constraint that your software is incompatible with 
                      >> everyone else.
                      >> > Only if you change the consensus rules (which are, in fact, a
                      >> > relatively small part of the code).
                      >> > Mike mantains Bitcoin XT and that's fine, Peter Todd maintains patches
                      >> > with the replace by fee policy, libbitcoin also changes many
                      >> > non-consensus things, there's code written in other languages...
                      >> > There's multiple counter-examples to your claim of that argument 
                      >> being faulty.
                      >> > Seriously, forking the project is just one click. You should try it
                      >> > out like at least 9627 other people have done.
                      >> > >From there, you can pay your own developers (if you don't know how to
                      >> > code yourself) and maybe they're also fine being insulted by you as
                      >> > part of the job.
                      >> > What you still can't do is unilaterally change the consensus rules of
                      >> > a running p2p consensus system, because you cannot force the current
                      >> > users to run any software they don't want to run.
                      >> >
                      >> >> The issue is that there is no way right now to change the 
                      >> consensus rules
                      >> >> except to go through the core maintainer unless you get everybody 
                      >> on the
                      >> >> network to switch to your fork. People who keep repeating that the 
                      >> software
                      >> >> development is "decentralized because you fork the code" without 
                      >> explaining
                      >> >> the constraints are just cultists.
                      >> > Please, stop the cultist crap. Maybe insulting people like that is how
                      >> > you got people to call you a troll.
                      >> > But, yes, you are right: there's no known mechanism for safely
                      >> > deploying controversial changes to the consensus rules
                      >> >
                      >> >> The discussion has nothing to do with who has the position now and 
                      >> I never
                      >> >> said he has "control over the consensus rules." The maintainer has 
                      >> a very
                      >> >> large influence way beyond anyone else. As for your claim that I want
                      >> >> someone hurt because I am explaining the process, that is 
                      >> ridiculous. If
                      >> >> the Core maintainers did not have significant influence to change the
                      >> >> consensus rules then everybody would not be spending all this time 
                      >> lobbying
                      >> >> them to have them changed.
                      >> > Well, if you don't think he has control over the consensus rules we're
                      >> > advancing.
                      >> > I think that was implied from some of your previous claims. He is no
                      >> > "decider" on consensus changes.
                      >> > Insisting on it can indeed get him hurt, so I'm happy that you're
                      >> > taking that back (or clarifying that really wasn't your position).
                      >> > Influence is very relative and not only core devs have "influence".
                      >> > Maybe Andreas Antonopolous has more "influence" than I have because he
                      >> > is a more public figure?
                      >> > Well, that's fine I think. I don't see the point in discussing who has
                      >> > how much influence.
                      >> >
                      >> >> The outside influences and stake of the developer is a relevant 
                      >> topic. The
                      >> >> same types of things are discussed on this list all the time in 
                      >> the context
                      >> >> of miners, users, merchants, and exchanges. Again, the developers 
                      >> try to
                      >> >> place themselves on some kind of pedestal where they are the 
                      >> protectors and
                      >> >> pure and everyone else (miners, users, merchants) are abusers, 
                      >> spammers,
                      >> >> attackers, scammers, cheaters, etc. It is Garzik who voluntarily 
                      >> made an
                      >> >> issue of how many bitcoins he holds and he made that issue in the 
                      >> same place
                      >> >> where he announces many of the technical issues. It is very 
                      >> relevant that
                      >> >> he has a minimal stake in Bitcoin holdings yet he goes around 
                      >> making major
                      >> >> decisions about Bitcoin and trying to dictate who is allowed to 
                      >> participate
                      >> >> in discussions. If a core developer has minimal stake in Bitcoin 
                      >> yet has
                      >> >> major veto power over code change that is a problem.
                      >> > Please, don't generalize. I don't think I put myself in any kind of 
                      >> pedestal.
                      >> > That is insulting to me and many others (you may not even know and
                      >> > you're insulting them).
                      >> > And I think my Bitcoin holdings are completely irrelevant when judging
                      >> > my contributions to the software: either they're good or not, and who
                      >> > I am or how many Bitcoins I have at any given time shouldn't matter.
                      >> > Again, nobody forces you to use our software, as said there's
                      >> > alternatives (including forking the project right now).
                      >> >
                      >> >> You are correct that you cannot give power to any person over the 
                      >> Internet
                      >> >> which is why some kind of process needs to be developed that does not
                      >> >> involve trying to convince one person to make the changes or a 
                      >> system that
                      >> >> depends on unwritten, ever-changing rules maintained by a handful 
                      >> of people.
                      >> > Well, for now the process we have is seeking consensus, and although
                      >> > our definition of "uncontroversial" is very vague, I think it is quite
                      >> > obvious when a proposed change is not "uncontroversial" (like in the
                      >> > block size debate).
                      >> > It seems to me that any other "formal process" would imply
                      >> > centralization in the decision making of the consensus rules (and from
                      >> > there you only have to corrupt that centralized organization to
                      >> > destroy Bitcoin).
                      >> >
                      >>
                      >>
                      >> _______________________________________________
                      >> bitcoin-dev mailing list
                      >> bitcoin-dev@lists•linuxfoundation.org
                      >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                      
                      
                      [-- Attachment #2: Type: text/html, Size: 17967 bytes --]
                      
                      ^ permalink raw reply	[flat|nested] 51+ messages in thread

                    • • * Re: [bitcoin-dev] BIP Process and Votes
                          2015-06-28 20:10                     ` Milly Bitcoin
                        @ 2015-06-28 20:16                       ` Mark Friedenbach
                          2015-06-28 20:26                         ` Ricardo Filipe
                          2015-06-28 23:52                         ` Milly Bitcoin
                          0 siblings, 2 replies; 51+ messages in thread
                        From: Mark Friedenbach @ 2015-06-28 20:16 UTC (permalink / raw)
                          To: Milly Bitcoin; +Cc: bitcoin-dev
                        
                        [-- Attachment #1: Type: text/plain, Size: 11910 bytes --]
                        
                        Milly you are absolutely wrong as has been pointed out by numerous people
                        numerous times. Your idea of how bitcoin development decision making works
                        is demonstrably false. Please stop filling our inboxes with trolling
                        accusations, or else this will have to become a moderated list. And no one
                        wants that.
                        On Jun 28, 2015 1:11 PM, "Milly Bitcoin" <milly@bitcoins•info> wrote:
                        
                        >  I really don't know who has power to do what behind the scenes.  From
                        > what i understand, if push comes to shove, it is under the ultimate control
                        > of one person who can revoke commit privileges.  Maybe I am wrong about
                        > that but the point is most people don't know for sure.
                        >
                        > You are correct about the people having the choice to download but the
                        > influence of the official release is way beyond the influence of any forked
                        > release.  What that means in the real world is an open question and would
                        > be different depending upon the specific circumstances and difficult to
                        > predict.  It is significant power to have control over the official release
                        > at the present time.  If they did not have significant power people would
                        > not spend significant efforts lobbying them to make changes.  Any new
                        > developers hired by companies will do so because they can influence over
                        > the official release since that is the only incentive.
                        >
                        > It seems to me that this block size fork is only the beginning of the
                        > issues that will arise over the coming years.  Whatever powers the core
                        > maintainers have it is going to be exploited one way or another as time
                        > goes on.  Maybe there are enough feedback mechanisms to protect against
                        > that, I don't really know.
                        >
                        > Russ
                        >
                        >
                        >
                        >
                        >
                        > On 6/28/2015 3:05 PM, Patrick Murck wrote:
                        >
                        > Wladimir has no more or less “power” to push change to the Bitcoin Core
                        > codebase than any other person with commit privileges to the GitHub repo.
                        > If I’m not mistaken there are 7 people with commit privileges and five of
                        > them are active. If Wladimir committed a change it could be reverted by any
                        > of the others. This is by design and ensures that changes will have reached
                        > some level of technical consensus before they are merged, among other
                        > things.
                        >
                        >  Furthermore even assuming the Core Maintainer commits a change to
                        > Bitcoin Core (that isn’t reverted and that gets packaged up into the next
                        > code release) that still doesn’t push a change to the bitcoin network.
                        > There is no auto-update on Bitcoin Core so individuals and companies
                        > running Bitcoin Core software have to choose to upgrade. Further still,
                        > developers that maintain alternative implementations would have to decide
                        > to merge those changes to the codebase they are indepently maintaining (and
                        > their users would need to update, etc.).
                        >
                        >  I understand why it might *seem* to be the case that the Core Maintainer
                        > is empowered to make changes to "teh Bitcoin" but the reality is that the
                        > Core Maintainer role is really about cat herding and project management of
                        > Bitcoin Core the open-source software project and not the bitcoin network.
                        > We’re lucky Wladimir has agreed to take on so much of the scut work to keep
                        > the project moving forward.
                        >
                        >  The process might get ugly and inefficient but that’s the cost of having
                        > no wizard behind the curtain.
                        >
                        >  -pm
                        >
                        > --
                        > Patrick Murck
                        >
                        > On June 28, 2015 at 9:23:47 AM, Milly Bitcoin (milly@bitcoins•info) wrote:
                        >
                        >  The core maintainer has always been in control of the consensus rules.
                        > Satoshi came up with the rules and put them in there. Since then any
                        > changes to any part of the code go through the core maintainer. It
                        > looks to me as if people are saying it somehow changed along the way
                        > because they don't want to hurt people's feeling, upset up, get them to
                        > quit, etc. Sure there are checks and balances and people don't have to
                        > use the main code base but if they change the consensus rules they are
                        > incompatible.
                        >
                        > The notion that because people can download different rules and run them
                        > is interesting from a theoretical perspective but that is constrained by
                        > the network effect. I can say the US government is not the "decider" of
                        > laws because I can vote them out, recall them, challenge things in
                        > court, or secede and start my own country. You can also say the
                        > judge/jury in a criminal court case is not a "decider" because the
                        > president can always issue a pardon. But those points are generally not
                        > useful in a practical sense.
                        >
                        > The issue about the developers is the tremendous influence they have to
                        > veto any changes. I don't have veto power yet I have more bitcoins than
                        > garzik says he has. The whole Bitcoin software development system is
                        > subject to attack from just a couple of people who have this veto
                        > power. With all the crying and moaning about centralization on this
                        > list I would think that would be a concern.
                        >
                        > Russ
                        >
                        >
                        >
                        > On 6/28/2015 11:35 AM, Jorge Timón wrote:
                        > > On Sun, Jun 28, 2015 at 3:13 PM, Milly Bitcoin <milly@bitcoins•info>
                        > <milly@bitcoins•info> wrote:
                        > >> I never said something was approved by garzik added something after it
                        > was
                        > >> opposed. What I said was a proposal was made and 4 people commented on
                        > the
                        > >> Github. He then tweeted there was near universal approval before most
                        > >> people even heard about the subject. It was not controversial but i was
                        > >> pointing out the arrogance of some of the developers. He considers the
                        > >> entire universe of Bitcoin stakeholders to be a very small group of
                        > >> insiders, not the entire universe of Bitcoin users. Another thing I have
                        > >> seen on Github for bitcoin.org is how some the maintainers change the
                        > rules
                        > >> on the fly. Sometimes they say a proposal had no objections so it is
                        > >> approved. Other times they say a proposal has no support so it is
                        > rejected.
                        > > Ok, I misunderstood.
                        > > Well, the fact is that the number of capable reviewers is quite small.
                        > > If more companies hired and trained more developers to become bitcoin
                        > > core developers that situation could change, but that's where we are
                        > > now.
                        > >
                        > >> You are also trying to say that the core developers actually have little
                        > >> influence and are not "deciders" because anyone can fork the code. That
                        > has
                        > >> already been discussed at length and such an argument is faulty because
                        > >> there is a constraint that your software is incompatible with everyone
                        > else.
                        > > Only if you change the consensus rules (which are, in fact, a
                        > > relatively small part of the code).
                        > > Mike mantains Bitcoin XT and that's fine, Peter Todd maintains patches
                        > > with the replace by fee policy, libbitcoin also changes many
                        > > non-consensus things, there's code written in other languages...
                        > > There's multiple counter-examples to your claim of that argument being
                        > faulty.
                        > > Seriously, forking the project is just one click. You should try it
                        > > out like at least 9627 other people have done.
                        > > >From there, you can pay your own developers (if you don't know how to
                        > > code yourself) and maybe they're also fine being insulted by you as
                        > > part of the job.
                        > > What you still can't do is unilaterally change the consensus rules of
                        > > a running p2p consensus system, because you cannot force the current
                        > > users to run any software they don't want to run.
                        > >
                        > >> The issue is that there is no way right now to change the consensus
                        > rules
                        > >> except to go through the core maintainer unless you get everybody on the
                        > >> network to switch to your fork. People who keep repeating that the
                        > software
                        > >> development is "decentralized because you fork the code" without
                        > explaining
                        > >> the constraints are just cultists.
                        > > Please, stop the cultist crap. Maybe insulting people like that is how
                        > > you got people to call you a troll.
                        > > But, yes, you are right: there's no known mechanism for safely
                        > > deploying controversial changes to the consensus rules
                        > >
                        > >> The discussion has nothing to do with who has the position now and I
                        > never
                        > >> said he has "control over the consensus rules." The maintainer has a
                        > very
                        > >> large influence way beyond anyone else. As for your claim that I want
                        > >> someone hurt because I am explaining the process, that is ridiculous. If
                        > >> the Core maintainers did not have significant influence to change the
                        > >> consensus rules then everybody would not be spending all this time
                        > lobbying
                        > >> them to have them changed.
                        > > Well, if you don't think he has control over the consensus rules we're
                        > > advancing.
                        > > I think that was implied from some of your previous claims. He is no
                        > > "decider" on consensus changes.
                        > > Insisting on it can indeed get him hurt, so I'm happy that you're
                        > > taking that back (or clarifying that really wasn't your position).
                        > > Influence is very relative and not only core devs have "influence".
                        > > Maybe Andreas Antonopolous has more "influence" than I have because he
                        > > is a more public figure?
                        > > Well, that's fine I think. I don't see the point in discussing who has
                        > > how much influence.
                        > >
                        > >> The outside influences and stake of the developer is a relevant topic.
                        > The
                        > >> same types of things are discussed on this list all the time in the
                        > context
                        > >> of miners, users, merchants, and exchanges. Again, the developers try to
                        > >> place themselves on some kind of pedestal where they are the protectors
                        > and
                        > >> pure and everyone else (miners, users, merchants) are abusers, spammers,
                        > >> attackers, scammers, cheaters, etc. It is Garzik who voluntarily made an
                        > >> issue of how many bitcoins he holds and he made that issue in the same
                        > place
                        > >> where he announces many of the technical issues. It is very relevant
                        > that
                        > >> he has a minimal stake in Bitcoin holdings yet he goes around making
                        > major
                        > >> decisions about Bitcoin and trying to dictate who is allowed to
                        > participate
                        > >> in discussions. If a core developer has minimal stake in Bitcoin yet has
                        > >> major veto power over code change that is a problem.
                        > > Please, don't generalize. I don't think I put myself in any kind of
                        > pedestal.
                        > > That is insulting to me and many others (you may not even know and
                        > > you're insulting them).
                        > > And I think my Bitcoin holdings are completely irrelevant when judging
                        > > my contributions to the software: either they're good or not, and who
                        > > I am or how many Bitcoins I have at any given time shouldn't matter.
                        > > Again, nobody forces you to use our software, as said there's
                        > > alternatives (including forking the project right now).
                        > >
                        > >> You are correct that you cannot give power to any person over the
                        > Internet
                        > >> which is why some kind of process needs to be developed that does not
                        > >> involve trying to convince one person to make the changes or a system
                        > that
                        > >> depends on unwritten, ever-changing rules maintained by a handful of
                        > people.
                        > > Well, for now the process we have is seeking consensus, and although
                        > > our definition of "uncontroversial" is very vague, I think it is quite
                        > > obvious when a proposed change is not "uncontroversial" (like in the
                        > > block size debate).
                        > > It seems to me that any other "formal process" would imply
                        > > centralization in the decision making of the consensus rules (and from
                        > > there you only have to corrupt that centralized organization to
                        > > destroy Bitcoin).
                        > >
                        >
                        >
                        > _______________________________________________
                        > 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: 18737 bytes --]
                        
                        ^ permalink raw reply	[flat|nested] 51+ messages in thread

                      • • * Re: [bitcoin-dev] BIP Process and Votes
                            2015-06-28 20:16                       ` Mark Friedenbach
                          @ 2015-06-28 20:26                         ` Ricardo Filipe
                            2015-06-28 21:00                           ` Adam Back
                            2015-06-28 23:52                         ` Milly Bitcoin
                            1 sibling, 1 reply; 51+ messages in thread
                          From: Ricardo Filipe @ 2015-06-28 20:26 UTC (permalink / raw)
                            To: Mark Friedenbach; +Cc: bitcoin-dev
                          
                          Then demonstrate it. He has been raising quite valid points over the
                          maintenance of bitcoin core.
                          
                          This is the same problem as the changes to consensus rules in bitcoin
                          core: they aren't explicitly defined for the external audience. Thus
                          forcing people to lobby for hard forks.
                          
                          2015-06-28 21:16 GMT+01:00 Mark Friedenbach <mark@friedenbach•org>:
                          > Milly you are absolutely wrong as has been pointed out by numerous people
                          > numerous times. Your idea of how bitcoin development decision making works
                          > is demonstrably false. Please stop filling our inboxes with trolling
                          > accusations, or else this will have to become a moderated list. And no one
                          > wants that.
                          >
                          > On Jun 28, 2015 1:11 PM, "Milly Bitcoin" <milly@bitcoins•info> wrote:
                          >>
                          >> I really don't know who has power to do what behind the scenes.  From what
                          >> i understand, if push comes to shove, it is under the ultimate control of
                          >> one person who can revoke commit privileges.  Maybe I am wrong about that
                          >> but the point is most people don't know for sure.
                          >>
                          >> You are correct about the people having the choice to download but the
                          >> influence of the official release is way beyond the influence of any forked
                          >> release.  What that means in the real world is an open question and would be
                          >> different depending upon the specific circumstances and difficult to
                          >> predict.  It is significant power to have control over the official release
                          >> at the present time.  If they did not have significant power people would
                          >> not spend significant efforts lobbying them to make changes.  Any new
                          >> developers hired by companies will do so because they can influence over the
                          >> official release since that is the only incentive.
                          >>
                          >> It seems to me that this block size fork is only the beginning of the
                          >> issues that will arise over the coming years.  Whatever powers the core
                          >> maintainers have it is going to be exploited one way or another as time goes
                          >> on.  Maybe there are enough feedback mechanisms to protect against that, I
                          >> don't really know.
                          >>
                          >> Russ
                          >>
                          >>
                          >>
                          >>
                          >>
                          >> On 6/28/2015 3:05 PM, Patrick Murck wrote:
                          >>
                          >> Wladimir has no more or less “power” to push change to the Bitcoin Core
                          >> codebase than any other person with commit privileges to the GitHub repo. If
                          >> I’m not mistaken there are 7 people with commit privileges and five of them
                          >> are active. If Wladimir committed a change it could be reverted by any of
                          >> the others. This is by design and ensures that changes will have reached
                          >> some level of technical consensus before they are merged, among other
                          >> things.
                          >>
                          >> Furthermore even assuming the Core Maintainer commits a change to Bitcoin
                          >> Core (that isn’t reverted and that gets packaged up into the next code
                          >> release) that still doesn’t push a change to the bitcoin network. There is
                          >> no auto-update on Bitcoin Core so individuals and companies running Bitcoin
                          >> Core software have to choose to upgrade. Further still, developers that
                          >> maintain alternative implementations would have to decide to merge those
                          >> changes to the codebase they are indepently maintaining (and their users
                          >> would need to update, etc.).
                          >>
                          >> I understand why it might *seem* to be the case that the Core Maintainer
                          >> is empowered to make changes to "teh Bitcoin" but the reality is that the
                          >> Core Maintainer role is really about cat herding and project management of
                          >> Bitcoin Core the open-source software project and not the bitcoin network.
                          >> We’re lucky Wladimir has agreed to take on so much of the scut work to keep
                          >> the project moving forward.
                          >>
                          >> The process might get ugly and inefficient but that’s the cost of having
                          >> no wizard behind the curtain.
                          >>
                          >> -pm
                          >>
                          >> --
                          >> Patrick Murck
                          >>
                          >> On June 28, 2015 at 9:23:47 AM, Milly Bitcoin (milly@bitcoins•info) wrote:
                          >>
                          >> The core maintainer has always been in control of the consensus rules.
                          >> Satoshi came up with the rules and put them in there. Since then any
                          >> changes to any part of the code go through the core maintainer. It
                          >> looks to me as if people are saying it somehow changed along the way
                          >> because they don't want to hurt people's feeling, upset up, get them to
                          >> quit, etc. Sure there are checks and balances and people don't have to
                          >> use the main code base but if they change the consensus rules they are
                          >> incompatible.
                          >>
                          >> The notion that because people can download different rules and run them
                          >> is interesting from a theoretical perspective but that is constrained by
                          >> the network effect. I can say the US government is not the "decider" of
                          >> laws because I can vote them out, recall them, challenge things in
                          >> court, or secede and start my own country. You can also say the
                          >> judge/jury in a criminal court case is not a "decider" because the
                          >> president can always issue a pardon. But those points are generally not
                          >> useful in a practical sense.
                          >>
                          >> The issue about the developers is the tremendous influence they have to
                          >> veto any changes. I don't have veto power yet I have more bitcoins than
                          >> garzik says he has. The whole Bitcoin software development system is
                          >> subject to attack from just a couple of people who have this veto
                          >> power. With all the crying and moaning about centralization on this
                          >> list I would think that would be a concern.
                          >>
                          >> Russ
                          >>
                          >>
                          >>
                          >> On 6/28/2015 11:35 AM, Jorge Timón wrote:
                          >> > On Sun, Jun 28, 2015 at 3:13 PM, Milly Bitcoin <milly@bitcoins•info>
                          >> > wrote:
                          >> >> I never said something was approved by garzik added something after it
                          >> >> was
                          >> >> opposed. What I said was a proposal was made and 4 people commented on
                          >> >> the
                          >> >> Github. He then tweeted there was near universal approval before most
                          >> >> people even heard about the subject. It was not controversial but i was
                          >> >> pointing out the arrogance of some of the developers. He considers the
                          >> >> entire universe of Bitcoin stakeholders to be a very small group of
                          >> >> insiders, not the entire universe of Bitcoin users. Another thing I
                          >> >> have
                          >> >> seen on Github for bitcoin.org is how some the maintainers change the
                          >> >> rules
                          >> >> on the fly. Sometimes they say a proposal had no objections so it is
                          >> >> approved. Other times they say a proposal has no support so it is
                          >> >> rejected.
                          >> > Ok, I misunderstood.
                          >> > Well, the fact is that the number of capable reviewers is quite small.
                          >> > If more companies hired and trained more developers to become bitcoin
                          >> > core developers that situation could change, but that's where we are
                          >> > now.
                          >> >
                          >> >> You are also trying to say that the core developers actually have
                          >> >> little
                          >> >> influence and are not "deciders" because anyone can fork the code. That
                          >> >> has
                          >> >> already been discussed at length and such an argument is faulty because
                          >> >> there is a constraint that your software is incompatible with everyone
                          >> >> else.
                          >> > Only if you change the consensus rules (which are, in fact, a
                          >> > relatively small part of the code).
                          >> > Mike mantains Bitcoin XT and that's fine, Peter Todd maintains patches
                          >> > with the replace by fee policy, libbitcoin also changes many
                          >> > non-consensus things, there's code written in other languages...
                          >> > There's multiple counter-examples to your claim of that argument being
                          >> > faulty.
                          >> > Seriously, forking the project is just one click. You should try it
                          >> > out like at least 9627 other people have done.
                          >> > >From there, you can pay your own developers (if you don't know how to
                          >> > code yourself) and maybe they're also fine being insulted by you as
                          >> > part of the job.
                          >> > What you still can't do is unilaterally change the consensus rules of
                          >> > a running p2p consensus system, because you cannot force the current
                          >> > users to run any software they don't want to run.
                          >> >
                          >> >> The issue is that there is no way right now to change the consensus
                          >> >> rules
                          >> >> except to go through the core maintainer unless you get everybody on
                          >> >> the
                          >> >> network to switch to your fork. People who keep repeating that the
                          >> >> software
                          >> >> development is "decentralized because you fork the code" without
                          >> >> explaining
                          >> >> the constraints are just cultists.
                          >> > Please, stop the cultist crap. Maybe insulting people like that is how
                          >> > you got people to call you a troll.
                          >> > But, yes, you are right: there's no known mechanism for safely
                          >> > deploying controversial changes to the consensus rules
                          >> >
                          >> >> The discussion has nothing to do with who has the position now and I
                          >> >> never
                          >> >> said he has "control over the consensus rules." The maintainer has a
                          >> >> very
                          >> >> large influence way beyond anyone else. As for your claim that I want
                          >> >> someone hurt because I am explaining the process, that is ridiculous.
                          >> >> If
                          >> >> the Core maintainers did not have significant influence to change the
                          >> >> consensus rules then everybody would not be spending all this time
                          >> >> lobbying
                          >> >> them to have them changed.
                          >> > Well, if you don't think he has control over the consensus rules we're
                          >> > advancing.
                          >> > I think that was implied from some of your previous claims. He is no
                          >> > "decider" on consensus changes.
                          >> > Insisting on it can indeed get him hurt, so I'm happy that you're
                          >> > taking that back (or clarifying that really wasn't your position).
                          >> > Influence is very relative and not only core devs have "influence".
                          >> > Maybe Andreas Antonopolous has more "influence" than I have because he
                          >> > is a more public figure?
                          >> > Well, that's fine I think. I don't see the point in discussing who has
                          >> > how much influence.
                          >> >
                          >> >> The outside influences and stake of the developer is a relevant topic.
                          >> >> The
                          >> >> same types of things are discussed on this list all the time in the
                          >> >> context
                          >> >> of miners, users, merchants, and exchanges. Again, the developers try
                          >> >> to
                          >> >> place themselves on some kind of pedestal where they are the protectors
                          >> >> and
                          >> >> pure and everyone else (miners, users, merchants) are abusers,
                          >> >> spammers,
                          >> >> attackers, scammers, cheaters, etc. It is Garzik who voluntarily made
                          >> >> an
                          >> >> issue of how many bitcoins he holds and he made that issue in the same
                          >> >> place
                          >> >> where he announces many of the technical issues. It is very relevant
                          >> >> that
                          >> >> he has a minimal stake in Bitcoin holdings yet he goes around making
                          >> >> major
                          >> >> decisions about Bitcoin and trying to dictate who is allowed to
                          >> >> participate
                          >> >> in discussions. If a core developer has minimal stake in Bitcoin yet
                          >> >> has
                          >> >> major veto power over code change that is a problem.
                          >> > Please, don't generalize. I don't think I put myself in any kind of
                          >> > pedestal.
                          >> > That is insulting to me and many others (you may not even know and
                          >> > you're insulting them).
                          >> > And I think my Bitcoin holdings are completely irrelevant when judging
                          >> > my contributions to the software: either they're good or not, and who
                          >> > I am or how many Bitcoins I have at any given time shouldn't matter.
                          >> > Again, nobody forces you to use our software, as said there's
                          >> > alternatives (including forking the project right now).
                          >> >
                          >> >> You are correct that you cannot give power to any person over the
                          >> >> Internet
                          >> >> which is why some kind of process needs to be developed that does not
                          >> >> involve trying to convince one person to make the changes or a system
                          >> >> that
                          >> >> depends on unwritten, ever-changing rules maintained by a handful of
                          >> >> people.
                          >> > Well, for now the process we have is seeking consensus, and although
                          >> > our definition of "uncontroversial" is very vague, I think it is quite
                          >> > obvious when a proposed change is not "uncontroversial" (like in the
                          >> > block size debate).
                          >> > It seems to me that any other "formal process" would imply
                          >> > centralization in the decision making of the consensus rules (and from
                          >> > there you only have to corrupt that centralized organization to
                          >> > destroy Bitcoin).
                          >> >
                          >>
                          >>
                          >> _______________________________________________
                          >> 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
                          >
                          
                          
                          ^ permalink raw reply	[flat|nested] 51+ messages in thread

                        • • * Re: [bitcoin-dev] BIP Process and Votes
                              2015-06-28 20:26                         ` Ricardo Filipe
                            @ 2015-06-28 21:00                           ` Adam Back
                              2015-06-29  0:13                             ` Milly Bitcoin
                              0 siblings, 1 reply; 51+ messages in thread
                            From: Adam Back @ 2015-06-28 21:00 UTC (permalink / raw)
                              To: Ricardo Filipe; +Cc: bitcoin-dev
                            
                            I think we need a second mailing list: bitcoin-process for people to
                            learn about bitcoin process.
                            
                            And someone to write a FAQ on it's sign up page so people interested
                            could at least discuss from a starting point of understanding how and
                            why it works the way it does!
                            
                            Adam
                            
                            
                            ^ permalink raw reply	[flat|nested] 51+ messages in thread

                          • • * Re: [bitcoin-dev] BIP Process and Votes
                                2015-06-28 21:00                           ` Adam Back
                              @ 2015-06-29  0:13                             ` Milly Bitcoin
                                2015-06-29  0:23                               ` Andrew Lapp
                                0 siblings, 1 reply; 51+ messages in thread
                              From: Milly Bitcoin @ 2015-06-29  0:13 UTC (permalink / raw)
                                To: bitcoin-dev
                              
                              The concern with that is that any FAQ will be developed by the same 
                              small group that controls the github now so they will spin it in an 
                              unrealistic way.  You see the problem now with the Bitcoin wiki.  While 
                              the wiki has some valuable information, it also has a number of 
                              incorrect and cult-like claims about how Bitcoin works.  Tim Swanson has 
                              made some good videos that describe some of the misinformation that 
                              often gets repeated on the Wiki and other places.
                              
                              I had suggested the info on the Wiki be reevaluated piece-by-piece and 
                              moved to Bitcoin.org but the developers didn't like that. Attempts to 
                              edit the Wiki often leads to the articles being defaced by the 
                              maintainers so that is a waste of time.
                              
                              Russ
                              
                              
                              
                              On 6/28/2015 5:00 PM, Adam Back wrote:
                              > I think we need a second mailing list: bitcoin-process for people to
                              > learn about bitcoin process.
                              >
                              > And someone to write a FAQ on it's sign up page so people interested
                              > could at least discuss from a starting point of understanding how and
                              > why it works the way it does!
                              >
                              > Adam
                              > _______________________________________________
                              > bitcoin-dev mailing list
                              > bitcoin-dev@lists•linuxfoundation.org
                              > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                              >
                              
                              
                              
                              
                              ^ permalink raw reply	[flat|nested] 51+ messages in thread

                            • • * Re: [bitcoin-dev] BIP Process and Votes
                                  2015-06-29  0:13                             ` Milly Bitcoin
                                @ 2015-06-29  0:23                               ` Andrew Lapp
                                  2015-06-29  1:11                                 ` Milly Bitcoin
                                  0 siblings, 1 reply; 51+ messages in thread
                                From: Andrew Lapp @ 2015-06-29  0:23 UTC (permalink / raw)
                                  To: bitcoin-dev
                                
                                Your discussion is taking up a lot of room in my inbox and it doesn't 
                                seem like either side is getting through to the other. Perhaps you could 
                                create a document outlining all the failure modes possible due to the 
                                current system, the current systems security assumptions and possible 
                                solutions. Now it seems this is just a semantic debate and would 
                                probably be better solved with you writing a BIP and having that 
                                reviewed and critiqued.
                                
                                -Andrew Lapp
                                
                                On 06/28/2015 08:13 PM, Milly Bitcoin wrote:
                                > The concern with that is that any FAQ will be developed by the same 
                                > small group that controls the github now so they will spin it in an 
                                > unrealistic way.  You see the problem now with the Bitcoin wiki.  
                                > While the wiki has some valuable information, it also has a number of 
                                > incorrect and cult-like claims about how Bitcoin works. Tim Swanson 
                                > has made some good videos that describe some of the misinformation 
                                > that often gets repeated on the Wiki and other places.
                                >
                                > I had suggested the info on the Wiki be reevaluated piece-by-piece and 
                                > moved to Bitcoin.org but the developers didn't like that. Attempts to 
                                > edit the Wiki often leads to the articles being defaced by the 
                                > maintainers so that is a waste of time.
                                >
                                > Russ
                                >
                                >
                                >
                                > On 6/28/2015 5:00 PM, Adam Back wrote:
                                >> I think we need a second mailing list: bitcoin-process for people to
                                >> learn about bitcoin process.
                                >>
                                >> And someone to write a FAQ on it's sign up page so people interested
                                >> could at least discuss from a starting point of understanding how and
                                >> why it works the way it does!
                                >>
                                >> Adam
                                >> _______________________________________________
                                >> 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
                                
                                
                                
                                ^ permalink raw reply	[flat|nested] 51+ messages in thread

                              • • * Re: [bitcoin-dev] BIP Process and Votes
                                    2015-06-29  0:23                               ` Andrew Lapp
                                  @ 2015-06-29  1:11                                 ` Milly Bitcoin
                                    0 siblings, 0 replies; 51+ messages in thread
                                  From: Milly Bitcoin @ 2015-06-29  1:11 UTC (permalink / raw)
                                    To: bitcoin-dev
                                  
                                  That sounds like a good idea except I have been told by the powers that 
                                  be that I am not allowed to post to Github.  Any Bip proposal is 
                                  supposed to be vetted on the mailing list first.
                                  
                                  My suggestion has been to continue development of the risk analysis 
                                  started by the Bitcoin Foundation found at 
                                  https://bitcoinfoundation.org/wp-content/uploads/2014/04/Bitcoin-Risk-Management-Study-Spring-2014.pdf. 
                                  The idea is to create a living document of risks and mitigations as well 
                                  as a decentralization metric.  When a change is proposed it is measured 
                                  against these risks and metrics in a somewhat standard fashion.
                                  
                                  If someone wants to post something like that to Github I can work on 
                                  it.  I am familiar with the process as I worked on something similar for 
                                  many years for the US FAA.  I worked in information security for large 
                                  aviation systems in the R&D stage applying the NIST 800-series documents 
                                  to the process (http://csrc.nist.gov/publications/PubsSPs.html).
                                  
                                  Russ
                                  
                                  
                                  
                                  On 6/28/2015 8:23 PM, Andrew Lapp wrote:
                                  > Your discussion is taking up a lot of room in my inbox and it doesn't 
                                  > seem like either side is getting through to the other. Perhaps you 
                                  > could create a document outlining all the failure modes possible due 
                                  > to the current system, the current systems security assumptions and 
                                  > possible solutions. Now it seems this is just a semantic debate and 
                                  > would probably be better solved with you writing a BIP and having that 
                                  > reviewed and critiqued.
                                  >
                                  > -Andrew Lapp
                                  >
                                  > On 06/28/2015 08:13 PM, Milly Bitcoin wrote:
                                  >> The concern with that is that any FAQ will be developed by the same 
                                  >> small group that controls the github now so they will spin it in an 
                                  >> unrealistic way.  You see the problem now with the Bitcoin wiki.  
                                  >> While the wiki has some valuable information, it also has a number of 
                                  >> incorrect and cult-like claims about how Bitcoin works. Tim Swanson 
                                  >> has made some good videos that describe some of the misinformation 
                                  >> that often gets repeated on the Wiki and other places.
                                  >>
                                  >> I had suggested the info on the Wiki be reevaluated piece-by-piece 
                                  >> and moved to Bitcoin.org but the developers didn't like that. 
                                  >> Attempts to edit the Wiki often leads to the articles being defaced 
                                  >> by the maintainers so that is a waste of time.
                                  >>
                                  >> Russ
                                  >>
                                  >>
                                  >>
                                  >> On 6/28/2015 5:00 PM, Adam Back wrote:
                                  >>> I think we need a second mailing list: bitcoin-process for people to
                                  >>> learn about bitcoin process.
                                  >>>
                                  >>> And someone to write a FAQ on it's sign up page so people interested
                                  >>> could at least discuss from a starting point of understanding how and
                                  >>> why it works the way it does!
                                  >>>
                                  >>> Adam
                                  >>> _______________________________________________
                                  >>> 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
                                  >
                                  
                                  
                                  
                                  
                                  ^ permalink raw reply	[flat|nested] 51+ messages in thread

                        • * Re: [bitcoin-dev] BIP Process and Votes
                            2015-06-28 20:16                       ` Mark Friedenbach
                            2015-06-28 20:26                         ` Ricardo Filipe
                          @ 2015-06-28 23:52                         ` Milly Bitcoin
                            1 sibling, 0 replies; 51+ messages in thread
                          From: Milly Bitcoin @ 2015-06-28 23:52 UTC (permalink / raw)
                            To: bitcoin-dev
                          
                          [-- Attachment #1: Type: text/plain, Size: 14515 bytes --]
                          
                          Nobody has pointed out I am "wrong," it is just semantics about the term 
                          "decider" and I am just essentially repeating things said by others.    
                          As for the term "troll," that is used primarily used by teenagers to 
                          deal with people they don't agree with.  Unfortunately the developers 
                          are often 20-something kids like yourself who have never dealt with a 
                          large system of diverse stakeholders or anything outside of their 
                          specific technical areas.
                          
                          As for your claim that I accused someone of something, I don't know what 
                          you are talking about.  If you don't like my messages then don't read 
                          them.  It looks to me like you don't like the idea of the developers 
                          being questioned about their authority which is understandable as one of 
                          the people involved in Blocksteam because you want the system to stay 
                          the way it is.
                          
                          If you want to moderate the list the go ahead, I can't stop you but I am 
                          not going to listen to anyone who uses the term "troll."
                          
                          Russ
                          
                          
                          
                          On 6/28/2015 4:16 PM, Mark Friedenbach wrote:
                          >
                          > Milly you are absolutely wrong as has been pointed out by numerous 
                          > people numerous times. Your idea of how bitcoin development decision 
                          > making works is demonstrably false. Please stop filling our inboxes 
                          > with trolling accusations, or else this will have to become a 
                          > moderated list. And no one wants that.
                          >
                          > On Jun 28, 2015 1:11 PM, "Milly Bitcoin" <milly@bitcoins•info 
                          > <mailto:milly@bitcoins•info>> wrote:
                          >
                          >     I really don't know who has power to do what behind the scenes. 
                          >     From what i understand, if push comes to shove, it is under the
                          >     ultimate control of one person who can revoke commit privileges. 
                          >     Maybe I am wrong about that but the point is most people don't
                          >     know for sure.
                          >
                          >     You are correct about the people having the choice to download but
                          >     the influence of the official release is way beyond the influence
                          >     of any forked release.  What that means in the real world is an
                          >     open question and would be different depending upon the specific
                          >     circumstances and difficult to predict.  It is significant power
                          >     to have control over the official release at the present time.  If
                          >     they did not have significant power people would not spend
                          >     significant efforts lobbying them to make changes.  Any new
                          >     developers hired by companies will do so because they can
                          >     influence over the official release since that is the only incentive.
                          >
                          >     It seems to me that this block size fork is only the beginning of
                          >     the issues that will arise over the coming years.  Whatever powers
                          >     the core maintainers have it is going to be exploited one way or
                          >     another as time goes on. Maybe there are enough feedback
                          >     mechanisms to protect against that, I don't really know.
                          >
                          >     Russ
                          >
                          >
                          >
                          >
                          >
                          >     On 6/28/2015 3:05 PM, Patrick Murck wrote:
                          >>     Wladimir has no more or less “power” to push change to the
                          >>     Bitcoin Core codebase than any other person with commit
                          >>     privileges to the GitHub repo. If I’m not mistaken there are 7
                          >>     people with commit privileges and five of them are active. If
                          >>     Wladimir committed a change it could be reverted by any of the
                          >>     others. This is by design and ensures that changes will have
                          >>     reached some level of technical consensus before they are merged,
                          >>     among other things.
                          >>
                          >>     Furthermore even assuming the Core Maintainer commits a change to
                          >>     Bitcoin Core (that isn’t reverted and that gets packaged up into
                          >>     the next code release) that still doesn’t push a change to the
                          >>     bitcoin network. There is no auto-update on Bitcoin Core so
                          >>     individuals and companies running Bitcoin Core software have to
                          >>     choose to upgrade. Further still, developers that maintain
                          >>     alternative implementations would have to decide to merge those
                          >>     changes to the codebase they are indepently maintaining (and
                          >>     their users would need to update, etc.).
                          >>
                          >>     I understand why it might *seem* to be the case that the Core
                          >>     Maintainer is empowered to make changes to "teh Bitcoin" but the
                          >>     reality is that the Core Maintainer role is really about cat
                          >>     herding and project management of Bitcoin Core the open-source
                          >>     software project and not the bitcoin network. We’re lucky
                          >>     Wladimir has agreed to take on so much of the scut work to keep
                          >>     the project moving forward.
                          >>
                          >>     The process might get ugly and inefficient but that’s the cost of
                          >>     having no wizard behind the curtain.
                          >>
                          >>     -pm
                          >>
                          >>     -- 
                          >>     Patrick Murck
                          >>
                          >>     On June 28, 2015 at 9:23:47 AM, Milly Bitcoin
                          >>     (milly@bitcoins•info <mailto:milly@bitcoins•info>) wrote:
                          >>
                          >>>     The core maintainer has always been in control of the consensus
                          >>>     rules.
                          >>>     Satoshi came up with the rules and put them in there. Since then
                          >>>     any
                          >>>     changes to any part of the code go through the core maintainer. It
                          >>>     looks to me as if people are saying it somehow changed along the
                          >>>     way
                          >>>     because they don't want to hurt people's feeling, upset up, get
                          >>>     them to
                          >>>     quit, etc. Sure there are checks and balances and people don't
                          >>>     have to
                          >>>     use the main code base but if they change the consensus rules
                          >>>     they are
                          >>>     incompatible.
                          >>>
                          >>>     The notion that because people can download different rules and
                          >>>     run them
                          >>>     is interesting from a theoretical perspective but that is
                          >>>     constrained by
                          >>>     the network effect. I can say the US government is not the
                          >>>     "decider" of
                          >>>     laws because I can vote them out, recall them, challenge things in
                          >>>     court, or secede and start my own country. You can also say the
                          >>>     judge/jury in a criminal court case is not a "decider" because the
                          >>>     president can always issue a pardon. But those points are
                          >>>     generally not
                          >>>     useful in a practical sense.
                          >>>
                          >>>     The issue about the developers is the tremendous influence they
                          >>>     have to
                          >>>     veto any changes. I don't have veto power yet I have more
                          >>>     bitcoins than
                          >>>     garzik says he has. The whole Bitcoin software development
                          >>>     system is
                          >>>     subject to attack from just a couple of people who have this veto
                          >>>     power. With all the crying and moaning about centralization on this
                          >>>     list I would think that would be a concern.
                          >>>
                          >>>     Russ
                          >>>
                          >>>
                          >>>
                          >>>     On 6/28/2015 11:35 AM, Jorge Timón wrote:
                          >>>     > On Sun, Jun 28, 2015 at 3:13 PM, Milly Bitcoin
                          >>>     <milly@bitcoins•info> <mailto:milly@bitcoins•info> wrote:
                          >>>     >> I never said something was approved by garzik added something
                          >>>     after it was
                          >>>     >> opposed. What I said was a proposal was made and 4 people
                          >>>     commented on the
                          >>>     >> Github. He then tweeted there was near universal approval
                          >>>     before most
                          >>>     >> people even heard about the subject. It was not controversial
                          >>>     but i was
                          >>>     >> pointing out the arrogance of some of the developers. He
                          >>>     considers the
                          >>>     >> entire universe of Bitcoin stakeholders to be a very small
                          >>>     group of
                          >>>     >> insiders, not the entire universe of Bitcoin users. Another
                          >>>     thing I have
                          >>>     >> seen on Github for bitcoin.org <http://bitcoin.org> is how
                          >>>     some the maintainers change the rules
                          >>>     >> on the fly. Sometimes they say a proposal had no objections
                          >>>     so it is
                          >>>     >> approved. Other times they say a proposal has no support so
                          >>>     it is rejected.
                          >>>     > Ok, I misunderstood.
                          >>>     > Well, the fact is that the number of capable reviewers is
                          >>>     quite small.
                          >>>     > If more companies hired and trained more developers to become
                          >>>     bitcoin
                          >>>     > core developers that situation could change, but that's where
                          >>>     we are
                          >>>     > now.
                          >>>     >
                          >>>     >> You are also trying to say that the core developers actually
                          >>>     have little
                          >>>     >> influence and are not "deciders" because anyone can fork the
                          >>>     code. That has
                          >>>     >> already been discussed at length and such an argument is
                          >>>     faulty because
                          >>>     >> there is a constraint that your software is incompatible with
                          >>>     everyone else.
                          >>>     > Only if you change the consensus rules (which are, in fact, a
                          >>>     > relatively small part of the code).
                          >>>     > Mike mantains Bitcoin XT and that's fine, Peter Todd maintains
                          >>>     patches
                          >>>     > with the replace by fee policy, libbitcoin also changes many
                          >>>     > non-consensus things, there's code written in other languages...
                          >>>     > There's multiple counter-examples to your claim of that
                          >>>     argument being faulty.
                          >>>     > Seriously, forking the project is just one click. You should
                          >>>     try it
                          >>>     > out like at least 9627 other people have done.
                          >>>     > >From there, you can pay your own developers (if you don't
                          >>>     know how to
                          >>>     > code yourself) and maybe they're also fine being insulted by
                          >>>     you as
                          >>>     > part of the job.
                          >>>     > What you still can't do is unilaterally change the consensus
                          >>>     rules of
                          >>>     > a running p2p consensus system, because you cannot force the
                          >>>     current
                          >>>     > users to run any software they don't want to run.
                          >>>     >
                          >>>     >> The issue is that there is no way right now to change the
                          >>>     consensus rules
                          >>>     >> except to go through the core maintainer unless you get
                          >>>     everybody on the
                          >>>     >> network to switch to your fork. People who keep repeating
                          >>>     that the software
                          >>>     >> development is "decentralized because you fork the code"
                          >>>     without explaining
                          >>>     >> the constraints are just cultists.
                          >>>     > Please, stop the cultist crap. Maybe insulting people like
                          >>>     that is how
                          >>>     > you got people to call you a troll.
                          >>>     > But, yes, you are right: there's no known mechanism for safely
                          >>>     > deploying controversial changes to the consensus rules
                          >>>     >
                          >>>     >> The discussion has nothing to do with who has the position
                          >>>     now and I never
                          >>>     >> said he has "control over the consensus rules." The
                          >>>     maintainer has a very
                          >>>     >> large influence way beyond anyone else. As for your claim
                          >>>     that I want
                          >>>     >> someone hurt because I am explaining the process, that is
                          >>>     ridiculous. If
                          >>>     >> the Core maintainers did not have significant influence to
                          >>>     change the
                          >>>     >> consensus rules then everybody would not be spending all this
                          >>>     time lobbying
                          >>>     >> them to have them changed.
                          >>>     > Well, if you don't think he has control over the consensus
                          >>>     rules we're
                          >>>     > advancing.
                          >>>     > I think that was implied from some of your previous claims. He
                          >>>     is no
                          >>>     > "decider" on consensus changes.
                          >>>     > Insisting on it can indeed get him hurt, so I'm happy that you're
                          >>>     > taking that back (or clarifying that really wasn't your position).
                          >>>     > Influence is very relative and not only core devs have
                          >>>     "influence".
                          >>>     > Maybe Andreas Antonopolous has more "influence" than I have
                          >>>     because he
                          >>>     > is a more public figure?
                          >>>     > Well, that's fine I think. I don't see the point in discussing
                          >>>     who has
                          >>>     > how much influence.
                          >>>     >
                          >>>     >> The outside influences and stake of the developer is a
                          >>>     relevant topic. The
                          >>>     >> same types of things are discussed on this list all the time
                          >>>     in the context
                          >>>     >> of miners, users, merchants, and exchanges. Again, the
                          >>>     developers try to
                          >>>     >> place themselves on some kind of pedestal where they are the
                          >>>     protectors and
                          >>>     >> pure and everyone else (miners, users, merchants) are
                          >>>     abusers, spammers,
                          >>>     >> attackers, scammers, cheaters, etc. It is Garzik who
                          >>>     voluntarily made an
                          >>>     >> issue of how many bitcoins he holds and he made that issue in
                          >>>     the same place
                          >>>     >> where he announces many of the technical issues. It is very
                          >>>     relevant that
                          >>>     >> he has a minimal stake in Bitcoin holdings yet he goes around
                          >>>     making major
                          >>>     >> decisions about Bitcoin and trying to dictate who is allowed
                          >>>     to participate
                          >>>     >> in discussions. If a core developer has minimal stake in
                          >>>     Bitcoin yet has
                          >>>     >> major veto power over code change that is a problem.
                          >>>     > Please, don't generalize. I don't think I put myself in any
                          >>>     kind of pedestal.
                          >>>     > That is insulting to me and many others (you may not even know and
                          >>>     > you're insulting them).
                          >>>     > And I think my Bitcoin holdings are completely irrelevant when
                          >>>     judging
                          >>>     > my contributions to the software: either they're good or not,
                          >>>     and who
                          >>>     > I am or how many Bitcoins I have at any given time shouldn't
                          >>>     matter.
                          >>>     > Again, nobody forces you to use our software, as said there's
                          >>>     > alternatives (including forking the project right now).
                          >>>     >
                          >>>     >> You are correct that you cannot give power to any person over
                          >>>     the Internet
                          >>>     >> which is why some kind of process needs to be developed that
                          >>>     does not
                          >>>     >> involve trying to convince one person to make the changes or
                          >>>     a system that
                          >>>     >> depends on unwritten, ever-changing rules maintained by a
                          >>>     handful of people.
                          >>>     > Well, for now the process we have is seeking consensus, and
                          >>>     although
                          >>>     > our definition of "uncontroversial" is very vague, I think it
                          >>>     is quite
                          >>>     > obvious when a proposed change is not "uncontroversial" (like
                          >>>     in the
                          >>>     > block size debate).
                          >>>     > It seems to me that any other "formal process" would imply
                          >>>     > centralization in the decision making of the consensus rules
                          >>>     (and from
                          >>>     > there you only have to corrupt that centralized organization to
                          >>>     > destroy Bitcoin).
                          >>>     >
                          >>>
                          >>>
                          >>>     _______________________________________________
                          >>>     bitcoin-dev mailing list
                          >>>     bitcoin-dev@lists•linuxfoundation.org
                          >>>     <mailto:bitcoin-dev@lists•linuxfoundation.org>
                          >>>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                          >
                          >
                          >     _______________________________________________
                          >     bitcoin-dev mailing list
                          >     bitcoin-dev@lists•linuxfoundation.org
                          >     <mailto:bitcoin-dev@lists•linuxfoundation.org>
                          >     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                          >
                          
                          
                          [-- Attachment #2: Type: text/html, Size: 23009 bytes --]
                          
                          ^ permalink raw reply	[flat|nested] 51+ messages in thread

                    • * Re: [bitcoin-dev] BIP Process and Votes
                        2015-06-28 19:05                   ` Patrick Murck
                        2015-06-28 20:10                     ` Milly Bitcoin
                      @ 2015-06-28 20:21                     ` NxtChg
                        1 sibling, 0 replies; 51+ messages in thread
                      From: NxtChg @ 2015-06-28 20:21 UTC (permalink / raw)
                        To: Patrick Murck, bitcoin-dev, Milly Bitcoin
                      
                      On 6/28/2015 at 10:05 PM, "Patrick Murck" <patrick.murck@gmail•com> wrote:
                      
                      >Maintainer is empowered to make changes to "teh Bitcoin" but the reality is that the Core Maintainer role is really about cat
                      >herding and project management of Bitcoin Core the open-source software project and not the bitcoin network.
                      
                      It's not about pushing a change, it's about refusing a change on the grounds of controversy.
                      
                      This is _not_ an attack on Wladimir. His position in view of circumstances is perfectly reasonable: to take the safest option.
                      
                      Even at the risk of stagnation, as he pointed out, at least your funds won't be expropriated. It's a noble position to defend the minority.
                      
                      Unfortunately (or fortunately), the majority of power usually gets what it wants. Of course, "they will have it their way anyway" is not an appropriate reason to flip-flop on an ethical position, so nobody expects Wladimir to change his mind.
                      
                      Thus, we are playing a variation of prisoner's dilemma here: the best solution would be an agreement on both sides, if only they could agree.
                      
                      In reality, there's a good chance that Gavin's fork will win, creating precisely the problems and risks, which Wladimir tries to avoid, only more. And we will end up with lose-lose situation.
                      
                      But we lack any other mechanism for a scenario where interests of some of those 7 committers become misaligned with interests of the majority (which seems to be the case).
                      
                      And every time Bitcoin will face similar disagreement in the future we will go through it again...
                      
                      
                      
                      ^ permalink raw reply	[flat|nested] 51+ messages in thread

• * Re: [bitcoin-dev] BIP Process and Votes
    2015-06-25  3:00 Raystonn
    2015-06-25  3:19 ` Milly Bitcoin
  @ 2015-06-25 19:03 ` Tom Harding
    1 sibling, 0 replies; 51+ messages in thread
  From: Tom Harding @ 2015-06-25 19:03 UTC (permalink / raw)
    To: bitcoin-dev, Raystonn
  
  On 6/24/2015 8: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.
  >
  
  Great question; very fair.  I, for one, eagerly await Mark's answer.
  
  I hope nobody forgot to tell adversaries totally outside the open source 
  ecosystem what the rules for hard forking changes are.
  
  The Chinese miners have it right - we have to work together.  If you 
  want to see who's trying, look at who has written a concrete BIP/code 
  vs. who hasn't; who has made changes in response to feedback, and who 
  hasn't.
  
  
  
  ^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [bitcoin-dev] BIP Process and Votes
@ 2015-06-25  3:53 Raystonn
  0 siblings, 0 replies; 51+ messages in thread
From: Raystonn @ 2015-06-25  3:53 UTC (permalink / raw)
  To: Gareth Williams; +Cc: bitcoin-dev

[-- Attachment #1: Type: text/html, Size: 1514 bytes --]

^ permalink raw reply	[flat|nested] 51+ messages in thread

end of thread, other threads:[~2015-07-01 22:34 UTC | newest]

Thread overview: 51+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox