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.
Topic: [ANN] Kryptohash | Brand new PoW algo | 320bit hash | ed25519 | PID algo for dif - page 24. (Read 149454 times)
January 13, 2015, 12:37:05 AM
There needs to be more done, smart phone wallets, then more integration, but it looks like the algo might change.
January 13, 2015, 12:35:08 AM
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.
January 13, 2015, 12:28:50 AM
Why the https://empoex.com/ where no trading volume, this is a good trading platform!!!
January 12, 2015, 11:32:22 PM
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.
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.
January 12, 2015, 10:27:10 PM
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.
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.
January 12, 2015, 10:58:03 AM
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.
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).
January 12, 2015, 03:45:55 AM
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.
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.
January 11, 2015, 10:12:10 PM
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~I'm working on the To Do list. Android Wallet is the next item on the list.
without further development,this coin may go dead.
January 11, 2015, 06:54:48 PM
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. I'm working on the To Do list. Android Wallet is the next item on the list.
January 11, 2015, 06:38:08 PM
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~I'm working on the To Do list. Android Wallet is the next item on the list.
without further development,this coin may go dead.
January 11, 2015, 12:24:32 PM
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.
I'm working on the To Do list. Android Wallet is the next item on the list.
January 11, 2015, 08:07:10 AM
the info showed on nonce-pool dashboard is not correct . 
January 11, 2015, 03:47:46 AM
haven't seen dev here for days
I know he's got a day job, so I know he is busy. He's probably busy building/testing wallets too.
January 11, 2015, 01:45:01 AM
haven't seen dev here for days
January 09, 2015, 02:40:14 PM
if the coin (and the dev) can take all the shit falling down and continue good work..
maybe then..
maybe then..
I'm thinking that is why he is taking it one code base at a time. It is not falling down, the current released wallets are functioning as designed. Once there is a stable cross platform code base then marketing can happen, more features can be added. Technical ability and the drive to play it straight is hard to contend with when compared to a lot of other coins out there.
January 09, 2015, 02:36:17 PM
there's a buy order for 0.3btc at 0.0000039
way too cheap,nobody is willing to sell at that price. 
wow first valid order with some real money, maybe we see 0.5btc order someday
January 09, 2015, 11:08:06 AM
Develop a detailed plan to roll out time?
January 08, 2015, 05:20:45 PM
plz don't spoil this thread,we are lucky to have a dedicated dev here who obviously has the technical knowledge to create something innovative.
calm down and waiting for dev's next masterpiece.
calm down and waiting for dev's next masterpiece.
January 08, 2015, 04:39:06 PM
no, waiting buyers to dump. there is absolutely no support to dump any coins now.
makes more easy to just delete wallet than sell them.
so i will wait bigger buy orders.
makes more easy to just delete wallet than sell them.
so i will wait bigger buy orders.
Do you mean that the price is OK for you to dump, just not enough buy orders? Wow, you must have like half a million or more then. And you mined it in 2 past weeks? Because earlier you said that you already dumped all your coins.
Marketing before the product is completed? Still needs Android/IOS/Windows Phone wallets, maybe POS integration? Cart/Horse?
Anything else dev can do specifically and just for you? Maybe he can have your mom buy you a nice new video adapter?
Heh, got ya!
Dev is doing for everyone here, and at a pace that a stable product can be created.
January 08, 2015, 04:11:49 PM
no, waiting buyers to dump. there is absolutely no support to dump any coins now.
makes more easy to just delete wallet than sell them.
so i will wait bigger buy orders.
makes more easy to just delete wallet than sell them.
so i will wait bigger buy orders.
Do you mean that the price is OK for you to dump, just not enough buy orders? Wow, you must have like half a million or more then. And you mined it in 2 past weeks? Because earlier you said that you already dumped all your coins.
Marketing before the product is completed? Still needs Android/IOS/Windows Phone wallets, maybe POS integration? Cart/Horse?
Anything else dev can do specifically and just for you? Maybe he can have your mom buy you a nice new video adapter?
Jump to: