-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support address re-use in Receive Chain Swap #432
Comments
This should be correct, as the additionally sent BTC amount needs to be refunded back to the sender using |
Don't we also need the matching Boltz status for a swap to be actually refundable?
The Boltz status is |
@ok300 why do we care about the swapper status here? If we know use added more funds to that address then it seems right to me to mark it as refundable. Where do you see an issue here? |
True, we don't need it. I thought we need the swapper status to agree with our status (refundable), but the refund doesn't need interaction as we can build the refund tx ourselves. Then the key question is: do we support address re-use? If yes:
|
I think the important items here are:
I am not sure if we need atm to change the refund_tx_id field to be a vector as we can define it as the last_refund_tx_id (unless it has a bad affect on our logic) |
I ran some tests and have two questions:
then non-cooperative Q: Is this desired behavior?
/// Number of blocks to monitor a swap after its timeout block height
pub const CHAIN_SWAP_MONITORING_PERIOD_BITCOIN_BLOCKS: u32 = 4320; This means if address re-use happens after this time (30 days), we will not pick it up. Q: should I remove this and instead let it monitor chain swaps forever? |
It is the only option. non-cooperative refund can't work within the lock height range.
It is a tradeoff so we won't get into performance issues. Users can use the rescan_swaps themselves in that cases (or periodically). |
Forgot to mention: this also means In normal cases (no address re-use), refundable swaps are shown in
So it is correct (and the only possible way) that I will document this in the docs.
|
Short update: Testing the situation above (address re-use + attempt refund after lock height timeout) I found that:
|
Scenario:
transaction.claimed
(the final status from the initial completed swap)Refundable
Example instance: testnet swap
7u5RFB8HQNdp
tb1pnvkd06a3q7e45pdtkyz4x3kdhnkarxespnz8uwsf7386kt2x2kpsqxaku7
( open in mempool explorer )On SDK startup:
The text was updated successfully, but these errors were encountered: