<p>1) It's not clear why you think every client having to download the entire block chain is a scalability problem. Pruning currently doesn't take place but it should eventually be possible in theory. Storage space is growing at a much faster rate than Bitcoin is.</p>

<p>2) To validate a new transaction, the only transactions you have to look at are the inputs to make sure it validly claims them. Presumably, you already know every currently-valid transaction output already. You have to check a block in order to accept it anyway.</p>

<p>3) This is the nature of the way Bitcoin prevents double-spending attacks. It's because Bitcoin has adopted a "no central authority at all" approach. Nobody, as far as I know, knows a way to do instantaneous transactions without a central authority. (Consider, for example, if a natural disaster splits the Bitcoin network into two halves and each half sees a conflicting transaction. How would you know?)</p>

CC BY-SA 3.0
2012-02-08T18:45:39.283Z
Space is not the only consideration, right? If Bitcoin was to scale to support billions of transactions, requiring everyone to know about all transactions ever seems unscalable. I probbaly just don't understand this too well, which is why I am asking.
Ziffusion
CC BY-SA 3.0
2012-02-08T18:48:04.627Z
@SanjayBhandari Bitcoin wouldn't support billions of transactions by putting them all in the main block chain. In that sense, what we have today is not scalable.
David Schwartz
CC BY-SA 3.0
2012-02-08T18:50:57.153Z
Also, don't you have to go backwards a bit to check validity? Or do you just check the most recent inputs?

Right, I do know why the confirmations are there. What I am asking is that with this built in delay, how can Bitcoin support large scale, and platforms that require extremely fast transactions.
Ziffusion
CC BY-SA 3.0
2012-02-08T18:55:21.467Z
I'm not sure what you mean by "go backwards". Your client already knows that every block is has accepted is valid, and it already knows which transaction outputs are still claimable. Updating this information is done when you receive a block, so you don't have to do it when you get a transaction. (Otherwise, you might receive/accept an invalid block and get on the wrong chain.)
David Schwartz
CC BY-SA 3.0
2012-02-08T18:18:43.477Z
2012-02-08T18:18:43.477Z
David Schwartz
<p>Scalability is something that will have to be considered, but it's not going to be a critical issue, for several reasons.</p>

<ol>
<li><p>Not everyone will need a full node. Lightweight clients offer almost as much security with very modest hardware requirements.</p></li>
<li><p>Not all transactions will appear on the blockchain. There are ways to make secure, instant, off-the-chain transactions requiring minimal trust.</p></li>
</ol>

CC BY-SA 3.0
2012-07-12T08:31:18.167Z
2012-07-12T08:31:18.167Z
Meni Rosenfeld
<p>It will not scale (to mass-market adoption) if you want to put all transactions directly into the blockchain. </p>

<p>There needs to be a hierarchy of services built on top of the core protocol. In addition to improving scalability, they can also offer all kinds of features that some people need, such as reversible transaction, instant (no-confirmation) transfers, verified accounts, or anonymity. The blockchain would be used as a clearing house between those services. Most people would not need to interact directly with it, but they can still rely on the guarantees it provides to the economy backed by the chain.</p>

<p>Just because the underlying protocol is radically peer-to-peer does not mean that you cannot have hierarchies layered over it. Just because git is peer-to-peer does not mean that anyone has the same impact on Linux kernel development. In the Bitcoin world, there will still be banks for example, and credit cards, and insurance companies. The difference is that no matter how powerful those become, they cannot mess with the money supply (and create coins for themselves out of thin air). If they screw up enough that a large number of people stop trusting them, they can be cut out of the loop.</p>

<blockquote>
  <p>Because of how a transaction ALWAYS needs to be confirmed (at least 6 times?) over P2P, the transfers are effectively far from instantaneous. There is a built in delay. Isn't this a problem? </p>
</blockquote>

