BIP 151: The End-To-End Encryption Bitcoin Never Had – but Soon Will
Bitcoin right now is not really anonymous. While Bitcoin addresses aren’t necessarily linked to real-world identities, they can be. Monitoring the unencrypted peer-to-peer network, analysis of the public blockchain, and Know Your Customer (KYC) policy or Anti-Money Laundering (AML) regulation can reveal a lot about who’s using Bitcoin, and for what.
This is not great from a privacy perspective. Bitcoin users might not necessarily want the world to know where they spend their money, what they earn or how much they own, while businesses may not want to leak transaction details to competitors – to name some examples.
Additionally, bitcoins being traceable, possibly “tainted,” and potentially worth less than other bitcoins is at odds with fungibility. This could even challenge Bitcoin’s value proposition as money.
But there are potential solutions to increase privacy, and improve fungibility.
One of these solutions is BIP 151, a Bitcoin Improvement Proposal designed to encrypt data among Bitcoin nodes.
The Problem
Traffic over the Bitcoin network has always been unencrypted. Transactions and blocks are sent from node to node in plain sight, as are Bloom filters, which are often used by Simplified Payment Verification (SPV) nodes. All this data can, therefore, be seen by Internet Service Providers (ISPs), open-WiFi providers and anyone monitoring the Bitcoin network.
This has obvious downsides. In the case of full nodes (and miners), information on where transactions and blocks originate can link Bitcoin addresses to IP addresses, which can be used to de-anonymize users. Moreover, ISPs and open-WiFi providers can potentially use the data to block certain transactions, for instance if they send bitcoins to a blacklisted address.
Most SPV-wallets (or lightweight clients – and in particular those based on the Bitcoinj-library) have an additional problem. To check funds, these wallets send out so-called Bloom filters, a mathematical trick that aggregates data into a compact package. Unfortunately, this has proved insecure from a privacy perspective: The packages can be used to reconstruct which Bitcoin-addresses belong to the wallet-user.
While there are some solutions available to encrypt data between nodes already, most obviously Tor and VPN, these are not ideal. For one, these solutions don’t work “out-of-the-box” ‒ they require extra software and sometimes special ports. Second, users typically need to rely on infrastructure and people outside of the Bitcoin system (and in particular Tor exit nodes). And there’s typically a hit to performance as well.
The Solution
BIP 151, designed and recently proposed by Bitcoin Core developer Jonas Schnelli, is a straightforward solution: It encrypts traffic between nodes.
To avoid potential security risks posed by the much more commonTLS/SSL cryptographic standard, BIP 151 proposes to use a cryptographic standard known as “ChaCha20/Poly1305@openssh.” This standard is already used by OpenSSH and the Google-API, among other projects, and is generally considered well-proved. It offers the added advantage of speeding up network traffic; Bitcoin messages currently include a SHA256-hash (another cryptographic standard) of the content, which is relatively “heavy” to compute.
With ChaCha20/Poly1305@openssh, anyone monitoring the network could still recognize packages as Bitcoin data. But they would not know the content of the data. This automatically improves privacy. Additionally, it becomes harder to censor specific transactions or blocks: ISPs or open-WiFi providers can only censor all Bitcoin-data, or none of it.
Realization
While BIP 151 was proposed quite recently, and the review process has just started, there is as of yet little reason to think it can’t be safely deployed on the Bitcoin network.
In fact, since BIP 151 has no impact on Bitcoin’s consensus layer, any miner, node or wallet on the network can opt in to the solution at any time – even if some other miners, nodes or wallet don’t. (If one or both connected nodes don’t apply BIP 151, the data is simply transmitted in plain text – which does, of course, mean the privacy and censorship-resistant benefits don’t hold up either.)
However, the solution might not be completely airtight. It could, at least in theory, be possible, for example, to analyze the encrypted data and conclude how big the message is. Comparing this with the data as it appears in mempools or on the blockchain might reveal which data was sent from a specific node. But all in all, this problem is probably negligible – and it would still be impossible to censor specific content pro-actively.
And, of course, BIP 151 doesn’t in itself make Bitcoin private or fungible; it’s a mere part of the puzzle. Perhaps the most relevant improvement to be rolled out alongside BIP 151 is a solution for node authentication to ensure a connected peer is a genuine node, not an ISP or WiFi-provider disguised as one. Schnelli is currently working on a solution to ensure node authentication as well.
Source | BitcoinMagazine
