158 / 736CLUSTER

Address Clustering

Které adresy mohou patřit pod společnou kontrolu

Jedna peněženka může používat mnoho adres. Address Clustering se je pokouší poskládat do souvisejících skupin. Výsledek ale závisí na předpokladech: chybné spojení může připsat cizí platbu nesprávnému člověku nebo službě.

Address Clustering je seskupování bitcoinových adres nebo výstupních skriptů (zápisů podmínek pro utracení) podle odhadované společné kontroly. Takové skupině se říká cluster. Vzniká v analytickém nástroji, nikoli jako seznam vlastníků uložený v blockchainu (veřejné historii potvrzených transakcí); jméno člověka či služby vyžaduje další důkazy.

Anna používá pro různé příjmy nové adresy a později z peněženky zaplatí v obchodě. Peněženka je aplikace nebo zařízení pro přijímání a odesílání bitcoinů. Analytik vidí pohyb peněz, ale musí si položit dvě různé otázky: které prostředky byly utraceny a které adresy asi ovládá stejný subjekt? Platba obchodu odpovídá první otázce. Sama není důvodem zařadit Annu a obchod do jedné skupiny. Address Clustering hledá jiné stopy společné kontroly, například společné použití více příjmů. Diagram plateb tak popisuje skutečné transakční vazby, zatímco barevně vyznačené skupiny už přidávají výklad. Právě tento rozdíl je při čtení podobných map zásadní. [1] [5]

Peníze přijaté v minulosti jsou evidovány jako UTXO, dosud neutracené výstupy transakcí. Každý takový výstup zaznamenává částku a podmínky, za kterých ji lze utratit. Nový vstup ukazuje na konkrétní starší výstup, ne na univerzální kolonku „adresa odesílatele“. Nástroj proto dohledává původní scriptPubKey, tedy zápis podmínek, za kterých lze výstup utratit. Adresa je u podporovaných typů pohodlný způsob, jak tyto podmínky reprezentovat; ne každý skript má běžnou adresu. Poctivý výklad musí rozlišit, zda seskupuje adresy, nebo skripty, a určit síť i rozsah bloků. Blok sdružuje transakce do dávky, která se připojuje ke společné historii. Technický údaj se tím ještě nestává totožností člověka. [4] [6]

Common-Input Ownership Heuristic předpokládá společnou kontrolu několika vstupů jedné transakce. Odhad change je další krok: hledá výstup, kterým se nevyužitý zbytek po platbě a poplatku vrací plátci. Pokud se nástroj trefí, může propojit Anninu novou adresu pro vratku s jejími staršími příjmy. Pokud za vratku omylem označí platbu obchodu, připojí cizí prostředky. Dva výstupy samy nerozhodují, který je který. Mohou znamenat také dva příjemce nebo převod mezi vlastními peněženkami. Ani dosud neviděná adresa sama nedokazuje, že patří plátci. [1] [3]

Zaokrouhlená částka, typ skriptu nebo opakované použití adresy mohou být vodítkem, nikoli neměnným pravidlem. Nová verze peněženky může transakce sestavovat jinak a starší model pak chybovat. CoinJoin umožňuje společnou transakci více účastníků; u Payjoin podle BIP 78 může přidat vlastní vstupy také příjemce. Spolupráce přitom nemusí vytvářet výstupy se stejnými částkami. Historicky naměřenou úspěšnost proto nelze bez nového ověření slibovat pro dnešní transakce. Důležité je také znát případy, pro které metoda vůbec nevydává odhad. [2] [3]

Představme si dvě dosud oddělené skupiny adres. Jediná chybná vazba je může spojit a převést omyl na všechny jejich členy. Programy k rychlému slučování často používají union-find, datovou strukturu pro evidenci spojených skupin. Její běžná podoba ale neumí odstranit starou vazbu a automaticky správně rozdělit výsledek. Doporučení pro kontrolovatelnou analýzu je proto uchovat transakce, jednotlivé vazby a verze pravidel, nejen konečný seznam adres. To je praktický důsledek popsaného šíření chyb: oprava může vyžadovat nový výpočet, nikoli pouhé přejmenování skupiny. [2]

Malte Möser a Arvind Narayanan zkoumají, jak bránit cluster collapse, tedy chybnému splynutí mnoha skupin do jedné velké. Jejich constrained union-find odmítá sloučit skupiny, mezi nimiž model předpokládá platební výstup. Vrátíme-li se k Anně, odhad „tady platí obchodu“ může bránit následnému spojení obou stran. Ani tato pojistka však nezná pravdu nezávisle: sama závisí na odhadu platby a může odmítnout správnou vazbu. Menší počet sloučení proto není automaticky úplnějším ani bezchybným obrazem vlastníků. [2]

Označit jednu adresu názvem směnárny a přenést označení na celý cluster jsou dva různé kroky. U štítku, tedy přiřazeného názvu, potřebujeme znát zdroj, období platnosti i cestu, kterou se rozšířil. Skupina ovládaná směnárnou navíc může obsluhovat mnoho zákazníků. Ani ověření modelu nemá stát jen na datech vytvořených stejným předpokladem. Chybné sloučení, přehlédnuté spojení a pokrytí vzorku je třeba posuzovat odděleně. Velké množství označených adres samo nezaručuje správnost jejich přiřazení. [1] [2]

Anna může převést prostředky mezi dvěma vlastními peněženkami. Pokud je model nepropojí, může tento pohyb započítat jako platbu mezi různými subjekty. Po vylepšení skupin jej rozpozná jako vlastní přesun, označovaný self-churn, a odhad platebního objemu klesne, přestože historie blockchainu zůstala stejná. Podobně zůstatek clusteru tvoří jeho dosud neutracené UTXO k určenému bloku; součet všech dávných příjmů by zahrnoval i již utracené peníze. Při porovnávání grafů proto sledujte nejen datum, ale i verzi modelu, štítků a použitý datový řez. [1] [2]

Pro nejúplnější obraz čtěte toto heslo společně s Common-Input Ownership Heuristic, Chain Surveillance, Change Address, CoinJoin, Payjoin, UTXO. Opačným směrem na něj odkazují také Pseudonymita, Chain Surveillance, Common-Input Ownership Heuristic, Transaction Labeling.

DOC · 001Meiklejohn et al. — A Fistful of BitcoinsPrimární zdroj DOC · 002Möser and Narayanan — Resurrecting Address Clustering in BitcoinPrimární zdroj DOC · 003BIP 78 — A Simple Payjoin ProposalSpecifikace DOC · 004Bitcoin Developer Guide — TransactionsDokumentace DOC · 005Bitcoin Developer Guide — WalletsDokumentace DOC · 006Bitcoin Developer Guide — Block ChainDokumentace
Revidováno: Primární zdroje · Nejde o investiční doporučení