[feature]: Multihop routing for taproot assets and Bitcoin taproot channels

[szhygulin]

When the taproot assets (TA) are sent over Lightning, a double conversion TA->BTC->TA leads to high transaction fees since edge nodes will likely set a high price spread to hedge against price risks. AFAIK such behavior is a result of TA channels being private. Additionally, the underlying Bitcoin Taproot channel does not participate in routing since it is private too.

Is it possible to make the TA channel public? In that case, routings like TA-> TA-> TA would be much cheaper than transactions with double conversion.

Alternatively, can the underlying Bitcoin Taproot channel be set as public so that it can participate in the routing?

[Roasbeef]

Is it possible to make the TA channel public? In that case, routings like TA-> TA-> TA would be much cheaper than transactions with double conversion.

Yes it's possible, but it introduces an entirely new set of concerns: price data for each asset in the public network, discovery, verification, etc, etc. We're currently no actively pursing this direction, as creating an entirely new network for each relevant asset is a tall bootstrapping task, which will fragment liquidity and UX.

Ultimately, it's all just routing fees, when you do TA->BTC->TA, your fees will eventually be comparable to if you do BTC->BTC->BTC.

[szhygulin]

Yes it's possible, but it introduces an entirely new set of concerns: price data for each asset in the public network, discovery, verification, etc, etc. We're currently no actively pursing this direction, as creating an entirely new network for each relevant asset is a tall bootstrapping task, which will fragment liquidity and UX.

is it possible to make the underlying taproot Bitcoin channel public so it can participate in routing?

[guggero]

is it possible to make the underlying taproot Bitcoin channel public so it can participate in routing?

Eventually, yes. But that requires general Lightning protocol (BOLTS) changes to be able to gossip "normal" taproot channels. And that's still work in progress (see lightning/bolts#1059 and lightning/bolts#995).