Re: [bitcoin-dev] Guessing the spentness status of the pruned relatives

[praxeology_guy <praxeology_guy@protonmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2206 bytes --]

Bram Cohen,

My apologies, I guess I glossed over your "The TXO bitfield" because by subject I thought it just had something to do with changing the txo's data structure.

Yes what you are proposing with "The TXO bitfield" is pretty much exactly the same as the MMR data structure... EXCEPT yours has the wonderful benefit of the MMR proofs not changing. Excellent idea!

Basically your idea is a change in how the MMR data is modified on spend... moving it from changing the leaf nodes to changing a node closer to the root... and particularly it seems you are making such a deltaLeaveHeight = block height... which might be a different height for each block, but not that big of a deal.

Which leads me to modifying the MMR structure so that the spentness bit array is actually part of the nodes at height DLH_REQUIRED's hash... and that the leaf nodes don't actually get changed to empty as Peter is proposing, instead the leaf nodes stay the same. This results in the same wonderful benefit of the MMR proofs not changing, just like in your "TXO bitfield" proposal.

I still like the MMR structure better, in the case that only utxos are added after a long delay. The delay and adding only utxos allows much fewer additions to the spentness bitfield and it's merkle tree. But if we are going to make commitments on the entire txo set instead of some policy of N blocks delayed utxos... your "TXO bitfield" idea looks great.

Say... one bad thing about only adding delayed utxos to the MMR, as I am proposing, is that the index changes/is created when the delayed addition happens. Verses with "txo bitfield" or adding all txos to the MMR, the index is created when the block is first made.

Thank you so much for your TXO bitfield idea... and harping on me about it. I'm really excited about these designs. :) As a funny side note,I had actually considered putting the spentness bitfield in the deltaLeafHeight = DLH_REQUIRED node's merkle hash... but quickly dismissed it since we were already were replacing the leafs w/ empties (which is a duplication of information). Your idea was the inspiration to switch from changing to empties to changing the spentness bits.

Humbled, Thanks,

Praxeology Guy

[-- Attachment #2: Type: text/html, Size: 2495 bytes --]