Address Clustering

Анна использует новые адреса для разных поступлений, а затем платит магазину из своего кошелька. Кошелёк — приложение или устройство для получения и отправки биткоинов. Аналитик видит движение денег, но должен разделить два вопроса: какие средства потрачены и какие адреса, возможно, контролирует один субъект? Платёж магазину отвечает на первый. Сам по себе он не даёт повода объединять Анну и магазин. 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]