From: Pindar Wong <pindar.wong@gmail•com>
To: Stephen Morse <stephencalebmorse@gmail•com>
Cc: bitcoin-development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure
Date: Wed, 3 Jun 2015 12:18:22 +0800 [thread overview]
Message-ID: <CAM7BtUofDnj6mJJ=zg3DxDC9TESJsjoOebRYfoAXmh0mew3J0w@mail.gmail.com> (raw)
In-Reply-To: <CABHVRKS5Mnp9vSJ6mZwNroY7jbBJx+4d+m4hVpWONisaMvBNUw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2764 bytes --]
On Wed, Jun 3, 2015 at 10:33 AM, Stephen Morse <stephencalebmorse@gmail•com>
wrote:
> Pindar,
>
> yes and it's a good idea to separate the hard/soft fork upgrades. The
>> point being here is that we're also establishing a process for the
>> community to self-determine the way forward in a transparent and verifiable
>> manner.
>>
>> What's not to like? :)
>>
>> I'll probably have some time on Sunday to help hack something up but I
>> don't think this is that heavy a coding lift? What am I missing?
>>
>
> As Matt mentioned, many members of the bitcoin community would be hesitant
> about giving miners this much power.
>
I understand this concern and it's a valid one, including other dimensions
such as better decentralization. Some might argue that the mining pools in
China currently have such power and that's a bad thing:-
https://blockchain.info/pools
I happen to think that it's unhealthy for the network but the irony is
that they are huge bitcoin fanbase that perhaps should be involved in this,
and other, decisions. The question is how.
Thus far our friends from f2pool have chimed in with some data from their
perspective. It would be interesting to hear from the others and I'm
finding ways to do exactly that.
So let's find a way to involve, and not alienate them or others. Let's find
a way to get more data and test assumptions and boundaries.
It essentially lets them vote to change the rules of the system.
>
It's data and yes, it gives then a very visible, verifiable 'vote' ...
though I prefer to think of this as 'voice' as in a ' hummmm. '
But miners are not the only part of this ecosystem, and they are not the
> only ones affected by the choice of block size limit, so they probably
> shouldn't be the only ones with a vote.
>
I fully agree and it doesn't have to be the only voice ... think 'choir'
... after all this is an ecosystem with each party playing their
respective roles. But sustainable ecosystems have 'keystone' species, and I
believe these to be the 'honest' miners that help secure the network.
Instead, we vote with the software we run, and all upgrade.
>
or not as the case may be. I think we're trying to find a level of rough
consensus where members of the community feel comfortable enough to do this
upgrade in their respective codebase.
>
> So, while I think an idea like this has its merits, I would bet that it's
> fairly unlikely to get enough support to be merged into bitcoin core.
>
Bitcoin was 'unlikely' ... yet it happened.
Nevertheless you raise the possibility of a different possible path forward
and that's positive. So thank you for doing that!
Bitcoin's humming in China, behind an GFW ... who could have guessed?
'Connect and Liberate' :)
p.
>
> Best,
> Stephen
>
>
[-- Attachment #2: Type: text/html, Size: 5141 bytes --]
prev parent reply other threads:[~2015-06-03 4:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-31 19:04 Stephen Morse
2015-06-02 21:26 ` Matt Whitlock
2015-06-03 0:30 ` Stephen Morse
[not found] ` <CAM7BtUod0hyteqx-yj8XMwATYp73Shi0pvdcTrW0buseLGc_ZQ@mail.gmail.com>
[not found] ` <CABHVRKT7H1p67Bz_T_caaGFnfuswnC+kXKGdkpRhtXUZQv3HtQ@mail.gmail.com>
[not found] ` <CAM7BtUrN9D__ha63Qfs2Fi4HSUFWb8BArHni9yFKRSdLSxCNnA@mail.gmail.com>
2015-06-03 2:33 ` Stephen Morse
2015-06-03 3:08 ` Vincent Truong
2015-06-03 3:36 ` Stephen Morse
2015-06-03 4:18 ` Pindar Wong [this message]
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='CAM7BtUofDnj6mJJ=zg3DxDC9TESJsjoOebRYfoAXmh0mew3J0w@mail.gmail.com' \
--to=pindar.wong@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=stephencalebmorse@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