Skip to content

Conversation

@tcharding
Copy link
Member

@tcharding tcharding commented May 25, 2022

Currently if we mix up height/time absolute timelocks when filtering policies the result is incorrect (to the best of my understanding).

Add a timelock module that includes a single public function for checking if absolute timelocks are the same unit. Use the new function to fix a bug in policy filtering.

  • Patch 1 is a docs bug fix
  • Patch 2 is the bug fix
  • Patch 3 is a unit test patch that fails if its moved before patch 2. Please review the unit test carefully to make sure I'm not confused.

Note

There is ongoing discussion around trying to design a suitable timelock API. This PR is an attempt to make some forward progress by taking baby steps and making objective improvements. I decided to do it here in miniscript because it will be easier to iterate on and more obvious when there are concrete usage examples along with each change.

cc dpc

We have mixed up relative/absolute on the trait methods for `from_after`
and `from_older`.
src/timelock.rs Outdated
/// Returns true if `a` and `b` are the same unit i.e., both are block heights or both are UNIX
/// timestamps. `a` and `b` are nLockTime values.
pub fn absolute_timelocks_are_same_unit(a: u32, b: u32) -> bool {
n_lock_time_is_block_height(a) && n_lock_time_is_block_height(b)
Copy link

Choose a reason for hiding this comment

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

I wonder if n_lock_time_is_block_height(a) == n_lock_time_is_block_height(b) is more readable to other people, or just me.

Copy link
Member Author

Choose a reason for hiding this comment

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

I like it!

tcharding added 2 commits May 26, 2022 14:32
Currently if we mix up height/time absolute timelocks when filtering
policies the result is incorrect.

Add a `timelock` module that includes a single public function for
checking if absolute timelocks are the same unit. Use the new function
to fix a bug in policy filtering.
Currently if we mix up height/time absolute timelocks when filtering
policies the result is incorrect.

Add a bunch of assertions that verify the bug.
@tcharding tcharding force-pushed the 05-25-timelock-usage branch from 9c744be to 42e1216 Compare May 26, 2022 04:32
@tcharding
Copy link
Member Author

Force push is cargo fmt and suggestion from @dpc.

@tcharding
Copy link
Member Author

Oh and I made the helper functions public because clippy warns otherwise, I think there is value in having both even though one is now not used. I specifically put the < and >= there, explicitly in front of everyone that sees it, instead of negating a function call in one to the other.

Copy link
Member

@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

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

ACK 42e1216

@sanket1729
Copy link
Member

Thanks for this, will catch up the lock time discussions upstream this week

@sanket1729
Copy link
Member

Edited the description to remove the @ mention

Copy link
Member

@sanket1729 sanket1729 left a comment

Choose a reason for hiding this comment

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

ACK 42e1216.

This is clean improvement. A nice step towards #270

@sanket1729 sanket1729 merged commit 0ac479f into rust-bitcoin:master Jun 2, 2022
@tcharding tcharding deleted the 05-25-timelock-usage branch June 3, 2022 03:29
heap-coder added a commit to heap-coder/rust-miniscript that referenced this pull request Sep 27, 2025
…usage

42e12168f4c4bcb6f521016930fa6a92289631fd Unit test mixed up absolute timelocks (Tobin C. Harding)
e4eb285400c417cf9e7255b0e7911649afb201ee Add a minimal timelock module (Tobin C. Harding)
0b62f5e212e8d5d33d4753db9168d3817f2f802a Fix incorrect timelock docs (Tobin C. Harding)

Pull request description:

  Currently if we mix up height/time absolute timelocks when filtering policies the result is incorrect (to the best of my understanding).

  Add a `timelock` module that includes a single public function for checking if absolute timelocks are the same unit. Use the new function to fix a bug in policy filtering.

  - Patch 1 is a docs bug fix
  - Patch 2 is the bug fix
  - Patch 3 is a unit test patch that fails if its moved before patch 2. Please review the unit test carefully to make sure I'm not confused.

  ## Note

  There is [ongoing discussion](rust-bitcoin/rust-bitcoin#994) around trying to design a suitable timelock API. This PR is an attempt to make some forward progress by taking baby steps _and_ making objective improvements. I decided to do it here in miniscript because it will be easier to iterate on and more obvious when there are concrete usage examples along with each change.

  cc dpc

ACKs for top commit:
  apoelstra:
    ACK 42e12168f4c4bcb6f521016930fa6a92289631fd

Tree-SHA512: 93a55c550a903477cf20f50873d7b778bc36c1eaaf9a31c247d46d931f46100296d3fc3c89cf34ad6b029a7a14f6ae20d8208f22f4536fffe23cd5dab5fa674b
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.

4 participants