トランザクションとスクリプト：DUP HASH160 ... EQUALVERIFY CHECKSIG

3 件のメッセージギャビン・アンドレセン, サトシ・ナカモト 2010年6月17日 — 2010年6月18日

ギャビン・アンドレセン 2010年6月17日原文 · 個別ページ

ビットコインのwallet.datを解析する小さなツールを書いているところだ。主にビットコインが正確にどのように動作するのかをよりよく理解したいからだ。

トランザクションの出力には値（ビットコインの数量）と、ビットコインに組み込まれたForth風の小さなスクリプト言語を通して実行されるバイト列があることがわかった。例えば： [‘TxOut: value: 100.00 Script: DUP HASH160 6fad…ab90 EQUALVERIFY CHECKSIG’]

まず、ビットコインにスクリプト言語が組み込まれていることに少し不安を感じる。非常にシンプルなスクリプト言語（ループなし、ポインタなし、数学と暗号だけ）であるにもかかわらずだ。不安なのは、より複雑であり、複雑さはセキュリティの敵だからだ。また、2番目の互換性のある実装を作ることも難しくなる。しかし、これは乗り越えられると思う。

コードを見ると、新しいトランザクションは署名をプッシュし、次に公開鍵をインタプリタのスタックにプッシュし、その後TxOutスクリプトを実行することで検証されている（この理解で合っているだろうか？）。

TxOutに任意の有効なスクリプトを持つトランザクションを作成するコードを書くことは可能だろうか？例えば、以下のスクリプトでTxOutを作成できるか：OP_2DROP OP_TRUE …誰でも使えるコインを作成するために？

そして、作成できるコインの種類における柔軟性こそが、このように設計された理由なのだろうか？

サトシ・ナカモト 2010年6月17日原文 · 個別ページ

スクリプトは実際には述語だ。真または偽に評価される単なる方程式だ。述語（predicate）は長くて馴染みのない言葉なので、スクリプトと呼んだ。

Bitcoinの性質上、バージョン0.1がリリースされた時点で、コアの設計はその生涯にわたって不変となった。そのため、考えられるすべてのトランザクションタイプをサポートするように設計したいと思った。問題は、各機能には使用されるかどうかに関わらず特別なサポートコードとデータフィールドが必要で、一度に一つの特殊ケースしかカバーできないことだった。特殊ケースの爆発的増加になっていただろう。解決策はスクリプトで、問題を一般化して、取引当事者がトランザクションをノードネットワークが評価する述語として記述できるようにした。

ノードは、送信者の条件が満たされているかどうかを評価する範囲でのみトランザクションを理解する必要がある。

サトシ・ナカモト 2010年6月18日原文 · 個別ページ

第2のバージョンは、私にとって大規模な開発とメンテナンスの負担になるだろう。第2のバージョンが物事を固定してしまう中で、ネットワークをアップグレードしながら後方互換性を維持するのは十分に大変だ。もし第2のバージョンに問題が発生すれば、ユーザー体験は両方に悪い印象を与えるが、少なくとも公式バージョンを使い続けることの重要性をユーザーに再認識させることにはなるだろう。もし誰かが第2のバージョンをフォークしようとしていたら、少数派バージョンを使うリスクについて多くの免責事項を公表しなければならないだろう。これは意見の不一致がある場合に多数派バージョンが勝つ設計であり、少数派バージョンにとってはかなり厳しいことになるし、できれば詳しく触れたくない。バージョンが1つしかない限り、その必要はない。

そうだ、ほとんどの開発者はソフトウェアのフォークを好まないが、今回は本当の技術的な理由がある。

gavinandresen、2010年6月17日午後7:58:14の引用トランザクション内スクリプトの柔軟性には感心しますが、私の悪い小さな頭はすぐにそれを悪用する方法を考え始めます。TxOutスクリプトにあらゆる種類の興味深い情報をエンコードでき、改造されていないクライアントがそれらのトランザクションを検証して無視するなら、便利な秘密のブロードキャスト通信チャネルになるでしょう。

それは人気が出て、誰かが支払いネットワークに何百万ものトランザクションを送り込んで最新のLady Gagaの動画を友達全員に転送するのが楽しいと思うまでは素敵な機能だな…… それがトランザクション手数料の理由の1つだ。必要であれば他にもできることがある。

laszlo、2010年6月17日午後6:50:31の引用この設計にどのくらい取り組んでいるのですか、サトシ？非常によく考え抜かれているように見えます。事前に多くのブレインストーミングと議論をせずに、ただ座ってコーディングするような種類のものではありません。皆が穴を探して明白な質問をしていますが、よく持ちこたえています 2007年からだ。ある時点で、信頼をまったく必要とせずにこれを行う方法があると確信し、考え続けることを止められなかった。コーディングよりも設計の作業の方がはるかに多かった。

幸いなことに、これまでに提起されたすべての問題は、以前に検討し計画していたものだ。