<p>No.</p>
<p>The switch to a different database for the wallet does not change the issues that would arise with multiple nodes having slightly different sync states.</p>

CC BY-SA 4.0
2024-06-06T16:53:47.983Z
If sharing wallet files is still not feasible, what are the recommended ways to scale a Bitcoin setup to handle increased load and avoid a single point of failure?
Jeff Trimmer
CC BY-SA 4.0
2024-06-06T16:26:50.297Z
2024-06-06T16:26:50.297Z
Ava Chow
<p>I have a setup where a single stateful Bitcoin node (with a watch-only wallet) is no longer sufficient due to being a single point of failure and the increasing load of requests. Consequently, I need to run multiple bitcoind server instances.</p>
<p>Around 6.5 years ago, <a href="https://bitcoin.stackexchange.com/questions/65350/share-a-common-wallet-dat-file-between-two-servers">in this question</a>, it was stated that sharing a wallet.dat file between multiple bitcoind servers was not possible due to the risk of wallet corruption and potential loss of funds. Specifically, Ava Chow noted that:</p>
<blockquote>
<p>&quot;You should not share a wallet.dat file between two servers. It may not even work and may result in wallet corruption and loss of funds. If you are planning on having the two instances open the same wallet file, that is not allowed. BDB (the database system used by Bitcoin Core) does not allow a database to be opened by multiple software simultaneously. If you are somehow able to do so, you can corrupt your wallet.</p>
</blockquote>
<blockquote>
<p>Furthermore, even if the wallet file is not accessed simultaneously, the two nodes will have different sync states which will result in the software being confused and potentially have to rescan every time you start up one of the nodes. It may also have other issues.&quot;</p>
</blockquote>
<p>Given that <a href="https://bitcoincore.org/en/releases/26.0/" rel="nofollow noreferrer">Bitcoin Core 26.0 Release Notes</a> state:</p>
<blockquote>
<p>&quot;The createwallet RPC will no longer create legacy (BDB) wallets when setting descriptors=false without also providing the -deprecatedrpc=create_bdb option. This is because the legacy wallet is being deprecated in a future release.&quot;</p>
</blockquote>
<p>With the change in wallet DB technology, is it now possible to safely share one or more wallet files between multiple bitcoind instances, ensuring that changes made on one server are reflected on the others without causing corruption? Does the new wallet technology support this use case or does it still have the same restrictions as the legacy BDB wallets?</p>
<p>If sharing wallet files is still not allowed, what are the recommended ways to scale a stateful Bitcoin Core setup (with wallet) to handle increased load and avoid a single point of failure?</p>
<p>Thank you for your insights.</p>

CC BY-SA 4.0
2024-06-06T16:27:49.187Z
Where is the increased load coming from? What are you using the wallet for?
Ava Chow
CC BY-SA 4.0
2024-06-06T16:52:03.577Z
The increased load is coming from applications invoking RPC commands to get blockchain and watch-only wallet information. The wallet is used as a watch-only wallet.
Jeff Trimmer
CC BY-SA 4.0
2024-06-06T20:06:01.877Z
@JeffTrimmer Is the question about having *the same* wallet file open by different wallet instances (e.g. network drive), or about two servers both with their own *copy* of the same wallet? The text you quote is about the first (which indeed is absolutely not possible) but depending on what you're doing, the second may be okay, especially in watch-only scenarios.
Pieter Wuille
CC BY-SA 4.0
2024-06-06T21:13:00.393Z
@PieterWuille The question is about having the same wallet file open by different wallet instances, but I now know this is not possible. I'm trying to scale bitcoind to multiple instances in a cluster with a watch-only wallet, where importing a descriptor into one instance is recognized by all nodes. I need the wallet state to synchronize without importing into each node. The nodes will be behind a load balancer, and I won't know the individual host addresses or how many nodes exist at any given time.
Jeff Trimmer
CC BY-SA 4.0
2024-06-06T21:39:05.433Z
Can you elaborate one what "synchronizing the wallet state" means? Different wallets with the same descriptor(s) imported will eventually see the same transactions, and the same balance. But if you're constructing new transactions on both, it's possible that one will use UTXOs that the other is in the process of spending already, for example. Or, if you invoke `getnewaddress` on both, they'll give out addresses the other instance has already given out.
Pieter Wuille
CC BY-SA 4.0
2024-06-07T19:59:47.577Z
You have identified the exact problem I am trying to solve. Constructing new transactions on both should not use UTXOs that the other is in the process of spending already. The invocation of `getnewaddress` should not give out an addresses that another instance has already given out.
Jeff Trimmer
<wallet><wallet.dat><scalability>
Is it Safe to Share a Wallet File Between Multiple Bitcoin Core Instances Using the New Wallet DB Technology?
Jeff Trimmer
# Is it Safe to Share a Wallet File Between Multiple Bitcoin Core Instances Using the New Wallet DB Technology?

