Merge branch 'master' into document-rpc-security
This commit is contained in:
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
@@ -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 |
@@ -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`.
|
||||
|
||||
@@ -58,12 +58,10 @@ z_listaddresses | | Returns a list of all the zaddrs in this node’s 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 node’s 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 zcashd’s working directory.<br><br>No value is returned but a JSON-RPC error will be reported if a failure occurred.
|
||||
|
||||
|
||||
121
doc/release-notes/release-notes-1.0.0-rc1.md
Normal file
121
doc/release-notes/release-notes-1.0.0-rc1.md
Normal 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
|
||||
|
||||
@@ -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...)
|
||||
|
||||
@@ -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).
|
||||
|
||||
28
doc/tor.md
28
doc/tor.md
@@ -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
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
*** Warning: This document has not been updated for Zcash and may be inaccurate. ***
|
||||
|
||||
Translation Strings Policy
|
||||
===========================
|
||||
|
||||
|
||||
Reference in New Issue
Block a user