<p>I already did working prototype for one bitcoind (with one copy of blockchain) managing multiple wallets: <a href="https://bitcointalk.org/index.php?topic=71542.msg96212" rel="nofollow">https://bitcointalk.org/index.php?topic=71542.msg96212</a> 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.</p>

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

CC BY-SA 3.0
2012-08-20T12:49:47.623Z
2012-08-20T12:49:47.623Z
Juraj
<p>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.</p>

<p>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:</p>

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

<p>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).</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2012-03-17T19:07:09.770Z
"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
CC BY-SA 3.0
2012-03-17T19:09:29.913Z
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
CC BY-SA 3.0
2012-03-17T18:47:41.970Z
2012-03-17T18:47:41.970Z
mckoss
<p>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 :<br>
<a href="https://bitcoin.stackexchange.com/questions/2584/is-reclaiming-disk-space-already-implemented-how-effective-will-it-be">Is &quot;Reclaiming Disk Space&quot; already implemented? How effective will it be?</a><br>
 Please read it before answering  </p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

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

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

CC BY-SA 3.0
2012-03-17T08:50:30.020Z
My 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
CC BY-SA 3.0
2012-03-17T17:29:15.360Z
many 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
CC BY-SA 3.0
2012-03-17T17:48:37.990Z
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
CC BY-SA 3.0
2012-06-20T00:23:15.167Z
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
CC BY-SA 3.0
2012-08-18T21:30:12.810Z
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
<client><blockchain><network><storage-footprint>
Read only blockchain in bitcoind , patch ideas
neofutur
# Read only blockchain in bitcoind , patch ideas

(Asked by: username_0 on 2012-03-17)

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?](https://bitcoin.stackexchange.com/questions/2584/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 ;)

**Tags:** client, blockchain, network, storage-footprint

> **Comments:**
> **username_1**: My 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.  
> **username_0**: many 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.  
> **username_0**: 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  
> **username_2**: 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?)  
> **username_3**: 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.  

---

## 2 answers

### Answer by username_4 on 2012-08-20. Score: 2

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.


---

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

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:

1. Sufficient funds coming from the Bitcoin source ("input transaction").
2. 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.

> **Comments:**
> **username_0**: "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 ;)  
> **username_0**: 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  

---

