<p>Short answers: yes, yes, no.</p>

<p>The longer answer is that you should stop thinking in terms of accounts/addresses - they are irrelevant as they don't really exist at the protocol level (they're just a client-side abstraction in the wallet).</p>

<p>Bitcoin functions in terms of <strong>coins</strong>, very much like your physical wallet containing coins. Coins are produced and consumed by transactions.</p>

<p>Every coin has a value (between 0.00000000 and 21000000.00000000 BTC), and an address of its owner (that's a simplification, but it suffices for now).</p>

<p>Every transaction consumes one or more coins. This is done by referencing them explicitly (by stating the hash of the transaction that created it), and providing a signature (for each) that proves you are the owner. They are consumed entirely: they're either spent or unspent, there is no "withdrawing" or "crediting" of/to them.</p>

<p>Every transaction also produces one or more new coins, whose sum in value cannot be more than the value of the coins consumed by the transaction.</p>

<p>As transactions deal with complete coins all the time, this means we sometimes have leftovers that need to be returned. This is what change addresses are for. When you have a coin of value 3.1 BTC, and you want to pay me 1 BTC, you'll create a transaction with one input (consuming the 3.1 BTC coin), and two outputs (one 1 BTC coin to me, one 2.1 BTC coin to a possibly different address of yourself).</p>

<p>Even though the concept of "balance of an address" is well-defined (the sum of the value of all unspent coins assigned to that address), this concept does not exist at the protocol level. You always work with full coins, and arbitrary amounts that get added/subtracted from balances (though the value of those coins is arbitrary).</p>

CC BY-SA 3.0
2014-01-12T14:29:49.657Z
Aha, I see. So for example can I see on Blockchain.info the balance of an address down to the coin granularity?
Randomblue
CC BY-SA 3.0
2014-01-12T15:31:16.363Z
If you click on a particular transaction, you can see which of its outputs are spent or not. In general, the view that these block explorer like sites present is misleading, as they interpret the data to make it look like a balance/ledger system.
Pieter Wuille
CC BY-SA 3.0
2014-01-12T14:19:07.880Z
2014-01-12T14:19:07.880Z
Pieter Wuille
<p>In Bitcoin transactions you always have to specify where the coins came from. This even goes as far as not specifying how many coins an input feeds into the transaction, since the amount is specified in the previous output.</p>

<ol>
<li>This is the classical case in which you spend coins that you previously received. The hash of <code>T1</code> has to be specified in <code>T2</code> as well as the index of the output being claimed.</li>
<li>Since <code>T2</code> only spends the funds available from <code>T1</code>, regardless of how many other outputs are at the disposal of the address that is signing the transaction it will be valid, even if since its creation other outputs became available to the address. Transactions are self-contained to a certain degree.</li>
<li>Without knowing the output you want to claim, i.e., the tuple of previous transaction and index, you will not be able to create a valid transaction. Should the sending party however communicate the hash and index to you before broadcasting the transaction you'd indeed be able to create such <code>T2</code>.</li>
</ol>

CC BY-SA 3.0
2014-01-12T14:18:46.927Z
2014-01-12T14:18:46.927Z
cdecker
<p>I'm confused about the inclusion of the hash of the previous transaction in a transaction. Is it mandatory? Should it be the hash of the last <em>outbound</em> transaction? What if an unexpected transaction messes up the linked list? I have written specific scenarios below for which I am unsure about the behaviour.</p>

<ol>
<li><p>I have an account <code>A</code> for which its only transaction <code>T1</code> was receiving 1 BTC from some other account. If I want to spend my 1 BTC in a transaction <code>T2</code>, do I need to include the hash of the transaction <code>T1</code> in <code>T2</code>?</p></li>
<li><p>I have an account <code>B</code> which so far only received 1 BTC from a transaction <code>T1</code> and I want to spend the 1 BTC in a transaction <code>T2</code> referencing <code>T1</code>. But just before broadcasting <code>T2</code>, a transaction <code>T3</code> also referencing <code>T1</code> credits my account with 1 BTC. Will <code>T2</code> be accepted despite <code>T3</code> entering the blockchain before <code>T2</code>?</p></li>
<li><p>I have an account <code>C</code> to which someone will send 1 BTC tomorrow in a transaction <code>T1</code>. Is it possible to "pre-spend" the 1 BTC in a transaction <code>T2</code> without knowing the hash of <code>T1</code>? By pre-spend I mean that as soon as my account gets credited with the 1 BTC from <code>T1</code>, transaction <code>T2</code> can immediately also enter the blockchain.</p></li>
</ol>

<transactions>
How do previous transactions work?
Randomblue
# How do previous transactions work?

(Asked by: username_0 on 2014-01-12)

I'm confused about the inclusion of the hash of the previous transaction in a transaction. Is it mandatory? Should it be the hash of the last *outbound* transaction? What if an unexpected transaction messes up the linked list? I have written specific scenarios below for which I am unsure about the behaviour.

1. I have an account `A` for which its only transaction `T1` was receiving 1 BTC from some other account. If I want to spend my 1 BTC in a transaction `T2`, do I need to include the hash of the transaction `T1` in `T2`?
2. I have an account `B` which so far only received 1 BTC from a transaction `T1` and I want to spend the 1 BTC in a transaction `T2` referencing `T1`. But just before broadcasting `T2`, a transaction `T3` also referencing `T1` credits my account with 1 BTC. Will `T2` be accepted despite `T3` entering the blockchain before `T2`?
3. I have an account `C` to which someone will send 1 BTC tomorrow in a transaction `T1`. Is it possible to "pre-spend" the 1 BTC in a transaction `T2` without knowing the hash of `T1`? By pre-spend I mean that as soon as my account gets credited with the 1 BTC from `T1`, transaction `T2` can immediately also enter the blockchain.

**Tags:** transactions


---

## 2 answers

### Answer by username_1 on 2014-01-12. Score: 2 | Accepted answer

Short answers: yes, yes, no.

The longer answer is that you should stop thinking in terms of accounts/addresses - they are irrelevant as they don't really exist at the protocol level (they're just a client-side abstraction in the wallet).

Bitcoin functions in terms of **coins**, very much like your physical wallet containing coins. Coins are produced and consumed by transactions.

Every coin has a value (between 0.00000000 and 21000000.00000000 BTC), and an address of its owner (that's a simplification, but it suffices for now).

Every transaction consumes one or more coins. This is done by referencing them explicitly (by stating the hash of the transaction that created it), and providing a signature (for each) that proves you are the owner. They are consumed entirely: they're either spent or unspent, there is no "withdrawing" or "crediting" of/to them.

Every transaction also produces one or more new coins, whose sum in value cannot be more than the value of the coins consumed by the transaction.

As transactions deal with complete coins all the time, this means we sometimes have leftovers that need to be returned. This is what change addresses are for. When you have a coin of value 3.1 BTC, and you want to pay me 1 BTC, you'll create a transaction with one input (consuming the 3.1 BTC coin), and two outputs (one 1 BTC coin to me, one 2.1 BTC coin to a possibly different address of yourself).

Even though the concept of "balance of an address" is well-defined (the sum of the value of all unspent coins assigned to that address), this concept does not exist at the protocol level. You always work with full coins, and arbitrary amounts that get added/subtracted from balances (though the value of those coins is arbitrary).

> **Comments:**
> **username_0**: Aha, I see. So for example can I see on Blockchain.info the balance of an address down to the coin granularity?  
> **username_1**: If you click on a particular transaction, you can see which of its outputs are spent or not. In general, the view that these block explorer like sites present is misleading, as they interpret the data to make it look like a balance/ledger system.  

---

### Answer by username_2 on 2014-01-12. Score: 1

In Bitcoin transactions you always have to specify where the coins came from. This even goes as far as not specifying how many coins an input feeds into the transaction, since the amount is specified in the previous output.

1. This is the classical case in which you spend coins that you previously received. The hash of `T1` has to be specified in `T2` as well as the index of the output being claimed.
2. Since `T2` only spends the funds available from `T1`, regardless of how many other outputs are at the disposal of the address that is signing the transaction it will be valid, even if since its creation other outputs became available to the address. Transactions are self-contained to a certain degree.
3. Without knowing the output you want to claim, i.e., the tuple of previous transaction and index, you will not be able to create a valid transaction. Should the sending party however communicate the hash and index to you before broadcasting the transaction you'd indeed be able to create such `T2`.


---

