nothingmuch

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

nothingmuch

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

nothingmuch

#!/bin/bash

set -e

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

sleep 2

# loop until all but 2 slowest peers have responded

nothingmuch

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.

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

nothingmuch

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

nothingmuch

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

nothingmuch

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!

nothingmuch

diff --git a/index.js b/index.js
index 5bacf9d..fee9969 100644
--- a/index.js
+++ b/index.js
@@ -98,6 +98,7 @@ Store.prototype._write = function (offset, buf, cb) {
     var offsets = self._blocks(offset, offset + buf.length)
     var pending = 1
     var buffers = {}
+
     for (var i = 0; i < offsets.length; i++) (function (o,i) {