オーバーフローバグ深刻
高さ74638のブロックが、ネットのバグを突いたらしい。整数オーバーフローで、合計が負になるトランザクションを作っている。2つのトランザクション出力は以下の通り：
out Value:92233720368.54(7ffffffffff85ee0) out Value:92233720368.54(7ff ffffffff85ee0)
至急、修正が要る。
編集： (satoshi) 0.3.10パッチのダウンロードリンクはこちら：topic 827
より良い修正ができるまで…ほんの少しのテストの後、これでうまくいくようだ：
--- a/main.h
+++ b/main.h
@@ -473,8 +473,12 @@ public:
// Check for negative values
foreach(const CTxOut& txout, vout)
+ {
if (txout.nValue < 0)
return error("CTransaction::CheckTransaction() : txout.nValue negative");
+ if (txout.nValue > 21000000*COIN)
+ return error("CTransaction::CheckTransaction() : txout.nValue over-max");
+ }
if (IsCoinBase())
{
@@ -520,6 +524,8 @@ public:
int64 nValueOut = 0;
foreach(const CTxOut& txout, vout)
{
+ if (txout.nValue > 21000000*COIN)
+ continue; // ignore over-max-value...
if (txout.nValue < 0)
throw runtime_error("CTransaction::GetValueOut() : negative value");
nValueOut += txout.nValue;不正なブロック以前のブロックチェーンの部分を再ダウンロードする必要がある — blkindex.datとblk0001.datファイルを削除すること。私はknightmbのブロックチェーンスナップショットから始めた。
あるいはgithubからの同じパッチ、http://gist.github.com/525921で直接適用できる生パッチが得られる。http://gist.github.com/raw/525921/fe2ad7583f0dd2444caa0b3e24d750bf45cac11b/Quick%20fix%20block%2074652
編集：これを使って直接パッチを適用できなかった。おそらくCRLFの問題だ。
変更を手動で適用し、結果をここにアップロードした：http://yyz.us/bitcoin/patch.bitcoin-gavin-overflow-quick-fix
これが暫定の修正だ。これで合っているか？ まだ加える変更がある。これで全部ではない。間もなくSVNにコミットする。
bool CheckTransaction() const
{
// コンテキストに依存しない基本チェック
if (vin.empty() || vout.empty())
return error("CTransaction::CheckTransaction() : vin or vout empty");
// 負の値とオーバーフロー値のチェック
int64 nTotal = 0;
foreach(const CTxOut& txout, vout)
{
if (txout.nValue < 0)
return error("CTransaction::CheckTransaction() : txout.nValue negative");
if (txout.nValue > 21000000 * COIN)
return error("CTransaction::CheckTransaction() : txout.nValue too high");
nTotal += txout.nValue;
if (nTotal > 21000000 * COIN)
return error("CTransaction::CheckTransaction() : txout total too high");
}
if (IsCoinBase())
{
if (vin[0].scriptSig.size() < 2 || vin[0].scriptSig.size() > 100)
return error("CTransaction::CheckTransaction() : coinbase script size");
}
else
{
foreach(const CTxIn& txin, vin)
if (txin.prevout.IsNull())
return error("CTransaction::CheckTransaction() : prevout is null");
}
return true;
}トピックをスティッキーにしないでくれ、あそこは誰も見ない。バンプするのに十分な投稿があるだろう。
みんなが生成を止めてくれると助かる。今のブランチのあたりから、ブランチを作り直すことになると思う。生成が少ないほど、それが早く済む。
最初のパッチはSVN rev 132に入る予定だ。まだアップロードされていない。まず他の雑多な変更を先に出してから、この件のパッチをアップロードする。
残念ながらコミュニティはもう大きすぎて分散しすぎており、何かに対して自発的かつ迅速な対応を多く期待することはできない。特にgeneration（マイニング）は、多くの人が自動化していてほとんど監視していないだろう。
私としては問題なさそうだ。
起動時に不正なブロックのハッシュを確かめる処理を組み込んで、それが最良のチェーンに載っていたら、そのブロックと後のブロックを孤立させる、というのは簡単にできないかな？ これを修正するためにチェーンの全部または大部分を再ダウンロードしなければならないのは辛い……
私としては問題なさそうだ。
起動時に不正なブロックのハッシュを確かめる処理を組み込んで、それが最良のチェーンに載っていたら、そのブロックと後のブロックを孤立させる、というのは簡単にできないかな？ これを修正するためにチェーンの全部または大部分を再ダウンロードしなければならないのは辛い……
あるいは全ブロックの簡易な再検証だけでもいい。なにしろ以前の5倍速くなっているのだから。 😉
アップデートを入手したら、knightmbのブロックチェーンをダウンロードするとよい。最新のセキュリティロックインが検証してくれるよう、ブロック74000より前で終わるような十分に古いものが望ましい。誰かそのリンクを見つけてくれないか？
アップデートを入手したら、knightmbのブロックチェーンをダウンロードするとよい。最新のセキュリティロックインが検証してくれるよう、ブロック74000より前で終わるような十分に古いものが望ましい。誰かそのリンクを見つけてくれないか？
http://knightmb.dyndns.org/files/bitcoin/blocks/
再ダウンロードする方がいい。
パッチ適用後だが全員がアップグレードする前のブロック検証は非常に遅くなるだろう！ おそらく次の難易度調整が大幅に低下するだろう。もちろん、次の調整が来る頃には全員がアップグレードしているだろうから、比較的素早く通過するだろう。
編集：うーん、含まれている情報ファイルがあるようで、それを見れば手がかりが得られるかもしれない。
私たちのようなバカな初心者に、ブロックチェーンをダウンロードしたらどうすればいいのか、説明してもらえないかな？
私たちのようなバカな初心者に、ブロックチェーンをダウンロードしたらどうすればいいのか、説明してもらえないかな？
それはBitcoinのデータディレクトリ内のファイルを置き換えることを意味する。何をしているか分かっていない限り推奨しない。
最も簡単で安全な方法は、wallet.datをバックアップしてからすべてを再ダウンロードすることだ。
パッチがSVN rev 132にアップロードされた！
現時点での推奨手順：
- シャットダウンする。
- knightmbのblkファイルをダウンロードする。（blk0001.datとblkindex.datファイルを置き換える）
- アップグレードする。
- 74000ブロック未満から始まるはずだ。残りは再ダウンロードさせればいい。
knightmbのファイルを使いたくない場合は、blk*.datファイルを削除するだけでもよいが、全員が同時にブロックインデックス全体をダウンロードするとネットワークにかなりの負荷がかかる。
まもなくリリースをビルドする。
私たちのようなバカな初心者に、ブロックチェーンをダウンロードしたらどうすればいいのか、説明してもらえないかな？
Bitcoinが動作していない状態で、Bitcoinのデータディレクトリに置く。Linuxなら~/.bitcoinだ。チェーン全体を再ダウンロードしたければ、Bitcoinが動作していない状態でデータディレクトリからファイルを削除するだけだ。
自分はblk00x.datファイルとblkindex.datファイルをデータディレクトリの外に移動してから、クライアントを再起動するつもりだ。これらが正しいファイルで合っている？
編集：いつもアップグレード前にやっているように、ディレクトリ全体もバックアップしておく。
knightmbのファイルを使いたくない場合は、blk*.datファイルを削除するだけでもよいが、全員が同時にブロックインデックス全体をダウンロードするとネットワークにかなりの負荷がかかる。
ブロックチェーン <= 64637のblk*.datを作るボランティアはいないか？
公式バイナリにknown-goodなブロックチェーンを同梱して、時間と帯域を節約するというのもありだろうか？
バグ修正には0.3.9 rc2の4-way SSE2パッチも含まれるだろうか？ 含まれていることを教えてくれてありがとう、theymos。もし含まれていないなら、時間があるときに別のリリース候補を出してほしい。
74000から無効ブロックまでのトランザクションはどうなる？ それらも今や全部無効なのか？
無効なのは、その不正ブロック自身とそれ以降のブロックだけだ。それより前のブロックはすべて有効だ。
[削除済み] Quote from: davidonpda on August 15, 2010, 10:41:29 PM
74637でちょうど持っていると既に言った。
サトシは74,000以前である必要があると言った。
それを作成する人がパッチ適用済みのクライアントを持ち、チェーン全体をダウンロードする限り、できればローカルネットワーク上の別のコンピューターから最適にダウンロードすれば、正しい場所で自動的に停止するはずだ。
[削除済み] Quote from: davidonpda on August 15, 2010, 10:41:29 PM
NewLibertyStandardの投稿（2010年8月15日22:44 UTC）サトシは74,000以前である必要があると言った。
そうは言っていない。彼は「望ましい」と言ったのであって、必要だとは言っていない。微妙な違いだ。 そして「…不正なブロックを含むブロックとそれ以降だけが無効だ。それ以前のブロックはすべて有効だ…」なら、74000より前である必要はない。
knightmbの時間を節約してあげたかっただけだが、君のはどのみち私のより大きいな。 😄
ブロックチェーンのダウンロードを更新しないでほしい。誰かのブロックチェーンダウンロードを使う場合、最後まで含むものは望ましくない。やや古いもののほうが良く、最新のブロックをダウンロードして検証できる。
tcatmの4-way SSE2 SHA-256はファイルsha256.cppに入っており、数リビジョン前にすでにアップロードされている。
たった今、Linux上でのビルドを有効にするmakefile.unixであるrev 134をアップロードした。今Linuxでrev 134をビルドすると -4wayスイッチが使える。
ビルドに問題がある場合は、makefile.unixを編集して：
- -DFOURWAYSSE2を削除
- 以下の行の末尾からobj/sha256.oを削除：
bitcoin: $(OBJS) obj/ui.o obj/uibase.o obj/sha256.o
bitcoind: $(OBJS:obj/%=obj/nogui/%) obj/sha256.o0.3.10のLinuxビルドには、私がビルドする際に -4wayオプションが含まれる。
Windows用のパッチダウンロードはこちらだ：
http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe
http://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip
SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip
手順：
- シャットダウンする。
- knightmbのblkファイルをダウンロードし、blk0001.datとblkindex.datファイルを置き換える。
http://knightmb.dyndns.org/files/bitcoin/blocks/http://rapidshare.com/files/413168038/BitcoinBlocks.torrent - 0.3.10にアップグレードする。
- 74000ブロック未満から開始され、残りを再ダウンロードするはずだ。
あるいは、blkファイルのダウンロードが面倒な場合は、以下のようにするだけでよい：
- シャットダウンする。
- blk*.datを削除（または移動）する。
- 0.3.10にアップグレードする。
- すべてのブロックを再ダウンロードし、おそらく約1時間かかる。
ああ、少しわかりにくいな 😕
自分で作る必要がないのか、それともあなたたちが既に持っているものをFTPに上げればいいのか？
Windowsマシンからブロックデータをダンプして、Linux/Macマシンに載せることはできる？
[編集] あなたの投稿を見た。では74,000未満のものをビルドする。技術者の皆さんの新しいチェーンダウンロードを数分節約できるはずだ。 😉
この焦らしに耐えられない！ Jr.メンバー以上で、非公式のSVN rev 134 Linux 64ビットビルドをコンパイル済みで共有してくれる人はいないだろうか？ そう、公式ビルドが数分後にリリースされることは分かっている。たいして重要ではない。
編集：サトシが先ほどコメントしたのでSVNバージョン番号を更新した。
ああ、気にしないでくれ。SVNバージョンが更新されてWindowsビルドもリリースされたので、待つことにする。 😳
[編集] あなたの投稿を見た。では74,000未満のものをビルドする。少なくとも技術者の皆さんの新しいチェーンのダウンロード時間を数分節約できるはずだ。
古いものはそのままにしてくれ！ 古いほうがいい。何番のブロックだ？ 60000から74000のどこかであれば問題ない。しばらく前から公開していたものは検証済みで、最善の選択肢だ。
knightmb、ちょうど君の古いファイルを使ってみたが、かなり古いシステムでもキャッチアップにそれほど時間はかからなかった。だから「わざわざやらなくていい」と言いたい。
これについて何か追加すべきだと思う：http://bitcointalk.org/index.php?topic=259.0必要な時にクライアントに警告メッセージを表示するラベルが必要だ 😊
今は常にウェブサイトを確認しなければならず、これは良くないと思う。
67000から開始するのは完璧だ。
ああ、今のところは74638で止まる。より多くのノードがアップグレードして生成するにつれて、ゆっくりと増加し始めるはずだ。
Linux版のビルドリンクは以下の通りだ。
Linux版にはtcatmの4-way SSE2 SHA-256が含まれており、i5およびAMD CPUでの生成が高速になる。-4wayスイッチを使って有効にし、お使いの環境で高速かどうか確認してほしい。
ダウンロードリンク：http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe
http://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.10-linux.tar.gz
SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip SHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz
これについて何か追加すべきだと思う：
http://bitcointalk.org/index.php?topic=259.0必要な場合に警告メッセージを表示するラベルがクライアントにあるべきだ。 今は常にウェブサイトを確認しなければならず、それは良くないと思う。
同意する。長い間やりたかったのだが、やる時間がなかった。
今のところ、bitcoin-listメーリングリストに登録することもできる。このようなお知らせや主要な新バージョン以外ではほとんど使われていない。
登録/解除ページ：http://lists.sourceforge.net/mailman/listinfo/bitcoin-list
knightmbの投稿（2010年8月15日22:59 UTC）[編集] 君の投稿を今見た。それなら74,000未満のものを作る。少なくとも君たち技術系の人たちが新しいチェーンをダウンロードする時間を数分節約できるはずだ。
古いものはそのままにしてくれ！ 古いほうがいい。何番のブロックだ？ 60000から74000のどこかであれば問題ない。しばらく前から公開していたものは検証済みで、最善の選択肢だ。
ファイルにブロック番号を付けたので、それぞれがどこで止まっているか正確にわかるはずだ。
BitCoinBlocks_Linux_67309.zip BitCoinBlocks_Windows_67300.zip
そのままにしておく。役に立てて嬉しい 😊
[削除済み] Quote from: davidonpda on August 15, 2010, 11:31:37 PM
… すでにブロック74638に達している。これはそのブロックが正常なものになったということか？
自分もこの点について混乱していたが、#bitcoin-devで確認を得た。
不正なブロックは74638番で、最後の正常なブロックは74637番だった。番号は0から始まるため、クライアントが74638ブロックと表示している場合、ブロック74637番まで、つまり最後の正常なブロックまで取得済みということになる。
同意する。長い間やりたかったのだが、やる時間がなかった。
今のところ、bitcoin-listメーリングリストに登録することもできる。このようなお知らせや主要な新バージョン以外ではほとんど使われていない。
購読・購読解除ページ：
http://lists.sourceforge.net/mailman/listinfo/bitcoin-list
いいね 😄
ともあれ自分は普段ウェブサイトをチェックしているが、初心者ユーザー（今後さらに増えてくる層）向けの解決策を考えていた。
小さなバグでも、初心者や情報を知らないユーザーが多いネットワークでは大問題になり得る。（そういう人たちはhttp://lists.sourceforge.net/mailman/listinfo/bitcoin-listのようなソースに目を通すことなど決してないだろう 😛）
（英語が下手ですまない、まだ通じているといいのだが 😁）
4b. 現在、ネットワークには良いノードと悪いノード（0.3.10より古いバージョンを実行しているもの）が混在している。古いバージョンを実行しているノードにしか接続しなければ、74638ブロックで止まってしまう。これは、クライアントを次のオプションで起動することで修正できる： -addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=76.235.234.64 -addnode=74.137.15.169 -addnode=68.68.99.14
ある意味、これは全員がアップグレードするまで一時的にブロック生成の難易度を下げることになる。そう、遅くなるが、それは各クライアントが難しいハッシュを生成するためにより多くの時間を持つということだ。
影響についての質問：不正なブロックの後、不正なブロックチェーンを使ってトランザクションを送信した。
そのトランザクションの状態はどうなっているのだろうか？ 見る限り、（更新済みの）送信側クライアントのウォレットは差し引かれた金額を表示している。
修正されたチェーンに再組み込みされ、受取人はそれを使用できるようになるのだろうか？
影響についての質問：不正なブロックの後、不正なブロックチェーンを使ってトランザクションを送信した。
そのトランザクションの状態はどうなっているのだろうか？ 見る限り、（更新済みの）送信側クライアントのウォレットは差し引かれた金額を表示している。
修正されたチェーンに再組み込みされ、受取人はそれを使用できるようになるのだろうか？
ああ、修正されたチェーンに再統合される。トランザクションは消えず、双方で引き続き表示されるが、確認数が0に戻り、再び増え始める。
ブロック74638以降の不正なチェーンでブロックを生成した場合のみ、そのブロックからの50 BTCが消える。不正なチェーン内のブロックはまだ成熟していなかったはずだ。
すべての手順を実行した。今、クライアントは0.3.10でブロック74638で停止した。これで問題ないのか？
まだ74638ブロックと表示されているなら、0.3.10のノードに接続されていない。
今日のところは、以下のパラメーターを追加してみてほしい：
-addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=68.68.99.14
参照http://bitcointalk.org/index.php?topic=828
クライアントを実行しているほとんどの人はこのメッセージスレッドを読んでいない。では…素朴な質問だ：
- これはバージョン3.8.1（大災害前）の不正なブロックチェーンを持つクライアントにどのような影響を与え続けるのだろうか？
- 3.8.10にアップグレードしたがブロックチェーンファイルを削除しないクライアントにどのような影響があるのだろうか？
クライアントを実行しているほとんどの人はこのメッセージスレッドを読んでいない。では…素朴な質問だ：
- これはバージョン3.8.1（大災害前）の不正なブロックチェーンを持つクライアントにどのような影響を与え続けるのだろうか？
- 3.8.10にアップグレードしたがブロックチェーンファイルを削除しないクライアントにどのような影響があるのだろうか？
- ノードパワーの50%以上がアップグレードされ、正しいチェーンが不正なチェーンを追い越せば、0.3.10ノードは不正なトランザクションが確認を得ることを困難にする。
- blk*.datファイルを削除しなかった場合、その50%への貢献にはなっておらず、正しいチェーンが不正なチェーンを追い越すまで不正なトランザクションが表示され続ける。
ある意味、これは全員がアップグレードするまで一時的にブロック生成の難易度を下げることになる。そう、遅くなるが、それは各クライアントが難しいハッシュを生成するためにより多くの時間を持つということだ。
もちろん、これは難易度が511.7に上がった直後に起きた。だから新しい「正しい」ブロックはすべてその難易度と戦うことになる。そしてネットワークの計算力のかなりの部分は不正チェーンの方に行ってしまっているから、新しいブロックを見つけるのに10分よりずっと長くかかるかもしれない。難易度調整がこれを察知して再び難易度を下げる可能性があるのはどの時点だろうか？
不正なチェーンも、アップグレードするノードが増えるにつれて速度が低下する。
74638以降、すでに14ブロックを生成した。0.3.10のビルドは約2～3時間前にアップロードされた。接続しているノードのうち、半数以上がすでに0.3.10だ。おそらく、不正なチェーンよりもすでに多くの計算力を持っていると思う。
できるだけ多くのCPUを投入している。ああ、全員がアップグレードするまでちょっと不公平なアドバンテージだな。 🤐 妻のPCが既に新しいブロックを2つ生成した（笑）。ツキが彼女の味方のようだ。
… 接続しているノードのうち、半数以上がすでに0.3.10だ。…
素晴らしいニュースだ！ でも、どうやってそれを調べたの？ 自分自身をできるだけ多くの人に接続させ、バージョンを調査してログを書き出す（通常のBitcoinの処理に加えて）、特別に調整されたクライアントを書くことを検討していた。
Windowsでは、findstr /c:“version message” debug.log
不正なチェーンは最近ブロック74678にあったようだ。追い越すのが待ちきれない。
http://nullvoid.org/bitcoin/statistix.phpの統計では、過去3時間で1時間あたり5ブロックだった。約1日前に難易度調整があり、1時間あたり6ブロックに戻るはずだった。
不正なチェーンも、アップグレードするノードが増えるにつれて速度が低下する。
74638以降、すでに14ブロックを生成した。0.3.10のビルドは約2～3時間前にアップロードされた。接続しているノードのうち、半数以上がすでに0.3.10だ。おそらく、不正なチェーンよりもすでに多くの計算力を持っていると思う。
それでも、古いバージョンからの接続を拒否する別バージョンを出すのは良いアイデアだと思う。さもなければネットワークはしばらくかなり分断されたままになるかもしれない。 :/
4b. 現在、ネットワークには良いノードと悪いノード（0.3.10より古いバージョンを実行しているもの）が混在している。古いバージョンを実行しているノードにしか接続しなければ、74638ブロックで止まってしまう。これは、クライアントを次のオプションで起動することで修正できる：
-addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=76.235.234.64 -addnode=74.137.15.169 -addnode=68.68.99.14
http://www.bitcoin.org/wiki/doku.php?do=show&id=74638_nodes
サトシ・ナカモトの投稿（2010年8月16日02:16 UTC）不正チェーンも、より多くのノードがアップグレードするにつれて鈍化している。
74638以降、すでに14ブロック生成している。0.3.10のビルドは2〜3時間前にアップロードされた。私が接続しているノードのうち、半数以上がすでに0.3.10だ。おそらく不正チェーンよりも多くの計算力をすでに持っていると思う。
それでも、古いバージョンからの接続を拒否する別バージョンを出すのは良いアイデアだと思う。さもなければネットワークはしばらくかなり分断されたままになるかもしれない。 :/
古いクライアントは接続させたままにしておきたい。正しいチェーンが不正なチェーンを追い越したときに、彼らも正しいチェーンに戻ってくるからだ。もっとも、古いチェーンが分岐したチェーンをどこまで遡って受け入れるかについて、具体的なことは知らない。
bdonlanの投稿（2010年8月16日02:39 UTC）サトシ・ナカモトの投稿（2010年8月16日02:16 UTC）不正チェーンも、より多くのノードがアップグレードするにつれて鈍化している。
74638以降、すでに14ブロック生成している。0.3.10のビルドは2〜3時間前にアップロードされた。私が接続しているノードのうち、半数以上がすでに0.3.10だ。おそらく不正チェーンよりも多くの計算力をすでに持っていると思う。
それでも、古いバージョンからの接続を拒否する別バージョンを出すのが良いと思う。そうしないとネットワークがしばらく分断されたままになるかもしれない。 :/
古いクライアントは接続させたままにしておきたい。正しいチェーンが不正なチェーンを追い越したときに、彼らも正しいチェーンに戻ってくるからだ。もっとも、古いチェーンが分岐したチェーンをどこまで遡って受け入れるかについて、具体的なことは知らない。
古いクライアントは前回リリースのスナップショットまで遡って受け入れるはずだ。だからこの問題がこんなに早く、しかも前回リリースからこれだけ時間が経った後に見つかったのなら、理論上はうまくいくはずだ。これは理論の良いテストだな 😁
Ground Loopの投稿（2010年8月16日00:29 UTC）影響についての質問：不正なブロックの後、不正なブロックチェーンを使ってトランザクションを送信した。
そのトランザクションの状態はどうなっているのだろうか？ 見る限り、（更新済みの）送信側クライアントのウォレットは差し引かれた金額を表示している。
修正されたチェーンに再組み込みされ、受取人はそれを使用できるようになるのだろうか？
ああ、修正されたチェーンに再統合される。トランザクションは消えず、双方で引き続き表示されるが、確認数が0に戻り、再び増え始める。
ブロック74638以降の不正なチェーンでブロックを生成した場合のみ、そのブロックからの50 BTCが消える。不正なチェーン内のブロックはまだ成熟していなかったはずだ。
興味深い。このシステムの奥底をどのように進んでいくかを見るのは魅力的だ。 私が生成したのはブロック73746だった。CTxOut(nValue=50.00000000, scriptPubKey=0x8DDD5C7DADB2D43AC5F186) 08/12/10 02:35 generated 50.00
そしてそのうち49.00を19Nzg21hQQDAY5GTdTTuUVPA4MaE7AusXzに送った（壊れたチェーンを使って）。
今は、そのノードが受信に気付き、新しいチェーンを使うようになるのを待っている。
チェーン全体を削除して再ダウンロードする代わりに、チェーンの末尾を手動で切り落とすRPCコマンドがあると便利かな？
この時点で、アップグレードしていないクライアントも正しいチェーンを持ってるのかな？
はい。唯一の例外は、パッチ未適用のクライアントが別の偽トランザクションを作成し検証に成功した場合だ。アップグレードしていない他のいくつかのノードにその偽ブロックを広められるだろうが、アップグレード済みクライアントの方がパッチ未適用クライアントより多くのパワーを持っているようなので、不正なリンクは長続きせず、アップグレード済みクライアントには広まらない。
未アップグレードのノードはほとんどの場合正しいチェーンを持っているが、依然としてすべてのブロックにオーバーフロートランザクションを含めようとしているため、継続的にフォークして無効なブロックを生成しようとしている。旧バージョンのノードを再起動すると、トランザクションプールが空になるため、トランザクションが再ブロードキャストされるまでしばらくは有効なブロックを生成するかもしれない。0.3.9以下のノードはまだアップグレードが必要だ。
SVNには、blk*.datファイルを手動で削除せずにブロックチェーンを自動的に再編成するために必要なコードが入っている。昨日はそのコードを迅速かつ慎重に書くことができないとわかっていたので、手動の簡易オプションで対応した。