Three records that should never be confused
A trading strategy records what it intended to do. An exchange records what actually filled. Bitcoin records transfers between spending conditions on its own network. A reliable application reconciles these records rather than assuming that one proves the others.
For example, a bot submits a buy order, receives a partial fill and later requests a withdrawal. The order response does not prove that the full quantity was purchased, and the withdrawal request does not prove that the coins arrived.
Transactions spend outputs
Bitcoin tracks unspent transaction outputs, or UTXOs. A transaction consumes previous outputs and creates new ones. Its input total covers payments, change and the transaction fee.
Suppose a wallet spends a 0.012 BTC output to send 0.004 BTC. With a 0.00002 BTC fee, change is 0.00798 BTC. The change is a new output, not a remainder stored inside the original one. This accounting example helps explain why an outgoing transaction may contain several outputs.
Spending requires satisfying the output’s conditions, commonly with a digital signature. An address describes a destination; it is not the private key and does not grant spending authority.
Custody is an operational decision
Choose custody according to the task. A trading account needs accessible working capital and a clear response to exchange downtime. Long-term storage needs a tested backup and recovery process. Using the same setup for every purpose creates avoidable complexity.
Before enabling withdrawals, verify the network, destination and provider requirements. Keep seed phrases offline and out of logs. Give trading API credentials only the permissions the strategy requires. A bot that only submits orders should not automatically receive withdrawal authority.
Confirmations are evidence, not a timer
Nodes validate transactions and blocks against consensus rules. Miners assemble candidate blocks and perform proof of work. A transaction has its first confirmation when included in the accepted chain; subsequent blocks increase its confirmation count.
The relevant chain is selected by accumulated work among valid chains. A reorganization can change recent inclusion. Consequently, an application should retain transaction identifiers, block references and confirmation state, rather than merely marking a payment complete after a fixed delay.
Set deposit acceptance rules according to the amount, counterparty and provider policy. Do not treat a displayed pending balance as spendable settlement evidence.
Keep exchange orders and on-chain transfers separate
A centralized-exchange fill updates the exchange’s internal ledger. It does not normally create an individual Bitcoin transaction for your account. Buying BTC on an exchange and receiving BTC in a self-custody wallet are separate operations.
For a trading bot, this distinction leads to two workflows. Order handling checks fills, commissions, quantities and balances. Transfer handling checks withdrawal status, transaction identifiers and arrival. A timeout should trigger reconciliation before a retry, because the first operation may already have succeeded.
Store order IDs for trades and transaction IDs for transfers. A local success message is insufficient evidence for either workflow.
Read older books alongside current specifications
Bitcoin’s basic accounting model remains valuable to learn. Wallet formats, software behavior and upgrade details require current references. Taproot’s specification, for example, describes both key-path and script-path spending, extending the concepts a reader encounters in earlier introductory material.
Check whether a guide is explaining historical behavior, consensus rules or a particular wallet’s policy. Those categories answer different questions and can change at different speeds.
A practical review before automation
- Which record proves a fill, and which proves a transfer?
- Does the program reconcile after an ambiguous timeout?
- Are quantities and commissions taken from actual execution?
- Can pending deposits be mistaken for usable funds?
- Are credentials scoped, backups tested and secrets excluded from logs?
Technical references and further reading
- Bitcoin Developer Guide: Transactions.
- Bitcoin Developer Guide: Block Chain.
- BIP 341: Taproot spending rules.
Further reading: Kalle Rosenbaum, Grokking Bitcoin; Russian edition published in 2020 as «Грокаем технологию Биткоин». This independent overview uses its own examples and focuses on operational questions for traders. It does not reproduce the book’s chapters, illustrations or exercises.