158 / 736CLUSTER

Address Clustering

どのアドレスが同じ管理下にあるのか

一つのウォレットは多くのアドレスを使えます。Address Clustering はそれらを関連するグループにまとめようとします。ただし結果は仮定に依存します。誤った結び付きが一つあるだけで、他人の支払いを別の人やサービスに帰属させることがあります。

Address Clustering は、共通の管理を推測して Bitcoin アドレスや出力スクリプト(資金の使用条件を記したコード)をまとめる手法です。そのグループを cluster と呼びます。分析ツールが作るもので、ブロックチェーン(承認済み取引の公開履歴)に保存された所有者名簿ではありません。人物やサービスの特定には別の証拠が必要です。

アンナは入金ごとに新しいアドレスを使い、後でウォレットから店に支払います。ウォレットは、ビットコインを受け取ったり送ったりするためのアプリや機器です。分析者には資金の動きが見えますが、二つの問いを分ける必要があります。何が使われたのか、そしてどのアドレスが同じ主体の管理下にありそうなのか、です。店への支払いは前者に答えます。それだけでアンナと店を同じグループにはできません。Address Clustering は複数の入金を一緒に使うなど、別の手掛かりを探します。支払いの図が示す実際の取引関係に、色分けされたグループは解釈を加えているのです。この違いが図を読むうえで重要です。 [1] [5]

以前受け取った資金は、未使用の取引出力である UTXO として存在します。それぞれの出力には金額と、その金額を使うための条件が記されています。新しい入力は特定の過去の出力を指し、共通の「送信者アドレス」欄を持つわけではありません。ツールは元の scriptPubKey、つまりその出力を使うための条件を調べます。対応する種類ではアドレスが条件を便利に表現しますが、すべてのスクリプトに一般的なアドレスがあるとは限りません。正確な説明には、アドレスとスクリプトのどちらをまとめるのか、対象ネットワークとブロック範囲は何かを示す必要があります。ブロックは、共有する履歴に追加する取引のまとまりです。技術的な識別子は人物の身元そのものではありません。 [4] [6]

Common-Input Ownership Heuristic は、一つの取引の複数入力に共通の管理者を仮定します。change の識別は別の工程です。支払いと手数料を差し引いた残りが支払人に戻る出力を探します。正しく推測すれば、アンナの新しいお釣り用アドレスと過去の入金を結び付けられます。店への支払いを change と誤認すれば、他人の資金を加えてしまいます。出力が二つあるだけでは役割は決まりません。二人の受取人や、自分のウォレット間の移動も考えられます。初めて現れたアドレスも、それだけで支払人のものとは証明できません。 [1] [3]

きりのよい金額、スクリプトの種類、アドレスの再利用は手掛かりであり、不変の法則ではありません。ウォレットの更新で取引の組み立て方が変わり、古いモデルが誤ることもあります。CoinJoin は複数参加者の共同取引を可能にし、BIP 78 の Payjoin では受取人も入力を追加できます。共同作業が同額の出力を作るとは限りません。過去の正確さを新しい評価なしに現在の取引へ保証することはできないのです。どんな場合に予測を出さないかも重要です。 [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.

DOC · 001Meiklejohn et al. — A Fistful of Bitcoins一次資料 DOC · 002Möser and Narayanan — Resurrecting Address Clustering in Bitcoin一次資料 DOC · 003BIP 78 — A Simple Payjoin Proposal仕様 DOC · 004Bitcoin Developer Guide — Transactions文書 DOC · 005Bitcoin Developer Guide — Wallets文書 DOC · 006Bitcoin Developer Guide — Block Chain文書
改訂日: 一次資料を優先 · 投資助言ではありません