Die Heuristik des gemeinsamen Input-Eigentums

Die Heuristik des gemeinsamen Input-Eigentums ist die älteste und am häufigsten verwendete Clustering-Regel in UTXO-Blockchains. Sie erzeugt die meisten Verknüpfungen in jedem Bitcoin-Cluster, liegt normalerweise richtig und führt, wenn sie falschliegt, zu Fehlern, durch die ganze Wallets zusammengeführt werden. Analystinnen und Analysten müssen sowohl wissen, warum sie funktioniert, als auch genau, bei welchen Transaktionen sie versagt.

Die Logik

Um ein UTXO auszugeben, muss eine Transaktion ein gültiges Entsperrskript oder einen Witness für diesen Output bereitstellen. In der Praxis bedeutet das eine Signatur des Schlüssels, der diesen Output kontrolliert. Eine Transaktion mit drei Inputs benötigt also Signaturen für drei Coins. Bei gewöhnlicher Nutzung erstellt eine Wallet eine Zahlung, indem sie Coins aus ihrem eigenen Guthaben auswählt und alle signiert. Wenn also mehrere Adressen als Inputs derselben Transaktion auftreten, ist die wahrscheinlichste Erklärung, dass eine Wallet und damit eine Kontrollinstanz die Schlüssel für alle diese Adressen hält.

Die Idee ist so alt wie Bitcoin. Im Abschnitt zum Datenschutz des Whitepapers von 2008 wird bereits davor gewarnt, dass Transaktionen mit mehreren Inputs „zwangsläufig offenbaren, dass ihre Inputs demselben Eigentümer gehörten“. Reid und Harrigan (2011, „Eine Analyse der Anonymität im Bitcoin-System“) verwendeten die Regel, um ein Nutzernetzwerk zu erstellen, und Meiklejohn et al. (2013, „Eine Handvoll Bitcoins“) formulierten sie als ihre Heuristik 1: Wenn zwei oder mehr Adressen Inputs derselben Transaktion sind, werden sie von demselben Nutzer kontrolliert. Die Regel wird auch Heuristik des gemeinsamen Input-Eigentums (CIOH) oder Mehrfachinput-Heuristik genannt.

Ein durchgearbeitetes Beispiel

Hier ist eine dekodierte Transaktion, vereinfacht auf die für das Clustering relevanten Felder (Kennungen gekürzt):

{
  "txid": "7c1e…40ab",
  "vin": [
    {"prevout": "a91f…03:1", "address": "bc1q…k3f7", "value_btc": 0.0400},
    {"prevout": "e2c8…7d:0", "address": "bc1q…m9a2", "value_btc": 0.0250},
    {"prevout": "51b0…e9:4", "address": "bc1q…x0d1", "value_btc": 0.0180}
  ],
  "vout": [
    {"n": 0, "address": "bc1q…p2w8", "value_btc": 0.0700},
    {"n": 1, "address": "bc1q…r4t6", "value_btc": 0.0128}
  ]
}

Die drei Inputs ergeben zusammen 0,0830 BTC; die Outputs ergeben zusammen 0,0828 BTC, die Gebühr beträgt also 0,0002 BTC (20.000 Satoshis). Die Heuristik des gemeinsamen Input-Eigentums verknüpft bc1q…k3f7, bc1q…m9a2 und bc1q…x0d1. Über die Outputs sagt sie nichts aus: Ob bc1q…r4t6 Wechselgeld ist, das derselben Wallet gehört, ist eine separate und deutlich schwächere Schlussfolgerung, die in der Lektion Heuristiken zur Wechselgelderkennung behandelt wird.

Wenn bc1q…m9a2 bereits zu einem Cluster mit 2.000 Adressen gehörte und bc1q…x0d1 zu einem Cluster mit 300 Adressen, führt diese eine Transaktion sie zu einem Cluster mit 2.301 Adressen zusammen. Das ist die Hebelwirkung der Regel – und zugleich ihre Gefahr.

Am stärksten ist die Regel bei Diensten. Verwahrende Börsen und Zahlungsdienstleister konsolidieren regelmäßig viele kleine Einzahlungen zu einem Output. Bei einer solchen Fan-in-Transaktion können Hunderte von Einzahlungsadressen auf einmal ausgegeben werden. Jeder Sweep verknüpft all diese Adressen mit der Wallet des Dienstes. Deshalb wachsen Service-Cluster auf Millionen von Adressen an und ist oft schon eine einzige verifizierte Einzahlung ausreichend, um sie zu kennzeichnen (siehe die Lektion Attribution und Kennzeichnung). Konsolidierungen durch gewöhnliche Nutzer funktionieren genauso, allerdings in kleinerem Maßstab: Eine Wallet, die ein Dutzend älterer Coins zusammenführt, um künftige Gebühren zu sparen, offenbart damit, dass sie alle diese Coins gehalten hat. Beide Fälle beruhen auf derselben Annahme – dass nur eine Partei signiert hat – und beide sind korrekt, solange niemand anderes einen Input beigesteuert hat.

Wie gut die Regel funktioniert

Die Belege für die Genauigkeit sind begrenzt, aber einheitlich. Meiklejohn et al. wendeten die Regel 2013 auf die gesamte Blockchain an und reduzierten 12.056.684 öffentliche Schlüssel auf etwa 5,58 Millionen Cluster. Nick (2015, eine Masterarbeit zur datengestützten Deanonymisierung in Bitcoin) gewann seltene Ground-Truth-Daten aus einem Datenschutzleck in den Bloom-Filtern, die von Light-Wallets verwendet wurden und die Adressgruppen echter Wallets offenlegten. Die Heuristik des gemeinsamen Input-Eigentums identifizierte mehr als 69 % der Adressen dieser Wallets. Beachten Sie, was diese Kennzahl erfasst: Recall (wie viel von jeder Wallet gefunden wurde), nicht Präzision (wie viele Verknüpfungen korrekt waren). Die Regel gilt bei gewöhnlichen Transaktionen generell als präzise, doch das beruht auf Annahmen zum Verhalten von Wallets, und die folgenden Transaktionen verletzen diese Annahmen.

Wo die Annahme versagt

CoinJoin. Mehrere Nutzer einigen sich auf eine gemeinsame Transaktion. Jeder steuert Inputs bei und signiert nur seine eigenen. Die Outputs enthalten typischerweise mehrere Beträge gleicher Höhe, sodass niemand erkennen kann, welcher Output zu wem gehört. Die Anwendung der Heuristik des gemeinsamen Input-Eigentums führt die Wallets aller Beteiligten zusammen – genau die falsche Verknüpfung, die CoinJoin erzeugen soll. In der Lektion Mixer, CoinJoin und Verschleierung in Graphen erfahren Sie, wie diese Transaktionen in einem Graphen aussehen.

PayJoin. Bei einem PayJoin (BIP 78) fügt der Empfänger einer Zahlung einen eigenen Input zur Transaktion des Senders hinzu. Das Ergebnis sieht wie eine gewöhnliche Zahlung mit zwei Inputs aus. Daher verknüpft die Regel die Coins des Senders mit denen des Empfängers, und auch der scheinbare Zahlungsbetrag wird verfälscht. Ein gut konstruierter PayJoin lässt sich nicht zuverlässig von einer normalen Transaktion unterscheiden. Seine Existenz setzt daher der Sicherheit jeder einzelnen Verknüpfung eine Obergrenze. Die Verbreitung von PayJoin war gering, was den Gesamtschaden begrenzt, ihn in einem konkreten Fall aber nicht ausschließt.

Andere Transaktionen mit mehreren Parteien. Jedes Protokoll, bei dem zwei oder mehr Parteien Inputs beisteuern, lässt die Regel versagen: gemeinsam finanzierte Eröffnungen von Lightning-Kanälen, manche Swap- und Batching-Protokolle sowie Transaktionen, die mit SIGHASH_ANYONECANPAY signiert werden. Damit können andere nach der ersten Signatur Inputs hinzufügen; verwendet wird es beispielsweise bei Crowdfunding-Verträgen.

Gemeinsame Kontrolle. Eine Multisig-Adresse, die mehreren Personen gemeinsam gehört, hat im Sinne des Skripts einen „Eigentümer“, in Wirklichkeit aber mehrere Personen. Die korrekte Entität ist die gemeinsame Vereinbarung, nicht eine einzelne signierende Person.

Verwahrung und Schlüsselimport. Ein Verwahrungsdienst gibt Kundeneinzahlungen gemeinsam aus. Sein Cluster ist daher für den Dienst korrekt, sagt aber nichts über die Kunden aus. Wallets, mit denen Nutzer private Schlüssel importieren oder Coins von anderen übernehmen können (Paper-Wallets, Geschenkkarten), können Coins verknüpfen, die verschiedenen Eigentümern gehörten. Der in der Lektion Was Clustering ist und warum es wichtig ist erwähnte Mt.-Gox-Cluster ist der bekannteste Fall.

Schutzmaßnahmen

Fünf Vorgehensweisen helfen, die Regel sinnvoll einzusetzen.

1. Wahrscheinliche CoinJoins vor dem Verknüpfen herausfiltern. Der einfachste Test sucht nach mehreren Outputs mit exakt gleichem Wert.

-- Mögliche CoinJoins markieren, damit ihre Inputs nicht verknüpft werden
WITH same_value AS (
  SELECT tx_id, value_sat, COUNT(*) AS n_equal
  FROM outputs
  GROUP BY tx_id, value_sat
),
shape AS (
  SELECT t.tx_id, t.input_count, MAX(s.n_equal) AS max_equal_outputs
  FROM transactions t
  JOIN same_value s ON s.tx_id = t.tx_id
  GROUP BY t.tx_id, t.input_count
)
SELECT tx_id
FROM shape
WHERE input_count >= 2
  AND max_equal_outputs >= 3;  -- diesen Schwellenwert anpassen und dokumentieren

Die Abfrage zählt für jede Transaktion, wie viele Outputs denselben Wert haben, behält die größte solche Gruppe bei und markiert Transaktionen mit mehreren Inputs, bei denen mindestens drei Outputs identisch sind. Die Festlegung des Schwellenwerts ist eine Ermessensentscheidung. Dabei werden auch einige gebündelte Auszahlungen von Börsen erfasst, bei denen zufällig gleiche Beträge ausgezahlt werden. Diese auszuschließen kostet nur einige Verknüpfungen (ein falsch negatives Ergebnis) und ist der sicherere Fehler. CoinJoin-Designs, die gleiche Outputs vermeiden, werden nicht erfasst. Der Test ist daher ein Filter und kein Detektor. Forschungswerkzeuge verwenden differenziertere Regeln. Goldfeder et al. (2018, „Wenn der Cookie auf die Blockchain trifft“) haben aus diesem Grund CoinJoins bei ihrem Clustering ausgeschlossen.

1. Ungewöhnliche Input-Kombinationen markieren. Inputs unterschiedlicher Skripttypen (zum Beispiel ein P2PKH-Input im Legacy-Format neben einem P2TR-Input) sind bei Software für einzelne Wallets ungewöhnlich und sollten genauer geprüft werden.

1. Zusammenführungen beobachten. Prüfen Sie jede Verknüpfung, durch die zwei große Cluster oder zwei Cluster mit unterschiedlichen Kennzeichnungen zusammengeführt würden. Harrigan und Fretter (2016, „Die erstaunliche Wirksamkeit des Adress-Clusterings“) stellten fest, dass große Cluster nur selten auf natürliche Weise zusammengeführt werden. Eine solche Zusammenführung ist daher ein Warnsignal.

1. Für jede Verknüpfung die Belegtransaktion aufbewahren. Stellt sich später heraus, dass eine Transaktion ein CoinJoin oder PayJoin war, können ihre Verknüpfungen entfernt und die Cluster neu erstellt werden.

1. Die Regel angeben, nicht nur das Ergebnis. Geben Sie an, dass ein Cluster mithilfe der Regel des gemeinsamen Input-Eigentums erstellt wurde, welche Ausschlüsse angewendet wurden und auf welcher Blockhöhe.

Vertrauensstufen

Wie Sie die tatsächlichen Adresspaare aus Input-Tabellen in SQL erstellen und daraus Cluster bilden, erfahren Sie in der Lektion UTXO-Daten abfragen.

Prüfungsschwerpunkt: warum gemeinsam ausgegebene Inputs auf eine gemeinsame Kontrollinstanz hindeuten (jeder Input benötigt eine eigene gültige Signatur, und Wallets wählen Coins aus ihrem eigenen Guthaben aus); die Regel als Heuristik 1 von Meiklejohn et al. und ihre Wurzeln im Whitepaper; Recall im Vergleich zur Präzision bei den Bloom-Filter-Belegen (mehr als 69 % der Wallet-Adressen gefunden); die wichtigsten Ausnahmen (CoinJoin, PayJoin gemäß BIP 78, gemeinsam finanzierte Kanäle, SIGHASH_ANYONECANPAY, Multisig, Verwahrung und Schlüsselimport); warum eine einzige Verknüpfung zwei ganze Cluster zusammenführen kann; vor dem Verknüpfen nach Outputs mit gleichem Wert filtern und den Schwellenwert dokumentieren; große oder widersprüchlich gekennzeichnete Zusammenführungen prüfen.