# How Bitcoin’s Blockchain Works: Transactions, Proof of Work and Finality

*Bitcoin is not a line of balances periodically certified by miners. It is a replicated state transition in which independently operated nodes verify spending conditions, blocks commit to ordered transactions, and proof of work helps valid branches converge.*

- Research question: What happens between a wallet creating a transaction and a full node treating it as confirmed, and what can still change afterward?
- Canonical: https://degreesofsatoshi.com/history/how-bitcoin-blockchain-works/
- Published 2026-08-09 · last reviewed 2026-08-09 · covers 2008-10-31/2026-08-09
- Author: Degrees of Satoshi editorial project (https://degreesofsatoshi.com/authors/degrees-of-satoshi-editorial-project/)
- Citation files: https://degreesofsatoshi.com/history/how-bitcoin-blockchain-works/citation.bib · https://degreesofsatoshi.com/history/how-bitcoin-blockchain-works/citation.ris · https://degreesofsatoshi.com/history/how-bitcoin-blockchain-works/citation.csl.json
- Evidence data: https://degreesofsatoshi.com/history/how-bitcoin-blockchain-works/evidence.json

## Key finding

Miners propose ordering and attach proof of work, but full nodes decide whether a block satisfies consensus. A transaction becomes increasingly buried under accumulated work while remaining subject to probabilistic reorganization rather than absolute protocol finality. ([Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf); [Bitcoin Core validation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/validation.cpp); [Proof-of-work and difficulty adjustment](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/pow.cpp))

## Verified record

| Stage | Protocol object or rule | What is independently checked | Important distinction | Source |
| --- | --- | --- | --- | --- |
| Transaction construction | Inputs identify prior outpoints; outputs specify satoshis and scripts | Values, authorization data, lock conditions, and absence of duplicate inputs | Private keys can authorize signature-based spends; they do not contain coins | mechanics-transaction-code,mechanics-tx-verification |
| Mempool admission | A node’s local set of unconfirmed transactions | Consensus prerequisites plus local fee, standardness, conflict, and resource policy | There is no single global mempool | [Bitcoin Core validation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/validation.cpp) |
| Candidate block | Coinbase followed by selected transactions | Subsidy-plus-fee limit, dependencies, block limits, and transaction validity | Consensus does not require one transaction-selection algorithm | [Bitcoin Core validation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/validation.cpp) |
| Commitments | Header transaction Merkle root and SegWit witness commitment | Calculated roots must match committed values | The header root commits txids; witness data uses the BIP141 coinbase commitment | mechanics-bip141,mechanics-merkle-code |
| Block header | 80 bytes: version, previous hash, Merkle root, time, nBits, nonce | Parent relation, target encoding, time constraints, and header hash | The timestamp is miner supplied within consensus bounds | [Block-header primitives](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/primitives/block.h) |
| Proof of work | Double-SHA-256 header hash at or below target | Target is valid for the height and proof satisfies it | Difficulty describes the target; proof of work does not validate scripts | [Proof-of-work and difficulty adjustment](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/pow.cpp) |
| Chain selection | Valid branch with greatest accumulated chainwork | All blocks on the candidate branch must pass consensus | ‘Longest chain’ is shorthand and can be wrong when work per block differs | [Bitcoin Core validation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/validation.cpp) |
| Confirmations and reorgs | Active-chain depth above the containing block | A competing valid branch can cause disconnect and connect operations | Confirmations provide probabilistic burial, not absolute finality | [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) |

## Bitcoin tracks spendable outputs rather than protocol-level accounts {#utxos-not-account-balances}

A Bitcoin transaction output contains an integer value in satoshis and a script that states the conditions for spending it. While that output remains unspent, it belongs to the node’s UTXO set. A later transaction input references the earlier transaction identifier and output index—often written `txid:vout`—and supplies the witness or script data needed to satisfy the condition. Validation consumes an output in full; any remainder must be deliberately recreated as change.

Wallet interfaces sum relevant UTXOs and display the result as a balance, but an address or wallet balance is not the primitive maintained by consensus. A private key likewise does not store bitcoin. It enables a wallet to produce a signature accepted by a particular spending condition. This model matters for history and forensics: one payment can consume several earlier outputs and create several new ones, and apparent ‘movement between addresses’ is an interpretation of that graph rather than an account transfer recorded by the protocol.

Sources: [Bitcoin transaction primitives](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/primitives/transaction.h); [Transaction consensus verification](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/consensus/tx_verify.cpp)

## A wallet selects inputs, creates outputs, and signs the relevant commitment {#construct-sign-and-price-a-transaction}

To pay, a wallet selects enough UTXOs to cover recipient outputs and the intended fee, chooses scripts for the recipient and usually for change, and signs according to the input types and signature-hash rules. The fee is not a special output. It is the difference `sum(inputs) − sum(outputs)`, which a miner may collect through the block’s coinbase transaction. Values must remain within consensus ranges, and an ordinary transaction cannot create more output value than its available inputs.

Scripts allow more than a simple single-key payment. Current output types can commit to key hashes, witness programs, multisignature arrangements, timelocks, or Taproot conditions. The exact bytes covered by a signature depend on the spending path and signature-hash mode. A readable explainer can use a one-key example, but should not imply that every transaction reveals a public key in advance, uses the same witness structure, or authorizes all outputs in precisely the same way.

Sources: [Bitcoin transaction primitives](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/primitives/transaction.h); [Transaction consensus verification](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/consensus/tx_verify.cpp); [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf); [BIP 141 — Segregated Witness](https://bips.dev/141/); [BIP 341 — Taproot](https://bips.dev/341/)

## Nodes validate before relay, and each node owns its mempool policy {#validation-policy-and-relay}

A wallet sends the serialized transaction to a node, which performs structural and contextual checks before accepting it into its mempool. The node verifies that referenced outputs exist and are available in its current view, values do not overflow or inflate supply, scripts and signatures succeed, and lock constraints are met. It also applies local policy covering standard forms, minimum fees, resource limits, ancestor relationships, and conflicts or replacements. Peers repeat their own checks rather than trusting the first node.

Consensus validity and relay policy are deliberately distinct. A transaction one node declines to store or forward can still be consensus-valid if a miner includes it in a valid block. There is also no authoritative network-wide mempool: nodes can see different transactions because of timing, connectivity, eviction, fee policy, replacement rules, or conflicting spends. An unconfirmed transaction is therefore a propagated proposal, not a reservation of an output or a promise of eventual confirmation.

Sources: [Transaction consensus verification](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/consensus/tx_verify.cpp); [Bitcoin Core validation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/validation.cpp); [BIP 113 — Median time-past](https://bips.dev/113/); [BIP 125 — Opt-in full replace-by-fee signaling](https://bips.dev/125/); [Bitcoin Core transaction policy documentation](https://github.com/bitcoin/bitcoin/tree/master/doc/policy)

## A miner assembles a candidate block and commits to its contents {#candidate-blocks-and-commitments}

A miner or block-template service selects transactions that fit consensus limits and whose dependencies can be satisfied in block order. Fee rate and package economics commonly influence selection, but Bitcoin consensus does not require a universal auction algorithm. The first transaction is the coinbase. It has a special input and creates outputs up to the permitted block subsidy plus the fees of included transactions; its output cannot be spent until it has matured for 100 blocks.

Transaction identifiers are arranged into a Merkle tree whose root enters the block header. Changing an included transaction changes its branch and therefore the root. SegWit requires an additional witness commitment: witness transaction identifiers form a separate Merkle root committed in a designated coinbase output, which is then indirectly committed by the ordinary transaction root. This nested construction is why it is imprecise to say that the header’s transaction Merkle root directly contains every witness byte.

Sources: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf); [Bitcoin transaction primitives](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/primitives/transaction.h); [Bitcoin Core validation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/validation.cpp); [Block-header primitives](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/primitives/block.h); [Merkle-root implementation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/consensus/merkle.cpp); [BIP 141 — Segregated Witness](https://bips.dev/141/)

## Proof of work commits an 80-byte header to a target {#header-proof-of-work-and-difficulty}

The serialized header contains version, the previous block hash, the transaction Merkle root, a timestamp, the compact target `nBits`, and a nonce. Miners vary the nonce and other mutable template data and repeatedly double-SHA-256 the header. A proof succeeds when the resulting hash, interpreted as a number under Bitcoin’s rules, is no greater than the target. Verification is inexpensive even though finding a qualifying hash is deliberately probabilistic and computationally costly.

The target is the consensus object; difficulty is a convenient ratio comparing it with a reference target. On mainnet, the target is recalculated every 2,016 blocks toward a two-week timespan, subject to adjustment bounds in the implementation. Ten minutes is therefore an average design target, not a schedule for the next block. Proof of work says that computation was committed to a header and its ancestry. It does not by itself prove transaction validity, authenticate a real-world fact, or guarantee that a miner followed relay policy.

Sources: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf); [Bitcoin Core validation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/validation.cpp); [Block-header primitives](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/primitives/block.h); [Proof-of-work and difficulty adjustment](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/pow.cpp); [Mainnet consensus parameters](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/kernel/chainparams.cpp)

## Receiving nodes verify the miner’s proposal before changing chainstate {#full-node-block-validation}

A full node checks the header, parent, proof of work, target, time rules, size and weight limits, transaction and witness commitments, coinbase form and reward, and every transaction’s scripts and state transition. It confirms that inputs refer to available UTXOs and that the block contains no prohibited double spend or excess creation. A block with immense proof of work is still rejected if one consensus check fails. Miners order valid candidates; they do not receive authority to rewrite the validation rules of unchanged nodes.

If the block is valid and belongs on the best available branch, the node connects it by removing spent outputs and adding newly created outputs to its UTXO database. It also updates indexes and removes confirmed or conflicting transactions from the local mempool as appropriate. The node’s accepted chain is thus the result of deterministic validation plus branch comparison. ‘Trust the blockchain’ is incomplete shorthand: the security property comes from independently enforced rules and accumulated work on a branch that passed them.

Sources: [Transaction consensus verification](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/consensus/tx_verify.cpp); [Bitcoin Core validation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/validation.cpp); [Proof-of-work and difficulty adjustment](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/pow.cpp); [Merkle-root implementation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/consensus/merkle.cpp); [BIP 141 — Segregated Witness](https://bips.dev/141/)

## Confirmations increase burial, but Bitcoin has no absolute finality flag {#confirmations-forks-and-reorganizations}

A transaction in the current tip’s block has one confirmation; every active-chain descendant adds another. Near-simultaneous valid blocks can give nodes different tips temporarily. Nodes compare valid branches by accumulated chainwork, not simply by counting blocks. When a branch with more work becomes available, a node can disconnect blocks from its former branch, reverse their UTXO changes, and connect the winning branch. This is a chain reorganization, not retroactive editing of a block’s bytes.

Transactions removed during a reorg may return to the local mempool if they remain valid and satisfy policy. A conflicting transaction confirmed on the winning branch may instead make them invalid. Confirmation counts can consequently decrease or return to zero. Greater depth normally makes reversal progressively more expensive and operationally unlikely, but the protocol never emits an irreversible-finality certificate. ‘Six confirmations’ is a widely used risk convention whose adequacy depends on transaction value, threat model, hash-power assumptions, and the recipient’s tolerance—not a consensus guarantee.

Sources: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf); [Bitcoin Core validation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/validation.cpp); [Proof-of-work and difficulty adjustment](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/pow.cpp)

## The chain proves protocol commitments, not every claim attached to them {#what-the-chain-can-and-cannot-prove}

A block timestamp is selected by its miner within validity constraints and should not be treated as a certified real-world instant. A transaction proves that its consensus spending conditions were satisfied; it does not prove the parties’ identities, the purpose of payment, delivery of goods, or legal ownership outside the protocol. Labels assigned to addresses by explorers and analysts are external evidence that can be useful but remain separate from block validation.

Simplified-payment-verification clients can check header proof of work and a Merkle path showing that a transaction was committed in a block, but they do not replay every script and UTXO transition as a full node does. Software defects and consensus upgrades introduce additional social and implementation risks distinct from routine reorganization probability. The technically accurate conclusion is bounded: Bitcoin makes a particular transaction history expensive to replace and independently auditable under shared rules; it does not turn every interpretation of that history into truth.

Sources: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf); [Bitcoin Core validation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/validation.cpp); [Block-header primitives](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/primitives/block.h); [BIP 113 — Median time-past](https://bips.dev/113/)

## Claims and their limits

- Bitcoin transactions consume identified previous outputs and create new outputs containing values and spending conditions. ([Bitcoin transaction primitives](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/primitives/transaction.h); [Transaction consensus verification](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/consensus/tx_verify.cpp))
- A block header contains version, previous-block hash, Merkle root, timestamp, compact target, and nonce. ([Block-header primitives](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/primitives/block.h))
- Under SegWit, witness data is committed through a witness Merkle root placed in the coinbase commitment structure. ([BIP 141 — Segregated Witness](https://bips.dev/141/); [Merkle-root implementation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/consensus/merkle.cpp))
- Bitcoin Core validates blocks and transactions before connecting their UTXO changes to chainstate. ([Bitcoin Core validation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/validation.cpp); [Transaction consensus verification](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/consensus/tx_verify.cpp))
- Bitcoin nodes compare valid branches using accumulated chainwork rather than block count alone. ([Bitcoin Core validation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/validation.cpp); [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf))
- Confirmations provide probabilistic economic settlement rather than absolute protocol finality. ([Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf); [Bitcoin Core validation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/validation.cpp))
- Replace-by-fee and standard transaction relay are policy behaviors distinct from base consensus validity. ([BIP 125 — Opt-in full replace-by-fee signaling](https://bips.dev/125/); [Bitcoin Core transaction policy documentation](https://github.com/bitcoin/bitcoin/tree/master/doc/policy))

## Caveats

- The walkthrough describes current mainnet concepts at a high level; exact validation paths depend on software version and transaction type.
- Mempool contents and policy are local. A node’s rejection from its mempool does not necessarily prove that a transaction would violate block consensus.
- The header transaction Merkle root commits transaction identifiers; SegWit witness bytes are committed through the separate BIP141 witness commitment.
- Ten minutes is a target average, not a guaranteed interval, and header timestamps are miner supplied within consensus constraints.
- The valid chain with greatest accumulated work is more precise than ‘the longest chain.’
- Coinbase outputs have a 100-block maturity rule; ordinary confirmed outputs should not be described as having the same consensus delay.
- Confirmation depth does not create absolute finality, and no universal confirmation count is safe for every threat model.
- On-chain data does not prove off-chain identity, beneficial ownership, legal purpose, or delivery of goods.

## Questions this dossier answers

### Does Bitcoin’s blockchain store account balances?

No protocol-level account balance is stored. Nodes maintain a set of unspent transaction outputs, each with a value and spending condition. Wallet software finds relevant UTXOs and sums them to display a familiar balance. ([Bitcoin transaction primitives](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/primitives/transaction.h); [Transaction consensus verification](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/consensus/tx_verify.cpp))

### Do miners decide whether a Bitcoin transaction is valid?

Miners choose transactions and propose an ordering in proof-of-work blocks, but independently operated full nodes verify every consensus rule. A node rejects a block with invalid scripts, unavailable inputs, excess issuance, or invalid proof of work regardless of who mined it. ([Transaction consensus verification](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/consensus/tx_verify.cpp); [Bitcoin Core validation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/validation.cpp); [Proof-of-work and difficulty adjustment](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/pow.cpp))

### What is a Bitcoin confirmation?

A transaction has one confirmation when its block is in the node’s active chain. Each valid descendant adds another, increasing the amount of accumulated work burying it. Confirmation is therefore chain depth, not a separate message sent by the miner. ([Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf); [Bitcoin Core validation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/validation.cpp); [Proof-of-work and difficulty adjustment](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/pow.cpp))

### Are six confirmations absolutely final?

No. Six is a widely used risk convention, not a consensus guarantee. A valid branch with greater accumulated work can reorganize blocks and reduce a transaction’s confirmation count; the appropriate threshold depends on value, threat model, and risk tolerance. ([Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf); [Bitcoin Core validation](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/validation.cpp); [Proof-of-work and difficulty adjustment](https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/pow.cpp))

## Sources

1. Bitcoin: A Peer-to-Peer Electronic Cash System — Satoshi Nakamoto, Bitcoin.org. https://bitcoin.org/bitcoin.pdf
2. Bitcoin transaction primitives, Bitcoin Core. https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/primitives/transaction.h
3. Transaction consensus verification, Bitcoin Core. https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/consensus/tx_verify.cpp
4. Bitcoin Core validation, Bitcoin Core. https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/validation.cpp
5. Block-header primitives, Bitcoin Core. https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/primitives/block.h
6. Merkle-root implementation, Bitcoin Core. https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/consensus/merkle.cpp
7. Proof-of-work and difficulty adjustment, Bitcoin Core. https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/pow.cpp
8. Mainnet consensus parameters, Bitcoin Core. https://github.com/bitcoin/bitcoin/blob/128456b62d5e38abea031f97f823d5b28aef9357/src/kernel/chainparams.cpp
9. BIP 141 — Segregated Witness, Bitcoin Improvement Proposals. https://bips.dev/141/
10. BIP 113 — Median time-past, Bitcoin Improvement Proposals. https://bips.dev/113/
11. BIP 125 — Opt-in full replace-by-fee signaling, Bitcoin Improvement Proposals. https://bips.dev/125/
12. BIP 341 — Taproot, Bitcoin Improvement Proposals. https://bips.dev/341/
13. Bitcoin Core transaction policy documentation, Bitcoin Core. https://github.com/bitcoin/bitcoin/tree/master/doc/policy

## Cite

Degrees of Satoshi editorial project. “How Bitcoin’s Blockchain Works: Transactions, Proof of Work and Finality.” Degrees of Satoshi, published 2026-08-09; last reviewed 2026-08-09. https://degreesofsatoshi.com/history/how-bitcoin-blockchain-works/

- HTML: https://degreesofsatoshi.com/history/how-bitcoin-blockchain-works/
- Markdown: https://degreesofsatoshi.com/history/how-bitcoin-blockchain-works/index.md
- Guide for agents: https://degreesofsatoshi.com/llms.txt