# Haven Protocol The official source of Haven documentation Welcome to Haven's Wiki documentation. To get started select one of the shortcuts below. {% content-ref url="/pages/-MIUlj1rFvEXa-1lvTg\_" %} [GUI](/gui/gui-overview) {% endcontent-ref %} {% content-ref url="/pages/-MIUll6wuVbU-v4hvd4h" %} [CLI](/cli/cli-overview) {% endcontent-ref %} {% content-ref url="/pages/-MIUmMaMJHsoxEj1Gv3v" %} [RPC](/rpc/rpc-overview) {% endcontent-ref %} {% content-ref url="/pages/-MI\_3bA6dCzHfVK\_C6d0" %} [FAQ](/faq/project-timeline) {% endcontent-ref %} {% content-ref url="/pages/-MIeoNknX2XX6WCg3rH1" %} [Broken mention](broken://pages/-MIeoNknX2XX6WCg3rH1) {% endcontent-ref %} # Overview * Overview * [Restore Account](/gui/gui-overview/gui-restore) * [Create Account](/gui/gui-overview/gui-create) * [Login](/gui/gui-overview/gui-login) * [Transfer](/gui/gui-overview/gui-transfer) * [Receive](/gui/gui-overview/gui-receive) * [Offshore Exchange](/gui/gui-overview/gui-offshore-exchange) * [Onshore Exchange](/gui/gui-overview/gui-onshore-exchange) * [Nodes](/gui/gui-overview/gui-nodes) * [Settings](/gui/gui-overview/gui-settings) * [Troubleshooting](/gui/gui-overview/gui-troubleshooting) # Restore Account # Create Account # Login # Transfer ### Transfer Basic stuff goes here ### Transfer Advanced stuff goes here # Receive # Offshore Exchange ### Exchange Basic ### Exchange Advanced # Onshore Exchange ### Onshore Basic ### Onshore Advanced # Nodes ### Remote Nodes ### Local Nodes # Settings # Troubleshooting # Signature #### The Basics A cryptographic method for proving ownership of a piece of information, as well as proving that the information has not been modified after being signed. # Smart Mining #### The Basics Smart mining is the process of having a throttled @miner mine when it otherwise does not cause drawbacks. Drawbacks include increases heat, slower machine, depleting battery, etc. The intent of smart mining is to increase network security by allowing as many people as possible to let the smart miner on all the time. For this to work, the miner must prove unobtrusive, or it will be turned off, depriving the Haven network from a little bit of security. As such, it is likely that a smart miner will mine slower than a normal miner on the same hardware. Smart mining is available in the official CLI and GUI wallet, which are available in the [downloads page](https://app.gitbook.com/s/-MIUkN4w3pz_N3EraYsq/gui/gui-overview/%7B%7B%20site.baseurl_root%20%7D%7D/downloads/). It is hoped that the relative slowness of a smart miner (especially on low-power machines) will be offset by the large amount of people running a miner for a possible "lottery win", and thus increase the Haven network security by a non trivial amount. The increased hash rate from many different sources helps keep the Haven network decentralized. # Overview ### Heads up! All CLI tutorials assume you have a terminal application already running on your computer an are technically proficient and know enough standard terminal commands such as how to create and change directories. * Overview * [Restore Account](/cli/cli-overview/cli-restore) * [Create Account](/cli/cli-overview/cli-create) * [Login](/cli/cli-overview/cli-login) * [Transfer](/cli/cli-overview/cli-transfer) * [Receive](/cli/cli-overview/cli-receive) * [Offshore Exchange](/cli/cli-overview/cli-offshore-exchange) * [Onshore Exchange](/cli/cli-overview/cli-onshore-exchange) * [Nodes](/cli/cli-overview/cli-nodes) * [Settings](/cli/cli-overview/cli-settings) * [Troubleshooting](/cli/cli-overview/cli-troubleshooting) # Installation ### Vault Directory Create a directory or folder on your computer in the location where you want to store your CLI Vault. ### Download Vault Download your CLI Vault [https://havenprotocol.org/products](https://havenprotocol.org/products/) for your desired operating system. Save, or move, it to the **Vault Directory** that you created above. ### **Verify SHA's** To verify the authenticity of the vault you just downloaded, you'll want to check the SHA Hashes. You can do this in two steps. * Type or copy `openssl dgst -sha256` into your terminal * Copy the path of the unzipped file 1. Mac: Select the file in Finder and click `⌘ c` 2. Windows: 3. Linux * Paste the path into the Terminal after the `openssl dgst -sha256` * The full command should now * `openssl dgst -sha256 /your-vault-path-file` * Click enter and the output of the unzipped file should match the SHA's shown at the download location. If they do not match, then do not open the file, and contact us in the Discord channel in the #support channel. ### Example ``` openssl dgst -sha256 ./haven-offshore-macos-1.1.2a.zip SHA256(./haven-offshore-macos-1.1.2a.zip) = 09d0786196ed14717d1df1c33d359782bc50f03aea01ffd5cdbec800f4133c61 ``` ### Antivirus Before you open the zip file you will first need to create an exception in your Antivirus (AV) software. Search for "**How to create an exception with ... "** where the `...` is the name of your AV software. Follow the steps and then return to this tutorial. With the AV Software exception created and the SHA's verified, you are now safe to open the CLI Vault. Sometimes the AV will still warn you by indicating that you have a [PUP - Potentially Unwanted Program or a PUA - Potentially Unwanted Application](https://en.wikipedia.org/wiki/Potentially_unwanted_program). This is **normal** and triggered by the mining software in the Haven Vault and is present in both Haven and Monero software. With the initial installing completed you can now [Create](/cli/cli-overview/cli-create) or [Restore](/cli/cli-overview/cli-restore) an Account. # Create Account # Restore Account # Login # Transfer # Receive # Offshore Exchange # Onshore Exchange # Nodes # Troubleshooting # Settings # Overview ### Index of JSON RPC Methods: * [transfer](/rpc/rpc-overview/rpc-transfer) * [transfer\_split](/rpc/rpc-overview/rpc-transfer-split) * [offshore](/rpc/rpc-overview/rpc-offshore) * [onshore](/rpc/rpc-overview/rpc-onshore) * [offshore\_transfer](/rpc/rpc-overview/rpc-offshore-transfer) * [offshore\_sweep\_all](/rpc/rpc-overview/rpc-offshore-sweep-all) * [get\_transfers](/rpc/rpc-overview/rpc-get-transfers) # Transfer ## Transfer Send XHV to a number of recipients. Alias: *None*. ### Inputs: * `destinations` - array of destinations to receive XHV: * *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 haven can be spent (0 to not add a lock). * `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 haven 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. * `amount_usd` - 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 ``` $ curl http://127.0.0.1:17751/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"transfer","params":{"destinations":[{"amount":100000000000,"address":"hvxy5mxT87WWDCfsAYYEtq9K8KNbPTRaEd2nKgLgPN3qP5PpH1AaJ6TaYYec9L2hKZGpuxQ4uZ4tkFFLxjaLHVAY7QZoBmW3g2"},{"amount":200000000000,"address":"hvxy5mxT87WWDCfsAYYEtq9K8KNbPTRaEd2nKgLgPN3qP5PpH1AaJ6TaYYec9L2hKZGpuxQ4uZ4tkFFLxjaLHVAY7QZoBmW3g2"}],"account_index":0,"subaddr_indices":[0],"priority":0,"ring_size":7,"get_tx_key": true}}' -H 'Content-Type: application/json' { "id": "0", "jsonrpc": "2.0", "result": { "amount": 300000000000, "fee": 86897600000, "multisig_txset": "", "tx_blob": "", "tx_hash": "7663438de4f72b25a0e395b770ea9ecf7108cd2f0c4b75be0b14a103d3362be9", "tx_key": "25c9d8ec20045c80c93d665c9d3684aab7335f8b2cd02e1ba2638485afd1c70e236c4bdd7a2f1cb511dbf466f13421bdf8df988b7b969c448ca6239d7251490e4bf1bbf9f6ffacffdcdc93b9d1648ec499eada4d6b4e02ce92d4a1c0452e5d009fbbbf15b549df8856205a4c7bda6338d82c823f911acd00cb75850b198c5803", "tx_metadata": "", "unsigned_txset": "" } ``` # Transfer Split ### **transfer\_split** Same as transfer, but can split into more than one tx if necessary. Alias: *None*. ### Inputs: * `destinations` - array of destinations to receive XHV: * *\`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 haven can be spent (0 to not add a lock). * `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 haven 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. * `amount_usd_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** ``` $ curl http://127.0.0.1:17751/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"transfer_split","params":{"destinations":[{"amount":1000000000000,"address":"hvxy5mxT87WWDCfsAYYEtq9K8KNbPTRaEd2nKgLgPN3qP5PpH1AaJ6TaYYec9L2hKZGpuxQ4uZ4tkFFLxjaLHVAY7QZoBmW3g2"},{"amount":2000000000000,"address":"hvxy5mxT87WWDCfsAYYEtq9K8KNbPTRaEd2nKgLgPN3qP5PpH1AaJ6TaYYec9L2hKZGpuxQ4uZ4tkFFLxjaLHVAY7QZoBmW3g2"}],"account_index":0,"subaddr_indices":[0],"priority":0,"ring_size":7,"get_tx_keys": true}}' -H 'Content-Type: application/json' { "id": "0", "jsonrpc": "2.0", "result": { "amount_list": [3000000000000], "fee_list": [473710000], "multisig_txset": "", "tx_hash_list": ["4adcdc1af3f665770cdf8fb7a380887cd07ac53c2b771bd18df5ca375d5e7540"], "tx_key_list": ["5b455c0f97168be652a2c03c5c68a064bb84cdae4ddef01b5c48d73a0bbb27075fb714f2ca19ea6c8ff592417e606addea6deb1d6530e2969f75681ffcbfc4075677b94a8c9197963ae38fa6f543ee68f0a4c4bbda4c453f39538f00b28e980ea08509730b51c004960101ba2f3adbc34cbbdff0d5af9dba061b523090debd06"], "unsigned_txset": "" } } ``` # Offshore ### **offshore** Same as `transfer_split`, but sends xUSD by burning XHV. Alias: *None*. ### Inputs: * `destinations` - array of destinations to receive xUSD: * `amount` - unsigned int; Amount in XHV 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 haven can be spent (0 to not add a lock). * `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 haven 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. * `amount_usd_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: ``` $ curl http://127.0.0.1:17751/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"offshore","params":{"destinations":[{"amount":1000000000000,"address":"hvxy5mxT87WWDCfsAYYEtq9K8KNbPTRaEd2nKgLgPN3qP5PpH1AaJ6TaYYec9L2hKZGpuxQ4uZ4tkFFLxjaLHVAY7QZoBmW3g2"},{"amount":2000000000000,"address":"hvxy5mxT87WWDCfsAYYEtq9K8KNbPTRaEd2nKgLgPN3qP5PpH1AaJ6TaYYec9L2hKZGpuxQ4uZ4tkFFLxjaLHVAY7QZoBmW3g2"}],"account_index":0,"subaddr_indices":[0],"priority":0,"ring_size":7,"get_tx_keys": true}}' -H 'Content-Type: application/json' { "id": "0", "jsonrpc": "2.0", "result": { "amount_list": [3000000000000], "amount_usd_list": [3000000000000], "fee_list": [473710000], "multisig_txset": "", "tx_hash_list": ["4adcdc1af3f665770cdf8fb7a380887cd07ac53c2b771bd18df5ca375d5e7540"], "tx_key_list": ["5b455c0f97168be652a2c03c5c68a064bb84cdae4ddef01b5c48d73a0bbb27075fb714f2ca19ea6c8ff592417e606addea6deb1d6530e2969f75681ffcbfc4075677b94a8c9197963ae38fa6f543ee68f0a4c4bbda4c453f39538f00b28e980ea08509730b51c004960101ba2f3adbc34cbbdff0d5af9dba061b523090debd06"], "unsigned_txset": "" } } ``` # Onshore ### **onshore** Same as transfer\_split, but sends XHV by burning xUSD. Alias: *None*. ### Inputs: * *`destinations`* - array of destinations to receive XHV: * *`amount`* - unsigned int; Amount in XHV 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 haven can be spent (0 to not add a lock). * `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 haven 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 in XHV for every transaction. * `amount_usd_list` - array of: integer. The amount transferred in xUSD 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: ``` $ curl http://127.0.0.1:17751/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"onshore","params":{"destinations":[{"amount":1000000000000,"address":"hvxy5mxT87WWDCfsAYYEtq9K8KNbPTRaEd2nKgLgPN3qP5PpH1AaJ6TaYYec9L2hKZGpuxQ4uZ4tkFFLxjaLHVAY7QZoBmW3g2"},{"amount":2000000000000,"address":"hvxy5mxT87WWDCfsAYYEtq9K8KNbPTRaEd2nKgLgPN3qP5PpH1AaJ6TaYYec9L2hKZGpuxQ4uZ4tkFFLxjaLHVAY7QZoBmW3g2"}],"account_index":0,"subaddr_indices":[0],"priority":0,"ring_size":7,"get_tx_keys": true}}' -H 'Content-Type: application/json' { "id": "0", "jsonrpc": "2.0", "result": { "amount_list": [3000000000000], "amount_usd_list": [3000000000000], "fee_list": [473710000], "multisig_txset": "", "tx_hash_list": ["4adcdc1af3f665770cdf8fb7a380887cd07ac53c2b771bd18df5ca375d5e7540"], "tx_key_list": ["5b455c0f97168be652a2c03c5c68a064bb84cdae4ddef01b5c48d73a0bbb27075fb714f2ca19ea6c8ff592417e606addea6deb1d6530e2969f75681ffcbfc4075677b94a8c9197963ae38fa6f543ee68f0a4c4bbda4c453f39538f00b28e980ea08509730b51c004960101ba2f3adbc34cbbdff0d5af9dba061b523090debd06"], "unsigned_txset": "" } } ``` # Offshore Transfer ### **offshore\_transfer** Same as transfer\_split, but sends xUSD between wallets. Alias: *None*. ### Inputs: * `destinations` - array of destinations to receive xUSD: * *amount* - unsigned int; Amount in xUSD 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 haven can be spent (0 to not add a lock). * `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 haven 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. * `amount_usd_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: ``` $ curl http://127.0.0.1:17751/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"offshore","params":{"destinations":[{"amount":1000000000000,"address":"hvxy5mxT87WWDCfsAYYEtq9K8KNbPTRaEd2nKgLgPN3qP5PpH1AaJ6TaYYec9L2hKZGpuxQ4uZ4tkFFLxjaLHVAY7QZoBmW3g2"},{"amount":2000000000000,"address":"hvxy5mxT87WWDCfsAYYEtq9K8KNbPTRaEd2nKgLgPN3qP5PpH1AaJ6TaYYec9L2hKZGpuxQ4uZ4tkFFLxjaLHVAY7QZoBmW3g2"}],"account_index":0,"subaddr_indices":[0],"priority":0,"ring_size":7,"get_tx_keys": true}}' -H 'Content-Type: application/json' { "id": "0", "jsonrpc": "2.0", "result": { "amount_list": [3000000000000], "amount_usd_list": [3000000000000], "fee_list": [473710000], "multisig_txset": "", "tx_hash_list": ["4adcdc1af3f665770cdf8fb7a380887cd07ac53c2b771bd18df5ca375d5e7540"], "tx_key_list": ["5b455c0f97168be652a2c03c5c68a064bb84cdae4ddef01b5c48d73a0bbb27075fb714f2ca19ea6c8ff592417e606addea6deb1d6530e2969f75681ffcbfc4075677b94a8c9197963ae38fa6f543ee68f0a4c4bbda4c453f39538f00b28e980ea08509730b51c004960101ba2f3adbc34cbbdff0d5af9dba061b523090debd06"], "unsigned_txset": "" } } ``` # Offshore Sweep All ### **offshore\_sweep\_all** Send all unlocked xUSD 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 haven can be spent (0 to not add a lock). * `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. * `amount_usd_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: ``` $ curl http://localhost:17751/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"offshore_sweep_all","params":{"address":"hvxy5mxT87WWDCfsAYYEtq9K8KNbPTRaEd2nKgLgPN3qP5PpH1AaJ6TaYYec9L2hKZGpuxQ4uZ4tkFFLxjaLHVAY7QZoBmW3g2","subaddr_indices":[4],"ring_size":7,"unlock_time":0,"get_tx_keys":true}}' -H 'Content-Type: application/json' { "id": "0", "jsonrpc": "2.0", "result": { "amount_list": [9985885770000], "fee_list": [14114230000], "multisig_txset": "", "tx_hash_list": ["ab4b6b65cc8cd8c9dd317d0b90d97582d68d0aa1637b0065b05b61f9a66ea5c5"], "tx_key_list": ["b9b4b39d3bb3062ddb85ec0266d4df39058f4c86077d99309f218ce4d76af607"], "unsigned_txset": "" } } ``` # Get Offshore Balance ### **get\_offshore\_balance** Return the wallet's balance in xUSD. Alias: *None*. ### Inputs: * `account_index` - unsigned int; Return xUSD balance for this account. * `address_indices` - array of unsigned int; (Optional) Return balance detail for those subaddresses. ### Outputs: * `balance` - unsigned int; The total balance in xUSD of the current haven-wallet-rpc in session. * `unlocked_balance` - unsigned int; Unlocked funds are those funds that are sufficiently deep enough in the Haven 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: ``` $ curl http://127.0.0.1:17751/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_ofshore_balance","params":{"account_index":0,"address_indices":[0,1]}}' -H 'Content-Type: application/json' { "id": "0", "jsonrpc": "2.0", "result": { "balance": 157443303037455077, "multisig_import_needed": false, "per_subaddress": [{ "address": "55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt", "address_index": 0, "balance": 157360317826255077, "label": "Primary account", "num_unspent_outputs": 5281, "unlocked_balance": 157360317826255077 },{ "address": "7BnERTpvL5MbCLtj5n9No7J5oE5hHiB3tVCK5cjSvCsYWD2WRJLFuWeKTLiXo5QJqt2ZwUaLy2Vh1Ad51K7FNgqcHgjW85o", "address_index": 1, "balance": 59985211200000, "label": "", "num_unspent_outputs": 1, "unlocked_balance": 59985211200000 }], "unlocked_balance": 157443303037455077 } } ``` # Get Transfers Returns a list of transfers. ### **get\_transfers** Returns a list of transfers. Alias: *None*. ### Inputs: * `in` - boolean; (defaults to false) Include incoming transfers. * `out` - boolean; (defaults to false) Include outgoing transfers. * `pending` - boolean; (defaults to false) Include pending transfers. * `failed` - boolean; (defaults to false) Include failed transfers. * `pool` - boolean; (defaults to false) 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; (Optional) 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: (one of "block", "in", "XUSD in", "out" and "XUSD out" * `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: ``` $ curl http://127.0.0.1:17751/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_transfers","params":{"in":true,"account_index":1}}' -H 'Content-Type: application/json' { "id": "0", "jsonrpc": "2.0", "result": { "in": [{ "address": "hvxy5mxT87WWDCfsAYYEtq9K8KNbPTRaEd2nKgLgPN3qP5PpH1AaJ6TaYYec9L2hKZGpuxQ4uZ4tkFFLxjaLHVAY7QZoBmW3g2", "amount": 200000000000, "confirmations": 1, "double_spend_seen": false, "fee": 21650200000, "height": 153624, "note": "", "payment_id": "0000000000000000", "subaddr_index": { "major": 1, "minor": 0 }, "suggested_confirmations_threshold": 1, "timestamp": 1535918400, "txid": "c36258a276018c3a4bc1f195a7fb530f50cd63a4fa765fb7c6f7f49fc051762a", "type": "in", "unlock_time": 0 }] } } ``` # Project Timeline This is an overview of the major project milestones since it began in early 2017. Jan 2017- Haven concept launched Jan 2018- Having failed to deliver a secure working product, a group of Haven community members took over the project with the aim of delivering the world's first private stablecoin. April 2018- Listed on TradeOgre and Bittrex exchanges May 2019- First testnet of Haven on Monero rebase (v0.14) June 2019- Mainnet fork rebase onto Monero update to include Bulletproofs and other upgrades Sept 2019- New web vault launched on testnet Oct 2019- First Offshore testnet launched and new web wallet launched on mainnet Nov 2019- Listed on Abra Dec 2019- Listed on Citex and VCC exchanges Jan 2020- xUSD launched on private testnet Feb 2020- Integrate Chainlink oracle feed for XHV vault exchange pricing March 2020- xUSD launched on public testnet including testing of new daemon and visible xUSD and XHV supply April 2020- New desktop vault on testnet May 2020- Final offshore code testing complete June 2020- Open source offshore codebase July 2020- xUSD launched onto mainnet and launch new desktop vault onto mainnet Sept 2020- Launch plan for Haven Foundation Oct 2020- Listed on BKEX exchange / Integrate Band Protocol oracle into price feed # The Protocol Here you can find answers to many of the commonly asked questions in relation the Haven network. # What is Haven? ## What is Haven Protocol? Haven is an open source, community-led ecosystem of private digital assets. It is a way for anyone to anonymously store their wealth without the need for any banks or third party intermediaries. It allows anyone, anywhere to hold their money in a range of different asset classes to suit their needs. Virtually any asset can be added to the network including precious metals, commodities and stocks allowing diversification in complete privacy. It is a Proof-of-Work cryptocurrency network based on the cryptonote protocol. It was originally started as a fork of Monero, one of the most highly regarded privacy focused coins in the space. # What can Haven be used for? This is just a brief overview of the many use cases that Haven could have in the future. **Storage-** Anyone who wants to store value outside of the traditional banking system without giving up their privacy and autonomy. Only you can access and use your wealth as you see fit. **Asset Conversion-** With the first asset, xUSD, live on mainnet we will be expanding the network by introducing a suite of private digital assets (xAssets) to cover major fiat currencies and high profile commodities such as xEUR, xCNY, xGOLD and xSILV. Anyone using the network can convert between all supported assets within their own digital vault. No counter-party, no 3rd party permission required, no limit on liquidity. **Payments-** Haven can be used for anything that does not require instant settlement and where privacy is desired. E-commerce plug-ins for Haven offer a simple solution for any business to easily integrate Haven payments into their store # How does it work? Haven uses what is known as a 'mint & burn' process to convert between all supported assets on the network. Once a person owns XHV (the volatile Haven base currency) that can then be used as network collateral to convert to any other supported xAsset. When a user converts from XHV to xUSD, they mint xUSD and burn the equivalent USD worth of XHV. This can be simply explained by the example below: Anne owns 200 XHV with a market value of $2. She decides to convert all of her XHV to xUSD so (200 x $2 = $400) therefore she receives 400 xUSD (minus fees). This process is carried out in her own private digital vault with no 3rd party intermediaries, or the need to use a centralised exchange. The assets on the network are known as **xAssets.** # Transactions # What are the transaction fees? ## # How do the transactions work? Haven has a unique way of processing transactions that take a little thought but are very simple once you understand the way they work. Each input in a user's balance can be thought of as a banknote. An example of this would be: Anne receives 20 XHV to her Haven vault. This then becomes a 20 XHV 'note'. She wants to send 10 XHV to Bob so in effect sends the 20 XHV note and receives 10 XHV in change once the transaction is complete. It's worth noting that if you have 1000 XHV in your vault and you received this balance as 10x 100 XHV then you have 10 inputs or 'notes in your vault. If you want to send 150 XHV then you have to send 2 x 100 XHV and wait for the change of 50 XHV once the transaction is complete. This applies to any transaction whether you are transferring any Haven xAsset or whether you are converting between xAssets (say xUSD to xGold). # Haven Assets # Can I see the supply of xAssets? Although the privacy features of Haven allow for anonymous accounts, balances and transactions, it was decided early on in the development phase that it would be beneficial to have transparent XHV and xAsset supplies. The live circulating supply of all assets can be viewed [here](https://network.havenprotocol.org/). The decision to make them visible was for several reasons including: * It allows for more efficient monitoring of the Haven network, which means attempted attacks and large scale manipulation can be detected and mitigated much faster. * It gives users greater confidence to enter the Haven network with the ability to view the number of XHV and xAssets in circulation at any given moment. * It allows for greater visibility and therefore greater analysis on coin metrics websites. As a result, to ensure accuracy and visibility, each mint and burn transaction will be created in such a way that amounts will be discoverable through analysis of the blockchain, and displayed in the Haven block explorers. This will allow users to maintain standard Monero levels of anonymity and wallet address privacy while allowing a clear view of circulating supply. # What is the supply of XHV and xAssets? Because of the unique 'mint & burn' process with Haven the supply of XHV and all other xAssets will fluctuate according to demand. If $1Million xUSD gets minted then the same USD value of XHV has to be burnt in order to create that xUSD. At the time of launch of the first xAsset (xUSD) there was approximately 13 million XHV. As Haven is PoW there are a certain number of new XHV being created as mining rewards with a maximum of 18.4 Million plus tail emission. Haven follows the same emission schedule as Monero. # How many xAssets will there be? Haven has recently launched the first 'coloured coin' implementation on a [cryptonote](https://cryptonote.org/) coin. This means that there is essentially no limit to the number of xAssets that could be added to the network. As long as an oracle can provide a reliable price feed into the network then it could be included. The first xAsset launched in July 2020 was xUSD. The 2nd planned phase of asset integration will be xGold, xSilv, xCNY, and xEUR giving users the opportunity to gain digital exposure to the primary precious metals (Gold and Silver) as well as two of the most widely used fiat currencies (Chinese Yuan and Euro). You can find a more technical explanation of how the coloured coin implementation works in the [***Haven Protocol Whitepaper***](https://havenprotocol.org/whitepaper/)***.*** # Whats an Oracle? In order for the Haven network to retrieve accurate and reliable price feed for XHV and all xAssets it requires an oracle. The oracle connects to a range of different price sources and feeds this to the network. Haven intends to use multiple oracles to further decentralise the network and reduce the likelihood of price manipulation. Having launched the first asset \[xUSD] with Chainlink providing the price feeds for XHV we will actively look for other suitable oracle services that meet the needs of the project. The live price feed from Chainlink can be found [***here***](https://feeds.chain.link/xhv-usd) # Is Haven private? Yes, because Haven is based on the Monero codebase it inherits all of its privacy features. Monero was chosen as it is widely considered to be the leading privacy focused cryptocurrency in the space and has a very active group of developers working on continuous improvement of the protocol. **• Ring Signatures-** are used to hide the identity of the sender of a transaction **• Ring Confidential Transactions (RingCT)-** are used to obscure the amount of coins in any transaction **• Stealth Addresses-** are used to hide the identity of the person (address) receiving any funds Haven's privacy features are by default and are integral to the codebase, therefore it is not possible to accidentally make a transparent transaction. # Why does Haven need privacy? Like any other account there will be sensitive information that a user would not want to be available publicly. This is especially true for personal financial data that, if stolen, can be used by unscrupulous parties to potentially steal those funds. The privacy features of Haven makes this much less likely to happen. For businesses that wish to use Haven it would make sense that accounts and transactions will likely contain commercially sensitive information and therefore would not want to be shared publicly. # Overview * Overview * Airgap * Address * Address Book * Account * Atomic Units * Block * Blockchain * Bootstrap Node * Bulletproofs * Canonically Unique Host * Change * Clearnet * Coinbase * Consensus * Cryptocurrency * Daemon * Denomination * Encryption * Fluffy Blocks * Fungibility * Kovri * Locally Unique Host * Mining * Mnemonic Seed * Node * Open Alias * Papper Wallets * Payment ID's * Pedersen Commitments * Pruning * Random X * Remote Node * Ring Size * RingCT * Ring Signatures * Scalability * Spend Key * Stealth Address * Tail Emision * Transactions * Unlock Time * View Key * Wallet # Airgap #### The Basics "An air gap, air wall or air gapping is a network security measure employed on one or more computers to ensure that a secure computer network is physically isolated from unsecured networks, such as the public Internet or an unsecured local area network.\[2] The name arises from the technique of creating a network that is physically separated (with a conceptual air gap) from all other networks. The air gap may not be completely literal, as networks employing the use of dedicated cryptographic devices that can tunnel packets over untrusted networks while avoiding packet rate or size variation can be considered air gapped, as there is no ability for computers on opposite sides of the gap to communicate." Taken from ) # Address #### The Basics When you send Haven to someone you only need one piece of information, and that is their Haven address. A *raw* Haven address is a set of 95 characters starting with a '4'. The Haven donation address, for instance, is 888tNkZrPN6JsEgekjMnABU4TBzc2Dt29EPAvkRxbANsAnjyPbb3iQ1YBRk1UXcdRsiKc9dhwMVgN5S9cQUiyoogDavup3H. Because those addresses are long and complex, you will often encounter an @OpenAlias address instead. For example, Haven donations can be sent to or donate.gethaven.org. If you would like to get an @OpenAlias address of your own then there is some information on the [OpenAlias page](https://app.gitbook.com/the-haven-project/). #### Integrated address An integrated address is an address combined with an encrypted 64-bit @payment-ID. A raw integrated address is 106 characters long. #### In-depth Information The address is actually the concatenation, in Base58 format, of the *public* @spend-key and the *public* @view-key, prefixed with the network byte (the number 18 for Haven) and suffixed with the first four bytes of the Keccac-256 hash of the whole string (used as a checksum). # Address Book #### The Basics In order to browse @I2P sites or services with @Kovri, you'll need an address book. An address book will allow you to translate @I2P websites/services that use the `.i2p` [top-level domain](https://en.wikipedia.org/wiki/Top_level_domain) into an address that @I2P network will understand. Without an address book, you would be stuck using a @base32-address every time you visit an @I2P website/service - and that's not fun! #### In-depth information Since [DNS](https://en.wikipedia.org/wiki/DNS) does not exist on the @I2P network, @Kovri also does **not** use DNS or any sort of @canonically-unique-host resolution. Instead, Kovri pairs a @locally-unique-host to a @base64-address @destination in a @subscription. Once your address book is filled with a @subscription, you can resolve your favorite `.i2p` domain site into a usable @I2P destination. #### Creating an Address Book By default, your installation will come with a default public @subscription called `hosts.txt` in your @data-directory. When @Kovri starts, it loads this subscription and fetches any other subscriptions you've specified. Once loaded, your address book will be appropriately filled. For details on how to manage subscriptions, see @subscription. #### Updating the Address Book Currently, there are several ways to update your address book: 1. Use a @jump-service to insert I2P addresses into your address book 2. Use a @jump-service to copy/paste an address into your private @subscription 3. Manually add or subtract from a private @subscription **Note: Kovri is in heavy development. In the future there *****will***** be easier ways to update the address book** #### Address Book / Naming specification For specification details and more, visit the [Address Book and Naming Specification](https://geti2p.net/en/docs/naming) # Account #### The Basics Those familiar with Haven's predecessors will be more familiar with the term *wallet* to describe this. In Haven we call this an account, and it is a private account owned and operated by a Haven user. Your account contains all of the Haven @transactions you have sent and received. Your account balance is a sum of all the Haven you've received, less the Haven you've sent. When using Haven you may notice that your account has two balances, a locked and an unlocked balance. The unlocked balance contains funds that can be spent immediately, and the locked balance contains funds that you can't spend right now. You may receive a transaction that has an @unlock-time set, or you may have sent some Haven and are waiting for the @change to come back to your wallet, both situations that could lead to those funds being locked for a time. A key difference between traditional electronic currency and Haven is that your account resides only under your control, normally on your computer, and cannot be accessed by anyone else if you practice good security. #### Multiple Accounts There are no costs attached to creating a Haven account, and there are no fees charged except for individual @transaction fees that go to @miners. This means that individuals can easily create a Haven account for themselves as well as a joint account to share with their partner, and individual accounts for their children. Similarly, a business could create separate accounts for each division or group. Since Haven's @transaction fees are quite low, moving funds between accounts is not an expensive exercise. #### Cryptographic Keys Haven relies heavily on a cryptography principle known as *public/private key cryptography* or *asymmetric cryptography*, which is thoroughly detailed in [this Wikipedia article](https://en.wikipedia.org/wiki/Public-key_cryptography). Your account is based on two keys, a @spend-key and a @view-key. The @spend-key is special in that it is the single key required to spend your Haven funds, whereas the @view-key allows you to reveal your @transactions to a third party, for example for auditing or accounting purposes. These keys in your account also play an important role in Haven's @transaction's privacy. The private keys for both of these must be protected by you in order to retain your account privacy. On the other hand, the public keys are obviously public (they are part of your Haven account address). For normal public/private key cryptography someone could send you a private message by encrypting it with either of your public keys, and you would then be the only one able to decrypt it with your private keys. #### Backing Up Your Account When you manage your own Haven Account with the private @spend-key, you are solely responsible for the security of your funds. Thankfully, Haven makes it very easy to backup your account. When creating a Haven account for the first time you will be given a unique @mnemonic-seed for your account that consists of 13 or 25 words in the language of your choosing. **This seed is the only thing you need to backup for your account**, and so it is imperative that it is written down and stored securely. Never store this seed in a form or location that would allow someone else to see it! ``` List of available languages for your wallet's seed: 0 : Deutsch 1 : English 2 : Español 3 : Français 4 : Italiano 5 : Nederlands 6 : Português 7 : русский язык 8 : 日本語 9 : 简体中文 (中国) 10 : Esperanto Enter the number corresponding to the language of your choice: 1 Generated new wallet: 4B15ZjveuttEaTmfZjLVioPVw7bfSmRLpSgB33CJbuC6BoGtZrug9TDAmhZEWD6XoFDGz55bgzisT9Dnv61sbsA6Sa47TYu view key: 4130fa26463d9451781771a8baa5d0b8085c47c4500cefe4746bab48f1d15903 ********************************************************************** Your wallet has been generated. To start synchronizing with the @daemon, use "refresh" command. Use "help" command to see the list of available commands. Always use "exit" command when closing haven-wallet-cli to save your current session's state. Otherwise, you might need to synchronize your wallet again (your wallet keys are NOT at risk in any case). PLEASE NOTE: the following 25 words can be used to recover access to your wallet. Please write them down and store them somewhere safe and secure. Please do not store them in your email or on file storage services outside of your immediate control. aunt knuckle italics moisture hawk thorn iris abort chlorine smog uphill glass aptitude nowhere sewage plywood dual relic fierce divers anvil nodes bubble cabin abort ********************************************************************** Starting refresh... Refresh done, blocks received: 21939 Balance: 0.000000000000, unlocked balance: 0.000000000000 Background refresh thread started ``` As the example above indicates, it is incredibly important to store these words in safe locations. If you are concerned about the risk of critical loss at your home, for instance, you may want to store a second copy of your seed with your attorney or in a safety deposit box. It is also recommended that it is stored in a way that does not make it obvious that it is your seed, so writing it into a letter or as part of other notes is advisable. #### Practicing Good Security Over and above backing up your @mnemonic-seed so that you have access to your account in the event of critical data loss, it is also important to practice good security. Use a secure password when creating a local Haven account (not used on [MyHaven](https://myhaven.com) or other web-based account systems). Don't ever give your Haven account password to anyone, as this can be used to access the Haven on your computer without knowing your @mnemonic-seed. Similarly, make sure you have running and up-to-date antivirus, especially on Windows computers. Finally, be careful when clicking links in emails or on unknown and untrusted websites, as malware installed on your computer can sit and wait for you to access your Haven account before taking the funds from it. #### Leaving Your Account to Next of Kin Providing access to your Haven account to your next of kin is just as easy as it is to backup your Haven account. Simply leave your @mnemonic-seed to them in your will, or store it somewhere safe where it will be given to them upon the execution of your will. A key advantage to this is that your next of kin won't have to wait for months for a third party to release the funds to them. # Atomic Units #### The Basics Atomic Units refer to the smallest fraction of 1 XHV. One atomic unit is currently 1e-12 XHV (0.000000000001 XHV, or one @piconero). It may be changed in the future. # Block #### The Basics A block is a container of @transactions, with a new block being added to the @blockchain once every 2 minutes (see constant `DIFFICULTY_TARGET_V2` defined as 120 seconds), on average. Blocks also contain a special type of transaction, the @coinbase-transaction, which add newly created Haven to the network. Blocks are created through the process of @mining, and the @node that successfully mines the block then broadcasts it to each of the @nodes connected to it, who subsequently re-broadcast the block until the entire Haven network has received it. Fake or bad blocks generally cannot be created, as @nodes that receive blocks always verify the @transactions they contain against a set of consensus rules that all nodes adhere to, including validating the cryptographic @signatures on each transaction. # Blockchain #### The Basics A @blockchain is a distributed database that continuously grows with a record of all of the transactions that have occurred with a given cryptocurrency. This database is often referred to as a ledger because the data contains a large list of transactions that have taken place. In Haven, these transactions are packaged together into 'blocks' every 2 minutes (on average), and all miners and nodes on the network have copies of these blocks. #### Haven's @Blockchain Unlike Bitcoin and other cryptocurrencies, transactions in the Haven @blockchain do not reveal where funds came from or went to, providing anonymity and making the currency completely @fungible. Additionally, the amounts of all transactions are hidden by @RingCT, a feature of Haven. For auditing or other transparency purposes a user can share a @view-key to prove they control certain amounts of Haven. # Bootstrap Node #### The Basics The @daemon running on a local @node has to sync with other @remote-nodes. While it is not fully synced, @wallet may still be connected to the local node. Therefore, the @wallet cannot access the @blocks that are not yet synced on the local @node. To allow the @wallet to be immediately usable, the daemon on the local @node uses a bootstrap node to which the RPC request are proxying to, giving access to the missing @blocks. Note: the replies from the bootstrap node may be untrustworthy. # Bulletproofs #### The Basics @RingCT was introduced to obfuscate transaction amounts. One goal of @RingCT was to prove the sum of inputs - outputs in the @transaction was equal to 0, and all outputs were positive numbers.\ To accomplish this, two kind of ring signatures were constructed: One ring signature for the whole transaction (to prove the sum is 0), and a set of ring signatures for the subsets of transaction bits (to prove the outputs are positive numbers), then combined together using originally Schnorr signatures (and later replaced by Borromean ring signature).\ While it was doing the job, a big drawback was the huge size of such a ringCT transaction. #### Where it comes to bulletproofs Back in 2017, a [Standford applied crypto group](https://crypto.stanford.edu/bulletproofs/) wrote a [paper](https://eprint.iacr.org/2017/1066.pdf) presenting a new kind of range proofs, called bulletproofs. > Bulletproofs are short non-interactive zero-knowledge proofs that require no trusted setup. Bulletproofs, unlike Borromean or Schnorr signatures, are very efficient as range proofs. Proving a big set of data only generates a small proof, and the size of this proofs grows logarithmically with the size of the data being proved.\ It means that increasing the number of outputs in a transaction will, with bulletproofs only slightly increase the size of the proof.\ Bulletproofs also have the advantage to allow to prove that multiple committed amounts are in the desired range at once. No need to prove each output to each destination in separate proofs; the whole transaction amounts could be proven in one bigger (but still very small) bulletproof. #### Thorough audit process and implementation As bulletproofs were really new, and the initial implementation made by the group, while thoroughly done, needed a rewrite focused on our specific use-case, implementing bulletproof in Haven was not a simple thing. \ The code has been written and rewritten to follow the new version of bulletproofs which was still being developed, but once this Haven implementation was finalized, the resulting deployment should be taken with extreme care. \ Therefore, the community started an auditing process. Researchers reached out to Benedikt Bünz, lead author of the Bulletproofs paper, and to [OSTIF](https://ostif.org/) an organization which helps open source technologies to improve and secure themselves. \ OSTIF directed the group to several organizations with the skills required to perform the audit. While one of them asked to be kept unnamed and was therefore put away from the process that needed to be public, two others (QuarksLab & Kudelski Security) were choosen to conduct the audit. \ Our 3 auditors were funded by the community to check out the if the implementation did not did not contain critical bugs, and if it did not have any exploits. \ The final reports were released during the summer of 2018, with several useful corrections and fixes suggested, and the final bulletproof implementation has been added first to Haven Stagenet, and then to the main Haven network during the October 2018 network upgrade. Since the bulletproofs deployment, the size of an average transaction has dropped by at least 80%, as well as the transaction fees. More explanations on Haven's implementation of bulletproofs could be found on youtube fondajo channel in a [conversation with Sarang Noether](https://www.youtube.com/watch?v=6lEWqIMLzUU). # Canonically Unique Host #### The Basics A Canonically-unique host is a [FQDN](https://en.wikipedia.org/wiki/FQDN) that will canonically resolve to a designated address or set of addresses. Not to be confused with a @locally-unique-host. #### In-depth information A Canonically-unique host is defined by remote authoritative sources; usually through [DNS](https://en.wikipedia.org/wiki/DNS). When resolving a peer's hostname, you will most likely use an external source for resolution unless you have the following implemented: * a database file similar to a \[hosts file]\()) * an internal-network resolver (which eventually pulls from external sources) #### Notes * Haven primarily uses @canonically-unique-host resolution while @I2P only uses @locally-unique-host resolution. * @I2P's and @Kovri's self-assigned top-level domain is currently `.i2p` and @Kovri intends to only process/use the `.i2p` [top-level domain](https://en.wikipedia.org/wiki/Top_level_domain) # Change #### The Basics Haven sent as part of a transaction, that returns to your account instead of going to another recipient. #### More Information The @wallet in the Haven software makes change automatically, but when you send a transaction, you are taking an input that you control and telling the Haven network what to do with it. The input is a "deposit" to your account that you are able to spend. Outputs are the part of the transaction that tells the Haven network where to send the funds. You might have multiple inputs in your account, in many different denominations (For example: you deposited 0.5 XMR on Friday, and 0.75 XMR on Saturday). So, when have a transaction with an input of 0.5 XMR, but you only want to send 0.1 XMR, your transaction will include a fee to pay the @miner, an output for 0.1 XMR to send to the recipient, and the rest that you want to send back to yourself will be an output back to you (this is called "change"). Once the transaction is completed, the change becomes available to you as an input that you can again split and send with a new transaction. # Clearnet #### The Basics When you use the Internet for things like news, email, social media, and even Haven, you are most likely using a clearnet connection. This means that *all* of your connections can be tracked, traced, and monitored by: * your [ISP](https://en.wikipedia.org/wiki/ISP) * the website/service/person you're communicating with * possibly a [Five Eyes](https://en.wikipedia.org/wiki/5_Eyes) capable entity and even if you use [HTTPS](https://en.wikipedia.org/wiki/HTTPS) or similar (which *encrypts* your transmission), your route is not hidden nor is it anonymous, thus; it is in the *clear*. #### In-depth information Since a traditional [VPN](https://en.wikipedia.org/wiki/VPN) cannot save you from clearnet (as you are still using *clearnet* (though you are more proxied than without a VPN)), you should use an *anonymous overlay network* to avoid using clearnet directly: * @Kovri * @Java-I2P * [Tor](https://torproject.org/) These technologies protect you from clearnet by building an anonymous network **over** clearnet to keep your transmissions both encrypted **and** anonymous. Here is an accurate, [interactive diagram](https://www.eff.org/pages/tor-and-https) provided by the [EFF](https://www.eff.org/) which describes *clearnet* as it relates to **Tor**. The concept also (somewhat) applies to @Kovri and @I2P in terms of anonymity with the exception that: * @Kovri does not use exit nodes when connecting to an @eepsite * Your traffic never need to leave the @I2P network * You do not need HTTPS to use @Kovri (with the exception of @reseed) # Coinbase #### The Basics A special type of transaction included in each block, which contains a small amount of Haven sent to the miner as a reward for their mining work. # Consensus #### The Basics Consensus describes a property of distributed networks like Haven where most of the participants follow the rules, and thus reject bad participants. # Cryptocurrency #### The Basics A digital currency in which encryption techniques are used to regulate the generation of units of currency and verify the transfer of funds, usually operating independently of a central bank. #### More Information Cryptocurrency is the generic term for a large set of digital assets that use encryption techniques to generate units of currency, verify the transactions, and transfer value. Generally, cryptocurrencies are considered to be decentralized. Cryptocurrency should not be confused with virtual currency which is a type of digital money that is usually controlled by its creators or developers. Some examples of virtual currency are gametime in World of Warcraft, ROBUX in Roblox, reward points programs, or Ripple, all of which can be exchanged for currency or cash value, but are not considered cryptocurrency because they are centalized and controlled/issued by a single entity. Haven is one of many cryptocurrencies currently available. Other examples are Bitcoin, Litecoin, Dogecoin, Dash, Zcash, etc, but nearly all other cryptocurrencies lack features that make them a true money (most importantly @fungibility which is a requirement for it to be a store-of-value). Not all cryptocurrencies operate the same, but they usually share the properties of decentralization, encryption, and the ability to send and receive transactions. Most are irreversible, pseudonymous, global, and permissionless. Most aim to be a store-of-value or be digital cash that allows you to transact. Most cryptocurrencies (including Haven) use a distributed ledger (called a @blockchain) to keep track of previous transactions. The blockchain serves to tell other users on the network that transactions have happened. There are many different ways for cryptocurrencies to create their blockchain, and not all are the same. Haven uses proof-of-work to craft blocks, where other cryptocurrencies may use proof-of-stake or other consolidated methods. Ultimately, cryptocurrency is an attempt to create trustless value; that is free from borders, governments, and banks. Whether that be to transact or to be digital gold is up to the users of each. # Daemon 'Daemon' is the general term for a piece of software running in the background. In Haven, the Daemon is started through the 'havend' program. If you run the Daemon locally, you are running a local [node](/overview/node). If the Daemon is running on another device it's a @remote-node. A @wallet, like the CLI or the GUI, needs to connect to a Daemon (local or remote) to relay @transactions to the network. It's possible to send commands to the Daemon directly or through the RPC interface. See the [Daemon RPC guide](https://app.gitbook.com/s/-MIUkN4w3pz_N3EraYsq/overview/%7B%7B%20site.baseurl_root%20%7D%7D/resources/developer-guides/daemon-rpc.html), which contains a detailed explanation (with examples) of the available RPC calls. For more detailed and technical information about the Daemon, see the Havendocs reference at the bottom of this page. **Other Resources** 1\. The [havend reference on Havendocs.org](https://havendocs.org/interacting/havend-reference/)\ 2\. 'Daemon' entry \[on Wikipedia]\())\ 3\. Havend-tagged questions [on StackExchange](https://haven.stackexchange.com/?tags=havend) # Denomination #### The Basics A denomination is a proper description of a currency amount. It is oftentimes a sub-unit of the currency. For example, traditionally a cent is 1/100th of a particular unit of currency.). Haven denomination names add SI prefixes after dropping the initial "mo" for ease of use. Actually, the smallest unit of Haven is 1 piconero (0.000000000001 XMR). #### Denominations of Haven \|------------+----------+-------------------| | Name | Base 10 | Amount | | ------------------------------------------: | :------: | -------------: | | piconero | 10^-12 | 0.000000000001 | | nanonero | 10^-9 | 0.000000001 | | micronero | 10^-6 | 0.000001 | | millinero | 10^-3 | 0.001 | | centinero | 10^-2 | 0.01 | | decinero | 10^-1 | 0.1 | | ============+==========+=================== | | | | **haven** | **10^0** | **1** | | ============+==========+=================== | | | | decanero | 10^1 | 10 | | hectonero | 10^2 | 100 | | kilonero | 10^3 | 1,000 | | meganero | 10^6 | 1,000,000 | | ------------+----------+------------------- | | | #### In-depth Information Support for input using SI prefixes was [added to the Haven codebase](https://github.com/haven-project/haven/pull/1826) on March 3, 2017 by [Havenmooo](https://github.com/havenmooo-haven). The smallest unit of Haven (10^-12 XMR) was originally called a tacoshi in honor of user [Tacotime](https://bitcointalk.org/index.php?action=profile;u=19270), an early Haven contributor and was later renamed for ease of use and consistancy. #### Havend Implementation The smallest fraction of Haven in the current havend implementation is also known as the @atomic-unit, which is currently one piconero. # Destination #### The Basics A @destination is the @I2P @in-net address of the final endpoint you are trying to connect to (example: an @I2P website, service, or Haven node). This can also include a *local destination* of which *other* peers need to connect to in order to make contact for communication (similar to how, in @clearnet, your IP address is given to a website when you connect so it knows *where* to send the information back to). #### In-depth Information An @I2P destination can be encoded into a @base32-address or @base64-address. Most users will only care about @base32-addresses or a `.i2p` hostname while, internally, @Kovri / @I2P @address-book uses @base64-addresses. Ultimately, all @destinations in @I2P are 516-byte (or longer) keys: `256-byte public key + 128-byte signing key + a null certificate = 516 bytes in Base64 representation` Note: certificates are not used now but, if they were, the keys would be longer. # Encryption #### The Basics From [Encryption](https://en.wikipedia.org/wiki/Encryption): \> In cryptography, encryption is the process of encoding messages or information in such a way that only authorized parties can decode and read what is sent. Encryption does not of itself prevent interception, but denies the message content to the interceptor. #### In-depth information From [Encryption](https://en.wikipedia.org/wiki/Encryption): > In an encryption scheme, the intended communication information or message (referred to as plaintext), is encrypted using an encryption algorithm, generating ciphertext that can only be read if decrypted. For technical reasons, an encryption scheme usually uses a pseudo-random encryption key generated by an algorithm. It is in principle possible to decrypt the message without possessing the key, but, for a well-designed encryption scheme, large computational resources and skill are required. An authorized recipient can easily decrypt the message with the key provided by the originator to recipients, but not to unauthorized interceptors. > The purpose of encryption is to ensure that only somebody who is authorized to access data (e.g. a text message or a file), will be able to read it, using the decryption key. Somebody who is not authorized can be excluded, because he or she does not have the required key, without which it is impossible to read the encrypted information. #### Kovri @Kovri implements various types of encryption in *at least* 4 essential capacities: * @Reseed for bootstrapping * @Garlic-routing: three layers of encryption (@garlic-encryption) are used to verify the secure delivery of @messages to the recipient/peer/@destination * @Tunnel encryption: garlic messages are passed through a @tunnel and encrypted by the @tunnel gateway to the @tunnel endpoint * @Transport layer encryption prevents the ability to decrypt @messages at the [media layer](https://en.wikipedia.org/wiki/OSI_model) For details on the types of encryption and cryptographic @signatures used in @Kovri and @I2P, visit @Java-I2P's [Cryptography](https://geti2p.net/spec/cryptography) # Fluffy Blocks #### The Basics A @block is made up of a header and @transactions. Fluffy Blocks only contain a header, a list of transaction indices, and any transactions that the node recieving the block may be missing. This saves bandwidth because nodes might already know about most or all of the transactions in the block and they don't need to be sent them again. #### See Also * [BIP152 "Compact Block Relay"](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) * [Xthin](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/release/doc/bu-xthin-protocol.md) # Fungibility #### The Basics Property of a currency whereby two units can be substituted in place of one another. Fungibility means that two units of a currency can be mutually substituted and the substituted currency is equal to another unit of the same size. For example, two $10 bills can be exchanged and they are functionally identical to any other $10 bill in circulation (although $10 bills have unique ID numbers and are therefore not completely fungible). Gold is probably a closer example of true fungibility, where any 1 oz. of gold of the same grade is worth the same as another 1 oz. of gold. Haven is fungible due to the nature of the currency which provides no way to link transactions together nor trace the history of any particular XHV. 1 XHV is functionally identical to any other 1 XHV. Fungibility is an advantage Haven has over Bitcoin and almost every other cryptocurrency, due to the privacy inherent in the Haven @blockchain and the permanently traceable nature of the Bitcoin blockchain. With Bitcoin, any BTC can be tracked by anyone back to its creation @coinbase-transaction. Therefore, if a coin has been used for an illegal purpose in the past, this history will be contained in the @blockchain in perpetuity. This lack of fungibility means that certain businesses will be obligated to avoid accepting BTC that have been previously used for purposes which are illegal, or simply run afoul of their Terms of Service. Currently some large Bitcoin companies are blocking, suspending, or closing accounts that have received Bitcoin used in online gambling or other purposes deemed unsavory by said companies. Haven has been built specifically to address the problem of traceability and non-fungibility inherent in other cryptocurrencies. By having completely private transactions Haven is truly fungible and there can be no blacklisting of certain XHV, while at the same time providing all the benefits of a secure, decentralized, permanent blockchain. # Kovri #### The Basics [Kovri](https://gitlab.com/kovri-project/kovri/) is a C++ implementation of the I2P network which was proposed to be integrated in Haven. At the moment the future of this I2P router is unclear and an integration with Haven is not planned. Read [anonimal's FFS proposal](https://forum.gethaven.org/9/work-in-progress/86967/anonimal-s-kovri-full-time-development-funding-thread) for more details and for reasoning behind the project. Also read the FAQ and User Guide in the [Kovri repository](https://gitlab.com/kovri-project/kovri/). # Locally Unique Host #### The Basics A locally-unique host is a [FQDN](https://en.wikipedia.org/wiki/FQDN) defined by **you** and resolved only by you; similar to how a \[hosts file]\()) is implemented. Not to be confused with @canonically-unique-host. #### In-depth information You have the option to share your interpretation of how the host is resolved (e.g., `localhost` always resolves to `127.0.0.1`) but the resolution is not canonically enforced (e.g., someone else can map `localhost` to any arbitrary IP address). Hosts in a public subscription can be considered @canonically-unique-host's within the @I2P network but, ultimately, you are free to re-define them as you wish. #### Notes * Haven primarily uses @canonically-unique-host resolution while @I2P only uses @locally-unique-host resolution. * @I2P's and @Kovri's assigned top-level domain is currently `.i2p` and @Kovri intends to only process/use the `.i2p` [top-level domain](https://en.wikipedia.org/wiki/Top_level_domain) # Mining #### The Basics The process of cryptographically computing a mathematical proof for a block, containing a number of transactions, which is then added to the blockchain. Mining is the distributed process of confirming transactions on the public ledger of all transactions, aka @blockchain. Haven nodes use the blockchain to distinguish legitimate transactions from attempts to re-spend coins that have already been spent elsewhere. Haven is powered strictly by Proof of Work. It employs a mining algorithm that has the potential to be efficiently tasked to billions of existing devices (any modern x86 CPU and many GPUs). Haven uses a variant of CryptoNight Proof of Work (PoW) algorithm, which is designed for use in ordinary CPUs and GPUs. The smart mining feature allows transparent CPU mining on the user's computer, far from the de facto centralization of mining farms and pool mining, pursuing Satoshi Nakamoto's original vision of a true P2P currency. # Mnemonic Seed #### The Basics A 13 or 25 word phrase used to backup a Haven account, available in a number of languages. This 25-word phrase has all the information needed to view and spend funds from a Haven @account. #### In-depth Information In the official wallet, the mnemonic seed comprises 25 words with the last word being used as a checksum. Those words correspond to a 256-bit integer, which is the account's *private* @spend-key. The *private* @view-key is derived by hashing the private spend key with Keccak-256, producing a second 256-bit integer. The corresponding *public* keys are then derived from the private keys. By storing the 25 word mnemonic key in a secure location, you have a backup of your private keys and hence all of your Havenj. Sharing this 25 word key is the equivalent of allowing another person complete access to your funds. It's not a good idea to store more than you want to lose in a "hot wallet" aka a wallet which is currently or has ever been connected to the internet or loaded onto any device that has or may in the future be connected to the internet or any untrusted source! By creating a cold, or @paper-wallet you can safely store Havenj. # Node #### The Basics A device on the Internet running the Haven software, with a full copy of the Haven blockchain, actively assisting the Haven network. A node that is not running on your local machine is called @remote-node. Remote nodes can be private, if they are for personal use only, or open, if they are accessible by other people. #### More Information Nodes participate in the Haven network and secure @transactions by enforcing the rules of the network. Nodes download the entire @blockchain to know what transactions have taken place. Nodes assist the network by relaying transactions to other nodes on the network. Nodes may also choose to contribute to the Haven network by participating in crafting @blocks (this is called @mining). Mining is the process by which nodes create a block from the previously accepted block, transactions that are waiting to be processed in the transaction pool, and the @coinbase-transaction. When a node believes it has crafted a valid block it will transmit the completed block to other nodes on the network and those nodes signal agreement by working on the next block in the chain. The rules that nodes follow are built into the Haven software; When all nodes agree about the rules to follow this is called @consensus. Consensus is necessary for a cryptocurrency because it is how the blockchain is built; If nodes don't agree about which blocks are valid, for example people who have not updated their Haven software, those nodes that don't agree will no longer be able to participate in the Haven network. The Haven Core Team plans for a network upgrade roughly every 6 months. At that time, if you are running a node it must be updated to the most recent version of the Haven software or it will no longer be able to participate in the network. # Open Alias #### The Basics The Monero Core Team released a standard called OpenAlias which permits much more human-readable addresses and "squares" the Zooko's triangle. OpenAlias can be used for any cryptocurrency and is already implemented in Haven, Bitcoin (in latest Electrum versions) and HyperStake. OpenAlias seeks to provide a way to simplify aliasing amidst a rapidly shifting technology climate. Users are trying to cross the bridge to private and cryptographically secure infrastructure and systems, but many of them have just barely started remembering the email addresses of their friends and family. As part of the ongoing development of the Haven cryptocurrency project, we asked ourselves: how can we simplify payments for users unfamiliar with cryptocurrency? Haven stealth addresses are at least 95 characters long - memorizing them is not an option, and asking someone to send a payment to is only going to lead to confusion. At its most basic, OpenAlias is a TXT DNS record on a FQDN (fully qualified domain name). By combining this with DNS-related technologies we have created an aliasing standard that is extensible for developers, intuitive and familiar for users, and can interoperate with both centralized and decentralized domain systems. A standard that allows you to use an email or domain syntax to pay someone instead of an address, eg. or donate.gethaven.org. More information can be found on the [OpenAlias page](https://app.gitbook.com/the-haven-project/) or on the [OpenAlias website](https://openalias.org) # Paper Wallet #### The Basics A paper wallet stores the information necessary to send and receive Haven. # Payment ID's *Note:* Long Payment IDs have been removed since release 0.15; it's not possible to use them anymore. More info in the [blog post](https://gethaven.org/2019/06/04/Long-Payment-ID-Deprecation.html) that announced their deprecation. #### The Basics Payment ID is an **arbitrary** and **optional** transaction attachment that consists of 32 bytes (64 hexadecimal characters) or 8 bytes (in the case of integrated addresses). The Payment ID is usually used to identify transactions to merchants and exchanges: Given the intrinsic privacy features built into Haven, where a single public address is usually used for incoming transactions, the Payment ID is especially useful to tie incoming payments with user accounts. #### Compact Payment IDs and Integrated Addresses Since the 0.9 Hydrogen Helix version, Payment IDs can be encrypted and embedded in a payment address. The Payment IDs of this type should be 64-bits and are encrypted with a random one-time key known only to the sender and receiver. #### Creating a Payment ID It is recommended to use the official wallet's `integrated_address` command to automatically generate Integrated Addresses that contain Compact Payment IDs. If you want to use the command line, you can generate Payment IDs as follows: Creating a compact Payment ID for an Integrated Address: `# openssl rand -hex 8` Creating an old-style Payment ID: `# openssl rand -hex 32` # Pedersen Commitments #### The Basics Pedersen commitments are cryptographic algorythms that allow a prover to commit to a certain value without revealing it or being able to change it. When you spend Haven, the value of the inputs that you are spending and the value of the outputs you are sending are encrypted and opaque to everyone except the recipient of each of those outputs. Pedersen commitments allow you to send Haven without revealing the value of the transactions. Pedersen commitments also make it possible for people to verify that transactions on the blockchain are valid and not creating Haven out of thin air. #### What It Means As long as the encrypted output amounts created, which include an output for the recipient and a change output back to the sender, and the unencrypted transaction fee is equal to the sum of the inputs that are being spent, it is a legitimate transaction and can be confirmed to not be creating Haven out of thin air. Pedersen commitments mean that the sums can be verified as being equal, but the Haven value of each of the sums and the Haven value of the inputs and outputs individually are undeterminable. Pedersen commitments also mean that even the ratio of one input to another, or one output to another is undeterminable. It is unclear which inputs are really being spent as the ring signature lists both the real inputs being spent and decoy inputs, therefore you don't actually know which input Pedersen commitments need to be summed. That's okay, because the @RingCT ring signature only has to prove that for one combination of the inputs the outputs are equal to the sum of the inputs. For mathematical reasons, this is impossible to forge. #### In-depth Information See information in [Ring Confidential Transactions paper](https://eprint.iacr.org/2015/1098.pdf) by Shen Noether of the Haven Research Lab. # Pruning 'Pruning' allows node operators to save 2/3 of storage space while keeping the full transaction history. Pruning works by removing 7/8 of unnecessary ring signature data. The 1/8 remaining data will be available to the other nodes and will be used to sync with the network. Other pruned nodes will have a random 1/8 of the data, which they will also make available to the network. There are no privacy or security downsides when using a pruned node. There are three ways to prune: * *Synchronize a pruned node from scratch:* You will download and sync only 1/3 of the full blockchain. * *Prune an existing node:* The already existing blockchain will be pruned, but this will not result in a smaller blockchain. Instead, it will mark parts of the file as free, so that future data will use that free space, causing the file to not grow until free space grows scarce. * *Create a new pruned blockchain from a full one:* A full blockchain that you already have will be used to create a new, pruned blockchain. Pruned nodes are very useful and preferable to @remote-nodes, but if possible, users should run a full node and opt for pruning only in case if necessary. The 'database pruning' feature [was added](https://github.com/haven-project/haven/pull/4843) on January 2019. See the [blog post](https://app.gitbook.com/s/-MIUkN4w3pz_N3EraYsq/overview/%7B%7B%20site.baseurl%20%7D%7D/2019/02/01/pruning.html) for more information. # Random X RandomX is a Proof Of Work algorithm developed by Monero contributors and adopted by Monero from release 0.15. This innovative POW is optimized for CPUs and it's based on execution of random code and other memory-heavy techniques. The goal is to discourage the use of specialized hardware (like ASICs) for @mining Haven. RandomX was created with the intent of keeping mining decentralized and to create a more egalitarian distribution of the @block rewards. RandomX specifications and development can be found [on the GitHub repository](https://github.com/tevador/RandomX), while [an article dedicated to RandomX](https://www.havenoutreach.org/stories/RandomX.html) made by the Outreach workgroup contains more information about the history of RandomX and its relation with Haven. # Remote Node A @node that doesn't run on the same local machine where the Haven @wallet is located is called "Remote Node" and can be private or open. A **private remote node** doesn't run on your local machine, but you have full control over it. A classic example is a node running on a VPS or a server. That node is not on your local machine, but you have full control over it. You can even decide to make it become an open node, allowing people to connect to it. An **Open remote node** can be used by people who, for their own reasons (usually because of hardware requirements, disk space, or technical abilities), cannot/don't want to run their own node and prefer to relay on one publicly available on the Haven network. Open remote nodes are often simply referred as "remote nodes". Using an open node will allow to make a @transaction instantaneously, without the need to download the @blockchain and sync to the Haven network first, but at the cost of the control over your privacy. the Haven community suggests to always run your own node to obtain the maximum privacy possible and to help decentralize the network. #### Public Nodes Open nodes are cool because, as we said above, allow people who are not running their own node to immediately join the Haven network. There are 2 main ways to connect to an open node: Simply get somebody to share with you their node, by asking them to "open it" and provide you with IP address and port, or use a public one. Public nodes are reachable in the network using two systems: * **Node aggregators**, which are basically lists of open remote nodes. The operators of those nodes decided to add them to the aggregator so that other people can use them. The aggregator will provide to the person who want to use a remote node a simple URL. This URL connects to one of the nodes in the list and will need to be inserted in the Haven wallet (GUI or CLI). The wallet will then contact one of the nodes provided by the URL and will allow the end user to immediately receive and send transactions. * **Native public nodes**. This is one of the new coolest features the Monero devs came up with to improve the user experience and to make easier to connect to the network. The @daemon allows to make a node public by simply adding the flag `--public-node`. Doing so, it will be advertised on the P2P network and people will be able to connect to it (or to another public node advertising itself in the same way) using the related option in the GUI and CLI wallets. Be aware that using public remote nodes can be risky. Node operators can link transactions to IP addresses. These risks can be mitigated, but you should always avoid using them if you have the possibility. Run your own node! # Ring Size #### The Basics Ring size refers to the total number of possible signers in a @ring-signature. If a ring size of 4 is selected for a given @transaction, this means that there are 3 foreign outputs in addition to your “real” output. A higher ring size number will typically provide more privacy than a lower number. However, reusing an odd, recognizable ring size number for transactions could possibly make transactions stand out. `Ring size = foreign outputs + 1 (your output)` # RingCT #### The Basics RingCT, short for Ring Confidential Transactions, is how transaction amounts are hidden in Haven. Ring CT was implemented in block #1220516 in January 2017. After September 2017, this feature became mandatory for all transactions on the network. RingCT introduces an improved version of @ring-signatures called "A Multi-layered Linkable Spontaneous Anonymous Group signature", which allows for hidden amounts, origins and destinations of transactions with reasonable efficiency and verifiable, trustless coin generation. For more information, please read the creator Shen Noether's paper [here](https://eprint.iacr.org/2015/1098). # Ring Signatures #### The Basics In cryptography, a ring signature is a type of digital signature that can be performed by any member of a group of users that each have keys. Therefore, a message signed with a ring signature is endorsed by someone in a particular group of people. One of the security properties of a ring signature is that it should be computationally infeasible to determine *which* of the group members' keys was used to produce the signature. For instance, a ring signature could be used to provide an anonymous signature from "a high-ranking White House official", without revealing which official signed the message. Ring signatures are right for this application because the anonymity of a ring signature cannot be revoked, and because the group for a ring signature can be improvised (requires no prior setup). #### Application to Haven A ring signature makes use of your @account keys and a number of public keys (also known as outputs) pulled from the @blockchain using a triangular distribution method. Over the course of time, past outputs could be used multiple times to form possible signer participants. In a "ring" of possible signers, all ring members are equal and valid. There is no way an outside observer can tell which of the possible signers in a signature group belongs to your @account. So, ring signatures ensure that transaction outputs are untraceable. Moreover, there are no @fungibility issues with Haven given that every transaction output has plausible deniability (e.g. the network can not tell which outputs are spent or unspent). To read how Haven gives you privacy by default (unlinkability), see @stealth-addresses. # Scalability #### The Basics The size of Haven @blocks (which contain @transactions) is flexible and can accommodate many transactions as demand changes. Formulas determine how the reward miners receive interacts with the number of transactions they choose to include in blocks. The @blockchain can therefore scale to meet changes in transaction volume. Scaling may also refer to the ability to conduct certain types of intermediate transactions safely without interacting with a blockchain. Haven does not currently support native off-chain solutions like atomic swaps, since its privacy features do not permit the use of required functionality like non-interactive refund transactions or complex scripting. However, academic and industry research is ongoing and promising in this area. # Spend Key #### The Basics One of the two pairs of private and public cryptographic keys that each account has, with the *private* spend key used to spend any funds in the account. #### In-depth Information The *private* spend key is a 256-bit integer that is used to sign Haven transactions. With the current deterministic key derivation method of the official wallet, the private spend key is also an alternate representation of the [mnemonic-seed](/overview/mnemonic-seed). It can be used to derive all other account keys. # Stealth Addresses #### The Basics Stealth addresses are an important part of Haven's inherent privacy. They allow and require the sender to create random one-time addresses for every @transaction on behalf of the recipient. The recipient can publish just one address, yet have all of his/her incoming payments go to unique addresses on the @blockchain, where they cannot be linked back to either the recipient's published address or any other transactions' addresses. By using stealth addresses, only the sender and receiver can determine where a payment was sent. When you create a Haven account you’ll have a private @view-key, a private @spend-key, and a Public Address. The @spend-key is used to send payments, the @view-key is used to display incoming transactions destined for your account, and the Public Address is for receiving payments. Both the @spend-key and @view-key are used to build your Haven address. You can have a “watch only” wallet that only uses the @view-key. This feature can be used for accounting or auditing purposes but is currently unreliable due to the inability to track outgoing transactions. You can decide who can see your Haven balance by sharing your @view-key. Haven is private by default and optionally semi-transparent! When using the Haven Wallet all this is handled by the software. Sending Haven is as easy as entering the destination address, the amount, and pressing Send. To recieve Haven, simply provide the sender your Public Address. To learn how Haven prevents tracking history (untraceability), see @ring-signatures. # Tail Emission #### The Basics Haven block rewards will never drop to zero. Block rewards will gradually drop until tail emission commences at the end of May 2022. At this point, rewards will be fixed at 0.6 XHV per block. #### Why Miners need an incentive to mine. Because of the dynamic blocksize, competition between @miners will cause fees to decrease. If mining is not profitable due to a high cost and low reward, miners lose their incentive and will stop mining, reducing the security of the network. Tail emission ensures that a dynamic block size and fee market can develop. # Transactions #### The Basics A cryptographically signed container that details the transfer of Haven to a recipient (or recipients). The parameters of a transaction contain one or more recipient addresses with corresponding amounts of funds and a @ring-size parameter that specifies the number outputs bound to the transaction. The more outputs that are used, a higher degree of obfuscation is possible, but that comes with a cost. Since a transaction gets larger with more outputs, the transaction fee will be higher. It is possible to form a transaction offline, which offers additional privacy benefits. A transaction can be uniquely identified with the use of an optional Transaction ID, which is usually represented by a 32-byte string (64 hexadecimal characters). #### In-depth Information Every transaction involves two keys: a public @spend-key, and a public @view-key. The destination for an output in a transaction is actually a one-time public key computed from these two keys. When a wallet is scanning for incoming transactions, every transaction is scanned to see if it is for "you". This only requires your private view key and your public spend key, and this check is immutable and cannot be faked. You cannot receive transactions and identify them without a corresponding private view key. In order to spend the funds you have to compute a one-time private spend key for that output. This is almost always done automatically by the Haven Wallet software. # Unlock Time #### The Basics A special transaction where the recipient can only spend the funds after a future date, as set by the sender. Unlock time allows you to send a transaction to someone, such that they can not spend it until after a certain number of blocks, or until a certain time. Note that this works differently than Bitcoin's [nLockTime](https://en.bitcoin.it/wiki/NLockTime), in which the transaction is not valid until the given time. # View Key #### The Basics One of two sets of private and public cryptographic keys that each account has, with the private view key required to view all transactions related to the account. Haven features an opaque blockchain (with an explicit allowance system called the @view-key), in sharp contrast with transparent blockchains used by any other cryptocurrency not based on CryptoNote. Thus, Haven is said to be "private, optionally transparent". Every Haven address has a private viewkey which can be shared. By sharing a viewkey, a person is allowing access to view every incoming transaction for that address. However, outgoing transactions cannot be reliably viewed as of June 2017. Therefore, the balance of a Haven address as shown via a viewkey should not be relied upon. # Wallet #### The Basics A Haven account, or wallet, stores the information necessary to send and receive Haven. In addition to sending and receiving, the Haven Wallet software keeps a private history of your transactions and allows you to cryptographically sign messages. It also includes Haven mining software and an address book. The term "hot wallet" describes a Haven [account](/overview/account) which is connected to the Internet. You can send funds easily but security is much lower than a cold wallet. Never store large amounts of cryptocurrency in a hot wallet! A cold wallet is generated on a trusted device or computer via an [airgap](/overview/airgap). If the device is to be reused, the data storage should be securely overwritten. As soon as a cold wallet is connected to the Internet or its mnemonic phrase or [spend-key](/overview/spend-key) is entered on an Internet-connected device, it's no longer "cold" and should be considered "hot". A Haven [paper-wallet](/overview/paper-wallet) can be generated by downloading the source code of [https://havenaddress.org/](http://paper-wallet.havenprotocol.org/#/). Verify the signature of the code on a trusted airgapped device. Create the wallet and print or store it on the media of your choice. Haven accounts and paper-wallets can be stored on any media - paper, USB drive, CD/DVD, or a hardware wallet device (Ledger available soon).