Bitcoin Address Verification Before Sending

Address Confirmation and Transaction Safety

This memo is published by CustodyStress, an independent Bitcoin custody stress test that produces reference documents for individuals, families, and professionals.

What Verification Attempts to Confirm

Bitcoin address verification before sending exists because Bitcoin transactions cannot be reversed. Once broadcast to the network and confirmed, the transaction is permanent. Wrong-address sends result in permanent loss. Verification procedures develop in response to this finality.

People search for bitcoin address verification before sending when preparing to make their first transaction or after hearing about address errors. The search reflects awareness that something can go wrong permanently. The question asks what verification can prevent and what it cannot.

---

What Verification Attempts to Confirm

Address verification procedures attempt to confirm that the address shown on the screen matches the address stored in the sending device. A hardware wallet shows an address on its own screen. Software wallets display addresses in their interface. The verification compares these displays.

Character-by-character comparison forms the foundation of most verification approaches. Bitcoin addresses contain 26 to 35 characters. Each character matters. A single wrong character sends Bitcoin to a different address. Full comparison checks every character in sequence.

Partial verification shortcuts emerge from tedium. First four characters, last four characters, middle section sampling. These patterns reduce cognitive load while attempting to maintain error detection. The assumption is that random address corruption will appear in the sampled sections.

What verification confirms is display agreement. The hardware wallet screen and the computer screen show the same string. This agreement reveals nothing about whether the address belongs to the intended recipient. Display consensus is necessary but not sufficient for correct sending.

---

The Trust Boundary in Device Displays

Verification assumes the hardware wallet display is trustworthy. The hardware wallet is designed to show the address that will actually receive the Bitcoin. Malware on the computer might alter the address shown in software, but the hardware wallet display is supposed to resist such attacks.

This creates a trust boundary. What the computer shows might be wrong. What the hardware wallet shows is treated as true. Verification checks whether these two displays agree, with the hardware wallet serving as reference.

The boundary breaks when the hardware wallet itself is compromised. Supply chain attacks replace components before purchase. Firmware vulnerabilities alter display behavior. Physical tampering modifies the device after acquisition. In these cases, the hardware wallet display shows an attacker-controlled address while appearing to function normally.

Verification between two compromised displays produces false confidence. Both devices show the same wrong address. Character-by-character checking passes. The verification procedure executes perfectly while verifying the wrong thing.

---

When Time Pressure Overrides Procedure

Time pressure degrades verification completeness. Market conditions create urgency. A seller expects payment within minutes. An exchange withdrawal window closes. Someone waits on the phone while the transaction processes.

Under time pressure, full character checking collapses to partial checking. First four, last four becomes first two, last two. Visual pattern matching replaces character reading. The brain recognizes the address shape rather than confirming its content.

Interruptions during verification create a restart problem. The sender begins checking characters, gets distracted, returns to the screen. Did they finish? Did they start over? Uncertainty about completion status leads to re-checking or to proceeding despite incompleteness.

The risk shifts from wrong-address sending to wrong-verification methodology. The address might be correct. The verification might be incomplete. Time pressure makes it difficult to know which condition exists.

---

Visual Similarity Attacks

Bitcoin addresses use alphanumeric characters that include visually similar symbols. The number zero and the letter O appear nearly identical in some fonts. The number one and lowercase L create confusion. The letter I and vertical bar pose similar problems.

Attackers exploit these similarities. An address differing by a single character might look identical during quick verification. The sender reads "1" while the character is "l". The sender reads "O" while the character is "0". Character-by-character verification fails when characters are misread rather than skipped.

Font rendering affects detection rates. Some display fonts clearly differentiate similar characters. Others make distinction difficult. The hardware wallet uses one font. The computer uses another. A character pair that looks different on one screen might look identical on the other.

This failure mode is independent of device compromise. Both displays show the correct address. The human verification step misreads a character. The error occurs in interpretation, not in the technology.

---

Copy-Paste Verification Gaps

Copy-paste operations move addresses between applications. The sender copies an address from email, a website, or a message. They paste it into their wallet software. Verification compares what was copied to what appears in the sending interface.

Clipboard malware intercepts copy operations. The sender copies one address. The malware replaces it with a different address. The sender pastes and sees the attacker's address. They then verify this address against... what? The original source is on a different screen, in a different application, or has scrolled away.

Verification often compares the pasted address to the hardware wallet display. If the clipboard was compromised, both the software and the hardware wallet will show the attacker's address. The hardware wallet displays what the software sent it. Verification between these two displays succeeds while confirming the wrong address.

The gap exists because verification checks display consistency, not source authenticity. The source address might never appear in the verification process. What gets verified is whether the computer and hardware wallet agree about the address currently in the transaction, not whether that address matches the intended destination.

---

QR Code Trust Assumptions

QR codes encode addresses as visual patterns. The sender scans a QR code with their phone or hardware wallet camera. The device decodes the pattern into an address. This eliminates manual character entry and copy-paste vulnerabilities.

QR code verification introduces new trust dependencies. The QR code itself becomes a potential attack surface. A printed QR code on a receipt might be replaced with a sticker. A QR code displayed on a compromised website might encode the wrong address. A QR code generator might insert different addresses than requested.

