Lightning Kanal öffnen fehlgeschlagen - alles verloren?

yellow · 13. Juli 2023 um 21:13

Ich denke ich habe eine große Menge Geld verloren, weil mit dem Kanal öffnen etwas schief gegangen ist. Ich verstehe nur bis zu einem gewissen Punkt, was vor sich gegangen ist. Vielleicht kann mir hier jemand sagen, ob es noch irgend eine Chance gibt.

Angefangen hat es damit, dass ich aus Versehen einen Kanal zu WalletOfSatoshi mit viel zu geringen Gebühren eröffnet habe. Nun habe ich nach einem Weg gesucht, die Gebühren zu erhöhen. Erst habe ich das mit RTL versucht, schlug aber fehl. Es war zwar RBF, aber da ich die volle Menge gesendet habe, gab es keinen modifizierbaren Output. Somit kam ich zum Schluss, dass ich RBF nicht nutzen kann.

Also habe ich versucht den Kanal zu schließen. Das ging, aber er wurde nicht geschlossen, da die Transaktion nur im Mempool war. Dann habe ich force close probiert… wieder das Selbe.

Dann habe ich in der Lightning FAQ den Artikel How to forget about a channel? gefunden. Das habe ich gemacht. Nur konnte ich aus irgend einem Grund die UTXOs nicht wo anders hin transferieren. Das Vergessen des Channels hat aber geklappt.

Da aber nun die ursprüngliche Transaktion zum Kanal eröffnen immer noch nicht aus dem Mempool verschwand, bekam ich Angst, dass sie irgendwann durchgeht, der Lightning Node den Channel aber nicht mehr kennt. Also habe ich versucht die Transaktion über die Bitcoin Wallet mit einem double spend zu überschreiben.

Dafür habe ich den private key der Lightning-Wallet in Core Bitcoin importiert. Das hat funktioniert. Über das löschen vom Mempool ist die Transaktion auch verschwunden und ich konnte die UTXOs noch einmal mit sehr hohen Gebühren abschicken.

Aber da passierte auf einmal etwas, das ich mir nicht erklären kann. Auf einmal tauchte ein RBF der ursprünglichen Transaktion zum Kanal eröffnen auf, der aber an eine andere Adresse ging. Das war Transaktion 9966c12044656d8bc13823413828b15574895949d1530b20a92d911a49d15a7a. Man sieht da auch die Ursprüngliche, die ersetzt wurde.

Das habe ich aber nicht initiiert und ich habe keine Ahnung was da passiert ist. Jedenfalls ist diese Transaktion dann in der Chain gelandet, weil mein double spend irgendwie nicht gebroadcastet wurde.

Kann es sein, dass das WalletOfSatoshi irgendwie anstoßen konnte? Haben sie jetzt Zugriff auf die Gelder bekommen? Wem könnte die Adresse gehören wo die Gelder jetzt gelandet sind? Sieht irgendjemand eine Chance, wie ich auf das Guthaben noch zugreifen könnte? Bin echt etwas verzweifelt, weil es nicht wenig ist…

utxo · 14. Juli 2023 um 06:51

Allgemeiner Hinweis: Bitte NIEMALS einen Channel vergessen lassen (abandonchannel bei LND / dev-forget-chan bei CLN), solange dieser sich noch im Mempool befindet und die Funds noch nicht wieder in der eigenen Wallet sind!

Hast du versucht, diese Rescan-Methoden auszuprobieren: FAQ — Core Lightning b8519a6-modded

yellow · 14. Juli 2023 um 07:15

Ja, das war ziemlich dumm mit dem Channel vergessen. Hatte schon so viel probiert und war genervt. Das war unverantwortlich. Danke, dass trotzdem helfen willst.

Ja, ich habe --rescan=depth und dev-rescan-outputs gemacht. Hat nichts geändert. War aber auch nur eine leise Hoffnung, weil die UTXOs ja schon onchain auf diese Adresse gegangen sind, die nicht mir gehört.

Im Endeffekt kann diese verlinkte Transaktion ja nur von meinem private Key angestoßen worden sein oder ein force close von der WalletOfSatoshi? Sonst hätte ja niemand Zugriff auf die UTXOs. Wenn es ein force close der WalletOfSatoshi ist, wäre das denkbar dass sie meine UTXOs auf eine Adresse von ihnen auszahlen konnten, weil mein Lightning Node den Channel vergessen hat?

ViresInNumeris · 14. Juli 2023 um 07:56

Oha, tut mir leid für Dich, falls es wirklich so ist! Das ist wirklich nicht wenig.

Hätte ich auch als vernünftigste Lösung angesehen.

Ja, das sieht so aus.

„Channel vergessen“ kenne ich so leider nicht. Aber mMn kann das nicht passieren, dass der LN Partner Zugriff auf Deine UTXO hat.
Du hast ja bestimmt gesehen, dass auf der Zieladresse (32GxVZ9Ry…) schon andere Transaktionen bestehen? Alle zwischen
2023-06-04 12:01
2023-06-05 16:21
Sagt Dir das ev. etwas? Hast Du da mit LN experimentiert oder so?

yellow · 14. Juli 2023 um 08:25

Danke fürs mitdenken. Ja das habe ich gesehen. Wie gesagt hatte ich ja erfolglos versucht ein RBF zu machen. Hatte erst gedacht dass es vielleicht doch irgendwie funktioniert hätte. Aber dann wäre es ja wieder eine Channel opening Transaktion. Offensichtlich ist das aber eine Transaktion zu einer Wallet?

Leider konnte ich es mit nichts von mir in Verbindung bringen. Genau in der Zeit wo diese Adresse aktiv war, war ich überhaupt nicht mit dem lightning Node aktiv. Wenn es nicht WalletOfSatoshi war und nicht ich könnte nur noch parallel jemand in Besitz meines private key gekommen sein?

ViresInNumeris · 14. Juli 2023 um 11:20

Bin nicht sicher, das Internet sagt mir:

How the Three Formats of Bitcoin Addresses Work

    P2PKH or Legacy Address Format (addresses start with “1”)
    P2SH or Compatibility Address Format (addresses start with “3”)
    Bech32 or Segwit Address Format (addresses start with “bc1”)

Es handelt sich also um eine P2SH also Pay To Script Hash Adresse, und nicht um eine „normale“?! Könnte das nicht eine Channel Opening Tx sein, mit einem entsprechenden Script dahinter? Ok, die vielen kleinen Inputs auf diese Adresse passen nicht dazu. Und auch nicht, dass Du nicht aktiv warst in dieser Zeit mit LN. Aber vielleicht mit der WalletOfSatoshi?!
Es wäre ja irgendwie auch seltsam, wenn Dich da tatsächlich jemand bestohlen hat und das Diebesgut dann einfach auf einer P2SH Adresse mit vielen anderen UTXO liegen lässt. Das wäre dann ein ziemlich unvorsichtiger/dummer Dieb.

Zugegegeben, ich fische hier auch ziemlich im Trüben. (Aber genau wegen solcher Beiträge / Fragen bin ich v.a. hier im Forum. Theretisch denke ich immer, ich verstehe schon Vieles. Und bei praktischen Fragen merke ich immer, dass sich weitere 1000 Fragen eröffnen).

yellow · 14. Juli 2023 um 13:16

Nein onchain habe ich da mit der WalletOfSatoshi auch nichts gemacht in der Zeit. Habe auch schon daran gedacht. Aber meine WalletOfSatoshi kann ja auch in keinem Zusammenhang dazu stehen, dass ich mit meinem Lightning Node einen Channel zum WalletOfSatoshi Node aufmache.

Ja, genau deshalb finde ich das auch so seltsam… wäre ein sonderbarer Diebstahl. Und ich war auch nicht unvorsichtig mit meinen Keys.

Es schaut schon so aus, dass die Gegenseite einen force close einleiten könnte. Hätte ich mir auch so gedacht, weil wenn dann müsste eine Ausnahmeregel bestehen „die Gegenseite darf nur einen force close machen, wenn auf ihrer Seite Guthaben liegt“ Weil dann muss das ja auch die Gegenseite können, sollte der andere Node nicht mehr erreichbar sein.

Zitat von docs.lightning.engineering

Either Alice or Bob may not be available, or may for other reasons be unable or unwilling to sign their closure transaction. In this case, the party aiming to close the channel will have to publish their commitment transaction. This will result in a non-cooperative close, also called a force close.

These commitment transactions are asymmetrical, as they spend the balance of the peer initiating the force close to an arbitration contract, while the funds of the other party are sent to their wallet immediately. This allows the peer that is not initiating the force closure to contest it.

Demnach hätten die Funds aber direkt zu mir zurückgehen sollen. Aber in dem Falle vielleicht nicht, weil der Channel ja noch im Mempool war?

Was ich überhaupt nicht verstehe ist, wenn das nicht ich war: Wie konnten meine UTXOs bewegt werden? Sobald der Channel eröffnet ist, verstehe ich es. Aber da die Transaktion noch im Mempool lag, waren die UTXOs ja noch bei mir meiner Ansicht nach? Und wie du sagst… wenn das dieser „arbitration contract“ sein sollte, ist sehr sonderbar, dass das eine Adresse ist, auf der schon Guthaben lag? Da komme ich nicht mit…

Ich habe auch nochmal alles durch getestet, was ich für den double spend probiert habe. An keiner Stelle wurde eine P2SH Adresse generiert.

yellow · 14. Juli 2023 um 13:22

Ah und dass das ein RBF zu meiner ursprünglichen Channel Transaktion ist passt auch nicht dazu dass das ein forced close ist.

yellow · 14. Juli 2023 um 13:32

Wobei… Vielleicht stellt nur der Explorer das als RBF dar, weil er die RBF fähige Transaktion im Mempool gesehen hat.

Wenn das nun wirklich mein force close ist, den ich ja tatsächlich probiert habe (wenn auch einen Tag vorher), dann wäre ich der Initiator und dann würde mein Guthaben festhängen laut den Regeln.

Erklärt nur immer noch nicht, warum das eine Adresse mit Guthaben ist.

ViresInNumeris · 14. Juli 2023 um 14:33

Sorry, ich kenne WoS kaum. Also das ist ein Custodial Service und Du hast einen Kanal dazu aufgemacht, zu deren Node (das ist ja das eig. Problem), oder? Und dass Du von Deiner Wallet (of S.) also Deiner App aus, ein Tx machst um die UTXO weiterzuschieben sollte keinen Zusammenhang haben? War das so gemeint?

Verstehe ich nicht ganz… ein Channel kann ja nicht „im Mempool“ sein, sondern er existiert faktisch erst, wenn die Opening Tx bestätigt wurde.

Hmm, ich auch dann nicht. Du sagst ja, dass der Input Deiner oben verlinkten Tx quasi Dein UTXO ist, dass Du eigentlich für das Öffnen des Channels benutzen wolltest, oder?
WENN ja und WENN der Channel erfolgreich geöffnet worden wäre UND dann (von Dir oder der Gegenpartei) Force Closed worder wäre, dann würden wir ja 2 tx sehen, und nicht bloss eine. Nämlich eben die Open und die Force Close. Wir sehen aber nur eine.

Interessant ist ja auch, dass Deine Tx eine „Sperrzeit ‎798.550“ hat!! Meines Wissens nach benutzt LN zum Channel Management keine absoluten Time Locks, sondern nur relative. Aber das ist nur Theorie, vielleicht sieht die Praxis anders aus?!

Ja genau. Meines Wissens aber eben mir relativem Time Lock.

Nein, das ist mMn eines der grössten Rätsel in diesem Fall. Und dann noch eine P2SH?!

yellow · 14. Juli 2023 um 15:16

Exakt. 100% Custodial und keinerlei Verbindung zu meinem Node. Ich habe sie nur verwendet, um incoming liquidity zu bekommen. Das ist angenehm… Du schickst von deinem Lightning Node zur WoS und dann kannst du es von dort wieder onchain mit einer Fee von 0,5% zu deinem Lightning Node zurück schicken. Aber das hat keinerlei direkten Zusammenhang mit meinem Lightning Node. Das war auch der erste Channel, den ich zu WoS aufmachen wollte.

Ja richtig. Ich nenne das so, wenn die Transaktion, die den Channel eröffnet noch nicht onchain ist. Aber genau das ist auch der Punkt, der technisch schwierig wird. Ich habe quasi versucht einen Channel zu force closen, der noch gar nicht existierte wie du sagst, aber durchaus schon im Mempool sichtbar war. Ab da fehlt mir auch das Wissen, wie das der Lightning Node behandelt. Vielleicht ist es gar nicht genau definiert… die Bitcoin Wallets haben da ja auch unterschiedliche Zugänge dazu.

Genau. Beide UTXOs dieser Transaktion waren meine und die hatte ich in der ursprünglichen Transaktion zum Channel öffnen verwendet. Diese blieb im Mempool stecken und wurde dann von dieser 996c1, die jetzt auf der Chain ist überschrieben.

Sehe ich auch so. Sollte das die force close sein, müsste das durch gegangen sein ohne, dass die open jemals auf die Chain gekommen ist. Dass 996c1 die ursprüngliche laut mempool Explorer RBF ersetzt könnte auch Auslegungssache vom explorer sein, denke ich.

Ich habe parallel auch mal dem WoS Support geschrieben. Habe wenig Hoffnung, aber vielleicht kommt es ja bis in die Technik, wo jemand eine Erklärung hat.

Ich fürchte da ist so ein Ausnahmefall passiert, dass es wohl einen Lightning Entwickler bräuchte, um Licht in die Sache zu bekommen. Kenne leider keinen. Werde wohl heute noch probieren ein Issue auf core lightning github aufzumachen.

yellow · 14. Juli 2023 um 15:23

Hier habe ich noch einen Artikel, wo erklärt wird, dass für den Initiator um die 2 Wochen das Guthaben gelockt bleibt:

https://www.reddit.com/r/lightningnetwork/comments/zpoamf/i_forceclosed_a_channel_and_want_to_find_out_how/

Von dem her hätte ich noch eine Chance, wenn das mein force close war.

Ich zweifle aber wegen der komischen Adresse wo funds drauf sind und in dem Beispiel aus reddit, steht auf mempool auch dabei, dass das ein Channel Close ist. P2SH ist es auch keine…

BR_Robin · 14. Juli 2023 um 16:58

Hallo, schade, dass du deine coins suchen musst. Ich hoffe du wirst sie wiederbekommen!

Ich habe den Thread gelesen und habe dazu ein paar Gedanken:

Ein Lightning Channel ist meiner Meinung nach immer eine bc1q Adresse (bald auch bc1p). Ich spreche zwar erstmal nur für LND, denke aber das Core Lightning das auch so handhabt.

Du hast einen Channel aufmachen wollen mit deiner ersten tx. Diese wurde aber ja definitiv nicht bestätigt, sondern das Geld wurde später an die 3… (P2SH) Adresse transferiert, welche sehr wahrscheinlich eben kein Lightning Channel ist.

Wenn dem so ist, dann ist WoS quasi aus der Sache raus. Den Channel zu WoS gibt es nicht und gab es auch nie. Es gab definitiv keinen Force Close. Dieser kann nämlich nur „nach“ der opening tx kommen und nicht diese einfach ersetzen. Deine opening tx hätte dann also erstmal bestätigt werden müssen und das wurde sie nicht.

Die Replacement tx ist kein klassisches RBF. Bei RBF kann man wie der Name suggeriert ja nur die fee ändern, aber nicht den Empfänger. Ich vermute, dass die originale tx einfach aus dem Mempool von einigen nodes gelöscht wurde und ein Double Spent durchgeführt wurde.

Jetzt ist die große Frage: Wer hat das getan?

Du meintest ja, du hast deine priv keys in ein anderes wallet importiert. Ich hätte vermutet, dass du den double spend selbst ausgeführt hast und das Geld eben nicht in den Channel sondern auf eine andere Adresse von dir geflossen ist.
Bist du sicher, dass diese nicht dir gehört?
Auch wenn die Channels mit bc1q beginnen, kann man für seine onchain funds auch P2SH Adressen verwenden.

Vielleicht wurdest du auch gehackt? Fehlt dir sonst noch Geld auf deiner Node?

Noch ein Kommentar zu den Timelocks.
Timelocks der LN Channels sind tatsächlich relativ und werden auch nur beim Force Close verwendet (und nicht besonders opening tx).

Es gibt aber wallets (wie z.B. electrum), welche in jede tx ein absolutes Timelock setzen (auf den Wert aktuelle Blockheight+1). Vllt ist das bei Core Lightning ja auch so.

Deine erste tx hatte ein niedriges timelock, eventuell weil es ja 4 Tage her war.
Die zweite tx hatte ein höheres, vllt weil die Transaktion zu der Blockheight erstellt wurde (aber vllt später erst gebroadcasted wurde?)

Du kannst ja mal gucken welche Zeit Block 798.550 hat und ob du da gerade irgendwas gemacht hast.

ViresInNumeris · 17. Juli 2023 um 09:31

Wie konnst Du darauf, dass LN Adressen immer bc1q sind?
Ich dachte, dass LN Tx eben P2SH sind. Leider habe ich z.B. hier

auch nichts dazu finden können.
Kann gut sein, dass ich mich irre, bin nur irgendwie zu doof, eine LN funding Tx zu finden.

bc1p ist klar (Taproot)

BR_Robin · 17. Juli 2023 um 17:13

Die onchain funds deiner Lightning Node können auf verschiedenen Adresstypen sein, aber LN Channels (also die Multisig Adresse, die von beiden Channel Partnern kontrolliert wird), müsste immer bc1q sein (oder bald bc1q).

Mit folgender Begründung:
Bevor es Segwit gab, konnte man die tx id einer Transaktion ändern ohne die Signatur ändern zu müssen. Dies nannte man Transaction Malleability und wurde durch Segwit gefixt. Dies war notwendig um im LN presigned tx auszutauschen, bevor der Channel offen ist.

Alle LN Channels müssen daher Segwit Adressen sein. Es gibt zwar auch nested segwit Adressen, welche mit einer 3 beginnen, aber diese gibt es eigentlich nur um backwards compatible mit älteren wallets zu sein.
Es gäbe keinen Grund diese im LN zu verwenden, da diese auch genau so native segwit Adressen (bc1q) nutzen können.
Ein Beweis, dass es keine 3… Channels gibt, ist es nicht, aber ich habe bisher nie eine gesehen.

Hier ist einer meiner Channel Opening Transactions. Alle channels von mir sind auf einer bc1q Adresse. Kann mir kaum vorstellen, dass es bei CLN anders ist.

yellow · 18. Juli 2023 um 09:39

Vielen Dank für das Mitdenken Robin. Mega wie engagiert die Leute hier sind.

Ich habe mittlerweile eine Antwort vom WalletOfSatoshi Support erhalten. Sehr ausführlich und sie haben auch versucht das weiter zu analysieren, obwohl sie definitiv nichts damit zu tun haben, wie wir schon festgestellt haben. Tolle Firma.

Genau das meinte der WoS Support auch. Es ist definitiv kein Lightning Channel. Sie meinten zusätzlich:

It’s not an RBF-flagged transaction, so it can’t have been used in that way to replace the channel opening transaction.

und wie du sagst:

Also the address it’s paying to is a P2SH (3-address), which is not a Lightning-compatible address. So if that transaction was initiated on your Lightning node, it’s sending the payment off your node to a regular BTC wallet. It can’t be a channel related transaction.

Danke für deine Info mit den Time locks und den guten Tipp. Habe ich gemacht. Da war ich gerade dabei die Keys auf meinem Bitcoin Node zu importieren, was auch die einzige Stelle ist, wo ich mir einen hack Angriff vorstellen könnte. Ich mache noch einmal eine gesonderte Antwort zum jetzigen Stand.

yellow · 3. August 2023 um 09:40

Vielleicht auch für Andere Interessant wie der Stand jetzt ist.

Ich denke nun dürfte ziemlich klar sein, dass es ein Diebstahl war. Die Guthaben wurden nun runter gezogen von der Adresse 32GxVZ9RyFJoKHAZRQGcDJDsLzUHW3vu63. Natürlich wäre ich extrem dankbar, wenn irgend jemand weiß, ob und wie man über die Zieladresse bc1qvk77n32du4xvruukkahu0anc2qtu936s4tl9s7 und bc1q8h7grawl0rmpavgnzp9s2x242675y55ygp40uu etwas herausfinden kann. Wenn man die Adressen anschaut, geht da richtig krass was ab. Da finden >10 BTC Transaktionen statt. Wenn das alles geklaut ist, ist da ordentlich was am laufen.

Ich habe auf meinem Server auch einiges an Analyse laufen. eine IP, die mich in der Zeit penetrant gescannt hat, war 77.72.83.88. Sie probiert es noch immer.

Ich bin zuvor schon noch einmal alles durch gegangen. Nach unseren ganzen Überlegungen gab es ja nur wenige Chancen:

Ich habe an eine falsche Adresse gesendet. Zum Beispiel aus Versehen keine von mir generiert und an eine aus einem Tutorial geschickt. Das konnte ich aber nachprüfen, weil ich auf der Commandline noch die ganze History hatte. Auch bin ich die Unterlagen noch einmal durch gegangen, die ich verwendet habe und da war diese Adresse nirgends zu finden.
Einbruch in meinen Server. Da ich im Aufsetzen von Debian Servern nicht wenig Ahnung habe, sehe ich das als wirklich sehr unwahrscheinlich an. Bis auf den BTC, Lightning und BTC Pay Server läuft darauf nichts. Zugang ist nur über einen nicht standard Port per SSH mit Key Authentifizierung möglich. Es hat auch nichts auf einen Einbruch hingedeutet.
Kompromitierte Software. Das ist die größte Schwachstelle. Da habe ich einiges verwendet. Leider im Stress dann sogar recht sorglos.

Zu 3. die verwendete Software, die Zugriff auf meinen Key gehabt hat:

Core Lightning - schließe aus, dass da was ist
BTC Pay Server - kann ich nicht glauben
Ride The Lightning - da wird es schon heikler, aber glaube ich auch nicht
c-lightning-rest - Siehe Ride The Lightning
clightning-dumpkeys - das ist für mich die heikelste Stelle und das war wirklich dumm von mir die Software ungeprüft zu verwenden. Ich hatte da Stress an die Keys zu kommen, weil ich den Kanal schon auf „vergessen“ gesetzt habe und wollte es daher nicht selbst machen. Sobald ich etwas Zeit habe, werde ich wohl den Code zu der Zeit nochmal prüfen.

Wie gesagt wäre 5. das Einzige, was ich mir so wirklich vorstellen kann. Wie immer bin ich um weitere Ideen froh. Dass ich jemals wieder an dieses Geld komme, glaube ich nicht wirklich. Aber ich bin jetzt auch extrem unsicher in Bezug auf den Lightning Node. Wundert mich eh, dass da noch nicht alles abgezogen wurde. Vermutlich ist das Beste den komplett zu schließen? Neue Keys kann ich ja nicht machen oder?

ViresInNumeris · 3. August 2023 um 13:05

Oh…
Irgendwie habe ich Deine Antwort total verpasst. Jedenfalls vielen Dank dafür!
Dass es Segwit Adressen sein müssen klingt natürlich logisch mit dieser Begründung.
Ich glaube ich habe irgendwie noch einen Knoten im Kopf, was LN Tx angeht.
Werde mir diese von Dir gepostete Opening Tx mal in Ruhe ansehen und darüber meditieren

Ja, allerdings! Auch wenn es mir sehr leid tut, falls Dein Geld wirklich verloren ist: Der Grund würde mich sehr interessieren. Ich verstehe auch immer noch nicht, warum ein Dieb eine P2SH Adresse verwenden würde.

Soapp · 4. August 2023 um 08:29

Kannst du einem Laien erklären, warum das merkwürdig ist ? VG

ViresInNumeris · 4. August 2023 um 17:21

Ok, habe meine Meditation nun abgeschlossen. Bitte vergesst, was ich über P2SH und LN gesagt habe. @BR_Robin hatte natürlich recht. Irgendwie hatte ich die bescheuerte Idee, jede Tx mit einem „komplizierteren“ Script (also quasi alles andere als P2PKH) und damit z.B. die HTLC für LN müsste mittels P2SH gemacht werden. Das stimmt natürlich nicht. Zudem: die gepostete LN Opening Tx ist ja eine „normale“ Multisig Tx. Soweit ich das jetzt zu verstehen glaube steht normalerweise beim LN nie eine HTLC in der Blockchain. Nur bei Forced Close, aber nicht bei collaborative close.

Also ich finde es nur merkwürdig. Dies würde meiner Ansicht nach bedeuten, dass es „kompliziertere Regeln“ gibt, wann und wie die gestohlenen BTC auf der 3… (P2SH) Adresse ausgegeben werden können. Und da sehe ich nicht wirklich einen Sinn dahinter. Ich würde erwarten, dass man gestohlene Coins ev. zunächst auf eine „normale“ Adresse verschiebt und dann irgendwie durch Coin Mixer zu „waschen“ versucht.

Wirklich vernünftig helfen kann ich leider nicht. Aber Du kast ja bestimmt auch gesehen, dass bei der von Dir verlinkten Adresse 32Gx… bei den beiden ersten grossen Tx mit den viele Inputs immer diese 2 Adressen als Input verwendet werden: 1. eben die 32Gx und dann die Legacy mempool - Bitcoin Explorer
Für beide Adressen gilt aber, dass die mehrfach als Input und output verwendet werden, insb. auch dass in einer Tx mehrere Inputs verschiedener Adressen auf die 32Gx bzw. 1Em gesendet werden.
Irgendwie ist das für mich nicht ganz nachvollziehbar. Das würde ja heissen, dass ein Dieb mehrere Opfer mit verschiedenen Adressen quasi mit einer einzigen Tx bestiehlt? Das fände ich etwas seltsam, da ich erwarten würde, dass er sobald er den PrivKey eines Opfers hat diesen sofort ausnutzt.
Aber das sind nur vage Vermutungen. Wenn z.B: der Dieb natürlich einen Seed stiehlt, dann kann das schon so sein.

Edit:
Habe mal versucht, das Script bei der 32Gx Adresse zu finden / verstehen, bin aber nur so weit gekommen.

Leider verstehe ich aber nicht, wie ich dieses Script
16001493430f84e52d0845251301c64c2bbbeb8c85a0fb
dekodieren kann.
Bzw. verstehe ich noch nicht mal die Logik dahinter. Bei P2SH müsste ich doch ein Script vorweisen, dass gehasht eben den P2SH Hash ergibt und dann noch das entsprechende Unlock script? Das sehe ich aber auch nicht im Screenshot.