Skip to content

Instantly share code, notes, and snippets.

Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
@nickfarrow
nickfarrow / malleablefrost.md
Last active May 13, 2024 05:03
Modifying FROST Threshold and Signers

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
RubenSomsen / Silent_Payments.md
Last active May 16, 2024 23:31
Silent Payments – Receive private payments from anyone on a single static address without requiring any interaction or extra on-chain overhead

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.

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


    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
staltz / introrx.md
Last active May 20, 2024 14:59
The introduction to Reactive Programming you've been missing