29

The most important reason is that the original Satoshi codebase was written in C++. A system like Bitcoin has extremely strong requirements about consistency in behaviour: all nodes on the network must accept and reject the exact same blocks, or we risk a fork. The first choice to avoid bugs that risk introducing inconsistency is to not rewrite the code from ...


25

I gave a keynote address at cppcon 2016 about almost this exact issue. There are a variety of reasons why C++ is an excellent language choice for blockchain applications like Bitcoin. Blockchain applications have a large attack surface. They're meant to interoperate with a large number of untrusted endpoints while still providing reliable service to local ...


16

Pay-to-PubKey (P2PK) and pay-to-PubKey-Hash (P2PKH) were both introduced in the original Bitcoin 0.1 release. P2PK was used by default for mining and payments received using the interactive IP-to-IP payment protocol; P2PKH was intended for use in non-interactive payments---but P2PKH transactions take up more space in the blockchain than P2PK. Is this space ...


15

As someone who was involved in doing that migration at the time, I believe it was the right decision. LevelDB is far from perfect, but I wouldn't know what else to use. In particular: BDB is much slower for our usage (large atomic batch writes, small random reads). There were reports of database corruption as well with BDB, at a time when it was used far ...


13

The book Mastering Bitcoin would be a good solid start (although it might not answer all your questions). It is also available for free.


12

I assume this question is about Bitcoin Core's internal operations. This description is valid for version 0.8 and later (up to 0.14 at least). One part of the system deals with the active chain, which is the longest valid chain of blocks (stored in $DATADIR/blocks) that we know of. This active chain gets blocks appended to - and occasionally removed when ...


12

I am not aware of an extensively commented version of the Bitcoin sourcecode, but you could check out the Bitcoin Developer Reference and you can read online the book Mastering Bitcoin by Andreas M. Antonopoulos, which covers Bitcoin's technical aspects extensively. There is also Princeton's Free Online Bitcoin course, which goes into details on some ...


12

Disclosure: I'm a Blockstream co-founder Major feature contributions to Bitcoin Core: Greg Maxwell, Andrew Poelstra and myself (as well as several other contributors) worked on libsecp256k1, a well-tested library for efficient elliptic curve cryptography using the curve secp256k1. Bitcoin Core switched signing to it in 0.10 and verification in 0.12 (with a ...


12

The bitcoin price is determined by a free market of buyers and sellers. There is no way to calculate the price on your own without an external source. I suppose the only exception to this would be if you ran your own bitcoin exchange and you had enough users and volume to produce a fair market price.


12

Introduction The key to finding out where a piece of code is without already knowing where it is is to start at the thing that will eventually lead to what you want to find. These can be logically thought through. For example, for relay and validation, these all occur after a node has received a block or transaction, so begin at the point where a block or ...


11

Most of the fixes have been implemented in Bitcoin Core's master branch, or earlier versions, as standard transaction checks that prevent default Bitcoin Core nodes from relaying or mining transactions that break the rules. Here are some details: Non-DER encoded ECDSA signatures These are currently non-standard, so Bitcoin Core nodes (since 0.8.0,...


11

The Schnorr implementation was never in Bitcoin Core. Rather it is in the libsecp256k1 library that is a subtree in Bitcoin Core. The commit you reference is actually a commit in that library which appears in Core's commit history because the subtree in Core is periodically updated with the libsecp256k1 upstream source code. The reason for removal is ...


11

In my view, the main implementation detail to be worked out with Dandelion is ensuring that there are no new DoS vectors introduced. In the existing transaction relay model of Bitcoin Core, transactions that do not make it into a node's mempool -- a proxy for what we expect to be (eventually) mined -- do not get relayed to other nodes. In the Dandelion ...


11

The separation between internal and external addresses comes from BIP32. Using a different chain for each permits you to give out an xpub for just the external ones to an auditor. They would then be able to observe your incoming payments, but not your spending.


10

To understand Bitcoin Core, the best resource is probably the source code itself: https://github.com/bitcoin/bitcoin To help understand what is going on in the code, try the developer documentation and the Princeton Bitcoin Book. Keep in mind that the code gets updated faster than the documentation, so the code should be your source of truth. Some ...


