mirror of
https://git.hush.is/hush/hush3.git
synced 2025-07-25 00:02:00 -04:00
Compare commits
12 Commits
37cff3924d
...
2bb9f87624
Author | SHA1 | Date | |
---|---|---|---|
|
2bb9f87624 | ||
|
002df24056 | ||
|
bd7f04ee57 | ||
|
dcbdafdba5 | ||
|
f5f52a7e81 | ||
|
87642c4895 | ||
|
5363c7cfb7 | ||
|
4887fa6447 | ||
|
4bd4664917 | ||
|
d779578ab9 | ||
|
d0c3d7587e | ||
|
ad653d6271 |
115
doc/cjdns.md
Normal file
115
doc/cjdns.md
Normal file
@ -0,0 +1,115 @@
|
||||
# CJDNS support in Hush
|
||||
|
||||
It is possible to run Hush over CJDNS, an encrypted IPv6 network that
|
||||
uses public-key cryptography for address allocation and a distributed hash table
|
||||
for routing.
|
||||
|
||||
## What is CJDNS?
|
||||
|
||||
CJDNS is like a distributed, shared VPN with multiple entry points where every
|
||||
participant can reach any other participant. All participants use addresses from
|
||||
the `fc00::/8` network (reserved IPv6 range). Installation and configuration is
|
||||
done outside of Hush, similarly to a VPN (either in the host/OS or on
|
||||
the network router). See https://github.com/cjdelisle/cjdns#readme and
|
||||
https://github.com/hyperboria/docs#hyperboriadocs for more information.
|
||||
|
||||
Compared to IPv4/IPv6, CJDNS provides end-to-end encryption and protects nodes
|
||||
from traffic analysis and filtering.
|
||||
|
||||
Used with Tor and I2P, CJDNS is a complementary option that can enhance network
|
||||
redundancy and robustness for both the Hush network and individual nodes.
|
||||
|
||||
Each network has different characteristics. For instance, Tor is widely used but
|
||||
somewhat centralized. I2P connections have a source address and I2P is slow.
|
||||
CJDNS is fast but does not hide the sender and the recipient from intermediate
|
||||
routers.
|
||||
|
||||
## Installing CJDNS and finding a peer to connect to the network
|
||||
|
||||
To install and set up CJDNS, follow the instructions at
|
||||
https://github.com/cjdelisle/cjdns#how-to-install-cjdns.
|
||||
|
||||
You need to initiate an outbound connection to a peer on the CJDNS network
|
||||
before it will work with your Hush node. This is described in steps
|
||||
["2. Find a friend"](https://github.com/cjdelisle/cjdns#2-find-a-friend) and
|
||||
["3. Connect your node to your friend's
|
||||
node"](https://github.com/cjdelisle/cjdns#3-connect-your-node-to-your-friends-node)
|
||||
in the CJDNS documentation.
|
||||
|
||||
One quick way to accomplish these two steps is to query for available public
|
||||
peers on [Hyperboria](https://github.com/hyperboria) by running the following:
|
||||
|
||||
```
|
||||
git clone https://github.com/hyperboria/peers hyperboria-peers
|
||||
cd hyperboria-peers
|
||||
./testAvailable.py
|
||||
```
|
||||
|
||||
For each peer, the `./testAvailable.py` script prints the filename of the peer's
|
||||
credentials followed by the ping result.
|
||||
|
||||
Choose one or several peers, copy their credentials from their respective files,
|
||||
paste them into the relevant IPv4 or IPv6 "connectTo" JSON object in the
|
||||
`cjdroute.conf` file you created in step ["1. Generate a new configuration
|
||||
file"](https://github.com/cjdelisle/cjdns#1-generate-a-new-configuration-file),
|
||||
and save the file.
|
||||
|
||||
## Launching CJDNS
|
||||
|
||||
Typically, CJDNS might be launched from its directory with
|
||||
`sudo ./cjdroute < cjdroute.conf` and it sheds permissions after setting up the
|
||||
[TUN](https://en.wikipedia.org/wiki/TUN/TAP) interface. You may also [launch it as an
|
||||
unprivileged user](https://github.com/cjdelisle/cjdns/blob/master/doc/non-root-user.md)
|
||||
with some additional setup.
|
||||
|
||||
The network connection can be checked by running `./tools/peerStats` from the
|
||||
CJDNS directory.
|
||||
|
||||
## Run Hush with CJDNS
|
||||
|
||||
Once you are connected to the CJDNS network, the following Hush
|
||||
configuration option makes CJDNS peers automatically reachable:
|
||||
|
||||
```
|
||||
-cjdnsreachable
|
||||
```
|
||||
|
||||
When enabled, this option tells Hush that it is running in an
|
||||
environment where a connection to an `fc00::/8` address will be to the CJDNS
|
||||
network instead of to an [RFC4193](https://datatracker.ietf.org/doc/html/rfc4193)
|
||||
IPv6 local network. This helps Hush perform better address management:
|
||||
- Your node can consider incoming `fc00::/8` connections to be from the CJDNS
|
||||
network rather than from an IPv6 private one.
|
||||
- If one of your node's local addresses is `fc00::/8`, then it can choose to
|
||||
gossip that address to peers.
|
||||
|
||||
## Additional configuration options related to CJDNS
|
||||
|
||||
```
|
||||
-onlynet=cjdns
|
||||
```
|
||||
|
||||
Make automatic outbound connections only to CJDNS addresses. Inbound and manual
|
||||
connections are not affected by this option. It can be specified multiple times
|
||||
to allow multiple networks, e.g. onlynet=cjdns, onlynet=i2p, onlynet=onion.
|
||||
|
||||
CJDNS support was added to Hush in version 3.9.3 and there may be fewer
|
||||
CJDNS peers than Tor or IP ones. You can use `hush-cli -addrinfo` to see the
|
||||
number of CJDNS addresses known to your node.
|
||||
|
||||
In general, a node can be run with both an onion service and CJDNS (or any/all
|
||||
of IPv4/IPv6/onion/I2P/CJDNS), which can provide a potential fallback if one of
|
||||
the networks has issues. There are a number of ways to configure this; see
|
||||
[doc/tor.md](https://git.hush.is/hush/hush3/src/branch/master/doc/tor.md) for
|
||||
details.
|
||||
|
||||
## CJDNS-related information in Hush
|
||||
|
||||
There are several ways to see your CJDNS address in Hush:
|
||||
- in the "Local addresses" output of CLI `-netinfo`
|
||||
- in the "localaddresses" output of RPC `getnetworkinfo`
|
||||
|
||||
To see which CJDNS peers your node is connected to, use `hush-cli -netinfo 4`
|
||||
or the `getpeerinfo` RPC (i.e. `hush-cli getpeerinfo`).
|
||||
|
||||
You can use the `getnodeaddresses` RPC to fetch a number of CJDNS peers known to your node; run `hush-cli help getnodeaddresses` for details.
|
@ -38,10 +38,30 @@ Defaults to 1. This is a default option that should not be changed or things wil
|
||||
|
||||
Defaults to 0. This option enables the "shielded index" which also calculates the "anonset" (anonymity set) also known as the "shielded pool". This data is avaailable in the getchaintxstats RPC, if zindex is enabled. Enabling this feature requires a full rescan or full sync from scratch, which is not done by default. If you don't do one of those things, your zindex stats will be incorrect.
|
||||
|
||||
# Mining options
|
||||
# Mining and Stratum server options
|
||||
|
||||
These options are only of interest to solo miners and mining pool operators....
|
||||
|
||||
## stratum
|
||||
|
||||
Defaults to off. This option enables a Stratum server.
|
||||
|
||||
## stratumaddress=<address>
|
||||
|
||||
Defaults to none. This option sets a Stratum Mining address to use when special address of 'x' is sent by miner.
|
||||
|
||||
## stratumbind=<ipaddr>
|
||||
|
||||
Defaults to: bind to all interfaces. This option Binds to given address to listen for Stratum work requests. Use [host]:port notation for IPv6. This option can be specified multiple times.
|
||||
|
||||
## stratumport=<port>
|
||||
|
||||
Defaults to 19031 or 19031 for testnet. This option sets the <port> to listen for Stratum work requests on.
|
||||
|
||||
## stratumallowip=<ip>
|
||||
|
||||
No default. This option allows Stratum work requests from specified source. Valid for <ip> are a single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24). This option can be specified multiple times.
|
||||
|
||||
# Other options
|
||||
|
||||
These options are not commonly used and likely on for advanced users and/or developers...
|
||||
@ -56,4 +76,4 @@ Defaults to 0 in hushd, defaults to 1 in some GUI wallets. Maintain a timestamp
|
||||
|
||||
## spentindex=1
|
||||
|
||||
Defaults to 0 in hushd, defaults to 1 in some GUI wallets. Maintain a full spent index, used to query the spending txid and input index for an outpoint
|
||||
Defaults to 0 in hushd, defaults to 1 in some GUI wallets. Maintain a full spent index, used to query the spending txid and input index for an outpoint
|
||||
|
73
doc/i2p.md
73
doc/i2p.md
@ -33,12 +33,10 @@ configuration options:
|
||||
none)
|
||||
|
||||
-i2pacceptincoming
|
||||
If set and -i2psam is also set then incoming I2P connections are
|
||||
accepted via the SAM proxy. If this is not set but -i2psam is set
|
||||
then only outgoing connections will be made to the I2P network.
|
||||
Ignored if -i2psam is not set. Listening for incoming I2P
|
||||
connections is done through the SAM proxy, not by binding to a
|
||||
local address and port (default: 1)
|
||||
Whether to accept inbound I2P connections (default: 1). Ignored if
|
||||
-i2psam is not set. Listening for inbound I2P connections is
|
||||
done through the SAM proxy, not by binding to a local address and
|
||||
port.
|
||||
```
|
||||
|
||||
In a typical situation, this suffices:
|
||||
@ -56,6 +54,36 @@ connections if `-i2pacceptincoming=1`. If `-i2pacceptincoming=0` then only
|
||||
outbound I2P connections are made and a different transient I2P address is used
|
||||
for each connection to improve privacy.
|
||||
|
||||
## Additional configuration options related to I2P
|
||||
|
||||
```
|
||||
-debug=i2p
|
||||
```
|
||||
|
||||
Set the `debug=i2p` config logging option to see additional information in the
|
||||
debug log about your I2P configuration and connections.
|
||||
|
||||
```
|
||||
-onlynet=i2p
|
||||
```
|
||||
|
||||
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
|
||||
make a node more susceptible to [Sybil
|
||||
attacks](https://en.bitcoin.it/wiki/Weaknesses#Sybil_attack).
|
||||
|
||||
Another consideration with `onlynet=i2p` is that the initial blocks download
|
||||
phase when syncing up a new node can be very slow. This phase can be sped up by
|
||||
using other networks, for instance `onlynet=onion`, at the same time.
|
||||
|
||||
In general, a node can be run with both onion and I2P hidden services (or
|
||||
any/all of IPv4/IPv6/onion/I2P/CJDNS), which can provide a potential fallback if
|
||||
one of the networks has issues.
|
||||
|
||||
## Persistent vs transient I2P addresses
|
||||
|
||||
In I2P connections, the connection receiver sees the I2P address of the
|
||||
@ -136,14 +164,19 @@ port (`TO_PORT`) is always set to 0 and is not in the control of Hush.
|
||||
|
||||
## Bandwidth
|
||||
|
||||
I2P routers may route a large amount of general network traffic with their
|
||||
default settings. Check your router's configuration to limit the amount of this
|
||||
traffic relayed, if desired.
|
||||
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
|
||||
as much to the I2P network as they consume.
|
||||
|
||||
With `i2pd`, the amount of bandwidth being shared with the wider network can be
|
||||
adjusted with the `bandwidth`, `share` and `transittunnels` options in your
|
||||
`i2pd.conf` file. For example, to limit total I2P traffic to 256KB/s and share
|
||||
50% of this limit for a maximum of 20 transit tunnels:
|
||||
It is possible, though strongly discouraged, to change your I2P router
|
||||
configuration to limit the amount of I2P traffic relayed by your node.
|
||||
|
||||
With `i2pd`, this can be done by adjusting the `bandwidth`, `share` and
|
||||
`transittunnels` options in your `i2pd.conf` file. For example, to limit total
|
||||
I2P traffic to 256KB/s and share 50% of this limit for a maximum of 20 transit
|
||||
tunnels:
|
||||
|
||||
```
|
||||
bandwidth = 256
|
||||
@ -153,9 +186,15 @@ share = 50
|
||||
transittunnels = 20
|
||||
```
|
||||
|
||||
If you prefer not to relay any public I2P traffic and only permit I2P traffic
|
||||
from programs which are connecting via the SAM proxy, e.g. Hush, you
|
||||
can set the `notransit` option to `true`.
|
||||
|
||||
Similar bandwidth configuration options for the Java I2P router can be found in
|
||||
`http://127.0.0.1:7657/config` under the "Bandwidth" tab.
|
||||
|
||||
Before doing this, please see the "Participating Traffic Considerations" section
|
||||
in [Embedding I2P in your Application](https://geti2p.net/en/docs/applications/embedding).
|
||||
|
||||
In most cases, the default router settings should work fine.
|
||||
|
||||
## Bundling I2P in a Hush 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.
|
||||
|
@ -221,7 +221,7 @@ class WalletTest (BitcoinTestFramework):
|
||||
for uTx in unspentTxs:
|
||||
if uTx['txid'] == zeroValueTxid:
|
||||
found = True
|
||||
assert_equal(uTx['amount'], Decimal('0.00000000'))
|
||||
assert_equal(uTx['amount'], Decimal('0'))
|
||||
assert(found)
|
||||
|
||||
#do some -walletbroadcast tests
|
||||
|
@ -4111,6 +4111,7 @@ UniValue z_listunspent(const UniValue& params, bool fHelp, const CPubKey& mypk)
|
||||
" \"address\" : \"address\", (string) the shielded address\n"
|
||||
" \"amount\": xxxxx, (numeric) the amount of value in the note\n"
|
||||
" \"memo\": xxxxx, (string) hexademical string representation of memo field\n"
|
||||
" \"memoStr\" : \"memo\", (string) Only returned if memo contains valid UTF-8 text.\n"
|
||||
" \"change\": true|false, (boolean) true if the address that received the note is also one of the sending addresses\n"
|
||||
" }\n"
|
||||
" ,...\n"
|
||||
@ -4479,6 +4480,7 @@ UniValue z_listreceivedbyaddress(const UniValue& params, bool fHelp, const CPubK
|
||||
" \"txid\": xxxxx, (string) the transaction id\n"
|
||||
" \"amount\": xxxxx, (numeric) the amount of value in the note\n"
|
||||
" \"memo\": xxxxx, (string) hexadecimal string representation of memo field\n"
|
||||
" \"memoStr\" : \"memo\", (string) Only returned if memo contains valid UTF-8 text.\n"
|
||||
" \"confirmations\" : n, (numeric) the number of notarized confirmations (dpowconfs)\n"
|
||||
" \"rawconfirmations\" : n, (numeric) the number of raw confirmations\n"
|
||||
" \"outindex\" (sapling) : n, (numeric) the output index\n"
|
||||
|
@ -1233,8 +1233,13 @@ bool CWalletDB::Recover(CDBEnv& dbenv, const std::string& filename, bool fOnlyKe
|
||||
CDataStream ssKey(row.first, SER_DISK, CLIENT_VERSION);
|
||||
CDataStream ssValue(row.second, SER_DISK, CLIENT_VERSION);
|
||||
string strType, strErr;
|
||||
bool fReadOK = ReadKeyValue(&dummyWallet, ssKey, ssValue,
|
||||
bool fReadOK;
|
||||
{
|
||||
// Required in LoadKeyMetadata():
|
||||
LOCK(dummyWallet.cs_wallet);
|
||||
fReadOK = ReadKeyValue(&dummyWallet, ssKey, ssValue,
|
||||
wss, strType, strErr);
|
||||
}
|
||||
if (!IsKeyType(strType))
|
||||
continue;
|
||||
if (!fReadOK)
|
||||
|
@ -34,7 +34,7 @@ if ($acname) {
|
||||
# HSC's by default have a blocktime of 60s
|
||||
$perday = 1440;
|
||||
# Dragonx has a blocktime of 36s
|
||||
$perday = 2400 if ($acname == 'DRAGONX');
|
||||
$perday = 2400 if ($acname eq 'DRAGONX');
|
||||
} else {
|
||||
$acname = 'HUSH3';
|
||||
}
|
||||
|
Loading…
x
Reference in New Issue
Block a user