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:
34
doc/i2p.md
34
doc/i2p.md
@@ -1,6 +1,6 @@
|
||||
# I2P support in Hush
|
||||
# I2P support in DragonX
|
||||
|
||||
It is possible to run a Hush or HSC full node as an
|
||||
It is possible to run a DragonX full node as an
|
||||
[I2P (Invisible Internet Project)](https://en.wikipedia.org/wiki/I2P)
|
||||
service and connect to such services.
|
||||
|
||||
@@ -42,13 +42,13 @@ configuration options:
|
||||
In a typical situation, this suffices:
|
||||
|
||||
```
|
||||
hushd -i2psam=127.0.0.1:7656
|
||||
dragonxd -i2psam=127.0.0.1:7656
|
||||
```
|
||||
|
||||
The first time hushd connects to the I2P router, if
|
||||
The first time dragonxd connects to the I2P router, if
|
||||
`-i2pacceptincoming=1`, then it will automatically generate a persistent I2P
|
||||
address and its corresponding private key. The private key will be saved in a
|
||||
file named `i2p_private_key` in the Hush data directory. The persistent
|
||||
file named `i2p_private_key` in the DragonX data directory. The persistent
|
||||
I2P address is used for accepting incoming connections and for making outgoing
|
||||
connections if `-i2pacceptincoming=1`. If `-i2pacceptincoming=0` then only
|
||||
outbound I2P connections are made and a different transient I2P address is used
|
||||
@@ -71,8 +71,8 @@ Make automatic outbound connections only to I2P addresses. Inbound and manual
|
||||
connections are not affected by this option. It can be specified multiple times
|
||||
to allow multiple networks, e.g. onlynet=onion, onlynet=i2p.
|
||||
|
||||
I2P support was added to Hush in version 3.9.3 and there may be fewer I2P
|
||||
peers than Tor or IP ones. Therefore, using I2P alone without other networks may
|
||||
There may be fewer I2P peers than Tor or IP ones. Therefore, using I2P alone
|
||||
without other networks may
|
||||
make a node more susceptible to [Sybil
|
||||
attacks](https://en.bitcoin.it/wiki/Weaknesses#Sybil_attack).
|
||||
|
||||
@@ -91,7 +91,7 @@ connection initiator. This is unlike the Tor network where the recipient does
|
||||
not know who is connecting to them and can't tell if two connections are from
|
||||
the same peer or not.
|
||||
|
||||
If an I2P node is not accepting incoming connections, then Hush uses
|
||||
If an I2P node is not accepting incoming connections, then DragonX uses
|
||||
random, one-time, transient I2P addresses for itself for outbound connections
|
||||
to make it harder to discriminate, fingerprint or analyze it based on its I2P
|
||||
address.
|
||||
@@ -104,35 +104,35 @@ incoming I2P connections (`-i2pacceptincoming`):
|
||||
- in the debug log (grep for `AddLocal`; the I2P address ends in `.b32.i2p`)
|
||||
- in the i2p/i2pd web console under "SAM Sessions"
|
||||
|
||||
To see which I2P peers your node is connected to, use `hush-cli getpeerinfo`
|
||||
To see which I2P peers your node is connected to, use `dragonx-cli getpeerinfo`
|
||||
RPC.
|
||||
|
||||
## Compatibility
|
||||
|
||||
Hush uses the [SAM v3.1](https://geti2p.net/en/docs/api/samv3) protocol
|
||||
DragonX uses the [SAM v3.1](https://geti2p.net/en/docs/api/samv3) protocol
|
||||
to connect to the I2P network. Any I2P router that supports it can be used.
|
||||
|
||||
## Ports in I2P and Hush
|
||||
## Ports in I2P and DragonX
|
||||
|
||||
Hush uses the [SAM v3.1](https://geti2p.net/en/docs/api/samv3)
|
||||
DragonX uses the [SAM v3.1](https://geti2p.net/en/docs/api/samv3)
|
||||
protocol. One particularity of SAM v3.1 is that it does not support ports,
|
||||
unlike newer versions of SAM (v3.2 and up) that do support them and default the
|
||||
port numbers to 0. From the point of view of peers that use newer versions of
|
||||
SAM or other protocols that support ports, a SAM v3.1 peer is connecting to them
|
||||
on port 0, from source port 0.
|
||||
|
||||
To allow future upgrades to newer versions of SAM, Hush sets its
|
||||
To allow future upgrades to newer versions of SAM, DragonX sets its
|
||||
listening port to 0 when listening for incoming I2P connections and advertises
|
||||
its own I2P address with port 0. Furthermore, it will not attempt to connect to
|
||||
I2P addresses with a non-zero port number because with SAM v3.1 the destination
|
||||
port (`TO_PORT`) is always set to 0 and is not in the control of Hush.
|
||||
port (`TO_PORT`) is always set to 0 and is not in the control of DragonX.
|
||||
|
||||
## Bandwidth
|
||||
|
||||
By default, your node shares bandwidth and transit tunnels with the I2P network
|
||||
in order to increase your anonymity with cover traffic, help the I2P router used
|
||||
by your node integrate optimally with the network, and give back to the network.
|
||||
It's important that the nodes of a popular application like Hush contribute
|
||||
It's important that the nodes of a popular application like DragonX contribute
|
||||
as much to the I2P network as they consume.
|
||||
|
||||
It is possible, though strongly discouraged, to change your I2P router
|
||||
@@ -159,7 +159,7 @@ in [Embedding I2P in your Application](https://geti2p.net/en/docs/applications/e
|
||||
|
||||
In most cases, the default router settings should work fine.
|
||||
|
||||
## Bundling I2P in a Hush application
|
||||
## Bundling I2P in a DragonX application
|
||||
|
||||
Please see the "General Guidance for Developers" section in https://geti2p.net/en/docs/api/samv3
|
||||
if you are developing a downstream application that may be bundling I2P with Hush.
|
||||
if you are developing a downstream application that may be bundling I2P with DragonX.
|
||||
|
||||
Reference in New Issue
Block a user