Swap failed while Waiting for Alice to lock Monero #688
Comments
This comment has been minimized.
This comment has been minimized.
|
Thanks for the report. At the moment, there isn't any functionality for a cooperative release of funds. It is an interesting idea, so I am going to open a separate issue for it! As for the other issue, I am not exactly sure what is going wrong. For some reason, we seem to try to broadcast to early, which is something we actually guard against ... Can you share those debug logs? |
|
Hi @thomaseizinger, thanks for the response, and setting up the issue #693 I am surprised that there is no current way for Bob to retrieve the locked XMR after Alice has punished and retrieved the BTC. May I ask why this is not standard to the protocol? Correct me if I am wrong, but those XMR are essentially burnt and will sit in the swap tool address for the rest of time? And in a future where a manual release may be possible, what if Alice doesn't contact Bob or want to cooperatively release the locked XMR funds? Is Bob doomed to lose the BTC after the ASB automatically punishes after the 72 block timeframe? I realize we should probably continue this conversation on the issue #693 you created, as the above may be off topic. And yes, I will post my debug logs as soon as have access to the pc I was running the swap tool on. And @kareldonk, as much I do appreciate you sympathizing with me and championing my issue here, I'd also really appreciate your civility in working with the devs so we can all come to a solution, or change to the protocol, that works for everyone. |
|
@thomaseizinger, Here is the .log text for the Swap ID that went wrong. Please let me know if you need more info: Aug 23 18:49:47.283 DEBUG Opening database at /home/XXXX/.local/share/xmr-btc-swap/cli/mainnet/database |
rishflab
added
bug
Yes, this is due to Monero not having any timelocks. From the protocol perspective, Bob (the user) may be malicious and never claim the XMR. Without claiming the XMR, Alice can never retrieve the BTC. As a result, she is allowed to claim the BTC funds after another 72 block time window. Swap protocols are time-sensitive. As long as both parties are online and act within a certain time frame, no funds are lost. If one party just disappears either willingly or unwillingly, certain spending paths must become possible otherwise the incentives in the protocol don't work out. That is unfortunately the nature of non-custodial and trustless protocols like these.
They don't sit in the tool. They sit in a multi-sig on the chain and can only be claimed through collaboration by both parties. Normal execution of the swap is essentially this collaboration.
It may be possible but has to be thought through properly, I've opened a discussion here: #713 |
|
Addressed in linked PR |
|
I'm having this bug as well. What is a ballpark timeframe for Alice to lock Monero? 🤓 |
Hi All,
I initiated a swap for 0.03 BTC (with the funds already in the internal wallet of the swap tool from a previously cancelled swap) and it failed as shown in the code at the bottom of this post.
The terminal was stuck on "Waiting for Alice to lock Monero" for a few hours before I went to sleep. Upon waking in the morning, I saw that the swap had failed/been cancelled as "Alice took too long to lock Monero." The ASB had punished me and took the 0.03 BTC sometime during the night as well. Afaik there was not break in my internet connection during this time.
Fortunately, I was contacted by the ASB operator that I initiated the swap with, and they were kind enough to let me know that there was no malicious intent behind the automatic punish and would like to see me get the XMR funds.
However they are also at a loss as to how I can recover my XMR funds as this situation has not happened to them before. According to them, the XMR are locked in the swap tool and need to be somehow be manually released to my XMR wallet. Would this manual release be accomplished from the trader or ASB side? Thank you for any help you can provide to either of us.
Terminal:
The text was updated successfully, but these errors were encountered: