Nick nickfarrow

Coldcard Firmware Security Audit — 2026-06-17

Scope: memory crashes / OOB, weak RNG, nonce reuse, Bitcoin signing logic (oversized-fee, change/fee handling), integer/number overflows, and anything else that could cause loss of funds or device compromise.

Method: read-only review. Python layer (PSBT/signing/serialization, RNG, NFC, QR) plus a deep multi-agent pass over the C code (bootloader/USB dispatch, secure-element I2C, NFC/NDEF, QR/BBQr decode, crypto wrappers, flash/firmware-update). Every C finding was put through an independent adversarial verifier prompted to refute it; only what

Private Collaborative Custody with FROST

With multiparty computation multisignatures like FROST [0], it is possible to build a collaborative custodian service that is extremely private for users.

Today's collaborative custodians can see your entire wallet history even if you never require them to help sign a transaction, and they have full liberty to censor any signature requests they deem inappropriate or are coerced into censoring.

With FROST, a private collaborative custodian can hold a key to a multisig while remaining unaware of the public key (and wallet) which they help control. By hiding this public key, we solve the issue of existing collaborative custodians who learn of all wallet transactions even if you never use them.

Further, in the scenario that we do call upon a private collaborative custodian to help sign a transaction, this transaction could be signed blindly. Being blind to the transaction request itself and unknowing of past onchain behavior, these custodians have no practical in

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).

Keybase proof

I hereby claim:

I am nickfarrow on github.
I am coinjoiner (https://keybase.io/coinjoiner) on keybase.
I have a public key ASDG-QPr5deQ9aVkC0aFBSt6Dk5xsEMcxallzlOF1uR2Ugo

To claim this, I am signing this object:

	#!/usr/bin/env python3
	"""Fetch Claude Code subscription usage across windows and models.

	Hits the same `/api/oauth/usage` endpoint that the in-app `/usage` command
	uses, authenticated with the OAuth token stored by `claude auth login`.

	Library use:

	from claude_usage import get_usage
	data = get_usage() # dict — raw API response

	#!/usr/bin/env python3
	"""Stamp a signature image onto a PDF — with interactive placement via a GUI preview."""

	import argparse
	import io
	import sys
	import tempfile
	from pathlib import Path

	from pypdf import PdfReader, PdfWriter

	# Multistage Rust Docker Build for Umbrel App
	# by utxo.club
	#
	# x86_64-unknown-linux-musl
	# aarch64-unknown-linux-musl
	#
	# Conditionally `cargo build` for platforms of x86_64 or ARM.
	# Use musl for static linking, producing a standalone executable with no dependencies.
	# In the final Docker stage we copy the built binary to alpine, and run with environment:
	# $LND_HOST, $LND_GRPC_PORT, $TLS_FILE, $MACAROON_FILE"