Welches nVersion-Bit ist das „Hard-Fork-Bit“?

Ein BIP-Entwurf aus dem Jahr 2015 schlug die Verwendung eines „Hard-Fork-Bits“ vor:

Das höchstwertige Bit in nVersion wird als Hardfork-Bit definiert. Derzeit sind Blöcke mit dieser Header-Bit-Einstellung auf 1 ungültig, da BIP34 nVersion als vorzeichenbehaftete Zahl interpretiert und verlangt, dass sie >=2 ist (bei BIP66, >=3). Unter den 640 Bits im Block-Header ist dies das einzige, das fest ist und keinen Zweck erfüllt, und daher der beste Weg, um den Einsatz eines Hardforks anzuzeigen.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html

Wenn die Bit-Indizes von links nach rechts zunehmen, stelle ich mir vor, dass das Hard-Fork-Bit den Index 31 belegt, der wie *unten gekennzeichnet ist ( nVersionist ein 32-Bit-Wert).

0                   1                   2                   3
0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1
                                                              *

Das Setzen von Bit 31 von soll laut Vorschlag nVersiondazu führen, dass ein Block als ungültig zurückgewiesen wird.

BIP-9 erlegt den verfügbaren Bits weitere Einschränkungen auf, insbesondere müssen die Bits 0-2 als [0, 0, 1] gesetzt werden:

Blöcke im STARTED-Zustand erhalten eine nVersion, deren Bitpositionsbit auf 1 gesetzt ist. Die obersten 3 Bits solcher Blöcke müssen 001 sein, sodass der Bereich der tatsächlich möglichen nVersion-Werte [0x20000000...0x3FFFFFFF] einschließlich ist.

https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki

Außerdem ordnet BIP-9 Versionsbits in aufsteigender Reihenfolge von rechts nach links an. Das heißt, Versionsbit 0 ist nVersionBit 31, Versionsbit 1 ist nVersionBit 30 und so weiter.

Aber wenn dies der Fall wäre, dann wäre das Versionsbit 0 tabu. BIP-9 sagt nichts darüber aus, und tatsächlich wurde BIP-68 mit Versionsbit 0 signalisiert:

Dieses BIP soll von "versionbits" BIP9 mit Bit 0 bereitgestellt werden.

https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki

Meine Fragen sind einfach:

  1. Welcher Bit-Index ist in Anbetracht meines obigen Diagramms nVersiondas "Hard-Fork-Bit"?
  2. Wenn ich mit meiner Interpretation richtig liege (ich glaube nicht), wie hätte dann BIP-68 signalisiert werden können, ohne dass die Blöcke als ungültig zurückgewiesen würden?

Update: Die Quelle meiner Verwirrung war der Gedanke, dass nVersiondie Bit-Indizierung und die Versions-Bit-Indizierung in entgegengesetzte Richtungen liefen. Das nicht. Um beispielsweise die Angebotsbereitschaft über Versionsbit 1 zu signalisieren, nVersionwird Bit 1 gesetzt. Die Regeln von BIP-9 werden aktiviert, wenn eine nVersionSignatur erkannt wird. Diese Signatur besteht aus den Bits 29-31, die als 1, 0, bzw. gesetzt sind 0. Dadurch bleibt Bit 31 ungesetzt.

Peters Antwort spricht die obige Frage (1) an.

Was Frage (2) betrifft, so hat die BIP-68-Signalisierung keine Blockablehnung verursacht, da Bit 0 gesetzt wurde, nicht Bit 31.

Antworten (1)

Bit 31 wird manchmal als Hard-Fork-Bit bezeichnet.

BIP34 hat Versionsnummern auf 2 oder höher beschränkt. Da die Blockversion eine vorzeichenbehaftete 32-Bit-Ganzzahl ist, führt das Setzen des höchsten Bits zu einer negativen Zahl, die BIP34 verletzen würde.

Infolgedessen führt jede Verwendung dieses Bits zu einer rückwärts inkompatiblen Änderung der Regeln – einem Hard Fork –, der für alle Teilnehmer des Systems offensichtlich ist.

Das scheint meiner Interpretation zu entsprechen. Wenn ja, wie könnte die BIP-68-Signalisierung das Setzen von Bit-31 erfordern und nicht dazu führen, dass diese Blöcke abgelehnt werden?
BIP68 gibt Bit 31 des nSequence-Feldes einer Transaktion Bedeutung . Das Hardfork-Bit ist Bit 31 des nVersion-Feldes eines Blocks.
Oh, ich verstehe, Sie sind durch die Bit-Reihenfolge verwirrt. Stellen Sie sich Bits nicht als eine Reihenfolge vor - sie ist nicht gut definiert, hängt von der Hardware ab und ist im Allgemeinen irrelevant. nVersion ist eine Ganzzahl, und Bit X davon ist der Wert von (nVersion >> X) & 1.
Der Einsatzplan von BIP-68 sieht vor, das Versionsbit 0 ( nVersionBit 31) als Signal zu setzen. Ich verstehe, dass die Funktionalität von BIP-68 darin bestand, dem Feld eine Bedeutung zuzuweisen nSequence. Meine Frage kommt vom Bereitstellungsmechanismus für BIP-68, der erfordert, dass Signalisierungsknoten Bit 31 setzen. nVersionZumindest sieht es so aus.
Ich verstehe nicht, wo du das gelesen hast. BIP68 wurde für die Verwendung von nVersion Bit 0 signalisiert, nicht Bit 31.
"Dieses BIP soll von "versionbits" BIP9 mit Bit 0 bereitgestellt werden." (von BIP-68) AFAICT, Versionbits Bit 0 ist Bit 31 in meinem Diagramm.
Bit 0 ist Bit 0, Bit 31 ist Bit 31. Ich verstehe nicht, warum Sie denken, dass es einen Austausch gibt?
Welches nVersion-Bit ist das „Hard-Fork-Bit“?
AntwortenHierDatenschutz-Bestimmungen1y, 0v