DanS
46693a355a
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>
94 lines
5.5 KiB
Markdown
94 lines
5.5 KiB
Markdown
# Security Warnings
|
||
|
||
## Security Audits
|
||
|
||
DragonX has not been subjected to a formal third-party security review. Some of
|
||
the Bitcoin, Zcash, Komodo, and Hush source code it is derived from has been
|
||
audited upstream, and DragonX integrates relevant fixes and recommendations from
|
||
those audits where they apply.
|
||
|
||
## Wallet Encryption
|
||
|
||
Wallet encryption is disabled by default, for several reasons. (It can be
|
||
enabled by running with both `-experimentalfeatures` and
|
||
`-developerencryptwallet`, but this is not recommended for the reasons below.)
|
||
|
||
- Encrypted wallets are unable to correctly detect shielded spends (due to the
|
||
nature of unlinkability of ShieldedSpends) and can incorrectly show larger
|
||
available shielded balances until the next time the wallet is unlocked. This
|
||
problem was not limited to failing to recognize the spend; it was possible for
|
||
the shown balance to increase by the amount of change from a spend, without
|
||
deducting the spent amount.
|
||
|
||
- While encrypted wallets prevent spending of funds, they do not maintain the
|
||
shielding properties of ShieldedOutputs (due to the need to detect spends). That
|
||
is, someone with access to an encrypted wallet.dat has full visibility of
|
||
your entire transaction graph (other than newly-detected spends, which suffer
|
||
from the earlier issue).
|
||
|
||
- We were concerned about the resistance of the algorithm used to derive wallet
|
||
encryption keys (inherited from [Bitcoin](https://bitcoin.org/en/secure-your-wallet))
|
||
to dictionary attacks by a powerful attacker. If and when we re-enable wallet
|
||
encryption, it is likely to be with a modern passphrase-based key derivation
|
||
algorithm designed for greater resistance to dictionary attack, such as Argon2i.
|
||
|
||
You should use full-disk encryption (or encryption of your home directory) to
|
||
protect your wallet at rest, and should assume (even unprivileged) users who are
|
||
running on your OS can read your wallet.dat file.
|
||
|
||
## Side-Channel Attacks
|
||
|
||
This implementation of DragonX is not resistant to side-channel attacks. You
|
||
should assume (even unprivileged) users who are running on the hardware, or who
|
||
are physically near the hardware, that your `dragonxd` process is running on will
|
||
be able to:
|
||
|
||
- Determine the values of your secret spending keys, as well as which notes you
|
||
are spending, by observing cache side-channels as you perform a ShieldedSpend
|
||
operation. This is due to probable side-channel leakage in C++.
|
||
|
||
- Determine which notes you own by observing cache side-channel information
|
||
leakage from the incremental witnesses as they are updated with new notes.
|
||
|
||
- Determine which notes you own by observing the trial decryption process of
|
||
each note ciphertext on the blockchain.
|
||
|
||
You should ensure no other users have the ability to execute code (even
|
||
unprivileged) on the hardware your `dragonxd` process runs on until these
|
||
vulnerabilities are fully analyzed and fixed.
|
||
|
||
## REST Interface
|
||
|
||
The REST interface is a feature inherited from upstream Bitcoin. By default,
|
||
it is disabled. We do not recommend you enable it until it has undergone a
|
||
security review.
|
||
|
||
## RPC Interface
|
||
|
||
Users should choose a strong RPC password. If no RPC username and password are set, dragonxd will not start and will print an error message with a suggestion for a strong random password. If the client knows the RPC password, they have at least full access to the node. In addition, certain RPC commands can be misused to overwrite files and/or take over the account that is running dragonxd. (In the future we may restrict these commands, but full node access – including the ability to spend from and export keys held by the wallet – would still be possible unless wallet methods are disabled.)
|
||
|
||
Users should also refrain from changing the default setting that only allows RPC connections from localhost. Allowing connections from remote hosts would enable a MITM to execute arbitrary RPC commands, which could lead to compromise of the account running dragonxd and loss of funds. For multi-user services that use one or more dragonxd instances on the backend, the parameters passed in by users should be controlled to prevent confused-deputy attacks which could spend from any keys held by that dragonxd.
|
||
|
||
## Block Chain Reorganization
|
||
|
||
DragonX inherits Komodo's Delayed-Proof-of-Work (dPoW) notarization code from its
|
||
Hush lineage. Note that DragonX does not currently run its own notary
|
||
infrastructure, so you should not assume active dPoW reorg protection. Treat deep
|
||
reorganizations as possible and wait for sufficient confirmations accordingly.
|
||
|
||
## Logging z_* RPC calls
|
||
|
||
The option `-debug=zrpc` covers logging of the z_* calls. This will reveal information about private notes which you might prefer not to disclose. For example, when calling `z_sendmany` to create a shielded transaction, input notes are consumed and new output notes are created.
|
||
|
||
The option `-debug=zrpcunsafe` covers logging of sensitive information in z_* calls which you would only need for debugging and audit purposes. For example, if you want to examine the memo field of a note being spent.
|
||
|
||
Private spending keys for z addresses are never logged.
|
||
|
||
## Potentially-Missing Required Modifications
|
||
|
||
In addition to potential mistakes in code we added to Bitcoin Core, Zcash
|
||
and Komodo and potential mistakes in our modifications to Bitcoin Core, Zcash and Komodo, it is also possible
|
||
that there were potential changes we were supposed to make to Bitcoin Core, Zcash and Komodo but
|
||
didn't, either because we didn't even consider making those changes or have not found out about
|
||
them. Patches Welcome!
|