19

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 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 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?

Improve this question
2
  • 3
    This is relevant: gist.github.com/1059233
    – gavinandresen
    Commented Sep 8, 2011 at 1:36
  • 1
    For those too lazy to click ^ Gavin is considering use of this technique to improve the start-up experience in the normal client.
    – eMansipater
    Commented Sep 8, 2011 at 12:28

3 Answers 3

Reset to default
5
+50

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.

Improve this answer
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.

Improve this answer
7
  • 1
    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
    Commented Sep 8, 2011 at 6:15
  • 3
    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
    Commented Sep 8, 2011 at 6:19
  • 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.
    – David Schwartz
    Commented Sep 8, 2011 at 7:00
  • 2
    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
    Commented Sep 8, 2011 at 12:05
  • 1
    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
    Commented Sep 8, 2011 at 12:26
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.