That is, no pool can only solo mining?
You are strong, you will come up is not it? All the miners will thank you.
hmm, from what I read, it says anyone mining this coin at the moment is getting screwed by dev You are strong, you will come up is not it? All the miners will thank you.
(miner or not not a good coin to mine)
Or the dev is not sufficiently careful to be trusted with your money, either way.
The quote from ypool is correct. The hash function throws away half of the intermediate state generated by the first sha256:
sha256(block stuff) --> hash1
twister(half of hash1) --> hash2
sha256(hash2) --> hash3
Thus, it's really only a 128 bit hash, not a 256 bit hash -- there are only 2^128 possible inputs to the second sha256, and thus, only 2^128 possible outputs. Numerically, this is probably not a critical weakness, but it's incredibly uncareful design. It also means that there are all sorts of ways to optimize the hash function well beyond what's in the built-in miner.
If you go beyond that, Twister was rejected from the sha3 competition for having substantial flaws. That doesn't outright make it inappropriate in a PoW function, but it should raise substantial questions -- all other features being equal, I would consider a coin that did sha256(), x(), sha256() slightly better if it used a stronger hash function for 'x' than one that seemed like it was already going down the path of having some cryptographic weaknesses. There's no reason to think that Twister makes this weaker than just dual sha256, but it should raise serious questions about the purpose for the coin's existence.
This is a technically poor coin / PoW design.
GROUNDLESS ACCUSATIONS!
and I do not think there is any flaw in my code.
I do not think the word "groundless" means what you think it does. Allow me to more concretely ground my statements so that you might understand them better:
- Wallet source code showing the code as I copy/pasted it:
https://github.com/tlas/tlascoin/blob/41921a44f7cc504d2c2d114edef026a58c1b43f7/src/hash.h#L17
Hasht1( 256, (const unsigned char*)hash1.ToString().c_str(),256, hashval );
You call ToString(), which creates a 64 byte hex representation of the hash. You then pass it to Hasht1, specifying a length of 256 bits (32 bytes).
The second claim I made was that Twister was rejected as a SHA3 candidate. Citation:
http://en.wikipedia.org/wiki/NIST_hash_function_competition
"The following non-conceded Round One entrants have had substantial cryptographic weaknesses announced"
... Twister ...
Which of these statements do you believe to be factually incorrect?
But the last round SHA256 ensure the safety.
Only half the "safety" because your entropy is halfed.
If i throw char[2] into sha256(), it aint safe! (as example)
Your weakening sha256 by this.
PS: there is still a pull req which you can/should accept
