Glossar / Lightning und Layer 2
Feature-Bit
- Was ist ein Feature-Bit?
- Ein Feature-Bit teilt anderen Lightning-Nodes mit, dass Ihr Node eine bestimmte Protokollerweiterung unterstützt, wobei ungerade Zahlen sie als optional und gerade Zahlen sie als verpflichtend kennzeichnen.
Lightning führt keine Versionsnummer mit, die Peers vergleichen könnten, daher ermitteln zwei Nodes durch den Austausch eines Bitfelds im Moment der Verbindung, was sie gemeinsam tun können. BOLT 9 vergibt 25 benannte Paare, vom Bit 0 bis zum Bit 67, und niemand darf beide Bits eines einzelnen Paares setzen. Wenn Ihre Wallet eine Rechnung ablehnt, die eine andere Wallet bezahlt, ist ein fehlendes Feature-Bit eine Sache, die Sie prüfen sollten.
So funktioniert es
Feature-Bits werden vom niedrigstwertigen Bit eines Bitfelds an gezählt, beginnend bei Bit 0, das den Wert 0x1 hat und als gerade gilt.
Sie werden paarweise vergeben, und die Paarung ist der eigentliche Kniff: Das ungerade Bit bedeutet, dass der Node die Funktion unterstützt, das gerade Bit bedeutet, dass er sie voraussetzt. Eine Fähigkeit kann daher als optional starten, sich still verbreiten und später auf verpflichtend hochgestuft werden, was laut BOLT 9 veraltete Nodes ablehnen werden, sodass die Unstimmigkeit auffällt, wenn zwei Nodes aufeinandertreffen, und nicht mitten in einer Zahlung. Die Anforderungen sagen den Rest klar: Ein Ursprungs-Node darf nicht beide Bits eines Paares setzen, und ein empfangender Node, der trotzdem beide sieht, behandelt die Funktion als verpflichtend.
Manche Funktionen bauen auf anderen auf, und der Absender trägt die ganze Kette. Einfache mehrteilige Zahlungen belegen die Bits 16 und 17 und hängen von payment_secret ab; Zeroconf-Kanäle belegen 50 und 51 und hängen von option_scid_alias ab; option_onion_messages_only_channels bei 66 und 67 hängt von gewöhnlichen Onion-Nachrichten ab. Der Ursprungs-Node muss jede transitive Abhängigkeit setzen, sodass Code hinter einem einzelnen Feature-Gate davon ausgehen kann, dass die stützenden Bits vorhanden sind, statt sie erneut zu prüfen.
Fünf der 25 Paare lauten jetzt nur noch ASSUMED: 0/1, 8/9, 12/13, 14/15 und 44/45. Jedes wurde so weit verbreitet, dass von jedem Node angenommen wird, es zu haben, und die Semantik nur in früheren Fassungen der Spezifikation fortbesteht. Die Tabelle lässt auch Nummern aus, ohne Zuordnung bei 2/3, 20/21, 30/31, 32/33, 52 bis 59 oder 64/65, sodass Lücken normal sind.
Wo Sie es sehen
Feature-Bits reisen an mehreren getrennten Stellen, und die Spalte Context der Tabelle in BOLT 9 benennt, wohin jedes Paar gehört, und bleibt in sechs der 25 Zeilen leer.
I kennzeichnet die init-Nachricht, die zwei Peers beim Verbinden austauschen, N eine node_announcement, die in den Gossip-Graphen gesendet wird, C eine channel_announcement, 9 eine Rechnung nach BOLT 11, B das Feld allowed_features eines verschleierten Pfads und T den channel_type, der beim Öffnen eines Kanals vereinbart wird. Viele Bits erscheinen nur in einem Kontext: option_payment_metadata, Bits 48 und 49, gibt es nur in Rechnungen, während option_anchors bei 22 und 23 in init, im Gossip und als Kanaltyp erscheint, aber nie in einer Rechnung.
Wenn zwei Kontexte nicht übereinstimmen, gewinnt die Rechnung: Die Begründung in BOLT 9 stellt fest, dass für Flags, die sowohl in node_announcement als auch in BOLT 11 stehen, die Werte der Rechnung die angekündigten überschreiben. Deshalb liest eine Wallet die Fähigkeiten aus der Rechnung, die Sie eingefügt haben, und nicht aus dem, was das Ziel dem Gossip-Netzwerk Stunden zuvor angekündigt hat.
Phoenix, von ACINQ auf seiner Eclair-Implementierung entwickelt, betreibt einen echten Node auf Ihrem Smartphone, sodass die Frage, ob er eine mehrteilige Zahlung oder eine verschleierte Route akzeptiert, durch ein mit seinem Peer ausgetauschtes Bitfeld entschieden wird und nicht durch eine Marketingseite. Muun zeigt On-Chain und Lightning als einen Kontostand, und seine Lightning-Zahlungen hängen weiterhin von den Bits in der Rechnung ab.
Feature-Bit vs. Versionsbit
Ein Feature-Bit handelt Fähigkeiten zwischen zwei Lightning-Peers aus; ein Versionsbit signalisiert einen Soft Fork in einem Bitcoin-Blockheader. BIP-9 gibt Minern die Bits 0 bis 28 des Versionsfelds im Header und fixiert ein Deployment bei 1.916 eines Fensters von 2.016 Blöcken im Mainnet, wonach es für jeden folgenden Block aktiv ist. Ein Feature-Bit bindet niemanden: Es ist eine Aussage zwischen zwei Peers, wahr in der einen Verbindung und falsch in der nächsten, ohne Schwellenwert, ohne Timeout und ohne netzwerkweite Aktivierung. Lightning handelt aus, was zwei Nodes füreinander tun; Bitcoin entscheidet, was alle akzeptieren müssen.