August 2020

29 minute read

Welcome to the third issue of ‘This Month in Bitcoin Privacy’ newsletter. Enjoy!

"Emperor moth (Saturnia pavonia)" by Roger Lancefield is licensed under CC BY-SA 2.0

August 2nd - FULL NODE DEEP DIVE: RONINDOJO

The Orange County (OC) Bitcoin Network, hosted by Stephen Cole and Brian Harrington, held their fifth online event in a series exploring Bitcoin full node devices and software. This session, sponsored by Bitcoin Magazine, featured RoninDojo developers Zelko and Guerra Moneta, who debuted their new website during the stream. As I mentioned in TMIBP01, this is an installation assistant and user interface for Samourai Wallet’s self-hosted Dojo full node backend.

This Bitcoin thing is a lot more than “number go up.”

Zelko and Guerra talked about how the project originated in the creation of Dojo user guides, which grew into an initiative to simplify and automate some of the processes involved as (eventually) a plug-and-play solution. They covered the existing features and explained why they made certain build decisions, such as not adding Lightning support. Zelko briefly discussed a future premium offering of RoninDojo for around $100 in order to sustain development. He gave a live demonstration of the GUI, designed by Pavel Ševčík. For the last twenty minutes, they rolled through the roadmap, hardware specifications, and answered miscellaneous questions.

As of August 31st, RoninDojo v1.6 and the UI were officially released.

For help to start, see Bitcoin Q+A’s user guide on “Connecting or Migrating your Samourai Wallet to RoninDojo.”

August 3rd - JUNK IN THE TRUNC: LIGHTNING PRIVACY

The Lightning Junkies podcast released episode LNJ034, an interview with data scientist and educator René Pickhardt. He is a co-author of ‘Mastering the Lightning Network’ and currently working on a PhD for the Norwegian University of Science and Technology (NTNU).

After relaying his background, how he came to Bitcoin, and the reality of Lightning adoption, the focus of the episode was Pickhardt’s blackmail attack disclosure from June, and other past attack vectors. In the last fifteen minutes (52:10), he plugged his own proposed BOLT14, “a collection of recommendations that help nodes to improve their abilities to discover payment paths with sufficient liquidity.” This is based on a paper he published with NTNU associate professor Mariusz Nowostawski in December 2019.

Looking at different strategies of finding rebalancing cycles we suggest, for the sake of speed, that nodes share with their neighbors on which local channels they would like to have inbound or outbound capacity. This information could easily be probed anyway and will not worsen the privacy of the nodes involved in re-balancing.

… The developed rebalancing algorithm uses a heuristic in which participants use the local knowledge and make local adjustments to estimate the optimization problem of finding [balance function] b such that [the imbalance of the network] G is minimized. The algorithm therefore is privacy-aware.

… As privacy aware payment channel networks use source-based path finding without knowing the constraints of the channels along an attempted path, the likelihood of conducting a successful payment with few attempts becomes considerably higher in a balanced network. Our results show that nodes do not need to strive for ν_u = 0.5 and perfect local balance of their channels in order to produce high success rate of random payments. It is sufficient for the overall network to be balanced if every node tries to optimize their channel balance coefficients [to] be almost equal. This can be achieved by making circular rebalancing payments.

Pickhardt said that while it sounds “a little bit counter-intuitive that when you share information, you actually hide more information with this,” he hopes that he can “convince the developer community that [BOLT14] is a good idea.” He also discussed Just in Time (JIT) Routing, which he had proposed back in March 2019. In April of this year, he and Tikhomirov et al. argued that “an attacker can easily discover channel balances using probing,” but “JIT routing mitigates the attack while improving pathfinding!”

When I did this experiment, I actually wanted to show- it was my hypothesis in research, that there is a trade-off between privacy and reliability. I argued that JIT routing is more reliable, but it lacks privacy. Instead, it turned out that it is more reliable and increases the privacy. I [thought], ‘Wow, this is a really great result.’

