public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Leandro Coutinho <lescoutinhovr@gmail•com>
To: David Kaufman <david@gigawatt•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 12:58:43 -0300	[thread overview]
Message-ID: <CAN6UTaw0N8g+Kk0AYENa9WnXP7tH6H7rikkZ+9N4zesdodrJXw@mail.gmail.com> (raw)
In-Reply-To: <CA+voGJT7tfHS-6bEqjhnOTz=jVidg7AAEXSis_GvqVvBZdRy0w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3628 bytes --]

Maybe it already exists ...

#9484 <https://github.com/bitcoin/bitcoin/pull/9484> 812714f
<https://github.com/bitcoin/bitcoin/commit/812714f> Introduce assumevalid
setting to skip validation presumed valid scripts (gmaxwell)
https://github.com/bitcoin/bitcoin/pull/9484

..., but ...
It would be very interesting if a new node could decide to be a pruned node:
  - it would need to trust one or more peers for the initial blockchain
download, because the blocks downloaded would not be validated
  - it would decide a time from when to get the blocks, like a week before
  - once a day a routine would run that would prune blocks older than the
chosen time

"

*The unspent transaction outputs (which is the only essential piece ofdata
necessary for validation) are already kept in a separate database,so
technically removing old blocks is perfectly possible.*" Pieter Wuille
https://bitcoin.stackexchange.com/questions/11170/why-is-pruning-not-considered-already-at-the-moment


On Fri, Apr 21, 2017 at 10:35 AM, David Kaufman via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 4702 bytes --]

  reply	other threads:[~2017-04-21 15:58 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-17  6:54 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
2017-04-21 15:58     ` Leandro Coutinho [this message]
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=CAN6UTaw0N8g+Kk0AYENa9WnXP7tH6H7rikkZ+9N4zesdodrJXw@mail.gmail.com \
    --to=lescoutinhovr@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=david@gigawatt$(echo .)com \
    /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