プライバシー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オプション付きのコマンドラインモードでのみ存在させればいい。