daily pastebin goal
38%
SHARE
TWEET

IRC FreeNode #litecoin-dev Log - LukeJr learning Scrypt

a guest Apr 29th, 2013 145 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. [15:21] <luke-jr> coblee: what are 1024,1,1?
  2. [15:21] <@coblee> the scrypt parameters
  3. [15:21] <TimothyA> coblee: other than costing me a shitton of resources?
  4. [15:21] <@coblee> N=1024,p=1,r=1
  5. [15:21] <luke-jr> coblee: what are they?
  6. [15:22] <+pooler> http://www.tarsnap.com/scrypt.html
  7. [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
  8. [15:24] <@coblee> so you would just do a string comparison with "scrypt(1024,1,1)"
  9. [15:24] <@coblee> i don't think it makes sense to parse that string
  10. [15:24] <+pooler> well it shouldn't be too hard to implement the generic version
  11. [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?
  12. [15:26] <@coblee> seems like extra work to parse the string and pass it to the generic method just for that
  13. [15:26] <+pooler> well the string looks parsable :)
  14. [15:27] <+pooler> but yeah you're right
  15. [15:28] <@coblee> luke-jr suggested that we do this "algoparams":[1024,1,1] so it's already parsed
  16. [15:28] <+pooler> ha, interesting
  17. [15:28] <+pooler> so you'd add two fields
  18. [15:28] <@coblee> we could do that, but not sure if the added complication does us any good
  19. [15:29] <@coblee> yeah, and probably to pushpool too
  20. [15:29] <+pooler> the first suggestion of "scrypt:1024,1,1" was not that bad either
  21. [15:29] <+pooler> reminds me of some http headers
  22. [15:29] <@coblee> yeah
  23. [15:29] <@coblee> or "algorithm":["scrypt",1024,1,1]
  24. [15:30] <@coblee> i just think that right now there's only 2: "sha256(sha256())" and "scrypt(1024,1,1)"
  25. [15:30] <luke-jr> sha256 doesn't take parameters tho
  26. [15:30] <@coblee> so there's no need to generify it just for the sake of that
  27. [15:30] <luke-jr> it's just a number of rounds
  28. [15:31] <+pooler> yeah, it's a matter of definitions
  29. [15:31] <luke-jr> coblee: I'd say, since scrypt is fundamentally flawed POW for this, it doesn't justify changing anything ;)
  30. [15:31] <luke-jr> it's more likely justified by some future algorithm that *does* make sense
  31. [15:31] <@coblee> think of it as sha256(sha256(x)) and scrypt(x,1024,1,1)
  32. [15:31] <luke-jr> so should support that
  33. [15:32] <@coblee> luke-jr: so what would you recommend?
  34. [15:33] <luke-jr> "algo":"scrypt","algoopts":[1024,1,1],"rounds":1
  35. [15:33] <luke-jr> <.<
  36. [15:33] <@coblee> it's just 1 or 2 line changes to the code on my end, so I don't care that much
  37. [15:33] <luke-jr> "algo":"scrypt","algoopts":[1024,1,1],"algorounds":1
  38. [15:33] <luke-jr> "algo":"scrypt","algoopts":[1024,1,1],"algoiter":1
  39. [15:33] <+pooler> looks too much complication to me
  40. [15:34] <luke-jr> XD
  41. [15:34] <@coblee> luke-jr: i can see you're a perfectionist
  42. [15:34] <@coblee> that's going to force miners to implement extra generic code that would almost never be used
  43. [15:34] <+pooler> sha256^2 is called SHA-256d in many scientific papers
  44. [15:35] <luke-jr> coblee: nah, miners can take shortcuts and malfunction if things are outside their assumptions
  45. [15:35] <luke-jr> like they do now
  46. [15:35] <@coblee> like handle scrypt 5 times in case you get algoiter=5
  47. [15:35] <@coblee> luke-jr: then what's the point?
  48. [15:36] <@coblee> the code would just be: if algo=="scrypt", do scrypt(1024,1,1), otherwise do sha256^2
  49. [15:36] <@coblee> would you even bother writing the code the correctly handle it in bfgminer?
  50. [15:36] <@coblee> s/the/to
  51. [15:37] <luke-jr> coblee: the point is that you don't need to change the format every time you add a new algorithm
  52. [15:38] <@coblee> which happens about once in your lifetime
  53. [15:38] <@coblee> maybe twice :)
  54. [15:38] <+pooler> _maybe_
  55. [15:38] <luke-jr> I don't consider litecoin special.
  56. [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?
  57. [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
  58. [15:39] <+pooler> boys... i hate compromises...
  59. [15:41] <luke-jr> I don't care enough to argue it either tho
  60. [15:41] <@coblee> so what would your current logic be?
  61. [15:41] <luke-jr> coblee: depends on how the scrypt kernels work
  62. [15:41] <luke-jr> if they are easily reconfigured, it makes sense to support that
  63. [15:42] <@coblee> pooler, is the optimized scrypt easy to reconfigure?
  64. [15:42] <+pooler> configured yes, but optimization requires manual tweaking for every parameter set
  65. [15:42] <+pooler> so in practice no.
  66. [15:43] <@coblee> well, i guess that would make it useless to have these params parsed
  67. [15:43] <luke-jr> pooler: could the optimization tweaks be part of the JSON reply? ;)
  68. [15:43] <+pooler> i think i see what you mean
  69. [15:43] <+pooler> but no, i don't think so
  70. [15:44] <@coblee> luke-jr: are you serious?
  71. [15:44] <+pooler> or maybe yes but it would require a lot of research
  72. [15:44] <luke-jr> coblee: I don't pretend to know how scrypt works.
  73. [15:44] <@coblee> why would litecoind tell you how to optimize your scrypt impl
  74. [15:44] <+pooler> coblee: i know it sounds strange :)
  75. [15:44] <luke-jr> ok, sounds like a string is the best option
  76. [15:45] <luke-jr> worst case someone can just parse it
  77. [15:45] <+pooler> true
  78. [15:45] <@coblee> yes ok. sticking with scrypt(1024,1,1) then
  79. [15:45] <+pooler> or scrypt:1024,1,1
  80. [15:45] <+pooler> now wait a minute
  81. [15:45] <+pooler> miners should also have an potion to manually specify the algo
  82. [15:46] <+pooler> *option
  83. [15:46] <luke-jr> "scrypt(1024,1,1)" seems clear
  84. [15:46] <luke-jr> pooler: they already do
  85. [15:46] <+pooler> i know :)
  86. [15:46] <+pooler> but the current option is just "scrypt"
  87. [15:46] <+pooler> so would that need to be deprecated?
  88. [15:46] <luke-jr> eventually, I plan to make it -a scrypt
  89. [15:47] <luke-jr> or -a 'scrypt(…)'
  90. [15:47] <luke-jr> or -a 'sha256:sse2_32'
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
 
Top