プライバシー vs 安全性：おつりの扱い
ウォレットファイルのバックアップと復元でコインを失う方法を説明する：
ウォレットにピカピカの 1,000 ビットコインが 1枚あるとする（実際にはウォレットに保存された公開鍵に支払われた 1,000 ビットコインのトランザクションだ）。
そのファイルをバックアップする。
次に 1 ビットコインを使う。ピカピカの 1,000 BTC コインは 1BTC とお釣りの 999BTC に分割される。そのお釣りには新しい別の公開鍵が割り当てられる。
ウォレットファイルを復元すると、Bitcoin は 1,000BTC コインが使われたことを認識する――1BTC はどこかに送られ、残りの 999BTC はどこかに送られた。999BTC の鍵がないので、それらのコインがあなたのものだとわからない。
だから失われる。
TEST ネットワークでお釣りの処理に関する代替ポリシーを試すのは良いアイデアだと思う。
お釣りのトランザクションには常に同じ公開鍵で署名すべきかもしれない。そうすればウォレットの復元時にコインを失わない……ただし、すべてのトランザクションが紐付けられるのでプライバシーが低下する。
ウォレットに最初から 100 の「お釣り」アドレスを用意し、必要に応じてランダムに選ぶのもいい。そして新しい 100 アドレスに置き換える超ギーク的な方法を用意する。
「ウォレットを復元したら BTC を失った」問題のさらに良い解決策があるかもしれない。アイデアは？
これは単に古いバックアップに復元した結果ではないか？
それはさておき、
シンプルなお釣り返還方法：
a) お釣りは送信元のアドレスに返される。 b) お釣りは新しく生成されたビットコインアドレスに返される。
ほとんどの人は気にせず、a)の動作を期待するので、これをデフォルトにする。 トランザクションのプライバシーを気にする人は、クライアントの設定オプションで b)を有効にできる。
新しいアドレスが必要な時に使用するために、事前に作成したアドレスのストックをウォレットにキューしておくべきだ。それほど大きくないので、たくさん持っておいても問題ない。これにより、誰かがバックアップを取った後に新しいアドレスを要求し、それで大きな支払いを受け取るケースもより一般的にカバーできる。あるタイプのアドレス需要が他のタイプのために枯渇しないように、別々のキューを設けるべきかもしれない。
アドレスは通常の場所に作成・保存されるが、「作成済み・未使用」アドレスの別のリストにも記載される。アドレスが要求されると、未使用キューの先頭のアドレスが渡され、新しいアドレスが作成されて末尾に追加される。
ブロック読み込みコードには、wallet.dat をコピーした人のケースを修復するために作られた何らかの再スキャンがある。ウォレットが復元されたために忘れられた、既に受信済みのブロック内の受信支払いを再発見するケースを再スキャンが処理できるか確認する必要がある。
少しでも古いバックアップを復元できないとすると、毎回トランザクションの後にバックアップしなければならないということになるのか？
これは可能な解決策か？ 俺は 2 台のコンピューターを持っていて、1 台を小額のトランザクションに常用している。時折、もう 1 台のマシンに大金を送って貯めておく――転送するだけだ。それから、すぐにそのマシンの wallet.dat を安全な場所にバックアップする。
確認だが、wallet.dat に保存されている「コイン」は本質的には単なるキャッシュだろう？ 俺が使える「本当の」BTC の数はチェーンにエンコードされている。
すべての秘密鍵を持っていれば、ブロックリストをスキャンしてその「キャッシュ」を復元できるはずだ。
提案：ウォレットにそのウォレットの最後の既知の正常ポイントとなるブロック番号/ID を含める。バックアップからウォレットを復元したら、新しいブロックを再スキャンして最新であることを確認できる。
第二の提案：ユーザーがすべての鍵を再ダウンロードせずにウォレットを再構築できるようにする。
最終的な提案：「本物の」重要データ（秘密鍵）を「キャッシュ」（現在のコイン）から分離する。コインにアクセスするために絶対に重要なデータを、効率的にコインを見つけて使えるように設計されたシステムと混同する理由はない。
（俺が BitCoin の内部動作を根本的に誤解していなければの話だが！）
dete：その場合、君は秘密鍵を失っている。コインを送るたびにほとんどの場合、自分自身にも一部のコインを送り返しているんだ――新しい鍵ペアにな。この新しい秘密鍵はバックアップに入っていないから、コインを失うことになる。
再スキャンが、すでに受信済みだがウォレットが復元されたため忘れられたブロックの中の受信支払いを再発見するケースを処理するかどうか確認する必要がある。
ああ、それは便利な挙動になるだろう。もっと良い鍵管理――アドレスを自由にインポート、エクスポート、作成、削除できる機能――も必要だと思う。現在のシステムは作成しかできない――削除もファイルへのエクスポートもできない。
新しいアドレスが必要な時に使用するために、事前に作成したアドレスのストックをウォレットにキューしておくべきだ。それほど大きくないので、たくさん持っておいても問題ない。これにより、誰かがバックアップを取った後に新しいアドレスを要求し、それで大きな支払いを受け取るケースもより一般的にカバーできる。あるタイプのアドレス需要が他のタイプのために枯渇しないように、別々のキューを設けるべきかもしれない。
アドレスは通常の場所に作成・保存されるが、「作成済み・未使用」アドレスの別のリストにも記載される。アドレスが要求されると、未使用キューの先頭のアドレスが渡され、新しいアドレスが作成されて末尾に追加される。
ブロック読み込みコードには、wallet.datをコピーした人のケースを修復するために作られた何らかの再スキャンがある。ウォレットが復元されたために忘れられた、既に受信済みのブロック内の受信支払いを再発見するケースを再スキャンが処理できるか確認する必要がある。
PGP で行われているように、鍵ペアをテキスト形式でエクスポートし、また戻ってインポートできるようにする方が良いだろう。 また、例えば no-warranty-expert-mode で、トランザクション出力（および入力）に対するさらなる制御を追加するのも便利だろう。 俺は tx 入力の手動選択と tx 出力の指定を要望する。-do-as-i-say オプション付きのコマンドラインモードでのみ存在させればいい。