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
2a07113074
xmr-btc-swap/xmr-btc/src/alice.rs

651 lines
20 KiB
Rust
Raw Normal View History

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
use crate::{
bitcoin,
Loop on blockchain call instead of delaying Previously there was a delay making a get raw transaction call to give some time for a transaction to be confirmed on the blockchain. This has been replaced with a loop that waits until the call is succesful.
2020-10-07 19:53:30 -04:00
bitcoin::{BroadcastSignedTransaction, WatchForRawTransaction},
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
bob, monero,
Rename ImportOutput to reflect purpose
2020-10-07 20:27:54 -04:00
monero::{CreateWalletForOutput, Transfer},
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::{bitcoin_amount, cross_curve_dleq_scalar, ecdsa_fun_signature},
Implement transport traits with generics
2020-10-08 18:46:24 -04:00
transport::{ReceiveMessage, SendMessage},
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
};
Remove empty lines between imports
2020-10-07 20:07:37 -04:00
use anyhow::{anyhow, Result};
use ecdsa_fun::{
adaptor::{Adaptor, EncryptedSignature},
nonce::Deterministic,
};
use rand::{CryptoRng, RngCore};
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
use serde::{Deserialize, Serialize};
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
use sha2::Sha256;
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
use std::convert::{TryFrom, TryInto};
pub mod message;
Remove duplicated macro definitions
2020-10-08 19:17:36 -04:00
pub use message::{Message, Message0, Message1, Message2};
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
Re-order send/receive There are no guarantees that send_message and receive_massage do not block the flow of execution. Therefore they must be paired between Alice/Bob, one send to one receive in the correct order. Define Alice to call `receive_message` first, with Bob sending the message. Do this because we are expecting Alice to be have a well known address, there is no currently such assumption for Bob.
2020-10-11 17:53:21 -04:00
// There are no guarantees that send_message and receive_massage do not block
// the flow of execution. Therefore they must be paired between Alice/Bob, one
// send to one receive in the correct order.
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
pub async fn next_state<
R: RngCore + CryptoRng,
Loop on blockchain call instead of delaying Previously there was a delay making a get raw transaction call to give some time for a transaction to be confirmed on the blockchain. This has been replaced with a loop that waits until the call is succesful.
2020-10-07 19:53:30 -04:00
B: WatchForRawTransaction + BroadcastSignedTransaction,
Rename ImportOutput to reflect purpose
2020-10-07 20:27:54 -04:00
M: CreateWalletForOutput + Transfer,
Implement transport traits with generics
2020-10-08 18:46:24 -04:00
T: SendMessage<Message> + ReceiveMessage<bob::Message>,
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
>(
bitcoin_wallet: &B,
monero_wallet: &M,
transport: &mut T,
state: State,
rng: &mut R,
) -> Result<State> {
match state {
State::State0(state0) => {
Re-order send/receive There are no guarantees that send_message and receive_massage do not block the flow of execution. Therefore they must be paired between Alice/Bob, one send to one receive in the correct order. Define Alice to call `receive_message` first, with Bob sending the message. Do this because we are expecting Alice to be have a well known address, there is no currently such assumption for Bob.
2020-10-11 17:53:21 -04:00
let alice_message0 = state0.next_message(rng).into();
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
Remove redundant type declarations
2020-10-08 17:48:00 -04:00
let bob_message0 = transport.receive_message().await?.try_into()?;
Re-order send/receive There are no guarantees that send_message and receive_massage do not block the flow of execution. Therefore they must be paired between Alice/Bob, one send to one receive in the correct order. Define Alice to call `receive_message` first, with Bob sending the message. Do this because we are expecting Alice to be have a well known address, there is no currently such assumption for Bob.
2020-10-11 17:53:21 -04:00
transport.send_message(alice_message0).await?;
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
let state1 = state0.receive(bob_message0)?;
Ok(state1.into())
}
State::State1(state1) => {
Remove redundant type declarations
2020-10-08 17:48:00 -04:00
let bob_message1 = transport.receive_message().await?.try_into()?;
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
let state2 = state1.receive(bob_message1);
Remove redundant type declarations
2020-10-08 17:48:00 -04:00
let alice_message1 = state2.next_message();
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
transport.send_message(alice_message1.into()).await?;
Ok(state2.into())
}
State::State2(state2) => {
Remove redundant type declarations
2020-10-08 17:48:00 -04:00
let bob_message2 = transport.receive_message().await?.try_into()?;
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
let state3 = state2.receive(bob_message2)?;
Ok(state3.into())
}
State::State3(state3) => {
tracing::info!("alice is watching for locked btc");
let state4 = state3.watch_for_lock_btc(bitcoin_wallet).await?;
Ok(state4.into())
}
State::State4(state4) => {
let state5 = state4.lock_xmr(monero_wallet).await?;
tracing::info!("alice has locked xmr");
Ok(state5.into())
}
State::State5(state5) => {
transport.send_message(state5.next_message().into()).await?;
// todo: pass in state4b as a parameter somewhere in this call to prevent the
// user from waiting for a message that wont be sent
Remove redundant type declarations
2020-10-08 17:48:00 -04:00
let message3 = transport.receive_message().await?.try_into()?;
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
let state6 = state5.receive(message3);
tracing::info!("alice has received bob message 3");
tracing::info!("alice is redeeming btc");
Fix clippy warnings
2020-10-08 01:18:34 -04:00
state6.redeem_btc(bitcoin_wallet).await?;
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
Ok(state6.into())
}
State::State6(state6) => Ok(state6.into()),
}
}
Fix clippy warnings
2020-10-08 01:18:34 -04:00
#[allow(clippy::large_enum_variant)]
Remove unused clone from states
2020-10-07 20:21:21 -04:00
#[derive(Debug)]
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
pub enum State {
State0(State0),
State1(State1),
State2(State2),
State3(State3),
State4(State4),
State5(State5),
State6(State6),
}
Remove duplicated macro definitions
2020-10-08 19:17:36 -04:00
impl_try_from_parent_enum!(State0, State);
impl_try_from_parent_enum!(State1, State);
impl_try_from_parent_enum!(State2, State);
impl_try_from_parent_enum!(State3, State);
impl_try_from_parent_enum!(State4, State);
impl_try_from_parent_enum!(State5, State);
impl_try_from_parent_enum!(State6, State);
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
Remove duplicated macro definitions
2020-10-08 19:17:36 -04:00
impl_from_child_enum!(State0, State);
impl_from_child_enum!(State1, State);
impl_from_child_enum!(State2, State);
impl_from_child_enum!(State3, State);
impl_from_child_enum!(State4, State);
impl_from_child_enum!(State5, State);
impl_from_child_enum!(State6, State);
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
impl State {
pub fn new<R: RngCore + CryptoRng>(
rng: &mut R,
btc: bitcoin::Amount,
xmr: monero::Amount,
refund_timelock: u32,
punish_timelock: u32,
redeem_address: bitcoin::Address,
punish_address: bitcoin::Address,
) -> Self {
Self::State0(State0::new(
rng,
btc,
xmr,
refund_timelock,
punish_timelock,
redeem_address,
punish_address,
))
}
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
}
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
#[derive(Debug, Deserialize, Serialize)]
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
pub struct State0 {
a: bitcoin::SecretKey,
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(with = "cross_curve_dleq_scalar")]
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
s_a: cross_curve_dleq::Scalar,
v_a: monero::PrivateViewKey,
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(with = "bitcoin_amount")]
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
btc: bitcoin::Amount,
xmr: monero::Amount,
refund_timelock: u32,
punish_timelock: u32,
redeem_address: bitcoin::Address,
punish_address: bitcoin::Address,
}
impl State0 {
pub fn new<R: RngCore + CryptoRng>(
rng: &mut R,
btc: bitcoin::Amount,
xmr: monero::Amount,
refund_timelock: u32,
punish_timelock: u32,
redeem_address: bitcoin::Address,
punish_address: bitcoin::Address,
) -> Self {
let a = bitcoin::SecretKey::new_random(rng);
let s_a = cross_curve_dleq::Scalar::random(rng);
let v_a = monero::PrivateViewKey::new_random(rng);
Self {
a,
s_a,
v_a,
redeem_address,
punish_address,
btc,
xmr,
refund_timelock,
punish_timelock,
}
}
pub fn next_message<R: RngCore + CryptoRng>(&self, rng: &mut R) -> Message0 {
let dleq_proof_s_a = cross_curve_dleq::Proof::new(rng, &self.s_a);
Message0 {
A: self.a.public(),
S_a_monero: monero::PublicKey::from_private_key(&monero::PrivateKey {
scalar: self.s_a.into_ed25519(),
}),
S_a_bitcoin: self.s_a.into_secp256k1().into(),
dleq_proof_s_a,
v_a: self.v_a,
redeem_address: self.redeem_address.clone(),
punish_address: self.punish_address.clone(),
}
}
pub fn receive(self, msg: bob::Message0) -> Result<State1> {
msg.dleq_proof_s_b.verify(
Update dependency to cross-curve-dleq and ecdsa_fun
2020-10-21 00:28:50 -04:00
msg.S_b_bitcoin.clone().into(),
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
msg.S_b_monero
.point
.decompress()
.ok_or_else(|| anyhow!("S_b is not a monero curve point"))?,
)?;
let v = self.v_a + msg.v_b;
Ok(State1 {
a: self.a,
B: msg.B,
s_a: self.s_a,
S_b_monero: msg.S_b_monero,
S_b_bitcoin: msg.S_b_bitcoin,
v,
btc: self.btc,
xmr: self.xmr,
refund_timelock: self.refund_timelock,
punish_timelock: self.punish_timelock,
refund_address: msg.refund_address,
redeem_address: self.redeem_address,
punish_address: self.punish_address,
})
}
}
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
#[derive(Debug, Deserialize, Serialize)]
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
pub struct State1 {
a: bitcoin::SecretKey,
B: bitcoin::PublicKey,
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(with = "cross_curve_dleq_scalar")]
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
s_a: cross_curve_dleq::Scalar,
S_b_monero: monero::PublicKey,
S_b_bitcoin: bitcoin::PublicKey,
v: monero::PrivateViewKey,
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(with = "bitcoin_amount")]
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
btc: bitcoin::Amount,
xmr: monero::Amount,
refund_timelock: u32,
punish_timelock: u32,
refund_address: bitcoin::Address,
redeem_address: bitcoin::Address,
punish_address: bitcoin::Address,
}
impl State1 {
pub fn receive(self, msg: bob::Message1) -> State2 {
State2 {
a: self.a,
B: self.B,
s_a: self.s_a,
S_b_monero: self.S_b_monero,
S_b_bitcoin: self.S_b_bitcoin,
v: self.v,
btc: self.btc,
xmr: self.xmr,
refund_timelock: self.refund_timelock,
punish_timelock: self.punish_timelock,
refund_address: self.refund_address,
redeem_address: self.redeem_address,
punish_address: self.punish_address,
tx_lock: msg.tx_lock,
}
}
}
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
#[derive(Debug, Deserialize, Serialize)]
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
pub struct State2 {
a: bitcoin::SecretKey,
B: bitcoin::PublicKey,
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(with = "cross_curve_dleq_scalar")]
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
s_a: cross_curve_dleq::Scalar,
S_b_monero: monero::PublicKey,
S_b_bitcoin: bitcoin::PublicKey,
v: monero::PrivateViewKey,
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(with = "bitcoin_amount")]
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
btc: bitcoin::Amount,
xmr: monero::Amount,
refund_timelock: u32,
punish_timelock: u32,
refund_address: bitcoin::Address,
redeem_address: bitcoin::Address,
punish_address: bitcoin::Address,
tx_lock: bitcoin::TxLock,
}
impl State2 {
pub fn next_message(&self) -> Message1 {
let tx_cancel = bitcoin::TxCancel::new(
&self.tx_lock,
self.refund_timelock,
self.a.public(),
self.B.clone(),
);
let tx_refund = bitcoin::TxRefund::new(&tx_cancel, &self.refund_address);
// Alice encsigns the refund transaction(bitcoin) digest with Bob's monero
// pubkey(S_b). The refund transaction spends the output of
// tx_lock_bitcoin to Bob's refund address.
// recover(encsign(a, S_b, d), sign(a, d), S_b) = s_b where d is a digest, (a,
// A) is alice's keypair and (s_b, S_b) is bob's keypair.
let tx_refund_encsig = self.a.encsign(self.S_b_bitcoin.clone(), tx_refund.digest());
let tx_cancel_sig = self.a.sign(tx_cancel.digest());
Message1 {
tx_refund_encsig,
tx_cancel_sig,
}
}
pub fn receive(self, msg: bob::Message2) -> Result<State3> {
let tx_cancel = bitcoin::TxCancel::new(
&self.tx_lock,
self.refund_timelock,
self.a.public(),
self.B.clone(),
);
bitcoin::verify_sig(&self.B, &tx_cancel.digest(), &msg.tx_cancel_sig)?;
let tx_punish =
bitcoin::TxPunish::new(&tx_cancel, &self.punish_address, self.punish_timelock);
bitcoin::verify_sig(&self.B, &tx_punish.digest(), &msg.tx_punish_sig)?;
Ok(State3 {
a: self.a,
B: self.B,
s_a: self.s_a,
S_b_monero: self.S_b_monero,
S_b_bitcoin: self.S_b_bitcoin,
v: self.v,
btc: self.btc,
xmr: self.xmr,
refund_timelock: self.refund_timelock,
punish_timelock: self.punish_timelock,
refund_address: self.refund_address,
redeem_address: self.redeem_address,
punish_address: self.punish_address,
tx_lock: self.tx_lock,
tx_punish_sig_bob: msg.tx_punish_sig,
tx_cancel_sig_bob: msg.tx_cancel_sig,
})
}
}
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
#[derive(Debug, Deserialize, Serialize)]
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
pub struct State3 {
Write action_generator_alice
2020-10-16 02:04:03 -04:00
pub a: bitcoin::SecretKey,
pub B: bitcoin::PublicKey,
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(with = "cross_curve_dleq_scalar")]
Write action_generator_alice
2020-10-16 02:04:03 -04:00
pub s_a: cross_curve_dleq::Scalar,
pub S_b_monero: monero::PublicKey,
pub S_b_bitcoin: bitcoin::PublicKey,
pub v: monero::PrivateViewKey,
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(with = "bitcoin_amount")]
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
btc: bitcoin::Amount,
Write action_generator_alice
2020-10-16 02:04:03 -04:00
pub xmr: monero::Amount,
pub refund_timelock: u32,
pub punish_timelock: u32,
pub refund_address: bitcoin::Address,
pub redeem_address: bitcoin::Address,
pub punish_address: bitcoin::Address,
pub tx_lock: bitcoin::TxLock,
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(with = "ecdsa_fun_signature")]
Write action_generator_alice
2020-10-16 02:04:03 -04:00
pub tx_punish_sig_bob: bitcoin::Signature,
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(with = "ecdsa_fun_signature")]
Write action_generator_alice
2020-10-16 02:04:03 -04:00
pub tx_cancel_sig_bob: bitcoin::Signature,
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
}
impl State3 {
pub async fn watch_for_lock_btc<W>(self, bitcoin_wallet: &W) -> Result<State4>
where
Loop on blockchain call instead of delaying Previously there was a delay making a get raw transaction call to give some time for a transaction to be confirmed on the blockchain. This has been replaced with a loop that waits until the call is succesful.
2020-10-07 19:53:30 -04:00
W: bitcoin::WatchForRawTransaction,
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
{
Add context to log messages
2020-10-08 17:49:17 -04:00
tracing::info!("watching for lock btc with txid: {}", self.tx_lock.txid());
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
let tx = bitcoin_wallet
Loop on blockchain call instead of delaying Previously there was a delay making a get raw transaction call to give some time for a transaction to be confirmed on the blockchain. This has been replaced with a loop that waits until the call is succesful.
2020-10-07 19:53:30 -04:00
.watch_for_raw_transaction(self.tx_lock.txid())
Make bitcoin::WatchForRawTransaction infallible And trigger refund if Alice's redeem transaction takes too long.
2020-10-15 06:17:42 -04:00
.await;
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
Add context to log messages
2020-10-08 17:49:17 -04:00
tracing::info!("tx lock seen with txid: {}", tx.txid());
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
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
Ok(State4 {
a: self.a,
B: self.B,
s_a: self.s_a,
S_b_monero: self.S_b_monero,
S_b_bitcoin: self.S_b_bitcoin,
v: self.v,
btc: self.btc,
xmr: self.xmr,
refund_timelock: self.refund_timelock,
punish_timelock: self.punish_timelock,
refund_address: self.refund_address,
redeem_address: self.redeem_address,
punish_address: self.punish_address,
tx_lock: self.tx_lock,
tx_punish_sig_bob: self.tx_punish_sig_bob,
tx_cancel_sig_bob: self.tx_cancel_sig_bob,
})
}
}
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
#[derive(Debug, Deserialize, Serialize)]
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
pub struct State4 {
a: bitcoin::SecretKey,
B: bitcoin::PublicKey,
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(with = "cross_curve_dleq_scalar")]
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
s_a: cross_curve_dleq::Scalar,
S_b_monero: monero::PublicKey,
S_b_bitcoin: bitcoin::PublicKey,
v: monero::PrivateViewKey,
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(with = "bitcoin_amount")]
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
btc: bitcoin::Amount,
xmr: monero::Amount,
refund_timelock: u32,
punish_timelock: u32,
refund_address: bitcoin::Address,
redeem_address: bitcoin::Address,
punish_address: bitcoin::Address,
tx_lock: bitcoin::TxLock,
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(with = "ecdsa_fun_signature")]
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
tx_punish_sig_bob: bitcoin::Signature,
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(with = "ecdsa_fun_signature")]
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
tx_cancel_sig_bob: bitcoin::Signature,
}
impl State4 {
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
pub async fn lock_xmr<W>(self, monero_wallet: &W) -> Result<State5>
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
where
W: monero::Transfer,
{
let S_a = monero::PublicKey::from_private_key(&monero::PrivateKey {
scalar: self.s_a.into_ed25519(),
});
let S_b = self.S_b_monero;
let (tx_lock_proof, fee) = monero_wallet
.transfer(S_a + S_b, self.v.public(), self.xmr)
.await?;
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
Ok(State5 {
a: self.a,
B: self.B,
s_a: self.s_a,
S_b_monero: self.S_b_monero,
S_b_bitcoin: self.S_b_bitcoin,
v: self.v,
btc: self.btc,
xmr: self.xmr,
refund_timelock: self.refund_timelock,
punish_timelock: self.punish_timelock,
refund_address: self.refund_address,
redeem_address: self.redeem_address,
punish_address: self.punish_address,
tx_lock: self.tx_lock,
tx_lock_proof,
tx_punish_sig_bob: self.tx_punish_sig_bob,
tx_cancel_sig_bob: self.tx_cancel_sig_bob,
lock_xmr_fee: fee,
})
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
}
pub async fn punish<W: bitcoin::BroadcastSignedTransaction>(
&self,
bitcoin_wallet: &W,
) -> Result<()> {
let tx_cancel = bitcoin::TxCancel::new(
&self.tx_lock,
self.refund_timelock,
self.a.public(),
self.B.clone(),
);
let tx_punish =
bitcoin::TxPunish::new(&tx_cancel, &self.punish_address, self.punish_timelock);
{
let sig_a = self.a.sign(tx_cancel.digest());
let sig_b = self.tx_cancel_sig_bob.clone();
let signed_tx_cancel = tx_cancel.clone().add_signatures(
&self.tx_lock,
(self.a.public(), sig_a),
(self.B.clone(), sig_b),
)?;
let _ = bitcoin_wallet
.broadcast_signed_transaction(signed_tx_cancel)
.await?;
}
{
let sig_a = self.a.sign(tx_punish.digest());
let sig_b = self.tx_punish_sig_bob.clone();
let signed_tx_punish = tx_punish.add_signatures(
&tx_cancel,
(self.a.public(), sig_a),
(self.B.clone(), sig_b),
)?;
let _ = bitcoin_wallet
.broadcast_signed_transaction(signed_tx_punish)
.await?;
}
Ok(())
}
}
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
#[derive(Debug, Deserialize, Serialize)]
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
pub struct State5 {
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
a: bitcoin::SecretKey,
B: bitcoin::PublicKey,
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(with = "cross_curve_dleq_scalar")]
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
s_a: cross_curve_dleq::Scalar,
S_b_monero: monero::PublicKey,
S_b_bitcoin: bitcoin::PublicKey,
v: monero::PrivateViewKey,
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(with = "bitcoin_amount")]
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
btc: bitcoin::Amount,
xmr: monero::Amount,
refund_timelock: u32,
punish_timelock: u32,
refund_address: bitcoin::Address,
redeem_address: bitcoin::Address,
punish_address: bitcoin::Address,
tx_lock: bitcoin::TxLock,
tx_lock_proof: monero::TransferProof,
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(with = "ecdsa_fun_signature")]
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
tx_punish_sig_bob: bitcoin::Signature,
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(with = "ecdsa_fun_signature")]
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
tx_cancel_sig_bob: bitcoin::Signature,
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
lock_xmr_fee: monero::Amount,
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
}
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
impl State5 {
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
pub fn next_message(&self) -> Message2 {
Message2 {
tx_lock_proof: self.tx_lock_proof.clone(),
}
}
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
pub fn receive(self, msg: bob::Message3) -> State6 {
State6 {
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
a: self.a,
B: self.B,
s_a: self.s_a,
S_b_monero: self.S_b_monero,
S_b_bitcoin: self.S_b_bitcoin,
v: self.v,
btc: self.btc,
xmr: self.xmr,
refund_timelock: self.refund_timelock,
punish_timelock: self.punish_timelock,
refund_address: self.refund_address,
redeem_address: self.redeem_address,
punish_address: self.punish_address,
tx_lock: self.tx_lock,
tx_punish_sig_bob: self.tx_punish_sig_bob,
tx_redeem_encsig: msg.tx_redeem_encsig,
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
lock_xmr_fee: self.lock_xmr_fee,
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
}
}
// watch for refund on btc, recover s_b and refund xmr
pub async fn refund_xmr<B, M>(self, bitcoin_wallet: &B, monero_wallet: &M) -> Result<()>
where
Loop on blockchain call instead of delaying Previously there was a delay making a get raw transaction call to give some time for a transaction to be confirmed on the blockchain. This has been replaced with a loop that waits until the call is succesful.
2020-10-07 19:53:30 -04:00
B: WatchForRawTransaction,
Rename ImportOutput to reflect purpose
2020-10-07 20:27:54 -04:00
M: CreateWalletForOutput,
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
{
let tx_cancel = bitcoin::TxCancel::new(
&self.tx_lock,
self.refund_timelock,
self.a.public(),
self.B.clone(),
);
let tx_refund = bitcoin::TxRefund::new(&tx_cancel, &self.refund_address);
let tx_refund_encsig = self.a.encsign(self.S_b_bitcoin.clone(), tx_refund.digest());
Loop on blockchain call instead of delaying Previously there was a delay making a get raw transaction call to give some time for a transaction to be confirmed on the blockchain. This has been replaced with a loop that waits until the call is succesful.
2020-10-07 19:53:30 -04:00
let tx_refund_candidate = bitcoin_wallet
.watch_for_raw_transaction(tx_refund.txid())
Make bitcoin::WatchForRawTransaction infallible And trigger refund if Alice's redeem transaction takes too long.
2020-10-15 06:17:42 -04:00
.await;
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
let tx_refund_sig =
tx_refund.extract_signature_by_key(tx_refund_candidate, self.a.public())?;
let s_b = bitcoin::recover(self.S_b_bitcoin, tx_refund_sig, tx_refund_encsig)?;
let s_b =
monero::PrivateKey::from_scalar(monero::Scalar::from_bytes_mod_order(s_b.to_bytes()));
let s = s_b.scalar + self.s_a.into_ed25519();
// NOTE: This actually generates and opens a new wallet, closing the currently
// open one.
monero_wallet
Rename ImportOutput to reflect purpose
2020-10-07 20:27:54 -04:00
.create_and_load_wallet_for_output(monero::PrivateKey::from_scalar(s), self.v)
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
.await?;
Ok(())
}
}
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
#[derive(Debug, Deserialize, Serialize)]
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
pub struct State6 {
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
a: bitcoin::SecretKey,
B: bitcoin::PublicKey,
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(with = "cross_curve_dleq_scalar")]
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
s_a: cross_curve_dleq::Scalar,
S_b_monero: monero::PublicKey,
S_b_bitcoin: bitcoin::PublicKey,
v: monero::PrivateViewKey,
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(with = "bitcoin_amount")]
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
btc: bitcoin::Amount,
xmr: monero::Amount,
refund_timelock: u32,
punish_timelock: u32,
refund_address: bitcoin::Address,
redeem_address: bitcoin::Address,
punish_address: bitcoin::Address,
tx_lock: bitcoin::TxLock,
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(with = "ecdsa_fun_signature")]
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
tx_punish_sig_bob: bitcoin::Signature,
tx_redeem_encsig: EncryptedSignature,
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
lock_xmr_fee: monero::Amount,
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
}
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
impl State6 {
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
pub async fn redeem_btc<W: bitcoin::BroadcastSignedTransaction>(
&self,
bitcoin_wallet: &W,
) -> Result<()> {
let adaptor = Adaptor::<Sha256, Deterministic<Sha256>>::default();
let tx_redeem = bitcoin::TxRedeem::new(&self.tx_lock, &self.redeem_address);
let sig_a = self.a.sign(tx_redeem.digest());
let sig_b =
adaptor.decrypt_signature(&self.s_a.into_secp256k1(), self.tx_redeem_encsig.clone());
let sig_tx_redeem = tx_redeem.add_signatures(
&self.tx_lock,
(self.a.public(), sig_a),
(self.B.clone(), sig_b),
)?;
bitcoin_wallet
.broadcast_signed_transaction(sig_tx_redeem)
.await?;
Ok(())
}
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
pub fn lock_xmr_fee(&self) -> monero::Amount {
self.lock_xmr_fee
}
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
}
Reference in New Issue Copy Permalink