Nodesignal-Talk - E184 - Silent Payments

nämlich einmal dem Thorsten. Hallo Thorsten. Hallo. Und den Chris habe ich gefunden. Hi Chris. Wow, hi. Was für eine Ehre. Grüße euch beide. Also ich habe die anderen Peers natürlich auch sehr lieb, die ich im Netzwerk finde. Ich muss mich ja mit allen verbinden. Wir sind ja ein Peer-to-Peer Electronic Cash System. Insofern, alle Peers sind gleichwertig. Viel Geplänkel vorneweg. Wir haben eine Blog-Zeit. Und zwar, wer hat sie von euch beiden? 845550. Ja, kann ich bestätigen.

Wobei ich sagen muss, eben, ich habe das mal verglichen, ich bin mal wieder einen Blog hinterher gewesen auf meinem Node. Im Vergleich mit was? Zum Beispiel mit Mempool. Vielleicht liegt es daran, dass deine Node hinter Tor liegt, dass das so ein bisschen später ankommt, zumindest ein paar Sekunden. Thorsten, würdest du das so unterschreiben, dass das passieren kann? Ja, aber das sollte meines Erachtens eher, quasi sag ich mal hier in unseren westlichen Geraden,

eher ein Teil von ein paar Sekündchen sein und nicht Minuten. Also ich war ziemlich lang auf Blog 549, als Mempool schon 550 angezeigt hat. Jetzt bin ich aber synchronisiert. Keine Ahnung, wo es liegt. Ich gucke es jetzt auch nicht hier. Also ich gucke jetzt lokal auf meine Node, nicht über Tor wie letztes Mal, dummerweise. Aber meine Node läuft über Tor. Ja, aber du kannst ja trotzdem lokal darauf zugreifen. Das macht ja dann durchaus Sinn.

Da musst du ja dann nicht extra ins Internet rausgehen, über Tor rausgehen, um dann wieder über Tor bei dir irgendwie wieder reinzukommen mit quasi mit angezogener fünffacher Handbremse, um dann irgendwie deine Seite hier zu laden. Um das ruhig mal ein bisschen plastisch zu machen. Der Thorsten streut noch ein bisschen Salz rein. In der Harbing-Folge habe ich mich da offenbart. Da war ich immer hinten dran. Ja, genau. Ja, Blog 840.000. Bei mir noch nicht.

Ja, sehr schön. Wir wollen uns im Thema Silent Payments wenden heute. Und das Ganze ist ein Auftakt zu einer losen Reihe rund um das Thema Privacy, was ja jetzt nochmal an Fahrt gewonnen hat rund um die Entwicklung bei Samurai und den ganzen Auswirkungen, die das Ganze hatte auf verschiedene Walletbetreiber und Coinjoin-Implementierung und und und. Genau, deswegen haben wir gedacht, wäre es nochmal ganz schön, noch ein paar Folgen rund um das

Thema Privacy im engeren und weiteren Sinne zu machen. Heute also der Start mit Silent Payments. Thorsten, was haben wir noch geplant? Wir haben uns auf der Zitadelle ein paar Leute geschnappt und haben gedacht, wir müssen das Thema Joinmarket mal ein bisschen beleuchten, weil ich glaube, wir hatten in 2022 schon mal eine Doppelfolge mit dem Oranged Mike damals noch. Da ging es ja auch so ein bisschen auch um das Thema Sparrow Wallet, Whirlpool und so weiter. Haben wir jetzt ja auch schon immer

wieder hier auch erwähnt. Der Max Hillebrand von CK Snacks/Wasabi war bei uns ja auch schon mal da und da haben wir uns gedacht, ja, Joinmarket fehlt in der besagten Runde, ist ja eigentlich mittlerweile jetzt noch so eine der Coinjoin-Implementierung, die jetzt noch übrig geblieben ist, nachdem Samurai jetzt ja hops genommen wurde und CK Snacks sich ja zumindest mit ihrem offiziellen Koordinator zurückzieht. Das heißt, Joinmarket wird bei uns auf jeden Fall

demnächst auch in einer Folge behandelt werden. Jo, was haben wir noch? Chris, du hast auch noch eine Folge in petto, ne? Ja, genau. Ich wollte mir die ganze Regulierungsgeschichte nochmal angucken und habe dafür wunderbare Gäste. Ich verrate das mal. Und zwar den Loddy und den Efe Cantillon. Den hatten wir ja zuletzt ja schon mal in der Folge. Und da läuft im Hintergrund auch schon ganz viel Vorbereitung. Die nehmen wir nächste Woche auf. Also der lose Arbeitstitel ist "Free Open Source

Money vs. Regulierung". Da sind ja durchaus auch so, im ganz, ganz weiteren Sinne harmonieren diese Themen ja durchaus auch quasi so ein bisschen mit Privacy-Themen, weil er ja schon jetzt dann von quasi der Regulator ja prinzipiell derjenige ist, der vielleicht jetzt hier ein Interesse daran hat, die Privacy bei Bitcoin auszuhebeln oder zumindest aufzuweichen, um da in irgendeiner Form dann Geldwäsche nachzugehen oder ähnliches. Genau. Was haben wir

noch, Jan-Paul? Wir werden auf jeden Fall noch ein Gespräch führen mit dem NetDiver. Der hat ja gerade das 21-Magazin "Bitcoin is Cypherpunk" rausgebracht. Übrigens ein fantastisches Magazin, NetDiver nochmal Hut ab. Also ich lese dieses Magazin sehr, also ich nehme mir wirklich Zeit dafür. Ich setze mich abends dazu hin. Thorsten hält es gerade in die Kamera. Und lese diese

Artikel wirklich sehr genau und muss sagen, es ist ein sehr gelungenes Magazin geworden. Und wir werden mit NetDiver eben über das ganze Thema Cypherpunk sprechen, also vor allem Cypherpunk und Privacy, was da eigentlich zusammengekommen ist. Das ist so unser Vorhaben. Vielleicht wird es auch ein bisschen allgemeiner werden, dass wir so ein bisschen mehr auch zum Beispiel über den

Fall Julian Assange sprechen werden. Genau. Das haben wir geplant. Und dann wollten wir nochmal mit dem Johannes von dem YouTube-Kanal "Bitcoin durchgespielt" auch nochmal eine Folge machen. Das geht so im Moment in Richtung Privacy best practices. Da sind wir aber noch dabei, das Ganze auszuarbeiten. Schauen wir mal, was da am Ende dabei rauskommt. Aber ihr könnt euch darauf freuen. Bei Nodesignal gibt es auf jeden Fall ein paar Folgen rund um das Thema Privacy

in Bitcoin. Kurze Ergänzung dazu. Gerade zu dem ersten Punkt in dem Magazin wurde die besagte, diese Doppelfolge von Matt Orange, Mike Lieber 2022 mit ihm aufgenommen haben, nämlich auch nochmal erwähnt und quasi empfohlen. Ist natürlich jetzt mittlerweile schon in die Jahre gekommen. Und vielleicht können wir uns zumindest die Folge mit Johannes dann so als gedankliches Follow-up oder so ein Update auch für diese Folge mal zu sehen. Weil wir haben da natürlich auch, wie ich eben

schon gesagt habe, viel über Samurai gesprochen. Ist natürlich jetzt aktuell keine Option mehr, deswegen, dass wir das Ganze nochmal auf den aktuellen Stand damit bringen. Genau. Ich bin auf jeden Fall gespannt, was da jetzt dann, was dabei rumkommt. Yes. Das Ganze ist natürlich nur möglich, weil wir ein Value for Value Podcast sind. Ist das so? Nein, also wir sind ein Value for Value Podcast und es würde uns sehr helfen, wenn ihr uns ein bisschen unterstützt dabei,

bei der Arbeit, die wir hier haben. Wir haben so ein paar Kosten, die wir mit euren Spenden, mit eurem Satz finanzieren. Darüber hinaus haben wir immer noch das Bounty-Programm. Das ist so ein bisschen im Hintergrund gerückt gerade, aber wir haben das nicht vergessen. Das ist auf jeden Fall da und wir werden dieses Satz auf jeden Fall auch zurück in die Community geben. Genau. Und das

ermöglicht uns auch, ein werbefreier Podcast zu sein. Also bei uns hört ihr keine Werbung, sondern ihr bekommt bis auf diesen Value for Value Hinweis reinen Bitcoin-Content. Jo. Und damit wollen wir in das Thema der heutigen Folge starten und zwar ist es Silent Payments. Ein Thema, das so ein bisschen gerade am Zahn der Zeit ist. Es ist sehr heiß. Es gab gerade eine sehr aktuelle Folge bei Stefan Levera, wo er Ruben Thomsen und Josie Baig zu Gast hatte

um genau über Silent Payments zu sprechen. Und diese beiden sind quasi maßgebliche Autoren dieses BIP 352. Aber bevor wir da tiefer reingehen, was da jetzt genau drin ist, vielleicht können wir mal erklären, warum brauchen wir eigentlich Silent Payments? Die Frage an euch beiden, Thorsten. Wie können wir das erklären, warum wir dieses Thema überhaupt aufgreifen wollen?

Ich kann ja mal einen Aufschlag machen und Christo darf es dann gerne ergänzen. Also ich glaube, das Grundprinzip wäre ja, wir sprechen von Zahlungen, die wir on-chain empfangen wollen.

Also ganz klar, das hier nochmal abzugrenzen, das hat jetzt nichts mit Second Layer, mit Lightning oder sonst was zu tun, sondern wir bewegen uns on-chain und on-chain ist es ja immer so, dass wir, wenn hier zum Beispiel Jan-Paul eine Zahlung empfangen möchte, muss ich ihn fragen, Jan-Paul, kannst du mir mal eine neue oder eine Adresse geben, an der ich eine Zahlung an dich

leisten kann? Das ist auf der einen Seite manuelle Arbeit, aber auf der anderen Seite macht er das, weil Jan-Paul nicht so ist, wie es vielleicht früher mal gemacht wurde, dass Jan-Paul irgendwann mal eine Adresse generiert hat, die auch seine Webseite gepackt hat und da kann ich dann nach gucken, okay, ich schicke Jan-Paul jetzt dann an die öffentliche Adresse, weil die einfach alle

kennen und die hat er dafür öffentlich, alles super. Warum macht er das? Aus Privatsphäregründen, eben genau deswegen, weil würde Jan-Paul alle Zahlungen auf diese eine Adresse empfangen,

würde man jegliche Zahlungen, die er dann halt darauf bekommt, entsprechend dann auch sehen. Also das dadurch, dass wir in der Timechain alles öffentlich haben, kann sich das auch jeder angucken, wie viel Spenden Jan-Paul dann auch so bekommen, weil wir ja genau wissen, Jan-Paul hat diese Adresse bei sich veröffentlicht, also können wir davon ausgehen, er kontrolliert sie und im gleichen Zuge, ja, können wir auch sehen, okay, Jan-Paul hat jetzt irgendwie in den letzten zwei,

drei Jahren fünf Bitcoin bekommen, okay, super. Also und Jan-Paul hat vielleicht auch noch sein Impressum auf seiner Webseite stehen, also ein prädestiniertes Ziel für eine 5-Dollar-Ranch Attack. Das ist nicht so vorteilhaft und deswegen generiert Jan-Paul im Normalfall immer wieder eine neue Adresse, damit man da keinen Zusammenhang zu den unterschiedlichen Zahlungen herstellen kann

und quasi man immer pro Zahlung eine neue Adresse hat. Ich finde, du hast sehr schön das Problem auf der Empfängerseite beschrieben, aber wir haben ja gesehen, ich glaube der Fall Alex Nawalny ist da ganz prominent, der hatte auch mal auf seiner Webseite zur Unterstützung eine statische Bitcoin Adresse angegeben und da ist das Problem dann tatsächlich auch gewesen, dass auch die Sender identifiziert werden konnten, also weil man natürlich in einer transparenten Blockchain

sehen konnte, von welchen UTXOs sind jetzt eigentlich Funds an die Zieladresse bei Nawalny eingegangen und da haben dann die russischen Behörden anhand von Börsendaten, die sie zur Verfügung hatten, relativ leicht auch die Sender identifizieren können. Also auch das ist ein Problem, das mit statischen oder wiederverwendeten Bitcoin Adressen auftreten kann.

Ja, guter Punkt. Vielleicht, wenn ich das noch ergänzen kann, es gibt im Grunde so ein, du hast es ja schon aufgezeigt, so ein Spannungsfeld zwischen Interactivity und Privacy. Also Interactivity ist das, was du geschildert hast, man muss interagieren oder muss aktiv sein. Jan-Paul würde jedes Mal eine neue Adresse generieren und dir eine andere geben als mir und dadurch seine Privacy hochhalten. Also ich weiß nicht, was du Jan-Paul geschickt

hast. Umgekehrt weißt du das auch nicht, aber Jan-Paul muss aktiv sein und eine neue Adresse schicken. Das ist also die Interactivity. Ist die hoch, ist die Privacy auch hoch. Ist die Interactivity niedrig, wie mit dieser statischen Adresse, ist auch die Privacy niedrig. Was aber eigentlich wünschenswert wäre, wenn man gar nicht so viel Interactivity haben müsste, sowas wie eine statische Adresse, also Interactivity niedrig und dabei gleichzeitig Privacy hoch. Und ich glaube,

das ist so ein bisschen das, was dann abtropft, die Fragestellung. Wie kriegt man das gelöst? Und das ist das, da kommen wir jetzt gleich drauf mit Silent Payments. Ja, ich würde noch gerne eine Sache ergänzen. Das habe ich jetzt auch aus dem, ich glaube aus dem Stefan-Livera-Podcast. Packen wir euch in die Show, das hört sich als eine sehr interessante, allerdings auch sehr, sehr tiefgehende Folge geworden. Aber da ist noch mal klar gemacht

worden, dass wir natürlich auch ein UX/UI-Problem haben. Denn, stell dir vor, du bist ein neuer Bitcoin-User und du siehst, okay, ich habe jetzt hier das erste Mal Bitcoin empfangen auf einer Adresse. Und beim nächsten Mal zeigt dir dein Wallet irgendwie eine andere Adresse an. Da musst du ja als Neuling, der du das nicht weißt, das ist sowas wie Adress Reuse solltest du nicht machen, das ist Best Practice. Für den ist es ja super verwirrend, wenn er jedes Mal eine neue Adresse

ausgeben muss. Und es wäre quasi aus dieser User Experience heraus, wäre es ja viel schöner, wenn ich nur eine Adresse habe, auf die ich meine Zahlung empfangen kann und trotzdem gleich sofort Privacy von vorne rein habe. Ja, das wäre ja genau das Szenario, was ich gerade eben beschrieben

habe. Dass du dann bei dir auf deiner Webseite dann einfach diesen Zahlungs- oder diesen Empfangscode dann halt veröffentlichen kannst, der dann keine eigentliche Adresse ist, die man jetzt irgendwie dann in irgendeinem Block Explorer oder sowas nachschauen kann, aber gleichzeitig dann quasi ohne dein Zutun von den Sendern verwendet werden kann. Und das ist ja, glaube ich, hier dann wirklich dann das, was Chris auch gerade schön beschrieben hat, dieses Spannungsfeld zwischen

Aktivität und Privatsphäre. Dass wir da einfach so quasi von beiden eigentlich das Beste aus beiden Welten bekommen. Und das ist, glaube ich, so ein bisschen so, dass vielleicht das Grundziel dann auch wirklich dann von Silent Payments hier oder was versucht wurde, zu erreichen. Es gibt ja noch die Möglichkeit, das mit einer automatisierten oder semi-automatisierten Lösung zu machen.

Zum Beispiel, wenn jetzt der Thorsten mein Arbeitgeber ist und der bezahlt mir mein Gehalt in Bitcoin und würde das jetzt nicht über Lightning machen, sondern das Geld ist so hoch, dass sich das on-chain lohnt. Thorsten ist ja großzügiger Arbeitgeber. Dann könnte ich dem Thorsten ja meinen XPAP geben, Extended Public Key. Und der Thorsten hätte im Grunde dann die

Möglichkeit, jedes Mal eine neue Adresse zu generieren. Das ist so was, was man zum Beispiel bei Pocket machen kann, wenn man da ein DCA hat, dass man von der Wallet den Extended Public Key dort hingibt auf deren Server. Und die generieren jedes Mal eine neue Adresse, wenn sie dir was schicken. Du hast damit zwei Probleme. Einmal dockst du deine Privacy. Also der Thorsten weiß

dann immer, was alle Adressen aus diesem, ja, aus diesem Key, was da drauf geschickt wird. Und das andere ist, dass, wenn da jetzt irgendwas fehlerhaft wäre an dem Server, man nicht mehr nachvollziehen kann, ob das wirklich meine Adresse ist. Wobei, ja, wenn du den XPAP bekommen hast, daraus kannst du ja eigentlich schon eigentlich, dann weißt du ja eigentlich, dann welche Adressen daraus abgeleitet sind. Oder nicht, wenn du jetzt, wenn du die Basis halt hast als Arbeitgeber in

dem Fall. Nur, wenn ich jetzt dein Arbeitgeber wäre, weiß ich ja, da können diese Adressen aus abgeleitet werden. Und wenn das halt einmal funktioniert hat und das bei dir angekommen ist, dann kann ich ja davon ausgehen, dass es auch in Zukunft so funktionieren wird. Das stimmt. Es gibt noch ein anderes Problem und zwar ist es das Gap Limit. Also du kannst ja mit dem XPAP ganz viele, nahezu unendliche, unendlich viele Adressen generieren.

Und es gibt das sogenannte Gap Limit Problem. Also wenn da zum Beispiel fünf Adressen oder zehn oder zwanzig oder hundert Adressen nicht benutzt sind und es gibt halt eine Lücke, dann kann der Empfänger beziehungsweise der Sender kann nicht mehr die ganze Blockchain scannen, um zu gucken, ob alle Adressen, also welche Adressen benutzt wurden.

ohne jetzt irgendwie im National zu treten, vielleicht dann zu viel ist und dass das deswegen vereinfacht wird. Ich erinnere mich, dass das bei der Bitbox App, also die quasi die App, die mit der Bitbox mit ausgeliefert wird als Software, ist das, glaube ich, auch relativ überschaubar, was man da an Adressen sich explizit anzeigen lassen kann.

Und als Empfänger, ich muss nicht irgendein System ständig online haben, das diese Adressen bereitstellt, sondern aufgrund von geschickter und intelligenter Mathematik sind wir in der Lage, sowohl der Sender als auch der Empfänger sind in der Lage, die Adressen mit den Informationen, die sie zur Verfügung gestellt bekommen haben, quasi on the fly zu errechnen. Und so, dass man so dann durch die kryptographischen Kniffe, ja, die Zahlung oder diese Adresse

ableiten, wie auch immer kann, und dass dann, dass die Zahlung dann auch erfolgen kann. Dass in dem Fall dann ich Jan-Paul auch was schicken kann. Wie wir gleich sehen werden, ist es nicht ganz, ganz ohne, wie sagen wir mal, Proof of Work oder ganz ohne Kosten? Das will ich jetzt noch nicht vorwegnehmen. Ja. Genau. Es hat auch eine Down-Zeit.

Ja, also genau. Es hat auf jeden Fall Trade-offs, da werden wir später noch dazu kommen. Aber ich würde ganz gerne nochmal versuchen, dass wir, das ist das Problem, glaube ich, das haben wir jetzt versucht klarzumachen. Es gibt so statische Adressen, sind ein Problem, weil du Privatsphäre verlierst. Es ist ein hoher Aufwand, wenn du einen BTC-Pay-Server betreibst. Es hat Privacy-Implikationen,

wenn du einen XPAP ausgibst und so weiter. Also gibt es eine Menge Probleme. Und was Silent Payments eigentlich erreichen wollen, sind sogenannte wiederverwendbare Zahlungscodes. Das heißt, du hast einen Zahlungscode, der beliebig oft wiederverwendet werden kann, von mehreren Absendern und auch mehrfach nacheinander, ohne Privatsphäre-Verluste und ohne das Thema Online-Kommunikation, ohne diese Interaktivität. Also wiederverwendbare Zahlungscode

gibst du einmal raus. Also ich gebe euch quasi, Thorsten und Chris, einfach mal meinen Zahlungscode und den könnt ihr immer wieder verwenden, um mir Sats zu schicken, ohne dass meine oder eure Privacy verloren geht und ohne dass ihr irgendwie interaktiv mit mir kommunizieren müsst. Reicht es so? Erstmal so als High-Level, was ist quasi der Use-Case von Silent Payments?

Stefan Livera hat das in der Folge Bitcoin-User-Name genannt. Ich glaube, das ist technisch nicht richtig, aber im Grunde so ein bisschen das, was es sein soll. Es geht ja schon. Also ich weiß nicht, inwieweit wir als nächstes Thema hatten wir für uns ja so quasi ein bisschen die Historia davon aufgeschrieben. Vielleicht, um da schon ein bisschen vorweg zu greifen, dieses BIP740, was ja auch von Sparrow und der Samurai Wallet implementiert war. Das war

ja auch dann quasi auch so Zahlungskurs, die wiederverwendbar waren. Und die Manifestierung, nenne ich es jetzt einfach mal, waren ja auch immer diese NIMS. Das heißt, das war auch immer so ein kurzer Code mit einer Zahl hinten dran und auf dieser Basis wurde dann so ein Avatar generiert. Und das ist ja im Endeffekt auch schon so ein bisschen, was du gerade beschrieben hast. Das ist ja schon so eine Art, ja, das ist mein Avatar, mein persönliches Profil. Und so ein

bisschen geht es ja dann auch so in die Richtung. Deswegen ist vielleicht so eine Abstraktion, all das als Username zu bezeichnen, gar nicht mal so falsch. Finde ich super. Vielleicht können wir das später nochmal aufgreifen, wenn wir das so ein bisschen durchgearbeitet haben, was da eigentlich passiert. Weil ich glaube, dass dieser Gedanke, dass das als Username quasi in Bitcoin zu verwenden, super interessant ist.

Also das ist wirklich das, was Silent Payments für mich sehr, sehr spannend gemacht haben. Aber wir wollten vielleicht vorher nochmal kurz aufgreifen, dass das Thema dieser wiederverwendbaren Zahlungscodes oder Reusable Payment Codes, das ist jetzt nichts Neues in Bitcoin. Nur so einen ganz kurzen Abriss. Das wurde bereits sehr früh, also 2011 im Bitcoin Talk Forum haben wir so einen, wie nennt man das, so einen Forumpost gefunden,

wo bereits über Stealth-Adresses gesprochen wurde. Stealth, wie übersetzt man Stealth auf Deutsch? Tarnkappe getarnt, also verheckt. Ja, ja, ja, genau. Genau, genau. Also getarnte Adressen, genau. Also das Thema ist schon relativ früh, zumindest im Bewusstsein, dass wir so etwas benötigen. Dann gibt es das BIP63 nach Vorschlag von Peter Todt, dass irgendwie das Ganze ans OP-Return bindet. Ich will da gar

nicht so tief reingehen. Dann gab es Payments, das BIP47, das der Thorsten kurz schon angedeutet hatte. Da werden wir auch, glaube ich, später in der Folge nochmal kurz drüber sprechen, im Vergleich zwischen Payments und Silent Payments. Und es gibt jetzt noch neben dem BIP352 gibt es jetzt auch noch das BIP351, Private Payments. Das bleibt heute ein bisschen außen vor. Vielleicht können wir das später nochmal aufgreifen in einer neuen Folge. Das

ist so ein bisschen ein Kompromiss zwischen Payments und Silent Payments. Ich will da gar nicht drauf reingehen, aber da gibt es mehrere Versuche eigentlich, um reusable Payment Codes zu implementieren. Und wir gucken uns heute dann Silent Payments an. Wollt ihr dazu noch was ergänzen? Habe ich irgendwas vergessen, was noch wichtig wäre jetzt in diesem kurzen historischen Abriss? Hast du gut gemacht. Ja, im Wesentlichen beruht das ja alles auf diesem Diffie-Hellman-Schlüsselaustausch.

Ja, elliptische Kurven, Kryptografie. Ich packe nochmal den Wiki-Link dazu in die Shownotes. Ich glaube, das ist da ganz gut beschrieben. Ich hätte mir das nochmal angeguckt extra. Und das sind alle die Dinge, die du genannt hast, die beruhen da drauf. Das ist ja einer der wesentlichen Elemente in, entschuldige Thorsten, dass ich jetzt drüber schwätze. Das ist ja eines der wesentlichen, wie sagt man, Primitives in Bitcoin, dieser

Diffie-Hellman-Key-Exchange. Das ist ja quasi eine der Grundlagen, wie das überhaupt funktionieren kann. Also wie die Kryptografie mit privaten und öffentlichen Schlüsseln funktionieren kann, sodass du auf einen öffentlichen Schlüssel etwas empfangen kannst, ohne dass jemand, der den öffentlichen Schlüssel kennt, auch diese Funds darauf ausgeben kann.

Es wird ein bisschen ergänzt um diese Shared-Secret-Geschichte. Das kommt ja auch zum Tragen bei den Silent-Payments, dass du so ein Shared-Secret hast, das du zwischen den Partnern generierst. Ich glaube, in der Podcast-Folge von Bitcoin Explained, wo auch Ruben Samson, also auch der einer der Entwickler, Samson, ja. Ich denke irgendwie immer an den, wenn ich den Namen höre, denke ich immer an Samson Mouw gleichzeitig. Ich meine, das sind komplett

unterschiedliche Typen, aber da muss ich trotzdem irgendwie mal dran denken. Aber in dem Podcast von Bitcoin Explained auch von Aaron von Vierdom und wer ist der zweite, der da mit sich geht? Jos Prowosz. Jos Prowosz oder so. Genau, die niederländischen Kollegen auf jeden Fall von Bitcoin Explained. Und da hat einer von beiden, ich weiß nicht wer es war, hat auf jeden Fall das Beispiel gemacht, dass man sich das gut vorstellen kann, wenn man sich an einer Webseite anmeldet, um quasi

eine Verschlüsselung zu einer Webseite aufzubauen. Da findet im Endeffekt auch dieser Schlüsselaustausch statt und dadurch, dass beide in Anführungszeichen quasi einen öffentlichen Schlüssel dann haben, ich als jemand, der auf die Webseite zugreift, die Webseite selber hat auch einen und da findet dann dieser Schlüsselaustausch ausstand und so wird die Kommunikation zwischen mir und der Webseite dann halt verschlüsselt, indem da halt dann dieser Diffie-Helmet-Schlüsselaustausch

stattfindet, weil, wie es Chris gerade schon gesagt hat, dieses shared secret, daraus dann jeder von sich ableiten kann und so man die Kommunikation dazwischen dann halt privat machen kann. Ja, das ist ein gutes Beispiel, weil es auch Alltagstauglich ist, man quasi ständig macht. Ja, auf jeden Fall. Lass uns auf jeden Fall die Folge in die Shownotes stecken. Ich suche gerade hier die Bitcoin Explained-Folge. Ja, pack mal rein.

Ja, packen wir auf jeden Fall rein. Und noch einiges mehr. Also wir haben in der Vorbereitung glaube ich einige Links gesammelt. Packen wir euch alles rein. Es gibt eine sehr schöne Übersichtsseite, SilentPayments.xyz von Seth for Privacy, der hat das glaube ich aufgesetzt, die das wirklich wunderbar erklärt. Da gibt es eine Startseite, da ist es nur quasi, was

bringen uns SilentPayments. Und wenn einen das tiefer interessiert, gibt es da oben rechts auf der Seite einen Button, da "Learn more", kann man draufklicken und da findet man tatsächlich noch ein paar mehr Erklärungen und auch weiterführende Links. Genau, das war quasi unsere Quelle für unsere, oder unsere Primärquelle für die Vorbereitung dieser Folge. Genau.

Ganz kurz, Ergänzung dazu finde ich spannend. Der besagte Seth for Privacy hat auch 2022 schon sogar schon einen Artikel im Bitcoin Magazine geschrieben, auch schon der im Endeffekt genau das beschreibt, worüber wir jetzt gerade reden. Also das Thema ist auch schon ein bisschen länger jetzt schon aktuell, aber hat scheinbar bisher noch nicht so richtig Fahrt aufgenommen. Da liegt ja das Grundprinzip auch noch mal da. Kann man auf jeden Fall auch nochmal in

die Shownotes mit reinpacken. Das fand ich ganz gut, um so quasi mal um das Thema reinzukommen und auch schon zu sehen, wie war der Stand vor zwei Jahren und wie hat sich es vielleicht jetzt so jetzt heute schon ein bisschen weiterentwickelt in der letzten Zeit? Das können wir vielleicht noch ganz kurz erzählen. Also diese Idee kommt von Ruben Somsen, den wir hier schon mehrfach erwähnt hatten. Also auch ein, ich glaube auch ein

Niederländer Bitcoin-Core-Entwickler. Und der hatte 2022 diese Idee mal in den Raum gestellt. Und nach meinem Verständnis ist jetzt quasi diese Idee in ein Büchel gegossen worden und auch nicht implementiert worden, sondern quasi die Spezifikation ist fertig. Das heißt, es ist jetzt erst nach zwei Jahren Arbeit quasi so weit, dass überhaupt Wallets diese Silent Payments implementieren können. Ja, guter Punkt. Ist vielleicht dann auch noch, wenn man schon direkt dabei ist, wir

haben eine Spezifikation. Und gleichzeitig kann man vielleicht auch an der Stelle schon mal sagen, es braucht keine Konsensänderung, um das einzuführen. Es braucht keine großartigen neuen Opcodes oder sonst irgendwie sowas. Das funktioniert jetzt, seitdem wir Taproot haben, auf darauf basiert es primär, funktioniert das schon quasi super jetzt auch schon im Mainnet. Das heißt, Wallets können es jetzt und implementieren es zum Teil auch schon

in gewisser Weise. Also wir sehen da jetzt auch schon die ersten, die das dann jetzt eingebaut haben. Also von der Perspektive gibt es da keine Restriktionen, dass man da jetzt noch auf irgendwas warten müsste, was jetzt irgendwie jetzt noch im Bitcoin-Hauptnetzwerk veröffentlicht werden müsste. Wie es bei so vielen anderen Sachen im Bitcoin-Netzwerk ja auch schon häufig ist, dass da irgendwelche Opcodes oder sowas fehlen oder Dinge dann erst überhaupt möglich machen.

Ja, super. Ich glaube, dann haben wir den historischen Abriss geleistet und versuchen

uns jetzt mal der Frage zu nähern, wie funktionieren eigentlich die Silent Payments. So, und das Ganze fängt mit etwas an, wo wir gerade im Vorgespräch auch schon schwer gerätselt haben, wie es denn eigentlich funktioniert. Wir müssen nämlich irgendwie ja diesen wiederverwendbaren Zahlungscode generieren, also diesen Silent Payment Code. Ich weiß nicht, mag einer von euch mal versuchen, was so die grundlegende Idee seiner Meinung nach ist, wie das funktioniert

mit dem Silent Payment Code. Es traut sich keiner, ich weiß, es ist schwierig. Wir können aber auch jederzeit sagen, so hey Leute, das haben wir jetzt auch nicht in aller Tiefe verstanden. Wen es tiefer interessiert, der kann sich gerne das BIP 352 anschauen. Wir verlinken den Link zum GitHub, wo das drinsteht. Da könnt ihr euch das im Detail nochmal anschauen. Wollen wir es trotzdem versuchen.

Ich kann ja mal ganz, ganz, ganz oberflächlich anfangen. Also dieser Zahlungscode fängt an mit SP, ich glaube Q. Das sind quasi so wie wir es bei… SP1. SP1, okay. Genau, SP1Q. So fangen die immer an. SP1Q, also quasi ähnlich wie wir auch Bitcoin-Adressen kodieren. Da haben wir ja auch mit BC1Q zum Beispiel oder BC1T, ne, das sind Teperate-Adressen. Doch, ne? Egal. Ihr wisst auf jeden Fall, die kodierten… BC1P. BC1P, genau. Nicht T, sondern P. Die haben ja quasi dieses standardisierte Format, was

dann für Menschen lesbar gemacht wird. Dahinter verbirgt sich natürlich ein Public Key, der halt entsprechend dann in diesem Adressformat kodiert wurde. Und das gleiche haben wir bei diesem SP-Code auch, dass dahinter auch, ja, was anderes steckt, als das, was da eigentlich nach vorne raus dann halt in diesem SP-Format dann dargestellt wird. Aber, was wichtig ist, wie kommen wir jetzt denn jetzt zu diesem SP-Format? Oder was gibt es da für Komponenten,

um diesen Code zu generieren? Also, oder diese Schlüssel. Also es gibt ja nicht nur einen Schlüssel. Also, das war ja meine, mein erster Guess, den ich eben ja so in unserem Vorgespräch reingebracht habe, dass ich sage, okay, ich mache ein Private Key, mache daraus ein Public Key und kodiere das dann in diesem SP-Format fertig. Aber so einfach ist es ja nicht. Ja. Wie komme ich dazu? Ich muss ja irgendwie in der Lage sein jetzt zu sagen, okay, hier

ist mein Silent Payment Code. Also, ich, Jan-Paul, sage, lieber Thorsten, lieber Chris, hier ist mein Silent Payment Code. Wie komme ich da hin? Und ich glaube, es ist etwas, also das Prinzip hat Thorsten ja schon beschrieben. Wir brauchen einen Private Key natürlich und daraus leiten wir ein Public Key ab. Und das ist quasi, das ist die Grundvoraussetzung. Ich glaube, der wesentliche Unterschied ist, dass wir bei diesen Silent Payments zwei Private

und auch zwei Public Keys haben. Zum einen ist es der sogenannte Scan Key, also der Empfänger Scan Key und der Empfänger Spend Key, sowohl Private als auch Public. So, diese beiden brauchen wir und dann können wir daraus quasi diesen Silent Payment Code ableiten. Ich weiß, das ist jetzt super abstrakt gewesen, aber ich glaube, darauf läuft es am Ende hinaus, dass wir quasi zwei Private Keys und zwei Public Keys haben, aus denen wir diesen Silent

Payment Code ableiten. Und das ist quasi der dritte Bestandteil, das dritte Level an Zahlungsinformation, das wir generieren, nämlich den Silent Payment Code oder Receiver Key oder wie auch immer man das nennen möchte. Das ist das, was der Empfänger halt rausgeben kann. Und im Gegensatz zu dem Public Key, den ich dir jetzt geben würde, wenn, ja, oder wenn ich dir jetzt eine Adresse geben würde, dann würde ich ja mich sozusagen doxen auf der Blockchain. Das

passiert da nicht. Ja, doch, am Ende schon. Vielleicht können wir auch da schon zum Senden an einen Silent Payment Code übergehen, oder? Also ich glaube, wichtig ist, dass wir halt, das, was wir gerade beschrieben haben, dazu führt, dass wir nachher einen statischen Zahlungscode haben, der halt mit SP1 und dann eine lange Zahl oder einen langen Wert kodiert ist. Und den können wir dann nehmen, um dahin dann quasi Funds zu schicken. Aber damit wir in dem Fall

jetzt, ich möchte Jan-Paul was schicken. Jan-Paul hat diesen Zahlungscode, den wir gerade beschrieben haben, generiert, schicken kann, brauchen wir noch ein paar Informationen, um für diese explizite Transaktion, die ich Jan-Paul jetzt quasi ein paar Passats schicken will, reingeben muss, damit ich

die für mich oder für diese explizite Transaktion richtige Empfangsadresse ableiten kann. Und das ist jetzt, glaube ich, das, was jetzt wichtig ist, dass wir da nicht nur quasi, wir haben ein Ding, leiten das ab, fertig, sondern wir haben jetzt quasi eine Basis, auf der wir dann jetzt auch noch Informationen von uns reingeben. Und auf diese Basis, da landen wir dann effektiv dann

nachher bei einer Adresse, die dann unser Ziel effektiv ist. Und was das steht jetzt, die Magic, die dann da passiert, ist, dass ich das als Sender ermitteln kann und gleichzeitig aber Jan-Paul das als Empfänger genauso ermitteln kann mit den Informationen, die er bekommen hat, und dass wir beide quasi zum, beide wieder zu dieser gleichen Adresse zurückfinden und Jan Paul so identifizieren kann, aha, okay, ich habe ihm hier was geschickt. So. Welche Komponenten

sind denn jetzt wichtig? Genau. Also es gibt genau, es gibt drei Inputs für die Adressgenerierung. Also, wir nehmen den Fall, also, sollen wir es mit Alice und Bob machen? So steht es auch in den ganzen Überschreibungen in Bitcoin. Genau, wir sprechen natürlich über Alice und Bob. So, Alice möchte an Bob Satoshis schicken. So, Bob ist also der Empfänger. Bob hat eine Silent-Payment-Code generiert und an Alice gegeben. Und jetzt möchte Alice eine Transaktion ausführen.

Sie muss irgendwie die Zieladresse festlegen. Und das macht sie bei Silent Payments, indem sie drei Informationen zusammenträgt. Das erste ist, das einfachste ist, glaube ich, Bobs Pubkey. Den kann er ableiten. Das steht in diesem Silent-Payment-Code, steht dieser Pubkey drin. Das kann die Alice für sich ableiten. Das zweite, was sie braucht, ist der Pubkey, beziehungsweise sind die Pubkeys der auszugebenden UTXOs. Also die UTXOs, die Alice verwenden möchte, um eine Transaktion an Bob

durchzuführen. Das ist der zweite Bestandteil. Und dann der dritte Bestandteil ist ein sogenanntes Shared-Secret, also ein gemeinsames Geheimnis, das generiert wird aus dem öffentlichen Schlüssel, aus dem Silent-Payment-Code, also aus Bobs Silent-Payment-Code und dem privaten UTXO-Schlüssel des Benutzers. Und das läuft dann halt wieder, das hatten wir, glaube ich, eben schon über diesen

Diffie-Hellman-Key-Exchange. Genau. Das Ergebnis ist, also wenn ich diese drei Inputs nehme, also den Bobs Pubkey, die Pubkeys der UTXOs von Alice, die sie für die Transaktion verwenden möchte, plus das Shared-Secret, das ergibt eine Taproot-Adresse. Und an diese Taproot-Adresse schickt am Ende Alice ihre Funds. Das heißt, wir sehen also, wenn wir eine Transaktion sehen, also in der Blockchain eine Transaktion sehen, dann sehen wir nicht irgendwie als Empfangsadresse einen

Silent-Payment-Code, sondern eine Taproot-Adresse. Das ist das Ergebnis, das dabei herauskommt.

Genau. Und wir haben keinen Zusammenhang mehr. Also Leute, die von extern auf diese Taproot-Adresse sehen, können so gesehen nicht mehr auf den Zahlungskurs zurückführen, weil ihnen halt diese Informationen, wir haben es gerade gesagt, die Private Keys für die UTXOs, die Alice hier versendet hat, die hat nur Alice und dementsprechend kann halt niemand, hat halt alle Informationen, also kein Dritter, in dem Fall Carol, glaube ich, ja Carol ist ja immer die, die dritte Person,

die hat jetzt quasi der fehlende Information, um zu sehen, aha, okay, da kommt das ursprünglich her, wobei ich gar nicht weiß, ob das überhaupt sowieso funktioniert, ob man das, ob man das zurückrechnen kann. Wahrscheinlich nicht, aber was mir noch mal gerade aufgefallen ist, dadurch, dass wir die Pubkeys der UTXOs verwenden, das sorgt nur dafür, dass ich unendlich viele abgeleitete Taproot-Empfangsadressen generieren kann. Das ist quasi, das ist der variable Bestandteil

in dieser Gleichung, wenn ich mir die Taproot-Adresse von Bob ausrechnen möchte. Also ist klar, jedes UTXO hat irgendwie, also jedes hat natürlich einen anderen Pubkey, hoffentlich, und deswegen führt das immer zu einem anderen Ergebnis in der Taproot-Adresse. Ja und hier das Shared Secret ist auch für jede Transaktion. Aber Shared Secret ist aber immer gleich, oder nicht?

Da steht jetzt ja den Private UTXO-Schlüssel des Benutzers mit. Also das ist ja quasi auch wieder die UTXOs, die in diese explizite Transaktion reingegeben werden, würde ich jetzt vermuten, weil die sind ja auch variabel. Ja, ich habe jetzt gedacht, das wäre auch eine Konstante, aber nee, das stimmt. Das einzige Konstante ist der Zahlungscode. Also Bob's Pubkey ist quasi das einzige Konstante dabei. Genau, der Silent Payment Code, den er dann bereitstellt. Was ja gut ist,

dass das die einzige Information ist, die halt irgendwie fix ist. Alles andere sorgt für Entropie, wie auch immer, oder ist halt quasi, dass es nicht von Fremden dann auch erkannt werden kann, weil wir zu viele Faktoren haben, die wir nicht wissen. Ja, ich glaube, das reicht auch, oder? Also jetzt für das Thema, wie generiere ich mir jetzt die Empfangsadresse? Genau, das haben wir jetzt, glaube ich, drin. Ja, absolut. So und jetzt ist natürlich die Sache, wie findet Bob raus,

dass er denn eine Zahlung bekommen hat? Weil Bob würde jetzt ja, müsste man jetzt ja vorausnehmen, wir haben gerade eben von dem Shared Secret gesprochen und Bob müsste jetzt ja natürlich dann auch diese Berechnung dann auch machen, damit er weiß, aha, okay, also Bob kennt ja diese Taproot-Adresse, die Alice in dem Moment generiert hat, kennt Bob ja selber noch gar nicht, weil er die Inputs, die Alice verwendet hat, zum Zeitpunkt der Erstellung des Zahlungscodes ja

nicht kennt, weil sie ja immer quasi on the fly berechnet wird. Das heißt, wir haben hier eigentlich, dass Bob immer wieder Rechenleistung aufbringen muss, um quasi auch zu dieser Taproot-Adresse zu gelangen, mit den Informationen, die er natürlich durch die Transaktion bekommen hat.

Und das ist vielleicht jetzt auch nochmal dann auch ein Trade-off, finde ich, von Sunside and Payments, der dann da jetzt dann mit reinkommt, dass wir quasi Rechenleistung erzeugen müssen, weil wir ja quasi die gleiche Rechnung in Anführungszeichen dann auch nochmal machen müssen, um mit dem empfangenden Satz zu kommen. Und die Rechenleistung kann er eigentlich nur

vollbringen, wenn er eine eigene Node hat. Genau. Weil er muss die Blockchain scannen. Also er weiß natürlich, keine Ahnung, die Transaktion ist in Block, was weiß ich, kurz vor dem letzten Halving passiert, dann weiß er ja, ab welchem Block er scannen muss. Er muss jetzt nicht die ganze Blockchain scannen, aber von da an muss er durchscannen. Und wenn dieser Silent Payment Code lange online ist, dann muss er eben die ganze Zeit durchscannen, ab dem Moment, wo dieses Ding online

ist. Und das geht eigentlich nur mit seiner eigenen Node, oder er muss sich eben auf jemanden verlassen, der das für ihn macht. Das ist aber bis jetzt, glaube ich, noch nicht so richtig implementiert. Aber warum brauche ich dafür eine eigene Node und kann ich irgendeine andere Node von irgendjemand anderem benutzen? Weil das ist für mich im Endeffekt den gleichen Service, also ob ich jetzt dann meine eigene, die hier lokal bei mir läuft, als quasi Ort der Quelle verwende oder eine andere.

Klar muss ich denen natürlich vertrauen, das ist nochmal ein anderes Thema, aber die Bereitstellung der Daten kann ja auch dann irgendeine öffentliche Node machen. Ja, aber dann hast du da irgendwie total viele Leute, die da drauf irgendwie rumscannen von außen. Das ist ja auch Netzwerk und Bandweite. Also wenn ich das auf meiner eigenen Node mache, dann mache ich das ja lokal. Ja, aber den Traffic hast du ja so oder so. Du musst ja die, also vielleicht nochmal,

wir sind schon echt ein bisschen, schon wieder einen Schritt zu weit. Ich würde ganz gerne nochmal versuchen, die Zohrer nochmal abzuholen. Also was macht Bob jetzt? Bob hat zu einer bestimmten Blockhöhe diesen Payment Code rausgegeben und jetzt weiß er natürlich nicht, welche Transaktionen auf auf seinen Payment Code eingegangen sind. Um das zu machen, also um zu sehen, welche Funds er denn jetzt erhalten hat, muss er sämtliche Blöcke und sämtliche Transaktionen quasi scannen und

überprüfen, ist es vielleicht eine Transaktion, die an mich ging. Und das macht er, indem er nochmal diese ECDH, also Ecliptic Curve, diese Kalkulation durchführt. Das heißt, genau, genau, also Ecliptic Curve, die vier Hellmann-Berechnungen durchführt, um zu prüfen, ob diese Transaktion eventuell oder das Output eventuell ihm gehört.

Genau, weil vielleicht, um das nochmal so rund zu machen, weil er zum Zeitpunkt der Erstellung des Zahlungscodes nicht weiß, auf welchen Adressen er zukünftig was empfangen wird, weil das halt abhängig ist von den Inputs, die die Leute zuschicken. Während du traditionell würdest du ja mit HD Wallets, würdest du ja wissen, okay, ich habe die und die Adressen, die ich mir aus dem Wallet generieren kann. Und da habe ich

jetzt was weiß ich, irgendeinen Automatismus, der immer die nächste Adresse nimmt. Da weiß ich, wo ich suchen muss. Aber das weißt du jetzt nicht mehr. Du musst jetzt irgendwo suchen. Im Moment hat man den Vorteil, das sind nur Taproot-Adressen und es muss eigentlich nur Taproot-Adressen scannen. Aber du musst eigentlich ab der Erstellung dieses Payment-Codes, musst du

zeitmäßig in die, nach vorne, also zu deiner Gegenwart das scannen. Irgendwo dann in der, in irgendwelchen Transaktionen, in irgendwelchen Blöcken. Genau, es gibt halt so ein paar, du hast es gerade schon beschrieben, so ein paar, sag ich mal, Möglichkeiten oder Optimierungen. Da wird aktuell, glaube ich, auch noch relativ viel daran gearbeitet, so wie ich das verstanden habe, genau in diesen Optimierungen, um diesen

Computing-Aufwand so minimal wie möglich zu halt machen. Das ist halt ein Punkt, dass man halt diesem Sign-in-Payment-Code dann halt einen Geburtstag in Anführungszeichen halt gibt. Und dann, was dann heißt, okay, ab diesem Geburtstag, ich gucke erst ab dann und dann in die Zukunft. Ich gucke mir nur Taproot-Adressen an. Idealerweise ist das momentan ja noch alles,

es ist eine gute Optimierung für aktuell, hat der Ruben auch ein paar Mal gesagt. Aber in Zukunft wird es wahrscheinlich, wenn wir nur noch Taproot-Adressen haben, dann ist diese Optimierung auch obsolet, weil dann haben wir halt nur noch, dann bringt uns das auch nichts mehr. Aber da gibt es halt jetzt auch noch so unterschiedliche Ansätze, wie man da halt effizienter an die eigenen

abgeleiteten Taproot-Adressen dann kommt. Ja, aber ich denke, es ist wichtig festzuhalten, also wenn ich ein, oder wenn ich Bob wäre und einen Sign-in-Payment-Code generiere, dann bringt das hohe Rechenkosten einfach mit sich oder Computation, Computing-Kosten einfach mit sich, weil ich halt mit meiner Node, ich habe hier so einen schwachbrüstigen Raspberry Pi 4 mit 4 Gigabyte bei mir auf dem Schreibtisch stehen, der muss quasi, also der lädt sich die Blöcke

runter, validiert natürlich die Transaktionen, die da drin sind, das ist ja eine Aufgabe, die er macht und dann muss er noch mal quasi berechnen, ist denn jetzt eines dieser Transaktionen, die zwar nur, also ich schaue mir zwar nur die Taproot-Transaktionen an, aber ist denn eine

dieser Transaktionen etwa eine, die mir FANZ hat zukommen lassen? Das erklärt vielleicht dann auch jetzt gerade eine Frage, die mir gekommen ist, die ich mir aber gerade im Kopf selber beantwortet habe, dass wir auf der Node-Seite keine dedizierte Software dafür brauchen, die irgendwie also so ein Kompagnonpart zu der Wallet, die halt dann irgendwie diese bestimmte Berechnung halt macht, sondern diese Berechnungsanfrage wird dann im Endeffekt von der Wallet dann durchgeführt,

die dann Silent Payments implementiert hat, oder? Ja, ja, genau. Also genau, das müssen die Wallets, müssen das implementieren, dass du quasi, also das, ich weiß nicht, da kennst du dich besser aus, ich erzähle jetzt wahrscheinlich Quatsch, aber die müssen quasi die, weiß nicht, irgendwie Libraries oder was auch immer da zur Verfügung steht quasi implementieren in ihre

Wallet, um halt diese Kalkulationen durchzuführen. So ungefähr stelle ich mir das jetzt zumindest vor, dass sie irgendwas… Es ist ja irgendwie eigentlich wieder so eine Funktionalität von dieser von dieser XPAP-Suche, die Chris gerade eben beschrieben hat, bei so einer Standard-HD-Wallet, die ja dann da stattfindet, sondern da gibt es halt dann jetzt eine andere Art und Weise, wie dann halt Adressen generiert werden oder abgeleitet werden und das ist dann halt dieser

Berechnungspfad, der dann da angewandt wird. Es ist einfach nur ein anderer Algorithmus, der dann dafür verwendet wird vermutlich. Stimmt, das… Ich wollte nur kurz ein Beispiel noch erzählen. Ich habe heute tatsächlich noch mal meine Sparrow Wallet aufgemacht, die mit meinem Electrum-Server verbunden ist und jedes Mal, wenn ich quasi eine Wallet da reinlade, dann sieht man unten in diesem Info-Fenster, dass er erst mal nach Transaktionen scannt. Also das ist genau das…

Genau, genau. Das ist das, was da passieren wird, wahrscheinlich auch mit Silent Payments.

Ja, genau. Das ist genau… Das ist vielleicht nur eine Frage, dass da vielleicht dann so was wie der Electrum-Server oder wie Fulcrum, also im Endeffekt diese Indexer für die HD-Wallets, dadurch wird es ja, wenn man das halt an so einen Electrum-Server anbindet, sind ja, sind diese Transaktionen, sind diese Wallets viel, viel schneller, als wenn ich das an den Bitcoin-Core anhänge, wo ich keinen Index dann aufgebaut habe, wie mit einem Electrum-Server.

Und da könnte es natürlich sein, dass diese Indexer-Implementierungen vielleicht dann in Zukunft dann auch dann da vielleicht auch noch Optimierung für anbieten, dass man da dann, weiß ich nicht, schneller dann, schneller nach diesen quasi, diese Art von Transaktionen dann halt haben, dass man da irgendwie einen eigenen Stack halt hat, der nur der durchsucht wird oder

so was. Kann ja auch sein. Ich wollte nur mal sicherstellen, dass das klar geworden ist, warum das mit jeder neuen Transaktion, die man macht, dann auch einen variablen Output gibt. Weil eben die, der Public Key der UTXOs, die man verwendet, mit einbezogen wird. Das katapultiert das dann immer wieder in eine ganz andere Ecke im Adressbereich, im Address Space, wenn man das sagen soll. Ja, sehr gut, sehr gut. Ja, ich glaube, das reicht auch erst mal,

oder? Also für den, für den funktionalen Abriss, oder? Genau. Vielleicht können wir noch mal einmal zur Zusammenfassung, das hat mir eigentlich ganz gut eingeleuchtet, noch mal sagen, also Josie Baig, das war einer der Entwickler, die an diesem Silent Payments gearbeitet haben, hat das so beschrieben in dem Stefan Rivera Podcast, dass wir mit Silent Payments quasi ein Drei-Level-Wallet bekommen. Ja, genau, das ist gut. Also wir haben, genau, also wir haben diese Send Keys,

wir haben Scan Keys und natürlich den Receive Key. Receive Key ist quasi der Silent Payment Code, den ich am Ende bekomme. Und der Scan Key ist der Schlüssel, mit dem ich Blöcke nach Transaktionen durchsuche, die ich empfangen habe. Und das ist natürlich getrennt von dem Send Key, das heißt, mit dem, also das ist der Key, mit dem ich die UTXOs dann ausgeben kann. Und was mir geholfen hat, das besser zu verstehen, war der Vergleich mit dem XPub und dem XPriv. Also der XPriv ist ja

quasi der Private Key, der zu dem XPub korrespondiert. Und der Scan Key ist so was wie ein XPub, also quasi meine Watch-Only-Wallet, die quasi die Blockchain quasi durchsuchen kann, nach Transaktionen, die zu mir gehören, kann aber keine Transaktionen autorisieren. Das heißt, wenn ich den Scan Key verliere, ist das ähnlich wie wenn ich den Pub Key verliere, habe ich zwar einen großen Privacy-Verlust, aber meine Fans sind nicht weg, weil ich ja mit dem

Scan Key und genauso wie mit dem XPub keine Transaktionen autorisieren kann. Das hat mir nochmal geholfen, das ein bisschen besser zu verstehen, wie sich Silent Payments in die uns bisher bekannte und vertraute Struktur von Wallets annähert oder einbettet.

Genau. Das ist eine gute Erklärung, gerade auch jetzt mit diesem Receive Key, dass der halt nur in Kombination mit den Inputs, das was Chris gerade auch nochmal klar herausgestellt hat, dass selbst wenn ich diesen Scan Key habe, dass der mir nichts hilft, weil ich ja die Inputs von, sage ich mal, den vorigen Transaktionen nicht kenne und somit auch nicht weiß, welche andere Zahlung du jetzt noch empfangen hast, in dem Fall oder in dem Fall Bob dann

empfangen hat. Du meinst den Send Key, glaube ich, Thorsten. Nee, was ich damals sagen will. Mit dem Scan Key kannst du ja alles scannen. Damit kannst du alle Transaktionen sehen. Ja, aber nur in Kombination mit den Inputs, oder? Nee, ich glaube nicht. Nee. Der hilft dir, das Ergebnis zu scannen auf der Blockchain. Genau. Weil du ja quasi, also was du ja siehst, guck mal, du schaust dir eine Transaktion an,

die jetzt in einem Block drin ist. Du siehst, okay, das ist eine Taproot-Adresse. Ich nehme mir den Pub Key, nehme meinen Private Key und kalkuliere daraus quasi die mögliche Silent Payment-Adresse oder Taproot-Adresse, die da rauskommt. Und das kann ich ja nur machen,

weil ich dieses Shared Secret mit Alice etablieren konnte. Weil es eben diese, ich weiß nicht, es ist ja eine Gleichheit zwischen dem Private Key kombiniert mit meinem Public Key, also dein Private Key kombiniert mit meinem Public Key ist das Gleiche wie mein Private Key kombiniert mit deinem, Thorstens oder Chris, Public Key. Jo. Gut. Cool. Mhm. Passt. Dann, du hast, es gibt vielleicht noch ein paar Trade-Offs. Also einerseits,

du musst halt diese Arbeit machen, also du musst das Scannen machen. Du hast, wenn du jetzt, keine Ahnung, diesen, keine Ahnung, ich habe diesen Payment-Link online, mein Silent Payment-Link oder Payment-Adress. Und dann sterbe ich und meine Nachfahren in 50 Jahren sehen, oh, der hat ja so ein Ding online. Dann müssen die im Grunde sicherstellen, müssen alles durchsuchen. Die

müssen nicht diese ganze Blockchain scannen, ne. Also du musst irgendwann sicherstellen, dass das Ding, ich will nicht sagen weg ist, oder du musst es, es kommt wahrscheinlich noch, Zeit limitieren, dass du sagst, das Ding ist nur aktiv bis Blockhöhe X in der Zukunft. Weil sonst ist dieses Ding immer online, also immer aktiv und kann immer empfangen. Ich glaube, was wichtig ist, dass man in der Stelle, wer es so gerade beschrieben hat, das Szenario, dass wir dann, wie sichern wir aktuell Wallets

mit einem Seed? Wir haben quasi eine HD-Wallet und das ist dann natürlich die Frage, wo hängt diese, also wo werden die privaten oder der private Schlüssel, der quasi die Ausgangsbasis für diesen Payment-Code ist, wo wird der gespeichert? Ist der Teil einer HD-Wallet? Ist das ein eigener Ableitungsfad davon? Ist das ein komplett eigener Seed, der nur dann

dafür verwendet wird? Also das ist mir an der Stelle zum Beispiel auch überhaupt nicht klar, ob wir das, wenn wir sagen, okay, ich habe jetzt ein Seed und darunter leite ich mir irgendwie einen Zahlungscode halt ab, reicht es dann, mir diesen Seed aufzuschreiben oder muss ich mir dann irgendwie noch was anderes zusätzlich dafür wegspeichern? Das sind vielleicht auch noch so Fragen, die vielleicht noch gar nicht geklärt sind oder wo wir jetzt noch gar

nicht darüber gesprochen haben. Super gute Frage. Also liebe Zuhörer, wenn ihr darauf eine Antwort wisst, würden wir uns sehr freuen über euren Input. Ich weiß es nicht, aber es ist eine wirklich exzellente Frage, Thorsten. Was muss ich mir quasi aufbewahren, um meinen Silent-Payment-Key wieder

recoveren zu können im Fall der Fälle? Vielleicht ist das wirklich, man hat ein Seed und dann ist das ein anderer Ableitungsfad, der halt dann nicht quasi auf irgendeinem, weiß ich nicht, wie so X-Pub-Ableitungsfad 1, 2, 3, 4, 5 ist, sondern es ist vielleicht irgendeine neue, irgendein spezifischer Ableitungsfad, wo das dann halt liegt, wo dann halt auf der Ebene dann dieser

private Schlüssel für liegt. Who knows? Weiß ich nicht. Ein Spezialfall geht auch nicht, wenn du jetzt so was wie Wasabi Wallet nimmst, das als Output einige Coin-Joints, aus einer Coin-Joint-Transaktion kommt, geht das auch nicht, weil du den nicht, also den kennst du ja noch nicht. Also du gibst einen Input in was weiß ich, Wasabi Wallet und du hattest ja die Möglichkeit, schon quasi mit dem Coin-Joint zu bezahlen. Das geht nicht bei diesem Silent-Payment,

weil du musst das UTXO ja kennen. Ja, ja, ja, ja, okay. Ah, interessant. Ja. Also Coin-Joints klappen damit nicht oder der Output, Coin-Joints als Output sozusagen. Ge-Coin-Jointed-Coins, die frisch aus dem Coin-Joint kommen, wo du den nimmst. Genau, wenn die halt irgendwo liegen dann. Wenn du von da aus das dann weiterschickst, das geht natürlich. Also du kannst ge-Coin-Jointed-Outputs natürlich als Input für

einen Senden an einen Silent-Payment-Link schicken, das geht. Aber vielleicht innerhalb des Coin-Joints selber ist es natürlich schwierig, weil wir da manuell Zutun brauchen. Das funktioniert wahrscheinlich jetzt in dem Sinne nicht. Wobei, ja doch. Irgendwann wird es auch schwerer, wenn mehr Taproot-Adressen, also wenn Taproot populärer wird und in ein paar Jahren vielleicht der Standard ist, dann dauert es länger, das zu scannen.

Ja, achso und das wäre natürlich noch ein Punkt, du brauchst eine Fullnode, zumindest jetzt nach unserem Verständnis. Also quasi ein Light-Client kannst du nicht verwenden. Also eine Client oder eine Wallet, die nicht alle Blöcke runterlädt. Ich weiß, das ist in Arbeit, das habe ich in den Podcasts auch gehört, aber das Ganze habe ich noch nicht verstanden. Also es ist, aber das ist auf jeden Fall noch nicht da. Ich glaube, wir können

festhalten, Stand jetzt, funktionieren Silent-Payments auf jeden Fall mit einer Bitcoin-Fullnode. Mit einem Light-Client ist es wohl noch in Arbeit. Ich weiß allerdings nicht, bin mir nicht sicher, ob das tatsächlich kommen kann und kommen wird. Ja, da haben sie das, das haben die irgendwie da ein paar Mal durchgekaut in den Podcasts, aber ich habe es auch nicht richtig verstanden. Ich war so froh, dass ich das Grundprinzip verstanden habe. Und ich glaube, wir haben es

jetzt auch ganz gut zusammengefasst. Es ist einfach eine komplett andere Denkweise, wie die Outputs von Transaktionen, wo die landen, oder? Ja, also die, wir kriegen, also die Adressfindung ist quasi was anderes. Die Adressfindung, wir gehen nicht davon aus, dass die Adresse von dem Empfänger bereitgestellt wird, sondern wir vom Sender quasi erstellt. Also wir als Sender sind in der Lage, die Empfangsadresse selber zu ermitteln, indem wir auch ein bisschen Rechenleistung ermitteln.

Also wir machen da ja auch diese Computing Power, dass wir dann ja auch für uns dann die Inputs zusammenrechnen, da die Multiplikation mit dem Public Key machen, also mit das quasi das ECDH, dass wir die dann halt machen und uns so quasi selber dann in der Lage sind, die Empfangsadresse zu errechnen. Und das Gleiche haben wir dann auf der Gegenseite entsprechend dann halt auch. Gut, wollen wir noch, wenn wir mit dem Thema soweit durch, noch einen kleinen Vergleich zu Paynm

machen? Ich glaube, vielleicht über Paynm selber haben wir, glaube ich, auch noch nie im Podcast so richtig gesprochen, wie das genau funktioniert. Also vielleicht deswegen auch eher in kurz. Ja, sehr gerne. Thorsten, du hast es ja auch mal bei uns auf der Webseite aufgesetzt. Also man kann uns tatsächlich auch per Paynm Spenden schicken. Vielleicht wäre das jetzt, nachdem es schon zwei Jahre oder so gefühlt live ist, mal ein guter Zeitpunkt zu erklären, was machten wir da

eigentlich mit diesen Paynms? Also Paynm ist BIP 740, hatten wir eben am Anfang schon mal gesagt. Das ist eine alternative Implementierung, die, glaube ich, ursprünglich von Samurai Wallet, glaube ich, vorangetragen wurde. Ist da auch in der Samurai Wallet immer noch verfügbar und in der Sparrow Wallet genauso. Was passiert da? Das ist im Endeffekt auch quasi so ein Zahlungscode,

den wir halt haben. Aber der große Unterschied ist, dass, wenn Alice Bob eine Spende zum Beispiel schicken will, muss Alice vorher eine Notification-Transaktion machen, in dem quasi der Zahlungscode, also der NIM von Bob mit Alice gekoppelt wird. So kann man sich das sinnbildlich vorstellen. Also dass die miteinander verknüpft werden, damit Alice in Zukunft in einer zweiten Transaktion auch wirklich dann Spenden schicken kann. Und das ist auch dann jetzt auch schon an

der Stelle auch schon auf jeden Fall der größte Unterschied zu Silent Payments. Da gibt es das halt effektiv nicht. Da braucht man diese Notification-Transaktion nicht machen. Und ich habe es gerade schon gesagt, wir haben zwei Transaktionen, wenn wir wirklich eine Zahlung machen wollen. Und da erkennt jeder sofort, dass wir auf jeden Fall mehr Kosten dadurch haben,

weil wir zwei Transaktionen machen. Wir haben einen Verbrauch mehr Block Space, das heißt, die Blöcke oder die Time Chain grundsätzlich wird voller dadurch, weil wir halt immer mindestens zwei Transaktionen machen wollen. Und ja, und ich glaube, das ist auch so ein bisschen auch das große Problem, dass das vielleicht auch gar nicht so viel Akzeptanz halt hat, weil die Hemmschwelle, erstmal so eine Notification-Transaktion machen zu wollen, ist wahrscheinlich ziemlich hoch,

bevor ich dann überhaupt erst die eigentliche Spende machen will. Und das ist vielleicht auch der Grund, warum das bei Nodesignal bei uns auch nicht wirklich benutzt wird. Weil erstens, es kennt glaube ich kaum jemand. Und zweitens, es ist ja schon recht komplex, um da eine einfache Spende umzusetzen. Wobei man sagen muss, also diese Notification-Transaction macht man nur

einmal. Also wenn ich jetzt zum Beispiel an den Paynm von Nodesignal etwas schicken möchte, dann mache ich das einmal, diese Notification-Transaction und kann dann quasi meine Spende starten. Und dann daraufhin, das ist dann wie so eine Art Payment Channel, kann ich dann immer wieder eine Zahlung an diesen Paynm schicken. Also die Notification-Transaction habe ich tatsächlich nur beim allerersten Mal, um diesen Payment-Channel in Anführungszeichen,

die ich hier mache, verwenden zu können. Aber nichtsdestotrotz, das stimmt, es ist auf jeden Fall eine Hürde, gerade bei hohen On-Chain-Fees, quasi zweimal Gebühren zu zahlen für eine tatsächliche Transaktion. Und was auch quasi auch öffentlich bekannt ist, ist, welche Verbindung inzwischen welchen nimmst du dann mit dieser Notification-Transaction? Das ist glaube ich ein eigener OP-Code, der da irgendwie verwendet wird oder eine Art von OP-Code, der verwendet

wird. Und diese Bekanntmachung von dieser Verbindung, die sieht man halt relativ einfach auf der Time-Chain und kann so prinzipiell dann auch erkennen, wie viele, ich glaube das Beispiel war auch in dem Podcast, wie viele Freunde hatte die Person dann? Also wie viele Leute haben eine Verbindung zu diesem Nimm aufgebaut dann? Und das ist natürlich jetzt auch wieder so ein bisschen so ein Privatsphäre-Issue eigentlich, dass man da auch Sachen daraus ableiten kann.

Ja und neben den zusätzlichen Transaktionen, die du machen musst, hast du halt auch so ein bisschen Bloat für die Blockchain. Und das hast du jetzt bei Silent Payment nicht. Also du bläst damit

die Blockchain nicht auf. Genau. Zum einen, du hast die Notification-Transaktion, das ist einmal, du hast quasi eine zusätzliche Transaktion, die Blockspace verbraucht und gleichzeitig, weil du einen OP-Code verwendest, der ja auch dann das Bitcoin-Skript größer macht, ist deine Transaktion auch grundsätzlich größer, als wenn du quasi eine ganz simple, ich schicke es einfach auf die Public Key oder eine ganze Pay-to-Script-Hash,

bla bla bla, also so eine einfache Variante davon. Da ist natürlich die Transaktion auch schon ein bisschen größer dann. Das sind vielleicht so die Punkte.

Bin total gespannt, ob wir in zwei Jahren oder so, ob das sich weiter durchsetzt und wir ganz viele Silent Payment-Adressen sehen werden als Static Addresses, wo man hinspenden kann. Oder bin ich echt mal gespannt. Und auch, wie die Heuristiken dahinterher kommen. Also, ob man das ganze Ding dann doch nachverfolgen kann. Also ich glaube, letztlich, also ohne, dass ich ja die Kryptografie dahinter durchschaue,

aber ich vertraue da doch etwas darauf, dass das nicht der Fall sein wird. Also, dass das genau ja auch der Grund ist, um halt Privatsphäre quasi on-chain möglich zu machen, dass das eben nicht zurückgerechnet werden kann. Dass wir deswegen diesen Ansatz bei Silent Payments verfolgen. Aber das, also, wie gesagt, das kann ich natürlich nur so in den Raum stellen und kann das nicht belegen, diese Behauptung. Was ich aber ganz schön finde

an Silent Payments ist, also zum einen, das BIP ist fertig. Also, das hatten wir eben schon festgestellt. Das ist quasi die Spezifikation ist da und kann jetzt von Wallis implementiert werden. Es braucht keinen Consensus Change. Das hat Thorsten ja auch schon gesagt. Wir brauchen keine zusätzlichen Opcodes. Das ist quasi, die Voraussetzungen sind schon da. So, und jetzt ist halt nur noch die Frage, welche Wallets werden die Silent Payments anbieten.

Und das fand ich nochmal ganz schön in diesem Podcast mit Stefan Levera oder bei Stefan Levera zu hören, weil da war der Appell sehr klar, hey, geht auf eure Wallets, Walletbetreiber und Entwickler zu und sagt denen, hey, zumindest das Senden könntet ihr doch schon mal implementieren,

weil das auch relativ wohl einfach ist. Die müssen eben nur diese, also die Wallets müssen nur diese drei Voraussetzungen, also Bobs Public Key, das Shared Secret und den Pub Key der Inputs, die sie verwenden wollen, das müssen sie zusammenbringen und dann kann man schon an einen Silent Payment Code eine Transaktion schicken. Damit wäre quasi schon mal die halbe Miete wäre schon da. Das ist relativ einfach. Auf der anderen Seite ist das Empfangen natürlich

etwas komplexer wohl. Da müssen wohl die Wallet Entwickler noch ein bisschen mehr Arbeit rein stecken und hat natürlich auch höhere Voraussetzungen. Du brauchst natürlich einen Fullnode Stand jetzt, um Silent Payments empfangen zu können und nicht nur empfangen zu können,

sondern auch danach scannen zu können, ob du jetzt was bekommen hast. Aber wenn das dann da ist, ist es doch mega geil, weil dann brauche ich ja nicht mehr quasi mehrere Adressen, sondern ich gebe euch einen Payment Code und sage hier, Payment Code für Thorsten ist derselbe, wie der für Chris, ist derselbe, wie für meinen Arbeitgeber, ist derselbe, wie für, weißt du, wo ich den rausgeben möchte. Und trotzdem kann ich unter Wahrung meiner Privatsphäre

Bitcoin Funds empfangen. Es ist auch egal, selbst wenn jemand rauskriegen würde, dass der Silent Payment Code zu mir gehört, kann er daraus noch immer nicht ableiten, welche Transaktionen denn jetzt tatsächlich zu mir gehören. Ich bin da recht optimistisch, dass das gut ausgeht. Also diesen Silent Payment Code ja nicht zu Person zuzuordnen, macht ja dann eigentlich wenig Sinn. Also das funktioniert ja nur, wenn man weiß, dass man, wenn ich da was hinschicke,

wer das dann auch bekommt. Weil das ist ja quasi meine Intention. Absolut, genau, ist absolut richtig. Wo wir wieder bei diesem Thema Username sind, was wir am Anfang hatten. Es klingt jetzt noch so abstrakt, aber was ich mega geil finde, ich habe das auf Twitter gefunden vor, heute ist der 28., nehmen wir auf, am 16. Mai hat Keith Moukai, wird er so gesprochen? Mewkai? Moukai? Ja, Keith. Keith aus dem C-Signer-Development-Team ein Video gepostet auf Twitter oder X.

"New C-Signer Experiment. Initial Support for BIP-352 Silent Payments." Und du siehst ein Video, wie du dir mit dem C-Signer so eine "Reusable Payment Address" generieren kannst. Du kannst dir also diese Payment Address generieren, du kannst dir den "Signing Pub Key" exportieren und du kannst dir den "Scanning Private Key" exportieren. Mega cool.

Also ich glaube, es ist noch nicht, weiß nicht, in welcher Version es dann kommen wird, in welchem wirklichen C-Signer-Release, aber die experimentieren schon daran. Das sieht ziemlich fertig aus. Das wäre jetzt auch meine letzte Frage wahrscheinlich gewesen, so hier jetzt der geneigte Hörer, der sich das jetzt hier über eine Stunde angehört hat und gesagt, das klingt alles total geil, ich will das jetzt mal ausprobieren. Wo kann ich das denn jetzt schon machen?

Wir haben die ganze Zeit davon gesprochen, es gibt schon ein paar Wallets, die das schon implementiert haben. Wo kann ich das denn nachschauen? Welche Wallets sind das? Und ansonsten, wo finde ich weitere Ressourcen? Vielleicht, dass wir das so als Abschluss noch mal machen. Ich glaube, eine gute Quelle ist tatsächlich den Link, den wir schon genannt hatten,

von Seth for Privacy, SilentPayments.xyz. Da gibt es unter den weitergehenden Informationen gibt es eine Seite, die heißt WalletSupport oder SilentPayments WalletSupport. Ich weiß nicht, wie, also ich hoffe, dass das aktualisiert wird. Da fehlt jetzt zum Beispiel noch C-Signer, aber da sehen wir das bei CakeWallet. Das ist wohl so eine Bitcoin- und Monero-Wallet, das bereits implementiert ist. Und bei Silentium, das sagt mir gar nichts.

Also Silentium ist ein Proof of Concept, steht hier in der Fußnote. "Should be used with caution from the developer." Okay. Ah, das ist ein Proof of Concept für SilentPayment Lite Wallets. Okay. Also die beiden Implementierungen gibt es bereits, da kann man das mal ausprobieren, wenn man möchte. Und ich habe heute gesehen, dass auf der Cashu-Donation-Seite auch schon eine SilentPayment-Adresse heute veröffentlicht wurde. Also heute ist, ihr habt die Blockzeit gehört. Der 28. Mai.

Ja, cool. Ja, ist doch mal was Positives, oder? Ja. Auf den ganzen Privacy-Rückschlägen scheint sich doch da jetzt wirklich richtig was zu tun. Finde ich mega cool. Finde ich gut, dass da auch so ein einfacher oder allgemeingültiger Ansatz jetzt gefunden wird, der es auf jeden Fall einfacher macht. Aber noch eine kurze Anmerkung zu dem, was du gesagt hast, mit dem, ob das aktualisiert wird. Die Webseite ist auch auf GitHub, also der Quellcode für die Webseite ist auf GitHub.

Und der Cess4Privacy hat auch explizit in einem Twitter-Thread auch darum gebeten, Ergänzungen zu dem ganzen Thema einzubringen. Er merged das dann und veröffentlicht das dann entsprechend. Das heißt, er versucht das halt so weit wie möglich aktuell zu halten, aber hofft dann natürlich dann auch auf die Schwarmintelligenz der Bitcoin-Community, die dann halt dann auch bei, selbst nur bei dieser SilentPayment-Webseite, Info-Webseite, dass die halt aktuell bleibt.

Und wenn ihr da irgendwie was seht, ob das eine neue Wallet ist, die da vielleicht noch nicht gelistet ist, dann scheut euch nicht, da vielleicht dann ihn darauf hinzuweisen oder selber einen Merge-Request für die Webseite einzustellen, dass das dann aktualisiert wird. Yes. Nice.

Ich würde sagen, damit haben wir eine Folge zu SilentPayments gemacht, die recht spontan gekommen ist. Also wir haben uns quasi am Wochenende, es ist uns irgendwas ausgefallen. Wie war das nochmal? Ach ich weiß nicht. Auf jeden Fall, es wäre sonst, ja genau, aber es wäre dann darauf hinausgelaufen, dass wir zweimal den Buchclub nacheinander gebracht hätten. Dann haben wir gesagt, nee, komm, wir müssen nochmal. Das kann man keinem antun.

Das kann man keinem antun. Chris, hörst du etwa nicht den Buchclub? Ähm, doch. Also ich höre das dann so als Blog-Veranstaltung mal, wenn das komplett ist. Ich komme im Moment nicht mehr mit. Ich gebe es zu. Alles gut. Genau, aber wir wollten jetzt nicht zwei Buchclub-Folgen nacheinander bringen und haben uns dann spontan entschieden, das Thema SilentPayments aufzugreifen. Und genau, haben jetzt hier in ein paar wenigen Stunden diese Folge uns irgendwie zusammengezimmert.

Ja, es war auf jeden Fall kein schlechter Ersatz. Also ich bin total begeistert und will da dranbleiben und das weiter verfolgen, was damit passiert. Und ich glaube, es ist auch wichtig, einfach diese Idee mal durchzugehen, weil mir schien es am Anfang erst ziemlich komplex, aber eigentlich ist es gar nicht so wild. Man muss ein bisschen Grundzeit reinstecken. Ja, ich glaube, das Grundprinzip, also wir hoffen, dass wir es euch so ein bisschen vermitteln konnten.

Wir haben es, glaube ich, das Grundprinzip verstanden. Natürlich, man kann dann auch in tiefere Tiefen reingehen und da gibt es sicherlich noch einige Schwierigkeiten. Thorsten hat eine gute Frage mit dem Backup, dem Recovery aufgeworfen, die wir jetzt auch noch nicht beantworten können. Aber vielleicht haben wir bei euch, ja. Ich finde, es ist ja wahrscheinlich wie bei allem dann später, also dass du ja nicht komplett auf Silent Payments umsteigen musst.

Dass es ja vielleicht sein kann, dass du sagst, ich habe jetzt hier für bestimmte Dinge nutze ich Silent Payment und für andere Dinge nutze ich einfach klassische HD-Wallets weiter. Das hat ja beides seine Vor- und Nachteile und dass man wie bei allen Dingen, die wir im letzten anderthalb Jahren oder wann auch immer besprochen haben, sich lohnt, sich mit allem ein bisschen auszukennen und zu wissen, in welcher Gelegenheit man was benutzt.

Ja, ich gehe aber davon aus, dass wird, wenn es das nicht schon ist, kurz oder lang Teil von HD-Wallets werden. Das heißt, das Ding wird Teil von einem Seed werden und wenn es das nicht sowieso schon irgendwie ist, dann muss man auch gar nicht entscheiden, sondern sagt halt einfach, man nutzt diese Funktionalität innerhalb einer Wallet. Okay, das kann auch sein.

Ja, das Coole an dem Ding ist ja, das funktioniert ja sogar theoretisch, dass man auf einem Cold Storage einen Payment-Code generieren kann. Das heißt, es muss ja nicht mal eine Hot Wallet in dem Fall sein und muss bei Payment in dem Fall auch nicht. Aber man kann ja so ein Key quasi auch auf Cold Storage generieren und so quasi Cold Storage auch direkt fernsehempfangen, was ja auch cool ist.

Wir sollten mal bei Bitbox anfragen, wie da denn der Status ist zu Silent Payments, ob sie sich das schon mal angeschaut haben, ob sie das implementieren wollen. Ja, guter Punkt hätten wir. Das wäre vielleicht sogar ein cooler Punkt gewesen, wenn sie gerade bei deinem Draht zu Joko und Co. haben. Ja, und dann könnten wir auch gleich bei Pocket fragen, ob sie nicht auch auf der Senderseite quasi Silent Payments implementieren wollten.

Dann hätten wir quasi einen geschlossenen Loop. Du kannst quasi, der Werbecode, das geht alles an 21, die werben das ja immer. Aber dann könnte man quasi bei Pocket seinen DCA-Auftrag haben und gibt denen nur einen Silent Payment Code statt einem XPAP und die schicken das dann an eine Bitbox, die das auch noch versteht und dann quasi die Fahndsteile im Code. Perfekt, die haben nur unsichtbar Macht. Nur deine Bankadresse musst du noch aus der Gleichung rauskriegen. Dein Bankkonto.

Ich trage Bargeld über die Schweizer Grenze, wenn es sein muss. Sehr gut. Cool, ich würde sagen, wir machen mal den Deckel drauf. Wir sind schon über eine Stunde unterwegs. Hat mir echt Spaß gemacht mit euch beiden. Ja, mega. Vielen, vielen Dank. Gebt uns auch gerne Feedback, ne? Also an euch da draußen. Gebt uns Feedback, ob das okay verständlich war oder ob das jetzt auch wieder, wie der Buchclub immer viel zu komplex war und wir wieder in unseren Nerdlöchern hier abgetaucht sind.

Dann gebt uns da auch gerne Feedback, dass wir das auf einem höheren Level nochmal versuchen beim nächsten Mal bei anderen Themen. Ein gutes Zeichen ist immer, wenn ich es verstanden habe, dann haben das glaube ich auch viele andere verstanden. Dann nochmal ganz kurz der Hinweis, dass wir ein Value for Value Podcast sind. Wir würden uns sehr freuen, wenn ihr darüber nachdenkt, uns einen kleinen Boost zu schicken.

Einen kleinen Absatz drüber kommen zu lassen für die Arbeit, die wir hier reinstecken. Das würde uns sehr helfen. Natürlich freuen wir uns auch über die Nachrichten, die ihr damit schicken könnt. Ihr könntet aber auch einfach so einen Boost schicken ohne Nachricht. Dann, focus on the signal, not on the noise. Ciao, ciao.