Bitcoin Whitepaper

Whitepaper는 문제를 제시하고 해결책을 제안하는 문서입니다. Bitcoin 문서는 일상적인 질문에서 시작합니다. 인터넷으로 돈을 보낼 때 우리 사이에 반드시 은행이나 다른 관리자가 있어야 할까요? Satoshi는 2008년 10월 31일 암호학 메일링 리스트에 제안을 보내고 본문 링크를 넣었습니다. bitcoin 가격이나 투자 수익을 약속한 것이 아닙니다. 지급 내역에 관한 결정을 한 회사에 맡기지 않고 돈을 받는 방법을 설명했습니다. 이 문제가 문서 전체를 이어 줍니다. [2] [1]

보내는 사람이 같은 돈을 쓰는 서로 다른 두 지급에 서명했다고 상상해 보세요. 한 수취인은 첫 지급을, 다른 수취인은 둘째 지급을 봅니다. 두 사람 모두 올바른 디지털 서명, 즉 지급할 권한의 증거를 확인할 수 있지만 둘 다 돈을 받을 수는 없습니다. 인터넷 데이터는 쉽게 복사되며 서명만으로는 해결되지 않습니다. 그래서 2절은 쓸 권한과 어느 지급이 공통 기록에 들어갈지를 구분합니다. Bitcoin은 서명에 공개 기록을 더해 이미 쓴 자금을 알아볼 수 있게 합니다. [1]

3–5절은 지급을 블록으로 묶는 방법을 설명합니다. 새 블록은 데이터의 짧은 디지털 지문인 hash로 앞 블록을 가리킵니다. 오래된 기록을 바꾸면 지문도 달라져 연결이 깨집니다. Proof of Work는 여기에 비용이 드는 계산 작업을 더합니다. 받아들일 수 있는 블록을 만들려면 수많은 시도가 필요하지만 결과 확인은 쉽습니다. 경쟁하는 갈래에서는 만든 계정이나 IP 주소 수가 아니라 규칙을 지키는 기록에 누적된 작업량이 중요합니다. 문서는 이를 가장 긴 체인이라고 부릅니다. 아무리 많은 작업도 무효 거래를 유효하게 만들지는 못합니다. 체인은 사건 순서를 정할 뿐 각 지급의 정확한 시각을 정하지도 않습니다. [1] [3]

컴퓨터와 전기에는 비용이 듭니다. 따라서 6절은 경제적 동기를 더합니다. 받아들여진 블록의 작성자는 새로 발행된 코인과 그 블록 지급의 수수료를 받을 수 있습니다. 수수료는 거래가 소비하는 가치와 새 출력 가치의 차이이며 무에서 추가로 만든 코인이 아닙니다. 문서는 미래에 수수료만으로 보상을 충당하는 상황도 생각합니다. 다만 제안의 경계를 알아야 합니다. 정확한 2,100만 한도나 210,000블록마다 반감한다는 규칙은 whitepaper에 없습니다. 이 규칙은 다른 Bitcoin 자료에서 확인해야 합니다. [1] [3]

누구나 모든 거래를 내려받아 검증하고 싶은 것은 아닙니다. 8절은 SPV, 간소화된 지급 검증을 제안합니다. 클라이언트는 블록의 핵심 요약 정보인 헤더와 Merkle 증명을 얻습니다. 후자는 hash를 연결해 특정 거래가 블록에 포함되었음을 보여 줍니다. 어떤 기록이 책에 있는지 확인하는 것과 책 전체의 정확성을 점검하는 것의 차이와 같습니다. 포함 증명만으로 모든 규칙이나 전체 지출 내역을 확인하지는 않습니다. Whitepaper는 이 한계를 인정합니다. 간소화된 클라이언트는 직접 거래를 검증하는 Full Node보다 특정 공격에 더 취약합니다. [1]

은행에서는 지급 기록 대부분이 공개되지 않습니다. Bitcoin은 공통 기록이 필요하므로 다른 방식으로 프라이버시를 보호해야 합니다. 10절은 지급과 키 보유자의 신원을 분리하고 다음 거래에 새 키 쌍을 사용하라고 권합니다. 동시에 약점도 인정합니다. 지급끼리 연결할 수 있습니다. 한 기록에서 사람의 신원이 밝혀지면 다른 지급도 드러날 수 있습니다. 새 주소는 마법의 변장이 아닙니다. 일부 연결을 줄여도 공개 기록에 남은 정보나 거래 상대가 아는 사실까지 지우지는 못합니다. [1]

11절은 공격자가 정직한 참여자들의 체인을 따라잡을 가능성을 묻습니다. 한쪽이 앞서 있지만 양쪽 모두 계속 노력하는 경주를 떠올려 보세요. 설명된 모형에서는 공격자의 계산 능력 비중이 작고 체인의 선두 격차가 클수록 추격 성공 가능성이 낮습니다. 계산은 가정과 포아송 근사, 즉 일정 기간 발생하는 사건 수를 추정하는 수학적 단순화를 사용합니다. 모든 실제 공격을 예측하지는 않습니다. 따라서 표에서 숫자 하나를 뽑아 모든 지급에 안전한 확인 횟수라고 할 수 없습니다. [1]

문서는 원래 설계를 설명합니다. 이후 네트워크와 소프트웨어는 발전했습니다. 예를 들어 BIP 141의 제안에 설명된 SegWit은 들어 있지 않습니다. BIP는 개선안을 설명하는 문서이며 공개만으로 자동으로 네트워크 규칙이 되는 결정이 아닙니다. 현재의 기술적 질문에서는 제안, 프로그램, 실제 적용되는 공통 규칙, 거래 전달에 관한 노드의 개별 방침을 구분해야 합니다. 노드가 어느 거래를 전달하지 않다가 나중에 유효한 블록 안에서 받아들일 수도 있습니다. 두 상황은 모순되지 않습니다. [4] [3]

요약과 중앙 관리자 없이 이중 지출을 막는다는 질문부터 읽으세요. 그다음 서명, 공통 기록, 블록 작성에 필요한 작업이 각각 무엇을 보태는지 따라가면 됩니다. 수학에서 막히더라도 처음부터 모든 공식을 이해할 필요는 없습니다. 어떤 공격을 모형화하고 무슨 가정을 쓰는지 먼저 파악한 뒤 세부 내용으로 돌아올 수 있습니다. 원래 이메일은 Satoshi가 언제 제안을 소개했는지 보여 주고 PDF는 논거를 담습니다. 전체에서 떼어 낸 한 문장은 특정 지갑이나 서비스가 안전하다는 증거가 아닙니다. [2] [1]

절 제목을 외우는 것보다 왜 어느 요소도 혼자서는 충분하지 않은지 이해하는 것이 중요합니다. 서명은 권한을 증명하고 공개 기록은 이중 지출 발견을 도우며 Proof of Work는 순서 변경을 어렵게 합니다. 각 요소에는 선행 연구가 있었고 Satoshi도 참고문헌에서 인용합니다. 기여는 결합 방식에 있습니다. 구체적 가정을 갖춘 논리적인 제안으로 읽으면 whitepaper는 여전히 Bitcoin의 사고방식을 이해하는 좋은 출발점입니다. 가격표나 투자 안내서가 아니며, 오늘날 Bitcoin이라는 이름을 쓰는 모든 규칙과 도구의 완전한 명세도 아닙니다. [1]