<p>Not in the current code. The way it works now, you have to make two RPC calls -- one to unlock the wallet for a period of time (<code>walletpassphrase</code>) and one to do the transaction (<code>sendtoaddress</code>). You can follow up with a command to lock the wallet immediately, if desired (<code>walletlock</code>).</p>

<pre><code>  walletpassphrase &lt;passphrase&gt; &lt;timeout&gt;
  Stores the wallet decryption key in memory for &lt;timeout&gt; seconds.

  walletlock
  Removes the wallet encryption key from memory, locking the wallet.
  After calling this method, you will need to call walletpassphrase again
  before being able to call any methods which require the wallet to be unlocked.
</code></pre>

CC BY-SA 3.0
2011-10-27T11:32:37.640Z
Thanks, David, it's working for me. One problem is that the timeout does not seem to work - so I always do "walletlock". This however creates the necessity to do walletpassphrase-sendtoaddress-walletlock inside a critical section, otherwise there would be a race condition. Also - "walletpassphrase" returns an error when called the second time, without having called "walletlock" in between... Do you know if this is by design? It would make life easier if "walletpassphrase" was idempotent.
bitboy9999
CC BY-SA 3.0
2011-10-27T11:39:20.080Z
You can treat error -15 (wallet already unlocked) as a form of success. Unfortunately, it seems this RPC is kind of in a sad state (or there's some 'right' way to use it neither of us know). I would suggest modifying 'sendtoaddress' to take a passphrase.
David Schwartz
CC BY-SA 3.0
2011-10-27T13:20:34.550Z
Absolutely, if "sendtoaddress" simply accepted a passphrase, it would be awesome!
bitboy9999
CC BY-SA 3.0
2011-10-27T10:52:52.573Z
2011-10-27T10:52:52.573Z
David Schwartz
<p>I'm using JSON-RPC to send commands to my bitcoind, and it works fine.</p>

<p>Now I want to encrypt my wallet. When I've done that, I will need to send the passphrase when calling SendToAddress. How do I do that?</p>

<p>Right now I send these parameters:</p>

<ul>
<li>address </li>
<li>amount</li>
<li>comment</li>
<li>commentTo</li>
</ul>

<p>which are put into an array in the order above.</p>

<p>Will the passphrase be another parameter that I append as the last element in that array?</p>

<wallet><encryption>
How to Call JSON-RPC SendToAddress when the Wallet is Encrypted?
bitboy9999
# How to Call JSON-RPC SendToAddress when the Wallet is Encrypted?

(Asked by: username_0 on 2011-10-27)

I'm using JSON-RPC to send commands to my bitcoind, and it works fine.

Now I want to encrypt my wallet. When I've done that, I will need to send the passphrase when calling SendToAddress. How do I do that?

Right now I send these parameters:

* address
* amount
* comment
* commentTo

which are put into an array in the order above.

Will the passphrase be another parameter that I append as the last element in that array?

**Tags:** wallet, encryption


---

## 1 answers

### Answer by username_1 on 2011-10-27. Score: 11 | Accepted answer

Not in the current code. The way it works now, you have to make two RPC calls -- one to unlock the wallet for a period of time (`walletpassphrase`) and one to do the transaction (`sendtoaddress`). You can follow up with a command to lock the wallet immediately, if desired (`walletlock`).

```
  walletpassphrase <passphrase> <timeout>
  Stores the wallet decryption key in memory for <timeout> seconds.

  walletlock
  Removes the wallet encryption key from memory, locking the wallet.
  After calling this method, you will need to call walletpassphrase again
  before being able to call any methods which require the wallet to be unlocked.

```

> **Comments:**
> **username_0**: Thanks, username_1, it's working for me. One problem is that the timeout does not seem to work - so I always do "walletlock". This however creates the necessity to do walletpassphrase-sendtoaddress-walletlock inside a critical section, otherwise there would be a race condition. Also - "walletpassphrase" returns an error when called the second time, without having called "walletlock" in between... Do you know if this is by design? It would make life easier if "walletpassphrase" was idempotent.  
> **username_1**: You can treat error -15 (wallet already unlocked) as a form of success. Unfortunately, it seems this RPC is kind of in a sad state (or there's some 'right' way to use it neither of us know). I would suggest modifying 'sendtoaddress' to take a passphrase.  
> **username_0**: Absolutely, if "sendtoaddress" simply accepted a passphrase, it would be awesome!  

---

