Gap Limit은 사용하지 않은 주소가 몇 개 연속 나오면 지갑이 더 이상 검색하지 않을지 정하는 값입니다. 백업으로 복원할 때 지갑은 주소를 다시 계산하고 각 주소의 거래 내역을 확인합니다. 방대한 후보를 끝없이 뒤지지 않으려면 멈출 기준이 필요합니다. 그 경계 너머의 입금은 올바른 키를 가지고 있어도 화면에 나타나지 않을 수 있습니다. 한도를 넘었다고 자금이 사라지거나 만들 수 있는 키의 수가 제한되는 것은 아닙니다.
안나는 비트코인을 받고 보내는 앱이나 기기인 지갑을 사용합니다. 다른 사람이 입금할 때 필요한 정보인 수신 주소를 미리 많이 만들었지만 일부는 사용하지 않았습니다. 지갑을 복원하자 몇몇 입금이 보이지 않습니다. 한도가 20인 검색을 생각해 봅시다. 인덱스 0의 주소에는 내역이 있고, 다음 인덱스 1–20에는 없으며, 21에는 입금이 있습니다. 인덱스는 주소의 순서 번호로, 영부터 셉니다. 검색은 빈 구간을 지나면 21에 이르기 전에 멈추므로 그 입금을 놓칩니다. 검색 중 사용한 주소가 나오면 연속 미사용 주소의 개수는 다시 셉니다. 따라서 지갑 전체가 최대 스무 개의 주소만 가질 수 있다는 뜻은 아닙니다. [1] [6]
여기서 미사용이란 지금 돈이 없다는 뜻이 아닙니다. 안나는 입금을 받은 뒤 전부 썼을 수 있습니다. 잔액은 영이 되어도 거래 내역은 남으므로 검색에서는 사용한 주소로 셉니다. BIP 44가 현재 잔액만이 아니라 내역을 확인하는 이유입니다. 빈 주소를 모두 한 번도 쓰지 않은 것으로 취급하면 복원이 너무 일찍 멈출 수 있습니다. 오래전에 다 쓴 입금도 복원한 지갑을 점검하는 데 도움이 됩니다. [1]
BIP 44는 계층형 지갑에서 계정과 주소를 구성하는 표준입니다. 이런 지갑은 키와 주소를 여러 갈래로 나뉘는 나무처럼 정리합니다. Address gap limit 규칙은 입금을 받는 주소의 나열인 외부 수신 분기의 검색 한도를 20으로 정합니다. 이 경계를 넘어 주소를 만들 때는 프로그램이 경고해야 한다고 설명합니다. 이는 복원 방식에 관한 약속이지 네트워크가 거래를 받아들일지 판단하는 합의 규칙이 아닙니다. 다른 지갑은 설정이나 검색 절차가 다를 수 있습니다. 같은 수신 주소를 계속 재사용하라는 권고도 아닙니다. [1]
기존 지갑은 순서상 먼 곳에 미리 만든 주소도 알고 있을 수 있습니다. 그러나 키만 담긴 백업으로 복원한 새 프로그램은 전에 어디까지 만들었는지 모를 수 있습니다. Electrum 문서는 Gap Limit을 넘는 주소가 일반적인 복원에서 자동으로 발견되지 않을 수 있다고 명시합니다. 해결 방법으로 한도를 늘리거나 사용한 위치까지 주소를 더 파생하는 방법을 설명합니다. 적절한 설정은 프로그램과 지갑 종류에 따라 확인해야 합니다. FAQ의 기본값 20은 Electrum 2.0에 관한 설명이며 모든 현재 지갑의 공통값은 아닙니다. [2]
지갑을 정돈된 나무로 생각해 봅시다. 계정은 자금을 묶음별로 나누고, 계정 안에는 여러 주소 분기가 있습니다. BIP 44에서 change=0은 수신 분기, change=1은 자신의 거스름돈 분기입니다. 거스름돈은 결제 후에도 보내는 사람에게 남는 금액입니다. 계정 검색은 계정 0의 외부 분기에서 시작합니다. 내역이 있으면 다음 계정으로 넘어가고, 내역 없는 첫 계정에서 계정 검색을 멈춥니다. 따라서 표준은 이전 계정에 내역이 없으면 새 계정을 만들지 말라고 정합니다. 한 분기의 빈 주소 구간과 건너뛴 빈 계정은 서로 다른 문제입니다. 한도를 늘리는 것만으로 프로그램이 어떤 다른 계정을 검색할지까지 정해지지는 않습니다. [1]
BIP 32는 결정론적 키 파생을 설명합니다. 같은 시작 정보와 같은 경로에서는 같은 키가 나옵니다. Derivation Path는 이 나무를 따라가는 경로입니다. 지출 규칙을 뜻하는 스크립트 유형과 함께 지갑이 추적할 주소를 결정합니다. 따라서 올바른 Seed Phrase, 즉 백업 단어만으로 필요한 정보가 전부 갖춰지는 것은 아닙니다. BIP 39에서는 선택적으로 설정한 passphrase도 키 파생의 출발점인 비밀 정보 seed를 계산하는 데 쓰입니다. passphrase는 앱 비밀번호와 별개인 추가 비밀 문자열입니다. 다른 passphrase는 다른 지갑으로 이어지므로 Gap Limit을 늘려도 해결되지 않습니다. 개인키는 지갑이 자금 지출을 승인하는 디지털 서명을 만들 때 사용하는 비밀 숫자 값입니다. 심화해서 보면 xpub은 다른 공개키를 파생하는 확장 공개키입니다. 주소와 결제를 추적하는 데 도움이 되지만 그것만으로 자금 사용을 승인할 수는 없습니다. 하지만 상위 개인키가 필요한 hardened 파생 단계는 xpub만으로 넘어갈 수 없습니다. 검색 범위를 늘려도 이 능력이 생기지는 않습니다. [4] [5] [6]
Bitcoin Core 29.0은 노드의 프로그래밍 인터페이스인 RPC를 통해 importdescriptors를 제공합니다. Descriptor는 키로 지출 조건과 추적할 주소를 구성하는 방법을 기술합니다. range는 파생할 인덱스 범위이며, 빈 구간을 만나면 멈추는 규칙이 아닙니다. 활성 descriptor의 next_index는 다음 주소를 만들 때 쓸 인덱스를 정합니다. timestamp는 언제부터 거래를 찾을지 정합니다. now는 한 번도 사용하지 않았다고 알고 있는 출력용이며 오래된 입금 복원을 대신하지 않습니다. 문서는 가져온 descriptors 중 가장 이른 timestamp보다 최대 두 시간 앞선 블록과 미확정 거래를 로컬에 보관하는 Mempool도 포함합니다. 주소를 올바르게 파생했어도 해당 기간을 검색하지 않았다면 내역에 보이지 않을 수 있습니다. [3]
안나에게 돌아가 봅시다. 기존 지갑의 수신 주소나 결제 기록이 남아 있다면 새 지갑이 실제로 찾았는지 확인할 수 있습니다. 최종 잔액뿐 아니라 이미 쓴 입금도 비교하면 좋습니다. 더 긴 검색은 빠진 내역을 찾을 수 있지만 시간과 조회가 더 필요합니다. 외부 서버를 쓰면 서로 관련된 주소를 더 많이 알려줄 수도 있습니다. 검색 자체는 돈을 옮기거나 블록체인을 바꾸지 않습니다. 내역이 계속 다르면 한도만 키울 것이 아니라 백업 정보, 계정, 경로, 주소 유형, 과거 데이터의 가용성을 확인해야 합니다. 주소 하나를 찾았다고 복원 전체가 완전하다고 증명되는 것은 아닙니다. [1] [2] [4]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 HD Wallet, Derivation Path, Extended Public Key (xpub), Output Descriptor, Change Address, Seed Phrase. 다음 항목에서도 이 글을 참조합니다 HD Wallet, Derivation Path.