-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MVP swaps support for SLP tokens and PIRATE. #1067
Conversation
# Conflicts: # mm2src/coins/lp_coins.rs # mm2src/coins/utxo/utxo_common.rs # mm2src/lp_swap/maker_swap.rs # mm2src/mm2_bitcoin/keys/src/lib.rs # mm2src/mm2_tests.rs
…work rules" on RICK side.
# Conflicts: # mm2src/mm2_tests.rs
…ove to docker_tests.
Did that to avoid locking the mutex on each balance call. #1034
# Conflicts: # Cargo.lock # Cargo.toml # mm2src/coins/lp_coins.rs # mm2src/coins/qrc20.rs # mm2src/coins/utxo.rs # mm2src/coins/utxo/qtum.rs # mm2src/coins/utxo/slp.rs # mm2src/coins/utxo/utxo_common.rs # mm2src/coins/utxo/utxo_standard.rs # mm2src/coins/utxo/utxo_tests.rs # mm2src/docker_tests.rs # mm2src/docker_tests/qrc20_tests.rs # mm2src/lp_ordermatch/best_orders.rs # mm2src/mm2_tests.rs
# Conflicts: # mm2src/coins/utxo/slp.rs # mm2src/coins/utxo/utxo_tests.rs # mm2src/lp_ordermatch/best_orders.rs
@@ -745,6 +745,7 @@ impl SwapOps for EthCoin { | |||
fee_addr: &[u8], | |||
amount: &BigDecimal, | |||
min_block_number: u64, | |||
_uuid: &[u8], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume will be used for later usage? Or it's simply to respect the interface for send_taker_fee
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As of now, it's simply to respect the interface, yes. But it will be useful in the future when we implement a more advanced swap protocol.
CoinProtocol::ZHTLC => try_s!(z_coin_from_conf_and_request(ctx, ticker, &coins_en, req, secret).await).into(), | ||
CoinProtocol::ZHTLC => { | ||
let dbdir = ctx.dbdir(); | ||
try_s!(z_coin_from_conf_and_request(ctx, ticker, &coins_en, req, secret, dbdir).await).into() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think here the ?
can be used if the trait is implemented.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We still have some old code depending on try_s!
- I will try to get rid of it wherever possible, thanks!
# Conflicts: # etomic_build/client/enable_tBCH # mm2src/docker_tests.rs # mm2src/mm2_bitcoin/keys/src/cashaddress.rs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 🔥
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @artemii235, there are a few questions and suggestions. Please take a look at them
self.rpc_client().send_raw_transaction(tx_bytes.into()).compat().await?; | ||
|
||
self.rpc_client() | ||
.wait_for_confirmations( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why should we wait for confirmations every time we send a transaction?
As far as I understand, this method is only used by swap functions like z_send_tx_fee
and z_send_htlc
. But MakerSwap/TakerSwap
is already waiting for confirmations if it's required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Due to Sapling specifics, the shielded output becomes spendable only after it's confirmed. So we have to wait for tx to be mined to allow construction of a new one. This is a bit tricky now because it's better to not wait for that long here, but we have to wait somewhere for output to be confirmed and used in case of concurrent swaps.
PS I've realized that z_unspent_mutex
should be locked during this process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest adding the sent transaction to a container inside BCH
coin. So when any other SLP token tries to generate a new transaction, it will wait until every transaction from this container is mined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excuse me, did you intend to post this comment to another place? ZCoin
has little relation to BCH and SLP.
@@ -459,7 +459,7 @@ impl MakerSwap { | |||
} | |||
|
|||
async fn wait_taker_fee(&self) -> Result<(Option<MakerSwapCommand>, Vec<MakerSwapEvent>), String> { | |||
const TAKER_FEE_RECV_TIMEOUT: u64 = 180; | |||
const TAKER_FEE_RECV_TIMEOUT: u64 = 600; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess, you increased the timeout because TakerSwap
doesn't send the fee transaction hex until send_outputs
waits for confirmations. What if we just don't wait for confirmations within send_outputs
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I provided more info on this in #1067 (comment). I should also add that I don't like it for now, but I keep thinking about how to make it better. Shielded transactions support and UX is full of tradeoffs in general.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are no blockers since it's an MVP. Thanks!
#927 #701