> On 7 May 2015, at 11:52, Jorge Timón <jti...@jtimon.cc> wrote:
>
> On Thu, May 7, 2015 at 11:25 AM, Mike Hearn <m...@plan99.net> wrote:
>> I observed to Wladimir and Gavin in private that this timeline meant a
>> change to the block size was unlikely to get into 0.11, leaving only 0.12,
>> which would give everyone only a few months to upgrade in order to fork the
>> chain by the end of the winter growth season. That seemed tight.
>
> Can you please elaborate on what terrible things will happen if we
> don't increase the block size by winter this year?
> I assume that you are expecting full blocks by then, have you used any
> statistical technique to come up with that date or is it just your
> guess?
> Because I love wild guesses and mine is that full 1 MB blocks will not
> happen until June 2017.
I've been looking at this problem for quite a while (Gavin cited some of my
work a few days ago) so thought I'd chime in with a few thoughts (some of which
I've not published). I believe the major problem here is that this isn't just
an engineering decision; the reaction of the miners will actually determine the
success or failure of any course of action. In fact any decision forced upon
them may backfire if they collectively take exception to it. It's worth bearing
in mind that most of the hash rate is now under the control of relatively large
companies, many of whom have investors who are expecting to see returns; it
probably isn't sufficient to just expect them to "do the right thing".
We're seeing plenty of full 1M byte blocks already and have been for months.
Typically whenever we have one of the large inter-block gaps then these are
often followed by one (and sometimes several) completely full blocks (full by
the definition of whatever the miner wanted to use as a size limit).
The problem with this particular discussion is that there are quite a few
"knowns" but an equally large number of "unknowns". Let's look at them:
Known: There has been a steady trend towards the mean block size getting
larger. See
https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=7&show_header=true&scale=0&address=
<https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=7&show_header=true&scale=0&address=>
Known: Now the trend was definitely increasing quite quickly last year but for
the last few months has been slowing down, however we did see pretty much a 2x
increase in mean block sizes in 2014.
Known: For most of 2015 we've actually been seeing that rate slow quite
dramatically, but the total numbers of transactions are still rising so we're
seeing mean transaction sizes have been reducing, and that tallies with seeing
more transactions per block:
https://blockchain.info/charts/n-transactions-per-block?timespan=all&showDataPoints=false&daysAverageString=7&show_header=true&scale=0&address=
<https://blockchain.info/charts/n-transactions-per-block?timespan=all&showDataPoints=false&daysAverageString=7&show_header=true&scale=0&address=>
Unknown: Why are seeing more smaller transactions? Are we simply seeing more
efficient use of blockchain resources or have some large consumers of block
space going away? How much more block space compression might be possible in,
say, the next 12 months?
Known: If we reach the point where all blocks are 1M bytes then there's a major
problem in terms of transaction confirmation. I published an analysis of the
impact of different mean block sizes against confirmation times:
http://hashingit.com/analysis/34-bitcoin-traffic-bulletin
<http://hashingit.com/analysis/34-bitcoin-traffic-bulletin>. The current 35% to
45% mean block size doesn't have a huge impact on transaction confirmations
(assuming equal fees for all) but once we're up at 80% then things start to get
unpleasant. Instead of 50% of first confirmations taking about 7 minutes they
instead take nearer to 19 minutes.
Known: There are currently a reasonably large number of zero-fee transactions
getting relayed and mined. If things start to slow down then there will be a
huge incentive to delay them (or drop them altogether).
Unknown: If block space starts to get more scarce then how will this affect the
use of the blockchain? Do the zero-fee TXs move to some batched transfer
solution via third party? Do people start to get smarter about how TXs are
encoded? Do some TXs go away completely (there are a lot of long-chain
transactions that may simply be "noise" creating an artificially inflated view
of transaction volumes)?
Known: There's a major problem looming for miners at the next block reward
halving. Many are already in a bad place and without meaningful fees then sans
a 2x increase in the USD:BTC ratio then many will simply have to leave the
network, increasing centralisation risks. There seems to be a fairly pervasive
assumption that the 300-ish MW of power that they currently use is going to pay
for itself (ignoring capital and other operating costs).
Unknown: If the block size is increased and yet more negligible fee
transactions are dumped onto the network then that might well motivate some
large fraction of miners to start to clamp block sizes or reject transactions
below a certain fee threshold; they can easily create their own artificial
scarcity if enough of them feel it is in their interest (it's not the most
tricky setting to change). One can well imagine VC investors in mining groups
asking why they're essentially subsidising all of the other VC-funded Bitcoin
startups.
Known: the orphan rate is still pretty-high even with everyone's fast
connections. If we assume that 20M byte blocks become possible then that's
likely to increase.
Unknown: What are the security implications for larger blocks (this one (at
least) can be simulated though)? For example, could large blocks with huge
numbers of trivial transactions be used to put other validators at a
disadvantage in a variant of a selfish mining attack? I've seen objections that
such bad actors could be blacklisted in the future but it's not clear to me
how. A private mining pool can trivially be made to appear like 100 pools of 1%
of the size without significantly affecting the economics of running that
private mine.
Cheers,
Dave
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
