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.

EthanHeilman

I, Ethan Heilman, am writing this in 2024.

OP_FFS was an idea written up by Jeremy Rubin in 2017, during an email conversation with Ethan Heilman about a streaming hash function bitcoin opcode. I am sharing it as it is sometimes referenced in public discussions but was not previously public and it felt like it should be public. For instance there was some discussion referring to OP_FFS on [the bitcoin-dev mailinglist in 2019] (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017355.html) and more recently on twitter in 2024.

This should not be read as a BIP proposal, BIP draft or endorsement, there are just notes written up during private correspondence. This is being published with Jeremy's express permission.

From Jeremy's email to me:

--------BEGIN BIP----------------

0xBEEFCAF3

Emulating Check Sig From Stack (OP_CSFS) using OP_CAT

OP_CAT enables the construction of covenants within Bitcoin script, albeit in a somewhat hacky manner. It requires the spender to place transaction elements on the stack, concatenate all the transaction elements, and then trick OP_CHECKSIG into verifying these elements. The spender accomplishes this by using a signature where both the private key and private nonce are set to 1.

I refere to this hack as the Poelstra trick and you can find more information here Understanding the Poelstra trick is the hard part of learning how to build a variant CSFS.

Some Background

Elements Project's OP_CHECKSIGFROMSTACK (CSFS) verifies an ECDSA signature sig over an arbitrary message m against a public key pk. Unlike Bitcoin's existing signature-checking opcodes, such as OP_CHECKSIG, which derive the message from the transaction executing the opcode, OP_CHECKSIGFROMSTACK reads an arbitrar

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 <[email protected]>
    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.

---