Merge branch 'master' into document-rpc-security

This commit is contained in:
Jay Graber
2016-10-19 18:56:11 -07:00
154 changed files with 2260 additions and 2236 deletions

View File

@@ -1,4 +1,4 @@
Zcash Core 1.0.0-beta2
Zcash Core 1.0.0-rc1
====================
[Zcash](https://z.cash/) is the Zcash client. It downloads and stores the entire history of Zcash transactions; depending on the speed of your computer and network connection, the synchronization process could take a day or more once the blockchain has reached a significant size.

View File

@@ -1,83 +0,0 @@
*** Warning: This document has not been updated for Zcash and may be inaccurate. ***
Unauthenticated REST Interface
==============================
The REST API can be enabled with the `-rest` option.
Supported API
-------------
####Transactions
`GET /rest/tx/<TX-HASH>.<bin|hex|json>`
Given a transaction hash: returns a transaction in binary, hex-encoded binary, or JSON formats.
For full TX query capability, one must enable the transaction index via "txindex=1" command line / configuration option.
####Blocks
`GET /rest/block/<BLOCK-HASH>.<bin|hex|json>`
`GET /rest/block/notxdetails/<BLOCK-HASH>.<bin|hex|json>`
Given a block hash: returns a block, in binary, hex-encoded binary or JSON formats.
The HTTP request and response are both handled entirely in-memory, thus making maximum memory usage at least 2.66MB (1 MB max block, plus hex encoding) per request.
With the /notxdetails/ option JSON response will only contain the transaction hash instead of the complete transaction details. The option only affects the JSON response.
####Blockheaders
`GET /rest/headers/<COUNT>/<BLOCK-HASH>.<bin|hex>`
Given a block hash: returns <COUNT> amount of blockheaders in upward direction.
JSON is not supported.
####Chaininfos
`GET /rest/chaininfo.json`
Returns various state info regarding block chain processing.
Only supports JSON as output format.
* chain : (string) current network name as defined in BIP70 (main, test, regtest)
* blocks : (numeric) the current number of blocks processed in the server
* headers : (numeric) the current number of headers we have validated
* bestblockhash : (string) the hash of the currently best block
* difficulty : (numeric) the current difficulty
* verificationprogress : (numeric) estimate of verification progress [0..1]
* chainwork : (string) total amount of work in active chain, in hexadecimal
####Query UTXO set
`GET /rest/getutxos/<checkmempool>/<txid>-<n>/<txid>-<n>/.../<txid>-<n>.<bin|hex|json>`
The getutxo command allows querying of the UTXO set given a set of outpoints.
See BIP64 for input and output serialisation:
https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki
Example:
```
$ curl localhost:18232/rest/getutxos/checkmempool/b2cdfd7b89def827ff8af7cd9bff7627ff72e5e8b0f71210f92ea7a4000c5d75-0.json 2>/dev/null | json_pp
{
"chaintipHash" : "00000000fb01a7f3745a717f8caebee056c484e6e0bfe4a9591c235bb70506fb",
"chainHeight" : 325347,
"utxos" : [
{
"scriptPubKey" : {
"addresses" : [
"mi7as51dvLJsizWnTMurtRmrP8hG2m1XvD"
],
"type" : "pubkeyhash",
"hex" : "76a9141c7cebb529b86a04c683dfa87be49de35bcf589e88ac",
"reqSigs" : 1,
"asm" : "OP_DUP OP_HASH160 1c7cebb529b86a04c683dfa87be49de35bcf589e OP_EQUALVERIFY OP_CHECKSIG"
},
"value" : 8.8687,
"height" : 2147483647,
"txvers" : 1
}
],
"bitmap" : "1"
}
```
Risks
-------------
Running a web browser on the same node with a REST enabled bitcoind can be a risk. Accessing prepared XSS websites could read out tx/block data of your node by placing links like `<script src="http://127.0.0.1:8232/rest/tx/1234567890.json">` which might break the nodes privacy.

View File

@@ -1,5 +1,3 @@
*** Warning: This document has not been updated for Zcash and may be inaccurate. ***
Bitcoin Core version 0.11.2 is now available from:
<https://bitcoin.org/bin/bitcoin-core-0.11.2/>

Binary file not shown.

Before

Width:  |  Height:  |  Size: 3.2 KiB

View File

@@ -1,232 +0,0 @@
*** Warning: This document has not been updated for Zcash and may be inaccurate. ***
UNIX BUILD NOTES
====================
Some notes on how to build Bitcoin in Unix.
Note
---------------------
Always use absolute paths to configure and compile bitcoin and the dependencies,
for example, when specifying the the path of the dependency:
../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX
Here BDB_PREFIX must absolute path - it is defined using $(pwd) which ensures
the usage of the absolute path.
To Build
---------------------
```bash
./autogen.sh
./configure
make
make install # optional
```
This will build bitcoin-qt as well if the dependencies are met.
Dependencies
---------------------
These dependencies are required:
Library | Purpose | Description
------------|------------------|----------------------
libssl | SSL Support | Secure communications
libboost | Boost | C++ Library
Optional dependencies:
Library | Purpose | Description
------------|------------------|----------------------
miniupnpc | UPnP Support | Firewall-jumping support
libdb4.8 | Berkeley DB | Wallet storage (only needed when wallet enabled)
qt | GUI | GUI toolkit (only needed when GUI enabled)
protobuf | Payments in GUI | Data interchange format used for payment protocol (only needed when GUI enabled)
libqrencode | QR codes in GUI | Optional for generating QR codes (only needed when GUI enabled)
For the versions used in the release, see [release-process.md](release-process.md) under *Fetch and build inputs*.
System requirements
--------------------
C++ compilers are memory-hungry. It is recommended to have at least 1 GB of
memory available when compiling Bitcoin Core. With 512MB of memory or less
compilation will take much longer due to swap thrashing.
Dependency Build Instructions: Ubuntu & Debian
----------------------------------------------
Build requirements:
sudo apt-get install build-essential libtool autotools-dev autoconf pkg-config libssl-dev
For Ubuntu 12.04 and later or Debian 7 and later libboost-all-dev has to be installed:
sudo apt-get install libboost-all-dev
db4.8 packages are available [here](https://launchpad.net/~bitcoin/+archive/bitcoin).
You can add the repository using the following command:
sudo add-apt-repository ppa:bitcoin/bitcoin
sudo apt-get update
Ubuntu 12.04 and later have packages for libdb5.1-dev and libdb5.1++-dev,
but using these will break binary wallet compatibility, and is not recommended.
For other Debian & Ubuntu (with ppa):
sudo apt-get install libdb4.8-dev libdb4.8++-dev
Optional:
sudo apt-get install libminiupnpc-dev (see --with-miniupnpc and --enable-upnp-default)
Dependencies for the GUI: Ubuntu & Debian
-----------------------------------------
If you want to build Bitcoin-Qt, make sure that the required packages for Qt development
are installed. Either Qt 4 or Qt 5 are necessary to build the GUI.
If both Qt 4 and Qt 5 are installed, Qt 4 will be used. Pass `--with-gui=qt5` to configure to choose Qt5.
To build without GUI pass `--without-gui`.
To build with Qt 4 you need the following:
sudo apt-get install libqt4-dev libprotobuf-dev protobuf-compiler
For Qt 5 you need the following:
sudo apt-get install libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler
libqrencode (optional) can be installed with:
sudo apt-get install libqrencode-dev
Once these are installed, they will be found by configure and a bitcoin-qt executable will be
built by default.
Notes
-----
The release is built with GCC and then "strip bitcoind" to strip the debug
symbols, which reduces the executable size by about 90%.
miniupnpc
---------
[miniupnpc](http://miniupnp.free.fr/) may be used for UPnP port mapping. It can be downloaded from [here](
http://miniupnp.tuxfamily.org/files/). UPnP support is compiled in and
turned off by default. See the configure options for upnp behavior desired:
--without-miniupnpc No UPnP support miniupnp not required
--disable-upnp-default (the default) UPnP support turned off by default at runtime
--enable-upnp-default UPnP support turned on by default at runtime
To build:
tar -xzvf miniupnpc-1.6.tar.gz
cd miniupnpc-1.6
make
sudo su
make install
Berkeley DB
-----------
It is recommended to use Berkeley DB 4.8. If you have to build it yourself:
```bash
BITCOIN_ROOT=$(pwd)
# Pick some path to install BDB to, here we create a directory within the bitcoin directory
BDB_PREFIX="${BITCOIN_ROOT}/db4"
mkdir -p $BDB_PREFIX
# Fetch the source and verify that it is not tampered with
wget 'http://download.oracle.com/berkeley-db/db-4.8.30.NC.tar.gz'
echo '12edc0df75bf9abd7f82f821795bcee50f42cb2e5f76a6a281b85732798364ef db-4.8.30.NC.tar.gz' | sha256sum -c
# -> db-4.8.30.NC.tar.gz: OK
tar -xzvf db-4.8.30.NC.tar.gz
# Build the library and install to our prefix
cd db-4.8.30.NC/build_unix/
# Note: Do a static build so that it can be embedded into the executable, instead of having to find a .so at runtime
../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX
make install
# Configure Bitcoin Core to use our own-built instance of BDB
cd $BITCOIN_ROOT
./configure (other args...) LDFLAGS="-L${BDB_PREFIX}/lib/" CPPFLAGS="-I${BDB_PREFIX}/include/"
```
**Note**: You only need Berkeley DB if the wallet is enabled (see the section *Disable-Wallet mode* below).
Boost
-----
If you need to build Boost yourself:
sudo su
./bootstrap.sh
./bjam install
Security
--------
To help make your bitcoin installation more secure by making certain attacks impossible to
exploit even if a vulnerability is found, binaries are hardened by default.
This can be disabled with:
Hardening Flags:
./configure --enable-hardening
./configure --disable-hardening
Hardening enables the following features:
* Position Independent Executable
Build position independent code to take advantage of Address Space Layout Randomization
offered by some kernels. Attackers who can cause execution of code at an arbitrary memory
location are thwarted if they don't know where anything useful is located.
The stack and heap are randomly located by default but this allows the code section to be
randomly located as well.
On an AMD64 processor where a library was not compiled with -fPIC, this will cause an error
such as: "relocation R_X86_64_32 against `......' can not be used when making a shared object;"
To test that you have built PIE executable, install scanelf, part of paxutils, and use:
scanelf -e ./bitcoin
The output should contain:
TYPE
ET_DYN
* Non-executable Stack
If the stack is executable then trivial stack based buffer overflow exploits are possible if
vulnerable buffers are found. By default, bitcoin should be built with a non-executable stack
but if one of the libraries it uses asks for an executable stack or someone makes a mistake
and uses a compiler extension which requires an executable stack, it will silently build an
executable without the non-executable stack protection.
To verify that the stack is non-executable after compiling use:
`scanelf -e ./bitcoin`
the output should contain:
STK/REL/PTL
RW- R-- RW-
The STK RW- means that the stack is readable and writeable but not executable.
Disable-wallet mode
--------------------
When the intention is to run only a P2P node without a wallet, bitcoin may be compiled in
disable-wallet mode with:
./configure --disable-wallet
In this case there is no dependency on Berkeley DB 4.8.
Mining is also possible in disable-wallet mode, but only using the `getblocktemplate` RPC
call not `getwork`.

View File

@@ -58,12 +58,10 @@ z_listaddresses | | Returns a list of all the zaddrs in this nodes wallet for
### Key Management
**beta 1 release note:** encrypted wallets are not yet fully supported. If the wallet is protected with a passphrase, zkeys will not be persisted to disk.
Command | Parameters | Description
--- | --- | ---
z_exportkey | zaddr | _Requires an unlocked wallet or an unencrypted wallet._<br><br>Return a zkey for a given zaddr belonging to the nodes wallet.<br><br>The key will be returned as a string formatted using Base58Check as described in the Zcash protocol spec.<br><br>Output:AKWUAkypwQjhZ6LLNaMuuuLcmZ6gt5UFyo8m3jGutvALmwZKLdR5
z_importkey | zkey [rescan=true] | _Wallet must be unlocked._<br><br>Add a zkey as returned by z_exportkey to a node's wallet.<br><br>The key should be formatted using Base58Check as described in the Zcash protocol spec.<br><br>Set rescan to true (the default) to rescan the entire local block database for transactions affecting any address or pubkey script in the wallet (including transactions affecting the newly-added address for this spending key).
z_importkey | zkey [rescan=true] | _Wallet must be unlocked._<br><br>Add a zkey as returned by z_exportkey to a node's wallet.<br><br>The key should be formatted using Base58Check as described in the Zcash protocol spec.<br><br>Set rescan to true (the default) to rescan the entire local block database for transactions affecting any address or pubkey script in the wallet (including transactions affecting the newly-added address for this spending key).<br><br>**NOTE:** If funds for imported keys fail to display, try stopping the node and restarting it with a `-reindex` flag. (`./src/zcashd -reindex`)
z_exportwallet | filename | _Requires an unlocked wallet or an unencrypted wallet._<br><br>Creates or overwrites a file with taddr private keys and zaddr private keys in a human-readable format.<br><br>Filename is the file in which the wallet dump will be placed. May be prefaced by an absolute file path. An existing file with that name will be overwritten.<br><br>No value is returned but a JSON-RPC error will be reported if a failure occurred.
z_importwallet | filename | _Requires an unlocked wallet or an unencrypted wallet._<br><br>Imports private keys from a file in wallet export file format (see z_exportwallet). These keys will be added to the keys currently in the wallet. This call may need to rescan all or parts of the block chain for transactions affecting the newly-added keys, which may take several minutes.<br><br>Filename is the file to import. The path is relative to zcashds working directory.<br><br>No value is returned but a JSON-RPC error will be reported if a failure occurred.

View File

@@ -0,0 +1,121 @@
4ZEC (1):
Correct line swap
Cory Fields (7):
release: add _IO_stdin_used to ignored exports
release: add check-symbols and check-security make targets
release: always link librt for glibc back-compat builds
release: add security/symbol checks to gitian
depends: allow for CONFIG_SITE to be used rather than stealing prefix
gitian: use CONFIG_SITE rather than hijacking the prefix
gitian: create debug packages for linux/windows
Daira Hopwood (6):
Fix RPC tests to not rely on accounts.
Cosmetics in RPC tests.
Fix blank lines in DEBIAN/copyright license texts.
Move the increment of nWitnessCacheSize to make the later assertions correct.
Add another assertion to narrow down where the bug occurs.
Add another assertion about the witness cache.
Jack Grigg (25):
Update release process to sign release tags
WriteWitnessCache: Catch errors and abort transaction
Throw an RPC error for all accounts except the default
Update tests for account deprecation
Deprecated -> Unsupported in RPC error
Correct docstring
Add unit tests for WriteWitnessCache
Document CWalletTx::FindMyNotes
Refactor test to clarify expectations
Add unit test that fails when calling FindMyNotes on a locked wallet
Add RPC test showing correct handling of JS txns from blockchain
Break the RPC test by encrypting the mirroring wallet
Delay caching of nullifiers when wallet is locked
Update comments
Only ignore runtime errors caused by failed note decryption
Remaining changes from bitcoin/bitcoin#6854
[gitian] Don't call "make check-symbols"
Fix Makefiles so "make dist" will run
Render full version correctly in configure.ac
Update libsnark to include determinism fix
Address review comments
Add more asserts to track down the bug
Increment witnesses for new transactions on rescan
Add clear error message for upgrading users
Set CBlockIndex.hashAnchor correctly in ConnectBlock
Jay Graber (17):
Document wallet reindexing for z_importkey description in payment-api.md
Rm beta 1 release note about encrypted wallets
Note that Coinbase maturity interval does not protect JoinSplits
Refer to Zcash wiki in INSTALL
Rm bitcoin logo
Rm build-unix.md, to keep single copy of build instructions for Zcash on github wiki
Rm Bitcoin-specific documentation
Add note that document is not updated for Zcash to translation policy
Rm doc for disabled REST interface
Change alpha to beta testnet, add zcash hidden service
Improve documentation on connecting to zcash hidden server
Improve documentation on connecting to zcash hidden server
Update tor.md
Distinguish between connecting to 1 vs multiple tor nodes
Revert "Rm Bitcoin-specific documentation"
Mv btc release notes to doc/bitcoin-release-notes
Reword joinsplit anchor paragraph
Kevin Gallagher (24):
Set wget retry options for fetching parameters
Increases timeout to 30s, wait before retry to 3s
Initial packaging for Debian
Moves zcash-fetch-params to /usr/bin
Adds newline between source and package definition
Adds copyright file back to Debian package
Updates Linux gitian descriptor file for Zcash
Updates trusty -> jessie in Gitian Linux descriptor
Adds distro: debian to gitian-linux.yml
Updates Gitian descriptor for Zcash
Removes Windows and OSX packaging from EXTRA_DIST
Moves V=1 and NO_QT=1 to MAKEOPTS
Include contrib/devtools/split-debug.sh from upstream
Adds faketime to Gitian build dependencies
Inlude crypto/equihash.tcc in list of sources for dist
Adds zcash/Zcash.h to LIBZCASH sources
Adds zcash/Proof.hpp to LIBZCASH_H
Add alertkeys.h to libbitcoin_server_a_SOURCES
Adds files in src/zcash/circuit to libzcash_a_SOURCES
Adds zcbenchmarks.h to libbitcoin_wallet_a_SOURCES
Adds json_test_vectors.h to zcash_gtest_SOURCES
Adds additional licenses to Debian copyright file
Updates Zcash Core developers -> Zcash developers
Adds . to blank lines in Google license
MarcoFalke (3):
[gitian] Set reference date to something more recent
[gitian] Default reference_datetime to commit author date
[gitian] hardcode datetime for depends
Sean Bowe (1):
Make 100KB transaction size limit a consensus rule, rather than a standard rule.
Simon (11):
Add vjoinsplit to JSON output of RPC call gettransaction
Fixes #1478 by ensuring wallet tests have the -datadir environment set appropriately.
Fixes #1491 by updating help message for rpc call z_importkey
Fix incorrect check of number of parameters for z_getnewaddress.
Add tests to verify that all z_* rpc calls return an error if there are too many input parameters.
Rename client identifier from Satoshi to MagicBean (closes #1481)
Use -debug=zrpc for z_* rpc calls (#1504)
Document CWallet::GetFilteredNotes and fix return type which should be void.
Fix test so that the encrypted wallet is output to the test_bitcoin -datadir folder.
Reorder gtests in zcash-gtest.
Return improved error message when trying to spend Coinbase coins (#1373).
Wladimir J. van der Laan (6):
devtools: add libraries for bitcoin-qt to symbol check
gitian: use trusty for building
gitian: make windows build deterministic
gitian: Need `ca-certificates` and `python` for LXC builds
build: Remove unnecessary executables from gitian release
gitian: Add --disable-bench to config flags for windows

View File

@@ -28,14 +28,17 @@ Also, the following commands use the `ZCASH_RELEASE_PREV` bash variable for the
previous release:
$ ZCASH_RELEASE_PREV=1.0.0-beta1
## B. create a new release branch / github PR
### B1. update (commit) version in sources
doc/README.md
src/clientversion.h
configure.ac
contrib/DEBIAN/control
contrib/gitian-descriptors/gitian-linux.yml
In `configure.ac` and `clientversion.h`:
- Increment `CLIENT_VERSION_BUILD` according to the following schema:
@@ -56,12 +59,20 @@ git shortlog helps a lot, for example:
$ git shortlog --no-merges v${ZCASH_RELEASE_PREV}..HEAD \
> ./doc/release-notes/release-notes-${ZCASH_RELEASE}.md
Update the Debian package changelog:
export DEBVERSION='1.0.0-rc1'
export DEBEMAIL="${DEBEMAIL:-team@z.cash}"
export DEBFULLNAME="${DEBFULLNAME:-Zcash Company}"
dch -v $DEBVERSION -D jessie -c contrib/DEBIAN/changelog
### B3. change the network magics
If this release breaks backwards compatibility, change the network magic
numbers. Set the four `pchMessageStart` in `CTestNetParams` in `chainparams.cpp`
to random values.
### B4. merge the previous changes
Do the normal pull-request, review, testing process for this release PR.
@@ -76,15 +87,13 @@ https://ci.z.cash/builders/depends-sources
Run `./fetch-params.sh`.
## D. make tags / release-branch for the newly merged result
## D. make tag for the newly merged result
In this example, we ensure zc.v0.11.2.latest is up to date with the
In this example, we ensure master is up to date with the
previous merged PR, then:
$ git tag v${ZCASH_RELEASE}
$ git branch zc.v${ZCASH_RELEASE}
$ git tag -s v${ZCASH_RELEASE}
$ git push origin v${ZCASH_RELEASE}
$ git push origin zc.v${ZCASH_RELEASE}
## E. deploy testnet
@@ -104,8 +113,6 @@ Zcash still needs:
* deterministic or reproducible builds
* signed git tags
* thorough pre-release testing (presumably more thorough than standard PR tests)
* release deployment steps (eg: updating build-depends mirror, deploying testnet, etc...)

View File

@@ -49,9 +49,9 @@ RPC Interface
If the client knows the RPC password, they have full access to the node. Users should choose a strong RPC password, and refrain from changing the default setting that only allows RPC connections from localhost. A remote host would enable a MITM to execute arbitrary RPC commands. For multi-user services that use one or more zcashd 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 zcashd.
Block Chain Reorganizations
----------------------------
Block Chain Reorganization: Major Differences
-------------------------------------------------
Users should be aware of new behavior in Zcash that differs significantly from Bitcoin: in the case of a block chain reorganization, Bitcoin's coinbase maturity rule helps ensure that any reorg shorter than the maturity interval will not invalidate any of the rolled-back transactions. However for Zcash, all JoinSplits which were anchored within the reorg interval will become invalid, rolling back transactions and reverting funds to the original owner. The transaction rebroadcast mechanism inherited from Bitcoin will not successfully rebroadcast transactions containing JoinSplits if the anchor needs to change—the JoinSplit creator must do that.
Users should be aware of new behavior in Zcash that differs significantly from Bitcoin: in the case of a block chain reorganization, Bitcoin's coinbase maturity rule helps to ensure that any reorganization shorter than the maturity interval will not invalidate any of the rolled-back transactions. Zcash keeps Bitcoin's 100-block maturity interval for generation transactions, but because JoinSplits must be anchored within a block, this provides more limited protection against transactions becoming invalidated. In the case of a block chain reorganization for Zcash, all JoinSplits which were anchored within the reorganization interval and any transactions that depend on them will become invalid, rolling back transactions and reverting funds to the original owner. The transaction rebroadcast mechanism inherited from Bitcoin will not successfully rebroadcast transactions depending on invalidated JoinSplits if the anchor needs to change. The creator of an invalidated JoinSplit, as well as the creators of all transactions dependent on it, must rebroadcast the transactions themselves.
For receivers of funds from a JoinSplit, using a higher minconf (minimum number of confirmations) can help mitigate the risk of relying on funds received from transactions that may be rolled back.
Receivers of funds from a JoinSplit can mitigate the risk of relying on funds received from transactions that may be rolled back by using a higher minconf (minimum number of confirmations).

View File

@@ -70,7 +70,7 @@ your zcashd's P2P listen port (8233 by default).
In a typical situation, where you're only reachable via Tor, this should suffice:
./zcashd -proxy=127.0.0.1:9050 -externalip=abc123.onion -listen
./zcashd -proxy=127.0.0.1:9050 -externalip=zctestseie6wxgio.onion -listen
(obviously, replace the Onion address with your own). If you don't care too much
about hiding your node, and want to be reachable on IPv4 as well, additionally
@@ -83,34 +83,32 @@ and open port 8233 on your firewall (or use -upnp).
If you only want to use Tor to reach onion addresses, but not use it as a proxy
for normal IPv4/IPv6 communication, use:
./zcashd -onion=127.0.0.1:9050 -externalip=abc123.onion -discover
./zcashd -onion=127.0.0.1:9050 -externalip=zctestseie6wxgio.onion -discover
3. Connect to a Zcash hidden server
-----------------------------------
To test your set-up, you might want to try connecting via Tor to just a
a single Zcash hidden server.
To test your set-up, you might want to try connecting via Tor on a different computer to just a
a single Zcash hidden server. Launch zcashd as follows:
Edit zcash.conf and comment out any nodes you might normally connect to.
#addnode=alphatestnet.z.cash
Launch zcashd as follows:
zcashd -onion=127.0.0.1:9050 -addnode=abc123.onion
./zcashd -onion=127.0.0.1:9050 -connect=zctestseie6wxgio.onion
Now use zcash-cli to verify there is only a single peer connection.
zcash-cli getpeerinfo
[
{
"id" : 1,
"addr" : "abc123.onion:18233",
"addr" : "zctestseie6wxgio.onion:18233",
...
"version" : 70002,
"subver" : "/Satoshi:0.11.2/",
"version" : 170002,
"subver" : "/MagicBean:1.0.0/",
...
}
]
To connect to multiple Tor nodes, use:
./zcashd -onion=127.0.0.1:9050 -addnode=zctestseie6wxgio.onion -dnsseed=0 -onlynet=onion

View File

@@ -1,3 +1,5 @@
*** Warning: This document has not been updated for Zcash and may be inaccurate. ***
Translation Strings Policy
===========================