Search content
Sort by
Showing 20 of 29 results by oveeps
Re: [ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer!
I'm beginning to think dcrypt is no longer a CPU-only algorithm, judging by the concentration of hashpower of the past few days in a few addresses. we might need to come up with a new one hmm. as someone mentioned recently, the assumption of the unbounded scratch space is not true (i.e. you only need a small fixed amount of memory if you are willing to make certain trade offs), and it's operation intensive rather than memory intensive.
A little more fiddling around and I have gotten about a 20% speed improvement by aborting the hash function at count = 120. What makes my eye twitch a little is that I can get a 30% speed improvement on top of that by re-writing
void digest_to_string(u8int *hash_digest, u8int *string)
in
https://github.com/slimcoin/slimminer/blob/master/dcrypt_sha256.c
to
Code:
char * byte_to_hex =
"000102030405060708090a0b0c0d0e0f"
"101112131415161718191a1b1c1d1e1f"
"202122232425262728292a2b2c2d2e2f"
"303132333435363738393a3b3c3d3e3f"
"404142434445464748494a4b4c4d4e4f"
"505152535455565758595a5b5c5d5e5f"
"606162636465666768696a6b6c6d6e6f"
"707172737475767778797a7b7c7d7e7f"
"808182838485868788898a8b8c8d8e8f"
"909192939495969798999a9b9c9d9e9f"
"a0a1a2a3a4a5a6a7a8a9aaabacadaeaf"
"b0b1b2b3b4b5b6b7b8b9babbbcbdbebf"
"c0c1c2c3c4c5c6c7c8c9cacbcccdcecf"
"d0d1d2d3d4d5d6d7d8d9dadbdcdddedf"
"e0e1e2e3e4e5e6e7e8e9eaebecedeeef"
"f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff";
void digest_to_string(u8int *hash_digest, u8int *str)
{
register int si = 0;
register int i = 0;
for(; i < SHA256_DIGEST_LENGTH; i++)
{
memcpy(str+si,byte_to_hex + hash_digest[i]*2,2);
si+=2;
}
str[SHA256_LEN] = 0;
return;
}
Which gets rid of the expensive branch and shift operations and just replaces it with a lookup / copy. This function converts a sha256 digest (32 bytes) to a lower case hex string. This is called inside the mixer function every time the internal buffer expands because for some reason they couldn't have used just the byte values (wtf: where they intentionally making it resource intensive in a way that can easily be optimized away?) which means tens to thousands of times per hash.
I'm not a great programmer but thats why I'm a little concerned that I could get such a significant speed improvement. I'm sure someone who knows what they are doing could do much better.
I'm not saying the dcrypt function should be replaced. Thats up to you guys but from my perspective it seems like it was knocked together just to be a different but probably wont stay CPU only if it isn't GPU mined already. I think the important aspect is Proof of Burn not what hashing algorithm you use. As far as a fair distribution is concerned I think dcrypt has done its job and even if an ASIC is made for it eventually it wont be broken completely until sha256 is.
Re: [ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer!
I'm beginning to think dcrypt is no longer a CPU-only algorithm, judging by the concentration of hashpower of the past few days in a few addresses. we might need to come up with a new one hmm. as someone mentioned recently, the assumption of the unbounded scratch space is not true (i.e. you only need a small fixed amount of memory if you are willing to make certain trade offs), and it's operation intensive rather than memory intensive.
A little more fiddling around and I have gotten about a 20% speed improvement by aborting the hash function at count = 120. What makes my eye twitch a little is that I can get a 30% speed improvement on top of that by re-writing
void digest_to_string(u8int *hash_digest, u8int *string)
in
https://github.com/slimcoin/slimminer/blob/master/dcrypt_sha256.c
to
Code:
char * byte_to_hex =
"000102030405060708090a0b0c0d0e0f"
"101112131415161718191a1b1c1d1e1f"
"202122232425262728292a2b2c2d2e2f"
"303132333435363738393a3b3c3d3e3f"
"404142434445464748494a4b4c4d4e4f"
"505152535455565758595a5b5c5d5e5f"
"606162636465666768696a6b6c6d6e6f"
"707172737475767778797a7b7c7d7e7f"
"808182838485868788898a8b8c8d8e8f"
"909192939495969798999a9b9c9d9e9f"
"a0a1a2a3a4a5a6a7a8a9aaabacadaeaf"
"b0b1b2b3b4b5b6b7b8b9babbbcbdbebf"
"c0c1c2c3c4c5c6c7c8c9cacbcccdcecf"
"d0d1d2d3d4d5d6d7d8d9dadbdcdddedf"
"e0e1e2e3e4e5e6e7e8e9eaebecedeeef"
"f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff";
void digest_to_string(u8int *hash_digest, u8int *str)
{
register int si = 0;
register int i = 0;
for(; i < SHA256_DIGEST_LENGTH; i++)
{
memcpy(str+si,byte_to_hex + hash_digest[i]*2,2);
si+=2;
}
str[SHA256_LEN] = 0;
return;
}
Which gets rid of the expensive branch and shift operations and just replaces it with a lookup / copy. This function converts a sha256 digest (32 bytes) to a lower case hex string. This is called inside the mixer function every time the internal buffer expands because for some reason they couldn't have used just the byte values (wtf: where they intentionally making it resource intensive in a way that can easily be optimized away?) which means tens to thousands of times per hash.
I'm not a great programmer but thats why I'm a little concerned that I could get such a significant speed improvement. I'm sure someone who knows what they are doing could do much better.
I'm not saying the dcrypt function should be replaced. Thats up to you guys but from my perspective it seems like it was knocked together just to be a different but probably wont stay CPU only if it isn't GPU mined already. I think the important aspect is Proof of Burn not what hashing algorithm you use. As far as a fair distribution is concerned I think dcrypt has done its job and even if an ASIC is made for it eventually it wont be broken completely until sha256 is.
Re: [ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer!
Ok gotta go to bed, didn't manage to clean up the code yet. Will post up the updated submitblock code soon!
The lack of new function, lack of marketing, hope a123 go ahead!，I have always been optimistic about this coin！！ 
Re: [ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer!
Did not produce a block 
Re: [ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer!
So I know I could make a spreadsheet to figure this out, but I love the convenience of the burn calc on slimcoin.club - any chance you could add something that says how many days until you break even and how many effective coins will be left on that date?
A few assumptions made: difficulty unchanged from last PoB, no new burnt coin.
For 10000 SLMs burnt, it will show
Quote
83.025724 SLMS GENERATED PER DAY, 14.27 SLMS DECAYED, 120 DAYS TO BREAKEVEN, 8425.162778 BURNT COINS LEFT AT BREAKEVEN
Do you know if the rate of decay changes as a function of increased difficulty?
Decay is a fixed constant that depends on the number of PoW blocks generated since burn: 1.00000198 per PoW block, burnCoins = nCoins / pow(BURN_DECAY_RATE, depthInChain);
For the slimcoin.club calculator, I just assumed 720 blocks per day are PoW (i.e. 3 PoW and 1 PoB), and thus I hard-coded the decay per day is 1.00000198 ^ 720 = 1.001427...
Re: [ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer!
I'm at 35k now.. will take some time..
you can grab the blockchain snapshot from https://github.com/kryptoslab/slimcoin/releases up, it goes up block 126100!
i also just finished setting up the NOMP @ stratum+tcp://www.slimcoin.club:41680, just to see what are the problems faced by pool makers. a lot of issues! particularly cos our client is an old pp fork which doesn't handle batch RPC, and I had to write a RPC proxy from scratch just for that. don't know whether it works cos i don't have that kinda hash power to claim a block, you guys can just try it out and see if it works
looks like a next todo is to port dcrypt and pob to the peercoin devel github tree.
(not claiming first pool, will help with pool setup if ocminer or any exp pool owners are using nomp)
Re: [ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer!
Hey guys,
whats the maximum block height currently ?
We need to pool whats the maximum block height currently ?
I'm building one, but I need to download the whole blockchain before.. i'm on block 3300 now
Waiting for a long time. Re: [ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer!
Hey guys,
whats the maximum block height currently ?
We need to pool whats the maximum block height currently ?
Re: [ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer!
I noticed you guys got a mention on CryptoPromote .... If you want, I can look into doing an article on the coin for CryptoArticles.com?
Just PM me with the most important details (except what's in the OP of course) and I'll get it done somewhere this week....
Thank you, this is a good news to inspire people.Just PM me with the most important details (except what's in the OP of course) and I'll get it done somewhere this week....
Re: [ANN][DOGE] Dogecoin - very currency many coin - v1.7 Available
http://www.dogeparty.io/assets/images/dogeparty@2x.png
Dogeparty XDP burn begins in less than 60 minutes!
Go here for details:
http://www.dogeparty.io/
Official thread here:
https://bitcointalk.org/index.php?topic=737231
Good idea Dogeparty XDP burn begins in less than 60 minutes!
Go here for details:
http://www.dogeparty.io/
Official thread here:
https://bitcointalk.org/index.php?topic=737231
