public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gavin Andresen <gavinandresen@gmail.com>
To: Alex Morcos <morcos@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Justus Ranvier <justusranvier@riseup.net>
Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Date: Thu, 18 Jun 2015 14:23:33 -0400	[thread overview]
Message-ID: <CABsx9T1ENeoZ968PDGUgBPdZLmkwRCDtBvZ2BwT0HaFdWxSL3g@mail.gmail.com> (raw)
In-Reply-To: <CAPWm=eX5Oc4QXkp3H5thPBPzJ-t7JGzF5pVaP+eSd0=h52ku=A@mail.gmail.com>

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

On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos <morcos@gmail.com> wrote:

> Let me take a pass at explaining how I see this.
>
> 1) Code changes to Bitcoin Core that don't change consensus:  Wladimir is
> the decider but he works under a process that is well understood by
> developers on the project in which he takes under reasonable consideration
> other technical opinions and prefers to have clear agreement among them.
>

Yes.

2) Changes to the consensus rules: As others have said, this isn't anyone's
> decision for anyone else.
>

Yes.


> It's up to each individual user as to what code they run and what rules
> they enforce.  So then why is everyone so up in arms about what Mike and
> Gavin are proposing if everyone is free to decide for themselves?  I
> believe that each individual user should adhere to the principle that there
> should be no changes to the consensus rules unless there is near complete
> agreement among the entire community, users, developers, businesses miners
> etc. It is not necessary to define complete agreement exactly because every
> individual person decides for themselves.  I believe that this is what
> gives Bitcoin, or really any money, its value and what makes it work, that
> we all agree on exactly what it is.  So I believe that it is misleading and
> bad for Bitcoin to tell users and business that you can just choose without
> concern for everyone else which code you'll run and we'll see which one
> wins out.  No.  You should run the old consensus rules (on any codebase you
> want) until you believe that pretty much everyone has consented to a change
> in the rules.  It is your choice, but I think a lot of people that have
> spent time thinking about the philosophy of consensus systems believe that
> when the users of the system have this principle in mind, it's what will
> make the system work best.
>

I don't think I agree with "pretty much everybody", because status-quo bias
is a very powerful thing. Any change that disrupts the way they've been
doing things will generate significant resistance -- there will be 10 or
20% of any population that will take a position of "too busy to think about
this, everything seems to be working great, I don't like change, NO to any
change."

For example, I think some of the resistance for bigger blocks is coming
from contributors who are worried they, personally, won't be able to keep
up with a bigger blockchain. They might not be able to run full nodes from
their home network connections (or might not be able to run a full node AND
stream Game of Thrones), on their old raspberry pi machines.

The criteria for me is "clear super-majority of the people and businesses
who are using Bitcoin the most," and I think that criteria is met.



> 3) Code changes to Core that do change consensus: I think that Wladimir,
> all the other committers besides Gavin, and almost all of the other
> developers on Core would defer to #2 above and wait for its outcome to be
> clear before considering such a code change.
>

Yes, that's the way it has mostly been working. But even before stepping
down as Lead I was starting to wonder if there are ANY successful open
source projects that didn't have either a Benevolent Dictator or some clear
voting process to resolve disputes that cannot be settled with "rough
consensus."


-- 
--
Gavin Andresen

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

  parent reply	other threads:[~2015-06-18 18:23 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-18  8:54 [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers odinn
2015-06-18 10:00 ` Mike Hearn
2015-06-18 11:14   ` Wladimir J. van der Laan
2015-06-18 11:47     ` Wladimir J. van der Laan
2015-06-18 13:36       ` Mike Hearn
2015-06-18 15:58         ` Gregory Maxwell
2015-06-18 12:29     ` Pieter Wuille
2015-06-18 12:50       ` Wladimir J. van der Laan
2015-06-18 12:56         ` Benjamin
2015-06-18 13:49       ` Mike Hearn
2015-06-18 14:05         ` Wladimir J. van der Laan
2015-06-18 14:16           ` Mike Hearn
2015-06-18 14:53           ` Milly Bitcoin
2015-06-18 14:56             ` Jeff Garzik
2015-06-18 15:13               ` Milly Bitcoin
2015-06-18 14:53       ` Jeff Garzik
2015-06-18 16:07         ` justusranvier
2015-06-18 16:28           ` Jeff Garzik
2015-06-18 17:04             ` justusranvier
2015-06-18 17:42               ` Alex Morcos
2015-06-18 18:01                 ` Milly Bitcoin
2015-06-18 18:23                 ` Gavin Andresen [this message]
2015-06-18 18:44                   ` Alex Morcos
2015-06-18 18:49                   ` Jorge Timón
2015-06-18 19:31                     ` Ross Nicoll
2015-06-18 21:42                       ` Matt Whitlock
2015-06-18 21:49                         ` Mark Friedenbach
2015-06-18 21:58                           ` Jeff Garzik
2015-06-18 22:33                             ` Mark Friedenbach
2015-06-18 22:52                               ` Jeff Garzik
2015-06-18 23:25                                 ` odinn
2015-06-18 23:16                               ` Ross Nicoll
2015-06-19  0:57                               ` Chris Pacia
2015-06-19  5:59                                 ` Eric Lombrozo
2015-06-19  9:37                               ` Mike Hearn
2015-06-19  9:53                                 ` Benjamin
2015-06-19 10:08                                   ` GC
2015-06-19 10:19                                   ` Mike Hearn
2015-06-19 10:52                                 ` Eric Lombrozo
2015-06-19 11:31                                 ` Jorge Timón
2015-06-19 12:26                                   ` GC
2015-06-19 11:48                                 ` Brooks Boyd
2015-06-21 14:45                                   ` Owen Gunden
2015-06-18 21:55                         ` Ross Nicoll
2015-06-18 19:24                   ` Matt Corallo
2015-06-18 19:32                     ` Gregory Maxwell
2015-06-18 12:38     ` Milly Bitcoin
2015-06-18 13:31     ` Mike Hearn
2015-06-18 13:50       ` Pieter Wuille
2015-06-18 15:03       ` Mark Friedenbach
2015-06-18 15:30         ` Milly Bitcoin
2015-06-18 15:46           ` Wladimir J. van der Laan
2015-06-18 16:05             ` Mike Hearn
2015-06-18 16:20               ` Wladimir J. van der Laan
2015-06-18 22:49               ` odinn
2015-06-18 16:11             ` Milly Bitcoin
2015-06-18 11:41   ` Lawrence Nahum
2015-06-18 14:33   ` Bryan Bishop
2015-06-18 18:09   ` Melvin Carvalho
2015-06-18 22:10   ` odinn

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=CABsx9T1ENeoZ968PDGUgBPdZLmkwRCDtBvZ2BwT0HaFdWxSL3g@mail.gmail.com \
    --to=gavinandresen@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=justusranvier@riseup.net \
    --cc=morcos@gmail.com \
    /path/to/YOUR_REPLY

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

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