Verification after QR scanning faces the same display comparison problem. The decoded address appears on the device screen. The sender verifies this against... the QR code? The QR code contains no human-readable information. Verification compares the decoded address to the source that provided the QR code, requiring screen switching and information retention.

The cognitive load differs from character-by-character verification but the fundamental problem remains. The sender must confirm that what the device decoded matches what the sender intended, without the QR code itself providing human-verifiable content.

---

Address Reuse and Verification Fatigue

Sending to the same address repeatedly creates verification fatigue. The first transaction gets full attention. Every character gets checked. Subsequent transactions to the same address receive less scrutiny. The address becomes familiar. Familiarity breeds assumption.

The sender begins to recognize the address pattern rather than verifying its content. They see the first few characters and assume the rest. This works until the address changes. The recipient generates a new address. The sender's visual pattern matching continues using the old pattern. The new address goes unnoticed.

Address book features compound this problem. The sender saves a verified address with a label. Later transactions select the label rather than the address. Verification shifts from checking the address to checking that the correct label was selected. If the address book itself is compromised or if the saved address was wrong initially, label verification confirms nothing about address correctness.

Verification fatigue also affects character checking completeness. Each repeated transaction to the same recipient makes full verification feel unnecessary. The shortcut from full checking to partial checking to pattern recognition happens gradually. The failure occurs when the address changes but the verification procedure does not scale back up to full checking.

---

When Multiple Addresses Appear

Some transactions involve multiple recipient addresses. Batch payments send to several addresses in one transaction. The sender must verify each address independently. Verification load scales linearly with address count.

Cognitive capacity does not scale linearly. Verifying one address takes full attention. Verifying five addresses introduces fatigue and error accumulation. The sender begins to skip characters, sample instead of checking completely, or trust that if the first three addresses were right, the rest are too.

Address position creates verification asymmetry. The first address gets thorough checking. The last address gets minimal checking. An attacker who controls address generation might place the wrong address late in the sequence, exploiting verification fatigue.

This failure surface exists even when all displayed addresses are correct. The verification procedure degrades under volume. What works for single-address verification breaks down under multiple-address load.

---

Test Transactions as Verification

Test transactions send small amounts before sending large amounts. The sender transmits a small value, waits for the recipient to confirm receipt, then sends the remainder. This approach uses economic consequences to verify address correctness.

Test transactions confirm that the address exists and can receive Bitcoin. They do not confirm that the address belongs to the intended recipient. An attacker-controlled address will receive the test transaction and can confirm receipt. The recipient thinks the test succeeded. The full amount follows to the wrong address.

Test transactions also create timing windows. The sender waits for confirmation. During this wait, conditions might change. The recipient switches to a new address. The sender completes the test successfully, then sends the full amount to an address the recipient no longer monitors.

The procedure adds steps and time but does not eliminate the verification problem. Address correctness still depends on confirming that the tested address belongs to the intended party. The test confirms deliverability, not ownership.

---

When Communication Channels Are Compromised

Address communication happens through email, messaging apps, phone calls, or in-person exchanges. Each channel introduces verification dependencies beyond the address itself.

Email compromise allows attackers to send addresses from legitimate accounts. The sender receives an address that appears to come from the correct person. Verification confirms the address matches what was received. The received address itself is malicious.

Man-in-the-middle attacks alter addresses during transmission. The recipient sends the correct address. The attacker intercepts and modifies it. The sender receives the modified version. Verification of the received address succeeds while confirming the attacker's address.

Out-of-band verification attempts to solve this by using multiple channels. The address arrives via email. Verification happens via phone call. This works only if both channels are not compromised. If the attacker controls both channels or if the recipient's systems are compromised, multi-channel verification confirms the wrong address through multiple independent confirmations.

---

Display Accuracy Limits

All verification depends on display accuracy. The screen must show what the device actually intends to send. Display failures create a gap between internal state and external presentation.

Hardware failures affect character rendering. A damaged display might show "3" as "8" or "B" as "8". The device internally has the correct address. The display shows a corrupted version. Verification using this display confirms the wrong thing.

Software rendering bugs create similar problems. Unicode handling errors might substitute similar-looking characters. Font antialiasing might blur character distinctions. Screen resolution limits might make small characters unreadable.

These failures are not attacks. They are technical limitations. Verification procedures assume displays accurately represent internal data. When this assumption breaks, verification confirms display content rather than transaction content.

---

Summary

Bitcoin address verification before sending attempts to prevent permanent loss from wrong-address transactions. Verification procedures check whether displayed addresses match across devices and sources. These checks confirm display agreement, not address ownership.

Verification fails through device compromise, time pressure, visual similarity misreading, clipboard attacks, QR code manipulation, verification fatigue, multi-address cognitive load, test transaction misinterpretation, communication channel attacks, and display accuracy limits. Each failure mode allows verification to complete successfully while confirming the wrong address.

The gap between verification and correctness exists because verification checks procedural compliance and display consistency. What verification cannot confirm is whether the address belongs to the intended recipient. Understanding what verification reveals and what it assumes is essential to understanding why wrong-address transactions occur despite verification attempts.

---

System Context

Bitcoin Custody Failure Modes

Bitcoin Purchase Verification Methods Across Channels

Test Seed Phrase Without Moving Bitcoin

← Return to CustodyStress