Neutrino can be dangerous, so lets grow Bitcoin’s immunity with a BIP/BOLT
In this article, BTCPayServer developer Nicolas Dorier outlines how Neutrino is dangerous for his self-sovereignty. The post accurately describes the dangers of light wallets giving sovereignty of Bitcoin’s consensus model to miners. This article is a proposal to compete with Neutrino by lowering the barriers for non-technical people to run and remotely connect to a full node.
SPV and Neutrino, from here on referred to as light wallets, trust the most accumulated work chain, but they do not verify consensus rules, such as block size, inflation, etc. This results in an attack vector exploitable by majority miners.
This exploit was nearly successful in 2017 when an analogous ‘virus’ nearly defeated a social-software ‘immunity system’ in Bitcoin. Miners attempted to change consensus rules with a proposed doubling of the block size. Segwit2x proponents bragged about how invisible this ‘upgrade’ would be for SPV users. The UASF & No2x movement won, but that fight will be harder to win in the future. As Bitcoin on-boards more and more people, Nicolas Dorier argues this social immune system has the threat of becoming diluted to the point of a minority ineffectiveness. If bitcoin’s goal is for mass adoption, we can not allow this immunity system to dilute, we must maintain and grow the impenetrable fortress of validation.
Banning light wallets is futile. Access to bitcoin is permission-less. If the Bitcoin Core repository does not merge Neutrino (or removes SPV), others will maintain forks to serve light wallets. Light wallets in some forms are also not inherently bad, either. Consider such an example:
We must educate users to run full nodes, and what it means to run a full node. Currently, this barrier to entry is huge, and the user does not learn what the ramifications of consensus changes are, and do not have the technical expertise to create remote connections to a home server. See this guide to setting up a full node with lightning to serve mobile wallets. It is not an easy endeavor.
I believe that a proper user interface, along with a BIP to make syncing a light wallet to a full node a 1 step easy QR scan, will not only increase node adoption, but educate users on consensus parameters. This lower barrier to entry and education should have the result of growing bitcoin’s social and software immunity as mass adoption continues.
Proposal overview: Connect remote light clients to a full node with 1 user step: a QR scan
The bitcoin full node creates a tor hidden service with authorized client to serve RPC calls, and generates a QR code with the connection information for the mobile wallet, which is also connected to tor.
The benefit of this setup is that the connection is end to end encrypted, anonymous, authenticated, and serves remote connections through NAT traversals. It is, essentially, acting like a VPN connection with a dynamic DNS. No additional configuration is required by the user. Tor hidden services with cookie authorization also prevents denial of service attacks, since the attacker can not reach the .onion address without the authentication cookie. If the full node or light wallet change IP addresses, or change NAT configurations, connectivity is re-established through the tor network.
Proposal detailed explanation: Connect remote light clients to a full node with 1 user step: a QR scan
Tor is compiled into the distribution of UI versions of a full node, similar to how Bisq or Wasabi Wallet connects over tor without the user ever having to install or configure tor. However, tor is not to connect to the bitcoin p2p network (not by default, an unnecessary burden on the tor network), but rather to serve a tor hidden service. This hidden service with authorized client & various hidden service ports are created by the full node. The full node’s UI then presents a QR code to scan by a mobile wallet that contains the following information:
- .onion address of the hidden service
- the secret cookie authentication to the hidden service
- the ports for p2p, RPC, and future proofed with a labeling sequence for other ports, such as localhost ports for software running in conjunction on the full node, such as lightning. (e.g. lnd_gRPC=10009, lnd_REST=8080)
A similar structure is used for lndconnect.
This requires that the mobile wallet also comes with tor compiled in. This is no easy task, as I am not aware of Tor being built in to any currently distributed app on Android and iOS platforms outside of browsers. However, such libraries do exist. Until this happens, the mobile wallet will need Orbot running on android, a necessary complexity for the end user until tor is built in to a light wallet app.
The command line arguments and configuration files for a full node running a tor hidden service to serve a remote light wallets are explained here:
bitcoind serves Blockstream Green over tor:
bitcoind and lnd serves light lightning wallet Zeus over tor:
Drawbacks and mitigation strategies:
Tor is slow. It is run by a community of volunteers and is not incentivized. Enabling tor by default will put an additional burden on the network. There are several mitigation strategies:
- Incentivize tor. Imagine some sort of c-lightning plugin that increases bandwidth for a circuit paid over lightning. This is beyond the scope of this proposal.
- Deploy a ‘tor for bitcoin’ protocol, where all full nodes supply entry and relay support for each other. Incentives are given since you benefit from access. Non-bitcoin data is prevented by only relaying specific data architectures and encrypted data sizes. This is beyond the scope of this proposal.
- Serve RPC calls in lieu of SPV or neutrino over tor, since the additional anonymity features of these protocols are not needed when the full node is already trusted. Minimize RPC calls for status, balance, etc. Blockstream’s Green wallet supports SPV over tor. While its refreshing to finally have this option in a wallet, SPV isn’t necessary since the node is already trusted. A simple RPC call is much more data efficient.
- Light wallets, and Android / iOS apps in general, with built in tor does not exist. In fact, I am not aware of ANY Android / iOS app that has built in tor outside of browsers. Tor on android is served by the app Orbot, however manual configuration is currently required. To make remote connections a 1 step QR scan, tor must be compiled into the light wallet app. This increases the complexity of mobile apps.
- Compiling tor into a full node increases complexity, and detaches potential hot patch fixes to the tor network to periods between a bitcoin node’s release schedule.
Neutrino is dangerous, so lets grow Bitcoin’s immunity with a better UI
New users learn about bitcoin by exploring and interacting with the user interface. Consensus metrics must be communicated in a visually appealing and easy to understand way so the user understands what the node is doing to their resources. If a proposed consensus change is revealed, the user can visualize their resources and determine of this change will still allow them to run a node.
The following metrics need to be displayed on a worst case scenario of full blocks:
- % Bandwidth used by their node. This requires running a bandwidth test.
- Bandwidth time to download the blockchain size in 1 year, 3 years, and 10 years.
- % Disk space used by their node.
- Growth rate of the blockchain (e.g. forecast blockchain size in 1 year, 3 years, 10 years)
- % CPU utilized and CPU time to fully re-validate the blockchain now, in 1 year, in 3 years, in 10 years based on current hardware. This requires benchmarking.
- Network averages & medians for the above data, although anonymous data collection would have to be voluntary.
- Other unforseen resource limitations not envisioned by this author.
If any of these parameters are exceeded, the user no longer has the resources to run the node, and may be more resistant to changes that exceed these parameters.
In conclusion
This proposal makes pairing a mobile wallet to a full node in the easiest possible way that also serves the user in a multitude of benefits in connectivity and privacy.
In a perfect bitcoin ecosystem, the barrier to running a full node is strictly resources. Deployment, configuration, and operation should not be a barrier.
In a perfect bitcoin ecosystem, the UI teaches the user what bitcoin consensus is. Newbies should be able to understand the consensus difference between their node and a competing node (say, a JPMCoin node or WellsFargo node or a Bitcoin4x node) purely through user interface. A proposed hard fork that alters these resources should be easily interpreted through the UI.
