Loop Out amount precision

[kornpow]

One of the largest barriers/sources of friction for people to use Loop Out for on-chain payments, is the lack of precision in setting the target UTXO size.

Merchant Invoice: 1000000 sats
loop out --amt=1000000 --addr={merchant address} --fast

This results in a transaction "TXswap" in the mempool like so:
UXTO1 (swap): 1000000 sat
UTXO2 (loops change): ??? sat

Once TXswap has confirmed, loopd will sweep UTXO1 in another transaction:
UTXO3 (payment): 999500 sat

Because of the fee, the end result is slightly underpaying the merchant invoice. This usually requires hours of back and forth, and waiting for a refund and trying again. Most likely just on-chain this time around...

I don't know if is feasible to add a --sweep_fee_sats flag, where I can specify I want the sweep to be 1000 sats, and then I'll just increase my total payment by 1000 sat. Or if it makes more sense just automatically increase the initial payment, to account for the sweep fee.

Loop out already gives some friction, by requiring 1-2 blocks to go by before the final TX is broadcast. This gives headaches for BitPay, and also CoinKite stores, which gives a timeout for when it expects the transaction to be broadcasted. At least if we can make the output payment amounts correct, we'd be getting closer to the feeling that BTC is "unlocked" in a channel instead of "locked" in a channel.
Thanks!

[alexbosworth]

This is possible with some provisos

The complicating factor is that you would need to potentially raise the fee of your swap if it's taking too long to confirm, and where do those funds come from? We normally take the funds from the swap itself to raise the on-chain fee.

One possible solution is to make the 2nd transaction pay to two addresses: the address you want to pay to, and then an additional change address. If the fee needs to be raised, then the requisite increase funds may simply be reduced from the change address output.

[kornpow]

I'd be happy with the second transaction paying to 2 addresses, only downside is you now have on-chain funds you dont want.

Or if it's be possible to ask for a small additional off-chain payment, similar to the pre-payment.

[alexbosworth]

I'd be happy with the second transaction paying to 2 addresses, only downside is you now have on-chain funds you dont want.

Or if it's be possible to ask for a small additional off-chain payment, similar to the pre-payment.

You could Loop In the excess if that's what you mean

[kornpow]

I considered that too, definitely an option, but the minimum loop in is like 250k sats, which is much higher than a typical chain fee.

[alexbosworth]

I considered that too, definitely an option, but the minimum loop in is like 250k sats, which is much higher than a typical chain fee.

Yeah although that could conceivably be adjusted lower as well

[joostjager]

Second output which is a change address looks like the smallest change. So on initiation of the swap, you'd need to specify two amounts: the exact amount to eventually pay out and the swap amount, which needs to be higher. The difference between the two is the maximum expected chain fee.

Would you prefer to specify the swap amount manually or let it be calculated automatically based on a fee estimate?

The workaround for all of this is of course to do a third transaction. So

1. off-chain payment -> on-chain htlc
2. on-chain htlc -> on-chain wallet address
3. on-chain wallet address -> on-chain external address

If 3 uses the unconfirmed output of 2, the duration of the whole process shouldn't be different from using a change address. It is slightly more expensive with one additional input though.

What is the main reason that makes the workaround less attractive? Is it the additional cost or the inconvenience of executing another step?

[kornpow]

Mostly the inconvenience. When doing a loop out for an on-chain payment, I already know that it is 2-3 blocks away before the final transaction is published. I don't want to wait around an hour, and then finally then send the on-chain payment.

1st Preference: If on-chain fee bumping is required, obtain that fee in another off-chain payment. This way we aren't creating small unwanted UTXOs.

2nd Preference: Create swap with a max on-chain fee, and a base on-chain fee. Create two UTXOs from the swap, one a payment, one change. Potentially lower loop-in minimums, so we can eliminate unwanted on-chain UTXOs.

[joostjager]

1st Preference: If on-chain fee bumping is required, obtain that fee in another off-chain payment. This way we aren't creating small unwanted UTXOs.

The sweeping of the htlc is entirely your process. So there is no-one to pay that off-chain bump amount too, or how did you envision this?

[kornpow]

That makes sense.

Since that is the case, I want the sweep amt to equal to my "payment", and the fee to be a fixed number of sat/byte, therefore knowable at the start of the swap.

1. Client: swap: AMT=1100000 sats (overpayment by x %)
2. Server: htlc publish: AMT=(1000000 sats + 3 sat/byte fee) OUT1 on-chain htlc (fee bumped until it makes into the chain)
3. Client: Request Refund: Refund User (1100000-(1000000 + 3 sat/byte fee) - HTLC chain fee - prepayment)
4. Client: Sweep Payment: 1000000 sats + 3 sat/byte fee
5. Server: Complete Refund

This is just an idea, still getting my head around the constraints we are dealing with here.

[githorray]

bos already has a feature that does this if you want to see it in action.

bos increase-inbound-liquidity --spend-address <address> --spend-amount <amount>

https://github.com/alexbosworth/balanceofsatoshis/blob/e822c64ba9cb3b83f4d6896ab6e3f1a1ff4b8018/bos#L608