From: Alex Morcos <morcos@gmail•com>
To: Gavin Andresen <gavinandresen@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:44:14 -0400 [thread overview]
Message-ID: <CAPWm=eVuCJVcw4ZU6x9SxASVLm4cE8_pRLNAZBzak8TqO43HWQ@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T1ENeoZ968PDGUgBPdZLmkwRCDtBvZ2BwT0HaFdWxSL3g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4615 bytes --]
Not that I know how to do this, but would you be willing to attempt some
other method of measuring just how much of a "super-majority" we have
before deploying code? Maybe that information would be helpful for
everyone. Obviously such a poll couldn't be perfect, but maybe better than
the information we have now.
A) I don't believe we should consider changing the 1 MB limit now
B) I conceptually believe in increasing block size, but would like to
follow a more conservative process and wait to see if a stronger technical
consensus on a plan to do so can develop.
C) I'd like to go along with Gavin and Mike's 8MB proposal (maybe we wait
til this is fully specified, but again not deployed)
Perhaps there can even be 4 polls:
Miners can vote in coinbases
Known corporate entities can announce their vote
Does the Bitcoin Foundation infrastructure still exist to represent some
authenticated (I think) set of individuals
A reddit poll
I don't even know if I think this is a good idea, but just trying to find a
way to move forward where more of us are on the same page.
On Thu, Jun 18, 2015 at 2:23 PM, Gavin Andresen <gavinandresen@gmail•com>
wrote:
> 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: 6244 bytes --]
next prev parent reply other threads:[~2015-06-18 18:44 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 8:54 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
2015-06-18 18:44 ` Alex Morcos [this message]
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='CAPWm=eVuCJVcw4ZU6x9SxASVLm4cE8_pRLNAZBzak8TqO43HWQ@mail.gmail.com' \
--to=morcos@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@gmail$(echo .)com \
--cc=justusranvier@riseup$(echo .)net \
/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