According to the previous discussions about
Heuristic2.
I think there are many cases that the payments are going to new addresses not only the change. That’s why the developers set up many restrictions about Heuristic 2 to lower the false positive rate. For detail please refer to the two studies below:
Bitcoin and Beyond: Exclusively Informational Money
(Section 5.1 entity graph)
http://arxiv.org/pdf/1304.4758.pdfA Fistful of Bitcoins: Characterizing Payments Among Men with No Names
(Section 4.3 Heuristic 2)
http://www0.cs.ucl.ac.uk/staff/s.meiklejohn/files/imc13.pdfPerhaps there are more conditions that can be added to the heuristic to identify the change addresses accurately. Such as the transaction amount like the previous discussion.
Condition: 1. Only two output in the transaction.
2. One of the output is a new address, the other one is an old address.
3*. The new address has the ugly amount of Bitcoin (e.g. 0.1876573 BTC), while the old address of the transaction has the amount that round to the two(?) digits after decimal point(e.g. 0.10 BTC).
In this way, we will be able to avoid the exception below. Even the converted amount has many digits in BTC. It is very unlikely the change amount will be a nice number and send to an old address.
Maybe when btc value will be stable, but more often than not for payments it's a round amount in $ or € or whatever converted to an amount with many digits in BTC...
-------------------------------------------------------------------------------------------------------------------------------------------------According to the discussions about the
new heuristic based on transaction patternsThis is very helpful!! Thanks!!
After reading this document. I think the transaction patterns we can leverage are:
Relay transations(one input, one output)
Peeling chain(consecutive transactions with one input, two outputs)
Sweep transactions(multiple inputs, one output)
I personally also often send the exact input to a casino as the exact amount I want to gamble with is not that important and I want to avoid a change address. This might be very specific to people that have full control over the inputs they spend though.
This is the exception that related to the Sweep transaction pattern. Perhaps we can set a bar for the number of input. It needs to be higher than the bar to be consider as a valid sweep transaction. Otherwise we consider it as an exception.
Those are the thoughts I have so far. Welcome to comment or propose some new ideas.
Really appreciate for all the ideas and resources.