Broadcast featurebits

[ZmnSCPxj-jr]

Once we decide that the code is safe for more general use (i.e. no longer whitelist by default) advertising the use of peerswap would be good, so that peerswap-enabled peers can preferentially peer with each other.

I propose having 4 feature bits:

• I intend to request onchain-to-offchain Swap Ins.
• I intend to accept onchain-to-offchain Swap Ins.
• I intend to request offchain-to-onchain Swap Outs.
• I intend to accept offchain-to-onchain Swap Outs.

This allows nodes that intend to provide one kind of service to locate and peer with nodes that would like to utilize such a service, and vice versa.

This would also be helpful for forwardable peerswaps, as their utility increases the more hops you can forward a peerswap to, so having a tight-knit network that is mostly peerswap-enabled would allow for better flow across this part of the network. As forwardable peerswaps can only forward Swap In, forwarding nodes that want to keep as little onchain funds as possible can advertise only support for Swap In.

Since the meanings of the featurebits is only about intent, the peer protocol itself should ignore those bits, i.e. even if a peer does not broadcast an "I intend to request offchain-to-onchain Swap Outs", we should still accept swap_out_request if it makes sense for our balance and we have the onchain funds for it. The featurebits are only intended to guide autopilots to preferentially peer with nodes that need/provide the peerswap service we are interested in.

[nepet]

Please have a look at #5 where we already started a discussion about this.

[nepet]

Also I would like to propose to not put too many burdens to the ln gossip but rather have a feature bit that announces peerswap support in general and move any kind of negotiation, assets, features to a separate peerswap specific gossip (maybe we could use onion messages here?)

[ZmnSCPxj-jr]

Since peerswap is done with a direct peer that you need a direct LN0-level