Eine nicht ganz einfache Aufschlüsselung verschiedener Ausgabearten und deren Adressformate

Free Bitcoins: FreeBitcoin | BonusBitcoin

Coins Kaufen: Bitcoin.deAnycoinDirektCoinbaseCoinMama (mit Kreditkarte)Paxfull

Handelsplätze / Börsen: Bitcoin.de | KuCoinBinanceBitMexBitpandaeToro

Lending / Zinsen erhalten: Celsius NetworkCoinlend (Bot)

Cloud Mining: HashflareGenesis MiningIQ Mining


Niemand hat mich in letzter Zeit nach verschiedenen Ausgabetypen und deren Adresskodierungen gefragt, aber ich hatte nach dem Lesen Lust, meine eigene Beschreibung zu schreiben [a recent similar post](https://www.reddit.com/r/Bitcoin/comments/rjdao2/people_keep_asking_me_about_the_different_types/). Ich werde nur Ausgabetypen behandeln, die eine einzelne Signatur verwenden.

**"Alte Ausgaben" aka Pay to Public Key Hash (P2PKH)**
P2PKH war der erste Ausgabetyp, der einen Adressstandard erhielt. Adressen für P2PKH-Ausgaben beginnen mit „1“ und verwenden die *Base58Check*-Kodierung. Die Adresscodierung stellt eine Prüfsumme bereit und stellt eine Kurzform zur Übermittlung von Empfängerinformationen dar – was die UX gegenüber der vorherigen Situation verbesserte, in der der Absender den vollständigen öffentlichen Schlüssel oder das nicht standardmäßige Ausgabeskript des Empfängers verarbeiten musste, um eine Transaktion zu senden.

Beispiel:

>*1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2*

Probleme:

* Groß-/Kleinschreibung beachten
* Hohe Transaktionsgebühr
* Größerer Daten-Footprint als Pay-to-Public-Key

**"Wrapped Segwit Outputs" alias Pay to Script Hash-wrapped Pay to Witness Public Key Hash (P2SH-P2WPKH)**
Segwit zielte darauf ab, a . einzuführen [new family of output types](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki), die wir als *native segwit* bezeichnen, aber die Autoren erkannten, dass die Einführung eines neuen Adressformats Zeit in Anspruch nehmen würde. Der Segwit-Softfork führte zusätzlich *wrapped segwit*-Ausgaben als Übergangslösung ein, um aufwärtskompatibel zu Wallets zu sein, die an P2SH-Adressen senden könnten. Da P2SH im März 2012 eingeführt wurde und bereits weit verbreitet für Multisig verwendet wurde, unterstützten die meisten Wallet-Softwares das Senden an P2SH, als Segwit 2017 aktiviert wurde. Verpackte Segwit-Adressen sind von anderen P2SH-Anwendungen nicht zu unterscheiden, bis sie ausgegeben wurden. P2SH-Adressen beginnen mit dem Präfix „3“ und verwenden die *Base58Check*-Codierung wie P2PKH-Adressen.

Verpackte Segwit-Ausgaben sperren Gelder an ein *P2SH-Programm*, aber ihr Eingabeskript enthält ein *Zeugen-Programm*, das die Skript-Validierung an den *Zeugen-Stack* umleitet. Dadurch wurde zwar Vorwärtskompatibilität erreicht, die Umleitung erfordert jedoch zusätzliche Daten, die an das Netzwerk weitergeleitet und in der Blockchain gespeichert werden müssen. Da Witness-Daten bei der Bewertung des Transaktionsgewichts um 75 % reduziert werden, sind umschlossene Segwit-Eingaben kostengünstiger zu erstellen, selbst wenn ihr Daten-Footprint größer ist als der von P2PKH.
Alle P2SH-Adressen beginnen mit „3“.
Beispiel:

>*347N1Thc213QqfYCz3PZkjoJpNv5b14kBd*

Probleme:

* Groß-/Kleinschreibung beachten
* Umleitung zum Witness-Stack zur Auswertung fügt zusätzliche Daten hinzu
* Noch größerer Daten-Footprint als P2PKH

**Native Segwit-Ausgaben**
Anstatt Gelder an ein *P2SH-Programm* zu binden, enthält das Ausgabeskript für native Segwit-Ausgaben direkt das W*itness-Programm*. Auf diese Weise benötigen native Segwit-Eingaben nur einen Zeugen-Stack und kommen ohne die Umleitungsdaten aus, die in der umschlossenen Segwit-Konstruktion benötigt werden, sodass nur ein Stub der Länge Null für das Eingabeskript übrig bleibt. Native Segwit-Ausgaben werden mit *bech32*-Adressen für Version 0 und *bech32m* für Version 1–16 dargestellt. Die bech32-Codierung erfolgt in Einzelbuchstaben, was das Aufzeichnen und Diktieren erleichtert sowie die Codierung in QR-Codes effizienter macht. Die bech32-Codierung wurde entwickelt, um Fehlererkennungsgarantien zu bieten. Bech32- und bech32m-Adressen beginnen mit „bc1“.

**0) P2WPKH, auch bekannt als Native Segwit v0**
Pay to Witness Public Key Hash wird oft einfach als "nativer Segwit" bezeichnet und gibt Sperrgelder an einen öffentlichen Schlüssel-Hash aus, ähnlich wie bei P2PKH. P2WPKH-Eingaben stellen jedoch den öffentlichen Schlüssel und die Signatur im Witness-Stack anstelle des Eingabeskripts bereit und profitieren so vom Zeugenrabatt. Bech32-Adressen, die die nativen Segwit-Ausgaben der Version 0 codieren, beginnen mit „bc1q“, da „q“ 0 in bech32 codiert.

Beispiel:

>*bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4*

Problem:

* Bech32-Adressen werden von einigen Wallets und Diensten immer noch nicht unterstützt

**1) P2TR alias Taproot alias Native Segwit v1**
Mit der kürzlich erfolgten Aktivierung von Taproot fügen wir unserem Portfolio native Segwit-v1-Ausgaben hinzu. Zahlungen an Taproot-Ausgaben sperren Gelder direkt an einen öffentlichen Schlüssel im *Zeugen-Programm* der Ausgabe, was (für Single-Sig-Anwendungen) bedeutet, dass die Eingabe nur ein einziges Skriptargument, eine Signatur, benötigt, anstatt beide einen öffentlichen Schlüssel bereitstellen zu müssen und Signatur wie P2WPKH. P2TR verwendet Schnorr-Signaturen, die kompakter kodiert sind als ECDSA-Signaturen, wodurch die Signaturgröße von 71-72 B auf 64 B reduziert wird. Dies bedeutet, dass P2TR den kleinsten Daten-Footprint hat, selbst wenn das Gesamtgewicht der Ein- und Ausgabe etwas größer ist als bei P2WPKH. Darüber hinaus können komplexere Ausgabebedingungen in den Blättern des Taptree kodiert werden, die in den öffentlichen Schlüssel des Zeugenprogramms optimiert werden. Bech32m-Adressen, die P2TR-Ausgaben kodieren, sind länger als die bech32-Adressen, die P2WPKH-Ausgaben kodieren, da öffentliche Schlüssel länger sind als der 20-Byte-Hash, der in P2WPKH verwendet wird. Adressen für P2TR-Ausgänge beginnen mit „bc1p“, weil „p“ 1 codiert.

Beispiel:

>*bc1p5d7rjq7g6rdk2yhzks9smlaqtedr4dekq08ge8ztwac72sfr9rusxg3297*

Problem:

* Bech32m-Adressen sind brandneu und werden noch nicht von vielen Wallets und Diensten unterstützt

**Kostenüberlegungen**

[Byte length vs weight vs vsize for single-sig output types](https://preview.redd.it/z7uxr603lb781.png?width=1662&format=png&auto=webp&s=e0315b49bc2fb41ea721eddb76b218305d2a3b65)

Alle vier beschriebenen Ausgabetypen erfüllen die Single-Sig-Nutzung, obwohl P2TR unter der Haube noch viel mehr kann. Im Allgemeinen sind die Transaktionskosten für neuere Ausgabetypen günstiger: `Legacy > Wrapped Segwit > Native Segwit`. Beachten Sie, dass die Gesamtkosten von P2TR-Input+Output zwar etwas höher sind als die von P2WPKH, P2TR jedoch einen Teil der Kosten vom Input zum Output verlagert. Wenn Sie nicht wissen, zu welchem ​​Preis Sie Ihr Geld später ausgeben müssen, sollten Sie es in P2TR-Ausgaben aufbewahren, da sie die geringsten Eingabekosten haben. Ebenso sollten Sie P2TR bevorzugen, wenn andere Sie bezahlen: Der Absender zahlt die Ausgabekosten, während der Empfänger die Eingabekosten trägt. Obwohl Sie möglicherweise immer noch auf einige Gegenparteien treffen, die nicht an bech32 senden können, und auf viele, die nicht an bech32m senden können, sind die wirtschaftlichen Anreize jedoch klar. Wenn Ihre bevorzugte Wallet oder Ihr bevorzugter Service bech32(m) noch nicht unterstützt, bitten Sie sie, dies zu tun.

Wenn Sie den Datenfußabdruck Ihrer Transaktionen auf der Blockchain berücksichtigen, sollten Sie P2TR auch unbedingt bevorzugen, da Sie damit das meiste für das Byte erhalten (siehe Spalte „raw“ [B]” in der Tabelle oben). Der Daten-Footprint für die Ausgabetypen ist `P2SH-P2WPKH > P2PKH > P2WPKH > P2TR`.

Reddit von Xekyo ansehen – Quelle anzeigen


Beitragsansichten:
1

[ad_2]

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close