OpenTimestampsの仕組み：ビットコインのタイムスタンプは何を証明するのか

OpenTimestampsの証明のようなビットコインのタイムスタンプは、ある1つのファイルがそのままの形で、遅くとも特定のビットコインのブロックの時刻までに存在していたことを示します。誤差は前後1〜2時間です。誰がそのファイルを書いたのか、内容が正しいのか、同じアイデアを先に持っていた人がいないのかは示しません。そして、作った人を信頼しなくても、無料のソフトウェアで自分で確かめられます。

ビットコインのタイムスタンプは何を証明するのか#

ビットコインのタイムスタンプのためのオープンな形式であるOpenTimestampsは、これを1行でまとめています。「タイムスタンプは、あるデータがある時点より前に存在していたことを証明する」（opentimestamps.org¹、2026年10月9日確認）。タイムスタンプにそれ以上の意味を読み込むなら、それはすべて付け足しです。

証明の対象はアイデアではなく、バイト列です。PDFにタイムスタンプを付ければ、証明はそのPDFそのものだけを対象にします。書き出し直したり、誤字を直したり、メタデータを削ったりすれば、証明は新しいファイルとはもう一致しません。

また、示すのは一方の側だけです。分かるのは作成日ではなく、ありうる最も遅い日付です。ファイルはブロックより何年も古いかもしれません。Peter Toddは2016年にOpenTimestampsを発表した文章で、証拠としての限界をはっきり書いています。「タイムスタンプが証明するのは、あるメッセージが存在したことだけで、それが唯一のメッセージだったことではない」。矛盾する2つの版にタイムスタンプを付けておき、後で都合のよい方だけを見せることもできるのです（Todd, 2016⁷、2026年10月9日確認）。

ビットコインのタイムスタンプが示すこと	示さないこと
このバイト列そのものが、遅くともあるブロックの時刻までに存在していたこと	ファイルがいつ作られたか
今も証明と一致するなら、ファイルが変わっていないこと	誰が書いたか、誰がタイムスタンプを付けたか
証明を作ったサービスを信頼しなくても、証明が成り立つこと	内容が正しいこと、査読されたこと、独自であること
	誰も先に持っていなかったこと、法的な先取権、所有権

誰が作ったのかは別の問題です。それに答える助けになるのは署名で、署名の鍵を誰が管理しているかが分かっていることも必要です。気になっているのが未発表のアイデアなら、研究のアイデアを公開前に守る方法をご覧ください。

OpenTimestampsはどのような仕組みか#

フィンガープリントを作る、まとめる、ビットコインに固定する（アンカー）、アップグレードする、の4段階です。

1. ファイルがフィンガープリントになる

クライアントは、ファイルのSHA-256ハッシュ、つまり64文字のフィンガープリントを計算します。同じバイト列からは常に同じフィンガープリントが得られ、1バイト変わればまったく違うものになり、フィンガープリントからファイルを復元することはできません。タイムスタンプを付けたファイルに空白を1つ加えると、公式のクライアントは File does not match original!（元のファイルと一致しない）と表示して受け付けません（2026年10月9日に試しました）。

手元のコンピューターから外に出るのは、フィンガープリントだけです。クライアントは送信の前にランダムなノンスも混ぜるので、README²の言葉を借りれば、「リモートのカレンダーは、タイムスタンプを付けたものの内容について何も知ることがない」のです。

知っておくべき隙が1つあります。.otsファイル自体には、タイムスタンプを付けたもののそのままのSHA-256が記録されています（ots info の1行目に表示されます）。対象が遺伝子名や1行の主張のように短く推測しやすい文なら、証明を持っている人は誰でも、ありそうな候補をハッシュにして、どれが一致するかを確かめられます。タイムスタンプを付けるものにランダムなソルトを混ぜれば、この隙はふさがります。Papexはそうしているので、短い文でもフィンガープリントから復元することはできません。

2. カレンダーサーバーが多数のフィンガープリントをまとめる

ファイルごとにビットコインの取引を1つ使うのではなく、公開のカレンダーサーバーが送られてきたものを集めて、マークルツリーを作ります。ハッシュを2つずつ組にしてまとめてハッシュにすることを階層ごとに繰り返し、1つのルートハッシュが残るまで続けるのです。Toddが挙げる例は、「その1万個のファイルからマークルツリーを作り、ツリーの頂点に1回の取引でタイムスタンプを付ける」というものです。⁷ 公開のカレンダーは「無料で使え、登録もAPIキーも必要ない」とされています（opentimestamps.org¹）。

証明には、自分のフィンガープリントからそのルートまでの経路が記録されます。各階層で、隣のどのハッシュを、どちら側に加えるかです。

3. 1つのビットコインの取引がルートを固定する

カレンダーは、ルートをビットコインの取引に書き込みます。マイナーがその取引をブロックに含めると、ブロックヘッダーがそれを固定します。ヘッダーのマークルルートは「このブロックに含まれるすべての取引のハッシュから導かれ、ヘッダーを変えずにそれらの取引を変えることはできないようにしている」とされています（Bitcoinの開発者向けドキュメント⁸、2026年10月9日確認）。ヘッダーには、ブロックの時刻も入っています。

ファイルからブロックヘッダーまでの連なりのどこかを変えれば、ハッシュはつながらなくなります。クライアントが最後に確かめるのはまさにこの点です。計算した値がヘッダーのマークルルートと等しくなければならず、報告される時刻はヘッダーの時刻です（python-opentimestampsのソースコード⁵）。

4. 未完了の証明と完全な証明

.otsファイルはすぐに手に入りますが、それは未完了です。末尾には、どのカレンダーが仕上げるかを示す記載があります。クライアントのREADMEは、確定には「数時間かかる」としています。² 後で ots upgrade を実行すると、経路の残りを取得してファイルに書き込みます。

この違いは、保存の面で重要です。未完了の証明には、そのカレンダーがまだ稼働していることが必要です。完全な証明に必要なのは、ビットコインのブロックヘッダーだけです。READMEによれば、将来のクライアントが過去のタイムスタンプを検証できるのは「関連するカレンダーのデータが利用できる限り」です。証明はアップグレードし、アップグレードしたファイルを保管してください。

カレンダーに求めるのは稼働していることであって、正直であることではありません。Toddの発表の言葉では、こうです。

「カレンダーは権威ではない。最悪でもサービスを拒めるだけで、偽の証明を作ることはできない」

ビットコインのタイムスタンプはどのくらい正確か#

分単位ではなく、時間単位の精度です。各ブロックヘッダーの時刻はマイナー自身が設定し、ビットコインが課すのはゆるい範囲だけです。ブロックの時刻は「直前の11ブロックの時刻の中央値より厳密に大きくなければならず」、「フルノードは、自分の時計で2時間以上先の時刻を持つヘッダーのブロックを受け付けない」とされています（Bitcoinの開発者向けドキュメント⁸）。

Bitcoin Wiki¹¹は、上限を「ネットワーク調整時刻＋2時間」としています。Bitcoin Core 27.0¹²以降、このチェックにはノード自身のシステム時計が使われています。「ネットワーク調整時刻はコンセンサスのコードから削除された」のです（いずれも2026年10月9日確認）。どちらにしても、Wikiの結論は変わりません。「ブロックの時刻は、1〜2時間の範囲でしか正確ではない」。Toddの見積もりでは、ブロックの時刻は「2〜3時間以内で正確である可能性が非常に高く」、「1日以内ならほぼ確実に正確」です。⁷

ですから、ビットコインのタイムスタンプは「この版は、遅くともおよそブロックの時刻までに存在していた。誤差は1〜2時間」と読んでください。論文が出る前にデータセットが存在していたこと、結果が出る前に仮説が存在していたことを示すには十分です。同じ日の午後に届いた2つの投稿のどちらが先かを決めるための道具ではありません。

実際の証明を確かめるとどうなるか#

Papex Labsの教育用の記録PXH-0BADXVXY7QM3（英語）、「Educational record: P is not equal to NP」は、この仕組みの公開された例です。教えるための記録で、研究成果ではありません。記録の確認ページ（Check evidence on the record）では、タイムスタンプの証拠を1つのダウンロード papex-timestamp-evidence.zip として提供しています。中身は、証明である witness.json.ots と、証明が対象とするバイト列そのものである witness.json です。

この記録には3つの時刻が付いていて、それぞれ別の時計に由来します。

時刻（UTC、2026年10月5日）	出来事	どの時計か
11:18:33	版に署名	Papexのサーバー
11:18:35	フィンガープリントをOpenTimestampsに送信	Papexのサーバー
11:26:56	ビットコインのブロック970009	ビットコインのブロックヘッダー

Papexを信頼せずに確かめられるのは、最後の1つだけです。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というブロックの時刻が表示されています。取引¹⁵はそのブロックに含まれており、カレンダーの32バイトのルートをOP_RETURN出力に載せています。

結論：署名された証拠は、ビットコインの誤差の範囲で、遅くとも2026年10月5日11:27（UTC）ごろまでに存在していました。この例ではブロックは送信の約8分後でしたが、もっと時間がかかることもよくあります。

.otsファイルを検証するには#

必要なのは3つです。.otsファイル、タイムスタンプを付けたときのままの元のファイル（またはそのSHA-256）、そしてビットコインのブロックヘッダーを読む手段です。以下のコマンドは、公式のPythonクライアントのREADME²と、その組み込みのヘルプ（バージョン0.7.2）によるものです（2026年10月9日確認）。

1. クライアントをインストールする。 Python 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… です。2つの独立したエクスプローラーでそのブロックを調べ、マークルルートと時刻を比べます。この方法では、信頼の対象が自分のノードからエクスプローラーに移るので、2つ使ってください。ビットコインとの照合は何も行われていないので、コマンドはそれでもエラーの状態で終了します。

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ファイルとタイムスタンプを付けたファイルを確かめます。プロジェクトのJavaScriptライブラリ⁶は、ノードがないときは公開のブロックエクスプローラーを使います。そのREADMEは率直です。「ブロックエクスプローラーを使った検証は便利だが、ローカルのノードに問い合わせるほど安全ではない」。

RFC 3161のタイムスタンプとビットコインのタイムスタンプ、どちらを使うべきか#

RFC 3161¹⁶（2001年）は、信頼できる第三者の機関によるタイムスタンプ（trusted timestamping）の標準です。ハッシュをタイムスタンプ局（Time Stamping Authority、TSA）に送ると、TSAはそのハッシュと時刻を含む、署名付きのトークンを返します。TSAは「信頼できる時刻源を使う」こと、ハッシュだけにタイムスタンプを付けること、そして「タイムスタンプを付ける対象のインプリントを一切調べない」ことを求められています（2026年10月9日確認）。検証では、トークンの署名を確かめ、RFCによれば、TSAの証明書が失効していないかも確かめます。

信頼の対象は、そのTSAです。秘密鍵が漏洩すれば、「その秘密鍵を使ってTSAが署名したトークンは、どれももう信頼できない」。¹⁶ 鍵には有効期間があるので、RFCは、信頼を更新するために、後でトークンにもう一度タイムスタンプを付けるべきだともしています。その代わりに、すぐに正確な時刻が得られます。形式は1秒未満の単位を扱え、精度を明記することもできます（任意）。

研究グループも使っています。スタンフォード大学の研究室で作られたtimestamp.stanford.edu¹⁹は、ブラウザ上でファイルのハッシュを計算し、そのダイジェストに「RFC 3161に準拠した、複数の公開のタイムスタンプ局のサーバーで」タイムスタンプを付けます（2026年10月9日確認）。

	RFC 3161	OpenTimestamps（ビットコイン）
誰を信頼するか	TSA、その鍵、その証明書チェーン	ビットコインの公開の履歴。カレンダーは稼働の面だけ
精度	秒単位か、それより細かい	1〜2時間
証明が完成するまでの時間	すぐ	通常は数時間
何年も後の確認	TSAの証明書の状態、または更新したタイムスタンプ	ブロックヘッダー（どのビットコインのノードも持っている）
費用	提供者による	公開のカレンダーは無料

もう1つの違いは法律です。英国とEUでは、eIDAS規則が、適格電子タイムスタンプに「それが示す日付と時刻の正確さ、およびその日付と時刻が結び付けられたデータの完全性の推定」を与えています（第41条、英国版¹⁷、2026年10月9日確認）。適格タイムスタンプには、適格トラストサービス提供者が署名または封印（シール）をします（第42条¹⁸）。その推定が必要なら、どの提供者を使うかを法律の専門家に相談してください。この記事は法的助言ではありません。

それぞれが合う場面です。

• RFC 3161： 正確な時刻や法的な推定が必要な場合、または使っている実験ノートや文書管理システムがすでに対応している場合。
• OpenTimestamps： 1つの企業の鍵や証明書に頼らずに、何十年後でも誰でも確かめられる証明が欲しく、1〜2時間の精度で足りる場合。事前登録した仮説、データセット、コードのリリース、原稿の版が典型的な例です。
• 両方： 2つは異なる形で破綻するので、組み合わせればより広く補えます。

進めながら記録を残す#

タイムスタンプが最も役に立つのは、何か月も後ではなく、版が固まったときに付けた場合です。Papexは、これを署名に組み込んでいます（アプリの画面は英語です）。署名は、署名した人々を記録の特定の1つの版に結び付けます。後の編集は、それ自身の署名と日付を持つ新しい版になり、以前の版はそのまま残ります。

署名すると、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. OpenTimestamps: Scalable, Trust-Minimized, Distributed Timestamping with Bitcoin（Peter Todd、2016年）、2026年10月9日確認 ↩ a b c
8. Bitcoinの開発者向けドキュメント：Block chain, block headers、2026年10月9日確認 ↩ a b
9. Bitcoinの開発者向けドキュメント：getblockhash、2026年10月9日確認 ↩
10. Bitcoinの開発者向けドキュメント：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日確認