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.
RETURN PUSHDATA(36)(...)
, theoretisch kann diese Ausgabe von niemandem konsumiert werden, da es OP_CHECKSIG
am Ende kein oder ähnliches OP gibt, das im Skriptstapel wahr zurückgibt.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.
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_RETURN
Skript 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_RETURN
Ausgabe auf der Coinbase-Transaktion, die das Präfix aa21a9ed
gefolgt 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.
JBaczuk
MCCCS
JBaczuk
Carpemer
JBaczuk
OP_RETURN
: github.com/bitcoin/bitcoin/commit/…Carpemer
JBaczuk
Andreas Chow