📅 Original date posted:2017-03-07
📝 Original message:On Tue, Mar 7, 2017 at 1:28 PM, praxeology_guy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> merkle tree hashes:
> - array of "piece count" leaf hashes, hashing the balance pieces
> - array of "(child layer count + 1)/2" node hashes, hashing pairs of child
> hashes, or copying up if only one child
> - repeat ^ until the root hash is written
> ... except reverse the layer order. In other words, it should be breadth
> first.
>
A big yuck on that format. It should be something based on a patricia trie
to support incremental updates. Also if the things being stored are output
transaction + output number then those two can be hashed together to make a
consistent size identifier and be put into the merkle set format I
proposed, which is exactly the intended usage:
https://github.com/bramcohen/MerkleSet
- We could make BCP 4383 blocks, which would be 12 times per year, given
> block period was exactly 10 minutes. But since block period is not exactly
> 10 minutes, and file names generated with period 4283 are much less
> comprehensible than file names generated with period 5000... I propose
> 5000.
>
If it's of that order it should be synched up with the work difficulty
reset interval of 2016. If the format supports incremental updates it would
of course be possible to require them more frequently later.
> - Having a shorter BCP period would result in more frequent checks on UTXO
> set integrity, and permit new pruning nodes to start synching closer to the
> tip. But it may require nodes to keep more copies of the balances file to
> satisfy the same backup period, and require more background work of
> creating more balances files.
>
With a patricia based format it would be possible to make much more common
utxo commitments, possibly as often as every block only trailing by a few,
and the cost of updating wouldn't be onerous and reorgs could be handled by
simply undoing the last few transactions in the set and and then rolling
forward.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170307/79914478/attachment.html>;
Bram Cohen [ARCHIVE] /
npub1ld…t8ur6
2023-06-07 17:57:07
in reply to nevent1q…ezdu
Author Public Key
npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6Published at
2023-06-07 17:57:07Event JSON
{
"id": "383543c3cf8c50a67412be2b91554312bfcdbf6b0ab7f24f4c2bee31ba24608a",
"pubkey": "fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9",
"created_at": 1686160627,
"kind": 1,
"tags": [
[
"e",
"808640e383dbbcbf442ecd6d1b0ab38b92db475a65ef8baecd2bf4a2841f705c",
"",
"root"
],
[
"e",
"c60a3349eb10fa53418772d527e77e0a09be4448754ad1e5ad9508554e510ba8",
"",
"reply"
],
[
"p",
"b8acca17a6f74c77cd8a4899846d99012d1b52082a01a2d2753fcb0c6669a60b"
]
],
"content": "📅 Original date posted:2017-03-07\n📝 Original message:On Tue, Mar 7, 2017 at 1:28 PM, praxeology_guy via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e merkle tree hashes:\n\u003e - array of \"piece count\" leaf hashes, hashing the balance pieces\n\u003e - array of \"(child layer count + 1)/2\" node hashes, hashing pairs of child\n\u003e hashes, or copying up if only one child\n\u003e - repeat ^ until the root hash is written\n\u003e ... except reverse the layer order. In other words, it should be breadth\n\u003e first.\n\u003e\n\nA big yuck on that format. It should be something based on a patricia trie\nto support incremental updates. Also if the things being stored are output\ntransaction + output number then those two can be hashed together to make a\nconsistent size identifier and be put into the merkle set format I\nproposed, which is exactly the intended usage:\nhttps://github.com/bramcohen/MerkleSet\n\n- We could make BCP 4383 blocks, which would be 12 times per year, given\n\u003e block period was exactly 10 minutes. But since block period is not exactly\n\u003e 10 minutes, and file names generated with period 4283 are much less\n\u003e comprehensible than file names generated with period 5000... I propose\n\u003e 5000.\n\u003e\n\nIf it's of that order it should be synched up with the work difficulty\nreset interval of 2016. If the format supports incremental updates it would\nof course be possible to require them more frequently later.\n\n\n\u003e - Having a shorter BCP period would result in more frequent checks on UTXO\n\u003e set integrity, and permit new pruning nodes to start synching closer to the\n\u003e tip. But it may require nodes to keep more copies of the balances file to\n\u003e satisfy the same backup period, and require more background work of\n\u003e creating more balances files.\n\u003e\n\nWith a patricia based format it would be possible to make much more common\nutxo commitments, possibly as often as every block only trailing by a few,\nand the cost of updating wouldn't be onerous and reorgs could be handled by\nsimply undoing the last few transactions in the set and and then rolling\nforward.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170307/79914478/attachment.html\u003e",
"sig": "e310f0827419d039e5527c0f7ec112879ca63869c851e1c338bc77f54f6a650a19b85be8c5f8496d62217c42ff86be01846bd56fba63b55cea4b3b222c247523"
}