(Asked by: username_0 on 2024-06-06)

I have a setup where a single stateful Bitcoin node (with a watch-only wallet) is no longer sufficient due to being a single point of failure and the increasing load of requests. Consequently, I need to run multiple bitcoind server instances.

Around 6.5 years ago, [in this question](https://bitcoin.stackexchange.com/questions/65350/share-a-common-wallet-dat-file-between-two-servers), it was stated that sharing a wallet.dat file between multiple bitcoind servers was not possible due to the risk of wallet corruption and potential loss of funds. Specifically, username_1 noted that:

> "You should not share a wallet.dat file between two servers. It may not even work and may result in wallet corruption and loss of funds. If you are planning on having the two instances open the same wallet file, that is not allowed. BDB (the database system used by Bitcoin Core) does not allow a database to be opened by multiple software simultaneously. If you are somehow able to do so, you can corrupt your wallet.

> Furthermore, even if the wallet file is not accessed simultaneously, the two nodes will have different sync states which will result in the software being confused and potentially have to rescan every time you start up one of the nodes. It may also have other issues."

Given that [Bitcoin Core 26.0 Release Notes](https://bitcoincore.org/en/releases/26.0/) state:

> "The createwallet RPC will no longer create legacy (BDB) wallets when setting descriptors=false without also providing the -deprecatedrpc=create\_bdb option. This is because the legacy wallet is being deprecated in a future release."

With the change in wallet DB technology, is it now possible to safely share one or more wallet files between multiple bitcoind instances, ensuring that changes made on one server are reflected on the others without causing corruption? Does the new wallet technology support this use case or does it still have the same restrictions as the legacy BDB wallets?

If sharing wallet files is still not allowed, what are the recommended ways to scale a stateful Bitcoin Core setup (with wallet) to handle increased load and avoid a single point of failure?

Thank you for your insights.

**Tags:** wallet, wallet.dat, scalability

> **Comments:**
> **username_1**: Where is the increased load coming from? What are you using the wallet for?  
> **username_0**: The increased load is coming from applications invoking RPC commands to get blockchain and watch-only wallet information. The wallet is used as a watch-only wallet.  
> **username_2**: @username_0 Is the question about having *the same* wallet file open by different wallet instances (e.g. network drive), or about two servers both with their own *copy* of the same wallet? The text you quote is about the first (which indeed is absolutely not possible) but depending on what you're doing, the second may be okay, especially in watch-only scenarios.  
> **username_0**: @username_2 The question is about having the same wallet file open by different wallet instances, but I now know this is not possible. I'm trying to scale bitcoind to multiple instances in a cluster with a watch-only wallet, where importing a descriptor into one instance is recognized by all nodes. I need the wallet state to synchronize without importing into each node. The nodes will be behind a load balancer, and I won't know the individual host addresses or how many nodes exist at any given time.  
> **username_2**: Can you elaborate one what "synchronizing the wallet state" means? Different wallets with the same descriptor(s) imported will eventually see the same transactions, and the same balance. But if you're constructing new transactions on both, it's possible that one will use UTXOs that the other is in the process of spending already, for example. Or, if you invoke `getnewaddress` on both, they'll give out addresses the other instance has already given out.  
> **username_0**: You have identified the exact problem I am trying to solve. Constructing new transactions on both should not use UTXOs that the other is in the process of spending already. The invocation of `getnewaddress` should not give out an addresses that another instance has already given out.  

---

## 1 answers

### Answer by username_1 on 2024-06-06. Score: 0 | Accepted answer

No.

The switch to a different database for the wallet does not change the issues that would arise with multiple nodes having slightly different sync states.

> **Comments:**
> **username_0**: If sharing wallet files is still not feasible, what are the recommended ways to scale a Bitcoin setup to handle increased load and avoid a single point of failure?  

---

