June 2021

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

"[2033] Black Arches (Lymantria monacha)" by Bennyboymothman is licensed under CC BY 2.0

Table of Contents

1. Bitcoin Design Guide
2. Removing Tor V2 Support
3. Chaincase PayJoin Demo
4. Improving Off-Chain Protocol Privacy
5. Taproot Locked In
6. Privacy Features in Trezor Suite
7. Ledger Data Dump Update
8. Coverting CoinJoined Coins to Cash
9. FATF Delays Finalising Guidance

June 2nd - BITCOIN DESIGN GUIDE

After a year of research and open collaboration, the first version of the Bitcoin Design Guide has been publicly released. As a “free and open-source, community-made handbook,” it compiles resources on “everything from Bitcoin basics to user onboarding, private key management, and designing transaction flows.” For example, I became aware of this effort through our Wallets Recovery project, which is referenced in the section on wallet interoperability.

So is the Bitcoin Design Guide done? Not at all. Since Bitcoin is always evolving, so will the guide. To keep the guide, ourselves, and the greater bitcoin design community up to speed, we’re always looking for additional feedback and contributors. The more people who chip in, the more people the guide can help. Join us in the Bitcoin Design community Slack to get in touch.

I had highlighted the privacy-related contributions in TMIBP07. In the chapter on ‘Payments and transactions,’ they explore aspects and best-practices of transaction privacy in Bitcoin, including CoinJoin and avoiding address reuse. They urge readers to ‘design with privacy in mind’ by “prevent[ing] user actions that negatively impact their privacy as they use your product.”

June 3rd - REMOVING TOR V2 SUPPORT

In TMIBP05, TMIBP07, and TMIBP08, I have been following Tor’s v3 onion service upgrade and its effect on Bitcoin. On June 3rd, Wladimir van der Laan merged the pull-request from Jon Atack (who later received a $100,000 grant from Strike), removing support for v2, ahead of the Tor Project’s scheduled deprecation next month. The latest Tor browser release announcement warns to “migrate your services and update your bookmarks to version 3 onion services as soon as possible.” After the merge, Pieter Wuille tweeted out that “for the next major release we’re dropping V2 support,” and the Tor Project amplified this.

This patch removes support in Bitcoin Core for Tor v2 onions, which are already removed from the release of Tor 0.4.6.

• no longer serialize/deserialize and relay Tor v2 addresses
• ignore incoming Tor v2 addresses
• remove Tor v2 addresses from the addrman and peers.dat on node launch
• update generate-seeds.py to ignore Tor v2 addresses
• remove Tor v2 hard-coded seeds

On June 28th, Bisq finished v1.7.0 which included a merged pull-request to prompt users to upgrade to Tor v3 addresses and announced that they would set this release as the “required minimum version for trading” in one week. It also fixed “a privacy issue” that would be disclosed.

June 6th - CHAINCASE PAYJOIN DEMO

In TMIBP11 and TMIBP12, I featured progress with Chaincase, an iOS client based on Wasabi. Following the Bitcoin 2021 Conference in Miami, Florida, some plebs organised “a day of hacking, mentorship, workshops, and discussions on how to contribute to bitcoin functionality accelerationism and build decentralized finance applications on bitcoin.” Dan Gould gave a presentation, “Hiding your Naughty Bits: A Mobile PayJoin Demo,” on the PayJoin feature of this relatively new privacy-focused wallet and how it breaks the common-input-ownership heuristic. The demo transaction merging coins from ‘Alice’ and ‘Bob’ is interpreted by Blockstream.info’s analysis as “possibly self-transfer,” meaning that they are not able to conclusively tell whether the UTXOs come from the same person or separate entities based on the structure of the transaction. A recording was published later.

Right now, we are really interested in the non-code contributions from users who outline why the app’s not stable for them, if it’s not stable for them. Those go so far. I’d really love to thank all of our users who have had the patience to adopt the app early, to get in the t.me/chaincase Telegram channel, giving feedback. It’s just been totally fabulous.

Then in the code / development department, we’ve been fortunate to work with the design community. I want to give a shout-out to Johns Beharry, Ed Pratt, Stephen DeLorme, and everyone else who has contributed to fixing the problems with Bitcoin privacy. Those contributions, I don’t know that that will necessarily end. Privacy software is never finished. Those contributions in coin selection, CoinJoin, and general guidance, helping users make decisions… We’re looking for those to continue.

Gould was also interviewed by Max Hillebrand for episode #19 of “Join the Wasabikas” to talk about his background with Tumblebit and HiddenWallet, the user experience of Chaincase, running Tor on iOS, and how to make privacy features more accessible.

I previously covered PayJoin development in TMIBP03, TMIBP05, TMIBP06, and TMIBP08.

June 10th - IMPROVING OFF-CHAIN PROTOCOL PRIVACY

