* [bitcoin-dev] 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)
@ 2015-06-30 19:54 Adam Back
2015-06-30 20:08 ` Justus Ranvier
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Adam Back @ 2015-06-30 19:54 UTC (permalink / raw)
To: Michael Naber; +Cc: bitcoin-dev
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?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] 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)
2015-06-30 19:54 [bitcoin-dev] 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) Adam Back
@ 2015-06-30 20:08 ` Justus Ranvier
2015-06-30 20:29 ` Milly Bitcoin
2015-06-30 22:55 ` Simon Liu
2015-06-30 22:56 ` Tom Harding
2 siblings, 1 reply; 5+ messages in thread
From: Justus Ranvier @ 2015-06-30 20:08 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1.1: Type: text/plain, Size: 986 bytes --]
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?
[-- Attachment #1.2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 18667 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] 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)
2015-06-30 20:08 ` Justus Ranvier
@ 2015-06-30 20:29 ` Milly Bitcoin
0 siblings, 0 replies; 5+ messages in thread
From: Milly Bitcoin @ 2015-06-30 20:29 UTC (permalink / raw)
To: bitcoin-dev
>"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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] 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)
2015-06-30 19:54 [bitcoin-dev] 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) Adam Back
2015-06-30 20:08 ` Justus Ranvier
@ 2015-06-30 22:55 ` Simon Liu
2015-06-30 22:56 ` Tom Harding
2 siblings, 0 replies; 5+ messages in thread
From: Simon Liu @ 2015-06-30 22:55 UTC (permalink / raw)
To: Adam Back, Michael Naber; +Cc: bitcoin-dev
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.
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] 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)
2015-06-30 19:54 [bitcoin-dev] 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) Adam Back
2015-06-30 20:08 ` Justus Ranvier
2015-06-30 22:55 ` Simon Liu
@ 2015-06-30 22:56 ` Tom Harding
2 siblings, 0 replies; 5+ messages in thread
From: Tom Harding @ 2015-06-30 22:56 UTC (permalink / raw)
To: Adam Back; +Cc: bitcoin-dev
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-06-30 22:56 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-30 19:54 [bitcoin-dev] 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) Adam Back
2015-06-30 20:08 ` Justus Ranvier
2015-06-30 20:29 ` Milly Bitcoin
2015-06-30 22:55 ` Simon Liu
2015-06-30 22:56 ` Tom Harding
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox