fix(tpu-v2): fix tpu-v2 wait for payment spend and extract secret #2261

laruh · 2024-11-01T06:58:04Z

In TakerCoinSwapOpsV2 trait wait_for_taker_payment_spend function was renamed to find_taker_payment_spend_tx (to avoid misunderstanding with wait_for_confirmation logic)

In EthCoin function find_taker_payment_spend_tx_impl was provided for trait find_taker_payment_spend_tx method
Added new extract_secret_v2 method in TakerCoinSwapOpsV2 trait. implemented for UTXO and EthCoin.
Did it as EthCoin legacy extract_secret doesnt fit TPU V2, so its better to require extract_secret_v2 for coins.
in lp_connect_start_bob and in lp_connected_alice provided fallback to legacy swap protocol.

Legacy fallback happens when:
user sets ctx.use_trading_proto_v2() as false, or other trading side uses legacy swap protocol, then even if user set ctx.use_trading_proto_v2() as true, they have to use legacy swap as well.
Other reason of starting legacy swap, even if ctx.use_trading_proto_v2() is true, is the trading coin which doesnt support TPU V2

~~- provide swap protocol version #2112 (review)~~ reverted

handle require confirmations before changing taker/maker swap state as Completed
Note: you can find the implementation above this line in taker_swap_v2.rs and in maker_swap_v2.rs

Self::change_state(Completed::new(), state_machine).await

moved SecretHashAlgo to crypto lib and provided detect_secret_hash_algo_v2 function for TPU (starting from this commit c1a5063)
ETH coin should use SHA256 in TPU.

laruh · 2024-11-05T09:44:38Z

ps: will resolve conflicts or cherrypick commits in new up to date branch after eth-maker-tpu-v2 merge #2211

…aker_payment_spend to TakerPaymentSpent

…aker's spendTakerPayment transaction on chain

…t_secret_v2

mariocynicys

thanks, first iteration

mm2src/coins/eth.rs

mariocynicys · 2024-11-11T19:58:48Z

mm2src/coins/eth/eth_swap_v2/eth_taker_swap_v2.rs

+
+            // get all logged TakerPaymentSpent events from `from_block` till current block
+            let events = match self
+                .events_from_block(taker_swap_v2_contract, "TakerPaymentSpent", from_block, current_block)


shouldn't we advance from_block if the event wasn't found?

shouldn't we advance from_block if the event wasn't found?

Shouldn't change blocks range, It introduces risks to skip necessary block.

Receiving empty events list does not necessarily indicate that there are no events, network latency can cause delays in the propagation and indexing of event logs even after a transaction is mined.
After a transaction is mined, the logs related to it need to be extracted and made available for querying. This process is not instantaneous.

Also we dont know all the nuances and differences of all blockchains. It is much safer to keep block range starting from swap start block.

UPD: l suggest to add if events.is_empty check to continue loop without moving forward
UPD2: added is empty check 8d5ed46

mm2src/coins/eth/eth_swap_v2/eth_taker_swap_v2.rs

mariocynicys · 2024-11-11T20:01:07Z

mm2src/coins/eth/eth_swap_v2/eth_taker_swap_v2.rs

