Ideas for a thin client for a hardware wallet

[pilotniq]

I'm new to Bitcoin, and I'd like to bounce some ideas for a thin client for Bitcoin hardware wallets. I may have misunderstood some fundementals.

I'm considering hardware devices, which would hold addresses and private keys. They would be used to securely store the private keys, and have an Ethernet connection for communicating with the P2P bitcoin network.

The wallet should be able to display the balances of the addresses, and spend bitcoins for the addresses. It has no ambition to verify transactions from other nodes on the network.

I'm thinking the client won't need to store much blockchain information except unspent inputs for its' own addresses. It might track the last six verified blocks in the block-chain and assume that that means that there is no fork. If the keypairs are generated on the device, it will know that there are no transactions in the blockchain for the addresses before they were created.

It will listen for 'deposits' to its address, update the balance, and remember the unspent outputs in order to be able to refer to them in output transactions.

I'm thinking this will let me make a thin client without needing a separate server.

Did I miss something? Is it immoral ;-) to connect to the Bitcoin network without validating third party transactions? Any other think-o's?

Thanks!

[lophie]

Welcome to the scene. You just described electrum client. Now go read about it and try it out.

[pilotniq]

Welcome to the scene.

Thank you.

You just described electrum client. Now go read about it and try it out.

My impression was that Electrum uses a server, whereas the system I described doesn't need one.

Electrum's Wiki page describes it as a "client-server protocol".

[grue]

see: multibit, bitcoinj, bitcoin for android

[lophie]

The things you described to be fetched from the network dictates the need of a server. An online entity that is providing you with specific information regarding specific addresses and block headers. Unless you are a full node (Mining or not), You are using a client server arch. Calling it not one does not magically make it so.

[pilotniq]

see: multibit, bitcoinj, bitcoin for android

The Thin Client Security wiki page says that header-only clients "... downloads a complete copy of the headers for all blocks in the entire blockchain": Why is this neccessary?

[pilotniq]

The things you described to be fetched from the network dictates the need of a server. An online entity that is providing you with specific information regarding specific addresses and block headers. Unless you are a full node (Mining or not), You are using a client server arch. Calling it not one does not magically make it so.

I was intending to pretend to be a full node on the P2P network, thereby not requiring a server.

[grue]

The things you described to be fetched from the network dictates the need of a server. An online entity that is providing you with specific information regarding specific addresses and block headers. Unless you are a full node (Mining or not), You are using a client server arch. Calling it not one does not magically make it so.

I was intending to pretend to be a full node on the P2P network, thereby not requiring a server.

>full node
>no blocks
pick one

[pilotniq]

>full node
>no blocks
pick one

Why?

Is it not possible to join the P2P network without having all blocks? Just to be able to listen to blocks and inject transactions without needing a separate server.

I'm just trying to understand this without having to code a test program.

[DeathAndTaxes]

>full node
>no blocks
pick one

Why?

Is it not possible to join the P2P network without having all blocks? Just to be able to listen to blocks and inject transactions without needing a separate server.

I'm just trying to understand this without having to code a test program.

Can you do it? Sure.  Can you do it securely?  Probably not.  The ugly part is it likely will work for some time until a dedicated attacker tries to exploit your paper thin security and then when it fails it (and given enough time it will), it will fail hard and cost either you or someone who relied on your a massive amount of funds.

Without at least the blockheaders your node has no way of knowing what other nodes are telling you is truthful.  How long do you think it would take a single GPU computer to generate 6 (or 60) blocks of fake history at difficulty 1?  If all your node does is ask for 6 most recent blocks ... ok here are 6 blocks I made for you and see your massive payment of 500 BTC is there, so please send me the gold/wire transfer/computer hardware I asked for.  Only later do you find out that you were fed a false history.  Yes I have 500 BTC but in the "real" blockchain I sent them to myself not you.  A double spent that you could not only not prevent, you couldn't even see that it had occurred.

