libera #monero-pow

6 Nov 2021

Monero's Proof of Work algorithm (RandomX) and related topics. Use #p2pool-log and #p2pool-mini for P2Pool discussions. Anti-spam active: PM hyc for voice.

• 13:51
  hyc
  hey, can someone with an Intel Mac verify this? tevador/RandomX #216#issuecomment-886029727
• 20:25
  hyc
  ok selsta verified for me. sech1, when you get a chance, mebbe approve/merge the last 2 PRs
• 20:27
  sech1
  hyc #217 and #222?
• 20:27
  hyc
  yep
• 20:28
  hyc
  I had an outstanding question on #222 tho
• 20:28
  hyc
  if you can answer, that'd be good
• 20:30
  sech1
  I have no idea, I didn't even know about this double column thing before today
• 20:31
  hyc
  have you built DLL with msvc recently?
• 20:32
  sech1
  I never build this DLL actually
• 20:32
  hyc
  oh, I thought you said you ran into this problem before on windows
• 20:32
  sech1
  It was in debug MSVC build, with static randomx lib
• 20:33
  hyc
  huh. interesting. I thought this was only a problem for shared libs, but oh well.
• 20:33
  sech1
  I don't think #222 will change debug MSVC behavior
• 20:34
  hyc
  you don't think it will fix anything?
• 20:34
  sech1
  because it's about external calls, not internal jumps within the same asm file
• 20:34
  sech1
  no, it definitely fixes some issues with linker
• 20:34
  sech1
  MSVC just does its own shenanigans in debug build
• 20:35
  hyc
  ah
• 20:35
  sech1
  like placing jmp trampoline for every function
• 20:46
  tevador
  MSVC debug build still crashes
• 20:52
  hyc
  have you got a trace of exactly where it crashes?
• 20:53
  hyc
  wondering if it's related to the line I commented about, or completely different location
• 20:53
  tevador
  I think it's an unrelated issue
• 20:58
  sech1
  in debug MSVC build? It crashes because pointer to functions were not pointing to the actual ASM code, so all size and ptr diff calculations were wrong
• 20:58
  tevador
  crashes here: github.com/tevador/RandomX/blob/master/src/jit_compiler_x86.cpp#L223
• 20:58
  sech1
  I have a workaround for this: SChernykh/RandomX 1adc7d8#diff-3d4646054ab2a831c4228adf316a676bbffaa2e65b19f6ceeb1cdf068484eff4R98
• 20:58
  tevador
  because epilogueSize is negative
• 20:59
  tevador
  can you PR it?
• 21:01
  sech1
  my branch is quite divergent from mainline, I'll make a separate PR tomorrow
• 21:01
  hyc
  cool. then 222 can go in as-is and your PR will take care of the rest
• 21:02
  tevador
  everything has been merged
• 21:03
  hyc
  ah just got the last email from github. cool
• 21:04
  sech1
  or maybe I'll PR today, it shouldn't take much time
• 21:12
  tevador
  soon it will be 2 years since RandomX activation on mainnet and I'm still waiting for shelby3's ASIC
• 21:13
  hyc
  lol
• 21:13
  hyc
  or linzhi's
• 21:14
  tevador
  linzhi must be bankrupt by now, their ASICs have bricked themselves by being too late, DAG won't fit anymore
• 21:15
  tevador
  ^I mean their ethereum stuff
• 21:15
  sech1
  tevador/RandomX #225
• 21:19
  tevador
  btw any info on how wownero's pool blocking strategy has been going?
• 21:19
  sech1
  works so far
• 21:19
  sech1
  I've been mining it solo for quite a while, but then switched all my servers to p2pool
• 21:21
  tevador
  the next step should be bundling p2pool with monerod
• 21:21
  hyc
  I'd like to see it integrated. otherwise wasting a lot of RAM on caches & datasets
• 21:22
  tevador
  1 GH/s of braindead miners still on minexmr
• 21:23
  hyc
  huh. I got 17 payouts today
• 21:23
  hyc
  previous was oct 27, nothing in between
• 21:28
  sech1
  hyc integrated how? It's completely different codebases, monerod doesn't use libuv. Maybe monerod can share RandomX caches via file mapping
• 21:28
  hyc
  just some mechanism so they can share randomx memory, yeah
• 21:29
  sech1
  it's better to have on monerod side via some RPC that tell the name of file mapping
• 21:29
  sech1
  or just some well known name
• 21:30
  hyc
  p2pool only needs to verify hashes right? why not just forward to monerod for verification
• 21:30
  sech1
  that's slower
• 21:30
  sech1
  maybe for "super-light" mode
• 21:31
  sech1
  But monerod doesn't have such RPC yet
• 21:31
  tevador
  in theory, RandomX could be moved completely out of monerod, something like github.com/tevador/randomx-service
• 21:32
  hyc
  yes, \i suggestted this a few days ago
• 21:32
  sech1
  without RandomX stuff, p2pool uses less than 100 MB of memory
• 21:32
  sech1
  and that's including 12 hours worth of sidechain blocks
• 21:34
  hyc
  suppose we do a randomx-service using unix domain sockets
• 21:37
  tevador
  even with localhost TCP, the overhead will be negligible compared to the ~1 ms it takes to calculate the hash
• 21:37
  sech1
  usually 2 ms when it's not in batch mode
• 21:37
  sech1
  because cache is cold
• 21:37
  sech1
  also, monerod uses only light mode normally
• 21:38
  hyc
  a single randomx-service that does mining plus p2pool + monerod verification would be slick
• 21:41
  sech1
  one more thing to set up?
• 21:41
  sech1
  probably better to keep it inside monerod
• 21:42
  tevador
  or monerod could get a RPC method for calculating hashes
• 21:43
  hyc
  yeah, that could work. all the necessary parts are already present
• 21:44
  sech1
  that would be limited to the current 2 RandomX caches though, but p2pool doesn't need more
• 21:48
  hyc
  so there's 2 actions, right? one is to validate if an incoming share was computed correctly\
• 21:48
  hyc
  the other is to submit a block to monerod if the incoming hash solves the mainchain difficulty
• 21:49
  hyc
  in the latter case, you can just send it to monerod without trying to validate it
• 21:51
  sech1
  I already send it before PoW validation
• 21:51
  sech1
  but PoW validation is done on p2pool side later anyway
• 23:39
  hyc
  can prob get a new monerod rpc ready before v0.18 release