public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Ryan X. Charles" <ryanxcharles@gmail.com>
To: Tom Harding <tomh@thinlink.com>,
	bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] No Bitcoin For You
Date: Sat, 16 May 2015 19:31:10 -0700	[thread overview]
Message-ID: <5557FD6E.2050903@gmail.com> (raw)
In-Reply-To: <5554BDC1.6070206@thinlink.com>

I agree with this analysis. I'm not sure if we will increase 1 MB
block size or not, but with a block size that small, it is all but
impossible for most people on the planet to ever own even a single utxo.

At 7tps, how long would it take to give 1 utxo to all of the 7 billion
people currently alive? It would take 1 billion seconds, or about 32
years.[1]  So for all practical purposes, at 1 MB block size, far less
than 1% of people will ever be able to own even a single satoshi.
Unless those people are willing to wait around 30 years for their
lightning network to settle, they will either not use bitcoin, or they
will use a substitute (such as a parallel decentralized network, or a
centralized service) that lacks the full trust-minimized security
guarantees of the main bitcoin blockchain.

I can't speak for most people, but for me personally, the thing I care
most about as an individual (besides being able to send bitcoin to and
from anyone on the planet) is being able to validate the blockchain.
With a pruning node, this means I need to download the blockchain one
time (not store it), and maintain the utxo set. The utxo set is,
roughly speaking, 30 bytes per utxo, and therefore, at one utxo per
person, about 7*30 billion bytes, or 210 GB. That's very achievable on
the hardware of today. Of course, some individuals or companies will
have far more than one utxo. Estimating an average of ten utxos per
person, that will be 2.1 TB. Also very achievable on the hardware of
today.

I don't think every transaction in the world should be on the
blockchain, but I think it should be able to handle (long-term) enough
transactions that everyone can have their transactions settled on a
timescale suitable for human life. 30 years is unsuitable, but 1 day
would be pretty good. It would be great if I could send trillions of
transactions per day on networks built on top of bitcoin, and have my
transactions settle on the actual blockchain once per day. This means
we would need to support about 1 utxo per person per day, or 7 billion
transactions per day. That translates to about 81 thousand
transactions per second [2], or approximately 10,000 times the current
rate. That would be 10 GB per ten minutes, which is achievable on
current hardware (albeit not yet inexpensively).

Using SPV security rather than pruning security makes the cost even
lower. A person relying on SPV would not have to download every 10 GB
block, but only their transactions (or a small superset of them),
which is already being done - scaling to 7 billion people would not
require that SPV nodes perform any more computation than they already
do. Nonetheless, I think pruning should be considered the default
minimum, since that it what is required to get the full
trust-minimized security guarantees of the blockchain. And that
requires 10 GB blocks (or thereabouts).

The number of people on the planet will also grow, perhaps to 14
billion people in the next few decades. However, the estimates here
would still be roughly correct. 10 GB blocks, or approximately so,
allows everyone in the world to have their transactions settled on the
blockchain in a timely manner, whereas 1 MB blocks do not. And this is
already achievable on current hardware. The most significant cost is
bandwidth, but that will probably become substantially less expensive
in the coming years, making it possible for everyone to inexpensively
and securely send and receive bitcoin to anyone else, without having
to use a parallel network with reduced security or rely on trusted
third parties.

[1] 10^9 / 60 / 60 / 24 / 365 ~= 32.

[2] 7*10^9 / 24 / 60 / 60 ~= 81018

On 05/14/2015 08:22 AM, Tom Harding wrote:
> A recent post, which I cannot find after much effort, made an 
> excellent point.
> 
> If capacity grows, fewer individuals would be able to run full
> nodes. Those individuals, like many already, would have to give up
> running a full-node wallet :(
> 
> That sounds bad, until you consider that the alternative is running
> a full node on the bitcoin 'settlement network', while massive
> numbers of people *give up any hope of directly owning bitcoin at
> all*.
> 
> If today's global payments are 100Ktps, and move to the Lightning 
> Network, they will have to be consolidated by a factor of 25000:1
> to fit into bitcoin's current 4tps capacity as a settlement
> network. You executing a personal transaction on that network will
> be about as likely as you personally conducting a $100 SWIFT
> transfer to yourself today. For current holders, just selling or
> spending will get very expensive!
> 
> Forcing block capacity to stay small, so that individuals can run 
> full nodes, is precisely what will force bitcoin to become a
> backbone that is too expensive for individuals to use.  I can't
> avoid the conclusion that Bitcoin has to scale, and we might as
> well be thinking about how.
> 
> There may be a an escape window.  As current trends continue toward
> a landscape of billions of SPV wallets, it may still be possible
> for individuals collectively to make up the majority of the
> network, if more parts of the network itself rely on SPV-level
> security.
> 
> With SPV-level security, it might be possible to implement a
> scalable DHT-type network of nodes that collectively store and
> index the exhaustive and fast-growing corpus of transaction
> history, up to and including currently unconfirmed transactions.
> Each individual node could host a slice of the transaction set with
> a configurable size, let's say down to a few GB today.
> 
> Such a network would have the desirable property of being run by
> the community.  Most transactions would be submitted to it, and
> like today's network, it would disseminate blocks (which would be
> rapidly torn apart and digested).  Therefore miners and other full
> nodes would depend on it, which is rather critical as those nodes
> grow closer to data-center proportions.
> 
> 
> 
> ------------------------------------------------------------------------------
>
>
>
> 
One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications 
> Performance metrics, stats and reports that give you Actionable 
> Insights Deep dive visibility with transaction tracing using APM 
> Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y 
> _______________________________________________ Bitcoin-development
>  mailing list Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

-- 
Ryan X. Charles
Software Engineer @BitGo

twitter.com/ryanxcharles
github.com/ryanxcharles
keybase.io/ryanxcharles
onename.com/ryanxcharles



  reply	other threads:[~2015-05-17  2:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-14 15:22 [Bitcoin-development] No Bitcoin For You Tom Harding
2015-05-17  2:31 ` Ryan X. Charles [this message]
2015-05-25 18:36 ` Mike Hearn
2015-05-26  2:26   ` Jim Phillips
2015-05-26  2:30 Thy Shizzle
2015-05-26  2:41 ` gabe appleton
2015-05-26  2:53 ` Jim Phillips
2015-05-26  2:51 Thy Shizzle
2015-05-26  3:02 Thy Shizzle
2015-05-26  3:23 ` Jim Phillips
2015-05-26  3:49   ` Jim Phillips
2015-05-26  5:43     ` gabe appleton
2015-05-26  8:29       ` Jim Phillips

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=5557FD6E.2050903@gmail.com \
    --to=ryanxcharles@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=tomh@thinlink.com \
    /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