Git-Mirrors/xmr-btc-swap
1
0
Fork 0
mirror of https://github.com/comit-network/xmr-btc-swap.git synced 2024-10-01 01:45:40 -04:00
Code Issues Packages Projects Releases Wiki Activity
4790d701e5
xmr-btc-swap/xmr-btc/Cargo.toml

40 lines
1.5 KiB
TOML
Raw Normal View History

Swap Monero for Bitcoin Co-authored-by: rishflab <rishflab@hotmail.com> Co-authored-by: Philipp Hoenisch <philipp@hoenisch.at> Co-authored-by: Tobin C. Harding <tobin@coblox.tech>
2020-09-28 02:18:50 -04:00
[package]
name = "xmr-btc"
version = "0.1.0"
authors = ["CoBloX Team <team@coblox.tech>"]
edition = "2018"
Merge branch 'master' into on-chain-protocol
2020-10-21 23:49:55 -04:00
# TODO: Check for stale dependencies, this looks like its a bit of a mess.
Swap Monero for Bitcoin Co-authored-by: rishflab <rishflab@hotmail.com> Co-authored-by: Philipp Hoenisch <philipp@hoenisch.at> Co-authored-by: Tobin C. Harding <tobin@coblox.tech>
2020-09-28 02:18:50 -04:00
[dependencies]
anyhow = "1"
async-trait = "0.1"
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 18:32:25 -04:00
bitcoin = { version = "0.23", features = ["rand", "serde"] }
Update cross-curve-dleq dependency Making build times considerably faster. On my machine, after running `cargo clean`, `cargo build -p swap` takes 2min 19s. The updated dependency also comes with a critical fix to the `Scalar` type, which originally wrongly assumed that secp256k1 and ed25519 scalars had the same endianness. For this reason, we now have to reverse the bytes of recovered scalars if we are to use them on a different chain. Finally, there is no need to append `RUST_MIN_STACK=100000000` to avoid stack overflows in tests and when running the binary.
2020-11-08 19:07:06 -05:00
cross-curve-dleq = { git = "https://github.com/comit-network/cross-curve-dleq", rev = "a19608734da1e8803cb4c806022483df4e7d5588", features = ["serde"] }
Swap Monero for Bitcoin Co-authored-by: rishflab <rishflab@hotmail.com> Co-authored-by: Philipp Hoenisch <philipp@hoenisch.at> Co-authored-by: Tobin C. Harding <tobin@coblox.tech>
2020-09-28 02:18:50 -04:00
curve25519-dalek = "2"
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 18:32:25 -04:00
ecdsa_fun = { git = "https://github.com/LLFourn/secp256kfun", rev = "510d48ef6a2b19805f7f5c70c598e5b03f668e7a", features = ["libsecp_compat", "serde", "serialization"] }
ed25519-dalek = { version = "1.0.0-pre.4", features = ["serde"] }# Cannot be 1 because they depend on curve25519-dalek version 3
Trigger refund if the publication of Monero TxLock takes too long
2020-10-15 03:34:55 -04:00
futures = "0.3"
[WIP] Generate actions for Bob's on-chain protocol Mimics what @thomaseizinger did here [1] and here [2]. This has the advantage that the consumer has more freedom to execute `Action`s without having to implement particular traits. The error handling required inside this protocol-executing function is also reduced. As discussed with Thomas, for this approach to work well, the trait functions such as `receive_transfer_proof` should be infallible, and the implementer should be forced to hide IO errors behind a retry mechanism. All of these asynchronous calls need to be "raced" against the abort condition (determined by the `refund_timelock`), which is missing in the current state of the implementation. The initial handshake of the protocol has not been included here, because it may not be easy to integrate this approach with libp2p, but a couple of messages still need to exchanged. I need @tcharding to tell me if it's feasible/good to do it like this. [1] https://github.com/comit-network/comit-rs/blob/move-nectar-swap-to-comit/nectar/src/swap/comit/herc20_hbit.rs#L57-L184. [2] https://github.com/comit-network/comit-rs/blob/e584d2b14f3602e2657d09b989e8ea1d483a0626/nectar/src/swap.rs#L716-L751.
2020-10-12 02:17:22 -04:00
genawaiter = "0.99.1"
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 18:32:25 -04:00
miniscript = { version = "1", features = ["serde"] }
monero = { version = "0.9", features = ["serde_support"] }
Swap Monero for Bitcoin Co-authored-by: rishflab <rishflab@hotmail.com> Co-authored-by: Philipp Hoenisch <philipp@hoenisch.at> Co-authored-by: Tobin C. Harding <tobin@coblox.tech>
2020-09-28 02:18:50 -04:00
rand = "0.7"
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 18:32:25 -04:00
serde = { version = "1", features = ["derive"] }
Swap Monero for Bitcoin Co-authored-by: rishflab <rishflab@hotmail.com> Co-authored-by: Philipp Hoenisch <philipp@hoenisch.at> Co-authored-by: Tobin C. Harding <tobin@coblox.tech>
2020-09-28 02:18:50 -04:00
sha2 = "0.9"
thiserror = "1"
Moving tor into swap
2020-10-22 19:32:48 -04:00
tokio = { version = "0.2", default-features = false, features = ["time"] }
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 01:36:50 -04:00
tracing = "0.1"
Swap Monero for Bitcoin Co-authored-by: rishflab <rishflab@hotmail.com> Co-authored-by: Philipp Hoenisch <philipp@hoenisch.at> Co-authored-by: Tobin C. Harding <tobin@coblox.tech>
2020-09-28 02:18:50 -04:00
[dev-dependencies]
Replace monero::CheckTransfer with monero::WatchForTransfer Instead of checking once to see if Monero's `TxLock` has been published, the new trait should keep looking until the transaction has been found. The new trait also allows the caller to set an expected number of confirmations on the transaction. The implementation of the trait is currently part of test code, but it should be similar to what we will eventually do for an application.
2020-10-14 22:10:31 -04:00
backoff = { version = "0.2", features = ["tokio"] }
Swap Monero for Bitcoin Co-authored-by: rishflab <rishflab@hotmail.com> Co-authored-by: Philipp Hoenisch <philipp@hoenisch.at> Co-authored-by: Tobin C. Harding <tobin@coblox.tech>
2020-09-28 02:18:50 -04:00
base64 = "0.12"
Update xmr-btc lib to use new monero-harness
2020-11-02 05:12:38 -05:00
bitcoin-harness = { git = "https://github.com/coblox/bitcoin-harness-rs", rev = "3be644cd9512c157d3337a189298b8257ed54d04" }
Fix Cargo.toml fmt
2020-10-08 01:07:49 -04:00
futures = "0.3"
Swap Monero for Bitcoin Co-authored-by: rishflab <rishflab@hotmail.com> Co-authored-by: Philipp Hoenisch <philipp@hoenisch.at> Co-authored-by: Tobin C. Harding <tobin@coblox.tech>
2020-09-28 02:18:50 -04:00
monero-harness = { path = "../monero-harness" }
reqwest = { version = "0.10", default-features = false }
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 18:32:25 -04:00
serde_cbor = "0.11"
Make it work on CI
2020-10-21 02:53:49 -04:00
tempfile = "3"
Update xmr-btc lib to use new monero-harness
2020-11-02 05:12:38 -05:00
testcontainers = "0.11"
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 01:36:50 -04:00
tracing = "0.1"
Fix Cargo.toml fmt
2020-10-08 01:07:49 -04:00
tracing-subscriber = "0.2"
Reference in New Issue Copy Permalink