Editora Coralina

Bitcoin is a digital monetary system that lets participants transfer value without asking a bank or central payment operator to update the ledger. A wallet provides the interface, private keys authorize spending, nodes enforce the rules, and miners order valid transactions into blocks. The result is a public record that anyone can inspect but no single participant can rewrite at will. ^[1]

Key takeaways

• Bitcoin can mean the network, its protocol, or the monetary unit BTC.
• A wallet does not contain coins in the physical sense. It manages keys and identifies spendable transaction outputs recorded by the network.
• Sending BTC means creating and signing a transaction that spends existing outputs and creates new ones.
• Broadcasting is not the same as confirmation. A transaction becomes confirmed only after a miner includes it in a valid block accepted by nodes.
• A transaction ID, recipient output, network fee, block inclusion, and confirmation count can all be checked independently.
• Bitcoin transfers are generally irreversible after confirmation, so the network, address, amount, and wallet interface must be checked before signing.
• BTC is volatile, and access can be lost if private keys or recovery information are exposed or destroyed.

What Bitcoin actually is

Bitcoin combines three closely related things. It is a peer-to-peer network of computers, a protocol defining the rules those computers follow, and a digital unit of account commonly identified as bitcoin or BTC.

The shared ledger is called the blockchain. Each validating node maintains its own view of that ledger and independently checks incoming blocks against the consensus rules. Agreement emerges when nodes accept the same valid chain rather than when a central database owner approves entries. ^[2]

Mining adds ordering and proof of work. Miners assemble candidate blocks, compete to produce valid proof of work, and may receive transaction fees plus a protocol-defined block subsidy. New issuance decreases over time, with the supply designed not to exceed 21 million BTC. That supply rule does not make the market price stable or guarantee that it will rise. ^[3]

One bitcoin is divisible into 100 million satoshis. This allows transactions to use fractions of a BTC rather than requiring anyone to buy or transfer a whole coin.

The minimum vocabulary you need

Wallet

A Bitcoin wallet is software or a device that helps generate receiving information, monitor transactions, construct payments, and use the appropriate private keys to sign them. Depending on its design, signing and network communication may happen in one application or in separate components. ^[4]

The practical consequence is simple: deleting an app does not necessarily destroy the bitcoin, while losing the only usable keys or recovery backup can make the associated funds inaccessible.

Private key and recovery backup

A private key provides the cryptographic authority needed to satisfy a spending condition. Whoever obtains usable private keys can usually authorize transactions, so they must not be sent to “support,” entered into an unfamiliar website, or stored in an exposed screenshot or cloud document.

Many wallets represent recovery data as a sequence of words, often called a recovery phrase or seed phrase. This phrase may allow the wallet’s keys to be reconstructed. Not every wallet uses the same backup format, so recovery instructions must be checked for the specific wallet rather than assumed. ^[5]

Address

A Bitcoin address is a user-facing representation of payment conditions. It tells a wallet how to create an output that the intended recipient should later be able to spend. It is not a username, an account at a bank, or a secret credential.

Address formats can differ while still belonging to Bitcoin. The sender must nevertheless confirm that the receiving service supports the displayed format and that both sides are using the native Bitcoin network. An address copied from another asset, another network, or a deceptive interface may lead to permanent loss.

UTXO

Bitcoin does not update a single account balance in the way a bank ledger does. It tracks unspent transaction outputs, usually shortened to UTXOs. Each valid transaction consumes one or more existing outputs and creates one or more new outputs. A wallet’s displayed balance is therefore an interpretation of the UTXOs it can spend. ^[2]

If a wallet spends an output larger than the intended payment, it can create a separate change output back to the sender. The interface may hide this bookkeeping, but the change is visible in the transaction data.

Network fee

The network fee is normally the difference between the total value of a transaction’s inputs and outputs. It is offered to miners, while the wallet typically estimates an appropriate fee based on transaction size and current network conditions. ^[2]

This is distinct from any fee or spread charged by an exchange, broker, wallet provider, or other service. A quoted service total may combine several components, so the user should inspect the breakdown before confirming an operation.

Mempool, block, and confirmation

A valid transaction may first circulate among nodes as an unconfirmed transaction. Nodes can keep eligible unconfirmed transactions in their local memory pools, or mempools, but those pools are not a permanent global ledger and do not have to be identical. ^[6]

