<p>I think if this became extensive, this would destabilize the entire network. Since nobody wants that, it won't become extensive.</p>

<p>The most fundamental thing the client does is decide what the current valid block chain is. Suppose I see two competing hash chains on the network. How can I know which one I should follow? The answer is to first make sure both chains are <em>valid</em> -- an invalid block chain can never win. How can I validate the hash chain if I can't make sure each transaction input in it validly claims a previous transaction's output? How can I do that without a full transaction table?</p>

<p>Suppose I see a transaction that claims someone sent me 50 Bitcoins. How can I determine those 50 Bitcoins are in fact valid? Well, I have to make sure that each input in that transaction validly claims an output from a previous transaction. How can I do that if I don't have the full transaction set?</p>

<p>In other words, a client cannot determine if it has received funds if it does not have access to a map of every unclaimed transaction output indexed by transaction ID.</p>

CC BY-SA 3.0
2011-09-08T06:15:10.263Z
It should be noted that the primary use for such "selfish clients" is in embedded device where not only storage but also network and CPU resources are at a premium. The current Android clients are all "selfish" and likely will be for some time to come. Since the folks running Bitcoin on their phone almost certainly have a full-blockchain node at home, they probably will not be a significant source of network problems.
David Perry
CC BY-SA 3.0
2011-09-08T06:19:47.217Z
I think for purposes of analyzing the Bitcoin network, you can treat it as if these clients don't exist. So they provide no benefit to the network (though they provide benefit to their users and to the currency as a whole) but do no harm. They are "selfish", but then their needs are pretty minimal as well. They are perfectly safe when they have a "known trusted" node to connect to.
David Schwartz
CC BY-SA 3.0
2011-09-08T06:25:12.483Z
The problem arises when those "selfish" nodes become such a majority that folks behind firewalls etc who are limited to 8 connections can't find a non-selfish client to connect to. Such clients can certainly `addnode` one or more of the [fallbacks](https://en.bitcoin.it/wiki/Fallback_Nodes) but that's a shoddy workaround at best.
David Perry
CC BY-SA 3.0
2011-09-08T07:00:16.837Z
Hopefully by that time there will be enough people running "generous" nodes to make up the slack. (I run several such nodes that can handle over 1,500 connections each. The busiest rarely see over 300.) Everyone has an interest in keeping the network stable and reliable.
David Schwartz
CC BY-SA 3.0
2011-09-08T12:05:17.697Z
BitcoinJ allows you to build such clients.

**"How can I validate the hash chain if I can't make sure each transaction input in it validly claims a previous transaction's output? How can I do that without a full transaction table?"**

Because BitcoinJ connects to a trusted node it knows that received blocks have been validated to only contain inputs for which there are outputs.
Jan
CC BY-SA 3.0
2011-09-08T12:26:34.677Z
As long as difficulty stays at decent levels, checking the cumulative difficulty of a blockchain through its headers will be a pretty darn good indicator of where to start.  As far as validating blocks or transactions, you would have to spider back through their 'dependencies'.  I'm looking for a better answer than "I think it would destabilize the network" here--I want to see some estimated impacts on block availability, network overhead up or down once the lower amount of downloading is contrasted with re-downloading later, etc.
eMansipater
CC BY-SA 3.0
2011-09-08T12:31:02.657Z
I.e. some statistics on how inter-dependent blocks are alone would go a long way towards a solid answer.
eMansipater
CC BY-SA 3.0
2011-09-08T03:27:26.653Z
2011-09-08T03:27:26.653Z
David Schwartz
<p>Is it possible that in the future, there will be a business in archive services?  Maybe people who wish to spend a very old Bitcoin that is more than x years old will need to wait a few minutes longer so that the archive servers will look it up.  I am using the analogy of present day banking.  My bank has 90 days of activity on-line.  If I want something older, then I have to request it and wait.</p>

CC BY-SA 3.0
2012-01-03T21:45:04.623Z
2012-01-03T21:45:04.623Z
shoeless joe
<p>There is proof of concept work in progress right now to solve this problem.  Basically by creating hub nodes capable of handling many thousands of connections.  These hub nodes are in fact a proxy backed by a real satoshi bitcoin daemon.  This will relieve standard bitcoin nodes from a lot of the connections being used up by these 'selfish' nodes and allow them to continue operating as do now.  Mining pools will have a strong incentive to run hub nodes as it will speed up propogation of their generated blocks as well as ensure they have the best chance of getting new blocks as quickly as possible.</p>

CC BY-SA 3.0
2011-09-08T14:30:57.733Z
2011-09-08T14:30:57.733Z
Shadders
<p>Right now, full clients of the Bitcoin network store every block ever generated (while "thin" clients instead rely on a node which does so).  This greatly increases first-time initialisation for the client, and also has significant implications for network overhead, amongst other things.  <strong>How would the network be impacted if nodes instead stored only the <a href="https://en.bitcoin.it/wiki/Protocol_specification#Block_Headers">headers</a> of most blocks in the blockchain until or unless they "needed" the actual block?</strong></p>

<p>These situations are fairly common, such as:</p>

<ul>
<li>verifying the validity of each new block as it is found and transmitted to the network</li>
<li>any time the client is sending or receiving bitcoins</li>
<li>etc.</li>
</ul>

<p>so that in general clients would still download all blocks broadcast when they were online.  However they would be able to:</p>

<ul>
<li>purge blocks they "don't care about" if storage space is limited</li>
<li>in the typical case, start sending and receiving bitcoins after downloading only the few most relevant blocks (and all the headers of course)</li>
<li>etc.</li>
</ul>

<p>Note that there are usually several entities "invested in" the continued availability of a given block, such as the original miner, who wants their 50 btc earned to remain valid, and anyone who received bitcoins from transactions in that block.  However, one intriguing consequence of this scenario would be that miners are incentivised to include as many transactions in their blocks as possible (currently one can mine without including <em>any</em> transactions if one so desires).  What would the other impacts on functionality and security be?</p>

<p><strong>Edit:</strong>
I'm looking for a better answer than "I think it would destabilize the network" here--I want to see some estimated impacts on block availability, network overhead up or down once the lower amount of downloading is contrasted with re-downloading later, etc.  Some statistics on how inter-dependent blocks are alone would go a long way towards a solid answer.</p>

<p><strong>Edit 2:</strong>
Right now this bounty's going to Shadders in a couple of hours.  But if anyone had more detailed info on the information I asked for in my first edit, they could definitely snipe it.  Any takers? </p>

CC BY-SA 3.0
2011-09-08T01:36:38.517Z
This is relevant: https://gist.github.com/1059233
gavinandresen
CC BY-SA 3.0
2011-09-08T12:28:45.890Z
For those too lazy to click ^ Gavin is considering use of this technique to improve the start-up experience in the normal client.
eMansipater
<blockchain><network><protocol><block-header>
How would the Bitcoin protocol be impacted if nodes only stored the blocks they cared about?
eMansipater
# How would the Bitcoin protocol be impacted if nodes only stored the blocks they cared about?

(Asked by: username_0 on 2011-09-08)