… My PhD is mainly focused around pathfinding. That is obviously also an issue, because pathfinding currently isn’t that reliable.. The more I am doing my research, the more I find privacy problems in Lightning, or attack vectors, stuff like that. I think that is very natural; the better you understand a technology, the more you find its flaws and drawbacks.

Later in the month, he expressed concern that “there are so many misconceptions about the privacy of Lightning in the wild for which often just the opposite seems to be true,” and worried “we won’t be able to fix that” in ‘Mastering the Lightning Network.’ However, it is clear that an effort is being made to counter misunderstanding. For example, in the third chapter on ‘How the Lightning Network Works,’ they refer to so-called “private channels” as “unannounced” channels instead, to avoid creating “a false sense of privacy.”

(Sidenote: The timing attacks paper by Prof. Dr. Florian Tschorsch and Elias Rohrer, featured in TMIBP01 and TMIBP02, has been “accepted for publication” with the second conference on Advances in Financial Technologies).

August 4th - HRF GRANTS TO JOININBOX, ZEUS, FULLY NODED

In June, the Human Rights Foundation (HRF) launched their ‘Bitcoin Development Fund,’ focused on “making the Bitcoin network more private, decentralized, and resilient.” Their next round of grants, “1 bitcoin each, worth over $11,000 at the time of writing,” has gone to “JoinInbox creator Openoms, Zeus creator Evan Kaloudis and Fully Noded creator Fontaine.” Openoms tweeted, “It is a great honour to have my work appreciated by a Foundation standing for the values I’d like to live.”

“The whole point of privacy is hiding in the crowd, and using JoinMarket as a maker required you to dwell deep in the command line,” Openoms, who’s also a contributor to the RaspiBlitz project, told Bitcoin Magazine. “By making it easier to be a maker, we can increase the liquidity and anonymity set available for CoinJoins significantly.”

As I covered in TMIBP01, JoinInBox is a terminal-based graphical menu for the CoinJoin implementation JoinMarket. While JoinMarket have had their own GUI for four years now, he has been optimizing this menu as part of an effort to expand the application suite for RaspiBlitz. Adam Gibson has also been looking into supporting maker functions for GUI-only users and recently started work on a JoinMarket Control Center prototype with “richer UI” and “easier cross platform binary distribution.”

Zeus is a Lightning mobile app for iOS and Android via F-Droid, supporting connections to your own node over a VPN or Tor. Kaloudis’ latest v0.3.1 release also enabled multi-path payments (MPP) sending, a feature that was added to LND at the end of April. As Lightning Labs’ protocol engineer Joost Jager explained, this comes with some privacy benefits:

A final benefit of multi-path payments is that it obfuscates payment amounts. If a routing node is connected to a well-known source or destination of payments, it could guess at what the payment amount distribution looks like. Without the assumption that each payment consists of a single HTLC, the guessing becomes harder, enhancing privacy on the network.

Christian Decker talked about Point Timelock Contracts (PTLCs), multi-path payments – which he had recently implemented in c-lightning – and privacy for Livera’s SLP200.

(1:12:06) We are making traffic analysis a lot harder for ISP-level attackers. By really increasing the chattiness of the network itself, we make it much harder for observers to associate or to collate individual observations into one payment. It is definitely not the perfect solution, to tell a wider part of the network about a payment being done, but it is an incremental step towards the ultimate goal of making basically every payment indistinguishable from each other, which we are getting with Schnorr and the Point Timelock Contracts.

Once we have the Point Timelock Contracts, we truly have a system where we are sending back-and-forth payments that are not collatable by payment hash, as you correctly pointed out. And not even by amount, because all of the payments have roughly the same amounts; it is the combination of multiple partial payments that gives you the actual transferred amount. It is not a clear loss or a clear win for privacy, that we’re now telling a larger part of the network. But I do think that the pre-splitter and the adaptive splitting, combined with PTLCs, will be an absolute win no matter where you look at it.

(Note: Pickhardt offered a counter-perspective on MPPs starting around 56:14 here.)

Check out Lightning Labs’ new newsletter to learn more about second-layer development and tools beyond privacy.

August 5th - PAYJOIN SUPPORT IN WASABI AND JOINMARKET

zkSNACKs released 1.1.12 of Wasabi Wallet. In the release notes organized by CTO Dávid Molnár, and the accompanying blog post by marketing strategist Riccardo Masutti, they note that a merchant-oriented implementation of PayJoin is now supported.

PayJoin is a collaborative transaction between the sender and the receiver of a payment, for example the merchant and the customer. The goal of the protocol is to break the common input ownership heuristic, while making it difficult to fingerprint that the transaction is in fact a CoinJoin. Further, it reduces the transaction fees paid by the merchant due to the consolidation of coins.

On August 20th, JoinMarket released 0.7.0, which also supports this type of PayJoin.

Otherwise known as pay-to-end-point (P2EP), this implementation – based on Nicolas Dorier’s BIP-78 – works with BTCPay Server, and should be compatible with future releases of Blockstream Green and Blue Wallet. Samourai and JoinMarket had previously implemented their own versions of peer-to-peer PayJoin, but limited to the pool of their own users; once they have added receiver support, JoinMarket intends to “deprecate and remove” the “pre-existing Joinmarket-Joinmarket payjoin function.” Regarding Samourai, there is ongoing discussion about how / whether to pursue compatibility.

August 8th - CROSS-CHAIN ATOMIC SWAPS WITH MONERO

Computer scientist and Monero researcher Joël ‘h4sh3d’ Gugger published a paper titled “Bitcoin-Monero Cross-chain Atomic Swap.” On July 31st, he had announced the completion of the research via Reddit. He had made a funding request for 18 XMR back in May through the Community Crowdfunding System (CCS), though he notes that he started researching “a Bitcoin/Monero atomic swap three and a half years ago.” Following review by the Monero Research Lab (MRL), the announcement was shared widely on August 3rd.

This protocol describes how to achieve atomic swaps between Bitcoin and Monero with two transactions per chain without trusting any central authority, servers, nor the other swap participant.

… Monero does not require any particular on-chain primitives (hashlocks, timelocks), all building blocks are off-chain primitives.. The Monero private spend key is split into two secret shares.. Participants will not use any multi-signature protocol; instead, the private spend key shares are distributed during initialization of the swap process where one participant will gain knowledge of the full key.. at the end of the protocol execution, either for a completed swap or for an aborted swap.

The paper remains purely technical, without making arguments about how swapping between Bitcoin and Monero benefits privacy. The introduction emphasizes that, being atomic, this will allow “two strangers to trade without risks nor the help of a third-party.” Unlike Zcash, Monero at least has an anonymity set to offer due to ring signatures being mandatory since 2017.

In the past, one of the most popular portals for swapping between these two cryptocurrencies was ShapeShift, the Denver-based crypto-to-crypto exchange. A Wall Street Journal investigation, which accused them of money laundering, noted that “in the case of Monero, recipient addresses and transaction amounts remain secret and the trail is severed.” Once ShapeShift decided to discard their account-less model and impose a requirement for mandatory membership in October 2018, following “direct or indirect threats from regulators,” trading volume in XMR/BTC reported shifted towards decentralised exchanges like Bisq.

On August 31st, Ciphertrace announced that they had “developed tools for the U.S. Department of Homeland Security (DHS) to track transactions of notoriously difficult-to-trace privacy coin Monero (XMR),” laying “the groundwork for future implementation of entity transactions clustering, wallet identification, exchange attribution, and other functionality.” As Riccardo Spagni and Matt Odell (49:49) later pointed out, this announcement may be based more on marketing than math.

August 9th - MALICIOUS TOR EXIT RELAYS

A security researcher and Tor server operator known as Nusenu published the first part of a report titled “How Malicious Tor Relays are Exploiting Users in 2020.” They claim to have “uncovered a malicious actor running more than 23% of the entire Tor network’s exit capacity,” and that the attacker specifically targeted “cryptocurrency related websites — namely multiple bitcoin mixer services.”

They replaced bitcoin addresses in HTTP traffic to redirect transactions to their wallets instead of the user provided bitcoin address. Bitcoin address rewriting attacks are not new, but the scale of their operations is.

