The daemon adds `CfdDetails` that contains:
* `Vec<TxUrl>` - relevant transaction-id URLs to block explorer based on the state and bitcoin network
* `Option<bitcoin::Amount>` - The payout if we already have an attestation
* Display tx-urls and payout when unfolding the cfd row in table
The way I see it, an oracle "event" consists of both an "announcement"
and an "attestation". In the case of this message, we want to keep
track of the state of the "attestation", so the rename should make it
unambiguous.
Instead of always keeping track of the next 24 hours of announcements,
we instruct the `oracle::Actor` to fetch (if necessary) announcements
based on new orders.
At the moment this results in removing code which allowed us to fetch
several announcements in parallel, but we will need to reintroduce it
once we let the `daemon`s create CFDs with multiple attestation
events.
Instead of passing in a script which may or may not be part of a
CET (because some CETs only pay to one party), we take the script
pubkey from an output of the transaction itself.
We keep seeing this in the logs, after a final tx went in:
```
2021-10-11 16:58:18 ERROR Could not find script in own state for txid b542cbc1920bdd926d79fb17377eda7152ed944ec64a1b09ce68dd11d9e7467e, ignoring
```
This happens because multiple transactions have the same script (e.g. CET, refund).
Once the CET is final we remove it from monitoring, which results in the txid not being available when matching.
We always replaced it with `remaining`, but when populating `awaiting_status` upon sync we only go by the keys, so we actually fill in the script status again.
We should remove the complete entry if we want to make sure that we don't want to process it anymore.
Note: Kept seeing monitoring logs for things that were already past Finality (...) so we looked into this.
In this protocol we *can* actually have transactions with the same script, hence, we have to handle the `GetHistoryRes` by `Txid`.
To make this easier to understand we group the `Vec<Vec<GetHistoryRes>>` by `Txid` into `HashMap<Txid, GetHistroyRes>`.
Note: The assumption is, that only `GetHistroyRes` is returned for the `Txid`+`Script` combination.
In a real-world scenario this should actually never happen, but it is still weird to see `PendingOpen` jump to `Open` when testing with timelocks and attestations.
Since this is "more correct" we distinguish fine-granular.
Co-authored-by: Lucas <lucas@comit.network>
The DLC does not concern the UI, hence the amounts should be handles in satoshi.
Note: This commit enforces db reset of CFDs that are stored in `as_btc`.
We are looping over multiple CFDs when trying to publish the CET.
If we fail inside the loop then the next CFD(s) are not processed and CETs might not get published properly.
This should make the code more resilient.
Reasoning:
The state transition can fail, hence the result.
It can, however, happen that there is no failure, but we still did not transition to a new state.
In such cases we don't want to save the state in the database because it would be an unwanted duplicated entry.
The `Attestation` in the `oracle` module has `Desiarialization` rules that conflict with loading it from the db.
We should not reuse domain structs between modules anyway, so this was cleaned up by introducing a dedicated `model::Attestation` and mapping to `oracle::Attestation`.
Note: Since our sliding window of `next_24_hours` in the oracle actor is current hour `+[1..24]` the window should always be able to handle fetching an event of current hour + 1.
Instead of the oracle actor sending out the `Announcements` we only store them internally and let the cfd actors chose what `Announcement` is relevant given the term of the offer.
The specific `Announcement` is then fetched from the oracle actor.
The monitoring logic for pending attestations remains the same.
Daniel Karzel
Lucas Soriano del Pino
DelicioiusHair
Thomas Eizinger
Mariusz Klochowicz
Philipp Hoenisch