From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YyrBC-0002f4-DY for bitcoin-development@lists.sourceforge.net; Sun, 31 May 2015 00:32:42 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.51 as permitted sender) client-ip=74.125.82.51; envelope-from=alex.mizrahi@gmail.com; helo=mail-wg0-f51.google.com; Received: from mail-wg0-f51.google.com ([74.125.82.51]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YyrBB-0003DS-1S for bitcoin-development@lists.sourceforge.net; Sun, 31 May 2015 00:32:42 +0000 Received: by wgme6 with SMTP id e6so88276456wgm.2 for ; Sat, 30 May 2015 17:32:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.193.71 with SMTP id hm7mr28677022wjc.40.1433032355004; Sat, 30 May 2015 17:32:35 -0700 (PDT) Received: by 10.27.102.73 with HTTP; Sat, 30 May 2015 17:32:34 -0700 (PDT) In-Reply-To: References: Date: Sun, 31 May 2015 03:32:34 +0300 Message-ID: From: Alex Mizrahi To: Bitcoin Dev Content-Type: multipart/alternative; boundary=047d7b873dc478c848051755d857 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 (alex.mizrahi[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: 1YyrBB-0003DS-1S Subject: Re: [Bitcoin-development] Block Size Increase Requirements 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: Sun, 31 May 2015 00:32:42 -0000 --047d7b873dc478c848051755d857 Content-Type: text/plain; charset=UTF-8 > > Stop trying to dictate block growth limits. Block size will be determined > by competition between miners and availability of transactions, not through > hard-coded limits. > Do you even game theory, bro? It doesn't work that way. Mike Hearn described the problem in this article: https://medium.com/@octskyward/hashing-7d04a887acc8 But the solution he's proposing is ridiculously bad and unsound: he expects business owners to donate large sums of money towards mining. If it comes to this, what sane business owner will donate, say, 100 BTC to miners instead of seeking some alternatives? Proof-of-stake coins are already there. I'm well aware of theoretical issues with PoS security, but those theoretical issues aren't as bad as donation-funded cryptocurrency security. But you know what works? Mining fees + block size limit. Users and merchants are interested in their transactions being confirmed, but block size limit won't allow it to turn into a race to bottom. This is actually game-theoretically sound. > I see now the temporary 1MB limit was a mistake. It should have gone in > as a dynamic limit that scales with average block size. > This means that miners will control it, and miners couldn't care less about things like decentralization and about problems of ordinary users. This means that in this scenario Bitcoin will be 100% controlled by few huge-ass mining operations. Possibly a single operation. We already saw GHASH.IO using 51% of total hashpower. Is that what you want? Miners are NOT benevolent. This was already demonstrated. They are greedy. --047d7b873dc478c848051755d857 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Stop trying to dictate block growth limits.=C2= =A0 Block size will be determined by competition between miners and availab= ility of transactions, not through hard-coded limits.

= Do you even game theory, bro? It doesn't work that way.

<= /div>
Mike Hearn described the problem in this article:

But th= e solution he's proposing is ridiculously bad and unsound: he expects b= usiness owners to donate large sums of money towards mining. If it comes to= this, what sane business owner will donate, say, 100 BTC to miners instead= of seeking some alternatives? Proof-of-stake coins are already there. I= 9;m well aware of theoretical issues with PoS security, but those theoretic= al issues aren't as bad as donation-funded cryptocurrency security.

But you know what works? Mining fees + block size lim= it.
Users and merchants are interested in their transactions bein= g confirmed, but block size limit won't allow it to turn into a race to= bottom.
This is actually game-theoretically sound.
=C2= =A0

=C2=A0 I see now the temporary= 1MB limit was a mistake.=C2=A0 It should have gone in as a dynamic limit t= hat scales with average block size.

This means that mi= ners will control it, and miners couldn't care less about things like d= ecentralization and about problems of ordinary users. This means that in th= is scenario Bitcoin will be 100% controlled by few huge-ass mining operatio= ns.

Possibly a single operation. We already saw GHASH.IO using 51% of total hashpower. Is tha= t what you want?

Miners are NOT benevolent. This w= as already demonstrated. They are greedy.
--047d7b873dc478c848051755d857--