the first block pruning release was working great for me, i am now using the second release but i am not able to get "Ready for committal" and in my debug.log i see lots of:
2014-06-21 14:50:48 ERROR: AcceptToMemoryPool: : transaction already exists
2014-06-21 14:50:50 connect() to 66.45.239.67:18253 failed after select(): Connection refused
Topic: [TEST RELEASE] Cryptonite binary for linux (NEW: Qt and Windows builds) - page 16. (Read 19296 times)
June 21, 2014, 09:52:10 AM
June 21, 2014, 09:48:05 AM
Tough week truthfully but the mrs had work shit to do last night so it was just going to be a romantic evening with the computer and myself... and the recently ported Civ V for linux... So of course this shit breaks on me right from the start.
sorry to hear about your week, i will have to check out the Civ V port.
June 21, 2014, 07:14:57 AM
Tough week truthfully but the mrs had work shit to do last night so it was just going to be a romantic evening with the computer and myself... and the recently ported Civ V for linux... So of course this shit breaks on me right from the start.
June 20, 2014, 11:48:32 PM
looking to break shit tonight
mhBpjn7iknihVoktgBkBERgPo9s5rXcKnD
[edit] is the testnet down? Not getting any connections
ok, keeps crashing on me while trying to synch
Three crashes, each the same error
log :: http://pastebin.com/tXEBxA1F
mhBpjn7iknihVoktgBkBERgPo9s5rXcKnD
[edit] is the testnet down? Not getting any connections
ok, keeps crashing on me while trying to synch
Code:
2014-06-21 00:34:31 AddToWallet a3199904ac62e9490511a5b31d023ceda9dcb545ddc9cf226167159db5fe0a58
2014-06-21 00:34:31 ERROR: CheckTransaction() : vin empty
2014-06-21 00:34:31 ERROR: AcceptToMemoryPool: : CheckTransaction failed
2014-06-21 00:34:31 UpdateTip()
Three crashes, each the same error
log :: http://pastebin.com/tXEBxA1F
Tough day billo? Guess breaking this is better then kicking the dog
June 20, 2014, 07:52:22 PM
looking to break shit tonight
Well you are doing a good job. I am writing code as fast as I can but can't keep it running.
edit: seems the disappearing blocks happen when a block gets orphaned. not quite sure if it's fixed but 7fdf8b6164131867ae46e227a1ba9441 is better.
June 20, 2014, 06:54:57 PM
looking to break shit tonight
mhBpjn7iknihVoktgBkBERgPo9s5rXcKnD
[edit] is the testnet down? Not getting any connections
ok, keeps crashing on me while trying to synch
Three crashes, each the same error
log :: http://pastebin.com/tXEBxA1F
mhBpjn7iknihVoktgBkBERgPo9s5rXcKnD
[edit] is the testnet down? Not getting any connections
ok, keeps crashing on me while trying to synch
Code:
2014-06-21 00:34:31 AddToWallet a3199904ac62e9490511a5b31d023ceda9dcb545ddc9cf226167159db5fe0a58
2014-06-21 00:34:31 ERROR: CheckTransaction() : vin empty
2014-06-21 00:34:31 ERROR: AcceptToMemoryPool: : CheckTransaction failed
2014-06-21 00:34:31 UpdateTip()
Three crashes, each the same error
log :: http://pastebin.com/tXEBxA1F
June 20, 2014, 03:41:27 PM
spam accepted here" n1V6XHG5RTwDaw1KymRjxYvsFM93Jbgjq2
June 20, 2014, 03:30:02 PM
Big news here. Latest release implements block pruning according to MBC scheme. So when you sync the new client it will be retrieving all of the block headers but only the contents of last 1k blocks. This version prints a lot of spam to the console. The driving force behind leaving the spam on for now is that the sync process is kind of involved and stuff like getinfo doesn't make any sense. It's really hard to tell if anything is going on until suddenly it is online. Getinfo also won't respond for a long period of time while the code is checking the downloaded data for consistency. So the spam kind of lets you know it is still working until we come up with improved UI. You can tell it's done syncing when the last line says "Ready for committal"
Restart after killing the client is also much slower now because of increased consistency checking. Again the spam will let you know what is going on.
As usual, expect lots of bugs. Performance enhancements are coming soon.
Mrvegad I am not confident in a fix for disappearing blocks yet. This could get especially interesting since all the blocks don't even exist anymore. I'm looking into it though. Complete rewrite of some temperamental code is on the short list.
Billotronic, yes you have to start with -testnet
http://gpile.it/files/cryptonited MD5 a3398cf9f07ec28705d08081a4dab210
Restart after killing the client is also much slower now because of increased consistency checking. Again the spam will let you know what is going on.
As usual, expect lots of bugs. Performance enhancements are coming soon.
Mrvegad I am not confident in a fix for disappearing blocks yet. This could get especially interesting since all the blocks don't even exist anymore. I'm looking into it though. Complete rewrite of some temperamental code is on the short list.
Billotronic, yes you have to start with -testnet
http://gpile.it/files/cryptonited MD5 a3398cf9f07ec28705d08081a4dab210
nice! can't wait to
June 20, 2014, 03:23:23 PM
lol,i shoot sticky on my display to remind me.
gross
June 20, 2014, 11:10:50 AM
lol i put a sticky note on my display to remind me.
June 20, 2014, 10:35:50 AM
Big news here. Latest release implements block pruning according to MBC scheme. So when you sync the new client it will be retrieving all of the block headers but only the contents of last 1k blocks. This version prints a lot of spam to the console. The driving force behind leaving the spam on for now is that the sync process is kind of involved and stuff like getinfo doesn't make any sense. It's really hard to tell if anything is going on until suddenly it is online. Getinfo also won't respond for a long period of time while the code is checking the downloaded data for consistency. So the spam kind of lets you know it is still working until we come up with improved UI. You can tell it's done syncing when the last line says "Ready for committal"
Restart after killing the client is also much slower now because of increased consistency checking. Again the spam will let you know what is going on.
As usual, expect lots of bugs. Performance enhancements are coming soon.
Mrvegad I am not confident in a fix for disappearing blocks yet. This could get especially interesting since all the blocks don't even exist anymore. I'm looking into it though. Complete rewrite of some temperamental code is on the short list.
Billotronic, yes you have to start with -testnet
http://gpile.it/files/cryptonited MD5 a3398cf9f07ec28705d08081a4dab210
Restart after killing the client is also much slower now because of increased consistency checking. Again the spam will let you know what is going on.
As usual, expect lots of bugs. Performance enhancements are coming soon.
Mrvegad I am not confident in a fix for disappearing blocks yet. This could get especially interesting since all the blocks don't even exist anymore. I'm looking into it though. Complete rewrite of some temperamental code is on the short list.
Billotronic, yes you have to start with -testnet
http://gpile.it/files/cryptonited MD5 a3398cf9f07ec28705d08081a4dab210
June 18, 2014, 11:52:40 PM
Edit: I restarted and let it run without mining, worked. Started up mining and let it run for a bit and had no problems. Not sure what to make of it.
Well I have no idea what is causing the issue because no one else seems to be having the same problem. We have to recode a lot of the syncing code anyway when we implement blockchain trimming, if the problem is still persisting after we do that then we'll pay more attention to it, but for now we have to focus on other things. June 18, 2014, 10:36:14 PM
Congrats on the test release! I am glad you finally found some developers and made this a reality! Props to you putting up the bounty.
Block chain bloat could prove troublesome to Cryptocoins, and even more so for coins that have quicker block speeds.. those blocks will add up over time. Also more and more features are being built on top of coins, and in new coins as well, which will bloat them even more. Due to the network effect transaction rates will go up in a parabolic arc, so I'm not sure everyone understands how big of a problem block chain bloat could be in the future if Cryptocoins are widely adopted.
Block chain bloat could prove troublesome to Cryptocoins, and even more so for coins that have quicker block speeds.. those blocks will add up over time. Also more and more features are being built on top of coins, and in new coins as well, which will bloat them even more. Due to the network effect transaction rates will go up in a parabolic arc, so I'm not sure everyone understands how big of a problem block chain bloat could be in the future if Cryptocoins are widely adopted.
June 18, 2014, 10:30:39 PM
Ok so I started with a clean db,wallet let it sink up then started to mine, within minutes of mining my blockcount started going down, i wasn't sending out txs and i didn't time my computer time.
Edit: I restarted and let it run without mining, worked. Started up mining and let it run for a bit and had no problems. Not sure what to make of it.
Edit: I restarted and let it run without mining, worked. Started up mining and let it run for a bit and had no problems. Not sure what to make of it.
June 18, 2014, 09:41:11 PM
Well I never claimed to be smart or not forgetful...
but you are sexy
June 18, 2014, 09:36:17 PM
Well I never claimed to be smart or not forgetful...
June 18, 2014, 09:35:24 PM
@Billotronic
Perhaps could it be that you are not running the daemon with -testnet again?
@Mrvegad
Not good. Any more info, logs maybe? Current theory is that if you get a crash at the right time, a good block can be marked invalid and saved to the database. Once this happens it starts going down the chain realizing there is no path to the current tip without hitting the bad block. So mostly I think we want to fix the original crash and not so much worry about the block deleting that happens later.
Perhaps could it be that you are not running the daemon with -testnet again?
@Mrvegad
Not good. Any more info, logs maybe? Current theory is that if you get a crash at the right time, a good block can be marked invalid and saved to the database. Once this happens it starts going down the chain realizing there is no path to the current tip without hitting the bad block. So mostly I think we want to fix the original crash and not so much worry about the block deleting that happens later.
oh fuck me thats embarrassing.
June 18, 2014, 09:33:50 PM
https://mega.co.nz/#!UoFmURBC!5S_t0__2Pf8KjgVtYvuOB8I_9u_iN6n0WkON5NZunoQ
https://mega.co.nz/#!xxt2GJSb!0caIsYbDM5ekXhCw5_3y9vPnitAbM1EDoo_4qdR0Kf8
Don't think it has nothing to do with me playing around with my computer time?
https://mega.co.nz/#!xxt2GJSb!0caIsYbDM5ekXhCw5_3y9vPnitAbM1EDoo_4qdR0Kf8
Don't think it has nothing to do with me playing around with my computer time?
June 18, 2014, 09:28:37 PM
@Billotronic
Perhaps could it be that you are not running the daemon with -testnet again?
@Mrvegad
Not good. Any more info, logs maybe? Current theory is that if you get a crash at the right time, a good block can be marked invalid and saved to the database. Once this happens it starts going down the chain realizing there is no path to the current tip without hitting the bad block. So mostly I think we want to fix the original crash and not so much worry about the block deleting that happens later.
Perhaps could it be that you are not running the daemon with -testnet again?
@Mrvegad
Not good. Any more info, logs maybe? Current theory is that if you get a crash at the right time, a good block can be marked invalid and saved to the database. Once this happens it starts going down the chain realizing there is no path to the current tip without hitting the bad block. So mostly I think we want to fix the original crash and not so much worry about the block deleting that happens later.
oh fuck me thats embarrassing.
June 18, 2014, 09:20:07 PM
@Billotronic
Perhaps could it be that you are not running the daemon with -testnet again?
@Mrvegad
Not good. Any more info, logs maybe? Current theory is that if you get a crash at the right time, a good block can be marked invalid and saved to the database. Once this happens it starts going down the chain realizing there is no path to the current tip without hitting the bad block. So mostly I think we want to fix the original crash and not so much worry about the block deleting that happens later.
Hang on I will upload log Perhaps could it be that you are not running the daemon with -testnet again?
@Mrvegad
Not good. Any more info, logs maybe? Current theory is that if you get a crash at the right time, a good block can be marked invalid and saved to the database. Once this happens it starts going down the chain realizing there is no path to the current tip without hitting the bad block. So mostly I think we want to fix the original crash and not so much worry about the block deleting that happens later.
Jump to: