Topic: [ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer! - page 26. (Read 284948 times)
September 07, 2014, 04:58:18 PM
Lately, something 'bigger' has come along and have decided to lower my activity on Slimcoin. I will do compilations and releases, maintain the master seed node for synchronized checkpointing, and review pull requests on github. Apart from that, I only plan on doing small tweaks here and there if necessary. I am not abandoning Slimcoin, I am merely giving the majority of the development up to the community. That does not mean I am gone, I may return to more development here depending on how the future goes.
September 07, 2014, 12:36:24 PM
Last commits by Slimcoin on Github see:
https://github.com/slimcoin/slimcoin/tree/master/src
init.cpp Added excess orphan block pruning 20 days ago
main.cpp Added excess orphan block pruning 20 days ago
main.h Added excess orphan block pruning 20 days ago
Should mostly 'fix' the windows memory exception error.
EDIT: https://github.com/slimcoin/slimcoin/commit/afd8ef7e18e17f876f0bc7b44e79ee867f0b3ac1
https://github.com/slimcoin/slimcoin/tree/master/src
init.cpp Added excess orphan block pruning 20 days ago
main.cpp Added excess orphan block pruning 20 days ago
main.h Added excess orphan block pruning 20 days ago
Should mostly 'fix' the windows memory exception error.
EDIT: https://github.com/slimcoin/slimcoin/commit/afd8ef7e18e17f876f0bc7b44e79ee867f0b3ac1
September 07, 2014, 12:23:39 PM
Any ideas how to fix this? It's driving me crazy to see all my burned coins degrading and I can't keep the wallet open for more than a few minutes at a time. I've tried deleting everything but wallet.dat and letting the blockchain reload, but it doesn't help.
See:
As for the bad alloc exception, I looked around and found an explanation that is probably the solution:
From https://github.com/bitcoin/bitcoin/issues/2353
How much memory does your system have?
I could implement the second option, but will look into how bitcoin fixed this issue.
Also, if you have any other exceptions, please post them.
From https://github.com/bitcoin/bitcoin/issues/2353
Quote
This is how bitcoin runs out of memory (virtual address space) while downloading blocks:
Whenever a node receives a block that it cannot link to the chain, it stores it in memory in mapOrphanBlocks. There is no limit to the size of that data. When a node is downloading blocks, it may download and keep in memory many blocks that it can't currently link to the chain. In particular, if your node connects to another node which is also downloading blocks and which is further along in the download, the other node will spam your node with an "inv" message for every new block that it downloads (no, the logic in CBlock::AcceptBlock does not prevent it), and your node will download and store those blocks in mapOrphanBlocks. This can occur with multiple connected nodes simultaneously which are at different points in the download.
I encountered this problem several times with 0.8.0rc1. With the current size of the blockchain, it is not hard to exhaust the virtual address space (at most 4GiB) in 32-bit builds, which includes all Windows builds.
The fix could proceed in one of two directions: (1) store orphan blocks on disk instead of in memory, or (2) don't keep an unbounded set of orphan blocks. For (2), the ideal would be to prevent downloading of too many orphans rather than discarding orphans that have already been downloaded, which is wasteful. The goal would be to download blocks roughly in order. One idea is to make use of "getheaders" during block download. Headers would be downloaded and linked together, and blocks would only be downloaded if we already know based on headers that they are not too far away from the chain of blocks that we already have.
Whenever a node receives a block that it cannot link to the chain, it stores it in memory in mapOrphanBlocks. There is no limit to the size of that data. When a node is downloading blocks, it may download and keep in memory many blocks that it can't currently link to the chain. In particular, if your node connects to another node which is also downloading blocks and which is further along in the download, the other node will spam your node with an "inv" message for every new block that it downloads (no, the logic in CBlock::AcceptBlock does not prevent it), and your node will download and store those blocks in mapOrphanBlocks. This can occur with multiple connected nodes simultaneously which are at different points in the download.
I encountered this problem several times with 0.8.0rc1. With the current size of the blockchain, it is not hard to exhaust the virtual address space (at most 4GiB) in 32-bit builds, which includes all Windows builds.
The fix could proceed in one of two directions: (1) store orphan blocks on disk instead of in memory, or (2) don't keep an unbounded set of orphan blocks. For (2), the ideal would be to prevent downloading of too many orphans rather than discarding orphans that have already been downloaded, which is wasteful. The goal would be to download blocks roughly in order. One idea is to make use of "getheaders" during block download. Headers would be downloaded and linked together, and blocks would only be downloaded if we already know based on headers that they are not too far away from the chain of blocks that we already have.
How much memory does your system have?
I could implement the second option, but will look into how bitcoin fixed this issue.
Also, if you have any other exceptions, please post them.
Before Slimcoin went awol he posted an 'untested' fix to github that should mostly resolve this issue. I don't think that anyone has compiled or tested the fix for windows yet.
I see the exact same errors with the current release on my windows VPS nodes each with 1 GB RAM, however another PC with 16 GB of RAM is 'stable', although these memory issues are still present ofc.
Windows OS below windows 7 is also worse for some reason.
I had a PM discussion with Slimcoin about compiling the new code for testing - I suggested that he should compile it - maybe he is re-writing the code base from unity instead ? It is doubtful that he would just abandon Slimcoin.
September 07, 2014, 11:42:11 AM
Any ideas how to fix this? It's driving me crazy to see all my burned coins degrading and I can't keep the wallet open for more than a few minutes at a time. I've tried deleting everything but wallet.dat and letting the blockchain reload, but it doesn't help.
September 07, 2014, 07:24:09 AM
September 07, 2014, 06:08:18 AM
I suppose we like the idea.
And some of us don't think it's had a decent chance to prove its merit.I see altcoin space as feature-oriented. To take a deliberately jaundiced perspective: it's all just a pile of whistles and bells decorating classic bitcoin - the basic feature set is fixed by the fork parent. In that context, PoB is a potential genuine extension of that feature set and has some claimed merit - this we are checking out because if it can be made to work, it gives the coin a valuable USP.
The idea does seem to make sense, at least at a surface level and I guess we're big enough and ugly enough to want to persist in finding out whether it is actually capable of delivering. Maybe the dev didn't get the initial implementation quite right. It's not as if it's the first time that's happened.
Quote
A few competent people could always take over.
I agree with the dev's assessment, a revised implementation based on the Peerunity fork holds some promise. The current slimcoin implementation is based on the Bitcoin 0.7.3 codebase (from which Peercoin was originally forked) and that's possibly a bit of an unsteady reed, still using BerkeleyDB and missing a raft of subsequent bugfixes, tweaks, etc.
Ironically, the collective task of getting this particular p2p engine firing smoothly is helping to establish a stronger sense of community ownership. Whilst it's not a strategy one would necessarily choose if given the option, there's little sense in throwing away all the progress to date in an impatient hissy-fit. I prefer to provide support where I think it'll be most effective, even if it's merely contributing a reliable node, as in this instance. I'm not at all sure that the effect of the last round of fixes wasn't banjaxed by the seed nodes going down while the dev was on holiday. We're still regaining network stability and that seems to be a problem in principle for any relatively low-hashrate coin.
We shouldn't underestimate the amount of work involved here. A browse through the repos commit history will inform you that “John Smith” has been consistently and persistently working on the code since December last year. The kids have only just gone back to school and his last post was about three weeks ago. I'm not anticipating full-time commitment from a man with a family, that would be unreasonable and, by my lights, undesirable.
However, I do think that the basic initial promise has been kept - mining on a Raspberry Pi and I prefer not to lose sight of this original goal because I can see a nice little brand story (“marketing strategy”, if you like) that would position this coin rather prettily in the spectrum of altcoin offerings and while it wouldn't necessarily demand involvement from the community of Slimcoin miners/owners, I believe it would definitely invite it. If-and-when the boat stops rocking, I'll start developing the idea further.
Cheers
Graham
September 07, 2014, 04:53:26 AM
Just for confirmation:
Cheers
Graham
Code:
gjh@tessier:~/Projects/Coinage$ ./slimcoin/src/slimcoind getblockhash 90141
00000010e9815d44f9f3e3dcba3ad793a8f81d9bf28498c81d83aed28b30d3b9
Cheers
Graham
September 07, 2014, 01:33:06 AM
I get the same hash.
September 06, 2014, 09:33:42 PM
if block 89923 is in your blockchain, you probably are on the right fork.
What are you getting for
slimcoind getblockhash 90141
00000010e9815d44f9f3e3dcba3ad793a8f81d9bf28498c81d83aed28b30d3b9
?
September 06, 2014, 04:17:18 PM
I suppose we like the idea.
A few competent people could always take over.
@d5000 Yes it is. Thanks for the help. I hope it starts staking now and mints again.
Edit: Oh and yes, maybe we will trade it between the three of us. Bitcoin is a medium sized circlejerk already.
Why not here.
A few competent people could always take over.
@d5000 Yes it is. Thanks for the help. I hope it starts staking now and mints again.
Edit: Oh and yes, maybe we will trade it between the three of us. Bitcoin is a medium sized circlejerk already.
Why not here. 
September 06, 2014, 04:07:11 PM
What are you idiots going to do once you collect enough of these coins ? Trade them between the three of you ?
Its dead you fools
Its dead you fools
September 06, 2014, 04:05:19 PM
if block 89923 is in your blockchain, you probably are on the right fork.
September 06, 2014, 02:12:40 PM
I've deleted all the nodes and the blockchain and started yet another time with
This works. I hope I'm on the "right" fork now, but only this node lets me actually download the blockchain...
Thanks a lot for uploading the chain though @rfcdejong!
Hope we hear back from the dev soon...
Code:
-connect=85.10.194.50
This works. I hope I'm on the "right" fork now, but only this node lets me actually download the blockchain...
Thanks a lot for uploading the chain though @rfcdejong!
Hope we hear back from the dev soon...
September 06, 2014, 01:28:43 PM
I've tried everything now.
It just wont go past 17/3x %. All it does is switch between them.
Deleted the blockchain, started again, same result.
It just wont go past 17/3x %. All it does is switch between them.
Deleted the blockchain, started again, same result.
i uploaded my %appdata%\slimcoin here, without wallet.dat ofcourse
try to download that, it will bring you to current date if it works
https://mega.co.nz/#!mQYxlCoQ!fQqJbRCe9CGHLrOkYCrUpwBoxyhzfIEbk1ULf-Qy30c
September 06, 2014, 12:46:12 PM
I've tried everything now.
It just wont go past 17/3x %. All it does is switch between them.
Deleted the blockchain, started again, same result.
It just wont go past 17/3x %. All it does is switch between them.
Deleted the blockchain, started again, same result.
September 06, 2014, 11:16:49 AM
try one of the following IP's, my client is connected mostly with them.
85.10.194.50
66.254.112.14
78.189.29.211
85.10.194.50
66.254.112.14
78.189.29.211
^^^ That's our server. I have the wallet on my laptop synched to it (and others) and minting seems to be happening --- and being confirmed, unlike the previous coupla dozen in late August which weren't. As to whether this is the right blockchain, well it's a popular choice of blockheight is all I'll venture
Code:
gjh@tessier:~/Projects/Coinage$ slimcoin/src/slimcoind getpeerinfo
[
{
"addr" : "146.185.168.142:43250",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410019597,
"conntime" : 1409943929,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 88887,
"banscore" : 0
},
{
"addr" : "222.190.105.10:47587",
"services" : "00000001",
"lastsend" : 1410019598,
"lastrecv" : 1410019598,
"conntime" : 1409943931,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 88887,
"banscore" : 0
},
{
"addr" : "66.228.43.203:45956",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410019597,
"conntime" : 1409943933,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 88887,
"banscore" : 0
},
{
"addr" : "54.191.247.114:56697",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410019597,
"conntime" : 1409943993,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 88889,
"banscore" : 0
},
{
"addr" : "78.189.29.211:41682",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410019555,
"conntime" : 1409944101,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 15164,
"banscore" : 0
},
{
"addr" : "66.254.112.14:41682",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410018872,
"conntime" : 1409944261,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 15157,
"banscore" : 0
},
{
"addr" : "202.198.62.133:37858",
"services" : "00000001",
"lastsend" : 1410019598,
"lastrecv" : 1410019598,
"conntime" : 1409944490,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 88887,
"banscore" : 0
},
{
"addr" : "85.234.11.66:58836",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410019597,
"conntime" : 1409944494,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 15164,
"banscore" : 0
},
{
"addr" : "144.76.118.179:44376",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410019597,
"conntime" : 1409944496,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 88887,
"banscore" : 0
},
{
"addr" : "106.186.126.57:41179",
"services" : "00000001",
"lastsend" : 1410019598,
"lastrecv" : 1410019597,
"conntime" : 1409944507,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 88887,
"banscore" : 0
},
{
"addr" : "83.104.61.47:23340",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410019597,
"conntime" : 1409944511,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 88887,
"banscore" : 0
},
{
"addr" : "188.134.72.213:37708",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410019597,
"conntime" : 1409944511,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 88887,
"banscore" : 0
},
{
"addr" : "95.211.57.109:53259",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410019597,
"conntime" : 1409944512,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 88887,
"banscore" : 0
},
{
"addr" : "49.77.54.36:49985",
"services" : "00000001",
"lastsend" : 1410019598,
"lastrecv" : 1410019598,
"conntime" : 1409944514,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 88887,
"banscore" : 0
},
{
"addr" : "192.3.21.71:32920",
"services" : "00000001",
"lastsend" : 1410019598,
"lastrecv" : 1410019597,
"conntime" : 1409944543,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 88890,
"banscore" : 0
},
{
"addr" : "121.229.79.242:26211",
"services" : "00000001",
"lastsend" : 1410019598,
"lastrecv" : 1410019598,
"conntime" : 1409944543,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 88890,
"banscore" : 0
},
{
"addr" : "192.99.184.33:35578",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410019597,
"conntime" : 1409944549,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 88890,
"banscore" : 0
},
{
"addr" : "106.186.126.61:53919",
"services" : "00000001",
"lastsend" : 1410019598,
"lastrecv" : 1410019597,
"conntime" : 1409944555,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 88892,
"banscore" : 0
},
{
"addr" : "54.191.21.109:62810",
"services" : "00000001",
"lastsend" : 1410019598,
"lastrecv" : 1410019597,
"conntime" : 1409944562,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 15157,
"banscore" : 0
},
{
"addr" : "222.94.98.239:55567",
"services" : "00000001",
"lastsend" : 1410019598,
"lastrecv" : 1410019598,
"conntime" : 1409944631,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 88892,
"banscore" : 0
},
{
"addr" : "60.28.18.130:58278",
"services" : "00000001",
"lastsend" : 1410019598,
"lastrecv" : 1410019598,
"conntime" : 1409944680,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 88892,
"banscore" : 0
},
{
"addr" : "88.113.158.141:57544",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410019597,
"conntime" : 1409975501,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 89230,
"banscore" : 0
},
{
"addr" : "112.113.96.138:50758",
"services" : "00000001",
"lastsend" : 1410019598,
"lastrecv" : 1410019598,
"conntime" : 1409997486,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 89479,
"banscore" : 0
},
{
"addr" : "79.194.74.153:60166",
"services" : "00000001",
"lastsend" : 1410019599,
"lastrecv" : 1410019599,
"conntime" : 1409999014,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 89516,
"banscore" : 0
},
{
"addr" : "81.207.93.95:51027",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410019597,
"conntime" : 1410004369,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 89558,
"banscore" : 0
},
{
"addr" : "200.50.125.123:57248",
"services" : "00000001",
"lastsend" : 1410019100,
"lastrecv" : 1410019099,
"conntime" : 1410011674,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 46501,
"banscore" : 0
},
{
"addr" : "190.252.87.227:49461",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410019414,
"conntime" : 1410013361,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 15164,
"banscore" : 0
},
{
"addr" : "107.181.250.216:63620",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410015262,
"conntime" : 1410015262,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 75468,
"banscore" : 0
},
{
"addr" : "85.57.241.211:3585",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410017695,
"conntime" : 1410015630,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 46470,
"banscore" : 0
},
{
"addr" : "85.58.54.90:3584",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410015836,
"conntime" : 1410015836,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 15164,
"banscore" : 0
},
{
"addr" : "177.80.48.195:52070",
"services" : "00000001",
"lastsend" : 1410018372,
"lastrecv" : 1410018386,
"conntime" : 1410016050,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 49996,
"banscore" : 0
},
{
"addr" : "118.100.200.159:51528",
"services" : "00000001",
"lastsend" : 1410019598,
"lastrecv" : 1410019597,
"conntime" : 1410016269,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 15164,
"banscore" : 0
},
{
"addr" : "119.56.126.18:18854",
"services" : "00000001",
"lastsend" : 1410019598,
"lastrecv" : 1410019598,
"conntime" : 1410016307,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 89679,
"banscore" : 0
},
{
"addr" : "81.167.135.5:65127",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410019597,
"conntime" : 1410017124,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 89674,
"banscore" : 0
},
{
"addr" : "88.151.72.47:54044",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410019414,
"conntime" : 1410018223,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 15164,
"banscore" : 0
},
{
"addr" : "89.212.138.20:60792",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410018242,
"conntime" : 1410018235,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 47557,
"banscore" : 0
},
{
"addr" : "124.10.130.186:3043",
"services" : "00000001",
"lastsend" : 1410019597,
"lastrecv" : 1410018894,
"conntime" : 1410018894,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 42047,
"banscore" : 0
},
{
"addr" : "109.199.64.140:3051",
"services" : "00000001",
"lastsend" : 1410019199,
"lastrecv" : 1410019198,
"conntime" : 1410019197,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 39158,
"banscore" : 0
},
{
"addr" : "188.34.255.94:49935",
"services" : "00000001",
"lastsend" : 1410019509,
"lastrecv" : 1410019503,
"conntime" : 1410019374,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 52525,
"banscore" : 0
},
{
"addr" : "112.113.96.138:52516",
"services" : "00000001",
"lastsend" : 1410019389,
"lastrecv" : 1410019599,
"conntime" : 1410019385,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 89719,
"banscore" : 0
}
]
Be careful out there!
Cheers
Graham
September 06, 2014, 07:26:25 AM
It switches between 17% and 34%.
Tried restarting a ton of times to no avail.
Would anyone mind uploading his SLM blockchain?
I really see this coin dying (if it can't be considered dead already if you look at the BTER orderbook) if the dev doesn't do something or a few competent devs take over..
Tried restarting a ton of times to no avail.
Would anyone mind uploading his SLM blockchain?
I really see this coin dying (if it can't be considered dead already if you look at the BTER orderbook) if the dev doesn't do something or a few competent devs take over..
try one of the following IP's, my client is connected mostly with them.
85.10.194.50
66.254.112.14
78.189.29.211
September 05, 2014, 10:29:48 PM
It switches between 17% and 34%.
Tried restarting a ton of times to no avail.
Would anyone mind uploading his SLM blockchain?
I really see this coin dying (if it can't be considered dead already if you look at the BTER orderbook) if the dev doesn't do something or a few competent devs take over..
Tried restarting a ton of times to no avail.
Would anyone mind uploading his SLM blockchain?
I really see this coin dying (if it can't be considered dead already if you look at the BTER orderbook) if the dev doesn't do something or a few competent devs take over..
September 05, 2014, 06:19:06 PM
@m5j0r: At this moment, my wallet is syncing fine, but I had similar problems some days ago. Nearly everytime I could solve it restarting the daemon every time it gets stuck, looking 10 minutes after if it syncs and if not restarting it again, until it downloads the blockchain. Sometimes I had to delete the blockchain, but most of times it got stuck it eventually resumed the download.
I better don't give my IP out because my client runs on a low memory machine and runs out of memory sometimes, so I am restarting it with a cronjob when it has stalled
I better don't give my IP out because my client runs on a low memory machine and runs out of memory sometimes, so I am restarting it with a cronjob when it has stalled
September 05, 2014, 04:33:09 PM
@slimcoin Please ffs can you help me sync the blockchain?
@hank has helped me before, I'm using his nodes because he seems one of the few that actually care. Thanks for that again at this point
I can not sync the blockchain. It is stuck at 17% even though it has connections and just sits there.
I have wasted enough power by running my sys 24/7 for minting/staking.
@hank has helped me before, I'm using his nodes because he seems one of the few that actually care. Thanks for that again at this point
I can not sync the blockchain. It is stuck at 17% even though it has connections and just sits there.
I have wasted enough power by running my sys 24/7 for minting/staking.
Jump to: