March 2013 Chain Split

2013년 삼월 11일, Bitcoin 0.8을 실행하던 노드가 블록 225 430을 채굴했다. 새 버전은 이를 받아들였지만 0.7.2 이하 일부 노드는 거부했다. 같은 부모에서 해당 블록을 포함한 브랜치와 포함하지 않은 브랜치가 함께 성장했다. 차이는 hash나 proof of work 자체가 아니라 로컬 소프트웨어가 그 블록을 유효하다고 판단하는지에 있었다. [2]

촉발 요인은 단순한 바이트 단위 블록 크기가 아니었다. 블록에는 전례 없이 많은 트랜잭션 입력이 들어 있었고, 구형 노드는 이를 기록하며 Berkeley DB 기본 잠금 수를 소진했다. 필요한 잠금 수는 각 노드의 데이터베이스 페이지 배치에도 좌우되므로, 이전의 최대 크기 테스트 블록은 통과했어도 더 작고 원래는 유효한 블록이 실패할 수 있었다. [1]

Bitcoin 0.8은 블록과 트랜잭션 인덱스를 Berkeley DB에서 같은 잠금 한도가 없는 LevelDB로 옮겼다. 처음에는 해시레이트의 약 60 %가 0.8 브랜치 위에서 작업했지만, 구형 노드는 시작 블록을 거부했기 때문에 그 작업량을 인정하지 않았다. 최중량 체인 규칙은 노드가 먼저 유효하다고 검증한 이력들 사이에서만 선택하므로 이 불일치를 혼자 해결할 수 없었다. [1]

Pieter Wuille는 긴급 경보를 공개하고 상점에 결제 처리를 중단하라고 권고했다. 개발자와 운영자의 논의 뒤 Eleuthria로 알려진 Michael Marsee가 이끄는 BTCGuild와 Marek Palatinus의 Slush Pool은 Bitcoin 0.7로 돌아갔다. 기술적으로 최신인 브랜치를 영구히 틀렸다고 선언하려는 것이 아니라, 널리 배포된 두 버전이 모두 검증할 수 있는 이력에 작업량을 신속히 모으려는 조치였다. [3]

호환 브랜치가 누적 작업량에서 앞서자 0.8 노드는 그쪽으로 reorg했고, 원래 0.8 브랜치에서만 채굴된 블록은 stale 상태가 되었다. BIP 50은 분열 중 최소 한 건의 큰 double spend를 기록한다. 사후 보고서는 도난 목적이 아닌 실험이었다고 설명한다. 그럼에도 이 사건은 체인 끝이 불확실할 때 거래소와 상점이 입금을 멈추고 추가 확인을 기다리는 이유를 보여 줬다. [1]

Bitcoin Core 0.8.1은 2013년 삼월 18일 공개되었다. 삼월 21일부터 오월 15일까지 적용되어 구형 peer가 처리하지 못하는 블록의 수용을 막는 임시 규칙과 블록 225 430의 내장 checkpoint를 추가했다. 사후 보고서는 10 000개 잠금의 추정 한도, 500 000바이트 채굴 한도, Berkeley DB 잠금 한도를 537 000으로 둔 backport도 명시한다. [4]

임시 호환성은 최종 상태가 아니었다. 구형 노드 운영자는 오월 15일까지 0.8.1, 갱신된 backport 또는 명시적으로 높인 잠금 한도로 옮겨야 했다. 채굴자는 조정된 날짜 전에 한도를 올려 네트워크의 나머지가 거부할 블록을 다시 만들지 않도록 해야 했다. 2013년 팔월 16일 네트워크는 블록 252 451을 받아들이며 패치되지 않은 노드를 영구히 뒤에 남겼다. [5]

이 사건은 합의가 블록 형식의 설명만으로 이루어지지 않음을 보여 줬다. 검증 코드, 라이브러리, 데이터베이스 트랜잭션, 오류 경로, 경계 테스트의 정확한 동작까지 포함한다. 후속 조치에는 testnet에서의 스트레스 트랜잭션 생성, 서비스 경보 개선, 긴 사이드 브랜치 감시, 더 신중한 변경 조정이 포함되었다. 빠른 복구는 당시 네트워크가 연락 가능한 소수 개발자와 대형 pool에 의존했다는 사실도 드러냈다. [1]