0:00

Herzlich willkommen bei Nodesignal, deine Bitcoin-Frequenz. Heute mit deinen Nodes,

0:26

dem Thorsten. Hi Thorsten. Hallo, schön mal wieder mit dir eine Folge aufzunehmen. Genau,

0:32

ich bin der Jan-Paul und wir haben den Gast der letzten Woche da, den habt ihr erst letzte Woche

0:38

gehört, liebe Zuhörer. Heute wieder der Merch. Hi Merch. Servus. Merch, vorstellen wollen wir

0:46

dich nicht mehr, aber erzähl doch mal, was hast du so die letzten Tage getrieben,

0:49

irgendwas Erwähnenswertes? Ja, wir hatten, ja ist schon mehr als ein paar Tage her, aber wir hatten

0:57

im November die Bitcoin Research Week hier bei Chaincode. Wir hatten 40 Leute etwa da für,

1:04

also Akademiker und Bitcoin-Entwickler, Lightning-Entwickler, andere nicht akademische

1:12

Researcher und das war ein Low-Device-Event, also Handys und Laptops waren beiseite gelegt und die

1:20

Leute sollten tatsächlich einfach nur miteinander reden und zwar den ganzen Tag. Und wir haben eine

1:27

ganze Menge Themen abgeklappert, haben viel neue Ideen und auch einfach mal schwierige Themen

1:35

angegangen, wie was ist denn eigentlich Rough Consensus und wie kriegen wir den? Also natürlich

1:42

konnten wir nicht alle Probleme lösen, aber wir haben glaube ich viele coole Gespräche gehabt und

1:48

ein paar Kontakte geknüpft. Hoffentlich gibt es ein paar Arbeitsgruppen, die daraus entstehen und

1:54

vielleicht ein paar Sachen vorantreiben. Cool. Du hattest gerade eben gesagt, im Vorgespräch,

2:00

du hast dich auch schon wieder bei einigen Sachen angemeldet, wo du wieder mitarbeiten willst,

2:04

obwohl du eigentlich keine Zeit hast. Ja, es gibt ein Coin Selection, also ein paar Leute waren

2:11

daran interessiert, das Thema Coin Selection formell zu definieren und vielleicht ein Paper

2:16

drüber zu schreiben. Da will ich mitsprechen. Ich habe mich glaube ich noch für zwei andere Sachen

2:25

mit auf die Liste setzen lassen, aber erstens weiß ich gerade nicht mehr genau welche und

2:29

da muss man auch mal gucken, wie weit die dann weiterlaufen und so. Das heißt, also du bist

2:38

weiterhin nicht beschäftigungslos. Das kann man glaube ich festhalten. Es ist echt tragisch,

2:45

dass der Tag nur 24 Stunden hat. Gut, dann lass uns doch gleich mal versuchen, in das Thema

2:53

überzugehen. Blockzeit. Achso, bevor wir das tun. Die Blockzeit. Merch, hast du die Blockzeit?

3:00

Die Blockzeit ist zurzeit 873.112. Ja super, dann haben wir ja jetzt die Blockzeit. Wir wollen

3:09

heute über das Thema Truck Transaktionen und Package Relay sprechen. Also es wird mal wieder

3:15

ein kleiner technischer Deep Dive für euch, aber bevor wir das machen, bevor wir so richtig in

3:20

die tiefsten Tiefen hinuntersteigen können, Merch, vielleicht kannst du einmal erklären,

3:24

was ist denn eigentlich das Problem? Warum müssen wir uns da um etwas kümmern?

3:28

Ja, leider hat Satoshi entschieden, dass man unbestätigte Transaktionen aneinanderketten kann

3:37

und nicht nur eine einzelne unbestätigte Transaktion absondern kann. Und das ist

3:45

kompliziert manchmal. Das ist natürlich toll, weil wir dann zum Beispiel Child Pays for Parent

3:50

verwenden können, um Transaktionen zu bumpen oder mit Lightning vielleicht dann auch Anker

3:55

Outputs verwenden können, um die Transaktion, also eine einseitige Schließung eines Kanals,

4:03

zu beschleunigen. Aber naja, jedenfalls das Thema ist halt, wie kriegen wir eigentlich hin,

4:11

dass unbestätigte Transaktionen schnell bestätigt werden, weil für manche Protokolle,

4:16

wie zum Beispiel Lightning, es wichtig ist, dass man innerhalb von einer begrenzten Zeit

4:21

eine Bestätigung kriegt auf eine Transaktion. Da gibt es ein paar Probleme, die das schwierig

4:27

machen oder die einen Antagonisten, einen Gegner erlauben können, einen zu verlangsamen. Und wir

4:35

wollen dann von dort, glaube ich, darauf kommen, wie Truck Transactions helfen, dieses Problem zu

4:42

verkleinern. Und vielleicht auch in dem Kontext, wie Pakete eben auf dem Netzwerk versendet werden,

4:50

weil die im Zusammenhang von Truck Transactions wichtig sind.

4:54

Vielleicht kannst du noch mal versuchen, in einem Satz zu erklären jeweils,

4:58

was sind Truck Transaktionen und was ist Package Relay?

5:02

Ja, okay. Truck Transaktionen, ich will immer auf Englisch reden, dann sofort. Truck Transaktionen

5:09

sind Transaktionen, die der Sender deklariert, dass sie nicht in eine große Struktur von

5:21

unbestätigten Transaktionen eingepflegt werden können. Der Sender bittet, dass die in einem

5:27

kleinen Cluster bleiben müssen und bittet die Nodes eben, dieses Verhalten zu entforcen.

5:35

Also klein heißt …

5:39

Also, genau. Also, diese Transaktion, die ich veröffentliche, ist eine Truck Transaktion,

5:46

und da sage ich irgendwie darüber aus, dass die nur ein Kind haben kann.

5:50

Ein Kind oder ein Älter.

5:53

Oder ein Älter. Aha, okay.

5:55

Und also, es ist eine selbst auferlegte Beschränkung der eigenen Transaktion. Also,

6:01

der Sender selbst macht dieses Label und das führt dazu, dass die Nodes, die diese BIP

6:08

implementieren, dass die eben den Verwandtschaftsgrad der Transaktion beschränken.

6:17

Du hast gerade, vielleicht greife ich jetzt schon ein bisschen vorweg, aber du hast gerade

6:22

Cluster gesagt. Das verweist uns ja wieder auf die Folge von vor vier Wochen, wo haben

6:26

wir es aufgenommen, aber letzte Woche habt ihr, liebe Hörer, das erst gehört, wo wir

6:30

über Cluster Mempool gesprochen. Wie hängt der Cluster, was wir letzte Woche über ein

6:34

Cluster Mempool besprochen haben, jetzt damit zusammen? Ist das zwingend Voraussetzung dafür,

6:39

dass diese beiden BIPs umgesetzt werden können? Ist das unabhängig davon oder wie hängen

6:46

diese Sachen miteinander in Verbindung? Ja, also Gloria Zhao hatte jetzt die letzten vier Jahre an Package Relay gearbeitet und

6:59

das war in vielerlei Hinsicht immer, also das hat erst mal dazu geführt, dass diese

7:06

ganzen Probleme klar definiert wurden und das formell herausgefunden wurde, wo eigentlich

7:12

Probleme sind und wie man weiterarbeiten kann. Aber es war ein bisschen unklar, was eigentlich

7:18

die langfristige Lösung sein könnte. Und dann wurde auf verwandter Ebene die Arbeit

7:27

an Cluster Mempool angefangen, um einige Probleme mit RBF und dem Mempool generell zu lösen.

7:35

Und dadurch hat sich herausgestellt, dass mit den Konzepten, die eingeführt wurden

7:42

in Cluster Mempool, es eigentlich überhaupt erst richtig möglich wird oder eine Theorie,

7:47

wie man Package Relay DOS-resistent und ohne Probleme umsetzen kann, wurde überhaupt erst

7:54

möglich. Vorher war es so unklar, wie man zum Beispiel bewertet, ob eine Gruppe von

8:03

Transaktionen besser ist als andere Transaktionen, die es versucht zu ersetzen. Und das wurde

8:07

erst durch Cluster Mempool klarer definiert und vergleichbar. Also insofern, die sind

8:15

sehr verwandt, indem sie ähnliche Problematiken ansehen, aber eigentlich orthogonal. Das eine

8:24

ist, wie tun wir generell mit unbestätigten Transaktionen umgehen? Und jetzt Truck Transactions

8:31

spezifisch versucht, Pinning-Probleme zu lösen oder zu verkleinern. Und Package Relay ist eben

8:40

die Frage, wie kann man zusammenhängende Transaktionen als Paket verschicken und nicht

8:46

eins? Genau, ich glaube, damit haben wir Package Relay dann doch noch im letzten Satz noch einmal

8:52

versucht zu definieren. Was hatten wir gesagt? Das sind Regeln, die es möglich machen, dass mehrere

9:00

miteinander verwandte Transaktionen im Paket, im Verbund miteinander im Netzwerk verbreitet

9:06

werden können. Lass mich doch da auch gerade noch einen Satz dazu sagen. Normalerweise verschicken

9:13

wir alle Transaktionen einzeln. Also wenn ein Node eine neue Transaktion sieht, tötet die

9:20

evaluieren. Wenn sie ihm in den Kram passt, dann tötet sie in seinen eigenen Mempool. Und nur was

9:26

im eigenen Mempool landet, wird dann anderen Nodes angeboten. Also der Node sagt einfach,

9:32

hey Nachbar, ich habe eine neue Transaktion, das ist die TX-ID, möchtest du die haben?

9:38

Und der Nachbar erwartet dann, dass die Transaktion generell in die verhandelten

9:49

Parameter passt. Also zum Beispiel, wenn der Nachbar schon einen überlaufenden Mempool hat,

9:55

dann hat er vielleicht eine höhere Minimum-Fee-Rate und akzeptiert Transaktionen nicht.

9:59

Das sagt er dann seinen Nachbarn, hey, ich nehme nur Transaktionen, die mindestens diese

10:03

Fee-Rate haben. Also wenn er eine neue Ankündigung kriegt, erwartet er, dass die ihm in den Mempool

10:09

passen wird und dass die valide ist und so weiter. Und dann sagt er, hey, gib her.

10:14

Also so werden dann die einzelnen Transaktionen durch das Netzwerk weitergegeben. Aber wenn wir

10:23

jetzt zum Beispiel einen Lightning-Channel angucken. Der Lightning-Channel ist ja im

10:31

Grunde genommen einfach nur eine UTXO, die von zwei Leuten zusammenverwaltet wird. Also die haben

10:38

diese gecashten Transaktionen, die Aussagen darüber machen, wie das Geld dann später ausgezahlt werden

10:49

könnte. Also wenn einer der beiden Channel-Partner aufhört teilzunehmen oder sein Rechner abraucht

11:01

oder im Urlaub ist oder sonst irgendwie Internet verliert, dann muss ja die andere Person die

11:07

Möglichkeit haben, ihr Geld zurückzukriegen, den Channel zu schließen oder wenn es sonst

11:12

irgendeinen Konflikt gibt, dass die Zusammenarbeit zusammenbricht. Und in dem Fall kann jeder von den

11:20

beiden Channel-Partnern die sogenannte Commitment-Transaction, das ist also quasi einfach

11:26

der letzte Stand des Lightning-Channels, nehmen und diese virtuelle oder unveröffentlichte

11:34

Transaktion, sollte ich sagen, einfach direkt ans Netzwerk schicken. Und das ist eben der letzte

11:41

Stand, wo der Channel neu verhandelt wurde. Also nachdem jemand Geld geschickt hatte, Alice und

11:46

Bob haben einen Channel, Alice schickt durch Bob an irgendjemand anderes Geld im Lightning-Netzwerk.

11:52

Sobald diese Transaktion durchgegangen ist, also ich sollte sagen, diese Zahlung ist durchgegangen,

11:58

weil die Transaktion ist ja in dem Kontext vielleicht vorbelastet. Hast du eine Frage?

12:06

Nee, nee, alles gut. Ich wollte es nochmal festhalten. Also die Transaktion wäre das,

12:10

was wir on-chain machen und die Zahlung ist das, was wir in Lightning machen. Vielleicht ist das

12:13

das Wording, auf das wir uns hier einigen können. Vorzüglich. Also wir führen eine Zahlung durch,

12:20

Alice schickt an Dave eine Zahlung und die wird eben über mehrere Hubs versendet durch Bob und

12:27

vielleicht Carol und dann zu Dave. Und nachdem dieses Multi-Hub-Kontrakt aufgelöst ist und die

12:36

HTLCs wieder in die Channels gefaltet sind, dann hat man eben einen gerade ruhigen Channel und das

12:45

ist der letzte Stand vielleicht, den Alice und Bob haben, diese Commitment-Transaction. Und

12:50

jeder von denen hat eine eigene Variante und die können sie einfach ans Netzwerk schicken und die

12:56

können so unilateral den Channel schließen. Solange beide da sind, können sie auch einfach

13:03

verhandeln und gemeinsam das Geld ausgeben, weil sie sich ja zusammen besitzen. Das heißt,

13:11

zu dem Zeitpunkt, wo diese Lightning-Zahlung durchgeführt wurde, war vielleicht der Mempool

13:16

super ruhig und die Fee-Rates waren niedrig und die Commitment-Transaktion hat eine relativ

13:21

niedrige Fee-Rate. Dann kommt ein tolles Projekt wie Babylon daher und beschließt, dass man jetzt

13:28

Staking auf Bitcoin machen kann und die Fee-Rates gehen zu 1000 Sats per vByte über Nacht und

13:34

bleiben so ein paar Tage. Und plötzlich muss Alice den Channel schließen und ihre Commitment-

13:41

Transaktion hat vielleicht bloß, keine Ahnung, 10 Sats per vByte. Die kommt nicht mal in den

13:46

Mempool rein oder jedenfalls sie wird nicht schnell bestätigt. Dadurch, dass die Transaktion von Alice

13:54

und Bob gemeinsam signiert wurde, kann Alice eben nicht alleine die Fee-Rate verändern von der

14:00

Transaktion. Und insbesondere, wenn Mempools total am Überlaufen sind, kann es sein, dass die

14:08

Commitment-Transaktion alleine überhaupt nicht in den Mempool aufgenommen wird. Wenn die Fee-Rate

14:15

zu niedrig ist, kann sie unter der Minimum-Fee-Rate von Nachbarn Mempools sein und dann kann Alice

14:20

die nicht mal überhaupt ans Netzwerk schicken. Was jetzt Track Transactions löst, unter anderem,

14:27

ist, dass es immer erlaubt, Transaktionen zu verschicken, solange ein Kind mit dabei ist und

14:37

höhere Fee-Rate. Ich glaube, ich bin prompt drei Schritte vorausgesprungen. Nein, nein, alles gut.

14:44

Also ich fand es gut. Ich habe dich ein bisschen ausreden lassen, weil ich das Beispiel mit

14:48

Lightning ganz gut finde. Da kann man noch mal genau erklären, was ist eigentlich das Problem,

14:52

das wir haben. Ich würde es jetzt noch mal versuchen zusammenzufassen. Wir haben einen

14:56

Kanal zwischen Alice und Bob, in dem wir Zahlungen hin und her schicken. Nach jeder Zahlung einigen

15:04

wir uns gemeinsam darauf, was der Kanalzustand ist. Also wie viele Sats liegen bei Alice und

15:09

wie viele Satoshi liegen bei Bob. Das machen wir, indem wir uns gegenseitig eine Transaktion

15:16

signieren, die den Kanalzustand quasi ausgibt. Also die sagt, hier ist eine Transaktion. Also

15:22

man ist ja den Vertrag, den Kanal, ist man ja eingegangen mit einem 2 aus 2 Multi-Sig. Und das

15:27

kann man jetzt auflösen und sagen, nach dem aktuellen Kanalzustand 70 Prozent bei Bob,

15:31

zum Beispiel 30 Prozent bei Alice. Diese Transaktion veröffentlichen wir jetzt.

15:35

Genau, das ist der Zwischenstand, der aktuelle finale Stand.

15:39

Genau. Und das Problem, das jetzt halt auftreten kann, ist, dass wir diese Commitment-Transaktion

15:45

signiert haben mit einer Gebühr in Anbetracht des aktuellen Mempools. Jetzt kann sich natürlich

15:51

der Mempool, wie du gesagt hast, kann sich halt ziemlich schnell auch sehr dynamisch entwickeln.

15:55

Wir könnten auf einmal einen sehr starken, also einen sehr vollen Mempool haben mit hohen Gebühren.

16:00

Dann kann es sogar vorkommen, dass deine Transaktion, also diese 2 aus 2 schließen

16:04

Transaktion des Kanals, dass die nicht veröffentlicht wird. Also dass die gar nicht

16:08

erst in den Mempool anderer Leute kommt. Also das war mir jetzt wichtig, bevor wir nochmal auf das

16:13

Truck-Transactions kommen. Also einfach das ist das Problem, das wir haben. Also beim Schließen

16:17

von Lightning-Kanälen haben wir Commitment-Transaktionen, die sehr niedrige Gebühren

16:21

haben und somit eventuell nicht zeitnah veröffentlicht werden können. So viel erstmal,

16:28

um das Problem zu beschreiben. Lass uns mal an 2 Punkten doch noch ein wenig genereller werden.

16:33

Also generell, wir haben die Commitment-Transaktion zu einer Zeit geschrieben oder ausgetauscht,

16:41

die potenziell überhaupt nichts mit der derzeitigen Zeit zu tun hat, Monate zurückliegen könnte.

16:48

Und deswegen ist es uns unmöglich, die Fee-Rate vorherzusagen, zu der wir die Commitment-Transaktion

16:54

verwenden wollen. Also wir haben sie vielleicht Monate vorher verhandelt und der Mempool könnte

17:00

komplett anders aussehen. Zweitens, also warum muss man denn eine Transaktion vielleicht zeitnah

17:07

durchbringen? Also weil man unilateral einen Channel schließen möchte, um eben das Geld

17:14

vielleicht anderweitig zu verhändeln? Weil man eine Penalty-Transaktion durchkriegen möchte?

17:19

Darf ich ein ganz kurzes, ein plastisches Beispiel noch mal bringen? Stellt euch vor,

17:22

ihr habt eure Node in Deutschland stehen und es kommt tatsächlich zu einer Dunkelflaute in

17:27

Deutschland von der viel gerühmten, die ja eventuell ins Haus steht. Aber es kann tatsächlich

17:31

der Fall ja eintreten, dass bei euch der Strom zum Beispiel ausfällt und ihr habt jetzt das Glück,

17:35

dass ihr noch ein Gerät davor geschaltet habt, vor eure Node, die noch eine Stunde

17:40

lang aus einer Batterie deine Node mit Strom versorgt. Das heißt, du hast eine Stunde Zeit,

17:45

um jetzt den Kanal zu schließen, um halt das Problem eines offenen Kanals zu verhindern,

17:50

an den du nicht mehr drankommst, weil deine Node mit der Commitment-Transaktion leider

17:55

nicht erreichbar ist. Und alle anderen in Deutschland wollen ihre Channel auch gerade

17:58

schließen. Oder wir haben ein externes Event, das die Transaktionsgebühren halt hochgetrieben hat.

18:07

Genau. Also generell einfach den Channel schließen zu wollen oder der Channel-Partner

18:14

versucht zu betrügen, indem man einen alten Zustand des Channels veröffentlicht und man

18:19

hat eben nur eine bestimmte Zeit, Bloodcat-Zeit, um zu reagieren mit der Gerechtigkeitstransaktion,

18:24

Penalty-Transaction. Ja, genau, es kommt hin. Und Straftransaktion, oder? Also Bestrafungstransaktion.

18:30

Ja, also diese Korrektur eben, die man dann verwenden kann, um die Transaktion des Channel-Partners,

18:39

die alte, entwertete Transaktion, zu überschreiben mit der gerechten Strafe. Da hat man eben auch eine

18:49

begrenzte Zeit. Und wenn eben dann der Mempool in dem Moment nicht günstig ist, dann kann es sein,

18:57

dass man Probleme hat, seine Transaktion zeitnah bestätigt zu bekommen.

19:03

Okay, so. Das war jetzt der Versuch, das Ganze high-level zu schreiben. Jetzt kommt der Deep

19:10

Dive-Teil. Wir können ja noch einen Hinweis darauf geben, wenn euch das Thema Lightning

19:17

noch mehr interessiert und auch wie die Transaktionen da drin so aufgebaut werden,

19:20

können wir noch mal einen Verweis auf unseren Buchclub aktuell machen. Da besprechen wir nämlich

19:23

genauso Themen auch noch gesondert, die wirklich nur darauf sich beziehen.

19:26

Genau, in der Folge über das Eröffnen und Schließen eines Kanals haben wir genau über

19:32

dieses Thema Commitment-Transaktionen auch gesprochen.

19:35

HTLC ist zum Beispiel auch, da gab es auch ein eigenes Kapitel darüber, wo genau das

19:38

beschrieben ist, was Murch gerade auch erklärt hat.

19:41

Ach, ihr lest immer noch Mastering Lightning?

19:43

Wir sind fast fertig. Das war jetzt auch ein Jahr lang oder so, oder?

19:48

Ja, wir sind, glaube ich, bald bei zwei. Okay, also wir haben jetzt das Problem beschrieben, dass die Transaktion eben vielleicht zeitnah

19:59

durchgehen muss und der Mempool sich entwickelt hat, seit der Zeit, dass die Commitment-Transaction

20:03

erzeugt wurde und potenziell sogar, dass der Mempool so voll ist, dass die Commitment-Transaction

20:11

selbst eine niedrigere Fee-Rate hat als das Minimum der Mempools der Nachbarn, sodass

20:17

wir denen gar nicht erst die Transaktion anbieten können.

20:20

Die nehmen die nicht, weil sie zu niedrig ist.

20:23

Da sind wir drin, soweit.

20:25

Das ist das Problem, das wir lösen wollen.

20:28

Wobei wir jetzt noch das, das eigentlich, also noch ein schwerwiegendes Problem, nämlich

20:35

das böswillige Akteure noch nicht beschrieben haben, das Thema Pending-Attacken.

20:38

Genau, deshalb will uns noch gar keiner angreifen. Genau, dann lasst uns doch bitte jetzt nochmal mit dazu nehmen.

20:43

Ich glaube, die Ausgangslage haben wir jetzt einigermaßen verstanden.

20:47

Jetzt kommt natürlich jetzt noch ein weiterer Akteur ins Spiel, nämlich ein sogenannter

20:51

böswilliger Akteur, der uns mit einer Pending-Attacke angreift.

20:55

Merch, was ist eine Pending-Attacke und was kann er damit erreichen?

20:58

Genau, also wir wollen zum Beispiel, das Gegenüber hat eine alte Transaktion ausgegeben.

21:09

Sorry, also wir haben immer noch einen Channel Alice und Bob.

21:14

Bob ist jetzt ein Angreifer vielleicht und Bob schließt den Channel mit einem alten

21:19

Zustand und veröffentlicht, also gibt den Funding-Output aus, also eine UTXO, an dem

21:29

der Channel dranhängt, mit eben seiner…

21:34

Wo er noch mehr Funds hat, als er eigentlich im Kanalzustand…

21:39

Er hat einen alten Zustand. …zustehen würde.

21:41

Ja, genau. Alten Zustand mit mehr Geld.

21:44

Er veröffentlicht den alten Zustand, versucht zu betrügen.

21:46

Und jetzt der erste Weg, wie man dagegen verteidigen könnte, wäre, dass man einfach seine eigene

21:55

Commitment Transaction mit dem neueren Zustand darüber ausgibt, den neuesten Zustand, und

22:00

diese alte Transaktion überschreibt im Mempool.

22:03

Wobei jetzt ja in der Situation ganz konkret, das hast du ja eben auch schon gesagt, das

22:08

hätte jetzt ja Alice die Chance oder die Situation, dass sie jetzt ja diese Judgment

22:11

oder Punishment Transaktion veröffentlichen könnte, wo ja dann der gesamte Kanalbetrag

22:15

dann ihr zugeschrieben wird an der Stelle.

22:18

Stattgegeben, das wäre wahrscheinlich noch…

22:20

Also das wäre ja das, wofür es das gibt an der Stelle.

22:24

Ja, alles sollte… Ja, okay. Dann lass mich ein anderes Beispiel holen.

22:28

Ich bin überzeugt von deinem Einwurf.

22:30

Sagen wir mal, Leute erzeugen einen Coinjoin zusammen und einer der Teilnehmer im Coinjoin

22:44

ist böswillig und er hängt an den Coinjoin sofort eine Transaktion dran, um diese Coinjoin

22:52

Transaktion zu verlangsamen. Also die erste Variante, mehrere Teilnehmer haben diesen Coinjoin zusammen erzeugt und

22:59

er möchte verhindern, dass dieser Coinjoin bestätigt.

23:02

Er gibt seinen eigenen Output am Coinjoin aus, aber er gibt ihn aus mit einer sehr großen

23:09

Transaktion, die eine sehr niedrige Fee Rate hat und damit pinnt er diesen Coinjoin.

23:14

Nämlich, wenn jetzt zum Beispiel die gerade am Verhandeln waren, eine schnellere Variante

23:21

des gleichen Coinjoins zu bauen mit einer höheren Fee Rate, dann wird es unmöglich

23:27

für die anderen Coinjoin Teilnehmer diese Variante zu broadcasten, weil er den alten,

23:35

die erste Variante gepinnt hat. Er hängt eine sehr große Transaktion mit einer sehr niedrigen Fee Rate dran.

23:45

Und jetzt schauen wir uns BIP 125 an, also RBF Regeln und Regel 3 sagt, wenn du eine

23:52

Transaktion ersetzen möchtest, musst du die Fees aller ersetzten Transaktionen aufbringen.

23:59

Und wenn jetzt zum Beispiel gerade Transaktionen durchgehen mit 10 Sats per V-Byte, du hängst

24:05

eine maximal große Transaktion als Kind daran mit 100.000 V-Bytes bei einem Sat per V-Byte.

24:16

Das Original sollte bei 10 durchgehen.

24:19

Sagen wir mal, dass die Eltern Transaktion nur 1000 Bytes wiegt.

24:27

Dann hat die also 10.000 Sats gezahlt für 10 Sats per V-Byte.

24:31

Und jetzt hängt er eine zweite Transaktion dran, der Angreifer, mit 100.000 V-Bytes und

24:38

ein Sat per V-Byte. Also er zahlt nochmal 100.000 Sats.

24:41

Die Transaktion geht nie durch, weil, seien wir mal ehrlich, seit 24.

24:46

April letzten Jahres sind keine Transaktionen mit einem Sat per V-Byte durchgegangen.

24:50

Aber wenn jemand jetzt die Eltern Transaktion ersetzen möchte, müssen sie über 110.000

24:59

Sats zahlen, wo sie vorher eigentlich nur 10.000 hätten zahlen müssen, um die zu ersetzen.

25:04

Was mir nicht ganz klar ist, also die Child Transaktion, die dieser böswillige Akteur

25:09

generiert, das ist doch eine nachfolgende Transaktion.

25:11

Das ist doch völlig unabhängig davon, ob der jetzt, also der Miner kann doch hingehen

25:15

und sagen, hey, ich nehme halt den CoinJoin.

25:18

Also was interessiert mich denn der Nachfolger, dieses Child, das ich da meinen möchte?

25:23

Genau. Okay, Situation ist so, die Leute machen den CoinJoin, hatten erwartet, dass 10.000 schnell

25:31

durchgeht, sorry, 10 Sats per V-Byte schnell durchgeht.

25:35

Und jetzt ist aber der Mempool bei 15.

25:39

Und aus irgendeinem Grund hat einer der CoinJoin Teilnehmer, möchte verhindern, dass der schnellere

25:47

CoinJoin durchgeht, den jetzt alle verhandeln, wo sie sagen, hey, wir zahlen auch 15.

25:52

Und er hängt eine große Transaktion dran an seinen eigenen Output in der Original Transaktion

26:01

und das verlangsamt oder das macht es sehr teuer.

26:03

Aber warum, genau, der Einwand von Jan-Paul löst sich dadurch ja trotzdem nicht, auch

26:11

wenn quasi der CoinJoin als Transaktionsblock isoliert betrachtet wird?

26:14

Darf ich versuchen, Murch, vielleicht kannst du mich dann gleich korrigieren.

26:18

Ich meine, es wird etwas verstanden zu haben.

26:21

Das Problem ist, dass, also der CoinJoin hängt noch im Mempool.

26:27

Und was die Teilnehmer des CoinJoin versuchen, alle bis auf den böswilligen Akteur, ist,

26:34

okay, wir wollen die Fee-Rate bumpen.

26:37

Wir kreieren also eine Schalttransaktion.

26:39

Richtig? Nein, der Murch.

26:43

Mein Beispiel ist schlecht, weil der Angreifer würde ja dann einfach auch bei den 15 nicht

26:49

teilnehmen. Der muss also eigentlich gar nicht pinnen.

26:51

Ich glaube, das ist, worauf Thorsten raus will. Das ist jetzt ja die Frage, reden wir jetzt gerade über Replace-by-Fee, weil das der

26:56

CoinJoin quasi einfach nur mit höheren Fees nochmal neu gemacht wird?

27:00

Oder sprechen wir über eine Child-Pays-for-Parent? Und was ja im Endeffekt dieser Angriff von dem böswilligen, das wäre nämlich meine

27:06

Frage, die du eben gesagt hast, weil du von den Regeln von Replace-by-Fee gesprochen hast.

27:09

Aber der Angreifer setzt ja in dem Sinne ja eine Child-Pays-for-Parent an der Stelle ein

27:13

und kein Replace-by-Fee. Oder sind die Regeln da gleich?

27:16

Genau. Also der Angriff, nehmen wir mal an, dass ein Angriff stattfindet, aber der Angriff

27:24

verhindert, macht RBF teuer.

27:26

Ja, das verstehe ich.

27:28

Dadurch, dass er ein Kind anhängt.

27:30

Also es verhindert einen ökonomischen RBF.

27:35

Also wenn eine Transaktion nicht gepinnt ist und die wiegt, sagen wir mal 100 Bytes, damit

27:44

ich von 10 Sites per Webite, da hatte ich 1000 Sites gezahlt, damit ich sie auf 11 ersetzen,

27:51

ich kann sie ersetzen mit einer anderen Transaktion, die auch 100 Webite wiegt und 1100 Sites zahlt,

28:00

um sie auf 11 Sites per Webite anzuheben.

28:02

Sagen wir mal, der Mempo ist gerade 15, dann will ich auf 15 bumpen und dazu muss ich 1500

28:10

Sites zahlen, um eine 100-Byte-Transaktion auf 15 Sites per Webite zu heben.

28:14

Die Regel 3 von BEP 125, also den RBF-Regeln, sagt, wenn ich mehr als eine Transaktion ersetzen

28:24

möchte, muss ich alle Fees, die aus dem Mempo verdrängt werden, ersetzen.

28:28

Und wenn jetzt eben ein großes Kind dranhängt an der Original-Transaktion, nennen wir sie

28:35

mal Transaktion A, Transaktion A hat 1000 Sites gezahlt, wiegt 100 Bytes und hat dadurch

28:43

10 Sites per Webite, an der hängt eine Transaktion B dran, die riesig ist, 100.000 Webites das

28:50

Maximum für Standard-Transaktionen, aber sie zahlt nur 1 Site per Webite, also zahlt

28:55

100.000 insgesamt. Damit ich jetzt Transaktion A ersetzen darf, auf 15 Sites per Webite, will ich eigentlich

29:04

ja nur 1500 zahlen, also 500 mehr als im Original, aber damit ich das Kind mit ersetzen darf,

29:14

die Transaktion B, die an A dranhängt, damit der Mempool insgesamt mindestens genauso viele

29:20

Fees hat wie vorher, muss ich 100.000 mehr zahlen, damit ich B verdrängeln darf.

29:28

Also das Problem rührt aus dieser Mempool-Policy, dass die Gesamtgebühr höher sein muss als

29:44

die Transaktion, die ich ersetzen möchte. Oder als die existierende…

29:47

Perfekt. Inklusive der Kinder dann an der Stelle.

29:51

Also dadurch, dass A und B verdrängt werden aus dem Mempool, wenn ich A ersetze, weil

29:55

B ja an A dranhängt, muss ich alle Gebühren ersetzen, die A und B in den Mempool einbrachten.

30:01

Die bringen zusammen gerade 110.000 ein.

30:05

Wer auch immer A verschickt hat, will eigentlich nur auf 15 bumpen und müsste nur 1500 dafür

30:15

zahlen auf der neuen Transaktion, also nur 500 mehr.

30:18

Aber jetzt, weil er B auch verdrängen muss, muss er 115.000 zahlen, um B zu erzeugen.

30:31

Ich glaube, was mir jetzt gerade eingefallen ist, was glaube ich auch den Zuhörern hier

30:35

an der Stelle wahrscheinlich fehlt, ist, um das zu verstehen, wie A und B hier zusammenhängen,

30:40

dass wenn wir A quasi ersetzen mit einer neuen Transaktion, dann hat das die A und B sind

30:47

doch über die Transaktions-ID verknüpft in irgendeiner Form.

30:50

Genau. Und wenn wir A ersetzen, ist es eine andere Transaktions-ID, als die vorher der Fall war,

30:58

die dann in A zwar drin, die geben zwar die gleichen UTXOs aus, aber die Transaktions-ID

31:02

ist eine andere. Deswegen fällt B an der Stelle weg.

31:04

Und deswegen haben wir quasi diese Verkettung, die wir nur auflösen können, wenn wir beide

31:09

an der Stelle ersetzen. Sonst würde ja B im losen Raum rumfliegen, weil ja das zuvor quasi in dem alten Zustand

31:17

definierte Transaktions-ID ja nicht mehr existiert, weil halt das UTXO jetzt für 15 Satz pro

31:23

Webite ausgegeben wird und nicht mehr mit 10. Und deswegen würde das Ding im leeren Raum fliegen.

31:28

Und dann sagt, das ist wahrscheinlich der Grund, warum die Regel dann sagt, entweder

31:32

gar nicht oder halt komplett. Also quasi nur zusammen an der Stelle.

31:35

Genau. Du hast das sehr gut erklärt.

31:39

Also die Transaktion A hat, sagen wir mal, ich ändere jetzt das Beispiel zum dritten

31:45

Mal. Alice schickt Bob Geld und sie hat ein Change Output auch auf der Transaktion.

31:50

Also Alice schickt dann Bob und Alice hat ein Change Output.

31:55

Jetzt möchte Alice ihren Change Output schnell ausgeben können, weil sie noch eine Transaktion

32:00

bauen möchte und ist deswegen interessiert, das könnte zum Beispiel im Kontext von Lightning

32:05

oder sonst wo sein, aber möchte ihre Original-Transaktion A ersetzen mit einer A*-Transaktion,

32:13

wo A* eben eine höhere Fee Rate hat und dementsprechend schneller bestätigt wird.

32:18

Und aus irgendwelchen Gründen möchte ja Bob an den Karren fahren und möchte das verlangsamen.

32:24

Und Bob gibt jetzt seinen Output, also an den Output, der ihn bezahlt, hängt er jetzt

32:33

diesen riesigen Klunker dran, um die zu verlangsamen.

32:38

Und jetzt führt es eben dazu, wenn Alice ihre Transaktion A ersetzen möchte, muss

32:44

sie sowohl A als auch B ersetzen, weil B dranhängt.

32:49

Und obwohl B vielleicht nach zwei Wochen dann austimet und, also aus dem Mempool fallen

33:00

Transaktionen nach zwei Wochen raus, wir vergessen die einfach, wenn sie nicht durchgehen, die

33:05

können natürlich wieder in den Mempool eingebroadcastet werden, aber diese Transaktion bei einem Side

33:12

Pivvy Bite im letzten Jahr wird ihr einfach nach zwei Wochen verfallen, weil nix durchgeht.

33:18

Es nicht mehr gebroadcastet wird dann.

33:21

Dadurch, dass Alice jetzt ihre Transaktion nicht zu 15 bumpen kann, sondern sie müsste

33:28

also eine neue Transaktion machen, die Alice und Bob bezahlt oder vielleicht nur sie zahlt,

33:33

weil ja Bob ein Säckel ist, muss sie aber zu 115.000 Satz und ihre Transaktion wiegt

33:42

nur 100 Satz per V-Bite, also zahlt sie jetzt über 1000 Satz per V-Bite statt 15 Satz per

33:49

V-Bite auf ihre Transaktion. Das ist Rule 3 Pinning.

33:53

Aber kann Alice überhaupt dann, also könnte sie das denn ersetzen, weil müsste die Transaktion

34:01

von Bob dann nicht neu signiert werden mit neuen Transaktionsfees an der Stelle?

34:04

Ne, die Transaktion von Bob verfällt, weil der Input nicht mehr existiert.

34:11

Also die Transaktion von Bob erlädert. Sie ersetzt sie dann genau und löst, also sie bezahlt dafür, dass die Ketten, um bei

34:16

dem Bild zu bleiben, von ihm dann irgendwie aufgelöst werden an der Stelle.

34:20

Sie muss alle Fees ersetzen, die von A und B in den Mempool eingebracht wurden und A

34:29

und B werden beide ersetzt.

34:31

Also die fallen aus dem Mempool raus, wenn A* akzeptiert wird.

34:35

Aber dazu muss sie natürlich sowohl die Fee-Rate als auch die Fee, die vorher da waren, übertreffen.

34:42

Und in letzter Konsequenz bedeutet das ja an der Stelle, Alice hat einen ökonomischen

34:47

Schaden, dadurch, dass sie super viel mehr Fees bezahlen müsste als vorher und Bobs

34:51

UTXO würde im Endeffekt aus dem Mempool rausfallen und für ihn hat das eigentlich nichts gekostet,

34:55

weil der UTXO, den er ja eingebracht hat, quasi gelöscht wurde.

34:59

In dem Sinne hat er nie Geld ausgegeben. Genau, kostenlos für Bob.

35:03

Er macht einen ökonomischen Schaden für A*, zahlt letztendlich überhaupt nichts, weil

35:08

der Input nie existierte. In dem Fall wird er, wenn Alice tatsächlich jetzt angekekst ist, weil er versucht hat,

35:17

ihren IBF zu verhindern und sich selbst das Geld zurückschickt, vielleicht verliert er

35:22

dann die Zahlung. Aber er hat eben einen ökonomischen Schaden oder eine Verzögerung auf Alice ausgeübt,

35:29

ohne eigene Kosten. Sehr gut.

35:32

Und das ist das, was wir eben bei der ersten Erklärung, also Pinned heißt an der Stelle

35:40

einfach, dass die Transaktion irgendwie angepinnt ist.

35:43

Also ist das die Analogie davon, dass wir sie quasi an so einem Anker hängen, Anker

35:48

ist vielleicht nochmal ein anderes Bild, weil das halt noch in einem anderen Kontext heute

35:51

vielleicht relevant ist, aber so.

35:53

Die ist festgenagelt. Genau, wir hängen sie an schweren Steinen, die Transaktion.

35:58

Die ist festgenagelt, wir können die nicht bewegen, wir können sie vor allem nicht beschleunigen,

36:04

weil eben jemand einen Brocken dran gehängt hat, der sie schwerer macht.

36:09

Wobei das Problem erst richtig scharf wird, wenn ich das jetzt richtig verstanden habe.

36:15

Also klar, natürlich, es setzt voraus, dass es einmal diesen böswilligen Akteur Bob gibt,

36:18

der tatsächlich diese Pinning-Attacke durchführt. Aber tatsächlich scharf wird die Attacke erst, wenn du darauf angewiesen bist, dass

36:26

du schnell die Transaktion A durch A* ersetzen kannst.

36:32

Ja, nehmen wir mal an, Transaktion A ist ein HTLC oder eine Justice Transaction oder in

36:43

irgendeiner Form. Die Transaktion muss bestätigt werden in den nächsten 10, 15 Blöcken.

36:49

Und wenn jetzt eben ein Gegner etwas dranhängen kann oder die verlangsamen kann oder es schwieriger

36:58

machen kann, die Transaktion zu ersetzen. Wenn jetzt zum Beispiel diese Transaktion insgesamt nur 1 Millibitcoin wert war, wenn

37:06

er sie zwingen würde, 100.000 Satz mehr zu zahlen, ist es ein ökonomischer Totalschaden.

37:11

Weil 100.000 Satz sind 1 Millibitcoin, sie müsste so viel zahlen, wie das wert ist,

37:16

es lohnt sich nicht mehr. Sie lässt vielleicht dann jetzt den HTLC verfallen, weil es sich einfach nicht rentiert

37:25

hätte, den zurückzuholen und dann nach 15 weiteren Blöcken oder so kann Bob das Geld

37:31

nehmen vielleicht. Okay, also mir ist das so einigermaßen klarer geworden.

37:39

Es ist halt schwierig. Also ich glaube, das ist echt nicht einfach, das zu verstehen, was eine Pinning-Attacke

37:44

ist. Ich hoffe, dass das jetzt ein bisschen geholfen hat unseren Zuhörern.

37:47

Oder, Thorsten, was meinst du? Also ich fand es jetzt gut, nachdem jetzt mit dem "Fahr mal hin und her" hat es mir

37:52

auf jeden Fall gut geholfen, das nachzuvollziehen an der Stelle.

37:55

Ja, ich fand schön, wie sich das entwickelt hat und du hast tatsächlich mehrere gute

37:59

Punkte gehabt, warum mein Beispiel vielleicht besser hätte sein können und jetzt haben

38:04

wir ein gutes Beispiel. Ja, sehr gut.

38:06

Der Thorsten müsste sich eigentlich auch mal auf dieses Chaincoblabs, was ist das?

38:10

Habt ihr nicht gerade eine Bewerbungsphase?

38:14

Vielleicht kannst du das mal kurz erzählen, Murch.

38:17

Ja, total mittendrin. Also Chaincode bietet auch nächstes Jahr wieder das BOSS-Programm Bitcoin Open Source Development

38:27

an und wir haben das letztes Jahr, also sorry, dieses Jahr zum ersten Mal gemacht.

38:32

Und die Idee ist also, für Leute, die gerne Open Source Entwickler werden wollen, bieten

38:40

wir ein drei Monate Programm an.

38:43

Die ersten paar Wochen sind sehr, also rumgedrehtes Klassenzimmer, man arbeitet daheim und kann

38:51

Fragen stellen und kriegt Hilfe von der Gruppe, arbeitet aber eigentlich durch eine Reihe

38:56

von Material durch, also einfach um Bitcoin Core besser kennen zu lernen, Lightning kennenzulernen,

39:03

mit den Remote Procedure Calls, also dem RPC-Interface von Bitcoin Core sich bekannt zu machen und

39:11

dann später mündet das in zwei Monate, glaube ich, Programm, wo man an einem Projekt arbeitet

39:20

für ein Open Source Projekt, also nicht nur Bitcoin Core, sondern auch andere und dann

39:26

mit einem Mentor zusammenarbeitet, der einem hilft.

39:29

Und die Idee ist, dass man eben damit den Sprung in Open Source schaffen könnte, falls

39:37

man das möchte. Die Idee ist, dass man ein bisschen Programmierkenntnisse mindestens mitbringt und viel Eigenmotivation.

39:46

Aber also letztes Jahr, dieses Jahr, Anfang dieses Jahres, wo wir das zum ersten Mal gemacht

39:53

haben, hatten wir tatsächlich über 600 Bewerber bekommen und am Ende sind, glaube ich, zwölf

40:01

Leute, die Vollzeit in Open Source arbeiten, dabei rausgekommen.

40:05

Also es ist definitiv ein großer Zeitaufwand, mindestens zehn Stunden pro Woche, ich glaube

40:13

eher mehr. Also die Leute, die Erfolg hatten, haben alle mehr investiert und dann, wo eben weniger

40:22

Leute dann übrig bleiben, wird die Betreuung stärker, weil sonst können wir das nicht

40:27

stemmen. Wir sind ja selbst bloß ein Dutzend Leute hier bei Chaincode.

40:31

Aber auch die Leute, die vorher dann ausgeschieden sind und nicht die ganzen drei Monate gemacht

40:36

haben, haben viel gelernt und also so viel gelernt, wie sie Zeit reingesteckt haben,

40:41

denke ich. Jedenfalls, wir bieten das wieder an.

40:44

Ihr könnt mehr finden auf learning.chaincode.com und die Bewerbungsfrist ist der 31.

40:51

Dezember. Wie viele Leute hattet ihr nach den 600 Bewerbungen jetzt dieses Jahr dann mit in die erste Phase

40:59

dann reingenommen? Also in Vergleich, Relation dazu?

41:02

Ja, über 600 Leute hatten sich beworben, über 300 Leute haben die erste Challenge

41:13

geschafft oder was eingereicht dafür, glaube ich.

41:15

Ich glaube, was eingereicht. Ich glaube, die erste Challenge war, füge einen Fehler in Bitcoin Core ein, sodass genau

41:25

ein Test fehlschlägt. Und das führt natürlich dazu, dass die Teilnehmer dann erstmal Bitcoin Core selbst kompilieren

41:33

müssen, C++ Code schreiben und dann ist es tatsächlich nicht ganz trivial, einen Fehler

41:39

so einzufügen, dass nur ein Test und nicht alle Tests oder gar kein Test fehlschlägt.

41:45

Und also wenn dann die Leute diesen Patch geschickt hatten, dann wurden sie eingeladen

41:52

zur Bitcoin Core Schnitzeljagd, wo dann, keine Ahnung, verwendet die Remote Procedure Calls,

42:04

um irgendwas über einen bestimmten Block rauszufinden oder solche Herausforderungen

42:10

wurden dann über die Wochen schwieriger und dann gab es zum Beispiel, glaube ich, einen

42:17

Block Building Herausforderungen, wo man...

42:20

Ja, also ich will auch nicht zu viel verraten, aber die Idee ist, dass eben Leute, die sehr

42:26

selbstmotiviert sind, die vielleicht auch Erfahrung haben mit Softwareentwicklung und

42:31

schon lange darüber nachdenken, in Open Source-Entwicklung reinzuschnuppern, dass die halt ein bisschen

42:40

Unterstützung kriegen und dann vielleicht auch Vollzeit mit uns mitarbeiten können.

42:46

Ich glaube, der Vorteil von so einem Programm ist ja einfach klar, man kann natürlich,

42:49

man kann ja irgendwie so selbstmotiviert oder selbst irgendwie sich in der Open Source-Entwicklung

42:53

erst mal beteiligen, aber wenn man zumindest so bei den ersten Schritten von erfahrenen

42:57

Leuten, wie jetzt dann bei euch, dann angeleitet wird, dann ist das, glaube ich, nochmal eine

43:00

ganz andere Qualität, als wenn man das irgendwie alles versucht, dann sehr autodidaktisch sich

43:05

selber beizubringen und da irgendwie vielleicht auch irgendwie ein Standing aufzubauen dann.

43:10

Genau, ja und vor allem, also es gab einen Gruppenchat dann natürlich und die Leute

43:16

haben sich sehr viel gegenseitig geholfen.

43:18

Hey, ich habe das versucht und das versucht, ich kriege diese Fehlermeldung, warum passiert

43:22

das, was mache ich falsch oder einfach so, wo kann ich das nachlesen oder die Leute haben

43:31

sich selbst organisiert, haben ein Netzwerk gebildet, wo dann auch sie später halt miteinander

43:39

zusammengearbeitet haben oder miteinander geredet haben.

43:42

Einer meiner neuen Kollegen bei Localhost ist jetzt auch aus diesem Programm gekommen,

43:46

der hat erst einen Open Source-Grant bekommen und wird jetzt dann mit uns bei Localhost

43:51

arbeiten nächstes Jahr.

43:54

Cool, ja also falls sich einer unserer Zuhörer angesprochen fühlt, schaut es euch auf jeden

44:00

Fall mal an, also ich meine, wenigstens mal draufschauen schadet sicherlich nicht und

44:04

sich der Challenge dazu stellen, kann man ja auch mal zu Hause im stillen Kämmerlein

44:08

probieren. Gut, dann machen wir weiter im Programm, oder?

44:14

Das war ein netter Exkurs.

44:17

Ja, nochmal ganz kurz durchatmen, nochmal schauen, wo sind wir?

44:23

Okay, pass auf, also wir haben jetzt über… Das war jetzt so quasi, das war so dieser Werbeblock, der zwischendurch so komplett

44:28

in den Themenwechsel kommt irgendwie, nur das ist keine richtige Werbung in dem Sinne

44:32

war. Also ich weiß zumindest nicht, dass wir von Chaincode Labs dafür bezahlt werden, dass

44:37

wir darüber gesprochen haben, insofern kann man das nicht als Werbung betiteln, sondern

44:40

es war einfach Interesse auch unserer Seite, was da eigentlich passiert bei Chaincode.

44:43

Das ist die einzige Art von Werbung, die wir bei Nord Signal machen.

44:46

Die Kostenfreiheit. Vielleicht sollte ich auch sagen, es ist ein kostenloses Programm und Open Source, ihr

44:52

könnt auch online durchlesen, was wir letztes Jahr gemacht haben, glaube ich.

44:57

Ja, cool. Gut, also wo stehen wir?

45:00

Wir haben uns angeschaut, was ist das eigentlich das Problem, was die Ausgangslage und dass

45:06

es eben zu diesen Pinning-Attacken führt und die Gloria Zhao, die du ja eben auch schon

45:11

genannt hattest, die hat sich vor, wenn ich das richtig in Erinnerung habe, vor zwei Jahren

45:15

dieses Problems angenommen und dazu das BIP 431 geschrieben und das heißt, das heißt

45:23

glaube ich, heißt es Topology Restrictions for Pinning, also da steckt es noch drin,

45:30

dass es eben um die Pinning-Attacken geht, um eine Lösung dafür.

45:35

Wir sprechen hier über Truck Transactions schon die ganze Zeit, die Abkürzung steht

45:38

für Topologically Restricted Until Confirmed, also topologisch eingeschränkt bis zur Bestätigung.

45:45

Mörtsch, vielleicht musst du uns einmal erklären, was denn dieses topologisch eingeschränkt,

45:51

was das denn bedeuten soll. Ich glaube, da stolpern die meisten erstmal drüber, was das denn bedeuten könnte.

45:56

Okay, also Topologie hier meint die Verwandtschaft von Transaktionen, also unter unbestätigten

46:08

Transaktionen bilden alle Transaktionen, die irgendwie zusammenhängen, ein Cluster, wie

46:12

ihr vielleicht schon in der letzten Folge gehört habt und zurzeit haben Bitcoin Core

46:20

Mempools dort folgende Restriktionen.

46:23

Du kannst nicht mehr als 24 Nachfahren haben, also Transaktionen, die Kinder oder Kindeskinder

46:29

sind von deiner eigenen Transaktion, du darfst nicht mehr als 24 davon haben.

46:34

Falls eine 25. vorbeikommt, sagen wir nein.

46:37

Und andererseits, du kannst nicht mehr als 25 Vorfahren haben und weder die Vorfahren

46:44

noch die Nachfahren können mehr als 101.000 Transaktionsbytes in Summe haben.

46:53

Sonst werden neue Sachen, die dem Cluster beitreten wollen, oder ich sollte sagen, den

46:59

Nachfahren oder Vorfahren beitreten wollen, abgewiesen.

47:02

In unserem Fall hier jetzt für Truck-Transaktionen haben wir noch deutlich beschränktere Topologie-Restriktionen,

47:13

nämlich man kann höchstens einen Vorfahr- und höchstens einen Nachfahr- haben und das

47:21

führt dazu, dass man entweder einen Vorfahr- oder einen Nachfahr- haben kann mit seiner

47:26

Transaktion. Also das Cluster von Truck-Transaktionen kann nie mehr als zwei Transaktionen groß sein.

47:33

Also das wäre mir nochmal wichtig, das rauszustellen.

47:37

Also die bestehenden Regeln über die Anzahl der Nachfolger, die Anzahl der Vorgänger

47:42

und der Größe dieses Gesamtsets von Transaktionen, das bleibt weiterhin bestehen.

47:47

Wir führen eine zusätzliche Verschärfung dieser Regeln hinzu, dass wir sagen, wir führen

47:53

sogenannte Truck-Transaktionen ein, die die Eigenschaft haben, dass sie nur maximal einen

47:57

Vorgänger und maximal einen Nachfolger haben können.

48:00

Und oder oder oder an der Stelle.

48:04

Also wahrscheinlich. Und, also wir haben Transaktion A und Transaktion B.

48:11

A ist der Vorfahr, B ist das Kind von A.

48:14

Würde es da jetzt noch C geben?

48:18

B darf nur einen Vorhaben. Genau.

48:20

Wenn wir jetzt eine Transaktion C haben, die an B dran hängt, hat Transaktion C zwei Vorfahren.

48:25

Nämlich A und B.

48:27

Und das ist nicht erlaubt. Und wenn Transaktion, ja und gleichzeitig hat eben A zwei Nachfahren, sodass das auch

48:37

nicht erlaubt ist. Also dadurch die Regel nur einen Vorfahr und nur einen Nachfahr führt tatsächlich dazu,

48:44

dass du nur entweder einen Vorfahr oder einen Nachfahr haben kannst.

48:47

Ja ergibt Sinn.

48:50

Genau. Gibt es noch weiteres, was wir jetzt mit den Truck-Transaktionen, also an zusätzlichen,

48:57

sagen wir mal, weiteren Beschränkungen zu den bescheidenen Regeln des, ja von Transaktionen

49:04

hinzufügen? Ja.

49:06

Nämlich die Transaktionen selbst sind größenbeschränkt.

49:11

Also die Elterntransaktion darf maximal 10.000 Bytes haben.

49:16

Also Wie-Bytes. Ich sage manchmal Bytes.

49:19

Ich meine immer Wie-Bytes.

49:21

Und falls eine Kindtransaktion eine Truck-Transaktion ist, also schon einen Vorfahren hat, darf

49:29

sie nur 1.000 Wie-Bytes groß sein.

49:32

Okay. Was jetzt dann, um unseren Beispiel von eben nochmal aufzugreifen, dass wir eine kleine

49:40

Vorgängertransaktion haben und wir haben eine Pinning-Attacke gehabt, dass wir eine

49:44

sehr sehr sehr große von der Wie-Byte-Anzahl Transaktion, die der böswillige Angreifer

49:49

jetzt als B-Transaktion anhängt, kann er jetzt in dem Sinne nicht mehr machen, weil

49:53

wenn wir A als Truck-Transaktion definieren würden, hätte er diese Größenbeschränkung

49:58

von 1.000 Wie-Byte an der Stelle, die die zweite Einschränkung an der Stelle sind.

50:04

Das heißt, er kann nicht mehr auf diese kompletten Block-Transaktionen bauen, sondern kann nur

50:09

noch 1.000 Zatz pro Wie-Byte, was ja in Relation zu einem Gesamtblock relativ klein ist.

50:14

Genau. Also vorher 100.000 zu nachher 1.000 ist also eine Verringerung von einem Faktor 100, wie

50:23

schlimm Pinning sein kann, dadurch, dass jemand eine niedrige Fee-Rate-Transaktion dranhängt

50:29

an deine Transaktion. Ich möchte klarstellen, dass wir nur ein Beispiel für eine Pinning-Transaktion gegeben

50:38

haben. Es gibt mehrere andere Konstruktionen, die für Pinning verwendet werden können und

50:45

manche von denen werden auch von Truck-Transaktionen mitigiert, aber ich glaube, wir wollen nicht

50:54

zurück und die anderen Pinning-Sachen angucken.

50:56

Nur, es gibt noch mehr Möglichkeiten, wie man Transaktionen pinnen könnte.

51:00

Zum Beispiel, indem man einen Vorfahrer einführt, der sehr große und niedrige Fees hat.

51:06

Das macht natürlich auch deine Transaktion deutlich langsamer.

51:09

Okay, aber vielleicht können wir nochmal, also die Frage, die sich mir immer noch stellt,

51:17

ist, also wie genau sorgen jetzt Truck-Transaktionen dafür, dass die Pinning-Attacke, wenn ich

51:24

es richtig verstanden habe, zumindest das Ausmaß dieser Pinning-Attacke stark reduziert

51:29

werden kann, sodass sie im Grunde unwirksam wird.

51:31

Genau, also wir kennen im Großen und Ganzen genau zwei Möglichkeiten, wie man eine Transaktion

51:39

beschleunigen kann. Möglichkeit 1 heißt CPFP.

51:42

Man hängt ein Kind dran, das eine höhere Fee hat.

51:45

Das Kind möchte von den Minern in einen Block gepackt werden.

51:49

Damit sie die Kind-Transaktion nehmen können, müssen sie die Eltern-Transaktion vorne dran

51:54

stehen haben und dadurch wird das Kind für die Eltern-Transaktion zahlen.

51:59

Child pays for parent. Die andere Möglichkeit ist, wir ersetzen eine Transaktion mit einer neuen Variante

52:05

der Transaktion, die eine höhere Fee-Rate hat und entweder den gleichen oder andere

52:11

Effekte, also andere Outputs erzeugt. Und das ist replace by fee, RBF.

52:16

RBF folgt den Regeln, die in BIP 125 stehen, in RBF.

52:23

Und Child pays for parent hat keine formellen Regeln.

52:27

Du machst einfach eine Kind-Transaktion, die viel Geld bietet.

52:30

Die Angriffe für Pinning werden durchgeführt, indem man entweder es schwer macht, die Transaktion

52:40

zu ersetzen oder teuer macht, die Transaktion zu ersetzen oder die es unmöglich machen,

52:47

ein weiteres Kind anzuhängen. Also eine weitere Variante für Pinning wäre, indem man eben die Ancestor, wir hatten ja

52:54

gerade schon über die Topologie gesprochen, wenn du 24 Kinder oder Kindeskinder dranhängst

53:00

an der Transaktion, dann kann der Verteidiger oder das Opfer keine Child pays for parent

53:06

durchführen, weil eben kein weiterer Nachfahre hinzugefügt werden darf.

53:10

Das ist eine andere Variante zu pinnen.

53:14

Diese Variante ist durch den sogenannten CPFP-Carve-Out entschärft.

53:21

Nämlich man darf immer eine weitere Kind-Transaktion des ältesten Vorfahren anhängen.

53:33

Also wenn man eine Kette von 25 Transaktionen hat, darf man an den Kopf eine noch dranhängen

53:40

und das ermöglicht einem Zweiparteien-System immer der anderen Partei mindestens noch eine

53:45

Transaktion dran zu hängen. Das ist das CPFP-Carve-Out.

53:47

Das ist das, was es jetzt heute schon gibt, oder?

53:49

Ja, das ist das, was es jetzt auch noch gibt.

53:52

Und das garantiert in Lightning eben, dass die Nachfahren auszuschöpfen kein valider

54:00

Angriff ist. Das ist nämlich ein sehr einfacher Angriff.

54:03

Wir können beide ein Output ausgeben an dieser Transaktion.

54:06

Ich hänge einfach so viele Nachfahren dran, dass du keinen dranhängen kannst.

54:11

Und damit ist Sense, der kann gar nichts machen.

54:14

Außer RBF, aber das geht ja nicht alleine bei einer 2 of 2 zum Beispiel.

54:19

Darf ich das nochmal versuchen zusammenzufassen für mich?

54:21

Ja. Wenn ich das richtig verstanden habe.

54:24

Glücklicherweise hat das deutsche Alphabet 26 Buchstaben.

54:28

Das heißt, wir können sagen, A ist die erste Transaktion und die hat 24 Nachfolger.

54:34

Also B bis Y.

54:37

Das sind also insgesamt diese 25 Transaktionen.

54:40

Child Pays for Parent Carve-Out erlaubt jetzt, dass ich eine Transaktion Z veröffentlichen

54:45

kann, was eigentlich entgegen der Regeln wäre, dass maximal 25 Transaktionen in diesem Cluster

54:50

zusammen sein können. Dadurch, dass Z aber direkt an A hängt, ist es zulässig.

54:55

Und damit kann ich effektiv die Transaktion A v-bumpen.

55:00

Perfekt, außer einer kleinen Anmerkung.

55:05

Es müssen alles Nachfahren von A sein, nicht nur ein Cluster.

55:10

Also, es ist eine Kette zum Beispiel.

55:12

A bis Y ist einfach eine Kette.

55:15

Ja, aber sonst, genau.

55:17

Also, der Verteidiger gegen diesen Angriff darf eben an A eine weitere Transaktion dranhängen,

55:24

würde jetzt zum Beispiel ein CPFP machen da mit einer hohen Gebühr.

55:27

Und damit ist der Angriff wirkungslos.

55:29

Okay, aber das ist CPFP Carve-Out, was wir aktuell drin haben.

55:36

So, und jetzt kommen Truck-Transaktionen.

55:38

Dadurch, dass Truck-Transaktionen ja definiert haben, dass sie nur quasi eine Beziehung haben

55:44

nämlich entweder zu einem Nachfolger oder zu einem Vorgänger.

55:50

So, ne? So ist es, genau.

55:52

Also, da tritt das Problem, das wir eben beschrieben haben,

55:56

wofür CPFP Carve-Out die Lösung ist, tritt dann nicht mehr auf,

55:59

weil es eben nur diese Eins-zu-eins-Beziehungen gibt.

56:02

Naja, wenn du jetzt also eine Elterntransaktion hast und schon ein Kind dranhängt,

56:09

dann kannst du ja das Paket nicht vergrößern.

56:12

Das sind ja schon zwei Transaktionen, du kannst also nicht ein zweites Kind dranhängen.

56:17

Und da kommen wir zu der sogenannten Sibling Eviction.

56:20

Wenn du ein anderes Kind von einer Truck-Transaktion veröffentlicht

56:24

und das hat eine höhere Fee-Rate, verdrängt es das Originalkind.

56:28

Also, du kannst Kinder immer ersetzen auf Truck-Transaktionen.

56:31

Dadurch kannst du eben in diesem Zwei-Transaktionen-Paket arbeiten.

56:35

Truck-Transaktionen sind immer ersetzbar.

56:40

Kinder von Truck-Transaktionen sind immer in Konflikt mit anderen Kindern

56:44

von der gleichen Elterntransaktion.

56:49

Also, dadurch brauchen wir keinen CPFP Carve-Out mehr.

56:53

Und das ist wichtig in dem Kontext, weil CPFP Carve-Out funktioniert nicht mit Cluster-Mempool.

56:59

Wir können keinen CPFP Carve-Out haben mit Cluster-Mempool,

57:02

weil wo genau ist denn eigentlich der erste Ancestor in einem Cluster?

57:08

Da können ja viele Ancestor-Transaktionen drin sein.

57:10

Das ist unklar. Das heißt, der CPFP Carve-Out, der im Moment für Lightning notwendigerweise existieren muss,

57:20

damit man eben gegen die Nachfahren-Flut-Attacke sicher ist,

57:32

der wird jetzt mitigiert dadurch, dass wir Truck-Transaktionen haben.

57:35

Die Idee ist, dass Lightning-Commitment-Transaktionen als Truck gelabelt werden,

57:41

also V3-Transaktionen.

57:43

Und dann kann eben genau ein Kind angehängt werden, das CPFP macht.

57:48

Das Kind ist größenbeschränkt, sodass man auch die anderen Pinning-Attacken nicht durchführen kann mit riesigen Transaktionen,

57:56

irgendwelchen Brocken, die die Transaktionen verlangsamen.

58:00

Also nicht komplett gelöst, aber um den Faktor 100 weniger schlimm.

58:06

Genau. Truck-Transaktionen machen dadurch, dass sie sich freiwillig auf zwei Transaktionen im Cluster beschränken,

58:17

sind jetzt nicht mehr so anfällig gegen die große angehängte Transaktion,

58:21

sind nicht anfällig gegen die Nachfahren-Flut und sind dadurch relativ leicht immer zu beschleunigen.

58:31

Thorsten, hast du noch eine Frage dazu? Ich überlege gerade, können wir nicht direkt von vornherein,

58:36

als die Person, die wirklich eine Truck-Transaktion veröffentlicht,

58:40

direkt auch irgendwie beide Transaktionen dann in den Mempool reingeben,

58:45

um quasi, dass man schon von vornherein ausschließt,

58:47

dass da eine bösartige Drittpartei diese zweite Transaktion da noch einbaut

58:53

und wir trotzdem dann diesen Schaden von bis zu 1000 Satz,

58:55

also hier diese 1000 V-Byte Schaden dann zufügen könnte,

58:58

um die direkt dann irgendwie auszuschließen?

59:02

Würde das funktionieren?

59:05

Ja, also die Idee ist jetzt natürlich,

59:08

die Eltern-Transaktion in dem Lightning-Beispiel ist eine 2-of-2-Multisig.

59:12

Das heißt, wenn Alice und Bob wieder unsere Channel-Partner sind,

59:17

haben die die zusammen erzeugt und weder Alice noch Bob

59:22

können später die V-Rate von der Eltern-Transaktion ändern.

59:26

Wenn die Transaktion von alleine durchgeht, braucht sie kein Kind

59:30

und kann auch nicht vom Kind verlangsamt werden.

59:33

Wenn die Transaktion aber eine zu niedrige V-Rate hat,

59:37

muss man ein Kind anhängen, um zu bumpen,

59:40

weil wir ja kein RBF verwenden können.

59:42

Und dann verdrängen jetzt aber Kinder sich gegenseitig,

59:47

sodass ich nicht Kind und Eltern ersetzen muss,

59:51

sondern nur das andere Kind. Und ich will ja eh mehr zahlen, als das andere Kind gezahlt hatte,

59:56

so dass, gut, vielleicht mein Kind wäre nur 100 Bytes

1:00:01

und das Kind, das der Böse gegenüber angehängt hat,

1:00:05

hätte 1000. Das heißt, ich kann vielleicht um den Faktor 100 mehr zahlen,

1:00:10

äh, sorry, Faktor 10 mehr zahlen müssen.

1:00:13

Aber vorher konnte es halt eine Transaktion von 100.000 an, ähm,

1:00:19

äh, verwenden und ich hätte vielleicht einen Faktor 1000 mehr zahlen müssen.

1:00:23

Also einen Faktor 100 weniger stimmen,

1:00:25

aber das ist leider nicht komplett zu verhindern.

1:00:28

Okay. Genau, also das war das, was ich meinte mit,

1:00:32

dass das Risiko einer pinnigen Attacke wird reduziert,

1:00:37

aber nicht gänzlich aus der Welt geschaffen. Das ökonomische Risiko dann zumindest, ne?

1:00:41

Ja, genau. Ja, ja, ja, genau.

1:00:44

Ja, also beziehungsweise das Risiko wird ja auf der Basis,

1:00:47

auf ökonomischer Basis kalkuliert, ne?

1:00:50

Mhm. Ja.

1:00:52

Jetzt würde ich ganz kurz sagen,

1:00:54

also ein, ein weiterer Besonderheit von Trunk, Truck Transaktionen ist,

1:01:00

eine Truck Transaktion darf eine Fee Rate von 0 haben.

1:01:03

Normalerweise verlangen wir ja immer, dass Transaktionen mindestens 1 Hard Preview bezahlen

1:01:09

und Truck Transaktionen dürfen also eine Fee Rate von 0 haben.

1:01:14

Warum? Weil wir können ja eine Elterntransaktion mit einer Fee von 0 haben

1:01:19

und dann mit dem Kind die Fee bringen.

1:01:21

Und das ermöglicht jetzt eben dieses Problem

1:01:26

mit den Commitment Transaktionen komplett zu umgehen.

1:01:28

Die Commitment Transaktion ist immer Fee Rate 0

1:01:32

und wenn du sie veröffentlicht willst,

1:01:35

entscheidest du in dem Moment, wo du veröffentlichen willst,

1:01:38

was die Fee Rate sein sollte und bringst die eben mit einem Kind.

1:01:42

Und das ist warum mir vor kurzem Leute,

1:01:45

ich habe, ich habe einen Vortrag gehalten bei PUBG

1:01:48

darüber, was so in 2024 in Bitcoin passiert ist

1:01:51

und ich habe meine Kollegen gefragt, die an Lightning arbeiten,

1:01:54

was ist denn das größte, was für Lightning passiert ist

1:01:59

und die meinen Bolt 12 und Packet Relay.

1:02:03

Nämlich. Okay, jetzt hast du aber schon das nächste Stichwort gesandt, Packet Relay.

1:02:08

Aber also, ich wollte da nur ganz kurz einhaken,

1:02:11

weil wir jetzt immer darüber gesprochen haben, bevor wir zu dem Thema Packet Relay übergehen,

1:02:15

weil wir immer darüber gesprochen haben, dass wir ja signalisieren irgendwie,

1:02:18

dass diese Transaktion, die ich hier veröffentliche, dass die eine Truck Transaction ist.

1:02:22

Du hast das Stichwort auch schon genannt, aber vielleicht kannst du noch einmal kurz erklären,

1:02:26

wie funktioniert denn aktuell tatsächlich dieses Signalisieren?

1:02:29

Hey, dies ist eine Truck Transaction.

1:02:32

Genau, okay.

1:02:34

Transaktionen haben ein Versionsfeld

1:02:37

und die Version war bisher beschränkt auf Version 1 und Version 2.

1:02:43

Andere Versionen waren nicht Standard.

1:02:46

Also, die wurden nicht von Bitcoin Core Nodes in ihren Mempool erlaubt,

1:02:52

außer wenn der non-standard konfiguriert war.

1:02:58

Also, Truck Transaktion führt als Signal V Version 3 ein.

1:03:07

Wenn man also eine Transaktion als Version 3 labelt,

1:03:11

dann signalisiert man damit,

1:03:13

dass man diese topologische Einschränkung erbittet

1:03:19

und dass diese Transaktion eben nur Cluster von zwei Transaktionen bildet.

1:03:24

Und, das haben wir, glaube ich, noch gar nicht gezeigt,

1:03:27

unbestätigte Truck Transaktionen können nur Truck Kinder und Truck Eltern haben,

1:03:34

sodass eben auch es nicht möglich ist,

1:03:37

an eine andere unbestätigte Transaktion, die nicht Truck ist,

1:03:41

eine Truck Transaktion anzuhängen oder umgekehrt.

1:03:45

Warum ist das wichtig? Das erschließt sich mir jetzt nicht sofort.

1:03:48

Also, nehmen wir mal an, unsere Commitment Transaktion im Lightning Channel ist eine Transaktion.

1:03:54

Warum ist es wichtig, dass auch die Child Transaktion eine Truck Transaktion ist

1:03:58

und nicht einfach eine normale Child Transaktion?

1:04:01

Weil eine normale Child Transaktion 100.000 WeBit haben dürfte?

1:04:05

Um das zu entforcen dann an der Stelle?

1:04:08

Also, für Eltern zu Kind ist es, glaube ich, ganz einfach.

1:04:12

Für Kind zu Eltern ist es mehr...

1:04:15

Ich glaube, da ist das Problem, wenn deine Eltern Transaktion schon andere Kinder hat zum Beispiel.

1:04:24

Oder viele Vorfahren hat,

1:04:26

dann ist Truck einfach nicht gegeben für das Kind.

1:04:28

Und es macht einfach keinen Sinn, die Kindbeschränkungen zu haben.

1:04:32

Ich glaube, deswegen... Also, entweder das Ganze klasst oder nicht.

1:04:36

Mhm. Vielleicht bin ich auch schief gewickelt,

1:04:40

aber ich dachte gerade, das ist doch logisch, oder?

1:04:42

Wenn eine Truck Transaktion, die als Kind auftritt,

1:04:48

kann ja nur als Truck Transaktion auftreten,

1:04:50

wenn die Eltern Transaktion bereits eine Truck Transaktion ist.

1:04:54

So ist das ja die Regel definiert. Insofern kann das ja gar nicht anders auftreten.

1:04:58

Du kannst keine Truck-Child Transaktion haben, die eine Eltern Transaktion hat, die keine Truck Transaktion ist.

1:05:04

Das ist auch richtig, ja. Ja, aber von der Definition.

1:05:07

Aber warum das notwendig ist?

1:05:09

Ich glaube, es wäre einfach ineffizient oder ineffektiv,

1:05:11

wenn man Truck Transaktion dranhängen würde.

1:05:14

Man könnte diese topological restriction,

1:05:17

also die Einschränkung der Topologie, nicht mehr entforsten,

1:05:21

weil die auf die Eltern Transaktion nicht zutrifft.

1:05:25

Genau. Okay, cool.

1:05:30

Jetzt hast du eben erzählt, dass die Lightning-Entwickler sich darüber sehr gefreut haben,

1:05:35

weil sie gesagt haben, die wichtigste Entwicklung in 2024

1:05:38

war Package Relay.

1:05:40

Wir haben diese beiden Themen, Truck Transactions und Package Relay, zusammengepackt,

1:05:44

weil nach meinem Verständnis gibt es Truck Transaktionen eben nur,

1:05:48

wenn wir sie gemeinsam mit Package Relay implementieren oder veröffentlichen.

1:05:52

Das wäre jetzt mein initiales Verständnis.

1:05:54

Das ist fast richtig.

1:05:57

Ich würde sagen, du kannst natürlich Truck Transaktionen einzeln haben,

1:06:00

also zum Beispiel in unserem Beispiel,

1:06:03

wenn die Commitment Transaktion eine Truck Transaktion ist,

1:06:05

aber nicht Zero Fee, dann könnte die ja eine niedrige, aber valide Fee Rate haben.

1:06:11

Und wenn es eben der Mempool gerade ruhig ist

1:06:13

und die einfach so durchgeht, muss man ja kein Kind dranhängen.

1:06:17

Also eine Truck Transaktion darf alleine stehen,

1:06:21

aber die besonderen Eigenschaften von Truck Transaktionen

1:06:25

sind nur im Kontext des Pakets relevant und hilfreich.

1:06:30

Aber wenn wir ja standardmäßig die Elton-Transaktion

1:06:33

über dem Lightning Channel immer mit 0 Satz pro V-Byte,

1:06:35

die würde ja niemals gemeint werden.

1:06:37

Genau. Ja, halt.

1:06:40

Es ist erlaubt, dass eine Transaktion Zero Fee hat,

1:06:43

aber nicht notwendig. Also man könnte schon eine Truck Transaktion machen,

1:06:46

die 10.000 V-Bytes hat.

1:06:48

Und es ist jetzt auch eine Frage,

1:06:50

genau wie das alles eingeführt wird in Lightning,

1:06:53

weil natürlich erst mal viele Bitcoin Core Nodes

1:06:57

upgedatet werden müssen zur Version 28,

1:07:01

wo dann eben Support für Truck Transaktionen,

1:07:04

für Package Relay und so weiter drin ist.

1:07:08

Und solange das auf dem Netzwerk nicht existiert,

1:07:10

will man vielleicht keine Lightning Channel drauf bauen,

1:07:12

die zum Beispiel erwarten,

1:07:15

dass Zero Fee Transaktionen erlaubt sind und so weiter.

1:07:18

Also der Rollout ist nicht ganz trivial.

1:07:23

Wenn du jetzt schon dabei bist, dann können wir auch dann bevor wir zu Package...

1:07:26

Wo war ich da? Eigentlich wollte man da erst am Ende drauf zukommen.

1:07:28

Jetzt hast du schon erzählt, wie so der Status eigentlich so ein bisschen davon ist.

1:07:34

Also in Version 28 von Bitcoin Core,

1:07:37

ich glaube, das haben wir letztes Mal schon ein bisschen erwähnt,

1:07:40

sind jetzt einige Sachen drin. Pay-to-Anchor ist drin.

1:07:44

Package Relay für One Parent, One Child,

1:07:47

also für zwei Transaktionen,

1:07:49

für Cluster von zwei Transaktionen oder Pakete von zwei Transaktionen ist Package Relay drin.

1:07:56

V3 Transaktions Support ist drin. Truck Transaktion ist drin.

1:08:00

V3 Transaktionen sind jetzt Standard in der Version.

1:08:03

Aber ist V3 denn wirklich...

1:08:06

Also ist die Änderung von V2 zu V3

1:08:09

nur das, was mit Truck jetzt gekommen ist

1:08:12

oder ist da noch mehr drin? Ja, also V1 und V2 Transaktionen sind immer noch erlaubt.

1:08:18

Aber wenn du eben eine Transaktion machst,

1:08:20

die Version 3 verwendet,

1:08:22

dann signalisierst du, dass sie sich gerne den Regeln von Truck Transaktionen unterlegen.

1:08:27

Also das ist die einzige Änderung, die da jetzt quasi in V3...

1:08:31

Das ist quasi Truck.

1:08:34

Genau. Okay.

1:08:36

Also was ist der Stand?

1:08:39

Genau, in Bitcoin Core ist der Release.

1:08:43

Hatte Unterstützung dafür.

1:08:46

Jetzt dauert es vermutlich ein halbes Jahr oder so mindestens,

1:08:49

damit eine ordentliche Node-Population entsteht

1:08:52

mit der Version 28.

1:08:56

Mein Verständnis ist, dass die verschiedenen Lightning-Teams

1:09:00

jetzt darüber gesprochen hatten im Lightning-Entwickler-Meeting

1:09:04

und dass sie vermutlich nächstes Jahr,

1:09:07

Ende nächsten Jahres oder so,

1:09:09

anfangen wollen, generell V3 zu verwenden.

1:09:13

Und ja, dann hoffentlich zum Beispiel,

1:09:18

um zurückzukommen auf den Babylon-Start,

1:09:21

da war über Nacht eben prompt die Fee-Rate

1:09:24

auf 1000 Sats per V-Bit hochgegangen.

1:09:26

Und ganz viele Channels sind zugegangen, weil Lightning-Nodes sich nicht einigen konnten,

1:09:31

was die aktuelle Fee-Rate für Channels sein sollten.

1:09:34

Und dann wurden viele Channels unilateral geschlossen.

1:09:38

Und so etwas würde eben nicht mehr passieren,

1:09:41

wenn die Commitment-Transaktion eine Fee von 0 haben könnte

1:09:45

und man eben die Fee der Commitment-Transaktion

1:09:48

über die Kind-Transaktion in dem Moment entscheiden kann,

1:09:51

wo man die Kind-Transaktion generiert.

1:09:55

Aber wenn man jetzt so ein bisschen darüber nachdenkt,

1:10:00

und dann nochmal in Kontakt bringt, was eigentlich dann bei einer Lightning-Zahlung passiert,

1:10:05

dass da ja dann die HTLCs aufgebaut werden, wo die im Endeffekt ja auch nichts anderes sind

1:10:08

als unbestätigte On-Chain-Transaktionen,

1:10:10

sieht man ja, oder kann man sich wahrscheinlich schon so überlegen,

1:10:13

wie aufwendig das jetzt wird, diese Getrack-Logik dann auch in die ganzen Lightning-Nodes

1:10:17

dann reinzubringen, dass dann wirklich auch diese komplette Transaktionskonstruktion

1:10:22

in Form der HTLCs dann auch da dann entsprechend dann implementiert ist.

1:10:26

Ich glaube, das wird gar nicht so schlimm.

1:10:29

Also ich bin bereit korrigiert zu werden,

1:10:34

falls ich mich falsch erinnere, aber HTLCs sind Outputs auf der Commitment-Transaktion.

1:10:39

Also wenn man ein HTLC, ein Multi-Hop-Contract staged,

1:10:45

dann sagt man dem Channel-Partner,

1:10:48

ich möchte eine HTLC zur Commitment-Transaktion hinzufügen.

1:10:52

Channel-Partner wird gegensegniert und so weiter.

1:10:55

Es ist so ein kleiner Tanz hin und her.

1:10:58

Man hat dann eine Commitment-Transaktion mit dem HTLC,

1:11:01

dann wird das Multi-Hop-Payment durchgeführt,

1:11:04

die Resolution kommt zurück

1:11:07

und der HTLC wird eben zu einer oder anderen Seite zurückgefaltet

1:11:11

und man macht eine neue Commitment-Transaktion. Das heißt, es sind nicht getrennte Transaktionen,

1:11:15

sondern nur Outputs. Aber ja, zum Beispiel HTLCs sind einer der Gründe,

1:11:19

warum es so dringlich sein kann, einen Channel zu schließen,

1:11:23

weil wenn zum Beispiel ein HTLC auf dem Channel drauf ist

1:11:27

und der Channel-Partner eben aufhört zu reagieren,

1:11:30

dann könnte man ja Geld verlieren,

1:11:32

weil der HTLC irgendwann sein Zeitlimit erreicht

1:11:36

und davor muss die Transaktion eben in einem Block sein,

1:11:39

damit man das Geld erhält.

1:11:42

Und dann gibt es natürlich eine Transaktion, um den HTLC-Output auszugeben.

1:11:48

Das ist aber eine zweite Transaktion, die eben, ich glaube, sogar erst angehängt werden kann,

1:11:53

nachdem die Eltern Transaktion,

1:11:55

die Commitment-Transaktion bestätigt ist.

1:11:58

Ist das Arbeit, die jetzt die Node-Implementierung,

1:12:02

also die Lightning-Implementierung wie LND, CLN und so weiter

1:12:06

durchführen müssen? Oder ist das etwas, was eine Wallet-Software,

1:12:08

die auf so einer LND-Node drauf sitzt, übernehmen müsste?

1:12:13

Ne, das ist in der Node-Software.

1:12:15

Das ist in der Node-Software. CLN, Async, LDK.

1:12:19

Die sind jetzt also wahrscheinlich schon längst dabei,

1:12:22

daran zu arbeiten, wie sie das jetzt,

1:12:24

die einen mehr, die anderen weniger vielleicht,

1:12:26

man weiß es nicht. Dadurch, dass sie darauf warten müssen,

1:12:29

dass das Netzwerk eben Support für V3-Transaktionen hat

1:12:33

und das flächendeckend, also sagen wir mal,

1:12:35

mindestens 20 Prozent der Nodes müssen das haben,

1:12:38

damit das einigermaßen sicher durchgeht.

1:12:40

Und dann müssen es vor allem aber auch Miner haben. Die Miner müssen ja V3-Transaktionen minen.

1:12:45

Und das dauert dann, also die Nodes kommen eigentlich

1:12:47

schneller als die Miner, manchmal zumindest.

1:12:50

Wobei jetzt die neueren Miner sind ein bisschen technisch versierter,

1:12:53

hatte ich den Eindruck. Also manche von denen unterhalten sich öfter mal mit uns

1:12:57

Bitcoin-Entwicklern. Ja, also die wollen ein bisschen Zeit lassen,

1:13:03

dass das Netzwerk wirklich auch sicher

1:13:06

diese Transaktionen bestätigt und in Blöcke packt.

1:13:10

Also die Miner, die akzeptieren.

1:13:13

Und dann werden sie es einsetzen.

1:13:16

Ich glaube, dass tatsächlich noch keine Arbeit, um Truck-Transaktionen zu implementieren, stattfindet.

1:13:22

Ich weiß, dass Pay-to-Anchor schon experimentell verwendet wurde

1:13:27

auf Testnet und Signet, was auch schön verwandt ist hier.

1:13:35

Aber ich weiß gar nicht, ob wir das Fass aufmachen wollen.

1:13:37

Heute nicht, ein anderes Mal.

1:13:41

Was ich mir jetzt auch noch schwierig vorstelle,

1:13:45

zumindest jetzt in der Interaktion mit dem Anwender einer Lightning Node,

1:13:50

der muss ja im Ende definieren, bzw. die LND oder die Wallet,

1:13:56

muss er irgendwie definieren, wie sieht denn jetzt eben diese Truck-Transaction Child, wie sieht die eigentlich genau aus?

1:14:01

Wo geht die hin? Auf welche Adresse? Wo will ich die eigentlich hinhaben?

1:14:04

Da ist sicherlich auch noch einiges zu machen,

1:14:07

weil der User ja dann entscheiden muss, wo soll denn die, also A, wo soll die Transaktion hinführen?

1:14:12

Was ist das Ziel? Und welche Fee möchte ich denn jetzt anbinden?

1:14:16

Das wird er ja sicherlich selber entscheiden wollen

1:14:18

und vielleicht nicht unbedingt der Logik der Gebührenabschätzung

1:14:23

von seiner Core Wallet oder von seiner Lightning-Implementierung

1:14:26

überlassen wollen.

1:14:29

Ja, das ist halt die Frage, ob das jetzt sich dann so sehr zu jetzt ändert.

1:14:34

Ich glaube, dass es tatsächlich sehr ähnlich ist,

1:14:36

weil im Moment verwenden Lightning-Channel auch schon Anker-Outputs.

1:14:40

Also die Channel haben generell eine konservative Fee,

1:14:46

die hoch genug sein muss, dass wenn der Mempool voll ist,

1:14:49

die Commitment-Transaktion noch in den Mempool kommt.

1:14:52

Aber dann die Feinjustierung wird auch schon mit Kind-Transaktionen gemacht,

1:14:59

die an sogenannten Anker-Outputs andocken.

1:15:02

Und zwar die erste Variante davon hat zwei Anker-Outputs,

1:15:07

einen für jeden Channel-Partner, wo der dann eine Kind-Transaktion dranhängen kann,

1:15:11

um CPFP zu machen.

1:15:14

Und ja, also ich glaube, im Großen und Ganzen ist der Flow sehr ähnlich.

1:15:23

Das Problem, das wegfällt, ist,

1:15:25

dass die Commitment-Transaktion alleine genug Fees haben muss,

1:15:29

damit sie überhaupt erst in den Mempool kommt,

1:15:31

weil Truck-Transaktion eben die Eltern-Transaktion

1:15:34

eine Fee von null haben darf.

1:15:38

Jetzt sind wir schon beim Ausblick.

1:15:41

Jetzt wollte ich doch einmal noch ganz kurz,

1:15:43

wir sind jetzt schon relativ tief drin oder lange dabei,

1:15:47

noch einmal ganz kurz Package-Relay besprechen.

1:15:50

Ich glaube nicht, dass wir es einmal vielleicht sauber definieren,

1:15:52

was ist das eigentlich mit Package-Relay?

1:15:56

Vielleicht noch mal ganz kurz, was ist die aktuelle Situation, das Problem dabei?

1:16:00

So wie ich das verstanden habe, war dadurch, dass ja jede Node selber entscheidet,

1:16:04

wie sie unbestätigte Transaktionen in ihrem Mempool aufnimmt,

1:16:11

kann es passieren, dass sie einfach Transaktionen abweist,

1:16:15

die einfach eine zu niedrige Fee-Rate haben.

1:16:18

Genau, das ist glaube ich gerade das Problem,

1:16:22

aber das ist die Situation, die wir haben.

1:16:25

Welches Problem entsteht dabei und wie kann jetzt Package-Relay dabei helfen,

1:16:29

das ein bisschen aufzulösen, das Problem?

1:16:32

Genau, also gehen wir noch mal konkret zurück

1:16:35

zu unserem Lightning Channel. Alice und Bob haben einen Lightning Channel.

1:16:38

Bob ist im Urlaub und die Fee-Rates im Mempool explodieren

1:16:44

und Alice hat einen HTLC, der bald ein Zeitlimit erreicht

1:16:51

und muss den Channel schließen.

1:16:53

Wenn jetzt die Commitment-Transaktion so eine niedrige Fee-Rate hat,

1:16:57

dass sie nicht in Mempool aufgenommen wird,

1:16:59

weil der Nachbar Mempool vielleicht mindestens 20 Sets PV-Bit braucht,

1:17:03

um überhaupt erst Transaktionen zu akzeptieren

1:17:07

und die Commitment-Transaktion war nur 15.

1:17:10

Dann kann Alice, das Node, diese Transaktion anbieten,

1:17:16

aber wahrscheinlich geht die Transaktion

1:17:19

nicht mal in Alice, das eigene Bitcoin-Core-Node,

1:17:22

weil sie ja auch schon da die Minimum-Fee-Rate nicht erreicht.

1:17:27

Wo Package-Relay jetzt ins Spiel kommt,

1:17:29

ist, bisher betrachten wir eben Transaktionen immer individuell.

1:17:35

Wenn eine Transaktion selbst nicht die Minimum-Fee-Rate erreicht,

1:17:40

kommt sie nicht in den Mempool. Dann kommt die Kind-Transaktion an.

1:17:44

Der Node sagt, ich kann nicht sagen, wie viel Fee die hat,

1:17:48

weil ich den Input nicht kenne. Ich packe die erstmal in mein Kinderheim, in das Orphanage

1:17:55

und dann frage ich den Nachbar zurück, hey, hast du die Eltern-Transaktion?

1:18:01

Und dann kriege ich die Eltern-Transaktion,

1:18:03

die Fee-Rate ist zu niedrig, niedriger als meine Minimum-Fee-Rate.

1:18:07

Ich sage, hey, Eltern-Transaktion, geh weg, dich will ich nicht.

1:18:11

Und die Kind-Transaktion bleibt im Kinderheim

1:18:14

oder wird sogar verworfen, weil die Eltern-Transaktion nicht reingeht.

1:18:19

Und wenn ich eben jetzt zwei Transaktionen zusammen

1:18:24

als Gruppe verschicken kann, dann kann ich als Node sagen, hey, ich habe ein Paket von Transaktionen,

1:18:29

die du zusammen evaluieren solltest.

1:18:32

Ich gebe dir sofort Transaktionen A und B zusammen als Paket

1:18:35

und du siehst, aha, B ist ein Kind von A.

1:18:40

B, wenn ich A betrachte und weiß, was der Output ist,

1:18:44

den ich in B ausgebe, hat eine saftige Fee

1:18:48

und zusammen als Paket sind die höher als meine Minimum-Fee-Rate,

1:18:52

sogar vielleicht hoch genug, dass die bald bestätigt werden.

1:18:55

Und dann will ich die natürlich absolut in meinem Mempool haben.

1:18:57

Also die Idee ist, dass man eben viele dieser Transaktionskettenprobleme

1:19:04

lösen kann, wenn man denn nur Transaktionen zusammen verschicken könnte.

1:19:08

Und generell das Thema Package Relay meint jetzt einfach,

1:19:11

wie würde man das hinkriegen,

1:19:14

dass wir auf unserem Gossip-Netzwerk,

1:19:18

also unserem Plaudernetzwerk,

1:19:20

mehrere Transaktionen zusammen als Gruppe verschicken kann,

1:19:24

ohne neue DOS-Angriffsflächen einzuführen.

1:19:27

Welche neuen Peer-to-Peer-Nachrichten brauchen wir denn dafür?

1:19:32

Wie muss ich die Validierungslogik ändern,

1:19:35

damit wir Pakete verarbeiten können?

1:19:38

Wer initiiert Package Relay?

1:19:42

Fragt der Sender nach, hey, ist das ein Paket?

1:19:44

Kannst du mir das ganze Paket geben? Oder tut der, sorry, fragt der Empfänger nach

1:19:49

oder tut der Sender anbieten, hey, ich hab ein Paket, willst du das Paket?

1:19:53

Wie verhindert man, dass die gleiche Transaktion fünfmal probiert wird,

1:19:58

wenn eine Transaktion vier Kinder hat und ich die viermal als Paket gebe mit jedem der vier Kinder?

1:20:03

Solche Dinge.

1:20:05

Das sind die offenen Fragen mit Package Relay.

1:20:08

So weit, so gut?

1:20:11

Fragen? Das klingt ja vom Grundprinzip eigentlich genauso wie das,

1:20:16

was wir in der letzten Woche über Cluster-Mempool besprochen haben.

1:20:18

Das wäre ja eigentlich, dass die Packete von der Logik her ja eigentlich ein Cluster sind.

1:20:22

Genau. Weil die gehören zusammen und die würde ich jetzt erwarten,

1:20:26

dass wir die auf Paketebene dann auch weiterverteilen würden,

1:20:29

dass wir, wenn wir ein Cluster gebildet haben, dass wir diese Cluster dann auch an unsere Nachbarnot dann weitergeben.

1:20:35

Also wenn man diese beiden BIPs dann irgendwie zusammen kombinieren könnte,

1:20:38

könnte ich mir vorstellen, dass das vielleicht ein Weg wäre.

1:20:40

Ja, und da ist genau auch die Verwandtschaft.

1:20:44

Also wie gesagt, Gloria hatte vier Jahre schon an Package Relay gearbeitet

1:20:50

und eben genau diese Designfragen erforscht und so fort.

1:20:53

Und es gab für viele Dinge einfach keine guten Antworten,

1:20:57

bis eben Cluster-Mempool angefangen hat zu reorganisieren.

1:21:02

Wie denken wir denn eigentlich über den Mempool nach?

1:21:04

Und jetzt die Transaktion eben in dem Kontext eines Clusters betrachtet,

1:21:08

statt in dem Kontext eines Ancestorsets.

1:21:11

Und eben Regeln dafür aufgestellt hat,

1:21:15

wie man zum Beispiel zwei Gruppen von Transaktionen miteinander

1:21:18

auf Mempool-Incentives oder Mining-Incentives vergleicht.

1:21:22

Was vorher einfach nicht klar war,

1:21:25

wie könnte man denn eigentlich überhaupt zwei Gruppen miteinander vergleichen.

1:21:29

Vielleicht will ich ja nur ein Subset von den Transaktionen,

1:21:36

die mir hier als Replacement-Set angeboten werden,

1:21:39

weil die anderen sind nicht gut oder vielleicht sogar invalide,

1:21:42

aber der Rest ist toll. Und dadurch, dass eben diese Arbeit an Cluster-Mempool stattgefunden hat,

1:21:48

gab es sozusagen einen kleinen Durchbruch bei Package-Relay,

1:21:52

weil viele dieser Strukturen, nämlich das V-Ray-Diagramm

1:21:57

und die neuen RBF-Regeln, die sich von Cluster-Mempool ableiten,

1:22:02

die haben eben Package-Relay überhaupt erst analysierbar oder gangbar gemacht.

1:22:09

Und dadurch, dass jetzt Cluster-Mempool angefangen hat,

1:22:12

bewegt sich beides wieder, würde ich sagen.

1:22:15

Cool. Also mir raucht so ein bisschen der Kopf, muss ich jetzt echt mal gestehen.

1:22:21

Ich weiß nicht, Thorsten, hast du noch eine wichtige Frage an den Merch?

1:22:26

Ich habe eine Frage an mich.

1:22:28

Darf ich ganz kurz?

1:22:30

Also ich hatte eben beschrieben, wie bisher ein Paket von zwei Transaktionen

1:22:36

eben vor Version 28 nicht propagiert werden konnte,

1:22:41

also nicht weiter gesendet werden konnte,

1:22:44

weil egal ob Kind- oder Elterntransaktion zuerst kommt,

1:22:48

für das Kind kennen wir den Vorfahren nicht

1:22:51

und deswegen können wir den Input nicht bewerten.

1:22:54

Und für die Elterntransaktion ist vielleicht die V-Rate zu niedrig

1:22:57

und wir weisen sie ab und damit wird das Paket abgewiesen.

1:23:00

Und eben was jetzt in Version 28 von Bitcoin Core released wurde,

1:23:05

ist sogenanntes opportunistic one parent, one child Packet Relay,

1:23:13

nämlich was jetzt passiert ist,

1:23:16

wir haben immer noch unsere Transaktion A, die die Elterntransaktion ist

1:23:19

und dann Transaktion B, die das Kind ist.

1:23:24

Der Node, der eine Transaktion weiterleiten möchte,

1:23:28

schickt die Kind-Transaktion.

1:23:32

Der andere Node sagt, er kenne die Elterntransaktion nicht,

1:23:36

packt die Transaktion erstmal ins Kinderheim, in die Orphanage,

1:23:41

fragt also beim ersten Node an, hey, kannst du mir die Elterntransaktion geben?

1:23:45

Die Elterntransaktion kommt an,

1:23:48

individuell hat sie eine zu niedrige V-Rate

1:23:51

und das einzige, was wir jetzt anders machen ist,

1:23:54

wir gucken, haben wir irgendwas im Kinderheim, was da dazu passt?

1:23:58

Und wenn ja, tun wir diese zwei Transaktionen als Paket bewerten und evaluieren.

1:24:03

Und wenn die zwei Transaktionen als Paket eine hohe V-Rate haben

1:24:07

oder eine hinreichende V-Rate haben,

1:24:09

dann packen wir die als Paket in unseren Mempool

1:24:12

und so kann eben, solange die Kind-Transaktion noch im Orphanage,

1:24:16

also im Kinderheim ist,

1:24:18

können wir one parent, one child Transaktionen propagieren im Netzwerk,

1:24:23

ohne irgendwelche neuen P2P-Messages,

1:24:26

also Peer-to-Peer Nachrichten,

1:24:28

mit denen man sich über zum Beispiel neue Transaktionen austauscht.

1:24:32

Und das ist eben released und deswegen sieht diese Zukunft,

1:24:37

in der wir hoffentlich Commitment-Transaktionen mit Zero-Fee haben,

1:24:43

sehr, sehr greifbar aus.

1:24:45

Das bedeutet jetzt dieses one child, one parent,

1:24:48

was du gerade beschrieben hast, ist jetzt erst mal so eine Quick-Win-Lösung,

1:24:52

die man vielleicht noch weiter ausgestalten müsste

1:24:55

für die komplexeren Fälle, die vielleicht dann noch kommen werden,

1:24:58

aber jetzt für diesen Use-Case von Lightning,

1:25:01

damit hat man da schon eine sehr, sehr einfache Lösung,

1:25:03

weil man wenig Anpassungsbedarf an der Stelle hatte

1:25:06

und das konnte man trotzdem schon eine Lösung dafür anbieten an der Stelle.

1:25:09

Ja, genau. Also mit Track-Transaktionen spezifisch,

1:25:15

dadurch, dass die eh schon auf Pakete von zwei Transaktionen limitiert sind,

1:25:19

die können, solange niemand,

1:25:22

also es ist kein verlässlicher Package-Relay,

1:25:26

weil eben ja jemand dein Orphanage einfach,

1:25:29

es sind maximal 100 Transaktionen im Orphanage,

1:25:32

also wenn jemand ganz viele elternlose Transaktionen schicken würde,

1:25:37

dann könnten sie dein Orphanage so schnell durchiterieren,

1:25:43

dass die Transaktion schon weg ist,

1:25:46

wenn du nach der Elterntransaktion fragst.

1:25:49

Aber generell, wenn dich niemand angreift, dann funktioniert das einfach.

1:25:52

Die Elterntransaktionen mit dem Kind zusammen werden propagiert

1:25:56

und wir können Track-Transaktionen mit der Elterntransaktion von Zero-Fee

1:26:02

übers Netzwerk weiterleiten.

1:26:04

Und ja, es ist so ein erster,

1:26:11

der erste Teil von Package-Relay,

1:26:13

das ist noch nicht das, was hier in BIP-331,

1:26:17

Ancestor Package-Relay beschrieben ist.

1:26:19

Deswegen ist es auch noch ein Draft in der Form dann,

1:26:22

aber das andere war dann jetzt erstmal so,

1:26:24

okay, das können wir jetzt, wie gesagt, schnell lösen,

1:26:28

dann schnell was drauf bauen dann.

1:26:31

Ja, aber ich möchte eben nicht das falsch darstellen,

1:26:35

das ist super cool schon. Das funktioniert nämlich generell,

1:26:37

außer wenn gerade jemand aktiv versucht, das zu verhindern.

1:26:41

Es ermöglicht unsere Track-Transaktionen,

1:26:43

es ermöglicht Zero-Fee-Channels hoffentlich,

1:26:48

vor allem in dem Zusammenhang mit Pay-to-Anchor

1:26:51

und FML-Dust, aber da können wir mal ein anderes Mal drüber reden.

1:26:58

Gut, also ich muss sagen, ich war jetzt die letzten zwei Minuten echt abgehängt,

1:27:03

aber das schiebe ich jetzt einfach auf meine Müdigkeit

1:27:05

nach einem langen Arbeitstag bei uns. Es ist hier 22 Uhr und noch was.

1:27:11

Ich sage erstmal vielen Dank, Murch, dass du dir mal wieder die Zeit genommen hast.

1:27:15

Wir haben heute über Track-Transaktionen und Package-Relay gesprochen.

1:27:19

War sehr cool. Murch, wir werden dich bestimmt demnächst wieder mal einladen.

1:27:23

Mir macht es immer Spaß, über diese Themen zu diskutieren.

1:27:27

Liebe Zuhörer, wenn ihr das auch cool findet,

1:27:29

denkt daran, wir sind ein Value-for-Value-Podcast

1:27:31

und dabei belasse ich es heute auch mal mit den Value-for-Value-Ansagen.

1:27:35

Murch, nochmal vielen Dank. Thorsten, auch dir vielen Dank.

1:27:38

Focus on the Signal. Not on the Noise.

1:27:41

Danke, macht's gut. Tschau, schön war's.

1:27:44

Tschau, tschau. [Musik]

1:27:57

Nodesignal.

1:27:59

Focus on the Signal.

1:28:02

Not on the Noise.

1:28:04

[Musik]

1:28:11

[MUSIK]