Feature Request: Permissions to View Chain Balance

[zapomatic]

Hello,

Thanks for building PeerSwap, it's been amazing!

One thing I've noticed in using it with my collection of peers is that it would be great to be able to know what the L-BTC balance is on my allowed peer list prior to trying to swap out. I don't see the harm in exposing this to peers that are in the allow list because they can brute force the information anyway by attempting to make a swap out and getting denied until it works--and unfortunately for the UX, this is often necessary. At least, exposing enough that full channel liquidity is covered is something you could brute force--maybe you don't need to know that someone has 20 L-BTC on-chain, but knowing that they can support a 5M sat swap out would be amazing. So if privacy is a concern it could just show the balance up to the point that a swap out on that channel could consume--and maybe show_chain_balance=full | swappable could be a config option.

I've had a few channel partners where I've wanted to swap out 5M sats, and get State_SwapCanceled with insufficient walletbalance, then try 4M, same result, 3M, same result, 2M, same result. Then I realize it's not worth reducing the request size and give up, but it's created 4 failed transaction payloads in my listswaps output.

Counter to this request, I can see how it's useful to go through with the request so the recipient can be made aware of the demand for L-BTC that they don't have, but I think there could be a better way of probing for this. Ultimately, it would be ideal to see that they have no L-BTC, then initiate a special pscli request that allows them to know that there is need for it. This could potentially be worked into a telegram bot or other external fulfillment automation process as a pre-warming action to the requestor then attempting the swap.

[grubles]

I like the idea of having it as a config option. Also, I agree the UX of spamming swap requests until you hit an available amount is pretty poor.

[Impa10r]

I would also include advertising capacity for receiving Liquid. Both the scope of advertising (all | allow list | none) and the size of this capacity (min and max) should be configurable. Because currently the receiving peer also pays onchain fee for claiming.

[zapomatic]

Agree with @Impa10r --I'd like to be able to configure a Peer like so:

{
  // do not allow swap in requests
  allow_in: false, 

  // allow swap out requests
  allow_out: true, 

  // allow the peer to view info about chain balance: 
  // "none" hides LBTC availability
  // "full" reveals full L-BTC balance to this peer
  // "limit" only shows up to the amount that is swappable 
  // based on channel liquidity, or limit configuration, or available on chain, whichever is less
  balance_lbtc: "limit", 

  // see above
  balance_btc: "none" 

  // only allow up to 5M L-BTC sats to be swap out requested
  limit_out_lbtc: 5000000, 

  // only allow up to 5M BTC sats to be swap out requested 
  limit_out_btc: 5000000, 

  // only allow up to 5M L-BTC sats to be swap in requested 
  limit_in_lbtc: 5000000, 

  // only allow up to 5M BTC sats to be swap in requested 
  limit_in_btc: 5000000, 

  // limit requests: (1440 = one day)
  // number of minutes required to elapse after a successful swap 
  // before peer can initiate another swap
  request_limit: 1440 
}

I'm not particular to the key names or data structure but this is the rough idea of the things I'd like to be able to configure.

[zapomatic]

one more config option that would be super helpful. Let me know if you'd like these filed as different tickets.

{
   min_out_lbtc: 2000000,
   min_out_btc: 2000000,
   min_in_btc: 2000000,
   min_in_lbtc: 2000000,
}

Since doing smaller swaps like 1M and less has a potentially high PPM compared to other methods, a node might want to avoid allowing tiny swaps. Especially since the receiver has to pay the chain fee on swap in. At a shared cost of ~300-500 sats, a swap of 100,000 is equivalent in fees to a 3,000-5,000 PPM rebalance, so there's a cut off point at which the peerswap could be harmful.

[zapomatic]

Regarding these extra restriction options, I just realized this could be a big deal for adoption and sustainability of the ecosystem. Among a group of us that are connected and using peerswap, one realized that he could swap out to obtain LBTC + inbound liquidity, then create an invoice on their node and pay it using Bitfinex via an L-BTC payment. In this way, he is able to increase his inbound liquidity, and re-balance his highly valuable bfx lightning channel--at the expense of other nodes providing the inbound liquidity for pretty much free (and draining their inbound/outbound ratio).

This also could be solved by adding a service fee on top of the swap options--and it may be the only real solution since someone could still do this behavior at small scale.

I'd also like to be able to set a policy that someone cannot swap out unless their inbound fee to my node is 0 (meaning that they have attempted to allow free traffic to balance the channel already).

[Impa10r]

Yes, don't keep large LBTC balances on the node. Spend it to rebalance some channel or do the bfx refill as you described.

Devs are working on the swap premium feature.

You can come up with a script that marks a peer suspicious given certain conditions.

[Impa10r]

I suggest we start by adding ability to offer available BTC or Liquid balance directly to a selected peer (and remove such an offer by advertising 0). The peer will see these offers in pscli listpeers and PeerSwap Web UI. There is no limit how many offers you show, they are just informational. First come, first served.

I can try tackling this goal either:

1. In PeerSwap Web UI via direct Keysends.
2. As PR to PeerSwap using its existing messaging. This will take longer to implement (don't know peerswap), but can further add an option to refuse all out swaps which were not explicitly offered.

What do you guys prefer?