A transaction has at least one input and two outputs which are measured in amounts of bitcoin. The sum of the input bitcoint amout must equal the sum of the output bitcoin amounts.
An input is always refers to an output of a prior transaction that and was not used in another transaction.
One of the outputs is used to pay the transaction fee. This output has the number 0. The transaction fee is paid to the miner who puts the transaction into a block.
An output also has a bitcoin address which is created from the recepient's public key.
All transactions are recorded in blocks that are stored in the blockchain.
A transaction can not be reversed.
Apparently, a transaction allows to store 80 bytes of user-data along with it.
The first transaction in a block is special: it starts a new coin which is owned by the creator of the block.
Every transaction gets inputs, which refer to previous outputs being spent. Every input has the txid and the signature to prove that it is allowed, plus an amount and script in every output.
Parts of a transaction
A (non coinbase-) transaction consists of
version
inputs
outputs
locktime
A transaction is prefixed by a four byte transaction version number.
This number indicates which set of rules to validate it to.
Transaction collections
Two transaction collections:
The transaction pool is (unordered) set of transactions that are not in blocks in the main chain, but for which we have input transactions.
The orphan transactions are transactions that cant't go into the pool due to missing input transactions
Transaction chain
A Bitcoin client might give you the impression that Bitcoins (or Satoshis) are transferred from one wallet to another. However, this is not really the case.
In reality, Bitcoins/Satoshis move from one transaction to another.
A transaction spends some or all of the satoshies that were received in the previous or earlier transaction.
Transaction identification
Transactions are identified by a 64-digit hexadecimal hash called a transaction identifier (txid).
The hash is calculated as SHA-256(transaction-data). Thus, it is based on both the coins being spent and on who will be able to spend the results of the transaction.
Outputs are tied to such a txid.
Signatures
Signatures don't describe what the transaction is doing, so they are not part of the transaction.
They are used to prove that the transaction is authorized by the previous owners of the coins.
Although signatures are not part of the transaction, they are part of the transaction hash.
Transaction fees
Transactions are not free: it costs bitcoins. Otherwise, the whole bitcoin network would be spammed with transactions.
The fee is credited to the miner who mined the block that contains the transactions.
The amount of the fee is the difference between the input and the output of a transaction.
Coinbase transaction
Aka generation transaction.
A coinbase transaction can only be created by a miner.
A coinbase transaction collects and spends the block reward which consists of a block subsidy and transaction fees paid by the transactions stored in this block.
A coinbase transaction's UTXO cannot be spent (that is: used as an input) for at least 100 blocks.
Thus, a miner is prevented from spending the transaction fees and block rewards from a block that may later be determined to be stale.
P2PKH transactions
The most common transaction type is the Pay-to-public-key-hash (P2PKH).
P2PKH lets someone (Alice) spend satoshis to a typical Bitcoin address. The recipient (Bob) can then further spend those satoshis using a simple cryptographic key pair.
Bob must first create a public/private key pair to make it possible for Alice to send him some satoshis. Bitcoin uses ECDSA for that.
Bob then creates a cryptographical hash of the public key (pubkey).
Bob sends the pubkey's hash to Alice. This hashes usually are encoded as Bitcoin addresses.
Now that Alice has Bob's address, she can create the transaction.
The (P2PKH-)transaction output contains a permission for everyone that controls Bob's previously generated private key.
These instructions are called pubkey script or scriptPubKey.
Alice broadcasts the transaction for addition to the blockchain.
The transaction is recognized as an unspent transaction output (UTXO). Bob's wallet displays the amount of this UTXO as spendable amount.
Later, Bob decides to spend some of this amount. So, he creates a hash of Alice's transaction and her corresponding output number. He has also to create a signature script (scriptSigs).
lock_time parameter
A transaction contains a lock_time parameter. If is set to a non zero value, it indicates that miners should not publish the transaction until the specified time.
Essentially, this ensures that the transaction is invalid before either a specific block number or specific point in time.
Such a transaction is already prepared and can be executed (spent) in the future.
This lock_time feature is used, for example, for micro payments.
Transaction limits
A transaction is at least 250 bytes. (The average is ca. 527 bytes)
Because the block size is limited to 1 MB, there can be at most 4000 transactions in a block.
Since a new block is generated approximately all 10 Minuts, there can maximally be at most 7 transactions per second.
In perspective, Visa is allegedly handling 2000 transactions per second with 10000 transactions per second in peak hours.
(Cf Bitcoin and Cryptocurrency Technologies, p. 96)