An unintuitive aspect of the Lightning protocol is that channels in the middle of your route don’t have to be real. If Alice is trying to pay BTC to David, through the route Alice ↔ Bob ↔ Charlie ↔ David, whether or not the Lightning channels between Bob and Charlie represent real channels with real Bitcoin doesn’t matter! Indeed, it doesn’t even matter to Alice whether or not David received genuine BTC at all. All that matters to her is that David accepted the payment as valid by revealing the preimage; if he didn’t, Alice never gave a single sat to Bob.

Equally, if Alice is receiving a BTC payment from David, through the David ↔ Charlie ↔ Bob ↔ Alice route, it doesn’t matter to Alice whether or not David sent genuine sats to Charlie. Or whether or not Charlie sent genuine BTC to Bob. All she cares is that somehow Bob was convinced to send genuine BTC to Alice.

The existing Lightning protocol does ensure that public channels correspond to valid UTXOs. But the reason why this is done is really just an anti-DoS measure: there has to be some limit on how many channels people can advertise. Tying the Lightning channel UTXO to the gossip advertisement happens to be the way we do that right now.

Lightning With Client-Side-Validated Tokens

The fact that Lightning payments can be safely routed over fake channels has so far been a theoretical curiosity for Lightning over Bitcoin. It’s been proposed before as a way to reduce liquidity requirements for channels between entities that trust each other. But the idea has never actually been implemented.

However, it makes a very big difference to Lightning on top of client-side-validated tokens.

To recap, a client-side-validated coin using a protocol such as RGB uses Bitcoin as a pure anti-doublespend mechanism: Bitcoin ensures there is exactly one history for a given coin. The validity of that history is verified client side. Thus if Alice gives Bob a coin representing $1 USD on RGB, she convinces Bob that the coin is real by giving Bob all the coin history data back to the genesis outputs(s) that created her particular coin.

Since history is not global, client-side-validation has the potential of enormous scalability. As I have explained on this blog before, a client-side-validation token could have a total volume of literally billions of transactions per second. But, these transactions are still a kind of on-chain transaction, which means they will take time to confirm; Lightning transactions can be almost instant.

Thus both RGB and Taproot Assets are working towards implementing Lightning channels that trade client-side validated tokens.

Which gets back to the issue of “fake” channels: while it might take a few megabytes of transaction data to prove that an RGB token in your posession is real, if you’re using that token for a Lightning channel, you do not need to know whether or not the RGB tokens of anyone else’s Lightning channels are real! It’s sufficient to have proof that your channel is real to be fully self-sovereign; if other people have been fooled into accepting fake coins, that’s not your problem.

Taproot Asset Universes

This does raise an interesting question: are the Asset Universes in Taproot Assets really necessary? The idea behind them is that light clients would — instead of proper validation — trust third party “universes” to perform coin validation for the asset(s) they are transacting. The universes would be expected to have most if not all transactions for a given asset, and would create large, signed, merkle trees committing to all valid coins at a given block height.

If the typical “light” wallet simply uses Lightning channels, by simply downloading a few MB worth of data they can have full client-side-validation of their coins, without relying on any third parties. Since it doesn’t actually matter whether or not intermediary Lightning channels are real, the light wallet could even do full routing themselves, based on gossiped channels (e.g. using, say, a proof-of-sacrifice anti-DoS mechanism).