Address Clustering

取引グラフは実際に使用済みの出力と、それを消費した取引を結びます。cluster はさらに推定管理に基づきノードをまとめます。二アドレス間の支払いだけで同一所有者とは判断できません。取引の辺と共通管理の関係は区別します。 [Meiklejohn et al. — A Fistful of Bitcoins]

入力は過去の UTXO を参照し、汎用的な送信者アドレス欄ではありません。元の scriptPubKey を取得し、ネットワークとブロック範囲を示す必要があります。通常のアドレス表現がないスクリプトもあり、無理に個人へ置き換えると技術的対象と身元を混同します。 [Bitcoin Developer Guide — Transactions]

Common-Input Ownership Heuristic は入力側を結びます。change 判定は出力を追加し得ますが、受取人を誤って選ぶと支払いの両者を統合します。二出力は必ずしも支払いと change ではなく、二受取人や自分のウォレット間移動の場合もあります。アドレスの新しさだけでは決まりません。 [Meiklejohn et al. — A Fistful of Bitcoins] [BIP 78 — A Simple Payjoin Proposal]

スクリプト形式、丸い金額、過去のアドレス利用はモデルの特徴であり、証明ではありません。CoinJoin と Payjoin は一部の仮定に反し、例外は目立つ同額出力を要しません。ソフトや利用行動の変化で誤り率は変わるため、過去の成績を現行データへ移すには新たな測定が必要です。 [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin] [BIP 78 — A Simple Payjoin Proposal]

Union-find は推移的グループを効率的に作ります。ただし通常の実装では過去の統合を単に削除し、最終 cluster を正しく分割できません。元の辺、取引、規則の版を保存し、必要なら再計算します。メンバー一覧だけでは統合の証拠経路を保持できません。 [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]

Möser と Narayanan は、支払い出力と予測される関係で隔てられたグループの統合を union-find で制限します。cluster collapse を抑え得ますが、この制約も支払い推定に依存します。保守的規則は正しい関係も拒否し得るため、統合が少ないだけで全所有者の記述が正確とは限りません。 [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]

一アドレスにサービス名を付けることと cluster 全体へ広げることは別の主張です。出所、期間、伝播経路を記録し、取引所グループを一顧客と見なさないようにします。同じ推定規則由来の参照データは完全には独立していません。誤統合、誤分割、標本の網羅範囲を分けて評価します。 [Meiklejohn et al. — A Fistful of Bitcoins] [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]

内部移動を認識すれば推定入金から self-churn を除外できます。したがってブロックチェーンが変わらなくても、グループの新版で過去指標が改訂されます。残高は特定ブロックで未使用の UTXO から計算し、過去の全受取出力を合計しません。モデルとラベルの版、データの区切りを示します。 [Meiklejohn et al. — A Fistful of Bitcoins] [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]