Any backup process/procedure would just be a stopgap until there's time to properly work on coding solutions in software. We can try to use words to help the situation until code gets there.
The main backup improvement will be pre-made pool of keys, and a rescan at load to scrape missed transactions from the block history. Then a backup will last forward for a long time.
Topic: Need a post writing up some things users should know (Read 9106 times)
see https://bitcointalksearch.org/topic/auto-backing-up-of-walletdat-921 for continued discussion about backups
So how simple is it? I'm just now thinking about foolproof backups on the lottery site I posted about yesterday, and I'm struggling to find information on this. Can bitcoind dump it in a safe state, or at least flush it on request? If I backup the file mid transaction, do I loose the whole thing or just the update in progress? When do I need to backup? Every outgoing transfer is obvious, there are key pairs created automagically, but what about transfers received? the key pair we already had, no new address needed to be created afaict. Or does bitcoin do the same change dance on the receive side too?
This part is, I believe, the most critical of them all. While MSE and clock skews may prevent normal program usage, the wallet backup issues have made people loose a bunch of coins which, obviously, sucks and doesn't do much on supporting continued usage.
This comment seems worthy of having this thread appear threaded so that discussion could expand exponentially. In the case that this forum is not threaded, however, I will briefly state (without getting offtopic) that there should be some sort of established procedures or mechanisms to handle either regular interval or triggered backups without interrupting the Bitcoin process. It seems that it is essential to "perfect" data reliability/availability as best as possible so as to provide more incentive for adoption.
Actually, it's not so offtopic.
Instead of introducing a warning or establishing a precedence of caution and delay in handling wallet file or backups, as I suggested above, the implementation for backing up data/wallet file needs more thought/establishment.
I am not familiar with the current process/structure of data flow that occurs, but if someone could write up or draw a diagram or something that shows how the flow of data appears then perhaps with this diagram-liek information, others, like myself, can help to understand how things work and maybe offer suggestions for improvements or to recognize things like after which data sent/received is worthy of implementing a kind of automated/triggered backup or similar action.
see https://bitcointalksearch.org/topic/auto-backing-up-of-walletdat-921 for continued discussion about backups
- Warning not to mess around with your wallet.dat file. It's a database file, it's not as simple as you think. In this Beta version, we haven't had time to try and tinker-proof it yet. It may not work as expected if you start swapping it around.
So how simple is it? I'm just now thinking about foolproof backups on the lottery site I posted about yesterday, and I'm struggling to find information on this. Can bitcoind dump it in a safe state, or at least flush it on request? If I backup the file mid transaction, do I loose the whole thing or just the update in progress? When do I need to backup? Every outgoing transfer is obvious, there are key pairs created automagically, but what about transfers received? the key pair we already had, no new address needed to be created afaict. Or does bitcoin do the same change dance on the receive side too?
This part is, I believe, the most critical of them all. While MSE and clock skews may prevent normal program usage, the wallet backup issues have made people loose a bunch of coins which, obviously, sucks and doesn't do much on supporting continued usage.
This comment seems worthy of having this thread appear threaded so that discussion could expand exponentially. In the case that this forum is not threaded, however, I will briefly state (without getting offtopic) that there should be some sort of established procedures or mechanisms to handle either regular interval or triggered backups without interrupting the Bitcoin process. It seems that it is essential to "perfect" data reliability/availability as best as possible so as to provide more incentive for adoption.
Actually, it's not so offtopic.
- Warning not to mess around with your wallet.dat file. It's a database file, it's not as simple as you think. In this Beta version, we haven't had time to try and tinker-proof it yet. It may not work as expected if you start swapping it around.
Instead of introducing a warning or establishing a precedence of caution and delay in handling wallet file or backups, as I suggested above, the implementation for backing up data/wallet file needs more thought/establishment.
I am not familiar with the current process/structure of data flow that occurs, but if someone could write up or draw a diagram or something that shows how the flow of data appears then perhaps with this diagram-liek information, others, like myself, can help to understand how things work and maybe offer suggestions for improvements or to recognize things like after which data sent/received is worthy of implementing a kind of automated/triggered backup or similar action.
see https://bitcointalksearch.org/topic/auto-backing-up-of-walletdat-921 for continued discussion about backups
- Warning not to mess around with your wallet.dat file. It's a database file, it's not as simple as you think. In this Beta version, we haven't had time to try and tinker-proof it yet. It may not work as expected if you start swapping it around.
So how simple is it? I'm just now thinking about foolproof backups on the lottery site I posted about yesterday, and I'm struggling to find information on this. Can bitcoind dump it in a safe state, or at least flush it on request? If I backup the file mid transaction, do I loose the whole thing or just the update in progress? When do I need to backup? Every outgoing transfer is obvious, there are key pairs created automagically, but what about transfers received? the key pair we already had, no new address needed to be created afaict. Or does bitcoin do the same change dance on the receive side too?
This part is, I believe, the most critical of them all. While MSE and clock skews may prevent normal program usage, the wallet backup issues have made people loose a bunch of coins which, obviously, sucks and doesn't do much on supporting continued usage.
The clock part will be covered in the next release (0.3.11 or higher). SVN rev 141 pops up a message box if your clock is too far off.
mizeryderia, you just copied and pasted satoshis post without adding any value.
You could have tried to address the points he raised, or at least put up a note explaining why this page was on the wiki and what you wanted people to do with it.
You could have tried to address the points he raised, or at least put up a note explaining why this page was on the wiki and what you wanted people to do with it.
I posted the above comment onto the wiki for posting a list these things users should know: http://www.bitcoin.org/wiki/doku.php?id=things_you_should_know
I apologize. I wasn't sure what to add.
mizeryderia, you just copied and pasted satoshis post without adding any value.
You could have tried to address the points he raised, or at least put up a note explaining why this page was on the wiki and what you wanted people to do with it.
You could have tried to address the points he raised, or at least put up a note explaining why this page was on the wiki and what you wanted people to do with it.
I apologize. I wasn't sure what to add.
I'm not sure what to call it, but we could use a post that lists these things users should know. If someone has time to write it, here's the list:
- Make sure your clock is set correctly.
- Microsoft Security Essentials. This never got written up proper.
- Warning not to mess around with your wallet.dat file. It's a database file, it's not as simple as you think. In this Beta version, we haven't had time to try and tinker-proof it yet. It may not work as expected if you start swapping it around.
- Make sure your clock is set correctly.
- Microsoft Security Essentials. This never got written up proper.
- Warning not to mess around with your wallet.dat file. It's a database file, it's not as simple as you think. In this Beta version, we haven't had time to try and tinker-proof it yet. It may not work as expected if you start swapping it around.
Jump to: