Herzlich willkommen beiNode-Signal, deine Bitcoin-Frequenz. Heute mal wieder mit einer bekanntenNode hier, nämlich dem Thorsten. Hallo Thorsten. Ja, ja. Hi. Und mit mir, ich bin der Jan Paul. Und wenn wir beide zusammenkommen,dann wird es wieder etwas technischer. Und wir haben uns heute vorgenommen,dass wir in das Thema ARK reingehen.
Thema ARK ist bei mir nochmal aufden Schirm gerutscht, weil es neulich im Socratic Seminar besprochenwurde, weil die Firma Second eine Implementierung des ARK-Protokollsauf Signet veröffentlicht hat. Das heißt, man kann auf Signetjetzt schon mal der Command-Line so ein bisschen mit ARK rumspielen.
haben das auf jeden Fall zum Anlassgenommen, zu sagen, okay, dann wollen wir uns auch bei Node-Signal nochmal mehr mitdem Thema ARK beschäftigen und soweit bei der Vorbereitung dieser Folge habe ichmir echt große Hoffnung gemacht auf ARK.
Ich glaube dass es wirklich einerealistische Möglichkeit ist, ein weiteres Layer 2 auf Bitcoin zubekommen, sodass wir halt nicht nur Lightning haben, sondern eben auch ARKals Layer 2, bei dem der Nutzer die volle Kontrolle über seine Bitcoinsbehält und jederzeit unilateral den Exit aus ARK Richtung Onchain nehmen kann. Und wie das funktioniert und ob dasalles so stimmt, was ich hier behaupte oder den Optimismus den ich hier ARKhabe, ob das so passt, das besprechen wir mit unserem heutigen Gast.
Und ich begrüße sehrherzlich den Robin Linus. Hallo Robin. Hi, danke Hallo. zu uns gefunden hast. Robin, bevor wir dich vorstellen,du die Blog-Zeit für uns? Na klar, die Blockzeitist 900.659 und die letzten 4 Bytes sind F8, 9, 0, F, A1. Thorsten kannst du bestätigen? Den Hash habe ich auch,oder zumindest den Ende des Hashes. Sehr gut. Sehr schön. Genau.
glaube, der ein oder andere hat schonmal mitbekommen, du bist, glaube ich, in einer größeren Bitcoin-Öffentlichkeitins Bewusstsein gekommen, weil du das Thema BitVM entwickelt hast. Vielleicht magst du mal ein, zwei Sätzedazu sagen, was BitVM ist und auch, wie du auf das Thema gekommen bist und wiedu überhaupt zu Bitcoin gekommen bist. ich zu Bitcoin gekommen bin.
Ich habe schon relativ früh, schon 2008oder so, als das mit der Finanzkrise war, angefangen an unserem Finanzsystemzu zweifeln und dann hat man so über die Jahre sich damit auseinandergesetzt,so Fiat-Geld-System und sowas. man, denke ich, auch relativ schnellauf den Trichter dass das ein ziemlicher Scam ist, dass das ziemlich ungerechtist und dass es zum Nachteil der meisten Menschen ist und dass halt denMenschen da die Lebenszeit geklaut wird. habe es aber damalseinfach so hingenommen.
Auf dem Weg hat mir tatsächlichauch irgendwann mal ein Freund von Bitcoin erzählt, aber ich habedas erstmal komplett dismissed und dachte so irgendein Internet-Scamoder sowas Das muss so um 2011. Das gewesen sein, wo ich daserste Mal von Bitcoin gehört habe. dann über viele Umwege kam ichdann 2016 nochmal auf Bitcoin, als ich in Costa Rica war. Das war eine ganz lustige Geschichte.
Ich war da in so einem kleinen Dorfjetzt nicht so klein schon irgendwie 2.000, 3.000 Leute, aber das war ganzwitzig die hatten einen Geldautomat und der hat nachts um 10 immer zugemacht,weil da immer Überfälle waren und deswegen wurde dann halt einfachder Geldautomat geschlossen nachts. Und dann hatten alle in diesem Dorffast jede Nacht das Problem, dass halt den Leuten das Bargeld ausgelaufen ist.
In Costa Rica gab es nicht so vielmit Visa-Card und so weiter und dann haben die Leute halt jeden Abend wiederdas gleiche nervige Problem gehabt, dass sie sich dann gegenseitig haltdas Bargeld abgekauft haben und dann irgendwie über PayPal oder sonst wassich das hin und her geschickt haben. Und ich halt ein Nerd bin, dachte ich,das muss doch irgendwie besser gehen und dann bin ich halt ins Internet gegangen. Nach einer Weile bin ich dannhalt über Bitcoin gestolpert.
hat mich sehr, sehr fasziniert, also allesda dran, von der Kritik am Geldsystem über halt die ganze Informatik undwie es halt Informatik und Physik und Ökonomie zusammenbringt und natürlichauch der psychologische Aspekt von Geld an und für sich und halt Mathe hat michimmer interessiert, Kryptografie fand ich sehr faszinierend, obwohl ich damalskeine Ahnung davon hatte und ja, da war halt relativ klar, das ist das Ding.
Und habe ich eigentlich nurnoch damit beschäftigt ganz Also in das sprichwörtlicheRabbit Hole gefallen, wie es so einigen hier passiert ist. Ganz tief, sehr gut. magst du noch irgendwie ein, zwei Sätzefür die Leute, die noch nie was von BitVM gehört haben, zu BitVM sagen, was es ist. Wir halten das kurz, wir haben ebenim Vorgespräch ja gesagt, eventuell können wir in einem halben Jahr oder sonochmal uns treffen und eventuell über BitVM sprechen, aber was ist BitVM?
Ganz grob gesagt istes auch eine Skalierungslösung. geht halt dabei darum, Bitcoinbridgen, auf Second Layers zu bridgen. Rollups ist ein großes Thema, aberauch zu Sidechains zu bridgen. kennen die Leute Liquid,die Liquid-Sidechain. Dort ist es halt so, dass das halteine Multisig ist, dass man im Prinzip einfach vertraut dass dieLeute, die halt das Geld da in der Multisig halten, nicht weglaufen. man hätte halt einfach gernbessere Bridges, die halt trustless sind idealerweise.
Und da ist halt das große ThemaSnarks, Zero-Knowledge-Proofs. Und das ist halt eine kryptografischeoder ein Tool, das halt kryptografische Kompressionen machen kann.
Also man kann damit schier unendlicheMengen an Computation in einen sehr kompakten Proof pressen Ein sehr heißer Kandidat umKryptowährungen allgemein zu skalieren und hat halt nativ keinen Snark-Verifierbisher, weil es halt so schwierig ist, Crypts zu updaten und BitVM ist quasi soein Hack, um von hinten durch die Brust ins Auge dann doch einen Snark-Verifierin Bitcoin reinzuhacken, um dann halt Bridges zu bauen, um dann halt BTCauf Second Layers zu bridgen in einer
möglichst vertrauensminimierten Weise. Ja super. Also es klingt auf jeden Fall sehr, sehrspannend, da mit BitWM auf uns zukommt. da würde ich mich ganz gerne nochmalein bisschen reinarbeiten und dann reden wir da nochmal ausführlich drüber. wir wollten heute bei ARK sprechenund meine Motivation dich einzuladen war, dass ich Video gesehen habe. Es ist auf YouTube veröffentlicht. Packen auch in die Shownotes. Und das heißt ARK WhiteboardMasterclass mit dem Burak.
Das ist quasi der ErfinderARK-Protokolls und Sam Parker. Und da habe ich gedacht, okay,das ist natürlich perfekt. Also wenn der Robin, der scheint dasganz gut verstanden zu haben und spricht Deutsch, dann ist er wahrscheinlich derbeste Ansprechpartner für das Thema. Wenn wir über ARK sprechen wollen. Vielleicht können wir damit beginnen. Und ich glaube, das ist auch dieMotivation, die Burak hatte, weil er ein paar Probleme in Lightningsieht, die er mit Arc angehen möchte.
Vielleicht können wir mal darübersprechen, vielleicht kannst du uns erzählen, Robin, was sind denndiese wesentlichen Kritikpunkte die Burak oder allgemein nichtnur Burak sondern allgemein beim Lightning-Protokoll bestehen?
high-level geistern ja da aufTwitter immer wieder diese Statistiken rum über die Lightning Wallets und da zeigtsich halt, dass irgendwie die Hälfte der Lightning Wallets Wallet of Satoshi ist,das heißt das sind Custodial Wallets ist denke ich so einer der Kernkritikpunktedass es halt nicht richtig Bitcoin ist, sondern es sind halt nur Versprechen aufBitcoin und Das widerspricht natürlich fundamental dem Ethos von Bitcoin.
Wenn man im Whitepaper den Abstractliest, ich glaube im ersten oder zweiten Satz steht halt drin,dass man es halt eigentlich ohne Trusted Third Party machen will. Und jetzt haben wir das doch wiedereingeführt, indem wir da halt so viele Custodial Lightning Wallets haben. Und das ist dann halt schon schmerzhaft. Und das wollen dann halt die Leute,denen der Cypherpunk-Idealismus im Herzen schlägt, die wollendas dann natürlich fixen.
Und, ähm... Eins der großen Problemenatürlich von Lightning ist das Onboarding, insbesondere halt dasInbound Liquidity Problem, also das Problem, dass um etwas empfangen zukönnen, muss ich erstmal, muss meine Counterparty, muss meine Gegenparteierstmal Geld für mich einsperren für den Fall, dass ich etwas empfangen möchte. Und das skaliert halt nicht so gut.
Also schon ein simples Rechenbeispiel,wenn man jetzt halt irgendwie 100 Millionen Nutzer hat, was glaube ich grobdas ist, was Paypal hat man hatte vor 10 Jahren, ich weiß auch nicht genau, aberwenn man mit 100 Millionen Nutzern rechnet und dann nur ermöglichen will, dass jedervon denen 10 Euro empfangen kann, dann muss es schon eine Milliarde Euro locken.
Und das ist natürlich ein riesenKostenfaktor und das zeigt halt, was da an Reibung ist, um das Ganze erstmalins Laufen zu bringen für Endnutzer. Ja, um nicht zu viel zu flamen, will ichaber auch sagen, ich denke, dass Lightning eine sehr interessante Technologie ist. Insbesondere hat es halt diese InstantFinality, was eine große Stärke ist. Das kann sonst nichts in der Art liefern. Also in diesem Level vonTrustlessness settelt nichts anderes so schnell, meines Wissens nach.
Und hat sich ja auch bereits jetztschon so als ein Settlement Layer etabliert zwischen verschiedenenSecond Layers auf Bitcoin. Lightning an und für sich aberdann haben wir auch so Sachen wie E-Cash und Sidechains. Liquid ist kompatibelmit Lightning und so. scheint es halt richtig gutzu funktionieren also als Glue zwischen Second Layers. Nur es funktioniert haltnicht so gut für Endanwender.
gibt es natürlich viele andere SachenMan muss halt online sein, man muss halt so eine Note laufen lassen, man mussonline sein, um empfangen zu können. Da gibt es dann immer Hacks, um dairgendwie drumherum zu kommen, aber es sind sehr, sehr viele Hürden fürEnd-User, die das Ganze halt, die einfach zu viel Reibung induzierenund dann deswegen die Leute halt in solche Custodial-Richtungen lenken. Und das ist das Kernproblem,was dann Arc lösen möchte.
dann lass uns doch mal direkt,wenn du gerade schon ARK ansprichst und in seinem Intro eben auch schongroßspurig in Anführungszeichen für ihn ARK als zweiten Second Layer odergroßen Second Layer Bitcoin sieht oder auserkoren hat, mal so ein bisschen indie Grundthematik von ARK reingehen.
Wir haben ja durchaus die quasivielleicht vergleichbar zu Lightning sind von den Grundprinzipien her,weil wir haben ja auch signifikante Unterschiede eben, weil wir halt bestimmteTrade-offs haben, die wir bei Lightning haben, die wir ja so lösen wollen. großer Punkt sind die Shared UTXOs. Vielleicht wollen wir daan das Thema mal reingehen.
Shared-UTXOs im Allgemeinenist ja eben die Idee, dass mehrere Nutzer sich eine UTXO teilen und dasskaliert dann UTXO-Ownership hatten die eben das Problem, dass üblicherweisehalt eine End-of-End-Signature ist, also irgendwie fünf Leute sharen eine UTXOund dann kann man halt Off-Chain-Updates machen, jedoch ist das Problem, dass ebenalle immer zu diesen Updates zustimmen müssen, weil wenn nicht alle zustimmenheißt das ja, dass derjenige der nicht
zugestimmt hat den anderen vertrauenmuss, dass das valider State-Update war Deswegen rennen die halt in diesesProblem, dass entweder tut man halt Trust erzeugen also Vertrauen brauchenoder man hat halt das Liveness Problem. Das heißt, wenn einer nicht onlineist, dann bleibt es stehen, das System. Dann kann man keine neuen Updates machen. Und war so das historisch gesehen,sodass das Kernproblem an Shared-UTXOs und ARK löst das halt in einerrelativ eleganten Art und Weise.
Kernlösungen sind halt diesesogenannten VTXOs, Virtual UTXOs. Und das sind halt eben UTXOs,das sind Outputs von vorgesignten Transitionen Transactions, daswird ziemlich dinglich heute. Das passt absolut. Also unsere Hörer glaube ich verstehenauch die englischen Begriffe sehr gut. Also muss dir nicht allzu viel Mühedamit geben, jetzt immer den deutschen Begriff zu finden, die englischenBegriffe passen Und ansonsten werden wir es so ein bisschen ergänzen, wovielleicht eine Ergänzung notwendig ist.
Gut, dann diese Pre-SignedTransactions, können halt Outputs erzeugen solche sogenannten Virtual UTXOs undUser, dem diese Virtual UTXO gehört, der ist auch in der Lage jederzeitdiese VTXO zu materialisieren, also das bedeutet diese Transaction zu machen unddann aus der VTXO eine UTXO zu machen. Aber ganze Arc-Spiel versucht halteben genau das zu vermeiden, also dass der End-User eben nicht on-chaingehen muss, sondern das Ganze immer so koordiniert wird, dass erin diesem einen Arc drin bleibt.
Kernidee das Ganze halt funktioniert,ist, haben diese VTXOs eine Lifetime, also nach einer gewissenZeit, zum Beispiel zwei Wochen oder einem Monat oder so, die halt aus. Dann das Geld quasizurückgegeben an den Server. Das habe ich jetzt noch nicht erwähnt. Es gibt halt einen Server, esgibt eine zentrale Rolle, die das Ganze halt koordiniert Für jedenArc, jeder Arc hat einen Server. Der ist aber trustless, alsoman muss dem nicht vertrauen.
kann halt eben jederzeit rausgehenund seine VTXO materialisieren, aber Trick ist eben, dass diese VTXOs jedenMonat zurück an den Server gehen. Das heißt, der Serverkann die einfach nehmen. Und klingt erstmal kontraintuitiv,weil wieso kann der Server jetzt einfach mir mein Geld wegnehmen?
Aber der Clou ist, erstens derStandardverlauf ist, dass ich meine VTXO einfach erneuere, dass ich mit demServer zusammen sage, hey, ich gebe dir meine VTXO zurück und dafür erstellstdu eine neue für mich, bei der halt die Lifetime wieder resettet ist, sodass esnochmal zwei Wochen oder einen Monat lebt.
Und... der Server das macht, binich glücklich und dann habe ich das resettet und wird halt meine VTXOeinfach wieder an den Server, also meine alte VTXO wird an den Serverzurückgegeben und ich habe dann meine neue VTXO, die eine neue Lifetime hat.
natürlich das Problem, was ist, wenn derServer das verweigert und sagt, nein, ich gebe dir keine neue VTXO und dannkann ich natürlich einfach On-Chain gehen, dann kann ich sagen, ja gut,dann mache ich halt den Unilateral Exit und materialisiere halt meine VTXO undmir dann halt meine On-Chain-New-TXO. Das heißt, egal was der Server macht,ich habe immer mein Geld und ich muss nie Gefahr laufen, dass meine VTXOvon mir Gefahr VTXO eingesagt wird.
würde ganz gernenochmal versuchen, diese Begriffe nochmal klarzustellen. Also haben einen Service Provider, dasist der sogenannte Arc Service Provider. Dieser Arc Service Provider ein UTXO,der ist quasi der Halter dieses UTXOs. Innerhalb dieses UTXOs teilensich alle Teilnehmer, alle Nutzer dieses Arc Service Providers oderdieser Arc, sogenannten VTXOs. Daher kommt diese Shared UTXOs.
Es gibt ein UTXO beim ServiceProvider, innerhalb dessen sind halt diese ganzen VTXOs, die sich alleTeilnehmer teilen untereinander. mir ein bisschen geholfen hat, daszu verstehen, war nochmal darüber nachzudenken, dass wir in Lightningja was ganz ähnliches haben. Da haben wir zwei Kanalpartnerauch ein Shared UTXO. Es sind halt nur diese zweiPartner, die ein Shared UTXO haben.
Und in Arc sind es halt hunderteoder idealerweise tausende oder zehntausende Teilnehmer, diesich halt ebenso ein UTXO teilen. Was geholfen verstehen darübernachzudenken, dass UTXO Genau, der Arc-Service-Provider. hast ja gesagt, der ist trustless. Das heißt, also dem müssen wir nichtvertrauen, wie du auch ausgeführt hast. Wir haben halt immer dieMöglichkeit, dieses VTXO, das wir halten, zu uns zurückzuholen,also wieder on-chain zu nehmen. Das ist das Versprechen. Okay, sehr gut.
glaube, um einfach mal so eineGrundvorstellung von Shared-UTXO zu bekommen, reicht das. Oder, Thorsten, hast du nochirgendwie eine Frage dazu, wie man das vielleicht präzisieren könnte nochmal? Du hast gerade ja nochmaldas Beispiel mit Lightning gebracht.
Da ist ja der Unterschied, dass das jaquasi ein 2 von 2 Multisig ist an der Stelle, was ja bei dem Shared-UIT-Arc jawahrscheinlich nicht der Fall ist dass das irgendwie ein riesiges Multisig ist,wo dann alle dann in irgendeiner Form dann einen Anteil daran haben, sonderndas wird ja dann extern verwaltet. Das ist halt, weil es eineOff-Chain-Lösung an der Stelle ist.
Deswegen kann es ja in dem Sinneeigentlich gar keine richtige, es ja über eine andere Funktionalität oderMöglichkeit gemanagt an der Stelle. Idealerweisehat man ja Covenants dafür. Mhm. Damit halt klar ist, dieseUTXO, diese Shared UTXO wird nach genau diesem Schlüssel verteilt und dem Usergehört so viel von dieser Shared UTXO. weil wir halt eben momentan keineCovenants haben, werden die halt emuliert mit Pre-Signed Transactions. Und damit das Ganze trustless ist,muss halt wirklich jeder signen.
insofern ist es halt schon ein Multisig. Aber es verwendet halt Music. Also diese Schnorr Multisignatures,wo halt N-of-N-Signature, sodass halt Leute von hundert Leuten müssensignen aber am Ende hast du halt eine einzige Signatur auf der Chain. Also nach meinem Verständnissind Covenants die Möglichkeit, eben den Designraum für diesePre-Signed Transactions zu eröffnen. Aber Robin, vielleicht kannst dues noch ein bisschen präzisieren.
Ja in Bitcoinimplementiert man Smart Contracts häufig mit Graphs von Transactions. Das ist im Prinzip schon inLightning so, in ARK, in BitVM. Es sind häufig halt Graphen vonTransaktionen, von Transaktionen die ausgeführt werden könnten,aber nicht ausgeführt wurden. Covenant ist quasi, dass manfestschreibt wie eine bestimmte UTXO ausgegeben werden kann. Also dass man sagt, diese UTXO kannnur mit einer bestimmten Transaktion ausgegeben werden oder mit einerMenge von bestimmten Transaktionen.
Also dass ich jetzt fünf verschiedeneTransaktionen habe, von denen ich dann eine wählen kann. das limitiert quasi, wie dieUTXO ausgegeben werden kann. Und Großen und Ganzen ist dashalt eigentlich dasselbe wie Pre-Signed Transactions, nur dassman halt nicht pre-signen muss. Also einer Pre-Signed Transaction hatman ja eben das Problem, dass die Partei, die pre-signed könnte, noch was anderessein und dann... ...wird die UTXO dann doch anders ausgegeben als vereinbart.
Und mit Covenants geht das halt nicht. Dann ist es halt festgeschrieben, dasses nur auf diese eine Art und Weise ausgegeben werden kann und dass eskeine andere Möglichkeit dafür gibt.
Und man kann halt eben Covenantsemulieren, wenn man halt N Parteien hat, die alle wollen, dass der Covenant, alsodass diese UTXO auf eine bestimmte Art und Weise ausgegeben wird, dann könnenhalt alle N Parteien das sein und wenn das halt wirklich auch eine N auf NSignature ist, dann kann auch keine Mehrheit, also keine N-1 Untergruppekann das jetzt ändern, sondern es können nur alle zusammen ändern.
Das heißt für jeden Einzelnen ist estrustless, aber das Problem ist halt, dass solche N auf N Signatures natürlich auchhalt einen Koordinationsaufwand bedeuten und ist halt das Problem, dass alle müssenhalt unterschreiben und wenn einer nicht unterschreibt, dann ist der Covenant nichtrichtig und es ist halt in der Praxis unmöglich zu unterscheiden zwischen demFall, dass N-1 Leute auf einen warten, der jetzt nicht kommt oder halt ob N-1 Leuteböse sind und den anderen abziehen wollen.
Und Deswegen löst halt Covenants inder Praxis alles sehr, sehr elegant und macht die Dinge sehr viel einfacherals mit Pre-Signed Transactions. Aber verstehe ich dasrichtig, dass zum jetzigen Zeitpunkt, wo wir ja noch keine Covenants haben,ARK dann alle Teilnehmer in so einem Shared-UTXO müssen, was auch immerjetzt an Transaktionen passiert? Ja, wir haben noch gar nichtwirklich drüber gesprochen, wie man dann jetzt tatsächlich Transaktionen macht in ARK.
so, dass halt eigentlich für jedeTransaktion oder immer wenn Leute Transaktionen machen wollen, dannwartet man halt eine Zeit lang, bis halt genug Leute eine Transaktionmachen wollen und dann macht man die nächste Shared UTXO und in der nächstenShared UTXO der Server wieder VTXOs verteilt er die neu so, wie die User dashalt nach ihren Transaktionen wollen.
Also, ich weiß nicht, ich habe 10 und willdir 3 senden dann gebe ich halt meine alte VTXO zurück und dafür erstellt der Servermir in der nächsten Shared UTXO halt eine VTXO die 7 ist und dir eine, die 3 ist. Und das Ganze passiert halt mit soeinem Atomic Swap, dass ich meine VTXO, meine alte VTXO an den Serverzurückgebe, genau dann, wenn er mir eine neue VTXO erstellt und dir halt eineVTXO erstellt die dann halt 3 ist oder wie viel ich dir halt schicken wollte.
Und das ist halt einer der Kerntricksin Arc, das Ganze halt Atomic zu machen, sodass halt weder derUser den Server abziehen kann, noch der Server den User abzieht Vielleicht können wir nochmaleinmal den Grundbegriff von diesen Runden nochmal herausstellen, weil ichglaube, das ist einer der wichtigen Grundbegriffe, die wir brauchen, umzu verstehen, was bei ARK passiert.
Also wir hatten die Shared UTXOs,wir haben den ARK Service Provider kennengelernt und jetzt hast du geradeschon von diesen Runden gesprochen. Wenn ich das richtig verstanden habe,der ARK Service Provider diese Runden und Runden heißt, da werden tatsächlichdie ARK Transaktionen durchgeführt.
Also zum Beispiel in der erstenTransaktion haben wir, keine Ahnung, jeder erhält halt sein UTXO, so wie eres haben möchte, du einen, der Thorsten fünf und ich vielleicht nochmal einenund dann, Um eine wirkliche Transaktion durchzuführen, müssen wir warten,bis die nächste Runde stattfindet. Und das ist das, was derService Provider veranstaltet. Soweit richtig?
Ja, also das Wesentliche isthalt, dass in einer Shared-UTXO werden in dem Moment, wo die Shared-UTXO erstelltwird, werden die VTXOs dazu erstellt. Also dann wird geguckt, wie istdiese UTXO verteilt und das ist statisch das ändert sich nie. Das ist auch anders als bei anderenShared-UTXO-Modellen, in denen halt eine bestimmte Shared-UTXO neuverteilt wird unter den Nutzern. In ARK bleibt das einfach immerstatisch und wenn ich eine Transaktion machen will, dann mussich eine neue Shared-UTXO machen.
In der dann die VTXOs halt neuverteilt werden und die alten VTXOs von der alten Shared UTXO, die werdenhalt an den Server zurückgegeben. Aber eine Shared-UE-TXObeinhaltet immer grundsätzlich auch eine, dass das eine On-Chain-Transaktionan der Stelle dann auch Genau, die Shared UTXO istimmer tatsächlich im UTXO-Set vorhanden Nur die VTXOs sind halt virtuellund idealerweise nie im UTXO-Set.
Okay, mir ist gerade nochmal so ein kleines Licht aufgegangen meinem Verständnis von ARK, weil dugesagt hast, dass es statisch ist. Also wenn ich es richtig verstandenhabe, wir haben quasi Zustand 1, da hat der ARK Service Provider einen UTXO,sagen wir mal, da sind 10 Bitcoin drin. in der nächsten Runde wenn derZustand 2 erstellt wird, dann quasi ein neues UTXO erstellt. Das können jetzt zum Beispiel 11Bitcoin sein, weil noch irgendwie ein Bitcoin mit dazugekommen ist. Genau.
Aber es ist nicht so, dass dasalte UTXO quasi ausgegeben wird. Das alte UTXO verändert sich nicht,sondern die Veränderung ist halt quasi der Übergang in einen neuen Zustand dermanifestiert ist in dem neuen Shared UTXO, das der Arc Service Provider On-Chain Genau. Ja, ja, okay. muss ja auch nichtsein, dass alle VTXOs von der alten Shared UTXO ausgegeben werden.
Es wird ja immer nur irgendein Subset vonUsern sein, die gerade eine Transaktion machen wollen und alle anderen Userwollen das eben nicht ausgeben, sondern die sind vielleicht noch nicht malonline und bleiben die halt unberührt. haben wir ja zumindest schonmal das mit den Runden soweit besprochen.
Jetzt ist dann Zweifelsfall ja dann nurdie Frage, du hattest gerade eben von diesem Kniff gesprochen, wie Atomic Swapdann in diesen Runden dann gebaut wird, also wie an der Stelle, das ist ja dannder Punkt, der Connectors genannt wird im White Paper von Arc, wie wir dannan dem Stelle dann so das hinbekommen, dass wenn ich meinen UTXO zum Beispielmeinen VUTXO aufgeben will, weil ich an Paul zum Beispiel paar Satz oderein paar Bitcoin schicken möchte, diese
Transaktion ja grundsätzlich erst in einernächsten Runde dann aufgenommen wird, Wie dann sichergestellt wird, dass derASP mich nicht bescheißt dass Jan-Paul wirklich auch sein neues VTXO von mirdann oder von dem Provider dann bekommt und ich dann auch sicher gehen kann, dassJan-Paul das dann wirklich auch hat und alles so ist, wie ich auch haben möchte.
Ja also meine VTXO ist haltvon 2 Multisig zwischen mir und ASP signed halt grundsätzlich erstmal für mich eineExit-Transaktion, sodass ich halt immer on-chain gehen kann, wenn ich will. Also am besten machen wires mit einem Strawman. Also ich erkläre erstmal die Version,die halt nicht funktioniert und dann, was das Problem da dran istund dann, wie man das Problem fixt.
Die naive Herangehensweise die eben nichtfunktioniert, wäre einfach, dass ich sage, ah ja, okay, ich seine das jetzt einfachso, dass es an den Server zurückgeht und da es ja eine Two-of-Two ist und meineExit-Transaktion ein gewisses Timelock hat, würde die VTXO damit halt schonan den Server zurückgehen, weil er halt einfach diese Transaktion ausführenkönnte, bevor mein Timelock sich öffnet.
Und das wäre die naive Variante unddas Problem daran ist natürlich, dass der Server mich dann bescheißen könnte. Wie stelle ich sicher, dass derServer mir tatsächlich mein neues VTXO erstellt und nicht einfach wegläuftund auf Nimmerwiedersehen sagt. Und das funktioniert, indem ich einfachin diese Transaktion noch einen weiteren Input dazu mache und dieser Input,der ist ein Output von der Transaktion die neue Shared UTXO erstellt. Shared UTXO wird ja von einerbestimmten Transaktion erstellt.
Es gibt ja eine Transaktiondie das machen wird. Und da sagen wir einfach, die VTXO Diejetzt noch einen weiteren Output haben. Das kann ein Zero-Start-Output sein,der quasi einfach nur Logik enkodiert und gar kein Value enkodiert. Aber... Dieser Output wird ja ebenüber die Transaktions-ID identifiziert. Also der Hash der Transaktionist die Output-ID. Das ist einfach, wie das dann ja, ja genau, alsonormale Bitcoin-Konzentrationen ja.
jetzt nehme ich diesenConnector-Output der repräsentiert quasi den State, dass die neueShared-UTXO erstellt worden ist. Weil dieser Connector-Output existiertgenau dann, wenn die Transaktion erstellt worden ist, die halt dieneue Shared-UTXO erstellt hat. Okay, vielleicht können wirnochmal einen Schritt zurückgehen. das ist ein wichtiger Punkt. ja, absolut. Deswegen würde ich da ganz gerneversuchen, das zu verstehen.
Da hatten wir auch im Vorgespräch,Thorsten und ich, ein bisschen gerätselt, wie das funktioniert. Aber, okay, ich glaube, wir habenverstanden, dass es trivial unsicher, wenn ich einfach hingehe und sage,hey, ich gebe meinen VTXO auf. Also ich sage dem Arc Service Providerhier, ich gebe meinen VTXO auf und bitte, lieber Arc Service Provider,erstell doch bitte ein neues VTXO. Wir machen mal den ganz einfachen Fall. Ich habe einen Bitcoin und ich möchteeinen Bitcoin jetzt an Thorsten schicken.
Es wäre trivial unsicher, wenn ichjetzt einfach sage, ich gebe meinen einen VTXO auf und vertraue dem ArcService Provider, dass er dem Thorsten ein neues VTXO in der nächsten RundeIn dem nächsten Shared-VTXO erstellt. Genau. Also dieses Problem wollen wir lösen.
Und es funktioniert, wenn ich das jetztrichtig verstanden habe, so dass... In dem neuen Shared-UTXO, in dem das neueVTXO für den Thorsten erstellt wird, damit eine quasi, also nur eine, also jetzt ganzsimpel, eine irgendwie Transaktion eine leere Transaktion diese Connector-Output ist einOutput, keine Transaktion. Wie bitte? Das ist ein Output. Okay, also diese, okay, okay, okay. Also zu dem VTXO kommtnoch ein Output dazu. dem Shared-UTXO. Wir sind on-chain, ne? Ja. Ja, okay.
In dem Shared-UTXO kommt jetzt nochein Output dazu und dieser Output stellt irgendwie sicher, das habeich noch nicht ganz verstanden, dass ich trustless mein VTXO anden Service-Provider aufgeben kann. Das ist das, was wir versuchen wollen.
Okay. das geht genau deshalbweil ich dann jetzt diesen Output nehme, also bevor das on-chain ist, sagt derServer mir, hey, ich werde jetzt diese Transaktion erstellen, in der dann eineneue Shared-UTXO erstellt wird und da wirst du dann deine VTXO drin haben,ich werde den Tree dann mit ihm signen und so weiter und dann weiß ich auch,okay, wenn diese Transaktion on-chain geht, dann werde ich meine VTXO haben.
Das ist einfach durch die Artund Weise, wie diese Shared-VTXO strukturiert ist ist das garantiert. Jetzt ist nur die Frage, wie kann ichden Server dazu zwingen, tatsächlich diese Transaktion auszuführen oder wiekann ich sicher sein, dass der Server meine alte VTXO nur dann bekommt, wenn ertatsächlich diese Transaktion ausführt.
Und das geht halt einfach dadurch,dass der Server dieser Transaktion einen weiteren Output hinzufügt unddie Existenz dieses Outputs ist quasi dann der Beweis dafür, dass dieseTransaktion ausgeführt wurde, weil der Output kann ja nicht existieren,ohne dass diese Transaktion ausgeführt Mhm. Und deswegen nehmeich diesen Output und nehme den als Input zu der Transaktion mit derich meine alte VTXO ausführe Ja? also soweit ist es mir klar. Also ich nehme diesen Outputquasi als Beweis dafür. Oder doch.
meine Transaktionmit der ich meine VTXO aufgebe. Ja. Und damit kann ich meinenVTXO erst aufgeben. Richtig? Wenn ich diesen Output Ja, also ichpresigner eben diese Transaktion mit der ich meine VTXO aufgebe. Jetzt kann der Server die nur dannausführen, wenn er auch vorher die Transaktion ausgeführt hat,mit der er das neue VTXO erstellt. Mhm. Weil meineTransaktion ja abhängig ist. Sie ist abhängig von dem Output,der die neue Shared UTXO erstellt. Thorsten, istdas hier klar geworden? Ja, so grob.
Aber vom Grundprinzip ist es jadann so, dass wir ja erst, in Anführungszeichen, den neuen Zustandalso der Service Provider erstellt erst den neuen Zustand quasi in Zustand2 und erst dann quasi revoke ich meinen Zustand 1 an der Stelle dann. Also wir haben quasi keine direkte, alsoeine zeitliche Abhängigkeit Ich würde jetzt instinktiv erwarten, dass quasi1 nach 2 quasi so und hier ist es jetzt in dem Sinne ja 2 ist quasi die Quellefür damit einzubauen funktioniert.
Ja, aber der Server wirddie Transaktion nicht on-chain machen. Also die Transaktion die die neueShared-UTXO erstellt, macht er erst on-chain, nachdem ich ihm meineAufgabetransaktion gegeben habe. ist das quasi eineKommunikation, alles dann, die ich quasi über ein direktes Kommunikationsprotokollinnerhalb von ARK mit dem Service Provider händle dann off-chain? Ja, also das Wesentliche isthalt, dass der Server vorhersagen kann, wie seine Transaktion aussehen wird.
Er kann ja sagen, hey, ich werde eineTransaktion machen, die wird ein neues Shared-UTXO erstellen und da wirst dudein Geld drin bekommen und dann kann ich das alles überprüfen und dann weißich, wie die Transaktion aussehen wird. Also ich kann die Transaktions-IDberechnen, bevor sie auf der Chain landet.
Und dann nehme ich die Transaktions-IDund identifiziere damit den Output, den diese Transaktion erzeugen wird unddann nehme ich die als Input für meine Aufgabetransaktion und dann sign ichmeine VTXO zusammen mit diesem Output, mit diesem Connector-Output und danngebe ich diese Pre-Signed-Transaction dem Server zurück und dann kommuniziereich damit, hey Server, du kannst meine VTXO haben, aber nur dann, wenn dutransaktionierst Wenn du diese Transaktion ausführst, die du mir gerade gezeigt hast
Das heißt, das neue Shared-UTXOmit dem neuen Zustand wo dann ich von Jan-Paul dann einen Bitcoin bekomme, dasgeht dann ja auch dann On-Chain, weil ja dann auf der Basis ja dann in demfinalisierten Zustand ja dann auch dann ein neues UTXO generiert wird, On-Chain. Und aber die Aufgabetransaktion die dannJan-Paul dann mit dem Service-Provider dann macht, die ist rein virtuellinnerhalb von dem ARK-Protokoll.
Ah. idealerweise wird derserver die auch nie brauchen die brauche eigentlich nur wenn ich bescheiße wennich jetzt sage ich mache jetzt doch noch mal ein unilateraler exit obwohl ichschon die vtx zurückgegeben hat dann kann der server sagen hey moment malbevor du jetzt wirklich ausüben kannst kann ich jetzt die aufgabe transaktionbenutzen um mein geld zurückzuholen aber der happy path funktioniert eigentlichso dass halt alle user nach einer weile
ihre vtx os zurückgegeben haben Und dannläuft einfach irgendwann dieses Timelock aus und dann gehört die UTXO, dieseShared UTXO einfach wieder dem Server. Ist das der Grund, warumes Transaktion mit einem Timelock gibt, dass irgendwann alles zurückan den Service Provider geht?
Einfach um sicherzustellen, dass nichtzu einem späteren Zeitpunkt einer der Nutzer dieses ARCs hingehen kannund einen alten Zustand hätten wir in Lightning gesagt, veröffentlicht kann,beziehungsweise ein veraltetes VTXO nimmt und das versucht On-Chain zu bringen. Kommt daher diese dass alle VTXOszurück an den Service Provider gehen? Ja, alsoes hat mehrere Gründe.
Also das erste ist halt, dassTransaktionen grundsätzlich so funktionieren, dass es halt eben, dassman die UTXO an den Server zurückgibt und dann eine neue dafür bekommt. das führt dann halt dazu, dass dannirgendwann diese Shared-UTXO ziemlich löchrig ist, dass größtenteilsder Server diese UTXO hat und dann nur noch wenige VTXOs drin sind. Und ist halt ein Liquidity-Problemfür den Server, weil der Server da ja nicht raus kann. Also sein Kapital ist da dringelockt bis er halt alle VTXOs hat.
Und deswegen macht man es dem Serverhalt leicht und sagt, naja, in vier Wochen gehört dir sowieso alles. Und jeder User muss halt innerhalbvon vier Wochen einmal eine Transaktion machen, beziehungsweisehalt einfach ein Update machen, was im Prinzip einfach bedeutet,er schickt die VTXO an sich selbst. dann halt... Um dem Server die Shared-UTXOwieder zurückzugeben sodass dem Kapital nicht die ganze Zeit gelockt ist.
Dann würde er dann quasi dieseShared-UTXO, die quasi ursprünglich ja dann quasi vollständig gefüllt war inirgendeiner Form mit N würde dann nach und nach dann quasi absickern in irgendeinerForm, dass nachher dann quasi dieses Shared-UTXO oder was dann irgendwie10 Bitcoin hat, aber im Endeffekt VTXOs sind dann nur noch irgendwie500.000 Satz oder sonst irgendwas drin.
Und wenn dann halt diese Zeit dannabgelaufen ist, dann wird ja quasi ein neues Shared-UTXO gebildet wo erdann wieder das komplette Shared-UTXO, auch alle virtuellen dann abbildet,die dann dann quasi, dass es wieder vollständig quasi kapitalisiertist, nenne ich es jetzt einfach mal. Okay. Okay, ich weiß, es ist einsuper komplexes Thema, Arik Wir haben jetzt mal versucht, da so ein bisschenreinzusteigen und zu erklären, wie diese Transaktionen funktionieren.
packe auf jeden Fall in die Show Notesganz, ganz viele Links, mit denen ich versucht habe, mir das Thema ein bisschenanzueignen Da kann der interessierte Hörer auf jeden Fall nochmal reinhören. Lass uns vielleicht nochmalein Level höher gehen. hatten ja angefangen mit,Lightning hat ein paar Probleme. Eins der wichtigsten Probleme wardas Thema Inbound-Liquidität für jeden Nutzer im Lightning-System.
Also erst Geld empfangen, wennmir meine Gegenpartei also mein Kanalpartner Liquidität auf seinerSeite zur Verfügung stellt, mit dem ich dann Satz empfangen kann. Das ist das Inbound-Liquidität-Problem,das wir in Lightning haben. Inwiefern ist das dennjetzt bei ARK besser? Naja, ARK, wieder ganzHigh-Level gesprochen, shiftet das Liquidity-Problem von den End-Usernhin zu dem ASP, zu diesem Server, zu dem ARK Service Provider.
Der hat das Liquidity-Problem und dieEnd-User haben gar kein Liquidity-Problem. Ich kann einfach jedem User, alsojedem neuen User einfach was schicken ohne dass der vorher Kapital lockenmuss oder dass jemand für ihn vorher Kapital locken muss, außer der Server. Der Server muss natürlich selberfür jede Shared UTXO nochmal Kapital da einspeisen in das System.
Man geht halt davon aus, dass derdas dann halt professionell macht und dass das für den deutlich einfacherist als jetzt in Lightning, wo das halt einfach hin zur Kunst machensoll, so der Durchschnittsmensch. Einzige Voraussetzungwäre ja dann an der Stelle, dass Empfänger Der dann neu dann daranpartizipieren möchte, eine dedizierte ARK-Wallet braucht, die dann halt dannauch dieses Kommunikationsprotokoll dann mit dem ASP dann auch Ja, auf jeden Fall. Okay, aber dasist ja schon wichtig.
Also du ARK nutzen möchtest, dannbrauchst du erstmal, also die einzige Voraussetzung ist, dass du eineARK-fähige Wallet hast und dann kannst du bereits ein VTXO empfangenSo einfach wäre das im Grunde, ne? Ja, okay, ja.
also ich wollte nur nochmal kurz anmerken, da wird ja dann auch dann, oder da muss ja dann auchdrin sichergestellt werden, dass halt bei diesem zwei Wochen vier WochenIntervall dann immer wieder die VTXOs ja dann auch dann wieder hier quasirotiert werden und sowas, das muss ja dann auch alles dann innerhalb von derWallet irgendwie sichergestellt werden.
ich mich dann wieder die Frage stelle,gerade wenn wir dieses, wir haben ja dann dadurch, dass wir ja keine Covenantshaben, das wir am Anfang besprochen haben, haben wir jetzt ja, stand jetztja immer noch dieses Problem, dass wir ja das nicht asynchron machen können,sondern wir müssen ja online sein. Das heißt, es ist ja quasi einProblem, dass es eigentlich nur synchron aktuell funktioniert. Ja, das isttatsächlich ein Problem.
ist der größte einer der zwei großenDrawbacks von Arc ist auf der einen Seite eben das Problem, Liquidity-Problemenexistiert und auf der anderen Seite eben dieses Koordinationsproblem fürdiese Covenant Emulation, insbesondere wenn man das halt jetzt dann auf MobileWallets machen will und insbesondere, wenn man es auf IOS machen will, Dennes ist halt so, dass iOS einem kaum erlaubt Tasks im Hintergrund zu machen. Also ich glaube höchstens für fünfSekunden oder so oder sogar noch weniger.
Und bedeutet dann halt, wenn dieseSigning Session mehr als fünf Sekunden dauert, Geht es einfach nicht. Dann funktioniert dasnicht mit einem iPhone. Und das ist natürlich ziemlich nervig. Und deswegen wäre es auchsuper, wenn es Covenants gäbe. gibt auch noch weitere Probleme. Zum Beispiel kann man Protokoll dossen. Also, dass man einfach sagt, hey, ja,ich möchte eine neue VTXO erzeugen.
Hier ist meine Transaktion und dannbin ich halt in der nächsten Runde drin und dann muss ich halt auch mit sein. Dann bin ich halt einer von den N Leuten,die da jetzt die Shared VTXO sein müssen. Und dann höre ich einfach auf. Dann mache ich einfach nichts. Dann müssen die wieder von vorne starten. Und wenn ich dann jetzt 100 Transaktionenmache mit 100 verschiedenen Accounts dann kann ich das halt für sehr lange anhalten.
das kann natürlich auf der einenSeite zu schlechter Nutzererfahrung führen, aber auf der anderen Seitekann es auch Security relevant sein, wenn ich das lange genug aufhaltenkann, um Justice Transactions oder Lightning Channels zu dossen, dannkann es halt auch Security relevant sein, also dass Leute Geld verlierenweil Protokoll einfach nicht fortführt. ist auf jeden Fall ein Problem. Und ja, Covenants insbesondere, alsoCTV ist ja einer der Themen oder einer der Opcodes, die da besprochen werden.
Und CTV würde das komplett lösen,also sowohl das DOS-Problem als auch das ganze Interaktionsproblem. Damit wäre das sehr viel einfacher,aber momentan muss man es halt eben von hinten durch die Brust ins Auge emulierenmit diesen End-of-End-Signatures. Ja Okay, glaube, glaube,dabei können wir es belassen. zu bauen, Arc, aber es wäre schöner,wenn wir Arc mit Covenants hätten. Ich glaube, das hast du schon ausgeführt. bin jetzt nichtda der Experte in dem Bereich.
Ich glaube auch, haben da sehr vielEnergie reingesteckt um das so weit wie möglich zu optimieren und die haben dasauch sehr weit getrieben Es ist trotzdem nicht ganz gelöst und es wäre sehrviel schöner mit richtigen Covenants, aber es ist kein Showstopper aber esist nicht schön, würde ich mal sagen. Mhm. Eine Frage die ich mir noch nichtso richtig erklären konnte, war, was kommen denn auf den Nutzereiner ARK an Transaktionskosten zu?
Also irgendwie, wir habenOn-Chain-Transaktionen, die der ARK Service Providerja immer wieder durchführt. Diese Kosten wird er ja sicherlichan den Nutzer der ARK weitergeben. Also, gibt es da weitere Faktorendie jetzt da reinspielen können in die Transaktionskosten? Also, ich kann mir vorstellen, es gibthalt diese On-Chain-Transaktionskosten. Gibt es weitere Kosten, die aufden Nutzer zukommen könnten?
Und kann man irgendwie, ich will jetztkeine Abschätzung machen, ich will jetzt nicht irgendwie, dass wir hinstellen undsagen, es wird irgendwie fünf Satz per WeBite kosten oder was auch immer, sonderndass man mal so einen Eindruck davon bekommt, wo kommen Transaktionskosten her? Ist es vielleicht teurer als Lightning? Ist es günstiger als Lightning? Was sind so die Vorstellungen? Also, alles, was RichtungTransaktionskosten geht.
Ja, ist so ein bisschen dasBootstrapping-Problem, also je größer der Arc ist, desto günstiger wird es. Denn es ist ja quasi so, dass hat immerdiese Shared-UTXOs und da ist jetzt eine Menge an Leuten drin und quasi da werdendann halt einfach die Transaktionskosten für die On-Chain-Transaktionenaufgeteilt zwischen diesen Leuten. Und wenn das 5 Leute sind,dann ist das natürlich teurer, als wenn es 500 Leute sind.
Und idealerweise hätten wir halt sehrviele Leute da drin, weil dann sind die Transaktionskosten nahe Null. dazu braucht man natürlich erstmalgenug User und dazu braucht man halt nur 500 User, sondern man braucht 500User, die jetzt gerade im Moment, in dem ich auch eine Transaktion machen willwollen die auch eine Transaktion machen. Das heißt, braucht sehr vieleUser, damit das funktioniert. Derart flüssig funktioniert.
Funktioniert auch sicher mit 10 Usern odermit 100 Usern, aber die Transaktionskosten werden halt zu der Anzahl der User, diegerade in der Runde sind, günstiger. Wenn dann halt eine On-Chain-Transaktionmomentan X kostet und ich halt 100 Leute da drin habe, dann zahleich halt X durch 100 anstatt X. je mehr Leute das sinddesto günstiger wird es.
Aber auf der anderen Seite hat mannatürlich insbesondere ohne Covenants das Problem, je mehr Leute das sind,desto schwieriger ist dieses Pre-Signing und desto fehleranfälliger ist diesesPre-Signing, beziehungsweise desto wahrscheinlicher ist es, dass einervon den Leuten, die pre-signen sollen, irgendwie aus irgendeinem Grundnicht das Pre-Signing zu Ende macht. deswegen ist das so einSpannungsverhältnis zwischen der Anzahl der User und den Fees.
Und Wenn wir dann Covenants haben, istdas vermutlich dann kein Problem mehr, dann kann der Server im Prinzip beliebiggroße Runden haben, aber dieser Emulation hat man doch noch das Problem, dassdie Anzahl der User schon irgendwie durch praktische Gründe begrenzt ist. sind halt jetzt die Happy Path Fees,also wenn alles glatt läuft, dann sich die Fees so, aber muss ja auch überdie Worst Case Fees reden und das ist halt erkläre ich das, also diese VTXOssind üblicherweise in einem Tree.
Rein naiv wenn man jetzt das naiv designenwürde, könnte man sagen, wir haben diese Shared UTXO und für die presignen wir eineTransaktion und diese eine Transaktion hat 100 Outputs Aber da könnte jetzt dannhalt ein User hingehen und sagen, ja, ich will meine VTXO materialisieren unddann macht er die Transaktion on-chain und plötzlich sind alle Leute on-chain. Da sind jetzt 100 Leute on-chain,obwohl eigentlich nur einer raus wollte.
Und das kann man halt ein bisschenoptimieren, indem man halt so einen Baum von Transaktionen presigned. Also man hat halt eine Transaktionund die hat dann vielleicht zwei Outputs und jeder der beiden Outputshat dann nochmal eine Transaktion mit zwei Outputs und so weiter. Und so baut man dann halt einenBaum auf von Transaktionen und dann die Blätter, also die letztenOutputs von all den Transaktionen entsprechen dann den VTXOs der User.
Und da ist es dann nun so, wenn ich dannhalt so einen Unilateral Exit machen will, dann muss ich meinen gesamten Pfadvon der Shared UTXO bis hin zu meiner VTXO Also der ganze Subbaum oder Pfaddurch den Baum, sagt mir eine Informatik, den muss ich halt on-chain bringen. Jetzt grob gesprochen, angenommen dasind jetzt 1000 User oder ich weiß nicht, ob 1000 ein bisschen viel ist,sagen wir 128 User sind in einer Runde drin, heißt das, ich habe da glaubeich eine Tiefe von 7 Transaktionen.
Und das bedeutet, eben jetzt diedurchschnittlichen Kosten momentan X sind, muss ich in der Lage sein,7 mal X bezahlen zu können um meinen Unilateral Exit zu machen, weil ich eben7 Transaktionen On-Chain machen muss, anstatt nur eine, um halt eben meinengesamten Pfad da ausrollen zu können. Und Ja, das will man natürlichvermeiden, sollte idealerweise in der Praxis eigentlich nie passieren,dass ich das machen muss, solange der ASP auch ehrlich ist, beziehungsweisenicht aufhört, Business zu machen.
So lange muss ich das auch nicht on-chainmachen, aber um halt meine Rechte wie sagt man, enforcen zu können, also meine Rechtedurchsetzen zu können, muss ich halt in der Lage sein, das ungefähr siebenfacheder durchschnittlichen Fees bezahlen zu können, um rauszukönnen wenn ich will. Ja, das war eine echtsuper Erklärung, Robin, vielen Dank.
Also wenn ich das richtig verstandenhabe, wir brauchen diese Möglichkeit des einseitigen Exits, um halt die Ehrlichkeitdes ASPs, des Arc Service Providers auch so ein bisschen zu erzwingen. Das ist einer der Hebel, mit dem wir quasiden Arc Service Provider dazu zwingen können, sich im Sinne seiner Nutzer zuverhalten, denn sonst kann ich ja immer noch on-chain gehen, aber es kostethalt abhängig von der Anzahl der Nutzer innerhalb dieses Shared UTXOs, kostetmich das halt Transaktionsgebühren.
Und das kann schon relativteuer werden für den, der diesen unilateralen Exit machen möchte. Okay, das ist natürlich einewichtige Information nochmal. Ja skaliert aberlogarithmisch, also jetzt für 128 User wäre es 7, aber für 1000 Userwäre es halt 10 oder so und mit Ja. 32 hättest du dann 4Milliarden oder so, also schon, ja, ja schon ordentlich Geld kosten. jeden Fall, das ist klar. Ja, aber super.
Also ich glaube, damit haben wirglaube ich die zwei wesentlichen Punkte bei den TransaktionsgebührenCool, dann lass uns doch vielleicht nochmal Zukunft schauen, ganz kurz. die Frage ist natürlich, wannkönnen wir endlich Arc nutzen? Ich hatte es in der Einleitungja schon mal kurz gesagt, es gibt jetzt von Second, das ist eineFirma die an einem Arc-Protokoll, einer Implementierung arbeitet. Die haben es jetzt aufSignet veröffentlicht. Das ist natürlich weitweg noch von Mainchain.
weiß nicht, Robin, hast du da so einengewissen Einblick, da der aktuelle Arbeitsstand ist bezüglich Arc? Ich glaube, sie habenschon mal Mainnet einmal kurz getestet haben dann quasi einmal kurz denServer angeworfen und die Leute ein paar Transaktionen machen lassenund das dann wieder ausgeschaltet. Ich bin nicht so wirklich im Bilde überderen Roadmap, aber was ich halt sagen kann, ist auf jeden Fall der Steven Roos,ich glaube, der ist der CEO von dem, ist auf jeden Fall ein Top-Entwickler.
Der hat auch für Blockstreamvorher gearbeitet, hat jahrelang an Rust-Bitcoin gearbeitet. Und er was macht, dannhat das Hand und Fuß. Und ich denke, da wird ziemlich schnellwas kommen, weil er ist sehr dahinter dass das bald auch wirklich live geht. Gibt es von Burak, also der,der quasi das Protokoll beziehungsweise das ganze Thema sich ja ausgedacht hat,irgendwie eine Art Roadmap oder sowas dass dann eine Referenzimplementierungvon seiner Seite dann kommt?
Oder ist das jetzt wirklich so, esgibt dieses Protokoll und das kann sich jetzt jeder nehmen und da jetzt dannseine eigene Implementierung draufbauen? Oder gibt es da irgendwie, wie esbei Cashew war, gab es ja irgendwann auch mal initial ja auch eineReferenzimplementierung und jetzt haben da alle möglichen Leute ja ihr Walletsund was weiß ich was draufgebaut? Das istein schwieriges Thema. Ich will da auch nicht allzu sehraus dem Nähkästchen plaudern.
Aber es ist so, dass ursprünglich haltder Burak mit dem Steven und dem Tiero zusammen eine Firma gegründet hatten,deren Ziel es war, ARK umzusetzen. will es jetzt mal nichtbewerten öffentlich. Jedenfalls ist das auseinandergegangenund glaube, der Burak hat sich da auch ziemlich zurückgezogen Derdann irgendwann sich angefangen mit Brol-Ups zu beschäftigen, einbisschen entfernt sind von ARK. Und hat eben der Steven dieses Secondgegründet und Tiero hat ArcLabs gegründet.
Und also insofern gibt es schontatsächlich zwei Implementierungen von diesem Protokoll Mhm. Konkurrenz belebt das Geschäft. Es ist schon mal gut, dass es dannwenigstens zwei Firmen gibt, die versuchen Ich gehe davon aus, dass man mit ARKals ARK-Service-Provider wahrscheinlich auch, wenn alles gut läuft, natürlichauch ganz gutes Geld verdienen kann. Da ist natürlich dann auch eine Motivationdahinter, die Implementierung möglichst schnell auf den Markt zu bringen.
Wer zuerst da ist, man hat natürlich denKapitalbedarf das muss man glaube ich dann auch immer dann sagen, dass man dannnatürlich dahin dann erstmal um den ASP zu auch erstmal ja einiges an Geld auchmitbringen muss, damit das dann auch entsprechend in der Größe dann auch kann. Das ist ein ganzwichtiger Punkt, das habe ich eben gar nicht benannt. Eben habe ich einfach nur dieseRechnung aufgemacht von wegen die On-Chain-Fees, aber dieOn-Chain-Fees reichen ja gar nicht.
Man muss auch noch den ASP bezahlenfür die Kapitalkosten, die der hat. Das Wobei da ist, glaube ich soweitich es verstanden habe, ist es nicht ganz einfach abzuschätzen, wie viel Liquiditätdenn jetzt oder wie viel Kapital der Arc-Service-Provider tatsächlichzur Verfügung stellen muss, oder?
Okay, aber also ich meine, esist ein Thema, wenn man sich ein bisschen mit der Materie beschäftigtkommt die Frage immer wieder auf, was sind die Kapitalkosten für denArc-Service-Provider, wie viel Liquidität muss er tatsächlich zur Verfügung stellen. Genau, packen auch mal in die Shownotesein, zwei Links dazu, kann man sich das auch mal anschauen was da diskutiert wird. ich würde jetzt so Richtung Ende kommen.
Robin, hast du noch was wo du denkstokay, das sollten wir vielleicht zumindest mal erwähnt haben kurz oder solltenwir auch nochmal kurz besprochen haben? Also ganz grob gibt esnoch halt die Idee, dass man halt Privacy damit einbaut, dass man haltquasi in diesen Runden Coinjoins macht, sodass der Server auch nicht weiß,wer da jetzt was gemacht hat, also wer da welche VTXO's erstellt hat. Das ist noch so eine Idee. Ich glaube, das ist aber ein Level anKomplexität, das momentan keiner umsetzt.
Was wir gar nicht besprochen haben,ist natürlich die Interoperabilität mit Lightning, es halt möglich ist,dass man Lightning Channels in VTXO's drin hat und dass man dann ja halteben Lightning als zentralen Settlement Layer verwenden kann und dass man ebenhalt auch Leute bezahlen kann, die eben selber keine ARK Wallet haben. ist noch so eine Sache. glaube, grob gesagt, halt auch ausZeitgründen, senden ist sehr einfach, soweit ich das in Erinnerung habe. Empfangen ist nicht ganz trivial.
vielleicht was andersrum. Nee, es war so rumgeschrieben. Senden ist sehr einfach undempfangen ist nicht ganz trivial. Da muss man, glaube ich demServer ein bisschen vertrauen. damit zu tun, dass es eben nichtdiesen Proof of Publication gibt. Also Lightning hängt ja davonab, dass man dieses Pre-Image veröffentlicht im Zweifelsfall. Und hier geht das halt nur dann,wenn man dann On-Chain geht. Ist eine bisschen längere Geschichte,aber das ist so die Kurzfassung davon.
Ja, also ich glaube, wirwollten auch nicht jetzt in alle Tiefe und alle technischen Details reingehen. Wir sind schon relativ tiefreingegangen in das Thema. Genau, ich glaube, wirhaben ganz ausgelassen. Wir haben immer nur von denrundenbasierten Zahlungen gesprochen. Es gibt ja noch Out-of-Round-Payments,läuft unter dem Stichwort R-Core. es gäbe sicherlich noch mehr, was manirgendwie in der Tiefe besprechen könnte. , bis dahin würde ich aber erstmalsagen, reicht es für heute.
Robin, echt vielen, vielen Dankdass du dir die Zeit genommen hast. fand es super interessant. Ich werde das Thema ARK auf jeden Fallnoch ein bisschen enger verfolgen in der nächsten Zeit, weil ich glaube,dass es wirklich spannend ist. Thorsten auch dir vielenDank, dass du dabei warst. Ich würde sagen, focus onthe signal, not on the noise. Ciao, ciao. Macht's gut. ciao. Danke Tom.