swaps: Announce available liquidity instead of static maximum value

[f321x]

Makes swap provider announce the actual available liquidity for forward and reverse swaps instead of a static hardcoded max value. This should increase reliability of swaps as clients will know upfront if the provider even has enough liquidity to fulfill their request.

[accumulator]

using the exact onchain balance as available liquidity might pose a privacy risk, as it might correlate UTXOs to the swap provider without initiating a swap (passive observers)

[f321x]

In server_update_pairs() i round down to the next 1000 sat:

        oc_balance = sum([coin.value_sats() for coin in self.wallet.get_spendable_coins()])
        max_forward = min(int(self.lnworker.num_sats_can_receive()), oc_balance, 10000000)
        max_reverse = min(int(self.lnworker.num_sats_can_send()), 10000000)
        self._max_forward = (max_forward // 1000) * 1000
        self._max_reverse = (max_reverse // 1000) * 1000

e.g. changing 984323 to 984000. We could also randomly round down in a specified range... Let me know if you have any more ideas how we could improve privacy for providers without reducing functionality.

[accumulator]

Maybe zero out after 1 or 2 significant numbers, e.g. 984323 -> 900000 or 980000

Also, maybe there's also a case to be made to offer at most 50% of available balance, to be able to service 2 clients if balance is below 10Msat cutoff point.

Maybe the anchors UTXO reserve also should be taken into account? (haven't checked)

[f321x]

I changed it to reduce the precision of the announced amounts to 2 leading digits, and deduct the anchor reserve, if required, when calculating the available onchain amount.

Also, maybe there's also a case to be made to offer at most 50% of available balance, to be able to service 2 clients if balance is below 10Msat cutoff point.

I'm not sure how this improves the usability, the provider announces the new liquidity as soon as it changed, so the other clients see what is still available. I imagine it could prevent one rejected swap if two clients request a swap > 50% of the available liquidity at the same time (which should happen rarely), but at the same time it would also prevent clients from requesting swaps > 50% even if the provider could satisfy the swap easily (which probably happens more often in practice).

[accumulator]

I'm not sure how this improves the usability, the provider announces the new liquidity as soon as it changed, so the other clients see what is still available. I imagine it could prevent one rejected swap if two clients request a swap > 50% of the available liquidity at the same time (which should happen rarely), but at the same time it would also prevent clients from requesting swaps > 50% even if the provider could satisfy the swap easily (which probably happens more often in practice).

Yeah I agree it's probably not that useful. The thinking was, as the available liquidity is fetched once before entering the swap dialog, there might be a liquidity reduction in the time between liquidity info fetch and doing the actual swap (it's not live-updated)..