Lightning Network - Bitcoin

[nachtbild]

Am 21.2.2018 um 16:50 schrieb Amsi:

Lightning wird quasi auf die Blockchain aufgesetzt und es werden Payment-Channels erstellt.
Die Transaktionen innerhalb dieser Channels werden nicht auf der Blockchain vermerkt (sind deshalb auch kostenlos oder seeeeehr günstig und schnell), sondern es wird lediglich bei Eröffnung eines Channels auf die Blockain geschrieben wie viel jeder einzahlt und beim Schließen des Channels wird quasi der Endkontostand notiert.
Channels haben kein Ablaufdatum.

Ich muss zu meinem Verständnis nochmal auf das Zigaretten-Beispiel von Seite 2 zurückkommen. C hatte ja seine gedruckten Scheinchen an den Zigerattenverkäufer (nennen wir ihn Z) abgegeben. Müsste also nun anstelle von C dann beim zitierten Schließen des Channels nicht Z der Schließung zustimmen? Was passiert, wenn Z sich weigert?

[Jokin]

Die Channels können ohne die Zustimmung anderer geschlossen werden. Es wird dann der Endkontostand beider Enden des Channels in die Blockchain geschrieben.

Wenn Du und ich einen Channel haben könnten wir beliebig oft Geldhin und hersenden. Wenn einer von uns schließt, wird auch der Stand des anderen in die Blockchain geschrieben.

[nachtbild]

vor 9 Minuten schrieb Jokin:

Die Channels können ohne die Zustimmung anderer geschlossen werden. Es wird dann der Endkontostand beider Enden des Channels in die Blockchain geschrieben.

Wenn Du und ich einen Channel haben könnten wir beliebig oft Geldhin und hersenden. Wenn einer von uns schließt, wird auch der Stand des anderen in die Blockchain geschrieben.

Wir machen einen Channel auf, ich schicke dir 1 BTC, du schickt mir 50 BTC zurück, ich schließe den Channel, mir werden 49 BTC in der Blockchain gutgeschrieben, dir die 49 BTC abgezogen? Lass uns das doch mal ausprobieren. 

Ähm, woher weiß die Blockchain denn nun, dass nicht mehr der usprüngliche C der neue Besitzer der BTC ist, sondern Z? Oder bekommt C seine Zigis quasi für lau beim Schließen des Channels?

Edith: Oder werden die Transaktionen zwischen C und Z im Rahmen des LN ebenfalls ausgewertet und dann später auf der Blockchain gespeichert?

Bearbeitet 4. März 2018 von nachtbild

[Jokin]

In dem ursprünglichen Beispiel gab es nur Paymentchannel zwischen A, B und C. Eine Bezahlung an Z war nicht möglich.

Wenn Du und ich einen Paymentchannel aufbauen, dann sind Geldtransfers genauso verbindlich wie auf der Blockchain. 

Jede Zahlung wird erstmal offchain in den Channels gehaltenbis sie durch das Schließen in der Blockchain eingetragen werden.

Zahlungen über andere Channels bleiben offen.

[Jokin]

Nochmal ein interessantes Beispiel wieso einseitige Schließungen nötig sind.

Das LN funktioniert als Netzwerk.

A und B haben einen Channel und jeweils 1 BTC eingezahlt.

A „1“ - - - „1“ B

B und C haben auch einen Channel und jeweils zwei BTC eingezahlt.

B „2“ - - - „2“ C

Oder als Netzwerk so:

A „1“ - - - „1“ B „2“ - - - „2“ C

Nun zahlt B an C 1 BTC:

A „1“ - - - „1“ B „1“ - - - „3“ C

B besitzt noch 2 BTC.

A kann auch 1 BTC an C zahlen indem B als Netzwerkknoten dient:

A „0“ - - - „2“ B „0“ - - - „4“ C

B hat weiterhin 2 BTC, ist aber nicht mehr in der Lage an C einen BTC zu senden.

In dem Fall wird B beide Channels auflösen und einen neuen Channel zu C aufbauen damit wieder BTC an beiden Enden des Paymentchannels liegen.

Daher wird es auch weiterhin immer wieder Transaktionen in der Blockchain geben, aber in der Anzahl weit weniger als heute, bzw. gleichviel, aber es werden kaum noch Krümeltransaktionen aufgenommen.

[c0in]

 

[SkaliertDoch]

Mehr als Tausend Nodes.

[Citizenseven]

 

[skunk]

Am ‎04‎.‎03‎.‎2018 um 08:49 schrieb Jokin:

B hat weiterhin 2 BTC, ist aber nicht mehr in der Lage an C einen BTC zu senden.

In dem Fall wird B beide Channels auflösen und einen neuen Channel zu C aufbauen damit wieder BTC an beiden Enden des Paymentchannels liegen.

Kann ich das Routing der Zahlungen irgendwie verhindern? Mal angenommen ich bestelle jeden Freitag Abend meine Pizza und möchte diese zukünftig über einen Payment Channel an C bezahlen. Um gebühren zu sparen würde ich in den Channel gleich genug deponieren damit es für einige Wochen reicht.

Aus genau den selben Grünen habe ich auch noch einen Channel mit A. Was genau ich damit bezahle spielt für dieses Beispiel eigentlich keine Rolle.

Andere Kunden wollen ebenfalls eine Pizza bezahlen und werden über mich B geroutet. Eine Woche später möchte ich meine nächste Pizza bezahlen aber leider ist mein Channel leer. Dann bin ich gezwungen die beiden Channel zu A und C zu schließen und neu zu eröffnen? Das wird dann aber teuer und nur weil andere Kunden meinen Channel für ihre Bezahlung genutzt haben.

[SkaliertDoch]

Die Nodes haben aber beträchtlich abgenommen...

 

https://lnmainnet.gaben.win/

[c0in]

Bitcoin Lightning Network Node Anleitung, zum einfachen Setup für Windows.
https://medium.com/@jadmubaslat/bitcoin-lightning-network-node-easy-setup-tutorial-for-windows-desktop-users-a-how-to-guide-9937b5a8a669

LIGHTNING NETWORK EXPLORER [TESTNET]
https://explorer.acinq.co/#/

Bearbeitet 23. März 2018 von c0in

[skunk]

Am 16.3.2018 um 13:44 schrieb skunk:

Kann ich das Routing der Zahlungen irgendwie verhindern? Mal angenommen ich bestelle jeden Freitag Abend meine Pizza und möchte diese zukünftig über einen Payment Channel an C bezahlen. Um gebühren zu sparen würde ich in den Channel gleich genug deponieren damit es für einige Wochen reicht.

Aus genau den selben Grünen habe ich auch noch einen Channel mit A. Was genau ich damit bezahle spielt für dieses Beispiel eigentlich keine Rolle.

Andere Kunden wollen ebenfalls eine Pizza bezahlen und werden über mich B geroutet. Eine Woche später möchte ich meine nächste Pizza bezahlen aber leider ist mein Channel leer. Dann bin ich gezwungen die beiden Channel zu A und C zu schließen und neu zu eröffnen? Das wird dann aber teuer und nur weil andere Kunden meinen Channel für ihre Bezahlung genutzt haben.

Die Frage kann ich jetzt selber beantworten:

--private              make the channel private, such that it won't be announced to the greater network, and nodes other than the two channel endpoints must be explicitly told about it to be able to route through it

Meine Lightning node läuft. Falls jemand Hilfe braucht oder mal ein paar Transaktionen senden möchte, einfach melden. Was ich bisher rausgefunden habe:

1.) Es gibt einen automatik modus bei dem die node einfach selbstständig channels eröffnet und schließt. Per config kann man darauf Einfluss nehmen was sowohl die Anzahl als auch die Menge an BTC angeht.

2.) Routing von Transaktionen kostet eine Gebühr: basefee + (amount * feerate / 1000000)

 

[skunk]

Mal ein kurzer Zwischenstand. Meine Lighning node ist jetzt auf der Map zu sehen. Das ist aber auch schon alles. Aktuell hat die Software noch diverse Bugs. Eine richtige Zahlung ist so noch nicht möglich. Teilweise gibt es Rechenfehler. Sowas geht garnicht.

Auch ein Recovery ist derzeit nicht möglich. Das Wallet kommt zwar mit einem Backup Seed und man kann mit diesem Seed auch jederzeit sein Wallet wiederherstellen nur fehlt dann in der Software der Rescan. Privater Schlüsel vorhanden aber Blockchain wird nicht nach alten Guthaben gescannt

Resourcen Verbrauch ist akzeptabel. Ich werde meine Lightning node einfach laufen lassen. Wer einen Channel zu mir eröffnen möchte, kann das gern machen. 035e3662cd71e0596daf5b150d86a990bc25cb1f73467950e0b08be5c73bf89a81@84.139.122.35:9735 bzw das passende Kommando ` lncli openchannel --node_key 035e3662cd71e0596daf5b150d86a990bc25cb1f73467950e0b08be5c73bf89a81 --connect 84.139.122.35:9735 --local_amt 1337 `
In diesem Fall ein 1337 sat channel.

Bitte kein Geld an mich senden ohne vorherige Absprache. Ich werde es selbstverständlich zurück senden aber ich möchte dafür auch am Platz sein und meine Logdatei überwachen.

 

Bearbeitet 25. März 2018 von skunk

[Axiom0815]

Am 4.3.2018 um 08:49 schrieb Jokin:

Nochmal ein interessantes Beispiel wieso einseitige Schließungen nötig sind.

Das LN funktioniert als Netzwerk.

A und B haben einen Channel und jeweils 1 BTC eingezahlt.

A „1“ - - - „1“ B

B und C haben auch einen Channel und jeweils zwei BTC eingezahlt.

B „2“ - - - „2“ C

Oder als Netzwerk so:

A „1“ - - - „1“ B „2“ - - - „2“ C

Nun zahlt B an C 1 BTC:

A „1“ - - - „1“ B „1“ - - - „3“ C

B besitzt noch 2 BTC.

A kann auch 1 BTC an C zahlen indem B als Netzwerkknoten dient:

A „0“ - - - „2“ B „0“ - - - „4“ C

B hat weiterhin 2 BTC, ist aber nicht mehr in der Lage an C einen BTC zu senden.

In dem Fall wird B beide Channels auflösen und einen neuen Channel zu C aufbauen damit wieder BTC an beiden Enden des Paymentchannels liegen.

Daher wird es auch weiterhin immer wieder Transaktionen in der Blockchain geben, aber in der Anzahl weit weniger als heute, bzw. gleichviel, aber es werden kaum noch Krümeltransaktionen aufgenommen.

Das Beispiel zeigt aber auch ein Problem. 
A start sich die Transfer- Gebühr, B muss sie zahlen.

Axiom

 

[skunk]

vor 9 Minuten schrieb Axiom0815:

Das Beispiel zeigt aber auch ein Problem. 
A start sich die Transfer- Gebühr, B muss sie zahlen.

Axiom

 

Nein. A zahlt für das Routing eine Gebühr an B. Vermutlich ist die Gebühr zu gering sodass B beim schließen und neue öffnen der Channels Verluste machen würde. Er kann aber auch einfach die Channels so lassen wie sie sind. Zahlt C Geld an A bekommt B erneut eine kleine Gebühr. Je länger er die Channel offen lässt um so mehr Gebühren bekommt er fürs Routing.

[Axiom0815]

vor 13 Minuten schrieb skunk:

Nein. A zahlt für das Routing eine Gebühr an B. Vermutlich ist die Gebühr zu gering sodass B beim schließen und neue öffnen der Channels Verluste machen würde. Er kann aber auch einfach die Channels so lassen wie sie sind. Zahlt C Geld an A bekommt B erneut eine kleine Gebühr. Je länger er die Channel offen lässt um so mehr Gebühren bekommt er fürs Routing.

Ach ich freue mich schon auf die Steuer-Diskussion in ein paar Jahren.
Ich habe 3 Satoshi bekommen als Routing-Gebühr und man soll ja alles immer einzeln aufführen und in Euro umrechnen. 

Axiom

[Christoph Bergmann]

Wie funktioniert das denn genau mit den Gebühren? Reduziert jeder Mittelsmann einfach den Betrag, den er weiterreicht, und da der Sender schon vorher weiß, wie viele Mittelsmänner es gibt, kann er die richtige Gebühr mitsenden?

[skunk]

vor 39 Minuten schrieb Christoph Bergmann:

Wie funktioniert das denn genau mit den Gebühren? Reduziert jeder Mittelsmann einfach den Betrag, den er weiterreicht, und da der Sender schon vorher weiß, wie viele Mittelsmänner es gibt, kann er die richtige Gebühr mitsenden?

Route und Gebühren werden vor dem versenden Berechnet. Die Option "Gebühren vom Betrag abziehen" gibt es derzeit noch nicht. Ein passender Feature Request ist vorhanden.

Ein Limit für die Gebühren gibt es noch nicht. Man sollte sich derzeit die Routen zum Ziel vorher ausgeben lassen. Dabei wird wohl auch die Gebühr mit ausgegeben (muss ich heute Abend mal testen). Macht man das nicht, droht eventuell eine ungewöhnlich hohe Gebühr. Es wird an ein paar Pull Requests gearbeitet um für die Gebühren ein Limit mit auf den Weg zu geben und die zu teuren Routen damit abzulehnen.

Das Routing ist derzeit noch Fehleranfällig. Es werden ungültige Routen berechnet. Die Hops verfügen über genug Kapital sind aber auf einem alten Blockheight stehen geblieben. Frisches Kapital werden diese Hops nicht routen können weil die passenden Einzahlungen für sie noch nicht stattgefunden haben. Auch kann ein Hop mit einer anderen timelock Einstellung Probleme machen. Zukünftig soll das beim Routing beachtet werden. Pull Request vorhanden aber noch nicht gemerged.

 

Bearbeitet 26. März 2018 von skunk

[skunk]

Am ‎04‎.‎03‎.‎2018 um 08:49 schrieb Jokin:

 

A „0“ - - - „2“ B „0“ - - - „4“ C

B hat weiterhin 2 BTC, ist aber nicht mehr in der Lage an C einen BTC zu senden.

In dem Fall wird B beide Channels auflösen und einen neuen Channel zu C aufbauen damit wieder BTC an beiden Enden des Paymentchannels liegen.

Daher wird es auch weiterhin immer wieder Transaktionen in der Blockchain geben, aber in der Anzahl weit weniger als heute, bzw. gleichviel, aber es werden kaum noch Krümeltransaktionen aufgenommen.

Dazu gibt es bereits zwei Lösungsansätze. Einer Anwender hat Versucht über A eine Route zu finden die am Ende bei C endet. Dann könnte er einfach eine Zahlung an sich selber durchführen um die Channels auszugleichen. Nehmen wir also an vor der Aktion sieht das Netzwerk so aus:

A „0“ - - - „2“ B „0“ - - - „4“ C "1" --- "1" A

Jetzt sendet B über die Route B->A->C->B 1 and sich selbst. Damit hätten wir den Endstand:

A „1“ - - - „1“ B „1“ - - - „3“ C "0" --- "2" A

Eine solche Überweisung ist theoretisch möglich wird aber derzeit noch von einigen Fehlerprüfern abgelehnt. Zahlung an sich selber ist nicht erlaubt. Ein Issue wurde dazu erstellt. Soll also irgendwann ermöglicht werden. Mir stellt sich am Ende die Frage ob C den alten Zustand nicht besser fand und eine entsprechende Zahlung in die Gegenrichtung starten würde. Damit hätte man dann ein Netzwerk was ständig versucht mit Micropayments die Channels auszugleichen und keiner Gewinnt das Spiel.

Was ich noch testen muss ist die Frage ob die Routing Gebühren pro Node oder pro Channel sind. Es gab da ein Update Channel Command. Eventuell kann man damit nachträglich die Gebühren anpassen. Das würde B ermöglichen die Gebühren kurzfristig zu reduzieren damit eine Route von C->B->A kostengünstiger wird und dann eine normale Zahlung für den Ausgleich der Channels sorgt.

Lösung Nummer zwei hört auf den Namen "splicing in/out". Damit soll es möglich sein den Kontostand eines Channels in beide Richtungen zu updaten. Derzeit noch nicht implementiert daher kann ich nicht mehr dazu sagen.

Bearbeitet 26. März 2018 von skunk

[Jokin]

Danke!

... damit zeigt sich, dass noch eine Menge Entwicklungspotenzial hinter dem Netzwerk steht. Oder auch, dass es noch in den Kinderschuhen steckt. Jedoch zeigt mir auch, dass die Netzwerk-Gemeinde ziemlich ehrgeizig ist die Probleme zu loesen, weil jeder daran glaubt und es werden taeglich mehr.

 

[skunk]

Ich glaube da muss ich noch ein paar Sache klar stellen.

Ich bin von Beruf Test Engineer. Ein gefundener Fehler ist ein Erfolgserlebnis für mich. Wenn ich dabei helfen kann ihn schnell und einfach zu beheben dann steigert das mein Erfolgserlebnis zusätzlich. Mein Ziel ist es die Fehler so früh wie möglich zu finden weil dadurch eine Fehlerbehebung deutlich kostengünstiger ist. Finde ich keine Fehler, ist das eher ein Misserfolg für mich. In dem Fall wird die spätere Fehlerbehebung teurer. Ich stelle mir dann bei den späteren Fehlern die Frage was ich hätte anders machen können um sie früher zu finden. Ich finde selbst in funktionierenden Systemen diverse teilweise gravierende Bugs die normalen Anwendern überhaupt nicht auffallen und nicht stören.

Lange Rede kurzer Sinn: Was alles fehlerfrei funktioniert, habe ich nicht aufgezählt. Bitte beachtet das beim Lesen meiner Aussagen. Dann besser selber die Software installieren und ein eigenes Bild von der Lage machen. Ich glaube dabei kann ich eher behilflich sein.

[skunk]

vor 5 Stunden schrieb Christoph Bergmann:

Wie funktioniert das denn genau mit den Gebühren? Reduziert jeder Mittelsmann einfach den Betrag, den er weiterreicht, und da der Sender schon vorher weiß, wie viele Mittelsmänner es gibt, kann er die richtige Gebühr mitsenden?

Hier mal ein Beispiel bei dem ich eine Router für eine 0 Überweisung suche (lncli queryroutes --dest 0347ffcb271ef54fa6103fc6392370ce398d1bc98460829f7046cf64026253a68e --amt 0). Gefunden werden 4 Routen mit unterschiedlichen Gebühren. Hier mal 2 der 4 Routen: 

        {
            "total_time_lock": 515428,
            "total_fees": "2",
            "total_amt": "2",
            "hops": [
                {
                    "chan_id": "566249587943473153",
                    "chan_capacity": "10000",
                    "amt_to_forward": "1",
                    "fee": "1",
                    "expiry": 515284
                },
                {
                    "chan_id": "566478286372339712",
                    "chan_capacity": "10000",
                    "amt_to_forward": "0",
                    "fee": "1",
                    "expiry": 515270
                },
                {
                    "chan_id": "565909838810185729",
                    "chan_capacity": "55000",
                    "amt_to_forward": "0",
                    "fee": "0",
                    "expiry": 515270
                }
            ]
        },
        {
            "total_time_lock": 515442,
            "total_fees": "3",
            "total_amt": "3",
            "hops": [
                {
                    "chan_id": "566249587943473153",
                    "chan_capacity": "10000",
                    "amt_to_forward": "2",
                    "fee": "1",
                    "expiry": 515298
                },
                {
                    "chan_id": "566467291161100288",
                    "chan_capacity": "10000",
                    "amt_to_forward": "1",
                    "fee": "1",
                    "expiry": 515284
                },
                {
                    "chan_id": "559832838023741440",
                    "chan_capacity": "230000",
                    "amt_to_forward": "0",
                    "fee": "1",
                    "expiry": 515270
                },
                {
                    "chan_id": "559685503494193152",
                    "chan_capacity": "1100",
                    "amt_to_forward": "0",
                    "fee": "0",
                    "expiry": 515270
                }
            ]
        },

[skunk]

Das Ziel habe ich mir mehr oder weniger Zufällig ausgesucht. Man kann also davon ausgehen, dass derzeit jedes Ziel nur 2-3 Hops entfernt ist. Ein Hop geht auf mein Konto weil ich bisher nur einen einzigen Channel offen habe was für das Routing einen unnötigen Umweg bedeutet. Maximal kann ich 0,0001 BTC senden sonst findet er keine Route.

Es gibt ein Kommando updatechanpolicy mit dem man die Gebühren aller oder gezielt bestimmter Channels anpassen kann.

So das war es erstmal von meiner Seite. Noch Fragen?

Bearbeitet 26. März 2018 von skunk

[c0in]

Die Woche der Lapps: Blockstream präsentiert Infrastruktur für Lightning

https://bitcoinblog.de/2018/03/27/die-woche-der-lapps-blockstream-praesentiert-infrastruktur-fuer-lightning/

[skunk]

@Christoph Bergmann

Zitat

Vielmehr waren die Probleme, dass es zu wenig Kunden gibt, die Kryptowährungen benutzen, und dass für diese die Benutzung oft noch zu umständlich ist. Lightning, muss man sagen, ändert an diesen Problemen nichts, sondern macht sie eher noch schlimmer. Lightning reduziert den Netzwerkeffekt, den sich Bitcoin mühsam aufgebaut hat, auf die derzeit existierenden 1.350 Nodes. Die Lapps dürften für den Empfänger der Zahlungen die wohl denkbar komplizierteste und aufwändigste Art sein, die gewünschte Zahlungs-Anwendung umzusetzen, während das Benutzen von Lightning das Zahlen für den User, zumindest derzeit, noch deutlich verkompliziert

 

Ich lasse folgendes einfach mal unkommentiert stehen:

# ./lnd/lncli addinvoice --memo 'Lehrgeld' --amt 15000 --expiry 86400
{
        "r_hash": "217dc421d3445bf27676121a5b87898dd6b2a15ff56d63c9c17ea8af31890c42",
        "pay_req": "lnbc150u1pdtkdmvpp5y97uggwng3dlyankzgd9hpuf3htt9g2l74kk8jwp06527vvfp3pqdqdf3jksun8v4kxgcqzysxqyz5vqas2700j2kacehfz3xz34ug7cymkwvcrdtcs5hruvq0s9s7klvkxqp3xrnuj2hyva4uta6pu7qrruxvf27cwcrnfuyxe056dgfap57qcqc0de5e"
}
# ./lnd/lncli decodepayreq lnbc150u1pdtkdmvpp5y97uggwng3dlyankzgd9hpuf3htt9g2l74kk8jwp06527vvfp3pqdqdf3jksun8v4kxgcqzysxqyz5vqas2700j2kacehfz3xz34ug7cymkwvcrdtcs5hruvq0s9s7klvkxqp3xrnuj2hyva4uta6pu7qrruxvf27cwcrnfuyxe056dgfap57qcqc0de5e
{
    "destination": "035e3662cd71e0596daf5b150d86a990bc25cb1f73467950e0b08be5c73bf89a81",
    "payment_hash": "217dc421d3445bf27676121a5b87898dd6b2a15ff56d63c9c17ea8af31890c42",
    "num_satoshis": "15000",
    "timestamp": "1522218860",
    "expiry": "86400",
    "description": "Lehrgeld",
    "description_hash": "",
    "fallback_addr": "",
    "cltv_expiry": "144"
}
# ./lnd/lncli listinvoices
{
    "invoices": [
        {
            "memo": "Lehrgeld",
            "receipt": null,
            "r_preimage": "bCp09f55/nBRLB3tOQm147uo/3rNjbbkhdqbQifgmrw=",
            "r_hash": "IX3EIdNEW/J2dhIaW4eJjdayoV/1bWPJwX6orzGJDEI=",
            "value": "15000",
            "settled": false,
            "creation_date": "1522218860",
            "settle_date": "0",
            "payment_request": "lnbc150u1pdtkdmvpp5y97uggwng3dlyankzgd9hpuf3htt9g2l74kk8jwp06527vvfp3pqdqdf3jksun8v4kxgcqzysxqyz5vqas2700j2kacehfz3xz34ug7cymkwvcrdtcs5hruvq0s9s7klvkxqp3xrnuj2hyva4uta6pu7qrruxvf27cwcrnfuyxe056dgfap57qcqc0de5e",
            "description_hash": null,
            "expiry": "86400",
            "fallback_addr": "",
            "cltv_expiry": "144"
        }
    ]
}