praxeology_guy [ARCHIVE] on Nostr: š
Original date posted:2017-02-28 š Original message:Peter Todd & Eric ...
š
Original date posted:2017-02-28
š Original message:Peter Todd & Eric Lombrozo,
I also think communicating the UTXO would be increadibly useful. I just made a writeup called "Synchronization Checkpoints" on github. "
https://github.com/bitcoin/bitcoin/issues/9885"; This idea also doesn't use commitments.
But... Commitments would be a plus, because then we having all of the miners verifying the UTXO. Below I brainstorm on how to make this happen with my "Synchronization Checkpoints" idea.
I think if there were commitments, such would not be feasible without it being a commitment on the UTXO as it was N blocks in the past rather than the highest block's UTXO set... because just one little fork of height 1 would be a big waste of effort for the miners.
- Miners would put a commitment at the current Checkpoint Block that would be a hash of the full state of the UTXO at the previous Checkpoint Block.
- I'll point out that blocks are like "incremental diffs" to the UTXO state.
I was thinking that say if a miner and other nodes are OK with storing multiple copies/backups of the UTXO state then to make this work with high performance:
1. Maintain a DB table who's only purpose is to sort UTXO.txid concat UTXO.vout.index.
2. Some Wait for no Forks blocks after a CheckPoint Block is made, begin populating a new UTXO Checkpoint File that is a serialized sorted UTXO set.
3. Merkle tree or bittorrent style hash the UTXO Checkpoint File
4. Party!
Cheers,
Praxeology
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170228/354c0708/attachment.html>
Published at
2023-06-07 17:56:29Event JSON
{
"id": "7591707f648297bf0fd2c3a31b5db816a470ea4e66613453dec5daf4e2a263d3",
"pubkey": "b8acca17a6f74c77cd8a4899846d99012d1b52082a01a2d2753fcb0c6669a60b",
"created_at": 1686160589,
"kind": 1,
"tags": [
[
"e",
"a0b524bf2f2752d90819b6de72593123747d751d12083bfe67597e028020ed0d",
"",
"root"
],
[
"e",
"27f03aa5e03c73310f5f4a89b428089c58b8016370cecc8a14d4e6fc8dbb5228",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "š
Original date posted:2017-02-28\nš Original message:Peter Todd \u0026 Eric Lombrozo,\n\nI also think communicating the UTXO would be increadibly useful. I just made a writeup called \"Synchronization Checkpoints\" on github. \"https://github.com/bitcoin/bitcoin/issues/9885\" This idea also doesn't use commitments.\n\nBut... Commitments would be a plus, because then we having all of the miners verifying the UTXO. Below I brainstorm on how to make this happen with my \"Synchronization Checkpoints\" idea.\n\nI think if there were commitments, such would not be feasible without it being a commitment on the UTXO as it was N blocks in the past rather than the highest block's UTXO set... because just one little fork of height 1 would be a big waste of effort for the miners.\n\n- Miners would put a commitment at the current Checkpoint Block that would be a hash of the full state of the UTXO at the previous Checkpoint Block.\n- I'll point out that blocks are like \"incremental diffs\" to the UTXO state.\n\nI was thinking that say if a miner and other nodes are OK with storing multiple copies/backups of the UTXO state then to make this work with high performance:\n1. Maintain a DB table who's only purpose is to sort UTXO.txid concat UTXO.vout.index.\n2. Some Wait for no Forks blocks after a CheckPoint Block is made, begin populating a new UTXO Checkpoint File that is a serialized sorted UTXO set.\n3. Merkle tree or bittorrent style hash the UTXO Checkpoint File\n4. Party!\n\nCheers,\nPraxeology\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170228/354c0708/attachment.html\u003e",
"sig": "d6c39068a84a5433eccfb04addbf017e2603a1d6c890a2e809599c4e93cfd6eb38b515c38c992707b49be5c135cbdadba8e409d2f90cf127db4615016e67ba18"
}