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...
Loading...
Loading...
Loading...
The X-Cash API https://api.xcash.foundation allows users to read information from various X-Cash products using one standardized API. The current individual API can still be used, but it is recommended to migrate and use the standard API for various reasons.
The individual API were built mostly for the websites, not as a standardized API for users.
The standard API will use "standardized" API methods, resources, parameters, return field types etc
The standard API will have more features than the individual API
The standard API will use one domain instead of multiple
The standard API is built with users in mind, using a specific backend processing and server setup for public APIs
Note: For the blockchain API it is not meant to be a complete set. You can get much more data using any remote daemon to get more info. This is meant to include the most common use cases and data.
I want to submit an issue or feature request
Please view the
I want to view the API for the blockchain
Please view the
I want to view the API for DPOPS
Please view the
I want to view the API for Namespace Protocol
Please view the
I want to view the API for X-Payment Twitter
Please view the
Note zachys (atomic units) are 10^6 in X-Cash
This method gets the stats
URL: https://api.xcash.foundation/v1/xcash/blockchain/unauthorized/stats
Method: GET
Inputs: None.
Results:
height - unsigned int; The current block height.
hash - string; The current block hash.
reward - unsigned long long; The current block reward in zachys (atomic units).
size - unsigned long long; The size of the blockchain in bytes.
version - unsigned int; The hard fork version.
versionBlockHeight - unsigned int; The block height the hard fork version started on.
nextVersionBlockHeight - unsigned int; The block height of the next hard fork version.
totalPublicTx - unsigned int; The total public tx.
totalPrivateTx - unsigned int; The total private tx.
circulatingSupply - unsigned long long; The circulating supply in zachys (atomic units).
generatedSupply - unsigned long long; The generated supply in zachys (atomic units).
totalSupply - unsigned long long; The total supply in zachys (atomic units).
emissionReward - unsigned long long; The estimated constant block reward in zachys (atomic units).
emissionHeight - unsigned int; The estimated block height that will start the emission (when the constant block reward is hit).
emissionTime - unsigned int; The estimated time when the emission will start (when the constant block reward is hit).
inflationHeight - unsigned int; The estimated block height that will start the inflation (when the total supply increases).
inflationTime - unsigned int; The estimated time when the inflation will start (when the total supply increases).
This method gets the block data
URL: https://api.xcash.foundation/v1/xcash/blockchain/unauthorized/blocks/{blockHeight}
Method: GET
Resources:
blockHeight - Not required - The block height (default is current block height).
Inputs: None.
Results:
height - unsigned int; The block height.
hash - string; The block hash.
reward - unsigned long long; The block reward in zachys (atomic units).
time - unsigned int; The time the block was produced.
xcashDPOPS - bool;
delegateName - string; The delegate name who produced the block.
tx - an array of transactions; The list of all transactions included in the block.
This method gets the transaction data
URL: https://api.xcash.foundation/v1/xcash/blockchain/unauthorized/tx/{txHash}
Method: GET
Resources:
tx - Required - The tx hash.
Inputs: None.
Results:
height - unsigned int; The block height (0 if not added to a block).
confirmations - unsigned int; The block confirmations.
time - unsigned int; The time.
type - string; "private | public".
sender - string; The sender, if public.
receiver - string; The receiver, if public.
amount - unsigned long long; The amount, if public.
This method proves a tx and its amount
URL: https://api.xcash.foundation/v1/xcash/blockchain/unauthorized/tx/prove/
Method: POST
Inputs (All are required):
tx - The tx hash.
address - The destination public address.
key - The tx key or tx proof.
Results:
valid - bool; Confirms that some amount was sent to the destination public address in this tx.
amount - unsigned long long; The amount sent to the destination public address.
This method proves that a wallet has at least a certain balance
URL: https://api.xcash.foundation/v1/xcash/blockchain/unauthorized/address/prove/
Method: POST
Inputs (All are required):
address - The public address to prove has a certain balance.
signature - The signature.
Results:
amount - unsigned long long; The amount that the address has proven that it holds. Note the address can hold more than this amount, but not less than this amount.
This method gets the public transaction history of an address
URL: https://api.xcash.foundation/v1/xcash/blockchain/unauthorized/address/history/{type}/{address}
Method: GET
Resources:
type - Required - "sender | receiver".
address - Required - The address.
Inputs: None.
Results:
An array of objects with the following structure:
tx - string; The tx.
key - string; The tx key.
sender - string; The sender.
receiver - string; The receiver.
amount - unsigned long long; The amount.
height - unsigned int; The block height.
time - unsigned int; The block timestamp.
This method validates an address
URL: https://api.xcash.foundation/v1/xcash/blockchain/unauthorized/address/validate/{address}
Method: GET
Resources:
address - Required - The address.
Inputs: None.
Results:
An array of objects with the following structure:
valid - bool; The validation status.
This method creates an integrated address
URL: https://api.xcash.foundation/v1/xcash/blockchain/unauthorized/address/createIntegrated/
Method: POST
Inputs:
address - Required - The public address.
paymentId - Not required - The payment id (either encrypted or long format).
Results:
integratedAddress - string; The integrated address
paymentId - string; The payment id
Note zachys (atomic units) are 10^6 in X-Cash
This method gets the stats
Method: GET
Inputs: None.
Results:
mostTotalRoundsDelegateName - string; The delegate name that has participated in the most X-Cash DPOPS rounds.
mostTotalRounds - unsigned int; The most total rounds.
bestBlockVerifierOnlinePercentageDelegateName - string; The delegate with the best online percentage.
bestBlockVerifierOnlinePercentage - unsigned int; The best online percentage.
mostBlockProducerTotalRoundsDelegateName - string; The delegate will the most block producer rounds.
mostBlockProducerTotalRounds - unsigned int; Total most block producer rounds.
totalVotes - unsigned long long; Total votes in zachys (atomic units).
totalVoters - unsigned int; Total voters.
averageVote - unsigned int; Average vote amount in zachys (atomic units).
votePercentage - unsigned int; The percentage of the amount of xcash ciruclating compared to how much is being voted.
roundNumber - unsigned int; The round number of X-Cash DPOPS.
totalRegisteredDelegates - unsigned int; Total registered delegates.
totalOnlineDelegates - unsigned int; Total online delegates.
currentBlockVerifiersMaximumAmount - unsigned int; The current amount of delegates that the system will use.
currentBlockVerifiersValidAmount - unsigned int; The current amount of delegates that is needed for verification.
This method gets all of the registered delegates
Method: GET
Inputs: None.
Results:
Array of objects with the following structure:
votes - unsigned long long; Total votes in zachys (atomic units).
voters - unsigned int; Total voters.
IPAdress - string; The IP address or domain name.
delegateName - string; The delegate name.
sharedDelegate - bool;
seedNode - bool;
online - bool;
fee - unsigned int; The fee.
totalRounds - unsigned int; Total rounds.
totalBlockProducerRounds - unsigned int; Total block producer rounds.
onlinePercentage - unsigned int; The online percentage.
This method gets all of the online delegates
Method: GET
Inputs: None.
Results:
Array of objects with the following structure:
votes - unsigned long long; Total votes in zachys (atomic units).
voters - unsigned int; Total voters.
IPAdress - string; The IP address or domain name.
delegateName - string; The delegate name.
sharedDelegate - bool;
seedNode - bool;
online - bool;
fee - unsigned int; The fee.
totalRounds - unsigned int; Total rounds.
totalBlockProducerRounds - unsigned int; Total block producer rounds.
onlinePercentage - unsigned int; The online percentage.
This method gets the current active delegates (top 50) during the round
Method: GET
Inputs: None.
Results:
Array of objects with the following structure:
votes - unsigned long long; Total votes in zachys (atomic units).
voters - unsigned int; Total voters.
IPAdress - string; The IP address or domain name.
delegateName - string; The delegate name.
sharedDelegate - bool;
seedNode - bool;
online - bool;
fee - unsigned int; The fee.
totalRounds - unsigned int; Total rounds.
totalBlockProducerRounds - unsigned int; Total block producer rounds.
onlinePercentage - unsigned int; The online percentage.
This method gets the delegates data
Method: GET
Resources:
delegateName - Required - The delegates name.
Inputs: None.
Results:
votes - unsigned long long; Total votes in zachys (atomic units).
voters - unsigned int; Total voters.
IPAdress - string; The IP address or domain name.
delegateName - string; The delegate name.
publicAddress - string; The public address.
about - string; about.
website - string; website.
team - string; team.
specifications - string; server Specifications.
sharedDelegate - bool;
seedNode - bool;
online - bool;
fee - unsigned int; The fee.
totalRounds - unsigned int; Total rounds.
totalBlockProducerRounds - unsigned int; Total block producer rounds.
onlinePercentage - unsigned int; The online percentage.
rank - unsigned int; The delegates current rank.
This method gets the stats about the blocks the delegate produced
Method: GET
Resources:
delegateName - Required - The delegate name.
Inputs: None.
Results:
totalBlocksProduced - unsigned int; The total blocks produced by the delegate
totalBlockRewards - unsigned long long; The total xcash from the blocks produced in zachys (atomic units).
averagePercentage - unsigned int; The average the delegate has produced a block. (100 is average, 200 is twice as good etc etc)
averageTime - unsigned int; The average time (in minutes) it takes for the delegate to produce a block.
blocksProduced - an arrray with the following structure:
blockHeight - unsigned int; The block height.
blockReward - unsigned long long; The block reward in zachys (atomic units).
time - unsigned int; The time stamp.
This method gets the vote data for a delegate
Method: GET
Resources:
delegateName - Required - The delegate name.
start - Required - The start item to return data (0 is the first item).
limit - Required - The maximum amount of items to return (Maximum of 1000).
Inputs: None.
Results:
An array of objects with the following structure:
publicAddress - string; The public address who created the vote.
amount - unsigned long long; The vote amount in zachys (atomic units).
reserveProof - string; The reserve proof.
This method gets the vote data from a specific address
Method: GET
Resources:
address - Required - The public address.
Inputs: None.
Results:
delegateName - string; The delegate name voted for.
amount - unsigned long long; The vote amount in zachys (atomic units).
This method gets the round details
Method: GET
Resources:
blockHeight - Required - The block height for the round.
Inputs: None.
Results:
An array of delegate names that verified the block
This method gets the last block producer
Method: GET
Inputs: None.
Results:
lastBlockProducer - The last block producer.
Note zachys (atomic units) are 10^6 in X-Cash
This method gets the stats
Method: GET
Inputs: None.
Results:
totalNamesRegisteredOrRenewed - unsigned int; The total registered or renewed names the delegates have processed.
totalVolume - unsigned long long; The total xcash paid to delegates using the namespace protocol in zachys (atomic units).
This method gets all of the registered delegates
Method: GET
Inputs: None.
Results:
Array of objects with the following structure:
delegateName - string; The delegate name.
amount - unsigned long long; The amount to register or renew a name, using this delegate in zachys (atomic units).
This method gets the delegates data
Method: GET
Resources:
delegateName - Required - The delegates name.
Results:
delegateName - string; The delegate name.
publicAddress - string; The public address.
amount - unsigned long long; The amount that a delegate charges to register or renew a name in zachys (atomic units).
totalNamesRegisteredOrRenewed - unsigned int; The total registered or renewed names that the delegate has processed.
totalVolume - unsigned long long; The total xcash paid to delegates using the namespace protocol in zachys (atomic units).
This method gets the names data for a specific name
Method: GET
Resources:
name - Required - The namespace.
Results:
address - string; The address.
saddress - string; The saddress.
paddress - string; The paddress.
expires - unsigned int; The time the domain expires.
delegateName - string; The delegate that registered the namespace.
delegateAmount - unsigned long long; The total xcash paid to delegates to register or renew the namespace in zachys (atomic units).
This method checks if a name can be purchased,either by it has not been registered yet, or it has expired
Method: GET
Resources:
name - Required - The namespace.
Results:
status - bool; True if one can register the name, otherwise false.
This method gets the address status
Method: GET
Resources:
address - Required - The address.
Results:
status - string; "not registered|address|saddress|paddress"
This method converts a name to an address
Method: GET
Resources:
name - Required - The namespace
Results:
address - string; The address.
saddress - string; The saddress.
paddress - string; The paddress.
This method converts an address to a name and extension
Method: GET
Resources:
address - Required - The address.
Results:
name - string; The name.
extension - string; The extension.
URL:
URL:
URL:
URL:
URL:
URL:
URL:
URL:
URL:
URL:
URL:
URL:
URL:
URL:
URL:
URL:
URL:
URL:
Use X-Cash Blockchain Export (xcash-blockchain-export) to create a raw file of the blockchain
This tool creates an export of the local blockchain version to a raw format.
This could be useful if you want to process blockchain efficiently with your custom tools, as the raw format is probably easier to work with than X-Cash's custom lmdb database. This can also be used to share the blockchain to others allowing them to download it quicker.
The tool works on your local copy of the blockchain and does not require xcashd running.
./xcash-blockchain-export [options]
Example:
./xcash-blockchain-export --help
Go to directory where you unpacked X-Cash.
./xcash-blockchain-export --stagenet --output-file=/tmp/blockchain.raw
Option
Description
--help
Enlist available options.
Option
Description
(missing)
By default xcash-blockchain-export assumes mainnet.
--stagenet
Export stagenet blockchain.
--testnet
Export testnet blockchain.
Specifying the log file path is not supported.
Option
Description
--log-level
0-4 with 0 being minimal logging and 4 being full tracing. Defaults to 0. These are general presets and do not directly map to severity levels. For example, even with minimal 0, you may see some most important INFO entries. Example: ./xcash-blockchain-export --log-level=1
Option
Description
--data-dir
Full path to data directory. This is where the blockchain, log files, and p2p network memory are stored. For defaults and details see data directory.
--database, --db-type
The default and only valid value is lmdb.
Option
Description
--output-file
Specify output file path. The default is $DATA_DIR/export/blockchain.raw. Example: ./xcash-blockchain-export --output-file=/tmp/blockchain.raw
--blocksdat
Output in blocks.dat format.
--block-stop
Only export up to this block number. By default do the full export (value 0).
Use X-Cash Blockchain Import (xcash-blockchain-import) to import a raw file of the blockchain
The tool imports a bootstrap file blockchain.raw to your full node to be used as thelmdb blockchain.
This could be useful if you want to decouple download from verification for any reason (like testing performance in isolation), or if you have a limited speed connection. Updated version of the blockchain.raw file can be found on X-Cash communities.
For best practices, you should use your own trusted blockchain.raw file that you exported earlier.
Also note that importing blockchain.raw will in most cases not speed up the process over syncing up from p2p network. This is because usual bottlenecks are disk IO and verification, not the download itself.
The tool works on your local files and does not require xcash running.
./xcash-blockchain-import [options]
Example:
./xcash-blockchain-import --help
Go to directory where you unpacked X-Cash.
./xcash-blockchain-import --stagenet --input-file=/tmp/blockchain.raw
Option
Description
--help
Enlist available options.
Option
Description
(missing)
By default xcash-blockchain-import assumes the mainnet blockchain.
--stagenet
Import stagenet blockchain.
--testnet
Import testnet blockchain.
Option
Description
--log-level
0-4 with 0 being minimal logging and 4 being full tracing. Defaults to 0. These are general presets and do not directly map to severity levels. For example, even with minimal 0, you may see some most important INFO entries. Example: ./xcash-blockchain-import --log-level=1
Option
Description
--data-dir
Full path to data directory. This is where the blockchain, log files, and p2p network memory are stored. For defaults and details see data directory.
--count-blocks
Count blocks in the bootstrap file and exit.
--drop-hard-fork
Whether to drop hard fork data. Off by default (0).
--database
The only valid value seems to be lmdb (the default).
Option
Description
--data-dir
Full path to data directory. This is where the blockchain, log files, and p2p network memory are stored. For defaults and details see data directory.
--count-blocks
Count blocks in the bootstrap file and exit.
--drop-hard-fork
Whether to drop hard fork data. Off by default (0).
--database
Option
Description
--dangerous-unverified-import
The safe default is to run verification (value 0). You can enable --dangerous-unverified-import if you are importing from your own and trusted blockchain.raw (which we assume was already verified). The "dangerous" mode will greatly speed up the process.
--batch
Whether to save to disk on an ongoing basis (the default, value 1) or maybe do everything in RAM and save everything in the end (value 0). No batching is only effective in combination with no verification (--dangerous-unverified-import). See also --batch-size.
--batch-size
How often to save to disk expressed in number of blocks. By default save every 5000 blocks (when verifying) or every 20000 blocks (when not verifying). Big batches are faster but require more RAM.
--resume
Resume from current height if output database already exists (the default, value 1). Changing to --resume=0 doesn't change much — existing blocks are skipped pretty quickly and the process is resumed anyway.
Use X-Cash RPC Daemon (xcash-daemon-rpc) to interact with a daemon through JSON-RPC commands
This is a list of the xcashd daemon RPC calls, their inputs and outputs, and examples for each.
Many RPC calls use the daemon's JSON RPC interface while others use their own interfaces, as illustrated below.
Note: "atomic units" refer to the smallest fraction of 1 XCASH according to the xcashd implementation. 1 XCASH = 1e6 atomic units of XCASH.
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.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 inform
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:
Block blob data - array of strings; list of block blobs which have been mined. See get_block_template to get a blob on which to mine.
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 X-Cash 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 xcash protocol at this block height.
minor_version - unsigned int; The minor version of the xcash protocol at this block height.
nonce - unsigned int; a cryptographic random one-time number used in mining a X-Cash 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 atomic units generated in this block and rewarded to the miner. Note: 1 XCASH = 1e6 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 (1562023 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:
block_header - A structure containing block header information. See get_last_block_header.
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 430477 is looked up by its hash:
Similar to get_block_header_by_hash above, this method includes a block's height as an input parameter to retrieve basic information about the block.
Alias: getblockheaderbyheight.
Inputs:
height - unsigned int; The block's height.
Outputs:
block_header - A structure containing block header information. See get_last_block_header.
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 430477 is looked up by its height (notice that the returned information is the same as in the previous example):
Similar to get_block_header_by_height 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.
Alias: getblockheadersrange.
Inputs:
start_height - unsigned int; The starting block's height.
end_height - unsigned int; The ending block's height.
Outputs:
headers - array of block_header (a structure containing block header information. See get_last_block_header).
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).
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.
block_header - A structure containing block header information. See get_last_block_header.
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 430477 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 430477 is looked up by its hash. Note that block 993056 has 3 non-coinbase transactions:
Retrieve general information about the state of your node and the network.
Alias:
/get_info
/getinfo
See other RPC Methods /get_info (not JSON)
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; bootstrap node to give immediate usability to wallets while syncing by proxying RPC to it. (Note: the replies may be untrustworthy).
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:
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:
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:
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:
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 get_info or get_last_block_header, rather than getheight below.
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).
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:
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).
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 xcash 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 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 bytes.
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
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:
This method is a convenient backward support and should not be used anymore. See get_info JSON RPC for details.
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).
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:
Use X-Cash RPC Wallet (xcash-wallet-rpc) to interact with a wallet through JSON-RPC commands
This is a list of the xcash-wallet-rpc calls, their inputs and outputs, and examples of each. The program xcash-wallet-rpc replaced the rpc interface that was in simplewallet and then xcash-wallet-rpc.
All xcash-wallet-rpc methods use the same JSON RPC interface. For example:
If the xcash-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 XCASH according to the xcashd implementation. 1 XCASH = 1e6 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 xcash-wallet-rpc in session.
unlocked_balance - unsigned int; Unlocked funds are those funds that are sufficiently deep enough in the X-Cash 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 xcash-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 xcash-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 XCASH to a number of recipients.
Alias: None.
Inputs:
destinations - array of destinations to receive XCASH:
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 empty - all indices)
priority - unsigned int; Set a priority for the transaction. Accepted Values are: 0-3 for: default, unimportant, normal, elevated, priority.
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 XCASH 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 X-Cash 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 XCASH:
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 empty - all indices)
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 XCASH 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 X-Cash 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:
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 X-Cash 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 XCASH 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 XCASH 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 OR "spend_key" - the spend 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:
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:
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:
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 empty - all indices)
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 atomic units
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; Integer amount to receive, in atomic 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:
Validates an address
Alias: None.
Inputs:
address - string; Address.
Outputs:
status - bool; true or false.
Example:
Create a new wallet. You need to have set the argument "–wallet-dir" when launching xcash-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 xcash-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_multisig under 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:
Get Started to use XCASH on the Ethereum and Polygon network.
This tutorial will act as a guide for step-by-step process to understand and use WXCASH, a wrapped representation of an XCASH coin on the Polygon and Ethereum network.
We are mentioning here WXCASH to talk about any wrapped token represensation of XCASH, being on Polygon and Ethereum network. In this guide, we will make the differentiation with the following pattern: Coin Name (Network). You will see:
XCASH (X-Cash): This is the XCASH coins interacting on the X-Cash network. This is the basic network, governed through the DPOPS consensus and validated by 50 delegates.
WXCASH (Polygon): This is an ERC20 token representing a wrapped version of XCASH on the Polygon (Matic) Network. This is the version of the wrapped coin you will have after performing a swap on the X-Bank, the X-Cash Foundation managed wallet. Contract address: 0x03678f2c2c762dc63c2bb738c3a837d366eda560
WXCASH (Ethereum): ERC20 token on the root chain (Ethereum). As the WXCASH (Polygon) is running on a child chain on Polygon, you need to use the PoS Polygon Bridge to withdraw them on the Ethereum network. Contract address: 0x235328f864f38a91f0d2282159ea7c7b7c9f7c62
The Polygon network has rebranded a few months ago. It was previously called Matic Network. When interacting with the network, you might see Polygon and Matic names cohabiting from time to time. They are the same, and you shouldn't worry
We will explain how to interact with the different networks, with the necessary
Swap XCASH from the X-Cash network to Polygon (X-Cash → Polygon)
Withdraw assets from Polygon on to root chain with the Matic Bridge (Polygon → Ethereum)
And the other way around
Go from the root Ethereum chain to Polygon with the (Ethereum → Polygon)
Withdraw assets from Polygon on to X-Cash main chain (Polygon → X-Cash)
To swap your XCASH (X-Cash) to WXCASH (Polygon), the only way is through the X-Bank.
As of today, there is no other way to swap XCASH (X-Cash) to WXCASH (Polygon), only through the X-Bank Swap feature. Don't try to get WXCASH any other way, it will result in a loss of your funds.
Go to your X-Bank account to start, select the Swap page.
Select the base amount of currency you would like to swap, the amount, and select "Swap". You will be prompted to validate the 1:1 swap. Validate to swap your XCASH to WXCASH, and vice versa.
The swap within the X-Bank is free, and will always be!
Once you have WXCASH in your X-Bank account, you can now transfer them and send them to a ERC-20 address.
You have several ways to get an ERC-20 address, and we recommend using Metamask or any other ERC-20 compatible wallet that supports the Polygon (Matic) Network.
You will need to add the Polygon (Matic) network to your Metamask application to be able to see your WXCASH (Polygon) tokens in your wallet. To add the Polygon (Matic) network, you just need to select "Custom RPC" in the Networks panel
And add the following information:
Network Name Polygon Mainnet
New RPC URL https://rpc-mainnet.maticvigil.com/
Chain ID 137
Currency Symbol (optional) MATIC
Block Explorer URL (optional) https://explorer-mainnet.maticvigil.com/
Then save. You will be able to select this network in Metamask now.
Once you have added the Polygon Network in your Metamask network selection, you can add the WXCASH (Polygon) token to your wallet. Click on Add Token at the bottom of the screen.
And in the contract address field, paste the following: 0x03678f2c2c762dc63c2bb738c3a837d366eda560
This contract address is the official and only contract address for WXCASH (Polygon). Always make sure that you are sending WXCASH (Polygon) with this contract address.
You can now see WXCASH (Polygon) in your Metamask wallet.
You can now withdraw WXCASH (Polygon) from the X-bank to your ERC-20 wallet. You just need to select the Transfer page in the X-bank, select WXCASH currency to withdraw, input an amount and your ERC-20 address (provided in your Metamask wallet), and select withdraw.
Because Polygon's transfer fees are so low, we have decided for the time being to keep the withdrawals free for the X-Bank users.
After a few necessary confirmations, the withdraw will be taken into account and you will be able to see your WXCASH (Polygon) tokens in your Metamask wallet.
To deposit WXCASH (Polygon) to the X-Bank, you can use your Metamask transfer function.
First, go to the Deposit page on the X-Bank, select the WXCASH currency and check Deposit instructions. It will give your deposit ERC-20 address. This address can only be used to deposit WXCASH (Polygon) in.
Depositing anything else than WXCASH (Polygon) on your X-Bank deposit address will result in a permanent loss of your funds.
On your Metamask transfer page, input your X-Bank ERC20 deposit address, the amount you wish to send, and click on Send.
You will need to pay the gas fees to perform any transaction from your Metamask wallet. Because you are on the Polygon network, you will need to use MATIC native token to pay for the gas. You can either buy some on exchange platforms where MATIC is listed, or you can try the MATIC faucet to get enough to perform a few transactions.
Luckily, the transaction fees are really small.
The amount will be credited to your X-Bank account shortly after.
Now that you have WXCASH (Polygon) in your Metamask account, you can use the Polygon Bridge to withdraw them to the Ethereum Chain.
You can connect your Metamask wallet to the Polygon Web Wallet interface. Please follow this guide to help you see your WXCASH (Polygon) in the Polygon Web Wallet.
Once you have connected your Metamask wallet to the Polygon Web Wallet, you will be able to see your WXCASH (Polygon). You can now use the withdraw (to Ethereum) function:
On the next page, select the number of WXCASH (Polygon) that you want to move to the Ethereum chain. They will become WXCASH (Ethereum).
You can then initiate the transfer, where you'll be prompted to validate.
The withdraw to the Ethereum chain will cost you a transaction on the Polygon Network, and a transaction on the Ethereum network.
It means that to complete a withdraw to the Ethereum network, you will need some MATIC on the Polygon Network, as well as some ETH on the Ethereum Network.
Use X-Cash CLI Wallet (xcash-wallet-cli) to interact with a wallet through the terminal
The official command line wallet for X-Cash. Available for Linux, macOS and Windows. Download here
Wallet uses your private keys to compute your total balance, retrieve your transactions history, and sign transactions.
However, wallet does not store the blockchain and does not directly participate in the p2p network.
The CLI wallet is the most reliable, secured and most feature complete wallet for X-Cash.
Wallet connects to a full node to scan the blockchain for your transaction outputs and to send your transactions out to the network. The full node can be either local (same computer) or remote.
The best practice is to run the full node on the same computer as the wallet (or within your home network) and the connection happens over HTTP.
Any transaction leaving the wallet is already blinded by all X-Cash privacy features. This means plain text HTTP communication isn't an issue on its own even if you connect to a remote node.
However, connecting to a remote node has other nuanced trade-offs, such as easiness of use and faster syncing. This happens at the cost of a potential privacy reduction and limited reliability. It is recommended to fully familiarize with the limits of using a remote node vs. a local node before attempting in doing so.
./xcash-wallet-cli [options] [command]
./xcash-wallet-cli --restore-deterministic-wallet
Go to directory where you unpacked X-Cash.
Run the daemon and wait until it syncs up with the network (may take up to a few days depending on your last block height, network speed and CPU available load):
./xcashd
In a separate terminal window, run the wallet:
./xcash-wallet-cli --generate-new-wallet XCashExampleWallet
Option
Description
--help
Enlist available options.
--version
Show xcash-wallet-cli version to stdout. Example: X-CASH '' (v1.5.0-unknown)
(default)
By default wallet assumes mainnet.
--stagenet
Run on stagenet. Remember to run your daemon with --stagenet as well.
--testnet
Run on testnet. Remember to run your daemon with --testnet as well.
--log-file
Full path to the log file.
--log-level <arg>
0-4 with 0 being minimal logging and 4 being full tracing. Defaults to 0. These are general presets and do not directly map to severity levels. For example, even with minimal 0, you may see some most important INFOentries.
--max-log-file-size
Soft limit in bytes for the log file (=104850000 by default, which is just under 100MB). Once log file grows past that limit, x-cash creates the next log file with a UTC timestamp postfix -YYYY-MM-DD-HH-MM-SS. In production deployments, you would probably prefer to use established solutions like logrotate instead. In that case, set --max-log-file-size 0 to prevent x-cash from managing the log files.
--max-log-files
Limit on the number of log files (=50 by default). The oldest log files are removed. In production deployments, you would probably prefer to use established solutions like logrotate instead.
Wallet depends on a full node for all non-local operations. The following options define how to connect to xcashd:
Option
Description
--daemon-address
Use xcashd instance at <host>:<port>. Example: ./xcash-wallet-cli --daemon-address xcash-stagenet.exan.tech:38081 --stagenet
--daemon-host
Use xcashd instance at host <arg> instead of localhost.
--daemon-port
Use xcashd instance at port <arg> instead of 18281.
--daemon-login
Specify username[:password] for xcashd RPC API. It is based on HTTP Basic Auth. Mind that connections are by default un-encrypted. Authentication only makes sense if you establish a secure connection (maybe via Tor, or SSH tunneling, or reverse proxy w/ TLS).
--trusted-daemon
Enable commands and behaviors which rely on xcashd instance being trusted. Default for localhost connection. The trust in this context concerns preserving your privacy. Only use this flag if you do control xcashd. Trusted daemon allows for commands like rescan_spent, start_mining, import_key_images and behaviors like not warning about potential attack on transient problems with transaction sending.
--untrusted-daemon
Disable commands and behaviors which rely on xcashd instance being trusted. Default for a non-localhost connections. See --trusted-daemon for more details.
--do-not-relay
The newly created transaction will not be relayed to the X-Cash network. Instead it will be dumped to a file in a raw hexadecimal format. Useful if you want to push the transaction through a gateway. This may be easier to use over Tor than X-Cash wallet.
--allow-mismatched-daemon-version
Allow communicating with xcashd that uses a different RPC version.
--generate-new-wallet
Create a new X-Cash wallet and save it to <arg> file. You will be asked for a password. The password is used to encrypt the wallet file but it is unrelated to your master spend key or mnemonic seed. Generate a very strong password with your password manager (~256 bits of entropy). Example: ./xcashd-wallet-cli --stagenet --generate-new-wallet $HOME/.bitxcash/stagenet/wallets/XCashExampleStagenetWallet
--kdf-rounds
Concerns encrypting the wallet file. The wallet file is encrypted with ChaCha stream cipher. The encryption key is derived from the user supplied password by hashing the password with CryptoNight. This option defines how many times the CryptoNight hashing will be applied. The default is 1 round of hashing. Note this is unrelated to spend key generation. The more rounds the longer you will wait to open the wallet or send transaction. But also the attacker will have it harder to brute force your wallet password. Note: You will have to remember and provide the same kdf-rounds on every wallet access! Recommendation: Do not change the default value. Instead generate a very strong wallet password with your password manager (256 bits of entropy).
Option
Description
--wallet-file
Open existing wallet. Example: ./xcash-wallet-cli --stagenet --wallet-file $HOME/.bitxc/stagenet/wallets/XCashExampleStagenetWallet This is only for wallet files generated with xcash-wallet-cli, xcash-wallet-gui, or xcash-wallet-rpc tools. If you have other type of wallet then see importing options.
--password
Provide wallet password as a parameter instead of interactively. Remember to escape/quote as needed. Not recommended because the password will remain in your command history and will also be visible in the process table. For automation prefer --password-file. The option also works in combination with --generate-new-wallet.
--password-file
Provide password as a file in stead of interactively. Trailing are discarded when reading the password file. Prefer this over --password if you automate wallet access. Make sure the password file is meaningfully separated from the wallet file. Otherwise it provides no security benefit. The option also works in combination with --generate-new-wallet.
Option
Description
--generate-from-device
Restore/generate a special wallet to work with a hardware device like Ledger or Trezor and save it to <arg> file. Example: ./xcash-wallet-cli --stagenet --generate-from-device XCashExampleDeviceWallet --subaddress-lookahead 5:20 This is a one-time action. Next time you simply open the wallet. By default the command expects Ledger hardware connected. For Trezor hardware add --hw-device Trezor (expected ~May 2019). It will take up to 25 minutes with default settings. This is because hardware devices are slow to pre-generate subaddresses. To mitigate use low --subaddress-lookahead 5:20. The local wallet will not have private spend key and will not be able to spend on its own. It serves as a user interface and a bridge for low-power hardware devices. Transaction signing with a private spend key always happens on the hardware device. See the complete guide to hardware wallet setup.
--generate-from-view-key
Restore a view-only version of the wallet to track incoming transactions and save it to <arg> file. The wallet is created based on a secret view key and standard address. The secret view key is meant to be pasted as hexadecimal.
--generate-from-spend-key
Restore a wallet from secret spend key and save it to <arg> file. The secret spend key is meant to be pasted as hexadecimal.
--restore-deterministic-wallet
Restore a wallet from secret mnemonic seed. Use this to restore from your 25 words backup. You will be asked for a password to encrypt the wallet file (once restored). Note this is not a passphrase to mnemonic seed. Mnemonic seeds generated by X-Cash official wallets are naked.
Option
Description
--generate-from-multisig-keys
Create a standard wallet from multisig keys. This is useful to combine all multisig secret keys back into the standard wallet (when you no longer need the multisig). The wallet will then have control of the funds. It only supports providing all secret keys even if the multisig scheme allowed for less (only N/N not N/M).
--restore-multisig-wallet
Restore a multisig wallet from secret seed that was earlier exported with the seed interactive command. This only restores your part of the wallet. Other multisig participants will still be necessary to sign the transaction.
Option
Description
--config-file
Full path to the configuration file. Note this should be a separate config than xcashduses because these tools accept different set of options.
Option
Description
--subaddress-lookahead
Accepts m:n, by default 50:200. The first value is the number of accounts and the second value is the number of subaddresses per account. The wallet will not check for payments to subaddresses further than naway from the last received payment. This can happen if you generated unique subaddresses for n clients in a row but none of them paid. On the other hand the more subaddresses you set to look ahead, the longer it takes to create your wallet, because they must be pre-computed. This is normally not a concern, except for hardware wallets. On the Ledger the default value of 50:200 can take over 20 minutes (one time on wallet creation)!
--max-concurrency
Max number of threads to use for parallel jobs. The default value 0 uses the number of CPU threads
Option
Description
--mnemonic-language
Language for mnemonic seed words. One of english, english_old, esperanto, french, german, italian, japanese, lojban, portuguese, russian, spanish. It might be a good idea to stick to default English which is by far the most popular and well tested. It also avoids potential non-ASCII characters pitfalls or bugs.
--use-english-language-names
If your display freezes, exit blind with ^C, then run again with --use-english-language-names. This can happen when X-Cash prompts for a language displaying language names in their natives alphabets.
These options are either legacy or rarely useful.
Option
Description
--non-deterministic
Generate legacy non-deterministic wallet. The view key will not be derived from the spend key. You would also have to backup the .keys. To restore non-deterministic wallet (standard address) use --generate-from-keys. To restore fully you will need the .keys file.
--generate-from-keys
Restore legacy non-deterministic wallet by providing both spend and view keys and the standard address.
--shared-ringdb-dir
Set shared ring database path. No longer worthwhile.
--electrum-seed
Provide mnemonic seed as a command line option for --restore-deterministic-wallet instead of interactively. This is not recommended b/c the seed will be saved in your command history and also visible in the process list.
--generate-from-json
You would run xcash-wallet-rpc to use this option.
--tx-notify
You would run xcash-wallet-rpc to use this option.
Wallet files are created and seek in current directory. This is rarely what you want. Use --wallet-file and similar options to control this.
Log files are created in the same directory as xcash-wallet-cli binary. Use --log-file to specify the location.
Commands are used interactively in the xcash-wallet-cli prompt.
You can also run a one-off command by providing it as a commandline parameter. This is rarely useful though. For automation prefer xcash-wallet-rpc.
The CLI wallet has built-in help for individual commands - we will not attempt to reproduce that. Instead we focus on grouping commands so you can quickly find what you are looking for. Use help command_name to learn more.
help - list all commands
help <command> - show help for individual command
version - show version of the xcash-wallet-cli binary
account - total balance; list accounts with respective balances
balance detail - within the current account, list addresses with respective balances
To perform on-chain transaction you should used the function transfer:transfer [<tx_privacy_settings>] [index=<N1>[,<N2>,...]] [<priority>] [<ring_size>] <address> <amount> [<payment_id>]
Option
Description
tx_privacy_settings
Blockchain privacy setting feature, can be public or private. Defaults to private.
index
Index of the transaction.
priority
Priority setting i.e. fee (multiplier) settings, can be [0, 1, 2, 3, 4]
Defaults to 1.
Leads to a multiplication of the base fee per kb of respectively 1x, 4x, 20x, and 166x.
ring_size
Number of possible signers in the ring signature. Defaults and fixed to 21since 1.4.0
address
Recipient address. Should be an XCASH, integrated or subaddress.
amount
Amount to be sent in XCASH.
payment_id
Payment id to be added to the transaction. Defaults to none.
About the fixed ring size
In X-Cash 1.4.0, we introduced a fixed ring size of 21 along with the release of public transactions. This choice has been made to improve significantly the privacy at the cost of an increase of the transaction size which is largely overbalanced by the introduction of bulletproof.
You can also move the entire balance by using the sweep_all command with the same parameters (except the amount) as the transfer command. If you leave sweep_all blank with no parameters it will send a tx back to your wallet. This is helpful in reducing unspents for voting.
Open the wallet file in the xcash-wallet-cli and once the wallet is fully synchronize, type the command:
Replace delegates_public_address|delegates_namewith the delegates public address or delegates name
account
account new
account switch
account label
address all
address new
address label
status - show if synced up to the blockchain height
fee - show current fee-per-byte and full node's mempool (the backlog of transactions depending on the priority)
wallet_info - show wallet file path, standard address, type and network
seed - show raw mnemonic seed
encrypted_seed - create mnemonic seed encrypted with the passphrase; you will need to remember or store the passphrase separately; restoring will not be possible without the passphrase
spendkey - show secret spend key and public spend key
viewkey - show secret view key and public view key
get_reserve_proof -> check_reserve_proof - prove the balance
get_spend_proof -> check_spend_proof - prove you made the payment
sign <file> -> verify <filename> <address> <signature> - prove ownership of the address; allows to verify the file was signed by the owner of specific X-Cash address
get_tx_proof -> check_tx_proof
prepare_multisig
make_multisig
finalize_multisig
export_multisig_info
import_multisig_info
submit_multisig
exchange_multisig_keys
export_raw_multisig_tx
These allow to learn and verify transaction's private key r. This was useful to create a proof of payment but got superseded by get_spend_proof.
get_tx_key <txid>
check_tx_key <txid> <txkey> <address>
set_tx_key <txid> <tx_key>
unspent_outputs - show a list of, and a histogram of unspent outputs (indivisible pieces of your total balance)
export_key_images <file> -> import_key_images <file> - used to inform the view-only wallet about outgoing transactions so it can calculate the real balance; normally view-only wallets only learn about incoming transactions, not outgoing
export_outputs <file> - export a set of outputs owned by this wallet to a <file>
The official X-Cash blockchain documentation to get started and develop with X-Cash. Learn the basic functions and join the validation of the blockchain as an elected delegate.
The X-Cash Foundation is an open-source, no-ICO blockchain project launched in 2018 developing a privacy centered cryptocurrency inheriting from Monero and bringing new innovation in the privacy coin space.
X-Cash main features are:
FlexPrivacy - Private and public transactions on the same blockchain Private by default, X-Cash's FlexPrivacy lets the user decide if he/she wants the transaction to be made public.
Delegated-Proof-of-Private-Stake - X-Cash custom consensus designed for privacy coins X-Cash consensus model gets rid of the decentralized yet unsustainable PoW consensus to propose its own variation of a DPoS with DBFT consensus.
Sidechains - The next step in blockchain hosting X-Cash will make it easy to create and host your own blockchain, while being able to profit from X-Cash's unique features.
The document was written and aggregated by the X-Cash Foundation, the X-Cash development team and contributors. If you would like to learn more about contributing please the visit our Github organization.
Looking to use X-Cash but don't know where to start? Check our list of quick guides:
What are you looking for?
Description
I want to connect to the network and create a node.
I want to stake my XCASH.
You can stake your XCASH towards a delegate and earn rewards depending on your vote. Check our our stake and voting section.
I want to become a delegate and start forging X-Cash.
You want to be part of the limited delegates that have the power to forge the next block? Have a look a our set up a delegate node guide.
I want to create/open a wallet.
How can I interact with the wallet or daemon?
I want to import a blockchain file.
I am looking for the API.
Check out our API section.
X-Cash website - The official website of the X-Cash project.
X-Cash official blog - Read about the latest development of X-Cash
X-Cash explorer - See your ongoing transactions and explorer the X-CASH blockchain.
GitHub - The X-Cash source code and related repositories.
X-Network - Check everything about X-Cash related development from the founding team.
Help Center - If you encounter a bug, or want to communicate on improvements.
Discord - Engage with the community, ask questions and talk with the team.
Twitter - Follow us for weekly updates, contests and community polls.
Reddit - Join the Reddit community
Telegram - Get the latest news and announcement of anything X-CASH related
FlexPrivacy - Public and Private transactions on the X-Cash blockchain.
DPoPS - Delegated Proof-of-Private-Stake, a DPoS implementation under X-Cash.
As a fork of Monero, most of the basic functions of X-Cash are already documented. These functions are transcribed from the official Monero documentation:
Use the X-Cash Daemon (xcashd) to create a node, sync the blockchain and relay transactions.
The X-Cash daemon xcashd keeps your computer synced up with the X-Cash network.
It downloads and validates the blockchain from the other nodes.
xcashd is entirely decoupled from your wallet.
xcashd does not access your private keys and therefore doesn't know your transactions and balance.
This means that you can run xcashdon a separate computer or in the cloud and access it remotely to retrieve/provide the data needed for wallet operations.
In practice, you can connect to a remotexcashdinstance provided by a semi-trusted 3rd party. Such 3rd party will not be able to steal your funds as all transactions are signed locally.
However, there are privacy and reliability implications when using a remote, untrusted node. For any real business we recommend running your own full node.
To provide a better reliability and trust, the team has setup a several public remote nodes across different locations:
Name
Location
usseed1.x-cash.org:18281
US - Oregon
usseed2.x-cash.org:18281
US - Virginia
euseed1.x-cash.org:18281
Europe - Germany
euseed3.x-cash.org:18281
Europe - France
asiaseed2.x-cash.org:18281
Asia - Singapore
./xcashd [options] [command]
Options define how the daemon should be working and are optional. Their names follow the --option-name convention.
Commands give access to specific services provided by the daemon. Commands are executed against the running daemon. Their names follow the command_name convention.
Go to directory where you unpacked X-Cash.
For learning and experimentation, you should stick to the testnet to avoid any wrong manipulation.
By default, the daemon connects to the mainnet. If you want to use real XCASH there is no need to add a specific argument.
Options define how the daemon should be working. Their names follow the --option-nameconvention.
The following groups are only to make reference easier to follow. The daemon itself does not group options in any way.
Option
Description
--help
Enlist available options.
--version
Show xcashd version to stdout. Example: X-CASH '' (v1.5.0-unknown)
--os-version
Show build timestamp and target operating system. Example output: OS: Microsoft (build 17763), 64-bit
Option
Description
(missing)
By default xcashd assumes mainnet.
--stagenet
Run on stagenet. Remember to run your wallet with --stagenet as well.
--testnet
Run on testnet. Remember to run your wallet with --testnet as well.
Option
Description
--log-file
Full path to the log file. Example (make sure your file permissions are correctly setup): ./xcashd --log-file=/var/log/xcash/mainnet/xcash.log
--log-level
0-4 with 0 being minimal logging and 4 being full tracing. Defaults to 0. These are general presets and do not directly map to severity levels. For example, even with minimal 0, you may see some most important INFO entries. Temporarily changing to 1 allows for much better understanding of how the full node operates. Example: ./xcashd --log-level=1
--max-log-file-size
Soft limit in bytes for the log file (=104850000 by default, which is just under 100MB). Once log file grows past that limit, xcashd creates the next log file with a UTC timestamp postfix -YYYY-MM-DD-HH-MM-SS. In production deployments, you would probably prefer to use established solutions like logrotate instead. In that case, set --max-log-file-size=0 to prevent xcashd from managing the log files.
--max-log-files
Limit on the number of log files (=50 by default). The oldest log files are removed. In production deployments, you would probably prefer to use established solutions like logrotate instead.
xcashd defaults are adjusted for running it occasionally on the same computer as your X-Cash wallet.
The following options will be helpful if you intend to have an always running node — most likely on a remote server or your own separate PC.
Option
Description
--config-file
Full path to the configuration file. By default xcashd looks for bitxcash.conf in X-Cash data directory.
--data-dir
Full path to data directory. This is where the blockchain, log files, and p2p network memory are stored. For defaults and details see data directory.
--pidfile
Full path to the PID file. Works only with --detach.
Example: ./xcashd --detach --pidfile=/run/xcash/xcashd.pid
--detach
Go to background (decouple from the terminal). This is useful for long-running / server scenarios. Typically, you will also want to manage xcashd daemon with systemd or similar. By default xcashd runs in a foreground.
--non-interactive
Do not require tty in a foreground mode. Helpful when running in a container. By default xcashd runs in a foreground and opens stdin for reading. This breaks containerization because no tty gets assigned and xcashd process crashes. You can make it run in a background with --detach but this is inconvenient in a containerized environment because the canonical usage is that the container waits on the main process to exist (forking makes things more complicated).
--no-igd
Disable UPnP port mapping on the router ("Internet Gateway Device"). Add this option to improve security if you are not behind a NAT (you can bind directly to public IP or you run through Tor).
--max-txpool-weight
Set maximum transactions pool size in bytes. By default 648000000 (~618MB). These are transactions pending for confirmations (not included in any block).
--enforce-dns-checkpointing
The emergency checkpoints set by X-CashPulse operators will be enforced. It is probably a good idea to set enforcing for unattended nodes.
If encountered block hash does not match corresponding checkpoint, the local blockchain will be rolled back a few blocks, effectively blocking following what X-CashPulse operators consider invalid fork.
The log entry will be produced: ERROR Local blockchain failed to pass a checkpoint, rolling back! Eventually, the alternative ("fixed") fork will get heavier and the node will follow it, leaving the "invalid" fork behind.
By default checkpointing only notifies about discrepancy by producing the following log entry: ERRORWARNING: local blockchain failed to pass a xcashPulse checkpoint, and you could be on a fork. You should either sync up from scratch, OR download a fresh blockchain bootstrap, OR enable checkpoint enforcing with the --enforce-dns-checkpointing command-line option As of 04/09/2019, X-Cash has not implemented X-CashPulse operators.
--disable-dns-checkpoints
The X-CashPulse checkpoints set by core developers will be discarded.
As of 04/09/2019, X-Cash has not implemented the X-CashPulse operators feature.
The following options define how your node participates in X-Cash peer-to-peer network. This is for node-to-node communication. The following options do not affect wallet-to-node interface.
The node and peer words are used interchangeably.
Option
Description
--p2p-bind-ip
Network interface to bind to for p2p network protocol. Default value 0.0.0.0 binds to all network interfaces and should be used in general working conditions. You must change this if you want to constrain binding, for example to configure connection through Tor via torsocks: DNS_PUBLIC=tcp://1.1.1.1 TORSOCKS_ALLOW_INBOUND=1 torsocks ./xcashd --p2p-bind-ip 127.0.0.1 --no-igd --hide-my-port
--p2p-bind-port
TCP port to listen for p2p network connections. Defaults to 18281 for mainnet, 28281 for testnet, and 38281 for stagenet. You normally wouldn't change that. This is helpful to run several nodes on your machine to simulate private a X-Cash p2p network (likely using private testnet). Example: ./xcashd --p2p-bind-port=48080
--p2p-external-port
TCP port to listen for p2p network connections on your router. Relevant if you are behind a NAT and still want to accept incoming connections. You must then set this to relevant port on your router. This is to let xcashd know what to advertise on the network. By default this value is 0.
--hide-my-port
xcashd will still open and listen on the p2p port. However, it will not announce itself as a peer list candidate. Technically, it will return port 0 in a response to p2p handshake (node_data.my_port = 0 in get_local_node_data function). In effect nodes you connect to won't spread your IP to other nodes. To sum up, it is not really hiding, it is more like "do not advertise".
--seed-node
Connect to a node to retrieve other nodes' addresses, and disconnect. If not specified, xcashd will use hardcoded seed nodes on the first run, and peers cached on disk on subsequent runs.
--add-peer
Manually add node to local peer list.
--add-priority-node
Specify list of nodes to connect to and then attempt to keep the connection open. To add multiple nodes use the option several times. Example: ./xcashd --add-priority-node=178.128.192.138:18081 --add-priority-node=144.76.202.167:18081
--add-exclusive-node
Specify list of nodes to connect to only. If this option is given the options --add-priority-node and --seed-node are ignored. To add multiple nodes use the option several times. Example: ./xcashd --add-exclusive-node=178.128.192.138:18081 --add-exclusive-node=144.76.202.167:18081
--out-peers
Set max number of outgoing connections to other nodes. By default 8. Value -1represents the code default.
--in-peers
Set max number of incoming connections (nodes actively connecting to you). By default unlimited. Value -1 represents the code default.
--limit-rate-up
Set outgoing data transfer limit [kB/s]. By default 2048 kB/s. Value -1 represents the code default.
--limit-rate-down
Set incoming data transfer limit [kB/s]. By default 8192 kB/s. Value -1 represents the code default.
--limit-rate
Set the same limit value for incoming and outgoing data transfer. By default (-1) the individual up/down default limits will be used. It is better to use --limit-rate-upand --limit-rate-down instead to avoid confusion.
--offline
Do not listen for peers, nor connect to any. Useful for working with a local, archival blockchain.
--allow-local-ip
Allow adding local IP to peer list. Useful mostly for debug purposes when you may want to have multiple nodes on a single machine.
xcashd node offers a powerful API. It serves 3 purposes:
provides network data (stats, blocks, transactions, ...)
provides local node information (peer list, hash rate if mining, ...)
provides interface for wallets (send transactions, ...)
This API is typically referred to as "RPC" because it is mostly based on JSON/RPC standard.
The following options define how the API behaves.
Option
Description
--rpc-bind-ip
IP to listen on. By default 127.0.0.1 because API gives full administrative capabilities over the node. Set it to 0.0.0.0 to listen on all interfaces - but only in connection with one of *-restricted-* options and --confirm-external-bind.
--rpc-bind-port
TCP port to listen on. By default 18281 (mainnet), 28281 (testnet), 38281(stagenet).
--rpc-restricted-bind-port
TCP port to listen on with the limited version of API. The limited API can be made public to create an Open Node. At the same time, you may firewall the full API port to still enjoy local querying and administration.
--confirm-external-bind
Confirm you consciously set --rpc-bind-ip to non-localhost IP and you understand the consequences.
--restricted-rpc
Restrict API to view only commands and do not return privacy sensitive data. Note this does not make sense with --rpc-restricted-bind-portbecause you would end up with two restricted APIs.
--rpc-login
Specify username[:password] required to connect to API. Practical usage is limited because API communication is in plain text over HTTP.
--rpc-access-control-origins
Specify a comma separated list of origins to allow cross origin resource sharing. This is useful if you want to use xcashd API directly from a web browser via JavaScript (say in a pure-fronted web appp scenario). With this option xcashd will put proper HTTP CORS headers to its responses. You will also need to set --rpc-login if you use this option. Normally though, the API is used by backend app and this option isn't necessary.
These are network notifications offered by xcashd. There are also wallet notifications like --tx-notify offered by xcashd-wallet-rpc here.
Option
Description
--block-notify
Run a program for each new block. The <arg> must be a full path. If the <arg>contains %s it will be replaced by the block hash. Example: ./xcashd --block-notify="/usr/bin/echo %s" Block notifications are good for immediate reaction. However, you should always assume you will miss some block notifications and you should independently poll the API to cover this up. Mind blockchain reorganizations. Block notifications can revert to same and past heights. Small reorganizations are natural and happen every day.
--block-rate-notify
Run a program when the number of blocks received in the recent past deviates significantly from the expectation. The <arg> must be a full path. The <arg> can contain any of %t, %b, %e symbols to interpolate: %t: the number of minutes in the observation window %b: the number of blocks observed in that window %e: the ideal number of blocks expected in that window The option will let you know if the network hash rate drops by a lot. This may be indicative of a large section of the network miners moving off to mine a private chain, to be later released to the network. Note that if this event triggers, it is not incontrovertible proof that this is happening. It might just be chance. The longer the window (the %t parameter), and the larger the distance between actual and expected number of blocks, the more indicative it is of a possible chain reorg double-spend attack being prepared. Recommendation: unless you run economically significant X-Cash exchange or operation, do not act on this data. It is hard to calibrate and easy to misinterpret. If this is a real attack, it will target high-liquidity entities and not small merchants.
--reorg-notify
Run a program when reorganization happens (ie, at least one block is removed from the top of the blockchain). The <arg> must be a full path. The <arg> can contain any of %s, %h, %n symbols to interpolate: %s: the height at which the split occurs %h: the height of the new blockchain %d: the number of blocks discarded from the old chain %n: the number of blocks being added The option will let you know when a block is removed from the chain to be replaced by other blocks. This happens when a 51% attack occurs, but small reorgs also happen in the normal course of things. The %d parameter will be set to the number of blocks discarded from the old chain (so if this is higher than the number of confirmations you wait to act upon an incoming payment, that payment might have been cancelled). The %n parameter wil be set to the number of blocks in the new chain (so if this is higher than the number of confirmations you wait to act upon an incoming payment, any incoming payment in the first block will be automatically acted upon by your platform). Recommendation: unless you run economically significant X-Cash exchange or operation, you do not need to bother with this option. Simply account for reorganizations by requiring at least 10 confirmations to consider payments no reversible.
These are advanced options that allow you to optimize performance of your xcashd node, sometimes at the expense of reliability.
Option
Description
--db-sync-mode
Specify sync option, using format: `[safe fast
fast
fastest]:[sync
async]:[[blocks]
[bytes]]The default isfast:async:250000000bytes. Thefast:async:*can corrupt blockchain database in case of a system crash. It should not corrupt if justxcashdcrashes. If you are concerned with system crashes usesafe:sync`.
--max-concurrency
Max number of threads to use for parallel jobs. The default value 0 uses the number of CPU threads.
--prep-blocks-threads
Sync up most of the way by using embedded, "known" block hashes. Pass 1to turn on and 0 to turn off. This is on (1) by default. Normally, for every block the full node must calculate the block hash to verify miner's proof of work. Because the CryptoNight PoW used in X-Cash is very expensive (even for verification), xcashd offers skipping these calculations for old blocks. In other words, it's a mechanism to trust xcashd binary regarding old blocks' PoW validity, to sync up faster.
--block-sync-size
How many blocks are processed in a single batch during chain synchronization. By default this is 20 blocks for newer history and 100 blocks for older history ("pre v4"). Default behavior is represented by value 0. Intuitively, the more resources you have, the bigger batch size you may want to try out. Example: ./xcashd --block-sync-size=500
--bootstrap-daemon-address
The host:port of a "bootstrap" remote open node that the connected wallets can use while this node is still not fully synced. Example: ./xcashd --bootstrap-daemon-address=opennode.xmr-tw.org:18089. The node will forward selected RPC calls to the bootstrap node. The wallet will handle this automatically and transparently. Obviously, such bootstraping phase has privacy implications similar to directly using a remote node.
--bootstrap-daemon-login
Specify username:password for the bootstrap daemon login (if required). This considers the RPC interface used by the wallet. Normally, open nodes do not require any credentials.
Mining functions will not work anymore under X-Cash 2.0
The following options configure solo mining using CPU with the standard software stack xcashd. This is mostly useful for:
generating your stagenet or testnet coins
experimentation and learning
if you have super cheap access to vast CPU resources
Be advised though that real mining happens in pools and with high-end GPU-s instead of CPU-s.
Note: On block 281000, X-Cash switched to Cryptonight HeavyX algorithm which is ASIC and NiceHash resistant.
Option
Description
--start-mining
Specify wallet address to mining for. This must be a standard address! It can be neither a subaddres nor integrated address.
--mining-threads
Specify mining threads count. By default ony one thread will be used. For best results, set it to number of your physical cores.
--extra-messages-file
Specify file for extra messages to include into coinbase transactions.
--bg-mining-enable
Enable unobtrusive mining. In this mode mining will use a small percentage of your system resources to never noticeably slow down your computer. This is intended to encourage people to mine to improve decentralization. That being said chances of finding a block are diminishingly small with solo CPU mining, and even lesser with its unobtrusive version. You can tweak the unobtrusivness / power trade-offs with the further --bg-*options below.
--bg-mining-ignore-battery
If true, assumes plugged in when unable to query system power status.
--bg-mining-min-idle-interval
Specify min lookback interval in seconds for determining idle state.
--bg-mining-idle-threshold
Specify minimum avg idle percentage over lookback interval.
--bg-mining-miner-target
Specify maximum percentage cpu use by miner(s).
These options are useful for X-Cash project developers and testers. Normal users shouldn't be concerned with these.
Option
Description
--test-drop-download
For net tests: in download, discard ALL blocks instead checking/saving them (very fast).
--test-drop-download-height
Like test-drop-download but discards only after around certain height. By default 0.
--regtest
Run in a regression testing mode.
--fixed-difficulty
Fixed difficulty used for testing. By default 0.
--test-dbg-lock-sleep
Sleep time in ms, defaults to 0 (off), used to debug before/after locking mutex. Values 100 to 1000 are good for tests.
--save-graph
Save data for dr X-Cash.
These options should no longer be necessary but are still present in xcashd for backwards compatibility.
Option
Description
--fluffy-blocks
Relay compact blocks. Default. Compact block is just a header and a list of transaction IDs.
--no-fluffy-blocks
Relay classic full blocks. Classic block contains all transactions
--show-time-stats
Official docs say "Show time-stats when processing blocks/txs and disk synchronization" but it does not seem to produce any output during usual blockchain synchronization.
--zmq-rpc-bind-ip
IP for ZMQ RPC server to listen on. By default 127.0.0.1. This is not yet widely used as ZMQ interface currently does not provide meaningful advantage over classic JSON-RPC interface. Unfortunately, currently there is no way to disable the ZMQ server.
--zmq-rpc-bind-port
Port for ZMQ RPC server to listen on. By default 18082 for mainnet, 38082 for stagenet, and 28082 for testnet.
--db-type
Specify database type. The default and only available: lmdb.
Commands give access to specific services provided by the daemon. Commands are executed against the running daemon. Their names follow the command_name convention.
The following groups are only to make reference easier to follow. The daemon itself does not group commands in any way.
See running for example usage. You can also type commands directly in the console of the running xcashd (if not detached).
Option
Description
help [<command>]
Show help for <command>.
version
Show version information. Example output: X-CASH '' (v1.5.0-unknown)
status
Show status. Example output: Height: 424951/424951 (100.0%) on mainnet, not mining, net hash 2.38 MH/s, v12, update needed, 8(out)+0(in) connections, uptime 0d 1h 18m 25s
Option
Description
print_pl
Show the full peer list.
print_pl_stats
Show the full peer list statistics (white vs gray peers). White peers are online and reachable. Grey peers are offline but your xcashd remembers them from past sessions.
print_cn
Show connected peers with connection initiative (incoming/outgoing) and other stats.
ban <IP> [<seconds>]
Ban a given <IP> for a given amount of <seconds>. By default the ban is for 24h. Example: ./xcashd ban 187.63.135.161
unban <IP>
Unban a given <IP>.
bans
Show the currently banned IPs. Example output: 187.63.135.161 banned for 86397 seconds.
in_peers <max_number>
Set the of incoming connections from other peers.
out_peers <max_uber>
Set the of outgoing connections to other peers.
limit [<kB/s>]
Get or set the download and upload limit.
limit_down [<kB/s>]
Get or set the download limit.
limit_up [<kB/s>]
Get or set the upload limit.
Option
Description
flush_txpool [<txid>]
Flush specified transaction from transactions pool, or flush the whole transactions pool if was not provided.
print_pool
Print the transaction pool using a verbose format.
print_pool_sh
Print the transaction pool using a short format.
print_pool_stats
Print the transaction pool's statistics (number of transactions, memory size, fees, double spend attempts etc).
Option
Description
print_coinbase_tx_sum <start_height> [<block_count>]
Show a sum of all emitted coins and paid fees within specified range. Example: ./xcashd print_coinbase_tx_sum 0 1000000000000
print_tx <transaction_hash> [+hex] [+json]
Show specified transaction as JSON and/or HEX.
relay_tx <txid>
Force relaying the transaction. Useful if you want to rebroadcast the transaction for any reason or if transaction was previously created with "do_not_relay":true.
Option
Description
print_height
Show local blockchain height.
sync_info
Show blockchain sync progress and connected peers along with download / upload stats.
print_bc <begin_height> [<end_height>]
Show detailed data of specified block.
hard_fork_info
Show current consensus version and future hard fork block height, if any.
is_key_image_spent <key_image>
Check if specified key image is spent. Key image is a hash.
Option
Description
exit, stop_daemon
Ask daemon to exit gracefully. The exit and stop_daemon are identical (one is alias of the other).
set log <{+,-,}categories>
Set the current log level/categories where <level> is a number 0-4
print_status
Show if daemon is running.
update (check download)
Check if update is available and optionally download it. The hash is SHA-256. On linux use sha256sum to verify. Example output: Update available: v0.13.0.4: https://downloads.getxcash.org/cli/xcash-linux-x64-v0.13.0.4.tar.bz2, hash 693e1a0210201f65138ace679d1ab1928aca06bb6e679c20d8b4d2d8717e50d6 Update downloaded to: /opt/xcash-v0.13.0.2/xcash-linux-x64-v0.13.0.4.tar.bz2
Mining functions will not work anymore under X-Cash 2.0
Option
Description
show_hr
Ask xcashd daemon to stop printing current hash rate. Relevant only if xcashd is mining.
hide_hr
Ask xcashd daemon to print current hash rate. Relevant only if xcashdis mining.
start_mining <adr> [<threads>] [do_background_mining] [ignore_battery]
Ask xcashddaemon to start mining. Block reward will go to <addr>.
stop_mining
Ask xcashd daemon to stop mining.
Option
Description
start_save_graph
Start saving data for dr X-Cash.
stop_save_graph
Stop saving data for dr X-Cash.
Option
Description
save
Flush blockchain data to disk. This is normally no longer necessary as xcashd saves the blockchain automatically on exit.
output_histogram [@<amount>] <min_count> [<max_count>]
Show number of outputs for each amount denomination. This was only relevant in the pre-RingCT era. The old wallet used this to determine which outputs can be used for the requested mixin. With RingCT denominations are irrelevant as amounts are hidden. More info in these SA answers.
A step-by-step guide to install and set up the DPoPS program on your XCASH node and become a delegate.
This guide is assuming that you have already followed the step of the server setup guide, or that you are comfortable and knowledgeable about your Linux instance.
This guide will walk you through installing, registering, and preparing a delegate node on your instance. Whether you are experienced in Linux or completely new to it, you will be able, at the end of the guide, to have your delegate node running and start securing the X-Cash public network (provided you get elected as a delegate 😉).
The xcash-dpops program is used to manage the block validation, communicate with the other delegates and forge blocks. It has also been designed to automatically retribute the voters of their shares.
In the first beta version, X-Cash's DPoPS will only run on a Linux/Unix OS. We recommend installing it on a Ubuntu VPS/dedicated server (18.04) for the best compatibility.
The delegate node will need to transit a lot of information, notably messages to the other delegates to verify the block information, As time goes by, the features and information that the delegates handle will increase (notably when the X-Cash Foundation will add token creation, NFT, sidechains, smart contracts, and other exciting features ⭐).
The recommended system requirement is designed to be future-development proof, meaning that a hardware update should never be needed and still comfortably handle the xcash-dpops program.
Minimum
Recommended
OS
Ubuntu 18.04
Ubuntu 18.04 or 20.04
CPU
4 threads, 2.0 GHz or more per thread
4 threads, 2.0 GHz or more per thread
RAM
6GB
32GB
Hard Drive
50GB
2TB
Bandwidth Transfer
100GB per month
500GB per month
Bandwidth Speed
100 Mbps
500 Mbps
It is estimated that the blockchain and decentralized database size will increase by 9GB per year.
The minimum requirements will suffice at the inception of the new consensus. However, as new features are brought to the program and the blockchain, hardware updates will be needed.
The dependencies will be automatically installed and updated with the installation script.
The following table summarizes the tools and libraries required to run xcash-dpops program.
Dependencies
Min. version
Ubuntu package
GCC
4.7.3
build-essential
CMake
3.0.0
cmake
pkg-config
any
pkg-config
OpenSSL
any
libssl-dev
Git
any
git
MongoDB
4.0.3
MongoDB C Driver (includes BSON library)
1.13.1
xcash-core
Latest version
The xcash-dpops program uses the system time to calibrate itself and get the signal to send and receive data. It is important that the system time is accurate, otherwise, the program will not work as intended.
To check your system time, use the following command, and verify that the setting System clock synchronization: yes
If it says no, run the following command:
The Installer Script has been designed to easily interact with the xcash-dpops program and provide easy steps for installation and updates. You can also use this script to restart the programs if you are not comfortable with the command-line interface.
To run the latest version of the installer script, run the following command that will fetch the autoinstaller.sh script from the official xcash-dpops repository:
You will be prompted with the installer menu of the xcash-dpops program:
The installation script enables you to install and manage your xcash-dpops program easily.
Before starting, it is recommended to start the installer script in a multiplexer window such as byobu to avoid corrupted installation in case of SSH disconnection.
Once you have prepared your Linux instance by following the server setup guide, you can run the installer script to easily install, build and configure the node, as well as download the blockchain.
xcash-dpops is the program needed to run and manage a delegate node. It is responsible for sending messages to the other delegates, organize the consensus, relay and forge new blocks, etc...
To start the installation process, run the latest version of the autoinstaller.sh script:
Choose Install (1) in the X-Cash DPoPS Installation Settings section and press ENTER
You will be prompted to choose different installation directories for:
The xcash-dpops program
The blockchain file
The delegate database
We very highly recommend using the default locations, as several update and installation programs are referencing to these paths.
You will be then asked if you want to configure the xcash-dpops program as a shared delegate or a solo delegate.
Shared Delegates - Rely on the vote of others to be elected into the top 50 and get a forging position. By choosing the shared delegates options, the program will configure your node to automatically retribute your voters. Later, when configuring your node, you will be able to chose a private group. This option enables you to choose which voters you decide to retribute. This option should be preferred if you are running a delegate node with a close group of people. You can configurate a private group in the Register delegate section.
If you wish to run a shared delegate node, you will have to prefund the delegate wallet to ensure that the first block reward payments can be sent without issue.
Solo Delegates - In some cases, delegates who owns a consequent amount of XCASH can be "elected" in the top 50 by voting for themselves. They don't need to setup fees as the block reward will be distributed to the delegate wallet. Solo delegates have to manually empty the delegate wallet and send the block reward to the wallet of their choice.
You will be able to change this setting whenever you want in the installer script menu (option 9).
Press ENTER for the default setting (shared delegate), or type No for solo delegate.
If you choose to install the program as a shared delegate, you will need to set up your delegate fee and the minimum payment amount.
The shared delegate fee is the percentage of fees that are taken from the reward and kept by the delegate. It can be used to pay for the server hosting, to finance projects in the X-Cash ecosystem, etc...
Type in your desired delegate fee expressed in % with up to 6 decimals.
The xcash-dpops program will set up a wallet service that will automatically handle the payment of the voters, just like a mining pool would.
The shared delegate minimum payment amount is the minimal threshold of XCASH to be sent periodically to the delegate's voters.
Type your desired minimum payment amount (minimum: 10,000 XCASH, maximum: 10M XCASH) as a whole number.
You will be asked to provide a wallet to receive the block reward when you are forging a new block.
You can either restore an existing wallet or choose to create a new wallet.
Leave empty or type YES to create a new wallet, or type No to choose to restore an existing wallet using the mnemonic seed.
Create a new wallet - If you choose to create a new wallet (YES), the installer will then ask you if you want to automatically generate a password for the wallet or provide a custom one. Press ENTER for the default setting (YES), or type No to provide a custom password.
Restore a wallet - If you choose to not to create a new wallet and restore an existing one instead (No), the installer will ask you to provide your wallet mnemonic seed and a new password.
Your block verifier key is used to identify yourself as a delegate. It is mandatory to store it securely. You will be asked if you want to create a new block verifier secret key, or import an existing one:
Type I to import your secret key, or C to create a new one.
Generate the block verifier keys - If it is your first time setting up a delegate node, you will need to generate a new block verifier key pair (C). By choosing to generate a new key pair, it will automatically be added to your xcash-dpops settings
Import the block verifier keys - If you already have a block verifier key, you can choose to import it (I). The program will then ask you to give your block verifier private key.
You will most likely already have a block verifier key pair if you have already registered as a delegate in the past and are just trying to reinstall the node program.
Once these settings have been provided, you will have an installation summary displayed.
The wallet password you have chosen or generated automatically will be displayed again at the end of the installation process. It is however a good idea to save it now.
The script will then install automatically the different programs and dependencies needed for the xcash-dpops program.
The installation script will follow automatically the next step of installation. Some of these steps might take a while.
Indeed, the script will download the blockchain (~16GB as of 01/06/2020), create a new wallet and synchronize it.
Depending on your server connection and specifications this could take up to several hours.
Once the script has installed everything, you will be prompted with your X-Cash Delegate wallet data.
Make sure to copy this information in a secure place, as this is the wallet that will receive the block reward. You will need the block verifiers key to register yourself as a delegate. Losing this information will result in a loss of funds.
By default, the wallet is named delegate-wallet and is stored in ~/xcash-official/xcash-wallets/
Now that the program is installed, your delegate wallet initialized, and the different services running, you can go register yourself as a delegate. Follow the register delegate guide to continue the node setup.
Once your server is set up and the necessary programs installed, you will be able to register yourself as a delegate.
Once you have correctly set up your instance, installed the different programs, you can now register as a delegate of the X-Cash Public Network. You will need to have all the services already running to generate the necessary parameters to register yourself as a delegate.
You should have noted your block verifier keys during the program installation. You will need to prepare a delegate name, your server IP address or domain name, and the block verifier public key. Furthermore, you will have to register from the wallet you will be used to collect the reward.
Chose your delegate name wisely as you won't be able to change it down the line. If you want to change the name, you will have to generate a new block verifier key pair and register yourself again, but you will however lose your previous delegate stats.
First of all, the wallet service should be running in the background. Stop it by using the command:
Open and let synchronize your wallet generated during the node installation, either when using the auto-installer or created manually.
Replace the <WALLET_NAME> with your own.
If you installed with the auto-installer script, the wallet name will be delegate-wallet
Once your wallet is fully synchronized, you can use the delegate_register command with the following parameters:
And replace the information with:
<delegate_name>: the name that will be displayed on the delegate explorer. Cannot be updated.
<IP_address|domain_name> : your server's IP address or its domain name (if you have bought a domain name and correctly set up the DNS record). It is recommended to register your delegate using your domain name, as you can redirect your server IP address to it easily in your DNS record, enabling you to change server in the future.
It is however possible to change this information at a later time. Can be updated.
<block_verifier_public_key> : the block verifier public key that you have generated earlier. Cannot be updated.
Example:
You will be prompted to wait for the next valid data interval. Once your request has been accepted, you will receive the message The delegate has been registered successfully.
You can check in the delegates explorer if your node is correctly appearing.
You can exit the wallet, and restart the wallet service:
Each registered delegates will be displayed in the delegates explorer, along with their statistics and information. At registration, the minimum information that is displayed is your delegate name and IP address. You can add additional instructions to help others identify you or rally to your cause and vote for you.
First of all, the wallet service should be running in the background. Stop it by using the command:
Open and let synchronize the wallet you used to register as a delegate, either when using the auto-installer or created manually.
Replace the <WALLET_NAME> with your own.
If you installed with the autoinstaller script, the wallet name will be delegate-wallet
Once your wallet is fully synchronized, you can use the delegate_update command with the following parameters:
Replace the <item> with one of the lists below, and change the corresponding <value>
Item
Type
Description
about
String (1024 char. max.)
Short description about you and your motivations as a delegate.
Example:
delegate_update about Even the smallest delegate can change the course of the future.
IP_address
String (255 char. max.)
Update the IP address or domain name of your delegate node. Must be in IPV4 format
Example:
delegate_update IP_address mydomain.com
website
String (255 char. max.)
Link to your landing page or website relating to your delegate information and statistics.
Example:
delegate_update website my-delegate-website.com
team
String (255 char. max.)
In case of delegate node managed by several persons. Can be a team name, names or GitHub profiles.
Example: delegate_update team Manager: @tic | Treasury: @tac
shared_delegate_status
String (255 char. max.)
solo: for a solo delegates.
shared: for shared delegates. Shared delegates set up a fee and redistribute a share of the reward to their voters.
Example: delegate_update shared_delegate_status group
delegate_fee
Number
[0 - 100] with up to 6 decimals
Fees (in percentage) taken by the shared delegate on the block reward. Provide the fee you have used during the node installation.
Example: delegate_update delegate_fee 12.354321
server_specs
String (255 char. max.)
A description of the servers' specifications and hardware.
Example: delegate_update server_specs Operating System = Ubuntu 20.04 - CPU = 6 threads (Intel E5-2630 v4 - 2.20GHz) - RAM = 16GB DDR4 - Hard drive = 400GB SSD - Bandwidth Transfer = Unlimited
You will be prompted to wait for the next valid data interval. Once your request has been accepted, you will receive the message The delegate info has been updated successfully.
You can exit the wallet and restart the wallet service:
A shared delegate can choose to run a private group, where the delegate decide which voters is getting a share of the block reward. This set up is favorable for people running a shared delegate group with a closed group of people, and only want to retribute this select group.
To change this setting, you will need to make some changes in the xcash-dpops.service and create a special configuration file that will list the wallet address you wish to send block reward payments to.
First, you will need to create a configuration file that will list the wallet address you will distribute to.
Then, you will need to add the addresses to distribute to in your list following the following format:
Where voting-address is the wallet address used to vote for the delegate, and payment-address is the wallet you want to distribute the share of the block reward to.
The voting-address and payment-address can be the same.
The maximum amount of payment-address that can be in the list is 100.
Once the config file is ready, save it and close. You will need to update the xcash-dpops.service so it can get the configuration file. First, run the stop program option in the installer script:
And choose option 13. Once the programs are stopped, open the xcash-dpops.service located in /lib/systemd/system/and add the parameter --private-group <path-to-configuration-file>to the ExecStart line.
Once done, save your changes and restart the programs by running the option 12 of the auto-installer script.
As a shared delegate (normal or private group), you will have to distribute a share of the block reward to your voters. On the first payment threshold, the program will automatically distribute the voters' share from the delegate wallet. However, the delegate wallet is empty at first and you might be missing some unspents to conveniently pay your voters.
It is recommended to pre-fund your delegate wallet when first setting it up. We recommend pre-funding between 500k to 1M XCASH into the delegate wallet.
Note zachys (atomic units) are 10^6 in X-Cash
This method gets the stats
Method: GET
Inputs: None.
Results:
totalUsers - unsigned int; Total users registered.
avgTipAmount - unsigned int; Average tip amount sent in zachys (atomic units).
totalDeposits - unsigned int; Total deposits.
totalWithdraws - unsigned int; Total withdraws.
totalTipsPublic - unsigned int; Total public tips sent.
totalTipsPrivate - unsigned int; Total private tips sent.
totalVolumeSentPublic - unsigned long long; Total volume sent for public tips, in zachys (atomic units).
totalVolumeSentPrivate - unsigned long long; Total volume sent for private tips, in zachys (atomic units).
totalTipsLastDayPublic - unsigned int; Total public tips sent in last day.
totalTipsLastDayPrivate - unsigned int; Total private tips sent in last day.
totalVolumeSentLastDayPublic - unsigned long long; Total volume sent for public tips in last day, in zachys (atomic units).
totalVolumeSentLastDayPrivate - unsigned long long; Total volume sent for private tips in last day, in zachys (atomic units).
totalTipsLastHourPublic - unsigned int; Total public tips sent in last hour.
totalTipsLastHourPrivate - unsigned int; Total private tips sent in last hour.
totalVolumeSentLastHourPublic - unsigned long long; Total volume sent for public tips in last hour, in zachys (atomic units).
totalVolumeSentLastHourPrivate - unsigned long long; Total volume sent for private tips in last hour, in zachys (atomic units).
This method gets the daily amount of payments and volumes sent per day
Method: GET
Resources:
start - Required - The start day to return data (Default is 1, the first start day).
limit - Required - The maximum amount of days to return (Default is all).
Inputs: None.
Results:
Array of objects with the following structure:
time - unsigned int; Total users registered.
amount - unsigned long long; Total tips sent.
volume - unsigned long long; Total volume sent in zachys (atomic units).
This method gets the top users for tips and volume
Method: GET
Resources:
amount - not required - The amount of items to return (Default is 10).
Inputs: None.
Results:
topTips - Array of objects with the following structure:
username - string; The username.
tips - unsigned int; Total tips sent.
topVolumes - Array of objects with the following structure:
username - string; The username.
volume - unsigned long long; Total volume sent in zachys (atomic units).
This method gets the recent tips
Method: POST
Resources:
amount - not required - The amount of items to return (Default is 10).
Inputs (All are required):
sort - "First" for most recent tips, "Last" for the least recent tips.
type - "Public" for only public transactions, "Private" for only private transactions, "All" for both.
Results:
Array of objects with the following structure:
tweetId - string; The tweet id.
fromUser - string; The username who sent the tip.
toUser - string; The username who received the tip.
amount - unsigned long long; The anount of the tip in zachys (atomic units).
time - unsigned int; The time.
type - string; The tip type.
This guide is aimed at people not familiar with Linux servers or hosting services.
We recommend using public-key authentication to access your server. Using a strong password to connect remotely in SSH is already secured, but using your own key pair for SSH connexion is always recommended.
The SSH key you will be generating will be used later on when accessing your server.
Open a terminal window on Linux or OSx and type the following command.
It will generate an SSH key pair in the form of a public key id_rsa.pub and the corresponding private key id_rsa created in the ~/.ssh directory
In the first beta version, X-Cash's DPoPS will only run on a Linux/Unix OS. We recommend installing it on a Ubuntu VPS/dedicated server (18.04) for the best compatibility.
Before looking into a server hosting service, it is recommended that you acknowledge the system requirements for running a delegate node.
The delegate node will need to transmit a lot of information, notably messages to the other delegates to verify the block informations, As time goes by, the features and information that the delegates handle will increase (notably when we will develop token creation, NFT, sidechains, smart contracts and other exciting features).
The recommended system requirement is designed to be "future-development proof", meaning that a hardware update should never be needed and it will still comfortably handle the xcash-dpops program.
It is estimated that the blockchain size will increase by 9GB per year.
There are a lot of server and VPS providers out there, notably AWS, Azure, Google Cloud, Hetzner, Alibaba, DigitalOcean, OVH etc... to only name a few. If you don't have your own server infrastructure, you will need to rent your server with a provider.
Make sure you read your server provider documentation. Each initial server setup can be different.
We will give a short tutorial here for preparing a server. Those steps should be easy to replicate with any server hosting providers.
Your server provider should propose you different Linux distributions to install directly from their dashboard. The xcash-dpops program was intensively tested on Ubuntu-18.04 and Ubuntu-20.04 and should be the preferred distribution.
Choose the Ubuntu 18.04 LTS or Ubuntu 20.04 LTS version and follow the installation process.
On Windows
Log into your server using your existing credentials (given by your server provider).
With Putty, indicate the hostname (which should be the server IP-Address) and the port (the default port is most of the time port 22) open the connection and connect to a user session with your credentials user/password (the default user should be root, and most times the password is sent to you via email by your server provider).
On Linux/Osx
In a terminal, use the command ssh log into your server using your existing credentials (given by your server provider). The hostname should be the server IP-Address, and the default user should be root.
When first connecting to your new server, you will be prompted to recognize the server's host key and validate the RSA fingerprint.
Type yes and continue the log in process. You will be prompted to provide your password (which most times, is sent to you via email by your server provider).
On Windows
Now, when you open the connection, you will be prompted to enter your key passphrase (if you have given one) to log in.
On Linux/OSx
Open a terminal window and use the command ssh -i, adding the path to your private key and your servers user@hostname
You will be prompted to give your key passphrase if you have provided one at the key generation.
In most hosting services, you can register your public SSH key in your server dashboard, which will automatically authorize your SSH key to connect to your server. If you want to add it manually, you can follow the tutorial below. Otherwise, just move on to the next step.
To copy the content of the public SSH key into the server, you need to create the authorized_keys file on your Linux machine.
On your Windows machine, open the public key file.
Copy the public key content (starting from ssh-rsa and the long string after) and paste it into the authorized_keys on your Linux machine.
Save and close the text editor. Now, adjust the permissions of the authorized_keys file so that the file does not allow group writable permissions.
Once done, restart your server's ssh.service before logging out to take your changes into effect:
You should now be able to login to your server using your SSH key. In Putty, browse and choose your private key file rsa-key.ppk to use it as an authentication for the next time you log into your server.
Now, when you open the connection, you will be prompted to enter your key passphrase (if you have given one), and you will be logged in.
You can use the ssh-copy-id command to copy the public key directly in the authorized_keys on your server.
ssh-copy-id is not natively installed on OSx systems. You need to install it by running brew install ssh-copy-id
Just use the following command by replacing mykey with your private key file and user@host with your server login information.
If you don't want to use the ssh_copy_id command, you can manually append the authorized_keys file by using the following command:
This will take the content of mykey.pub and append it to the authorized_keys file directly on the server. Once done, restart your server's ssh.service before logging out to take your changes into effect:
You can now test the connection to your server by trying to login with your SSH key:
You will be prompted to give your key passphrase if you have provided one during key generation.
The xcash-dpops auto-installer script has been designed for root users. It should work for other users as well.
Create a new user session named xcash where you will only store files and programs related to the delegate function.
Set and confirm the new user’s password at the prompt. It is highly recommended to use a password here:
Follow the prompts to set the new user’s information. You can leave it empty.
Now that the xcash user is created, you need to give it sudo rights:
You can now switch user session from root by using the command su:
Your delegate name is your brand! ⭐
When you register as a delegate, your server will be recognized and listed in the delegates website through its domain name. If you haven't registered a domain name for your server, the default domain will be the server's IP address.
While in itself it is completely possible to use it as is, it is recommended to brand yourself by buying a domain name of your choice. We believe that it will help you greatly if you are planning to run a shared delegate and are looking for votes.
There are a lot of services out there to buy a domain name: NameCheap, Google Domains, OVH, GoDaddy, etc... to only name a few. You will need to create an account over there and reserve the domain name of your choice.
Once you have reserved your domain name, you need to change the DNS record to point your newly bought domain name to your IP address. This can be done by changing the A (Address) Record in your domain name provider dashboard.
Assuming that the domain you bought is domain-name.com, the A Record above will permit people to identify your server with domain-name.com and the subdomain delegate.domain-name.com
As an X-Cash holder, you can stake your delegate and vote for a preferred delegate. Follow the guide below to learn more about voting & staking.
Currently you can vote from the CLI wallet, android wallet, and GUI wallet. X-Bank does not have the ability to vote yet.
Shared Delegates: The shared delegates are public delegates for whom you can vote. They will redistribute your share of the rewards minus their fees. As a voter, you should favor shared delegates.
Solo Delegates: Solo delegates are elected by themselves and are keeping the reward for them. You can vote for solo delegates, but don't expect to receive a share of the block reward.
Private group: Private delegates group are delegates that will only redistribute shares of the block reward to a select group of their voters. They are usually decided with the delegate in private, so you shouldn't vote for them if you haven't communicated with the delegate first.
You can calculate your expected ROI depending on several factor to help you with your vote.
Community member and delegate UrsaMajor is providing a comprehensive list of delegates to help you understand and calculate what reward you can expect by voting with your XCASH.
There is a couple of rules to observe when voting:
You can only have one vote assigned per wallet. If you want to vote for another delegate, you will need to create a new wallet, and send to it XCASH you plan to vote with.
Votes are taken into account at the top of the next hour. If you apply a new vote at XX:30, it will be in effect at XX+1:00.
You need a minimum of 2,000,000 (2 Million) XCASH in the wallet to vote.
Spending from the staked amount in your wallet will cancel the vote. You can split your wallet into a staked and unstaked balance and resplit it at any time. When sending tx it will only spend from the untaked amount, until their is no more left, it will ask you if you want to cancel the vote and still send the tx.
You can view the staked and unstaked balance anytime by using the balance command
By voting for shared delegates, or within a private group after making an agreement with the delegate, you will receive a share of the block reward, which is a form of staking of your coins.
Before running the wallet binaries, it is recommended to allow the X-Cash binaries folder in your firewall. Windows mistakenly picks up the executable as dangerous.
You will need to synchronize your wallet to a node, or download your own blockchain locally. To synchronize, you have two options:
Running the daemon and synchronizing the full blockchain (slow but most secure)
Using a remote node to synchronize (quick)
To synchronize the blockchain locally, run the daemon xcashd executable with administrator rights. This will download and synchronize the blockchain to your computer (blockchain location by default : C:\ProgramData\X-CASH).
The daemon will connect to an X-Cash node and download the blockchain to your computer.
This could take several hours depending on your connection.
Once the blockchain is completely synchronized, leave the X-Cash daemon opened and go to the next step and restore your wallet.
To synchronize the wallet using a remote node, you can connect to a trusted node to synchronize your wallet without downloading the blockchain locally. To do that, you will need to open the wallet using the command line interface and adding the parameter --daemon-address.
First, launch a terminal (mac/linux) or a command prompt with administrator rights (windows) in the folder where you have downloaded the wallet binaries. To do so, find the path to your X-Cash binaries and change your directory to this location.
Once your terminal is windows is located in the wallet binaries, you can run the CLI wallet with the following parameter:
During the registration period, you can chose from one of the following trusted daemon address:
us1.xcash.foundation:18281 europe1.xcash.foundation:18281 europe2.xcash.foundation:18281 europe3.xcash.foundation:18281 oceania1.xcash.foundation:18281
Example:
You will be able to open a wallet file if you have one and let it synchronize the last block. If you don't have a wallet file, or wish to restore a wallet, follow the instructions below. If your wallet is synchronized, you can go to the prepare your vote section.
Wallet files made using the binaries 1.5.0 and the GUI wallet can be used with the 2.0.0 binaries.
If you don't have the wallet files or want to restore a wallet, you can use the --restore-deterministic-wallet parameter and provide your mnemonic seed.
First, launch a terminal (mac/linux) or a command prompt with administrator rights (windows) in the folder where you have downloaded the wallet binaries. To do so, find the path to your X-Cash binaries and change your directory to this location.
Once your terminal is windows is located in the wallet binaries, you can run the CLI wallet with the following parameter:
You will be then prompted to give your wallet mnemonic seed and a new password. Once entered, your wallet will synchronize blocks with the remote node. It could take a while as a newly created wallet needs to scan all the blocks until the last one.
Once done, your wallet is ready and you can start to prepare your vote.
To vote, you will need to have at least 2,000,000 (2 Millions) XCASH unlocked in your wallet. As you can cast only one vote from one given wallet address, you will need to create and top up another wallet if you want to cast another vote.
When you cast your vote, your wallet will create a reserve proof, which is a cryptographic proof of the current amount stored in your wallet. If you spend any amount from your wallet, the reserve proof will be broken and your vote will become invalid.
Before casting your vote, you will need to concatenate the unspents of your wallet, otherwise your vote could be invalid. To do that, you just need to use the function sweep_all to your wallet address.
Make sure to correctly input your wallet address (the one starting with XCA...) after the sweep_all function. Putting an invalid XCASH address or any other address that isn't your own will result in the permanent loss of all your wallet funds.
This will take all your unspents, concatenate them into one unspent and send it back to you.
The amount of your wallet will be 0 after a sweep_all until the transaction is complete. Your funds will come back on the next blocks, and you will have to wait about 10 blocks for your funds to become unlocked again.
Once your wallet is prepared with the amount you wish to vote with, you can cast your vote.
To vote, it's quite easy. Use the vote command:
The wallet will create a reserve proof with the staked amount you provided of the wallet (or the full balance if you set it to all and assign it to the designated delegate. Once your vote has been casted, you will have to wait with your wallet running until the top of hour before getting a success message.
You will get a success message when your vote ****has been taken into account.
You will need to vote again if your wallet balance grows. To quickly vote for the same delegate you already have a vote for, run the following command
revote <amount>
Voting with Android wallet instructions made by Aquila-Audax 🙏
Please be aware that the Android wallet is still in Beta so, be careful using it and save always in a secure place a backup of your public and private view/spend keys and/or the mnemonic seed. If this info is lost, there will be no way to restore it if necessary!
In case you have already generated a wallet, voting from the Android X-Cash Wallet APP is a very simple process.
Tap to resume and type your wallet password:
Wait for your wallet to synchronize with the network.
Once synced, tap the DPOPS button in the upper right corner.
Scroll down the list to find your desired delegate and tap it’s name to select it, or type it’s name in the “Delegate Name” textbox near the “Vote” button.
With the desired delegate’s name in the text box, tap the Vote button.
In the next window, you will have two choices:
a. If you are in the 3rd minute of the hour, you can tap Quick Vote and the vote will be placed right away
b. If you are out of the 3rd minute, you can tap Auto Waiting and the app will place the vote after the needed waiting time (you need to maintain the wallet opened till you will receive the confirmation). Please note that in my version, it says that 35 mins. waiting time are needed to place the order (which means that the app will try to place the vote on the 2nd minute of the hour and will throw an error showing “invalid vote time”. A minor change will be done on the next version to reflect the last change on the voting system, and apply the vote only on the 3rd minute instead of the 2nd and the 3rd minute which was the previous manner.
At the top of the next hour, your vote will be placed ! You will receive your share of the block reward on this wallet.
X-Cash DPoPS (Delegated-Proof-of-Private-Stake) is a variation of DPoS and DBFT consensus.
Becoming a delegate is ambitious, and reaching and keeping a forging spot is rewarding but can be taken out at any time. As a delegate, you will have to prove that you are fit to keep this role. This documentation will help you get set up, register as a delegate, start forging, and securing the X-Cash Network.
The top 50 delegates are elected as block verifiers.
Using a variation of Delegated Byzantine Fault tolerance consensus where 55% consensus must be reached for a new block to be added to the network.
DBFT allows for up to 45% of the elected block verifiers to be faulty. The system will still be able to produce a new block.
Using Verifiable Random Functions (VRF) to select the next block producer in the system. This allows for a random, but a verifiable way of selecting the next block producer.
Reserve proof-based voting/staking system: the XCASH's stake always stays in your wallet.
There is no lockup period. The staked XCASH always remain in your wallet and you can use them at any time. However, moving them from your wallet will cancel your entire staking
No need to keep your wallet/computer online if you are staking towards a shared delegate
The minimum stake to vote for a delegate is 2 million XCASH.
The election process occurs in every block.
New votes will be taken into account for the next block.
Your current vote will automatically get cancelled if you change your vote to a different delegate.
There aer no voting fees. You can cast a new vote or switch your vote as many time as you like.
Blocks can be verified in the X-Cash's Daemon with a detailed explanation of the block content.
The voting and reserve bytes data is held in a decentralized database system.
The block format is designed to store a hash of the reserve bytes data, pointing to the decentralized database, to reduce size increase of the blockchain.
As an X-Cash namespace owner, you will need to renew your namespace every year.
You will need to renew your namespace, as they only last 1 year after every register or renewal. You can renew a namespace after it expires, but anyone else can as well, so make sure to renew it a few days before the expiration date. You can not currently renew early or for multiple years at this time.
You can always view all details (including registration time) of your namespace by visiting http://www.delegates.xcash.foundation/remotedatagetinformationfromname?parameter1=NAME (where NAME is your name of the namespace)
Open and fully sync your wallet that is tied to the "address" field on your namespace.
Once you have a delegate and price you want to use, run this command remote_data_renewal_start
Once the command is complete you will have 24 hours to renew the domain. You will need to send a PUBLIC transaction to the delegate for the amount. You should then wait 30 minutes to make sure that transaction has been processed. Once this is done run this wallet command remote_data_renewal_end <tx_hash>
Once done you can confirm using the above API to see if your namespace was successfully renewed.
As an X-Cash namespace owner, you can stake update data associated with it.
The X-Cash Namespace allows users to register their own name in the namespace. This allows a user to associate a public address with an easy to remember name (NAME.xcash) This protocol also allows a user to setup a public only wallet that can only send and receive public transactions, and a private only wallet that can only send and receive private transactions (using NAME.pxcash for public and NAME.sxcash for private). Each registration cost an amount that is set by the delegates. Each delegate can set their own price, but users can only use the current block producer (or wait for the next one etc) to register. Each registration is valid for 1 year and renewals are the same cost as registering.
This protocol is built into xcash-dpops repo so it will be the same instructions to update for delegates.
Characteristics
Have users be able to type NAME.xcash in the wallet instead of the long public address to send.
Be certain for a private transaction from a user by giving them NAME.sxcash
Be certain for a public transaction from a user by giving them NAME.pxcash
Delegates host the namespace and can set their registration/renewal price
This page contains every Wallet RPC calls related to DPoPS functions.
Place your vote for a delegate.
Alias: vote.
Inputs:
delegate_data - String; Name or public address of the delegate to receive the vote.
amount - string; The amount or all
Outputs:
vote_status - string; Status of the vote call.
Example:
Register a delegate.
Alias: delegateregister.
Inputs:
delegate_name - string; Name of the delegate to register.
delegate_IP_address - string; IP of the delegate to register.
Outputs:
delegate_register_status - string; Status of the delegate registration call.
Example:
Update delegate information.
Alias: delegateupdate.
Inputs:
items - Parameters to change
IP_address - string; IP address of the delegate.
about - string; Description of the delegate.
website - string; website address of the delegate.
team - string; __
pool_mode - string;
fee_structure - string;
server_settings - string;
value - string; Value of the field to update.
Outputs:
delegate_update_status - string; Status of the delegate update call.
Example:
Revote for a delegate.
Alias: revote.
Inputs:
amount - string; The amount or all
Outputs:
status - string; Status of the vote call.
Example:
Get who the user has voted for
Alias: revote.
Outputs:
status - string; who the user has voted for.
Example:
This section is designed to gather steps for managing the different services around the xcash-dpops program, getting logs and monitoring the activity.
You can manage your program installation with the installer script:
The installation script enables you to install and manage your xcash-dpops program easily.
If you have an issue with your program running, or need to do some changes in the settings and need to restart the different program, it is recommended to restart the service using the installer script.
Run the installer script and choose option 12.
When a new update of the program is pushed, you will need to a update your program.
Run the installer script and choose option 2.
To change your settings from a solo to a shared delegate (and vice versa), you can run the installer script and choose option 9, or change the settings (fees and minimum payout) with option 10.
You will be asked to input a delegate fee and a minimum payout amount to your voters. The script will automatically change the program settings to match your changes.
As a shared delegated, you will have the responsability to distribute the payout to your voters. The voters information and shares are stored locally into your delegate node database. Before attempting to update your node, or do maintenance on your server, it is highly recommended to backup this information.
To backup your shared delegate database, chose option 19:
To be added.
allows you to change your public_address or VRF key must be using a domain name with delegate add txt record, value @ data is xcash-dpops:MYNEWPUBLICKEY or xcash-dpops:MYNEWVRFKEY you can do 1 or both at the same time does not matter then open ANY wallet (does not need to be the delegate wallet in case you lost it) and type delegate_recover mydomain, and it will do everything for you.
systemd is generally used to manage low-level programs in Linux-based systems. It's a reliable way to automatically run programs on startup, and manage and monitor the different services.
The different services needed for the X-Cash consensus running on the server are listed below:
All the unit files are located in /lib/systemd/system/
At some point, you might have to need to restart or check the status of the services, either to reflect a change you have made, to update, or to run the program with different parameters.
To start a systemd service, run:
Example:
To restart a systemd service, run:
Example:
To stop a systemd service, run:
Example:
To check the status of a systemd service, run:
Example:
Output:
While the services are running in the background, you might want to check the outputs of the different programs.
To monitor the services, we are using journalctl which fetch the journal of the systemd services. Using journalctl without paramaters will show the full contents of the journal, starting with the oldest entry collected.
For a live logging with better readability, we will limit the output by using the following parameters:
To check the xcash-dpops services, you can copy the following commands:
The xcash-daemon service export its logs in a different place. To display the latest log, use the following command:
We can change the motd generated when we login to our server to make it show us basic node information like the service status, our balance and blockchain syncronization status
Optionally, we can to disable all the automatic scripts executed when we log in and only enable ours.
We need to place our script in the update-motd.d directory, we will name it 00-xcash-node-checks and put our script inside
If you have custom service names you need to adjust the service variable names at the beginning of the script
Then, we need to make it executable
After that, every time we log in to our server by ssh we will see something like this.
You can register a namespace to associate public addresses with a name.
Open and fully sync your wallet that you want to register. This will tied to the NAME.xcash namespace. You will also need two other addresses. One that you want to be tied to NAME.sxcash that can only send and receive private transactions, and one that you want to be tied to NAME.pxcash that can only send and receive public transactions. It is highly reccomended you use two new wallets for this.
You can view if a name is avalible by using http://www.delegates.xcash.foundation//remotedatagetnamestatus?parameter1=NAME
Once you have a delegate and price you want to use for name, run this command remote_data_save_name <name>
Once the command is complete you will have 24 hours to register the domain. You will need to send a PUBLIC transaction to the delegate for the amount. You should then wait 30 minutes to make sure that transaction has been processed. Once this is done run this wallet command remote_data_purchase_name <saddress> <saddress_signature> <paddress> <paddress_signature> <tx_hash> where saddress is the private only address and paddress is the public only address. To get the saddress_signature you need to open the saddress wallet and run sign YOUR_SADDRESS_PUBLIC_ADDRESS and it will save the signature in a file, that is the saddress_signature. You need to do the same for the paddress wallet. This is needed because it proves ownership of the wallets you want to register.
Once done you can confirm using the above API to see if your namespace was successfully registered.
This page contains every Wallet RPC calls related to Namespace functions.
Update the remote data for namespace
Alias: update_remote_data.
Inputs:
item - String; The item to update (website or smart_contract_hash)
value - String; The value
Outputs:
status - string; Status
Example:
Saves a name for 1 hour, so one can purchase it
Alias: remote_data_save_name.
Inputs:
name - String; The namespace name to save
Outputs:
status - string; Status
Example:
Pruchases the name once it has been saved
Alias: remote_data_purchase_name.
Inputs:
saddress - String; The saddress (private only address)
saddress_signature - String; The signature from the saddress wallet to proove access
paddress - String; The paddress (public only address)
paddress_signature - String; The signature from the paddress wallet to proove access
tx_hash - String; The tx to show the delegate was paid
Outputs:
status - string; Status
Example:
Sets the amount the delegate wants to charge per namespace register or renew
Alias: _remote_data_delegate_set_amount.
Inputs:
amount - String; The amount in zachy's (10^6)
Outputs:
status - string; Status
Example:
Starts the renewal process
Alias: _remote_data_renewal_start.
Outputs:
status - string; Status
Example:
Ends the renewal process
Alias: _remote_data_renewal_end.
Inputs:
tx_hash - String; The tx hash that paid the delegate to renew the name
Outputs:
status - string; Status
Example:
Guilhem Chaumont, Paul Bugnot, Zach Hildreth, Balthazar Giraux
Version 1.0
This document gives an extensive summary of the components of DPoPS, a Delegated Proof-of-Private-Stake implementation under X-Cash, a Monero based hybrid-privacy coin. The change of consensus algorithm from Proof-of-Work to Delegated Proof-of-Stake is a significant milestone for the X-Cash blockchain, and will also bring innovation to CryptoNote, Monero and the overall blockchain ecosystem.
Delegated Proof-of-Stake (DPoS) is an efficient, decentralized, democratic, and flexible blockchain consensus framework which has been actively researched in the last years. However, the private nature of a coin can make DPoS implementation challenging as balances are obfuscated. As a representative system, DPoS needs the right balance of transparency to remain efficient, and most privacy coins cannot cope with missing part of their opacity.
To address this challenge, we would like to suggest DPoPS, an improved Delegated Proof-of-Stake algorithm for privacy coins. DPoPS inherits all the advantages of the original DPoS consensus while offering the opportunity to be used in a privacy coin.
From a technical implementation perspective, it has been chosen to use a combination of Delegated Proof-of-Stake and delegated Byzantine Fault Tolerance (DBFT) with the use of Verifiable Random Functions (VRF) for the block producer election. As X-Cash is a privacy-based coin where balances are hidden, Monero’s reserve Proofs are extensively used through the election process.
In a centralized system, all parties of an ecosystem refer to the decision making of a known and trusted third-party; the general consensus is not needed, as the centralized entity administers the decisions and validations. In a decentralized system (blockchain, DLTs, etc.), reaching consensus is challenging as every party must agree to the majority on a similar decision, instantly and without fault. Algorithmically, several solutions have been developed to solve this issue, namely, but not limited to, Proof-of-Work (PoW), Proof-of-Stake (PoS) or Delegated Proof-of-Stake (DPoS) [1] [2].
Until recently, most privacy coins were backed by Proof-of-work algorithms mainly for historical reasons and because the private nature of these blockchains made it hard to reveal one’s stake in the blockchain without voiding the anonymity principle of the blockchain entirely.
In the last few years, we have seen Proof-of-Stake privacy coins emerge using mixing and conjoin methods to allow private transactions. Having a private balance and stake is another problem in itself. Some blockchain successfully achieved partial or complete anonymity of staking through a combination of reserve proof and transaction mixing. If privacy can be promoted and even guaranteed using a Proof-of-Stake algorithm, it is imaginable that a blockchain could host a privacy coin while using a Delegated-Proof-of-Stake algorithm.
What makes DPoS appealing is that it allows anyone with a minimal amount of coins to take part directly or indirectly in the consensus process while having the same benefits as a PoS algorithm - being more energy-efficient and flexible, having a quicker transaction broadcasts, and being more attack-proof [3]. In a way, DPoS allows more people to take part in the governance of a blockchain than PoS, and one could argue that it is closer to the general principle of decentralization because it is more open to the public.
However, applying DPoS to a privacy coin is quite challenging due to the private nature of the blockchain. The same challenges as for PoS have to be faced (stake and balance privacy) and voting privacy also has to be guaranteed.
Achieving a DPoS consensus in a privacy coin would prove that blockchain could be an alternative to traditional governance models - including the ones used outside of the blockchain ecosystems. In this paper, we are exploring one of the possible paths enabling a DPoS consensus in a CryptoNote (CN) coin. This path could pave the way for Monero and other CN coins to a new governance model.
In order to explain the challenges in the implementation of DPoS in privacy coins, more especially in CN coins, we will expose the state of the art of DPoS. Then, we will discuss the different points which need to be addressed in order to make this blockchain consensus applicable to privacy coins. Lastly, we will explain the way we implemented DPoPS in the X-CASH protocol.
There are two primary reasons behind the creation of the DPoS consensus (and PoS to some extent). Dan Larimer most specifically references the fact that bitcoin’s Proof-of-Work is too wasteful [4]. Much energy is poured into bitcoin mining, and there are probably other alternatives to achieve the same goal. He was also looking at improving the speed efficiency of the algorithm. The redundancy of Proof-of-Work was, in his mind, one of the shortcomings of the bitcoin.
DPoS is designed to be as robust as Bitcoin’s Proof-of-Work algorithm, competitively fast (if possible as fast as a centralized exchange database) while still being open and decentralized.
Larimer successfully implemented DPoS in BitShares, Steem, and EOS. Now, more and more projects are successfully using DPoS as a governance model for their blockchain architecture (Ark, Cardano, Tezos, Lisk, etc.).
In order to explain what a DPoS consensus is about, we will discuss the different points/aspects making DPoS unique. First, we will address the block producing process before studying the role the delegates play in the consensus. Then, we will discuss the standard DPoS election process and its consequences to expose the security advantages this algorithm offers finally.
The reason Proof-of-Work, and to some extent PoS, is deemed inefficient - both regarding energy consumption and blockchain speed - is the fact the whole network takes part in blocks validation (e.g. transactions validation). This principle - necessary to guarantee a neutral and censorship-resistant creation of blocks - is given to a select few in DPoS called Block producers.
These block producers are selected from the delegates at specific times during a block production round. The delegates are elected through a process where token holders can cast their votes proportionally to the voter’s stake in the network. This election process allows token holders to commission a delegate to represent them while still holding their assets in cold storage. Particl has called this “cold staking” [5]. At the end of each election, the top candidates gathering the most votes are elected.
The quantity of delegate spots is usually an odd number and can vary significantly depending on the blockchain. A higher number of delegate nodes is commonly associated with a better decentralization while being done at the cost of lower performances.
It is important to note that the number of delegates is usually much lower than the number of nodes in both PoW (miners) and PoS (stakers) blockchains. This is why DPoS is usually deemed more centralized than competitors’ consensus.
In a DPoS blockchain, every new block a delegate is selected to become the block producer in a round-robin manner and is given a time slot during which it is supposed to produce a block. In case of default of a block producer, the next block producer is selected and is in charge of forging the block. This means that the round time is linked to the blockchain’s specific block time and never changes.
In order to produce a block, the current block producer refers to the consensus node(s) to establish the current state of the network and validate both the blocks and their link in the chain. This goes to show how essential delegates and consensus nodes are in DPoS. In bitcoin’s proof of work, while only miners can create blocks, every node in the network (full and light nodes) verifies the integrity of both transactions and blocks.
The election process is different in every DPoS blockchain - the beginning, the duration and the ending of the process can vary in terms of conditions and times. This being said, the election processes usually follows the same path. Token holders vote for a delegate in order to increase its chances of becoming a block producer by gathering more votes than its competitors. The vote in itself is given to a delegate for a specific period and tacitly reconducted if the voter did not change its vote. This implies that the voter can change its vote at any time during a round in anticipation of the next election round.
Because delegates are elected, the block reward for successfully producing a block is usually shared and spread to the voters in order to reward them of their trust. This creates an incentive for the votes to delegate their stakes and for their representatives to be the avatar they were elected to be. A social contract of sorts if passed between delegates and voters.
At the end of each round, a new election takes place, allowing voters to reassess their position. This system promotes delegates’ responsibility towards their electorate and having a shorter round is not that big of a deal in a blockchain system. In a political system, on the other hand, even though having a short mandate is deemed to be promoting politicians’ responsibility, it is also considered to lead to immobilism.
At the end of each round, the network checks the delegates’ status from the last election list before starting the next block production round.
As for any blockchain, the DPoS algorithm needs to guarantee the security of the network. It is possible to divide attacks into two groups: attacks from network actors and attacks from outside sources, purely perpetrated to damage the network.
First of all, an actor could benefit from cheating the rest of the network. It is important to remember that voters play an important role in a DPoS blockchain - they elect the delegates who can become block producers. By doing this, they also take part in the network’s security and “checks and balances” system. Because the token holders elect delegates every round, the system promotes a virtuous circle where delegates have more incentive to represent their electorate the best way possible since their mandate is at stake.
Just as in PoS, the staking system helps prevent the number of bad actors in the network. As opposed to PoW, to become a block producer one needs to prove its interest in the success of the network through a staking mechanism. The fundamental rationale behind this process is to make sure that a significant stake is collateralized by the actors in charge of the consensus. Therefore, they are mechanically incentivized to behave in a manner that will not negatively impact the coin behind the blockchain. For instance, in case of a double spend or a DDOS attack performed by the delegates, the market capitalization of the coin would be significantly impacted, making the loss from the collateral devaluation more harmful than the potential profits from the attack. More generally, anybody who is willing to benefit from the network - whether through block minting or voting - has an interest in protecting the network’s integrity through this collateralization process. In consequence, the incentive of being a bad actor in the network drops significantly.
As discussed, the hypothesis could arise that outside actors could benefit from damaging the blockchain. In a PoW blockchain, an attack could damage the network through what is known as a “51% attack”. In this specific case, one needs to control 51% of the computing power behind a blockchain’s block production. This type of attack can be already hard to set up, especially for the top cryptocurrencies where the additionally needed hashrate is not reachable; either from pure hardware supply limitation or lack of liquidity in the hashrate market places such as NiceHash. The bigger the network is, the tougher this type of attack gets.
Potentially, It can get even harder with a PoS/DPoS consensus. Rather than having 51% of the computing power, an actor needs 51% of the coin staking supply to proceed to such attack. A quick look at Bitcoin’s market cap exposes the ludicrousness of the idea.
Moreover, most DPoS blockchains have raised the threshold of required stake in the network from 51% to 67%, making an attack even more costly and therefore, the network more resilient.
Finally, just like any blockchain, a DPoS blockchain needs to be Byzantine Fault Tolerant (BFT) [6]. In this specific case, we call this Delegated BFT (DBFT).
To overcome byzantine failures, a network needs to guarantee a consistent and coherent global view of the system’s state. For DPoS consensuses, a more centralized approach has usually been adopted.
One possible DBFT implementation is to have one or a group of consensus nodes define the state of the blockchain. A consensus node is a witness of the system’s state. Like any witness, its testimony is questioned and confronted with reality/facts. Whether there is a single or a group of consensus node, most DPoS algorithms offer a decentralized process to confront the version of the truth proposed by each actor of the consensus.
While it is often argued that DPoS is more centralized than other types of consensus, because of the block production process and the existence of consensus nodes, the election of delegates makes it very democratic. Just like politics, there is a very delicate scale between democracy (in this case, decentralization) and efficiency, and each blockchain brings a different vision to the table.
What is more evident is the fact that this consensus algorithm is still in its infancy, and none of these projects features private transactions beside ideation stage project such as pEOS [7]. The key goal and motivation behind the X-Cash Delegated Proof-of-Stake variant is to offer an alternative governance model for networks hosting privacy coins.
To understand the challenges of using a DPoS consensus in a privacy coin, it is important to realize what information is protected/hidden depending on the blockchains.
Privacy on a blockchain is actually defined by more than offering private transactions. If only transactions were private, any person with time, resources, or any well-programmed computer could recreate transactions on a network through the use of statistical analysis for instance.
To protect one’s privacy, a network needs to hide as much information as possible. It can be raised that any information that is released could be compared to any other in order to decrypt the transaction web. Thus, to achieve complete privacy, a blockchain needs to hide not only the transaction but also the sender’s and recipient’s addresses, both their balances, transaction history, amounts exchanged and more. We could point out that having a hidden transaction is not necessary at all, it is more critical to have transactions without information than everything but visible transactions.
This is where achieving consensus gets hard; how can one create trust in a network deprived of data/information. It gets even harder to imagine having a DPoS consensus because so much relies on trust to make this type of consensus work. DPoS can only work if token holders have the resources to evaluate, control, and eventually sanction their representatives. Any representative system needs to have a delicate equilibrium of transparency. It is our belief that in order to achieve an efficient DPoS consensus with a privacy coin, some concessions have to be made. We will try to present methods allowing to reach consensus while trying to display the privacy benefits and drawbacks of each one.
We have identified four main areas where friction arises when trying to implement DPoS consensus in a fundamentally obfuscated blockchain. These points will be addressed chronologically by following the delegation of voting power through its whole journey.To understand the challenges of using a DPoS consensus in a privacy coin, it is important to realize what information is protected/hidden depending on the blockchains.
Before addressing the voting process and the delegates’ election, we will focus on the difficulty of proving one’s stake in a privacy coin. This will give us a better understanding of the importance of randomizing the block producer selection. Lastly, we will suggest possible DBFT implementations for privacy coins.
Generally speaking, transparency plays a significant role in the block production process. Whether a blockchain uses PoW, PoS, or DPoS, every miner/block producer tries to find the solution to a mathematical problem. Once this problem is solved, the solution is spread out through the whole network for everyone to see. Achieving consensus would be nearly impossible without such transparency; transparency is one of the most genuine sources of trust.
As opposed to PoW systems, computing power is mostly irrelevant in PoS based system (DPoS included). A PoW consensus is a system where candidates to block production are constantly competing for the block rewards/transaction fees. In PoS, one can only become a block producer by proving their stake in the network. The stake is represented through a minimum amount of token/coin locked in a wallet.
In a transparent blockchain - where transactions are public - the network will check the amount of coins locked per address before starting the block producer selection process.
The mechanism changes slightly in DPoS consensus because holders can not become block producer directly. As mentioned earlier, a delegate (candidate block producer) need to either be a top token/coin holder or gather enough vote delegation to enter the delegates list. Whether it is PoS or DPoS, the block election process requires full transparency on the number of tokens/coins staked. This is why having a stake-based consensus in a private transaction blockchain is not easy to achieve without damaging privacy [8] [9] [10].
One of the possible solutions is to use reserve proofs. Reserve proofs were introduced to Monero in 2018 [11], it allows any wallet to generate a proof of amount. Before this, someone with a Monero wallet needed to send both his view key and signed key images to an auditor. Not giving out the View Key prevents the auditor from seeing all the incoming transfers (past and future). This also means that before the introduction of reserve proofs, staking would have been very hard to achieve in Monero (and other CN coins) without violating a wallet owner’s privacy.
Reserve proofs are not perfect though. In a PoS consensus, one only needs to prove he has the minimum stake required to participate in the block production. This means that one can prove he has the minimum stake without disclosing how much exactly is in the wallet.
In DPoS, since one is delegating his stake as a vote, the more stake one has, the more he weights in the network. Through the use of a reserve proof, one needs to display partly or totally his stake in order to be able to vote.
Another possible drawback of reserve proofs in DPoS is the fact that the reserve proof is set on a specific amount of tokens/coins. If one chooses their whole balance, every time a transaction is sent to the wallet, a new reserve proof have to be generated. While not being a concerning issue, this shows that cold dynamic staking is not possible under this framework.
As we can see, proving one has enough tokens/coins to participate in the network while maintaining anonymity is hard in a PoS consensus, it is even harder in DPoS because an actor has an incentive to disclose the highest number of his stake as possible.
This, of course, changes the anonymity level of the blockchain but gives every participant a choice. On the one hand, someone very strict about his/her anonymity would probably prefer staking less or not staking at all while maintaining his balance private. On the other hand, some people do not really care about their balance being fully or partly public, especially if they still benefit from transactional privacy. Later on, we will discuss what the implications of the staking mechanism in the delegates’ election are.
The addition of reserve proofs in order to add some privacy to the staking mechanism has consequences on the delegates election process. Since the amount of vote one has in a DPoS is proportional to the amount staked, the number of tokens/coins one has decided to display through the reserve proof is the sole driver of one’s weight in the number.
It is important to also note that making one’s reserve proof public will automatically let everyone else know the number of votes one gets as well as which candidate delegate received these votes. While this can seem very public for a privacy coin, it answers a democratic need as well as a blockchain one. Anyone, within and outside the network should be able to verify the election process. Transparency will create both trust and responsibility from a delegate towards its electorate.
On the blockchain side, every token holder and every node is informatically able to check anyone’s reserve proof. Before the election, the algorithm randomly assigns a different number of reserve proof checks to be executed in order to start the election process. The choice of randomizing this check was made with efficiency in mind. Checking every reserve proof at the beginning of each election round would be extremely time and computing-consuming. The random check solution is satisfyingly good on both regards.
To stay consistent, and in order to promote delegates’ responsibility, the activity of a delegate remains public. This way, any of its supporters can verify the number of blocks that were produced, the reward perceived, and any transactions to make sure the block reward was distributed according to votes repartition.
Once again, this solution appears satisfying in regards to the democratic process but give out more privacy than one could wish. Just like token holders can choose between taking part in the block production through a vote, delegates can decide to remain partly anonymous.
Even though a delegate’s wallet is completely public, the person/organization behind the node can decide to remain anonymous. The people still remain in power and decide whether a person/organization is trustworthy enough and deserve to be elected as a delegate.
As stated earlier, most DPoS consensus base the block producer selection on a round-robin scheduling algorithm meaning delegates are given in turn an equal opportunity to create the block (equal time slice) [12] [13]. If a block producer fails to create a block, its turn is skipped altogether and the next delegate in line becomes the new block producer. Such scheduling scheme is used in blockchains such as Lisk and Tendermint.
This scheduling’s most significant benefits are its predictability and fairness, which explain its extensive usage. The predictability can also be an issue, in an area as competitive as block generation where financial retribution is involved, there are many incentives in exploiting predictability.
Blockchains have used different methods to randomize block production. In PoW, block difficulty and competition are based on chance [14] [15]. In PoS, the nodes’ chances are sometimes based on the amount of coin they stake [16]. In DPoS, randomization could prevent staking optimization (changing one stake’s destination or usage) and attacks. For example, if a delegate knows the positions occupied by its competitors in a round-robin, he could DDOS attack them before their turn comes, thus skipping it. This could be motivated by the level of fees or simply because diminishing the split makes the whole pot bigger.
For example, Peercoin uses what is called a “coin-age” parameter where the longer the coins have been in a node/wallet (90 days limit), the better the chances of being the next block producer. Every time a block is generated, the coin-age value is consumed and comes back to 0 - diminishing the changes of producing the next block greatly. Reddcoin uses a similar mechanism, but the coin-age function is nonlinear instead of limited to a maximum to make older coins age slower than newer ones.
There are plenty more ways to randomize the block producer selection but making a choice can have various consequences. Overall, using randomness in the selection of the next block producer diminish the threat of attack every delegate faces during the block generation round. On the long run, it is also a fair way to spread block rewards equally between network participants.
To achieve randomness in the selection of the next block producer, we have chosen to use Verifiable Random Functions (VRFs) [17] which are already used in some DPoS based cryptocurrency such as ONT (Ontology) [18] and ADA (Cardano) [19] [20]. VRFs were introduced by Silvio Michali, Michael Rabin and Salil Vadhan [21]. They are pseudo-random functions providing a public and verifiable proof of the output’s correctness without requiring the secret key used to generate the function. With VRFs, anyone with access to the public key would be able to verify the randomness of the block producer selection process without being given the secret key to generate the random function used.
Through its redundancy and consensus mechanisms, Blockchain is one of the most successful Byzantine Fault Tolerant systems. In the case of Bitcoin (and PoW), the blockchain is replicated as many times as there are nodes in the network. One of the reasons DPoS is deemed more efficient than PoW or PoS is the fact that BFT consensus is reached with lesser redundancy. In consequence, the network is still resistant to error or misinformation while being far quicker.
To improve speed, some DPoS blockchains have chosen to reduce the number of delegates even further [22]. Others have decided to use what are called “consensus nodes”. These are usually different than delegates but can sometimes be one or several elected delegates. A consensus node’s role is to establish the consensus truth. It usually receives new blocks and checks them for errors and tampering. If the consensus node agrees with the data contained in the block, it will transmit the latter to all the delegates except the one who created the block. If the majority of the delegates agrees (usually 67% of the delegates), the block is validated and added to the blockchain.
One of the most often used contestations against DPoS is the fact that the consensus protocol happens between a reduced amount of nodes - the delegates. By delegating their votes, token holders have also delegated the block verification process.
On the EOS blockchain, only 21 consensus nodes/delegates [23] produce and validate the blocks which have raised some concern among the community. This has the benefits of making the blockchain faster but detractors argue that it also makes the blockchain very centralized in the hands of a few actors. Reducing the number of delegates also increases the ease of setting up a cartel where delegates gain and retain control of the network. Such unhealthy behaviors are currently one of the biggest challenges DPoS will have to overcome has several cryptocurrency projects such as EOS and Lisk have been affected by this.
In an ideal world, everybody in the network should be checking a block’s validity. Unfortunately, most token holders do not necessarily want to set up a node to perform this verification process, and it also reduces the overall performance of the network. This is why in practice this task is usually delegated to the rest of the delegates.
There is no absolute number in terms of consensus node and delegates when it comes to Byzantine Fault Tolerance. The only constant that appears is that a higher number of replication there is, the more resistant the blockchain is. It also appears than the number of validators is inversely proportional to the blockchain’s efficiency - energy consumption and quickness. In the specific case of privacy coins, users seem to value more decentralization and tolerance to failure above efficiency and this is why we have usually tried to opt for a higher number of delegates.
This section covers the way we implemented DPoPS in X-Cash. This description addresses the processes which have to be modified in order to adapt block creation and Byzantine failures. The delegates election process is addressed first because it modifies the fundamental rules of block creation – going from PoW to DPoS. Then, we explain and detail the VRF usage allowing to randomize the block producer selection process.
Please note that this is a technical implementation of the DPoPS explained earlier. While there is some theoretical explanation attached to the integration, most of this section addresses its practical and technical points – database, functions, data transmission processes, and more. We have added commentaries to each section that can be read as warnings on the difficulties as well as a summaries.
As described in the previous section, reserve proofs are cryptographic proofs used to confirm that an address holds a specific amount of cryptocurrency. In Cryptonote, these proofs are used to reveal this information without disclosing the private view key of the wallet. In X-Cash DPoS, these proofs are a core component of the DPoPS consensus as they are used as votes for the delegate election process.
From a technical standpoint, a reserve proof is a cryptographic proof where one can prove that a wallet's balance falls between two amounts and are similar to the range proofs used in cryptonote [24]. Those amounts by default are 0 to ((2^64 ) - 1) and expressed in atomic supply (meaning for X-Cash that each coin is composed of one million atomic coins). Because the lower range is always the same as the upper range, it is better stated that the wallet's balance is at least X amount. Range proofs are a commitment validation that uses Pedersen Commitments.
Pedersen Commitments are a commitment scheme where:
with:
Note: is multiplied by 8 to make sure that the results are on the main subgroup of the ed255519 curve.
In the voting system, both upper and lower limits of the range proofs are set to be equal and correspond to the full wallet balance:
This implies that a wallet can only vote with its full balance and for a unique delegate. Therefore, if one wishes to vote for multiple delegates using a single wallet, they will first need to split the balance across multiple wallets.
The switch to a DPoS based consensus algorithm involves additional data used in the process. This data involves various information such as delegates identifier id, vote counting, delegates ranking, and in the case of X-Cash DPoPS reserve proofs, among other more specific data.
To guarantee and improve the decentralization, it is crucial to keep this data stored in a decentralized manner among the network participants. For technical reasons, it has been decided to keep this data off the main chain. These reasons include a need to improve latency, data bandwidth, as well as not impacting the main chain with data that would not be relevant for the long term. For instance, storing the reserve proofs on chain would lead to adding data that quickly becomes non-pertinent once the reserve proof has been spent.
For this reason, it has been chosen to rely on a decentralized database that is stored off-chain.
Database type and uses.
For higher performances and scalability potential, it has been chosen to go for a NoSQL database type using MongoDB. The estimated data pushed in the database is estimated at 10 GB per year with a possibility to archive the data after a certain period. The database will be used to cover four cases:
statistics of the DPoS system, history of delegates ranking, reliability statistics, historical block producer data … etc.
Registered delegates: data linked to delegates details, identification ID, owner, location, IP address… etc.
Reserve proofs: storing of all reserve proofs used in the voting scheme. For a reduced syncing time, the reserve proofs are split into 12.5 MB chunks.
Reserve bytes: VRF data (keys+random strings), next round block verifiers public addresses, current round block verifiers signatures… etc.
Consensus and characteristics.
The consensus with regards to the database content is achieved at every round through a dBFT vote. Every round of block forging, the delegates also compare their database content by sharing the hash of it. A regular dBFT vote process is then carried so that all delegates can align on the same version of the DB.
Data stored details.
delegates
statistics
reserve proof(x)
reserve_bytes(x)
Updating delegates information.
For the delegates to update their information in the database, we can distinguish three functionalities:
add a delegate to the database
update delegate information in the database
remove a delegate from the database
These features are achieved through a simple process where delegates are sure they're communicating with all elected block producers.
Delegate first request the block verifier list from a random seed node and then contact all delegates to perform the wanted operation (add, modify, remove). Each operation is signed using the delegate’s private key so as long as it is matching the signature stored in the block producer database, the data will be updated. In this step, no vote is performed and each block producer modifies their data independently. The consensus will still happen as there is a vote among the block producer on the content of the database at the beginning of each round.
Syncing database collections.
Statistics and Delegates
The statistics and delegates databases are synced using the same process. First, the delegate requests the list of block verifiers and then compute a hash of its database. This hash is shared with all delegates, which then replies if the hash matches theirs. If yes, this implied that the delegate shares the same database content as the queried block producer. The delegates aggregate the results from all block producers and identify the resulting consensus on its database status. If block producers agree under de dBFT rules that the delegate does not have a synced DB, this last one will start syncing the DB from a random node in the consensus.
Reserve proofs
Reserve proofs are decomposed into 50 collections which each hold up to 1000 reserve proofs. The syncing process of these collections works in a similar fashion as the syncing of the statistics and delegates syncing collection process except that the delegates have to loop through the 50 collections individually.
Reserve bytes
Finally, the reserve byte collection is synced based on the local height of the delegates. As the reserve bytes are linked to the height of the blockchain, they do not need to be refreshed if they have been synced once. In practice, this means that the delegate will compare it is local height to the network height and only syncs if he is lagging behind. This can happen if the delegate is syncing the database for the first time or if a new block has been forged.
Delegates election process. Receiving and validating reserve proof
One of the main processes of the delegate election is to add the users’ reserve proofs into the database. This is achieved through the following process; users generate a reserve proof in their wallet and share it with all block verifiers. Once they receive it, each delegate is going to compare the reserve proof to its version of the decentralized DB, if the reserve proof is already in the DB, it will not be counted. If not, the block verifier will check the reserve proof validity in the blockchain. If the reserve proof is still valid, any reserve proof belonging to the public address of the reserve proof will be deleted from the database. Once this is done, the reserve proof can be added. Since there are multiple reserve proof collections, and to make sure the consensus of each collection is respected, it is crucial that all delegate add the reserve proof to the same collection. Therefore, the reserve is added to the first unemptied collection starting from 1 to 50.
Verifying reserve proofs.
Verifying the reserve proofs inventory is a key process of the X-Cash DPoPS. Because this step can be quite intensive in terms of computing load, this has to be done in a decentralized manner where all delegates do not have to check every single reserve proof every round. The process we have chosen to follow is to run on a separate thread a random reserve proof checker for every delegate.
Every block producer extract and checks a reserve proof from the decentralized DB randomly. If the reserve proof is invalid, the block producer will first verify if it has already identified as invalid during the round. If no, it will add it to a local buffer of all invalid reserve proofs it has identified. When the round is closed to be finished, block producers share the proofs they have identified to be invalid, and a dBFT vote is carried to create a consensus on the reserve proofs to remove from the database. Once this is finished, every delegate updates their local version of decentralized DB in preparation for the next election round.
During this phase is also computed a delegate score. This score is based on the number of invalid reserve proofs a delegate has found. This is done to incentivize the delegate to participate in the reserve proof checking process by creating a ranking and publish it. Currently, we have chosen only to compute the score in an indicative manner and not include it as part of a potential penalization process. Based on the reception of this indicator and the participation of delegates in the process, we will review the impact of the score.
Block producer election.
The effective 100 block verifiers election is the final element of the election process. This is carried during the block production process after the block has been produced and voted by all block verifiers. In practice, block verifiers vote and elect the block verifiers of the next round. This implies that the block verifiers list is updated on a block basis.
During the block creation process, after verifying the block and the validity of the transactions, block verifiers sign the block and perform a final dBFT vote. After this step, the next block verifiers election start. Because the block verifiers share the same version of the decentralized DB which is also checked at the start of the round, they can perform a dBFT vote on the list of next verifiers. If a consensus is reached, they add the reserve bytes linked these verifiers into the decentralized DB as well a hash of it within the block for further data validation.
By choosing to carry the election of the delegates every round, our goal to enable a fast rebalancing of the delegates in case of unwanted behavior. Indeed, such a process is allowed by quickly removing invalid reserve proofs (=canceled votes) as well as excluding a block producer if it does not meet the eligibility requirement. While we understand this can raise a concern with regards to political stability, we hope it will lead to healthier behavior among the delegates.
Another challenging issue is raised by the fact that reserve proofs are checked randomly by the block producer. This potentially leads to the fact that an invalid reserve proof could not be selected for checking during a specific period. To address this issue, we have assessed the survival probabilities of an invalid reserve proof under full staking (50,000 reserve proofs of 2M XCASH). At 300 random checks in the network per second (derived from 100 delegates verifying at one reserve proof per 300ms) we estimate an invalid reserve proof to be identified in less than 500s, 96.5% of the time. This means that most reserve proofs will be invalidated after a few block maximum. Combined with the need for several confirmations on the exchange, we believe to be exempted from potential short term voting+market arbitrages situations.
We are still reviewing how this process could be improved, notably by involving external nodes in the verification process in exchange for compensation.
Through the use of reserve proofs, a decentralized database and a decentralized process of reserve proof verification, we are able to provide a safe and efficient ground for the delegates election process. This processed is carried each round where the current round block verifiers elect the 100 next ones. By combining the storage of the delegate's details in a decentralized reserve bytes collection with a hash directly stored in the blockchain, we are able to guarantee the data validity and integrity without compromising the blockchain size.
What are VRFs.
VRFs are used to guarantee that the block producer selection is effectively random. The reasons for this has been discussed in the previous part of the document is mainly justified by a needed increase in security. Indeed, random block producer selection based on VRF makes the list of next block producers unpredictable and therefore leads to higher complexity of performing malicious attacks.
From a technical perspective, VRFs are pseudo-random functions that give a verifiable proof of the correctness of its output [25]. The pseudo-randomness nature of the function means that based on a set of input, the outcome of the function will always seem to be random, although it can be deterministic. The key added value of VRFs comes with the fact that they come with verifiable proof of their correctness meaning that the person who ran the function can prove to someone else that the result of the function did come from running the function itself and is not a number generated from an external process.
In practice, through the generation of a secret and public key pair (), one can compute a beta string output based on any input value (referred to as the alpha sting) while also generating a proof of correctness .
Later on, this person can prove to anyone that is correct with respect to the PK and VRF.
VRFs Properties.
We recall below the main properties of VRFs:
Time complexity: the execution time is constant and independent of the length of the alpha string
Uniqueness: impossibility to create two unique proofs that would verify the same set of public key, alpha, and beta string.
Collision resistance: impossibility to create two alpha string that would generate the same beta string
Random uniqueness: impossibility to predict the output of the function
Both RSA (RSA-FDH-VRF) and Elliptic Curve (ECVRF) can be used in VRF for the key generation. We have chosen to go for ECVRF, primarily because this gives the same level of key strength while shortening the length. For the cryptographic components, the Libsodium library [26] is used in combination with the Algorand integration of VRFs [27] [28].
Guaranteeing the randomness of the next block producer selection is a key feature of X-Cash DPoPS. This process is decomposed into three major steps:
VRF Keys Generation: each delegate generates a pair of Secret and Public keys as well as a one-hundred-character string
Ranking Hash Generation: delegates aggregate the keys and strings of others and hash it
VRF Keys Random Selection: delegates extract from the ranking hash the keys that will be used to perform the VRF
Next Block Producer Calculation: delegates use the key and random strings to perform a VRF and determine the next block producer selection
During the first step of the process, each delegate generates a set of Secret and Public VRF keys as well as a one-hundred-character string. This set of information is shared among all delegates so that every delegate owns the set of all other delegates.
The next step consists in ranking the strings and keys according to delegates position in terms of stake votes. Because all delegates have shared and received the same information while viewing the same ranking of stakes, the end rankings should be the same across all delegates.
Once this is done, delegates concatenate the one hundred-character strings with the previous block hash and generate from it a SHA2-512 hash. From this hash, they extract a byte that will be converted into a 1-100 number through the process described above. At this point, all delegates are still expected to be computing the same number, which corresponds to the rank of delegates from which the keys will be used to perform a VRF.
The final step of the process consists of performing the VRF using the keys of delegates that was selected in step 3. In the final step, the delegates extract from the VRF beta string 6 delegates number: the first one being the next block producer and the 5 others being its backup nodes. The extraction is done in a similar manner where the bytes of the beta string are sequentially processed into a delegate number. Similarly, to step 3, each byte is selected if below 200 in decimal value. Additionally, each block producer and backup nodes can be only selected once so in case of double selection the byte is skipped to the next one.
Each step involving calculus is also verified and validated through a dBFT consensus vote. The underlying goal of the voting is to create a final consensus on the result of these steps to allow nodes with a discrepancy to catch back on the process. This also enables to potentially identify the malicious nodes in the network that would diverge on a regular basis of the network consensus. The dBFT vote is done during the following step of the process:
Delegates keys and random string aggregation
Alpha string for the delegate ranking extraction and VRF
Delegate ranking number for the VRF key selection
VRF Beta string
Some interesting comments can be made on the Block producer election process. The first ones concern the random one-hundred-character string generation which is supposed to be fully random. This is currently set up this way in the GitHub version of X-Cash DPoPS but nothing prevents delegates from generating a customized version of the string. This means that delegates can submit any string to the others and this could challenge the randomness nature of the block producer election. In practice, as the string is bundled with the other delegates’ and after hashed there is no determinism in the election of the delegate’s secret and public key.
Given that we are extracting the VRF key node number from a 64-byte SHA2 and that we are excluding the byte higher than 200, this could potentially raise a question of having a hash that doesn’t contain a usable byte. Out of 64-byte, that probability is 5.7E-43. Therefore, the odds of such event occurring are considered low enough. Similar reasoning and conclusion can also be applied to the block producer and backup extraction from the VRF beta string. In the case of the calculation running out of bytes to choose, the main seed node will create the block for that round, to ensure the blockchain does not get stuck.
Through the use of VRF and dBFT consensus within the next block producer selection process, we hope to offer a new variant of this process that is efficient, reliable, and fault-tolerant. The random block producer selection process is a critical component of DPoPS as it prevents anticipation and improves security. Over the next upgrades and through the feedback from the community and the first implementation, the process will be improved with both new features and efficiency enhancements.
The modified block creation process is presented in this part by diving into how we addressed the chosen DBFT protocol and used it in DPoPS. For the easiness of reading, we are not covering the full details inherited from the CryptoNote block creation process [29], but only focusing on the enhancements we have made. The section also highlights both the daemon syncing process and data transmission protocol which we had to create.
The consensus method used in the X-Cash DPoPS is an application of the dBFT consensus protocol with some notable changes compared to the existing implementation of dBFT in cryptocurrencies consensus. It has been previously discussed how the block producer selection is made through VRF while not all consensus related data are stored on the blockchain.
We have chosen to go for a rather simple implementation of dBFT where delegates submit a data to be voted on and hash it. By then exchanging all hashes among all delegates, they are able to quickly determine if the other delegates have the same resulting hash.
This method is quickly used to determine if a consensus is generated among the delegates on any resulting output of a given function.
In a given set of N = 3n +1 delegates, we need 2n+1 delegates to reach a consensus in order for everyone to accept it.
Although the philosophy of the block remains the same, i.e. holding transactions, the structure of the block is significantly evolving under the X-Cash DPoPS to adapt to the various changes it implies. The most notable one is the need to track and record the consensus on the election of the delegates. For technical reasons, that are described in section 0, some of this data is stored in a separated decentralized database where dBFT rules also apply. The goal of this section is to dive in the structure of the block and explains how it is linked to the decentralized DB to make sure that the blockchain core principles still apply.
By using a delegated Proof-of-stake consensus, there is a significant increase in the data quantity used to perform the consensus. This data is stored in the reserve bytes section of the decentralized database. It includes the block producer name, its public address, and all the data linked the VRF production and the next round block verifiers. To guarantee the traceability and the integrity of this data, we need to find a way to have it reflected on the blockchain.
This is done by concatenating the reserve bytes data with the full content of the block to be produced and hash it. The resulting SHA2-512 is added to the block under the reserve blocks data variable, and then the block can be finally hashed into what is known as the block hash. Using this method, any nodes in the network including delegates can easily verify a posteriori any block in the chain as well as its pending reserve bytes data in the decentralized database.
To adjust for the change of algorithm, it is also required to upgrade the daemon syncing process to take into account the need to also check the block producers and verifiers. We provide below a high level of this process which consists of first retrieving the list of block verifiers from a random seed node. The next step is to randomly connect to one of them and request the reserve bytes for both the previous and current block.
To validate the block, the daemon will check if the previous block 100 public addresses (i.e. the expected 100 block verifiers for the next round) matches the one that signed the current block. If 67 or more do so, then the block is considered to be valid and is added to the local version of the blockchain. If not, it will be skipped, and the daemon will request the block from another block verifiers.
Summary.
To enable a fast and efficient communication among the delegates as well as adding the necessary functions to perform the consensus, we have created a set of data templates that we describe as the Data Transmission Protocol. These templates are separated into 4 main categories:
Block verifiers verification processes
Delegates commands
Blockchain syncing processes
Database syncing processes
Delegates identification processes.
To make sure that delegates are not impersonated, we have set up an identification process used in all delegates to delegates communication. This process mainly relies upon validating a signed message from a delegate, to ensure that they actually sent the message. Along this data is shared some additional information to guarantee that the delegates communicating are synced both in terms of blockchain and consensus status. The previous block hash is included to ensure that an elected delegate can not perform a replay attack with valid data in a different round. The current round part and current round part backup node, are included so an elected delegate can not perform a replay attack in different sections of the current round:
previous_block_hash - The previous block hash.
current_round_part - The current round part (1-4).
current_round_part_backup_node - The current main node in the current round part (0-5)
All messages involving a delegates authority will be signed using the delegates private key, corresponding to their registered public address that is stored in the decentralized database.
Templates.
The below figure gives a high-level overview of the templates used in the data transmission protocol. A more detailed description of each function can be found APPENDIX 0.
In this section, we describe the typical process for a block production round. Before launching the block creation process, the 100 elected delegates perform a VRF according to the process described in section 0. The resulting beta string will be included in the produced block to determine the next block verifiers and producers.
The next step consists of extracting each delegate’s role from the last beta string included in the last block. Each delegate is assigned a role of being a block verifier (validator) or producer in addition to potentially being a backup node for the validators. There are five backup nodes which can be used in two cases. The first one is the case where there is a technical failure of the block producer such as a disconnection from the network or high latency while the second one is the case where the network fails to reach consensus on a dBFT vote.
Once the roles have been assigned, the delegate will start creating its version of the next block. The block is composed of a header and the transaction content. The block header detailed data is given in APPENDIX X.X, and the transactions will be taken from the mempool at the discretion of the block producer in the same manner as in the original Proof-of-work process where miners were given a financial incentive to include the more rewarding transactions.
Once the block is finalized, two dBFT votes will be generated among the network of delegates. The first vote validates the block validity (VRF data, hash… etc) while the second vote validates the transaction content. If this step is successfully passed, the block will be signed by all block verifiers, and an additional dBFT vote will be carried to confirm the signature step.
The next step consists in carrying the election of the next 100 block verifiers. This is done by carrying a dBFT vote on the delegates stake ranking in the decentralized database. Ultimately the reserve bytes data of the block are added to the decentralized database, the block hash is completed and the block is added to the blockchain.
The decision to offload some data in a decentralized database can be challenged as the blockchain cannot be fully verified on a standalone basis anymore. This is true for the detailed delegate data although the core structure of the blocks remains the same. This approach is also interesting for two reasons, first of all, it will allow the blockchain to not increase due to this additional data. Secondly, the decentralized database will potentially allow new features that are under reflexion now: smart contracts, DLT based data storage, DLT based tokenization … etc.
Some concerns have also been raised about the block time increase to five minutes. This increase is made on purpose as the mainnet will progressively switch to a full settlement layer for big transactions only. By increasing the time, and also potentially the transaction fees, we hope to create an incentive for transactions to happen off mainnet through the sidechains and side channels.
The block creation process remains relatively heavy in terms of steps, dBFT votes, overall data consumption, and some challenging questions can be made on the data it will consume. Our estimates suggest that the overall network data consumption needed to create a block will be in the 1.5 GB range on average or 15 MB per delegates. Over the cycle of the block production, this represents an average needed bandwidth of 50 kB/s with peaks of 500 kB/s. This is an interesting metric as it shows that the bandwidth of the servers will be high enough to manage the mainnet and also shows great potential for the further scalability through sidechains.
The goal of this section is to explore the implications – namely related to economic and scalability - that DPoPS will have on the X-Cash ecosystem and other CryptoNote coins exploring the possibility of adopting DPoPS. Finally, we will explain our vision for both X-Cash and DPoPS in the future and the evolution we will implement.
Block reward and coin emission.
The block reward scheme will remain the same under DPoPS as in POW beside the following changes:
block-time increased from two to five minutes
block reward multiplied by two
The reasons for this change are multiple. The first one is justified by the fact that there are no alternative chains under DPoPS and therefore the number of confirmation to consider a transfer to be valid can be greatly reduced, notably from an exchange perspective. This means that fast block time is no longer needed as the confirmation time will be greatly reduced. The second reason is that once sidechains will be deployed, the mainchain will act as a settlement layer for these subchains meaning that users’ transactions will be directly carried in these sidechains. Sidechains block time will be customizable and it is therefore expected that sidechains dedicated for payment will be created with a block time in the magnitude order of the second.
Behind this philosophy relies the goal to keep a low transaction time and capacity on the mainnet which will mechanically induce higher transaction fees not compatible with micropayments. This implication is wanted and needed to avoid filling the mainnet with unnecessary transactions. Indeed, every transactions’ consensus and security level should be in line with its need. Through these mechanisms, we hope to progressively create an incentive from both a market and transaction time perspective to offload transactions on sidechains.
Mining price and market flow.
An interesting impact of switching the DPoPS from a mining perspective is the reduction of the marginal cost of creating X-CASH. In PoW, the costs of mining can be decomposed in fixed hardware costs and marginal costs from electricity consumption. In DPoS, the collateral needed to participate in the consensus can be assimilated as fixed costs but once this is paid for, there are no marginal costs of minting token.
This has great implications because, from a market flow perspective, we can expect that this will increase the ratio of hold vs. sold coins. Indeed, under PoW, miners are more likely to be tempted to sold part of the mined coins because they need to cover for the electricity costs. Under DPoS, not only do they not need to do it because the marginal costs are null, but they are also incentivized to keep the coins if they want to keep their stake constant relative to the circulating supply. Because the supply is increasing from the mining process, selling the coins would lead to having a voting market share decreasing over time. For people running full delegates node, this implies that they can potentially lose their ranking if they do not stake back the proceed from block forging.
Effective vs isolated circulating supply.
The switch to DPoPS also introduces a new form of supply: the isolated circulating supply. Under PoW, we distinguish three supply. The circulating supply which describes all the coins that have been mined and in circulation, the segregated supply that has been mined but that is locked in a specific wallet and the total supply which includes additionally the supply to be mined. Under DPoPS, the circulating supply is broken down into the effective vs isolated supply. Because circulating coins need to be locked in order to stake, this induces additional segregation of coins estimated at 40-60% of the circulating supply.
This leads to a lower effective circulating supply which usually has positive impacts on the price of the coins but arises at the cost of reduced liquidity.
Market of sidechains.
The key objective behind DPoPS is to pave the way for the next step which is the sidechains. While this subject is tackled in the next section of the paper and will be covered in a dedicated paper, we can highlight the potential positive impacts of sidechains from a financial perspective for delegates. When sidechains are released, delegates will be given the opportunity to host sidechains.
This will materialize in through a decentralized market where delegates will post their bids to host sidechains and be paid in XCASH. The typical metrics used here will be XCASH/kB/delegate for transactions and XCASH/kB/delegate/mo for storing. Based on this, we can see that XCASH will act as a gas in the network to run sidechains. On the other end, clients, consumers, and users will be able to buy sidechains from these bids and create their own subnetwork where the consensus, storage and transaction processing will be carried by delegates.
From a delegates perspective, this means that an additional source of revenues will be generated, increasing the yield of the collateral used for the delegate election. From a user perspective, this also leads to lower transaction costs for a given expected return on collateral.
An infrastructure for further deployments.
Thanks to DPoPS, we will have a more flexible network while still having a high level of decentralization (similarly to bitcoin and other PoW cryptocurrencies, the mining process has lead to the concentration of the mining power into a few mining pools, raising a concern about decentralization). In terms of flexibility, this will translate into a dynamic number of delegates if needed to better match the need for further/lesser decentralization. The new consortium of 100 delegates will also provide better coordination among the network and more particularly for the testing phases which are critical for the next developments.
Sidechains.
Summary.
Sidechains will be next major upgrade of the network and will happen once DPoS in in place and working accurately. Sidechains are parallel blockchains that relies on X-Cash from a technological and consensus perspective. Sidechains can be described as fork of X-Cash where the consensus is still managed by the mainnet operators and under similar rules. The key difference relies upon the fact that sidechains are managed by only a subset of mainnet delegates which leads to great implications such as lower costs, faster consensus and higher flexibility at the cost of less security.
Consensus protocol.
In the first iteration of sidechains, the consensus protocol will be the same as the mainnet, i.e. DPoPS. This means that similarly to the mainnet 2x+1 delegates will be needed to reach a consensus raising the minimum number of delegates needed to run a sidechain to 4. In the next version, our goal is to allow a wider range of consensus types such as proof-of-work, proof-of-authority, and proof-of-identity.
Settlement layer.
Sidechains will offer the (non-mandatory) feature to use the mainnet as a settlement layer. Transactions made within the sidechains will have the possibility to be pushed back and settled on the mainnet where sidechains will be used to carry less important transactions while the result is still recorded on the mainchain. This feature will be a key component of the network scalability as it will allow transactions to be carried off the mainnet while still having a high and satisfactory level of decentralization and security.
Type of sidechains.
We can distinguish two type of sidechains, X-CASH based sidechains, and data-based sidechains. The first one has a pure monetary purpose where people can send X-Cash at lower costs while also allowing for higher scalability. Thanks to the settlement feature, when the sidechain is closed, the remaining unspents (=balances) will be pushed back to the mainnet. From a scalability perspective, these sidechains will allow a drastic increase of the transaction per second as each sidechain will be able to carry between 10 to 20 transaction per seconds while the number of sidechains that can be run simultaneously is virtually unlimited.
On the other hand, sidechains will have the possibility to be data-based without involving the transfer of X-Cash. These type of sidechains will be used for a wide range of use cases where fiduciary token are not necessarily needed: supply chain, voting, … etc.
Not only sidechains will allow higher scalability in terms of transactions output, but they will also help the long term viability of the mainnet by reducing its size increase thanks to the offloading of non relevant transactions. Because sidechains can be deleted without impacting the mainnet, this also means that archiving is possible, guaranteeing the long term scaling of the infrastructure.
Side channels.
Side channels are similar to sidechains in the way that they are used to offload the mainnet from transactions. The key difference in terms of features is that they only carry monetary-based transactions that include X-Cash or tokens. From a technical perspective, side channels consist in locking a portion of the coins stored in the blockchain via a multi-signature scheme or smart contracts within a set of predefined participants. Each transaction will be shared and signed by the participants without being broadcasted to the network. This allows creating multiple transactions while only having the ultimate one written on the blockchain, saving transaction fees and enabling almost instantaneous transactions.
A layer set to evolve.
This first iteration of X-Cash DPoPS aims at setting up a new protocol with core features enabling an efficient and secure consensus to happen. Thanks to the feedback from the community, our goal is to improve it in the next iteration while also adding the next features that will allow additional use cases.
From an X-Cash perspective, the release of DPoPS will also introduce a new way of open-sourcing its development and involve further the community. Through the voting system, delegates will also be the voice of the community and will guide the next steps of developments.
Being a precursor for DPoS implementation in privacy based coin.
Currently, most privacy coins rely on PoW consensus and switching to a stake based system can be challenging due to the opacity of the balances. Through the DPoPS algorithm, we hope to be a precursor in the research of this field and will allow successive improvements, potentially made in cooperation with other coins.
From a research perspective, we want to stick to the open-source philosophy and give back as much as we have taken over the pasts years. For this reason, any development related to DPoPS will remain open source under
A consensus algorithm that can be reused and adapted for all coins.
The switch from a PoW consensus to a more energy-efficient algorithm will be a key challenge in the next years for all cryptocurrencies including bitcoin. Thanks to the DPoPS consensus algorithm we hope to have built a framework that can be derived to be adapted in any coins. We strongly believe the democratic nature of DPoS combined with privacy features that can be implemented in any coin can offer an interesting environment for a cryptocurrency to evolve.
X-Cash started as an open-source cryptocurrency focusing on privacy and decentralization. While CryptoNote offers state of the art privacy based on ring signatures and stealth addresses, it also limits the blockchain potential in terms of capacity, transaction output, and features.
The X-Cash team’s vision is to offer the most flexible cryptocurrency possible – enabling public transactions, sidechains hosting and side-channels payments – and is, therefore, proposing a network upgrade to become more scalable. Our vision is that DPoS offers the best tradeoff between security, scalability, and decentralization.
Implementing any stake-based consensus algorithm in a privacy coin can be challenging. For X-Cash, the choice has been made to use reserve proofs for stake verification combined with the release of a specific protocol that allows a standardized and secured communication in the network.
From a blockchain consensus perspective, it has been chosen to use a process where all block verfifiers validate every steps through a dBFT based vote. This allows an additional layer of security while also relying on verifiable random functions for the selection of each round’s block producer to further guarantee the resilience to malicious attacks.
Through this upgrade, the X-Cash team is also introducing an additional concept of a decentralized database. This feature is a key component of the DPoPS as it offloads the mainchain from the lesser essential information required in the consensus. Thanks to its capacity to easily evolve, the decentralized database will also preface the next improvements to be made to the network.
In privacy coins, users value decentralization and tolerance to failure above efficiency, and this is why we have generally opted for the more decentralized, fair, and trustworthy options over more efficient ones. With the introduction of sidechains, we will, however, allow creating additional blockchains where the decentralization vs. efficiency tradeoff will better match the specific user or use case’s needs.
We believe that the fact that users have the right to decide whether they are ready to give up some privacy to take part in the network is a positive evolution. If anything, it makes the X-Cash blockchain more open because anyone can take part in the blockchain consensus without the need for specialized hardware.
From a community point of view, we are convinced the introduction of DPoPS will strengthen the users around their delegates and allow a more democratic decision-making process in any network related decision. With DPoPS, the team’s vision to create the most efficient and democratic decentralized organization is getting one step closer.
MAIN_NODES_TO_NODES_PART_4_OF_ROUND_CREATE_NEW_BLOCK Description: This template is used during the block creation process by the block producer to share the block header of the proposed block with the block verifiers for them to verify it. Specific variables: block_ bob
MAIN_NODES_TO_NODES_PART_4_OF_ROUND
Description: This template is used during the block creation process by the block producer to share the block content of the proposed block with the block verifiers for them to verify it. Specific variables: vrf_public_key, vrf_alpha_string, vrf_rpoof, vrf_beta_string
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_VRF_DATA
Description: This template is used in all VRF related processes by the block producer to share the VRF data with the block verifiers for them to verify all block verifiers data. Specific variables: vrf_secret_key, vrf_public_key, random_data
NODES_TO_NODES_VOTE_RESULTS
Description: This template is used in all consensus related processes by the delegates to share the result of their votes with the other delegates.
Specific variables: vote_settings, vote_data
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_BLOCK_BLOB_SIGNATURE
Description: This template is used in the signature aggregation process by the block verifiers to share their block blob signature.
Specific variables: block_blob_signature
BLOCK_VERIFIERS_TO_MAIN_NETWORK_DATA_NODE_CREATE_NEW_BLOCK
Description: This template is used during the block production process by the block verifiers to inform the block producer that they acknowledge it’s status.
Specific variables: N/A
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_INVALID_RESERVE_PROOFS
Description: This template is used during the reserve proofs verification process by all delegates to share with the other delegates the invalid reserve proofs they have found.
Specific variables: reserve_proof
NODE_TO_NETWORK_DATA_NODES_GET_PREVIOUS_CURRENT_NEXT_BLOCK_VERIFIERS_LIST
Description: This template is used by any node from the network to request the list of previous, current and next block verifiers.
Specific variables: N/A
NODE_TO_NETWORK_DATA_NODES_GET_CURRENT_BLOCK_VERIFIERS_LIST
Description: This template is used by any node from the network to request the list of current block verifiers.
Specific variables: N/A
NETWORK_DATA_NODE_TO_NODE_SEND_PREVIOUS_CURRENT_NEXT_BLOCK_VERIFIERS_LIST
Description: This template is used by a network data node to send the list of previous, current a next block verifiers to a node that requested it.
Specific variables: N/A
NETWORK_DATA_NODE_TO_NODE_SEND_CURRENT_BLOCK_VERIFIERS_LIST
Description: This template is used by a network data node to send the list of current block verifiers to a node that requested it.
Specific variables: N/A
NODES_TO_BLOCK_VERIFIERS_REGISTER_DELEGATE
Description: This template is used by a node in the network to register as a delegate in the decentralized database and share its details with all block verifiers
Specific variables: delegate_name, delegates_IP_address, public_address, xcash_proof_of_stake_signature
NODES_TO_BLOCK_VERIFIERS_REMOVE_DELEGATE
Description: This template is used by a delegate in the network to ask the block verifiers to be removed from the decentralized database.
Specific variables: N/A
NODES_TO_BLOCK_VERIFIERS_UPDATE_DELEGATE
Description: This template is used by a delegate in the network to ask the block verifiers to modify its details in the decentralized database.
Specific variables: value
NODE_TO_BLOCK_VERIFIERS_ADD_RESERVE_PROOF
Description: This template is used by a node in the network to send a reserve proof to the block verifiers to be added to the decentralized database.
Specific variables: reserve_proof
NODE_TO_BLOCK_VERIFIERS_GET_RESERVE_BYTES
Description: This template is used by a node in the network to request the reserve bytes for a given block.
Specific variables: block_height
BLOCK_VERIFIERS_TO_NODE_SEND_RESERVE_BYTES
Description: This template is used by a block verifier to send to a node the reserve bytes for a given block.
Specific variables: reserve_bytes
NODES_TO_BLOCK_VERIFIERS_RESERVE_BYTES_DATABASE_SYNC_CHECK_ALL_UPDATE
Description: This template is used by a node to check which block verifiers have a synced reserve bytes database.
Specific variables: N/A
BLOCK_VERIFIERS_TO_NODES_RESERVE_BYTES_DATABASE_SYNC_CHECK_ALL_DOWNLOAD
Description:The purpose of this message is for a node to check what block verifiers have a synced reserve bytes database
Specific variables:
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_BYTES_DATABASE_SYNC_CHECK_ALL_UPDATE
Description: This template is used by a block verifier to check if its reserve bytes database is synced.
Specific variables: data_hash
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_BYTES_DATABASE_SYNC_CHECK_ALL_DOWNLOAD
Description: this template is used by a block verifier to confirm to another one if it’s reserve bytes database is up to date.
Specific variables: reserve_bytes_database
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_BYTES_DATABASE_SYNC_CHECK_UPDATE
Description: This template is used by a block verifier to check if its reserve bytes database is synced.
Specific variables: data_hash
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_BYTES_DATABASE_SYNC_CHECK_DOWNLOAD
Description: This template is used by a block verifier to check if its reserve bytes database is synced.
Specific variables: reserve_bytes_database
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_BYTES_DATABASE_DOWNLOAD_FILE_UPDATE
Description: This template is used by a block verifier to download the up-to-date reserve bytes database from a block verifier.
Specific variables: file
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_BYTES_DATABASE_DOWNLOAD_FILE_DOWNLOAD
Description: This function is used by a block verifier to send its up-to-date reserve bytes database to another one.
Specific variables: reserve_bytes_database
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_PROOFS_DATABASE_SYNC_CHECK_ALL_UPDATE
Description: This template is used by a block verifier to check if its reserve proof database is synced.
Specific variables: data_hash
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_PROOFS_DATABASE_SYNC_CHECK_ALL_DOWNLOAD
Description: this template is used by a block verifier to confirm to another one if its reserve bytes database is up to date.
Specific variables: reserve_proof_database
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_PROOFS_DATABASE_SYNC_CHECK_UPDATE
Description: This template is used by a block verifier to check if its reserve proof database is synced.
Specific variables:
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_PROOFS_DATABASE_SYNC_CHECK_DOWNLOAD
Description: This template is used by a block verifier to confirm to another one if it’s reserve bytes database is up to date.
Specific variables: reserve_proof_database
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_PROOFS_DATABASE_DOWNLOAD_FILE_UPDATE
Description: This template is used by a block verifier to download the up-to-date reserve proof database from a block verifier.
Specific variables: file
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_PROOFS_DATABASE_DOWNLOAD_FILE_DOWNLOAD
Description: This function is used by a block verifier to send its up-to-date reserve bytes database to another one.
Specific variables: reserve_proofs_database
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_DELEGATES_DATABASE_SYNC_CHECK_UPDATE
Description: This template is used by a block verifier to check if its delegates database is synced.
Specific variables: data_hash
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_DELEGATES_DATABASE_SYNC_CHECK_DOWNLOAD
Description: this template is used by a block verifier to confirm to another one if its delegates database is up to date.
Specific variables: delegates_database
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_DELEGATES_DATABASE_DOWNLOAD_FILE_UPDATE
Description: This template is used by a block verifier to download the up-to-date delegates database from a block verifier.
Specific variables: N/A
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_DELEGATES_DATABASE_DOWNLOAD_FILE_DOWNLOAD
Description: This function is used by a block verifier to send its up-to-date delegates database to another one.
Specific variables: delegates_database
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_STATISTICS_DATABASE_SYNC_CHECK_UPDATE
Description: This template is used by a block verifier to check if its statistics database is synced.
Specific variables: data hash
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_STATISTICS_DATABASE_SYNC_CHECK_DOWNLOAD
Description: This template is used by a block verifier to confirm to another one if its statistics database is up to date.
Specific variables: statistics_database
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_STATISTICS_DATABASE_DOWNLOAD_FILE_UPDATE
Description: This template is used by a block verifier to download the up-to-date statistics database from a block verifier.
Specific variables: N/A
BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_STATISTICS_DATABASE_DOWNLOAD_FILE_DOWNLOAD
Description: This function is used by a block verifier to send its up-to-date statistics database to another one.
Specific variables: statistics_database
X-Cash nodes interact with each other through a daemon. Check the daemon documentation - to connect to the network.
Go to the CLI wallet documentation () to learn everything about the X-CASH wallet and the different commands.
You can interact with X-Cash with Remote Procedure Calls. Have a look at and to learn more.
You can bootstrap your synchronization if you already have a RAW file of the blockchain. Check out the full documentation of
I want to start building in python
Please view the
I want to start building in Go
Please view the
Install from
Build from
or
group: for private groups. Private groups works as shared but the delegate decide how he/she going to distribute the votes. See how to set it up
URL:
URL:
URL:
URL:
Generally speaking, running a delegate node requires knowledge and experience in information and network technologies. However, we believe that it should be accessible to everyone who is willing to learn. This guide will help you get introduced to servers and Linux system, and getting started securely to start your own delegate node. If you find yourself stranded, will be happy to help you 🙂
One easy way to generate an SSH key on Windows is by using PuttyGen. You can download Putty at and follow to create your SSH key pair.
We are agnostic as to which server provider you should choose to run the xcash-dpops program. Our recommendation is to find a Dedicated server or VPS that matches the , and to follow the service you are most confortable with.
Use your SSH RSA key pair that you have to access your newly rented server. Most of the server hosting service lets you provide your SSH key on their dashboard and automatically authorize it.
In Putty, go to the SSH > Auth tab and browse to your private key file rsa-key.ppk to use as authentication to log into your server.
With the key pair you have , you will have to register the public key on your server so it can recognize you. To do so, you need to add your public SSH key into the file ~/.ssh/authorized_keys in your server.
Once , use your preferred text editor to create and/or open the authorized_keys file:
The public key was created after with PuttyGen. You have created two files: the public key rsa-key and the private key rsa-key.ppk
to your server with your already existing credentials (given by your server provider) as a root user.
NameCheap has for setting up the DNS record, but any other domain name provider should have a similar service.
Once you have done every step above, and are familiarized with your server, you can go through the next step and install the delegate program, xcash-dpops. Follow the for a complete tutorial.
All delegates are listed on the . Take time to get to learn more about them, check their reliability statistics, and their setup. You will find 3 types of delegates:
The 's information is filled by the delegates. There are currently no checks to the veracity of the information provided. It is your duty to make sure that a delegate is trustworthy, that he will redistribute the reward and that the fees displayed are correct.
Most if not all delegates are discussing freely on X-Cash official Discord server. We recommend that you there and engage discussion with the node manager to help you make a choice.
A simple ROI-Calculator is available here ; there you can see how much rewards you can possibly earn by staking XCASH.
Download locally this (updated every few days, but you can manually update it yourself), and input your desired staking amount to see what reward you can expect depending on the delegate you are voting for, their current stake and fees.
To participate in the network, you will have to vote with your XCASH to elect a delegate that you see as trustworthy and you want to help to get a forging position. The DPOPS consensus has been designed so that the XCASH you use to vote stays in your wallet, hence in your control (see ).
Download the 2.0.0 version of the X-Cash binaries, on our or on the .
You can either put the <delegates_public_address> which is a standard XCASH public address, or the <delegate_name>. This information is available on the .
Download the wallet on your compatible android phone using the following link :
The X-Cash Public Network is governed by 50 delegates through a custom Delegated Proof of Stake (DPoS) consensus, the . Anyone can run an X-Cash node and become a delegate. But to be able to forge new blocks and earn the reward, you will need to be voted into the top 50 by other members of the community.
**** - Source code of the DPoPS program.
**** - Delegated Proof-of-Private-Stake, a DPoS implementation under X-Cash.
**** - Join the Discord server to announce yourself as a delegate.
Please use the as the website will step by step walk you through what you need to do, with custom commands, as you will need to see real time delegate prices and who to send the xcash to, but the general process is described below.
You can view the previous block producer on the website with the price, but you can also use the
**** - Source code of the DPoPS and namespace program.
Don't forget to update your delegate fee by as well.
In systemd, a unit refers to any resource that the system knows how to operate on and manage. This is the primary object that the systemd tools know how to deal with. These resources are defined using configuration files called unit files. Whether you installed with the or , the programs needed to run the X-Cash consensus are managed in systemd with unit files.
Please use the as the website will step by step walk you through what you need to do, with custom commands, as you will need to see real time delegate prices and who to send the xcash to, but the general process is described below.
You can view the previous block producer on the website with the price, but you can also use the
The purpose of this section is to describe the primary components and purposes of these templates. More details can be found in the dedicated section of the DPoPS Github.
Minimum
Recommended
OS
Ubuntu 18.04
Ubuntu 18.04
CPU
4 threads, 2.0 GHz or more per thread
4 threads, 2.0 GHz or more per thread
RAM
6GB
32GB
Hard Drive
50GB
2TB
Bandwidth Transfer
100GB per month
500GB per month
Bandwidth Speed
100 Mbps
500 Mbps
What is DPoPS? What's unique about this consensus?
We recommend that you have a look at the technical design of the consensus, which as been built from the ground up to work with X-Cash.
I want to become a delegate and set up a validator node.
First, follow the server setup guide if you are not familiar with Linux instances. Then, follow the node program installation to install the necessary program to run the consensus. Finally, see the instructions to register yourself as a delegate.
I want to vote.
Have a look at our quick vote & staking guide.
I want to participate in the beta.
If you want to become a delegate during the beta, you will need to install a server as per the guide, install the node programand register yourself as a delegate. Then, follow up on the additional instructions to join the beta.
If you just want to vote, the instructions are indicated in vote & staking.
I want to register or renew a name in the xcash namespace
I want to edit my namespace.
Please review the manage documentation
I want to setup my price as a delegate.
Please review the delegate management documentation
Name
Type
Requried
Purpose
public_address
char*
True
The public address of the delegate
total_vote_count
char*
True
The total vote count that the delegate has received.
total_vote_count_number
long long int
True
Same as the above just stored as an int
IP_address
char*
True
The IP address of the delegate
delegate_name
char*
True
The username of the delegate
about
char*
False
About the delegate
website
char*
False
The delegate’s website
team
char*
False
The delegate’s team
pool_mode
char*
True
If the delegate is running a shared delegate structure or not
fee_structure
char*
True
The fee the delegate will charge if running the pool mode (can be 0 if pool mode is false)
server_settings
char*
False
The server specs of the delegate
block_verifier_score
char*
True
the block verifiers score for invalid reserve proofs
online_status
char*
True
The current online status of the delegate
block_verifier_total_rounds
char*
True
The total rounds the delegate has participated in
block_verifier_online_total_rounds
char*
True
The amount of rounds that delegate was online for and participated in
block_verifier_online_percentage
char*
True
The percentage of the above two fields, used to show the stability of the delegate for staking information
block_producer_total_rounds
char*
True
The total rounds the delegate has been the block producer
block_producer_block_heights
char*
True
A list of block heights the delegate wa the block producer for
Name
Type
Purpose
most_total_rounds_delegate_name
char*
The delegate name of the block verifier that has participated in the most total rounds
most_total_rounds
char*
The amount of the block verifier that has participated in the most total rounds
best_block_verifier_online_percentage_delegate_name
char*
The delegate name of the best block verifier that has the least amount of time outs
best_block_verifier_online_percentage
char*
The percentage of the best block verifier that has the least amount of time outs
most_block_producer_total_rounds_delegate_name
char*
The delegate name of the block verifier that has been the block producer the most
most_block_producer_total_rounds
char*
The amount of the block verifier that has been the block producer the most
Name
Type
Purpose
public_address_created_reserve_proof
char*
The public address of the user that is staking
public_address_voted_for
char*
The public address of the delegate that the user staked towards
total
char*
The total amount of the reserve proof
reserve proof
char*
The reserve proof
Name
Type
Purpose
block_height
char*
The block height
reserve_bytes_data_hash
char*
The SHA2-512 data hash of the reserve_bytes field
reserve_bytes
char*
The network block with all of the VRF data in the reserve bytes.
[1]
G. Kostarev, "Review of blockchain consensus mechanisms," 21 07 2017. [Online]. Available: https://blog.wavesplatform.com/review-of-blockchain-consensus-mechanisms-f575afae38f2.
[2]
Blockgenic, "Different Blockchain Consensus Mechanisms," 10 11 2018. [Online]. Available: https://hackernoon.com/different-blockchain-consensus-mechanisms-d19ea6c3bcd6.
[3]
M. Wright, "Delegated Proof of Stake (DPOS) vs Proof of Work (POW)," 04 01 2015. [Online]. Available: https://bytemaster.github.io/bitshares/2015/01/04/Delegated-Proof-of-Stake-vs-Proof-of-Work/.
[4]
D. Larimer, "DPOS Consensus Algorithm - The Missing White Paper," 29 05 2017. [Online]. Available: https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper.
[5]
"Cold Staking," Particl, 18 07 2019. [Online]. Available: https://particl.wiki/staking.
[6]
"Byzantine fault," Wikipedia, [Online]. Available: https://en.wikipedia.org/wiki/Byzantine_fault.
[7]
"pEOS Whitepaper - Private, untraceable transactions on EOS," pEOS, [Online]. Available: https://peos.one/docs/pEOS_whitepaper_rev1_1.pdf.
[8]
Jakiman, "Purple paper - Technical notes," PIVX, 23 03 2017. [Online]. Available: https://pivx.org/wp-content/uploads/2017/03/PIVX-purple-paper-Technincal-Notes.pdf.
[9]
D. D. Evan Duffield, "Dash: A Payments-Focused Cryptocurrency," Dash, 21 03 2015. [Online]. Available: https://github.com/dashpay/dash/wiki/Whitepaper.
[10]
"ENIGMA - A private, secure and untraceable transaction system for cloack," Cloack, [Online]. Available: https://www.cloakcoin.com/user/themes/g5_cloak/resources/CloakCoin_Whitepaper_v2.1.pdf.
[11]
"get_reserve_proof," Monero, [Online]. Available: https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#get_reserve_proof.
[12]
"Delegated Proof of Stake (DPOS)," BitShares, 29 08 2018. [Online]. Available: https://how.bitshares.works/en/master/technology/dpos.html.
[13]
"aelf - A Multi-Chain Parallel Computing," aelf, 07 06 2018. [Online]. Available: https://aelf.io/gridcn/aelf_whitepaper_EN.pdf?v=1.6.
[14]
A. HAYES, "How Does Bitcoin Mining Work?," Investopedia, 25 06 2019. [Online]. Available: https://www.investopedia.com/tech/how-does-bitcoin-mining-work/.
[15]
B. Batog, "Bitcoin Mining versus Lottery," 30 10 2017. [Online]. Available: https://medium.com/@batog/bitcoin-mining-versus-lottery-69d3b46e0f65.
[16]
a. b. B. C. C.-f.-B. D. D. d. d. E. E. F. F. G. g. J.-L. j. j. k. l. m. m. m. N. P. p. Q. Alias, "Whitepaper:Nxt," Nxt, [Online]. Available: https://web.archive.org/web/20150203012031/http://wiki.nxtcrypto.org/wiki/Whitepaper:Nxt#Blocks.
[17]
L. R. D. P. J. V. S. Goldberg, "Verifiable Random Functions (VRFs)," 14 09 2018. [Online]. Available: https://tools.ietf.org/html/draft-irtf-cfrg-vrf-03.
[18]
q. Honglei-Cong, "VBFT Introduction," Ontology, 19 07 2018. [Online]. Available: https://github.com/ontio/documentation/blob/master/vbft-intro/vbft-intro.md.
[19]
"PROOF OF STAKE MINING," Cardano, [Online]. Available: https://www.cardano.org/en/ouroboros/.
[20]
NicolasDP, "cardano-crypto," 11 06 2018. [Online]. Available: https://github.com/input-output-hk/cardano-crypto/blob/master/tests/goldens/cardano/crypto/VRF.
[21]
S. Micali, M. O. Rabin and S. P. Vadhan, "Verifiable random functions", Proceedings of the 40th IEEE Symposium on Foundations of Computer Science. pp. 120–130., (1999).
[22]
D. Larimer, "Consensus Algorithm (BFT-DPOS)," 16 03 2018.
[23]
D. Larimer, "Consensus Algorithm (BFT-DPOS)," EOS, 16 03 2018. [Online]. Available: https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md.
[24]
M. A. T. M. R. L. Noether S, "Ring Confidential Transactions".
[25]
Y. A. odis Y, "A Verifiable Random Function with Short Proofs and Keys," 2005.
[26]
jedisct, "libsodium," [Online]. Available: https://github.com/jedisct1/libsodium.
[27]
M. S. A. Chen J, "A secure and efficient distributed ledger".
[28]
H. R. M. S. V. G. Z. N. A. Gilad Y, "Proceedings of the 26th Symposium on Operating Systems Principles".
[29]
M. A. T. A. M. J. C. Albert Werner, "CRYPTONOTE STANDARD 003: CryptoNote Blockchain," September 2012.
How turbo tx work
Traditional 0-conf tx work by allowing a user to accept a tx that has not been added to a block yet. These are not guaranteed tx, but are relative low risk. Based on this system its said that 0-conf tx are safe to a point for small amounts (like buying small products from a store) where the wait time needs to be much lower than the block time. this is based on a few things:
#1 All tx should be moved into the next block (the faster the tx is added the better). This is due to the longer a tx is in the mem pool (the waiting area for tx before they go into a block) the more chance their is for that tx to get reversed by the sender.
#2 The only way to replace a tx is to, send a tx to the store, buy the products, leave the store and send another tx to yourself, then have a modified daemon that will accept your second tx and control enough network power (does not have to be 51% can be 25% for a 1/4 chance etc) to have your daemon mine the block and insert the second tx.
Since most proof of work coins have only a few centralized pools, the pool operators can have a high chance to reverse transactions since all workers are sending hashes to their daemon. Any one accepting 0-conf tx on this kind of network have these 2 aspects to trust that wont happen.
This is more a less a convenience thing. a store can accept 0-conf on the off basis this will happen, but for small style line waiting purchases. Obviously if buying a car or something it would be best to wait for at least one confirmation, as only a 51% attack could reverse it at that point.
With xcash's unique combination of unspent based blockchain and DBFT consensus mining, their are ways to improve the current 0-conf tx disadvantages.
For the most part no, their is only a select combination of blockchains they can work on. Most account based blockchains (where they use a nonce to index txs and only store your current balance) wont work. This is due to one could just send the tx to the store, and then quickly send another tx with a higher fee to themselves and cancel out the store tx once in their car. Only blockchains that are unspent based (where it keeps a record of all the in and out amounts that make your balance) can work. This is due to because daemons on the network will reject double spent unspents, or unspents that are already in the mem pool (waiting to be added to a block). However some blockchains like Bitcoin have a replace by fee (even though bitcoin is a unspent style blockchain), so it would not work on this type of unspent blockchain.
In xcash things work differently due to xcash DPOPS. Only the top 50 delegates can mine blocks on the network. One can have their own delegate in the top 50 and attempt a replace but they would need to be picked so they only max can have a 2% chance. This right here is more decentralized than most proof of work coins. But their are still ways to make this better, and xcash has figured out how to make guaranteed 0-conf tx.
Here is how this works xcash DPOPS works off of DBFT (delegated byzantine fault tolerance). DBFT requires everyone to verify a block BEFORE adding it to the network. Because of this if a delegate modified its xcashd to accept that second tx (the fake or replacement tx), it wont show in the mempool for the other 49 delegates.
Also a valid tx wont be in all 50 delegates, but should be in the majority more than 27. Because of this if a DBFT check of each individual transaction that the block producer selected to mine is run, their will never be a reversed tx being added to a block based on these few rules above, as the other 49 will always stop the malfunctioning tx and or delegate. As long as 27+ DPOPS delegates are true, this holds. If not their are way worse things to worry about so its a non point to look at what if not. (For example delegates could just mine infinite blocks every few seconds etc etc)
if a user uses a xcashd that has the 0-conf tx in the mempool (or can find a delegate who has it) and verifies the tx pub key and outputs, then 0-conf tx are confirmed valid before they are added to the block.
This would 100% eliminate the concerns for 0-conf. This is because if 27+ delegates mempool have a tx in it, it will be mined at some point due to the DBFT and unspent features. Also if a delegate has invalid tx it wont be mined due to the dbft check.
Once your server is set up and the necessary programs installed, you will be able to set your register/renewal price as a delegate.
Once you have correctly set up your instance, installed the different programs, you can set your register/renewal price as a delegate. If your the previous block producer, users will see your delegate and your price on website and can choose to use your delegate or wait for another maybe cheaper delegate. They can also view all delegates prices on the website.
By default your price will be 100M xcash until you update it.
First of all, the wallet service should be running in the background. Stop it by using the command:
Open and let synchronize the wallet you used to register as a delegate, either when using the auto-installer or created manually.
Replace the <WALLET_NAME> with your own.
If you installed with the autoinstaller script, the wallet name will be delegate-wallet
Once your wallet is fully synchronized, you can use the remote_data_delegates_set_amount command with the following parameters:
Replace the <amount> with the amount of xcash (has to be whole numbers and in regular units) you want to charge for registering and renewal of names in the xcash namespace.
You will be prompted to wait for the next valid data interval (at most 10 inutes). Once your request has been accepted, you will receive the message The remote data amount has been updated successfully.
You can exit the wallet and restart the wallet service:
How to send a turbo tx.
Note (turbo tx will not work for sub addresses)
You can send turbo tx from any wallet. If using a GUI based wallet their should be a slider to do this. In the CLI wallet you can specifiy the public or private tx style by using transfer public XCA 100 or transfer private XCA 100. If left blank it will default to private.
You now can specifiy the turbo tx settings by using transfer tpublic XCA 100 or transfer tprivate XCA 100. If left blank it will default to a non turbo private tx.
You can also use the tpublic and tprivate fields for the tx_privacy_settings field on the RPC.
Once you send a turbo transaction, you will receive the same details like any other transaction, but will also receive a link to a url and a "turbo tx id". You can give this url to the receiver to have them instantly verify your tx.
These id stay valid for 1 hour before being deleted as the point of a turbo tx is to verify before being in a block, but once in a block extra data is no longer needed. Users can verify tx for one hour after sending them (even if they are added to the blockchain) using the turbo tx id, otherwise the real tx id will be needed.
How to receive turbo tx
The steps to check if any mem pool tx is guaranteed is the following #1 Check if at least 27+ delegates have the tx in their mem pool. #2 Use one of the delegates to check the tx key and verify the amount.
We have built a tool that allows for all of this to happen, and outputs true or false with stats on a webpage. We host the tool, but its opensource and anyone can run it on their on computer to verify tx as well.
Note (turbo tx will not work for sub addresses)
Once someone sends you a turbo tx id or link, it is very simple to verify the tx.
You will need to use a tool to verify the turbo tx. You can use our official website to easily type in the id and it will tell you if its verified or not. You can also run a local version of the tool, as its open source. You will need both the frontend and backend
Once you have the tool setup or decide to use the official website, go to the link, or type the id into the website. It should then say if its verified or not, and the tx details.
The tool can only tell you blockchain wise if the transaction is valid and will make it on the blockchain. Its up to you though to make sure that the sending and receiving address are correct, as well as the amount, as we dont know the details of the tx between the two parties. If its going to your wallet from the correct sender, and for the correct amount then its verified.
Set of instructions to participate in the phase 2 of the DPOPS beta.
We would also like to give a huge thanks to all the contributors who assisted us since the alpha to identify these bugs and also providing their feedback to improve DPOPS. We are able to move forward with the phase 2 of the beta with the help of all beta participant and engaged community members.
The following guide is split into two sections: the first part for becoming a delegate during the beta, and the second part dedicated to voting during the beta.
The phase 2 will start on Saturday 29th August, at 6 pm Paris time. Until this time, you won't be able to perform any other operation on the blockchain apart from voting and updating delegate information.
If you weren't part of phase 1 of the beta, you will first have to rent a server and install the node validation program. We recommend that you go through the whole documentation to install the node program.
If you have joined the beta during the first phase, you most certainly have your setup already prepared. You will just need to update your block verifier keys before moving forward.
To do that without re-installing all your delegate setup, first run this command to update your xcash-dpops binaries:
Then, to update your keys in your different service, copy and paste the following command and run it in your terminal:
This will generate a new pair of block verifier keys, as well as update the xcash-dpops.service file with the corresponding information.
Be sure to securely save your block verifier keys.
Now, you will have to tell your program to start automatically at the right time on August 29th.
Edit the systemd unit file xcash-dpops.service from the /lib/systemd/system/ folder :
You will get the following unit file:
At the ExecStart line, add the following option at the end:
The --block-verifiers-secret-key should always be the first parameter.
This will tell the xcash-dpops program to start 5 minutes before 6 PM Paris time on August 29th.
Once the changes added, save and close the xcash-dpops.service file and update systemctl to take the changes into account:
You will need to reset the current blockchain and data you have gathered in your local database during the first phase of the beta. First, copy/paste the following command to launch the auto-installer script and stop the running programs:
Choose option 10 to automatically reset the local database and bring back your local blockchain to block 640,000.
Finally, run the auto-installer's option 7 - Restart Programs to restart the different services.
You can now register yourself as a delegate.
In case you don't have the blockchain downloaded or you are joining the beta for the first time, we have prepared a bootstrap version of the blockchain snapshot. To download it, you will need to run the auto-installer script:
And chose option 4: Update/Install the blockchain
Now that your installation of the program is ready, you can register yourself as a delegate. Your information will be added to the delegates' explorer in the next minutes, and you will be ready to accept votes.
Do not forget to update your public information.
To make sure that you are correctly registered and every step has been done accordingly, check the live logging of the xcash-dpops program using the command:
The system should display Waiting for the specific start time if you have followed every step correctly.
If you find yourself having difficulties, don't hesitate to join the Discord channel for delegates.
To vote with your XCASH, you will need to download the beta version of the 2.0.0 binaries on GitHub. Select the link relating to your Operating System and download the GitHub release. Unpack them in a folder (preferably close to the root or C:/ folder).
You will need to synchronize the wallet on the alternative chain (the "beta-chain"), either by downloading the alternative chain completely or by synchronizing through one of the seed nodes. We highly recommend synchronizing from a seed node, as downloading the whole blockchain will take time, data, and will be useless at the end of the beta phase because it will be discarded.
You will need to restore the wallet you will use to vote with and synchronize it with a seed node.
Open a terminal window (cmd or PowerShell) as an administrator and change directory to your wallet folder.
Then, run the xcash-wallet-cli.exe with the following option:
And replace <daemon_address> with either europe1.xcash.foundation or us2.xcash.foundation depending on your location. You will be then prompted to restore your wallet. Insert the seed of your wallet and let it synchronize to the current height.
On Unix systems
Open a terminal window and run the xcash-wallet-cli file with the following options:
And replace <daemon_address> with either europe1.xcash.foundation or us2.xcash.foundation depending on your location. You will be then prompted to restore your wallet. Insert the seed of your wallet and let it synchronize to the current height.
Once your wallet as finished synchronizing completely, you will be able to vote for your desired delegate.
Initiating a transfer or a sweep_all function before the start of the beta on August 28th will not succeed and prevent you from voting.
You will have to restore your wallet again in that case.
Use the vote command:
You can either put the <delegates_public_address> which is a standard XCASH public address, or the <delegate_name>. This information is available on the delegate explorer.
The wallet will create a reserve proof with the entirety of the wallet and assign it to the designated delegate. You will get a success message when your vote is taken into account.
There is a couple of rules to observe when voting:
You can only have one vote assigned per wallet. If you want to vote for another delegate, you will need to create a new wallet, and send to it XCASH you plan to stake.
Votes are taken into account at the top of the next hour. If you apply a new vote at XX:30, it will be in effect at XX+1:00.
You need a minimum of 2,000,000 (2 Million) XCASH in the wallet to vote.
Spending any amount in your wallet will cancel the vote. It is recommended to stake from a wallet you are not actively using.
This yellow paper details the technical concepts and implementation of hybrid transactions (also known as FlexPrivacy ©), a feature enabling public and private transactions on the X-Cash public blockchain.
In the first part, the paper aims at detailing how the hybrid transactions operate from a user’s perspective with some real-world use cases. A parallel is made between the digital money system and the economic behaviors associated with the current FIAT system. Secondly, a deeper understanding of the technology is given, explaining the implication on a blockchain perspective, as well as the edge cases and their approaches. Lastly, the last part consists in an in-depth approach of the mathematical concepts and technical implementation of the hybrid transaction in the X-Cash blockchain.
The hybrid transaction feature allows users to send and receive public or private transactions on the X-Network Blockchain X-Cash, which is based on the CryptoNote protocol. This feature is implemented on a per transaction basis where users can directly switch the privacy type by choosing the setting before attempting to send a transaction.
In a public transaction, the following additional information is made public:
Sender’s address
Receiver’s address
Amount sent
Change amount sent back to the sender’s address
However, the public transaction does not compromise the sender’s or receiver’s wallet full balances nor the real mixin (number of signatures in the ring signature that authorizes the transaction) that provided the X-Cash balance. For privacy reasons, it is essential to keep these two details unknown in every transaction.
The previous default transaction type of full privacy in CryptoNight coin (through stealth addresses and RingCT) remains available and unchanged in the new hybrid setup. This system is a very close approach to the current fiat system from a daily usage perspective, where the option is given to make a transaction leaving a trail (similar to using check, credit card. . . etc.) versus paying in cash which grants a potentially high level of anonymity. Either way, similarly to the fiat system, there is no need to have multiple accounts to pay with cash, or check and the account balance, as well as the receiverś account balance, is never made public.
Public transactions have been made available on X-Cash since the 1.4.0 release on November 6 th, 2018 with backward compatibility.
As of 2019, cryptocurrencies can be split between non-privacy coins (Bitcoin, Ethereum) and full privacy coins (Monero, Grin... etc.). While those technologies usually exist separately, some protocols offer an hybrid solution, notably Zcash, that requires multiple addresses, one for privacy features and one for transparent transactions.
X-Network team’s objective when creating the hybrid public/private transactions within the X-Cash system is to make both transaction types available to the user, from the same address, on a per transaction basis. The aim is to enable the user to have the same “privacy options” as in the traditional FIAT system. In the current FIAT system, the average distribution of money for an individual consists in having a portion of cash and most of their funds in a bank account. For most of the transactions, such as buying food or goods in a store, a person has two main options: pay using a credit card, check. . . etc. that will leave a transaction trail, or pay using cash which would assimilate it to an anonymous transaction.
This privacy duality found in the traditional payment system can be assimilated with the ability to choose between a public or private transaction on a decentralized payment system. Making that option accessible on the same blockchain and from the same wallet would make it more practical.
The hybrid transactions feature on the X-Cash blockchain enables the choice on a per transaction basis to display the identifying details of a transaction to make it either public, or private. On a public transaction, the following information are publicly displayed:
• Sender’s address
• Receiver’s address
• Amount sent
• Change amount sent back to the sender’s address
In X-Cash, private transactions have existed from the inception of the project; they are the default CryptoNight based payments that use stealth address and RingCT to keep the sender, receiver, inputs and amount private. This, in turn, keep the sender’s and receiver’s balance hidden. In a private transaction on the X-Cash blockchain, details about the transfer is made private to everyone except the sender and receiver.
A public transaction on the X-Cash blockchain will display additional information that needs to be recorded on the blockchain to make the transaction fully public. While the sender’s and receiver’s address are made public, neither balances are exposed. Additionally, the amounts and the change from the unspent part of the inputs going back to the sender are shown.
While the transaction details are made public, there is a significant difference with regards to traceability as the balance of the wallet remains hidden. Exposing a wallet’s balance through a blockchain transaction is one of the primary concerns of public blockchains with public transactions.
In these blockchains, another anonymity threat is the disclosure of a wallet balance to anyone knowing the wallet address. In X-Cash, it has been chosen not to replicate these two features which make the blockchain transaction system closer to the fiduciary system where balances remain anonymous from a person to another.
Since X-CASH is based on CryptoNight (CN) technology and is a privacy coin at the core, it was also chosen to keep RingCT for both public and private transactions. This allows one to send a public transaction and still keep the core features of RingCT, which is the “mixin” of the Inputs, without compromising the privacy of a private transaction.
In practice, the implementation of public transactions on the X-Cash blockchain allowed viewing public transactions on a blockchain explorer, contrary to other CN coins. Any transaction sent publicly and linked to a public key can be viewed in the explorer when providing said user public address.
The first potential issue that arose was the inclusion of public transactions in the ring signatures, with the potential to hinder one’s privacy.
When the ring size of a transaction is 2, there is a chance that one of the stealth address is a public X-Cash address. In that particular case, the mixin is completely known and privacy of the non public transaction is not attained.
This situation could arise because the ring size can be chosen on a transaction basis in classic cryptonote coins (such as Monero). To mitigate the potential impacts on privacy reduction, the transaction ring sized is increased and fixed to 21.
In that case, when assuming 50% public transactions on the network, it would mean that 10-11 out of 21 of the mixin would be known, leaving a 10% chance to find the real mixin of the transaction and consequently mitigate the privacy of the transaction.
When making a public transaction, the input associated to this transaction is made public. A case could arise where someone would want to have all of their inputs made private, and avoid having their transactions linked to an incoming public transaction.
The user would have to use a technique used in CryptoNight coins called a “churn”. In practice, this can be done by privately sending the full balance of one wallet back to itself, creating a new set of private inputs, breaking the links from any transaction the wallet has ever received.
This is materialized in CryptoNight by the sweep_all function. In the X-CASH blockchain, the function is still available as a command line and has been implemented in the GUI using the anonymize wallet feature.
The objective of this section is to dive deeper into the technical and mathematical workings of public transactions. The explanations are limited to the cryptographic components.
A brief overview of standard private transactions in cryptonote protocols is needed to better understand the underlyings of public transactions. When an X-Cash wallet is created, three main pieces of information are given [1]:
•public key
• view key
• private key
The public key is the public address of the private key. One can think of this relationship as an asymmetrical encryption, where the public key is mathematically linked to the private key. The view key allows for anyone that knows the view key of a public key to see incoming funds into the wallet. The spend key allows one to create signatures in a transaction and in turn spend X-Cash. In this example, the three pieces of information for the demonstration of the X-Cash wallet are:
public key:
XCA1h3QnoPnNU32DrqE6mcDmtZzHx6ms6fopqnaJpG16TgAFzJA2RA4NJbHTVCDeXAGd5aNmibsQd8c7 DAmSLtpX6cv7ZPi8Kr
view key:
69dc4db4542ed49e42a7c001b367ce359f5176966fb619616e0f610247e13e0e
private key:
1ff599322f839324b278319b44d87dc6c7d726c63a710b426aedd60afdad6108
When one wants to make a transaction, the private key is used to sign it. The details are hidden due to RingCT. Itself based upon ring signatures, which are a group of signatures where only one of the members is signing anonymously the message/transaction. In X-Cash, this leads to three points:
• A transaction is combined with 20 others to create this ring signature group (21 transactions per RingCT);
• The amounts are hidden due to stealth addresses (one-time-use keys that hold X-CASH). This is how balances can be hidden, because they are stored away from the actual address and into many stealth addresses instead.
• Since any of the addresses in the ring signature could be the sender, an additional public key is generated for the transaction called a key image. The key images’ purpose is to link multiple signatures from the same private key, so the system can be sure a double spending has not occurred.
Inside the structure of each transaction, there are two main fields [2]:
• prefix
• signatures
While the signatures have been briefly discussed, they remain outside of the scope of this paper, so the focus will be made on prefix.
The prefix field contains several sub-fields:
• version
• unlock_time
• input_num
• inputs
• output_num
• outputs
• extra_size
• extra
To understand public transactions, the below fields need to be detailed.
input_num, output_num Numbers of inputs and outputs in a transaction.
Inputs are basically the key images that contain the real data of the transaction, and a list of each stealth address from the ring members group to hide who actually created the transaction.
Outputs
These are the stealth addresses. Each output contains:
The amount (hidden by ringCT in a private transaction)
The target (the stealth address)
The target is composed of a one-time generated public and private key pair to which the transaction is sent to on the blockchain. This is how funds can not be linked to any given public address on the blockchain: the actual amount does not go directly to the public address. Instead, it is stored in a one-time key, which is able to be unlocked using a few pieces of data that only the recipient would know, thus allowing them to spend the funds.
Extra size The size of the extra field stored in varint encoding [3]
Extra
This is the part that makes public transactions possible. The extra field has 4 sub-fields [4]:
•Extra field size
• Tx public key
• Extra nonce
• Tx size padding
The extra nonce is the field of subject for public transactions. This field usually will store the payment ID of a transaction if applicable; however, this field allows any arbitrary amount of bytes to be stored, and there are no protocol rules or verification of what can be stored in this field [4]. The way each piece of data is separated from each other is by prefixing the data with a particular tag. In public transactions, we prefix all of the data we need to store using the 0x02 tag, which is the extra nonce tag. This tag is structured as follows
0x02 | size of data (in varint encoding) | data
Together, the public view key and public spend key are used as a public key. Said key constitute the public key to another key pair, the private view key and private spend key. Public view and spend keys can be derived from the public address. A public address in X-CASH is 98 bytes long and is a base 58 representation of data. The initial data to create a public address is:
the network byte(s) (in X-CASH it is 0x5c134)| public spend key (32 bytes) | public view key (32 bytes
This data is then run through the keccak_256 hashing algorithm, bytes from the output are appended to the initial data, and then the initial data is converted to base 58 in 8-byte blocks...
While the goal is not to fully detail the process, one can see that the initial data includes the public view key and public spend key of the public address. This means that we have to reverse the steps above on any address to get their public view key and public spend key.
One can decode their corresponding outputs in a given transaction by either using their view key, or the transaction private key. The transaction private key is not the addresses private key; it is a private key that is generated when a transaction is sent. This is why all transactions also have a transaction public key as well. The transaction private key is mainly used to prove that funds were sent to a particular address. [4] When a transaction is created, before it is relayed to the network, the transaction private key is calculated using:
G = the Ed25519 base point
r = a random scalar
H = a hashing function (keccak_256 in this case)
r = the random scalar from above
A = the receivers public view key n = the index of the output
G = the Ed25519 base point
B = the receiverś public spend key
Once all the data is generated, the stealth address can be generated from the formula. This is how the sender will be able to receive X-Cash from that stealth address since it was created using their public view and public spend key pairs.
Another stealth address is also created for the spent outputs remaining in the unspent balance so it gets sent back to the sender and is calculated using their public view and spend keys.
To decode these stealth addresses one needs to calculate:
if P= P then this stealth address is decoded (the amount is shown and it is mathematically ´ provable that the data given (view key, private transaction key etc) is the holder of that amount in that stealth address).
If any reader has noticed, the private transaction key is used in the formula to create both the senders and receivers stealth address. This is important to keep note of since this is the underlining of how it will be possible to send a public transaction.
This is the basics of how a private transaction works in the cryptonote algorithm.
The last section highlighted that a stealth address could be decoded using any of those private key pairs in that formula. The private key of the receiver can be used to decode and spend one of the outputs, but it is important to note that the view key of each person would decode each stealth address. There is one common public / private key pair that is used in the formula above, and it is used in both stealth addresses (the sender and the receiver). This is known as the transaction private and transaction public key pair.
To decode a stealth address, these three given options are only known to each party. This is how the information is kept private, because only the owners of each wallet know their private view key and private spend key.
This implied that if the private transaction key was given to a third party, they could decode the transaction for both stealth addresses in that transaction (the receivers amount as well as the sender’s change).
So adding the tx private key in the tx extra makes the tx public.
From there, several checks need to be done. A public transaction can hold 2 addresses to ensure data integrity: the receivers and the senders. Both stealth addresses in every public transaction have to be decipherable with the provided transaction private key; otherwise, the transaction will be considered an invalid public transaction (but still a valid private transaction as it is accepted on the blockchain). It is also necessary to verify that the sender is the address that actually sent that public transaction to ensure data integrity.
The first one is a limitation as of now and is why one can not have multiple receiving addresses in one public transaction. The second one is a step in the process. The third one is calculated by performing an additional step before the transaction gets relayed.
To verify after the public transaction is relayed to the network that one XCA address is the sender, and thus the other one has to be the receiver, it is needed to link the private transaction key (since the sender can only know this) and the senderś public address. This is accomplished by using the private key of the sender, to sign a message that contains the transaction private key. This makes it possible to verify that the public address, which actually sent the transaction, is the correct sender once the transaction has been relayed in the network.
To summarize, the following data needs to be added in the tx extra field:
• The transaction private key.
• The signature from the signed message of the transaction private key from the sender private key.
• Public address 1.
• Public address 2.
To verify the public transaction after the transaction has been sent, the following process needs to be executed:
• Verify that there are only 2 output addresses.
• Check the validity of the tx extra’s data structure
• Check that the transaction private key can decode both outputs in the transaction.
Check to see which address is the sender by verifying the message against the two addresses in the transaction.
This concludes how public addresses are created, and shows that they do not interfere in any way with X-Cash’s privacy. Public transactions also still give the sender the same level of privacy since his private signature is still mixed with 20 other members’ in the ring signature, thus giving his inputs the same level of privacy as for a private transaction.
The major comparative advantage of hybrid transactions relies on their ability to be performed on the same wallet and using the same public address which simplifies their use and integration.
From a user perspective, hybrid transactions are easy to use and have been implemented in the various tools of the X-Cash products: GUI CLI wallets, mining pool, explorer. . . etc.
Public transactions are an essential component of the X-Network ecosystem and allow users to choose and adjust their level of anonymity when performing X-Cash transactions. Coupled with the sidechain solution, hybrid transactions will fulfill their potential and enable unique use cases.
[1] M. J. T. N. N. A. M. J. Seigen. CRYPTONOTE STANDARD 007 : CryptoNote Keys and Addresses. https://cryptonote.org/cns/cns007.txt
[2] M. J. T. N. N. A. M. J. Seigen. CRYPTONOTE STANDARD 004 : CryptoNote Transactions. https://cryptonote.org/cns/cns004.txt
[3] M. J. T. N. N. A. M. J. Seigen. CRYPTONOTE STANDARD 003 : CryptoNote Blockchain. https://cryptonote.org/cns/cns003.txt
[4] M. J. T. N. N. A. M. J. Seigen. CRYPTONOTE STANDARD 005 : CryptoNote Transaction Extra Field. https://cryptonote.org/cns/cns005.txt
The X-Cash Turbo TX allows users to send Layer 1 zero confirmation transactions from any wallet. Tx can be verified a few seconds after sending using our dedicated website or by running their own local version of the tool. This does not replace instant payments as that will be a true instant send on the layer 2, but adds additional functionallity to our layer 1, that is unique to coins that have a unspent tx system, plus a DBFT block consensus algorithm.
I want to learn more about turbo tx
I want to send a turbo tx
I want to receive and verify a turbo tx
Characteristics
Send Layer 1 instant tx.
Send from any wallet, CLI, RPC, GUI, mobile
Useful for merchants
Easy to use tool to verify
Powered by the DPOPS Layer 2
****GitHub - Source code of the DPoPS and namespace program.
Please review the
Please review the documentation
Please review the documentation
This guide hasn't been updated since May 2020. It is highly recommended to install the xcash-dpops program with the installer script provided here.
This guide is designed for people knowledgeable in Linux and who want to install everything from scratch. If you are not comfortable with the Linux distribution, or if you are following these steps without understanding what you are doing, you might make a mistake that will prevent the xcash-dpops program to run as intended.
It is recommended to install the program the different programs needed for the xcash-dpops in the same folder, in the the /root/ directory or the /home/$USER/ if you are installing from a user different than root.
In the ~ directory, create the xcash-official directory and the xcash-wallets , systemdpid , and logs directory within. Additionally, create the .X-CASH directory that will store the X-Cash blockchain file.
First, update your system packages and install the necessary dependencies:
If you want to install xcash-core from source, you will need to install these additional packages.
You will need to get the latest stable version (current release) on the MongoDB website: https://www.mongodb.com/download-center/community
Version: Latest current release. OS: Ubuntu 18.04 Linux x64 (if you are using this version). Package: Server
Then click on All version binaries.
Copy the link address of the tgz file of the latest version available (disregarding debug symbols version) and use it to download the installation folder using this command (replacing the link with the most recent version).
Then, extract it and remove the downloaded file:
Lastly, add the MongoDB binaries folder to your path with the following command.
Replace $USER/xcash-official/mongodb-linux-x86_64-ubuntu1804-4.4.0-rc7-36-gcf4ac31/bin with the MongoDB binaries folder in your system.
Additionally, create the /data/db folder that will keep the delegates databases:
First, download the latest stable version of the MongoDB C Driver. Go to the official GitHub repository and download the latest stable release. Get the tarball file in your installation folder:
Now, build the driver using the following commands (based on these instructions):
Then, update the links and cache of the newly installed library:
xcash-core from sourceClone the xcash-core repository to your installation folder and go to the downloaded folder:
Make sure to have all the dependencies installed, and build the binaries using make:
Once the build finishes, the binaries will be located in ~/xcash-official/xcash-core/build/release/bin
At this point, all the dependencies should be installed and built. First, clone the xcash-dpops repository:
Go into the downloaded folder, and build using make:
Once the build is completed, you will get the xcash-dpops Has Been Built Successfully message. Now that the program is built, you will need to generate a wallet to be used for the delegate and set up the different units for systemd to organize how your server manages the different services.
You will need to create a wallet to register as a delegate, to receive the block reward if you are elected as a top delegate and if you are a shared delegate, the payments will be sent from this wallet as well.
To generate a new wallet, use the following command:
Replace <WALLET_NAME>, <PASSWORD> and the <REMOTE_NODE> with the parameters of your choice.
The wallet synchronization can take time the first time. It will depend on which remote node you chose, and your servers internet connection.
Make sure that you write down your mnemonic key and store it in a secure place as it will be the only way to restore your wallet in case of a problem. Failing to do so will result in loss of funds.
The wallet files will be located in ~/xcash-official/xcash-wallets/
In systemd, a unit refers to any resource that the system knows how to operate on and manage. This is the primary object that the systemd tools know how to deal with. These resources are defined using configuration files called unit files.
On this guide, we will set up the different unit files to manage the programs needed to run your delegate node. The unit files template are present in the xcash-dpops/scripts/systemd folder, but will need to be adjusted with your delegate information.
Create two empty PID files in the systemdpid folder previously created, that will manage the corresponding services:
Edit the systemd unit file mongodb.service from in the xcash-dpops/scripts/systemdfolder :
You will get the following unitfile:
In the file, replace the following if needed:
User: User of the system (most likely root)
PIDFile: The path to mongod.pid file that you created at the initialization step.
ExecStart:
Replace the path to the mongod file.
Replace the path to the database directory (/data/db as per the instructions)
Edit the systemd unit file xcash-daemon.service from in the xcash-dpops/scripts/systemdfolder :
You will get the following unitfile:
In the file, replace the following if needed:
User: User of the system (most likely root)
PIDFile: The path to xcash-daemon.pid file that you created at the initialization step.
ExecStart:
Replace the path to the xcashd file.
Replace the path to the xcash-daemon_Log.txt file.
Replace the path to the xcash-daemon.pid file.
Edit the systemd unit file xcash-rpc-wallet.service from in the xcash-dpops/scripts/systemdfolder :
You will get the following unit file:
In the file, replace the following if needed:
User: User of the system (most likely root)
ExecStart:
Replace the path to the xcash-wallet-rpc file.
Replace the path to the xcash-wallets folder, and replace WALLET by your delegate wallet name.
Replace PASSWORD with your delegate wallet password.
Edit the systemd unit file firewall.service from in the xcash-dpops/scripts/systemdfolder :
You will get the following unit file:
In the file, replace the following if needed:
User: User of the system (most likely root)
ExecStart: Replace the path to the firewall/firewall_script.sh file.
Edit the systemd unit file xcash-dpops.service from in the xcash-dpops/scripts/systemdfolder :
You will get the following unit file:
In the file, replace the following if needed:
User: User of the system (most likely root)
WorkingDirectory: Replace the path of the xcash-dpops/build folder.
ExecStart:
Replace the path to the xcash-dpops file.
Replace BLOCK_VERIFIER_SECRET_KEY with your generated verifier secret key. This should be the first parameter.
The instructions to generate the block verifier secret key is given in the generate block verifier key guide. Make sure to update the file with your Block Verifier Secret Key and restart the service.
Now that you have prepared all the unit systemd files, you will need to copy all of them to the system folder:
Then, reload systemd to take the changes into account and run the services.
The block verifier key is a unique identifier generated by a delegate and is used in the consensus process to sign messages and verify the information. As a delegate, you will need to generate a block verifier key before being able to register yourself in the system.
First of all, stop the currently running process of the xcash-dpops program.
Then, run the xcash-dpops program with the --generate-key option. The program is located in the xcash-dpops/build folder. Run the command:
You will be given a block verifier public key and block verifier private key.
Securely save the key you will be using! Once you have registered as a delegate with this key pair, you will be identified in the system with this. If you lose it, you will lose your delegate stats and will have to start over.
First of all, stop the currently running process of the xcash-dpops program.
Then, add your block verifier secret key as a parameter in the service. See the setup of the services guide to see how to edit the unit file.
Once done, make sure to save the new changes to systemctl by using the following command:
It is recommended to run the xcash-dpops test before you run the main program. The test will ensure that your system is compatible and that you have set up your system correctly.
To run the X-CASH DPOPS test, make sure to have already started the xcash-daemon, xcash-rpc-wallet and mongodb systemd services, and to have stopped the xcash-dpops systemd service if it was already running.
Navigate to the folder that contains the binary, rebuild the binary in debug mode then run the test
The test will return the number of passed and failed tests at the bottom of the console. The failed test need to be 0 before you run the node. If the output is not showing 0 for a failed test, then you need to scroll through the testing output and find what test failed (It will be red instead of green).
If this is a system compatibility test, then you will need to fix the system. If this is a core test that has failed, then you need to possibly rebuild, or contact us on the DPoPS testing section or go the Discord channel to get help from testers and the dev-team.
If you plan on being a delegate but need to accept people vote to help you place in the top delegates spot and earn the right to forge blocks, you will need to run a shared delegate. The shared delegates website will automatically pay your voters taking into account their share.
We recommend changing from a solo delegate to a shared delegate with the auto-installer script as described above. The manual process described below can be prone to error in the setup.
To run your node as a shared delegate, you just need to run the xcash-dpops program with the following added set of parameters:
With :
<fee> : Your delegate fee is the amount of the block reward you are keeping to yourself. The <fee> is expressed in percentage (%) and can take up to 6 decimals.
<amount> : The minimum amount of XCASH that can be sent to voters as part of their payment. Has to be an integer number.
Example
Will register as a shared delegate, taking a fee of 12.092032% from the block reward, and process payments to voters when they have accumulated to 10,000 XCASH.
xcash-dpops programTo make sure that your node is running with the parameters, you should update the unit files and restart the service.
First, make sure to stop the running xcash-dpops service:
Then, edit the unit file:
And add the parameters to the ExecStart variable:
Make sure that the following parameter is in first place:
Make sure to update your public information when you change fees, and change shared_delegate_status to true if you are running a shared delegate node to let people know that they can vote for you.
The shared delegate website has been automatically installed if you installed it with the auto-installer script.
As a shared delegate, you will need to pay your voters a share of the block reward. We have designed a delegate pool website, which works similarly to a regular PoW pool website, where your voters can see their pending payments, your forging statistics and so on...
First, install the website dependencies:
NodeJS
Install nodeJS latest available version:
And update to the latest version using this tutorial.
First, if you are installing from root user, you need to give the current permissions:
Install npm globally:
Angular & Uglify JS
Install Angular and UglifyJS globally:
Build
Once all dependencies are installed, clone the delegate pool website repository :
Go into the folder, install the dependencies, and build the website:
It will build in the distfolder.
Compress the .js files with Uglify-JS and move all of the contents of this folder to your xcash-dpops/ folder:
And you are done 🎉 Verify that you are listed in the delegate explorer, and start advertising your node to get people joining your cause and vote for you!
