> This leaves the BTC utxo set unmanageable and unpredictable. Although this is true, I don't think this eliminates the possibility of such UTXO commitment. I

> This leaves the BTC utxo set unmanageable and unpredictable. Although this is true, I don't think this eliminates the possibility of such UTXO commitment. It is iteratively updated every block and doesn't care about predictability. The code as written could be easily merged into BTC as well. The only small difference would be in backtracking: When we have full node that uses fast syncing we could implement that they retrieve older blocks until they are satisfied (either by assumevalid or some accumulated work), and verify from that point. They can simply apply the commitment backwards. On Bitcoin Cash, this would require block propagation that includes the TxOuts being spent by the block. This is a bit more difficult on Bitcoin to the difference in sighashing: these TxOuts aren't directly committed transactions that spend them.