Eclair hat zwei Änderungen zusammengeführt, die Lightning-Nodes vor überhöhten Bitcoin-Minergebühren bei der Finanzierung und beim Splicing von Kanälen schützen sollen. Die Anpassungen gelangten am 2. und 5. Oktober in den Hauptentwicklungszweig. Am 12. Oktober war auf der Release-Seite jedoch weiterhin v0.14.3 aus dem September als neueste Version aufgeführt. Ob die Änderungen bereits in einer veröffentlichten Version enthalten sind, ist daher nicht bestätigt.
Eclair, entwickelt von ACINQ, ist eine Software für Lightning-Nodes. Die Änderungen betreffen Gebühren bei gemeinsam finanzierten Kanälen und beim Splicing sowie Transaktionsprüfungen im Eclair-Signer-Modus. Ein möglicher Verlust würde als Minergebühr anfallen und nicht direkt an einen Angreifer fließen.
PR #3388 begrenzt Gebührenforderungen von Gegenparteien
Die erste Änderung, PR #3388, betrifft Replace-by-Fee-Transaktionen (RBF), die eine Gegenpartei anstößt. Beim Eröffnen eines gemeinsam finanzierten Kanals oder beim Ändern der Kanalfinanzierung per Splicing kann die Gegenpartei eine Ersatztransaktion mit einem höheren Gebührensatz vorschlagen. Vor der Änderung gab es für einen Eclair-Node, der Mittel beisteuert, in diesem Ablauf keine ausdrückliche Gebührenobergrenze. Er konnte dadurch für seinen Anteil an der Transaktion mehr bezahlen müssen.
Eine böswillige Gegenpartei hätte den finanzierenden Eclair-Node so dazu bringen können, einen beliebig hohen Miner-Gebührensatz zu akzeptieren, ohne selbst die zusätzlichen Kosten zu tragen. Der finanzielle Schaden wäre den Minern als Transaktionsgebühr zugeflossen, nicht unmittelbar der Gegenpartei.
Mit der Änderung weist Eclair Anfragen zurück, deren Gebührensatz über dem von der Software für die Finanzierungstransaktion empfohlenen Limit liegt. Die Beschränkung greift nicht, wenn die Gegenpartei für Liquidität bezahlt und Eclairs Gebührenanteil übernimmt oder wenn der Eclair-Node nichts zur Transaktion beiträgt. In diesen Fällen trägt der Node die Kosten, um die es bei der Änderung geht, nicht.
PR #3390 prüft tatsächliche Gebühren im Signer-Modus
Die zweite Änderung, PR #3390, betrifft den Eclair-Signer-Modus. Dabei wählt das Bitcoin-Core-Backend bitcoind die Bitcoin-Eingänge aus und erstellt die Transaktion. Eclair behält die privaten Schlüssel und signiert sie. Die Verwahrung der Signierschlüssel schützt allein jedoch nicht vor einem kompromittierten Backend: Dieses könnte eine Gebühr innerhalb des Budgets melden, tatsächlich aber eine höhere Gebühr in die Transaktion einbauen – etwa indem es eine Wechselgeldausgabe entfernt.
Bei Bitcoin-Transaktionen wird jeder Teil des Eingabewerts, der keiner Ausgabe zugewiesen ist, zur Minergebühr. Durch das Entfernen von Wechselgeld kann ein Node daher Geld verlieren, ohne dass es an eine vom Angreifer kontrollierte Adresse überwiesen wird.
Die Änderung ermittelt die tatsächliche Gebühr anhand der Werte der ausgegebenen Eingänge und ruft die zugehörigen Transaktionen über ihre Transaktions-IDs ab, um diese Beträge zu prüfen. Anschließend vergleicht Eclair die vom Backend gemeldete Gebühr mit dem berechneten Wert und wendet das Budget auf die tatsächliche Gebühr an. Die Prüfung stützt sich damit nicht mehr nur auf die Angabe des Backends. Zusätzlich kontrolliert Eclair, ob der von der Software rekonstruierte Finanzierungsanteil dieselbe verifizierte Gebühr aufweist, und weist Transaktionen mit einer ungültigen Position der Wechselgeldausgabe zurück.
Oktober-Änderungen noch nicht in einem Release aufgeführt
Die beiden Änderungen betreffen Gebührenlimits bei gemeinsamer Finanzierung und beim Splicing sowie die Prüfung von Transaktionsgebühren im Signer-Modus. Sie sind unabhängig von einer früheren Schwachstelle zu Gebühren bei kooperativen Kanalschließungen und dem am 2. Oktober offengelegten Denial-of-Service-Problem, das Nodes nach einem Neustart betreffen könnte.
Am 12. Oktober führte die Release-Seite von Eclair weiterhin v0.14.3 aus dem September als neueste Version. Die Aufnahme von Änderungen in den Hauptentwicklungszweig bestätigt nicht, dass sie bereits in einem veröffentlichten Paket verfügbar sind. Betreiber müssen daher prüfen, ob ihr installiertes Build die Oktober-Anpassungen enthält.