Active slimcoin twitter: https://twitter.com/SlimcoinProject

Configured the P2Pool, and added the custom Proof of Burn block headers, but got it stuck at the get_block_header polling phase. Apparently the block header for SLM isn't hashed by sha256 but by Dcrypt? Don't think this was supposed to be the case according to the SLM whitepaper, since Dcrypt for hashing block headers would be unnecessarily intensive, will look into it further and propose changes for the upcoming hard fork if necessary.

Also glad to report that Slimcoind has also been running smoothly on the Raspberry Pi for the past 3 days, no crashes, using only 106MB out of the 496MB total. Load average between 0.2 to 0.4. Out of the 49152 coins I burnt, 236 has already decayed. But that produced 2093 coins, so that still seems quite productive.

Think we need a burn calculator of sorts, to get a sense of the ROI. Will work on it, though anyone is keen or exploring the idea or have already built one?

The mine pool built what time

Did you resync from the start, jade ?


50k SLM burnt? LOL quite a number of burning money.
I will ask my friend dcct about the ROI calculator for PoB.

I sent him 300SLMs for his explorer work and if you could send him some for the bounty he will be happy about this. SLM is one of hidden gems in cryptoworld now. Let's us accumulating alot more before it explodes

I believe I've managed to chase down the bug causing transactions to show up as "Mint by burn" when they actually weren't.

The code that did up the transaction list checked whether the transaction was in a PoB block, but forgot to check whether it was the coinbase transaction, with the result that all transactions in PoB blocks would show up as "Mint by burn". I'm not quite sure why the incorrect amount appeared in the list -- but try my patch and see if it fixes the GUI bug. (Or if you don't have a gui environment to test it on, I can do it if you compile an updated windows client. Haven't got a build environment of my own yet...)

(BTW, it looks like even the check for PoB block is kind of hacky -- the check for PoS blocks calls a wtx.IsCoinStake() function, but the check for PoB is implemented as a boolean flag passed in to the function by the caller... kind of ugly...)

Hmm I was quite hoping it is truly resistant to GPU mining, similar to how Cryptonite has almost very little advantage over CPUs (assumption based on http://cpucoinlist.com/). Anyone has any insights on how Dcrypt holds up? Being a CPU-only coin has a certain appeal, and it might not be too late to switch to another algo in time for the fork.


Awesome! I'm testing it out right now, am spamming myself with 0.01 SLMs in hope of catching a PoB block. I'll PM you on regarding the Amazon EC2 build environment I compiled the Slim-Qt on

Not insight, but from the whitepaper:

It goes into more detail that quickly becomes beyond my comprehension   http://www.slimcoin.club/whitepaper.pdf

Difficulty is rising, it's back at what it used to be when the pools were active.

Are there any pools now? If this difficulty is done without ANY pool then it's insane!

"difficulty" : 0.20134940,

PS: I have a large amount of burn coins as well, over 2% of the total amount, but that is because i never stopped mining and when the diff was low i got many

"Net Burnt Coins" : 8074.81369400,
"Effective Burnt Coins" : 7389.20701100,
"Immature Burnt Coins" : 111.67010000,
"Decayed Burnt Coins" : 523.93658300

Coolio. Update my nodes without a hitch. Good progress.

~ Raspberry of approval from our mascot