Skip to content
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

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

sosaucily
Copy link
Contributor

@sosaucily sosaucily commented Mar 29, 2023

Added a ManagerOptions type with defaults, to let the constants of the DLCManager be configurable.

Open to design ideas!

Copy link
Contributor

@Tibo-lg Tibo-lg left a 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/Cargo.toml Outdated Show resolved Hide resolved
dlc-manager/src/manager.rs Show resolved Hide resolved
dlc-manager/src/manager.rs Outdated Show resolved Hide resolved
Comment on lines 361 to 362
self.options.refund_delay,
self.options.refund_delay * 2,
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor Author

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.

Comment on lines +1154 to +1155
self.options.cet_nsequence,
self.options.cet_nsequence * 2,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto

Copy link
Contributor Author

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?

Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor

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.

dlc-manager/src/manager.rs Outdated Show resolved Hide resolved
)
.unwrap(),
));

let cet_nsequence: u32 = ManagerOptions::default().cet_nsequence;
Copy link
Contributor

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)

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Contributor Author

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()),
Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes!

@sosaucily
Copy link
Contributor Author

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?

Copy link
Contributor

@Tibo-lg Tibo-lg left a 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.
Copy link
Contributor

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.

Copy link
Contributor Author

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 {
Copy link
Contributor

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.

Comment on lines +1154 to +1155
self.options.cet_nsequence,
self.options.cet_nsequence * 2,
Copy link
Contributor

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;
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants