ビットコイン・インスティテュート

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

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

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

ギャビン・アンドレセンの投稿(2010年6月17日19:58 UTC)

トランザクション内スクリプトという仕組みの柔軟性には感心するが、自分の中の意地悪な部分が、すぐにそれを悪用する方法を考え始めてしまう。TxOutスクリプトには様々な興味深い情報を仕込めるし、改変されていないクライアントがそうしたトランザクションを検証して無視するだけなら、隠れた一斉配信の通信路として使える。

これは流行るまでは便利な機能だ。だが、誰かが「最新のレディー・ガガのビデオを友人全員に配ろう」と思いつき、何百万ものトランザクションで決済ネットワークを溢れさせ始めたらどうなるか…

それがトランザクション手数料の理由の1つだ。必要であれば他にもできることがある。

ラズロ・ハニエツの投稿(2010年6月17日18:50 UTC)

サトシ、この設計にはどれくらいの期間取り組んできたの? とてもよく考え抜かれているようだし、事前にたくさんのブレインストーミングや議論をせずに、ただ座ってコードを書けるようなものじゃないよね。みんな穴を探そうと当たり前の質問を投げかけているが、しっかり持ちこたえている 😊 2007年からだ。ある時点で、信頼をまったく必要とせずにこれを行う方法があると確信し、考え続けることを止められなかった。コーディングよりも設計の作業の方がはるかに多かった。

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