Pages:
Author

Topic: [ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer! - page 11. (Read 284948 times)

member
Activity: 60
Merit: 10
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...
newbie
Activity: 21
Merit: 0
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.
legendary
Activity: 1092
Merit: 1000
I've got another 160k SLM to dump, someone place a buy order plz  Grin
hero member
Activity: 819
Merit: 502
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
full member
Activity: 141
Merit: 100
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
member
Activity: 60
Merit: 10
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.

full member
Activity: 222
Merit: 103
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.
member
Activity: 98
Merit: 10
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 :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.

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.
member
Activity: 60
Merit: 10
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://bitcointalksearch.org/topic/m.7090075
Will try testing myself on the weekend when I have time to VM some different flavors of windows.
full member
Activity: 222
Merit: 103
looks like someone has a very optimized miner, or a selfhosted pool for a botnet (because there is NO official pools), the Dumps and the Difficulty rise have began in the same time...

The time for the algo change has come. Some popular one or PoS-PoB only.

And yes - it's a good time to buy some SLMs
member
Activity: 63
Merit: 10
yeouch. Whoever is selling em like that is pretty dumb though- doing it gradually would have made em a ton more money
legendary
Activity: 1092
Merit: 1000
full member
Activity: 222
Merit: 103
another big "sale" at BTER for ~ 4 BTC
member
Activity: 98
Merit: 10
Is everyting OK with pool? Last payout was 3 days ago, but blocks are getting found and confirmed...

I was just wondering the same thing.

The pool shares the daemon with the giveaway daemon, but even though I requested an address for "nomp" using getaccountaddress, the SLM seem to be going into the "" account instead. Hmm might be a bug with the client, will look into fixing this.

I've temporarily transferred funds from the "" account to "nomp", but it seems like the past few payouts were lost cos I don't seem to have captured any errors. The current immature blocks should be paid out once they mature.
full member
Activity: 222
Merit: 103
Is everyting OK with pool? Last payout was 3 days ago, but blocks are getting found and confirmed...
member
Activity: 63
Merit: 10
Ah so about 3 weeks- that makes more sense. Good luck Smiley  If you have any issues with the wallet taking stupid amounts of memory you might consider updating to the newer one- it doesn't include staking, but it's more stable and uses fewer resources.

It's the latest one. I activated staking "by hand" and it's running OK for days (even when the VM with it was solomining). It consumes near 200Mb of memory (127M RAM + 82M VM) and zero CPU :-) - it's a VM on a colocation server doing CPU-mine (some free resources) so it's fine Smiley

ah nice Smiley
full member
Activity: 222
Merit: 103
Ah so about 3 weeks- that makes more sense. Good luck Smiley  If you have any issues with the wallet taking stupid amounts of memory you might consider updating to the newer one- it doesn't include staking, but it's more stable and uses fewer resources.

It's the latest one. I activated staking "by hand" and it's running OK for days (even when the VM with it was solomining). It consumes near 200Mb of memory (127M RAM + 82M VM) and zero CPU :-) - it's a VM on a colocation server doing CPU-mine (some free resources) so it's fine Smiley
member
Activity: 63
Merit: 10
There's no bottom limit, but the wallet needs to be open.  Thing is, at this point with 110 burnt you'd get about .5 slim a day, which means about a month for a block on average.


edit: although if you burned them months ago and haven't gotten any PoB blocks, I'm guessing you aren't leaving your wallet running 24/7

It was 16 of October exactly. The wallet is 24/7 and staking OK, will wait and see, thanks!

Ah so about 3 weeks- that makes more sense. Good luck Smiley  If you have any issues with the wallet taking stupid amounts of memory you might consider updating to the newer one- it doesn't include staking, but it's more stable and uses fewer resources.
full member
Activity: 222
Merit: 103
There's no bottom limit, but the wallet needs to be open.  Thing is, at this point with 110 burnt you'd get about .5 slim a day, which means about a month for a block on average.


edit: although if you burned them months ago and haven't gotten any PoB blocks, I'm guessing you aren't leaving your wallet running 24/7

It was 16 of October exactly. The wallet is 24/7 and staking OK, will wait and see, thanks!
member
Activity: 63
Merit: 10
How many SLMs must be burned to start PoB process? Burned for test 110SLMs month ago and still never seen PoB transaction...

There's no bottom limit, but the wallet needs to be open.  Thing is, at this point with 110 burnt you'd get about .5 slim a day, which means about a month for a block on average.


edit: although if you burned them months ago and haven't gotten any PoB blocks, I'm guessing you aren't leaving your wallet running 24/7
Pages:
Jump to: