Saved by bc
비트코인의 키와 주소
비트코인의 키와 주소
readwise.io • 비트코인의 키와 주소
1. Base58 / Base58Check / 체크섬
Q. Base58이랑 Base58Check는 뭐가 달라?
A.
- Base58 = 그냥 “58진법 문자집합”으로 인코딩하는 방식. (0,O,l,I 같은 헷갈리는 문자 제거)
- Base58Check =
데이터 + 체크섬(앞 4바이트)를 붙인 뒤 Base58로 인코딩한 것. - 비트코인에선 타이핑/복사 오류를 잡아내기 위한 목적이 핵심이야.
- 문서에서도 먼저 Base58 인코딩 방법을 예시 숫자 1000으로 설명한 뒤,
이어서 체크섬 아이디어를 소개하고, 마지막에 SHA-256을 두 번 돌린 후 앞 4바이트를 붙여 Base58로 인코딩하는 절차를 Base58Check로 정의해.
- 문서에서도 먼저 Base58 인코딩 방법을 예시 숫자 1000으로 설명한 뒤,
Q. 체크섬(checksum)이라는 말, 직관적으로 어떻게 이해하면 돼?
A.
- “sum을 check한다”는 말 그대로,
- 원본 데이터에서 특정 규칙(예: 전체에 해시 돌림 → 앞 4바이트)으로 뽑아낸 검증용 요약값을 뒤에 붙여두는 것.
- 나중에 다시 똑같이 계산해봤을 때 붙어있는 값과 다르면 “중간에 뭔가 틀어졌다/오타 났다”는 걸 바로 알 수 있음.
- 문서에서도
1357에 대해1+3+5+7=16을 뒤에 붙여135716으로 쓰고, 뒤의 16으로 입력이 맞는지 확인하는 예시를 통해 감을 잡게 해줘.
Q. WIF는 정확히 뭐를 가리켜? 그냥 Base58Check 결과를 부르는 말이야?
A.
- WIF = Wallet Import Format.
- “아무 데이터나 Base58Check한 것”이 아니라, **‘개인키(및 압축 여부, 네트워크 정보)를 특정 규칙 + Base58Check로 인코딩한 포맷’**을 말해.
- 앞에 0x80(메인넷) 같은 prefix를 붙이고,
- 압축 공개키용이면 0x01을 뒤에 더 붙인 뒤,
- 그 전체에 대해 Base58Check를 적용한 결과가 WIF 문자열.
- 문서에서도 WIF-압축형 예시(KxFC…)를 들고
“네트워크로 전파하려는 목적이 아니라 손으로 옮길 때를 고려한 포맷”이라고 강조해.
2. 개인키 · 공개키 · 주소 관계
Q. 개인키:공개키:주소 = 1:1:1 이라는 설명, 완전히 맞아?
A.
- “순수한 수학적 맵핑” 기준으로는
- 1개의 개인키 → 1개의 공개키 → 1개의 해시 값(예:
RIPEMD160(SHA256(K))) → 그걸 Base58Check하면 1개의 주소. - 그래서 아주 로우레벨에선 1:1:1이라고 말해도 큰 거짓말은 아니야.
- 1개의 개인키 → 1개의 공개키 → 1개의 해시 값(예:
- 하지만 실제 지갑/현대 비트코인 사용 패턴까지 생각하면,
- “하나의 시드/마스터키로부터 굉장히 많은 (개인키, 공개키, 주소) 세트가 파생된다”는 그림이 훨씬 현실적.
- 또 P2PKH, P2SH, Bech32 등 “같은 공개키/스크립트에서 나오는 서로 다른 주소 형식”도 있어서, 넓게 보면 1 공개키 → 여러 타입의 주소로 볼 수도 있어.
Q. “공개키 하나에서 주소가 여러 개 나온다”는 말은 어떻게 이해하면 돼?
A.
- 순수하게 “공개키 한 개”만 놓고 보면,
- P2PKH(1로 시작), P2SH-P2WPKH(3으로 시작), Bech32(‘bc1…’) 등 다른 스크립트/주소 타입으로 감싸는 방식에 따라 여러 주소 형식이 나올 수 있음.
- 하지만 지갑 UX 차원에서 “트랜잭션마다 새 주소”가 나오는 건,
- 보통 HD 지갑에서 새로운 child 공개키를 계속 파생하기 때문이지,
- 단일 공개키 하나를 계속 재포장하는 것만은 아님.
3. HD 지갑, BIP32, “하나의 시드로 여러 주소”
Q. 요즘 지갑은 하나의 개인키(또는 시드)에서 트랜잭션마다 새 주소를 만들어주는데, 이게 HD 구조(BIP32) 때문 맞지?
A.
- 맞아, 네가 이해한 흐름이 매우 정확해.
- 역사적으로 보면:
- 초기(사토시 시대):
- “개인키 : 공개키 : 주소 = 사실상 1:1:1”에 더 가까운 사용.
- 새 주소를 원하면 그냥 새 키쌍을 만들어서 추가로 관리.
- 키 백업이 번거롭고, 구조화가 부족했음.
- BIP32 (HD Wallets) 제안 이후:
- 하나의 마스터 키/시드에서 **경로(path)**를 따라 무수히 많은 child 키들을 파생.
m / purpose' / coin_type' / account' / change / index류의 구조가 생기고,- 지갑이 자동으로 index를 올려가며 **“거래마다 새 주소”**를 생성해 프라이버시를 개선.
- 초기(사토시 시대):
- 그래서 네 요약:
“비트코인 초기에는 포대님 말씀대로 그러다가, 나중에 계층 결정 지갑 구조(HD)가 나오면서 master/child 개념이 생기고, 요즘엔 하나의 시드/마스터로 트랜잭션마다 새 주소를 만든다”
→ 방향성/맥락 모두 적절한 이해야.
4. 공개키와 주소 생성 파이프라인 (문서 기준 핵심만)
Q. ‘공개키에서 주소가 나온다’는 걸 문서 기준으로 최소 단위로 정리하면?
A.
- 공개키 K (압축/비압축)
SHA256(K)- 그 결과에
RIPEMD160()적용 →A = RIPEMD160(SHA256(K)) - 네트워크 prefix 붙임 (메인넷 P2PKH = 0x00 등)
- 이 전체에 대해 SHA256 두 번 → 앞 4바이트 = checksum
prefix + A + checksum을 Base58 인코딩 → 사람이 보는 비트코인 주소
- 이 pipeline을 문서에서도 SHA256 → RIPEMD160 → Base58Check 흐름로 딱 정리해줘.
5. 내일 다시 볼 때 떠올리면 좋은 “키워드 메모”
- Base58 = 헷갈리는 문자 제거 + 58진법 인코딩
- Base58Check =
(prefix + data) + sha256(sha256(...)) 앞 4바이트후 Base58 - 체크섬 = “내가 맞게 썼나?”를 나중에 재계산해서 검증하는 요약값
- WIF = “개인키를 사람이 안전하게 들고 다니기 좋은 Base58Check 포맷”
- 순수 이론:
개인키 → 공개키 → 해시 → 주소는 1:1:1 - 실제 지갑: 하나의 시드/마스터에서 child 키들을 무한히 파생(BIP32 HD)
- 거래마다 새 주소 = HD 파생 + 프라이버시 강화 전략
크기의 한계를 극복하기 위해 비트코인에서는 압축 공개키를 사용한다.
readwise.io • 비트코인의 키와 주소
비트코인의 1byte는 1byte가 아니다. 1byte 곱하기 전세계 노드수이므로 2025년 기준 1byte는 수만byte와 같다.
트랜잭션 수수료는 비트코인의 양이 아닌 트랜잭션에 사용되는 용량 기준이므로 용량이 돈임.
그래서 비트코인은 1byte 줄이는데에 진심이며, 온갖 수학적 고민이 담겨 있다.
Base58Check 인코딩 만약 여러분의 개인키가 아래와 같다고 해보자 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd 소문자 엘과 대문자 아이, 숫자 영과 대문자 오를 구분하는것이 너무 어렵다.
혹시나 타이핑 오류가 나지 않았을지 걱정된다.
그래서 아래와 같이 개인키를 표현할 수 있다.
KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ 여기엔 대문자 오, 대문자 아이, 소문자 엘, 숫자 영이 없다.
타이핑 오류를 방지해준다.
readwise.io • 비트코인의 키와 주소
Base58이 있고, Base58Check가 있음. 뒤에꺼는 체크섬이 추가됨.