payment to 1/p2pkh address should account for fees

[nicolasburtey]

trafficstars

I've made a payment using loop out to a 1 address. The merchant was supposed to received X amount of sats, but instead loop out sent X - on chain fees. This result in the creation of a ticket as the merchant server didn't automatically reconcile the payment because the amount he received was different.

It might work differently with 3 or bc1 addresses and the problem might not be present in those cases?

[alexbosworth]

There should be no difference in the final sweep output address, but the swap on-chain fee deduction amount is not so deterministic so this feature would require a solution where the output could be swapped for another if the fee didn't come out as expected

[alexbosworth]

@nicolasburtey for this feature it could be implemented one of two ways, curious which you would prefer:

There is a problem where chain-fees may need to be raised during the Loop Out, which could disrupt the amount sent to the external address.

1. If the fees do need to be raised during the Loop, the Loop Out funds could return back to your own wallet instead of the address you specified
2. You could over-fund the Loop Out and have a secondary output to your own wallet, the amount of which would then be reduced in the case that there were a chain-fee raise

Which would you prefer?

[nicolasburtey]

I would prefer to avoid a secondary output that could be close to the dust limit. If I could be paid back of the overpaid fees on lightning I feel this what would make the most sense.

[alexbosworth]

You could always Loop In the secondary output if it existed and dust can't really go on chain too easily but maybe there could still be some too-small to loop in annoying UTXOs if the secondary output were too small

So the implication of funds returning off-chain would result in a larger secondary output