But wait you say I connect to 8 independent nodes?  Do you?  If there is enough incentive to steal don't you think a botnet for example could produce tens of thousands of "independent" nodes and poison the pool of potential nodes around you.  Now currently there is very limited value in an attacker doing that as each full node (in in the case of electrum the electrum server is doing the full node validation) implicitly does NOT TRUST anything any nodes tells it and validates every block, every transactions, every output back to the genesis block if necessary.  So a "poisened node" strategy has very little utility. 

But against a "naive node" well that is a different story.  Let the false history games begin.

TL/DR:   This is money.  If someone can exploit your system to steal money they will.  Period. 

[pilotniq]

>full node
>no blocks
pick one

Why?

Is it not possible to join the P2P network without having all blocks? Just to be able to listen to blocks and inject transactions without needing a separate server.

I'm just trying to understand this without having to code a test program.

Can you do it? Sure.  Can you do it securely?  Probably not.  The ugly part is it likely will work for some time until a dedicated attacker tries to exploit your paper thin security and then when it fails it (and given enough time it will), it will fail hard and cost either you or someone who relied on your a massive amount of funds.

Don't get me wrong. I'm interested in designing a secure solution, and that's why I'm bringing it up for discussion. I want to learn.

Without at least the blockheaders your node has no way of knowing what other nodes are telling you is truthful.

How do the blockheaders help?

 How long do you think it would take a single GPU computer to generate 6 (or 60) blocks of fake history at difficulty 1?  If all your node does is ask for 6 most recent blocks ... ok here are 6 blocks I made for you and see your massive payment of 500 BTC is there, so please send me the gold/wire transfer/computer hardware I asked for.  Only later do you find out that you were fed a false history.  Yes I have 500 BTC but in the "real" blockchain I sent them to myself not you.  A double spent that you could not only not prevent, you couldn't even see that it had occurred.

Thanks for the input, I get your point.

However, surely I could verify that a block was generated with a valid difficulty? If I have the latest generated block, and am given a subsequent block referencing the previous block, there must be a formula for verifying that the new block was calculated with a valid difficulty?

For an attacker to generate say six 'fake' blocks with a valid difficulty and the first one referring to the previous truly valid block must be reasonably difficult (similar to actually 'mining' those blocks)?

But wait you say I connect to 8 independent nodes?  Do you?  If there is enough incentive to steal don't you think a botnet for example could produce tens of thousands of "independent" nodes and poison the pool of potential nodes around you.  Now currently there is very limited value in an attacker doing that as each full node (in in the case of electrum the electrum server is doing the full node validation) implicitly does NOT TRUST anything any nodes tells it and validates every block, every transactions, every output back to the genesis block if necessary.  So a "poisened node" strategy has very little utility. 

But against a "naive node" well that is a different story.  Let the false history games begin.

Thanks for the input.

[jim618]

With the latest bitcoinj code, you can have trim down the blockchain storage to
+ a checkpoints file which gives you every blockheader at each difficulty transition (about every 2000 blocks). This is currently only 12 kB
+ a BlockStore that stores the last 5,000 or so blocks in a circular store. This is size limited - it is about 600 KB.

You can use a bloom filter based on your Bitcoin addresses so that your data stream is reduced but this still gives you all the data you need to track transactions, blocks and forks (up to 5,000 blocks deep).

With a few Bitcoin network connections you can track transactions propagating (roughly) so you can get a pretty good heuristic for transaction confidence (ie did the network 'like' the transaction). MultiBit uses one Bitcoin connection as a download peer and 3 others to monitor transactions coming in.

If you want a device connecting directly to the Bitcoin P2P network - ie no intermediate server - I think bitcoinj gives the lowest resource footprint. Well I don't know of a smaller one. I'd be interested to know if anyone has a smaller/ lighter way of doing it.

You can run this with Raspberry Pi level hardware but I doubt you'd get it into a smaller device like a smartcard.

[grue]

Come to think of it, there's no real reason why your hardware wallet even needs to communicate with the network. You're protecting your private keys, so all it has to do is be able to sign transactions securely. Communication with the network can be left to the merchant or any other third party.