Gossip

[nepet]

As we already discussed on discord we need to have a way to explore PeerSwap enabled nodes.

Why

In order to utilize PeerSwap, a node operator needs a way to find other PeerSwap enabled nodes in the network. We want to explore the network but we also do not want to extend the gossip bolt#07 as PeerSwap does not need to touch any other bolt and can be run as a plugin on top of the lightning network.

How

Here is an Idea I'd like to share - contains some things we already talked about, lets just save this here:

We set a feature bit, as described in bolt#9 in the node_announcement message. This way we could utilize the gossip to explore nodes that announced that they support the PeerSwap protocol.

We now could connect to every node that has the PeerSwap enabled flag set but we might not want to. We rather would like to only connect to nodes of certain interest, e.g. nodes that have good rates or that support assets we are interested in.

Therefore we need a custom message protocol that allows for communication outside of the bolts. This could be done quite simple with a PeerSwap gossip port that listens for incoming (signed) queries and returns a signed message to the requester containing more swap info.

Please share your thoughts, ideas and suggestions.

[remyers]

PeerSwap nodes could exchange queries with each other via Onion Messages. This has the advantage of not requiring a new port and reuses functionality that should soon be implemented by most nodes.

Using Onion Messages would also allow private queries between nodes that might otherwise communicate via Tor or some other alternate transport system.

[remyers]

I'm going to use the feature bits 158/159 in my plugin for testing purposes. I'm not aware of anyone currently using these feature bits. Official features bits are in a lower range so I think this should be safe.

[ZmnSCPxj-jr]

I would propose four featurebits:

• I intend to request onchain-to-offchain Swap In.
• I intend to accept onchain-to-offchain Swap In.
• I intend to request offchain-to-onchain Swap Out.
• I intend to accept offchain-to-onchain Swap Out.

This lets those who intend to use or provide particular kinds of swap to preferentially peer with the correct type.

Having fees for peerswap would be problematic for forwardable peerswaps. It would not be possible to just forward a peerswap if fees are involved, a forwarder would have to check if the planned next hop requires a higher fee that what it itself advertises. If the planned next hop requires a higher fee for peerswaps, then the forwarder either cannot use that next hop, or must effectively pay for the rebalancing.

The reason why forwardable peerswaps is compelling is that it offers forwarding nodes an opportunity to rebalance without paying out a rebalancing fee. If peerswaps involved a swap fee, then a forwarding node must advertise the highest of what its peers advertise so it can forward to those peers. If the forwarding node ends up swallowing the difference in fee from what it advertises to what its next hop advertises, then it is not an advantage compared to self-paying rebalances, and self-paying rebalances will remain the dominant strategy for profiteering forwarding nodes. We want to change the network incentives to make self-paying rebalances less dominant on the network, that is even mentioned in the peerswap.dev page, so I implore you to reconsider adding fees to peerswap.

An alternative would be to just pay for the onchain action of operating the onchain HTLC. The initiator (whoever sends swap_in_request or swap_out_request) provides its intended onchain feerate. Then the responder determines if the intended onchain feerate is reasonable. This allows forwarders to also forward the exact same onchain feerate query to the planned next hop. If the negotiation is OK, then the only fee paid is to offset the onchain fees involved in the onchain HTLC. The ultimate acceptor (i.e. the one that does not forward the peerswap) does not earn extra fees, but does get more inbound capacity, which is just as good, because the sats must flow.

In short, maybe instead of advertising feerates, should instead consider negotiating feerates, because negotiation works with forwarding, advertising does not (i.e. if you intend to forward, what do you advertise?).