Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z008M-0003Hb-AG for bitcoin-development@lists.sourceforge.net; Wed, 03 Jun 2015 04:18:30 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.170 as permitted sender) client-ip=209.85.212.170; envelope-from=pindar.wong@gmail.com; helo=mail-wi0-f170.google.com; Received: from mail-wi0-f170.google.com ([209.85.212.170]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z008K-0006Om-Rt for bitcoin-development@lists.sourceforge.net; Wed, 03 Jun 2015 04:18:30 +0000 Received: by wibut5 with SMTP id ut5so88768277wib.1 for ; Tue, 02 Jun 2015 21:18:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.86.73 with SMTP id n9mr36499073wiz.78.1433305102831; Tue, 02 Jun 2015 21:18:22 -0700 (PDT) Received: by 10.194.156.226 with HTTP; Tue, 2 Jun 2015 21:18:22 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jun 2015 12:18:22 +0800 Message-ID: From: Pindar Wong To: Stephen Morse Content-Type: multipart/alternative; boundary=f46d0442806e8256a00517955950 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pindar.wong[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Z008K-0006Om-Rt Cc: bitcoin-development Subject: Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 04:18:30 -0000 --f46d0442806e8256a00517955950 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 3, 2015 at 10:33 AM, Stephen Morse 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 > > --f46d0442806e8256a00517955950 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 3, 2015 at 10:33 AM, Stephen Morse <stephencaleb= morse@gmail.com> wrote:
Pindar,

yes and it's a good idea to separate the hard/sof= t 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 transpare= nt and verifiable manner.=C2=A0

What's not= to like? :)

I'll probably have some time on Sunday t= o 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.
<= /div>

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 a= nd that's a bad thing:-

https://blockchain.info/pools

I happen to think=C2= =A0 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,=C2= =A0 decisions. The question is how.=C2=A0

Thus far our friends from= f2pool have chimed in with some data from their perspective. It would be i= nteresting to hear from the others and I'm finding ways to do exactly t= hat.

So let's find a way to involve, and not alienate them or o= thers. Let's find a way to get more data and test assumptions and bound= aries.


=
It essentially lets them vote to change the rules of the system.

It's data an= d yes, it gives then a very visible, verifiable 'vote' ... though I= prefer to think of this as 'voice'=C2=A0 as in a ' hummmm. = 9;=C2=A0

<= div>But miners are not the only part of this ecosystem, and they are not th= e only ones affected by the choice of block size limit, so they probably sh= ouldn't be the only ones with a vote.

I fully agree and it doesn't have to be th= e only voice ...=C2=A0 think 'choir' ...=C2=A0 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 &= #39;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.=C2=A0=C2=A0 I think we'= ;re trying to find a level of rough consensus where members of the communit= y feel comfortable enough to do this upgrade in their respective codebase. =
=C2=A0

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.=C2=A0

Bitcoin was 'unlikely' ...=C2=A0 yet it happened.

Nevertheless you raise the possibility of a different possible path= forward and that's positive. So thank you for doing that!=C2=A0
Bitcoin's humming in China, behind an GFW ... who could have guessed?=

'Connect and Liberate' :)

p.<= br>=C2=A0
=
Best,
Stephen


--f46d0442806e8256a00517955950--