Address Clustering

安娜为不同收款使用新地址，之后又从钱包向商店付款。钱包是接收和发送比特币的应用程序或设备。分析人员看到了资金流动，却必须区分两个问题：哪些资金被花掉了，哪些地址可能由同一主体控制？向商店付款回答的是第一个问题，本身并不足以把安娜和商店归为一组。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]