Bitcoin-Adresse

Alice möchte Bob bezahlen. Bob öffnet in seiner Wallet Empfangen, prüft die angezeigte Adresse und schickt sie als Text oder QR-Code. Alice übernimmt sie in ihre Wallet und kontrolliert vor dem Senden Empfänger und Betrag. Die einzelnen Zeichen muss sie nicht selbst deuten; das übernimmt die Anwendung. Aus der Adresse erstellt die Wallet eine Bedingung, die beim späteren Ausgeben erfüllt werden muss, meist durch eine Signatur mit dem passenden privaten Schlüssel. In der Transaktion wird diese Bedingung als Skript namens scriptPubKey gespeichert. Dort stehen Betrag und Skript, nicht der vertraute Adresstext. Die Adresse ist also eine praktische Zahlungsangabe und kein Behälter, in dem Coins liegen. [1] [3]

Kopieren Sie die lange Adresse oder scannen Sie den QR-Code, statt sie abzutippen. Damit ist die Prüfung nicht abgeschlossen: Schadsoftware kann eine Adresse in der Zwischenablage austauschen. Vergleichen Sie die vollständige Adresse mit den Angaben, die Sie über einen vertrauenswürdigen Weg vom Empfänger erhalten haben. Bei einer Hardware Wallet prüfen Sie zusätzlich das Display des Geräts. Anfang und Ende allein reichen nicht, denn eine betrügerische Adresse kann sie nachahmen. Die Prüfsumme in der Adresse hilft, Tippfehler zu erkennen. Sie bestätigt aber nicht, dass eine korrekt geschriebene Adresse zur gewünschten Person gehört. Die Wallet muss außerdem Format und Netzwerk unterstützen. Eine kleine Testzahlung kann helfen, ersetzt aber keine erneute Prüfung beim nächsten Transfer. Eine bestätigte Zahlung an eine falsche, jedoch gültige Adresse lässt sich im Protokoll nicht einfach stornieren. [2] [7] [8] [18]

Wenn Bob das nächste Mal Empfangen öffnet, kann dort eine andere Adresse stehen. Sein Geld ist deshalb nicht verschwunden. Neue Adressen schützen die Privatsphäre: Wer eine veröffentlichte Adresse kennt, kann deren Zahlungen in der Blockchain verfolgen, sollte dadurch aber nicht automatisch alle Eingänge der Wallet sehen. Wiederverwendung erleichtert genau diese Verknüpfung. Auch neue Adressen garantieren keine Anonymität; spätere Transaktionen können weitere Zusammenhänge offenlegen. Eine Adresse darf für den Empfang geteilt werden, sollte aber nicht gedankenlos überall veröffentlicht werden. Eine Adresse steht auch nicht zwingend für eine Person: Mehrere Menschen können Geld gemeinsam verwalten, oder ein Dienst verwaltet es für seine Kunden. [1] [14]

Eine Wallet verwaltet Schlüssel, findet damit ausgebbare Zahlungen und zeigt deren Summe an. Das Guthaben kann somit von vielen Adressen stammen. Eine übliche HD Wallet erzeugt ganze Familien von Schlüsseln aus einem gemeinsamen Ausgangspunkt. Eine neue Adresse bedeutet deshalb keine neue Wallet. Beim Bezahlen kann die Anwendung einen Restbetrag außerdem an eine eigene Change Address zurückgeben. Für eine Wiederherstellung reichen Adressen allein jedoch nicht aus. Die Sicherung muss die benötigten Schlüssel und deren Ausgaberegeln wiederherstellen können. Viele Wallets verwenden dafür eine Seed Phrase, also Wiederherstellungswörter; komplexere Einrichtungen benötigen gegebenenfalls weitere Angaben. Der Zahlende braucht weder diese Wörter noch Ihre privaten Schlüssel. [10] [14]

Ein QR-Code stellt lediglich Daten dar. Er kann eine einzelne Adresse oder eine mit bitcoin: beginnende Zahlungsanforderung enthalten, ergänzt um Betrag, Empfängerbezeichnung oder Nachricht. BIP21 beschrieb dieses Verfahren, BIP321 erweitert es. Prüfen Sie vor der Freigabe, was die Wallet tatsächlich eingelesen hat. Anfragen für das Lightning Network, etwa eine invoice für eine einzelne Zahlung oder ein offer, über das wiederholt neue invoices angefordert werden können, verwenden einen anderen Zahlungsablauf; Lightning Address erleichtert das Anfordern einer solchen Zahlung. Manche Anforderungen bieten mehrere Zahlungswege. Auch eine Nachrichtensignatur bestätigt nicht automatisch die Identität: BIP322 kann nachweisen, dass die Bedingungen eines Skripts erfüllt werden können. Das belegt für sich genommen weder die rechtliche Identität noch die Zustimmung zu einer beliebigen Rechnung. [15] [16] [17]

Base58Check verbindet ein Versionsbyte mit den Nutzdaten, dem payload. Es fügt die ersten vier Bytes von SHA256(SHA256(version || payload)) hinzu und kodiert das Ergebnis in Base58. Im Mainnet steht 0x00 für P2PKH und 0x05 für P2SH; daraus ergeben sich die üblichen Anfänge 1 und 3. Testnetze verwenden andere Versionen. Das Alphabet lässt die leicht verwechselbaren Zeichen 0, O, I und l aus. Diese 32-Bit-Prüfsumme erkennt viele Tippfehler, bestätigt aber nicht den Empfänger. [2] [3]

Eine native SegWit-Darstellung enthält das Präfix bc fürs Mainnet oder tb fürs Testnet, das Trennzeichen 1, die Witness-Version und Daten in Gruppen zu 5 Bit. Am Ende stehen 6 Prüfsummenzeichen. BIP173 führte Bech32 ein; nach einer Schwäche bei bestimmten Einfügungen und Löschungen behielt BIP350 Bech32 für Version 0 bei und legte Bech32m für Versionen 1–16 fest. Buchstaben dürfen einheitlich klein oder groß, aber nie gemischt sein. Die Kodierungsgrenze beträgt 90 Zeichen. Auch eine gültige Darstellung kann zum falschen Netz oder zu einer nicht unterstützten Version gehören. [7] [8]

P2PKH und P2WPKH verweisen auf einen 20 Byte langen HASH160 eines öffentlichen Schlüssels. P2SH nutzt HASH160 des redeemScript, P2WSH hingegen SHA256 des witnessScript. SegWit v0 erkennt damit P2WPKH mit 20 Byte und P2WSH mit 32 Byte. P2TR nach BIP341 ist anders: Sein Programm der Version 1 enthält den angepassten, 32 Byte langen x-only-Ausgabeschlüssel Q, keinen Hash eines gewöhnlichen Empfangsschlüssels. In Q kann auch die Wurzel eines Baums zusätzlicher Skripte einfließen. Dadurch ist der Schlüssel kryptografisch an diese Ausgabebedingungen gebunden. Die Adresse zeigt daher nicht alle Ausgabemöglichkeiten. [6] [9]

Frühe Bitcoin-Outputs zahlten häufig direkt an einen öffentlichen Schlüssel. P2PKH verschob dessen Offenlegung auf die Ausgabe. BIP13 und BIP16 ermöglichten mit P2SH die Weitergabe eines Hashes komplexerer Scripts. BIP141 ergänzte versionierte Witness-Programme, BIP173 Bech32 und BIP341 mit BIP350 das Taproot-Format mit Bech32m. Hinter dem anderen Aussehen stehen andere Prüfbedingungen. „Konvertieren“ Sie eine Adresse nicht durch manuellen Austausch des Präfixes: Es könnte ein anderer oder unausgebbarer Output entstehen. Einige nicht standardisierte Skripte und frühe pay-to-pubkey-Ausgänge haben keine gewöhnliche kanonische Adresse. [4] [5] [6] [7] [8] [9] [3]

Eine HD Wallet nach BIP32 leitet viele Schlüssel aus einer gemeinsamen Wurzel ab. Die Pfade unterscheiden Ausgabetypen: BIP44 nutzt den Zweck 44' für P2PKH, BIP84 den Zweck 84' für P2WPKH und BIP86 den Zweck 86' für P2TR mit einem Schlüssel. Danach folgen der Münztyp (coin type), das Konto, der Empfangs- oder change-Zweig und der Adressindex. Eine Seed Phrase allein bestimmt möglicherweise nicht alle Pfade, Konten und Multisig-Regeln. Ein Output Descriptor hält auch Schlüsselherkunft und Script-Aufbau fest. Wiederherstellung muss die tatsächlichen Mittel finden, nicht nur eine bekannte Adresse erneut anzeigen. [10] [11] [12] [13] [14]

P2PKH und P2WPKH zeigen anfangs gewöhnlich einen Schlüsselhash; bei der Ausgabe wird der öffentliche Schlüssel offengelegt. P2SH und P2WSH offenbaren das verwendete redeemScript beziehungsweise witnessScript. Taproot enthält schon im Output einen angepassten öffentlichen Schlüssel. Ein key-path spend ergänzt üblicherweise eine Schnorr Signature, ein script-path spend legt das gewählte Script, den control block und den Merkle-Pfad offen; ungenutzte Zweige können verborgen bleiben. Nicht jede Adresse verbirgt also den öffentlichen Schlüssel. [6] [9]