The old implementation was broken, as evidenced by the test cases I added. Specifically, we were implementing this policy in terms of PolicyThreshold, but PolicyThreshold requires you to mask any unused public keys with PolicyOpaque, which PolicyTypeUnlockConditions can't do. We also now handle algorithms other than SpecifierEd25519 correctly. Overall, this brings validation into agreement with consensus.validateSignatures. We can't match its behavior exactly (because v1 transactions contain a list signatures that target specific inputs, while v2 transaction inputs carry their signatures with them), but that's fine; we just need to ensure that any UnlockConditions that were satisfiable in v1 are also satisfiable in v2.
The old implementation was broken, as evidenced by the test cases I added. Specifically, we were implementing this policy in terms of
PolicyThreshold, butPolicyThresholdrequires you to mask any unused public keys withPolicyOpaque, whichPolicyTypeUnlockConditionscan't do. We also now handle algorithms other thanSpecifierEd25519correctly. Overall, this brings validation into agreement withconsensus.validateSignatures. We can't match its behavior exactly (because v1 transactions contain a list signatures that target specific inputs, while v2 transaction inputs carry their signatures with them), but that's fine; we just need to ensure that anyUnlockConditionsthat were satisfiable in v1 are also satisfiable in v2.