[ANN] Kryptohash | Brand new PoW algo | 320bit hash | ed25519 | PID algo for dif

[wr104]

The biggest threat this coin could ever face would be me losing my full time job.

I'm working on the To Do list.  Android Wallet is the next item on the list.

[driedgrape]

The biggest threat this coin could ever face would be me losing my full time job.

I'm working on the To Do list.  Android Wallet is the next item on the list.

That's really a bad news~
without further development,this coin may go dead.

[driedgrape]

The biggest threat this coin could ever face would be me losing my full time job.

I'm working on the To Do list.  Android Wallet is the next item on the list.

BTW : thanks for your honesty.

[xinbinbin]

The biggest threat this coin could ever face would be me losing my full time job.

I'm working on the To Do list.  Android Wallet is the next item on the list.

That's really a bad news~
without further development,this coin may go dead.

A detailed plan of time? You love this coin? Why should we give up it!

[tsiv]

Current version of KSHAKE320 algorithm requires 64Kb per hash.  I could change it to require 128Kb+ on a dime.

But, what limits the speed of the algorithm is not the amount of RAM but, the speed you can store/read data to/from RAM.  If in the future, new RAM technology allows for very fast memory that is also affordable then, the KSHAKE320 algorithm may no longer offer an advantage over regular hashing algorithms.

Correct me if I'm wrong, but the 64 kB scratchpad looks unnecessary. OpenCL isn't exactly a native tongue to me, but from what I gather the core is roughly something like this:

Code:

initState(A);
absorbInput(A);
for( i = 0; i < 546; i++ ) {
  keccakPermutation(A);
  saveStateToScratchpad(i, A);
}

initState(A);
for( i = 0; i < 546; i++ ) {
  absorbFromScratchpad(A, i);
  keccakPermutation(A);
}

If that is correct, then you could just have two keccak states instead the current scratchpad implementation? Something like this:

Code:

initState(A);
initState(B);
absorbInput(A);
for( i = 0; i < 546; i++ ) {
  keccakPermutation(A);
  absorbFromState(B, A);
  keccakPermutation(B);
}

I might be misinterpreting the openCL kernel or overlooking something, seems too obvious of a way to get rid of the scratchpad.

[wr104]

Current version of KSHAKE320 algorithm requires 64Kb per hash.  I could change it to require 128Kb+ on a dime.

But, what limits the speed of the algorithm is not the amount of RAM but, the speed you can store/read data to/from RAM.  If in the future, new RAM technology allows for very fast memory that is also affordable then, the KSHAKE320 algorithm may no longer offer an advantage over regular hashing algorithms.

Correct me if I'm wrong, but the 64 kB scratchpad looks unnecessary. OpenCL isn't exactly a native tongue to me, but from what I gather the core is roughly something like this:

Code:

initState(A);
absorbInput(A);
for( i = 0; i < 546; i++ ) {
  keccakPermutation(A);
  saveStateToScratchpad(i, A);
}

initState(A);
for( i = 0; i < 546; i++ ) {
  absorbFromScratchpad(A, i);
  keccakPermutation(A);
}

If that is correct, then you could just have two keccak states instead the current scratchpad implementation? Something like this:

Code:

initState(A);
initState(B);
absorbInput(A);
for( i = 0; i < 546; i++ ) {
  keccakPermutation(A);
  absorbFromState(B, A);
  keccakPermutation(B);
}

I might be misinterpreting the openCL kernel or overlooking something, seems too obvious of a way to get rid of the scratchpad.

The first hash is calculated using 120 bytes of data as an input. The result of this first hash (using Extendable Output Function SHAKE-320) is stored in the 64Kb scratchpad (120 * 546 to be exact).  
Then, a second hash is calculated using those 64Kb of scratchpad data as an input and the final result is a 40 bytes hash (320bits).

[tsiv]

Current version of KSHAKE320 algorithm requires 64Kb per hash.  I could change it to require 128Kb+ on a dime.

But, what limits the speed of the algorithm is not the amount of RAM but, the speed you can store/read data to/from RAM.  If in the future, new RAM technology allows for very fast memory that is also affordable then, the KSHAKE320 algorithm may no longer offer an advantage over regular hashing algorithms.

Correct me if I'm wrong, but the 64 kB scratchpad looks unnecessary. OpenCL isn't exactly a native tongue to me, but from what I gather the core is roughly something like this:

Code:

initState(A);
absorbInput(A);
for( i = 0; i < 546; i++ ) {
  keccakPermutation(A);
  saveStateToScratchpad(i, A);
}

initState(A);
for( i = 0; i < 546; i++ ) {
  absorbFromScratchpad(A, i);
  keccakPermutation(A);
}

If that is correct, then you could just have two keccak states instead the current scratchpad implementation? Something like this:

Code:

initState(A);
initState(B);
absorbInput(A);
for( i = 0; i < 546; i++ ) {
  keccakPermutation(A);
  absorbFromState(B, A);
  keccakPermutation(B);
}

I might be misinterpreting the openCL kernel or overlooking something, seems too obvious of a way to get rid of the scratchpad.

The first hash is calculated using 120 bytes of data as an input. The result of this first hash (using Extendable Output Function SHAKE-320) is stored in the 64Kb scratchpad (120 * 546 to be exact).  
Then, a second hash is calculated using those 64Kb of scratchpad data as an input and the final result is a 40 bytes hash (320bits).

And that's exactly what the second code snippet does. Instead of first calculating the full output of the XOF into a scratchpad and then separately hashing the scratchpad contents into the final hash, you can do it block by block. Maintain two keccak states, calculate first 120 bytes of the XOF output using the first state, update the second hash state with those 120 bytes, then calculate the next 120 bytes of the XOF, update the second hash with that. Repeat until finished.

