Bitcoin Whitepaper

Whitepaper は、問題を示し、その解決策を提案する文書です。Bitcoin の文書は日常的な疑問から始まります。インターネットでお金を送るとき、銀行などの管理者が必ず間に必要なのでしょうか。Satoshi は2008年10月31日に暗号学のメーリングリストへ提案を送り、本文へのリンクを示しました。bitcoin の価格や投資利益を約束したのではありません。支払い履歴の判断を一つの会社に委ねずに、お金を受け取る方法を説明したのです。この問題が文書全体をつないでいます。 [2] [1]

同じお金を使う二つの異なる支払いに、送り手が署名したとします。一人の受取人は最初の支払いを、別の受取人はもう一方を見ます。どちらも正しいデジタル署名、つまり支払う権限の証拠を確認できますが、二人ともそのお金を受け取ることはできません。ネット上のデータは簡単にコピーでき、署名だけでは解決しないのです。第2節は、使う権限と、どの支払いが共通の履歴に入るかを分けています。Bitcoin は署名に公開記録を加え、すでに使われた資金を見分けられるようにします。 [1]

第3–5節は、支払いをブロックにまとめる方法を説明します。新しいブロックは、データの短い指紋である hash を通じて前のブロックを参照します。古い記録を変えると指紋も変わり、つながりが崩れます。Proof of Work は、そこに費用のかかる計算作業を加えます。受け入れられるブロックを作るには多くの試行が必要ですが、結果の確認は簡単です。競合する分岐では、作ったアカウントやIPアドレスの数ではなく、規則を守る履歴に積み重なった作業が重要になります。文書はこれを最長のチェーンと呼びます。大量の作業でも無効な取引は有効になりません。チェーンが定めるのは出来事の順序であり、各支払いの正確な時刻ではありません。 [1] [3]

コンピューターも電力も無料ではありません。第6節は経済的な動機を加えます。受け入れられたブロックの作成者は、新しく発行されるコインと、収録された支払いの手数料を受け取れます。手数料は取引が使う価値と新しい出力の価値との差であり、何もないところから増やしたコインではありません。将来は手数料だけで報酬を賄う可能性も考えています。ただし提案の範囲は知っておく必要があります。2,100万という正確な上限や210,000ブロックごとの半減は whitepaper に書かれていません。それらの規則は別の Bitcoin 資料で確認します。 [1] [3]

誰もが全取引をダウンロードして検証したいわけではありません。第8節は SPV、簡易支払い検証を提案します。クライアントはブロックの基本情報を含むヘッダーと、Merkle 証明を入手します。後者は hash をつなぎ、特定の取引がブロックに収録されていることを示します。本にある記載が載っているか調べることと、本全体の正しさを確認することの違いに似ています。収録証明だけでは全規則や支出履歴全体を検証しません。Whitepaper はこの限界を認めています。簡易クライアントは、自分で取引を検証する Full Node より特定の攻撃に弱いのです。 [1]

銀行では支払い記録の多くが非公開です。Bitcoin には共有履歴が必要なので、別の方法でプライバシーを守らなければなりません。第10節は支払いと鍵の持ち主の身元を切り離し、次の取引には新しい鍵ペアを使うことを勧めます。同時に弱点も認めます。支払い同士は関連付けられます。一つの記録を人物と結び付けられると、別の支払いも分かるかもしれません。新しいアドレスは魔法の変装ではありません。一部のつながりを減らしても、公開履歴や相手が知る情報まで消すことはできません。 [1]

第11節は、攻撃者が正直な参加者のチェーンに追い付く可能性を考えます。一方が先行し、双方が作業を続ける競争を想像してください。説明されたモデルでは、攻撃者の計算能力の割合が小さく、先行幅が大きいほど、追い付く可能性は下がります。計算は仮定とポアソン近似、つまり一定期間の出来事の数を見積もる数学的な簡略化を使っています。現実の全攻撃を予測するわけではありません。表の数字一つを抜き出して、あらゆる支払いに安全な承認数とすることはできません。 [1]

文書が説明するのは元の設計です。ネットワークとソフトウェアは進化しており、例えば BIP 141 で提案された SegWit は出てきません。BIP は改善案を説明する文書で、公開だけで自動的にネットワークの規則になる決定ではありません。現在の技術的な問いでは、提案、プログラム、実際に適用される共通規則、ノードの取引中継方針を区別します。ある取引を中継しないノードが、後でその取引を含む有効なブロックを受け入れることはあります。矛盾ではありません。 [4] [3]

まず要約を読み、管理者なしで二重支払いをどう防ぐかを考えます。次に署名、共有履歴、ブロック作成に必要な作業が何を補うか追ってください。数学で止まっても、最初から全公式を理解する必要はありません。どの攻撃をモデル化し、何を仮定しているかを先に捉え、詳細には後で戻れます。元のメールは Satoshi がいつ提案したかを示し、PDF は論拠を説明します。そこから切り離した一文は、特定のウォレットやサービスの安全を証明しません。 [2] [1]

大切なのは節の名前の暗記ではなく、どの部品も単独では足りない理由です。署名は権限を示し、公開履歴は二重支払いの検出を助け、Proof of Work は順序の書き換えを難しくします。部品には先行研究があり、Satoshi も参考文献で引用しています。貢献は組み合わせ方です。具体的な仮定に基づく、筋道立てた提案として読むなら、whitepaper は今も Bitcoin の考え方へのよい入口です。価格表でも投資案内でもなく、現在 Bitcoin と呼ばれる全規則や道具の完全な仕様書でもありません。 [1]