[Cryptography] [OT] Improvement to Momentum PoW

Bill Cox waywardgeek at gmail.com
Mon Jul 27 17:02:20 EDT 2015

On Mon, Jul 27, 2015 at 12:46 PM, John Tromp <john.tromp at gmail.com> wrote:

> On Mon, Jul 27, 2015 at 2:29 PM, Bill Cox <waywardgeek at gmail.com> wrote:
> > A problem with Momentum as currently implemented is that it can be run
> with
> > reduced memory, enabling efficient GPU attacks.
> Dave Andersen's latest remarks on his GPU code:
> https://bitcointalk.org/index.php?topic=826901.msg11944049#msg11944049
> You can ask him what he thinks is a faster implementation.
> Fore reduced memory, you can find all collisions in 8MB,
> using Cuckoo Cycle's algorithm for finding 2 cycles in bipartite graphs.
> >  I think we can get around
> > this problem simply by changing the parameters it uses.
> > If instead, we run with n == 26, and Hb's output also being 26 bits,
> then we
> > get around 2^26 collisions.
> To me, that's a completely different beast.
> I would no longer call that Momentum...
> -John

Well, it certainly seems different, at least in terms of optimizations and
attacks.  With input/output of Hb set to the same width, I _think_ it is
more GPU resistant.  I could be wrong.  I think we can not compute the
collisions efficiently in less than around 2^27 bytes, though there's the
obvious TMTO option, as usual in Momentum.

If this works as I think it does, without any attacks I'm missing, then I
would prefer this version, since it forces an ASIC to use more memory.  I
think the main ASIC defense for Momentum is total memory bandwidth.  The
latency defense is overcome with buffered radix-sort, but the data still
has to be written and read once.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150727/484f1efb/attachment.html>

More information about the cryptography mailing list