Wallets, no matter the type, are merely programs. They run on a computer, and communicate with CAS by various means. Usually, the program is a "daemon", a type of program on a Linux-based server that runs in the background. No matter which type, the program runs on a public server and listens for applications to connect and send/receive information.

Each daemon listens on a certain "port". The port is specific to each server and the daemon(s) it runs. The Internet address of the server ("host") and the port it listens on must be correctly specified in CAS for a successful data conversation.

The General Bytes CAS supports many different cryptocurrencies. Each one requires different parameters, and this is turn varies by the wallet provider you elect to use. This information may be known definitively to GB, and the wallet will be pre-populated with wallet providers (e.g. Coinbase, Kraken, etc). Other wallets are unknown to GB, but you have the option of using those wallets if you can acquire the required parameters from the wallet provider.

This article is intended to help with you determine those parameters.

RPC is an acronym for Remote Procedure Call. It is the method commonly used for programs running on Internet servers to communicate with each other. The parameters required in Crypto Settings are for RPC communication.

General Bytes support will never ask you for your RPC credentials, nor should you offer them. This information permits access to your funds, and we would be reckless in accepting that responsibility. You must do this part yourself.

Parameters must be precise. The slightest typo will cause the whole conversation to fail. Every piece must be supplied by your wallet provider, or in the case of local nodes, it must match exactly the node configuration. The  parameters required may include:

Protocol: this is the format used to transfer information. This is always "http".

Host: this is the IP address of the server hosting the wallet. If you have installed, configured and implemented your own node, then you should already know the IP address of the server you installed the node on. If it's a local node, then you'll most likely use 127.0.0.1

Port: specified by the wallet operator, it's a 4-5 digit number and varies by the type of wallet. The operator may not use the conventional port suggested by the community, you should verify with the operator. Some examples of conventional ports:

• 8332: Bitcoin Core

• 8332: Bitcoin Cash

• 8545: Ethereum

• 8333: Litecoin

• 18081: Monero

• 9998: DASH

• 11001: Sumcoin

• 8090: Cardano

User: this is the "user" portion of the RPC credentials given to you by the wallet operator. If you created your own node, then you set your own "user".  RPC credentials are entirely different than account credentials, and the two are rarely identical.

Password: this is the "password" for the RPC user specified above. If you use a wallet provider, use the password they specify for your account. This may be the same as your user password, or it may be different, and it is completely dependent upon the wallet provider's discretion.

Account: this is typically set when everybody uses the same user/password (above). This identifies your account from everyone else's. In some cases "account" identifies your wallet name, as specified by the wallet provider. When implementing a local BTC node, you may have many different wallets for different purposes or BATM's.

Example:

A typical sample "parameter" for a local Bitcoin Core node (bitcoind) will look something like:

http:TheDutch:6szuvplZHgwKWrif_Ms2StzICOJLp4jbwsPRgPiKDqA=:123.123.123.123:8332:PITCO

• There are no quotes.

• All fields are seperated by a colon (":").

• Empty fields are skipped ("::"). NO SPACE BETWEEN THE COLONS!

When you have configured your parameters correctly, test them:

If you've entered the correct parameters, the appropriate tests will show green:

Port Forwarding

You need 2 servers to share information? There’s many ways to do that, but the most private & secure method (so far) implements an SSH tunnel.

SSH is “Secure Shell”, and it’s basically an encrypted exchange of data between your computer & another. In the case of an SSH “tunnel”, you’re not involved. The computers talk to each other, with all the security & privacy guaranteed by SSH. This article covers some solid basics, but doesn’t pretend to teach network security. Get professional help if you value your money & the business that generates it.

Typically, once an SSH tunnel is established, it is left in service the entire time. It’s never turned off (though it can be) but needs to be started every time that one (or the other) computer is rebooted.

The GB Wallet Tunnel was created to simplify this process. It is encouraged, but not required. You can use either approach.

• See: Install the GB Wallet Tunnel Server