JoinMarket, Electrum Personal Server, and CoinSwap developer Chris Belcher published the draft of a new Bitcoin Improvement Proposal (BIP) to the mailing list: “Anti-fee-sniping protection with nSequence in taproot transactions to improve privacy for off-chain protocols.” He writes that it “proposes a certain type of wallet behaviour” with Taproot that will provide “a greater anonymity set for off-chain protocols which will make use of point-time-locked contracts (PTLCs) such as CoinSwap, Lightning and Discrete Log Contracts.” I have covered development and analysis of these protocols from a privacy perspective previously in TMIBP01, TMIBP03, TMIBP06, TMIBP07, TMIBP09, and others.

This BIP proposes to improve the privacy and fungibility of off-chain protocols by having on-chain wallets like Bitcoin Core also set the nSequence field in their taproot transactions as in BIP68. This would be in place of their regular nLockTime anti-fee-sniping protection. The end result is that, if an observer of the blockchain sees a taproot spend with an nSequence value, then that could be either: a regular spend from a wallet, or an off-chain settlement transaction spent with a timelock.

For more on this draft, see summaries and commentary in Bitcoin Optech Newsletter #153 and Block Digest #272.

June 12th - TAPROOT LOCKED IN

Last month’s TMIBP12 covered Taproot reaching the signalling threshold for lock-in, which was solidified by June 12th and kept the soft fork on schedule for November activation.

If miners would signal support for the upgrade in 90% of all blocks within a single two-week difficulty period (1,815 or more blocks out of 2,016), Taproot would activate on block 709,632, estimated to be mined this November.

In celebration, Pieter Wuille shared the whole timeline of Taproot development:

It’s been a long story, that started in a diner in Los Altos, CA where in Greg Maxwell, Andrew Poelstra and I somewhere in January 2018 had lunch. While I briefly had to leave the table, they had come up with a really cool idea to hide Merkle roots in P2PK-like outputs.

A few months later, a few people including me started writing a specification to focus on this idea as an upgrade to Bitcoin’s script capabilities. There were so many ideas, but we couldn’t realistically include everything in one proposal. At the time there were so many ideas even for “structural” Script improvements (not counting ideas for new opcodes); there was cross-input signature aggregation, graftroot, g’root, of course Taproot itself, …

Initially my hope was to create one proposal that did all of them. But given how fast ideas were evolving, it seemed better to focus on a subset (primarily things usable without interactive setup) + bugfixes + upgrade mechanisms.

In May 2019, @ajtowns, @n1ckler, @real_or_random, and I published the first drafts of these BIPs. The following months several improvements were made in response to feedback; x-only pubkeys were introduced, the quadratic residuosity tiebreaker was removed, and the sighashing scheme was improved to include all scriptPubKeys being spent. At the end of 2019, structured review sessions were organized by @bitcoinoptech and @ajtowns, which brought in many eyes (though the number seemed to shrink a bit over time…) and questions, but mostly, I think it helped bring exposure to the ideas in it.

August 2020 would mark the last semantic change to the proposal, reverting the quadratic residue tiebreaker after realizing it wasn’t actually helping performance, and making matters more complicated. A few months later in October the proposal was considered mature and accepted enough to be merged into the Bitcoin Core codebase - without activation - ready to be include in the 0.21.0 release. This allowed testing on testnet without affecting mainnet.

… Thanks to everyone who has helped us get this far - contributors to the BIPs, to the reference code, reviewers of those[.] But this is also just the beginning. The real work will be in the ecosystem of wallets and other applications adopting changes to make use of Taproot.

On June 30th, BTCPayServer founder Nicolas Dorier published a video about “the concept of Musig2, which is a feature made possible by Taproot and is designed to make multi-signature Bitcoin transactions less complex without sacrificing privacy.” I have previously covered MuSig in TMIBP04, TMIBP05, TMIBP06, and TMIBP11.

Murch and Aaron van Wirdum have both tweeted long informational threads on Taproot.

Check out Matt Corallo and Wirdum’s recent talk “How To Activate Taproot And Future Soft Forks,” Bitcoin Optech Newsletter #153 and #154 for a new “weekly series about how developers and service providers can prepare for the upcoming activation of taproot,” and other recent technical developments beyond Bitcoin privacy.

June 16th - PRIVACY FEATURES IN TREZOR SUITE

In TMIBP11, I included the roadmap plans of Trezor to introduce coin control and CoinJoin. This month they wrote about these and other privacy features for the new Suite interface, including Tor Switch for network traffic protection (highlighted in TMIBP12), locktime, and ‘Discreet mode’ that “blurs out all sensitive data, only revealing it on mouse-over.”

Privacy is often a secondary focus for those building on Bitcoin. Ensuring there is robust infrastructure in place for Bitcoin is a priority; confidentiality at the expense of sound money would be a mistake. Instead, greater anonymity is achieved through separate tools that obscure interactions with the base layer.

June 17th - LEDGER DATA DUMP UPDATE

