Address Clustering групує адреси Bitcoin або скрипти виходів (записи умов витрачання) за припущенням про спільний контроль. Таку групу називають cluster. Вона виникає в аналітичному інструменті, а не записується в блокчейн (публічну історію підтверджених транзакцій) як список власників. Ім’я людини чи назва сервісу потребують інших доказів.
Анна використовує нові адреси для різних надходжень, а згодом платить магазину зі свого гаманця. Гаманець — це застосунок або пристрій для отримання й надсилання біткоїнів. Аналітик бачить рух коштів, але має розділити два питання: які кошти витрачено і які адреси, ймовірно, контролює той самий суб’єкт? Платіж магазину відповідає на перше. Сам по собі він не дає підстав об’єднати Анну й магазин. Address Clustering шукає інші ознаки, наприклад спільне витрачання кількох надходжень. Схема платежів відображає справжні транзакційні зв’язки, а кольорові групи вже додають тлумачення. Для читання таких карт це принципова різниця. [1] [5]
Отримані раніше кошти існують як UTXO, невитрачені виходи транзакцій. Кожен такий вихід містить суму й умови, за яких її можна витратити. Новий вхід посилається на конкретний попередній вихід, а не на універсальне поле «адреса відправника». Інструмент знаходить первинний scriptPubKey, запис умов витрачання. Для підтримуваних типів адреса зручно представляє ці умови; не кожен скрипт має звичайну адресу. Ретельне пояснення має уточнювати, чи групуються адреси або скрипти, і називати мережу та діапазон блоків. Блок об’єднує транзакції в пакет, який додають до спільної історії. Технічний ідентифікатор від цього ще не встановлює особу людини. [4] [6]
Common-Input Ownership Heuristic припускає спільний контроль кількох входів транзакції. Пошук change — окремий крок: він визначає вихід, що повертає платнику решту після платежу й комісії. Правильний здогад пов’яже нову адресу решти Анни з давнішими надходженнями. Якщо за change помилково прийняти платіж магазину, до групи потраплять чужі кошти. Два виходи самі не визначають своїх ролей. Це можуть бути два отримувачі або перекази між власними гаманцями. Навіть раніше невідома адреса сама не доводить належність платнику. [1] [3]
Округлена сума, тип скрипту чи повторне використання адреси є підказками, а не незмінними законами. Оновлення гаманця може інакше складати транзакції й спричинити помилки старої моделі. CoinJoin дозволяє співпрацю кількох учасників; у Payjoin за BIP 78 отримувач теж може додати власні входи. Співпраця не вимагає однакових сум на виходах. Тому історичну точність не можна обіцяти для нинішніх транзакцій без нової перевірки. Важливо також знати випадки, для яких метод узагалі не дає прогнозу. [2] [3]
Уявімо дві окремі групи адрес. Один хибний зв’язок може об’єднати їх і поширити помилку на всіх учасників. Для швидкого об’єднання програми часто використовують union-find, структуру даних для пов’язаних груп. Її звичайна форма не вміє видалити давній зв’язок і автоматично правильно розділити результат. Практична рекомендація для перевірної аналітики — зберігати транзакції, окремі зв’язки й версії правил, а не лише підсумковий список адрес. Це наслідок описаного поширення помилок: виправлення може вимагати перерахунку, а не простого перейменування групи. [2]
Malte Möser та Arvind Narayanan досліджують cluster collapse, помилкове злиття багатьох груп у величезну. Їхній constrained union-find відмовляється об’єднувати групи, пов’язані прогнозованим платіжним виходом. У прикладі Анни припущення «вона платить магазину» може перешкодити подальшому злиттю сторін. Але цей запобіжник не знає істини незалежно: він сам залежить від прогнозу платежу й може відхилити правильний зв’язок. Менше об’єднань тому не означає автоматично повнішої чи безпомилкової картини власників. [2]
Позначити одну адресу назвою біржі та поширити назву на весь cluster — різні кроки. Мітка потребує джерела, періоду чинності та простежуваного шляху поширення. Група під контролем біржі може обслуговувати багатьох клієнтів. Перевірка моделі також не повинна спиратися лише на дані, утворені тим самим припущенням. Помилкові злиття, пропущені зв’язки й охоплення вибірки слід оцінювати окремо. Велика кількість позначених адрес сама не гарантує правильного приписування. [1] [2]
Анна може переказати кошти між власними гаманцями. Якщо модель не пов’яже їх, рух може бути врахований як платіж між різними суб’єктами. Краще групування розпізнає внутрішній переказ, або self-churn, і зменшить оцінку обсягу платежів без зміни історії блокчейну. Так само баланс групи складається з її ще невитрачених UTXO на певному блоці; сума всіх давніх надходжень включала б уже витрачені гроші. Порівнюючи графіки, перевіряйте дату, версію моделі, мітки та зріз даних. [1] [2]
Для повної картини прочитайте також Common-Input Ownership Heuristic, Chain Surveillance, Change Address, CoinJoin, Payjoin, UTXO. На цю статтю також посилаються Псевдонімність, Chain Surveillance, Common-Input Ownership Heuristic, Transaction Labeling.