They explain that the attacker engaged in selective SSL stripping, removing “HTTP-to-HTTPS redirects to gain full access to plain unencrypted HTTP traffic.” Websites that do not use “established countermeasures, namely HSTS Preloading and HTTPS Everywhere,” make this attack possible, and it is “not specific to Tor Browser. Malicious relays are just used to gain access to user traffic.” ZDNet noted that a similar attack using Tor-to-web proxies had been performed in 2018; computer scientist Neal Krawetz pointed to an earlier attack from 2014. Nusenu did not report which mixing services were targeted and how much, if any, bitcoin was successfully hijacked this way.

Fully Noded clarified that they were not affected, and Wasabi published a blog post in more detail about why “replacement attacks are not possible due to the architecture of Wasabi.” But these attacks do highlight the value of features like Onion-Location, helping users to stay within the Tor network, rather than relying on exit nodes to access clearnet content.

August 11th - DESIGN SKETCH FOR FIRST VERSION OF COINSWAP

After announcing a work-in-progress implementation of CoinSwap in May and receiving a grant in June, Chris Belcher emailed a more detailed design sketch to the Bitcoin-dev mailing list, including “multi-transaction Coinswap, routed Coinswap, fidelity bonds, a liquidity market and private key handover,” as well as potential attack vectors.

Belcher had been interviewed by Max for the Bit-Buy-Bit podcast, published on August 6th, and we also interviewed Belcher on August 10th. ‘ZmnSCPxj’ replied to the mailing list that the maker / taker relationship in CoinSwaps potentially “has a massive advantage over CoinJoin.”

In CoinJoin, since all participants sign a single transaction, every participant knows the total number of participants. Thus, in CoinJoin, it is fairly useless to have just one taker and one maker, the maker knows exactly which output belongs to the taker. Even if all communications were done via the single paying taker, the maker(s) are shown the final transaction and thus can easily know how many participants there are (by counting the number of equal-valued outputs).

With CoinSwap, in principle no maker has to know how many other makers are in the swap.

Nadav Kohen commented that some of the “complexity more or less goes away once we have Schnorr signatures and can use MuSig with adaptor signatures.” He wrote about how adaptor signatures work in “Schnorr Applications: Scriptless Scripts.”

August 12th - SCHNORR SIGNATURECHECKERS

Following last month’s meeting highlighted in TMIBP02, the Bitcoin Core PR Review Club held their fourth meeting, hosted by John Newberry, to discuss “support for Schnorr signatures and integration in SignatureCheckers.” You can read the meeting log here.

Check out Nadav Kohen’s “Introduction to Schnorr Signatures,” Lucas Nuzzi’s “Schnorr Signatures & The Inevitability of Privacy in Bitcoin,” Bitcoin Optech’s Schnorr Taproot Workshop and Newsletter #111 to learn more.

August 18th - DUST ATTACKS

CoinDesk journalist Colin Harper reported on an ongoing dust attack that started around August 4th, attributed to “an entity that appears to be advertising an obscure Bitcoin SV messaging application,” Memo SV. Days earlier, Samourai Wallet had dubbed this “the most organized dusting we have seen for some time.”

As explained elsewhere by Murch and Yahiheb, “The definition of dust is client-specific and not a network rule. Bitcoin Core considers a transaction output to be dust, when its value is lower than the cost of spending it.” While receiving a tiny amount of free money may sound harmless, dust can cause a variety of problems, even for custodial wallet users. Following the acquisition of Neutrino last year, some Coinbase customers who sought to leave the service encountered a Catch-22: closing your account requires having zero remaining balance, but if you had a “dust balance,” i.e. an amount too small to be withdrawn, you were stuck. These frustrated customers developed a work-around, passing along their dust balances to each other via Coinbase’s internal account system, until the amount was large enough to finally be withdrawn.

