개발자 참고 자료
이곳은 참조 계층입니다. 무언가를 구매하는 과정이 아니라 비트코인 코드를 읽거나 원시 트랜잭션을 디코딩할 때 마주치는 P2P 메시지 유형, 스크립트 옵코드, RPC 필드 이름, 프로토콜 구조를 다룹니다.
이 분야가 존재하는 이유는, 이러한 용어의 대부분을 아직도 찾아보는 곳인 Bitcoin Core 개발자 용어집이 2021년 이후 거의 바뀌지 않았고 항목 여러 개가 더 이상 소프트웨어를 설명하지 않기 때문입니다. 그 용어집이 문서화한 BIP70 결제 프로토콜은 Bitcoin Core 0.20.0 버전에서 삭제되었습니다. 블룸 필터 항목은 Core가 0.19.0에서 기본적으로 제공을 중단한 메커니즘을 설명합니다. 그런 항목은 모두 현재 코드가 하는 일에 맞춰 여기에서 다시 쓰였으며, 정정 사실을 조용히 반영하지 않고 명시합니다.
용어는 몇 가지 무리로 나뉩니다. inv, getdata, MSG_FILTERED_WITNESS_BLOCK 같은 메시지 유형은 피어 투 피어 프로토콜에 속합니다. OP_RETURN과 OP_CHECKSIG 같은 옵코드는 Script에 속합니다. 서명 해시 플래그, 시퀀스 번호, 락타임은 서명이 실제로 무엇을 확정하는지를 좌우합니다. X509와 결제 요청 항목은 역사적인 것이며, 그렇다고 스스로 밝히고 있습니다.
대부분의 독자는 이 분야가 필요하지 않을 것이며, 그래도 괜찮습니다. 정확한 필드 이름을 검색했을 때 한 줄짜리 토막글이 아니라 그것을 정확하게 설명하는 페이지에 도착하도록 하기 위해 마련되었습니다.
용어 47개. 마지막 검토일은 2026년 10월 29일입니다.
개발자 참고 자료 분야의 용어
- 결제 프로토콜(BIP70)별칭: Payment protocol (BIP70)결제 프로토콜(BIP70)은 단순한 주소를 서명되고 인증서로 뒷받침되는 결제 요청으로 대체하려 했던 비트코인의 시도였으며, Bitcoin Core는 버전 0.20.0에서 마지막 남은 지원을 제거했습니다.
- 내부 바이트 순서내부 바이트 순서는 비트코인이 직렬화된 구조 내부에서 사용하는 배치 방식입니다. 정수는 최하위 바이트부터 기록하고, 해시 다이제스트는 SHA-256이 생성한 순서 그대로 기록합니다.
- 디스크립터 체크섬디스크립터 체크섬은 출력 디스크립터에서 해시 기호 뒤에 붙는 8자리 코드로, 지갑이 잘못된 키를 가져오기 전에 입력 오류와 복사 오류를 잡아내는 BCH 부호입니다.
- 레이블비트코인 URI의 레이블은 대금을 받는 사람이나 사업체의 이름을 나타내며, 지갑에서는 주소나 트랜잭션에 붙이는 개인 메모입니다.
- 루트 인증서루트 인증서는 인증서 체인의 맨 위에 있는 자체 서명된 신뢰의 기준점이며, 신뢰되는 이유는 오직 운영체제나 브라우저 공급업체가 그것을 넣어 두었기 때문입니다.
- 리딤 스크립트별칭: Redeem script리딤 스크립트는 pay-to-script-hash 출력 뒤에 숨겨진 전체 지출 계약으로, 지출하는 쪽이 서명 스크립트 끝에 제시하며, 해시를 계산해 일치하는지 확인합니다.
- 리프 인증서리프 인증서는 실제로 접속한 서버가 제시하는 최종 개체 인증서이며, 도메인 이름에 대한 통제권을 증명할 뿐 그 배후의 사람들에 대해서는 아무것도 증명하지 않습니다.
- 서명 스크립트별칭: Signature script, scriptSig서명 스크립트는 입력이 자신이 사용하는 출력의 공개 키 스크립트를 충족하기 위해 담고 있는 잠금 해제 데이터이며, 현대의 SegWit 입력에서는 비어 있습니다.
- 영수증비트코인에서 영수증은 결제가 이루어졌다는 증거로 보관하는 모든 것을 뜻합니다. BIP70에서는 판매자가 서명한 확인서였고, 실제로는 트랜잭션 ID입니다.
- 오피코드(Opcode)별칭: Opcode, 데이터 푸시 opcode, 비데이터 푸시 opcode오피코드(Opcode)는 비트코인 스크립트의 1바이트 명령으로, 검증 노드에 다음에 무엇을 할지, 즉 데이터를 스택에 푸시할지 이미 스택에 있는 값에 대해 하나의 연산을 수행할지를 알려 줍니다.
- 위트니스 스크립트위트니스 스크립트는 P2WSH 출력의 실제 지출 조건을 담고 있으며, 해당 바이트가 통상 비용의 4분의 1로 계산되는 위트니스 안에서 이동합니다.
- 인증서 체인인증서 체인이란 서버가 제시하는 인증서를 사용자의 기기가 이미 신뢰하는 루트 인증서까지 연결하는 순서 있는 인증서 목록이며, 각 연결 고리는 다음 연결 고리에 의해 서명됩니다.
- 점 함수점 함수는 secp256k1의 생성점에 개인 키를 곱하여 개인 키를 공개 키로 바꾸며, 모든 비트코인 주소가 기반으로 삼는 단방향 단계입니다.
- 중간 인증서중간 인증서는 루트 인증서와 리프 인증서 사이에 위치하며, 루트 인증서가 이 인증서에 서명하고 이 인증서가 리프 인증서에 서명합니다. 따라서 루트 인증서의 개인 키는 오프라인에 보관되어 사용되지 않을 수 있습니다.
- Bitcoin Script별칭: ScriptBitcoin Script는 모든 비트코인 출력이 담고 있는 작은 스택 기반 언어로, 해당 코인을 다시 사용할 수 있기 전에 누군가가 충족해야 하는 조건을 정합니다.
- Bitcoin URI별칭: BIP21Bitcoin URI는 결제 정보를 bitcoin:로 시작하는 하나의 클릭 가능한 문자열에 담으며, 주소와 금액, 레이블을 포함할 수 있습니다.
- CompactSize별칭: Compact size unsigned integer, VarInt, 컴팩트사이즈CompactSize는 비트코인이 직렬화된 데이터에서 개수와 길이를 앞에 붙일 때 사용하는 가변 길이 정수로, 253 미만의 값에는 1바이트가 들고 나머지 값에는 최대 9바이트가 듭니다.
- MSG_BLOCKMSG_BLOCK는 인벤토리 유형 2로, 노드가 getdata 메시지에 넣어 상대 피어에게 해시로 블록 하나 전체를 요청할 때 쓰는 코드입니다.
- MSG_CMPCT_BLOCKMSG_CMPCT_BLOCK는 인벤토리 유형 4로서, 요청 전용 코드입니다. 이 코드는 공지 메시지에 절대 나타나지 않으며, 먼저 이를 수락한 상대방에게 보내는 getdata 메시지 안에서만 유효합니다.
- MSG_FILTERED_WITNESS_BLOCK필터링된 위트니스 블록 유형은 BIP144의 예약 목록과 Bitcoin Core의 소스 enum에 들어 있지만, 양쪽 모두에 이를 뒷받침하는 구현은 없습니다.
- MSG_TXMSG_TX는 인벤토리 항목을 트랜잭션으로 표시하며, 유형 코드는 1이고, 확인되지 않은 결제가 상대 피어 누구도 그 내용을 보기 전에 피어들에게 알려지는 방식입니다.
- MSG_WITNESS_BLOCK위트니스 블록 인벤토리 유형은 세그윗을 지원하는 노드가 서명을 제거하는 대신 모두 붙인 확장 직렬화 형식으로 블록을 요청하는 방식입니다.
- MSG_WITNESS_TX위트니스 트랜잭션 요청은 getdata로 전송되며, 피어에게 지정된 트랜잭션을 서명 데이터를 제거하지 않고 그대로 붙인 채로 반환하라고 지시합니다.
- OP_CHECKMULTISIGOP_CHECKMULTISIG는 공개 키 목록에 대해 서명 그룹을 한 단계로 검증하며, 일괄 검증을 막기 때문에 Taproot 지출에서는 전혀 사용할 수 없습니다.
- OP_CHECKSIGOP_CHECKSIG는 스택에서 공개 키와 서명을 꺼내 그 서명이 이 트랜잭션에 대한 것인지 검증하며, 이것이 바로 본인이 코인을 소유하고 있음을 실제로 증명하는 검사입니다.
- OP_DUPOP_DUP는 스택 맨 위 항목을 복사해 두 번 사용할 수 있게 하며, 그래서 표준 pay-to-public-key-hash 스크립트는 공개 키를 해시하는 동시에 그 키에 대해 검증할 수 있습니다.
- OP_EQUALOP_EQUAL은 스택 맨 위의 두 항목을 바이트 단위로 비교해 참 또는 거짓 결과를 푸시하며, 모든 pay-to-script-hash 출력에서 마지막 오피코드입니다.
- OP_EQUALVERIFYOP_EQUALVERIFY는 스택 최상단의 두 항목을 비교하고, 두 값이 다르면 스크립트를 즉시 종료하며, 레거시 지출에서 올바른 공개 키를 제시했는지는 바로 이 방식으로 증명됩니다.
- OP_HASH160OP_HASH160은 스택 맨 위 항목에 SHA-256을 적용한 뒤 그 결과에 RIPEMD-160을 적용하여 20바이트 다이제스트를 남기며, 이는 1 또는 3으로 시작하는 모든 주소 안에 담긴 동일한 지문입니다.
- OP_RETURNOP_RETURN은 트랜잭션 출력을 증명 가능하게 사용 불가능한 상태로 만드는 오피코드이며, 이를 통해 유통 중인 코인의 집합을 비대하게 만들지 않으면서 소량의 임의 데이터를 블록체인에 기록할 수 있습니다.
- OP_VERIFYOP_VERIFY는 스택의 최상단 항목을 꺼내고, 그 항목이 참이 아니면 스크립트 전체를 중단시키며, 이로써 비트코인 스크립트의 모든 검사는 반드시 충족해야 하는 요건이 됩니다.
- PaymentDetailsPaymentDetails는 실제로 결제 내용을 기술한 BIP70 내부 메시지로, 어느 출력으로 지불할지, 얼마를 지불할지, 요청이 언제 만료되는지, 서명된 트랜잭션을 어디로 보낼지를 담고 있었습니다.
- PaymentRequestPaymentRequest는 BIP70의 외곽 봉투입니다. 직렬화된 PaymentDetails 바이트 열과 인증서 체인, 서명을 함께 감싸므로, 지불하는 쪽이 누가 요청했는지 확인할 수 있었습니다.
- PKI별칭: 공개 키 기반 구조PKI, 즉 공개 키 기반 구조는 인증 기관, 인증서, 신뢰 저장소로 이루어진 체계로, 소프트웨어가 공개 키에 붙은 이름이 실제로 그 키의 것인지 판단할 수 있게 해 줍니다.
- PP amountPP amount는 BIP70 출력 안에 있던 사토시 단위 필드이며, 판매자가 결제자가 보낼 금액을 정하게 하려는 경우 0으로 설정되었습니다.
- PP expiresPP expires는 BIP70 PaymentDetails 메시지에서 선택적으로 쓰이던 Unix 타임스탬프로, 해당 시점이 지나면 지갑이 요청을 더 이상 처리하지 않도록 지시했습니다.
- PP memoPP memo는 BIP70에서 판매자, 지불인 또는 수신 확인 서버가 사람이 읽을 수 있도록 결제에 첨부할 수 있었던 UTF-8 자유 텍스트 메모였습니다.
- PP merchant dataPP merchant data는 BIP70 상인이 결제 요청에 넣고 그대로 돌려받던 불투명한 바이트 문자열로, 들어오는 코인을 주문과 대조할 수 있게 했습니다.
- PP pki dataPP pki data는 BIP70 결제 요청에서 판매자의 인증서를 담던 필드로, DER로 인코딩되었고 리프 인증서가 먼저 오며 그 뒤에 중간 인증서가 따르고 루트 인증서는 빠져 있었습니다.
- PP pki typePP pki type은 BIP70 결제 요청에서 판매자가 어떻게 서명했는지를 밝히던 한 단어 문자열이었습니다. 값은 none, SHA-256을 사용하는 x509, SHA-1을 사용하는 x509였습니다.
- PP scriptPP script는 지불인이 그대로 재현해야 했던 원시 잠금 스크립트를 담은 BIP70 출력의 필수 필드였으며, 이는 트랜잭션 출력에 최종적으로 남는 것과 동일한 바이트입니다.
- Pubkey 스크립트별칭: scriptPubKey, 잠금 스크립트, Pubkey scriptPubkey 스크립트는 모든 트랜잭션 출력에 붙는 짧은 비트코인 스크립트이며, 해당 출력의 코인이 다시 이동하려면 충족해야 하는 조건을 명시합니다.
- R 파라미터R 파라미터는 결제 주소를, 지갑이 서명된 요청을 가져오는 데 사용할 것으로 기대되는 URL로 대체하는 비트코인 URI에 대한 BIP72 추가 사항입니다.
- RPC 바이트 순서RPC 바이트 순서는 비트코인 소프트웨어가 32바이트 해시를 표시하는 역순 방식이며, 지갑이나 블록 탐색기에서 복사하는 모든 트랜잭션 ID가 취하는 형식입니다.
- SSL 서명SSL 서명은 BIP70이 PaymentRequest를 웹 서버의 인증서 키로 서명한 바이트들에 붙인 이름이며, 이 명칭은 쓰일 당시부터 이미 잘못된 이름이었습니다.
- URI QR 코드URI QR 코드는 bitcoin: URI를 부호화한 정사각형 흑백 무늬로, 원래는 직접 입력해야 할 주소와 금액을 카메라로 읽을 수 있게 해 줍니다.
- X.509 인증서별칭: X509 인증서X.509 인증서는 공개 키를 이름 및 유효 기간과 결합한 서명된 파일이며, 거래소에 접속할 때 이루어지는 모든 HTTPS 연결의 기반이 되는 형식입니다.
나머지 13개 분야
- 기본 용어비트코인이란 무엇인지, 사토시란 무엇인지, 그리고 용어집의 나머지 항목이 기대고 있는 몇 가지 핵심 개념.
- 주소와 키코인이 보내지는 곳, 개인 키가 실제로 통제하는 것, 그리고 하나의 시드에서 수천 개의 주소가 만들어지는 방식.
- 지갑과 수탁핫월렛, 콜드 스토리지, 수탁형, 멀티시그가 각각 누가 코인을 옮길 수 있는지를 어떻게 바꾸는지.
- 프라이버시와 보안사람들의 비트코인을 노리는 공격과, 이를 막는 습관과 도구.
- 트랜잭션과 수수료비트코인 트랜잭션의 구성 요소, 비용이 그만큼 드는 이유, 멈춘 트랜잭션을 풀어 주는 방법.
- 구매와 거래소주문 유형, 스프레드, 수수료 체계: 거래소가 수수료를 부과할 때 쓰는 용어.
- 시장과 투자시가총액, 변동성, 현물 ETF. 가격 전망은 빼고 가격에 관한 용어만 다룹니다.
- 채굴과 합의새 블록이 만들어지는 방식, 난이도가 조정하는 것, 그리고 관리하는 주체가 없는데도 규칙이 지켜지는 이유.
- 프로토콜과 업그레이드SegWit, Taproot, 소프트 포크, BIP: 비트코인이 어떻게 바뀌고 누가 결정하는지.
- 라이트닝과 레이어 2결제 채널, 인보이스, 라우팅: 블록 공간 비용을 내지 않고 비트코인을 옮기기 위한 방식.
- 규제와 세금KYC, 트래블 룰, MiCA, 양도소득: 본인의 계좌와 세금 신고에 닿는 규칙.
- 문화와 역사Mt. Gox, 제네시스 블록, HODL, 그리고 사람들이 비트코인을 이야기하는 방식을 만든 사건과 은어.
- 노드와 소프트웨어Bitcoin Core, 풀 노드, 프루닝, RPC: 규칙을 집행하는 소프트웨어.
자주 묻는 질문
이 분야는 누구를 위한 것입니까?
비트코인의 소스를 읽거나, 원시 트랜잭션을 디코딩하거나, P2P 프로토콜과 RPC 인터페이스를 다루는 모든 사람을 위한 것입니다. 구매 계층이 아니라 참조 계층이며, 비트코인을 보유하거나 쓰는 데 이 중 어느 것도 필요하지 않습니다.
비트코인 스크립트란 무엇입니까?
코인을 쓸 수 있는지를 결정하는 작은 스택 기반 언어입니다. 의도적으로 반복문이 없으므로 모든 스크립트의 비용을 실행 전에 예측할 수 있습니다. 대부분의 거래는 소수의 표준 패턴 중 하나를 사용합니다.
바이트 순서는 왜 계속 바뀝니까?
비트코인이 해시를 저장하는 순서와 반대 순서로 표시하기 때문입니다. 프로토콜이 쓰는 것은 내부 바이트 순서이고, RPC 출력과 블록 탐색기는 이를 뒤집습니다. 둘을 섞는 것이 고전적인 첫 번째 버그입니다.
권위 있는 문서는 어디에 있습니까?
어느 한 사이트가 아니라 소스와 BIP에 있습니다. 여기의 항목은 명세가 있는 경우 이를 인용하고, 오래된 개발자 문서가 시대에 뒤떨어진 부분은 그대로 반복하지 않고 바로잡습니다.