Re: [Bitcoin-development] we can all relax now
On Wed, Nov 06, 2013 at 10:59:28PM -0600, Kyle Jerviss wrote: Each block that you solve has a reward. In practice, some blocks will be orphaned, so the expected reward is slightly less than the nominal reward. Each second that you delay publishing a block, the expected reward drops somewhat. You don't understand how to read papers. A good author will state his assumptions. For instance my third paragraph read: Now in a purely inflation subsidy environment, where I don't care about the other miners success, of course I should publish. However, if my goals are to find *more* blocks than the other miners for whatever reason, maybe because transaction fees matter or I'm trying to get nLockTime'd announce/commit fee sacrifices, it gets more complicated. Now that you understand the assumptions made, you can attack the paper in one of two ways: 1) Show it's wrong. 2) Show its assumptions make it irrelevant. You've done neither. -- 'peter'[:-1]@petertodd.org 0006d61eb32f3643aa30c2f9647e4e758af84b03abc43f09959f signature.asc Description: Digital signature -- 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=60136231iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big)
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/60 = 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=60136231iu=/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)
Correcting myself: On Thu, Nov 7, 2013 at 4:00 PM, Pieter Wuille pieter.wui...@gmail.com wrote: I believe that C. Decker's paper used measurements for propagation delays for blocks 18-19, 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 2-21, 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=60136231iu=/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)
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.wui...@gmail.comwrote: Correcting myself: On Thu, Nov 7, 2013 at 4:00 PM, Pieter Wuille pieter.wui...@gmail.com wrote: I believe that C. Decker's paper used measurements for propagation delays for blocks 18-19, 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 2-21, 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=60136231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list 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=60136231iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] we can all relax now
Once the ASIC race calms down because everyone has one, has more or less optimal power supplies, process improvements aren't easily reachable anymore etc then I'd expect people to dissipate from the large pools because eliminating their fees will become the next lowest hanging fruit to squeeze out extra profit. There's no particular reason we need only a handful of pools that control a major fraction of the hashpower. If we end up with a few hundred pools or lots of miners on p2pool, then a lot of these theoretical attacks become not very relevant (I don't think ID sacrifices will be so common or large as to justify a pile of custom mining code+strategies at any point ...) On Thu, Nov 7, 2013 at 2:24 PM, Peter Todd p...@petertodd.org wrote: On Thu, Nov 07, 2013 at 02:56:56PM +1000, Gavin Andresen wrote: P.S: If any large pools want to try this stuff out, give me a shout. You have my PGP key - confidentiality assured. If I find out one of the large pools decides to run this 'experiment' on the main network, I will make it my mission to tell people to switch to a more responsible pool. I hope they listen. A few months ago ASICMiner could have made use of that attack if my memories of their peak hashing power were correct. They certainely could have used the selfish miner version, (we need better name for that) although development costs would eat into profits. GHash.IO, 22%, says they're a private Bitfury ASIC mining pool - dunno what they mean by that, but they're involved with CEX.IO who has physical control of a bunch of hashing power so I guess that means their model is like ASICMiners. They're a bit short of 30%, but maybe some behind-the-scenes deals would fix that, and/or lowering the barrier with reactive block publishing. (a better name) And if you think you can get away with driving up EVERYBODY's orphan rate without anybody noticing, you should think again. ...and remember, if you only do the attack a little bit, you still can earn more profit, and only drive up the orphan rate a little bit. So who knows, maybe the orphans are real, or maybe they're an attack? ASICMiner was involved with a bunch of orphans a while back... You know what this calls for? A witchhunt! BURN THE LARGE POOLS! P.P.S: If you're mining on a pool with more than, like, 1% hashing power, do the math on varience... Seriously, stop it and go mine on a smaller pool, or better yet, p2pool. That I agree with. Glad to hear. -- 'peter'[:-1]@petertodd.org 0007bd936f19e33bc8b8f9bb1f4c013b863ef60a7f5a6a5d2112 -- 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=60136231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list 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=60136231iu=/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)
-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.42 BTC/kB Q=0.1 - f = 0.34 BTC/kB Q=0.25 - f = 0.23 BTC/kB Q=0.40 - f = 0.15 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=60136231iu=/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- -- 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=60136231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
