<blockquote>
  <p>So if I were to create the same transaction using bitcoinjs and bitcoinj, the end result of the signed transaction would be the same with both libraries, is that correct?</p>
</blockquote>

<p>They certainly should. That's why they're called deterministic. Any particular library could have a bug in it, however. I would check against examples given in the spec to make sure a library is compliant with the spec, or run the unit tests if the library you're using has them.</p>

CC BY-SA 3.0
2015-05-27T15:59:36.550Z
It's not like it matters if they are the same or not though. Only the signer would know.
Claris
CC BY-SA 3.0
2015-05-28T10:12:16.557Z
Forgive the naivety, but how does deterministic ECDSA signing differ from normal/standard (?) ECDSA signing? I actually wondered this recently when I saw the *pybitcointools* library has a `deterministic_ecdsa_sign` function which uses hmac. Even an ELI5 and a link would be great
Wizard Of Ozzie
CC BY-SA 3.0
2015-05-28T13:39:47.297Z
An ECDSA signature requires for one of its inputs an unpredictable integer (named "k"). One way to generate k is to use a [CSPRNG](http://en.wikipedia.org/wiki/CSPRNG). Another way is to use H(x), where H is a [cryptographic hash function](http://en.wikipedia.org/wiki/CRHF), and x differs for each signature. If x is based only on the key and the message, H(x) is deterministic. Because it's easier to code (without mistakes) H(x) than a CSPRNG, H(x) is safer. See also [this blog post](http://blog.cr.yp.to/20140323-ecdsa.html) (scroll to the end) by DJB for a discussion of what to use for x.
Christopher Gurnee
CC BY-SA 3.0
2015-05-28T13:42:32.370Z
@WizardOfOzzie (forgot to respond to you by name in the reply above; doing so now instead....)
Christopher Gurnee
CC BY-SA 3.0
2015-05-27T13:29:42.883Z
2015-05-27T13:29:42.883Z
morsecoder
<p>So if I were to create the same transaction using bitcoinjs and bitcoinj, the end result of the signed transaction would be the same with both libraries, is that correct?</p>

<transactions><bitcoinj><bitcoinjs>
Do all implementation of Deterministic RFC6979-compliant ECDSA signatures generate the same signed transaction given the same data?
User134
# Do all implementation of Deterministic RFC6979-compliant ECDSA signatures generate the same signed transaction given the same data?

(Asked by: username_0 on 2015-05-27)

So if I were to create the same transaction using bitcoinjs and bitcoinj, the end result of the signed transaction would be the same with both libraries, is that correct?

**Tags:** transactions, bitcoinj, bitcoinjs


---

## 1 answers

### Answer by username_1 on 2015-05-27. Score: 4 | Accepted answer

> So if I were to create the same transaction using bitcoinjs and bitcoinj, the end result of the signed transaction would be the same with both libraries, is that correct?

They certainly should. That's why they're called deterministic. Any particular library could have a bug in it, however. I would check against examples given in the spec to make sure a library is compliant with the spec, or run the unit tests if the library you're using has them.

> **Comments:**
> **username_2**: It's not like it matters if they are the same or not though. Only the signer would know.  
> **username_3**: Forgive the naivety, but how does deterministic ECDSA signing differ from normal/standard (?) ECDSA signing? I actually wondered this recently when I saw the *pybitcointools* library has a `deterministic_ecdsa_sign` function which uses hmac. Even an ELI5 and a link would be great  
> **username_4**: An ECDSA signature requires for one of its inputs an unpredictable integer (named "k"). One way to generate k is to use a [CSPRNG](http://en.wikipedia.org/wiki/CSPRNG). Another way is to use H(x), where H is a [cryptographic hash function](http://en.wikipedia.org/wiki/CRHF), and x differs for each signature. If x is based only on the key and the message, H(x) is deterministic. Because it's easier to code (without mistakes) H(x) than a CSPRNG, H(x) is safer. See also [this blog post](http://blog.cr.yp.to/20140323-ecdsa.html) (scroll to the end) by DJB for a discussion of what to use for x.  
> **username_4**: @username_3 (forgot to respond to you by name in the reply above; doing so now instead....)  

---

