kapische! Danke
…um 25% senken, nicht um 75%, oder?
Ein Difficulty Adjustment kann die Difficulty maximal um 75% senken, bzw. auf ein Viertel (25%) vom vorherigen Wert senken.
3 „Gefällt mir“
Jap, das stimmt wohl so, ich hatte das anders in Erinnerung.
Der Luke verbreitet seinen Schmarrn auch auf Nostr und spricht jetzt von einem Hardfork. Aber es seien natürlich die anderen, die den Hardfork machen würden.
ich werde meine Bitcoin nach dem fork erst einmal von den Shitcoins trennen, indem ich eine nicht konforme BIP110-Transaktion mache. (Wenn ihr sowas anstrebt, bitte informiert euch gründlich über die Gefahren, denn da gibt es welche und die können zum Verlust eurer Coins führen).
Durch diese Transaktion werden meine Bitcoin durch andere private keys freigeschaltet als die Shitcoins auf Lukes Blockchain. Sobald sie voneinander getrennt sind, werde ich versuchen meine Shitcoins zu verkaufen. Wahrscheinlich wird es keine exchange geben, die den Müll annimmt und wahrscheinlich wird die hashrate so niedrig, dass ich paar Jahre warten muss, bis meine Transaktion auf der shitchain durchgeht, aber vielleicht finden sich ein paar BIP110er, die den Scheiss kaufen wollen. Schließlich stehen sie ja ungebrochen zu ihrer Shitchain.
Das wird für Lightning sicher auch spannend. Die alten Kanäle (oder neue Kanäle, die durch replay in beiden Chains geöffnet werden) hätten dann, je nach Wert der Fork-Chain, ggf. einen nicht zu vernachlässigenden höheren Wert als neue Kanäle ohne replay.
Ich bin derzeit am Überlegen wie ich mich mit meiner Node am besten darauf vorbereite. Neue Kanäle ohne Replay (nach Abtrennen der Coins, so wie du es machen willst) öffnen, von diesen rebalances in alte Kanäle machen, die alten dann schließen und so doppelt abkassieren wäre möglich.
Das Problem ist, dass das vielleicht andere auch machen wollen und schon geht es darum wer es schneller durchzieht. Also vielleicht alle Gebühren sehr hoch stellen, sodass andere dafür teuer zahlen müssten. Aber was wenn das auch alle machen? Dann könnte es vorübergehend sehr hohe Lightning-Gebühren und vielen Kanalschließungen geben.
Spannend auf jeden Fall.
1 „Gefällt mir“
krass, an lightning hab ich noch gar nicht gedacht. wird das denn so einfach gehen? müssten die Kanäle nicht inkompatibel sein mit der Shitchain? ich glaube was lightning angeht, da halte ich mich erstmal zurück. Da bin ich noch zu sehr noob, als das ich da genau weiß was ich tue. Ich habe einen Kanal offen und betreibe eine lightning node, aber bin da nicht so drin wie du mit deinen 200 Kanälen ;-)
Vorher unternehme ich gar nichts
1 „Gefällt mir“
Warum? Die Chain zeigt die Wahrheit. Wenn etwas auf der Chain vor dem Fork existiert hat, dann existiert es auch danach. Die Kanäle sind auf beiden Chains gleichermaßen gültig. BIP110 ändert zwar ein paar Sachen, aber die Lightning-Skipte passen trotz der neuen Einschränkungen noch rein.
Stimmt. Jedoch baut Lightning darauf, eine globale Chain zu haben, die im Gleichschritt läuft. Es gibt ein paar Dinge, die timelock-basiert sind und dabei wird es dann spannend.
- Angenommen: 3% Hashpower (alle im Ocean-Pool minen für BIP110)
- Angenommen es gibt einen permanenten chain split bei BIP110-Aktivierung (sehr wahrscheinlich).
Dann gilt für die BIP110-Chain für die aktuelle Difficulty: 1 Block alle 5,5 Stunden
Übrigens würde das erste Difficulty Adjustment für die BIP110-Chain somit erst nach 466 Tagen erfolgen.
Für Lightning gelten dann unterschiedliche Zeiträume für:
- Kanalöffnungen (~6 Blöcke)
- HTLCs (CSV/CLTV): Timelocks laufen falsch, HTLC läuft ab. CSV 144 entspricht 1 Tag auf Chain alt, 30 Tage auf Chain 110
- Justice-Transaktionen: Watchtower auf Chain 110 reagieren zu spät bei Force-Closes mit gefälschten Kanalzuständen (alter Commitment-Zustand)
Unterschiedliche Zeiträume sind nicht das Problem.
„Kanal ist offen“ ist kein Bitcoin-Konsensuszustand. Es ist lediglich der Zustand, den die beiden Lightning-Implementierungen anhand ihrer jeweiligen Sicht der Blockchain ableiten. Das ändert aber nichts daran, dass bereits signierte Commitment- und HTLC-Transaktionen gültig bleiben, sobald das Funding-UTXO existiert. Ob die Implementierungen den Kanal momentan als „offen“ ansehen, ist dafür nicht entscheidend.
Ein ganz normaler (wenn auch seltener) Fall ist ein Reorg:
Ein Kanal wird von beiden Nodes als „offen“ angesehen, sobald er z. B. 2 Bestätigungen hat. Die Kanalöffnungs-Transaktion wird in Block X aufgenommen, dann folgt Block X+1. Der Kanal ist also „offen“. Es werden HTLCs ausgetauscht und die entsprechenden Commitment-Transaktionen signiert.
Dann gibt es plötzlich eine konkurrierende längere Kette, in der Block X durch Y ersetzt wird. Nehmen wir an, die Kanalöffnungs-Transaktion landet dort erst in Block Y+2. Dann gilt der Kanal aus Sicht der Implementierungen vorübergehend wieder als nicht „offen“. Neue HTLCs werden deshalb nicht mehr angenommen. Die bereits signierten Commitment- und HTLC-Transaktionen bleiben aber trotzdem gültig, sobald das Funding-UTXO auf dieser Chain existiert. Die Funding-Transaktion ist schließlich dieselbe und enthält dieselbe UTXO.
Ein Problem könnte allerdings entstehen, wenn die Funding-Transaktion auf der langsamen Chain noch unbestätigt ist und dort per RBF durch eine Version mit höherer Gebühr ersetzt wird, während sie auf der schnellen Chain bereits bestätigt wurde.
Was heißt hier „falsch“? CSV und CLTV orientieren sich an der jeweiligen Blockhöhe. Sie verhalten sich also exakt wie spezifiziert. Sie laufen nicht falsch, sondern unterschiedlich schnell, weil die beiden Chains unterschiedlich schnell Blöcke produzieren. Das ist ein Feature und kein Bug.
Was genau meinst du mit „zu spät“? Meinst du die langsamere Blockproduktion? Eine langsamere Chain verlängert die reale Zeit bis zum Ablauf der CSV-Frist eher und gibt damit eher mehr Zeit zum Reagieren.
Oder meinst du, dass Watchtower die andere Chain gar nicht beobachten? Das wäre tatsächlich ein anderes Problem, hat aber nichts mit den CSV-/CLTV-Fristen selbst zu tun.
Ja, das meinte ich. Die „Sicherheit“, dass der Kanal von beiden Seiten „unveränderlich“ in der Blockchain geschrieben ist, ist nicht gegeben. Außer die schnellere Chain richtet sich an die langsamere Chain (confirmations erhöhen). Gut, ist jetzt nicht der wichtigste Punkt.
Wenn sich unterschiedliche Nodes mit unterschiedlichen Blockchains im HTLC-Pfad befinden, woher weiß eine Node, ob das Payment einen Timeout erreicht hat, weitergeleitet werden soll, das Preimage weitergeleitet werden soll, das HTLC downstream das Ziel erreicht hat oder expired ist? Das ist mit unterschiedlichen Layer1s nicht so einfach zu beantworten.
Ja, ich meinte, dass Watchtower eher gar nicht reagieren könnten, weil die Justice-Tx eventuell gar nicht gesehen wird (Block invalid).
Nicht die schnelle Chain müsste sich nach der langsameren richten. Wenn eine Lightning-Implementierung einen Kanal auf beiden Chains konsistent halten möchte, müsste sie ihre Entscheidungen anhand beider Chains treffen. Ein Kanal würde dann beispielsweise erst als „offen“ gelten, wenn auf beiden Chains genug Bestätigungen vorliegen.
Wenn eine Node auf beiden Chains im gleichen Kanalzustand halten möchte, müsste sie den Timeout bereits dann als erreicht ansehen, wenn er auf einer der beiden Chains erreicht wurde. Anschließend würde sie den Kanal auf beiden Chains schließen und das HTLC Onchain abwickeln.
Auch hier: Wenn der Kanalzustand auf beiden Chains konsistent bleiben soll, könnte die Node ein HTLC z.B. nur weiterzuleiten, solange es auf beiden Chains noch gültig ist.
Hier muss man nichts anpassen. Die Node leitet das Preimage weiter sobald sie die Zahlung erhalten hat, also der nächste Hop die entsprechende Commitment-Änderung gültig signiert hat. Also wie immer.
Entscheidend ist doch nicht, auf welcher Chain der nächste Hop läuft, sondern dass jede Node ihren eigenen Kanalzustand konsistent hält. Ob das HTLC downstream erfüllt wurde, erfährt sie wie sonst auch über das Preimage beziehungsweise eine Fehlermeldung ihres direkten Peers. Erfolgt das nicht rechtzeitig, behandelt sie ihr eigenes HTLC nach den für ihren Kanal geltenden Timeout-Regeln.
Klar wird es dadurch komplexer, und langfristig macht es auch keinen Sinn. Aber es sollte mit entsprechenden Anpassungen eigentlich funktionieren.
Man bräuchte natürlich für jeden Chain einen Watchtower, der dann auch unverzüglich für das Replay in der anderen Chain sorgt.
Das ist natürlich alles komplex, problemanfällig, langsam etc. Aber es wird nun mal bei dem Fork, falls er denn wirklich passiert, Kanäle geben, die auf zwei unterschiedlichen Chains existieren und den Anspruch auf Coins auf beiden Chains verbriefen. Was die jeweiligen Nodes damit machen ist dann deren Sache.
Wenn meine Node auf Core läuft und eine andere auf Knots, dann kann der Kanal ohne Änderungen dennoch weiterhin genutzt werden bis ihn eine Seite schließt (aus welchem Grund auch immer).
Ich bin noch nicht sicher wie ich damit umgehe. Ich bleibe zwar auf Core, aber es könnte Sinn machen einen BIP110-Konformen Watchtower einzurichten um die Coins in der Fork-Chain abzusichern. Noch ist ja Zeit und habe gerade erst angefangen mich mit den Möglichkeiten und Auswirkungen zu beschäftigen.
Ich denke aber ich werde passend zu Block 961632 zumindest alle Kanäle vorübergehend deaktivieren und erst mal die ein oder andere Stunde abwarten wie es sich so entwickelt.
Aktuelle Prognose: Die BIP 110 Chain wird wertlos bzw. aufgegeben und das Problem erledigt sich so von alleine.
Allerdings wurde dies bislang meiner Meinung nach noch nicht getestet. Wir werden sehen, wie sich das ausspielt.
Ich denke das ist unnnötig, da die BIP110 Chain eine Teilmenge der „alten“ Chain ist. Alle Txs des Knots Mempools sind auch im Core Mempool enthalten.
Ich glaube auch nicht, dass jemand ernsthaft versuchen wird seine Kanäle dauerhaft auf beiden Chains aktuell zu halten. Vieles würde einfach sehr lange dauern. Die Übergangszeit wird aber richtig spannend.
Ja du hast recht. Alle Schließungen von Kanälen vor den Fork werden in beiden Mempools gleichermaßen akzeptiert. Es sollte also kein zweiter Watchtower nötig sein.
Zum Thema LN gibts einen ausführlichen Beitrag https://jumble.social/notes/naddr1qvzqqqr4gupzplgzvey9waaaw05hclph75svs0yzud30unp956lf8uecqzpagertqy88wumn8ghj7mn0wvhxcmmv9uq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59uqy2mrfva58gmnfdenj6ctwvskky6ts95cnzvpddphhwtt5dukkumm594kx7um994ekzarn94mks6tvv5kk2an9wfuk7mn994jkcum994shyem4v4ese53r05
