Address Clustering gruppiert Bitcoin-Adressen oder Ausgabeskripte (codierte Regeln für das Ausgeben von Bitcoin) nach vermuteter gemeinsamer Kontrolle. Eine solche Gruppe heißt Cluster. Sie entsteht im Analysewerkzeug, nicht als Eigentümerliste in der Blockchain (der öffentlichen Historie bestätigter Transaktionen). Die Zuordnung zu einer Person oder einem Dienst braucht weitere Belege.
Anna verwendet neue Adressen für verschiedene Eingänge und bezahlt später mit ihrer Wallet in einem Geschäft. Eine Wallet ist eine Anwendung oder ein Gerät zum Empfangen und Senden von Bitcoin. Ein Analyst sieht Geldbewegungen, muss aber zwei Fragen trennen: Welche Mittel wurden ausgegeben, und welche Adressen könnten derselben Kontrolle unterliegen? Die Zahlung ans Geschäft beantwortet die erste Frage. Allein deshalb gehören Anna und das Geschäft nicht in dieselbe Gruppe. Address Clustering sucht andere Hinweise, etwa gemeinsam ausgegebene Eingänge. Ein Zahlungsdiagramm zeigt tatsächliche Transaktionsverbindungen; farbige Gruppen ergänzen bereits eine Interpretation. Diese Unterscheidung ist beim Lesen solcher Karten entscheidend. [1] [5]
Frühere Eingänge liegen als UTXO vor, noch nicht ausgegebene Transaktionsausgänge. Jeder solche Ausgang hält einen Betrag und die Bedingungen fest, unter denen er ausgegeben werden darf. Ein neuer Eingang verweist auf einen bestimmten früheren Ausgang, nicht auf ein allgemeines Feld „Absenderadresse“. Das Werkzeug ermittelt dessen ursprünglichen scriptPubKey, also die Bedingungen für die Ausgabe. Eine Adresse stellt diese Bedingungen bei unterstützten Typen bequem dar; nicht jedes Skript besitzt eine übliche Adresse. Eine sorgfältige Erklärung unterscheidet deshalb zwischen Adressen und Skripten und benennt Netzwerk sowie Blockbereich. Ein Block bündelt Transaktionen, die in die gemeinsame Historie aufgenommen werden. Eine technische Kennung wird dadurch noch nicht zur Identität eines Menschen. [4] [6]
Die Common-Input Ownership Heuristic vermutet gemeinsame Kontrolle über mehrere Eingänge einer Transaktion. Die Erkennung von change ist ein eigener Schritt: Gesucht wird der Ausgang, der den nach Zahlung und Gebühr übrigen Betrag zurückgibt. Ein richtiger Schluss verbindet Annas neue Wechselgeldadresse mit früheren Eingängen. Wird dagegen die Zahlung ans Geschäft für change gehalten, werden fremde Mittel zugeordnet. Zwei Ausgänge allein verraten ihre Rollen nicht. Sie können zwei Empfänger oder Überweisungen zwischen eigenen Wallets darstellen. Auch eine zuvor unbekannte Adresse beweist nicht, dass sie dem Zahlenden gehört. [1] [3]
Gerundete Beträge, Skripttypen oder wiederverwendete Adressen liefern Hinweise, keine unveränderlichen Regeln. Ein Wallet-Update kann Transaktionen anders erstellen und ein älteres Modell fehlleiten. CoinJoin ermöglicht gemeinsame Transaktionen mehrerer Beteiligter; bei Payjoin nach BIP 78 kann der Empfänger eigene Eingänge hinzufügen. Zusammenarbeit muss keine gleich hohen Ausgänge erzeugen. Historisch gemessene Genauigkeit lässt sich daher ohne neue Prüfung nicht für heutige Transaktionen versprechen. Ebenso wichtig ist, für welche Fälle das Verfahren keine Vorhersage liefert. [2] [3]
Zwei bislang getrennte Adressgruppen können durch eine einzige falsche Verbindung zusammenfallen. Der Fehler betrifft dann alle Mitglieder. Zum effizienten Zusammenführen verwenden Programme oft union-find, eine Datenstruktur für verbundene Gruppen. Ihre übliche Form kann eine alte Verbindung nicht entfernen und das Ergebnis automatisch korrekt aufteilen. Für überprüfbare Analysen sollten deshalb Transaktionen, einzelne Verbindungen und Regelversionen erhalten bleiben, nicht nur die fertige Adressliste. Das ist eine praktische Folgerung aus der beschriebenen Fehlerausbreitung: Eine Korrektur kann eine Neuberechnung verlangen, statt nur eine Umbenennung der Gruppe. [2]
Malte Möser und Arvind Narayanan untersuchen cluster collapse, das fälschliche Zusammenfallen vieler Gruppen zu einer großen. Ihr constrained union-find lehnt Verbindungen zwischen Gruppen ab, die durch einen vermuteten Zahlungsausgang getrennt sind. Bei Anna kann die Vermutung „sie bezahlt das Geschäft“ also eine spätere Zusammenführung verhindern. Doch auch diese Sicherung kennt die Wahrheit nicht unabhängig: Sie hängt von der Zahlungserkennung ab und kann richtige Verbindungen ablehnen. Weniger Zusammenführungen ergeben daher nicht automatisch ein vollständiges oder fehlerfreies Bild der Eigentümer. [2]
Eine Adresse nach einer Börse zu benennen und diese Kennzeichnung auf einen ganzen Cluster zu übertragen sind getrennte Schritte. Ein Label braucht Herkunft, Gültigkeitszeitraum und einen nachvollziehbaren Verbreitungsweg. Eine börsenkontrollierte Gruppe kann zudem viele Kunden bedienen. Die Modellprüfung sollte nicht allein auf Daten beruhen, die dieselbe Annahme erzeugt hat. Falsche Zusammenführungen, übersehene Beziehungen und Stichprobenabdeckung müssen getrennt bewertet werden. Viele beschriftete Adressen garantieren für sich genommen keine richtigen Zuordnungen. [1] [2]
Anna kann Mittel zwischen zwei eigenen Wallets verschieben. Erkennt das Modell ihre Verbindung nicht, zählt es den Vorgang möglicherweise als Zahlung zwischen verschiedenen Beteiligten. Verbesserte Gruppen können ihn als eigenen Transfer, self-churn, erkennen. Das geschätzte Zahlungsvolumen sinkt dann ohne Änderung der Blockchain-Historie. Ebenso besteht der Saldo eines Clusters aus seinen noch nicht ausgegebenen UTXO an einem bestimmten Block; die Summe sämtlicher früherer Eingänge enthielte bereits ausgegebenes Geld. Vergleichen Sie bei Grafiken deshalb neben dem Datum auch Modellversion, Labels und Datenstichtag. [1] [2]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Common-Input Ownership Heuristic, Chain Surveillance, Change Address, CoinJoin, Payjoin, UTXO. Auf diesen Eintrag verweisen außerdem Pseudonymität, Chain Surveillance, Common-Input Ownership Heuristic, Transaction Labeling.