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

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

    BIP: ????
    Title: Change forwarding
    Author&#58; Yuval Kogman <nothingmuch@woobling.org>
    Comments&#45;URI&#58; https&#58;//github.com/bitcoin/bips/wiki/Comments&#58;BIP&#45;????
    Status&#58; Draft
    Type&#58; Informational
    Created&#58; 2018&#45;11&#45;05
    License&#58; CC0&#45;1.0
             GNU&#45;All&#45;Permissive

nothingmuch

Unequal Amount Mixing for ZeroLink using Preferred Value Series Fixed Denominations

This is a quick sketch of several modifications to zerolink. This document tries to articulate an as of yet unproven intuition is that combined together they can allow unequal input amounts as well as relaxation of the post-mix no linking restriction, while retaining the same conservative assumptions about mixed output indistinguishability.

Disallowing post-mix linking is arguably bad for fungibility, since users are likely to bypass this restriction by transferring to other wallets. Therefore, if I am able to justify this change this seems like a much more substantial contribution to usability and fungibility. That said even if it can't be shown to be reasonable to do so, some of these ideas still have merit on their own, so not all would be lost.

Proposed Protocol Changes

"Soft Fork" changes

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

// 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