Good morning list, I saw elsewhere that there are plans to move peerswap to *two* hops, but no further, as reliability is a concern.
The logic behind allowing up to two hops distance is that the two endpoints know the state of the channels to the intermediate node. But we should also consider that the intermediate node itself also knows the state of those channels. Along every intermediate node on the forwardable peerswap path, every intermediate node knows the state of its incoming channel and its outgoing channel. Presumably, we can write smart programs that can automatically select an outgoing channel that: * Would really appreciate the adjustment in channel balance. * Is with a peer with high uptime. Thus, while there is a degradation in expected reliability compared to a single-hop case, we expect the degradation to be small. Remember, the intermediate nodes in a forwardable peerswap are all incentivized for the swap to succeed, because it gets two channels improved balance ***for free***, whereas self-paying reblances have a cost. We can expect that the intermediate nodes have an incentive to ensure the swap succeeds, just as we expect that the intermediate nodes have an incentive to ensure that any payment succeeds. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
