（ギャビン・アンドレセンのコンテキスト投稿）

ウォレットファイルのバックアップと復元でコインを失う方法を説明する：

ウォレットにピカピカの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をコピーした人のケースを修復するために作られた何らかの再スキャンがある。ウォレットが復元されたために忘れられた、既に受信済みのブロック内の受信支払いを再発見するケースを再スキャンが処理できるか確認する必要がある。