See latest version at https://github.com/bitcoin/bips/blob/master/bip-0326.mediawiki
// 22/4/2021 | |
// random various unrelated functions coded to help me figure out how to use rust-bitcoin | |
// should be useful for figuring out why certain things in teleport are coded the way they are | |
extern crate bitcoincore_rpc; | |
use bitcoincore_rpc::{Client, Error, RpcApi, Auth}; | |
extern crate bitcoin_wallet; | |
use bitcoin_wallet::account::{ | |
MasterAccount, Unlocker, Account, AccountAddressType |
25/5/2020
Imagine a future where a user Alice has bitcoins and wants to send them with maximal privacy, so she creates a special kind of transaction. For anyone looking at the blockchain her transaction appears completely normal with her coins seemingly going from address A to address B. But in reality her coins end up in address Z which is entirely unconnected to either A or B.
Now imagine another user, Carol, who isn't too bothered by privacy and sends her bitcoin using a regular wallet which exists today. But because Carol's transaction looks exactly the same as Alice's, anybody analyzing the blockchain must now deal with the possibility that Carol's transaction actually sent her coins to a totally unconnected address. So Carol's privacy is improved even though she didn't change her behaviour, and perhaps had never even heard of this software.
I keep a diary of all the work I do on bitcoin privacy.
It may also be interesting to my collaborators and donors, and anyone who wants to follow how my projects are going (these days I'm almost exclusively working on developing CoinSwap, see https://gist.github.com/chris-belcher/9144bd57a91c194e332fb5ca371d0964).
Support this work with a donation: https://bitcoinprivacy.me/coinswap-donations
13/7/2019
JoinMarket can be sybil attacked today at relatively low cost which can destroy its privacy. Bitcoins can be sacrificed with burner outputs and time-locked addresses (also called fidelity bonds), and this can be used to greatly improve JoinMarket's resistance to sybil attacks.
With real-world data and realistic assumptions we calculate that under such a fidelity bond system an adversary would need to lock up 30,000-80,000 bitcoins for months, or send 45-120 bitcoins to burner addresses to have a good chance of sybil attacking the system if it were added to JoinMarket.
#! /usr/bin/python3 | |
##this file calculates the success probability of a sybil attack on the | |
# orderbook with fidelity bonds used in joinmarket | |
# see https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b | |
from scipy.optimize import brentq | |
from time import time | |
from datetime import timedelta |
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.
edit: this scheme has serious problems, see the comments
2019/03/21
Lightweight wallets are ones which are not full nodes. Lots of people use them because full nodes are costly: they cost time to setup/synchronize, education, disk space, bandwidth, RAM and a few other resources.
24/02/2019
JoinMarket has a tumbler application which aims to send bitcoins in a way that delinks the origin and destination.
I have some thoughts on how and why to improve the tumbler algorithm.
Feel free to bikeshed some of these parameters (averages, counts, etc), as my important points are about other stuff.
17/01/2019
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