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

compiler: improve logic when deciding between conjunctions and multi/multi_a #657

Merged
merged 5 commits into from
Mar 12, 2024

Commits on Mar 12, 2024

  1. Configuration menu
    Copy the full SHA
    b2ec4a8 View commit details
    Browse the repository at this point in the history
  2. error: remove some unused variants

    There is more to come, but do a bunch now because it's cathartic.
    apoelstra committed Mar 12, 2024
    Configuration menu
    Copy the full SHA
    0666aef View commit details
    Browse the repository at this point in the history
  3. consolidate some FIXMEs

    When you grep the codebase for FIXME it's nice if the output isn't
    overwhelmed by the same message repeated 20 times.
    apoelstra committed Mar 12, 2024
    Configuration menu
    Copy the full SHA
    78db616 View commit details
    Browse the repository at this point in the history
  4. policy: rename Threshold variant to Thresh

    This matches the same variant in Terminal, matches the string
    serialization "thresh", and will avoid weird compiler errors related to
    collisions with the upcoming `Threshold` type.
    
    This will be an annoying API-breaking change, but fortunately(?) this PR
    is already breaking the API for thresholds in an annoying way.
    apoelstra committed Mar 12, 2024
    Configuration menu
    Copy the full SHA
    bc3b8dc View commit details
    Browse the repository at this point in the history
  5. compiler: improve logic for deciding between thresholds and ands

    In our threshold logic we have some special cases to handle multi,
    multi_a, and conjunctions. However, we were not choosing between
    these special cases correctly. Our logic was roughly that we would
    try to use multi_a if all children were pk()s, OR try to use multi
    if all children were pk() and there weren't too many, OR try to
    use a conjunction if k == n.
    
    The correct logic is: if all children are keys, and there aren't
    too many, try to use multi or multi_a. ALSO, if k == n, try to
    use a conjunction.
    
    With this fix, the compiler correctly finds that conjunctions are more
    efficient than CHECKMULTISIG when k == n and n < 3. When n == 3 the
    two cases have equal cost, but it seems to prefer the conjunction. It
    also correctly finds that when k == n, it is always more efficient to
    use a conjunction than to use CHECKSIGADD.
    
    This change necessitates changing some tests.
    apoelstra committed Mar 12, 2024
    Configuration menu
    Copy the full SHA
    200991d View commit details
    Browse the repository at this point in the history