Lightning: Wie aus Payment-Channels ein Netzwerk entsteht

"Blitz" von Etmo via flickr.com. Lizenz: Creative Commons

Endlich kommen wir zum zweiten Teil der Erklärung des Lightning-Netzwerks: Wie wird aus Payment-Channels ein Netzwerk? Wie kann jemand Bitcoins an jemanden anderen senden, ohne direkt einen Channel mit ihm zu unterhalten? Warum braucht man dafür kein Vetrauen? Und wie finden die Lightning-Nodes eine Route durch das Netzwerk? Lest es selbst!

Wie schon im ersten Teil der Lightning-Erklärung muss ich ankündigen, dass die Sache nicht ganz unkompliziert wird. Wenn ihr es endlich geschafft habt, eingermaßen zu verstehen, wie Bitcoin funktioniert, und nun einen neuen Stock sucht, um den ihr eure Hirnlappen herumknoten könnt — dann ist das Lightning-Netzwerk genau das richtige Hobby für euch.

Beginnen wir zum Verständnis nochmal mit den Grundlagen: Das Lightning-Netzwerk soll ein Netzwerk von offchain-Transaktionen werden, also von Transaktionen, die nicht auf der Bitcoin-Blockchain sind, aber dennoch ebenso gültig. Dies hat den Vorteil, dass man nicht warten muss, bis die Miner die Transaktion bestätigen, und, vor allem: dass die Transaktionen nicht von jedem Knoten im Netzwerk geprüft und gespeichert werden müssen.

Sprich: Transaktionen sind schneller und eine ganze Menge der Probleme, die die Skalierung von Bitcoin derzeit so kontrovers machen, fallen weg. Klingt gut, oder?

Payment Channels

Die Grundlage von Lightning sind sogenannte Payment-Channels. Man kann sich diese so vorstellen, als würden wir einen Überweisungszettel ständig umschreiben, anstatt ihn einzuwerfen.

Anstatt Ihnen Geld zu überweisen, gebe ich Ihnen einen Zettel, und den können Sie einwerfen, wie Sie wollen, um die Überweisung klar zu machen. Wir beide können den Zettel aber auch wieder und wieder umschreiben, um zwischen uns beiden Transaktionen zu verrechnen. So können wir unendlich viele Transaktionen vollziehen, ohne dass es zu einer SEPA-Überweisung kommt.

Bei Bitcoin nutzen die Payment-Channels eine Multisig-Adresse, in die beide Parteien eines Channels Geld einzahlen – sagen wir, jeder 0,1 Bitcoin – und diese Adresse bildet dann die Balance eines Channels. Stellen Sie sich vor, wir beide überweisen Geld auf ein Treuhandkonto, vom dem nur Geld überwiesen werden darf, wenn wir beide unterschreiben.

Diese Balance eines Bitcoin Payment-Channels ändern wir mit einer Transaktion, die von beiden Parteien signiert, aber nicht an die Blockchain gesendet wird. Wenn Sie mir etwa 0,01 Bitcoin geben, bilden wir eine Transaktion, die aus der Multisig-Adresse 0,09 Bitcoin an Sie und 0,11 Bitcoin an mich auszahlt. Ich kann die Transaktion nun an die Miner senden, oder warten, bis Sie mir weitere 0,01 Bitcoin senden, wodurch die neue Transaktion 0,08 Bitcoin an Sie und 0,12 Bitcoin an mich auszahlt. Und so weiter.

Es ist theoretisch zwar auch möglich, dass man einen Channel ohne Guthaben aufbaut, aber in der Regel wird man zu Beginn ein wenig Geld hineinlegen, um damit sowohl senden als auch empfangen zu können.

Etwa so sieht die Architektur von Payment-Channels aus. Reichlich kompliziert, aber wer ein wenig Zeit und Gedanken investiert, wird verstehen, warum.

Der Trick beim Payment-Channel ist, dafür zu sorgen, dass das ganze funktioniert, ohne dass wir uns vertrauen müssen. Also ohne dass die eine Partei die andere dadurch erpressen kann, dass sie ihre Signatur verweigert (und damit das Geld beider Parteien einfriert), und ohne dass eine Partei eine Transaktion ungeschehen machen kann, indem sie eine vergangne Transaktion an die Blockchain sendet. Eine clevere Kombination von Smart Contracts sorgt dafür, dass Payment-Channels ohne Vertrauen auskommen. Zumindest solange, wie euer Knoten online ist. Wie es genau geht, könnt ihr in meinem Artikel lesen. Oder gleich im Whitepaper.

Hier kommen wir dazu, wie aus einem Payment-Channel ein Netzwerk wird. Denn solche Payment-Channels sind zwar eine entzückende Technologie, aber, ehrlich gesagt, so richtig nützlich sind sie im Alltag nur in Ausnahmefällen. Sowohl 21.co als auch SatoshiPay haben Payment-Channels gebaut, ohne dass diese wirklich zum Verkaufsschlager geworden sind. Daher ist die Frage, wie man über sie hinauskommt.

Wie aus Channels ein Netzwerk wird

Kommen wir zu dem Teil, für den ich mir für euch einen Knoten ins Gehirn gedreht habe. Wie aus Channels ein Netzwerk wird – das Lightning Netzwerk.

Stellt euch mal vor, zwei meiner Leser, Jens und Sven, haben jeweils einen Payment-Channel mit mir. Nun versucht Jens über diese Channels einen Bitcoin an Sven zu senden. Wie ist das möglich?

Eine Lightning-Transaktion über einen Mittelsmann. Die Grafik ist aus einer Präsentation der Lightning-Entwickler.