When a miner includes the transaction in an accepted block, it receives its first confirmation. Each accepted block built after that increases the confirmation count. More confirmations generally make replacement of that transaction history more difficult, but no fixed number can guarantee settlement for every risk level or business policy. ^[7]

Transaction ID

The transaction ID, or TXID, is an identifier derived from transaction data. It is the main reference used to search for a transaction in a wallet, blockchain explorer, or node interface. A TXID proves that a specific transaction representation exists; by itself, it does not prove that a recipient controls the destination keys or that an off-chain commercial obligation has been fulfilled. ^[8]

The mechanism map: from a tap to a confirmed payment

What happens during a native on-chain Bitcoin transfer

Stage	User action	Wallet or service mechanism	Network mechanism	Observable result and check
1. Receive payment details	The recipient generates or displays a Bitcoin address.	The receiving wallet derives payment information from its keys or wallet structure.	Nothing has been submitted to Bitcoin yet.	Check that the full address is unchanged and that the requested network is Bitcoin.
2. Build the payment	The sender enters or scans the address and specifies the BTC amount.	The wallet selects spendable UTXOs, creates the recipient output, may create a change output, and estimates a network fee.	The transaction still exists only inside the sender’s software.	Review the destination, amount, fee, and total before signing.
3. Authorize spending	The sender approves the transaction.	The wallet signs the required transaction data with the relevant private keys. A hardware or offline signer may perform this step separately.	No confirmation exists merely because a signature has been produced.	A signing device may show the destination and amount on its own screen for independent review.
4. Broadcast	The signed transaction is submitted.	A network-connected wallet or service sends it to one or more Bitcoin nodes.	Nodes check it and may relay it to peers if it satisfies their validation and relay policies. [6]	A TXID may appear, and a node or explorer may show the transaction as unconfirmed.
5. Wait in mempools	The user waits rather than sending the payment again.	The wallet monitors peers or a service backend for status changes.	Eligible transactions can remain in node mempools until mined, replaced, rejected, or eventually removed. Mempools can differ between nodes. [6]	Check whether the TXID is visible, whether it remains unconfirmed, and whether the transaction is marked replaceable.
6. Enter a block	No additional user action is normally required.	The wallet detects a block containing the transaction.	A miner includes the transaction in a candidate block; nodes independently validate the block before accepting and relaying it.	The transaction gains a block height or block reference and its first confirmation.
7. Accumulate confirmations	The sender and recipient wait for the level required by their own risk policy.	Wallets and services update the status as new blocks are accepted.	Later blocks extend the accepted chain containing the transaction.	The displayed confirmation count rises. The recipient can verify the relevant output, not merely the overall transaction status.

The chain is therefore not “sender presses Send, recipient instantly owns money.” The actual path is construction, authorization, broadcast, node validation, miner selection, block validation, and confirmation. A delay at one layer does not automatically imply failure at every other layer.

A realistic first transaction

Consider a user moving BTC from a custodial exchange account to a self-custody wallet. No particular provider, amount, or completion time needs to be assumed.

1. The user installs or initializes a Bitcoin wallet from a trusted source and records its recovery information offline according to that wallet’s instructions.
2. The wallet displays a native Bitcoin receiving address. The user verifies the address in the wallet itself rather than relying solely on clipboard contents.
3. In the exchange withdrawal interface, the user selects BTC and checks that the offered withdrawal network is the Bitcoin network. A similarly named network, tokenized version of bitcoin, or unrelated chain is not interchangeable with native BTC.
4. The user pastes or scans the address, compares the full destination again, reviews the withdrawal amount and all displayed charges, and completes any security or compliance steps required by the provider.
5. The exchange may initially show an internal status such as pending or processing. At this point it may be handling account checks or preparing the withdrawal; a Bitcoin transaction cannot yet be independently verified unless a real TXID has been provided.
6. After broadcast, the TXID can be inspected. The user checks that one output matches the receiving address and intended amount, while recognizing that the transaction may also contain a change output belonging to the sender or service.
7. Once the transaction is included in a block, the receiving wallet reports a confirmation. The user waits for the confirmation policy appropriate to the wallet, service, or transaction context.

