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.

RubenSomsen

nickfarrow

Modifying FROST Signers and Threshold

FROST's distributed key generation involves N parties each creating a secret polynomial, and sharing evaluations of this polynomial with other parties to create a distributed FROST key.

The final FROST key is described by a joint polynomial, where the x=0 intercept is the jointly shared secret s=f(0). Each participant controls a single point on this polynomial at their participant index.

The degree T-1 of the polynomials determines the threshold T of the multisignature - as this sets the number of points required to interpolate the joint polynomial and compute evaluations under the joint secret.

T parties can interact in order to interpolate evaluations using the secret f[0] without ever actually reconstructing this secret in isolation (unlike Shamir Secret Sharing where you have to reconstruct the secret).

---

RubenSomsen

Silent Payments

Receive private payments from anyone on a single static address without requiring any interaction or extra on-chain overhead.

Update: This now has a BIP and WIP implementation

Overview

The recipient generates a so-called silent payment address and makes it publicly known. The sender then takes a public key from one of their chosen inputs for the payment, and uses it to derive a shared secret that is then used to tweak the silent payment address. The recipient detects the payment by scanning every transaction in the blockchain.

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

    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

staltz

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

---

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

---