IRC FreeNode #litecoin-dev Log - LukeJr learning Scrypt

[15:21] <luke-jr> coblee: what are 1024,1,1?
[15:21] <@coblee> the scrypt parameters
[15:21] <TimothyA> coblee: other than costing me a shitton of resources?
[15:21] <@coblee> N=1024,p=1,r=1
[15:21] <luke-jr> coblee: what are they?
[15:22] <+pooler> http://www.tarsnap.com/scrypt.html
[15:23] <@coblee> i don't think you would implement a generic scrypt function that takes in these 3 params. so having it as hardcoded string should be fine
[15:24] <@coblee> so you would just do a string comparison with "scrypt(1024,1,1)"
[15:24] <@coblee> i don't think it makes sense to parse that string
[15:24] <+pooler> well it shouldn't be too hard to implement the generic version
[15:26] <@coblee> guess not, but what's the benefit? in case we do change the algo to 4096,8,1, you wouldn't have to modify the cgminer code and it will just work?
[15:26] <@coblee> seems like extra work to parse the string and pass it to the generic method just for that
[15:26] <+pooler> well the string looks parsable :)
[15:27] <+pooler> but yeah you're right
[15:28] <@coblee> luke-jr suggested that we do this "algoparams":[1024,1,1] so it's already parsed
[15:28] <+pooler> ha, interesting
[15:28] <+pooler> so you'd add two fields
[15:28] <@coblee> we could do that, but not sure if the added complication does us any good
[15:29] <@coblee> yeah, and probably to pushpool too
[15:29] <+pooler> the first suggestion of "scrypt:1024,1,1" was not that bad either
[15:29] <+pooler> reminds me of some http headers
[15:29] <@coblee> yeah
[15:29] <@coblee> or "algorithm":["scrypt",1024,1,1]
[15:30] <@coblee> i just think that right now there's only 2: "sha256(sha256())" and "scrypt(1024,1,1)"
[15:30] <luke-jr> sha256 doesn't take parameters tho
[15:30] <@coblee> so there's no need to generify it just for the sake of that
[15:30] <luke-jr> it's just a number of rounds
[15:31] <+pooler> yeah, it's a matter of definitions
[15:31] <luke-jr> coblee: I'd say, since scrypt is fundamentally flawed POW for this, it doesn't justify changing anything ;)
[15:31] <luke-jr> it's more likely justified by some future algorithm that *does* make sense
[15:31] <@coblee> think of it as sha256(sha256(x)) and scrypt(x,1024,1,1)
[15:31] <luke-jr> so should support that
[15:32] <@coblee> luke-jr: so what would you recommend?
[15:33] <luke-jr> "algo":"scrypt","algoopts":[1024,1,1],"rounds":1
[15:33] <luke-jr> <.<
[15:33] <@coblee> it's just 1 or 2 line changes to the code on my end, so I don't care that much
[15:33] <luke-jr> "algo":"scrypt","algoopts":[1024,1,1],"algorounds":1
[15:33] <luke-jr> "algo":"scrypt","algoopts":[1024,1,1],"algoiter":1
[15:33] <+pooler> looks too much complication to me
[15:34] <luke-jr> XD
[15:34] <@coblee> luke-jr: i can see you're a perfectionist
[15:34] <@coblee> that's going to force miners to implement extra generic code that would almost never be used
[15:34] <+pooler> sha256^2 is called SHA-256d in many scientific papers
[15:35] <luke-jr> coblee: nah, miners can take shortcuts and malfunction if things are outside their assumptions
[15:35] <luke-jr> like they do now
[15:35] <@coblee> like handle scrypt 5 times in case you get algoiter=5
[15:35] <@coblee> luke-jr: then what's the point?
[15:36] <@coblee> the code would just be: if algo=="scrypt", do scrypt(1024,1,1), otherwise do sha256^2
[15:36] <@coblee> would you even bother writing the code the correctly handle it in bfgminer?
[15:36] <@coblee> s/the/to
[15:37] <luke-jr> coblee: the point is that you don't need to change the format every time you add a new algorithm
[15:38] <@coblee> which happens about once in your lifetime
[15:38] <@coblee> maybe twice :)
[15:38] <+pooler> _maybe_
[15:38] <luke-jr> I don't consider litecoin special.
[15:39] <@coblee> and b/c of that you want to write complicated logic to be general enough to handle any possible opts and rounds?
[15:39] <luke-jr> no, I want to be able to write such logic in the future if it is needed then, without breaking compatibility
[15:39] <+pooler> boys... i hate compromises...
[15:41] <luke-jr> I don't care enough to argue it either tho
[15:41] <@coblee> so what would your current logic be?
[15:41] <luke-jr> coblee: depends on how the scrypt kernels work
[15:41] <luke-jr> if they are easily reconfigured, it makes sense to support that
[15:42] <@coblee> pooler, is the optimized scrypt easy to reconfigure?
[15:42] <+pooler> configured yes, but optimization requires manual tweaking for every parameter set
[15:42] <+pooler> so in practice no.
[15:43] <@coblee> well, i guess that would make it useless to have these params parsed
[15:43] <luke-jr> pooler: could the optimization tweaks be part of the JSON reply? ;)
[15:43] <+pooler> i think i see what you mean
[15:43] <+pooler> but no, i don't think so
[15:44] <@coblee> luke-jr: are you serious?
[15:44] <+pooler> or maybe yes but it would require a lot of research
[15:44] <luke-jr> coblee: I don't pretend to know how scrypt works.
[15:44] <@coblee> why would litecoind tell you how to optimize your scrypt impl
[15:44] <+pooler> coblee: i know it sounds strange :)
[15:44] <luke-jr> ok, sounds like a string is the best option
[15:45] <luke-jr> worst case someone can just parse it
[15:45] <+pooler> true
[15:45] <@coblee> yes ok. sticking with scrypt(1024,1,1) then
[15:45] <+pooler> or scrypt:1024,1,1
[15:45] <+pooler> now wait a minute
[15:45] <+pooler> miners should also have an potion to manually specify the algo
[15:46] <+pooler> *option
[15:46] <luke-jr> "scrypt(1024,1,1)" seems clear
[15:46] <luke-jr> pooler: they already do
[15:46] <+pooler> i know :)
[15:46] <+pooler> but the current option is just "scrypt"
[15:46] <+pooler> so would that need to be deprecated?
[15:46] <luke-jr> eventually, I plan to make it -a scrypt
[15:47] <luke-jr> or -a 'scrypt(…)'
[15:47] <luke-jr> or -a 'sha256:sse2_32'