Transactions

The previous pages covered blocks. This section covers transactions, the contents of those blocks.

What a transaction is

A transaction consumes existing coins and creates new ones. It names the coins being spent, proves that the spender is authorized to spend them, and defines the outputs that replace them. The consumed coins are removed from the ledger and the new outputs are added.

The network does not store account balances, so a transaction never updates a balance. The reasoning behind this design is covered in the UTXO model.

Inputs: what is being spent

Each input points at exactly one coin and proves the right to move it.

• The outpoint names the coin. It is a pair: the id of the transaction that created the coin, and the index of the output within that transaction. Together they uniquely identify one coin in the UTXO set.
• The unlocking script is the proof. For an ordinary payment this is a Schnorr signature. For a pay-to-script-hash coin it also carries the redeem script the coin was locked to.
• An input spends its coin in full. Partial spends are not possible, so paying a small amount out of a large coin produces a change output.

Outputs: what is being made

Each output is a new coin, and a coin is an amount plus the rule for spending it.

• The value is an integer in sompi. The protocol has no fractional amounts; KAS is a display unit applied by wallets and applications.
• The locking script decides who can spend it next. It is derived from the recipient’s address, and it is the only condition protecting the coin. The lock types in use across the network are charted at output script classes.
• Since Toccata an output can also carry a covenant binding. That is how the base layer enforces rules about what the next transaction may do with the coin. See Programmability.

What else a transaction carries

A short list of fields wraps the two sides:

• A version. Zero is the original layout and still valid for any ordinary payment. One arrived with Toccata and is what covenant bindings and priced script execution need.
• A lock time, which sets the earliest point the transaction may be included - either a minimum DAA score or a wall-clock timestamp.
• A payload, an arbitrary data field enabled for ordinary transactions at Crescendo.

A transaction has no fee field, sender field, or balance field. The fee is the difference between total input value and total output value. The sender is implied by whoever satisfies the input locks. The full object model - every field, and the coin record a node has to supply alongside it - is covered in Transaction Model.

The transaction id

A transaction’s id is a hash over it with the signature scripts and payload left out. Its hash covers everything.

Because signatures are excluded from the id, the id is fixed before anyone signs. Several parties can agree on a transaction, pass it around, and each add a signature without changing the id they agreed on. This is what makes partially signed transaction workflows possible.

What a signature covers

The default signing mode commits to every input and every output in the transaction. Any modification invalidates the signature, so no party - including the miner that includes it - can alter a signed transaction in transit.

The rest of this section

• UTXO Model - why the ledger is a set of coins rather than a table of balances, and why that fits a blockDAG.
• Transaction Model - the objects and fields a transaction is built from, and the coin record a node has to supply to check it.
• Fees & Mass - what a transaction costs, and why it is priced by mass instead of by size.
• The Mempool - where transactions wait, and how miners choose among them.
• Throughput - how much the network can carry, and what limits it.