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