docs: rebrand documentation, packaging, and helper scripts to DragonX
The docs/packaging were largely un-rebranded Hush3 content, with several docs stating facts that are wrong for DragonX. This rewrites them against the verified DragonX source state. Corrections (not just branding): - PoW: RandomX (CPU), not Equihash/ASIC — README, overview.md, randomx.md - Privacy: private from genesis (ac_private=1, Sapling@height1), not "as of block 340000" — overview.md, payment-api.md - Removed the false "coinbase must be shielded" consensus claim (shield-coinbase.md, payment-api.md); coinbase is directly spendable - Fixed default fee 0.0001 (was 0.0010000, 10x); stratum port 22769 (was 19031) - datadir ~/.hush/DRAGONX, DRAGONX.conf, dragonxd/dragonx-cli/dragonx-tx, git.dragonx.is throughout; branch model dev->dragonx - Softened the inherited dPoW reorg claim (no live DragonX notary infra) Packaging: fix build-debian-package.sh + gen-manpages.sh to use the dragonx binaries/manpages; rename bash-completions to dragonx*; drop hush-arrakis-chain from the package. Keep /usr/share/hush (hardcoded in the binary for params). Also: README links/logo, ObsidianDragon + SilentDragonXAndroid wallets, networking/init/dev-process/contrib/util rebrand, and leftover helper scripts. Delete legacy duplicates (hushd.* init/service, HUSH3.conf examples, OLD_WALLETS.md, hsc.md) and rename hush-uri.bat -> dragonx-uri.bat. Out of scope (noted, not changed): historical changelog/copyright, the Hush mainnet airdrop snapshot, seed data files, depends/ source mirrors, and the in-code strCurrencyUnits="HUSH". Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -2,55 +2,69 @@
|
||||
|
||||
**Summary**
|
||||
|
||||
Use `z_shieldcoinbase` RPC call to shield coinbase UTXOs.
|
||||
Use the `z_shieldcoinbase` RPC call to move mining coinbase UTXOs into the shielded pool.
|
||||
|
||||
**Who should read this document**
|
||||
|
||||
Miners, Mining pools, Online wallets
|
||||
Miners, mining pools, online wallets.
|
||||
|
||||
## Background
|
||||
|
||||
The current Hush protocol includes a consensus rule that coinbase rewards must be sent to a shielded address.
|
||||
DragonX is a fully private chain from genesis (`ac_private=1`, Sapling active at
|
||||
height 1). All ordinary payments are shielded (`z2z`) and transparent addresses can
|
||||
never be transaction recipients — they only ever receive mining coinbase.
|
||||
|
||||
There is **no** consensus rule that coinbase must be shielded: mature coinbase is
|
||||
directly spendable. `z_shieldcoinbase` is therefore an optional convenience for
|
||||
miners who want to move coinbase into the shielded pool for privacy, and to sweep
|
||||
up many small coinbase UTXOs in a single operation. See
|
||||
[hd-transparent-keys.md](hd-transparent-keys.md) for how transparent coinbase keys
|
||||
work on a private chain.
|
||||
|
||||
## User Experience Challenges
|
||||
|
||||
A user can use the z_sendmany RPC call to shield coinbase funds, but the call was not designed for sweeping up many UTXOs, and offered a suboptimal user experience.
|
||||
A user can use the `z_sendmany` RPC call to shield coinbase funds, but that call was
|
||||
not designed for sweeping up many UTXOs and offers a suboptimal experience.
|
||||
|
||||
If customers send mining pool payouts to their online wallet, the service provider must sort through UTXOs to correctly determine the non-coinbase UTXO funds that can be withdrawn or transferred by customers to another transparent address.
|
||||
If customers send mining pool payouts to their online wallet, the service provider
|
||||
must sort through UTXOs to correctly determine the non-coinbase UTXO funds that can be
|
||||
withdrawn or transferred by customers.
|
||||
|
||||
## Solution
|
||||
|
||||
The z_shieldcoinbase call makes it easy to sweep up coinbase rewards from multiple coinbase UTXOs across multiple coinbase reward addresses.
|
||||
The `z_shieldcoinbase` call makes it easy to sweep up coinbase rewards from multiple
|
||||
coinbase UTXOs across multiple coinbase reward addresses.
|
||||
|
||||
z_shieldcoinbase fromaddress toaddress (fee) (limit)
|
||||
|
||||
The default fee is 0.0010000 HUSH and the default limit on the maximum number of UTXOs to shield is 50.
|
||||
The default fee is 0.0001 DRAGONX and the default limit on the maximum number of UTXOs
|
||||
to shield is 50.
|
||||
|
||||
## Examples
|
||||
|
||||
Sweep up coinbase UTXOs from a transparent address you use for mining:
|
||||
|
||||
hush-cli z_shieldcoinbase tMyMiningAddress zMyPrivateAddress
|
||||
dragonx-cli z_shieldcoinbase RMyMiningAddress zsMyPrivateAddress
|
||||
|
||||
Sweep up coinbase UTXOs from multiple transparent addresses to a shielded address:
|
||||
|
||||
hush-cli z_shieldcoinbase "*" zMyPrivateAddress
|
||||
dragonx-cli z_shieldcoinbase "*" zsMyPrivateAddress
|
||||
|
||||
Sweep up with a fee of 1.23 HUSH:
|
||||
Sweep up with a fee of 1.23 DRAGONX:
|
||||
|
||||
hush-cli z_shieldcoinbase tMyMiningAddress zMyPrivateAddress 1.23
|
||||
dragonx-cli z_shieldcoinbase RMyMiningAddress zsMyPrivateAddress 1.23
|
||||
|
||||
Sweep up with a fee of 0.1 HUSH and set limit on the maximum number of UTXOs to shield at 25:
|
||||
Sweep up with a fee of 0.1 DRAGONX and set limit on the maximum number of UTXOs to shield at 25:
|
||||
|
||||
hush-cli z_shieldcoinbase "*" zMyPrivateAddress 0.1 25
|
||||
dragonx-cli z_shieldcoinbase "*" zsMyPrivateAddress 0.1 25
|
||||
|
||||
### Asynchronous Call
|
||||
|
||||
The `z_shieldcoinbase` RPC call is an asynchronous call, so you can queue up multiple operations.
|
||||
The `z_shieldcoinbase` RPC call is an asynchronous call, so you can queue up multiple operations.
|
||||
|
||||
When you invoke
|
||||
|
||||
hush-cli z_shieldcoinbase tMyMiningAddress zMyPrivateAddress
|
||||
dragonx-cli z_shieldcoinbase RMyMiningAddress zsMyPrivateAddress
|
||||
|
||||
JSON will be returned immediately, with the following data fields populated:
|
||||
|
||||
@@ -70,13 +84,13 @@ You can use the RPC call `lockunspent` to see which UTXOs have been locked. You
|
||||
|
||||
The number of coinbase UTXOs selected for shielding can be adjusted by setting the limit parameter. The default value is 50.
|
||||
|
||||
If the limit parameter is set to zero, the zcashd `mempooltxinputlimit` option will be used instead, where the default value for `mempooltxinputlimit` is zero, which means no limit.
|
||||
If the limit parameter is set to zero, the `mempooltxinputlimit` option will be used instead, where the default value for `mempooltxinputlimit` is zero, which means no limit.
|
||||
|
||||
Any limit is constrained by a hard limit due to the consensus rule defining a maximum transaction size.
|
||||
|
||||
In general, the more UTXOs that are selected, the longer it takes for the transaction to be verified. Due to the quadratic hashing problem, some miners use the `mempooltxinputlimit` option to reject transactions with a large number of UTXO inputs.
|
||||
|
||||
Currently, as of November 2017, there is no commonly agreed upon limit, but as a rule of thumb (a form of emergent consensus) if a transaction has less than 100 UTXO inputs, the transaction will be mined promptly by the majority of mining pools, but if it has many more UTXO inputs, such as 500, it might take several days to be mined by a miner who has higher or no limits.
|
||||
As a rule of thumb (a form of emergent consensus) if a transaction has less than 100 UTXO inputs, the transaction will be mined promptly by the majority of mining pools, but if it has many more UTXO inputs, such as 500, it might take longer to be mined by a miner who has higher or no limits.
|
||||
|
||||
### Anatomy of a z_shieldcoinbase transaction
|
||||
|
||||
|
||||
Reference in New Issue
Block a user