Collaborative Custody는 소유자와 다른 사람 또는 서비스가 함께 비트코인을 보호하는 관리 방식입니다. 흔한 모델에서는 소유자가 혼자 결제할 만큼의 키를 갖고, 문제가 생기면 서비스가 돕습니다. 이런 독립성은 상품 이름이 아니라 지갑의 실제 규칙에서 확인되어야 합니다.
피터는 자기 지갑으로 비트코인을 관리합니다. 걱정되는 것은 기기나 백업을 잃는 상황입니다. 지갑은 비트코인을 받고 보내는 앱이나 기기입니다. 여기서 서명은 비밀 숫자 값인 개인 키로 결제를 승인했다는 검증 가능한 증거를 만드는 작업입니다. 다른 사람은 그 비밀 값을 몰라도 서명을 확인할 수 있습니다. Unchained는 2-of-3 모델을 설명합니다. 세 키 중 두 키의 서명이 있어야 결제할 수 있습니다. 피터는 A와 B를, 서비스는 C를 보유합니다. 가능한 조합은 A+B, A+C, B+C이며 C만으로는 부족합니다. 여러 서명을 요구하는 방식을 Multisig라고 합니다. 피터는 서비스 없이 결제하고 키 하나를 잃으면 도움을 받을 수 있습니다. 하지만 동일한 Seed Phrase, 즉 같은 단어 백업으로 복원한 두 기기는 독립적이지 않습니다. 공통 비밀이 노출되면 둘 다 위험해집니다. [1] [4] [8]
사용 가능한 A+B와 완전한 지갑 자료가 있다면 서비스 장애만으로 피터의 결제 능력이 사라지지는 않습니다. A만 남았다면 A+C를 위해 서비스가 필요합니다. 이때 장애나 서명 거부가 복구를 막을 수 있습니다. A와 B를 모두 잃으면 C만으로는 구할 수 없습니다. 따라서 독립적인 이탈과 도움을 받는 복구는 따로 시험해야 합니다. Casa의 자체 인프라 없는 복구 안내도 서비스 키를 사용할 수 없다고 명시적으로 가정합니다. 실제 절차와 장비는 상품에 따라 달라지며 “collaborative”라는 말만으로 알 수 없습니다. [1] [6]
피터에게 백업이 있어도 대체 앱은 어떤 지갑을 재구성할지 알아야 합니다. 일반적인 2-of-3에는 서비스를 포함한 세 참여자의 공개 키와 사용 규칙이 필요합니다. 공개 키는 서명을 검증하고 개인 키는 서명을 만듭니다. Output Descriptor는 주소 파생 방식 등을 포함한 구성을 소프트웨어가 읽을 수 있게 설명합니다. 자신의 Seed Phrase 백업 두 개로 공급자의 누락된 공개 키를 만들어 낼 수는 없습니다. 서비스가 작동할 때 내보낸 파일을 저장하고 확인해야 합니다. 공유 전에는 내용도 살펴야 합니다. 일반적인 descriptor 형식에는 개인 키도 들어갈 수 있습니다. [4] [5]
코디네이터는 거래 자료를 구성하고 서명자는 승인에 쓰는 키를 보유합니다. BIP 174의 PSBT 형식은 미완성 거래와 필요한 정보를 프로그램과 기기 사이에 전달합니다. 파일을 만드는 것만으로 빠진 서명이 생기지는 않습니다. 키가 없는 코디네이터도 다른 수취인을 제시해 피해를 줄 수 있습니다. 서명 전에는 주소, 금액, 수수료, 그리고 자기 지갑으로 돌아오는 잔액인 change를 확인해야 합니다. Hardware Wallet은 키를 컴퓨터와 분리하는 데 도움이 되지만, 화면에서 무엇을 확인할 수 있고 피터가 실제로 무엇을 승인하는지도 중요합니다. [2] [3]
첫 결제 전, 앱이 공동 지갑을 구성할 때부터 오류가 생길 수 있습니다. BIP 129는 참여자가 서명 기준 수, 포함된 키, 첫 주소를 비교하도록 키와 구성을 교환하는 방법을 설명합니다. 지출 조건을 표현하는 스크립트 유형과 후속 키를 생성하는 파생 경로도 포함됩니다. 조작된 설정은 입금을 다른 곳으로 보낼 수 있습니다. 다만 이 문서 자체는 기기 저장소의 변조 저항성이나 이후 수신 주소 및 change 주소의 검증을 다루지 않습니다. 표준 지원이 제품 전체의 안전 인증은 아닙니다. [2]
XPUB는 지갑의 특정 가지에서 공개 키를 파생하는 확장 공개 키입니다. 이 정보와 구성을 아는 공급자는 지출에 필요한 서명이 부족해도 주소와 결제를 추적할 수 있습니다. 고객 이름이 있는 계정과 연결하면 신원과의 연관도 생깁니다. 프라이버시와 지출 권한은 별개입니다. 서비스가 혼자 결제할 수 없다는 말에도 조건이 있습니다. 피터의 다른 키를 얻거나 해로운 거래에 서명하도록 속일 가능성은 남아 있습니다. 공급자 권한을 줄이면 일부 위험은 줄지만 모두 사라지지는 않습니다. [2] [4]
피터가 키를 잃고 앱에서 새 키를 만들었다고 합시다. 그렇다고 예전 입금에 대한 이전 키가 무효가 되지는 않습니다. 거래 출력에는 금액과 나중에 그 금액을 쓰기 위해 충족해야 할 조건이 담깁니다. 자금은 UTXO, 즉 아직 쓰지 않은 거래 출력으로 존재하며 각자 지출 조건이 있습니다. 일반적인 Multisig에서는 새 조건을 만들고 관련 자금을 확인된 거래로 그쪽에 옮겨야 합니다. 이후 예전 주소에 무엇이 남았는지 확인합니다. 계정 비밀번호나 키 이름 변경은 이 전송을 대신하지 못합니다. 구성과 가족용 안내도 갱신해야 상속인이 실제 자금과 맞지 않는 계획을 따르지 않습니다. [4] [9]
유용한 연습은 별도의 테스트 지갑으로 합니다. 피터는 저장한 구성을 호환 프로그램으로 불러와 주소를 비교하고, 원래 서비스 없이 자기 키로 서명할 수 있는지 확인합니다. Watch-only 모드는 주소와 잔액을 보여 줄 뿐 서명 능력을 증명하지 않습니다. Caravan은 오픈소스 코디네이터지만 구체적인 형식과 기기 지원은 확인해야 합니다. 도움을 받는 복구, 사용할 수 없는 키, 수수료, change도 연습에 포함합니다. 결과물은 잔액을 보고 느끼는 안심이 아니라 사용 버전까지 적힌 이해하기 쉬운 절차여야 합니다. [3] [6] [7]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Multisig, 자기 수탁, Output Descriptor, PSBT, Bitcoin Inheritance Plan, Counterparty risk. 다음 항목에서도 이 글을 참조합니다 Bitcoin Inheritance Plan, Institutional custody.