hsc-creator/hsc-options-explained.md

Hush Smart Chains (HSC) Parameters

When you decide to "roll your own" Hush Smart Chain (HSC), these are the -ac_ parameters you can use and how they function. Please feel free to fork and contribute if you find anything that needs updating.

ac_adaptivepow

Understanding Difficulty Stranding

The ac_adaptivepow parameter solves a vulnerability known as "Difficulty Stranding." Low-hashrate blockchains are particularly susceptible to this vulnerability.

When a blockchain's hashrate is much lower than that of another blockchain with the same mining algorithm, miners from the higher-powered chain can move to the lower-powered chain and mine a large number of blocks in a short amount of time.

In so doing, the rapid influx of new miners causes a part of the lower-powered chain's consensus mechanism called the Difficulty Adjustment Algorithm (DAA) to drastically increase the difficulty of finding a block. When the higher-powered group of miners leave, the difficulty level remains.

The smaller group of miners now may not be able to provide enough hash power to overcome the new difficulty level, and therefore this chain can be frozen.

This type of behavior is called "difficulty stranding,” and can be used as a method of malicious attack. This is a threat that is faced by all pure PoW chains that have a minor hashrate.

ac_adaptivepow Adjusts the Difficulty Level

The ac_adaptivepow parameter changes the Difficulty Adjustment Algorithm (DAA) of a Smart Chain to alleviate the potential effects of a "difficulty stranding" attack.

One method by which ac_adaptivepow alleviates the vulnerability is the changing of the time at which the difficulty level is set. Normally, the difficulty level is adjusted at the conclusion of finding a new block. With ac_adaptivepow, the difficulty target is adjusted as a part of the process of finding a new block.

This makes the process of lowering the difficulty easier and faster, as the DAA can take into account the amount of time the miners on the network are consuming to find a new block. If the amount of time is too high, the DAA can lower the difficulty as needed. More details on the implementation and rationale can be found in this blog post.(opens new window)

Adding the parameter -ac_adaptivepow=1 enables AdaptivePoW for a newly created Smart Chain.

ac_algo

The ac_algo parameter changes the chain's mining algorithm from the default equihash to a different algorithm. The default for Hush and Hush Smart Chains is Equihash (200,9).

Different Equihash

If you want to enable a different form of the EquiHash algorithm, then set -ac_algo=equihash -ac_nk=N,K where N and K would be your specified values.

Valid (N,K) choices are:

• (200,9) (the default, used by HUSH and ZEC)
• (210,9)
• (48,5)
• (96,5)
• (144,5)
• (150,5)

As an example, BEAM uses Equihash (150,5), so it would include -ac_algo=equihash -ac_nk=150,5 in its parameters.

Use randomX algorithm

To enable randomX algorithm, set -ac_algo=randomx. To get extra debug info printed to standard error (STDERR) about RandomX, you can also add -debug=randomx. Changing -debug does not change consensus rules, and can be added or removed whenever you want.

There are also two advanced options for the RandomX PoW, which most users will not need to change:

ac_randomx_interval (default 1024) and -ac_randomx_lag (default 64)

Do not change these from the defaults unless you have a very good reason to do so and understand the implications.

ac_blocktime

This parameter sets the average time (in seconds) by which a new block should be mined.

If this parameter is not included, the default value is ac_blocktime=60.

When the value of ac_blocktime is less than 60, the Smart Chain's block time will stabilize within less than twelve hours after launch. If the Smart Chain's ac_blocktime value is greater than 60, the Smart Chain's block time can require several days to stabilize.

When the value of ac_blocktime is less than 12 seconds (a high speed Smart Chain), the variances in network quality between consensus nodes (miners and stakers) can create difficulties in achieving a stable blockchain consensus. High-speed Smart Chains may function effectively on a LAN or other stable network, but The Hush Developers recommend caution when attempting to manage a high-speed Smart Chain on the public Internet.

Examples

./hushd -ac_name=HELLOWORLD -ac_supply=555555 -ac_reward=100000000 -ac_blocktime=20 &

ac_cbmaturity

The ac_cbmaturity parameter allows the COINBASE_MATURITY value to be changed.

