Bitcoin is a peer-to-peer monetary network and a native digital asset, BTC. It allows participants to transfer value without requiring a bank to maintain the definitive ledger. Wallet software creates and signs transaction instructions, independent nodes check those instructions against shared rules, and miners compete to place valid transactions into proof-of-work blocks.
Key Takeaways
- A wallet does not store coins as files. It manages the keys needed to authorize spending of transaction outputs recorded on the Bitcoin blockchain.
- A Bitcoin address is receiving information, not a username or a reusable bank account number.
- Sending BTC normally involves selecting spendable outputs, creating new outputs, adding a fee, signing the transaction and broadcasting it.
- Broadcasting is not the same as confirmation. A transaction remains unconfirmed until a miner includes it in a valid block.
- Confirmed transactions do not have a standard chargeback mechanism. Recovering BTC sent to the wrong party usually requires that party to cooperate.
- Bitcoin’s price, wallet balance and transaction validity are separate questions. A valid transaction can occur while the market price rises or falls sharply.
What Bitcoin Is—and What It Is Not
Bitcoin combines an asset, a transaction ledger, a peer-to-peer communication system and a set of consensus rules. No single company owns the network or decides which valid participant may use it. Software implementations communicate with peers, while independently operated full nodes validate blocks and transactions before relaying them. [1]
BTC is the unit accounted for by that system. One bitcoin is divisible into 100,000,000 satoshis, making a satoshi the smallest native accounting unit used by the protocol. Bitcoin Core’s consensus code defines this relationship directly. [2]
Bitcoin is not the same thing as:
- A wallet: software or hardware used to manage keys and construct transactions.
- An exchange: a business that may buy, sell, convert or custody BTC under its own terms.
- A blockchain explorer: an interface for reading publicly available network data.
- A stablecoin: a token designed to track another asset, typically a national currency.
- Wrapped bitcoin: a representation of BTC issued on a different network, with additional issuer, bridge or smart-contract risks.
Bitcoin has a rule-based issuance schedule rather than discretionary creation by a central administrator. Its block subsidy declines over time, and the system is commonly described as having a 21 million BTC limit. That limit does not mean all units will be accessible or circulating: coins can be lost, deliberately made unspendable or remain otherwise unavailable. [1]
The Minimum Vocabulary You Need
| Term | Meaning | Why it matters in practice |
|---|---|---|
| Private key | Secret cryptographic data used to authorize spending | Anyone who obtains the relevant private keys can generally sign transactions controlling the associated BTC. |
| Public key and address | Related cryptographic data used to define receiving conditions | You share an address to receive BTC, but never share a private key or wallet recovery secret. |
| Wallet | A program, file or dedicated device that manages keys and transaction activity | Wallet design determines who controls the keys, how backups work and how transactions are approved. |
| Recovery phrase or seed backup | Human-readable backup data used by many wallets to derive keys | Exposure may give an attacker control; loss may make recovery impossible. Exact backup procedures depend on the wallet. |
| UTXO | An unspent transaction output available to be used as a later transaction input | A displayed balance may consist of several separate outputs rather than one account entry. |
| Transaction fee | The difference between the total value of inputs and outputs | Miners may prioritize transactions partly according to their effective fee rate, while wallet and service policies also affect processing. |
| Mempool | A node’s local collection of valid unconfirmed transactions | Mempools are not one perfectly identical global queue; different nodes may temporarily show different sets of transactions. |
| TXID | A transaction identifier derived from transaction data | It is the main reference used to locate and inspect a transaction. |
| Block | A validated collection of transactions linked to a preceding block | Inclusion in a block gives a transaction its first confirmation. |
| Confirmation | A measure based on the block containing a transaction and blocks built after it | More confirmations generally make replacement through a chain reorganization progressively harder. |
| Full node | Software that independently checks blocks and transactions against Bitcoin’s rules | It can reject invalid data even if another peer, miner or service presents that data as valid. |
| Miner | A participant that assembles candidate blocks and performs proof-of-work | Miners choose among valid transactions for candidate blocks, but full nodes still decide whether the resulting block follows consensus rules. |
Bitcoin’s ledger follows the UTXO model. A transaction consumes one or more previous unspent outputs and creates new outputs. Each output can be validly spent only once; an attempt to reuse it conflicts with the network’s double-spend rules. [3]
Custody: Who Can Actually Authorize a Transaction?
The first operational decision is not which price chart to watch. It is who controls the keys.
| Model | Who normally controls the keys? | What the user depends on | Primary failure risk |
|---|---|---|---|
| Custodial account | The exchange, broker or payment service | The provider’s security, solvency, withdrawal policies, compliance process and account recovery | Frozen access, provider compromise, insolvency or withdrawal restrictions |
| Self-custodial software wallet | The user | Device security, authentic software and a reliable backup | Malware, phishing, exposed backup or accidental deletion |
| Hardware signing device | The user, through keys intended to remain on the device | Authentic hardware, secure initialization, correct backup and careful on-device review | Compromised recovery secret, supply-chain deception or approving altered details |
“Not your keys” means that a balance shown by a custodial platform is generally a claim on the provider until a withdrawal is completed on-chain. Conversely, self-custody removes some provider dependence but makes the user responsible for key protection and recovery. Bitcoin wallet systems can separate address generation, transaction signing and network broadcasting, which is why offline and hardware signing arrangements are possible. [4]
No custody model removes all risk. The useful question is which failures the model makes possible and which party must prevent or recover from them.
Mechanism Map: From “Send” to a Confirmed Bitcoin Payment
| Step | User action | What the wallet or service does | What happens on the Bitcoin network | Observable result and check |
|---|---|---|---|---|
| 1. Obtain receiving data | The recipient generates or copies a Bitcoin address. | The receiving wallet derives the necessary payment information from its key structure. | Nothing has moved yet. Creating or sharing an address is not an on-chain transaction. | Check the complete address through a separate trusted channel when possible. |
| 2. Enter the payment | The sender pastes or scans the address and specifies an amount. | The wallet identifies suitable UTXOs, estimates a fee and usually creates a change output for value not sent to the recipient or paid as a fee. | The proposed transaction is still local and has no network status. | Review the asset, native network, destination, amount and fee before approval. |
| 3. Sign | The sender approves the transaction. | The signing component uses the required private keys to produce cryptographic authorization satisfying the spending conditions. | A signed transaction can now be checked by Bitcoin nodes, but signing alone does not broadcast or confirm it. | A hardware device, if used, should display the destination and amount for independent review. |
| 4. Broadcast | The wallet or service submits the signed transaction. | A networked component sends the serialized transaction to one or more peers. | Nodes validate the transaction under their policies and consensus rules. Accepting nodes may store it in their local mempools and relay it. | A TXID may become available. Search it in a reputable explorer or query a trusted node; “not found” can mean delayed propagation, rejection or an explorer issue. |
| 5. Select for a block | No additional user action is normally required. | The wallet monitors transaction status. A custodial service may keep its own status labels and confirmation threshold. | Miners choose valid transactions for candidate blocks, commonly considering fee rate and other policies. | The transaction remains unconfirmed until included. Its visibility in a mempool is not proof of settlement. |
| 6. Mine and validate | The sender and recipient wait. | Applications detect a block that contains the transaction. | A miner finds valid proof-of-work and broadcasts the block. Full nodes independently validate the block and its transactions before extending their accepted chain. | The transaction shows a block hash, block height and one confirmation if the block remains in the active chain. |
| 7. Accumulate confirmations | The recipient waits for the assurance level appropriate to the situation. | A wallet or service increments the displayed confirmation count as additional blocks build on the transaction’s block. | Each subsequent block adds proof-of-work after the recorded transaction. | Confirm that the status refers to the active chain and compare the TXID, recipient output and amount with the intended payment. |
Full nodes verify transactions and blocks before relaying them. Blocks contain a reference to the preceding block, while proof-of-work makes rewriting an older record increasingly costly as more blocks are added after it. This creates probabilistic finality rather than an absolute promise that a particular confirmation count is sufficient for every situation. [5]
How a Bitcoin Transaction Uses Inputs, Outputs and Change
Suppose a wallet controls several UTXOs and needs to pay a recipient. It does not edit an account balance. Instead, it chooses one or more eligible outputs as inputs and creates a new transaction.
The transaction may create:
- an output assigned to the recipient;
- a change output controlled by the sender’s wallet; and
- an implicit miner fee equal to total inputs minus total outputs.
If selected inputs exceed the intended payment, the wallet generally returns the remaining spendable value as change. That change may go to a newly generated internal address, so seeing an unfamiliar second output does not automatically indicate that funds were stolen. The transaction should still be decoded and checked rather than judged from the number of outputs alone.
UTXO structure also explains why two payments with the same BTC amount can require different transaction sizes and fees. A transaction combining many inputs generally contains more data than one spending a single suitable input. Fees therefore depend on transaction data and market conditions, not simply on the BTC value being transferred. Inputs must be fully spent into new outputs or left as fees. [6]
A Realistic Beginner Scenario
A person acquires BTC through a service and wants to move it to a self-custodial wallet. No assumed amount, fee or processing time is needed to understand the workflow.
- Prepare the receiving wallet. The user installs authentic wallet software or initializes a trusted signing device, follows its backup procedure and generates a native Bitcoin receiving address.
- Verify compatibility. Before creating a withdrawal or exchange request, the user confirms that both sides refer to native BTC on the Bitcoin network—not a similarly named token or a representation on another blockchain.
- Review service conditions. The user checks whether the required direction and network are currently available, along with displayed fees, limits and compliance requirements. These conditions can depend on the operation and the results of compliance checks.
- Submit the address carefully. The complete address is compared with the wallet display. Checking only the first and last few characters is weaker because malware can replace clipboard contents with a deceptively similar address.
- Wait for a TXID. An internal “processing” status means the service may not yet have broadcast a Bitcoin transaction. Once a TXID exists, the user can examine the network-facing record.
- Verify the outputs. The user checks that the TXID resolves to the intended network transaction and that an output pays the expected address and amount.
- Observe confirmations. The wallet should detect the payment after broadcast or confirmation, depending on its design. The user waits for an assurance level appropriate to the wallet, service and purpose.
This scenario contains two different systems: the provider’s internal account and processing records, followed by the public Bitcoin transaction. A provider status cannot by itself prove that a transaction is confirmed; the TXID and active-chain data provide the network-level evidence.
If exchanging into or out of BTC is the chosen next step, first review current availability and operation requirements, then check the available Bitcoin exchange direction. Availability of a particular pair, network or route should be confirmed before creating a request.
How to Verify a Transaction Without Guessing
A transaction identifier can expose several useful facts through a blockchain explorer or a properly configured node. Bitcoin Core interfaces can return decoded transaction fields including inputs, outputs, block hash and confirmation count when the required transaction data is available. [7]
Verification checklist
- Does the TXID exist on the expected Bitcoin network?
- Is the transaction unconfirmed or included in a block?
- Does one output correspond to the intended receiving address or script?
- Does that output contain the expected BTC amount?
- Is the containing block currently part of the active chain?
- How many confirmations are shown?
- Do multiple independent data sources agree?
An explorer is a convenient viewer, not the source of Bitcoin’s rules. It can be delayed, unavailable, configured incorrectly or misleading. A user seeking stronger independent verification can run a full node, though doing so requires technical setup and ongoing resource management.
Zero confirmations means the transaction has been broadcast or otherwise observed but is not yet included in a block. Competing unconfirmed transactions can create double-spend risk, and only one conflicting spend can ultimately remain in the accepted blockchain. [8]
Why Confirmation Time Is Not Guaranteed
Bitcoin does not assign each broadcast transaction a guaranteed place in the next block. Miners select from transactions available to them, and their policies may differ. A wallet’s fee estimate is an estimate, not a promise.
Confirmation behavior can change because of:
- current demand for limited block space;
- the transaction’s effective fee rate;
- the amount of transaction data created by its inputs and outputs;
- minimum relay and mining policies;
- whether the transaction depends on an unconfirmed parent;
- temporary propagation differences between nodes; and
- wallet, exchange or recipient confirmation policies.
A low-fee transaction can remain pending longer than expected. Depending on how it was constructed and which wallet features are available, fee adjustment or another acceleration method may be possible, but it should not be assumed. Repeatedly creating replacement transactions without understanding wallet behavior can make diagnosis harder. Bitcoin documentation explicitly warns that transactions paying only minimal fees may face long waits when block space is scarce. [3]
Where the Model Applies—and Where It Changes
| Situation | What remains true | What changes |
|---|---|---|
| Custodial transfer between users of one platform | The provider updates its own records. | There may be no Bitcoin transaction or TXID unless the provider later settles on-chain. |
| Native Bitcoin withdrawal | A valid on-chain transaction should eventually be identifiable by its TXID if broadcast. | The provider may perform internal checks before broadcasting and may require its own number of confirmations for later deposits. |
| Lightning payment | BTC-denominated value can be transferred using Bitcoin-related cryptographic mechanisms. | The payment uses an off-chain channel protocol; its verification and failure signals differ from a basic on-chain transaction. |
| Wrapped or tokenized BTC | The token may reference or claim backing by BTC. | It follows another network’s rules and introduces additional custody, bridge, issuer or smart-contract assumptions. |
| Unconfirmed transaction | Nodes may validate and relay it under local policies. | It is not yet secured by inclusion in a proof-of-work block and may be dropped, delayed or conflict with another transaction. |
| Confirmed transaction | It has been included in a block accepted by the observing node. | Its practical assurance depends on confirmation depth, transaction value, threat model and recipient policy. |
The basic map also cannot establish whether BTC is fairly priced, whether buying it is suitable for a particular person, or how its purchasing power will change. Network validity does not prove investment merit.
Likewise, public addresses and transaction records do not make Bitcoin fully anonymous. They are pseudonymous identifiers that can sometimes be connected to people through exchange records, address reuse, public disclosures or transaction analysis. Legal, tax and reporting treatment varies by country and can change, so current guidance from the relevant local authorities must be checked separately.
Common Failure Points and Their Visible Signs
| Visible sign | Possible explanation | What to check |
|---|---|---|
| No TXID after a service marks an operation as processing | The service may still be conducting internal processing or compliance checks. | Check the provider’s exact status definition and whether a transaction has actually been broadcast. |
| TXID exists but shows zero confirmations | The transaction is waiting for block inclusion or may have propagation, fee or dependency issues. | Inspect fee information, mempool visibility, parent transactions and any conflicting spend indicators. |
| Wallet balance does not update but the explorer shows the correct output | The wallet may be unsynchronized, watching the wrong account or using a network connection with stale data. | Confirm the network, synchronization state, receiving address and wallet derivation or account settings. |
| Recipient claims non-payment despite confirmations | The wrong address may have been used, the recipient may be checking a different account, or the payment may not meet the service’s crediting policy. | Compare the full destination and amount, then provide the TXID without sharing private keys or recovery data. |
| Address changes after pasting | Clipboard-replacement malware may be active. | Stop the transaction, disconnect the affected device where appropriate and verify the destination on a separate trusted display. |
| A support agent asks for a recovery phrase or private key | This is a strong sign of theft or impersonation. | Do not disclose the secret. End contact and navigate to the provider through a known, independently verified route. |
| A message demands urgent crypto payment to protect funds | It matches a common scam pattern based on pressure and irreversible payment. | Do not use the supplied link, phone number, QR code or address; verify the claim independently. |
| BTC was sent using an unexpected network | The sender and recipient may have used incompatible systems or a tokenized representation rather than native Bitcoin. | Identify the actual blockchain, transaction identifier, recipient support and control of the destination keys. Recovery may be impossible or require specialist action. |
Unexpected messages that demand urgent action, provide a payment address or direct the victim to “secure” funds with a cryptocurrency transfer are established phishing and impersonation patterns. Legitimate wallet support does not need a recovery phrase to inspect a public transaction. [9]
Security Checklist Before Sending BTC
- Confirm that the asset is native BTC and that both sides support the same Bitcoin network.
- Generate the receiving address inside the intended wallet or obtain it from the intended recipient.
- Compare the complete destination using a trusted second channel or hardware display when feasible.
- Review the amount, fee and any service charges shown before approval.
- Understand whether the wallet is custodial or self-custodial.
- Keep private keys, recovery phrases, backups and wallet passwords out of chats, email and cloud documents unless the wallet’s documented secure procedure explicitly requires a particular protected method.
- Do not assume a small test transfer guarantees a later address is safe; malware can alter subsequent transactions.
- Never send BTC because an unexpected caller claims that a transfer will protect an account, reverse fraud or unlock a withdrawal.
- Save the TXID and relevant service records, but do not publish sensitive account information.
- Verify confirmation status independently rather than relying only on a screenshot.
Bitcoin transactions are designed to authorize specific outputs. They do not include a universal undo button, card-style dispute process or central administrator who can rewrite a valid payment. A mistaken payment can usually be returned only through a new transaction authorized by whoever controls the destination.
What You Can Now Explain and Check
After working through this model, you should be able to distinguish a wallet from the Bitcoin network, a custodial balance from self-custodied BTC, and an internal platform transfer from an on-chain transaction.
You should also be able to explain why a wallet selects UTXOs, why change may appear as a separate output, how fees arise, what miners do, why full nodes still validate miners’ blocks, and why a broadcast transaction is not yet a confirmed payment.
For an actual transaction, the practical test is concrete: identify the correct network, locate the TXID, inspect its outputs, match the destination and amount, verify active-chain inclusion and observe the confirmation count. If any of those elements is missing, the available evidence does not yet justify claiming that the intended Bitcoin payment has settled.