massiveman
Member
Offline
Activity: 112
Merit: 10


March 14, 2014, 04:36:27 PM 

Re: [ANN] cudaMiner  a new litecoin mining application [Windows/Linux] Today at 12:36:02 PM Reply with quote #8701 Quote from: phm on Today at 12:33:06 PM
What hash rates are you getting on your hardware? Just want to compare... something. Roll Eyes
AMD Phenom II X6 1055T  CPU standalone ca 95 kHash/s on 6 threads
AMD Phenom II X6 1055T using the first 3 GPUs in the machine and 6 CPU threads: close to 800 kHash/s (Groestl remains on CPU)
cannot get GPU use readings, as GPUz has decided to always crash on start after the previous driver update (revision 334 drivers I think). Currently running R 335 drivers from nvidia.
ok it doesnt seem so bad actually, hes only getting that improvement with the cpu and 3 gpus, can't see it being a massive gain overall and would require most rig owners to buy better cpus. the difficulty might not even make it viable.




programmaticbuy
Newbie
Offline
Activity: 11
Merit: 0


March 14, 2014, 04:38:38 PM 

God I'm so horny right now





theironman


March 14, 2014, 04:48:02 PM 

God I'm so horny right now
Good for you. Today is the official men´s day "Steak & blowjob day"




deadthings
Sr. Member
Offline
Activity: 1106
Merit: 255
Betking.io  Best Bitcoin Casino


March 14, 2014, 04:58:52 PM 

Today is the official men´s day "Steak & blowjob day"
And all this time I thought it was Pi Day. Sheesh, have I got it all wrong!




LordShanken


March 14, 2014, 05:21:31 PM 

So this is the end for CPU mining , it was just a matter of time I was laughing from the beginning on about this coin. Taken from their website: The problem is that, due to Quarkcoin's simple use of function compositions, if BLAKE512(x) has collisions, then so does BMW512(BLAKE512(x)) and SKEIN512(KECCAK512(... and so on, until we reach Quark(x), which also has collisions. Similarly, if SKEIN512 or Grøestl512 have collisions, then so does Quark(x). Simply put, if there's a collision attack or secondpreimage attack for BLAKE512(x), then Quark(x) is cracked.
That's already complete nonsense. The developers are just full of crap. Let's say there is a secondpreimage attack for BLAKE512. So am able to compute an input value X, so that BLAKE512(X) = Y, where Y matches the difficulty and finds a block. If Keccac runs before Blake, I still need to find a l need to find an input Z, so that Keccak(Z) = X. Furthermore, they claim: Heavycoin takes 64 bits from the output of each of 4 wellknown cryptographic hash functions (SHA256, Keccak512, Grøestl512 and BLAKE512) and interleaves these bits into a combined 256bit hash that is more resistant against collisions and secondpreimage attacks. LMFAO. These kids have no clue what they are talking about. In fact, the opposite is true. If one hash function is broken, it's possible to freely choose the corresponding 64 bit in the output. Oh guys, just quit this coin. It's pathetic and an insult to anyone capable of adding 1 and 1.




keccak512 (OP)


March 14, 2014, 06:05:06 PM Last edit: March 14, 2014, 06:21:28 PM by keccak512 

