Slimcoin | First Proof of Burn currency | Decentralized Web

[3429z781678124]

Did you download the blockchain with the same Linux version or via Wine/Windows?

New git-repository: I started syncing on Windows 10 with Slim236000.7z from http://www.slimcoin.club, on ubuntu 14.04 with an existing blockchain from slimcoin-0.3.2.1. Syncing from scratch not tested.

Syncing from scratch and fully compiling (slimcoind & slimcoint-qt) works for me on ubuntu 14.04 with slimcoin-0.3.2.1 source from kryptolab.

[vladin79]

I have successfully synced on Windows 7 with Slim236000.7z. I am now using slimcoin-qt v.0.3.2.1-alpha as a server and I am using pooler-cpuminer-2.4.2-win64 to mine. The miner is running for several hours now, but still hasn't mined anything.

Do you know what is the probability to mine something? For how long the miner has to be running in order to mine something? I am asking this in order know if I am doing something wrong or just the chances to mine something are too low. Here is the output from the miner:

Code:

[2015-08-23 10:36:54] thread 1: 3576 hashes, 5.13 khash/s
[2015-08-23 10:36:55] thread 3: 4776 hashes, 3.63 khash/s
[2015-08-23 10:36:55] thread 0: 4572 hashes, 3.18 khash/s
[2015-08-23 10:36:55] thread 2: 20424 hashes, 3.25 khash/s
[2015-08-23 10:36:58] thread 0: 12720 hashes, 4.36 khash/s
[2015-08-23 10:36:58] thread 2: 13020 hashes, 4.36 khash/s
[2015-08-23 10:36:58] thread 3: 14520 hashes, 4.28 khash/s
[2015-08-23 10:36:59] thread 0: 4368 hashes, 4.93 khash/s
[2015-08-23 10:36:59] thread 2: 4368 hashes, 5.28 khash/s
[2015-08-23 10:36:59] thread 3: 4284 hashes, 4.89 khash/s

And this is the info from the slimcoin:

Code:

{
"version" : "v.0.3.2.1-alpha",
"protocolversion" : 60003,
"walletversion" : 60000,
"balance" : 0.00000000,
"newmint" : 0.00000000,
"stake" : 0.00000000,
"blocks" : 425503,
"moneysupply" : 5013898.67464500,
"connections" : 3,
"proxy" : "",
"ip" : "115.132.153.249",
"difficulty" : 0.01776730,
"testnet" : false,
"keypoololdest" : 1440253104,
"keypoolsize" : 102,
"paytxfee" : 0.00000000,
"errors" : ""
}

Also, are there any working pools at the moment?

[d5000]

Have you resolved your problem? Unfortunately I'm not into mining, so I can't answer your question. You may be on a fork, perhaps check https://bchain.info/SLM/ and compare the block hashes with yours. I also don't know if there is a working pool, but I don't think so, as the last posts all were about solo mining.

My Linux client gets stuck at block 422195, so that seems to be other "critical" block. Until now I had no luck with the Windows client via Wine and I don't know what i'm doing wrong  as it has worked other times.

If someone can provide me a blkindex.dat after block 425000 or so (according to gjhiggins it should be sufficient to sync), it would be very helpful

[hashmaster3000]

Hi,

I have uploaded a copy of my blkindex.dat and blk0001.dat here:
http://en.file-upload.net/download-10868526/slimcoin_blockchain_blk429503_89e2ef43.7z.html
SHA256: 7dfc6146e8a988477b8827864502ed8521b25775e111ff3fb41b4c1f1545e269

It's synced up to block 429503.

[vladin79]

Last night the client was stuck at block 427046 forever. This morning it successfully synced to the newest block. I suppose these sticks are completely random and maybe depend on some state of the network.

I have uploaded a full snapshot of my synced database up to block 429986 here:

http://en.file-upload.net/download-10869903/Slim429986.7z.html

Also, I have noticed, that without an actual log file in the database folder, corresponding to the current blk0001.dat and blkindex.dat files, the client gives database error when started.

I am running slimcoin-qt client v.0.3.2.1-alpha on Windows 7 64 bit.

I still haven't mined anything. Can someone, which is successfully mining, please tell me if I am using the right miner (pooler-cpuminer-2.4.2-win64) and if the outputs from the client and from the miner are normal?

This is the info from the slimcoin client:

Code:

{
"version" : "v.0.3.2.1-alpha",
"protocolversion" : 60003,
"walletversion" : 60000,
"balance" : 0.00000000,
"newmint" : 0.00000000,
"stake" : 0.00000000,
"blocks" : 430041,
"moneysupply" : 5083088.29537200,
"connections" : 4,
"proxy" : "",
"ip" : "46.10.159.50",
"difficulty" : 0.00341642,
"testnet" : false,
"keypoololdest" : 1440740142,
"keypoolsize" : 101,
"paytxfee" : 0.00000000,
"errors" : ""
}

This is the output from the miner:

Code:

[2015-08-28 10:04:28] 3 miner threads started, using 'scrypt' algorithm.
[2015-08-28 10:04:28] DEBUG: got new work in 10 ms
[2015-08-28 10:04:28] thread 0: 4104 hashes, 15.66 khash/s
[2015-08-28 10:04:28] thread 2: 4104 hashes, 14.05 khash/s
[2015-08-28 10:04:28] thread 1: 4104 hashes, 13.82 khash/s
[2015-08-28 10:04:33] thread 2: 70272 hashes, 16.11 khash/s
[2015-08-28 10:04:33] DEBUG: got new work in 141 ms
[2015-08-28 10:04:33] thread 1: 69096 hashes, 15.10 khash/s
[2015-08-28 10:04:38] thread 2: 80568 hashes, 16.21 khash/s

[d5000]

Thanks hashmaster3000 and vladin79! I was now able to sync again with the Linux 0.4.1-alpha client. Will observe if there are any more issues.

Last night the client was stuck at block 427046 forever. This morning it successfully synced to the newest block. I suppose these sticks are completely random and maybe depend on some state of the network.

It seems that the "windows sync problem" and the "linux sync problem" are different issues. The Windows client seems to get stuck at random blocks and eventually will continue syncing. But the Linux client gets stuck every time on the same block and won't continue to sync, so - as gjhiggins has already pointed out - the only way to download the last blockchain is to use a windows client to download the "critical" blocks or a recent blockchain snapshot.

Yes and it's true that the linux client will throw database errors (and won't start) if the files in the database folder are not present or out of date. So blkindex.dat alone is not enough to sync, at least for me.

[jonnylatte]

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?

[d5000]

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?

I have not found a PoB block since I changed finally to version 0.4.1 (~2 weeks ago), but I think it is too early to draw conclusions as I have relatively few coins burnt (and I am not mining or PoS minting). Until now, syncing with the 0.4.1 Linux command line client works fine - I had no crash nor got stuck since then.

When I find a block I'll report it here.

[Monty81]

Not familar with "proof of burn" I thought it was a joke first of all anyway im going to research into this further and hopefully it has some potential to overtake pos and pow.

[forevernoob]

I cannot get the slimminer to compile under linux.
I get stuck when trying to ./configure

I have all required dependencies I think.

Code:

checking for SHA256_Init in -lcrypto... no
configure: error: SHA256_Init was not found in openssl

[jonnylatte]

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

Code:

HTTP request failed: The requested URL returned error: 500 Internal Server Error
[2015-09-13 08:49:02] submit_upstream_work json_rpc_call failed

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.

[jonnylatte]

I cannot get the slimminer to compile under linux.
I get stuck when trying to ./configure

I have all required dependencies I think.

Code:

checking for SHA256_Init in -lcrypto... no
configure: error: SHA256_Init was not found in openssl

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

[zodiac3011]

slimminer windows got corrupt header

[jonnylatte]

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

[zodiac3011]

downloaded from OP LOL, I went to github link and downloaded the good version already LOL anyway thanks

[forevernoob]

I cannot get the slimminer to compile under linux.
I get stuck when trying to ./configure

I have all required dependencies I think.

Code:

checking for SHA256_Init in -lcrypto... no
configure: error: SHA256_Init was not found in openssl

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

Thanks - libssl-dev was missing from my system. (Debian)

But I compiled kryptoslab's version instead it's the best slimcoin miner right?

[forevernoob]

So it seems like all the slimcoin pools are dead right?
How do I solo mine with minerd?

[jonnylatte]

So it seems like all the slimcoin pools are dead right?
How do I solo mine with minerd?

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.

[jonnylatte]

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.

[forevernoob]

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.

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.