가명성

안나는 북극성이라는 필명으로 블로그를 씁니다. 독자는 안나의 글을 알아보지만 실제 이름까지 알지는 못할 수 있습니다. Bitcoin 주소도 비슷하게 작동할 수 있습니다. 법적 이름이 없는 식별자라도 그와 관련된 결제를 알아볼 수 있기 때문입니다. 이것이 가명성입니다. 안나가 블로그에 후원 주소를 올리면 독자는 해당 주소로 들어오는 돈을 살펴볼 수 있습니다. 나중에 안나가 블로그와 본인의 이름을 연결하면 이미 보이던 내역에 새로운 맥락이 생깁니다. 암호를 깨뜨릴 필요는 없었습니다. 새 정보가 이전에는 따로 있던 두 가지를 이어 주었을 뿐입니다. Bitcoin Whitepaper도 한 연결이 드러나면 다른 거래까지 알아내는 데 도움이 될 수 있다고 경고합니다. [1] [2]

Bitcoin 주소는 새 거래 출력의 자금을 사용하려면 어떤 조건을 충족해야 하는지 지갑에 알려 줍니다. 사람의 등록 정보나 신분증 번호가 아닙니다. 출력에는 금액과 그 금액을 쓰기 위해 충족해야 할 조건이 기록됩니다. 안나는 여러 주소를 쓸 수 있고 여러 사람이 공동 지갑 하나를 관리할 수도 있습니다. 개인키는 지갑이 결제를 승인하는 디지털 서명을 만들 때 사용하는 비밀 데이터입니다. Public Key, 즉 공개 키는 디지털 서명을 검증하는 데 쓰이지 서명자의 성명을 확인하는 데 쓰이지 않습니다. 유효한 서명은 해당 개인 키가 사용되었음을 보여 줍니다. 서명만으로는 안나와 보관을 맡은 업체, 그 키를 얻은 도둑을 구분할 수 없습니다. 자금을 움직일 수 있다는 것과 법적 신원을 안다는 것은 다른 문제입니다. [4]

안나가 블로그 주소를 업무 청구서에도 쓰면 삶의 두 영역을 스스로 연결하게 됩니다. 독자는 같은 주소의 다른 입금도 볼 수 있지만 어느 것이 후원금이고 어느 것이 고객의 대금인지는 모를 수 있습니다. 결제마다 새 수신 주소를 쓰면 이런 단순한 연결을 줄일 수 있습니다. 일반적인 지갑은 계정을 새로 만들지 않고도 많은 주소를 생성하고 보통 같은 백업으로 관리합니다. 그러나 새 주소가 익명성을 보장하는 새 신원은 아닙니다. 다른 단서를 통해 여러 주소를 같은 사람이 쓴다는 사실이 드러날 수 있습니다. [2]

안나가 KYC 절차로 신원 확인을 마친 거래소에서 bitcoin을 샀다고 가정해 봅시다. 거래소는 안나의 계정과 출금할 때 입력한 주소를 압니다. 하지만 출금 사실만으로 안나가 도착 주소를 관리한다고 단정할 수는 없습니다. 다른 사람에게 돈을 보냈을 수도 있기 때문입니다. 그래도 거래소에는 우연히 블로그를 읽는 사람에게 없는 구체적인 연결 정보가 있습니다. 판매자는 주문과 경우에 따라 배송 주소를 압니다. 이 자료가 Bitcoin 거래에 자동으로 기록되거나 모두에게 공개되는 것은 아닙니다. 다만 공개 기록에 맥락을 더할 수 있습니다. 따라서 프라이버시는 특정 관찰자가 실제로 무엇을 아는지를 기준으로 판단해야 합니다. [2]

Bitcoin은 실명 계좌의 잔액을 더하고 빼는 방식으로 작동하지 않습니다. 결제는 이전의 미사용 출력인 UTXO를 사용하고 새 출력을 만듭니다. 금액과 서로의 연결 관계는 공개되어 있습니다. 관찰자는 거래 사이의 실제 연결을 볼 수 있지만 각 부분을 누가 관리하는지는 추정해야 하는 경우가 많습니다. 이 차이가 중요합니다. 가치가 이동한 공개 기록은 완성된 소유자 명단이 아닙니다. 나중에 이름을 알게 되면 오래된 결제도 새롭게 해석할 수 있습니다. 블로그에서 주소를 지워도 과거 거래는 사라지지 않으며 저장된 블로그 사본도 남아 있을 수 있습니다. [1] [4]

지갑은 여러 UTXO를 합쳐 결제하고 남은 금액을 자신이 관리하는 주소로 거스름돈, 영어로 change, 형태로 돌려보내기도 합니다. 분석가는 합쳐진 입력을 한 소유자의 것으로 가정하고 어느 출력이 거스름돈인지 추정할 수 있습니다. 이 과정에서 서로 관련이 있다고 여겨지는 주소 묶음이 만들어집니다. 이런 방법은 휴리스틱입니다. 유용한 추론이지만 신원의 증명은 아닙니다. 예를 들어 CoinJoin과 PayJoin은 여러 참여자가 한 거래를 함께 만들 수 있게 합니다. 따라서 그럴듯한 주소 관계도만으로 안나가 모든 주소를 관리한다고 확신할 수 없습니다. 결론의 신뢰성은 다른 증거에도 달려 있습니다. [6]

안나가 다른 앱에서 지갑을 살펴보려고 XPUB, 즉 확장 공개 키를 내보냈다고 해 봅시다. BIP 32는 키를 나뭇가지처럼 여러 분기로 구성합니다. XPUB로 해당 분기의 다른 공개 키를 계산할 수 있지만 강화 파생 단계는 넘어갈 수 없습니다. 그 단계에는 개인 키가 필요하기 때문입니다. 주소 유형에 필요한 정보까지 있으면 앱은 관련 결제를 추적할 수 있습니다. XPUB 자체로 지출에 서명할 수는 없지만 해당 분기의 과거와 미래 활동이 드러날 수 있습니다. 같은 백업에서 만들어진 모든 지갑과 계정을 자동으로 보여 주는 것은 아닙니다. 그래도 고객에게 전달하는 주소 하나보다는 훨씬 넓은 범위를 볼 수 있습니다. [3]

안나가 웹 블록 탐색기에서 자기 주소를 검색하면 운영자는 검색을 네트워크 연결 정보인 IP 주소나 로그인한 계정과 연결할 수 있습니다. 지갑이 내역을 가져오는 서버도 비슷한 정보를 얻을 수 있습니다. 이런 서비스 이용 정보는 공개 블록체인과 다르지만 그 기록을 사람과 연결하는 데 도움이 될 수 있습니다. Full Node는 네트워크 규칙에 따라 비트코인 거래와 블록을 독립적으로 검증하는 소프트웨어를 실행하는 컴퓨터입니다. 지갑이 실제로 자신의 Full Node를 사용한다면 외부 서버로 보내는 조회를 줄일 수 있습니다. Tor는 IP 주소 노출을 줄일 수 있지만 블로그와 결제 사이에 이미 공개된 연결을 없애지는 못합니다. [2]

Lightning Network 결제는 보통 공개 블록체인에 개별 거래로 기록되지 않습니다. 따라서 눈에 보이는 흔적 하나가 줄지만 아무도 결제에 대해 모른다는 뜻은 아닙니다. Lightning 노드는 결제 채널을 관리하는 소프트웨어입니다. 채널에서는 두 당사자가 넣어 둔 자금의 배분을 갱신합니다. 노드는 공개 키를 식별자로 사용하며 자신의 공개 채널을 네트워크에 알릴 수 있습니다. BOLT 11 결제 요청에서는 수신 노드의 식별자를 알아낼 수 있으며 결제에 관한 다른 정보나 수신자에게 도달하는 경로 정보가 들어 있을 수도 있습니다. 보내는 사람, 받는 사람, 이용하는 서비스가 가진 정보는 서로 다릅니다. 요청을 공개하면 결제 자체가 메인 체인 밖에서 이루어져도 일부 정보가 다른 사람에게 알려질 수 있습니다. [5] [7]

안나는 주소를 공개하거나 앱에 내역을 보여 주기 전에 간단히 물을 수 있습니다. 누가 어떤 정보를 연결할 수 있게 될까요? 개별 결제에 새 주소를 쓰고, 누구에게 XPUB를 주는지 알며, 지갑이 어디서 데이터를 가져오는지 이해하는 것은 도움이 됩니다. 하지만 어느 한 조치도 완전한 익명성을 약속하지 않으며 새 설정이 오래된 연결을 지우지도 않습니다. 목표는 불필요한 정보 공유를 줄이고 이미 존재하는 연결을 파악하는 것입니다. 긴 문자열이 저절로 사람을 숨겨 줄 것이라고 믿는 것보다 실용적입니다. [2] [3]