Validity checklist of transactions consist of following items:
These messages hold a single transaction.
Check syntactic correctness
Make sure neither in or out lists are empty
Size in bytes <= MAX_BLOCK_SIZE
Each output value, as well as the total, must be in legal money range
Make sure none of the inputs have hash=0, n=-1 (coinbase transactions)
Check that nLockTime <= INT_MAX[1], size in bytes >= 100[2], and sig opcount <= 2[3]
Reject "nonstandard" transactions: scriptSig doing anything other than pushing numbers on the stack, or scriptPubkey not matching the two usual forms[4]
Reject if we already have matching tx in the pool, or in a block in the main branch
For each input, if the referenced output exists in any other tx in the pool, reject this transaction.[5]
For each input, look in the main branch and the transaction pool to find the referenced output transaction. If the output transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions, if a matching transaction is not in there already.
For each input, if the referenced output transaction is coinbase (i.e. only 1 input, with hash=0, n=-1), it must have at least COINBASE_MATURITY (100) confirmations; else reject this transaction
For each input, if the referenced output does not exist (e.g. never existed or has already been spent), reject this transaction[6]
Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range
Reject if the sum of input values < sum of output values
Reject if transaction fee (defined as sum of input values minus sum of output values) would be too low to get into an empty block
Verify the scriptPubKey accepts for each input; reject if any are bad
Add to transaction pool[7]
"Add to wallet if mine"
Relay transaction to peers
For each orphan transaction that uses this one as one of its inputs, run all these steps (including this one) recursively on that orphan
Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a script. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes.
Transaction script organization
Endianity weirdness causes:
Some number in form of Variable-length integer, some in little endian form
Note: Hashes in Merkle Tree displayed in the Block Explorer are of little-endian notation. For some implementations and calculations, the bits need to be reversed before they are hashed, and again after the hashing operation.
Few notes about transactions and validation:
Structure
Transaction structure is following:
More info on transaction structure
Validation
Validity checklist of transactions consist of following items: These messages hold a single transaction.
(in more info link is a similar checklist for blocks as well) More info on validation
Bitcoin transaction script
Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a script. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. Transaction script organization
Endianity weirdness causes:
Some number in form of Variable-length integer, some in little endian form
More on variable length int
Note: Hashes in Merkle Tree displayed in the Block Explorer are of little-endian notation. For some implementations and calculations, the bits need to be reversed before they are hashed, and again after the hashing operation.
More info on Merkle tree
Common Data structures
List of common data structures in bitcoin block and transaction and its documentation: DATA STRUCTURES