Alternative to unlocking an encrypted wallet

Question

Sorry - I know that this is Q&A, but I can't find an appropriate place for feature requests, so here goes...

Unlocking the wallet for a period of time is one of the biggest security flaws with the bitcoin daemon. Once the wallet is unlocked then any process on an authorised machine can connect and issue send instructions until such stage as the wallet is locked again.

Just a thought, but how about appending the wallet password as an optional parameter to the JSON RPC calls that require an encrypted wallet to be unlocked. Assuming the implementation used SSL for RPC calls the password can be transmitted to the daemon securely and used to unlock it solely for that method call.

Answer 1

It's OK - the Q&A is a good place for feature requests as well :)

Anyway I think this is a good idea, but we'll need to do some research to assess its feasibility in the current code base. I'll post back our findings, hopefully in a week or so, after the next feature request review.

Comments

Just to let you know we haven't forgotten about this - I'll get back to you shortly.

---

Thanks - looking forward to it

---

OK, this looks fairly feasible - as you say we can add an extra high-level JSON-RPC parameter that locks then unlocks the wallet for the duration of that call. The API is single-threaded so, during the duration of a call, no other API calls can 'slip in' to take advantage of the wallet's temporary state.

---

Sounds good. You say that the API is single-threaded, so when one call has unlocked the wallet no others can take advantage. Does that also mean that if two calls are made at the same time (our system is multi-threaded, so this is a possibility), that when the first call completes and locks the wallet, the second call will not be adversely affected if it is part-way through?

---

I mean, in MultiChain it is not possible for two calls to be processed simultaneously. While your first call is executing, the second will be waiting for the API to accept its incoming request.

---

Gotcha! I'm perfectly happy with that.

---

Any further updates on this request?

---

This is not yet on the roadmap for the free version - it may be in future, or we may reserve it for a future premium version which has a collection of security, performance and integration features that are focused on enterprise requirements.