Feathercoin 0.8.5 Client
-
Wrapper, have you been able to recreate the blockchain DB corruption?
What kind of error message did you get on launch? This may be a well documented quirk :)
Wellenreiter, I have seen your fix for Debian on GitHub and will give it a spin tomorrow.
-
simply added a close button to the qrcode window. beneficial for all versions I think ;)
-
[quote name=“Bushstar” post=“43526” timestamp=“1386873903”]
Wrapper, have you been able to recreate the blockchain DB corruption?What kind of error message did you get on launch? This may be a well documented quirk :)
[/quote]Still got 0.8.5 upgrade / restore back up -receive fields description mismatch.
I’ve reproduced some upgraded wallets and also cut down Debug.log file for the upgrade period.
I’ve checked but not seen any similar fault, too busy could be wrong. Let me know if Maintenance Task identified…
Is it because mining had no Address label? so the all addresse field content dropped down one? In my case address Bit-messa**** being first in the index. Which is why it is the new mining label?
I’ll look at data structures and get back.
-
I can’t find why my receive address got mismatched after update, yet. We need a workaround whatever. May be a coincidence but got this in Debug.log.
AddToWallet 261d5a88ba8a9b56c3b85fae9c42f2301c942e4c649117df414fe234b63984c2
AddToWallet 390a6f0d0abd8cba8218af790047833576a23363ae1bc6c11856970f7ac8834a
ERROR: bool CBlock::ReadFromDisk(const CDiskBlockPos&)() : deserialize or I/O error
ERROR: bool CBlock::ReadFromDisk(const CDiskBlockPos&)() : deserialize or I/O error
ERROR: bool CBlock::ReadFromDisk(const CDiskBlockPos&)() : deserialize or I/O error
-rescanSee below my mining has a “bit-message label”. the 6i1BPX is my mining receive.
Field description mismatch. I only just updated my real system, so that should be clean of tests.
This is the line in main.cpp that adds the receive address to the wallet on a rescan.
>>>>>
// make sure all wallets know about the given transaction, in the given block
void SyncWithWallets(const uint256 &hash, const CTransaction& tx, const CBlock* pblock, bool fUpdate)
{
BOOST_FOREACH(CWallet* pwallet, setpwalletRegistered)
pwallet->AddToWalletIfInvolvingMe(hash, tx, pblock, fUpdate);[attachment deleted by admin]
-
With the change up to 0.8.5 is there a possibility for distributing a block chain bootstrap? The one thing I kept hearing from folks that I’ve turned on to feathercoin is that it takes so long for the initial sync. From my view it only makes sense to streamline the process given the client upgrade from 0.6.x to 0.8.x means bootstrap.dat support is built in.
As it stands now I’ve started handing out thumb drives which contain the installer, a batch file, and my relatively up-to-date block chain with index, blk0001.dat and blkindex.dat, as a zip file. The user runs the batch file and if the block chain isn’t found in the users data directory, it’s extracted from the zip file, and finally the installer is run. While this works fine it is somewhat archaic in nature. Given the updated client supports bootstrapping is there a plan to release an official bootstrap so I can simply say download this and this and enjoy?
-
The easiest way I’ve found to update someone’s blockchain over the local LAN.
To do that go to help debug, then use addnode onetry to add another PC with wallet that is on the network, the wallet sync then happens automatically.
You can check you got the link, getpeerinfo to display the connected peers.
Also, the initial sync problem you describe is not unique to Feathercoin, it effects all flavours of p2peer coins.
-
[quote name=“Nexistenz” post=“43869” timestamp=“1386958039”]
With the change up to 0.8.5 is there a possibility for distributing a block chain bootstrap? The one thing I kept hearing from folks that I’ve turned on to feathercoin is that it takes so long for the initial sync. From my view it only makes sense to streamline the process given the client upgrade from 0.6.x to 0.8.x means bootstrap.dat support is built in.As it stands now I’ve started handing out thumb drives which contain the installer, a batch file, and my relatively up-to-date block chain with index, blk0001.dat and blkindex.dat, as a zip file. The user runs the batch file and if the block chain isn’t found in the users data directory, it’s extracted from the zip file, and finally the installer is run. While this works fine it is somewhat archaic in nature. Given the updated client supports bootstrapping is there a plan to release an official bootstrap so I can simply say download this and this and enjoy?
[/quote]I’m so glad you’re asking, since we need someone to volunteer for this.
Please, take that zip, add a nice README.txt explaining what it is, add it to uTorrent, seed it, and post the magnet link here. You’ll be doing everyone a great service.
-
I agree with kevlar …
Going off topic on my 0.8.5 Upgrade database bug tho’ Any thoughts 3 back…
-
[quote name=“Kevlar” post=“43883” timestamp=“1386960685”]
I’m so glad you’re asking, since we need someone to volunteer for this.Please, take that zip, add a nice README.txt explaining what it is, add it to uTorrent, seed it, and post the magnet link here. You’ll be doing everyone a great service.
[/quote]
I’d be more than willing to, but with the crap internet I’ve got,1Mb/254Kb service, there’s no way I could seed it properly. I wouldn’t be adverse to throwing it up somewhere if someone else would like to seed it though, but since it’s literally two files zipped, not the block chain serialized, pretty much anyone could do it. As it stands I just [url=http://hastebin.com/weyidilumo.dos]threw up[/url] the script that’s included on the thumb drive with instructions on how to use it yourself when making thumb drives to give out. -
I’ve found a bug in upgrading some clients. I haven’t found the cause.
It happens on Kubuntu 13.10 with a standard [guide] Virtualbox Linux compile and my PC, upgrade 0.6.4.4 or import a 0.6.4.4. backup.
My Wallet receive address and database field labels got mismatched after upgrade. 6i1B~ is my mining address and the label was blank before the upgrade, now say Bit-message the wrong label (See image 2.)
This is how it used to look - Mining n/a
(see image 3.)I couldn’t easily find a .DAT file generic viewer to see why there might be a field match…
When testing previous Beta versions of 0.8.5 I got the field mismatch but mined coins showed up, ok.
Notes
I didn’t compile it as Qt5 (see image 1)Both databases were Berkelay5.1
[attachment deleted by admin]
-
Wrapper, is that 64bit or 32bit Kubuntu?
So you get the same problem if you create a new 0.6.4.4 wallet to import?
I’m wondering if you get the same problem if you create a new wallet, import your private keys and then import that to 0.8.5. Perhaps your .dat file is unhappy.
I will setup a VM and try to recreate the problem, let me know if it is 32 or 64 bit.
-
[quote name=“Bushstar” post=“44175” timestamp=“1387011581”]
Wrapper, is that 64bit or 32bit Kubuntu?
So you get the same problem if you create a new 0.6.4.4 wallet to import?
I’m wondering if you get the same problem if you create a new wallet, import your private keys and then import that to 0.8.5. Perhaps your .dat file is unhappy.
I will setup a VM and try to recreate the problem, let me know if it is 32 or 64 bit.
[/quote]It is 64bit. I don’t have my 0.6.4.4 wallet as I thought my backups were the same and just upgraded it. I was doing a Virtualbox compile first, which was slow, so I just went ahead. Then the same happened in the VirtualBox test .
Previously, I think I was testing new installs not upgrades, done a lot, exact detail hazy.
I can reproduce small databases from my initial FTC wallet backup then send that to you, should make mode of failure obvious?. +Test Upgrade works on very old wallet backups?
Sorry for delay, just found “notify me of relpies” in “Attachments and other options”
-
[quote name=“wrapper0feather” post=“44051” timestamp=“1386985708”]
I’ve found a bug in upgrading some clients. I haven’t found the cause.It happens on Kubuntu 13.10 with a standard [guide] Virtualbox Linux compile and my PC, upgrade 0.6.4.4 or import a 0.6.4.4. backup.
[/quote]So, I installed VirtualBox on my Arch system and loaded up an install of Kubuntu 13.10, upgraded all the packages, and downloaded FTC-qt sources from git so I could try to recreate this issue. I’ve started to download all the dependencies, but I see that libdb4.8-dev and libdb4.8+±dev have no packages available on a default Kubuntu… could that be why you are getting db errors??
*EDIT*
Nevermind, I see libdb5.1+±dev has an install candidate. I’ll try with that, since you said you were using Bdb 5 anyway :) -
Brilliant, I’m going mad here thinking its just me. I’ve duplicated it many times but need a database viewer to see why the fields are out of sync, we can analyse my files if any one can suggest the tools I need…
P.S it still remotely be a glitch with keys, an extra key from a failed bare (test) install, might be knocking it (restored backup) out of sync…?? just my only last idea, it shouldn’t be, I tried to avoid doing that as I identified as something to specifically test, later.
Bare install then upgrade my “real install,” I just updated the client the first wallet it saw was my old wallet, so that should rule that out though…
Most of my tests, were in clones of a fresh install virtual box, 0.8.5 which the source and Qt folders were deleted, i.e: clone from github and recompile in Qt-creator. I did both for the upgrade test, straight to old wallet, replace bare install, with old wallet.
VirtualBox - Kubuntu 13.10 Feathercoin0.8.5Beta - Test compile guide.
[url=http://forum.feathercoin.com/index.php/topic,4566.0.html]http://forum.feathercoin.com/index.php/topic,4566.0.html[/url] -
Well, this experiment has shown at least two deps in the qt readme file need to be updated :)
the libdb5.1+±dev needs to replace libdb4.8+±dev on modern Ubuntu installs, and the dependency libminiupnpc-dev needs to be added if one is to compile it themselves. -
Yes, I was just going through that (cross checking the readme), then support and new members went mad.
I’m sure I researched the data base issue, It should be ok to be 5.1, you just couldn’t go back? to 4.8.
I haven’t been able to test the extracting keys, as I’ve never done that yet, more work…
-
Well, I can’t reproduce your situation, because everything went perfectly for my test.
I did use a 32bit install of Kubuntu 13.10 on VirtualBox, however, and I did not try cloning the vdi as you did. I just built 0.6.4.4 from the git repo with QT Creator using DB 5.1 as we discussed, downloaded the blockchain (took forever!), and sent a few transactions from and to my main wallet. Then I downloaded the 0.8.5 from git and built that with QT Creator as well. The DB reindex just finished and I see the correct labels on the two transactions made.
I dunno? -
[quote name=“wrapper0feather” post=“44442” timestamp=“1387061633”]
Yes, I was just going through that (cross checking the readme), then support and new members went mad.I’m sure I researched the data base issue, It should be ok to be 5.1, you just couldn’t go back? to 4.8.
I haven’t been able to test the extracting keys, as I’ve never done that yet, more work…
[/quote]
I’ve extracted the private keys from my 0.8.5.0 Wallet and imported on another VM without problems.
Didn’t try to export on 0.6.4.4 and import on 0.8.5.0 -
[quote name=“Wellenreiter” post=“44521” timestamp=“1387094490”]
[quote author=wrapper0feather link=topic=4885.msg44442#msg44442 date=1387061633]
Yes, I was just going through that (cross checking the readme), then support and new members went mad.I’m sure I researched the data base issue, It should be ok to be 5.1, you just couldn’t go back? to 4.8.
I haven’t been able to test the extracting keys, as I’ve never done that yet, more work…
[/quote]
I’ve extracted the private keys from my 0.8.5.0 Wallet and imported on another VM without problems.
Didn’t try to export on 0.6.4.4 and import on 0.8.5.0
[/quote]That’s good news. If we never have to get out that python hank and I wrote to convert broken WIF keys again to make importing work, it’ll be too soon.
-
Wrapper, I am unable to recreate the problem on Kubuntu. I tested a heavily used 0.6.4.4 wallet and dropped it into the Feathercoin datadir and ran 0.8.5. Everything has come across without error.
I am wondering if your wallet.dat is corrupt.
Let’s do “wallet surgery”. We will dump your private keys and import them back into a 0.6.4.4 wallet to try the test over again.
Go to the console in the Qt client and do the following.
If you’ve encrypted your wallet you’ll need to unlock it
[b]walletpassphrase [passphrase] 1000[/b]
Then enter in dumpprivkey and your public address. This will generate the private key for your public key, make a note of this key.
[b]dumpprivkey [feathercoin address][/b]
Once you have all the private keys exported close the client down, backup and remove your wallet.dat from the Feathercoin datadir. Run the program to generate a new wallet.dat and then run the following to import your private keys.
[b]importprivkey [feathercoin private key][/b]
The client will freeze a little while it rescans the blockchain. Once all keys have been imported you will have a brand new shiny wallet.dat file ready to import to 0.8.5. I hope it works this time round :)
