Feathercoin 0.8.5
-
404 Page not found. :(
-
[quote]
Bushstar
Have you built another client like Litecoin to see if the QR codes are working there?
I just want to make sure that it is the client and not your computer. [/quote]Litecoin v0.8.5.1-8-gffd7439-beta
Linux (13.10) compiled versions from source -
Litecoin -Doesn’t have the option for QR codes, right click in receive coins.
whereas Feathercoin 0.6.4.4 QR code menu option is there on right click, but nothing happens.
-
Thanks for that Wrapper.
Wellenreiter and Lizhi I have added both of you again. Apologies Lizhi, I thought I had added you before.
The client compiles but is still broken by the changes to the key so is currently no good. The commit that broke compatibility is linked in below.
https://github.com/bitcoin/bitcoin/commit/dfa23b94c24aae6466152fccbe896ba5dc0e97b4
-
can you add me to the repository. user: groll
I will take a look but as usual my time is limited.
-
Hi Groll / Bush,
Re: Crowd development.
If you can think of any way I can help, test compiling, looking into some function / patch you need more info on / stuck on (history) or some such. Shout out.
-
groll, I have now added you to the repo. The commit that broke ACP and CAlert is as follows.
https://github.com/bitcoin/bitcoin/commit/dfa23b94c24aae6466152fccbe896ba5dc0e97b4
This made way for HD Wallets. We could simply reverse the commit but I would say that we make ACP and CAlert compatible with the changes to OpenSSL and include HD Wallets in this release.
Before the client downloads the block chain it appears fine.
[quote]feathercoind getinfo
{
“version” : 80500,
“protocolversion” : 60002,
“walletversion” : 60000,
“balance” : 31.61469999,
“blocks” : 111537,
“timeoffset” : 0,
“connections” : 0,
“proxy” : “”,
“difficulty” : 119.77041035,
“testnet” : false,
“keypoololdest” : 1381493269,
“keypoolsize” : 94,
“paytxfee” : 0.00000000,
“mininput” : 0.00010000,
“unlocked_until” : 0,
“errors” : “”
}[/quote]makekeypair appears to work.
[quote]feathercoind makekeypair
{
“PublicKey” : “04e4f418ea6c6ac443e98f3c7b5d2bd22ce8816288bf9c50e54e6142d4991
aa176329dcec83391f6c3c6feda62b79353ed656af35c56c3182221a0437c1fe8766f”,
“PrivateKey” : “5nvuGK5APZXj5jjZXtRpW5bSasPqLn6fYazQLbTxTo8EphB2kr6”
}[/quote]However when the blockchain starts downloading we get this assert error.
[quote]Assertion failed: mapBlockIndex.count(hashSyncCheckpoint), file checkpointsync.c
pp, line 223[/quote][quote name=“wrapper0feather” post=“34932” timestamp=“1384852938”]
Hi Groll / Bush,Re: Crowd development.
If you can think of any way I can help, test compiling, looking into some function / patch you need more info on / stuck on (history) or some such. Shout out.
[/quote]Thanks Wrapper. There should be a whole lot of testing soon. Right now the client compiles but crashes when the blockchain starts downloading with the following assert error. Be careful with this release as the wallets are not backwards compatible afterwards. Make sure you have a backup first.
-
Hierarchical Deterministic Wallets (11-2-2012)
https://en.bitcoin.it/wiki/BIP_0032
The Bitcoin reference client uses randomly generated keys. In order to avoid the necessity for a backup after every transaction, (by default) 100 keys are cached in a pool of reserve keys.
Deterministic wallets do not require such frequent backups, and elliptic curve mathematics permit schemes where one can calculate the public keys without revealing the private keys. This permits for example a webshop business to let its webserver generate fresh addresses (public key hashes) for each order or for each customer.
-
More background, Litecoin Devs talk of support for BIP32 and HD wallets. Oct 2013
https://forum.litecoin.net/index.php/topic,6466.msg50141.html#msg50141
-
[quote name=“Bushstar” post=“34947” timestamp=“1384863075”]
groll, I have now added you to the repo. The commit that broke ACP and CAlert is as follows.https://github.com/bitcoin/bitcoin/commit/dfa23b94c24aae6466152fccbe896ba5dc0e97b4
This made way for HD Wallets. We could simply reverse the commit but I would say that we make ACP and CAlert compatible with the changes to OpenSSL and include HD Wallets in this release.
Before the client downloads the block chain it appears fine.
[quote]feathercoind getinfo
{
“version” : 80500,
“protocolversion” : 60002,
“walletversion” : 60000,
“balance” : 31.61469999,
“blocks” : 111537,
“timeoffset” : 0,
“connections” : 0,
“proxy” : “”,
“difficulty” : 119.77041035,
“testnet” : false,
“keypoololdest” : 1381493269,
“keypoolsize” : 94,
“paytxfee” : 0.00000000,
“mininput” : 0.00010000,
“unlocked_until” : 0,
“errors” : “”
}[/quote]makekeypair appears to work.
[quote]feathercoind makekeypair
{
“PublicKey” : “04e4f418ea6c6ac443e98f3c7b5d2bd22ce8816288bf9c50e54e6142d4991
aa176329dcec83391f6c3c6feda62b79353ed656af35c56c3182221a0437c1fe8766f”,
“PrivateKey” : “5nvuGK5APZXj5jjZXtRpW5bSasPqLn6fYazQLbTxTo8EphB2kr6”
}[/quote]However when the blockchain starts downloading we get this assert error.
[quote]Assertion failed: mapBlockIndex.count(hashSyncCheckpoint), file checkpointsync.c
pp, line 223[/quote][quote author=wrapper0feather link=topic=4155.msg34932#msg34932 date=1384852938]
Hi Groll / Bush,Re: Crowd development.
If you can think of any way I can help, test compiling, looking into some function / patch you need more info on / stuck on (history) or some such. Shout out.
[/quote]Thanks Wrapper. There should be a whole lot of testing soon. Right now the client compiles but crashes when the blockchain starts downloading with the following assert error. Be careful with this release as the wallets are not backwards compatible afterwards. Make sure you have a backup first.
[/quote]This seems like an easy one to fix.
The line of code in question is:
[quote]
assert(mapBlockIndex.count(hashSyncCheckpoint));
[/quote]So stick a breakpoint on that line and examine your call stack. What’s calling it? What’s hashSyncCheckpoint value and where is it coming from? Put another breakpoint in mapBlockIndex.count (where is that defined?). What is the expected value? More details please!
Also, your header exclusion compiler macro name is funny: #ifndef PRIMECOIN_CHECKPOINTSYNC_H #define PRIMECOIN_CHECKPOINTSYNC_H
-
[quote name=“Kevlar” post=“35009” timestamp=“1384887430”]
This seems like an easy one to fix.The line of code in question is:
[quote]
assert(mapBlockIndex.count(hashSyncCheckpoint));
[/quote]So stick a breakpoint on that line and examine your call stack. What’s calling it? What’s hashSyncCheckpoint value and where is it coming from? Put another breakpoint in mapBlockIndex.count (where is that defined?). What is the expected value? More details please!
Also, your header exclusion compiler macro name is funny: #ifndef PRIMECOIN_CHECKPOINTSYNC_H #define PRIMECOIN_CHECKPOINTSYNC_H
[/quote][url=http://youtu.be/tlPQD04tn88]http://youtu.be/tlPQD04tn88[/url]
-
Tuck, that is so against the rules for the forum, but I think we need to keep it. It’s hilariously appropriate.
Kevlar - I am giving you a high-five across the huge land-mass between us.
-
I left PRIMECOIN_CHECKPOINTSYNC_H in there as the code for this is from Primecoin. I do not mind leaving references to Primecoin as a nod to Sunny lest we forget his contributions.
However you can have the honour of renaming it if you like?
Let’s debug.
The function CheckSyncCheckpoint that the assert is in is called from here…
[quote](gdb) info stack
#0 CheckSyncCheckpoint (hashBlock=@0x28f07c, pindexPrev=0x969f168)
at checkpointsync.cpp:223
#1 0x004442f4 in SetBestChain (state=@0x28fa50, pindexNew=0x969f088)
at main.cpp:1980
#2 0x004454fe in ConnectBestBlock (state=@0x28fa50) at main.cpp:1343
#3 0x0042335e in AppInit2 (threadGroup=@0x28fe18) at init.cpp:1068
#4 0x00425627 in AppInit (argc=1, argv=0x4862a40) at init.cpp:228
#5 0x004261a5 in main (argc=1, argv=0x4862a40) at init.cpp:260[/quote]mapBlockIndex is defined in main.cpp as follows.
[quote]map -
On Wrapper0feathers suggestion I have created a branch pre-ACP commit which will run. This can be used for testing the client whilst we look at the compatibility between Sunny’s code and 0.8.5.
https://github.com/FeatherCoin/Feathercoin-0.8.5/tree/master-0.8-pre-ACP
-
Complite 0.8.5 success. Run it ,Need to resynchronization transaction records. ;)
[attachment deleted by admin]
-
I have updated the checkpoint data on both 0.8.5 branches. The non-ACP branch will be deleted eventually but for now it allows us to test.
The data comes from the debug.log as shown below and allows us to enter the correct number of transactions since the last hard coded checkpoint. The number of transactions a day is just an estimated amount taken from our totals transactions and the number of days since launch.
[quote]received block 8c4e02f6c0d20e856fd7e952a147fee30ce145ca6932a284f354924362d2b408
SetBestChain: new best=8c4e02f6c0d20e856fd7e952a147fee30ce145ca6932a284f354924362d2b408 height=41300 log2_work=52.63077 tx=257285 date=2013-06-25 13:26:47 progress=0.036524
ProcessBlock: ACCEPTED[/quote]Commit is here.
https://github.com/FeatherCoin/Feathercoin-0.8.5/commit/1414528e1bf46d938cc4a7bf05f41c22ee43a797
-
[quote name=“Bushstar” post=“35126” timestamp=“1384942002”]
I left PRIMECOIN_CHECKPOINTSYNC_H in there as the code for this is from Primecoin. I do not mind leaving references to Primecoin as a nod to Sunny lest we forget his contributions.However you can have the honour of renaming it if you like?
Let’s debug.
The function CheckSyncCheckpoint that the assert is in is called from here…
[quote](gdb) info stack
#0 CheckSyncCheckpoint (hashBlock=@0x28f07c, pindexPrev=0x969f168)
at checkpointsync.cpp:223
#1 0x004442f4 in SetBestChain (state=@0x28fa50, pindexNew=0x969f088)
at main.cpp:1980
#2 0x004454fe in ConnectBestBlock (state=@0x28fa50) at main.cpp:1343
#3 0x0042335e in AppInit2 (threadGroup=@0x28fe18) at init.cpp:1068
#4 0x00425627 in AppInit (argc=1, argv=0x4862a40) at init.cpp:228
#5 0x004261a5 in main (argc=1, argv=0x4862a40) at init.cpp:260[/quote]mapBlockIndex is defined in main.cpp as follows.
[quote]map -
I’m looking at the commit (the one with more magic numbers… and in a mystery struct too. I don’t envy you your job right now. Thank god they’re commented?), did this fix the problem?
-
seems that the synccheckpoint was loaded from the DB in DB.cpp and initialised at load of block chain via ReadSyncCheckpoint. this code is relovatd in main.cpp in 0.8.5 but seems to not load the checkpoint so the checkpoint is not initilised and stay at 0
[quote]
Feathercoin version v0.6.4.4 (Sep 21 2013, 08:46:22)
Startup time: 11/21/13 02:33:20
Default data directory C:\Users\…\AppData\Roaming\Feathercoin
Used data directory C:\Users\…\AppData\Roaming\Feathercoin
Bound to [::]:9336
Bound to 0.0.0.0:9336
[b]Loading block index…[/b]
dbenv.open LogDir=C:\Users\…\AppData\Roaming\Feathercoin\database ErrorFile=C:\Users\…\AppData\Roaming\Feathercoin\db.log
LoadBlockIndex(): hashBestChain=c479e1f97c80d2d83a46 height=110649 date=11/09/13 02:41:38
[b]LoadBlockIndexDB(): synchronized checkpoint 42bb31183d1437566b7cedfa0f120d616975f2b4462372af681859cf77528516[/b]
Verifying last 2500 blocks at level 1[/quote]from new main.ccp you should have one of the message
[code]// ppcoin: load hashSyncCheckpoint
if (!pblocktree->ReadSyncCheckpoint(hashSyncCheckpoint))
printf(“LoadBlockIndexDB(): synchronized checkpoint not read\n”);
else
printf(“LoadBlockIndexDB(): synchronized checkpoint %s\n”, hashSyncCheckpoint.ToString().c_str());[/code]
my guess is that the DB upgrade have not move the syncCheckpoint to the new DB so the load fail.
if DB has no checkpoint save should we just initialise with genesis block (as it’s the only block on initial load)? -
I learnt more about the code in the last 5 mins than the last month. A+++++++
P.S. I am setting up a VirtualBox to compile and test 0.8.5, as I have no spare hardware. Could be useful to separate 0.8.5 wallet tests. I’ll post a guide, if it works.
-
Feathercoin 0.8.5 now runs with CAlert and ACP from Sunny. The latest commit was to get our figures in line for the transactions-based verification progress by sipa which is linked in below. It seems that not having the correct figures here breaks Sunny’s ACP.
https://github.com/bitcoin/bitcoin/commit/9f2467ad6241ce6cf0897ed30c676598d59441a7
I have tested 0.8.5 on a 0.6.4.4 datadir and from fresh both appear to work.
Can others please verify that the latest 0.8.5 now works?
The next obvious bug to test is the crash on exit. I’ll catch this and get some data.
