Yuval Kogman nothingmuch

This subject of this is about the possibility of active tagging deanonymization attacks by a malicious coordinator, so I will address the claims pertaining to that first, and the rest of the claims in order of relevance.

There's also an important correction, due to Sjors: I overlooked a relevant detail of BIP 341 and misremembered the related behavior when I did consider it. The implication is that transactions that spend at least one P2TR input partially mitigates the simplest form of this attack, but as detailed below it's not a sufficient mitigation.

The Wasabi and Ginger Bitcoin wallets, which implement the WabiSabi protocol, are vulnerable to tagging attacks due to lack of inadequate checks of ownership proofs.

In the protocol clients register their Bitcoin UTXOs independently. A valid input registration request includes a BIP-322 ownership proof, which commits to the so called Round ID. This in turn is a hash commitment to the parameters of the round, including the server's anonymous credential issuance parameters (analogous to a public key).

The parameters are obtained by polling the server for information about active rounds. If inconsistent round IDs are given to clients, this effectively partitions them, allowing deanonymization.

Although clients obtain the ownership proofs of other clients and seemingly verify them, BIP-322 proofs verification requires knowledge of the spent outputs scriptPubKey which light clients cannot obtain on their own. This public key is included alongside the ownership proofs, which makes their verification non-bind

The Samourai Bitcoin wallet, which implements the whirlpool variant of the zerolink protocol, is vulnerable to key tagging attacks due to the absence of any key consistency checks, completely defeating the privacy claims of the protocol.

In Whirlpool CoinJoin transactions, clients utilize a variant of ZeroLink nominate Bitcoin UTXOs as inputs into a collaborative transaction that allows them to send a fixed amount back to themselves anonymously, somewhat analogous to a mixing stage in a mixnet. Inputs and outputs are registered from separate tor circuits. In order to reject unauthorized outputs, this variant of Zerolink uses RSA blind signatures. Blind signatures are given in response to valid input registrations. An unblinded signature and message is then used as an authorization token, allowing the server to ensure it corresponds to one of the inputs, ostensibly without revealing which one.

The server's blind signing key is obtained by the client by [extracting it f

Introduction

A blind signature based rate limiting tokens, or their keyed verification analogues (e.g. privacy pass) can be used to rate limit requests, but presents challenges with regards to stockpiling and interaction requirements (credential requests can be batched and done ahead of time subject to anti-stockpiling mitigations, but are still fundamentall O(N)).

The somewhat obvious idea (probably not novel, but I couldn't find a description) presented here uses the unlinkable multi-show property of anonymous credentials to construct token bucket filters with a one time setup, permitting non-interactive self-issuance of usage tokens whose honest usage is anonymous (tokens of a single credential or different credentials are indistinguishable).

One time set up

A client wishes to make repeated anonymous requests to a rate limited server.

Summary

Since Taproot (more generally any kind of MAST) spends have variable size which depends on the path being used, the last such input to be signed in a multiparty transaction can always use a larger than estimated witness to unfairly extract a fee contribution from the other parties to the transaction (keeping the absolute fees the same and reducing the feerate for the transaction).

Attack Scenario

Bitcoin Privacy Introduction

Why privacy matters in Bitcoin

Celsius recent court filings provided a terrible and arguably avoidable loss of privacy for many of its customers, and will likely have chilling ripple effects for a long time to come. The goal of this presentation-turned-writeup is to give some context so that the reader can understand the consequences of such incidents and where to find more detailed information in order to mitigate such risks, and the tradeoffs that entails.

moved to https://github.com/zkSNACKs/WabiSabi/blob/master/explainer.md

WabiSabi by Analogy

WabiSabi is a protocol (work in progress) for constructing CoinJoin transactions with the aid of a centralized coordinator. It utilizes keyed-verification anonymous credentials, homomorphic value commitments, and zero knowledge proofs to achieve privacy and flexibility.

CAVEAT LECTOR

this notes have been largely superseded by discussions in the https://github.com/zkSNACKs/WabiSabi repository.

secondly, this describes a general framework which may be instantiated in different ways, a point that was not made clearly (the specific types described are more like independent examples of possible designs, not a specific proposal)

Overview

Modifications to the zerolink Chaumian coinjoin scheme to support:

bitcoin privacy related bookmarks

	# This script lives in my home manager home.packages. I also have:
	#
	# programs.direnv.enable = true;
	# programs.direnv.nix-direnv.enable = true;
	#
	# To enable a language, I use e.g.:
	#
	# nix registry add rust-direnv ~/code/dev-templates/rust
	#
	# where the directory is my local fork of https://github.com/the-nix-way/dev-templates