# Bitcoin Protocol Development

## Week 1 Topic
### Based on an "Incomplete History of Bitcoin Development"
<i> How have show-stopping bugs or disruptions to the network been handled in the past? </i>

### Centralization of Power: Alerts and Checkpoints

In the summer of 2010 checkpoints are introduced as a safeguard against malicious peers broadcasting low-diff chains. In theory, this gives Satoshi the power to decide which chain is the correct one; a patched, newly released client could point to a now newly valid chain. The soon-after introduced alert system further centralizes bug response power to Satoshi.

### The First Incident

The first major bug is the 15th August 2010 critical overflow bug. An integer overflow is used to make a negative total transaction with two big outputs. Satoshi releases a patched version and tells miners to re-org the block with the affected transaction out of history.

### The alert system

A week after the bug, Satoshi introduces an alert system. The alert can also trigger a safe mode that disables all money-handling RPC methods. Only Satoshi has a key to this system. Satoshi never ended up using it, but some alerts were issued once he stepped away from the project in 2010.

A full list of alerts issued can be found on the [bitcoin wiki](https://en.bitcoin.it/wiki/Alert_system). It was indeed used by core developers to issue alerts for security upgrades, with the last bug-related alert being issued on the 11th of April 2014 for the OpenSSL hearbleed vulnerability. A final alert was issued on January 19, 2017, displaying the message "Alert Key Compromised".

On the 1st of November 2016, the alert system is retired again. A few years later the alert private keys were also made public at the Building on Bitcoin conference and in an [email to the bitcoin-dev mailing list](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016189.html) by Bryan Bishop on the 3rd of July 2018. In the email vulnerabilities of the alert system are also detailed. The alert system was entirely removed from Bitcoin Core in version [0.12.1](https://bitcoin.org/en/alert/2016-11-01-alert-retirement#software-without-the-alert-system).

## Checkpoints

The last checkpoint was introduced on [block height 295000](https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L160). It's purpose then relegated to protect against spamming a relatively low difficulty chain to syncing nodes, no further checkpoint height has been added since. The checkpoints are part of the [validation code](https://github.com/bitcoin/bitcoin/blob/0dfc25f82a01d9fec26380d95915df31e1fe2c02/src/validation.cpp#L3102) in Bitcoin Core. A change introduced by Gregory Maxwell soon after the inclusion of the latest checkpoint block basically made their purpose obsolete. He introduced a check for the accumulated proof of work in [PR 9053](https://github.com/bitcoin/bitcoin/pull/9053). His work finally distanced the checkpointing code away from Bitcoin Core dictating which the best chain is in the event of a split, or related network bug.

### The role of BIPs

The first Bitcoin improvement proposal (BIP1) is authored by Amir Taaki. Future BIPs also contain post-mortems to unexpected and future bugs.

One such BIP, BIP 50, was authored after an unexpected hardfork on the 11th of March 2013. A change from Berkeley DB to LevelDB introduced an involuntary fix to a previous bug with the original Berkely DB implementation. A badly configured maximum number of database locks in the original Berkeley DB-based version led to an implicit maximum block size, inconsistent with the actual consensus rules. After the introduction of LevelDB, a big block was mined by upgraded clients, but rejected by older clients with the Berkeley DB bug, leading to a chain split. As soon as the split was detected, core developers issued an alert and contacted pool operators to downgrade their nodes. The pre-0.8 chain was then viewed as the 'valid' chain. A double spend on a merchant was indeed attempted. A follow-up fork is also defined in the BIP. It was done on the 16th of August 2013, block 252451, forking unpatched nodes out of the network.

### Two DOS attacks - with very different handling

A more complete list of Bitcoin vulnerabilities is hosted on the [bitcoin wiki](https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures). Two of these are further described below because they provide interesting case studies to compare vulnerability responses. One is JJ's (Chris Jeffrey) infamous "Breaking Bitcoin" DOS attack, the other a more recent DOS and inflation bug (CVE-2018-17144).

JJ disclosed an OOM attack that could lead to Bitcoin Core nodes shutting down on systems with less than 10 GB of RAM to Bitcoin Core maintainer Pieter Wuille. A fix was made available in Bitcoin Core v0.15.0. The code patching the issue however was not marked as such and the issue remained unannounced. JJ proceeded to break this unofficial embargo 70 days after his initial disclosure during his talk at the Breaking Bitcoin conference, presenting a full talk detailing the issue. To much criticism, he finished his talk with the now infamous line ["This conference is called Breaking Bitcoin - I'm sorry"](https://www.youtube.com/watch?v=0WCaoGiAOHE&t=10958s).

CVE-2018-17144 was caused by an optimization added in Bitcoin Core version 0.14. The bug was initially reported on September 17 2018 as a crash to the Bitcoin Core maintainers Pieter Wuille, Greg Maxwell, and Wladimir Van Der Laan. They further shared the report with other Bitcoin Core developers, of which Matt Corallo identified a critical inflation bug. More developers were informed to alert companies to the DOS bug and a patch was prepared. A patch is made available soon after a new version of Bitcoin Core is tagged. Between the initial report of the bug and the tagged patch only 12 hours passed. The inflation bug is kept secret until the full disclosure on the 20th of September 2018.

### Current Disclosure Policy

Bitcoin Core describes the disclosure process on their [contact](https://bitcoincore.org/en/contact/) page with the sentence: `To report security issues: [e-mail] (not for support).`

### My opinions

I believe that Bitcoin could use a more transparent and stricter mechanism to deal with vulnerabilities. Yes, CVE-2018-17144 was handled well. Multiple developers worked on different fronts to get a release out as soon as possible. Some worked on patching, some on getting the release tagged and built as soon as possible and others contacted and co-operated with miners. However. at some point, a lot of people knew about the bug, without it being public knowledge yet. A more stringent distribution of roles, planned out and distributed beforehand, could have prevented this. There is also no clear social contract with the disclosing party as to what constitutes an acceptable disclosure timeline. The question of 'when is it ok to talk about the issue?' is not answered.

Besides, no program reimbursing researchers for their security findings exists. Bitcoin got very lucky so far with bugs being found and exploited only by well-intentioned participants. I am not convinced this will remain like this, especially with Bitcoin making better-funded enemies. An indication of this is the IRS recently looking to hire security researchers to break hardware wallets.

CVE-2018-17144 was disclosed by BCash developer awemany. Even though many rated the bug as the most severe since the original 2010 inflation bug, he hardly got any financial recuperation for his disclosure by the Bitcoin community, even after some Bitcoin developers shared his donation address.

### Some More Questions

Are bugs given the attention that they deserve and how confident do you feel that future responses will work out?

Should we re-introduce centralized response systems like the alert system?