📅 Original date posted:2014-04-10
📝 Original message:Ok I think I've got a good understanding of where we're at now. I can
promise that the next person to waste your time in 30 days will not be me.
I'm pleasantly surprised to see a community that doesn't kickban newcomers
and takes the time to explain (re-explain) concepts.
Hoping to add *beneficial* thoughts in the future!
On Thu, Apr 10, 2014 at 12:59 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
> On Thu, Apr 10, 2014 at 6:47 PM, Brian Hoffman <brianchoffman at gmail.com>
> wrote:
> > 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.
>
> As this is a suggestion that I think I've seen come up once a month
> for the past 3 years, let's try to answer it thoroughly.
>
> The actual "state" of the blockchain is the UTXO set (stored in
> chainstate/ by the reference client). It's the set of all unspent
> transaction outputs at the currently active point in the block chain.
> It is all you need for validating future blocks.
>
> The problem is, you can't just give someone the UTXO set and expect
> them to trust it, as there is no way to prove that it was the result
> of processing the actual blocks.
>
> As Bitcoin's full node uses a "zero trust" model, where (apart from
> one detail: the order of otherwise valid transactions) it never
> assumes any data received from the outside it valid, it HAS to see the
> previous blocks in order to establish the validity of the current UTXO
> set. This is what initial block syncing does. Nothing but the actual
> blocks can provide this data, and it is why the actual blocks need to
> be available. It does not require everyone to have all blocks, though
> - they just need to have seen them during processing.
>
> A related, but not identical evolution is merkle UTXO commitments.
> This means that we shape the UTXO set as a merkle tree, compute its
> root after every block, and require that the block commits to this
> root hash (by putting it in the coinbase, for example). This means a
> full node can copy the chain state from someone else, and check that
> its hash matches what the block chain commits to. It's important to
> note that this is a strict reduction in security: we're now trusting
> that the longest chain (with most proof of work) commits to a valid
> UTXO set (at some point in the past).
>
> In essence, combining both ideas means you get "superblocks" (the UTXO
> set is essentially the summary of the result of all past blocks), in a
> way that is less-than-currently-but-perhaps-still-acceptably-validated.
>
> --
> Pieter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/b0cab188/attachment.html>;
Brian Hoffman [ARCHIVE] /
npub1nq…lnwve
2023-06-07 15:18:31
in reply to nevent1q…g7y4
Author Public Key
npub1nqeart5fmxjzj4tejkp7fckp0qa4hw3gpha6espxudum2qlvvrhqvlnwvePublished at
2023-06-07 15:18:31Event JSON
{
"id": "db462a1b10ea6604f9b7d9ac85c7c0b5e81ebed9d12c64f3632de169a2442fa7",
"pubkey": "9833d1ae89d9a42955799583e4e2c1783b5bba280dfbacc026e379b503ec60ee",
"created_at": 1686151111,
"kind": 1,
"tags": [
[
"e",
"aae8a2dedee78eef571f285fef23331d89c84b104c87b098618414541001d13e",
"",
"root"
],
[
"e",
"50a7da11791de8cec7190076c2977b913d334cd111d6d3d02fe9b99e28a1deb1",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2014-04-10\n📝 Original message:Ok I think I've got a good understanding of where we're at now. I can\npromise that the next person to waste your time in 30 days will not be me.\nI'm pleasantly surprised to see a community that doesn't kickban newcomers\nand takes the time to explain (re-explain) concepts.\n\nHoping to add *beneficial* thoughts in the future!\n\n\nOn Thu, Apr 10, 2014 at 12:59 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003ewrote:\n\n\u003e On Thu, Apr 10, 2014 at 6:47 PM, Brian Hoffman \u003cbrianchoffman at gmail.com\u003e\n\u003e wrote:\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\n\u003e As this is a suggestion that I think I've seen come up once a month\n\u003e for the past 3 years, let's try to answer it thoroughly.\n\u003e\n\u003e The actual \"state\" of the blockchain is the UTXO set (stored in\n\u003e chainstate/ by the reference client). It's the set of all unspent\n\u003e transaction outputs at the currently active point in the block chain.\n\u003e It is all you need for validating future blocks.\n\u003e\n\u003e The problem is, you can't just give someone the UTXO set and expect\n\u003e them to trust it, as there is no way to prove that it was the result\n\u003e of processing the actual blocks.\n\u003e\n\u003e As Bitcoin's full node uses a \"zero trust\" model, where (apart from\n\u003e one detail: the order of otherwise valid transactions) it never\n\u003e assumes any data received from the outside it valid, it HAS to see the\n\u003e previous blocks in order to establish the validity of the current UTXO\n\u003e set. This is what initial block syncing does. Nothing but the actual\n\u003e blocks can provide this data, and it is why the actual blocks need to\n\u003e be available. It does not require everyone to have all blocks, though\n\u003e - they just need to have seen them during processing.\n\u003e\n\u003e A related, but not identical evolution is merkle UTXO commitments.\n\u003e This means that we shape the UTXO set as a merkle tree, compute its\n\u003e root after every block, and require that the block commits to this\n\u003e root hash (by putting it in the coinbase, for example). This means a\n\u003e full node can copy the chain state from someone else, and check that\n\u003e its hash matches what the block chain commits to. It's important to\n\u003e note that this is a strict reduction in security: we're now trusting\n\u003e that the longest chain (with most proof of work) commits to a valid\n\u003e UTXO set (at some point in the past).\n\u003e\n\u003e In essence, combining both ideas means you get \"superblocks\" (the UTXO\n\u003e set is essentially the summary of the result of all past blocks), in a\n\u003e way that is less-than-currently-but-perhaps-still-acceptably-validated.\n\u003e\n\u003e --\n\u003e Pieter\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/b0cab188/attachment.html\u003e",
"sig": "d4d45804819fa8e78101ea576c9bd715cf54a2ad90863a1c34646b98dd2f4efe3232a07ad9428a859f95c16c10b0ced2a355a78d71d47827df40b93bfdda7bf5"
}