<p>No, Bitcoin transactions cannot be cleanly projected on a single &quot;from address&quot; or a single &quot;to address&quot;. Bitcoin can facilitate many payments in a single transaction and there may be multiple senders and usually are multiple receivers.</p>
<p>Even in a simple transaction where one user pays another user, the sender may use multiple inputs, and almost always will assign a change output to themselves. Thus, there is one sender (or more) and two receivers.</p>
<p>Nothing stops multiple users to create a transaction together. E.g. in a PayJoin transaction, the receiver contributes an input to a transaction that pays themselves, thus making it two senders, and one or two receivers (depending on whether there is change).</p>
<p>Two users may also join to make separate payments in one transaction. In a so-called CoinJoin transaction, they each are contributing their own inputs and assigning some funds to receivers and sending change back to themselves. So you might for example have two senders and four receivers.</p>
<p>The challenge gets a whole new dimension when you think about how custodial services work. When you e.g. send funds from an online wallet service or brokerage, the service will often batch dozens of payments/withdrawals together and pay them all from their omnibus wallet. The initiators of the payments and withdrawals do not control any of the addresses that fund the transaction, but are &quot;senders&quot; in the sense that they mandated the payments. The custodian is the actual sender, but may not know who any of the receivers are and is only executing payments on behalf of customers. E.g. sending to any of the &quot;from&quot; addresses of the transaction would likely credit some random user of the service which is neither the service or any of the senders.</p>
<p><strong>There is no such thing as a &quot;from&quot; address in a bitcoin transaction, and you can usually not distinguish whether an output goes back to the sender or to a receiver.</strong></p>
<p>I would suggest that you assume a general case of multiple senders and multiple receivers for each transaction in your model, and track account-based cryptocurrencies as the special case of a single sender and single receiver. Note that even for account-based currencies, a lot of smart contracts also allow sending to multiple recipients in one transaction.</p>

CC BY-SA 4.0
2021-05-27T07:21:18.123Z
Is there a resource out there with blockchain processing algorithms?
Mike M
CC BY-SA 4.0
2021-05-27T12:08:57.187Z
Well, there are a bunch of opensource libraries and wallets that do "blockchain processing", but it's hard to answer such a general question.
Murch
CC BY-SA 4.0
2021-05-26T15:04:06.227Z
2021-05-27T12:33:05.560Z
2021-05-27T12:33:05.560Z
Murch
<p>I am working on a project where we need to get the &quot;from&quot; and &quot;to&quot; address for every transaction across a number of cryptocurrencies. In account-based currencies, this is pretty straightforward, but in UTXO-based it's not. Are there known algorithms that &quot;normalize&quot; between the two?</p>

<utxo><payment><tracking><account-to-account>
Is it possible to assign a single "from" and a single "to" address to Bitcoin transactions?
Mike M
# Is it possible to assign a single "from" and a single "to" address to Bitcoin transactions?

(Asked by: username_0 on 2021-05-11)

I am working on a project where we need to get the "from" and "to" address for every transaction across a number of cryptocurrencies. In account-based currencies, this is pretty straightforward, but in UTXO-based it's not. Are there known algorithms that "normalize" between the two?

**Tags:** utxo, payment, tracking, account-to-account


---

## 1 answers

### Answer by username_1 on 2021-05-26. Score: 5 | Accepted answer

No, Bitcoin transactions cannot be cleanly projected on a single "from address" or a single "to address". Bitcoin can facilitate many payments in a single transaction and there may be multiple senders and usually are multiple receivers.

Even in a simple transaction where one user pays another user, the sender may use multiple inputs, and almost always will assign a change output to themselves. Thus, there is one sender (or more) and two receivers.

Nothing stops multiple users to create a transaction together. E.g. in a PayJoin transaction, the receiver contributes an input to a transaction that pays themselves, thus making it two senders, and one or two receivers (depending on whether there is change).

Two users may also join to make separate payments in one transaction. In a so-called CoinJoin transaction, they each are contributing their own inputs and assigning some funds to receivers and sending change back to themselves. So you might for example have two senders and four receivers.

The challenge gets a whole new dimension when you think about how custodial services work. When you e.g. send funds from an online wallet service or brokerage, the service will often batch dozens of payments/withdrawals together and pay them all from their omnibus wallet. The initiators of the payments and withdrawals do not control any of the addresses that fund the transaction, but are "senders" in the sense that they mandated the payments. The custodian is the actual sender, but may not know who any of the receivers are and is only executing payments on behalf of customers. E.g. sending to any of the "from" addresses of the transaction would likely credit some random user of the service which is neither the service or any of the senders.

**There is no such thing as a "from" address in a bitcoin transaction, and you can usually not distinguish whether an output goes back to the sender or to a receiver.**

I would suggest that you assume a general case of multiple senders and multiple receivers for each transaction in your model, and track account-based cryptocurrencies as the special case of a single sender and single receiver. Note that even for account-based currencies, a lot of smart contracts also allow sending to multiple recipients in one transaction.

> **Comments:**
> **username_0**: Is there a resource out there with blockchain processing algorithms?  
> **username_1**: Well, there are a bunch of opensource libraries and wallets that do "blockchain processing", but it's hard to answer such a general question.  

---

