Bitcoin Core

パベルは本の代金をビットコインで受け取っています。客がスマートフォンの支払い画面を見せても、本当に支払われたのか、有効なブロックに入ったのかを確かめたいと思いました。公開ブロックエクスプローラーに問い合わせる方法もあれば、自分のノードにつないだウォレットを使う方法もあります。そのノードを動かすソフトウェアがBitcoin Coreです。ここでいうノードは、ソフトウェアを動かしてBitcoinのルールを自ら検証するコンピューターです。ブロックは、共有の履歴に追加される取引のまとまりを指します。データは他のノードから受け取りますが、有効かどうかは自分で判断します。パベルは説明のための人物です。ここで大切なのは、他人の表示を信じるだけでなく、自分で検証することです。インストールしてもマイナーになったり、BTCをもらえたり、他人の支払いを取り消せたりするわけではありません。ソースコードはMITライセンスで公開され、その条件の下で調査、変更、再配布ができます。 [1] [16]

Bitcoin Coreは両方の役割を持てるため、混同しやすいところです。ノードは過去の履歴と新しいブロックを確認します。ウォレットは関連する資金を追跡し、アドレスを作り、取引を準備します。秘密鍵を管理していれば、それを使った署名もできます。秘密鍵とは、対応するビットコインの支出を認めるデジタル署名をウォレットが作るための秘密のデータです。鍵そのものを他のノードに送るわけではありません。一方、Coreはウォレットなしでも動きます。パベルは別の対応アプリで支払い、自分のノードから検証済みデータを得ることもできますが、接続に追加ソフトウェアが必要な場合もあります。Coreを起動しただけで、他のウォレットすべてが自動的につながるわけではありません。名前の目安として、bitcoin-qtは画面操作、bitcoindはバックグラウンド動作、bitcoin-cliはプログラムへのコマンド送信を担います。 [12] [17]

新しいノードは、まず過去の履歴に追いつく必要があります。これをInitial Block Download、略してIBDと呼びます。通常の同期ではブロックをダウンロードし、そのつながり、マイナーの仕事、取引のルールを調べます。その結果、まだ使われていない取引出力であるUTXOを記録したローカルな状態、chainstateができます。取引出力には金額と、それを使うための条件、例えば必要な署名が記されています。別の取引で使われるまでは、この記録に残ります。氏名や銀行口座の一覧ではありません。速度はコンピューター、記憶装置、回線に左右されるため、開始直後に遅いだけで故障とは限りません。パベルは現在の支払いを確かめる前に、同期完了を確認します。

ただし正確には、assumevalidは定められた条件で古い履歴のスクリプト、つまり支出条件の検証を省略でき、-assumevalid=0でこの近道を無効にできます。別の機能AssumeUTXOでは、照合された状態スナップショットから始め、以前の履歴をバックグラウンドで処理できます。スナップショットは、あるブロック時点のUTXOの状態を保存したものです。プログラムはまず、そのhash（デジタルの指紋）をコードに記された期待値と照合します。それだけで以前の全履歴を独立に検証し終えたことにはなりません。両者は前提が異なるため、すべての導入環境が最初からまったく同じ検証を済ませたとは言えません。 [9] [10] [12] [17]

同期後もCoreは接続先のノードからデータを受け取ります。こうした接続先をpeersと呼びます。受け入れた未承認取引は、一時的な待合室であるMempoolに置かれます。そこにあるだけではブロックでの承認を意味せず、ノードごとに内容も異なります。新しいブロックが届くとCoreは検証します。有効な候補チェーンの中では、コンピューターの投票数や単なるブロック数ではなく、累積作業量が最大のものを選びます。そこでパベルは「支払いを見つけた」と「支払いが承認された」を区別します。自分のノードでも即時の取り込みは保証されず、別の有効な枝が追跡中の履歴の一部を置き換える再編成もなくなりません。 [16]

パベルのノードが、ある未承認取引をMempoolに入れなかったとします。それでも、その取引が有効なブロックに入れないとは限りません。コンセンサスルールは、ノードにとって有効なブロックや支出を定めます。一方、ローカルなrelay policyは、資源の過負荷を防ぐといった目的で、どの未承認取引を受け入れて中継するかを追加で決めます。この方針が、受信したブロック内の取引に同じ形で適用されるわけではありません。そこではコンセンサス上の有効性が決め手です。したがってMempoolの設定が違うだけでネットワークが分裂するわけではありません。この区別があれば、Coreの設定をめぐる議論を、すべて通貨ルールの変更だと取り違えずに読めます。 [13]

Coreはブロックのデータ、ノードの状態、必要ならウォレットを保存します。Pruningは、処理済みの古いブロックファイルと、その変更を取り消すためのデータを削除して容量を節約します。新しいブロックの検証は続きますが、全履歴を手元に残しているわけではなくなります。過去の照会や古い支払いの再走査には、再ダウンロードが必要になる場合があります。インデックスは検索を速める補助的な記録で、例えばtxindexはpruningと併用できません。ノードの用途に合わせて選びます。さらに重要なのは、公開ブロックは再取得できても、失った秘密鍵はそこから復元できないことです。Coreのウォレットには独自の安全なバックアップが必要です。動作中はbackupwalletなどのバックアップ機能を使い、書き込み中のデータベースを無造作にコピーしないでください。 [11] [12]

パベルは公式サイトから始め、選んだリリースの説明を読みます。SHA-256チェックサムはダウンロードしたファイルの指紋で、期待した内容との違いを検出します。ただし、その指紋を誰が公表したかまでは分かりません。そのため、デジタル署名と署名鍵の身元も確認します。攻撃者がプログラムと独自のチェックサムをセットで渡したなら、両者の一致だけでは攻撃を防げません。さらに詳しく確かめるため、プロジェクトは再現可能なビルドを利用しています。別々の人が同じソースコードから同一のファイルを作り、結果を比較できます。Guixはその構築環境をそろえる助けになります。これはプログラムの出所の検証を強めますが、コードに不具合がないという証明ではありません。 [8] [7]

Coreには、他のプログラムから操作するためのJSON-RPCというインターフェースがあります。状態の照会やサービスとの接続に便利ですが、利用できるウォレットや権限によっては資金の操作も可能です。認証情報を自称サポート担当者に渡すものではありません。このインターフェース自体は通信を暗号化せず、公開インターネットにさらすための設計でもありません。他のBitcoinノードとの通常の接続と、この操作機能の公開は別です。ローカル接続には.cookieファイルの一時的な認証情報も使われます。遠隔管理は文書に従い、安全な接続と限定的なアクセスで行います。ノードを試す段階で、管理用の入口を世界中に開く必要はありません。 [14]

コードの変更は誰でも提案できます。他の貢献者が読み、テストし、議論し、リポジトリの管理者であるmaintainersが受け入れられた変更を統合できます。それでも、パベルのノードを遠隔操作する権限は得られません。実行するソフトウェアは運用者が選びます。ただし、その選択も一人で全員のルールを書き換えられる投票券ではありません。互換性のない変更は、自分のノードを他から切り離すことがあります。Bitcoin Coreは重要なルールの実装であり、ネットワーク全体を所有する会社ではありません。告知では、提案、コードへの採用、ソフトウェアの公開、実際の利用を区別しましょう。その間には長い道のりがある場合があります。 [15]

まず秘密鍵を保存せずにノードだけ動かすこともできます。パベルはファイルと署名を確認し、IBDが終わるのを待ち、使うウォレットが本当に自分のノードのデータを参照しているかを確かめます。その後は接続、ブロックの進行、空き容量を見ます。更新前には変更点や移行条件を記したrelease notesを読み、ウォレットを使っていればバックアップと復元も確かめます。問題調査にはdebug.logが役立ちますが、内容を考えず公開するものではありません。Pruning、インデックス、RPCは、意味の分からない手順の丸写しではなく、自分の用途に合わせます。個人ノードは理解して使える検証道具であるべきです。最初の少額購入に必須ではありませんが、なぜ支払いを有効と判断するのか自分で把握したいときに意味を持ちます。 [12] [14]