The COINBASE_MATURITY value is the number of blocks that must be confirmed between the creation of a coin (in a coinbase transaction) and the moment the coin can be spent.

This allows the developers of a Smart Chain to require that miners and stakers on a blockchain network wait for an arbitrary amount of time after mining new coins to spend them.

For example, if a Smart Chain is set to ac_cbmaturity=10, newly mined coins must wait for 10 confirmations on the network before they can be spent.

By default, this value is set to 1 on Smart Chains without ac_eras and set to 100 on Smart Chains with ac_eras.

ac_cbopret

The ac_cbopret parameter allows the Decentralised Trustless Oracle mechanism to be enabled on a Smart Chain.

Fact

The Prices CryptoCondition module required the existence of a completely trustless and decentralized price feed Oracle (a DTO). The DTO was implemented by piggybacking on the timestamp consensus rules. It works by requiring the miners of the Smart Chain to include the required off-chain data as a part of OP_RETURN of the coinbase transaction (The transaction that pays the block reward to the miner). The validation of the off-chain data is part of the consensus rules and if the data is false, the block will be rejected by the network, which incentivizes the miner to be truthful. To achieve consensus, all nodes allow an error of about 1% in the reported data.

The value of the parameter is a 4 bit binary number converted to decimal. Each bit of the binary number has a specific meaning as explained below:

Let the 4 bit binary number be wxyz

w,x,y,z are bit4, bit3, bit2 and bit1 respectively

• if z = 1 : DTO is enabled and miners are required to add some data to the coinbase transaction's OP_RETURN
• if y = 1 : the data miners will write is prices of BTC vs fiat pairs viz., BTC_USD, BTC_GBP, BTC_EUR and Major fiat vs USD pairs
• if x = 1 : the data miners will write is prices of Cryptocurrencies included in the -ac_prices parameter
• if w = 1 : the data miners will write is prices of Stocks included in the -ac_stocks parameter

Examples

If we only want the prices for BTC vs fiat pairs and fiat vs USD pairs, we have (w=0,x=0,y=1,z=1) i.e., 0011 -> converted to decimal is 3; the value for the ac_cbopret parameter is 3 If we want the pairs from the above example and prices of the Cryptocurrencies included in the -ac_prices parameter, we have (w=0,x=1,y=1,z=1) i.e., 0111 -> converted to decimal is 7; the value for the ac_cbopret parameter is 7 If we just want the prices of the Stocks included in the -ac_stocks parameter, we have (w=1,x=0,y=0,z=1) i.e., 1001 -> converted to decimal is 9; the value for the ac_cbopret parameter is 9

ac_cc

The ac_cc parameter sets the network cluster on which the chain can interact with other chains via CryptoCondition modules and MoMoM technology.

Once activated, the ac_cc parameter can allow features such as cross-chain fungibility -- coins on one Smart Chain can be directly transferred to any other Smart Chain that has the same ac_cc setting and the same set of notary nodes (same set of notary pubkeys).

Most functionalities enabled by ac_cc can function with or without notarization service. However, cross-chain transaction validation and its dependent features, including cross-chain fungibility, require notarization.

If the ac_cc parameter is set to a value greater than 0 (i.e. CryptoCondition is permitted on the Smart Chain) users should include the -pubkey parameter when launching the daemon of this Smart Chain.

ac_cc=0

Setting ac_cc=0 disables CryptoCondition on the Smart Chain entirely.

TIP It is better to NOT use ac_cc=0 for a Smart Chain where CryptoCondition should not be enabled. Omitting the ac_cc parameter altogether will achieve the same result.

ac_cc=1

Setting ac_cc=1 permits CryptoCondition on the Smart Chain, but will not allow the Smart Chain to interact in cross-chain CryptoCondition functionality with other Smart Chains.

ac_cc=2 to 99

The values of 2 through 99 (inclusive) indicate Smart Chains that can validate transactions that occur on other Smart Chains on the same cluster (i.e. the same ac_cc value), but their coins are not fungible and therefore cannot be transferred between blockchains.

ac_cc=100 to 9999

Setting the value of ac_cc to any value greater than or equal to 100 will permit cross-chain interaction with any Smart Chain that has the same ac_cc value and is secured by notary nodes with the same pubkey.

All Smart Chains that have the same ac_cc (>= 100) value form a cluster, where the base tokens of all the chains in the cluster are fungible via the burn protocol.

For example, a Smart Chain set to ac_cc=201 in its parameters can interact with other Smart Chains with ac_cc=201 on the same notary-node network, but cannot interact with a Smart Chain set to ac_cc=301.

Summary of ac_cc

Consider a chain with -ac_cc=N

• If N = 0, CryptoCondition is disabled
• If N > 0, CryptoCondition is enabled
• If N = 1, on-chain CryptoCondition is active, cross-chain validation is disabled
• If N >= 2 and <= 99, the chain allows for cross-chain contracts between all other chains bearing the same N value. The base coins in each Smart Chain are non-fungible across chains.
• If N >= 100, the chain can form a cluster with all other chains with the same N value and on the same dPoW notarization network. The base coins of all chains in the cluster are fungible via the burn protocol.

Examples

A 555555 pre-mined chain with no CryptoCondition modules enabled. ./hushd -ac_name=HELLOWORLD -ac_supply=555555 &

A 555555 pre-mined chain with CryptoCondition modules on-chain only; no cross-chain CryptoCondition modules. ./hushd -ac_name=HELLOWORLD -ac_supply=555555 -ac_cc=1 &

A 555555 pre-mined chain where CryptoCondition modules are allowed between all fellow Smart Chains that have -ac_cc=2 in their launch parameters. However, the cross-chain burn protocol is not active, and therefore coins cannot be transferred between chains. ./hushd -ac_name=HELLOWORLD -ac_supply=555555 -ac_cc=2 &

A 555555 pre-mined chain. CryptoCondition modules are allowed between all fellow Smart Chains that have -ac_cc=102 in their launch parameters. Also, all -ac_cc=102 chains can use the cross-chain burn protocol to transfer coins from one chain to another. ./hushd -ac_name=HELLOWORLD -ac_supply=555555 -ac_cc=102 &

ac_ccactivate

-ac_ccactivate=block_height

The ac_ccactivate launch parameter allows for the activation of CryptoCondition on an existing Hush Smart Chain wherein CryptoCondition was not originally enabled.

Add the ac_ccactivate parameter to the existing launch command for the Smart Chain and set the value equal to a future block height. When this block height is reached, CryptoCondition will be available on the Smart Chain.

This change requires a hard fork of the Smart Chain. If the Smart Chain is receiving Hush's dPoW security service, the notary nodes must relaunch their Smart Chain daemons with the new launch parameter. All nodes must also update their daemons in the same manner.

By default, ac_ccactivate uses the default ac_cc value of ac_cc=2. It is not necessary to further specify ac_cc in the launch parameters, unless a value other than 2 is required.

Examples

Before Using ac_ccactivate ./hushd -ac_name=EXAMPLE -ac_supply=72000000 -addnode=1.2.3.4 &

After Using ac_ccactivate ./hushd -ac_name=EXAMPLE -ac_supply=72000000 -ac_ccactivate=140 -addnode=1.2.3.4 &

In this example, CryptoCondition will be available at blockheight 140. All nodes, include the notary nodes, must relaunch the daemon with the new parameters before blockheight 140.

ac_ccactivateht

Set the height for enabling cryptoconditions transactions. CC transactions before this height will be ignored. This can be used to enable CC's on a chain which was launched without having CC's enabled at the time of it's genesis block.

ac_ccenable

The ac_ccenable parameter restricts the Smart Chain so that only indicated CryptoCondition modules can be enabled. ac_ccenable requires ac_cc to be active.

To indicate which CryptoCondition modules should be available, insert each module's eval code in decimal and separated by commas.

The following table presents an abbreviated list of EVAL codes. For more information, please see this linked content.

Name of the module	EvalCode
IMPORTPAYOUT	225
IMPORTCOIN	226
ASSETS	227
FAUCET	228
REWARDS	229
DICE	230
FSM	231
AUCTION	232
LOTTO	233
HEIR	234
CHANNELS	235
ORACLES	236
PRICES	237
PEGS	238
TRIGGERS	239
PAYMENTS	240
GATEWAYS	241
TOKENS	242
IMPORTGATEWAYS	243

