제5장 – 세그윗
한글
책 The Blocksize War의 5장을 아래에 싣습니다. 전체 책은 Amazon에서 구할 수 있습니다. 안내 말씀으로, 종이책 판매 수익의 50%는 분쟁, 전염병, 재난 또는 의료 서비스 배제로 영향을 받는 사람들에게 의료 지원을 제공하는 자선 단체인 Médecins Sans Frontières에 기부됩니다.
Scaling Bitcoin Hong Kong 둘째 날 첫 세션에서 주요 시간대 중 하나에 비트코인 개발자 Pieter Wuille이 Segregated Witness(세그윗)라는 것에 대해 발표했습니다. 세그윗은 새 클라이언트가 기존 클라이언트와 호환되지 않게 만들지 않으면서 비트코인 블록 크기를 늘리는 방식입니다. 즉 하드포크가 아니라 소프트포크였습니다. 비트코인 트랜잭션은 여러 구성 요소로 이루어지며 그 중 하나는 지출을 승인하는 서명입니다. 데이터 양을 기준으로 할 때 이 서명은 일반적으로 트랜잭션에서 가장 큰 부분을 차지합니다. 세그윗은 새로운 트랜잭션 형식이었으며 이 형식에서는 서명을 여전히 1 MB 제한을 가진 오래된 블록에 포함할 필요가 없었습니다. 세그윗으로 업그레이드한 클라이언트는 이러한 서명을 포함한 새로운 블록을 보게 됩니다. 이러한 새로운 클라이언트에게는 기존의 1 MB 블록 크기 제한이 제거되고 400만 유닛 가중치 제한으로 대체되었습니다. 가중치 제한은 바이트 단위의 비서명 데이터 양의 4배에 바이트 단위의 분리된 서명 데이터 양을 더한 값으로 정의되었습니다. 이는 계산에서 서명 데이터가 할인을 받는다는 의미였지만 전체 제한은 약 2 MB가 되며 이는 물론 많은 사람들이 원했던 것으로 보였습니다. 즉 약 2 MB로의 블록 크기 제한 증가입니다.
플로리다에 기반을 둔 Luke Dashjr라는 비트코인 개발자가 호환 가능한 비트코인 업그레이드인 소프트포크로 세그윗을 가능하게 만든 편법을 알아냈습니다. Luke는 가장 극단적인 작은 블록 지지자들 중 한 명으로 여겨졌으며 Gregory Maxwell과 함께 큰 블록 커뮤니티에서 미움받는 인물이었습니다. Luke는 남들과 다른 비주류 의견을 내세우는 것을 전혀 두려워하지 않았습니다. 어느 정도 이 독실한 가톨릭 신자이자 7명 자녀의 아버지는 기술 커뮤니티의 카산드라였습니다. 예외적으로 직설적이었습니다. 그러나 Luke는 분명히 비트코인에 대한 매우 강한 기술적 이해를 가지고 있었으며 남들과 다르게 보게 만든 그의 겉보기에 비선형적인 사고방식이 다른 개발자들이 제대로 알아내지 못한 이 편법을 구상하는 데 도움이 되었을 수 있습니다.
이를 이해한 사람들에게 세그윗은 훌륭한 윈윈 제안처럼 보였습니다. 네트워크는 2 MB 블록에 도달할 수 있으면서도 업그레이드가 호환되지 않는 문제를 피할 수 있었습니다. 이에 더해 오래된 서명 장치와 새로운 서명 장치는 서로 매끄럽게 상호 작용할 수 있었고 업그레이드는 전적으로 선택 사항이었습니다. 사용자는 세그윗으로 업그레이드하거나 이전과 같이 네트워크를 계속 사용할 수 있었습니다. 오래된 서명 장치의 관점에서 보면 새로운 방식의 트랜잭션에는 서명이 빠져 있을 것입니다. 그러나 서명 장치는 트랜잭션을 여전히 보고 전체장부에 포함되면 유효한 것으로 인식할 것입니다. 세그윗은 또한 단순한 블록 크기 제한 증가 하드포크보다 트랜잭션 용량이 더 빠르게 증가할 수 있음을 의미했습니다. 모든 사람이 업그레이드할 때까지 기다릴 필요가 없고 비교적 빠르게 새로운 블록 공간을 사용하기 시작할 수 있기 때문입니다.
세그윗이 비트코인에 확실한 이득으로 보였을 뿐만 아니라 의도적이든 아니든 블록 크기 전쟁에서 작은 블록 지지자들의 훌륭한 전술적 움직임으로도 보였습니다. 이 제안은 그저 너무 좋아서 반대할 만한 유효한 논거가 없었습니다. Gavin은 세그윗 제안을 지지해야 했으며 대체로 지지했습니다.39 확장 콘퍼런스가 시간을 벌고 이 아이디어를 내놓기 위한 뒤편의 음모였다면 잘한 일입니다! 여기서 이러한 비난을 하는 것이 아님을 밝혀둡니다. 큰 블록 지지자들은 하드포크를 위한 캠페인이 중단되었을 것이며 귀중한 시간을 벌 수 있었습니다. 당시 오래 활동한 큰 블록 지지자들 중 일부와 이야기를 나눈 기억이 있습니다. 그들은 자신들이 기발하다고 여긴 제안에 밀렸다고 생각한다고 말했습니다.
물론 이 모든 것은 이론상이었습니다. 모두가 세그윗을 이해하고 모든 행위자가 합리적인 가상 세계에서는 훌륭한 움직임이었습니다. 블록 크기 제한을 둘러싼 논쟁이 벌어지는 상황에서 이 제안은 제한을 없애고 다른 것으로 대체함으로써 논쟁을 무효화했습니다. 그러나 현실은 전혀 그렇지 않았습니다. 세그윗은 예외적으로 복잡했고 거의 아무도 이해하지 못했습니다. 이는 작은 블록 지지자들이 상대방의 지능을 과대평가한 또는 적어도 상대방이 컴퓨터 과학의 측면을 이해하는 능력을 과대평가한 첫 번째 주요 사례였습니다. 예를 들어 돌이켜보면 이 제안은 단순히 “2 MB 블록으로 증가” 같은 이름으로 불렸어야 했습니다. 대신 깊이 암호 같고 혼란스러운 이름을 가지고 있었으며 이는 명확하고 단순해서 이해할 수 있는 것을 원했던 큰 블록 지지자들에게 매우 의심스럽게 들렸습니다. 큰 블록 지지자들은 이 움직임이 적에게서 나왔다는 것을 감지한 듯했고 자신들의 방식을 원했습니다. 이 전쟁은 통제에 관한 것이었고 그들은 통제를 원했습니다. 그들은 세그윗을 더 큰 블록을 막기 위한 추가 지연 수단으로 보았습니다. 따라서 세그윗을 제대로 이해하지 못한 채 반대했습니다.
세그윗이 기술 커뮤니티에서 지지를 얻기 시작하자 큰 블록 지지자들 사이에서 잘못된 이해와 오해가 쌓이기 시작했습니다. 이러한 오해와 소문에는 다음이 포함되었으며 물론 이에 국한되지 않았습니다.
-
세그윗은 진짜 블록 크기 제한 증가가 아니고 트랜잭션을 압축할 뿐입니다. 세그윗의 경우 업그레이드하지 않은 클라이언트는 여전히 1 MB 블록만 보는 것이 사실이지만 오래된 노드가 1 MB 제한을 강제하기 때문에 하드포크에서도 마찬가지입니다. 세그윗의 경우 업그레이드한 노드는 1 MB보다 큰 블록을 보며 이는 아마도 큰 블록 지지자들이 원했던 것입니다;
-
비트코인은 디지털 서명의 사슬에 기반하는데 세그윗이 이를 제거함으로써 사슬을 깨뜨리고 보안 위험을 만듭니다;
-
채굴자가 세그윗을 위해 업그레이드하지 않고 블록을 생성하면 이 블록은 업그레이드한 클라이언트에게 거부됩니다. 이는 사슬 분할 위험을 높입니다. 이는 채굴자가 사슬을 분할하도록 의도적으로 설계된 맞춤형 소프트웨어를 사용하는 경우에만 일어날 것입니다;
-
사용자가 세그윗으로 업그레이드하면 업그레이드하지 않은 사용자에게 자금을 보낼 수 없게 됩니다;
-
세그윗 업그레이드는 되돌릴 수 있으며 그러면 세그윗 출력 안에 있는 코인이 누구에게든 도난당할 수 있습니다. 세그윗을 되돌리는 것은 하드포크가 될 것입니다.
많은 오해는 비합리적이었으므로 반박을 쉽게 명확히 말할 수 없었습니다. 이는 대부분의 사람들이 애초에 비트코인 트랜잭션의 기초를 제대로 이해하지 못했다는 사실에서 비롯된 것으로 보였습니다. 예를 들어 세그윗 형식 주소라는 표현이 자주 언급되었지만 세그윗에는 새롭거나 다른 주소 형식이 없었습니다. 사람들이 어차피 비트코인 트랜잭션의 작동 방식을 이해하지 못했다면 세그윗의 작동 방식을 설명하는 것은 단순히 불가능했습니다.
세그윗은 매우 복잡해서 Jeff Garzik조차 이해하지 못하는 듯했습니다. 그는 수수료 입찰을 위한 두 개의 바구니가 있을 것이라고 생각했습니다. 하나는 오래된 1 MB 제한과 관련되고 하나는 새로운 400만 유닛 가중치 제한과 관련된다는 것입니다.40 실제 사실은 두 제한인 블록 크기와 블록 가중치가 서로 일관되도록 구성되어 동등하므로 수수료 시장 바구니는 하나만 있게 된다는 것이었습니다. 이는 Jeff에 대한 비판이 아닙니다. 세그윗은 완전히 이해하고 파악하기가 극히 어려운 제안이었으며 이는 이 아이디어의 근본적인 약점으로 드러났습니다. 이는 기술적으로는 세그윗이 탄탄한 전진 방향이었을 수 있지만 관련된 복잡성 때문에 이를 비트코인 커뮤니티에 전달하는 것이 단순히 가능하지 않았다는 점을 잘 보여줍니다.
높은 복잡성 외에도 세그윗에 반대하는 유효한 논거가 일부 있었습니다. 세그윗의 이점과 증가된 블록 공간을 얻으려면 사용자 서명 장치가 새로운 트랜잭션 형식을 지원하도록 업그레이드해야 했습니다. 이는 트랜잭션 형식을 변경할 필요가 없는 더 단순한 하드포크 증가보다 더 많은 시간이 걸릴 수 있었습니다. 그러나 일부 사용자가 세그윗으로 업그레이드하자마자 업그레이드가 더 느린 뒤처진 사람들에게 블록 공간이 확보될 것이라는 점은 지적해야 합니다.
많은 작은 블록 지지자들에게 사용자들이 새로운 트랜잭션 형식으로 업그레이드하도록 만드는 것은 세그윗의 취지 중 하나였습니다. 블록 크기 제한 증가를 제공하는 데 더해 새로운 세그윗 트랜잭션 형식은 여러 버그도 수정했는데 바로 제3자 트랜잭션 가변성과 sighash 연산의 비선형 확장입니다. 여기서는 너무 자세히 들어가지 않겠습니다. 간단히 말하면 제3자 트랜잭션 가변성은 본질적으로 전체장부에 확정되기 전에 누구든 비트코인 트랜잭션의 트랜잭션 ID를 변경할 수 있고 트랜잭션은 여전히 유효하게 남는다는 능력 때문에 생기는 문제입니다. 이는 과거에 자금을 추적하는 데 어려움을 겪은 일부 서명 장치와 상인들에게 문제를 일으켰습니다. 이는 본질적으로 버그입니다. 이를 수정하는 것은 라이트닝이라는 2층 트랜잭션 네트워크를 위해서도 어느 정도 필요했습니다.
sighash 연산의 비선형 확장은 트랜잭션의 입력 수가 증가함에 따라 트랜잭션을 검증하는 데 필요한 해싱 연산 수가 선형이 아니라 2차적으로 증가한다는 의미입니다. 이 확장 문제는 공격자가 네트워크가 멈출 정도로 검증에 오래 걸리는 트랜잭션을 만들 수 있으므로 더 큰 블록에 장애물이었습니다. 이 문제는 실제로 블록 크기 제한 증가에 반대하는 작은 블록 지지자들이 든 주요 이유 중 하나였는데 공격자가 이 약점을 악용할 수 있었기 때문입니다. 공격자는 이러한 큰 트랜잭션을 많이 담은 블록을 구성할 수 있었으며 그 결과 일반적인 컴퓨터가 검증하는 데 여러 시간이 걸릴 수 있었습니다. 따라서 많은 작은 블록 지지자들에게 이 문제를 수정하는 것은 블록 크기 제한 증가의 전제 조건이었습니다. 그들은 이 약점을 간과하고 적대적 사고방식이 부족한 큰 블록 지지자들의 안일함을 비난했습니다. 반대로 큰 블록 지지자들은 비트코인이 거의 파괴 불가능하거나 반취약하다고 믿는 듯했으며 그들이 자주 표현한 대로였습니다. 작은 블록 지지자들은 시스템의 견고함을 개발팀의 노력과 신중함 덕분으로 돌렸지만 이는 커뮤니티에서 마땅히 받아야 할 만큼 인정받지 못했습니다. 대부분의 큰 블록 지지자들은 이러한 버그를 수정하는 것이 우선순위가 되어서는 안 되며 핵심은 블록 크기 제한이라고 믿었습니다.
그럼에도 세그윗을 사용할 때 이러한 버그들은 수정되었습니다. 작은 블록 지지자들의 관점에서 보면 이는 완전히 합리적입니다. 세그윗을 사용하면 잘 확장되지 않는 오래된 버그 있는 트랜잭션에는 오래된 1 MB 제한을 유지하면서 동시에 버그가 없는 새로운 트랜잭션에는 더 많은 공간을 제공할 수 있었습니다. 공학적 관점에서 보면 세그윗은 환상적으로 보였습니다. 문제는 다시 복잡성이었습니다. 대부분의 비트코인 사용자는 이러한 문제들을 전혀 몰랐고 관심도 없었습니다. 그리고 비트코인은 단순한 공학과 컴퓨터 과학 그 이상입니다. 사회적 시스템이기도 하고 살아 있는 결제 시스템이며 경제 시스템이자 금융 시스템입니다. 이러한 각도에서 볼 때 세그윗이 타당한지는 덜 명확했습니다.
세그윗 아이디어가 2015년 12월 홍콩 콘퍼런스에서 발표되었지만 여전히 구현되고 분석되고 테스트되고 논의되어야 했습니다. 세그윗이 마침내 Bitcoin Core에 출시된 것은 2016년 11월이 되어서였으며 10개월이 넘는 긴 기다림이었습니다. Bitcoin Core에 출시되었다고 해서 사람들이 세그윗을 사용하기 시작할 수 있다는 의미는 아니었습니다. 이는 프로토콜 규칙의 변경이었으며 더 정확히는 프로토콜 규칙의 강화 또는 소프트포크였습니다. 이는 활성화 방법이 있다는 의미였습니다. 선택된 활성화 방식은 채굴자가 지지를 신호해야 한다는 것이었습니다. 2,016블록 난이도 조정 구간에서 95퍼센트의 블록이 지지를 신호하면 2주간의 유예 기간 뒤 소프트포크가 활성화될 것입니다. 12개월 뒤에도 활성화가 일어나지 않으면 업그레이드는 중단될 것입니다.
큰 블록 지지자들에게 이 활성화 방법은 부적절했습니다. 그들은 무엇에 대해서도 95퍼센트 합의를 얻을 수는 없다고 주장했습니다. 이는 해시레이트의 5퍼센트만 가진 작은 채굴자 연합이라도 변화를 막을 수 있게 할 것입니다. 일부 큰 블록 지지자들은 이 95퍼센트 활성화 기준을 지연 전술로 보았으며 Bitcoin XT의 75퍼센트 기준을 선호했습니다. 큰 블록 지지자들은 채굴자 깃발을 투표 즉 의사결정 과정으로 보는 경향이 있었습니다. 이러한 맥락에서 95퍼센트는 별로 합리적으로 보이지 않았습니다. 반면 작은 블록 지지자들은 깃발을 신호 방식 또는 안전 기능으로 보았습니다. 그들의 관점에서 사용자는 프로토콜 규칙을 결정하며 채굴자 신호는 새로운 규칙으로 안전하게 전환하기 위해 필요했습니다. 이는 정치적 투표 과정으로 여겨지지 않았습니다.
게다가 95퍼센트는 아무 데서나 뽑아낸 것이 아니었습니다. 직전 세 번의 비트코인 소프트포크는 모두 같은 95퍼센트 기준으로 활성화되었습니다. 2015년 7월 BIP 66(서명을 DER 인코딩으로 제한), 2015년 12월 BIP 65(Check Lock Time Verify), 그리고 2016년 7월에 동시에 활성화된 세 가지 다른 소프트포크인 BIP 68, BIP 112와 BIP 113이었습니다. 세그윗은 같은 또는 약간 수정된 활성화 방법을 계속 사용하기로 했을 뿐입니다. 이러한 이전 소프트포크들이 완벽하게 진행되지 않았다는 점은 주목해야 합니다. 2015년 7월 BIP 66 활성화는 몇 블록 동안 사슬 분할을 일으켰는데 채굴자들이 업그레이드했다고 신호했음에도 소프트포크를 위해 업그레이드하지 못한 것으로 보였기 때문입니다. 2016년 7월 업그레이드도 예상보다 오래 걸렸고 커뮤니티는 채굴 풀에 지지 신호를 보내도록 요청해야 했습니다. 논쟁에서 큰 블록 측에 있던 채굴 풀은 이 관련 없는 소프트포크에 대한 업그레이스가 더 느렸으며 아마도 Bitcoin Core에 대한 어느 정도의 환멸 때문이었을 것입니다.
위의 역사와 커뮤니티의 새로운 긴장을 고려하면 세그윗이 출시되었을 때 채굴자들이 세그윗을 활성화할지 여부는 상당히 불확실했습니다. 실제로 채굴 풀 중 하나인 ViaBTC는 클라이언트가 출시되기 전부터 업그레이드를 지지하지 않겠다고 이미 밝혔습니다.41 세그윗은 공학적 마법이었지만 갈등의 긴장을 가라앉히는 데는 거의 도움이 되지 않았습니다.
39
https://twitter.com/gavinandresen/status/800405563909750784
40
https://www.slideshare.net/jgarzik/bitcoin-status-report-on-chain-scaling-aug-2016
41
영문 — Chapter 5 – SegWit
Chapter 5 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 first session of the second day of Scaling Bitcoin Hong Kong, during one of the prime slots, Bitcoin developer Pieter Wuille gave a talk on something called Segregated Witness (SegWit). SegWit is a way of increasing the Bitcoin blocksize, without the new client being incompatible (i.e. it was a softfork rather than a hardfork). A Bitcoin transaction consists of various components, one of which is the signature, authorising the spend. This signature is typically the largest part of the transaction, based on the amount of data. SegWit was a new transaction format, where the signature would not need to be included in the old block, which still had a 1 MB limit. Clients that upgraded to SegWit would see a new block, which included these signatures; for these newer clients, the old 1 MB blocksize limit was removed and replaced by a 4 million unit “weight limit”. The weight limit was defined as four times the amount of non-signature data in bytes plus the amount of segregated signature data, in bytes. This meant that the signature data received a discount in the calculation, but the overall limit would be around 2 MB, which is of course what many people seemed to want: a blocksize limit increase to around 2 MB.
A Florida-based Bitcoin developer called Luke Dashjr had figured out a hack, which made SegWit possible as a compatible (softfork) Bitcoin upgrade. Luke was regarded as one of the most extreme small blockers and was another hate figure in the large block community, alongside Gregory Maxwell. Luke was not at all scared of standing out from the crowd with his non-consensus opinions. To some extent, the committed Catholic and father-of-seven was the Cassandra of the technical community; exceptionally strident. However, Luke clearly had a very strong technical understanding of Bitcoin, and his apparent non-linear thinking, which made him see things differently from others, may have helped him conceive of this hack that the other developers couldn’t quite work out.
To those that understood it, SegWit seemed like a brilliant win-win proposal. The network could get to 2 MB blocks, yet we avoided the problem of the upgrade being incompatible. In addition to this, old wallets and new wallets could seamlessly interact with each other and the upgrade was entirely optional: users could either upgrade to SegWit, or continue using the network as before. From the perspective of old wallets, the new style transactions would be missing a signature. However, the wallet would still see the transaction and recognise it as valid once it was included in the blockchain. SegWit also meant that transaction capacity could potentially increase faster than with a simple blocksize limit increase hardfork, because we would not need to wait for everyone to upgrade and we could begin using the new blockspace reasonably quickly.
Not only did SegWit appear to be a solid win for Bitcoin, it also appeared to be a brilliant tactical move, whether intentional or not, from the small blockers in the blocksize war. The proposal was simply so good there were no valid arguments against it. Gavin would have to support the SegWit proposal, and for the most part he did.39 If the scaling conferences were a behind-the-scenes conspiracy to buy time and release this idea, then well played! It should be noted that I am not making this accusation here. The large blockers would have been stopped in their tracks with their campaign for a hardfork, and vital time would have been bought. I remember speaking to some of the long-standing large blockers at the time. They informed me that they thought they had been outmanoeuvred by what they considered to be an ingenious proposal.
Of course, this was all in theory. In a hypothetical world, where everyone understood SegWit and all actors were rational, it was a brilliant move. With people arguing over the blocksize limit, the proposal removed the limit and replaced it with something else, thereby negating the argument. However, in reality that was far from the case. SegWit was exceptionally complicated and almost nobody understood it. This was the first major example of the small blockers overestimating the intelligence of their opponents, or at least overestimating the ability of their opponents to understand aspects of computer science. For instance, in hindsight the proposal should have simply been called something like “Increase to 2 MB blocks”. Instead, it had a deeply cryptic and confusing name, which sounded highly suspicious to the large blockers, who wanted something clear and simple they could understand. Large blockers seemed to detect that this move came from their enemy and they wanted their way. This war was about control, and they wanted control. They saw SegWit as an additional stalling mechanism, to stop larger blocks. Therefore, without really understanding SegWit, they opposed it.
As SegWit began to gain traction in the technical community, misconceptions and misunderstandings among the large blockers started to mount. These misunderstandings and rumours included (but were certainly not limited to) the following:
-
SegWit is not a “real” blocksize limit increase, it only compresses transactions (it is true that, with SegWit, non-upgraded clients still only see 1 MB blocks, but this is also true with a hardfork since old nodes enforce a 1 MB limit. With SegWit, upgraded nodes do see blocks larger than 1 MB, which is presumably what the larger blockers wanted);
-
Bitcoin is based on a chain of digital signatures, which SegWit removes thereby breaking the chain and creating a security risk;
-
If a miner does not upgrade for SegWit and produces a block, this block will be rejected by the upgraded clients. This increases the risk of a chain-split (this should only happen if a miner uses custom software deliberately designed to split the chain);
-
If a user upgrades to SegWit, they will be unable to send funds to a user who has not upgraded;
-
The SegWit upgrade could be reversed, and then coins inside SegWit outputs could be stolen by anyone (reversing SegWit would be a hardfork).
Many of the misunderstandings were nonsensical and therefore a rebuttal could not easily be articulated. They appeared to stem from the fact that most people didn’t really understand the basics of Bitcoin transactions in the first place. For instance, the phrase “SegWit format address” was often mentioned, but SegWit didn’t have a new, or different, address format. If people didn’t understand the mechanics of Bitcoin transactions anyway, explaining the mechanics of SegWit was simply impossible.
SegWit proved so complicated that even Jeff Garzik didn’t seem to understand it. He thought there would be “two buckets” for fee bidding: one related to the old 1 MB limit, and one related to the new 4 million unit weight limit.40 In actual fact, the two limits, blocksize and blockweight, were constructed such that they were consistent with each other and therefore equivalent, such that there would only be one fee market bucket. This is not a criticism of Jeff; SegWit was an extremely difficult proposal to fully appreciate and understand, which proved to be a fundamental weakness of the idea. This just goes to illustrate that, while, technically, SegWit may have been a solid way forward, it was simply not possible to communicate this to the Bitcoin community due to the complexity involved.
There were some valid arguments against SegWit, apart from the high degree of complexity. In order to get the benefits of SegWit and the increased blockspace, user wallets had to upgrade to support the new transaction format. This could take more time than a simpler hardfork increase, which did not require transaction formats to change. It should be pointed out, however, that as soon as some users upgraded to SegWit, it would free up blockspace for the laggards who were slower to upgrade.
To many of the small blockers, getting users to upgrade to a new transaction format was part of the point of SegWit. In addition to providing a blocksize limit increase, the new SegWit transaction format also fixed a number of bugs, namely third party transaction malleability and the non-linear scaling of sighash operations. I won’t go into too much detail here. Briefly, third party transaction malleability is essentially an issue that arises because anyone has the ability to change the transaction ID of a Bitcoin transaction before it gets confirmed in the blockchain, and for the transaction to remain valid. This had caused issues for some wallets and merchants in the past, who had trouble tracking funds. It is essentially a bug. Fixing this was also somewhat necessary for a layer-two transaction network called lightning.
The non-linear scaling of sighash operations means that, as the number of inputs in a transaction increase, the number of hashing operations required to validate the transaction increases quadratically rather than linearly. This scaling problem was an impediment to larger blocks, as attackers could create transactions which took so long to verify that the network could grind to a halt. This issue was actually one of the main reasons cited by small blockers for opposing blocksize limit increases, as attackers could exploit this weakness. An attacker could construct a block which contained many of these large transactions, such that it could take an ordinary computer many hours to validate. Therefore, to many small blockers fixing this issue was a prerequisite to a blocksize limit increase. They derided the large blockers for complacency in overlooking this weakness and lacking an adversarial mindset. Conversely, large blockers appeared to believe Bitcoin was almost indestructible or antifragile, as they often put it. Small blockers attributed the robustness of the system to hard work and caution from the development team, but that wasn’t appreciated by the community to the extent it should be. Most large blockers believed that fixing these bugs should not be a priority; it was the blocksize limit that was key.
Regardless, when using SegWit, these bugs were fixed. From the point of view of small blockers, this made perfect sense. With SegWit, we could keep the old 1 MB limit for the old buggy transactions that did not scale well, and at the same time have more space available for new transactions without the bugs. From an engineering point of view, SegWit seemed fantastic. The problem, again, was the complexity; most Bitcoin users had no idea about these problems and did not care about them. And Bitcoin is more than just engineering and computer science. It is also a social system, a live payment system, an economic system, and a financial system. Whether SegWit made sense when looking through these angles was less clear.
Although the idea for SegWit was presented to the conference in December 2015 in Hong Kong, it still had to be implemented, analysed, tested and discussed. It was not until November 2016 when SegWit was finally released in Bitcoin Core, a long wait of more than 10 months. Even though it was released in Bitcoin Core, this did not mean that people could begin using SegWit. It was a change to the protocol rules, or, more precisely, a tightening of the protocol rules or a softfork. This meant there was an activation methodology. The chosen activation mechanics were that miners had to signal support. If 95 percent of blocks signalled support in a 2,016-block difficulty adjustment window, the softfork would then activate, after another two-week grace period. If, after 12 months, the activation had not occurred, the upgrade would be aborted.
To the large blockers, this activation methodology was inappropriate. You never get 95 percent agreement on anything, they argued. This would allow any small coalition of miners, with just five percent of the hashrate, to block the change. Some large blockers saw this 95 percent activation threshold as a stalling tactic, and preferred the 75 percent threshold in Bitcoin XT. Large blockers tended to see the miner flags as a vote, a decision-making process. In this context, 95 percent did not seem to make much sense. On the other hand, smaller blockers saw the flags as a signalling mechanism or safety feature. In their view, users decided on the protocol rules and miner signalling was necessary to ensure a safe transition to the new rules. It was not considered a political voting process.
Besides, 95 percent was not picked out of nowhere. The last three Bitcoin softforks had all activated using this same 95 percent threshold: BIP 66 (restricting signatures to DER encoding) in July 2015; BIP 65 (Check Lock Time Verify) in December 2015; and BIP 68, BIP 112 and BIP 113, three different softforks which activated at the same time in July 2016. SegWit had just chosen to continue with the same (or slightly modified) activation methodology. It should be noted that these previous softforks had not progressed perfectly. The activation of BIP 66 in July 2015 caused a chain-split for a few blocks, as miners appeared to fail to upgrade for the softfork, despite flagging that they had upgraded. The July 2016 upgrade also took longer than expected and the community had to lobby mining pools to signal support. Mining pools on the large block side of the debate were slower to upgrade for this unrelated softfork, perhaps due to a degree of disillusionment with Bitcoin Core.
Given the above history and the new tension in the community, when SegWit was released there was considerable uncertainty as to whether miners would activate SegWit or not. Indeed, one of the mining pools, ViaBTC, had already indicated they would not support the upgrade even before the client was released.41 While SegWit was engineering wizardry, it did little to calm tensions in the conflict.
39
https://twitter.com/gavinandresen/status/800405563909750784
40
https://www.slideshare.net/jgarzik/bitcoin-status-report-on-chain-scaling-aug-2016