結果自体は手元にあったのですが、念のため再計算いたしました。
と、開示の前にハッシュ交換の方法提示ですよね。考え付いたのは以下の三点です。
1, すべての取引情報を新しいハッシュ関数でハッシュしてハードコード
SHA-256に対する情報改ざんなどを防ぐには、この方法です。
万一、中身を挿げ替えされても、新しいハッシュ関数のハッシュ値は変わるためです。
そして、このハッシュ値を新しい基準にして、新しいハッシュ関数でスタートです。
ただ、ちょっと考えるだけでも大変な作業です。
2, SHA-256でハッシュされた取引情報は、ハッシュ値同士の比較ではなく全比較
この方法での移行は楽そうですが、計算量が多過ぎるため現実的ではないかな。
3, ECDSAはすべてバーンして、PQCと新しいハッシュ関数のみを有効化する
（ECDSAのメッセージハッシュがSHA-256絡みのため）
この方法も、移行は楽でしょう。ところが、強い反発は免れません。
でも一時期、この提案……本当にありましたからね。ECDSAをすべてバーン、です。
正直、時間がなくなると3になる可能性もありますよね。
期限を決めて、ECDSAをSHA-256と一緒に葬ります。
ハッシュ関数の交換はもちろん、PQCもセットに実装できて大満足。
さらに問題となっているあのSatoshiのアドレスも無事解決です。（あの残高流出＝崩壊です）
そして、前もってやられたとしても、期限さえ迎えれば安全という「免罪符」になり、さらに、早めに新しいアドレスに移行しておかなかった方が悪いで処理可能。まあ、ずいぶんと運営側に都合が良いものにはなりますが、安全かつ確実なので、この可能性は普通にあります。
コールドウォレットに置いておいた分、もしこの提案だと冗談抜きでバーンされるので注意です。
でも量子の躍進をみていると、３しかない。冗談抜きで、それは現実的な話です。
アナウンスがあったら、最初はトランザクションが混むでしょうから、落ち着いてから新しいPQCアドレスに移動すれば問題ないです。そんなに手間はかかりません。ただし忘れるとバーンです。
そこも運営でやってよ。それは無理なのです。なぜなら秘密鍵が必要になるためです。
