Topic: Slimcoin | First Proof of Burn currency | Decentralized Web - page 156. (Read 137076 times)

Slimcoin wll be delisted from multifaucet.tk
Reason - too many problem with this daemon.

What is the current stable Linux wallet? - Now moving PoS/Depo VM from WinXP to Debian - and SlimCoin is the last one. And how about stability - does the block stuck problem solved?

And yes - can add some bounty in SLM. For fixing Windows wallet when solomining at least. Maybe - for a working pool solution.

This is not a "we will do 99999+ super improvements .... and then cash out" coin. People should look at it as a financial experiment.

Slimcoin has already a working Proof of Burn system. That is a major innovation. Really. And it works fine so far.

The problem is that some client versions have glitches (Windows QT client) and that the code is now pretty old. There was some work in August by gjhiggins on a newer codebase for SLM but since then I haven't seen new commits.

I am currently thinking about a more attractive bounty system, so wealthy slimcoiners can sponsor development more easily. Slimcoin has currently no own crowdfunding mechanism. Perhaps we can use NXT (they have done a similar thing with the Tennesee project) or Counterparty for this purpose.

I would like to remember all devs reading here that there are two bounties currently:

- 20.000 SLM for fixing the Windows wallet.
- 20.000 SLM for a "electrum-like" light wallet.

It's true, regarding the actual price that are not big bounties, but if we can fix the wallet, the major problem for a more massive adoption would have been solved.

@hankrules: I'll try out the brain wallet to see if it's working.

There are future plans for slimcoin?

Does the brain wallet on slimcoin.club work?

I have followed this coin since its launch. However I have stopped for a while due to no dev, I hope that this coin will improve and I will be back on it as soon as possible 

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.

Here is the JonnyLatte minerd compiled in MinGW64.

.bat
minerd.exe -a dcrypt -o 127.0.0.1:41684 -O user:password -t 2 --hashtable=4

With hashtable 5 my minerd crash. With 4 works very nice.

https://mega.nz/#!KttQjaRK!RCO2NeGe8U5fIgdm0i3Lp6I-FVYjSmqPXDntgI7z1yM. I have core2duo. Hashrate is up to 10 khash/s, depend if i am using PC or not.

Cheers

edit: I am testing a few days already. On laptop, windows 7 32x, cpu i5, 4 GB RAM, compiled with cygwin, i am getting the best 19 khash/s. Number of threads 3, hash table 5. Same compiled with cygwin on my desktop, windows 10, 8GB RAM core2duo, i am getting 13 khash/s. Little strange i was expecting i will get quite better result with i5 than dual core. Anyhow work is very stabile, but if you have some parallel work which use CPU, hash rate is decreasing. I am mining solo on the wallet 3.2.1. Found plenty of blocks.

I have noticed that my i5 CPU is busy only 30 %. Is there a way to increase usage of CPU by miner. I guess hash rate should be better than.

@gjhiggins: Do you remember which of your commits is the last usable 0.3.2 version? It would be good to link to it directly in the OP.

I have still not found any PoB blocks with the 0.4.1 wallet. So I changed back to 0.3.2, for now. Johnnylatte has posted the bug at Reddit, I will now start a Github issue item for it.

The Qt config file for that repos has been edited to be Windows-specific and INCLUDEPATH needs changing for Linux compilation:


HTH

Cheers

Graham

How do I get 3.2.1?

I compiled from source from this git: https://github.com/slimcoin-project/slimcoin

I tried to compile kryptoslab's version but it just fails with:

Soruce used:
git clone https://github.com/kryptoslab/slimcoin

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

I'm having some trouble solomining.
It seems to connect OK to slimcoind but it fails when it finds a hash.

@johnnylatte: I have now added your version of slimminer to the OP, marked as experimental. Thanks for your work!

I have still not minted anything with the client 0.4.1, so it's pretty probable that there is a bug somewhere. Has someone minted a block with PoB or PoS with the experimental 0.4.1 version or are all getting the errors johnnylatte has reported?

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://bitcointalksearch.org/topic/m.7090075

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. 

The Slimminer link in the OP is updated now to Kryptoslab's version (from October 2014). I can also include johnnylatte's version, if it works as expected.

Basically, the Slimcoin source code can be compiled the same way as Bitcoin's source code, at least using Linux. The dependencies are the same. I have compiled several Linux command line versions without problems and the process is straightforward (make -f makefile.unix / make install). So you can use anyone of the available Bitcoin compilation tutorials, or look for a Peercoin tutorial as PPC is the direct predecessor of SLM.

Hey any chance you can do a write up on how to compile the slimcoin source code?
I need it to be able to solo mine.

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.