Swapout Charging 2x Fees? - Please I need to Understand what happened.

[jvxis]

Hi, I did a BTC Swapout with a Peer:
Our channel has more than 5M of outbound liquidity.

ID: 7ba0b4122bb3a9f5e35ac714d89104501fecfa588f354fd2cf4e1515df6ac75a Created At: 2024-01-05 06:47:39 Asset: btc Type: swap-out Role: sender State: State_SwapOutSender_AwaitTxConfirmation Initiator Node ID: Friendspool⚡🍻 | 023e24602891c28a7872ea1ad5c1bb41abe4206ae1599bb981e3278a121e7895d6 Peer Node ID: Tiger 🐯 | 038607b58550d272ce8a058b77bc7a00e099687531359074bb600477f6bb7d1764 Amount: 2000000 Channel ID: 811731:986:0 Opening TX ID: https://mempool.space/tx/2f1376f69e753258eeb3832c9a228cca59cd5b9a4b0b656ebdd6778bddca0da8 Claim TX ID: Cancel Message: LND Channel ID: 892507673190858752

Then the code sent this to him.
⚡️ Sent 17,848 to Tiger 🐯 out Tiger 🐯 - Friendspool⚡🍻 023e2460

First question: what is this amount? Is it a service fee? If it is, how do I set it?

The peer received:
💵 Received 17.848 for “peerswap btc fee 811731x986x0 7ba0b4122bb3a9f5e35ac714d89104501fecfa588f354fd2cf4e1515df6ac75a” via Friendspool⚡🍻

And then sent:
⛓ (pending) Sent 2.007.985. Paid 7.985 fee. Sent to bc1qaneettmxu5ydrrcf0x6jy33efckdyfay08jxvj, bc1qr2saufdfz92pq62pxf3xtqdhqtqzudnlmg9a7mhsdyqzste6fyhsj68plf

Then I received:
⛓ Received 1,991,494

And Paid:
⚡️ Sent 2,000,000 to Tiger 🐯 out Tiger 🐯 - Friendspool⚡🍻 023e2460

Second question: If my peer sent 2,007,985 and I received 1,991,494, on-chain fees were charged twice? Why?

Please help me to understand what happened.

Thanks
JVX

[emtll]

As you can see, the previously paid invoice guarantees that Tiger will not suffer losses due to onchain fees, if you do not pay the lightning invoice, as there are two transactions, the first onchain transaction goes to an intermediate address and awaits payment of the invoice that will generate a pre image that will release the last transaction, which is the claim tx, which goes to your onchain wallet.

As it happens, our fellow initiator will pay the fees onchain, receive the value he set deducted onchain and will also pay the full lightning incoive.

In the case described he paid 2,017,848 sats while he only received 1,991,494, a cost of 26,354 sats for Friendspool alone.

Meanwhile, the Tiger received 2,017,848 sats via lightning. After deducting onchain fees, the final balance was left with 2,000,000 sats.

In other words, Tiger had no costs in the operation while FriendsPool covered all the costs.

I don't think this is wrong since the initiator was Friends. But I see the same charging behavior when the initiator makes a swapin request, where the remote peer will bear the costs alone, which I don't think is fair.

PROPOSAL TO DEVS:

After the operation ends and by the confirming the claim tx, an invoice will be generated with half the costs for the other Peer to pay, in this case, Tiger.

Thus balancing the costs of this entire operation half to half.

For example: FriendsPool paid 17,848 sats at the beginning. At the end of the transaction he could receive back from Tiger via invoice: 8,924 sats and thus they would be sharing the costs. But of course Friends would still cost more than 17k at the end of it all.

[zapomatic]

There certainly seems to be something off with the math on these...

It might be worth not initiating btc swaps until this is resolved or cleared up if you don't want to excessively tip the recipient for access to their on-chain funds. And I'm not sure if this problem exists on swap in causing the recipient to over pay so it might be worth setting bitcoinswaps=false in the config until this is researched more. With the lbtc swaps it seems the pre-payment is only over the initial txn fee by something like ~45 sats, which I can consider a fine tip/service fee for taking the lbtc that the other party had to peg in to create, but in the btc case, it looks like the prepayment overpays for the opening_tx by over double.

Friends sent Tiger 17,848 to cover both of the on-chain transactions.
The first on-chain txn is the contract: https://mempool.space/tx/2f1376f69e753258eeb3832c9a228cca59cd5b9a4b0b656ebdd6778bddca0da8
which Tiger's node spent 7,985 sats to process.

Then there was a followup txn that actually moved the on-chain funds to Friends: https://mempool.space/tx/594dd479bac5a88bd92d522379c16b505b3c9cb11b24ecff1ebdc3670c552b65

But, the fee for the second transaction came out of the 2M sats going to Friends so Friends did end up paying for that txn too, which they should have--the issue is that the original txn was overpaid by so much that it looks like it should have covered both chain txn fees (and then some).

So Tiger received 17,848 sats on LN, sent 2M + 7,985 sats on-chain, then received 2M sats via LN, which means Tiger ended up with .02017848 - .00007985 = 2,009,863 sats in the end, an extra 9,863 sats (tip?).

And Friends paid 17,848 LN sats up front + 2M LN sats later and ended up with
1,991,494 sats on chain, which means Friends actually ended up with 1,991,494 - 17,848 = 1,973,646 so Friends really paid 26,354 sats in the end for the whole process, 9,863 of which was excess paid to Tiger by miscalculating the starting tx cost.

So there is something buggy with the fee that gets sent over for the opening txn. If this is a condition that can't be reliably fixed, then maybe the solution is to add a followup HTLC on LN to resolve the overage paid by the initiator. Unless this is just considered a tip...

[wtogami]

(I did not read the above carefully, I am mentioning a possibly related design goal that might explain.)

Design Goal: The swapout prepayment was never meant to be exactly what the other side pays for the onchain commitment transaction. IIRC it's calculated with the assumption of 3 inputs and 2 outputs because for privacy reasons you can't tell the other side which UTXO's you have available prior to the swap. The swap requestor is intended to pay ON THE AVERAGE more than the acceptor's onchain costs so in theory the automated acceptance side is at least not made worse off.

It's possible this design goal failed?

Reality is with recent high fee rates bitcoinswaps=false should probably be used by everyone as the onchain environment is too chaotic and expensive.