Setor

Super folge!

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.

Sehr spannende Folge!

Super Folge! Hier ist noch ein GO wrapper den ich für eine schnellere Version für BlindBit (Silent Payments indexing) nutze. https://github.com/setavenger/go-bitcoinkernel

Nostr DMs sind prinzipiell immer verschlüsselt (auch NIP-04). Die erste Idee der DMs (NIP-04) hat, wie richtig beschrieben, signifikante Privatsphäre Probleme. Jeder kann sehr einfach sehen wer mit wem kommuniziert. Aber wichtig man kann nicht sehen WAS kommuniziert wurde. Wenn wirklich jemand NIP-04 lesen kann, würde das eigentlich nur eine von zwei Sachen sein: - private keys wurden geleaked - secp256k1 cryptography ist gebrochen (wird auch in Bitcoin genutzt), ich denke mal das hätten wir gemerkt Ich würde mal schätzen, dass die Nuss einfach vom Sender selbst eingelöst wurde oder es keine DMs waren sondern ein wirklich öffentlicher Kanal.