BIBLEPAY - RANDOMX INTEGRATION

    Yeah i was getting the same error this morning but on windows10.

I think you were in the pool actually, you can see in block history that you were mining for hours.

Thank you, I have now got it the external and wallet set up and am mining on testnet

http://rxtest.biblepay.org/workers (BBP)
ygsYVjsR5RamCuiXyHUAoZb7nq8aM1WDUP   1   0   100%   21.47 KH

https://minexmr.com/#worker_stats (XMR pool to test)
16.67 H/s   0.00 H/s   410000   0   0   4 minutes ago   *base address*

Code: [Select]

vm.nr_hugepages = 4
1GB pages successfully enabled
 * CPU          Intel(R) Xeon(R) CPU X7560 @ 2.27GHz (2) x64 -AES
                L2:0.5 MB L3:48.0 MB 4C/4T NUMA:1
 * MEMORY       1.4/3.9 GB (37%)
 * DONATE       10%
 * ASSEMBLY     auto:none
 * POOL #1      rxtest.biblepay.org:3008 algo auto
 * COMMANDS     hashrate, pause, resume
 * OPENCL       disabled
 * CUDA         disabled
[2020-02-14 06:49:37.424]  net  use pool rxtest.biblepay.org  Orphan Charity
[2020-02-14 06:49:37.424]  net  new job from rxtest.biblepay.org diff 75000 algo rx/0 height 2033499
[2020-02-14 06:49:37.424]  rx   init dataset algo rx/0 (4 threads) seed 154eb7a21cd32a59...
[2020-02-14 06:49:37.426]  rx   allocated 2336 MB (2080+256) huge pages 0% 0/1168 +JIT (1 ms)
[2020-02-14 06:50:26.275]  rx   dataset ready (48850 ms)
[2020-02-14 06:50:26.276]  cpu  use profile  *  (2 threads) scratchpad 2048 KB
[2020-02-14 06:50:26.309]  cpu  READY threads 2/2 (2) huge pages 100% 2/2 memory 4096 KB (33 ms)
[2020-02-14 06:50:52.508]  cpu  accepted (1/0) diff 1 BBP (0 ms)
[2020-02-14 06:51:26.459] speed 10s/60s/15m 135.1 134.1 n/a H/s max 183.3 H/s
[2020-02-14 06:51:35.559]  net  new job from rxtest.biblepay.org diff 54217 algo rx/0 height 2033500
[2020-02-14 06:52:26.599] speed 10s/60s/15m 131.6 137.5 n/a H/s max 183.3 H/s
[2020-02-14 06:53:11.739] [rxtest.biblepay.org:3008] read error: "end of file"
[2020-02-14 06:53:12.776]  net  orphan donations started
[2020-02-14 06:53:12.776]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033500
[2020-02-14 06:53:20.105]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033501
[2020-02-14 06:53:26.833] speed 10s/60s/15m 138.0 125.3 n/a H/s max 183.3 H/s
[2020-02-14 06:53:33.432]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033502
[2020-02-14 06:54:27.094] speed 10s/60s/15m 123.8 117.0 n/a H/s max 183.3 H/s
[2020-02-14 06:55:27.334] speed 10s/60s/15m 113.1 113.6 n/a H/s max 183.3 H/s
[2020-02-14 06:55:31.757] [rxtest.biblepay.org:3008] read error: "end of file"
[2020-02-14 06:56:27.530] speed 10s/60s/15m 155.6 147.5 n/a H/s max 200.6 H/s
[2020-02-14 06:57:27.724] speed 10s/60s/15m 117.2 148.3 n/a H/s max 220.5 H/s
[2020-02-14 06:58:27.906] speed 10s/60s/15m 135.9 151.8 n/a H/s max 236.7 H/s
[2020-02-14 06:58:33.536]  net  new job from rxtest.biblepay.org-Charity diff 50000 algo rx/0 height 2033502
[2020-02-14 06:59:01.798] [rxtest.biblepay.org:3008] read error: "end of file"
[2020-02-14 06:59:28.023] speed 10s/60s/15m 140.9 170.6 n/a H/s max 236.7 H/s
[2020-02-14 06:59:37.751]  net  new job from rxtest.biblepay.org-Charity diff 33333 algo rx/0 height 2033503

note the errors
[2020-02-14 06:55:31.757] [rxtest.biblepay.org:3008] read error: "end of file"

debug.log (tail)

Code: [Select]

2020-02-14 14:54:36 ProcessMessages(version, 141 bytes) FAILED peer=2111
2020-02-14 14:54:41 Flushed 49 addresses to peers.dat  11ms
2020-02-14 14:54:52 ProcessMessages(version, 141 bytes) FAILED peer=2112
2020-02-14 14:55:10 ProcessMessages(version, 141 bytes) FAILED peer=2113
2020-02-14 14:55:36 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 28764 fInitialDownload=0
2020-02-14 14:55:36 ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-14 14:55:36 UpdateTip: new best=7394ea2f327ddbd1bbbb865412bb2106a20249d63455c894351c3ed5ef0844cf height=28764 version=0x50000010 log2_work=48.51122856 tx=46915 date='2020-02-14 14:54:42' progress=0.999988 cache=11.7MiB(63827txo) evodb_cache=1.5MiB
2020-02-14 14:55:36 {PNB}: ACC  ProcessMessages(version, 141 bytes) FAILED peer=2114
2020-02-14 14:55:50 ProcessMessages(version, 141 bytes) FAILED peer=2115
2020-02-14 14:55:59 ProcessMessages(version, 141 bytes) FAILED peer=2116
2020-02-14 14:57:05 ProcessMessages(version, 141 bytes) FAILED peer=2117
2020-02-14 14:57:10 ProcessMessages(version, 141 bytes) FAILED peer=2118
2020-02-14 14:57:28 ProcessMessages(version, 141 bytes) FAILED peer=2119
2020-02-14 14:57:31 ProcessMessages(version, 141 bytes) FAILED peer=2120
2020-02-14 14:57:41 ProcessMessages(version, 141 bytes) FAILED peer=2121
2020-02-14 14:57:42 ProcessMessages(version, 141 bytes) FAILED peer=2122
2020-02-14 14:57:55 CGovernanceObject::RequestOrphanObjects -- number objects = 0
2020-02-14 14:58:00 ProcessMessages(version, 141 bytes) FAILED peer=2123
2020-02-14 14:58:00 ProcessMessages(version, 141 bytes) FAILED peer=2124
2020-02-14 14:58:01 ProcessMessages(version, 141 bytes) FAILED peer=2125
2020-02-14 14:58:12 ProcessMessages(version, 141 bytes) FAILED peer=2126
2020-02-14 14:59:02 AdvertiseLocal: advertising address 45.62.240.90:40001


Let me know if the processMessages have gone away once you synced to the top.
The end of file error is pretty normal; that happens ocasionally and the miner recovers from it.
But Ill try to trap that today and see what the root cause is while Im looking for the timeout issue.

EDIT:
Ok I see you are synced to the top.  Ok, after I look into the xmrig timeout, I will look into my dev nodes log and see if I have the same process messages errors.

Could you perhaps start the pool at 10k difficulty then go up? 75k is too high for my little single 4c/4t machine.

75k is the monero diff for the current block, but the actual pool difficulty is only 1 (for both XMR or BBP).

Thats great, yeah on the bbp part dropping out, I see the same behavior.  What I have discovered is I can dual mine for about 8-14 hours or so, then the monero side keeps working and the bbp side stops.  I have a feeling that something in the code has a timeout (on the bbp side in xmrig) that I need to fix. 

In the mean time, all, please just restart the miner after a few hours if the bbp drops out and you will see yourself in the pool again.

You can clearly see the problem btw on the xmrig side by looking in the console window and seeing no "BBP 1" shares solved.

But anyway I wanted to ask you the most crucial question (Im glad to hear the wattage is the same).  Could you please do a side by side baseline between pure XMR mining from their xmrig, vs biblepay dual mining using our xmrig?  That is show us your hashrate for XMR alone vs dual XMR-BBP?  Id like to see the efficiency drop % that our blakehashes take away from the total?

Thanks!

Sure thing i will do some comparisons in a few hours on a few diffrent cpus.

Code: [Select]

