Show Posts
|
Pages: « 1 2 3 [4] 5 »
|
Took forever, but I finally managed to compile both slimcoin-qt and slimcoind on Windows. Latest commit: Added 5 hard-coded seed nodes: [37.187.100.75, 5.9.81.9, 192.3.21.71, 107.181.250.216, 107.181.250.217] Fixed some header issues (not sure if bug or just my configuration) Release Notes: Incorporated all of Slimcoin's changes since last release: Improved PoS cpu usage, Disk read efficiency, Reduced mem requirements, RPC improvements Incorporated some of my changes: Bans misbehaving old clients, added checkpoints, added seed nodes, turned off PoS by default You can download the Windows-Qt release at https://github.com/kryptoslab/slimcoin/releases
|
|
|
Good point actually. I've pushed a commit that makes it reservebalance=1000000 by default, so PoS will be opt-in for now. addnode=107.181.250.216:41682 addnode=107.181.250.217:41682
Added these nodes to the peer list of the block explorer.
|
|
|
My slimcoin client was taking nearly 300% CPU when I killed it. I have staking disabled and it has been running fine for weeks. Any ideas why it went crazy?
Could you dump the debug.log onto pastebin and post us the link?
|
|
|
Just a quick update, I've forked slimcoin to https://github.com/kryptoslab/slimcoin. I pushed a couple of changes here which focuses on gradually banning clients that are stuck at 15164 or keep requesting for blocks between 30k to 60k, while not keeping legitimate users away. If you have memory concerns, this would be quite useful; my clients now run consistently at a lower RAM utilisation and uses much less bandwidth - the old code really can eat up gigabytes of both RAM and bandwidth every day. Also, hankrules suggested a checkpoint which I incorporated into the code. He is also offering to work on a dnsseed node. Currently I'm about a quarter done into browser-based burning. I quite like the convenience of the idea here and I do intend for it to visually show how mining and burning works in an interactive fashion, so as to educate and encourage the uptake of SLM. Also, I have noted that since the change the supply of SLM has grown much faster than before. I know, in theory it should be the same like before because of the diff adjustment for PoS. Perhaps it is related to the PoW changes, I don't know.
The rates of SLM minting for PoW and PoB are inversely linked to the difficulty, so I guess the minting rate is much higher. A month back it was like, 8 SLMs minted every PoW block but now it's 12 to 13. I am neutral regarding PoS removal. Note that PoS in PPC is the main security mechanism, with PoW having almost no importance. So in a PPC-based PoW/PoB coin without changing this, the PoB algorithm (which is the most experimental part of the coin) would carry "most responsibility" for blockchain security. But I am not an expert on this issue, only read this in the PPC forums, as I am not a programmer.
I'm also quite ambivalent about PoS removal. PoB in this current implementation does not secure the blockchain, and the design of SLM actively discourages mining, so it might make Slimcoin vulnerable to 51% attacks if it's PoW/PoB only. I'll explore 2 methods of fixing the PoS issue on a testnet branch and will update here once I get the code up; hopefully everyone can run a copy to test and we can be rich in test-SLMs for a bit. I intend to check/change the hashing function (slimcoin himself did note that this is quite intensive and he tried to fix it), as well as simulate and re-weigh the values for PoS, PoB and PoW. If all these fail, then I'll disable PoS and we can see if it helps stability (compared to the main fork). If all goes well, we can then have a hard fork implementing these PoS changes and disabling access from old clients. In the background, we should still see if there are any skilled devs willing to port it to a newer code-base. Slimcoin did mention he was interested in this approach though he remains busy. Could I have your SLM address for donation, please? Very appreciate for helping this coin.
I am planning to give SLMs away faucet-style, but tied to IP and the web-wallet mining itself (ala lucky draw while browser mining), so will welcome donations for spreading more SLMs around and get people excited about it. You can donate SLMs to Sg72f5icXXAjrdV7o15ZrFdj9CvNaTZwS1; this is what feeds the browser mining rewards (besides the rewards from mining, that is).
|
|
|
For the client itself, I will hope that improved awareness and better prices will also bring in developer interest (perhaps the original dev's interest too?). In the meantime, I think we can start building up a list of things to fix specifically, perhaps by listing them as issues on github. If no one steps up, I'll fork and make changes to the slimcoin code-base.
The latest version for github is actually quite stable: 3.2.0.6. So far for me, the high cpu/memory usage stems from 2 issues: PoS and bad nodes. Because the version numbers have not changed, older incompatible nodes are freely connecting and repeatedly downloading the blockchain data which fails their verification; I had to block each ip/ip range one by one.
I usually disable PoS cos it sucks my cpu, but PoS itself doesn't really contribute much to the growth. d5000 mentioned that previously there was bump in the reward, but it was also met with a corresponding 10x increase in difficulty which should cancel out: this change was to reduce the number of PoS blocks generated then, which was overwhelming the PoW/PoB blocks.
PoS also appears to be the cause of some block sync and distribution issue: Primer- had mentioned it quite regularly back then, and I also had the same experience. I also noticed that in the past consecutive PoS blocks actually caused my nodes to reject the chain thus orphaning it, though it could also have been an effect of the automatic checkpointing server which seems down now.
I'm still in favour of PoS actually, as long as the bugs can be fixed. Think one of the main issue could also be that dcrypt instead of dbl-sha256 is used for PoS blocks, and that is really really intensive (which can lead to unresponsiveness with a lot of transactions), so that can be an avenue of exploration.
I don't encounter these problems now; but as BitcoinFX mentioned, this could be because of the small number of active nodes.
Needed Changes 1. Add checkpoints 2. Remove PoS or Fix PoS 3. Hardfork with new Protocol Version to reject all older clients
|
|
|
Slimcoin still appears very promising to me but it lacked marketing and awareness, and is also difficult to set up and learn about the various innovations. I thus spent sometime deciphering the slimcoin source and built this site http://www.slimcoin.club/. It has a brain wallet with mining, transaction and burning built in; all transactions and blocks are signed locally (I never see your key) then sent to one of my nodes for broadcasting. (oh yea while burning coins is ok, burnt-coin mining on browser is still buggy; that'll be my next to fix. mining works but is very slow, so i'm thinking of using it more for faucet and coin distribution and to introduce the concept of mining) I plan to make the page the on-board ramp to get people interested and learn about slimcoin mining, transactions, burning, and to eventually install the client full-time; but yet remain completely functional for those who aren't into running the full client (assuming my nodes remain up). Also, for us slmers there's a rudimentary block explorer. Everything's still very alpha and I'm open to your suggestions and your help.
|
|
|
one of my nodes got stuck at 111900s as well a couple of hours ago; though i suppose it might have resolved since you guys mentioned this almost half a day ago.
the latest version by dev on github "v0.3.2.0-6-gafd8ef7-dirty-alpha" seems quite stable. haven't had it give me any problems for quite a while.
all these seem to be listeners and have synced up to at least 112489 on my peer list.
192.3.21.71:41682, 37.187.100.75:41682, 203.20.114.252:41682, 5.9.81.9:41682
|
|
|
I've noticed several points in time today when consecutive POS blocks led to the blocks getting stuck in some clients. I'm comparing with only blockexperts.com/slm.
79651 - 79653: POW -> POS -> POS: The time difference between these three blocks is almost an hour. It showed that I had 23 orphans.
POW (I mined 79651) -> POS (79652@03:52:35) -> POS(79653@04:41:10) -> POW (I mined 79654@04:41:49) -> POW (I mined at 03:52:52 -> forked) ... 22 POWs -> *Fork resolved back to the blockexpert's chain. ^
This happened another time: I noticed that blockexperts got stuck at a POS block, but it later resolved towards my chain. I can't remember the block numbers.
Same issue at POW@79776 -> POS -> POS -> POS -> POW (79780). -> POW (+4 minutes after POS) -> 10 POW orphans -> fork resolved ^
Appears to be happening right now @ 79793. As of now it's 20 minutes since the block expert's client accepted a block, while it appears my client has ignored the POS and is happily going down it's POW chain.
Anything to do with the client #? Blockexperts seem to be a bit behind (v0.3.2.0-alpha vs v0.3.2.0.2-g53d7c33-alpha).
In all these cases, my client rejected the POS despite it being obviously earlier. So I'm guessing the POW score somehow made my client think I'm the winner, and the POS time made the blockexperts think it's the winner?
My client abandoned the POW chain only after another POS block hit in - I'm guessing it is some block score threshold hysteresis?
Since I'm obviously not the only miner around, I assume all other miners also couldn't submit their blocks through?
[edit: 79794, a second POS, brought the network back in line. i don't think this should be the correct behaviour though?]
|
|
|
HELP! I've got over 600 coins paid to me in the past few days, but none are showing up in my wallet. I've had the blockchain downloaded for over 12 hours, and still no sign of my coins. How long does it take for the transaction to show up? I'd think it'd be less then 12 hours. Does anyone have any idea how to fix this?
there appears to be no current consensus on which is the valid blockchain, as the admin's nodes and checkpoint nodes appear to be down. you might not be on the correct chain which your 600 slm transaction occurred. wait a couple of day and let the forks resolve first.
|
|
|
how about block 62703 ?
all have this hash?
getblockhash 62703 de6c470f108e5f26383f0fedb1bbad9b723fb6176bb5aa2312f1173377e755c5
i have this: getblockhash 62703 de6c470f108e5f26383f0fedb1bbad9b723fb6176bb5aa2312f1173377e755c5
|
|
|
getblockhash 63204 6520b565111078281bce8c574b49182765d27ddb299a9ad2ae0e6fd784687a09
getblockhash 63204 0000000439239c957deb709b3ef6040986c1b1a9af8d9a8460efe94c9b4c819e ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) I've been mining via slimminer and the client for about 3 days, with not a single block found. Looks like even if I did find a block I may be wasting my time. I think I'll shut down the client until the forks are resolved. getblockhash 63204 0000000439239c957deb709b3ef6040986c1b1a9af8d9a8460efe94c9b4c819e perhaps we should share our node ips? i don't mind how the forks resolve as long as they do. i'm on 192.3.21.71, currently at block 63693, diff 0.00539.
|
|
|
Has anyone felt any difference in the PoS cpu usage issue in the last update?
I was running a client cpu-bound to a single G1620 for PoS both before and after, and cpu utilisation appears to drop from about 25ish to 15ish. But it's hard to say as I wasn't monitoring the utilisation in particular.
|
|
|
So I turned off the auto SLM sending function and just exported the time stamps the blocks stopped syncing. Aug 1 0730: 55674 - 55680: 8 minutes Aug 1 0840: 55717 - 55720: 4 minutes Aug 1 1115: 55849 - 55865: 20 minutes Aug 1 1201: 55877 - 55893: 22 minutes Aug 1 1502: 56020 - 56031: 16 minutes Aug 1 1642: 56082 - 56097: 22 minutes Aug 1 1748: 56135 - 56158: 26 minutes (Debug log sliced out for this section: http://pastebin.com/ytuNWsj9, btw 2 wallet flushes timestamped) Aug 1 1930: 56215 - 56240: 21 minutes Aug 1 2051: 56302 - 56323: 22 minutes Aug 2 0140: 56538 - 56542: 4 minutes For sharing. I'll try to figure out what's wrong as well hmm.
|
|
|
New UpdateTL;DR: The client will now use less cpu resources and the blocks will propagate faster. I looked around the source code to see where the PoS was using so much CPU usage. I finally found it today, it was actually an issue with how the PoS used the block.GetHash() function so freely. I forked this off of Peercoin, so the GetHash() used double SHA256, not that intense. Dcrypt is much, much more intensive, yet it was called in the same places. I made changes that removed the need to call GetHash() at all on PoS. I ran an absolute worse case test and it used 50% of 1 core. On normal usage, PoS used 8-10% on 1 core, compared to the 3-5% on 1 core with PoS disabled. I even looked further into making PoS use less cpu, the portion that adds the 5% cpu usage to the client is part of the core of PoS, and cannot be optimized. I searched for other places in the client that could suffer from a similar issue of excessive calls of GetHash(). I found 2 more in the "getdata" command and the "block" command the nodes send to each other. Downloads - Source code: https://github.com/slimcoin/slimcoin - Binaries (Linux and windows): cutable Thanks for the fix! It definitely wasn't an easy task to root out the problem. Downloading and testing it now. (edit) Incidentally, I had much difficulties downloading the blockchain despite the -maxconnection settings; but once I commented out all addnode= entries in the slimcoin.conf file everything went smoothly. (/edit)
|
|
|
"difficulty" : 0.99092765, "errors" : "", "generate" : false, "genproclimit" : -1, "hashespersec" : 0, "networkghps" : 0.01028020,
It is real?? ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) Yes, POS mechanism clearly a problem! PoS cpu-hogging is just fixed, so I presume there's a sudden release of txns ready for minting. There's also an upcoming PoS fix which should kick in on Aug 4 that reduces the PoS generation rate by 10x.
|
|
|
yup i did, the daemon had run fine for a while. it's running fine now too.
|
|
|
I've been running the new daemon and it threw up 300000 lines of so of the following in debug.log
ERROR: CBlock::ReadFromDisk() : OpenBlockFile failed ERROR: CTransaction::ReadFromDisk() : OpenBlockFile failed
ending finally with
************************ EXCEPTION: N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_6system12sys tem_errorEEEEE accept: Too many open files slimcoin in ThreadRPCServer()
Not sure if it's just my server but just to share it out.
|
|
|
@primer- the desynchronisation looks really bad! Would be quite hard to mine anything like that. I get something like this Wed Jul 30 18:56:32 2014 : All ok! Values: 54009 54009 Wed Jul 30 18:57:33 2014 : All ok! Values: 54009 54009 Wed Jul 30 18:58:34 2014 : All ok! Values: 54009 54009 Wed Jul 30 18:59:35 2014 : All ok! Values: 54009 54009 Wed Jul 30 19:00:35 2014 : 54010 vs 54009 : Sync error. Will send SLMs in the next minute. Wed Jul 30 19:01:41 2014 : 54010 vs 54009 : 2 minutes off:6a92988cfc165a6f66caed81d1303050931917c1f5161bd885d595eebe86526c Wed Jul 30 19:02:48 2014 : All ok! Values: 54010 54010 Wed Jul 30 19:03:49 2014 : All ok! Values: 54010 54010 Wed Jul 30 19:04:50 2014 : All ok! Values: 54010 54010 Wed Jul 30 19:05:50 2014 : All ok! Values: 54010 54010 Wed Jul 30 19:06:56 2014 : All ok! Values: 54010 54010 Wed Jul 30 19:07:57 2014 : All ok! Values: 54010 54010 Wed Jul 30 19:09:03 2014 : All ok! Values: 54010 54010 Wed Jul 30 19:10:09 2014 : All ok! Values: 54010 54010 Wed Jul 30 19:11:15 2014 : All ok! Values: 54010 54010 Wed Jul 30 19:12:16 2014 : All ok! Values: 54010 54010 Wed Jul 30 19:13:23 2014 : 54012 vs 54010 : Sync error. Will send SLMs in the next minute. Wed Jul 30 19:14:24 2014 : 54013 vs 54010 : 2 minutes off:b33f5ca66ada10036bab0cddbf106804923bc40e9721098f74328837e97e6043 Wed Jul 30 19:15:30 2014 : All ok! Values: 54013 54015 Wed Jul 30 19:16:36 2014 : All ok! Values: 54016 54016 Wed Jul 30 19:17:42 2014 : All ok! Values: 54016 54016 Wed Jul 30 19:18:42 2014 : All ok! Values: 54016 54016 Wed Jul 30 19:19:48 2014 : All ok! Values: 54017 54017 Wed Jul 30 19:20:54 2014 : All ok! Values: 54017 54018
|
|
|
+1 for the static build! anyone tried running that on a raspberry pi yet? ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Just to share that I had trouble syncing (the logs mentioned connection refused), but I bootstrapped the blockchain from another node and it worked fine. Currently I'm using a script to check with blockexperts API, and sending 0.01 SLM once my block count gets stuck: this is based on primer-'s observation that transactions somehow seem to wake up the daemon. I also observed that sending valid blocks even if they are orphaned also work sometimes, so I guess it has something to do with sending valid signed data originating from your node. Debug.log doesn't show anything amiss; activity just somehow stops. Perhaps it's some kind of DDoS protection that went overboard? Script if anyone's interested: http://pastebin.com/1dnUQW7t. Don't forget to change to your address and path. Example of orphanages filled during block sync issues when script is not running (this is grepped from only PoW blocks in listtransactions, circa block 53330) : "confirmations" : 412, "confirmations" : 0, "confirmations" : 397, "confirmations" : 0, "confirmations" : 384, "confirmations" : 370, "confirmations" : 363, "confirmations" : 357, "confirmations" : 342, "confirmations" : 341, "confirmations" : 324, "confirmations" : 322, "confirmations" : 319, "confirmations" : 315, "confirmations" : 304, "confirmations" : 0, "confirmations" : 296, "confirmations" : 0, "confirmations" : 0, "confirmations" : 0, "confirmations" : 0, "confirmations" : 243, "confirmations" : 238, "confirmations" : 234,
|
|
|
I have a running wallet on a long fork but all recent transactions are marked with a question mark. Does it mean all these blocks were deleted from the database and we cannot get them back? No, I had another computer that was not fully synced yet when the reorganization happened and cut it off. And all block upto block 43685 was left was there.
i also had some transactions affected by the fork. "repairwallet" at the console fixed the balance for me. however, when I try to send the coins again I get "Error: The transaction was rejected. This might happen if some of the coins in your wallet were already spent, such as if you used a copy of wallet.dat and coins were spent in the copy but not marked as spent here." any ideas how I can fix this? thanks. (edit: i tried to rebroadcast the earlier transaction but that failed. dumpprivkey and re-import/rescan didn't work either)
|
|
|
|