Auto-backup backs up the wallet.dat the currently running wallet uses/sees to a folder "backups" which is created in the same folder as your wallet.dat. If you use different *.dat files in the same folder things may indeed get a bit confusing, but this (advanced) scenario is not what the auto-backup was made for. It was made for the beginners/non-technical users (which will be the majority if Dash adoption grows as much as we all hope) who most probably don't even know that there is a file with the name wallet.dat and even less know where it is located. User who already know how to use different *.dat files in the same folder should know how to make proper backups. BTW, that's the same reason why I implemented the "Open Configuration File" menu. We Dashtalk user know where the configuration file is located, but if you ever had the fun to explain an OSX user where it is located and how to change it you'll understand. Edit: if it's really needed I could change the upper limit to 50 or more files, no biggie.
Again, I'm only armchair programming here, but to support AJM's use case, wouldn't it be enough to filter the files here: https://github.com/dashpay/dash/pull/306/files#diff-c865a8939105e6350a50af02766291b7R757 If you only put them in the folder_set if the filename begins with strWalletFile, then cleanup will only remove the oldest entry for the currently active wallet, so all the ones from other wallet files would remain untouched
I second that (besides "Edit" part) the-baker AjM I'd say "no" to increasing max # of backup files in general but I agree that nWalletBackups could be the limit for every single wallet. The point of this function is to help novice users and/or have some simplified version of time machine BUT at the same time we should try our best not to teach users bad practice of storing backups on the same storage they actually run their wallets. My logic behind that is like that: you would definitely want to use auto-backups for quite a long time if you have large enough max number -> you will leave proper backup setup "for later" -> inevitable disaster.
UdjinM6: Is there a way to make a timer to force the user to properly backup at a certain point? Example message (upon downloading): Welcome to Dash! Proper backup of your wallet file (wallet.dat) is essential, and as such you will be required to perform a backup within 2 (two) days of this message or whenever you next open your wallet. To learn how to perform a backup, click here (link to tutorial). Example message (at time of backup): Dash requires that your wallet.dat is backed up to an outside secure location. Please perform this function before continuing. To learn how to perform a backup, click here. This could result in Dash users being the most secure minded, educated group in all of crypto! It could be a huge advantage going forward. Just sayin'.
hmmmm... not sure about this... messages like that could be annoying and might have overcomplicated implementation (calculating days? ## of backups? both?)... crowning actually was advocating for KISS (can't find any reason to disagree on this) so maybe smth simpler, like additional info-box on first launch - right after wallet asked you where do you want your datadir to be...or maybe even in the same dialog... not sure...
Yes, I think it is important, failing the timer, to have something that alerts the user to the importance of backups.
I asked this in the release thread which is pretty dead, LOL. But I'm wondering if this can be done, or if it might be what is planned? Is there any way that the reference node could be integrated into each wallet / miner node, with another consensus blockchain? A reference node seems necessary, therefore it needs to be decentralized. If all it does is keep track of where each masternode is on the list, couldn't a secondary, short blockchain be added? it's older info could expire at some point. Say it holds a month's worth, or 3 rounds worth and dumps the older info to keep it short and sweet ?? Can anyone explain how many masternodes are kept int the voting pool from the reference node? It's a bit of a problem to have "fair chance" at being chosen as the masternode, while making it hard/impossible to know who will be next. Another thought occures to me that we could have several masternodes functioning per round. That would make it even harder to figure out what is going on. Of course, that would split the payments in more directions, increasing transactions and blockchain bloat. Or? Well, just giving away my brain farts to see if any of them smell good or trigger a brilliant thought in one of you brilliant people, LOL
I saw your question there but I have no answer for it. Yet. Here are some thoughts though... We've been discussing p2pool-like solutions ("a secondary, short blockchain", "it holds a month's worth, or 3 rounds worth and dumps the older info to keep it short and sweet") inside dev team some time ago but hadn't yet come to conclusion if it really suits us afaik. Problem with another blockchain - someone has to mine it. And hashrate there must be enough to be at least as secure as main chain. We can make it merge-mined with main or smth like that however but it means same miners will produce consensus for sharing their own block reward with masternodes. And there's something wrong with that model imo. Or we can make it POS-like but I'm not sure how exactly. Also Evan proposed another model some time ago - storing limited MN list changes in blockchain or smth like this if I remember correctly. The idea there was that we can make every node on the network to be aware of the exact same MN list at any given point of time by utilizing the same blockchain. I'm still not sure which approach is better however. I see no significant gain from "several masternodes functioning per round" other than making payments more even so people could sleep better for example for 4 MNs per block you'd get ~ 0.5 DASH almost every day at current MN count. Other than that.... I don't know. As for blockchain bloat - in that example with 4 MNs it means 5 outputs instead of 2 for "normal"-mined block and say 103 instead of 100 for p2pool-mined block (take this one for example http://explorer.dashninja.pl/tx/76ef1856f2c777c26adf95b90db9077bb4986d4079f150f38d67e510c4092f23 - 141(!) outputs). Not too much bloat imo.
I've implemented an acceptable compromise for both worlds and it's still KISS : when you configure Dash to create e.g. 3 backups it keeps now 3 backups per wallet-name, see https://github.com/dashpay/dash/pull/317
Thanks so much for taking the time to read ;P I'm sure it's all obvious to you guys, and that you will find an eloquent solution soon
Camosoul! These will be on the list for testing next (maybe tomorrow?): https://github.com/dashpay/dash/commit/40149c4e41114499c324abc313aea93a59bfa2f7 You will be on Testnet every day and every hour this time, right?
You know what would be really cool? if we hosted the read-only page for viewing the budget-related stuff on the Masternode network.... for better or worse I cut over a small site of mine onto an Apache server running on vultr over the weekend, and it works quite well. A distributed network of Apache servers sharing hosting duties could be pretty awesome. My 75 - 100 hits per day isn't even making my node break a sweat, just sayin'... ;-)
I tried using instantX on mainnet a few times today, and it never went through. Has it been inconsistent?
I have saying this for days, I did message Dev's about it. Things I noticed in the debug log, masternode B rank out of range, masternode spamming network and 34% are still on version 0.11.2.22, so am thinking this will get sorted on the next much anticipated release (or not, lol) MasternodePOS::mnse - MasternodeB ranking is too low ProcessMessageInstantX::txlreq - masternode is spamming transaction votes: CTxIn(COutPoint