Der Kern der Sache ist recht einfach: Jens schickt mir einen Bitcoin (bzw. die Transaktion für einen Bitcoin) und ich schicke einen Bitcoin (bzw. eine Transaktion) an Sven.

Mir fällt kein besserer Vergleich ein als das beliebte Brettspiel Risiko. In diesem darf jeder Spieler, nachdem er seine Schlachten geführt hat, jede Armee um ein einziges Land verschieben. Nun kann man etwa eine Armee von Brasilien nach Nordwestafrika ziehen. Da die Armee, die bisher in Nordwestafrika stand, sich aber noch nicht bewegt hat, kann man sie nach Ägypten ziehen. Und so weiter. Ein wenig wie bei den Postboten früher, die bei den Stationen das Pferd gewechselt haben, um im Eiltempo durch ganz Deutschland zu reiten.

Faszinierend, Risiko wird auch in Arabien gespielt. Der gelbe Spieler könnte Truppen von Mexiko bis nach Ägypten ziehen, obwohl an sich nur ein Grenzübertritt je Truppe und Runde erlaubt ist. Bild von Islam Hassan via flickr.com. Lizenz: Creative Commons

Im Prinzip haben wir damit schon die grundlegende Topographie des Lightning-Netzwerks dargestellt. Die Zahlungen flitzen durch die Channels. Wenn Sven etwa noch einen Channel mit Tony hat und Tony mit Jan, dann kann Jens über die Route Christoph-Sven-Tony eine Transaktion an Jan senden. Und so weiter.

Was sich für ein Netzwerk daraus bildet, steht noch in den Sternen. Es könnte sein, dass es komplett dezentral bleibt und jeder User zwei, drei, vier Channels betreibt und sich die Zahlungen dadurch ihren Weg suchen. Es wäre gleichsam aber auch möglich, dass sich große Hubs bilden, die viel Kapital in vielen Channels einsperren, um die Verbindungen innerhalb des Netzwerkes zu vereinfachen. Sie werden wohl dadurch Geld verdienen, dass sie Daten über die Zahlungsgewohnheiten ihrer Channel-Partner sammeln und / oder Gebühren verlangen.

Wie schon bei den Payment-Channels lautet die goldene, große Frage nun: Wie kann das Ganze ohne Vertrauen funktionieren? Also, wenn Jens eine Transaktion an Christoph schickt, damit der sie an Sven weiterleitet – wie kann Jens sicher gehen, dass Christoph sich nicht ins Fäustchen lacht und den Bitcoin einfach behält?

Die Antwort ist nicht ganz einfach zu verstehen. Aber wir versuchen es.

Hash Time-Locked Contracts

Um über Christoph Geld von Jens zu erhalten, generiert Sven einen zufällig Wert. Nennen wir ihn R. R ist einfach irgendeine Folge von Nummern oder Zeichen, wie ein Passwort. Daraus bildet er dann eine Hash. Das ist eine mathematische Einwegfunktion: Aus einer Zeichenfolge entsteht immer dieselbe Hash, aber es ist nicht möglich, aus der Hash die Zeichenfolge zu rekonstruieren. Mehr darüber in diesem Artikel.

Diese Hash schickt Sven dann zu Jens. Nehmen wir, der Anschauung wegen, an, es sei eine SHA 256 Hash wie diese:

0a8500781be5e73270e1c19ae7e7ab4ca321415734de17a48ec110fdf389a799

Jens verspricht nun Christoph, dass er einen Bitcoin bekommt, wenn er den Wert liefert, der zu dieser Hash führt. Natürlich belässt Jens es nicht bei einem Versprechen, sondern bildet eine spezielle Transaktion: einen sogenannten Hash Contract.

Um das zu verstehen, solltet ihr wissen, dass jede Transaktion in ihrem Kern ein Script hat. Eine normale Transaktion sagt: “Du darfst mich ausgeben, wenn du eine Transaktion mit dem privaten Schlüssel signierst, der zu dieser oder jener Adresse passt.” Ein Hash Contract sagt nun eben: “Du darfst mich ausgeben, wenn du mir die entsprechende Signatur UND den Wert lieferst, der zu dieser oder jener Hash führt.”

Jens schickt also eine solche Transaktion an Christoph. Damit Christoph die Bitcoins in der Transaktion erhalten kann, muss er Sven darum bitten, ihm den der Hash zugrunde liegenden Wert zu geben. Dies macht Sven im Austausch gegen einen Bitcoin. In unserem Fall wäre der Wert “bitcoinblog.de”, was ihr mit dem netten Hashgenerator von Henrik nachprüfen könnt.

Wie verhindern wir aber, dass Christoph einfach darauf pfeift, die Transaktion weiterzuleiten? Er könnte sich ja schadenfroh damit zufrieden geben, dass Jens einen Bitcoin weniger hat, ohne Sven bezahlt zu haben. Die Transaktion von Jens steckt im Nirwana, und weder Christoph noch Sven haben etwas bekommen. Ähnlich würde es ablaufen, wenn Sven die Herausgabe des “Passworts” verweigert. Die verschiedenen Parteien der Transaktion könnten die anderen erpressen: Gib’ mir 0,1 Bitcoin mehr, oder deine 1,0 Bitcoin Transaktion wird für immer feststecken.

Hier kommen die Time-Locked-Contracts ins Spiel. Denn eine Lightning-Transaktion kann auf zwei Arten ausgezahlt werden. Zum einen, wie oben beschrieben, wenn Christoph seine Signatur und den der Hash zugrundeliegenden Wert abliefert. Zum anderen – und das ist das Sicherheitsnetz – wenn der Sender der Transaktion – Jens – seine Signatur zeigt. Dies funktioniert aber erst nach Ablauf einer bestimmten Zeit, daher auch “Time-Locked.” Wenn sich also eine Partei der Transaktionskette weigert, das Passwort rauszugeben, kann der Sender der Transaktion diese nach Ablauf einer bestimmten Zeit wieder auflösen. Das schlimmste, was passieren kann, ist, dass die Bitcoins für eine bestimmte Zeit eingefroren sind.

Es ist gar nicht so schwer, oder? Wir können das ganze auch darauf ausdehnen, dass die Zahlung von Sven über Tony zu Jan geht. In diesem Fall gibt Jens die Hash an Christoph, Christoph an Sven und Sven an Tony, während Jan die Lösung des Rätsels den Weg andersherum läuft, also an Tony, von Tony an Sven und vonn Sven an Christoph. Es ist im Prinzip derselbe Vorgang, außer, dass die “Time-Lock” entsprechend eingestellt werden muss, damit die Channels kaskadierend einfallen.

Damit hätten wir die Frage, wie Lightning ohne Vertrauen funktioniert, einigermaßen beantwortet. Schwieriger ist hingegen die Frage, woher die einzelnen Teilnehmer des Netzwerkes wissen, wie ihre Transaktion den Weg von Sender zu Empfänger findet.

Flare, Sphinx, Onion Rounting

Um eine Lightning-Transaktion abzusenden, brauchen Sie im Idealfall nur eine Hash. Sven möchte Geld haben, also hinterlegt er öffentlich eine Hash, und jeder, der Sven etwas spenden will, schickt Geld an die Hash. Zumindest könnte eine Zahlung so ablaufen.

Die Kunst besteht nun darin, eine Möglichkeit zu finden, den Lightning-Knoten auf eine dezentrale Weise klar zu machen, auf welchem Weg eine Zahlung ihr Ziel erreicht. Dies wird noch dadurch verkompliziert, dass nicht alle Mittelsmänner gleich sind. Wenn etwa Jan einen Bitcoin über Christoph an Sven schicken will, aber Christoph in seinem Channel an Sven nur 0,1 Bitcoin hat, muss sich Jan einen anderen Mittelsmann mit mehr Geld im Channel suchen. Eine Route durch das Netzwerk muss also nicht nur einen Weg ans Ziel finden, sondern auch sicherstellen, dass die Mittelsmänner genügend Bitcoins in den Channels haben.

Manche sagen, ein solches “Routing” wäre ohne zentrale Hubs nicht möglich, weshalb Lightning nicht, wie von vielen erhofft, besonders privat ist, sondern ganz im Gegenteil, ein Alptraum der Transparenz wird. Andere hingegen sagen, ein solches Routing ist nicht nur möglich, sondern bereits so gut wie entwickelt.

Genaueres kann ich hier nicht beurteilen. Ich kann mich nur auf die Lightning-Entwickler verlassen. Rusty Russel, Lightning-Entwickler für Blockstream, bloggt über das sogenannte Onion Routing im Dezember 2016: “Im Internet ist Routing einfach. Man wirft ein Paket raus, auf das eine Adresse gestempelt ist, und der Empfänger findet heraus, wie er es näher bringt. In der Regel funktioniert es. Wenn man aber Anonymität möchte, geht das jedoch nicht.” Und Anonymität ist, so Russel, für jeden Blockstream-Mitarbeiter ein großes, wichtiges Thema. Daher haben “Christian Decker und Olaoluwa Osuntokun das zuvor publizierte Sphinx-Schema für Lightning implementiert.”

“Sphinx” von David Stanley via flickr.com. Lizenz: Creative Commons

Sphinx ist ein Protokoll, entwickelt von George Danezis und Ian Goldberg. Es ist laut Whitepaper “ein kryptographisches Nachrichtenformat, das genutzt wird, um anonyme Nachrichten in einem Mix Netzwerk zu verbreiten. Es ist kompakter als andere vergleichbare Methoden, und bietet ein vollständiges Set an Sicherheit-Features: Es macht die Antworten ununterscheidbar, versteckt die Länge der Pfade sowie die Position der Sender und und bricht den Link zwischen den Gliedern der Reise einer Nachricht durch das Netzwerk.”

Für Lightning bedeutet die Anwendung von Sphinx, wie Rusty Russel erklärt, “dass kein Node sagen kann, wie viele Sprünge eine Transaktion bereits hinter sich hat, noch wie viele sie noch vor sich hat; lediglich, was der vergangene und was der nächste Sprung ist.” Dies ermöglicht, wie Russel in einem anderen Post erläutert, ein “vernünftiges” Maß an Privacy: Einzelne Knoten wissen, wie erwähnt, nur die letzte und die nächste Station einer Transaktion.

Allerdings können Nodes zusammenarbeiten, um Transaktionen zu identifizieren, und es ist möglich, mit Traffic-Analysen mehr herauszufinden. Laut Rusty gibt es jedoch bereits Ideen, wie man diese Probleme lösen kann, auch wenn die gegenwärtige Implementierung noch nicht in der Lage ist, auf ein übermäßig großes Netzwerk zu skalieren.

Eine Alternative zu Sphinx ist das Flare-Protokoll, das BitFury entwickelt hat. Die Firma hat darüber im Spätsommer 2016 ein Whitepaper geschrieben. Getestet wurde Flare von ACINQ, einem französischen Startup, das einen der ersten Lightning-Prototypen entwickelt hat. Laut BitFury konnte ACINQ mit 2.500 AWS-Knoten schnell und relativ zuverlässig Routen für Transaktionen finden. So wie ich es verstehe, hat Flare vor allem das Potenzial, gut zu skalieren:

“Das Design von Flare zielt darauf ab, zu gewährleisten, dass Routen im Lightning-Netzwerk so schnell wie möglich gefunden werden, während die Menge an Daten minimiert und die Dezentralität erhalten wird. Der Preis, um dies zu erreichen, ist, dass jeder Node proaktiv Informationen über die Topologie des Netzwerks sammelt, und reaktiv Informationen über die Topologie zusammenstellt, die er für eine Transaktion braucht … Wir haben Simulationen des Routing-Algorithmus durchgeführt und sind der Ansicht, dass sie bis zu 100.000 Knoten skalieren können.”

An sich steht dem Lightning-Netzwerk also nichts weiter im Wege.

About Christoph Bergmann (1148 Articles)
Das Bitcoinblog wird von bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder. Wenn Ihnen das Blog gefällt, freuen wir uns über Spenden an 1BvayiASVCmGmg4WUJmyRHoNevWWo5snqC. Wir akzeptiere mit dieser Adresse sowohl Bitcoin als auch Bitcoin Cash. Weitere Infos, wie Sie uns unterstützen können, finden Sie HIER. Gastbeiträge sind ebenfalls willkommen. Meinen öffentlichen PGP-Schlüssel sowie den Bitmessage-Schlüssel finden Sie HIER

32 Comments on Lightning: Wie aus Payment-Channels ein Netzwerk entsteht

  1. “An sich steht dem Lightning-Netzwerk also nichts weiter im Wege.”

    ..ausser das ASIC-Boost Patent von BitMain-Industries(70%der ASIC-Chip Herstellung

    weltweit), ueber das du leider nie berichtet hast und welches seit Jahren die fuer lightning

    notwendige aktivierung von SEGWIT wortwörtlich aktiv fuer alle beteiligten verhindert.

    https://www.asicboost.com/

    • pffff … weiß du, warum ich nicht über AsicBoost schreibe?

      Weil es ganz offensichtlich eine Blendgranate ist. Zumindest sagen das alle Experten zum Thema (Sergio, Timo, Marco, Sam Cole, Emin). Und noch mehr Gründe. Wer weiterhin glaubt, dass wir kein SegWit und kein Lightning haben wegen böse-Miner-AsicBoost, der will das glauben. Und dagegen kann und werde ich nicht anschreiben.

      Ich habe nicht über AsicBoost geschrieben, weil es Leuten wie dir nicht gefallen würde, was ich darüber schreiben würde.

      Und, ach ja:

      ” welches seit Jahren die fuer lightning notwendige aktivierung von SEGWIT”

      Unwissenheit oder absichtliche Misinformation? SegWit gibt es erst seit November, ein Lightning-Routing ist erst ab Dezember oder so möglich. Wie kommst du auf “Seit Jahren”?

      • Bei Software-Jahren ist das genauso wie bei Katzenjahren. Man nehme diese mit 7 mal.

      • Jens K. // 25. April 2017 at 13:00 //

        Also mit Asicboost lässt sich das irrationale Verhalten von Jihan & Co. schon ganz gut erklären.

        Generell vermute ich, dass Jihan irgendwo außerhalb der von Satoshi vorgesehenen Incentivierungen wirtschaftliche Anreize gefunden hat, um so zu handeln, wie er es tut.

        Das wäre prinzipiell schon ein spannendes Thema.

      • Sorry. Ich hätte sehr gerne darüber geschrieben, weil eine Menge Misinformation zu AsicBoost im Spiel ist und eine Menge Menschen offenbar froh sind, jetzt eine einfache Erklärung für den ganzen Mist gefunden zu haben, die den bestehenden Sündenbock bestätigt. Aber da ich keine Lust mehr auf die ständigen Kämpfe und Anfeindungen habe, lasse ich es. Wer sich informieren will, findet alle nötigen Quellen im Netz.

      • Jens K. // 25. April 2017 at 13:59 //

        Das hört sich so an, als ob du die absolute Wahrheit kennst.

      • Nein, kenne ich nicht und brauche ich auch nicht. Aber es gibt ein paar Dinge, die ich weiß:

        (1) Jihan Wu und Co. haben dutzendfach erklärt, aus welchen Gründen sie prinzipiell oder gegenwärtig nicht für SegWit sind und unter welchen Umständen sie es akzeptieren werden.

        (2) Eine lange Reihe von technischen Experten, darunter BitMain-unabhängige Hersteller von Asics und die Erfinder von Asic-Boost, haben erklärt, dass die Asic-Boost Vorwürfe Unsinn sind und dass SegWit nur eine von vielen Formen von einem möglichen heimlichen AsicBoost lösen würden.

        Solange diese beiden Punkte nicht mit Argumenten erwidert, sondern ignoriert werden, betrachte ich die Widerholung der AsicBoost-Vorwürfe als Misinformation.

      • Jens K. // 26. April 2017 at 23:34 //

        Dann vielleicht was zum Killswitch? Oder auch Misinformation?

      • Na klar werde ich darüber schreiben. Bin zwar noch damit beschäftigt, mir ein Bild zu machen, bevor ich ein Urteil fälle.

        Bisher sieht es etwa so aus, ja, ist im Source Code, nein, ist kein Killswitch (sagen zumindest ein paar Experten, aber ich muss erst noch durchsteigen, warum), aber ja, was ist es dann? Warum ist es drin? Was macht es? Etwa so. Infos von deiner Seite sind willkommen.

        P.S.: Darf ich deine ausbleibende Antwort zu meinem letzten AsicBoost Kommentar so verstehen, dass das Thema vorerst vom Tisch ist?

      • Unglaublich :

        […]

        einfach un-glaublich.

      • Du hast den Link schon unter dem Artikel über Litecoin untergebracht. Dieses Blog hier ist keine Müllhalde für Spam. Ich werde ohnehin über ascibleed berichten.

      • Jens K. // 27. April 2017 at 11:56 //

        Es sprengt hier einfach den Rahmen für die Blog-Kommentare. Wenn ich sage “Also mit Asicboost lässt sich das irrationale Verhalten von Jihan & Co. schon ganz gut erklären.” soll das noch nicht heißen, dass die Erklärung stimmt. Ich komme wohl nicht drum herum, es selbst auch einmal durchzurechnen.

        Aber ich weiß ehrlich gesagt, was mir lieber ist. Ob SegWit aus wirtschaftlichen Gründen von Bitmain blockiert wird oder aus politischen Gründen, um die Core Roadmap zu verhindern.

        Naja, in der Firmware von Bitmain ist ein Killswitch eingebaut, da gibt es gar nichts zu beschönigen. Bitmain, Cloudflare oder die USA hätten wohl einige Miner z.T. einfach vom Netz nehmen können.

        Unabhängig davon, warum dieses Backdoor eingebaut wurde, ist es vollkommen inakzeptabel und zeigt doch, dass man Bitmain, speziell deren technischer “Expertise”, in keinem Fall vertrauen darf.

      • Hallo, Killswitch: Bin dran, das Thema ist klar, dafür gibt es klare Beweise, und es ist nicht in Scalability-Politik verwoben. Das ist kein Ding.

        AsicBoost: Rechne mal durch. Alle Experten, alle Miner, alle Mining-Hersteller sagen, dass es Quatsch ist und dass die Zahlen nicht stimmen. Soweit ich weiß spart AsicBoost 20 Prozent Energie, macht aber einen Miner nicht 20 Prozent effektiver. Da unter modernen Mining-Bedingungen die Stromkosten vermutlich nur eine kleine Summe der Gesamtkosten des Minings sind (die Anschaffung / Herstellung ist am teuersten) ist das eher vernachlässigbar. Wie auch immer. Informiere dich und lies was beide Seiten sagen.

        Hier etwa ein weiterer Artikel: https://medium.com/@zhangsanbtc/if-bitmain-opposes-segwit-because-of-asicboost-why-did-they-agree-to-activate-segwit-before-a-257d832d8ef7

        Wenn du die Grundannahme fallen lässt, dass alle unbedingt SegWit wollen, ist AsicBoost im Grunde genommen kein Thema. Darum ärgert es mich auch so, wenn das immer wieder vorgebracht wird. Es wurde hundertfacht gesagt, warum nicht jeder SegWit so megageil findet, es wurde hundertfach gesagt, was die Miner wollen, und es wurde sogar ein schriftliches Abkommen unterzeichnet, in dem das festgehalten wurde. Es ist kein Geheimnis.

        AntBleed: Darüber werde ich, wie gesagt, berichten. Das ist ein wichtiges Thema.

  2. ..wie gesagt , Lightning network braucht Segwit auf Bitcoin und segwit wird von ASIC-Boost(BitmainIndustries) verhindert, da es mit segwit nicht mehr funktionieren wuerde..

    AsicBoost Increases Profits by 2,000% For Bitcoin Miners If Utilized Covertly: Antonopoulos

    https://www.cryptocoinsnews.com/asicboost-increases-profits-2000-bitcoin-miners-utilized-covertly/?utm_source=dlvr.it&utm_medium=twitter

    oder als video von antonopoulos von vor 4 tagen:

    ..das sind wesentlichste informationen…

    • Warum braucht Lightning SegWit?

      Warum erhöht sich der Profit um 2.000 Prozent?

      Wenn du hier schon deinen Kreuzzug gegen BitMain hertragen musst, dann bitte mit Argumenten anstatt mit Links.

      P.S.: Ich habe auch einen Link!

      https://btcmanager.com/the-story-behind-the-asicboost-extension-blocks-scandal/

      • Volker // 26. April 2017 at 7:42 //

        Christoph – schöner Artikel über Lightning, dabei soll es auch bleiben. Ich ermuntere Dich weiter, Deinen Standpunkt gegen Spekulationen, Verschwörungen etc. aufrecht zu erhalten. Das ist guter (technischer) Journalismus.
        Die Kiddies mit ihren “böse ASIC Boot Welt” haben doch eine Platform in Reddit dafür. Da dürfen sie wild spekulieren, und sich mal richtig empören, dass da einer versucht, mit Bitcoin Geld zu verdienen, und es damit anderen “fast” unmöglich macht, auch was daran zu verdienen. Und jetzt richtig wild rumzetern, dass da eine Stimme von ganz oben (von den neuen “freien” kapitalistischen Göttern oder Religionsführern? – haha) her muss, die/der das jetzt mal korrigiert. Denn so sein Geld verdienen, das ist ja moralisch verwerflich.
        Irgendwie haben sie alle nicht kapiert, was es bedeutet, an einem “offenen” System mit zuarbeiten, wo jeder OHNE KONTROLLE dran teilnehmen können soll… Dieses Gutmenschen Verhalten kommt jetzt also auch in die Bitcoin Welt. Mist.

  3. Toller Artikel!

  4. Vielen Dank für den anschaulichen Artikel mit tollen Vergleichen!

    Meiner Meinung wird es nicht um Hubs herumkommen und auch um Gebühren, von jedem Knoten einzeln. Diese werden wahrscheinlich relativ niedrig ausfallen, aber auch kleine Nodes werden sie verlangen (müssen). Um einen Payment Channel zu eröffnen, brauche ich eine (relativ komplexe und damit teure) OnChain Transaktion. Um ihn wieder zu schließen, auch. Diese Fee muss zudem relativ hoch angesetzt werden, damit sie nicht im Mempool stecken bleibt. Mal angenommen, ich möchte Dir regelmäßig etwas spenden, wenn mir ein Artikel gefällt, eröffne ich einen Payment Channel mit 0,1BTC und möchte Dir ab und zu 0,001BTC zukommen lassen. Irgendwann schickt jemand über mich, Dich 0,09BTC an Bitcoin.de (zu denen Du einen Channel hattest). Wenn ich Dir nun wieder Mal etwas spenden will, stelle ich fest, dass unser Channel “aufgebraucht” ist und ich mir entweder eine neue Route suchen muss, oder einen neuen Channel zu Dir aufbauen, wieder über eine teure OnChain Transaktion. Oder ich hoffe darauf, dass irgendjemand in Deinem Netzwerk über mich etwas an jemanden aus meinem Netzwerk verschickt und unser Channel wieder auf meiner Seite “gefüllt” ist. Noch schlimmer wird es, wenn man einen Payment Channel z.B. zu BitPay eröffnet und üppig füllt, denn dann steigt die Gefahr, dass er schnell von meinem Netzwerk “aufgebraucht” wird und ich auf den Fees sitzenbleibe, die zum Öffnen und Schließen benötigt werden. Es ist sehr unwahrscheinlich, dass Bitpay eine Transaktion über mich an jemanden von meinem Netzwerk routet. Von daher halte ich Fees für unabdingbar für Dezentralisierung.

    Naheliegend ist es doch, dass sich wenige große Hubs bilden, denn der Durchschnittsnutzer wird keine 5 Channels zu irgendjemandem offen halten, über die er praktisch keinen Überblick hat, sondern braucht nur einen mit einem großen Hub, die wiederum perfekt untereinander vernetzt sind und jegliche Routen abdecken können. Wallet Anbieter werden mit Sicherheit ihre eigenen Hubs aufsetzen und bekommen (endlich) die Möglichkeit, Geld über Fees zu verdienen, um die Entwicklung zu finanzieren. Leider wird die Dezentralisierung stark darunter leiden…

    Zusätzlich muss man beachten, dass man das Netzwerk ständig beobachten muss, ob der Channel Partner keine alte Transaktion propagiert, deren Balance zu seinen Gunsten war. Dieser kann man mit einer Penalty Transaktion gegensteuern, wenn man eine neuere von beiden Seiten signierte Transaktion vorweisen kann. Entweder vertraut man diese Aufgabe einem externen Dienstleister (z.B. Wallet Betreiber) an, oder man muss einen Full Node 24/7 online haben. Somit ist Dein Vergleich mit dem nicht eingeworfenen Überweisungsschein sehr gut und anschaulich, allerdings wird er nicht jedes Mal umgeschrieben, sondern ein neuer (im Prinzip sogar zwei, für jeden einer) geschrieben und von beiden Seiten unterschrieben. Das hindert jedoch keine Partei, einen alten Überweisungsschein zu veröffentlichen. Dazu sind die Time Locks vorgesehen, innerhalb derer man anhand eines beidseitig signierten Überweisungsscheins mit neuerem Datum beweisen kann, dass man im Recht ist.

    Sphinx wird sich auch beweisen müssen, dass man nicht weiß, wie viele Hops vor und nach einem kommen, denn alleine die Grafik mit den immer kürzeren Timelocks von Hop zu Hop dürfte dies verraten.

    Hoffentlich sehen wir bald bei Litecoin mehr! Wobei Litecoin eine deutlich kleinere Verbreitung hat als Bitcoin und somit nicht 1zu1 übertragbar ist…

    • Danke für den Kommentar bei dem es mal ums Thema geht 🙂

      Ich kann das wenigste davon beantworten. Vermutlich wirst du recht haben – wir müssen erst mal sehen, wie es sie abspielt. Litecoin könnte dafür ein Labor sein, aber ich stelle mir das Raiden-Netzwerk auf Ethereum interessanter vor, um zu erfahren, wie sich das Netzwerk ausbildet.

      Ein paar Ideen / Antworten:

      – OnChain-Gebühren: Kann sein, dass sie für die komplizierte Eingangstransaktion hoch sind, kann aber auch sein, dass sie sehr günstig sind, weil LN ja die Last auf die Blöcke reduziert. Zumindest ist das das Ziel — denkbar wäre auch, dass Miner etwa sehr viele Channels mit kleinen Guthaben eröffnen (0,1 MB oder so) und das dann natürlich mehr oder weniger kostenlos machen, um später davon zu profitieren. Es gibt hier recht viele Szenarien, die von so vielen unbekannten Variablen abhängen, dass man das jetzt noch nicht sagen kann.

      – Channel “aufgebraucht”: Darüber habe ich auch ein wenig nachgedacht, kam aber zu keiner echten Lösung. Eventuell bekomme ich von einem LN-Dev noch eine Antwort darauf, eventuell bekomme ich mal ein Interview, um solche DInge zu klären. Aber wie ich es verstehe, bekomme ich ja in dem von dir genannten Beispiel den Betrag, den ich an Bitcoin.de weiterleite, quasi im selben Moment, weswegen mein Channel doch noch immer funktionsfähig sein sollte? Wie das mit der Hash und den Transaktionen abläuft – keine Ahnung.

      – Wenn ein Channel leer wird … die Fees müssten doch eigentlich in der letzten Transaktion schon enthalten sein, ansonsten kann ja keiner den Channel schließen? Oweh. Kompliziert …

      – da man für mehrere Channels auch jeweils die Beträge reinlegen muss, denke ich auch, dass es zu großen Hubs kommen wird und der Normal-User sich mit einem Channel zu einem solchen Hubs begnügen wird. Aber da Bitcoiner ja schon an sich keine Normal-User sind, kann das alles auch anders kommen. Mal schaun 🙂

      – Netzwerk beobachten: Gefällt mir auch nicht. Würde für mich einen Payment-Channel für Spenden recht unattraktiv machen.

      – Sphinx: Keine AHnung. Anscheinend funktioniert es mit >2.500 Knoten (zumindest ist das die Zahl, die ich irgendwoher im Kopf habe). Wäre für den Anfang schon mal recht gut. Aber auch das kann ich nicht einschätzen, das übersteigt meine Kompetenz ziemlich weit …

      • Danke für den Kommentar bei dem es mal ums Thema geht 🙂

        Ich dachte mir, ASICboost, Jihan & Segwit Signaling haben wir die letzten Wochen fast unter jedem Artikel ausreichend durchgekaut, ich warte hier eigentlich auch noch auf Roger & BU 😉

        Raiden kann natürlich von der Komplexität des Ethereum Netzwerks profitieren und benötigt gar keinen Konsens, was spannend ist. Die Komplexität Ethereums macht vieles einfach, aber birgt auch Schwierigkeiten und mögliche Angriffsvektoren, wie wir bereits beobachten konnten. Ob “ein Netzwerk für Alles” auf Dauer gut skaliert, bleibt auch abzuwarten, aber jetzt komme ich vom Thema ab…

        OnChain Gebühren könnten in der Tat kurzfristig sinken, wenn vieles über Channels läuft, allerdings habe ich des öfteren gelesen, LN ist eher für Transaktionen bis 100$ gedacht, da ein gewisses Vertrauen und Überwachung nötig ist. Aber du hast Recht, zu viele Unbekannte, die sich erst ergeben werden…

        Aber wie ich es verstehe, bekomme ich ja in dem von dir genannten Beispiel den Betrag, den ich an Bitcoin.de weiterleite, quasi im selben Moment, weswegen mein Channel doch noch immer funktionsfähig sein sollte?

        Ja, nur eben z.B. mit der Balance 0,099BTC Du, 0,001BTC ich und somit kann ich Dir so lange nichts mehr über diesen Channel schicken, bis Du mir (oder über mich) etwas schickst oder jemand über Dich… Der Netzwerkeffekt muss sich hier auch noch zeigen, gerade bei Payment Anbietern wie Bitpay gehen viele kleine Zahlungen in eine Richtung und nur relativ wenige große raus.

        Wenn ein Channel leer wird

        “leer” wird ein Channel nie, die Gesamtbilanz in jedem Channel bleibt immer gleich, bis er geschlossen wird. Es verändert sich nur die jeweilige Auszahlungsquote der beiden Partner und soweit ich das verstehe, muss man bei jedem neuen “Settlement”, welches beide signieren, eine Gebühr zurück auf die Chain berücksichtigen. Denn man benötigt laut [1] eine Transaktion zum Öffnen und eine zum Schließen eines Channels und diese muss zwangsläufig eine Gebühr enthalten, um in einen Block zu kommen. Bei normalen Transaktionen kann man die Gebühr abschätzen, die man aktuell benötigt. Aber was passiert, wenn die letzte Transaktion in einem Channel vor einem Monat war und eine Seite will ihn schließen, aber die damals festgelegte Gebühr nicht mehr ausreicht, um in einen Block aufgenommen zu werden?

        Aber da Bitcoiner ja schon an sich keine Normal-User sind, kann das alles auch anders kommen.

        Wenn LN skaliert gehen wir mehr in Richtung Durchschnittsuser und der Mensch ist faul. Wie man überall sieht, auch nicht wirklich an seiner Privatsphäre interessiert. Stichwort Payback, Hauptsache läuft (einfach).

        Das mit dem Netzwerk beobachten läuft auf externe Dienstleister (und somit leider auch Zentralisierung) hinaus, denn kaum ein Durchschnittsuser wird einen Full Node 24/7 online lassen. Mal abgesehen von der Möglichkeit gezielter Attacken auf diesen, um das Monitoring zu stören…

        Alles noch nicht ganz klar, daher bin ich ganz froh, dass es scheinbar bei Litecoin erstmal eine öffentliche Beta gibt 😉

        1. https://medium.com/@AudunGulbrands1/lightning-faq-67bd2b957d70

    • Name required // 25. April 2017 at 17:26 // Reply

      Stratis arbeitet gerade an exakt dem Modell. Es soll Nodes geben, die u.a. für die Payment-Channels zuständig sind, andere als Tumbler für Bitcoin fungieren, wieder andere sollen Anknüpfungspunkte für firmeneigene Blockchains sein, die über die Stratis-Hauptblockchain abgesichert werden und vieles mehr.
      Vielleicht kann man die im Artikeltext als Überweisungen bezeichneten Off-Chain-Transaktionen noch besser als Wechsel bezeichnen, wie es sie ja im herkömmlichen Zahlungswesen bereits gibt. Hierbei werden ja auch lediglich Zahlungsverpflichtungen weitergegeben, ohne dass eine Bank gegenzeichnet …

      • Müssen wir jetzt neben Roger, Jihan, ASICboost, BU, Segwit Blockierern und anderen “Verrätern” auch unter jedem Beitrag noch Stratis unterbringen? Das Projekt steckt afaik noch in den Kinderschuhen und verspricht, die nächste eierlegende Wollmilchsau zu werden. Mag sein, dass es zu dieser wird, aber derzeit ist wenig Substanz vorhanden. Selbst das Whitepaper enthält NULL technische Details [1], und liest sich wie ein Werbeprospekt. Und die Programmiersprache ist unerheblich, wirklich. Es gibt sogar vernünftige Projekte in Skriptsprachen wie PHP oder JavaScript. Nichts für ungut…

        Zum zweiten (themenrelevanten) Teil: Ich denke, mit nicht eingeworfenen Überweisungsscheinen hat Christoph gut getroffen, denn es ist tatsächlich ein Überweisungsauftrag von einer Art Treuhandkonto an zwei Empfänger.

        1. https://stratisplatform.com/files/Stratis_Whitepaper.pdf

      • Tony Ford // 26. April 2017 at 13:00 //

        Meiner Meinung nach sind Programmiersprachen wie Java und Javascript perspektifisch interessanter als C#. U.a. weil es die meisten Plattformen erreicht, sich zudem immer mehr zum Standard entwickelt.
        Andererseits spielt die Sprache nur eine untergeordnete Rolle, weil sich Quellcodes mit einem gewissen Aufwand in andere Sprachen überführen lassen.

    • Christoph // 30. April 2017 at 22:47 // Reply

      Ich bin gedanklich EXAKT bei den gleichen Problemen angelangt und weiß auch keine Lösung, außer eben zentrale Banken äh Hubs. Das kann es ruhig geben – ist eine wertvolle Erweiterung von Bitcoin, aber es löst auf keinem Fall alle Probleme!

  5. Tony Ford // 25. April 2017 at 14:41 // Reply

    Asicboost ist eine Leistungssteigerungen des Bitcoin-Mining, nicht mehr und nicht weniger.
    Mittels dieser Leistungssteigerung können die Miner die diese neuen Miner anfänglich einsetzen, profitieren, weil sie sich einen Vorteil zu den Minern mit alter Technik verschaffen.

    Lightning spielt dabei keine nennenswerte Rolle, weil …
    – Lightning zwar die Anzahl der Tx ( onchain ) senkt, jedoch die Anzahl der Blöcke nach wie vor gleich bleibt und dementsprechend auch der Reward gleich bleibt
    – die Tx-Gebühren spielen im Vergleich zum Reward eine untergeordnete Rolle, sie machen lediglich ca. 10% an den Einnahmen der Miner aus.
    – Miner bedingt dieser Konstellation primär von steigenden Kursen profitieren. D.h. für Miner ein Kursanstieg von 20% wesentlich mehr wert ist als alle Transaktionsgebühren die anfallen.

    Ein Asicboost verkauft sich umso besser je besser sich der Kurs entwickelt. Wenn der Kurs stagniert, wird kaum ein Miner aufrüsten, sondern versuchen mit dem bestehenden Equipment seine Kosten wieder ein zu spielen.

    Es ist schade, dass so wenig Wissen um die Zusammenhänge besteht und man irgendwelchen Miner-Hetztiraden blind hinterher läuft, sich quasi aufhetzen lässt.

    • Was ich nicht verstehe ist: Warum wird SegWit von vielen Pools (Minern) nicht akzeptiert, wenn sich doch alle einig sind, das der Kurs mit SegWit massiv steigen würde? (siehe auch Litecoin als Beispiel, für Bitcoin vermutlich 2000+ mit SegWit).

      Vieleicht sind es nicht wirtschaftlichen Gründe für diese SegWit Blockade, obwohl ich mir das bei soviel Geld um das es hier geht kaum vorstellen kann.

      Oder, vieleicht würde ein ASICBOOST-Pool trotz massiver Preissteigerung, die SegWit mit sich brächte, am Ende Geld verlieren, weil er Marktanteile verlieren würde, ohne ASICBOOST. Wäre doch denkbar. In dem Fall würde eine SegWit Blockierung Sinn machen, da SegWit ja ASICBOOST inkompatibel macht.

      jm2c

      • Tony Ford // 26. April 2017 at 8:59 //

        Der “ASICBOOST-Pool” profitiert mit oder ohne SegWit von den Vorteilen gegenüber anderen Minern.

        Der Streitpunkt ist weniger wirtschaftlicher, sondern primär politischer Natur.

        Mittels einer Hardfork auf 2 MB ( welche zu Beginn der Blocksize-Debatte mit den Entwicklern ausgehandelt wurde ) wäre SegWit von Minern längst akzeptiert und wohl auch aktiviert worden.

        Der Ball liegt meines Erachtens nach auf Seiten von Bitcoin Core, die es letztendlich in der Hand haben sich an die Aussagen von damals zu halten, womit sich dann nämlich auch die Miner an ihren Aussagen halten würden.

        Andererseits, vielleicht braucht Bitcoin auch gar nicht mehr Tx – Kapazitäten, denn wie man sieht läuft das Netzwerk seit Wochen und Monaten auch mit der begrenzten Anzahl an Tx stabil weiter.
        Vielleicht entwickelt sich Bitcoin eben zum Settlement-Netzwerk, ähnlich wie Gold quasi primär als Settlement dient.

  6. “The burden of knowing more about a subject than most people, is that most of what you hear people say about it is wrong.

    And the liability of thinking you know more than most people, is that you stop correcting yourself.”

    Eric Lombrozo

  7. Es heißt: “der Hash”.

      • Aus dem Gefühl heraus würde ich auch “der” nehmen, Duden online findet nur “Hashtag”. Aber aus meiner Jugendzeit kenne ich nur “das Hash”, aber um Verwechslungen zu vermeiden wäre “der” oder gar “die” hier passender 😉
        Oder wir einigen uns auf “die Prüfsumme”…

        Jetzt sind wir aber wieder ein paar Meter vom Thema abgeschweift!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s