How do previous transactions work?

Question

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.

Answer 1

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).

Answer 2

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.