Sending Bitcoin — From Receiving an Address to Confirming Arrival

The whole procedure in five steps

• A bitcoin transfer is assembled in the opposite order from a card payment. The receiving side presents a destination — an address on-chain, an invoice on Lightning — and the sending side pushes funds to it from their own wallet. Nothing corresponding to a card number travels from payer to payee.
• The procedure divides into five steps.

• What matters is that the substantive safety check finishes at step 3. As bitcoin.org states plainly, a transaction cannot be reversed, and the only way back is for the recipient to send it back. After step 4, the options are to raise the fee or to wait.
• That asymmetry is not a defect; it follows necessarily from a design with no intermediary. The background is covered in "Why Lost Bitcoin Cannot Be Recovered". The sections below walk each step in practical terms.

Receiving the destination — address formats and QR codes

• A bitcoin address is a string derived from a public key by a one-way hash. It is a value meant to be published in order to receive, and knowing it moves nothing. The three-layer structure of keys is covered in "Wallets and Security".
• Four formats account for nearly everything you will see. They serve the same purpose; what differs is the size that feeds into the fee calculation and how widely each is supported.

• The receiving side has one rule worth keeping: do not reuse addresses. Modern wallets are hierarchical deterministic, generating a fresh address for each receipt automatically. Reusing one ties your payment history to a single identifier and increases public-key exposure. "Bitcoin Privacy" explains why.
• What a payment QR code actually contains is, in most cases, a URI beginning with `bitcoin:` as defined in BIP-21. Alongside the address it can carry an amount, a label, and a message, and an embedded amount removes one opportunity for manual error. The amount in the URI is still a value the other party composed, however, so reading the figure your own wallet displays remains part of the procedure.
• One more detail: Bech32 and Bech32m do not permit mixed case. An address is sometimes displayed entirely in uppercase for QR encoding efficiency; that is the same address as its lowercase form.

Verifying the destination — what gets caught automatically and what does not

• Address formats carry built-in error detection, but the coverage has edges. Knowing where automation stops and human checking begins is the point of this section.
• The Bech32 format used by bc1q addresses is defined in BIP-173: substitution errors of up to four characters are detected, and the probability of missing anything larger is stated as below one in a billion (BIP-173 itself later disclosed that it is not necessarily robust against runs of fewer than five inserted or deleted characters). For Taproot addresses beginning bc1p, the successor Bech32m format in BIP-350 fixes that weakness and plays the same role.
• There is one thing a checksum will never catch: a correctly typed address belonging to someone else. Simple typos are stopped, but an address handed to you by the wrong person is formally flawless. This is why a mistaken send is described as a failure prevented by procedure rather than by knowledge.
• The working check has three stages. First, never type an address by hand — paste it or scan the QR code. Second, visually compare the first and last few characters of what you pasted; malware that rewrites the clipboard to swap the destination genuinely exists, so "I copied it, therefore it is right" does not hold. Third, if you use a hardware wallet, always confirm the destination on the device screen — a computer or phone display can be rewritten by malware, while the device screen is independent.
• And one layer sits entirely outside format verification: who gave you the destination. An address arriving in a social-media message, or from an account claiming to be support, can be formally valid and still be the wrong destination. "Bitcoin Scams and Self-Defense" covers how to read that layer.

Choosing amount and fee — sat/vB and change

• A bitcoin fee is based on the data size of the transaction, not on the amount sent. Sending 1 BTC and sending 0.001 BTC cost the same if the transactions are the same size. The unit is sat/vB (satoshi per virtual byte), and vsize is block weight divided by four.
• It is worth understanding how the fee is "taken". The difference between the sum of the inputs and the sum of the outputs goes to the miner as the fee. There is no separate fee field; whatever is left over becomes the fee. Ordinary wallets automatically return the remainder to an address of your own as change, but when a transaction is assembled by hand, forgetting the change output pays the entire remainder as fee. "Bitcoin Transactions in Depth" covers the structure.
• The going rate is not fixed. On 15 August 2026, the recommended fee shown by mempool.space was 1 sat/vB even in the fastest band (effectively the floor), but in periods of contention for block space that figure rises many times over. The current level is also tracked weekly on this site's "Bitcoin Now" page.
• How to choose depends on the goal. If nothing is urgent, set a lower fee and wait; if there is a deadline, take the recommended band or above. As described below, a wallet supporting replacement lets you start low and raise it after watching for a while. Conversely, a fee set extremely low may not be relayed at all.
• Output size has a floor of its own to keep in mind. Extremely small outputs can fall outside standard relay. A use case built on many tiny transfers belongs on Lightning rather than on-chain in the first place.

The final check — the line you cannot cross back over

• The moment before signing is the last one that can be taken back. The checklist below pairs each item with what happens if it is missed. If any single line cannot be confirmed, stop there.

• Network selection causes an outsized share of accidents. The ticker "BTC" can refer to the Bitcoin network or to a differently issued token on another chain, and those are entirely different destinations. When withdrawing from an exchange, check the network name, not only the asset name.
• Expectations about refunds also need aligning. Nothing corresponding to a card chargeback exists at the protocol level. A refund can only take the form of the recipient sending a separate transaction back.
• Finally, stopping when you are being hurried is the single most effective habit. Someone hurries you because they want it settled before you consult a third party. Agreeing on one rule — that any transfer gets talked through with someone first — makes the methods that work by isolating a target much harder to run.

After broadcasting — reading confirmations and arrival

• A signed transaction pushed to the network first lands in each node's memory pool (mempool), and miners select from it, preferring higher fees, when building a block. Blocks arrive roughly every ten minutes on average, but the interval varies and can be anything from seconds to more than an hour.
• Zero confirmations is not settlement. Bitcoin Core 28.0 made full-RBF the default in October 2024, and 29.0 removed the option to disable it in April 2025. On a default-configured node as of August 2026, unconfirmed transactions are in principle all replaceable regardless of signalling. "It did not signal RBF, so zero confirmations is safe" no longer holds.
• Reversal gets harder as confirmations accumulate. Whitepaper §11 calculates that an attacker with 10% of hash power catches up about 20% of the time at one confirmation, falling to about 0.024% at six (in the same table, the figure drops below 0.1% from five). The convention of treating six confirmations as final comes from that calculation — though the figure assumes a model in which the attacker's hash power is fixed and cannot be rented.
• There are two ways to confirm arrival: your own wallet's balance, and looking up the transaction ID (txid) in a block explorer. The latter depends on a third-party service, so reducing that dependency means querying your own full node instead. "Running a Bitcoin Node" covers how.
• The condition for crediting on the receiving side is the recipient's internal rule, not a protocol rule. Exchanges each set their own required confirmation count, and some in-person payments are accepted at zero confirmations. "How many confirmations is final" is a risk-management choice against amount and counterparty, not a standard.

When it stalls — RBF and CPFP

• When a transfer does not arrive, the cause splits three ways: it was never broadcast, it is sitting in the mempool with a fee too low for its turn to come, or it is already in a block and you are waiting for the other side to credit it. Looking up the txid in a block explorer tells you which immediately.
• If a low fee is the problem, two remedies exist. RBF (Replace-By-Fee) replaces the transaction with one spending the same inputs at a higher fee. Historically this used the opt-in scheme of BIP-125, where a transaction qualified only if one of its inputs carried a sequence number below 0xFFFFFFFE; as noted above, on default configurations today replacement is possible regardless of signalling. Whether you can actually use it depends on whether your wallet supports fee bumping.
• CPFP (Child-Pays-For-Parent) creates a high-fee child transaction spending an output of the stalled one, giving miners an incentive to mine the pair together. The receiving side can do it using the unconfirmed output they received; the sending side can do it using the change output. From Bitcoin Core 28.0, one-parent-one-child (1P1C) package relay means a parent that falls below the minimum relay fee on its own can still propagate when evaluated together with its child.
• A premise underlies all of this: RBF, CPFP, and fee prioritization are relay and mempool policies each node chooses individually, not the consensus rules that determine block validity. That is why defaults can change without a soft fork — and why the node on the other side may not be configured the way yours is.
• If you do nothing, nodes drop transactions that remain unconfirmed past a certain age from the mempool (the period is a node setting). No funds are lost when that happens. The inputs that were going to be spent remain unspent UTXOs, and you can simply send again. Not arriving and being lost are different things.

Test sends, and the situations that trip people up

• Before sending a large amount, always make a small test send and confirm it arrives before doing the real one. The extra fee is cheap insurance against an accident that cannot be undone. A new counterparty, a new wallet, or an operation you have not performed in a while — any of these is reason enough to treat the transfer as a test-send case regardless of amount.
• Withdrawing from an exchange adds a layer above the on-chain fee. Withdrawal fees are often a fixed amount set by the operator and may not track network congestion at all. Withdrawal limits, hold conditions, and which address formats are supported are likewise the operator's own rules. When something does not work, suspect the terms of service before suspecting the protocol.
• Sending over Lightning changes the procedure itself. The receiving side presents a BOLT11 invoice or QR code, and payment completes in seconds. There is no waiting for confirmations, but the receiving side needs inbound capacity, and a payment fails if no route is found. It suits small, frequent amounts; larger sums, or a counterparty without Lightning support, go on-chain. "Introduction to the Lightning Network" covers the mechanics and "Paying with Bitcoin" the trade-off.
• Moving funds to another wallet of your own follows exactly the same procedure. Even when the destination is you, neither address verification nor the test send can be skipped. When moving to a new hardware wallet, the safe order is to restore from the backup first, confirm it actually restores, and only then move the balance.
• Japanese tax treatment turns not on the act of transferring but on what you did. As the National Tax Agency sets it out, the taxable moments are sale, purchase of goods, exchange between crypto-assets, and acquisition through mining and the like; merely holding is not taxed. Using bitcoin to pay can therefore be a taxable event. This site does not give individual tax advice — see "Bitcoin Taxes (Japan)" for detail, and confirm your own position with a tax accountant or your local tax office.

In summary — what procedure can lower, and what it cannot

• Here is what this page covered, split into what a procedure can address and what it cannot.

• Three structural points are worth holding onto. First, a transfer cannot be reversed, and a refund exists only as a voluntary send back by the recipient. Second, the fee is based on data size rather than amount, so the smaller the transfer the heavier the fee weighs proportionally. Third, how many confirmations to wait for is not a standard but a risk-management choice against amount and counterparty.
• The questions this site has no answer to are equally clear. Which wallet product or exchange to use, how much to send, and when to send it. These are individual recommendations or value judgments, and they sit outside educational commentary.
• This page is educational commentary, not investment advice and not individualized tax advice. It is current as of August 2026, and fee levels and software defaults both change. At the moment you actually send, confirm against the primary sources cited here and your wallet's official documentation.