[wr104]

Current version of KSHAKE320 algorithm requires 64Kb per hash.  I could change it to require 128Kb+ on a dime.

But, what limits the speed of the algorithm is not the amount of RAM but, the speed you can store/read data to/from RAM.  If in the future, new RAM technology allows for very fast memory that is also affordable then, the KSHAKE320 algorithm may no longer offer an advantage over regular hashing algorithms.

Correct me if I'm wrong, but the 64 kB scratchpad looks unnecessary. OpenCL isn't exactly a native tongue to me, but from what I gather the core is roughly something like this:

Code:

initState(A);
absorbInput(A);
for( i = 0; i < 546; i++ ) {
  keccakPermutation(A);
  saveStateToScratchpad(i, A);
}

initState(A);
for( i = 0; i < 546; i++ ) {
  absorbFromScratchpad(A, i);
  keccakPermutation(A);
}

If that is correct, then you could just have two keccak states instead the current scratchpad implementation? Something like this:

Code:

initState(A);
initState(B);
absorbInput(A);
for( i = 0; i < 546; i++ ) {
  keccakPermutation(A);
  absorbFromState(B, A);
  keccakPermutation(B);
}

I might be misinterpreting the openCL kernel or overlooking something, seems too obvious of a way to get rid of the scratchpad.

The first hash is calculated using 120 bytes of data as an input. The result of this first hash (using Extendable Output Function SHAKE-320) is stored in the 64Kb scratchpad (120 * 546 to be exact).  
Then, a second hash is calculated using those 64Kb of scratchpad data as an input and the final result is a 40 bytes hash (320bits).

And that's exactly what the second code snippet does. Instead of first calculating the full output of the XOF into a scratchpad and then separately hashing the scratchpad contents into the final hash, you can do it block by block. Maintain two keccak states, calculate first 120 bytes of the XOF output using the first state, update the second hash state with those 120 bytes, then calculate the next 120 bytes of the XOF, update the second hash with that. Repeat until finished.

Unless, I feed the second hash using the first hash output in reverse order (last byte first) which I didn't do in this version of the algorithm.

Well, this is why it is good to have other people reviewing your work.  Good catch.

[xinbinbin]

Why the https://empoex.com/ where no trading volume, this is a good trading platform!!!

[WORE]

Why the https://empoex.com/ where no trading volume, this is a good trading platform!!!

There needs to be more done, smart phone wallets, then more integration, but it looks like the algo might change.

[xinbinbin]

Why the https://empoex.com/ where no trading volume, this is a good trading platform!!!

There needs to be more done, smart phone wallets, then more integration, but it looks like the algo might change.

Too bad, I dig a month, sell do not go out, a waste of electricity, I quit!!!

[Undead_Phenix]

Why the https://empoex.com/ where no trading volume, this is a good trading platform!!!

There needs to be more done, smart phone wallets, then more integration, but it looks like the algo might change.

Too bad, I dig a month, sell do not go out, a waste of electricity, I quit!!!

he he ,what a Chiglish~ 

[SecretsOfCrypto]

what are the benefits of this new PoW algorithm? why is it better than the others?

[wr104]

Well, I'm going to have to put the Android wallet on hold while I work on a new Wallet that will transition the network to a KSHAKE320 version2 algorithm.

This could take at least a couple of weeks due to all the testing required to ensure the transition can be as smooth as possible.  

[Undead_Phenix]

Well, I'm going to have to put the Android wallet on hold while I work on a new Wallet that will transition the network to a KSHAKE320 version2 algorithm.

This could take at least a couple of weeks due to all the testing required to ensure the transition can be as smooth as possible.  

Is the KSHAKE320 version2 algorithm cooler ? 

[tacee]

the net hashrate is stable at 20Mh/s these days 

[WORE]

Well, I'm going to have to put the Android wallet on hold while I work on a new Wallet that will transition the network to a KSHAKE320 version2 algorithm.

This could take at least a couple of weeks due to all the testing required to ensure the transition can be as smooth as possible.  

Is the KSHAKE320 version2 algorithm cooler ? 

Yep, way cooler than avian zombies.  But on the plus side, the coin over all is compliant to new encryption standards on top of an invention that conceptually destroys counterfeit money.  Way cooler than what the corporate banker Nazi's have done to curb that problem.

[bufferfund]

The biggest threat this coin could ever face would be me losing my full time job.

I'm working on the To Do list.  Android Wallet is the next item on the list.

sad if you are about to losing your day job?

i guess dev means he may lose full time for developping this coin.

[WORE]

The biggest threat this coin could ever face would be me losing my full time job.

I'm working on the To Do list.  Android Wallet is the next item on the list.

sad if you are about to losing your day job?

i guess dev means he may lose full time for developping this coin.

No that isn't it at all.  He means that if Earth were to be hit by Nibiru and all life on either planet were to be destroyed then he might lose his job.  But the blockchain would still be intact, just lost for a while.  Kind of like a black hole, no data is lost.

[crypto_currency]

The biggest threat this coin could ever face would be me losing my full time job.

I'm working on the To Do list.  Android Wallet is the next item on the list.

sad if you are about to losing your day job?

i guess dev means he may lose full time for developping this coin.

No that isn't it at all.  He means that if Earth were to be hit by Nibiru and all life on either planet were to be destroyed then he might lose his job.  But the blockchain would still be intact, just lost for a while.  Kind of like a black hole, no data is lost.

so ,what does that mean reguarding the future of this coin ??