Bob has to check for the possibility to cancel in every state after he locked the BTC.
Otherwise Bob will try to perform actions that don't have any point.
As Bob is dialing Alice, we now ensure that we are connected to Alice
at each step that needs communication.
If we are not connected, we proceed with dialing.
In an attempt to improve libp2p usage, we also add known address of
Alice first and only use peer_id to dial.
This ensures that we use the expected peer id.
98: Remove tor module r=da-kami a=da-kami
This removes the currently unused `tor module`.
Different `tokio` versions have been causing issues with the `tor` module in the past (i.e. `Cargo.lock` broken problem...). It started causing issues again when adding a dependency to `jsonrpc_client` working on https://github.com/comit-network/xmr-btc-swap/pull/97
We don't support `tor` at the moment and are no planning to add this feature initially as it is not super important to users.
The functionality can easily added again at a later point.
Co-authored-by: Daniel Karzel <daniel@comit.network>
This module was intended to contain helper functions for each step.
However, those are not needed except for the negotiate step.
A dedicated module is not needed for one function.
The usage of the peer id is incorrect as we do not even check it when
dialing. For now, we can ignore it.
We can then re-introduce it and use it properly at a later stage.
Reworked Alice XmrLocked state transition handler to handle the
scenario when Alice received the encsig but Bob refunds.
Previously Alice was trying to redeem after receiving the encsig
without checking if t1 had elapsed.
Previously state0 had to be set after creating Alice's behaviour.
With the event loop we no longer has access to the swarm so
set_state0() has to be called indirectly through a channel. This
means it is difficult to guarantee state0 is being set due to the
asynchronous nature of channels. This was solved by initialising
Alice with state0.
Previously the libp2p swarm had to be manually polled within the
protocol execution code to execute actions such as sending a
message. The swarm is now wrapped in SwarmDriver which polls the
swarm in a seperate task
Tracing should be initialized by test and the `_guard` kept alive within the test.
Re-using this code in different tests does not really have any additional value.
Instead of specifying what messages we want to include, I went for a filter that excludes noise.
That way we get more useful logging.
Use reusable test init functions for happy path test
Extract tracing setup to reusable function
Move test initialization to seperate functions
Increase stack size in CI
Fix monero max finality time
Force Bob swarm polling to send message 2
Run Bob state to xmr_locked in punish test to force the sending of
message2. Previously Bob state was run until btc_locked. Although
this was the right thing to do, message2 was not being sent as the
swarm was not polled in btc_locked. Alice punish test passes.
Add info logging to executor
Move state machine executors into seperate files
Remove check for ack message from Alice. Seems like a bad idea to
rely on an acknowledgement message instead of looking at the
blockchain.
Fix warnings
Consolidate and simplify swap execution. Generators are no longer
needed. Consolidate recovery and swap data structures. The
recursive calls can be replaced with a loop if returning prior to
completion is desired for testing purposes.
Fill out alice abort path
Move state machine executors into seperate files
Not compiling due to recursion/async issues
Fix async recursion compilation errors
Fix Bob swap execution
Remove check for ack message from Alice. Seems like a bad idea to
rely on an acknowledgement message instead of looking at the
blockchain.
Fix Bob abort
Fix warnings
Xmr lock complete
Add TxCancel submit to XmrLocked
Bob swap completed
Remove alice
This introduces a lot of duplication between the binary and the
library, but it's okay because this module should only be a temporary
measure until we allow recovery to be handled by the original state
machine.
Also, fix a bug in `xmr_btc::alice::action_generator` caused by the
incorrect assumption that Alice's ability to punish Bob could be
determined before the cancel transaction hits the blockchain.
The numerous tor conditional compile flags were removed by
extracting transport creation to the main statement. A tor
transport is created if Alice specifies a tor port using the CLI.
The hardcoded configuration was replaced with CLI
configuration options. CLI based config was chosen
over a config file as it does not access and clutter
the user's file system. By CLI options depend on whether
the program is run in Alice or Bob mode.
Before this patch Bob is not sending message 3. This is because we are not
polling Bob's swarm correctly. To fix it we can just mimic the other NB's and
bubble up an event when Bob receives message 3 response from Alice, this way we
can `await` upon this event which triggers polling, making Bob's swarm send the
message.
Also use cosntant backoff retry strategy as opposed to exponential
backoff. This is in case retrying several times quickly causes the
retry intervals to become large enough that the test is very slow
and/or the Bitcoin lock transaction expires.
The current problem occurs on the last message i.e. Bob sending
tx_redeem_encsig to Alice. The action is yielded for Bob to do it, but
Alice appears to never receive it (unconfirmed claim, requires more
logging).
Unfortunately, I had to put the wrap the swarm in Alice's `Network`
struct in an `Arc<Mutex<T>>` in order to be able to use `backoff` to
control the retry mechanism. This is because the stream of events
cannot be turned into a `SharedFuture` (unlike Bob's).
It would be good to find an alternative solution.
Alice does not respond with anything when receiving message 2 from Bob. We don't
want to leave Bob's request/response protocol waiting so send an empty response
back.
It looks like the compiler can ascertain that `message0` will be
initialised by the time we use it, so it doesn't need to be an
`Option` and it doesn't need to be declared as mutable.
In order for Alice to complete the handshake she needs to transition to state 3,
for this she needs message 2 from Bob.
Send `bob::Message2` to Alice and transition to `State3` - completing the
handshake.
Anything that needs to be re-exported by this crate from
`curve25519_dalek` can be re-exported from the `monero` module. In
fact, the `Scalar` type was already being re-exported.
We model the getting of amounts as a network behaviour even though conceptually
it is a protocol. Refine/refactor the code a bit to make this more obvious.
- Use `Amounts` instead of `Messenger`
We only ever connect to a single peer, update peer tracker to reflect this. This
is a single patch because the handling of the two network behaviours is a
intertwined.
- Only track one peer connection
- Track the peer id and the multiaddr of the counterparty
- Emit an event for connection established on Alice's side as well as Bob's side
Add a binary crate `swap` that implements two nodes (Alice and Bob). With this
applied we can start up a node for each role and do:
- Bob: Requests current amounts using BTC is input
- Alice: Responds with amounts
- Bob: (mock) get user input to Ok the amounts
... continue with swap (TODO)
Franck Royer
Daniel Karzel
Daniel Karzel
bors[bot]
rishflab
Franck Royer
Lucas Soriano del Pino
Philipp Hoenisch
Tobin C. Harding
Lucas Soriano