<p>One way to look at security is to identify the risks. For a bitcoin client there are at least :</p>

<p><strong>1. Theft of private keys</strong> </p>

<p>Mitigation:</p>

<p>1.1 Keys should be encrypted. </p>

<p>1.2 Keys should not available to servers. </p>

<p>1.3 Key generation should be done securely. </p>

<p><strong>2. Loss of private keys</strong></p>

<p>2.1 You should be able to backup your wallet or private keys. </p>

<p><strong>3. Client software fails or is untrustworthy</strong> </p>

<p>3.1 Software should be open source so that you can build it yourself and inspect the code. </p>

<p>3.2 Software downloads should be signed by private key of author to prevent 'look-a-like' malicious software. </p>

<p>3.3 Author should spend time building their reputation (even if pseudonymous).</p>

<p>3.4 The software environment the client runs in should be resistant to attack. </p>

<p><strong>MultiBit's scorecard</strong></p>

<p>For MultiBit - which I am the lead developer on - the "Security Scorecard" is currently:</p>

<p>1.1 Currently no, planned for 0.3.0 release.</p>

<p>1.2 There is no server - purely local.</p>

<p>1.3 Keys are generated locally.</p>

<p>2.1 You can backup your wallet.  Key export and import is planned for 0.3.0 release.</p>

<p>3.1 Code is open source with an industry standard (Maven) build.</p>

<p>3.2 Currently no.</p>

<p>3.3 Author is a real public person - Jim Burton.</p>

<p>3.4 MultiBit uses a Java Virtual Machine - its security depends on the desktop machine not being rooted.</p>

CC BY-SA 3.0
2012-01-17T11:18:20.533Z
Just something worth noting: the key difference between Stratum and other projects is that it does't require a local copy of the blockchain. Good analysis.
ripper234
CC BY-SA 3.0
2012-01-17T17:13:56.200Z
Jim, surely 3.2 should get on the list for 0.3.0? I'll update the Maven build in line with BitCoinJ so that a release triggers a signing operation with GPG.
Gary
CC BY-SA 3.0
2012-01-17T10:14:01.127Z
2012-01-17T10:42:48.767Z
2012-01-17T10:42:48.767Z
jim618
<p>I'll answer about "the Stratum model" - <strong>it has the potential to be very secure, for any practical purpose</strong>.</p>

<p>Consider these facts:</p>

<ol>
<li>Both the client and server implementations will be open source.</li>
<li>The vision is to have multiple independent servers, run by various entities (including large, "semi trusted" entities such as major exchanges and pools).</li>
<li>The server never gets a client's private keys. The server only acts as a relay to the Bitcoin network - it answers queries such as "list all transactions to address X", and pushes "<a href="https://strongcoin.com/blog/the_easiest_way_to_create_secure_offline_bitcoin_transactions">offline transactions</a>" generated privately by the client to the rest of the network.</li>
</ol>

<p>So, if the server never has a client's private keys, it cannot spend one's bitcoins. I can think of two possible attack vectors:</p>

<ol>
<li>A server can lie in response to a query - when you ask for "all transactions to address X", it can add fictitious ones, or remove some.</li>
<li>A server can lie that it forwarded an offline transaction, but instead discard it.</li>
</ol>

<p>Both these attacks are mitigated by talking to multiple semi-trusted servers. Suppose there are a lot indepndant servers, run by various exchanges, pools, and other semi-trusted parties. The Stratum client protocol will, in the future, send queries to multiple servers:</p>

<ol>
<li>Queries are sent to N sent servers, and are considered truthful by the client if at least M servers agree. A good value for <code>M</code> might be <code>N/2+1</code>.</li>
<li>Offline transactions are similarly pushed to N servers. It suffices that one of them is honest, and will transmit the transaction to the Bitcoin network to circumvent any potential problem.</li>
</ol>

<p>Given the above analysis, only a coalition of more than half Stratum servers operators has the potential to disrupt to protocol. Since we'll only consider semi-trusted servers, and not point out client at any random Stratum server (to mitigate an attacker starting 1000 evil servers), then <strong>all of these trusted server operators have way more to lose if they cheat than the client does</strong>. I wouldn't use Stratum for a 100,000 BTC transaction, but I think it would be safe even in up to 1000 BTC or more (arbitrary number, the actual number will depend on the number and nature of deployed stratum servers).</p>

<p>All of the above depends strongly on the Startum client itself. Since it does know your private keys, if it were written by a malicious party it could leak your keys - but so could any program running on your computer! It is open source, and the security considerations are identical to the standard Bitcoin client. Each Stratum client should be evaluated according to the reputation of its authors, and the amount of scrutiny its source code receives.</p>

CC BY-SA 3.0
2012-01-17T10:55:14.700Z
I wouldn't be satisfied by a N/2+1, I definitely would like a much higher number, such as 95%.
o0'.
CC BY-SA 3.0
2012-01-17T11:15:27.180Z
@Lohoris - configuration details :) Note that transacting and querying Stratum Servers is likely to incur a small processing fee in the future.
ripper234
CC BY-SA 3.0
2012-01-17T05:46:17.620Z
2012-01-17T05:46:17.620Z
ripper234
<p>As there was some disagreement on security of various models of Bitcoin clients in <a href="https://bitcoin.stackexchange.com/a/2585/323">comments to this answer</a>, I'd like to address the problem.</p>

<p>How secure are various models of Bitcoin clients? Those would include the standard client, "lightweight client" (one keeping only block headers from old blocks), eWallets, client-server client (relying on one server for all information, but keeping a wallet separate), and the proposed Stratum client (relying on many servers for information).</p>

<p>Also, how does the security of such model rely on the person developing it (core Bitcoin team, reputable Bitcoin enthusiasts, people not known in the community)?</p>

<p>For example, "Stratum client offers security features X. If the server was created by a trusted party, the security concerns are Y, if the server was created by malevolent person, the security concerns are Z".</p>

<client><security><protocol><thin-clients><safety>
How secure are various models of Bitcoin clients?
ThePiachu
# How secure are various models of Bitcoin clients?

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

As there was some disagreement on security of various models of Bitcoin clients in [comments to this answer](https://bitcoin.stackexchange.com/a/2585/323), I'd like to address the problem.

How secure are various models of Bitcoin clients? Those would include the standard client, "lightweight client" (one keeping only block headers from old blocks), eWallets, client-server client (relying on one server for all information, but keeping a wallet separate), and the proposed Stratum client (relying on many servers for information).

Also, how does the security of such model rely on the person developing it (core Bitcoin team, reputable Bitcoin enthusiasts, people not known in the community)?

For example, "Stratum client offers security features X. If the server was created by a trusted party, the security concerns are Y, if the server was created by malevolent person, the security concerns are Z".

**Tags:** client, security, protocol, thin-clients, safety


---

## 2 answers

### Answer by username_1 on 2012-01-17. Score: 8

One way to look at security is to identify the risks. For a bitcoin client there are at least :

**1. Theft of private keys**

Mitigation:

1.1 Keys should be encrypted.

1.2 Keys should not available to servers.

1.3 Key generation should be done securely.

**2. Loss of private keys**

2.1 You should be able to backup your wallet or private keys.

**3. Client software fails or is untrustworthy**

3.1 Software should be open source so that you can build it yourself and inspect the code.

3.2 Software downloads should be signed by private key of author to prevent 'look-a-like' malicious software.

3.3 Author should spend time building their reputation (even if pseudonymous).

3.4 The software environment the client runs in should be resistant to attack.

**MultiBit's scorecard**

For MultiBit - which I am the lead developer on - the "Security Scorecard" is currently:

1.1 Currently no, planned for 0.3.0 release.

1.2 There is no server - purely local.

1.3 Keys are generated locally.

2.1 You can backup your wallet. Key export and import is planned for 0.3.0 release.

3.1 Code is open source with an industry standard (Maven) build.

3.2 Currently no.

3.3 Author is a real public person - Jim Burton.

3.4 MultiBit uses a Java Virtual Machine - its security depends on the desktop machine not being rooted.

> **Comments:**
> **username_2**: Just something worth noting: the key difference between Stratum and other projects is that it does't require a local copy of the blockchain. Good analysis.  
> **username_3**: Jim, surely 3.2 should get on the list for 0.3.0? I'll update the Maven build in line with BitCoinJ so that a release triggers a signing operation with GPG.  

---

### Answer by username_2 on 2012-01-17. Score: 7

I'll answer about "the Stratum model" - **it has the potential to be very secure, for any practical purpose**.

Consider these facts:

1. Both the client and server implementations will be open source.
2. The vision is to have multiple independent servers, run by various entities (including large, "semi trusted" entities such as major exchanges and pools).
3. The server never gets a client's private keys. The server only acts as a relay to the Bitcoin network - it answers queries such as "list all transactions to address X", and pushes "[offline transactions](https://strongcoin.com/blog/the_easiest_way_to_create_secure_offline_bitcoin_transactions)" generated privately by the client to the rest of the network.

So, if the server never has a client's private keys, it cannot spend one's bitcoins. I can think of two possible attack vectors:

1. A server can lie in response to a query - when you ask for "all transactions to address X", it can add fictitious ones, or remove some.
2. A server can lie that it forwarded an offline transaction, but instead discard it.

Both these attacks are mitigated by talking to multiple semi-trusted servers. Suppose there are a lot indepndant servers, run by various exchanges, pools, and other semi-trusted parties. The Stratum client protocol will, in the future, send queries to multiple servers:

1. Queries are sent to N sent servers, and are considered truthful by the client if at least M servers agree. A good value for `M` might be `N/2+1`.
2. Offline transactions are similarly pushed to N servers. It suffices that one of them is honest, and will transmit the transaction to the Bitcoin network to circumvent any potential problem.

Given the above analysis, only a coalition of more than half Stratum servers operators has the potential to disrupt to protocol. Since we'll only consider semi-trusted servers, and not point out client at any random Stratum server (to mitigate an attacker starting 1000 evil servers), then **all of these trusted server operators have way more to lose if they cheat than the client does**. I wouldn't use Stratum for a 100,000 BTC transaction, but I think it would be safe even in up to 1000 BTC or more (arbitrary number, the actual number will depend on the number and nature of deployed stratum servers).

All of the above depends strongly on the Startum client itself. Since it does know your private keys, if it were written by a malicious party it could leak your keys - but so could any program running on your computer! It is open source, and the security considerations are identical to the standard Bitcoin client. Each Stratum client should be evaluated according to the reputation of its authors, and the amount of scrutiny its source code receives.

> **Comments:**
> **username_4**: I wouldn't be satisfied by a N/2+1, I definitely would like a much higher number, such as 95%.  
> **username_2**: @Lohoris - configuration details :) Note that transacting and querying Stratum Servers is likely to incur a small processing fee in the future.  

---

