Reviewing Bitcoin’s historical past of proposed privateness enhancements can assist us be informed from the previous and stay alongside of new enhancements as we pass.
Reviewing Bitcoin’s historical past of proposed privateness enhancements can assist us be informed from the previous and stay alongside of new enhancements as we pass.
A model of this text was once in the beginning printed on sethforprivacy.com.
Ragnar Lifthrasir asked for a list of Bitcoin proposals and concepts to fortify privateness that both are nonetheless a piece in development, have been deserted or by no means applied, or didn’t make an affect, and so this is my strive at simply that.
This may increasingly in no way be an exhaustive record, and I may just use any assist I will be able to get with protecting it up-to-the-minute or discovering ancient proposals that experience fallen out of style. The sections beneath shall be damaged down via challenge or implementation and so as of proposal (the place imaginable).
Word: Whilst a few of these proposals have been non-starters or had been deserted, some are fascinating and probably promising proposals. This isn’t a “corridor of disgrace,” however reasonably a possibility to be told from previous proposals and stay alongside of new ones as we pass alongside.
Bitcoin
Confidential Transactions
Standing: By no means officially proposed for Bitcoin
Execs: Significantly advanced privateness in opposition to amount-based heuristics; allows greatly-improved and extra versatile app-layer privateness gear for Bitcoin (i.e., unequal output CoinJoins)
Cons: Provide auditability turns into extra complicated (however remains to be imaginable) and is dependent upon extra complicated cryptography; transaction sizes and verification instances are each considerably greater
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 somebody outdoor of the transaction individuals. Miners, nodes and exterior observers can nonetheless validate that transactions don’t create or spoil price range with out realizing the actual quantities being transferred.
Additional Studying:
Reusable Cost Codes For Hierarchical Deterministic Wallets — BIP47
Standing: Unanimously discouraged for implementation
Execs: A lot more straightforward receipt of price range to a static tackle whilst maintaining privateness; no direct hyperlink between fee 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 the best way to search for price range despatched to them; notification transaction can undermine privateness if finished incorrectly
The proposal for Reusable Cost Codes is likely one of the best-known BIPs because of its adoption and use via Samourai Wallet beneath the title “PayNym.” This proposal is very similar to Stealth Addresses in {that a} unmarried fee code can be utilized to derive unlinkable on-chain addresses, however differs in that it does now not use other addressing codecs on-chain and as a substitute is dependent upon a notification transaction to permit the recipient to seek out their price range on-chain.
PayNyms, in spite of being rejected/discouraged in BIP47 have noticed fairly in style use and feature lately been applied in Sparrow Wallet or even via a Bitcoin mining pool “Lincoin.”
A great summary of the three main Reusable Payment Code schemes has been provided by Ruben Somsen, the creator of Silent Payments within the gist for Reusable Taproot Addresses.
Additional Studying:
Stealth Addresses — BIP63
Standing: By no means approved as a BIP in spite 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 need to scan all transactions to validate which of them are owned via the consumer’s non-public keys; can now not do easy address-based pockets sync
Stealth Addresses are a singular thought 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/printed tackle on-chain. Whilst this does upload substantial overhead to pockets scan instances (all transactions will have to be scanned to look what’s owned via your non-public keys as a substitute of simply validating recognized addresses) it totally breaks pockets clustering via addresses at the side of many different key heuristics.
Stealth Addresses have been in the beginning proposed for Bitcoin in 2011 on BitcoinTalk, however have been abandoned as a BIP after OP_RETURN was changed:
“OP_RETURN were given modified to 40 bytes on the final minute, fighting my stealth tackle same old from running, and moved directly to paintings on different issues.”
–u/petertodd
Whilst Darkish Pockets did put in force Stealth Addresses for Bitcoin, the pockets by no means formally introduced and was once deserted. Monero, alternatively, comprises Stealth Addresses as they have been a core a part of the unique Cryptonote protocol that Monero was once constituted of.
Additional Studying:
PayJoin — BIP78
Standing: Draft
Execs: Creates transactions that glance customary however destroy commonplace heuristics; simple to accomplish when supported via the recipient
Cons: Calls for scorching pockets at the service provider/recipient facet, can not ship to easy tackle and many others.; malicious sender can try to power recipient to show UTXOs (assault is mitigated if correctly applied)
PayJoin can also be widely recognized to the Bitcoin privateness crowd because it has gotten some media and minor adoption in spite of its legit “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 price range, obfuscating the actual nature of the fee on-chain.
A equivalent protocol was once applied in Samourai Wallet in 2019 as “Stowaway” (prior to the PayJoin proposal BIP), and PayJoin correct 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:
Despite the fact that applied in some wallets and gear, PayJoin utilization sadly turns out to stay very sparse these days (even though it’s onerous to stumble on on-chain so may well be upper than we understand). Lots of the loss of adoption seems to be because of the want to stay scorching keys at the service provider facet in an effort to toughen PayJoin which many traders are unwilling to do for the benefits PayJoin brings.
Additional Studying:
Peer-To-Peer Communique Encryption — BIP151 and BIP324
Standing: Unique BIP151 withdrawn, new BIP324 in draft
Execs: Prevents easy snooping via internet-service suppliers (ISPs) and cell carriers; prevents man-in-the-middle assaults via rogue nodes pretending to be your specified far off node; can pin recognized excellent nodes to be sure to have wholesome nodes as friends
Cons: Greater overhead in peer-to-peer (P2P) protocol; new denial-of-service (DoS) vectors created by way of encryption; does now not totally save you deep packet inspection via ISPs, and many others.
P2P communique encryption is a huge and essential step ahead in securing the P2P community in Bitcoin in opposition to commonplace assaults and offering elementary privateness to these working a node from their ISP and different elementary surveillance, and has been proposed for Bitcoin by way 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 repeatedly finished within the cryptocurrency house, however may be being labored on within the Monero neighborhood.
Additional Studying:
Dandelion — BIP156
Standing: Rejected
Execs (Particularly Dandelion++ Iteration): Prevents deterministic linking of transactions again to their originating node via lively surveillance of the P2P community; supplies robust network-level privateness with out necessitating use of an anonymity community (that have their very own critical DoS/Sybil problems)
Cons (Particularly Dandelion++ Iteration): Transaction broadcast takes for much longer (typically one minute to one-and-a-half mins for whole propagation as a substitute of only some seconds); opens up new DoS vectors if the usage of a malicious far off node and now not your personal
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 via settling on a suite of nodes to transmit the transaction to in collection (separately, known as the “stem” segment) after which best transmit to the remainder of the community after a predetermined selection of nodes have additionally transmitted the transaction (known as the “fluff” segment).
Dandelion++, an iteration that resolves most of the issues of the unique Dandelion proposal, was once applied in Monero in 2020.
Additional Studying:
Taproot — BIP341
Standing: Draft (however in fact now not, because it’s already deployed in Bitcoin by way of comfortable fork)
Execs: Significantly advanced privateness when the usage of scripts (like multisig or Lightning channel opens/closes) assuming vast adoption; extra scripting chances by way of Tapscript; possible potency enhancements, batching, and many others.
Cons: Non-cooperative, channel-close transactions will have to nonetheless expose script, negating privateness positive aspects in the ones scenarios
Taproot is most likely probably the most well-recognized BIP in this record, and has in fact been applied in Bitcoin in spite of nonetheless being marked as “Draft” within the BIP GitHub repository.
Taproot is in point of fact best in this record because it has up to now long gone nearly unused, however as issues can transfer very slowly towards adoption in Bitcoin (particularly when non-compulsory, as Taproot utilization is) it’ll most likely take a number of years prior to Taproot is extensively used.
As soon as Taproot is usable for Lightning Community channel opens it’ll supply excellent privateness via hiding the script main points in each and every channel open transaction and making it a lot tougher to seek out channel opens on-chain in Bitcoin. This privateness does destroy down within the match of a non-cooperative channel shut, alternatively, because the script will have to be printed 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 received’t pass into element on my ideas, however see the quote below for the abstract of what the proposal was once intended to do:
“SNICKER (Easy Non-Interactive Coinjoin with Keys for Encryption Reused) is an easy way for permitting the introduction of a two celebration coinjoin with none synchronisation or interplay between the individuals. It is dependent upon the theory of reused keys (both reused addresses, or identity of possession of signed inputs and thus pubkeys in signatures).”
So far as I will be able to 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 a typical transaction sort on-chain
Cons: Does now not in fact obfuscate or destroy any on-chain historical past, it simply makes an attempt to damage easy possession heuristics; lets in the ones with tainted price range to change for “blank” price range to the detriment of the change player; no transparent privateness benefits in maximum scenarios
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 robust pushback because it does not anything to take away historical past or destroy 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 impartial bills however which in fact change their cash with each and every different, optionally creating a fee within the procedure.”
It gave the impression that CoinSwap were deserted, as there was once no development made since 2020, however lately, Chris Belcher introduced an implementation of CoinSwap known as Teleport Transactions.
Additional Studying:
Silent Bills
Standing: Paintings in development, now not but officially proposed for Bitcoin
Execs: A lot more straightforward receipt of price range to a static tackle whilst maintaining privateness; no direct hyperlink between fee code and on-chain addresses/transactions (in contrast to static Bitcoin addresses); does now not require on-chain notification transaction, in contrast to BIP47
Cons: Lately utterly incompatible with gentle wallets; including a brand new Silent Cost code after preliminary block obtain (IBD) calls for utterly restarting IBD; calls for consistent scanning of the blockchain for brand spanking new makes use of/transactions
Silent Bills are all of the 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 fee code and obtain bills that aren’t linkable on-chain, there stay critical tradeoffs within the manner that make light-wallet utilization nearly inconceivable and will require whole re-downloading of the Bitcoin blockchain to seek out new transactions for any new Silent Addresses.
It is going to be fascinating to look this proposal play out however up to now 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 creator of Silent Bills, within the gist for Reusable Taproot addresses.
Additional Studying:
Reusable Taproot Addresses
Standing: Paintings in development, now not but officially proposed for Bitcoin
Execs: A lot more straightforward receipt of price range to a static tackle whilst maintaining privateness; no direct hyperlink between fee code and on-chain addresses/transactions (in contrast to static Bitcoin addresses); combines first fee and notification into one “actual” transaction, in contrast to BIP47; notification transaction seems similar to some other Taproot spend on-chain
Cons: Sender and receiver each will have to toughen and use Taproot; sender must practice a distinct protocol so that you can get well from backup
Whilst this proposal bears many similarities to BIP47 and Silent Payments, it leverages new functions in Taproot to actually fortify at the tradeoffs taken via BIP47 reusable fee codes. A great summary has been provided by Ruben Somsen, the creator of Silent Payments within the gist beneath:
Reusable Taproot addresses:
- No steady scanning of each transaction
- One-time interplay with the recipient (stateful for sender: in the event that they put out of your mind, they want to have interaction once more)
- No on-chain footprint
- Sender must practice a distinct protocol so that you can get well from backup (this drawback will also be mitigated, see beneath)
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 a majority of these proposals are nonetheless very a lot a piece in development and have not begun to be given a transparent sure/no approval. As such, the Lightning Community proposals are principally added beneath as necessary traits to practice that probably be offering advanced privateness when the usage of the Lightning Community.
Because the Lightning Community was once in the beginning designed as a device for scalability and now not privateness, most of the core design choices first of all selected are extraordinarily destructive to consumer privateness. Most of the proposals beneath are in the hunt for to treatment the ones problems and optimistically shall be in a position to take action with out harming fee reliability or routing potency.
Path Blinding
Standing: Paintings in development
Execs: Prevents sender from ascertaining complete path to recipient; hides recipient node alias/pubkey; supplies significantly better recipient privateness total as opposed to present clear routing strategies; can give higher fee good fortune fee via offering native routing information in some explicit situations
Cons: Will also be tricky to craft blinded routes in explicit routing graph situations; could have a adverse affect on fee good fortune fee in explicit situations
The present Lightning Community suffers from serious problems targeted round receiver privateness, and Path Blinding is likely one of the key proposals in the hunt for to treatment no less than part of this factor.
To cite the proposal:
“Path blinding is a light-weight methodology to supply recipient anonymity via blinding an arbitrary quantity of hops on the finish of an onion trail.”
Path blinding remains to be very a lot a piece in development however displays promise for permitting a receiver to obtain price range with out deterministically revealing the general node receiving the price range.
Additional Studying:
Trampoline Onion Routing
Standing: Paintings in development
Execs: Can permit gentle wallets to craft routes in a privacy-preserving approach with out a complete direction graph; can be utilized to supply receiver privateness from the sender (however now not the trampoline node so far as I will be able to inform)
Cons: None that I do know of at the moment
Whilst now not strictly a privateness growth, Trampoline Onion Routing can give higher direction privateness in some situations for the receiver and so is discussed right here. It will also be paired with direction blinding to supply even higher obtain privateness, particularly to be used instances the place you can’t run a complete node or assemble complete routes your self for no matter reason why.
The total privateness implications are nonetheless into consideration, however it’ll be a fascinating proposal to practice at the side of.
Additional Studying:
Alias SCID
Standing: Paintings in development
Execs: Prevents easy linking of bills to unmarried node alias/pubkey via the usage of a singular alias in step with channel/peer
Cons: None that I do know of at the moment
One of the crucial crucial privateness problems in Lightning these days 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 fee.
The important thing technique to resolving this factor in Lightning is one thing known as “Alias SCID,” which lets you power your friends to simply confer with you or your channels via 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 essential information is accumulated from the recipients node at once as a substitute of being all incorporated within the bill as in BOLT11 invoices)
Cons: None that I do know of at the moment
BOLT12 is a mixture of most of the different proposed enhancements and integrates them into a brand new and a lot more versatile bill sort for Lightning, also known as an “be offering.” The implementation of BOLT 12 along direction blinding and node alias SCIDs could be a large step ahead for each privateness and consumer revel in in Lightning, and is reasonably of the present holy grail of proposals.
You should definitely keep watch over its building for those who use or have an interest within the Lightning Community because it guarantees to mend most of the present problems.
Additional Studying:
Sidechains
The Liquid Community
Standing: Are living since 2018
Execs: Mildly advanced per-transaction privateness because of Confidential Transactions (however most commonly needless because of virtually no utilization lowering crowd to cover in); less expensive charges than on-chain
Cons: Custodial (by way of a federation); virtually no utilization will give you virtually no crowd to cover in; previous problems with “emergency” multisig being held via 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 be capable of transact at the Liquid Community.
Liquid supplies reasonable privateness enhancements over on-chain Bitcoin because of its use of Confidential Transaction and this can be very reasonable to transact in.
Customers must be very conscious that Liquid is a federated fashion the place custodians cling the keys for your bitcoin, and thus your price range are prone to loss or robbery and also you must now not suppose you’re going to at all times be capable of 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 robust 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.; somebody can get started a brand new minimint, now not simply explicit other people/teams; can select a particular minimint to used according to federation contributors recognition, agree with, 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 keeping consumer privateness from custodians
Cons: Custodial (by way of federations); possible regulatory power on federation contributors because of custody/switch of consumer’s price range; centralization of Lightning Community because of customers now not working their very own node, managing channels, and many others. and as a substitute depending on federation Lightning services and products
FediMint (and the particular preliminary implementation, minimint) is a fairly new proposal for construction 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.) via permitting a relied on federation of custodians to carry price range 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 via Seth For Privateness. Critiques expressed are totally their very own and don’t essentially replicate the ones of BTC Inc or Bitcoin Mag.
