By then we hopefully will have reached a point at which hard-forking has become practically impossible. Look at bitcoin. The broader the user base gets and the more mainstream and "non-enthusiast" we go, the harder managing a hard-fork becomes.
well that's a little naive ;)
an outdated node can't know that the masternode it's talking to is "invalid" and the submitted block should be orphaned. This would basically make every update a hard fork.
Imo the most effective way of getting rid of classic pools would be a merge of p2pool (or...
Your PC's time shouldn't make a difference at all. What needs to match is your mobile's time and the validating server's time. The server's time is synced with internet time servers so you need to sync your device's clock with those.
As long as the difference doesn't exceed the lifetime of a...
Dude, that's just wrong. The codes are generated from the timestamp and your secret (the QR code) only. There's no way for it to block multiple devices.
When you enter the key on another device, it works. As long as the time is set accurately on a device, it will work once you entered the key...
They aren't payments of 0 tDRK. The amount shown represents your change in overall balance, which is 0 of course when you're paying yourself. No matter what the amount that's actually moved is.
Won't change anything. To those people every pop-up dialog looks like this
I really don't like the idea of facilitating laziness and ignorance. But for the sake of DRK it should be done :tongue:
Imho if your system is compromised, it doesn't make a difference if you unlock your wallet for hours or just a split second. Any malware that aims at stealing DRK will do so as soon as you entered the passphrase.
The scenario where an attacker gains access to your system in the very few hours...
done :grin: can't we just lift the 20kB tx size limit? It doesn't seem to matter if too large transactions are split up into smaller transactions or just raise the size limit.
while(amountToSend > 0){
txAmount = 0;
while((txSize < MAX_SIZE) && (txAmount < amountToSend)){
addInput()...
What's the big deal? The client can just split transactions > 5000 DRK into multiple transactions < 5000 DRK. Wouldn't even require any further interaction with the user.