Was ist der Zweck des Skripts wie RETURN PUSHDATA(36)(...)

Das Beispiel ist hier: https://www.blockchain.com/btc/tx/63910fdfa84db96bd1f28fead4c32f97388d5368c10059d035aac3c5f72fcdc0

Eigentlich gibt es zwei AusgängeDUP HASH160 PUSHDATA(20)[78ce48f88c94df3762da89dc8498205373a8ce6f] EQUALVERIFY CHECKSIG and RETURN PUSHDATA(36)[aa21a9ed9463ee420b10cbad1d997bfa132a89dc9ba3de04e7233e6e6954f1bc339ebb1a]

Der seltsame Punkt ist, dass die erste Ausgabe 12,77303443 BTC hat, die zweite 0 BTC.

Es gibt zwei Fragen zu dieser Transaktion.

  1. Wie konnte die Coinbase mehr als 12,5 BTC haben?
  2. Was ist eigentlich der Zweck der RETURN PUSHDATA(36)(...), theoretisch kann diese Ausgabe von niemandem konsumiert werden, da es OP_CHECKSIGam Ende kein oder ähnliches OP gibt, das im Skriptstapel wahr zurückgibt.

Antworten (3)

1) Wie konnte die Coinbase mehr als 12,5 BTC haben?

Wegen Transaktionsgebühren

2) Was ist der Zweck von RETURN PUSHDATA(36)(...),

Der Zweck besteht darin, Daten in die Blockchain einzubetten. Es wurden keine Bitcoins verbrannt (und keine Transaktionsgebühr), also ist dies eine kostenlose Möglichkeit, Daten in die Blockchain einzubetten.

Technisch gesehen ist es jedoch nicht kostenlos, da die Gebühr auf Satoshi/kB basiert und die zusätzlichen Daten die Größe des TX etwas erhöhen.
@JBaczuk Es ist ein Coinbase-Tx.
Sie haben Recht, aber es ist nur für Coinbase kostenlos, nicht für TX mit OP_RETURN
@JBaczuk Daten für was einbetten, Spaß oder den richtigen Hash des Blocks erhalten (der in der Coinbase-Eingabe enthalten sein sollte)? Wird der UXTO-Pool diese Ausgabe im Speicher halten?
@Capemer Es werden keine unverbrauchbaren Ausgaben gespeichert, es gibt eine Prüfung, die UTXO sofort löscht, die mit beginnt OP_RETURN: github.com/bitcoin/bitcoin/commit/…
@JBaczuk, was ist dann der Zweck davon?
Die Leute missbrauchen es, um alle Daten zu speichern, die sie "dauerhaft" speichern möchten.
In diesem Fall ist diese Ausgabe Teil von segwit. Es ist für die Zeugendatenverpflichtung. Siehe BIP 141: github.com/bitcoin/bips/blob/master/… . Der Grund für die Verwendung von OP_RETURN ist, dass das UTXO nicht zum UTXO-Set hinzugefügt wird, da es nachweislich nicht ausgegeben werden kann.

2) Was ist der Zweck von RETURN PUSHDATA(36)(...), eigentlich kann diese Ausgabe theoretisch niemals von irgendjemandem konsumiert werden, da es am Ende kein OP_CHECKSIG oder ähnliches OP gibt, um im Skript wahr zurückzugeben Stapel.

Nach meinem Verständnis ist dies in SegWit-fähigen Blöcken obligatorisch.

Das zweite Skript (beginnend mit OP_RETURN) stellt den Merkleroot des Zeugenbaums bereit. IIRC wurde auf diese Weise erstellt, um eine Hard Fork zu verhindern. Das Hinzufügen eines zusätzlichen Felds zum Block-Header würde definitiv einen Hard Fork erfordern, daher bestand die beste Alternative darin, die Daten irgendwo zu platzieren, wo sie bereits in allen aktuellen Blöcken verfügbar sind. Da das OP_RETURNSkript niemals eine gültige Ausgabe sein wird, wird es einfach ignoriert.

Referenz und weitere Informationen: BIP141 Commitment-Struktur und eine ähnliche Frage

Wie MCCCS sagte, setzt sich die Mining-Belohnung aus Blocksubventionen und Transaktionsgebühren zusammen.

Die zweite Ausgabe auf der Coinbase verpflichtet sich zu den Zeugendaten im Block. Wie Sie vielleicht wissen, verpflichtet sich der Blockheader über das Merkle-Root-Feld zu Transaktionen im Block. Die Merkle-Wurzel wird erzeugt, indem aus den TXIDs (Transaktionskennungen) aller Transaktionen ein Merkle-Baum aufgebaut wird. Da sich TXIDs nicht an die Zeugendaten binden, würde die Merkle-Wurzel allein die Zeugendaten änderbar lassen.

Jeder Block, der Segwit-Transaktionen enthält, muss daher das Witness Commitment aufweisen . Die Witness Commitment hat die Form einer 36-Byte- OP_RETURNAusgabe auf der Coinbase-Transaktion, die das Präfix aa21a9edgefolgt von dem 32-Byte-Hash hat, der die Merkle-Wurzel der Transaktionen WTXIDs (Witness Transaction Identifiers) ist. Die WTXIDs werden aus der gesamten Transaktion erstellt, einschließlich des Zeugen.