157 / 736CIOH

Common-Input Ownership Heuristic

함께 쓰면 같은 주체의 통제로 보이는 이유

지갑이 여러 입금을 한 결제에 모아 쓰면 이전에 보이지 않던 연결이 드러납니다. 분석가는 같은 주체가 통제한다고 추정할 수 있지만, 하나의 공동 거래가 반드시 한 명의 소유자를 뜻하지는 않습니다.

Common-Input Ownership Heuristic은 Bitcoin 거래 하나의 여러 입력, 즉 사용하는 이전 금액에 대한 참조를 보통 같은 주체가 통제한다고 가정합니다. 지갑의 사용 방식에서 관련 주소를 찾는 분석 단서입니다. Bitcoin 규칙이나 자금 소유권의 증명은 아닙니다.

피터는 서로 다른 주소로 두 번 돈을 받았습니다. 나중에 자전거 수리비를 낼 때 지갑이 두 금액을 함께 씁니다. 지갑은 비트코인을 받고 보내는 앱이나 기기입니다. 외부 관찰자에게는 각각의 입금 당시 보이지 않았던 연결이 나타납니다. 누군가 이 돈을 하나의 거래에서 쓸 수 있었다는 것입니다. 일반적인 개인 지갑이라면 같은 사람이 통제한다고 의심하는 것이 자연스럽습니다. 이 행동이 실용적인 추정 규칙인 휴리스틱의 근거입니다. 그러나 Bitcoin은 모든 입력의 소유자가 같아야 한다고 요구하지 않습니다. 입력이 더 많다는 사실만으로 추정이 맞을 확률을 알 수도 없습니다. [1] [6]

받은 자금은 이전 거래의 미사용 출력인 UTXO로 존재합니다. 각 출력에는 금액과 그 금액을 사용할 수 있는 조건이 기록되어 있습니다. 새 거래의 입력은 그중 특정 출력을 가리킵니다. 분석가는 사용 규칙을 정하는 짧은 프로그램인 스크립트에 적힌 조건을 찾아 해당 주소나 스크립트를 다른 입력의 것과 연결합니다. 이것이 이 방법의 정확한 범위입니다. 입력이 하나뿐인 거래에는 새롭게 연결할 쌍이 없습니다. 또한 어떤 새 출력이 결제이고 어떤 것이 change, 즉 지불자에게 돌아가는 잔액인지도 이 규칙만으로 알 수 없습니다. 다른 단서가 필요합니다. 따라서 수리점으로 가는 출력을 피터의 결제에 포함됐다는 이유만으로 피터의 것이라고 할 수는 없습니다. [1] [4]

피터와 다른 사람이 공동 거래를 준비하고 각자 자신의 입력에 서명할 수 있습니다. 비트코인 사용을 승인하는 서명을 만드는 비밀 숫자인 개인 키는 따로 보관합니다. PSBT는 미완성 거래와 필요한 정보를 프로그램이나 장치 사이에 전달하는 형식으로, BIP 174에 설명되어 있습니다. 정보를 모으는 코디네이터가 모든 키를 가질 필요는 없습니다. 네트워크는 사용 조건이 충족됐는지 확인하지, 모든 서명을 한 사람이 만들었는지 확인하지 않습니다. Multisig는 또 다른 문제입니다. 하나의 입력에 여러 서명을 요구할 수 있지만, 이 휴리스틱은 여러 입력 사이의 관계를 추정합니다. [2] [5] [6]

CoinJoin은 여러 참여자가 각자의 자금을 공동 거래에 넣을 수 있게 합니다. Payjoin은 결제 안에서 이 문제를 보여 줍니다. BIP 78에 따르면 수취인도 자신의 입력을 추가할 수 있습니다. 수리점이 이렇게 결제를 받았다면 규칙을 맹목적으로 적용할 경우 수리점 자금과 피터 자금을 같은 집단으로 묶을 수 있습니다. 협력에는 모든 출력의 금액이 같아야 한다는 조건도 없습니다. 따라서 명백한 CoinJoin처럼 보이는 거래만 빼고 나머지를 단일 소유자의 결제로 단정할 수 없습니다. 모든 거래가 협업이라는 뜻이 아니라, 겉모습만으로는 그 가능성을 항상 배제할 수 없다는 뜻입니다. [2]

주소 A, B, C를 생각해 봅시다. 첫 거래가 A+B의 출력을 함께 쓰고, 다른 거래가 B+C의 다른 출력을 모아 씁니다. 같은 UTXO를 두 번 쓰는 상황이 아닙니다. 도구는 공통된 B를 통해 A+B+C를 한 집단인 cluster로 묶을 수 있습니다. 하지만 두 번째 거래가 서로 다른 사람의 협력이었다면 이미 분류된 A에도 오류가 미칩니다. 이렇게 잘못된 연결이 집단 전체로 퍼집니다. 틀린 연결 수가 적다고 해서 잘못 귀속된 주소 수도 적다는 보장은 없습니다. [1] [3]

거래소는 여러 고객을 위해 관리하는 자금을 하나의 거래에서 쓸 수 있습니다. 이때 휴리스틱이 서비스의 공통된 운영 통제를 정확히 찾을 수는 있습니다. 그러나 자금의 경제적 소유자가 어느 고객인지는 정하지 못합니다. 서비스 이름조차 입력만 보고 알 수 없습니다. 라벨에는 추가 증거가 필요하고 해당 시기에 맞아야 합니다. 반대로 피터는 자금을 한 번도 합치지 않는 여러 지갑을 쓸 수 있습니다. 발견한 집단을 센다고 그대로 사람 수가 나오는 것은 아닙니다. 통제, 소유, 신원은 관련이 있지만 별개의 질문입니다. [1]

분석가는 주소 연결이 맞았는지 알고 싶습니다. 그런데 이후에 함께 썼다는 사실만으로 확인한다면 똑같은 가정을 되풀이할 수 있습니다. 그것이 자동으로 독립적인 증거가 되지는 않습니다. Malte Möser와 Arvind Narayanan은 이런 참조 데이터의 활용과 한계를 설명합니다. 따라서 평가에는 표본 출처, 제외한 거래, 조사 기간을 밝혀야 합니다. 잘못된 병합, 놓친 연결, 포함 범위는 따로 평가해야 합니다. 알려진 사례를 통한 보정 없이 점수를 올바른 인물 식별의 확률로 해석해서는 안 됩니다. [3]

피터는 사용할 UTXO를 직접 고르는 Coin Control로 이전에 분리된 입금이 앞으로 연결되는 일을 줄일 수 있습니다. 과거 거래가 지워지는 것은 아니며 어떤 자금을 고르는지 이해해야 합니다. Payjoin도 다른 모든 귀속 추정 방법을 없애지는 않습니다. 분석에서는 각 연결을 거래, 규칙 버전, 포함하거나 제외한 이유로 거슬러 올라갈 수 있어야 합니다. 이는 출처의 한계에서 도출한 검토 질문입니다. 오류가 발견되면 어떤 주소가 그 집단에 속하는지 다시 판단할 수 있어야 합니다. 바뀌지 않은 결론에 메모만 붙여서는 잘못된 귀속이 고쳐지지 않습니다. [2] [3]

더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Address Clustering, CoinJoin, Payjoin, Chain Surveillance, PSBT, Coin Control. 다음 항목에서도 이 글을 참조합니다 Payjoin, Coin Selection, Chain Surveillance, Address Clustering.

DOC · 001Meiklejohn et al. — A Fistful of Bitcoins1차 출처 DOC · 002BIP 78 — A Simple Payjoin Proposal명세 DOC · 003Möser and Narayanan — Resurrecting Address Clustering in Bitcoin1차 출처 DOC · 004Bitcoin Developer Guide — Transactions문서 DOC · 005BIP 174 — Partially Signed Bitcoin Transaction Format명세 DOC · 006Bitcoin Developer Guide — Wallets문서
개정일: 1차 출처 우선 · 투자 조언이 아닙니다