wallet.datの自動バックアップ

12 件のメッセージ BitcoinTalk nelisky, サトシ・ナカモト, mizerydearia, ジェフ・ガージック 2010年8月24日 — 2010年9月6日
nelisky 2010年8月24日 原文 · 個別ページ

他の多くの方と同様に、wallet.datのバックアップが必要である。そしてこれはサーバー上にあるため、無人で実行される必要がある。また、このサーバーは宝くじに使用されているため、bitcoindを停止してはならない。

今のところ単にファイルをコピーしており、破損したファイルに耐えられるよう頻繁に行っている。しかしこれは理想的ではない。すべてのトランザクション後にバックアップすべきである(送信時のみ正しいか? 送金の受信時には新しいアドレスは作成されないはずだが)。あるいは新しいアドレスを作成するたびにバックアップすべきである。

そのため、ファイルをコピーする代わりに、db_dumpを使用して内容をダンプし、念のため-rフラグを使用することを考えた。これは機能するだろうか?

理想的な解決策は、以下のいずれかを行うRPC呼び出しである:

  • フラッシュして、新しいRPC呼び出し(どの呼び出しでもよく、ロック解除コマンドである必要はない)が来るまで更新をロックする
  • フラッシュしてwallet.datを別のファイルにコピーする
  • フラッシュしてjsonrpc経由でダンプする。各鍵が配列内で個別に返されれば、‘lastseen=X’を指定して新しい鍵のみを取得できる

これは実現可能だろうか? どれが最も適しているだろうか?

topic 873 がやや関連している。

別のトピックに投稿し始めたが、ここでも繰り返す。このスレッドの方がトピックに特化しているようだ。

主なバックアップの改善は、事前生成された鍵のプールと、ロード時にブロック履歴から見逃したトランザクションをスクレイピングする再スキャンだ。そうすればバックアップは長期間有効に持続する。

nelisky、あなたと同じアイデアを投稿し始めていた。

ウォレットをロックし、フラッシュし、wallet.datを指定した場所にコピーしてからアンロックするjson-rpcコマンドはどうだろうか?プールされた鍵よりも小さなプロジェクトなので、先に実装できるかもしれない。

ファイルをコピーする最もシンプルでポータブルな方法は何だろうか?Boostに何かあるか?

名前は何がよいだろうか?例えば: backupwallet

nelisky 2010年8月26日 原文 · 個別ページ

Quote from: satoshi on August 26, 2010, 12:57:40 AM

別のトピックに投稿し始めたが、ここでも繰り返す。このスレッドの方がトピックに特化しているようだ。

主なバックアップの改善は、事前生成された鍵のプールと、ロード時にブロック履歴から見逃したトランザクションをスクレイピングする再スキャンだ。そうすればバックアップは長期間有効に持続する。

nelisky、あなたと同じアイデアを投稿し始めていた。

ウォレットをロックし、フラッシュし、wallet.datを指定した場所にコピーしてからアンロックするjson-rpcコマンドはどうだろうか?プールされた鍵よりも小さなプロジェクトなので、先に実装できるかもしれない。

ファイルをコピーする最もシンプルでポータブルな方法は何だろうか?Boostに何かあるか?

名前は何がよいだろうか?例えば: backupwallet

そうだ、あなたの別の投稿を見たし、アドレスのプールというのはとても気に入っているが、それらが全部使われた時に簡単にバックアップする方法はまだ必要だろう?アドレス空間が巨大なのは分かっているが、1日に数千のアドレスを配信するアプリケーションがあるかもしれない。

Quote from: satoshi on August 26, 2010, 12:57:40 AM

別のトピックに投稿し始めたが、ここでも繰り返す。このスレッドの方がトピックに特化しているようだ。

主なバックアップの改善は、事前生成された鍵のプールと、ロード時にブロック履歴から見逃したトランザクションをスクレイピングする再スキャンだ。そうすればバックアップは長期間有効に持続する。

nelisky、あなたと同じアイデアを投稿し始めていた。

