Quote from: oryhp on Today at 09:03:28 PM

It's possible what follows contains logical mistakes.

I was toying with a similar idea where each output would be its own Utreexo. Since that's a forest of trees, an output would need to keep the roots and each root would have the amount sum of the elements in the tree. This way, we'd know the amount the Utreexo UTXO holds and can do the inflation check.
Much like Utreexo, a transaction comes with is a list of inclusion proofs [proof1, proof2,...] which gives us the inputs. A transaction also defines the outputs that are created. We check the signature and that the transaction is well balanced and then delete the inputs from the Utreexo tree and add outputs as new elements to the Utreexo.
I'm not sure I remember correctly, but I believe anyone can delete an element if they have the forest roots and the inclusion proof and anyone can add an element if they have the element and the roots. Since we have both as part of a transaction validation, anyone can update the Utreexo accumulator.

This obviously isn't compatible with Bitcoin today, but may be an interesting direction to think in. Those interested in a specific Utreexo may have the tree saved locally and could share it with others in the tree if someone lost their inclusion proofs.
It may even be permissionless to put your UTXO in any Utreexo. Simply spend a regular UTXO and add it as an element to Utreexo which should be possible because we have the forest roots for all of them.

I admit I have not studied Utreexo as much as I would like I only heard about it a month ago or so, my idea was slightly inspired by the basic idea of Utreexo which was turning outputs into commitments to outputs for scaling purposes. But as far as I can tell the Utreexo concept is more like a lite-client scaling technique and probably needs to be reinforced with EC cryptography in my opinion in order to become something that can be represented to a regular full node.

I may be incorrect but I think the issue is the merkle tree being committed to is not some kind of a tagged branch commitment scheme like taproot but more like a direct hash tree. My theory is that something with tagged commitments would be possible to reproduce without needing to store inclusion proofs similar to how taproot doesn't require you to hold all the involved public keys but bare multi-sig does.