Yuval Kogman nothingmuch

bitcoin privacy related bookmarks

protocols

Motivation

Locking down REST and/or JSON-RPC APIs in a generic way, with an object capability security model.

Proposed Design

Given some sort of priviliged access to a backend, this proxy would expose the service with no changes to the API apart from additional requirement for macaroon authorization.

A second mode would also be able to expose such a service to an unrestricted port, by statically configuring a macaroon to be submitted to an upstream endpoint, allowing hardened APIs to be exposed with no macaroon required.

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&#58; ????
    Title&#58; 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

In Bitcoin every redeemable UTXO is encumbered by a script, which along with the right inputs (that cause it to evaluate to true) would release those funds.

Focusing only on pay to pubkey hash scripts, which refer to a single key by the RIPEMD160 of the SHA256 of the curve point generate from the private key, if you enumerate private keys, derive the pubkey, and hash it, the birthday problem quantifies your chances of finding a RIPEMD160 hash collision for which you have the corresponding private key that allows you to sign a transaction that redeems that UTXO.

This is the most efficient way of brute forcing P2PKH outputs under the assumption that the keys were generated with a cryptographically secure random number genreator.

We could also consider P2PK outputs but they are not in common use, or P2SH outputs which would require finding a collision of script hashes (as opposed to pubkey hashes, so this is a much larger space of inputs, but some of those scripts are deterministically generatable from a pub

turing completeness is needed if a contract can only be specified in terms of a universal turing machine acting on some input, i.e. some equivalent of an eval function, but a blockchain can never reach consensus on a predicate that doesn't halt

specifying predicates as total functions guarantees by construction that any specifiable predicate is will terminate over the entire domain of possible inputs

logically it follows that you only really need a total language to specify arbitrary predicates, but in practice that might still not be enough because even if a predicate provably terminates, it doesn't mean it does so in a reasonable time frame, nor does it guarantee that the input domain is sufficient for specifying all the things a blockchain might reach consensus about

an ideal language for such transactions would therefore not only guarantee termination, it would also give strong bounds on the complexity, be efficient to evaluate in practice, and place no arbitrary restrictions on the input domain, but t

github's rendering of org mode sucks (links, footnotes and outline layout are all kind of broken), so this gist is best cloned and viewed in emacs.

once my editing settles down this will be converted to markdown or mediawiki format for better viewing on github. apologies!

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

	guix hash dependency source file guix revision package file line
	1wl1x93b5w457ddsdgj0lh7yjq4q6l7wfbgwhagkc8fm2qkkrd0p expat-2.2.6.tar.bz2 HEAD gnu/packages/xml.scm 75
	1wm4pv12f36cwzhldpp7vy3lhm3xdcnp4f184xkxsp7b18r7gm7x libXau-1.0.8.tar.bz2 HEAD gnu/packages/xorg.scm 4821
	0dbfn5bznnrhqzvkrcmw4c44yvvpwdcsrvzxf4rk27r36b9x865m libXext-1.3.3.tar.bz2 HEAD gnu/packages/xorg.scm 4547
	040rcs9fpv4bslhiy43v7dcrzakz4vwwpyqg4jp8bn24sl95ci7f protobuf-2.6.1.tar.bz2 HEAD gnu/packages/protobuf.scm 139
	1c2vma9gqgc2v06rfxdiqgwhxmzk2cbmknwf1ng3m76vr0xb5x7k xextproto-7.3.0.tar.bz2 HEAD gnu/packages/xorg.scm 2369
	18dighcs333gsvajvvgqp8l4cx7h1x7yx9gd5xacnk80spyykrf3 zlib-1.2.11.tar.gz HEAD gnu/packages/compression.scm 81
	0jjirhw6xwz2ffmbg5kr79108l8i1bdaw7szc67n3qpkygaxsjb0 dbus-1.10.18.tar.gz d8048a1212e880ce360aaf1b32f4bf3c84e51028 gnu/packages/glib.scm 78
	1wy7svvp7df6bjpg1m5vizb3ngd7rhb20vpclv3x3qa71khs6jdl fontconfig-2.12.1.tar.bz2 ab4e939c50b579eaee634c7c90c600f9c9f3aa3f gnu/packages/fontutils.scm 233
	121gm15ayfg3rglby8ifh8384

	#!/bin/bash

	set -e

	echo "Pinging peers..."
	bitcoin-cli ping

	sleep 2

	# loop until all but 2 slowest peers have responded