diff --git a/slides-bitcoinlightning-introduction/bitcoin-lightning-intro.md b/slides-bitcoinlightning-introduction/bitcoin-lightning-intro.md
index 8cab411..2b09653 100644
--- a/slides-bitcoinlightning-introduction/bitcoin-lightning-intro.md
+++ b/slides-bitcoinlightning-introduction/bitcoin-lightning-intro.md
@@ -32,7 +32,7 @@ https://lightning.network/
 
 ### Die Idee dahinter - Kanal
 
-* zwei Nutzer erzeugen einen Kanal und legen jeweils einen Betrag an eines der Enden das Kanales
+* zwei Nutzer erzeugen einen Kanal und legen jeweils einen Betrag an eines der Enden das Kanals
 * wenn der Kanal geöffnet ist, können Beträge von der einen Seite zur anderen Seite transferiert werden
 * wird der Kanal geschlossen, bekommen die Nutzer den Betrag ihrer Seite des Kanals gut geschrieben
 
@@ -57,7 +57,7 @@ https://lightning.network/
 * die grundlegende Idee geht auf Satoshi Nakamoto zurück
 * mit der vermehrten Nutzung von Bitcoin wurde das Problem der Skalierbarkeit drängender
 * ab 2016 entstanden erste Implementierungen (lnd, c-lightning, eclair)
-* zur Umsetzung brauchte man das Segregated-Witness-Update (2017)
+* zur effizienten Umsetzung brauchte man das Segregated-Witness-Update (2017)
 * Rusty Russel entwickelte auf Grundlage des Whitepapers einen RFC-Standard für das Lightning Netzwerk
 
 ---
@@ -69,16 +69,53 @@ https://lightning.network/
 * Beta-Status
 * sehr aktive Community
 * im produktiven Einsatz in El Salvador
+* Entwicklungsbedarf beim Routing
+* Pickardt Payments
 
 ---
 <!-- fg=green,bg=black -->
 
-
 ## Aufbau
 
-* wie funktioniert es?
-* Pfade
-* Pickardt Payments
+* Wie funktioniert es? (etwas detailierter)
+
+---
+<!-- fg=green,bg=black -->
+
+### Funktionsweise
+
+* es gibt die genannten Zahlungskanäle (uni- bidirektionale)
+* mit Hilfe des Kanals können sich zwei Knoten durch Benutzung einer 2-2-Multisignatur-Wallet Geldbeträge hin- und herschicken
+* der Kanal wird durch eine Funding-Transaktion geöffnet
+* nach jeder Zahlung wird der aktuelle Zustand in einer Commitment-Transaktion festgehalten
+* schließt eine(r) den Kanal wird eine Settlement-Transaktion veröffentlicht
+* diese speichert den finalen Saldo beider Parteien aus der letzten Commitment-Transaktion in der Bitcoin-Blockchain
+* das Protokoll zur Verwaltung eines Kanals ist mithilfe von HTLCs konstruiert und soll betrügerisches Verhalten bestrafen
+
+---
+<!-- fg=green,bg=black -->
+
+Hashed Timelock Contract (HTLC)
+
+* ist eine Klasse von Transaktionen
+* der Sender muss entweder einen kryptographischen Beweis vorlegen oder bis zu einem bestimmten Datum warten
+* besteht aus zwei Komponenten:
+    * Geheimnis (Secret) - zufällige Zahl (Pre Image) welche gehasht ist
+    * Zeitschloss
+* wer das Pre Image kennt besitzt den kryptographischen Beweis um die Transaktion zu tätigen
+* werden in bidrektionalen Kanälen verwendet
+
+---
+<!-- fg=green,bg=black -->
+
+### Routing
+
+* ermöglicht Zahlungen zwischen beliebigen Knoten, wenn es eine Route gibt
+* Idee des Onion-Routing:
+    * Sender muss zuerst Pfad ermitteln
+    * für jeden Hop können Transaktionen verschachtelt werden
+* Knoten können für die Dienstleistung des Geld weiterleitens eine Gebühr erheben
+* die Gebühr wird über das Gossip-Protokoll dem Netzwerk mitgeteilt
 
 ---
 <!-- fg=green,bg=black -->
@@ -90,20 +127,29 @@ https://lightning.network/
 * Bluewallet
 * Phoenix
 * RaspiBlitz
-* Casanode
+* Casa Node
+* Sphinx
+* Podcast 2.0
 
 ---
 <!-- fg=green,bg=black -->
 
 ## Diskussion
 
-* dezentralität
-* sicherheit
+* Dezentralität
+* Sicherheit
 * Entwicklungsstand
+* Offline-Zahlungen
+* Privatsphäre
 
 ---
 <!-- fg=green,bg=black -->
 
 ## Links
 
-* Lightning White Paper
+* https://lightning.network
+* https://github.com/lightning/bolts
+* https://github.com/fiatjaf/lnurl-rfc
+* https://explorer.acinq.co/
+* https://github.com/rootzoll/raspiblitz
+