Bitcoin-Adresstypen erklärt

Direkte Antwort

Vergleichen Sie Legacy-, verschachtelte SegWit-, native SegWit- und Taproot-Adressformate, Präfixe, Kompatibilität und Sicherheitsgrenzen.

Zwei Bitcoin-Adressen können beide BTC empfangen und dennoch unterschiedliche Transaktionsstrukturen darunter erzeugen. Eine Hauptnetz-Adresse, die mit 1, eine mit 3, eine bc1q -Adresse und eine bc1p -Adresse können alle gültige Ziele sein, aber sie repräsentieren nicht unbedingt dasselbe Skript, dieselbe Kodierung oder dieselbe zukünftige Ausgabebedingung.

Dieser Unterschied ist leicht zu übersehen, da die Wallet eine Adresse als einzelne Zeichenfolge darstellt. Darunter sagt die Adresse der Software, wie ein Transaktionsoutput konstruiert werden soll. Sobald dieser Output bestätigt ist, wird er zu einem UTXO, das später gemäß den durch diesen Output kodierten Skriptregeln ausgegeben werden muss.

Die praktische Frage ist daher nicht einfach “Welches Präfix ist neuer?”, sondern ob die Adresse zum beabsichtigten Bitcoin-Netzwerk gehört, welchen Output-Typ sie repräsentiert, ob die sendende Software dieses Format unterstützt und was die Adresse Ihnen vor der Autorisierung einer Zahlung sagen kann – und was nicht.

Was eine Bitcoin-Adresse darstellt

Eine Bitcoin-Adresse ist kein Konto im banktechnischen Sinne. Sie enthält kein Bitcoin, hält keinen privaten Schlüssel und bietet keine vollständige Ansicht des Wallet-Guthabens. Sie ist eine menschenlesbare Kodierung, die einer Wallet hilft, einen bestimmten Transaktionsoutput zu konstruieren.

Die vereinfachte Beziehung ist:

Bitcoin-Adresse
        ↓
Adressdekodierung
        ↓
scriptPubKey
        ↓
Transaktionsoutput
        ↓
Bestätigter UTXO
        ↓
Zukünftige Ausgabebedingung

Wenn Sie Bitcoin senden, bewegt die Wallet kein Objekt von einer Adresszeichenfolge zu einer anderen. Sie verbraucht vorhandene UTXOs als Transaktionseingaben und erstellt neue Ausgaben. Die Zieladresse liefert die Informationen, die zum Erstellen einer dieser Ausgaben erforderlich sind.

Aus diesem Grund ist ein Adressformat technisch wichtig. Eine P2PKH-Adresse führt zu einem anderen Ausgabenskript als eine P2WPKH-Adresse. Eine Taproot-P2TR-Ausgabe ist wiederum anders. Diese Ausgaben können alle ausgebbares Bitcoin darstellen, aber die Bedingungen und die Serialisierung, die beim Ausgeben verwendet werden, sind nicht identisch.

Die Adresse ist nicht der private Schlüssel

Der private Schlüssel bleibt von der Adresse getrennt. Eine Wallet verwendet privates Schlüsselmaterial, um die Signatur oder Witness-Daten zu erstellen, die für die Ausgabebedingung erforderlich sind. Die Veröffentlichung einer Empfangsadresse veröffentlicht nicht den privaten Schlüssel.

Das Gegenteil ist ebenfalls wichtig: Das Sehen einer Adresse beweist nicht, dass eine bestimmte Person den entsprechenden Schlüssel kontrolliert. Blockchain-Analyse kann Transaktionen und Outputs beobachten, aber eine Adresszeichenfolge allein ist kein Identitätsnachweis.

Warum mehrere Formate existieren

Bitcoin hat mehrere Adressformate, weil sich das Transaktionssystem weiterentwickelt hat, während die Kompatibilität mit älteren Outputs erhalten blieb. Neue Formate ersetzten keine alten Outputs auf der Blockchain. Stattdessen führten sie zusätzliche Möglichkeiten ein, Ausgabebedingungen auszudrücken.

Die vier Formate, auf die die meisten Benutzer im Bitcoin-Mainnet treffen, sind:

• Legacy P2PKH, üblicherweise angezeigt mit einer Adresse, die mit 1.
• P2SH, üblicherweise beginnend mit 3; verschachteltes SegWit ist eine wichtige Verwendung von P2SH, aber nicht die einzige.
• Natives SegWit, kodiert mit Bech32 und üblicherweise beginnend mit bc1q für Witness-Version 0.
• Taproot, kodiert mit Bech32m und beginnend mit bc1p für Witness-Version-1-P2TR-Outputs.

Die wichtige Änderung ist nicht das Erscheinungsbild der Zeichenfolge. Es ist, was das dekodierte Ziel der Wallet sagt, in den neuen Output zu platzieren.

Bitcoin-Adresstypen im Vergleich

Gebräuchlicher Name	Mainnet-Präfix	Kodierung	Typische Ausgabe	Was Ihnen das Präfix sagt
Legacy	1	Base58Check	P2PKH	Version-Byte-Familie für eine Mainnet-Public-Key-Hash-Adresse
P2SH (einschließlich verschachteltem SegWit)	3	Base58Check	P2SH; verschachteltes SegWit ist eine mögliche Redeem-Skript-Konstruktion	Das Ziel ist P2SH, nicht das genaue Redeem-Skript darin
Natives SegWit	bc1q	Bech32	Witness v0, üblicherweise P2WPKH oder P2WSH	Mainnet-Bech32-Witness-Version-0-Ziel
Taproot	bc1p	Bech32m	P2TR	Mainnet-Witness-Version-1-Taproot-Ziel

Diese Tabelle ist zur Identifizierung nützlich, aber das Präfix ist keine vollständige Beschreibung des zukünftigen Ausgabeverhaltens. Das klarste Beispiel ist eine 3... Adresse: Sie identifiziert P2SH, aber P2SH kann sich auf viele Redeem-Skripte verpflichten. Nested SegWit ist nur eine Möglichkeit.

Legacy-P2PKH-Adressen

Legacy pay-to-public-key-hash, oder P2PKH, ist das Adressformat, das am engsten mit früher Bitcoin-Wallet-Software verbunden ist. Auf dem Mainnet beginnen diese Base58Check-Adressen normalerweise mit 1.

Die Adresse repräsentiert einen Hash eines öffentlichen Schlüssels. Wenn eine Wallet an dieses Ziel zahlt, erstellt sie ein P2PKH-Sperrskript, das eine gültige Signatur und den entsprechenden öffentlichen Schlüssel erfordert, wenn die Ausgabe ausgegeben wird.

OP_DUP
OP_HASH160

OP_EQUALVERIFY
OP_CHECKSIG

Die sichtbare Adresse ist daher nicht das Skript selbst. Die Wallet dekodiert die Base58Check-Adresse, extrahiert Version und Nutzdaten und konstruiert das entsprechende scriptPubKey.

P2PKH-Ausgaben bleiben gültige Bitcoin-Ausgaben. “Legacy” bedeutet nicht ungültig oder automatisch unsicher. Der Unterschied wird relevant, wenn man die Transaktionsstruktur vergleicht: Das Ausgeben einer traditionellen P2PKH-Ausgabe platziert die Entsperrdaten im Eingabeskript, anstatt die SegWit-Witness-Serialisierung zu verwenden.

Dieser Unterschied kann das Transaktionsgewicht im Vergleich zu üblichen SegWit-Schlüsselausgaben erhöhen. Es bedeutet nicht, dass eine P2PKH-Zahlung automatisch eine bestimmte Gebühr hat. Eingabeanzahl, Ausgabeanzahl, gewählte Gebührenrate und der Rest der signierten Transaktion bestimmen weiterhin die endgültigen Kosten.

P2SH und Nested SegWit

Pay-to-Script-Hash, oder P2SH, verlagerte einen Teil der Ausgabelogik hinter einen Hash. Mainnet-P2SH-Adressen verwenden Base58Check und beginnen normalerweise mit 3.

Ein standardmäßiger P2SH-Output platziert den Redeem-Script-Hash im Sperrskript:

OP_HASH160

OP_EQUAL

Das vollständige Redeem-Skript wird nur bereitgestellt, wenn der Output ausgegeben wird. Dies schuf ein wichtiges Kompatibilitätswerkzeug, als SegWit eingeführt wurde: Ein SegWit-Witness-Programm konnte in einem P2SH-Redeem-Skript platziert werden, sodass ein Sender, der gewöhnliche P2SH-Adressen verstand, einen Output bezahlen konnte, der später unter SegWit-Regeln ausgegeben werden würde.

Eine gängige Einzelschlüssel-Konstruktion heißt P2SH-P2WPKH:

P2SH-Adresse
    ↓
Hash des redeemScript
    ↓
redeemScript enthält ein P2WPKH-Witness-Programm
    ↓
Signatur und öffentlicher Schlüssel werden bei der Ausgabe über Witness-Daten bereitgestellt

Ein 3-Präfix beweist kein SegWit

Dies ist eine der wichtigsten Grenzen der visuellen Adressidentifikation. Eine Adresse, die mit 3 beginnt, sagt Ihnen, dass das Ziel die Mainnet-P2SH-Adressversion verwendet. Es offenbart nicht das vollständige Redeem-Skript, bevor der Output ausgegeben wird.

P2SH existierte vor SegWit und kann andere Skripte umhüllen. Jede 3... Adresse als “SegWit-Adresse” zu behandeln, ist daher zu weit gefasst.

Technische Grenze: das Präfix identifiziert das äußere Adressformat. Es beweist nicht das genaue Skript, das hinter einem P2SH-Hash verborgen ist.

Native SegWit und bc1q

Native SegWit entfernt den P2SH-Kompatibilitäts-Wrapper und stellt das Witness-Programm direkt dar. BIP 173 führte die Bech32-Kodierung für native SegWit-Adressen ein.

Im Bitcoin-Mainnet ist der menschenlesbare Teil bc. Witness-Version 0 erzeugt Adressen, die allgemein am Anfang erkennbar sind bc1q.

Zwei häufige Witness-Version-0-Outputs sind:

• P2WPKH: ein 20-Byte-Witness-Programm, das häufig für Einzelschlüssel-Wallet-Zahlungen verwendet wird.
• P2WSH: ein 32-Byte-Zeugenprogramm, das sich auf ein Zeugenskript verpflichtet.

Die Adresse selbst gibt der Wallet die Zeugenversion und das Programm. Für Zeugenversion 0 haben gängige Ausgabeskripte diese Formen:

P2WPKH: OP_0 
P2WSH:  OP_0

Die Ausgabe enthält direkt das Zeugenprogramm anstelle eines P2SH-Wrappers. Wenn die UTXO ausgegeben wird, werden die vom Zeugenprogramm benötigten Signatur- oder Skriptdaten im Transaktionszeugen geliefert, nicht in einem traditionellen P2PKH-Stil-scriptSig.

Bech32 ändert auch die Fehlererkennung

Bech32 ist nicht nur ein anderes Alphabet. Es enthält eine Prüfsumme, die für diese Adressfamilie entwickelt wurde, und trennt den lesbaren Netzwerkteil von den kodierten Zeugendaten.

Bech32-Zeichenfolgen dürfen Groß- und Kleinbuchstaben nicht mischen. Wallets zeigen Bitcoin-Mainnet-Bech32-Adressen normalerweise in Kleinbuchstaben an. Eine vollständig in Großbuchstaben kodierte Zeichenfolge kann gemäß der Spezifikation gültig sein, aber gemischte Groß-/Kleinschreibung ist ungültig.

Taproot und bc1p

Taproot führte Pay-to-Taproot- oder P2TR-Ausgaben ein. P2TR verwendet Witness-Version 1 mit einem 32-Byte-Witness-Programm. Im Bitcoin-Mainnet beginnt die resultierende Adresse mit bc1p.

Witness-Version 1 und höher verwenden Bech32m anstelle der ursprünglichen Bech32-Prüfsumme. BIP 350 führte diese Änderung ein, nachdem eine Schwachstelle in der Verwendung der ursprünglichen Bech32-Prüfsumme für neuere Witness-Versionen festgestellt wurde.

Dies ergibt eine praktische Identifikationsregel:

bc1q... → Zeugenversion 0 → Bech32
bc1p... → Zeugenversion 1 P2TR → Bech32m

Das entsprechende P2TR-Locking-Skript verwendet Witness-Version 1 und einen 32-Byte-Taproot-Ausgabeschlüssel:

OP_1

Eine P2TR-Ausgabe verpflichtet sich auf diesen Taproot-Ausgabeschlüssel. Sie kann später über den Schlüsselpfad oder, wenn ein Skriptbaum festgelegt wurde, über einen gültigen offengelegten Skriptpfad ausgegeben werden.

Die Adresse verrät nicht, welcher Pfad letztendlich verwendet wird. Wenn Sie bc1p sehen, wissen Sie, dass die Ausgabe P2TR ist. Es sagt Ihnen nicht, ob der zukünftige Ausgeber eine Schlüsselpfad-Signatur verwenden oder einen Skriptpfad offenlegen wird.

Was Bitcoin-Präfixe wirklich aussagen

Präfixe sind nützlich, weil sie es einem Menschen ermöglichen, schnell die wahrscheinliche Adressfamilie und das Netzwerk zu identifizieren. Sie sollten als erste Prüfung behandelt werden, nicht als vollständige Validierung.

Beispielanfang	Wahrscheinliche Mainnet-Bedeutung	Was es nicht beweist
1...	P2PKH-Mainnet-Adresse	Eigentümer, Guthaben oder Empfängeridentität
3...	P2SH-Mainnet-Adresse	Dass das Redeem-Skript verschachteltes SegWit ist
bc1q...	Native Witness-Version-0-Adresse	Ob es sich nur anhand des Präfixes um P2WPKH oder P2WSH handelt
bc1p...	P2TR-Witness-Version-1-Adresse	Welcher Taproot-Ausgabepfad später verwendet wird

Das Präfix kann auch nicht die Person authentifizieren, die Ihnen die Adresse gegeben hat. Eine perfekt kodierte, prüfsummengültige Adresse kann dennoch dem falschen Empfänger gehören.

Netzwerk kommt vor Adresstyp

Bevor Sie zwischen Legacy, SegWit oder Taproot wählen, bestätigen Sie, dass die Adresse zum Bitcoin-Netzwerk gehört, das Sie verwenden möchten.

Bech32-Familienadressen machen dies über ihren lesbaren Teil sichtbar. BIP 173 definiert bc für Bitcoin-Mainnet und tb für Bitcoin-Testnet-Adressen. Der lesbare Teil ist daher Teil der Netzwerkvalidierung, nicht Dekoration.

Base58Check-Adressfamilien verwenden auch unterschiedliche Versionsbytes zwischen Mainnet- und Testnetzwerken, auch wenn der Unterschied für einen Benutzer, der nur auf die Zeichenfolge schaut, weniger offensichtlich ist.

Eine Wallet sollte eine nicht unterstützte Netzwerk-/Adresskombination ablehnen, aber die endgültige Verantwortung bleibt, das von der sendenden Anwendung angezeigte Netzwerk zu bestätigen. Die Erkennung des Adressformats ist kein Ersatz für die Netzwerkverifizierung.

Für den breiteren Transaktionskontext – Eingaben, Ausgaben, Bestätigungen und die Bitcoin-Basisschicht – verwenden Sie die Bitcoin-Netzwerkreferenz.

Adresstyp und Transaktionsgebühren

Es ist üblich zu hören, dass eine neuere Bitcoin-Adresse “günstiger” ist. Diese Aussage ist in einigen Vergleichen in der Richtung nützlich, aber zu einfach, um als Gebührenregel zu dienen.

Die vom Empfänger gewählte Adresse beeinflusst den Typ und die serialisierte Größe der heute erstellten Ausgabe. Wichtiger ist, dass der Skripttyp, wenn diese Ausgabe später ausgegeben wird, die Struktur der entsprechenden Transaktionseingabe beeinflusst.

SegWit ändert auch die Weight-Berechnung der Transaktion, da Witness-Bytes anders gewichtet werden als Nicht-Witness-Bytes. Ein üblicher Native-SegWit-Schlüssel-Spend hat daher ein anderes Weight-Profil als ein vergleichbarer Legacy-P2PKH-Spend. Dies beeinflusst die virtuelle Größe, wenn die UTXO ausgegeben wird, legt aber die Gesamtgebühr nicht im Voraus fest.

Der gleiche BTC-Betrag kann zu unterschiedlichen zukünftigen Kosten führen

Betrachten Sie zwei Benutzer, die jeweils den gleichen Betrag an Bitcoin erhalten. Einer erhält eine P2PKH-Ausgabe und der andere eine P2WPKH-Ausgabe. Der Wert ist identisch. Die zukünftige Eingabestruktur ist es nicht.

Wenn diese UTXOs später ausgegeben werden, werden ihre Entsperrdaten unterschiedlich serialisiert. Dies ändert die Transaktions-Weight und damit die virtuelle Größe. Bei gleichem sat/vB-Satz bedeutet unterschiedliche vSize eine andere Gesamtgebühr.

Dies ist ein veranschaulichendes technisches Szenario, kein Benutzertransaktionsdatensatz oder eine Behauptung über eine bestimmte Wallet.

Der Adresstyp bestimmt nicht allein die endgültige Gebühr. Eine Transaktion mit vielen effizienten SegWit-Eingaben kann größer sein als eine mit einer einzigen Legacy-Eingabe. Auch die Anzahl der Ausgaben, Signaturen, Skriptpfade und die gewählte Gebührenrate spielen eine Rolle.

Für den vollständigen Zusammenhang zwischen Weight, virtueller Größe und sat/vB lesen Sie wie Bitcoin-Transaktionsgebühren funktionieren. Wenn Sie eine transaktionsspezifische Schätzung benötigen und keinen konzeptionellen Vergleich, verwenden Sie die Bitcoin-Transaktionsgebührenrechner.

Kompatibilität ist eine Prüfung des Absenders

Eine gültige Bitcoin-Adresse ist für einen Zahlungsablauf nicht nützlich, wenn die sendende Wallet oder der Abhebungsdienst das Format nicht versteht.

Diese Unterscheidung war besonders wichtig bei der Einführung von nativem SegWit und später Taproot. Das Bitcoin-Netzwerk konnte den Ausgabetyp erkennen, während ältere Anwendungen die Erstellung dieses Ziels nicht unterstützten.

Wenn ein Dienst eine bc1q oder bc1p Adresse ablehnt, ändern Sie die Adresse nicht manuell. Entfernen Sie keine Zeichen, ändern Sie nicht das Präfix und konvertieren Sie sie nicht über eine beliebige Website. Verwenden Sie ein Adressformat, das Ihre empfangende Wallet tatsächlich generiert hat und das der Absender ausdrücklich unterstützt.

Das Senden zwischen Formaten ist keine Konvertierung

Sie benötigen keine Legacy-Wallet, um eine Legacy-Adresse zu bezahlen, oder eine Taproot-Wallet, um eine Taproot-Adresse zu bezahlen, im Sinne einer Übereinstimmung von Quell- und Zielformat. Die sendende Transaktion verbraucht alle unterstützten UTXOs, die die Wallet auswählt, und erstellt eine neue Ausgabe für das Zielskript.

Die relevante Frage ist, ob die sendende Software die angeforderte Zielausgabe dekodieren und konstruieren kann.

Eine gültige Adresse kann trotzdem falsch sein

Prüfsummen erkennen bestimmte Übertragungsfehler. Sie authentifizieren nicht den beabsichtigten Empfänger.

Wenn Malware eine kopierte Adresse durch eine andere gültige Bitcoin-Adresse ersetzt, kann die Ersetzung die Prüfsummenvalidierung perfekt bestehen. Das technische Format ist gültig; das Ziel ist falsch.

Deshalb ist “die Wallet hat die Adresse akzeptiert” nicht die endgültige Sicherheitsprüfung. Die Akzeptanz sagt Ihnen, dass die Software ein gültiges oder unterstütztes Ziel erkannt hat. Sie beweist nicht, woher die Adresse stammt.

Überprüfen Sie, bevor Sie senden

Ein nützlicher Überprüfungsprozess trennt Formatvalidierung von Empfängervalidierung.

1. Bestätigen Sie das Netzwerk. Stellen Sie sicher, dass die Wallet oder der Dienst Bitcoin im beabsichtigten Bitcoin-Netzwerk sendet und nicht ein anderes Asset oder eine Testumgebung.
2. Lesen Sie die Adressfamilie. A 1, 3, bc1q oder bc1p Das Präfix gibt Ihnen einen ersten Hinweis auf das Format.
3. Bestätigen Sie die Unterstützung des Absenders. Der Abhebungsdienst oder die Wallet muss das Zielformat ausdrücklich akzeptieren.
4. Überprüfen Sie das Ziel über einen vertrauenswürdigen Kanal. Vergleichen Sie die vollständige Adresse auf einem vertrauenswürdigen Display, wo dies praktikabel ist, anstatt sich nur auf einige erste und letzte Zeichen zu verlassen.
5. Überprüfen Sie den endgültigen Transaktionsbildschirm der Wallet. Bestätigen Sie Empfänger, Betrag, Netzwerkgebühr und etwaiges Wechselgeld, bevor Sie signieren.
6. Schützen Sie privates Material. Die Überprüfung der Empfängeradresse erfordert niemals die Eingabe einer Seed-Phrase oder eines privaten Schlüssels auf einer Website.

Bei großen oder betrieblich sensiblen Überweisungen fügen Organisationen oft unabhängige Verfahren zur Zieladressverifizierung hinzu. Diese Verfahren sind eine betriebliche Kontrolle, keine Eigenschaft eines bestimmten Bitcoin-Adressformats.

Adresswiederverwendung ist ein separates Thema

Eine Bitcoin-Adresse verfällt auf Protokollebene nicht einfach, weil sie einmal verwendet wurde. Wenn die entsprechende Ausgabebedingung kontrollierbar bleibt, können zukünftige Zahlungen an dieselbe Adresse weiterhin gültige Ausgaben erzeugen.

Das macht Adresswiederverwendung nicht wünschenswert. Die Wiederverwendung einer Empfängeradresse kann Transaktionen auf der öffentlichen Blockchain leichter zuordenbar machen und die Privatsphäre verringern.

Diese Datenschutzfrage ist getrennt davon, ob die Adresse P2PKH, P2SH, P2WPKH oder P2TR ist. Ein modernes Adressformat macht die wiederholte Verwendung desselben sichtbaren Ziels nicht privat.

Die Grenzen der Adressvalidierung

Die Formatvalidierung beantwortet eine enge Frage: ob die Zeichenfolge gemäß den relevanten Adressregeln als erwartete Art von Bitcoin-Ziel dekodiert werden kann. Sie authentifiziert nicht die Person, die sie bereitgestellt hat, beweist nicht den Besitz eines privaten Schlüssels, beweist nicht den Gesamtsaldo einer Wallet, garantiert nicht, dass ein Dienst das Format unterstützt, und bestimmt nicht die endgültige Transaktionsgebühr.

Es kann auch keine Informationen preisgeben, die durch die Ausgabekonstruktion absichtlich verborgen wurden. Eine P2SH-Adresse gibt vor dem Ausgeben nicht das vollständige Redeem-Skript preis, und eine P2TR-Adresse sagt Ihnen nicht im Voraus, ob die zukünftige Ausgabe den Schlüsselpfad verwendet oder einen Skriptpfad offenlegt. Behandeln Sie die erfolgreiche Dekodierung als eine Prüfung im Zahlungsprozess, nicht als Beweis dafür, dass jede umgebende Annahme korrekt ist.

Auswahl eines Empfangsformats

Der sicherste Standard ist, eine von der Wallet generierte Adresse zu verwenden, die Sie tatsächlich kontrollieren, anstatt eine Adresse manuell zu erstellen oder zu konvertieren.

Wenn die empfangende Wallet mehr als einen Adresstyp anbietet, verwenden Sie den Typ, der der beabsichtigten Skriptrichtlinie der Wallet entspricht und den der Absender dekodieren kann. Eine P2WPKH-Adresse ist geeignet, wenn die Wallet absichtlich ein Zeugen-Version-0-Schlüssel-Hash-Ziel generiert. Eine P2TR-Adresse ist geeignet, wenn die Wallet absichtlich ein Taproot-Ziel generiert und der Absender es unterstützt. Ältere P2PKH- oder P2SH-Ziele bleiben gültig, wenn ein Arbeitsablauf diese Formate erfordert.

Wählen Sie kein Format nur, weil jemand behauptet, es sei “das günstigste”. Die Ausgabe, die Sie heute erstellen, wird erst dann zu einer Eingabe, wenn sie später ausgegeben wird, und die endgültigen Kosten dieser zukünftigen Transaktion hängen von der vollständigen Transaktionsstruktur und der Gebührenrate ab.

Die Adresse sollte von der empfangenden Wallet stammen. Der Absender sollte sie unterstützen. Das Netzwerk sollte übereinstimmen. Diese drei Prüfungen sind wichtiger als das Jagen eines Präfixes an sich.

Bitcoin-Adressen FAQ

Was ist der Unterschied zwischen bc1q und bc1p?

bc1q ist üblicherweise der Anfang einer Bitcoin-Mainnet-Zeugen-Version-0-Adresse, die mit Bech32 kodiert ist, wie z. B. P2WPKH oder P2WSH. bc1p identifiziert eine Mainnet-Zeugen-Version-1-P2TR-Adresse, die mit Bech32m kodiert ist.

Verwendet jede Bitcoin-Adresse, die mit 3 beginnt, SegWit?

Nein. Eine Mainnet-Adresse, die mit 3 beginnt, ist eine P2SH-Adresse. Verschachteltes SegWit kann P2SH verwenden, aber P2SH kann sich auf andere Redeem-Skripte verpflichten, daher beweist das Präfix allein nicht, dass die Ausgabe verschachteltes SegWit ist.

Sind Bitcoin-Adressen case-sensitiv?

Base58Check-Adressen verwenden ein case-sensitives Alphabet. Bech32- und Bech32m-Kodierungen dürfen Groß- und Kleinbuchstaben nicht mischen; Bitcoin-Wallets zeigen sie normalerweise in Kleinbuchstaben an. Ändern Sie die Groß-/Kleinschreibung einer Adresse nicht manuell.

Kann ich Bitcoin von einem Adresstyp zu einem anderen senden?

Ja, wenn die sendende Wallet das Zielformat unterstützt. Eine Transaktion kann einen unterstützten Eingabetyp ausgeben und einen anderen unterstützten Ausgabetyp erstellen. Quell- und Zielpräfixe müssen nicht übereinstimmen.

Läuft eine Bitcoin-Adresse ab?

Keine Protokollregel lässt eine normale Bitcoin-Adresse nach einem festgelegten Datum oder nach einer Zahlung ablaufen. Wallets generieren oft neue Empfangsadressen, weil Adresswiederverwendung die Privatsphäre verringern kann, nicht weil zuvor generierte Adressen automatisch ungültig werden.

Welchen Bitcoin-Adresstyp sollte ich verwenden?

Verwenden Sie eine von der empfangenden Wallet generierte Adresse für das Bitcoin-Netzwerk und den Skripttyp, den Sie verwenden möchten, und bestätigen Sie dann, dass der Absender dieses Format unterstützt. Natives SegWit ist bei modernen Zahlungen üblich, während Taproot geeignet ist, wenn beide Seiten P2TR unterstützen. Transformieren Sie nicht manuell ein Adressformat in ein anderes.

Technische Quellen

Die obigen Adressformat-Beschreibungen basieren auf Bitcoin Improvement Proposals und Bitcoin Core-Dokumentation. Diese Referenzen definieren Adresskodierungen, Witness-Programme und Skriptverhalten; sie beweisen nicht die Identität oder Sicherheit einer bestimmten Empfängeradresse. Der breitere Quellenansatz von BitcoinToolkit wird auf der Datenquellen page.

• BIP 13: Adressformat für Pay-to-Script-Hash — spezifiziert das Base58Check-P2SH-Adressformat.
• BIP 16: Pay to Script Hash — definiert das P2SH-Ausgabemodell und die Redeem-Skript-Auswertung.
• BIP 49: Ableitungsschema für P2WPKH-verschachtelt-in-P2SH — dokumentiert die in diesem Leitfaden besprochene übliche Einzelschlüssel-Verschachtelungs-SegWit-Konstruktion.
• BIP 141: Segregated Witness — definiert Zeugenprogramme, Transaktions-Weight und SegWit-Ausgabesemantik.
• BIP 173: Base32-Adressformat für native v0-16-Zeugenausgaben — führte die Bech32-native-SegWit-Adresskodierung ein.
• BIP 350: Bech32m-Format für v1+-Zeugenadressen — definiert Bech32m und die Prüfsummenregel für neuere Zeugenversionen.
• BIP 341: Taproot — definiert Taproot-Ausgabe- und Ausgaberegeln, einschließlich P2TR-Zeugenversion 1.
• Bitcoin Core-Ausgabebeschreibungen — dokumentiert strukturierte Beschreibungen üblicher Bitcoin-Ausgabeskripte und Schlüsselausdrücke.

Quellen

1. BIP 13: P2SH-Adressformat
2. BIP 141: Segregated Witness
3. BIP 173: Bech32-native-SegWit-Adressen
4. BIP 350: Bech32m
5. BIP 341: Taproot
6. Bitcoin Core-Ausgabedeskriptoren

Fehler gefunden? Melden Sie ein Inhaltsproblem oder lesen Sie unsere Korrekturrichtlinie.