Knowing Your Coin Privacy (Using KYCP.org)
Know Your Coin Privacy (KYCP) is an online tool for users of Bitcoin to visualize the degree of privacy in a bitcoin transaction. Various metrics are used to quantify this including measuring the resistance of a transaction against privacy attacks such as Merged Inputs Heuristics and Coinjoin Sudoku. These metrics make it especially useful for determining the quality of joint transactions such as CoinJoins.
In other words: inspect the entire history of your wallet using a single UTXO.
How to Use the KYCP Online Tool
Note: KYCP relies on OXT for data. If you are unable to see your transaction analyzed you must wait until at least 6 confirmations have been performed on the transaction.
Find a transaction to analyze. In the below example a transaction hash is used but an UTXO can also be provided. Input this value into the search bar at https://kycp.org.
Click to access the above example transaction in KYCP.org: f39d831aef2e49e21f542e2e3a2b0d577dae40132b7da49506b45e0b042794a7 (link)
Reading the Results on KYCP
In the above example KYCP returns the following information, starting from the top:
- How long ago the transaction was made. Three hours ago or at 2019–07–25 07:33:51.
- A link to open the transaction in OXT.me.
- The total value of the transaction: 14.6317 ฿.
- How many addresses have been previously used in the transaction: 6 addresses reused. More details about this later.
- How many inputs share a common previous transaction: 46 input merges and 0 output merges. For mix transactions, this number should always be zero. More details about this later.
- Boltzmann support message: “OXT has not yet fully analysed this transaction. Please try again later for full results.” Because the example transaction is relatively large, Boltzmann data is unavailable. Most smaller transactions otherwise will display the Boltzmann info including deterministic links, possible combinations, and entropy.
Understanding Address Reuses
An address is considered reused if it has sent or received more than one input and one output. One input and one output (1–1) is a normal transaction however, anything more is problematic. The above example has six address reuses which means six of the addresses have been previously used in a transaction before.
Furthermore, there are 46 input merges. This means that of the 81 inputs, 46 share a common previous transaction. Thus it can be assumed they belong to the same wallet or collaborate together. Having no merges is ideal for privacy.
Understanding the Graph
The left side of the graph depicts all the transaction inputs including the address (note the color), a colored box (either orange, green, or red- more about this in the next section), a left bracket arrow (<), bitcoin amount, and input index.
On the right column of the graph are the outputs. Some transactions may have labels such as “ANON_” or wallet names here. These are automatically imported from OXT.me.
In the example, there are 81 total inputs. Of these 81 inputs, 46 inputs share a common previous transaction which are color-coded. Observe that index 2 and index 3 are both pink, for example. In total this address (6c8df...2d3) appears four times in the transaction.
Clicking on the left bracket (<) will open a link to the previous transaction in KYCP.org. Notice that the links for both index 2 and 3 are the same transaction.
Understanding Clusters
The center column visualizes clustered inputs and outputs that have been regrouped as being part of the same entity or owner (this could be the same exchange, or individual wallet, and so forth). As mentioned in the previous section, there is a color box depicted next to an address in the input list. This color maps to the color of the bands shown here. An orange band indicates being identified in the same cluster. For merged inputs, this denotes coming from the same transaction while for merged outputs, it means they were spent by the same transaction. A red band indicates a relation between the two clusters, or in other words address reuse.
Green bands, on the other hand, display a lack of any deterministic links. An example chart with can be found in the next section.
In the above example, observe input 22 and 36. Looking at the TXIDS for 22 and 36 in the left column one can observe these are indeed the same previous transaction (c5896…dc0), listed in light green. This means the two inputs originate from the same transaction. In this example we can see the 2 inputs mixed together previously.
In the following example, observe that inputs 1, 53, 71, and 74 are red, indicating address reuse. Looking at their addresses in the left column one can observe these are indeed the same address (bc1qg…2du), listed in cyan. This means these two clusters belong to the same wallet.
In the next example, inputs 5, 55, and 80 are related to output 97 via input 55.
Although output 97 is not spent yet, it will bring its problematic history with it once it is spent.
Observe input 55 in the list of inputs. This same address is used in output 97.
Example Graphs
In the above CoinJoin, the Boltzmann information is returned whereas in the previous example of the large transaction it was not. Since this is a small transaction the system can easily return its analysis.
The above CoinJoin transaction has five inputs each with an equal amount of inputs (.05 ฿). There are no deterministic links meaning that the probability of a link between an input to an output is zero. This is considered good privacy. Transaction (TX) efficiency compares transaction entropy to the “best possible transaction” with the same number of inputs and outputs. 100% is considered good privacy.
Lastly, the following is an example of what the vast majority of bitcoin transactions look like.
Update: new features
Recently, two additional features have been added to KYCP: entropy density and probable links.
Entropy density was introduced to compliment the obtained percentage of possible entropy known as wallet efficiency, labeled simply as “efficiency” in KYCP. Wallet efficiency is calculated by taking the actual entropy of the transaction and dividing it by the theoretical perfect score that could be obtained for that particular transaction configuration. However, a drawback with wallet efficiency is that it is often so low (below 1%) that it can be impractical. Entropy density, on the other hand, is how the obtained entropy is spread across all inputs and outputs. In Information Theory, entropy is the measure of uncertainty for a variable while density measures the concentration of a substance. In the context of address analysis, a higher concentration of entropy, not less, is therefore desirable.
Entropy density has been calculated by taking the entropy* and dividing it by the total number of inputs and outputs. For coinjoins, an entropy density of 1.0 or above is the target to shoot for. Conversely, an entropy density less than 1.0 denotes a suboptimal coinjoin.
The above transaction utilizes the free STONEWALL feature of Samourai Wallet. STONEWALL creates doubt as to whether or not a transaction involves one wallet or two wallets. The entropy density score is high for a non-perfect coinjoin as is the wallet efficiency which can also be considered high for any kind of transaction. The 1.585 entropy score is the standard score for a STONEWALL transaction of a composition of 2 inputs and 4 outputs.
Whirlpool coinjoins structurally obtain 100% wallet efficiency (100% of the maximum possible entropy for their composition) and always score above 1.0 entropy density. The first screenshot in the “Example Graphs” section is an example of a Whirlpool coinjoin.
*Raw entropy can be seen by clicking the OXT button and consulting the data provided in the ‘Summary’ tab. Note however that entropy is only provided for transactions within a certain limit of number of inputs and outputs.
Note: All perfect coinjoins (that is, a coinjoin that has the same number of inputs and outputs and all the output values are equal) from 3 inputs and 3 outputs and higher will always return an entropy density greater than 1.0. Any coinjoin less than 1.0 is considered suboptimal. Therefore, particular attention to entropy density should be made when performing a coinjoin and even more so when the entropy is less than 100%.
Support the Know Your Coin Privacy project:
