📅 Original date posted:2014-04-10
📝 Original message:Okay...will let myself out now ;P
On Thu, Apr 10, 2014 at 12:54 PM, Ricardo Filipe
<ricardojdfilipe at gmail.com>wrote:
> that's what blockchain pruning is all about :)
>
> 2014-04-10 17:47 GMT+01:00 Brian Hoffman <brianchoffman at gmail.com>:
> > Looks like only about ~30% disk space savings so I see your point. Is
> there
> > a critical reason why blocks couldn't be formed into "superblocks" that
> are
> > chained together and nodes could serve a specific superblock, which
> could be
> > pieced together from different nodes to get the full blockchain? This
> would
> > allow participants with limited resources to serve full portions of the
> > blockchain rather than limited pieces of the entire blockchain.
> >
> >
> > On Thu, Apr 10, 2014 at 12:28 PM, Mike Hearn <mike at plan99.net> wrote:
> >>
> >> Suggestions always welcome!
> >>
> >> The main problem with this is that the block chain is mostly random
> bytes
> >> (hashes, keys) so it doesn't compress that well. It compresses a bit,
> but
> >> not enough to change the fundamental physics.
> >>
> >> However, that does not mean the entire chain has to be stored on
> expensive
> >> rotating platters. I've suggested that in some star trek future where
> the
> >> chain really is gigantic, it could be stored on tape and spooled off at
> high
> >> speed. Literally a direct DMA from tape drive to NIC. But we're not
> there
> >> yet :)
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Put Bad Developers to Shame
> > Dominate Development with Jenkins Continuous Integration
> > Continuously Automate Build, Test & Deployment
> > Start a new project now. Try Jenkins in the cloud.
> > http://p.sf.net/sfu/13600_Cloudbees
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/10c46b57/attachment.html>;
Brian Hoffman [ARCHIVE] /
npub1nq…lnwve
2023-06-07 15:18:30
in reply to nevent1q…dmv3
Author Public Key
npub1nqeart5fmxjzj4tejkp7fckp0qa4hw3gpha6espxudum2qlvvrhqvlnwvePublished at
2023-06-07 15:18:30Event JSON
{
"id": "133f6eda5e5a591ef8f7608fa1132ca7c73766131f5896385e9b5c96bac4b93a",
"pubkey": "9833d1ae89d9a42955799583e4e2c1783b5bba280dfbacc026e379b503ec60ee",
"created_at": 1686151110,
"kind": 1,
"tags": [
[
"e",
"aae8a2dedee78eef571f285fef23331d89c84b104c87b098618414541001d13e",
"",
"root"
],
[
"e",
"63016362dc9caf01afc0cd8ca726f8820a9d26c3c5d1d8d83e9a47eb5f3b4805",
"",
"reply"
],
[
"p",
"aa5cd512f153f77aa335d71793f2cd219569188aedabd7d0239386b17f7728d8"
]
],
"content": "📅 Original date posted:2014-04-10\n📝 Original message:Okay...will let myself out now ;P\n\n\nOn Thu, Apr 10, 2014 at 12:54 PM, Ricardo Filipe\n\u003cricardojdfilipe at gmail.com\u003ewrote:\n\n\u003e that's what blockchain pruning is all about :)\n\u003e\n\u003e 2014-04-10 17:47 GMT+01:00 Brian Hoffman \u003cbrianchoffman at gmail.com\u003e:\n\u003e \u003e Looks like only about ~30% disk space savings so I see your point. Is\n\u003e there\n\u003e \u003e a critical reason why blocks couldn't be formed into \"superblocks\" that\n\u003e are\n\u003e \u003e chained together and nodes could serve a specific superblock, which\n\u003e could be\n\u003e \u003e pieced together from different nodes to get the full blockchain? This\n\u003e would\n\u003e \u003e allow participants with limited resources to serve full portions of the\n\u003e \u003e blockchain rather than limited pieces of the entire blockchain.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e On Thu, Apr 10, 2014 at 12:28 PM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e Suggestions always welcome!\n\u003e \u003e\u003e\n\u003e \u003e\u003e The main problem with this is that the block chain is mostly random\n\u003e bytes\n\u003e \u003e\u003e (hashes, keys) so it doesn't compress that well. It compresses a bit,\n\u003e but\n\u003e \u003e\u003e not enough to change the fundamental physics.\n\u003e \u003e\u003e\n\u003e \u003e\u003e However, that does not mean the entire chain has to be stored on\n\u003e expensive\n\u003e \u003e\u003e rotating platters. I've suggested that in some star trek future where\n\u003e the\n\u003e \u003e\u003e chain really is gigantic, it could be stored on tape and spooled off at\n\u003e high\n\u003e \u003e\u003e speed. Literally a direct DMA from tape drive to NIC. But we're not\n\u003e there\n\u003e \u003e\u003e yet :)\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \u003e Put Bad Developers to Shame\n\u003e \u003e Dominate Development with Jenkins Continuous Integration\n\u003e \u003e Continuously Automate Build, Test \u0026 Deployment\n\u003e \u003e Start a new project now. Try Jenkins in the cloud.\n\u003e \u003e http://p.sf.net/sfu/13600_Cloudbees\n\u003e \u003e _______________________________________________\n\u003e \u003e Bitcoin-development mailing list\n\u003e \u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/10c46b57/attachment.html\u003e",
"sig": "ece7c9ef01fd0766d20e9beeef9a82bcfd8cc0214557fad378ac2a35452e35b57e6db4e06fbd63d25183cda7e3384da0cfd1b58e4c07485af9f4d2ddd4e6bd73"
}