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

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

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

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

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=53DED62D-6645-464A-998F-C31464FD0C1A@gmail.com \
    --to=elombrozo@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=s7r@sky-ip.org \
    /path/to/YOUR_REPLY

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

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