This diff introduces a new "approvals" mechanism that alters the swap flow by requiring explicit user intervention before the Bitcoin lock transaction is broadcast. Previously, the Bitcoin lock was executed automatically without any user prompt. Now, the backend defines `ApprovalRequestType` (e.g. a `PreBtcLock` variant with details like `btc_lock_amount`, `btc_network_fee`, and `xmr_receive_amount`) and `ApprovalEvent` (with statuses such as `Pending`, `Resolved`, and `Rejected`). The method `request_approval()` in the `TauriHandle` struct uses a oneshot channel and concurrent timeout handling via `tokio::select!` to wait for the user's decision. Based on the outcome—explicit approval or timeout/rejection—the approval event is emitted through the `emit_approval()` helper, thereby gating the subsequent broadcast of the Bitcoin lock transaction.
On the UI side, changes have been made to reflect the new flow; the modal (for example, in `SwapSetupInflightPage.tsx`) now displays the swap details along with explicit action buttons that call `resolveApproval()` via RPC when clicked. The Redux store, selectors, and hooks like `usePendingPreBtcLockApproval()` have been updated to track and display these approval events. As a result, the overall functionality now requires the user to explicitly approve the swap offer before proceeding, ensuring they are aware of the swap's key parameters and that the locking of funds occurs only after their confirmation.
* cli: log the reason we can't find tx_cancel
When we can't find tx_cancel even though the cancel timelock
expired, we publish it ourselves.
However, some users had a problem where the tx_cancel wasn't
found even though it was already published.
This leads to the cli getting stuck in `CancelTimelockExpired`
when it should go to `BtcCancelled`.
This commit introduces an additional log statement that will
help us narrow down why that is.
* gui: update the documentation icon
Occasionally our ci jobs would fail due to network errors.
This is a known issue which is worked around by disabling
http multiplexing, for now. Hopefully.
There was an issue before we were falsely applying a default node to use and not actually iterating through our list and checking for availiability. This commit fixes this issue and removes a few dead nodes.
This pull requests
- Adds rust native support for the `asb` to listen on an onion service. Previously we were depedent on a seperately running `torc` client. Instead we now use [arti](https://tpo.pages.torproject.net/core/arti/), a rust implementation of the tor protocol.
- Removes the `tor.control_port` and `tor.socks5_port` property from the config of the `asb`
- Adds a new `tor.register_hidden_service` boolean property to the config of the `asb` which when enabled automatically runs a hidden service at startup
- Adds a new `tor.hidden_service_num_intro_points` config property to specify how many introduction points to register the onion service at
- Adds support for the `cli` to dial onion addresses
This is dependent on https://github.com/umgefahren/libp2p-tor/pull/24
Closes https://github.com/UnstoppableSwap/core/issues/16
