Nodesignal-Techboost - E176 - Updates März 2024

Frisch. Sehr gut. Gut. Und der Calsoso auf der anderen Seite. Hi Calsoso. Abend. Hallo. Da ist guten Abend. Offensichtlich sind Calsoso und ich in der gleichen Zeitzone, nur Anthomus nicht. Anthomus ist irgendwo anders. Gut, dann wir haben wieder einen Techboost. Wer von euch kann mir denn mal die Blockzeit sagen, bevor wir hier anfangen? Die 837425. Kann ich bestätigen. Yes, die habe ich auch. Großartig. Dann sind wir da synchron und können hiermit anfangen. Gut, kurzer Hinweis vorab.

Ihr wisst es, wir sind ein Value for Value Podcast. Das heißt, alles was wir hier machen, machen wir quasi in unserer Freizeit und machen das ohne Werbung und ohne irgendwelche fremdgesteuerten Interessen oder so weiter. Wir finanzieren uns quasi nur über eure Spenden. Das heißt, wenn ihr einen kleinen Mehrwert irgendwie aus unserer Arbeit seht, dann würden wir uns über eine kleine Spende freuen.

Das heißt, der größte Teil davon geht wieder in die Bitcoin Community, in Form unserer Bounties zurück und in andere Projekte, die wir in Zukunft vielleicht noch finden werden. Das heißt, wenn ihr uns ein bisschen unterstützen wollt, dann würden wir uns darüber sehr freuen. Gut, dann gehen wir in unsere Agenda für heute rein. Wir haben wieder zwei Hauptthemenpunkte, die wir jetzt eigentlich immer so größtenteils so grob als Struktur hatten. Das sind einmal die Quick Updates.

Das heißt, es gibt Neuerungen, die wir jetzt nicht im Detail besprechen, aber zumindest die, die das ja schon mal mitbekommen haben, da ist was passiert. Und dann gibt es ein paar Hauptthemen, wo wir dann ein bisschen mehr darüber sprechen wollen. Deswegen fangen wir jetzt mal mit den Quick Updates an. Und da können wir mit Google anfangen, die einen Block Explorer, wenn man das denn so bezeichnen mag, bei sich in die Google Suche integriert haben.

Und ja, ob das ist, das jetzt gut, ist das jetzt schlecht? Wie ist eure Meinung dazu? Ja, also wenn man danach sucht, dann ist es eher das Indexen von Bitcoin Adressen. Und ganz klare Empfehlung an alle, die jetzt hier zuhören, nutzt das nicht. Nutzt es auf jeden Fall nicht mit euren eigenen Adressen, weil ja, Google und eure eigenen Transaktionen in Verbindung zu bringen, ist auf jeden Fall eine richtig schlechte Idee.

Aber es zeigt doch ein großes Interesse an dem Thema Bitcoin und das finde ich ist was Gutes. Also ist es gut für Bitcoin? Yes. Es gibt ja so dieses schöne Meme mit dieser einen Antwort, die es auf jede Frage gibt, ob das gut für Bitcoin ist.

Ja, also ich glaube so die generelle Entwicklung und zu sehen, dass ja gerade auch Google, die sich doch stark distanziert haben mit dem Werbeband und dann zwischendurch halt auch, also einfach das Thema so mehr oder weniger gemutet haben, jetzt zumindest aus Firmen Sicht, da ist es schon ein krasses Zeichen, dass die jemanden hinsetzen, der einfach in ihren eigenen Reihen sozusagen an sowas entwickelt.

Also es muss ja irgendjemand intern bauen auf deren Seite und sich dafür bezahlt werden und also der Gedanke ist irgendwie interessant, so würde ich es beschreiben. Ja, also das kann ich auch nur so unterschreiben. Am Ende gibt es genügend andere Optionen, die wir hier im Space schon kennen.

Am besten benutzt ihr natürlich eure eigene Node und habt da dann entsprechend Mempool oder so laufen und könnt dann mit geschützter Privatsphäre dann eure Adressen nachschlagen und selbst wenn ihr keine eigene Node laufen habt, dann setzt euch eine eigene Node auf. Aber dann selbst Mempool.space oder so ist da immer noch die Behauptens, immerhin, dass sie da keine Logs führen.

Ja, also das sollte auf jeden Fall die letzte Wahl sein, aber natürlich, wenn ihr irgendwie Recherche macht und irgendwelche alten Adressen von Satoshi nachschlagen wollt, dann ist das ein valides Mittel. Was man gut machen kann, ist, dass man Mempool.space über die Toradresse aufruft, über die Onion-Adresse und so zumindest dann die IP-Adresse gegenüber Mempool.space verschleiert.

Das heißt, das ist eigentlich immer noch so die beste Variante, wenn man dann wirklich keine eigene Node und keinen eigenen lokalen Mempool hat, wo man das nachgucken kann, dass man das in idealer Weise dann einfach über den Tor-Browser dann die Onion-Adresse aufruft und das dann da macht. Das funktioniert halt auch ganz gut. Ja, auf jeden Fall. Gut, dann soweit so gut zu der neuen Google-Bitcoin-Adress-Suche, wenn man sie denn so bezeichnen kann.

Mal gucken, ob da noch irgendwie noch mehr kommt oder ob es da jetzt bei dem Feature-Set irgendwie bleibt, was die da bisher haben. Wir verlinken euch auf jeden Fall dann mal so ein Bitcoin-Magazin-Artikel, wo noch ein bisschen mehr dazu drinsteht. Dann gab es jetzt, glaube ich, letzte Woche Donnerstag, also kurz vor Ostern, noch eine Neuigkeit.

Da hat der Bitcoin-User oder der Entwickler, ich weiß nicht, Supertestnet, ich weiß nicht, ob er so, also ich kannte ihn vorher nicht, glaube ich, ich habe den Namen vorher schon mal gehört irgendwie, aber sonst war er mir sonst nicht so geläufig. Der hat ein neues Protokoll entwickelt, das nennt sich Hedgehog, wird Hedgehog, ja, wird so ausgesprochen, ne, okay.

Genau, also auf Englisch auf Igel entwickelt, was ein Second Layer für Bitcoin ist, was ganz cool ist, was ziemlich ähnlich wie Lightning ist, aber den Vorteil hat, dass es Offline-Zahlungen zwischen zwei Peers ermöglicht, was ja bei Lightning immer noch das Problem ist, weil die Nodes für Zahlungen oder die Peers immer online müssen, um diese Zahlung zu erhalten. Jo, Hedgehog, was wissen wir denn darüber oder wissen wir davon noch nicht so viel?

Also, ja, also es ist sehr spannend, aber auch sehr frisch. Also, ne, sonderlich viel wissen wir da noch nicht. Ja, also eben, dass es asynchron ist, ist auf jeden Fall ein riesen Vorteil gegenüber Lightning.

Also, natürlich, so, man braucht immer noch einen Kanal zwischen den zwei Parteien und der Sender muss entsprechend auch online sein, aber der Empfänger muss nicht online sein und das ist gerade für Personen, die Spenden empfangen wollen oder sonstige Zahlungen empfangen wollen, ein riesen Vorteil, gerade wenn man nicht die Möglichkeiten hat, einen eigenen Server laufen zu haben oder eben entsprechend eine eigene Node zu Hause, ist das ein riesen Vorteil auf jeden Fall.

Ich weiß nicht genau, also eben, wie gesagt, viele Informationen gibt es da noch nicht genau, wie das technisch gelöst wird. Es gibt da einige Schlagwörter, die da verwendet werden, wie "revocable connectors", aber genau, wie das alles hinter den Kulissen abläuft, das werden wir vermutlich dann noch in den nächsten Monaten erfahren, wenn das etwas mehr diskutiert wird.

Ja, aber grundsätzlich soll es deutlich weniger Komplexität haben im Gegensatz zu Lightning und eben sonst die gleichen Vorteile von Lightning bieten.

Also, dass man auch entsprechend Bitcoin in einer Multisig-Transaktion oder auf einer Multisig-Adresse parkt zwischen den zwei Nutzern und dass es auch entsprechend so eine Justice-Transaction gibt, wie man das auch bei Lightning kennt, dass wenn eine Partei dann einen falschen Kanalzustand veröffentlicht, dann kann der andere Partner dann entsprechend diese widerlegen und die gesamten Coins einstreichen.

Hier ist dann die Rede von ein paar Blöcken, die der Empfängerzeit hat oder der andere Partnerzeit hat. Das scheint mir etwas kurz zu sein, wenn es gerade darum geht, dass man ja auch offline sein kann oder dass der Vorteil ist. Deswegen kann ich mir vorstellen, dass da mehr Blöcke sinnvoller wären. Aber wie gesagt, es ist alles noch in den Kinderschuhen und es scheint auch noch keine wirkliche Implementierung hiervon zu geben.

Ich fand, dass er das ja in Form eines Videos veröffentlicht und dann mal so einen Showcase gezeigt hat. Er hat parallel zwei Kanalpartner gezeigt, Alice und Bob, und wie die sich dann Zahlungen hin und her geschickt hat. Für mich wirkte das so ein bisschen, ohne ihm jetzt vielleicht zu nahe zu treten, ich kann das nicht beurteilen, für mich wirkte es so witzigerweise so, oh mein Gott, ich habe hier gerade was voll Cooles entwickelt und das funktioniert ja sogar tatsächlich.

Ich muss davon sofort ein Video machen und das veröffentlichen. Natürlich jetzt nicht so hysterisch, aber schon, dass das irgendwie noch, wie du schon sagst, sehr, sehr frisch ist und dadurch halt es noch kein GitHub-Repo in dem Sinne gibt, wo dann wirklich noch mehr dazu steht.

Es gibt zwar einen Eintrag von ihm auf GitHub, aber das war eher dann so ein Use Case, was man mit diesen Zahlungskanälen dann prinzipiell dann machen könnte dann oder eine Idee für eine Implementierung eher dafür, aber jetzt nicht, wie diese Technik selber funktioniert. Ja, ich meine der Kalle, ein Freund der Sendung hier, der auch in dem Bereich definitiv deutlich mehr Ahnung hat, als wir alle zusammen, wenn ich das so sagen darf. Das darfst du. Das musst du sogar.

Der scheint auf jeden Fall ganz angetan von der Idee gewesen zu sein, deswegen ja, das ist schon mal ein erstes Siegel, würde ich mal sagen. Wenn das funktioniert, ist das auf jeden Fall, klingt das auf jeden Fall sehr, sehr cool. Das lässt sich auf jeden Fall so unterschreiben. Aber ja, gucken wir mal, was die Zukunft so bringt.

Krass, also ich hatte es nicht auf meiner Bingo-Karte, dass wir das Lightning-Netzwerk nochmal komplett über den Haufen werfen und mit einer neuen Implementierung in der Form. Also so wirkt es für mich, wenn es das sein soll. Ich bin mir nicht sicher, ob das wirklich für ein Use Case als adäquates Konkurrenzprodukt zu Lightning darstellen soll.

Das klang eher so, weil ich kann mich nicht daran erinnern, dass es da irgendwas mit Routing oder solche Sachen daran teil waren, also dass man darüber Zahlungen dann halt über mehrere Peers dann halt routen kann, wie es bei Lightning ist. Das klang für mich eher so, als wäre es so wirklich ein Zahlungskanal zwischen zwei Leuten, die halt im Gegensatz zu Lightning dann halt asynchron sind.

Also dass das der Hauptunterschied ist und jetzt nicht, dass das jetzt, wir schicken jetzt hier eine Zahlung von einer Seite des Netzwerks zum anderen, sondern wirklich dieser Peer-to-Peer-Ansatz, dass das wirklich dann asynchron funktioniert. So wirkte das auf mich. Ja, also das kann ich auch so bestätigen. Am Ende gehe ich schon davon aus, dass es auch möglich wäre, dann auch Routing zu machen, wenn allerdings dann alle online sind.

Also es geht natürlich nicht, wenn einzelne Peers offline sind. Das heißt, also natürlich wäre es dann deutlich schwieriger, so ein funktionierendes Netzwerk aufzubauen, weil man dann eben deutlich schwieriger Routen findet, wenn immer wieder Leute offline sind.

Allerdings könnte es auch sein, dass eben Lightning und Hedgehog entsprechend irgendwie auch kombinierbar sind in gewissem Maße, dass man eventuell irgendwie so On- und Offboarding-Ramps hat von Lightning auf Hedgehog, wenn man oder ich weiß es nicht, also wie genau da die Möglichkeiten sich auftun.

Aber gerade wenn es eben darum geht, ich will irgendeiner Organisation oder eine Einzelperson regelmäßig so Spenden senden, dann würde es Sinn machen, wenn ich mit denen einen Kanal aufmache und kann denen immer wieder Sets schicken, einmal die Woche, einmal im Monat, wie auch immer. Und die Person muss nicht online sein. Das wäre auf jeden Fall ein Use Case, ob das dann eben, also wie gesagt, gab es da keinen Hinweis zu Routing oder sonstigen zusätzlichen Netzwerkeigenschaften.

Okay, das ordnet das nochmal ein bisschen ein. Ja, sehr gut. Wie gesagt, wir gucken einfach mal, was jetzt da in den nächsten Wochen, Monaten, Jahren dann noch kommt, wie da jetzt dann, ob da der Momentum dann da ist und da jetzt viele Leute drauf springen. Bei ARK war es ja am Anfang ja auch ziemlich gehypt und dann ist es irgendwie, zumindest von meinem Gefühl, relativ ruhig darum geworden jetzt letztes Jahr.

Aber vielleicht kriegt man das auch einfach als Nicht-Entwickler weniger mit, wie viel da im Hintergrund wirklich passiert bei der Protokoll-Weiterentwicklung und solchen Dingen. Deswegen, lassen Sie uns einfach mal schauen, wenn das wieder irgendwie bei uns in die periphere hochgespült wird und dann greifen wir es im Zweifelsfall dann nochmal auf, wenn da was Neues zukommt. Gut, dann der nächste Punkt, den wir bei uns auf der Liste haben, ist eigentlich nur eine Randbemerkung.

Da hat eine Firma, ein Unternehmen, ich weiß es jetzt gar nicht so genau, angekündigt, einen Open Source Secure Chip vorzustellen. Und zwar jetzt nächste Woche in Nürnberg auf der Embedded World 2024, was aus meiner Sicht eine Konferenz für so Embedded Computing, Embedded Chips, also quasi so integrierte Schaltkreise, also solche Sachen, wo solche Dinge vorgestellt werden, wo quasi Chips und Platinen und all so ein ganzer Kram dann wahrscheinlich heiß besprochen wird.

Und da soll so ein Open Source Secure Element vorgestellt werden, was bemerkenswert ist, weil alle Secure Elemente, die so in Hardwarewallets bisher verwendet wurden, waren Closed Source. Da wusste man halt also einfach nicht, wie funktioniert der Quellcode dahinter oder was macht der Quellcode wirklich in diesen Secure Elementen.

Und das kam bei Twitter rein, das ist Tropic Square, also der Kanal heißt Tropic Square und die haben nur so ein bisschen geteased, dass sie eben auf der Konferenz sind und haben dann ein Bild gepostet von wegen "Do not trust this Chip". Ich finde ja die Message schon ganz cool. "Vertraut uns nicht" oder irgendwie, sie haben geschrieben "Kommt zu uns an den Stand, aber vertraut nicht, was wir euch erzählen". "Don't trust Verify", richtig groß geschrieben. Wäre ja eine coole Entwicklung.

Ich hatte das letztens irgendwo gehört, dass es da irgendwie noch nicht so richtig eine Lösung für gibt, dass dieser Teil von Hardwarewallets dann eben auch auditierbar wird. Wäre ja schön, wenn das funktioniert. Und Nürnberg, ich musste tatsächlich selber gerade noch googeln, ist Nürnberg tatsächlich, ist die internationale Schreibweise. Ja, richtig.

Deswegen hatte ich auch nochmal nachgedacht, das ist auch doch, weil jetzt hier bei uns das Dokument mit reingeschrieben ist, dass es wirklich Nürnberg ist, also es ist hier in Deutschland. Und wie gesagt, vom 9. bis zum 11. April, also nächste Woche prinzipiell, geht das dann los.

Das heißt, vielleicht können wir da wirklich jetzt dann, wenn da dann was veröffentlicht wurde im nächsten Techbooster, den wir jetzt dann im Mai aufnehmen, dann da auch nochmal ein Update zu geben, dass wir da gucken, was dann da wirklich vorgestellt wurde, ob das signifikant was Neues ist oder ob das irgendwie jetzt dann doch nur eine Luftnummer war oder sein wird. Wir wissen es halt einfach noch nicht. Aber zumindest kommt da scheinbar irgendwas. Anthemus, hast du noch was dazu?

Nee, eigentlich wurde alles gesagt. Ich hatte zufälligerweise heute auf Twitter einen Post gesehen, ich habe mir das jetzt gerade entfallen, von wem der war.

Aber es war von einem Core Contributor auch, der einen kurzen Thread über Secure Elements auch geschrieben hatte und grundsätzlich auch betont hatte, dass eben in vielen Umgebungen Secure Element gar nicht notwendig ist, zum Beispiel auf Linux-Rechnern, wo man eben auch die gesamte Festplatte verschlüsseln kann, aber entsprechend halt da ein sehr starkes Passwort haben muss, damit das eben langfristig sicher ist.

Gerade auf Geräten, wo man eben mit einem Pin auskommen möchte, wie zum Beispiel auf einem Handy, ist eben so ein Secure Element wichtig, weil es eben ermöglicht, dass man so ein Rate Limiting einstellt. Das heißt also, dass man nur zehnmal ein Passwort eingeben kann oder so ein Pin eingeben kann und entsprechend so ein Brute Forcing dann entgegenwirkt.

Und entsprechend kennt man das auch dann von Hardware Wallets, dass man dann einen Pin hat, um sich da einzuloggen und dafür braucht man dann eben so ein Secure Element. Und eben die haben alle NDAs unterschrieben, dass die eben diese Chips verwenden dürfen und entsprechend Einsicht bekommen, wie die funktionieren.

Aber leider gibt es da, wie schon erwähnt, keine Open Source Variante und das ist sehr kontra der gesamten Bewegung hier in Bitcoin und da würden wir natürlich gerne Alternativen sehen und das ist hoffnungsvoll. Aber auch hier wieder könnte ein langer Weg sein, bis wir das tatsächlich dann in der Produktion sehen.

Ja, das ist ein gutes Stichwort, weil ganz im Gegensatz dazu hat jetzt die Phoenix oder Assang, die Firma, die hinter der bekannten Phoenix Wallets steht, was Neues vorgestellt, aber schon funktioniert und zwar eine kleine Library, die nennt sich Phoenix ID, was im Endeffekt die Phoenix Wallet als Implementierung, als API-Schnittstelle oder als Schnittstelle mit APIs für Entwickler ist, die man auf einem Server laufen lassen kann.

Was bedeutet, man nimmt diese kleine Software, schmeißt sie auf einen Server, quasi führt sie aus oder ruft sie dann extern mit seiner eigenen Software auf und bekommt so im Endeffekt dann die Experience, die man auch hat, wenn man die Phoenix Wallet selber benutzt.

Das heißt, man muss sich über dieses ganze Thema Kanalmanagement, Liquidität und sowas alles mit in seiner Applikation, die man mit Lightning anbinden will, nicht weiter kümmern, sondern das macht alles diese Library, die dann halt an die Phoenix Node angebunden ist. Und das ist in dem Sofern ganz cool, dass das auch für Entwickler jetzt eine gute Möglichkeit ist, schneller Lightning Services oder Lightning Anwendungen schreiben zu können. So habe ich zumindest verstanden.

Genau, dass sie für Unternehmen, also das ist gerade für Unternehmen oder Dienstleister praktisch ist, weil sie, wie du schon sagst, wir alle kennen oder viele kennen die Phoenix Wallet als Endnutzer. Aber wenn du Services und Dienstleistungen anbietest, dann hast du ja ganz andere Probleme. Du musst Liquidität beschaffen, die Kanäle müssen immer gefüllt sein, du musst empfangen können und dafür bieten sie dann auch direkt Services an, dass du dich darum nicht mehr kümmern musst.

Das läuft alles auf dem Server. Und ist non-custodial, also deine Funds sind in deiner Hand. Deswegen coole Sache. Du hast auch schon gesagt, für Entwickler auch gebaut, weil dann eben schnellere Lösungen entwickelt werden können. Frage in die Runde.

Ist es, also mein erster Gedanke, als ich das gelesen habe, war, dass man das ja dann ganz entspannt integrieren könnte auf einer Node, also zum Beispiel jetzt auf einer MyNote oder so, hätte man dann entsprechend die App da laufen und könnte dann vom Handy aus sich damit verbinden und hätte entsprechend nicht die gesamte Rechenleistung auf dem Handy, um da die Node dann entsprechend zu betreiben. Wäre das ein sinnvoller Ansatz?

Oder das war in dem Artikel zumindest nicht so benannt, der Use Case. Ja, du müsstest ja, weil meines Erachtens müssten ja dann die Anwendungen, die dann lokal auf deiner Node laufen, müssten ja dann eigentlich so geschrieben werden, dass du die im Endeffekt dann als Quelle, diese Library verwendet für alles. Und da frage ich mich so ein bisschen, wofür benutzt du dann deine eigene Bitcoin-Node dann überhaupt noch?

Weil ich glaube, diese Library greift ja dann auf die Lightning-Node von Assange zu, die wiederum dann eine eigene Bitcoin-Node halt hat. Das heißt, die Verifizierung von diesen Kanälen machst du nicht mehr mit der eigenen Node. Deswegen ist ein bisschen die Frage, was man damit genauer dann jetzt dann machen möchte. Also in dem Kontext jetzt wirklich dann, wenn man eine eigene Node bei sich betreibt.

Okay, das heißt, man könnte das gar nicht verknüpfen dann mit der eigenen Node, die man da laufen hat. Also mir würde es nur darum gehen, dass man halt eben die ganzen Vorteile von Channel Management und so weiter bekommt von Phoenix, aber eben lokal laufend einfach nur auf dem eigenen Server quasi der Node, die man laufen hat. Das ist halt im Endeffekt dann ja die Frage.

Ich habe es halt wirklich so verstanden, dass es ja im Endeffekt so eine Entwicklungsbibliothek halt ist, die halt an die Assange nun angebunden ist und du kannst halt relativ simpel dann Funktionen dann von dieser Schnittstelle oder Library aufführen.

Wenn du sagst jetzt hier "Create Channel", dass der dann halt möglich mit zwei Klicks oder zwei Funktionen, die dann in deinem Code implementiert werden, dann automatisch über die Schnittstelle dann direkt einen Kanal dann bei Assange aufmacht und das du so dann mit ein paar Zahlen Code im Endeffekt Liquidität dann in deine Anwendung reinbekommst, die du dann für was anderes benutzen kannst.

Deswegen bin ich mir nicht so genau sicher, ob das dann jetzt wirklich in diesem Kontext, wir haben Standardsoftware wie jetzt hier ThunderHub, Rides of Lightning und solche Sachen, dass man die dann darauf anbinden kann.

Deswegen vielleicht ja, dass man dann halt vielleicht eher, ich könnte es mir eher vorstellen, dass man sagt, dass die Node-Anbieter sagen, am Anfang, wenn man sie einrichtet, okay, du hast die Auswahl hier, du kannst dir hier eine Bitcoin Fullnote konfigurieren und du kannst dir Lightning-Node-Implementierung auswählen.

Du hast da LND, du hast da C-Lightning, aber du kannst auch die teuerste, aber auf der gleichzeitig die auch entspannteste Variante von Phoenix nehmen und dann würden die im Endeffekt dann quasi in der Node-Implementierung selber dann halt diese Library verwenden, um dir dann halt quasi Channel-Kapazitäten zur Verfügung zu stellen. Das Problem ist natürlich nur, was du dann dabei hast.

Du hast ja keine richtige Lightning-Node im klassischen Sinne, dass du einen Public Key bekommst, der extern verfügbar ist. Das ist ja immer ein bisschen das Problem, was du bei Phoenix hast, was jetzt im Gegensatz zu einer wirklichen LND- oder C-Lightning-Node ja dann schon hast, dass du wirklich, wenn du auf, weiß ich nicht, AmboSpot.Space oder N1ML, ne, 1, diese andere Lightning Explorer, den es da noch gibt, dass du ja wirklich dann nach dir suchen kannst und dich da auch findest.

Bei Phoenix wirst du das halt nicht machen können, weil das halt kein öffentlicher Kanal ist, der da existiert. Da muss man halt so ein bisschen überlegen, ob das, klar, das würde funktionieren, aber wirklich für so eine Voll-Voll-Convenience-Lösung könnte ich mir das gut vorstellen, dass man das da dann wirklich dann dafür anbietet oder verwendet. Das macht Sinn. Ja, ja, verstehe. Aber ja, ist auf jeden Fall, denke ich mal, es hat einen Use Case.

Vielleicht jetzt auch wieder mehr für die Entwickler als jetzt dann für den Endnutzer dann. Ja, denke ich auch. Gut, gehen wir auch wieder zu einem eher technischen Thema, beziehungsweise eher einem Entwicklerthema. Da hat der liebe Kalle, den hattest du, Antomas, eben auch schon mal erwähnt, der hat wieder im Kontext von Cashu wieder was Neues rausgehauen oder die haben wieder einen Proof of Concept gebaut, dass da wieder irgendwas funktioniert. Ich versuch's mal zusammen zu bekommen.

Die haben Multinatural Payments, also quasi viele Nüsse und die natürlich sind, also Multinatural. Das ist ein bisschen so der Witz mit Cashu, da ist ja alles im Kontext von irgendwelchen Nüssen oder Nussanalogien. Und was die damit machen wollen ist, ich glaube, da muss man, oder das macht, kann einer von euch das machen, da ein bisschen ausführen, wie das funktioniert mit den unterschiedlichen Mints und den Leitungszahlungen?

Genau, das Problem oder das Risiko, was wir noch letztes Mal in der Folge diskutiert hatten, war ja, dass die Mint mit meinen Funds abhauen kann. Und das ist eines der Sachen, die zumindest optimiert wird durch dieses Protokoll oder diesen Entwurf. Und zwar geht es hier darum, dass man, wenn man Funds in seiner Nusswallet hält, in seiner Cashwallet hält, dass man die bei mehreren Mints verteilt liegen haben kann.

Das heißt, dass nicht mehr nur eine Mint mit meinen Funds abhauen kann, sondern mehrere. Im besten Fall aber eben nicht, weil ich das Risiko streue und weil ich die gegeneinander auch prüfen kann. Kalle hat hier in seinem Twitter-Post, wo er das vorgestellt hat, nochmal so ein bisschen ausgeholt, was für Vorteile das hat und das bringt eben dem Nutzer die Sicherheit, dass er zum einen nicht auf einen vertrauen muss und dass man auch auditieren kann.

Und ich glaube, einer der ersten Punkte, also damit eröffnet er eigentlich, dass es bisher ein Riesenproblem war, wenn du nicht genug Funds in deinem E-Cash-Wallet hast, dann bezahlen willst, dann musst du immer noch, ich muss mal kurz schauen, dann brauchst du immer noch, dann ist es super kompliziert. Ich glaube genau, das Hauptproblem ist wirklich, du kannst ja in einer Cashwallet mehrere E-Cash von unterschiedlichen Mints haben.

Und das ist glaube ich aktuell das Problem, dass man, wenn man eine Lightning, also wenn man quasi so einen Swapout über Lightning dann halt quasi woanders hin machen möchte, dass das aktuellen immer nur aus einer Mintquelle geht. Also man kann keine Cash-Tokens von unterschiedlichen Mints zusammenfassen, um damit eine Lightning-Zahlung zu bezahlen, die halt den Bestand von einer Mint, der in deiner Wallet liegt, übersteigt.

Und das ist glaube ich genau der Use-Case, den er jetzt hier anführt, dass man das halt machen kann, dass man halt sich aus mehreren Mintquellen bedient und da aggregiert dann zusammen dann eine Lightning-Zahlung dann bezahlen zu können. Genau, aus mehreren Mintquellen viele kleine Zahlungen zu einer großen Bündel, so beschreibt das hier eben auch.

Und das ergänzt natürlich nochmal an Privatsphäre, also das bringt nochmal deutlich mehr Privatsphäre, als wenn ich nur bei einer Mint bin, was ja so schon ein riesen Vorteil von Cashu ist, dass die Mint nicht weiß, wem die Token gehören. Wenn ich das aber nochmal verteilen kann auf mehrere Mints, dann wird es halt nochmal mehr random, finde ich eine gute Lösung. Ja, steckt viel Potenzial drin, glaube ich.

Also so wie ich das verstanden habe, war das eben vorher auch möglich, allerdings musste dann, wenn man eine größere Transaktion machen wollte, als man in einer einzigen Mint hatte, mussten quasi vorab so Transferzahlungen zwischen den Mints stattfinden, bevor man dann tatsächlich die Lightning-Zahlung machen musste. Und wenn dann die Lightning-Zahlung fehlschlägt, dann sind alle anderen Zahlungen vorher trotzdem passiert. Und das kann man dann entsprechend nicht mehr rückgängig machen.

Also kann man schon, aber dann wieder mit neuen Transaktionen, also die waren nicht voneinander abhängig. Und hier ist jetzt eben der riesen Vorteil, dass das alles integriert wird in eine Zahlung. Das heißt, wenn die Zahlung dann entsprechend im leitenden Netzwerk nicht durchgeht, dann bewegen sich auch keine eCash-Token.

Und hier mit dieser Lösung fällt eben die Notwendigkeit für Coin Control, um zu gucken, wo liegen jetzt welche und okay, ich muss gucken, wie viele liegen auf dieser Mint und wie hoch sind die Zahlungen, die ich ungefähr machen will. Das fällt alles weg und man kann die Wallets deutlich simplifizieren und einfach sagen, mir wird einfach nur ein Balance angezeigt und vielleicht irgendwo in den Advanced-Settings kann man dann sehen, wo die tatsächlich liegen.

Aber so als Benutzeroberfläche ist es alles super simpel und man zahlt einfach nur Lightning-Invoice und solange man insgesamt genug Sets hat oder eCash-Token, dann entsprechend geht die Zahlung durch und das kann alles irgendwie so obfuscated werden. Und das ist auf jeden Fall ein riesen UI-Sprung und auch ein riesen Durchbruch für die Benutzerfreundlichkeit. Ja, da ist das Stichwort wieder Atomarität, also die Zahlung ist atomar.

Entweder sie funktioniert vollständig oder sie funktioniert gar nicht, quasi so wie ja dann auch in Routing im Lightning-Netzwerk genauso ist, dass es nur zwei Zustände geben kann. Entweder es ist erfolgreich oder es schlägt fehl und alles, was in diesem Prozess passiert ist, wird wieder zurückgerollt quasi in den Zustand, wie es halt dann vor der Zahlung war. Das heißt, diese Zahlung hat effektiv nicht stattgefunden. Ja, sehr gut.

Also ich finde es immer wieder erstaunlich, jetzt auch nochmal, um das noch ein bisschen zu kommentieren, wie krass, wie viele auch so irgendwie gefühlt im Wochenrhythmus bei Cashu irgendwelche coolen neuen Erfindungen oder so Ideen halt rausfallen, die da irgendwie, wie man Dinge anders und besser und effektiver bauen kann.

Also ich weiß nicht, ob das jetzt irgendwie so ein Cashu-Bubble ist, ein bisschen, wo man drin ist, weil man halt irgendwie, Kalle, jetzt natürlich auch im deutschen Space sehr, sag ich mal, sprachfreudig oder sowas ist, aber ich habe das Gefühl, da passiert wesentlich mehr als jetzt irgendwie in anderen Projekten, also zumindest jetzt in den letzten Monaten. Also da ist richtig Drive drin, von meiner Perspektive.

Auf jeden Fall. Es ist, ich meine, es ist auch immer noch jetzt, sagen wir mal, im Vergleich zum Lightning-Ökosystem immer noch ein junges Projekt und sehr agil und da wird noch sehr viel so aufgedeckt und neue Ideen, die da dann entwickelt werden.

Also dann im Gegensatz dazu ist halt Lightning schon deutlich größer, da sind größere Unternehmen, die dann irgendwie ihre Entwicklungsabteilungen schon drin haben, da geht alles so etwas mehr so den geordneteren Wegen und ich meine, bei Bitcoin ist natürlich das dann andere Extrem dann schon sehr, sehr starr, aber so wollen wir es auch haben. Deswegen ist es auch schön, da diese Möglichkeiten zu haben, in diesen kleinen anderen zusätzlichen Layern.

Wobei man natürlich dagegenhalten musste vom Grundprinzip ist, Xiaomi und E-Cash sind älter als Lightning und Bitcoin zusammen. Also wenn man das mal überlegt, das ist ja was aus den 90ern, also das ist ja schon vom Konzept her schon wesentlich älter als die anderen beiden Sachen. Das ist richtig, klar, ja, ja, aber ich meine, entsprechend war dann auch sehr lange Ruhe um das Projekt und dann natürlich jetzt aufbauend auf Bitcoin und dann jetzt auch mit Lightning.

Also das ist ja wirklich die Integration in Lightning, also dieses Seamless, dass die wirklich alles dann immer gucken, dass es wirklich, dass man hat einfach eine Ausgangsschnittstelle und die ist eigentlich immer Lightning und dass man da halt immer wieder diesen Fluchtpunkt raus hat, das ist schon irgendwie, oder Fluchtpunkt ist vielleicht der falsche Begriff, aber ihr wisst, was ich meine, dass man diesen Weg zurück, dann halt auch wieder ins normale Bitcoin-Netzwerk zurück.

Dann nächster Punkt, wir haben gerade über das Bitcoin-Netzwerk gesprochen, jetzt kehren wir wieder ein bisschen auf den Mainlayer zurück, wir haben jetzt viel über die höheren Ebenen gesprochen, ganz viel und jetzt sprechen wir mal ein bisschen wieder über eine Wallet, die primär oder eigentlich ausschließlich das Bitcoin Mainnet bedient, beziehungsweise Bitcoin als Hauptlayer bedient und das ist die Sparrow Wallet und ich glaube den Punkt Kalso, den hattest du mit reingebracht, ne?

Weiß nicht, möchtest du was dazu sagen? Genau, ich hatte das bei uns in die Gruppe gepostet, kurz nachdem wir die letzte Folge aufgenommen haben und wir haben in den Folgen davor oder generell schon öfter darüber gesprochen, was man beachten muss, wenn man Software runterlädt aus dem Netz und um das zu verifizieren, dass es wirklich von dem Entwickler stammt oder dass diese zwei Sachen, zum einen, dass es wirklich von dem Entwickler signiert wurde und dass das Paket, was ich

runterlade auf dem Weg zu mir auf meinen Rechner nicht verändert wurde, dass da nicht irgendwelche Schadsoftware integriert wurde und Sparrow hat jetzt eben verkündet, dass sie mit dem neuesten Release gleich integriert haben, dass man ja PGP Download File Verifizierung durchführen kann, also die Verschlüsselung, die ihr nutzt, wenn ihr bisher vielleicht schon irgendwelche, weiß nicht, auf Sparrow Seite hatten wir das beim letzten Mal diskutiert,

da gab es direkt unter dem Download gibt es eine Anleitung, was man beachten muss oder wie man es überprüfen kann, aber eben bisher noch mit einer Drittsoftware, die man dafür nutzt oder Betriebssystem integrierte Programme, die das unterstützen und jetzt ist es als ein Teil der Software integriert und man kann den Download gleich selbst verifizieren und genau, da wird der Hash überprüft, man sieht, dass es signiert wurde von dem Autor, Greg

Sparrow und bekommt eine kurze Verifizierung angezeigt. Finde ich eine coole Lösung, das direkt ins Programm mit einzubauen. Ja, also macht es auf jeden Fall für, also convenient oder macht es halt einfacher, also auch für Laien besser zu benutzbar und ich glaube viele Leute schreckt, dass dieses, man soll alle Bitcoin Wallets, wenn man sie runterlädt, auch vorher verifizieren, weil es da wirklich ja dann auch um Geld geht, dass man das auf jeden Fall immer machen sollte.

Ich glaube viele Leute, wenn man Software irgendwo runterlädt oder sowas, wird einem diese Sachen ja bei normaler Software nicht bereitgestellt, dass man da irgendwas verifizieren kann, aber gerade im Bitcoin Wallet Umfeld ist das ja schon wichtig und deswegen sind diese Berührungspunkte wahrscheinlich da auch schon schwierig und wenn man da halt dann einen einfachen Zugang zu bekommt als jemand, der das nicht so gewohnt ist, ist das glaube ich ein guter Punkt.

Ich meine BISC hat das auch früher oder hat das auch immer schon so gemacht, werden wir gleich auch noch mal darüber reden über BISC selber, weil es auch jetzt ein großes Update gab, aber die haben das halt auch immer schon so gemacht, dass man halt über die Software selber so einen Update halt hatte und der hat eigentlich auch schon automatisch dann die Signaturen und die ganzen Sachen immer runtergeladen, um das dann, das da runtergeladene

File wirklich dann auch schon zu verifizieren und deswegen ist es auf jeden Fall eine gute Entwicklung. Du sprichst einen guten Punkt an.

Gerade bei Sparrow war es so, dass ich mich lange, dass es mich lange davon abgehalten hat jetzt noch eine Software runterzuladen, weil ich eigentlich mal mein UTXO-Management machen wollte Anfang des Jahres und dann immer wieder rausgeschoben habe, weil ich dachte, oh jetzt musst du dir wieder diverse YouTube-Videos angucken oder Anleitungen raussuchen, wie man das dann macht, dass man überprüft, dass die Software wirklich von dem Entwickler signiert

wurde und dass das Paket nicht verändert wurde und hatte irgendwie diesen Hustle immer vor mir hergeschoben. Das hat mich davon abgehalten, bis wir in dieser einen Folge, ich glaube es war die vorletzte, dann besprochen hatten, dass das eben direkt auf der Seite nochmal in ein paar wenigen Schritten erklärt stand. Danach bin ich drauf gegangen und habe es einfach getestet und jetzt habe ich es mal probiert und das ist super.

Also es ist ja eigentlich nicht schwierig, es sind ja wirklich eigentlich nur so, man muss halt den PGP-Key runterladen und dann muss man im Effekt zwei Terminal-Aufrufe machen, wo man einmal die prüft und einmal dann halt die Signatur überprüft und das war es eigentlich. Aber natürlich ist das schon, oh Gott, ich muss die Konsole aufmachen, für super viele Leute sagen so, nee, auf gar keinen Fall, ich schalte jetzt hier aus und laufe weg. Verstehe ich, absolut.

Man muss dazu sagen, das ist natürlich hier so ein bisschen so ein Huhn-und-Ei-Problem, also man braucht ja einmal die Sparrow-Software, um diesen Verifikationsprozess durchzuführen und muss entsprechend einmal die Software dann am Anfang selbst verifiziert haben. Guter Punkt. Sonst macht das Ganze keinen Sinn.

Das heißt einmal muss man das natürlich gemacht haben, das kann aber natürlich jetzt vielleicht auch jemand für einen aufsetzen, wenn man jemanden in seinem Umfeld hat, der technisch da stabiler unterwegs ist. Aber wenn man dann einmal eine Instanz hat, der man vertraut, dann kann man dieses weitere Update dann entsprechend hiermit verifizieren. Ein weiterer Punkt, der auch super interessant ist, das ist nicht nur auf Sparrow limitiert.

Entsprechend kann man auch andere Software mit Sparrow dann auch verifizieren, wenn man Sparrow vertraut. Das heißt also, wenn ich jetzt eine andere Software runterlade, die mit dem gleichen System signiert wurde, dann kann ich das auch einfach in Sparrow reinladen und das verifizieren lassen und dann damit dann auch weiterarbeiten. Es gibt natürlich da auch ein paar Sternchen, die wir dafür sehen müssen, weil nicht alle Projekte das genau gleich mit dem gleichen Schema signieren.

Das heißt, es funktioniert nicht immer, aber wenn man dieses gleiche System hat, dass man da die Signatur hat und das Manifest und entsprechend die Installationsdatei, wenn man diese drei hat, die mit PGP signiert wurden, dann kann man das auch in Sparrow verifizieren. Das ist ein guter Punkt, ist mir gar nicht so aufgefallen.

Aber jetzt, wo ich gerade diesen Screenshot sehe, der da noch in diesem Tweet unten drunter angehangen ist, sieht man, dass man da wirklich dann auch frei Dateien hinterlegen kann, die da verifiziert werden können. Das ist ein guter Punkt. Packen wir euch auf jeden Fall auch mit in die Show Nodes den Tweet nochmal, wo das nochmal aufgelistet und vielleicht auch nochmal, um den Gesamtkontext zu nennen, haben wir jetzt gar nicht gesagt, das war Teil der Sparrow Version 1.8.3.

Mittlerweile gibt es auch schon wieder eine 1.8.4. Das war aber im Endeffekt nur ein kleiner Fix, der für die Sparrow Server Terminal Variante war. Also die Hauptvariante, die bei euch am Desktop läuft, war da jetzt nicht von betroffen. Da hat sich nichts geändert, aber das war jetzt im Prinzip für diese Terminal Variante, die man dann auf einer Node oder sonst irgendwie auf einem Server-System laufen lassen kann.

Aber nur, damit ihr da auch mal Bescheid wisst, um welche Version wir jetzt hier gerade sprechen, weil das jetzt ja auch schon ein Monat fast her ist, dass das veröffentlicht wurde. Genau. Gut. Dann habt ihr noch was zur Sparrow oder sollen wir weitergehen? Wir können weiter. Perfekt. Dann kommen wir auch schon zum letzten Punkt von unserer Quick-Update-Liste und wir sind auch schon wieder bei 40 Minuten für schnelle Updates. Tech-Boost, das passt nicht so zusammen. Naja, wie auch immer.

Gucken wir mal. Die Mutini Wallet ist jetzt auch im iOS App Store und in Google Play Store verfügbar. Aber das war vorher wohl nicht der Fall. Die gab es vorher scheinbar nur als APK-Download oder als, ich glaube, als Web-App über dem Browser. Anthomos NIC, sehr gut. Und gerade, das ist das eine, also da gibt es jetzt auch ganz normal über die Standardbezugsquellen, das ist das eine.

Und das zweite ist jetzt auch von heute ganz frisch, haben wir noch mit reingenommen, gab es noch ein neues Update 0.6.1. Da ist irgendwie so ein bisschen, der Homescreen wurde ein bisschen überarbeitet. Man kann irgendwie sein Noster-Profil da jetzt noch ein bisschen darüber bearbeiten.

Das heißt, man hat jetzt bei Mutini Wallet auch seit kurzem, ist jetzt nicht seit heute, aber ich glaube schon vorher gewesen, dass da auch Noster-Integration ist, dass man da so ein bisschen so diese Social-mäßige in den Wallets drin hat. Das machen momentan ziemlich viele Wallets, wie mir so aufgefallen ist. Jetzt Sois, die Sois Wallet macht das auch aktuell. Wir haben es bei der Inats Wallet, das ist eher eine Cashu Wallet, die aber auch als Lightning Wallet benutzt werden kann.

Die hat auch so einen Noster-Importer, dass man auch so seine Noster-Kontakte direkt mit Cashews bewerfen kann. Also da passiert momentan viel in dem Noster-Umfeld. Das heißt, ja, es ist halt die Frage, ob das so gut ist. Es ist wahrscheinlich ein nettes Feature, aber ich glaube, alle Leute brauchen das jetzt auch nicht unbedingt, dass man das in jeder Lightning Wallet unbedingt eine Noster-Integration haben muss. Ich weiß nicht, wie seht ihr das?

Ja, wenn es die Wallet ist, die man eh standardmäßig verwendet, ich glaube, dann ist es cool, wenn die das auch macht. Ich glaube, da geht es eher darum, dass du, wenn du eine dieser Wallets schon verwendest, dass du dann auch die Funktionen kriegst. Weniger als, dass wir jetzt zusätzlich diese App installieren und dann auch noch dort die Noster-Profile bespielen. Ich glaube, der Vollständigkeit halber ist es schon echt ein cooles Feature. Antonis, was du dazu hast?

Also eigentlich nicht viel da hinzuzufügen. Ich meine, grundsätzlich ist es natürlich immer ein Boost für Noster. Wenn viele andere Apps da eine Integration bieten, gibt es immer wieder User, die Noster bis jetzt nicht benutzen, aber die Wallet entsprechend benutzen und dann sehen, was sind diese ganzen Funktionen? Ich probiere das mal aus. Und das spült eventuell noch ein paar Nutzer in das Noster-Ökosystem.

Aber für mich persönlich ist das jetzt auch kein riesen Anreiz, eine bestimmte Wallet zu nutzen. Aber was vielleicht ein Anreiz sein kann, diese Wallet in Zukunft zu benutzen, das stand jetzt auch noch in diesem Presse-Release von der Version, die heute, also von der 0.6.1, die heute veröffentlicht wurde, darin, ich lese das einfach mal vor und zitiere das.

"Coming up shortly after this release, we will be adding federated Lightning addresses that lock incoming payments to your key, which you may redeem at any point by coming back online." Was im Endeffekt bedeutet, dass die so einen Service anbieten werden, wie es glaube ich auch bei der Zeus Wallet schon existiert, dass man eine Lightning-Adresse hat, die mehr oder weniger so halb gehostet ist dann von der Mutni Wallet, weil die Mutni Wallet ist halt eine Self-Custodial Wallet.

Und dieses federated heißt im Endeffekt, es gibt wahrscheinlich auch wieder so ein zwei-Key-System, das heißt die alten Schlüssel können damit online sein und du hast einen Schlüssel dafür und die empfangen dann, wenn dein Gerät nicht online ist, dann die Lightning-Zahlung, aber du kannst sie halt erst, also du kannst sie halt nur claimen, wenn bzw. die Funds können nur von dir geclaimt werden, weil du derjenige bist mit dem Schlüssel.

Und so funktioniert das so ein bisschen, dass man dann auch Offline-Zahlungen, wir hatten es eben schon bei dem Thema von am Anfang, dass man da jetzt auch auf Lightning so Offline-Zahlungen untenrum ermöglicht, also aber auch eher durch so ein Workaround oder durch so eine neue Technik dann. Und ja, das soll wohl aber eher nur für die Mutni oder Mutini Plus User. Ich glaube Mutni sagt man, oder Anthemus? Du hast das letzte Mal so ausgesprochen. Mutini.

Mutini. Mutini, genau, die Betonung ist auf dem U. Mäuterei. Ah, sehr gut.

Genau, da gibt es scheinbar auch noch so eine Plus-Variante, also wahrscheinlich ist das so Premium-Abo oder so, dass man halt quasi da so als Supporter, Donator oder so was, dann ist das man in so einem Inner Circle, das ist vielleicht ein bisschen legal, aber tief verhaftet dieser Wert, aber zumindest, dass halt diese Funktionen dann erst an diesen Usern zur Verfügung gestellt werden, einfach damit man Anreiz hat, okay, hier, ihr könnt

ja ein paar Euro oder ein paar Satz irgendwie bezahlen, dass ihr halt dann bestimmte Features einfach schon vorher nutzen könnt. Machen ja viele Software-Projekte, die sich so finanzieren, dass du da dann einfach so einen gewissen verlässlichen Einkommensstrom in irgendeiner Form bekommen, was ja durchaus finde ich auch legitim ist. Wäre ja mal spannend, ob die dieses NPUB-Cash, was wir letztes Mal diskutiert haben, nutzen die das dafür? Oder haben die etwas anderes?

Nee, das ist eine einfachere Untersuchung. Ja, bei Suess war das ja auch schon so, dass die, also da gab es ja einen Riesenbrief in der Community auch, weil die ja diese Zahlung, der so, also ganz bin ich da auch nicht durchgestiegen, so wie ich das verstehe, halten dir entsprechend die HTLCs quasi für dich bereit, solange wie du offline bist.

Und wenn du online gehst, kannst du die claimen, aber solange ist die Transaktion im Lightning-Netzwerk nicht abgeschlossen und entsprechend bindest du die gesamte Liquidität in allen Kanälen, die diese Transaktion durchlaufen hat. Und entsprechend, je nachdem, wie lange du offline bist, kann das lange Zeit dazu führen, dass du diese Kanäle blockierst. Das war zumindest mein Verständnis der Sachlage damals und der Auseinandersetzung, die es da zwischen Suess und anderen Lightning-Akteuren gab.

Ich weiß nicht, ob das jetzt hier bei Mutiny auch der Fall ist, dass das so funktioniert, aber ja, das sind eben so diese Workarounds, die man fahren muss in Lightning, um da für den Empfänger die Möglichkeit zu bieten, dass die offline sind. Das wäre natürlich bei Hedgehog, wie am Anfang besprochen, nativ dann entsprechend ein Feature des Netzwerks und des Protokolls.

Ja, das heißt, da muss man irgendwie Superuser sein, damit man das nutzen kann, aber da wird man dann vielleicht sehen, wie sich da, wie das dann implementiert ist, wenn das dann ausgerollt wird.

Das scheint ja irgendwie auch in Kürze zu kommen und wie gesagt, wenn wir da noch was sehen oder hören, dann können wir das vielleicht noch nachschieben und wenn nicht, ist es glaube ich auch nicht so wichtig dann, außer das wird jetzt hier der neue heiße Scheiß, über den man auf jeden Fall reden muss, was ich jetzt nicht unbedingt glaube.

Dann haben wir unsere Quick Updates, die nicht so quick sind, hinter uns gelassen und kommen jetzt zu unseren vermeintlichen Hauptthemen, die wir uns rausgesucht haben. Das sind in der Zahl drei Stück. Führen wir mal mit dem ersten an, das hattest du Anthomus rausgesucht. Das ist das Thema Stratum V2. Ich weiß nicht, macht es aus meiner Sicht Sinn, erstmal zu erklären, was Stratum V2 überhaupt ist oder was das Stratum-Protokoll überhaupt an sich ist.

Ich glaube, das hilft erstmal, um dann die Leute erstmal abzuholen. Kann da einer von euch einen kleinen Überblick machen, was der Unterschied oder was das Stratum-Protokoll an sich ist und dann vielleicht was der Unterschied zwischen Stratum V1, was es ja auch gibt und Stratum V2 jetzt, wo es jetzt auch ein Update zu gab oder was Neues zu gibt, wie sich das unterscheidet. Ja, wir haben, glaube ich, das schon ein paar Mal erwähnt in unterschiedlichen Zusammenhängen in den letzten Folgen.

Grundsätzlich, ich meine, das passt auch ganz gut. Wir hatten ja jetzt auch hier bei Nord Signal schon ein paar Mining-Themen. Da kommen, glaube ich, ja auch noch ein paar. Aber hier geht es eben um das Protokoll, wie im Miner zusammen mit Pools, also wie die Kommunikation läuft.

Und bis jetzt war es eben so, dass die Mining-Pools die Blöcke zusammenstellen, also entsprechend sagen, welche Transaktionen wie zusammengestellt werden sollen und dann entsprechend einen sogenannten Block-Template rausgeben und raussenden an alle Miner, die an diesem Pool teilnehmen. Und diesen Template verwenden dann die einzelnen Miner, die auf der Welt verstreut sind und versuchen da mit entsprechenden Blocks zu minen.

Das gibt dem Pool eben relativ viel Macht, vor allem bestimmte Transaktionen zu zensieren. Das ist auf der einen Seite, kann man das so auslegen, dass wenn der Pool bestimmte Ziele hat oder bestimmte Sachen durchsetzen möchte, dann kann er bestimmte Transaktionen zensieren.

Auf der anderen Seite kann man es aber auch so sehen, dass der Pool entsprechende Zielscheibe wird für regulatorische Instanzen, die sich an den Pool wenden, je nachdem in welcher Gesetzgebung man unterwegs ist, dann bestimmte Schwarzlisten durchzusetzen. Und dies wird versucht jetzt zu umgehen mit Stratum V2. Das ist schon seit vielen, vielen Jahren in der Mache. Da wurde schon vor Jahren darüber diskutiert und wird daran gearbeitet. Das ist aber ein relativ großes Problem.

Das Ziel ist mit Stratum V2, dass diese Erstellung des Block Templates an die Miner weitergegeben wird. Das heißt, man ist zwar immer noch an den Pool angebunden, allerdings können alle einzelnen Miner erstellen ihre eigenen Block Templates. Das heißt, je nachdem auf welchen Mempool man gerade zugreift, wie gut man verletzt ist, hat man einen etwas unterschiedlichen Mempool und dadurch auch vielleicht etwas unterschiedliche Transaktionen.

Man kann die auch unterschiedlich seine Algorithmen einstellen, je nachdem wie man optimieren möchte in seinen Blöcken. Das heißt, es könnte gut sein, dass dann in einem Pool dann unterschiedliche Block Templates oder an unterschiedlichen Block Templates wird zum gleichen Zeitpunkt gearbeitet und der Miner, der entsprechend dann ein Hash findet, der Block Template wird dann entsprechend verwendet. Das schiebt eben die gesamte Verantwortung auf die einzelnen Miner.

Und das ist ein Riesenvorteil für die Zensurresistenz und die Dezentralität, weil wir dadurch die Pools als zentrale Instanz etwas neutralisieren können. Das als Hintergrund zu und das ist im Stratum V2. Ja, sehr gut. Vielen Dank. Was mir jetzt in dem Kontext ja dann, also was vielleicht die Neuigkeit jetzt die dabei ist, ist also dieses Protokoll selber gab es schon jetzt, wie du es schon gesagt hast, schon aus meiner Sicht schon relativ lange.

Der Brainspool und die dazugehörige Brains, glaube ich einfach nur Brains, hat das auch entsprechend dieses Stratum V2 Protokoll auch weiterentwickelt. Von denen kommt das primär und der Brainspool war auch bisher jetzt auch immer seit einigen Jahren auch der einzige, der das der dann eine API oder eine Schnittstelle geliefert hat, dass man mit seinem eigenen Miner dann über das BrainsOS zum Beispiel an das Stratum V2 Protokoll von denen oder den Stratum V2 Pool von denen andocken konnte.

So und was sich jetzt, glaube ich, geändert hat, ist primär, dass sie jetzt eine Referenzimplementierung rausgegeben haben. Das ist im Endeffekt die Neuigkeit, über die wir jetzt heute sprechen wollen oder die wir jetzt hier gerade besprechen.

Die im Endeffekt jetzt dann anderen Pools oder anderen Minern die Möglichkeit gibt, dass die relativ einfach mit dieser Referenzimplementierung das bei sich in die Miner oder in die Pools integrieren können und so dann halt auch selber Stratum V2 für die anderen Pools dann bereitstellen können.

So dadurch, dass du aber gerade eben gesagt hast, das ist vielleicht noch ein bisschen, dass wir da noch ein bisschen weiter reingehen, dass die Miner jetzt ja dann die Blocktemplates generieren müssen oder generieren wollen. Benötigen die ja meines Erachtens auch jetzt dann relativ zeitnah auch Informationen über den Zustand der Transaktionen, der in Mempool vorhanden ist, was ja vorher nicht der Fall war, vorher hat das ja alles der Pool gemacht.

Das heißt, die müssten ja irgendwie dann auch an eine Bitcoin Full Node angebunden werden, was vorher nicht so der Fall war. Das ändert sich ja aus meiner Sicht auch nochmal, oder? Richtig, genau. Das muss man eben dann entsprechend selber aufsetzen. Also wenn man dann selber eine Node laufen hat, dann müsste man halt den Miner entsprechend dann an die Node anbinden.

Es gibt natürlich viele verschiedene APIs, an die man dann halt auch einen Miner entsprechend anhängen könnte, um diese Information zu bekommen. Aber idealerweise würde man dann den Miner entsprechend dann auch an die eigene Node mit anbinden. Das ist aber eben in dieser Firmware, also es gibt eben unterschiedliche Modelle.

Das Schöne ist bei dieser Implementierung, dass es möglich ist, Miner damit zu verbinden, die eben noch keinen Firmware Update haben und entsprechend noch auf Stratum V1 laufen. Die können trotzdem mit dieser Implementierung an Stratum V2 teilnehmen. Allerdings läuft das eben dann entsprechend über einen Proxy. Das heißt, man muss dann so einen Proxy Server zwischenlaufen haben, der dann entsprechend diese Block Templates erstellt. Das ist dann so ein Hub dazwischen.

Den muss dann aber der Pool bereitstellen oder muss dann das der Pool bereitstellen, der das dann benutzt und nicht der Miner selber, der das bei sich verwenden will? Richtig, so wie ich das verstehe, ist das dann entsprechend. Aber das zerstört so ein bisschen den Sinn der ganzen Sache. Ich glaube, das ist hauptsächlich, weil am Ende betreibt das ja dann trotzdem der Pool. So wie ich das verstehe, ist das.

Man muss die Geräte, also die Miner selber, müssen kein Update auf die Firmware haben, um über, also man kann die Default-Firmware von Bitmain zum Beispiel verwenden und die dann, der Miner denkt, der ist an einen V1 Pool angebunden, aber dadurch, dass das ein Proxy ist, ist er dann trotzdem indirekt oder implizit dann an einen V2 Pool angebunden. Das ist, glaube ich, der große Vorteil hierbei, dass man das Mining-Gerät selber nicht aktualisieren muss.

Der Pool selber muss in jedem Fall Infrastruktur bereitstehen, weil sonst würde es ja überhaupt nicht funktionieren. Richtig. Nur, dass eben die Frage ist, wer diesen Proxy betreibt. Weil wenn der Pool den Proxy betreibt, dann erstellt der Pool wieder die Block-Templates. Wenn der Miner auf V2 läuft, also ein Firmware-Update hat, dann kann man den entsprechend verbinden mit einer Fullnode und der erstellt seine eigenen Block-Templates und dadurch ist diese Dezentralisierung gewährleistet.

Wenn der Pool aber den Proxy betreibt, ich weiß nicht, ob es auch möglich ist, als Nutzer oder als Besitzer eines Miners auch ein Proxy auf dem Server einfach laufen zu haben, an dem man sich anbindet, dass es von Seiten des Pools gleich aussieht. Naja, aber ich sehe gerade, es gibt ja so eine Grafik, die können wir euch auch gerne jetzt mal in das aktuelle Kapitelbild einbinden, weil ich die ganz hilfreich finde, um das mal so ein bisschen nachzuvollziehen.

Da ist im Endeffekt im oberen linken Bereich Geräte abgebildet, wo dran steht, die laufen noch auf der Stratum V1-Firmware und die sind dann halt an diesen vorgeschalteten großen Proxy angebunden, der dann wiederum aber eine Stratum V2-Connection zu dem Stratum V2-Mining-Pool hat. Das heißt, das setzt ja schon theoretisch voraus, dass der Mining-Pool ja auf jeden Fall auf V2 laufen muss.

Und aus meiner Sicht suggeriert es ein bisschen dadurch, dass wir jetzt ja diese zwei großen Geräte daneben stehen haben, dass das schon irgendwie vom Pool kommt und weniger aus dem Peer-to-Peer-Netzwerk, weil wir haben die Miner an sich ja eher so, die sind halt eher damit als diese kleinen Rechner da dargestellt. Deswegen wirkt das auf mich so, dass die dann eher die Infrastruktur bereitstellen dafür. Genau.

Ich nehme an, dass das halt einfach eine Art ist, weil wenn man natürlich jetzt als Pool sagt, okay, ich steige jetzt auf Stratum V2 um, dann würde man halt einen riesen Marktanteil verlieren an allen Minern, die eben noch nicht auf Stratum V2 laufen. Entsprechend ist das halt noch eine Möglichkeit, um diese Miner eben mit einzubinden, selbst wenn man dann immer noch die Block-Templates eben erstellt.

Aber man hofft natürlich, dass mit der Zeit mehr und mehr Stratum V2-Miner sich anbinden, für die man diese Dienstleistung dann entsprechend nicht mehr anbieten muss, weil die selber ihre Block-Templates erstellen. Das ist auch interessant, weil ich habe ja hier auch einen Miner rumstehen und da hatte ich ja Brains so erst darauf installiert und da hat man wirklich explizit beim Brains-Pool immer die Wahl gehabt, ob man auf V1 oder V2 minen will.

Das heißt, da habe ich das so verstanden, dass die da ja prinzipiell auch immer zwei Pools parallel betrieben haben, der dann vermutlich aus meiner Sicht dann ja eigentlich, oder? Nee, weil man konnte ja explizit auf V1 auswählen. Das heißt, die mussten da ja auch einen V1-kompatiblen Pool auch noch laufen haben. Nee, da muss es ja so gewesen sein. Das heißt, in der Form konnte man diese Lösung, wie sie jetzt hier vorgestellt haben, da noch nicht benutzen.

Beziehungsweise, die geht jetzt ja hier wirklich von einem reinen Stratum V2-Setup aus. Und wir stellen halt durch diesen Proxyserver einfach nur eine Schnittstelle für alte Endgeräte zur Verfügung. Richtig, genau. Ja, und eben das ist voll Open Source, diese Implementierung. Wir haben, glaube ich, gar nicht den Namen genannt. Das ist SRI. Das ist der Name dieser Implementierung.

Die kann eben verwendet werden von entweder existierenden Pools, um entsprechend umzusteigen oder, wenn hier einer der Zuhörer, wenn ihr gerne einen eigenen Pool starten wollt, könnt ihr das damit machen. Oder wenn ihr einen Haufen Freunde habt, die Platminer und Bitaxis zu Hause laufen habt, damit könnt ihr einen eigenen Pool dann zusammen schnüren. Ja, also auf jeden Fall sehr coole Sache. Ich bin also ein Riesenfan von Stratum V2 seit Jahren schon.

Das ist so eine Sache, die ein bisschen ernüchternd ist, dass es alles viel länger dauert, als man sich erhofft. Aber es ist schön, jetzt diese Entwicklung endlich zu sehen. Das ist meiner Meinung nach ein Riesenbaustein in der Sicherung der Dezentralität im Mining Space. Gerade für, ich meine, man sieht jetzt gerade nach dem Absturz der Mining Dominanz in China jetzt eigentlich genau das gleiche Spiel nur in den USA. Man hat trotzdem auf der ganzen Welt einzelne Miner, die da rumspringen.

Aber wenn die alle an zentralen Pools dranhängen, ist es nur eine Frage der Zeit, bis das irgendwie regulatorisch eingenommen wird. Und wenn wir es hinbekommen, dass wir einen großen Anteil dieser Einzelminer dann auf Stratum V2 dann bekommen, dann ist eben viel Macht von den Pools weggenommen und entsprechend diese Gefahr etwas gemindert, dass wir da zu viel Zentralisierung sehen. Also ich kann das kaum überbewerten, wie wichtig das ist, dass wir das hinbekommen.

Ja, würde ich dir absolut zustimmen. Ich finde es auch spannend, es gibt ja so eine kleine Aufrüstung von den Highlights und da stehen einfach definitiv mehr Pro-Argumente dafür, dass das für Miner selber viel mehr Pro-Argumente hat, als jetzt für die Pools selber. Für die Pools ist es natürlich eine Beschneidung prinzipiell von der eigenen Möglichkeit, sage ich jetzt mal.

Aber auf der anderen Seite ist es natürlich vielleicht dann auch für Pools, die sich aktiv dafür entscheiden, so einen Pool, also einen Stratum V2 Pool zu betreiben, dass es ein Commitment quasi an die Grundwerte von Bitcoin jetzt ist. Vielleicht kann man es so beschreiben, aber das wäre es ja schon auf jeden Fall.

Und was vielleicht auch noch ganz cool ist und erwähnenswert ist, das sehe ich jetzt hier gerade auch noch mal in dem Artikel, es gibt da scheinbar dann in dieser Referenzimplementierung auch gleichzeitig noch so ein, das nennt sich Pool Fallback Funktionalität, das im Endeffekt bedeutet, dass du, wenn du an einen Stratum V2 Pool angebunden bist, der diese Referenzimplementierung verwendet, dass du dich theoretisch nicht nur an einen Pool anbinden kannst, sondern an mehrere.

Und wenn dein Blocktemplate, was du gebaut hast und das an den Pool schickst und das wird abgelehnt, dann sorgt diese Implementierung im Endeffekt dafür, dass du zu einem anderen Pool wechselst. Was darum wieder bedeutet, dass die Pools, die wirklich anfangen Blocktemplates zu zensieren, Hashrate verlieren auf Dauer, wenn das bei mehr Meinern passiert.

Und die Endlösung, also dieses Fallback ist im Endeffekt dann so, dass wenn das bei allen Pools passiert, sei jetzt mal dahingestellt, ob das realistisch ist, aber dann landet man im Endeffekt dadurch, dass man ja den Vorteil hat, man ist ja dann durch seine Infrastrukturen an einen Bitcoin Fullnode angebunden, weil das heißt, man hat halt eigentlich immer die aktuellsten Transaktionen, dann endet man im Endeffekt als Solominer, weil du quasi

in dem Konstellationen, du hast ein Mininggerät und du hast eine Bitcoin Fullnode, das heißt, du kannst trotzdem valide Blöcke bauen und die auch publischen. Also das ist durchaus legitim.

Und das ist eigentlich auch ganz cool, dass man da so ein bisschen so ein, wie soll man das sagen, so ein Judging, also dass man so ein Gerichtsbarkeit da so ein bisschen drin hat, dass das dann Anreiz auch für Pools ist, nicht zu zensieren, weil durch dieses Protokoll sichergestellt wird, dass im Zweifelsfall die ganzen Mininggeräte, wenn sie zensierte Blocktamp, also Playbills zurückbekommen, dass die einfach dann aus dem Miningpool abhauen

und die Hashrate da innerhalb von kurzer Zeit massiv einbricht. Und das ist vielleicht auch noch ein ganz cooler Anreiz, dann wirklich dann zu sagen, okay, wir betreiben jetzt hier einen ehrlichen, offenen, transparenten Pool, der nicht zensiert. Deswegen habt ihr bei uns, haben wir auch eine stabile Hashrate. Ja, also da bin ich ganz bei dir. Das ist auf jeden Fall ein cooles Feature.

Also ich sehe auch den Vorteil eben für die Pools, dass sie dann auch entsprechend sagen können, so wir haben nichts damit zu tun, so wie die Blöcke zusammengestellt werden. Das übergeben wir komplett an die Nutzer. Das ist natürlich schwierig, wenn es halt nur einzelne Pools sind, die entsprechend dieses Protokoll verwenden und andere Pools das selbst übernehmen.

Allerdings, wenn das eben große so Adoption erfährt, dann und das so ein Industriestandard wird, dann ist das schon ein valides Argument, auch gegenüber einem Gesetzgeber zu sagen, wir sind dafür nicht verantwortlich und geben diese Verantwortung ab. Ich sehe gerade auch noch, um das vielleicht mal ein bisschen abzurunden, es steht auch noch unten drunter, dass man auch an der Entwicklung von dieser Referenzimplementierung natürlich auch mitwirken kann.

Und wenn man spenden möchte, um das zu unterstützen, dann geht das auch wieder, wie wir es beim letzten Mal schon ein paar Mal hatten, über das OpenSats, das heißt, über OpenSats findet man dann auch nur das Projekt von Stratum V2 oder, wartet mal ganz kurz, ich gucke einfach mal direkt rein hier, wie das, ja genau, das Projekt heißt Stratum V2, was da über OpenSats gesupported werden kann, also jetzt nicht Brains oder sowas, sondern das ist wirklich

das Protokoll selber und das könnt ihr, wenn ihr da Interesse daran haben solltet oder wie auch immer, dass man das auf jeden Fall auch mit ein paar Satz dann auch mitbedenken oder bewerfen kann, um die Entwicklung da voranzutreiben und zu unterstützen.

Aber wir haben gerade über Stratum V2 gesprochen. Da war eine Zwei im Namen. Jetzt sprechen wir noch über eine andere Software, wo es ja seit Kurzem auch eine Zwei im Namen gibt. Das war lange angekündigt, immer wieder, ja, es kommt bald, es kommt bald, bald, soon, two weeks, two weeks. Ja, und jetzt ist es dann scheinbar endlich gekommen. Es gibt jetzt nämlich BISC 2. Das lief quasi immer vorher in der Hauptversionsnummer 1, 9.1, 9.2, 9.3, bla bla bla.

Und jetzt gibt es eine neue Variante, die BISC 2 ist. Was vielleicht auch nochmal zu sagen muss, um ganz, ganz von vorne anzufangen. Also man updatet die Software nicht über die alte BISC-Variante, man muss es separat installieren. Das ist eine eigene Installation. Über die alte BISC 1 Version kann man die neue BISC 2 Version nicht updaten. Das ist mir zumindest eben schon mal aufgefallen, als ich BISC, die alte Variante aufgemacht habe. Also ihr müsst das explizit herunterladen.

Das ist in dem Sinne auch eine eigene neue Software. Genau. Das nennt sich jetzt aktuell noch BISC Easy und entspricht dem, wie BISC bisher funktioniert hat, dass du eben eine Reputation aufbaust, also Bewertungen bekommst für bereits durchgeführte Trades auf dieser dezentralen Exchange. Und da sollen aber jetzt zukünftig noch neue Wege kommen zu handeln.

Du hast es schon gesagt, einige Swap-Varianten, dass du zwischen Liquid und Lightning Bitcoin swapst oder dass du auch zu Monero swapst und ja verschiedene weitere. Die sind aber alle erstmal noch auf der Roadmap.

Und genau das ist eines dieser Features, die jetzt neu sind zukünftig, die auch kommen werden, ist, dass du nicht mehr bloß diese eine Reputation hast, also dein eigenes Profil, was ja auch privatsphäre-technisch kritisch sein kann, sondern dass du zukünftig eben ganz viele Alias haben kannst, ganz viele verschiedene Persönlichkeiten. So habe ich es jetzt verstanden aus dem Artikel, den wir auch verlinken werden.

Damit ja nochmal ein ganz anderer Ansatz auf der Plattform zu handeln und zu agieren und ja eben nicht bloß auf diesem Reputationsmodell. Antimus, hast du es schon getestet? Hast du ein bisschen mehr Einblick? Nein, also getestet habe ich das selber noch nicht, aber grundsätzlich, also eben habt ihr das eigentlich schon ganz gut zusammengefasst. Also grundsätzlich, wie gesagt, ist es eine komplett neu aufgesetzte Software, komplette neue Architektur.

Das ist aktuell für Desktop, es soll aber eben dann auch entsprechend Clients dann auch für Mobile geben. Und die fundamentalen Eigenschaften dieser Decentralized Exchange sind eben noch gleich, dass man eben noch, dass es noch Peer-to-Peer ist, es ist immer noch über Tor und es soll auch noch ITP-Support kommen und eben dann noch die Mobile Apps. Und der Hauptvorteil eben diese unterschiedlichen Trade-Protokolle, also gerade dieses BISC-Easy ist ganz schön.

Es gab halt immer das Problem, dass man als neuer Nutzer bei BISC immer schon Bitcoin haben musste, um entsprechend die Deposit, also die Kaution zu hinterlegen. Und das war immer so ein Problem, okay, ich möchte meine ersten Bitcoin kaufen, so wie kriege ich das jetzt hin?

Und dann gab es irgendwie so Seitenkanäle, wo man sich irgendwie über irgendeinen Messenger dann ausgetauscht hat und darüber Trades gemacht hat, damit man überhaupt anfangen konnte, wenn man niemanden in seinem direkten Umfeld hatte. Und das soll jetzt hiermit eben dann vereinfacht werden, dass man seine ersten Bitcoin kaufen kann, auch ohne eine Kaution aufzugeben am Anfang.

Und das ist natürlich sehr limitiert dann auf kleine Summen, damit man da das Risiko minimiert, dass oder einfach Leute davor, dass es sich nicht lohnt, da Groß-Scams zu betreiben. Aber so bekommt man seine ersten Bitcoin dann ohne Kaution aufgeben zu müssen und dann kann man diese als Kaution verwenden, um größere Käufe dann zu tätigen.

Genau, ja, und eben, also das wird auch schön, dass es dann in Zukunft dann auch Lightning Trades gibt, also ähnlich wie man es kennt von Robosets, dass man da weitere Möglichkeiten hat. Und ich sehe das Ganze als ein bisschen so ein Neustart für BISC, um da deutlich mehr Potenzial zu eröffnen.

Die alte Software war eben sehr langsam, hat viel Rechenleistung benötigt und war sehr aufgebläht und das ist hoffentlich jetzt hier etwas simpler und effizienter aufgebaut und wird hier auf unterschiedlichen Plattformen laufen und viel Entwicklungspotenzial in den nächsten Jahren bieten. Hoffen wir mal. Ein kleiner Nugget, den ich jetzt gerade erst gesehen habe, deswegen musste ich gerade auch so schmunzeln. Das ist ein super Pop Quiz.

Wie der Name BISC entstanden ist, das war mir gar nicht bewusst. Und zwar, das ist von dem früheren Satoshi Square, das war so ein Protokoll bei Meetups in den ersten Jahren, wie man sich Bitcoin gegenseitig handeln konnte. Das war Satoshi Square und der ursprüngliche Name für BISC war davon inspiriert oder auch das Protokoll war davon inspiriert und sollte am Anfang Bit Square heißen. Und aus dem SQ von Square kam dann BISC. Die ersten zwei Buchstaben von Bit und von Square, BISC. Interessant.

Ich finde es ganz spannend, weil man hat jetzt ja schon in den letzten Zeit gemerkt, wie viele, sage ich mal, modernere Lösungen für diese Peer-to-Peer Plattformen rausgekommen sind. Auf der einen Seite hatten wir, jetzt ist es gerade schon gesagt, RoboSats, aber jetzt ist es dann auch diese App-basierten Lösungen, die wir jetzt gesehen haben mit Peach, Wechsel und was es da nicht sonst noch so alles jetzt in der Richtung gibt.

Und da war BISC ja schon immer so noch so ein bisschen dieser schwerfällige alte Elefant, der so irgendwie, ja, ihr müsst das auf jeden Fall auf dem Desktop installieren, dann super viele Leute. Aber ich habe gar keinen normalen Computer mehr, was soll ich tun? Also das ist ja prinzipiell eher so die Generation von heute.

Und jetzt glaube ich auch dieser Ansatz, dass man das Ganze dann ins Web oder als mobile Variante sogar bringt, ist, glaube ich, dann wieder wirklich so, du hast es gerade schon gut beschrieben, wieder so, wir schließen wieder in die aktuelle Zeit halt mit unserer Software auf und werfen vielleicht die Altlasten auch über Bord, was dann auch vielleicht der Grund war, das, was ich gerade am Anfang gesagt habe, dass man nicht mehr aktualisieren

kann, dass die Software halt wirklich nur komplett eigenständig ist, weil diese ganzen Altlasten aus dem alten Ding einfach nicht mehr gebraucht werden oder vielleicht, dass man einfach sagen wollte, wir schneiden jetzt die alten Zöpfe ab und fangen quasi auf einer neueren Technologie nochmal neu an oder versuchen es zumindest. Ja, also das passt auf jeden Fall.

Also man muss natürlich da auch dazu sagen, dass im Gegensatz zu Peach zum Beispiel, hinter Peach steht eben auch ein Unternehmen, die entsprechend sehr agil auch handeln können und die haben eben ihre App, die sie dann schnell entwickeln können und anpassen können.

Bei BISC ist das Ganze deutlich, schwerfällig war das schon ein gutes Wort, also das ist eben so eine DAO, das heißt dementsprechend so eine Decentralized Organization, die sich über die BISC auch koordiniert und die haben ein ganzes System, die haben entsprechend auch ihre eigene, in ihren eigenen so wrapped Bitcoin, Shitcoin, mit denen sie dann so die ganzen Wahlstimmen entsprechend dann verteilen und darüber werden dann Entscheidungen getroffen,

wie weiter vorgegangen wird und die ganzen Contributor und Maintainer und so Moderatoren, die die Trades dann entsprechend moderieren, die werden auch bezahlt entsprechend in diesem Token und das ist ein riesen System im Hintergrund und da gibt es dann immer wieder wiederkehrende Wahlen, wo dann bestimmte Positionen vergeben werden und so weiter.

Also es ist ein riesiges System, das bleibt auch alles erhalten, auch in der alten BISC 1 Version, das läuft da auch weiter, aber diese ganzen Funktionalitäten, ist auch cool, dass das funktioniert hat, dass entsprechend so keine offizielle Firma gegründet werden musste und die Leute weitestgehend anonym bleiben konnten und so auch nicht anzugreifen waren, aber das alles in einer Software zu haben, war einfach sehr ineffizient und so

ist jetzt diese ganze Verwaltung in der alten Software geblieben und die neue Implementierung mit BISC 2 ist dann wirklich nur dem Handeln und dem Endnunzer dann zugewandt.

Er ist mittlerweile schon sehr, sehr in die Jahre gekommen, aber ich denke gerade auch dieses Thema DAO, was du gerade schon noch ein bisschen erläutert hast, wird da vielleicht auch noch mal erläutert, weil der MC ja auch einer von denjenigen ist, der auch so eine BISC-Node auch betreibt, also der stellt auch Infrastruktur für BISC zur Verfügung und erzählt auch noch mal so ein bisschen darum, wie das so ein bisschen funktioniert. Können wir vielleicht auch noch mal in die Show-Nodes machen.

Ich erinnere mich daran, dass die Soundqualität nicht so geil war, aber kann man sich vielleicht trotzdem noch mal anhören, wer da noch mal reinhören möchte. Also verlinken wir euch auf jeden Fall dann noch mal.

Aber wäre vielleicht dann in dem Kontext noch mal vielleicht auch ein Follow-up oder ein Update wert, dass man den MC vielleicht noch mal zu dem Thema noch mal fragt, ob er noch mal Bock hat, was zu erzählen, weil ich könnte mir auch vorstellen, dass er auch von der Infrastrukturseite, er da jetzt ja auch dann durchaus immer noch beteiligt ist und da vielleicht sich auch jetzt einiges auch geändert hat, dass er jetzt auch eine

Infrastruktur, irgendwelche Dinge neu bereitstellen musste und da Sachen anpassen musste auf seiner Seite. Wäre vielleicht auch noch mal spannend aus meiner Sicht. Und wenn nicht, können wir es vielleicht dann auch noch mal als Voice-Nachricht oder so was dann hier in den Tech-Boost reinholen. Wäre vielleicht auch noch mal eine Idee. Gut, haben wir noch was zu BISC 2 oder sollen wir zum letzten Punkt übergehen? Alle nicken, alle sind glücklich. Das ist schön. Gerne übergehen.

Gut, sind wir mit BISC 2 durch und kommen zu unserem letzten Thema für heute. Und da geht es um Run'n'Dojo in der Variante 2.1.3.

Klingt jetzt erst mal von der Versionszahl gar nicht so spektakulär, aber vom Thema selber ist es eigentlich ganz interessant, weil die nämlich jetzt auch den Weg gehen oder zumindest die Software dafür fit machen, dass man bei die Whirlpool-Koordinatoren, also Run'n'Dojo ist ja an Whirlpool von Samurai angebunden und die verfolgen das jetzt so weit, dass die Koordinatoren dezentralisiert werden.

Wir haben jetzt ja aktuell bei Whirlpool eigentlich nur einen großen Koordinator und das ist der von Samurai selber. Und da ist jetzt die Idee, dass man das dezentralisiert. Und ich glaube, so wie ich es verstehe, ist es jetzt so, dass Run'n'Dojo jetzt dafür vorbereitet wird, dass die in der Lage sind, dieses Kommunikationsprotokoll zu sprechen, damit man mit diesen dezentralisierten Koordinatoren auch kommunizieren kann. So verstehe ich zumindest jetzt dieses neue Update.

Ich weiß nicht, an Thomas, Kalso, habt ihr da noch mehr zu? Ja, also auch das eine Entwicklung, auf die wir schon lange gewartet haben. Wie du schon gesagt hast, Run'n'Dojo ist hier jetzt ausführend und stellvertretend mit dem Versionsupdate. Die haben das entsprechend durchgeführt. Aber hauptsächlich geht es hier um die Entwicklung, dass der Koordinator von Whirlpool dezentralisiert wurde und das ist eine Entwicklung von Samurai selber.

Und wenn man zurückgeht, die Hauptkritik an dem Samurai-Ökosystem und an Whirlpool im Vergleich zu anderen Coinjoin-Implementierungen war, dass es einen zentralen Koordinator gibt, der die Whirlpool-Runden entsprechend immer koordiniert und die einzelnen Nutzer zusammenführt und diese Transaktionen baut. Der Koordinator war schon immer geblendet, wie man sagt. Das heißt, er konnte jetzt nicht sehen genau, wer an diesen Runden teilnimmt.

Das heißt, es war schon limitiert, was da oder eigentlich kaum Details über die Herkunft dieser Privatsphäre wurde da wenig beeinträchtigt. Allerdings gab es da schon ein paar Sachen, vor allem für diejenigen, die Samurai ohne eine Node betrieben haben, also ohne eine eigene Node. Und entsprechend hat man dann die Node von Samurai verwendet und hat auch seine X-POP aufgegeben und damit dann an Samurai quasi seine ganzen Coins gedoxed.

Das war ein riesen Kritikpunkt an dem Samurai-Ökosystem und entsprechend ist das jetzt ein erster Schritt, um dem entgegenzuwirken. Der Koordinator ist jetzt in der Lage, dezentral zu sein. Das heißt, es können unterschiedliche oder mehrere Koordinatoren gleichzeitig betrieben werden, sowohl von Samurai selber als auch extern. Und mit denen kann man sich dann entsprechend auch verbinden.

Jetzt zum aktuellen Zeitpunkt ist es noch so, dass es einen Hauptkoordinator gibt und diese zusätzlichen Koordinatoren fungieren als Backups. Das heißt, sollte ein Koordinator entweder einfach ein Netzwerkproblem haben und nicht mehr zugänglich sein, dann wird automatisch auf einen neuen Koordinator umgeswitcht.

Oder sollte es entsprechend einen Angriff auf Samurai geben oder irgendwie regulatorisch da etwas durchgesetzt werden, dass sie den Betrieb einstellen müssen bei ihrem Hauptkoordinator, dann würde das automatisch auf weitere Koordinatoren umspringen. Langfristig ist aber natürlich das Ziel, dass das gesamte Netzwerk halt hier, also deren Protokoll nennt sich Soroban, das ist eben ein Protokoll, das auf Tor läuft und hier die Kommunikation übernimmt.

Langfristig ist das Ziel, dass hier die Koordinatoren immer wieder gewechselt werden und dann sowohl Koordinatoren von Samurai als auch externe verwendet werden, damit das System möglichst resilient ist und hier kein Honeypot entsteht für bestimmte Daten. Finde ich auf jeden Fall eine gute Erklärung dafür.

Was ich jetzt hier noch in dem Artikel darüber lese, ist, dass über dieses Soroban, was du gerade genannt hast, dieses Kommunikationsprotokoll jetzt auch die Kommunikation mit den Mixing-Partnern darüber stattfindet.

Es schien vorher ja auch, dass das anders war, dass es vorher halt so war, alle waren vorher an den Verpo-Koordinator angeschlossen und der hat im Endeffekt quasi die Informationen in so einem Sternensystem an die angeschlossenen Peers verteilt und der hat halt koordiniert, okay, die fünf Leute kommen jetzt in den Coin-Join rein und schickt denen im Endeffekt die Informationen zu, okay, hier schickt mir eure Signaturen, damit wir diese Runde machen

können und jetzt scheint es ja so zu sein, dass die Peers untereinander auch kommunizieren können. Das heißt, dass wir so ein bisschen so eine Vollvermaschung so ein bisschen dann von der Topologie hinbekommen und nicht mehr ein bisschen weg von dieser Sternenstruktur, wie es vielleicht vorher dann war.

Das ist vielleicht auch nochmal ganz spannend zu erwähnen, dass das dann durchaus auch nochmal Möglichkeiten bietet, dass man wirklich von dieser krassen Zentralität von dem Virpo-Koordinator auch nochmal wegkommt, dass dann auch wirklich die Peers untereinander in der Lage sind, miteinander zu sprechen, wie es jetzt gerade auch zum Beispiel, wie war es vorher bei Biscutten, da sprechen ja dann über dieses BIS-Protokoll auch die Peers direkt miteinander, ohne dass

dazwischen irgendwie ein zentraler Koordinator in dem Sinne dann halt steht, sondern da ist ja wirklich dann die Kommunikation Peer-to-Peer zwischen denen, die den Trade aufmachen. >>Richtig, genau, man kennt das ja so von so einem Gossip-Network. Das ist hier ähnlich, dass man entsprechend ein ganzes Netzwerk erschließt und darüber die Information weitergibt.

So wie ich das verstehe, braucht es eben immer noch diesen Koordinator, der dann tatsächlich diese Daten dann bündelt, aber wie diese Daten dann tatsächlich an den Koordinator gelangen, könnte dann über mehrere Hubs dann auch passieren. Dass man dann nicht unbedingt die direkte Route hat. Es bleibt aber trotzdem die Empfehlung, die klare Empfehlung, eine eigene Node laufen zu haben. Es muss nicht zwangsläufig eine Ronin-Dojo-Node sein.

Das ist natürlich die stabilste Node für diese Anwendung, wenn man viel, also durchgehend eine Whirlpool laufen hat, fährt man auf jeden Fall am besten, wenn man eine Ronin-Dojo laufen hat. Allerdings gibt es eben auch Whirlpool-Implementierungen auf vielen anderen Nodes, wie jetzt zum Beispiel MyNode, Umbrell, Start9 und so weiter. Die üblichen Verdächtigen, die so Marktplätze haben, diese Node-Implementierung haben in der Regel auch eine Whirlpool-Implementierung.

Das heißt, darüber kann man das auch laufen haben. Aber da auf jeden Fall die klare Empfehlung, eine eigene laufen zu lassen, weil sonst gibt man immer noch die XPUB-Un-Samurai, wenn man nur am Handy entsprechend die App verwendet.

Das heißt, auch wenn ihr als ersten Schritt einfach nur die Mobile-App hattet und da schon mal eine Wallet drauf hattet und dann mal eine Node aufsetzen wollt, portiert nicht einfach die Wallet rüber, sondern erstellt eine komplett neue Wallet und schickt die Fonds dann entsprechend rüber. Weil ihr wollt, also selbst wenn ihr dann entsprechend auf euren eigenen Node umzieht, die behalten immer noch die XPUB. Das heißt, da wollt ihr einen frischen Neuanfang, um da alle Verbindungen zu kappen.

Ja, guter Punkt. Und was ich auch noch spannend finde, wir hatten gerade eben schon mal über Sparrow gesprochen, beziehungsweise sprechen wir ja relativ häufig, die ja auch eine Whirlpool-Integration haben. Da bin ich jetzt auch mal gespannt, was da jetzt dann prinzipiell auch in Zukunft noch passieren wird, ob die da jetzt auch dann dieses neue Soroban-Protokoll bei sich dann implementieren, weil die im Endeffekt abstrahieren das ja so ein bisschen.

Man kann eine eigene Bitcoin-Fullnode als Koordinator in Anführungszeichen ja dann für Sparrow benutzen und diese eigene Runnern oder diese eigene Whirlpool-Koordinator-Koordinationssoftware, da kriegt man ja bei Sparrow in dem Sinne ja nichts von mit. Dann in dem Sinne dann, aber da wird ja denke ich mal jetzt auch in Zukunft auch noch irgendwie eine Veränderung dann auf Sparrow da hinzukommen, wenn das nicht in eine komplett eigene Infrastruktur halt läuft, das weiß ich halt nicht so genau.

Also die arbeiten ja auch mit Whirlpool, aber ich weiß nicht, ob die als eigenständiger anderer zentraler Koordinator hier agieren und in dem Sinne halt erstmal unabhängig von dem eigentlichen Samurai-Whirlpool sind, der halt über die Samurai-Mobile-Wallet läuft. So wie ich das verstehe, sind die, also hat bis jetzt Sparrow keinen eigenen Koordinator. Also die schicken im Endeffekt einfach nur die Information weiter an den Samurai-Koordinator.

Also entsprechend von der eigenen Node, an die man angeboten ist mit seiner Sparrow-Wallet, die verbindet sich entsprechend mit dem Koordinator von Samurai, weil man partizipiert ja, wenn man Sparrow benutzt, auch an der Liquidität von gesamten Whirlpool. Und das lief alles aktuell über einen Koordinator. Es wurde aber schon quasi gelabelt, welche User von Sparrow kommen und welche von Samurai kommen, weil es eben auch einen entsprechend Gebührensplit gab für dann entsprechend die Maintainer.

Wie du aber schon richtig angesprochen hast, jetzt in Zukunft könnte das gut sein, dass dann Sparrow einen eigenen Koordinator stellen kann, der dann wahlweise auch angesteuert werden kann. Das ist ein guter Punkt, dass die dann wirklich auch einer von den dezentralisierteren Koordinatoren werden, weil sie sagen, okay, wir machen uns jetzt "flügge" vom Samurai und werden ein bisschen selbstständiger.

Oder vielleicht ist es ja einfach gewollt, dass wir da mehr Diversität in den Koordinatoren bekommen, dann einfach um diesen "single point of failure" loszuwerden. Und das Schöne ist, dass man aber trotzdem die Liquidität beibehält. Also man spielt immer noch in einem Pool und hat ein Anonymity-Set pro Pool. Und das möchte man auf jeden Fall nicht aufgeben.

Ich meine, wir haben ja in der letzten Folge oder vorletzten Folge, ich weiß nicht genau wann das war, dass wir die 10.000 Bitcoin geknackt haben in "unspent" Whirlpool-Capacity. Das ist eine Riesensumme und eben das da in diesem Anonymity-Set sich zu bewegen, das möchte man, das ist der Riesenvorteil hier. Und entsprechend dann die Möglichkeit haben, trotzdem dezentrale Koordinatoren zu haben und gleichzeitig in einem Pool zu baden. Das ist hier das Ziel.

In dem Sinne verbleiben wir auf jeden Fall bis in einen Monat, bis zum nächsten Tech Boost, wo wir uns die Updates aus dem Monat April, der jetzt gerade frisch angefangen ist, dann uns anschauen und dann sehen wir uns oder hören uns bis dahin dann in anderen Formaten, aber spätestens dann im Tech Boost wieder. Deswegen danke Anthomos, danke Calso, dass wir das heute zusammen gemacht haben. In dem Sinne, focus on the signal, not on the noise. Schönen Abend und ciao. Ciao. Ciao.