public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
@ 2013-11-13 23:52 Gavin Andresen
  0 siblings, 0 replies; 16+ messages in thread
From: Gavin Andresen @ 2013-11-13 23:52 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]

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, chaotic inefficient market with tens of thousands of
individual decisions ("which mining pool should I join" and "how high
should my dice site set fees" and "how large should the minimum payout be"
and "should I make my blocks bigger or smaller") might arrive at the
'correct' price, even if NOBODY involved has any clue how or why it
happened.

Or it might just be a coincidence.

RE: orphan rate:

The network-wide orphan rate has been very steady apart from the March
blockchain fork. Kudos to Ben Reeves for keeping track of the data and
giving us a nice chart:
  http://blockchain.info/charts/n-orphaned-blocks

RE: new block latency:

We should be able to reduce the size of new block announcements by about a
factor of ten with very little additional effort (transmit/relay as
"merkleblock" with full bloom filters-- the factor of 10 is because a
transaction id hash is 32 bytes, average transaction size is a few hundred
bytes).

Mining revenue is a fixed-size pie, so if EVERYBODY agreed to accept
(somewhat) higher orphan rates for more transaction volume then, in the
long run, there is no difference.  Well, except that more transaction
volume means more utility for Bitcoin as a whole, so everybody should
benefit from a higher bitcoin price.

That's a classic free-rider problem, though-- a miner could defect to try
to get a lower orphan rate.

This is one of the reasons why I think relaying all blocks in a race is
probably the right thing to do; if a miner is mildly punished (by losing
the occasional block race) for creating blocks that don't include "enough"
already-relayed transactions, that is a strong incentive to go along with
whatever consensus has been established.

The same argument applies for a miner producing too-large blocks, or blocks
with lots of transactions that were never relayed across the network.

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 3310 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
@ 2013-11-13 11:52 Michael Gronager
  2013-11-13 12:34 ` Michael Gronager
                   ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Michael Gronager @ 2013-11-13 11:52 UTC (permalink / raw)
  To: Bitcoin Dev

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.

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 simple number we
can use to estimate the minimum fee. Key assumption is that the latency
will depend on block size (# txns) and the fork rate will depend on latency.

Using the formulas from last week:

P_fork = t_propagate/t_blocks

and:

t_propagate = t_0 + alpha*S ~= alpha*S

We get a measure for alpha as a function of the average fork rate and
average block size:

alpha = P_fork*t_block/S

Further, take the formula for the minimum fee:

f > alpha*E_bounty/t_block

And insert the formula for alpha:

f > P_fork*E_bounty/S_average

Luckily the fork frequency and the average block size are easily
measurable. blockchain.info keeps historical graphs of number of
orphaned blocks pr day - average over the last year is 1.5. Average
number of blocks per day over the last year is 169, which yields a
P_fork of ~1/113. Average block size in the same time is 134kBytes,
which yields a minimum fee:

f > 0.00165XBT/kb or 0.00037XBT/txn

So the 0.0001 is only 4 times too small. Further, let us look at the
trend over the last 12 months. Pieter Wuille claimed that there has been
several improvements over the last half year that would bring down the
latency, there has also been speculations regarding direct connections
between the major pools etc - lets see if this is indeed true.

If you look instead of 360 days, only at the last 90 days the average
block size has been 131kBytes, and the fork rate has been ~1/118, which
results in a minimum fee of:

f > 0.00162XBT/kb or 0.00037XBT/txn

So a small improvement but not statistically important...

Last question, recalling that optimal revenue block size is a function
of the txn-fee (from the last writeup) - lets see what fee it takes to
support a block size of 131kBytes:

S = 1/2 * (t_block/alpha - E_bounty/f)

S = 1/2 * (S/P_fork - E_bounty/f)

f = E_bounty/[(1/P_fork-2)*S] = 0.00165XBT/kB

So a 4 times increase is still sufficient for the current load.

Anyway - the all important number is alpha, the network latency which we
expect to be dependent of various things such as interconnectivity,
bandwidths, software quality etc, where mainly the latter is within our
hands to bring down the fee. And you can actually setup the standard
client to choose a better fee, as all the parameters in the formula are
easily measured!



^ permalink raw reply	[flat|nested] 16+ messages in thread

• * Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
    2013-11-13 11:52 Michael Gronager
  @ 2013-11-13 12:34 ` Michael Gronager
    2013-11-15 10:46   ` Peter Todd
    2013-11-13 20:01 ` John Dillon
    2013-11-15 10:32 ` Peter Todd
    2 siblings, 1 reply; 16+ messages in thread
  From: Michael Gronager @ 2013-11-13 12:34 UTC (permalink / raw)
    To: Bitcoin Dev
  
  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 network wisdom ;)
  
  On 13/11/13, 12:52 , 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.
  > 
  > 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 simple number we
  > can use to estimate the minimum fee. Key assumption is that the latency
  > will depend on block size (# txns) and the fork rate will depend on latency.
  > 
  > Using the formulas from last week:
  > 
  > P_fork = t_propagate/t_blocks
  > 
  > and:
  > 
  > t_propagate = t_0 + alpha*S ~= alpha*S
  > 
  > We get a measure for alpha as a function of the average fork rate and
  > average block size:
  > 
  > alpha = P_fork*t_block/S
  > 
  > Further, take the formula for the minimum fee:
  > 
  > f > alpha*E_bounty/t_block
  > 
  > And insert the formula for alpha:
  > 
  > f > P_fork*E_bounty/S_average
  > 
  > Luckily the fork frequency and the average block size are easily
  > measurable. blockchain.info keeps historical graphs of number of
  > orphaned blocks pr day - average over the last year is 1.5. Average
  > number of blocks per day over the last year is 169, which yields a
  > P_fork of ~1/113. Average block size in the same time is 134kBytes,
  > which yields a minimum fee:
  > 
  > f > 0.00165XBT/kb or 0.00037XBT/txn
  > 
  > So the 0.0001 is only 4 times too small. Further, let us look at the
  > trend over the last 12 months. Pieter Wuille claimed that there has been
  > several improvements over the last half year that would bring down the
  > latency, there has also been speculations regarding direct connections
  > between the major pools etc - lets see if this is indeed true.
  > 
  > If you look instead of 360 days, only at the last 90 days the average
  > block size has been 131kBytes, and the fork rate has been ~1/118, which
  > results in a minimum fee of:
  > 
  > f > 0.00162XBT/kb or 0.00037XBT/txn
  > 
  > So a small improvement but not statistically important...
  > 
  > Last question, recalling that optimal revenue block size is a function
  > of the txn-fee (from the last writeup) - lets see what fee it takes to
  > support a block size of 131kBytes:
  > 
  > S = 1/2 * (t_block/alpha - E_bounty/f)
  > 
  > S = 1/2 * (S/P_fork - E_bounty/f)
  > 
  > f = E_bounty/[(1/P_fork-2)*S] = 0.00165XBT/kB
  > 
  > So a 4 times increase is still sufficient for the current load.
  > 
  > Anyway - the all important number is alpha, the network latency which we
  > expect to be dependent of various things such as interconnectivity,
  > bandwidths, software quality etc, where mainly the latter is within our
  > hands to bring down the fee. And you can actually setup the standard
  > client to choose a better fee, as all the parameters in the formula are
  > easily measured!
  > 
  > ------------------------------------------------------------------------------
  > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
  > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
  > Free app hosting. Or install the open source package on any LAMP server.
  > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
  > http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
  > _______________________________________________
  > Bitcoin-development mailing list
  > Bitcoin-development@lists•sourceforge.net
  > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  > 
  
  
  
  
  ^ permalink raw reply	[flat|nested] 16+ messages in thread

• • * Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
      2013-11-13 12:34 ` Michael Gronager
    @ 2013-11-15 10:46   ` Peter Todd
      0 siblings, 0 replies; 16+ messages in thread
    From: Peter Todd @ 2013-11-15 10:46 UTC (permalink / raw)
      To: Michael Gronager; +Cc: Bitcoin Dev
    
    [-- Attachment #1: Type: text/plain, Size: 554 bytes --]
    
    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 numbers exactly?
    
    Also fee per txn is *not* useful and we really shouldn't quote it so
    that newbies reading this stuff get the right understanding.
    
    -- 
    'peter'[:-1]@petertodd.org
    00000000000000075ed91531e07d2045b5823da050fe373bde7bb363965e44ae
    
    [-- Attachment #2: Digital signature --]
    [-- Type: application/pgp-signature, Size: 685 bytes --]
    
    ^ permalink raw reply	[flat|nested] 16+ messages in thread

• * Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
    2013-11-13 11:52 Michael Gronager
    2013-11-13 12:34 ` Michael Gronager
  @ 2013-11-13 20:01 ` John Dillon
    2013-11-13 20:32   ` Michael Gronager
    2013-11-15  9:54   ` Peter Todd
    2013-11-15 10:32 ` Peter Todd
    2 siblings, 2 replies; 16+ messages in thread
  From: John Dillon @ 2013-11-13 20:01 UTC (permalink / raw)
    To: Michael Gronager; +Cc: Bitcoin Dev
  
  -----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 IRC that he is writing a paper of some kind on this topic. I
  suggest he submit it to that crypto-currency thing the foundation is
  sponsoring. Given the Nov 24th deadline, I also suggest at least making part of
  it public ASAP so some peer review can be done. It would be a shame for a
  simple math error to cause embarassment later.
  
  
  > 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 simple number we
  > can use to estimate the minimum fee.
  
  Are you sure about that? You are assuming linearity where none may exist.
  
  
  > Luckily the fork frequency and the average block size are easily
  > measurable. blockchain.info keeps historical graphs of number of
  > orphaned blocks pr day
  
  Are those stats accurate? Have any pool operators at least confirmed that the
  orphaned blocks that blockchain.info reports match their own records?
  
  My gut feeling is to relay all orphaned blocks. We know that with a high
  investment and sybil attack as blockchain.info has done you can have better
  awareness of orphaned blocks than someone without those resources. If having
  that awareness is ever a profitable thing we have both created an incentive to
  sybil attack the network and we have linked profitability to high up-front
  capital investments.
  
  On those grounds alone I will argue that we should relay all orphans to even
  the playing field. If there is a circumstance where we do not want the attacker
  to have that knowledge we have failed anyway, as blockchain.info's sybil attack
  on the network clearly shows.
  
  
  > Anyway - the all important number is alpha, the network latency which we
  > expect to be dependent of various things such as interconnectivity,
  > bandwidths, software quality etc, where mainly the latter is within our
  > hands to bring down the fee. And you can actually setup the standard
  > client to choose a better fee, as all the parameters in the formula are
  > easily measured!
  
  With relayed orphans you could even have P2Pool enforce an optimal tx inclusion
  policy based on a statistical model by including proof of those orphans into
  the P2Pool share chain. P2Pool needs to take fees into account soon, but simply
  asking for blocks with the highest total fees or even highest fee/kb appears to
  be incomplete according to what your and Peter's analysis is suggesting.
  
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1.4.11 (GNU/Linux)
  
  iQEcBAEBCAAGBQJSg9pfAAoJEEWCsU4mNhiP5mcH/jKd2Rpl9gEJ7WhTndS5gYJ9
  Ep151NyD/iKpAA4E/d9QVYalo8595LCqnrXnV6wuvuiifB6EJD5WBJq3MAMyaJLA
  agl920ygY98slhDmFhnwlU9lkJVim5FoUkZgE7lQ5dr0MIhvoLQiF2Ywky49Izf0
  IqL+nyW83AQweSalvktA+XGkDfGDV/EnJN7SdNqKDNtE7E9NeMl61NNOWNndsYy6
  uT4PF2YB7rh8wGyHXMTC4Z192pfW4S4s60ZAflG/sTtWCcEwWi+5V/RIu0o5Hmog
  RFpEPvc6d6ykdqtPfTRADMGkT2wC1yXsgeos9oFFVVuVSj8EqHb2db0B+psHRBk=
  =76Qs
  -----END PGP SIGNATURE-----
  
  
  
  ^ permalink raw reply	[flat|nested] 16+ messages in thread

• • * Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
      2013-11-13 20:01 ` John Dillon
    @ 2013-11-13 20:32   ` Michael Gronager
      2013-11-15  9:54   ` Peter Todd
      1 sibling, 0 replies; 16+ messages in thread
    From: Michael Gronager @ 2013-11-13 20:32 UTC (permalink / raw)
      To: bitcoin-development
    
    -----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 simple number we
    >> can use to estimate the minimum fee.
    > 
    > Are you sure about that? You are assuming linearity where none may exist.
    
    Well, my work from last week and now is a model. A model enabling you to
    easily calculate the minimum fee and as a miner which transaction to
    include to not shoot yourselves in the foot risking to create an
    orphaned block.
    
    The assumption that there is a linearity between block size and latency
    is shown pretty well in the paper by Decker et. al (see last weeks
    post). What I add this week is mainly more up to date numbers and a
    formula dependent only of data that is easy to measure. (fork rate and
    block size).
    
    > 
    > Are those stats accurate? Have any pool operators at least confirmed that the
    > orphaned blocks that blockchain.info reports match their own records?
    
    Probably not - but the are at least a minimum - in case they are higher,
    the fee should go up further.
    
    > 
    > My gut feeling is to relay all orphaned blocks. We know that with a high
    > investment and sybil attack as blockchain.info has done you can have better
    > awareness of orphaned blocks than someone without those resources. If having
    > that awareness is ever a profitable thing we have both created an incentive to
    > sybil attack the network and we have linked profitability to high up-front
    > capital investments.
    
    Another way to measure latency is to setup a node that only listens but
    do not relay data. By measuring the propagation of blocks of different
    size as well as transactions, you can get a propagation distribution and
    from that an average. However, the relevant propagation time is the one
    between the pools/(single miners). Which you cannot assess using this
    scheme - however, it would be nice to compare it to the orphan block scheme.
    
    > 
    > With relayed orphans you could even have P2Pool enforce an optimal tx inclusion
    > policy based on a statistical model by including proof of those orphans into
    > the P2Pool share chain. P2Pool needs to take fees into account soon, but simply
    > asking for blocks with the highest total fees or even highest fee/kb appears to
    > be incomplete according to what your and Peter's analysis is suggesting.
    
    Indeed, and nice... But note that it is never of benefit for the miner
    to include a transaction with a fee of less than ~0.0004BTC - unless it
    is linked to another transaction that pay an extra fee.
    
    There have been a lot of assumptions on the fee size and generally it
    has been linked to the bitcoin exchange rate. This analysis shows that
    this is wrong. Also it shows that the scalability of bitcoin is directly
    linked to the network and node latency (with the current latency it will
    never beneficial for miners to include more than ~30k transactions in a
    block or ~70 pr second resulting in ~10MB blocks).
    However, halving the latency will double the capacity, down to the
    minimum which is governed by the speed of light.
    
    > 
    > 
    > ------------------------------------------------------------------------------
    > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
    > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
    > Free app hosting. Or install the open source package on any LAMP server.
    > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
    > http://pubads.g.doubleclick.net/gampad/clk?id=63469471&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/
    
    iQEcBAEBAgAGBQJSg+H7AAoJEKpww0VFxdGRn+gIAIgju90DED5r//USqKvkQsYI
    JDj0tLBLMg9BPXOOt3eJ+NX4YE4lW+QkwqDd/swuJxLmj0l9BQKgt1lTb/f0P/cY
    GdE14gh5EYlvNzY1h0TGKcMe8NTWXU0/tC+Clpy4sqBHPXW/eF/77sLQUnFRrLKi
    sT48aHOOFUdBLdlyylUzzevh/FFVLidkKqV031tv52+BFHcTFd4kRPwZXgBSs9YH
    U66MkJ4ytAqeOfJue9n7Qn4kJF9kNIhRpqTrtapqu8jglLfuYlJ3s5fwaw9FxQdR
    +On4IWeXzURQ6tcVRCovCq/2lxRKIbYGlW7HGVASjRmm68/+8YUAfFsYFl6DIgA=
    =9tbL
    -----END PGP SIGNATURE-----
    
    
    
    ^ permalink raw reply	[flat|nested] 16+ messages in thread

  • * Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
      2013-11-13 20:01 ` John Dillon
      2013-11-13 20:32   ` Michael Gronager
    @ 2013-11-15  9:54   ` Peter Todd
      2013-11-15  9:59     ` Gregory Maxwell
      2013-11-15 10:47     ` Michael Gronager
      1 sibling, 2 replies; 16+ messages in thread
    From: Peter Todd @ 2013-11-15  9:54 UTC (permalink / raw)
      To: John Dillon; +Cc: Bitcoin Dev, Michael Gronager
    
    [-- Attachment #1: Type: text/plain, Size: 12968 bytes --]
    
    On Wed, Nov 13, 2013 at 08:01:27PM +0000, 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 including different pool sizes
    > > into the numbers.
    > 
    > Peter claims on IRC that he is writing a paper of some kind on this topic. I
    > suggest he submit it to that crypto-currency thing the foundation is
    > sponsoring. Given the Nov 24th deadline, I also suggest at least making part of
    > it public ASAP so some peer review can be done. It would be a shame for a
    > simple math error to cause embarassment later.
    
    Here's what I've got to date. The first two sections is just a
    relatively simple proof that mining is more profitable as centralization
    increases under any circumstance, even before any real-world factors are
    taken into account. (other than non-zero latency and bandwidth) Nice
    homework problem, and neat that you can easily get a solid proof, but
    academic because it doesn't say anything about the magnitude of the
    incentives.
    
    The latter part is the actual derivation with proper model of
    supply-and-demand for fees. Or will be: while you can of course solve
    the equations with mathematica or similar - getting a horrid mess - I'm
    still trying to see if I can simplify them sanely in a way that's
    step-by-step understandable. Taking me longer than I'd like; sobering to
    realize how rusty I am. That said if any you do just throw it at
    Mathematica, looks like you get a result where the slope of your
    expected block return is at least quadratic with increasing hashing
    power. (though I spent all of five minutes eyeballing that result)
    
    
    \documentclass{article}
    \usepackage{url}
    \usepackage{mathtools}
    \begin{document}
    \title{Expected Return}
    \author{Peter Todd}
    \date{FIXME}
    \maketitle
    
    \section{Expected return of a block}
    \label{sec:exp-return-of-a-block}
    
    Let $f(L)$, a continuous function,\footnote{Transactions do of course give a
    discontinuous $f$. For a large $L$ the approximation error is negligible.} be
    the fee-per-byte available to a rational miner for the last transaction
    included in a block of size $L$. $f(L)$ is a continuous function defined for $L
    \ge 0$. Supply and demand dictates that:
    
    \begin{equation}
        f(L) \ge f(L+\epsilon) \label{eq:f-increases}
    \end{equation}
    
    A reasonable example for $f$ might be $f(L) = kL$, representing the demand side
    of a linear supply and demand plot. For a block of size $L$ that is optimally
    filled with transactions the value of those fees is just the integral:
    
    \begin{equation}
        E_f(L) = \int_0^L f(l)\,dl
    \end{equation}
    
    Let $P(Q,L)$, a continuous function, be the probability that a block of size
    $L$ produced by a miner with relative hashing power $Q$ will be orphaned.
    Because a miner will never orphan their own blocks the following holds true:
    
    \begin{equation}
        P(Q,L) \le P(Q + \epsilon,L) \label{eq:p-increases}
    \end{equation}
    
    Similarly because larger blocks take longer to propagate and thus risk getting
    orphaned by another miner finding a block at the same time:
    
    \begin{equation}
        P(Q,L) \ge P(Q,L + \epsilon)
    \end{equation}
    
    By combining $P(Q, L)$, $E_f(L)$ and the inflation subsidy $B$, gives us the
    expected return of a block for a given size and hashing power:\footnote{Note
    how real world marginal costs can be accommodated easily in the definitions of
    $f$ and $B$.}
    
    \begin{equation}
        E(Q,L) = P(Q,L)[E_f(L) + B]
    \end{equation}
    
    The optimal size is simply the size $L$ at which $E(Q, L)$ no longer increases:
    
    \begin{equation}
        \frac{d}{dL}\big[E(Q, L(Q))\big] = 0
    \end{equation}
    
    We will define the function $L(Q)$ as the optimal value for a given $Q$. A
    miner creating optimal blocks will thus have an expected return per block found
    of $E'(Q)=E(Q,L(Q))$. Note how this definition is per unit hashing power by
    virtue of being per block found.
    
    
    \section{Optimal return $E'$ vs. hashing power $Q$}
    
    We want to know if a large miner has a larger return for a given amount of
    hashing power. We do this by taking the derivative with respect to $Q$ of the
    expected return given optimal strategy:
    
    \begin{align*}
        \frac{d}{dQ}\big[E'(Q)\big] &= \frac{d}{dQ}\big[P(Q,L(Q))\big]\big[E_f(L(Q)) + B\big] + P(Q,L(Q))\frac{d}{dQ}\big[E_f(L(Q))\big] \\
                                    &= \frac{dL(Q)}{dQ}\Big[\frac{dP(Q,L(Q))}{dQ}\big[E_f(L(Q)) + B\big] + P(Q,L)\frac{dE_f(L(Q))}{dQ}\Big]
    \end{align*}
    
    We know that $L(Q)$, $E_f$, $P$, and $B$ are all $\ge 0$. Thus for $dE'/dQ$ to
    be negative requires either $dL/dQ$ to be negative, or for $dL/dQ$ to be
    positive and one of $dP/dQ$ or $dE_f/dQ$ negative.
    
    Suppose $dP/dQ$ negative and $dL/dQ$ positive:
    
    \begin{align}
        \frac{dL(Q)}{dQ} > 0    &\implies L(Q + \epsilon) > L(Q) \notag \\
        \frac{dP(L(Q))}{dQ} < 0 &\implies P(Q + \epsilon, L(Q + \epsilon)) < P(Q, L(Q)) \label{eq:dl-pos-dp-neg}
    \end{align}
    
    But that contradicts our definition \eqref{eq:p-increases} of $P$ as continuous
    and increasing. Suppose instead that $dE_f/dQ$ is negative and $dL/dQ$
    positive:
    
    \begin{align}
        \frac{dL(Q)}{dQ} > 0      &\implies L(Q) < L(Q + \epsilon) \notag \\
        \frac{dE_f(L(Q))}{dL} < 0 &\implies E_f(L(Q)) > E_f(L(Q + \epsilon)) \notag \\
                                  &\implies \int_0^{L(Q)} f(l)\,dl > \int_0^{L(Q+\epsilon)} f(l)\,dl \notag \\
                                  &\implies f(l) < 0 \label{eq:dl-pos-de-neg}
    \end{align}
    
    Again we have a contradiction with our definition \eqref{eq:f-increases} of
    $f$. Finally suppose $dL/dQ$ is negative:
    
    \begin{align}
        \frac{dL(Q)}{dQ} < 0 &\implies L(Q) > L(Q + \epsilon) \notag \\
                             &\implies P(Q + \epsilon, L(Q + \epsilon)) < P(Q, L(Q)) \notag \\
                             &\implies \frac{dP(Q, L(Q))}{dQ} < 0 \notag \\
                             &\implies \frac{dL(Q)}{dQ}\frac{dP(Q, L(Q))}{dQ} > 0 \label{eq:dl-neg-dp-neg} \\
                             &\implies E_f(L(Q + \epsilon)) < E_f(L(Q)) \implies \frac{dE_f(L(Q))}{dQ} < 0 \notag \\
                             &\implies \frac{dL(Q)}{dQ}\frac{dE_f(L(Q))}{dQ} > 0 \label{eq:dl-neg-de-neg}
    \end{align}
    
    Even if $dL/dQ$ is negative \eqref{eq:dl-neg-dp-neg} and
    \eqref{eq:dl-neg-de-neg} show that $dE'/dQ > 0$. In conjunction with
    \eqref{eq:dl-pos-dp-neg} and \eqref{eq:dl-pos-de-neg} we prove that increased
    hashing power always leads to increased return on investment per unit hashing
    power.
    
    
    \subsection{Real-world implications to centralization}
    
    While the author has shown that they still remember first-year, is this result
    relevant?
    
    The proof holds regardless of what any of the functions actually are, provided
    that they meet the requirements set out in section
    \ref{sec:exp-return-of-a-block}. The requirements are met by any reasonable
    real-world scenario\footnote{Negative fees are not reasonable!}, and show an
    incentive for mining to centralize even in an ideal situation where all miners
    are on a level playing field and have no fixed costs.
    
    However the proof is abstract, and doesn't tell us anything about how strong
    that pressure is; it may be insignificant enough to be outweighed by effects
    such as social pressure.
    
    We need to investigate $dE'/dQ$ in detail.
    
    
    \section{Detailed derivation of of $P(Q,L)$}
    
    \subsection{Assumptions}
    
    The difficulty is assumed to be in a steady state condition and the
    percentage of hashing power for any given miner is fixed. Unconfirmed
    transactions are assumed to be known to all miners, giving everyone an
    equal opportunity of mining any given transaction.
    
    We assume that the graph of all Bitcoin miners is fully connected and
    that the bandwidth, $1/k$, and latency, $t_0$, is identical for all
    connections and unchanging. We assume that miners always attempt to
    build upon the first block they see on the longest chain known to them,
    and when they find a block, they always broadcast it to all other miners
    simultaneously. From that we see that the time taken for a block of size
    $L$ to propagate to $100\%$ of the hashing power is simply:
    
    \begin{equation}
        t(L) = t_0 + kL
    \end{equation}
    
    
    \subsection{Analysis}
    
    When miner $Q$ finds a block during the condition of full consensus the
    outcomes can be described by the following state tree.  The numbers in brackets
    are the "scorecard" of blocks found by $Q$ and all other miners should a given
    state be reached:
    
    \begin{description}
    
        \item[1)] No other block is found prior to full propagation. (1:0)
    
        \item[2)] $Q$ finds another block prior to full propagation. (2:0)
        \begin{description}
            \item[2.1)] $Q$'s second block is not orphaned. (2:0)
            \item[2.2)] $Q$'s second block is orphaned. (2:3)
        \end{description}
    
        \item[3)] $(1-Q)$ finds another block prior to full propagation. (1:1)
        \begin{description}
            \item[3.1)] $(1-Q)$'s block is orphaned. (2:1)
            \item[3.2)] $(1-Q)$'s block is not orphaned. (1:2)
        \end{description}
    \end{description}
    
    Miner $Q$ wins if states $1$, $2.1$, or $3.1$ are reached. Though it is
    possible to derive an equation for $P$ that accurately models possible states -
    the author did exactly that in a fit of madness - the resulting equation is
    unwieldly and offers no additional insight.
    
    We want to end up with a $dE'/dQ$ that captures second order effects. Since
    $L(Q)$ and thus $E'(Q)$ will depend on $Q$ our approximation of $P$ should be
    such that $dP/dQ$ is at least linear.
    
    With $\lambda$ as the block interval the probabilities of reaching states $1$,
    $2$, and $3$ are as follows:
    \begin{align}
        p_1 &= 1 - \frac{t}{\lambda} \\
        p_2 &= \frac{t}{\lambda} Q \\
        p_3 &= \frac{t}{\lambda} (1-Q)
    \end{align}
    
    We could assume that states $2$ and $3$ both lead to the block being orphaned,
    thus giving us:
    \begin{equation}
        P(Q, L) = 1 - \frac{t}{\lambda} = 1 - \frac{t_o + kL}{\lambda}
    \end{equation}
    
    However this gives us a linear $E(Q, L)$, linear $L(Q)$, and thus only a
    quadratic $E'(Q)$. We need at least one more state in our model; state $2.1$ is
    a good choice. Reaching state $2.2$ is exceptionally improbable - the miners
    $(1-Q)$ have to find three blocks in time $t$ - so ignoring state $2.2$ and
    thus using the probability for state $2$ instead has negligible impact on the
    model. Meanwhile state $3$ requires that state $3.1$ be used directly and would
    result in a third-order terms in $P$ when treating state $3$ as an always loss
    is a conservative lower-bound.
    
    This gives us:
    \begin{align}
        P(Q, L) &= p_1 + p_2 = 1 - \frac{t}{\lambda} + \frac{t}{\lambda} Q = 1 - (1-Q)\frac{t}{\lambda} \notag \\
                &= 1 - (1-Q)\frac{t_o + kL}{\lambda}
    \end{align}
    
    
    \subsection{Detailed derivation of E'(Q)}
    
    Some preliminaries:
    
    \begin{align}
        \frac{dP(Q,L)}{dL} &= -(1-Q)\frac{k}{\lambda} \\
        \notag\\
        \frac{dE(Q,L)}{dL} &= \frac{dP(Q,L)}{dL}\big[E_f(L) + B\big] + P(Q,L)\frac{dE_f(L)}{dL} \notag\\
                           &= \frac{dP(Q,L)}{dL}\big[E_f(L) + B\big] + P(Q,L)\,f(L)
    \end{align}
    
    We're not going to get very far without a definition for $f$ so we'll use a
    simple linear demand model:
    
    \begin{align}
        f(L) &= a - bL \\
        E_f(L) &= aL - \frac{1}{2}bL^2
    \end{align}
    
    Now we set $dE/dL=0$ and solve for $L$. To simplify the problem we will consider the no-subsidy, $B=0$ case:
    
    \begin{align}
        0 &= \frac{dP(Q,L)}{dL}E_f(L) + P(Q,L)\,f(L) \\
          &= -(1-Q)\frac{k}{\lambda}\big[aL - \frac{1}{2}bL^2] + \big[1 - (1-Q)\frac{t_o + kL}{\lambda}\big](a - bL) \\
    \end{align}
    
    
    \end{document}
    
    > > Luckily the fork frequency and the average block size are easily
    > > measurable. blockchain.info keeps historical graphs of number of
    > > orphaned blocks pr day
    > 
    > Are those stats accurate? Have any pool operators at least confirmed that the
    > orphaned blocks that blockchain.info reports match their own records?
    > 
    > My gut feeling is to relay all orphaned blocks. We know that with a high
    > investment and sybil attack as blockchain.info has done you can have better
    > awareness of orphaned blocks than someone without those resources. If having
    > that awareness is ever a profitable thing we have both created an incentive to
    > sybil attack the network and we have linked profitability to high up-front
    > capital investments.
    > 
    > On those grounds alone I will argue that we should relay all orphans to even
    > the playing field. If there is a circumstance where we do not want the attacker
    > to have that knowledge we have failed anyway, as blockchain.info's sybil attack
    > on the network clearly shows.
    
    Agreed.
    
    -- 
    'peter'[:-1]@petertodd.org
    0000000000000004fe7b45f3bbc4c7edbd9ff86c963fe77282453e1b38f66503
    
    [-- Attachment #2: Digital signature --]
    [-- Type: application/pgp-signature, Size: 685 bytes --]
    
    ^ permalink raw reply	[flat|nested] 16+ messages in thread

  • • * Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
        2013-11-15  9:54   ` Peter Todd
      @ 2013-11-15  9:59     ` Gregory Maxwell
        2013-11-15 10:47     ` Michael Gronager
        1 sibling, 0 replies; 16+ messages in thread
      From: Gregory Maxwell @ 2013-11-15  9:59 UTC (permalink / raw)
        To: Peter Todd; +Cc: Bitcoin Dev, Michael Gronager
      
      On Fri, Nov 15, 2013 at 1:54 AM, Peter Todd <pete@petertodd•org> wrote:
      > \documentclass{article}
      
      LaTeX moon language to PDF moon language conversion:
      
      https://people.xiph.org/~greg/peter_todd_mining_ev.pdf
      
      
      
      ^ permalink raw reply	[flat|nested] 16+ messages in thread

    • * Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
        2013-11-15  9:54   ` Peter Todd
        2013-11-15  9:59     ` Gregory Maxwell
      @ 2013-11-15 10:47     ` Michael Gronager
        2013-11-15 11:12       ` Peter Todd
        1 sibling, 1 reply; 16+ messages in thread
      From: Michael Gronager @ 2013-11-15 10:47 UTC (permalink / raw)
        Cc: Bitcoin Dev
      
      -----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 in increased earnings.
      
      So build your own huge mining data center and you rock.
      
      However, that is hardly the real work scenario today. Instead we have
      pools (Huge pools). It would be interesting to do the calculation:
      
      	Q = Total pool size (fraction of all mining power)
      	q = My mining power (do.)
      	e = fraction of block fee that pool reserves
      
      It is pretty obvious that given your formulas small miners are better
      off in a pool (can't survive as solo miners), but there will be a
      threshold q_min above which you are actually better off on you own -
      depending also on e. (excluding here all benefits of a stable revenue
      stream provided by pools)
      
      Next interesting calculation would be bitcoin rate as a function of pool
      size, I expect a sharp dip somewhere in the 40%s of hardware controlled
      by one entity ;)
      
      Finally, as you mention yourselves, qualification of the various
      functions is needed. This could e.g. suggest if we are like to get 3 or
      10 miners on the long run.
      
      And now for section 2. You insert a definition of f(L) = a-bL. I think
      the whole idea of letting f depend on L is superfluous. As a miner you
      are always free to choose which transactions to include. You will always
      choose those with the biggest fee, so really it is only the average fee
      that is relevant: f(L) = c. Any dependence in L will be removed by the
      reshuffeling. To include an extra transaction will require either that
      it has a fee larger than another (kicking that out out) or that it has a
      fee so large that it covers for the other transaction too. Also recall
      that there is a logical minimum fee (as I have already shown), and a
      maximum optimal block size - that is until the bounty becomes 0 (which
      is where other effects kick in).
      
      > Here's what I've got to date. The first two sections is just a
      > relatively simple proof that mining is more profitable as centralization
      > increases under any circumstance, even before any real-world factors are
      > taken into account. (other than non-zero latency and bandwidth) Nice
      > homework problem, and neat that you can easily get a solid proof, but
      > academic because it doesn't say anything about the magnitude of the
      > incentives.
      > 
      > The latter part is the actual derivation with proper model of
      > supply-and-demand for fees. Or will be: while you can of course solve
      > the equations with mathematica or similar - getting a horrid mess - I'm
      > still trying to see if I can simplify them sanely in a way that's
      > step-by-step understandable. Taking me longer than I'd like; sobering to
      > realize how rusty I am. That said if any you do just throw it at
      > Mathematica, looks like you get a result where the slope of your
      > expected block return is at least quadratic with increasing hashing
      > power. (though I spent all of five minutes eyeballing that result)
      > 
      > 
      > \documentclass{article}
      > \usepackage{url}
      > \usepackage{mathtools}
      > \begin{document}
      > \title{Expected Return}
      > \author{Peter Todd}
      > \date{FIXME}
      > \maketitle
      > 
      > \section{Expected return of a block}
      > \label{sec:exp-return-of-a-block}
      > 
      > Let $f(L)$, a continuous function,\footnote{Transactions do of course give a
      > discontinuous $f$. For a large $L$ the approximation error is negligible.} be
      > the fee-per-byte available to a rational miner for the last transaction
      > included in a block of size $L$. $f(L)$ is a continuous function defined for $L
      > \ge 0$. Supply and demand dictates that:
      > 
      > \begin{equation}
      >     f(L) \ge f(L+\epsilon) \label{eq:f-increases}
      > \end{equation}
      > 
      > A reasonable example for $f$ might be $f(L) = kL$, representing the demand side
      > of a linear supply and demand plot. For a block of size $L$ that is optimally
      > filled with transactions the value of those fees is just the integral:
      > 
      > \begin{equation}
      >     E_f(L) = \int_0^L f(l)\,dl
      > \end{equation}
      > 
      > Let $P(Q,L)$, a continuous function, be the probability that a block of size
      > $L$ produced by a miner with relative hashing power $Q$ will be orphaned.
      > Because a miner will never orphan their own blocks the following holds true:
      > 
      > \begin{equation}
      >     P(Q,L) \le P(Q + \epsilon,L) \label{eq:p-increases}
      > \end{equation}
      > 
      > Similarly because larger blocks take longer to propagate and thus risk getting
      > orphaned by another miner finding a block at the same time:
      > 
      > \begin{equation}
      >     P(Q,L) \ge P(Q,L + \epsilon)
      > \end{equation}
      > 
      > By combining $P(Q, L)$, $E_f(L)$ and the inflation subsidy $B$, gives us the
      > expected return of a block for a given size and hashing power:\footnote{Note
      > how real world marginal costs can be accommodated easily in the definitions of
      > $f$ and $B$.}
      > 
      > \begin{equation}
      >     E(Q,L) = P(Q,L)[E_f(L) + B]
      > \end{equation}
      > 
      > The optimal size is simply the size $L$ at which $E(Q, L)$ no longer increases:
      > 
      > \begin{equation}
      >     \frac{d}{dL}\big[E(Q, L(Q))\big] = 0
      > \end{equation}
      > 
      > We will define the function $L(Q)$ as the optimal value for a given $Q$. A
      > miner creating optimal blocks will thus have an expected return per block found
      > of $E'(Q)=E(Q,L(Q))$. Note how this definition is per unit hashing power by
      > virtue of being per block found.
      > 
      > 
      > \section{Optimal return $E'$ vs. hashing power $Q$}
      > 
      > We want to know if a large miner has a larger return for a given amount of
      > hashing power. We do this by taking the derivative with respect to $Q$ of the
      > expected return given optimal strategy:
      > 
      > \begin{align*}
      >     \frac{d}{dQ}\big[E'(Q)\big] &= \frac{d}{dQ}\big[P(Q,L(Q))\big]\big[E_f(L(Q)) + B\big] + P(Q,L(Q))\frac{d}{dQ}\big[E_f(L(Q))\big] \\
      >                                 &= \frac{dL(Q)}{dQ}\Big[\frac{dP(Q,L(Q))}{dQ}\big[E_f(L(Q)) + B\big] + P(Q,L)\frac{dE_f(L(Q))}{dQ}\Big]
      > \end{align*}
      > 
      > We know that $L(Q)$, $E_f$, $P$, and $B$ are all $\ge 0$. Thus for $dE'/dQ$ to
      > be negative requires either $dL/dQ$ to be negative, or for $dL/dQ$ to be
      > positive and one of $dP/dQ$ or $dE_f/dQ$ negative.
      > 
      > Suppose $dP/dQ$ negative and $dL/dQ$ positive:
      > 
      > \begin{align}
      >     \frac{dL(Q)}{dQ} > 0    &\implies L(Q + \epsilon) > L(Q) \notag \\
      >     \frac{dP(L(Q))}{dQ} < 0 &\implies P(Q + \epsilon, L(Q + \epsilon)) < P(Q, L(Q)) \label{eq:dl-pos-dp-neg}
      > \end{align}
      > 
      > But that contradicts our definition \eqref{eq:p-increases} of $P$ as continuous
      > and increasing. Suppose instead that $dE_f/dQ$ is negative and $dL/dQ$
      > positive:
      > 
      > \begin{align}
      >     \frac{dL(Q)}{dQ} > 0      &\implies L(Q) < L(Q + \epsilon) \notag \\
      >     \frac{dE_f(L(Q))}{dL} < 0 &\implies E_f(L(Q)) > E_f(L(Q + \epsilon)) \notag \\
      >                               &\implies \int_0^{L(Q)} f(l)\,dl > \int_0^{L(Q+\epsilon)} f(l)\,dl \notag \\
      >                               &\implies f(l) < 0 \label{eq:dl-pos-de-neg}
      > \end{align}
      > 
      > Again we have a contradiction with our definition \eqref{eq:f-increases} of
      > $f$. Finally suppose $dL/dQ$ is negative:
      > 
      > \begin{align}
      >     \frac{dL(Q)}{dQ} < 0 &\implies L(Q) > L(Q + \epsilon) \notag \\
      >                          &\implies P(Q + \epsilon, L(Q + \epsilon)) < P(Q, L(Q)) \notag \\
      >                          &\implies \frac{dP(Q, L(Q))}{dQ} < 0 \notag \\
      >                          &\implies \frac{dL(Q)}{dQ}\frac{dP(Q, L(Q))}{dQ} > 0 \label{eq:dl-neg-dp-neg} \\
      >                          &\implies E_f(L(Q + \epsilon)) < E_f(L(Q)) \implies \frac{dE_f(L(Q))}{dQ} < 0 \notag \\
      >                          &\implies \frac{dL(Q)}{dQ}\frac{dE_f(L(Q))}{dQ} > 0 \label{eq:dl-neg-de-neg}
      > \end{align}
      > 
      > Even if $dL/dQ$ is negative \eqref{eq:dl-neg-dp-neg} and
      > \eqref{eq:dl-neg-de-neg} show that $dE'/dQ > 0$. In conjunction with
      > \eqref{eq:dl-pos-dp-neg} and \eqref{eq:dl-pos-de-neg} we prove that increased
      > hashing power always leads to increased return on investment per unit hashing
      > power.
      > 
      > 
      > \subsection{Real-world implications to centralization}
      > 
      > While the author has shown that they still remember first-year, is this result
      > relevant?
      > 
      > The proof holds regardless of what any of the functions actually are, provided
      > that they meet the requirements set out in section
      > \ref{sec:exp-return-of-a-block}. The requirements are met by any reasonable
      > real-world scenario\footnote{Negative fees are not reasonable!}, and show an
      > incentive for mining to centralize even in an ideal situation where all miners
      > are on a level playing field and have no fixed costs.
      > 
      > However the proof is abstract, and doesn't tell us anything about how strong
      > that pressure is; it may be insignificant enough to be outweighed by effects
      > such as social pressure.
      > 
      > We need to investigate $dE'/dQ$ in detail.
      > 
      > 
      > \section{Detailed derivation of of $P(Q,L)$}
      > 
      > \subsection{Assumptions}
      > 
      > The difficulty is assumed to be in a steady state condition and the
      > percentage of hashing power for any given miner is fixed. Unconfirmed
      > transactions are assumed to be known to all miners, giving everyone an
      > equal opportunity of mining any given transaction.
      > 
      > We assume that the graph of all Bitcoin miners is fully connected and
      > that the bandwidth, $1/k$, and latency, $t_0$, is identical for all
      > connections and unchanging. We assume that miners always attempt to
      > build upon the first block they see on the longest chain known to them,
      > and when they find a block, they always broadcast it to all other miners
      > simultaneously. From that we see that the time taken for a block of size
      > $L$ to propagate to $100\%$ of the hashing power is simply:
      > 
      > \begin{equation}
      >     t(L) = t_0 + kL
      > \end{equation}
      > 
      > 
      > \subsection{Analysis}
      > 
      > When miner $Q$ finds a block during the condition of full consensus the
      > outcomes can be described by the following state tree.  The numbers in brackets
      > are the "scorecard" of blocks found by $Q$ and all other miners should a given
      > state be reached:
      > 
      > \begin{description}
      > 
      >     \item[1)] No other block is found prior to full propagation. (1:0)
      > 
      >     \item[2)] $Q$ finds another block prior to full propagation. (2:0)
      >     \begin{description}
      >         \item[2.1)] $Q$'s second block is not orphaned. (2:0)
      >         \item[2.2)] $Q$'s second block is orphaned. (2:3)
      >     \end{description}
      > 
      >     \item[3)] $(1-Q)$ finds another block prior to full propagation. (1:1)
      >     \begin{description}
      >         \item[3.1)] $(1-Q)$'s block is orphaned. (2:1)
      >         \item[3.2)] $(1-Q)$'s block is not orphaned. (1:2)
      >     \end{description}
      > \end{description}
      > 
      > Miner $Q$ wins if states $1$, $2.1$, or $3.1$ are reached. Though it is
      > possible to derive an equation for $P$ that accurately models possible states -
      > the author did exactly that in a fit of madness - the resulting equation is
      > unwieldly and offers no additional insight.
      > 
      > We want to end up with a $dE'/dQ$ that captures second order effects. Since
      > $L(Q)$ and thus $E'(Q)$ will depend on $Q$ our approximation of $P$ should be
      > such that $dP/dQ$ is at least linear.
      > 
      > With $\lambda$ as the block interval the probabilities of reaching states $1$,
      > $2$, and $3$ are as follows:
      > \begin{align}
      >     p_1 &= 1 - \frac{t}{\lambda} \\
      >     p_2 &= \frac{t}{\lambda} Q \\
      >     p_3 &= \frac{t}{\lambda} (1-Q)
      > \end{align}
      > 
      > We could assume that states $2$ and $3$ both lead to the block being orphaned,
      > thus giving us:
      > \begin{equation}
      >     P(Q, L) = 1 - \frac{t}{\lambda} = 1 - \frac{t_o + kL}{\lambda}
      > \end{equation}
      > 
      > However this gives us a linear $E(Q, L)$, linear $L(Q)$, and thus only a
      > quadratic $E'(Q)$. We need at least one more state in our model; state $2.1$ is
      > a good choice. Reaching state $2.2$ is exceptionally improbable - the miners
      > $(1-Q)$ have to find three blocks in time $t$ - so ignoring state $2.2$ and
      > thus using the probability for state $2$ instead has negligible impact on the
      > model. Meanwhile state $3$ requires that state $3.1$ be used directly and would
      > result in a third-order terms in $P$ when treating state $3$ as an always loss
      > is a conservative lower-bound.
      > 
      > This gives us:
      > \begin{align}
      >     P(Q, L) &= p_1 + p_2 = 1 - \frac{t}{\lambda} + \frac{t}{\lambda} Q = 1 - (1-Q)\frac{t}{\lambda} \notag \\
      >             &= 1 - (1-Q)\frac{t_o + kL}{\lambda}
      > \end{align}
      > 
      > 
      > \subsection{Detailed derivation of E'(Q)}
      > 
      > Some preliminaries:
      > 
      > \begin{align}
      >     \frac{dP(Q,L)}{dL} &= -(1-Q)\frac{k}{\lambda} \\
      >     \notag\\
      >     \frac{dE(Q,L)}{dL} &= \frac{dP(Q,L)}{dL}\big[E_f(L) + B\big] + P(Q,L)\frac{dE_f(L)}{dL} \notag\\
      >                        &= \frac{dP(Q,L)}{dL}\big[E_f(L) + B\big] + P(Q,L)\,f(L)
      > \end{align}
      > 
      > We're not going to get very far without a definition for $f$ so we'll use a
      > simple linear demand model:
      > 
      > \begin{align}
      >     f(L) &= a - bL \\
      >     E_f(L) &= aL - \frac{1}{2}bL^2
      > \end{align}
      > 
      > Now we set $dE/dL=0$ and solve for $L$. To simplify the problem we will consider the no-subsidy, $B=0$ case:
      > 
      > \begin{align}
      >     0 &= \frac{dP(Q,L)}{dL}E_f(L) + P(Q,L)\,f(L) \\
      >       &= -(1-Q)\frac{k}{\lambda}\big[aL - \frac{1}{2}bL^2] + \big[1 - (1-Q)\frac{t_o + kL}{\lambda}\big](a - bL) \\
      > \end{align}
      > 
      > 
      > \end{document}
      > 
      >>> Luckily the fork frequency and the average block size are easily
      >>> measurable. blockchain.info keeps historical graphs of number of
      >>> orphaned blocks pr day
      >>
      >> Are those stats accurate? Have any pool operators at least confirmed that the
      >> orphaned blocks that blockchain.info reports match their own records?
      >>
      >> My gut feeling is to relay all orphaned blocks. We know that with a high
      >> investment and sybil attack as blockchain.info has done you can have better
      >> awareness of orphaned blocks than someone without those resources. If having
      >> that awareness is ever a profitable thing we have both created an incentive to
      >> sybil attack the network and we have linked profitability to high up-front
      >> capital investments.
      >>
      >> On those grounds alone I will argue that we should relay all orphans to even
      >> the playing field. If there is a circumstance where we do not want the attacker
      >> to have that knowledge we have failed anyway, as blockchain.info's sybil attack
      >> on the network clearly shows.
      > 
      > Agreed.
      > 
      
      -----BEGIN PGP SIGNATURE-----
      Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
      Comment: GPGTools - http://gpgtools.org
      Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
      
      iQEcBAEBAgAGBQJShfvZAAoJEKpww0VFxdGRDVoIALEgjxC8PQvj4hyp8CmTM8wP
      4ASL72gs/V6cRZuVPXjKJrrWxs2GjvxASQWaZa+9Oe5pXTg1Qa9yo5/3vBnB4kmK
      SgeJNo+C1rQjd3KuunAV0vG4pkIYnMa9GyBYnWf8mNuP1oysy8NSDOVt2jhtO5A3
      gKra0YFJYIEyOgewfefDrxokP0iSfQnJO7mPYfkoaLQm0ugoAi1IR8EiAuZX3oT9
      v80o9yhKqilz0wxhvsFAFf8txfpJw7LWTne5L/gQkHIV3v3dY7fLoWTfil/mqsAq
      6+d6xf+9s1tOXD18C/QTvhZIAyE3yiW7ZxbOyAYbQmbjORRZBdgWzaxCQbTHQNM=
      =k1i2
      -----END PGP SIGNATURE-----
      
      
      
      ^ permalink raw reply	[flat|nested] 16+ messages in thread

    • • * Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
          2013-11-15 10:47     ` Michael Gronager
        @ 2013-11-15 11:12       ` Peter Todd
          2013-11-15 11:58         ` Michael Gronager
          0 siblings, 1 reply; 16+ messages in thread
        From: Peter Todd @ 2013-11-15 11:12 UTC (permalink / raw)
          To: Michael Gronager; +Cc: Bitcoin Dev
        
        [-- Attachment #1: Type: text/plain, Size: 4171 bytes --]
        
        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 never orphans his own
        > blocks) island and growing that will of course result in increased earnings.
        > 
        > So build your own huge mining data center and you rock.
        > 
        > However, that is hardly the real work scenario today. Instead we have
        > pools (Huge pools). It would be interesting to do the calculation:
        > 
        > 	Q = Total pool size (fraction of all mining power)
        > 	q = My mining power (do.)
        > 	e = fraction of block fee that pool reserves
        > 
        > It is pretty obvious that given your formulas small miners are better
        > off in a pool (can't survive as solo miners), but there will be a
        > threshold q_min above which you are actually better off on you own -
        > depending also on e. (excluding here all benefits of a stable revenue
        > stream provided by pools)
        
        Unfortunately the math doesn't work that way. For any Q, a bigger Q
        gives you a higher return. Remember that the way I setup those equations
        in section 3.2 is such that I'm actually modeling two pools, one with Q
        hashing power and one with (1-Q) hashing power. Or maybe more
        accurately, it's irrelevant if the (1-Q) hashing power is or isn't a
        unified pool.
        
        The other thing is the fraction of the block fee the pool reserves
        indicates you're talking about real-world costs... and the moment you do
        that you find that pools themselves have economies of scale simply by
        virtue of using a small overhead infrastructure, their nodes etc., for a
        large number of miners. On that basis alone a small miner joining a
        larger pool would always be financially advantageous modulo situations
        where the large pool had legal restrictions that artificially increased
        their overheads.
        
        > Next interesting calculation would be bitcoin rate as a function of pool
        > size, I expect a sharp dip somewhere in the 40%s of hardware controlled
        > by one entity ;)
        
        Bitcoin rate?
        
        > Finally, as you mention yourselves, qualification of the various
        > functions is needed. This could e.g. suggest if we are like to get 3 or
        > 10 miners on the long run.
        
        The equations give an incentive to centralize all the way up to 1 miner
        with 100% hashing power.
        
        Of course, if that one pool were p2pool, that might be ok!
        
        > And now for section 2. You insert a definition of f(L) = a-bL. I think
        > the whole idea of letting f depend on L is superfluous. As a miner you
        > are always free to choose which transactions to include. You will always
        > choose those with the biggest fee, so really it is only the average fee
        > that is relevant: f(L) = c. Any dependence in L will be removed by the
        > reshuffeling. To include an extra transaction will require either that
        > it has a fee larger than another (kicking that out out) or that it has a
        > fee so large that it covers for the other transaction too. Also recall
        > that there is a logical minimum fee (as I have already shown), and a
        > maximum optimal block size - that is until the bounty becomes 0 (which
        > is where other effects kick in).
        
        By defining f(L) you can model supply and demand, which can be relevant
        in that a steep demand curve with a small number of high-fee
        transactions can reduce centralization pressure in my model.
        
        Of course, by defining f(L) = a-bL you also wind up with mathematica
        spitting out some truly hideous polynomials. :P Setting f(L) = c as you
        suggest is something I looked at, and results in equations that are more
        reasonable, so I think I'll likely wind up doing that. You can make a
        good argument anyway that the centralization would cause a flattening of
        any demand curve anyway, as in the no-blocksize-limit case the larger
        pools cost per transaction tends towards zero as their hashing power
        increases - why pay high fees when the large pool will mine them almost
        as fast?
        
        -- 
        'peter'[:-1]@petertodd.org
        0000000000000000b4ff49cd2cad865d6cbca99828987a02f3d5f41067eab00a
        
        [-- Attachment #2: Digital signature --]
        [-- Type: application/pgp-signature, Size: 685 bytes --]
        
        ^ permalink raw reply	[flat|nested] 16+ messages in thread

      • • * Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
            2013-11-15 11:12       ` Peter Todd
          @ 2013-11-15 11:58         ` Michael Gronager
            2013-11-15 19:09           ` Peter Todd
            0 siblings, 1 reply; 16+ messages in thread
          From: Michael Gronager @ 2013-11-15 11:58 UTC (permalink / raw)
            To: bitcoin-development
          
          -----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 setup those
          > equations in section 3.2 is such that I'm actually modeling two
          > pools, one with Q hashing power and one with (1-Q) hashing power.
          > Or maybe more accurately, it's irrelevant if the (1-Q) hashing
          > power is or isn't a unified pool.
          
          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 economy of scale (well actually a math
          of scale...) and that can end up paying for the lost e. The question
          is what is the ratio q/Q where I should rather mine on my own ? This
          question is interesting as it will make bigger miners break away from
          pools into solo mining, but I also agree that from pure math the most
          advantageous scenario is the 100% mining rig.
          
          > The equations give an incentive to centralize all the way up to 1
          > miner with 100% hashing power.
          > 
          > Of course, if that one pool were p2pool, that might be ok!
          
          Ha, yes, and then the math for p2pool starts... a math where we have
          much more stales...
          
          
          -----BEGIN PGP SIGNATURE-----
          Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
          Comment: GPGTools - http://gpgtools.org
          Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
          
          iQEcBAEBAgAGBQJShgxWAAoJEKpww0VFxdGRoiwH/3RGTH503PJ8UWuyKjrxscb4
          dG3TyThZCDs12DvtC+2TPKnIkQFinGx9442tZU/O+qmwsGJsNVoEcnGmKEYz/vlI
          XzFF30ugslB4FKwHZYRqXELaKR4RvUtSzu6td8P3n+e6d0MZsuemMornpbXZkw3n
          CbMlYuiG4h3iUAwTaOTS26cFbZoo6eyogydDjnS7Ogi2Ur85Rydi/Lj24rj7UxYB
          +WUkYAv3bCqCzTkv1LxO7HwY1SICZDmoGRbuil5M7bJ+MftYt6Q6DVprGSVP0mOV
          9eEVeMVY/WmMZCI/01ruXpzC3gxU60vOd/a3q9G2hd9Tn00HzugAllEXh7ZzzUs=
          =unP8
          -----END PGP SIGNATURE-----
          
          
          
          ^ permalink raw reply	[flat|nested] 16+ messages in thread

        • • * Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
              2013-11-15 11:58         ` Michael Gronager
            @ 2013-11-15 19:09           ` Peter Todd
              0 siblings, 0 replies; 16+ messages in thread
            From: Peter Todd @ 2013-11-15 19:09 UTC (permalink / raw)
              To: Michael Gronager; +Cc: bitcoin-development
            
            [-- Attachment #1: Type: text/plain, Size: 2081 bytes --]
            
            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 economy of scale (well actually a math
            > of scale...) and that can end up paying for the lost e. The question
            > is what is the ratio q/Q where I should rather mine on my own ? This
            > question is interesting as it will make bigger miners break away from
            > pools into solo mining, but I also agree that from pure math the most
            > advantageous scenario is the 100% mining rig.
            
            The underlying issue is what is the pools expenses compared to yours.
            There is an overhead to mining, you need to spend money and time (and
            hence money) running and administering full nodes at the very minimum.
            The pool can amortise that cost over many hashers; the solo miner can't.
            
            Pools will of course have some profit margin, but why would you expect
            that margin to not be sufficiently low to make it in a solo-miner's
            interest to join the pool? Both the pool and the former solo-miner earn
            more return after all if they centralize.
            
            The fundemental issue is that in the design of Bitcoin there is an
            incentive for miners to join into pools, and that incentive exists at
            any amount of hashing power. Sure second order effects like regulation
            and social pressure can counteract that incentive in some circumstances,
            but that's not very strong protection.
            
            > > The equations give an incentive to centralize all the way up to 1
            > > miner with 100% hashing power.
            > > 
            > > Of course, if that one pool were p2pool, that might be ok!
            > 
            > Ha, yes, and then the math for p2pool starts... a math where we have
            > much more stales...
            
            However p2pool doesn't necessarily need a linear blockchain to function,
            so there is a potential for stales to be much less relevant.
            
            -- 
            'peter'[:-1]@petertodd.org
            000000000000000772f720b0a231150f22af20760c1463ef920f71ba3daab819
            
            [-- Attachment #2: Digital signature --]
            [-- Type: application/pgp-signature, Size: 490 bytes --]
            
            ^ permalink raw reply	[flat|nested] 16+ messages in thread

• * Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
    2013-11-13 11:52 Michael Gronager
    2013-11-13 12:34 ` Michael Gronager
    2013-11-13 20:01 ` John Dillon
  @ 2013-11-15 10:32 ` Peter Todd
    2013-11-15 11:47   ` Michael Gronager
    2 siblings, 1 reply; 16+ messages in thread
  From: Peter Todd @ 2013-11-15 10:32 UTC (permalink / raw)
    To: Michael Gronager; +Cc: Bitcoin Dev
  
  [-- Attachment #1: Type: text/plain, Size: 2536 bytes --]
  
  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.
  > 
  > 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 simple number we
  > can use to estimate the minimum fee. Key assumption is that the latency
  > will depend on block size (# txns) and the fork rate will depend on latency.
  > 
  > Using the formulas from last week:
  > 
  > P_fork = t_propagate/t_blocks
  > 
  > and:
  > 
  > t_propagate = t_0 + alpha*S ~= alpha*S
  
  Assuming t_0 is negligible is wrong in this case. Or, it should be...
  
  > We get a measure for alpha as a function of the average fork rate and
  > average block size:
  > 
  > alpha = P_fork*t_block/S
  
  So alpha has units of seconds/byte, which lets us indirectly figure out
  the bandwidth the blocks are propagating at assuming t_0=0 and all links
  are equal. When you realize that P_fork is basically a multiplier on the
  bandwidth required to get a block out fast enough, the derivation makes
  sense. In any case we get:
  
  alpha = (1/113)*600s/134kBytes = 39.62uS/byte = 24kB/second
  
  Which is atrocious... but when you remember that Bitcoin nodes send
  blocks to all peers simultaneously,(1) thus dividing up the bandwidth and
  ruining latency you see why. t_0 shouldn't be at all negligible due to
  speed of light, but with this low bandwidth it is anyway.
  
  1) To be precise, nodes answer queries for blocks from all peers
  simultaneously.
  
  This also indicates that pools haven't taken the simple step of peering
  with each other using high-bandwidth nodes with restricted numbers of
  peers, which shows you how little attention they are paying to
  optimizing profits.  Right now mining pulls in $1.8 million/day, so
  that's up to $16k wasted.
  
  However, because miners don't orphan themselves, that $16k loss is born
  disproportionately by smaller miners... which also means the 24kB/sec
  bandwidth estimate is wrong, and the real number is even worse. In
  theory anyway, could just as easily be the case that larger pools have
  screwed up relaying still such that p2pool's forwarding wins.
  
  -- 
  'peter'[:-1]@petertodd.org
  000000000000000658459cd64e63243e719106014257870d073207c2d5460137
  
  [-- Attachment #2: Digital signature --]
  [-- Type: application/pgp-signature, Size: 685 bytes --]
  
  ^ permalink raw reply	[flat|nested] 16+ messages in thread

• • * Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
      2013-11-15 10:32 ` Peter Todd
    @ 2013-11-15 11:47   ` Michael Gronager
      2013-11-15 19:19     ` Peter Todd
      0 siblings, 1 reply; 16+ messages in thread
    From: Michael Gronager @ 2013-11-15 11:47 UTC (permalink / raw)
      To: bitcoin-development
    
    -----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 agree it
    is strikingly small (ISDN like), but this is not the case, the size
    dependence of this number originates both from the limited network
    bandwidth and from the validation and verification time of the blocks as
    well as the latency in sending thee again.
    
    The connection between propagation time and fork rate cannot be denied,
    and the bandwidth can be deducted from that alone - see Decket et al.
    
    t_0 on a 10000km link is on the order of 40ms, and that is only counting
    the finite light speed in the fibers - if you ping the same distance you
    get roughly 1-200ms (due to latencies in network equipment). at a size
    of ~100kbyte t_0 hence becomes irrelevant.
    
    > This also indicates that pools haven't taken the simple step of peering
    > with each other using high-bandwidth nodes with restricted numbers of
    > peers
    
    agree
    
    > , which shows you how little attention they are paying to
    > optimizing profits.  Right now mining pulls in $1.8 million/day, so
    > that's up to $16k wasted.
    
    yup, but the relevant comparison is not 16k vs 1.8m, but the pool
    operator earnings which are on the order of 1% of the 1.8m so it is 18k
    vs 16k - I wouldn't mind doubling my income...
    
    > 
    > However, because miners don't orphan themselves, that $16k loss is born
    > disproportionately by smaller miners... which also means the 24kB/sec
    > bandwidth estimate is wrong, and the real number is even worse.
    
    Yes, agree
    
    > In
    > theory anyway, could just as easily be the case that larger pools have
    > screwed up relaying still such that p2pool's forwarding wins.
    
    Yeah, we should resurrect p2pool ;)
    
    > 
    > 
    > 
    > ------------------------------------------------------------------------------
    > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
    > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
    > Free app hosting. Or install the open source package on any LAMP server.
    > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
    > http://pubads.g.doubleclick.net/gampad/clk?id=63469471&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/
    
    iQEcBAEBAgAGBQJShgniAAoJEKpww0VFxdGRrwQIALKsOtBUaAaQTX9ikN+10mSE
    pE2dp2VnUvfUqpXf3MgJtAvg2RFqHjziyBMYmpMw5tLJPpeUthpNXm6Vm/Yg0DdL
    JXSESIrd4Pdb/xPk2Fh9OKHmR1SB/8VxtRL2Vj1HmzzBcBiCylcaBuKlRkizvGSF
    KrUm3EOFUfzgGYFUnqNceZ3CuQHWFAXbsitNqU6Vop8JOTgiSLhUrvb7r3W7Ewuy
    jM3H2KAk/PrdGXwna3sUfDXmmOxmPm1pBy6+OaBTHEv+ALkreD++XSUnLUUTky9N
    nZt2g7eMEFHIkVooj/HOGiwAvVwd7r86etiyUi8c2Pd46ff2OP5h1uiP/Qr28MA=
    =Bsv9
    -----END PGP SIGNATURE-----
    
    
    
    ^ permalink raw reply	[flat|nested] 16+ messages in thread

  • • * Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
        2013-11-15 11:47   ` Michael Gronager
      @ 2013-11-15 19:19     ` Peter Todd
        2013-11-20 10:01       ` Peter Todd
        0 siblings, 1 reply; 16+ messages in thread
      From: Peter Todd @ 2013-11-15 19:19 UTC (permalink / raw)
        To: Michael Gronager; +Cc: bitcoin-development
      
      [-- Attachment #1: Type: text/plain, Size: 1610 bytes --]
      
      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 = 29ms/kb
      
      Huh? Where did 454000 come from?
      
      > > , which shows you how little attention they are paying to
      > > optimizing profits.  Right now mining pulls in $1.8 million/day, so
      > > that's up to $16k wasted.
      > 
      > yup, but the relevant comparison is not 16k vs 1.8m, but the pool
      > operator earnings which are on the order of 1% of the 1.8m so it is 18k
      > vs 16k - I wouldn't mind doubling my income...
      
      That's only true for a PPS pool though, not the more usual pools that
      pay relative to blocks actually found. Heh, actually, that might be part
      of the problem... also doesn't help how varience is going to make
      noticing 1% hard.
      
      > > In
      > > theory anyway, could just as easily be the case that larger pools have
      > > screwed up relaying still such that p2pool's forwarding wins.
      > 
      > Yeah, we should resurrect p2pool ;)
      
      P2Pool has 1% hashing power right now; I mine on it myself with what
      little hashing power I have.
      
      The more interesting thing is how do you grow P2Pool - requiring a full
      node is going to make that tricky. Also the once we start adding more
      efficient block propagation by transmitting headers + txids p2pool's
      current advantage goes away.
      
      -- 
      'peter'[:-1]@petertodd.org
      0000000000000005fbc1840bbd5bd71d4d6cd2930e20da9e697710f58bd4f69d
      
      [-- Attachment #2: Digital signature --]
      [-- Type: application/pgp-signature, Size: 490 bytes --]
      
      ^ permalink raw reply	[flat|nested] 16+ messages in thread

    • • * Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
          2013-11-15 19:19     ` Peter Todd
        @ 2013-11-20 10:01       ` Peter Todd
          0 siblings, 0 replies; 16+ messages in thread
        From: Peter Todd @ 2013-11-20 10:01 UTC (permalink / raw)
          To: Michael Gronager; +Cc: bitcoin-development
        
        [-- Attachment #1: Type: text/plain, Size: 633 bytes --]
        
        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
        > > > 
        > > > Which is atrocious... 
        > > 
        > > alpha = P_fork*t_block/S = 1/113*454000/134 = 29ms/kb
        > 
        > Huh? Where did 454000 come from?
        
        Oh right, you're using the actual block interval, not the steady state
        one.
        
        -- 
        'peter'[:-1]@petertodd.org
        00000000000000056032432f186a8276d3feecb805d064c1def85905670a453b
        
        [-- Attachment #2: Digital signature --]
        [-- Type: application/pgp-signature, Size: 685 bytes --]
        
        ^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2013-11-20 10:01 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-13 23:52 [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize Gavin Andresen
  -- strict thread matches above, loose matches on Subject: below --
2013-11-13 11:52 Michael Gronager
2013-11-13 12:34 ` Michael Gronager
2013-11-15 10:46   ` Peter Todd
2013-11-13 20:01 ` John Dillon
2013-11-13 20:32   ` Michael Gronager
2013-11-15  9:54   ` Peter Todd
2013-11-15  9:59     ` Gregory Maxwell
2013-11-15 10:47     ` Michael Gronager
2013-11-15 11:12       ` Peter Todd
2013-11-15 11:58         ` Michael Gronager
2013-11-15 19:09           ` Peter Todd
2013-11-15 10:32 ` Peter Todd
2013-11-15 11:47   ` Michael Gronager
2013-11-15 19:19     ` Peter Todd
2013-11-20 10:01       ` Peter Todd

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox