Sending Bitcoin — From Receiving an Address to Confirming Arrival

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.

Check the destination and amount before signing and broadcasting. There is no central desk that can cancel a broadcast transaction. An unconfirmed transaction may be replaceable, but the original can confirm first, so cancellation is not guaranteed. Refunding a confirmed payment generally requires the recipient to send a separate transaction back.

"Still unconfirmed" and "safely cancelled" are different states. Keep that distinction in mind as you separate pre-send checks from post-send status checks. "Why Lost Bitcoin Cannot Be Recovered" explains the background.

You do not need a whole bitcoin. On-chain Bitcoin amounts can be expressed as 1 BTC = 100,000,000 sat. Sat is short for satoshi: a smaller unit of the same amount, not a separate crypto-asset.

These are unit conversions, not suggested payment amounts or yen prices. The yen value changes with the exchange rate. The smallest representable unit is also different from a wallet or service minimum.

First establish whether the recipient expects an on-chain Bitcoin transaction or a Lightning payment. BTC-linked tokens on other chains are not necessarily accepted at the same destination. Match the supported network and receiving method on both sides, not just the asset ticker.

A bitcoin address encodes the information needed to build a receiving locking script or witness program. P2PKH/P2WPKH use public-key hashes, P2SH/P2WSH use script hashes, and P2TR uses a tweaked public key, so the contents are not uniform. An address is meant to be shared for receiving; knowing it alone moves nothing. "Wallets and Security" explains the relationship between keys and addresses.

Four formats account for nearly everything you will see. They serve the same purpose, but they differ in the size that feeds into the fee calculation and in how widely each is supported.

There is one rule worth keeping on the receiving side: do not reuse addresses. Modern wallets are hierarchical deterministic and generate 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.

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.

Use three checks. Obtain the destination through a channel where you can verify the recipient, then paste it or scan the QR code. Compare the entire address shown by the wallet with the trusted source. Checking only the first and last characters can miss a substituted look-alike address. With a hardware wallet, also check the full destination, amount, and fee on the device screen. Copying, scanning, or viewing a device screen does not establish the recipient's identity by itself.

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.

An on-chain fee mainly depends on the transaction's virtual size and the chosen fee rate. More inputs or outputs can change the size even when the payment amount stays the same. BIP-141 defines vsize as transaction weight divided by four, rounded up. Fee rates are expressed in sat/vB.

For example, a 140 vB transaction at 5 sat/vB pays a fee of 700 sat (0.000007 BTC). These are hypothetical figures for explaining the calculation, not a current fee recommendation. An exchange withdrawal fee is a separate charge, so check both the amount received and the total cost before sending.

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.

Fee estimates change with congestion and node policies. This site's "Bitcoin Now" page tries to refresh public data in the browser about every 60 seconds and shows dated saved values for fields it cannot fetch. Check the collection time so a fallback value is not mistaken for a current recommendation.

Check your timing needs and the wallet's fee-adjustment features before choosing. Recommended fee bands are estimates, not guarantees of confirmation by a deadline. RBF and CPFP, explained below, have conditions of their own, and a very low-fee transaction may not be relayed.

Very small outputs can be rejected under node relay policy. Lightning is another option to compare for repeated small payments, but recipient support, fees, routing, and custody conditions need separate checks.

Check the following before signing and broadcasting. The checklist helps avoid relying on cancellation or correction after sending. If any item cannot be confirmed, stop there.

Network selection is one of the checks to make before sending. The ticker "BTC" may refer to Bitcoin or to a separately issued token on another chain, with different receiving methods. When withdrawing from an exchange, match the network name as well as 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.

Pause if pressure to hurry is causing you to skip checks. Scams can demand a payment before you have time to consult someone else. Verify the request, including the claimed urgency, through an independent channel or with someone you trust.

A broadcast transaction is stored in the mempool of nodes that accept it. Not every node holds the same transactions. Miners choose what to include using fee rates, parent-child relationships, and their own policies; this is not a simple queue ranked by the absolute fee amount.

Blocks arrive about every ten minutes on average, but this is not a deadline from sending to receipt. Intervals vary, and finding the next block does not guarantee that your transaction will be included.

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 signaling. "It did not signal RBF, so zero confirmations are safe" no longer holds.

The figure uses the model in whitepaper §11, with attacker hash power set to 10%. Its catch-up probability is about 20% at one confirmation and about 0.024% at six; the same table falls below 0.1% from five. These are calculations under model assumptions, not the loss probability of an individual payment. Six confirmations are not an absolute guarantee against reversal. Check the recipient's required confirmation count.

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.

Distinguish a send operation that has not completed, an unconfirmed transaction, and a confirmed transaction awaiting credit by the receiving service. Start with the sending wallet's status and txid, then compare with your node or a block explorer if needed. Absence from one explorer alone does not prove that a transaction was never broadcast, was cancelled, or lost the funds.

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 signaling. 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.

Removal from one node's mempool does not cancel a transaction. It may remain on other nodes or be rebroadcast and confirm later. Creating another payment merely because the first disappeared from a display risks both confirming and paying twice. Follow the sending wallet's official procedure to check the original transaction and its inputs before creating a potentially duplicate payment.

A small test payment can help check the receiving method and your own procedure. Check deposit or withdrawal minimums and the extra fees first. A successful test does not guarantee the recipient's trustworthiness or the safety of the next payment. Recheck the destination, network, and amount for the main payment too.

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.

Lightning uses different receiving and confirmation procedures; a BOLT11 invoice is one example. Each payment need not wait for an on-chain confirmation, but conditions such as routing and inbound capacity still apply, and payments can fail. Completion time is not guaranteed. "Introduction to the Lightning Network" covers the mechanics and "Paying with Bitcoin" the trade-off.

Moving funds to another wallet of your own still requires checking the destination and network. Follow the new device's official procedure for checking its backup. Do not erase your only working device to test recovery or enter a recovery phrase on an unknown website. The recovery checklist in "Wallets and Security" offers further context.

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.

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 if the recipient chooses to send the funds back. Second, the fee is based on data size rather than amount, so the smaller the transfer, the more heavily the fee weighs in proportion. Third, how many confirmations to wait for is not a standard but a risk-management choice that depends on the amount and the 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. Those are individual recommendations or value judgments, and they sit outside educational commentary.

This page is educational commentary, not investment advice or individualized tax advice. Changes are recorded in the revision history. Fee levels, software defaults, and service terms can change, so check primary sources and your wallet's official procedure at the time you send.