How to analyze coin flow?

[avision]

I will try to keep it short..

When thinking about a visualisation tool and when hearing about the bitfinex "incident" i recapped what i know about bitcoin and what it means for following the flow of bitcoins from addresses.

1. Bitcoins do not exist. Only transactions and address
2. An Address is like an account with a balance
3. The balance is calculated and approved through the transactions

So basically if i have 5btc it is because the transactions tell so.

So my questions:

1. Forward tracing: This means after one transaction to another address the value is actually mixed with all other values coming from other sources to this address. So no way to follow it? I don`t see one.

2. Backward tracing: I can track the origin of the 5 btc in transactions. But also only one reliable step? Beacause if someone uses a service where you could exchange btc to btc from one account to antoher and they move through a big "service address" it will automatically be mixed with those also. - something wrong with my thoughts?

3. Tracing big ammounts of btc "lost" or "stolen" like in bitfinex could only be traced to an interessting point if they somewhen cluster in other adresses which do not belong to a known entity which is likely to have a big throughput in btc?

And the most important question:

I thought about a visualization of "nodes/Adresses" and their flows. You could mark addresses if you think you know it belongs to X and then follow the transactions. But if my "feelings" are right you could not trace anything reliably for more then one transaction.

So is there anything you would like in terms of user-interface an visualasation and tracing of transaction which still would be interessting? Because my inital ideas won`t be worth alot but i still like visualisation and management of big data

Yours,
Alex

[DannyHamilton]

1. Bitcoins do not exist. Only transactions and address

Addresses do not exist in the blockchain or in transactions.  Addresses only exist in wallets.

In the transactions there are:

• Inputs (supplying value to the transaction from previously unspent outputs, and meeting the requirements that those previously unspent outputs were encumbered with)
• Outputs (creating new unspent outputs, assigning value to the unspent outputs, and encumbering them with a requirement that must be met to spend them)

2. An Address is like an account with a balance

An address is nothing like an account at all.  In the blockchain, there are no balances.

An address is a label that describes a script (essentially a small computer program).
The script that the address describes encumbers the output with a requirement that must be met if that output is used to supply value as an input to a new transaction.
Every unspent output is handled individually, they are not pooled together as a "balance".  Your wallet adds up all the individual outputs and show the total to you as a "balance", but that is not how the wallet manages them in transactions or the blockchain.

3. The balance is calculated and approved through the transactions

See above.  At the protocol level, there are no "balances".  Balanced are not "approved".  A balance is something that your wallet shows you after it counts up all the outputs that it thinks you have the ability to meet the encumbrance requirements.  Transactions just spend unspent outputs as inputs, and then create new unspent outputs.

So basically if i have 5btc it is because the transactions tell so.

If you have 5 BTC, it is because you have the ability to meet the encumbrance requirements on a set of unspent outputs which have assigned values that total up to 5 BTC.