ウォレットをロックし、フラッシュし、wallet.datを指定した場所にコピーしてからアンロックするjson-rpcコマンドはどうだろうか?プールされた鍵よりも小さなプロジェクトなので、先に実装できるかもしれない。

ファイルをコピーする最もシンプルでポータブルな方法は何だろうか?Boostに何かあるか?

名前は何がよいだろうか?例えば: backupwallet

名前も実装アプローチも全て素晴らしい。

ファイルコピーについては、boost依存を増やす必要があるだろうか?私としては依存の少ないコアライブラリが欲しい。C++では標準のファイルストリームを使えばいいだろう?http://www.dreamincode.net/code/snippet2306.htm のようなもの(ざっと検索した結果で試していないが、正しそうだ)。

さらに良くするなら、ウォレットに変更があるたびにコピーを行うトリガーを追加するのはどうか?まあ、これが適切に動作するにはファイルロックに依存することになるが、Windowsではうまくいかなかった記憶がある。あっちでコーディングしたのは随分前だが Smiley

Quote from: satoshi on August 26, 2010, 12:57:40 AM

別のトピックに投稿し始めたが、ここでも繰り返す。このスレッドの方がトピックに特化しているようだ。

主なバックアップの改善は、事前生成された鍵のプールと、ロード時にブロック履歴から見逃したトランザクションをスクレイピングする再スキャンだ。そうすればバックアップは長期間有効に持続する。

nelisky、あなたと同じアイデアを投稿し始めていた。

ウォレットをロックし、フラッシュし、wallet.datを指定した場所にコピーしてからアンロックするjson-rpcコマンドはどうだろうか?プールされた鍵よりも小さなプロジェクトなので、先に実装できるかもしれない。

ファイルをコピーする最もシンプルでポータブルな方法は何だろうか?Boostに何かあるか?

名前は何がよいだろうか?例えば: backupwallet

mmap(2) + memcpy(3) か?Boost::Iostreamsには既にmapped_file Sourceがある。

Quote from: satoshi on August 26, 2010, 12:57:40 AM

別のトピックに投稿し始めたが、ここでも繰り返す。このスレッドの方がトピックに特化しているようだ。

主なバックアップの改善は、事前生成された鍵のプールと、ロード時にブロック履歴から見逃したトランザクションをスクレイピングする再スキャンだ。そうすればバックアップは長期間有効に持続する。

nelisky、あなたと同じアイデアを投稿し始めていた。

ウォレットをロックし、フラッシュし、wallet.datを指定した場所にコピーしてからアンロックするjson-rpcコマンドはどうだろうか?プールされた鍵よりも小さなプロジェクトなので、先に実装できるかもしれない。

ファイルをコピーする最もシンプルでポータブルな方法は何だろうか?Boostに何かあるか?

名前は何がよいだろうか?例えば: backupwallet

非常に便利そうだ!

メモリに読み込んで書き出す方法だと、メモリが逼迫した状況で失敗する可能性がある。

copyfile(const char* from, const char* to)やcopyfile(path from, path to)のような、できればBoostにあるものを探している。見つけてくれれば、実装にかかる可能性が高くなる。

Quote from: nelisky on August 26, 2010, 01:21:57 AM

Quote from: satoshi on August 26, 2010, 12:57:40 AM

もう一つのトピックに投稿し始めたが、ここで繰り返す。このスレッドの方がトピックに特化しているようだ。

主なバックアップの改善は、事前生成された鍵のプールと、ロード時にブロック履歴から見逃したトランザクションを拾うための再スキャンだ。これにより、バックアップが長期間有効になる。

neliskyが言ったのと同じアイデアを投稿しようとしていた。

そうだ、あなたの別の投稿を見たし、アドレスのプールというのはとても気に入っているが、それらが全部使われた時に簡単にバックアップする方法はまだ必要だろう?アドレス空間が巨大なのは分かっているが、1日に数千のアドレスを配信するアプリケーションがあるかもしれない。

Quote from: satoshi on August 26, 2010, 12:57:40 AM

ウォレットをロックし、フラッシュし、指定した場所にwallet.datをコピーし、アンロックするjson-rpcコマンドはどうだ?プールされた鍵より小さなプロジェクトになるので、先に実装できるかもしれない。

ファイルをコピーする最も簡単なポータブルな方法は何か?Boostに何かあるか?

名前はどうすべきか?こういうのはどうだ: backupwallet <保存先>

名前も実装アプローチも全て素晴らしい。

ファイルコピーについては、boost依存を増やす必要があるだろうか?私としては依存の少ないコアライブラリが欲しい。C++では標準のファイルストリームを使えばいいだろう?http://www.dreamincode.net/code/snippet2306.htm のようなもの(ざっと検索した結果で試していないが、正しそうだ)。

さらに良くするなら、ウォレットに変更があるたびにコピーを行うトリガーを追加するのはどうか?まあ、これが適切に動作するにはファイルロックに依存することになるが、Windowsではうまくいかなかった記憶がある。あっちでコーディングしたのは随分前だが Smiley

JSONやwxWidgetsの依存関係を置き換える多数のものにBoostが必要だ。Boostは良い、ポータブルなもので、避けるべきではない。

nelisky 2010年8月27日 原文 · 個別ページ

Quote from: satoshi on August 27, 2010, 01:13:42 AM

メモリに読み込んで書き出す方法だと、メモリが逼迫した状況で失敗する可能性がある。

copyfile(const char* from, const char* to)やcopyfile(path from, path to)のような、できればBoostにあるものを探している。見つけてくれれば、実装にかかる可能性が高くなる。

Quote from: nelisky on August 26, 2010, 01:21:57 AM

Quote from: satoshi on August 26, 2010, 12:57:40 AM

もう一つのトピックに投稿し始めたが、ここで繰り返す。このスレッドの方がトピックに特化しているようだ。

主なバックアップの改善は、事前生成された鍵のプールと、ロード時にブロック履歴から見逃したトランザクションを拾うための再スキャンだ。これにより、バックアップが長期間有効になる。

neliskyが言ったのと同じアイデアを投稿しようとしていた。

そうだ、あなたの別の投稿を見たし、アドレスのプールというのはとても気に入っているが、それらが全部使われた時に簡単にバックアップする方法はまだ必要だろう?アドレス空間が巨大なのは分かっているが、1日に数千のアドレスを配信するアプリケーションがあるかもしれない。

Quote from: satoshi on August 26, 2010, 12:57:40 AM

ウォレットをロックし、フラッシュし、指定した場所にwallet.datをコピーし、アンロックするjson-rpcコマンドはどうだ?プールされた鍵より小さなプロジェクトになるので、先に実装できるかもしれない。

ファイルをコピーする最も簡単なポータブルな方法は何か?Boostに何かあるか?

名前はどうすべきか?こういうのはどうだ: backupwallet <保存先>

名前も実装アプローチも全て素晴らしい。

ファイルコピーについては、boost依存を増やす必要があるだろうか?私としては依存の少ないコアライブラリが欲しい。C++では標準のファイルストリームを使えばいいだろう?http://www.dreamincode.net/code/snippet2306.htm のようなもの(ざっと検索した結果で試していないが、正しそうだ)。

さらに良くするなら、ウォレットに変更があるたびにコピーを行うトリガーを追加するのはどうか?まあ、これが適切に動作するにはファイルロックに依存することになるが、Windowsではうまくいかなかった記憶がある。あっちでコーディングしたのは随分前だが Smiley

JSONやwxWidgetsの依存関係を置き換える多数のものにBoostが必要だ。Boostは良い、ポータブルなもので、避けるべきではない。 Quote from: nelisky on August 26, 2010, 01:21:57 AM Quote from: satoshi on August 26, 2010, 12:57:40 AM

もう一つのトピックに投稿し始めたが、ここで繰り返す。このスレッドの方がトピックに特化しているようだ。

主なバックアップの改善は、事前生成された鍵のプールと、ロード時にブロック履歴から見逃したトランザクションを拾うための再スキャンだ。これにより、バックアップが長期間有効になる。

neliskyが言ったのと同じアイデアを投稿しようとしていた。

