Improve timelock code #414
Conversation
There was a problem hiding this comment.
ACK e870519. Thanks for looking into this. Apart from the refactor here, there is also great value in someone looking at this code again.
| @@ -89,7 +89,7 @@ impl TimeLockInfo { | |||
| |mut timelock_info, sub_timelock| { | |||
| // If more than one branch may be taken, and some other branch has a requirement | |||
| // that conflicts with this one, set `contains_combination` | |||
| if k >= 2 { | |||
| if k > 1 { | |||
There was a problem hiding this comment.
This one is an improvement and I will ACK this change. But generally speaking, the symbols > >= should represent the way to think about the code rather than the conversion.
If while explaining some concept, we usually say "Two or more" rather than "more than one", it makes sense to write >=2.
There was a problem hiding this comment.
Interesting, thanks for your thoughts. I tried to explain this if statement out loud to myself and I was unsure if I would say "if there are more than 1 ..." or "if there are 2 or more". I think I'd say "more than one" but I think that's just from reading > statements many times, so might be circular reasoning :) Amusingly I then opened the editor at this line and there is the following code comment
// If more than one branch may be taken, and some other branch has a requirement
// that conflicts with this one, set `contains_combination`.
|
This would now has conflicts because of changes in #340. Would need rebase |
Bitcoin Core uses the identifier `LOCKTIME_THRESHOLD` but we are using `HEIGHT_TIME_THRESHOLD`. Its not immediately clear that one is better than the other so lets use the same identifier as Bitcoin Core.
It is more typical to write `if k > 1` than `if k >= 2`.
Use more descriptive names for the 'combine' methods while removing the 'timelocks' bit of the method names.
We currently use the form "time lock" and also "timelock" (implies `TimeLock`, `Timelock`). Which we use is not important but we should be uniform. Favour "timelock" (and `Timelock`).
Add a simple unit test showing how `combine_threshold` works. Test asserts that multiple timelocks of the same type result in unspendable paths if threshold is 2.
When using `fold` the first argument is the accumulator, we can use the typical functional programming identifier `acc` with no loss of clarity. The other argument is a timelock, this is clear because we are iterating `timelocks`, use `t` instead of `sub_timelock` with no loss of clarity (subjective).
|
Force push is rebase only. |
Done while working on a timelock module. This is all the initial patches (except one) from #408 (which is a PR displaying usage of the new timelock module).
Note, does not do the 'make
TimelockInfofields pub crate' change - I was unsure if this was correct.