Gavin Andresen

프로젝트 창시자가 물러난다고 소프트웨어가 스스로 관리되지는 않는다. 수정과 테스트, 새 버전 배포를 조율할 사람이 필요하다. 비트코인 초기에 Satoshi의 뒤를 이어 이 책임을 맡은 사람이 Gavin Andresen이었다. 2015년 11월 17일 행사에 맞춰 작성된 MIT 소개도 이 경력을 설명하며, 당시 수석 유지관리자로는 이미 Wladimir van der Laan을 적고 있다. 이는 소프트웨어 개발상의 역할이지 네트워크 소유권이 아니다. 오래된 약력만으로 현재의 저장소 접근 권한을 알 수도 없다. 저장소는 소스 코드를 함께 보관하는 공간이다. [1]

초보자가 디지털 화폐라는 생각을 이해해도 코인이 없으면 받거나 보내 보는 경험을 하기 어렵다. Andresen은 Bitcoin Faucet으로 이 장벽을 낮추려 했다. 2010년 6월 11일 발표한 이 서비스는 처음에 1,100 BTC를 준비하고 체험용으로 코인 다섯 개씩을 제공했다. 방문자는 채굴에 성공하기를 기다리거나 판매자를 찾을 필요가 없었다. Faucet은 이미 존재하는 자금을 나눠 주었으며 새 비트코인이나 블록 보상을 만들지 않았다. 목적은 첫 사용을 쉽게 하는 것이었지 화폐 발행 규칙을 바꾸는 것이 아니었다. [2]

2010년 6월 11일 답글에서 Andresen은 한도를 분명히 했다. IP 주소당 코인 다섯 개이며 매일 받는 것이 아니었다. IP 주소는 컴퓨터 네트워크의 연결을 식별한다. 비트코인 지갑 주소도 아니고 개인을 확실하게 구별하는 명단도 아니다. 따라서 서비스를 보호하는 것은 신원 확인과 다른 일이었다. 사람과 자동 프로그램을 구별하는 데 쓰이는 과제인 CAPTCHA는 당시 추가 방안으로 검토되었다. 이런 초기 상태는 이후 변경과 구분해야 한다. 오늘날의 비슷한 서비스를 보고 과거의 운영 방식을 추정해서는 안 된다. [2]

또 다른 기여는 별도의 실용적인 문제를 다뤘다. 수취인은 돈을 쓰기 전에 여러 서명이 필요하도록 정하고 싶을 수 있다. 송금인이 매번 이 규칙 전체를 처리해야 할까? 2012년의 BIP 16은 Pay to Script Hash를 설명한다. 지급은 조건을 담은 스크립트의 짧은 디지털 지문인 hash를 가리킨다. BIP는 번호가 붙은 비트코인 개선 제안이다. 여기서 redeemScript라고 부르는 스크립트 자체는 나중에 자금을 쓰는 사람이 제시한다. 조건이 사라지는 것이 아니라, 언제 누가 조건을 제시하는지가 달라진다. [3]

여러 사람이 동의해야 열리는 금고를 떠올려 보자. 그 규칙을 보여 준다고 돈이 나오는 것은 아니다. 마찬가지로 2012년 BIP 16은 제시된 redeemScript의 hash를 확인한 다음 그 조건을 실행하도록 한다. 스크립트를 안다는 사실은 필요한 서명을 대신하지 못한다. 삽입되는 이 스크립트에는 520바이트라는 기술적 한도도 있다. 바이트는 데이터 크기를 재는 단위다. 초보자에게 중요한 구분은 두 가지다. 올바른 규칙을 제시했는지, 그리고 그 규칙이 요구하는 것을 갖추었는지 각각 확인한다. [3]

2015년 Andresen은 최대 블록 크기를 점진적으로 늘리는 BIP 101을 제출했다. 문서는 이를 Hard Fork라고 설명한다. 새 규칙이 허용하는 일부 블록을 기존 규칙은 거부하게 되는 변경이다. 목록에서 이 제안의 상태는 종료를 뜻하는 Closed다. 반면 BIP 16은 도입되었다는 뜻의 Deployed로 표시된다. BIP 번호나 유명한 작성자가 있다고 활성화가 입증되는 것은 아니다. 제안을 읽을 때는 그 규칙이 실제로 쓰이기 시작했는지도 확인해야 한다. [4] [3]

블록 확대는 왜 논쟁거리가 되었을까? 큰 블록은 거래를 더 담을 수 있지만 데이터를 전송하고 받아 검증해야 한다. 그래서 2015년 BIP 101은 전송 비용과 더 높은 요구 수준이 대규모 운영자에게 유리할 위험도 다룬다. 느린 연결을 쓰는 사람과 대형 채굴 기업의 여건은 다를 수 있다. 기술 발전에 대한 작성자의 기대는 제안을 지지하는 논거이지 모든 미래 상황에서 측정된 결과가 아니다. 처리 용량과 네트워크를 독립적으로 검증할 수 있는 능력 사이에서 균형을 찾는 문제다. [4]

Bitcoin.org는 개발자가 사용자에게 규칙 변경을 강요할 수 없다고 설명한다. 어떤 소프트웨어를 실행할지는 사람들이 선택하기 때문이다. 함께 작동하려면 참여자들의 규칙은 서로 호환되어야 한다. Andresen은 제안을 쓰고 코드를 준비하며 다른 사람을 설득할 수 있었지만, 모두의 비트코인을 일방적으로 바꿀 수는 없었다. 따라서 서비스가 무엇을 가능하게 했는지, 코드가 무엇을 했는지, 네트워크가 무엇을 채택했는지 기여별로 살펴보는 편이 좋다. 이전의 공로가 이후의 모든 주장을 자동으로 옳게 만들지는 않는다. [5]