Right now, full clients of the Bitcoin network store every block ever generated (while "thin" clients instead rely on a node which does so). This greatly increases first-time initialisation for the client, and also has significant implications for network overhead, amongst other things. **How would the network be impacted if nodes instead stored only the [headers](https://en.bitcoin.it/wiki/Protocol_specification#Block_Headers) of most blocks in the blockchain until or unless they "needed" the actual block?**

These situations are fairly common, such as:

* verifying the validity of each new block as it is found and transmitted to the network
* any time the client is sending or receiving bitcoins
* etc.

so that in general clients would still download all blocks broadcast when they were online. However they would be able to:

* purge blocks they "don't care about" if storage space is limited
* in the typical case, start sending and receiving bitcoins after downloading only the few most relevant blocks (and all the headers of course)
* etc.

Note that there are usually several entities "invested in" the continued availability of a given block, such as the original miner, who wants their 50 btc earned to remain valid, and anyone who received bitcoins from transactions in that block. However, one intriguing consequence of this scenario would be that miners are incentivised to include as many transactions in their blocks as possible (currently one can mine without including *any* transactions if one so desires). What would the other impacts on functionality and security be?

**Edit:**
I'm looking for a better answer than "I think it would destabilize the network" here--I want to see some estimated impacts on block availability, network overhead up or down once the lower amount of downloading is contrasted with re-downloading later, etc. Some statistics on how inter-dependent blocks are alone would go a long way towards a solid answer.

**Edit 2:**
Right now this bounty's going to username_6 in a couple of hours. But if anyone had more detailed info on the information I asked for in my first edit, they could definitely snipe it. Any takers?

**Tags:** blockchain, network, protocol, block-header

> **Comments:**
> **username_1**: This is relevant: https://gist.github.com/1059233  
> **username_0**: For those too lazy to click ^ Gavin is considering use of this technique to improve the start-up experience in the normal client.  

---

## 3 answers

### Answer by username_6 on 2011-09-08. Score: 5 | Accepted answer

There is proof of concept work in progress right now to solve this problem. Basically by creating hub nodes capable of handling many thousands of connections. These hub nodes are in fact a proxy backed by a real satoshi bitcoin daemon. This will relieve standard bitcoin nodes from a lot of the connections being used up by these 'selfish' nodes and allow them to continue operating as do now. Mining pools will have a strong incentive to run hub nodes as it will speed up propogation of their generated blocks as well as ensure they have the best chance of getting new blocks as quickly as possible.


---

### Answer by username_2 on 2011-09-08. Score: 4

I think if this became extensive, this would destabilize the entire network. Since nobody wants that, it won't become extensive.

The most fundamental thing the client does is decide what the current valid block chain is. Suppose I see two competing hash chains on the network. How can I know which one I should follow? The answer is to first make sure both chains are *valid* -- an invalid block chain can never win. How can I validate the hash chain if I can't make sure each transaction input in it validly claims a previous transaction's output? How can I do that without a full transaction table?

Suppose I see a transaction that claims someone sent me 50 Bitcoins. How can I determine those 50 Bitcoins are in fact valid? Well, I have to make sure that each input in that transaction validly claims an output from a previous transaction. How can I do that if I don't have the full transaction set?

In other words, a client cannot determine if it has received funds if it does not have access to a map of every unclaimed transaction output indexed by transaction ID.

> **Comments:**
> **username_3**: It should be noted that the primary use for such "selfish clients" is in embedded device where not only storage but also network and CPU resources are at a premium. The current Android clients are all "selfish" and likely will be for some time to come. Since the folks running Bitcoin on their phone almost certainly have a full-blockchain node at home, they probably will not be a significant source of network problems.  
> **username_2**: I think for purposes of analyzing the Bitcoin network, you can treat it as if these clients don't exist. So they provide no benefit to the network (though they provide benefit to their users and to the currency as a whole) but do no harm. They are "selfish", but then their needs are pretty minimal as well. They are perfectly safe when they have a "known trusted" node to connect to.  
> **username_3**: The problem arises when those "selfish" nodes become such a majority that folks behind firewalls etc who are limited to 8 connections can't find a non-selfish client to connect to. Such clients can certainly `addnode` one or more of the [fallbacks](https://en.bitcoin.it/wiki/Fallback_Nodes) but that's a shoddy workaround at best.  
> **username_2**: Hopefully by that time there will be enough people running "generous" nodes to make up the slack. (I run several such nodes that can handle over 1,500 connections each. The busiest rarely see over 300.) Everyone has an interest in keeping the network stable and reliable.  
> **username_4**: BitcoinJ allows you to build such clients.  **"How can I validate the hash chain if I can't make sure each transaction input in it validly claims a previous transaction's output? How can I do that without a full transaction table?"**  Because BitcoinJ connects to a trusted node it knows that received blocks have been validated to only contain inputs for which there are outputs.  
> **username_0**: As long as difficulty stays at decent levels, checking the cumulative difficulty of a blockchain through its headers will be a pretty darn good indicator of where to start.  As far as validating blocks or transactions, you would have to spider back through their 'dependencies'.  I'm looking for a better answer than "I think it would destabilize the network" here--I want to see some estimated impacts on block availability, network overhead up or down once the lower amount of downloading is contrasted with re-downloading later, etc.  
> **username_0**: I.e. some statistics on how inter-dependent blocks are alone would go a long way towards a solid answer.  

---

### Answer by username_5 on 2012-01-03. Score: 0

Is it possible that in the future, there will be a business in archive services? Maybe people who wish to spend a very old Bitcoin that is more than x years old will need to wait a few minutes longer so that the archive servers will look it up. I am using the analogy of present day banking. My bank has 90 days of activity on-line. If I want something older, then I have to request it and wait.


---

