On Fri, Nov 15, 2013 at 02:19:56PM -0500, Peter Todd wrote:
On Fri, Nov 15, 2013 at 12:47:46PM +0100, Michael Gronager wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15/11/13, 11:32 , Peter Todd wrote:
alpha = (1/113)*600s/134kBytes = 39.62uS/byte = 24kB/second
On Wed, Nov 13, 2013 at 08:01:27PM +, John Dillon wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Last week I posted a writeup: On the optimal block size and why
transaction fees are 8 times too low (or transactions 8 times too big).
Peter Todd made some nice additions to it
On Wed, Nov 13, 2013 at 12:52:21PM +0100, Michael Gronager wrote:
Last week I posted a writeup: On the optimal block size and why
transaction fees are 8 times too low (or transactions 8 times too big).
Peter Todd made some nice additions to it including different pool sizes
into the numbers.
On Wed, Nov 13, 2013 at 01:34:07PM +0100, Michael Gronager wrote:
Just a quick comment on the actual fees (checked at blockchain.info) the
average fee over the last 90 days is actually ~0.0003BTC/txn - so not
too far behind the theoretical minimum of 0.00037BTC/txn.
How did you get those
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Peter,
Love to see things put into formulas - nice work!
Fully agree on the your fist section: As latency determines maximum
block earnings, define a 0-latency (big-miner never orphans his own
blocks) island and growing that will of course result
On Fri, Nov 15, 2013 at 11:47:53AM +0100, Michael Gronager wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Peter,
Love to see things put into formulas - nice work!
Fully agree on the your fist section: As latency determines maximum
block earnings, define a 0-latency (big-miner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15/11/13, 11:32 , Peter Todd wrote:
alpha = (1/113)*600s/134kBytes = 39.62uS/byte = 24kB/second
Which is atrocious...
alpha = P_fork*t_block/S = 1/113*454000/134 = 29ms/kb
or 272kbit pr second - if you assume this is a bandwidth then I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Q = Total pool size (fraction of all mining power) q = My mining
power (do.) e = fraction of block fee that pool reserves
Unfortunately the math doesn't work that way. For any Q, a bigger
Q gives you a higher return. Remember that the way I
On Fri, Nov 15, 2013 at 12:58:14PM +0100, Michael Gronager wrote:
My Q and q are meant differently, I agree to your Q vs Q-1 argument,
but the q is me as a miner participating in a pool Q. If I
participate in a pool I pay the pool owner a fraction, e, but at the
same time I become part of an
On Fri, Nov 15, 2013 at 12:47:46PM +0100, Michael Gronager wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15/11/13, 11:32 , Peter Todd wrote:
alpha = (1/113)*600s/134kBytes = 39.62uS/byte = 24kB/second
Which is atrocious...
alpha = P_fork*t_block/S = 1/113*454000/134 =
Just a quick comment on the actual fees (checked at blockchain.info) the
average fee over the last 90 days is actually ~0.0003BTC/txn - so not
too far behind the theoretical minimum of 0.00037BTC/txn.
I suppose, though, that it has more to do with old clients and fee
settings (0.0005) than
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Last week I posted a writeup: On the optimal block size and why
transaction fees are 8 times too low (or transactions 8 times too big).
Peter Todd made some nice additions to it including different pool sizes
into the numbers.
Peter claims on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi John,
Thanks for the feedback - comments below:
However, it occurred to me that things can in fact be calculated even
simpler: The measured fork rate will mean out all the different pool
sizes and network latencies and will as such provide a
Couple of thoughts:
RE: the marvelous coincidence that the average fee these days is very close
to the modeled minimum orphan cost:
Engineers tend to underestimate the power of markets, even inefficient
markets, to arrive at the 'correct' price. It would not surprise me at all
if the messy,
14 matches
Mail list logo
