違う、違う、まだ違う。自分で試してみたが、クライアントはそれらをすべて無視するだけだ。
もう少しうまくやるチャンスはないのか？ 必要なのはチェーンの成長を遅らせることだけ。個々の khps はそのままでよい。
ここに挙げたことは、もう多くの人間が試した。だからこそリリースには多くのセキュリティアップデートがあるんだ 😉
あなた方多くの人々は、その経験、特に結果と結論を共有してくれるだろうか？ 実験を伴う良い分析は、科学研究論文として発表できるかもしれない。興味はあるだろうか？
それを成立させる唯一の方法は、群全体と現在のdifficultyを上回るCPUパワーを持つことだ。時間逆行チェーン、低速DoS、高速DoS、群の操作、ワームホール、タイムトラベル──これまでにすべて試されてきた。だが何か独自のアイデアを思いついたなら、喜んで試す。
設計上の弱点（実装上の脆弱性ではなく）の議論が、何らかの公開フォーラムで自身のセクションを持ち、より集約されて一般に届くようになり次第、他の独自のアイデアを提示することにやぶさかではない。ただ、もう「違う、それは不可能だ、もう議論済みだ、フォーラムを読め」と言われるのが嫌なだけだ。 飽きるんだ、本当に。フォーラムは繰り返されるアイデアで膨れ上がっている。それらを集めよう。 すでに行われた本物の分析が見たい。結果を確認するためと、努力を重複させないために。 頻繁に提案される（実は弱点ではない）弱点をまとめた wiki の記事を見たが、あれは分析でも議論でもなく、ただの言明にすぎず、あまり説得力がない。 それに、ここで議論されている他の多くの明白な（非）弱点には触れていない。
たとえば、私は、Bitcoin ノードの運用コストは設計上、PC を持つ平均的なジョーには手が届かないと主張する。 トランザクション量（特に完全な履歴）のせいで、控えめな PC ハードウェアで実用的に運用することは不可能になる。 今ではない。5年、あるいは 15年待ってみよう。そうすれば、Bitcoin の運用にサーバーハードウェアが必要になることが分かる。 ディスク上に Bitcoin ノードを保存するために必要な容量と、保存されたすべてのデータを処理する（受信するトランザクションごとに検証する）ために必要な時間を見積もる方法があるべきだ。 そして私の見積もりでは、世界的なトランザクションレートはシステムによって制限される。 ここで私が間違っている理由を文書化しよう。そうすれば誰もが気を煩わせる必要がなくなり、皆が安心して Bitcoin に参加できる。いいね？