BTC / Lightning Non-Custodial-Service, einige fragen

Hi,

Ich betreibe einen Lighning Node und möchte einen Non-Custodial-Service für meine Kunden Anbieten. Ich möchte eine Webseite erstellen auf der meine Kunden eine Non-Custodial Wallet besitzen, sie sollen in der Lage sein über meine Plattform via Lightning Spenden durchführen zu können.

Jetzt stellen sich mir einige Fragen, ist es überhaupt möglich einen solchen Dienst Anbieten zu können ohne das jeder meine Kunden vorher eine Einzahlung in Lighning durchgeführt hat?

Beispiel:

Bob hat eine Lightning - Wallet auf meiner Plattform und hat da 50€ in BTC eingezahlt,

Alice hat noch keine Bitcoins im Lightning Netzwerk bereitgestellt, kann ich ihr trotzdem eine LN-Wallet über meine Plattform anbieten oder muss sie vorher BTC einzahlen? Sie ist ja nur der Empfänger der Spende, es wäre ja sinnlos wenn Spendenempfänger vorher BTC einzahlen müssen :sweat_smile:

Besteht jetzt die möglich dass ich eine Inovice für Alice zu erstelle doch nur Alice zugriff auf Pfunds hat?
Oder muss Alice die Inovices selber erstellen? Das würde ja bedeuten das Alice für das Empfangen einer Spende auf der Plattform angemeldet (Online) sein muss!?

Ich habe mich die letzten Tage mit BLOT11 beschäftigt, doch bin nicht so wirklich Schlau daraus geworden, vllt kann mir jemand von euch Blot11 etwas genauer erläutern.

In der Theorie weiß ich wie LN funktioniert, allerdings finde ich kaum Dokus auf Deutsch und die Englischen die ich finde, lassen nur noch mehr Fragen offen als sie Beantworten für mich.

Ich hoffe ich konnte mein Problem gut genug Beschreiben.

Ich werde aus deinem Post nicht ganz schlau. Ich vermute, du hast manche technischen Zusammenhänge noch nicht richtig verstanden, denn so etwas wie eine Lightning-Wallet gibt es eigentlich nicht.

Bei einer Custodial-Lösung hast du eine (oder mehrere) Nodes des Anbieters. Und der Anbieter hat eine interne Datenbank, in der die Kontostände der einzelnen Kunden hinterlegt sind.

Eine Non-Custodial-Lösung bekommt jeder Kunde eine eigenen Node mit Kanälen und allem was dazugehört. Apps wie Breez, Phoenix oder Blixt Wallet machen das so. Man kann natürlich das Kanal-Management automatisieren, sodass er der Kunde nicht mitbekommt.

Willst du wirklich eine Non-Custodial-Lösung für deine Kunden anbieten? Wenn ja, mach dich auf sehr, sehr, sehr viel Arbeit gefasst.

Dass es keine Lightning Wallets gibt ist mir klar, ich wusste in dem Moment nur nicht was der Passende begriff ist.

Ja es sollte eine Non-Custodial-Lösung sein, der User soll sein Guthaben zu 100% unter seine Kontrolle haben. Mein LN-Node soll Quasi nur die Brücke Zwischen den Usern bilden, ich hoffe das ist verständlich wie ich das meine :sweat_smile:

Wenn ich Breez als Beispiel nehme das ist ja auch eine LN - „Wallet“ ohne das ich eine eigene Node betreiben muss dafür.

Doch bei Breez hast du eine eigene Node, die eben auf deinem Smartphone läuft. Anders geht es gar nicht. Da läuft eine LND-Node und Channels werden automatisch angelegt, wenn benötigt.

Ok, also müsste ich Tatzächlich Lightning in JavaScript „Portieren“ damit ich es im Browser verwenden könnte, so wie ich dich jetzt Verstanden habe ?

Dumme frage, aber gibt es da schon was?

Ich glaube deine Idee ist konzeptionell nicht ganz durchgedacht. Da gibt es viele Gründe die dagegen sprechen. So eine Lösung wäre ein ziemlich hoher Aufwand und würde im Endeffekt nicht die Eigenschaften haben, die du dir erhoffst.

Roman hat allerdings in mehren Seiner Videos gesagt das es Möglich ist eine Node mit mehreren Private Keys zu betreiben, deshalb sehe ich es so, dass man keine Full Node im Browser ausführen muss. Die Full Node kann ich ausführen und die Pfunds sind Trotzdem unter der Kontrolle des Nutzers, sehe ich das Falsch?

Schau, das was du vor hast ist sehr kompliziert. Da gibt es vermutlich nicht sehr viele Entwickler auf der Welt, die etwas vergleichbares schon gemacht haben.

Wenn du dir das zutraust, dann setze dich schon mal hin und lerne, wie Lightning funktioniert. Dann solltest du auch deine eigenen Fragen beantworten können.