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.
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.
Block until we are sure that the update was done, because otherwise we might have weird side effects in the UI because there is a dependency on the announcements being available when creating offers.
- store TakerId for proposals to be able to respond to specific taker about
settlement proposal when the user takes action
- send the collab settlement response (accept or reject) from the maker
- handle rejection (remove from the map), CFD state in the UI returns to "Open"
- Handles the Oracle's attestation in the cfd actor, transition according to the knowledge we have about the timelock expiry already.
- Tries to publish the CET if we are in `CetStatus::Ready`, i.e. both the attestation and timelock expiry happened. We try publishing if either event happened, and just print a log in case it's not ready yet.
- Tries to re-publish CET if we are in `PendingCet` upon restart.
- Re-triggers CET monitoring upon startup.
- Extends any state after `ContractSetup` to be able to store the attestation. (see below for ideas to change that)
Things that could be done different:
Currently we are carrying on the attestation through a lot of states - because we cannot just transition the user to `OpenCommitted` because it is a user decision to go for commit, but we have to keep the attestation around once it happened.
To reduce the state complexity, we could store the attestation independent of the state, but associated with the cfd.
This would make things a lot simpler, but we would then always have to go to the database to check if the attestation is already around (which might make other parts more complex).
Add support for multiple update proposals.
A taker might request to update/change a CFD in different ways, e.g.: propose to settle it or roll over.
In order to support different scenarios we introduce another layer of abstraction.
The rest of the changes creates a boilerplate for the actual rollover protocol.
New HashMap can store both incoming and outgoing settlement proposals at the
same time and resulted in some code simplification, as there are less types
needed to convey the intention.
Provide a type alias for convenience (this also ensures that both binaries store
settlement proposals in the same way)
Opted not to implement an additional message to fetch a specific announcement from the Oracle actor because it would have made the oracle actor unnecessarily complex (We would have to split it into different functionality by trait).
The taker cfd actor holds a sliding window of all the announcements received from the oracle actor.
Daniel Karzel
Thomas Eizinger
Philipp Hoenisch
Lucas Soriano del Pino
Mariusz Klochowicz