Bitcoinová adresa

Výstup transakce obsahuje částku a bajty scriptPubKey; běžný text adresy v něm není. Peněženka adresu dekóduje, ověří síť a checksum a sestaví například OP_DUP OP_HASH160 <20bajtový hash> OP_EQUALVERIFY OP_CHECKSIG nebo verzovaný witness program. Průzkumník blockchainu naopak rozpoznaný skript převádí zpět na adresu pro zobrazení. Nestandardní skript ani raný pay-to-pubkey nemusejí mít jedinou kanonickou adresu. [Bitcoin whitepaper — Transactions and Privacy] [Bitcoin Core — destination encoders and decoders]

Base58Check serializuje verzový bajt a payload, připojí první čtyři bajty SHA256(SHA256(verze || payload)) a výsledek zapíše v Base58. Na mainnetu značí 0x00 P2PKH a 0x05 P2SH, odtud obvyklé počáteční 1 a 3; testovací sítě mají jiné verze. Abeceda vynechává 0, O, I a l. 32bitový checksum zachytí mnoho přepisů, není však podpisem ani ověřením příjemce. [Bitcoin Core — Base58Check implementation] [Bitcoin Core — destination encoders and decoders]

Nativní segwitová adresa má human-readable part bc pro mainnet či tb pro testnet, oddělovač 1, witness verzi, data převedená na pětibitové skupiny a šestimístný polymod checksum. BIP173 přiděluje Bech32 pouze verzi 0; po odhalení slabiny vůči některým vložením a smazáním požaduje BIP350 pro verze 1–16 Bech32m. Celý zápis smí být jednotně malými či velkými písmeny, nikdy smíšeně, a má nejvýše 90 znaků. Formálně platný kód může přesto patřit jiné síti nebo nepodporované budoucí verzi. [BIP 173 — Base32 address format for native v0 witness outputs] [BIP 350 — Bech32m format for witness v1 and later]

P2PKH a P2WPKH zavazují k 20bajtovému HASH160 veřejného klíče. P2SH zavazuje k HASH160 redeemScriptu, P2WSH k SHA256 witnessScriptu. SegWit v0 proto rozeznává přesně 20bajtový P2WPKH a 32bajtový P2WSH program. P2TR je jiné: jeho 32bajtový program verze 1 je upravený x-only výstupní klíč Q, který může současně zavazovat k Merkleovu kořeni skriptů, nikoli hash běžného přijímacího klíče. Úplná politika utracení z adresy vyčíst nejde. [BIP 141 — Segregated Witness consensus layer] [BIP 341 — Taproot validation and output keys]

Nejstarší bitcoinové výstupy často platily přímo na veřejný klíč. P2PKH odsunulo jeho zveřejnění do okamžiku utracení a Base58Check usnadnil předávání. BIP13/BIP16 schovaly složité podmínky za P2SH, takže odesílatel zavázal jen k hashi skriptu. BIP141 zavedl verzované witness programy a BIP173 pro v0 Bech32; Taproot podle BIP341 přinesl v1 a BIP350 Bech32m. Jde o změny skriptu a konsensu, ne vzhledu prefixu; ruční „převod“ může vytvořit jinou podmínku nebo neutratitelný výstup. [BIP 13 — Address Format for pay-to-script-hash] [BIP 16 — Pay to Script Hash] [BIP 141 — Segregated Witness consensus layer] [BIP 173 — Base32 address format for native v0 witness outputs] [BIP 350 — Bech32m format for witness v1 and later] [BIP 341 — Taproot validation and output keys]

Peněženka BIP32 odvozuje z rozšířeného kořene mnoho klíčů. Běžné přijímací cesty oddělují rodiny: BIP44 používá purpose 44' pro P2PKH, BIP84 84' pro nativní P2WPKH a BIP86 86' pro jedno-klíčový P2TR; následují účet, vnější/change větev a index. Seed phrase sama nemusí určit typ skriptu, cestu, účty ani multisig politiku. Output descriptor uchová klíče, jejich původ, větve a konstrukci skriptu úplněji; obnovu je nutné otestovat, ne pouze znovu nalézt jednu známou adresu. [BIP 32 — Hierarchical deterministic wallets] [BIP 44 — Multi-account hierarchy] [BIP 84 — Derivation for native P2WPKH] [BIP 86 — Derivation for single-key P2TR] [Bitcoin Core — Output descriptors]

P2PKH či P2WPKH nejprve ukazuje hash klíče, při utracení se obvykle zveřejní veřejný klíč. P2SH a P2WSH při použití dané cesty odhalí redeemScript či witnessScript. P2TR už ve výstupu nese upravený x-only klíč; key-path spend odhalí jen Schnorrův podpis, script-path spend vybraný leaf, control block a Merkleovu cestu, zatímco nepoužité listy mohou zůstat skryté. Tvrzení „adresa skrývá veřejný klíč“ tedy neplatí obecně. [BIP 141 — Segregated Witness consensus layer] [BIP 341 — Taproot validation and output keys]

Opakované použití adresy propojí platby ke stejnému zamykacímu skriptu a zesílí heuristiky clusterování. Peněženky proto odvozují novou externí adresu a change posílají na interní větev. Adresa však není osoba: jeden skript může ovládat více lidí, jeden člověk tisíce skriptů a burza prostředky sdružuje. „Zůstatek adresy“ v exploreru je součet dosud neutracených výstupů se shodným rozpoznaným skriptem, nikoli položka konsensuálního účtu. Heuristiky common-input a change mají výjimky a nejsou důkazem vlastnictví. [Bitcoin whitepaper — Transactions and Privacy] [Bitcoin Core — Output descriptors]

Software má odmítnout chybný checksum, jinou síť, smíšenou velikost písmen a nesoulad witness verze s Bech32/Bech32m. Nezastaví však malware, který ve schránce nahradí adresu jinou platnou, napadený web s cizím QR ani záměnu kontaktu. U významné částky ověřte celý údaj nebo platební požadavek na důvěryhodném displeji, ideálně přímo na hardwarové peněžence, a zvažte malý test. Kontrola jen prvních a posledních znaků podlehne look-alike adresám; potvrzenou platbu na chybný platný skript protokol neumí vrátit. [Bitcoin Core — Base58Check implementation] [BIP 173 — Base32 address format for native v0 witness outputs] [BIP 350 — Bech32m format for witness v1 and later]

Holá adresa není totéž co URI bitcoin: podle BIP21, které může nést částku, label, message či další platební instrukci. Není ani Lightning invoice, offer nebo Lightning Address; ty řídí off-chain platbu a někdy mohou být přibaleny k on-chain fallbacku. Podpis zprávy podle BIP322 může v daném schématu prokázat kontrolu skriptu, ne právní totožnost, vlastnictví všech výstupů ani autorizaci konkrétní faktury. Pro složité politiky a zálohy je správným objektem descriptor či nativní export peněženky, ne jedna adresa. [BIP 21 — URI scheme] [BIP 322 — Generic signed message format] [Bitcoin Core — Output descriptors]