I'll sell my 658 BCH for 0.14 BTC each if someone wants the entire lot.

Escrow through collincrypto on bitrated.

Offer withdrawn, I'm going to wait until this thing gets easier to trade and just use an exchange.

What type of blockchain is it? is it forked from something else or a complete new design?

I didn't port anything over to slimcoin, I made some optimizations to the already ported CPU miner as well as my own version of the GPU miner that was dumped in the forum. I think I may have scared away a few people by publishing the fact that someone had been mining with a highly optimized miner long before I made mine public because you can see when the hashes in the blockchain started to be dominated by optimized ones.

https://github.com/JonnyLatte/slimminer
https://github.com/JonnyLatte/slimminerGPU

I have not looked at anything related to slimcoin for quite some time as well as I have been occupied learning solidity programming for ethereum as well as real life obligations.

Honestly I dont have much hope for the future of slimcoin. Any developer with the skills needed to fix its problems isnt really going to be moved by a bounty in SLM because they would be much better off starting from a clean ledger and in the same way a bounty for work on the client would probably be better spent working on the protocol with the end goal being the eventual creation of a new altcoin with a better distribution. Saving the distribution has the value of maintaining slimcoin's historical point of being the first PoB altcoin but how important is that really compared to a better distribution and daveloper interest/investment? Look at Emercoin right now, its a clone of peercoin but it has sustained more active developers for some time (a lot of peercoin developers are more interested in producing spinoffs using peercunity rather than working on the core protocol and how long has something as simple as cold locked minting been promised and not delivered?) Developer interest is what sustains these projects beyond a single bubble cycle since its how altcoins get features that put them in their demographic niche.

Slimcoins resilience has been remarkable though. I think this is mostly due to the strong incentive of PoB. In fact if peercoin does get its act together they will eventually transition to something like slimcoin incentives but on coin stake rather than burn. Mint or miss out is just a better way to do it than hold for as long as you like then mint for the full reward. I fully believe that if slimcoin had been developed before peercoin then peercoin would have never left the ground and in many ways peercoin was in as bad a state when i discovered it (no exchanges, only one very secretive dev, crappy website and no marketing) as slimcoin is now with exception to the uneven distribution of funds due to peercoin sticking with sha256 and the advent of GPU/ASIC having a relatively open availability or at least a shorter time being monopolized relative to the total supply.

I would love to be able to throw 5... 10.. 30 BTC into funding development of slimcoin but I think most of that would be pissed away. I could learn how to be a core developer myself but that would take at least a year before i could be confident in making changes to the client and that is time I would not be spending learning to program smart contracts and at the end better stake based consensus algorithms will already be maturing and newer ones like Casper developed.

Sorry to be a downer but thats just where I'm at with slimcoin.

If you implement something like the lightning network you could trade as fast as a centralized exchange:

https://youtu.be/8zVzw912wPo

Highly experimental GPU miner based on the one posted here previously but integrated into my own code (I could not get theirs to be stable)

Additional parameters:
      --gpu                   enable gpu mining
      --platform=N      index of the OpenCL platform to use
      --device=N        index of the OpenCL device to use
      --worksize        number of values to send to the GPU at a time
     --cputhreads      number of threads that will remain CPU workers

Works best for me with half of the threads remaining as CPU miners but there is a lot of room for experimentation. Setting the worksize really high is not necessary as each round of work sent to a thread will just get divided up and sent to the GPU in batches anyway (setting it too can result in errors). Not including --platform and --device will default them to zero which is usually what you want anyway unless you have multiple cards in which case you can run the program for each card.

Additional improvements needed: 

 - Pre-calculating internal hashes for dcrypt on the GPU should speed things up slightly, this I will work on next weekend
 - More testing to get it as stable as the CPU miner / testing on windows.
 
Notes:

This was only tested on my PC: AMD FX-8370 Eight-Core Processor × 8  / 64bit Ubuntu  + AMD Radeon HD 7850.
My previous miner gave me 60kh/s this one is doing about 100kh/s consistently with about half the block being generated by the GPU. This is not an improvement in speed over the previous version in terms of GPU mining, its just I hope easier to use.

Repository:

https://github.com/JonnyLatte/slimminerGPU

gavrilo77, one thing you might try is setting the scan time (-s N) to something a little higher than the default 5 seconds, for me 30 seconds gets me a much higher hash rate without a significant number of stale blocks. I think the reason for this is that less time is spent fetching new work which is time that the threads are idle. I dont think this would be a problem with a pool/stratum though.

EDIT: What I just stated should not work. If you increase the scan time it should not have a significant effect on the hashrate. This has been bugging me since I wrote it and I have figured out what the bug is behind this behaviour: the way this version of slimminer optimizes its dcrypt function is to simply skip over any value that takes too long to hash, it effectively only hashes about 1 in 256 values. The effective hashrate that is displayed only includes completed hashes as it should however what I did not count on was that when work is divided up for each thread the miner doesn’t just split up the ranges of nonce values and pass them to each thread but instead it estimates how much each thread can process for the amount of time it will be running. Since the stored values for the hashrate are used in this calculation those values are 1/256 times what is needed for the right amount of work to be passed to each thread. So increasing the scan time only worked to increase the hash rate because of this bug. 

Anyway I have fixed this problem by recording the number of hashes skipped over and then recalculating the hashrate to include them after the effective hashrate is displayed. This hash brought the hashrate back up to the right level even with the short and appropriate scan time since threads are not starved for work and constantly asking for more.

TL;DR: updated version of  https://github.com/JonnyLatte/slimminer fixes problem that results from the optimized version of dcrypt having a low effective hashrate but needing to think it has a higher hashrate in order for enough work to be allocated to its threads. This improves the hashrate and lowers the time spent asking for more work.

EDIT2: ok found a block with it and noticed a miner aesthetic glitch, when a block is reported to be found it displayed the hashrate but since I changed the internal hashrates to include the skipped hashes it is displaying this increased hashrate at this point. That does not really effect anything but I'll get rid of it in another commit.

EDIT3: hashrate displayed correctly when block found, hashrate and effective hashrate now stored separately. Another thing I noticed is that the hashrate fluctuates quite a bit so I have changed the code to make the new hashrate calculation a weighted average of the previous hashrate so that the hashrate does not fluctuate so much and in turn the work supplied to each thread does not fluctuate much.

Edit4: latest version compiled for windows 32 bit using cygwin: https://github.com/JonnyLatte/slimminer/releases/tag/v0.2

I think I'm pretty much done making modifications to it at this point.

I'm guessing you are using version 0.4.1 slimcoin client. Try 3.2.1

Ok so I completely changed the timing code. The original code had each thread calculating its own hashrate as a double and storing that in an array with one thread when called adding together all the hashrates and displaying that sum. For some reason this fails pretty badly with highly optimized versions of dcrypt. To fix this instead of each thread calculating its hashrate it simply adds how many hashes it has done to an array then one thread every couple of seconds calculates its hashrate and the total hashrate from the time elapsed in one thread as opposed to calculating the hashrate based on each threads time elapse. This is the more objective way to do it I was looking for and solves the problem. As a bonus thread hashrates are now shown in order of thread from 0 to thread n followed by the total hashrate. I also added another command line option "--hashrates" so that you can combine it with "--quiet" to show just the total hashrates without the hashrate for each thread (how I like it)

TL;DR: new version of slimminer shows correct hashrate for highly optimized version of dcrypt CPU mining

https://github.com/JonnyLatte/slimminer

If anyone is curious I'm CPU mining at 40kh/s with my AMD FX-8370 Eight-Core Processor

EDIT: pre-calculating dcrypt internal hashes up to depth 5 added set with command line argument --hashtable=N. If memory cannot be allocated the program should fail gracefully.

This optimization brings the hashrate on my machine from 40kh/s to 60kh/s but requires significant amounts of RAM. (special achievement here with this improvement the CPU miner is mining faster than the GPU miner was when I tested it on windows)

The build instructions are in the README file:

Dependencies:
   libcurl-*-dev      http://curl.haxx.se/libcurl/
   libjansson         http://www.digip.org/jansson/
      autoconf              https://www.gnu.org/software/autoconf/
      (jansson is included in-tree)

Basic *nix build instructions:
   ./autogen.sh   # only needed if building from git repo
   ./nomacro.pl   # only needed if building on Mac OS X or with Clang
   ./configure CFLAGS="-O3"
   make

BitcoinFX also posted a guide that got me started on windows.
 
https://bitcointalk.org/index.php?topic=613213.msg7090075#msg7090075

As for whether my version should be official I would say once a few people verify it finds them blocks as it does for me. I would also point out that when you massively increase the mumber of threads the hashrate calculation is way off. At first I assumed this was because the program spends most of its time waiting for the network or for threads to start so I moved the timing code to include the time taken to fetch blocks and then all of the time not calculating the time passed (ie get the start time just after the interval is calculated). That made it more accurate but its still way off. Its still make way more blocks when the thread count is pushed up although I have not tested this objectively. This is the main problem that stops me from recommending it as a default cpu miner option. 

If you wish to try my version of slimminer here is the source:

https://github.com/JonnyLatte/slimminer

I have included all optimizations except pre-calculating the hashes for the scratchpad/buffer.

I don't know of any publicly available pools which is kind of a pain as it would help with testing of my version of the miner (verifying hash rates etc).

There is a GPU miner however it crashes on me after a while every time I run it (compiled for ubuntu) and I have not gotten around to figure out why. There is a windows 64 bit binary available for it although that would mean trusting a complete stranger who has made only 2 posts on the forum although the source does what the person claims: https://bitcointalk.org/index.php?topic=613213.msg10012906#msg10012906

to solo mine with slimminer:


./minerd -o 127.0.0.1:41683 -O username:password

This will run it with a thread for each core

./minerd -o 127.0.0.1:41683 -O user:pass -t 16

will run with 16 threads. You will also need to properly configure your slimcoin.conf with a matching  username "rpcuser=username" and password"rpcpassword=password" and if you are mining from a different machine add "rpcallowip=192.168.1.102" for example.

As for the best miner I think the GPU miner would be it if it could be made stable. Other than that I think there are several improvements that can be made to kryptoslab's optimized version which I have in my own version but its not ready to be released as the more I optimize it the more the calculation for the hashrate seems to get inaccurate so I need a good way to profile my changes in an objective way.

some optimizations of the dcrypt function for mining:

- calculating the half state for the first hash then for each nonce. you only need 1 shar256 round instead of 2 with a little memory copying overhead since I'm using openssl

- looping the index through the first hash/skip-list to the end to see if it aligns and aborting the hash if it doesn’t and aborting the hash if the end value does not match the first time. This gives me the biggest speed boost.

- not converting the skip-list to ascii and then back again since it will only be hashed once

- precalculating all of the possible hashes for the first 4 rounds of the buffer (this requires a lot of memory but gives a pretty good speedup. Right now I have a different version for my laptop that has less ram and so only computes the first 3 hashes and a computer with vast amounts of memory could push it to 5 (~3GB of ram needed for that though: the size of the resulting digest as well as the sha256 context of the result hash. for me the attempted slowed down or crashed randomly and took 20 seconds to calculate the table which was faster to load from a file)) this saves ~2 sha256 calls for how deep you go but replaces that with a couple of memory copies to get the pre-calculated state. Not a bad speed up though 

- using a fixed sized buffer and limiting the count at 16. kryptoslab's version seems optimal at around 100 max iterations however if you stepped through the skiplist and find out how many rounds are needed before actually hashing anything but the first hash you can abort without wasting the hashing power. Since you know the count will never go over 16 you can now just allocate the maz sized buffer instead of using the self made expanding default one. I actually think a fixed buffer should be in the main client dcrypt function with the result hash being done progressively hashed if it fills the buffer. That way you can eliminate the large memory requirements of dcrypt. I really don’t like the idea of random sized memory requirements for the hash function, some of the iteration counts I have seen go over 3K iterations which means 64*3k memory being allocated and deallocated over and over. I wonder what the max iteration count is on the blockchain... It bugs me also that the original dev wrote this function with a custom memory manager that does not test to see if the memory was in fact properly allocated: https://github.com/kryptoslab/slimcoin/blob/master/src/dcrypt.cpp (extend_array) which means if a block with a hash with a huge count is received by a client you could actually remotely crash a client when it receives the block if its low on memory and cant page some out. Extremely unlikely but annoying that its possible.

What is your process for building slimminer?

I use the guide:

https://bitcointalk.org/index.php?topic=613213.msg7090075#msg7090075

but substitute kryptoslab's optimized version:

https://github.com/kryptoslab/slimminer

The OpenSSL library is usually already installed, but you have to install the header files. Depending on your Linux distribution, you'll need these packages:

    Red Hat, Fedora, CentOS - openssl-devel
    Debian, Ubuntu - libssl-dev
    Arch - openssl

Mining on version 0.4.1 compiled myself on ubuntu 14.04 32 bit I get the following error when a block is submitted:


I have received this error consistently when submitting blocks to version 0.4.1.

To verify it wasn’t just caused by my modified version of slimminer I also mined on version 0.3.2.0 found at https://github.com/kryptoslab/slimcoin/releases compiled from source on the same machine. I have found several blocks that have been submitted and accepted without a problem.

hmm, I have the qt-client compiled on ubuntu 14.04 32 bit.

I have it synced with the help of the bootstrap hashmaster3000 has provided and my own wallet with burnt coins loaded with the burnt coins showing in the client but it doesnt seem to be minting (wallet unlocked) or mining (might take a while on only 4kh/s but still the difficulty is quite low) I'm more interested in PoB though as I have significant coins burned and my GPU is currently occupied with ETH mining. 

Any one else have the qt client (https://github.com/slimcoin-project/Slimcoin) compiled for ubuntu 32 bit or otherwise synced but not producing blocks?

"What wallet version are you using for solomine?"

v.0.3.2.1-alpha on windows 7 64 bit. Client downloaded from https://github.com/kryptoslab/slimcoin/releases/

my slimcoin.conf has the following nodes:


addnode=37.187.100.75:41682
addnode=203.20.114.252:41682
addnode=5.9.81.9:41682

also I have "gen=0" so the client does not mine itself but just acts as a server with the -server flag

I launch the gpu miner with the following:

minerd -o http://localhost:41683 -O username:password -t 32

I have an 8 core system and found 32 threads (-t 32) works best for me (should be a multiple of the number of cores you have).

bittick or anyone new here, if you want some SLM to mess around with proof of burn post an address for tips.

I'm pretty certain that the GPU miner was the same one used since ~block 17K since the low count values ware actually in the range for the GPU miner (less than 16 count) and not the iteration limited CPU miner which worked best at around 100.

I am still mining this and checking up on it now and again because of Proof of burn. I cant find fault in this aspect of slimcoin so in my opinion the currency deserves to live. Its just a shame that the PoW function was not effective in preventing a GPU miner or that that was even promised in the first place. Its also a shame that the PoS aspect is also not working well an that it wasnt completely disabled.

If there is going to be marketing for this coin I would advice directing it towards getting developers interested rather than speculators so that these problems can be addressed and slimcoin can maintain its place as the first PoB cryptocurrency. 

There is a working GPU miner for this currency:

https://bitcointalk.org/index.php?topic=613213.msg10012906#msg10012906

I have mined about 90K SLM with it since the difficulty dropped so there is that...

There are some interesting optimizations in the code, I could not figure it out at first until I had the idea myself: they hash the block header then they setup the index value and iterate it through the hash without creating the internal buffer or scratchpad. When they get to the end they check if the index value aligned (1 in 16 chance) and if it does not then they abort the hash. That means the skip list is never re-hashed for the hashes they do and the count/number of times the scratchpad is hashed is known before hashing the scratchpad to create the buffer. That way they can abort if the buffer would be too big without first filling it up with a very good improvement in speed. Very good job whoever coded the GPU miner Bravo!

A couple of improvements I can suggest would be to hash the half state of the initial hash like bitcoin miners do.

The other improvement idea I have is theoretical (have not tried it) but I will throw it out there: when the scratchpad is re-hashed only 1 byte is changed and the scratchpad always starts off filled with 0xFF and it is always set to a byte that came from a ascii hex digit (only 16 combinations). That means for a count of N there are only N^16 possible hashes for the buffer and since you can progressively hash this you can stop at whatever N you please. What I'm saying is that if you have enough memory you can pre-calculate a fair chunk of the possible buffers then use a lookup table to retrieve the pre-calculated hashes to progressively add the rest of the hash.

Even just calculating the first 4 iterations would mean 2*4 less sha256 blocks per hash with a reasonable amount of memory usage...

I just noticed bter is back up (I dont have any funds on there) is everyone's balance showing up?

https://twitter.com/btercom

"We are preparing for the withdrawals. CNY, USD and NXT withdrawals will be handled first."

looks like they are not trying to screw people...