redundant wallet not picking up transactions about dcrwallet HOT 9 CLOSED

This would seem to be by design, as it would be too time consuming to rescan the entire chain. See davecgh's response here and here.

from dcrwallet.

I see, so that's why I the only transaction trace I can find is when using getrawtransaction. Because the wallet is just ignoring it otherwise. In that case what would be the correct way to re-sync other wallets (create new addresses according to the main wallet growth ? set the wallet to reuse addresses when purchasing tickets ?Maybe a "full rescan" command would be useful if someone would loose count of how many adresses have been created by the main wallet.

Then, what would be the correct way to have redundant wallets online so they can vote in case the main wallet is down or a network error occurs when a ticket is chosen ?. From my perspective the only way to achieve that was to create identical wallet online but having just one used for transactions and purchases. The other wallet would just be unlocked and ready to vote but with a really high maintainbalance value and low ticket price so it doesn't create new tickets.

from dcrwallet.

The devs have given fairly stern advice not to use multiple wallets generated with the same seed.

However, I believe with the --ticketaddress flag for dcrwallet, you can avoid having multiple wallets with the same seed and achieve staking redundancy. Sorry for the wiki link. Does this look like a solution? I'm genuinely curious about this.

I'd love if a developer could provide some advice on how to go about setting up redundancy with PoS.

from dcrwallet.

Yes I think further advice would be needed because the --ticketaddress flag seems to allow a separation of vote from the main wallet such as : Wallet A is a cold wallet (locked or offline) but has defined with --ticketaddress that wallet B can vote in its place. Which is great but doesn't provide redundancy by itself.

from dcrwallet.

You can use redundant wallets so long as the only function of the wallet is voting. You must also either reuse or pregenerate all the addresses on the voting wallet, so it knows what addresses to look out for when you send it tickets.

Ideally, after creating your voting wallet and generating addresses, close the wallet with 'stop' and then copy it.

from dcrwallet.

Suppose then you reopen this copied wallet on multiple machines (each with enablestakemining still on?), then when it comes time to vote won't there be a race?

from dcrwallet.

No. Stake voting is handled differently and doesn't rely on address tracking. As long as --enablestakemining is on and the wallet is unlocked, it will vote automatically and without issue. You may get an error that the vote was already seen on the network, but no corruption.

from dcrwallet.

Thanks for the information, that clears up a lot of things. However on a more practical note, I'm not sure copying wallet files between systems is the most secure or efficient way of handling redundancy.

For the moment I've been experimenting with following procedure on each redundant system:
1- init a wallet using your seed (--create)
2- before starting the dcrwallet, copy wallet.db to keep an initial empty version of itself ex: wallet.db.init
3- start dcrwallet

Then when you want a full rescan on one of the redundant wallet to keep track of possible new addresses:
1- stop dcrwallet
2- copy wallet.db.init over wallet.db
3- start dcrwallet

The wallet will print "No recorded transaction history -- needs full rescan", and the wallet will sync and become up to date with all transactions and addresses from your main wallet. This way you don't have to move wallet files manually or re-enter the seed each time.

I guess if you could initiate the same "full rescan" operation with a dcrctl wallet command that would be an even better way of dealing with this situation.

from dcrwallet.

Yeah, creating the wallet and copying pre-full scan is an easy way to ensure it does the initial rescan upon loading it up. There should be a way to trigger that from RPC as well, but for now it can only be triggered on startup.

Be sure to know that anything that is imported, like a redeem script for a multsig P2SH, will NOT be automatically discovered by a wallet rescan. Be careful not to lose imported keys or scripts.

from dcrwallet.