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.