Colin Percival on #litecoin-dev 02


SUBMITTED BY: Guest

DATE: May 7, 2013, 7:51 a.m.

FORMAT: Text only

SIZE: 3.5 kB

HITS: 3274

  1. 11:52 < iddo> cperciva: are you familiar with the claim that scrypt that litecoin uses (N=1024,p=1,r=1) can be done with only 1024 bits of RAM, though probably around 500x time complexity penalty, by unrolling the code?
  2. 11:54 < cperciva> iddo: it's not unrolling, but yes
  3. 11:55 < cperciva> iddo: there's a memory-time tradeoff
  4. 11:55 -!- mode/#litecoin-dev [+o coblee] by ChanServ
  5. 11:55 < iddo> yes not unrolling, i mean re-calculate the needed values in the mem buffer on the fly as needed
  6. 11:56 < cperciva> correct
  7. 11:56 < iddo> that figure of only needed 1024 registers sounds plausible to you? it's only twice more than SHA256 internal state of 512 bits
  8. 11:57 < cperciva> iddo: yes, that sounds about right
  9. 11:57 < cperciva> iddo: with p=1, r=1, the internal state is only two 256-bit blocks
  10. 11:58 < iddo> i see
  11. 11:58 < iddo> so i wonder if scrypt ASIC manufacturer would prefer to take the time penalty hit, and implement p=1,r=1 scrypt with 1024 bits per hash attempt, with many hash attempts in parallel
  12. 11:59 < razorfishsl> the thruput is still crap... I tried with FPGA
  13. 12:00 < iddo> razorfishsl: interesting...
  14. 12:00 < razorfishsl> I can get about 5kh/s per core
  15. 12:00 < cperciva> iddo: they might -- more likely they'd opt to go part way, since once they've got a 20k gate sha256 circuit adding a few more gates to have a 4 kb RAM instead of a 1 kb RAM wouldn't cost much (but would give them a 4x speedup)
  16. 12:00 < iddo> razorfishsl: and much memory per core ?
  17. 12:00 < razorfishsl> no
  18. 12:01 < razorfishsl> but there are people claiming tehy can match a GPU with an FPGA
  19. 12:01 < iddo> razorfishsl: sorry i meant "how much" per core ?
  20. 12:01 < cperciva> iddo: the point of scrypt is to limit how many hashes you can compute per second per mm^2 of ASIC -- it doesn't prove anything about *how* people reach that limit
  21. 12:02 < iddo> i see
  22. 12:02 < razorfishsl> I cannot see how people can get 'high' figures from an FPGA , but I keep failing
  23. 12:03 < razorfishsl> (by that I mean, I have had some top quality engineers look at it)
  24. 12:04 < iddo> cperciva: what do you think of scrypt with really huge mem buffer? me and another person tried to benchmark it a little here: https://bitcointalk.org/index.php?topic=122256.msg1318485#msg1318485
  25. 12:04 < iddo> cperciva: do you think that e.g. 512 megabytes mem buffer will be good on modern CPUs, but useless for GPUs/ASIC ?
  26. 12:06 < iddo> or maybe the space/time tradeoff implies that 512 megabytes mem buffer will still be good on GPUs
  27. 12:07 < cperciva> once you get to 512 MB, I doubt GPUs will be much use
  28. 12:09 < iddo> i suppose that we should try to test 512 MB under intensive use while multitasking, if modern PC cannot handle it then only servers could run the litecoin client
  29. 12:13 < iddo> cperciva: i'm trying to persuade the bitcoin devs to use scrypt with a nice password derivation algorithm that they come up with: https://bitcointalk.org/index.php?topic=102349.0
  30. 12:13 < iddo> cperciva: my push is at https://bitcointalk.org/index.php?topic=19137.msg1929096#msg1929096 and https://bitcointalk.org/index.php?topic=19137.msg1965624#msg1965624
  31. 12:14 < iddo> cperciva: do you have a recommendation for scrypt parameters for password derivation ?
  32. 12:16 < cperciva> iddo: for password derivation, I recommend r=8, p=1, N= as big as you have memory and time for
  33. 12:17 < iddo> cool, thanks

loading...

comments powered by Disqus