From: Michael Gronager <gronager@ceptacle.com>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big)
Date: Thu, 07 Nov 2013 22:58:42 +0100 [thread overview]
Message-ID: <527C0D12.8030905@ceptacle.com> (raw)
In-Reply-To: <20131107203123.GB3805@petertodd.org>
-----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-----
next prev parent reply other threads:[~2013-11-07 21:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-07 14:11 [Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big) Michael Gronager
2013-11-07 15:00 ` Pieter Wuille
2013-11-07 15:19 ` Pieter Wuille
2013-11-07 15:22 ` Mike Hearn
2013-11-07 15:53 ` Michael Gronager
2013-11-07 20:31 ` Peter Todd
2013-11-07 21:58 ` Michael Gronager [this message]
2013-11-15 10:52 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=527C0D12.8030905@ceptacle.com \
--to=gronager@ceptacle.com \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox