<div>Peter Todd,<br></div><div><div><div><div><div><div><br></div></div></div><div>This MMR structure looks good to me.&nbsp; 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.<br></div><div><br></div></div></div></div><div>Re: "only left or right child of inner node be a fully spent node"...&nbsp; that sounds fine to me, but the software should virtually consider that the previous dissapearing leaf nodes still exist.&nbsp; It would instead say be a special case handled by the meta hashing function.&nbsp; Would save a good amount of time from unneccesary hashing.&nbsp; 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.<br></div><div><div><div><br></div></div><div>Below is questions about txo/utxo MMR commitments after reading: "<a href="https://petertodd.org/2016/delayed-txo-commitments">https://petertodd.org/2016/delayed-txo-commitments</a>".<br></div></div><div><br></div><div>I'm mainly concerned about the performance of recalculating all of the node hashes on old spends.&nbsp; But probably with a long enough delay policy, it shouldn't be an issue.<br></div><div><br></div><div>Then the issues with people keeping their MMR proofs up to date and discovering received txos before they get pruned.&nbsp; Sure would be nice if a wallet didn't have to keep on updating their MMR proof.&nbsp; Hopefully spends would refer to old txos by their MMR index.<br></div><div><br></div><div>How are you ordering MMR additions?&nbsp; Are you only adding old utxos to the MMR? Or every old txo?&nbsp; I think you are doing all old txos (mostly would be spent nodes), but why not just old utxos?&nbsp; 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?&nbsp; Potentially a tx could use a MMR.ix, allblock'stxo.ix (if we want to maintian that index), or tx.id &amp; vout.ix depending on how old the tx is.<br></div><div><br></div><div>What is the process for removing old utxos from the utxo set, and placing them into the MMR?&nbsp; Are you going to keep height in the utxo db, and then iterate through the whole thing?<br></div><div><br></div><div>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?&nbsp; I would figure a longer delay would be better as long as the utxo doesn't get too big.&nbsp; Longer delay means less MMR maintainance.<br></div><div><br></div><div>Have you considered not making a new commitment on every block, instead maybe every 6*24 blocks or so?&nbsp; This could reduce the number of times the same nodes are re-hashed, while not having much impact on security.<br></div><div><br></div><div>What about re-orgs?&nbsp; You'd have to restore the previous leaf &amp; inner nodes.&nbsp; You'd need both the txos and MMR proofs, right?&nbsp; It looks like you clear this info from the TXO journal when the delay duration threshold is met.&nbsp; I guess this info might also be stored with the block data, and could be recovered from there.<br></div><div><br></div><div>What are your current thoughts on block size weighting for MMR proofs?&nbsp; Just count the extra byte length that full nodes need to relay as simliar to SegWit witness data?<br></div><div><br></div><div>Cheers,<br></div><div>Praxeology Guy<br></div>