nopara73 / dumplings Goto Github PK

View Code? Open in Web Editor NEW

26.0 10.0 16.0 60.29 MB

A cross platform and open source software to create reproducible CoinJoin statistics from Blockchain data.

C# 100.00%

dumplings's Introduction

Setup & Run

Get Git: https://git-scm.com/downloads
Get .NET Core SDK: https://www.microsoft.com/net/download
Get Bitcoin Core: https://bitcoincore.org/ or Bitcoin Knots: https://bitcoinknots.org/
Make sure your bitcoin.conf has the following entries: txindex = 1, server = 1, rpcuser = user, rpcpassword = password, listen = 1, rpcworkqueue = 128
Run Bitcoin and wait until it's synchronized.
git clone https://github.com/nopara73/Dumplings.git
cd Dumplings/Dumplings.Cli
dotnet run -- sync --rpcuser=user --rpcpassword=password

Usage

Run Bitcoin, wait until it's synchronized.
cd Dumplings/Dumplings.Cli

1. Synchronization

In order to run other commands and local storage to be up to date you have to synchronize Dumplings. You can synchronize it with the sync command. This will go through the blockchain and find and save transactions that other commands work with.

dotnet run -- sync --rpcuser=user --rpcpassword=password

If you want to resync, then use the resync command.

dotnet run -- resync --rpcuser=user --rpcpassword=password

2. Integrity Checks

After you synchronized you probably want to do some data integrity checks too:

dotnet run -- check --rpcuser=user --rpcpassword=password

3. Creating Statistics

The software can create statistics after it synchronized. Synchronization will create a folder, called Scanner and some files in it:

From these files you can create many kind of statistics quickly or just create the existing statistics. You can download a Scanner folder that's synced up to 2020-05-22 from here.

The expected location of the scanner folder is Dumplings\Dumplings.Cli\bin\Debug\netcoreapp3.1\Scanner on Windows and Dumplings/Dumplings.Cli/Scanner/ on Linux (and probably on OSX.)

After synchronization you can create statistics as follows: dotnet run -- COMMAND --rpcuser=user --rpcpassword=password, where the COMMAND is the command for the statistics you want to create.

Commands & Results

MonthlyVolumes

Total monthly volume of CoinJoin transactions.

FreshBitcoins

Best proxy for user adoption.

How many non-remixed bitcoins get to CoinJoined monthly.

Average count of remixes is a derived metric, which shows how many times a bitcoin participated in mixes in average: total volume/fresh bitcoins.

NeverMixed

Bitcoins those were intended to be mixed, but were not.

For Wasabi and Otheri, it counts CoinJoin change outputs those have been spent, but not in other CoinJoins. (Note 1: the software does not currently examine if the change is coming from CoinJoined inputs. Note 2: more related metrics and more detailed explanation on Wasabi's inefficiency can be found under the WasabiCjEfficiency repository.)
For Samuri, it counts TX0 transaction outputs those have been spent, but not in other TX0 or coinjoin transactions.

The following is a derived metric: it's the percentage of nevermixed coins to fresh bitcoins.

PostMixConsolidation

Average number of inputs in the first non-coinjoin transactions after coinjoins.

FAQ

What does Wasabi, Samuri, Otheri mean?

Wasabi: Wasabi Wallet ZeroLink CoinJoins.
Samuri: Samourai Wallet Whirlpool CoinJoins.
Otheri: Other CoinJoin looking transactions.

What about JoinMarket?

JoinMarket transactions are not obvious to identify with high accuracy solely from Blockchain data. To identify JM transactions one would need to listen to JM orderbook, which is off-chain data, so that is outside the scope of Dumplings. BlockSci made the best known attempt to identify them, which had only a 94% accuracy rate, which included computationally expensive subsetsum problem solving and left out larger JoinMarket transactions. Leaving out larger JM transactions would lead to misleading results and graphs, so I opted to not do that.

In summary: Every JoinMarket transactions are "Other CoinJoin Transactions," but not every "Other CoinJoin Transactions" are JoinMarket transactions.

What about network level privacy?

Not all CoinJoins are created equal. Statistics like this gives the wrong impression that a Samurai CJ is just as good as a Wasabi or a JoinMarket CJ. This is not the case. Just like Blockchain.info's SharedCoin CoinJoins weren't, Samourai CoinJoins aren't trustless either, as these companies know your xpub, from which all your present, past and future Bitcoin addresses can be derived, thus users gain no privacy against these companies and the third parties they share your data with, even if they CoinJoin.

dumplings's People

Contributors

Stargazers

Watchers

Forkers

maxhillebrand seresistvanandras molnard nabisabi kukks adampetho prusnak alg747 22388o arealayer funquake

dumplings's Issues

Inaccurate statement regarding Samourai Xpubs

Samourai CoinJoins aren't trustless either, as these companies know your xpub, from which all your present, past and future Bitcoin addresses can be derived, thus users gain no privacy against these companies and the third parties they share your data with, even if they CoinJoin.

Using dojo users don't submit their xpubs to Samourai therefore this statement is inaccurate.

Samourai vs Joinstr

This example of Joinstr coinjoin from here looks very similar to possible Samourai coinjoins - just five equal inputs, five equal outputs, no change.

I don't know precise algorithm Dumplings uses for Samourai coinjoin detection, but somebody with better knowledge of this code could take a look and make sure these aren't counted as Samourai coinjoins.

Joinstr code is here - https://gitlab.com/1440000bytes/joinstr.

Bitcoin Knots vs Bitcoin Core

The README.md mentions Bitcoin Knots, but does not mention what is the specific reason to use Bitcoin Knots and not the upstream Bitcoin Core?

ISTM that Bitcoin Core should work too, but maybe I am missing something?

additional metrics

please add

anonset per round [quantity of equal value outputs at different pools]
total quantity of vbytes
relation of anonset / vbyte
multiple of anonset * remix count
anonset weighted volume mix score

The CoinJoin equality metric is misleading.

2 people mix 1 BTC with each other on output side = 2*(2-1)*1 = 2 BTC "CoinJoin Equality"

3 people mix 1 BTC with each other on output side = 3*(3-1)*1 = 6 BTC

60 people mix 1 BTC with each other on output side = 60*(60-1)*1= 3540 BTC

By (almost) squaring the number of users you are again falling into the trap of thinking that anon-set grows exponentially, when in fact it's additive.

It doesn't make sense to say that there is more value "Equality" than has been mixed (e.g. in the last example, 60 BTC has been mixed but the CoinJoin Equality value is 59 times larger than this).

This makes mixing methods with a large number of participants per mix (like wasabi) look good, whereas mixing methods with fewer participants per mix but plenty of remixing (like whirlpool) look bad by ignoring the remixes and the backward/forward looking anon-set gained by ensuing perfect non-deterministic mixing.

Mempool

It would be useful to get a coinjoin transaction as soon as it is seen in the mempool.

Use `dumptxoutset` instead of `gettxout`?

Currently Dumplings is doing a lot of gettxout calls to Bitcoin Core / Knots to check each TXO individually. It would probably be a lot faster to use dumptxoutset instead, then load it in memory and then query that data instead. But it would require bitcoind and Dumplings running on the same machine, which is probably ok tradeoff.

It was implemented in bitcoin/bitcoin#16899.

$ bitcoin-cli help dumptxoutset
dumptxoutset "path" ( format show_header "separator" )

Write the UTXO set to disk.

Arguments:
1. path                   (string, required) Path to the output file. If relative, will be prefixed by datadir.
2. format                 (json array, optional, default=compact serialized format) If no argument is provided, a compact binary serialized format is used; otherwise only requested items available below are written in ASCII format (if an empty array is provided, all items are written in ASCII).
     [
       "txid",            (string) Info to write for a given UTXO
       "vout",            (string) Info to write for a given UTXO
       "value",           (string) Info to write for a given UTXO
       "coinbase",        (string) Info to write for a given UTXO
       "height",          (string) Info to write for a given UTXO
       "scriptPubKey",    (string) Info to write for a given UTXO
       ...
     ]
3. show_header            (boolean, optional, default=true) Whether to include the header line in non-serialized (ASCII) mode
4. separator              (string, optional, default=",") Field separator to use in non-serialized (ASCII) mode

Result:
{                             (json object)
  "coins_written" : n,        (numeric) the number of coins written in the snapshot
  "base_hash" : "hex",        (string) the hash of the base of the snapshot
  "base_height" : n,          (numeric) the height of the base of the snapshot
  "path" : "str",             (string) the absolute path that the snapshot was written to
  "txoutset_hash" : "hex",    (string) the hash of the UTXO set contents
  "nchaintx" : n              (numeric) the number of transactions in the chain up to and including the base block
}

Examples:
> bitcoin-cli dumptxoutset utxo.dat
> bitcoin-cli dumptxoutset utxo.dat '[]'
> bitcoin-cli dumptxoutset utxo.dat '["txid", "vout"]' false ':'

Non instant mixing

Describing non instant mixing of tx outputs as inefficient is inaccurate.