비트코인 타임스탬프가 증명하는 것: OpenTimestamps 작동 원리와 .ots 파일 검증 방법

OpenTimestamps 증명 같은 비트코인 타임스탬프는 바로 그 파일 하나가 늦어도 특정 비트코인 블록의 시각에는 존재했음을 보여 줍니다. 오차는 한두 시간 정도입니다. 누가 그 파일을 썼는지, 내용이 옳은지, 같은 아이디어를 먼저 떠올린 사람이 없었는지는 보여 주지 않습니다. 그리고 타임스탬프를 만든 쪽을 믿지 않고도 무료 소프트웨어로 직접 확인할 수 있습니다.

비트코인 타임스탬프는 무엇을 증명하나요?#

비트코인 타임스탬프의 개방형 형식인 OpenTimestamps는 이를 한 줄로 요약합니다. "타임스탬프는 어떤 데이터가 어떤 시점 이전에 존재했음을 증명한다"(opentimestamps.org¹, 2026년 10월 9일 확인). 사람들이 타임스탬프에서 그 이상을 읽어 낸다면 그것은 덧붙인 해석입니다.

증명의 대상은 아이디어가 아니라 바이트입니다. PDF에 타임스탬프를 찍으면 증명은 정확히 그 PDF만 다룹니다. 다시 내보내거나, 오타를 고치거나, 메타데이터를 지우면 증명은 새 파일과 더는 맞지 않습니다.

또 증명은 한쪽 방향만 말합니다. 알려 주는 것은 가능한 가장 늦은 날짜이지 만든 날짜가 아닙니다. 파일은 블록보다 몇 년 더 오래되었을 수도 있습니다. Peter Todd는 2016년 OpenTimestamps를 발표하면서 증거로서의 한계를 분명히 밝혔습니다. "타임스탬프는 어떤 메시지가 존재했음을 증명할 뿐, 바로 그 메시지가 존재했음을 증명하지는 않는다." 누군가 서로 모순되는 두 버전에 타임스탬프를 찍어 두었다가, 나중에 자기에게 유리한 쪽만 보여 줄 수도 있습니다(Todd, 2016⁷, 2026년 10월 9일 확인).

비트코인 타임스탬프가 보여 주는 것	보여 주지 않는 것
바로 이 바이트들이 늦어도 특정 블록의 시각에는 존재했다	파일이 언제 만들어졌는지
파일이 여전히 증명과 맞는다면 바뀌지 않았다	누가 썼는지, 누가 타임스탬프를 찍었는지
증명을 만든 서비스를 믿지 않아도 증명이 성립한다	내용이 옳은지, 심사를 거쳤는지, 독창적인지
	다른 누구도 먼저 갖고 있지 않았다는 것, 법적 우선권이나 소유권

누가 만들었는지는 별개의 질문입니다. 서명은, 서명 키를 누가 관리하는지 아는 것과 함께, 이 질문에 답하는 데 도움이 됩니다. 아직 발표하지 않은 아이디어가 걱정이라면 연구 아이디어를 선점당하지 않으려면 글을 보십시오.

OpenTimestamps는 어떻게 작동하나요?#

지문 만들기, 묶기, 고정하기, 업그레이드의 네 단계를 거칩니다.

1. 파일이 지문이 됩니다

클라이언트는 파일의 SHA-256 해시, 즉 64자짜리 지문(fingerprint)을 계산합니다. 같은 바이트는 언제나 같은 지문을 내고, 1바이트만 바뀌어도 완전히 다른 지문이 나오며, 지문을 되돌려 파일을 얻을 수는 없습니다. 타임스탬프를 찍은 파일에 공백 하나만 더해도 공식 클라이언트는 File does not match original!이라며 거부합니다(2026년 10월 9일 시험).

컴퓨터 밖으로 나가는 것은 지문뿐입니다. 클라이언트는 지문을 보내기 전에 무작위 논스(nonce)도 섞습니다. 그래서 README²의 표현대로 "원격 캘린더는 타임스탬프를 찍는 어떤 것의 내용에 대해서도 아무것도 알지 못한다".

알아 둘 만한 빈틈이 하나 있습니다. .ots 파일 자체에는 타임스탬프를 찍은 대상의 SHA-256 값이 그대로 기록됩니다(ots info가 첫 줄에 출력합니다). 유전자 이름이나 한 줄짜리 주장처럼 짧고 짐작하기 쉬운 텍스트라면, 증명을 가진 사람은 누구나 그럴듯한 후보를 해시해 보고 어느 것이 맞는지 알아낼 수 있습니다. 타임스탬프를 찍을 대상에 무작위 솔트(salt)를 섞으면 이 빈틈이 막힙니다. Papex는 이렇게 하므로, 짧은 텍스트라도 지문에서 되살려 낼 수 없습니다.

2. 캘린더 서버가 여러 지문을 묶습니다

파일마다 비트코인 트랜잭션을 하나씩 쓰는 대신, 공개 캘린더 서버(calendar server)는 제출된 지문을 모아 머클 트리(Merkle tree)를 만듭니다. 해시를 둘씩 짝지어 함께 해시하는 일을 단계마다 되풀이해, 마지막에 루트 해시 하나만 남깁니다. Todd가 든 예는 "그 1만 개 파일로 머클 트리를 만들고, 그 트리의 꼭대기를 트랜잭션 하나로 타임스탬프한다"는 것입니다.⁷ 공개 캘린더는 "무료로 쓸 수 있고, 가입이나 API 키가 전혀 필요 없습니다"(opentimestamps.org¹).

증명에는 지문에서 그 루트까지 가는 경로가 기록됩니다. 단계마다 이웃한 어느 해시를 어느 쪽에 붙이는지가 적힙니다.

3. 비트코인 트랜잭션 하나가 루트를 확정합니다

캘린더는 루트를 비트코인 트랜잭션에 써넣습니다. 채굴자가 그 트랜잭션을 블록에 넣으면 블록 헤더가 그것을 확정(commit)합니다. 헤더의 머클 루트는 "이 블록에 포함된 모든 트랜잭션의 해시에서 도출되며, 그래서 헤더를 바꾸지 않고는 그 트랜잭션 중 어느 것도 바꿀 수 없다"(비트코인 개발자 문서⁸, 2026년 10월 9일 확인). 헤더에는 블록의 시각도 들어 있습니다.

파일에서 블록 헤더까지 이어지는 사슬의 어느 곳이든 바꾸면 해시가 맞아떨어지지 않습니다. 클라이언트의 마지막 검사가 바로 이것입니다. 계산한 값이 헤더의 머클 루트와 같아야 하고, 클라이언트가 보고하는 시각은 헤더의 시각입니다(python-opentimestamps 소스 코드⁵).

4. 대기 중인 증명과 완성된 증명

.ots 파일은 곧바로 받지만 아직 완성되지 않은 상태입니다. 파일 끝에는 어느 캘린더가 일을 마무리할지 적은 메모가 붙어 있습니다. 클라이언트 README에 따르면 확인에는 "몇 시간이 걸립니다".² 나중에 ots upgrade를 실행하면 경로의 나머지를 받아 와 파일에 써넣습니다.

이 차이는 보관할 때 중요합니다. 미완성 증명은 그 캘린더가 계속 온라인에 있어야 하지만, 완성된 증명은 비트코인 블록 헤더만 있으면 됩니다. README는 앞으로의 클라이언트도 "관련 캘린더 데이터를 구할 수 있다면" 과거의 타임스탬프를 검증할 것이라고 말합니다. 그러니 증명을 업그레이드하고, 업그레이드한 파일을 보관하십시오.

캘린더에 기대는 것은 가용성이지 정직성이 아닙니다. Todd의 발표문은 이렇게 말합니다.

"캘린더는 권위를 갖지 않는다. 최악의 경우에도 서비스를 거부할 수 있을 뿐, 거짓 증명을 만들어 내지는 못한다."

비트코인 타임스탬프는 얼마나 정확한가요?#

분 단위가 아니라 시간 단위로 정확합니다. 각 블록 헤더의 시각은 채굴자가 직접 정하고, 비트코인은 느슨한 범위만 강제합니다. 블록의 시각은 "직전 11개 블록 시각의 중앙값보다 엄격히 커야" 하고, "풀 노드는 자기 시계 기준으로 2시간보다 더 미래의 헤더를 가진 블록을 받아들이지 않는다"(비트코인 개발자 문서⁸).

Bitcoin Wiki¹¹는 상한을 "네트워크 보정 시각 + 2시간"으로 적습니다. Bitcoin Core 27.0¹²부터 이 검사는 노드 자체의 시스템 시계를 씁니다. "네트워크 보정 시각은 합의 코드에서 제거되었다"(둘 다 2026년 10월 9일 확인). 어느 쪽이든 위키의 결론은 그대로입니다. "블록 시각은 한두 시간 이내로만 정확하다." Todd의 추정으로는 블록 시각은 "2~3시간 이내로 정확할 가능성이 매우 높고", "하루 이내라는 것은 거의 확실하다".⁷

그러니 비트코인 타임스탬프는 이렇게 읽으십시오. 이 버전은 늦어도 대략 그 블록의 시각에는 존재했고, 한두 시간의 허용 오차가 있다. 논문이 나오기 전에 데이터셋이 있었다거나, 결과가 나오기 전에 가설이 있었다는 것을 보여 주기에는 충분합니다. 같은 날 오후에 들어온 두 투고 가운데 어느 쪽이 먼저였는지 가리는 도구는 아닙니다.

실제 증명을 확인해 보면 어떤가요?#

Papex Labs의 교육용 기록 PXH-0BADXVXY7QM3(영어), "Educational record: P is not equal to NP"(교육용 기록: P는 NP와 같지 않다)는 이 방식을 보여 주는 공개 사례입니다. 연구 결과가 아니라 교육용 기록입니다. 이 기록의 확인 페이지(Check evidence on the record, 앱 화면은 영어입니다)는 타임스탬프 증거를 papex-timestamp-evidence.zip 파일 하나로 내려받게 해 줍니다. 이 파일에는 증명인 witness.json.ots와, 증명이 다루는 바로 그 바이트인 witness.json이 들어 있습니다.

이 기록에는 세 개의 시각이 붙어 있고, 각각 다른 시계에서 나옵니다.

시각(UTC, 2026년 10월 5일)	일어난 일	누구의 시계
11:18:33	버전 서명	Papex 서버
11:18:35	OpenTimestamps에 지문 제출	Papex 서버
11:26:56	비트코인 블록 970009	비트코인 블록 헤더

Papex를 믿지 않고 확인할 수 있는 것은 마지막 시각뿐입니다. 2026년 10월 9일에 한 확인은 다음과 같았습니다.

1. shasum -a 256 witness.json은 7ed0729a…f055a4를 냈고, 이는 ots info witness.json.ots의 "File sha256 hash" 줄과 같은 값입니다. 증명은 바로 이 바이트들에 관한 것입니다.
2. ots info는 경로 전체를 보여 주었습니다. 캘린더의 트리, 이어서 비트코인 트랜잭션(111204d7…22a7df), 그다음 블록 자체의 트랜잭션 트리를 따라 올라가는 13번의 짝짓기 단계가 나오고, 머클 루트가 74e144e8…f95781인 블록 970009에서 끝납니다.
3. mempool.space¹³와 blockstream.info¹⁴에서 본 블록 970009는 같은 머클 루트, 트랜잭션 5,787건, 블록 시각 2026-10-05 11:26:56 UTC를 보여 줍니다. 그 트랜잭션¹⁵은 이 블록에 들어 있고, OP_RETURN 출력에 캘린더의 32바이트 루트를 담고 있습니다.

결론: 서명된 증거는 비트코인의 허용 오차 안에서, 늦어도 2026년 10월 5일 11:27 UTC 무렵에는 존재했습니다. 이번에는 제출 후 약 8분 만에 블록이 나왔지만, 더 오래 걸리는 경우가 많습니다.

.ots 파일은 어떻게 검증하나요?#

세 가지가 필요합니다. .ots 파일, 타임스탬프를 찍었을 때와 똑같은 원본 파일(또는 그 SHA-256 값), 그리고 비트코인 블록 헤더를 읽을 방법입니다. 아래 명령은 공식 파이썬 클라이언트 0.7.2 버전의 README²와 내장 도움말에서 가져왔습니다(2026년 10월 9일 확인).

1. 클라이언트를 설치합니다. 파이썬 3이 필요합니다.

pip3 install opentimestamps-client

2. 증명을 원본 옆에 둡니다. 기본적으로 ots verify paper.pdf.ots는 같은 폴더에서 paper.pdf를 찾습니다. 파일을 직접 지정하려면 -f를, 해시만 있다면 16진수 SHA-256 값과 함께 -d를 씁니다.

ots verify -f paper-final.pdf paper.pdf.ots
ots verify -d <sha256-in-hex> paper.pdf.ots

3. 자신의 비트코인 노드로 검증합니다. 가장 강력한 확인 방법입니다. README에 따르면 검증에는 "로컬 Bitcoin Core 노드(프루닝 노드도 괜찮다)"가 필요합니다.² 클라이언트는 노드의 로컬 설정을 읽으며, 주소를 직접 넘겨줄 수도 있습니다.

ots --bitcoin-node http://USER:PASS@127.0.0.1:8332/ verify paper.pdf.ots

성공하면 README의 예처럼 나옵니다. Success! Bitcoin block 358391 attests existence as of 2015-05-28 CEST. 클라이언트는 날짜만, 그것도 사용자의 현지 시간대로 출력합니다. 시각까지 알려면 노드에 bitcoin-cli getblockhash 358391⁹로 물은 다음 bitcoin-cli getblockheader <hash>¹⁰를 실행하십시오. 블록의 time과 merkleroot가 나옵니다.

4. 노드가 없다면 마지막 단계를 직접 확인합니다. --no-bitcoin 옵션을 주면 클라이언트는 비트코인에 접속하는 일만 빼고 나머지를 모두 합니다.

ots --no-bitcoin verify witness.json.ots

클라이언트는 파일을 증명과 대조한 다음 남은 일을 출력합니다. 이 예에서는 To verify manually, check that Bitcoin block 970009 has merkleroot 74e144e89dee…입니다. 서로 독립된 블록 탐색기 두 곳에서 그 블록을 찾아 머클 루트와 시각을 비교하십시오. 이렇게 하면 신뢰의 대상이 자신의 노드에서 그 탐색기들로 옮겨 가므로, 두 곳을 쓰십시오. 비트코인과 대조한 것이 없으므로 명령은 여전히 오류 상태로 끝납니다.

5. 증명이 대기 중이라면 ots upgrade paper.pdf.ots를 실행한 뒤 다시 검증하십시오. 이전 파일은 .bak으로 남습니다. 증명을 읽어 보고 싶다면 ots info paper.pdf.ots가 증명의 모든 단계를 보여 줍니다.

메시지	뜻
Success! Bitcoin block N attests existence as of …	경로를 그 블록의 헤더와 대조해 확인했다
File does not match original!	파일이 타임스탬프를 찍은 파일과 바이트 단위로 같지 않다
Pending confirmation in Bitcoin blockchain	아직 블록에 들어가지 않았다. 나중에 업그레이드한다
Could not connect to Bitcoin node	노드를 찾지 못했다. --bitcoin-node나 --no-bitcoin을 쓴다

간단히 확인하려면 opentimestamps.org¹에서 .ots 파일과 타임스탬프를 찍은 파일을 브라우저로 검사할 수 있습니다. 이 프로젝트의 자바스크립트 라이브러리⁶는 노드가 없으면 공개 블록 탐색기를 대신 쓰며, README는 이 점을 솔직하게 밝힙니다. "블록 탐색기를 이용한 검증은 편리하지만 로컬 노드에 묻는 것만큼 안전하지는 않다."

RFC 3161 신뢰 타임스탬프와 비트코인 타임스탬프 중 무엇을 써야 하나요?#

RFC 3161¹⁶(2001년)은 기관이 발급하는 신뢰 타임스탬프(trusted timestamping)의 표준입니다. 해시를 타임스탬프 기관(Time Stamping Authority, TSA)에 보내면, TSA는 그 해시와 시각을 담은 서명된 토큰을 돌려줍니다. TSA는 "신뢰할 수 있는 시간 출처를 사용해야" 하고, 해시에만 타임스탬프를 찍어야 하며, "타임스탬프를 찍는 임프린트(imprint)를 어떤 방식으로도 검사하지 않을" 의무가 있습니다(2026년 10월 9일 확인). 검증할 때는 토큰의 서명을 확인하고, RFC가 덧붙이듯 TSA의 인증서가 폐지되지 않았는지도 확인합니다.

이때 신뢰는 그 기관에 놓입니다. 기관의 개인 키가 유출되면 "그 개인 키로 TSA가 서명한 어떤 토큰도 더는 신뢰할 수 없다".¹⁶ 키의 수명에는 끝이 있으므로, RFC는 신뢰를 갱신하려면 나중에 토큰에 다시 타임스탬프를 찍어야 한다고도 말합니다. 그 대가로 즉시 정밀한 시각을 얻습니다. 이 형식은 1초 미만의 단위까지 허용하고, 정확도를 선택적으로 명시할 수 있습니다.

연구 집단도 이 방식을 씁니다. 스탠퍼드의 한 연구실이 만든 timestamp.stanford.edu¹⁹는 브라우저에서 파일을 해시하고, 그 다이제스트에 "RFC 3161을 준수하는 여러 공개 타임스탬프 기관 서버를 통해" 타임스탬프를 찍습니다(2026년 10월 9일 확인).

	RFC 3161	OpenTimestamps(비트코인)
누구를 신뢰하나	TSA, 그 키와 인증서 체인	비트코인의 공개 이력. 캘린더는 가용성만
정밀도	초 단위 또는 그 이상	한두 시간
완성된 증명까지 걸리는 시간	즉시	보통 몇 시간
몇 년 뒤의 확인	TSA 인증서 상태 또는 갱신한 타임스탬프	모든 비트코인 노드가 가진 블록 헤더
비용	제공자에 따라 다름	무료 공개 캘린더

또 다른 차이는 법입니다. 영국과 EU에서 eIDAS 규정은 적격(qualified) 전자 타임스탬프에 "그것이 표시하는 날짜와 시각의 정확성, 그리고 그 날짜와 시각이 결합된 데이터의 무결성에 대한 추정"을 부여합니다(제41조, 영국판¹⁷, 2026년 10월 9일 확인). 적격 타임스탬프는 적격 신뢰 서비스 제공자가 서명하거나 봉인합니다(제42조¹⁸). 그런 추정이 필요하다면 어느 제공자를 쓸지 법률 자문가에게 물으십시오. 이 글은 법률 자문이 아닙니다.

각각이 맞는 경우는 다음과 같습니다.

• RFC 3161: 정밀한 시각이나 법적 추정이 필요할 때, 또는 쓰고 있는 실험 노트나 문서 시스템이 이미 이 방식을 지원할 때.
• OpenTimestamps: 한 회사의 키나 인증서에 기대지 않고 수십 년 뒤에도 누구나 확인할 수 있는 증명을 원하고, 한두 시간의 정밀도로 충분할 때. 사전 등록한 가설, 데이터셋, 코드 릴리스, 원고 버전이 대표적인 경우입니다.
• 둘 다: 두 방식은 실패하는 지점이 서로 달라서, 함께 쓰면 더 많은 경우를 감당합니다.

작업하면서 기록 남기기#

타임스탬프는 몇 달 뒤가 아니라 버전이 확정되는 시점에 만들 때 가장 쓸모가 있습니다. Papex는 이것을 서명 과정에 넣었습니다. 서명은 서명한 사람들을 기록의 정확히 한 버전과 연결합니다. 이후 수정은 별도의 서명과 날짜를 가진 새 버전이 되고, 이전 버전은 그대로 남습니다.

서명하면 그 버전의 솔트를 더한 지문만 Papex 밖으로 나갑니다. 이 지문은 OpenTimestamps로 타임스탬프를 받아 비트코인에 고정되며, .ots 증명은 위의 예와 똑같이 Papex 없이 어떤 OpenTimestamps 도구로도 확인할 수 있습니다. 지갑도 암호화폐도 필요 없습니다.

작업하는 동안 초안은 비공개로 남습니다. 서명한 뒤에는 그 버전을 비공개로 둘지, 초대한 사람과 공유할지, 공개할지 직접 정합니다.

한계는 이 글에서 설명한 그대로입니다. 타임스탬프는 어떤 버전이 어느 날짜까지 존재했음을 보여 주고, 서명은 누가 정확히 어느 버전에 서명했는지를 보여 줍니다. 둘 다 저자 자격, 소유권, 독창성, 정확성, 법적 우선권을 증명하지 않습니다. 또 서명 시각은 Papex 자체의 시계에서 나오고, 독립적인 시각은 비트코인 시각입니다. 특허가 걸려 있을 수 있다면 공개가 특허권에 영향을 줄 수 있으므로, 공개하기 전에 변리사나 소속 기관의 기술이전 부서와 상의하십시오.

papex.org에서 기록을 시작할 수 있습니다.

출처#

1. OpenTimestamps: A timestamping proof standard, 2026년 10월 9일 확인 ↩ a b c
2. OpenTimestamps Client README (GitHub의 opentimestamps-client), 2026년 10월 9일 확인 ↩ a b c d
3. OpenTimestamps Client 명령줄 옵션, otsclient/args.py, 2026년 10월 9일 확인
4. OpenTimestamps Client 검증 코드, otsclient/cmds.py, 2026년 10월 9일 확인
5. python-opentimestamps, BitcoinBlockHeaderAttestation (notary.py), 2026년 10월 9일 확인 ↩
6. javascript-opentimestamps README, 2026년 10월 9일 확인 ↩
7. Peter Todd, OpenTimestamps: Scalable, Trust-Minimized, Distributed Timestamping with Bitcoin (2016년), 2026년 10월 9일 확인 ↩ a b c
8. 비트코인 개발자 문서: Block chain, block headers, 2026년 10월 9일 확인 ↩ a b
9. 비트코인 개발자 문서: getblockhash, 2026년 10월 9일 확인 ↩
10. 비트코인 개발자 문서: getblockheader, 2026년 10월 9일 확인 ↩
11. Bitcoin Wiki: Block timestamp, 2026년 10월 9일 확인 ↩
12. Bitcoin Core 27.0 릴리스 노트, 2026년 10월 9일 확인 ↩
13. mempool.space: 비트코인 블록 970009, 2026년 10월 9일 확인 ↩
14. blockstream.info: 비트코인 블록 970009, 2026년 10월 9일 확인 ↩
15. mempool.space: 트랜잭션 111204d7…22a7df, 2026년 10월 9일 확인 ↩
16. RFC 3161: Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP), 2026년 10월 9일 확인 ↩ a b
17. eIDAS 규정(영국판), 제41조: Legal effect of electronic time stamps, 2026년 10월 9일 확인 ↩
18. eIDAS 규정(영국판), 제42조: Requirements for qualified electronic time stamps, 2026년 10월 9일 확인 ↩
19. 스탠퍼드 신뢰 타임스탬프 서비스(Stanford trusted timestamping service), 2026년 10월 9일 확인 ↩
20. Papex 기록 PXH-0BADXVXY7QM3, 2026년 10월 9일 확인