The SSH tunnel must be key-based. Yes, you can use a login password instead, but it’s so insecure that I won’t even discuss it. We’re using keys; end of discussion.

Terminology

Let’s agree on a few terms to avoid confusion below.

• You’re connecting a remote node server. We’ll call that the “node”.

• You’re “dialing out” from a local computer. We’ll call that the “local”.

• Lastly, you’ll be connecting a CAS server to the remote. We’ll call the CAS server: “CAS”.

Create a key pair.

The node will we “dialing out” to CAS, so we’ll create the key pair on the node.

1. Login to your node.

2. Create a type “ed25519” public key pair:

ssh-keygen -t ed25519

• Using a password is encouraged, but prohibits automation. If someone somehow gains root access to your node, they’ll have access to your CAS server - if you don’t use a password. When the node must be restarted (for any reason, e.g. after updates), the key must be unlocked each & every time. It adds complexity to the restart procedure, but adds an extra layer of security. Usually the node will only be restarted manually anyhow, so using a password is advised.

• When offered, enter a password to encrypt your key. The password shouldn’t be crazy-complex, but not too easy, either.

• Note the names of the public & private keys. The default save location is “$HOME/.ssh” - which is what we’ll assume was used, as well as the default key file names:

  • private key = “id_ed25519”, so it’s full path is normally: $HOME/.ssh/id_ed25519

  • public key = “id_ed25519.pub”, full path = $HOME/.ssh/id_ed25519.pub

  • save the public key contents locally. It’s not a sensitive item, and you can share it freely without worrying about somebody intercepting it. They can’t hack it. It’s safe.

  • the private key is the magic; protect it at all costs, and it’s a required tunnel parameter.

You’ll need to view the public key for the next step.

cat $HOME/.ssh/id_ed25519.pub

Authorize the key.

We need to authorize the public key. The public key is shared with systems that you want to access. They authorize your public key by adding it to a list.

Open another Terminal window & login to your CAS server.

Type:

wget -qO - ipv4.icanhazip.com

results in your CAS' public IP address. You’ll need that in the next step.

Now let’s authorize your public key:

1. Open the authorization list:

   mkdir $HOME/.ssh nano $HOME/.ssh/authorized_keys

2. Copy & Paste the public key file contents (press Ctrl-Shift-V to paste into nano).

3. Exit and save (Ctrl-X, then “Y”).

Typing this:

cat $HOME/.ssh/authorized_keys

should display something like this:

If no errors, then you’re good to move on to the next step. The key entered will only work for a login that has it listed in their file. Multiple users can add that public key. In this example, the user’s login name is “demo” (see the “demo@blackbox” prompt?).

Assemble the SSH parameters.

You started reading this article with the port in hand. Read the docs!

• In this example, we’ll forward port 8090.

The login username and CASIP address are determined by your CAS server credentials.

• in this example, we’ll use demo@123.123.123.123

The private key was created in the first step.

• in this example, we’ll use $HOME/.ssh/id_ed25519

Try the tunnel.

First, make sure you’ve set it up properly so far. Fill in the correct parameters here:

ssh -i $HOME/.ssh/id_ed25519 demo@123.123.123.123

This should result in an SSH login prompt on your CAS server.

• Your key password will be requested (assuming you created it that way).

• The CAS server fingerprint may be identified as “new”, if so - permit it to proceed (reply: yes).

Exit the connection (type “exit”) if no errors are shown.

• if you see errors, return to the beginning, check your syntax! Something’s wrong.

We’re ready to proceed if there were no errors so far.

Type this (with the correct parameters inserted) to create a tunnel to your CAS server:

ssh -f -N -i $HOME/.ssh/id_ed25519 -R 8090:127.0.0.1:8090 demo@123.123.123.123

• Enter the requested password again (if any).

• You’ll have to repeat this process anytime you reboot this node, or your CAS server.

Test it.

Your relevant CAS Crypto Setting tests should now pass, as though the node were running on your CAS server. NOTE: you must modify your CAS Crypto Setting parameter’s “host” when using an SSH tunnel.