Was stellen die oberen 8 Bits von Sequenz und Sperrzeit in Lightning Commitment-Transaktionen dar?

In Bolt 3 der Lightning Network-Spezifikationen heißt es für Commitment-Transaktionen:

Sperrzeit: Die oberen 8 Bits sind 0x20, die unteren 24 Bits sind die unteren 24 Bits der verdeckten Zusagenummer.

Sequenz: Die oberen 8 Bits sind 0x80, die unteren 24 Bits sind die oberen 24 Bits der verdeckten Zusagenummer

Was ist der Grund für diese spezifischen oberen 8 Bits? Ich verstehe, dass die unteren 24 Bits effektiv willkürliche Daten sind, die zum Speichern der verdeckten Verpflichtung verwendet werden, aber warum dann nicht alle 32 Bits für beide verwenden?

Antworten (1)

git blameWenn Sie sich BOLT 03 ansehen, können Sie den Satz bezüglich der Sperrzeit bis zu diesem Commit verfolgen: https://github.com/lightningnetwork/lightning-rfc/commit/f1eaa2544665c9b85a2fd95be9c83dad45888982

Glücklicherweise hat der Autor in der Commitment-Nachricht in Git eine gute Erklärung gegeben, warum das 0x20für die oberen 8 Bits im Locktime-Feld eingeführt wurde (ich habe dem nichts hinzuzufügen):

Use 0x20 as high byte for locktime in commitment transaction

The most significant byte of the locktime in a commitment transaction
must be set to 0x20. This is to make sure that the locktime value
is always higher than 500,000,000, making it interpreted as a Unix
epoch timestamp, and not a block height. It also makes sure that the
locktime is below the current time, allowing the commitment transaction
to be included in a block.

Since the sequence field in the input of the commitment transaction is
used for the other half of the obscured commitment transaction number,
it will never assume the maxInt value (0xFFFFFFFF) which would disable
locktime checking.

Ähnlich finden wir für die ersten 8 Bits der Sequenznummer diesen Commit: https://github.com/lightningnetwork/lightning-rfc/commit/125b9a36572d05eb79b1c9527a70acadadc7cfc1 Aus der Commit-Nachricht kann ich noch einmal zitieren:

 BOLT 3: Fix commitment transaction input sequence number.

From BIP 68:

    If bit (1 << 31) of the sequence number is set, then no consensus
    meaning is applied to the sequence number and can be included in any
    block under all currently possible circumstances.

Which is what we want.
Ah okay das macht sehr viel Sinn! Wenn ich also technisch richtig verstehe, dass die Sequenznummer das erste Byte nicht speziell auf 0x80 setzt, könnten sich beide Knoten darauf einigen, es auf eine beliebige Zahl gleich oder höher als 0x80 zu setzen und die restlichen 7 Bits zum Speichern von mehr zu verwenden Daten, ohne dass dies einen On-Chain-Konsens beeinflusst?
Ja das erscheint vernünftig. Obwohl es natürlich gegen den Lightning Network "Consensus" verstoßen würde, der auf Kanalebene sowieso nur lokal ist (was konkret bedeutet, dass Partner davon abweichen könnten)
Was stellen die oberen 8 Bits von Sequenz und Sperrzeit in Lightning Commitment-Transaktionen dar?
AntwortenHierDatenschutz-Bestimmungen1y, 0v