158 / 736CLUSTER

Address Clustering

Które adresy mogą być pod wspólną kontrolą

Jeden portfel może używać wielu adresów. Address Clustering próbuje układać je w powiązane grupy. Wynik zależy jednak od założeń: błędny związek może przypisać cudzą płatność niewłaściwej osobie lub usłudze.

Address Clustering grupuje adresy Bitcoin lub skrypty wyjść (zapisy warunków wydania środków) według przypuszczalnej wspólnej kontroli. Taką grupę nazywa się cluster. Powstaje ona w narzędziu analitycznym, a nie jako lista właścicieli zapisana w blockchainie (publicznej historii potwierdzonych transakcji). Ustalenie osoby lub usługi wymaga dodatkowych dowodów.

Anna używa nowych adresów do różnych wpłat, a później płaci portfelem w sklepie. Portfel to aplikacja lub urządzenie do odbierania i wysyłania bitcoinów. Analityk widzi przepływ pieniędzy, lecz musi rozdzielić dwa pytania: jakie środki wydano i które adresy może kontrolować ten sam podmiot? Płatność sklepowi odpowiada na pierwsze. Sama nie uzasadnia umieszczenia Anny i sklepu w jednej grupie. Address Clustering szuka innych wskazówek, choćby wspólnego wydawania kilku wpływów. Diagram płatności pokazuje więc rzeczywiste związki transakcji, a kolorowe grupy dodają interpretację. To ważne rozróżnienie przy czytaniu takich map. [1] [5]

Otrzymane wcześniej środki istnieją jako UTXO, niewydane wyjścia transakcji. Każde takie wyjście zapisuje kwotę i warunki jej wydania. Nowe wejście wskazuje konkretne wcześniejsze wyjście, a nie uniwersalne pole „adres nadawcy”. Narzędzie odszukuje pierwotny scriptPubKey, zapis warunków wydania. Dla obsługiwanych typów adres wygodnie reprezentuje te warunki; nie każdy skrypt ma zwykły adres. Rzetelny opis musi odróżniać grupowanie adresów od grupowania skryptów oraz wskazywać sieć i zakres bloków. Blok grupuje transakcje w pakiet dołączany do wspólnej historii. Techniczny identyfikator nie staje się przez to tożsamością człowieka. [4] [6]

Common-Input Ownership Heuristic zakłada wspólną kontrolę kilku wejść transakcji. Rozpoznawanie change to osobny krok: szuka wyjścia zwracającego resztę po płatności i opłacie. Trafny wniosek łączy nowy adres reszty Anny z wcześniejszymi wpływami. Pomylenie zapłaty sklepowi z change dołączy cudze środki. Same dwa wyjścia nie rozstrzygają ich ról. Mogą oznaczać dwóch odbiorców albo przelewy między własnymi portfelami. Również nigdy wcześniej niewidziany adres nie dowodzi, że należy do płacącego. [1] [3]

Zaokrąglona kwota, typ skryptu czy ponownie użyty adres są wskazówkami, nie stałymi prawami. Aktualizacja portfela może inaczej budować transakcje i zmylić stary model. CoinJoin pozwala współpracować kilku uczestnikom; w Payjoin według BIP 78 odbiorca może dodać własne wejścia. Współpraca nie wymaga wyjść o równych kwotach. Nie można więc obiecywać historycznej skuteczności dla dzisiejszych transakcji bez nowych pomiarów. Ważne są też przypadki, dla których metoda nie podaje prognozy. [2] [3]

Wyobraźmy sobie dwie oddzielne grupy adresów. Jeden fałszywy związek może je scalić i przenieść błąd na wszystkich członków. Programy często wykorzystują union-find, strukturę danych śledzącą połączone grupy, do szybkiego scalania. Jej zwykła postać nie potrafi usunąć dawnego połączenia i automatycznie poprawnie rozdzielić wyniku. Praktyczne zalecenie dla sprawdzalnej analizy to zachowanie transakcji, poszczególnych powiązań i wersji reguł, a nie samej końcowej listy. Wynika to z opisanego rozchodzenia się błędów: naprawa może wymagać ponownego obliczenia zamiast zmiany nazwy grupy. [2]

Malte Möser i Arvind Narayanan badają cluster collapse, błędne zlanie wielu grup w jedną wielką. Ich constrained union-find odrzuca scalenie grup powiązanych wyjściem uznanym przez model za płatność. W przykładzie Anny przypuszczenie „płaci sklepowi” może więc zapobiec późniejszemu połączeniu obu stron. To zabezpieczenie nie zna jednak prawdy niezależnie: samo zależy od prognozy płatności i może odrzucać poprawne związki. Mniej scaleń nie daje automatycznie pełnego ani bezbłędnego obrazu właścicieli. [2]

Oznaczenie jednego adresu nazwą giełdy i rozszerzenie nazwy na cały cluster to dwa kroki. Etykieta wymaga źródła, okresu ważności i prześledzenia sposobu rozszerzenia. Grupa kontrolowana przez giełdę może obsługiwać wielu klientów. Walidacja modelu nie powinna też opierać się wyłącznie na danych wytworzonych tym samym założeniem. Błędne scalenia, pominięte związki i pokrycie próby należy oceniać osobno. Wiele oznaczonych adresów samo w sobie nie gwarantuje poprawnych przypisań. [1] [2]

Anna może przesłać środki między własnymi portfelami. Jeśli model ich nie powiąże, może policzyć ruch jako płatność między różnymi podmiotami. Lepsze grupowanie rozpozna przelew wewnętrzny, czyli self-churn, i zmniejszy szacowany wolumen bez zmiany historii blockchaina. Podobnie saldo grupy tworzą jej nadal niewydane UTXO na określonym bloku; suma wszystkich dawnych wpływów obejmowałaby pieniądze już wydane. Porównując wykresy, sprawdzaj więc datę, wersję modelu, etykiety i punkt odcięcia danych. [1] [2]

Pełniejszy obraz uzyskasz, czytając to hasło razem z Common-Input Ownership Heuristic, Chain Surveillance, Change Address, CoinJoin, Payjoin, UTXO. Do tego hasła prowadzą również odsyłacze z Pseudonimowość, Chain Surveillance, Common-Input Ownership Heuristic, Transaction Labeling.

DOC · 001Meiklejohn et al. — A Fistful of BitcoinsŹródło pierwotne DOC · 002Möser and Narayanan — Resurrecting Address Clustering in BitcoinŹródło pierwotne DOC · 003BIP 78 — A Simple Payjoin ProposalSpecyfikacja DOC · 004Bitcoin Developer Guide — TransactionsDokumentacja DOC · 005Bitcoin Developer Guide — WalletsDokumentacja DOC · 006Bitcoin Developer Guide — Block ChainDokumentacja
Zaktualizowano: Najpierw źródła · To nie jest porada inwestycyjna