Glossar / Transaktionen und Gebühren
Relativer Zeitsperrenwert
- Was ist ein relativer Zeitsperrenwert?
- Ein relativer Zeitsperrenwert macht eine Transaktionseingabe ungültig, bis die Coin, die sie ausgibt, seit ihrer eigenen Bestätigung eine festgelegte Anzahl von Blöcken oder Intervallen von 512 Sekunden alt ist.
Spezifiziert im BIP-68.
BIP-68 gab dem vier Byte langen Sequenzfeld jeder Eingabe eine Konsensbedeutung, aber nur für Transaktionen, die Version 2 oder höher angeben. Die Regel erreichte das Netzwerk über ein versionbits-Deployment von BIP-9 auf Bit 0, das am 1. Mai 2016 begann und zusammen mit BIP-112 und BIP-113 ausgeliefert wurde. Wenn Sie Coins hinter einem Wiederherstellungs- oder Kanal-Skript halten, beginnt der Countdown bei jeder Bewegung dieser Coins von Neuem.
Wie es funktioniert
Relative Zeitsperrenwerte werden im Sequenzfeld kodiert, und das höchste Bit entscheidet, ob überhaupt etwas geschieht.
Ist Bit 31 gesetzt, trägt das Feld keine Konsensbedeutung und die Eingabe kann in jeden beliebigen Block aufgenommen werden. Ist Bit 31 nicht gesetzt, maskieren Nodes das Feld mit 0x0000ffff und lesen die verbleibenden 16 Bits als Wartezeit. Bit 22 wählt die Einheit. Ist es nicht gesetzt, zählt die Zahl Blöcke, und BIP-68 gibt den Bereich mit 0 bis 65.535 Blöcken an, was es 1,25 Jahre nennt. Ist es gesetzt, zählt die Zahl Perioden von 512 Sekunden, einen Bereich, den das BIP mit unter 33.554.431 Sekunden angibt, etwa 1,06 Jahre. Die ungewöhnliche Zahl 512 wurde gewählt, weil Blöcke etwa alle 600 Sekunden eintreffen, sodass beide Einheiten mit denselben 16 Bits eine ähnliche Spanne abdecken.
Eine Eingabe mit einem blockbasierten Wert von n kann n Blöcke nach dem Block aufgenommen werden, der die Ausgabe gemint hat, die sie ausgibt, sodass ein Wert von 1 bereits im unmittelbar nächsten Block erfüllt ist und nicht erst im übernächsten. Zeitbasierte Werte werden nie mit einer Uhr verglichen. BIP-68 misst vom Median Time Past des Blocks vor demjenigen, der die Ausgabe gemint hat, und vergleicht mit dem Median Time Past des Blocks vor dem, der gerade gebaut wird, und BIP-113 definiert diesen Wert als den Median der Zeitstempel der letzten 11 Blöcke. Mediane werden statt roher Zeitstempel verwendet, weil die Konsensregeln garantieren, dass der Median monoton voranschreitet, was einen Miner daran hindert, durch eine falsche Angabe der Blockzeit zusätzliche Gebühren zu kassieren.
Zwei Ausnahmen sind wichtig. Die Regeln gelten nie für das Sequenzfeld der Eingabe einer Coinbase-Transaktion. Und sechs Positionen, 16 bis 21, blieben undefiniert, damit ein späterer Soft Fork die Granularität oder die Obergrenze ohne ein neues Feld erhöhen kann.
Wo er auftritt
BIP-112 führt einen relativen Zeitsperrenwert anhand eines Treuhandvertrags vor, der 30 Tage nach seiner Aufladung abläuft.
Alice, Bob und ein Treuhandagent teilen ein Skript mit 2 von 3 Unterschriften. Je zwei von ihnen können jederzeit ausgeben; nach der Verzögerung unterschreibt Alice allein. Das BIP ist deutlich beim Auslöser: Die Uhr beginnt erst zu laufen, wenn die Zahlung an die Treuhandadresse bestätigt ist. Das ist der ganze Unterschied zu einer Kalenderfrist, und deshalb dient ein einziges Skript jeder neuen Treuhand, ohne neu geschrieben zu werden.
Die Regel prägt auch das Verhalten der Mempools. Die Sequenzsperrenprüfung von Bitcoin Core läuft gegen die Höhe des nächsten Blocks statt gegen die aktuelle Spitze und behandelt eine unbestätigte Vorgängertransaktion so, als würde sie in diesem Block bestätigt, sodass eine Ausgabe, deren Wartezeit mit dem kommenden Block abläuft, etwas vor ihrer Ausgebbarkeit weitergeleitet wird. Außerhalb dieses Spielraums gibt es keine Warteschlange: Eine unreife Ausgabe ist ungültig, nicht ausstehend.
Relativer Zeitsperrenwert vs. OP_CHECKSEQUENCEVERIFY
Ein relativer Zeitsperrenwert liegt an der Transaktionseingabe, während OP_CHECKSEQUENCEVERIFY im Skript der Coin liegt und prüft, dass eine ausgebende Eingabe einen solchen einhält.
BIP-68 allein bindet niemanden. Wer die Ausgabe baut, wählt den Sequenzwert, sodass eine dort geschriebene Verzögerung eine Präferenz ist, keine Regel, auf die sich eine Gegenpartei verlassen kann. BIP-112 schließt die Lücke, indem es das Feld aus dem Skript lesbar macht: Der Opcode schlägt fehl, wenn die Transaktionsversion unter 2 liegt, wenn beim Sequenzwert der Eingabe das Deaktivierungs-Flag gesetzt ist, wenn die beiden Werte sich bei ihrer Einheit widersprechen oder wenn die Zahl auf dem Stack den maskierten Sequenzwert übersteigt. Trägt der Stack-Wert selbst das Deaktivierungs-Flag, verhält sich der Opcode wie ein NOP, bewusst gelassener Raum für einen künftigen Soft Fork. Erst mit diesen Prüfungen wird die Wartezeit zu etwas, worauf ein Treuhandagent oder ein Lightning-Peer zählen kann.