block-size tradeoffs & hypothetical alternatives (Re: Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it)

Not that I'm arguing against scaling within tech limits - I agree we can and should - but note block-size is not a free variable. The system is a balance of factors, interests and incentives.

As Greg said here https://www.reddit.com/r/Bitcoin/comments/3b0593/to_fork_or_not_to_fork/cshphic?context=3 there are multiple things we should usefully do with increased bandwidth:

a) improve decentralisation and hence security/policy neutrality/fungibility (which is quite weak right now by a number of measures) b) improve privacy (privacy features tend to consume bandwidth, eg see the Confidential Transactions feature) or more incremental features. c) increase throughput

I think some of the within tech limits bandwidth should be pre-allocated to decentralisation improvements given a) above.

And I think that we should also see work to improve decentralisation with better pooling protocols that people are working on, to remove some of the artificial centralisation in the system.

Secondly on the interests and incentives - miners also play an important part of the ecosystem and have gone through some lean times, they may not be overjoyed to hear a plan to just whack the block-size up to 8MB. While it's true (within some limits) that miners could collectively keep blocks smaller, there is the ongoing reality that someone else can take break ranks and take any fee however de minimis fee if there is a huge excess of space relative to current demand and drive fees to zero for a few years. A major thing even preserving fees is wallet defaults, which could be overridden(plus protocol velocity/fee limits).

I think solutions that see growth scale more smoothly - like Jeff Garzik's and Greg Maxwell's and Gavin Andresen's (though Gavin's starts with a step) are far less likely to create perverse unforeseen side-effects. Well we can foresee this particular effect, but the market and game theory can surprise you so I think you generally want the game-theory & market effects to operate within some more smoothly changing caps, with some user or miner mutual control of the cap.

So to be concrete here's some hypotheticals (unvalidated numbers):

a) X MB cap with miner policy limits (simple, lasts a while) b) starting at 1MB and growing to 2*X MB cap with 10%/year growth limiter + policy limits c) starting at 1MB and growing to 3*X MB cap with 15%/year growth limiter + Jeff Garzik's miner vote. d) starting at 1MB and growing to 4*X MB cap with 20%/year growth limiter + Greg Maxwell's flexcap

I think it would be good to see some tests of achievable network bandwidth on a range of networks, but as an illustration say X is 2MB.

Rationale being the weaker the signalling mechanism between users and user demanded size (in most models communicated via miners), the more risk something will go in an unforeseen direction and hence the lower the cap and more conservative the growth curve.

15% growth limiter is not Nielsen's law by intent. Akamai have data on what they serve, and it's more like 15% per annum, but very variable by country http://www.akamai.com/stateoftheinternet/soti-visualizations.html#stoi-graph CISCO expect home DSL to double in 5 years (http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/VNI_Hyperconnectivity_WP.html ), which is about the same number.

(Thanks to Rusty for data sources for 15% number).

This also supports the claim I have made a few times here, that it is not realistic to support massive growth without algorithmic improvement from Lightning like or extension-block like opt-in systems. People who are proposing that we ramp blocksizes to create big headroom are I think from what has been said over time, often without advertising it clearly, actually assuming and being ok with the idea that full nodes move into data-centers period and small business/power user validation becomes a thing of the distant past. Further the aggressive auto-growth risks seeing that trend continuing into higher tier data-centers with negative implications for decentralisation. The odd proponent seems OK with even that too.

Decentralisation is key to Bitcoin's security model, and it's differentiating properties. I think those aggressive growth numbers stray into the zone of losing efficiency. By which I mean in scalability or privacy systems if you make a trade-off too far, it becomes time to re-asses what you're doing. For example at that level of centralisation, alternative designs are more network efficient, while achieving the same effective (weak) decentralisation. In Bitcoin I see this as a strong argument not to push things to that extreme, the core functionality must remain for Lightning and other scaling approaches to remain secure by using the Bitcoin as a secure anchor. If we heavily centralise and weaken the security of the main Bitcoin chain, there remains nothing secure to build on.

Therefore I think it's more appropriate for high scale to rely on lightning, or a semi-centralised trade-offs being in the side-chain model or similar, where the higher risk of centralisation is opt-in and not exposed back (due to the security firewall) to the Bitcoin network itself.

People who would like to try the higher tier data-center and throughput by high bandwidth use route should in my opinion run that experiment as a layer 2 side-chain or analogous. There are a few ways to do that. And it would be appropriate to my mind that we discuss them here also.

An experiment like that could run in parallel with lightning, maybe it could be done faster, or offer different trade-offs, so could be an interesting and useful thing to see work on.

> On Tue, Jun 30, 2015 at 12:25 PM, Peter Todd <pete@petertodd•org> wrote:
>> Which of course raises another issue: if that was the plan, then all you
>> can do is double capacity, with no clear way to scaling beyond that.
>> Why bother?

A secondary function can be a market signalling - market evidence throughput can increase, and there is a technical process that is effectively working on it. While people may not all understand the trade-offs and decentralisation work that should happen in parallel, nor the Lightning protocol's expected properties - they can appreciate perceived progress and an evidently functioning process. Kind of a weak rationale, from a purely technical perspective, but it may some value, and is certainly less risky than a unilateral fork.

As I recall Gavin has said things about this area before also (demonstrate throughput progress to the market).

Another factor that people have said, which I think I agree with fairly much is that if we can chose something conservative, that there is wide-spread support for, it can be safer to do it with moderate lead time. Then if there is an implied 3-6mo lead time we are maybe projecting ahead a bit further on block-size utilisation. Of course the risk is we overshoot demand but there probably should be some balance between that risk and the risk of doing a more rushed change that requires system wide upgrade of all non-SPV software, where stragglers risk losing money.

As well as scaling block-size within tech limits, we should include a commitment to improve decentralisation, and I think any proposal should be reasonably well analysed in terms of bandwidth assumptions and game-theory. eg In IETF documents they have a security considerations section, and sometimes a privacy section. In BIPs maybe we need a security, privacy and decentralisation/fungibility section.

Adam

NB some new list participants may not be aware that miners are imposing local policy limits eg at 750kB and that a 250kB policy existed in the past and those limits saw utilisation and were unilaterally increased unevenly. I'm not sure if anyone has a clear picture of what limits are imposed by hash-rate even today. That's why Pieter posed the question - are we already at the policy limit - maybe the blocks we're seeing are closely tracking policy limits, if someone mapped that and asked miners by hash-rate etc.

On 30 June 2015 at 18:35, Michael Naber <mickeybob@gmail•com> wrote:

> Re: Why bother doubling capacity? So that we could have 2x more network
> participants of course.
>
> Re: No clear way to scaling beyond that: Computers are getting more capable
> aren't they? We'll increase capacity along with hardware.
>
> It's a good thing to scale the network if technology permits it. How can you
> argue with that?

On 06/30/2015 02:54 PM, Adam Back wrote:

> Decentralisation is key to Bitcoin's security model, and it's
> differentiating properties.

Continually repeating this statement without defining terms or providing evidence does not make it true or informative.

"Decentralization" is a popular buzzword these days, but how about stating the problem description in a way that is more precise and accurate?

One of Bitcoin's differentiating properties is that it prevents double spending without using a trusted third party.

Now instead of arguing about some nebulous "decentralization" that nobody can define or measure, we can talk about more helpful questions like:

Under what circumstances will miners and/or nodes behave as a trusted third party (collusion)?

What incentives exist which increase, and which reduce, any tendencies that may exist for nodes to collude?

In what ways specifically does MAX_BLOCK_SIZE relate to either of the following questions?

>"Decentralization" is a popular buzzword these days, but how about

stating the problem description in a way that is more precise and accurate? One of Bitcoin's differentiating properties is that it prevents double spending without using a trusted third party.

I have been researching how it can be defined and measured (at least up to a certain point). Here is a paper on measuring decentralization of government functions: http://www.sscnet.ucla.edu/polisci/faculty/treisman/Papers/defin.pdf. Not exactly the same thing as being discussed here but the paper gives a framework of how decentralization metrics could be defined in a somewhat standard way.

Russ

My understanding is that BIP 101 has working code to raise the block size and is ready for evaluation today.

When will Lightning and Sidechains be ready so that a fair and controlled test can be made?

On 06/30/2015 12:54 PM, Adam Back wrote:

> People who would like to try the higher tier data-center and
> throughput by high bandwidth use route should in my opinion run that
> experiment as a layer 2 side-chain or analogous.  There are a few ways
> to do that.  And it would be appropriate to my mind that we discuss
> them here also.
>
> An experiment like that could run in parallel with lightning, maybe it
> could be done faster, or offer different trade-offs, so could be an
> interesting and useful thing to see work on.
>

On 6/30/2015 12:54 PM, Adam Back wrote:

> Secondly on the interests and incentives - miners also play an
> important part of the ecosystem and have gone through some lean times,
> they may not be overjoyed to hear a plan to just whack the block-size
> up to 8MB.  While it's true (within some limits) that miners could
> collectively keep blocks smaller, there is the ongoing reality that
> someone else can take break ranks and take any fee however de minimis
> fee if there is a huge excess of space relative to current demand and
> drive fees to zero for a few years.  A major thing even preserving
> fees is wallet defaults, which could be overridden(plus protocol
> velocity/fee limits).

Let's pretend it is late 2012.

Nobody has ever violated the soft limit of 500KB/block. Block reward is about to be cut in half. Fees are right where they are today. 1 BTC = about $15.

It's a good thing nothing was done in 2012 to try to boost fees out of concern for miner profits.

Nor should we today. The 16X rise in the economic value¹ of the block reward since that time covers the entire .5X effect of the halving itself, plus three additional halvings. There is far less reason today to worry on miners' behalf about fees than there was in late 2012.

Running out of ways to grow does threaten miner profit, and therefore security, growth. So let's hope all the scaling ideas work.

> I'm not sure if anyone has a clear picture of what limits are imposed
> by hash-rate even today.

From the all-blocksizes plot, it's clear visually that the 750K soft limit, and another less common soft limit at 900K, are being imposed, but broken more and more frequently as demand outpaces them.

These soft limits serve no purpose, other than to delay transactions. A 750KB block is followed by another 750KB or larger block just as frequently as you would expect from the actual block time distribution, which recently (prior to spam now underway) had a rate of a full 1MB block being needed every 104 minutes (in an earlier post I gave a relation which is very stable, given the stable average transaction size).

___________________

¹Someday, if bitcoin is wildly successful, exchange rates vs. obsolete currencies won't be meaningful. If that happens, increases in the economic value of bitcoin will likely be measured by decreases in the general price level of all goods and services.