<p>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 scratch.</p>

<p>Although all programming languages have flaws, and C++ is no exception, there are various reasons that make it an appropriate choice. An easily-overlooked one is that it provides very tight control over memory usage. Many modern languages (especially those that rely on garbage collection) make it hard if not impossible to reason about tight bounds of memory usage. Since Bitcoin Core is a security-critical application that is directly exposed to the Internet, it is nontrivial to guarantee that there is no way to trigger it to allocate large amounts of memory, thrashing the machine's swap space, or worse, killing the process.</p>

<p>This is in addition to a good balance between high-level where desired but also many avenues for performance optimization. Performance may be more important than is immediately obvious, as the convergence of the network relies on quick validation and propagation of blocks. If blocks take too long to validate compared to their creation frequency, economic factors start to unfairly advantage larger/faster miners (see the Selfish Mining attack, for example). Under extreme conditions, if blocks would take ~minutes to validate, the network may fail to converge at all, as nodes simply don't hear about blocks in time anymore.</p>

CC BY-SA 3.0
2016-09-05T13:42:18.313Z
"A system like Bitcoin has extremely strong requirements about consistency in behaviour" which is exactly why Ethereum promotes a diversity of implementations. The Satoshi codebase formed a *de facto* standard, to write a competing implementation is to stress-test the specification.
spraff
CC BY-SA 3.0
2016-09-05T14:27:52.417Z
"make it hard if not impossible to reason about tight bounds of memory usage"  Right, because having tight control over memory usage has never caused security issues...  http://heartbleed.com/
NPSF3000
CC BY-SA 3.0
2016-09-05T14:32:22.460Z
@spraff And everyone runs the same one, because they're afraid of differences. In consensus systems, variety simply doesn't work. Even the satoshi client cannot just change rules of the network.
Pieter Wuille
CC BY-SA 3.0
2016-09-05T14:33:46.660Z
@NPSF3000 Fair point, but modern C++ hardly ever needs manual memory management (as opposed to C), though it does become harder when you want to avoid relying on over-eager copying.
Pieter Wuille
CC BY-SA 3.0
2016-09-05T21:56:06.550Z
I think the garbage collection fanboys (Java?) are going to disagree.
Peter Mortensen
CC BY-SA 3.0
2016-09-06T09:02:58.743Z
@PieterWuille When Ethereum becomes more widely adopted on different devices, diversity of clients will be more normal. Simply **having** a variety of clients in parallel development is useful for finding bugs in the design, specification, and implementation, even if hardly anyone uses them in practice.
spraff
CC BY-SA 3.0
2016-09-06T09:12:45.833Z
Sure, and Bitcoin also has a variety of clients (even Bitcoin Core's unit tests are reimplemented in Python), which helps with finding problems. But it's not a guarantee, and you shouldn't use reimplementations in production. That's just asking for problems. N different implementations means ~N^2 combinations of sources of possible inconsistencies.
Pieter Wuille
CC BY-SA 4.0
2018-07-31T02:13:53.193Z
_"it is nontrivial to guarantee that there is no way to trigger it to allocate large amounts of memory, thrashing the machine's swap space, or worse, killing the process"_ -> Sounds like the argument for GCs!
hmijail
CC BY-SA 3.0
2016-09-05T11:11:30.540Z
2016-09-05T14:12:12.720Z
2016-09-05T14:12:12.720Z
Pieter Wuille
<p>I gave a <a href="https://www.youtube.com/watch?v=w4jq4frE5v4" rel="noreferrer">keynote address at cppcon 2016</a> about almost this exact issue. There are a variety of reasons why C++ is an excellent language choice for blockchain applications like Bitcoin.</p>

<p>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 clients. This requires keeping tight control over resources like memory and CPU usage.</p>

<p>Modern CPUs have lots of cores. Some parts of blockchain applications parallelize perfectly (like checking digital signatures) while some parts don't parallelize at all (like executing transactions in order). Modern C++ has a very good mix of effective inter-thread communication and optimization of single-thread performance.</p>

<p>C++ doesn't have a run time that stops the world or manages memory, giving your application consistent control over this behavior. Move semantics allow you to get objects that <em>behave</em> like values (<code>a=b; a+=1;</code> does not change <code>b</code>) but <em>perform</em> like references (deep copies are avoided except where needed).</p>

<p>Smart pointers allow you to avoid the costs of GC without the tedium of manual memory management. Design patterns like RAII makes code easier to maintain. Template metaprogramming facilitates independence between APIs and implementations.</p>

<p>C++'s inheritance scheme makes the design of complex type hierarchies easier.</p>

<p>The language is both mature and maintained. The compiler technology is extremely solid, yet new features are still being added. And the new features are aimed at solving real issues. Debuggers and analytical tools of all kinds are available for everything from performance profiling to automatic detection of issues of all kinds.</p>

CC BY-SA 3.0
2016-09-06T08:58:59.533Z
Upvoted. This goes into more detail than my own answer.
Pieter Wuille
CC BY-SA 3.0
2018-03-25T16:19:35.123Z
But to summarize, there's no mandatory point why it has to be C++ right?
Ini
CC BY-SA 3.0
2018-03-26T08:00:41.947Z
No. Other languages have advantages and disadvantages, but I think performance would have suffered with any other choice (but C).
David Schwartz
CC BY-SA 4.0
2018-07-25T04:20:31.940Z
C is not the only language that compiles to machine code
Alexander Mills
CC BY-SA 4.0
2018-07-31T02:24:23.880Z
_"C++ doesn't have a run time that stops the world or manages memory, giving your application consistent control over this behavior."_-> but it does! C++'s runtime is the one taking care of freeing memory when you don't do it explicitly. So you're actually pitting your ad-hoc, unnoticed memory management with a purposefully developed GC – which would have saved you from a whole class of bugs. And, according to [C++11's memory model author Hans Boehm](http://www.hpl.hp.com/techreports/2003/HPL-2003-215.ps), you are possibly causing *worse* pauses than those caused by a GC.
hmijail
CC BY-SA 3.0
2016-09-05T23:44:20.453Z
2017-02-02T03:34:35.527Z
2017-02-02T03:34:35.527Z
David Schwartz
<p>What made the core developers choose C++ as the main programming language for implementing bitcoin? Was this because of their personal preference? Or another reason?</p>

CC BY-SA 3.0
2016-09-05T19:44:18.030Z
The correct answer would be: find the author and ask him :) But even then, the truth is always the same: developers choose the programming languages they know and love
Andrea Corbellini
<bitcoin-core-development><c++>
Why is bitcoin written in C++?
Vincent
# Why is bitcoin written in C++?