Dust also has privacy consequences. In March 2019, Ádám “Nopara” Ficsór noted that Wasabi wallet users were being dusted. In an attempt to make the dust economical, bitcoin users will often consolidate them together during low-fee periods, which can result in multiple addresses becoming linked to a common owner. “About half of them don’t mind joining together some of their dusts, exposing the links between their mixed outputs (not the mixes though).” During that week’s Tales from the Crypt Rabbit Hole Recap, he said he did not know what the attackers were trying to achieve, but the dust had been interfering with their ability to accurately measure the anonymity set. Since their 1.1.3 release, as a countermeasure, the wallet automatically hides / separates UTXOs which are less than or equal to 0.0001BTC from spendable coins.

Ergo, an analyst for Samourai’s “separate, yet complimentary” visualization and publication platform OXT Research, has been sharing data points on this latest ‘promotional dusting’ behaviour since August 11th. He claims to have “traced some 84,000 dust outputs from 146 transactions,” and thinks that raising the dust limit may act as “a deterrent.” Others have suggested revitalising coin management tools that can deal with these UTXOs in a privacy-preserving way, such as Peter Todd’s ‘Dust-B-Gone.’ Since November 2017, Samourai Wallet has had a “Dust Alerting” feature and allowed their users to label any UTXO as ‘Do Not Spend.’

And while there are currently no grounds to believe that the culprit behind this dust attack was either a malicious chain analytics company or exchange, Harper highlighted why such actors could be motivated to pull an attack like this.

CoinDesk reached out to Chainalysis and CipherTrace to ask if they use dust in their analytics. Both companies denied using this technique, though Chainalysis Manager of Investigation Justin Maile added that dusting is “more often [used] by investigators” to trace illicit funds. Maile continued that exchanges may use dusting to trace stolen funds following a hack.

Dave Jevans, the CEO of blockchain analytics company CipherTrace, told CoinDesk that “hackers may use dusting as a strategy for identifying individuals who can then be phished or extorted.”

August 19th - OXT RESEARCH VULNERABILITY DISCLOSURE

The research arm of Samourai Wallet announced that they had “discovered two potential privacy vulnerabilities” in Wasabi Wallet. A pastebin of the private disclosure was published later.

When a mixed output is remixed, these vulnerabilities break the ZeroLink guarantee for the previous mix, cancelling its benefits. These vulnerabilities break a core assumption of mixing, with each remix effectively canceling out the privacy gains of the previous mix.

The first alleged vulnerability related to a “lack of strong endogenous randomness” when the client or coordinator is selecting UTXOs for a mix, requiring the attacker to have “knowledge of events related to the mixing process and of the composition of the targeted wallet” in order to exploit it. The second alleged vulnerability related to “the existence of peel chains composed of toxic change outputs propagating across the mixes.” Toxic (or ‘doxxic’) change is any unmixed UTXO created and sent back to your wallet; if not segregated, they can potentially damage the privacy gains by creating deterministic links with postmix funds.

As a consequence, the anonymity set after remix becomes 50 instead of the expected and reported 99. “But 50 seems fine!” Privacy enhancing tools shouldn’t produce results that are a lottery. A good mixer should provide constant and predictable outcomes.

About 48 hours later as promised, they released a full disclosure report publicly. In the summary, they recommended that “the best solution is obviously to introduce consistent randomness into the coin selection process.” The researchers noted that “the Wasabi Wallet team did not accept the results in this disclosure.”

On August 21st, while not a direct response to the report, Ficsór answered some relevant questions. He argued that the “mathematical metrics” for calculating the anonymity sets “are terribly misleading the users” because they work “quite well for a single transaction” but not “multiple transactions.” He also advised that while Wasabi has labeling tools and separates new coins from postmix funds by default, they currently don’t have a “technical solution” for what users should do “with your ugly red coins” (unmixed UTXOs, including change). Samourai has previously written about how they measure anonymity during the Whirlpool mixing process, though they agree such numbers can be misunderstood and therefore deliberately do not display anonymity set metrics. Their wallet segregates toxic change into a so-called “bad bank.”

