edit: this scheme has serious problems, see the comments
2019/03/21
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.
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 are even worse for security. They can display anything to the user (including printing infinite bitcoins) without even spending energy on proof-of-work.
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).
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.
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.
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.
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.
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.