public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [Bitcoin-development] soft-fork block size increase (extension blocks)
@ 2015-06-01 15:40 Adam Back
  2015-06-01 16:12 ` Mike Hearn
  0 siblings, 1 reply; 10+ messages in thread
From: Adam Back @ 2015-06-01 15:40 UTC (permalink / raw)
  To: Gavin Andresen; +Cc: Bitcoin Dev

Hi Gavin

Sorry for slow response & broken threading - mailbox filled up & only
saw your response on archive.

I do earnestly think opt-in block-size increases are politically
cleaner (gives different people different sized blocks by their own
volition without forcing a compromise) and less risky than hard forks.
Particularly if a hard-fork were really provoked without clear and
wide consensus - dragons lay there.

> Then ask the various wallet developer how long it would take them to update
> their software to support something like this,

I don't think thats any particular concern, extension block payments
are forwards and backwards compatible.  Businesses who are keen to
have more transactions, would make it their problem to implement in
their wallet, or ask the wallet vendor/maintainer they're working with
to do it.  Nothing breaks if they dont use it.  The people that have
the need for it will work on it.  Market at work.  If it turns out
they dont really have a need for it, just projected huge numbers for
their business plan that say dont materialise, well no foul.

> and do some UI mockups of what the experience would look like for users.

I am not a UX guy, but for example it might be appropriate for tipping
services or other micropayments to use an extension block.  Or small
retail payments.  They can choose what address they use.  Merchants,
integrators etc can do likewise.
It gives plenty enough scope that people can work with useful
trade-offs while others work on lightning.

> If there are two engineering solutions to a problem, one really simple, and
> one complex, why would you pick the complex one?

Because the more complex one is safer, more flexible, more future
proof and better for decentralisation (and so as a bonus and might
actually get done without more months of argument as its less
contentious because it gives users choice to opt-in).  Bitcoin itself
is complex, a central ledger is simpler but as we know uninteresting
which is to say this is a security tradeoff.

Obviously I do appreciate KISS as a design principle, and utility of
incremental improvements, but this is a security trade-off we're
discussing here.  I am proposing a way to not weaken security, while
getting what you think is important - access to more TPS with a higher
centralisation tradeoff (for those who opt-in to it, rather than for
everyone whether that tradeoff is strongly against their interests or
not).

The decentralisation metrics are getting worse, not better, see Greg
Maxwell's comments
http://www.reddit.com/r/Bitcoin/comments/37vg8y/is_the_blockstream_company_the_reason_why_4_core/crqg381

This would not by those metrics be a good moment in history to make
the situation worse.

> Especially if the complex solution has all of the problems of the simple
> one (20MB extension blocks are just as "dangerous" as 20MB main blocks,
> yes? If not, why not?)

Not at all, thats the point.  Bitcoin has a one-size fits all
blocksize.  People can pool mine the 8MB extension block, while solo
or GBT mining the 1MB block.  Thats more centralising than staying at
1MB (because to get the fees from the extension block some people
without that kind of bandwidth are pool mining 8/9th of the lower
security/decentralisation transactions.  But its less centralising
than a fixed blocksize of 9MB (1+8 for apples/apples) because
realistically if those transactions are not spam, they would've
happened offchain, and offchain until we get lightning like systems
up, means central systems which are worse than the slight
centralisation of 8MB blocks being single servers and prone to custody
& security failure.  I think you made that point yourself in a recent
post also.

Sound good? ;)  Seriously I think its the least bad idea I've heard on
this topic.

As an aside, a risk with using companies as a sounding board, is that
you can get a misleading sense of consensus.  Did they understand the
tradeoff between security (decentralisation) and blocksize.  Did they
care?  Do they represent users interests?  Would they have "voted"
instead for extension blocks if it was presented in similar terms?  (I
have to imagine they might have preferred extension blocks given the
better story if you gloss over complexity and tradeoffs).

Adam



^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] soft-fork block size increase (extensionblocks)
@ 2015-06-01 19:02 Raystonn .
  2015-06-17 15:28 ` [Bitcoin-development] soft-fork block size increase(extensionblocks) Raystonn .
  0 siblings, 1 reply; 10+ messages in thread
