Commit Graph

96 Commits

Author SHA1 Message Date
binarybaron
d8dacbdee9
Monero wallet refresh fix (#1487)
* Upgrade monero-wallet-rpc to `v0.18.3.1`

* Give feedback to user about state of monero refresh and retry if fails

This commit changes the following behaviour in the refresh functionality of the monero wallet
- Allows for multiple retries because in some cases users have experienced an issue where the wallet rpc returns `no connection to daemon` even though the daemon is available. I'm not 100% sure why this happens but retrying often fixes the issue
- Attempt to print the current sync height while the wallet is syncing. This only works to some degree because the `monero-wallet-rpc` stops responding (or takes a long time to respond) while it's refreshing
- The `monero-wallet-rpc` is started with the `--no-initial-sync` flag which ensures that as soon as it's started, it's ready to respond to requests
---------

Co-authored-by: Byron Hambly <bhambly@blockstream.com>
Co-authored-by: Byron Hambly <byron@hambly.dev>
2024-03-25 15:08:54 +01:00
Byron Hambly
fb42ca13cc
chore: clippy fix 2022-10-19 15:02:46 +02:00
binarybaron
3660a08b96 Inform Bob that he has been punished 2022-04-13 16:17:52 +02:00
Daniel Karzel
a9b10717ba
Record the monero-wallet-restore blockcheight before locking BTC
This solves issues where the CLI went offline after sending the BTC transaction, and the monero wallet restore blockheight being recorded after Alice locked the Monero, resulting in the generated XMR redeem wallet not detecting the transaction and reporting `No unlocked balance in the specified account`.
2021-12-23 10:12:23 +11:00
rishflab
da9d09aa5e Create Database trait
Use domain types in database API to prevent leaking of database types.
This trait will allow us to smoothly introduce the sqlite database.
2021-09-30 18:56:52 +10:00
rishflab
3ba1ed2bcb Change message log level to debug to allow enabling through flag
We do not have a way to enable tracing through a command line
argument so it did not make sense to have these messages set to
trace. Ideally a trace flag should be added but it is not that
straightforward with structopt. We could add a --log-level arg
that allows you select a log level but this is verbose.
2021-09-11 22:17:32 +10:00
rishflab
0afe83e4e8 Move "swap started" UI message after swap confirmed with ASB
The "swap started" message was being too early, before the ASB had
confirmed they could perform the swap. This was leading to a confusing
scenario where the UI incorrectly indicated to the user that the swap
had started. Users were trying to resume or refund the swaps but there
was no swap id in the db. Moving this message after the swap setup
should resolve this problem. Closes #756, #729, #560.
2021-09-09 16:58:17 +10:00
rishflab
ce58b8b333 Handle errors when waiting for subscriptions
We were not thorough enough in PR #705 and there were some remaining
unhandled errors.

Co-authored-by: Daniel Karzel <daniel@comit.network>
2021-09-02 14:23:41 +10:00
rishflab
af50c655ae Remove timeout on send encrypted signature
Bob was timing out if the encrypted signature could not be sent in 60
seconds. This behaviour is unnecessary because we are racing against
the cancel timelock anyway. By timing out before this, we remove the
opportunity for bob and alice to re-establish a connection.
2021-08-31 18:26:03 +10:00
Daniel Karzel
18faa786d6 Fail if something goes wrong when checking tx lock status
Probably a failure when interacting with the electrum node to get script
 status updates
2021-08-31 18:26:00 +10:00
Thomas Eizinger
8f50eb2f34
Utilize tracing's fields more 2021-07-07 16:02:02 +10:00
Thomas Eizinger
9119ce5cc4
Tidy up log messages across the codebase
1. Clearly separate the log messages from any fields that are
captured. The log message itself should be meaningful because it
depends on the underlying formatter, how/if the fields are displayed.
2. Some log messages had very little context, expand that.
3. Wording of errors was inconsistent, hopefully all errors should
now start with `Failed to ...`.
4. Some log messages were duplicated across multiple layers (like opening
the database).
5. Some log messages were split into two where one part is now an `error!`
and the 2nd part is an `info!` on what is happening next.
6. Where appropriate, punctuation has been removed to not interrupt
the reader's flow.
2021-07-07 16:02:00 +10:00
Thomas Eizinger
5463bde4f8
Add a mandatory --change-address parameter to buy-xmr
Fixes #513.
2021-07-06 20:07:53 +10:00
Thomas Eizinger
683d565679
Make variable naming consistent 2021-07-06 20:06:41 +10:00
Daniel Karzel
c0070f8fa7
Move files from protocol to appropriate module
Some network and application specific code does not belong in the protocol module and was moved.
Eventloop, recovery and the outside behaviour were moved to the respective application module because they are application specific.

The `swap_setup` was moved into the network module because upon change both sides will have to be changed and should thus stay close together.
2021-06-28 10:04:08 +10:00
Daniel Karzel
818147a629
swap_setup instead of spot_price and execution_setup
Having `spot_price` and `execution_setup` as separate protocols did not bring any advantages, but was problematic because we had to ensure that `execution_setup` would be triggered after `spot_price`. Because of this dependency it is better to combine the protocols into one.

Combining the protocols also allows a refactoring to get rid of the `libp2p-async-await` dependency.

Alice always listens for the `swap_setup` protocol. When Bob opens a substream on that protocol the spot price is communicated, and then all execution setup messages (swap-id and signature exchange).
2021-06-28 10:04:07 +10:00
Daniel Karzel
fb9fb21c2b
CLI log statements to be more JSON friendly
Values to be logged as fields.
Upon starting a swap we print the swap-id as well.
2021-05-21 15:00:31 +10:00
Philipp Hoenisch
dc8dd5af28
Add relative and absolute max transaction fee. 2021-05-07 10:24:41 +10:00
Philipp Hoenisch
dc6ab0fa52
Ensure that constant weights do not go out of sync with code. 2021-05-07 10:24:41 +10:00
Philipp Hoenisch
9e8b788aa9
Rename weight constants. 2021-05-07 10:24:41 +10:00
Philipp Hoenisch
ee90c228b4
Dynamically calculate fees using electrum's estimate_fee.
Electrum has an estimate-fee feature which takes as input the block you want a tx to be included.
The result is a recommendation of BTC/vbyte.
Using this recommendation and the knowledge about the size of our transactions we compute an appropriate fee.
The size of the transactions were taken from real transactions as published on bitcoin testnet.
Note: in reality these sizes might fluctuate a bit but not for much.
2021-05-07 10:24:41 +10:00
Philipp Hoenisch
38540b4de5
Dynamically chose fee for TxCancel.
Bob chooses the fee for TxCancel because he is the one that cares.
2021-05-07 10:24:41 +10:00
Philipp Hoenisch
1012e39527
Dynamically chose fee for TxRefund and TxPunish.
Alice chooses the fee for TxPunish because she is the one that cares.
Bob chooses the fee for TxRefund because he is the one that cares.

Note must be taken here because if the fee is too low (e.g. < min tx fee) then she might not be able to publish TxRedeem at all.
2021-05-07 10:24:41 +10:00
Thomas Eizinger
e266fb07ef
Don't stutter 2021-04-26 12:45:39 +10:00
Thomas Eizinger
6d06db3259
Use macro-based JSON-RPC client 2021-04-26 12:45:35 +10:00
bors[bot]
19766b9759
Merge #405
405: Concurrent swaps with same peer r=da-kami a=da-kami

Fixes #367 

- [x] Concurrent swaps with same peer

Not sure how much more time I should invest into this. We could just merge the current state and then do improvements on top...?

Improvements:

- [x] Think `// TODO: Remove unnecessary swap-id check` through and remove it
- [x] Add concurrent swap test, multiple swaps with same Bob
- [ ] Save swap messages without matching swap in execution in the database
- [ ] Assert the balances in the new concurrent swap tests
- [ ] ~~Add concurrent swap test, multiple swaps with different Bobs~~
- [ ] ~~Send swap-id in separate message, not on top of `Message0`~~

Co-authored-by: Daniel Karzel <daniel@comit.network>
2021-04-13 08:50:44 +00:00
Daniel Karzel
c976358c37
Multiple swaps with the same peer
- Swap-id is exchanged during execution setup. CLI (Bob) sends the swap-id to be used in his first message.
- Transfer poof and encryption signature messages include the swap-id so it can be properly associated with the correct swap.
- ASB: Encryption signatures are associated with swaps by swap-id, not peer-id.
- ASB: Transfer proofs are still associated to peer-ids (because they have to be sent to the respective peer), but the ASB can buffer multiple
- CLI: Incoming transfer proofs are checked for matching swap-id. If a transfer proof with a different swap-id than the current executing swap is received it will be ignored. We can change this to saving into the database.

Includes concurrent swap tests with the same Bob.

- One test that pauses and starts an additional swap after the transfer proof was received. Results in both swaps being redeemed after resuming the first swap.
- One test that pauses and starts an additional swap before the transfer proof is sent (just after BTC locked). Results in the second swap redeeming and the first swap being refunded (because the transfer proof on Bob's side is lost). Once we store transfer proofs that we receive during executing a different swap into the database both swaps should redeem.

Note that the monero harness was adapted to allow creating wallets with multiple outputs, which is needed for Alice.
2021-04-13 18:16:19 +10:00
Daniel Karzel
489696ee08
Swap-id as file name for generated Monero wallet
Instead of using the private view-key as wallet filename we use the swap-id, to be able to identify which wallet is associated with which swap.
2021-04-08 19:23:54 +10:00
Daniel Karzel
548f057726
Try to open wallet in case generate_from_keys fails 2021-04-08 19:15:30 +10:00
Thomas Eizinger
5d75f1adba
Remove import line in favor of FQ macro usage 2021-04-01 17:08:26 +11:00
Thomas Eizinger
4c2e254543
Don't log subscription
This object is very verbose and not meant to be logged.
2021-04-01 17:08:25 +11:00
Thomas Eizinger
01739eddb1
Introduce a more flexible transaction subscription system
Instead of watching for status changes directly on bitcoin::Wallet,
we return a Subscription object back to the caller. This subscription
object can be re-used multiple times.

Among other things, this now allows callers of `broadcast` to decide
on what to wait for given the returned Subscription object.

The new API is also more concise which allows us to remove some of
the functions on the actor states in favor of simple inline calls.

Co-authored-by: rishflab <rishflab@hotmail.com>
2021-03-30 10:29:19 +11:00
Thomas Eizinger
c5827f84ca
Refactor recursive function to loop
This should get rid of the ever-growing stack size issue.
2021-03-29 12:15:48 +11:00
Thomas Eizinger
fc175a3f53
De-couple state from Monero wallet 2021-03-29 12:15:12 +11:00
Thomas Eizinger
cde3f0f74a
Remove connection handling from swap execution
The swap should not be concerned with connection handling. This is
the responsibility of the overall application.

All but the execution-setup NetworkBehaviour are `request-response`
behaviours. These have built-in functionality to automatically emit
a dial attempt in case we are not connected at the time we want to
send a message. We remove all of the manual dialling code from the
swap in favor of this behaviour.

Additionally, we make sure to establish a connection as soon as the
EventLoop gets started. In case we ever loose the connection to Alice,
we try to re-establish it.
2021-03-24 15:17:54 +11:00
Thomas Eizinger
16dfea035b
Simplify code within BobState::XmrLockProofReceived
To achieve this, we decompose `watch_for_locked_xmr` into two parts:

1. A non-self-consuming function to construct a `WatchRequest`
2. A state transition that can now consume `self` again because
it is only called once within the whole select! expression.

Ideally, we would move more logic onto this state transition (like
comparing the actual amounts and fail the transition if it is not
valid). Doing so would have an unfortunate side-effect: We would
always wait for the full confirmations before checking whether or
not we actually receive enough XMR.

This allows us to have state transitions that consume self.
2021-03-18 15:45:58 +11:00
Thomas Eizinger
338f4b82e5
Introduce dedicated bob::State6 for cancelling 2021-03-18 15:45:57 +11:00
Thomas Eizinger
c32ef92cf5
Simplify code within BobState::EncSigSent 2021-03-18 15:45:57 +11:00
Thomas Eizinger
09e2d5b5d7
Simplify code within BobState::XmrLocked
By reducing the number of local variables, we can greatly simplify
this piece of code.
2021-03-18 15:45:57 +11:00
Thomas Eizinger
b1affe3ecf
Insert latest state and call run_until only once
Instead of calling this function in all the branches, we can simply
make the whole match statement evaluate to the new state and perform
this functionality at the very end.
2021-03-18 15:45:56 +11:00
Thomas Eizinger
0d8962762a
Use early return to reduce one level of indentation 2021-03-18 15:45:55 +11:00
bors[bot]
113f2fa385
Merge #322
322: Refactor `ExecutionParams` and harmonize sync intervals of wallets r=thomaseizinger a=thomaseizinger



Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
2021-03-17 06:25:59 +00:00
Thomas Eizinger
09c41f89c4
Rename ExecutionParams to EnvironmentConfig 2021-03-17 16:31:16 +11:00
Thomas Eizinger
bc43ed6ebd
Pass execution params directly into wallet for initialization
This reduces the amount of parameters that we need to pass in.
2021-03-17 16:30:58 +11:00
rishflab
8675d88727 Don't wait for tx lock confirmed after broadcast
Bob does not care whether tx lock is confirmed. That is alice's problem.
This wait was introduced to remedy a bug in status_of_script() which was
 failing when called on a transaction with no confirmations.
2021-03-17 15:34:29 +11:00
Thomas Eizinger
273cf15631
Introduce Watchable abstraction for Bitcoin wallet
We have a repeated pattern where we construct one of our
Tx{Cancel,Redeem,Punish,Refund,Lock} transactions and wait until
the status of this transaction changes. We can make this more
ergonomic by creating and implementing a `Watchable` trait that
gives access to the TxId and relevant script for this transaction.
This allows us to remove a parameter from the `watch_until_status`
function.

Additionally, there is a 2nd pattern: "Completing" one of these
transaction and waiting until they are confirmed with the configured
number of blocks for finality. We can make this more ergonomic by
returning a future from `broadcast` that callers can await in case
they want to wait for the broadcasted transaction to reach finality.
2021-03-16 19:24:32 +11:00
Thomas Eizinger
a0830f099f
Pass relevant execution params into wallet instead of via functions
The execution params don't change throughout the lifetime of the
program. They can be set in the wallet at the very beginning.
This simplifies the interface of the wallet functions.
2021-03-16 19:24:31 +11:00
rishflab
e5c0158597
Greatly reduce load onto the Electrum backend
We achieve our optimizations in three ways:

1. Batching calls instead of making them individually.

To get access to the batch calls, we replace all our
calls to the HTTP interface with RPC calls.

2. Never directly make network calls based on function
calls on the wallet.

Instead, inquiring about the status of a script always
just returns information based on local data. With every
call, we check when we last refreshed the local data and
do so if the data is considered to be too old. This
interval is configurable.

3. Use electrum's notification feature to get updated
with the latest blockheight.

Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Rishab Sharma <rishflab@hotmail.com>
2021-03-16 19:24:31 +11:00
Thomas Eizinger
c2329b19a2
Tell the user more about the monero lock transaction
First, we tell the user that we are now waiting for Alice to lock
the monero. Additionally, we tell them once we received the
transfer proof which will lead directly into the
"waiting for confirmations" function.
2021-03-05 16:56:47 +11:00
bors[bot]
20f2e56e2d
Merge #271
271: Bob can verify that the XMR lock tx was published r=da-kami a=da-kami

The Monero `txhash` log was removed. I feel the user should have the possibility to verify that the transaction was actually published so I added the tx-hash to the confirmation output. 

We could potentially print the tx-hash when receiving the transfer proof already, but that might not add much value compared to printing it with the confirmations. 

Additionally we should allow the user to at least know when the XMR can be expected in the user's wallet, otherwise the swap ends like this:

```
2021-03-04 13:49:19   INFO Monero lock tx received 5 out of 5 confirmations
```

This is just not very informative - yes, the final transaction is an implementation detail, but I don't think we should hide the transactions from the user. By printing the tx-hash for spending from the lock-tx into the user wallet we ensure the user knows that the XMR can now be expected in the user wallet. 

--- 

To add context, here the complete log (with debug enabled) **before** this change: 

```
2021-03-04 13:30:46  DEBUG Database and seed will be stored in /Users/dakami/Library/Application Support/xmr-btc-swap
2021-03-04 13:30:46  DEBUG Starting monero-wallet-rpc on port 56145
2021-03-04 13:30:51  DEBUG Requesting quote
2021-03-04 13:30:51   INFO Received quote: 1 XMR = 0.00433500 BTC
2021-03-04 13:30:51   INFO Still got 0.01018746 BTC left in wallet, swapping ...
2021-03-04 13:30:51   INFO Spot price for 0.00500000 BTC is 1.153402537485 XMR
2021-03-04 13:30:52  DEBUG Starting execution setup with 12D3KooWCdMKjesXMJz1SiZ7HgotrxuqhQJbP5sgBm2BwP1cqThi
2021-03-04 13:30:55   INFO Published Bitcoin 3a6690a962191529892318819fb20e7f1ac4625400e64ee734056a9b2a17ad8f transaction as lock
2021-03-04 13:41:13  DEBUG Received Transfer Proof from 12D3KooWCdMKjesXMJz1SiZ7HgotrxuqhQJbP5sgBm2BwP1cqThi
2021-03-04 13:42:11   INFO Monero lock tx received 1 out of 5 confirmations
2021-03-04 13:45:33   INFO Monero lock tx received 2 out of 5 confirmations
2021-03-04 13:47:49   INFO Monero lock tx received 3 out of 5 confirmations
2021-03-04 13:48:56   INFO Monero lock tx received 4 out of 5 confirmations
2021-03-04 13:49:19   INFO Monero lock tx received 5 out of 5 confirmations
2021-03-04 13:49:19  DEBUG Encrypted signature sent
2021-03-04 13:49:19  DEBUG Alice acknowledged encrypted signature
2021-03-04 13:49:19  DEBUG watching for tx: e5569d3f0bcccac95252dffaebe74ead0360c09b76bc762de890aaa0e51afbcf
2021-03-04 13:49:20  DEBUG Received protocol error "missing transaction" from Electrum, retrying...
2021-03-04 13:49:22  DEBUG Received protocol error "missing transaction" from Electrum, retrying...
```



Co-authored-by: Daniel Karzel <daniel@comit.network>
2021-03-04 06:24:59 +00:00