1. Forward tracing: This means after one transaction to another address the value is actually mixed with all other values coming from other sources to this address. So no way to follow it? I don`t see one.

Think of it a bit like this...

Each output is a lump of a separate precious metal. Lets say you have 1 BTC of gold, 1 BTC of silver, and 1 BTC of platinum. To "spend" your outputs, you toss them into a crucible and melt them together.  You now have 3 BTC worth of liquid alloy.  Then you pour out new lumps from the crucible.  Lets say you pour out two-thirds of the mixture into a lump, and the remaining one-third into another lump.  You give the two-thirds lump to a merchant, and keep the one-third lump for yourself.

Since all the metals were well mixed before pouring, the two-thirds lump has two-thirds of 1 BTC worth of gold, two-thirds of 1 BTC worth of silver, and two-thirds of 1 BTC worth of platinum.  It is all "mixed", but if you were to analyze the 2 BTC lump, you could still determine what its components are.

If I create an actual bitcoin transaction, I need to list SPECIFIC unspent outputs as inputs to the transaction.  Those outputs become "spent", so they can never be spent again, but they are permanently listed with that transaction in the blockchain as the inputs that supplied value to the transaction.  Then I need to list SPECIFIC new unspent outputs.  By looking at the list of inputs, and the list of outputs, you can assign a percentage of each input that the new outputs is made up of.  You can then follow the process forward to the next transaction, and so on.

2. Backward tracing: I can track the origin of the 5 btc in transactions. But also only one reliable step? Beacause if someone uses a service where you could exchange btc to btc from one account to antoher and they move through a big "service address" it will automatically be mixed with those also.

You can identify all the previously unspent outputs that supplied value to the transaction where your output was created.  Then you can identify all the previously unspent outputs that supplied value to the transactions that created each of those identified outputs. This process can be repeated all the way back to the block where the original outputs were created.  This "tree" of transactions grows exponentially which each level you trace back since transactions typically have multiple inputs.  This can make it unwieldy and difficult to trace without the assistance of a computer and some good analysis software.

3. Tracing big ammounts of btc "lost" or "stolen" like in bitfinex could only be traced to an interessting point if they somewhen cluster in other adresses which do not belong to a known entity which is likely to have a big throughput in btc?

Not sure what you're trying to say here.  Tracing any bitcoins through addresses is possible given enough computing power and good enough analysis software.  Attaching identities to any of those addresses requires that the entity doing the tracing has access to a list of addresses for which they know the owner.  Then once traced bitcoins pass through such an address, the entity doing the tracing can approach that owner and ask them who they got the bitcoins from.  They can then approach that sender and ask who they got the bitcoins from, and so on until they trace back to the beginning.

I thought about a visualization of "nodes/Adresses" and their flows. You could mark addresses if you think you know it belongs to X and then follow the transactions.

This already exists.  Blockchain.info has created such a visualization to follow bitcoins forwards.  It's not a very good one, and I'm sure that there is private software created for law enforcement that works much better.

But if my "feelings" are right you could not trace anything reliably for more then one transaction.

Your "feelings" are unreliable.

[Kprawn]

What happens with Transaction Visualization software once Bitcoin mixers are used.  .... I doubt that this software can follow any coins that went through these services. Yes the authorities can

subpoena these services to release the data on these transactions, but there are no guarantees that these services will be in the same country where this crime has been reported. The process to get

this information is costly and these hackers use several mixers to hide their tracks. 

[BillyBobZorton]

What happens with Transaction Visualization software once Bitcoin mixers are used.  .... I doubt that this software can follow any coins that went through these services. Yes the authorities can

subpoena these services to release the data on these transactions, but there are no guarantees that these services will be in the same country where this crime has been reported. The process to get

this information is costly and these hackers use several mixers to hide their tracks. 

Yeah nowadays there are mixers like heelix which can give you clean coins and and use a randomization pattern and delay of transactions to make a complete clusterfuck when it comes to trying to trace transactions. If hacker is smart he will use that and his trace will be cleared.

[avision]

Not sure what you're trying to say here.  Tracing any bitcoins through addresses is possible given enough computing power and good enough analysis software.  Attaching identities to any of those addresses requires that the entity doing the tracing has access to a list of addresses for which they know the owner.  Then once traced bitcoins pass through such an address, the entity doing the tracing can approach that owner and ask them who they got the bitcoins from.  They can then approach that sender and ask who they got the bitcoins from, and so on until they trace back to the beginning.

Well but transactions only record "how much" btc where moved not "which" bitcoins. So if A and B give C a bitcoin each - C has now two btc. If C gives D a bitcoin there is no way i could say that this bitcoin D now has came from A or B - it could originate from both - A or B. That is the point where in my eyes it should get impossible to do a solid analysis.

Forward it is the same: A and B give C a btc each. C now has two bitcoins. C gives D a bitcoin. At this moment i do not know if C gave D the btc from A or the one from B. Atleast if i look at the protocol it should not be possible to identify D`s btc. Because in the transaction most importantly two things are checked - do i have the private key to sign the transaction - and if the sum of the future transactions from and to this address enables me to send amount X of btc to another address.

You can ofcourse look if a big amount of btc comes back to a small number of wallets/addresses later. But that is mostly monitoring conspicuous values not realy tracing individual flows.

EDIT:
Ok i might have missed something - in an outgoing transaction .. do i specify which incoming transaction is used to "spend" my btc?
So in this case A and B give a btc to C - C now has two btc which he can spend. If C now gives D a bitcoin - does C specify in the transaction WHICH transaction(s) he uses as input to give D the btc? And is this probably transparent in the blockchain? That would ofcourse change how i have to think about the whole picture.

