Bitcoin Gets An Upgrade: Bitcoin Core Version 0.12.0 Released


Bitcoin Gets An Upgrade: Bitcoin Core Version 0.12.0 Released

One of the many advantages of Bitcoin, and digital currency in general, is that they are almost living technologies. They can be modified and upgraded (some are easier than others to implement) relatively quickly compared to things like fiat currencies, which can take a decade to revise. Improved speed, compatibility and higher security is always under consideration. Now, for all you miners and techies out there, Bitcoin Core has released Version v0.12.0, and here is what you can expect.

What changed? Quite a bit

ECDSA signatures inside Bitcoin transactions now use validation using libsecp256k1 instead 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.

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 -maxuploadtarget parameter. 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 .

With BIP 130, between compatible peers, BIP 130 direct headers announcement is used. This means that blocks are advertized 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.

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 fee rate (as a package) will be evicted and the node’s effective minimum relay fee rate will be increased to match this fee rate plus the initial minimum relay fee rate. The initial minimum relay fee rate is set to 1000 Satoshis per kB.

It is now possible to replace transactions in the transaction memory pool of Bitcoin Core 0.12 nodes. Bitcoin Core will only allow replacement of transactions which have any of their inputs’ nSequence number set to less than 0xffffffff – 1. Moreover, a replacement transaction may only be accepted when it pays sufficient fee, as described in BIP 125.

Transaction replacement can be disabled with a new command line option, – mempoolreplacement=0. Transactions signaling replacement under BIP125 will still be allowed into the mempool in this configuration, but replacements will be rejected. This option is intended for miners who want to continue the transaction selection behavior of previous releases.

You can now have an RPC, or Randome-cookie authentication. When no – rpcpassword is specified, the daemon now uses a special ‘cookie’ file for authentication. This file is generated with random content when the daemon starts, and deleted when it exits. Its contents are used as authentication token. Read access to this file controls who can access through RPC. By default it is stored in the data directory but its location can be overridden with the option – rpccookiefile.

Bitcoin Core has a heuristic ‘priority’ based on coin value and age. This calculation is used for relaying of transactions which do not pay the minimum relay fee, and can be used as an alternative way of sorting transactions for mined blocks. Bitcoin Core will relay transactions with insufficient fees depending on the setting of -limitfreerelay= (default: r=15 kB per minute) and -blockprioritysize=<s>.

In Bitcoin Core 0.12, when mempool limit has been reached a higher minimum relay fee takes effect to limit memory usage. Transactions which do not meet this higher effective minimum relay fee will not be relayed or mined even if they rank highly according to the priority heuristic. The mining of transactions based on their priority is also now disabled by default. To re-enable it, simply set -blockprioritysize= where is the size in bytes of your blocks to reserve for these transactions. The old default was 50k, so to retain approximately the same policy, you would set –blockprioritysize=50000.

Starting with Tor version it is possible, through Tor’s control socket API, to create and destroy ‘ephemeral’ hidden services programmatically. Bitcoin Core has been updated to make use of this. This means that if Tor is running (and proper authorization is available), Bitcoin Core automatically creates a hidden service to listen on, without manual configuration. Bitcoin Core will also use Tor automatically to connect to other .onion nodes if the control socket can be successfully opened. This will positively affect the number of available .onion nodes and their usage.