đź“… Original date posted:2017-03-29
📝 Original message:I believe nearly everyone at Bitcoin Unlimited would be supportive of a UTXO check-pointing scheme. I’d love to see this happen, as it would greatly reduce the time needed to get a new node up-and-running, for node operators who are comfortable trusting these commitments.
I’m confident that we could work with the miners who we have good relationships with to start including the root hash of the (lagging) UTXO set in their coinbase transactions, in order to begin transforming this idea into reality. We could also issue regular transactions from “semi-trusted” addresses controlled by known people that include the same root hash in an OP_RETURN output, which would allow cross-checking against the miners’ UTXO commitments, as part of this initial “prototype” system.
This would "get the ball rolling" on UTXO commitments in a permissionless way (no one can stop us from doing this). If the results from this prototype commitment scheme were positive, then perhaps there would be support from the community and miners to enforce a new rule which requires the (lagging) root hashes be included in new blocks. At that point, the UTXO commitment scheme is no longer a prototype but a trusted feature of the Bitcoin network.
On that topic, are there any existing proposals detailing a canonical ordering of the UTXO set and a scheme to calculate the root hash?
Best regards,
Peter
> On Mar 29, 2017, at 12:33 PM, Daniele Pinna via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> What about periodically committing the entire UTXO set to a special checkpoint block which becomes the new de facto Genesis block?
>
> Daniele
>
> ------------------------------
>
> Message: 5
> Date: Wed, 29 Mar 2017 16:41:29 +0000
> From: Andrew Johnson <andrew.johnson83 at gmail.com <mailto:andrew.johnson83 at gmail.com>>
> To: David Vorick <david.vorick at gmail.com <mailto:david.vorick at gmail.com>>
> Cc: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>
> Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
> Message-ID:
> <CAAy62_+JtoAuM-RsrAAp5eiGiO+OHLDjzqgbnF2De7TUU7TyYg at mail.gmail.com <mailto:CAAy62_%2BJtoAuM-RsrAAp5eiGiO%2BOHLDjzqgbnF2De7TUU7TyYg at mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> I believe that as we continue to add users to the system by scaling
> capacity that we will see more new nodes appear, but I'm at a bit of a loss
> as to how to empirically prove it.
>
> I do see your point on increasing load on archival nodes, but the majority
> of that load is going to come from new nodes coming online, they're the
> only ones going after very old blocks. I could see that as a potential
> attack vector, overwhelm the archival nodes by spinning up new nodes
> constantly, therefore making it difficult for a "real" new node to get up
> to speed in a reasonable amount of time.
>
> Perhaps the answer there would be a way to pay an archival node a small
> amount of bitcoin in order to retrieve blocks older than a certain cutoff?
> Include an IP address for the node asking for the data as metadata in the
> transaction... Archival nodes could set and publish their own policy, let
> the market decide what those older blocks are worth. Would also help to
> incentivize running archival node, which we do need. Of course, this isn't
> very user friendly.
>
> We can take this to bitcoin-discuss, if we're getting too far off topic.
>
>
> On Wed, Mar 29, 2017 at 11:25 AM David Vorick <david.vorick at gmail.com <mailto:david.vorick at gmail.com>>
> wrote:
>
> >
> > On Mar 29, 2017 12:20 PM, "Andrew Johnson" <andrew.johnson83 at gmail.com <mailto:andrew.johnson83 at gmail.com>>
> > wrote:
> >
> > What's stopping these users from running a pruned node? Not every node
> > needs to store a complete copy of the blockchain.
> >
> >
> > Pruned nodes are not the default configuration, if it was the default
> > configuration then I think you would see far more users running a pruned
> > node.
> >
> > But that would also substantially increase the burden on archive nodes.
> >
> >
> > Further discussion about disk space requirements should be taken to
> > another thread.
> >
> >
> > --
> Andrew Johnson
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/9b48ebe3/attachment.html <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/9b48ebe3/attachment.html>>;
>
> ------------------------------
> _______________________________________________
> 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/20170329/ca39b10a/attachment.html>;
Peter R [ARCHIVE] /
npub1vx…lz2gn
2023-06-07 17:58:19
in reply to nevent1q…f8cm
Author Public Key
npub1vxzlqg5f7ykqr3hheqxdcqe35q02a8rr2mez30sjaldhlvu4hsvsqlz2gnPublished at
2023-06-07 17:58:19Event JSON
{
"id": "df1a2b3388f4008be9df30db7ce9c501196d8245d33d1d819ebbdf3cfb6c2dae",
"pubkey": "6185f02289f12c01c6f7c80cdc0331a01eae9c6356f228be12efdb7fb395bc19",
"created_at": 1686160699,
"kind": 1,
"tags": [
[
"e",
"f66fb8ea0b053d3b896ce377aea38775ffc7975376c3ee96291861cf920b456b",
"",
"root"
],
[
"e",
"787bf1d90f6afab410fdb4c11996a60f5979ae4b5064f4cd002874d937d5ec70",
"",
"reply"
],
[
"p",
"d095b8308db6dba342441a113eb30e1fc39625c0f54d4eb0c3b214d083d846a5"
]
],
"content": "📅 Original date posted:2017-03-29\n📝 Original message:I believe nearly everyone at Bitcoin Unlimited would be supportive of a UTXO check-pointing scheme. I’d love to see this happen, as it would greatly reduce the time needed to get a new node up-and-running, for node operators who are comfortable trusting these commitments. \n\nI’m confident that we could work with the miners who we have good relationships with to start including the root hash of the (lagging) UTXO set in their coinbase transactions, in order to begin transforming this idea into reality. We could also issue regular transactions from “semi-trusted” addresses controlled by known people that include the same root hash in an OP_RETURN output, which would allow cross-checking against the miners’ UTXO commitments, as part of this initial “prototype” system.\n\nThis would \"get the ball rolling\" on UTXO commitments in a permissionless way (no one can stop us from doing this). If the results from this prototype commitment scheme were positive, then perhaps there would be support from the community and miners to enforce a new rule which requires the (lagging) root hashes be included in new blocks. At that point, the UTXO commitment scheme is no longer a prototype but a trusted feature of the Bitcoin network. \n\nOn that topic, are there any existing proposals detailing a canonical ordering of the UTXO set and a scheme to calculate the root hash?\n\nBest regards,\nPeter\n\n\n\u003e On Mar 29, 2017, at 12:33 PM, Daniele Pinna via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e What about periodically committing the entire UTXO set to a special checkpoint block which becomes the new de facto Genesis block? \n\u003e \n\u003e Daniele \n\u003e \n\u003e ------------------------------\n\u003e \n\u003e Message: 5\n\u003e Date: Wed, 29 Mar 2017 16:41:29 +0000\n\u003e From: Andrew Johnson \u003candrew.johnson83 at gmail.com \u003cmailto:andrew.johnson83 at gmail.com\u003e\u003e\n\u003e To: David Vorick \u003cdavid.vorick at gmail.com \u003cmailto:david.vorick at gmail.com\u003e\u003e\n\u003e Cc: Bitcoin Dev \u003cbitcoin-dev at lists.linuxfoundation.org \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e\n\u003e Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting\n\u003e Message-ID:\n\u003e \u003cCAAy62_+JtoAuM-RsrAAp5eiGiO+OHLDjzqgbnF2De7TUU7TyYg at mail.gmail.com \u003cmailto:CAAy62_%2BJtoAuM-RsrAAp5eiGiO%2BOHLDjzqgbnF2De7TUU7TyYg at mail.gmail.com\u003e\u003e\n\u003e Content-Type: text/plain; charset=\"utf-8\"\n\u003e \n\u003e I believe that as we continue to add users to the system by scaling\n\u003e capacity that we will see more new nodes appear, but I'm at a bit of a loss\n\u003e as to how to empirically prove it.\n\u003e \n\u003e I do see your point on increasing load on archival nodes, but the majority\n\u003e of that load is going to come from new nodes coming online, they're the\n\u003e only ones going after very old blocks. I could see that as a potential\n\u003e attack vector, overwhelm the archival nodes by spinning up new nodes\n\u003e constantly, therefore making it difficult for a \"real\" new node to get up\n\u003e to speed in a reasonable amount of time.\n\u003e \n\u003e Perhaps the answer there would be a way to pay an archival node a small\n\u003e amount of bitcoin in order to retrieve blocks older than a certain cutoff?\n\u003e Include an IP address for the node asking for the data as metadata in the\n\u003e transaction... Archival nodes could set and publish their own policy, let\n\u003e the market decide what those older blocks are worth. Would also help to\n\u003e incentivize running archival node, which we do need. Of course, this isn't\n\u003e very user friendly.\n\u003e \n\u003e We can take this to bitcoin-discuss, if we're getting too far off topic.\n\u003e \n\u003e \n\u003e On Wed, Mar 29, 2017 at 11:25 AM David Vorick \u003cdavid.vorick at gmail.com \u003cmailto:david.vorick at gmail.com\u003e\u003e\n\u003e wrote:\n\u003e \n\u003e \u003e\n\u003e \u003e On Mar 29, 2017 12:20 PM, \"Andrew Johnson\" \u003candrew.johnson83 at gmail.com \u003cmailto:andrew.johnson83 at gmail.com\u003e\u003e\n\u003e \u003e wrote:\n\u003e \u003e\n\u003e \u003e What's stopping these users from running a pruned node? Not every node\n\u003e \u003e needs to store a complete copy of the blockchain.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Pruned nodes are not the default configuration, if it was the default\n\u003e \u003e configuration then I think you would see far more users running a pruned\n\u003e \u003e node.\n\u003e \u003e\n\u003e \u003e But that would also substantially increase the burden on archive nodes.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Further discussion about disk space requirements should be taken to\n\u003e \u003e another thread.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e --\n\u003e Andrew Johnson\n\u003e -------------- next part --------------\n\u003e An HTML attachment was scrubbed...\n\u003e URL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/9b48ebe3/attachment.html \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/9b48ebe3/attachment.html\u003e\u003e\n\u003e \n\u003e ------------------------------\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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/ca39b10a/attachment.html\u003e",
"sig": "44307cfa9bd61f23dac876a08c4c6c63665f69a610bf05af20b8d23f94378fc045cccca6cb6c6b6533461126bb8b11e649a2cae485c503951141c8a4141883db"
}