public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Raystonn ." <raystonn@hotmail.com>
To: "Mike Hearn" <mike@plan99.net>, "Adam Back" <adam@cypherspace.org>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] soft-fork block size increase (extensionblocks)
Date: Mon, 01 Jun 2015 19:02:44 -0000	[thread overview]
Message-ID: <COL131-DS3380A8C27DE6CBC0D98A4CDB60@phx.gbl> (raw)


[-- 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 --]

             reply	other threads:[~2015-06-01 19:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-01 19:02 Raystonn . [this message]
2015-06-17 15:28 ` [Bitcoin-development] soft-fork block size increase(extensionblocks) Raystonn .
2015-06-18  0:04   ` Tom Harding
  -- strict thread matches above, loose matches on Subject: below --
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 .

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=COL131-DS3380A8C27DE6CBC0D98A4CDB60@phx.gbl \
    --to=raystonn@hotmail.com \
    --cc=adam@cypherspace.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox