feat: add external signing API for HSMs and custom signers

[tee8z]

I added this interface into the project so I can hook it up with the keymeld project I've been working on. Since keymeld is a centralizing force, I am trying to communicate this is not the preferred approach. This api, of exposing the data to be signed, makes it easier to use this project with an HSM as well. If you hate this idea and don't want to merge this into main I completed understand and will maintain this change on a fork.

Summary

This PR adds an external signing API that allows users to integrate DLC signing with external systems like HSMs, secure enclaves, or signing services (e.g., keymeld).

Changes

• src/signing.rs: New module with SigningData struct containing:

  • Outcome transaction sighashes (for both attestation and expiry outcomes)
  • Adaptor points for attestation outcomes (derived from oracle locking points)
  • Split transaction sighashes for each win condition
  • Aggregate public keys for both funding and split transactions

• src/lib.rs: Exports the new signing module and integrates SigningData generation into the existing API

• src/regtest.rs: Added comprehensive tests for the external signing workflow

Use Cases

This API is useful when you need to:

• Sign DLC transactions using an external HSM or secure enclave
• Use a custom MuSig2 implementation
• Batch multiple DLC signatures into a single signing session

Design Notes

• For most use cases, the existing SigningSession state machine remains the preferred approach
• The new API provides all necessary sighashes and metadata for external signers

[conduition]

Thank you for this pull, I think this is a great idea. I've got some catch-up to do from the holidays but I'll try to review this once I have some time. At a glance, your approach looks straightforward and I can't foresee any big changes, but i'll take a closer look soon 👍

[conduition]

Hey @tee8z, I'm sorry for my tardiness getting back to you on this. Lately I've been focused on PQC research, and seeing the way the winds are heading (long term, bad for ECDLP), i can't justify to work on this repo much anymore in the future since the fundamental premise of DLCs depends on ECDLP, and while it may hold in the short term I want to build for the long-term.

If you'd like to take over development let me know, I'm sure we can work something out to transition

[tee8z]

Hey @conduition,

I completely understand, figuring out what Bitcoin signatures will look like and how they perform in a quantum world is definitely a higher priority than continuing work/maintenance on the DLCTix crate.

I’d be happy to take over maintaining this crate. Even though DLCs may not have a strong long term outlook given current quantum signature concerns, I plan to keep a close eye on your work (and others’) to see whether a new scheme or approach can provide similar functionality. The key feature, in my view, is the ability to cryptographically sign for an external outcome that enables a specific Bitcoin spending path. If a viable alternative emerges, I’d definitely explore how to adapt toward it.

Please let me know how you’d like to proceed. You can reach me at tee8z@protonmail.com if you’d prefer to continue the conversation there.

Thank you for all the work you’ve put into getting this crate off the ground and for pushing Bitcoin signatures forward.

Cheers