For example, the following parameters create a Smart Chain where only the faucet and rewards modules are active:

./hushd -ac_name=EXAMPLE -ac_supply=0 -ac_reward=100000000 -ac_cc=2 -ac_ccenable=228,229

When -ac_cc is set, but -ac_ccenable is not, all CryptoCondition modules are enabled.

WARNING ac_ccenable disables spending utxos that are created under a non-enabled CryptoCondition module. We have also implemented additional functionality that disables API functions. This prevents the user from creating a utxo that ac_ccenable would render unspendable. It is still possible to create raw transactions that bypass this security feature, and thus create utxos that are unspendable. A normal user or developer relying on our API functionality should not be concerned with this. However, those who experiment with raw transactions should be cautious.

WARNING If the developer is also using a new feature that has yet to be documented here, ac_cclib, the eval codes in the libcc.so will not disable CryptoCondition API calls. Therefore, there remains a risk that a disabled API call can still be used to create a utxo, which will then be non-spendable.

ac_cclib

The ac_cclib parameter is used in conjunction with various CryptoCondition modules.

Typically, the Smart Chain that uses the ac_cclib parameter will have a unique build process. This is described as a part of each CryptoCondition module in question. Once the Smart Chain is properly built, the terminal command to launch the chain will include the ac_cclib parameter in a manner similar to the following:

-ac_cclib=desired_CC_module

Each CryptoCondition module uses the ac_cclib parameter differently, and therefore the reader should refer to the desired CryptoCondition module for further instructions.

ac_decay

This is the percentage which determines the block reward decrease on each block-reward "halving".

This parameter will have no effect if ac_reward is not set.

This is the formula that ac_decay follows:

block_reward_after = block_reward_before * ac_decay / 100000000;

For example, if this parameter is set to 75000000, at each "halving" the block reward will drop to 75% of its previous value.

Examples

A 555555-coin pre-mine, with a 10-coin block reward, and the block reward decreases by 25% every 2000 blocks.

./hushd -ac_name=HELLOWORLD -ac_supply=555555 -ac_reward=1000000000 -ac_halving=2000 -ac_decay=75000000 &

ac_end

This is the block height at which block rewards will end. Every block after this height will have 0 block reward (this means that, assuming all other settings are default, the only incentive to mine a new block will be transaction fees).

Examples

A 555555-coin pre-mine, with a block reward of 0.0005 coin. The block reward ends at block 25000.

./hushd -ac_name=HELLOWORLD -ac_supply=555555 -ac_reward=50000 -ac_end=25000 &

A 555555-coin pre-mine, with a 5-coin block reward, and the block reward ends at block 200.

./hushd -ac_name=HELLOWORLD -ac_supply=555555 -ac_reward=500000000 -ac_end=200 &

A 555555-coin pre-mine, with a 5-coin block reward, the block reward decreases by 50% every 2000 blocks, and the block reward ends at block 10000.

./hushd -ac_name=HELLOWORLD -ac_supply=555555 -ac_reward=500000000 -ac_halving=2000 -ac_end=10000 &

ac_eras

The ac_eras parameter allows the value of a chain's block reward to vary over time.

Each different time interval is called an "era" and a chain can have at most seven eras.

ac_eras Combined With ac_cbmaturity

When active, ac_eras changes the behavior of coinbase coins (i.e., the coins that are created as a result of mining). ac_eras forces the COINBASE_MATURITY value of coinbase coins to be 100 instead of the normal value of 1. Therefore, coinbase coins become spendable after 100 confirmations.

This COINBASE_MATURITY value can be explicitly changed using the ac_cbmaturity parameter.

ac_eras Instructions

The ac_eras parameter accepts only one value. The value must be between 2 and 7, inclusive. When activated, ac_eras allows certain other Smart Chain parameters to accept multiple values.

The principle parameter that is affected by ac_eras is ac_reward. The ac_reward parameter must receive at least one value.

Also, ac_decay, ac_halving, ac_end, and ac_notarypay can each receive multiple values and thereby affect reward functionality.

