トランザクションとスクリプト：DUP HASH160 ... EQUALVERIFY CHECKSIG
ビットコインのwallet.datを解析する小さなツールを書いているところだ。主にビットコインが正確にどのように動作するのかをよりよく理解したいからだ。
トランザクションの出力には値（ビットコインの数量）と、ビットコインに組み込まれたForth風の小さなスクリプト言語を通して実行されるバイト列があることがわかった。例えば： [‘TxOut: value: 100.00 Script: DUP HASH160 6fad…ab90 EQUALVERIFY CHECKSIG’]
まず、ビットコインにスクリプト言語が組み込まれていることに少し不安を感じる。非常にシンプルなスクリプト言語（ループなし、ポインタなし、数学と暗号だけ）であるにもかかわらずだ。不安なのは、より複雑であり、複雑さはセキュリティの敵だからだ。また、2番目の互換性のある実装を作ることも難しくなる。しかし、これは乗り越えられると思う。
コードを見ると、新しいトランザクションは署名をプッシュし、次に公開鍵をインタプリタのスタックにプッシュし、その後TxOutスクリプトを実行することで検証されている（この理解で合っているだろうか？）。
TxOutに任意の有効なスクリプトを持つトランザクションを作成するコードを書くことは可能だろうか？ 例えば、以下のスクリプトでTxOutを作成できるか：OP_2DROP OP_TRUE …誰でも使えるコインを作成するために？
そして、作成できるコインの種類の柔軟性が、このように設計された理由なのだろうか？
ビットコインの性質上、バージョン0.1を出した時点で、核となる設計はそれから先ずっと変えられなくなった。そのため、私は考えうるすべてのトランザクション種別をサポートするように設計したかった。問題は、一つ一つの種別が使われるかどうかに関係なく専用のサポートコードとデータフィールドを必要とし、しかも一度に一つの特殊ケースしかカバーできなかったことだ。そうしていれば特殊ケースの爆発になっていただろう。解決策は スクリプトであり、これは問題を一般化して、取引当事者が自分たちのトランザクションをノードネットワークが評価する述語として記述できるようにする。ノードは、送信者の条件が満たされているかどうかを評価する範囲でトランザクションを理解できればよい。
スクリプトは実体としては述語である。真または偽に評価される単なる等式だ。述語 (predicate) は長くて馴染みのない言葉なので、私はスクリプトと呼ぶことにした。
支払いの受取人はスクリプトに対してテンプレートマッチを行う。現状、受取人は2つのテンプレートのみを受け入れる: 直接支払いとビットコインアドレスだ。将来のバージョンはトランザクション種別を増やすテンプレートを追加でき、そのバージョン以降を実行するノードはそれらを受け取れるようになる。ネットワーク内のあらゆるバージョンのノードは、新しいトランザクションの中身を読めなくても、ブロックへの検証と取り込みは行える。
この設計は、私が何年も前に設計した非常に多様なトランザクション種別をサポートする。エスクロー取引、担保付き契約、第三者仲裁、複数当事者署名などだ。ビットコインが大きく普及した場合、これらは将来探求したくなるものだが、すべて後で可能にするために最初から設計しておく必要があった。
ビットコインの第2の互換実装が良いアイデアになるとは私は思わない。設計の多くの部分は、すべてのノードがロックステップで完全に同一の結果を得ることに依存しており、第2の実装はネットワークにとって脅威になる。MITライセンスは他のすべてのライセンスおよび商用利用と互換性があるので、ライセンスの観点から書き直す必要はない。
サトシ、この設計にはどれくらいの期間取り組んできたの？ とてもよく考え抜かれているようだし、事前にたくさんのブレインストーミングや議論をせずに、ただ座ってコードを書けるようなものじゃないよね。みんな穴を探そうと当たり前の質問を投げかけているが、しっかり持ちこたえている 😊
ビットコインの第2の互換実装が良いアイデアになるとは私は思わない。設計の多くの部分は、すべてのノードがロックステップで完全に同一の結果を得ることに依存しており、第2の実装はネットワークにとって脅威になる。MITライセンスは他のすべてのライセンスおよび商用利用と互換性があるので、ライセンスの観点から書き直す必要はない。
良いアイデアかどうかにかかわらず、いずれ必ず誰かがネットワークを攪乱しようとする (あるいは自分の用途のために乗っ取ろうとする) 。既存コードを改変するか、自前の版を書くかのどちらかで、いずれにしてもネットワークの脅威となる。
トランザクション内スクリプトという仕組みの柔軟性には感心するが、自分の中の意地悪な部分が、すぐにそれを悪用する方法を考え始めてしまう。TxOutスクリプトには様々な興味深い情報を仕込めるし、改変されていないクライアントがそうしたトランザクションを検証して無視するだけなら、隠れた一斉配信の通信路として使える。
これは流行るまでは便利な機能だ。だが、誰かが「最新のレディー・ガガのビデオを友人全員に配ろう」と思いつき、何百万ものトランザクションで決済ネットワークを溢れさせ始めたらどうなるか…
第2のバージョンは、私にとって大規模な開発とメンテナンスの負担になるだろう。第2のバージョンによる固定化がなくても、ネットワークをアップグレードしながら後方互換性を維持するのは十分に大変だ。もし第2のバージョンに問題が発生すれば、ユーザー体験は両方に悪い印象を与えるが、少なくとも公式バージョンを使い続けることの重要性をユーザーに再認識させることにはなるだろう。もし誰かが第2のバージョンをフォークしようとしていたら、少数派バージョンを使うリスクについて多くの免責事項を公表しなければならないだろう。これは意見の不一致がある場合に多数派バージョンが勝つ設計であり、少数派バージョンにとってはかなり厳しいことになるし、できれば詳しく触れたくない。バージョンが1つしかない限り、その必要はない。
そうだ、ほとんどの開発者はソフトウェアのフォークを好まないが、今回は本当の技術的な理由がある。
ギャビン・アンドレセンの投稿（2010年6月17日19:58 UTC）トランザクション内スクリプトという仕組みの柔軟性には感心するが、自分の中の意地悪な部分が、すぐにそれを悪用する方法を考え始めてしまう。TxOutスクリプトには様々な興味深い情報を仕込めるし、改変されていないクライアントがそうしたトランザクションを検証して無視するだけなら、隠れた一斉配信の通信路として使える。
これは流行るまでは便利な機能だ。だが、誰かが「最新のレディー・ガガのビデオを友人全員に配ろう」と思いつき、何百万ものトランザクションで決済ネットワークを溢れさせ始めたらどうなるか…
それがトランザクション手数料の理由の1つだ。必要であれば他にもできることがある。
ラズロ・ハニエツの投稿（2010年6月17日18:50 UTC）サトシ、この設計にはどれくらいの期間取り組んできたの？ とてもよく考え抜かれているようだし、事前にたくさんのブレインストーミングや議論をせずに、ただ座ってコードを書けるようなものじゃないよね。みんな穴を探そうと当たり前の質問を投げかけているが、しっかり持ちこたえている 😊 2007年からだ。ある時点で、信頼をまったく必要とせずにこれを行う方法があると確信し、考え続けることを止められなかった。コーディングよりも設計の作業の方がはるかに多かった。
幸いなことに、これまでに提起されたすべての問題は、以前に検討し計画していたものだ。
いいね。私やギャビンみたいな連中があれこれ穴を探そうとしても、悪く取らないでくれたらと思ってさ……みんなここに集まってるのは、これがどんどん発展して大きなものになるのを見たいからだと思うんだ。でも同時に、壊し方を見つけるのにも興味があるんだよ（そうすれば直せるから）。これまでのところ、互換性を壊さずに機能を足せてるから、ちゃんと押さえてるんだと思うよ。
これは興味深い。トランザクション手数料を支払う代わりに、匿名の支払いの中にメッセージを埋め込む方法になり得る。
つまり、支払いの中に「公開鍵 [xxx] 宛に暗号化されたメッセージ: [yyyyy]」というNo-op文字列が含まれていたら、それが宛先に渡されるということか？ あるいは「受信者への平文メッセージ: [zzzzz]」でもいい。
もちろんこれらのメッセージの内容、つまり [xxx] や [yyyyy] はBitcoin自体とは無関係だが、Bitcoinの上に構築されるレイヤーの一部として使えるだろう。
メッセージの埋め込みにこれほど興味があるのは、TorやI2Pのような「ライブ」な匿名ネットワークではなく、Freenetのような「静的」な匿名ネットワークが使えるようになるからだ。ライブなネットワークにはexit nodeがあり、その一部は侵害され得る。政府が全exit nodeの1%を侵害すれば、特定のサイトがどこにホストされているかを突き止められる可能性が少しはある。先ほどのHeroin Storeの例で言えば、その店宛にNバイトのメッセージを送り、侵害したすべてのexit nodeでNバイトのメッセージを監視する。それを数時間続けて、Nバイトのメッセージがどこに送られているかを見れば、最終的にその店のIPアドレスが分かる。
Freenetのようなネットワークでは、データはただ漂っているだけで、たとえばウェブサイトが特定の1台のマシンにあるわけではない。データをクラウドに公開すれば、人々が定期的にアクセスしている限りそこに残り続ける。
色々調べた結果、scriptは拡張性を提供することを意図しているのだと理解できた。
bitcoinが、生成によって分配される23,000,000個の「株式」に分割された一種の資産を表すものだとする。
ユーザーが別のカスタム資産を作れるようにしたい。その資産はグローバルにユニークなhashを持ち、アドレス間で送受信できる。たとえば企業が「株式」を発行し、それをbitcoinで交換・検証できるようにする。ゲームエンジンが独自の通貨を発行して追跡することもできる。
scriptで何か近いことでも実現できるのだろうか、それとも互換性を壊す変更が必要になるのだろうか？ そもそも現時点でこういったオプションをサポートするためにネットワークを「アップグレード」することは可能なのだろうか？