3 changed files with 612 additions and 2 deletions
@ -0,0 +1,609 @@ |
|||
# 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. |
|||
|
|||
To enable randomX algorithm, set `-ac_algo=randomx`. |
|||
|
|||
<!---another example of different equihash algo --> |
|||
|
|||
Default for Hush mainnet is Equihash (200,9). |
|||
|
|||
## 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=777777 -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 Antara 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 Antara 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. Antara 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 Antara on the Smart Chain entirely. |
|||
|
|||
TIP |
|||
It is better to NOT use `ac_cc=0` for a Smart Chain where Antara should not be enabled. Omitting the `ac_cc` parameter altogether will achieve the same result. |
|||
|
|||
### ac_cc=1 |
|||
Setting `ac_cc=1` permits Antara on the Smart Chain, but will not allow the Smart Chain to interact in cross-chain Antara 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, Antara is disabled |
|||
* If N > 0, Antara is enabled |
|||
* If N = 1, on-chain Antara 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 777777 pre-mined chain with no Antara modules enabled. |
|||
`./hushd -ac_name=HELLOWORLD -ac_supply=777777 &` |
|||
|
|||
A 777777 pre-mined chain with Antara modules on-chain only; no cross-chain Antara modules. |
|||
`./hushd -ac_name=HELLOWORLD -ac_supply=777777 -ac_cc=1 &` |
|||
|
|||
A 777777 pre-mined chain where Antara 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=777777 -ac_cc=2 &` |
|||
|
|||
A 777777 pre-mined chain. Antara 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=777777 -ac_cc=102 &` |
|||
|
|||
## ac_ccactivate |
|||
|
|||
-ac_ccactivate=block_height |
|||
|
|||
The `ac_ccactivate` launch parameter allows for the activation of Antara on an existing Hush Smart Chain wherein Antara 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, Antara 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=24.54.206.138 &` |
|||
|
|||
After Using `ac_ccactivate` |
|||
`./hushd -ac_name=EXAMPLE -ac_supply=72000000 -ac_ccactivate=140 -addnode=24.54.206.138 &` |
|||
|
|||
In this example, Antara will be available at blockheight `140`. All nodes, include the notary nodes, must relaunch the daemon with the new parameters before blockheight `140`. |
|||
|
|||
## ac_ccenable |
|||
|
|||
The `ac_ccenable` parameter restricts the Smart Chain so that only indicated Antara modules can be enabled. `ac_ccenable` requires ac_cc to be active. |
|||
|
|||
To indicate which Antara 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](https://git.hush.is/hush/hush3/src/branch/master/src/cc/eval.h#L43). |
|||
|
|||
| 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 Antara modules are enabled. |
|||
|
|||
**WARNING** |
|||
`ac_ccenable` disables spending utxos that are created under a non-enabled Antara 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 Antara 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 Antara 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 Antara 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 Antara module uses the `ac_cclib` parameter differently, and therefore the reader should refer to the desired Antara 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 777777-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=777777 -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 777777-coin pre-mine, with a block reward of 0.0005 coin. The block reward ends at block 25000. |
|||
|
|||
`./hushd -ac_name=HELLOWORLD -ac_supply=777777 -ac_reward=50000 -ac_end=25000 &` |
|||
|
|||
A 777777-coin pre-mine, with a 5-coin block reward, and the block reward ends at block 200. |
|||
|
|||
`./hushd -ac_name=HELLOWORLD -ac_supply=777777 -ac_reward=500000000 -ac_end=200 &` |
|||
|
|||
A 777777-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=777777 -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=777777 -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](https://git.hush.is/hush/hnomp#disable-coinbase-mode). 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 777777-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=777777 -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 777777-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=777777 -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=777777 &` |
|||
|
|||
## 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](https://git.hush.is/hush/hnomp#disable-coinbase-mode) for details. |
|||
|
|||
### ac_perc with ac_founders |
|||
Please see the -ac_founders documentation for this functionality. |
|||
|
|||
### Examples |
|||
|
|||
<!--- Need example without PoS... --> |
|||
|
|||
## 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=77777 -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=777777 -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`.) |
|||
|
|||
### Examples |
|||
|
|||
<!--- Need example without PoS... --> |
|||
|
|||
## 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 777777 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=777777 -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 777777-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=777777 -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 61 on a newly created Smart Chain. |
|||
|
|||
This can also be used to activate sapling prior to block 61. (Activating sapling prior to block 61 should not be done on a chain intended for production use.) |
|||
|
|||
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=77777 -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=777777 -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 Antara 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_timelock... |
|||
|
|||
`-ac_timeunlockgte=satoshis -ac_timelockfrom=height -ac_timelockto=height` |
|||
|
|||
The `ac_timelock`... parameters enforce "coinbase locking". |
|||
|
|||
In coinbase locking, the Smart Chain's block-reward feature behaves in a different manner compared to a default Smart Chain. Any block reward that is greater than or equal to the `ac_timeunlockgte` satoshi amount is temporarily locked. It will be unlocked (and therefore spendable) on a random block between the `ac_timelockfrom` and `ac_timelockto` heights. |
|||
|
|||
The random unlock time for each reward is independent of the unlock time of other rewards. |
|||
|
|||
For example: |
|||
|
|||
`./hushd -ac_name=HELLOWORLD -ac_supply=0 -ac_reward=10000000000 -ac_halving=10000 -ac_timelockgte=10000000000 -ac_timeunlockfrom=10000 -ac_timeunlockto=100000` |
|||
|
|||
For the first 10000 blocks, any rewards that are greater than or equal to 10000000000 are locked until a random block between 10000 and 100000. |
|||
|
|||
### also found these in the code... |
|||
-ac_timeunlockfrom |
|||
-ac_timeunlockto |
|||
|
|||
# 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. |
|||
|
|||
# Other |
|||
|
|||
Found these other parameters in hush_utils.h not present in other docs... |
|||
|
|||
## ac_peg |
|||
|
|||
It's in code [here](https://git.hush.is/hush/hush3/src/branch/master/src/cc/pegs.cpp#L26). I first found `-ac_import` which led me to peg... and `-ac_pegsccparams` |
|||
|
|||
## misc |
|||
|
|||
-ac_nk |
|||
-ac_ccactivateht |
|||
-ac_beam |
|||
-ac_coda |
|||
-ac_mineropret |
|||
-ac_overwinter" |
|||
|
|||
|
After Width: | Height: | Size: 37 KiB |
Loading…
Reference in new issue