<div dir="ltr">I see more people are thinking about this cross-chain lightning problem and even working on it, it seems.<br>That is great, let's please join forces if we can. I'm happy to help in any way I can.<br><br>Here's an example on how I think things could work in the future, like 2 or 3 steps after what I think cdecker is doing and<br>like 5 or 6 steps of what I'm currently doing.<br>Please, point out anything I may be missing or any alternatives I'm not considering.<br><br>Let's say Alice has a lightning node configured to run on network=chain_A.<br>She wants to pay an invoice Bob gave her, but it turns out that bob has his lightning node configured for network=chain_B.<br><br>Let's assume we already have trampoline routing as per <a href="https://github.com/lightningnetwork/lightning-rfc/pull/654">https://github.com/lightningnetwork/lightning-rfc/pull/654</a><br><br>In fact, let's copy the entire example there and change some things. We part from:<br><br><br>```text<br>Alice                 TA1                  TA2 -> TB3         Bob<br>  |                   ^ |                   ^      |           ^<br>  |                   | |                   |      |           |<br>  `---> H1 ---> H2 ---' `---> H3 ---> H4 ---'      `---> H5 ---'<br>```<br><br>But here not all nodes operate in the same chain, they distribute as follows:<br><br>chain_A: Alice, TA1, TA2, H1, H2, H3, H4<br>chain_B: Bob, TB3, H5<br><br>Now the first problem we encounter, is that since TA2 and TB3 don't<br>operate in the same chain, the direct payment between them can't<br>happen as described in the example for regular trampoline payments,<br>for there can't be a channel between nodes in different chains.<br><br>But what if TA2 and TB3 belonged to the same person?<br>Let's call that person Carol and let's call the software that makes things happen a "Gateway" (we can find a better name later, as with anything else).<br>Note that apart from TA2 and TB3, Carol's gateway could also connect to other nodes operating in chain_C, chain_D and chain_E, for example.<br><br>```text<br>                                               Carol<br>Alice                 TA1                  TA2 -*?-> TB3         Bob<br>  |                   ^ |                   ^         |           ^<br>  |                   | |                   |         |           |<br>  `---> H1 ---> H2 ---' `---> H3 ---> H4 ---'         `---> H5 ---'<br>```<br><br>Now the main concern is to clarify what the "-*?->" nomenclature means.<br><br>But before that, shouldn't alice, when building trampoline_onion_packet, notice that TB3 and Bob don't belong to chain_A?<br>We need a way for Alice to know that she can actually attempt that.<br>Carol could advertise that she is managing a gateway between TA2 and TB3 (perhaps more) in some gossip network.<br>Note this network doesn't need to be part of the lightning protocol, or be just optional following the "it's ok to be odd" design.<br>Few things are easier than ignoring gossip that is not of your interest, I think.<br><br>We could have an update_gateway gossip message with something like:<br><br>- gateway_id<br>- list of node ids<br>- list of signatures by those node's ids<br>- signature by gateway_id<br><br>The proportional fees charged for different combinations may be different,<br>take into account that we're not only talking about fees but also prices,<br>for the asset in chain_A may not be the same as the asset in chain_B and, even if they are,<br>there can be some discount for the units in one of the chains for whatever reason.<br><br>Apart from a gossip message we would need some update_gateway_route, perhaps with:<br><br>- src_chain_id<br>- dest_chain_id<br>- price (this can include an implicit proportional fee)<br><br>I know, this is a directed graph and it potentially grows exponentially with the number of chains in the same gateway.<br>But it would be worse with a graph separately by node_id rather than chain_id.<br>I honestly don't see other way around this.<br><br>Also, I know there's the "free option" problem (see <a href="https://en.bitcoin.it/wiki/Atomic_swap#Financial_optionality">https://en.bitcoin.it/wiki/Atomic_swap#Financial_optionality</a> ).<br>Let's remember that at the very moment Carol's gateway software is processing "-*?->" some validation could be triggered<br>that concluded something along the lines:<br>"you know what? I don't like this H5 path nor any other I found for what I consider a fair price at this very moment,<br>so I'm going to pass and forward back to whoever initiated this payment<br>an error saying I'm not ok with that price anymore, perhaps suggesting a different one while at it.<br>I will also make sure my gateway nodes are sending the right price for that pair and direction in update_gateway_route"<br><br>Well, that's not the best way to explain it but I think it can be understood.<br>Even if that's not enough, even if other people can't find better ways to mitigate the free option problem,<br>there are potential use cases with constant or relatively stable exchange rates for which this shouldn't be a problem.<br>So let's please focus on everything else except for the free option problem in this thread.<br><br>Let's just accept that both Alice and the gateway software are using some formula to convert<br>from the amt_to_forward received by TA2 to the one that TB3 is supposed to receive and process.<br>If f(amt_to_forward_TA2, price_current) > f(amt_to_forward_TA2, price_alice),<br>TA2 may fail and send H4 an error that ultimately will get back to alice.<br>We could use amt_to_forward * price nomenclature rather than f(amt_to_forward, price) if you like.<br>Let's just remember we need to define price's type though.<br>Presumably some approximation of rational numbers that computers can handle reasonably well and<br>with a precision that is reasonable enough for our requirements.<br><br>Another operation that is required as part of "-*?->" (and that alice must do) that I personally find much more troubling is the<br>calculation from amt_to_forward_TA2 to final_cltv_expiry for Bob or the following outgoing_cltv_value if there were more trampoline nodes<br>inbetween, or even more gateways and chains.<br>With the price we can calculate f(amt_to_forward_AT2, price) = amt_to_forward_BT3 and derive the rest from there,<br>even though a trampoline hop payload for TB3 is not needed since it can be assumed by alice to be calculated by carol's gateway<br>from what it receives. The point is TB3 doesn't need to know or care about the prices for other gateways after it.<br><br>Maybe I am mistaken, but just like with the price we should just be able to define the following:<br><br>g(outgoing_cltv_value_TA2, chain_time_translation) = outgoing_cltv_value_TB2<br><br>So since Alice would need to calculate g too, in reality update_gateway_route would look like:<br><br>- src_chain_id<br>- dest_chain_id<br>- price (this can include an implicit proportional fee)<br>- chain_time_translation<br><br>I imagine the type for chain_time_translation to be an imaginary number.<br>Actually, not. I usually imagine imaginary numbers as an array with 2 real elements,<br>but in this case I think just 2 integers should be fine, sorry.<br>Why 2?<br>Well, chains not only have different start times and current height, they also potentially have different<br>estimated times between blocks (ie bitcoin has 10 minutes, but other chains have other settings).<br>I was I assuming something like:<br><br>g(outgoing_cltv_value_TA2, chain_time_translation) =<br>chain_time_translation_param_1 + (outgoing_cltv_value_TA2 * chain_time_translation_param_2) =<br>outgoing_cltv_value_TB2<br><br>Please anyone feel free to actually solve that problem before me.<br>I haven't thought hard about this because if I assume unity (1 as in algebra class) for both price and chain_time_translation<br>I don't actually need to care about the types or the f and g operations, since doing that I know f(x)=x and g(y)=y by definition if x=1 and y=1.<br><br>In any case, we know Alice (the payer) needs to calculate f and g for the whole path using some inter-chain gossip. for prices and chain time translation.<br><br>As part of "-*?->", Each gateway also should recalculate f and g locally, potentially with different, more updated values of x and y and perhaps return an error.<br><br>But beyond those 2 validations "-*?->" is pretty much undefined.<br><br>What I really want to define precisely in "-*?->" is how carol's gateway (CG from now on) communicates with TA2 and TB3.<br><br>TA2 and TB3 have some kind of plugin or extension to talk to CG and also CG can talk to them via rpc, cli or equivalent.<br>We can assume CG, TA2 and TB3 all run in the same machine or local network.<br><br>When TA2 receives a trampoline hop for which next's hop is a node in a list of sibling gateway nodes configured on init or in the relevant plugin:<br><br>1) TA2 gives the peeled trampoline onion to CG (including the relevant hmac) for it to process it and give an error back or:<br>2) CG gives the processed onion to TB3, which processes it even though it perceives it as a loss, for it trusts any message from CG<br>3) Any errors received by TB3 must be relied back to TA2 through CG, that's 2 new messages for this mini-protocol within "-*?->"<br><br>If everything goes well, I think TB3 needs to communicate one more time with TA2 through CG to pass the payment preimage.<br>But I'm not very sure about this part, I should re-read lightning-rfc more times.<br>If that's the case, there's 2 more messages here too (one from BT3 to TCG, another from CG to TX2).<br><br>I feel the best way to document this communication between CG, TA2 and TB3 is a UML sequence diagram.<br>I promise one if people want it. I just need to reinstall plantUML, but I won't do that today.<br><br>I hope people can find flaws on my assumptions or reasoning.<br>Or perhaps just add more detail to vaguely defined ideas.<br><br>Any form of feedback is welcomed.<br></div>