Integrate Bitcoin changes from 0.12.0
Motivation
During the last 3 years, many useful changes and improvements have been made to Bitcoin source code. The current version of Bitcoin is 0.16.2, Crown is on 0.10.
-
Refactoring of different Bitcoin modules (decomposition etc.)
-
Moving from BOOST to C++ 11/14 features
-
Other functional changes
Integration analysis
0.12.0 https://bitcoin.org/en/release/v0.12.0
Major version release, bringing new features and other improvements
-
0.12.0 and later will obfuscate the chainstate (?)
-
Signature validation using libsecp256k1. The advantage is largest on x86_64, where validation is over five times faster. A side effect of this change is that libconsensus no longer depends on OpenSSL. It looks like libsecp256k1 is being used by Crown Core already.
-
Reduce upload traffic.
-maxuploadtarget
this option can be specified in MiB per day and is turned off by default. Disable "listening" (-listen=0
). Reduce maximum connections (-maxconnections=<num>
). More details are here: /doc/reduce-traffic.md. Consider if we need to restrict access to this features to MNs/SNs. -
Direct headers announcement - BIP-0130. This means that blocks are advertised by announcing their headers directly, instead of just announcing the hash. https://github.com/bitcoin/bitcoin/pull/6494.
-
Memory pool limiting. Bitcoin Core 0.12 will have a strict maximum size on the mempool. The default value is 300 MB and can be configured with the
-maxmempool
parameter. -
Opt-in Replace-by-fee transactions. BIP-125. Many nodes today will not replace any transaction in their mempool with another transaction that spends the same inputs, making it difficult for spenders to adjust their previously-sent transactions to deal with unexpected confirmation delays or to perform other useful replacements.
-
RPC: Random-cookie RPC authentication. When no
-rpcpassword
is specified, the daemon now uses a special ‘cookie’ file for authentication. By default it is stored in the data directory but its location can be overridden with the option-rpccookiefile
. This allows running bitcoind without having to do any manual configuration. -
Relay: Any sequence of pushdatas in OP_RETURN outputs now allowed
-
Relay and Mining: Priority transactions. Changes in priority calculations. Review deliberately during merge
-
Automatically use Tor hidden services. This new feature is enabled by default if Bitcoin Core is listening, and a connection to Tor can be made. It can be configured with the
-listenonion
,-torcontrol
and-torpassword
settings. Do not merge it. -
Notifications through ZMQ
-
Wallet: Transaction fees. Various improvements have been made to how the wallet calculates transaction fees.
-
Wallet: Negative confirmations and conflict detection. The wallet will now report a negative number for confirmations that indicates how deep in the block chain the conflict is found.
-
Wallet: Merkle branches removed. Previously, every wallet transaction stored a Merkle branch to prove its presence in blocks. This wasn’t being used for more than an expensive sanity check.
-
With 0.12 it is possible to use wallet functionality in pruned mode. This can reduce the disk usage from currently around 60 GB to around 2 GB. However, rescans as well as the RPCs
importwallet
,importaddress
,importprivkey
are disabled. -
NODE_BLOOM service bit. Support for the NODE_BLOOM service bit, as described in BIP 111, has been added to the P2P protocol code. A controversial feature. Needs more research during merge.
-
Option parsing behavior. Command line options are now parsed strictly in the order in which they are specified.
-
RPC: Low-level API changes.
-
RPC: SSL support dropped. SSL support for RPC, previously enabled by the option rpcssl has been dropped from both the client and the server. This was done in preparation for removing the dependency on OpenSSL for the daemon completely. Re-consider all usages of OpenSSL in Crown.
-
Mining Code Changes. The mining code in 0.12 has been optimized to be significantly faster and use less memory.
-
Other P2P Changes. The list of banned peers is now stored on disk rather than in memory. Restarting bitcoind will no longer clear out the list of banned peers; instead a new RPC call (
clearbanned
) can be used to manually clear the list. The newsetban
RPC call can also be used to manually ban or unban a peer.