Bitcoin address

Alice wants to pay Bob. Bob opens Receive in his wallet, checks the address shown and sends it as text or a QR code. Alice loads it into her wallet and checks the recipient and amount before sending. Neither person needs to interpret every character: the application handles that. From the address, the wallet constructs a condition that must be met to spend the money later, usually by signing with the right private key. The transaction records this condition as a script called scriptPubKey. It stores an amount and a script, not the familiar address text. An address is therefore a convenient way to share payment details, rather than a container with coins inside. [1] [3]

Copy the long address or scan its QR code instead of typing it. Your checks should not end there: clipboard malware can replace the intended address with another one. Compare the complete address with the details obtained from the recipient through a trusted channel; if you use a Hardware Wallet, check its own display too. Matching the beginning and end is not enough, since a fraudulent address can imitate them. Addresses contain a checksum, a way to catch typing errors. It cannot tell whether a correctly written address belongs to the intended person. Your wallet must also support the format and network. A small test payment can help, but does not replace checking the address on the next transfer. The protocol offers no simple cancellation of a confirmed payment to a wrong yet valid address. [2] [7] [8] [18]

When Bob opens Receive next time, he may see a different address. This does not mean his money has disappeared. A fresh receiving address helps privacy: someone who knows a published address can follow payments to it on the blockchain, but should not automatically gain a view of every payment the wallet receives. Reusing an address makes that connection easier. Fresh addresses still do not guarantee anonymity; later transactions can reveal other links. An address can be shared for payment, but that does not make publishing it everywhere harmless. Nor does one address mean one person: several people may manage funds together, or a service may hold them for customers. [1] [14]

A wallet manages keys, finds payments it can spend and shows their total. Its balance can therefore come from many addresses. A typical HD Wallet generates families of keys from a common starting point, so a new address does not mean opening another wallet. When making a payment, the application may also return unused funds to its own Change Address. Addresses alone are not enough for recovery, though. A backup must restore the necessary keys and their spending rules. Many wallets use a Seed Phrase, a set of recovery words, for this; more complex arrangements may need additional information. The payer never needs those words or your private keys. [10] [14]

A QR code is simply a way to represent information. It can contain an address alone or a payment request beginning bitcoin: with an amount, recipient label or message. BIP21 described this scheme and BIP321 extends it. Check what your wallet actually loaded before approving payment. Lightning Network requests, such as an invoice for one payment or an offer from which fresh invoices can be requested repeatedly, use a different payment flow; Lightning Address makes requesting such a payment easier. Some requests offer several ways to pay. Likewise, signing a message does not automatically identify a person: BIP322 can demonstrate that a script’s conditions can be met, but does not by itself establish legal identity or approval of an arbitrary invoice. [15] [16] [17]

Base58Check combines a version byte with the data called payload. It appends the first four bytes of SHA256(SHA256(version || payload)) and encodes the result in Base58. On mainnet, version 0x00 denotes P2PKH and 0x05 denotes P2SH, hence the usual leading 1 or 3. Test networks use other versions. The alphabet omits easily confused 0, O, I and l. This 32-bit checksum catches many typing errors but cannot authenticate the recipient. [2] [3]

A native SegWit representation includes prefix bc for mainnet or tb for testnet, separator 1, a witness version and data split into 5-bit groups. It ends with 6 checksum characters. BIP173 introduced Bech32; after a weakness involving certain insertions and deletions emerged, BIP350 retained Bech32 only for witness version 0 and specified Bech32m for versions 1–16. Letters may be uniformly lowercase or uppercase, but never mixed. The encoding limit is 90 characters. Even a valid representation can refer to the wrong network or an unsupported version. [7] [8]

P2PKH and P2WPKH refer to a 20-byte HASH160 of a public key. P2SH uses HASH160 of redeemScript, while P2WSH uses SHA256 of witnessScript. SegWit v0 thus recognizes 20-byte P2WPKH and 32-byte P2WSH. P2TR under BIP341 differs: its version 1 program contains a 32-byte tweaked x-only output key Q, not a hash of an ordinary receiving key. Q can also incorporate the root of a tree of additional scripts, cryptographically linking the key to those spending conditions. The address alone therefore cannot reveal every spending option. [6] [9]

Early Bitcoin outputs often paid directly to a public key. P2PKH delayed its disclosure until spending. BIP13 and BIP16 allowed P2SH to convey a hash of a more complex script. BIP141 added versioned witness programs, BIP173 Bech32, and BIP341 with BIP350 the Taproot format using Bech32m. Different appearances thus reflect different verification conditions. Do not manually “convert” an address by replacing its prefix: you may create a different or unspendable output. Some nonstandard scripts and early pay-to-pubkey outputs have no ordinary canonical address. [4] [5] [6] [7] [8] [9] [3]

An HD Wallet under BIP32 derives many keys from a common root. Paths distinguish output types: BIP44 uses purpose 44' for P2PKH, BIP84 purpose 84' for P2WPKH, and BIP86 purpose 86' for single-key P2TR. Next come coin type, account, receiving or change branch, and address index. A Seed Phrase alone may not specify every path, account and Multisig rule. An Output Descriptor also records key origins and script construction. Recovery must find the actual funds, not merely display one familiar address again. [10] [11] [12] [13] [14]

P2PKH and P2WPKH usually expose a key hash initially; spending reveals the public key. P2SH and P2WSH reveal the redeemScript or witnessScript used. Taproot already includes a tweaked public key in the output. A key-path spend normally adds a Schnorr Signature, while a script-path spend reveals the selected script, control block and Merkle path; unused branches may remain hidden. It is therefore incorrect to say that every address hides the public key. [6] [9]