📅 Original date posted:2017-04-21
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170421/a959f172/attachment.html>;
Leandro Coutinho [ARCHIVE] /
npub193…w8y7x
2023-06-07 18:00:20
in reply to nevent1q…mt7t
Author Public Key
npub193zsep73u9swc6nknsuulvf283fd4sz3kphpq8s3y5y4eeg0x8tsnw8y7xPublished at
2023-06-07 18:00:20Event JSON
{
"id": "8cab176e14c03adbffa20e7fad5e990c719eba874cdf6f22e383c177ed899416",
"pubkey": "2c450c87d1e160ec6a769c39cfb12a3c52dac051b06e101e1125095ce50f31d7",
"created_at": 1686160820,
"kind": 1,
"tags": [
[
"e",
"9e0bce6c49b056a94ef9193a53941e860a13142ae7014703964955e2e8de52b1",
"",
"root"
],
[
"e",
"ac658c3044930b3404b7feae545aa9f7a6024459fbd42c0ae485a71e841ed8e1",
"",
"reply"
],
[
"p",
"7925498f1f6291840cf185ec7b414996dda43ff23909655c8c3e4d2ca2b2fc07"
]
],
"content": "📅 Original date posted:2017-04-21\n📝 Original message:Maybe it already exists ...\n\n#9484 \u003chttps://github.com/bitcoin/bitcoin/pull/9484\u003e 812714f\n\u003chttps://github.com/bitcoin/bitcoin/commit/812714f\u003e Introduce assumevalid\nsetting to skip validation presumed valid scripts (gmaxwell)\nhttps://github.com/bitcoin/bitcoin/pull/9484\n\n..., but ...\nIt would be very interesting if a new node could decide to be a pruned node:\n - it would need to trust one or more peers for the initial blockchain\ndownload, because the blocks downloaded would not be validated\n - it would decide a time from when to get the blocks, like a week before\n - once a day a routine would run that would prune blocks older than the\nchosen time\n\n\"\n\n*The unspent transaction outputs (which is the only essential piece ofdata\nnecessary for validation) are already kept in a separate database,so\ntechnically removing old blocks is perfectly possible.*\" Pieter Wuille\nhttps://bitcoin.stackexchange.com/questions/11170/why-is-pruning-not-considered-already-at-the-moment\n\n\nOn Fri, Apr 21, 2017 at 10:35 AM, David Kaufman via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi Danny,\n\u003e\n\u003e On Mon, Apr 17, 2017 at 3:11 AM, Danny Thorpe wrote:\n\u003e \u003e\n\u003e \u003e 1TB HDD is now available for under $40 USD. How is the 100GB storage\n\u003e \u003e requirement preventing anyone from setting up full nodes?\n\u003e\n\u003e Yeah, but that's because most people (well, using myself as the\n\u003e \"target market\" anyway) are upgrading to SSD's for the faster boot and\n\u003e response times. Modern consumer OS's run incredibly slow on\n\u003e non-ssd drives! And since the vast majority of consumer laptops sold\n\u003e today fall into the $400 to $700 range, a 200 - 500gb SSD is about the\n\u003e most storage upgrade people can afford.\n\u003e\n\u003e And so I think David's premise, that having to devote only 30GB to\n\u003e running a full node instead of 100, would remove a major obstacle that\n\u003e prevents many more people running full bitcoin nodes.\n\u003e\n\u003e My only suggestion is, does it scale? I mean, if the bitcoin network\n\u003e volume grows exponentially and in 2 years the blockchain is 500GB, can\n\u003e the \"small node\" be adjusted down from one fifth of the blockchain to\n\u003e just one-tenth, or one twentieth? Can different smalInesses\n\u003e interoperate? Can I choose to store a small node with 20 - 30% of the\n\u003e blockchain, while others chose to share just 5% or 10% of it? Can I run\n\u003e \"less small\" node today that's 50GB?\n\u003e\n\u003e Can the default install be a \"small node\" that requires about 30GB of\n\u003e storage (if that is indeed the sweet spot for enticing many more users to\n\u003e bringing nodes online), but allow the user at install time, to choose *how*\n\u003e small? To, say, drag a slider anywhere up and down the range from\n\u003e 10GB to 100GB?\n\u003e\n\u003e If not, then it will have to be revisited constantly as the blockchain\n\u003e grows, and disk storage prices drop. I suspect the blockchain will\n\u003e grow in size, at some point in the not too distant future, much faster\n\u003e than storage prices drop, so making small, smaller and smallest nodes\n\u003e that can be configured to store more or less of it will be necessary\n\u003e to motivate most users to run nodes at all. But when that happens,\n\u003e there is likely to be exponentially *more* people using bitcoin, too!\n\u003e So an exponentially growing number of users running (smaller and\n\u003e smaller) nodes would take up the slack.\n\u003e\n\u003e Then, the blockchain would begin to look a lot more like a bittorrent,\n\u003e right? ;-) but -- happily -- one that you never need to download fully.\n\u003e\n\u003e -dave\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170421/a959f172/attachment.html\u003e",
"sig": "e7350461db836cb1281edb93f27ce82fa49a8fa330a68a1717cc09738c441964907bef02dd5bfc19ec09ed6d3ef524afd693fad7e8e28f0356e0665d28cc9651"
}