Connection actor takes care of establishing a connection to the maker and is
monitoring its status.
The connection actor:
- listens for periodically sent heartbeat messages from the maker,
- publish the maker status on a watch::channel feed outside TakerActorSystem,
- observe changes on the watch channel and shut down Rocket if maker goes offline
Note: this is a stepping stone resulting in temporary behaviour. Eventually,
we'd want to support reconnecting to the maker as well as operating the
taker without the maker being online (with a limited set of actions).
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Add configurable log levels on taker and maker and start tracing connection related information to track down a problem where the taker does not receive orders but there are not connection errors on both sides.
Withdraw is an optional subcommand of the network subcommand, so the command reads like this, e.g. taker:
`./taker mainnet withdraw --address ...`
Internally, we use the wallet actor for withdrawing for now (simplifies the implementation, otherwise we would have to extract the wallet construction outside the actor).
Fee rate can either be passed by user or is set to default fee rate of `1.0`.
We enable RBF (replace by fee) signalling so that users can bump the transaction fee.
The which do not fit into the 65535 byte message size
limit of the noise protocol are chunked before
encryption. This feature was introduced to handle the
very large messages which contained the CET's.
More research is required into the NOISE_PARAMS and
whether they can be used to configure snow elegantly
handle authentication.
Fetching new events all over the place is cumbersome and it is likely that we will forget about doing so (e.g. atm we forgot doing this when receiving a roll-over request at the maker). Hence, we now fetch on a regular interval for a fixed timespan:
When starting up we fetch oracle events for the next 24h. Afterwards we check every 5 minutes again if there is a new event to check. This should ensure that we always know about needed events.
Include a generic Wallet actor constructor in the actor systems and allow
passing in a generic Wallet actor implementing xtra::Handlers into the cfd
actors.
Rename 'Maker' and 'Taker' to 'MakerActorSystem' and 'TakerActorSystem' for
readability.
Co-authored-by: Mariusz Klochowicz <mariusz@klochowicz.com>
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.
Mariusz Klochowicz
Thomas Eizinger
Daniel Karzel
rishflab
dependabot[bot]
Philipp Hoenisch
Lucas Soriano del Pino