1. Educate Yourself

Confidentiality is having the agency to decide when you reveal personal information. It is a particularly valuable quality today, when the collection and storage of personal data is taking place at unprecedented levels. We are in an age where data is of high value, and Beldex aims to equip individuals with tools to obfuscate their information and interactions with the internet. Protecting your data keeps power on your side.

Beldex's confidentiality tools offer free communication by incentivising indviduals through its cryptocurrency block reward to keep the network confidential, secure and untraceable.

Before you start using Beldex, you should educate yourself on how Beldex will help you obfuscate your data.

2. Choose Your Wallet

The Beldex wallets are a gateway into confidential, decentralised transactions and communications. They allow you to hold private keys, secure Beldex, stake Beldex and trade peer-to-peer.

If you are unsure about which wallet to choose, you should go to the Which Wallet To Use page.

3. Acquire Beldex

Beldex can be purchased on exchanges (currently listed on MEXC, Gate.io, KuCoin and other exchanges which can be found here: https://coinmarketcap.com/currencies/beldex/#Markets).

You can also aquire Beldex by staking it on masternodes & earning rewards in BDX for your contribution. Staking BDX on masternodes is process by which users can participate in the Beldex network and earn rewards by validating transactions made on the Beldex blockchain.

4. Stake and Earn Beldex

You can stake Beldex to receive rewards by running a Master Node with peers or by yourself.

To operate a Master Node, an operator time-locks a significant amount of Beldex and provides a minimum level of bandwidth and storage to the network. In return for their services, Beldex Master Node operators receive a portion of the block reward from each block.

The Beldex wallets are a gateway into confidential, decentralised transactions and communications. They allow you to hold private keys and secure, mine, stake or trade Beldex. Each wallet is designed specifically for different users depending on their goal and level of expertise.

The different wallets currently available are the:

• Graphical user interface wallet (GUI)

• Command-line interface wallet (CLI)

• Mobile wallet

• Web wallet

Use cases

Before deciding which wallet you want to use, you must first know what you want the wallet for.

Receiving and sending Beldex

All Beldex wallets can receive and send Beldex, however some are much easier to use for this specific purpose.

The easiest wallets to use for sending and receiving Beldex are:

• Graphical user interface wallet (GUI), or the

• Mobile wallet

The GUI wallet can be downloaded

Hosting a Master Node as an Operator

If you want to host and operate a Beldex Master Node, there is only one wallet that offers the ability to register a Master Node: the command-line interface wallet (CLI) which can be downloaded .

To better understand how to prepare, register and maintain a Master Node, check out this guide .

Staking to a Master Node as a contributor.

Do you have at least 25% of a Beldex Master Node staking requirement, and want to contribute to a Master Node pool?

If so, you will want to either use the:

• Graphical user interface wallet (GUI) - Currently under development, or the

• Command-line interface wallet (CLI)

You can download the cli-wallet from

Confidentiality is having the agency to decide when you reveal personal information. It is a particularly valuable quality today, when the collection and storage of personal data are taking place at unprecedented levels in history.

Beldex is a confidential currency based on Monero, Beldex currently offers incentive based Master Nodes and in future Beldex will be using POS instead of POW.

Beldex is mainly focused on utilities where you can spend beldex freely, we are in the process of creating a crypto ecosystem to eliminate the middleman and perform financial transactions with absolute freedom

More information on the project can be found on the

If you are unsure where to start check out our "Getting Started" page by

Community Channels

• Telegram Channel:

• Telegram Chat:

• Discord:

• GitHub:

• Twitter:

• Facebook:

Copyright

Copyright (c) 2019 The Beldex Project.

Portions Copyright (c) 2014-2018 The Monero Project. Portions Copyright (c) 2012-2013 The Cryptonote developers.

Wallets

The Beldex wallets are a gateway into confidential, decentralised transactions and communications. They allow you to hold private keys, secure or mine Beldex, and trade peer-to-peer.

Beldex wallets store a collection of public and private keys which can be used to receive, view, or spend Beldex.

The wallet uses the private keys through a daemon which synchronises with the Beldex Network to scan for incoming transactions and to send outgoing transactions.

Command Line Interface Wallet (CLI)

The Cli Wallet is for more advanced users and offers the most tools when interacting with the Beldex Blockchain.

CLI Guides

Address

A Beldex public address is what you publish to get paid.

An address can be generated offline and for free. It boils down to generating a large random number representing your private spending key.

Publishing your Beldex address does not endanger your confidentiality. That's because in Beldex transactions go to stealth addresses which are decoupled from your public address.

There are a few types of public addresses in Beldex:

• Main address - basic type of an address, also refered to as raw address

• Subaddress - what you should be using by default

• Integrated address - relevant for exchanges, merchants, and other businesses accepting Beldex in a fully automated way

Main address

Historicaly, raw address was the only available option. For that reason it is the most widely adopted and supported address type.

Its strength is simplicity. However, these days users should prefer receiving to subaddresses instead.

Technically, raw address is also a basis for creating subaddresses and integrated addresses.

Raw address is still useful for:

• accepting block reward in a solo-mining scenario as other addresses are not supported

• accepting from senders who batch payouts (like mining pools); in this scenario the sender is paying multiple parties using a single transaction; such transaction has multiple outputs; subaddresses do not work in this scenario

• accepting from senders who use legacy wallets (can't send to subaddress)

Beldex raw address is composed of two public keys:

• public spend key

• public view key

It also contains a checksum and a "network byte" which actually identifies both the network and the address type.

Data structure

It totals to 70 bytes. The bytes are then encoded (src) in Beldex specific Base58 format, resulting in a 96 chars long string. Example main address:

bxXk6eS3Ng98QxDTdC47eNdfCXttJycKraXxfsw9cMVngGUqP3kiSE6cwXoApU6gjzSXVX1ASAPAi1MSXA935XUs1MWEcv9

See the source code.

Generating

Main address is derived from the root private key.

Reference

• StackExchenge answer

• https://xmr.llcoins.net/addresstests.html

In cryptocurrencies, multisig feature allows you to sign a transaction with more than one private key. Funds protected with multisig can only be spent by signing with M-of-N keys.

Beldex Multisignature

Beldex doesn't directly implement multisignatures (at least not in a classical sense). Monero emulates the feature by secret splitting and Beldex has brought this code from Moneros code base.

Transactions are still signed with a single spend key. The spend key is a sum of all N private keys. The rationale for such design is to decouple multisig from ring signatures.

Let's consider the 2-of-3 scheme. We have 3 participants. Each participant is granted exactly 2 private keys in a way that pairs do not repeat between participants. This way any 2 participants together have all 3 private keys required to create the private spend key.

Multi-signing is a wallet-level feature. There is no way to learn from the blockchain which transactions were created using multiple signatures.

It is also worth noting in Beldex there is no multisig addresses as such. The Address structure does not care how the underlying private spend key got created.

In Beldex, multisignature is supported for M of N participants making any combination of signers possible.

After multisig wallet setup every participant ends up knowing the public address and private view key. This is necessary for participants to recognize and decipher transactions they are supposed to co-sign.

Guides

Remote Nodes

On any given cryptocurrency network, storing a full copy of the blockchain is not possible or practical for many users. In Bitcoin and Ethereum, users can choose to connect to a public full node that holds a copy of the blockchain and can query and submit transactions to the network. This works because Bitcoin and Ethereum full nodes can efficiently search the blockchain for transactions that have the users public key as the target.

Due to the construction of CryptoNote currencies, public full nodes (called remote nodes) are put under much more stress. When a user connects to a remote node, they must temporarily download every block (upon wallet creation or since last checked block) to their local machine and check each transaction for a public transaction key which can be generated from the users private view key. This process can cause a significant performance impact on remote nodes. Considering that there is no reward for this service, it can dissuade users from operating syncing services for light clients. CryptoNote mobile wallets are often unreliable and sometimes have to switch between remote nodes multiple times before establishing a reliable connection to either scan the blockchain or to submit a transaction.

Additionally, malicious remote node operators running one of the few popular nodes can record the IP address of users as they broadcast specific transactions. Although no information about the actual transaction is revealed by this attack, specific IP addresses can be linked with transactions which can then be used to establish a link to a real-world identity, compromising confidentiality.

Beldex circumvents these issues by requiring each Master Node to act as a remote node that can be used by general users. Master Nodes naturally lend themselves to this work as they already hold a full copy of the blockchain and form a widely distributed network of high bandwidth nodes. By using Master Nodes as remote nodes, there is an inherent financial limitation as to how much of the remote node network any given party can own, and therefore, how much data a malicious node operator can collect.

Getting Super Powers

Becoming a super hero is a fairly straight forward process:

$ give me super-powers

Once you're strong enough, save the world:

# Ain't no code for that yet, sorry
echo 'You got to trust me on this, I saved the world'

A stake involves holding a specific cryptocoin in a wallet for a particular period of time. A staking requirement is the minimum amount of said cryptocoin that is required to stake.

Master Node Staking Requirement

A Beldex staking Requirement is the collateral requirement an operator stakes through a time-locked output, which can be unlocked as per the contributor's request. Upon a request to unlock the funds they will stay locked for an additional 15 days where the contributor will still receive rewards. In the extra field of the transaction, the Master Node operator includes the Beldex address which may receive Master Node rewards. This address will also be used as the public key for Master Node operations such as swarm voting.

Before each node joins the Master Node network, other nodes must individually validate that the said nodes collateral outlay matches the required amount, as per the decreasing collateralisation requirement. If the node is offline for a reasonable time, its uptime proof will not be sent to the other nodes resulting in a deregister of the node. Deregistered nodes will have their collateral requirement locked for 30 days.

The staking requirement is 10,000 bdx during Master Node launch (block height 56240). The staking amount is constant at the moment. The amount may vary based on the future emmision.

If you have a Mnemonic Seed Phrase, restoring your wallet from it would probably be a good option. Otherwise, you can restore your wallet from private keys. You will need to have the following keys to proceed:

• Wallet public address

• Spend Key

• View Key

Step 1: Download and unzip CLI wallet

• Download the latest release of wallet CLI software for your desired operating system: https://github.com/beldex-coin/be/reldex/releases

• Unzip beldex-[operating-system]-[platform]-[version].zip file

Step 2: Run wallet in restore mode

• Open a Command Prompt (Windows) or Terminal (Linux / OSX) and navigate to the wallet folder

• Run wallet with --generate-from-keys argument:

./beldex-wallet-cli --generate-from-keys [New Wallet Name]

Where [New Wallet Name] is a new wallet name. You can enter any name here, use something rememberable and meaningful.

Step 3: Enter wallet address, view and spend keys

On the next step, specify all 3 wallet keys, one by one:

• Enter Standard address and press [Enter]

• Enter Secret spend key and press [Enter]

• Enter Secret view key and press [Enter]

Step 4: Enter wallet password

• You will be prompted for a password. Enter a new password that follows the Password Policy and press [Enter].

• Confirm password and press [Enter].

Step 5: Specify a blockchain height

If you know the block height at which wallet was created or a first transaction was made, you can enter it here. Specifying a blockchain height will help to scan the wallet faster.

If you don't know a specific blockchain height, press [Enter] for scanning from block height 0.

Step 6: Wait for the refresh process to finish

For refresh process to start, you need to have your daemon running. Another option would be to use a remote node. For that, use the following command, replacing and with the host and port number of the remote node you are connecting to:

./beldex-wallet-cli --daemon-address <host>:<port>

Once refresh is done, you can use your full functioning restored wallet. Your public wallet address will remain the same.

To fully restore your wallet and be able to view balance and make transactions, having your seed stored will be enough. You don't need your wallet password or other keys to restore the wallet once you have a seed phrase.

Step 1: Download and unzip CLI wallet

• Download the latest release of wallet CLI software for your desired operating system: https://github.com/beldex-coin/beldex/releases

• Unzip beldex-[operating-system]-[platform]-[version].zip file

Step 2: Run wallet in restore mode

• Open a Command Prompt (Windows) or Terminal (Linux / OSX) and navigate to the wallet folder

• Run wallet with --restore-deterministic-wallet argument

For Linux:

./beldex-wallet-cli --restore-deterministic-wallet

For Windows:

beldex-wallet-cli --restore-deterministic-wallet

Step 3: Enter wallet name

You will be prompted to enter a wallet name and click [Enter]. You can enter any name here, use something rememberable and meaningful.

Step 4: Enter your seed phrase

• You will be prompted to enter 25 word mnemonic seed you have stored. Paste it and press [Enter].

• If you have a seed encryption passphrase, enter it on the next step. Otherwise, press [Enter].

Step 5: Enter wallet password

• You will be prompted for a password. Enter a new password that follows the Password Policy and press [Enter].

• Confirm password and press [Enter].

Step 6: Specify a blockchain height

If you know the block height at which wallet was created or a first transaction was made, you can enter it here. Specifying a blockchain height will help to scan the wallet faster.

If you don't know a specific blockchain height, press [Enter] for scanning from block height 0.

Step 7: Wait for the refresh process to finish

For refresh process to start, you need to have your daemon running. Another option would be to use a remote node. For that, use the following command, replacing and with the host and port number of the remote node you are connecting to:

./beldex-wallet-cli --daemon-address <host>:<port>

Once refresh is done, you can use your full functioning restored wallet. Your public wallet address will remain the same.

Integrated addresses are ideal for accepting Beldex in an automated fashion - like in online stores and exchanges.

Beldex integrated address embeds a payment ID. This allows you to learn for what you are being paid.

Please note these are Beldex technical payment IDs and must not be confused with business identifiers like order number or invoice number.

The transaction to integrated address will not reveal the payment ID publicly. Payment ID in a transaction will be encrypted with a shared secret (one-time random key known only to sender and recipient). Only the recipient will be able to match the transaction against payment ID.

Beldex integrated address obsoletes the former practice of using full 32-bytes payment ID in a transaction extra field (where it was not encrypted).

Data structure ():

It totals to 77 bytes. The bytes are then encoded () in Beldex specific Base58 format, resulting in a 106 chars long string. Example integrated address:

4LhSDqBZdjLQWajr4pBcFkdjL8oGY7MDvfJkKfrQVaokfDMxU6bDVb6h8tsD1jpKpSXbbB1p8RxPbA7fmjvLGjicKLBdQvDMbHA7TWVCUQ

Integrated addresses vs subaddresses

Both types allow you to learn for what you are being paid.

Individuals should prefer subaddresses to receive payments. This is to improve confidentiality in certain scenarios. See article on for details.

Businesses accepting payments in an automated way should prefer integrated addresses. The rationale is as follows:

• Scenario where subaddresses improve confidentiality is not applicable to businesses b/c businesses have the same identity over time. Consequently, subaddresses provide no benefits over integrated addresses.

• No private key is necessary to generate integrated address. This provides a strong security advantage because services that generate integrated addresses need no access to wallet. In contrast, to generate a subaddress, one needs a private view key.

• No shared counter is necessary to generate integrated address. This allows individual services to independently generate integrated addresses w/o synchronizing on a common sequence. In contrast, subaddresses are generated sequentially, and so the sequence (the counter or index) is a coupling point between the wallet and all services that need to generate the address. Back to integrated addresses, note that embedded payment IDs are 64-bit. This means the space is large enough that one can simply generate them randomly and reliably assume uniqueness.

• In very specific scenarios, preparation effort to monitor a very huge number of subaddresses, could became an issue. See for details.

Caveats

There are some caveats:

• Single transaction cannot pay to multiple integrated addresses.

• As individual running a wallet you should generally prefer subaddresses. However, if you happen to use integrated addresses, you should allow Beldex software to generate integrated addresses for you (instead of forcing your own payment IDs).

Reference

• question on

Although Beldex implements novel changes on top of the (, & ), much of Beldex’s networking functionality and scalability is enabled by a set of incentivised nodes called Master Nodes. To operate a Master Node, an operator and provides a minimum level of bandwidth and storage to the network. In return for their services, Beldex Master Node operators receive a portion of the block reward from each block.

The resulting network provides market-based resistance to Sybil attacks, addressing a range of problems with existing mixnets and confidentiality-focused services. This resistance is based on supply and demand interactions which help prevent single actors from having a large enough stake in Beldex to have a significant negative impact on the second-layer confidentiality services Beldex provides. first theorised that Sybil attack resistant networks can be derived from cryptoeconomics. As an attacker accumulates Beldex, the circulating supply decreases, in turn applying demand-side pressure, driving the price of Beldex up. As this continues, it becomes increasingly costly for additional Beldex to be purchased, making the attack prohibitively expensive.

To achieve this economic protection, Beldex encourages the active suppression of the circulating supply. In particular, the and must be designed to ensure enough circulating supply is locked and reasonable returns are provided for operators to ensure Sybil attack resistance

Master Node Activities

Right now Master Nodes are full nodes on the Beldex network. Full nodes become Master Nodes when the owner for 30 days (2 days on testnet) and submits a registration transaction. Once accepted by the network, the Master Node is eligible to win . Multiple participants can be involved in one Master Node and can have the reward automatically distributed.

Guides & Resources

Windows

Download BelNet GUI for windows from the .exe file below:

Linux

Download BelNet GUI for Linux using the guide below:

Step 1: Add the key

Enter the following command to add the keys

sudo curl -L https://deb.beldex.io/pub.gpg | sudo apt-key add - && echo "deb https://deb.beldex.io/apt-repo stable main" | sudo tee /etc/apt/sources.list.d/beldex.list

Step 2: Update the certificate

Enter the following command into the terminal to install and update the certificate

sudo apt install ca-certificates && sudo apt update

Step 3: Install BelNet GUI

Enter the following command to complete the BelNet GUI installation

sudo apt install belnet-gui

Step 1: Install Docker and Docker-Compose

Docker and docker-compose are prerequisites to download and run the docker images and container.

Enter the following commands to download and install docker.

sudo apt update && sudo apt install apt-transport-https ca-certificates curl software-properties-common -y && curl -fsSL 
https://download.docker.com/linux/ubuntu/gpg
 | sudo apt-key add - && sudo add-apt-repository "deb [arch=amd64] 
https://download.docker.com/linux/ubuntu
 focal stable" && sudo apt update && sudo apt install docker-ce -y && sudo systemctl status docker

Enter the following commands to download and install docker-compose.

sudo curl -L "
https://github.com/docker/compose/releases/download/1.28.5/docker-compose-$(uname
 -s)-$(uname -m)" -o /usr/local/bin/docker-compose && sudo chmod +x /usr/local/bin/docker-compose && docker-compose --version

Step 2: Pull the Image From Docker Hub

Enter the following command into the terminal to pull the BelNet Exit Node image from the docker hub.

docker pull beldex/belnet-exitnode:v2

Step 3: Download & Compose yml File

Enter the following command to get the BelNet yml file from Beldex deb.

sudo apt install wget && wget 
https://deb.beldex.io/Beldex-projects/Belnet/docker-compose.yml

Step 4: To Run Container

Enter the following command to run the yml file as a container.

docker-compose up -d

Step 5: Login Into Container

Enter the following command to get the container ID and other details.

docker ps

Enter the following command after replacing your container ID in place of <container -id>

docker exec -it <container -id> bash

Step 6: To View Exit Node Address

Your exit node is now live. Get your exit node’s BelNet address using the following command.

host -t cname localhost.bdx 127.3.2.1

Outline For Existing Master Node Participants and Operators

Infinite Staking is an incremental upgrade on the existing staking process that is currently available on the Beldex network (currently active in Hardfork 10: Bulletproofs, introduced in Hardfork 9: Master Nodes). With Infinite Staking, Master Nodes do not expire and funds remain locked until a contributor or operator explicitly requests the Master Node to unlock the funds.

Since Infinite Staking is an incremental upgrade, most of the steps necessary to register and participate in a Master Node remain the same. A quick overview for the new staking process is summarised for quick grokking. (Yes, grokking is a word. Google it.)

Updated Staking Process and Commands

Operators

Operators will still use the following commands when setting up a Master Node. The commands are as follows:

• prepare_registration in the daemon that is running in --master-node mode.

• register_master_node with the command returned by the daemon. Auto staking is no longer an option.

Contributors

Two new commands have been added to stop your Master Node from staking, and both the contributor and operator can execute these commands:

• stake <master node key> to contribute to the node. Auto staking is no longer an option.

Operators & Contributors (When Master Node Active)

Two new commands have been added to stop your Master Node from staking, both the contributor and operator can execute these commands:

• (Optional) print_locked_stakes to preview all the current wallet’s transactions that are locked in a Master Node or blacklisted on the network.

• request_stake_unlock <master node key> to request to unlock the stake in 15 days (10800 blocks).

Unlocking Stakes & Deregistration

Master Nodes will continually receive block rewards indefinitely until a stake is unlocked or the Master Node becomes deregistered. Unlocking is available via the request_stake_unlock <master node key> in the command line wallet. Once the unlock is requested and the request is included in a block in the blockchain, the Master Node will then expire in 15 days (10800 blocks) and the funds will become unlocked after expiry.

In pooled nodes, any contributor that requests the stake to unlock will schedule the Master Node for expiration. All locked stakes in that Master Node will be unlocked in 15 days (10800 blocks). Once the unlock is requested, this process can not be undone or prolonged. Master Node participants will continue receiving rewards until expiration.

Under the new system, deregistrations can be issued at any point during the active lifecycle of the Master Node. This is inclusive of the time period during which the Master Node is scheduled for expiry. Getting deregistered removes your Master Node from the network and your stakes are placed into a list of blacklisted transactions. Blacklisted transactions are locked and unspendable for 30 days (21600 blocks) from the block in which the Master Node was deregistered.

Receiving a deregistration after participants have already requested the stake to unlock overrides the 15 day (10800 blocks) unlock time, and resets the unlock time to 30 days (21600 blocks).

Minimum Contribution Rules

Infinite Staking introduces new limitations on the number of transactions that can be contributed to a Master Node, changing the minimum contribution rules for participating in the Master Node.

Master Nodes accept at most 4 contributions, meaning the minimum contribution to a Master Node becomes:

In a pooled Master Node with reserved spots, the Minimum Contribution must be either the Reserved Amount or the Contribution determined by the above equation, whichever is larger.

A simplistic example being, if the staking requirement is 24,000 BDX then if,

• Operator contributes 50% of the requirement (12,000 BDX)

• The next contributor must contribute at least (⅓ * 12,000) BDX i.e. 4000 BDX to become a participant.

• If this contributor had reserved a spot for more than 4000 BDX, their Minimum Contribution would be that amount.

There are rules in the client software in place to stop users from irreversibly funding a Master Node into an invalid state.

Staking Changes

Users are no longer allowed to stake on behalf of another participant in the Master Node. All contributions for a participant must come from the same wallet address as the one specified in the Master Node.

Developer API Changes

get_master_nodes

Updated/newly added fields:

• requested_unlock_height - The height at which the stakes will unlock and the Master Node will expire.

• contributors

  • locked_contributions - An array of each contribution from the contributor that is locked.

    • key_image - A string representation of the locked key image (stake).

    • key_image_pub_key - A string representation of the public key component of a key image.

    • amount - The amount of Beldex locked in this contribution.

get_master_node_blacklisted_key_images

Retrieve a list of blacklisted transactions from deregistered Master Nodes on the network.

• blacklist - An array of each blacklisted transaction from deregistered Master Nodes

  • key_image - A string representation of the blacklisted key image (stake).

  • unlock_height - The height at which the stake can be spent again.

The easiest and most efficient way to set up a master node is by using Docker. Follow these two simple steps to set up a master node with Docker. We have provided a shell script to handle all the heavy lifting for you.

Note: This guide assumes some familiarity with the command line and running a Linux server. For a more detailed walkthrough, check out our full Master Node setup guide.

Step 1 : Create or Download the shell file

Copy the below code to a shell file master-node-deploy.sh

OR

Step 2: Register Master Node

Make sure the node is fully synced before run this command

Check the node status

You should receive an output similar to the screenshot provided. Ensure that the height of your node matches the current network height, which can be verified at . If the heights do not match, allow the node to fully sync, which may take 4-5 hours.

Prepare for Registration

Once the node is fully synced, run the below command to register the master node

After successfully running the command, you will receive an output similar to the screenshot below. To complete the registration, execute the master node command from the output in your wallet.

The beldex-wallet-cli is the “Command Line Interface” wallet software that is used to run Beldex accounts through command prompt or terminal. The CLI wallet only uses text to do operations, where the oki-wallet-gui wallet offers a graphical user interface with buttons to do most of the operations the beldex-wallet-cli does.

Bear in mind that the CLI wallet, while harder to use, is generally faster and more reliable. If you are still interested in the 'beldex-wallet-cli' you can find it here. Download the latest release for your specified Operating System, for this user guide we are going to assume you are running Linux.

Step 1: Opening beldex-wallet-cli and beldexd.

To use the beldex-wallet-cli we must first have the daemon, beldexd, up and running. The beldexd is your node which the beldex-wallet-cli broadcasts through. Without the node running the beldex-wallet-cli will not be able to operate.

Run the beldexd file from the folder you extracted the release.

$ ./beldexd

Once you run the above command you will get the below message in the terminal

**********************************************************************

The daemon will start synchronizing with the network. This may take a long time to complete.

You can set the level of process detailization through "set_log <level|categories>" command,

where <level> is between 0 (no details) and 4 (very verbose), or custom category based levels (eg, *:WARNING).

Use the "help" command to see the list of available commands.

Use "help <command>" to see a command's documentation.

**********************************************************************

Let the daemon run until the node is completely synced, you will know the node is synced once the terminal outputs the following text:

**********************************************************************

You are now synchronized with the network. You may now start beldex-wallet-cli.

Use the "help" command to see the list of available commands.

**********************************************************************

Now the daemon is synced we can run the beldex-wallet-cli file.

Step 2: Setting up your beldex-wallet-cli account.

If this is your first time opening the beldex-wallet-cli it will request for you to specify a wallet name. For the purposes of this user guide we will use the example name MyBeldexWallet

Specify wallet file name (e.g., MyBeldexWallet). If the wallet doesn't exist, it will be created.

Wallet file name (or Ctrl-C to quit): MyBeldexWallet

Because this is the first time we have used the name MyBeldexWallet the following text will appear in our terminal. Type in Y or Yes to confirm your wallet name.

No wallet found with that name. Confirm creation of new wallet named: MyBeldexWallet

(Y/Yes/N/No): Yes

The beldex-wallet-cli has now generated us a wallet called MyBeldexWallet and is now prompting us for a password for our generated wallet.

Please note:

• When typing the password, the characters will not appear. It will seem as if you are typing and no text is appearing however the terminal is logging every character your clicking including if it is capitalised or lowercase.

• Write down your wallet name and password on a piece of paper as this information will be required every time we want to enter our wallet.

• Use a password with uppercase letters, lowercase letters, numbers, symbols and make the password at least 9 characters long.

Generating new wallet...

Enter a new password for the wallet:

Confirm password:

Now once we have chosen our password for the wallet we must choose our language. For the purposes of this user guide I suggest you use English by typing 1 and clicking enter.

List of available languages for your wallet's seed:

If your display freezes, exit blind with ^C, then run again with --use-english-language-names

0 : Deutsch

1 : English

2 : Español

3 : Français

4 : Italiano

5 : Nederlands

6 : Português

7 : русский язык

8 : 日本語

9 : 简体中文 (中国)

10 : Esperanto

11 : Lojban

Enter the number corresponding to the language of your choice: 1

The beldex-wallet-cli will generate and spit out several lines of text. Some of the information that was outputted will only ever show once, therefore it is very important to do this next section properly otherwise we may lose access to our account, thus losing access to our funds.

Let’s take a close look at each section of the newly generated wallet:

The text after Generated new wallet shows your public address. This address can be shared and will be used to receive Beldex to your wallet. All Beldex public addresses start with b....and are followed with a string of characters. The public address shown will be your primary address however multiple public addresses can be generated from this primary address.

You do not need to write down the public address, the command address will re-display it whenever required.

Generated new wallet: bxdXk6eS3Ng98QxDTdC47eNdfCXttJycKraXxfsw9cMVngGUqP3kiSE6cwXoApU6gjzSXVX1ASAPAi1MSXA935XUs1MWEcv9

The View key address is not to be shared unless you want to show the transactions received to the public address connected to this wallet. You do not need to write down the view key as it can be re-displayed with the command viewkey.

View key: 97d3c27e20818e5e23a6548458b50d4f128a2709c55eb7f9518d0e957a5d2e0d

The next few lines of text show how to navigate the beldex-wallet-client.

This user guide will look into more detail the commands that can be used within the beldex-wallet-client further in the guide.

Your wallet has been generated!

To start synchronizing with the daemon, use the "refresh" command.

Use the "help" command to see the list of available commands.

Use "help <command>" to see a command's documentation.

Always use the "exit" command when closing beldex-wallet-cli to save

your current session's state. Otherwise, you might need to synchronize

your wallet again (your wallet keys are NOT at risk in any case).

The next section with the random 25 words is your mnemonic seed. The seed is used to easily back-up and restore your wallet without needing any other information. At this stage, grab a pen and paper and write down your 25 words in order(having these words out of order will not restore your wallet) and store the piece of paper in a safe and secure place. If your words are stored in a text file on your computer or stored online, you increase your risk of someone else getting control of your account.

NOTE: the following 25 words can be used to recover access to your wallet. Write them down and store them somewhere safe and secure. Please do not store them in your email or on file storage services outside of your immediate control.

ponies innocent oyster whale autumn knapsack jostle elapse

inroads joining doorway ticket drying obnoxious algebra tutor

biplane sack alpine zinger huge duets refer rigid inroads

The last of the outputs are the account balance, because your wallet does not have any Beldex in it currently the balance is showing 0.

Once we receive a transaction of Beldex into our wallet the balance will appear as soon as the transaction is confirmed in one block (usually less than 2 minutes). Once the transaction has been confirmed over 10 blocks the balance will show in unlocked balance.

The unlocked balance is the Beldex available to be spent/sent to other addresses.

Starting refresh...

Refresh done, blocks received: 0

Untagged accounts:

Account Balance Unlocked balance Label

* 0 bxdXk6 0.000000000 0.000000000 Primary account

----------------------------------------------------------------------------------

Total 0.000000000 0.000000000

Currently selected account: [0] Primary account

Tag: (No tag assigned)

Balance: 0.000000000, unlocked balance: 0.000000000

Background refresh thread started”

The server specifications such as storage and bandwidth for hosting an MNApp are dependent on the user's requirements. For example, a video streaming platform may require more storage than an information sharing platform.

However, you need a Linux system with Ubuntu 18.04 or 20.04 to run an MNApp.

Step 1: Install BelNet on Your System and Generate Your Belnet Address

Download and run the binaries

Enter the following command into the terminal to download the Belnet binaries from cloud

wget 
https://deb.beldex.io/Beldex-projects/Belnet/deps/v0.9.6/linux/belnet-linux-x86_64-v0.9.6.zip

Unzip the file using the following command

unzip belnet-linux-x86_64-v0.9.6.zip

Run the Belnet binary

sudo ./belnet

Then, copy and paste the following command to open the belnet.ini file.

sudo vim /var/lib/belnet/belnet.ini

Scroll down to the [network] section and configure the keyfile by giving it a name of your choice. Your MNApp private key will be stored in the following path. Here, we’ve named our keyfile, mnappkey.private

keyfile=/var/lib/belnet/mnappkey.private

Enter the following command and restart the Belnet client

sudo ./belnet

Step 2: Find Your MNApp’s BelNet Address

To find your MNApp address, enter the following command.

host -t cname localhost.bdx 127.3.2.1

For example, this is the MNApp address for the Beldex explorer hosted on BelNet cw41adqqhykuxw51xmagkkb3fixyieat1josbux13jn6o973tqgy.bdx

Step 3: Download and Install Nginx

Nginx is a dependency. So download and install it using the following commands

sudo apt update
sudo apt install nginx

Use the following command to check whether nginx is working

systemctl status nginx

Step 4: Setup Your MNApp Web Page

Your web content goes into this directory

Create a directory using the following command. Give a name to your directory. You can do this by replacing your_own-directory in the command below with your directory name.

sudo  mkdir /var/www/your_own_directory/

Place your html web page into this directory

Step 5: Configure Nginx

Below is a sample configuration of Nginx

Enter the following commands

sudo cd /etc/nginx/sites-available
sudo vim default

Now enter your directory’s name (established in Step 4) in place of your_own_directory in the command below.

root /var/www/your_own_directory; 

Add the index file of your webpage here using the following command.

Note: Replace your_webpage with the filename that you want to assign to your index html file.

index your_webpage.html;

Now choose a server name by entering the following command. Replace the sample BelNet address below with your MNApp’s BelNet address generated in Step 2.

server_name cw41adqqhykuxw51xmagkkb3fixyieat1josbux13jn6o973tqgy.bdx;

Save it by pressing Esc and then :wq

Restart Nginx using the following command

sudo systemctl restart nginx.service

To access your MNApps, connect to BelNet and enter the MNApp’s BelNet address into a browser’s address bar

e.g. http://cw41adqqhykuxw51xmagkkb3fixyieat1josbux13jn6o973tqgy.bdx/

Note: You cannot host a masternode and an MNApp in the same server. You cannot host a BelNet exit node and an MNApp in the same server.

Server Requirements

• Operating System: Ubuntu 18.04 or higher

• Storage: Minimum 40GB

• RAM: 2-4 GB

• CPU: 1 Core

Step 1: Initial Master Node Setup

1. Add the Public Key: Install the public key required to verify and sign the Beldex Master Node packages:

   Copy

   sudo curl -L https://deb.beldex.io/pub.gpg | sudo apt-key add -

2. Add the Package Repository: Inform the package manager about the location of the Beldex repository:

   Copy

   echo "deb https://deb.beldex.io/apt-repo stable main" | sudo tee /etc/apt/sources.list.d/beldex.list

3. Update Package Repositories: Resynchronize your package manager to include the new repository:

   Copy

   sudo apt update

4. Install the Master Node Package: Set up your Master Node by installing the required package:

   Copy

   sudo apt install beldex-master-node

   • This command will detect your public IP or prompt you to enter it manually and update the configuration file (/etc/beldex/beldex.conf) with the necessary settings.

Step 2: Verify Services Status

Beldex Node:

Check if the beldex-node service is running correctly:

systemctl status beldex-node.service

Command Output:

Beldex Storage Server:

Verify the status of the beldex-storage-server service:

systemctl status beldex-storage-server.service

Command Output:

Note: Ping to daemon will start after 57000 blocks

Belnet Router:

Confirm the belnet-router service is operational:

systemctl status belnet-router.service

Command Output:

Step 3: Check Status of the Daemon

Beldex Daemon:

• Verify the status of beldexd:

  Copy

  beldexd status

• If the Master Node public key and last pings are not displayed, restart the beldex-node service:

systemctl restart beldex-node.service

Status after received ping from the storage server and belnet

Note: Ping from storage server and belnet is mandatiry for master node registration

Step 4: Register Master Node

1. Once the node synchronization reaches 100%, prepare the Master Node registration:

   Copy

   beldexd prepare_registration

Enter the wallet address when prompted, and follow the instructions carefully.

After providing all the required prompt data, the register_master_node string will be generated.

Open the Electron Desktop wallet and enter the generated register_master_node string in the registration section as shown in the below screenshot

When you click the "Register Master Node" button, the Master Node will be successfully registered, and a confirmation message stating "Master Node registered successfully" will be displayed.

Congratulations !!! You are now successfully registerd the master node and the reward will be credited directly to the wallet which you used to regiuster the master node

Error Handling and Troubleshooting

1. Storage Server Not Pinging:

If the beldex-storage-server does not respond to pings in the beldexd status, restart the service:

systemctl restart beldex-storage-server.service

2. Belnet Router Not Pinging:

If the belnet-router ping is not received:

systemctl restart belnet-router.service

3. Belnet Router Bootstrap Error:

If belnet-router fails to bootstrap, follow these commands:

• Check the service status:

  Copy

  systemctl status belnet-router.service

• Navigate to the Belnet directory:

  Copy

  cd /var/lib/belnet

• Bootstrap Belnet:

  Copy

  belnet-bootstrap

• Restart the belnet-router service:

  Copy

  systemctl restart belnet-router.service

• This process ensures the belnet-bootstrap binary downloads the required files to /var/lib/belnet and initiates pings.

System Requirements

Below are the system requirements and the minimum specifications of dedicated server or VPS

Step 1: Install BelNet on your VPS

Copy and paste the following link into the terminal

This will download the Belnet binaries from cloud

Unzip the file using the following command

Execution

• install vim editor using the following command

• Install tmux in your system

• Create a tmux session

• Run the Belnet binary

• Download the bootstrap file using belnet-bootstrap

Step 2: Configure Belnet.ini using vim

• Go to Belnet config directory

• Edit the belnet.ini file by entering the following command

Add the following lines under the [router] section or uncomment the following by removing the #.

This will configure the number of connections that an exit node can maintain.

Add the following lines under the [network] section or uncomment the following by removing the #.

Step 3 Enable IP Forwarding via ''sysctl''

Open the following folder

Add the following lines. This will allow IP forwarding for both IPV4 and IPV6

Press ESC + :wq to save and exit to /etc/sysctl.conf

Enable the changes using the following command

Step 4: Setup firewall

Please check firewall status using the following command

Default result should return the following

-P INPUT ACCEPT

-P FORWARD ACCEPT

-P OUTPUT ACCEPT

Add firewall rules for IPv4

Copy and paste the following commands

Add route for Belnet interface's IPv6

It is beneficial to block ports for Simple Mail Transfer Protocol (SMTP), SMTP over Secure Sockets Layer (SSL), SMTP over Transport Layer Security (TLS), Internet Relay Chat (IRC) and IRC over SSL. This is non-mandatory but may protect your exit node from Distributed Denial Of Service (DDOS) attacks. For more details, kindly check with your VPS host.

Now it is completed

Then, enter the following commands,

The above commands unroll to:

Make firewall settings persistent after rebooting the system by using the command given below

Select Yes on the pop-up window to save current rules to install both for IPv4 and IPv6.

Run Belnet

Step 5: Fetch your permanent .bdx address

Enter the following command to fetch your address

To check if your exit node is publicly hosted, enter the following command

Step 6: If you face any errors, you can troubleshoot your DNS using the following command

Open the resolv.conf file

Please add the following nameserver in the file

Save and exit the file using the command ESC + :wq

JSON 2.0 RPC Calls

get_quorum_state

Get the quorum state which is the list of public keys of the nodes who are voting, and the list of public keys of the nodes who are being tested.

Testnet Example

    curl -X POST http://127.0.0.1:38157/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_quorum_state", "params": {"height": 200}}' -H 'Content-Type: application/json'

Result

    {
      "id": "0",
      "jsonrpc": "2.0",
      "result": {
        "nodes_to_test":
           ["578e5ee53150a3276dd3c411cb6313324a63b530cf3651f5c15e3d0ca58ceddd",
            …
            "c917034e9fcd0e9b0d423638664bbfc36eb8a2eeb68a1ff8bed8be5f699bc3c0"],
        "quorum_nodes":
           ["fc86a737756b6ed9f81233d22da3baee32537f3087901c3e94384be85ca1a9ee",
            …
            "ee597c5c7bbf1452e689a785f1133fc1355889b4111955d54cb5ed826cd35a32"],
        "status": "OK",
        "untrusted": false
      }
    }

Nodes have been omitted with “...” for brevity in nodes_to_test and quorum_nodes.

Inputs

• Int height

The height to query the quorum state for

Outputs

• String[] nodes_to_test

An array of public keys identifying service nodes which are being tested for the queried height.

• String[] quorum_state

An array of public keys identifying service nodes which are responsible for voting on the queried height.

get_staking_requirement

Get the required amount of Beldex to become a Master Node at the queried height. For stagenet and testnet values, ensure the daemon is started with the --stagenet or --testnet flags respectively.

Testnet Example

    curl -X POST http://127.0.0.1:38157/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_staking_requirement", "params": {“height”: 111111}}' -H 'Content-Type: application/json'  

Result

    {
      "id": "0",
      "jsonrpc": "2.0",
      "result": {
        "staking_requirement": 100000000000,
        "status": "OK"
      }
    }

Inputs

• Int height

The height to query the staking requirement for

Outputs

• Uint64 staking_requirement

The staking requirement in Beldex atomic units for the queried height

get_master_node_key

Get the master node public key of the queried daemon. The daemon must be started in --maste-node mode otherwise this RPC command will fail.

Testnet Example

    curl -X POST http://127.0.0.1:38157/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_master_node_key"}' -H 'Content-Type: application/json'  

Result

    {
      "id": "0",
      "jsonrpc": "2.0",
      "result": {
        "master_node_pubkey": "8d56c1fa0304884e612ee2efe763b2c50991a66329418fd084a3f23c75399f34",
        "status": "OK"
      }
    }

Inputs

• N/A

Outputs

• String master_node_pubkey

The public key identifying the queried master node

get_master_nodes

Get the metadata currently associated with the queried master node public keys such as, registration height and contributors, etc. If no public key is specified, this returns all the metadata for every service node the queried daemon currently knows about.

Testnet Example

    curl -X POST http://127.0.0.1:38157/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_master_nodes", “params”: {“master_node_pubkeys”: []}}' -H 'Content-Type: application/json'

Result

    {
      "id": "0",
      "jsonrpc": "2.0",
      "result": {
        "master_node_states": [{
          "contributors": [{
            "address":    "86kZfTEf5JGw2SgLrGuxRNFxRTf51fvbbcCYW949RsKjX75JMA1B1d8CT4VbwfGR8uf3f3AJSTaBHGpN3QRG2N2LyiksWVg",
            "amount": 100000000000,
            "reserved": 100000000000
          }],
          "last_reward_block_height": 2968,
          "last_reward_transaction_index": 4294967295,
          "last_uptime_proof": 0,
          "operator_address": "86kZfTEf5JGw2SgLrGuxRNFxRTf51fvbbcCYW949RsKjX75JMA1B1d8CT4VbwfGR8uf3f3AJSTaBHGpN3QRG2N2LyiksWVg",
          "portions_for_operator": 18446744073709551612,
          "registration_height": 1860,
          "master_node_pubkey": "3afa36a4855a429f5eac1b2f8e7e77657a2e862999ab4d59e473826f9b15f2da",
          "staking_requirement": 100000000000,
          "total_contributed": 100000000000,
          "total_reserved": 100000000000
        }],
        "status": "OK"
      }
    }

Inputs

• String[] master_node_pubkeys

An array of master node public keys in strings that you wish to query metadata for. If an empty array is given, this RPC command returns all master nodes it knows about.

Outputs

• Entry[] master_node_states

The array of metadata for the queried master node(s)

• String master_node_pubkey

The queried master node’s identifying public key

• Uint64 registration_height

The height at which the registration transaction arrived on the blockchain

• Uint64 last_reward_block_height

The last block height this master node received a reward. Rewards are sent to service nodes whom have been waiting longest since their last reward and are then sent to the back of the queue.

• Uint64 last_reward_transaction_index

The position in the queue to receive a reward for the master nodes grouped in the last_reward_block_height.

• Uint64 last_uptime_proof

Unix epoch timestamp of the last time this daemon has received a ping from the queried master node.

• Contribution[] contributors

An array consisting of all the addresses that have contributed to the queried master node.

• Uint64 Contribution.amount

The amount of Beldex in atomic units the contributor has staked.

• Uint64 Contribution.reserved

The amount of Beldex in atomic units the contributor has reserved and must fulfill to completely contribute their part to the service node. Amount is equal to reserved once the contributor has fully contributed their part.

• String Contribution.address

The Beldex address that funds must come from to fulfill the contribution requirement.

• Uint64 total_contributed

The total Beldex currently contributed going towards the staking requirement.

• Uint64 total_reserved

The total Beldex that has been reserved by all contributors. The remaining Beldex is open for other contributors to increase their stake towards the master node.

• Uint64 portions_for_operator

The operator cut expressed as a value from 0 -> STAKING_PORTIONS (defined in beldex/src/cryptonote_config.h) which is the fee taken from the master node reward and given to the operator address before rewards are distributed to the contributors.

• Uint64 operator_address

The wallet address which is the primary owner of the master node and also the address which the operator cut is sent to.

First, the wallet to be converted to multisig must be empty. It is best to use a brand-new wallet for the purpose, although not required. It is strongly advised to make a copy of the wallet files first, just in case something goes wrong.

Overview

In short, the process is:

Wallet Creation

1. All parties command prepare_multisig and send data to ALL other parties

2. All parties command make_multisig <threshold> <data1> <data2> .... <dataN> and send 2nd batch of data to ALL other parties

3. All parties command finalize_multisig <data1> <data2> ...... <DataM> with the data from ALL other parties.

Receiving

1. All parties can type address to see the created multisig wallet address. The address will, of course, be the same for all parties since they're all watching the same wallet.

Preparation for Sending

1. To prepare for sending all parties command export_multisig_info <filename> and send the file to all other parties

2. To complete preparation, all parties command import_multisig_info <filename1> <filename2> ..... <filenameM> and import files from other parties

Sending

1. To send, any party can use the usual transfer command, but the result will be a file named multisig_beldex_tx which must be sent to any 1 other signer

2. The other party commands sign_multisig multisig_beldex_tx and the file is updated with the signature.

3. The completely signed file is pushed to the network with use of submit_multisig multisig_beldex_tx.

Below is a step-by-step walkthrough.

Wallet Creation

Requirements:

• N empty beldex-wallet-cli wallets.

• All parties wallets connected to a beldexd.

• Confidential communication channel.

Step 1 - Prepare Multisig

All N people should open up their beldex-wallet-cli and generate a new wallet. Make sure you do not have any $beldex within your wallet.

The 1st, 2nd, 3rd, and so on, up to the Nth person commands in their beldex-wallet-cli:

prepare_multisig

The output will be something like:

MultisigV1cR7X7ZAfa5ncRmQv1hpt4P1DmmnhinhokhDMqsmuWXmHFrb6xUr3FtBGygCfMScxnKJvXK1vvPNahXNWfYWVquieBErr98sFtgs24c2YuYrQT78uxV8oYx1A9bKeHSUfYzCniN5kMznEfvKCw3FiomjLvw364gg98ZWp16zA7pUVozid  
Send this multisig info to all other participants, then use make_multisig <threshold> <info1> [<info2>...] with others' multisig info  
This includes the PRIVATE view key, so needs to be disclosed only to that multisig wallet's participants

Copy the entire line Multisig…...Vozid and be sure to capture the whole thing when copying.

Each person must send their Multisig…...arg to each other person, it is suggested to send this information through a confidential comunication channel.

Step 2 - Make Multisig

All N people now have the Multisig...arg text from the other N-1 people. With that, each of them can create their part of the multisig wallet. Before you proceed, note that the wallet will lose access to the underlying wallet when converted to multisig. This is not really a problem, since we started with an empty wallet, and if all goes OK with this step, you won't ever need it unless you want to go through the process again for whatever reason (like HDD died, but you have the seed mnemonic of the underlying wallet and want to reconstruct the multisig wallet).

Person 1 commands:

make_multisig <threshold> <data person 2> <data person 3> ..... <data person N>

Where <threshold> is the number of signers required out of the N people, <data person 2>is the output provided by Person 2, and <data person 3> is the output provided by Person 3, and <data person N> is the output provided by the Nth person.

This is the process for M of N multisig wallets, For the below example we will show a 2 of 3 multisig wallet.

This should look similar to:

make_multisig 2 MultisigV12EHtuvxFyAYDNcDsbDqWHDfkRr4JZchSdf8eZQSFwiMKDk15CYEJeQyEwtSnqUZdRr2BsEaT9z2biUdDTEQM4T3N625owvKMDoyhbRj3bwkBtceLKimap8DBAiUmSABpdf62HnPYiRtLW4JdVFmfqjndhWjYBypx1duvpi3qwfSrBY9a MultisigV1TqQ8Gt5Sb3GYtVJa1fQrK7e7hPm59XbooNvLxPSBR4856bW9jtD1hEyWy4yULKrX7reZZ6vrKdBCdSdk4nfApCGYJAA2WP4pKNwHDyKTuLEeuoDhqno8keEVeEF9AZsWXvng1avUTRREmy11h8wu8pdjopC4AguQKiHCJCN7aT9W6b8C  

Notice how there are 2 strings starting with Multisig....arg. One is from person 2 and other from person 3, if their is 5 different people their would be 4 different strings of Multisig....arg. The number at the beginning is the minimum required number of signatures. Since it's a 2/3 scheme - it's 2.

To reiterate, for a 5/8 scheme which means there are 8 people who can sign and 5 people must sign to authorise a transaction out of the Multi signature wallet. In this circumstance, the command each person would run has a <threshold> that equals 5 and 7 strings of multisig...arg.

The output from the make_multisig command will be similar to:

Another step is needed  
MultisigxV1PKCwmVrucV8bXi18VnHFqRXcnAq4osFL3ahzPHCiN48zhs28u6jmEhy7ktZbUEGfRtTuFjjKzJYb61fnFwnysBBnNXsUtCgFMXPa7FyNKVy2AnUg3ePEnKqWkgKVvA81axTS8r9EX1DmVPXgFKkFzw4Yj4ZtMcJVo77b5ayuMzjFtsaijko9X2bjd9AVfFVGBFMCSLa4xXhNVNz19CTUJx5gpoPG  
Send this multisig info to all other participants, then use finalize_multisig <info1> [<info2>...] with others' multisig info

With any M of N schemes there's an additional step to be done here. The new Multisig...arg info that was just outputted must be passed to ALL other participants (For person 1 they must send it to persons 2 & 3 ... all the way up to person N).

Persons N sends the new output to all other persons.

Step 3 - Finalize Multisig

Here we do one last command to make the wallet ready for receiving. It requires the 2nd batch of Multisig…....arg strings received from other parties.

Person N will run the command:

finalize_multisig MultisigxV1Vg1tsRLurvAc5aSA9Hd9God3MQhijCFoE1rPDFzx7ufwhs28u6jmEhy7ktZbUEGfRtTuFjjKzJYb61fnFwnysBBnfYm4xJWcJ4qM4khSb2KkyAKDuT39pTvdmemhojNjeYCmgSQ1NZLyBj48R1tVpiGNxa7TDnGbSgLuKBq35AX6jfu5PECAcDDn22CFQbJZip7xnBbn89Szzh27xeozfxcLiqqm MultisigxV14xDZBGACz3iUh2aVKGE5q5VzcvJdg2qCvZECgUWCdy5QNXsUtCgFMXPa7FyNKVy2AnUg3ePEnKqWkgKVvA81axTSfYm4xJWcJ4qM4khSb2KkyAKDuT39pTvdmemhojNjeYCmCNaRSsDEcemLLL8wCvzsy5R6hhkhWLYkD9vhZwprSFFKMZ7tfRko2VfMBoKQhB7PKXbf1npk2xceVKu2y7kExywb

Unfortunately the wallet will not display an output at this point. There's no indication that the process was successfully completed (for now). All N persons do the same, and all N wallets will show the same address after this step.

Now each person run the command:

address

And each N people of the multisig wallet should be shown the same address in their wallet.

Receiving

Step 1 Fund The Multisig Account

This is simple, just send to the shared address. You can send multiple times, just like a normal wallet. You can use payment ID’s as well, or generate an integrated address to receive funds.

Best part, whomever is sending the funds won't be able to tell that the address belongs to a multisig wallet since it looks like any other Beldex address.

Step 2 Check Multisig Account Balance

Just open the wallet and run the refresh command. Once completed, all persons can verify that the funds arrived.

Person 1, 2, 3 up to N can run the command:

show_transfers

To see incoming transfers or the following command to see the balance of the wallet:

balance

Preparation for Spending

Step 1 - Export Multisig

Without this step, it will not be possible to create a transaction that spends Beldex. As a minimum, the sender needs to get a partial key image from all the people who will sign the transaction with them later. They could get it from the parties immediately and then later decide with whom to sign.

Person N commands:

export_multisig_info miN

Where miN can be any filename. The output will be:

Multisig info exported to miN

The file miN will be located in the shell working folder*

Person N sends that file to other people. Persons 2 & 3 up to N do the same.

Optional: Step 1.2 Sending Multisig Info File with terminal - transfer.sh

It is optional to use the terminal to send each person the multisig info files.

UPLOADING MULTISIG INFO FILE

Person 1 will open up a new terminal and change to the directory mi1 has been saved.*

Person 1 will run the following command:

curl --upload-file ./mi1 https://transfer.sh/mi1

Person 1 will receive the link to the file as an output, looking similar to:

https://transfer.sh/Ehl5q/mi1

Person 1 will need to send this link to Person 2, Person 3, .... Person N. Person 2 will need to do the same and send the link to Person 1, 3 ..... N. Person 3 will need to do the same and send the link to Person 1, 2 ..... N. Person N will need to do the same and send the link to Person 1, 2, 3, 4, 5 ...... N-1.

DOWNLOADING MULTISIG INFO FILE

Person 1 should change to the directory of their beldex-wallet-cli and use Person 2, 3, 4 ... N’s download link to run the commands:

curl <link> -o <filename>

Replacing <link> with the link Person 2, 3 ... N shared with Person 1 and <filename> with the filename of the Multisig info file that Person 2, 3 or ... N generated, for example Person 1 will run the command:

curl https://transfer.sh/Iedv9/mi2 -o mi2

And the command:

curl https://transfer.sh/dfvr3/mi3 -o mi3

and all the way up to:

curl https://transfer.sh/dfvr3/mi3 -o miN

Likewise, Person 2, 3 .... and N should do the same, changing directories to their beldex-wallet-cli and downloading with the alternative Persons download link, and filename.

curl https://transfer.sh/Ehl5q/mi1 -o mi1

Step 2 - Import Multisig

Now, they must all import each other's file so they can be ready to make a TX later.

For example, Person 2 commands:

import_multisig_info mi1

import_multisig_info mi3

import_multisig_info miN

The wallet will look for files in the shell working folder* and if the files are found the output will look like:

2 outputs found in mi1  
Height 56156, transaction <88ba687dc79a0b39e6de6d0763eda8363d33d9f58ec9a096171bd9a7f1dae873>, received 0.100000000000  
Height 56156, transaction <d6ac845b9400759525519cdc5d514eb8f5b1d265b24d1c016e75b20ed3b4b7da>, received 0.100000000000

Persons 1, 3 .... and N do the same.

Spending

Step 1 - Transfer (Preparing Unsigned Transaction)

Any of the multisig wallets can start a transaction, it doesn't matter. To avoid weird things from happening only do it for 1 transaction at a time. If anything weird happens, do the step 1 & 2 again to fix.

For example, let's say that Person 3 will make the TX.

Person 3 performs the usual transfer command:

transfer bxTmZX8EzZVjS9zNg7zAsrEQFDgcVC2qV2ZMyoWsbyK4SNB2SwMHZtMhPSsFyTmRBQUaGVF5k3qy5CMFM6Lvj7gi3AeszDag7 50

The output will look like:

Unsigned transaction(s) successfully written to file: multisig_beldex_tx

Check in the folder where you started beldex-wallet-cli from. There should be a file named multisig_beldex_tx.

Send the file multisig_beldex_tx to one of the people who will sign the TX.

Person 3 will send the file multisig_beldex_tx to the Person 1, 2 or N. Person 3 can send this file through email or alternatively use the transfer.sh commands outside of the wallet:

curl --upload-file ./multisig_beldex_tx https://transfer.sh/multisig_beldex_tx

If Person 3 chooses to use transfer.sh command to send the file to Person 1 or 2 they will receive a <link>.

Person 1 or 2 must finish the signature. Person 1 or 2 copies/downloads the file to the same folder from where he started (or will start) beldex-wallet-cli.

Person 1 or 2 can run the command to download the file to the beldex-wallet-cli directory.

curl https://transfer.sh/CJqnM/multisig_beldex_tx -o multisig_beldex_tx

Replacing https://transfer.sh/CJqnM/multisig_beldex_tx with the link provided by Person 3.

Step 2 - Sign Multisig

Let's say Person 2 was picked as the partner. They must finish the signature. Person 2 copies the file to the same folder from where he started (or will start) beldex-wallet-cli.

Then, Person 2 commands:

sign_multisig multisig_beldex_tx

and they will be prompted to check it first:

Loaded 1 transactions, for 108.082287779, fee 0.061108880, sending 50.000000000 to bxTmZX8EzZVjS9zNg7zAsrEQFDgcVC2qV2ZMyoWsbyK4SNB2SwMHZtMhPSsFyTmRBQUaGVF5k3qy5CMFM6Lvj7gi3AeszDag7, 58.021178899 change to bxScXhWpAG2aUHmFemwvn4HddHA5GQ4u6MvYsW2hVteJSwLJXCEhk2aVp4XzyqGmvyUqc3w8fwWwg6szGEytUSx51C6WQ3er8, with min ring size 10, no payment ID.

Is this okay? (Y/Yes/N/No):

If ok, answer Y, and the output will look like:

Transaction successfully submitted, transaction <3b03b16c79eaa5564171ae88242c4cdb1f9e0b41fc3de949c6524c5026a3f3bb>

If the threshold is greater than 2 another multisig_beldex_tx file will need to be signed by the amount of signers required.

Step 3 - Submit Multisig

Finally, person with the final signed file submits the transaction to the network by commanding:

submit_multisig multisig_beldex_tx

There will be a confirmation prompt:

Loaded 1 transactions, for 108.082287779, fee 0.061108880, sending 50.000000000 to bxTmZX8EzZVjS9zNg7zAsrEQFDgcVC2qV2ZMyoWsbyK4SNB2SwMHZtMhPSsFyTmRBQUaGVF5k3qy5CMFM6Lvj7gi3AeszDag7, 58.021178899 change to bxScXhWpAG2aUHmFemwvn4HddHA5GQ4u6MvYsW2hVteJSwLJXCEhk2aVp4XzyqGmvyUqc3w8fwWwg6szGEytUSx51C6WQ3er8, with min ring size 10, no payment ID.

Is this okay? (Y/Yes/N/No):

If ok, answer Y, and the transaction will be sent. The output will look like:

Transaction successfully submitted, transaction <3b03b16c79eaa5564171ae88242c4cdb1f9e0b41fc3de949c6524c5026a3f3bb>  

You can check its status by using the show_transfers command.

The person 2 could also send the signed TX to person 3, who could then submit it to the network himself.

If you want to make another one, you have to go back to preparation for spending step (sync the key images again).

The wallet will look for the files and export them to the folder from where it was started, ie where your command prompt / shell was when you called beldex-wallet-cli. It may or may not be the same folder as your actual wallet files or beldex-wallet-cli, depending on how you go about it.

For example, your wallet could be on some USB drive like f:\temp\, and your wallet software on c:\beldex\ and your shell working folder could be c:\.

If you remain in c:\ with the shell, you could start the wallet by its full path and specify the wallet file location: c:\beldex\beldex-wallet-cli.exe --wallet-file f:\temp\mywallet. In this case, all the import/export stuff would be read/written to c:\because that's still your shell's working folder.

It would be probably feel more natural to cd into the wallet folder. Do f: to change drive and then cd f:\temp\. Then, simply start the wallet from that location by its full path again: c:\beldex\beldex-wallet-cli.exe --wallet-file mywallet. Notice how you don't have to write the full wallet path now as you're already there with your shell. In this case, all the files mentioned above would be written or read from the same folder as the wallet files.

Source:

Monero Stack Exchange: how to use monero multisigniture wallets

First, the wallet to be converted to multisig must be empty. It is best to use a brand-new wallet for the purpose, although not required. It is strongly advised to make a copy of the wallet files first, just in case something goes wrong.

Overview

In short, the process is:

Set-up

1. Both parties prepare beldex-wallet-cli files

2. Both parties command prepare_multisig and send data to each other

3. Both parties command make_multisig

Receiving

1. All parties can type address to see the created multisig wallet address. The address will, of course, be the same for all parties since they're all watching the same wallet.

Preparation for Sending

1. To prepare for sending both parties command export_multisig_info <filename> and send the file to the other party

2. To complete preparation, all parties command import_multisig_info <filename1> <filename2> and import files from other parties

Sending

1. To send, any party can use the usual transfer command, but the result will be a file named multisig_beldex_tx which must be sent to any 1 other signer

2. The other party commands sign_multisig multisig_beldex_tx and the file is updated with the signature.

3. The completely signed file is pushed to the network with use of submit_multisig multisig_beldex_tx

Below is a step-by-step walkthrough.

Set-up

Step 1 Initiate Creation of Multisig Wallet and Exchange Data

Requirements:

• 2 empty beldex-wallet-cli wallets

• Both wallets connected to beldexd

• Confidential communication channel

Person A must run the command in their beldex-wallet-cli:

Person A will receive the output:

Copy the entire line Multisig...5ozpN and be sure to capture the whole thing when copying.

Send this line to person B through a confidential communication channel.

Person B does the same and sends his output to person A.

Person B must run the command in their beldex-wallet-cli:

Person B will receive the output:

Person B will copy the Multisig…...eJi4FS and send it to person A through a confidential communication channel.

Step 2 Create Multisig Wallets

Both person A and person B now have the Multisig...arg text from the other one. With that, each of them can create their part of the multisig wallet. Before you proceed, note that the wallet will lose access to the underlying account when converted to multisig. This is not really a problem, since we started with an empty one, and if all goes ok with this step, you won't ever need it unless you want to go through the process again for whatever reason (like HDD died, but you have the seed mnemonic of the underlying account and want to reconstruct the multisig wallet).

Person A will use the output Person B sent and will run the command:

The wallet will output something similar to:

Person B will use the output Person A sent and run the command:

The wallet will output something similar to:

Now each person involved should exchange addresses and compare, they must be the same.

Receiving

Step 1 Fund The Multisig Account

This is simple. Just send to the shared address. You can send multiple times, this is the same as a normal wallet. You can use payment ID’s as well, or generate an integrated address to receive funds.

Best part, whomever is sending the funds won't be able to tell that the address belongs to a multisig wallet since it looks like any other.

Step 2 Check Multisig Account Balance

Just open the wallet and command refresh. Once completed, both persons can verify that the funds arrived.

Person A commands:

Person A outputs:

Person B can do the same:

Person B has the same outputs:

Spending

Step 1 Synchronizing Key Images

1.1 Exporting Multisig Info

Without this step, it will not be possible to create a spending transaction.

Both persons need to run the following command to sync their key images:

Where <filename> can be any filename.

Person A will run the command:

Person A will receive the output:

The file mi1 will be located in the shell working folder*

Person A sends that file to Person B. They can send the file in many ways, preferably through by handing a usb drive with the file on it, however If you would like to send the file through terminal use , an optional step has been added if you choose to use this method.

Person B does the same, but changing the filename and runs the command:

Person B will receive the output:

The file mi2 will be located in the shell working folder*

Person B sends that file to person A.

Now, they must both import each other's file.

Optional: Step 1.2 Sending Multisig Info File with terminal - transfer.sh

It is optional to use the terminal to send each person the multisig info files.

UPLOADING MULTISIG INFO FILE

Person A will open up a new terminal and change to the directory “mi1” has been saved.*

Person A will run the following command:

Person A will receive the link to the file as an output, looking similar to:

Person A will need to send this link to Person B.

Person B will run a similar command:

Person B will receive the link to the file as an output, looking similar to:

Person B will need to send this link to Person A.

Downloading Multisig Info file

Person A should change to the directory of their beldex-wallet-cli and use Person B’s download link to run the command:

Replacing <Person B link> with the link Person B shared with Person A and <filename>with the filename of the Multisig info file that Person A generated, for example Person A will run the command:

Likewise, Person B should do the same, changing directories to their beldex-wallet-cli and downloading with Person A’s download link, and filename.

Step 1.3 Importing Multisig Info

Person A will run the command:

Depending on the transactions made in to the multsig wallet the output will look similar to:

Person B will run a similar command:

and the output will look like:

Step 2 Preparing Spending Transaction

Either person A or person B can do this, it doesn't matter. To avoid weird things from happening only do it for 1 transaction at a time.

Person A performs the usual transfer command:

The output will look like:

Check in the folder where you started beldex-wallet-cli from. There should be a file named multisig_beldex_tx.

Person A will send the file multisig_beldex_tx to the Person B. Person A can send this file through email or alternatively use the transfer.sh commands outside of the wallet:

If Person A chooses to use transfer.sh command to send the file to Person B they will receive a <link> to pass to Person B.

Person B must finish the signature. Person B copies/downloads the file to the same folder from where he started (or will start) beldex-wallet-cli.

Person B can run the command to download the file to the beldex-wallet-cli directory.

Replacing https://transfer.sh/CJqnM/multisig_beldex_tx with the link provided by Person A.

Then, Person B runs the command:

A prompt will be displayed to allow person B to check the transaction before signing:

If ok, answer Y, and the output will look like:

Finally, person B submits the transaction to the network by commanding:

There will be a confirmation prompt:

If ok, answer Y, and the transaction will be sent. The output will look like:

The person B could also send the signed TX to person A, who could then submit it to the network himself.

If you want to make another one, you have to go back to step 1 of spending (sync the key images again).

Note on folders and file locations, as it could create some confusions. The wallet will look for the files and export them to the folder from where it was started, ie where your command prompt / shell was when you called beldex-wallet-cli. It may or may not be the same folder as your actual wallet files or beldex-wallet-cli, depending on how you go about it.

For example, your wallet could be on some USB drive like f:\temp\, and your wallet software on c:\beldex-windows-x64\ and your shell working folder could be c:\.

If you remain in c:\ with the shell, you could start the wallet by its full path and specify the wallet file location: c:\beldex-windows-x64\beldex-wallet-cli.exe --wallet-file f:\temp\mywallet. In this case, all the import/export stuff would be read/written to c:\because that's still your shell's working folder.

It would be probably feel more natural to cd into the wallet folder. Do f: to change drive and then cd f:\temp\. Then, simply start the wallet from that location by its full path again: c:\beldex-windows-x64\beldex-wallet-cli.exe --wallet-file mywallet. Notice how you don't have to write the full wallet path now as you're already there with your shell. In this case, all the files mentioned above would be written or read from the same folder as the wallet files.

Source:

Hardfork Version 10: Bulletproofs

get_block_template Updates

Due to batching of Governance rewards the calculation of rewards has been updated in Beldex. As a side effect of this, in the get_block_template json response, expected_reward now returns only the miner reward instead of the entire block reward.

For example, pre-hardfork 9, if the block reward was 100, expected_reward returned 100, even though ~50% of the reward was sent to the master node. Post Bulletproofs hardfork, expected_reward now returns 50, which is the exact amount the miner would receive.

A real example of this is on the testnet, for block 63056.

Calling get_block_template on block 63056

Calling get_block on block 63056

Of importance, from get_block_template

And get_block

The expected_reward is the same amount as the 1st vout amount in get_block which is the miner output (the 2nd being the Master Node Output). In summary, the expected_rewardreturned by get_block_template is exactly the reward the miner will receive.

Extracting Reward Amounts from Block Outputs

In the Bulletproofs hardfork, batching of Governance rewards was introduced and removes the governance output from most miner transactions. This means, for most blocks the outputs will only include the Miner reward and the Master Node reward.

The Governance reward is paid out every GOVERNANCE_REWARD_INTERVAL number of blocks, in code this is checked as (block_height % GOVERNANCE_REWARD_INTERVAL == 0).

An example miner transaction JSON output with the Governance reward

An example miner transaction JSON output without the Governance reward

Hardfork Version 9: Master Nodes

Extracting Reward Amounts from Block Outputs

This hardfork introduces Master Node rewards to the outputs of the miner transaction. Master Nodes can split the given reward with up to 4 participants. Then, at most the miner transaction can have a maximum of 6 outputs, 1 reserved for the miner, 1 for governance, up to 4 for master node participants.

An example miner transaction JSON output with 4 master node participants looks like

Subaddress is what you should be using by default to receive Beldex.

Learn for what you are being paid

By providing a unique subaddress for each anticipated payment you will know for what you are being paid.

This use case overlaps with integrated addresses. Subaddresses are generally prefered for reasons outlined below.

Prevent payer from linking your payouts together

To prevent the payer from linking your payouts together simply generate a new subaddress for each payout. This way services like Shapeshift wouldn't know it is you again receving Beldex.

Note it won't help if you have an account with the service. Then your payouts are already linked in the service database, regardless of Beldex.

Group funds into accounts

!!! Note Feel free to skip this if your are new to Beldex. Accounts are not essential and currently not supported by the GUI.

Accounts are a convenience wallet-level feature to group subaddresses under one label and balance.

You may want to organize your funds into accounts like "cash", "work", "trading", "mining", "donations", etc.

As accounts are only groupings of subaddresses, they themselves do not have an address.

Accounts are deterministically derived from the root private key along with subaddresses.

As of September 2018 accounts are only supported by the CLI wallet and missing from GUI wallet.

Accounts are similar to subaccounts in your classic bank account. There is a very important difference though. In Beldex funds don't really sit on accounts or public addresses. Public addresses are conceptually a gateway or a routing mechanism. Funds sit on transactions' unspent outputs. Thus, a single transaction can - in principle - aggregate and spend outputs from multiple addresses (and by extension from multiple accounts). The CLI or GUI wallet may not directly support creating such transactions for simplicity.

In short, think of accounts as a soft grouping of your funds.

Why not multiple wallets?

The advantage over creating multiple wallets is that you only have a single seed to manage. All subaddresses can be derived from the wallet seed.

Additionally, you conveniently manage your subaddresses within a single user interface.

Wallet level feature

Subaddresses and accounts are a wallet-level feature to construct and interpret transactions. They do not affect the consensus.

Data structure

Subaddress has a dedicated "network byte":

Otherwise the data structure is the same as for the main address.

Generating

Each subaddress conceptually has:

• account index (also known as "major" index)

• subaddress index within the account (also known as "minor" index)

The indexes are 0-based. By default wallets use account index 0.

The indexes are not directly included in the subaddress data structure. Instead, they are used as input to generating subaddress keys.

Private view key

The subaddress private view key m is derived as follows:

m = Hs("SubAddr" || a || account_index || subaddress_index_within_account)

Where:

• Hs is a Keccak-256 hash function interpreted as integer and modulo l (maximum edwards25519 scalar)

• || is a byte array concatenation operator

• SubAddr is a 0-terminated fixed string (8 bytes total)

• a is a private view key of the main address (a 32 byte little endian unsigned integer)

• account_index is index of an account (a 32 bit little endian unsigned integer)

• subaddress_index_within_account is index of the subaddress within the account (a 32 bit little endian unsigned integer)

Deriving "sub view keys" from the main view key allows for creating a view only wallet that monitors the entire wallet including subaddresses.

Public spend key

The subaddress public spend key D is derived as follows:

D = B + m*G

Where:

• B is main address public spend key

• m is subaddress private view key

• G is the "base point"; this is simply a constant specific to edwards25519

Public view key

The subaddress public view key C is derived as follows:

C = a*D

Where:

• a is a private view key of the main address

• D is a public spend key of the subaddress

Special case for (0, 0)

The subaddress #0 on the account #0 is the main address. As main address has different generation rules, this is simply implemented via an if statement.

Building the address string

The procedure is the same as for the main address.

Caveats

• It is not recommended to sweep all the balances of subaddress to main address in a single transaction. That links the subaddresses together on the blockchain. However, this only concerns privacy against specific sender and the situation will never get worse than not using subaddresses in the first place. If you need to join funds while preserving maximum privacy do it with individual transactions (one per subaddress).

• Convenience labels are not preserved when recreating from seed.

Reference

• monero-python - the easiest to follow implementation by Michał Sałaban

• get_subaddress_spend_public_key() - Monero reference implementation

• historical discussion on Github - gives context but is not up to date with all details

• StackExchange answer - excellent summary by knaccc

Displaying commands

The beldex-wallet-cli has multiple commands to conduct different operations on the Beldex Blockchain. By typing help and clicking enter after loading your wallet will bring up the commands that can be used.

1.0 Accounts

1.1 Creating new account

When a wallet is generated it will automatically have an account labelled Primary accountwith index 0. If at any time you wish to create an additional account use the command:

account new <label text with white spaces allowed>

This command will create a subaddress which is labelled with a tag and index number. This subaddress will share the same seed as your Primary address. To ensure this new account is displayed you must type exit to save your session.

You will note that there is now an asterisk to the left of index 1. The asterisks show us the account in which the commands we run will apply to.

Note: Restoring your wallet from your seed will not restore your accounts as the index of your subaddress data is stored on your computer within your wallet file. All the funds stored in your additional accounts will be shown in your Primary account if you need to restore your wallet from scratch.

[wallet bxcnR2]: account new Secondary account
[wallet bxcnR2]: Untagged accounts:
[wallet bxcnR2]: Account Balance Unlocked balance Label
[wallet bxcnR2]: 0 bxcnR2 0.000000000 0.000000000 Primary account
[wallet bxcnR2]: * 1 8Y5J5W 0.000000000 0.000000000 Secondary account
[wallet bxcnR2]: ----------------------------------------------------------------------------------
[wallet bxcnR2]: Total 0.000000000 0.000000000

1.2 Switching account

When transferring out or receiving to a specific account we need to make sure that the account we are performing the action is the one the CLI is currently connected to. An asterisk will show which account we are connected to. In the below example the asterisk is shown to the left of Secondary account so any operations will be associated with that account.

Each of the accounts connected to your Primary address will have an index associated with them. The index number will be shown to the left of the Account column. By default, index “0” is your Primary account.

[wallet bxcnR2]: account new Secondary account
[wallet bxcnR2]: Untagged accounts:
[wallet bxcnR2]: Account Balance Unlocked balance Label
[wallet bxcnR2]: 0 bxcnR2 0.000000000 0.000000000 Primary account
[wallet bxcnR2]: * 1 8Y5J5W 0.000000000 0.000000000 Secondary account
[wallet bxcnR2]: ----------------------------------------------------------------------------------
[wallet bxcnR2]: Total 0.000000000 0.000000000

To switch between the accounts you have created run the command:

account switch <index>

After running the command a similar output shown below will be on your terminal.

[wallet bxcnR2]: account switch 0
[wallet bxcnR2]: Currently selected account: [0] Primary account
[wallet bxcnR2]: Tag: (No tag assigned)
[wallet bxcnR2]: Balance: 0.000000000, unlocked balance: 0.000000000

1.3 Changing account labels

To change the label name connected to a specific Beldex Primary or Sub-address use the command:

account label <index> <label text with white spaces allowed>

Replacing <index> with the index number associated with the account you wish to relabel, and replacing <label text with white spaces allowed> with the new label you would like to name the specified account.

Below shows the current accounts and labels for a specific wallet.

[wallet bxmjSH]: Untagged accounts:
[wallet bxmjSH]: Account Balance Unlocked balance Label
[wallet bxmjSH]: * 0 bxmjSH 0.000000000 0.000000000 Primary account
[wallet bxmjSH]: 1 8TLgNy 0.000000000 0.000000000 Secondary
[wallet bxmjSH]: ----------------------------------------------------------------------------------
[wallet bxmjSH]: Total 0.000000000 0.000000000

Using the command account label 0 My Account we have changed the label connected to our Primary address from “Primary account” to “My Account”.

[wallet bxmjSH]: account label 0 My Account
[wallet bxmjSH]: Untagged accounts:
[wallet bxmjSH]: Account Balance Unlocked balance Label
[wallet bxmjSH]: * 0 bxmjSH 0.000000000 0.000000000 My Account
[wallet bxmjSH]: 1 8TLgNy 0.000000000 0.000000000 Secondary
[wallet bxmjSH]: ----------------------------------------------------------------------------------
[wallet bxmjSH]: Total 0.000000000 0.000000000

1.4 Tagging and untagging accounts:

The beldex-wallet-cli allows you to group accounts by tagging or untagging them.

Below shows a wallet with 4 accounts, Dog, Kid 1 and Kid 2.

[wallet 8VP3bv]: Untagged accounts:
[wallet 8VP3bv]: Account Balance Unlocked balance Label
[wallet 8VP3bv]: 0 bxXk6e 0.000000000 0.000000000 My Account
[wallet 8VP3bv]: 1 8RDvY6 0.000000000 0.000000000 Dog
[wallet 8VP3bv]: 2 8VJDwN 0.000000000 0.000000000 Kid 1
[wallet 8VP3bv]: * 3 8VP3bv 0.000000000 0.000000000 Kid 2
[wallet 8VP3bv]: ----------------------------------------------------------------------------------
[wallet 8VP3bv]: Total 0.000000000 0.000000000

We can tag a single account with the following command:

account tag <tag_name> <account_index>

[wallet 8VP3bv]: account tag Pets 1
[wallet 8VP3bv]: Accounts with tag: Pets
[wallet 8VP3bv]: Tag's description:
[wallet 8VP3bv]: Account Balance Unlocked balance Label
[wallet 8VP3bv]: 1 8RDvY6 0.000000000 0.000000000 Dog
[wallet 8VP3bv]: ----------------------------------------------------------------------------------
[wallet 8VP3bv]: Total 0.000000000 0.000000000

When needing to perform multiple tags we can do it through one command:

account tag <tag_name> <account_index_1> [<account_index_2> ...]

[wallet 8VP3bv]: account tag Family 2 3
[wallet 8VP3bv]: Accounts with tag: Family
[wallet 8VP3bv]: Tag's description:
[wallet 8VP3bv]: Account Balance Unlocked balance Label
[wallet 8VP3bv]: 2 8VJDwN 0.000000000 0.000000000 Kid 1
[wallet 8VP3bv]: * 3 8VP3bv 0.000000000 0.000000000 Kid 2
[wallet 8VP3bv]: ----------------------------------------------------------------------------------
[wallet 8VP3bv]: Total 0.000000000 0.000000000

Similarly we can untag accounts by running the following command:

account untag <account_index_1> [<account_index_2> ...]

Using the above exampled wallet we will remove our “Dog” account from “Pets”.

[wallet 8VP3bv]: account untag 1
[wallet 8VP3bv]: Accounts with tag: Family
[wallet 8VP3bv]: Tag's description:
[wallet 8VP3bv]: Account Balance Unlocked balance Label
[wallet 8VP3bv]: 2 8VJDwN 0.000000000 0.000000000 Kid 1
[wallet 8VP3bv]: * 3 8VP3bv 0.000000000 0.000000000 Kid 2
[wallet 8VP3bv]: ----------------------------------------------------------------------------------
[wallet 8VP3bv]: Total 0.000000000 0.000000000
[wallet 8VP3bv]:
[wallet 8VP3bv]: Untagged accounts:
[wallet 8VP3bv]: Account Balance Unlocked balance Label
[wallet 8VP3bv]: 0 bxXk6e 0.000000000 0.000000000 My Account
[wallet 8VP3bv]: 1 8RDvY6 0.000000000 0.000000000 Dog
[wallet 8VP3bv]: ----------------------------------------------------------------------------------
[wallet 8VP3bv]: Total 0.000000000 0.000000000

1.5 Adding Tag descriptions

If you require additional information attached to a specific tag you can add a description with the following command:

account tag_description <tag_name> <description>

For example:

[wallet 8VP3bv]: account tag_description Family This is my family.
[wallet 8VP3bv]: Accounts with tag: Family
[wallet 8VP3bv]: Tag's description: This is my family.
[wallet 8VP3bv]: Account Balance Unlocked balance Label
[wallet 8VP3bv]: 2 8VJDwN 0.000000000 0.000000000 Kid 1
[wallet 8VP3bv]: * 3 8VP3bv 0.000000000 0.000000000 Kid 2
[wallet 8VP3bv]: ----------------------------------------------------------------------------------
[wallet 8VP3bv]: Total 0.000000000 0.000000000

2.0 Balance

To check the balance of your wallet you can run one of two commands:

balance or balance detail

Running the command balance will generated a simple output showing your balance and unlocked balance of the specific account you are in. For example:

[wallet 86TmZX]: balance
Currently selected account: [0] Primary account
Tag: (No tag assigned)
Balance: 172286.035054991, unlocked balance: 172086.338373771

While running the command balance detail will generate a more detailed output, showing the account number, first few characters of the address, balance, unlocked balance, Outputs and the Label of the account. For example:

[wallet 86TmZX]: balance detail
Currently selected account: [0] Primary account
Tag: (No tag assigned)
Balance: 172286.035054991, unlocked balance: 172086.338373771
Balance per address:
Address Balance Unlocked balance Outputs Label
0 86TmZX 172286.035054991 172086.338373771  3347 Primary account

There are other commands that will also output the balance which have been covered by this guide, such as the account command.

3.0 Getting the Block Height

To show the blockchain height run the command:

bc_height

4.0 Blackballing Transactions

Blackballing transactions allows you to ignore others' outputs (containers of money) that are known to be spent in a certain transaction.

For example let’s imagine that txid: 4f4b371a0da8858bbeab8a40ff37de1f6ff33e64a616e5ced8239062570b7542 is known to be fake and if this txid is seen within a RingCT transaction the network can assume it is fake, therefore an actor has a better chance of deducing the real transaction within the RingCT.

By blackballing the above txid we remove the chance of it being used within our RingCT.

To do this we will use the following command:

blackball <output public key> | <filename> [add]

For example:

[wallet bxXk6e]: blackball 4f4b371a0da8858bbeab8a40ff37de1f6ff33e64a616e5ced8239062570b7542

To check if the txid was added to our list of txids not to use we can use the following command:

blackballed <output public key>

If the txid is on our list the following will output:

[wallet bxXk6e]: blackballed 4f4b371a0da8858bbeab8a40ff37de1f6ff33e64a616e5ced8239062570b7542
[wallet bxXk6e]: Blackballed: <4f4b371a0da8858bbeab8a40ff37de1f6ff33e64a616e5ced8239062570b7542>

Alternatively if the txid is not on our list the following will output:

[wallet bxXk6e]: blackballed 4f4b371a0da8858bbeab8a40ff37de1f6ff33e64a616e5ced8239062570b7542
[wallet bxXk6e]: not blackballed: <4f4b371a0da8858bbeab8a40ff37de1f6ff33e64a616e5ced8239062570b7542>

To unblackball a txid use the following command:

unblackball <output public key>

For example:

[wallet bxXk6e]: unblackball 4f4b371a0da8858bbeab8a40ff37de1f6ff33e64a616e5ced8239062570b7542

5.0 Reserve Proof

Reserve Proofs are used to generate a signature proving that you own an amount of Beldex, with the option to sign the reserve proof with a key.

For example let’s imagine you see a car for sale but they will accept Beldex as payment, however they have advised in their online listing that they are only interested in serious buyers and require you to prove you have the Beldex within your initial contact. Luckily we can use the Reserve Proof commands for this proof.

5.1 Generate Reserve Proof

To begin we will need to run the get_reserve_proof command to generate our proof.

get_reserve_proof (all|<amount>) [<message>]

If the individual you are sending this proof to requires you to prove you have 1000 Beldex you will need to replace the section (all|<amount>) with a 1000, otherwise replace it with the amount you need to prove you have reserved. If you want to put an extra layer of encryption over the file replace [<message>] with a password.

Your command will similar to the below command:

get_reserve_proof 1000 Car

The Cli will request your wallet password and once your password is entered it will tell you it generated a signature file.

[wallet 86TmZX]: get_reserve_proof 1000 Car
Wallet password:
signature file saved to: beldex_reserve_proof

This signature file beldex_reserve_proof will be saved in your Beldex folder, where your daemon and wallet keys are. Keep in mind every time you run the get_reserve_proofcommand it will overwrite your beldex_reserve_proof file.

You will want to send this file to the person who requires the proof. You can upload the beldex_reserve_proof file through https://transfer.sh/ by running the command within the folder of your signature file:

curl --upload-file ./beldex_reserve_proof https://transfer.sh/beldex_reserve_proof`

The terminal will then print out a link to your signature file which you can then provide to the individual performing the check.

https://transfer.sh/QhoC7/beldex_reserve_proof

Make sure you provide the following to the individual who will be checking your reserve proof:

• The beldex_reserve_proof file through the transfer.sh link.

• The beldex address you are proving has Beldex in it.

• The <message> if you encrypted the file.

5.2 Checking Reserve Proof

To check a reserve proof we need to first have the beldex_reserve_proof file in our Beldex folder.

If you do not have the beldex_reserve_proof file in your beldex folder request the individual sending the file to you to use https://transfer.sh/, once they send you the link to their beldex_reserve_proof you can use the following command to download it.

curl <link> -o beldex_reserve_proof

Replacing <link> with the link to download the beldex_reserve_proof.

Now that the beldex_reserve_proof is in our folder we can run the following command:

check_reserve_proof <address> <signature_file> [<message>]

Where <address> is the address of the wallet where the command get_reserve_proof was ran. <signiture_file> is the file that was received from the individual sending you the reserve proof, normally generated as beldex_reserve_proof and <message> is the key set by the individual who sent you the reserve proof.

Therefor for the previous example where we created a reserve proof for 1000 beldex and signed with “car”, we would run the command:

check_reserve_proof bxTmZX8EzZVjS9zNg7zAsrEQFDgcVC2qV2ZMyoWsbyK4SNB2SwMHZtMhPSsFyTmRBQUaGVF5k3qy5CMFM6Lvj7gi3AeszDag7 beldex_reserve_proof Car

If all goes well, the terminal will output the following:

Good signature -- total: 1014.862440831, spent: 0.000000000, unspent: 1014.862440831

You may note that it shows a reserve proof which is greater than 1000, this is because the command is adding up all the transactions into the address specified until it is greater than the reserve proof set.

6.0 Spend Proof

Spend Proofs are used to generate a signature proving that you generated a TXID, with the option to sign the spend proof with a key.

For example let’s imagine you have bought a car from a dealership with beldex and have sent 1000 BDX to the seller. Unfortunately the dealer does not know which transaction is yours as he has received 5 transactions of 1000 BDX in the same block for 5 different cars. He knows the txid’s but wants you to prove that you have generate one of the txid’s in his list. Luckily we can prove we generated the txid by using the get_spend_proof command.

6.1 Generate Spend Proof

To begin we will first need to find the txid associated with our transaction. To do this run the following command in our wallet:

show_transfers

The terminal will output a list of transactions in and out of your address. You should have a transaction in your list with the amount you spent to the dealership. Copy the txid(by highlighting) associated with this transaction and save it in a notepad for later.

We can now run the get_spend_proof command to generate our proof.

get_spend_proof <txid> [<message>]

Replacing <txid> with the txid of our transfer out and replacing <message> if we want to add a password to the proof. If all went well the terminal will output the following text:

signature file saved to: beldex_spend_proof

This signature file beldex_spend_proof will be saved in your Beldex folder, where your daemon and wallet keys are. Keep in mind every time you run the get_spend_proof command it will overwrite your beldex_spend_proof file.

You will want to send this file to the person who requires the proof. You can upload the beldex_spend_proof file through https://transfer.sh/ by running the command within the folder of your signature file:

curl --upload-file ./beldex_spend_proof https://transfer.sh/beldex_spend_proof

The terminal will then print out a link to your signature file which you can then provide to the individual performing the check. For example:

https://transfer.sh/QhoC7/beldex_spend_proof

Make sure you provide the following to the individual who will be checking your reserve proof:

• The beldex_spend_proof file through the transfer.sh link.

• The beldex transaction txid associated with the transaction you are proving you generated.

• The <message> if you encrypted the file.

6.2 Checking Spend Proof

To check a spend proof we need to first have the beldex_spend_proof file in our Beldex folder and the txid associated with the transaction being proved.

If you do not have the beldex_spend_proof file in your beldex folder request the individual sending the file to you to use https://transfer.sh/, once they send you the link to their beldex_spend_proof you can use the following command to download it.

curl <link> -o beldex_spend_proof

Replacing <link> with the link to download the beldex_spend_proof.

Now that the beldex_spend_proof is in our folder we can run the following command:

check_spend_proof <txid> <signature_file> [<message>]

Where <txid> is the txid associated with the transaction that is being proved. <signiture_file> is the file that was received from the individual sending you the spend proof, normally generated as beldex_spend_proof and <message> is the key set by the individual who sent you the spend proof.

An example would look like the following command

check_spend_proof 20eb3b5545d6587e5a379feb2fc69b43d4f8b6b825bb7eff78e263d4e7e8eaa9 beldex_spend_proof car

If all goes well, the terminal will output the following:

Good signature

If you receive a Good signature message that should be a good proof that the txid you are checking was generated from the sender. Keep in mind however that this can potentially not always be the case, considering someone could get access to someone else's computer thus having access to this file.

7.0 TX Proof

TX Proofs are used to generate a signature file proving that you generated a TXID, with the option to sign the spend proof with a key. TX proofs work similar to Reserve Proof’s and Spend Proofs however they show more detailed information.

For example let’s imagine you have bought a car from a dealership with beldex and have sent 1000 BDX to the seller. Unfortunately the dealer does not know which transaction is yours as he has received 5 transactions of 1000 BDX in the same block for 5 different cars. He knows the txid’s but wants you to prove that you have generate one of the txid’s in his list. Luckily we can prove we generated the txid by using the get_tx_proof command.

7.1 Generate Spend Proof

To begin we will first need to find the txid associated with our transaction. To do this run the following command in our wallet:

show_transfers

The terminal will output a list of transactions in and out of your address. You should have a transaction in your list with the amount you spent to the dealership. Copy the txid(by highlighting) associated with this transaction and save it in a notepad for later.

We can now run the get_tx_proof command to generate our proof.

get_tx_proof <txid> <address> [<message>]

Replacing <txid> with the txid of our transfer out, <address> with the receiver's address, and replacing <message> if we want to add a password to the proof. If all went well the terminal will output the following text:

signature file saved to: beldex_tx_proof

This signature file beldex_tx_proof will be saved in your Beldex folder, where your daemon and wallet keys are. Keep in mind every time you run the get_tx_proof command it will overwrite your beldex_tx_proof file.

You will want to send this file to the person who requires the proof. You can upload the beldex_tx_proof file through https://transfer.sh/ by running the command within the folder of your signature file:

curl --upload-file ./beldex_tx_proof https://transfer.sh/beldex_tx_proof

The terminal will then print out a link to your signature file which you can then provide to the individual performing the check. For example:

https://transfer.sh/QhoC7/beldex_tx_proof

Make sure you provide the following to the individual who will be checking your reserve proof:

• The beldex_tx_proof file through the transfer.sh link.

• The beldex transaction txid associated with the transaction you are proving you generated.

• The receivers beldex address.

• The <message> if you encrypted the file.

7.2 Checking tx Proof

To check a tx proof we need to first have the beldex_tx_proof file in our Beldex folder, the receiver's address and the txid associated with the transaction being proved.

If you do not have the beldex_tx_proof file in your beldex folder request the individual sending the file to you to use https://transfer.sh/, once they send you the link to their beldex_tx_proof you can use the following command to download it.

curl <link> -o beldex_tx_proof

Replacing <link> with the link to download the beldex_tx_proof.

Now that the beldex_tx_proof is in our folder we can run the following command:

check_tx_proof <txid> <address> <signature_file> [<message>]

Where <txid> is the txid associated with the transaction that is being proved, <address> is the receiver’s address and <signiture_file> is the file that was received from the individual sending you the tx proof, normally generated as beldex_tx_proof and <message> is the key set by the individual who sent you the tx proof.

An example would look like the following command:

check_tx_proof 3f8c62b4d83100ff4f89b44a96350e65aeaa83a9b4273c31f94b9aa12e713044 8RrEpWMLd3rRuirYqsjg1iaNsukAAojWjFDhJ2kK2o4uM6tkcjMerA4SZNat6QHEYe1SoGCFQddVPgRqmkA8kARX1ffU1Wcjc beldex_tx_proof

If all goes well, the terminal will output the following:

Good signature
TRrEpWMLd3rRuirYqsjg1iaNsukAAojWjFDhJ2kK2o4uM6tkcjMerA4SZNat6QHEYe1SoGCFQddVPgRqmkA8kARX1ffU1Wcjc received 40000.000000 in txid <3f8c62b4d83100ff4f89b44a96350e65aeaa83a9b4273c31f94b9aa12e713044>
This transaction has 1 confirmations

If you receive a Good signature message that should be a good proof that the txid you are checking was generated from the sender. Keep in mind however that this can potentially not always be the case, considering someone could get access to someone else's computer thus having access to this file.

8.0 TX key

A TX key is a private key associated with a TXid. Only the wallet that has sent the transaction can generate a TX key from the TXID that both parties can see. A TX key can be used to validate a transaction on a case by case basis. In essence, you can provide the tx key, txid and the receiver address to someone to prove you had generate that transaction.

8.1 View TX key

To view the TX key of a specific transaction you have generate you will need to run the command:

get_tx_key <txid>

Where <txid> is the transaction id associated with the transfer out you are proving is yours.

The terminal will prompt the user for the wallets password and then print out the tx key, which will look similar to:

[wallet 86TmZX]: get_tx_key d5fb415aad43f4e45bc72566d5ad4c8f12629db1f924d953efc2521c137a987f
Wallet password:
Tx key: 5dfc4d677e2707317f306219b6aa445feaab4c652927237c012f7e72cb41bf0e

Provide the <tx key> with the <txid> and <receiving address> to the individual who will run the validation, thus this will prove you generated the transaction.

8.2 Validate transaction with TX key

Once we have a <tx key>, <txid> and <receiving address> from a specific transaction we can use the following command to prove they are all associated:

check_tx_key <txid> <txkey> <address>

For the previous example we would run the following command from any beldex wallet:

check_tx_key d5fb415aad43f4e45bc72566d5ad4c8f12629db1f924d953efc2521c137a987f 5dfc4d677e2707317f306219b6aa445feaab4c652927237c012f7e72cb41bf0e 86TZ2VaG1p9PQkDgdVCYwnjoxYSU7ErXX56etGsqHLugAGqynFwBvP4dnN7wvYCcJfMa9LPgtYu8UEUqyc4xsxmx2ZTyMp4U3

The terminal will show text of how much Beldex the address received. It will also show how many confirmations the transaction has received from the blockchain. For example:

[wallet 86TZ2V]: check_tx_key d5fb415aad43f4e45bc72566d5ad4c8f12629db1f924d953efc2521c137a987f 5dfc4d677e2707317f306219b6aa445feaab4c652927237c012f7e72cb41bf0e 86TZ2VaG1p9PQkDgdVCYwnjoxYSU7ErXX56etGsqHLugAGqynFwBvP4dnN7wvYCcJfMa9LPgtYu8UEUqyc4xsxmx2ZTyMp4U3  
86TZ2VaG1p9PQkDgdVCYwnjoxYSU7ErXX56etGsqHLugAGqynFwBvP4dnN7wvYCcJfMa9LPgtYu8UEUqyc4xsxmx2ZTyMp4U3 received 10000.000000000 in txid <d5fb415aad43f4e45bc72566d5ad4c8f12629db1f924d953efc2521c137a987f>
This transaction has 10 confirmations

9.0 Tx Notes

The beldex-wallet-cli allows you to add notes to specific txid’s, however this note does not get stored on the blockchain, rather it is stored on client side, on the device that generates the tx_note.

9.1 Set tx note

To set a tx note we will need a the <txid> and the <message> you want to add to the txid. For instance, if you want to add a note to a txid that is connected to your wallet run the following command to show your transactions in/out with their <txid>’s:

show_transfers

To set the note to the <txid> run the following command:

set_tx_note <txid> [free text note]

Where <txid> is the transaction id associated to the transaction you are adding the [free text note] too. Your command will look similar to the following example:

[wallet 86TmZX]: set_tx_note d5fb415aad43f4e45bc72566d5ad4c8f12629db1f924d953efc2521c137a987f This is a tx note example.

9.2 View tx note

To view a note connected to a txid run the following command:

get_tx_note <txid>

Where <txid> is the transaction id that has the note connected to it. For example, if we run the command on the previous <txid> mentioned, the terminal will display the following text:

[wallet 86TmZX]: get_tx_note d5fb415aad43f4e45bc72566d5ad4c8f12629db1f924d953efc2521c137a987f
note found: This is a tx note example.

You can also view a tx note by running the show_transfers command, each transaction that has a note connected to it will display the text to the right of each transfer.

10 Changing wallet password

Changing the wallet password is only client side(locally), and if the password is forgotten the wallet can always be restored with the mnemonic seed. If you know the password to the wallet and want to change it you can run the following command:

password

Once the command has been run the terminal will prompt you for the current password and the new password twice. If entered correctly the terminal will go back to receiving inputs, otherwise the terminal will output an error such as Passwords do not match! Please try again or Error: invalid password.

11 Encrypting seed phrase

Your seed passphrase is a 25 word phrase which is used to recover access to your wallet on a client or gui and is. The command encrypted_seed allows your to add an additional password, or encryption layer, to your 25 word mnemonic seed. Encrypting your seed will stop others from recovering access to your wallet if they somehow gain access to your 25 word mnemonic seed as they will not have the passphrase that decrypts them. This means, your passphrase should not be written or saved in the same location as your encrypted 25 word mnemonic seed phrase.

To encrypt your seed run the following command:

encrypted_seed

Initially the cli wallet will prompt you to enter your wallet password. Next it will request for your seed encryption passphrase, enter in your desired password/passphrase once, click enter, then type the passphrase in again.

The wallet will output your mnemonic seed which is a 25 word passphrase. It is generally best practice to write these 25 words down and store them somewhere safe and securely, write your passphrase down(which is the phrase you used to encrypt the 25 words) and store this somewhere else. Storing the 25 words with the passphrase in a file on your computer that is not encrypted is giving others easier access to your mnemonic seed.

Thinking of running a Beldex Master Node? Great! The guide below will help you configure a device with the necessary Master Node software packages, and stake $BDX to register the node on the Beldex network.

Note: This guide assumes some familiarity with the command line and running a Linux server. For a more detailed walkthrough, check out our full Master Node setup guide.

Operating system requirements

One of:

• Ubuntu 18.04 ("bionic")

• Ubuntu 20.04 ("focal")

• Ubuntu 20.10 ("groovy")

Note: There are strict uptime requirements for Master Nodes. It is strongly discouraged to run a Master Node on a device that will not be continuously on-line. We recommend running your Master Node on a VPS with a reputable provider.

Firewall Configuration

If you are using a firewall then you should ensure that the following ports are open and reachable:

• Port 29089 (storage server to storage server)

• Port 29090 (client to storage server)

• Port 19090 (blockchain syncing)

• Port 19095 (Master Node to Master Node)

• Port 1090 (UDP, not TCP, unlike all of the above; Belnet router data)

Super Fast guide - New Master Node Setup

Configuring a new Beldex Master Node is pretty simple and straight forward. For running a Master Node you need to get your VPS's public IP address. The Master Node requies a public IP address. You cna get the public IP address of your VPS using the below command.

curl -s ifconfig.me

Copy your public IP address, you may require to add the IP address manually if the deb setup will not fetch your IP address automatically.

Run the below 5 commands on your Linux server (these commands will work on Debian and Ubuntu; modifications may be necessary for other Linux distributions):

curl -L https://deb.beldex.io/pub.gpg | sudo apt-key add -

echo "deb  https://deb.beldex.io/apt-repo stable main" | sudo tee /etc/apt/sources.list.d/beldex.list

sudo apt install ca-certificates

sudo apt update

sudo apt install beldex-master-node

The services will run via systemd as beldex-node.service, beldex-storage-server.service and beldet-router.service

Once the blockchain has synced to the server (which can take several hours, If sync from the beginning), your Master Node will be ready to be staked. You can use the beldexd status command to check the sync progress.

Express guide - New Master Node Setup

Step 1: Initial repository set-up

To add the Beldex repository, run the following commands.

Note: You only need to follow this step once, to set up the repository. The repository will subsequently be automatically updated whenever you fetch new system updates.

This first command installs the public key used to sign the Beldex Master Node packages:

sudo curl -L https://deb.beldex.io/pub.gpg | sudo apt-key add -

The second command tells apt where to find the packages.

echo "deb https://deb.beldex.io/apt-repo stable main" | sudo tee /etc/apt/sources.list.d/beldex.list

Then resync your package repositories with:

sudo apt update

Step 2: Beldex Master Node configuration

To configure your Master Node, simply install the beldex-master-node package:

sudo apt install beldex-master-node

This will detect your public IP (or allow you to enter it yourself) and automatically update the /etc/beldex/beldex.conf configuration file with the necessary additional settings to run a Master Node.

Step 2: Belnet Status Check

Check whether your Belnet router setup is done correctly or not using the below command.

systemctl status belnet-router.service

If the Belnet router is setup correctly you will get the message shown in the below screenshot.

If the Belnet router is not setup correctly you will get the error message as shown in the image below

The issue is because the public IP and port of your VPS is not set in belnet.ini file, so you need to set it manually, the file is located in the path /var/lib/belnet/router/belnet.ini . Add the IP address and port in the file as follows

public-ip=<Your Public IP Address>

public-port=1090

Congratulations! Your Master Node is now ready to be registered and staked.

Staking your Master Node

Preparing your Master Node for registration

To prepare your master Node for registration, run the following command:

beldexd prepare_registration

This will prompt you for some registration details, then output a registration command. Copy the output from this command in preparation for the next step.

Note: You can safely run this command multiple times if you change your mind about some of the registration questions before you submit the registration.

Staking and registering your Master Node

To stake and register your Master Node, open the Beldex Electron wallet. Make sure your wallet has a balance of at least 10,000 $BDX to meet the Master Node staking requirement (less if you're configuring a shared Master Node). Navigate to the Master Nodestab > Registration section, and paste the output from the above command, then click Register Master Node.

Done! Your staking transaction will now be submitted to the network. After a short delay, your Master Node will be registered and start contributing to the network (and receiving rewards!).

Checking registration status

You can easily check if your Master Node is registered on the network. First, connect to the VPS where the Master Node is running and run the following command to retrieve your Master Node's public key:

beldexd status

This will output a bunch of information about your Master Node, but there's one part we're interested in at this stage: The long string of random letters and numbers after the characters MN: . This string is your Master Node's public key, used to identify your Master Node on the list of registered and operational Master Nodes. Select and copy the public key (do not copy any of the surrounding information).

You can now jump onto explorer.beldex.io, open the full list of active Master Nodes, and use Cmd+F/Ctrl+F to check if your Master Node's public key appears in the list.

Upgrading - For Existing Master Node

When a new release is available, upgrading is as simple as syncing your repositories:

curl -L https://deb.beldex.io/pub.gpg | sudo apt-key add -

sudo apt update

Then installing any updates using:

sudo apt upgrade

Note that this will install both updated Beldex packages and any available system updates (this is generally a good thing!)

During the upgrade, the running instance of beldexd will be restarted to ensure that the updated beldexd is now active.

If, for some reason, you want to install only updated Beldex package upgrades, but not other system packages, then instead of sudo apt upgrade you can use:

sudo apt upgrade beldexd 

sudo apt upgrade beldex-storage-server 

sudo apt upgrade belnet-router 

Back-ups

Backing up your Master Node's secret key. Will allow you to easily recover or migrate your Master Node

Reveal MN secret key:

beldex-mn-keys show /var/lib/beldex/key_ed25519

Restore from MN secret key:

beldex-mn-keys restore /var/lib/beldex/key_ed25519

Having trouble? Just head to our Support section.

This document is for Master Node Operators who have used the previous Master Node Full Guide and wish to update the version of their Master Node.

Note that this update guide is for individuals running their Master Node as a Service on linux. If you are using any screen's you will need kill the screens and go back to the Master Node Full Guide and follow it once more.

It is highly recommended running your Master Node as a Service due to the ease of updating.

Step 1: Load and Update your VPS.

If you are updating your VPS you would by now have a good understanding of how to log in to your server. If you don't check out how you prepared your server in this guide here.

Once we have logged in to our VPS we should update our package lists, the below command downloads the package lists from the repositories and "updates" them to get information on the newest versions of packages and their dependencies. It will do this for all repositories and PPAs.

sudo apt update

You will notice a bunch of package lists were downloaded, once this is complete run the below command to fetch new versions of any packages we currently have installed on the system.

sudo apt upgrade

You will be prompted to authorise the use of disk space, type y and enter to authorise.

If you are prompted during the upgrade that a new version of any file is available then click the up and down arrows until you are hovering over install the package maintainer’s version and click enter.

Alright, good to go. Our server is now up to date. On to the fun part!

Step 2: Download the new Beldex Binaries

To download the Linux binaries use the following command:

wget <link>

Where <link> is the download link of the latest linux release. To find the link go to https://github.com/beldex-coin/beldex/releases/latest, right click the latest linux release and click Copy Link Location.

Your command should look something like:

wget https://github.com/beldex-coin/beldex/releases/download/v3.1.3/beldex-linux-x64-v3.1.3.zip

To unzip the downloaded zip file run the following command (changing 3.1.3 to whatever version you downloaded above):

unzip beldex-linux-x64-v3.1.3.zip

You will see something like this:

Archive:  beldex-linux-x64-v3.1.3.zip
   creating: beldex-linux-x64-v3.1.3/
  inflating: beldex-linux-x64-v3.1.3/beldex-blockchain-ancestry  
  inflating: beldex-linux-x64-v3.1.3/beldex-blockchain-depth  
  inflating: beldex-linux-x64-v3.1.3/beldex-blockchain-export  
  inflating: beldex-linux-x64-v3.1.3/beldex-blockchain-import  
  inflating: beldex-linux-x64-v3.1.3/beldex-blockchain-mark-spent-outputs  
  inflating: beldex-linux-x64-v3.1.3/beldex-blockchain-stats  
  inflating: beldex-linux-x64-v3.1.3/beldex-blockchain-usage  
  inflating: beldex-linux-x64-v3.1.3/beldex-gen-trusted-multisig  
  inflating: beldex-linux-x64-v3.1.3/beldex-wallet-cli  
  inflating: beldex-linux-x64-v3.1.3/beldex-wallet-rpc  
  inflating: beldex-linux-x64-v3.1.3/beldexd  

Note that they are unzipped into the beldex-linux-x64-v3.1.3 folder; you can check they are unzipped by running the following to change into the folder and then listing the files:

cd beldex-linux-x64-v3.1.3
ls

We now want to replace our "symlink" to the new extracted beldex-linux-x64-v3.1.3 folder. If you are unfamiliar with what the "symlink" was doing previously have a look at the Master Node Full Guide where you first set it up.

Otherwise, run the following command.:

cd
ln -snf <folder_name> beldex

Where <folder_name> is the new folder we created when unziping the release. In this case if we were to update to v3.0.2 the commands we would use would be:

cd
ln -snf beldex-linux-x64-v3.1.3 beldex

This replaces our virtual beldex folder that pointed to an old folder to the beldex-linux-x64-v3.1.3 folder we created.

At this point it is wise to restart your system with the following command:

sudo reboot

Once the system has restarted it will reboot the new version of beldexd.

Log back in to your VPS and double check the new version of beldexd is running smoothly by running the following command:

sudo journalctl -u beldexd.service -af

NOTE: If you’re nervous about trusting the binaries or the download link, you should build it from source yourself. Instructions for that can be found in the README of https://github.com/beldex-project/beldex

Excellent! You have now updated your Master Node.

First, the wallet to be converted to multisig must be empty. It is best to use a brand-new wallet for the purpose, although not required. It is strongly advised to make a copy of the wallet files first, just in case something goes wrong.

Overview

In short, the process is:

Wallet Creation

1. All parties command prepare_multisig and send data to ALL other parties

2. All parties command make_multisig <threshold> <data1> <data2> and send 2nd batch of data to ALL other parties

3. All parties command exchange_multisig_keys <data1> <data2> with the data from ALL other parties.

Receiving

1. All parties can type address to see the created multisig wallet address. The address will, of course, be the same for all parties since they're all watching the same wallet.

Preparation for Sending

1. To prepare for sending all parties command export_multisig_info <filename> and send the file to all other parties

2. To complete preparation, all parties command import_multisig_info <filename1> <filename2> and import files from other parties

Sending

1. To send, any party can use the usual transfer command, but the result will be a file named multisig_beldex_tx which must be sent to any 1 other signer

2. The other party commands sign_multisig multisig_beldex_tx and the file is updated with the signature.

3. The completely signed file is pushed to the network with use of submit_multisig multisig_beldex_tx.

Below is a step-by-step walkthrough.

Wallet Creation

Requirements:

• 3 empty beldex-wallet-cli wallets

• All parties wallets connected to a beldexd

• Confidential communication channel

Step 1 - Prepare Multisig

All 3 people should open up their beldex-wallet-cli and generate a new wallet. Make sure you do not have any $beldex within your wallet.

Person 1, 2 and 3 runs the following command within their beldex-wallet-cli:

The output will be something like:

Copy the entire line Multisig…...Vozid and be sure to capture the whole thing when copying.

Person 1 to send the Multsig...arg to Person 2 and 3, Person 2 to send their output to Person 1 and 3 and Person 3 to send their output to Person 1 and 2.

Step 2 - Make Multisig

All 3 persons now have the Multisig...arg text from the other 2. With that, each of them can create their part of the multisig wallet. Before you proceed, note that the wallet will lose access to the underlying wallet when converted to multisig. This is not really a problem, since we started with an empty wallet, and if all goes OK with this step, you won't ever need it unless you want to go through the process again for whatever reason (like HDD died, but you have the seed mnemonic of the underlying wallet and want to reconstruct the multisig wallet).

Person 1 commands:

Where <threshold> is the number of signers required out of the 3 people, <data person 2>is the output provided by Person 2, and <data person 3>is the output provided by Person 3.

This should look similar to:

Notice how there are 2 strings starting with Multisig....arg. One is from person 2 and other from person 3. The number at the beginning is the minimum required number of signatures. Since it's a 2/3 scheme - it's 2.

The output from the make_multisig command will be similar to:

With 2/3 there's an additional step to be done here. The new Multisig...arg info must be passed to ALL other participants (persons 2 & 3).

Persons 2 & 3 do the same as above and send the info to other 2 parties.

Step 3 - Exchange Multisig

Here we do one last command to make the wallet ready for receiving. It requires the 2nd batch of Multisig…....arg strings received from other parties.

Person 1 will run the command:

Unfortunately the wallet will not display an output at this point. There's no indication that the process was successfully completed (for now). All 3 persons do the same, and all 3 wallets will show the same address after this step.

Now each person run the command:

And each 3 parties of the multisig wallet should be shown the same address in their wallet.

Receiving

Step 1 Fund The Multisig Account

This is simple. Just send to the shared address. You can send multiple times, just like a normal wallet. You can use payment ID’s as well, or generate an integrated address to receive funds.

Best part, whomever is sending the funds won't be able to tell that the address belongs to a multisig wallet since it looks like any other Beldex address.

Step 2 Check Multisig Account Balance

Just open the wallet and run the refresh command . Once completed, all persons can verify that the funds arrived.

Person 1, 2 & 3 can run the command:

To see incoming transfers or the following command to see the balance of the wallet:

Preparation for Spending

Step 1 - Export Multisig

Without this step, it will not be possible to create a transaction that spends Beldex. As a minimum, the sender needs to get a partial key image from the same person who will sign the transaction with him later. He could get from both parties immediately and then later decide with whom to sign.

Person 1 commands:

Where mi1 can be any filename. The output will be:

The file mi1 will be located in the shell working folder*

Person 1 sends that file to other persons. Persons 2 & 3 do the same.

Optional: Step 1.2 Sending Multisig Info File with terminal - transfer.sh

It is optional to use the terminal to send each person the multisig info files.

UPLOADING MULTISIG INFO FILE

Person 1 will open up a new terminal and change to the directory mi1 has been saved.*

Person 1 will run the following command:

Person 1 will receive the link to the file as an output, looking similar to:

Person 1 will need to send this link to Person 2 and Person 3. Person 2 will need to do the same and send the link to Person 1 and 3. Person 3 will need to do the same and send the link to Person 1 and 2.

DOWNLOADING MULTISIG INFO FILE

Person 1 should change to the directory of their beldex-wallet-cli and use Person 2 and 3’s download link to run the commands:

Replacing <link> with the link Person 2 and 3 shared with Person 1 and <filename> with the filename of the Multisig info file that Person 2 or 3 generated, for example Person 1 will run the command:

And the command:

Likewise, Person 2 and 3 should do the same, changing directories to their beldex-wallet-cli and downloading with the alternative Persons download link, and filename.

Step 2 - Import Multisig

Now, they must all import each other's file so they can be ready to make a TX later.

For example, Person 2 commands:

The wallet will look for files in the shell working folder and if the files are found the output will look like:

Persons 1 & 3 do the same.

Spending

Step 1 - Transfer (Preparing Unsigned Transaction)

Any of the 3 persons can start a transaction, it doesn't matter. To avoid weird things from happening only do it for 1 transaction at a time. If anything weird happens, do the step 1 & 2 again to fix.

For example, let's say that Person 3 will make the TX.

Person 3 performs the usual transfer command:

The output will look like:

Check in the folder where you started beldex-wallet-cli from. There should be a file named multisig_beldex_tx.

Send the file multisig_beldex_tx to either person 1 or 2.

Person 3 will send the file multisig_beldex_tx to the Person 1 or 2. Person 3 can send this file through email or alternatively use the transfer.sh commands outside of the wallet:

If Person 3 chooses to use transfer.sh command to send the file to Person 1 or 2 they will receive a <link>.

Person 1 or 2 must finish the signature. Person 1 or 2 copies/downloads the file to the same folder from where he started (or will start) beldex-wallet-cli.

Person 1 or 2 can run the command to download the file to the beldex-wallet-cli directory.

Replacing https://transfer.sh/CJqnM/multisig_beldex_tx with the link provided by Person 3.

Step 2 - Sign Multisig

Let's say Person 2 was picked as the partner. He must finish the signature. Person 2 copies the file to the same folder from where he started (or will start) beldex-wallet-cli.

Then, Person 2 commands:

and they will be prompted to check it first:

If ok, answer Y, and the output will look like:

Step 3 - Submit Multisig

Finally, person with the signed file submits the transaction to the network by commanding:

There will be a confirmation prompt:

If ok, answer Y, and the transaction will be sent. The output will look like:

You can check its status by using the show_transfers command.

The person 2 could also send the signed TX to person 3, who could then submit it to the network himself.

If you want to make another one, you have to go back to preparation for spending step (sync the key images again).

The wallet will look for the files and export them to the folder from where it was started, ie where your command prompt / shell was when you called beldex-wallet-cli. It may or may not be the same folder as your actual wallet files or beldex-wallet-cli, depending on how you go about it.

For example, your wallet could be on some USB drive like f:\temp\, and your wallet software on c:\beldex\ and your shell working folder could be c:\.

If you remain in c:\ with the shell, you could start the wallet by its full path and specify the wallet file location: c:\beldex\beldex-wallet-cli.exe --wallet-file f:\temp\mywallet. In this case, all the import/export stuff would be read/written to c:\because that's still your shell's working folder.

It would be probably feel more natural to cd into the wallet folder. Do f: to change drive and then cd f:\temp\. Then, simply start the wallet from that location by its full path again: c:\beldex\beldex-wallet-cli.exe --wallet-file mywallet. Notice how you don't have to write the full wallet path now as you're already there with your shell. In this case, all the files mentioned above would be written or read from the same folder as the wallet files.

Source:

This document will tell you exactly how to set up and operate a Master Node for the Beldex Project. This document was written with non-developers in mind, so people new to linux or command line operations should be able to follow along without any trouble.

If you feel confident around servers and the CLI, then skip to the Express Setup Guide

You can of course run the Beldex software on any operating system that you can get it to build on, but for the purposes of this document, the instructions apply to running a Master Node on a remote Ubuntu 16.04 server. If that isn’t what you want to do, syntax and server set up will of course differ according to whatever OS you choose to run your Master Node from.

Summary of Beldex Master Node Requirements

Full summary of Beldex Master Node Requirements. This may change depending on Master Node functionality, so you should check here regularly, or follow our Telegram/Discord announcements channel.