Jeff Garzik은 jgarzik이라는 계정명으로 알려진 개발자입니다. 비트코인 소프트웨어와 구체적인 변경이나 절차를 설명하는 문서인 BIP를 작성했습니다. 그의 기여는 비트코인이 발전하는 방식을 보여 줍니다. 작성자는 코드를 쓰고 규칙을 제안할 수 있지만, 전체 네트워크에 채택을 명령할 수는 없습니다.
Jeff Garzik은 GitHub에서 jgarzik이라는 이름을 사용합니다. 개별 저장소, 즉 코드와 변경 이력을 공개해 두는 곳에서 그의 작업을 살펴볼 수 있습니다. 한 사람에게 막연히 “비트코인을 운영하는 사람”이라는 역할을 부여하는 것보다 유용합니다. 프로그램이라면 무엇을 하는지와 어느 버전인지를, 제안이라면 무엇을 바꾸려 했는지를 확인해야 합니다. 개발자 프로필만으로 다른 사람들이 실행할 소프트웨어 버전이 결정되지는 않습니다. [1]
Garzik의 cpuminer를 소개하는 README는 이를 CPU, 즉 컴퓨터 프로세서로 비트코인을 채굴하는 프로그램이라고 설명합니다. 멀티스레드 방식은 동시에 실행되는 여러 작업 흐름에 계산을 나눌 수 있게 합니다. Litecoin과 Bitcoin용 pooler/cpuminer는 이 프로그램에서 파생되었다고 명시합니다. 기존 코드를 가져와 별도로 발전시키는 것을 프로젝트의 fork라고 부릅니다. 이 행위만으로 비트코인 네트워크가 분리되지는 않으며, 파생판에 나중에 추가된 기능이 Garzik의 원본에도 있었다고 볼 수는 없습니다. [2] [3]
다른 예로 Picocoin이 있습니다. 여기에는 개발자가 비트코인 애플리케이션을 만드는 데 활용할 수 있는 C 언어 라이브러리 libccoin이 포함됩니다. 하지만 README는 관련 HD 지갑과 brd 노드를 WIP, 즉 개발 중이라고 표시합니다. HD 지갑은 공통된 출발점에서 여러 키를 파생하며, 노드는 비트코인 네트워크와 통신하도록 설계됩니다. 저장소는 2024년 2월 15일 아카이브 처리되었습니다. 역사를 공부하는 데 유용하지만, 코드가 공개되어 있다는 사실만으로 완성되고 유지보수되며 개인 저축을 맡기기에 안전한 제품이라고 판단할 수는 없습니다. [4]
한 노드가 연결된 상대 노드에 어떤 미확인 거래가 있는지 알고 싶다고 해 봅시다. Garzik의 BIP 35는 이 작업을 다룹니다. mempool 메시지로 목록을 요청하면 inv 응답에 거래 식별자인 해시가 담겨 오고, 이후 getdata로 거래 데이터 자체를 요청할 수 있습니다. Mempool은 확인 전 거래가 머무는 각 노드의 “대기실”이며, 전 세계가 공유하는 하나의 목록이 아닙니다. Bitcoin Core 문서의 getrawmempool 명령도 특정 노드의 내용을 반환합니다. 거래가 거기에 있다고 해서 블록에 확인되었다는 뜻은 아닙니다. [5] [8]
블록 크기는 거래를 담을 공간뿐 아니라 전송과 검증에 필요한 자원에도 영향을 줍니다. Garzik, Tom Harding, Dagur Valberg Johannsson은 BIP 100에서 채굴자가 블록에 기록한 투표에 따라 한도를 조정하자고 제안했습니다. 2016블록마다 다시 계산하고 블록 기준 75%의 지지를 요구하며, 매번 변경할 수 있는 폭도 제한하는 방식입니다. 사람 수로 표를 세는 투표가 아닙니다. 등록부는 제안을 Closed, 즉 종료 상태로 표시합니다. 문서의 설명이 전체 비트코인 네트워크의 채택을 입증하지는 않습니다. [6]
원래의 1 MB 한도를 계속 검사하는 일반 노드를 생각해 보세요. 더 큰 블록을 받으면, 해당 채굴자가 한도 상향을 지지하더라도 이 노드는 블록을 거부합니다. BIP 100은 바로 이런 분리를 경고합니다. 블록에 기록된 표는 새 소프트웨어가 해석할 데이터이지, 옛 프로그램을 고치는 명령이 아닙니다. 기존 규칙이 거부하던 블록을 허용하는 변경은 Hard Fork입니다. 여기서 fork는 GitHub에 단순히 파생 프로젝트를 만드는 것과 다른 의미입니다. [6]
Garzik의 BIP 102는 한도를 한 번에 2 MB로 높이는 다른 방법을 제안했습니다. 활성화하려면 정해진 시간 조건과 최근 1000블록 중 95%의 지지 신호를 동시에 충족해야 했습니다. 조건이 충족되어도 오래된 검증 프로그램이 자동으로 업데이트되지는 않으므로, 그 프로그램은 큰 블록을 계속 거부합니다. 이 제안 역시 Closed 상태입니다. 제안된 변경을 기록한 문서이며, 오늘날 비트코인의 블록 크기 규칙을 설명하는 문서는 아닙니다. [7]
각 BIP는 내용과 상태를 함께 읽어야 합니다. BIP 35는 노드 간 서비스와 통신을 다루는 Peer Services 계층에서 Deployed, 즉 배포됨으로 표시됩니다. BIP 100과 BIP 102는 어느 블록을 유효하게 인정할지에 관한 것이므로 Consensus (hard fork) 계층에서 Closed로 표시됩니다. 같은 작성자가 두 분야에서 일하더라도 결과는 다를 수 있습니다. 네트워크 메시지 하나가 성공적으로 도입되었다고 해서 그 사람의 모든 규칙 변경안도 도입된 것은 아닙니다. [5] [6] [7]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Cynthia Lummis, Mike Hearn, 블록 크기 전쟁. 다음 항목에서도 이 글을 참조합니다 Mike Hearn.