Peter Todd는 Bitcoin 개발자이자 시간 잠금 제안 BIP 65의 저자, 미확인 거래 교체 정책 BIP 125의 공동 저자, OpenTimestamps 개발자입니다. 각각 지출 조건, 결제 상태, 데이터의 존재 증명이라는 서로 다른 보장을 다룹니다. 하나가 다른 모든 보장까지 제공하는 것은 아닙니다.
어떤 계약서 버전이 분쟁이 시작되기 전에 존재했다는 사실을 입증해야 한다고 생각해 보세요. Peter Todd와 관련된 프로젝트 OpenTimestamps가 바로 이런 문제를 다룹니다. 2016년 당시 발표는 공개 시험 버전을 소개하고 개발과 테스트에 기여한 Riccardo Casatta에게 감사를 표했습니다. 이는 당시의 협업 기록이지, 프로젝트가 지금도 시험 단계에 머물러 있다는 뜻은 아닙니다. Todd는 미래의 지출 조건과 아직 확인되지 않은 결제도 연구했습니다. 먼저 이 두 분야부터 살펴보겠습니다. [1]
Todd의 BIP 65는 OP_CHECKLOCKTIMEVERIFY, 줄여서 CLTV를 도입했습니다. 이 명령은 특정 지출 경로를 사용하려면 정해진 블록 높이나 시간 경계에 도달하도록 조건을 걸 수 있습니다. 공동 저축에 수령인이 나중에만 사용할 수 있는 예비 접근 경로를 둔다고 생각해 보세요. 그전에는 시간 조건이 이 경로를 막습니다. 조건이 충족되어도 코인이 저절로 전송되지는 않습니다. 유효한 거래를 만들고 서명 같은 다른 요건도 충족해야 합니다. 별도 지출 경로가 있다면 그 경로에는 자체 조건이 적용되므로, 잠금이 모든 사용 방법에 적용된다고 볼 수는 없습니다. [2]
시간 잠금은 지갑 화면의 시계만 따라가는 기능이 아닙니다. BIP 65는 지출 조건을 정한 명령인 스크립트와 거래의 nLockTime 필드 사이 관계를 검사합니다. 둘 다 블록 높이 또는 시간 중 같은 종류의 경계를 사용해야 합니다. 입력의 nSequence 필드도 검사를 무력화하는 최종값이면 안 됩니다. 이는 절대적인 경계이며, 출력이 확인된 뒤 얼마나 지났는지를 재는 상대적 나이가 아닙니다. 조건을 만족해도 특정 초에 블록에 들어간다는 보장은 없습니다. 채굴자가 유효한 블록에 거래를 포함해야 합니다. [2]
전파된 거래는 각 노드가 보관하는 미확인 거래 모음인 mempool에 남아 있을 수 있습니다. 수수료가 오르면 송신자는 교체 거래로 더 높은 수수료를 제시하고 싶을 수 있습니다. David A. Harding과 Peter Todd는 최초의 opt-in 교체 정책을 BIP 125에 설명했습니다. 교체 가능 여부는 nSequence로 표시하거나, 해당 결제가 출력을 사용하는 미확인 선행 거래에서 물려받을 수 있었습니다. 따라서 개별 결제뿐 아니라 거래 간 의존 관계도 중요했습니다. 수수료를 높이면 도움이 될 수 있지만 즉시 확인을 보장하지는 않습니다. [3]
mempool에서의 교체는 노드가 확인 후보로 보관하는 거래를 바꿉니다. 이미 확인된 이력을 다시 쓰는 것은 아닙니다. 또한 BIP 125는 과거의 opt-in 정책을 설명하며, 모든 프로그램에 영원히 적용되는 규칙이 아닙니다. 이후 Bitcoin Core 버전들은 해당 신호 없이도 교체를 허용하는 동작을 표준으로 삼았지만, 교체 거래를 받아들이는 조건은 여전히 적용합니다. 수령인이 기억할 점은 신호가 없다는 사실만으로 결제가 최종 확정되었다고 볼 수 없다는 것입니다. 지갑의 ‘전송됨’ 표시 역시 확인된 블록에 들어갔다는 뜻과 다릅니다. [3] [6]
계약서 이야기로 돌아가 봅시다. OpenTimestamps는 특정 데이터가 입증된 시간 경계 이전에 존재했다는 사실을 검증할 수 있게 합니다. 내용의 짧은 디지털 지문인 hash와 Bitcoin에 연결된 증명을 사용합니다. 문서가 바뀌면 검증할 때 얻는 지문도 달라집니다. 그러나 타임스탬프 자체는 작성자, 내용의 진실성, 정확한 생성 순간을 증명하지 않습니다. 거짓 내용을 미리 작성해 타임스탬프를 받을 수도 있기 때문입니다. 증명은 데이터가 늦어도 언제까지 존재했는지 제한할 뿐, 그보다 얼마나 오래전부터 있었는지는 알려 주지 않습니다. [1] [4]
OpenTimestamps 클라이언트는 문서 자체를 캘린더 서버로 보내지 않습니다. 지문을 무작위 값과 함께 처리해 서버가 받은 데이터에서 내용을 추론하지 못하게 합니다. 여기서 캘린더는 요청을 모아 Bitcoin에 연결하도록 돕는 서비스입니다. 내용 보호가 완전한 익명성을 뜻하지는 않습니다. 비슷한 시각이나 함께 만든 증명은 요청 사이의 연관성을 드러낼 수 있습니다. .ots 파일은 문서의 백업이 아닙니다. 정확한 원본과 함께 보관해야 합니다. 지문으로 잃어버린 글을 복구할 수 없고, 수정한 사본은 이미 다른 데이터입니다. [5]
새 타임스탬프는 아직 확인된 Bitcoin 블록에 연결되지 않았을 수 있습니다. 따라서 .ots 파일이 있다는 것만으로 완료를 뜻하지는 않습니다. OpenTimestamps 클라이언트는 대기 중인 증명과 블록까지의 경로를 갖춘 완전한 증명을 구분합니다. ots upgrade 명령은 보충 자료가 준비되었을 때 가져와 저장할 수 있지만 블록 채굴을 강제하지는 못합니다. 이후 원본 데이터와 Bitcoin 체인을 기준으로 증명을 검증해야 합니다. 대기 중인 결제와 마찬가지로, 파일이나 알림의 등장보다 실제 상태가 중요합니다. [5]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Luke Dashjr, Mara van der Laan, Satoshi Nakamoto. 다음 항목에서도 이 글을 참조합니다 Luke Dashjr, Mara van der Laan.