(Asked by: username_0 on 2016-09-05)

What made the core developers choose C++ as the main programming language for implementing bitcoin? Was this because of their personal preference? Or another reason?

**Tags:** bitcoin-core-development, c++

> **Comments:**
> **username_1**: The correct answer would be: find the author and ask him :) But even then, the truth is always the same: developers choose the programming languages they know and love  

---

## 2 answers

### Answer by username_2 on 2016-09-05. Score: 34

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 scratch.

Although all programming languages have flaws, and C++ is no exception, there are various reasons that make it an appropriate choice. An easily-overlooked one is that it provides very tight control over memory usage. Many modern languages (especially those that rely on garbage collection) make it hard if not impossible to reason about tight bounds of memory usage. Since Bitcoin Core is a security-critical application that is directly exposed to the Internet, it is nontrivial to guarantee that there is no way to trigger it to allocate large amounts of memory, thrashing the machine's swap space, or worse, killing the process.

This is in addition to a good balance between high-level where desired but also many avenues for performance optimization. Performance may be more important than is immediately obvious, as the convergence of the network relies on quick validation and propagation of blocks. If blocks take too long to validate compared to their creation frequency, economic factors start to unfairly advantage larger/faster miners (see the Selfish Mining attack, for example). Under extreme conditions, if blocks would take ~minutes to validate, the network may fail to converge at all, as nodes simply don't hear about blocks in time anymore.

> **Comments:**
> **username_3**: "A system like Bitcoin has extremely strong requirements about consistency in behaviour" which is exactly why Ethereum promotes a diversity of implementations. The Satoshi codebase formed a *de facto* standard, to write a competing implementation is to stress-test the specification.  
> **username_4**: "make it hard if not impossible to reason about tight bounds of memory usage"  Right, because having tight control over memory usage has never caused security issues...  http://heartbleed.com/  
> **username_2**: @username_3 And everyone runs the same one, because they're afraid of differences. In consensus systems, variety simply doesn't work. Even the satoshi client cannot just change rules of the network.  
> **username_2**: @username_4 Fair point, but modern C++ hardly ever needs manual memory management (as opposed to C), though it does become harder when you want to avoid relying on over-eager copying.  
> **username_5**: I think the garbage collection fanboys (Java?) are going to disagree.  
> **username_3**: @username_2 When Ethereum becomes more widely adopted on different devices, diversity of clients will be more normal. Simply **having** a variety of clients in parallel development is useful for finding bugs in the design, specification, and implementation, even if hardly anyone uses them in practice.  
> **username_2**: Sure, and Bitcoin also has a variety of clients (even Bitcoin Core's unit tests are reimplemented in Python), which helps with finding problems. But it's not a guarantee, and you shouldn't use reimplementations in production. That's just asking for problems. N different implementations means ~N^2 combinations of sources of possible inconsistencies.  
> **username_6**: _"it is nontrivial to guarantee that there is no way to trigger it to allocate large amounts of memory, thrashing the machine's swap space, or worse, killing the process"_ -> Sounds like the argument for GCs!  

---

### Answer by username_7 on 2016-09-05. Score: 30

I gave a [keynote address at cppcon 2016](https://www.youtube.com/watch?v=w4jq4frE5v4) 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 clients. This requires keeping tight control over resources like memory and CPU usage.

Modern CPUs have lots of cores. Some parts of blockchain applications parallelize perfectly (like checking digital signatures) while some parts don't parallelize at all (like executing transactions in order). Modern C++ has a very good mix of effective inter-thread communication and optimization of single-thread performance.

C++ doesn't have a run time that stops the world or manages memory, giving your application consistent control over this behavior. Move semantics allow you to get objects that *behave* like values (`a=b; a+=1;` does not change `b`) but *perform* like references (deep copies are avoided except where needed).

Smart pointers allow you to avoid the costs of GC without the tedium of manual memory management. Design patterns like RAII makes code easier to maintain. Template metaprogramming facilitates independence between APIs and implementations.

C++'s inheritance scheme makes the design of complex type hierarchies easier.

The language is both mature and maintained. The compiler technology is extremely solid, yet new features are still being added. And the new features are aimed at solving real issues. Debuggers and analytical tools of all kinds are available for everything from performance profiling to automatic detection of issues of all kinds.

> **Comments:**
> **username_2**: Upvoted. This goes into more detail than my own answer.  
> **username_8**: But to summarize, there's no mandatory point why it has to be C++ right?  
> **username_7**: No. Other languages have advantages and disadvantages, but I think performance would have suffered with any other choice (but C).  
> **username_9**: C is not the only language that compiles to machine code  
> **username_6**: _"C++ doesn't have a run time that stops the world or manages memory, giving your application consistent control over this behavior."_-> but it does! C++'s runtime is the one taking care of freeing memory when you don't do it explicitly. So you're actually pitting your ad-hoc, unnoticed memory management with a purposefully developed GC – which would have saved you from a whole class of bugs. And, according to [C++11's memory model author Hans Boehm](http://www.hpl.hp.com/techreports/2003/HPL-2003-215.ps), you are possibly causing *worse* pauses than those caused by a GC.  

---

