Bitcoin Core (formerly Bitcoin-Qt) is the third Bitcoin client, developed by Wladimir J. van der Laan based on the original reference code by Satoshi Nakamoto. It has been bundled with bitcoind since version 0.5. Bitcoin-Qt has been rebranded to Bitcoin Core since version 0.9.0.
Bitcoin Core is a full-fledged client that forms the basis of the network. It is characterized by a high level of security, confidentiality and stability. However, it has fewer options and takes up quite a bit of disk space and RAM. The MIT Digital Currency Initiative funds some of development of Bitcoin Core. The project also maintains the cryptography library libsecp256k1.
Bitcoin Core can be used as a desktop client for regular payments or as a server utility for merchants and other payment services.
Bitcoin 0.1 was released on 9 January 2009 by Satoshi Nakamoto with only Windows supported. This was followed by some minor bug fixing versions. On 16 December 2009 Bitcoin 0.2 was released. It included a Linux version for the first time and made use of multi-core processors for mining. In version 0.3.2 Nakamoto included checkpoints as a safeguard. After the release of version 0.3.9 Satoshi Nakamoto left the project and shortly after stopped communicating on online forums. By this time development of the software was being undertaken by a wide group of independent developers which is referred to as a community, many of whom had various ideas on how to improve bitcoin.
Between 2011 and 2013 new versions of the software were released at Bitcoin.org. Developers wanted to differentiate themselves as creators of software rather than advocates for bitcoin and so now maintain bitcoincore.org for just the software.
Bitcoin-Qt version 0.5.0 was released on 1 November 2011. It introduced a front end that uses the Qt user interface toolkit. The software previously used Berkeley DB for database management. Developers switched to LevelDB in release 0.8 in order to reduce blockchain synchronization time. The update to this release resulted in a minor blockchain fork on the 11 March 2013. The fork was resolved shortly afterwards. Seeding nodes through IRC was discontinued in version 0.8.2. In this release transaction fees, also known as relay fees, were reduced from 50,000 satoshis to 10,000 satoshis. From version 0.9.0 the software was renamed to Bitcoin Core. Transaction fees were reduced again by a factor of ten as a means to encourage microtransactions. Although Bitcoin Core does not use OpenSSL for the operation of the network, the software did use OpenSSL for remote procedure calls. Version 0.9.1 was released to remove the network’s vulnerability to the Heartbleed bug.
Release 0.10 was made public on 16 February 2015. It introduced a consensus library which gave programmers easy access to the rules governing consensus on the network. The developers have stated that for consensus on soft forks a super-majority of 95% of hash power is required for agreement. In version 0.11.2 developers added a new feature which allowed transactions to be made unspendable until a specific time in the future. Bitcoin Core 0.12.1 was released on April 15, 2016 and enabled multiple soft forks to occur concurrently. Around 100 contributors worked on Bitcoin Core 0.13.0 which was released on 23 August 2016. It introduced more than ten significant changes.
In July 2016, the CheckSequenceVerify soft fork activated.
In October 2016, Bitcoin Core’s 0.13.1 release featured the “Segwit” soft fork that included a scaling improvement aiming to optimize the bitcoin blocksize. The patch which was originally finalised in April, and 35 developers were engaged to deploy it. This release featured Segregated Witness (SegWit) which aimed to place downward pressure on transaction fees as well as increase the maximum transaction capacity of the network. Estimates place the total block size using SegWit at about 1.7& The 0.13.1 release endured extensive testing and research leading to some delays in its release date. SegWit prevents various forms of transaction malleability. SegWit was activated by miners on 24 August 2017, at block 481,824.
- Introduction of a new generation anonymous interface (REST standard).
- Improving the security of operations. The place of outdated OpenSSL came the modern system of saving data Libsecp256k.
- There are more convenient view. It is possible to view the wallet of another person and be aware of their operations;
- Developed and installed a library of approvals, which allowed to improve the interaction of bitcoin with other software;
- There is a system that opens up new opportunities in the field of operations management. This, in turn, speeds up the process of transactions in the network;
- Work continues on the division of one core into several different utilities with a narrow specialization.
The original creator of the bitcoin client has described their approach to the software’s authorship as it being written first to prove to themselves that the concept of purely peer-to-peer electronic cash was valid and that a paper with solutions could be written. While the majority of peers on the network may use Bitcoin Core, the developers’ influence on bitcoin is limited by the choice of which implementation people voluntarily decide to use. The lead developer is Wladimir J. van der Laan, who took over the role on 8 April 2014. Gavin Andresen was the former lead maintainer for the software client. Andresen left the role of lead developer for bitcoin to work on the strategic development of its technology. He left because he didn’t want to get involved with trivial decision-making.
The code was originally stored at Sourceforge before being available on GitHub. Because there is no formal structure, development is based around Bitcoin Improvement Proposals or BIPs, which are similar to Request for Comments. Public mailing lists are used to vet initial expressions of ideas. If enough support is displayed a BIP document is written. This is the standard for sharing ideas and gaining community feedback on improving bitcoin and was initiated by Amir Taaki in 2011.
The roadmap for the client includes data link layer solutions for scalability. Core developers view bitcoin as a settlement layer. Bitcoin Core is one of several full node client implementations that are actively deployed. Alternatives include Bitcoin XT, Bitcoin Classic and Bitcoin Unlimited. All are derived from Bitcoin Core and contain implementation of hard fork proposals. These software forks allow bitcoin miners to demonstrate their vote on the direction of bitcoin’s development.
Core developers prefer to gradually, not rapidly enlarge bitcoin’s transaction handling capabilities. Core developers believe in the premise that barriers to running a full Bitcoin Core node should be kept low as possible so that the blockchain layer at the very lowest level remains highly decentralized. Core has reputation for tending for being risk averse. This is demonstrated by the reluctance of Core developers to increase the network’s ability to process transactions.
Bitcoin Core includes a transaction verification engine and connects to the bitcoin network as a full Bitcoin Core node. Moreover, a cryptocurrency wallet, which can be used to transfer funds, is included by default. The wallet allows for the sending and receiving of bitcoins. It does not facilitate the buying or selling of bitcoin. It allows users to generate QR codes to receive payment.
The software validates the entire blockchain, which includes all bitcoin transactions ever. This distributed ledger which has reached more than 130 gigabytes in size must be downloaded or synchronised before full participation of the client may occur. A command line-based daemon with a JSON-RPC interface, bitcoind, is bundled with Bitcoin Core. It provides access to testnet, a global testing environment that imitates the bitcoin main network or Mainnet. It uses an alternative blockchain where real bitcoin are not used and the blockchain cannot be adversely affected. Regtest or Regression Test Mode creates a private blockchain which is used as a local testing environment. bitcoin-cli is the third program included. It allows users to send RPC commands to bitcoind.
Checkpoints have been hard coded into the client. These maintain data integrity by keeping a part of the blockchain data in the source code where it is able to be compared to the blockchain when its downloading is complete. A one megabyte block size limit was added in 2010 by Satoshi Nakamoto as a temporary anti-spam measure. This limited the maximum network capacity to about three transactions per second. Since then, some minor changes to the software have improved network capacity incrementally. A network alert system was included by Satoshi Nakamoto as a way of informing users of important news regarding bitcoin. In November 2016 it was retired. It had become obsolete as news on bitcoin is now widely disseminated. Miners were able to signal their decision on the incorporation of new features by voting as per BIP9, however this signaling is now disabled as of BIP8, and miners can only accelerate new features as of BIP8.
A powerful scripting language is used to define transactions. This Forth-like language is part of one of three distinct Apis. It can enable various transaction parameters. The script uses reverse Polish notation for validation. ScriptPubKey is used to “lock” transactions based on a set of future conditions. scriptSig is used to meet these conditions or “unlock” a transaction. Operations on the data are performed by various OP_Codes. Two stacks are used — main and alt. Looping is forbidden.
- Compatibility with Linux (both GNOME and KDE), Mac OS X and Windows
- All functionality of the original wxWidgets client
- Asks for confirmation before sending coins
- CSV export of transactions
- Clearer transaction list with status icons and real-time filtering
- Progress bar on initial block download
- Languages: Dutch, English, German, Chinese and many more. Translations are being done by volunteers on Transifex.
- Sendmany support in UI (send to multiple recipients in one transaction)
- Multiple unit support, can show subdivided bitcoins (mBTC, µBTC) for users that like large numbers (only decimal units)
- Splash screen that details progress
- Debug window
- Payment requests (BIP 70)
- Coin control
- bitcoin-cli as a RPC client, instead of bitcoind executable functioning both as a server and as a RPC client
- Post frequency: about 1 post per month
- Twitter fans: 10,457
- Alexa rating: 166,043
Bitcoin Core is often criticized for being slow in downloading and verifying the Bitcoin transaction database (the blockchain). The download may be quicker using the bootstrap method. NOTE: As of version 0.10.0 it is now slower to download the blockchain via the torrent than it is to download the full blockchain through the P2P client.
It has also been criticized for “hogging” upload bandwidth when peers connect to download the blockchain (possible only when run with port 8333 accessible to outside connections). This perceived “issue” has been discussed extensively on GitHub. Most modern routers support quality-of-service that can be configured to properly share the internet connection across all services, and even deprioritise Bitcoin traffic. Bitcoin Core includes a script for Linux to configure QoS on an individual host. Windows users can also use third-party software such as Netbalancer to throttle the application’s upload bandwidth and ensure that one has enough upload bandwidth available for regular computer and internet use to be unaffected.
Among the disadvantages of Bitcoin Core is to identify the following:
- Requires a very long synchronization wallet;
- Bitcoin Core has special requirements for PC hardware;
- A fully loaded Bitcoin Core client weighs about 92 gigabytes, so you’ll need a lot of free space on the hard drive.
Wallet management is also cumbersome. Unlike clients such as Armory, MultiBit, Electrum and others only one wallet at a time is supported, and its location is required to be the same as the blockchain storage, making it difficult to place the wallet on an encrypted drive. It is recommended to backup the wallet.dat file every 50 transactions, due to the way Bitcoin Core handles change.
A Bitcoin Improvement Proposal (BIP) is a design document, typically describing a new feature for Bitcoin with a concise technical specification of the feature and the rationale for it. This is broadly similar to the way in which Internet “Request for Comments” (RFCs) and the Python computer language’s “Python Enhancement Proposals” (PEPs) are used.
The process itself is documented in BIP 2, and BIP 123 provides a categorization. 2 BIP process, revisedBIP 2 specifies the BIP process. BIP numbers are awarded liberally. As of February 2017, 152 BIP numbers have been assigned, but only 27 BIP’s have reached the active/final stages.9 Version bits with timeout and delayBIP specifies a state machine for determining 95% miner consensus of soft forks. There has been one successful BIP 9 soft fork, and one is (Segregated Witness), as of 2017 open for voting. 16 Pay to script hash allows transactions to be sent to a script hash (Bitcoin Core address starting with 3) instead of a public key hash (addresses starting with 1). To spend bitcoins sent via P2SH, the recipient must provide a script matching the script hash, and data which makes the script evaluate to true. The recipient might need the signatures of several people to spend these bitcoins, or a password might be required, or the requirements could be completely unique.32 Defines HD walletsThese HD (‘Hierarchical Deterministic”) wallets can be shared partially or entirely with different systems.39 Mnemonic code or sentences for the generation of deterministic wallets. 43 Adds a “Purpose Field” for use HD wallets to determine the further structure; for example, the scheme described in BIP44 should use the value 44’ as the “purpose”.44 Logical hierarchy for deterministic wallets based on the algorithm described in BIP32 and “purpose” scheme described in BIP43. 65 CHECKLOCKTIMEVERIFYCLTV allows a transaction output to be unspendable until some specific point of time in the future.112 CHECKSEQUENCEVERIFY CSV enables making a Bitcoin Core address (starting with 3) which can’t spend bitcoin received, for a specified amount of time after receiving. One can have a 2-of-3 multisig address, which times out to a backup rule, unless there is 2-of-3 consensus.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.