How does a transaction turn old outputs into new ones?

Where could you start with a real question?

Suppose a payment needs only part of an output you control. Read the UTXO model first, then follow inputs and outputs. Change explains the remainder; the fee guide shows why that remainder is smaller than a simple payment subtraction.

How should you connect these guides?

Use the transaction as a state transition: old outputs become spent, and new outputs become available under new conditions. The UTXO lesson establishes that model before inputs and outputs expose the record structure. Change and fee accounting then explain where the selected value goes. Follow this order if a balance display feels simpler than the underlying mechanism.

Script and timelocks add conditions to that transition. A valid signature is not always enough: the output may require several signatures or a delay. Read the complete condition before deciding which input data proves authority. The transaction must also have the right context and enough value to cover its new outputs.

The offline tools let you isolate arithmetic from signing. Select invented outputs in the builder, then compare the fee calculator’s units with the fees lesson. These tools use sample amounts and stated assumptions. They do not connect to a wallet, retrieve outputs or promise that an estimated size matches a finished transaction.

For a worked reading route, start with a payment that consumes an output larger than the recipient amount. Identify the input, subtract the recipient output and fee, and locate the new change output. Then ask what that change output will require when spent later. This closes the loop from receiving value to spending it again.

Where do the mechanisms come from?

Sources: Transaction developer reference; Segregated witness specification.