So I think this is just a regular merkle tree of the utxo set, not really a “utreexo” thing per se.
Yes, you are right. This could have been done with just a regular merkle tree over the UTXO set, but I chose to use the utreexo data structure since it it is pretty straight forward to convert it to the “proper” utreexo representation that is per block deterministic.
I don’t see how this really works for lightning channel announcements – can’t you just give a proof for a utxo as at block X, then spend it in block X+1? ie, at best, isn’t this just proof-of-use-of-blockspace?
This is a very good point. I can prove that a channel was opened, but there is no guarantee that it will stay open. Maybe one could require the proofs to be “refreshed” every X blocks? Each proof could also contain a proof of channel-age.
Also, can’t you use the same utxo multiple times with different blinding factors to advertise multiple lightning channels? If you make the “verifier’s public key” (
P'inP' = P+bG) be the channel’s advertised public key (musig(A,B)?) that might be good enough to prevent selling utxos.
The current setup is proving that the proper public key (not the blinded one) is commited to in the utreexo structure, so the blinding factor doesn’t matter. But there is currently no way of telling whether a public key has been reused for multiple proofs, so that should be added for the LN use case.