diff --git a/20220523/nit-20220523.txt b/20220523/nit-20220523.txt
index ef671f9391a70dcb79c389e14a55c3888acb2ff7..6dbd6b80a4e98ce029edefcc5a08736c023ab0e5 100644
--- a/20220523/nit-20220523.txt
+++ b/20220523/nit-20220523.txt
@@ -59,8 +59,8 @@ Verwendete Technologie: Blockchain
auch bei gesteigerter Rechenleistung.
Konsequenz: Jedes Mining (und damit anteilmäßig jede Transaktion)
- ist dermaßen aufwendig, daß die jeweils aktuell stärksten Rechner
- der Welt dafür 10 Minuten brauchen.
+ ist dermaßen aufwendig, daß alle auf der Welt für das Bitcoin-Mining
+ betriebenen Rechner zusammen dafür 10 Minuten brauchen.
--> Der Ressourcenverbrauch ist systembedingt gleichbleibend hoch.
Konsequenz: Eine Transaktion dauert ungefähr 10 Minuten.
@@ -104,7 +104,7 @@ Verwendete Technologie: Blockchain
- Hardware-Bedarf:
Standard-Rechner sind zu langsam. --> spezielle Rechner
- FPGA (Freely Programmable Gate Arrqay, umprogrammierbare Hardware)
+ FPGA (Freely Programmable Gate Array, umprogrammierbare Hardware)
--> immer noch zu langsam
ASIC (Application-Specific Integrated Circuit, speziell angefertigte Hardware)
--> veralten, danach für nichts anderes einsetzbar
diff --git a/20220530/nit-20220530.txt b/20220530/nit-20220530.txt
new file mode 100644
index 0000000000000000000000000000000000000000..d1bddc40d34f58f0cc1c07f21a08fe71ee9ff75d
--- /dev/null
+++ b/20220530/nit-20220530.txt
@@ -0,0 +1,163 @@
+Aufgabe, 23.05.2022, 16:13:58
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Vergleich des Bitcoin-Systems mit anderen, rein digitalen Systemen
+ - andere Krypto-Währungen
+ (z.B. mit Proof of Stake statt Proof of Work)
+ - GNU Taler
+ (anonym, mit Einbeziehung der Banken)
+ - "Ewiges Logfile"
+ (1990er Jahre, Vorläufer(?) der Blockchain)
+
+Vergleich der Ergebnisse um 17:30 Uhr
+
+Ergebnisse, 23.05.2022, 17:31:53
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ * Umweltfreundlichere Alternativen zu Bitcoin:
+ https://cryptoticker.io/de/5-umweltfreundliche-kryptowahrungen/
+
+ Was kostet der Konsensmechanismus?
+
+ - Cardano: full Proof of Stake
+ Die Sicherheit hängt nicht vom Energieverbrauch ab.
+
+ - Ripple: Beglaubigung der Knoten
+ --> nicht mehr konsequent dezentral
+
+ - Polkadot: Proof of Stake
+
+ - EOS: delegated Proof of Stake
+
+ - IOTA: nicht dezentral
+ (dezentral wäre es mit Proof of Work)
+
+ Proof of Stake: https://en.wikipedia.org/wiki/Proof_of_stake#Energy_consumption
+ ca. 1/1000 des Energieverbrauchs von Proof of Work --> immer noch viel
+
+ Dezentralität: Bei erfolgreichen 51%-Angriff auch bei Bitcoin nicht gewährleistet.
+ Aktuelle Situation: Selbstverpflichtung des 51%-Teilnehmers
+
+ Ethereum: aktuell Proof of Work; Wechsel zu Proof of Stake ist angekündigt
+
+ Bitcoin mit erneuerbaren Energien: löst nur einen Teil des Problems
+ (Entweder: nur überschüsseige Energie nutzen --> mehr ASICs erforderlich.
+ Oder: Energie fehlt anderswo; Hardware-Problem bleibt bestehen.)
+
+ * GNU-Taler:
+
+ o Taxable Anonymous Libre Electronic Reserves
+ -> freie Software für Bezahlsystem in traditionellen Währungen
+ + datenschutzfreundlich wie klasssisches Bargeld,
+ aber für Steuerbehörden nachverfolgbar -> gegen Geldwäsche
+ + Umtausch von Talern zur jeweiligen Landeswährung möglich durch Exchange-Punkte
+ + hoher Energieverbrauch vermieden
+ + keine starken Wertschwankungen durch "Kopplung" an traditionelles Währungssystem
+ -(?) zentrales Netzwerk, hinter welchem regulierte Geschäftsbanken stehen
+ o Münz-Regulation durch Signaturen der Münzen auf RSA-Basis
+
+ Quellen:
+ https://www.heise.de/news/Projekt-GNU-Taler-Das-quelloffene-Bargeld-4892826.html
+ https://nlnet.nl/project/GNUTaler/
+
+ Für mich stellt sich jetzt die Frage, wie genau das mit dem RSA
+ funktioniert. Das habe ich noch nicht verstanden.
+
+ * "Ewiges Logfile"
+
+ Dies ist ein Grundprinzip, das auch der Blockchain zugrundeliegt.
+ Siehe:
+ - https://de.wikipedia.org/wiki/Ewige_Logdatei
+ - http://altlasten.lutz.donnerhacke.de/mitarb/lutz/logfile/idee.html
+ (Das "Ewige Logfile" der IKS Jena scheint nicht mehr in Betrieb zu sein.)
+ - https://web.archive.org/web/20090719011914/http://bothie.sharedaemon.org/logfile/top_frameset.de.html
+ Eine weitere nicht mehr funktionelle Implementation des "Ewigen Logfiles",
+ deren Web-Interface noch besichtigt werden kann.
+
+ * Proof of Space
+
+ Chia Coin (2018)
+ - Einmalige Aufgaben rechnen, auf unbestimmte Zeit speichern.
+ - Wer beweisen kann, eine Aufgabe vorher bereits gelöst zu haben,
+ darf in die Blockchain schreiben.
+ - https://www.chia.net/assets/proof_of_space.pdf
+ https://www.heise.de/-6037645
+ https://de.wikipedia.org/wiki/Proof_of_Space
+ https://en.wikipedia.org/wiki/Proof_of_space
+
+ Wie funktioniert das?
+ - Wie funktioniert die Überprüfung, ob jemand anderer viel Platz investiert hat,
+ ohne selbst genausoviel Platz investieren zu müssen?
+ - Wieso kann man den Platz nicht durch Rechenleistung ersetzen?
+ - Wieso verbraucht dies insgesamt weniger Rechenleistung als der Proof of Work?
+ Vermutung (anhand von proof_of_space.pdf):
+ - Jeder Block der Blockchain enthält eine Zahl, die Verifiable Delay Function (VDF).
+ - Damit der Block gültig wird, benötigen wir einen Datenschnipsel,
+ dessen Hash die VDF ist. --> Wir müssen einen Hash invertieren.
+ - Das ist normalerweise unmöglich. Wir können aber eine riesengroße Tabelle mit
+ Hash-Werten verschiedener Datenschnipsel erstellen und hoffen, daß der gesuchte
+ Hash dabei ist.
+ - Beim Farming erstellt man diese riesengroße Tabelle.
+ Falls die eigene Tabelle den gesuchten Hash enthält, gibt es eine Belohnung.
+ - Sobald der Block eine VDF und den passenden Datenschnipsel enthält, ist er gültig.
+
+ anfänglich geschätzte Speichergröße: 1.1 TiB
+ entspricht 1 Aufgabe alle 468 Tage
+ entspricht 2 Chia Coins
+ aktuelle Gesamtgröße der Sammlung der möglichen Aufgaben
+ mit möglichen Lösungen: 15.9 EiB, dezentral gespeichert
+ (!= Größe der Blockchain)
+
+ Vorteil gegenüber Proof of Work: weniger benötigte Rechenleistung
+ Nachteil gegenüber Proof of Work: mehr benötigter Massenspeicher (Festplatten usw.)
+
+ * Proof of Stake
+
+ - https://de.wikipedia.org/wiki/Proof_of_Stake
+ - Ethereum will von Proof of Work auf Proof of Stake umstellen.
+ Existierende umweltfreundlichere Alternativen zu Bitcoin (siehe oben)
+ nutzen bereits Proof of Stake.
+
+ Quelle: https://cryptowolf.de/proof-of-stake-was-ist-das/
+
+ - "Stärkere Bestrafung
+ Hacker und Betrüger werden bei Proof of Stake deutlich stärker bestraft.
+ Bei Proof of Work gibt es zwar eine Belohnung, wenn alles richtig ist –
+ aber wenn etwas falsch ist, gibt es normalerweise keine Strafe. Bei Proof
+ of Stake verlieren Betrüger Ihre Coins, wenn sie versuchen, falsche
+ Informationen als richtig darzustellen. Nur Besitzer von Coins können
+ beim PoS-Forging mitmachen und müssen diese als Garantie für ihre
+ Ehrlichkeit hinterlegen."
+
+ - Alle Coins von Anfang an vorhanden. Es kommen keine neuen mehr dazu.
+ Wer die Transaktionen überprüft, bekommt als Belohnung die involvierten Gebühren.
+
+ Quelle: https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463
+
+ - Interessante Alternative: "Useful Proof of Work"
+
+ - Proof of Stake erfordert das vorherige Vorhandensein einer Verteilung der Währung
+ (z.B. bei Umstellung von Proof of Work auf Proof of Stake).
+
+ - Proof of Stake = Proof of Work bei einer Überweisung an sich selbst,
+ der um so einfacher wird, je größer die zu "hash"ende Transaktion ist
+ und je länger sie bereits zurückliegt
+ - Die Miteinbeziehung der Zeit ist möglicherweise nicht nötig.
+ - Alternative: gewichteter Zufall. Das System erlaubt gelegentlich dem Inhaber
+ einer bestimmten Münze, die nächste Münze zu prägen.
+ - Vorteil beim Miteinbeziehen der Zeit: attraktiver für "kleine" Teilnehmer,
+ wirkt einer Zentralisierung entgegen
+
+ - Problem: Exponentielles Anwachsen eines einzelnen Stakeholders.
+ - Mögliche Lösung: Sobald man das Geld ausgibt, ist man nicht mehr dominant.
+ - Oder existiert das 51%-Problem bei Proof of Stake nicht?
+ - Löst die Bestrafungsregel das Problem? Wer überprüft das?
+
+ - Beispiele: Ethereum, PPCoin
+
+ * Warum das alles?
+
+ - Proof of Work/Share/Space: notwendig, um eine Blockchain betreiben zu können
+ - Blockchain = dezentral
+ Niemand hat alleinige Kontrolle über die Währung (außer bei 51%-Angriff).
+ --> Das Vorhandensein einer Instanz, der alle gleichermaßen vertrauen, ist unnötig.
+
+ ? Alternativen? GNU Taler?
diff --git a/20220613/nit-20220613.txt b/20220613/nit-20220613.txt
new file mode 100644
index 0000000000000000000000000000000000000000..bfe1a6bc8eab03f98757ab2ccff1763da7149d96
--- /dev/null
+++ b/20220613/nit-20220613.txt
@@ -0,0 +1,180 @@
+Krypto-Währungen, 30.05.2022
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ - Konzept: Irgendetwas ist absichtlich schwierig.
+ "Proof of <irgendwas>"
+
+ - Dadurch, daß man diese schwierige Aufgabe löst, gewinnt man Währungseinheiten.
+ "Gelddrucken ist erlaubt." Aber es ist absichtlich schwierig.
+
+ - Sinn der Sache: Konsens darüber, was gültige Währung ist und was nicht,
+ ohne daß eine zentrale Instanz benötigt würde.
+
+ - Nachteil: Das Lösen der schwierigen Aufgabe (proof of work, proof of space)
+ verbraucht Ressourcen (Rechenzeit, Speicherplatz).
+
+ - Alternative: proof of stake.
+ Dann sind alle Währungseinheiten von Anfang an vorhanden.
+ Mögliches Problem: Exponentielles Anwachsen eines einzelnen Stakeholders
+ Mögliche Lösung: Sobald man das Geld ausgibt, ist man nicht mehr dominant.
+ Bestrafungssystem evtl. möglich
+
+ * Warum das alles?
+
+ - Proof of Work/Share/Space: notwendig, um eine Blockchain betreiben zu können
+ - Blockchain = dezentral
+ Niemand hat alleinige Kontrolle über die Währung (außer bei 51%-Angriff).
+ --> Das Vorhandensein einer Instanz, der alle gleichermaßen vertrauen, ist unnötig.
+
+ - Problem: Das dezentrale System begünstigt verbrecherische Nutzung des Systems
+ ("Geldwäsche", z.B. Erpressungsgelder)
+
+ ? Alternativen? GNU Taler?
+
+ * GNU-Taler:
+
+ o Taxable Anonymous Libre Electronic Reserves
+ -> freie Software für Bezahlsystem in traditionellen Währungen
+ + datenschutzfreundlich wie klasssisches Bargeld,
+ aber für Steuerbehörden nachverfolgbar -> gegen Geldwäsche
+ + Umtausch von Talern zur jeweiligen Landeswährung möglich durch Exchange-Punkte
+ + hoher Energieverbrauch vermieden
+ + keine starken Wertschwankungen durch "Kopplung" an traditionelles Währungssystem
+ -(?) zentrales Netzwerk, hinter welchem regulierte Geschäftsbanken stehen
+ o Münz-Regulation durch Signaturen der Münzen auf RSA-Basis
+
+ Quellen:
+ https://www.heise.de/news/Projekt-GNU-Taler-Das-quelloffene-Bargeld-4892826.html
+ https://nlnet.nl/project/GNUTaler/
+
+ Für mich stellt sich jetzt die Frage, wie genau das mit dem RSA
+ funktioniert. Das habe ich noch nicht verstanden.
+
+GNU-Taler, 13.06.2022, 14:37:43
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Quelle: https://nlnet.nl/project/GNUTaler/
+ - anonym wie Bargeld
+ - erschwert Geldwäsche
+
+Quelle: https://www.heise.de/news/Projekt-GNU-Taler-Das-quelloffene-Bargeld-4892826.html
+ - zentrale Instanzen: Exchange
+ - Nutzer anonym
+ - Händler nachverfolgbar
+
+Funktionsweise:
+
+ - Bei der Nutzung signiert man die "Überweisung" mit einem privaten Schlüssel
+ und schickt sie an die Exchange.
+ - Dieser prüft die Gültigkeit der Überweisung und führt sie aus.
+ - Peer-to-Peer-Zahlungen: noch nicht möglich, aber geplant
+
+Behauptung: Zahlung kann anonym erfolgen; Umtausch in klassische Währung ist nachvollziehbar
+
+ - Umtausch in klassische Währung:
+ geregelt durch die Exchange, typischerweise eine klassische Bank
+
+ - Anonyme Zahlung?
+
+Verfahren: blinde Signaturen
+
+ - Quelle: https://sceweb.sce.uhcl.edu/yang/teaching/csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF
+ "fundamentally new kind of cryptography"
+
+ - Jede Münze hat ein Schlüsselpaar.
+ - Die Exchange kennt diese Schlüsselpaare nicht.
+
+ - Grundidee: Die Exchange unterschreibt etwas, ohne zu wissen, was sie da unterschreibt.
+
+ - Analogie: Unterschrift auf unbekanntem Dokument
+ mittels Durchschlagpapier in verschlossenem Briefumschlag
+
+ - Anwendung auf eine geheime Wahl auf Entfernung,
+ bei der sichergestellt wird, daß jede Stimme gezählt wird
+ --> Trustee (Wahlleiter*in) darf Stimmen zählen,
+ aber nicht wissen, von wem diese jeweils sind.
+
+ - Stimmzettel in anonymem, inneren Umschlag, den man blind unterschreiben kann
+ --> Man kann per Blind-Unterschrift bestätigen,
+ daß der Inhalt des Umschlags für die Wahl zulässig ist.
+ "In diesem Umschlag befindet sich ein gültiger Stimmzettel."
+
+ - Der anonyme, innere Umschlag wird in einem nicht-anonymen, äußeren Umschlag
+ an Trustee versendet.
+ Trustee unterschreibt den inneren Umschlag (und damit blind den Stimmzettel)
+ und sendet diesen in einem neuen äußeren Umschlag zurück.
+ --> Der innere Umschlag wurde nicht geöffnet,
+ dessen Inhalt aber von Trustee unterschrieben.
+ Damit bestätigt Trustee den Willen von Elector, ohne diesen zu kennen.
+
+ - Elector kann den von Trustee unterschriebenen Stimmzettel nun anonym einreichen.
+ --> Sinn der Aktion: Nur Elector darf den inneren Umschlag öffnen.
+
+ - Trustee kann die - anonymen und unterschriebenen - Stimmzettel nun veröffentlichen.
+
+Funktionsweise:
+
+ * Wir haben:
+
+ - ein Schlüsselpaar s (öffentlich), s' (geheim),
+
+ - eine "kommutierende Funktion" c mit Inversem c', die sich "mit der Signatur verträgt",
+ d.h. c'(s'(c(x))) = s'(x) für ein bestimmtes, aber unbekanntes x.
+ --> Wir wählen ein x und und lassen es mit s' signieren.
+ Wir ordnen dem x ein c(x) zu und lassen dieses ebenfalls mit s' signieren.
+ Dann ordnet c' diesem s'(c(x)) wieder die Signatur s'(x) zuordnen.
+
+ * Vorgehensweise
+
+ - Provider (= Elector = Payer) wählt ein zufälliges x
+ und übergibt c(x) an Signer (= Trustee = Bank).
+
+ - Signer unterschreibt c(x) --> s'(c(x)).
+
+ - Provider erzeugt daraus s'(x) = c'(c(s'(x)))
+ --> Damit hat Provider eine Signatur von Signer für x, ohne daß Provider x kennt.
+
+ * Anwendung auf Zahlungssystem
+
+ - "(3) Bank signs note ... and debits payer's account."
+ --> Die Bank (= Signer = Trustee) kennt x also doch???
+
+Quelle: https://en.wikipedia.org/wiki/Blind_signature
+
+ * Vermutung: Spezialfall von homomorpher Verschlüsselung
+
+ - Sei c eine Verschlüsselung und c' eine Entschlüsselung.
+
+ - Wir haben mathematische Botschaften a und b.
+
+ - verschlüsselt: c(a) bzw. c(b)
+
+ - Homomorphe Verschlüsselung bedeutet: c(a+b) = c(a) + c(b)
+ (und/oder entsprechend für andere Rechenarten)
+
+ * Hier: Verschlüsselung ist homomorph zu RSA
+
+ - Nachricht m, RSA-verschlüsselt r(m), wieder entschlüsselt r'(r(m))
+
+ - dazu homomorphe Verschlüsselung c: c'(r(c(m))) = r(m)
+ --> Dies ist nichttrivial!
+
+ - Wie dies für RSA funktioniert:
+ https://en.wikipedia.org/wiki/Blind_signature#Blind_RSA_signatures
+
+ * Fortsetzung: nächste Woche
+
+
+Themen für nächste Woche
+~~~~~~~~~~~~~~~~~~~~~~~~
+Ressourcen sparen durch Software
+ - Wie muß man programmieren, damit die Software
+ möglichst wenig Strom verbraucht?
+ - Wie kann man die in Rechenzentren vorhandene Rechenleistung
+ möglichst effizient nutzen?
+ - Beispiel: virtuelle Rechner, Container, Cloud
+
+Smartphones: Bestandsaufnahme
+ - Wie hoch kann der Anteil an freier Software sein
+ (auf Standard-Smartphones bzw. auf speziellen, freien Smartphones)?
+ - Wieviel digitale Souveränität kann man gewinnen?
+
+Bitte schon mal recherchieren!