aliashraf
Legendary
Offline
Activity: 1456
Merit: 1174
Always remember the cause!
|
Some assumptions: 1- We are testing Whether Y has ever released/moved coins such that they are collected by X.
2- Neither X nor Y are not coinbase addresses, i.e. they are not used by miners to claim block reward.
3- We cover output script types with a distinguished unlocking address, identifiable.
Now I'm going to show that how complicated and resource intensive it is to avoid false negatives for the test results because in its general form this problem ends to an exhaustive search..
We have Address X Which appears in a number of txns as the lock address of one or more outputs, where each transaction has a number of inputs which are unlocked by a number of addresses. Omitting coinbase addresses, if any, from the list of input addresses we get are a set I1 which has m addresses where m is typically greater than 1. If Y is not in I1 now number of the test subjects are m and the serach should be run m times and continue untill it halts. In each loop we should take care of recurring addresses by removing them.
Halt conditions: 1- Y is spotted. 2- All the new candidates are omitted early because of them being coinbase addresses. 3- The search space is exhausted, proving no links between the two. We ignore the trivial positive case, i.e., yes, Y has financed X! The last two conditions are actually the same: coinbase txns as the halting factor, and both result into a True negative result, still they are very unlikely to reach in practice.
Firstly, the Second halt condition is not reachable unless we are talking about a very special X address directly linked to a miner, for normal addresses it is not happening.
Secondly, bitcoin ledger has ordered 750,000,000 txns right now, exhausting the total search space is very likely to involve a considerable portion of this ledger, if not all of it, before we are out of non coinbase inputs. For each candidate address, the list of all transactions toward it should be queried and for each transaction to be examined it should be located then fetched from the HDD and the list of inputs should be preserved on the HDD as well (to prevent recurring addresses and loops) with a unique index applied, it is a very resource consuming process almost comparable to syncing the whole blockchain.
Conclusion: I'd improve the question like this: Is address X financed by address Y in 10 or fewer hopes?
It is also notable that "indirect" involvement in funds transfered to an address losses its informatic importance when it is 'too' indirect.
|