As I covered in TMIBP01, a new variable-amount CoinJoin protocol, dubbed “WabiSabi,” is being developed. Ficsór confirmed that when it is ready, “Wasabi Wallet’s CoinJoin algorithm will be replaced.” He later added that this “isn’t strictly news as I’ve [been] planning for and talking about it since 2018,” referencing a ZeroLink issue thread on extensions to Chaumian CoinJoin (CCJ).

On August 24th, Cointelegraph writer Adrian Żmudziński published comments from Ficsór and Mário Havel, co-founder of Paralelná Polis and “considered one of Slovakia’s experts in cryptocurrencies.” Havel believes that the vulnerability report is “technically correct but not so critical as initially presented,” and that they “affect only [the anonymity in] some CoinJoin scenarios in which the user is mixing more [unspent transaction outputs].”

“Doing privacy correctly, especially with tools like coin control requires some learning and attention. In this case, the user has to be aware of possible attack scenarios and avoid them by managing UTXOs correctly.”

“Personally, I use both wallets since both have different features and perks. […] Both are great wallets even without the CoinJoin feature and it is only up to the user how he uses it and what features of the wallet he needs.”

On August 28th, OXT Research published a follow-up post to address comments and criticisms of their report. They argue that it is “unreasonably optimistic” to assert that “the premix activity of a wallet” would be “beyond the reach of any adversary,” and “we do not believe relying on user induced randomness is a satisfactory solution.”

August 20th - DIRTCOIN DIARIES’ PAYNYM TORCH

The Bitcoin Enemies virtual meetup hosted their second session of ‘Dirtcoin Diaries’ group discussion, with a focus on PayNyms. In the four days leading up to the meeting, they had organised a PayNym torch with proceeds going to support development of RoninDojo.

PayNyms are an implementation of BIP-47, which specifies creating “a payment code which can be publicly advertised and associated with a real-life identity without creating the loss of security or privacy inherent to P2PKH address reuse.” Instead of publishing a single donation address that all donors send money to, you share a pseudonymous identity (representing the payment code) that can be used to generate a fresh address for each payment. Not only can this obscure your donation address to the public, as each donor will only know the particular receive address they’ve paid to, but it significantly reduces address reuse. Ravi Patel has written about how you can also avoid address reuse by setting up a donation page or store with BTCPay Server. At least one shop, MINE.FARM.BUY, uses both in their checkout.

During the meetup, they talked about why BIP-47 hasn’t been more widely adopted yet, how complex it is under the surface, and strategies for using coins received through PayNyms. Samourai Wallet reported that 82,800 PayNyms have been registered so far in their directory.

The idea for a PayNym torch originated in issues with last year’s Lightning Torch event, a fun way to test channel capacity across the Lightning Network. While this transaction relay was being described as “a worldwide marathon,” American participants were shy about passing the torch to those living in parts of the world under U.S. sanctions. On February 26th 2019, OXT developer and researcher Laurent initiated a PayNym torch with Iranian bitcoiner Ziya Sadr. Similar to the Lightning torch, whoever received the PayNym torch would add a small amount, 0.001 BTC, and then pass it on to another PayNym of their choice.

August 21st - THE SOLUTION TO SIM SWAPPING?

Chainalysis’ public sector outreach and sales engineer Scott Johnston published an article to the blog of UK Finance, a three-year-old trade association representing the UK financial services sector. The piece, aimed at “compliance professionals and financial investigators,” is titled “How to fight back against SIM swapping with blockchain analysis.”

In cases involving stolen cryptocurrency, they can use blockchain analysis to trace stolen funds to a cryptocurrency service they can subpoena for information on the attacker. An example of this is on our blog, from a recent SIM swapping attack we investigated in which the victim had roughly $25,000 worth of cryptocurrency stolen. The attacker moves the funds through several intermediary wallets before depositing them across several different cryptocurrency services including exchanges, merchant services providers and darknet markets.

If the problem of SIM swapping was a weed, then applying blockchain analysis would be like trimming some leaves: this does nothing to address any of the root causes. Low-paid mobile service provider employees and contractors who are easy to socially engineer. Fundamental weaknesses in mobile network security. Widespread misuse of phone numbers as identifiers, when the user doesn’t actually control them. Data brokers having easy access to personally identifying mobile subscription and GPS data that is abused for everything from tax investigations to stalking to extra-judicial drone strikes.

