From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DF420B63 for ; Fri, 21 Apr 2017 15:58:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com [209.85.220.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3D2DAFF for ; Fri, 21 Apr 2017 15:58:45 +0000 (UTC) Received: by mail-qk0-f177.google.com with SMTP id y63so45102988qkd.1 for ; Fri, 21 Apr 2017 08:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2NBPHM3s/lbDNvEGz6bBc9waKltON/7gsIG+jwRnWvM=; b=smmxyC/KekrRcI0YGLJ+LtS4Viprai6oreKacWFhGX12EWjCNHprE0xCs+8usJzq5L fBDy+Riljj1FRFxahjrkyZerpaD8sQiRVt/rHXfEG54BH4KyBermOmhAVit9tZDXhJhZ wxBmpD8Xqg/o/cIrjC7wJFCkvN235zTdkjhDWqvRjhh1cNkkDHqvMrSvCeFsjXduqwPK TkElEFigDMoh8j1jQTW41TP+JHrNGG5JnuZvVHZWqt5XihdgSJgCGS2qf7DQxeZxs2n7 8HjftPU50YkdJ7KpJ4vr3/KJVs26A3ixZjsIQGxwGxWAb1H2gv6VdB84RUP30Kw8h67V iLuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2NBPHM3s/lbDNvEGz6bBc9waKltON/7gsIG+jwRnWvM=; b=cc0nVid0lm9XxWGjDI/84ea52z1cO5mQVZE0SRbVD6WtE4BG1G2BPZMTyO33TsMEgE rNU7shC8/asFQKuM4FRhYkfi+TTB6dqguH9ThVWaR28w2XP+heb2xJMu5hfy6frvh768 81SJ7YF2txJz0P1CsI+XvCjD8Vkd/ayvWAZ0Us7MGPvXS8kh/61Qm07LWehq4B8otzok z7bPffqWi01RxgznRN/Xd2ohqrVpD2ENnuyZVMzRDRAtO0a/HGMBy8cO7n3SIgRKa0E5 ps+Y5dk2O+RKmAq0IfOc565FY8SArgR7VisNmGqlAwvokF9PnaokiNXjpKuZzGvvrxrU 34NA== X-Gm-Message-State: AN3rC/4LEzKr7azzQ56wXxuwvce+GfCKDRCEKnTo9+apQsCDYkQymR8f MGP31LoiNy0UjZHM0/vqiDajiL1U9w== X-Received: by 10.55.170.209 with SMTP id t200mr14749260qke.176.1492790324394; Fri, 21 Apr 2017 08:58:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.38.9 with HTTP; Fri, 21 Apr 2017 08:58:43 -0700 (PDT) In-Reply-To: References: From: Leandro Coutinho Date: Fri, 21 Apr 2017 12:58:43 -0300 Message-ID: To: David Kaufman Content-Type: multipart/alternative; boundary=94eb2c06e8ae02deef054daf5575 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 21 Apr 2017 16:02:01 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 15:58:47 -0000 --94eb2c06e8ae02deef054daf5575 Content-Type: text/plain; charset=UTF-8 Maybe it already exists ... #9484 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 > --94eb2c06e8ae02deef054daf5575 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Maybe it already exists ...

#9484 812714f Introduce assumevalid setting to skip validation presum= ed valid scripts (gmaxwell)
https://github.com/bitcoin/bitcoin/pull/9484

..., b= ut ...
It would be very interesting if a new node could decide to be a p= runed node:
=C2=A0 - it would need to trust one or more peers for the in= itial blockchain download, because the blocks downloaded would not be valid= ated
=C2=A0 - it would decide a time from when to get the blocks,= like a week before
=C2=A0 - once a day a routine would run that = would prune blocks older than the chosen time

"The unspent t= ransaction outputs=20 (which is the only essential piece of
data 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-pru= ning-not-considered-already-at-the-moment


On Fri, Apr 21, 2017 at 10:= 35 AM, David Kaufman via bitcoin-dev <bitcoin-dev@list= s.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.=C2=A0 How is the 100GB sto= rage
> 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.=C2=A0 Modern consumer OS's run incredibly slow on
non-ssd drives!=C2=A0 And since the vast majority of consumer laptops sold<= br> 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?=C2=A0 I mean, if the bitcoin network<= br> volume grows exponentially and in 2 years the blockchain is 500GB, can
the "small node" be adjusted down from one fifth of the blockchai= n to
just one-tenth, or one twentieth?=C2=A0 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 30G= B 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.=C2=A0 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.=C2=A0 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

--94eb2c06e8ae02deef054daf5575--