So this is the end for CPU mining , it was just a matter of time I was laughing from the beginning on about this coin. Taken from their website: The problem is that, due to Quarkcoin's simple use of function compositions, if BLAKE512(x) has collisions, then so does BMW512(BLAKE512(x)) and SKEIN512(KECCAK512(... and so on, until we reach Quark(x), which also has collisions. Similarly, if SKEIN512 or Grøestl512 have collisions, then so does Quark(x). Simply put, if there's a collision attack or secondpreimage attack for BLAKE512(x), then Quark(x) is cracked.
That's already complete nonsense. The developers are just full of crap. Let's say there is a secondpreimage attack for BLAKE512. So am able to compute an input value X, so that BLAKE512(X) = Y, where Y matches the difficulty and finds a block. If Keccac runs before Blake, I still need to find a l need to find an input Z, so that Keccak(Z) = X. We never claimed Quark is bad for secondpreimage resistance. It's pretty good. We claim Quark is no better for collisions than BLAKE512, and we have proposed an alternative solution that does not rely solely on BLAKE512. With regard to secondpreimage on Blake, the Blake hash is the first function in the chain, so Keccak cannot come before Blake. (We should probably get the webdev to fix the confusion on the website: "if there's a collision attack or secondpreimage attack for..") Furthermore, they claim: Heavycoin takes 64 bits from the output of each of 4 wellknown cryptographic hash functions (SHA256, Keccak512, Grøestl512 and BLAKE512) and interleaves these bits into a combined 256bit hash that is more resistant against collisions and secondpreimage attacks. LMFAO. These kids have no clue what they are talking about. In fact, the opposite is true. If one hash function is broken, it's possible to freely choose the corresponding 64 bit in the output. Oh guys, just quit this coin. It's pathetic and an insult to anyone capable of adding 1 and 1. In Heavycoin if one of the 4 cryptographic hashes is completely broken, then you lose 64 bits out of 256 bits. In Bitcoin if SHA256 is completely broken, then you lose 256 bits. Both scenarios are unlikely, but in one of them you lose fewer bits.




reorder


March 14, 2014, 06:07:09 PM 

That's already complete nonsense. The developers are just full of crap. Let's say there is a secondpreimage attack for BLAKE512. So am able to compute an input value X, so that BLAKE512(X) = Y, where Y matches the difficulty and finds a block. If Keccac runs before Blake, I still need to find a l need to find an input Z, so that Keccak(Z) = X.
Furthermore, they claim:
LMFAO. These kids have no clue what they are talking about. In fact, the opposite is true. If one hash function is broken, it's possible to freely choose the corresponding 64 bit in the output. Oh guys, just quit this coin. It's pathetic and an insult to anyone capable of adding 1 and 1.
Did you miss the 'interleaved' word somehow? You need all 4 hashes to have last 4 bits zero to match the target 0x0000FFFF.. I'd suggest just reading the code. However, using only last 64 bits of each of 4 hashes (and effectively only last 810 bits for PoW at current difficulty) kills the math behind their cryptographic security proofs.




keccak512 (OP)


March 14, 2014, 06:23:11 PM 

However, using only last 64 bits of each of 4 hashes (and effectively only last 810 bits for PoW at current difficulty) kills the math behind their cryptographic security proofs.
The risk is still spread over multiple cryptographic hash functions.




LordShanken


March 14, 2014, 06:27:26 PM 

We never claimed Quark is bad for secondpreimage resistance. It's pretty good. We claim Quark is no better for collisions than BLAKE512, and we have proposed an alternative solution that does not rely solely on BLAKE512.
And that's wrong and easy to prove. In Heavycoin if one of the 4 cryptographic hashes is completely broken, then you lose 64 bits out of 256 bits. In Bitcoin if SHA256 is completely broken, then you lose 256 bits. Both scenarios are unlikely, but in one of them you lose fewer bits.
If in Quark one of the 4 cryptographic hashes is broken, you lose  NOTHING! I am going to provide you an easy to brake hashing function. Craphash(H) = ~H. Simply flip all bits. So, and now you claim that CrapHash(Keccak512(Skein512(Blake512(X)))) or Blake512(Skein512(Keccac512(CrapHash(X)))) is broken? Sorry, but that's ridiculous.




LordShanken


March 14, 2014, 06:36:13 PM 

Did you miss the 'interleaved' word somehow? You need all 4 hashes to have last 4 bits zero to match the target 0x0000FFFF.. I'd suggest just reading the code.
However, using only last 64 bits of each of 4 hashes (and effectively only last 810 bits for PoW at current difficulty) kills the math behind their cryptographic security proofs.
That's does not need to be bad to just take a portion of a hash. But if one of the algorithms for Heavycoin is broken, you simply do not need to apply it any longer. You satisfy a higher difficulty with less effort. If the same algorithm for Quark is broken, you do not win anything. And that's why Quark is more secure. That more than obvious. Heavycoins claims the opposite. Claiming 1+1 = 3 is pretty much at the same level.




delusiona1
Member
Offline
Activity: 90
Merit: 10


March 14, 2014, 06:49:14 PM 

Lordshanken is a scammer dont listen to him! [/quote] TO THE MOOON

HVC: HAccgXrfMZdTsMZss47dAqZ82trPoeiiB7 BTC: 14SoM653x2iEEipDcHchimBfFXwbQUZ3fh



BitDice.CC
Newbie
Offline
Activity: 41
Merit: 0


March 14, 2014, 06:52:26 PM 

A motherfucker hacked the bankroll (1k+ HVC). I'm looking into it. 188.116.54.12




LordShanken


March 14, 2014, 07:02:11 PM 

Lordshanken is a scammer dont listen to him!
"Hey, someone's pointing out that the developers have no clue of math and even proves it. Let's call him a scammer." Yeah, that's going to work out. :)




Lys
Newbie
Offline
Activity: 12
Merit: 0


March 14, 2014, 07:08:59 PM 

Well I actually wanted to wait for a response of keccak when I told him about my Dice site a couple of days ago but I got no response yet so I'm just gonna release it here now anyway. I will raise the limits as soon as I get ahold of more HVC.




keccak512 (OP)


March 14, 2014, 07:18:27 PM 

We never claimed Quark is bad for secondpreimage resistance. It's pretty good. We claim Quark is no better for collisions than BLAKE512, and we have proposed an alternative solution that does not rely solely on BLAKE512.
And that's wrong and easy to prove. While we wait for your proof, here's one for you to ponder regarding collisions in Quark. Quark's multihashing strategy is to chain functions together. It is known that chaining functions together, eg. H1(H2(...(Hn(x)))), does not improve collision resistance. A collision in Hn(x) trivially leads to a collision in the entire chain. This is algebraically visible in the definition of the chained function. If this is still unclear, then consider this simple proof for chains of length two. Suppose we have a combined cryptographic hash function F composed of a chain of two cryptographic hash functions H1 and H2. F(x) = H1(H2(x)) We will show that a collision in H2 leads to a collision in F. First, assume we have a collision in H2. Thus, by definition, we have two blocks w and x such that H2(w) = H2(x) = y. Thus, we have F(w) = H1(H2(w)) and F(x) = H1(H2(x)), which is equal to F(w) = H1(y) and F(x) = H1(y). Uhoh, H1(y) = H1(y) = z, so we have F(w) = z and F(x) = z. So F(w) = F(x) = z. Thus, for inputs w and x the chained function F also collides. This is true for any collision in H2 and any length chain of functions. So chaining functions together does nothing for collisions.




Jungian
Legendary
Offline
Activity: 930
Merit: 1010


March 14, 2014, 07:19:12 PM 

Why not a dicegame like justdice?




keccak512 (OP)


March 14, 2014, 07:20:41 PM 

Well I actually wanted to wait for a response of keccak when I told him about my Dice site a couple of days ago but I got no response yet so I'm just gonna release it here now anyway. I will raise the limits as soon as I get ahold of more HVC. What's your HVC address?




Lys
Newbie
Offline
Activity: 12
Merit: 0


March 14, 2014, 07:26:40 PM 

Well I actually wanted to wait for a response of keccak when I told him about my Dice site a couple of days ago but I got no response yet so I'm just gonna release it here now anyway. I will raise the limits as soon as I get ahold of more HVC. What's your HVC address? HPprVuuY26BkhuBkoXCoGjH29XNFSJLCTw is the bank account




Wenzel745
Member
Offline
Activity: 61
Merit: 10
I'll use crypto to buy a Fiat


March 14, 2014, 07:28:45 PM 

So it seems to me that value of coin is most directly correlated with interest which again is closely related to awareness. It would follow then, that creating an extremely simplified and userfriendly wallet that even nonmining community people could use to at least get a taste for the coin would be a really good thing for the community.
Would anyone be willing to build such a wallet? I don't have enough HVC right now for any meaningful bounty, but if you guys think it's a good idea I'm sure we can rope something together!

BTC: 163pZXhATaWiuGAX9o9y6PuKCF8ipDWnJH HVC: HJWFdgUJPEw1oiLckBFPBzs8vCTLokCGgd



