-
Notifications
You must be signed in to change notification settings - Fork 40
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
Add a ManagerOptions type to allow for customizable options #102
base: master
Are you sure you want to change the base?
Add a ManagerOptions type to allow for customizable options #102
Conversation
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, looks good, my main concern is the added dependency otherwise mainly nits.
dlc-manager/src/manager.rs
Outdated
self.options.refund_delay, | ||
self.options.refund_delay * 2, |
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 might as well have two options rather than forcing the *2
to be more flexible? You'd probably need to check that max > min
though.
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.
Sure, i'll make that change. More flexibility is always good.
@Tibo-lg What is the intention of having a minRefundDelay and a max? What does it do to have those bounds, rather than just 1 value and making the refund after that time?
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 created a type called RefundDelayWindow. Tell me what you think.
self.options.cet_nsequence, | ||
self.options.cet_nsequence * 2, |
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.
ditto
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.
So I set about trying to make this change in the same way I did for refund_delay, but it became a huge rats nest. I created a struct called CETnSequenceWindow
, but I couldn't import it from dlc-manager in dlc-messages because of a circular dependency. Then I tried just using a cet_nsequence_min and cet_nsequence_max, and handing those all the way down, but that also became really messy because that sometimes it expects just the "min" value, and it gets really confusing.
What do you think?
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'm not sure I understand why you need to use that in dlc-messages?
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.
Ah, I think I was trying to pass the struct with the min/max values too far down , when I could have just been passing the u32.
Anyway, do you think it would be good to have a CETnSequenceWindow object with a min / max values, or just leave it as a u32 with default 288?
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 mentioned above I feel like not having a separate object is simpler as in I think the max value is only required in few places.
) | ||
.unwrap(), | ||
)); | ||
|
||
let cet_nsequence: u32 = ManagerOptions::default().cet_nsequence; |
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.
Seeing this I feel it might be better to preserve the const
values (maybe with a DEFAULT
prefix)
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'm not sure what you mean here. I see that cet_nsequence used to be a CONST, and now because I'm grabbing this off the struct I can only store it as a let. Can you give me an example? I'm not sure what you mean by using the DEFAULT prefix. Thanks
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 I meant was that you could keep the const and use them to initialize the default values of the struct, and make them accessible so that someone using the default values doesn't have to initialize a struct for nothing just to access the default values.
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.
Ah, I understand now. Yes, updated
@@ -502,6 +502,7 @@ fn manager_execution_test(test_params: TestParams, path: TestPath) { | |||
alice_oracles, | |||
Arc::clone(&mock_time), | |||
Arc::clone(&electrs), | |||
Some(ManagerOptions::default()), |
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.
You might as well pass None
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!
…m:dlc-link/rust-dlc into feat/allow-customizable-num-confirmations
OK @Tibo-lg I think it's ready for review again. I didn't make a Window object for CETnSequence, but I left the window struct for the refund times. Can you elaborate for me why there is a window for refund, rather than just a single value? |
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.
Thinking about this more, I feel it might actually be best to have three values for both cet_nsequence
and refund. The reason is because you need:
- one that you use when you are offering a contract
- a min and a max value for when you receive an offer, to reject contracts that have values outside of the range you define. For example, if the
refund
value is too short, your counterparty might be able to use the refund before you have time to close the contract (and for the nsequence they might be able to cheat by using an old state without you having enough time to react to publish the punishment transaction).
@@ -37,16 +37,54 @@ use std::collections::HashMap; | |||
use std::ops::Deref; | |||
use std::string::ToString; | |||
|
|||
/// The number of confirmations required before moving the the confirmed state. | |||
/// The number of btc confirmations required before moving the DLC to the confirmed state. |
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 change this comment, I'm not sure "btc confirmations" makes so much sense.
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.
Oh I think github copilot did that, I can remove it.
|
||
/// The min and max value in seconds until a DLC will be refunded. | ||
#[derive(Clone, Copy)] | ||
pub struct RefundDelayWindow { |
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.
Looking through the code I'm not sure this is really useful, in some places you end up passing that when only one of the value is required.
self.options.cet_nsequence, | ||
self.options.cet_nsequence * 2, |
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 mentioned above I feel like not having a separate object is simpler as in I think the max value is only required in few places.
) | ||
.unwrap(), | ||
)); | ||
|
||
let cet_nsequence: u32 = dlc_manager::manager::CET_NSEQUENCE; |
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.
If you just use default value it feels like most of the changes in this file are unnecessary?
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'm not sure I really understand what you mean by the 3 values of refund time and nsequence, and I'm not sure how they would be handled in the code.
If you don't mind, would it be OK if I scale this PR back to only be accepting the NUM_CONFIRMATIONS as a configurable variable? That's the only thing I actually wanted, and I feel like I'm starting to bite off more than I can chew.
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.
Or feel free to jump in and make commits on this PR if you'd like.
Added a ManagerOptions type with defaults, to let the constants of the DLCManager be configurable.
Open to design ideas!