crowning
Well-known member
No, it's just mixing stuff.
And, in addition, when you mix on a newly installed wallet for the very first time you get asked exactly this, whether you want to see those transactions or not.
Last edited:
V12.1 Testnet Launch Thread
- Thread starter eduffield
- Start date
- Status
No, it's just mixing stuff.
And, in addition, when you mix on a newly installed wallet for the very first time you get asked exactly this, whether you want to see those transactions or not.
So I just confirmed for myself (you all obviously knew) that I still need a hot wallet to start my masternodes. Is there a plan to make it so we never have to expose our wallets to the internet?
Also, one of my MN wallets won't get beyond a fork (the 12365 one) Is there a way to force a wallet to follow the longest fork? Because multiple starts with zap and reindex leaves me in the same spot. It would be nice to have a way to force the wallet to take the longest chain?
Oh yah, I forget all the time. I need to delete all my files in the .dash/testnet3 folder to bypass the forks, ugh
Also, one of my MN wallets won't get beyond a fork (the 12365 one) Is there a way to force a wallet to follow the longest fork? Because multiple starts with zap and reindex leaves me in the same spot. It would be nice to have a way to force the wallet to take the longest chain?
Oh yah, I forget all the time. I need to delete all my files in the .dash/testnet3 folder to bypass the forks, ugh
Last edited:
Check this in debug window
Code:
masternodebroadcastnetwork messages in general are still not ideal however so broadcast relaying could fail too... @UdjinM6 is working on it.
It always adds one more key to the pool once you use one from the pool, the problem is you don't have it in backup.
yep, should be much better with the latest binaries thoughCheck this in debug window
Code:masternodebroadcast
network messages in general are still not ideal however so broadcast relaying could fail too... @UdjinM6 is working on it.
EVERYONE: pls, update your masternodes and if you are mining pls update biniries too. Network needs both most of miners AND masternodes to use binaries with fixed payment code (or we'll keep forking).
Thanks!
Cant we make backup during mix process, i mean when new key is added?
I think it's safer if you simply made a bunch of keys that will last a while (I figure 10,000 a month for liquidity providing) and keep a back up of the wallet in several places, then refilling the key pool at the end of that time period, and taking a new backup of the wallet. I don't know, with automatic backing up of wallets, people might get lazy and then one day the hard drive fails....
Check this in debug window
Code:masternodebroadcast
network messages in general are still not ideal however so broadcast relaying could fail too... @UdjinM6 is working on it.
Thank you
If your PC or Os or Dash crash, all gone, thats why i asked autobackup.
When wallet add new key, you have basically new wallet and you dont have ANY backup at that point.
You only have old backups + that what wallet made when it started.
I understand, AjM. One thing that I do for my liquidity wallet is create 40,000 keys with keypoolrefill 40000 in the command line. And every time I back up my wallet, I do the same. The wallet then makes sure I have 40,000 available keys. I like to do it this way because I always know how many keys I have left, 'cause you can see it when you do a "getinfo" so I know where I stand with my backups.
However, you can do this another way. You can put keypool=40000 in the dash.conf file and issue keypoolrefill in the command line. Now, I'm not sure if it always keeps the wallet updated with 40,000 keys after that or if you periodically have to issue keypoolrefill in the command line to refill. If the later, then I guess you'd have just as much control as I have when I simply do the command with the 40000 without putting it in the dash.conf file\
Anyway, when I refill my wallet, I make a backup for my USBs etc...
So I guess my question is, do you mean to have something that backs up your wallet automatically to another location aside from the hard drive that is running your wallet?
Anyway, when we have Evolution, the wallets will be "backed up" in the network; retrievable with your deterministic wallet, which will be super nice because then it'll be almost impossible to lose your funds if you don't lose your 20 word key thingie, or whatever it is. Also, Evan is planning to make it so that you can also store a personal backup on your own server or whatever, so in the extremely unlikelihood that your account backups disappear off the network, you still have that information in your own possession.
However, you can do this another way. You can put keypool=40000 in the dash.conf file and issue keypoolrefill in the command line. Now, I'm not sure if it always keeps the wallet updated with 40,000 keys after that or if you periodically have to issue keypoolrefill in the command line to refill. If the later, then I guess you'd have just as much control as I have when I simply do the command with the 40000 without putting it in the dash.conf file\
Anyway, when I refill my wallet, I make a backup for my USBs etc...
So I guess my question is, do you mean to have something that backs up your wallet automatically to another location aside from the hard drive that is running your wallet?
Anyway, when we have Evolution, the wallets will be "backed up" in the network; retrievable with your deterministic wallet, which will be super nice because then it'll be almost impossible to lose your funds if you don't lose your 20 word key thingie, or whatever it is
. Also, Evan is planning to make it so that you can also store a personal backup on your own server or whatever, so in the extremely unlikelihood that your account backups disappear off the network, you still have that information in your own possession.
You have 1000 keys to use until backup starts to become useless, that's what keypool is for - it's a set of pre-generated pairs (private key, public key). You will use freshly new generated address/privkey added to keypool at this point only 1000 tx outputs later so you have a plenty time to make back. Currently wallet is making new backup on every (re)start.
ashmoran
Member
If you feel adventurous: Here is a rough-cut Windows binary: https://dashpay.atlassian.net/build...fact/JOB1/electrum-dash.exe/electrum-dash.exe
I am still in the process of creating proper packages
Ensure that you are connecting to electrum.drk.siampm.com, as Masternode/Trezor functionality needs a updated server
Instructions should be here --> https://github.com/dashpay/electrum-dash/blob/develop/docs/masternodes.md
Progress! I'm using a Mac so I've gone about getting everything to work from a cloned Electrum-Dash repo (develop branch).
I've also got 1345 tDASH – the DashNinja faucet is very generous
– in Dash Core 0.12.1.However, I've looked everywhere and I can't see any way to make Electrum-Dash run on testnet. The only evidence I can find is GitHub issue #21 for Electrum ("Add access to the Testnet network for debugging purposes"), which seems to imply it doesn't exist.
Is it possible to test Masternode-Trezor support without using 1000 real dash? The masternode collateral required for this test is worth several times the price of my laptop
Since talking about adding keys, I issued keypoolrefill 20000 to my test wallet and it crashed. This is the last of my log:
There doesn't seem to be an error, it just crashed. Looks like I'd have to reissue the command to get it to finish after restarting. Anyway, don't know if that was just a issue with my computer as it's a little old, or something that needed to be reported It's probably my old computer, but if anyone else wants to try it to see if the wallet crashes, have fun
Code:
2016-05-27 15:26:34 init message: Loading wallet... (71.32 %)
2016-05-27 15:26:34 keypool added key 14266, size=13567
2016-05-27 15:26:34 init message: Loading wallet... (71.33 %)
2016-05-27 15:26:34 keypool added key 14267, size=13568
2016-05-27 15:26:34 init message: Loading wallet... (71.33 %)
2016-05-27 15:26:34 keypool added key 14268, size=13569
2016-05-27 15:26:34 init message: Loading wallet... (71.34 %)
2016-05-27 15:26:34 keypool added key 14269, size=13570
2016-05-27 15:26:34 init message: Loading wallet... (71.34 %)
2016-05-27 15:26:34 keypool added key 14270, size=13571
2016-05-27 15:26:34 init message: Loading wallet... (71.35 %)
2016-05-27 15:26:34 keypool added key 14271, size=13572
2016-05-27 15:26:34 init message: Loading wallet... (71.35 %)There doesn't seem to be an error, it just crashed. Looks like I'd have to reissue the command to get it to finish after restarting. Anyway, don't know if that was just a issue with my computer as it's a little old, or something that needed to be reported
It's probably my old computer, but if anyone else wants to try it to see if the wallet crashes, have fun 
Ok, how about this idea.
In the same way that when you password protect your wallet you're forced to reboot the QT, why not make it that once you press Start Mixing, a pop-up appears warning the user the QT needs to restart the wallet to prepare it for the mixing process, warning users to "Please backup after restarting"
"Creating mix wallet requires you to restart the QT. It's a one time operation and can take just a few minutes. Please backup wallet after restarting. Existing funds will not be affected, but previous backups will become obsolete" - sort of thing?
On close/reopen you could have it fill the keypool with an absurd amount. Also in the Information window there could be a keypool monitor, or even right under the Private Send amount in the main windows to help keep track ... when it is about to, or actually runs out (x<1000) it could warn the user to refill and backup again?
Ideas are easy, hum?
.
In the same way that when you password protect your wallet you're forced to reboot the QT, why not make it that once you press Start Mixing, a pop-up appears warning the user the QT needs to restart the wallet to prepare it for the mixing process, warning users to "Please backup after restarting"
"Creating mix wallet requires you to restart the QT. It's a one time operation and can take just a few minutes. Please backup wallet after restarting. Existing funds will not be affected, but previous backups will become obsolete" - sort of thing?
On close/reopen you could have it fill the keypool with an absurd amount. Also in the Information window there could be a keypool monitor, or even right under the Private Send amount in the main windows to help keep track ... when it is about to, or actually runs out (x<1000) it could warn the user to refill and backup again?
Ideas are easy, hum?
.
Last edited:
Not sure about the first one but we could probably save keymap size on start in some tmp variable, show (sizeOnStart + keypoolSize - currentSize) and warn if it's very low (like 10%) or even stop mixing completely... smth like the way notebooks behave when they run out of battery... hmm...Ok, how about this idea.
In the same way that when you password protect your wallet you're forced to reboot the QT, why not make it that once you press Start Mixing, a pop-up appears warning the user the QT needs to restart the wallet to prepare it for the mixing process, warning users to "Please backup after restarting"
"Creating mix wallet requires you to restart the QT. It's a one time operation and can take just a few minutes. Please backup wallet after restarting. Existing funds will not be affected, but previous backups will become obsolete" - sort of thing?
On close/reopen you could have it fill the keypool with an absurd amount. Also in the Information window there could be a keypool monitor, or even right under the Private Send amount in the main windows to help keep track ... when it is about to, or actually runs out (x<1000) it could warn the user to refill and backup again?
Ideas are easy, hum?
.
Are you saying that if i have fresh new wallet and 1000 keys in it,
and i do 6 hours of mixing, wallet is still unchanged in any way?
Agree, this would be very nice info.
No, i thought when mixing happens,
keys are changed and that info is lost if something crashes,
because that info is only in the memory.
Wallet is changed of course (filled with new keys) but you could still be using keys from first 1000 keys generated on wallet creation. Keys are used in the same order they were created the question is have you used 1000 already or not. Wallet is dumped to disk periodically to save some meta-data but I believe it writes to disk as soon as it has new key. So technically you always have new keys saved but you have no backup and the wallet you are saving to could get corrupted (i.e. become unrecoverable).
Ok, so if 1000 is not all yet used and wallet crash, all is good because of that backup which was made in the start, right?
- Status