<p>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.</p>
<p>Listen to Charlie Lee talk about this at the Hashers United conference in Las Vegas.</p>
<ul>
<li><a href="https://www.youtube.com/watch?v=aHX34MbXuOk#t=469m00s" rel="nofollow noreferrer">https://www.youtube.com/watch?v=aHX34MbXuOk#t=469m00s</a></li>
<li><a href="https://www.youtube.com/watch?v=qbj7aXu7FTw" rel="nofollow noreferrer">https://www.youtube.com/watch?v=qbj7aXu7FTw</a></li>
</ul>
<blockquote>
<p>[transcript starts at approximately 9:45 in the second video.]</p>
<p>Q: [...] But in hindsight, do you regret selecting the N, r, and p, parameters for scrypt?</p>
<p>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.</p>
<p>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.</p>
</blockquote>

CC BY-SA 3.0
2015-03-29T03:31:03.393Z
2015-03-30T20:15:08.380Z
2020-06-16T11:10:03.350Z
morsecoder
<p>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.</p>
<p><a href="http://www.daemonology.net/" rel="nofollow noreferrer">Colin Percival</a>, the creator of scrypt, <a href="https://twitter.com/cperciva/status/311260784288223232" rel="nofollow noreferrer">has said</a>:</p>
<blockquote>
<p>Q: are you into #litecoin at all?</p>
<p>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.</p>
<p>Q: I'm considering enhancing #litecoin. How is scrypt being used poorly? Maybe I can help improve it</p>
<p>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.</p>
</blockquote>
<p>Is there a technical justification for such a low N and r?</p>

CC BY-SA 3.0
2015-03-30T12:42:18.333Z
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
CC BY-SA 3.0
2015-03-30T19:06:01.503Z
@DavidSchwartz If being only ASIC-minable is was their motivation, then why use scrypt at all? Why not just stick with SHA256?
Nick ODell
CC BY-SA 3.0
2015-03-30T19:29:38.750Z
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
CC BY-SA 3.0
2015-03-30T19:30:41.560Z
@DavidSchwartz Ah, I misread your comment.
Nick ODell
<litecoin><scrypt>
Why did Litecoin choose the scrypt factors that they did?
Nick ODell
# Why did Litecoin choose the scrypt factors that they did?

(Asked by: username_0 on 2015-03-29)

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](http://www.daemonology.net/), the creator of scrypt, [has said](https://twitter.com/cperciva/status/311260784288223232):

> 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?

**Tags:** litecoin, scrypt

> **Comments:**
> **username_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.)  
> **username_0**: @DavidSchwartz If being only ASIC-minable is was their motivation, then why use scrypt at all? Why not just stick with SHA256?  
> **username_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.  
> **username_0**: @DavidSchwartz Ah, I misread your comment.  

---

## 1 answers

### Answer by username_2 on 2015-03-29. Score: 3 | Accepted answer

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.

* <https://www.youtube.com/watch?v=aHX34MbXuOk#t=469m00s>
* <https://www.youtube.com/watch?v=qbj7aXu7FTw>

> [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.


---

