Such mal nach lncli updatechabstatus
Ich habe auf die Schnelle folgendes gefunden
„lncli updatechanstatus --funding_txid 123 --action disable“
„123“ muss du dann ersetzen. Dies setzt den Channel „auf deiner Seite“ auf inaktiv. D.h. Du lässt nicht mehr zu, dass jemand aus dem Channel raus routet. Sollte dein Partner den Channel aber nicht disabled haben, wird immer noch rein geroutet.
Willst du den Channel wieder freigaben, ersetze „disable“ durch „enable“
Nein, zu wenig local balance führt nicht automatisch zu disabled channels. Tools wie Charge-LND können das aber automatisieren, wenn man möchte.
Danke - danach habe ich gesucht, scheitere jedoch bei der Anwendung.
Wenn ich eingebe
lncli updatechanstatus --funding_txid 877************600 --action disable
bekomme ich die Fehlermeldung
[lncli] rpc error: code = Unknown desc = edge not found
„123“ habe ich ersetzt mit der „chan-id“, die ich mit
lncli listchannels
ausgelesen habe. Oder ist mit „–funding_txid“ etwas anderes gemeint?
Update: Lösung gefunden, es ist die Kanal öffnende Transaktion. Geht ja aus dem Namen auch schon hervor 
Vielen Dank - Rätsel gelöst, Frage beantwortet 
Update 2, der Vollständigkeit halber, mit
lncli getchaninfo 877************600
kann ich das Ein- und Ausschalten sehen/verifizieren.
Da im Eingangspost „angeblich“ steht: Wer weiß das genau?
Hier mal ein willkürliches Beispiel aus dem mempool:
Nebenbei interessant, dass es hier Anfangsstände gibt, die (so vermute ich) bei der Eröffnung festgelegt wurden. Auf der Seite von Coincharge habe ich davon schon einmal gelesen: Dual Funded Channel
max/min htlc sind Teil der Channel Update Message im LN Gossip (https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#the-channel_update-message), d.h. jede Node mit aktuellem Graphen wird bei der Pfadberechnung diesen Aspekt mitberücksichtigen und entscheiden, ob die zu sendende Menge an Sats durch diesen Pfad sendbar wäre.
Allerdings ist dies nicht zwingend erfüllt, da max/min htlc aus Privacy-Gründen (Preisgabe der Local Balance / der Gesamtmenge auf der Node) nicht balance-aktuell geführt und aktualisiert werden (mit Charge-LND wäre dies theoretisch machbar). D.h. die max htlc kann größer sein als die tatsächlich verfügbare Menge an local balance, die Pfadberechnung wäre ok, das Payment schlägt dabei aber fehl (Failure Detail: Insufficient Balance).
Ich habe mich durch diesen (und viele andere) Threads zum Thema Lightning gelesen und auch schon etwas herum experimentiert auf meiner Node. Dabei bin ich aber zu dem Schluss gekommen, dass Lightning als 2nd Layer für mich unbrauchbar und ziemlicher Käse ist!
Bei Lightning endet für die große Masse der (interessierten und versierten) Menschen der Traum von „Be your own bank“ und „Don’t trust, verify“. Lightning ist kompliziert, fehleranfällig, unzuverlässig, zeitkritisch und unberechenbar: Da es neben rationaler Informationstechnologie auch vom unterschiedlichen, teils irrationalen Agieren des Faktors „Mensch“ abhängt (Gebühren, Kanalmanagement, etc.)
Dabei können Fehler jede Menge Geld kosten. Wenn ich es nicht selbst hosten kann oder will, dann bleibt es immer dabei, anderen zu vertrauen so wie z.B. Acinq, Alby, WoS oder anderen. Letzten Endes führt Lightning damit zur Konzentration bei diesen „Multis“ und ist Gift für die Dezentralisierung.
In diesem Sinn vertraue ich, wenn ich (ohnehin seltene) Zahlungen via LN abwickeln werde, doch weiter meiner unsichtbaren LN-Wallet bei Strike, als mir diese für mich obsolete Technik anzutun.
Ich kann deinen Frust ein Stück weit nachvollziehen, aber finde man muss da differenzieren.
Der Betrieb von “selfhostet” Lightning um eigene Zahlungen abwickeln zu können ist nicht wirklich kompliziert. So ein Umbrel/Raspiblitz auf Raspi zu installieren bekommen auch viele wenig technikaffine Menschen hin, dann 2-3 Channels öffnen und einfach laufen lassen.
Der Betrieb einer Node die Zahlungen routen soll ist ein anderes Kaliber. Da muss man sich mit der Ökonomie des Netzwerks auseinandersetzen, Kanalmanagement betreiben, eine gewisse Größe erreichen (Vermögenswerte einfrieren und Risiko akzeptieren) und das ganze monitoren, usw.
Kann man auch beim empfangen den Kanal wählen?
Kann man die Kanäle labeln so das man Gelder aus verschiedenen Quellen über verschiedene Kanäle empfängt?
Du musst entweder die Kanäle, in denen du nichts empfangen willst, temporär deaktivieren oder die Gebühren extrem hoch setzen. Mit der Umbrel-Node ist das allerdings etwas schwieriger nach meiner Erfahrung.
Am Ende wirst du vielleicht am gleichen Punkt ankommen, wie ich: Lightning ist richtig doof und Technik für die Tonne. So mein Fazit. Lightning ist ein Grund, nicht an Bitcoin zu glauben.
Geht das mit einer anderen Node Software vielleicht besser?
Was ist der Zweck dahinter? Meinst du wirklich Empfangen oder Routen?
Da du Empfangen schreibst geh ich mal davon aus das du von irgendwoher wirklich Sats empfangen willst. Dann sollte es normalerweise egal sein über welchen Channel das rein kommt. Wäre wie wenn du bei nem Girokonto sagst “och nee, jetzt hat der das Geld von einer Sparkasse überwiesen, ich hätte lieber eine andere Bank gehabt”. Also es gibt schon ein paar technische Möglichkeiten da was zu steuern, die sind aber nicht intuitiv, weil das eben kein normaler Use-Case ist.
Es kann ja sein das ich einen bestimmten Channel nur benutze um anonym spenden zu empfangen und nicht will das dieser Channel mit seinem Public Key benutzt wird um Invoices zu erstellen wenn ich ihn nicht explicit auswähle
