Yuval Kogman nothingmuch

Blind Merged Mining with covenants ( sighash_anyprevout / op_ctv )

Update: the content of this gist is also explained in this Spacechains video.

This write-up was also published on bitcoin-dev.

Blind Merged Mining (BMM) is the idea of committing the hash of another blockchain into a unique location on the Bitcoin blockchain, and paying a Bitcoin fee to miners for the privilege of deciding this hash and capturing the fees inside the other blockchain. Since miners don’t have to know what the hash represents and are simply incentivized to choose the highest bidder, it requires no extra validation on their part (“blind”). This idea was originally conceived of by Paul Sztorc, but required a specific soft fork. [0]

In essence, BMM is a mechanism that allows external blockchains (altcoins, tokens) to outsource their mining to the Bitcoin blockchain. Instead of burning electricity with ASICs, th

Fidelity Bonds in an Anonymity set

If timelocked outputs are used as fidelity bonds, there is some inevitable degradation in the anonymity of users of a system that requires such bonds. Part of this would be entirely unavoidable - in that when the utxo is spent, the CLTV nature of the scriptPubKey must be revealed, and in most scenarios this would probably watermark that the utxo was being used for a fidelity bond purpose. But what might be avoided is the tracing, or linking, of a particular utxo used repeatedly for the same purpose.

Concrete case: Joinmarket maker

To make the issue clearer, consider the specific case of Joinmarket, and the recent proposal on fidelity bonds by Chris Belcher [1]. Here, the fidelity bond would be used to sign an ephemeral identity used on a message channel. The user, having committed funds to the bond, would perforce re-use that same bond every time he reconnects to the trading pit and so what is currently a completely ephemeral identity (it can be changed as often as

Financial mathematics of JoinMarket fidelity bonds

13/7/2019

4/4/2021 (edited fixing formula and adding two graphs)

7/5/2021 (added appendix 1)

To read the context see the main document Design for improving joinmarket's resistance to sybil attacks using fidelity bonds.

JoinMarket with off-chain fees

17/01/2019

Problem: Single JoinMarket coinjoins aren't private enough

A single JoinMarket coinjoin often doesn't hide which inputs belong to the maker(s) and which belong to the taker. This is because the coinjoin fee is included on-chain.

To tell apart takers' inputs from makers' inputs, subset matching can be used. The taker's subset is

Described here is a variant of what has previously been published under the name "P2EP" or Pay-to-endpoint, in which A pays B but B contributes utxos, i.e. it's a coinjoin-payment.

I'm using the term "payjoin" here to refer to using that idea, but not including a URI/endpoint specific to B, and not allowing (as a merchant would) arbitrary payments, which opens up certain problems around snooping attackers (more on this below). So payjoin just means "A pays B but B actively participates and passes across utxos as extra inputs".

I'll defer a more features-focused and non-tech friendly description of what this means to a later blogpost.

	Reducing noise in the rebroadcast set:

	I think there are two ways these filters reduce the rebroadcast set

	1. Caching min fee rate by itself —> mempool is emptying out, blocks are being mined & txn fees are decreasing. Time to rebroadcast, set is calculated & cache is applied.

	Time 1: caching job runs, top block computed to include a, b, c
	Mempool looks like: j i h g f e d \| c b a

	Time 2-4: txns come in

	$ ghci
	GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
	Prelude> let z = \s z -> z
	Prelude> let s = \n s z -> s $ n s z
	Prelude> let unchurch n = n (+1) 0
	Prelude> unchurch z
	0
	Prelude> let n1 = s z
	Prelude> let n2 = s $ s z
	Prelude> let n3 = s $ s $ s z

	#!/usr/bin/env python
	from __future__ import print_function
	"""
	Find/count JM transactions in blocks.
	Ensure your joinmarket-clientserver virtualenv (jmvenv) is activated,
	make sure your Bitcoin Core node is available and joinmarket.cfg is appropriately set.

	Pass start and end block number:
	`python jmtxfinder.py 400000 400200`.

	# bitcoin-cli wrapper for running c-lightning with a pruned Bitcoin node
	# (EXPERIMENTAL). It forwards all requests to bitcoind. If a getblock request fails,
	# blockstream.info is queried instead. If your prune setting is high enough (2 weeks
	# = 2016?) using this wrapper SHOULDN'T have security implications because the
	# important blocks are still queried through your own bitcoind.
	# Tested with c-lightning 0.6.2. Set the --bitcoin-cli=PATH option in c-lightning to
	# the path of this file to use it.
	BCLI=bitcoin-cli

	getblock() {