How does the mechanism work?

A previous-output reference identifies both the earlier transaction and the output within it. The input is not a statement such as “take money from this address”. Validation resolves the referenced output and checks whether the transaction may spend it.

An output contains an amount and a locking script. That script defines spending conditions. Address-based interfaces help construct common scripts, but not every valid output is best understood as a payment to a person.

Transaction order is not a list of people who approved the payment. Inputs identify spendable records, while outputs state new conditions; either side can include several entries controlled by the same participant. Conversely, a condition can involve several participants behind a single output. Avoid reading every output as a separate person or every input as a distinct sender. Inspect the construction before assigning those labels. The protocol’s accounting can be completely explicit while the real-world relationship between participants remains unknown. This is one reason a transaction graph is a record of spending links rather than a verified directory of identities.

Inputs reference old outputs; outputs set new conditionsEach input points back to a specific previous output. New outputs state amounts and spending conditions. The fee is the difference between the input and output sums.Input: previous outputCheck spending conditionsNew amounts + conditionsInput sum - output sum = fee
An input references the past; an output sets conditions for a future spend.

What would you see in an example?

Imagine combining an output from an earlier receipt with another output from a separate receipt. Both are inputs to the new transaction. You create a recipient output and a change output. Add the input amounts, then add the output amounts. The difference is the fee; there is no separate fee output paid to a miner address.

What does a minimal input actually identify?

The previous-output reference, often called an outpoint, contains a 32-byte transaction identifier and a 4-byte output index. Together these occupy 36 bytes before the other input fields. The input also has a script field and a sequence number; witness data is represented separately when the transaction uses the witness serialization. These fields do different jobs even when an interface hides them.

For an invented worked example, let the referenced outputs contain 80,000 and 40,000 satoshis. The transaction creates a 100,000-satoshi recipient output and a 19,200-satoshi change output. Input sum is 120,000; output sum is 119,200. Their difference, 800 satoshis, is the fee. That difference is derived during validation rather than read from a dedicated fee field.

A new output encodes its amount as an 8-byte integer measured in satoshis, followed by a length-prefixed script. The 8-byte field does not mean arbitrary values are permitted. Validation applies monetary range and balance rules. A transaction that tries to create outputs worth more than its inputs cannot become valid through a high fee setting or a valid signature.

Follow validation in an order that exposes dependencies. Resolve each referenced output, obtain its amount and conditions, check the supplied authorisation, and calculate the totals. Some signature schemes also commit to information about the previous outputs. This is why a signer needs reliable input data and why a neat list of recipient addresses cannot substitute for the full transaction context.

Worked mechanism sequenceFor an invented worked example, let the referenced outputs contain 80,000 and 40,000 satoshis. The transaction creates a 100,000-satoshi recipient output and a 19,200-satoshi change output. Input sum is 120,000; output sum is 119,200. Their difference, 800 satoshis, is the fee. That difference is derived during validation rather than read from a dedicated fee field.Resolve 120,000 sat inputs119,200 sat output sum800 sat difference is fee
Follow the example in the text. Monetary amounts and fee rates are invented, not live observations.

Common misunderstandings

The transaction identifier is not an output identifier on its own. If a transaction created several outputs, the index selects which one is being spent. Index 0 identifies the first output; it does not stand for every output from that transaction.

The input does not repeat a trusted declaration of the money it contains in the ordinary transaction encoding. A validating node resolves that value from the referenced output. A dishonest display or a malformed transaction cannot create spendable value by asserting a larger input amount.

Check yourself

Where would you look for a transaction’s dedicated miner-fee output?

Reveal the answer

There is no required fee output. Calculate the difference between resolved input amounts and new output amounts. Miners may claim transaction fees through the block’s issuance transaction transaction.

What does this diagram leave out?

The diagram omits serialization details, locktime and specialised scripts. Signatures and witness data depend on the kind of output being spent. Changing transaction fields can affect which signatures remain valid, so a transaction is more than a list of addresses and amounts.