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

Introducing Older/After Translation functionality #435

Open
SarcasticNastik opened this issue Jun 19, 2022 · 5 comments
Open

Introducing Older/After Translation functionality #435

SarcasticNastik opened this issue Jun 19, 2022 · 5 comments

Comments

@SarcasticNastik
Copy link
Contributor

SarcasticNastik commented Jun 19, 2022

In the same way as #434

Up until now, we had support for key translation (and upcoming hash translations) which provide similar analysis guarantees as before. Doing the same for older/after does change things, and some of the miniscripts analysis we are able to do might not be possible. For example:- script_size requires us knowing the serialized length of the older/after time integer parameter.
Besides associating the Older type for a generic MiniscriptKey to u32, there are following possibilities we can try to offer:

  1. All the miniscripts are analyzable and we always keep the type Older -> u32 association.
  2. We introduce Analyzable trait, and use it to store the association as above for proper analysis. (More involving to implement, but gives us more flexibility working with generic miniscripts)
  3. We migrate the analysis requiring older/after parameter u32 to only support MiniscriptKey + ToPublicKey, but we might lose some flexibility here. (easier to implement)
    I'm confused here and would like to know others' view on the same.
@apoelstra
Copy link
Member

I'm curious if there is any value in using custom types for timelocks.

@sanket1729
Copy link
Member

sanket1729 commented Jun 20, 2022

@apoelstra, I think there is some value.

  1. Writing UNIX timestamps are annoying when dealing with the timelocks based on times instead of height.
  2. It is still good to reason about things abstractly. For example, HTLC script can use timeout, options code can use expiry etc.
  3. The incremental effort is minimal.

@sanket1729
Copy link
Member

I am re-evaluating the technical costs regarding mixing timelocks and looks like introducing associated types might be harder here for the reasons listed in the post.

We should revisit this after #270

@sanket1729
Copy link
Member

@SarcasticNastik, we can discuss this in another medium. I think we should revisit this after LockTime stuff is resolved cleanly.

rust-bitcoin/rust-bitcoin#994

#408

@SarcasticNastik
Copy link
Contributor Author

Sorry for the late reply. So @sanket1729 and I had a discussion regarding the same and the main issue we faced was we can't analyze the miniscripts for a generic type for older/ after(extra_prop.rs calculates the properties for every miniscript, including checks for timelock mixing). To overcome this we require specialization feature from rust nightly to support timelock mixing calculation for the cases where type Older\ After = u32or a major refactor. We've put this off for now.

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

No branches or pull requests

3 participants