Taproot is likely the most well-recognized BIP on this list, and has actually been implemented in Bitcoin despite still being marked as “Draft” in the BIP GitHub repository.
Taproot is really only on this list as it has so far gone practically unused, but as things can move very slowly toward adoption in Bitcoin (especially when optional, as Taproot usage is) it will likely take several years before Taproot is widely used.
Once Taproot is usable for Lightning Network channel opens it will provide good privacy by hiding the script details in each channel open transaction and making it much harder to find channel opens on-chain in Bitcoin. This privacy does break down in the event of a non-cooperative channel close, however, as the script must be revealed in this case on-chain.
Further Reading:
SNICKER
Status: Abandoned, never formally proposed for Bitcoin
As I don’t know much about SNICKER I won’t go into detail on my thoughts, but see the quote below for the summary of what the proposal was meant to do:
“SNICKER (Simple Non-Interactive Coinjoin with Keys for Encryption Reused) is a simple method for allowing the creation of a two party coinjoin without any synchronisation or interaction between the participants. It relies on the idea of reused keys (either reused addresses, or identification of ownership of signed inputs and thus pubkeys in signatures).”
As far as I can tell the proposal has been abandoned since 2020.
Further Reading:
CoinSwap
Status: Work in progress, but never formally proposed for Bitcoin
Pros: Appears to be a normal transaction type on-chain
Cons: Does not actually obfuscate or break any on-chain history, it merely attempts to break simple ownership heuristics; allows those with tainted funds to swap for “clean” funds to the detriment of the swap participant; no clear privacy advantages in most situations
CoinSwap was a popular and oft-discussed proposal in 2020 to allow users to swap UTXOs (and thus their associated history), but was met with strong pushback as it does nothing to remove history or break deterministic links.
See the below quote for a simple summary of CoinSwap:
“Coinswap is a protocol that allows two or more users to create a set of transactions that look like independent payments but which actually swap their coins with each other, optionally making a payment in the process.”
It seemed that CoinSwap had been abandoned, as there was no progress made since 2020, but recently, Chris Belcher launched an implementation of CoinSwap called Teleport Transactions .
Further Reading:
Silent Payments
Status: Work in progress, not yet formally proposed for Bitcoin
Pros: Much easier receipt of funds to a static address while preserving privacy; no direct link between payment code and on-chain addresses/transactions (unlike static Bitcoin addresses); does not require on-chain notification transaction, unlike BIP47
Cons: Currently completely incompatible with light wallets; adding a new Silent Payment code after initial block download (IBD) requires completely restarting IBD; requires constant scanning of the blockchain for new uses/transactions
Silent Payments are all the rage in recent Bitcoin discussion, and are similar in some ways to BIP47 (mentioned above).
While they also offer the ability to share or publicize a single static payment code and receive payments that are not linkable on-chain, there remain serious tradeoffs in the approach that make light-wallet usage practically impossible and can require complete re-downloading of the Bitcoin blockchain to find new transactions for any new Silent Addresses.
It will be interesting to see this proposal play out but so far the better option appears to be BIP47 still.
A great summary of the three main reusable payment code schemes has been provided by Ruben Somsen , the author of Silent Payments, in the gist for Reusable Taproot addresses .
Further Reading:
Reusable Taproot Addresses
Status: Work in progress, not yet formally proposed for Bitcoin
Pros: Much easier receipt of funds to a static address while preserving privacy; no direct link between payment code and on-chain addresses/transactions (unlike static Bitcoin addresses); combines first payment and notification into one “real” transaction, unlike BIP47; notification transaction appears just like any other Taproot spend on-chain
Cons: Sender and receiver both must support and use Taproot; sender needs to follow a special protocol to be able to recover from backup
While this proposal bears many similarities to BIP47 and Silent Payments , it leverages new capabilities in Taproot to essentially improve on the tradeoffs taken by BIP47 reusable payment codes. A great summary has been provided by Ruben Somsen , the author of Silent Payments in the gist below:
Reusable Taproot addresses:
No continuous scanning of every transaction
One-time interaction with the recipient (stateful for sender: if they forget, they need to interact again)
No on-chain footprint
Sender needs to follow a special protocol to be able to recover from backup (this downside can be mitigated, see below)
BIP47:
No continuous scanning of every transaction
No interaction with the recipient
On-chain footprint (or alternatively one-time interaction and stateful backups)
Silent Payments:
Continuous scanning of every transaction (increases cost of running full node)
No interaction with the recipient
No on-chain footprint
Further Reading:
Lightning Network
Please note that most of these proposals are still very much a work in progress and have yet to be given a clear yes/no approval. As such, the Lightning Network proposals are mainly added below as important developments to follow that potentially offer improved privacy when using the Lightning Network.
As the Lightning Network was originally designed as a tool for scalability and not privacy, many of the core design decisions initially chosen are extremely detrimental to user privacy. Many of the proposals below are seeking to remedy those issues and hopefully will be able to do so without harming payment reliability or routing efficiency.
Route Blinding
Status: Work in progress
Pros: Prevents sender from ascertaining full route to recipient; hides recipient node alias/pubkey; provides much better recipient privacy overall versus current transparent routing methods; can provide better payment success rate by providing local routing data in some specific scenarios
Cons: Can be difficult to craft blinded routes in specific routing graph scenarios; can have a negative impact on payment success rate in specific scenarios
The current Lightning Network suffers from severe issues centered around receiver privacy, and Route Blinding is one of the key proposals seeking to remedy at least a part of this issue.
To quote the proposal :
“Route blinding is a lightweight technique to provide recipient anonymity by blinding an arbitrary amount of hops at the end of an onion path.”
Route blinding is still very much a work in progress but shows promise for allowing a receiver to receive funds without deterministically revealing the final node receiving the funds.
Further Reading:
Trampoline Onion Routing
Status: Work in progress
Pros: Can allow light wallets to craft routes in a privacy-preserving way without a full route graph; can be used to provide receiver privacy from the sender (but not the trampoline node as far as I can tell)
Cons: None that I know of at this time
While not strictly a privacy improvement, Trampoline Onion Routing can provide better route privacy in some scenarios for the receiver and so is mentioned here. It can also be paired with route blinding to provide even better receive privacy, especially for use cases where you cannot run a full node or construct entire routes yourself for whatever reason.
The full privacy implications are still under consideration, but it will be an interesting proposal to follow along with.
Further Reading:
Alias SCID
Status: Work in progress
Pros: Prevents simple linking of payments to single node alias/pubkey by using a unique alias per channel/peer
Cons: None that I know of at this time
One of the critical privacy issues in Lightning today is the fact that nodes have permanent aliases and pubkeys that are used for gossip and channel management, and as such, any receipt of payments leaks your nodes alias and pubkey to the sender of the payment.
The key approach to resolving this issue in Lightning is something called “Alias SCID,” which allows you to force your peers to only refer to you or your channels by an alias which can be unique to each peer and/or channel.
Further Reading:
Offers — BOLT12
Status: Work in progress
Pros: Drastically-improved privacy and flexibility for payments as the recipient; much smaller QR codes and much less data needed in the offer itself (as the necessary data is collected from the recipients node directly instead of being all included in the invoice as in BOLT11 invoices)
Cons: None that I know of at this time
BOLT12 is a combination of many of the other proposed improvements and integrates them into a new and much more flexible invoice type for Lightning, also called an “offer.” The implementation of BOLT 12 alongside route blinding and node alias SCIDs would be a big step forward for both privacy and user experience in Lightning, and is somewhat of the current holy grail of proposals.
Be sure to keep an eye on its development if you use or are interested in the Lightning Network as it promises to fix many of the current issues.
Further Reading:
Sidechains
The Liquid Network
Status: Live since 2018
Pros: Mildly improved per-transaction privacy due to Confidential Transactions (but mostly useless due to almost no usage reducing crowd to hide in); cheaper fees than on-chain
Cons: Custodial (via a federation); almost no usage gives you almost no crowd to hide in; past issues with “emergency” multisig being held by very few parties
The Liquid Network is a Bitcoin-pegged and federated sidechain for Bitcoin that allows users to peg BTC to redeem it for L-BTC and then be able to transact on the Liquid Network.
Liquid provides moderate privacy improvements over on-chain Bitcoin due to its use of Confidential Transaction and it is extremely cheap to transact in.
Users should be very aware that Liquid is a federated model where custodians hold the keys to your bitcoin , and thus your funds are at risk of loss or theft and you should not assume you will always be able to convert back to BTC.
But Liquid remains practically unused even after four years of being in the wild and heavy marketing .
Further Reading:
FediMint
Status: Work in progress
Pros: Very strong privacy when transacting within the sidechain; interoperable with the Lightning Network without requiring each user to run a node/manage channels/etc.; anyone can start a new minimint, not just specific people/groups; can choose a specific minimint to used based on federation members reputation, trust, etc.; can serve as a middle ground between self-sovereign Lightning (Zeus, Core LN, LND, etc.) and “single-custodian” Lightning (Wallet of Satoshi, Cash App, Strike, etc.) while retaining user privacy from custodians
Cons: Custodial (via federations); potential regulatory pressure on federation members due to custody/transfer of user’s funds; centralization of Lightning Network due to users not running their own node, managing channels, etc. and instead relying on federation Lightning services
FediMint (and the specific initial implementation, minimint) is a relatively new proposal for building a federated Chaumian-blinded eCash as a sidechain to Bitcoin, denominated in bitcoin. These federated sidechains would be relatively small, interoperable and would compete on reputation, uptime and fees.
While it is still very much a work in progress, minimint holds promise for a middle ground between fully self-sovereign Lightning Network usage (Zeus, Core LN, LND, etc.) and single-custodian Lightning Network usage (Cash App, Strike, etc.) by allowing a trusted federation of custodians to hold funds and manage Lightning node(s) for their users.
Note that the proposal is still fully custodial, but has differing tradeoffs compared to something like the Liquid Network .
Further Reading:
This is a guest post by Seth For Privacy. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
