제2장 – 전쟁으로의 행진

한글

책 The Blocksize War의 2장을 아래에 싣습니다. 책 전체는 Amazon에서 구할 수 있습니다. 알려드리자면, 종이책 판매로 생기는 모든 수익의 50%는 분쟁, 전염병, 재난 또는 의료 서비스로부터의 배제로 영향을 받는 사람들에게 의료 지원을 제공하는 자선 단체인 Medecins Sans Frontieres에 기부됩니다.

비트코인의 초기인 2009년부터 2011년 초까지, 전체 생태계는 단 하나의 소프트웨어, 비트코인 클라이언트로만 이루어져 있었습니다. 이 소프트웨어는 처음에는 Microsoft Windows용으로 존재했으며 서명 장치, 풀 노드와 채굴기로 구성되어 있었습니다. 모바일 애플리케이션도, 상점도, 도박 웹사이트도, 다크넷 시장도, 상장지수상품도, 거래소도, 기관 투자자도 없었습니다. 그저 원시적이고 기본적인 소프트웨어 애플리케이션 하나만 있었습니다. 할 수 있는 일은 비트코인을 채굴하고 보내고 받는 것뿐이었습니다. 당시 비트코인은 거의 쓸모가 없었고, 겉보기에는 이 시스템이 별 가치나 잠재력을 가진 것처럼 보이지 않았습니다. 이 분야에 관심을 가지려면 상상력이 있어야 했습니다. 여러 단계 앞을 내다보고 이 시스템이 시간이 지나며 어떻게 발전하고 변할지를 개념화해야 했습니다. 비트코인이 어떻게 진화할지에 대한 가정을 층층이 쌓아 올렸습니다. 이러한 가정 중 다수는 검증된 적도 종합적으로 논의된 적도 없었습니다. 그저 당연한 것으로 받아들여졌습니다. 2015년이 되자 비트코인은 생긴 지 5년 또는 6년이 되었고, 이 분야에 헌신해 온 사람들에게는 하나의 가정을 품기에 꽤 긴 시간이었습니다. 실제로 공동체 안의 많은 사람들은 비트코인이 어떻게 작동하는지에 대해 서로 다르고 충돌하는 가정을 가지고 있었고, 이러한 불일치의 정도는 드러난 적이 없었습니다. 이제 이러한 불일치가 수면 위로 떠오르고 있었고, 비트코인이 이 사람들에게 그토록 큰 의미를 지녔기에 결과는 험악하고 예측할 수 없게 될 수 있었습니다.

비트코인 가격도 크게 올랐으며, 2010년의 사실상 몇 센트에서 2015년 여름에는 1코인당 약 US$220가 되었습니다. 따라서 분쟁의 많은 당사자들은 비트코인에 일찍 투자하여 재정적인 관점에서 상당히 이득을 보았습니다. 그로 인한 좋지 않은 결과로 공동체 안의 일부는 지나치게 자신감을 갖게 되었고, 심지어 약간 오만해지기도 했습니다. 예를 들어 누군가 비트코인 가격이 US$1 미만이던 2011년 초에 투자하기로 결정했다고 해 보겠습니다. 이 투자는 특정한 가정과 특정한 비전에 근거했을 수 있습니다. 그러고 나서 2015년까지 비트코인을 계속 보유하여 투자금이 200배 넘게 늘어나는 것을 보았을 수 있습니다. 이는 사람의 심리에 영향을 줄 가능성이 큽니다. 2011년에 세운 가정이 분명 옳았다고 느끼지 않겠습니까. 결국 그런 큰 수익으로 이어졌기 때문입니다. 이 투자자는 이제 비트코인을 매우 잘 이해하고 앞으로 무엇이 최선인지 안다고 여기게 될 가능성이 크며, 큰 수익을 냈기에 2011년에 비트코인을 분명히 잘 이해했다고 믿습니다. 안타깝게도 사람들은 매우 다르고 충돌하는 비전을 가진 다른 사람들도 2011년 초에 비트코인에 투자했다는 점을 잘 이해하지 못했고, 이로써 다소 결함 있고 편향된 이 논리가 반박됩니다. 종종 사람들은 다른 초기 투자자들이 모두 자신과 동의한다고 그저 가정했고, 블록 크기 전쟁에서 자신과 반대편에 있는 사람들은 신규 참여자라고 여긴 듯했습니다. 이는 블록 크기 전쟁이 왜 그토록 빠르게 격화되고 사나워진 것처럼 보였는지를 설명하는 데 크게 도움이 됩니다.

이 시점에서 초기의 비트코인 역사를 조금 살펴볼 가치가 있습니다. 비트코인이 출시되었을 때 블록 크기 제한은 없었으나, 더 큰 블록, 아마도 32 MB를 초과하는 블록은 시스템을 고장 냈을 가능성이 큽니다. 이 제한은 2010년 여름에 Satoshi가 처음 도입했습니다. 2010년 7월 15일에 Satoshi는 소프트웨어 저장소에 다음 코드 한 줄을 추가했습니다:

static const unsigned int MAX_BLOCK_SIZE = 1000000;5

이 업그레이드를 담은 소프트웨어는 그 뒤 2010년 7월 19일에 출시되었습니다. 새로운 1 MB 제한은 2010년 9월 7일, 블록 높이 79,400(비트코인이 시작된 이후 79,400개의 블록)에 발효되었습니다. 이러한 유형의 업그레이드를 소프트포크라 부르는데, 즉 블록 유효성에 대한 제한을 강화하는 새로운 규칙입니다. 제한을 추가하거나 낮추면 규칙이 강화되므로 소프트포크입니다. 제한을 올리면 규칙이 완화되므로 하드포크로 알려져 있습니다. 하드포크가 일어나면 모든 사람이 새로운 체인을 따르기 위해 새로운 소프트웨어로 업그레이드해야 합니다. 그러나 이러한 소프트포크/하드포크 용어는 당시에는 알려지지 않았고 2012년 4월부터 사용되었습니다.6 이 블록 크기 제한 소프트포크는 일종의 활성화 방법을 갖춘 비트코인의 첫 번째 새로운 규칙이었으며, 이 경우 특정 블록 높이에서 새 규칙이 활성화되는 플래그 데이 방식이었습니다. Satoshi는 당시 블록 크기 제한에 대한 분명한 이유를 제시하지 않았습니다. 많은 큰 블록 지지자들은 이 조치가 일시적이었다고 주장하지만, 제가 찾을 수 있었던 당시 기록 중 이를 보여주는 기록은 없었습니다.

다음으로 관심 가는 주요 사건이자 큰 블록 지지자들이 널리 인용하는 일은 2010년 10월 4일에 일어났습니다. 블록 크기 제한이 활성화된 지 한 달도 되지 않아 비트코인 개발자 중 한 사람인 Jeff Garzik이 제한을 없애고 올리자고 제안했습니다.7 그는 1 MB 규칙을 없애는 소프트웨어 패치를 제출했고, 이를 통해 비트코인이 Paypal의 거래 처리 속도에 맞게 확장될 수 있다고 주장했습니다. Jeff는 이러한 문제가 당시에는 해당되지 않는다는 것을 알았지만 마케팅과 서사 관점에서 중요하다고 여겼습니다. 불과 15분 뒤에 Theymos가 답글을 달아 이렇게 말했습니다. “이 패치를 적용하면 다른 비트코인 클라이언트와 호환되지 않게 됩니다.” 그러자 Satoshi가 대화에 끼어들었습니다:

+1 theymos. 이 패치를 사용하지 마십시오, 네트워크와 호환되지 않게 되어 본인에게 손해가 됩니다. 필요해지는 시점에 가까워지면 변경을 단계적으로 도입할 수 있습니다.

다음 날, Satoshi는 추가로 의견을 남겼는데, 이는 현재 큰 블록 지지자들이 가장 널리 인용하는 발언 중 하나입니다:

단계적으로 도입할 수 있습니다, 예를 들면:

if (blocknumber > 115000)

maxblocksize = largerlimit

훨씬 이전 버전부터 넣기 시작할 수 있어서, 해당 블록 번호에 도달하여 발효될 때쯤에는 그것이 없는 오래된 버전은 이미 구식이 됩니다.

기준 블록 번호에 가까워지면, 구버전에 경고를 넣어 업그레이드해야 한다는 것을 반드시 알도록 하겠습니다.

당시 블록 높이가 83,500이었다는 점에 유의해야 합니다. 따라서 블록 높이 115,000은 31,500 뒤의 미래이며, 약 7개월 뒤였습니다. 큰 블록 지지자들에게 Satoshi의 의도는 분명합니다. Satoshi는 제한을 일시적인 조치로 도입했을 뿐이며, 이미 올리는 방법을 명확한 계획과 함께 안내하고 있었습니다.

그러나 대체로 큰 블록 지지자들은 전체 그림이나 맥락을 항상 보지는 않았습니다. 이 대화를 네트워크와 호환되지 않게 되므로 당장 블록 크기 제한을 올리는 패치에 Satoshi가 반대한 것으로 해석할 수 있습니다. 그러고 나서 Satoshi는 더 신중한 입장을 취하고, 원한다면 안전하게 업그레이드할 수 있는 안전장치를 갖추어 제한을 올릴 수 있는 방법을 설명합니다. 이러한 서사는 작은 블록 지지자들이 말하던 내용과 더 비슷하게 느껴집니다.

큰 블록 지지자들이 널리 인용하는 다음 Satoshi 발언은 이보다 더 이른 2008년 11월의 것으로, 비트코인이 시작되기 전이며, 네트워크가 결국 하루 1억 건에 이르는 Visa만큼 많은 거래를 처리할 수 있게 된다는 내용입니다. 이 발언은 큰 블록 지지자들에게 매우 중요하며 그들의 비트코인 비전 중 다수와 분명히 강하게 일치합니다:

네트워크가 그만큼 커지기 훨씬 전부터 사용자는 이중 지불을 확인하기 위해 간편 결제 검증(8절)을 사용하는 것이 안전할 것이며, 이를 위해서는 블록 헤더들의 체인, 즉 하루 약 12KB만 있으면 됩니다. 새로운 코인을 만들려는 사람들만 네트워크 노드를 운영해야 할 것입니다. 처음에는 대부분의 사용자가 네트워크 노드를 운영하겠지만, 네트워크가 일정 규모를 넘어 성장하면 점점 더 전문 하드웨어의 서버 팜을 갖춘 전문가들에게 맡겨질 것입니다. 서버 팜은 네트워크에 노드 하나만 두면 되고, 나머지 LAN은 그 하나의 노드와 연결됩니다.

대역폭이 생각만큼 부담스럽지는 않을 수 있습니다. 일반적인 거래는 약 400바이트가 될 것입니다(ECC는 훌륭하게 간결합니다). 각 거래는 두 번 브로드캐스트되어야 하므로 거래당 1KB라고 해 보겠습니다. Visa는 FY2008에 370억 건의 거래를 처리했으며, 하루 평균 1억 건의 거래입니다. 그만큼 많은 거래는 100GB의 대역폭을 차지하며, 이는 DVD 12장 또는 HD 화질 영화 2편의 크기이며, 현재 가격으로 약 $18어치의 대역폭입니다.

네트워크가 그만큼 커지려면 몇 년이 걸릴 것이며, 그때가 되면 인터넷으로 HD 영화 2편을 보내는 것은 별일처럼 느껴지지 않을 것입니다.8

물론 작은 블록 지지자들도 이에 대한 반박을 가지고 있습니다. 그들은 Satoshi가 간편 결제 검증(SPV) 기술이 존재한다는 가정하에 이러한 의견을 말했다고 주장합니다. 이는 경량 서명 장치가 무효한 블록 안의 이중 지불에 대한 증거를 받을 수 있어서, 보통의 경우 모든 거래를 검증할 필요가 없다는 뜻입니다. 이 기술은 아직 개발되지 않았고 가능하지 않을 수도 있습니다. 따라서 일부 작은 블록 지지자들은 처리량에서 Visa와 경쟁한다는 Satoshi의 주장이 더는 적용되지 않는다고 주장합니다. 이는 다소 까다로운 논증이자 SPV 의미에 대한 좁은 해석으로 볼 수 있습니다.

Satoshi에 대한 아래 답글은 비트코인이 처음 발표된 원래 이메일 글타래에 있던 것으로, 시작되기 몇 달 전이었습니다. Satoshi가 비트코인을 발표했을 때 Satoshi에게 온 바로 첫 답글은 James A Donald라는 사람에게서 왔으며, 아이디어가 발표된 지 불과 하루 만에 용량에 대한 우려를 표명했습니다:

적시에 이중 지불 사건을 탐지하고 거부하려면 거래 안에 들어 있는 비트코인들의 과거 거래 대부분을 가지고 있어야 하며, 이를 단순하게 구현하면 각 피어가 과거 거래 대부분, 또는 최근에 발생한 과거 거래 중 상당 부분을 가지고 있어야 합니다. 수억 명이 거래를 한다면 이는 많은 대역폭이며, 각자 모두 또는 그 상당 부분을 알아야 합니다.9

작은 블록 지지자 쪽에서 쓰는 Satoshi 발언으로는, 2010년 6월에 Gavin과의 논의에서 경쟁 클라이언트를 “네트워크에 대한 위협”이라고 부르고 비트코인의 핵심 설계가 “석판에 새겨졌다”라고 말한 대목이 아마 가장 많이 언급됩니다:

비트코인의 본질은 버전 0.1이 출시되자 핵심 설계가 남은 수명 내내 석판에 새겨진 것과 같다는 점입니다. 그래서 저는 제가 생각할 수 있는 모든 가능한 거래 유형을 지원하도록 설계하고 싶었습니다. 문제는 각 기능이 쓰이는지 여부와 관계없이 특별한 지원 코드와 데이터 필드를 필요로 했고, 한 번에 하나의 특수한 경우만 다루었다는 점입니다. 특수한 경우들의 폭발이 되었을 것입니다. 해결책은 스크립트였으며, 이는 문제를 일반화하여 거래 당사자들이 노드 네트워크가 평가하는 술어로서 거래를 기술할 수 있게 합니다. 노드는 보내는 사람의 조건이 충족되는지를 평가하는 범위에서만 거래를 이해하면 됩니다.

스크립트는 실제로 술어입니다. 단지 참 또는 거짓으로 평가되는 식입니다. 술어(Predicate)는 길고 낯선 단어이므로 저는 스크립트라고 불렀습니다.

지급을 받는 사람은 스크립트에 템플릿 일치를 수행합니다. 현재 받는 사람은 직접 지급과 비트코인 주소라는 두 가지 템플릿만 받습니다. 차후 버전은 더 많은 거래 유형을 위한 템플릿을 추가할 수 있으며, 그 버전 이상을 실행하는 노드는 이를 받을 수 있게 됩니다. 네트워크 안의 모든 버전의 노드는 읽는 방법을 모르더라도 모든 새로운 거래를 블록으로 검증하고 처리할 수 있습니다.

이 설계는 제가 수년 전에 설계한 어마어마하게 다양한 가능한 거래 유형을 지원합니다. 에스크로 거래, 보증 계약, 제3자 중재, 다자 서명 등입니다. 비트코인이 크게 자리 잡으면 앞으로 살펴보고 싶어질 것들이지만, 나중에 가능하도록 처음부터 모두 설계해야 했습니다.

저는 두 번째로 호환되는 비트코인 구현이 좋은 생각이 되리라고 믿지 않습니다. 모든 노드가 정확히 동일한 결과를 단계에 맞추어 얻는 데 설계가 너무 의존하므로, 두 번째 구현은 네트워크에 위협이 될 것입니다. MIT 라이선스는 다른 모든 라이선스 및 상업적 이용과 호환되므로 라이선스 관점에서 다시 쓸 필요가 없습니다.10

Satoshi는 이 분야에 참여한 첫 2년 동안 많은 의견을 남겼으며, 그 중 다수는 이 전쟁의 어느 쪽을 지지한다고도 말할 수 있습니다. 대체로 그 발언들은 Satoshi가 블록 크기 제한과 거래 처리량이라는 좁은 문제에서는 대체로 큰 블록 지지자들을 지지한 듯 보이지만, 비트코인 규칙의 유연성에 대한 관점에서는 작은 블록 쪽을 다소 지지한 듯 보인다고 말할 수 있습니다. 이 시점에서 논쟁은 거의 종교처럼 되며, 양쪽 모두 자신의 주장을 뒷받침하는 의견이나 해석을 찾으려고 모든 Satoshi 발언을 샅샅이 살폈습니다.

그러나 Satoshi가 어떻게 생각했는지는 특별히 중요하게 여겨져서는 안 됩니다. 많은 작은 블록 지지자들은 Satoshi는 이제 중요하지 않다는 견해를 분명히 했습니다. 적어도 5년 전의 그의 견해는 중요하지 않아야 하는데, 그 이후로 많은 것이 바뀌었기 때문입니다. 네트워크가 작동하는 모습을 본 경험 덕분에 우리는 당시의 Satoshi보다 비트코인에 대해 아마 훨씬 더 많이 압니다. 비트코인은 종교가 아니며 Satoshi는 예언자가 아니라고 작은 블록 지지자들은 종종 주장했습니다. 결정은 과학적 장점만으로 내려져야 하며 Satoshi가 말한 것은 아무 차이가 없다고 그들은 주장했습니다. 그러나 비트코인은 종교와 비슷한 특성을 일부 가지고 있으며, 많은 사람들이 그렇게 느낀 것으로 보입니다. 결국 종교는 매우 성공적입니다. 아마 이러한 특성이 비트코인의 성공에 어느 정도 기여했을 것입니다.

Satoshi는 실제로 2015년에 논쟁에 기여한 것으로 나타났습니다. Bitcoin XT가 공개된 날, Satoshi의 이메일 주소 중 하나([email protected])에서 이메일이 발송되었으며, 생각을 바꾸었다는 주장을 포함하여 작은 블록 지지자 쪽 주장을 펼쳤습니다:

최근 블록 크기 논쟁을 메일링 리스트를 통해 지켜보았습니다. 논쟁이 해결되고 포크 제안이 폭넓은 합의를 이루기를 바랐습니다. 그러나 Bitcoin XT 0.11A의 정식 출시로 그런 일은 일어나기 어려워 보이며, 그래서 이 매우 위험한 포크에 대한 우려를 밝히지 않을 수 없습니다.

이 가짜 비트코인의 개발자들은 저의 원래 비전을 따르고 있다고 주장하지만, 진실과는 거리가 멉니다. 제가 비트코인을 설계할 때 합의 규칙의 향후 변경이 거의 만장일치에 가까운 동의 없이는 어렵도록 설계했습니다. 비트코인은 Gavin Andresen이나 Barack Obama, Satoshi Nakamoto라 할지라도 카리스마 있는 지도자의 영향으로부터 보호되도록 설계되었습니다. 거의 모든 사람이 변경에 동의해야 하며, 강제나 압박 없이 그렇게 해야 합니다. 이런 방식으로 포크를 함으로써 이들 개발자는 자신들이 존중한다고 주장하는 “원래 비전”을 위반하고 있습니다.

그들은 비트코인이 본래 어떤 모습이어야 했는지에 대해 주장하기 위해 저의 오래된 글들을 이용합니다. 그러나 그때 이후로 많은 것이 변했고, 저의 초기 견해 중 일부와 모순되는 새로운 지식이 얻어졌음을 인정합니다. 예를 들어 저는 풀드 마이닝과 그것이 네트워크 보안에 미치는 영향을 예상하지 못했습니다. 보안 속성을 유지하면서 비트코인을 경쟁력 있는 통화 시스템으로 만드는 것은 사소한 문제가 아니며, 견고한 해결책을 마련하기 위해 더 많은 시간을 가져야 합니다. 이타심에만 의존하기보다는 사용자들이 노드를 운영하도록 하는 더 나은 유인이 필요하다고 생각합니다.

2명의 개발자가 비트코인을 포크하고 광범위한 기술적 비판에도 불구하고 포퓰리스트적 전술을 사용해 “비트코인”이 무엇인지를 재정의하는 데 성공할 수 있다면, 비트코인을 실패한 프로젝트라고 선언할 수밖에 없습니다. 비트코인은 기술적으로도 사회적으로도 견고하도록 의도되었습니다. 지금의 상황을 지켜보는 것은 매우 실망스럽습니다.11

대부분의 큰 블록 지지자들은 즉시 그 이메일을 가짜라고 일축했습니다. 그러나 이메일 헤더는 그 이메일이 실제로 Vistomail에서 발송되었음을 보여주는 듯했습니다. 따라서 세 가지 가능성이 남습니다. i. Satoshi의 이메일 계정이 해킹당했습니다. ii. Vistomail 관리자들이 이메일을 보냈습니다. 또는 iii. 이 이메일이 진정으로 Satoshi에게서 온 것입니다. 두 번째 가능성은 극히 낮아 보이므로, 이 메시지가 진짜이거나 계정이 해킹당했을 가능성이 높습니다. Satoshi의 다른 이메일 계정([email protected])이 누군가 비밀번호를 재설정할 수 있어 해킹당한 적이 있으므로 해킹된 이메일 계정이라는 것도 충분히 가능합니다. 어느 쪽이든 그것은 사실 중요하지 않았습니다. Satoshi와 같은 한 개인이 이 위기에서 시스템을 혼자 구해낼 만큼 큰 영향력을 가지고 있었다면, 비트코인은 개인에 대한 의존이라는 초창기를 벗어나지 못한 것입니다. 비트코인은 논란이 많고 혁명적인 화폐 시스템으로서 노출될 막대한 압력을 견디기 위해 그 자체로 견고해야 했으며, 아마 쉽게 제지되거나 언제든 사라질 수 있는 한 개인에 의존해서는 안 되었습니다. 이것이 Satoshi가 애초에 사라진 이유일 수 있습니다. 이 이야기에서 Satoshi의 개입으로 보이는 부분은 여기에서 끝났다고 말하고 싶습니다. 그러나 유감스럽게도 Satoshi, 더 정확히는 Satoshi에 대한 주장들이 이후 이야기에서 다시 등장합니다.

2010년에는 이러한 확장성 문제에 대한 논의가 있었지만, 큰 의견 충돌은 없었습니다. 모두가 그저 배우는 중이었습니다. 2011년 4월까지는 상황이 조금 변한 듯했고, 확장성과 거래 수수료, 그리고 장기적인 비트코인 채굴 유인에 대한 깊은 의견 충돌이 드러났습니다. 모두 여전히 예의 바르고 정중했지만, 근본적인 의견 차이가 드러나는 듯했습니다. BitcoinTalk 사용자 “Vandroiy”가 질문을 제기했습니다. 그는 본질적으로 블록 보조금이 소진되어 낮아지면 채굴자들에게 어떻게 유인을 제공할 것인지를 물었습니다. 물론 백서에 “유인은 전적으로 거래 수수료로 전환될 수 있다”고 되어 있으므로 모두가 그 답을 알고 있었습니다.12 그러나 Vandroiy는 더 어려운 질문을 하고 있었습니다. Vandroiy가 2011년 4월 22일에 말한 바와 같습니다.

개별 소규모 채굴자는 누구나 이익을 극대화하려 합니다. 어떤 거래를 포함할지에 대한 그의 결정은 수수료 수준에 큰 변화를 만들지 않습니다. 따라서 채굴자는 최대 이익을 위해 매우 낮은 수수료를 내는 거래를 포함해 어떤 수수료를 내는 모든 거래를 포함할 것입니다. 그 결과 거래 가격이 하락합니다. 그러면 이미 거의 수익을 내지 못하던 채굴자들은 수익이 더 줄어들어 그만둡니다. 이로 인해 해시레이트가 감소하고 난이도가 하락하며, 이러한 순환이 반복됩니다. 이러한 논리에 따르면 난이도는 0에 가깝게 하락할 가능성이 높습니다.13

Vandroiy의 지적을 경제적 관점에서 분석하면, 그는 본질적으로 거래를 포함하는 한계비용이 0에 가깝고, 경쟁 환경에서는 가격이 한계비용과 같아진다고 말하고 있었습니다. 그러면 시장은 낮은 가격에서 청산되며, 이는 때로 “수수료 죽음의 소용돌이 문제”라고 불렸습니다. 그러나 이것은 균형 가격에 도달해 청산하는 것만이 유일한 목적인 정상적인 시장이 아니었습니다. 어떤 사람들은 백서의 표현처럼 이 시장이 채굴자들에게 유인을 제공하는 긍정적인 외부효과 또는 다른 목적을 가지고 있다고 믿었습니다. 이것이 비트코인에 진정으로 문제였는지 여부는 매우 논란이 되었습니다. 이 스레드를 읽어보면 대략 절반의 사람들이 이것이 문제라고 생각하고 절반은 그렇지 않은 듯했습니다. Mike Hearn조차 처음에는 죽음의 소용돌이 문제에 동의하는 듯했고, “그럴듯해 보인다”고 말했습니다. 그러나 다음 날인 2011년 4월 23일에 Mike는 자신의 입장을 매우 정당하게 재고했고, 더 이상 이것을 문제로 보지 않았습니다.

죽음의 소용돌이 논증은 수수료나 우선순위가 아무리 낮아도 제가 모든 거래를 포함할 것이라고 가정합니다. 그렇게 하는 데 비용이 들지 않는데 왜 공짜 돈을 받지 않겠습니까. 그러나 현실에는 그렇게 할 수 있지만 그렇게 하지 않는 기업들로 가득합니다. 그렇게 하면 자신의 사업을 해칠 것임을 이해하기 때문입니다.14

수수료 시장 죽음의 소용돌이를 문제라고 생각한 대부분의 사람들은 제안된 해결책으로 수렴하는 듯했습니다. 블록 크기 제한이 수수료가 너무 낮아지는 것을 막을 것이며, 블록이 가득 차므로 사용자들이 블록 내 공간을 두고 서로 경쟁 입찰해야 한다는 것입니다. 따라서 이 블록 크기 제한은 경제학자들이 생산자 잉여라고 부르는 것을 만들어내며, 블록 보조금이 소진된 뒤 채굴자들에게 유인을 제공할 수 있습니다. 이 의견 충돌이 커뮤니티를 정확히 둘로 나누는 듯했지만, 아무도 그 상황을 크게 걱정하지 않는 듯했습니다. 더 논쟁하는 대신 그 후 몇 년 동안 이 문제에 대한 공개 논의는 거의 없는 듯했습니다. 논의 참여자들은 모두 비트코인이 자신이 선호하는 방향으로 더 발전할 것이라고 가정한 듯했습니다. 2013년에 Mike는 수수료 죽음의 소용돌이를 정당한 문제로 인정하는 듯했지만, 블록 크기 제한 대신 잠재적 해결책으로 “보증 계약”을 제안했습니다.15

이 블록 크기 문제에 대한 적극적인 캠페인의 첫 공개 증거는 비트코인 개발자이자 작은 블록 지지자인 Peter Todd가 제작한 영상입니다. 2013년 5월에 그는 YouTube에 전문적으로 제작된 영상을 공개했습니다.16 그 영상에서 그는 사용자들이 모든 거래를 검증하고 비트코인을 탈중앙화된 상태로 유지할 수 있도록 블록 크기 제한이 작게 유지되어야 한다고 주장했습니다. 그 영상은 심지어 “당신이 사용하는 소프트웨어를 바꾸어 1 MB 블록 크기를 늘리려는 사람은 누구든 무시하라”는 말까지 했습니다. 그 영상은 큰 블록 지지자들에게 광범위하게 조롱당했으며, 그들은 결국 Peter의 작은 블록 캠페인 웹사이트인 keepbitcoinfree.org를 차지해 더 큰 블록을 지지하는 자료로 교체했습니다.

Peter Todd는 “수수료에 의한 교체”(RBF)라고 불리는 것의 주요 옹호자라는 입장 때문에 많은 큰 블록 지지자들을 화나게 하기도 했습니다. RBF는 사용자들이 비트코인 거래가 전체장부에서 확정되기 전에 동일한 거래 입력을 더 높은 수수료로 다시 사용해 새로운 거래로 교체할 수 있게 합니다. 이 RBF 정책을 채택한 채굴자들은 더 높은 수수료의 거래를 포함하기로 선택합니다. 반면 이를 채택하지 않고 대신 최초 확인 우선(FSS) 원칙을 사용하는 채굴자들은 자신이 먼저 본 거래를 포함합니다. 일반적으로 Mike와 Gavin, 그리고 큰 블록 지지자들은 RBF에 반대했고, 작은 블록 지지자들은 이를 지지하는 경향이 있었습니다. 여기에서는 이것과 블록 크기 전쟁 사이에 결정적인 구분을 해야 합니다. 블록 크기 제한은 비트코인 프로토콜의 일부이지만, RBF는 단지 채굴자 정책일 뿐입니다. 따라서 채굴자들은 RBF와 관련해 원하는 대로 할 자유가 있으며 합의가 필요하지 않습니다. 비트코인 프로토콜 규칙과 RBF와 같은 시스템의 다른 측면 사이의 구분은 작은 블록 지지자들에게는 매우 중요했지만, 대부분의 큰 블록 지지자들은 그 구분을 보지 못하거나 같은 정도로 중요하다는 데 동의하지 않았습니다. 어떤 사람들은 그것을 작은 블록 지지자들이 뜻을 이루기 위해 만들어낸 자의적인 구분으로 보았습니다. 이러한 구분에도 불구하고 RBF를 둘러싼 핵심 경제 논증은 채굴자 수수료 죽음의 소용돌이를 둘러싼 논증과 거의 정확히 같았습니다.

RBF 반대자들은 그것이 사용자 경험을 해치고 이중 지불을 더 쉽게 만든다고 주장했고, 옹호자들은 채굴자들이 이익을 늘리기 위해 어차피 더 높은 수수료의 거래를 선택하도록 유인되므로 이는 불가피하며 소프트웨어 정책도 이러한 경제적 현실에 맞추는 것이 좋다고 주장했습니다. 이에 대한 큰 블록 지지자들의 반박은 채굴자들도 사용자 경험을 신경 쓰므로, 자신들이 의존하는 시스템의 사용자 경험을 왜 해치겠느냐는 것이었습니다.

제게는 이 명백한 딜레마에 대한 답이 주로 채굴 산업의 경쟁 수준에 달려 있는 듯합니다. 채굴 산업이 소수의 작은 주체들에게 고도로 집중되어 있었다면, FSS는 다소 논리적인 정책으로 보였고 수수료 죽음의 소용돌이 논증은 적용되지 않는 듯합니다. 이는 이들 채굴자가 내리는 결정이 생태계에 큰 영향을 미쳐 채굴자로서의 미래 수익을 해칠 수 있기 때문입니다. 산업 집중도가 낮다면 개별 채굴자의 결정이 생태계에 미치는 영향은 더 제한적입니다. 채굴자들은 장기적인 사용자 경험을 신경 쓰기보다 단기 이익을 극대화하기로 선택할 수 있으며, 어차피 자신의 행동만으로는 큰 영향을 미치지 않기 때문입니다. 이 문제는 때로 공유지의 비극이라고 불립니다. 공유지의 비극이 여기에 적용된다고 믿는다면, 합리적인 것은 RBF 정책을 적용하는 것일 수 있으며, 수수료 죽음의 소용돌이 위험은 다소 현실적으로 보입니다.

RBF를 둘러싼 논증들은 블록 크기 문제와 매우 비슷한 변곡점을 가진 듯했습니다.

큰 블록 지지자들은 단기를 우선시했고, 작은 블록 지지자들은 장기에 집중했습니다.
큰 블록 지지자들은 사용자 경험을 우선시했고, 작은 블록 지지자들은 시스템을 더 회복력 있게 만드는 것을 선호했습니다.
큰 블록 지지자들은 성장을 우선시했고, 작은 블록 지지자들은 지속가능성을 더 우려했습니다.
큰 블록 지지자들은 더 실용적이고 사업 중심적이었고, 작은 블록 지지자들은 더 과학적이고 이론적이었으며, 전형적으로 매우 지적인 컴퓨터와 암호학 전문가들이었습니다.

반드시 어느 한쪽이 기술적 논증에 동의하지 않았던 것은 아닙니다. 그저 선호가 다르고 고려 중인 각 요소의 중요성에 두는 가중치가 달랐을 뿐입니다. 유감스럽게도 이는 화해가 불가능해 보이는 다른 결론들로 이어졌습니다.

2015년 4월 15일 수요일에 London에서 DevCore라는 Bitcoin Foundation 공식 행사가 있었습니다. Gavin은 “왜 더 큰 체인이 필요한가”라는 제목의 기조연설을 하기 위해 날아와 참석했습니다. 저도 그 행사에 참석했습니다. Gavin은 매우 다가가기 쉬웠고 그 문제를 논의할 의지가 있었습니다. Gavin은 저에게 1 MB는 터무니없이 작으며 많은 웹 페이지가 그보다 크다고 강조했습니다. 그의 생각에 정보기술의 역사는 기하급수적 성장과 사물이 더 빨라지고 커지는 것에 관한 것이었습니다. Moore의 법칙이 반복적으로 언급되었고, 시스템이 시간이 지나며 어떻게 개선되는지, 결국 비트코인이 기가바이트 단위의 훨씬 더 큰 블록을 가지게 되며 기술적 확장성 문제가 없을 것인지를 보여주는 예로 사용되었습니다. Gavin은 조용히 저에게 20 MB 제한으로의 도약을 선호하지만, 다른 사람들이 동참한다면 타협해 8 MB로 바꿀 의향이 있다고 말했습니다. 며칠 뒤인 2015년 4월 18일에 Mike와 Gavin은 London에서 저녁 Q&A 세션을 열었습니다. 블록 크기를 논의하면서 Gavin은 다음과 같이 말했습니다.

저는 그냥 제 영향력을 행사하며 이렇게 될 것이라고 말하고, 마음에 들지 않으면 다른 프로젝트를 찾으라고 말해야 할지도 모릅니다. 솔직히 P2SH 건에서 일어난 일이 바로 그것이었습니다. 저는 그냥 모두의 말을 들었고, 몇 가지 제안을 들었으며, 이렇게 될 것이라고 말했습니다.17

그가 이렇게 말할 때 저는 방 안을 빠르게 둘러보았습니다. 대다수 사람들은 Gavin이 이러한 권한을 가지는 것을 반기는 듯했습니다. 그러나 분명히 소수의 사람들, 아마 5퍼센트 정도가 이에 다소 화가 났고 Gavin이 그 발언으로 거만하다고 보았으며, 꽤 불편해 보였습니다. 그들에게 Gavin은 비트코인의 책임자가 아니었습니다. 그가 단순히 영향력을 행사해 프로토콜을 바꿀 수 있다면 비트코인의 존재 이유는 정확히 무엇입니까. P2SH를 언급하면서 Gavin은 2012년의 다소 논쟁적인 비트코인 소프트포크 업그레이드를 꺼내고 있었습니다. 당시 경쟁적인 제안들이 있었고 Gavin이 본질적으로 앞으로의 길을 선택했습니다.18 강연 뒤에 남아 있으면서 Mike가 Gavin을 밀어붙여 블록 크기에 대해 점점 더 강경한 입장을 취하게 하려 하고, Gavin은 조금 맞서고 있다는 것을 분명히 느꼈습니다. Mike는 Gavin이 GitHub의 주요 Bitcoin Core 저장소에서 다른 개발자들을 내보내고 저장소를 완전히 장악할 수 있는지 묻기까지 했습니다. 그들과 더 이야기해보니 Gavin이 결국 Mike와 함께 더 강한 입장을 취할 가능성이 있어 보였습니다. 두 사람은 Gavin이 그 입장을 취하면 결정적이 될 것이라고 분명히 생각했습니다. Gavin이 이를 어떻게 언제 할지, 그리고 어떤 구체적 조치를 취할지는 당시 저에게는 불분명했습니다.

2015년 5월 4일, Gavin은 “더 큰 블록을 출시할 때”라는 제목의 블로그를 게시했습니다19. 이것은 더 큰 블록에 대한 우려를 다루려고 시도한 일련의 블로그 글 중 첫 번째였습니다. Gavin은 이제 더 큰 블록을 추진할 때라고 분명히 결정했습니다. 2015년 5월 7일, GitHub에서 Bitcoin Core 프로젝트의 대표 관리자인 Wladimir Van Der Laan은 비트코인 메일링 리스트에 보낸 이메일에서 다음과 같이 말했습니다:

저는 가까운 미래에 블록 크기를 늘리는 것에 약하게 반대합니다. 몇 가지 근거는 다음과 같습니다. 간결함을 위해, 하드포크 일정을 정하는 데 내재된 실질적이고 정치적인 문제들은 제외합니다.20

Bitcoin Core는 비트코인의 참조 구현체의 이름이었고, Satoshi가 원래 만든 클라이언트의 후손이었습니다. 이 클라이언트는 처음에는 그저 Bitcoin 또는 Bitcoin-QT라고 불렸지만, Mike Hearn의 제안 이후 2013년 2월에 Bitcoin Core라는 이름이 채택되었는데21, 지금 보면 다소 아이러니해 보입니다. Gavin은 이전에 GitHub에서 Bitcoin 저장소의 소유권을 Wladimir에게 넘겨주었고, 이를 통해 Gavin은 비트코인의 연구 측면에 더 집중할 수 있게 되었습니다. 거래 수수료와 블록 공간 같은 영역을 연구하기 위해 Gavin이 통제권을 넘긴 것으로 보였다는 점에서도 아이러니가 있습니다. 저장소를 관리하는 고된 유지보수 작업과 비교하면 당시에는 이것이 더 중요한 역할로 보였을 수 있으며, Gavin이 어떤 권한을 내려놓은 것으로 보지 않았습니다. 나중에 큰 블록 지지자들은 Gavin이 Wladimir에게 통제권을 넘긴 결정을 치명적인 실수로 여겼습니다. 그러나 작은 블록 지지자들은 대체로 Wladimir에게는 실질적인 권한이 없으며, 저장소를 소유하는 것은 단지 관리인 역할일 뿐이라고 주장했습니다. 코드를 병합하는 최종 결정은 개발자 집단의 폭넓은 합의가 있을 때만 이루어졌으므로, 결국 저장소에 대한 통제권은 중요하지 않습니다. 이에 더해 결정적으로, 비트코인 규칙은 소프트웨어 저장소의 변경으로 결정되지 않으며, 사용자들이 이미 실행하고 있는 클라이언트들에 의해 결정됩니다. 물론 저장소는 프로토콜 변경이 포함된 새로운 버전의 클라이언트를 게시할 수 있었지만, 자동 업그레이드 기능은 없었고 아무도 업그레이드를 강제받지 않았습니다. 이것은 작은 블록 지지자들에게는 결정적이었지만 큰 블록 지지자들은 보지 못했거나 동의하지 않았던 구분의 또 다른 사례입니다. 큰 블록 지지자들에게는 너무 많은 권한이 Bitcoin Core의 손에 있었고, 따라서 Bitcoin Core는 빠르게 그들의 주적이 되었습니다.

소프트웨어 프로젝트의 대표 관리자 권한에 대해 어떤 견해를 가지고 있든, 가까운 미래의 블록 크기 증가에 대한 “약한” 반대라는 Wladimir의 발언은 매우 중요해 보였습니다. Gavin의 엄청난 설득에도 불구하고 하드포크가 Bitcoin Core에 병합되지 않을 것처럼 보였고, 따라서 Gavin의 선택지는 다소 제한적으로 느껴졌습니다. 2015년 5월 29일, Gavin은 자신이 계획한 일에 대해 지금까지 중 가장 강한 힌트를 주었습니다. Bitcoin XT로 지지를 옮기고 대안의 호환되지 않는 비트코인 프로토콜에 힘을 실을 수 있다는 것이었습니다. 아래의 이메일이 꽤 명확했음에도, 저는 그것을 결코 실제로 믿지 않았고 위협으로 여겼습니다. 일종의 협상 전술이라고 생각했습니다.

우리가 곧 합의에 이르지 못한다면, 저는 Mike의 Bitcoin-Xt 프로젝트에 지금 큰 증가를 구현하고 시간이 지나며 커지도록 하는 패치를 검토하고 제출하는 데 도움을 요청하겠습니다. 그렇게 하면 이런 모든 분노와 논쟁을 다시 겪지 않아도 될 수 있습니다.

그다음 저는 가맹점 서비스와 거래소와 호스팅형 서명 장치 회사들과 bitcoind를 사용하는 다른 인프라 회사들(그리고 더 늦기 전에 더 큰 블록이 필요하다는 데 저와 동의하는 모든 사람들)에게 Bitcoin Core 대신 Bitcoin-Xt를 실행하고, 그것을 실행하고 있다고 밝히도록 설득하는 데 도움을 요청하겠습니다. 우리는 클라이언트 버전을 관찰하여 네트워크에서의 채택을 확인할 수 있을 것입니다.

어쩌면 그때가 되면 더 늦기 전에 더 큰 블록이 필요하다는 합의가 이루어질 것입니다. 그렇다면 좋습니다! 조기 배포는 그저 조기 테스트 역할을 할 것이고, 이미 배포된 모든 소프트웨어는 더 큰 블록을 위한 준비가 될 것입니다.

그러나 개발자들 사이에 여전히 합의가 없지만 “지금 더 큰 블록” 움직임이 성공한다면, 저는 큰 채굴자들에게도 똑같이 하도록 만드는 데 도움을 요청하고, 소프트포크 블록 버전 투표 방식을 이용해 (바라건대) 과반수, 그리고 더 큰 블록을 생산하려는 초 과반수를 확보하겠습니다. 그 과정의 목적은 모든 의심자들에게 더 큰 블록을 지지하기 시작하는 편이 낫고 그렇지 않으면 뒤처질 것임을 증명하고, 그런 일이 일어나기 전에 업그레이드할 기회를 주는 것입니다.

왜냐하면 우리가 여기서 합의에 이르지 못한다면, 합의를 결정하는 궁극적인 권위는 대다수의 가맹점과 거래소와 채굴자들이 실행하고 있는 코드이기 때문입니다.22

2015년 7월 21일, 과거 Google에서 Mike Hearn과 함께 일했던 또 다른 비트코인 개발자 Pieter Wuille이 하드포크 블록 크기 증가를 제안했습니다. Pieter는 논쟁에서 “작은 블록” 쪽에 속한 것으로 여겨졌습니다. 저에게는 이것이 타협안처럼 보였고, Gavin의 압박에 대한 대응으로 보였습니다. 그 제안은 BIP 103이라는 번호가 붙었고, 제안을 해준 Wladimir Van Der Laan과 Gregory Maxwell이라는 개발자에게 사의를 표했으며23, 이는 그들의 잠재적 지지를 보여주었습니다. 그 제안은 하드포크가 2017년 1월에 활성화되고, 그 시점에 블록 크기 한도가 2063년까지 연간 17.7퍼센트씩 증가한다는 내용이었습니다. 그 제안에는 활성화 방법이 포함되지 않았습니다. 더 많은 논의를 위한 촉매로 의도된 것처럼 보였고, 합의에 도달하면 활성화 방법을 정할 수 있었습니다.

저는 이 제안을 중요한 순간으로 여깁니다. 블록 크기 증가 일정은 다소 보수적으로 보였습니다. 그러나 저는 그것이 협상의 일부라고 생각했습니다. 저는 Gavin이 그 제안에 긍정적으로 반응하고, 어쩌면 반대 제안을 내놓으며, 양측이 점차 서로에게 다가갈 것으로 기대했습니다. 우리는 천천히 해결을 향해 나아가는 것처럼 보였습니다. 놀랍게도 Gavin과 큰 블록 지지자들은 BIP 103에 전혀 긍정적으로 반응하지 않았습니다. 그들은 제안된 증가가 너무 작아서 진전이라기보다 모욕에 가깝다고 여겼습니다. 안타깝게도 BIP 103은 도움이 되지 않는 듯했습니다. BIP 103에서 제안된 연간 17.7퍼센트 증가로는 비트코인 거래에 대한 수요가 이 성장 수준을 초과할 가능성이 있어 보였습니다. 반면 큰 블록 지지자들은 정확히 그 반대를 보장하려 했습니다. 그들은 블록 크기 한도가 수요보다 더 빠르게 증가하기를 원했습니다. 양측이 서로 반대되는 것을 원한다면, 타협이 정말 이루어질 수 있었겠습니까?

큰 블록 지지자들에게 우선순위는 사용자 경험에 관한 것이었습니다. 가득 찬 블록을 피하는 것이 핵심이었고, 그렇지 않으면 사용자들은 자신의 거래가 확정되기까지 예측할 수 없는 시간 동안 기다려야 했습니다. 이것이 이처럼 신뢰할 수 없다면 어떤 가맹점이 비트코인을 결제 수단으로 채택하겠습니까? 블록 공간을 차지하려는 입찰 경쟁에서 사용자들에게 서로 경쟁 입찰하도록 강제하는 것은, 정의상 일부 사용자들이 비트코인을 사용할 가능성을 박탈하고 그들을 다른 것으로 떠나게 만들 것입니다. 이것은 끔찍한 사업 전략으로 여겨졌습니다. 의도적으로 사용자를 떠나게 하면서 성공하는 플랫폼이 어떤 종류입니까?

작은 블록 지지자들에게 이것은 그런 문제가 아니었습니다. 그들에게 가득 찬 블록은 어떤 위기가 아니었고, 오히려 성공의 징표였습니다. 그것은 비트코인이 인기를 얻고 있음을 보여주었고, 블록 크기 한도라는 제약을 반영하는 새로운 균형 수준의 사용자 채택이 일어날 것이었습니다. 그들은 수수료가 너무 높아져 사용자가 떠난다는 큰 블록 지지자의 주장을 가끔 조롱했고, 그것을 일종의 역설에 비유했습니다. “아무도 더 이상 그곳에 가지 않는다… 너무 붐비기 때문이다.”

이에 더해 작은 블록 지지자들은 어차피 장기적으로 가득 찬 블록을 필요하고 불가피한 것으로 여기는 경향이 있었습니다. 블록 보조금이 낮을 때 수수료 시장 붕괴 악순환을 막기 위해 필요했습니다. 보조금이 낮아진 뒤 채굴자들이 체인을 앞으로 움직이도록 보장하기 위해서도 필요했습니다. 블록에 들어가지 못하고 포함되기를 기다리며 쌓여 있는 거래의 여유분이 항상 있는 것이 매우 중요하다고 여겨졌습니다. 그렇게 하면 채굴자들은 항상 블록을 만들 유인이 있습니다. 가득 찬 블록도 없고 여유 거래도 없다면, 수익이 없는데 왜 채굴자가 굳이 채굴을 하겠습니까? 대신 채굴자들은 기계를 끄고, 에너지 비용을 아끼고, 각 블록 이후에 밀린 거래가 다시 쌓이기를 기다릴 것입니다. 이것은 네트워크 보안을 크게 떨어뜨릴 것입니다. 큰 블록 지지자들은 이 논리를 매우 부적절하다고 여겼습니다. 블록 보조금은 수십 년 동안 유지될 것이므로, 20년에서 100년 뒤에 문제가 될 수 있는 일을 위해 왜 지금 고객을 잃어야 합니까?

작은 블록 지지자들은 또한 어차피 가득 찬 블록은 불가피하다고 믿었습니다. 결국 블록 공간이 비어 있다면 왜 다 쓰지 않겠습니까? 누구든 전체장부에 자신이 좋아하는 무엇이든 저장할 수 있었고, 예를 들어 자신의 음악 모음이나 암호화된 문서가 있었습니다. 저렴하고 고도로 복제되는 저장소에 대한 수요는 본질적으로 무한하다고 그들은 주장했습니다. 따라서 한도를 예상 수요보다 높게 올려 달라는 요구는 무의미했습니다. 실제로 한 사람이 쉽게 모든 공간을 혼자 채울 수 있었습니다. 이 지점에 대한 큰 블록 지지자들의 반박은 채굴 유인 논쟁으로 돌아갔고, 채굴자들은 이렇게 하지 않을 것이며, 채굴자들은 이 정도 양의 데이터가 블록에 들어오도록 놔두지 않을 것이라고 그들은 주장했습니다. 이에 더해 큰 블록 지지자들은 비트코인의 첫 5년 동안 블록이 가득 차지 않았으며, 이러한 특성이 비트코인의 성공에 기여했다고 주장했습니다. 왜 누군가가 지금 그것을 바꾸는 위험한 조치를 원하겠습니까?

안타깝게도 커뮤니티는 합의에 더 가까워지지 않았고, Gavin은 자신의 계획을 밀고 나갔습니다. 2015년 7월에 Gavin은 자신의 제안에 대해 일부 중국의 채굴자들과 채굴 풀들의 의향을 타진했다고 전해집니다.24 Beijing에서 회의가 있었고, 이 크기의 블록을 빠르게 전파하기에는 중국의 통신 기반 시설이 너무 약하다고 여겨졌기 때문에, 채굴자들이 20 MB까지 늘리자는 Gavin의 주장에 동의하지 않았다고 전해집니다. 따라서 8 MB 블록으로 합의에 도달했다고 전해집니다. Gavin은 이제 몇 주 앞으로 다가온 8월의 큰 계획된 움직임을 물밑에서 준비하고 있었습니다.

Bitcoin XT 웹사이트의 Q&A 부분에서 다음과 같이 말했습니다:

결정은 Mike와 Gavin 사이의 합의를 통해 이루어지며, 심각한 분쟁이 발생하면 Mike가 최종 결정을 내립니다.25

커뮤니티의 일부에서는 이것이 그저 이 모든 것이 Mike의 권력 장악이라는 인상을 강화했습니다. 최종 결정을 내린다는 Mike는 누구였습니까? Mike에게 뭔가 잘못이 있었다는 것이 아니라, 그는 꽤 괜찮은 사람처럼 보였습니다. 다만 이런 말을 이렇게 노골적으로 하는 것이 올바른 접근처럼 느껴지지 않았습니다. 비트코인 사용자들은 통제권을 가지고 있다고 느끼기를 좋아하고, 소유권을 가지고 금융 주권을 가지기를 원합니다. 이것은 Bitcoin XT의 메시지에 전혀 속하지 않았고, Bitcoin XT는 개인적으로 Mike라는 인물에 너무 집중된 것처럼 보였습니다. 큰 블록 지지자 쪽의 두 번째 큰 실수가 바로 여기에 있습니다. Bitcoin XT는 풀뿌리 사용자 접근처럼 꾸며지기보다 Mike와 너무 연관되었습니다. 소프트웨어를 Gavin 중심으로 내세웠더라도 성공 가능성을 높였을 것입니다.

영문 — Chapter 2 – March To War

Chapter 2 of the book The Blocksize War is published below. The full book is available on Amazon. As a reminder, 50% of any profits from physical book sales will be donated to Médecins Sans Frontières, a charity that provides medical assistance to people affected by conflict, epidemics, disasters, or exclusion from healthcare.

In the early days of Bitcoin, from 2009 to early 2011, the entire ecosystem consisted of just one piece of software, the Bitcoin client. This software existed initially for Microsoft Windows and comprised of the wallet, full node and miner. There were no mobile applications, no merchants, no gambling websites, no darknet markets, no exchange traded products, no exchanges, no institutional investors; just one primitive and basic software application. All one could do was mine some coins, send them and receive them. At the time, Bitcoin was pretty useless, and on the surface the system did not appear to have much value or potential. To be interested in the space, one had to have an imagination. One had to see many steps ahead and conceptualise how the system would develop and change over time. Building layer upon layer of assumptions with regards to how Bitcoin would evolve. Many of these assumptions had never been tested or comprehensively discussed; they were just taken for granted and accepted. By 2015, Bitcoin had been around for five or six years, and for those dedicated to the space, this was quite a long time to hold an assumption. Many in the community actually had different, conflicting assumptions with respect to how Bitcoin worked, and the extent of these disagreements had never been revealed. Now, these disagreements were bubbling to the surface and, with Bitcoin meaning so much to these people, the results could become ugly and unpredictable.

The Bitcoin price had also appreciated significantly, from essentially a few cents in 2010 to around US$220 a coin by the summer of 2015. Many parties to the conflict had therefore benefited considerably from a financial perspective by investing in Bitcoin early. An unfortunate consequence of this is that some in the community became overconfident, even a little arrogant. For instance, let’s say someone had decided to invest in the early part of 2011, when the price of Bitcoin was under US$1. They may have based this investment on certain assumptions and a particular vision. They could have then continued to hold the coins into 2015, seeing their investment increase by more than 200 times. This is likely to influence one’s psychology: surely the assumptions made in 2011 were correct? After all, they led to such strong gains. This investor is now likely to consider themselves to have a very strong understanding of Bitcoin and to know what is best going forwards, believing that they clearly understood Bitcoin well in 2011 because they made such strong gains. Unfortunately, maybe people did not quite appreciate that others with very different and conflicting visions had also invested in Bitcoin in early 2011, thereby negating this somewhat flawed and biased logic. Often, it appeared that people just assumed that the other early investors all agreed with them and that those on the other side of them in the blocksize war were newcomers. This goes a long way to explaining how the blocksize war appeared to escalate and become so vicious, so quickly.

It is worth going into a bit of early Bitcoin history at this point. When Bitcoin was released, there was no blocksize limit, although it is likely that larger blocks, perhaps more than 32 MB, would have broken the system. The limit was first introduced by Satoshi in the summer of 2010. On July 15, 2010, Satoshi added the following line of code to the software repository:

static const unsigned int MAX_BLOCK_SIZE = 1000000;5

The software containing this upgrade was then released on July 19, 2010. The new 1 MB limit did not come into force until September 7, 2010, at block height 79,400 (79,400 blocks since Bitcoin was launched). This type of upgrade was called a softfork, i.e. a new rule tightening restrictions on block validity. It is a softfork because adding or lowering the limit tightens the rules. Increasing the limit would relax the rules and is therefore known as a hardfork. Everyone needs to upgrade to new software to follow the new chain in the event of a hardfork. However, this softfork/hardfork terminology was not known at the time, and was only used as of April 2012.6 This blocksize-limit softfork was Bitcoin’s first new rule that had some kind of activation methodology, in this case a flag day, where the new rules became active at a certain block height. Satoshi never provided a clear reason for the blocksize limit at the time. Many large blockers contend that the measure was only temporary, although no notes from the time that I could find indicate this.

The next key event of interest, and something widely cited by the large blockers, occurred on October 4, 2010. Not even one month after the blocksize limit became active, one of the Bitcoin developers, Jeff Garzik, proposed removing it and increasing the limit.7 He submitted a software patch removing the 1 MB rule and he argued this would ensure Bitcoin could scale to match Paypal’s transaction rate. Although Jeff knew such an issue wasn’t applicable in these early days, he considered it important from a marketing and narrative perspective. Just 15 minutes later, Theymos replied, stating that: “Applying this patch will make you incompatible with other Bitcoin clients.” Satoshi then chimed into the conversation:

+1 theymos. Don’t use this patch, it’ll make you incompatible with the network, to your own detriment. We can phase in a change later if we get closer to needing it.

The next day, Satoshi made an additional comment, in what is now one of the most widely quoted statements from the larger blockers:

It can be phased in, like:

if (blocknumber > 115000)

maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don’t have it are already obsolete.

When we’re near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

It should be noted that, at the time, the block height was 83,500; therefore, block height 115,000 was 31,500 into the future, approximately seven months later. To the large blockers, Satoshi’s intention here is clear. Satoshi only introduced the limit as a temporary measure and was already providing instructions on how to increase it, with a clear plan in place.

However, in general, large blockers didn’t always look at the whole picture or context. One can interpret the dialogue as Satoshi opposing the patch to increase the blocksize limit right away, as it would make one incompatible with the network. Satoshi then takes a more cautious stance and goes on to describe how one could increase the limit if one wanted to, with some safety mechanisms to ensure a smooth upgrade. This narrative feels more similar to what the small blockers were saying.

The next quote from Satoshi widely cited by the large blocks is from even earlier, November 2008, before Bitcoin had even launched, where he talks about the network eventually being able to handle as many transactions as Visa, 100 million per day. This quote is very important to the large blockers and clearly aligns strongly with many of their visions for Bitcoin:

Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node.

The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so let’s say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices.

If the network were to get that big, it would take several years, and by then, sending 2 HD movies over the Internet would probably not seem like a big deal.8

Of course, the small blockers have a response to even this. They claim that Satoshi was making these comments under the assumption that Simplified Payment Verification (SPV) technology exists. What this means is that light wallets could receive proof of a double spend in an invalid block and would therefore, in normal circumstances, not be required to verify all the transactions. This technology has not yet been developed and may not be possible. Therefore, some small blockers argue, Satoshi’s claims about competing with Visa for throughput no longer apply. This can be considered as a somewhat pedantic argument and a narrow interpretation of the meaning of SPV.

The below reply to Satoshi was in the original email thread where Bitcoin was first announced, a few months before it even launched. The very first reply to Satoshi when he announced Bitcoin was from somebody called James A Donald, who was already expressing concern about capacity, within just one day of the idea being announced:

To detect and reject a double spending event in a timely manner, one must have most past transactions of the coins in the transaction, which, naively implemented, requires each peer to have most past transactions, or most past transactions that occurred recently. If hundreds of millions of people are doing transactions, that is a lot of bandwidth – each must know all, or a substantial part thereof.9

As for Satoshi quotes used by the small blocker side, perhaps the most referenced is when Satoshi referred to a competing client as a “menace to the network” and mentioned how the core design of Bitcoin was “set in stone”, in a discussion with Gavin in June 2010:

The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender’s conditions are met.

The script is actually a predicate. It’s just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.

The receiver of a payment does a template match on the script. Currently, receivers only accept two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them. All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.

The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we’ll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.

I don’t believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.10

Satoshi made many comments during the first two years of his involvement in the space, many of which could be said to support either side in this war. In general, it could be said that the quotes indicate that Satoshi seemed to broadly support the large blockers with respect to the narrow issue of the blocksize limit and transaction throughput, but Satoshi seemed somewhat supportive of the smaller block position with respect to their view on the flexibility of the Bitcoin rules. At this point, the debate appears to get almost religious, with both sides poring over every Satoshi quote looking for comments or interpretations supporting their cause.

What Satoshi thought, however, should not be considered as especially important. Many smaller blockers articulated a view that Satoshi was now irrelevant. At least, his views five years ago shouldn’t matter, because a lot has changed since then. We now probably know much more about Bitcoin than Satoshi back then, due to the experience of seeing the network in action. Bitcoin is not a religion and Satoshi is not a prophet, small blockers often contended. Decisions should be made based on scientific merit alone; what Satoshi said makes no difference, they claimed. However, Bitcoin does have some characteristics similar to a religion and this does appear to be how many people felt. After all, religions are very successful; perhaps these characteristics contributed somewhat to Bitcoin’s success.

Satoshi did actually appear to contribute to the debate in 2015. On the day Bitcoin XT was published, an email was sent from one of Satoshi’s email addresses ([email protected]), articulating the small blocker side of the argument, including a claim that he had changed his mind about scaling:

I have been following the recent block size debates through the mailing list. I had hoped the debate would resolve and that a fork proposal would achieve widespread consensus. However with the formal release of Bitcoin XT 0.11A, this looks unlikely to happen, and so I am forced to share my concerns about this very dangerous fork.

The developers of this pretender-Bitcoin claim to be following my original vision, but nothing could be further from the truth. When I designed Bitcoin, I designed it in such a way as to make future modifications to the consensus rules difficult without near unanimous agreement. Bitcoin was designed to be protected from the influence of charismatic leaders, even if their name is Gavin Andresen, Barack Obama, or Satoshi Nakamoto. Nearly everyone has to agree on a change, and they have to do it without being forced or pressured into it. By doing a fork in this way, these developers are violating the “original vision” they claim to honour.

They use my old writings to make claims about what Bitcoin was supposed to be. However I acknowledge that a lot has changed since that time, and new knowledge has been gained that contradicts some of my early opinions. For example I didn’t anticipate pooled mining and its effects on the security of the network. Making Bitcoin a competitive monetary system while also preserving its security properties is not a trivial problem, and we should take more time to come up with a robust solution. I suspect we need a better incentive for users to run nodes instead of relying solely on altruism.

If two developers can fork Bitcoin and succeed in redefining what “Bitcoin” is, in the face of widespread technical criticism and through the use of populist tactics, then I will have no choice but to declare Bitcoin a failed project. Bitcoin was meant to be both technically and socially robust. This present situation has been very disappointing to watch unfold.11

Most large blockers immediately dismissed the email as a fake. However, the email headers seemed to indicate the email did originate from Vistomail. This therefore leaves three possibilities: i. Satoshi’s email account was hacked; ii. Vistomail administrators sent the email; or iii. This email was genuinely from Satoshi. The second possibility seems extremely unlikely, therefore it’s probable that either this message is genuine or the account was hacked. A hacked email account is certainly possible, since Satoshi’s other email account ([email protected]) was hacked when somebody was able to reset the password. Either way, it didn’t really matter. If one individual, such as Satoshi, had so much influence over the system that he could rescue it from this crisis alone, then Bitcoin had failed to move on past the early days of reliance on an individual. Bitcoin had to be robust in of itself to withstand the immense pressures it would be exposed to as a controversial and revolutionary money system, without reliance on one individual, who could presumably easily be stopped or could vanish at any time. This may be why Satoshi disappeared in the first place. I would like to say this is where the supposed involvement of Satoshi ended in this story. However, unfortunately, Satoshi, or more precisely claims about Satoshi, come into the story again later on.

While, in 2010, there were discussions about these scaling issues, there were no significant disagreements; everyone was just learning. By April 2011, things appeared to have changed a little and a deep disagreement about scaling, transaction fees and long-term Bitcoin mining incentivisation became apparent. Everyone was still civil and polite, but a fundamental difference of opinion seemed to emerge. BitcoinTalk user “Vandroiy” posed a question: he essentially asked how miners would be incentivised when the block subsidy ran out and became low. Of course, everyone knew the answer to this, as the whitepaper says “the incentive can transition entirely to transaction fees”.12 However, Vandroiy was asking a more challenging question. As Vandroiy put it on April 22, 2011:

Any single, small miner intends to maximize profit. His decision on what transactions to include doesn’t create a big change in the height of fees. Thus, the miner will include all transactions that pay any fee, even very low fees, to have maximum profit. This results in the price for transactions dropping. In turn, those miners who already were hardly profitable have their earnings further reduced and quit. This reduces hashrate, difficulty drops, and the circle repeats. By this reasoning, difficulty is likely to drop close to zero.13

Analysing Vandroiy’s point from an economic perspective, he was essentially saying that the marginal cost of including a transaction is near zero and, in a competitive environment, price equals marginal cost. The market would then clear at low prices, sometimes referred to as the “fee death spiral problem”. However, this was not a normal market where the only objective was to reach an equilibrium price and clear; some believed this market had a positive externality, or another objective, as the whitepaper put it, to incentivise miners. Whether or not this was truly a problem for Bitcoin proved highly controversial. From reading this thread, it appears as if roughly half the people thought this was a problem and half did not. Even Mike Hearn initially seemed to agree with the death spiral problem, stating that it “seems plausible”. However, the following day, on April 23, 2011, Mike had, quite legitimately, re-considered his position, and he no longer considered this as a problem:

The death spiral argument assumes that I would include all transactions no matter how low their fee/priority, because it costs me nothing to do so and why would I not take the free money? Yet real life is full of companies that could do this but don’t, because they understand it would undermine their own business.14

Most of the people who thought the fee market death spiral was a problem seemed to settle on a proposed solution: the blocksize limit would prevent fees falling too low, as users would have to bid against each other for space in blocks, which would be full. This blocksize limit would therefore create what economists call a producer surplus, which could incentivise miners once the block subsidy ran out. While this disagreement seemed to split the community right down the middle, nobody appeared too worried by the situation. Instead of debating further, there appeared to be little public discussion on the matter for the next few years. The participants in the discussion all seemed to assume that Bitcoin would evolve more in their preferred direction. In 2013, Mike appeared to recognise the fee death spiral as a legitimate problem, but proposed “assurance contracts”15 as a potential solution, rather than a blocksize limit.

The first public evidence of active campaigning on this blocksize issue was a video produced by Bitcoin developer and small blocker, Peter Todd. In May 2013, he released a professionally-produced video on YouTube16. In the video, he argued that it was necessary for the blocksize limit to remain small, such that users could validate all the transactions and keep Bitcoin decentralised. The video even talked about “ignoring anyone trying to change the software you use, to increase the 1 MB blocksize”. The video has been extensively derided by the large blockers, who even eventually took over Peter’s small block campaign website keepbitcoinfree.org, and replaced it with material supporting larger blocks.

Peter Todd also angered many of the large blockers, due to his position as the main proponent of something called “Replace by fee” (RBF). RBF allows users to replace a Bitcoin transaction (before it is confirmed in the blockchain), with a new transaction by spending the same transaction input again, only with a higher fee. Miners adopting this RBF policy would choose to include the higher fee transaction. In contrast, miners not adopting this and instead using the first seen safe (FSS) principal, would include the transaction they saw first. In general, Mike, Gavin and large blockers were opposed to RBF, while small blockers tended to support it. A crucial distinction should be made here between this and the blocksize war: the blocksize limit is a part of the Bitcoin protocol, while RBF is only a miner policy. Miners are therefore free to do what they like with respect to RBF and there is no need for consensus. The distinction between a Bitcoin protocol rule and any other aspect of the system, such as RBF, was extremely important to small blockers, while most larger blockers never saw the distinction or agreed that it mattered to the same extent. Some considered it as an arbitrary distinction which smaller blockers had created to get their way. Despite this distinction, the core economic argument around RBF was almost exactly the same as that around the miner fee death spiral.

Opponents of RBF opined that it damaged the user experience and made double spending more likely, while advocates claimed miners were incentivised to choose higher fee transactions anyway, to increase profits, therefore it was inevitable and the software policy might as well align with this economic reality. The large blockers’ retort to this was that miners cared about the user experience too, and therefore why would they damage the user experience of the system they depended on?

It seems to me that the answer to this apparent dilemma depends primarily on the level of competitiveness in the mining industry. If the mining industry was highly concentrated among a few small players, then FSS seemed a somewhat logical policy and the fee death spiral argument appears not to apply. This is because the decisions these miners make would have a significant impact on the ecosystem and thus potentially damage their future earnings as miners. If the level of industry concentration is low, then the impact the decisions of individual miners have on the ecosystem is more limited. Miners may instead choose to maximise their short-term profits, rather than care about the long-term user experience, that their action alone would not impact significantly anyway. This problem is sometimes referred to as a tragedy of the commons. If one believes the tragedy of the commons is applicable here, the rational thing may therefore be to apply RBF policies, and the fee death spiral risk seems somewhat viable.

The arguments over RBF seemed to have very similar inflection points to the blocksize issue:

Large blockers prioritised the short term, while small blockers focused on the long term;
Large blockers prioritised the user experience, while small blockers favoured making the system more resilient;
Large blockers prioritised growth, while small blockers were more concerned about sustainability;
Large blockers were more pragmatic and business-focused, while small blockers were more scientific and theoretical, typically highly intelligent computer and cryptography boffins.

It was not necessarily the case that either side disagreed on the technical arguments; they just had different preferences and weighted the importance of each component under consideration differently. Unfortunately, this resulted in different conclusions that appeared impossible to reconcile.

On Wednesday, April 15, 2015, there was an official Bitcoin Foundation event in London, called DevCore. Gavin was in attendance, having flown over to deliver his keynote speech entitled “Why we need a bigger chain”. I was also in attendance at the event. Gavin was very approachable and willing to discuss the issue. Gavin emphasised to me that 1 MB was ridiculously small, and that many web pages were larger than that. In his mind, the history of information technology was about exponential growth and things becoming faster and larger. Moore’s law was mentioned repeatedly, used as an example to show how systems improve over time and that eventually Bitcoin would have much larger blocks, into the gigabytes, and there would be no technical scaling issues. Gavin quietly mentioned to me that he favoured a jump to a 20 MB limit, but that he was willing to compromise and maybe change this to 8 MB, if others came on board. A few days later, on April 18, 2015, Mike and Gavin held an evening Q&A session in London. When discussing blocksize, Gavin said the following:

I may just have to throw my weight around and say, this is the way it’s going to be, and if you don’t like it, find another project. Frankly, that is what happened with the P2SH thing; I just kind of said, I have listened to everybody, I have listened to a couple of proposals and this is the way it is going to be17

As he said this, I took a quick glance around the room. The majority of people seemed happy with Gavin having this power. However, there was clearly a minority of people, perhaps just five percent or so, who were somewhat angered by this and viewed Gavin as being arrogant in making that comment; they looked quite uncomfortable. To them, Gavin was not in charge of Bitcoin; if he could simply throw his weight around and change the protocol, what exactly was the point of Bitcoin? In mentioning P2SH, Gavin was bringing up a somewhat contentious Bitcoin softfork upgrade in 2012, where there were competing proposals and Gavin had essentially chosen the path forwards.18 From hanging around after the talk, I got a clear sense that Mike was pushing Gavin to take a tougher and tougher stance on the blocksize, while Gavin was pushing back a little. Mike was even asking if Gavin could boot the other developers out of the main Bitcoin Core repository on GitHub and take full control of the repository. From chatting to them further, it did seem possible that Gavin would eventually join Mike in taking a stronger stance. The two of them clearly thought that, once Gavin had taken that position, it would prove decisive. Quite how and when Gavin would do this, and what specific action he would take, was unclear to me at the time.

On May 4, 2015, Gavin published a blog entitled “Time to roll out bigger blocks”19. This was the first in a series of blogposts where he attempted to address the concerns with larger blocks. Gavin had clearly decided now was the time to make the push for larger blocks. On May 7, 2015, the lead maintainer of the Bitcoin Core project on GitHub, Wladimir Van Der Laan, made the following comment in an email to the Bitcoin mailing list:

I’m weakly against a block size increase in the near future. Some arguments follow. For sake of brevity, this ignores the inherent practical and political issues in scheduling a hardfork.20

Bitcoin Core was the name of the reference implementation of Bitcoin and a descendant of the client Satoshi originally created. This client had initially just been called Bitcoin or Bitcoin-QT, however the name Bitcoin Core was adopted in February 2013 after a suggestion from Mike Hearn21, which now seems somewhat ironic. Gavin had previously handed the ownership of the Bitcoin repository on GitHub to Wladimir, to enable Gavin to focus more on the research side of Bitcoin. There is also some irony here, as Gavin appeared to have handed over control so that he could research areas like transaction fees and blockspace. This may have seemed like a more important role at the time, compared to the grinding maintenance work of managing the repository; it was not seen as Gavin relinquishing any power. Later on, the larger blockers regarded Gavin’s decision to hand over control to Wladimir as a critical mistake. However, small blockers typically contended that Wladimir had no real power, and that owning the repository was only a janitorial role. The final decision on merging code was made only if there was broad agreement from the group of developers, so ultimately control of the repository does not matter. In addition to this, and crucially, the Bitcoin rules are not determined by changes to the software repository; they are determined by the clients which users are already running. Of course, the repository could publish new versions of the client with protocol changes, but there was no automatic upgrade feature, and nobody was forced to upgrade. This is another example of a distinction which was crucial to small blockers, but which the large blockers simply did not see or agree with. To the large blockers, there was too much power in the hands of Bitcoin Core, therefore it quickly became their main enemy.

Whatever one’s views on the power of the lead maintainer of the software project, the comment from Wladimir about his “weak” opposition to a blocksize increase in the near future, seemed highly significant. It appeared as if the hardfork would not be merged into Bitcoin Core, despite tremendous lobbying from Gavin, and Gavin’s options therefore felt somewhat limited. On May 29, 2015, Gavin gave the strongest hint yet of what he planned to do: that he may switch his support over to Bitcoin XT and throw his weight behind the alternative incompatible Bitcoin protocol. Despite the below email, which was pretty clear, I never really believed it and considered it a threat; I thought it was some kind of negotiating tactic.

If we can’t come to an agreement soon, then I’ll ask for help reviewing/submitting patches to Mike’s Bitcoin-Xt project that implement a big increase now that grows over time so we may never have to go through all this rancor and debate again.

I’ll then ask for help lobbying the merchant services and exchanges and hosted wallet companies and other bitcoind-using-infrastructure companies (and anybody who agrees with me that we need bigger blocks sooner rather than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they are running it. We’ll be able to see uptake on the network by monitoring client versions.

Perhaps by the time that happens there will be consensus bigger blocks are needed sooner rather than later; if so, great! The early deployment will just serve as early testing, and all of the software already deployed will ready for bigger blocks.

But if there is still no consensus among developers but the “bigger blocks now” movement is successful, I’ll ask for help getting big miners to do the same, and use the soft-fork block version voting mechanism to (hopefully) get a majority and then a super-majority willing to produce bigger blocks. The purpose of that process is to prove to any doubters that they’d better start supporting bigger blocks or they’ll be left behind, and to give them a chance to upgrade before that happens.

Because if we can’t come to consensus here, the ultimate authority for determining consensus is what code the majority of merchants and exchanges and miners are running.22

On July 21, 2015, Pieter Wuille, another Bitcoin developer, who had worked with Mike Hearn at Google in the past, proposed a hardfork blocksize increase. Pieter was regarded as being on the “small block” side of the argument. To me, this appeared to be a compromise proposal, a response to the pressure from Gavin. The proposal was numbered BIP 103 and acknowledged Wladimir Van Der Laan and a developer called Gregory Maxwell for their suggestions23, indicating their potential support. The proposal was for the hardfork to activate in January 2017, at which point the blocksize limit would increase by 17.7 percent per annum until the year 2063. The proposal did not include any activation methodology. It appeared to be meant as a catalyst for further discussion and then, once agreement had been reached, the activation methodology could be determined.

I consider this offer as a significant moment. The blocksize increase schedule did seem a bit conservative; however, I thought it was part of a negotiation. I expected Gavin to react positively to the offer, perhaps provide a counter offer, and the sides could gradually move towards each other. It appeared as if we were slowly moving towards a resolution. To my astonishment, Gavin and the large blockers did not react positively to BIP 103 at all. They regarded the proposed increase as so small that it was more of an insult than progress. Unfortunately, BIP 103 did not seem to help. With the 17.7 percent annual increase proposed in BIP 103, it seemed likely that demand for Bitcoin transactions would exceed this level of growth. In contrast, the large blockers wanted to ensure exactly the opposite; they wanted the blocksize limit to increase faster than demand. If both sides wanted the opposite, then could compromise really be achieved?

To the large blockers, the priority was about the user experience. Avoiding full blocks was key, otherwise users would have to wait for an unpredictable amount of time for their transactions to confirm. What merchant would adopt Bitcoin as a payment method if it was as unreliable as this? Forcing users to bid against each other in a bidding war for blockspace would, by definition, deny some users the ability to use Bitcoin, driving them away to something else. This was considered as a terrible business strategy. What kind of platform succeeds when it deliberately drives away users?

To the small blockers, this was not such a problem. To them, full blocks would not be some kind of crisis; if anything, they were a sign of success. They indicated that Bitcoin was becoming popular, and a new equilibrium level of user adoption would occur, reflecting the blocksize limit constraint. They occasionally mocked the large blocker argument about fees getting too high and causing users to leave, likening it some kind of paradox: “Nobody goes there anymore… it’s too crowded.”

In addition to this, small blockers tended to consider full blocks as both necessary and inevitable in the long term anyway. It was necessary to prevent a fee market death spiral when the block subsidy was low. It was also necessary to ensure miners would move the chain forwards once the subsidy became low. It was considered vital to always have a surplus of transactions which didn’t get in the blocks and were sitting there waiting to be included; that way, miners always had an incentive to build blocks. If there were no full blocks and no surplus transactions, why would a miner even bother mining if there is no revenue? Instead, miners would turn their machines off, save energy costs and wait for a backlog of transactions to build up again after each block. This would greatly reduce network security. Large blockers considered this reasoning as highly inappropriate. The block subsidy would be around for decades; why lose customers now for something that may be a problem in 20 to 100 years?

Small blockers also believed full blocks were inevitable anyway. After all, if blockspace was available, why not use it up? Anyone could store anything they liked in the blockchain, for instance their music collection or encrypted documents. Demand for cheap, highly-replicated storage was essentially unbounded, they argued. Asking for the limit to increase above expected demand was therefore nonsense. Indeed, one person could easily fill all the space up themselves. The retort to this point from the larger blockers circled back to the mining incentive argument; miners would not do this, they claimed, miners would not let this amount of data in the blocks. In addition to this, large blockers argued that blocks had not been full in the first five years of Bitcoin, a characteristic which they said contributed to its success. Why would anyone want to make the risky move of changing that now?

Unfortunately, the community was no closer to agreement and Gavin pushed ahead with his plan. In July 2015, Gavin is said to have sounded out some of the Chinese miners and mining pools on his proposal.24 There was a meeting In Beijing, at which miners are said to have disagreed with Gavin in pushing for an increase to 20 MB, as the Chinese communication infrastructure was considered too weak to quickly broadcast blocks of this size. Therefore, agreement was said to be reached for 8 MB blocks. Gavin was preparing behind the scenes for his big planned move in August, now just a few weeks away.

In the Q&A section of the Bitcoin XT website, the following was said:

Decisions are made through agreement between Mike and Gavin, with Mike making the final call if a serious dispute were to arise.25

In some sections of the community, this just re-enforced the impression that this was all a power grab by Mike. Who was Mike to “make the final call”? It was not that there was anything wrong with Mike, he seemed to be a pretty nice guy; it’s just that making this statement so blatantly didn’t feel like the right approach. Bitcoiners like to feel in control, they want to take ownership and have financial sovereignty. This was not part of the messaging of Bitcoin XT at all, which appeared too focused around Mike personally. Therein lies the second major blunder from the large blocker side: Bitcoin XT was too associated with Mike, rather than being dressed up as more of a grassroots user approach. Even focusing the software around Gavin was likely to improve the chances of success.