This scenario separates two ledgers. The balance shown inside a custodial exchange is generally an obligation recorded in that company’s system. The self-custody wallet begins controlling an on-chain output only when the withdrawal transaction creates the relevant output and the wallet has the keys needed to spend it.

What a blockchain explorer can—and cannot—prove

A blockchain explorer is a convenient interface for public network data. Given a TXID, it can typically display inputs, outputs, amounts, fee information, block inclusion, and confirmation status. The same underlying information can be checked through a node, reducing reliance on a particular explorer’s interface or infrastructure.

Explorer data can answer questions such as:

• Does this transaction exist in the data source being queried?
• Is it unconfirmed or included in a block?
• Which outputs did it create?
• Does the expected destination and value appear among those outputs?
• How many blocks currently follow the block containing it?

It cannot prove the real-world identity of the person controlling an address. Nor can it determine whether a sale, refund, contract, or customer-support claim is legitimate. Bitcoin transactions are publicly recorded, but addresses are not automatically tied to verified legal identities. Calling Bitcoin completely anonymous is therefore misleading. ^[9]

Searching an address or TXID through a third-party explorer can also reveal information about the user’s interests to that provider. Verification improves transparency, but the method chosen can have privacy consequences.

Custody changes the risk model

Custodial balance

With custody, a company controls the keys while the customer sees an account balance. This can simplify recovery and trading, but it introduces dependence on the provider’s security, withdrawal process, availability, compliance controls, and terms.

An internal transfer between two customers of the same platform may never appear as a separate Bitcoin transaction. The platform can update its private database instead. Only an on-chain deposit or withdrawal necessarily interacts with the Bitcoin network.

Self-custody

With self-custody, the user controls the information required to authorize spending. This removes the need to ask a custodian for each transfer, but it also moves backup and transaction-verification responsibility to the user.

A properly designed signing-only or hardware wallet can keep private keys separate from the internet-connected component that builds and broadcasts transactions. It reduces some attack paths, but it cannot protect a payment that the user approves to an attacker’s address after ignoring the details shown on the signing device. ^[4]

The phrase “not your keys, not your coins” captures a custody distinction, not a complete security plan. Key control without tested backups, authentic software, careful address review, and a recovery procedure can still end in loss.

Where the model changes

The mechanism map above describes native, on-chain Bitcoin. Several related products use different mechanisms:

• Exchange balances: the provider may update an internal ledger without creating an on-chain transaction.
• Wrapped or tokenized bitcoin: a token on another blockchain is governed by that blockchain and by the arrangements connecting the token to BTC.
• Payment channels and second-layer systems: routine transfers may occur outside the base-chain transaction flow and later interact with it under separate rules.
• Broker purchases: buying price exposure does not always mean that withdrawable BTC has been delivered to a user-controlled address.

These distinctions prevent a common mistake: seeing “BTC” in an interface and assuming the same keys, network, settlement process, and withdrawal rights apply everywhere.

Wallets, exchanges, and merchants may also use different confirmation requirements. Service processing time is not identical to Bitcoin confirmation time, and neither has a universal deadline. Fees, transaction selection, node policies, security reviews, and network conditions can all affect the observable result.

Legal, tax, reporting, and identity-verification rules vary by country and transaction type. A public Bitcoin address does not remove obligations imposed by a local jurisdiction or by a service’s compliance program. Those requirements should be checked with appropriate local sources before acting.

Common failure points and their visible signs

How to diagnose a Bitcoin transaction problem

