getblocktemplate

일반적인 mode=template 모드에서 페터의 프로그램은 이전 블록, 거래, 허용되는 보상 등의 정보를 받습니다. 이는 작업안이지 이미 발견한 블록이 아닙니다. 소프트웨어는 보상을 배정하는 특별한 첫 거래인 coinbase를 만들고 블록 구성을 마쳐야 합니다. 헤더는 블록 데이터를 짧게 요약한 부분입니다. 소프트웨어는 그런 다음 채굴 목표를 만족하는 헤더의 해시, 즉 숫자로 나타낸 암호학적 지문을 찾습니다. 조건을 만족하는 결과가 계산 작업을 증명하는 Proof of Work가 됩니다. getblocktemplate 자체는 지급 주소를 받거나 채굴기의 계산을 시작하지 않습니다. 정상 응답만으로 페터가 채굴 중이라고 할 수는 없습니다. [1]

노드가 페터의 프로그램이 이해하지 못하는 형식으로 자료를 보낸다고 생각해 봅시다. 그래서 요청의 rules 필드에는 지원하는 규칙을 적습니다. 여기서 확인한 Bitcoin Core v29.0은 segwit을 요구하며, 테스트 네트워크 Signet에서는 signet도 요구합니다. SegWit은 거래 검증 자료의 처리 방식 등을 바꾼 기능입니다. 맞는 단어를 추가하는 것으로는 부족하며, 프로그램이 실제로 처리할 수 있어야 합니다. capabilities는 인터페이스의 다른 기능을 알리는 필드로 rules를 대신하지 않습니다. 정확한 요구 사항은 사용하는 구현과 버전에 따라 달라집니다. [2]

data 필드에는 프로그램 사이에서 전송할 수 있도록 순서를 정한 거래 전체가 들어갑니다. 이렇게 데이터를 배열하는 것을 직렬화라고 합니다. 데이터의 기본 단위인 바이트는 숫자 0–9와 문자 a–f를 쓰는 십육진수로 표현됩니다. 응답에는 거래의 짧은 식별자도 포함됩니다. 기술 명세인 BIP 145에 따르면 txid는 witness 자료를 빼고 계산하지만 hash는 이를 포함합니다. Witness에는 자금을 쓸 권한을 증명하는 서명 등이 들어 있습니다. 블록 헤더의 주 Merkle root는 거래들을 묶어 나타내는 지문이며 witness hash가 아니라 txid를 사용합니다. 필드를 혼동하는 것은 단순한 명칭 문제가 아닙니다. 잘못된 종합 지문이 나와 구성한 블록이 무효가 될 수 있습니다. [3]

페터는 변화가 있었는지 노드에 끊임없이 물을 필요가 없습니다. Long polling은 서버가 이전 자료를 바꾸려 할 때까지 요청을 열린 상태로 둡니다. 프로그램은 longpollid를 받아 그대로 돌려보냅니다. 서버는 그 값으로 프로그램이 어떤 갱신을 기다리는지 구분합니다. 프로그램은 그 안의 문자에서 특정한 의미를 추측해서는 안 됩니다. BIP 22는 긴 응답 대기 시간을 전제로 합니다. 불완전하거나 잘못된 응답이 반복되면 즉시 재시도하는 루프 대신 시도 사이에 간격을 둬야 합니다. 따라서 조용히 기다리는 상태 자체가 장애는 아닙니다. [4]

일반 요청을 반복한다고 매번 새로 선정한 내용을 받는 것은 아닙니다. Bitcoin Core v29.0은 준비된 템플릿을 캐시에 보관합니다. 이전 블록이 달라지거나, 미확인 거래의 로컬 집합인 mempool이 바뀌고 준비 시점부터 오 초를 넘게 지났을 때 다시 구성합니다. 헤더의 시각은 별도로 갱신할 수 있습니다. 따라서 페터가 같은 거래 구성을 다시 받아도 노드가 멈췄다는 뜻은 아닙니다. 이 특정 버전의 동작은 호출마다 고유한 채굴 작업이 생긴다는 보장도 아닙니다. [2]

페터는 블록 구성 방식을 바꾼 뒤, 많은 계산을 하기 전에 오류를 찾고 싶습니다. proposal 모드에서는 전체 블록을 십육진수로 적어 data에 전달합니다. Bitcoin Core v29.0은 Merkle root도 검사하지만, 계산 작업의 증거인 유효한 Proof of Work를 이미 찾았을 필요는 없습니다. 블록안이 노드가 현재 따르는 체인의 마지막 블록을 잇지 않으면 inconclusive-not-best-prevblk를 반환합니다. 이 검사의 전제가 충족되지 않았다는 뜻이지, 유효성을 전부 판정했다는 뜻이 아닙니다. 사전 검사는 블록을 네트워크에 전파하지도 않습니다. [2]

필요한 작업 증명을 찾으면 소프트웨어는 submitblock으로 전체 블록을 제출할 수 있습니다. hexdata에는 헤더나 지문만이 아니라 직렬화한 블록 전체를 십육진수로 담습니다. Bitcoin Core 29 문서에 따르면 수락할 때는 null을, 그 외에는 명세에 따른 문자열 결과를 반환합니다. 선택적인 두 번째 매개변수 dummy는 무시되며 보상을 정하는 데 쓰이지 않습니다. 노드가 수락해도 영구적인 확정이 보장되지는 않습니다. 이후 체인이 발전하면서 어느 가지가 주 체인으로 남는지가 바뀔 수 있습니다. [5]

막 시작한 노드는 필요한 이력을 아직 내려받고 검증하지 못했을 수 있습니다. 주 네트워크인 mainnet에서 Bitcoin Core v29.0은 연결된 피어가 없거나 초기 동기화 IBD(initial block download) 중이면 템플릿 발급을 거부합니다. 이는 현재 네트워크에 맞춰 일할 준비가 되었느냐의 문제이지 특정 블록을 거절한 것이 아닙니다. 따라서 문제를 살필 때는 대기 중인 long poll, 준비되지 않은 노드, 블록안 검사 결과를 구분해야 합니다. 모두 “새 작업이 없다”처럼 보여도 필요한 대응은 다릅니다. [2]