Today marks the official release ofBitcoin Core0.12.0, the twelfth generation of Bitcoin's reference client as first launched by Satoshi Nakamoto seven years ago. Developed by close to 100 contributors over seven months, the latest version of Bitcoin Core includes more than 20 improvements, particularly regarding performance, security and usability.
These are the sixth most notable changes.
Memory Pool Limiting
Memory pools are the collections of unconfirmed transactions as stored individually by all full nodes. Memory pools fill up in between blocks as new transactions are transmitted over the Bitcoin network and are depleted when these transactions are included in blocks. But if a series of subsequent blocks remain full for an extended period – either due to legitimate transactions or spam attacks – memory pools might not deplete completely, and backlogs could build up. With no maximum limit, the backlog might even grow to the point where nodes run out of memory and crash. (This is the “crash landing” scenario former Bitcoin XT lead developer Mike Hearn feared.)
Memory pool limiting, as the name suggests, enforces a hard limit on the maximum size of memory pools to prevent this scenario. If the maximum is reached, nodes reject or clear their memory pools of transactions that offer the lowest amount of fees per byte.
Full node operators can configure their limits, but the default maximum size in Bitcoin Core 0.12.0 is set on 300 megabytes.
Blockchain Pruning for Wallet Users
One of the burdens of running a full node is the requirement to store the complete blockchain. This adds up to55 gigabytes at the time of this writing, and can grow another 50 gigabytes per year under the current 1-megabyte block size limit.
To decrease this requirement, Bitcoin Core 0.12.0 allows users to prune the blockchain, which means they can get rid of older data once their node has verified it. The amount of data to keep is configurable, though Bitcoin Core 0.12.0 will still require a minimum 2 gigabytes of disk space.
Pruning the blockchain does mean these nodes will no longer be able to share all the blockchain data with peers, such as full nodes syncing with the network for the first time.
(It should be noted that pruning the blockchain was first introduced in Bitcoin Core 0.11.0, but was not yet available for users running Bitcoin Core as a wallet.)
Upload Traffic Limiting
Full nodes continually transmit and relay transactions and blocks to each other over Bitcoin’s peer-to-peer network. This typically requires a modest amount of data to be downloaded, but sharing that same data with several peers at the same time can add up to significant upload costs.
Bitcoin Core 0.12.0 introduces a configurable data cap for upload traffic. If this cap comes within reach, the node will seize uploading blocks older than a week, typically requested by nodes first syncing with the network. Additionally, any light clients will be disconnected and no longer served any block data.
Opt-in Replace-by-fee
As the number of transactions on the Bitcoin network increases, not all transactions might fit into blocks. As such, miners will probably pick the transactions sent by users who included most fees. This means that some transactions – from users that paid too low a fee – could never confirm at all. And since many full nodes and miners currently reject conflicting transactions (sent from the same inputs as an earier transaction), low fee transactions can get “stuck” on the network.
To solve this, Bitcoin Core 0.12.0 introduces opt-in replace-by-fee. If a transaction is sent using opt-in replace-by-fee, users can replace their own transaction with a newer transaction by including a higher fee. (This also means that miners can increase their income, as they get to pick transactions that include higher fees.)
The “opt-in” part of opt-in replace-by-fee means these types of transactions will not be the default, and will be flagged as replace-by-fee transactions on the Bitcoin network. Anyone relying on zero-confirmation transactions should want to monitor for these replace-by-fee transactions, as these could very easily be reverted until they are confirmed. (Of course, zero-confirmation transactions were never secure.)
Whether opt-in replace-by-fee will actually be useful depends on Bitcoin miners; they ultimately decide which transactions to include in blocks, and under what policies.
Tor by Default
While Bitcoin is often claimed to provide anonymity to users, this is not entirely true. Bitcoin users can be de-anonymized, for example, through the peer-to-peer network. If it is determined from which IP-address a transaction originated, this information can be used to identify Bitcoin users.
To protect users' privacy, Bitcoin Core 0.12.0 automatically connects to the Bitcoin network through anonymizing tool Tor (The Onion Router) – ifTor is installed on the same computer. Tor encrypts data and routes it through several nodes all across the world before broadcasting it. This makes it hard – perhaps impossible – to trace where a Bitcoin transaction originated.
(It should be noted that using Tor in itself might not be sufficient to protect a Bitcoin user’s identity. SeeBitcoin Magazine'sBeginners Guide to Bitcoin Privacyfor more information.)
Faster Signature Validation
Signatures are the cryptographic trick where private keys are “combined” with any other data to calculate a unique string of numbers. Corresponding public keys can be used to verify that the signatures were created using the private keys. In Bitcoin's case, signatures are effectively used to prove ownership of bitcoin, and, as such, to validate transactions.
But there are several ways to conduct this cryptographic trick, which could result in different signatures – all valid in their own way. And if different Bitcoin nodes apply different methods for validation, some nodes might consider certain transactions valid while other nodes do not, which could split the Bitcoin network.
Following up on a soft fork to solve this problem last year, Bitcoin Core 0.12.0 now switches all validation from the “OpenSSL” cryptographic library to “libsecp256k1”, developed by Dr. Pieter Wuille, Gregory Maxwell and other Bitcoin Core developers.
As an added benefit, this new signature validation scheme requires less CPU-power, lowering the cost of running a full node and significantly decreasing block validation time.
For a full list of improvements, see Bitcoin Core 0.12.0's release notes onGitHub.
Thanks to Bitcoin Core lead developer Wladimir van der Laan, andCiphrexCEO and Bitcoin Core developer Eric Lombrozo for proofreading and added feedback.
No comments:
Post a Comment