From: Raystonn . @ 2015-06-01 19:02 UTC (permalink / raw)
  To: Mike Hearn, Adam Back; +Cc: Bitcoin Dev


[-- Attachment #1.1: Type: text/plain, Size: 3781 bytes --]

I also need to argue for increasing the default block limit to the full 1MB in the next release.  We’re already hitting that limit in bursts of transactions, which puts pressure on the average displayed in the below graphs.

From: raystonn@hotmail.com 
Sent: Monday, June 01, 2015 11:39 AM
To: Mike Hearn ; Adam Back 
Cc: Bitcoin Dev 
Subject: Re: [Bitcoin-development] soft-fork block size increase (extensionblocks)

> And we're not going to get to VISA scale any time soon

No, not at these block size limits.  The closer we get to the maximum block size, the slower we grow the average block size toward it.  Number of transactions per day is of course highly correlated with average block size.  Based on these graphs we can expect that hitting 1 million transactions per day will be impossible without raising the maximum block size.


https://blockchain.info/charts/avg-block-size?showDataPoints=false&show_header=true&daysAverageString=7&timespan=all&scale=1&address=



https://blockchain.info/charts/n-transactions?showDataPoints=false&timespan=all&show_header=true&daysAverageString=7&scale=1&address= 



From: Mike Hearn 
Sent: Monday, June 01, 2015 11:01 AM
To: Adam Back 
Cc: Bitcoin Dev 
Subject: Re: [Bitcoin-development] soft-fork block size increase (extensionblocks)

  (at reduced security if it has software that doesnt understand it) 

Well, yes. Isn't that rather key to the issue?  Whereas by simply increasing the block size, SPV wallets don't care (same security and protocol as before) and fully validating wallets can be updated with a very small code change.

  A 1MB client wont even understand the difference between a 1MB and 8MB
  out payment. 

Let's say an old client makes a payment that only gets confirmed in an extension block. The wallet will think the payment is unconfirmed and show that to the user forever, no?

Can you walk through the UX for each case?

  If I am not misremembering, I think you've sided typically
  with the huge block, big data center only end of the spectrum.  

It would be Satoshi, that argued that.

I think there must be a communication issue here somewhere. I'm not sure how this meme has taken hold amongst you guys, as I am the guy who wrote the scalability page back in 2011:

https://en.bitcoin.it/wiki/Scalability


It says:

  The core Bitcoin network can scale to much higher transaction rates than are seen today, assuming that nodes in the network are primarily running on high end servers rather than desktops. 


By "much higher rates" I meant VISA scale and by "high end server" I meant high end by today's standards not tomorrows. There's a big difference between a datacenter and a single server! By definition a single server is not a datacenter, although it would be conventional to place it in one. But even with the most wildly optimistic growth imaginable, I couldn't foresee a time when you needed more than a single machine to keep up with the transaction stream. 


And we're not going to get to VISA scale any time soon: I don't think I've ever argued we will. If it does happen it would presumably be decades away. Again, short of some currently unimagined killer app.


So I don't believe I've ever argued this, and honestly I kinda feel people are putting words in my mouth.


--------------------------------------------------------------------------------
------------------------------------------------------------------------------



--------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[-- Attachment #1.2: Type: text/html, Size: 9530 bytes --]

[-- Attachment #2: image[2].png --]
[-- Type: image/png, Size: 53618 bytes --]

[-- Attachment #3: image[12].png --]
[-- Type: image/png, Size: 50593 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2015-06-18  0:04 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-01 15:40 [Bitcoin-development] soft-fork block size increase (extension blocks) Adam Back
2015-06-01 16:12 ` Mike Hearn
2015-06-01 17:21   ` Adam Back
2015-06-01 18:01     ` Mike Hearn
2015-06-01 18:39       ` [Bitcoin-development] soft-fork block size increase (extensionblocks) Raystonn .
2015-06-02  0:42     ` [Bitcoin-development] soft-fork block size increase (extension blocks) Tom Harding
2015-06-17 16:17       ` Richard Moore
2015-06-01 19:02 [Bitcoin-development] soft-fork block size increase (extensionblocks) Raystonn .
2015-06-17 15:28 ` [Bitcoin-development] soft-fork block size increase(extensionblocks) Raystonn .
2015-06-18  0:04   ` Tom Harding

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox