We are only making requests to Olivia that are absolutely necessary,
i.e. only fetch attestations when they are likely ready and only
fetch attestations that we definitely need.
As a result, we can trigger the sync much more frequent.
Fixes#349.
A fan-out actor takes an incoming message and forwards it to a set
of actors. This allows our `oracle::Actor` to be unaware, how many
other actors are interested in the attestation, thus simplifying it.
The `oracle::Actor` only needs to be able to send the
`oracle::Attestation` to an actor who can handle it. We were already
able to express this using trait bounds, but it was blocking us from
being able to make the `{maker_taker}_cfd::Actor` generic over
different actors due to infinite, cyclic types.
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
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.
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)
Keep track of outgoing/incoming settlement proposals in a hashmap inside the CFD
rocket that is available as a Rocket state in order to derive correct CfdState
for the UI.
Add placeholders for actions for accepting/rejecting settlement offers in the maker.
Also:
- rename Accept/Reject in few places to reduce ambiguity between interacting
with an order and a settlement proposal.
- allow only one in-flight settlement proposal from the taker
This should greatly improve resilience as we no longer have any
tasks within `tokio` that can fail without recovering.
Instead, we periodically ping the actor with a `Sync` message which
updates the local state of all scripts and sends out messages accordingly.
Caused trouble because of route collisions, so the integration was done now.
Required distinguishing Maker and Taker on the cfd level, which comes in handy anyway.
We distinguish by order origin, but still map to a `Role` enum (`Taker` / `Maker`) for readability.
To avoid duplication the `Role` from contract setup was moved into the model and used throughout.
This reverts commit 4b8237c9d6.
After last night's conversation, we decided to return to the first version of
the PR, which will come in a subsequent commit.
`attach_stream` uses `send` under the hood which will process messages
in order. This will guarantee that the `taker_cfd::Actor` processes the
messages in the order they come in on the wire. That allows us to assume
that we will always get the `Accept` message before the first `Setup` message.
This goes towards handling all cfd state transitions in one place, so it becomes easier to reason about it.
Currently, state transitions are scattered over the code of the cfd actor.
This change bundles the actual transition in the cfd itself.
Inserting the new state into the db is still in the responsibility of the caller.
note: the `monitor` import in `taker.rs` should technically not be part of this commit, but was needed because I decided that the `CfdMonitoringEvent` should live in the `monitor` actor. But since that is not part of the `Cfd` in `model` the taker needs to know about the `monitor`.
Daniel Karzel
Mariusz Klochowicz
Lucas Soriano del Pino
Thomas Eizinger
Philipp Hoenisch