413 / 736HEARN

Mike Hearn

bitcoinj 개발자이자 네트워크·결제 제안 저자

Mike Hearn은 bitcoinj 개발에 참여하고 지갑이 노드 및 상점과 통신하는 방법을 제안했습니다. 그의 작업을 살펴보면 평범한 비트코인 결제 뒤에서 무슨 일이 일어나는지, 여러 종류의 수신 알림이 왜 같은 뜻이 아닌지 이해할 수 있습니다.

Mike Hearn은 비트코인 개발자이자 기술적 해결책을 제안하는 문서인 여러 BIP의 공동 저자입니다. bitcoinj 라이브러리와 함께 연결 확인, 필요한 거래 선별, 결제 과정의 통신 방법에 기여했습니다. 휴대전화 지갑에서 결제를 기다리는 상점까지의 흐름을 따라가면 그의 기여를 이해하기 쉽습니다.

비트코인 지갑을 개발한다고 해서 통신 기능을 전부 처음부터 작성해야 하는 것은 아닙니다. 이미 만들어진 기능을 묶은 라이브러리를 바탕으로 앱을 만들 수 있습니다. bitcoinj가 그런 라이브러리입니다. AUTHORS 파일에는 여러 기여자와 함께 Mike Hearn의 이름이 있고, Git의 변경 이력을 참고하도록 안내합니다. 이를 통해 구체적인 기여를 추적할 수 있습니다. Hearn 혼자 모든 기능을 작성했다거나 지금도 프로젝트 전체를 이끈다는 뜻은 아닙니다. [1]

bitcoinj는 로컬에 Bitcoin Core를 설치하지 않아도 지갑을 관리하고 거래를 보내거나 받을 수 있게 하는 Java 라이브러리입니다. 휴대전화에는 Simplified Payment Verification의 약자인 SPV, 즉 간소화된 결제 검증이 유용합니다. 모든 거래를 완전히 검증하는 대신 블록 헤더와 지갑에 관련된 거래를 다뤄 데이터 사용량과 기기 자원을 줄입니다. 문서는 실험적인 전체 검증 모드도 설명합니다. 둘은 다른 방식입니다. 가볍게 동작한다는 말은 모든 규칙을 똑같이 검사하되 속도만 빠르다는 뜻이 아닙니다. [2]

노트북이 절전 상태에서 깨어났다고 생각해 봅시다. 다른 노드와의 연결이 열려 있는 것처럼 보여도 실제로는 작동하지 않을 수 있습니다. Hearn의 BIP 31은 nonce를 담은 ping을 보내도록 합니다. 여기서 nonce는 특정 요청을 구분하는 숫자입니다. 상대는 pong 메시지에 같은 숫자를 담아 돌려줍니다. 프로토콜 버전이 60000을 초과하면 요청과 응답을 연결하고 응답 시간을 잴 수 있습니다. 이것은 통신 확인입니다. 답장이 왔다는 사실만으로 노드가 정직하거나 결제가 유효하다는 것이 입증되지는 않습니다. [3]

휴대전화가 자신과 무관한 거래까지 내려받아야 할까요? Hearn과 Matt Corallo의 BIP 37은 일치할 가능성이 있는 데이터를 골라내는 작은 도구인 Bloom 필터를 설명합니다. filterload는 필터를 설정하고, filteradd는 항목을 추가하며, filterclear는 필터를 제거합니다. 무관한 거래가 통과할 수도 있는데, 이를 거짓 양성이라고 합니다. 필터가 정밀하면 전송량은 줄지만 상대 노드가 거래를 지갑의 IP 주소와 연결하기 쉬워질 수 있습니다. 데이터를 아낀다고 개인정보까지 자동으로 보호되는 것은 아닙니다. [4]

휴대전화는 받은 거래가 실제로 특정 블록에 속하는지 확인해야 합니다. BIP 37의 merkleblock 메시지는 Merkle 증명에 필요한 데이터를 제공합니다. 데이터의 지문에 해당하는 해시 몇 개로 거래와 블록 헤더에 있는 통합 지문 사이의 연결을 검사할 수 있으므로 블록 전체를 받을 필요가 없습니다. 그러나 그 증명이 상대가 다른 거래를 숨기지 않았다는 사실까지 보장하지는 않습니다. SPV는 거래의 유효성을 완전히 검사하는 방법을 대신하지도 않습니다. bitcoinj 문서는 공격자가 지갑의 모든 연결을 장악하고 보여 줄 정보를 고를 때 생기는 위험을 설명합니다. [4] [5]

물건을 살 때는 금액과 받는 사람을 알아야 합니다. Gavin Andresen과 Hearn의 BIP 70은 이를 위해 PaymentRequest를 도입합니다. 메시지에는 거래가 자금을 어디에 배정할지 지정하는 출력, 금액, 선택적인 요청 만료 시점 등 결제 정보가 담깁니다. 상점의 신원은 웹 서버와 비슷하게 X.509 인증서로 인증할 수 있습니다. 하지만 이런 인증이 없는 요청인 pki_type none도 허용됩니다. 따라서 결제 요청 형식을 썼다는 사실만으로 상점의 신원이 인증되었다고 볼 수는 없습니다. [6]

요청에 결제 서버가 지정되어 있으면, 결제를 승인한 뒤 지갑이 그 서버에 Payment 메시지를 보냅니다. 응답인 PaymentACK은 상점이 처리를 위해 결제를 접수했다는 뜻일 수 있습니다. 고객에게 유용하지만 여전히 상점 서버의 알림일 뿐, 블록 확인의 증거는 아닙니다. 마찬가지로 refund_to는 상점이 필요할 때 환불할 곳을 알려 줄 뿐, 그 필드가 돈을 돌려주지는 않습니다. 앱은 결제에 관한 메시지와 실제 자금 이동을 구별해야 합니다. [6]

오래된 안내서를 읽으면 그 절차가 어디서나 작동할 것처럼 느낄 수 있습니다. 등록부의 BIP 70 상태는 Deployed, 즉 구현되어 사용된 상태입니다. 그러나 Bitcoin Core 0.20.0 릴리스 노트에는 이 프로그램에서 지원을 완전히 제거했다고 적혀 있습니다. 모순은 아닙니다. 과거에 사용된 명세를 오늘날 모든 클라이언트가 지원해야 하는 것은 아니기 때문입니다. Hearn의 작업은 지갑의 발전을 이해하는 데 도움이 되지만, 실제로 적용하려면 해당 프로그램과 버전에서 제공하는 기능도 확인해야 합니다. [6] [7]

더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Jeff Garzik, Gloria Zhao, Merkle Tree. 다음 항목에서도 이 글을 참조합니다 Jeff Garzik, Gloria Zhao.

DOC · 001bitcoinj — recorded contributors문서 DOC · 002bitcoinj — library and verification modes문서 DOC · 003BIP 31 — Pong message문서 DOC · 004BIP 37 — connection Bloom filtering문서 DOC · 005bitcoinj — security model문서 DOC · 006BIP 70 — Payment Protocol문서 DOC · 007Bitcoin Core 0.20.0 — BIP70 removal문서
개정일: 1차 출처 우선 · 투자 조언이 아닙니다