Receive Chain Swap: support refund even when lockup address is re-used #471
Conversation
ok300
force-pushed
the
ok300-receive-chain-swap-address-reuse
branch
2 times, most recently
from
f15df31
to
11c0adb
Compare
ok300
force-pushed
the
ok300-receive-chain-swap-address-reuse
branch
from
11c0adb
to
c25de91
Compare
ok300
changed the base branch from
ok300-yse-refund-loop-fix
to
yse-refund-loop-fix
hydra-yse
force-pushed
the
yse-refund-loop-fix
branch
2 times, most recently
from
9090ef9
to
c8de986
Compare
ok300
force-pushed
the
ok300-receive-chain-swap-address-reuse
branch
from
c25de91
to
d2eae3f
Compare
…coin operations" error" This reverts commit 8a325e3.
# Conflicts: # lib/core/src/chain_swap.rs # lib/core/src/model.rs # lib/core/src/sdk.rs # lib/core/src/swapper/boltz/bitcoin.rs
| info!("Successfully broadcast refund for incoming Chain Swap {id}, is_cooperative: {is_cooperative}"); | ||
|
|
||
| // After refund tx is broadcasted, set the payment state to `RefundPending`. This ensures: | ||
| // - the swap is not shown in `list-refundables` anymore |
There was a problem hiding this comment.
It's my understanding that this PR fixes that the refundable swap is no longer shown in list_refundables. I have two questions, after executing a refund:
- Is the payment shown with the refund_tx_id in
list_payments? - Is it possible to broadcast another tx to effectively bump the fee?
My concern is the swap is no longer refundable if broadcasting the refund with too low a fee
There was a problem hiding this comment.
Is the payment shown with the refund_tx_id in
list_payments?
Yes.
Is it possible to broadcast another tx to effectively bump the fee?
Only for cooperative refunds. The non-coop refunds don't have RBF enabled.
However there is no timeout after which cooperative refunds are impossible. The only way I could test non-cooperative refunds was by commenting out the coop refund call. Boltz participated in the coop refund even weeks after a swap failed.
My concern is the swap is no longer refundable if broadcasting the refund with too low a fee
From what I can tell, this can only happen if
- Boltz is not reachable for the coop refund and
- the user chooses a feerate that is too low
IMO this is unlikely because of the 1st point.
There was a problem hiding this comment.
Only for cooperative refunds. The non-coop refunds don't have RBF enabled
I tried on main branch to do this, but I get a "No UTXO found" error. Probably because the electrum script_list_unspent excludes them "Any output that is spent in the mempool does not appear"
Boltz participated in the coop refund even weeks after a swap failed
I think Boltz will always try to cooperate with a refund (always if the lockup failed or if the swap expired after they refund themselves). So it's more doomsday handling
Done, opened a separate issue: #539 |
# Conflicts: # cli/Cargo.lock # lib/Cargo.lock # lib/core/Cargo.toml
* commit 'a515718dc72c1c8eb62cecb7ad9c9862e8dc727c': feat: allow send transition from `TimedOut` to `Created` (#545) Propagate signer interface changes (#544) fix: double-lockup when payment is TimedOut (#541) Reserved address pool (#531) Prevent swap double claim (#542) Receive Chain Swap: support refund even when lockup address is re-used (#471) Bring remaining u32 amount types to u64 (#537) Add swift framework plists (#536) Update README.md Update README.md Update roadmap
Fixes #432