<p>Arvind Narayanan and Jeremy Clark wrote an excellent paper about that: <a href="https://queue.acm.org/detail.cfm?id=3136559" rel="nofollow noreferrer">Bitcoin's Academic Pedigree</a>. I recommend reading the paper in full, but the following briefly summarizes the paper's content.</p>
<h2>Linked timestamping/verifiable logs</h2>
<p>Bitcoin borrows the blockchain data structure from Bayer, Haber, and Stornetta which described a very similar data structure in context of a timestamping service in the 1990s. The original also makes use of Merkle trees already. The authors suggested regularly publishing the &quot;blockheaders&quot; in a newspaper.</p>
<h2>Byzantine fault tolerance</h2>
<p>Byzantine Fault Tolerance (BFT) describes a distributed network to converge on a shared state even when their are malicious or unstable actors. While the whitepaper doesn't cite a specific source, Nakamoto described Bitcoin as a practical solution to the Byzantine Generals' Problem (a challenge that requires BFT), thus indirectly referencing an enormous body of scientific work done in the 1980s through 2000s. While not mentioned, peer-to-peer networks like BitTorrent (2001) must have served as an inspiration.</p>
<h2>Proof of work</h2>
<p>Originally proposed as a means to deter spam, sybil attacks, and denial of service attacks, PoW failed adoption in those applications due to the stark difference of computing power in various devices.</p>
<h2>Digital cash</h2>
<p>Digital Cash refers to a form of money that can be electronically transferred but exhibits characteristics of cash: final settlement, peer-to-peer transferability, resistance to forging, and transactional privacy. HashCash, b-money, and bit gold discussed ideas of using puzzle solutions as cash. None of these earlier projects had a solution for the doublespending problem, though. DigiCash solved the doublespending problem but required a central operator to issue new tokens.</p>
<h2>Public keys as identies</h2>
<p>While public-key cryptography was discovered in the 70s, the use of public keys as pseudonymous identities was first described by David Chaum in 1981. Since anyone can generate their own key pair, public-key cryptography lends itself to self-certified authentication.</p>
<h2>Secret sauce: Putting it all together</h2>
<p>Prior solutions for Byzantine Fault Tolerance required some level of honest behavior from which Nakamoto sidestepped partially by introducing economic incentives and assuming self-interest. Instead of publishing their chain in the newspaper as Bayer, Haber, and Stornetta floated, Nakamoto uses a peer-to-peer network and proof of work to decentrally author the timestamping data structure. The resulting shared groundtruth solves the doublespending problem that remained unsolved for HashCash, b-money, and bit gold.<br />
The rewards for block authors incentivize collaborative convergent participation, ensuring both BFT but also distributing initial funds to the network. As the network identities derive from self-generated private keys, the peer-to-peer network can be open and permissionless—sidestepping the single points of failure of trusted third parties that caused issues for many previous digital cash projects.</p>

CC BY-SA 4.0
2021-05-04T17:55:13.463Z
Follow up question - I'm trying to understand what prevents participants from issuing fake UTXOs. Nakamoto pointed to Proof of Work and the longest chain to solve the Byzantine Generals Problem, but from what I understand transactions are also verified by nodes. What tech should I research to understand how nodes create consensus on valid transactions?
tjr226
CC BY-SA 4.0
2021-05-04T19:14:08.673Z
Every transaction id is unique, and therefore each transaction is output uniquely traceable. Synchronizing nodes simply keep the full list of all unspent transaction outputs. You can read more on https://bitcoin.stackexchange.com/a/56589/5406, https://bitcoin.stackexchange.com/q/95564/5406, https://bitcoin.stackexchange.com/q/12427/5406
Murch
CC BY-SA 4.0
2021-05-04T20:14:33.140Z
Sorry - I'm phrasing my question poorly. I agree that UTXOs are traceable from the Genesis block. What I'd like to understand is the system that nodes use to get consensus on what valid transactions to put in the mempool. I'll start by going through these Python implementations of Bitcoin nodes, but if there are specific technical subjects I can research that would be very helpful (compared to reading code) https://bitcoin.stackexchange.com/questions/41682/a-complete-bitcoin-implementation-in-python
tjr226
CC BY-SA 4.0
2021-05-04T21:08:38.280Z
The mempool holds unconfirmed transactions. Every node has its own mempool and they don't need to match. They usually overlap almost completely, though. The transactions in the mempool must be valid, and cannot be in conflict with other transactions in the mempool, but only the transactions included in blocks are what everyone converges on and becomes part of the consensus.
Murch
CC BY-SA 4.0
2021-05-04T03:27:26.030Z
2021-05-04T12:24:00.170Z
2021-05-04T12:24:00.170Z
Murch
<p>When watching a tutorial, they mentioned that Bitcoin is based off 4 or 5 technologies that existed for at least a decade before Bitcoin. Satoshi Nakamoto was the first person to combine them all into a digital currency.</p>
<p>I'm aware of at least some of them - SHA-256, ECDSA, peer-to-peer distributed ledger - but want to try and understand all of them.</p>
<p>What other technologies underpin Bitcoin?</p>

