📅 Original date posted:2017-04-03
📝 Original message:On Sun, Apr 2, 2017 at 1:43 PM, praxeology_guy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> TL;DR: using spentness bits scales linearly... vs swapping digest leafs
> with empties can scale with logorithmically increasing storage
> requirements. So if you are using a 32 byte hash and spentness bits, you
> are pretty much limited to only being able to prune 8 to 12 layers. This
> corresponds to an MMR proof length of 512 to 768 bytes.
>
Yes the point of the txo bitfield is that the constant factors are so good
that it's entirely under control. Making the memory commitments smaller
requires that the proofs be kept up to date and increases CPU requirements
and proof size. It would be entirely reasonable to make an MMRs of the
bitfield or the insertion index data structure but they aren't needed
immediately if ever. For the insertion ordering structure it's reasonable
to require full nodes to cache the top bunch of layers to make the proofs
smaller, but a very expedient approximation of that is to make them simply
remember a root per block for all the insertions contained therein, and
have full nodes remember all of those.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170402/7d4e165b/attachment.html>;
Bram Cohen [ARCHIVE] /
npub1ld…t8ur6
2023-06-07 17:58:56
in reply to nevent1q…zl6q
Author Public Key
npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6Published at
2023-06-07 17:58:56Event JSON
{
"id": "6f5aa70ba056033fbb072650c1a251e80aa5ce2ff98d919a64c3dfdb68f1df86",
"pubkey": "fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9",
"created_at": 1686160736,
"kind": 1,
"tags": [
[
"e",
"56cde3ba45fdc2fd1de191987567d27ad54a1430fd971dd6fb1d3c51a3891d99",
"",
"root"
],
[
"e",
"b48223418aefb3ae53acb7cc8618f91e3d0ffcf2664a4f2937e66a818211fd42",
"",
"reply"
],
[
"p",
"b8acca17a6f74c77cd8a4899846d99012d1b52082a01a2d2753fcb0c6669a60b"
]
],
"content": "📅 Original date posted:2017-04-03\n📝 Original message:On Sun, Apr 2, 2017 at 1:43 PM, praxeology_guy via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e TL;DR: using spentness bits scales linearly... vs swapping digest leafs\n\u003e with empties can scale with logorithmically increasing storage\n\u003e requirements. So if you are using a 32 byte hash and spentness bits, you\n\u003e are pretty much limited to only being able to prune 8 to 12 layers. This\n\u003e corresponds to an MMR proof length of 512 to 768 bytes.\n\u003e\n\nYes the point of the txo bitfield is that the constant factors are so good\nthat it's entirely under control. Making the memory commitments smaller\nrequires that the proofs be kept up to date and increases CPU requirements\nand proof size. It would be entirely reasonable to make an MMRs of the\nbitfield or the insertion index data structure but they aren't needed\nimmediately if ever. For the insertion ordering structure it's reasonable\nto require full nodes to cache the top bunch of layers to make the proofs\nsmaller, but a very expedient approximation of that is to make them simply\nremember a root per block for all the insertions contained therein, and\nhave full nodes remember all of those.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170402/7d4e165b/attachment.html\u003e",
"sig": "45b90403a252d5407301c5a612c69e4ee12aec6ac4bd2bab8a9e6a2445eefe3114781be12c8963fc8f5a4776e25d464b2b23d02e5387faf7f0fa2a3484d50b8c"
}