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.


Added these nodes to the peer list of the block explorer.

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.


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'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.


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?]

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.

i have this:

getblockhash 62703
de6c470f108e5f26383f0fedb1bbad9b723fb6176bb5aa2312f1173377e755c5

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.

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.

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)

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

+1 for the static build! anyone tried running that on a raspberry pi yet?

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 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)