<p>Yes, any person you give your <code>rpcpass</code> and <code>rpcuser</code> to can control your wallet, that's not what the wallet encryption password designed to protect against. You really don't want to be giving arbitrary users your RPC authentication details under any circumstance, and I can't think of one where you would need to. </p>

CC BY-SA 3.0
2013-12-06T01:36:33.883Z
Well, we are talking about levels of rights... for example, I am able to imagine a scenario where user A is designated to have read-only access to the wallet, while the one who has right to spend coins is someone else...
Mittag Leffler
CC BY-SA 3.0
2013-12-06T01:40:11.677Z
Bitcoind and BitcoinQT are not built to have user accounts like this. You will need to build a layer of abstraction on top of the RPC interface if you wish to have this type of functionality. You could alternatively use a deterministic wallet like Electrum, which is built to have separate read-only and readwrite wallet access using BIP0032 key derivation.
Anonymous
CC BY-SA 3.0
2013-12-06T01:19:15.157Z
2013-12-06T01:19:15.157Z
Anonymous
<p>I am dabbling with <strong>Bitcoin-QT</strong> with -server parameter locally, I guess this is not very different from using <strong>bitcoind</strong> remotely. I use <strong>Java</strong> and some http client library pluss a json parser to communicate with Bitcoin API via JSON RPC. However, this question is not related to the platform I use in any way, this is a pure Bitcoin API question. </p>

<p>What I have noticed is the following: if I make a call to <strong>wallettpassphrase</strong> with timeout, say, 5 seconds, the wallet remains open for all other connections for the same amount of time. For example, if connection A issues <strong>wallettpassphrase my_phrase 5</strong>, another connection, say B, does not have to know passphrase to spend coins. It is sufficient to try many times until some other connection opens up the wallet.</p>

<p>I haven't tried it myself, but I wonder... is this the same with <strong>bitcoind</strong>? In other word, if 2 different machines, A and B, connect to the same <strong>bitcoind</strong> server residing on a third machine, say C, and if machine A issues walletpassphrase for 5 seconds, will machine B be able to spend coins without knowing the passphrase within those 5 seconds?</p>

<p>If it will, isn't this a most serious impendiment for using <strong>bitcoind</strong> with many connections?</p>

<api><passphrase>
Potential security problem: wallettpassphrase opens up the wallet for everybody!
Mittag Leffler
# Potential security problem: wallettpassphrase opens up the wallet for everybody!

(Asked by: username_0 on 2013-12-06)

I am dabbling with **Bitcoin-QT** with -server parameter locally, I guess this is not very different from using **bitcoind** remotely. I use **Java** and some http client library pluss a json parser to communicate with Bitcoin API via JSON RPC. However, this question is not related to the platform I use in any way, this is a pure Bitcoin API question.

What I have noticed is the following: if I make a call to **wallettpassphrase** with timeout, say, 5 seconds, the wallet remains open for all other connections for the same amount of time. For example, if connection A issues **wallettpassphrase my\_phrase 5**, another connection, say B, does not have to know passphrase to spend coins. It is sufficient to try many times until some other connection opens up the wallet.

I haven't tried it myself, but I wonder... is this the same with **bitcoind**? In other word, if 2 different machines, A and B, connect to the same **bitcoind** server residing on a third machine, say C, and if machine A issues walletpassphrase for 5 seconds, will machine B be able to spend coins without knowing the passphrase within those 5 seconds?

If it will, isn't this a most serious impendiment for using **bitcoind** with many connections?

**Tags:** api, passphrase


---

## 1 answers

### Answer by username_1 on 2013-12-06. Score: 2

Yes, any person you give your `rpcpass` and `rpcuser` to can control your wallet, that's not what the wallet encryption password designed to protect against. You really don't want to be giving arbitrary users your RPC authentication details under any circumstance, and I can't think of one where you would need to.

> **Comments:**
> **username_0**: Well, we are talking about levels of rights... for example, I am able to imagine a scenario where user A is designated to have read-only access to the wallet, while the one who has right to spend coins is someone else...  
> **username_1**: Bitcoind and BitcoinQT are not built to have user accounts like this. You will need to build a layer of abstraction on top of the RPC interface if you wish to have this type of functionality. You could alternatively use a deterministic wallet like Electrum, which is built to have separate read-only and readwrite wallet access using BIP0032 key derivation.  

---

