MIME-Version: 1.0
In-Reply-To: <5049F137-E123-47F6-9D24-FE51B92629FF@hashingit.com>
References: <554A91BE.6060105@bluematt.me>
	<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
	<CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
	<5049F137-E123-47F6-9D24-FE51B92629FF@hashingit.com>
Date: Thu, 7 May 2015 15:40:23 +0200
Message-ID: <CABm2gDpceBQ=SqH-axgbMgOGOf8cOe1wLyJgJY5TEFu4taiNwA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Dave Hudson <dave@hashingit.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
Precedence: list

On Thu, May 7, 2015 at 1:55 PM, Dave Hudson <dave@hashingit.com> wrote:
> 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=

Looking at this graph and in retrospective, we shouldn't have removed
the standard policy limit without observing the supposedly disastrous
effects of hitting the limit first.
Removing the standard limit would have been trivial (bdb issues aside)
at any point after seeing the effects.

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

Well, this is only for first confirmations of free transaction.
A higher fee should increase your probabilities, but if you're sending
free transactions you may not care about them taking longer to be
included.

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

Well, maybe "instant and free" it's not a honest form of bitcoin
marketing and it just has to disappear.
Maybe we just need to start being more honest about pow being good for
processing micro-transactions: it is not.
Hopefully lightning will be good for that.
Free and fast in-chain transactions is something temporary that we
know will eventually disappear.
If people think it would be a adoption disaster that it happens soon,
then they could also detail an alternative plan to roll that out
instead of letting it happen.
But if the plan is to delay it forever...then I'm absolutely against.

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

I take this as an argument for increasing fee competition and thus,
against increasing the block size.

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

No blacklisting, please, that's centralized.
In any case, a related known: bigger blocks give competitive advantage
to bigger miners.