Refactor signatures

[jonesmarvin8]

🎯 Purpose

Refactor signatures for compatibility with Keycard. Both Keycard and LEE are BIP-340 compliant; however, the proposal was updated in 2022. Keycard is pre-2022 BIP-340 and LEE (currently) is post-2022. Post 2022 allowed for signatures to sign messages of variable length.

In this PR, we pre-hash messages before signing. Thus, enforcing 32-byte length for messages.

This PR updates how messages are signed. This induces a breaking change to LEE.

• Changes to Signature breaks verification of previous transactions. Thus, current state from history cannot be verified without introducing versions (for Signature).
  • Mitigation: Generate a signature based on current testnet state, and re-initialize genesis block based on thee current state.
• This does not affect spendability or retrievability of public accounts. Public accounts are retrieved from the sequencer, and new transactions (using this PR) will generate and verify signatures based on the logic included in this PR.

⚙️ Approach

• Introduce functions for Message (public and privacy version) for to hash a message (hash_message()).
• Update Signature::new logic to only accept [u8;32] message.
• Signature::new_with_aux_rand updated to sign_prehash_with_rand
• Comment out varied length test vectors for BIP-340 added in 2022.

🧪 How to Test

Refactoring. All previous tests still work (except the test vectors noted above)

🔗 Dependencies

N/A

🔜 Future Work

None.

📋 PR Completion Checklist

Mark only completed items. A complete PR should have all boxes ticked.

• Complete PR description
• Implement the core functionality
• Add/update tests
• Add/update documentation and inline comments

---

[moudyellaz]

lgtm, thanks for addressing my comments

[schouhy]

Thanks LGTM! Left some minor comments