Message-ID: <527C0D12.8030905@ceptacle.com>
Date: Thu, 07 Nov 2013 22:58:42 +0100
From: Michael Gronager <gronager@ceptacle.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
	rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <527B9F9B.4060808@ceptacle.com>
	<20131107203123.GB3805@petertodd.org>
In-Reply-To: <20131107203123.GB3805@petertodd.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] On the optimal block size and why
 transaction fees are 8 times too low (or transactions 8 times too big)
Precedence: list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/11/13, 21:31 , Peter Todd wrote:
>> Final conclusions is that the fee currently is too small and that
>> there is no need to keep a maximum block size, the fork
>> probability will automatically provide an incentive to not let
>> block grows into infinity.
> 

Great additions! - I was about to do a second iteration of the
calculations including the pool size, but you beat me to it - thanks!

Still the picture remains the same - you can half the fee if you are a
large pool

> Q=0    -> f = 0.0033 BTC/kB Q=0.1  -> f = 0.0027 BTC/kB Q=0.25 -> f
> = 0.0018 BTC/kB Q=0.40 -> f = 0.0012 BTC/kB

You second list of numbers is an unlikely extreme:

> k = 1mS/kB

The propagation latency in the network is more due to the block
verification than due to its network (fiber) propagation time,
bringing down the number of hops helps tremendously, so I agree that
we can probably bring down k by a factor of ~10 (k=8-12) if we
consider only pools directly connected. This should bring us close to
break even with the current fee size, but we should really get some
empirical data for interconnected large pools. However - important
note - if you are a 1% miner - don't include transactions!

> 
> Q=0    -> f = 0.000042 BTC/kB Q=0.1  -> f = 0.000034 BTC/kB Q=0.25
> -> f = 0.000023 BTC/kB Q=0.40 -> f = 0.000015 BTC/kB
> 

> 
> This problem is inherent to the fundemental design of Bitcoin: 
> regardless of what the blocksize is, or how fast the network is,
> the current Bitcoin consensus protocol rewards larger mining pools
> with lower costs per KB to include transactions.

I don't see a problem of rewarding economy of scale, as long as the
effect is not too grave (raising the min fee would actually make it
more profitable for smaller miners).

Michael

> 1)
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03200.html
>
> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming
> models. Explore techniques for threading, error checking, porting,
> and tuning. Get the most from the latest Intel processors and
> coprocessors. See abstracts and register 
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>
> 
> 
> 
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSfA0SAAoJEKpww0VFxdGRSEUIALFws8/nNDGPDFWKX2N19jWA
YecC7ZdMgN+1xmf+z2TNjaREvUqI1BLbYO3qQj9AsvTgkMZDwo8c5hMfJL7//V+z
vLiygTbEcorEbyM54w8yTuDVBqdNEg22Cn2T35DIEmqxGP5OSqw+vEBp2B4Y7asv
GG+JgYTVNJf6kZ1GV8cXYnXVBgfccZfXllBYOIPjyk2tdz7HMJN10WKUePbSJtg+
zcvly05JY70d1quERj/fXxVsHpPP6BrH5sH+h4WPxM27+i6R3N90JLAWbB9D4h2s
oYK9MMlH3UC3HR4AR7po4xxuOpxOK3Exa6d9ACQGPGtLRNVWmHiBFT2SViKViK4=
=gALT
-----END PGP SIGNATURE-----