Guten Tag,
Ich würde mich gerne mehr in die 2nd layer Thematik von bitcoin rein arbeiten.
z.B erstmal:
Wie funktioniert überhaupt das Prinzip.
Microsoft arbeitet gerade ja auch an einer Lösung mit dem Projekt ION.
Hat da jemand Tipps, Infos oder gute Ideen wo ich mich informieren kann?
Ggf. Hat hier jemand schon Erfahrungen damit gesammelt?
LG
Bis zum 12. Oktober warten und folgendes Buch kaufen:
„Mastering the Lightning Network: A Second Layer Blockchain Protocol for Instant Bitcoin Payments“ von Andreas M. Antonopoulos.
Natürlich gibt es auch schon vom Blocktrainer Informationen dazu:
Nicht nötig zu warten
Muss man nicht kaufen
Das Buch ist Open Source und öffentlich auf GitHub einsehbar, Andreas arbeitet mit der Community zusammen. Einfach die einzelnen Kapitel anklicken und lesen, die meisten sind auch bereits vollständig fertig:
Das Buch ist allerdings relativ anspruchsvoll, man sollte zumindest Mastering Bitcoin zuvor gelesen haben.
Die beste Möglichkeit sich in das Thema rein zu arbeiten @Cointact ist finde ich sich eine Full Node aufzusetzen und selber am LN teilzunehmen. Hier im Forum findest du dann massig Leute mit denen du Channel austauschen kannst und Videos zu verschiedenen Optionen findest du auf dem Blocktrainer Kanal.
Und der bereits verlinkte Artikel auf https://www.blocktrainer.de ist sowieso total genial, der erklärt das wirklich sehr gut.
Danke für deine Antwort.
Ich werde mich hier weiter umsehen.
Eine node in Form von umbrel läuft bereits. Ebenso ein kleiner USB miner zum Spielen. Doch irgendwie komme ich noch nicht so richtig dahinter wie z.B. ION technologisch oder auch framework technisch funktionieren soll.
Was ich damit meine ist, dass ich als „user“ die Technologie sehr gut verstehe. Im Sinne von, „sei kein Apple User, sei ein linux root“. 
Doch als angehende programmiererin komme ich einfach nicht dahinter wie ein 2.layer funktionieren soll. Ist ein 2. Layer ein Programm auf, oder verknüpft mit einer node? Oder ist ein 2.layer wie ION eine eigene node die nach den Regeln von bitcoin core funktioniert?
Also nehmen wir mal an ich hätte eine coole Idee die auf oder mit der bitcoin blockchain laufen soll. Ist eigentlich egal was. Tokenisierung von Dingen oder sowas. Ich sende bitcoin an den 2.layer und bekomme 1sat mit einem gewissen Anhang zurück. Oder was weiß ich.
Wie kann ich mir das vorstellen?
Nimmt man sich einfach bitcoin core und programmiert dann da herum?
Liebe Grüße
Hast Du schon mal in das entsprechende Whitepaper geschaut? Vielleicht klärt das Deine Fragen zum Teil.
Das von @HODLer verlinkte Whitepaper löst wahrscheinlich alle Unklarheiten, ist aber schon ein Schinken.
Aber mal auf die Schnelle von einem Nicht-Experten:
Kein Bitcoin Second Layer wie Lightning, Cardano, Binance Smart Chain etc. ist direkt mit dem Bitcoin Base Layer verknüpft. Es ist also nicht möglich Bitcoin von der Mainchain zu diesen Layern zu transferieren!
Bei einer direkten Verbindung der Bitcoin Blockchain mit anderen Netzwerken wäre die Sicherheit der Bitcoin Blockchain gefährdet.
Die Bitcoin werden stattdessen nur auf der Mainchain gelockt, und ein entsprechender Stellvertreter/Token wird auf dem Second Layer übertragen. Wenn der tokenisierte Bitcoin vom Second Layer zurück übertragen werden soll, wird einfach die Sperre auf der Mainchain wieder aufgehoben.
Die Kunst liegt nun alleine darin den Sperr- und Entsperr-Mechanismus so zu designen, dass auf dem Base Layer und dem Second Layer unter Berücksichtigung aller Parteien alles mit rechten Dingen zu geht.
Dafür werden Multisig-Adressen und sogenannte Hash Time Locked Contracts (HTLCs) verwendet. Je nach Anwendungsfall werden Bitcoin auf der Mainchain z.B. an Multisig Adressen gesendet, zu denen die Schlüssel bei unterschiedlichen Second Layer Parteien liegen. Zusätzlich können Bitcoin auf Adressen für gewisse Zeiträume gesperrt werden.
Falls Englisch ok ist, wird in diesem Video die Lightning Funktionsweise in Bezug zur Bitcoin Mainchain sehr gut erklärt. Und das in einem Rollenspiel zwischen A. Antonopoulus und R. Pickhardt:
Lightning Series: Mastering Lightning with Andreas M. Antonopoulos & René Pickhardt - YouTube
@skyrmion
Wir kommen der Sache deutlich näher!
Ich denke mal das war auch schon der erste Teil der Lösung die ich gesucht habe.
mal ein doofes Beispiel:
Ein Unternehmen programmiert eine Music-Box App die mit Sat aufgeladen werden kann.
pro Track kostet dass dann 1 sat.
Wenn jetzt der User diese App nutzen will, transferiert der User sat auf sein Wallet der App. Sagen wir mal 10 sat. Was nun passiert, ist dass ein Channel zwischen dem Unternehmen und dem User geöffnet wird. Pro Track wird dann aufm 2. layer (Die Wallet-App), 1 sat an das Unternehmen gesendet. Sind nun alle tracks „Verbraucht“ könnte es in der App geschrieben sein, dass sich der Channel schließt und die „Dienstleistung“ abgeschlossen wurde. Der Channel schließt sich und das Unternehmen erhält dann die 10 sat auf dem Main Layer. richtig?
Meine Frage ist dann wiederum, wo oder als was müsste das Programm der App geschrieben sein?
Die Music-Box-App wäre dann nichts anderes als ein Wallet speziell für diese Dienstleistung.
Man könnte auch sagen, das Wallet ist eine „Wallet-App“. Also ein Wallet das bei bestimmten „Signaturen“ bestimmte Tracks spiel. Ist das so richtig?
Das Whitepaper gebe ich mir natürlich auch noch.
An das Whitepaper habe ich gar nicht mehr gedacht.
Danke @HODLer manchmal sieht man den Wald vor lauter Bäumen nicht mehr.
Liebe Grüße und danke der guten Antworten.
Jedes Öffnen und Schließen eines Lightning Channels erfordert eine on-chain Transaktion, inkl. der dafür fälligen on-chain Gebühren. Es wäre also nicht im Sinne des Erfinders, wenn man bei jeder Lightning Zahlung einen Channel aufmacht.
Stattdessen verwendet man eine eigene (non-custodial) oder fremde (custodial) Lightning Node, die bereits mit mehreren Channels gut an das restliche Lightning Netz angebunden ist. Solange es zwischen der Sende- und der Empfangs-Node einen oder mehrere Pfade über andere Lightning Nodes gibt, die zusammen eine ausreichende Balance aufweisen, kann man darüber zahlen.
Nur gelegentlich muss man die Channels wieder mit BTC von der Mainchain füllen, wofür dann on-chain Transaktionen notwendig sind.
Mit den Details kenne ich mich wie gesagt leider nicht aus. Es gibt aber sicher ein paar erfahrene Lightning User oder Entwickler hier, die das wissen. Evtl. @DocBrown ?
Die Wallet App könnte wahrscheinlich so funktionieren, dass sie für jeden Track automatisch im Hintergrund eine Lightning Rechnung vom Anbieter erhält. Die Transaktion wird automatisch von der App durchgeführt und nach Empfang wird der Track gestreamt. Solche Micro Payments sind möglich, wenn die Node Betreiber entlang der Zahlungsroute keine Base Fee verlangen, sondern nur einen prozentualen Anteil.
Wenn man so eine App selbst programmieren wollte, müsste man wahrscheinlich eine API zur Lightning Node Software LND verwenden.
Ich verstehe immer am meisten, wenn ein „Nicht-Experte“ erklärt, der es verstanden hat.
Also danke für die Übersetzungs-Leistung und „weiter so“!
Das ist so nicht richtig. Erstmal sind Cardano usw. keine Second Layer, Lightning schon.
Dazu am besten folgenden Twitterthread lesen, ganz frei nach dem Motto, er hat es toll erklärt, ich kann es nicht besser.
Das ist jetzt eine Definitionsfrage was transferieren in deinen Augen bedeutet.
Was Lightning konkret angeht tauscht du nur Signaturen und neue Transaktionen in diesem Netzwerk aus. (Details wie banales „messaging“ usw. sind hier mal ausgeschlossen)
Es handelt sich dabei jedoch immer um gültige Bitcoin Transaktionen, ich werde das unten versuchen einmal grob vom Prinzip her zu erklären (es ist aber technisch nicht so umgesetzt).
Du lockst keine Bitcoin auf der Mainchain, die in Lightning dann einen Stellvertreter kriegen, der übertragen wird.
Was du machst ist mit deinem Channelpartner Publickeys austauschen, nun könnt ihr beide mit den ausgetauschten Publickeys eine 2-of-2 Multisig erstellen (ich werde in den „Skizzen“ unten dann diese Adresse als bc1…2of2 nennen).
Wer auch immer von beiden derjenige ist, der diesen Channel funded, der wird dann noch eine refund transaction erstellen in der die Multisig den ganzen Betrag an eine vom Funder alleine kontrollierte Adresse (diese werde ich unten bc1…fd1, bc1…fd2 usw. nennen) auszahlt.
Erst wenn diese refund transaction von der Gegenpartei signiert wurde wird der Funder die Funding Transaction für die 2-of-2 Multisig wirklich machen (signieren, erstellen wird er sie vielleicht schon vorher) und publizieren.
Das macht er, damit er eben nicht in eine Geiselsituation kommt und auf dieser 2-of-2 1BTC liegen, die er nur mit Hilfe der Gegenpartei bewegen kann, obwohl diese bisher nichts getan hat um sich einen Anteil an diesen zu verdienen.
Nun sieht der Verlauf eines solchen Payment Channels (notwendige Info durch Penaltyfunktionen werden alte Zustände für beide Parteien ökönomisch unlukrativ gemacht) über seine Existenz so aus:
Wie es prinzipiell abläuft (sehr vereinfacht, fees wurden weggelassen usw.)
FD (Funder) und CP (Channelpartner) tauschen PubKeys aus und erstellen eine 2-of-2 Multisigadresse.
FD erstellt eine Refundtransaktion oder auch Commit 0 manchmal genannt, die so aussieht:
Txid: Refund…commit0
–
Input: bc1…2of2 (Multisigadresse die bisher keine UTXO/Balance hat) Amount: 1 BTC
Output: bc1…fd1 (Vom FD alleine kontrollierte Adresse) Amount: 1 BTC
–
Er lässt jetzt erstmal CP diese Transaktion signieren, damit er eben nicht in die Geiselnahme kommt.
Sobald diese signiert wurde hat er praktisch seine Versicherung, dann kreiert er die Fundingtransaktion, die so aussieht:
Txid: Fund…blabla
–
Input: bc1…fd0 (Adresse die FD alleine kontrlliert) Amount: 1 BTC
Output: bc1…2of2 (Multisig von oben) Amount: 1 BTC
–
Diese signiert er und publiziert er jetzt, dann liegen seine ursprünglichen 1 BTC auf der Adresse bc1…2of2, aber er hat in der Rückhand schon die Versicherung, dass im Todesfall von CP oder was auch immer passiert er an seine Bitcoins kommt.
Was jetzt im Paymentchannel passiert ist, dass eben weil Txid: Refund…commit0 nicht publiziert wurde man dann die Verteilung des Geldes die ganze Zeit updaten kann und einfach dabei bleibt es nicht zu publizieren.
Das heißt man zahlt die Miete und macht ein neues Commitment:
Txid: Blabla…commit1
–
Input: bc1…2of2 Amount: 1 BTC
Output: bc1…fd2 Amount: 0,5 BTC
Output: bc1…cp1 (neuer Output nur in der Hand von CP kommt dazu) Amount: 0,5 BTC
–
Diese Transaktion wird signiert und die Refund…commit0 ökonomisch schädlich für jeden der sie publiziert gemacht.
Wiederhole Schritt 6. und mache ein Update was die Geldverteilung angeht, z.B. kauft CP/Vermieter vom FD/Mieter einen Fernseher.
Neue Txid: Blabla…commit2
–
Input: bc1…2of2 Amount: 1 BTC
Output: bc1…fd3 Amount: 0,7 BTC
Output: bc1…cp2 Amount: 0,3 BTC
–
Diese Transaktion wird signiert und die Blabla…commit1 ökonomisch schädlich für jeden der sie publiziert gemacht.
Wiederhole Schritt 6.
Wiederhole Schritt 7. bezogen auf Blabla…commit2
Irgendwann wollen die Parteien ihren Paymentchannel schließen und publizieren einfach die letzte Blabla…commitX nachdem sie diese von allen Penaltyfunktionen befreit haben und teilen das Geld entsprechend dem letzten Stand auf.
Hierbei gibt es keine praktisch gelockten Funds zu irgendeinem Zeitpunkt auf der Blockchain, in der Chain gibt es dann nur 2 Transaktionen.
A: Fundingtransaktion
Txid: Fund…blabla
–
Input: bc1…fd0 (Adresse die FD alleine kontrlliert) Amount: 1 BTC
Output: bc1…2of2 (Multisig von oben) Amount: 1 BTC
–
B: Settlementtransaktion
Neue Txid: Blabla…commit2 (hat in der Realität ne andere TXID als die Blabla…commit2, weil hier die Outputs nicht wirklich identisch zu denen aus Blabla…commit2 sind)
–
Input: bc1…2of2 Amount: 1 BTC
Output: bc1…fd2 Amount: 0,7 BTC
Output: bc1…cp2 Amount: 0,3 BTC
–
Dieses Geld ist in beiden Fällen sofort spendable ohne in irgendeiner Form gelockt zu sein.
Nun zu der etwas detaillierteren, aber noch immer unvollständigen Erklärung wie Paymentchannels und somit die Basis des Lightning Networks aktuell funktioniert und wo immer dieses Bild entsteht, dass hier Geld gelockt ist.
Punkt 1 bleibt genau gleich.
Punkt 2 ändert sich folgendermaßen:
FD erstellt wie zuvor zuerst die Refundtransaktion/Commit 0, aber Bob akzeptiert das nur, wenn in dem Output ersichtlich ist, dass dieser widerrufbar/bestrafbar ist.
Es somit nicht eine einfache P2WPKH Adresse, für die nur ein Schlüssel den Alice kennt benötigt wird um das Geld auszugeben.
Was er hingegen als Script hinter dieser Adresse (nach aktuellem Stand) verlangt ist eine folgende Bedingung zum Ausgeben der Coins:
FD-Key && 144 Blöcke || FD-RevKey && CP-Key.
Was so viel bedeutet wie, hinter dem Output bc1…fd1 in der Refundtransaktion steckt das Script Funder kann mit seinem Key nachdem diese Transaktion bestätigt wurde nach 144 Blöcken diesen Output ausgeben ODER der Channelpartner mit seinem CP-Key und dem FD-RevKey, wenn er vom Funder den RevocationKey erhalten hat (wie er und wieso er den erhält kommt noch)
Das ändert unsere Refundtransaktion von der Optik nicht (bleibt ein Input/ein Output, gibt kein Wechselgeld usw. wie gesagt alles sehr vereinfacht)
Txid: Refund…commit0
–
Input: bc1…2of2 (Multisigadresse die bisher keine UTXO/Balance hat) Amount: 1 BTC
Output: bc1…fd1 (Script dahinter FD-Key&&144Blk||FD-RevKey&&CP-Key) Amount: 1 BTC
–
Wichtig ist nur, der Funder hat nun eine Transaktion die ihm garantiert, dass er nach 144 Blöcken im schlimmsten Fall, sobald er die Refundtransaktion publiziert sein Geld wieder hat (144 hab ich jetzt nur gewählt, weil das ein Tag ist, weiß nicht was aktuell im Protokoll für eine genaue Zahl verwendet wird). Er ist also somit genauso safe wie zuvor vor der Geiselnahme.
Weiters ist wichtig, dass der Channelpartner nun weiß, dass er einen Mechanismus hat mit der er diese Transaktion bestrafen kann, wenn es eine aktuelle Version gibt.
Er braucht dazu nur den FD-RevKey (den hat bisher nur der FD) und diesen FD-RevKey wird er einfordern, wenn ein aktuellerer Stand vorgeschlagen wird. Wie zum Beispiel die Zahlung der Miete.
Punkt 3 bleibt gleich, weil CP eben nun sicher ist, ich habe einen Hebel den ich setzen kann sobald diese Transaktion nicht mehr aktuell ist, ich muss nur den FD-RevKey einfordern bevor ich einen anderen Stand der Balance als legitim ansehe und somit eine Zahlung als empfangen akzeptiere, er hat schließlich den Vorteil von 144 Blöcken was das Ausgeben vom Output bc1…fd1 angeht, FD muss 144 Blöcke warten.
Punkt 4 ist pretty much the same.
Punkt 5 ist pretty much the same.
Punkt 6 ist von der Ausgangslage gleich, es wurde die Refundtransaktion nicht publiziert und man kann Updates an der Geldverteilung vornehmen und wir zahlen wieder die Miete.
Der Unterschied jetzt im Vergleich zu vorher:
Beide erhalten eine eigene Commit1 Transaktion, die sie als aktuellen Stand akzeptieren und diese unterscheiden sich leicht (nicht in den Beträgen aber in den Scripten hinter den Beträgen)
Also wir wissen, dass FD in der Rückhand immer die Refund…commit0 Transaktion hat und er der einzige ist, der FD-Key und FD-RevKey kennt und somit immer versuchen könnte die ursprünglichen 1 BTC gänzlich für sich zu nehmen, die einzige Bedingung unter der CP nun einen neuen Stand (die Mietzahlung) akzeptieren würde ist folgender, er kriegt von FD den FD-RevKey und kann somit sofort sagen, ok, wenn FD jemals diese Transaktion publiziert und es das neue UTXO bc1…fd1 gibt, dann kann ich die 1 BTC gänzlich für mich nehmen, weil ich 144 Blöcke Vorsprung habe.
(Das ist jetzt nicht alles chronologisch ab diesem Punkt, ich müsste dafür in die Spezifikationen schauen)
Was aber nun beim Erstellen des neuen Standes passiert ist folgendes, FD gibt CP den FD-RevKey, damit dieser weiß, FD hat keinen Grund mehr commit0 zu publizieren, weil er dann ziemlich sicher alles verliert.
Weiters machen sie die 2 unterschiedlichen Transaktionen, die Transaktion die FD halten wird sieht folgendermaßen aus und lässt FD von CP signieren was seinen Multisigteil angeht:
Txid: FD…commit1
–
Input: bc1…2of2 Amount: 1 BTC
Output: bc1…fd2 (Script dahinter FD-Key&&144Blk||FD-RevKey2&&CP-Key) Amount: 0,5 BTC
Output: bc1…cp1 Amount: 0,5 BTC
–
CP hingegen wird folgende Transaktion halten und FD signieren lassen:
Txid: CP…commit1
–
Input: bc1…2of2 Amount: 1 BTC
Output: bc1…cp1 (Script dahinter CP-Key&&144Blk||CP-RevKey2&&FD-Key) 0,5 BTC
Output: bc1…fd2 Amount: 0,5 BTC
–
FD weiß jetzt, dass CP nur eine Transaktion signiert hat in der bc1…fd2 eine einfache Adresse ist, deren FD nicht weggenommen werden können und weiß sobald ein neuer Stand im Raum steht, TV-Kauf muss er um den CP-RevKey bitten, damit er wieder einen Vorsprung von 144 Blöcken hat, wenn CP versuchen sollte diese Transaktion zu publizieren, weil sie besser für ihn ist als der aktuellste Stand (wie auch immer der aussieht).
CP weiß ebenfalls, FD hat nur eine signierte Transaktion von ihm FD…commit1, in der der 2.Output für ihn dieses Mal 0,5BTC sind, die nicht gefährdet sind, alles was er machen muss ist beim nächsten Update der Balances nach dem FD-RevKey2 fragen.
Punkt 7 ist eigentlich in diesem Prozess des Austausches der RevocationKeys erklärt.
Mehr schreibe ich mal nicht dazu, weil ich merke, desto mehr es wird desto besser wären eigentlich wahre Skizzen für so eine Erklärung.
Was jedoch hier in der realistischeren Erklärung im Vergleich zur prinzipiellen oben genauso gilt, sofern es rein kooperativ verläuft gibt es keinen Zeitpunkt zu dem Geld timelocked ist.
Es werden lediglich im Falle, dass einer alleine den Channel schließen will Timelocks auferlegt um der Gegenpartei die Chance zu geben ihn zu bestrafen, falls es nicht der aktuellste Stand ist.
Was jedoch diesen „Mythos“ pusht, dass man Geld irgendwo locken muss um es dann in einem anderen Netzwerk repräsentativ freizuschalten oder sonst was ist, dass viele in der Übergabe der alleinigen Kontrolle über das Geld in die 2-Mann Kontrolle eine Art sehen, dass man gefangen ist und nicht mehr frei handeln kann. Andere pushen die „Sicherheitsmechanismen“ wie eben die Timelocks beim Schließen der Channel (wenn man es alleine macht) als etwas was Geld lockt, das gilt aber nur für einen kurzen Zeitraum, der AB DEM ZEITPUNKT GILT, wenn der Channel zu ist und nicht für den Zeitraum während du ihn nutzt, also ist es nicht wirklich eine Anforderung um im Lightning Network teilzunehmen sondern eher eine Konsequenz davon, dass man das Netzwerk verlässt. Mir ist klar, dass besonders dann mit Punkten wie HTLCs (die als Brücke für channelübergreifende Zahlungen genutzt werden) das Wort „lock“ umso mehr in Verbindung gebracht wird, aber wenn du und ich im privaten Leben über unsere Bitcoin Core Node Transaktionen generieren und sie eben sehr kreativ gestaltet sind, dass wir beide über die Scripte sicher sein können zumindest den anderen zu bestrafen, wenn er versucht zu betrügen und diese BITCOIN TRANSAKTIONEN dann über USB-Sticks regelmäßig austauschen und sie nicht publizieren, dann würden wir doch nie davon reden, dass wir nicht direkt mit Bitcoin verbunden sind, Lightning ist nichts anderes als Bitcoin auf einer anderen Art/Ebene. Lightning ist ein Layer 2 (zweite Schicht, andere Art Bitcoin zu nutzen, wir nutzen nämlich zu jeder Zeit nichts anderes als gültige Signaturen und Bitcoin Transaktionen) und Cardano, BSC oder Coinbase als Custodial sind nicht damit vergleichbar.
Vieles von dem was ich schrieb ist nicht vollständig und die Transaktionen gehören noch angepasst an aktuelle Entwicklungen wie z.B. Dual-Funding, Anchor-Outputs usw.
Dann kommt noch, dass HTLCs und zukünftig PTLCs gar nicht aufgegriffen wurden, aber wenn es in so wenigen Zeilen verständlich erklärt wäre würden andere keine darüber schreiben. Eltoo gar nicht erwähnt usw.
Das ist etwas viel Nitpicking, aber sowas wie Sidechains sind Layer 2s oder was auch immer als L2 verkauft wird ist nicht vergleichbar mit „wahren“ L2s und ruiniert die geniale Ingenieurarbeit die in vertrauensminimierte Methoden gesteckt wurde um Leuten die Möglichkeit zu geben effizienter mit Bitcoin umzugehen usw. Gleiches gilt für wahre L2s auf ETH.
Dazu 2 Tweets.
Hoffe du schaust dir dieses Video hier an 13. Payment Channels and Lightning Network - YouTube , so wie ich dich einschätze wirst du es ziemlich gut verarbeiten können und dann Lightning deutlich besser verstehen als du es eh schon tust und dann dieses „ich bin kein Experte“ runterreden deines Verständnisses sein lassen. Du bringst eine Art zu denken mit, die es dir sehr einfach machen wird dich schnell sehr gut mit dem ganzen auszukennen.
Falls noch Lücken nach dem Video bestehen (wird sicher welche geben) werden die sicher mit dem Buch von Rene usw. gefüllt werden, hab es mal kurz durchgeschaut und das wirkt dort alles wunderbar erklärt und mit tollen grafischen Darstellungen, die meinen Blödsinn da ziemlich alt aussehen lassen.
Als Nachtrag, will das nicht ans Ende editieren, sorry für dieses blöde denglisch, oft blockiert einfach der Versuch ein deutsches Wort für etwas zu finden und dann schreib ich einfach aus Faulheit wie ich es gedacht habe und ich muss sagen, gott sei Dank hab ich aufgehört zu schreiben, jetzt so in der endgültigen Fassung muss ich sagen, dass es echt blöd ist mit reinem Text Transaktionen darzustellen und es wirklich Bilder/Grafiken braucht.