Telling apart incoming and outgoing transactions

[gerbilboy]

Hi folks, I'm working on a small project which requires me to get all transaction data for an address and separate the TX's into incoming (receiving), and outgoing (sending).

To get the TX's, I'm using the API at https://www.blocktrail.com/api/docs#api_data. However, I noticed that when getting the TX's they are not separated by incoming and outgoing, so I had to devise some kind of sorting algorithm to separate them.

I came up with this:

Assuming we are looking at the transactions in/out of address X.
Assuming that an address that is not X, is "foreign"

A TX is "sent" if there is no foreign addresses in the inputs.
A TX is "received" if X doesn't appear in the inputs.

This seems to be working for the most part, but I'm getting some transactions that don't fall into these categories. Clearly, there is still a lot for me to learn about bitcoin TX's.

Some examples of these 'weird' TXs:
3418d6bdc26f43aa0cce0bf3c07d0a91f2e052f520db1f0b244938d2b8b6ff7f
d6437de71f1b5a331eb728e64ff6a36eb48bcf224973e28359ef218a530a1e6c
7b0b9486c0df9692f6b038da2c647d94793d08a0252ea0c460ee77b38ed47d1f

It looks like the block explorer considers these all being "sent", but I've never seen transactions like these before. What are these? And does anyone have some better definitions for sent/received transactions?

Thank you

[AriBitcoin]

Transactions are both incoming and outgoing. They come from party A to party B. From party A's perspective, they are outgoing. For part B, they are incoming.

[gerbilboy]

Transactions are both incoming and outgoing. They come from party A to party B. From party A's perspective, they are outgoing. For part B, they are incoming.

So, from the point of view of the party with address X, for whom I'm obtaining the TX's for, is the following true?

A TX is "received" if X doesn't appear in the TX's inputs.

A TX is "sent" if the TX is not "received"

Thanks for the reply

[colatkinson]

A transaction can have inputs signed by multiple keys--this is the concept behind hierarchical deterministic (HD) wallets, among others.

Bitcoin inputs and outputs are not just sent to addresses, they are controlled by scripts. Outputs should generally conform to standard script formats (P2PKH, P2SH, etc.), and inputs contain instructions to unlock them. Saying that value is sent to an address is essentially shorthand for saying, "This transaction has an output with a script that can be unlocked by a signature for this public key."

What I'm getting at is, which transactions are sending funds in which direction is complicated, and you won't be able to find a way to cover all your bases. The scheme you described should cover many cases, but it might be worth it to reevaluate this way of thinking about transactions if it's really that central to your application.

[DannyHamilton]

It is possible to send a transaction to yourself.

As such, perhaps you should use the following rules:

1. A transaction is "sent to one's self" if X appears in at least 1 output AND at least 1 input was previously received at X.

2. A transaction is "sent" to a new address if at least 1 output is sent somewhere that is NOT X AND at least 1 input was previously received at X.

3. A transaction is "received" at X if X appears in at least 1 output AND at least 1 input was previously received somewhere other than X.

Keeping in mind that it is possible for a transaction to be any one, any two, OR all three of the above simultaneously.

So...
A single transaction can be "sent".
A single transaction can be "received".
A single transaction can be "sent to one's self".
A single transaction can be "sent" AND "sent to one's self".
A single transaction can be "sent to one's self" AND "received".
A single transaction can be "sent" AND "received" AND "sent to one's self"

[gerbilboy]

Very helpful responses, thank you!