2016年1月15日、Bitcoin Core v0.12 が合意クリティカルな ECDSA 署名検証の標準バックエンドとして libsecp256k1 を採用し、OpenSSL を置き換えた。OpenSSL はサトシのオリジナル v0.1 リリース以来 7年間、ビットコインの依存ライブラリーであり続けていた。
背景：
libsecp256k1 プロジェクトは 2013年3月5日、ピーター・ウィーユによって開始された。当初の動機は性能で、ウィーユは GLV-method endomorphism によって OpenSSL の汎用楕円曲線コードを上回る速度向上が得られるか確かめたかった。1 週間でライブラリーはビットコインの全ブロックチェーンを検証可能になった（当時のブロック高は約 225,000）。
グレゴリー・マクスウェルが参加し、プロジェクトは性能実験から、OpenSSL の secp256k1 実装を完全に置き換えるビットコイン専用ライブラリーへと拡大していった。
OpenSSL を置換する理由：
2014年までに、合意クリティカルなコードで OpenSSL を使用することの具体的な問題が複数特定されていた：
- 署名解析の不整合が予期せぬチェーン分裂を引き起こす可能性。OpenSSL のバージョンが異なると、同じ署名が有効か無効かで判定が割れる場合があり、全ノードが同じ結論に達する必要がある合意システムでは許容できない。
- 性能 — libsecp256k1 は最終的に署名検証で 2.5〜5.5倍高速。署名検証は新ブロック検証コストの大部分を占める。
- 監査可能性 — 単一の曲線とビットコインが必要とする操作のみに焦点を絞ることで、ライブラリーは深く査読可能なサイズに収まり、サイドチャネル攻撃に対する定数時間実装も実現できた。
2014年11月、ウィーユは libsecp256k1 のテストを書きながら CVE-2014-3570 を発見・報告した。これは OpenSSL の BN_sqr（二乗）ルーチンの重大なバグで、長年 OpenSSL に潜在していた。
マクスウェルは Bitcoin Magazine の記事で結論をこうまとめた。「OpenSSL はビットコインのような合意クリティカルなシステムには適さないライブラリーだ」
展開：
- Bitcoin Core v0.10（2015年2月）: ウォレット署名の標準として libsecp256k1 を採用。
- Bitcoin Core v0.12（2016年1月15日）: 合意クリティカルな ECDSA 署名検証の標準として libsecp256k1 を採用。
意義：
libsecp256k1 は、サトシが当初選定した依存ライブラリーで最も影響力の大きい置換例である。サトシの v0.1 が OpenSSL を採用したのは、2008年当時としては自明な選択だった——Windows 上の C++ プロジェクト向け標準暗号ライブラリーだったからだ。2016年までに、Bitcoin Core 開発者たちは、合意システムにとって「自明」と「正しい」は同じではないと結論し、3年かけてビットコイン専用の置換実装を作り上げた。
このパターン——コードベースが成熟するにつれてサトシの設計選択がビットコイン固有の実装に段階的に置き換えられていくこと——は、Bitcoin Core の進化における繰り返し現れるテーマである。PR #4641（laanwj、2014）も同様で、サトシのハンガリアン記法による変数命名規則を新しい Bitcoin Core コードから体系的に削除する動きの始まりだった。