For every era, there must be a corresponding value in ac_end that indicates the block height at which this era ends. To set the final era to last indefinitely, set the ac_end value of that era to 0; the 0 setting should only be used for the last era. If the last era's ac_end value is not 0, the chain's block rewards will stop after the final ac_end value, and every block after the final ac_end value will have no block reward.

In all parameters receiving multiple values, the values must be preceded by a comma.

For example:

./hushd -ac_name=HELLOWORLD -ac_supply=555555 -ac_eras=3 -ac_reward=5000000000,7000000000,4000000000 -ac_end=1000,10000,0

In this Smart Chain, the first era will have a reward of 5000000000, the second will have 7000000000, and the third will have 4000000000. The reward for the first era ends at block 1000, for the second era at block 10000, and the third era lasts indefinitely.

If any of the relevant parameters has fewer distinct values than eras, the parameter's final value will carry through the remaining eras.

For example:

-ac_eras=2 -ac_reward=100000000,200000000 -ac_halving=100 -ac_end=10000,0

In this Smart Chain, the ac_halving value for both eras is 100.

One more feature of ac_eras is the ability to transition from one era to the next with a linear progression, rather than a direct switch. To achieve this effect, in the initial era (the point at which the linear progression should begin) set the ac_decay value to 100000000 and the ac_halving value to 1.

For example, the following parameters create a Smart Chain with a "slow start" reward:

./hushd -ac_name=HELLOWORLD -ac_reward=0,10000000000 -ac_eras=2 -ac_end=1000,0 -ac_decay=100000000,100000000 -ac_halving=1

This chain's block reward will grow linearly from 0 to 100 over 1000 blocks, then stay at 100 indefinitely.

Tip Use the getblocksubsidy API method to verify your Smart Chain will work as expected at each relevant height: ./hush-cli -ac_name=HELLOWORLD getblocksubsidy <blockheight>

ac_founders

The ac_founders parameter creates a "founder's reward."

This parameter requires ac_perc. If the ac_perc value is not declared, the ac_founders value defaults to 35%. Also, either ac_pubkey OR ac_script must be set.

The ac_perc value determines the percentage of block rewards paid to the founder. These rewards are not paid out immediately, but rather according to the ac_founders setting.

ac_founders determines the frequency at which the founder's reward is paid.

For example:

-ac_reward=100000000 -ac_perc=10000000 -ac_founders=100

The above parameters result in mining rewards of 100000000 satoshis (1 coin) per block, with a difference on every 100th block. On the 100th block exception, 1000000000 additional satoshis (10 coins) are paid to the founder's address.

The coins rewarded to the founder are created at the moment of payment, thus increasing the overall coin supply. See ac_perc for more details.

Use ac_pubkey to send the founder's reward to a normal address.

Use ac_script to send the founder's reward to a multi-signature address.

Set ac_founders=1 to stay compatible with most stratum implementations. Any other value requires a team member's modifications to hnomp using the disable-cb feature. Please reach out to our team if you have further questions about how to set up a stratum.

ac_founders_reward

The ac_founders_reward parameter functions in a manner that is similar to a combination of the ac_perc and ac_founders parameters.

However, the value specified in the ac_founders_reward parameter is given in satoshis, as opposed to a percentage of the block reward. Also, the founder's reward does not accumulate over several blocks.

The ac_founders_reward parameter can be used in place of ac_perc.

The ac_founders_reward parameter must be used in combation with ac_founders and either ac_script or ac_pubkey.

The ac_founders_rewards value is entirely independent of the ac_reward value.

Consider the following combination of parameters, for example.

-ac_reward=1000000000 -ac_perc=10000000 -ac_founders=10 -ac_pubkey=034916536402c0c4cf53b05e3b5d948aacafede47df640b33cb89bd28179cd2d3f

This combination pays the pubkey address 10 coins every 10 blocks.

Compare the above to the following combination.

ac_reward=1000000000 -ac_founders_reward=100000000 -ac_founders=10 -ac_pubkey=034916536402c0c4cf53b05e3b5d948aacafede47df640b33cb89bd28179cd2d3f

This combination pays the pubkey address 1 coin every 10 blocks.

The ac_founders_reward parameter is not compatible with the ac_eras parameter.