9

At the moment in my opinion, Gavin does indeed control Bitcoin Project to some extent. He is widely recognised as the main developer behind it and could probably push his authority on a lot of subjects if he so desired. However, I am under the impression that he would not perform such actions - they would undermine the credibility of Bitcoin and be bad for ...


9

In the Bitcoin blockchain, each block has a 32-bit field called version. Right now, it takes on simple small values like 2 or 3. As an example of changes, block version 3 introduced new rules about transaction validity, as well as anti-malleability measures. Miners with the new Bitcoin client create blocks with the version set to 3 to signal their ...


9

The Developer Documentation may also be of use.


8

There are a number of "core" developers. And the ones who have access to commit directly to the Github project obviously have more "power" than other people. Since the software is open source you can of course make your own copy of it and modify it to your likings but you won't be able to change any of the "rules" of the network unless you get the rest of ...


8

That's because of the QT translation files, see https://github.com/bitcoin/bitcoin/search?l=typescript I'm not sure why they are recognized as TypeScript (it's just XML), I guess it's because of the filename extension .ts.


8

My new book "A Dissection of Bitcoin" examines the original Bitcoin source code written by Satoshi. As for now, it is the first and only book available that helps you read the Bitcoin source code.


8

BIP 100: Jeff Garzik Miners vote on blocksize, constrained between 1 and 32 MB. BIP 101: Gavin Andresen Blocksize increases to 8 MB, and doubles every two years after that. (This is what XT implements.) BIP 102: Jeff Garzik Blocksize increase to 2 MB. (Intended as a fallback that everyone can agree on.) BIP 103: Pieter Wuille Blocksize increase by 17.7% each ...


8

The problem arises from the uneven propagation of information in the network. While the propagation of small blocks is fast, i.e., every miner gets to know a new block approximately at the same time, this is no longer true for large blocks. Large blocks take a lot of time to be forwarded to every node in the network, since this includes miners, these miners ...


8

Do you modify the block or do you not modify the block? If you don't modify the block, it still pays the mining reward to the same account. So you've just done what everyone wants you to do. If you do modify the block, it won't be valid anymore until and unless you mine it. That leaves you two choices: 1) You can ignore this block and mine some other ...


8

Dorier is correct that Neutrino/SPV nodes are not full nodes, because they do not verify the entirety of the blockchain, leaving potential room for attack. However, the portrayal that Neutrino is no better than other SPV modes is not correct. Neutrino is a form of SPV which improves greatly over other implementations in regards to privacy. All SPV modes ...


7

However, the paper is a high level overview of Bitcoin, and does not specify important parts of the protocol. That's true, and Hal Finney noted this when the bitcoin paper was published to the metzdowd cryptography mailing list. (The Bitcoin paper was published before the Bitcoin source code.) Unfortunately I am having trouble fully understanding the ...


7

Information on current (ie, not past/public/resolved) security issues should be sent to the private bitcoin-security@lists.sourceforge.net mailing list.


7

FYI the code under discussion is available here on GitHub. -> is a member access operator in C++, just as . is. They both expect the name of an object's member on the right (e.g. a member function or variable). The difference is that . expects an object on the left, whereas -> expects a pointer to an object which it first dereferences. So chainActive....


7

The size of secp256k1's coordinate field is 2256 - 232 - 977. That means there are only 232 + 977 (about 4 billion) possible 32-byte combinations that are not a valid coordinate. Only slightly less than half (around 2255 - 1.17 * 2127) of those are the X coordinate of a point on the curve (in fact, for every valid X coordinate, there are either exactly 0 ...


6

I don't think there's really any better reason than "Satoshi Nakamoto chose to write the code that way, and nobody ever changed it". There's no inherent reason why these values couldn't be loaded from a configuration file, but there's a general principle that config files are intended for parameters that are user configurable. A Bitcoin user couldn't ...


Only top voted, non community-wiki answers of a minimum length are eligible