Read only blockchain in bitcoind , patch ideas

This question is related to to the ( already nearing 2 GB and always increasing size ) blockchain download needed to use the bitcoin network, and is referencing this previous question :
Is "Reclaiming Disk Space" already implemented? How effective will it be?
Please read it before answering

Currently if I have bitcoind running on 20 machines, or 20 bitcoind running on the same machine, each of them need to download and store 2 GB blockchain, total 40 GB diskspace used and much bandwidth to dowload it 20 time.

I think the easiest way to make it better would be to have a "read-only" blockchain, one of the bitcoind writes it and the others only use it read only to check transactions.

This could be used to be my own trusted blockchain provider, for all my machines and bitcoind running, on the same machine or remotely using sshfs or other mounting options.

Now the questions :
1- How to implement this in bitcoind ? easiest way to do this ?
2- can this be a problem for the bitcoin network itself in any way ?

Rules : I dont want answers like "try poolserverj" or "you dont need that" please ;)

neofutur

Posted 2012-03-17T05:35:43.460

Reputation: 1 495

2My question would be, what is the reason you are running bitcoind on 20 machines? You could run it on one or two machines (two if you want to have a backup) and make every other communicate to those two with anything they need. – ThePiachu – 2012-03-17T08:50:30.020

2many possible reasons, I want to have more than one backup, I want to povide ssh wallets to my friends, I have small devices who dont have enough diskspace to store the blockchain locally. – neofutur – 2012-03-17T17:29:15.360

anyway "why I need this" is not the question, and "20 machines" is just an example, another why is bitcoin scalibility, and the need of trusted blockchain providers, see http://www.slideshare.net/dakami/bitcoin-8776098 particularly the slide 12 ;see also a comment in bitcoin code, main.h around line 1855 : "// FAT32 filesize max 4GB, fseek and ftell max 2GB, so we must stay under 2GB", this could be another reason

– neofutur – 2012-03-17T17:48:37.990

I think this is a good idea for further research and development. An untrusted blockchain provider is interesting too, but perhaps so much harder to do as to not be worth it. (How do you prove an output wasn't spent?) – David Schwartz – 2012-06-20T00:23:15.167

I believe a good solution to this problem will soon be using one node that does not prune, and others that prune blocks aggressively (only keep the last few hundred) that bootstrap from the non-pruned one. – Pieter Wuille – 2012-08-18T21:30:12.810

Answers

I already did working prototype for one bitcoind (with one copy of blockchain) managing multiple wallets: https://bitcointalk.org/index.php?topic=71542.msg96212 It is IMHO easiest thing to to with current codebase and it would fulfill the goal to provide for multiple users' wallets independently while using resources for only one running bitcoind.

But the discussion around it died somehow, looks like nobody tried the prototype and I got only some private inquiries.

Juraj

Posted 2012-03-17T05:35:43.460

Reputation: 339

The problem comes down to trusting a third party. The current client only trusts the designation of the genesis block - you can independently verify all the other blocks derive from that, and have been secured by the highest difficulty.

In theory, you could merely store the sequence of hashes of the blocks (32 bytes per block). But when you receive a Bitcoin transaction, you need to have proof that there is:

Sufficient funds coming from the Bitcoin source ("input transaction").
That those funds haven't been spent previously.

The proof that a Bitcoin address has funds is pretty short - you just need to know the block that contains the transaction, and the proof that the transaction hash is part of the "merkle root" of the block (I think this generally requires just a few hundreds of bytes of data, and you don't have to trust the source of the provider - since you verify it yourself against your stored block chain hashes).

But the 2nd part, knowing that the input hasn't already been spent is much harder - you have to "prove a negative". The only way to know that an input hasn't already been used is to look at ALL transactions since the input was created, and verify that none of them spend the input already.

I think you would have to rely on a trusted source, then, that does retain the entire block chain. You could rely on a signed "statement" from a trusted service (or perhaps multiple independent trusted services), that a particular input has not been spent up through a given block.

mckoss

Posted 2012-03-17T05:35:43.460

Reputation: 839

1"The problem comes down to trusting a third party", in this case I ll be my own "third party blockchain provider" and I trust myself, I also have a very good PGP and OTC wot, so many friends can trust me too ;) – neofutur – 2012-03-17T19:07:09.770

Also, as I understand it the "light" client I want can check everything he needs, he do have the full blockchain , but its read only – neofutur – 2012-03-17T19:09:29.913