Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UlxdI-0007io-SU for bitcoin-development@lists.sourceforge.net; Mon, 10 Jun 2013 08:39:20 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.53 as permitted sender) client-ip=209.85.215.53; envelope-from=melvincarvalho@gmail.com; helo=mail-la0-f53.google.com; Received: from mail-la0-f53.google.com ([209.85.215.53]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UlxdE-00049A-JM for bitcoin-development@lists.sourceforge.net; Mon, 10 Jun 2013 08:39:20 +0000 Received: by mail-la0-f53.google.com with SMTP id fs12so3935058lab.26 for ; Mon, 10 Jun 2013 01:39:09 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.28.129 with SMTP id b1mr1769313lah.51.1370853549800; Mon, 10 Jun 2013 01:39:09 -0700 (PDT) Received: by 10.112.2.8 with HTTP; Mon, 10 Jun 2013 01:39:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Jun 2013 10:39:09 +0200 Message-ID: From: Melvin Carvalho To: John Dillon Content-Type: multipart/alternative; boundary=089e0160bde0e0022d04dec8b613 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 (melvincarvalho[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: 1UlxdE-00049A-JM 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: Mon, 10 Jun 2013 08:39:21 -0000 --089e0160bde0e0022d04dec8b613 Content-Type: text/plain; charset=ISO-8859-1 On 10 June 2013 10:26, John Dillon wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On Mon, Jun 10, 2013 at 8:14 AM, Melvin Carvalho > wrote: > > -1 > > > > Firstly I appreciate the ingenious thought that went into this post. > > > > However, Bitcoin's fundamental philosophy was one CPU one vote. > > Indeed it was. Which is why as GPU's came onto the scene Satoshi was > strongly > against them. I have to wonder what he thinks of ASICs where just a > handful of > companies control the supply of Bitcoin hashing power. > Thanks for your reply. Do you have a pointer to Satoshi being strongly against GPU? I'd be interested to see that. FWIW, I've read all his forum posts a few times, I just dont recall this one, tho I'm sure it's there... > > Satoshi also never forsaw pools, which are why just 2 or 3 people control > the > majority of Bitcoin hashing power. > > > The asymmetry lies in psychological terms, in that new defaults tend to > be > > adopted 80% of the time, so core devs have disproportionate amount of > power > > as things stand. > > That's why I'm very clear that doing nothing is a vote for the status quo. > Of > course wallet authors can do what they want to try to get users to vote > according to their wishes, or for that matter simply steal your vote, but > we > already must put a lot of faith into wallets to not steal our funds. > > > Unless there's a very good reason not to, e.g. miners are clearly abusing > > the system, we should stick with 1 CPU one vote. > > People are proposing we put control of the blocksize entirely into the > hands of > miners, yet we all have an interest in auditing the blocks miners produce. > There must be balance. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQEcBAEBCAAGBQJRtY2jAAoJEEWCsU4mNhiPQEsH/0VNA7aJYdUbJjTnIiKoaCv3 > JtWS1MKHjAJE6ZPDt+T/QPkEdZI4kNz3DGcZL6EDJtvZxZHfvEIaZDF1gpaH6OkC > oIZ0PkFPOxi0cncuAvT/a770evu7LzuT6fisY3EgGnlHujLQZ47LEa73Xo7pJVc7 > RJHamGwkj+3HZRIuZIAn87qws/zRyTx5SXvb56xCKb0oxE4ZO0dn+8/nNSPWw13i > p3LpLlEQBBu+Du2nPSQupRjkz4MPP8v9EYefV5cjtNBK7ufAvA64OnwKB5dST+h+ > N/vBcj3EIj/WEOf4myGcVxKp+skJ2SJDwxLigevgkKYPDNTVfXIverdXB0ANrQA= > =c8iU > -----END PGP SIGNATURE----- > --089e0160bde0e0022d04dec8b613 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable




Satoshi also never forsaw pools, which are why just 2 or 3 people control t= he
majority of Bitcoin hashing power.

> The asymmetry lies in psychological terms, in that new defaults tend t= o be
> adopted 80% of the time, so core devs have disproportionate amount of = power
> as things stand.

That's why I'm very clear that doing nothing is a vote for th= e status quo. Of
course wallet authors can do what they want to try to get users to vote
according to their wishes, or for that matter simply steal your vote, but w= e
already must put a lot of faith into wallets to not steal our funds.

> Unless there's a very good reason not to, e.g. miners are clearly = abusing
> the system, we should stick with 1 CPU one vote.

People are proposing we put control of the blocksize entirely into th= e hands of
miners, yet we all have an interest in auditing the blocks miners produce.<= br> There must be balance.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJRtY2jAAoJEEWCsU4mNhiPQEsH/0VNA7aJYdUbJjTnIiKoaCv3
JtWS1MKHjAJE6ZPDt+T/QPkEdZI4kNz3DGcZL6EDJtvZxZHfvEIaZDF1gpaH6OkC
oIZ0PkFPOxi0cncuAvT/a770evu7LzuT6fisY3EgGnlHujLQZ47LEa73Xo7pJVc7
RJHamGwkj+3HZRIuZIAn87qws/zRyTx5SXvb56xCKb0oxE4ZO0dn+8/nNSPWw13i
p3LpLlEQBBu+Du2nPSQupRjkz4MPP8v9EYefV5cjtNBK7ufAvA64OnwKB5dST+h+
N/vBcj3EIj/WEOf4myGcVxKp+skJ2SJDwxLigevgkKYPDNTVfXIverdXB0ANrQA=3D
=3Dc8iU
-----END PGP SIGNATURE-----

--089e0160bde0e0022d04dec8b613--