Welcome to the tenth issue of ‘This Month in Bitcoin Privacy’ newsletter. Enjoy!
Table of Contents
- Disjointed: Services Flagging Mixed Coins
- Recurring Taproot Meetings
- JoinMarket Privacy Bugfix
- Quick and Discreet: Lightning and DLCs
- Signal Accepts Bitcoin Donations
- FATF Public Consultation on Virtual Assets
- Electrum Supports Trampoline Routing
Note: Due to my busy schedule, this month’s issue of the newsletter has fewer stories and will be more concise than usual.
March 1st - DISJOINTED: SERVICES FLAGGING MIXED COINS
Bottlepay user ‘MartyB’ self-reported that they had “rejected my incoming btc transactions” based on analysis that they had been mixed through Whirlpool. “If you have been sent mixed coins you will get stung.” The message screenshot captured the service claiming they “unfortunately are unable to accept them due to the high percentage of the transactions having been through services used for coin mixing.” Samourai Wallet stated that “we have currently been unable to verify this report but are working hard to do so,” and recommended using their Ricochet feature. “We will use the information to design tools to route around their heuristics. We can move faster than they can if you communicate with us.”
Bottlepay recently relaunched after raising £11 million in seed funding from “British fund manager Alan Howard, present and former Goldman Sachs partners, venture capital firm FinTech Collective, and financial services firm NYDIG and tech entrepreneur Phil Doye.” A few days later, they tweeted:
What did we miss?
Bottlepay is a regulated business, focused on taking #bitcoin powered payments mainstream.
We’re operating within the framework as it currently stands, whilst constantly trying to bring positive change to it.
However, as lawyer Rafael Yakobi reminded BlockFi last year, “You’re following regulations that don’t exist. Coinjoin is not illegal, nor is it suspicious without more evidence of the same.”
On March 4th, researcher ‘6102’ reported that Bitstamp Europe was “flagging coinjoins made with wasabi months/years AFTER withdrawal,” and encouraged others to notify if they had a similar experience. On March 23rd, Kristaps Kaupe self-reported that BitMEX had emailed about a “deposit transaction (last summer) that ‘may be connected with activity that is against 1.1(a) of the HDR Terms of Service.’, it was @joinmarket coinjoin.” On March 26th, Wasabi marketing strategist Riccardo Masutti self-reported that Bitwala “sent me an email 3 days ago about a couple of post-CoinJoin transactions that happened almost 6 MONTHS AGO.”
“These exchanges and services off-load their liability, oftentimes, to these chain surveillance companies. The chain surveillance companies give them risk scores. We know that some of the companies simply flag it as ‘CoinJoin has happened’ and ‘this is a risky behaviour.’ They are kind of admitting that they can’t tell the difference between the overwhelmingly legitimate, law-abiding use of CoinJoin, and the illicit use, because it actually works! Instead of determining ‘this is illicit’ and ‘this isn’t illicit,’ they respond by just trying to label it all as ‘risky.’ It shows how much improvement we’ve had in terms of Bitcoin privacy tools over the last two years.”
Matt Odell, an advisor to Bottlepay, discussed this on Tales from the Crypt Rabbit Hole Recap (44:14 – 1:08:23). He said a statement was forthcoming and that action was taken due to their interpretation of the 5th Anti-Money Laundering Directive (AMLD5). In TMIBP01, I included a determination by Europol’s European Cybercrime Centre (EC3) that AMLD5 “does not apply” to non-custodial wallets like Wasabi, and in TMIBP06, I covered reluctant compliance among custodial European services.
March 2nd - RECURRING TAPROOT MEETINGS
This month featured three Schnorr / Taproot activation-focused meetings via public IRC on March 2nd, 16th, and 23rd. Russell O’Connor proposed a “speedy trial” modified method which will “attempt to either quickly succeed or quickly fail – without compromising safety in either case.” There was “broad agreement” during the third meeting that the client be released by mid-May, and activation should occur around block height #707616 / November 15th.
It’s not going to materially change the user experience of any Bitcoin soft fork, but it can slightly improve privacy, both on the blockchain by having that, you don’t have to reveal all of the details about [whether] you’re using some kind of complicated multisig policy or something really fancy… in every case. So your transactions will look more normal, like everyone else’s transactions. Schnorr signatures can be used to improve privacy on the Lightning Network.
Check out The Van Wirdum Sjorsnado #29 and #31; Bitcoin Optech Newsletter #138, #139, #141, and #142; the Schnorr Taproot Workshop; and Aaron van Wirdum’s article for summaries and other developments.
March 9th - JOINMARKET PRIVACY BUGFIX
Adam Gibson published v0.8.2 with “an urgent privacy bugfix” to “stop takers from sending info revealing transaction inputs to makers.” He explained in the release notes that this was an unintentional “privacy failure w.r.t makers, but not a coin loss risk,” “did not give away the output address of the taker,” and “did not publish privacy-losing information on the blockchain, i.e. not to the public, but specifically to the makers in that transaction (in their log files).” On March 10th, Openoms also updated JoinInbox to v0.3.0 with this fix.
March 13th - QUICK AND DISCREET: LIGHTNING AND DLCS
In TMIBP09, I highlighted the launch of a new podcast, hosted by Max Hillebrand, titled “Join the Wasabikas.” This month, two episodes focused on the privacy of Bitcoin ‘smart’ contracts and the Lightning Network with Chris Stewart, Nadav Kohen, and István András Seres. I have previously covered research on this topic in TMIBP01, TMIBP02, TMIBP03, TMIBP04, TMIBP05, TMIBP07, and TMIBP08.
One of the reasons I personally really like Lightning and feel responsible for it, is that there are so many misconceptions about the privacy guarantees of Lightning. Maybe a podcast is a good place for a general audience, not just academic people, to get more knowledgeable [on] these trade-offs.
March 15th - SIGNAL ACCEPTS BITCOIN DONATIONS
The Signal Technology Foundation, which funds development of the popular encrypted messaging app, announced that they could now accept tax deductible cryptocurrency donations, processed through The Giving Block, which aids other non-profits as well. Donors can identify themselves for a tax receipt, or do so anonymously.
As a nonprofit organization, we depend on your support. If you’ve been patiently waiting for Signal to accept cryptocurrency donations, you no longer need to hodl back your generosity.
Later in the month, while the Human Rights Foundation (HRF) has already been accepting and gifting bitcoin for a while, Gladstein announced that donors could also use their new PayNym. I have previously covered PayNyms in TMIBP03, TMIBP06, and TMIBP09, as well as HRF’s bitcoin grants in TMIBP01 and TMIBP03. This month, I was myself a grateful recipient!
March 19th - FATF PUBLIC CONSULTATION ON VIRTUAL ASSETS
The Financial Action Task Force (FATF) opened a public consultation until April 20th regarding “updating its Guidance on the risk-based approach to virtual assets (VAs) and virtual asset service providers (VASPs).” The previous version of the guidance was published in June 2019, and a new draft has been released for review.
While these so-called recommendations are non-binding, if a member nation was to refuse to implement them, severe diplomatic and financial consequences could result.
The recommendations include trying to “limit jurisdiction’s exposure to P2P transactions” by “denying licensing of VASPs if they allow transactions to/from non-obliged entities (i.e., private / unhosted wallets) (e.g., oblige VASPs via the ‘travel rule’ to accept transactions only from/to other VASPs).”
A number of jurisdictions are using, or exploring using, blockchain analytics services to assist with their supervision. The services can be used in a number of ways, including to pinpoint areas that supervisors may wish to focus on during assessments of individual firms and helping to categorise the highest risk firms based on their activity. There is a cost consideration with these tools and not all VAs are covered by all vendors. Blockchain analytics are also widely used by VASPs and some FIs to monitor their own exposure to risk (e.g., VA transfers that have passed through mixer services). It is important to consider any potential implications for privacy and data protection in the use of such tools, if they allow transparency that is not otherwise available (e.g., on public blockchains).
Coin Center’s Peter van Valkenburgh – who also filed additional comments to FinCEN’s proposed rulemaking the week before – summarised the problematic aspects of the draft, such as the “expanded definition of VASPs (the persons and businesses obligated to register and conduct AML surveillance) that could include non-custodial participants in cryptocurrency networks, such as multi-sig minority keyholders and various participants in smart contract and ‘layer two’ mechanisms.” Human Rights Foundation (HRF) director Alex Gladstein asked, “Why do you let brutal dictatorships like China, the GCC, Saudi Arabia, Russia, and Turkey sit as members of the FATF and help drag the world towards totalitarian financial surveillance?”
On March 25th, in a guest post for CoinDesk, former FATF executive secretary Rick McDonell threatened that VASPs “need to comply in full force and spirit with global anti-money laundering and counter-terrorism financing conventions or risk being sanctioned or shut out by regulators or criminally pursued by law enforcement.” He is the executive director of the Association of Certified Anti-Money Laundering Specialists (ACAMS), which hosted FinCEN director Kenneth Blanco, making similar comments, in September 2020 (see TMIBP05).
I previously covered the FATF’s report on ‘red flag indicators’ for virtual assets in TMIBP04, and the working group of VASPs (USTRWG) creating a customer data sharing platform to comply with the Travel Rule in TMIBP02 and TMIBP05.
March 30th - ELECTRUM SUPPORTS TRAMPOLINE ROUTING
As part of their “second major release with support for the Lightning Network,” Electrum published v4.1.0 to enable legacy and end-to-end trampoline payments. Trampoline routing was originally proposed by ACINQ co-founder Pierre-Marie Padio and Blockstream engineer Christian Decker. In August 2019, Bastien Teinturier submitted a draft specification, which was superceded (as summarised in Bitcoin Optech Newsletter #130) in December 2020 “based on what we learnt after 1 year running trampoline in production in Phoenix and many discussions with @ecdsa while Electrum worked on their own trampoline implementation.”
This proposal allows nodes running on constrained devices to sync only a small portion of the network and leverage trampoline nodes to calculate the missing parts of the payment route while providing the same privacy as fully source-routed payments.
As explained in the release notes:
There are two types of trampoline payments: legacy and trampoline end-to-end. Legacy payments are possible with any receiver, but they offer less privacy than end-to-end trampoline payments. Electrum decides whether to perform legacy or end-to-end based on the features in the invoice:
- OPTION_TRAMPOLINE_ROUTING_OPT (bit 25) for Electrum
- OPTION_TRAMPOLINE_ROUTING_OPT_ECLAIR (bit 51) for Eclair/Phoenix
When performing a legacy payment, Electrum will add a second trampoline node to the route in order to protect the privacy of the payer and payee. It will fall back to a single trampoline if the two-trampoline strategy has failed for all trampolines. (Note: two-trampoline payments are currently not possible if the first trampoline is the ACINQ node, and is disabled for that node.)