The point is.. you don't need to store the child private key anywhere.
It is correct that you need it to sign transaction from child public keys. But it can always be derived using the master private key.
The big advantage with this is that you only need the master private key to gain access to all of your child private keys. This simplifies the whole backup process a lot.
With old fashioned wallets, you need to back it up regularly since these contain X unused private-/public- keypairs (called: address gap).
Each time new private keys are attached to this wallet, you need to back it up to ensure you'll not lose access to these private keys.
This does no longer apply to HD wallets. You only need the xpriv (which can be backed up upon creating the wallet) to derive all future private keys.
Topic: Bitcoin crash when sending coins (Read 15521 times)
I uploaded this fix to the SVN. It watches for spent coins and updates your wallet on load and also continuously as blocks come in. I also put a better error message, but it should never hit it because it always finds spent coins ahead of time, unless you spent the same money at the same time on two computers at once.
If you want to try it, PM or e-mail me your e-mail address where I can send it as an attachment and also what OS (win, linux 32-bit, linux 64-bit).
If you want to try it, PM or e-mail me your e-mail address where I can send it as an attachment and also what OS (win, linux 32-bit, linux 64-bit).
The resync idea would go through your wallet and check it against the block index to find any transactions that your current computer doesn't realize are already spent. That could happen if they were spent on another computer with a copy of the wallet file, or you had to restore the wallet to a backup from before they were spent. Currently, the software just assumes it always knows whether its transactions are spent because it marks them spent in wallet.dat when it spends them.
A wallet merge tool is possible to implement but much less in demand once resync solves most of the problem. With resync, you could do about the same thing by sending all the money from one wallet to the other. The receiver would resync and discover all its overlapping coins were spent, then receive them in the new transaction.
A wallet merge tool is possible to implement but much less in demand once resync solves most of the problem. With resync, you could do about the same thing by sending all the money from one wallet to the other. The receiver would resync and discover all its overlapping coins were spent, then receive them in the new transaction.
Yes, I thought it had something to do with that.
It would be nice if there was a wallet tool for merging wallet files, removing unused bitcoin addresses and as you say resyncing. (I tried to just re-download all the blocks, but as you know the transactions stayed anyway.)
What about resyncing in the future when the Merkle-tree is pruned?
It would be nice if there was a wallet tool for merging wallet files, removing unused bitcoin addresses and as you say resyncing. (I tried to just re-download all the blocks, but as you know the transactions stayed anyway.)
What about resyncing in the future when the Merkle-tree is pruned?
That is what happens if you copy wallet files around. If you copy your wallet file to a second computer, then they both think the money in the wallet is theirs. If one spends any of it, the other doesn't know those coins are already spent and would try to spend them again, and that's the error you would hit.
Now that it's clear this is a key error message, it ought to be something more like "the money appears to be already spent... this could happen if you used a copy of your wallet file on another computer."
You can move or backup your wallet file, but it needs to have only one "lineage" and only used in one place at a time. Any time you transfer money out of it, then you must no longer use any previous copies.
This brings up a good point. In the case of restoring a backup that may be from before you spent some coins, we need to add functionality to resync it to discover which coins have already been spent. This would not be hard to do, it just hasn't been implemented yet. I'll add it to the list. This would make it mostly repair the situation instead of giving that error message.
Now that it's clear this is a key error message, it ought to be something more like "the money appears to be already spent... this could happen if you used a copy of your wallet file on another computer."
You can move or backup your wallet file, but it needs to have only one "lineage" and only used in one place at a time. Any time you transfer money out of it, then you must no longer use any previous copies.
This brings up a good point. In the case of restoring a backup that may be from before you spent some coins, we need to add functionality to resync it to discover which coins have already been spent. This would not be hard to do, it just hasn't been implemented yet. I'll add it to the list. This would make it mostly repair the situation instead of giving that error message.
Lately when I've been trying to send coins, the following popups twice, then the application terminates.
When i restart bitcoin.exe, the transaction is showing as 0/unconfirmed. The status do not change even when the total block count increases.
I'm running two instances of bitcoin in my home LAN, one at my desktop computer, and one in a virtual machine on my laptop, with the switch -connect=192.168.0.2 (ip of desktop computer).
This occurs when I send to my own bitcoin address, to my other computers bitcoin address and to an other bitcoin address not currently active anywhere. I'm not sending by ip.
I've been moving wallets and index-files back and forth, could this have something to do with this?
Code:
EXCEPTION: St13runtime_error
SendMoney() : wtxNew.AcceptTransaction() failed
c:\Documents and Settings\username\bitcoin-0.2.0\bitcoin.exe in
CMyApp::OnExceptionInMainLoop()
SendMoney() : wtxNew.AcceptTransaction() failed
c:\Documents and Settings\username\bitcoin-0.2.0\bitcoin.exe in
CMyApp::OnExceptionInMainLoop()
When i restart bitcoin.exe, the transaction is showing as 0/unconfirmed. The status do not change even when the total block count increases.
I'm running two instances of bitcoin in my home LAN, one at my desktop computer, and one in a virtual machine on my laptop, with the switch -connect=192.168.0.2 (ip of desktop computer).
This occurs when I send to my own bitcoin address, to my other computers bitcoin address and to an other bitcoin address not currently active anywhere. I'm not sending by ip.
I've been moving wallets and index-files back and forth, could this have something to do with this?
Jump to: