2

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, bip32utils uses python's ecdsa library (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, but it seems to me that consistency (even to the point of reproducing a bug) is crucial with bitcoin.

Improve this question
2

1 Answer 1

Reset to default
2

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 and also on github. 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.

Improve this answer
2
  • 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
    Commented Jun 21, 2015 at 5:01
  • 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
    – Claris
    Commented Jun 21, 2015 at 17:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.