Onion Information

Page Clicks: 0

First Seen: 03/12/2024

Last Indexed: 10/23/2024

Domain Index Total: 84

Table of Contents Bitcoin Confidential Transactions Reusable Payment Codes for Hierarchical Deterministic Wallets - BIP 47 Stealth Addresses - BIP 63 PayJoin - BIP 78 Peer-to-Peer Communication Encryption - BIP 151 and BIP 324 Dandelion - BIP 156 Taproot - BIP 341 SNICKER CoinSwap Silent Payments Reusable Taproot addresses Lightning Network Route Blinding Trampoline Onion Routing Alias SCID Offers - BOLT 12 Side-chains The Liquid Network FediMint Conclusion Ragnar Lifthrasir asked for a list of Bitcoin proposals and ideas to improve privacy that either are still a work in progress, were abandoned or never implemented, or failed to make an impact, and so here is my attempt at just that. This will by no means be an exhaustive list, and I could use any help I can get keeping it up to date or finding historical proposals that have fallen out of favor. The sections below will be broken down by project or implementation and in order of proposal (where possible). Note: While some of these proposals were non-starters or have been abandoned, some are interesting and potentially promising proposals. This is not a “hall of shame”, but rather a chance to learn from past proposals and keep up with new ones as we go along. Bitcoin # Confidential Transactions # Status: Never formally proposed for Bitcoin Pros: Drastically improved privacy against amount-based heuristics; enables greatly improved and more flexible app-layer privacy tools for Bitcoin (i.e. unequal output CoinJoins) Cons: Supply auditability becomes more complex (but is still possible) and relies on more advanced cryptography; Transaction sizes and verification times are both significantly increased Confidential Transactions (used in Monero since 2017 and Liquid since 2018) are a technique used to blind the amounts in a transaction in way that is still verifiable and provable without revealing amounts to anyone outside of the transaction participants. Miners, nodes, and external observers can still validate that transactions do not create or destroy funds without knowing the true amounts being transferred. Initial proposal/investigation by Greg Maxwell Confidential Transactions in Elements Ring Confidential Transactions - article on Monero’s RingCT implementation of Confidential Transactions “How RingCT Hides Monero Transaction Amounts” - LocalMonero Reusable Payment Codes for Hierarchical Deterministic Wallets - BIP 47 # Status: Unanimously discouraged for implementation 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) Cons: Most versions require a notification transaction to be sent on-chain so that the recipient knows how to look for funds sent to them; Notification transaction can undermine privacy if done incorrectly The proposal for reusable payment codes is one of the well-known BIPs due to the adoption and usage of it by Samourai Wallet under the name “ PayNym ”. This proposal is similar to stealth addresses in that a single payment code can be used to derive unlinkable on-chain addresses, but differs in that it does not use different addressing formats on-chain and instead relies on a notification transaction to allow the recipient to find their funds on-chain. PayNyms, despite being rejected/discouraged in BIP 47 have seen quite widespread usage and have recently been implemented in Sparrow Wallet and even by a Bitcoin mining pool, “ Lincoin ”. 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 . Original Payment Code BIP - 47 Stealth Addresses - BIP 63 # Status: Never accepted as a BIP despite being given a BIP number Pros: When enforced, prevents all links between off-chain addresses/pubkeys and on-chain one-time addresses; Breaks all address-based heuristics Cons: Wallets now have to scan all transactions to validate which ones are owned by the user’s private keys; Can no longer do simple address-based wallet sync Stealth Addresses are a novel concept that allows a receiver to share or publish a single static address that senders can derive one-time addresses from, breaking any cryptographic links to the shared/published address on-chain. While this does add considerable overhead to wallet scan times (all transactions must be scanned to see what is owned by your private keys instead of just validating known addresses) it entirely breaks wallet clustering by addresses along with many other key heuristics. Stealth Addresses were originally proposed for Bitcoin in 2011 on Bitcoin Talk, but were abandoned as a BIP after OP_RETURN was changed : OP_RETURN got changed to 40 bytes at the last minute, preventing my stealth address standard from working, and moved on to work on other things. u/petertodd While Dark Wallet did implement stealth addresses for Bitcoin, the wallet never officially launched and was abandoned. Monero, on the other hand, includes Stealth Addresses as they were a core part of the original Cryptonote protocol that Monero was created from. Original Stealth Address BIP - 63 “How Monero Stealth Addresses Protect Your Identity” - LocalMonero “What is Stealth Address technology and Why Does Monero Use It?” - SerHack PayJoin - BIP 78 # Status: Draft Pros: Creates transactions that look normal but break common heuristics; Easy to perform when supported by the recipient Cons: Requires hot wallet on the merchant/recipient side, cannot send to simple address etc.; Malicious sender can attempt to force recipient to reveal UTXOs (attack is mitigated if properly implemented) PayJoin may also be well-known to the Bitcoin privacy crowd as it has gotten some media and minor adoption despite it’s official “Draft” status. PayJoin lets the sender and recipient of a transaction work together to build a combined transaction that includes a UTXO (or more) from both the sender and intended recipient of funds, obfuscating the true nature of the payment on-chain. A similar protocol has been implemented in Samourai Wallet in 2019 as “Stowaway” (before the PayJoin proposal BIP), and PayJoin proper was implemented in BTCPay Server in June 2020 , JoinMarket in August 2020 , Blue Wallet in October 2020 , and Sparrow Wallet in November 2020 . See their docs for more info: Stowaway - Samourai Wallet BTCPay Server PayJoin Guide - BTCPay Server PayJoin (aka P2EP) user guide - JoinMarket Paying to a PayNym - Sparrow Wallet Although implemented in some wallets and tools, PayJoin usage unfortunately seems to remain very sparse today (though it’s hard to detect on-chain so might be higher than we realize). Most of the lack of adoption appears to be due to the need to keep hot keys on the merchant side in order to support PayJoin which many merchants are unwilling to do for the advantages PayJoin brings. Initial blog post on PayJoin Original PayJoin BIP - 78 PayJoin Adoption - Bitcoin Wiki Peer-to-Peer Communication Encryption - BIP 151 and BIP 324 # Status: BIP 324 deployed in Bitcoin Core v26.x and enabled by default in v27.0 Pros: Prevents simple snooping by ISPs and mobile carriers; Prevents man-in-the-middle attacks by rogue nodes pretending to be your specified remote node; Can pin known-good nodes to ensure you have healthy nodes as peers Cons: Increased overhead in p2p protocol; New DoS vectors created by the use of encryption; Does not fully prevent deep packet inspection by ISPs etc. Peer-to-peer communication encryption is a large and necessary step forward in securing the p2p network in Bitcoin against common attacks and providing basic privacy to those running a node from their ISP and other basic surveillance, and has been proposed for Bitcoin via BIPs 151 and 324. To quote the author: BIP324 proposes a new Bitcoin P2P protocol, which features transport encryption and slightly lower bandwidth usage. p2p comms encryption is something that is not commonly done in the cryptocurrency space, but is also being worked on in the Monero community (linked below). BIP 324 website Original BIP - 151 Official BIP - 324 Monero’s investigation into p2p comms encryption Issue around Monero’s p2p comms proposal Dandelion - BIP 156 # Status: Rejected Pros (specifically Dandelion++ iteration): Prevents deterministic linking of transactions back to their originating node by active surveillance of the p2p network; Provides strong network-level privacy without necessitating use of an anonymity network (which have their own serious DoS/Sybil issues) Cons (specifically Dandelion++ iteration): Transaction broadcast takes much longer (usually 1-1.5min for complete propagation instead of just a few seconds); Opens up new DoS vectors if using a malicious remote node and not your own Dandelion is an approach to bringing plausible deniability to the Bitcoin peer-to-peer network in a way that prevents others on the network from deterministically tying transactions with the originating node. It does this by selecting a set of nodes to transmit the transaction to in series (one at a time, called the “stem” phase) and then only transmit to the rest of the network after a pre-determined number of nodes have also transmitted the transaction (called the “fluff” phase). Dandelion++, an iteration that resolves many of the problems with the original Dandelion proposal, was implemented in Monero in 2020. Original Dandelion BIP - 156 Dandelion++ journal article “Dandelion for Monero” - Monero Outreach “How Dandelion++ Keeps Monero’s Transaction Origins Private” - LocalMonero Taproot - BIP 341 # Status: Draft (but actually not, as it’s already deployed in Bitcoin via soft-fork) Pros: Drastically improved privacy when using scripts (like multi-sig or Lightning channel opens/closes) assuming broad adoption; More scripting possibilities via Tapscript; Potential efficiency improvements, batching, etc. Cons: Non-cooperative channel-close transactions must still reveal script, negating privacy gains in those situations 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 towards 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. Original Taproot BIP - 341 SNICKER # Status: Abandoned, never f...