474: Add more log details r=bonomat a=bonomat
Resolves#448
1. The first commit adds an additional log statement of the exchange rate for each state-update. This is useful because it allows us to measure profitability easily, i.e. by knowing what was the exchange rate when the swap was started and what was it when it was finalized.
2. The second commit changes a bunch of log messages.
3. The third commit is adds a new commandline flag to toggle json format.
Co-authored-by: Philipp Hoenisch <philipp@hoenisch.at>
Co-authored-by: Philipp Hoenisch <philipp@coblox.tech>
485: Update assert_weight test to account for a range up to 8 bytes. r=bonomat a=bonomat
Fixes#482
Weights fluctuate because of the length of the signatures. Valid ecdsa signatures can have 68, 69, 70, 71, or 72 bytes. Since most of our transactions have 2 signatures the weight can be up to 8 bytes less than the static weight (4 bytes per signature).
Since it is really hard to get these short signatures (<1 in 100), I also include the transaction in the assert message which will help for debugging purposes.
Source: https://medium.com/coinmonks/on-bitcoin-transaction-sizes-97e31bc9d816
Co-authored-by: Philipp Hoenisch <philipp@hoenisch.at>
Introduces a minimum buy Bitcoin amount similar to the maximum amount already present.
For the CLI the minimum amount is enforced by waiting until at least the minimum is available as max-giveable amount.
Max-buy and spread is not something that one would configure on every run.
More convenient to keep this in the config.
The max-buy Bitcoin value was adapted to `0.02` which is more reasonable for mainnet.
Activated feature `serde-float` to serialize the spread (Decimal) as float instead of string.
```
...
[maker]
max_buy_btc = 0.02
ask_spread = 0.02
```
Weights fluctuate because of the length of the signatures. Valid ecdsa signatures can have 68, 69, 70, 71, or 72 bytes. Since most of our transactions have 2 signatures the weight can be up to 8 bytes less than the static weight (4 bytes per signature).
452: Asb manual recovery commands r=da-kami a=da-kami
Fixes#377
Allows us to manually finish swaps if we run into error scenarios during execution.
I opted for putting all these commands under subcommand `manual-recovery` to run them e.g. (cancel):
```
./asb manual-recovery cancel [--force] --swap-id (...)
```
I combined the `cancel` and `refund` command in the same commit, because I only adapted the e2e tests once cancel and refund were implemented (cancel alone is a bit useless anyway...).
Co-authored-by: Daniel Karzel <daniel@comit.network>
Adds `cancel`, `refund`, `punish`, `redeem` and `safely-abort` commands to the ASB that can be used to trigger the specific scenario for the swap by ID.
`asb --help` :
(...)
SUBCOMMANDS:
balance Prints the Bitcoin and Monero balance. Requires the monero-wallet-rpc to be running.
help Prints this message or the help of the given subcommand(s)
history Prints swap-id and the state of each swap ever made.
start Main command to run the ASB.
withdraw-btc Allows withdrawing BTC from the internal Bitcoin wallet.
In the production code it is a weird indirection that we load the state and then pass in the state and the database.
In the tests we have one additional load by doing it inside the command, but loading from the db is not expensive.
461: Add resume-only mode for the ASB r=da-kami a=da-kami
Fixes#378
Resume-only is a maintenance mode where no swaps are accepted but unfinished swaps are resumed.
This is achieve by ignoring incoming spot-price requests (that would lead to execution setup) in the event-loop.
- [x] Refactor `spot_price`, move Alice's decision logic into dedicated `NetworkBehaviour`
- [x] Protocol (network) level tests for the `spot_price` behaviour
Co-authored-by: Daniel Karzel <daniel@comit.network>
Each test spawns swarm for Alice and Bob that only contains the spot_price behaviours and uses a memory transport.
Tests cover happy path (i.e. expected price is returned) and error scenarios.
Implementation of `TestRate` on `LatestRate` allows testing rate fetch error and quote calculation error behaviour.
Thanks to @thomaseizinger for ramping up the test framework for comit-rs in the past!
Instead of handling all errors on the inside spot_price errors are bubbled up (as `SwapRequestDeclined`).
This allows us to test both Alice's and Bob's behaviour for all scenarios.
What goes over the wire should not be coupled to the errors being printed.
For the CLI and ASB we introduce a separate error enum that is used for logging.
When sending over the wire the errors are mapped to and from the `network::spot_price::Error`.
As part of Bob-specific spot_price code was moved from the network into bob.
Clearly separation of the network API from bob/alice.
Move Alice's spot price logic into a dedicated network behaviour that handles all the logic.
The new behaviour encapsulates the complete state necessary for spot price request decision making.
The network behaviour cannot handle asynchronous calls, thus the balance is managed inside the spot price and has to updated regularly from the outside to ensure the spot price balance check has up to date data.
At the moment the balance is updated upon an incoming quote requests.
Code that is relevant for both ASB and CLI remains in the `network::spot_price` module (e.g. `network::spot_price::Error`).
When a CLI requests a spot price have some errors that are expected, where we can provide a proper error message for the CLI:
- Balance of ASB too low
- Buy amount sent by CLI exceeds maximum buy amount accepted by ASB
- ASB is running in maintenance mode and does not accept incoming swap requests
All of these errors returns a proper error to the CLI and prints a warning in the ASB logs.
Any other unexpected error will result in closing the channel with the CLI and printing an error in the ASB logs.
Resume-only is a maintenance mode where no swaps are accepted but unfinished swaps are resumed.
This is achieve by ignoring incoming spot-price requests (that would lead to execution setup) in the event-loop.
466: Add support to dynamically chose bitcoin transaction fees. r=bonomat a=bonomat
Resolves#443 (Bitcoin only).
@da-kami /@thomaseizinger: do you know how fees work in Monero?
If not, I'll read up on it and to come up with a proper strategy.
Monero Fees will be covered in #470
Note:
The there is a hardcoded relative and absolute upper bound. I personally feel safer if this is hardcoded for now as it is too easy to get wrong.
At the time of writing, this equals roughly USD $56.
Eventually we will want to make this also configurable.
Co-authored-by: Philipp Hoenisch <philipp@hoenisch.at>
Co-authored-by: Philipp Hoenisch <philipp@coblox.tech>
Fees are hard to compute and it is too easy to get wrong and lose a lot of money. Hence, a hardcoded maximum of 100,000 satoshi for a single transaction is in place.
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.
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.
Alice chooses the fee for TxRedeem because she 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.
