BIP32는 시드 하나에서 키 나무를 만드는 규격이며, 자식 키를 인덱스 2^31을 경계로 일반과 강화로 나눕니다. 일반 자식은 부모 공개 확장 키만으로 공개키를 계산할 수 있고, 강화 자식은 부모 개인키가 있어야만 계산됩니다. 이 글은 2026-10-27에 연 BIP 32 원문(상태 Deployed)에서 확인한 규칙만 다룹니다.
확인 기준일 2026-10-27 · 다음 확인 예정 2026-11-26
확장 키는 무엇으로 이루어질까?
개인 확장 키는 개인키 k와 32바이트 체인 코드 c의 쌍이고, 공개 확장 키는 공개키 K와 같은 체인 코드의 쌍입니다. 한 부모마다 일반 자식 2^31개와 강화 자식 2^31개를 둡니다.
| 항목 | 명세 내용(절) |
|---|---|
| 일반 자식 인덱스 | 0부터 2^31-1 (Extended keys) |
| 강화 자식 인덱스 | 2^31부터 2^32-1, 표기 iH는 i+2^31 (Extended keys) |
| 공개 부모에서 강화 자식 | CKDpub는 실패를 반환 (CKD functions) |
| 직렬화 길이 | 78바이트: 버전 4, 깊이 1, 부모 지문 4, 자식 번호 4, 체인 코드 32, 키 33 (Serialization format) |
| 마스터 키 | 시드 128~512비트에 HMAC-SHA512, 키 문자열 Bitcoin seed (Master key generation) |
공개 확장 키가 새면 무엇이 위험할까?
원문 Security 절은 부모 확장 공개키와 그 아래 일반 자식의 개인키 하나를 함께 알면 부모 확장 개인키를 아는 것과 같다고 경고합니다. 그래서 강화 키를 계정 수준에 쓰라고 설명합니다. 강화 자식은 공개 부모로부터 계산이 실패하도록 정의되어 이 연결이 끊깁니다.
내 지갑의 경로와는 어떻게 이어질까?
지갑 앱이 보여 주는 경로의 작은따옴표는 강화 단계를 뜻하는 표기입니다. 경로 해석은 같은 시드인데 주소가 다를 때: 파생 경로와 계정 번호 글에, 복구에 필요한 정보 묶음은 출력 디스크립터: 비트코인 지갑 복구에 필요한 정보 글에 있습니다.
자식 키를 계산하는 두 가지 길은?
개인 부모에서 개인 자식을 만드는 CKDpriv는 강화 자식이면 0x00, 부모 개인키, 4바이트 인덱스를 HMAC-SHA512의 입력으로 쓰고, 일반 자식이면 부모 공개키와 인덱스를 씁니다. 결과 512비트를 둘로 나눠 왼쪽 절반은 부모 키에 더하는 값으로, 오른쪽 절반은 새 체인 코드로 씁니다. 값이 곡선 위수 n 이상이거나 자식 키가 0이면 다음 인덱스로 넘어갑니다. 공개 부모에서 공개 자식을 만드는 CKDpub는 같은 계산을 공개키 쪽에서 하므로 일반 자식에서만 성립합니다. 이 차이가 xpub로 주소를 미리 만들 수 있는 이유이자 노출 위험의 출처입니다.
이 글에서 확인하지 못한 것은?
단어 시드 문구로 변환하는 규격, 계정 경로의 관례, 지갑별 구현 차이는 다른 문서의 내용이라 이번에 열지 않았습니다. 원문에는 Wallet structure 절과 시험 벡터가 있으나 그 값을 인용하지 않았습니다. 지갑이 내보내는 xpub를 어디까지 공유해도 되는지는 이 글이 아니라 해당 지갑의 설명과 원문 Security 절을 함께 보고 판단해야 합니다. 요약하면 일반 자식은 공개 정보만으로 이어 가기 편하고, 강화 자식은 개인키 없이는 이어 갈 수 없어 공유 범위를 끊어 줍니다.
자주 묻는 질문
xpub만 공유하면 자금을 잃을 수 있나요?
xpub 자체로는 지출 서명을 만들 수 없습니다. 다만 원문은 일반 자식 개인키 하나가 함께 새면 부모 개인키까지 계산된다고 경고하므로, xpub는 읽기 권한이라도 개인키와 분리해 다룹니다.
강화 키는 공개 확장 키로 주소를 만들 수 없나요?
그렇습니다. 원문에서 공개 부모로부터 강화 자식을 만드는 함수는 실패를 반환합니다.
시드는 몇 비트여야 하나요?
BIP32 원문은 128~512비트를 허용하고 256비트를 권장한다고 적습니다. 단어 형태의 시드 문구는 별도 규격의 내용이라 이 글에서 다루지 않습니다.
