kristapsk/bitcoin-scripts

Improving ricochet privacy

Opened this issue · 5 comments

Ricochet transaction chains created with ricochet-send.sh and ricochet-send-from.sh already are helpful defense against automated blockchain analysis that limits number of hops they are analyzing (and they do - from what I have seen, they show scores, which are mostly proximity of address to specific activities), but they have distinguishable pattern - chain of 1 input, 1 output transactions. I believe privacy can be improved litle bit here by reducing number of 1 input, 1 output transactions and replacing at least some of them with 1 input, 2 output or 2 input, 2 output transactions which are more common (see 1in-1out vs 1in-2out statistics charts).

Additional factor is time, but I don't see how to improve that with these scripts, users can do it themselves by increasing sleeptime_min, sleeptime_max and hop_confirmations parameters of the scripts.

Add additional donation output to Tx0 / Tx1

That is what Samourai Wallet already does. They currently add 0.001 BTC fee to themselves.

My plan would be to add 1% with upper limit of 0.001 BTC donation to early hop, with txfee_factor randomization applied on top of it (so could be up to 0.0013 BTC with default settings). Of course, we don't want address reuse, so script would ask server side for PGP signed address, preferably over Tor (if torify is available), with clearnet HTTPS fallback. That currently looks to me unavoidable centralization. In worst case for the user, if I'm evil actor and torify does not work for the user, that would allow me to tie specific transactions to user IP address. My hope is that power Bitcoin users using these scripts to improve privacy will have working Tor instance on machine too.

Addititional Q - is torify often available? Should try 127.0.0.1:9050 (Tor default) and 127.0.0.1:9150 (Tor Browser default) SOCKS proxies too?

Also need to think how to do it in a way that donation is voluntary (otherwise it's not a donation), likely should be some documented way how to turn this off.

Would look like this.

ricochet-send.sh

  • Tx0: 1..n inputs from wallet (depends on Core's coin selection), 2 outputs (to ricochet Tx1 and change back to wallet)
  • Tx1: 1 input, 2 outputs (to ricochet Tx2 and development donation) - all legacy P2PKH
  • Txn...: 1 input, 1 output transactions as before

ricochet-send-from.sh

  • Tx0: 1..n inputs from wallet (1 if no address reuse), 2 outputs (to ricochet Tx1 and development donation)
  • Tx1: 1 input, 1 output transactions as before
  • Txn...: 1 input, 1 output transactions as before

Fake BIP78 payjoin in ricochet-send.sh Tx0

Currently ricochet hops always use legacy P2PKH addresses. If migrated to bech32 P2WPKH, ricochet-send.sh could ensure that Tx0 always have at least two inputs from wallet. That way it shares anonymity set with these payjoins. I think SegWit is requirement here, as I'm not aware of any payjoin implementations in the wild that uses P2PKH.

Additional factor is time, but I don't see how to improve that with these scripts, users can do it themselves by increasing sleeptime_min, sleeptime_max and hop_confirmations parameters of the scripts.

Maybe provide parameters in the script for users to add value for sleep time? This is just improving UX and anyone who is running bash scripts can be assumed as advanced user who already knows how to add such things if there is enough documentation about it.

That is what Samourai Wallet already does. They currently add 0.001 BTC fee to themselves.

0.001 BTC for Ricochet is not a small fee IMO anyway its Samourai 😄

My plan would be to add 1% with upper limit of 0.001 BTC donation to early hop

Disagree

Also need to think how to do it in a way that donation is voluntary (otherwise it's not a donation), likely should be some documented way how to turn this off.

Agree

depends on Core's coin selection

Cough Cough. Privacy ends here.

Maybe provide parameters in the script for users to add value for sleep time?

There are already parameters for that.

if [ "$2" == "" ]; then
echo "Usage: $(basename $0) [options] amount destination_address [hops [txfee [sleeptime_min [sleeptime_max [hop_confirmations [txfee_factor]]]]]]"
echo "Where:"
echo " amount - amount to send in BTC"
echo " destination_address - destination address"
echo " hops - number of hops (default: 5)"
echo " txfee - average transaction fee per kvB (default: \"estimatesmartfee 2\", currently $($(dirname $0)/estimatesmartfee.sh $bitcoin_cli_options 2) BTC)"
echo " sleeptime_min - minimum sleep time between hops in seconds (default: 10)"
echo " sleeptime_max - maximum sleep time between hops in seconds (default: 15)"
echo " hop_confirmations - minimum number of confirmations between hops (default: 0)"
echo " txfee_factor - variance around average transaction fee, e.g. 0.00002000 fee, 0.2 var = fee is between 0.00001600 and 0.00002400 (default: 0.3)"
exit
fi

if [ "$2" == "" ]; then
echo "Usage: $(basename $0) [options] source_address destination_address [hops [txfee [sleeptime_min [sleeptime_max [hop_confirmations [txfee_factor]]]]]]"
echo "Where:"
echo " source_address - source address (all funds from that address will be send)"
echo " destination_address - destination address"
echo " hops - number of hops (default: 5)"
echo " txfee - average transaction fee per kvB (default: \"estimatesmartfee 2\", currently $($(dirname $0)/estimatesmartfee.sh $bitcoin_cli_options 2) BTC)"
echo " sleeptime_min - minimum sleep time between hops in seconds (default: 10)"
echo " sleeptime_max - maximum sleep time between hops in seconds (default: 15)"
echo " hop_confirmations - minimum number of confirmations between hops (default: 0)"
echo " txfee_factor - variance around average transaction fee, e.g. 0.00002000 fee, 0.2 var = fee is between 0.00001600 and 0.00002400 (default: 0.3)"
exit
fi

if there is enough documentation about it.

I am actually thinking about writing some basic more detailed documenation finally. Initially wrote these scripts for my personal use, documenation wasn't priority.

My plan would be to add 1% with upper limit of 0.001 BTC donation to early hop

Disagree

Disagree with specific amounts or idea in general? I basically took amounts Samourai uses, just added upper limit of ~1% on top of it, so that people could use this for smaller amounts. But I'm open to suggestions here.

Probably it's good idea to try to not have that amont too dusty, so that it looks more like a "normal" transaction.

depends on Core's coin selection

Cough Cough. Privacy ends here.

That's out of scope of these scripts. One can either use ricochet-send-from.sh to spend specific UTXO (unless there is address reuse, then will spend all UTXOs associated with that address) or use bitcoin-cli lockunspent to freeze / unfreeze specific UTXOs before doing transaction. Also, now that Bitcoin Core has multiple wallet support, is good idea to use multiple wallets to separate coins from different sources.

Disagree with specific amounts or idea in general?

Idea in general. This is just adding hops in Bitcoin transaction.

Also, now that Bitcoin Core has multiple wallet support, is good idea to use multiple wallets to separate coins from different sources.

You can have different wallets to separate coins but there would still be coins in a wallet with different transactions. Coin selection algorithms used in Bitcoin Core are not necessarily focused on improving privacy so it is possible that you end up using more inputs in a transaction than required, hence sharing more information about your wallet history.

This is just adding hops in Bitcoin transaction.

Does not change what already existing scripts do. This just adds one extra output in already existing transaction in process. Block space efficiency is important goal, but adding these hops currently is practical privacy solution that works. For example, if I send coinjoined bitcoins to a friend, who then sends them directly to Binance or Coinbase, he is in risk of freezed funds or account closure. In ideal world more people would be using coinjoins, coinswaps and other privacy techniques, so that all bitcoins are "dirty", but we aren't there (hopefully - yet).

For example, if I send coinjoined bitcoins to a friend, who then sends them directly to Binance or Coinbase, he is in risk of freezed funds or account closure. In ideal world more people would be using coinjoins, coinswaps and other privacy techniques, so that all bitcoins are "dirty", but we aren't there (hopefully - yet).

Agree we need post coinjoin tools. Disagreement was only about adding a fees for ricochet.