[TLS] Tlascoin | CPU| POW / NEW Twister algo | NO PREMINE| Exchange

[MisO69]

So, tlas -

What I want to know is:  Did you do it on purpose, or were you too busy creating a stream of crapcoins to be careful enough?

elaborate please ... 

Let's make it a homework question.  Here's the hash code from tlas, stripped down a little.  What's the bug?

    SHA256((pbegin == pend ? pblank : (unsigned char*)&pbegin[0]), (pend - pbegin) * sizeof(pbegin[0]), (unsigned char*)&hash1);

    BitSequence hashval[32];
    Hasht1( 256, (const unsigned char*)hash1.ToString().c_str(),256, hashval );
    uint256 hash2;
    SHA256((unsigned char*)&hashval, sizeof(hashval), (unsigned char*)&hash2);
    return hash2;

Hint - here's the function prototype for Hasht1.  Following the NIST standard API, all lengths are in bits:

HashReturn Hasht1(int hashbitlen, const BitSequence *data,
                DataLength databitlen, BitSequence *hashval);

So this coin is broken? in what way? Please explain in English.

Thanks.

[archit]

So, tlas -

What I want to know is:  Did you do it on purpose, or were you too busy creating a stream of crapcoins to be careful enough?

elaborate please ... 

Let's make it a homework question.  Here's the hash code from tlas, stripped down a little.  What's the bug?

    SHA256((pbegin == pend ? pblank : (unsigned char*)&pbegin[0]), (pend - pbegin) * sizeof(pbegin[0]), (unsigned char*)&hash1);

    BitSequence hashval[32];
    Hasht1( 256, (const unsigned char*)hash1.ToString().c_str(),256, hashval );
    uint256 hash2;
    SHA256((unsigned char*)&hashval, sizeof(hashval), (unsigned char*)&hash2);
    return hash2;

Hint - here's the function prototype for Hasht1.  Following the NIST standard API, all lengths are in bits:

HashReturn Hasht1(int hashbitlen, const BitSequence *data,
                DataLength databitlen, BitSequence *hashval);

So this coin is broken? in what way? Please explain in English.

Thanks.

From the discussion on YPool

[13:39] archit: @squaggle You really like giving homework, tlas coin page
[13:56] shotuser: @squaggle 3rd argument to hash1 shouldn't be integer, prototype says its of type 'DataLength' whatever that is
[14:12] squaggle: @archit I know. It's a terrible occupational hazard.
[14:12] curiouser: @squaggle 3rd argument to hash1 should be 512, not 256
[14:12] squaggle: @shotuser minor nit. there's a really serious stupidity.
[14:12] squaggle: @curiouser You get the prize.
[14:13] squaggle: And, more generally, that hash function is a speed benchmark of sprintf.
[14:13] curiouser: yeah seems pretty silly
[14:13] squaggle: sprintf is called 32 times every iteration of the loop.
[14:14] curiouser: not a very nice way to wake me up, though
[14:14] squaggle: *grin*
[14:16] shotuser: ha i got the right arg at least ;p still clueless without checking the source why it should be 512 instead of 256
[14:16] squaggle: It's called "how to convert a 256 bit hash function to a weak 128 bit hash function with HUGE slowdown" - a nice way to have a private miner that runs 100x faster than anyone else's without a lot of work.

So the inbuilt miner is critically broken.

[solocoin]

That is, no pool can only solo mining?

You are strong, you will come up is not it? All the miners will thank you.

[djm34]

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 
(miner or not not a good coin to mine)

[archit]

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 
(miner or not not a good coin to mine)

pool mining isn't hard, the dev is screwing you all

[K1773R]

WTS 10K TLS for 0.2 BTC for all.

Fablio2 is bad trader, We talked business about 0.1 BTC = 10K LTS, and I send he 0.1 BTC, now he just selling my 2500 LTS,

and he returned my 0.075 BTC, Bad faith!

use the trust system and mark him as scammer

[dga]

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 
(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.

[titancoin]

this is nice coin,but why no have miner and pool,where hava much of the programmer?

[tlas]

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 
(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.

[titancoin]

if any flaw in this coin code,this coin will be the only one solo coin!!!so interesting！！！！

[audrey-chicka]

I can´t connect. Did the settings change?

[dga]

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 
(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?

[tlas]

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 
(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.

[dga]

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 
(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.

My original post was very clear about this:

"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."

Please go re-read my critique and think about it before responding in anger.  As the English phrase says, "don't shoot the messenger" -- it is not my fault that your code has flaws.  As the developer, it is YOUR responsibility to ensure both the implementation and cryptographic security of your coin.  If you're unwilling to do that, your coin should not exist.

[tamdc]

Dual E5-2620

{
"blocks" : 2978,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.21028127,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"hashespersec" : 36181,
"networkhashps" : 11331382,
"pooledtx" : 0,
"testnet" : false
}

[K1773R]

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  
(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

[spicelord]

http://crypto-cartel.com/tlascoin-tls-cpu-currently-coin-twister-algo/
Put a post up on my blog about the coin. It's not much but we're all trying.
Donations appreciated  TCHzpNCFjtW6XAiuJnc9pUgVhMVwMPi6zX

[AfrikaMan]

[14:13] squaggle: And, more generally, that hash function is a speed benchmark of sprintf.
[14:13] curiouser: yeah seems pretty silly
[14:13] squaggle: sprintf is called 32 times every iteration of the loop.

This is the part that is more worrisome to me. I didn't benchmark, but all the sprintf's and string conversions are extremely slow. Is this deliberate attempt to slow down mining in the wallets/daemons?

[servicelabs]

E3 1230 V3

getmininginfo

{
"blocks" : 3345,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.36285969,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"hashespersec" : 14577,
"networkhashps" : 12772798,
"pooledtx" : 0,
"testnet" : false
}

[archit]

[14:13] squaggle: And, more generally, that hash function is a speed benchmark of sprintf.
[14:13] curiouser: yeah seems pretty silly
[14:13] squaggle: sprintf is called 32 times every iteration of the loop.

This is the part that is more worrisome to me. I didn't benchmark, but all the sprintf's and string conversions are extremely slow. Is this deliberate attempt to slow down mining in the wallets/daemons?

Pretty much yeah