+            let found_event = events.into_iter().find(|event| &event.data.0[..32] == id.as_slice());
+
+            if let Some(event) = found_event {
+                if let Some(tx_hash) = event.transaction_hash {


will this ever be None? will this be a recoverable state then? otherwise we can terminate early.

will this ever be None?

are you talking about event.transaction_hash? This type is from a dependency, we should handle it as it is. The transaction_hash could be None if the log is emitted by a transaction in a pending state. Once the transaction is included in a mined block, the value should be Some.

will this be a recoverable state then?

For TPU V2 we aim to have automatic recover process, if find_taker_payment_spend_tx return error then refund process will be started

komodo-defi-framework/mm2src/mm2_main/src/lp_swap/taker_swap_v2.rs

Lines 1698 to 1716 in c700b59

let taker_payment_spend = match state_machine

.taker_coin

.find_taker_payment_spend_tx(

&self.taker_payment,

self.taker_coin_start_block,

state_machine.taker_payment_locktime(),

)

.await

{

Ok(tx) => tx,

Err(e) => {

let next_state = TakerPaymentRefundRequired {

taker_payment: self.taker_payment,

negotiation_data: self.negotiation_data,

reason: TakerPaymentRefundReason::MakerDidNotSpendInTime(format!("{}", e)),

};

return Self::change_state(next_state, state_machine).await;

},

};

otherwise we can terminate early

Could clarify what do you mean by termination? You want to return error and break loop?
We should try to find transaction in the loop until time is out

The transaction_hash could be None if the log is emitted by a transaction in a pending state. Once the transaction is included in a mined block, the value should be Some.

aren't we getting events till the current mined block? so this tx shouldn't be pending?

For TPU V2 we aim to have automatic recover process

I just meant we can not do nothing about the fact that tx hash is none.
nothing to do with swap recovery.

how I was thinking (which might be wrong) is that some event types don't have a tx hash which means we supplied a bad event id from the beginning meaning that we can't proceed further. this might not be the case though, gotta read more about this, excuse my eth illiteracy 😂

aren't we getting events till the current mined block? so this tx shouldn't be pending?

yeah, you are right as we are using from and to block filters for eth_getLogs API, tx should be confirmed

async fn events_from_block( &self, swap_contract_address: Address, event_name: &str, from_block: u64, to_block: u64, ) -> MmResult<Vec<Log>, FindPaymentSpendError> { let contract_event = TAKER_SWAP_V2.event(event_name)?; let filter = FilterBuilder::default() .topics(Some(vec![contract_event.signature()]), None, None, None) .from_block(BlockNumber::Number(from_block.into())) .to_block(BlockNumber::Number(to_block.into())) .address(vec![swap_contract_address]) .build(); let events_logs = self .logs(filter) .await .map_err(|e| FindPaymentSpendError::Transport(e.to_string()))?; Ok(events_logs) }

some event types don't have a tx hash

I think you are confused a bit. Events/logs themselves don't necessarily contain the transaction hash. Instead, the transaction hash is associated with the transaction that emitted the event. So Log type from web3 just contains info about tx which emitted this log.

Note about event and log words. event in Solidity is a way for a contract to emit logs during the execution of a function.
So they are close words, just events refer to the Solidity construct used in the smart contract to emit logs, while logs refer to the actual data that is recorded in the blockchain when events are emitted.

So using from to block range we are looking for Log which was emitted by spend taker payment transaction.

As for empty tx hash I would like to refer to previous comment #2261 (comment) empty event list or none transaction_hash are not 100% that there is no tx which we are looking for, it could be just blockchain indexation delays or other reasons.

i will read further regarding the truncated (not necessarily empty? right?) event list issue, any resourced regarding the indexaction delay issues and such would be so helpful!

regarding an event not having a transaction_hash thought, how would we successfully get the event which has None for the transaction_hash and then try again and all of a sudden we get a Some transaction_hash! is that possible? are these event logs mutable?

i will read further regarding the truncated (not necessarily empty? right?) event list issue, any resourced regarding the indexaction delay issues and such would be so helpful!

I would say that chain reorganization, network latency, node synchronization lag issues could cause missing information issues. These problems usually temporarily, as I understand. You should wait for more confirmed blocks also try to fetch the info from different nodes.

regarding an event not having a transaction_hash thought, how would we successfully get the event which has None for the transaction_hash and then try again and all of a sudden we get a Some transaction_hash! is that possible? are these event logs mutable?

Logs are not mutable. Also they are tied to transactions. When a transaction calls a smart contract function that emits an event, this event generates log, which is permanently recorded in the blockchain.

But there’s a nuance. Lest check doc. According to the documentation https://www.chainnodes.org/docs/ethereum/eth_getLogs, a log from a pending transaction might lack a transaction hash, but when the transaction is confirmed, the log should include it.

Therefore, ideally, when we request a list of logs using the events_from_block function with from_block and to_block filters, it should return only logs from confirmed blocks, which means confirmed transactions. In this case, event.transaction_hash should ideally always be Some.

komodo-defi-framework/mm2src/coins/eth/eth_swap_v2/eth_taker_swap_v2.rs

Lines 530 to 531 in 8d5ed46

if let Some(event) = found_event {

if let Some(tx_hash) = event.transaction_hash {

We dont need to change from_block. However, if Log has transaction_hash:None, it doesn't mean Log doesn't have transaction (actually its not correct by itself, as logs are not owners of txs), it means smth went wrong as eth_getLogs API with fromBlock and toBlock filters will use confirmed blocks.

Some additional info https://docs.alchemy.com/docs/deep-dive-into-eth_getlogs#what-are-logs-or-events

Logs and events are used synonymously—smart contracts generate logs by firing off events, so logs provide insights into events that occur within the smart contract. Logs can be found on transaction receipts.

Anytime a transaction is mined, we can see event logs for that transaction by making a request to eth_getLogs and then take actions based off those results. For example, if a purchase is being made using crypto payments, we can use eth_getLogs to see if the sender successfully made the payment before providing the item purchased.

However, if Log has transaction_hash:None, it doesn't mean Log doesn't have transaction, it means smth went wrong as eth_getLogs API with fromBlock and toBlock filters will use confirmed blocks.

im missing u between the lines here so let me repeat that to you and see if i got it correctly. transaction_hash MUST always be Some eventually, if it was None this is a temporary reporting/mining/etc... thing.

However, if Log has transaction_hash:None, it doesn't mean Log doesn't have transaction, it means smth went wrong as eth_getLogs API with fromBlock and toBlock filters will use confirmed blocks.

im missing u between the lines here so let me repeat that to you and see if i got it correctly. transaction_hash MUST always be Some eventually, if it was None this is a temporary reporting/mining/etc... thing.

Yes, in the context of not using "pending" tag in "eth_getLogs" API, we expect transaction_hash always be Some.
The best we can do is to repeat loop cycle until time is out, if None occurred.

mm2src/mm2_main/src/lp_ordermatch.rs

onur-ozkan · 2024-11-12T08:40:02Z

Could you add some PR description to describe the work and help us on review?

laruh · 2024-11-12T09:13:47Z

Could you add some PR description to describe the work and help us on review?

Updated PR description

…nts.is_empty() check, rename with_tpu_version function.

mm2src/coins/eth/eth_swap_v2/eth_taker_swap_v2.rs

dimxy · 2024-11-13T18:12:30Z

mm2src/mm2_main/src/lp_ordermatch.rs

@@ -1167,6 +1171,9 @@ pub struct TakerRequest {
    #[serde(default)]
    #[serde(skip_serializing_if = "Option::is_none")]
    pub rel_protocol_info: Option<Vec<u8>>,
+    #[serde(default)]
+    #[serde(skip_serializing_if = "Option::is_none")]
+    pub swap_version: Option<u32>,


I think this swap_version is needed to differentiate between legacy and TPU swaps.
I'd suggest making it a enum (Legacy/TPU) instead of numeric.
I believe a numeric 'version' is what we can change regularly (like improving protocol between nodes).

I'd suggest making it a enum (Legacy/TPU) instead of numeric.

TPU is already a numeric, we call ongoing update as Trading Protocol Upgrade V2 also we have swap v2 naming in repo.

I believe a numeric 'version' is what we can change regularly (like improving protocol between nodes).

I think it doesn't matter is it regular or rare, every swap protocol update which breaks backward compatibility and forces all seed nodes to be updated requires the version bump.

I suggest to keep versioning simple, where we treat legacy as v1 or none.
I think I will make field non optional and provide necessary functions for default and skip_serializing_if annotations, to not do None and Some(1) checks for legacy

where we treat legacy as v1

Also, its logically to think about legacy as v1 version as our tpu is starting from 2 not 1

simplified swap_version field 707946a

also please join the discussion if you think you have smth to add
#2261 (comment)

I think legacy and TPU are not versions in fact, but two different algorithms.
(I am concerned, because I added a version field in another PR which will be increased when we add/remove features to the swap protocol. I think it may be confusing to have several version fields so adding a scope to it, where it possible, would help to better understand code)

I think legacy and TPU are not versions in fact, but two different algorithms.

Ummm, we can consider them as backward incompatible versions with each other. Tbh i am all for it for having just one version field that controls minor features and swap protocol used, this is simpler than using multiple versions.

edit: also what about an enum encabsulating the minor version/feature:

enum SwapVersion { #[default] Legacy(u32), TPU(u32), ... }

So its about messages versioning within some protocol, not protocol version itself? Correct me if I understood it wrong.

well, in daemons code they call it 'protocol version' and change each time whenever any, even slight-less, change in p2p messages occurs, this number just grows steadily.
If we want it to reflect that this is legacy or tpu we need to make it structured to provide space for numbering change (but this is maybe not needed as both message flows do not mix)

or what protocol are you providing inside legacy swap protocol?

No problem with msg, I named it 'protocol' like in daemons code.

That might be in the swap negotiation layer or better in the order matching layer

I implemented this for legacy at the negotiation level in #2112
I guess for order matching we would need this as well (if we may add new swap types or features)
But I think for order matching versoning will change more rarely

I guess for order matching we would need this as well (if we may add new swap types or features)
But I think for order matching versoning will change more rarely

I meant it would be better off having such negotiation params agreed upon before matching the order to the taker. This doesn't really shine in the burn case since we consider it as optional feature (if the other peer doesn't support it we will just proceed without burn), but if we wanna mark the feature/fix as required, then such a swap will fail after starting, in which case not starting it was the efficient choice to avoid locking funds etc...

As for ordermatching, this pr introduces swap_version in Taker and Maker orders

mariocynicys · 2024-12-11T11:07:49Z

mm2src/mm2_main/src/lp_swap/taker_swap_v2.rs

@@ -432,6 +434,9 @@ impl<MakerCoin: MmCoin + MakerCoinSwapOpsV2, TakerCoin: MmCoin + TakerCoinSwapOp

    fn taker_payment_locktime(&self) -> u64 { self.started_at + self.lock_duration }

+    #[inline]
+    fn spend_maker_payment_conf_timeout(&self) -> u64 { self.started_at + 4 * self.lock_duration }


why 4*lock duration?
also could we rename this to maker_payment_spend.. instead of spend_maker_payment..

fixed names 2d80017

I took 3 * self.lock_duration for maker to confirm spend taker payment tx, as this is the maximum time on taker (funding) locktime.
And 4 * on taker side for spend maker payment tx, as taker spends some time searching for maker's transaction to extract secret.
These functions are supposed to be used on PaymentSpent state to be sure that trader got their payment and spend tx is confirmed. So I think final conf timeouts should have big multipliers. Do you think we should increase constants?

Do you think we should increase constants?

The opposite actually. Let me first mention the lock times of each swaps tx since these confuse me:

funding -> 3T

maker payment -> 2T

taker payment -> 1T

taker payment spend - no locktime

maker payment spend - no locktime

So.

If the taker payment spend doesn't wanna confirm in time, as a maker, you want to refund your own maker payment ASAP, so after 2T (given that it wasn't even already spent, which is very unlikely).
Same holds for the maker payment spend. you, as a taker, would want to refund your taker payment ASAP if the maker payment spend is stuck (given that it wasn't even already spent, which is much more unlikely since the taker knew the secret from the spend of the taker payment in the first place).

let me spawn @shamardy here in this case since these locktimes scare me :)

after writing that, im not even sure if waiting for these txs to be confirmed makes sense anymore haha.
these locktimes are part of the atomicity guarantees of the atomic swap. they are in place to make sure you are able to spend and get your spend confirmed before the other party can initiate a refund.
if we can't confirm within these locktimes, we are ... just screwed :)

if we can't confirm within these locktimes, we are ... just screwed :)

Could you clarify what do mean by "locktimes". For confirmations we have _conf_timeout functions.

As for PeymentSpent state, if confirmation time is out there is still a chance that trader could spent payment on TakerPaymentRefundRequired/MakerPaymentRefundRequired. We are going to have smth similar you do on legacy. Try to spend or refund. This step should be fine.

Well I think fn maker_payment_conf_timeout(&self) -> u64 { self.started_at + self.lock_duration / 3 } could be bigger (as an example). But still this potential fail is covered by if !state_machine.require_maker_payment_confirm_before_funding_spend { and if state_machine.require_maker_payment_confirm_before_funding_spend {. Maker shouldn't get taker's payment. So both should refund.

btw this is how we calc locktime

komodo-defi-framework/mm2src/mm2_main/src/lp_swap.rs

Lines 782 to 793 in 2d80017

/// Some coins are "slow" (block time is high - e.g. BTC average block time is ~10 minutes).

/// https://bitinfocharts.com/comparison/bitcoin-confirmationtime.html

/// We need to increase payment locktime accordingly when at least 1 side of swap uses "slow" coin.

pub fn lp_atomic_locktime(maker_coin: &str, taker_coin: &str, version: AtomicLocktimeVersion) -> u64 {

match version {

AtomicLocktimeVersion::V1 => lp_atomic_locktime_v1(maker_coin, taker_coin),

AtomicLocktimeVersion::V2 {

my_conf_settings,

other_conf_settings,

} => lp_atomic_locktime_v2(maker_coin, taker_coin, &my_conf_settings, &other_conf_settings),

}

}

This relates to what I and @Alrighttt mentioned before, taker should act selfishly, same for maker. They should always try refund or spend/confirm endlessly until one of them works, refunds also need confirmations. Maybe refunds can start to be tried after lock time (1T) has passed but with refunds they need to check spend and spend confirmations as well like how we are currently fixing for legacy swaps here #2280

after writing that, im not even sure if waiting for these txs to be confirmed makes sense anymore haha.
these locktimes are part of the atomicity guarantees of the atomic swap. they are in place to make sure you are able to spend and get your spend confirmed before the other party can initiate a refund.
if we can't confirm within these locktimes, we are ... just screwed :)

True, we need rebroadcasting of spend transactions and trying multiple channels (multiple RPCs, p2p tx helper thing, etc...). It's a hard problem to fix with the current code and state machine. There is a case of malicious RPC nodes that give bad secret which is why the most general solution is trying refunding as well in parallel. For this PR, we don't need the general complete solution yet. We can wait for confirmations for 1T and TakerPaymentRefundRequired means that we move to a state of trying to spend or refund like how it's being fixed in legacy swaps.

But after thinking about this more, using state machine, it's easier to solve than legacy swaps as we can move to different states easily, trying spending then refunding, etc.. by new state transitions :)

We might need to implement/modify this to a different type of state machine that is called nondeterministic finite automata (NFAs) where the current state is a set, so refunding and confirmation of refunding is tried while spending and confirmation of spending is tried at the same time and we move to the next state if either of those is successful. Sorry if I complicated this more 😅

I would rename state to TakerPaymentRefundOrSpendRequired then.

We can wait for confirmations for 1T and TakerPaymentRefundRequired means that we move to a state of trying to spend or refund like how it's being fixed in legacy swaps.

We might need to implement/modify this to a different type of state machine that is called nondeterministic finite automata (NFAs) where the current state is a set, so refunding and confirmation of refunding is tried while spending and confirmation of spending is tried at the same time and we move to the next state if either of those is successful.

Yes, we can implement one of these approaches (probably its better to just follow the first one in the current state machine) as the next step after #2280 merge

mariocynicys · 2024-12-11T11:10:15Z

mm2src/mm2_main/src/lp_swap/maker_swap_v2.rs

+    #[inline]
+    fn spend_taker_payment_conf_timeout(&self) -> u64 { self.started_at + 3 * self.lock_duration }
+


why 3 * locktime?
also the same for spend_taker.. -> taker_payment_spend

mm2src/mm2_main/src/lp_swap/maker_swap_v2.rs

mm2src/mm2_main/src/lp_swap/taker_swap_v2.rs

mm2src/coins/lp_coins.rs

mm2src/mm2_main/src/lp_ordermatch.rs

mariocynicys · 2024-12-11T11:39:27Z

mm2src/mm2_main/tests/docker_tests/swap_proto_v2_tests.rs

-        block_on(wait_for_swap_finished(&mm_bob, &uuid, 60));
-        block_on(wait_for_swap_finished(&mm_alice, &uuid, 30));
+        block_on(wait_for_swap_finished(&mm_bob, &uuid, 180));
+        block_on(wait_for_swap_finished(&mm_alice, &uuid, 100));


Q: why were these increased.

hmm dont remember, I think there were some issues during development so tests were failing.
returned old seconds, works fine

mm2src/mm2_main/src/lp_ordermatch.rs

…_taker_payment_spend_confirm

…m above fn lp_connect

…_tests.rs

laruh · 2024-12-16T14:27:21Z

@shamardy @mariocynicys @dimxy I reverted swap version f8ba975 to not to block this PR

…yment-spend

mariocynicys · 2024-12-25T11:29:06Z

mm2src/mm2_main/src/lp_ordermatch/my_orders_storage.rs

@@ -706,6 +706,8 @@ mod tests {

    wasm_bindgen_test_configure!(run_in_browser);

+    const LEGACY_SWAP_V: u32 = 1;


this is no longer needed.

mariocynicys · 2024-12-25T11:35:27Z

mm2src/mm2_main/src/lp_ordermatch.rs

+        let taker_p2p_pubkey = match taker_p2p_pubkey {
+            PublicKey::Secp256k1(pubkey) => pubkey.into(),
+        };


such a deterministic match looks so weird 😂

*this is not part of the review, i am sure it's in a lot of place, we should tackle this weird stuff later when refactoring

mariocynicys · 2024-12-25T11:46:28Z

mm2src/mm2_main/src/lp_swap/taker_swap_v2.rs

+    /// Determines if the maker payment spend transaction must be confirmed before marking swap as Completed.
+    pub require_maker_payment_spend_confirm: bool,


as per our conversation thread here: #2261 (comment)

i think this flag doesn't make sense anymore

i think this flag doesn't make sense anymore

Discussion you're referencing is about making wait for confirmation time equal one lock time after adding refund or spend functionality to TPU

mariocynicys · 2024-12-25T12:23:40Z

mm2src/coins/eth/eth_swap_v2/mod.rs

+    pub(crate) swap_contract_address: Address,
+    pub(crate) event_name: &'a str,
+    pub(crate) abi_contract: &'a Contract,
+    pub(crate) swap_id: &'a [u8],


can we add size type to this if possible

mariocynicys · 2024-12-25T12:25:39Z

mm2src/coins/eth/eth_swap_v2/mod.rs

+    }
+}
+
+pub(crate) struct SpendTxSearchParams<'a> {


nit: we can move this above to before using it.

mariocynicys · 2024-12-25T12:26:40Z

mm2src/coins/eth/eth_swap_v2/mod.rs

+                        // Move to next window if there was an error
+                        next_from_block += self.logs_block_range;
+                        continue;


why? we might skip important blocks this way.

mariocynicys · 2024-12-25T12:45:48Z

mm2src/coins/eth/eth_swap_v2/eth_taker_swap_v2.rs

+
+fn get_dex_fee_and_amount_from_eth_payment_data(
+    decoded: &Vec<Token>,
+    tx_value: U256,
+) -> Result<(U256, U256), PrepareTxDataError> {
+    check_decoded_length(decoded, 7)?;
+    let dex_fee = match decoded.get(1) {
+        Some(Token::Uint(dex_fee)) => *dex_fee,
+        _ => {
+            return Err(PrepareTxDataError::Internal(format!(
+                "Invalid token type for dex fee, got decoded function data: {:?}",
+                decoded
+            )))
+        },
+    };
+    let amount = tx_value
+        .checked_sub(dex_fee)
+        .ok_or_else(|| PrepareTxDataError::Internal("Underflow occurred while calculating amount".into()))?;
+    Ok((dex_fee, amount))
+}


nit: this file is slowly following the path of its bigger brother eth.rs with these global functions being added :)

laruh added the in progress label Nov 1, 2024

laruh mentioned this pull request Nov 1, 2024

feat(eth-swap): maker tpu v2 implementation #2211

Merged

laruh force-pushed the fix-tpu-v2-wait-for-payment-spend branch 2 times, most recently from a6052b3 to 6f0d1a6 Compare November 4, 2024 05:27

Base automatically changed from eth-maker-tpu-v2 to dev November 8, 2024 14:10

laruh added 9 commits November 8, 2024 21:48

add wait_for_maker_payment_spend to MakerPaymentSpent, add wait_for_t…

9d7f476

…aker_payment_spend to TakerPaymentSpent

support Eth in lp bob/alice and use start_taker/maker_swap_state_machine

de3a970

use wait_for_confirmations in MakerPaymentSpent and in TakerPaymentSpent

ea5475b

rename wait_for_taker_payment_spend to find_taker_payment_spend_tx

934a2f0

EthCoin find_taker_payment_spend_tx_impl function now tries to find m…

ca0ee56

…aker's spendTakerPayment transaction on chain

provide extract_secret_v2 in TakerSwapOpsV2, implement EthCoin extrac…

9449cca

…t_secret_v2

reuse utxo extract_secret_v2 in legacy extract_secret

2e65abf

eth extract_secret_v2 tests

43a1baf

cargo fmt

c700b59

laruh force-pushed the fix-tpu-v2-wait-for-payment-spend branch from 35ed147 to c700b59 Compare November 8, 2024 14:59

laruh marked this pull request as ready for review November 8, 2024 15:00

shamardy added P2 and removed in progress labels Nov 11, 2024

mariocynicys reviewed Nov 11, 2024

View reviewed changes

review: remove unnecessary param from extract_secret_v2_impl, add eve…

8d5ed46

…nts.is_empty() check, rename with_tpu_version function.

dimxy reviewed Nov 13, 2024

View reviewed changes

mm2src/coins/eth/eth_swap_v2/eth_taker_swap_v2.rs Outdated Show resolved Hide resolved

dimxy reviewed Nov 13, 2024

View reviewed changes

mm2src/coins/eth/eth_swap_v2/eth_taker_swap_v2.rs Outdated Show resolved Hide resolved

dimxy reviewed Nov 13, 2024

View reviewed changes

mm2src/coins/eth/eth_swap_v2/eth_taker_swap_v2.rs Outdated Show resolved Hide resolved

dimxy reviewed Nov 13, 2024

View reviewed changes

mm2src/coins/eth/eth_swap_v2/eth_taker_swap_v2.rs Outdated Show resolved Hide resolved

dimxy reviewed Nov 13, 2024

View reviewed changes

review: simplify "swap_version" field type, make it non-optional

707946a

laruh added under review and removed in progress labels Dec 11, 2024

mariocynicys reviewed Dec 11, 2024

View reviewed changes

laruh added 7 commits December 11, 2024 20:45

review: fix taker payment log message

5bd4ee2

review: fix functions names

2d80017

review: doc comms for require_maker_payment_spend_confirm and require…

46212fa

…_taker_payment_spend_confirm

review: use references

ae56f2d

review: move StateMachineParams closer to LegacySwapParams. place the…

b9cef2b

…m above fn lp_connect

review: rename taker/alice to taker_pubkey and maker to maker_pubkey

ac9a5a3

fix clippy in tests

ab56a12

laruh added in progress and removed under review labels Dec 12, 2024

laruh force-pushed the fix-tpu-v2-wait-for-payment-spend branch from 363405d to e108534 Compare December 12, 2024 12:11

update maker and taker pubkey fields in test jsons

0ca61fd

laruh force-pushed the fix-tpu-v2-wait-for-payment-spend branch from e108534 to 0ca61fd Compare December 12, 2024 12:21

update maker and taker pubkey fields in test jsons in swaps_file_lock…

653e074

…_tests.rs

laruh added under review and removed in progress labels Dec 12, 2024

onur-ozkan added status: pending review and removed under review labels Dec 16, 2024

revert "swap_version" field

f8ba975

laruh force-pushed the fix-tpu-v2-wait-for-payment-spend branch from a857c9a to f8ba975 Compare December 16, 2024 14:26

Merge remote-tracking branch 'origin/dev' into fix-tpu-v2-wait-for-pa…

0a5ff84

…yment-spend

mariocynicys self-assigned this Dec 23, 2024

laruh requested review from dimxy, borngraced and mariocynicys December 23, 2024 12:57

mariocynicys removed their assignment Dec 23, 2024

mariocynicys reviewed Dec 25, 2024

View reviewed changes

	let taker_payment_spend = match state_machine
	.taker_coin
	.find_taker_payment_spend_tx(
	&self.taker_payment,
	self.taker_coin_start_block,
	state_machine.taker_payment_locktime(),
	)
	.await
	{
	Ok(tx) => tx,
	Err(e) => {
	let next_state = TakerPaymentRefundRequired {
	taker_payment: self.taker_payment,
	negotiation_data: self.negotiation_data,
	reason: TakerPaymentRefundReason::MakerDidNotSpendInTime(format!("{}", e)),
	};
	return Self::change_state(next_state, state_machine).await;
	},
	};

	if let Some(event) = found_event {
	if let Some(tx_hash) = event.transaction_hash {

	/// Some coins are "slow" (block time is high - e.g. BTC average block time is ~10 minutes).
	/// https://bitinfocharts.com/comparison/bitcoin-confirmationtime.html
	/// We need to increase payment locktime accordingly when at least 1 side of swap uses "slow" coin.
	pub fn lp_atomic_locktime(maker_coin: &str, taker_coin: &str, version: AtomicLocktimeVersion) -> u64 {
	match version {
	AtomicLocktimeVersion::V1 => lp_atomic_locktime_v1(maker_coin, taker_coin),
	AtomicLocktimeVersion::V2 {
	my_conf_settings,
	other_conf_settings,
	} => lp_atomic_locktime_v2(maker_coin, taker_coin, &my_conf_settings, &other_conf_settings),
	}
	}

		#[inline]
		fn spend_taker_payment_conf_timeout(&self) -> u64 { self.started_at + 3 * self.lock_duration }

		@@ -706,6 +706,8 @@ mod tests {

		wasm_bindgen_test_configure!(run_in_browser);

		const LEGACY_SWAP_V: u32 = 1;

		/// Determines if the maker payment spend transaction must be confirmed before marking swap as Completed.
		pub require_maker_payment_spend_confirm: bool,

fix(tpu-v2): fix tpu-v2 wait for payment spend and extract secret #2261

Are you sure you want to change the base?

fix(tpu-v2): fix tpu-v2 wait for payment spend and extract secret #2261

Conversation

laruh commented Nov 1, 2024 • edited Loading

laruh commented Nov 5, 2024

mariocynicys left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

laruh Nov 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

laruh Nov 13, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

onur-ozkan commented Nov 12, 2024

laruh commented Nov 12, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mariocynicys Nov 14, 2024 • edited Loading

Choose a reason for hiding this comment

dimxy Nov 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dimxy Nov 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

laruh Dec 11, 2024 • edited Loading

Choose a reason for hiding this comment

mariocynicys Dec 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

laruh Dec 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shamardy Dec 16, 2024 • edited Loading

Choose a reason for hiding this comment

shamardy Dec 16, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

laruh commented Dec 16, 2024

Choose a reason for hiding this comment

mariocynicys Dec 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

laruh commented Nov 1, 2024 •

edited

Loading

laruh Nov 12, 2024 •

edited

Loading

laruh Nov 13, 2024 •

edited

Loading

mariocynicys Nov 14, 2024 •

edited

Loading

dimxy Nov 14, 2024 •

edited

Loading

dimxy Nov 14, 2024 •

edited

Loading

laruh Dec 11, 2024 •

edited

Loading

mariocynicys Dec 11, 2024 •

edited

Loading

laruh Dec 11, 2024 •

edited

Loading

shamardy Dec 16, 2024 •

edited

Loading

shamardy Dec 16, 2024 •

edited

Loading

mariocynicys Dec 25, 2024 •

edited

Loading