Peter Todd,
This MMR structure looks good to me. I really like how wallets keep their MMR
proof and txo index instead of requiring the entire network to maintain an
index on txids w/ plain old utxo snapshots.
Re: "only left or right child of inner node be a fully spent node"... that
sounds fine to me, but the software should virtually consider that the previous
dissapearing leaf nodes still exist. It would instead say be a special case
handled by the meta hashing function. Would save a good amount of time from
unneccesary hashing. Might also do the rule: if a parent node has a single
fully spent child node, its hash is equal to its other child's hash.
Below is questions about txo/utxo MMR commitments after reading:
"https://petertodd.org/2016/delayed-txo-commitments";.
I'm mainly concerned about the performance of recalculating all of the node
hashes on old spends. But probably with a long enough delay policy, it
shouldn't be an issue.
Then the issues with people keeping their MMR proofs up to date and discovering
received txos before they get pruned. Sure would be nice if a wallet didn't
have to keep on updating their MMR proof. Hopefully spends would refer to old
txos by their MMR index.
How are you ordering MMR additions? Are you only adding old utxos to the MMR?
Or every old txo? I think you are doing all old txos (mostly would be spent
nodes), but why not just old utxos? Are you doing it to make MMR index =
blockchain txo index, so such an index can be used in all TX inputs except for
non-confirmed transactions? Potentially a tx could use a MMR.ix,
allblock'stxo.ix (if we want to maintian that index), or tx.id & vout.ix
depending on how old the tx is.
What is the process for removing old utxos from the utxo set, and placing them
into the MMR? Are you going to keep height in the utxo db, and then iterate
through the whole thing?
Are you still proposing a 1 year txo commitment delay? Do you have any
data/preformance studies judging the cost of a larger utxo and longer delay vs
smaller utxo and shorder delay? I would figure a longer delay would be better
as long as the utxo doesn't get too big. Longer delay means less MMR
maintainance.
Have you considered not making a new commitment on every block, instead maybe
every 6*24 blocks or so? This could reduce the number of times the same nodes
are re-hashed, while not having much impact on security.
What about re-orgs? You'd have to restore the previous leaf & inner nodes.
You'd need both the txos and MMR proofs, right? It looks like you clear this
info from the TXO journal when the delay duration threshold is met. I guess
this info might also be stored with the block data, and could be recovered from
there.
What are your current thoughts on block size weighting for MMR proofs? Just
count the extra byte length that full nodes need to relay as simliar to SegWit
witness data?
Cheers,
Praxeology Guy
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