In TMIBP02, TMIBP07, and TMIBP08, I covered last year’s data breach of customer information from e-commerce and marketing database(s) used by hardware wallet company Ledger. Over one million email addresses and 272,853 shipping orders were dumped on RaidForums, and there were further leaks via Shopify discovered this year.

Following a report by Lawrence Abrams in Bleeping Computer, they updated their ‘Ongoing phishing campaign’ page to include a warning about a fake Ledger Nano X being mailed to victims of the breach, accompanied by photos of the packaging, device, and enclosed letter:

The fake device comes in authentic-looking packaging with the Ledger logo. The package includes a fake letter and a tampered Ledger hardware wallet. It is shrink-wrapped as if the box has never been opened. The fake letter explains that you need to replace your existing hardware wallet to secure your funds.

This is a scam. The Ledger Nano is fake. A flash drive implant has been connected to the printed circuit board. It contains a file with a fake Ledger Live app. There are enclosed instructions in the Nano box which ask the user to connect the device to their computer, open a drive and run the fake Ledger Live app. To initialize the device, the user is asked to enter his 24 words in the fake Ledger Live app. This is a scam. A Ledger Nano is not a USB device. It does not contain any application to download and install on your computer. The only way to download the Ledger Live app is by using the official download page. Plus, Ledger and Ledger Live will never ask you to share your 24-word recovery phrase.

If you were impacted by this breach, I recommend Kraken’s “Security Advisory: Mobile Phones,” Jameson Lopp’s “A Home Defense Primer,” “A Modest Privacy Protection Proposal,” and Michael Bazzell’s “Privacy, Security, & OSINT Show.”

June 24th - CONVERTING COINJOINED COINS TO CASH

Wage in bitcoin, not war. In TMIBP05, TMIBP08, and TMIBP12, I have included topics and events affecting the future of fiat cash as well as digital cash. Since crypto-to-fiat transfers often come with privacy pitfalls, many people are curious about the safest and most effective ways to do so, when necessary. J. Daniel Beluska from Wasabi Wallet, managed by a company that itself has their contributors “100% paid in Bitcoin,” wrote a simple guide to “compare and contrast all the various ways to convert your CoinJoined coins to fiat cash.” He does not provide specific examples or recommendations; if you are seeking some pointers there, check out Bitcoin Q+A’s articles on Bisq and Hodl Hodl.

June 25th - FATF DELAYS FINALISING GUIDANCE

In TMIBP10 and TMIBP11, I covered the Financial Action Task Force (FATF)’s public consultation regarding their guidance on “the risk-based approach to virtual assets (VAs) and virtual asset service providers (VASPs).” The consultation closed in April, and this month “delegates representing the 205 members of the Global Network and observer organisations, such as the IMF, the United Nations and the World Bank met virtually” for the fourth plenary.

The Plenary finalised a second 12-month review of the implementation of FATF’s revised Standards on virtual assets and VASPs. The report finds that many jurisdictions have continued to make progress in implementing these revisions, finalised in 2019. So far, 58 out of 128 reporting jurisdictions advised that they have now implemented the revised FATF Standards, with 52 of these regulating VASPs and six of these prohibiting the operation of VASPs. The private sector have made progress in developing technological solutions to enable the implementation of the ‘travel rule’. However, the majority of jurisdictions have not yet implemented the FATFs requirements, including the “travel rule”. This disincentivises further investment in the necessary technology solutions and compliance infrastructure. These gaps in implementation also mean that we do not yet have global safeguards to prevent the misuse of VASPs for money laundering or terrorist financing. The lack of regulation or implementation of regulation in jurisdictions can enable continued misuse of virtual assets through jurisdictional arbitrage.

“The report will be published on 5 July” and the guidance would be finalised “in October 2021.” Note: Since I happened to finish the newsletter late on this date, here is them sharing the report! Relevant bits in the next issue.

The day prior, Coin Desk reporter Ian Allison had noted that according to ‘regulatory insiders,’ there was “such an enthusiastic response from the industry that some are predicting the FATF will likely kick the can down the road to its next plenary meeting in four months’ time,” particularly as a result of their attempt to try “to catch everything in DeFi” and (according to the plenary summary) only “58 out of 128 reporting jurisdictions” implementing their revised standards. Lawyer Jake Chervinsky shared the news and said, “Thanks to everyone who wrote comments. This is a good start!”

Meanwhile, Allison also reported that members of the U.S Travel Rule Working Group (USTRWG), specifically engineers from “BitGo, Coinbase, Gemini, Kraken, and Fidelity,” had completed a demonstration of version 1.0 of their Travel Rule solution, using “dummy PII, just to test that the plumbing works.” They intend to “begin sending transactions accompanied by real customer PII by the end of Q4.” I have followed FATF’s ‘travel rule’ and related policy developments in TMIBP02, TMIBP05, TMIBP06, and TMIBP07.

For more on this topic, see this guest-post by ‘pretyflaco’ on “Regulatory attention on Bitcoin & privacy techniques to counter,” published at the end of last month by Fulmo.

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