Upon rejection, we always have to remove the order on the maker side, otherwise a taker cannot re-try taking (with e.g. a different amount) because there is already a rejected cfd in the taker database.
We would have liked to attach the stream of `TakerStreamMessage`s
directly to the `MessageChannel`, but we failed and instead decided to
let the `maker_inc_connections::Actor` send these messages to itself
and then forward them to the `maker_cfd::Actor`.
Inserting cfd or updating its state requires a follow-up update on the Cfd feed
sent to the UI. Encapsulate the behaviour in functions that are shared
across Cfd actors.
Once we have collaborative close present in the state(s) we lock in the profit based on the price of the collaborative close.
Note: Currently no automated validation on the maker side if the given amounts and price of collaborative settlement are sane.
Simplify model's state machine as PendingClose only matters for the UI
(for user feedback & available actions).
Disallow proposing another settlement if one was already signed.
The primary goal was to remove all of the calls to `serde_json::to_string()`
for the data-handling, thus enabling us to do (more or less):
```rust
Order {
row.column,
...
}
```
as well as clean up the SQL for easier reading. This has mostly been
accomplished, with further refinements easily accomplished once the
upstream issues in `sqlx` are addressed. See #314 for issues we are
tracking.
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.
Anything that can fail (e.g. fetching oracle stuff) has to be tried before we change any state or notify the taker, otherwise it can happen that we remain in a failed state that causes very weird side effects.
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 `monitor::Actor` only needs to be able to send the
`monitor::Event` 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.
Distinguish between collaborative close and cet closing.
Moved the payout on the `Cfd` which decides what the payout of the `Cfd` is, where
- `None` means the payout is not decided yet (we can optimize that and potentially combine this with `profit` in another iteration)
- `Some(payout)` can be a refund, collaborative or cet payout
Refund is handled in an early exit guard based on the state.
Collaborative settlement has priority over cet payout (attestation). In case there is a collaborative settlement present we always return payout based on that.
The function signature didn't need to take the whole state, as it was only
borrowed internally.
Removes the need for many `.clone()` calls sprinkled in the codebase.
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.
Daniel Karzel
Lucas Soriano del Pino
Thomas Eizinger
Mariusz Klochowicz
Philipp Hoenisch
DelicioiusHair