Ich fand diese interessante Interpretation der Bitcoin-Transaktionstyptrends aus dem Jahr 2015 .
Da dieser Artikel von vor 2 Jahren ist, frage ich mich:
a. Gibt es neuere Transaktionstypen?
b. Wie groß ist die durchschnittliche Größe jeder dieser Transaktionen?
c. Gibt es eine Website/Möglichkeit, die in jedem Block enthaltenen Transaktionstypen anzuzeigen?
Es gibt verschiedene Adressformate und andere Standard-Transaktionsarten:
Pay to Public Key (P2PK) gibt Bindungszahlungen direkt an den öffentlichen Schlüssel des Empfängers statt an die abgeleitete Adresse aus. Diese wurden fast vollständig durch P2PKH ersetzt, obwohl manchmal Mining-Belohnungen immer noch an P2PK ausgezahlt werden.
Eingang¹: 114 B
Ausgang: 44 B (komprimiert), 76 B (unkomprimiert)
Bereits vor der Einführung von P2SH waren Multisig -Transaktionen möglich, indem der entsprechende Op-Code direkt im Ausgabeskript verwendet wurde. Die meisten Multisig-Transaktionen werden heute jedoch mit P2SH-Transaktionen durchgeführt.
Eingabe: Variable (hängt von m-von-n ab)
Ausgabe: Variable (muss alle Pubkeys enthalten)
Pay to Public Key Hash (P2PKH) ist heute das am häufigsten verwendete Adressformat. Ein P2PKH-Ausgang signiert Gelder direkt an eine Adresse, die von einem einzelnen Empfängerschlüssel abgeleitet wurde.
Eingang¹: 148 B (komprimiert), 180 B (unkomprimiert)
Ausgang: 34 B
Pay to Script Hash (P2SH) wurde in der Vergangenheit hauptsächlich für Multisignatur-Transaktionen verwendet, aber jedes gültige Einlöseskript ist erlaubt. Die kreative Verwendung von P2SH ermöglichte die Einführung rückwärtskompatibler Segwit-Adressen: „Nested Pay to Witness Public Key Hash“ (P2SH-PWPKH oder NP2WPKH) und „Nested Pay to Script Hash“ (P2SH-P2WSH oder NP2WSH) können per gesendet werden jeder Client, der an P2SH senden kann.
Input¹: variabel (2-of-3: 297 B, NP2WPKH: 91 vBytes, NP2WSH 2-of-3: 139 vBytes)
Output: 32 B
Pay to Witness Public Key Hash (P2WPKH) ist das entsprechende native Segwit-Format für P2PKH, das ein Witness-Programm anstelle eines Signaturskripts verwendet. P2WPKH-Adressen sind mit bech32 anstelle von base58 codiert, was bedeutet, dass nur Clients, die das native Segwit-Format verstehen, an sie senden können.
Eingang¹: 68 vBytes
Ausgang: 31 B
Pay to Witness Script Hash (P2WSH) ist das entsprechende native Segwit-Format für P2SH, das eher ein Witness-Programm als ein Redescript verwendet. P2WSH-Adressen sind mit bech32 und nicht mit base58 codiert, nur aktualisierte Clients können an sie senden.
Input¹: variabel (2-of-3: 105 vBytes)
Output: 43 B
Pay to Taproot (P2TR) ist ein natives Segwit-Format, das Eigenschaften von P2PK mit P2WSH-Fähigkeiten kombiniert. Es ist auch der erste Ausgabetyp, der Schnorr-Signaturen verwendet. Die Ausgaben enthalten ein Witness-Programm der Version 1, und Adressen werden mit bech32m codiert, das sich von bech32 nur in der Prüfsumme unterscheidet. Ausgaben können entweder über den Schlüsselpfad ausgegeben werden, der ähnlich wie P2PK ist, da nur eine Signatur benötigt wird, oder über den Skriptpfad, wo ein Zweig des Taptree aufgedeckt wird und das Blattskript auf ähnliche Weise wie bei P2WSH erfüllt wird.
Input: variabel (Keypath: 57,5 vB, scriptpath 2-of-3²: 82,75 vB–115,5 vB)
Output: 43 B
Nulldatentransaktionen (OP_RETURN) dürfen einen einzigen Ausgang haben, der bis zu 83 Byte Daten in die Blockchain schreibt.
Eingabe: N/A
Ausgabe: x ≤ 83 + 11(?) Bytes
Nicht standardmäßige Transaktionen umfassen alle anderen Transaktionen, die nicht in eine der obigen Vorlagen passen. Nicht standardmäßige Transaktionen werden von den meisten Knoten im Netzwerk nicht weitergeleitet.
Zusätzlich fügt der Transaktions-Overhead 10 Bytes für Nicht-Segwit-Transaktionen und 10,5 Vbytes für Segwit-Transaktionen hinzu (für numInputs, numOutputs < 256).
overhead = version + numInputs + numOutputs + nLocktime = 4 + 1 + 1 + 4 = 10 bytes
segwit overhead = version + numInputs + numOutputs + nLocktime + marker + flag = 16 + 4 + 4 + 16 + 1 + 1 [weight units] = 42 weight units = 10.5 vbytes
Wenn Nicht-Segwit- und Segwit-Eingaben gemischt werden, wird die Gewichtung der Nicht-Segwit-Eingaben um 1 WU für den hinzugefügten leeren Zeugenstapel erhöht.
¹ Beachten Sie, dass sie aufgrund der gewählten Formatierung zur Darstellung von ECDSA-Signaturen in Bitcoin eine variable Größe von bis zu 72 Byte haben, wobei die meisten 71 Byte oder 72 Byte groß sind. Die oben angegebenen Zahlen stellen die maximale Größe der Eingabeskripte dar.
Ausgaben für ²-von-3-Skriptpfade haben unterschiedliche Eingabegewichte, je nachdem, ob eine MuSig-Konstruktion verwendet wird, ob es ein einzelnes Blatt mit einer 2-von-3-Konstruktion oder drei 2-von-2-Blättern in unterschiedlichen Tiefen im Baum gibt. Siehe zB https://bitcoin.stackexchange.com/a/96018/5406 .
Viele der oben genannten Formate können variable Eingabe- und Ausgabegrößen erzeugen. Im Allgemeinen betrug die durchschnittliche Transaktionsgröße in der vergangenen Woche 514 Bytes . Ich vermute, dass diese Zahl die absolute Transaktionsdatengröße und nicht die virtuelle Größe sein könnte, leider hinken Blockchain-Datenanbieter bei der richtigen Bewertung von Segwit-Transaktionen immer noch hinterher.
p2sh.info sammelt eine Reihe von Statistiken über verschiedene Transaktionsformate, aber soweit ich das beurteilen kann, leider nicht die Anzahl der Transaktionen, die die jeweiligen Formate in jedem Block verwenden.
Alle Größenangaben werden nach bestem Wissen und Gewissen bereitgestellt, Korrekturen sind willkommen. Zahlen mit "(?)" konnte ich nicht bestätigen. H/T an Pieter Wuille, Alex Bosworth, Raghav Sood, Sergi Delgado für Korrekturen.
Die Transaktionsgröße kann je nach Eingabegröße, Adresskomprimierung und Adresstyp variieren.
Bisher haben wir P2PKH (Normal), P2SH-P2WPKH (usually addresses starts with 3), UND native Segwit-Adressen P2WPKH and P2WSH(bech32).
Tsusanka