Examples

A 555555-coin pre-mine, with a 5-coin block reward, and founder's reward of 10 coins sent to 034916536402c0c4cf53b05e3b5d948aacafede47df640b33cb89bd28179cd2d3f every 10 blocks.

./hushd -ac_name=HELLOWORLD -ac_supply=555555 -ac_reward=500000000 -ac_founders_reward=1000000000 -ac_founders=10 -ac_pubkey=034916536402c0c4cf53b05e3b5d948aacafede47df640b33cb89bd28179cd2d3f &

ac_halving

This is the number of blocks between each block reward halving. This parameter will have no effect if ac_reward is not set. The lowest possible value is 1440 (~1 day). If this parameter is set, but ac_decay is not, the reward will decrease by 50% each halving.

Examples

A 555555-coin pre-mine, with a 5-coin block reward, and the block reward decreases by 50% every 2000 blocks.

./hushd -ac_name=HELLOWORLD -ac_supply=555555 -ac_reward=500000000 -ac_halving=2000 &

ac_name

WARNING: All Smart Chains are required to set ac_name.

This is the ticker symbol for the coin you wish to create. We recommended it consist only of numbers and uppercase letters.

Examples

A simple Smart Chain

./hushd -ac_name=HELLOWORLD -ac_supply=555555 &

ac_perc

The ac_perc parameter has two different functionalities depending on the configuration of the chain parameters.

ac_perc without ac_founders

When ac_perc is used without -ac_founders the chain will follow an inflation-tax model. In this model, the -ac_perc parameter is the percentage added to the block reward, and the transactions that allocate these rewards are sent to the -ac_pubkey address. Naturally, for this configuration to function the -ac_pubkey parameter must be included.

