Nodesignal-Techboost - E251 - NPM Chaos, Coinjoin Analysis & Open Source Vibes

Danke!

Und es heißt “Common Input Ownership Heuristic” 🤓

Bzgl. Joinmarket. Alice will Bob 100k Sats schicken Alice nutzt Joinmarket mit der Annahme, dass ihr Anonymitäts-Set dadurch größer wird Alice ist also nun taker in einer Joinmarket TX und setzt ihren Output auf Bobs Adresse Bob kann aber rausfinden welcher Input zu Alice gehört da man relativ leicht zurückrechnen kann wer der taker ist Generelle plausible Annahme ist: Sender = Taker, da der taker auch die Outputs amounts festlegt Weiter wird das Problem im verlinkten Bitcoin Talk Beitrag aufgerollt und ist auch hilfreich, um das Problem besser zu verstehen. Generell, wenn Alice ihr Anonymitäts-Set vergrößern will, und mehrere Joinmarket Transaktionen anstößt - also als Taker auftritt - besteht ein ähnliches Problem wie oben beschrieben. Sogar eine dritte Partei die nicht Teil der Transaktion war, kann ähnlich wie Bob den Taker identifizieren. Zusätzliche Annahmen: Taker ist tendenziell (deutlich) öfter Taker als Maker Maker ist tendenziell (deutlich) öfter Maker als Taker Maker nutzt Output aus TX_1 als Input in TX_2 (wieder als Maker, siehe 2.) Wenn ein Maker in TX_2 als Maker erkannt wird, ist er auch in TX_1 als Maker identifiziert. Maker werden, anders als der Taker, als eine Gruppe betrachtet. Also ein Maker kann unter Makern nicht identifiziert werden. Da ist das Problem nicht so schlimm. Beim Taker ist das ein Problem, da gibt ja nur einen. Dadurch kann dann die Transaktionskette mit recht großer Wahrscheinlichkeit nachvollzogen werden. Also die coins von Alice können (wenn sie konsequent Taker ist) von TX_1 -> TX_2 -> TX_N mitverfolgt werden. Sein Punkt ist schlussendlich, dass NUR die Maker ihr Anonymitäts-Set vergrößern und Taker NICHT. Es sind jedoch die Taker, die alles bezahlen. Sowohl die Mining fees und obendrauf noch die Maker für ihren “Dienst” bezahlen.

GM