[poncom]

Not sure what you're trying to say here.  Tracing any bitcoins through addresses is possible given enough computing power and good enough analysis software.  Attaching identities to any of those addresses requires that the entity doing the tracing has access to a list of addresses for which they know the owner.  Then once traced bitcoins pass through such an address, the entity doing the tracing can approach that owner and ask them who they got the bitcoins from.  They can then approach that sender and ask who they got the bitcoins from, and so on until they trace back to the beginning.

Well but transactions only record "how much" btc where moved not "which" bitcoins. So if A and B give C a bitcoin each - C has now two btc. If C gives D a bitcoin there is no way i could say that this bitcoin D now has came from A or B - it could originate from both - A or B. That is the point where in my eyes it should get impossible to do a solid analysis.

Forward it is the same: A and B give C a btc each. C now has two bitcoins. C gives D a bitcoin. At this moment i do not know if C gave D the btc from A or the one from B. Atleast if i look at the protocol it should not be possible to identify D`s btc. Because in the transaction most importantly two things are checked - do i have the private key to sign the transaction - and if the sum of the future transactions from and to this address enables me to send amount X of btc to another address.

Blockchain.info and other explorers use a system called taint analysis to determine how closely the coins in one address are linked to the coins in another address. If one address A sent coins to another unused address B then the coins in address B have 100% taint from the coins in address A.

If one address C sent address D the same amount of coins that it address D was already holding then the coins in address D have 50% taint from the coins in address C.

https://blockchain.info/taint/3AbixYB8q3hHuAkFWSxUnTtqncFgRFYGDb

[Soros Shorts]

EDIT:
Ok i might have missed something - in an outgoing transaction .. do i specify which incoming transaction is used to "spend" my btc?
So in this case A and B give a btc to C - C now has two btc which he can spend. If C now gives D a bitcoin - does C specify in the transaction WHICH transaction(s) he uses as input to give D the btc? And is this probably transparent in the blockchain? That would ofcourse change how i have to think about the whole picture.

Yes, in an outgoing transaction you specify the inputs. This is usually done automatically by your wallet software. However, if for example, you enable the Coin Control feature of Bitcoin Core, you would be able to explicitly specify which inputs are used for your outgoing transaction.

[thejaytiesto]

EDIT:
Ok i might have missed something - in an outgoing transaction .. do i specify which incoming transaction is used to "spend" my btc?
So in this case A and B give a btc to C - C now has two btc which he can spend. If C now gives D a bitcoin - does C specify in the transaction WHICH transaction(s) he uses as input to give D the btc? And is this probably transparent in the blockchain? That would ofcourse change how i have to think about the whole picture.

Yes, in an outgoing transaction you specify the inputs. This is usually done automatically by your wallet software. However, if for example, you enable the Coin Control feature of Bitcoin Core, you would be able to explicitly specify which inputs are used for your outgoing transaction.

I use coin control all the time but its very annoying and not user friendly. I hope in the future they can figure out a way to automatically mix the coins so you don't have to worry about coin control and taking into account inputs and outputs otherwise we will never reach mainstream usage.

[DannyHamilton]

Well but transactions only record "how much" btc where moved not "which" bitcoins.

That is completely false.  Did you even read what I wrote?

Transactions do not record "how much" BTC were moved.  They ONLY record "which" unspent transaction outputs are being spent, and which new unspent outputs are being created.

So if A and B give C a bitcoin each - C has now two btc. If C gives D a bitcoin there is no way i could say that this bitcoin D now has came from A or B - it could originate from both - A or B.

Lets look at an example...

• Alan sends Carl 1 BTC in output 1 of transaction XYZ
• Bob sends Carl 1 BTC in output 2 of transaction UVW
• Carl now has control over 2 BTC
• More specifically Carl has the private key that can provide the required signature to spend either (or both) of output 1 of transaction and output 2 of transaction UVW
• Carl sends 1 BTC to Dennis with transaction RST
• Which BTC does Dennis have?

There are 3 possibilities when Carl created his transaction, and properly written visualization software should be able to handle all 3.

Possibility 1
Carl built a transaction RST that spent output 1 of transaction XYZ as an input, and which created a new output 0 valued at 1 BTC encumbered with a spending requirement that a signature generated with a private key that only Dennis has access to be provided.
In this case it is clear that the bitcoin received by Dennis (to the extent that bitcoins exist) is the same bitcoin that was originally sent by Alan.

Possibility 2
Carl built a transaction RST that spent output 2 of transaction UVW as an input, and created a new output 0 valued at 1 BTC encumbered with a spending requirement that a signature generated with a private key that only Dennis has access to is provided.
In this case it is clear that the bitcoin received by Dennis (to the extent that bitcoins exist) is the same bitcoin that was originally sent by Bob.

Possibility 3
Carl built a transaction RST that spent BOTH output 1 of transaction XYZ AND output 2 of transaction UVW as an inputs.  The transaction was therefore provided with 2 BTC of value. Carl created 2 new outputs in his transaction. Output 0 valued at 1 BTC is encumbered with a spending requirement that a signature generated with a private key that only Dennis has access to is provided. Output 1 valued at 0.99 BTC is encumbered with a spending requirement that a signature generated with a private key that only Carl has access to is provided. The remaining 0.01 BTC is left unassigned to any output.  This 0.01 BTC is considered by the protocol to be a "transaction fee", and the miner that confirms the transaction in a block is entitled to assign this 0.01 BTC to himself.

In possibility 3, 1 BTC was sent to Dennis, 0.99 BTC of "change" was sent back to Carl, and a fee of 0.01 BTC was paid.  Half of each of those values was from each of the two inputs supplied. So:

• 0.5 BTC of the 1 BTC output received by Dennis is from Alan
• 0.5 BTC of the 1 BTC output received by Dennis is from Bob
• 0.495 BTC of the 0.99 BTC output that Carl sent to himself is from Alan
• 0.495 BTC of the 0.99 BTC output that Carl sent to himself is from Bob
• 0.005 BTC of the 0.01 BTC fee received by the miner is from Alan
• 0.005 BTC of the 0.01 BTC fee received by the miner is from Bob

Forward it is the same: A and B give C a btc each. C now has two bitcoins. C gives D a bitcoin. At this moment i do not know if C gave D the btc from A or the one from B.

Of course you do.  Just look at the transaction.  The transaction will specify which of the received outputs was listed as an input to the transaction.  It is possible that the transaction spends BOTH of the received 1 BTC outputs. In that case, each new output will have received half its value from each input.

Atleast if i look at the protocol it should not be possible to identify D`s btc.