そうだ、あなたの別の投稿を見たし、アドレスのプールというのはとても気に入っているが、それらが全部使われた時に簡単にバックアップする方法はまだ必要だろう?アドレス空間が巨大なのは分かっているが、1日に数千のアドレスを配信するアプリケーションがあるかもしれない。

Quote from: satoshi on August 26, 2010, 12:57:40 AM

ウォレットをロックし、フラッシュし、指定した場所にwallet.datをコピーし、アンロックするjson-rpcコマンドはどうだ?プールされた鍵より小さなプロジェクトになるので、先に実装できるかもしれない。

ファイルをコピーする最も簡単なポータブルな方法は何か?Boostに何かあるか?

名前はどうすべきか?こういうのはどうだ: backupwallet <保存先>

名前も実装アプローチも全て素晴らしい。

ファイルコピーについては、boost依存を増やす必要があるだろうか?私としては依存の少ないコアライブラリが欲しい。C++では標準のファイルストリームを使えばいいだろう?http://www.dreamincode.net/code/snippet2306.htm のようなもの(ざっと検索した結果で試していないが、正しそうだ)。

さらに良くするなら、ウォレットに変更があるたびにコピーを行うトリガーを追加するのはどうか?まあ、これが適切に動作するにはファイルロックに依存することになるが、Windowsではうまくいかなかった記憶がある。あっちでコーディングしたのは随分前だが Smiley

では、私が言及したスニペットのシンプルな標準fstreamの使用の何が問題なのか?シンプルが一番だと思う Smiley

しかしboost::filesystemの機能を既に使っているなら、そこからcopy_fileを使える。他に何かのために既に必要でなければ、少々大げさだと思うだけだ。

Quote from: satoshi on August 27, 2010, 01:13:42 AM

メモリに読み込んで書き出す方法だと、メモリが逼迫した状況で失敗する可能性がある。

copyfile(const char* from, const char* to)やcopyfile(path from, path to)のような、できればBoostにあるものを探している。見つけてくれれば、実装にかかる可能性が高くなる。

Quote from: nelisky on August 26, 2010, 01:21:57 AM

Quote from: satoshi on August 26, 2010, 12:57:40 AM

もう一つのトピックに投稿し始めたが、ここで繰り返す。このスレッドの方がトピックに特化しているようだ。

主なバックアップの改善は、事前生成された鍵のプールと、ロード時にブロック履歴から見逃したトランザクションを拾うための再スキャンだ。これにより、バックアップが長期間有効になる。

neliskyが言ったのと同じアイデアを投稿しようとしていた。

そうだ、あなたの別の投稿を見たし、アドレスのプールというのはとても気に入っているが、それらが全部使われた時に簡単にバックアップする方法はまだ必要だろう?アドレス空間が巨大なのは分かっているが、1日に数千のアドレスを配信するアプリケーションがあるかもしれない。

Quote from: satoshi on August 26, 2010, 12:57:40 AM

ウォレットをロックし、フラッシュし、指定した場所にwallet.datをコピーし、アンロックするjson-rpcコマンドはどうだ?プールされた鍵より小さなプロジェクトになるので、先に実装できるかもしれない。

ファイルをコピーする最も簡単なポータブルな方法は何か?Boostに何かあるか?

名前はどうすべきか?こういうのはどうだ: backupwallet <保存先>

名前も実装アプローチも全て素晴らしい。

ファイルコピーについては、boost依存を増やす必要があるだろうか?私としては依存の少ないコアライブラリが欲しい。C++では標準のファイルストリームを使えばいいだろう?http://www.dreamincode.net/code/snippet2306.htm のようなもの(ざっと検索した結果で試していないが、正しそうだ)。

さらに良くするなら、ウォレットに変更があるたびにコピーを行うトリガーを追加するのはどうか?まあ、これが適切に動作するにはファイルロックに依存することになるが、Windowsではうまくいかなかった記憶がある。あっちでコーディングしたのは随分前だが Smiley

JSONやwxWidgetsの依存関係を置き換える多数のものにBoostが必要だ。Boostは良い、ポータブルなもので、避けるべきではない。

mmapが何をするか誤解していないか?mmap / CreateFileMappingはファイルをヒープメモリに読み込むのではない:http://en.wikipedia.org/wiki/Mmap

