Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B7198727 for ; Wed, 19 Apr 2017 17:43:06 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DF9AB1A4 for ; Wed, 19 Apr 2017 17:43:05 +0000 (UTC) Received: by mail-wm0-f43.google.com with SMTP id m123so18105585wma.0 for ; Wed, 19 Apr 2017 10:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bittorrent-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ac2FcBUzTZr2JV/KVjXfYe8VMDjRf7PwY7CTW1eENOE=; b=t5QPpSiRdXFbjAZ0I33Lwi2289/uzJYqRHPTFE2GY9iRIZk3hv4vvCwS9rBQzqgjb5 mHGI2M7cRiVr+nbmkeCtNdnboxK29RfrmgIuDYVUkx/9bQq+dWeHWOxdfJ4wuqZHyirg 3dYGYwm1stYQymmpK+sJtr4rklNqPm6G9ooPt5vOrtfVH1z8o1rHwODk+QGOuqrYPDlU IqmRHecjdTFB0bvSodKLn/g2Uug1/dqiJ9cYNa+FDFxB5o/PRe9mQcZLdGwceXAsa0hN zM6NDLYd+HIGncVYgkaadIzNqZ7ybuuSmQeuZg8aN5eRgeEtQc0rthm/w6K6T0lDcHeD NHmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ac2FcBUzTZr2JV/KVjXfYe8VMDjRf7PwY7CTW1eENOE=; b=g5wfXHYSaulNuS1OyyKbP1D6y2Ek9ykUgu7/C+bgUlEaorqnW6DsBYpKhT7UmlAyg6 wyb92ayzigpOnSgg/O1RFdqnL88XV8TKmOsF3hX2l0uVVVDJbqrtnTWAtHLUB4g4of1b 2QJKord6poLUS9kwTCXF08cJn7mvX3lXBFD2Seu5ApaSfHMLtjg6pdvSEhYuWCwwgEZI bk4Vbhp+YL7REh0s+wnoI2Y3Wn2YTG10ROpDy9idDPGjkYAD4m/M7r2v6f+Q9rFwQO53 cBT1QtFia6GWT0sXnbCKWXSNlY9O60GbzqirgH46oiGTrITLZI9qv+uOQV4L2qlPF802 Cvkg== X-Gm-Message-State: AN3rC/4DShMOMbJQ+NyY9UhGoFMJ4Z+n6WOL/5SqgtAbm3o0S7teZeC6 Gz0jkxATQDxD2rg1N7AGCbYd0rqYyaO6 X-Received: by 10.28.4.142 with SMTP id 136mr19524771wme.89.1492623784510; Wed, 19 Apr 2017 10:43:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.147.132 with HTTP; Wed, 19 Apr 2017 10:43:03 -0700 (PDT) In-Reply-To: References: From: Bram Cohen Date: Wed, 19 Apr 2017 10:43:03 -0700 Message-ID: To: Natanael Content-Type: multipart/alternative; boundary=001a1141819e75ae08054d888ed1 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev , Erik Aronesty Subject: Re: [bitcoin-dev] Properties of an ideal PoW algorithm & implementation X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 17:43:06 -0000 --001a1141819e75ae08054d888ed1 Content-Type: text/plain; charset=UTF-8 Repeatedly hashing to make it so that lossy implementations just fail sounds like a great idea. Also relying on a single crypto primitive which is as simple as possible is also a great idea, and specifically using blake2b is conservative because not only is it simple but its block size is larger than the amount of data being hashed so asicboost-style attacks don't apply at all and the logic of multiple blocks doesn't have to be built. Memory hard functions are a valiant effort and are holding up better than expected but the problem is that when they fail they fail catastrophically, immediately going from running on completely commodity hardware to only running on hardware from the one vendor who's pulled off the feat of making it work. My guess is it's only a matter of time until that happens. So the best PoW function we know of today, assuming that you're trying to make mining hardware as commodity as possible, is to repeatedly hash using blake2b ten or maybe a hundred times. Mind you, I still think hard forking the PoW function is a very bad idea, but if you were to do it, that would be the way to go. --001a1141819e75ae08054d888ed1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Repeatedly hashing to make it s= o that lossy implementations just fail sounds like a great idea. Also relyi= ng on a single crypto primitive which is as simple as possible is also a gr= eat idea, and specifically using blake2b is conservative because not only i= s it simple but its block size is larger than the amount of data being hash= ed so asicboost-style attacks don't apply at all and the logic of multi= ple blocks doesn't have to be built.
Memory hard functions are a valiant effo= rt and are holding up better than expected but the problem is that when the= y fail they fail catastrophically, immediately going from running on comple= tely commodity hardware to only running on hardware from the one vendor who= 's pulled off the feat of making it work. My guess is it's only a m= atter of time until that happens.

So the best PoW function we know of today, assu= ming that you're trying to make mining hardware as commodity as possibl= e, is to repeatedly hash using blake2b ten or maybe a hundred times.=C2=A0<= /div>

Mind y= ou, I still think hard forking the PoW function is a very bad idea, but if = you were to do it, that would be the way to go.
--001a1141819e75ae08054d888ed1--