<p>The confirmations make it impossible for someone to double-spend. If you trust the other party enough, you do not have to wait for this. Same if you have other ways to get back at them if they do cheat. If you are a merchant, you can just calculate a percentage of fraud due to loss. Or take an insurance policy. Shop owners already do that in the real world (to mitigate theft), as do credit card processors. If you provide a service to them (like one month VPN), you can stop doing that if the payment "bounces". If you ship physical goods, you can wait three hours for confirmation easily. You can buy and sell currencies instantaneously on trading platforms like MtGox (so you don't need to trust or even know who you are trading with, as long as you trust the platform).</p>

<p>Waiting for confirmations allows you to (in an automated fashion) accept payment from someone who you know nothing about, without trusting anyone else to vouchsafe, either. That is a nice extra feature of Bitcoin, but it comes in addition to "real-world" guarantees you already have.</p>

CC BY-SA 3.0
2012-02-09T05:18:35.473Z
2012-02-09T05:39:10.080Z
2012-02-09T05:39:10.080Z
Thilo
<p>I have been looking into the Bitcoin protocol / algorithm a bit. I have the basics down, I think, but there are a lot of questions about how the whole thing is supposed to scale. For example,</p>

<ol>
<li>Each client currently downloads the entire block chain, right? How is this scalable? They are supposed to be able to prune the Merkel trees, but I haven't gotten a good insight into how this works in P2P.</li>
<li>What was the thought process behind tracking transactions the way they are? You kind of have to traverse a lot of that tree to validate new transactions? Right?</li>
<li>Because of how a transaction ALWAYS needs to be confirmed (at least 6 times?) over P2P, the transfers are effectively far from instantaneous. There is a built in delay. Isn't this a problem? There is some delay already because of the nature of the algorithm that accepts the transaction into a block (solving the reverse hash).</li>
</ol>

<protocol><algorithms><scalability>
Bitcoin protocol / algorithm scalability
Ziffusion
# Bitcoin protocol / algorithm scalability

(Asked by: username_0 on 2012-02-08)

I have been looking into the Bitcoin protocol / algorithm a bit. I have the basics down, I think, but there are a lot of questions about how the whole thing is supposed to scale. For example,

1. Each client currently downloads the entire block chain, right? How is this scalable? They are supposed to be able to prune the Merkel trees, but I haven't gotten a good insight into how this works in P2P.
2. What was the thought process behind tracking transactions the way they are? You kind of have to traverse a lot of that tree to validate new transactions? Right?
3. Because of how a transaction ALWAYS needs to be confirmed (at least 6 times?) over P2P, the transfers are effectively far from instantaneous. There is a built in delay. Isn't this a problem? There is some delay already because of the nature of the algorithm that accepts the transaction into a block (solving the reverse hash).

**Tags:** protocol, algorithms, scalability


---

## 3 answers

### Answer by username_3 on 2012-02-09. Score: 8 | Accepted answer

It will not scale (to mass-market adoption) if you want to put all transactions directly into the blockchain.

There needs to be a hierarchy of services built on top of the core protocol. In addition to improving scalability, they can also offer all kinds of features that some people need, such as reversible transaction, instant (no-confirmation) transfers, verified accounts, or anonymity. The blockchain would be used as a clearing house between those services. Most people would not need to interact directly with it, but they can still rely on the guarantees it provides to the economy backed by the chain.

Just because the underlying protocol is radically peer-to-peer does not mean that you cannot have hierarchies layered over it. Just because git is peer-to-peer does not mean that anyone has the same impact on Linux kernel development. In the Bitcoin world, there will still be banks for example, and credit cards, and insurance companies. The difference is that no matter how powerful those become, they cannot mess with the money supply (and create coins for themselves out of thin air). If they screw up enough that a large number of people stop trusting them, they can be cut out of the loop.

> Because of how a transaction ALWAYS needs to be confirmed (at least 6 times?) over P2P, the transfers are effectively far from instantaneous. There is a built in delay. Isn't this a problem?

The confirmations make it impossible for someone to double-spend. If you trust the other party enough, you do not have to wait for this. Same if you have other ways to get back at them if they do cheat. If you are a merchant, you can just calculate a percentage of fraud due to loss. Or take an insurance policy. Shop owners already do that in the real world (to mitigate theft), as do credit card processors. If you provide a service to them (like one month VPN), you can stop doing that if the payment "bounces". If you ship physical goods, you can wait three hours for confirmation easily. You can buy and sell currencies instantaneously on trading platforms like MtGox (so you don't need to trust or even know who you are trading with, as long as you trust the platform).

Waiting for confirmations allows you to (in an automated fashion) accept payment from someone who you know nothing about, without trusting anyone else to vouchsafe, either. That is a nice extra feature of Bitcoin, but it comes in addition to "real-world" guarantees you already have.


---

### Answer by username_1 on 2012-02-08. Score: 8

1) It's not clear why you think every client having to download the entire block chain is a scalability problem. Pruning currently doesn't take place but it should eventually be possible in theory. Storage space is growing at a much faster rate than Bitcoin is.

2) To validate a new transaction, the only transactions you have to look at are the inputs to make sure it validly claims them. Presumably, you already know every currently-valid transaction output already. You have to check a block in order to accept it anyway.

3) This is the nature of the way Bitcoin prevents double-spending attacks. It's because Bitcoin has adopted a "no central authority at all" approach. Nobody, as far as I know, knows a way to do instantaneous transactions without a central authority. (Consider, for example, if a natural disaster splits the Bitcoin network into two halves and each half sees a conflicting transaction. How would you know?)

> **Comments:**
> **username_0**: Space is not the only consideration, right? If Bitcoin was to scale to support billions of transactions, requiring everyone to know about all transactions ever seems unscalable. I probbaly just don't understand this too well, which is why I am asking.  
> **username_1**: @SanjayBhandari Bitcoin wouldn't support billions of transactions by putting them all in the main block chain. In that sense, what we have today is not scalable.  
> **username_0**: Also, don't you have to go backwards a bit to check validity? Or do you just check the most recent inputs?  Right, I do know why the confirmations are there. What I am asking is that with this built in delay, how can Bitcoin support large scale, and platforms that require extremely fast transactions.  
> **username_1**: I'm not sure what you mean by "go backwards". Your client already knows that every block is has accepted is valid, and it already knows which transaction outputs are still claimable. Updating this information is done when you receive a block, so you don't have to do it when you get a transaction. (Otherwise, you might receive/accept an invalid block and get on the wrong chain.)  

---

### Answer by username_2 on 2012-07-12. Score: 1

Scalability is something that will have to be considered, but it's not going to be a critical issue, for several reasons.

1. Not everyone will need a full node. Lightweight clients offer almost as much security with very modest hardware requirements.
2. Not all transactions will appear on the blockchain. There are ways to make secure, instant, off-the-chain transactions requiring minimal trust.


---

