Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
DSPV Security - Miner-resistant design of lightweight bitcoin wallets

edit: this scheme has serious problems, see the comments

DSPV security - Miner-Resistant Design of Lightweight Bitcoin Wallets

2019/03/21

What are lightweight wallets

Lightweight wallets are ones which are not full nodes. Lots of people use them because full nodes are costly: they cost time to setup/synchronize, education, disk space, bandwidth, RAM and a few other resources.

Lightweight wallets have a reduced security model (meaning another party can control which bitcoin consensus rules the user follows) and reduced privacy model (meaning another party can track the user's economic activity). In this blog post I'm talking only about the security model. It's purpose is to get the idea out there and see whether bitcoin users are comfortable with the tradeoffs.

When I say security I'm not talking about private keys, but security of the bitcoin system and its consensus rules.

SPV security

A common security model for lightweight wallets is SPV security, which is where the wallets fully-trust miners for their validation of consensus rules. It works by having wallets follow the most-work chain of block headers. This gives power to 51% of miners who could, for example print infinite bitcoins, steal coins without knowing their privkeys or break anti-DOS rules (such as the block size limit).

The 2015-2017 scalability conflict in bitcoin involved threats of 51% miner attacks on SPV lightweight wallets. This rightly convinced many people that SPV security wallets are a bad idea.

Custodial wallets

Custodial wallets are even worse for security. They can display anything to the user (including printing infinite bitcoins) without even spending energy on proof-of-work.

DSPV security

Another possible security model for lightweight wallets is to have the wallet software also query their developers. I'm calling it DSPV security or Developer-SPV security.

You could think of this as 2-of-2 multisig for choosing the chain. 51% of miners hold one key and the lightweight wallet developers hold the other. Both would need to become attackers in order to make users of this wallet follow an invalid chain that prints infinite bitcoins (and of course the attack doesn't work on full nodes).

Developers are presumably already very interested and engaged in bitcoin. If a user isn't using a full node then it makes sense for developers to also have a say on the user's behalf.

This would work by having the wallet software somehow query the developers and obtain the best block hash from the developer's full node. The wallet requires that the block hash is included recently in the blockchain being followed, otherwise it will stop working and give an error.

The user should always has the option of disabling this check (this would be appropriate if the user has pointed their lightweight wallet at their own full node).

Example design for Electrum wallet

DSPV in Electrum would work by having the developer's public key be included in the Electrum software. When a new block arrives the developer will sign a message with his privkey containing the best block hash, and upload that message to every Electrum server. Electrum wallets will download these signed messages, verify the signature and check whether the block hash was included in their blockchain within the last 6 blocks. If not they will stop working and display an error (unless the user has disabled this check, for example because they connect to their own Electrum server).

The 6 block timeout means that any miner attack on SPV wallets which mines invalid blocks will stop working against Electrum wallets after 6 blocks. Presumably this should provide enough disincentive for 51% of miners to never attempt it. This is unlike the Bitcoin Classic and S2X threats where SPV wallets would have followed the invalid chain forever. The timeout also means the developer's full node can go down for a while without affecting users.

There can be more than one developer public key. Electrum has multiple developers and all of them could have a keypair and be able to issue signed block hash messages. This also helps protect against accidental downtimes.

Objections and Replies

Any improvement to lightweight wallets is bad because people should use full node wallets

It is true that improving lightweight wallet security reduces the relative incentive to use full node wallets. However the incentive to use lightweight wallets is already very high, because of the high resource cost of full nodes. The demand for lightweight wallets will always exist and isn't going away. I would rather this demand be satisfied by the best possible design.

The choice isnt between DSPV and full nodes, but between DSPV and custodial wallets, or DSPV and SPV security.

This makes wallets dependent on their developers

They already are.

Wallets are massively dependent on their developers, as any software is. If developers lose interest or their backing companies shut down then in a short period the wallet will become unmaintained and die. See the history of countless dead bitcoin wallets such as Hive Wallet or Multibit.

Client-side block filters / Neutrino / BIP157

Recently some people were saying they oppose client-side block filters because they would lead to an ecosystem where SPV security is more popular, and so threaten the security of bitcoin itself. Hopefully the design of DSPV can answer their concerns.

It's also worth pointing out again that opposing Neutrino may not lead to most people using full node wallets, it's more likely to lead to most people using blockchain.info's web wallet.

@chris-belcher

This comment has been minimized.

Copy link
Owner Author

@chris-belcher chris-belcher commented Mar 21, 2019

After discussing this on IRC, there are a few serious issues with the idea.

  1. One concern that not being addressed is that it makes developers a more attractive target for compromise or coercion-- doubly so because keys would have to be online,

  2. It may be harder to shed legal liability for their signing than it is for their software

  3. Market forces end up creating a power law distribution so this sort of thing would confer a lot more power in fewer hands. Yes, developers already have some power but at least absent push software updates it's gated by users upgrading. Imagine things worked like this before in 2015 but even MORE users used SPV clients than did then (because like... they were more secure!) .... and the keys were held by Hearn (anything bitcoinj based) and kyupichan (electrum). People who work on SPV wallets may tend to be supportive of their security model.

  4. There is no way to prevent it from providing "sham reorg protection", so you could easily see people concluding it was "more safe" than fullnodes. "Look, I don't need to be able to handle reorgs, I just wait for Hearn to sign my blocks!" :P

@chris-belcher

This comment has been minimized.

Copy link
Owner Author

@chris-belcher chris-belcher commented Mar 29, 2019

Here is a way to deal with point 4.

Instead of serving the tip hash, serve the hash of a block that is some blocks deep, for example 100 blocks deep. Then the scheme cant be used easily as reorg resistance (unless reorgs of 100 blocks are expected, which would indicate other serious problems)

A downside is then lightweight wallets would take 100 blocks after a miner-backed-hijacking event to realize that they're on the wrong chain. However thinking about it a hijack attempt is probably aiming to hijack the currency long-term rather than for a short period, and the 100 block wait will protect against that and so provide a disincentive to attempting it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.