# Bitcoin ECDSA signature

I am trying to use the ecdsaSign function in ecdsa.c of https://github.com/kvhnuke/Ethereum-Arduino/tree/master/Ethereum-Arduino/libs which is based on the files in the repo https://github.com/someone42/hardware-bitcoin-wallet

The signature that I generate using the above function ea9c02e96049f6e0ca1ddbcb1ef4ab122ab1d42fb52e537456b446c281cc72342caeec1d88d2ed67d14a06358148468e61a4e5a499cc7972be39e9f46c2cf06a

To crosscheck it I am using the ecdsa_sign function from the repo https://github.com/trezor/trezor-firmware/tree/master/crypto which I know generates the desired signature - f388ade4a3ef1f44ff31e860ca8e92c6d0fa77562b274f59a8b82af3e7c3177a5851f9720efe77b1872e23a2545b71aed5451ed4ff1c0fc2cac093fc084b99d6

msg used : 1020212013102021201310202120131020212013102021201310202120131020

privkey used : 8000238ac88eef15f5dae0c5ec08525f26ebe36a23fb81255a1595098b559c02

can someone please help me understand what I am missing here?

• ECDSA signatures are not necessarily (or usually) deterministic. That is, signing the same data twice with the same key is not bound to give twice the same result.
– fgrieu
Aug 17 '20 at 18:12
• The signature consists of an $(r, s)$ value, usually concatenated. No prices for guessing why the first value is called $r$. Aug 17 '20 at 21:22
• @MaartenBodewes: bitcoin uses two different formats to encode signatures; for transactions it uses the DER encoding from SEC1 and rfc3279 plus a 'sighash' byte, for messages it uses the 'plain' or P1363 encoding plus a 'recovery' byte. More on-topic, to prevent attacks which change a transaction signature and hash without changing the 'real' data, bitcoin now requires s be the lower of the two equivalent values, aka 'low-s'. I don't know about Ethereum. The data shown is obviously not a bitcoin transaction, and the signatures shown are clearly plain format. Aug 18 '20 at 2:35