2020-02-14 14:55:50 ProcessMessages(version, 141 bytes) FAILED peer=2115
2020-02-14 14:55:59 ProcessMessages(version, 141 bytes) FAILED peer=2116
2020-02-14 14:57:05 ProcessMessages(version, 141 bytes) FAILED peer=2117
2020-02-14 14:57:10 ProcessMessages(version, 141 bytes) FAILED peer=2118
2020-02-14 14:57:28 ProcessMessages(version, 141 bytes) FAILED peer=2119
2020-02-14 14:57:31 ProcessMessages(version, 141 bytes) FAILED peer=2120
2020-02-14 14:57:41 ProcessMessages(version, 141 bytes) FAILED peer=2121
2020-02-14 14:57:42 ProcessMessages(version, 141 bytes) FAILED peer=2122
2020-02-14 14:57:55 CGovernanceObject::RequestOrphanObjects -- number objects = 0
2020-02-14 14:58:00 ProcessMessages(version, 141 bytes) FAILED peer=2123
2020-02-14 14:58:00 ProcessMessages(version, 141 bytes) FAILED peer=2124
2020-02-14 14:58:01 ProcessMessages(version, 141 bytes) FAILED peer=2125
2020-02-14 14:58:12 ProcessMessages(version, 141 bytes) FAILED peer=2126
2020-02-14 14:59:02 AdvertiseLocal: advertising address 45.62.240.90:40001


So looking at this processMessages issue, yes, I confirm this is something new that has been introduced into the RandomX core version (develop) and all of our nodes are doing it for some reason when they send the version message.  So far it has not been affecting us actually connecting with each other but yet this is something that needs fixed.

Ill just put this on the todo list for now as my goal today is to:
- Fix the bug where we drop the bbp mining after hours in xmrig
- Expose the monero shares in the pool

Here comes some numbers from my part without fiddling to much with threads and affinity settings.  Large pages and MSR mod is active on all tests.

Ryzen 5 3600@4ghz, msi b450m Gaming plus, 1.2v vcore, 12 threads, 2x4gb 2666 cl16

• Bbp+xmr=13900-14000HPS
• 70watts (package powerdraw)

• xmrig 5.3.0, monero hashrate = 6900-7050HPS
• 69-70watts (package powerdraw)

Ryzen 5 1600 (14nm)@3.3ghz, Asus b350 rog strix, 1,05v vcore, 6 threads, --cpu-affinity 0x555 1x8gb 3200mhz cl16

• Bbp+xmr= 7863-7900HPS
• 55 watts (package powerdraw)

• xmrig 5.3.0 , monero hashrate=3911-3950HPS
• 55watts (package powerdraw)

[email protected], msi x399 gaming pro carbon ac, 1,15v vcore, 16 threads --cpu-affinity 0x5D75D7, 4x4gb 3200mhz cl16

• Bbp+xmr=16100-16300HPS
• 140-145watts (package powerdraw)

• xmrig 5.3.0, monero hashrate= 8050-8400HPS
• 140-145 watts (package powerdraw)

So looking at this processMessages issue, yes, I confirm this is something new that has been introduced into the RandomX core version (develop) and all of our nodes are doing it for some reason when they send the version message.  So far it has not been affecting us actually connecting with each other but yet this is something that needs fixed.

Ill just put this on the todo list for now as my goal today is to:
- Fix the bug where we drop the bbp mining after hours in xmrig
- Expose the monero shares in the pool

I noticed how the some cycles are donated to charity for both BBP and XMR. The donation appears to be identified by the "-Charity" to be transparent.

Code: [Select]

[2020-02-14 12:04:46.623]  net  orphan donations started
[2020-02-14 12:04:46.624]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033630
[2020-02-14 12:04:46.774]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033631
[2020-02-14 12:05:08.887]  cpu  accepted (1/0) diff 75000 XMR-Charity (0 ms)
[2020-02-14 12:05:23.498]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033632
[2020-02-14 12:05:24.817] speed 10s/60s/15m 118.2 240.9 n/a H/s max 351.7 H/s
[2020-02-14 12:05:28.819]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033633
[2020-02-14 12:06:24.977] speed 10s/60s/15m 164.8 164.5 n/a H/s max 351.7 H/s
[2020-02-14 12:07:25.180] speed 10s/60s/15m 163.5 160.8 n/a H/s max 351.7 H/s
[2020-02-14 12:08:25.328] speed 10s/60s/15m 180.7 176.4 n/a H/s max 351.7 H/s
[2020-02-14 12:09:25.543] speed 10s/60s/15m 143.6 154.2 n/a H/s max 351.7 H/s
[2020-02-14 12:10:25.847] speed 10s/60s/15m 149.0 146.0 n/a H/s max 351.7 H/s
[2020-02-14 12:10:28.868]  net  new job from rxtest.biblepay.org-Charity diff 14249 algo rx/0 height 2033633
[2020-02-14 12:11:05.134]  net  new job from rxtest.biblepay.org-Charity diff 11974 algo rx/0 height 2033634
[2020-02-14 12:11:15.687]  cpu  accepted (2/0) diff 11974 XMR-Charity (0 ms)
[2020-02-14 12:11:19.910]  net  new job from rxtest.biblepay.org-Charity diff 11974 algo rx/0 height 2033635
[2020-02-14 12:11:26.076] speed 10s/60s/15m 157.2 155.5 n/a H/s max 351.7 H/s
[2020-02-14 12:12:26.316] speed 10s/60s/15m 168.9 190.3 n/a H/s max 351.7 H/s
[2020-02-14 12:13:26.569] speed 10s/60s/15m 170.8 170.9 n/a H/s max 351.7 H/s
[2020-02-14 12:13:39.624]  net  new job from rxtest.biblepay.org-Charity diff 10000 algo rx/0 height 2033636
[2020-02-14 12:14:26.781] speed 10s/60s/15m 252.3 183.5 n/a H/s max 351.7 H/s
[2020-02-14 12:14:39.043]  net  new job from rxtest.biblepay.org-Charity diff 10000 algo rx/0 height 2033637
[2020-02-14 12:14:46.625]  net  orphan donations finished

I can see the start and end of the orphan donations and then afterward I can see that I am now mining to my wallet, I presume.

Code: [Select]

[2020-02-14 12:14:46.628]  net  new job from rxtest.biblepay.org diff 10000 algo rx/0 height 2033637
[2020-02-14 12:14:50.578]  cpu  accepted (3/0) diff 10000 XMR (91 ms)
[2020-02-14 12:14:57.340]  cpu  accepted (4/0) diff 10000 XMR (90 ms)
[2020-02-14 12:14:57.568]  cpu  accepted (5/0) diff 10000 XMR (90 ms)
[2020-02-14 12:15:01.172]  net  new job from rxtest.biblepay.org diff 10000 algo rx/0 height 2033638


75k is the monero diff for the current block, but the actual pool difficulty is only 1 (for both XMR or BBP).

Ok, I must have read the xmrig console text wrong then.


Initially, it took 15 minutes last night for me to get a share... then started being more consistent. So, that's what lead me to believe it was set at a high diff.

Ok, I must have read the xmrig console text wrong then.


Initially, it took 15 minutes last night for me to get a share... then started being more consistent. So, that's what lead me to believe it was set at a high diff.

Not sure if xmrig proxy will work with this bbp-xmrig miner but it would be a way to get several low hashing rigs to be shown as 1 high performance one.

Ok, I must have read the xmrig console text wrong then.


Initially, it took 15 minutes last night for me to get a share... then started being more consistent. So, that's what lead me to believe it was set at a high diff.

Yeah there are large swings sometimes, I solved 5 bbp for 1 randomx, then the opposite later.

I look forward to this next version will be more transparent.

Here comes some numbers from my part without fiddling to much with threads and affinity settings.  Large pages and MSR mod is active on all tests.

Ryzen 5 3600@4ghz, msi b450m Gaming plus, 1.2v vcore, 12 threads, 2x4gb 2666 cl16

• Bbp+xmr=13900-14000HPS
• 70watts (package powerdraw)

• xmrig 5.3.0, monero hashrate = 6900-7050HPS
• 69-70watts (package powerdraw)

Ryzen 5 1600 (14nm)@3.3ghz, Asus b350 rog strix, 1,05v vcore, 6 threads, --cpu-affinity 0x555 1x8gb 3200mhz cl16

• Bbp+xmr= 7863-7900HPS
• 55 watts (package powerdraw)

• xmrig 5.3.0 , monero hashrate=3911-3950HPS
• 55watts (package powerdraw)

[email protected], msi x399 gaming pro carbon ac, 1,15v vcore, 16 threads --cpu-affinity 0x5D75D7, 4x4gb 3200mhz cl16

• Bbp+xmr=16100-16300HPS
• 140-145watts (package powerdraw)

• xmrig 5.3.0, monero hashrate= 8050-8400HPS
• 140-145 watts (package powerdraw)

This is really excellent.

Thank you very much.

I'll put this in a spreadsheet right now, and attach it to the op post.

What this points to is a 99% efficiency level, (or truly a 198% hashpower increase without much overhead at all).  This is great, because our mission is being accomplished without any compromises.  We are not compromising blockchain security, because each solution must be based on the last block in our equation.  The miners receive two sources of income.

Its very interesting.  It appears to have the potential to be 'the cpu worlds' version of merged mining.

So yes, mining XMR alone is actually barely profitable, but the way we can look at this is our miner gets the electric bill covered from the XMR side and the BBP side is potentially pure profit.  BBP receives a revenue stream for orphan sponsorships that doesn't add sell pressure.  I feel this has the potential to take off.

Btw everyone, I spoke to Steven from SAI.ngo and he confirmed that we can sponsor Venezuelan orphans for the wholesale rate of $20.  Ill post more on that topic on the main thread.

Ok, I made a wiki page for it:
https://wiki.biblepay.org/RandomX_Hashing_Speed_Comparison

I will post it in the op.

I noticed how the some cycles are donated to charity for both BBP and XMR. The donation appears to be identified by the "-Charity" to be transparent.

Code: [Select]

[2020-02-14 12:04:46.623]  net  orphan donations started
[2020-02-14 12:04:46.624]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033630
[2020-02-14 12:04:46.774]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033631
[2020-02-14 12:05:08.887]  cpu  accepted (1/0) diff 75000 XMR-Charity (0 ms)
[2020-02-14 12:05:23.498]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033632
[2020-02-14 12:05:24.817] speed 10s/60s/15m 118.2 240.9 n/a H/s max 351.7 H/s
[2020-02-14 12:05:28.819]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033633
[2020-02-14 12:06:24.977] speed 10s/60s/15m 164.8 164.5 n/a H/s max 351.7 H/s
[2020-02-14 12:07:25.180] speed 10s/60s/15m 163.5 160.8 n/a H/s max 351.7 H/s
[2020-02-14 12:08:25.328] speed 10s/60s/15m 180.7 176.4 n/a H/s max 351.7 H/s
[2020-02-14 12:09:25.543] speed 10s/60s/15m 143.6 154.2 n/a H/s max 351.7 H/s
[2020-02-14 12:10:25.847] speed 10s/60s/15m 149.0 146.0 n/a H/s max 351.7 H/s
[2020-02-14 12:10:28.868]  net  new job from rxtest.biblepay.org-Charity diff 14249 algo rx/0 height 2033633
[2020-02-14 12:11:05.134]  net  new job from rxtest.biblepay.org-Charity diff 11974 algo rx/0 height 2033634
[2020-02-14 12:11:15.687]  cpu  accepted (2/0) diff 11974 XMR-Charity (0 ms)
[2020-02-14 12:11:19.910]  net  new job from rxtest.biblepay.org-Charity diff 11974 algo rx/0 height 2033635
[2020-02-14 12:11:26.076] speed 10s/60s/15m 157.2 155.5 n/a H/s max 351.7 H/s
[2020-02-14 12:12:26.316] speed 10s/60s/15m 168.9 190.3 n/a H/s max 351.7 H/s
[2020-02-14 12:13:26.569] speed 10s/60s/15m 170.8 170.9 n/a H/s max 351.7 H/s
[2020-02-14 12:13:39.624]  net  new job from rxtest.biblepay.org-Charity diff 10000 algo rx/0 height 2033636
[2020-02-14 12:14:26.781] speed 10s/60s/15m 252.3 183.5 n/a H/s max 351.7 H/s
[2020-02-14 12:14:39.043]  net  new job from rxtest.biblepay.org-Charity diff 10000 algo rx/0 height 2033637
[2020-02-14 12:14:46.625]  net  orphan donations finished

I can see the start and end of the orphan donations and then afterward I can see that I am now mining to my wallet, I presume.

Code: [Select]

