A model of this newsletter was once in the beginning revealed on sethforprivacy.com.
Ragnar Lifthrasir asked for a list of Bitcoin proposals and concepts to support privateness that both are nonetheless a piece in development, had been deserted or by no means applied, or did not make an have an effect on, and so here’s my strive at simply that.
This may increasingly certainly not be an exhaustive record, and I may just use any lend a hand I will get with preserving it up-to-the-minute or discovering ancient proposals that experience fallen out of style. The sections under shall be damaged down through mission or implementation and so as of proposal (the place conceivable).
Word: Whilst a few of these proposals had been non-starters or were deserted, some are fascinating and probably promising proposals. This isn’t a “corridor of disgrace,” however reasonably a possibility to be informed from previous proposals and stay alongside of new ones as we cross alongside.
Bitcoin
Confidential Transactions
Standing: By no means officially proposed for Bitcoin
Execs: Significantly stepped forward privateness towards amount-based heuristics; allows greatly-improved and extra versatile app-layer privateness equipment for Bitcoin (i.e., unequal output CoinJoins)
Cons: Provide auditability turns into extra advanced (however remains to be conceivable) and is determined by extra complex cryptography; transaction sizes and verification instances are each considerably larger
Confidential Transactions (utilized in Monero since 2017 and Liquid since 2018) are a method used to blind the quantities in a transaction in some way this is nonetheless verifiable and provable with out revealing quantities to any individual outdoor of the transaction members. Miners, nodes and exterior observers can nonetheless validate that transactions don’t create or break budget with out realizing the real quantities being transferred.
Additional Studying:
Reusable Fee Codes For Hierarchical Deterministic Wallets — BIP47
Standing: Unanimously discouraged for implementation
Execs: A lot more straightforward receipt of budget to a static tackle whilst maintaining privateness; no direct hyperlink between cost code and on-chain addresses/transactions (in contrast to static Bitcoin addresses)
Cons: Maximum variations require a notification transaction to be despatched on-chain in order that the recipient is aware of search for budget despatched to them; notification transaction can undermine privateness if finished incorrectly
The proposal for Reusable Fee Codes is without doubt one of the best-known BIPs because of its adoption and use through Samourai Wallet underneath the title “PayNym.” This proposal is very similar to Stealth Addresses in {that a} unmarried cost code can be utilized to derive unlinkable on-chain addresses, however differs in that it does no longer use other addressing codecs on-chain and as a substitute is determined by a notification transaction to permit the recipient to search out their budget on-chain.
PayNyms, regardless of being rejected/discouraged in BIP47 have observed moderately popular use and feature just lately been applied in Sparrow Wallet or even through a Bitcoin mining pool “Lincoin.”
A great summary of the three main Reusable Payment Code schemes has been provided by Ruben Somsen, the writer of Silent Payments within the gist for Reusable Taproot Addresses.
Additional Studying:
Stealth Addresses — BIP63
Standing: By no means permitted as a BIP regardless of being given a BIP quantity
Execs: When enforced, prevents all hyperlinks between off-chain addresses/pubkeys and on-chain one-time addresses; breaks all address-based heuristics
Cons: Wallets now must scan all transactions to validate which of them are owned through the consumer’s non-public keys; can not do easy address-based pockets sync
Stealth Addresses are a unique idea that permits a receiver to proportion or put up a unmarried static tackle that senders can derive one-time addresses from, breaking any cryptographic hyperlinks to the shared/revealed tackle on-chain. Whilst this does upload substantial overhead to pockets scan instances (all transactions will have to be scanned to peer what’s owned through your non-public keys as a substitute of simply validating identified addresses) it fully breaks pockets clustering through addresses at the side of many different key heuristics.
Stealth Addresses had been in the beginning proposed for Bitcoin in 2011 on BitcoinTalk, however had been abandoned as a BIP after OP_RETURN was changed:
“OP_RETURN were given modified to 40 bytes on the remaining minute, fighting my stealth tackle usual from running, and moved directly to paintings on different issues.”
–u/petertodd
Whilst Darkish Pockets did enforce Stealth Addresses for Bitcoin, the pockets by no means formally introduced and was once deserted. Monero, then again, comprises Stealth Addresses as they had been a core a part of the unique Cryptonote protocol that Monero was once comprised of.
Additional Studying:
PayJoin — BIP78
Standing: Draft
Execs: Creates transactions that glance standard however spoil not unusual heuristics; simple to accomplish when supported through the recipient
Cons: Calls for scorching pockets at the service provider/recipient aspect, can’t ship to easy tackle and many others.; malicious sender can try to pressure recipient to expose UTXOs (assault is mitigated if correctly applied)
PayJoin can be widely known to the Bitcoin privateness crowd because it has gotten some media and minor adoption regardless of its respectable “draft” standing. PayJoin shall we the sender and recipient of a transaction paintings in combination to construct a blended transaction that features a UTXO (or extra) from each the sender and meant recipient of budget, obfuscating the real nature of the cost on-chain.
A equivalent protocol was once applied in Samourai Wallet in 2019 as “Stowaway” (prior to the PayJoin proposal BIP), and PayJoin right kind was once applied in BTCPay Server in June 2020, JoinMarket in August 2020, Blue Wallet in October 2020, and Sparrow Wallet in November 2020. See those paperwork for more info:
Even if applied in some wallets and equipment, PayJoin utilization sadly turns out to stay very sparse nowadays (regardless that it’s laborious to come across on-chain so could be upper than we notice). Many of the loss of adoption seems to be because of the want to stay scorching keys at the service provider aspect with the intention to beef up PayJoin which many traders are unwilling to do for the benefits PayJoin brings.
Additional Studying:
Peer-To-Peer Communique Encryption — BIP151 and BIP324
Standing: Authentic BIP151 withdrawn, new BIP324 in draft
Execs: Prevents easy snooping through internet-service suppliers (ISPs) and cellular carriers; prevents man-in-the-middle assaults through rogue nodes pretending to be your specified far flung node; can pin identified just right nodes to be sure to have wholesome nodes as friends
Cons: Larger overhead in peer-to-peer (P2P) protocol; new denial-of-service (DoS) vectors created by way of encryption; does no longer totally save you deep packet inspection through ISPs, and many others.
P2P verbal exchange encryption is a big and vital step ahead in securing the P2P community in Bitcoin towards not unusual assaults and offering fundamental privateness to these working a node from their ISP and different fundamental surveillance, and has been proposed for Bitcoin by the use of BIPs 151 and 324.
“BIP324 proposes a brand new Bitcoin P2P protocol, which options delivery encryption and moderately decrease bandwidth utilization.”
P2P communications encryption is one thing that isn’t regularly finished within the cryptocurrency area, however may be being labored on within the Monero neighborhood.
Additional Studying:
Dandelion — BIP156
Standing: Rejected
Execs (In particular Dandelion++ Iteration): Prevents deterministic linking of transactions again to their originating node through energetic surveillance of the P2P community; supplies sturdy network-level privateness with out necessitating use of an anonymity community (that have their very own severe DoS/Sybil problems)
Cons (In particular Dandelion++ Iteration): Transaction broadcast takes for much longer (generally one minute to one-and-a-half mins for entire propagation as a substitute of only some seconds); opens up new DoS vectors if the use of a malicious far flung node and no longer your individual
Dandelion is an technique to bringing believable deniability to the Bitcoin peer-to-peer community in some way that forestalls others at the community from deterministically tying transactions with the originating node. It does this through deciding on a suite of nodes to transmit the transaction to in collection (one by one, referred to as the “stem” segment) after which simplest transmit to the remainder of the community after a predetermined selection of nodes have additionally transmitted the transaction (referred to as the “fluff” segment).
Dandelion++, an iteration that resolves lots of the issues of the unique Dandelion proposal, was once applied in Monero in 2020.
Additional Studying:
Taproot — BIP341
Standing: Draft (however in fact no longer, because it’s already deployed in Bitcoin by the use of comfortable fork)
Execs: Significantly stepped forward privateness when the use of scripts (like multisig or Lightning channel opens/closes) assuming huge adoption; extra scripting chances by the use of Tapscript; doable potency enhancements, batching, and many others.
Cons: Non-cooperative, channel-close transactions will have to nonetheless expose script, negating privateness positive factors in the ones eventualities
Taproot is most probably essentially the most well-recognized BIP in this record, and has in fact been applied in Bitcoin regardless of nonetheless being marked as “Draft” within the BIP GitHub repository.
Taproot is in point of fact simplest in this record because it has thus far long gone nearly unused, however as issues can transfer very slowly towards adoption in Bitcoin (particularly when not obligatory, as Taproot utilization is) it’ll most probably take a number of years prior to Taproot is broadly used.
As soon as Taproot is usable for Lightning Community channel opens it’ll supply just right privateness through hiding the script main points in each and every channel open transaction and making it a lot more difficult to search out channel opens on-chain in Bitcoin. This privateness does spoil down within the match of a non-cooperative channel shut, on the other hand, because the script will have to be published on this case on-chain.
Additional Studying:
SNICKER
Standing: Deserted, by no means officially proposed for Bitcoin
As I don’t know a lot about SNICKER I gained’t cross into element on my ideas, however see the quote below for the abstract of what the proposal was once supposed to do:
“SNICKER (Easy Non-Interactive Coinjoin with Keys for Encryption Reused) is an easy means for permitting the introduction of a two birthday party coinjoin with none synchronisation or interplay between the members. It is determined by the speculation of reused keys (both reused addresses, or id of possession of signed inputs and thus pubkeys in signatures).”
So far as I will inform the proposal has been deserted since 2020.
Additional Studying:
CoinSwap
Standing: Paintings in development, however by no means officially proposed for Bitcoin
Execs: Seems to be an ordinary transaction sort on-chain
Cons: Does no longer in fact obfuscate or spoil any on-chain historical past, it simply makes an attempt to damage easy possession heuristics; lets in the ones with tainted budget to change for “blank” budget to the detriment of the change player; no transparent privateness benefits in maximum eventualities
CoinSwap was once a well-liked and oft-discussed proposal in 2020 to permit customers to change UTXOs (and thus their related historical past), however was once met with sturdy pushback because it does not anything to take away historical past or spoil deterministic hyperlinks.
See the below quote for a easy abstract of CoinSwap:
“Coinswap is a protocol that permits two or extra customers to create a suite of transactions that appear to be unbiased bills however which in fact change their cash with each and every different, optionally creating a cost within the procedure.”
It appeared that CoinSwap have been deserted, as there was once no development made since 2020, however just lately, Chris Belcher introduced an implementation of CoinSwap referred to as Teleport Transactions.
Additional Studying:
Silent Bills
Standing: Paintings in development, no longer but officially proposed for Bitcoin
Execs: A lot more straightforward receipt of budget to a static tackle whilst maintaining privateness; no direct hyperlink between cost code and on-chain addresses/transactions (in contrast to static Bitcoin addresses); does no longer require on-chain notification transaction, in contrast to BIP47
Cons: These days utterly incompatible with mild wallets; including a brand new Silent Fee code after preliminary block obtain (IBD) calls for utterly restarting IBD; calls for consistent scanning of the blockchain for brand new makes use of/transactions
Silent Bills are the entire rage in fresh Bitcoin dialogue, and are equivalent in many ways to BIP47 (discussed above).
Whilst in addition they be offering the power to proportion or publicize a unmarried static cost code and obtain bills that don’t seem to be linkable on-chain, there stay severe tradeoffs within the manner that make light-wallet utilization nearly unimaginable and will require entire re-downloading of the Bitcoin blockchain to search out new transactions for any new Silent Addresses.
It’s going to be fascinating to peer this proposal play out however thus far the easier possibility seems to be BIP47 nonetheless.
A great summary of the three main reusable payment code schemes has been provided by Ruben Somsen, the writer of Silent Bills, within the gist for Reusable Taproot addresses.
Additional Studying:
Reusable Taproot Addresses
Standing: Paintings in development, no longer but officially proposed for Bitcoin
Execs: A lot more straightforward receipt of budget to a static tackle whilst maintaining privateness; no direct hyperlink between cost code and on-chain addresses/transactions (in contrast to static Bitcoin addresses); combines first cost and notification into one “actual” transaction, in contrast to BIP47; notification transaction seems identical to another Taproot spend on-chain
Cons: Sender and receiver each will have to beef up and use Taproot; sender must observe a different protocol in an effort to get well from backup
Whilst this proposal bears many similarities to BIP47 and Silent Payments, it leverages new features in Taproot to actually support at the tradeoffs taken through BIP47 reusable cost codes. A great summary has been provided by Ruben Somsen, the writer of Silent Payments within the gist under:
Reusable Taproot addresses:
- No steady scanning of each transaction
- One-time interplay with the recipient (stateful for sender: in the event that they fail to remember, they want to engage once more)
- No on-chain footprint
- Sender must observe a different protocol in an effort to get well from backup (this problem will also be mitigated, see under)
BIP47:
- No steady scanning of each transaction
- No interplay with the recipient
- On-chain footprint (or then again one-time interplay and stateful backups)
Silent Bills:
- Steady scanning of each transaction (will increase price of working complete node)
- No interplay with the recipient
- No on-chain footprint
Additional Studying:
Lightning Community
Please observe that these kind of proposals are nonetheless very a lot a piece in development and haven’t begun to be given a transparent sure/no approval. As such, the Lightning Community proposals are basically added under as vital trends to observe that probably be offering stepped forward privateness when the use of the Lightning Community.
Because the Lightning Community was once in the beginning designed as a device for scalability and no longer privateness, lots of the core design choices first of all selected are extraordinarily adverse to consumer privateness. Most of the proposals under are in the hunt for to treatment the ones problems and confidently shall be ready to take action with out harming cost reliability or routing potency.
Course Blinding
Standing: Paintings in development
Execs: Prevents sender from ascertaining complete path to recipient; hides recipient node alias/pubkey; supplies a lot better recipient privateness total as opposed to present clear routing strategies; may give higher cost luck price through offering native routing information in some explicit situations
Cons: May also be tough to craft blinded routes in explicit routing graph situations; could have a destructive have an effect on on cost luck price in explicit situations
The present Lightning Community suffers from critical problems focused round receiver privateness, and Course Blinding is without doubt one of the key proposals in the hunt for to treatment no less than part of this factor.
To cite the proposal:
“Course blinding is a light-weight methodology to supply recipient anonymity through blinding an arbitrary quantity of hops on the finish of an onion trail.”
Course blinding remains to be very a lot a piece in development however displays promise for permitting a receiver to obtain budget with out deterministically revealing the overall node receiving the budget.
Additional Studying:
Trampoline Onion Routing
Standing: Paintings in development
Execs: Can permit mild wallets to craft routes in a privacy-preserving method and not using a complete course graph; can be utilized to supply receiver privateness from the sender (however no longer the trampoline node so far as I will inform)
Cons: None that I do know of presently
Whilst no longer strictly a privateness development, Trampoline Onion Routing may give higher course privateness in some situations for the receiver and so is discussed right here. It can be paired with course blinding to supply even higher obtain privateness, particularly to be used instances the place you can not run a complete node or assemble complete routes your self for no matter explanation why.
The overall privateness implications are nonetheless into consideration, however it’ll be a fascinating proposal to observe at the side of.
Additional Studying:
Alias SCID
Standing: Paintings in development
Execs: Prevents easy linking of bills to unmarried node alias/pubkey through the use of a novel alias in keeping with channel/peer
Cons: None that I do know of presently
One of the vital essential privateness problems in Lightning nowadays is the truth that nodes have everlasting aliases and pubkeys which might be used for gossip and channel control, and as such, any receipt of bills leaks your nodes alias and pubkey to the sender of the cost.
The important thing technique to resolving this factor in Lightning is one thing referred to as “Alias SCID,” which lets you pressure your friends to just seek advice from you or your channels through an alias which will also be distinctive to each and every peer and/or channel.
Additional Studying:
Gives — BOLT12
Standing: Paintings in development
Execs: Significantly-improved privateness and versatility for bills because the recipient; a lot smaller QR codes and far much less information wanted within the be offering itself (because the vital information is gathered from the recipients node immediately as a substitute of being all integrated within the bill as in BOLT11 invoices)
Cons: None that I do know of presently
BOLT12 is a mix of lots of the different proposed enhancements and integrates them into a brand new and a lot more versatile bill sort for Lightning, often known as an “be offering.” The implementation of BOLT 12 along course blinding and node alias SCIDs could be a large step ahead for each privateness and consumer revel in in Lightning, and is relatively of the present holy grail of proposals.
Remember to control its building when you use or have an interest within the Lightning Community because it guarantees to mend lots of the present problems.
Additional Studying:
Sidechains
The Liquid Community
Standing: Reside since 2018
Execs: Mildly stepped forward per-transaction privateness because of Confidential Transactions (however most commonly pointless because of nearly no utilization decreasing crowd to cover in); inexpensive charges than on-chain
Cons: Custodial (by the use of a federation); nearly no utilization will provide you with nearly no crowd to cover in; previous problems with “emergency” multisig being held through only a few events
The Liquid Community is a Bitcoin-pegged and federated sidechain for Bitcoin that permits customers to peg BTC to redeem it for L-BTC after which have the ability to transact at the Liquid Community.
Liquid supplies average privateness enhancements over on-chain Bitcoin because of its use of Confidential Transaction and this can be very reasonable to transact in.
Customers will have to be very mindful that Liquid is a federated type the place custodians dangle the keys in your bitcoin, and thus your budget are liable to loss or robbery and also you will have to no longer think you’ll at all times have the ability to convert again to BTC.
However Liquid stays nearly unused even after 4 years of being within the wild and heavy marketing.
Additional Studying:
FediMint
Standing: Paintings in development
Execs: Very sturdy privateness when transacting throughout the sidechain; interoperable with the Lightning Community with out requiring each and every consumer to run a node/organize channels/and many others.; any individual can get started a brand new minimint, no longer simply explicit other folks/teams; can select a particular minimint to used in accordance with federation participants recognition, consider, and many others.; can function a center floor between self-sovereign Lightning (Zeus, Core LN, LND, and many others.) and “single-custodian” Lightning (Pockets of Satoshi, Money App, Strike, and many others.) whilst maintaining consumer privateness from custodians
Cons: Custodial (by the use of federations); doable regulatory force on federation participants because of custody/switch of consumer’s budget; centralization of Lightning Community because of customers no longer working their very own node, managing channels, and many others. and as a substitute depending on federation Lightning products and services
FediMint (and the particular preliminary implementation, minimint) is a fairly new proposal for development a federated Chaumian-blinded eCash as a sidechain to Bitcoin, denominated in bitcoin. Those federated sidechains could be fairly small, interoperable and would compete on recognition, uptime and charges.
Whilst it’s nonetheless very a lot a piece in development, minimint holds promise for a center floor between totally self-sovereign Lightning Community utilization (Zeus, Core LN, LND, and many others.) and single-custodian Lightning Community utilization (Money App, Strike, and many others.) through permitting a depended on federation of custodians to carry budget and organize Lightning node(s) for his or her customers.
Word that the proposal remains to be totally custodial, however has differing tradeoffs in comparison to one thing like the Liquid Network.
Additional Studying:
This can be a visitor put up through Seth For Privateness. Evaluations expressed are fully their very own and don’t essentially mirror the ones of BTC Inc or Bitcoin Mag.