Visible sign	Likely layer	Possible explanation	What to verify
The service says “processing,” but there is no TXID	Service layer	The provider may not have constructed or broadcast the withdrawal yet.	Check the provider’s status, security requests, compliance requirements, and whether a TXID has actually been issued.
A TXID is shown but cannot be found	Broadcast or data-source layer	The transaction may not have propagated, the TXID may be wrong, or the selected explorer may not see it.	Copy the complete TXID, try an independent data source, and ask the sender whether the transaction was broadcast successfully.
The transaction is visible but unconfirmed	Mempool and mining layer	It has been broadcast but not included in an accepted block. Fee conditions, transaction dependencies, replacement, or relay policies may be relevant.	Inspect fee rate, unconfirmed parents, replaceability, and current transaction status before attempting any fee-management feature.
The receiving wallet shows no balance	Wallet synchronization or destination layer	The wallet may be unsynchronized, monitoring a different account, or not control the destination output.	Compare the on-chain output with the address displayed by the wallet and confirm that the correct wallet or account is open.
The displayed amount is lower than expected	Service or transaction-construction layer	A service charge may have been deducted, or the user may be looking at the wrong output rather than the recipient output.	Compare the withdrawal record, transaction outputs, network fee, and any separately disclosed service charge.
The destination is correct-looking but belongs to another network	User-interface and network-selection layer	A deposit route for a different blockchain or token representation may have been selected.	Stop before signing and obtain explicit confirmation that both sender and recipient support the same network and address type.
Funds went to an attacker’s address	Authorization and security layer	Phishing, clipboard malware, a fake application, or deceptive support may have altered the destination.	Preserve the TXID and records, secure remaining wallets and accounts, and contact the relevant service. Bitcoin itself does not provide a chargeback mechanism.
A confirmation count briefly decreases	Blockchain layer	The network’s accepted chain view may have reorganized near its tip.	Wait for the wallet or node to update and check whether the transaction appears in the replacement chain or returned to an unconfirmed state.

Never “fix” uncertainty by immediately repeating the same payment. First identify whether the original transaction was never created, created but not broadcast, broadcast but unconfirmed, replaced, or confirmed. Otherwise, both transactions may eventually settle.

Security checks before using real BTC

• Obtain wallet software through a trusted distribution path and verify the application identity before creating a wallet or entering recovery data.
• Keep private keys and recovery phrases away from websites, messages, cloud notes, screen-sharing sessions, and anyone claiming to be support.
• Verify the complete address. Matching only the first and last few characters can miss address-substitution attacks. ^[10]
• Confirm the network on both the sending and receiving sides. Asset labels alone are insufficient.
• Review transaction details on the most trustworthy display available, especially when a separate signing device is used.
• For an unfamiliar workflow, consider a smaller initial transfer while accounting for the fact that it creates an additional transaction and additional fees.
• Keep backups protected from both theft and accidental destruction, and understand the recovery process before substantial value depends on it.
• Treat urgent messages, guaranteed returns, recovery services, giveaways, and requests to “verify” a seed phrase as warning signs.

Bitcoin transfers generally cannot be cancelled through a central operator. A recipient can voluntarily send a refund, but that refund is a new transaction rather than a reversal of the original payment. Volatility adds a separate risk: the market value of BTC can change sharply even when the network works exactly as designed. ^[9]

Buying or exchanging BTC without confusing the layers

Before creating an exchange order, distinguish the quoted conversion from the later blockchain transfer. The displayed exchange rate, any service charge, the network fee, identity or source-of-funds checks, and the final BTC output are different parts of the process.

If an exchanger supports BTC, that does not imply every currency pair, payment method, address format, or network route is available. Current availability should be checked before submitting funds. Verification requirements can also vary by direction and by the outcome of compliance checks.

After understanding those limits, a practical next step is to check the currently available Bitcoin exchange direction. Review the exact asset, network, destination, quoted terms, and verification requirements before creating a request.

What you can now explain and verify

• You can explain why a wallet manages keys and UTXOs rather than storing digital coins inside the app.
• You can distinguish transaction creation, signing, broadcasting, mempool visibility, block inclusion, and later confirmations.
• You can use a TXID to check the recipient output and confirmation status instead of trusting a screenshot or status message.
• You can tell the difference between an exchange’s internal balance and BTC controlled through an on-chain wallet.
• You can identify where a delay is occurring: inside a service, during broadcast, in a node’s mempool, or before block inclusion.
• You can recognize that native BTC, tokenized bitcoin, custodial balances, and second-layer payments do not share one universal settlement model.
• You can explain why the full address, correct network, private-key security, and recovery backup matter before a transaction is authorized.
• You can verify what the blockchain shows without claiming that it proves a person’s identity, a legal agreement, future price, or guaranteed recovery.

The most useful beginner habit is to separate what an interface claims from what can be observed at each layer. A service status describes the service. A signed transaction shows authorization. Mempool visibility shows propagation to a data source. A block shows inclusion. Confirmations show that additional accepted blocks have accumulated. Each answers a different question.