From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UsVs0-0002nw-Bw for bitcoin-development@lists.sourceforge.net; Fri, 28 Jun 2013 10:25:36 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of googlemail.com designates 74.125.83.48 as permitted sender) client-ip=74.125.83.48; envelope-from=john.dillon892@googlemail.com; helo=mail-ee0-f48.google.com; Received: from mail-ee0-f48.google.com ([74.125.83.48]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UsVry-0006K1-Jz for bitcoin-development@lists.sourceforge.net; Fri, 28 Jun 2013 10:25:36 +0000 Received: by mail-ee0-f48.google.com with SMTP id b47so937896eek.35 for ; Fri, 28 Jun 2013 03:25:28 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.14.38.14 with SMTP id z14mr13239577eea.49.1372415128282; Fri, 28 Jun 2013 03:25:28 -0700 (PDT) Received: by 10.223.12.131 with HTTP; Fri, 28 Jun 2013 03:25:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Jun 2013 10:25:28 +0000 Message-ID: From: John Dillon To: Melvin Carvalho Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.4 (-) 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 (john.dillon892[at]googlemail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (john.dillon892[at]googlemail.com) -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: 1UsVry-0006K1-Jz Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting 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: Fri, 28 Jun 2013 10:25:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Thinking about this a little more, I guess it does not hurt to build some > kind of voting system into the clients. But I think it's more useful for > straw polls. For example a bug fix 100% of people should agree on. A > protocol optimization perhaps 80% would agree on. A protocol change that > redistributes wealth or incentives perhaps only 60% will agree on. > > At this point in time it's far too easy to deliver contentious changes into > the hands of the general population. I think that fortunately we're blessed > with a very strong dev team, but the fundamental philosophy of bitcoin is to > not put too much trust in single point, but rather, to distribute and > diversify trust to the edges. I disagree entirely. Your example of "straw polls" for bug fixes and features is precisely what the current method of rough consensus and running code, an IETF expression, handles just fine. What the method does not handle effectively are issues that are fundementally political rather than technical in nature. Blocksize is precisely the latter because while the tradeoffs are technical in nature the fundemental issue at hand is what do we want Bitcoin to be? Who are we going to allow to participate? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRzWR7AAoJEEWCsU4mNhiPEYsIAME+VvS4vfE0PdOMv3vHWGSH HwUJdtKPold4+p0jhPBKSMbgnpMvXsZezMIIxj8xehnblnVuUdyakibXAdgVNLvp a6SCw+W/VnopYCw151zZ4FQS92KQuSbX+XmYTQy32oqZIXtBmTE1fydw5q6YhoXb gCCygPRyLTIQxLZAxqqRrQ0nsSE5ID5kDcr+xRsmCvfIKrzoOCbYL+nXPCB4Zzgu Gs7Lfa0yfTrUlQmoDseyoWrVuhfYuFNesTAs3z6imMTdHqZh8Z+a+gmC+G9qFO1h y7hOmzW4oz7hH4R2F6M+UpV6rKdwMaNYwrDw5eHClDgGYNfjjVduQ/YMQnbjyAc= =5mhd -----END PGP SIGNATURE-----