UFO Core 0.12 Released
First version bits BIP9 softfork deployment
The deployment sets the block version number to 0x20000001 between midnight 1st May 2016 and midnight 1st May 2017 to signal readiness for deployment. The version number consists of 0x20000000 to indicate version bits together with setting bit 0 to indicate support for this combined deployment, shown as “csv” in the
getblockchaininfo RPC call.
BIP112 soft fork to enforce OP_CHECKSEQUENCEVERIFY
BIP112 redefines the existing OP_NOP3 as OP_CHECKSEQUENCEVERIFY (CSV) for a new opcode in the Bitcoin scripting system that in combination with BIP68allows execution pathways of a script to be restricted based on the age of the output being spent.
Signature validation using libsecp256k1
ECDSA signatures inside Bitcoin transactions now use validation using libsecp256k1instead of OpenSSL.
Depending on the platform, this means a significant speedup for raw signature validation speed. The advantage is largest on x86_64, where validation is over five times faster. In practice, this translates to a raw reindexing and new block validation times that are less than half of what it was before.
Libsecp256k1 has undergone very extensive testing and validation.
A side effect of this change is that libconsensus no longer depends on OpenSSL.
Direct headers announcement (BIP 130)
Between compatible peers, [BIP 130] (https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki) direct headers announcement is used. This means that blocks are advertised by announcing their headers directly, instead of just announcing the hash. In a reorganization, all new headers are sent, instead of just the new tip. This can often prevent an extra roundtrip before the actual block is downloaded.
With this change, pruning nodes are now able to relay new blocks to compatible peers.
Memory pool limiting
Previous versions of Bitcoin Core had their mempool limited by checking a transaction’s fees against the node’s minimum relay fee. There was no upper bound on the size of the mempool and attackers could send a large number of transactions paying just slighly more than the default minimum relay fee to crash nodes with relatively low RAM. A temporary workaround for previous versions of Bitcoin Core was to raise the default minimum relay fee.
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. Whenever a transaction would cause the mempool to exceed its maximum size, the transaction that (along with in-mempool descendants) has the lowest total feerate (as a package) will be evicted and the node’s effective minimum relay feerate will be increased to match this feerate plus the initial minimum relay feerate. The initial minimum relay feerate is set to 1000 satoshis per kB.
Bitcoin Core 0.12 also introduces new default policy limits on the length and size of unconfirmed transaction chains that are allowed in the mempool (generally limiting the length of unconfirmed chains to 25 transactions, with a total size of 101 KB). These limits can be overriden using command line arguments; see the extended help (
--help -help-debug) for more information.
Reduce upload traffic
A major part of the outbound traffic is caused by serving historic blocks to other nodes in initial block download state.
It is now possible to reduce the total upload traffic via the
-maxuploadtargetparameter. This is not a hard limit but a threshold to minimize the outbound traffic. When the limit is about to be reached, the uploaded data is cut by not serving historic blocks (blocks older than one week). Moreover, any SPV peer is disconnected when they request a filtered block.
This option can be specified in MiB per day and is turned off by default
-maxuploadtarget=0. The recommended minimum is 144 * MAX_BLOCK_SIZE (currently 144MB) per day.
Whitelisted peers will never be disconnected, although their traffic counts for calculating the target.
A more detailed documentation about keeping traffic low can be found in /doc/reduce-traffic.md.
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. For example, if a transaction A has 5 confirmations and spends the same input as a wallet transaction B, B will be reported as having -5 confirmations. If another wallet transaction C spends an output from B, it will also be reported as having -5 confirmations. To detect conflicts with historical transactions in the chain a one-time
-rescan may be needed.
Unlike earlier versions, unconfirmed but non-conflicting transactions will never get a negative confirmation count. They are not treated as spendable unless they’re coming from ourself (change) and accepted into our local mempool, however. The new “trusted” field in the
listtransactions RPC output indicates whether outputs of an unconfirmed transaction are considered spendable.
Bitcoind can now (optionally) asynchronously notify clients through a ZMQ-based PUB socket of the arrival of new transactions and blocks. This feature requires installation of the ZMQ C API library 4.x and configuring its use through the command line or configuration file. Please see docs/zmq.md for details of operation.
NODE_BLOOM service bit
Support for the
NODE_BLOOM service bit, as described in BIP 111, has been added to the P2P protocol code.
BIP 111 defines a service bit to allow peers to advertise that they support bloom filters (such as used by SPV clients) explicitly. It also bumps the protocol version to allow peers to identify old nodes which allow bloom filtering of the connection despite lacking the new service bit.
In this version, it is only enforced for peers that send protocol versions
>=70011. For the next major version it is planned that this restriction will be removed. It is recommended to update SPV clients to check for the
NODE_BLOOM service bit for nodes that report versions newer than 70011.
The Uniform Fiscal Object 0.12 available from: