This is a step-by-step guide for installing a Bitcoin Core node as a Hot Wallet source for CAS. While you can operate a node on any suitable server, this guide is based upon a VPS using Digital Ocean. The intricacies of node installation (and operation) in a different environment are outside the scope of our support, and in such situations you should seek assistance from the Bitcoin Core community.

This guide demonstrates Bitcoin Core version: 27.0

Other/newer versions may (and probably will) work, but this guide only supports this version.

It’s common for full nodes on high-speed connections to use 200 gigabytes upload or more a month. Download usage is around 20 gigabytes a month, plus around an additional 195 gigabytes the first time you start your node.

- https://bitcoin.org/en/full-node#minimum-requirements

1. Install the software:

Download and install the Bitcoin daemon on your server:

Optional: verify the file integrity:

• If successfully verified, you’ll see: "bitcoin-27.0-x86_64-linux-gnu.tar.gz: OK" .

Decompress the Bitcoin Core tarball:

Install the 2 required binaries to the system:

2. Create an RPC token:

The RPC token is designed to eliminate the need for hard-coded passwords in configuration and script files. You will receive a password here ONCE.

Download rpcauth.py from GitHub:

Modify the file permissions to allow the python script to execute:

Then finally run the RPC token generator that you just installed and enabled:

• Replace AnyNameYouWantHere with any preferred user name.

  • Don’t use spaces or any special symbols.

Example:

Open

• Save all the information securely. You'll need every detail in the steps to follow.  

• The RPC User = AnyNameYouWantHere

• The RPC Password = Kq66rZya7MNpCU_e0zZSgjR2Mb7rBeyX9QSeGhwPMeY=

• The cookie/token ("rpcauth") will only be required in the Bitcoin Core configuration file (next step).

3. Create the Bitcoin Core configuration file.

Create a new file and secure it:

Open the file using the nano editor:

Add the following settings & rpcauth credentials (created above):

• Replace the “rpcauth” line with the cookie/token you generated in the previous step 2.

• Exit the nano editor with Control+X and “Y” to save your changes.

• The CAS parameter “port” is the same as the “rpcport” specified in this step (8332).

4. Start the bitcoind daemon:

"When Bitcoin Core daemon first starts, it will begin to download the blockchain. This step will take at least several days, and it may take much more time on a slow Internet connection or with a slow computer."

- from https://bitcoin.org/en/full-node#other-linux-daemon

• It may take several minutes for Bitcoin Core to completely start.

• In actual practice, expect to wait 1-5 days for bitcoind to fully synchronize.

• CAS will NOT be able to interact with bitcoind until the synchronization is COMPLETE!

• To check the status, get the current block being processed by your node: 

  •  Compare the returned number to the latest network block:

    • (e.g https://www.blockchain.com/btc/blocks)

  • The debug log is typically located at $HOME/.bitcoin/debug.log

    • You can also check the status periodically using tail .bitcoin/debug.log

To STOP or interrupt Bitcoin Core at any time, use the following command:

• It will resume downloading from the point where it stopped the next time you start it. It may take a few minutes to completely shut down.

5. Setup a secure tunnel for encrypted communication.

Your CAS server and this node must have a secure line. Your passphrase and other sensitive information will be passed back & forth. Encrypt (and protect) this communication by using a secure SSH tunnel.

The GB Wallet Tunnel is recommended.

General Bytes has incorporated an open-source SSH client into CAS.

Click here for instructions to install the GB Wallet Tunnel Server on this node.

6. Save the required information for CAS:

user: this is the “RPC User” you invented earlier in Step 2.

password: is the “RPC Password” you also created earlier in Step 2.

7. Create a Wallet

After the node has fully synchronized, you’ll need to create a hot wallet.

• As of v23.0, the native, default wallet type is “descriptor”.

• See: https://bitcoindevkit.org/descriptors/

Create a Descriptor wallet:

• Creates a subfolder cas_default containing a wallet.dat file (the actual wallet),

• sets the avoid_reuse flag to comply with Bitcoin convention, and

• loads the wallet by default.

Create a new wallet address for funding:

Open

• The “bech32m” option is demonstrated, but you may also specify legacy, p2sh-segwit, or bech32.

• The resulting address (e.g. bc1q4wv99c3yqpwttt7a59qqqqmyxda0z8l2ups7fx) funds the wallet.

8. Final Step: Configure your CAS

Your bitcoind node is now complete, but you’ll still need to plug in the parameters (created above) into your Bitcoin Crypto Settings.

Additional Notes:

Remote Procedure Call (RPC) Reference:

More information about the RPC API: https://developer.bitcoin.org/reference/rpc/index.html

Important notes regarding pruning nodes:

A "pruning node" (or lightweight node) is a special configuration that may be applied to bitcoind. It is unsupported by General Bytes. It is a substantial security risk when operating a BATM. Per the Bitcoin wiki:

“Lightweight nodes are sometimes able to be temporarily tricked into accepting transactions or blocks that are not actually valid. This could cause serious financial damage, especially for websites that automatically process Bitcoin transactions. Full nodes provide the maximum security possible, and so they should be used by all businesses, and also by regular users whenever doing so is convenient.”

- https://en.bitcoin.it/wiki/Full_node

Backups

Backup is a simple matter of executing this RPC call:

• https://developer.bitcoin.org/reference/rpc/backupwallet.html

You can also just copy/archive the wallet file normally located in $HOME/.bitcoin/wallet.dat .

The wallet.dat file can change over time because:

• New Transactions: when you receive or send Bitcoin, new transactions are recorded in the wallet file.

• New Addresses: if you generate new addresses for receiving Bitcoin are added to the wallet file.

• Private Key Generation: new private keys (for new addresses) are stored in the wallet file.

A file backup would be the most comprehensive recovery option in the event of catastrophe. Since the file is so sensitive though, having multiple copies also increases your hack risks. Secure your backups!

Private Keys

It is dangerous to print or expose your private key(s). Be extremely cautious with these operations. Anyone with access to your private key(s) can control your Bitcoin funds associated with that address. We generally recommended you use hardware wallets or other secure methods for managing your private keys.

If you absolutely must retrieve your private key for a specific address - you must first determine the type of wallet you’re using:

• Examine the descriptors attribute in the result.

  • true = use the listdescriptors method.

  • false = use the dumpprivkey method.

The dumpprivkey command is deprecated and unusable for non-legacy wallets. Example:

• Replace "your_bitcoin_address" with the actual address for which you want to retrieve the private key. This command will output the private key associated with that address.

• Only works for legacy-type (non-descriptor) wallets.

The listdescriptors command works for non-legacy wallets (bech32, bech32m, and descriptors). It is a bit more complex to use than dumpprivkey, and prints out the all the keys in JSON format.

• Returns all descriptors and their private keys, including their derivation paths.

Related articles