バージョン 0.3.12
バージョン 0.3.12 が利用可能になった。
機能：
- json-rpc エラーがより標準的なエラーオブジェクトを返すようになった。（ギャビン・アンドレセンに感謝）
- json-rpc コマンドラインが終了コードを返すようになった。
- json-rpc
backupwalletコマンド。 - 受信したメッセージによって例外が発生した場合に回復して続行する。他のノードが例外を引き起こせるべきではなく、これまで起きたことはないが、例外を引き起こす方法が見つかった場合、ネットワークノードの停止に利用されることを防ぐ。
エラー文字列の内容を検査する json-rpc コードがある場合は、{“code”:
ダウンロード：
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/
「非標準」トランザクションを禁止することで何が起きるのか？
main.cpp:506
// Rather not work on nonstandard transactions
if (GetSigOpCount() > 2 || ::GetSerializeSize(*this, SER_NETWORK) < 100)
return error("AcceptToMemoryPool() : nonstandard transaction");GetSigOpCount には何が含まれ、GetSerializeSize は何を測っているのか？
これはネットワーク側で「ゆるく」強制されている:
main.cpp:1425
// Check that it's not full of nonstandard transactions
if (nHeight > 79400 && GetSigOpCount() > MAX_BLOCK_SIGOPS)
return error("AcceptBlock() : too many nonstandard transactions");Bitcoin クライアントは現在、2 つの可能なテンプレートに一致するトランザクションのみを作成・認識する。
これらは、トランザクションがそれらの標準トランザクションに適合するいくつかの一般的な指標に大まかに適合するかどうかを確認する簡易テストだ。ノードはそれらのトランザクションのみを自身のブロックに追加しようとする。
将来、既存の 2 種類のトランザクションにテンプレートを追加する場合、「非標準トランザクションには取り組まない」テストを変更してそれらを受け入れるようにできる。
将来、既存の 2 種類のトランザクションにテンプレートを追加する場合、「非標準トランザクションには取り組まない」テストを変更してそれらを受け入れるようにできる。
将来の新しいクライアントが非標準トランザクションを生成できるよう更新されたとしても、古いクライアントはそれを拒否してしまうのではないか？
将来の新しいクライアントが非標準トランザクションを生成できるよう更新されたとしても、古いクライアントはそれを拒否してしまうのではないか？
古いクライアントは、自分が生成するブロックにそれらを含めないというだけだ。だからトランザクションが少し遅くなることはあっても、完全に止まることはない。
satoshi および皆へ: ウォレットのセキュリティについて長く深く考えてきた。今、より多額の bitcoin を動かす（といいのだが）他の Web サービスを実装しているところだ。backupwallet は素晴らしい。今は新しいアドレスを作るたびに自動でバックアップを取っている。トランザクションを送るときも含めてだ。
だが、トランザクションを大量に送るサイトでこれはスケールするのか？ 毎回ウォレット全体をバックアップする必要があるが、それにはアドレス、鍵、トランザクションが含まれ、使用に応じてかなり大きくなる。より集約的な利用には、バックアップ点を減らすか、データの分離を改善するかのどちらかが必要だと思う。
これに対して思いつく単純な解決策は次の二つだ:
- アドレス/鍵を他のすべてから分離する。これにより差分バックアップが容易になるか、少なくともハードウェア障害時に資金を再現するのに必要な分にバックアップサイズを抑えられる。
- 将来機能として話されていた、使用するアドレスをあらかじめ束で生成しておく方式を実装する。そうすれば一度のウォレットバックアップで今後 1,000件のトランザクションをカバーできる、というような形になる。 2.1) これを効率よく使うには、未使用プールに残っているアドレス数を問い合わせ、必要に応じて新しいバッチの生成を要求できるようにすべきだ。そうすれば適切なタイミングでバックアップを作成でき、アドレス生成からバックアップまでの間にデータを失う可能性を 0 にできる。
もちろん 1)と 2)の両方を実現できれば完璧だが、上記のいずれかを将来のリリースで期待してよいか？ それとも自前でパッチを当て始めるべきか？