Dave Hudson [ARCHIVE] on Nostr: ๐ Original date posted:2015-05-07 ๐ Original message:> On 7 May 2015, at 11:52, ...
๐
Original date posted:2015-05-07
๐ Original message:> On 7 May 2015, at 11:52, Jorge Timรณn <jtimon at jtimon.cc> wrote:
>
> On Thu, May 7, 2015 at 11:25 AM, Mike Hearn <mike at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/360dfd3b/attachment.html>
๐ Original message:> On 7 May 2015, at 11:52, Jorge Timรณn <jtimon at jtimon.cc> wrote:
>
> On Thu, May 7, 2015 at 11:25 AM, Mike Hearn <mike at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/360dfd3b/attachment.html>