コンセンサスルール

以前の取引で受け取った同じ資金を、ある人があなたへの支払いと店への支払いの両方に使おうとしたとします。両方の支出が有効な履歴に入ることはできません。ノードはこれを確かめるため、金額とその支出条件を記録した「取引出力」を追跡します。ノードがブロックを受け取ったときに調べるのは、誰が勧めたかではなく、自分が適用するルールを満たすかどうかです。支出対象の出力が利用可能か、必要な署名を含む Bitcoin Script の条件、Proof of Work、マイナー報酬の上限などを検証します。ルール違反があれば拒否します。企業の支持やインターネット投票の多数派でも、この結果は変わりません。 [1]

マイナーは取引を選んでブロックの発見を目指し、Full Node はその結果を独立に検証します。開発者は変更を提案してソフトウェアを公開できますが、それだけで他のノードのルールが変わるわけではありません。どのソフトウェアを動かすかは運用者が決めます。その選択で決まるのは自分のノードが何を受け入れるかであり、全員に何を受け入れさせるかではありません。 [2] [1]

ノードには未承認取引に関するルールもあります。どの取引を Mempool、つまり承認を待つ取引を一時的に保存する手元の場所に置き、他のノードへ転送するかを決めるものです。このローカルな policy は、コンセンサスより厳しく設定できます。したがって、メンプールへの受け入れを拒否された取引でも、ブロック内では有効な場合があります。ブロックの検証に取引の転送ポリシーは適用されません。 [3]

Soft Fork はルールを厳しくする変更です。新しいルールで有効なブロックは、古いルールにも適合します。ただし、古いノードは新たな条件を検証しません。一方、Hard Fork は古いノードが拒否するブロックを認めることがあります。有効化の仕組みは変更の調整を助けますが、全員の同意を保証せず、どのソフトウェアを使うかという運用者の判断にも代わりません。 [4]

自分の Full Node を使えば、ブロックエクスプローラーという検索サイトに頼らず、受け取ったブロックを検証できます。ノードが共通の履歴から続く複数の分岐を知っている場合もあります。有効な分岐の中で選択の基準になるのは chainwork、つまり各ブロックの採掘難易度に応じて割り当てられた作業量の合計です。実際に消費した電力を測るものでも、単にブロックを数えるものでもありません。作業量が多くてもルール違反は認められません。ノード同士が同じ結果に達するには、珍しいケースでもルールを同じように適用する必要があります。プログラムの不具合があると、受け入れるブロックが食い違うことがあります。 [4] [5]

手数料が低すぎる取引について、ノードは転送を拒否することがあります。それでもマイナーがブロックに取り込み、取引とブロックがコンセンサスを満たせば、ノードはそのブロックを受け入れます。これに対して、マイナーが新規発行が認められたビットコインの量である Block Subsidy と、ブロック内の取引手数料の合計を超える報酬を得ようとすれば、Proof of Work が有効でもブロックは拒否されます。違いは拒否の理由であって、マイナーの評判ではありません。 [3] [1]