5

Litecoin uses the scrypt factors (N=1024, r=1, p=1) This means that each hashing thread takes 128kB of memory. The scrypt paper recommends r=8.

Colin Percival, the creator of scrypt, has said:

Q: are you into #litecoin at all?

A: I'm aware of it, and I'm aware that they used scrypt poorly (not enough RAM usage). That's the limit of my knowledge.

Q: I'm considering enhancing #litecoin. How is scrypt being used poorly? Maybe I can help improve it

A: I'd suggest talking to @solardiz about this -- my knowledge of how litecoin misuses scrypt comes mostly from him. The 1-tweet summary is that scrypt is designed to achieve security by using lots of RAM, and litecoin doesn't use lots of RAM.

Is there a technical justification for such a low N and r?

Improve this question
4
  • 1
    The truth is, however, the reverse. The less RAM you use, the more secure you are. The low N was a fortunate choice that makes Litecoin more secure than its designers intended. (Short reason why: The more RAM you use, the harder it is for people who invest in the coin to have a hash power advantage over those who use botnets or rented machines to attack the coin. Using more RAM helps attackers because they can more easily use commodity hardware they've stolen or rented to launch double spend attacks. Using less RAM helps those who have invested in the coin use ASICs to protect it.)
    – David Schwartz
    Commented Mar 30, 2015 at 12:42
  • 1
    @DavidSchwartz If being only ASIC-minable is was their motivation, then why use scrypt at all? Why not just stick with SHA256?
    – Nick ODell
    Commented Mar 30, 2015 at 19:06
  • 1
    The first part of your "if" is plainly false. The evidence suggests that their motivation was to be ASIC-resistant, but that they failed. This was a lucky mistake -- Litcoin is more secure because of it.
    – David Schwartz
    Commented Mar 30, 2015 at 19:29
  • @DavidSchwartz Ah, I misread your comment.
    – Nick ODell
    Commented Mar 30, 2015 at 19:30

1 Answer 1

Reset to default
3

Litecoin basically copied the parameters from a coin called tenebrix. The parameters were chosen partially because using more memory intensive parameters caused the GUI to be noticeably slow.

Listen to Charlie Lee talk about this at the Hashers United conference in Las Vegas.

[transcript starts at approximately 9:45 in the second video.]

Q: [...] But in hindsight, do you regret selecting the N, r, and p, parameters for scrypt?

A: So, the parameters I chose were copied straight from Tenebrix. The reason why they were chosen that way is because if you make the parameters harsher, more memory harsh, it actually slows down the client. Every time a block comes in, the client would actually freeze, for a minute, to verify the block, because it was so hard. At that time, it was decided, that it was a tradeoff. They decided to go with a better experience of the user using the client, and not as memory harsh, because at that time there wasn't any GPU that was capable of doing it, and it was CPU-only.

It would be great if the parameters were more memory harsh, but I think it was a tradeoff, and it was decided early on, to err on the side faster client speed instead of harsher memory requirements.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.