public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: David Kaufman <david@gigawatt.com>
To: Danny Thorpe <danny.thorpe@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes
Date: Fri, 21 Apr 2017 09:35:51 -0400	[thread overview]
Message-ID: <CA+voGJT7tfHS-6bEqjhnOTz=jVidg7AAEXSis_GvqVvBZdRy0w@mail.gmail.com> (raw)
In-Reply-To: <CAJN5wHW=p+q+DT9R=uheLxOjKBX=xcB+fOZR2KACgJO9SdXypw@mail.gmail.com>

Hi Danny,

On Mon, Apr 17, 2017 at 3:11 AM, Danny Thorpe wrote:
>
> 1TB HDD is now available for under $40 USD.  How is the 100GB storage
> requirement preventing anyone from setting up full nodes?

Yeah, but that's because most people (well, using myself as the
"target market" anyway) are upgrading to SSD's for the faster boot and
response times.  Modern consumer OS's run incredibly slow on
non-ssd drives!  And since the vast majority of consumer laptops sold
today fall into the $400 to $700 range, a 200 - 500gb SSD is about the
most storage upgrade people can afford.

And so I think David's premise, that having to devote only 30GB to
running a full node instead of 100, would remove a major obstacle that
prevents many more people running full bitcoin nodes.

My only suggestion is, does it scale?  I mean, if the bitcoin network
volume grows exponentially and in 2 years the blockchain is 500GB, can
the "small node" be adjusted down from one fifth of the blockchain to
just one-tenth, or one twentieth?  Can different smalInesses
interoperate? Can I choose to store a small node with 20 - 30% of the
blockchain, while others chose to share just 5% or 10% of it? Can I run
"less small" node today that's 50GB?

Can the default install be a "small node" that requires about 30GB of
storage (if that is indeed the sweet spot for enticing many more users to
bringing nodes online), but allow the user at install time, to choose *how*
small? To, say, drag a slider anywhere up and down the range from
10GB to 100GB?

If not, then it will have to be revisited constantly as the blockchain
grows, and disk storage prices drop.  I suspect the blockchain will
grow in size, at some point in the not too distant future, much faster
than storage prices drop, so making small, smaller and smallest nodes
that can be configured to store more or less of it will be necessary
to motivate most users to run nodes at all.  But when that happens,
there is likely to be exponentially *more* people using bitcoin, too!
So an exponentially growing number of users running (smaller and
smaller) nodes would take up the slack.

Then, the blockchain would begin to look a lot more like a bittorrent,
right? ;-) but -- happily -- one that you never need to download fully.

-dave


  parent reply	other threads:[~2017-04-21 13:36 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-17  6:54 [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes David Vorick
2017-04-17  7:11 ` Danny Thorpe
2017-04-17  7:27   ` David Vorick
2017-04-20 15:50   ` Erik Aronesty
2017-04-20 23:42     ` Aymeric Vitte
2017-04-21 13:35   ` David Kaufman [this message]
2017-04-21 15:58     ` Leandro Coutinho
2017-04-17 10:14 ` Aymeric Vitte
2017-04-19 17:30   ` David Vorick
2017-04-20  9:46     ` Tom Zander
2017-04-20 20:32       ` Andrew Poelstra
2017-04-21  8:27         ` Tom Zander
2017-04-20 11:27     ` Aymeric Vitte
2017-04-18  7:43 ` Jonas Schnelli
2017-04-18 10:50 ` Tom Zander
2017-04-18 13:07   ` Tier Nolan
2017-04-18 23:19     ` Aymeric Vitte
2017-04-19  4:28       ` udevNull
2017-04-19 13:47         ` Angel Leon
2017-04-21 20:38 ` Gregory Maxwell
2017-04-23 16:27   ` Aymeric Vitte
2017-05-03 14:03   ` Erik Aronesty
2017-05-03 19:10     ` Natanael
2017-05-03 22:45       ` Aymeric Vitte

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='CA+voGJT7tfHS-6bEqjhnOTz=jVidg7AAEXSis_GvqVvBZdRy0w@mail.gmail.com' \
    --to=david@gigawatt.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=danny.thorpe@gmail.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