ビットコインの性質上、バージョン 0.1 がリリースされた時点で、核となる設計はその後の生涯にわたって固定されたものとなる。そのため、私は考えうるすべてのトランザクション種別をサポートするように設計したかった。問題は、一つ一つの種別が使われるかどうかに関係なく専用のサポートコードとデータフィールドを必要とし、しかも一度に一つの特殊ケースしかカバーできなかったことだ。そうしていれば特殊ケースの爆発になっていただろう。解決策は スクリプト であり、これは問題を一般化して、取引当事者が自分たちのトランザクションをノードネットワークが評価する述語として記述できるようにする。ノードは、送信者の条件が満たされているかどうかを評価する範囲でトランザクションを理解できればよい。
スクリプトは実体としては述語である。真または偽に評価される単なる等式だ。述語 (predicate) は長くて馴染みのない言葉なので、私はスクリプトと呼ぶことにした。
支払いの受取人はスクリプトに対してテンプレートマッチを行う。現状、受取人は 2 つのテンプレートのみを受け入れる: 直接支払いとビットコインアドレスだ。将来のバージョンはトランザクション種別を増やすテンプレートを追加でき、そのバージョン以降を実行するノードはそれらを受け取れるようになる。ネットワーク内のあらゆるバージョンのノードは、新しいトランザクションの中身を読めなくても、ブロックへの検証と取り込みは行える。
この設計は、私が何年も前に設計した非常に多様なトランザクション種別をサポートする。エスクロー取引、担保付き契約、第三者仲裁、複数当事者署名などだ。ビットコインが大きく普及した場合、これらは将来探求したくなるものだが、すべて後で可能にするために最初から設計しておく必要があった。
ビットコインの第 2 の互換実装が良いアイデアになるとは私は思わない。設計の多くの部分は、すべてのノードがロックステップで完全に同一の結果を得ることに依存しており、第 2 の実装はネットワークにとって脅威になる。 MIT ライセンスは他のすべてのライセンスおよび商用利用と互換性があるので、ライセンスの観点から書き直す必要はない。