ecdsa sign message contract

[KyrylR]

The new bitcoin_message_ecdsa_verify contract verifies an ECDSA signature over the Bitcoin signed-message digest derived from the Simplicity sig_all_hash. This makes it possible to satisfy and spend a Simplicity contract using a signature produced by Jade’s sign_message anti-exfil flow.

[apoelstra]

Why provide both the nonce point and R from the signature? The nonce point by itself is sufficient and will save you a check and an error path. You also don't need to (and should not) actually has the Bitcoin signed message:<len>\n text, since you can just directly construct ctx.

But stepping back -- this seems like a terrible idea to me. The "signmessage" functionality is intentionally domain-separated by this Bitcoin signed message text so that you can't accidentally sign a transaction by signing a maliciously-crafted message. This eliminates that protection. It also makes it impossible for the the Jade to verify what it's signing, since you're just providing it a hash with no preimage data. This eliminates all the protection provided by the Jade having a screen etc.

This is in addition to how inherently inefficient this scheme is.

[KyrylR]

Why provide both the nonce point and R from the signature? The nonce point by itself is sufficient and will save you a check and an error path.

Got it, thx, will do the optimization if we decide to proceed with the approach

You also don't need to (and should not) actually has the Bitcoin signed message:\n text, since you can just directly construct ctx.

As I understand, this is related to the second part (correct me if I am wrong)

But stepping back -- this seems like a terrible idea to me. The "signmessage" functionality is intentionally domain-separated by this Bitcoin signed message text so that you can't accidentally sign a transaction by signing a maliciously-crafted message. This eliminates that protection. It also makes it impossible for the the Jade to verify what it's signing, since you're just providing it a hash with no preimage data. This eliminates all the protection provided by the Jade having a screen etc.

Created this: Blockstream/Jade#296

If I understand you correctly you wanna have the approach the prevents blind signing by default, while spending the Simplicity input on the Jade

This is in addition to how inherently inefficient this scheme is.

Fully agree

Thought this PoC was the best way to quickly explain the problem faced by guys on Simplicity Lending and have a discussion

[apoelstra]

If I understand you correctly you wanna have the approach the prevents blind signing by default, while spending the Simplicity input on the Jade

Yes. The Jade needs to know what transaction it's signing (at least, it needs to know that it's signing a transaction!).