Steven Roose stevenroose

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

Evan (@emschwartz) came up with this idea we sometimes refer to as Fishchain. The idea is that you can request a packet of data by broadcasting a payment where the condition is the hash of that data.

Not sure if this new or not, but I just noticed that the Fishchain idea works not just for message retrieval bounties as stated above, but message delivery bounties as well.

Imagine A wants to deliver a message m to B, but doesn't have a direct connection. C has a way to talk to both A and B, but doesn't want to relay a message for free. Neither A nor B trust C.

A could tell C: My buddy, B, will pay you 5 cents if you deliver my message to her.

C thinks that that is a fair price, so she first gets A to sign the hash of the message H(m). She then contacts B saying that she has a message for her whose hash is H(m) and presents A's signature over H(m). B promptly creates a transfer to C using H(m) as the condition.

Locate the section for your github remote in the .git/config file. It looks like this:

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = [email protected]:joyent/node.git

Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:

Goals

Syncthing devices that store data in encrypted format. Such a device can participate fully in a cluster, but the information on the device is not directly usable.

Assumptions and Definitions

There exists a secret key per folder, known only by devices that can access the unencrypted data. We call these "secure devices".
Devices that do not know the secret key can only access encrypted data. We call these "insecure devices".

O(1) Block Propagation

The problem

Bitcoin miners want their newly-found blocks to propagate across the network as quickly as possible, because every millisecond of delay increases the chances that another block, found at about the same time, wins the "block race."

	➜ rust-libwally cat Cargo.toml
	[package]
	name = "rust-libwally"
	version = "0.1.0"
	authors = ["Riccardo Casatta <[email protected]>"]
	build = "build.rs"

	[dependencies]
	libc = "0.2"

	#! /bin/sh

	test_run()
	{
	if [ "`./truncated-graph-traversal \"$1\"`" = "$2" ]; then
	echo "$2"
	else
	./truncated-graph-traversal "$1" >&2
	echo Expected "$2" >&2
	exit 1

	package main

	import (
	"encoding/hex"
	"fmt"

	"github.com/btcsuite/btcd/btcec"
	"github.com/btcsuite/btcd/chaincfg"
	"github.com/btcsuite/btcd/txscript"
	"github.com/btcsuite/btcd/wire"

	package main

	import (
	"encoding/hex"
	"fmt"
	"os"

	"github.com/btcsuite/btcd/chaincfg/chainhash"
	"github.com/btcsuite/btcd/txscript"
	"github.com/btcsuite/btcd/wire"


	void enableSSL() {
	// the password used for the certutil db
	var sslPassword = "";

	// the certificate subject
	// retrieved from certutil with command
	// > certutil -d sql:. -L -n my_domain
	// and look for the "Subject: " line under certificate data
	var certificateName = "CN=mydomain.com,OU=...";