<p>You would be best off using something that links to <code>libsecp256k1</code> than <code>openssl</code>, which is in the process of being dropped in Bitcoin Core due to endless security concerns anyway. I'm not aware of any that do, but I will update this answer if I find any. </p>

<blockquote>
  <p>are there plans to implement a deterministic wallet in bitcoind?</p>
</blockquote>

<p>Possibly, there's currently some planning going on with this, its at least likely that the current wallet will be deprecated and replaced with something more separate from the actual daemon. The current wallet is very heavily tied into the client in a lot of places, and has some massive dependencies like BerkeleyDB which are completely overkill for a key value store.</p>

<p>The current train of thought and some code is partly mixed into the <a href="http://bitcoinstats.com" rel="nofollow">bitcoin-dev logs</a> and also on <a href="https://github.com/bitcoin/bitcoin/pull/6265" rel="nofollow">github</a>. You shouldn't be using any of this with real money though, it is likely to be unstable for a long time.</p>

<blockquote>
  <p>are there any bip32 wallets which call already-existing-functions in bitcoind wherever possible?</p>
</blockquote>

<p>None I am aware of, most wallet software currently developed is either built on BitcoinJ (which numerous privacy and security considerations), querying some remote service (privacy and massive security issues), or something home brewed. Generally key management through JSON-RPC is pretty awful so that is somewhat understandable.</p>

<blockquote>
  <p>if not then what level of risk is involved in using bip32 wallets which rely on non-openssl ecdsa libraries?</p>
</blockquote>

<p>It's good you're thinking about this sort of thing to begin with. </p>

<p>Depends on the library, but the worst possible outcome is that a software implementation bug causes all of your money to be lost or stolen. This isn't unreasonable to suggest, and it happens almost constantly through the history of Bitcoin. Blockchain.info rolled their own RNG and has lost funds on a number of occasions due to it, Mt Gox wrote their own wallet and lost a pile of money when a function errored out and they sent their money to the pubkeyhash null, Bitcoin Armory found the ECDSA code they used leaked private keys through the signature. There's bound to have been more mistakes but these are the ones that have been made public.</p>

<p>Pretty high levels of risk, really. </p>

CC BY-SA 3.0
2015-06-21T05:01:25.220Z
Have you got a link re the Armory issue? Never heard that. MtGox I remember though; `76a9140088ac` is a problem since it's not RIPMD8 :)
Wizard Of Ozzie
CC BY-SA 3.0
2015-06-21T17:16:05.670Z
They imported some code from another party, audited it and found the RNG for signing to be completely broken, implemented a fix, and then left the fix commented out in the release version. [Armory CVE-2014-002](https://s3.amazonaws.com/bitcoinarmory-media/CVEs/ArmoryCVE-2014-002.pdf)
Claris
CC BY-SA 3.0
2015-06-20T16:09:43.853Z
2015-06-20T16:15:27.667Z
2015-06-20T16:15:27.667Z
Claris
<p>i want to use a hierarchical deterministic (bip32) wallet but i'm a bit put off by a lot of the libraries which use different ecdsa libraries to the core <code>bitcoind</code> client. for example pycoin uses a <a href="https://github.com/richardkiss/pycoin/blob/master/pycoin/ecdsa/ellipticcurve.py" rel="nofollow">natively implemented elliptic curve library</a>, <a href="https://github.com/jmcorgan/bip32utils" rel="nofollow">bip32utils</a> uses <a href="https://github.com/warner/python-ecdsa" rel="nofollow">python's ecdsa library</a> (i think).</p>

<p>while i'm sure these implementations work extremely well, i'm worried that there may be some rare edge cases where they diverge from <code>openssl</code>'s ecdsa implementation.</p>

<ol>
<li>are there plans to implement a deterministic wallet in <code>bitcoind</code>?</li>
<li>are there any bip32 wallets which call already-existing-functions in <code>bitcoind</code> wherever possible?</li>
<li>if not then what level of risk is involved in using bip32 wallets which rely on non-<code>openssl</code> ecdsa libraries?</li>
</ol>

<p>p.s. i get that <code>openssl</code>'s implementation of ecdsa is <a href="https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki" rel="nofollow">also not perfect</a>, but it seems to me that consistency (<a href="https://bitcointalk.org/index.php?topic=260595.msg2780720#msg2780720" rel="nofollow">even to the point of reproducing a bug</a>) is crucial with bitcoin.</p>

CC BY-SA 3.0
2015-06-20T18:18:27.580Z
There is a relatively new HD/Bip32 patch/PR for bitcoind. Check https://github.com/bitcoin/bitcoin/pull/6265.
Jonas Schnelli
CC BY-SA 3.0
2015-06-21T07:58:09.177Z
@JonasSchnelli, very cool. i can't wait for this to be stable!
mulllhausen
<bip32-hd-wallets>
bip 32 wallet with openssl
mulllhausen
# bip 32 wallet with openssl

(Asked by: username_0 on 2015-06-20)

i want to use a hierarchical deterministic (bip32) wallet but i'm a bit put off by a lot of the libraries which use different ecdsa libraries to the core `bitcoind` client. for example pycoin uses a [natively implemented elliptic curve library](https://github.com/richardkiss/pycoin/blob/master/pycoin/ecdsa/ellipticcurve.py), [bip32utils](https://github.com/jmcorgan/bip32utils) uses [python's ecdsa library](https://github.com/warner/python-ecdsa) (i think).

while i'm sure these implementations work extremely well, i'm worried that there may be some rare edge cases where they diverge from `openssl`'s ecdsa implementation.

1. are there plans to implement a deterministic wallet in `bitcoind`?
2. are there any bip32 wallets which call already-existing-functions in `bitcoind` wherever possible?
3. if not then what level of risk is involved in using bip32 wallets which rely on non-`openssl` ecdsa libraries?

p.s. i get that `openssl`'s implementation of ecdsa is [also not perfect](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki), but it seems to me that consistency ([even to the point of reproducing a bug](https://bitcointalk.org/index.php?topic=260595.msg2780720#msg2780720)) is crucial with bitcoin.

**Tags:** bip32-hd-wallets

> **Comments:**
> **username_1**: There is a relatively new HD/Bip32 patch/PR for bitcoind. Check https://github.com/bitcoin/bitcoin/pull/6265.  
> **username_0**: @username_1, very cool. i can't wait for this to be stable!  

---

## 1 answers

### Answer by username_2 on 2015-06-20. Score: 2 | Accepted answer

You would be best off using something that links to `libsecp256k1` than `openssl`, which is in the process of being dropped in Bitcoin Core due to endless security concerns anyway. I'm not aware of any that do, but I will update this answer if I find any.

> are there plans to implement a deterministic wallet in bitcoind?

Possibly, there's currently some planning going on with this, its at least likely that the current wallet will be deprecated and replaced with something more separate from the actual daemon. The current wallet is very heavily tied into the client in a lot of places, and has some massive dependencies like BerkeleyDB which are completely overkill for a key value store.

The current train of thought and some code is partly mixed into the [bitcoin-dev logs](http://bitcoinstats.com) and also on [github](https://github.com/bitcoin/bitcoin/pull/6265). You shouldn't be using any of this with real money though, it is likely to be unstable for a long time.

> are there any bip32 wallets which call already-existing-functions in bitcoind wherever possible?

None I am aware of, most wallet software currently developed is either built on BitcoinJ (which numerous privacy and security considerations), querying some remote service (privacy and massive security issues), or something home brewed. Generally key management through JSON-RPC is pretty awful so that is somewhat understandable.

> if not then what level of risk is involved in using bip32 wallets which rely on non-openssl ecdsa libraries?

It's good you're thinking about this sort of thing to begin with.

Depends on the library, but the worst possible outcome is that a software implementation bug causes all of your money to be lost or stolen. This isn't unreasonable to suggest, and it happens almost constantly through the history of Bitcoin. Blockchain.info rolled their own RNG and has lost funds on a number of occasions due to it, Mt Gox wrote their own wallet and lost a pile of money when a function errored out and they sent their money to the pubkeyhash null, Bitcoin Armory found the ECDSA code they used leaked private keys through the signature. There's bound to have been more mistakes but these are the ones that have been made public.

Pretty high levels of risk, really.

> **Comments:**
> **username_3**: Have you got a link re the Armory issue? Never heard that. MtGox I remember though; `76a9140088ac` is a problem since it's not RIPMD8 :)  
> **username_2**: They imported some code from another party, audited it and found the RNG for signing to be completely broken, implemented a fix, and then left the fix commented out in the release version. [Armory CVE-2014-002](https://s3.amazonaws.com/bitcoinarmory-media/CVEs/ArmoryCVE-2014-002.pdf)  

---

