public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: s7r <s7r@sky-ip•org>
To: Eric Lombrozo <elombrozo@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Process and Votes
Date: Thu, 25 Jun 2015 16:51:33 +0300	[thread overview]
Message-ID: <558C0765.1070402@sky-ip.org> (raw)
In-Reply-To: <53DED62D-6645-464A-998F-C31464FD0C1A@gmail.com>

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


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

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

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=558C0765.1070402@sky-ip.org \
    --to=s7r@sky-ip$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=elombrozo@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox