BIP는 Bitcoin Improvement Proposal의 약자입니다. Bitcoin에 관한 기술적 해결책, 절차 또는 중요한 정보를 설명하는 문서입니다. 누구나 검토하고 이의를 제기하며 필요하면 활용할 수 있지만, 문서를 공개한다고 소프트웨어나 네트워크 규칙이 자동으로 바뀌지는 않습니다.
Anna는 컴퓨터에서 결제를 준비한 뒤 다른 제조사의 하드웨어 지갑으로 서명하려고 합니다. 두 프로그램은 서로 주고받는 데이터를 이해해야 합니다. BIP 174는 바로 이 문제를 다룹니다. 아직 완성되지 않은 거래와 서명에 필요한 정보를 전달하는 공통 형식인 PSBT를 설명합니다. 개발자들은 각자 호환되지 않는 형식을 만드는 대신 하나의 문서를 따를 수 있습니다. 이것이 BIP가 필요한 실용적인 이유 중 하나입니다. [8]
번호마다 다루는 일이 다릅니다. BIP39는 복구 단어를 만들고 이를 지갑 키를 파생하는 출발 데이터인 seed로 변환하는 방법을 설명합니다. BIP 141은 네트워크에서 활성화된 뒤 적용되기 시작한 거래 처리 규칙의 변화인 SegWit을 설명합니다. BIP 174는 블록 유효성 규칙을 바꾸지 않고 지갑끼리 서명할 거래를 전달하도록 돕습니다. 반면 BIP 50은 2013년 3월 네트워크가 일시적으로 갈라진 사고의 원인과 해결 과정을 기록합니다. 모든 BIP가 새로운 Bitcoin 규칙을 제안하는 것은 아닙니다. [6] [7] [8] [9]
해결책을 설명하고, 프로그램을 만들고, 사용하는 것은 서로 다른 단계입니다. 설명은 명세, 코드는 구현이라고 합니다. 지갑이 아직 초안인 제안을 시험할 수도 있고, 어떤 문서는 실제 사용되는 프로그램이 전혀 없을 수도 있습니다. 블록 유효성 규칙을 바꾸는 경우에는 해당 소프트웨어가 규칙을 적용하기 시작하는 활성화도 필요합니다. 문서가 공개되었다고 해서 네트워크 규칙을 확인하는 컴퓨터인 자신의 노드가 자동으로 업데이트되지는 않습니다. [7] [10]
번호는 주로 정확한 문서를 찾고 같은 제안을 놓고 이야기하기 위한 표식입니다. 번호가 높다고 더 좋은 제안이거나 권장 업데이트라는 뜻은 아닙니다. 번호가 있는 문서도 미완성으로 남거나 보류될 수 있습니다. 어떤 서비스가 특정 BIP를 지원한다고 홍보한다면, 어떤 기능을 말하는지와 해당 소프트웨어 버전이 정말 그 기능을 제공하는지까지 확인해야 합니다. [2]
작성자는 먼저 이전 작업을 조사하고 개발자들이 공개적으로 이메일을 주고받는 Bitcoin Development Mailing List에서 아이디어를 논의합니다. 긴 문서를 쓰기 전에 의견을 듣다가 문제를 발견할 수도 있습니다. 충분히 다듬은 제안은 GitHub의 공동 저장소 bitcoin/bips에 pull request, 즉 문서 포함 요청으로 제출합니다. 작성자가 번호를 직접 고르지는 않습니다. 편집자가 주제, 형식, 준비 정도를 확인한 뒤 번호를 부여합니다. [1]
BIP Editors는 공개 문서를 관리합니다. 사전 논의, 설명의 명확성, 형식, 라이선스를 확인하고 번호와 기록을 관리합니다. 그렇다고 사용자가 어떤 소프트웨어를 쓰거나 노드가 어떤 규칙을 받아들일지 결정할 권한을 갖는 것은 아닙니다. 저장소에 등록되었다는 사실은 안전성이나 공동체의 동의를 보증하지 않습니다. 실제 사용은 개별 프로젝트와 네트워크 참여자가 결정합니다. [1]
새 BIP가 승인되었다는 기사를 보면 문서를 열어 실제로 무슨 일이 있었는지 확인하세요. 번호만 받은 것인지, 작성자가 작업을 끝낸 것인지, 지원 기능이 이미 사용되는 것인지 구별해야 합니다. 지갑 기능은 공식 문서와 출시 버전에서 근거를 찾고, 네트워크 규칙 변경은 활성화 조건과 진행 상황도 확인하세요. 흥미로운 제안과 지금 사용할 수 있는 기능을 구분하는 방법입니다. [10] [2]
현재 절차는 상태가 Deployed인 BIP 3, Updated BIP Process가 설명합니다. BIP 2를 대체하고 문서 유형과 상태를 간소화했습니다. 그래서 예전 글의 Standards Track이나 Final은 현재 분류와 맞지 않을 수 있습니다. 최신 파일과 변경 이력을 기준으로 읽어야 합니다. 저장소는 제안을 공개하고 보존하는 곳이며 Bitcoin의 미래를 투표로 결정하는 체계가 아닙니다. [1] [5]
Specification은 서로 호환되는 프로그램을 만들 수 있도록 기술 규칙을 설명합니다. 완료 전에는 설계를 어떻게 구현하는지 보여 주는 실제 작동 프로그램이 필요합니다. 이를 참조 구현이라고 합니다. 테스트 벡터, 즉 예시 입력과 예상 결과도 준비해야 합니다. Informational은 정보, 분석 또는 지침을 제공합니다. Process는 BIP 공개 절차처럼 일을 진행하는 방식을 정합니다. BIP 3는 마지막 유형에 속하며 새로운 Bitcoin 거래 형식을 정의하지 않습니다. [1]
Draft는 작업 중인 초안입니다. Complete는 작성자가 계획한 작업을 끝내고 채택을 권한다는 뜻입니다. Deployed는 실제 사용이 입증되었음을 나타냅니다. Process에서는 토론하고 타당한 반론을 처리한 뒤 얻는 폭넓은 합의인 rough consensus의 요건을 충족했다는 뜻일 수도 있으며, 단순한 표 계산은 아닙니다. Closed는 더 이상 적극적으로 개발하거나 추진하거나 사용하지 않는 역사적 문서입니다. 기록에는 남습니다. Deployed라도 모든 지갑이 지원한다는 뜻은 아닙니다. [1]
문서 머리말에는 작성자, 유형, 상태, 번호 부여 날짜, 라이선스와 토론 링크가 있습니다. Requires는 필요한 다른 BIP, Replaces는 대체하려는 제안, Proposed-Replacement는 가능한 후속 제안을 가리킵니다. Complete 상태가 된 뒤의 변경은 날짜와 버전 번호를 붙여 변경 기록인 Changelog에 남깁니다. 머리말의 Version 항목은 문서의 현재 버전을 나타냅니다. 기존 설계와 호환되지 않는 변경은 원칙적으로 새 BIP로 제안해야 합니다. 같은 번호가 조용히 다른 의미로 바뀌는 것을 막기 위해서입니다. [1]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Soft Fork, 합의 규칙, Bitcoin Core, Bitcoin, Hard Fork, BIP 39. 다음 항목에서도 이 글을 참조합니다 Soft Fork, 블록 크기 전쟁, Bitcoin Core, 비트코인 교육.