Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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
Copyright (c) 2019 The Beldex Project.
Portions Copyright (c) 2014-2018 The Monero Project. Portions Copyright (c) 2012-2013 The Cryptonote developers.
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.
The Cli Wallet is for more advanced users and offers the most tools when interacting with the Beldex Blockchain.
Guide
Description
How to restore your wallet with spend and view keys.
How to restore your wallet with a seed phrase (25 word mnemonic seed).
Details on different commands within the beldex-wallet-cli.
How to setup the beldex-wallet-cli for the first time on Linux.
More information on the project can be found on the
If you are unsure where to start check out our "Getting Started" page by
Telegram Channel:
Telegram Chat:
Discord:
GitHub:
Twitter:
Facebook:
feature allows you to sign a transaction with more than one private key. Funds protected with multisig can only be spent by signing with 2-of-2 keys.
feature allows you to sign a transaction with more than one private key. Funds protected with multisig can only be spent by signing with 2-of-3 keys.
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.
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
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.
Index
Size in bytes
Description
0
2
1
32
public spend key
33
32
public view key
65
4
bxXk6eS3Ng98QxDTdC47eNdfCXttJycKraXxfsw9cMVngGUqP3kiSE6cwXoApU6gjzSXVX1ASAPAi1MSXA935XUs1MWEcv9
Main address is derived from the root private key.
Subaddress is what you should be using by default to receive Beldex.
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.
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.
!!! 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.
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.
Subaddresses and accounts are a wallet-level feature to construct and interpret transactions. They do not affect the consensus.
Subaddress has a dedicated "network byte":
Index
Size in bytes
Description
0
1
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.
The subaddress private view key m is derived as follows:
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.
The subaddress public spend key D is derived as follows:
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
The subaddress public view key C is derived as follows:
Where:
a is a private view key of the main address
D is a public spend key of the subaddress
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.
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.
Use Case
Scheme
Example
Shared Account
(1-of-2)
Both husband and wife individually have full access to their funds.
(2-of-2)
Both husband and wife must agree to spend their funds.
(2-of-3)
An escrow service is involved as an independent 3rd party, to co-sign with either the seller, or with the buyer, if seller and buyer do not agree.
(2-of-3)
A single owner controls all 3 keys but secures them via a different means to diversify risks.
(M-of-N)
Some cryptocurrencies provide full flexibility on the number of signers.
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.
Guide
Description
Setup Guide for a 2 of 2 Multsig Wallet.
Setup Guide for a 2 of 3 Multsig Wallet.
Setup Guide for a M of N Multisig 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.
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.
Once you run the above command you will get the below message in the terminal
Let the daemon run until the node is completely synced, you will know the node is synced once the terminal outputs the following text:
Now the daemon is synced we can run the beldex-wallet-cli file.
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
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.
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.
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.
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.
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.
The next few lines of text show how to navigate the beldex-wallet-client.
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.
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.
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
Before deciding which wallet you want to use, you must first know what you want the wallet for.
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
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)
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.
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:
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.
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.
To switch between the accounts you have created run the command:
After running the command a similar output shown below will be on your terminal.
To change the label name connected to a specific Beldex Primary or Sub-address use the command:
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.
Using the command account label 0 My Account we have changed the label connected to our Primary address from “Primary account” to “My Account”.
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.
We can tag a single account with the following command:
When needing to perform multiple tags we can do it through one command:
Similarly we can untag accounts by running the following command:
Using the above exampled wallet we will remove our “Dog” account from “Pets”.
If you require additional information attached to a specific tag you can add a description with the following command:
For example:
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:
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:
There are other commands that will also output the balance which have been covered by this guide, such as the account command.
To show the blockchain height run the command:
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:
For example:
To check if the txid was added to our list of txids not to use we can use the following command:
If the txid is on our list the following will output:
Alternatively if the txid is not on our list the following will output:
To unblackball a txid use the following command:
For example:
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.
To begin we will need to run the get_reserve_proof command to generate our proof.
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:
The Cli will request your wallet password and once your password is entered it will tell you it generated a signature file.
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.
The terminal will then print out a link to your signature file which you can then provide to the individual performing the check.
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.
To check a reserve proof we need to first have the beldex_reserve_proof file in our Beldex folder.
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:
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:
If all goes well, the terminal will output the following:
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.
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.
To begin we will first need to find the txid associated with our transaction. To do this run the following command in our wallet:
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.
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:
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.
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:
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.
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.
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:
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
If all goes well, the terminal will output the following:
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.
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.
To begin we will first need to find the txid associated with our transaction. To do this run the following command in our wallet:
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.
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:
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.
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:
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.
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.
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:
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:
If all goes well, the terminal will output the following:
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.
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.
To view the TX key of a specific transaction you have generate you will need to run the command:
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:
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.
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:
For the previous example we would run the following command from any beldex wallet:
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:
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.
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:
To set the note to the <txid> run the following command:
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:
To view a note connected to a txid run the following command:
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:
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.
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:
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.
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:
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.
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).
Index
Size in bytes
Description
0
1
1
32
public spend key
33
32
public view key
65
8
compact payment ID - 8 bytes randomly generated by the recipient; note that it does not need encryption in the address itself but it is hidden in a transaction paying to integrated address to prevent linking payment with the address by external observers
73
4
4LhSDqBZdjLQWajr4pBcFkdjL8oGY7MDvfJkKfrQVaokfDMxU6bDVb6h8tsD1jpKpSXbbB1p8RxPbA7fmjvLGjicKLBdQvDMbHA7TWVCUQ
Both types allow you to learn for what you are being paid.
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.
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).
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.
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.
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.
You can stake Beldex to receive rewards by running a Master Node with peers or by yourself.
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.
In short, the process is:
Set-up
Both parties prepare beldex-wallet-cli files
Both parties command prepare_multisig and send data to each other
Both parties command make_multisig
Receiving
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
To prepare for sending both parties command export_multisig_info <filename> and send the file to the other party
To complete preparation, all parties command import_multisig_info <filename1> <filename2> and import files from other parties
Sending
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
The other party commands sign_multisig multisig_beldex_tx and the file is updated with the signature.
The completely signed file is pushed to the network with use of submit_multisig multisig_beldex_tx
Below is a step-by-step walkthrough.
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.
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.
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.
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:
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 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:
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 orbeldex-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 onc:\beldex-windows-x64\and your shell working folder could bec:\.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 toc:\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 thencd 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:
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
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
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.
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]
Confirm password and press [Enter].
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.
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:
Once refresh is done, you can use your full functioning restored wallet. Your public wallet address will remain the same.
Restoring your wallet from seed
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.
Unzip beldex-[operating-system]-[platform]-[version].zip file
Run wallet with --restore-deterministic-wallet argument
For Linux:
For Windows:
You will be prompted to enter a wallet name and click [Enter]. You can enter any name here, use something rememberable and meaningful.
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].
Confirm password and press [Enter].
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.
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:
Once refresh is done, you can use your full functioning restored wallet. Your public wallet address will remain the same.
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.
In short, the process is:
Wallet Creation
All parties command prepare_multisig and send data to ALL other parties
All parties command make_multisig <threshold> <data1> <data2> and send 2nd batch of data to ALL other parties
All parties command exchange_multisig_keys <data1> <data2> with the data from ALL other parties.
Receiving
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
To prepare for sending all parties command export_multisig_info <filename> and send the file to all other parties
To complete preparation, all parties command import_multisig_info <filename1> <filename2> and import files from other parties
Sending
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
The other party commands sign_multisig multisig_beldex_tx and the file is updated with the signature.
The completely signed file is pushed to the network with use of submit_multisig multisig_beldex_tx.
Below is a step-by-step walkthrough.
Requirements:
3 empty beldex-wallet-cli wallets
All parties wallets connected to a beldexd
Confidential communication channel
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.
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.
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.
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.
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:
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.
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.
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.
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:
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 orbeldex-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 onc:\beldex\and your shell working folder could bec:\.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 toc:\because that's still your shell's working folder.It would be probably feel more natural to
cdinto the wallet folder. Dof:to change drive and thencd 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:
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.
In short, the process is:
Wallet Creation
All parties command prepare_multisig and send data to ALL other parties
All parties command make_multisig <threshold> <data1> <data2> .... <dataN> and send 2nd batch of data to ALL other parties
All parties command finalize_multisig <data1> <data2> ...... <DataM> with the data from ALL other parties.
Receiving
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
To prepare for sending all parties command export_multisig_info <filename> and send the file to all other parties
To complete preparation, all parties command import_multisig_info <filename1> <filename2> ..... <filenameM> and import files from other parties
Sending
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
The other party commands sign_multisig multisig_beldex_tx and the file is updated with the signature.
The completely signed file is pushed to the network with use of submit_multisig multisig_beldex_tx.
Below is a step-by-step walkthrough.
Requirements:
N empty beldex-wallet-cli wallets.
All parties wallets connected to a beldexd.
Confidential communication channel.
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:
The output will be something like:
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.
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:
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:
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:
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.
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:
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:
And each N people of the multisig wallet should be shown the same address in their wallet.
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.
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:
To see incoming transfers or the following command to see the balance of the wallet:
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:
Where miN can be any filename. The output will be:
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:
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, 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:
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:
And the command:
and all the way up to:
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.
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 .... and N do the same.
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:
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 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:
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.
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:
and they will be prompted to check it first:
If ok, answer Y, and the output will look like:
If the threshold is greater than 2 another multisig_beldex_tx file will need to be signed by the amount of signers required.
Finally, person with the final 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 orbeldex-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 onc:\beldex\and your shell working folder could bec:\.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 toc:\because that's still your shell's working folder.It would be probably feel more natural to
cdinto the wallet folder. Dof:to change drive and thencd 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:
identifies the network and address type; - main chain; - test chain; - stagenet chain
checksum ( of the previous 65 bytes, trimmed to first bytes)
It totals to 70 bytes. The bytes are then encoded () in Beldex specific Base58 format, resulting in a 96 chars long string. Example main address:
See the .
To prevent the payer from linking your payouts together simply generate a new subaddress for each payout. This way services like wouldn't know it is you again receving Beldex.
identifies the network and address type; - mainnet; - stagenet; - testnet
Otherwise the data structure is the same as for the .
The subaddress #0 on the account #0 is the . As main address has different generation rules, this is simply implemented via an if statement.
The procedure is the same as for the .
- the easiest to follow implementation by Michał Sałaban
- Monero reference implementation
- gives context but is not up to date with all details
- excellent summary by knaccc
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 . Download the latest release for your specified Operating System, for this user guide we are going to assume you are running Linux.
The GUI wallet can be downloaded
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 .
You can download the cli-wallet from
You will want to send this file to the person who requires the proof. You can upload the beldex_reserve_proof file through by running the command within the folder of your signature file:
If you do not have the beldex_reserve_proof file in your beldex folder request the individual sending the file to you to use , once they send you the link to their beldex_reserve_proof you can use the following command to download it.
You will want to send this file to the person who requires the proof. You can upload the beldex_spend_proof file through by running the command within the folder of your signature file:
If you do not have the beldex_spend_proof file in your beldex folder request the individual sending the file to you to use , once they send you the link to their beldex_spend_proof you can use the following command to download it.
You will want to send this file to the person who requires the proof. You can upload the beldex_tx_proof file through by running the command within the folder of your signature file:
If you do not have the beldex_tx_proof file in your beldex folder request the individual sending the file to you to use , once they send you the link to their beldex_tx_proof you can use the following command to download it.
Data structure ():
identifies the network and address type; - main chain; - test chain; - stage chain
checksum ( of the previous 73 bytes, trimmed to first bytes)
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:
Individuals should prefer subaddresses to receive payments. This is to improve confidentiality in certain scenarios. See article on for details.
In very specific scenarios, preparation effort to monitor a very huge number of subaddresses, could became an issue. See for details.
question on
Before you start using Beldex, you should on how Beldex will help you obfuscate your data.
If you are unsure about which wallet to choose, you should go to the page.
Beldex can be purchased on exchanges (currently listed on MEXC, Gate.io, KuCoin and other exchanges which can be found here: ).
To operate a , 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 from each block.
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.
Open a (Windows) or (Linux / OSX) and navigate to the wallet folder
You will be prompted for a password. Enter a new password that follows the and press [Enter].
Download the latest release of wallet CLI software for your desired operating system:
Open a (Windows) or (Linux / OSX) and navigate to the wallet folder
You will be prompted for a password. Enter a new password that follows the and press [Enter].
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
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.
Explains about the Masternode staking requirement and rules
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.
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.
A quick guide to set up your exit node
Docker and docker-compose are prerequisites to download and run the docker images and container.
Enter the following commands to download and install docker.
Enter the following commands to download and install docker-compose.
Enter the following command into the terminal to pull the BelNet Exit Node image from the docker hub.
Enter the following command to get the BelNet yml file from Beldex deb.
Enter the following command to run the yml file as a container.
Enter the following command to get the container ID and other details.
Enter the following command after replacing your container ID in place of <container -id>
Your exit node is now live. Get your exit node’s BelNet address using the following command.
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.)
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.
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.
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).
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).
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.
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.
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.
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.
A Guide to update the master nodes
It is highly recommended running your Master Node as a Service due to the ease of updating.
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.
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.
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!
To download the Linux binaries use the following command:
Your command should look something like:
To unzip the downloaded zip file run the following command (changing 3.1.3 to whatever version you downloaded above):
You will see something like this:
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:
Otherwise, run the following command.:
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:
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:
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:
Excellent! You have now updated your Master Node.
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.
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.
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)
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.
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):
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.
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:
The second command tells apt where to find the packages.
Then resync your package repositories with:
To configure your Master Node, simply install the beldex-master-node package:
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.
Check whether your Belnet router setup is done correctly or not using the below command.
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
Congratulations! Your Master Node is now ready to be registered and staked.
To prepare your master Node for registration, run the following command:
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.
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!).
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:
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).
When a new release is available, upgrading is as simple as syncing your repositories:
Then installing any updates using:
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:
Backing up your Master Node's secret key. Will allow you to easily recover or migrate your Master Node
Reveal MN secret key:
Restore from MN secret key:
A brief description about the Masternode functions
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.
An guide to setup the Masternode
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.
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.
Spec
Note
Latest Binary
Software
Ubuntu 18.04 or higher
Storage
40GB or more
Ram
2-4 GB
CPU
1 Core
Master Nodes are full nodes on the Beldex network
Once accepted by the network, the Master Node is eligible to win block rewards.
Multiple participants can be involved in one Master Node and can have the reward automatically distributed
It is also worth noting that Master Nodes are quite basic at the moment, and operators will need to stay up to date with new updates to keep in line with software and hardware requirements. Once all of the updates are out, Master Nodes will also:
Route end user’s internet traffic, either as an exit node or relay in a novel mixnet.
Receive, store and forward encrypted user messages.
Monitor other Master Nodes and vote on their performance.
Be called into quorums which give them authority over instant transactions
Act as remote nodes for users.
Once these features come out, Master Node operation will require better servers, particularly when it comes to bandwidth. For the purposes of this guide, however, we will only consider the current requirements.
This section of this guide is for new users to servers and the CLI interface.
Righto! Let’s get started. Choosing where to set up a Master Node is the biggest choice you will make when running a Master Node. There are a number of things to consider. Because you will be locking up funds for 30 days (2 days for testnet) at a time, you will want to ensure that your server has:
A stable, relatively fast connection to be able to respond to ping requests to avoid being booted off the network.
We recommend 2GB of RAM to cope with running the software reliably (Note: This requirement may be much greater once services are live). 1GB is fine for testing.
At Least a 20GB SSD or Hard disk drive, this will be used to store the blockchain (Note: to future proof yourself against blockchain growth and message storage we recommend a 30 - 40 GB drive).
A stable power supply. If your server goes down during the staking period, you may get kicked off the network, and not receive rewards while your funds are still locked for the remainder of the staking period.
For most users, we assume that your home internet connection is relatively slow (< 4MB/s down and up) and probably lacks support for external connections. If this is the case, you will probably not want to run a Master Node from your home in the long term, as this could cost you if and when you get booted off. Since we’re just testing at the moment, you could run it from home anyway, but for this guide we’ll avoid it.
Typically, the easiest and cheapest way to host a server outside of your home is to use a Virtual Private Server (VPS). There are thousands of options when it comes to VPS providers, but for now, just about any one will do. In the future, selection will be made more difficult because most providers will not allow exit node traffic, so we have compiled a list of exit node friendly providers to choose from if you want to stay with your provider for more than a few months.
Hosting Provider
Product Name
Cost Per Month $USD
Bandwidth Provided
Exit Friendliness Rating
Netcup
VPS 1000 G8
10.50
30 - 35 MiB’s
5 / 10
Online.net
Start-2-S-SSD
13.99
15 - 17 MiB’s
9 / 10
Scaleway
START1-M
9.33
20 - 25 MiB’s
7 / 10
OVH
VPS SSD 2
7.61
10 - 15 MiB’s
9 / 10
Leaseweb
Virtual Server XL
34.45
30 - 35 MiB’s
5 / 10
Digital Ocean
2 GB, 2 vCPUs
15
9 - 11 MiB’s
8 / 10
Feral Hosting
Neon Capability
19.68
9 - 11 MiB’s
9 / 10
Trabia
VDS-8G
38.54
9 - 11 MiB’s
8 / 10
Hetzner
EX41-SSD (30 TB)
39.71
80 - 40 MiB’s
4 / 10
Note: We do not officially endorse any of these providers, this list is simply illustrative of some of the options currently available*
Try not to pick the first one off the list. Do some digging and see which one looks the best to you, what your budget is, and what the latency is like for you based on the server location that you choose.
When selecting your VPS’ operating system, choose Ubuntu 16.04 64 bit or Ubuntu 18.04 64 bit if you want to follow this guide. If you feel more confident or wish to run your server on another distribution or operating system, the Beldex commands in this guide will still apply.
Every provider has a slightly different way of issuing you access to your new VPS. Most will send an email with the IP address, root username, and a root password of the VPS.
To access your server, you will need a SSH client for your operating system. Because we’re on Windows today, we’ll download PuTTY, Mac users can also use PuTTY. If you’re a Linux user, you probably don’t want us telling you where to get a SSH client from.
To connect to our VPS we will need to paste the IP address into the SSH client’s “Host Name (or IP address)” input box and click the “Open” button. The Port number can usually just be left as 22.
A terminal window will now appear prompting for your log-in details, username(root) and password, which were provided by your VPS provider. When entering your password, nothing will visually appear in the terminal. This is normal. Hit enter when it’s typed or pasted, and you should be logged in to your VPS.
Create a non-root User
Best practice when running a public server is to not run your software as the root user. Although it is possible to do everything as root, it is strongly recommended that you create a non-root user on our VPS by running the following command:
Replacing <username> with a name you will log-in with. For this user-guide we will use mnodeas our username.
The terminal will prompt you for a new password for our newly created user. Use a secure password that is different password from the root password.
Once the password has been set, the terminal will prompt for a few details about the individual running the user. You can just hit enter through each of the inputs as the details are not important for the purposes of running a Master Node.
Once that’s done, run the following two commands to give our new account admin privileges and to change to such account.
Before we proceed further, it is advised to close your terminal and reopen PuTTY to set up a saved session with our mnode user. Your SSH client will have a load and save session function. For PuTTY we will need to type in our VPS IP address again, on the same screen type mnode under “Saved Session”. Click on “Data” under the drop-down menu “Connection”, and type in mnode (or your username defined before) into the input box “Auto-login username”. Go back to your session screen, where we entered the IP address, and click “Save”. You can load this session whenever you want to check on your Master Node.
Hot Tips for using the Console
Consoles don't work like the rest of your computer. Here are some basic tips for navigating your way around the command line!
Don't try copying something by using the usual Ctrl + C hotkey! If you want to copy something, do so by highlighting text and then right clicking it. Pasting works by right clicking a blank area in the console.
If you want to kill a process or stop something from running, press Ctrl + C. (This is why you shouldn't try copying something with this hotkey.)
You can always check the directory you are in by typing pwd and list its contents by typing ls.
You can always return to your home directory by typing cd.
You can move into a given directory by typing cd <name> or move back up one level by typing cd ...
PuTTY allows you to easily duplicate or restart a session by right clicking the top of the window. Handy if you’re trying to do a few things at once.
Once we have logged in correctly to the VPS for the first time, the VPS may be configured to prompt for a new password for the root account. The terminal will require you to enter the new password twice before we can start running commands. If you aren't prompted for a new rootpassword but want to change it anyway, type sudo passwd. Choose something very secure!
Server Preparation Continued
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.
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.
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 set up, up to date, and is not running as root. On to the fun part!
If you are using a firewall then make sure the following ports are open/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)
In order to download and extract the Linux binaries, we need to make sure a couple tools are installed:
Now download the Linux binaries by running the following command:
Your command should look something like:
To unzip the downloaded zip file run the following command (changing 2.0.4 to whatever version you downloaded above):
Now all the binaries are unzipped into the beldex-linux-x86_64-v4.0.0 , belnet-linux-x86_64-v0.9.5 and beldex-storage-linux-x86_64-v2.2.0 folders; you can check they are unzipped by running the following to change into the folder and then listing the files:
Excellent! We now have all of the necessary files to get it started!
At this point you can run the binaries directly in your terminal, but this is not a viable approach to running it as a master node: when you close PuTTY the program running inside it will also shut down, which is no good for a master node.
Instead we will configure the binaries as a system service which makes it automatically start up if the server reboots, and restarts it automatically if it crashes for some reason.
We need to setup system servieces for three files, lets do it one by one.
Create the beldexd.service file:
Copy the text below and paste it into your new file:
Note: Make sure to give your public ip address instead of <Your Public IP Addr> and the directory path instead of <DIR PATH> in the above file
Get the <DIR PATH> using the below command.
You can get the public IP of your machine using the below command
(If you want to run a testnet master node, append
--testnetto the end of the ExecStart line. Alternatively, if you want to be able to run both a testnet and mainnet master node simultaneously you can use two service files:beldexd.serviceandbeldexd-testnet.serviceand add--testnetto theExecStart=line in the latter. You would then usebeldexd-testnet.serviceinstead ofbeldexd.servicein the commands below when you want to control the testnet master node.)
Once completed, save the file and quit nano: CTRL+X -> Y -> ENTER.
Reload systemd manager configuration (to make it re-read the new service file):
Enable beldexd.service so that it starts automatically upon boot:
Start beldexd.service:
The daemon will now start syncing. You won’t be able to do much if it hasn’t synced.
To watch the progress at any time you can use the following command (hit Ctrl-C when you are done watching it). You should see it syncing the blockchain:
Alternatively you can ask the daemon to report its sync status using the following command:
Create the storage-server.service file:
Copy the text below and paste it into your new file:
Note: Make sure to give your directory path instead of <DIR PATH> in the above file
Get the <DIR PATH> using the below command.
You can get the public IP of your machine using the below command
Once completed, save the file and quit nano: CTRL+X -> Y -> ENTER.
Reload systemd manager configuration (to make it re-read the new service file):
Enable storage-server.service so that it starts automatically upon boot:
Start storage-server.service:
Get the bootstrap signed file to communicate with the master nodes in the network. Use the below command to get the signed file:
2. Create the belnet.service file:
3. Copy the text below and paste it into your new file:
Note: Make sure to give your directory path instead of <DIR PATH> in the above file
Get the <DIR PATH> using the below command.
You can get the public IP of your machine using the below command
Once completed, save the file and quit nano: CTRL+X -> Y -> ENTER.
Reload systemd manager configuration (to make it re-read the new service file):
Enable belnet.service so that it starts automatically upon boot:
Start belnet.service:
While we wait for the daemon to sync, we can now get a wallet going.
You do not have to run this wallet on the server and you should not! Download the software and run it from elsewhere for security reasons!
You can run the CLI wallet (Command Line Interface wallet) on any other computer, including your home computer to avoid leaving your wallet on the server.
However, if you do want to run the CLI wallet on another computer, you will either need to run another daemon on that local machine or use a remote node (publicnode1.rpcnode.stream:29095, for example).
Or on windows:
If you are made of money and are willing to take the small risk of losing all of your funds, you can continue running the wallet inside the Master Node VPS. So we don't have to talk about a myriad of other operating systems or potential user cases, the rest of this guide will assume you are running the wallet in the same VPS.
As such, it’ll probably save us time to open a second PuTTY session. You can do this by right clicking the window of the current PuTTY session and clicking “Duplicate Session.”
Log in as the non-root user that we set up before, in our case mnode, and launch the wallet using:
If you are on testnet run the command with the --testnet flag:
~/beldex/beldex-wallet-cli --testnet
When beldex-wallet-cli first runs, it will request for you to specify a wallet name. Assuming we haven't created one yet, we will use the e.g. name MyWallet
Because this is the first time we have used the name MyWallet the client will prompt us to create a new wallet. Type y and click return to continue.
The beldex-wallet-cli has generated us a wallet called MyWallet and is now prompting us for a password.
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 you type 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.
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 in 1 and clicking return.
The CLI will generate and spit out several lines of text. The first two lines of text show your wallet public address. This address can be shared, will be used to receive Beldex to your wallet, and will be used during the preparation and registration of our Master Node. All Mainnet Beldex public addresses start with an L and are followed with a string of characters, Testnet Public addresses start with a T. The public address shown will be your primary address, however multiple public addresses can be generated from this primary address.
Line 13 to 17 show your 25-word mnemonic (“new-monic”) seed. The seed is used to easily backup 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. 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 wallet.
It is at this point that we should get some Beldex in the wallet. The amount of Beldex required to run a node is 10,000 BDX. If you do not have enough you will have the option to join in or run your own Master Node pool.
If you are staking please do not use Subaddresses. They are currently unsupported by the Beldex wallet.
We will need our address to register our Master Node later, to get your primary address type the following command:
Highlight the string of characters that were outputted and save this in a notepad for later use, your public address should look similar to:
(Note that this is an example testnet wallet address; your address will start with L if it is a mainnet wallet)
NOTE: Do not use CTRL + C to copy your address, it will close the wallet down. Simply highlight the address and this will automatically save the portion you highlighted into your clipboard.
Once you have enough Beldex in this wallet, just leave it open, we’ll come back to it in a minute.
The next part of the guide will split into two sections: * If you are an individual staker and do not require any other contributors to run your Master Node jump into 6.1 - individual Staking. * If you want to run a pooled Master Node or contribute towards a pool jump into 6.2 - Pool Staking
6.1 - Individual Staking
If you want to run the Master Node as an individual you will require the following things.
A fully synchronized, up-to-date Beldex daemon running with the --master-node flag (see step 4).
A beldex-wallet-cli primary address with enough Beldex in your account to meet the Master Node Staking Requirement (see step 5).
Now if we have the two above items we can proceed to our daemon to register our Master Node.
Log in (if not already connected) as the mnode user on the VPS running the master node, then start the registration process by running the following interactive command:
The daemon will output the current staking requirement and prompt you with an input to clarify whether you are an individual staker or you will be running a pool. Type y and click enter as we will be the sole staker.
The daemon will now prompt us for the Beldex address of the operator. If you followed step 5 you should have this address saved in a notepad, if not run through step 5 again to find your Beldex Address. Once we have the Beldex Address copied to our clipboard we can then right click the terminal screen to paste the address. Double check the address matches the one of your wallet then click enter if it is the same.
The daemon will now ask for a final confirmation, if you agree to the information provided type y and click enter.
The daemon will output a command for us to run looking similar to:
NOTE: You must run the command outputed by your daemon and not the command shown above.
Copy the whole line of text and paste it into your notepad as we will need to run this command in our beldex-wallet-cli. If registering multiple nodes, it will likely be necessary to wait at least 10 blocks between Master Nodes before running the register Master Node command in the wallet.
You have 2 weeks from the moment of preparing the registration command on the Master Node to actually run the register_service_node command in the wallet, however it is advised to do it as soon as possible.
Run through step 5 once more to open our Beldex wallet (if you don't already have it open). Once we are in our wallet run the command the daemon outputted for us when we prepared our Master Node registration.
The wallet will prompt us to confirm our password, then the amount of Beldex to stake. Confirm this by typing y and clicking enter.
Note: At this point you now have locked stakes! To unlock your stake run the following
Well done! Let's continue to the next step "Step 7 - Master Node Check" to check if our Master Node is running.
6.2 - Pool Staking
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
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 10,000 Beldex then if,
Operator contributes 50% of the requirement (5,000 Beldex)
The next contributor must contribute at least (⅓ * 5,000) Beldex i.e. 1667 Beldex to become a participant.
If this contributor had reserved a spot for more than 1667 Beldex, 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.
Depending on the individual and their circumstance they will need to:
NOTE: It is advised to read both sections of "6.2 - Pool Staking" to have a better understanding of the process.
6.2.1 - OPERATOR
The Operator is the individual who will be hosting the pool and running the Master Node daemon, thus incurring the operating expenses encompassed by running a node.
The Operator will need to have:
A fully synchronized, up-to-date Beldex daemon running with the --master-node flag (see step 4) at all times.
A beldex-wallet-cli primary address with enough Beldex in their account to meet 25% of the Staking Requirement.
1-3 other contributors who also have a wallet (beldex-wallet-cli or the desktop GUI wallet) with enough Beldex in their accounts to meet 25% of the staking requirement.
If the operator wants to reserve contribution spots for specific contributors: The address and contribution amounts the 1-3 contributors will stake.
NOTE: The other contributors addresses are optional to have as you can create your pool to be open to anyone to contribute to, however they are recommended to have to avoid any issues of other individuals stealing their spots. On the other hand, a reserved contribution spot can only be filled by that contributor: if they change their mind before submitting a stake your master node will be stuck inactive, so it is recommended to use reserved contribution spots only with contributors you trust.
Now if we have the three/four above items we can proceed to our daemon to register our Master Node.
Log in (if not already connected) as the mnode user on the VPS running the master node, then start the registration process by running the following interactive command:
The terminal will prompt the operator to specify if they will contribute the entire stake, because we are running this as a pooled Master Node we will type n and click enter.
Next the terminal will request the input for the operator cut. This value is between 0-100 and represents the percentage of the reward the operator will receive before the reward is distributor to the share holders. If you have agreed to a 10% operator cut with the other contributors you would type 10 and click return.
The terminal will now display the minimum reserve the operator can contribute and request the operator to input the amount in Beldex they wish to contribute. Type your desired <operator contribution> and click return.
Once we have set the operators desired stake amount we have the option to either leave the pool open for anyone to contribute or lock a reserve for individuals that have agreed with us to stake within our Master Node.
Reserved Pool
If the operator wishes to reserve spots for specific contributors they should type y and click return.
The terminal will now prompt the operator for the number of additional contributors they have organised to be apart of this Master Node. Type in the number of reserved contributors, not including themselves, and click return.
The daemon will now prompt us for the Beldex address of the operator. If you followed step 5 you should have this address saved in a notepad, if not run through step 5 again to find your address. Once we have the Beldex Address copied to our clipboard we can then right click the terminal screen to paste the address then click return to confirm your address.
Next the operator must input the amount of Beldex each contributor will contribute and the contributor's address.
NOTE: It is possible to reserve only some of the required stakes for specific contributors while leaving the remaining stake open.
You will now be asked to confirm the information above is correct.
Open Pool
If the operator wishes to leave their pool complete open to contributions they should type nand click return. The terminal will prompt the operator to input their address. Once the address has been inputted the terminal will display the remaining portion that needs to be contributed by others. If you agree click y and hit return.
The daemon will display a summary of the information we entered. This is our chance for a final check over to make sure we entered in the right information. If you confirm the information is correct type y and click return.
The daemon will output a command for us to run within our wallet, looking similar to:
NOTE: You must run the command outputed by your daemon and not the command shown above.
Copy the whole line of text in your daemon and paste it into your notepad as we will need to run this command in our beldex-wallet-cli.
You have 2 weeks from the moment of registering the Master Node to run the register_service_node command, however it is advised to do it as soon as possible.
Before you disconnect from your VPS run the following command to get your <Master Node Public Key> and save it in your notepad (your contributors will need it):
Run through step 5 once more to open our Beldex wallet. Once we are in our wallet run the command the daemon outputted for us when we prepared our Master Node. The wallet will prompt us to confirm our password, then the amount of Beldex to stake. Confirm this by typing y and clicking enter.
Once this command completes your staking transaction will be sent to be included on the blockchain. It may take a few minutes for the transaction to be mined into a block; you can check the status using
Once the master node registration is received you can send the <Master Node Public Key>to your contributors with the amount of Beldex they are required to stake.
NOTE: the final amount will typically be slightly lower than what you entered in the prepare_registration command. This is expected: the required amounts are based on the registration block height which has usually advanced by a couple blocks between the time you prepared the registration and the time it gets mined into the blockchain.
At this point we will need to wait until all contributors have staked before the master node activates and becomes eligible to receive rewards.
6.2.2 - POOL CONTRIBUTOR
The pool contributor must first receive the Master Node Pubkey and the requirements (amount ofbeldex to send) from the Master Node Operator.
If you are staking please do not use Subaddresses. They are currently unsupported by the Beldex wallet
The pool contributor must have downloaded the necessary binaries, is running a daemon or is connected to a remote node, has generated a wallet through either the beldex-wallet-cli or the desktop GUI wallet, and has enough Beldex to stake. They can then run the following command in their beldex-wallet-cli .
Where the <Master Node Pubkey> is the Pubkey provided from the Master Node operator, the <address> the master node operator will likely reserve an address for which they want you to stake for, this will usually be the same address as the wallet you are planning to stake from, in the case of an open pool this will always be the address you will you stake from and you will also receive rewards here too. <contribution amount> is the amount of Beldex they are going to stake which they agreed to with the Master Node Operator.
If using the desktop GUI wallet, the Stake command can be found under the Advanced - Master Node menu. Enter the service <Master Node Pubkey> and <contribution amount>and hit the Stake button.
At this stage you will need to wait for the other contributors to provide their collateral. Once everyone has staked you can refer to “Step 7 - Master Node Check” to see where your Master Node Operator’s node is in the list.
Congratulations, you are now staking.
After we have locked our collateral we will need to check if our Master Node Pubkey is sitting in the list with the other Master Node’s on the network. This will prove our Master Node is running, recognised and will receive a reward if it keeps running.
Connect to the VPS where the master node is running and run the following command to see our Master Node Public Key:
The Master Node Public Key is used to identify our Master Node within the list of Master Nodes currently on the network.
If you want more detailed Master Node status you can use the follow command:
To check this information directly with the master node itself, first get the current block height by running ~/beldex/beldexd status into the terminal: it will output this information. Once we have the block height we can then check the current Master Nodes on the network at our specified block height.
Run the command ~/beldex/beldexd print_quorum_state <block height> replacing <block height> with the number minus 1 that was outputted when running statuscommand.
If your <Master Node Pubkey> is sitting in the list you know you are now staking.
Master Nodes will continually receive block rewards indefinitely until a stake is unlocked or the Master Node becomes deregistered. Unlocking is available via the following command which needs to be run 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.
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).
See Locked Stake Amount and Duration
We can also view our locked stake by running the following command from our beldex-wallet-cli we staked from:
This section is for power users who are more familiar with servers and the CLI interface. There's a couple of things your going to want to do before you commence.
1. Get a Server that meets requirements
2. Run the Daemon on a server from a non-root user account, then stake from a local wallet (or a wallet on a separate server).
3. Connect via SSH to your server
4. add new user
5. login to your new user account via SSH
6. Update necessary security patches and system utilities
7. Download & unzip Beldex
8. Set up Beldex to run as a service
Paste the following:
Save and exit: CTRL+X -> Y -> ENTER
Enable and start the service:
Wait for the Beldex Daemon sync the blockchain (1 - 8 Hours depending on internet speed). You can watch the progress using:
Hit Ctrl-C when you are tired of watching.
9. Open a Wallet
This wallet can be in a screen session on the Master Node machine, or a wallet on your local computer (assuming you have downloaded the binaries locally).
Linux/MAC - ./beldex-wallet-cli Windows - beldex-wallet-cli
Enter Name: Name your wallet
Enter password
Language: 1 (for English)
Securely store:
Address
Seed Phrase
Pass-phrase
Send enough Beldex to fund a node, wait for Balance to be unlocked (20 mins, 10 confirmations)
10. Register your Master Node
Connect via SSH to your VPS with the Master Node running (mnode@<ipaddress>).
Contribute entire Stake: Y/N
Enter Beldex Address
Enable Restaking: Y/N
Confirm: Y
Copy green registration message
Ctrl +AD
11. Reattach to Master Node or local wallet
Paste in registration message <enter>
12 Connect back to Master Node VPS account
Copy master node key, and search for it on:
or check the detailed status using:
Well done! You will receive a block reward when your Master Node has been active for some time and the network chooses you within the list
Server Requirements
Operating System: Ubuntu 18.04 or higher
Storage: Minimum 40GB
RAM: 2-4 GB
CPU: 1 Core
Add the Public Key: Install the public key required to verify and sign the Beldex Master Node packages:
Add the Package Repository: Inform the package manager about the location of the Beldex repository:
Update Package Repositories: Resynchronize your package manager to include the new repository:
Install the Master Node Package: Set up your Master Node by installing the required package:
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.
Beldex Node:
Check if the beldex-node service is running correctly:
Command Output:
Beldex Storage Server:
Verify the status of the beldex-storage-server service:
Command Output:
Note: Ping to daemon will start after 57000 blocks
Belnet Router:
Confirm the belnet-router service is operational:
Command Output:
Beldex Daemon:
Verify the status of beldexd:
If the Master Node public key and last pings are not displayed, restart the 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
Once the node synchronization reaches 100%, prepare the Master Node 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
1. Storage Server Not Pinging:
If the beldex-storage-server does not respond to pings in the beldexd status, restart the service:
2. Belnet Router Not Pinging:
If the belnet-router ping is not received:
3. Belnet Router Bootstrap Error:
If belnet-router fails to bootstrap, follow these commands:
Check the service status:
Navigate to the Belnet directory:
Bootstrap Belnet:
Restart the belnet-router service:
This process ensures the belnet-bootstrap binary downloads the required files to /var/lib/belnet and initiates pings.
BelNet GUI Installation Guide for Windows & Linux
Download BelNet GUI for windows from the .exe file below:
Download BelNet GUI for Linux using the guide below:
Enter the following command to add the keys
Enter the following command into the terminal to install and update the certificate
Enter the following command to complete the BelNet GUI installation
A comprehensive guide to setting up your exit node
Below are the system requirements and the minimum specifications of dedicated server or 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
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 #.
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
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
Enter the following command to fetch your address
To check if your exit node is publicly hosted, enter 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
A detailed guide for Masternode RPC endpoints
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
Result
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 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
Result
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 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
Result
Inputs
N/A
Outputs
String master_node_pubkey
The public key identifying the queried master node
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
Result
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.
get_block_template UpdatesDue 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.
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
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
A guide to setup master node using docker
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.
Copy the below code to a shell file master-node-deploy.sh
OR
Make sure the node is fully synced before run this command
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.
A comprehensive guide to hosting your first MNApp
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.
Download and run the binaries
Enter the following command into the terminal to download the Belnet binaries from cloud
Unzip the file using the following command
Run the Belnet binary
Then, copy and paste the following command to open the belnet.ini file.
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
Enter the following command and restart the Belnet client
To find your MNApp address, enter the following command.
For example, this is the MNApp address for the Beldex explorer hosted on BelNet cw41adqqhykuxw51xmagkkb3fixyieat1josbux13jn6o973tqgy.bdx
Nginx is a dependency. So download and install it using the following commands
Use the following command to check whether nginx is working
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.
Place your html web page into this directory
Below is a sample configuration of Nginx
Enter the following commands
Now enter your directory’s name (established in Step 4) in place of your_own_directory in the command below.
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.
Save it by pressing Esc and then :wq
Restart Nginx using the following command
To access your MNApps, connect to BelNet and enter the MNApp’s BelNet address into a browser’s address bar
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.
Guide/Resource
Description
Setting up Master Node
How to host and maintain a Master Node using the .
How to update your Master Node version.
How to use JSON 2.0 RPC Calls with Master Nodes.
Beldex Block explorer showing the current Master Node Pubkeys.
This document is for Master Node Operators who have used the previous 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 and follow it once more.
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 .
Where <link> is the download link of the latest linux release. To find the link go to , right click the latest linux release and click Copy Link Location.
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 where you first set it up.
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
You can now jump onto , 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.
Having trouble? Just .
Beldex circumvents these issues by requiring each 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.
If you feel confident around servers and the CLI, then skip to the
Full summary of Beldex Master Node Requirements. This may change depending on Master Node functionality, so you should check here regularly, or follow our / announcements channel.
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Full nodes become Master Nodes when the owner and submits a registration transaction.
Where <link> is the download link of the latest linux release. To find the link go to , right click the latest linux release and click Copy Link Location.
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
Jump into section if they are running the daemon and hosting the pool;
Jump into section if they are contributing to someone's Master Node.
or by looking for your <Master Node Public Key> in the "Master Nodes Awaiting" section on
You can jump onto to see if your Master Node is in the list or we can continue in the terminal to output the same information.
If you are running your Master Node on testnet go to instead.
Where <VERSION> is mentioned replace with the , example v3.0.2
.
This guide will be regularly updated when new features are added to Master Nodes.
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.
e.g.
S. No.
Spec
Note
1
CPU Cores
2 or more
2
RAM
4 GB
3
Storage
40 GB SSD
4
Higher Bandwidth
At least 1 GB preferable
This is a list of the beldexd daemon RPC calls, their inputs and outputs, and examples of each.
Many RPC calls use the daemon's JSON RPC interface while others use their own interfaces, as demonstrated below.
Note: "atomic units" refer to the smallest fraction of 1 BDX according to the beldexd implementation. 1 BDX = 1e12 atomic units.
The majority of beldexd RPC calls use the daemon's json_rpc interface to request various bits of information. These methods all follow a similar structure, for example:
Some methods include parameters, while others do not. Examples of each JSON RPC method follow.
Look up how many blocks are in the longest chain known to the node.
Alias: getblockcount.
Inputs: None.
Outputs:
count - unsigned int; Number of blocks in longest chain seen by the node.
status - string; General RPC error code. "OK" means everything looks good.
Example:
Look up a block's hash by its height.
Alias: on_getblockhash.
Inputs:
block height (int array of length 1)
Outputs:
block hash (string)
Example:
Get a block template on which mining a new block.
Alias: getblocktemplate.
Inputs:
wallet_address - string; Address of wallet to receive coinbase transactions if block is successfully mined.
reserve_size - unsigned int; Reserve size.
Outputs:
blocktemplate_blob - string; Blob on which to try to mine a new block.
blockhashing_blob - string; Blob on which to try to find a valid nonce.
difficulty - unsigned int; Difficulty of next block.
expected_reward - unsigned int; Coinbase reward expected to be received if block is successfully mined.
height - unsigned int; Height on which to mine.
prev_hash - string; Hash of the most recent block on which to mine the next block.
reserved_offset - unsigned int; Reserved offset.
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
Example:
Submit a mined block to the network.
Alias: submitblock.
Inputs:
Outputs:
status - string; Block submit status.
In this example, a block blob which has not been mined is submitted:
Block header information for the most recent block is easily retrieved with this method. No inputs are needed.
Alias: getlastblockheader.
Inputs: None.
Outputs:
block_header - A structure containing block header information.
block_size - unsigned int; The block size in bytes.
depth - unsigned int; The number of blocks succeeding this block on the blockchain. A larger number means an older block.
difficulty - unsigned int; The strength of the Beldex network based on mining power.
hash - string; The hash of this block.
height - unsigned int; The number of blocks preceding this block on the blockchain.
major_version - unsigned int; The major version of the beldex protocol at this block height.
minor_version - unsigned int; The minor version of the beldex protocol at this block height.
nonce - unsigned int; a cryptographic random one-time number used in mining a Beldex block.
num_txes - unsigned int; Number of transactions in the block, not counting the coinbase tx.
orphan_status - boolean; Usually false. If true, this block is not part of the longest chain.
prev_hash - string; The hash of the block immediately preceding this block in the chain.
reward - unsigned int; The amount of new generated in this block and rewarded to the miner. Note: 1 BDX = 1e12 atomic units.
timestamp - unsigned int; The unix time at which the block was recorded into the blockchain.
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
In this example, the most recent block (56754 at the time) is returned:
Block header information can be retrieved using either a block's hash or height. This method includes a block's hash as an input parameter to retrieve basic information about the block.
Alias: getblockheaderbyhash.
Inputs:
hash - string; The block's sha256 hash.
Outputs:
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
In this example, block 912345 is looked up by its hash:
Alias: getblockheaderbyheight.
Inputs:
height - unsigned int; The block's height.
Outputs:
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
In this example, block 912345 is looked up by its height (notice that the returned information is the same as in the previous example):
Alias: getblockheadersrange.
Inputs:
start_height - unsigned int; The starting block's height.
end_height - unsigned int; The ending block's height.
Outputs:
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
In this example, blocks range from height 1545999 to 1546000 is looked up (notice that the returned informations are ascending order and that it is at the April 2018 network upgrade time):
Full block information can be retrieved by either block height or hash, like with the above block header calls. For full block information, both lookups use the same method, but with different input parameters.
Alias: getblock.
Inputs (pick one of the following):
height - unsigned int; The block's height.
hash - string; The block's hash.
Outputs:
blob - string; Hexadecimal blob of block information.
json - json string; JSON formatted block details:
major_version - Same as in block header.
minor_version - Same as in block header.
timestamp - Same as in block header.
prev_id - Same as prev_hash in block header.
nonce - Same as in block header.
miner_tx - Miner transaction information
version - Transaction version number.
unlock_time - The block height when the coinbase transaction becomes spendable.
vin - List of transaction inputs:
gen - Miner txs are coinbase txs, or "gen".
height - This block height, a.k.a. when the coinbase is generated.
vout - List of transaction outputs. Each output contains:
amount - The amount of the output, in atomic units.
target -
key -
extra - Usually called the "transaction ID" but can be used to include any random 32 byte/64 character hex string.
signatures - Contain signatures of tx signers. Coinbased txs do not have signatures.
tx_hashes - List of hashes of non-coinbase transactions in the block. If there are no other transactions, this will be an empty list.
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
Look up by height:
In the following example, block 912345 is looked up by its height. Note that block 912345 does not have any non-coinbase transactions. (See the next example for a block with extra transactions):
Look up by hash:
In the following example, block 993056 is looked up by its hash. Note that block 993056 has 3 non-coinbase transactions:
Retrieve information about incoming and outgoing connections to your node.
Alias: None.
Inputs: None.
Outputs:
connections - List of all connections and their info:
address - string; The peer's address, actually IPv4 & port
avg_download - unsigned int; Average bytes of data downloaded by node.
avg_upload - unsigned int; Average bytes of data uploaded by node.
connection_id - string; The connection ID
current_download - unsigned int; Current bytes downloaded by node.
current_upload - unsigned int; Current bytes uploaded by node.
height- unsigned int; The peer height
host - string; The peer host
incoming - boolean; Is the node getting information from your node?
ip - string; The node's IP address.
live_time - unsigned int
local_ip - boolean
localhost - boolean
peer_id - string; The node's ID on the network.
port - string; The port that the node is using to connect to the network.
recv_count - unsigned int
recv_idle_time - unsigned int
send_count - unsigned int
send_idle_time - unsigned int
state - string
support_flags - unsigned int
Following is an example of get_connections and it's return:
Retrieve general information about the state of your node and the network.
Alias:
/get_info
/getinfo
Inputs: None.
Outputs:
alt_blocks_count - unsigned int; Number of alternative blocks to main chain.
block_size_limit - unsigned int; Maximum allowed block size
block_size_median - unsigned int; Median block size of latest 100 blocks
bootstrap_daemon_address - string;
cumulative_difficulty - unsigned int; Cumulative difficulty of all blocks in the blockchain.
difficulty - unsigned int; Network difficulty (analogous to the strength of the network)
free_space - unsigned int; Available disk space on the node.
grey_peerlist_size - unsigned int; Grey Peerlist Size
height - unsigned int; Current length of longest chain known to daemon.
height_without_bootstrap - unsigned int; Current length of the local chain of the daemon.
incoming_connections_count - unsigned int; Number of peers connected to and pulling from your node.
mainnet - boolean; States if the node is on the mainnet (true) or not (false).
offline - boolean; States if the node is offline (true) or online (false).
outgoing_connections_count - unsigned int; Number of peers that you are connected to and getting information from.
rpc_connections_count - unsigned int; Number of RPC client connected to the daemon (Including this RPC request).
stagenet - boolean; States if the node is on the stagenet (true) or not (false).
start_time - unsigned int; Start time of the daemon, as UNIX time.
status - string; General RPC error code. "OK" means everything looks good.
target - unsigned int; Current target for next proof of work.
target_height - unsigned int; The height of the next block in the chain.
testnet - boolean; States if the node is on the testnet (true) or not (false).
top_block_hash - string; Hash of the highest block in the chain.
tx_count - unsigned int; Total number of non-coinbase transaction in the chain.
tx_pool_size - unsigned int; Number of transactions that have been broadcast but not included in a block.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
was_bootstrap_ever_used - boolean; States if a bootstrap node has ever been used since the daemon started.
white_peerlist_size - unsigned int; White Peerlist Size
Following is an example get_info call and its return:
Look up information regarding hard fork voting and readiness.
Alias: None.
Inputs: None.
Outputs:
earliest_height - unsigned int; Block height at which hard fork would be enabled if voted in.
enabled - boolean; Tells if hard fork is enforced.
state - unsigned int; Current hard fork state: 0 (There is likely a hard fork), 1 (An update is needed to fork properly), or 2 (Everything looks good).
status - string; General RPC error code. "OK" means everything looks good.
threshold - unsigned int; Minimum percent of votes to trigger hard fork. Default is 80.
version - unsigned int; The major block version for the fork.
votes - unsigned int; Number of votes towards hard fork.
voting - unsigned int; Hard fork voting status.
window - unsigned int; Number of blocks over which current votes are cast. Default is 10080 blocks.
Example:
Ban another node by IP.
Alias: None.
Inputs:
bans - A list of nodes to ban:
host - string; Host to ban (IP in A.B.C.D form - will support I2P address in the future).
ip - unsigned int; IP address to ban, in Int format.
ban - boolean; Set true to ban.
seconds - unsigned int; Number of seconds to ban node.
Outputs:
status - string; General RPC error code. "OK" means everything looks good.
Examples:
banning by host
In the following example, host is banned with its IP address string-formatted as A.B.C.D:
banning by ip
In the following example, integer-formatted IP is banned:
Get list of banned IPs.
Alias: None.
Inputs: None.
Outputs:
bans - List of banned nodes:
host - string; Banned host (IP in A.B.C.D form).
ip - unsigned int; Banned IP address, in Int format.
seconds - unsigned int; Local Unix time that IP is banned until.
status - string; General RPC error code. "OK" means everything looks good.
Example:
Flush tx ids from transaction pool
Alias: None.
Inputs:
txids - array of strings; Optional, list of transactions IDs to flush from pool (all tx ids flushed if empty).
Outputs:
status - string; General RPC error code. "OK" means everything looks good.
Example:
Get a histogram of output amounts. For all amounts (possibly filtered by parameters), gives the number of outputs on the chain for that amount. RingCT outputs counts as 0 amount.
Inputs:
amounts - list of unsigned int
min_count - unsigned int
max_count - unsigned int
unlocked - boolean
recent_cutoff - unsigned int
Outputs:
histogram - list of histogram entries, in the following structure:
amount - unsigned int; Output amount in atomic units
total_instances - unsigned int;
unlocked_instances - unsigned int;
recent_instances - unsigned int;
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
Example:
Get the coinbase ammount and the fees ammount for n last blocks starting at particular height
Alias: None.
Inputs:
height - unsigned int; Block height from which getting the amounts
count - unsigned int; number of blocks to include in the sum
Outputs:
emission_amount - unsigned int; amount of coinbase reward in atomic units
fee_amount - unsigned int; amount of fees in atomic units
status - string; General RPC error code. "OK" means everything looks good.
Example:
Give the node current version
Alias: None.
Inputs: None.
Outputs:
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
version - unsigned int;
Example:
Gives an estimation on fees per kB.
Alias: None.
Inputs:
grace_blocks - unsigned int; Optional
Outputs:
fee - unsigned int; Amount of fees estimated per kB in atomic units
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
Example:
Display alternative chains seen by the node.
Alias: None.
Inputs: None.
Outputs:
chains - array of chains, the following structure:
block_hash - string; the block hash of the first diverging block of this alternative chain.
difficulty - unsigned int; the cumulative difficulty of all blocks in the alternative chain.
height - unsigned int; the block height of the first diverging block of this alternative chain.
length - unsigned int; the length in blocks of this alternative chain, after divergence.
status - string; General RPC error code. "OK" means everything looks good.
Example:
Relay a list of transaction IDs.
Alias: None.
Inputs:
txids - array of string; list of transaction IDs to relay
Outputs:
status - string; General RPC error code. "OK" means everything looks good.
Example:
Get synchronisation informations
Alias: None.
Inputs: None.
Outputs:
height - unsigned int;
peers - array of peer structure, defined as follows:
spans - array of span structure, defined as follows (optional, absent if node is fully synced):
connection_id - string; Id of connection
nblocks - unsigned int; number of blocks in that span
rate - unsigned int; connection rate
remote_address - string; peer address the node is downloading (or has downloaded) than span from
size - unsigned int; total number of bytes in that span's blocks (including txes)
speed - unsigned int; connection speed
start_block_height - unsigned int; block height of the first block in that span
status - string; General RPC error code. "OK" means everything looks good.
target_height - unsigned int; target height the node is syncing from (optional, absent if node is fully synced)
Example:
Get all transaction pool backlog
Alias: None.
Inputs: None.
Outputs:
backlog: array of structures tx_backlog_entry (in binary form):
blob_size - unsigned int (in binary form)
fee - unsigned int (in binary form)
time_in_pool - unsigned int (in binary form)
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
Example:
Alias: None.
Inputs:
amounts - array of unsigned int; amounts to look for
cumulative - boolean; (optional, default is false) States if the result should be cumulative (true) or not (false)
from_height - unsigned int; (optional, default is 0) starting height to check from
to_height - unsigned int; (optional, default is 0) ending height to check up to
Outputs:
distributions - array of structure distribution as follows:
amount - unsigned int
base - unsigned int
distribution - array of unsigned int
start_height - unsigned int
status - string; General RPC error code. "OK" means everything looks good.
Example:
Retrieve details using the name hash of the corresponding BNS name.
Alias: None.
Inputs:
entries - array of string; Entries to look up.
include_expired - boolean; (Optional) If provided and true, include entries in the results even if they are expired.
Outputs:
entry_index - The index in request_entry's `entries` array that was resolved via Beldex Name Service.
name_hash - The hash of the name that was queried, in base64.
owner - The address that purchased the BNS.
backup_owner - Address of the backup owner. Omitted if no backup owner.
encrypted_bchat_value - The encrypted bchat value.
encrypted_wallet_value - The encrypted wallet value.
encrypted_belnet_value - The encrypted belnet value.
encrypted_eth_addr_value - The encrypted eth address value.
update_height - The last height that this Beldex Name Service entry was updated on the Blockchain.
expiration_height - For records that expire, this will be set to the expiration block height.
tx_id - The txid of the mapping's most recent update or purchase.
Example:
Retrieve information based on the address of the BNS-owned wallets.
Alias: None.
Inputs:
entries - array of string; The owner's address to find all Beldex Name Service entries.
include_expired - boolean; (Optional) If provided and true, include entries in the results even if they are expired.
Outputs:
request_index - The index in request's `entries` array that was resolved via Beldex Name Service.
name_hash - The hash of the name that was queried, in base64.
owner - The address that purchased the BNS.
backup_owner - Address of the backup owner. Omitted if no backup owner.
encrypted_bchat_value - The encrypted bchat value.
encrypted_wallet_value - The encrypted wallet value.
encrypted_belnet_value - The encrypted belnet value.
encrypted_eth_addr_value - The encrypted eth address value.
update_height - The last height that this Beldex Name Service entry was updated on the Blockchain.
expiration_height - For records that expire, this will be set to the expiration block height.
tx_id - The txid of the mapping's most recent update or purchase.
Example:
Retrieve the encrypted value based on the specified type and nonce.
Alias: None.
Inputs:
type - uint16_t; The BNS type (mandatory); supported values are: 0 = bchat, 1 = wallet, 2 = belnet.
name_hash - string; The 32-byte BLAKE2b hash of the name to look up, encoded as 64 hex digits or 44/43 base64 characters (with/without padding).
Outputs:
encrypted_value - The encrypted BNS value, in hex.
nonce - The nonce value used for encryption, in hex.
Example:
Decrypt the BNS value corresponding to the provided encrypted value.
Alias: None.
Input:
name - string; The BNS name with which to encrypt the value.
type - string; The mapping type: "bchat" or "belnet" or "wallet".
encrypted_value - string; The encrypted value represented in hex.
Output:
value - The decrypted value.
Example:
Not all daemon RPC calls use the JSON_RPC interface. This section gives examples of these calls.
The data structure for these calls is different than the JSON RPC calls. Whereas the JSON RPC methods were called using the /json_rpc extension and specifying a method, these methods are called at their own extensions. For example:
For calls that end with .bin, the data is exchanged in the form of binary, serialized objects, as defined in the Core RPC Server.
Get the node's current height.
Alias: /getheight.
Inputs: None.
Outputs:
height - unsigned int; Current length of longest chain known to daemon.
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
Get all blocks info. Binary request.
Alias: /getblocks.bin.
Inputs:
block_ids - binary array of hashes; first 10 blocks id goes sequential, next goes in pow(2,n) offset, like 2, 4, 8, 16, 32, 64 and so on, and the last one is always genesis block
start_height - unsigned int
prune - boolean
Outputs:
blocks - array of block complete entries
current_height - unsigned int
output_indices - structure as follows:
indices - array of tx output indices, structure as follows:
indices - array of unsigned int
start_height - unsigned int
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
Get blocks by height. Binary request.
Alias: /getblocks_by_height.bin.
Inputs:
heights - array of unsigned int; list of block heights
Outputs:
blocks - array of block complete entries
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
Get hashes. Binary request.
Alias: /gethashes.bin.
Inputs:
block_ids - binary array of hashes; first 10 blocks id goes sequential, next goes in pow(2,n) offset, like 2, 4, 8, 16, 32, 64 and so on, and the last one is always genesis block
start_height - unsigned int
Outputs:
current_height - unsigned int
m_block_ids - binary array of hashes; see block_ids above.
start_height - unsigned int
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
Get global outputs of transactions. Binary request.
Alias: None.
Inputs:
txid - binary txid
Outputs:
o_indexes - array of unsigned int; List of output indexes
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
Get outputs. Binary request.
Alias: None.
Inputs:
outputs - array of structure get_outputs_out as follows:
amount - unsigned int;
index - unsigned int;
Outputs:
outs - array of structure outkey as follows:
amount - unsigned int;
height - unsigned int; block height of the output
key - the public key of the output
mask
txid - transaction id
unlocked - boolean; States if output is locked (false) or not (true)
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
Look up one or more transactions by hash.
Alias: /gettransactions.
Inputs:
txs_hashes - string list; List of transaction hashes to look up.
decode_as_json - boolean; Optional (false by default). If set true, the returned transaction information will be decoded rather than binary.
prune - boolean; Optional (false by default).
Outputs:
missed_tx - array of strings. (Optional - returned if not empty) Transaction hashes that could not be found.
status - General RPC error code. "OK" means everything looks good.
txs - array of structure entry as follows:
as_hex - string; Full transaction information as a hex string.
as_json - json string; List of transaction info:
version - Transaction version
unlock_time - If not 0, this tells when a transaction output is spendable.
vin - List of inputs into transaction:
key - The public key of the previous output spent in this transaction.
amount - The amount of the input, in atomic units.
key_offsets - A list of integer offets to the input.
k_image - The key image for the given input
vout - List of outputs from transaction:
amount - Amount of transaction output, in atomic units.
target - Output destination information:
key - The stealth public key of the receiver. Whoever owns the private key associated with this key controls this transaction output.
extra - Usually called the "payment ID" but can be used to include any random 32 bytes.
signatures - List of signatures used in ring signature to hide the true origin of the transaction.
block_height - unsigned int; block height including the transaction
block_timestamp - unsigned int; Unix time at chich the block has been added to the blockchain
double_spend_seen - boolean; States if the transaction is a double-spend (true) or not (false)
in_pool - boolean; States if the transaction is in pool (true) or included in a block (false)
output_indices - array of unsigned int; transaction indexes
tx_hash - string; transaction hash
txs_as_hex - string; Full transaction information as a hex string (old compatibility parameter)
txs_as_json - json string; (Optional - returned if set in inputs. Old compatibility parameter) List of transaction as in as_json above:
Example 1: Return transaction information in binary format.
Example 2: Decode returned transaction information in JSON format. Note: the "vin", "vout" and "signatures" list have been truncated in the displayed return for space considerations.
Example 3: Returned a missed (unexisting) transaction.
Get the known blocks hashes which are not on the main chain.
Alias: None.
Inputs: None
Outputs:
blks_hashes - array of strings; list of alternative blocks hashes to main chain
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
Example:
Check if outputs have been spent using the key image associated with the output.
Alias: None.
Inputs:
key_images - string list; List of key image hex strings to check.
Outputs:
spent_status - unsigned int list; List of statuses for each image checked. Statuses are follows: 0 = unspent, 1 = spent in blockchain, 2 = spent in transaction pool
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
Example:
Broadcast a raw transaction to the network.
Alias: /sendrawtransaction.
Inputs:
tx_as_hex - string; Full transaction information as hexidecimal string.
do_not_relay - boolean; Stop relaying transaction to other nodes (default is false).
Outputs:
double_spend - boolean; Transaction is a double spend (true) or not (false).
fee_too_low - boolean; Fee is too low (true) or OK (false).
invalid_input - boolean; Input is invalid (true) or valid (false).
invalid_output - boolean; Output is invalid (true) or valid (false).
low_mixin - boolean; Mixin count is too low (true) or OK (false).
not_rct - boolean; Transaction is a standard ring transaction (true) or a ring confidential transaction (false).
not_relayed - boolean; Transaction was not relayed (true) or relayed (false).
overspend - boolean; Transaction uses more money than available (true) or not (false).
reason - string; Additional information. Currently empty or "Not relayed" if transaction was accepted but not relayed.
status - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.
too_big - boolean; Transaction size is too big (true) or OK (false).
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
Example (No return information included here.):
Start mining on the daemon.
Alias: None.
Inputs:
do_background_mining - boolean; States if the mining should run in background (true) or foreground (false).
ignore_battery - boolean; States if batery state (on laptop) should be ignored (true) or not (false).
miner_address - string; Account address to mine to.
threads_count - unsigned int; Number of mining thread to run.
Outputs:
status - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.
Example:
Stop mining on the daemon.
Alias: None.
Inputs: None.
Outputs:
status - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.
Example:
Get the mining status of the daemon.
Alias: None.
Inputs: None.
Outputs:
active - boolean; States if mining is enabled (true) or disabled (false).
address - string; Account address daemon is mining to. Empty if not mining.
is_background_mining_enabled - boolean; States if the mining is running in background (true) or foreground (false).
speed - unsigned int; Mining power in hashes per seconds.
status - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.
threads_count - unsigned int; Number of running mining threads.
Example while mining:
Example while not mining:
Save the blockchain. The blockchain does not need saving and is always saved when modified, however it does a sync to flush the filesystem cache onto the disk for safety purposes against Operating System or Harware crashes.
Alias: None.
Inputs: None.
Outputs:
status - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.
Example:
Get the known peers list.
Alias: None.
Inputs: None.
Outputs:
gray_list - array of offline peer structure as follows:
host - unsigned int; IP address in integer format
id - string; Peer id
ip - unsigned int; IP address in integer format
last_seen - unsigned int; unix time at which the peer has been seen for the last time
port - unsigned int; TCP port the peer is using to connect to beldex network.
status - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.
white_list - array of online peer structure, as above.
Example (truncated lists):
Set the log hash rate display mode.
Alias: None.
Inputs:
visible - boolean; States if hash rate logs should be visible (true) or hidden (false)
Outputs:
status - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.
Example while mining:
Error while not mining:
Set the daemon log level. By default, log level is set to 0.
Alias: None.
Inputs:
level - integer; daemon log level to set from 0 (less verbose) to 4 (most verbose)
Outputs:
status - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.
Example:
Set the daemon log categories. Categories are represented as a comma separated list of <Category>:<level> (similarly to syslog standard <Facility>:<Severity-level>), where:
Category is one of the following:
* - All facilities
default
net
net.http
net.p2p
logging
net.throttle
blockchain.db
blockchain.db.lmdb
bcutil
checkpoints
net.dns
net.dl
i18n
perf
stacktrace
updates
account
cn
difficulty
hardfork
miner
blockchain
txpool
cn.block_queue
net.cn
daemon
debugtools.deserialize
debugtools.objectsizes
device.ledger
wallet.gen_multisig
multisig
bulletproofs
ringct
daemon.rpc
wallet.simplewallet
WalletAPI
wallet.ringdb
wallet.wallet2
wallet.rpc
tests.core
Level is one of the following:
FATAL - higher level
ERROR
WARNING
INFO
DEBUG
TRACE - lower level A level automatically includes higher level. By default, categories are set to *:WARNING,net:FATAL,net.p2p:FATAL,net.cn:FATAL,global:INFO,verify:FATAL,stacktrace:INFO,logging:INFO,msgwriter:INFO. Setting the categories to "" prevent any logs to be outputed.
Alias: None.
Inputs:
categories - string; Optional, daemon log categories to enable
Outputs:
categories - string; daemon log enabled categories
status - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.
Example to set all facilities to Security Level Info:
Example without input to set the default categories:
Show information about valid transactions seen by the node but not yet mined into a block, as well as spent key image information for the txpool in the node's memory.
Alias: None.
Inputs: None.
Outputs:
spent_key_images - List of spent output key images:
id_hash - string; Key image.
txs_hashes - string list; tx hashes of the txes (usually one) spending that key image.
status - string; General RPC error code. "OK" means everything looks good.
transactions - List of transactions in the mempool are not in a block on the main chain at the moment:
blob_size - unsigned int; The size of the full transaction blob.
double_spend_seen - boolean; States if this transaction has been seen as double spend.
do_not_relay; boolean; States if this transaction should not be relayed
fee - unsigned int; The amount of the mining fee included in the transaction, in atomic units.
id_hash - string; The transaction ID hash.
kept_by_block - boolean; States if the tx was included in a block at least once (true) or not (false).
last_failed_height - unsigned int; If the transaction validation has previously failed, this tells at what height that occured.
last_failed_id_hash - string; Like the previous, this tells the previous transaction ID hash.
last_relayed_time - unsigned int; Last unix time at which the transaction has been relayed.
max_used_block_height - unsigned int; Tells the height of the most recent block with an output used in this transaction.
max_used_block_hash - string; Tells the hash of the most recent block with an output used in this transaction.
receive_time - unsigned int; The Unix time that the transaction was first seen on the network by the node.
relayed - boolean; States if this transaction has been relayed
tx_blob - unsigned int; Hexadecimal blob represnting the transaction.
tx_json - json string; JSON structure of all information in the transaction:
version - Transaction version
unlock_time - If not 0, this tells when a transaction output is spendable.
vin - List of inputs into transaction:
key - The public key of the previous output spent in this transaction.
amount - The amount of the input, in atomic units.
key_offsets - A list of integer offets to the input.
k_image - The key image for the given input
vout - List of outputs from transaction:
amount - Amount of transaction output, in atomic units.
target - Output destination information:
key - The stealth public key of the receiver. Whoever owns the private key associated with this key controls this transaction output.
extra - Usually called the "transaction ID" but can be used to include any random 32 bytses.
rct_signatures - Ring signatures:
type
txnFee
ecdhInfo - array of Diffie Helman Elipctic curves structures as follows:
mask - String
amount - String
outPk
rctsig_prunable
rangeSigs - array of structures as follows:
asig
Ci
MGs - array of structures as follows:
ss - array of arrays of two strings.
cc - String
Example (Note: Some lists in the returned information have been truncated for display reasons):
Get hashes from transaction pool. Binary request.
Alias: None.
Inputs: None.
Outputs:
status - string; General RPC error code. "OK" means everything looks good.
tx_hashes - binary array of transaction hashes.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
Example:
Get the transaction pool statistics.
Alias: None.
Inputs: None.
Outputs:
pool_stats - Structure as follows:
bytes_max - unsigned int; Max transaction size in pool
bytes_med - unsigned int; Median transaction size in pool
bytes_min - unsigned int; Min transaction size in pool
bytes_total - unsigned int; total size of all transactions in pool
histo - structure txpool_histo as follows:
txs - unsigned int; number of transactions
bytes - unsigned int; size in bytes.
histo_98pc unsigned int; the time 98% of txes are "younger" than
num_10m unsigned int; number of transactions in pool for more than 10 minutes
num_double_spends unsigned int; number of double spend transactions
num_failing unsigned int; number of failing transactions
num_not_relayed unsigned int; number of non-relayed transactions
oldest unsigned int; unix time of the oldest transaction in the pool
txs_total unsigned int; total number of transactions.
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
Example:
Send a command to the daemon to safely disconnect and shut down.
Alias: None.
Inputs: None.
Outputs:
status - string; General RPC error code. "OK" means everything looks good.
Example:
Alias:
/getinfo
get_info
Get daemon bandwidth limits.
Alias: None.
Inputs: None.
Outputs:
limit_down - unsigned int; Download limit in kBytes per second
limit_up - unsigned int; Upload limit in kBytes per second
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
Example:
Set daemon bandwidth limits.
Alias: None.
Inputs:
limit_down - signed int; Download limit in kBytes per second (-1 reset to default, 0 don't change the current limit)
limit_up - signed int; Upload limit in kBytes per second (-1 reset to default, 0 don't change the current limit)
Outputs:
limit_down - unsigned int; Download limit in kBytes per second
limit_up - unsigned int; Upload limit in kBytes per second
status - string; General RPC error code. "OK" means everything looks good.
Example:
Limit number of Outgoing peers.
Alias: None.
Inputs:
out_peers - unsigned int; Max number of outgoing peers
Outputs:
status - string; General RPC error code. "OK" means everything looks good.
Example:
Limit number of Incoming peers.
Alias: None.
Inputs:
in_peers - unsigned int; Max number of incoming peers
Outputs:
status - string; General RPC error code. "OK" means everything looks good.
Example:
Obsolete. Conserved here for reference.
Alias: None.
Inputs: None.
Outputs:
status - string; General RPC error code. "OK" means everything looks good.
Example:
Obsolete. Conserved here for reference.
Alias: None.
Inputs: None.
Outputs:
status - string; General RPC error code. "OK" means everything looks good.
Example:
Get outputs.
Alias: None.
Inputs:
outputs array of get_outputs_out structure as follows:
amount - unsigned int;
index - unsigned int;
Outputs:
outs - array of structure outkey as follows:
height - unsigned int; block height of the output
key - String; the public key of the output
mask - String
txid - String; transaction id
unlocked - boolean; States if output is locked (false) or not (true)
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
Update daemon.
Alias: None.
Inputs:
command - String; command to use, either check or download
path - String; Optional, path where to download the update.
Outputs:
auto_uri - string;
hash - string;
path - String; path to download the update
status - string; General RPC error code. "OK" means everything looks good.
update - boolean; States if an update is available to download (true) or not (false)
user_uri - string;
version - string; Version available for download.
Example:
Block blob data - array of strings; list of block blobs which have been mined. See to get a blob on which to mine.
block_header - A structure containing block header information. See .
Similar to above, this method includes a block's height as an input parameter to retrieve basic information about the block.
block_header - A structure containing block header information. See .
Similar to above, but for a range of blocks. This method includes a starting block height and an ending block height as parameters to retrieve basic information about the range of blocks.
headers - array of block_header (a structure containing block header information. See ).
block_header - A structure containing block header information. See .
See other RPC Methods
info - structure of connection info, as defined in
Note: It is recommended to use JSON RPC where such alternatives exist, rather than the following methods. For example, the recommended way to get a node's height is via the JSON RPC methods or , rather than below.
This method is a convenient backward support and should not be used anymore. See JSON RPC for details.
Reworked from RPC calls for Beldex under their .
This is a list of the beldex-wallet-rpc calls, their inputs and outputs, and examples of each. The program beldex-wallet-rpc replaced the rpc interface that was in simplewallet and then beldex-wallet-cli.
All beldex-wallet-rpc methods use the same JSON RPC interface. For example:
If the beldex-wallet-rpc was executed with the --rpc-login argument as username:password, then follow this example:
Note: "atomic units" refer to the smallest fraction of 1 BDX according to the beldexd implementation. 1 BDX = 1e9 atomic units.
Return the wallet's balance.
Alias: getbalance.
Inputs:
account_index - unsigned int; Return balance for this account.
address_indices - array of unsigned int; (Optional) Return balance detail for those subaddresses.
Outputs:
balance - unsigned int; The total balance of the current beldex-wallet-rpc in session.
unlocked_balance - unsigned int; Unlocked funds are those funds that are sufficiently deep enough in the beldex blockchain to be considered safe to spend.
multisig_import_needed - boolean; True if importing multisig data is needed for returning a correct balance.
per_subaddress - array of subaddress information; Balance information for each subaddress in an account.
address_index - unsigned int; Index of the subaddress in the account.
address - string; Address at this index. Base58 representation of the public keys.
balance - unsigned int; Balance for the subaddress (locked or unlocked).
unlocked_balance - unsigned int; Unlocked balance for the subaddress.
label - string; Label for the subaddress.
num_unspent_outputs - unsigned int; Number of unspent outputs available for the subaddress.
Example:
Return the wallet's addresses for an account. Optionally filter for specific set of subaddresses.
Alias: getaddress.
Inputs:
account_index - unsigned int; Return subaddresses for this account.
address_index - array of unsigned int; (Optional) List of subaddresses to return from an account.
Outputs:
address - string; The 95-character hex address string of the beldex-wallet-rpc in session.
addresses array of addresses informations
address string; The 95-character hex (sub)address string.
label string; Label of the (sub)address
address_index unsigned int; index of the subaddress
used boolean; states if the (sub)address has already received funds
Example:
Get account and address indexes from a specific (sub)address
Alias: None.
Inputs:
address - String; (sub)address to look for.
Outputs:
index - subaddress informations
major unsigned int; Account index.
minor unsigned int; Address index.
Example:
Create a new address for an account. Optionally, label the new address.
Alias: None.
Inputs:
account_index - unsigned int; Create a new address for this account.
label - string; (Optional) Label for the new address.
Outputs:
address - string; Newly created address. Base58 representation of the public keys.
address_index - unsigned int; Index of the new address under the input account.
Example:
Label an address.
Alias: None.
Inputs:
index - subaddress index; JSON Object containing the major & minor address index:
major - unsigned int; Account index for the subaddress.
minor - unsigned int; Index of the subaddress in the account.
label - string; Label for the address.
Outputs: None.
Example:
Get all accounts for a wallet. Optionally filter accounts by tag.
Alias: None.
Inputs:
tag - string; (Optional) Tag for filtering accounts.
Outputs:
subaddress_accounts - array of subaddress account information:
account_index - unsigned int; Index of the account.
balance - unsigned int; Balance of the account (locked or unlocked).
base_address - string; Base64 representation of the first subaddress in the account.
label - string; (Optional) Label of the account.
tag - string; (Optional) Tag for filtering accounts.
unlocked_balance - unsigned int; Unlocked balance for the account.
total_balance - unsigned int; Total balance of the selected accounts (locked or unlocked).
total_unlocked_balance - unsigned int; Total unlocked balance of the selected accounts.
Example:
Create a new account with an optional label.
Alias: None.
Inputs:
label - string; (Optional) Label for the account.
Outputs:
account_index - unsigned int; Index of the new account.
address - string; Address for this account. Base58 representation of the public keys.
Example:
Label an account.
Alias: None.
Inputs:
account_index - unsigned int; Apply label to account at this index.
label - string; Label for the account.
Outputs: None.
Example:
Get a list of user-defined account tags.
Alias: None.
Inputs: None.
Outputs:
account_tags - array of account tag information:
tag - string; Filter tag.
label - string; Label for the tag.
accounts - array of int; List of tagged account indices.
Example:
Apply a filtering tag to a list of accounts.
Alias: None.
Inputs:
tag - string; Tag for the accounts.
accounts - array of unsigned int; Tag this list of accounts.
Outputs: None.
Example:
Remove filtering tag from a list of accounts.
Alias: None.
Inputs:
accounts - array of unsigned int; Remove tag from this list of accounts.
Outputs: None.
Example:
Set description for an account tag.
Alias: None.
Inputs:
tag - string; Set a description for this tag.
description - string; Description for the tag.
Outputs: None.
Example:
Returns the wallet's current block height.
Alias: getheight.
Inputs: None.
Outputs:
height - unsigned int; The current beldex-wallet-rpc's blockchain height. If the wallet has been offline for a long time, it may need to catch up with the daemon.
Example:
Send beldex to a number of recipients.
Alias: None.
Inputs:
destinations - array of destinations to receive BDX:
amount - unsigned int; Amount to send to each destination, in atomic units.
address - string; Destination public address.
account_index - unsigned int; (Optional) Transfer from this account index. (Defaults to 0)
subaddr_indices - array of unsigned int; (Optional) Transfer from this set of subaddresses. (Defaults to 0)
priority - unsigned int; Set a priority for the transaction. Accepted Values are: 0 and 1 for: flash and unimportant.
mixin - unsigned int; Number of outputs from the blockchain to mix with (0 means no mixing).
ring_size - unsigned int; Number of outputs to mix in the transaction (this output + N decoys from the blockchain).
unlock_time - unsigned int; Number of blocks before the beldex can be spent (0 to not add a lock).
payment_id - string; (Optional) Random 32-byte/64-character hex string to identify a transaction.
get_tx_key - boolean; (Optional) Return the transaction key after sending.
do_not_relay - boolean; (Optional) If true, the newly created transaction will not be relayed to the beldex network. (Defaults to false)
get_tx_hex - boolean; Return the transaction as hex string after sending (Defaults to false)
get_tx_metadata - boolean; Return the metadata needed to relay the transaction. (Defaults to false)
Outputs:
amount - Amount transferred for the transaction.
fee - Integer value of the fee charged for the txn.
multisig_txset - Set of multisig transactions in the process of being signed (empty for non-multisig).
tx_blob - Raw transaction represented as hex string, if get_tx_hex is true.
tx_hash - String for the publically searchable transaction hash.
tx_key - String for the transaction key if get_tx_key is true, otherwise, blank string.
tx_metadata - Set of transaction metadata needed to relay this transfer later, if get_tx_metadata is true.
unsigned_txset - String. Set of unsigned tx for cold-signing purposes.
Example:
Same as transfer, but can split into more than one tx if necessary.
Alias: None.
Inputs:
destinations - array of destinations to receive BDX:
amount - unsigned int; Amount to send to each destination, in atomic units.
address - string; Destination public address.
account_index - unsigned int; (Optional) Transfer from this account index. (Defaults to 0)
subaddr_indices - array of unsigned int; (Optional) Transfer from this set of subaddresses. (Defaults to 0)
mixin - unsigned int; Number of outputs from the blockchain to mix with (0 means no mixing).
ring_size - unsigned int; Sets ringsize to n (mixin + 1).
unlock_time - unsigned int; Number of blocks before the beldex can be spent (0 to not add a lock).
payment_id - string; (Optional) Random 32-byte/64-character hex string to identify a transaction.
get_tx_keys - boolean; (Optional) Return the transaction keys after sending.
priority - unsigned int; Set a priority for the transactions. Accepted Values are: 0-3 for: default, unimportant, normal, elevated, priority.
do_not_relay - boolean; (Optional) If true, the newly created transaction will not be relayed to the beldex network. (Defaults to false)
get_tx_hex - boolean; Return the transactions as hex string after sending
new_algorithm - boolean; True to use the new transaction construction algorithm, defaults to false.
get_tx_metadata - boolean; Return list of transaction metadata needed to relay the transfer later.
Outputs:
tx_hash_list - array of: string. The tx hashes of every transaction.
tx_key_list - array of: string. The transaction keys for every transaction.
amount_list - array of: integer. The amount transferred for every transaction.
fee_list - array of: integer. The amount of fees paid for every transaction.
tx_blob_list - array of: string. The tx as hex string for every transaction.
tx_metadata_list - array of: string. List of transaction metadata needed to relay the transactions later.
multisig_txset - string. The set of signing keys used in a multisig transaction (empty for non-multisig).
unsigned_txset - string. Set of unsigned tx for cold-signing purposes.
Example:
Sign a transaction created on a read-only wallet (in cold-signing process)
Alias: None.
Inputs:
unsigned_txset - string. Set of unsigned tx returned by "transfer" or "transfer_split" methods.
export_raw - boolean; (Optional) If true, return the raw transaction data. (Defaults to false)
Outputs:
signed_txset - string. Set of signed tx to be used for submitting transfer.
tx_hash_list - array of: string. The tx hashes of every transaction.
tx_raw_list - array of: string. The tx raw data of every transaction.
In the example below, we first generate an unsigned_txset on a read only wallet before signing it:
Generate unsigned_txset using the above "transfer" method on read-only wallet:
Sign tx using the previously generated unsigned_txset
Submit a previously signed transaction on a read-only wallet (in cold-signing process).
Alias: None.
Inputs:
tx_data_hex - string; Set of signed tx returned by "sign_transfer"
Outputs:
tx_hash_list - array of: string. The tx hashes of every transaction.
In the example below, we submit the transfer using the signed_txset generated above:
Send all dust outputs back to the wallet's, to make them easier to spend (and mix).
Alias: sweep_unmixable.
Inputs:
get_tx_keys - boolean; (Optional) Return the transaction keys after sending.
do_not_relay - boolean; (Optional) If true, the newly created transaction will not be relayed to the beldex network. (Defaults to false)
get_tx_hex - boolean; (Optional) Return the transactions as hex string after sending. (Defaults to false)
get_tx_metadata - boolean; (Optional) Return list of transaction metadata needed to relay the transfer later. (Defaults to false)
Outputs:
tx_hash_list - array of: string. The tx hashes of every transaction.
tx_key_list - array of: string. The transaction keys for every transaction.
amount_list - array of: integer. The amount transferred for every transaction.
fee_list - array of: integer. The amount of fees paid for every transaction.
tx_blob_list - array of: string. The tx as hex string for every transaction.
tx_metadata_list - array of: string. List of transaction metadata needed to relay the transactions later.
multisig_txset - string. The set of signing keys used in a multisig transaction (empty for non-multisig).
unsigned_txset - string. Set of unsigned tx for cold-signing purposes.
Example (In this example, sweep_dust returns nothing because there are no funds to sweep):
Send all unlocked balance to an address.
Alias: None.
Inputs:
address - string; Destination public address.
account_index - unsigned int; Sweep transactions from this account.
subaddr_indices - array of unsigned int; (Optional) Sweep from this set of subaddresses in the account.
priority - unsigned int; (Optional) Priority for sending the sweep transfer, partially determines fee.
mixin - unsigned int; Number of outputs from the blockchain to mix with (0 means no mixing).
ring_size - unsigned int; Sets ringsize to n (mixin + 1).
unlock_time - unsigned int; Number of blocks before the beldex can be spent (0 to not add a lock).
payment_id - string; (Optional) Random 32-byte/64-character hex string to identify a transaction.
get_tx_keys - boolean; (Optional) Return the transaction keys after sending.
below_amount - unsigned int; (Optional) Include outputs below this amount.
do_not_relay - boolean; (Optional) If true, do not relay this sweep transfer. (Defaults to false)
get_tx_hex - boolean; (Optional) return the transactions as hex encoded string. (Defaults to false)
get_tx_metadata - boolean; (Optional) return the transaction metadata as a string. (Defaults to false)
Outputs:
tx_hash_list - array of: string. The tx hashes of every transaction.
tx_key_list - array of: string. The transaction keys for every transaction.
amount_list - array of: integer. The amount transferred for every transaction.
fee_list - array of: integer. The amount of fees paid for every transaction.
tx_blob_list - array of: string. The tx as hex string for every transaction.
tx_metadata_list - array of: string. List of transaction metadata needed to relay the transactions later.
multisig_txset - string. The set of signing keys used in a multisig transaction (empty for non-multisig).
unsigned_txset - string. Set of unsigned tx for cold-signing purposes.
Example:
Send all of a specific unlocked output to an address.
Alias: None.
Inputs:
address - string; Destination public address.
account_index - unsigned int; Sweep transactions from this account.
subaddr_indices - array of unsigned int; (Optional) Sweep from this set of subaddresses in the account.
priority - unsigned int; (Optional) Priority for sending the sweep transfer, partially determines fee.
mixin - unsigned int; Number of outputs from the blockchain to mix with (0 means no mixing).
ring_size - unsigned int; Sets ringsize to n (mixin + 1).
unlock_time - unsigned int; Number of blocks before the beldex can be spent (0 to not add a lock).
payment_id - string; (Optional) Random 32-byte/64-character hex string to identify a transaction.
get_tx_keys - boolean; (Optional) Return the transaction keys after sending.
key_image - string; Key image of specific output to sweep.
below_amount - unsigned int; (Optional) Include outputs below this amount.
do_not_relay - boolean; (Optional) If true, do not relay this sweep transfer. (Defaults to false)
get_tx_hex - boolean; (Optional) return the transactions as hex encoded string. (Defaults to false)
get_tx_metadata - boolean; (Optional) return the transaction metadata as a string. (Defaults to false)
Outputs:
tx_hash_list - array of: string. The tx hashes of every transaction.
tx_key_list - array of: string. The transaction keys for every transaction.
amount_list - array of: integer. The amount transferred for every transaction.
fee_list - array of: integer. The amount of fees paid for every transaction.
tx_blob_list - array of: string. The tx as hex string for every transaction.
tx_metadata_list - array of: string. List of transaction metadata needed to relay the transactions later.
multisig_txset - string. The set of signing keys used in a multisig transaction (empty for non-multisig).
unsigned_txset - string. Set of unsigned tx for cold-signing purposes.
Example:
Relay a transaction previously created with "do_not_relay":true.
Alias: None.
Inputs:
hex - string; transaction metadata returned from a transfer method with get_tx_metadata set to true.
Outputs:
tx_hash - String for the publically searchable transaction hash.
Example:
Save the wallet file.
Alias: None.
Inputs: None.
Outputs: None.
Example:
Get a list of incoming payments using a given payment id.
Alias: None.
Inputs:
payment_id - string; Payment ID used to find the payments (16 characters hex).
Outputs:
payments - list of:
payment_id - string; Payment ID matching the input parameter.
tx_hash - string; Transaction hash used as the transaction ID.
amount - unsigned int; Amount for this payment.
block_height - unsigned int; Height of the block that first confirmed this payment.
unlock_time - unsigned int; Time (in block height) until this payment is safe to spend.
subaddr_index - subaddress index:
major - unsigned int; Account index for the subaddress.
minor - unsigned int; Index of the subaddress in the account.
address - string; Address receiving the payment; Base58 representation of the public keys.
Example:
Get a list of incoming payments using a given payment id, or a list of payments ids, from a given height. This method is the preferred method over get_paymentsbecause it has the same functionality but is more extendable. Either is fine for looking up transactions by a single payment ID.
Alias: None.
Inputs:
payment_ids - array of: string; Payment IDs used to find the payments (16 characters hex).
min_block_height - unsigned int; The block height at which to start looking for payments.
Outputs:
payments - list of:
payment_id - string; Payment ID matching one of the input IDs.
tx_hash - string; Transaction hash used as the transaction ID.
amount - unsigned int; Amount for this payment.
block_height - unsigned int; Height of the block that first confirmed this payment.
unlock_time - unsigned int; Time (in block height) until this payment is safe to spend.
subaddr_index - subaddress index:
major - unsigned int; Account index for the subaddress.
minor - unsigned int; Index of the subaddress in the account.
address - string; Address receiving the payment; Base58 representation of the public keys.
Example:
Return a list of incoming transfers to the wallet.
Inputs:
transfer_type - string; "all": all the transfers, "available": only transfers which are not yet spent, OR "unavailable": only transfers which are already spent.
account_index - unsigned int; (Optional) Return transfers for this account. (defaults to 0)
subaddr_indices - array of unsigned int; (Optional) Return transfers sent to these subaddresses.
verbose - boolean; (Optional) Enable verbose output, return key image if true.
Outputs:
transfers - list of:
amount - unsigned int; Amount of this transfer.
global_index - unsigned int; Mostly internal use, can be ignored by most users.
key_image - string; Key image for the incoming transfer's unspent output (empty unless verbose is true).
spent - boolean; Indicates if this transfer has been spent.
subaddr_index - unsigned int; Subaddress index for incoming transfer.
tx_hash - string; Several incoming transfers may share the same hash if they were in the same transaction.
tx_size - unsigned int; Size of transaction in bytes.
Example, get all transfers:
Example, get available transfers:
Example, get unavailable transfers:
Return the spend or view private key.
Alias: None.
Inputs:
key_type - string; Which key to retrieve: "mnemonic" - the mnemonic seed (older wallets do not have one) OR "view_key" - the view key
Outputs:
key - string; The view key will be hex encoded, while the mnemonic will be a string of words.
Example (Query view key):
Example (Query mnemonic key):
Make an integrated address from the wallet address and a payment id.
Alias: None.
Inputs:
standard_address - string; (Optional, defaults to primary address) Destination public address.
payment_id - string; (Optional, defaults to a random ID) 16 characters hex encoded.
Outputs:
integrated_address - string
payment_id - string; hex encoded;
Example (Payment ID is empty, use a random ID):
Retrieve the standard address and payment id corresponding to an integrated address.
Alias: None.
Inputs:
integrated_address - string
Outputs:
is_subaddress - boolean; States if the address is a subaddress
payment - string; hex encoded
standard_address - string
Example:
Stops the wallet, storing the current state.
Alias: None.
Inputs: None.
Outputs: None.
Example:
Rescan the blockchain from scratch, losing any information which can not be recovered from the blockchain itself. This includes destination addresses, tx secret keys, tx notes, etc.
Alias: None.
Inputs: None.
Outputs: None.
Example:
Set arbitrary string notes for transactions.
Alias: None.
Inputs:
txids - array of string; transaction ids
notes - array of string; notes for the transactions
Outputs: None.
Example:
Get string notes for transactions.
Alias: None.
Inputs:
txids - array of string; transaction ids
Outputs:
notes - array of string; notes for the transactions
Example:
Set arbitrary attribute.
Alias: None.
Inputs:
key - string; attribute name
value - string; attribute value
Outputs: None.
Example:
Get attribute value by name.
Alias: None.
Inputs:
key - string; attribute name
Outputs:
value - string; attribute value
Example:
Get transaction secret key from transaction id.
Alias: None.
Inputs:
txid - string; transaction id.
Outputs:
tx_key - string; transaction secret key.
Example:
Check a transaction in the blockchain with its secret key.
Alias: None.
Inputs:
txid - string; transaction id.
tx_key - string; transaction secret key.
address - string; destination public address of the transaction.
Outputs:
confirmations - unsigned int; Number of block mined after the one with the transaction.
in_pool - boolean; States if the transaction is still in pool or has been added to a block.
received - unsigned int; Amount of the transaction.
Example:
Get transaction signature to prove it.
Alias: None.
Inputs:
txid - string; transaction id.
address - string; destination public address of the transaction.
message - string; (Optional) add a message to the signature to further authenticate the prooving process.
Outputs:
signature - string; transaction signature.
Example:
Prove a transaction by checking its signature.
Alias: None.
Inputs:
txid - string; transaction id.
address - string; destination public address of the transaction.
message - string; (Optional) Should be the same message used in get_tx_proof.
signature - string; transaction signature to confirm.
Outputs:
confirmations - unsigned int; Number of block mined after the one with the transaction.
good - boolean; States if the inputs proves the transaction.
in_pool - boolean; States if the transaction is still in pool or has been added to a block.
received - unsigned int; Amount of the transaction.
In the example below, the transaction has been proven:
In the example below, the wrong message is used, avoiding the transaction to be proved:
Generate a signature to prove a spend. Unlike proving a transaction, it does not requires the destination public address.
Alias: None.
Inputs:
txid - string; transaction id.
message - string; (Optional) add a message to the signature to further authenticate the prooving process.
Outputs:
signature - string; spend signature.
Example:
Prove a spend using a signature. Unlike proving a transaction, it does not requires the destination public address.
Alias: None.
Inputs:
txid - string; transaction id.
message - string; (Optional) Should be the same message used in get_spend_proof.
signature - string; spend signature to confirm.
Outputs:
good - boolean; States if the inputs proves the spend.
In the example below, the spend has been proven:
In the example below, the wrong message is used, avoiding the spend to be proved:
Generate a signature to prove of an available amount in a wallet.
Alias: None.
Inputs:
all - boolean; Proves all wallet balance to be disposable.
account_index - unsigned int; Specify the account from witch to prove reserve. (ignored if all is set to true)
amount - unsigned int; Amount (in atomic units) to prove the account has for reserve. (ignored if all is set to true)
message - string; (Optional) add a message to the signature to further authenticate the prooving process.
Outputs:
signature - string; reserve signature.
Example:
Proves a wallet has a disposable reserve using a signature.
Alias: None.
Inputs:
address - string; Public address of the wallet.
message - string; (Optional) Should be the same message used in get_reserve_proof.
signature - string; reserve signature to confirm.
Outputs:
good - boolean; States if the inputs proves the reserve.
In the example below, the reserve has been proven:
In the example below, all wallet reserve has been proven:
In the example below, the wrong message is used, avoiding the reserve to be proved:
Returns a list of transfers.
Alias: None.
Inputs:
in - boolean; (Optional) Include incoming transfers.
out - boolean; (Optional) Include outgoing transfers.
pending - boolean; (Optional) Include pending transfers.
failed - boolean; (Optional) Include failed transfers.
pool - boolean; (Optional) Include transfers from the daemon's transaction pool.
filter_by_height - boolean; (Optional) Filter transfers by block height.
min_height - unsigned int; (Optional) Minimum block height to scan for transfers, if filtering by height is enabled.
max_height - unsigned int; (Opional) Maximum block height to scan for transfers, if filtering by height is enabled (defaults to max block height).
account_index - unsigned int; (Optional) Index of the account to query for transfers. (defaults to 0)
subaddr_indices - array of unsigned int; (Optional) List of subaddress indices to query for transfers. (defaults to 0)
Outputs:
in array of transfers:
address - string; Public address of the transfer.
amount - unsigned int; Amount transferred.
confirmations - unsigned int; Number of block mined since the block containing this transaction (or block height at which the transaction should be added to a block if not yet confirmed).
double_spend_seen - boolean; True if the key image(s) for the transfer have been seen before.
fee - unsigned int; Transaction fee for this transfer.
height - unsigned int; Height of the first block that confirmed this transfer (0 if not mined yet).
note - string; Note about this transfer.
payment_id - string; Payment ID for this transfer.
subaddr_index - JSON object containing the major & minor subaddress index:
major - unsigned int; Account index for the subaddress.
minor - unsigned int; Index of the subaddress under the account.
suggested_confirmations_threshold - unsigned int; Estimation of the confirmations needed for the transaction to be included in a block.
timestamp - unsigned int; POSIX timestamp for when this transfer was first confirmed in a block (or timestamp submission if not mined yet).
txid - string; Transaction ID for this transfer.
type - string; Transfer type: "in"
unlock_time - unsigned int; Number of blocks until transfer is safely spendable.
out array of transfers (see above).
pending array of transfers (see above).
failed array of transfers (see above).
pool array of transfers (see above).
Example:
Show information about a transfer to/from this address.
Alias: None.
Inputs:
txid - string; Transaction ID used to find the transfer.
account_index - unsigned int; (Optional) Index of the account to query for the transfer.
Outputs:
transfer - JSON object containing payment information:
address - string; Address that transferred the funds. Base58 representation of the public keys.
amount - unsigned int; Amount of this transfer.
confirmations - unsigned int; Number of block mined since the block containing this transaction (or block height at which the transaction should be added to a block if not yet confirmed).
destinations - array of JSON objects containing transfer destinations:
amount - unsigned int; Amount transferred to this destination.
address - string; Address for this destination. Base58 representation of the public keys.
double_spend_seen - boolean; True if the key image(s) for the transfer have been seen before.
fee - unsigned int; Transaction fee for this transfer.
height - unsigned int; Height of the first block that confirmed this transfer.
note - string; Note about this transfer.
payment_id - string; Payment ID for this transfer.
subaddr_index - JSON object containing the major & minor subaddress index:
major - unsigned int; Account index for the subaddress.
minor - unsigned int; Index of the subaddress under the account.
suggested_confirmations_threshold - unsigned int; Estimation of the confirmations needed for the transaction to be included in a block.
timestamp - unsigned int; POSIX timestamp for the block that confirmed this transfer (or timestamp submission if not mined yet).
txid - string; Transaction ID of this transfer (same as input TXID).
type - string; Type of transfer, one of the following: "in", "out", "pending", "failed", "pool"
unlock_time - unsigned int; Number of blocks until transfer is safely spendable.
Example:
Sign a string.
Alias: None.
Inputs:
data - string; Anything you need to sign.
Outputs:
signature - string; Signature generated against the "data" and the account public address.
Example:
Verify a signature on a string.
Alias: None.
Inputs:
data - string; What should have been signed.
address - string; Public address of the wallet used to sign the data.
signature - string; signature generated by sign method.
Outputs:
good - boolean;
Example:
Export all outputs in hex format.
Alias: None.
Inputs: None.
Outputs:
outputs_data_hex - string; wallet outputs in hex format.
Example:
Import outputs in hex format.
Alias: None.
Inputs:
outputs_data_hex - string; wallet outputs in hex format.
Outputs:
num_imported - unsigned int; number of outputs imported.
Example:
Export a signed set of key images.
Alias: None.
Inputs: None.
Outputs:
signed_key_images - array of signed key images:
key_image - string;
signature - string;
Example:
Import signed key images list and verify their spent status.
Alias: None.
Inputs:
signed_key_images - array of signed key images:
key_image - string;
signature - string;
Outputs:
height - unsigned int;
spent - unsigned int; Amount (in atomic units) spent from those key images.
unspent - unsigned int; Amount (in atomic units) still available from those key images.
Example:
Create a payment URI using the official URI spec.
Alias: None.
Inputs:
address - string; Wallet address
amount - unsigned int; (optional) the integer amount to receive, in atomicunits
payment_id - string; (optional) 16 or 64 character hexadecimal payment id
recipient_name - string; (optional) name of the payment recipient
tx_description - string; (optional) Description of the reason for the tx
Outputs:
uri - string; This contains all the payment input information as a properly formatted payment URI
Example:
Parse a payment URI to get payment information.
Alias: None.
Inputs:
uri - string; This contains all the payment input information as a properly formatted payment URI
Outputs:
uri - JSON object containing payment information:
address - string; Wallet address
amount - unsigned int; Decimal amount to receive, in coin units (0 if not provided)
payment_id - string; 16 or 64 character hexadecimal payment id (empty if not provided)
recipient_name - string; Name of the payment recipient (empty if not provided)
tx_description - string; Description of the reason for the tx (empty if not provided)
Example:
Retrieves entries from the address book.
Alias: None.
Inputs:
entries - array of unsigned int; indices of the requested address book entries
Outputs:
entries - array of entries:
address - string; Public address of the entry
description - string; Description of this address entry
index - unsigned int;
payment_id - string;
Example:
Add an entry to the address book.
Alias: None.
Inputs:
address - string;
payment_id - (optional) string, defaults to "0000000000000000000000000000000000000000000000000000000000000000";
description - (optional) string, defaults to "";
Outputs:
index - unsigned int; The index of the address book entry.
Example:
Delete an entry from the address book.
Alias: None.
Inputs:
index - unsigned int; The index of the address book entry.
Outputs: None.
Example:
Refresh a wallet after openning.
Alias: None.
Inputs:
start_height - unsigned int; (Optional) The block height from which to start refreshing.
Outputs:
blocks_fetched - unsigned int; Number of new blocks scanned.
received_money - boolean; States if transactions to the wallet have been found in the blocks.
Example:
Rescan the blockchain for spent outputs.
Alias: None.
Inputs: None.
Outputs: None.
Example:
Start mining in the beldex daemon.
Alias: None.
Inputs:
threads_count - unsigned int; Number of threads created for mining.
do_background_mining - boolean; Allow to start the miner in background
ignore_battery - boolean; Ignore battery status
Outputs: None.
Example:
Stop mining in the beldex daemon.
Alias: None.
Inputs: None.
Outputs: None.
Example:
Get a list of available languages for your wallet's seed.
Alias: None.
Inputs: None.
Outputs:
languages - array of string; List of available languages
Example:
Create a new wallet. You need to have set the argument "–wallet-dir" when launching beldex-wallet-rpc to make this work.
Alias: None.
Inputs:
filename - string; Wallet file name.
password - string; (Optional) password to protect the wallet.
language - string; Language for your wallets' seed.
Outputs: None.
Example:
Open a wallet. You need to have set the argument "–wallet-dir" when launching beldex-wallet-rpc to make this work.
Alias: None.
Inputs:
filename - string; wallet name stored in –wallet-dir.
password - string; (Optional) only needed if the wallet has a password defined.
Outputs: None.
Example:
Close the currently opened wallet, after trying to save it.
Alias: None.
Inputs: None.
Outputs: None.
Example:
Change a wallet password.
Alias: None.
Inputs:
old_password - string; (Optional) Current wallet password, if defined.
new_password - string; (Optional) New wallet password, if not blank.
Outputs: None.
Example:
Check if a wallet is a multisig one.
Alias: None.
Inputs: None.
Outputs:
multisig - boolean; States if the wallet is multisig
ready - boolean;
threshold - unsigned int; Amount of signature needed to sign a transfer.
total - unsigned int; Total amount of signature in the multisig wallet.
Example for a non-multisig wallet:
Example for a multisig wallet:
Prepare a wallet for multisig by generating a multisig string to share with peers.
Alias: None.
Inputs: None.
Outputs:
multisig_info - string; Multisig string to share with peers to create the multisig wallet.
Example:
Make a wallet multisig by importing peers multisig string.
Alias: None.
Inputs:
multisig_info - array of string; List of multisig string from peers.
threshold - unsigned int; Amount of signatures needed to sign a transfer. Must be less or equal than the amount of signature in multisig_info.
password - string; Wallet password
Outputs:
address - string; multisig wallet address.
multisig_info - string; Multisig string to share with peers to create the multisig wallet (extra step for N-1/N wallets).
Example for 2/2 Multisig Wallet:
Example for 2/3 Multisig Wallet:
Export multisig info for other participants.
Alias: None.
Inputs: None.
Outputs:
info - string; Multisig info in hex format for other participants.
Example:
Import multisig info from other participants.
Alias: None.
Inputs:
info - array of string; List of multisig info in hex format from other participants.
Outputs:
n_outputs - unsigned int; Number of outputs signed with those multisig info.
Example:
Turn this wallet into a multisig wallet, extra step for N-1/N wallets.
Alias: None.
Inputs:
multisig_info - array of string; List of multisig string from peers.
password - string; Wallet password
Outputs:
address - string; multisig wallet address.
Example:
Sign a transaction in multisig.
Alias: None.
Inputs:
tx_data_hex - string; Multisig transaction in hex format, as returned by transfer under multisig_txset.
Outputs:
tx_data_hex - string; Multisig transaction in hex format.
tx_hash_list - array of string; List of transaction Hash.
Example:
Submit a signed multisig transaction.
Alias: None.
Inputs:
tx_data_hex - string; Multisig transaction in hex format, as returned by sign_multisigunder tx_data_hex.
Outputs:
tx_hash_list - array of string; List of transaction Hash.
Example:
Get RPC version Major & Minor integer-format, where Major is the first 16 bits and Minor the last 16 bits.
Alias: None.
Inputs: None.
Outputs:
version - unsigned int; RPC version, formatted with Major * 2^16 + Minor(Major encoded over the first 16 bits, and Minor over the last 16 bits).
Example:
Map the BNS name to the BChat Id, Belnet key, bdx address and ETH address.
Alias: None.
Inputs:
years - string; (Optional) The mapping years "1year || 1y" , "2years || 2y" , "5years || 5y" , "10years || 10y".
owner - string; (Optional) The ed25519 public key or wallet address that has authority to update the mapping.
backup_owner - string; (Optional) The secondary, backup public key that has authority to update the mapping.
name - string; The name to purchase via Beldex Name Service.
value_bchat - string; The value of bchat id that the name maps to Beldex Name Service.
value_wallet - string; The value of wallet that the name maps to Beldex Name Service.
value_eth_addr - string; The value of ETH address that the name maps to Beldex Name Service.
value_belnet - string; The value of belnet address that the name maps to Beldex Name Service.
account_index - uint32_t; (Optional) Transfer from this account index. (Defaults to 0).
subaddr_indices - array of unsigned int; (Optional) List of subaddress indices to query for transfers. (defaults to 0).
priority - unsigned int; Set a priority for the transaction. Accepted Values are: 0 and 1 for: flash and unimportant.
get_tx_key - boolean; (Optional) Return the transaction keys after sending.
do_not_relay - boolean; (Optional) If true, do not relay this sweep transfer. (Defaults to false).
get_tx_hex - boolean; (Optional) return the transactions as hex encoded string. (Defaults to false).
get_tx_metadata - boolean; (Optional) return the transaction metadata as a string. (Defaults to false).
Outputs:
tx_hash - String for the publicly searchable transaction hash.
tx_key - String for the transaction key if get_tx_key is true, otherwise, blank string.
amount - Amount transferred for the transaction.
fee - Integer value of the fee charged for the txn.
tx_blob - Raw transaction represented as hex string, if get_tx_hex is true.
tx_metadata - Set of transaction metadata needed to relay this transfer later, if get_tx_metadata is true.
multisig_txset - Set of multisig transactions in the process of being signed (empty for non-multisig).
unsigned_txset - String. Set of unsigned tx for cold-signing purposes.
Example:
Renew the BNS name for,
1 Year
2 Years
5 Years
10 Years
Alias: None.
Inputs:
years - string; (optional)The mapping years "1year || 1y" , "2years || 2y" , "5years || 5y" , "10years || 10y". Default value is "1 year"
name - string; The name to Renew.
account_index - uint32_t; (Optional) Transfer from this account index. (Defaults to 0).
subaddr_indices - array of unsigned int; (Optional) List of subaddress indices to query for transfers. (defaults to 0).
priority - unsigned int; Set a priority for the transaction. Accepted Values are: 0 and 1 for: flash and unimportant.
get_tx_key - boolean; (Optional) Return the transaction keys after sending.
do_not_relay - boolean; (Optional) If true, do not relay this sweep transfer. (Defaults to false).
get_tx_hex - boolean; (Optional) return the transactions as hex encoded string. (Defaults to false).
get_tx_metadata - boolean; (Optional) return the transaction metadata as a string. (Defaults to false).
Outputs:
tx_hash - String for the publicly searchable transaction hash.
tx_key - String for the transaction key if get_tx_key is true, otherwise, blank string.
amount - Amount transferred for the transaction.
fee - Integer value of the fee charged for the txn.
tx_blob - Raw transaction represented as hex string, if get_tx_hex is true.
tx_metadata - Set of transaction metadata needed to relay this transfer later, if get_tx_metadata is true.
multisig_txset - Set of multisig transactions in the process of being signed (empty for non-multisig).
unsigned_txset - String. Set of unsigned tx for cold-signing purposes.
Example:
Modify the Bchat and Belnet key values, as well as the wallet's address and ETH address. Additionally, it is possible to update both the Owner and Backup Owner information.
Alias: None.
Inputs:
name - string; The name to Update.
value_bchat - string; The value of bchat id that the name maps to Beldex Name Service.
value_wallet - string; The value of wallet that the name maps to Beldex Name Service.
value_eth_addr - string; The value of ETH address that the name maps to Beldex Name Service.
value_belnet - string; The value of belnet address that the name maps to Beldex Name Service.
owner - string; (Optional) The ed25519 public key or wallet address that has authority to update the mapping.
backup_owner - string; (Optional) The secondary, backup public key that has authority to update the mapping.
signature - string; (Optional) Signature derived using libsodium generichash on {current txid blob, new value blob} of the mapping to update. By default the hash is signed using the wallet's spend key as an ed25519 keypair, if signature is specified.
account_index - uint32_t; (Optional) Transfer from this account index. (Defaults to 0).
subaddr_indices - array of unsigned int; (Optional) List of subaddress indices to query for transfers. (defaults to 0).
priority - unsigned int; Set a priority for the transaction. Accepted Values are: 0 and 1 for: flash and unimportant.
get_tx_key - boolean; (Optional) Return the transaction keys after sending.
do_not_relay - boolean; (Optional) If true, do not relay this sweep transfer. (Defaults to false).
get_tx_hex - boolean; (Optional) return the transactions as hex encoded string. (Defaults to false).
get_tx_metadata - boolean; (Optional) return the transaction metadata as a string. (Defaults to false).
Outputs:
tx_hash - String for the publically searchable transaction hash.
tx_key - String for the transaction key if get_tx_key is true, otherwise, blank string.
amount - Amount transferred for the transaction.
fee - Integer value of the fee charged for the txn.
tx_blob - Raw transaction represented as hex string, if get_tx_hex is true.
tx_metadata - Set of transaction metadata needed to relay this transfer later, if get_tx_metadata is true.
multisig_txset - Set of multisig transactions in the process of being signed (empty for non-multisig).
unsigned_txset - String. Set of unsigned tx for cold-signing purposes.
Example:
In order to modify the Owner or BackupOwner of a wallet that currently lacks ownership, it is imperative to provide the corresponding signature. This signature is essential for executing the alteration through the bns_update_mapping function within alternative wallets.
Alias: None.
Inputs:
name - string; The name to Update using signature.
owner - string; (Optional) The ed25519 public key or wallet address that has authority to update the mapping.
backup_owner - string; (Optional) The secondary, backup public key that has authority to update the mapping.
account_index - uint32_t; (Optional) Transfer from this account index. (Defaults to 0).
Output:
signature - A signature valid for using in BNS to update an underlying mapping.
Example:
View the hash of the BNS name.
Alias: None.
Input:
name - string; The desired name to hash.
Output:
name - The name hashed and represented in base64.
Example:
Retrieve a list of BNS Names linked with a wallet.
Alias: None.
Inputs:
decrypt - boolean; (Optional) If true (default false) then also decrypt and include the `value` field.
include_expired - boolean; (Optional) If true (default false) then also include expired records.
Outputs:
hashed - The hashed name (in base64).
name - The plaintext name.
owner - Address of the wallet.
backup_owner - backup_owner address if given.
encrypted_bchat_value - Encrypted value of bchat that the name maps to, in hex.
encrypted_wallet_value - Encrypted value of BDX wallet address that the name maps to, in hex.
encrypted_eth_addr_value - Encrypted value of eth address that the name maps to, in hex.
encrypted_belnet_value - Encrypted value of belnet address that the name maps to, in hex.
bchat_value - Decrypted bchat value that the name maps to. Only provided if `decrypt: true` was specified in the request.
wallet_value - Decrypted wallet value that the name maps to. Only provided if `decrypt: true` was specified in the request.
belnet_value - Decrypted belnet value that that the name maps to. Only provided if `decrypt: true` was specified in the request.
eth_addr_value - Decrypted etc address value that the name maps to. Only provided if `decrypt: true` was specified in the request.
update_height - Last height that this Beldex Name Service entry was updated on the Blockchain.
expiration_height - For records that expire, this will be set to the expiration block height.
expired - Indicates whether the record has expired. Only included in the response if "include_expired" is specified in the request.
txid - transaction id.
Example:
Add the BNS names in the cache.
Alias: None.
Input:
names - array of string; The (unhashed) name of the record.
Outputs: None.
Example:
Retrieve the encrypted value of the specified BNS value by indicating the type.
Alias: None.
Input:
name - string; The BNS name with which to encrypt the value.
type - string; The mapping type: "bchat" or "belnet" or "wallet".
value - string; The value to be encrypted.
Output:
encrypted_value - The encrypted value, in hex.
Example:
Decrypt the BNS value corresponding to the provided encrypted value.
Alias: None.
Inputs:
name - string; The BNS name with which to encrypt the value.
type - string; The mapping type: "bchat" or "belnet" or "wallet".
encrypted_value - string; The encrypted value represented in hex.
Output:
value - The value decrypted.
Example:
The specified amount will be burnt from the provided tx_id using the unspent transaction or amount.
Alias: None.
Inputs:
amount - uint64_t; burn amount.
tx_id - string; Transaction ID used to find the transfer.
account_index - uint32_t; (Optional) Transfer from this account index. (Defaults to 0).
subaddr_indices - array of unsigned int; (Optional) List of subaddress indices to query for transfers. (defaults to 0).
priority - unsigned int; Set a priority for the transaction. Accepted Values are: 0 and 1 for: flash and unimportant.
get_tx_key - boolean; (Optional) Return the transaction keys after sending.
do_not_relay - boolean; (Optional) If true, do not relay this sweep transfer. (Defaults to false).
get_tx_hex - boolean; (Optional) return the transactions as hex encoded string. (Defaults to false).
get_tx_metadata - boolean; (Optional) return the transaction metadata as a string. (Defaults to false).
Output:
tx_hash - String for the publicly searchable transaction hash.
tx_key - String for the transaction key if get_tx_key is true, otherwise, blank string.
amount - Amount transferred for the transaction.
fee - Integer value of the fee charged for the txn.
tx_blob - Raw transaction represented as hex string, if get_tx_hex is true.
tx_metadata - Set of transaction metadata needed to relay this transfer later, if get_tx_metadata is true.
multisig_txset - Set of multisig transactions in the process of being signed (empty for non-multisig).
unsigned_txset - String. Set of unsigned tx for cold-signing purposes.
Examples:
coin burn using tx_id
coin burn using amount
Reworked RPC calls for Beldex under their .