From: Tom Harding <tomh@thinlink•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] No Bitcoin For You
Date: Thu, 14 May 2015 08:22:41 -0700 [thread overview]
Message-ID: <5554BDC1.6070206@thinlink.com> (raw)
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.
next reply other threads:[~2015-05-14 15:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-14 15:22 Tom Harding [this message]
2015-05-17 2:31 ` Ryan X. Charles
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=5554BDC1.6070206@thinlink.com \
--to=tomh@thinlink$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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