search

lightninglabs / taproot-assets

A layer 1 daemon, for the Taproot Assets Protocol specification, written in Go (golang)
MIT License
457 stars 110 forks source link

bip-taro-universe: flesh out capability for unilateral exit from pocket universe due to provable censorship #36

Open Roasbeef opened 2 years ago

Roasbeef commented 2 years ago

There's an existing TODO in the BIPs for the Pocket Universe construct. At a high level, a Pocket Universe is a sort of Taro-specific federated sidechain. Parties can opt to "freeze" their normal assets in a top-level native Bitcoin transaction, then inhiert the capaubilities of cheaper aggregrated on-chain transfer byu doing them in a virtual transaction graph. This virtual trancstion graph is commited to th eUniverse, so parties can observer trnasfer,s and also prove ownership of transfers.

One issue with the current design is while operators can't forge transfers (can't forge a digital sig), they can chose to omit commitments all together. With the current design, omitting a commitment ends up burning an asset, as that's an invalid state transition.

I've come up with a new idea, dubbed "exit portals". The idea is that rather than put their locked asset commitment in that top-level output controlled by the federation (?), they instead create an output on chain that allows parties to unilaterally exit from the pocket universe. This relies on the fact that if commitment N contains my asset, but commitment N+1 doesn't, then assuming I have the commitment data, I can create an inclusion proof for commitment N and an exclusion proof for N+1. I can then use the on-chain exit portal to regain full control of the asset, as we'd add additional VM state machine validation for this exit case.

In order to work properly this exit portal output needs to be created in the same transaction (?) as the initial pocket universe asset transfer. This trade off means it doesn't inherit the UTXO scaling properties (1 UTXO, unbounded amount of assets) quite like the existing concept did. However it may be possible to batch these outputs together, Coinpool style, enabled by anything CTV-like. Alternatively, it may be possible to retain the UTXO aggregation by having the initial entrance transaction a prior delegate another exiting output (or output descndent chain?) as the exit portal.

Related to https://github.com/lightninglabs/taro/issues/9

ben2077 commented 2 months ago

If we are going to use CTV to construct such a top-level output, essentially we need to commit to the transaction in advance, for example, the denomination that can be obtained when exiting, because the amount of money to be received cannot be dynamically calculated.