For example, if -ac_reward=100000000 and -ac_perc=10000000, for each block mined the miner receives 100000000 satoshis (1 coin), and the owner of the -ac_pubkey address receives 10000000 satoshis (0.1 coin, which is 10% of the miner's reward). The amount sent to the pubkey is not taken from the user, rather it is created at this point. Therefore, each transaction inflates the overall coin supply.

The maximum amount of coins created via this method across all transactions per block is capped at (1000000 * <percentage>).

TIP Vout 1 of each coinbase transaction must be the correct amount sent to the corresponding pubkey. This only affects a miner trying to use a stratum. There is a coinbase-override method for this purpose. Please see this repo for details.

ac_perc with ac_founders

Please see the -ac_founders documentation for this functionality.

ac_prices

The ac_prices parameter has to be used along with the ac_cbopret parameter to supply TICKERS of the Cryptocurrencies whose BTC prices are to be included in the DTO.

Examples

A Smart Chain with a DTO that brings prices of various Cryptocurrencies vs BTC on-chain.

./hushd -ac_cbopret=5 -ac_name=HELLOWORLD -ac_cbopret=5 -ac_prices="ETH, LTC, BNB, NEO, LRC, QTUM, OMG, ZRX, STRAT, IOTA, XVG, KMD, EOS, ZEC, DASH, XRP, STORJ, XMR, BAT, BTS, LSK, ADA, WAVES, STEEM, RVN, DCR, XEM, ICX, HOT, ENJ" -ac_cc=10797 -ac_reward=3000000000 -ac_supply=120000000 -ac_pubkey=02d3431950c2f0f9654217b6ce3d44468d3a9ca7255741767fdeee7c5ec6b47567 -ac_perc=55555 -ac_blocktime=120 &

ac_private

If ac_private is set to 1, zk-SNARKS is enabled, and all z address functionality is enabled. Therefore, all transactions on the blockchain are private.

Examples

A Hush Smart Chain.

./hushd -ac_name=HELLOWORLD -ac_supply=555555 -ac_private=1 &

ac_pubkey

The ac_pubkey parameter designates a pubkey for receiving payments from the network. These payments can come in the genesis block, in all blocks mined thereafter, and from every transaction on the network.

This parameter is not intended for isolated use. It should only be activated on chains that also use at least one of the following parameters: ac_perc, ac_founders, or ac_import=PUBKEY.

The pubkey must be a 66 character string (a compressed pubkey). You can find this pubkey for any address by using the validateaddress command, and searching for the returned pubkey property. The first two digits of a compressed pubkey are only either 02 or 03. (The corresponding private key must be present/imported to the wallet before using validateaddress.)

ac_public

Hush does not support ac_public=1 chains as it is a platform for privacy!

ac_reward

WARNING: It is recommended that this parameter be included on all Hush Smart Chains. Please see below for additional notes.

This is the block reward for each mined block, given in satoshis.

If ac_reward is not set, the default block reward will be 10000 satoshis. It is recommended that ac_reward be included in all Hush Smart Chains. This prevents the Smart Chain from becoming an on-demand blockchain, and therefore this increases the Smart Chain's security.

To make a Smart Chain that has no block reward and is not on-demand, include the parameters: -ac_reward=1 -ac_end=1. The Smart Chain's first block will reward only the -ac_supply value, after which the ac_reward value will be 0.

Examples

A 555555 coin pre-mine, with a 1 coin block reward that does not end. (Note that ac_supply is given in coins, while ac_reward is given in satoshis.)

./hushd -ac_name=HELLOWORLD -ac_supply=555555 -ac_reward=100000000 &

A 0 coin pre-mine with a 1-coin block reward that does not end. This is an example of a pure PoW Smart Chain that has no pre-mined coins.

./hushd -ac_name=HELLOWORLD -ac_supply=0 -ac_reward=100000000 &

A 555555-coin pre-mine, with a 10-coin block reward, and the block reward decreases by 25% every 2000 blocks.

./hushd -ac_name=HELLOWORLD -ac_supply=555555 -ac_reward=1000000000 -ac_halving=2000 -ac_decay=75000000 &

ac_sapling

The ac_sapling parameter adjusts the block height of a Smart Chain's default sapling activation. (Sapling is an upstream privacy technology originally provided by Zcash, inheritted via Komodo, which Hush is a fork.)

By default, sapling will activate at block 1 on a newly created Smart Chain.

This can also be used to activate sapling at a different block height.

To delay sapling activation, set ac_sapling to a block height far in the future. For example, -ac_sapling=5000000 will delay sapling activation to block 5000000. At block 5000000 sapling will be activated.

ac_script

The ac_script parameter enables the ac_founders reward to be sent to a multi-signature address or any p2sh address. If this parameter is used, block 1 (the "premine") will be mined to the ac_script address.

This parameter requires that ac_founders also be active. If ac_script is set, ac_pubkey must not be.

ac_script should be set to the "hex" value of "scriptPubKey".

Finding the scriptPubKey

To find the "scriptPubKey" value, first create a multi-signature address with the createmultisig command.

Command

./hush-cli -ac_name=EXAMPLE createmultisig 2 "[\"RMnZJpfLbFHUxMS3HM5gkvtFKeduhr96Ec\",\"RW2Yx4Tk9WGfUvhbJTXGFiRhr7PKcVtrm5\",\"RQ1uqBj9yk94BcxEZodbeNqb3jWv8pLeA4\"]"

Response

{
  "address": "bGHcUFb7KsVbSFiwcBxRufkFiSuhqTnAaV",
  "redeemScript": "522102040ce30d52ff1faae7a673c2994ed0a2c4115a40fa220ce055d9b85e8f9311ef2102a2ba4606206c032914dd48390c15f5bf996d91bf9dbd07614d972f39d93a511321026014ef4194f6c7406a475a605d6a393ae2d7a2b12a6964587299bae84172fff053ae"
}

On a test chain, send coins to the bGHcUFb7KsVbSFiwcBxRufkFiSuhqTnAaV address.

Command

./hush-cli -ac_name=EXAMPLE sendtoaddress bGHcUFb7KsVbSFiwcBxRufkFiSuhqTnAaV 10

Response (txid)

ef0d05f14ea2a5bfa1c99142c2e3d78c851223d7476ed2e57b61b6e07f741f0f

Observe the resulting transaction with getrawtransaction <txid> 1.

Command

./hush-cli -ac_name=EXAMPLE getrawtransaction ef0d05f14ea2a5bfa1c99142c2e3d78c851223d7476ed2e57b61b6e07f741f0f 1

Response

{
  "value": 10.0,
  "valueSat": 1000000000,
  "n": 1,
  "scriptPubKey": {
    "asm": "OP_HASH160 2706324daaac92c93420e985f55d88ea20e22ae1 OP_EQUAL",
    "hex": "a9142706324daaac92c93420e985f55d88ea20e22ae187",
    "reqSigs": 1,
    "type": "scripthash",
    "addresses": ["bGHcUFb7KsVbSFiwcBxRufkFiSuhqTnAaV"]
  }
}

Set ac_script to the "hex" value from the returned json object.

Command

-ac_script=a9142706324daaac92c93420e985f55d88ea20e22ae187

ac_stocks

The ac_stocks parameter has to be used along with the ac_cbopret parameter to supply TICKERS of the Stocks (available at https://api.iextrading.com/1.0/tops/last (opens new window)) whose USD prices are to be included in the DTO.

Examples

A Smart Chain with a DTO that brings prices of various Stocks vs USD on-chain.

./hushd -ac_cbopret=9 -ac_name=HELLOWORLD -ac_cbopret=9 -ac_stocks="AAPL,ADBE,ADSK,AKAM,AMD,AMZN,ATVI,BB,CDW,CRM,CSCO,CYBR,DBX,EA,FB,GDDY,GOOG,GRMN,GSAT,HPQ,IBM,INFY,INTC,INTU,JNPR,MSFT,MSI,MU,MXL,NATI,NCR,NFLX,NTAP,NVDA,ORCL,PANW,PYPL,QCOM,RHT,S,SHOP,SNAP,SPOT,SYMC,SYNA,T,TRIP,TWTR,TXN,VMW,VOD,VRSN,VZ,WDC,XRX,YELP,YNDX,ZEN,BRK.A" -ac_cc=10797 -ac_reward=3000000000 -ac_supply=120000000 -ac_pubkey=02d3431950c2f0f9654217b6ce3d44468d3a9ca7255741767fdeee7c5ec6b47567 -ac_perc=55555 -ac_blocktime=120 &

ac_supply

This is the amount of pre-mined coins you would like the chain to have.

The node that sets gen during the creation process will mine these coins in the genesis block.

If ac_supply is not set, ac_reward must be set, and a default value of 10 coins will be used in the genesis block. If ac_founders is set, the pre-mined coins will be mined to the founder's reward address.

The ac_supply parameter should be set to a whole number without any decimals places. It should also be set to less than 2000000000 to avoid 64-bit overflows.

TIP An additional fraction of a coin will be added to the initial supply based on the Smart Chain's parameters. This is used by nodes to verify the genesis block. For example, the DEX chain's ac_supply parameter is set to 999999, but in reality the genesis block was 999999.13521376.

Examples

A simple Smart Chain with pre-mined coins and a block reward of 0.0005.

./hushd -ac_name=HELLOWORLD -ac_supply=555555 -ac_reward=50000 &

ac_snapshot

The ac_snapshot parameter defines the frequency with which a Smart Chain creates snapshots of the address - balance data.

Example

The following example instructs the Smart Chain to execute a snapshot once every 1440 blocks. (Approximately one snapshot per day.)

-ac_snapshot=1440

Payments Module Functionality

The ac_snapshot parameter is required by the paymentsairdrop method of the Payments CryptoCondition Module.

The user first executes the paymentsairdrop method to create a Payments plan that is designed to distribute airdrops to addresses on the chain.

The user then executes the paymentsrelease method to release payments based on the amounts in the addresses in the most recent snapshot, as recorded by the ac_snapshot customization.

The Payments Module features several customizations to control the nature of these automated airdrops.

ac_txpow

Setting -ac_txpow=1 enforces a transaction-rate limiter. This can help to prevent spam transactions on a Smart Chain.

ac_txpow forces all transactions (other than coinbase transactions) to have a txid starting and ending with 00.

This parameter is currently a proof of concept. Many of the traditional API commands, such as sendtoaddress or sendmany, are not currently supported. Instead, use createrawtransaction and signrawtransaction.

Reference

To learn more about the origin of CryptoConditions, please refer to this IETF documentation here.