nothingmuch

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

nothingmuch

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

nothingmuch

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.

nothingmuch

# 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

nothingmuch

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

nothingmuch

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.

nothingmuch

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.

nothingmuch

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:

nothingmuch

bitcoin privacy related bookmarks

protocols

• CoinShuffle: Practical Decentralized Coin Mixing for Bitcoin | SpringerLink
• Blindcoin: Blinded, Accountable Mixes for Bitcoin | SpringerLink
• P2P Mixing and Unlinkable P2P Transactions
• P2P Mixing and Unlinkable Transactions
• Anonymous CoinJoin Transactions with Arbitrary Values
• Sci-Hub | Sybil-Resistant Mixing for Bitcoin | 10.1145/2665943.2665955

nothingmuch

// PoC for 2-of-3 multisig where one of the keys is an opendime (sealed at time of scriptPubKey creation)
// see on https://ivy-lang.org/bitcoin
// the script ivy generates seems sub-optimal (some unconditional rotation and rolling of stack elements)
// but this is just a yucky PoC, and the ivy source is arguably easier to understand anyway

contract LockWithKeyHashMultisig(
  pubKey1: PublicKey,
  pubKey2: PublicKey,
  pubKey3hash: Ripemd160(Sha256(PublicKey)), // opendime address
  dummyKey: PublicKey, // should be a curve point with no known discrete log