Wie schneiden bech32-Adressen im Vergleich zu P2SH-Adressen in Bezug auf die Transaktionsgröße ab?

Bech32 (beginnt mit bc1) und P2SH (beginnt mit 3) können beide für Segwit-Transaktionen verwendet werden. Ich weiß, dass bech32 kleinere Transaktionen erstellen soll, aber ich würde gerne wissen, wie viel kleiner (als P2SH). Wie vergleichen sich Transaktionen, die von einer normalen Single-Key-Adresse kommen?

Antworten (2)

bech32 produziert kleinere Transaktionen als P2SH-Segwit-Transaktionen.

  • ein zusätzliches Byte pro Ausgabe, um P2SH-Ausgaben zu erstellen, als um bech32-Utxos zu erstellen (P2SH verwendet OP_HASH160und OP_EQUALzusätzlich zu einem 20-Byte-Hash in seinem Skript, während bech32 nur ein festes 00Byte zusätzlich zu einem 20-Byte-Hash verwendet), und
  • 23 zusätzliche Bytes pro Eingabe, die von P2SH-Utxos ausgegeben werden müssen, als von bech32-Utxos (P2SH muss das Skript erzeugen, das bei der Ausgabe im Sigscript gehasht wurde, was 23 Bytes zum Codieren benötigt - bech32 hat überhaupt kein Nicht-Zeugen-Sigscript).

Grundsätzlich erfordert P2SH einen Skript-Hash, natives SegWit nicht, und alles andere ist ähnlich. Natives SegWit stellt das Skript bereit, wenn die Ausgabe erstellt wird, und P2SH stellt es bereit, wenn die Ausgabe ausgegeben wird.

Wenn Sie wissen möchten, wie viel Sie bei jeder Transaktion gespart haben (oder sparen können), bietet Blockstream Explorer eine nette Funktion, mit der Sie die Einsparungen sehen können. Zum Beispiel können Sie bei dieser Transaktion zusätzliche 16 % Gebühren sparen

bitcoincore.org/en/segwit_wallet_dev/… sagt: „Im Vergleich zu den P2SH-Versionen ist die Transaktionsgröße der nativen Versionen in den meisten Fällen kleiner“.
Hier ist ein Beispiel : SegWit => 30 % Ersparnis. Natives SegWit => 16 % zusätzliche Ersparnis

Sie sind beide nur eine Codierung. Das resultierende tx könnte genau identisch sein. Im wirklichen Leben verwenden die Leute bech32 jedoch nur für native Segwit-Transaktionen, während p2sh als Wrapper für Segwit verwendet wird. der tx ist tatsächlich ein kleines bisschen kleiner, wenn p2sh verwendet wird.

Ach, tatsächlich? P2SH ist eigentlich kleiner? Was ist dann der Vorteil von bech32? Ich verstehe nicht ganz, was "native" im Zusammenhang mit "native segwit" bedeutet. Übrigens, haben Sie Quellen, wo wir mehr darüber lesen / Ihre Antwort überprüfen könnten?
Die beste Quelle ist immer die tatsächliche Quelle. bech32 wurde in bip173 vorgeschlagen, das Sie hier finden können: github.com/bitcoin/bips/blob/master/bip-0173.mediawiki Es enthält auch einen Abschnitt darüber, wie bech32 besser ist als andere Codierungen. Für die Größe gibt es keine eindeutige Quelle, ohne anzugeben, was genau Sie vergleichen möchten. bech32 ist eine Kodierung, p2sh ist eine Art Transaktion. Für meinen Vergleich bin ich davon ausgegangen, dass bech32 dem nativen Segwit entspricht.
Diese Antwort ist in mehrfacher Hinsicht falsch: 1. Es ist nicht nur eine andere Codierung, umschlossene Segwit- und native Segwit-Ausgaben sind unterschiedliche Ausgabetypen. Wenn Gelder an eine verpackte Segwit-Adresse gesendet werden, können sie nur in einer verpackten Segwit-Eingabe ausgegeben werden und umgekehrt für nativen Segwit. 2. Gewickelte Segwit- und native Segwit-Transaktionen können nicht identisch sein, auch wenn sie die gleiche Wirkung haben können (zu unterschiedlichen Gebührenkosten). 3. Eingewickelte Segwit-Transaktionen verwenden mehr Blockspace als native Segwit-Transaktionen.
Wie schneiden bech32-Adressen im Vergleich zu P2SH-Adressen in Bezug auf die Transaktionsgröße ab?
AntwortenHierDatenschutz-Bestimmungen1y, 0v