Windowsにmmap(2)があるとは思えない。自作のものを作ってテストするよりも、既存のファイルコピー関数を呼び出す方が良い。

Quote from: nelisky on August 27, 2010, 01:21:09 AM

Quote from: satoshi on August 27, 2010, 01:13:42 AM

メモリに読み込んで書き出すと、メモリが逼迫している状況では失敗する可能性がある。

copyfile(const char* from, const char* to) や copyfile(path from, path to) のようなものを探している。できればBoostにあるもの。見つけてくれれば、実装に取りかかる可能性が高くなる。

Quote from: nelisky on August 26, 2010, 01:21:57 AM

ファイルコピーについては、boost依存を増やす必要があるだろうか?私としては依存の少ないコアライブラリが欲しい。

JSONやwxWidgetsの依存を置き換える十数個の機能のためにBoostは必須だ。Boostは良い、ポータブルなものだ。敬遠すべきではない。

では、私が言及したスニペットのシンプルな標準fstreamの使用の何が問題なのか?シンプルが一番だと思う Smiley

しかしboost::filesystemの機能を既に使っているなら、そこからcopy_fileを使える。他に何かのために既に必要でなければ、少々大げさだと思うだけだ。

ありがとう。どこかにあるだろうと思っていた。

すでに十数箇所でboost::filesystemを使っている。新たに追加される依存関係ではない。そうでなければ各OSごとに#ifdefを用意してあらゆる場所でテストしなければならないような、多くのポータブルなものを提供してくれる。

Quote from: satoshi on August 27, 2010, 02:54:07 AM

Windowsにmmap(2)があるとは思えない。自作のものを作ってテストするよりも、既存のファイルコピー関数を呼び出す方が良い。

Quote from: nelisky on August 27, 2010, 01:21:09 AM

Quote from: satoshi on August 27, 2010, 01:13:42 AM

メモリに読み込んで書き出すと、メモリが逼迫している状況では失敗する可能性がある。

copyfile(const char* from, const char* to) や copyfile(path from, path to) のようなものを探している。できればBoostにあるもの。見つけてくれれば、実装に取りかかる可能性が高くなる。

Quote from: nelisky on August 26, 2010, 01:21:57 AM

ファイルコピーについては、boost依存を増やす必要があるだろうか?私としては依存の少ないコアライブラリが欲しい。

JSONやwxWidgetsの依存を置き換える十数個の機能のためにBoostは必須だ。Boostは良い、ポータブルなものだ。敬遠すべきではない。

では、私が言及したスニペットのシンプルな標準fstreamの使用の何が問題なのか?シンプルが一番だと思う Smiley

しかしboost::filesystemの機能を既に使っているなら、そこからcopy_fileを使える。他に何かのために既に必要でなければ、少々大げさだと思うだけだ。

ありがとう。どこかにあるだろうと思っていた。

すでに十数箇所でboost::filesystemを使っている。新たに追加される依存関係ではない。そうでなければ各OSごとに#ifdefを用意してあらゆる場所でテストしなければならないような、多くのポータブルなものを提供してくれる。

Windowsバージョンのmmapは返信したメッセージで言及した:CreateFileMapping

以前のメッセージで、boostからの使い方を述べた:Boost::Iostreamsには既にmapped_file Sourceがある。

すまない、最近非常に忙しくてメッセージを流し読みしているが、それでも追いつけない。

可能な限りWindows API呼び出しは避けたい。通常6〜8個のパラメータが必要で、正しく動作させるために多くのテストが必要で、簡単なことを行うのに1ページ分のコードが必要になる。

通常iostreamsは避けている。よく制限にぶつかるようだ。90年代にC++ストリーム標準をやや台無しにしてしまった。残念なことに、正しく実装すればストリームは非常に強力で便利なものになり得る。rpc.cppで使っているのは、まだ間違いだったと判明するかもしれない。

結論は、自作のものを作ってテストするよりも、既存のファイルコピー関数を呼び出す方が良いということだ。

rpc backupwallet がSVN rev 147に入った。