decoupling of wallet and blockchain

[GoogleCodeExporter]

Currently the BlockChain depends on the Wallet and calls methods directly. I 
believe that this is not correct.

In my eyes the BlockChain doesn't even have to know about the Wallet. It should 
be the other way around. And i'll take that statement one step further by 
saying that the Wallet shouldn't work on the BlockChain but should communicate 
with the Node.

In the bitcoin wiki there is a page about the bitcoin infrastructure: 
https://en.bitcoin.it/wiki/Infrastructure

While the 'wallet protocol' doesn't seem to be finished yet it should be clear 
that the Wallet can work by communicating with the Node via the 'p2p protocol'.

I'll attach a patch against r70 that removes the Wallet dependency in the 
BlockChain. It is pretty unpolished but my intention here is to spark the 
discussion about the more fundamental decoupling mentioned above.

Original issue reported on code.google.com by fha...@gmail.com on 12 May 2011 at 5:51

Attachments:

• wallet-uncoupling.patch

[GoogleCodeExporter]

Going via some p2p protocol doesn't make a whole lot of sense. The "wallet 
protocol" is something Luke invented and I never really understood, the closest 
real code is probably something like WebCoins protocol.

That said, having BlockChain accept listeners is a good improvement. It makes 
the API a bit more confusing because it's not as obvious how to connect wallets 
and blockchains together, or even that you have to do that, but we can address 
this with documentation and some kind of higher level glue classes.

Original comment by hearn@google.com on 12 May 2011 at 6:18

[GoogleCodeExporter]

Afaik it should be possible to implement the wallet without relying on a local 
blockstore. The wallet can get all the information it needs from any node. 
A local node (inclusive blockchain) has the advantage that you don't have to 
trust on a third party and that you'll get the data you want faster.
But for a very thin client it should be possible to just implement the wallet 
part and connect it to a remote node.

Original comment by fha...@gmail.com on 12 May 2011 at 7:46

[GoogleCodeExporter]

I don't think you could trust a node without having a local store of at least 
the headers. It seems to me any node that was at all involved in a mining pool 
would have an incentive to lie about the value of your keys. 

Original comment by jwsam...@gmail.com on 12 May 2011 at 9:39

[GoogleCodeExporter]

> I don't think you could trust a node without having a local store of at least 
the headers. It seems to me any node that was at all involved in a mining pool 
would have an incentive to lie about the value of your keys. 

That however is not up to the code to decide.

The library should support this mode of operation (a really thin client, that 
only holds the keys), and the user would need to choose a node (or group of 
nodes) that he trusts. Seeing how big the block chain is, I'd think this would 
become the default way to implement mobile clients.

Original comment by thilopl...@googlemail.com on 13 May 2011 at 5:26

[GoogleCodeExporter]

Any modern mobile can store 5mb of data per year without problems and besides, 
like I said to Miron, you don't really have to keep all of them. The chance of 
needing a block gets much lower as you go further back from the head. We could 
just pick some arbitrary number (if not 120 then 1000) and keep them in a ring 
buffer. But only worth it if storage is really an end-user complaint.

Having thought about it more, I'm not sure it's so easy to decouple these 
objects. To use the getheaders optimization on first launch the Peer needs to 
know that there are no keys created before a particular block, so it can 
request only what's necessary. If the BlockChain doesn't talk to the Wallet, 
then the Peer has to on its behalf anyway.

I'd rather avoid introducing too much abstraction right now. A good 
implementation of SPV mode is the first goal and will take a while. After that, 
there might be a simple way to extend it to support keys-only operation a la 
WebCoin, but there might also be no point.

Original comment by hearn@google.com on 13 May 2011 at 8:44

[GoogleCodeExporter]

I don't see why a 'wallet only' implementation shouldn't be able to trust in 
the network more then a local node. 

If you assume that you can't get transactions before the client is first 
launched you can just get the last 10 blocks from the network. Declare the 
oldest one your 'head' and ask for new blocks every 10 minutes or use something 
like C2DM. 

When you get a new block from a peer you block that peer for a while (let's say 
a week). That way it should be possible to be sure that no one is messing with 
the data unless the network is subverted. But then bitcoin itself is in trouble.

If there is a new transaction for the client it can be displayed as 
0/unconfirmed until the next blocks are received. If the user really want's to 
make sure that a transaction is valid he can load the related blocks, but 
anything in the blockchain that is older than a few blocks should be valid.

The 'head' is updated when there are more than 10 blocks that the client knows 
about. This includes the 10th to last block and the status of the wallet at 
this point.

At least that's what i am thinking ...

Original comment by fha...@gmail.com on 13 May 2011 at 9:04

[GoogleCodeExporter]

When wallet only was brought up I assumed the intention was to not look at the 
blocks at all. Sounds like the goal would be to still scan the blocks for your 
own transactions and discard all blocks but a subset. I agree that would be 
possible.
What I would be very scared of is the client asking a random node for the value 
of a given key without seeing the block with the transaction in it.

Original comment by jwsam...@gmail.com on 13 May 2011 at 12:12

[GoogleCodeExporter]

I'm going to close this out - we can discuss a specific design change on the 
mailing list if somebody proposes one (ideally with a patch).

Original comment by hearn@google.com on 6 Jul 2011 at 12:46

• Changed state: WontFix