Question regarding signing and verifying messages
2qx opened this issue · comments
Hello @bitjson , trying to get signed and verified string messages on mainnet-js but hitting a bit of an issue with the signatures from libauth.
For testing, the example from electron-cash was taken, but implemented for mainnet-js here:
message: "Chancellor on brink of second bailout for banks"
PrivateKey: L1TnU2zbNaAqMoVh65Cyvmcjzbrj41Gs9iTLcWbpJCMynXuap6UN
Cash Address: bitcoincash:qqehccy89v7ftlfgr9v0zvhjzyy7eatdkqt05lt3nw
The implementation to sign is here:
After applying the message formatting and using secp256k1.signMessageHashRecoverableCompact, this returns a signature of:
/2Mw6ePgwVsfd3u3jIJD2LsOBlT9VnbvzDf7JK/YXjIix2qOxzmeDeSY3w5kBOGDJ8Jk5DFkJbNr1XlfOVVjRg==
From what I understand, with different nonces there can be different there can be different signatures. However, the resulting signature from libauth with secp256k1.signMessageHashRecoverableCompact() throws an error on https://tools.bitcoin.com/verify-message/ as being too short.
There have been separate tests to break out and test the message magic formatting and they appear to match what is created by electron-cash.
It's not clear from the documentation what the RecoveryId is used for. I'm thinking that perhaps this id should have been included in the signature.
Its there anything that clearly stands out as being incorrect. Would it be possible to use signMessageHashSchnorr and future-proof against leaking keys using RFC6979?
I think may have figured out the recoveryId and the signature length outlined above.
It seems that the recoveryId and compression is encoded and prepended to the signature like so:
Further, the signatures (from libauth) without the prefix seem to match electron-cash exactly.