lnrpc: add NoHash option to signer.SignMessage rpc #8098
Conversation
|
@guggero Gotcha, that makes sense, thanks for taking a look. So I'm working on this for LNDK. We're currently working on supporting paying bolt 12 offers, and part of the process is to sign the invoice request... the data LDK needs to pass to LND is already hashed. I had first looked into changing this on LDK's side -- to try to pass in an unhashed value into the SignMessage api. But the hashing formula for is a bit more complicated just a SHA256 (it requires a merkle root as well alongside it) https://github.com/lightningdevkit/rust-lightning/blob/6cafba9f5bc5c67d2ba302d2f53082ef22685b42/lightning/src/offers/merkle.rs#L104 so it doesn't quite work. Just brainstorming here but... Would it be safer if the noHash option can only be taken on a particular piece of data that can be deserialized into a struct on LND's side? I suppose another option would be to support the full bolt 12 hash making process on LND's side instead. Oi, and sorry for the red X marks in the CI checks. I'll fix those up once we discuss what the best option is here. :) |
|
Ah, so it's just a tagged hash? I guess then instead of allowing the message not to be hashed, we could allow the |
|
@guggero Sorry for the slow reply, was making sure I can refactor to expose the tag data in LDK. Looks like it works so I'll rework this PR in that direction :) |
|
Replacing this with a new PR to use a more accurate branch name. |
This PR adds the option to not hash the message before signing it with
signer.SignMessage. I'm running into a scenario where the message I need to pass into this API call is already hashed.I'm need this when needing a Schnorr signature of the message, so I made the change for that particular circumstance. But if this would be useful in a non-Schnorr scenario as well, I'd be happy to expand the change.