Re: [bitcoin-dev] BIP Process and Votes

Re: [bitcoin-dev] BIP Process and Votes

[Raystonn]

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

Re: [bitcoin-dev] BIP Process and Votes

[Milly Bitcoin]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Tom Harding]

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.

Re: [bitcoin-dev] BIP Process and Votes

[Jorge Timón]

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?

Re: [bitcoin-dev] BIP Process and Votes

[Milly Bitcoin]

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?
>

Re: [bitcoin-dev] BIP Process and Votes

[Jorge Timón]

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.

Re: [bitcoin-dev] BIP Process and Votes

[Milly Bitcoin]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Jorge Timón]

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.

Re: [bitcoin-dev] BIP Process and Votes

[Milly Bitcoin]

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.
>

Re: [bitcoin-dev] BIP Process and Votes

[Jorge Timón]

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).

Re: [bitcoin-dev] BIP Process and Votes

[Milly Bitcoin]

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).
>

Re: [bitcoin-dev] BIP Process and Votes

[Patrick Murck]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Milly Bitcoin]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Mark Friedenbach]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[NxtChg]

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...

Re: [bitcoin-dev] BIP Process and Votes

[Ricardo Filipe]

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
>

Re: [bitcoin-dev] BIP Process and Votes

[Adam Back]

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

Re: [bitcoin-dev] BIP Process and Votes

[Milly Bitcoin]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Milly Bitcoin]

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
>

Re: [bitcoin-dev] BIP Process and Votes

[Andrew Lapp]

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

Re: [bitcoin-dev] BIP Process and Votes

[Milly Bitcoin]

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
>

Re: [bitcoin-dev] BIP Process and Votes

[odinn]

-----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-----

Re: [bitcoin-dev] BIP Process and Votes

[Milly Bitcoin]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Tier Nolan]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Milly Bitcoin]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Jeff Garzik]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Milly Bitcoin]

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

Re: [bitcoin-dev] BIP Process and Votes

[s7r]

+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
> 

Re: [bitcoin-dev] BIP Process and Votes

[Eric Lombrozo]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[s7r]

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

Re: [bitcoin-dev] BIP Process and Votes

[Milly Bitcoin]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[nxtchg]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[cipher anthem]

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

Re: [bitcoin-dev] BIP Process and Votes

[Pindar Wong]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Warren Togami Jr.]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Mark Friedenbach]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Pindar Wong]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Milly Bitcoin]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Jeff Garzik]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Milly Bitcoin]

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.
>

Re: [bitcoin-dev] BIP Process and Votes

[Raystonn]

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

Re: [bitcoin-dev] BIP Process and Votes

[Gareth Williams]

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.

Re: [bitcoin-dev] BIP Process and Votes

[Milly Bitcoin]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Alex Morcos]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Mark Friedenbach]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Milly Bitcoin]

 >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

Re: [bitcoin-dev] BIP Process and Votes

[Raystonn]

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

Re: [bitcoin-dev] BIP Process and Votes

[Bryan Bishop]

[-- 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 --]

Re: [bitcoin-dev] BIP Process and Votes

[Milly Bitcoin]

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
>

Re: [bitcoin-dev] BIP Process and Votes

[Jeff Garzik]

[-- 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 --]

[bitcoin-dev] BIP Process and Votes

[Raystonn]

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