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

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

nothingmuch

Notes on foundational modules of Dat code:

Hypercore

Feeds

totally ordered sets of blocks encoded as merkle trees

static: pure merkle trees, created by merkle-tree-stream

node types are leaf, node & root

flat-tree numbers all nodes in tree for given tree size

tree root = hash of all roots (unless $|blocks| log 2 ∈ \mathbb{N}$)

stream is not written in flat-tree order, but a breadth first upwards walk of flat tree (0, 2, 1, 4, 6, 5, 3…)

nothingmuch

#!/bin/bash
#https://wiki.archlinux.org/index.php/Core_utilities#Colored_output_when_reading_from_stdin

t=$(tempfile)
trap "rm '$t'" EXIT

script -q -c "$*" "$t" > /dev/null

stty sane

nothingmuch

From 2acd388b62d527fd2e845aa58cc3784142ac1a7f Mon Sep 17 00:00:00 2001
From: Yuval Kogman <nothingmuch@woobling.org>
Date: Sun, 23 Sep 2012 23:09:25 +0200
Subject: [PATCH] Push PAD futzing to setup_frame

- during parse method all SvFAKEs which correspond to slots have their offsets
  saved in a ptable
- the frame setup code will alias these slots to the pad
- pad ops are now back to normal behavior

nothingmuch

[  326.259124] ------------[ cut here ]------------
[  326.259172] kernel BUG at /home/apw/COD/linux/fs/btrfs/volumes.c:2788!
[  326.259220] invalid opcode: 0000 [#1] SMP 
[  326.259257] Modules linked in: zram(C) rfcomm bnep bluetooth snd_hda_codec_analog binfmt_misc snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi i915 snd_rawmidi psmouse snd_seq_midi_event snd_seq drm_kms_helper drm snd_timer i2c_algo_bit snd_seq_device snd dcdbas coretemp ppdev soundcore snd_page_alloc microcode serio_raw parport_pc video mei(C) mac_hid lp parport ses enclosure usbhid hid uas usb_storage e1000e btrfs zlib_deflate libcrc32c
[  326.259663] 
[  326.259678] Pid: 3266, comm: btrfs Tainted: G         C   3.4.4-030404-generic #201206221555 Dell Inc. OptiPlex 755                 /0GM819
[  326.259777] EIP: 0060:[<f873fc7a>] EFLAGS: 00010246 CPU: 0
[  326.259840] EIP is at btrfs_balance+0x55a/0x560 [btrfs]
[  326.259878] EAX: ffffff00 EBX: ffffffef ECX: 00000052 EDX: f714645c
[  326.259923] ESI: dbdd7a00 EDI: 00000000 EB