Monday, February 25, 2013

Bitcoin block size thoughts

As pasted from an IRC discussion today:
  •  (a) I once posted a patch to change max block size, so I thought about this long before forum readers ever woke up to the issue,
  • (b) I have since backed down from that radical position,
  • (c) it seems likely that max block size will change sometime in bitcoin's future,
  • (d) block size is VERY MUCH like bitcoin's 21M limit, so a lot of care must be taken when changing MAX_BLOCK_SIZE logic.  Block size is an economically limited resource whose production is tightly defined and controlled by algorithm, with an intentionally steady production rate (the 1MB limit). 
  • (d.1) Nonewithstanding the major impacts of a hard fork, in and of itself.
  • (e) I lean against solutions that are feedback-based (average of last 1000 block sizes, etc.), as they can be gamed too easily
  • (f) implementation will likely be:  if (now > chosen hard fork future date) { do it }
  • (g) my default rhetorical position will be to push back against changes, for now, since there is no demonstrated need for hard fork.
  • (g.1) Block sizes are nowhere near maximum, and
  • (g.2) Competition for space encourages efficient solutions, whereas a too-loose block size policy incentivizes the opposite: dumping into the block chain
  • (h) when I ran asic + p2pool, I set max block size at 900k and free tx at 300k.  That reflects my personal (not official dev team etc.) preferences.  I filtered out 1e8 outputs from mempool. We are nowhere near competing for block space at this point.
  • And very importantly, (i) it is a mistake to increase block size simply because people are too lazy to implement layers on top of bitcoin.  Bitcoin will forever be a zen balance of applications and layers that sit on top of the blockchain, and those that directly use the blockchain itself as their comm/functional layer (c.f. SatoshiDICE).

So I generally agree with a lot of gmaxwell's points, and it is important therefore to not arbitrarily increase blocksize, simply because that makes some apps easier -- because they free-ride on the blockchain itself. Maybe one future state of The Mainnet Blockchain is simply a high security merged mining root for several important chains, who can say?

Block size is a core economic resource, like the number of bitcoins itself. Not merely the number of transactions we can support... it influences fees and many other factors.

My off-the-cuff guess (may be wrong) for a solution was:  if (todays_date > SOME_FUTURE_DATE) { MAX_BLOCK_SIZE *= 2, every 1 years }  [Other devs comment: too fast!]  That might be too fast, but the point is, not feedback based nor directly miner controlled.


  1. Block size does not need to change right now.
  2. If and when block size changes, implement a simple rule, and let the free market figure out the rest (which might include a more complex rule years later, when the picture is more clear).
Standard disclaimer:  speaking only for myself, not any other dev or organization.

P.S. That was more than I intended to type, about block size.  It seems more like The Question Of The Moment on the web, than a real engineering need. Just The Thing people are talking about right now, and largely much ado about nothing.

Friday, February 1, 2013

Avalon miner: power usage

Power usage snapshot, raw numbers:

     66.3 Ghps / 620 Watts / 5.6 Amps

thanks to Kill-A-Watt.  See previous post for the more complete review.

Let the efficiency and electricity cost calculations begin!

cgminer status snapshot, showing hash speed, temperature, etc. at the time of the power measurements:

   [Elapsed] => 2186
   [MHS av] => 66320.47
   [Found Blocks] => 0
   [Getworks] => 73
   [Accepted] => 2060
   [miner_count] => 24
   [asic_count] => 10
   [fan1] => 0
   [fan2] => 1920
   [fan3] => 1920
   [temp1] => 27
   [temp2] => -1
   [temp3] => 48
   [temp_max] => 49