[ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer!

[jonnylatte]

Anyone want to test my build of https://github.com/kryptoslab/slimminer for windows?

http://www73.zippyshare.com/v/84890173/file.html

If you have the old windows miner please post the difference in has rate and try some different iteration limits with the command-line flag -i on the new miner.

If the miner does not work for you and asks for a dll please post that or whatever problem you have.
I built it on windows 7 using this guide https://bitcointalk.org/index.php?topic=613213.msg7090075#msg7090075
Will try testing myself on the weekend when I have time to VM some different flavors of windows.

[1715052719]

1715052719

[1715052719]

1715052719

[1715052719]

1715052719

[1715052719]

1715052719

[1715052719]

1715052719

[a123]

Wow works like a charm, thanks!

I used it on a relatively clean install of Windows 7 and it still runs; so I suspect it should work for most people.

I've taken the files from Jonnylatte's release and scanned it, and repackaged it into a .7z because somehow Github keeps rejecting the original .zip.

You can get it now from both https://github.com/kryptoslab/slimminer/releases/download/v0.1/Slimmer.7z and http://www73.zippyshare.com/v/84890173/file.html.

For pool purposes, run it using: minerd -o stratum+tcp://www.slimcoin.club:41680 -O <addr>:1

The iteration optimisation is set to 128 as per default (i.e. -i 128). You can vary this to optimise for your platform; faster PCs may benefit from lower iterations and vice versa. The other hex conversion speed-up by JL is already hard-coded in.

<addr> can be generated using the brain wallet if you don't have the client. Go to http://www.slimcoin.club/#wallet, click "Key Generation", type in a passphrase and an address will be generated. All generation is done in-browser and nothing is sent back, but to be sure you can disconnect from the internet when you generate the key and then close the browser window. The slimcoin client will have a built-in brain wallet import RPC for the next release.

[ArchitektoR]

New miner works on XP x64, but the performance is something strange - it's better on my main PC (Xeon-i7 QuadCore), but slower on VM with 12 Cores... Playing with "-i" but still slower or the same.

[jonnylatte]

Its probably the change to the hex code as it uses more memory. I just rebuilt with the old hex lookup but obviously keeping the iteration limit. The improvement for my desktop (core 2 duo) was noticeable (20-30%) so perhaps we need a low power and high power build(s) There could be a middle-ground too with a smaller lookup or the original code unrolled.

The previous build I zipped using the windows built in functionality which could be why github wouldn't take it.

This one I copied out of my vm/build environment onto my pc to zip so make sure to virus scan it as I'm less confident about my web surfing computer being clean.  

http://www17.zippyshare.com/v/94055711/file.html

Edit: needs the dlls from the other download so I have renamed it so you can put it in the same folder.

[iHashFury]

Hello

It taking so long to download the block chain. Is there any other seed nodes or help?

Code:

{
    "version" : "v0.3.2.0-6-gafd8ef7-alpha",
    "protocolversion" : 60003,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "newmint" : 0.00000000,
    "stake" : 0.00000000,
    "blocks" : 150957,
    "moneysupply" : 1634521.19807900,
    "connections" : 6,
    "proxy" : "",
    "difficulty" : 0.18738420,
    "testnet" : false,
    "keypoololdest" : 1415289646,
    "keypoolsize" : 100,
    "paytxfee" : 0.01000000,
    "unlocked_until" : 0,
    "errors" : "WARNING: Checkpoint is too old. Wait for block chain to download, or notify developers of the issue."
}

Code:

addnode=37.187.100.75:41682
addnode=107.181.250.216:41682
addnode=85.10.194.50:41682
addnode=31.28.25.35:41538
addnode=81.207.93.95:61778
addnode=37.187.100.75:38100
addnode=188.226.131.93:41682
addnode=5.9.81.9:41682
addnode=144.76.118.179:53639
addnode=176.31.9.212:64643
addnode=141.48.30.99:37415
addnode=222.95.29.218:37409
addnode=85.58.43.25:3684
addnode=31.19.194.185:55754
addnode=222.95.29.218:13473
addnode=222.95.29.218:27393
addnode=115.132.152.185:49367
addnode=201.232.105.207:41682
addnode=104.228.244.149:54157
addnode=66.229.2.9:57848
addnode=190.252.87.227:41682
addnode=112.113.96.138:53964
addnode=66.228.43.203:35884

[gavrilo77]

My cpu hash rate suddenly decreased ~10 times. have no idea why. Somebody had the same issue?

Have i5 2540, hash rate was 1.5 khash/s, now is 0.15 khash/s. The same value give wallet and miner.

Problem solved. It was adapter issue

[primer-]

I've got another 160k SLM to dump, someone place a buy order plz 

[Mr E]

So, I have had the slimcoin windows QT client crashing again. The specific error is:

Code:

************************
EXCEPTION: St9bad_alloc       
std::bad_alloc       
D:\<***>\SlimCoin\slimcoin-qt-0321.exe in ThreadMessageHandler()      

Immediately before this, there were a very large number of messages of "likely old client, incrementing misbehaviour count", and quite a few "connection timeout" messages. I'm not sure if this is normal or not.

Let me know if you have any suggestions I can try to troubleshoot further.

[jonnylatte]

Are you using this release?

https://github.com/kryptoslab/slimcoin/releases/tag/v0.3.2.1

I have not had any problems using it. How much RAM do you have?

While I'm on the topic of RAM, its possible to completely eliminate the dynamic memory requirements of the dcrypt function:

Code:

#define SHA256_HEX_LEN 64

uint256 dcrypt_progressive(const uint8_t *data, size_t data_sz)
{
	//if(fTestNet) return sha256d(data,data_sz);   // for testnet hashes use sha256d

	SHA256_CTX	ctx;   // sha256 context
	uint256		hash_result;    

	uint32_t    index = 0;
	uint8_t     index_values[SHA256_HEX_LEN +1]; 
	uint8_t     scratch_pad[SHA256_HEX_LEN +1];  

	SHA256_Init(&ctx);	// initialize context which will progressively hash the result as data for it is generated in scratch_pad

	sha256_to_str(data, data_sz, index_values);    // initialize index_values with sha256(data) -> ascii/hex
	memset(scratch_pad, 0xff, SHA256_HEX_LEN);     // initialize scratchpad all 0xff 

 	do
	{
		index += hex_char_to_int(index_values[index]) + 1; // increment index by the value of the hex char in index_values and add 1 so index is always increasing

		if(index >= INDEX_BUFFER_LEN) // if index is past index_values size, wrap index around and scramble index_values
		{
			index &= 0x3f;	// wrap index around
			sha256_to_str(index_values, INDEX_BUFFER_LEN, index_values); //rescramble with sha256(index_values) -> ascii/hex
		}

		scratch_pad[SHA256_HEX_LEN] = index_values[index]; //set a byte in scratch_pad to index_values[index]
		sha256_to_str(scratch_pad, SHA256_HEX_LEN + 1, scratch_pad); // sha256 hash 

		SHA256_Update(&ctx,scratch_pad,SHA256_HEX_LEN); // write scratch_pad to the sha256 context that will generate the resulting dcrypt hash
	}
	while( (index != SHA256_HEX_LEN - 1) || (index_values[SHA256_HEX_LEN - 1] != scratch_pad[SHA256_HEX_LEN - 1] )); 
	// loop ends when index is at "SHA256_HEX_LEN - 1" and the value of index_values matches the value of scratch_pad at that location
	// this should have a 1 in 16 chance for every time index happens to hit "SHA256_HEX_LEN - 1" 

	SHA256_Update(&ctx,  (u8int*)data,data_sz); // write the original data to the sha256 context for the resulting hash
	SHA256_Final((u8int*)hash_result, &ctx);	// finalize the hash and store the result

	return hash_result; // we are done here
}

Instead of building up a buffer and hashing it at the end this version progressively hashes the data generated. Sha256 contexts have an internal buffer which is of fixed size. So it seems dcrypt was never memory hard except for the fact that you can get a minor optimization with hashing by buffering the data instead of hashing progressively and then aborting if the resulting buffer gets too big. The optimization is not that you are saving memory or preventing too much memory use, its that you are not hashing longer buffers saving the processing of the large data. This is probably why there isnt a spectacular increase in efficiency by limiting the number of iterations (you are only really saving one sha256 call on the larger buffer but still wasting many small calls for calculating the scratchpad and index values)

In any case I think this version of Dcrypt algorithm might be better for the main client to prevent too much resource usage while we wait on the possibility of a change in hash functions.

I dont think its bad that Dcrypt has fixed memory usage. I hope my code is a clear implementation that could be of help to someone writing a GPU miner which I now believe should not be too difficult to implement (the problem is now variable computation time instead of variable memory usage) If we have a GPU miner then it will be much harder for a botnet or server farm to compete and if we can do it with dcrypt then changing the hashing function is less important...

[Mr E]

Are you using this release?

https://github.com/kryptoslab/slimcoin/releases/tag/v0.3.2.1

I have not had any problems using it. How much RAM do you have?

Yes, I just downloaded it again and confirmed that the files are identical, so that's the version I've been running.
I've got 8GB of RAM, but also a number of other things running at the same time, so memory could be the issue. In particular I have noticed a couple of times it crashed right at the moment I launched another program (in one case a VM, in the other, Minecraft).

I might try a few more experiments along this line and see what happens...

[jonnylatte]

You could also check to see if you have enough virtual address space.

It seems this problem was solved for bitcoin since 0.9.0 by restricting the number of orphan blocks that are stored.

[gavrilo77]

Is it speed 1.5 khash normal for i5-2540M?

[pantheist]

So I know it's a lot of work, but if you have time could you keep us updated on what you're working on?  Especially since this was already abandoned by one developer, I think keeping people updated on progress could do a lot for interest in the coin.

[Mr E]

So I know it's a lot of work, but if you have time could you keep us updated on what you're working on?  Especially since this was already abandoned by one developer, I think keeping people updated on progress could do a lot for interest in the coin.

Well, for what it's worth, I'm hoping to work on implementing the 'coin control' features from the current bitcoin core into slimcoin as time permits. Don't expect it in a hurry, though, as I'm still wrestling with getting my build environment to work properly.

I don't know anything about what a123 is working on.

Is it speed 1.5 khash normal for i5-2540M?

Well, it sounds around the right size. With the standard GUI client, I get around ~ 0.5khash/sec per core on a 3GHz core2.



PS - so my slimcoin-qt has been stable for the last few days; and I haven't been using that computer a lot over that time. Coincidence?    guess I'll find out over the weekend, since I'll be using it more again.

[ArchitektoR]

The pool does not accept connections, what's the problem?

[jonnylatte]

a123 Messaged me saying he would review my code but that he is currently away on a cruise with limited internet access which is unfortunate timing with the pool.

Anyone still working on p2pool?

[luckyboho]

The coins that are burnt are forever gone. They are compensated by the proof of burn blocks that are generated as a result of the burning. That destruction of coins is why the coin cap is set to be as high as it is.

[jonnylatte]

https://i.imgur.com/f58pg0U.png

This is just a hint about something I may be working on. No time-frame available but I will update here when code that does things gets connected to code that talks to things.

[ArchitektoR]

GPU miner? - GOOD, GOOD!!

[primer-]

Hehe, the sheeple are regrouping