[2020-02-14 12:14:46.628]  net  new job from rxtest.biblepay.org diff 10000 algo rx/0 height 2033637
[2020-02-14 12:14:50.578]  cpu  accepted (3/0) diff 10000 XMR (91 ms)
[2020-02-14 12:14:57.340]  cpu  accepted (4/0) diff 10000 XMR (90 ms)
[2020-02-14 12:14:57.568]  cpu  accepted (5/0) diff 10000 XMR (90 ms)
[2020-02-14 12:15:01.172]  net  new job from rxtest.biblepay.org diff 10000 algo rx/0 height 2033638


Yes, exactly.  Over a longer period, say overnight, it should spend roughly 10% of its time donating to the pools XMR address.
I'm about to release the new pool version which computes the randomx share count and exposes it on the page also, so hopefully this will make it completely transparent.

We will also expose the pools charity address somewhere on the page, so they can click a tab and see the donations that have been mined in a given month.  I think one way we can work around Moneros anonymity features, is we can train people to look at 'the last 4 weeks of revenue mined to the XMR charity address for the pool'.  That should roughly match the monthly pool charity expenses and give a pretty close idea they are in compliance.  The script that checks the pool can work over a longer period etc.

Also, I just realized, we can make an api available to people who want to scrape the shares.  This would allow anyone to see that the pool is actually hashing 10% to orphan charity shares.  I know in the future we will need to enforce that so eventually we can release the plan that will spork-check the pools adresses, but in the launch phase, anyone can scrape the orphan share count once per hour off the pool api, and log the charity shares solved and the total pools share solved.  This should show 10% of our hashes are going to charity.

So, I think this idea is actually viable from what I can tell from a high level.

So looking at this processMessages issue, yes, I confirm this is something new that has been introduced into the RandomX core version (develop) and all of our nodes are doing it for some reason when they send the version message.  So far it has not been affecting us actually connecting with each other but yet this is something that needs fixed.

Ill just put this on the todo list for now as my goal today is to:
- Fix the bug where we drop the bbp mining after hours in xmrig
- Expose the monero shares in the pool

Ok, thank you for reporting the processMessages issue, and also starting to recreate your sancs.  I haven't gotten around to the sancs yet (I turned off chainlocks in testnet temporarily so we can run free of sancs for a while).  But yes we can get back to that as soon as we prove RX is running reliably.

I will check out the process messages very soon - hopefully today.

In the mean time I have a new version of the pool to be released and a new miner (that adresses the shutoff bug after N hours).

Let me explain how these features work and then we can get back to checking the core client messages.

** XMRIG 5.5.6 - Leisure Upgrade for TestNet **


Xmrig 5.5.6 is ready.  In this version we solved the issue where the bbp side mining drops out after N hours. 

Also, the rxtest pool has been upgraded.
Now you can see your XMR and BBP shares in the worker stats, and I have extended the round time to 15 minutes so we can see a clearer picture of orphan charity vs bbp mining in the worker stats.

As far as XMR transparency, we have added a new tab to the nomp pool:  XMR Inquiry.
From here you can click it and type in your XMR address and click search.  The minexmr pool will show you what you are owed on the xmr side.
To adjust your reward threshhold you can decrease it from there or request an immediate withdrawal.

So as you can see, we pass all RandomX XMR shares directly through to minexmr, hence the reason we are leveraging their website for XMR payments.

In the near future I will expose a BX link for the pools XMR charity address also - so users can click on that address and also see the BX transactions (IE what the pool generated for charity).

Ok, thank you for reporting the processMessages issue, and also starting to recreate your sancs.  I haven't gotten around to the sancs yet (I turned off chainlocks in testnet temporarily so we can run free of sancs for a while).  But yes we can get back to that as soon as we prove RX is running reliably.

I will check out the process messages very soon - hopefully today.

In the mean time I have a new version of the pool to be released and a new miner (that adresses the shutoff bug after N hours).

Let me explain how these features work and then we can get back to checking the core client messages.

So I debugged the processMessages (FAIL) error, and the great news is it is a harmless error and has something to do with the way we are checking the minimum peer governance version, and the message in the log is harmless.  I fixed this for the next version; but no rush in releasing it til we have a new testnet release.

I also discovered while testing your reported bug that we have an inefficiency to fix while scanning randomx headers - it turns out we can speed up the process for assessing GSCs and memorizing the prayers ; Ill let this wait also til the next release also.