Have you actually looked at the protocol? Or are you just guessing how you think it might work and then assuming that your guess is right?

Because in the transaction most importantly two things are checked - do i have the private key to sign the transaction - and if the sum of the future transactions from and to this address enables me to send amount X of btc to another address.

Nope. Nope. Nope. Nope.

First of all, there are more than two important things that are checked.  Second of all, there is no check against "the sum of the future transactions from and to this address".

There is a check that the signatures are valid.
There is a check that all the outputs listed in the transaction are not spent yet (that they are still in the UTXO).
There is a check that the sum of the values of the transaction's outputs does not exceed the sum of the values of the transaction's inputs.
There is a check that all the scripts in the transaction are valid.
There are additional checks, but those 4 all apply to this discussion we are having.

EDIT:
Ok i might have missed something - in an outgoing transaction .. do i specify which incoming transaction is used to "spend" my btc?

Yes.  Or more specifically, you specify exactly which transaction output is being spent (since a single transaction can, and often does, have more than 1 output).

So in this case A and B give a btc to C - C now has two btc which he can spend.

Actually, he has 2 distinct and separate unspent transaction outputs that he can spend.

If C now gives D a bitcoin - does C specify in the transaction WHICH transaction(s) he uses as input to give D the btc?

Yes.  More specifically, he specifies WHICH transaction outputs he uses as input to supply value to the transaction. That transaction then assigns that value to one or more new outputs, at least one of which requires a signature from D.

And is this probably transparent in the blockchain? That would ofcourse change how i have to think about the whole picture.

That's what I keep telling you.