nBits

비트코인은 헤더 안에 256비트 목표값이 필요하지만 그 값을 위해 32바이트를 할애할 수 없으므로, 반올림한 값을 4바이트에 저장합니다. 첫 번째 바이트는 지수이고 나머지 3바이트는 계수이며, 목표값은 계수에 256의 (지수 빼기 3) 제곱을 곱한 값입니다. 모든 노드가 자신이 기대하는 값을 다시 계산하므로, 규칙이 허용하는 것보다 쉬운 목표값을 주장하는 헤더는 즉시 거부됩니다.

작동 방식

nBits는 지수 1바이트 뒤에 계수 3바이트가 오는 형태로 읽히며, 둘을 결합해 완전한 256비트 숫자를 만듭니다.

제네시스 블록이 담고 있는 값인 0x1d00ffff를 봅니다. 지수는 0x1d이며 이는 29이고, 계수는 0x00ffff이며 이는 65,535입니다. 따라서 목표값은 65,535에 2의 208 제곱을 곱한 값이며, 이 숫자는 16진수 영 여덟 개, 그다음 ffff, 그다음 64자리를 채우는 영으로 표기됩니다. 이것이 메인넷이 허용하는 가장 쉬운 목표값이고, 난이도 1의 정의입니다.

사람들을 헷갈리게 하는 두 가지 특이점이 있습니다. 첫째는 정밀도입니다. 계수가 24비트에 불과하므로 임의의 256비트 숫자를 표현할 수 없어, 부호화된 목표값은 항상 반올림된 값이며, 목표값에서 nBits로 갔다가 다시 목표값으로 돌아오는 왕복이 항상 출발값을 되돌려주지는 않습니다. 둘째는 부호 비트입니다. 계수의 최상위 비트가 설정되어 있으면 그 값은 음수로 취급되므로, 부호화하는 쪽은 계수를 1바이트만큼 내리고 지수를 올려 보상합니다. 그래서 제네시스 값이 더 뻔해 보이는 0x1cffff00이 아니라 0x1d00ffff로 읽히고, 계수 안의 선행 0바이트가 버그가 아니라 정상인 것입니다.

직렬화된 헤더에서 이 필드는 바이트 오프셋 72에 위치하며 리틀 엔디언으로 기록되므로, 그 4바이트는 디스크와 네트워크상에서 ff ff 00 1d로 나타납니다.

확인할 수 있는 곳

nBits는 여러 다른 이름으로 오가며, 이를 둘러싼 혼란의 대부분이 여기서 나옵니다.

블록 탐색기는 이를 "bits"로 표시하고 더 읽기 쉬운 난이도 수치 옆에 16진수 값을 출력합니다. Bitcoin Core RPC getblock은 이를 "bits"로 반환하고, getblocktemplate는 후보 헤더가 넘어서야 하는 요건으로서 이를 채굴 소프트웨어에 넘깁니다. 소스 코드에서는 CBlockHeader의 nBits 멤버이며, arith_uint256::SetCompact와 GetCompact가 변환합니다. 채굴 풀은 이를 거의 드러내지 않습니다. Stratum은 작업 알림 안에 같은 4바이트를 기계로 보내고, 펌웨어는 그 의미를 생각할 필요가 전혀 없습니다.

이 필드는 또한 연속적으로가 아니라 일정에 따라 바뀝니다. 2,016개 블록의 창 전체 동안 고정되어 있으며 난이도 재조정에서만 새 값을 가지므로, 한 시간 간격으로 채굴된 두 블록은 그 사이에 재조정이 끼어들지 않았다면 동일한 nBits 필드를 지닙니다.

nBits vs 목표 임계값

nBits는 부호화이고, 목표 임계값은 그것이 부호화하는 숫자입니다. 노드는 헤더 해시를 nBits와 직접 비교하지 않습니다. 먼저 4바이트를 완전한 256비트 목표값으로 펼친 다음, 해시가 그 값 이하에 있는지 확인합니다. nBits를 목표값 자체로 취급하는 것은 대화에서는 괜찮지만 코드에서는 틀립니다. 1단위만 차이 나는 두 nBits 값이 디코딩되면 목표값이 엄청난 절대량만큼 달라지기 때문입니다.