Lightweight Client Security Model

[MatthewLM]

I'm planning to create a bitcoin client (codenamed BitEagle). Here is a basic description of the security and validation model. Any comments welcome.

The BitEagle nodes will download block headers from the bitcoin network and a special full validating super-node. The nodes will download these headers from elsewhere in the network in case the super-node is compromised. Nodes will accept the highest difficulty headers and have trust in this fact. The super-node acts as a trusted node. If a BitEagle client node cannot connect successful to the super-node a security warning will be issued. Block checkpoints (Same as with the original client) will also be used in an odd case where the super-node has been compromised and all other connections are bad. If the network and super-node does not provide the same block-chain then a security warning is given (For how many blocks should it be different before giving a warning?).

BitEagle clients will connect to the super-node via DNS with IPv4 or IPv6. The super-node will make connections to the rest of the bitcoin network via secret IP addresses and will disguise itself as a Satoshi client. The super-node will accept connections by the DNS resolved IPs and these connections will disconnect nodes which do not behave as BitEagle client nodes. The only purpose of these connections is to ask for block headers and for other additional special purposes, outside the standard bitcoin protocol. One of these purposes is for clients to ask the super-node for transactions that are owned by them, so full block downloads are not required. The super-node will also provide other services which are not to be described here.

Clients will verify the identity of the super-node via a security protocol such as TLS. BitEagle client nodes will connect as normal with no TLS. The model can scale to multiple super-nodes possibly run by different people. The software could use PKI to identify trustable super-nodes via certificates specific to that purpose but I do not plan to likely add this feature to begin with.

Below you can see a diagram of this model. Green connections are encrypted (and authenticated in the case of the super-node) and black ones are not.



I might have missed out parts. Questions or comments welcome.

[jgarzik]

Bitcoin was built so that anyone may validate data from untrusted sources, eliminating the need for super-nodes.

If indeed you are downloading headers, why would you compromise privacy and security by adding a trusted super-node back into the mix?

Connect to the normal network, get addresses, then "getheaders" (P2P command)

[MatthewLM]

1. The super node will provide additional features that the bitcoin network does not provide.
2. The super-node protects against potential issues with network isolation.
3. The super-node doesn't compromise security. If you disagree, explain why it does.
4. The super-node doesn't compromise privacy. If you disagree, explain why it does.

Edit: I'm not going to use TLS for client-to-client communication unless there is a good reason to. Not needed I think. It is needed for the super-node connection.

[Pieter Wuille]

1. The super node will provide additional features that the bitcoin network does not provide.

Which?

2. The super-node protects against potential issues with network isolation.

How?

3. The super-node doesn't compromise security. If you disagree, explain why it does.

I need to trust the super-node if I use it, no? If I don't need any trust, we have the same situation as the current client provides. If I do need to trust it, this means a decrease in security. It may be a marginal one, and it may be worth it for some people, given the benefits it provides (see Electrum, for example), but it is a risk.

4. The super-node doesn't compromise privacy. If you disagree, explain why it does.

Depending on what the super nodes and how it functions, it may be able to derive what your addresses (or even who you) are.

[MatthewLM]

I refreshed the page by accident (It was actually a bug in Chrome) when posting and now I have to start again. :-(

Which?

I'll explain the features properly at a later date. Though I did mention removing the need to download entire blocks if the super-node provides only the information the client needs. Clients are interested only in their own transactions or transactions spendable by them.

How?

The super-node provides at least one trusted node. If the super-node cannot be connected to, then a security warning is issued. If the bitcoin network is not providing the same block headers as the super-node then a security warning is issued.

I need to trust the super-node if I use it, no?

The super-node is compared to the bitcoin network to ensure both behave identically. So the super-node can't get away with providing bad block headers. It could get away with not sharing transactions in which case the clients wont receive any bitcoins but the transactions are still there on the blockchain and can be redeemed, so it would be a temporary disruption.

The system does increase the security in the cases where you are not using a trusted internet connections such as if you are connecting through somebody else'se network.

Depending on what the super nodes and how it functions, it may be able to derive what your addresses (or even who you) are.

I'll be looking into providing SOCKS support for clients. They could therefore use Tor.

[Pieter Wuille]

I refreshed the page by accident (It was actually a bug in Chrome) when posting and now I have to start again. :-(

Which?

I'll explain the features properly at a later date. Though I did mention removing the need to download entire blocks if the super-node provides only the information the client needs. Clients are interested only in their own transactions or transactions spendable by them.

This kind of filtering is already being discussed. It would be a protocol extension that allows a light node to request that it is only interested in certain transactions; the peer would then only forward filtered blocks and transactions, but still cryptographically committed to the block header chain, via merkle paths. This means that you'd get the SPV security guarantee, with low storage and low bandwidth, and without relying on any particular trusted peer (though you could set up one, and trust it of course). Since the filtering would be done using a Bloom filter, which (intentionally) allows false positives, some privacy can be maintained still.

[MatthewLM]

The question is, when will that be implemented? Sure I can use the new protocol extension but only when it has been implemented by the rest of the network. For now I can only implement the feature in the server-client model.

[Mike Hearn]

Matt already has a patch to implement it in the C++ side for serving and bitcoinj for receiving. I don't think it's ready for a pull request yet.

Generally it's best to avoid trusted nodes, IMHO. Quite apart from the security dimension, it will be expensive for you if your client takes off.

[MatthewLM]

Matt already has a patch to implement it in the C++ side for serving and bitcoinj for receiving. I don't think it's ready for a pull request yet.

Is this code available online?

Generally it's best to avoid trusted nodes, IMHO. Quite apart from the security dimension, it will be expensive for you if your client takes off.

The idea of the trusted server is to increase security, not the other way around. The clients will not rely upon the server solely. It will rely upon the rest of the network as well.