Watch-only Wallet

앨리스는 키를 하드웨어 지갑에 보관하고 휴대폰으로 입금을 확인하려 합니다. 그래서 백업 단어가 아닌 지갑의 공개 설정을 휴대폰으로 옮깁니다. 앱은 이 설정으로 해당 주소를 알아보고 네트워크에서 관련 거래를 찾습니다. 서명 장치가 집에서 꺼져 있어도 앨리스는 20 000 sat(비트코인의 최소 단위)의 입금과 확인 상태를 볼 수 있습니다. 그렇다고 휴대폰에 그 돈을 쓸 권한이 생긴 것은 아닙니다. 같은 방식으로 상인은 회계 담당자에게 키를 주지 않고 입출금 내역을 보여 줄 수 있습니다. 중요한 것은 실제로 무엇을 가져왔느냐입니다. 키를 복구하는 백업 단어인 Seed Phrase를 입력하면 이런 분리는 사라집니다. [12]

관찰 앱에는 다른 사람의 공개 주소도 추가할 수 있습니다. 따라서 화면의 금액은 사용자가 그 돈을 쓸 수 있다는 증거도, 모든 빚을 갚을 능력이 있다는 증거도 아닙니다. 앱은 찾아낸 UTXO, 즉 이전 지급에서 생긴 출력 중 아직 쓰지 않은 것을 합산합니다. 하지만 가져온 정보와 이용 가능한 이력에 맞는 것만 찾습니다. 빠진 주소, 끝나지 않은 검색, 신뢰할 수 없는 서버 때문에 결과가 불완전할 수 있습니다. 화면에 0이 나온다는 사실만으로 비트코인을 잃었다고 판단하지 말고, 먼저 관찰 범위와 데이터 출처를 확인해야 합니다. [8] [9]

앨리스가 지불하려 하면 앱이 사용 가능한 UTXO를 고르고 수신자, 금액, 수수료를 준비합니다. 입력에서 쓰고 남은 부분은 자신의 지갑으로 돌아올 수 있는데, 이를 거스름돈 또는 change라고 합니다. 이 정보는 BIP174가 정의한 부분 서명 비트코인 거래 형식인 PSBT로 전달할 수 있습니다. 별도 장치는 자체 UTXO 데이터베이스 없이도 서명에 필요한 정보를 받습니다. 앨리스는 그 장치의 신뢰할 수 있는 화면에서 실제 수신자, 금액, 수수료와 거스름돈을 확인해야 합니다. 침해된 앱이 의도와 다른 거래를 준비했을 수 있기 때문입니다. sighash 설정도 중요합니다. 이는 서명이 거래의 어느 부분을 포함하는지 정합니다. 확인하고 서명한 뒤에야 승인한 제안 및 지갑 규칙과 일치하는 최종 거래를 네트워크에 전파합니다. [2] [10]

확장 공개키인 xpub은 지갑의 특정 분기에서 다른 공개키를 파생할 수 있지만, 혼자서는 지급에 서명하지 못합니다. 그래도 지갑 규칙과 함께 이를 얻은 사람은 파생 가능한 주소, 과거와 미래의 지급, 잔액을 연결할 수 있습니다. 한 번의 입금을 위해 주소 하나를 알려 주는 것보다 훨씬 많은 정보를 내주는 셈입니다. 외부 서버도 앱의 반복 조회로 비슷한 전체 모습을 알아낼 수 있습니다. 블록체인을 직접 검증하는 자신의 Full Node를 운영하면 이런 노출을 줄일 수 있습니다. 암호화 등으로 연결을 보호해도 목적지 서버에는 조회 내용이 보입니다. 필요한 계정만 내보내고 복사본을 줄이며 주소에 이름이나 지급 목적을 붙이는 라벨도 보호하세요. [1] [13] [14]

다음 내용은 설정과 복구를 위한 기술 참고 자료입니다. 스크립트는 지출 조건을 정하고, Output Descriptor는 그 규칙과 주소 파생에 필요한 정보를 기록합니다. HD Wallet은 seed에서 키 트리를 만듭니다. seed는 이 키들을 파생하는 출발점이 되는 비밀 데이터입니다. non-hardened 파생은 xpub으로 추가 공개키를 만들 수 있지만 hardened 파생에는 개인키가 필요합니다. Multisig는 필요한 서명 수를 미리 정합니다. 주소를 가져오면 그 스크립트만 관찰하며 앞으로 생길 수신·거스름돈 주소까지 보지는 않습니다. 공개키로 여러 스크립트 유형을 다루려면 소프트웨어가 명시적으로 도출해야 합니다. 계정 xpub은 non-hardened 후손을 도출하지만 P2PKH, SegWit, Taproot, 내부 분기, Multisig 서명 임계값은 지정하지 않습니다. 디스크립터가 이 정보를 보완합니다. 서명 장치의 올바른 계정에서 네트워크와 스크립트 유형을 확인해 내보내고, 파생 경로, 즉 시작 키에서 거쳐 가는 단계들을 추측하지 마세요. [1] [4] [7]

HD 지갑은 보통 수신 /0/*와 change, 즉 거스름돈을 위한 내부 /1/*를 나눕니다. 내부 분기가 없으면 지출 후 일부 자금이 사라진 것처럼 보일 수 있습니다. range는 파생 주소의 범위로, 너무 작으면 입금을 놓칠 수 있습니다. next_index는 다음에 생성할 주소를 정합니다. 두 프로그램의 값이 어긋나면 주소를 재사용할 수 있습니다. 활성 디스크립터, 범위, 인덱스를 일치시키세요. 수신 주소는 서명 장치 화면에서 확인해야 합니다. 악성코드는 그럴듯한 잔액을 보여 주면서 주소를 바꿀 수 있습니다. [6] [9]

Bitcoin Core의 importdescriptors는 timestamp로 재검색 시작점을 정합니다. now는 과거 이력을 건너뛰고 0은 Genesis Block부터 검색하도록 요청합니다. range 범위와 과거 블록의 가용성도 중요합니다. active는 해당 디스크립터를 새 주소 생성에 사용할지 정하고, internal은 거스름돈처럼 지갑 내부로 돌아오는 출력을 표시합니다. 오래된 블록을 삭제한 노드는 필요한 이력이 없을 수 있습니다. Rescan은 기존 거래를 찾는 작업일 뿐입니다. 최초 사용 날짜나 높이를 기록하고 복구 결과를 알려진 주소 및 거래와 비교하세요. 화면의 0만으로 판단해서는 안 됩니다. [9] [10]

BIP380은 출력 스크립트 집합을 표현하는 언어를 정의합니다. 예시 wpkh([d34db33f/84h/0h/0h]xpub…/0/*)#checksum에는 스크립트 유형, 마스터 키 지문, 원래 파생 경로, 계정 공개키, 분기, 가변 인덱스, 체크섬이 담깁니다. 그대로 가져올 수 있는 유효한 데이터는 아닙니다. Taproot는 BIP386의 tr()를 사용하고 BIP389는 한 표현에서 여러 경로를 지원합니다. 체크섬은 옮겨 적는 오류를 찾지만 작성자를 인증하지는 않습니다. xprv가 들어간 디스크립터는 비밀키를 포함하므로 관찰용 조정기에 넣으면 안 됩니다. [4] [5] [6] [7]

BIP32에는 중요한 예외가 있습니다. 부모 xpub과 오직 non-hardened 단계로 파생한 후손의 개인키가 함께 있으면 부모 개인키를 계산할 수 있습니다. xpub만으로는 부족하며 두 정보의 조합이 위험합니다. 내보낸 계정 위의 hardened 단계는 공격이 그 경계를 넘지 못하게 합니다. 관찰 지갑, 해당 데이터베이스, 함께 사용하는 PSBT 파일에 xprv, seed, 개인키를 절대로 넣지 마세요. [1]

Multisig 관찰에는 서명 임계값, 스크립트 유형, 각 공동 서명자의 xpub, 키의 출처와 순서, 두 주소 분기가 필요합니다. xpub 하나로는 충분하지 않습니다. seed가 온전해도 디스크립터를 잃으면 복구가 어려워질 수 있습니다. 순서나 스크립트를 감싸는 방식이 달라지면 다른 주소가 나올 수 있기 때문입니다. 모든 서명 장치에서 규칙과 예시 주소를 확인하세요. 체크섬이 있는 디스크립터나 표준 구성을 백업하고, 그것이 공동 서명자 사이의 관계도 드러낸다는 점을 고려하세요. [4] [11]

개인키와 별도로 두 분기의 디스크립터, 키 출처, 네트워크, 생성 날짜나 높이, 범위, 인덱스, 라벨, Multisig 규칙을 보관하세요. BIP329는 라벨을 옮기며 디스크립터나 이력을 대신하지 않습니다. 별도 프로필이나 테스트 네트워크에서 공개 구성을 가져오고 이력을 검색한 뒤, 두 분기의 옛 주소와 예상 UTXO를 비교하세요. PSBT를 준비해 지정 장치로 서명하고 전파 전에 결과를 확인합니다. Watch-only는 관찰과 준비를 위한 것이며 지출 권한을 주지 않습니다. [3] [9] [12]