<ecdsa><sha256>
What previously existing technologies made Bitcoin possible?
tjr226
# What previously existing technologies made Bitcoin possible?

(Asked by: username_0 on 2021-05-04)

When watching a tutorial, they mentioned that Bitcoin is based off 4 or 5 technologies that existed for at least a decade before Bitcoin. Satoshi Nakamoto was the first person to combine them all into a digital currency.

I'm aware of at least some of them - SHA-256, ECDSA, peer-to-peer distributed ledger - but want to try and understand all of them.

What other technologies underpin Bitcoin?

**Tags:** ecdsa, sha256


---

## 1 answers

### Answer by username_1 on 2021-05-04. Score: 6 | Accepted answer

Arvind Narayanan and Jeremy Clark wrote an excellent paper about that: [Bitcoin's Academic Pedigree](https://queue.acm.org/detail.cfm?id=3136559). I recommend reading the paper in full, but the following briefly summarizes the paper's content.

## Linked timestamping/verifiable logs

Bitcoin borrows the blockchain data structure from Bayer, Haber, and Stornetta which described a very similar data structure in context of a timestamping service in the 1990s. The original also makes use of Merkle trees already. The authors suggested regularly publishing the "blockheaders" in a newspaper.

## Byzantine fault tolerance

Byzantine Fault Tolerance (BFT) describes a distributed network to converge on a shared state even when their are malicious or unstable actors. While the whitepaper doesn't cite a specific source, Nakamoto described Bitcoin as a practical solution to the Byzantine Generals' Problem (a challenge that requires BFT), thus indirectly referencing an enormous body of scientific work done in the 1980s through 2000s. While not mentioned, peer-to-peer networks like BitTorrent (2001) must have served as an inspiration.

## Proof of work

Originally proposed as a means to deter spam, sybil attacks, and denial of service attacks, PoW failed adoption in those applications due to the stark difference of computing power in various devices.

## Digital cash

Digital Cash refers to a form of money that can be electronically transferred but exhibits characteristics of cash: final settlement, peer-to-peer transferability, resistance to forging, and transactional privacy. HashCash, b-money, and bit gold discussed ideas of using puzzle solutions as cash. None of these earlier projects had a solution for the doublespending problem, though. DigiCash solved the doublespending problem but required a central operator to issue new tokens.

## Public keys as identies

While public-key cryptography was discovered in the 70s, the use of public keys as pseudonymous identities was first described by David Chaum in 1981. Since anyone can generate their own key pair, public-key cryptography lends itself to self-certified authentication.

## Secret sauce: Putting it all together

Prior solutions for Byzantine Fault Tolerance required some level of honest behavior from which Nakamoto sidestepped partially by introducing economic incentives and assuming self-interest. Instead of publishing their chain in the newspaper as Bayer, Haber, and Stornetta floated, Nakamoto uses a peer-to-peer network and proof of work to decentrally author the timestamping data structure. The resulting shared groundtruth solves the doublespending problem that remained unsolved for HashCash, b-money, and bit gold.  
The rewards for block authors incentivize collaborative convergent participation, ensuring both BFT but also distributing initial funds to the network. As the network identities derive from self-generated private keys, the peer-to-peer network can be open and permissionless—sidestepping the single points of failure of trusted third parties that caused issues for many previous digital cash projects.

> **Comments:**
> **username_0**: Follow up question - I'm trying to understand what prevents participants from issuing fake UTXOs. Nakamoto pointed to Proof of Work and the longest chain to solve the Byzantine Generals Problem, but from what I understand transactions are also verified by nodes. What tech should I research to understand how nodes create consensus on valid transactions?  
> **username_1**: Every transaction id is unique, and therefore each transaction is output uniquely traceable. Synchronizing nodes simply keep the full list of all unspent transaction outputs. You can read more on https://bitcoin.stackexchange.com/a/56589/5406, https://bitcoin.stackexchange.com/q/95564/5406, https://bitcoin.stackexchange.com/q/12427/5406  
> **username_0**: Sorry - I'm phrasing my question poorly. I agree that UTXOs are traceable from the Genesis block. What I'd like to understand is the system that nodes use to get consensus on what valid transactions to put in the mempool. I'll start by going through these Python implementations of Bitcoin nodes, but if there are specific technical subjects I can research that would be very helpful (compared to reading code) https://bitcoin.stackexchange.com/questions/41682/a-complete-bitcoin-implementation-in-python  
> **username_1**: The mempool holds unconfirmed transactions. Every node has its own mempool and they don't need to match. They usually overlap almost completely, though. The transactions in the mempool must be valid, and cannot be in conflict with other transactions in the mempool, but only the transactions included in blocks are what everyone converges on and becomes part of the consensus.  

---

