[Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big)

[Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big)

[Michael Gronager]

Following the discussion on the recent mining sybil trick, I reread the
article on block propagation by Decker et al.* and decided to use it for
doing a proper estimate of transaction fee size and optimal block size.

The propagation of a block depends on and is roughly proportional to its
size. Further, the slower a block propagates the higher the risk of a
fork, so as a miner you are basically juggling the risk of a fork
(meaning you loose your bounty) vs the opportunity for including more
transactions and hence also get those fees.

This alone will dictate the minimal transaction fee as well as the
optimal block size!

Lets try to put it into equations. For the purpose of this initial study
lets simplify the work by Decker et al. Roughly, we can say that the
average propagation time for a block is t_propagate, and the average
time between blocks is t_blocks. Those are roughly 10sec and 600sec
respectively. The risk of someone else mining a block before your block
propagates is roughly**:

P_fork = t_propagate/t_blocks (~1/60)

Also note that propagation time is a function of block size, S:

t_propagate = t_0 + alpha*S

where Decker et al have determined alpha to 80ms/kb. We also define the
fee size pr kilobyte, f, so

E_fee = f*S

Given these equations the expected average earning is:

E = P_hashrate*(1 - P_fork)*(E_bounty + E_fees)

And inserting:

E  = P_hashrate*[1 - (t_0 + alpha*S)/t_block]*(E_bounty + f*S)

We would like to choose the fee so the more transactions we include the
more we earn. I.e. dE/dS > 0:

dE/dS = P_hashrate*{[(t_block - t_0)*f - alpha*E_bounty]/t_block -
2*alpha*f/t_block*S}

Which gives:

 f > alpha*E_bounty/(t_block-t_0) ~ alpha*E_bounty/t_block

or f > 80*25/600000 = 0.0033 or assuming a standard transaction size of
0.227kb:

f_tx > 0.00076.

Note that this number is 8 times higher than the current transaction
fee! So the current optimal block size is an empty block i.e. without
other transactions than the coinbase! (miners don't listen now...)

Lets see what you loose by e.g. including 1000 transactions:

E(1000) = P_hashrate*24.34XBT

Which is a loss of 2.6% compared to not including transactions at all!

So there are two ways forward from here. 1) raise the minimum fee, and
2) make transactions smaller. We cannot make transactions much smaller,
but we can utilize that most of them have already been broadcasted
verified and validated and then just include their hash in the block***.
This changes the relevant size for a transaction from 0.227kb to
0.032kb. Which makes f_tx = 0.00011. We are almost there!

Now assume that we implement this change and raise the minimum fee to
0.00015, what is then the optimal block size (dE/dS = 0) ?

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

Which gives 1083kb for a bounty of 25 and 2417kb for a bounty of 12.5.
Optimal size in case of no bounty or an infinite fee is 3750MB.

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.

*)
http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf
**) The calculations should be done using the proper integrals and
simulations, but I will leave that for academia ;)
***) A nice side effect from switching to broadcasting transactions in
blocks as only their hash is that it decouples fee size from transaction
size!

Re: [Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big)

[Pieter Wuille]

Hi,

(I didn't have time to read your e-mail entirely yet, I'll do so later)

I believe that C. Decker's paper used measurements for propagation
delays for blocks 180000-190000, which happened between may and juli
2012. The latest bitcoind/bitcoin-qt release at the time was 0.6.3.

I'm sure the general patterns are valid, but if you're relying on
actual speed numbers, I believe they may be very different now. I
don't have numbers of course, but at least the changes 0.8 should
impact propagation significantly. Some changes merged in git head (to
become 0.9) could improve things further. If we're talking about
long-term scalability, we should base decisions on the best technology
available, at least.

-- 
Pieter


