-
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
[r2r] Lightning Refunds #1592
[r2r] Lightning Refunds #1592
Conversation
…nt secret from payment info and db
…ymentInstructionsReceived to MAKER_SUCCESS_EVENTS
…rt, recreate_swap_data
@artemii235 @ozkanonur I think the new |
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.
Thanks for the PR! It's a first review iteration.
} | ||
|
||
// Todo: need to also check on-chain spending |
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.
Do you plan to do it on next iteration? 🙂
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, this should be done in next sprint. This can only happen when the channel the payment is sent/received over is closed before the swap finishes, so this will be done alongside claiming swap or refunding on-chain for closed channels.
I believe it might be easier to implement this if Event::ChannelClosed
from rust-lightning side provides info about unsettled HTLCs in the channel closing transaction.https://github.com/KomodoPlatform/atomicDEX-API/blob/ae5daf7c082b3493555057a7c7559e6d5d211893/mm2src/coins/lightning/ln_events.rs#L85 But if this can't be done easy from rust-lightning side I believe it can be done on mm2 straight away. Just need to check the rust-lightning code in details for unsettled HTLCs and make sure I don't miss anything before implementing this, that's why I moved it to next sprint.
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.
Good job!
First review iteration
mm2src/coins/lightning.rs
Outdated
@@ -741,6 +785,74 @@ impl SwapOps for LightningCoin { | |||
} | |||
} | |||
|
|||
fn can_be_released(&self) -> bool { true } |
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.
In my opinion, can_be_released
is not clear enough. Could you please give it another name?
At least, can_release_payment
or can_fail_htlc_backwards
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.
can_be_released
is removed after implementing this suggestion #1592 (comment) by @artemii235
mm2src/coins/lightning/ln_events.rs
Outdated
PaymentInfo::new(payment_hash, PaymentType::InboundPayment, "keysend".into(), amt_msat); | ||
payment_info.preimage = Some(preimage); | ||
payment_info.status = HTLCStatus::Received; |
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.
How about adding PaymentInfo::with_preimage_and_status
?
mm2src/coins/lightning/ln_events.rs
Outdated
"Swap Payment".into(), | ||
amt_msat, | ||
); | ||
payment_info.status = HTLCStatus::Received; |
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.
How about adding PaymentInfo::with_status
?
mm2src/coins/lightning/ln_sql.rs
Outdated
amount_msat, | ||
fee_paid_msat, | ||
is_outbound, | ||
status, | ||
created_at, | ||
last_updated | ||
) VALUES ( | ||
?1, ?2, ?3, ?4, ?5, ?6, ?7, ?8, ?9, ?10, ?11 | ||
?1, ?2, ?3, ?4, ?5, ?6, ?7, ?8, ?9, ?10 |
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.
How about giving a name to each SQL parameter like it's done for starts_swaps
:
https://github.com/KomodoPlatform/atomicDEX-API/blob/728b20db56c25eb35a00cc1e922267bb4736923f/mm2src/mm2_main/src/database/stats_swaps.rs#L135-L150
mm2src/coins/lightning/ln_sql.rs
Outdated
let params = [ | ||
&preimage as &dyn ToSql, | ||
&last_updated as &dyn ToSql, | ||
&payment_hash as &dyn ToSql, | ||
]; |
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.
Please consider using the rusqlite::params
or db_common::owned_named_params
macros
…l_sql, used params macro where applicable
@artemii235 @sergeyboyko0791 this is ready for next review iteration |
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.
Next review iteration
@@ -1079,7 +1086,28 @@ impl MakerSwap { | |||
])); | |||
} | |||
|
|||
let taker_payment = self.r().taker_payment.clone(); | |||
if let Some(payment) = &taker_payment { | |||
if let Err(e) = self.taker_coin.on_maker_payment_refund_start(&payment.tx_hex).await { |
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.
This is really confusing because TakerSwapOps::on_maker_payment_refund_start
is called on the Maker side if only the taker payment has been sent.
Shouldn't TakerSwapOps
be used on the Taker side only?
Also I'm really not sure if MakerSwapOps
and TakerSwapOps
names are suitable as the coins traits.
What if we have MakerSwapMakerCoin
, MakerSwapTakerCoin
, TakerSwapMakerCoin
, TakerSwapTakerCoin
.
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.
What if we have
MakerSwapMakerCoin
,MakerSwapTakerCoin
,TakerSwapMakerCoin
,TakerSwapTakerCoin
I like the idea, it will remove a lot of the confusion. We need @artemii235 opinion on this too before proceeding since he suggested this #1592 (comment).
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.
Yeah, this looks more clear than Maker/TakerSwapOps
, so I agree 🙂
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.
Only MakerSwapTakerCoin
, TakerSwapMakerCoin
are needed in this PR. Will open an issue for the refactor/spliting of SwapOps
#1592 (comment) to the 4 above traits.
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.
Will open an issue for the refactor/spliting of SwapOps #1592 (comment) to the 4 above traits.
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.
Consider this as solved!
// Since taker payment is refunded successfully, maker payment can be released for lightning and similar protocols. | ||
// # Important: New code that leads to refund failure shouldn't be added below this code block. | ||
if let Err(e) = self.maker_coin.on_taker_payment_refund_success(&maker_payment).await { | ||
error!("Error {} on calling on_taker_payment_refund!", e) | ||
} |
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.
Should we do the same if self.taker_coin.is_auto_refundable()
?
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, @sergeyboyko0791 @artemii235 do you think it's worth adding 2 new swap commands TakerSwapCommand::OnRefundStart
, TakerSwapCommand::OnRefundSuccess
and the same for maker_swap
? This will help us avoid a lot of confusion in the future.
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.
Yeah, looks like it's worth doing it. As these are commands, I would name them PrepareForRefund
and FinalizeRefund
or something similar 🙂
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.
PrepareForRefund
and FinalizeRefund
are good enough names, couldn't come up with better names myself :)
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 really like this idea.
do you think it's worth adding 2 new swap commands TakerSwapCommand::OnRefundStart , TakerSwapCommand::OnRefundSuccess and the same for maker_swap? This will help us avoid a lot of confusion in the future.
Consider this as solved, but will not resolve so Artem can see this conversation at the next review iteration
…mentation for LightningCoin
…_auto_refundable in maker_swap's recover_funds
…Refund, TakerSwapCommand::FinalizeTakerPaymentRefund
…nd, MakerSwapCommand::FinalizeMakerPaymentRefund
@artemii235 @sergeyboyko0791 this is ready for another review! |
// Since taker payment is refunded successfully, maker payment can be released for lightning and similar protocols. | ||
// # Important: New code that leads to refund failure shouldn't be added below this code block. | ||
if let Err(e) = self.maker_coin.on_taker_payment_refund_success(&maker_payment).await { | ||
error!("Error {} on calling on_taker_payment_refund!", e) | ||
} |
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 really like this idea.
do you think it's worth adding 2 new swap commands TakerSwapCommand::OnRefundStart , TakerSwapCommand::OnRefundSuccess and the same for maker_swap? This will help us avoid a lot of confusion in the future.
Consider this as solved, but will not resolve so Artem can see this conversation at the next review iteration
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.
Thank you for the fixes! Just a few questions
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.
Awesome!
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.
🔥
#1045
SwapOps
traits. These methods are related to auto refunding of swap payments and early release of swap payments by the other side of the swap.check_if_my_payment_sent
,search_for_swap_tx_spend_my
,search_for_swap_tx_spend_other
SwapOps
methods forLightningCoin
.MakerPaymentInstructionsReceived
toMAKER_SUCCESS_EVENTS
,TakerPaymentInstructionsReceived
toTAKER_SUCCESS_EVENTS
.LightningDB
methods to reduce calls to DB.