Bitcoin
Bitcoin is a decentralized P2P electronic cash system without a central server or trusted parties. Users hold the cryptographic keys to their own money and make transactions directly with each other, with the help of the network to check for double-spending. Bitcoins, usually denoted by BTC (e.g. 0.1 BTC), can also be exchanged for traditional currencies like US dollars.
Contents
Introduction
The Bitcoin network runs on peer-to-peer networking, digital signatures and cryptographic proof to make and verify transactions. Nodes broadcast transactions to the network, which records them in a public record of all transactions, called the blockchain. A block is a record of some or all of the most recent Bitcoin transactions that have not yet been recorded in any prior blocks. In order to preserve the integrity of the blockchain, each block in the chain confirms the integrity of the previous one, all the way back to the first one, using hashing.
New bitcoins are generated by the network through the process of mining. Mining involves inserting a new block into the current blockchain, this is difficult because it requires generating a valid hash (in this case a large integer).
A variation in difficulty is achieved by requiring that this integer is below a certain threshold — the data in the block is perturbed by a nonce value, until the data in the block hashes to produce an integer below the threshold — which takes a lot of processing power. The threshold is set by the number of people currently mining for bitcoins so as to achieve a general speed of about 1 block every 10 minutes.
Consensus
The Consensus is a Bitcoin specific term to describe P2P network participants’ compatibility, with the Consensus rules describing implementation details of the protocol to adhere to.
The consensus rules are the specific set of rules that all Bitcoin full nodes will unfailingly enforce when considering the validity of a block and its transactions. For example, the Bitcoin consensus rules require that blocks only create a certain number of bitcoins. If a block creates more bitcoins than is allowed, all full nodes will reject this block, even if every other node and miner in the world accepts it. Adding new consensus rules can generally be done as a softfork, while removing any consensus rule requires a hardfork. Rules regarding the behavior of the mere network protocol are not consensus rules, even if a change to the network protocol behavior breaks backward-compatibility. The consensus rules are only concerned with the validity of blocks and transactions. These rules are called consensus rules because Bitcoin requires that all participants in the Bitcoin economy have consensus (with the meaning of the next definition) as to the consensus rules. If the economy disagrees about the consensus rules, then the currency and economy splits into two or more totally-independent pieces.
Nature of consensus failure
The nature of consensus is a very strict yet completely voluntary uncoordinated interaction of many independent users. It is both a requirement of the networks correct operation, and a facilitator of its correct operation at the same time. You can be considered to be in consensus with any other node that will accept any data structure relevant to consensus as valid that you have accepted as valid (ignoring of course an instance where two different miners both find valid blocks at the same time and each relay theirs to part of the network, the next valid block will decide which preceding block was valid based on which one it extends from). Consensus can be broken violating explicit consensus rules (violating a rule explicitly spelled out as a consensus rule, i.e. the cap of 21 million bitcoin, rate at which they are issued, the maximum size of a block, that a transaction is only valid if citing a valid unspent coin, etc.) or violating unexplicit rules (due to a bug or unintended consequence of design, i.e. a valid structure erroneously being invalidated due to software bug/improper format/etc., or the use of an attack avenue to overstress the node with load due to a bug or bad design). Both types of consensus failures could potentially come to be intentionally or unintentionally.
A discussion of two consensus breaks in Bitcoin Core’s history, one explicit, one unexplicit: https://bitcointalk.org/index.php?topic=702755.0
How to get Bitcoins?
There are a variety of ways to acquire bitcoins:
- Accept bitcoins as payment for goods or services.
- There are several services where you can trade them for traditional currency.
- Find someone to trade cash for bitcoins in-person through a local directory. To find traders near you, you can use LocalBitcoins or a bitcoin map.
- Participate in a mining pool.
- If you have very good hardware, you can solo mine and attempt to create a new block (currently yields 12.5 BTC plus fees). See #Mining.
Bitcoin software
Some points to illustrate above warning:
- As mentioned earlier, different clients implement different rules on #Consensus. For example:
- A #Thin client does per se not implement all rules, but only a subset.
- A #Full node client may be forked to allow customizing options which are incompatible with the network Consensus at large.
- Another full node may be programmed to validate in Consensus until it has itself reached a majority coverage, in order to leverage majority to implement different rules. The assumption is that the minority will follow suit, see #Nature of consensus failure for examples.
- A lot of Linux distributions do not officially package bitcoin clients, and one reason are its special requirements to function on the P2P network. Some bitcoin developers even come to the conclusion the clients should not be packaged at all. See a related fedora request for further information. Using a rolling release distribution does pose additional risks in this respect.
The above implies you should also take continuous due care to test related updates.
Thin client
The thin clients are also named Simple Payment Verification (SPV) clients.
Thin clients do not fully validate the blockchain or compute a full Unspent Transaction Output Set (UTXO). They derive their security in proxy by connecting to a fullnode and downloading the blockheaders. They are still able to guarantee the Proof of Work behind a block is valid, and each blockheader contains a merkle root of all the transactions in the block. This allows them to query full node clients for the blockheaders and the data to prove their transaction is in the merkle root in the blockheader. They however must trust that miners are mining valid blocks, and have no way to make sure rules like the issuance rate or cap of Bitcoins are being followed.
There are several Bitcoin thin client implementations in the official repositories and in the AUR.
Full node
A full node is a bitcoin client which starts with the initial genesis block of the blockchain, and sequentially validates the signature chain of every historical Bitcoin transaction and validity of each historical block to construct upon arriving at the tip of the chain the current Unspent Transaction Output Set (UTXO). This is the current set of unspent coins, and which private keys they are encumbered to. It is called a full node because it obviously verifies the cryptographic integrity of the UTXO set itself. A full node client may or may not also participate in relaying unconfirmed transactions around the network and operate a mempool of all unconfirmed transactions, and may or may not participate in serving the full historical blockchain to new full node clients bootstrapping themselves.
There are several Bitcoin full node implementations in the official repositories and in the AUR.
If you decide to install one: It is possible to run a full node that deletes almost all historical blocks, only keeping the recent history to a certain threshold, but only after having downloaded (260GB as of October 2019) and verified them (which is CPU intensive) in sequence to arrive at the present period it retains. This is to ensure the same guarantee of the cryptographic integrity of the UTXO set. Afterwards, one may reduce storage and limit bandwith.
The initial download of the blockchain can be sped up by increasing the database cache as much as your RAM allows, add dbcache=M to
/.bitcoin/bitcoin.conf where M is the number of megabytes of RAM to allocate.
Mining
The concept of Bitcoin mining is based on searching for an input that is hard to find but easy to prove the existence of. Bitcoin miners construct blocks that consist of a set of transactions users are trying to make and link them to the previously solved block. Miners add a random piece of data to this, and hash a summary of the block. If the hash of this summary is below the desired target of the network, the block is considered valid. Since it is easy to reproduce any individual hash, they are impossible to predict, so the miner does not know which piece of data will create a desirable hash.
Mining requires the use of a miner, which is a program used to compute the required hashes and thus create Bitcoins. To learn more about mining please read this article.
There are several Bitcoin miners in the official repositories, as well as in the AUR.
Источник
What is bitcoin linux
Copy raw contents
UNIX BUILD NOTES
Some notes on how to build Bitcoin Core in Unix.
(For BSD specific instructions, see build-*bsd.md in this directory.)
Always use absolute paths to configure and compile Bitcoin Core and the dependencies. For example, when specifying the path of the dependency:
Here BDB_PREFIX must be an absolute path — it is defined using $(pwd) which ensures the usage of the absolute path.
This will build bitcoin-qt as well, if the dependencies are met.
These dependencies are required:
| Library | Purpose | Description |
|---|---|---|
| libboost | Utility | Library for threading, data structures, etc |
| libevent | Networking | OS independent asynchronous networking |
| Library | Purpose | Description |
|---|---|---|
| miniupnpc | UPnP Support | Firewall-jumping support |
| libnatpmp | NAT-PMP Support | Firewall-jumping support |
| libdb4.8 | Berkeley DB | Optional, wallet storage (only needed when wallet enabled) |
| qt | GUI | GUI toolkit (only needed when GUI enabled) |
| libqrencode | QR codes in GUI | Optional for generating QR codes (only needed when GUI enabled) |
| univalue | Utility | JSON parsing and encoding (bundled version will be used unless —with-system-univalue passed to configure) |
| libzmq3 | ZMQ notification | Optional, allows generating ZMQ notifications (requires ZMQ version >= 4.0.0) |
| sqlite3 | SQLite DB | Optional, wallet storage (only needed when wallet enabled) |
| systemtap | Tracing (USDT) | Optional, statically defined tracepoints |
For the versions used, see dependencies.md
C++ compilers are memory-hungry. It is recommended to have at least 1.5 GB of memory available when compiling Bitcoin Core. On systems with less, gcc can be tuned to conserve memory with additional CXXFLAGS:
Alternatively, or in addition, debugging information can be skipped for compilation. The default compile flags are -g -O2 , and can be changed with:
Finally, clang (often less resource hungry) can be used instead of gcc, which is used by default:
Linux Distribution Specific Instructions
Dependency Build Instructions
Now, you can either build from self-compiled depends or install the required dependencies:
Berkeley DB is required for the wallet.
Ubuntu and Debian have their own libdb-dev and libdb++-dev packages, but these will install Berkeley DB 5.1 or later. This will break binary wallet compatibility with the distributed executables, which are based on BerkeleyDB 4.8. If you do not care about wallet compatibility, pass —with-incompatible-bdb to configure.
Otherwise, you can build Berkeley DB yourself.
SQLite is required for the descriptor wallet:
To build Bitcoin Core without wallet, see Disable-wallet mode
Optional port mapping libraries (see: —with-miniupnpc , —enable-upnp-default , and —with-natpmp , —enable-natpmp-default ):
ZMQ dependencies (provides ZMQ API):
User-Space, Statically Defined Tracing (USDT) dependencies:
If you want to build bitcoin-qt, make sure that the required packages for Qt development are installed. Qt 5 is necessary to build the GUI. To build without GUI pass —without-gui .
To build with Qt 5 you need the following:
Additionally, to support Wayland protocol for modern desktop environments:
libqrencode (optional) can be installed with:
Once these are installed, they will be found by configure and a bitcoin-qt executable will be built by default.
Dependency Build Instructions
Now, you can either build from self-compiled depends or install the required dependencies:
Berkeley DB is required for the wallet:
Newer Fedora releases, since Fedora 33, have only libdb-devel and libdb-cxx-devel packages, but these will install Berkeley DB 5.3 or later. This will break binary wallet compatibility with the distributed executables, which are based on Berkeley DB 4.8. If you do not care about wallet compatibility, pass —with-incompatible-bdb to configure.
Otherwise, you can build Berkeley DB yourself.
SQLite is required for the descriptor wallet:
To build Bitcoin Core without wallet, see Disable-wallet mode
Optional port mapping libraries (see: —with-miniupnpc , —enable-upnp-default , and —with-natpmp , —enable-natpmp-default ):
ZMQ dependencies (provides ZMQ API):
User-Space, Statically Defined Tracing (USDT) dependencies:
If you want to build bitcoin-qt, make sure that the required packages for Qt development are installed. Qt 5 is necessary to build the GUI. To build without GUI pass —without-gui .
To build with Qt 5 you need the following:
Additionally, to support Wayland protocol for modern desktop environments:
libqrencode (optional) can be installed with:
Once these are installed, they will be found by configure and a bitcoin-qt executable will be built by default.
The release is built with GCC and then «strip bitcoind» to strip the debug symbols, which reduces the executable size by about 90%.
miniupnpc may be used for UPnP port mapping. It can be downloaded from here. UPnP support is compiled in and turned off by default. See the configure options for UPnP behavior desired:
libnatpmp may be used for NAT-PMP port mapping. It can be downloaded from here. NAT-PMP support is compiled in and turned off by default. See the configure options for NAT-PMP behavior desired:
It is recommended to use Berkeley DB 4.8. If you have to build it yourself, you can use the installation script included in contrib/ like so:
from the root of the repository.
Otherwise, you can build Bitcoin Core from self-compiled depends.
Note: You only need Berkeley DB if the wallet is enabled (see Disable-wallet mode).
If you need to build Boost yourself:
To help make your Bitcoin Core installation more secure by making certain attacks impossible to exploit even if a vulnerability is found, binaries are hardened by default. This can be disabled with:
Hardening enables the following features:
Position Independent Executable: Build position independent code to take advantage of Address Space Layout Randomization offered by some kernels. Attackers who can cause execution of code at an arbitrary memory location are thwarted if they don’t know where anything useful is located. The stack and heap are randomly located by default, but this allows the code section to be randomly located as well.
On an AMD64 processor where a library was not compiled with -fPIC, this will cause an error such as: «relocation R_X86_64_32 against `. ‘ can not be used when making a shared object;»
To test that you have built PIE executable, install scanelf, part of paxutils, and use:
The output should contain:
Non-executable Stack: If the stack is executable then trivial stack-based buffer overflow exploits are possible if vulnerable buffers are found. By default, Bitcoin Core should be built with a non-executable stack, but if one of the libraries it uses asks for an executable stack or someone makes a mistake and uses a compiler extension which requires an executable stack, it will silently build an executable without the non-executable stack protection.
To verify that the stack is non-executable after compiling use: scanelf -e ./bitcoin
The output should contain: STK/REL/PTL RW- R— RW-
The STK RW- means that the stack is readable and writeable but not executable.
When the intention is to run only a P2P node without a wallet, Bitcoin Core may be compiled in disable-wallet mode with:
In this case there is no dependency on Berkeley DB 4.8 and SQLite.
Mining is also possible in disable-wallet mode using the getblocktemplate RPC call.
Additional Configure Flags
A list of additional configure flags can be displayed with:
Setup and Build Example: Arch Linux
This example lists the steps necessary to setup and build a command line only, non-wallet distribution of the latest changes on Arch Linux:
Note: Enabling wallet support requires either compiling against a Berkeley DB newer than 4.8 (package db ) using —with-incompatible-bdb , or building and depending on a local version of Berkeley DB 4.8. The readily available Arch Linux packages are currently built using —with-incompatible-bdb according to the PKGBUILD. As mentioned above, when maintaining portability of the wallet between the standard Bitcoin Core distributions and independently built node software is desired, Berkeley DB 4.8 must be used.
These steps can be performed on, for example, an Ubuntu VM. The depends system will also work on other Linux distributions, however the commands for installing the toolchain will be different.
Make sure you install the build requirements mentioned above. Then, install the toolchain and curl:
Источник
