Importprivkey from p2p mining. Laggy GUI now.

MrMime

MrMime

Active member
Foundation Member
So recently, I imported some saved private keys that I had when I was P2P mining into my main wallet. Since then, my GUI now lags pretty bad, and denominations are too small to be auto denominated (hundreds of ~.1 drk transactions). It takes minutes to change to send tab, and often 20 minutes to download an hour worth of blockchain.

I was wondering if there was anyway from console I can remove that address and revert it back to normal? I tried sending those inputs to a different address, but transaction file was sadly too big.

Would prefer if I could keep the ~33 dark or so from p2p mining in my main wallet, but if I can do something like dump the private keys and remove them from wallet, than that would be preferred also as wallet is essentially unusable.

Attempting to send all of the inputs to a new address ends up creating a ~182KB transaction that is too large to send. Trying to find the max cutoff size transaction.
 
Last edited by a moderator:
If you have an older wallet.dat file preimport, the new address won't be in there to my knowledge. Darkcoind over the qt client is generally needed for times when you have tons of micropayments and dusts in order to send to a new address without lag. Your best bet would be to either try an older backup file for the time being and then use darkcoind to send all the micropayments in chunks to a fresh address. Unfortunately, I've never attempted such a large tx before so I do not know the cutoff limit size-wise. I was also under the impression that even if you did large tx's, you ended up paying for it in a larger tx fee to do so unless broken up.
 
Thanks for your help oblox and crowning. I might have to use darkcoind, or just wait the ~20 minutes to toggle through the menu and send. Unfortunately the cut-off size is around 5kb per transaction, and that only counts for about 3% of my total inputs to that address. I would happily pay the .182 DRK fee if it'd let me send a transaction the size that I am asking, but oh well. Thanks guys!
 
Actually, It looks like 5kb is not a limit for transaction - it's a limit for "free" transaction (wallet will calculate some fee anyway). An the real limit is 100kb.
For tx larger than 5kb you have to explicitly set fee in options - minimal fee is 0.001 per kb BUT I would highly recommend to set higher fee (maybe even 0.1) or you could end up waiting to be included in block for a really long time (if you will ever get there).
Uuw9y9J.png

O9xHXdI.png


http://test.explorer.darkcoin.fr/tx/673fda130289bc176479dfc9bc7d60fdf3b16e487cd5882100e34eb904d6073f
37 DRK, 1.8 DRK fee, 18Kb

While testing this I made another 2 large transactions with different priority. This ^^^ one is "medium" and 2 previous was "low" and "low-medium". It's been an hour since I sent them and they are still not included in block. So if you want to give it a try make sure you have transaction of quite high priority.
 
UdjinM6 Thanks for pointing out that 5KB was only for 'free transactions'. I did indeed have my default tx fee at .001, and assumed the extra fee tacked on would cover however many inputs I'd send through. Unfortunately, all these inputs are pretty low priority. Anyway to manually change this per address?
 
MrMime said:
UdjinM6 Thanks for pointing out that 5KB was only for 'free transactions'. I did indeed have my default tx fee at .001, and assumed the extra fee tacked on would cover however many inputs I'd send through. Unfortunately, all these inputs are pretty low priority. Anyway to manually change this per address?
Click to expand...
You said that you imported private keys to some wallet. Do you have any other input with at least medium priority here? If you do try to include them too. And please try with small amounts first ;)

EDIT: Btw, how many inputs ("Quantity" when you "select all") are shown in your coin control?
 
I see, I'll try combining inputs from my different addresses.

For the address in question I have 1010 inputs, next highest has ~10, and most others have only 1.
 
MrMime said:
I see, I'll try combining inputs from my different addresses.

For the address in question I have 1010 inputs, next highest has ~10, and most others have only 1.
Click to expand...

Interesting... Because while testing qt I had 1000+ inputs too and it worked quite good, just a small almost unnoticeable lag... and the one that I sent dust from was really slow...

Btw, you can try to speed things up. First of all, as always, backup your wallet.dat. Then run qt (or daemon, it daesn't matter) with -zapwallettxes parameter. It will take some time and will look like it hangs but at the end it should clean wallet from "old" transactions and rescan.

EDIT: it should work fine but just in case - make sure your balance match after you done this.
 
Yeah, I've tried clearing out darkcoin folder, and letting it redownload the chain and once it gets to the point where those small inputs start being fed into wallet, it lags to all hell. It's weird. I will definitely try that parameter, thank you!
 
MrMime said:
Yeah, I've tried clearing out darkcoin folder, and letting it redownload the chain and once it gets to the point where those small inputs start being fed into wallet, it lags to all hell. It's weird. I will definitely try that parameter, thank you!
Click to expand...
That's an interesting info... Will try that on testnet too. Thanks :smile:
 
MrMime said:
Yeah, I've tried clearing out darkcoin folder, and letting it redownload the chain and once it gets to the point where those small inputs start being fed into wallet, it lags to all hell. It's weird. I will definitely try that parameter, thank you!
Click to expand...


UdjinM6 said:
That's an interesting info... Will try that on testnet too. Thanks :smile:
Click to expand...

I can confirm this: download is fast till the point were the micro payments from p2p mining come in. I can provide you with the privkey from that address if you like to test it.
 
UdjinM6 Tried using that parameter, and flash screen hung a bit while it was scanning, but no apparent change in speed of blockchain synching.
 
MrMime said:
UdjinM6 Tried using that parameter, and flash screen hung a bit while it was scanning, but no apparent change in speed of blockchain synching.
Click to expand...
hmm.. ok... but did it help to speed up GUI? (you said you waited minutes to change tab)
 
Ok... thanks for the info... sadly I have no more idea how to fix it yet :sad:
 
MrMime said:
Hey np. Thanks a bunch for your assistance so far! =) <3
Click to expand...

Hey Mime, ran into the same issue myself had an address with about 2600 tx's. Eventually I had to use the daemon and not QT to move the funds to a new wallet.

I tried UdjinM6's suggestion on a bloated wallet and it didn't improve QT's responsiveness at all. Funny thing because that should be the issue of the bloat. (all the tx's)
When running the above command, tx's all cleared out, it should be back to fully functional again.

Bash: 
./darkcoind --zapwallettxes=2

It seems that the above flag "zapwallettxs" doesn't delete every single tx.

After doing zap wallet, I'm still showing 2647 transactions.
Bash: 
$ ./darkcoind listtransactions "*" 100000 | grep -c "txid"
2647

QT is still not possible to use.

Also the size of the original wallet and 'zapped' wallet are the same of 29Mb's. Zap doesn't do the trick.
 
Last edited by a moderator:
Propulsion you misspelled zapwallettxes :wink:
Code: 
  -zapwallettxes=<mode>  Delete all wallet transactions and only recover those parts of the blockchain through -rescan on startup
                         (default: 1, 1 = keep tx meta data e.g. account owner and payment request information, 2 = drop tx meta data)
 
UdjinM6 said:
Propulsion you misspelled zapwallettxes :wink:
Code: 
  -zapwallettxes=<mode>  Delete all wallet transactions and only recover those parts of the blockchain through -rescan on startup
                         (default: 1, 1 = keep tx meta data e.g. account owner and payment request information, 2 = drop tx meta data)
Click to expand...
I'd shake your hand if I could; fixed!
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top