On Thu, Nov 7, 2013 at 3:11 PM, Michael Gronager <gronager@ceptacle.com> wrote:
> Following the discussion on the recent mining sybil trick, I reread the
> article on block propagation by Decker et al.* and decided to use it for
> doing a proper estimate of transaction fee size and optimal block size.
>
> The propagation of a block depends on and is roughly proportional to its
> size. Further, the slower a block propagates the higher the risk of a
> fork, so as a miner you are basically juggling the risk of a fork
> (meaning you loose your bounty) vs the opportunity for including more
> transactions and hence also get those fees.
>
> This alone will dictate the minimal transaction fee as well as the
> optimal block size!
>
> Lets try to put it into equations. For the purpose of this initial study
> lets simplify the work by Decker et al. Roughly, we can say that the
> average propagation time for a block is t_propagate, and the average
> time between blocks is t_blocks. Those are roughly 10sec and 600sec
> respectively. The risk of someone else mining a block before your block
> propagates is roughly**:
>
> P_fork = t_propagate/t_blocks (~1/60)
>
> Also note that propagation time is a function of block size, S:
>
> t_propagate = t_0 + alpha*S
>
> where Decker et al have determined alpha to 80ms/kb. We also define the
> fee size pr kilobyte, f, so
>
> E_fee = f*S
>
> Given these equations the expected average earning is:
>
> E = P_hashrate*(1 - P_fork)*(E_bounty + E_fees)
>
> And inserting:
>
> E  = P_hashrate*[1 - (t_0 + alpha*S)/t_block]*(E_bounty + f*S)
>
> We would like to choose the fee so the more transactions we include the
> more we earn. I.e. dE/dS > 0:
>
> dE/dS = P_hashrate*{[(t_block - t_0)*f - alpha*E_bounty]/t_block -
> 2*alpha*f/t_block*S}
>
> Which gives:
>
>  f > alpha*E_bounty/(t_block-t_0) ~ alpha*E_bounty/t_block
>
> or f > 80*25/600000 = 0.0033 or assuming a standard transaction size of
> 0.227kb:
>
> f_tx > 0.00076.
>
> Note that this number is 8 times higher than the current transaction
> fee! So the current optimal block size is an empty block i.e. without
> other transactions than the coinbase! (miners don't listen now...)
>
> Lets see what you loose by e.g. including 1000 transactions:
>
> E(1000) = P_hashrate*24.34XBT
>
> Which is a loss of 2.6% compared to not including transactions at all!
>
> So there are two ways forward from here. 1) raise the minimum fee, and
> 2) make transactions smaller. We cannot make transactions much smaller,
> but we can utilize that most of them have already been broadcasted
> verified and validated and then just include their hash in the block***.
> This changes the relevant size for a transaction from 0.227kb to
> 0.032kb. Which makes f_tx = 0.00011. We are almost there!
>
> Now assume that we implement this change and raise the minimum fee to
> 0.00015, what is then the optimal block size (dE/dS = 0) ?
>
>  S = 1/2 * (t_block/alpha - E_bounty/f)
>
> Which gives 1083kb for a bounty of 25 and 2417kb for a bounty of 12.5.
> Optimal size in case of no bounty or an infinite fee is 3750MB.
>
> 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.
>
> *)
> http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf
> **) The calculations should be done using the proper integrals and
> simulations, but I will leave that for academia ;)
> ***) A nice side effect from switching to broadcasting transactions in
> blocks as only their hash is that it decouples fee size from transaction
> size!
>
> ------------------------------------------------------------------------------
> 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

Re: [Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big)

[Pieter Wuille]

Correcting myself:

On Thu, Nov 7, 2013 at 4:00 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> I believe that C. Decker's paper used measurements for propagation
> delays for blocks 180000-190000, which happened between may and juli
> 2012. The latest bitcoind/bitcoin-qt release at the time was 0.6.3.

They did use data from blocks 20000-210000, september-november 2012.
That was still before the 0.8 release, however.

-- 
Pieter

Re: [Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big)

[Mike Hearn]

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

I think trying to help miners figure out the propagation/fees tradeoff at
the moment is a non-starter until we understand it better ourselves. A
server that tracks and records block propagation times, how many fees per
passed up per block, orphan stats per size bucket etc would be tremendously
helpful.


On Thu, Nov 7, 2013 at 4:19 PM, Pieter Wuille <pieter.wuille@gmail.com>wrote:

> Correcting myself:
>
> On Thu, Nov 7, 2013 at 4:00 PM, Pieter Wuille <pieter.wuille@gmail.com>
> wrote:
> > I believe that C. Decker's paper used measurements for propagation
> > delays for blocks 180000-190000, which happened between may and juli
> > 2012. The latest bitcoind/bitcoin-qt release at the time was 0.6.3.
>
> They did use data from blocks 20000-210000, september-november 2012.
> That was still before the 0.8 release, however.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> 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
>

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

Re: [Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big)

[Michael Gronager]

Mike, Pieter,

My writeup outlines a framework for good approximation to a minimal fee
as well as the optimal block size. The model has basically just one
parameter, the propagation time - if that goes down, so can the fee.
(Well there is another parameter too, the time btw blocks, which
currently with the current hash acceleration is more like 400 than 600).

Also seconding Mike, that, yes, it would be tremendously useful to track
propagation times and other things on the network to help us all decide
the proper settings.

Finally, it would be great if someone from academia would grab the ball
and do the full probabilistic analysis based on my outline.

Michael

On 7/11/13, 16:22 , Mike Hearn wrote:
> I think trying to help miners figure out the propagation/fees tradeoff
> at the moment is a non-starter until we understand it better ourselves.
> A server that tracks and records block propagation times, how many fees
> per passed up per block, orphan stats per size bucket etc would be
> tremendously helpful.
> 
> 
> On Thu, Nov 7, 2013 at 4:19 PM, Pieter Wuille <pieter.wuille@gmail.com
> <mailto:pieter.wuille@gmail.com>> wrote:
> 
>     Correcting myself:
> 
>     On Thu, Nov 7, 2013 at 4:00 PM, Pieter Wuille
>     <pieter.wuille@gmail.com <mailto:pieter.wuille@gmail.com>> wrote:
>     > I believe that C. Decker's paper used measurements for propagation
>     > delays for blocks 180000-190000, which happened between may and juli
>     > 2012. The latest bitcoind/bitcoin-qt release at the time was 0.6.3.
> 
>     They did use data from blocks 20000-210000, september-november 2012.
>     That was still before the 0.8 release, however.
> 
>     --
>     Pieter
> 
>     ------------------------------------------------------------------------------
>     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
>     <mailto:Bitcoin-development@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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
> 

Re: [Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big)

[Peter Todd]

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

> 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.

Your definition of P_fork is inaccurate for a miner with non-negligable
hashing power - a miner will never fork themselves. Taking that into
account we have three outcomes:

1) The block propagates without any other miner finding a block.
2) During propagation another miner finds a block. (tie)
2.1) You win the tie by finding another block.
2.2) You lose the tie because someone else finds a block.

We will define t_prop as the time it takes for a block to propagate from
you to 100% of the hashing power, and as a simplifying assumption we
will assume that until t_prop has elapsed, 0% of the hashing power has
the block, and immedately after, 100% has the block. We will also define
t_int, the average interval between blocks. (600 seconds for Bitcoin)
Finally, we will define Q as the probability that you will find the next
block.

The probabilities of the various outcomes:

1) 1 - (t_prop/t_int * (1-Q))
2) t_prop/t_int * (1-Q)
2.1) Q
2.2) 1-Q

Note that to simplify the equations we have not taking into account
propagation in our calculations for outcomes 2.1 or 2.2

Thus we can define P_fork taking into account Q:

P_fork(Q) = (t_prop/t_int * (1-Q))(1-Q) = t_pop/t_int * (1-Q)^2

Over the range 0 < Q < 0.5 the probability of a fork decreases
approximately linearly as your hashing power increases:

d/dq P_fork(Q) = 2(Q-1)

Q=0   -> d/dq P_fork(Q) = -2
Q=1/2 -> d/dq P_fork(Q) = -1

With our new, more accurate, P_fork(Q) function lets re-calculate the
break-even fee/KB using your original approach:

t_prop = t_0 + \alpha*S
E_fee = f*S

E(Q) = Q*(1 - P_fork(Q))*(E_bounty + E_fee)
E(Q) = Q*[1 - (t_0 + k*S)/t_int * (1-Q)^2]*(E_B + f*S)

d/dS E(Q) = Q*[ -2fSk/t_int*(1-Q)^2 - f*t_0/t_int*(1-Q)^2 + f - E_b*k/t_int*(1-Q)^2 ]

Again, we want to choose the fee so that the more transactions we
include the more we earn, dE/dS > 0 We find the minimum fee to include a
transaction at all by setting S=0, thus we get:

d/dS E(Q, S=0) = Q*[ f - f*t_0/t_int*(1-Q)^2 - E_b*k/t_int*(1-Q)^2 ] > 0

f(1 - t_0/t_int*(1-Q)^2) > E_b*k/t_int*(1-Q)^2

f > [E_b*k/t_int(1-Q)^2] / [1 - t_0/t_int*(1-Q)^2]

f > [E_b*k*(1-Q)^2] / [t_int - t_0*(1-Q)^2]

With Q=0:

f > E_b*k / (t_int - t_0) ~ E_b*k/t_int

This is the same result you derived. However lets look at Q != 0:

df/dQ = 2*E_b*k * [t_int*(q-1)] / [t_int - t_0(q-1)^2]^2

With negligible latency we get:

df/dQ, t_0=0 = 2*E_b*k*(q-1)/t_int

So what does that mean? Well in the region 0 < q < 1/2, df/dQ is always
negative. In other words, as you get more hashing power, the fee/KB you
can charge and still break even decreases linearly because you will
never orphan yourself. Lets trythe same assumptions as your first
analysis, based on the work by Decker et al

Based on the work by Decker et al, lets try to calculate break-even
fee/KB for negligible, 10%, 25% and 40% hashing power:

t_0 = 10s
t_int = 600s
k = 80ms/kB
E_b = 25BTC

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

Let's assume every miner is directly peered with every other miner, each
of those connections is 1MB/s, and somehow there's no latency at all:

k = 1mS/kB

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

Regardless of how you play around with the parameters, being a larger
miner has a significant advantage because you can charge lower fees for
your transactions and therefor earn more money. But it gets even more
ugly when you take into account that maybe a guy with 0.1% hashing power
can't afford the high bandwidth, low-latency, internet connection that
the larger pool has:

k = 10mS/kB, t_0=5s, Q=0.01 -> 0.000411 BTC/KB
k =  1mS/kB, t_0=1s, Q=0.15 -> 0.000030 BTC/KB

So the 1% pool has an internet connection capable of 100kB/s to each
peer, taking 5s to reach all the hashing power. The 15% pool can do
1MB/s to each peer, taking 1s to reach all the hashing power. This small
different means that the 1% pool needs to charge 13.7x more per KB for
their transactions to break even! It's a disaster for decentralization.
Businesses live and die on percentage points, let alone orders of
magnitude differences in cost, and I haven't even taken into account
second-order effects like the perverse incentives to publish your blocks
to only a minority of hashing power.(1)

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. It's a fundemental issue. An
unlimited blocksize will make the problem even worse by increasing fixed
costs, but keeping the blocksize at 1MB forever doesn't solve the
underlying problem either as the inflation subsidy becomes less
important and fees more important.

1) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03200.html

-- 
'peter'[:-1]@petertodd.org
00000000000000054eeccf3ac454892457bf4919d78efb275efd2ddd1a920c99

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big)

[Michael Gronager]

-----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-----

Re: [Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big)

[Peter Todd]

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

On Thu, Nov 07, 2013 at 10:58:42PM +0100, Michael Gronager wrote:
> > 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.

Well if large pools wanted it would be trivial for all of them to just
connect to each other... but my 25kB/s average data rate sure indicates
that they either aren't bothering, or aren't bothering to do that
correctly.

> However - important
> note - if you are a 1% miner - don't include transactions!

Which is an awful solution, although probably a correct one.... After
all, if you don't include transactions, you can start mining blocks
earlier too based on just the header.

> > 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).

That's a fundemental misunderstanding; there's no such thing as a min
fee.

As for economies of scale, the "product" we're paying miners for is
decentralization and resistance to 51% attack. If instead only get 51%
attack resistance, we're getting a bum deal. If that's all we're
getting, we don't actually have 51% resistance...

-- 
'peter'[:-1]@petertodd.org
00000000000000075ed91531e07d2045b5823da050fe373bde7bb363965e44ae

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]