phc-discussions - Re: [PHC] Memory-hard proof of work with fast verification (CPU Hash)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date: Thu, 9 Jul 2015 03:27:43 +0100
From: denis bider <pwhashing@...isbider.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Memory-hard proof of work with fast verification (CPU Hash)

It is generally a good idea for the network to defend itself against DoS by requiring incoming node connections to submit a costly proof of work A that's cheap to verify, just to accept the connection. If this measure is effective, it allows use of proof of work B that's costlier to verify for actual block verification. If a node submits an invalid block, disconnect it and require it to go through proof of work A again if it wants to re-connect.

Of course, this requires some proof of work A that's cheap to verify and still not trivializable. But the incentives to attack proof of work A (which merely gates connections) are much different to incentives to attack proof of work B (which underpins the currency).

-----Original Message-----  From: Zooko Wilcox-O'Hearn  Sent: Wednesday, July 8, 2015 15:27  To: discussions@...sword-hashing.net  Subject: Re: [PHC] Memory-hard proof of work with fast verification (CPU  Hash)    Dear Bill Cox and Solar Designer:   Thanks for the useful conversation.   On Tue, Jul 7, 2015 at 10:29 PM, Bill Cox <waywardgeek@...il.com>  wrote: > > One more concern is a possible DDoS attack on the network.   Publishing > 1,000's of fake solutions to blocks per second that require the  entire > network to debunk them with a very computationally expensive  verification > would be bad.  I read about that DDoS problem somewhere recently...  can't > remember if it was the Argon2 paper or somewhere else.   Hm, that's a good point. I haven't thought this one all the way through. I don't know how to assign a budget to this one, other than "the cheaper verification is the better".

Content of type "text/html" skipped