It is concerning that people with potential influence in the UK government and banking sector would be giving out advice that more financial surveillance and control is the solution to this problem. But it would also be unsurprisng given their trajectory over recent years, handicapping individual privacy and safety in favour of a surveillance state that has repeatedly failed to deliver on its promises of so-called national security.

If you have been a victim of SIM swapping or worry about becoming one, I recommend reading the EFF’s article on “The Problem with Mobile Phones,” Kraken’s “Security Advisory: Mobile Phones,” and Jameson Lopp’s “A Modest Privacy Protection Proposal.”

August 27th - WHAT IS AN XPUB?

Cryptography is not a magic spell that solves all security problems. Cryptography can provide solutions to cleanly defined problems that often abstract away important but messy real-world concerns. Cryptography can give guarantees about what happens in the presence of certain well-defined classes of attacks. These guarantees may not apply if real-world attackers “don’t follow the rules” of a cryptographic security model.

— “The Joy of Cryptography” by Mike Rosulek

Public key cryptography has been around since the 1970s and functioned on a few simple premises: the public key encrypts, the private key decrypts; share the public key, hide the private key; the public key can be derived from the private key, but the private key cannot be derived from the public key. As many people may have realised for the first time in the past week, the picture is a bit more complicated in Bitcoin.

BIP-32 introduced hierarchical deterministic wallets using a tree of extended key pairs. These wallets were much easier to use because you don’t have to update your wallet backup every time a new address is generated. In BIP-39 compliant wallets, the master key pair is generated from your mnemonic seed words. The master extended public key (xPub) can be used to derive all “descendant” public keys, often referred to as child and grand-child keys. (Note: If you are using BIP-49 wrapped or BIP-84 native SegWit, then technically these are the yPub and zPub.) Addresses are then derived from these public keys, and these addresses are what you actually send bitcoin to.

Because of this construction, knowing an extended private key allows reconstruction of all descendant private keys and public keys, and knowing an extended public key allows reconstruction of all descendant non-hardened public keys.

In simple terms, while anyone who has access to your xPub alone cannot spend your bitcoin funds, they can see all addresses derived from it, all the coins you control at those addresses, and any transaction history. This is why the label “public key” can be a little misleading, as this information should not be shared with untrusted parties if you care about financial privacy. As Belcher has suggested, from a UX perspective, it may be helpful to refer to the xPub as a “view key,” similar (though not technically equivalent) to how Zcash viewing keys are explicitly designed to expose transaction details that are otherwise obscured.

If you use a light wallet and aren’t connecting to your own node, you may have shared your x/y/zPub with the wallet service operators. This presents a serious privacy trade-off, though this design decision is not necessarily malicious. In order to display your balance, your wallet needs to query a blockchain explorer to count the coins it holds, and having the xPub is a very convenient way to find out which addresses have been used.

Of course, that can be done without the xPub. For example, in their support documentation, Ledger asserts that “Ledger Live stores the xpub locally on your computer when you add the account. Your xpub is never sent to Ledger’s servers. It is encrypted by your Ledger Live password if you have set one.” In practice, this method offers some protection compared to services that do access xPubs: if a Ledger user were to switch to using their own node instead, Ledger the company would only be aware of the relationship between addresses that the user queried the balance for prior to migrating to their own node. They could not associate them with newly generated addresses going into the future (assuming the user can avoid linking them through spending patterns).

Some attempts have been made to preserve the privacy of light wallet users’ address ownership, using filters that don’t explicitly tell the provider or peer nodes which addresses belong to them. Requests using BIP-37 bloom filters will contain false positives, “meaning the remote peer cannot accurately know which transactions belong to the client and which don’t.” However, it was soon found that this ambiguity breaks down after multiple filters. BIP-157 / 158 “Neutrino” client-side filtering, still in the draft stage, aims to rectify this by having “full nodes generate deterministic filters on block data that are served to the client. A light client can then download an entire block if the filter matches the data it is watching for.”

Finally, client privacy is improved because blocks can be downloaded from any source, so that no one peer gets complete information on the data required by a client. Extremely privacy conscious light clients may opt to anonymously fetch blocks using advanced techniques such a Private Information Retrieval.⁶

We had interviewed Ficsór, Dorier, and Pierre Rochard about their views on Neutrino filters back in March 2019. Ficsór then wrote about how Wasabi, “a BIP157-ish client side filtering light wallet,” handles ‘Network Level Privacy.’

The vision of a light wallet that does not leak too much information while establishing the user’s UTXO set had haunted Bitcoin developers for centuries.

August 28th - DEBATING BLOCKCHAIN ANALYSIS

The Blockchain Debate Podcast hosted by Richard Yan held a debate between Alex Gladstein and Dave Jevans, founder and CEO of Ciphertrace. Similar to Gladstein’s debate with Elliptic’s Tom Robinson featured in TMIBP01, the motion was: “Blockchain analysis companies are bad for bitcoin.” Needless to say, Gladstein agreed with the motion, while Jevans disagreed. Describing himself as an ex-cypherpunk, he had published “On Cryptocurrency Tracing Companies and Privacy on the Blockchain” in May, arguing that “CipherTrace has always been an advocate of user privacy” and such companies are not “violating human rights.”

In his opening statement, Gladstein cited an article from The Atlantic titled “The Panopticon Is Already Here,” about the role of artificial intelligence in China’s endeavor to “build an all-seeing digital system of social control, patrolled by precog algorithms that identify potential dissenters in real time,” systems that are gaining favour with other states around the world. “Whether or not Dave’s company would work with those governments, I’m sure his competitors will.”

In Jevan’s opening statement, he argued that if these financial surveillance tools were not available, “within six to eight months, at least thirty countries would ban cryptocurrencies,” echoing Robinson’s sentiment. He still disagreed with the allegation that they collect personally identifiable information or deanonymize “individual identities,” and framed their work as similar to ‘reporting that someone made a purchase at Target,’ rather than ‘identifying who made the purchase and what items were purchased.’

Gladstein countered that even if Ciphertrace or someone like them wasn’t collecting that information, they would still be a vital cog in the machine of multiple actors who are trying to do so. Given that Jevans claimed to merely identify businesses and exchange entities (particularly VASPs), he asked whether Ciphertrace’s tools were effective against peer-to-peer activity. “I wouldn’t say it’s useless, but we certainly don’t focus on it,” Jevans responded.

Jevans attempted to downplay the significance of their actions in a “realistic” world where “financial investigation and tracking is not new.” He had made the decision many years ago to act as “a bridge between the crypto community” and the compliance industry surrounding traditional finance. When Gladstein suggested a third option – dedicating their resources and knowledge to support privacy-enchancing technology – Jevans noted that his business worked “almost every week” with teams at Zcash and Monero. Ciphertrace and Zcash are both members of the Blockchain Alliance coalition. What this collaboration entailed, he did not say.

Gladstein plugged Belcher’s work on CoinSwap, Liquid’s testing of confidential transactions, the Lightning Network, and the Schnorr / Taproot upgrade as ongoing efforts to render blockchain surveillance ineffective. Jevans did not comment on whether these techniques would hinder their work, but rather took credit for incentivising the development and adoption of privacy technology. He later asserted that it should be assumed just “putting your stuff on the internet” would be accompanied by mass surveillance. They concluded the debate by discussing FATF’s Travel Rule and what distinguished Ciphertrace from other blockchain surveillance companies.

We don’t need compliance. We don’t need blockchain analytics companies. They are tools of those in power. Bitcoin exists as a tool for the powerless. Blockchain analytics companies, or as I like to call them ‘financial surveillance’ companies, are bad for Bitcoin.

Thanks for reading! Feel free to bookmark or subscribe to catch the next edition of ‘This Month in Bitcoin Privacy.’

That One Privacy Girl