Bible Pay

Archives => TestNet Discussion Archive => Topic started by: Rob Andrews on February 07, 2020, 10:28:39 AM

Title: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 07, 2020, 10:28:39 AM
RandomX Integration


Welcome to the Biblepay-RandomX Integration Testing thread.

In this thread we will be testing:
Dash 0.14.0.5 changes (these occurred between Nov 2019 and Jan 2020).  These include: https://github.com/biblepay/biblepay-evolution/commit/34851a046392e169fcfa90a0bbcd7a01e1096090 which are ddos and chainlocks enhancements.
Test BiblePay Core RandomX hashes, RandomX solo mining, RX multithread solo mining.
Test xmrig->bbpcore mining against bbpcore using RX.
Test xmrig dual-hash mining.
Test bbp->nomp pool mining.
Stress test biblepay; verify RAM utilization and reliability in running for days.
Test BBP against sancs; regression test sanctuary abilities.
Verify how many BBP memory footprints can fit on a VM.




Starting Version:    1.5.0.2+


(Please ensure your version is greater than this, otherwise your testnet branch will not sync.  We are at block  ____28050_____________ as of February 9th, 2020).
BlockHash 28189:
c6fd*****


Testnet Download Links:


Ready:
     Windows 64-bit:      https://biblepay.org/biblepayevo64develop.exe
     Linux PC 64bits Daemon:     https://biblepay.org/biblepayd-evo-testnet-x86_64-pc-linux-gnu.tar.gz
     Linux 64 bits QT:       https://biblepay.org/biblepay-qt-evo-testnet-x86_64-pc-linux-gnu.tar.gz
     MacOS QT: https://biblepay.org/biblepaycore-evo-testnet.dmg

     Linux 64 bits II (QT/biblepayd/biblepay-cli) zip:  https://biblepay.org/bbp-lin-develop-64.zip

Not ready:
(Unknown state, probably wont run due to memory constraints in the future)
       Linux ARM64 daemon: https://biblepay.org/biblepayd-evo-testnet-aarch64-linux-gnu.tar.gz


To self compile:
https://github.com/biblepay/biblepay-evolution/blob/develop/BuildBiblePay.txt
** Note above:  The instructions have changed, see the changes for randomx.  **

The ETA for MainNet for RandomX  is   April 30th, 2020.




CONFIGURING FOR TESTNET:


Create a biblepaytest.conf file with the following contents:
testnet=1
debug=1

Place the file in ~/.biblepayevolution



Start testnet by typing:
./biblepay-qt -conf=biblepaytest.conf

(Note the blocks and chainstate will sync into the ./biblepayevolution/testnet3 folder.


NOTE: This version will also work side-by-side our production nodes,
so, you also have the option if you are short on machines, to run TestNet side by side a prod node!

To run a TestNet Sanctuary:
https://forum.biblepay.org/index.php?topic=391.msg5968#msg5968

How to create a deterministic sanc from scratch:
https://docs.dash.org/en/stable/masternodes/dip3-upgrade.html

__________________________________________________________________________________________________________________________________________________________________________________________


POOLS for TESTNET (RandomX):

http://rxtest.biblepay.org


Instructions to pool mine:

Launch xmrig.exe or xmrig with these args:

xmrig-bbp-win64.exe -o rxtest.biblepay.org:3008 -u your_biblepay_testnet_address -p your_monero_prod_address --threads nproc_count

Where your bbp receive address for testnet receives Biblepay rewards, and your monero prod address receives prod rewards.


___________________________________________________________________________________________________________________________________________________________________________________________
XMRIG - The dual-hash miner for Biblepay + XMR:

To download Xmrig - binaries are here:

linux-64-bit :  https://github.com/biblepay/xmrig/raw/master/binaries/xmrig-bbp-linux64
windows-64-bit:  https://github.com/biblepay/xmrig/raw/master/binaries/bbprig.zip
(Extract the zip file to a folder on your machine, such as c:\mining\).  Run the miner from a batch file in that subdirectory (this allows the miner to use the dependencies).

To build your own xmrig:
https://github.com/biblepay/xmrig

How to mine:
xmrig-bbp-win64.exe -o rxtest.biblepay.org:3008 -u your_biblepay_testnet_address -p your_monero_prod_address --threads nproc_count
Where your bbp receive address for testnet receives Biblepay rewards, and your monero prod address receives prod rewards.

___________________________________________________________________________________________________________________________________________________________________________________________

How to get a monero production wallet, without running the full monero client (How to get an XMR address to mine to):
Since it is not allowed to mine to SX, we need to go with the next best option.
I'm sure other SPV wallets exist, but I'm currently using this one:

https://mymonero.com/

Just install it, then create a wallet.  Then use that address for your mining reward address.
NOTE:  The XMR side of the pool has a complicated payment strategy that we will explain asap.    For now know that XMR is held until the balance gets to 1xmr, but we will explain how to lower the threshhold etc.

The BiblePay payment side works the same as usual:  After the mined block matures in the pool, all the BBP is dispersed automatically.
____________________________________________________________________________________________________________________________________________________________________________________________


What is so special about XMR+BBP dual-hash mining?  What entices me as an XMR miner to mine BiblePay+XMR?



How does this work, why am I earning double what I earn in XMR alone?

The way it works is when you mine XMR alone, the solution can only go to one pool because you are solving a blockheader based on the current height and time and nonce for Monero.
However, BiblePay, with RX integrated can also be solved *at the same time*.  How?  Every randomx hash is checked against our current height and difficulty, giving you one chance to win a biblepay block for every XMR hash.


Why is biblepay interested in integrating wtih XMR?

We are interested because we want more miners, because miners give us more PR.  And we want to help more orphans.  Theoretically, the more XMR miners that dual-hash-mine, the more of our 10% tithe goes to orphan-charity.  That is a win-win for us, XMR, and the orphans!

How are the payments allocated for the work I spend mining?

For every 100,000 hashes, 90,000 go toward your personal account and 10,000 toward our orphan-charity XMR address (IE we tithe 10% to orphan charity, dispersed in XMR liquidations to our charity partners).  Out of the 90,000 that go toward your personal account, every single hash has an equal chance at winning a BBP block.  On the biblepay side, we pay out 100% of the earnings to your personal BBP address (we keep no overhead, unless a pool charges a small bit of overhead, TBD).   On the orphan-charity side that we spend from our collected revenue for our foundation, our liquidated XMR is guaranteed to go 100% to our voted charity (with no overhead kept by us).  We only partner with charities who are 75%+ efficient, such as compassion.com, Cameroon-one, Kairos, etc (therefore the maximum passes through to the children in need.  You can also see our orphan collage at https://accountability.biblepay.org).

__________________________________________________________________________________________________________________________________________________________________________________________________

Hashrate comparison chart, supplied by earlzmoade, showing a 200% increase in hashrates between xmrig plain vanilla and xmrig dual mode:

https://wiki.biblepay.org/RandomX_Hashing_Speed_Comparison









Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 08, 2020, 03:14:49 PM
Exciting times!  We look forward to an influx of thousands of randomx miners into biblepay to help donate to orphan charity!

Let's get started by simply testing the core wallet first.


For now, please restart the node with -erasechain=1 as transitioning to the first randomx block will tell you 'block index needs rebuilt, rebuild now?'  If you do not start with an empty chain, you can do that rebuild also.  Please see the op post for the blockhash and the block number.

Once we confirm this, then let's try solo mining.

Note that solo mining from the BBPcore wallet is 40 times slower than xmrig mining.  This is because the rx-core small-footprint algo is designed to conserve ram and is designed for syncing, and for efficient use of resources on sancs (this lets sancs run multiple copies and exchanges run bbp without kicking us off the exchange).

Each biblepaycore solo mining thread uses up 256meg of ram (due to the randomx virtual machine).  BE Very Careful about how you start the miner!  As you can crash biblepay if you attempt to use all your machine's ram at once.  For example, first test it with 'setgenerate true 1'.  Then increase to 3.  Slowly increase to see how much ram you can tolerate losing on your machine. 

Know that it will never be profitable to solo mine using the built in miner - because it is tuned for syncing and core efficiency.  The purpose for the solo miner is to allow us to debug when all nodes have failed (IE testnet) and ensure randomx is working.  In prod, most likely everyone will be running xmrig. 

The randomx-nomp pool is almost ready.  But please dont try it yet.

We will need to revive our sancs.  Technically since the chain in testnet is still intact this should just mean 'exec revivesanc sancname'.

Good luck everyone!

Let's hope this project breathes new life into Biblepay and puts us in the top 50!

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 08, 2020, 06:48:25 PM
Ok, now 3 versions are ready:

Windows 64

Linux 64 bit biblepayd

Linux 64 bit QT

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 08, 2020, 06:58:10 PM
I just did a rough calculation, and it may be possible that just 8 new randomx miners would be able to support 1 Venezuelan orphan.

($25 of mining revenue per month = $2.50 towards orphan-charity, roughly) and at our potential wholesale rate, that means just 8 miners could sponsor one orphan.

I look forward to this test scenario.  We really can make a huge impact in the world if the goal is reached.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 08, 2020, 08:49:34 PM
See OP post - XMRig has been released for windows and linux.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 09, 2020, 08:50:36 AM
** Pause Testing **

Ok, I was able to mine up until the superblock, but since we have no sancs, this exploited a problem.

In creating a solution I have discovered a bug that needs fixed; so please halt testing until the next mandatory upgrade.


Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 10, 2020, 10:44:57 PM
BiblePay - Mandatory Upgrade for TestNet
1.5.0.2f

- Make randomx compatible with GSC superblocks



* See OP Post for updated blockhash.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 11, 2020, 10:16:17 AM
BiblePay - Mandatory Upgrade for TestNet
1.5.0.2f

- Make randomx compatible with GSC superblocks



* See OP Post for updated blockhash.

Ok everyone, it looks like testing is ready now.

- Windows, linux and mac binaries are released now.

- Remember to start with a clean chain, just pass -erasechain=1 when you start (this should get you over the hump at the randomx_cutover_height).

- The xmrig miner is ready, go ahead and download it and try it.

- The randomx nomp pool is up:    rxtest.biblepay.org
(I realize I have some hps ratios and labels to update still, but it appears to be functioning in a primitive form now).

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 11, 2020, 11:47:27 AM
This for sure is a nice step for   biblepay i think.

I will try testnet on one of my ryzen 1600s machine.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 12, 2020, 01:42:57 PM
So i tried to run xmrig-bbp miner but i just get this message  " The code execution cannot proceed because VCRUNTIME140_1.dll was not found"
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 12, 2020, 04:13:47 PM
So i tried to run xmrig-bbp miner but i just get this message  " The code execution cannot proceed because VCRUNTIME140_1.dll was not found"

Hi, please tell us your bitness and OS, and please paste the command line you used so I can reproduce?  (Please be sure to paste the exact command line so I can trace the filename also).

Thanks.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: sunk818 on February 12, 2020, 10:34:21 PM
Hi, please tell us your bitness and OS, and please paste the command line you used so I can reproduce?  (Please be sure to paste the exact command line so I can trace the filename also).

Thanks.


I have same error:
https://github.com/biblepay/xmrig/blob/master/binaries/xmrig-bbp-win64.exe (https://github.com/biblepay/xmrig/blob/master/binaries/xmrig-bbp-win64.exe)
Using Windows 10 64-bit
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: oncoapop on February 13, 2020, 01:46:20 AM
Results from compiling the Linux ubuntu 18.04 version from source,

Platform: Linux 4.15.0-76-generic #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020 x86_64 x86_64 x86_64 GNU
Hardware: 6 x vCPU x Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz with 16 Gb RAM (VPS)

Repo:
git clone http://github.com/biblepay/biblepay-evolution

Code: [Select]
# RandomX Part
>cd biblepay-evolution/src/crypto/RandomX

>biblepay-evolution/src/crypto/RandomX: No such file or directory
The directory also does not appear in the source repo

https://github.com/biblepay/biblepay-evolution/tree/master/src/crypto

Finally compilation halts with the following message:
Code: [Select]
In file included from bls/bls.cpp:5:0:
bls/bls.h:14:10: fatal error: chiabls/bls.hpp: No such file or directory
 #include <chiabls/bls.hpp>
          ^~~~~~~~~~~~~~~~~
compilation terminated.
Makefile:9971: recipe for target 'bls/libbiblepayconsensus_la-bls.lo' failed
make[2]: *** [bls/libbiblepayconsensus_la-bls.lo] Error 1
make[2]: Leaving directory '/home/xmrbbp/biblepay-evolution/src'
Makefile:11657: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/xmrbbp/biblepay-evolution/src'
Makefile:686: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

Advice would be greatly appreciated!

Thanks.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 13, 2020, 08:33:22 AM
Results from compiling the Linux ubuntu 18.04 version from source,

Platform: Linux 4.15.0-76-generic #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020 x86_64 x86_64 x86_64 GNU
Hardware: 6 x vCPU x Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz with 16 Gb RAM (VPS)

Repo:
git clone http://github.com/biblepay/biblepay-evolution

Code: [Select]
# RandomX Part
>cd biblepay-evolution/src/crypto/RandomX

>biblepay-evolution/src/crypto/RandomX: No such file or directory
The directory also does not appear in the source repo

https://github.com/biblepay/biblepay-evolution/tree/master/src/crypto

Finally compilation halts with the following message:
Code: [Select]
In file included from bls/bls.cpp:5:0:
bls/bls.h:14:10: fatal error: chiabls/bls.hpp: No such file or directory
 #include <chiabls/bls.hpp>
          ^~~~~~~~~~~~~~~~~
compilation terminated.
Makefile:9971: recipe for target 'bls/libbiblepayconsensus_la-bls.lo' failed
make[2]: *** [bls/libbiblepayconsensus_la-bls.lo] Error 1
make[2]: Leaving directory '/home/xmrbbp/biblepay-evolution/src'
Makefile:11657: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/xmrbbp/biblepay-evolution/src'
Makefile:686: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

Advice would be greatly appreciated!

Thanks.
So there are a few issues here:
1) When you git clone you must clone the develop branch (not only to get the right branch, but also to get the randomx part):
for example:
cd /
mkdir biblepay-develop
cd biblepay-develop
git clone http://github.com/biblepay/biblepay-evolution
git pull origin develop

(You can also git clone develop initially, if you want, but I think you get the idea) - the pull origin develop will pull the develop branch into the evolution folder that you cloned.
Then when you build you will of course see the RandomX part.

The 2nd problem is it appears your depends directory was not compiled, (ie resulting in the chiabls error) -- please see this compile doc:
https://github.com/biblepay/biblepay-evolution/blob/develop/BuildBiblePay.txt

Notice the part about setting the environment variables, then cd to depends then make depends then cd back to making biblepay.

ChiaBLS is part of the depends build.




Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 13, 2020, 10:12:35 AM
So i tried to run xmrig-bbp miner but i just get this message  " The code execution cannot proceed because VCRUNTIME140_1.dll was not found"
I have same error:
https://github.com/biblepay/xmrig/blob/master/binaries/xmrig-bbp-win64.exe (https://github.com/biblepay/xmrig/blob/master/binaries/xmrig-bbp-win64.exe)
Using Windows 10 64-bit


Ok, so I did reproduce this on our other windows box that does not contain a development environment, and received the same error.  So the root cause of this is the c++ compile must be compiled with more switches allowing us to statically link the dependencies in (for the windows builds).

So I have updated the OP post with a new download URL:  A zip file instead.  This allows us to pack in the other dependencies also.

Please try again with the zip file version.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 13, 2020, 12:10:58 PM
I have same error:
https://github.com/biblepay/xmrig/blob/master/binaries/xmrig-bbp-win64.exe (https://github.com/biblepay/xmrig/blob/master/binaries/xmrig-bbp-win64.exe)
Using Windows 10 64-bit



Ok, so I did reproduce this on our other windows box that does not contain a development environment, and received the same error.  So the root cause of this is the c++ compile must be compiled with more switches allowing us to statically link the dependencies in (for the windows builds).

So I have updated the OP post with a new download URL:  A zip file instead.  This allows us to pack in the other dependencies also.

Please try again with the zip file version.

Cheers it works just fine now Rob!

One thing i was thinking about, is it possible to make a config.json  file  like on  normal  xmrig miner.  For the reason batch file i seem to be able to get large pages working fine but the msr mod wont work from batch file or rather trying to run batch file with admin rights wont work.

So if we could add the parameters in a config.json file can then just run the   xmrig-bbp-win64.exe with admin rights and poff we get msr  mod up and running aswell, its significant hashrate increase  perhaps 7-10% i belive. Pretty much the pool fee.

Quote
* ABOUT        XMRig/5.5.5 MSVC/2017
 * BBP + XMR - Welcome to the future of orphan charity
 * LIBS         libuv/1.31.0 OpenSSL/1.1.1c hwloc/2.1.0
 * HUGE PAGES   permission granted
 * 1GB PAGES    unavailable
 * CPU          AMD Ryzen 5 1600 Six-Core Processor (1) x64 AES
                L2:3.0 MB L3:16.0 MB 6C/12T NUMA:1
 * MEMORY       2.3/7.9 GB (29%)
 * DONATE       10%
 * ASSEMBLY     auto:ryzen
 * POOL #1      rxtest.biblepay.org:3008 algo auto
 * COMMANDS     hashrate, pause, resume
 * OPENCL       disabled
 * CUDA         disabled
[2020-02-13 18:40:24.583]  net  use pool rxtest.biblepay.org  Orphan Charity
[2020-02-13 18:40:24.584]  net  new job from rxtest.biblepay.org diff 75000 algo rx/0 height 2032833
[2020-02-13 18:40:24.585]  msr  to write MSR registers Administrator privileges required.
[2020-02-13 18:40:24.585]  rx   init dataset algo rx/0 (12 threads) seed 154eb7a21cd32a59...
[2020-02-13 18:40:24.592]  rx   allocated 2336 MB (2080+256) huge pages 100% 1168/1168 +JIT (6 ms)
[2020-02-13 18:40:28.270]  rx   dataset ready (3679 ms)
[2020-02-13 18:40:28.271]  cpu  use profile  *  (6 threads) scratchpad 2048 KB
[2020-02-13 18:40:28.376]  cpu  READY threads 6/6 (6) huge pages 100% 6/6 memory 12288 KB (105 ms)
[2020-02-13 18:40:29.849]  cpu  accepted (1/0) diff 1 BBP (0 ms)
[2020-02-13 18:40:30.273]  cpu  accepted (2/0) diff 75000 XMR (69 ms)
[2020-02-13 18:40:43.846]  cpu  accepted (3/0) diff 1 BBP (0 ms)
[2020-02-13 18:41:05.197]  cpu  accepted (4/0) diff 75000 XMR (56 ms)
|    CPU # | AFFINITY | 10s H/s | 60s H/s | 15m H/s |
|        0 |       -1 |  1306.8 |     n/a |     n/a |
|        1 |       -1 |  1292.4 |     n/a |     n/a |
|        2 |       -1 |  1286.1 |     n/a |     n/a |
|        3 |       -1 |  1301.3 |     n/a |     n/a |
|        4 |       -1 |  1289.5 |     n/a |     n/a |
|        5 |       -1 |  1285.8 |     n/a |     n/a |
|        - |        - |  7761.9 |     n/a |     n/a |
[2020-02-13 18:41:18.325] speed 10s/60s/15m 7761.9 n/a n/a H/s max 7761.9 H/s
[2020-02-13 18:41:19.857]  cpu  accepted (5/0) diff 1 BBP (0 ms)
[2020-02-13 18:41:24.840]  cpu  accepted (6/0) diff 1 BBP (0 ms)
[2020-02-13 18:41:26.868]  cpu  accepted (7/0) diff 1 BBP (0 ms)
[2020-02-13 18:41:28.288] speed 10s/60s/15m 7715.0 n/a n/a H/s max 7761.9 H/s
[2020-02-13 18:41:33.491]  cpu  accepted (8/0) diff 75000 XMR (73 ms)
[2020-02-13 18:41:36.665]  cpu  accepted (9/0) diff 75000 XMR (69 ms)
[2020-02-13 18:41:37.857]  cpu  accepted (10/0) diff 1 BBP (0 ms)
[2020-02-13 18:41:40.000]  net  new job from rxtest.biblepay.org diff 180445 algo rx/0 height 2032834
[2020-02-13 18:41:40.846]  cpu  accepted (11/0) diff 1 BBP (0 ms)
[2020-02-13 18:41:45.850]  cpu  accepted (12/0) diff 1 BBP (0 ms)
[2020-02-13 18:41:46.850]  cpu  accepted (13/0) diff 1 BBP (0 ms)
[2020-02-13 18:41:53.930]  cpu  accepted (14/0) diff 1 BBP (0 ms)
[2020-02-13 18:42:06.575]  net  new job from rxtest.biblepay.org diff 225351 algo rx/0 height 2032834
[2020-02-13 18:42:28.325] speed 10s/60s/15m 7730.8 7597.8 n/a H/s max 7761.9 H/s
[2020-02-13 18:42:35.085]  cpu  accepted (15/0) diff 225351 XMR (66 ms)
[2020-02-13 18:42:37.312]  cpu  accepted (16/0) diff 225351 XMR (70 ms)
[2020-02-13 18:42:40.502]  cpu  accepted (17/0) diff 225351 XMR (71 ms)
[2020-02-13 18:42:48.861]  cpu  accepted (18/0) diff 1 BBP (0 ms)
[2020-02-13 18:42:49.661]  net  new job from rxtest.biblepay.org diff 418694 algo rx/0 height 2032835
[2020-02-13 18:42:49.860]  cpu  accepted (19/0) diff 1 BBP (0 ms)
[2020-02-13 18:42:52.308]  cpu  accepted (20/0) diff 1 BBP (0 ms)
[2020-02-13 18:42:59.878]  cpu  accepted (21/0) diff 1 BBP (0 ms)
[2020-02-13 18:43:17.850]  cpu  accepted (22/0) diff 1 BBP (0 ms)
[2020-02-13 18:43:28.345] speed 10s/60s/15m 7373.9 7095.0 n/a H/s max 7761.9 H/s
|    CPU # | AFFINITY | 10s H/s | 60s H/s | 15m H/s |
|        0 |       -1 |  1231.3 |  1190.4 |     n/a |
|        1 |       -1 |  1243.4 |  1183.2 |     n/a |
|        2 |       -1 |  1225.2 |  1177.4 |     n/a |
|        3 |       -1 |  1239.1 |  1188.7 |     n/a |
|        4 |       -1 |  1242.8 |  1178.0 |     n/a |
|        5 |       -1 |  1235.2 |  1182.4 |     n/a |
|        - |        - |  7417.0 |  7100.1 |     n/a |
[2020-02-13 18:43:32.674] speed 10s/60s/15m 7417.0 7100.1 n/a H/s max 7761.9 H/s
[2020-02-13 18:43:45.868]  cpu  accepted (23/0) diff 1 BBP (0 ms)
[2020-02-13 18:43:54.860]  cpu  accepted (24/0) diff 1 BBP (0 ms)
[2020-02-13 18:43:57.867]  cpu  accepted (25/0) diff 1 BBP (0 ms)
[2020-02-13 18:44:00.861]  cpu  accepted (26/0) diff 1 BBP (0 ms)
[2020-02-13 18:44:05.168] SIGHUP received, exiting
[2020-02-13 18:44:05.170]  cpu  stopped (1 ms)

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 13, 2020, 01:40:33 PM
Cheers it works just fine now Rob!

One thing i was thinking about, is it possible to make a config.json  file  like on  normal  xmrig miner.  For the reason batch file i seem to be able to get large pages working fine but the msr mod wont work from batch file or rather trying to run batch file with admin rights wont work.

So if we could add the parameters in a config.json file can then just run the   xmrig-bbp-win64.exe with admin rights and poff we get msr  mod up and running aswell, its significant hashrate increase  perhaps 7-10% i belive. Pretty much the pool fee.

This is great, looks like a very good start for us, that its working now on your end.

So although I'm not entirely against the config file, I feel with our modded pool requirements, it might not be in our best interests to make the config file itself work, if we can make all of the functionality work for the most part for our pool(s).  This is because the config file will be primarily used by miners who want the multipool (failover) strategies, and, I think that is something we can make available if this ecosystem actually takes off (but of course, that still requires knowledge of how our pools will work, so even the failover strategy will be customized).

However, I am all for making the advanced mods work for the miner inherently by default, to give them 98%+ of the available hashrate.

So for this first baby step, since I actually have no windows 10 boxes in my house (I did have one but it was burned last year), Id like to ask you to try an expiriment first.  I believe the MSR mod is already compiled in this version (5.5.5). 

Could you please try this:  Add the msr mod ryzen config settings to the mining batch file, then create a shortcut in windows for the command prompt, then right click it and Launch as Administrator, then launch the mining batch file?  Did that solve the problem and let the miner see that it has admin rights?

Thanks!

EDIT: On my windows 7 box, I click start, find the cmd.exe icon, then right click it and launch it as admin.  Then I run the miner from the command prompt.  But in my personal case, I cant install the Win10SDK for the msr mod because I dont have win10 to try this part on so my miner skips over the msr check.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 13, 2020, 01:50:57 PM
This is great, looks like a very good start for us, that its working now on your end.

So although I'm not entirely against the config file, I feel with our modded pool requirements, it might not be in our best interests to make the config file itself work, if we can make all of the functionality work for the most part for our pool(s).  This is because the config file will be primarily used by miners who want the multipool (failover) strategies, and, I think that is something we can make available if this ecosystem actually takes off (but of course, that still requires knowledge of how our pools will work, so even the failover strategy will be customized).

However, I am all for making the advanced mods work for the miner inherently by default, to give them 98%+ of the available hashrate.

So for this first baby step, since I actually have no windows 10 boxes in my house (I did have one but it was burned last year), Id like to ask you to try an expiriment first.  I believe the MSR mod is already compiled in this version (5.5.5). 

Could you please try this:  Add the msr mod ryzen config settings to the mining batch file, then create a shortcut in windows for the command prompt, then right click it and Launch as Administrator, then launch the mining batch file?  Did that solve the problem and let the miner see that it has admin rights?

Thanks!

EDIT: On my windows 7 box, I click start, find the cmd.exe icon, then right click it and launch it as admin.  Then I run the miner from the command prompt.  But in my personal case, I cant install the Win10SDK for the msr mod because I dont have win10 to try this part on so my miner skips over the msr check.

Wait, I think I found a way for you to make it work.
Right click on xmrig-bbp64.exe, check Run as admistrator | Save.  Now restart with the batch file, and it says on my output:  MSR  - Ryzen registers set successfully.
For me, it did not increase my HPS, but I have 30 windows open and a VM running that takes up 70% of my ram, etc.

Let me know if it actually worked?

EDIT:  It might have increased by 5%.  I need to try it after a reboot.


Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 13, 2020, 02:13:15 PM
Wait, I think I found a way for you to make it work.
Right click on xmrig-bbp64.exe, check Run as admistrator | Save.  Now restart with the batch file, and it says on my output:  MSR  - Ryzen registers set successfully.
For me, it did not increase my HPS, but I have 30 windows open and a VM running that takes up 70% of my ram, etc.

Let me know if it actually worked?

EDIT:  It might have increased by 5%.  I need to try it after a reboot.

After Reading your replies i tried various things, i found that the thing that works that i managed to get to work so far was to open up cmd as adminstrator then just cd to  path, then just copy paste parameters  from batch file and voila  the msr mod is kicking up. ;D
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 13, 2020, 02:23:43 PM
Wait, I think I found a way for you to make it work.
Right click on xmrig-bbp64.exe, check Run as admistrator | Save.  Now restart with the batch file, and it says on my output:  MSR  - Ryzen registers set successfully.
For me, it did not increase my HPS, but I have 30 windows open and a VM running that takes up 70% of my ram, etc.

Let me know if it actually worked?

EDIT:  It might have increased by 5%.  I need to try it after a reboot.

I logged latest attempt and seems pretty high hashrate jump for me gonna play abit with threads and cores for my ryzen 5 1600.

gonna try a ryzen 5 3600 and a 1920x in the coming days aswell.

Quote
* ABOUT        XMRig/5.5.5 MSVC/2017
 * BBP + XMR - Welcome to the future of orphan charity
 * LIBS         libuv/1.31.0 OpenSSL/1.1.1c hwloc/2.1.0
 * HUGE PAGES   permission granted
 * 1GB PAGES    unavailable
 * CPU          AMD Ryzen 5 1600 Six-Core Processor (1) x64 AES
                L2:3.0 MB L3:16.0 MB 6C/12T NUMA:1
 * MEMORY       2.2/7.9 GB (28%)
 * DONATE       10%
 * ASSEMBLY     auto:ryzen
 * POOL #1      rxtest.biblepay.org:3008 algo auto
 * COMMANDS     hashrate, pause, resume
 * OPENCL       disabled
 * CUDA         disabled
[2020-02-13 21:15:46.854]  net  use pool rxtest.biblepay.org  Orphan Charity
[2020-02-13 21:15:46.856]  net  new job from rxtest.biblepay.org diff 75000 algo rx/0 height 2032914
[2020-02-13 21:15:47.052]  msr  register values for "ryzen" preset has been set successfully (196 ms)
[2020-02-13 21:15:47.053]  rx   init dataset algo rx/0 (12 threads) seed 154eb7a21cd32a59...
[2020-02-13 21:15:47.060]  rx   allocated 2336 MB (2080+256) huge pages 100% 1168/1168 +JIT (6 ms)
[2020-02-13 21:15:50.381]  rx   dataset ready (3321 ms)
[2020-02-13 21:15:50.383]  cpu  use profile  *  (6 threads) scratchpad 2048 KB
[2020-02-13 21:15:50.537]  cpu  READY threads 6/6 (6) huge pages 100% 6/6 memory 12288 KB (154 ms)
[2020-02-13 21:15:52.081]  cpu  accepted (1/0) diff 1 BBP (0 ms)
[2020-02-13 21:15:52.165]  cpu  accepted (2/0) diff 75000 XMR (56 ms)
[2020-02-13 21:15:54.121]  cpu  accepted (3/0) diff 1 BBP (0 ms)
[2020-02-13 21:16:00.145]  cpu  accepted (4/0) diff 1 BBP (0 ms)
[2020-02-13 21:16:02.160]  cpu  accepted (5/0) diff 1 BBP (0 ms)
[2020-02-13 21:16:08.208]  cpu  accepted (6/0) diff 1 BBP (0 ms)
[2020-02-13 21:16:15.279]  cpu  accepted (7/0) diff 1 BBP (0 ms)
|    CPU # | AFFINITY | 10s H/s | 60s H/s | 15m H/s |
|        0 |       -1 |  1390.3 |     n/a |     n/a |
|        1 |       -1 |  1406.9 |     n/a |     n/a |
|        2 |       -1 |  1392.9 |     n/a |     n/a |
|        3 |       -1 |  1374.2 |     n/a |     n/a |
|        4 |       -1 |  1384.9 |     n/a |     n/a |
|        5 |       -1 |  1382.8 |     n/a |     n/a |
|        - |        - |  8332.0 |     n/a |     n/a |
[2020-02-13 21:16:19.286] speed 10s/60s/15m 8332.0 n/a n/a H/s max 8459.7 H/s
[2020-02-13 21:16:26.328]  cpu  accepted (8/0) diff 1 BBP (0 ms)
[2020-02-13 21:16:33.307]  cpu  accepted (9/0) diff 1 BBP (0 ms)
[2020-02-13 21:16:39.310]  cpu  accepted (10/0) diff 1 BBP (0 ms)
[2020-02-13 21:16:50.698] speed 10s/60s/15m 8433.9 n/a n/a H/s max 8516.0 H/s
|    CPU # | AFFINITY | 10s H/s | 60s H/s | 15m H/s |
|        0 |       -1 |  1415.0 |  1406.5 |     n/a |
|        1 |       -1 |  1414.4 |  1408.8 |     n/a |
|        2 |       -1 |  1418.1 |  1411.0 |     n/a |
|        3 |       -1 |  1417.3 |  1406.6 |     n/a |
|        4 |       -1 |  1421.9 |  1401.0 |     n/a |
|        5 |       -1 |  1425.1 |  1411.1 |     n/a |
|        - |        - |  8511.8 |  8445.1 |     n/a |
[2020-02-13 21:17:01.096] speed 10s/60s/15m 8511.8 8445.1 n/a H/s max 8523.9 H/s
[2020-02-13 21:17:04.001]  cpu  accepted (11/0) diff 75000 XMR (67 ms)
[2020-02-13 21:17:16.330]  cpu  accepted (12/0) diff 1 BBP (0 ms)
[2020-02-13 21:17:21.214]  cpu  accepted (13/0) diff 75000 XMR (61 ms)
[2020-02-13 21:17:23.853] SIGHUP received, exiting
[2020-02-13 21:17:23.856]  cpu  stopped (2 ms)

Looks like 8-10% increase for me in hashrate with the MSR mod Active.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 13, 2020, 02:37:55 PM
** MSR MOD Update **

Just a note for anyone who is attempting to add the msr mod.  I see that in the code, we already do set the registers for the ryzen for the msr mod, so I believe you do not need to install the windows10 debugging kit, or follow any of these commands listed in the below reddit thread, or add anything to your batch file.  You only need to right click on the miner.exe and check run as administrator.  The code should do the rest including setting the registers for MSR and launching the miner.

https://www.reddit.com/r/MoneroMining/comments/e9tuvd/randomx_boost_guide_for_ryzen_on_windows_9100_hs/
^^ These cpu register values are compiled in the code already ^^

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 13, 2020, 02:40:04 PM
I logged latest attempt and seems pretty high hashrate jump for me gonna play abit with threads and cores for my ryzen 5 1600.

gonna try a ryzen 5 3600 and a 1920x in the coming days aswell.

Looks like 8-10% increase for me in hashrate with the MSR mod Active.

Thats great!

Yeah, Ill post my HPS when I finally reboot.  I remember seeing about 5,000 hps when my memory is in use, but around 9,000 on a fresh reboot when the large pages are available.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: oncoapop on February 13, 2020, 04:48:29 PM
So there are a few issues here:
1) When you git clone you must clone the develop branch (not only to get the right branch, but also to get the randomx part):
for example:
cd /
mkdir biblepay-develop
cd biblepay-develop
git clone http://github.com/biblepay/biblepay-evolution
git pull origin develop

(You can also git clone develop initially, if you want, but I think you get the idea) - the pull origin develop will pull the develop branch into the evolution folder that you cloned.
Then when you build you will of course see the RandomX part.

The 2nd problem is it appears your depends directory was not compiled, (ie resulting in the chiabls error) -- please see this compile doc:
https://github.com/biblepay/biblepay-evolution/blob/develop/BuildBiblePay.txt

Notice the part about setting the environment variables, then cd to depends then make depends then cd back to making biblepay.

ChiaBLS is part of the depends build.

Yes, I do apologise. I recall that you did tell me this before and so I used the old testnet script with the new RandomX part and it completed the compile. Thank you.

For the record
Code: [Select]

cd
git clone -b develop http://github.com/biblepay/biblepay-evolution

# RandomX Part
cd biblepay-evolution/src/crypto/RandomX
mkdir build && cd build
cmake -DARCH=native ..
make
cd ../../../../..
# end of RandomX Part

evodir=$HOME"/biblepay-evolution"
cd $evodir/depends

# Build with all cores, depending on the number of CPU cores available
cores=`lscpu | grep "^CPU(s):" | awk -F" " '{print $2}'`
proc=$cores

make -j$proc

cd ..

./autogen.sh

wdir=`pwd`
./configure --prefix $wdir/depends/x86_64-pc-linux-gnu

make -j$proc

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 14, 2020, 06:54:07 AM
Have been running cense last evening the bbp-xmrig dual miner.  Theres no diffrence in wattage from just mining monero to this dual miner  from what i can tell.

Came home from part time work and i see that the miner is still running, the monero "part" of it anyway but the BBP shares stopped like 5 hours ago, ill link the log file:

Quote
[2020-02-14 10:13:38.371]  net  new job from rxtest.biblepay.org diff 214662 algo rx/0 height 2033321
[2020-02-14 10:13:55.824]  cpu  accepted (3430/0) diff 1 BBP (0 ms)
[2020-02-14 10:14:07.826]  cpu  accepted (3431/0) diff 1 BBP (0 ms)
[2020-02-14 10:14:25.820]  cpu  accepted (3432/0) diff 1 BBP (0 ms)
[2020-02-14 10:14:32.601] speed 10s/60s/15m 7695.1 7650.9 7691.6 H/s max 7711.5 H/s
[2020-02-14 10:14:38.368]  cpu  accepted (3433/0) diff 214662 XMR (69 ms)
[2020-02-14 10:14:39.848]  cpu  accepted (3434/0) diff 1 BBP (0 ms)
[2020-02-14 10:15:21.901]  net  new job from rxtest.biblepay.org diff 214812 algo rx/0 height 2033322
[2020-02-14 10:15:23.153] [rxtest.biblepay.org:3008] read error: "end of file"
[2020-02-14 10:15:23.637]  net  orphan donations started
[2020-02-14 10:15:23.638]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033322
[2020-02-14 10:15:24.550]  cpu  accepted (3435/0) diff 75000 XMR-Charity (0 ms)
[2020-02-14 10:15:26.442] [rxtest.biblepay.org:3008] connect error: "connection refused"
[2020-02-14 10:15:32.607] speed 10s/60s/15m 7690.5 7694.2 7691.6 H/s max 7711.5 H/s
[2020-02-14 10:15:57.483] [rxtest.biblepay.org:3008] connect error: "connection refused"
[2020-02-14 10:16:02.188]  cpu  accepted (3436/0) diff 75000 XMR-Charity (0 ms)
[2020-02-14 10:16:03.410]  cpu  accepted (3437/0) diff 75000 XMR-Charity (0 ms)
[2020-02-14 10:16:04.070]  cpu  accepted (3438/0) diff 75000 XMR-Charity (0 ms)
[2020-02-14 10:16:19.388] [rxtest.biblepay.org:3008] connect error: "connection refused"
[2020-02-14 10:16:32.615] speed 10s/60s/15m 7695.1 7693.9 7691.6 H/s max 7711.5 H/s
[2020-02-14 10:17:06.718] [rxtest.biblepay.org:3008] connect error: "connection refused"
[2020-02-14 10:17:17.503]  cpu  accepted (3439/0) diff 75000 XMR-Charity (0 ms)
[2020-02-14 10:17:30.921]  cpu  accepted (3440/0) diff 75000 XMR-Charity (0 ms)
[2020-02-14 10:17:32.341]  cpu  accepted (3441/0) diff 75000 XMR-Charity (0 ms)
[2020-02-14 10:17:32.626] speed 10s/60s/15m 7693.3 7694.9 7691.6 H/s max 7711.5 H/s
[2020-02-14 10:18:11.042]  cpu  accepted (3442/0) diff 75000 XMR-Charity (0 ms)
[2020-02-14 10:18:12.902]  cpu  accepted (3443/0) diff 75000 XMR-Charity (0 ms)
[2020-02-14 10:18:32.634] speed 10s/60s/15m 7700.9 7694.8 7691.6 H/s max 7711.5 H/s
[2020-02-14 10:18:43.772]  cpu  accepted (3444/0) diff 75000 XMR-Charity (0 ms)
[2020-02-14 10:19:00.087]  net  new job from rxtest.biblepay.org-Charity diff 217125 algo rx/0 height 2033323
[2020-02-14 10:19:08.772]  cpu  accepted (3445/0) diff 217125 XMR-Charity (0 ms)
[2020-02-14 10:19:32.642] speed 10s/60s/15m 7690.4 7691.4 7691.3 H/s max 7711.5 H/s
[2020-02-14 10:19:57.111]  net  new job from rxtest.biblepay.org-Charity diff 235379 algo rx/0 height 2033324
[2020-02-14 10:20:09.303]  cpu  accepted (3446/0) diff 235379 XMR-Charity (0 ms)
[2020-02-14 10:20:32.651] speed 10s/60s/15m 7695.0 7694.7 7691.3 H/s max 7711.5 H/s
[2020-02-14 10:21:32.659] speed 10s/60s/15m 7694.6 7695.6 7691.4 H/s max 7711.5 H/s
[2020-02-14 10:21:51.175]  cpu  accepted (3447/0) diff 235379 XMR-Charity (0 ms)
[2020-02-14 10:22:07.082]  net  new job from rxtest.biblepay.org-Charity diff 217565 algo rx/0 height 2033325
[2020-02-14 10:22:27.227]  net  new job from rxtest.biblepay.org-Charity diff 217565 algo rx/0 height 2033326
[2020-02-14 10:22:32.666] speed 10s/60s/15m 7694.4 7695.9 7691.3 H/s max 7711.5 H/s
[2020-02-14 10:23:32.676] speed 10s/60s/15m 7693.7 7694.7 7691.5 H/s max 7711.5 H/s
[2020-02-14 10:23:48.255]  net  new job from rxtest.biblepay.org-Charity diff 177324 algo rx/0 height 2033327
[2020-02-14 10:23:49.177]  cpu  accepted (3448/0) diff 177324 XMR-Charity (0 ms)
[2020-02-14 10:24:18.863]  cpu  accepted (3449/0) diff 177324 XMR-Charity (0 ms)
[2020-02-14 10:24:28.246]  cpu  accepted (3450/0) diff 177324 XMR-Charity (0 ms)
[2020-02-14 10:24:32.687] speed 10s/60s/15m 7695.4 7694.7 7691.5 H/s max 7711.5 H/s
[2020-02-14 10:24:45.882]  net  new job from rxtest.biblepay.org-Charity diff 216251 algo rx/0 height 2033328
[2020-02-14 10:24:50.491]  cpu  accepted (3451/0) diff 216251 XMR-Charity (0 ms)
[2020-02-14 10:25:23.637]  net  orphan donations finished
[2020-02-14 10:25:23.639]  net  new job from rxtest.biblepay.org diff 212013 algo rx/0 height 2033328
[2020-02-14 10:25:32.696] speed 10s/60s/15m 7694.7 7695.6 7691.5 H/s max 7711.5 H/s
[2020-02-14 10:26:08.687]  cpu  accepted (3452/0) diff 212013 XMR (69 ms)
[2020-02-14 10:26:14.046]  cpu  accepted (3453/0) diff 212013 XMR (74 ms)
[2020-02-14 10:26:27.257]  cpu  accepted (3454/0) diff 212013 XMR (85 ms)
[2020-02-14 10:26:32.703] speed 10s/60s/15m 7696.4 7694.3 7691.6 H/s max 7711.5 H/s
[2020-02-14 10:27:32.712] speed 10s/60s/15m 7696.7 7697.6 7691.8 H/s max 7711.5 H/s
[2020-02-14 10:27:49.538]  cpu  accepted (3455/0) diff 212013 XMR (75 ms)
[2020-02-14 10:28:12.478]  cpu  accepted (3456/0) diff 212013 XMR (68 ms)
[2020-02-14 10:28:32.720] speed 10s/60s/15m 7695.1 7694.3 7691.8 H/s max 7711.5 H/s
[2020-02-14 10:28:38.489]  cpu  accepted (3457/0) diff 212013 XMR (76 ms)
[2020-02-14 10:28:43.890]  cpu  accepted (3458/0) diff 212013 XMR (55 ms)
[2020-02-14 10:28:59.409]  net  new job from rxtest.biblepay.org diff 212559 algo rx/0 height 2033329
[2020-02-14 10:29:13.468]  cpu  accepted (3459/0) diff 212559 XMR (71 ms)
[2020-02-14 10:29:24.829]  cpu  accepted (3460/0) diff 212559 XMR (71 ms)
[2020-02-14 10:29:32.730] speed 10s/60s/15m 7695.7 7693.8 7694.7 H/s max 7711.5 H/s
[2020-02-14 10:29:46.859]  net  new job from rxtest.biblepay.org diff 213107 algo rx/0 height 2033330
[2020-02-14 10:30:12.223]  cpu  accepted (3461/0) diff 213107 XMR (55 ms)
[2020-02-14 10:30:32.741] speed 10s/60s/15m 7697.4 7695.2 7694.8 H/s max 7711.5 H/s
[2020-02-14 10:30:38.240]  cpu  accepted (3462/0) diff 213107 XMR (72 ms)
[2020-02-14 10:31:32.751] speed 10s/60s/15m 7695.0 7695.5 7694.9 H/s max 7711.5 H/s
[2020-02-14 10:32:31.536]  net  new job from rxtest.biblepay.org diff 212970 algo rx/0 height 2033331
[2020-02-14 10:32:32.759] speed 10s/60s/15m 7698.3 7696.0 7695.0 H/s max 7711.5 H/s
[2020-02-14 10:32:58.995]  cpu  accepted (3463/0) diff 212970 XMR (55 ms)
[2020-02-14 10:33:32.766] speed 10s/60s/15m 7694.1 7695.8 7695.0 H/s max 7711.5 H/s
[2020-02-14 10:33:38.444]  cpu  accepted (3464/0) diff 212970 XMR (78 ms)
[2020-02-14 10:34:04.363]  cpu  accepted (3465/0) diff 212970 XMR (75 ms)
[2020-02-14 10:34:32.775] speed 10s/60s/15m 7696.3 7695.2 7695.3 H/s max 7711.5 H/s
[2020-02-14 10:35:32.785] speed 10s/60s/15m 7692.3 7682.6 7694.5 H/s max 7711.5 H/s
[2020-02-14 10:36:32.796] speed 10s/60s/15m 7692.1 7685.1 7693.8 H/s max 7711.5 H/s

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: sunk818 on February 14, 2020, 08:52:13 AM
Could you perhaps start the pool at 10k difficulty then go up? 75k is too high for my little single 4c/4t machine.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: oncoapop on February 14, 2020, 09:06:08 AM
Yes, I do apologise. I recall that you did tell me this before and so I used the old testnet script with the new RandomX part and it completed the compile. Thank you.

For the record
Code: [Select]

cd
git clone -b develop http://github.com/biblepay/biblepay-evolution

# RandomX Part
cd biblepay-evolution/src/crypto/RandomX
mkdir build && cd build
cmake -DARCH=native ..
make
cd ../../../../..
# end of RandomX Part

evodir=$HOME"/biblepay-evolution"
cd $evodir/depends

# Build with all cores, depending on the number of CPU cores available
cores=`lscpu | grep "^CPU(s):" | awk -F" " '{print $2}'`
proc=$cores

make -j$proc

cd ..

./autogen.sh

wdir=`pwd`
./configure --prefix $wdir/depends/x86_64-pc-linux-gnu

make -j$proc


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

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: sunk818 on February 14, 2020, 09:12:52 AM
i sent some accepted hashes but my yf address is not showing up on pool workers. is that to be expected?


http://rxtest.biblepay.org/workers (http://rxtest.biblepay.org/workers)
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 14, 2020, 09:47:13 AM
    Yeah i was getting the same error this morning but on windows10.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 14, 2020, 09:59:14 AM
Have been running cense last evening the bbp-xmrig dual miner.  Theres no diffrence in wattage from just mining monero to this dual miner  from what i can tell.

Came home from part time work and i see that the miner is still running, the monero "part" of it anyway but the BBP shares stopped like 5 hours ago, ill link the log file:

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!

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 14, 2020, 10:01:20 AM
i sent some accepted hashes but my yf address is not showing up on pool workers. is that to be expected?


http://rxtest.biblepay.org/workers (http://rxtest.biblepay.org/workers)

Yes, its to be expected if you hash a couple and let the block go by, yes (as you probably know from experience of running nomp pool, that the round changes when blocks change).

EDIT: Btw, the nomp in its current state only registers the BBP solved shares - the XMR shares pass through to the monero side which is not exposed in the pool yet.  Im going to add metrics for that asap.  So you must also ensure the solved hashes are solving BBP shares as XMR dont register.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 14, 2020, 10:02:17 AM
    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.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 14, 2020, 10:04:46 AM
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.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 14, 2020, 10:06:52 AM
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).
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 14, 2020, 10:08:18 AM
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.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 14, 2020, 11:03:33 AM
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

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 14, 2020, 02:21:16 PM
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

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

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

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: oncoapop on February 14, 2020, 02:26:28 PM
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
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: sunk818 on February 14, 2020, 06:09:50 PM
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.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 15, 2020, 03:18:59 AM

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.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 15, 2020, 08:38:15 AM

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.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 15, 2020, 08:50:00 AM
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.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 15, 2020, 09:34:30 AM
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.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 15, 2020, 09:39:51 AM
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.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 15, 2020, 12:43:58 PM
** 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).
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 15, 2020, 02:34:13 PM
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.


Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: oncoapop on February 15, 2020, 10:21:52 PM
XMR miner on same hardware:
Code: [Select]
Model name:          Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz
Stepping:            2
CPU MHz:             1797.916
BogoMIPS:            3595.83
Virtualization:      VT-x
Hypervisor vendor:   KVM
Virtualization type: full
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            30720K
NUMA node0 CPU(s):   0-5
- Compile xmrig for XMR only
Validation of hash rate from pool:
Code: [Select]
2.35 KH/s 0.00 H/s 374925243 114492 0 about a minute ago paladin
Xmrig console output:
Code: [Select]
[2020-02-15 05:48:32.798]  net  new job from us-west.minexmr.com:443 diff 117786 algo rx/0 height 2034184
[2020-02-15 05:49:05.115] speed 10s/60s/15m 2077.5 2063.7 2011.9 H/s max 2164.9 H/s
[2020-02-15 05:49:28.820]  cpu  accepted (3383/0) diff 117786 (72 ms)
[2020-02-15 05:49:32.828]  net  new job from us-west.minexmr.com:443 diff 117750 algo rx/0 height 2034185
[2020-02-15 05:50:05.168] speed 10s/60s/15m 2065.7 2054.3 2012.8 H/s max 2164.9 H/s
[2020-02-15 05:50:05.777]  net  new job from us-west.minexmr.com:443 diff 117770 algo rx/0 height 2034186
[2020-02-15 05:51:05.220] speed 10s/60s/15m 2092.0 2082.8 2018.5 H/s max 2164.9 H/s
[2020-02-15 05:51:57.700]  cpu  accepted (3384/0) diff 117770 (72 ms)
[2020-02-15 05:52:05.275] speed 10s/60s/15m 2033.7 2085.6 2025.9 H/s max 2164.9 H/s
[2020-02-15 05:52:46.657]  cpu  accepted (3385/0) diff 117770 (72 ms)
[2020-02-15 05:53:05.333] speed 10s/60s/15m 2090.6 2094.7 2033.8 H/s max 2164.9 H/s
[2020-02-15 05:53:43.143]  net  new job from us-west.minexmr.com:443 diff 117692 algo rx/0 height 2034187
[2020-02-15 05:54:05.390] speed 10s/60s/15m 2111.2 2103.9 2039.1 H/s max 2164.9 H/s
[2020-02-15 05:54:14.771]  cpu  accepted (3386/0) diff 117692 (72 ms)

Compile BBP version
>cli -version
BiblePay Core RPC client version 1.5.0.2

Compile xmrig (BBP+XMR)

Code: [Select]
* ABOUT        XMRig/5.5.6 gcc/7.4.0
 * BBP + XMR - Welcome to the future of orphan charity
 * LIBS         libuv/1.18.0 OpenSSL/1.1.1 hwloc/1.11.9
 * HUGE PAGES   supported
 * 1GB PAGES    disabled
 * CPU          Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz (6) x64 AES
                L2:0.8 MB L3:30.0 MB 6C/6T NUMA:1
 * MEMORY       8.5/15.7 GB (54%)
 * DONATE       10%
 * ASSEMBLY     auto:intel
 * POOL #1      rxtest.biblepay.org:3008 algo auto
 * COMMANDS     hashrate, pause, resume
 * OPENCL       disabled
 * CUDA         disabled
[2020-02-15 18:24:31.011]  net  use pool rxtest.biblepay.org  Orphan Charity
[2020-02-15 18:24:31.011]  net  new job from rxtest.biblepay.org diff 75000 algo rx/0 height 2034566
[2020-02-15 18:24:31.016]  msr  msr kernel module is not available

BBP pool
Biblepay
Code: [Select]
Address BBP Shares BBP Invalid XMR Shares XMR Invalid XMR Charity Shares Efficiency Hashrate
yLnVyHJxEdVVLQSmafTPsQhaeomNV96gWu 19 5 34 0 0 79.16% 102.01 KH
XMR pool
Code: [Select]
2.94 KH/s 0.00 H/s 39041199 40000 0 less than a minute ago *base address*
XMR/BBP miner console
Code: [Select]
020-02-15 19:57:54.291]  net  new job from rxtest.biblepay.org diff 120621 algo rx/0 height 2034613
[2020-02-15 19:58:01.819] speed 10s/60s/15m 4106.8 4146.3 4165.3 H/s max 4319.6 H/s
[2020-02-15 19:58:54.263]  cpu  accepted (277/20) diff 1 BBP (0 ms)
[2020-02-15 19:59:01.868] speed 10s/60s/15m 4094.9 4103.8 4156.6 H/s max 4319.6 H/s
[2020-02-15 19:59:03.058]  net  new job from rxtest.biblepay.org diff 119971 algo rx/0 height 2034614
[2020-02-15 19:59:37.747]  net  new job from rxtest.biblepay.org diff 119321 algo rx/0 height 2034615
[2020-02-15 19:59:42.731]  net  new job from rxtest.biblepay.org diff 118678 algo rx/0 height 2034616
[2020-02-15 19:59:50.170]  cpu  rejected (277/21) diff 1 BBP "Stale" (0 ms)
[2020-02-15 20:00:01.925] speed 10s/60s/15m 4018.6 4080.5 4148.4 H/s max 4319.6 H/s
[2020-02-15 20:00:11.184]  cpu  accepted (278/21) diff 1 BBP (0 ms)
[2020-02-15 20:00:32.179]  cpu  accepted (279/21) diff 1 BBP (0 ms)
[2020-02-15 20:00:35.175]  cpu  accepted (280/21) diff 1 BBP (0 ms)
[2020-02-15 20:00:56.401]  net  new job from rxtest.biblepay.org diff 117412 algo rx/0 height 2034617
[2020-02-15 20:00:58.185]  cpu  rejected (280/22) diff 1 BBP "Stale" (0 ms)
[2020-02-15 20:01:01.984] speed 10s/60s/15m 3990.0 4023.2 4136.7 H/s max 4319.6 H/s
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: sunk818 on February 15, 2020, 11:55:27 PM
I think it'd be a worthwhile experiment to see how much one would earn on a monero pool with the same hardware. Reason being is that 10% hash rate does not equal to 10% miner reward because you would need your hashes to go toward a successful monero block. What is the monero hash rate and how realistic is that bbp + xmr pool would be able to solve a monero block? the monero only pool mining would be a test to see how much would be earned from monero alone. same hardware can be pointed to bbp + xmr pool and see what results occur.


the other idea is to upstream xmr hashes to a xmr pool and get pool payments from the larger pool. when bbp + xmr pool gets large enough to contend as a pool that can hold its own, then it certainly makes sense to be its own pool.


just some random thoughts... i'm not married to either idea, just looking out for the orphans and how best to create a stable revenue stream for them.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 16, 2020, 02:42:28 AM
I think it'd be a worthwhile experiment to see how much one would earn on a monero pool with the same hardware. Reason being is that 10% hash rate does not equal to 10% miner reward because you would need your hashes to go toward a successful monero block. What is the monero hash rate and how realistic is that bbp + xmr pool would be able to solve a monero block? the monero only pool mining would be a test to see how much would be earned from monero alone. same hardware can be pointed to bbp + xmr pool and see what results occur.


the other idea is to upstream xmr hashes to a xmr pool and get pool payments from the larger pool. when bbp + xmr pool gets large enough to contend as a pool that can hold its own, then it certainly makes sense to be its own pool.


just some random thoughts... i'm not married to either idea, just looking out for the orphans and how best to create a stable revenue stream for them.

We are already mining the monero part via minexmr, one of the biggest monero pools.
And ofc its about more than just pool hashrate, ddos protection pool uptime and what not.

Another topic are you guys getting 10%  rejected stale BBP shares?

i have 2541/283 accepted bbp shares seems alot rejected ones.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 16, 2020, 09:01:57 AM
We are already mining the monero part via minexmr, one of the biggest monero pools.
And ofc its about more than just pool hashrate, ddos protection pool uptime and what not.

Another topic are you guys getting 10%  rejected stale BBP shares?

i have 2541/283 accepted bbp shares seems alot rejected ones.

So before I answer let me give a background from my perspective on the BBP rejected shares:
On version 5.5.5, I was debugging for a couple days and I noticed repetetive behavior on the xmrig side - that about after 8 hours of mining, my BBP side would drop out.  It has something to do with an expiration (which I thought I fixed in 5.5.6).  But at that time, the BBP share would be rejected in every post but it was not a stale share.

So now moving along to 5.5.6, in this version, we reconnect to the pool and reauthorize the miner automatically after a certain amount of time - and I thought that fixed it.  However it appears this actually permutated the same error into stale shares instead of connectivity issues.

So before I went to sleep last night I rebooted the pool; and this confirms that the problem is definitely inside our xmrig (not in the pool).

So for now in summary:  If you restart the xmrig miner, you can mine perfectly for about 8 hours then we start to get stale shares on every share.
I just restarted mine and now its working again.

I'll look at this today.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 16, 2020, 09:09:26 AM
XMR miner on same hardware:
Code: [Select]
Model name:          Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz
Stepping:            2
CPU MHz:             1797.916
BogoMIPS:            3595.83
Virtualization:      VT-x
Hypervisor vendor:   KVM
Virtualization type: full
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            30720K
NUMA node0 CPU(s):   0-5
- Compile xmrig for XMR only
Validation of hash rate from pool:
Code: [Select]
2.35 KH/s 0.00 H/s 374925243 114492 0 about a minute ago paladin
Xmrig console output:
Code: [Select]
[2020-02-15 05:48:32.798]  net  new job from us-west.minexmr.com:443 diff 117786 algo rx/0 height 2034184
[2020-02-15 05:49:05.115] speed 10s/60s/15m 2077.5 2063.7 2011.9 H/s max 2164.9 H/s
[2020-02-15 05:49:28.820]  cpu  accepted (3383/0) diff 117786 (72 ms)
[2020-02-15 05:49:32.828]  net  new job from us-west.minexmr.com:443 diff 117750 algo rx/0 height 2034185
[2020-02-15 05:50:05.168] speed 10s/60s/15m 2065.7 2054.3 2012.8 H/s max 2164.9 H/s
[2020-02-15 05:50:05.777]  net  new job from us-west.minexmr.com:443 diff 117770 algo rx/0 height 2034186
[2020-02-15 05:51:05.220] speed 10s/60s/15m 2092.0 2082.8 2018.5 H/s max 2164.9 H/s
[2020-02-15 05:51:57.700]  cpu  accepted (3384/0) diff 117770 (72 ms)
[2020-02-15 05:52:05.275] speed 10s/60s/15m 2033.7 2085.6 2025.9 H/s max 2164.9 H/s
[2020-02-15 05:52:46.657]  cpu  accepted (3385/0) diff 117770 (72 ms)
[2020-02-15 05:53:05.333] speed 10s/60s/15m 2090.6 2094.7 2033.8 H/s max 2164.9 H/s
[2020-02-15 05:53:43.143]  net  new job from us-west.minexmr.com:443 diff 117692 algo rx/0 height 2034187
[2020-02-15 05:54:05.390] speed 10s/60s/15m 2111.2 2103.9 2039.1 H/s max 2164.9 H/s
[2020-02-15 05:54:14.771]  cpu  accepted (3386/0) diff 117692 (72 ms)

Compile BBP version
>cli -version
BiblePay Core RPC client version 1.5.0.2

Compile xmrig (BBP+XMR)

Code: [Select]
* ABOUT        XMRig/5.5.6 gcc/7.4.0
 * BBP + XMR - Welcome to the future of orphan charity
 * LIBS         libuv/1.18.0 OpenSSL/1.1.1 hwloc/1.11.9
 * HUGE PAGES   supported
 * 1GB PAGES    disabled
 * CPU          Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz (6) x64 AES
                L2:0.8 MB L3:30.0 MB 6C/6T NUMA:1
 * MEMORY       8.5/15.7 GB (54%)
 * DONATE       10%
 * ASSEMBLY     auto:intel
 * POOL #1      rxtest.biblepay.org:3008 algo auto
 * COMMANDS     hashrate, pause, resume
 * OPENCL       disabled
 * CUDA         disabled
[2020-02-15 18:24:31.011]  net  use pool rxtest.biblepay.org  Orphan Charity
[2020-02-15 18:24:31.011]  net  new job from rxtest.biblepay.org diff 75000 algo rx/0 height 2034566
[2020-02-15 18:24:31.016]  msr  msr kernel module is not available

BBP pool
Biblepay
Code: [Select]
Address BBP Shares BBP Invalid XMR Shares XMR Invalid XMR Charity Shares Efficiency Hashrate
yLnVyHJxEdVVLQSmafTPsQhaeomNV96gWu 19 5 34 0 0 79.16% 102.01 KH
XMR pool
Code: [Select]
2.94 KH/s 0.00 H/s 39041199 40000 0 less than a minute ago *base address*
XMR/BBP miner console
Code: [Select]
020-02-15 19:57:54.291]  net  new job from rxtest.biblepay.org diff 120621 algo rx/0 height 2034613
[2020-02-15 19:58:01.819] speed 10s/60s/15m 4106.8 4146.3 4165.3 H/s max 4319.6 H/s
[2020-02-15 19:58:54.263]  cpu  accepted (277/20) diff 1 BBP (0 ms)
[2020-02-15 19:59:01.868] speed 10s/60s/15m 4094.9 4103.8 4156.6 H/s max 4319.6 H/s
[2020-02-15 19:59:03.058]  net  new job from rxtest.biblepay.org diff 119971 algo rx/0 height 2034614
[2020-02-15 19:59:37.747]  net  new job from rxtest.biblepay.org diff 119321 algo rx/0 height 2034615
[2020-02-15 19:59:42.731]  net  new job from rxtest.biblepay.org diff 118678 algo rx/0 height 2034616
[2020-02-15 19:59:50.170]  cpu  rejected (277/21) diff 1 BBP "Stale" (0 ms)
[2020-02-15 20:00:01.925] speed 10s/60s/15m 4018.6 4080.5 4148.4 H/s max 4319.6 H/s
[2020-02-15 20:00:11.184]  cpu  accepted (278/21) diff 1 BBP (0 ms)
[2020-02-15 20:00:32.179]  cpu  accepted (279/21) diff 1 BBP (0 ms)
[2020-02-15 20:00:35.175]  cpu  accepted (280/21) diff 1 BBP (0 ms)
[2020-02-15 20:00:56.401]  net  new job from rxtest.biblepay.org diff 117412 algo rx/0 height 2034617
[2020-02-15 20:00:58.185]  cpu  rejected (280/22) diff 1 BBP "Stale" (0 ms)
[2020-02-15 20:01:01.984] speed 10s/60s/15m 3990.0 4023.2 4136.7 H/s max 4319.6 H/s

Thanks!
So it is very nice that your console(s) confirm that you receive 2070/4023 hps (confirming roughly 195% increase is consistent with earlz's results also) - I will add this result to the wiki page.

This also confirms that you will receive almost exactly the same XMR reward if you mine against minexmr as you would against the biblepay/xmr side.  If anyone wants to switch for a couple days feel free to as you will easily see on the minexmr earnings page the results earned.

As far as our Nomp pools hash/ps readout, I do realize that is completely wrong.  Its because no multiplier exists yet for randomx.  Ill create one asap.  I believe its just a matter of changing the multiple from 256 to something like 2.5  - (randomx hashes take a massive amount of time compared to x11 hashes - something like 2000:200000).

Edit:  Ill fix the getting started guide along with the multiplier right after we release this next bug fix.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 16, 2020, 02:09:49 PM
Ok, I updated the rxtest pool algorithm properties to be much closer to randomx.  So now the worker hashrate speed should be "closer".

Also the graph should come down to earth over the next 4 hours.

I also updated the getting started tab with the proper starting instructions.

Let me burn in the new version of xmrig before I deploy it.  If it lasts over the next 4 hours Ill preliminarily release it so we can all test it.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 17, 2020, 09:31:32 AM
Did Another comparison with 8 threads and higher Clocks.


Conclusion 10.6% increase in hashrate but 27% increase in power
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 17, 2020, 09:36:02 AM
Did Another comparison with 8 threads and higher Clocks.


Conclusion 10.6% increase in hashrate but 27% increase in Power over the 6 thread config.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 17, 2020, 09:42:36 AM
Did Another comparison with 8 threads and higher Clocks.

  • Ryzen 5 1600 (14nm)@3.3ghz, Asus b350 rog strix,  8 threads, --cpu-affinity 0xD75, 1x8gb 3200mhz cl16
  • BBP+Xmr-8740 HPS, 70 watts
  • Ryzen 5 1600 (14nm)@3.3ghz, Asus b350 rog strix,  8 threads, --cpu-affinity 0xD75, 1x8gb 3200mhz cl16
  • Xmr only - 4375HPS, 70 watts

Conclusion 10.6% increase in hashrate but 27% increase in power

Thats interesting that the 11% increase pulls 27% more watts (probably 14 more watts or so).
But it also makes me wonder about total system power consumption to break even with XMR.  I remember seeing something like 10,000 hps required to breakeven at 8 cents a kwh, but I believe I was using 500 watts for the power supply.

So out of curiosity do you know if any of these industrial miners can pack 10 ryzen procs in a single machine using some type of board, so the total system power supply is only 1500 watts?  Similar to how they chain asics together?

Im seeing that the casual gamer will pretty much receive their stipend back in the form of xmr while the household pays the electricity (plus they get bbp of course in our case which is a pro).

Im almost ready to release the new miner.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 17, 2020, 09:55:33 AM
BBP Xmrig 5.5.7e - Leisure Upgrade



Ok, this version theoretically stops the dropouts, let us please test it. 

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 17, 2020, 10:53:09 AM
Thats interesting that the 11% increase pulls 27% more watts (probably 14 more watts or so).
But it also makes me wonder about total system power consumption to break even with XMR.  I remember seeing something like 10,000 hps required to breakeven at 8 cents a kwh, but I believe I was using 500 watts for the power supply.

So out of curiosity do you know if any of these industrial miners can pack 10 ryzen procs in a single machine using some type of board, so the total system power supply is only 1500 watts?  Similar to how they chain asics together?

Im seeing that the casual gamer will pretty much receive their stipend back in the form of xmr while the household pays the electricity (plus they get bbp of course in our case which is a pro).

Im almost ready to release the new miner.



For sure its intresting idea daisy chain cpus.  Atleast i dont think there is that for ryzen processors, closest would be to get some dual socket epyc processors i belive.
Myself i just get asus boards so i can setup OS  and miner remote access and all then remove gpu and just run the machine headless.  Saves a few watts not having to think of the gpu.


something like the intel xeon phi but for ryzen would be sweet.

However we think about it its intresting years ahead with 3d stacking cpus, ddr5 coming to zen 4 i belive it was, intels forevos and so on.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 18, 2020, 08:48:34 AM
So I'm going through the code today in an attempt to merge the latest randomx changes into xmrig, and also to harden the build to prevent crashes.
This algorithm is huge, it's a monster when considering how much machine language is generated.
I've exploited some conditions where the bytecode that is generated crashes about 10 stack frames ahead of the last hash (another words the actual crash occurs in the rx virtual machine, in machine language).  Ive been trying to isolate this as it appears to actually be in the jit code on the rx side (last night I removed all the possible biblepay code around it and it still points to the jit code, so Im merging in the latest from XMRig now to see if its something they fixed recently).

But anyway, Id like to find out each OS version that is running out there.  Im using windows 7.  Can each of you please post if you are primarily using the windows exe or the linux version?

After the next build we will need a volunteer to run the linux version for a few days straight, to ensure the jit issue is fixed.  The windows version will probably be OK, as we have a compiler flag we can  set that will overcome any machine language exceptions and let it recover (and keep mining).
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 18, 2020, 09:17:36 AM
So I'm going through the code today in an attempt to merge the latest randomx changes into xmrig, and also to harden the build to prevent crashes.
This algorithm is huge, it's a monster when considering how much machine language is generated.
I've exploited some conditions where the bytecode that is generated crashes about 10 stack frames ahead of the last hash (another words the actual crash occurs in the rx virtual machine, in machine language).  Ive been trying to isolate this as it appears to actually be in the jit code on the rx side (last night I removed all the possible biblepay code around it and it still points to the jit code, so Im merging in the latest from XMRig now to see if its something they fixed recently).

But anyway, Id like to find out each OS version that is running out there.  Im using windows 7.  Can each of you please post if you are primarily using the windows exe or the linux version?

After the next build we will need a volunteer to run the linux version for a few days straight, to ensure the jit issue is fixed.  The windows version will probably be OK, as we have a compiler flag we can  set that will overcome any machine language exceptions and let it recover (and keep mining).

Im using windows 10 on my machines.
Gonna move over my headless systems to ubuntu.  Also im no linux guru so  yeah.....

Also i have been running almost 24 hours now i belive this latest miner and it seems to me it works pretty nice.

I have  3.99%  rejected shares for bbp.
Perhaps i can get less rejected shares by changing difficulty to 256 for bbp ?

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 18, 2020, 10:39:27 AM
Im using windows 10 on my machines.
Gonna move over my headless systems to ubuntu.  Also im no linux guru so  yeah.....

Also i have been running almost 24 hours now i belive this latest miner and it seems to me it works pretty nice.

I have  3.99%  rejected shares for bbp.
Perhaps i can get less rejected shares by changing difficulty to 256 for bbp ?
Oh ok, good to know that you have a headless linux to test on also.
Yes, please let me make a post first for the next release so you can test with the newest version as Im seeing now that monero actually doesnt recommend people to debug in MSVS as some devs are complaining about crashes, so Im building a windows version now in mingw64, to see if the problem the whole time has been the way VS2017 compiles the code.  I also see XMRig no longer supports VS.

Uh, as far as rejects, I don't think we have to worry much as let me explain something on those - and since we are such as "niche" this is actually slightly different info than POBH, or RX in prod.  Since bbp-rx solves for an algorithm, our stales mean any hash that was submitted after the block changes (or a client really was solving for the wrong prior block hash).

So, in our case our hashes will really be minimized when the difficulty increases.
Another words:  With tiny diff (we have a .005 diff in testnet), if any miners share solves the block, there is a very high propensity for stale shares over the next 30 seconds (while the clients abort the current shares and get new ones).

However, when diff is say 10 in prod, since we do support multiple solutions per round (this is in contrast to the way bbp in prod works, which will be a big pro).  Another words, you can have 20 threads running, and if 10 solve shares, they will all be accepted (because all 10 had a chance to solve that block for that round).

So basically, its more on my end - I will try increasing the pools latency for block scanning in testnet.  But in testnet, if we can get diff to increase, stale shares should drop even more to a miniscule number (ie < 1%).

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 18, 2020, 11:08:46 AM
XMRig - 5.5.8 - Leisure Upgrade
GCC Version



This release is the GCC version for both windows and linux.
May we please test this new version on both platforms to ensure long term stability?

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 18, 2020, 11:12:19 AM
XMRig - 5.5.8 - Leisure Upgrade
GCC Version



This release is the GCC version for both windows and linux.
May we please test this new version on both platforms to ensure long term stability?

Sure thing. I will try Windows version today and tomorrow evening hopefully i will have a new rig for linux to test on aswell.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 18, 2020, 11:52:17 AM
Hey Rob.

Im testing new miner now.
Quick question, i changed the : rxtest.biblepay.org:3008 to rxtest.biblepay.org:3256

to change difficulty. Monero and charity monero seems fine from output but i havent seens any bbp solved or rejected.

Should i switch back to starting difficulty ?
Also can say that i have been running miner for 30 minutes so i figured should have gotten some bbp shares solved atleast.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 18, 2020, 03:46:08 PM
Hey Rob.

Im testing new miner now.
Quick question, i changed the : rxtest.biblepay.org:3008 to rxtest.biblepay.org:3256

to change difficulty. Monero and charity monero seems fine from output but i havent seens any bbp solved or rejected.

Should i switch back to starting difficulty ?
Also can say that i have been running miner for 30 minutes so i figured should have gotten some bbp shares solved atleast.

Yeah, I think 256 is way too hard for randomx, let me go in and edit the pool settings and change two settings.  Just a wild guess but we might be able to get away with 2 and 5, Ill let you test those.  Theoretically the payments will work fine with the new settings - but Ill post when these are changed.

Btw, I have been debugging the GCC version now, trying to get to the source of that machine language error and I believe I finally found it.
(This Randomx algo is very interesting in that hashes have to be done in order.  Basically the problem was the original monero devs make it like this:
first hash -> next Hash -> . . . -> Test hash from a separate VM
BBP was like this:
First hash -> next Hash -> Test hash from the 'same' virtual machine.
(Sounds innoculous but the problem is it corrupts the scratchpad, and I wouldnt have known that except through this trial and error (that took about 3 days of debugging).

I just hope this is behind us!

So, I need to issue a new release.  Thanks!
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 18, 2020, 03:58:13 PM
Hey Rob.

Im testing new miner now.
Quick question, i changed the : rxtest.biblepay.org:3008 to rxtest.biblepay.org:3256

to change difficulty. Monero and charity monero seems fine from output but i havent seens any bbp solved or rejected.

Should i switch back to starting difficulty ?
Also can say that i have been running miner for 30 minutes so i figured should have gotten some bbp shares solved atleast.

On the pool, I changed the 3 difficulties, please try these:

port 3008:  Diff = 2

Port 3032:  Diff = VarDiff (range:  1-10)

Port 3256:  Diff = 10

Thanks!

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 18, 2020, 04:05:29 PM
XMRig - 5.5.9



Please upgrade to 5.5.9 everyone as this version has the new code to prevent out of order execution.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 18, 2020, 04:35:41 PM
5.5.9 i got up and running.
Im testing out the  3256 port.

after 5 minutes i got 2 biblepay shares so seems working better now with lower difficulty.

Positive the terminal got less cluttered. 

ill let it run 12 hours atleast.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 18, 2020, 04:45:11 PM
5.5.9 i got up and running.
Im testing out the  3256 port.

after 5 minutes i got 2 biblepay shares so seems working better now with lower difficulty.

Positive the terminal got less cluttered. 

ill let it run 12 hours atleast.

Thanks, but unfortunately I added a new bug!

Re-releasing now (Ill increase the version).

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 18, 2020, 04:50:44 PM
XMRig - 5.6.0


- Fix share submission bug


Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 18, 2020, 05:02:47 PM
On the pool, I changed the 3 difficulties, please try these:

port 3008:  Diff = 2

Port 3032:  Diff = VarDiff (range:  1-10)

Port 3256:  Diff = 10


I just added two more ports:


port 3008:  Diff = 2
port 3007:  Diff = 7
Port 3005:  Diff = 5
Port 3032:  Diff = VarDiff (range:  1-10)
Port 3256:  Diff = 10

Ill remove the non corresponding ports later once we work the kinks out.

EDIT:  I see we also need to pass the correct nomp difficulty through to the client (it always says 1).  Ill add to todo.


Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 19, 2020, 12:14:05 PM
Looks like this latest release was real solid! I ran one rig for over 12 hours and only a few bbp share rejects, also

Currently installed ubuntu etc on another rig and fiddling with activating 1 gb huge pages.
Then im gonna see how it works.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 19, 2020, 02:10:10 PM
Looks like this latest release was real solid! I ran one rig for over 12 hours and only a few bbp share rejects, also

Currently installed ubuntu etc on another rig and fiddling with activating 1 gb huge pages.
Then im gonna see how it works.

Thats great!  Yeah, on an unrelated note, I probably spent 24 hours of my life doing some debugging that was unecessary.
I have been debugging xmrig in a virtual machine, and some of the changes I released were in response to believing I introduced a bug.
So just out of curiosity this morning I downloaded xmrig in the vm and ran it in debug mode and sure enough it crashed.  So the whole time Ive been dealing with something that is already part of the environment.  So basically I believe the way I need to summarize this is :  RandomX creates machine language in JIT for execution on various processors.  We cannot debug this in a vm 'normally'. 

This is pretty wild, so now I rebooted and Im testing the last version in windows again (this thing gave me so many false positives, I think after setting the MSR registers, the machine asked me to reboot, then the miner started dissapearing (silent exit) on my dev machine) - but as a strange coincinence (not related to something we added recently). 

Oh well anyway long story short it appears the GCC version is working on my windows dev machine now after a reboot, and its not exiting.

I guess I had some locked ram pages or something...

Ill try to burn this version in and confirm.

This morning I added the passthrough difficulty onto the users display.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 19, 2020, 02:25:33 PM
Sounds nice!  8)

Yeah i was wondering before why only saw 1 difficulty  when changing bbp difficulty..

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 19, 2020, 08:37:00 PM
Pinning this for the future in case anyone else has this issue (a silent exit by the miner after a random amount of time, especially on ryzen 1700s):
https://www.reddit.com/r/MoneroMining/comments/e4k7cq/xmrig_ryzen_7_1700_fix/f9e676q/

So there is a workaround, (Im experiencing this myself), we can make a loop in a batch file like this (pretend this is miner5.bat):

:miningloop
xmrig.exe --params
goto miningloop

I will probably be doing this myself.

And just to give a little background on the problem, first of all there is a CPU setting on some motherboards called 'opcache' that might fix the underlying issue.
But the reason we aren't trying to handle this inside the program is since the JIT machine language is generated on the fly, the actual error signal is a segfault, but in a machine language area that can't have an error catch around it - and - segfaults cause program instability if you try to program around them.  Another words the only safe way to handle this is to let the process die and restart the process at the OS level.

Hopefully not many of our users will have to do this - but I appear to be one in this category with my early version of the 1700, etc. 

I havent tried the bios change yet but Ill post if it works later.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 20, 2020, 11:20:55 AM
Please all, lets remember to test English, Russian and Ukraine during the next release:

https://forum.biblepay.org/index.php?topic=494.new#new

Just ensure the English behavior of the wallet is OK, for one (IE all menus are still captioned).  And if we have any Russian speaking testers, we can use your help testing Ukraine and Russian also.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 20, 2020, 11:31:26 AM
Never mind, it looks like we will need a core wallet release anyway for a couple more reasons.

Ill try to get this ready within 24 hours.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 20, 2020, 07:36:04 PM
1.5.0.3-Mandatory Upgrade for TestNet


- Ensure with chainlocks disabled, we can still sync from 0
- Ensure RX performance does not impact initial sync performance
- Add mutex around multithreaded rx queries, and solve initial singlethreaded lock issue
- Merge Marcus Antonios language translations from https://forum.biblepay.org/index.php?topic=494.new#new
- Ensure VersionMessage is handled properly in this branch

** All versions are ready **
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 20, 2020, 09:21:09 PM
XMRIG - 5.6.1-Leisure Upgrade for TestNet



- Pass actual share difficulty through to miner as first solved
parameter, and Solved share difficulty as second param (in brackets) for
each solved share, and add network latency to each solved share
- Modify code to be more compatible with future xmrig changes
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 21, 2020, 08:44:57 AM
XMRIG - 5.6.1-Leisure Upgrade for TestNet



- Pass actual share difficulty through to miner as first solved
parameter, and Solved share difficulty as second param (in brackets) for
each solved share, and add network latency to each solved share
- Modify code to be more compatible with future xmrig changes

ill be trying out 5.6.1 out later tonight on both windows and linux over the weekend.
Been running 5.6.0 on linux for 18h and it seems real stable for me,  not many rejects at all. accepted 1776/22 this with  Bbp 10 difficulty.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 21, 2020, 09:03:08 AM
ill be trying out 5.6.1 out later tonight on both windows and linux over the weekend.
Been running 5.6.0 on linux for 18h and it seems real stable for me,  not many rejects at all. accepted 1776/22 this with  Bbp 10 difficulty.

Thats great!

Yeah, I think the issues were on my end due to hardware.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 21, 2020, 10:06:01 AM
So it looks like all the testnet versions have been compiled.  Once you all upgrade can we please do a hash test?  Here is my hash test:


10:04:55

getblockhash 30197


10:04:55

2275f97ab020e94e4c4298798f55290764941daa92ef49a07b5fbef31adc2d4a


Once I know the entire network agrees then we can move on to testing that sancs still work properly.

Feel free to recreate your sancs.

Btw, they all say ENABLED in testnet because when chainlocks is off, they don't get ddosed.  So please ignore the status until we turn on chainlocks again.

Another words, they are all most likely down actually and they actually need revived.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 21, 2020, 10:08:02 AM
Do you guys feel optimistic about this idea?  IE have we come up wtih something good for orphan charity?
Imo, I think its a pretty good pool/system, in that you get two reward streams.  If I was a monero miner I think Id do this , even without helping charity.  Adding orphans on for me is a huge plus on top of that even.

I feel this is an underestimated idea.  As if it should attract a few thousands miners in one year.  I see there are 50,000 connections to minexmr, so we have plenty to pull in if they get wind of this.

We will probably need to run multiple pools to handle the load; probably one pool per 1000 users, etc.  But we can do that, given that our price should rise for each 1000 miners.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 21, 2020, 10:34:07 AM
From my perspective i was really hyped for the monero changing alghorithm from cryptonight to randomx because i already  had a bunch of cpus, and i think monero has a bright future so i want to support them.

Same time i really liked the idea of Bbp, giving to charity and all.
So then it was like shall i mine xmr or bbp cant do both on my cpus.. well dilemmas were rising.
 
Now  i think you might have hit the  jackpot, i mean xmr preety stable in price and all.  Also hopefully alot more help for those in need.  I belive alot of people are intrested in dual mining aswell. In the end i support monero network , bpp aswell and also can help some people in need. Cant ask for much more.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: oncoapop on February 21, 2020, 11:06:37 AM
From my perspective i was really hyped for the monero changing alghorithm from cryptonight to randomx because i already  had a bunch of cpus, and i think monero has a bright future so i want to support them.

Same time i really liked the idea of Bbp, giving to charity and all.
So then it was like shall i mine xmr or bbp cant do both on my cpus.. well dilemmas were rising.
 
Now  i think you might have hit the  jackpot, i mean xmr preety stable in price and all.  Also hopefully alot more help for those in need.  I belive alot of people are intrested in dual mining aswell. In the end i support monero network , bpp aswell and also can help some people in need. Cant ask for much more.

Thank you.

1. Firstly as you realized that I have not been able to recreate my sancs as somehow none of wallets were able to sync past 28010 and those that did at the correct hash as you published were empty.

2. Hence I would appreciate it if you could kindly send sufficent tBBP to be able to recreate the number of sancs that you would require me to setup in testnet. Address: yfAMxhGyQUXSAaPeV7d7YfhmQnY9o6utwA. Thank you.

3, I have been dual mining XMR + BBP at the moment (without synced BBP wallets). This innovative strategy is great, I really like the pace of innovation at BBP, though it can be challenging to keep up at times! I like the idea but have no idea how it will affect the long term economics. One needs to calculate the optimal ABN such that it manages to sustain the price of BBP assuming a large percentage of new XMR+BBP miners liquidate their BBP.

Thank you.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: oncoapop on February 21, 2020, 11:30:45 AM
Could you also kindly post the updated binaries for linux_x86. For some reason, the wallet is not able to start when using the downloaded binaries:

Code: [Select]
.error: couldn't connect to server: unknown (code -1)
(make sure server is running and you are connecting to the correct RPC port)

My larger servers can compile 1.5.0.3+ from source code and the wallets sync to the published height and hash but my smaller machines are unable to complete the task.

Code: [Select]
>cli -version
BiblePay Core RPC client version 1.5.0.3

>block
30211

>cli getblockhash 30211
82a5ef56631f932affee373ec8151f42e4472d0081969ceddc720d2ab305afda

Thank you.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 21, 2020, 12:45:18 PM
Thank you.

1. Firstly as you realized that I have not been able to recreate my sancs as somehow none of wallets were able to sync past 28010 and those that did at the correct hash as you published were empty.

2. Hence I would appreciate it if you could kindly send sufficent tBBP to be able to recreate the number of sancs that you would require me to setup in testnet. Address: yfAMxhGyQUXSAaPeV7d7YfhmQnY9o6utwA. Thank you.

3, I have been dual mining XMR + BBP at the moment (without synced BBP wallets). This innovative strategy is great, I really like the pace of innovation at BBP, though it can be challenging to keep up at times! I like the idea but have no idea how it will affect the long term economics. One needs to calculate the optimal ABN such that it manages to sustain the price of BBP assuming a large percentage of new XMR+BBP miners liquidate their BBP.

Thank you.

i  have no sanctuaries yet.  I have alot of these  tbbp i send over for you.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: oncoapop on February 21, 2020, 01:03:47 PM
i  have no sanctuaries yet.  I have alot of these  tbbp i send over for you.

Thank you, earlzmoade!
Blessings,
Oncoapop
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 21, 2020, 01:57:07 PM
Btw Rob i noticed diff seems ok on output in xmrig now, just wondering all Xmr charity chares always show 0 ms for me.

Shouldnt it be mixed like normal xmr shares like some show 60 ms, others 77 ms and so on..

Anyways great job on latest release!
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 21, 2020, 06:18:02 PM
Btw Rob i noticed diff seems ok on output in xmrig now, just wondering all Xmr charity chares always show 0 ms for me.

Shouldnt it be mixed like normal xmr shares like some show 60 ms, others 77 ms and so on..

Anyways great job on latest release!

Thanks a lot!
So trying to reproduce the 'latency' display, Im running 5.6.1 for windows:  I can see the Diff, (solved diff) then the latency.

For XMR I see 121 ms in parentheses and for BBP 120 ms in parentheses.

EDIT: OK - I see what you mean on XMR-Charity, yes, something is wrong in there, I will look at this!

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 21, 2020, 06:22:17 PM
Could you also kindly post the updated binaries for linux_x86. For some reason, the wallet is not able to start when using the downloaded binaries:

Code: [Select]
.error: couldn't connect to server: unknown (code -1)
(make sure server is running and you are connecting to the correct RPC port)

My larger servers can compile 1.5.0.3+ from source code and the wallets sync to the published height and hash but my smaller machines are unable to complete the task.

Code: [Select]
>cli -version
BiblePay Core RPC client version 1.5.0.3

>block
30211

>cli getblockhash 30211
82a5ef56631f932affee373ec8151f42e4472d0081969ceddc720d2ab305afda

Thank you.

1) Thanks, thats great on the hash btw, ours match.

2) On the binary, could you please tell me, on the downloaded linux binary, tell me the version in your getinfo?  It should be 1503 (or from the RPC tab).  Btw, you can try re-syncing with -erasechain=1 first.  (If you are running 1503).  If its not 1503 we need to make a release, which I dont mind making if its not 1503.  But it could be you have a bad block in the file from 1502, as we had a bug in 1502.  Once you resync your old funds should reappear as we did not veer off the big time original 300 million we made when we created the sancs.  Just let me know on the version and ill be glad to add a compile step to keep pressure from asking MIP.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 21, 2020, 06:29:40 PM
From my perspective i was really hyped for the monero changing alghorithm from cryptonight to randomx because i already  had a bunch of cpus, and i think monero has a bright future so i want to support them.

Same time i really liked the idea of Bbp, giving to charity and all.
So then it was like shall i mine xmr or bbp cant do both on my cpus.. well dilemmas were rising.
 
Now  i think you might have hit the  jackpot, i mean xmr preety stable in price and all.  Also hopefully alot more help for those in need.  I belive alot of people are intrested in dual mining aswell. In the end i support monero network , bpp aswell and also can help some people in need. Cant ask for much more.

Thanks, that makes me feel a lot better; I think a lot of miners will share the same thoughts!

And I think miners will be more compassionate than we think, especially if they can earn two coins that might be worth more in the future.

The other nice thing this clears up is the issue where we view mining as an expense (like I originally did in the early days).  I feel with the charity aspect in the mix, this makes the miners more of the 'heroes'.  Another words, I look at a miner as 'helping' our cause now, as they are paying for the orphans and donating precious electricity to sponsor orphans.  So they become the heroes in this case, which I think is huge for the total team morale; another words in the early days, it was sort of a union vs. company mantra, the miners are spending the money but providing security.  In this system its more of the miners are donating compassionately , and are not an expense, but the co-mvp's for success, etc.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 21, 2020, 06:40:15 PM
Thank you.

1. Firstly as you realized that I have not been able to recreate my sancs as somehow none of wallets were able to sync past 28010 and those that did at the correct hash as you published were empty.

2. Hence I would appreciate it if you could kindly send sufficent tBBP to be able to recreate the number of sancs that you would require me to setup in testnet. Address: yfAMxhGyQUXSAaPeV7d7YfhmQnY9o6utwA. Thank you.

3, I have been dual mining XMR + BBP at the moment (without synced BBP wallets). This innovative strategy is great, I really like the pace of innovation at BBP, though it can be challenging to keep up at times! I like the idea but have no idea how it will affect the long term economics. One needs to calculate the optimal ABN such that it manages to sustain the price of BBP assuming a large percentage of new XMR+BBP miners liquidate their BBP.

Thank you.

On #1, let me see if you got past 28010 with the erasechain=1 and 1.5.0.3?

On #2, do you still need some more after Earlz's?

On #3,  Yes, thanks for the compliment and lets talk about the long term ramifications.  Although, I cannot say this with certainty, the good news is our DSS (decision support study) of the cryptoeconomic model that we ran a couple months ago did shed what I believe to be a little more light on the subject (as compared to what I knew before running it).  So, I stress, I cannot predict the future nor say with certainty.  But these are the elements I take away from that DSS:  It appears to be a pro to *not* limit our coin emissions for POW to miners (through ABN, or limiting schemes) as long as there is no 51% attack risk, another words, we seem to believe that a high miner distribution (vs a small miner distribution) gives us a wider investor ratio and a lot of free PR.  (In the case of randomx - these addl miners do provide more security to bbp as the influx makes a 51% even less - then we add on chainlocks also).  The larger coins that are successful have 50,000+ distinct miners widely receiving tiny amounts into distinct wallets, but we generally see 1-5% of those miners become investors who buy the currency.  A lot just hold on to the coins in hope that some day they go to $1 and never sell them.  So thats one point.  The other point is trying to increase the value per unit, due to the extreme difficulty of mining one currency unit.  Let us speculate that 5,000 new miners come on board- what this does is it makes it extremely hard to mine one bbp.  One bbp that used to be worth .002 cents starts being worth potentially .20 cents, because no miners want to sell it below their cost.  I realize this is hard to believe, but the effect takes a long time and its a basic energy:cost-per-unit arbitrage that lets the free market eventually drive the BBP price per unit up to the electric cost.  So what we would ideally want to see is a year down the road, 10,000 miners with a cost per bbp at .25 cents, etc.  That would allow us to support 1,000 orphans per month (without sell pressure).  This is similar to what you see in BTC, Dash and Doge - those coins per unit are selling for the electric cost, etc.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 21, 2020, 07:43:14 PM
Thanks a lot!
So trying to reproduce the 'latency' display, Im running 5.6.1 for windows:  I can see the Diff, (solved diff) then the latency.

For XMR I see 121 ms in parentheses and for BBP 120 ms in parentheses.

EDIT: OK - I see what you mean on XMR-Charity, yes, something is wrong in there, I will look at this!

The latency is fixed for the next release for XMR-Charity.  Thanks.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 23, 2020, 04:15:24 AM
In the NOMP rx test getting started section, under example  you could add lets say.


to add .your_worker_name after monero adress for per cpu information.

Perhaps its self explanable but its never wrong to make things easy for people that are new to this  kind of stuff.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: togoshigekata on February 23, 2020, 11:53:46 AM
Do you guys feel optimistic about this idea?  IE have we come up wtih something good for orphan charity?
Imo, I think its a pretty good pool/system, in that you get two reward streams.  If I was a monero miner I think Id do this , even without helping charity.  Adding orphans on for me is a huge plus on top of that even.

I feel this is an underestimated idea.  As if it should attract a few thousands miners in one year.  I see there are 50,000 connections to minexmr, so we have plenty to pull in if they get wind of this.

We will probably need to run multiple pools to handle the load; probably one pool per 1000 users, etc.  But we can do that, given that our price should rise for each 1000 miners.

I think its a cool feature

and RandomX seems to be pretty popular in the Altcoin Mining section of Bitcointalk

I started a Bitcointalk thread about Merge Mining BBP and XMR:
https://bitcointalk.org/index.php?topic=5226080.0
(Please post in here periodically!)

How do we spread the news of our feature to all the Monero miners?
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 23, 2020, 12:13:33 PM
In the NOMP rx test getting started section, under example  you could add lets say.


to add .your_worker_name after monero adress for per cpu information.

Perhaps its self explanable but its never wrong to make things easy for people that are new to this  kind of stuff.

Yes, good idea, I will post when its ready.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 23, 2020, 02:15:01 PM
I think its a cool feature

and RandomX seems to be pretty popular in the Altcoin Mining section of Bitcointalk

I started a Bitcointalk thread about Merge Mining BBP and XMR:
https://bitcointalk.org/index.php?topic=5226080.0
(Please post in here periodically!)

How do we spread the news of our feature to all the Monero miners?

Monero is really big and so far as i know Bbp is the only coin that has this feature, being able to dual mine with xmr..
Although in testnet, but for sure it seems like a superb idea, when i saw it posted in reddit i was like finally, this is groundbreaking..

Aswell as that Bbp is not just another blockchain with the same features, what i feel is puts Bbp in another bracket is the charity aspect of it.

Christians or not christians people will jump aboard, we could do a post on lets say reddit/moneromining   and so forth to get some more people when we are getting closer to launch.

Aswell as you did the mining altcoins section i saw.  Intresting times ahead indeed.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 24, 2020, 09:55:23 AM
Monero is really big and so far as i know Bbp is the only coin that has this feature, being able to dual mine with xmr..
Although in testnet, but for sure it seems like a superb idea, when i saw it posted in reddit i was like finally, this is groundbreaking..

Aswell as that Bbp is not just another blockchain with the same features, what i feel is puts Bbp in another bracket is the charity aspect of it.

Christians or not christians people will jump aboard, we could do a post on lets say reddit/moneromining   and so forth to get some more people when we are getting closer to launch.

Aswell as you did the mining altcoins section i saw.  Intresting times ahead indeed.

And you know I'd almost like to say we may be the first bitcoin fork with randomx, because you know Monero is a Bytecoin branch.
So this is very unique in that we might have something novel here.  (Whats nice about the bitcoin branch is QT, imho.  QT empowers the user with the transactionlist and coin control tab).  And of course we have the GSCs - so in the future large companies can make scheduled payments through the wallet  - or use governance.

I've also been thinking lately of something that I feel God wants in the ecosystem:  A Christian dashboard that makes us a useful tool for Christians - for our next website.
I was thinking one problem I have when I pray for people is sort of the CRM problem - you need to remember where they are in their walk etc, so we could have a dashboard that lets you manage your Christian relationships (IE John is agnostic, a summary, last contact with him, what we shared last, etc).  Something that makes Christians realize BiblePay is a useful CRM type tool.  I already realize we need a better prayer blog with more of an interactive feel.

Im going to recreate our roadmap and try to capture a new updated vision now. 

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: oncoapop on February 24, 2020, 10:55:35 AM
On #1, let me see if you got past 28010 with the erasechain=1 and 1.5.0.3?

On #2, do you still need some more after Earlz's?

On #3,  Yes, thanks for the compliment and lets talk about the long term ramifications.  Although, I cannot say this with certainty, the good news is our DSS (decision support study) of the cryptoeconomic model that we ran a couple months ago did shed what I believe to be a little more light on the subject (as compared to what I knew before running it).  So, I stress, I cannot predict the future nor say with certainty.  But these are the elements I take away from that DSS:  It appears to be a pro to *not* limit our coin emissions for POW to miners (through ABN, or limiting schemes) as long as there is no 51% attack risk, another words, we seem to believe that a high miner distribution (vs a small miner distribution) gives us a wider investor ratio and a lot of free PR.  (In the case of randomx - these addl miners do provide more security to bbp as the influx makes a 51% even less - then we add on chainlocks also).  The larger coins that are successful have 50,000+ distinct miners widely receiving tiny amounts into distinct wallets, but we generally see 1-5% of those miners become investors who buy the currency.  A lot just hold on to the coins in hope that some day they go to $1 and never sell them.  So thats one point.  The other point is trying to increase the value per unit, due to the extreme difficulty of mining one currency unit.  Let us speculate that 5,000 new miners come on board- what this does is it makes it extremely hard to mine one bbp.  One bbp that used to be worth .002 cents starts being worth potentially .20 cents, because no miners want to sell it below their cost.  I realize this is hard to believe, but the effect takes a long time and its a basic energy:cost-per-unit arbitrage that lets the free market eventually drive the BBP price per unit up to the electric cost.  So what we would ideally want to see is a year down the road, 10,000 miners with a cost per bbp at .25 cents, etc.  That would allow us to support 1,000 orphans per month (without sell pressure).  This is similar to what you see in BTC, Dash and Doge - those coins per unit are selling for the electric cost, etc.

Thank you for that analysis.

For the time being, I have recreated 3 sancs. I realized that the 1.5.0.3 compilation was flaky (at least on my) Ubuntu 16.04 so I had to upgrade all my servers to 18.04 before compiling Biblepayd from source. As you can imagine, upgrading and then compiling on 1-2 CPU servers with 1-2 Gb of RAM, was not painless... but it is done and we have 3 more ENABLED sancs on testnet.

 
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 24, 2020, 08:09:11 PM
Thank you for that analysis.

For the time being, I have recreated 3 sancs. I realized that the 1.5.0.3 compilation was flaky (at least on my) Ubuntu 16.04 so I had to upgrade all my servers to 18.04 before compiling Biblepayd from source. As you can imagine, upgrading and then compiling on 1-2 CPU servers with 1-2 Gb of RAM, was not painless... but it is done and we have 3 more ENABLED sancs on testnet.

Ok, thats great you are back up with 3.  Let me take a look at what state mine are in and once I get them up Ill post again and see if we can enable chainlocks here in testnet (primarily so we can see the d-dossing POSE start working again).

So one concern I do have though, to my knowledge, the last unix release should not have been flaky; so I assume maybe you had a bad block in there.  Im not sure who the right testnet guy is for this, but could you or someone please test the unix binary release and see if "getinfo" does show 1.5.0.3 for it, and if you can sync from zero?  Just delete the chain with "-erasechain=1" and see if it syncs then let one run from the binary.  I just want to make sure we dont have any surprises later.

As far as compiling it, I assume you already have swap space on there?  That is a necessity as with randomx we use 256meg extra.  Actually Im hoping you can tell us how well biblepay-qt works on your 1 gig vm with randomx in it?  It will be refreshing to know that it works fine for days.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: oncoapop on February 25, 2020, 02:07:30 AM
Ok, thats great you are back up with 3.  Let me take a look at what state mine are in and once I get them up Ill post again and see if we can enable chainlocks here in testnet (primarily so we can see the d-dossing POSE start working again).

So one concern I do have though, to my knowledge, the last unix release should not have been flaky; so I assume maybe you had a bad block in there.  Im not sure who the right testnet guy is for this, but could you or someone please test the unix binary release and see if "getinfo" does show 1.5.0.3 for it, and if you can sync from zero?  Just delete the chain with "-erasechain=1" and see if it syncs then let one run from the binary.  I just want to make sure we dont have any surprises later.

As far as compiling it, I assume you already have swap space on there?  That is a necessity as with randomx we use 256meg extra.  Actually Im hoping you can tell us how well biblepay-qt works on your 1 gig vm with randomx in it?  It will be refreshing to know that it works fine for days.

This is the experiment and results:

1. Use an existing server running a 1.5.0.3 wallet (compiled from source) which can sync to the top (shows hardware and OS is fine).
Code: [Select]
>uname -a
Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
(Ubuntu 18.04 upgraded from 16.04)

>lscpu
...
Model name:          Intel(R) Xeon(R) CPU           X7560  @ 2.27GHz x 4 vCPU
...
>cli getblockhash 30939
19a3bdb654b0f7ebc7b7bd64fde3d44d7abc94564ab21b161664025e084d71b9

2. stop biblepayd on old account
3. download binaries in the new user account (newly created) in separate directory

Code: [Select]
wget https://biblepay.org/biblepayd-evo-testnet-x86_64-pc-linux-gnu.tar.gz

Hash of the downloaded file
93c1a6cdbc8b1b546fe13d782cdd14014cb6c7999897ec8e91b94823002b962d

tar -xvf biblepayd-evo-testnet-x86_64-pc-linux-gnu.tar.gz
chmod +x  biblepay*

4. cli -version (to confirm deployment of binaries)

Code: [Select]
BiblePay Core RPC client version 1.5.0.3

4. biblepaytest.conf with

Code: [Select]
addnode=testnet.biblepay.org
addnode=dns1.biblepay.org
addnode=dns3.biblepay.org

rpcuser=x
rpcpassword=x
rpcallowip=127.0.0.1
daemon=1
testnet=1
debug=1

5. start biblepayd (it creates new testnet3 directory and copy of the blockchain)
6. it creates a fresh wallet so no chance of bad blocks etc
7. Errors:
Code: [Select]
error code: -28
error message:
Loading PODC Researchers
...
Loading wallet... (97.3 %)
....
error: couldn't connect to server: unknown (code -1)
(make sure server is running and you are connecting to the correct RPC port)

8. ..debug.log file output around the time of biblepayd exit

Code: [Select]
2020-02-25 07:32:17 Received a POST request for / from 127.0.0.1:50724
2020-02-25 07:32:17 ThreadRPCServer method=mnsync
2020-02-25 07:32:22 Received a POST request for / from 127.0.0.1:50730
2020-02-25 07:32:22 ThreadRPCServer method=mnsync
2020-02-25 07:32:27 Received a POST request for / from 127.0.0.1:50732
2020-02-25 07:32:27 ThreadRPCServer method=mnsync
2020-02-25 07:32:28 peer=2 using obsolete version 70216; disconnecting
2020-02-25 07:32:32 Received a POST request for / from 127.0.0.1:50744
2020-02-25 07:32:32 ThreadRPCServer method=mnsync
2020-02-25 07:32:35  pushing version 1702received version message: /BiblePay Core:1.5.0.3/: version 70753, blocks=30947, us=45.62.240.90:40001, peer=3
2020-02-25 07:32:35 debug turned on:
2020-02-25 07:32:35   thread biblepay-msghan category 1
2020-02-25 07:32:35 added time data, samples 2, offset -51 (+0 minutes)
2020-02-25 07:32:36 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 2000 fInitialDownload=1
2020-02-25 07:32:36 more getheaders (2000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:37 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 4000 fInitialDownload=1
2020-02-25 07:32:37 more getheaders (4000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:37 ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 Pre-allocating up to position 0x100000 in rev00000.dat
2020-02-25 07:32:37 UpdateTip: new best=9c223ac553eac067ad9cc119adf40e470e2eb950408775d2c3b6096010d41528 height=1 version=0x20000000 log2_work=2.00000000 tx=2 date='2019-09-19 15:33:01' progress=0.000019 cache=0.0MiB(1txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=238af87743f4d3b9f4c9169fb4ab985517785264b4d23e137643c84306e180a8 height=2 version=0x20000000 log2_work=2.58496250 tx=3 date='2019-09-19 15:33:16' progress=0.000028 cache=0.0MiB(2txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=2b6ee76068025deb173c6e8be0f414b160b3c938b37f56ef37b7b1564c84a09d height=3 version=0x20000000 log2_work=3.00000000 tx=4 date='2019-09-19 15:33:31' progress=0.000037 cache=0.0MiB(3txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=39cc5ad4f5a201cfd266c6a13fc6a8822fd7b971ae881a17b0ca32aab97277be height=4 version=0x20000000 log2_work=3.32192809 tx=5 date='2019-09-19 15:33:46' progress=0.000047 cache=0.0MiB(4txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=b19d93b185162c891d2582024abe93e6e8e87ffa9e6a9d22e88220d5f24853d5 height=5 version=0x20000000 log2_work=3.90689060 tx=6 date='2019-09-19 15:34:01' progress=0.000056 cache=0.0MiB(5txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=0bfe393a24953d7739d3a9da70c2074cb45c3e9a7161d65157a8d9d72d02893b height=6 version=0x20000000 log2_work=4.58496250 tx=7 date='2019-09-19 15:34:16' progress=0.000066 cache=0.0MiB(6txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=a4c3024fbb6090607413b6e06854b5a4991d7ce91d1f4891002f187603f3ae33 height=7 version=0x20000000 log2_work=4.85798100 tx=8 date='2019-09-19 15:34:31' progress=0.000075 cache=0.0MiB(7txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=126ad2068e4e77b671ce614779b9591fb2be5f14e21a42cacb0c00e28e38ff9e height=8 version=0x20000000 log2_work=5.52356196 tx=9 date='2019-09-19 15:34:46' progress=0.000084 cache=0.0MiB(8txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=169b7e142aa235a788f369ab89c6f3b0686bcf772b145645c337fa8d7b745d41 height=9 version=0x20000000 log2_work=5.64385619 tx=10 date='2019-09-19 15:35:01' progress=0.000094 cache=0.0MiB(9txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=1c75deb60d1cd8fdebe33259a60ee4baf98f7ea1dc78f14d59a5dcd4a855fc3c height=10 version=0x20000000 log2_work=5.97727992 tx=11 date='2019-09-19 15:35:16' progress=0.000103 cache=0.0MiB(10txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=b9432e382586d661ba8788a2987f7a02a2801597e632826480ee997baa6ff28f height=11 version=0x20000000 log2_work=6.06608919 tx=12 date='2019-09-19 15:35:31' progress=0.000112 cache=0.0MiB(11txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=6a95a72b12f328d734bb0c1f96db5f6a208ec1b277b7d63a62d4a8cf246b5f53 height=12 version=0x20000000 log2_work=6.26678654 tx=13 date='2019-09-19 15:35:46' progress=0.000122 cache=0.0MiB(12txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=544141fe4185dd6564f999fec8888d8706e0add70807da218da0a0639317e60c height=13 version=0x20000000 log2_work=6.59991284 tx=14 date='2019-09-19 15:36:01' progress=0.000131 cache=0.0MiB(13txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=2d2ab820680ce697c6a27c2822f1f96c6279aeb0b8d0197a69a48a925c5b9028 height=14 version=0x20000000 log2_work=6.65821148 tx=15 date='2019-09-19 15:36:16' progress=0.000140 cache=0.0MiB(14txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=1a3235f8c697a63257c0256323cd5826f69cbb72d3c52bf3ab924cc32af6fde9 height=15 version=0x20000000 log2_work=6.84549005 tx=16 date='2019-09-19 15:36:31' progress=0.000150 cache=0.0MiB(15txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=d89053eead9f9cf2019c87de1be982cf10c2b2b25be65bb77ccbb5cf60da8dd1 height=16 version=0x20000000 log2_work=6.90689060 tx=17 date='2019-09-19 15:36:46' progress=0.000159 cache=0.0MiB(16txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  Received a POST request for / from 127.0.0.1:50748
2020-02-25 07:32:37 ThreadRPCServer method=mnsync
2020-02-25 07:32:38 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 6000 fInitialDownload=1
2020-02-25 07:32:38 more getheaders (6000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:38 ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=7146495d05421dd4d7119cf57c297e22458d6b624e1045c25c9a3c487ef6f9d8 height=17 version=0x20000000 log2_work=7.18982456 tx=18 date='2019-09-19 15:37:01' progress=0.000168 cache=0.0MiB(17txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=ee115f49afd3ceed1f9ea5f9022b9037daecd4ccfb1675a537db0d20cc319f84 height=18 version=0x20000000 log2_work=7.22881869 tx=19 date='2019-09-19 15:37:16' progress=0.000178 cache=0.0MiB(18txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=8b01c2d73109efc42d3b26df74ebb4b6f47bad592023fd2cbcdc65b1861a71ae height=19 version=0x20000000 log2_work=7.41785251 tx=20 date='2019-09-19 15:37:31' progress=0.000187 cache=0.0MiB(19txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=d3b7cfe27ef18576767c381a2b54815bc478370a76296f797d71ae36bf03cc62 height=20 version=0x20000000 log2_work=7.45121111 tx=21 date='2019-09-19 15:37:46' progress=0.000197 cache=0.0MiB(20txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=058b0d5d41589e36cb7374aba076d3c210e0ceee8b3eb9b5640430f491771c58 height=21 version=0x20000000 log2_work=7.61470984 tx=22 date='2019-09-19 15:38:01' progress=0.000206 cache=0.0MiB(21txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=802d2463b3bdaecc5fe815892db95ce4a3b1825290d41d76d39fb831dfca79e6 height=22 version=0x20000000 log2_work=7.64385619 tx=23 date='2019-09-19 15:38:16' progress=0.000215 cache=0.0MiB(22txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=9953e73de4d29a101bfcfd74c2a7042c2d5ec5877902ffa2801defbb3f7b4eb1 height=23 version=0x20000000 log2_work=7.75488750 tx=24 date='2019-09-19 15:38:31' progress=0.000225 cache=0.0MiB(23txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=d85ed38301f90a5681ac93d588d9bde375f495f2e72d5cbdfa6bd0cd1c8ca7ed height=24 version=0x20000000 log2_work=7.78135971 tx=25 date='2019-09-19 15:38:46' progress=0.000234 cache=0.0MiB(24txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=0d33f97d3ddc85477973e1ece454f059d899f99a53e2aca8225f373c0397cd86 height=25 version=0x20000000 log2_work=7.85798100 tx=26 date='2019-09-19 15:39:49' progress=0.000243 cache=0.0MiB(25txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=644f05f9a7d3e5601f79408f058a9b28bda146a4eadd628e113761683db80f5c height=26 version=0x20000000 log2_work=8.03891899 tx=27 date='2019-09-19 15:40:04' progress=0.000253 cache=0.0MiB(26txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=0b59e12acb0fe81a37dbcc1e81d71729276f395780a6d9c6b940623f4375caf4 height=27 version=0x20000000 log2_work=8.06608919 tx=28 date='2019-09-19 15:40:19' progress=0.000262 cache=0.0MiB(27txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=58d8a70a891a0bd3183baf0d75a73978b4f20a6a2d4530f5d4c4bce63790d99b height=28 version=0x20000000 log2_work=8.19475685 tx=29 date='2019-09-19 15:40:34' progress=0.000271 cache=0.0MiB(28txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=22a0fe6b3f80fb41bfeb221c53fbc1ff04505f7792128e38f15919fd022c3a20 height=29 version=0x20000000 log2_work=8.22400167 tx=30 date='2019-09-19 15:40:49' progress=0.000281 cache=0.0MiB(29txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=2b7bc612b2cb69c9105cab95a5138381d153d99ee0fda9778f5287df58a88797 height=30 version=0x20000000 log2_work=8.24317398 tx=31 date='2019-09-19 15:41:04' progress=0.000290 cache=0.0MiB(30txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=94c551030dcee5fa52fc418f1e8a273eb94e925450c84602c8bf38e98789b41a height=31 version=0x20000000 log2_work=8.30378075 tx=32 date='2019-09-19 15:41:19' progress=0.000299 cache=0.0MiB(31txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=fb4706c120c646c23cb7e4c9ee9e1e1781e1d8f71cbcd2f17bbedc8124ad1848 height=32 version=0x20000000 log2_work=8.32192809 tx=33 date='2019-09-19 15:41:34' progress=0.000309 cache=0.0MiB(32txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 8000 fInitialDownload=1
2020-02-25 07:32:39 more getheaders (8000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:39 ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=91e4e1c6076bfb9d03bf1f549d642bc254426c71e8d15c152aab3f77fd72bafa height=33 version=0x20000000 log2_work=8.36194377 tx=34 date='2019-09-19 15:41:49' progress=0.000318 cache=0.0MiB(33txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=7f0fb4ad6eb15674d507e0a92c3c54004df3530fe11d746f4a25dd2200f6f458 height=34 version=0x20000000 log2_work=8.45121111 tx=35 date='2019-09-19 15:42:04' progress=0.000328 cache=0.0MiB(34txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=7b81729377d3ba308318c10279f3eaf96f6db68837d82d5f2c3467c915278793 height=35 version=0x20000000 log2_work=8.46760555 tx=36 date='2019-09-19 15:42:19' progress=0.000337 cache=0.0MiB(35txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=a924bfa21d5f4163399587997b1fe54682c65e7281889529ec03f75e2ab1d419 height=36 version=0x20000000 log2_work=8.52747701 tx=37 date='2019-09-19 15:42:34' progress=0.000346 cache=0.0MiB(36txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=2e58b956975d2cb2f80fbe9d25791ad9e38cf6142953a363937a7a23fd51be69 height=37 version=0x20000000 log2_work=8.54689446 tx=38 date='2019-09-19 15:42:49' progress=0.000356 cache=0.0MiB(37txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=c27b3aa43aa465b77f4b5b34d7c74bc3d19ff03ea0cac74dbfa2fd9582e51fdd height=38 version=0x20000000 log2_work=8.66888498 tx=39 date='2019-09-19 15:43:04' progress=0.000365 cache=0.0MiB(38txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=b46840fbe5e9ef46c8ddb7bdc9e25b50493c77550cff19e6ef4b8b317ac829f3 height=39 version=0x20000000 log2_work=8.68299458 tx=40 date='2019-09-19 15:43:19' progress=0.000374 cache=0.0MiB(39txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=334aa28219438ad386a7a4e87eb2f633cce4ced15e5cc18e9828b4eabe32b6c6 height=40 version=0x20000000 log2_work=8.79116289 tx=41 date='2019-09-19 15:43:34' progress=0.000384 cache=0.0MiB(40txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=da4f541fd413398cccce5f6d9e0dbc644f9b17a051f465740fc8484a2b7ce7b9 height=41 version=0x20000000 log2_work=8.80735492 tx=42 date='2019-09-19 15:43:49' progress=0.000393 cache=0.0MiB(41txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=cbbc7e3fd74891f2e816535c0679fde81858ceff2ae9fb5bd5d17af78c44e4f8 height=42 version=0x20000000 log2_work=9.00842862 tx=43 date='2019-09-19 15:44:04' progress=0.000402 cache=0.0MiB(42txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=3b9ac1a20a201b282e88f6d1d87ab51efb6898ebe2d9ac5d45f78dd5007ebcfb height=43 version=0x20000000 log2_work=9.02236781 tx=44 date='2019-09-19 15:44:19' progress=0.000412 cache=0.0MiB(43txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=ab9a2d23f7ea54bb9b52c5c9216ff9b9d5af70abcfa1debc0900d621c50f2850 height=44 version=0x20000000 log2_work=9.03342300 tx=45 date='2019-09-19 15:44:34' progress=0.000421 cache=0.0MiB(44txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=8120a9b85934314afa09de38bd4426e1f409cdf2b51fa1e8730ee77c224d8ee4 height=45 version=0x20000000 log2_work=9.05799172 tx=46 date='2019-09-19 15:44:49' progress=0.000430 cache=0.0MiB(45txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=aa3fffe227186ba2f8708a8e2566a8fa0b8aef5476ab0e8154a4461b9c12dc47 height=46 version=0x20000000 log2_work=9.24555271 tx=47 date='2019-09-19 15:45:04' progress=0.000440 cache=0.0MiB(46txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=698e25b95048d926c45f2dc841d58cfd74163a04a7735fa8b2a7eefc61ef5916 height=47 version=0x20000000 log2_work=9.25502857 tx=48 date='2019-09-19 15:45:19' progress=0.000449 cache=0.0MiB(47txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=2e6124234f988fdcfcece29a79905eea6784ada8f8442094a3ef91bdcbf6b50b height=48 version=0x20000000 log2_work=9.28540222 tx=49 date='2019-09-19 15:45:34' progress=0.000459 cache=0.0MiB(48txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 10000 fInitialDownload=1
2020-02-25 07:32:39 more getheaders (10000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:39 ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=241b8591f93464cff00c25db841f900fb01d7642013161425bf817c84fff8479 height=49 version=0x20000000 log2_work=9.29691621 tx=50 date='2019-09-19 15:45:49' progress=0.000468 cache=0.0MiB(49txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=6aa1e8b38ea074e8133339deafb7b0d83e4565e2b37169b47aa3f0fb9fb394d9 height=50 version=0x20000000 log2_work=9.35755200 tx=51 date='2019-09-19 15:46:04' progress=0.000477 cache=0.0MiB(50txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=6057db921f2482de6c9dcddc00af4e46804de1b1501a37418fcc6cbe8d5b5a18 height=51 version=0x20000000 log2_work=9.36632221 tx=52 date='2019-09-19 15:46:19' progress=0.000487 cache=0.0MiB(51txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=dc0df33264aa68c778af06ba6f24d549f8f17046e1eaa8e019f997d5d1e14dea height=52 version=0x20000000 log2_work=9.40087944 tx=53 date='2019-09-19 15:46:34' progress=0.000496 cache=0.0MiB(52txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=8f10cec7dc3515c52ba90a612e4c82d440cbd4a99a2ab443b74a7c1be51ee90e height=53 version=0x20000000 log2_work=9.40939094 tx=54 date='2019-09-19 15:46:49' progress=0.000505 cache=0.0MiB(53txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=23cdaa4ea1065033b4c743a61fb04fb8653c21d3a39bc7e96b84ab9334aa43f9 height=54 version=0x20000000 log2_work=9.43879185 tx=55 date='2019-09-19 15:47:04' progress=0.000515 cache=0.0MiB(54txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=72ce7c4f1bf8b41c9b057da94204d929af35ee6756c7e14e1c9706c2d7c48ad6 height=55 version=0x20000000 log2_work=9.59432460 tx=56 date='2019-09-19 15:47:19' progress=0.000524 cache=0.0MiB(55txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=341c4a6f8608d9e50776f795bee87de579aee661ce208946f7c3584389b927ce height=56 version=0x20000000 log2_work=9.60547952 tx=57 date='2019-09-19 15:47:34' progress=0.000533 cache=0.0MiB(56txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=15a315723556907044d8507786644576e4b670bb44696ca017967716298ed8d7 height=57 version=0x20000000 log2_work=9.61286850 tx=58 date='2019-09-19 15:47:49' progress=0.000543 cache=0.0MiB(57txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=544ef623886523e18ef22ce0e511ac9401e6ca779c30066f077c0b66a4015b89 height=58 version=0x20000000 log2_work=9.65463603 tx=59 date='2019-09-19 15:48:04' progress=0.000552 cache=0.0MiB(58txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=54025bb678c76a60009db817ef24632494fa19d38f2b4230da8a5a71f6346662 height=59 version=0x20000000 log2_work=9.66355810 tx=60 date='2019-09-19 15:48:19' progress=0.000561 cache=0.0MiB(59txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=042d11e87e46385b06014051f584211ac8fc5fe3abbc301fa02a9fa535440424 height=60 version=0x20000000 log2_work=9.68299458 tx=61 date='2019-09-19 15:48:34' progress=0.000571 cache=0.0MiB(60txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=8b209285a11fab86daf23dc119c086563d6cc57e0899e5271b270c94bf0cb32a height=61 version=0x20000000 log2_work=9.78953364 tx=62 date='2019-09-19 15:48:49' progress=0.000580 cache=0.0MiB(61txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=4556e43581acae7ef87acacd32d37b2e93bdf443f39aeaa3f5e82794fcf1cc29 height=62 version=0x20000000 log2_work=9.79928162 tx=63 date='2019-09-19 15:49:04' progress=0.000590 cache=0.0MiB(62txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=1d1128eed7a0061ebe4e868f7be6c67282eaf86c9d53f79acb4eb74d10712c0b height=63 version=0x20000000 log2_work=9.80574387 tx=64 date='2019-09-19 15:49:19' progress=0.000599 cache=0.0MiB(63txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=a6258371135e84756876859543bb54abe79cf51a2adf2ce702fd8d5b78dcd5cf height=64 version=0x20000000 log2_work=9.84705735 tx=65 date='2019-09-19 15:49:34' progress=0.000608 cache=0.0MiB(64txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  SPORK -- hash: a59460fb13eea5a1a6f01e07b7a4ba69d641392f3e22cb8d5cf8e6495cbbfc0e id: 10004 value:   10000000 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 0b55391d2c25736279fb64125f046026b833b7021b00cafb296dcd287b72106f id: 10008 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 0cf0f08e13495f654e08b57e5c05673cd1bab7ab7d2198d50802ece16e29ef79 id: 10015 value: 4070908800 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 6525f1c1a122176edaa8299439b580e5dca25b000a501023333f1a2aadcef848 id: 10019 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 50c879a0841b5cd3c49346b235c096c885a054e4ac0f8afd0d337732992aee07 id: 10002 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 90666fd23a735a86b8f150508b1b20e3e631e0b89de6ced2bde5414531e79a8c id: 10014 value:      17000 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 7ff45555e5fe6acbc1c19e1bbc002514a45288ee07392803cc9d4c25b8c9641b id: 10005 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 815ca4a6ad852c303d6dba1542db80d9eee0e1e0bc0e315b22d73910b2343bba id: 10090 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 2b4801666c9dcc6a0b7b9fcdd3adf437a03afd3c166449a2195484840f49ac96 id: 10018 value: 4070908800 bestHeight: 64 peer=3 new
2020-02-25 07:32:39  pushing version 1702Moving 149.28.125.16:40001 to tried
2020-02-25 07:32:39 received version message: /BiblePay Core:1.5.0.3/: version 70753, blocks=30947, us=45.62.240.90:53846, peer=4
2020-02-25 07:32:39 SPORK -- hash: 7d62890f09ccf897835181aa2f5c3ff48813cdebf2c5ecac2e1fe6efbe94008c id: 10011 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 820ec77eb24c149872bcf49391234e10d1c16f1602b238a6661bf7a8171acc53 id: 10016 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:40 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 12000 fInitialDownload=1
2020-02-25 07:32:40 more getheaders (12000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:40 ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=196adb6b953dced2c60d200f1a59cbb93b3aa8879eb5f3027e19abdc62504bc3 height=65 version=0x20000000 log2_work=9.85486838 tx=66 date='2019-09-19 15:49:49' progress=0.000618 cache=0.0MiB(65txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=74379e8f191f45b64896d68d5e8b8be33fef82850b20d787c5401810a85e2a7f height=66 version=0x20000000 log2_work=9.87651695 tx=67 date='2019-09-19 15:50:05' progress=0.000627 cache=0.0MiB(66txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=675d263f69868db421cf65a289ff214c48db48cb192f05f65a380d3c9f0e0bca height=67 version=0x20000000 log2_work=9.88264305 tx=68 date='2019-09-19 15:50:20' progress=0.000636 cache=0.0MiB(67txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=4fd3c136076767986a0a02d874c3618191c86ae51b5cd1ac53625b4cc1e1995a height=68 version=0x20000000 log2_work=9.90689060 tx=69 date='2019-09-19 15:50:35' progress=0.000646 cache=0.0MiB(68txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=79d80617c48debe332ef73294fd8316d99d9001482b0178b580208f0de375362 height=69 version=0x20000000 log2_work=9.91288934 tx=70 date='2019-09-19 15:50:50' progress=0.000655 cache=0.0MiB(69txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=77c4a20d1d6f574278ae4d101eecf5b8ca31378769b46f663fc21291f8f6e272 height=70 version=0x20000000 log2_work=9.92777796 tx=71 date='2019-09-19 15:51:05' progress=0.000664 cache=0.0MiB(70txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=339c93cc309b3289c61038a534bbcc15f5f8a68fd3d90d0ddbe1bac65cfd2fae height=71 version=0x20000000 log2_work=9.95855272 tx=72 date='2019-09-19 15:51:20' progress=0.000674 cache=0.0MiB(71txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=6db29ae6ee8e1756b53ae3af09043955f8016a8265c910c739f6bc364ddf973e height=72 version=0x20000000 log2_work=9.96434087 tx=73 date='2019-09-19 15:51:35' progress=0.000683 cache=0.0MiB(72txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=51a48fc0fcb6d6352096ac6fb4e02c0f5a5014fbd09fce53e6cce0abf2655e05 height=73 version=0x20000000 log2_work=9.98441846 tx=74 date='2019-09-19 15:51:50' progress=0.000692 cache=0.0MiB(73txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=dd79ca11e9f8521931d638629caaf57b1f8406817eff930e097626de9c5ae531 height=74 version=0x20000000 log2_work=9.99152185 tx=75 date='2019-09-19 15:52:05' progress=0.000702 cache=0.0MiB(74txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=6a033ba378c2d2831824396ce815d51ff4193a1d2896829d1e3b5b92cbd8816d height=75 version=0x20000000 log2_work=10.04028972 tx=76 date='2019-09-19 15:52:20' progress=0.000711 cache=0.0MiB(75txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=36d33dc35b375955c52f577178f9450c4b36f91703da6eb3e06887f6d0cb0921 height=76 version=0x20000000 log2_work=10.04575966 tx=77 date='2019-09-19 15:52:35' progress=0.000721 cache=0.0MiB(76txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=e5b7ff0c63bcd278ef62b17d5247b9f111b91037539b335f4eefdee62549a542 height=77 version=0x20000000 log2_work=10.09143539 tx=78 date='2019-09-19 15:52:45' progress=0.000730 cache=0.0MiB(77txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=58d5e1d024470d9e07bd5f51e9c5685c0ca38fba711f1b2ba1f237efc8bd9e76 height=78 version=0x20000000 log2_work=10.09803208 tx=79 date='2019-09-19 15:52:45' progress=0.000739 cache=0.0MiB(78txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=02219965066165abbd3c67c845339b288145a2cca7b43e7ea4d2b70a048df3bd height=79 version=0x20000000 log2_work=10.21674586 tx=80 date='2019-09-19 15:52:45' progress=0.000749 cache=0.0MiB(79txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=9e09baa119a525754e44f6b57981b216e46120f300c7165ea83b4e49ff0b6088 height=80 version=0x20000000 log2_work=10.22279490 tx=81 date='2019-09-19 15:52:46' progress=0.000758 cache=0.0MiB(80txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 14000 fInitialDownload=1
2020-02-25 07:32:41 more getheaders (14000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:42 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 16000 fInitialDownload=1
2020-02-25 07:32:42 more getheaders (16000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:42 Received a POST request for / from 127.0.0.1:50752
2020-02-25 07:32:42 ThreadRPCServer method=mnsync
2020-02-25 07:32:43 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 18000 fInitialDownload=1
2020-02-25 07:32:43 more getheaders (18000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:44 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 20000 fInitialDownload=1
2020-02-25 07:32:44 more getheaders (20000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:44  pushing version 1702received version message: /BiblePay Core:1.5.0.3/: version 70753, blocks=30911, us=45.62.240.90:40001, peer=5
2020-02-25 07:32:44 added time data, samples 3, offset -39 (+0 minutes)
2020-02-25 07:32:45 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 22000 fInitialDownload=1
2020-02-25 07:32:45 more getheaders (22000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:45  pushing version 1702received version message: /BiblePay Core:1.5.0.3/: version 70753, blocks=30947, us=45.62.240.90:40001, peer=7
2020-02-25 07:32:45 added time data, samples 4, offset -52 (+0 minutes)
2020-02-25 07:32:45  pushing version 1702Moving 64.137.171.248:40001 to tried
2020-02-25 07:32:45 received version message: /BiblePay Core:1.5.0.3/: version 70753, blocks=30911, us=45.62.240.90:59934, peer=6
2020-02-25 07:32:46 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 24000 fInitialDownload=1
2020-02-25 07:32:46 more getheaders (24000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:46 SPORK -- hash: a59460fb13eea5a1a6f01e07b7a4ba69d641392f3e22cb8d5cf8e6495cbbfc0e id: 10004 value:   10000000 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 90666fd23a735a86b8f150508b1b20e3e631e0b89de6ced2bde5414531e79a8c id: 10014 value:      17000 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 90666fd23a735a86b8f150508b1b20e3e631e0b89de6ced2bde5414531e79a8c id: 10014 value:      17000 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 0b55391d2c25736279fb64125f046026b833b7021b00cafb296dcd287b72106f id: 10008 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 50c879a0841b5cd3c49346b235c096c885a054e4ac0f8afd0d337732992aee07 id: 10002 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 50c879a0841b5cd3c49346b235c096c885a054e4ac0f8afd0d337732992aee07 id: 10002 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 0cf0f08e13495f654e08b57e5c05673cd1bab7ab7d2198d50802ece16e29ef79 id: 10015 value: 4070908800 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 6525f1c1a122176edaa8299439b580e5dca25b000a501023333f1a2aadcef848 id: 10019 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 6525f1c1a122176edaa8299439b580e5dca25b000a501023333f1a2aadcef848 id: 10019 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 6525f1c1a122176edaa8299439b580e5dca25b000a501023333f1a2aadcef848 id: 10019 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: a59460fb13eea5a1a6f01e07b7a4ba69d641392f3e22cb8d5cf8e6495cbbfc0e id: 10004 value:   10000000 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: a59460fb13eea5a1a6f01e07b7a4ba69d641392f3e22cb8d5cf8e6495cbbfc0e id: 10004 value:   10000000 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 50c879a0841b5cd3c49346b235c096c885a054e4ac0f8afd0d337732992aee07 id: 10002 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 0cf0f08e13495f654e08b57e5c05673cd1bab7ab7d2198d50802ece16e29ef79 id: 10015 value: 4070908800 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 0cf0f08e13495f654e08b57e5c05673cd1bab7ab7d2198d50802ece16e29ef79 id: 10015 value: 4070908800 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 90666fd23a735a86b8f150508b1b20e3e631e0b89de6ced2bde5414531e79a8c id: 10014 value:      17000 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 7d62890f09ccf897835181aa2f5c3ff48813cdebf2c5ecac2e1fe6efbe94008c id: 10011 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 7d62890f09ccf897835181aa2f5c3ff48813cdebf2c5ecac2e1fe6efbe94008c id: 10011 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 7ff45555e5fe6acbc1c19e1bbc002514a45288ee07392803cc9d4c25b8c9641b id: 10005 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 2b4801666c9dcc6a0b7b9fcdd3adf437a03afd3c166449a2195484840f49ac96 id: 10018 value: 4070908800 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 2b4801666c9dcc6a0b7b9fcdd3adf437a03afd3c166449a2195484840f49ac96 id: 10018 value: 4070908800 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 815ca4a6ad852c303d6dba1542db80d9eee0e1e0bc0e315b22d73910b2343bba id: 10090 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 820ec77eb24c149872bcf49391234e10d1c16f1602b238a6661bf7a8171acc53 id: 10016 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 820ec77eb24c149872bcf49391234e10d1c16f1602b238a6661bf7a8171acc53 id: 10016 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 2b4801666c9dcc6a0b7b9fcdd3adf437a03afd3c166449a2195484840f49ac96 id: 10018 value: 4070908800 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 815ca4a6ad852c303d6dba1542db80d9eee0e1e0bc0e315b22d73910b2343bba id: 10090 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 815ca4a6ad852c303d6dba1542db80d9eee0e1e0bc0e315b22d73910b2343bba id: 10090 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 7d62890f09ccf897835181aa2f5c3ff48813cdebf2c5ecac2e1fe6efbe94008c id: 10011 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 7ff45555e5fe6acbc1c19e1bbc002514a45288ee07392803cc9d4c25b8c9641b id: 10005 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 7ff45555e5fe6acbc1c19e1bbc002514a45288ee07392803cc9d4c25b8c9641b id: 10005 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 820ec77eb24c149872bcf49391234e10d1c16f1602b238a6661bf7a8171acc53 id: 10016 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 0b55391d2c25736279fb64125f046026b833b7021b00cafb296dcd287b72106f id: 10008 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 0b55391d2c25736279fb64125f046026b833b7021b00cafb296dcd287b72106f id: 10008 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:47 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 26000 fInitialDownload=1
2020-02-25 07:32:47 more getheaders (26000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:47 Received a POST request for / from 127.0.0.1:50758
2020-02-25 07:32:47 ThreadRPCServer method=mnsync
2020-02-25 07:32:48 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 28000 fInitialDownload=1
2020-02-25 07:32:48 more getheaders (28000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:49 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 30000 fInitialDownload=1
2020-02-25 07:32:49 more getheaders (30000) to end to peer=3 (startheight:30947)

8. The biblepayd appears to exit

9. Control experiment, reload wallet in old account again and sync, to show we didn't mess up the OS.

Code: [Select]
> cli getblockhash 30948
26c0a305f665d85d11de7e13618012e3a5fad037400e7f70f5490b6b0c9c9e97

>cli getblockhash 30939
19a3bdb654b0f7ebc7b7bd64fde3d44d7abc94564ab21b161664025e084d71b9


Findings
Compiling from source under the old user account works fine on the server. However, using the binaries in a newly created user account gives the above errors and the wallet cannot be loaded.



Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 25, 2020, 10:47:11 AM
This is the experiment and results:

1. Use an existing server running a 1.5.0.3 wallet (compiled from source) which can sync to the top (shows hardware and OS is fine).
Code: [Select]
>uname -a
Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
(Ubuntu 18.04 upgraded from 16.04)

>lscpu
...
Model name:          Intel(R) Xeon(R) CPU           X7560  @ 2.27GHz x 4 vCPU
...
>cli getblockhash 30939
19a3bdb654b0f7ebc7b7bd64fde3d44d7abc94564ab21b161664025e084d71b9

2. stop biblepayd on old account
3. download binaries in the new user account (newly created) in separate directory

Code: [Select]
wget https://biblepay.org/biblepayd-evo-testnet-x86_64-pc-linux-gnu.tar.gz

Hash of the downloaded file
93c1a6cdbc8b1b546fe13d782cdd14014cb6c7999897ec8e91b94823002b962d

tar -xvf biblepayd-evo-testnet-x86_64-pc-linux-gnu.tar.gz
chmod +x  biblepay*

4. cli -version (to confirm deployment of binaries)

Code: [Select]
BiblePay Core RPC client version 1.5.0.3

4. biblepaytest.conf with

Code: [Select]
addnode=testnet.biblepay.org
addnode=dns1.biblepay.org
addnode=dns3.biblepay.org

rpcuser=x
rpcpassword=x
rpcallowip=127.0.0.1
daemon=1
testnet=1
debug=1

5. start biblepayd (it creates new testnet3 directory and copy of the blockchain)
6. it creates a fresh wallet so no chance of bad blocks etc
7. Errors:
Code: [Select]
error code: -28
error message:
Loading PODC Researchers
...
Loading wallet... (97.3 %)
....
error: couldn't connect to server: unknown (code -1)
(make sure server is running and you are connecting to the correct RPC port)

8. ..debug.log file output around the time of biblepayd exit

Code: [Select]
2020-02-25 07:32:17 Received a POST request for / from 127.0.0.1:50724
2020-02-25 07:32:17 ThreadRPCServer method=mnsync
2020-02-25 07:32:22 Received a POST request for / from 127.0.0.1:50730
2020-02-25 07:32:22 ThreadRPCServer method=mnsync
2020-02-25 07:32:27 Received a POST request for / from 127.0.0.1:50732
2020-02-25 07:32:27 ThreadRPCServer method=mnsync
2020-02-25 07:32:28 peer=2 using obsolete version 70216; disconnecting
2020-02-25 07:32:32 Received a POST request for / from 127.0.0.1:50744
2020-02-25 07:32:32 ThreadRPCServer method=mnsync
2020-02-25 07:32:35  pushing version 1702received version message: /BiblePay Core:1.5.0.3/: version 70753, blocks=30947, us=45.62.240.90:40001, peer=3
2020-02-25 07:32:35 debug turned on:
2020-02-25 07:32:35   thread biblepay-msghan category 1
2020-02-25 07:32:35 added time data, samples 2, offset -51 (+0 minutes)
2020-02-25 07:32:36 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 2000 fInitialDownload=1
2020-02-25 07:32:36 more getheaders (2000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:37 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 4000 fInitialDownload=1
2020-02-25 07:32:37 more getheaders (4000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:37 ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 Pre-allocating up to position 0x100000 in rev00000.dat
2020-02-25 07:32:37 UpdateTip: new best=9c223ac553eac067ad9cc119adf40e470e2eb950408775d2c3b6096010d41528 height=1 version=0x20000000 log2_work=2.00000000 tx=2 date='2019-09-19 15:33:01' progress=0.000019 cache=0.0MiB(1txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=238af87743f4d3b9f4c9169fb4ab985517785264b4d23e137643c84306e180a8 height=2 version=0x20000000 log2_work=2.58496250 tx=3 date='2019-09-19 15:33:16' progress=0.000028 cache=0.0MiB(2txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=2b6ee76068025deb173c6e8be0f414b160b3c938b37f56ef37b7b1564c84a09d height=3 version=0x20000000 log2_work=3.00000000 tx=4 date='2019-09-19 15:33:31' progress=0.000037 cache=0.0MiB(3txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=39cc5ad4f5a201cfd266c6a13fc6a8822fd7b971ae881a17b0ca32aab97277be height=4 version=0x20000000 log2_work=3.32192809 tx=5 date='2019-09-19 15:33:46' progress=0.000047 cache=0.0MiB(4txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=b19d93b185162c891d2582024abe93e6e8e87ffa9e6a9d22e88220d5f24853d5 height=5 version=0x20000000 log2_work=3.90689060 tx=6 date='2019-09-19 15:34:01' progress=0.000056 cache=0.0MiB(5txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=0bfe393a24953d7739d3a9da70c2074cb45c3e9a7161d65157a8d9d72d02893b height=6 version=0x20000000 log2_work=4.58496250 tx=7 date='2019-09-19 15:34:16' progress=0.000066 cache=0.0MiB(6txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=a4c3024fbb6090607413b6e06854b5a4991d7ce91d1f4891002f187603f3ae33 height=7 version=0x20000000 log2_work=4.85798100 tx=8 date='2019-09-19 15:34:31' progress=0.000075 cache=0.0MiB(7txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=126ad2068e4e77b671ce614779b9591fb2be5f14e21a42cacb0c00e28e38ff9e height=8 version=0x20000000 log2_work=5.52356196 tx=9 date='2019-09-19 15:34:46' progress=0.000084 cache=0.0MiB(8txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=169b7e142aa235a788f369ab89c6f3b0686bcf772b145645c337fa8d7b745d41 height=9 version=0x20000000 log2_work=5.64385619 tx=10 date='2019-09-19 15:35:01' progress=0.000094 cache=0.0MiB(9txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=1c75deb60d1cd8fdebe33259a60ee4baf98f7ea1dc78f14d59a5dcd4a855fc3c height=10 version=0x20000000 log2_work=5.97727992 tx=11 date='2019-09-19 15:35:16' progress=0.000103 cache=0.0MiB(10txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=b9432e382586d661ba8788a2987f7a02a2801597e632826480ee997baa6ff28f height=11 version=0x20000000 log2_work=6.06608919 tx=12 date='2019-09-19 15:35:31' progress=0.000112 cache=0.0MiB(11txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=6a95a72b12f328d734bb0c1f96db5f6a208ec1b277b7d63a62d4a8cf246b5f53 height=12 version=0x20000000 log2_work=6.26678654 tx=13 date='2019-09-19 15:35:46' progress=0.000122 cache=0.0MiB(12txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=544141fe4185dd6564f999fec8888d8706e0add70807da218da0a0639317e60c height=13 version=0x20000000 log2_work=6.59991284 tx=14 date='2019-09-19 15:36:01' progress=0.000131 cache=0.0MiB(13txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=2d2ab820680ce697c6a27c2822f1f96c6279aeb0b8d0197a69a48a925c5b9028 height=14 version=0x20000000 log2_work=6.65821148 tx=15 date='2019-09-19 15:36:16' progress=0.000140 cache=0.0MiB(14txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=1a3235f8c697a63257c0256323cd5826f69cbb72d3c52bf3ab924cc32af6fde9 height=15 version=0x20000000 log2_work=6.84549005 tx=16 date='2019-09-19 15:36:31' progress=0.000150 cache=0.0MiB(15txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=d89053eead9f9cf2019c87de1be982cf10c2b2b25be65bb77ccbb5cf60da8dd1 height=16 version=0x20000000 log2_work=6.90689060 tx=17 date='2019-09-19 15:36:46' progress=0.000159 cache=0.0MiB(16txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  Received a POST request for / from 127.0.0.1:50748
2020-02-25 07:32:37 ThreadRPCServer method=mnsync
2020-02-25 07:32:38 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 6000 fInitialDownload=1
2020-02-25 07:32:38 more getheaders (6000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:38 ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=7146495d05421dd4d7119cf57c297e22458d6b624e1045c25c9a3c487ef6f9d8 height=17 version=0x20000000 log2_work=7.18982456 tx=18 date='2019-09-19 15:37:01' progress=0.000168 cache=0.0MiB(17txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=ee115f49afd3ceed1f9ea5f9022b9037daecd4ccfb1675a537db0d20cc319f84 height=18 version=0x20000000 log2_work=7.22881869 tx=19 date='2019-09-19 15:37:16' progress=0.000178 cache=0.0MiB(18txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=8b01c2d73109efc42d3b26df74ebb4b6f47bad592023fd2cbcdc65b1861a71ae height=19 version=0x20000000 log2_work=7.41785251 tx=20 date='2019-09-19 15:37:31' progress=0.000187 cache=0.0MiB(19txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=d3b7cfe27ef18576767c381a2b54815bc478370a76296f797d71ae36bf03cc62 height=20 version=0x20000000 log2_work=7.45121111 tx=21 date='2019-09-19 15:37:46' progress=0.000197 cache=0.0MiB(20txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=058b0d5d41589e36cb7374aba076d3c210e0ceee8b3eb9b5640430f491771c58 height=21 version=0x20000000 log2_work=7.61470984 tx=22 date='2019-09-19 15:38:01' progress=0.000206 cache=0.0MiB(21txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=802d2463b3bdaecc5fe815892db95ce4a3b1825290d41d76d39fb831dfca79e6 height=22 version=0x20000000 log2_work=7.64385619 tx=23 date='2019-09-19 15:38:16' progress=0.000215 cache=0.0MiB(22txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=9953e73de4d29a101bfcfd74c2a7042c2d5ec5877902ffa2801defbb3f7b4eb1 height=23 version=0x20000000 log2_work=7.75488750 tx=24 date='2019-09-19 15:38:31' progress=0.000225 cache=0.0MiB(23txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=d85ed38301f90a5681ac93d588d9bde375f495f2e72d5cbdfa6bd0cd1c8ca7ed height=24 version=0x20000000 log2_work=7.78135971 tx=25 date='2019-09-19 15:38:46' progress=0.000234 cache=0.0MiB(24txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=0d33f97d3ddc85477973e1ece454f059d899f99a53e2aca8225f373c0397cd86 height=25 version=0x20000000 log2_work=7.85798100 tx=26 date='2019-09-19 15:39:49' progress=0.000243 cache=0.0MiB(25txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=644f05f9a7d3e5601f79408f058a9b28bda146a4eadd628e113761683db80f5c height=26 version=0x20000000 log2_work=8.03891899 tx=27 date='2019-09-19 15:40:04' progress=0.000253 cache=0.0MiB(26txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=0b59e12acb0fe81a37dbcc1e81d71729276f395780a6d9c6b940623f4375caf4 height=27 version=0x20000000 log2_work=8.06608919 tx=28 date='2019-09-19 15:40:19' progress=0.000262 cache=0.0MiB(27txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=58d8a70a891a0bd3183baf0d75a73978b4f20a6a2d4530f5d4c4bce63790d99b height=28 version=0x20000000 log2_work=8.19475685 tx=29 date='2019-09-19 15:40:34' progress=0.000271 cache=0.0MiB(28txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=22a0fe6b3f80fb41bfeb221c53fbc1ff04505f7792128e38f15919fd022c3a20 height=29 version=0x20000000 log2_work=8.22400167 tx=30 date='2019-09-19 15:40:49' progress=0.000281 cache=0.0MiB(29txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=2b7bc612b2cb69c9105cab95a5138381d153d99ee0fda9778f5287df58a88797 height=30 version=0x20000000 log2_work=8.24317398 tx=31 date='2019-09-19 15:41:04' progress=0.000290 cache=0.0MiB(30txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=94c551030dcee5fa52fc418f1e8a273eb94e925450c84602c8bf38e98789b41a height=31 version=0x20000000 log2_work=8.30378075 tx=32 date='2019-09-19 15:41:19' progress=0.000299 cache=0.0MiB(31txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=fb4706c120c646c23cb7e4c9ee9e1e1781e1d8f71cbcd2f17bbedc8124ad1848 height=32 version=0x20000000 log2_work=8.32192809 tx=33 date='2019-09-19 15:41:34' progress=0.000309 cache=0.0MiB(32txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 8000 fInitialDownload=1
2020-02-25 07:32:39 more getheaders (8000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:39 ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=91e4e1c6076bfb9d03bf1f549d642bc254426c71e8d15c152aab3f77fd72bafa height=33 version=0x20000000 log2_work=8.36194377 tx=34 date='2019-09-19 15:41:49' progress=0.000318 cache=0.0MiB(33txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=7f0fb4ad6eb15674d507e0a92c3c54004df3530fe11d746f4a25dd2200f6f458 height=34 version=0x20000000 log2_work=8.45121111 tx=35 date='2019-09-19 15:42:04' progress=0.000328 cache=0.0MiB(34txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=7b81729377d3ba308318c10279f3eaf96f6db68837d82d5f2c3467c915278793 height=35 version=0x20000000 log2_work=8.46760555 tx=36 date='2019-09-19 15:42:19' progress=0.000337 cache=0.0MiB(35txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=a924bfa21d5f4163399587997b1fe54682c65e7281889529ec03f75e2ab1d419 height=36 version=0x20000000 log2_work=8.52747701 tx=37 date='2019-09-19 15:42:34' progress=0.000346 cache=0.0MiB(36txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=2e58b956975d2cb2f80fbe9d25791ad9e38cf6142953a363937a7a23fd51be69 height=37 version=0x20000000 log2_work=8.54689446 tx=38 date='2019-09-19 15:42:49' progress=0.000356 cache=0.0MiB(37txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=c27b3aa43aa465b77f4b5b34d7c74bc3d19ff03ea0cac74dbfa2fd9582e51fdd height=38 version=0x20000000 log2_work=8.66888498 tx=39 date='2019-09-19 15:43:04' progress=0.000365 cache=0.0MiB(38txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=b46840fbe5e9ef46c8ddb7bdc9e25b50493c77550cff19e6ef4b8b317ac829f3 height=39 version=0x20000000 log2_work=8.68299458 tx=40 date='2019-09-19 15:43:19' progress=0.000374 cache=0.0MiB(39txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=334aa28219438ad386a7a4e87eb2f633cce4ced15e5cc18e9828b4eabe32b6c6 height=40 version=0x20000000 log2_work=8.79116289 tx=41 date='2019-09-19 15:43:34' progress=0.000384 cache=0.0MiB(40txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=da4f541fd413398cccce5f6d9e0dbc644f9b17a051f465740fc8484a2b7ce7b9 height=41 version=0x20000000 log2_work=8.80735492 tx=42 date='2019-09-19 15:43:49' progress=0.000393 cache=0.0MiB(41txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=cbbc7e3fd74891f2e816535c0679fde81858ceff2ae9fb5bd5d17af78c44e4f8 height=42 version=0x20000000 log2_work=9.00842862 tx=43 date='2019-09-19 15:44:04' progress=0.000402 cache=0.0MiB(42txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=3b9ac1a20a201b282e88f6d1d87ab51efb6898ebe2d9ac5d45f78dd5007ebcfb height=43 version=0x20000000 log2_work=9.02236781 tx=44 date='2019-09-19 15:44:19' progress=0.000412 cache=0.0MiB(43txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=ab9a2d23f7ea54bb9b52c5c9216ff9b9d5af70abcfa1debc0900d621c50f2850 height=44 version=0x20000000 log2_work=9.03342300 tx=45 date='2019-09-19 15:44:34' progress=0.000421 cache=0.0MiB(44txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=8120a9b85934314afa09de38bd4426e1f409cdf2b51fa1e8730ee77c224d8ee4 height=45 version=0x20000000 log2_work=9.05799172 tx=46 date='2019-09-19 15:44:49' progress=0.000430 cache=0.0MiB(45txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=aa3fffe227186ba2f8708a8e2566a8fa0b8aef5476ab0e8154a4461b9c12dc47 height=46 version=0x20000000 log2_work=9.24555271 tx=47 date='2019-09-19 15:45:04' progress=0.000440 cache=0.0MiB(46txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=698e25b95048d926c45f2dc841d58cfd74163a04a7735fa8b2a7eefc61ef5916 height=47 version=0x20000000 log2_work=9.25502857 tx=48 date='2019-09-19 15:45:19' progress=0.000449 cache=0.0MiB(47txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=2e6124234f988fdcfcece29a79905eea6784ada8f8442094a3ef91bdcbf6b50b height=48 version=0x20000000 log2_work=9.28540222 tx=49 date='2019-09-19 15:45:34' progress=0.000459 cache=0.0MiB(48txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 10000 fInitialDownload=1
2020-02-25 07:32:39 more getheaders (10000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:39 ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=241b8591f93464cff00c25db841f900fb01d7642013161425bf817c84fff8479 height=49 version=0x20000000 log2_work=9.29691621 tx=50 date='2019-09-19 15:45:49' progress=0.000468 cache=0.0MiB(49txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=6aa1e8b38ea074e8133339deafb7b0d83e4565e2b37169b47aa3f0fb9fb394d9 height=50 version=0x20000000 log2_work=9.35755200 tx=51 date='2019-09-19 15:46:04' progress=0.000477 cache=0.0MiB(50txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=6057db921f2482de6c9dcddc00af4e46804de1b1501a37418fcc6cbe8d5b5a18 height=51 version=0x20000000 log2_work=9.36632221 tx=52 date='2019-09-19 15:46:19' progress=0.000487 cache=0.0MiB(51txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=dc0df33264aa68c778af06ba6f24d549f8f17046e1eaa8e019f997d5d1e14dea height=52 version=0x20000000 log2_work=9.40087944 tx=53 date='2019-09-19 15:46:34' progress=0.000496 cache=0.0MiB(52txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=8f10cec7dc3515c52ba90a612e4c82d440cbd4a99a2ab443b74a7c1be51ee90e height=53 version=0x20000000 log2_work=9.40939094 tx=54 date='2019-09-19 15:46:49' progress=0.000505 cache=0.0MiB(53txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=23cdaa4ea1065033b4c743a61fb04fb8653c21d3a39bc7e96b84ab9334aa43f9 height=54 version=0x20000000 log2_work=9.43879185 tx=55 date='2019-09-19 15:47:04' progress=0.000515 cache=0.0MiB(54txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=72ce7c4f1bf8b41c9b057da94204d929af35ee6756c7e14e1c9706c2d7c48ad6 height=55 version=0x20000000 log2_work=9.59432460 tx=56 date='2019-09-19 15:47:19' progress=0.000524 cache=0.0MiB(55txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=341c4a6f8608d9e50776f795bee87de579aee661ce208946f7c3584389b927ce height=56 version=0x20000000 log2_work=9.60547952 tx=57 date='2019-09-19 15:47:34' progress=0.000533 cache=0.0MiB(56txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=15a315723556907044d8507786644576e4b670bb44696ca017967716298ed8d7 height=57 version=0x20000000 log2_work=9.61286850 tx=58 date='2019-09-19 15:47:49' progress=0.000543 cache=0.0MiB(57txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=544ef623886523e18ef22ce0e511ac9401e6ca779c30066f077c0b66a4015b89 height=58 version=0x20000000 log2_work=9.65463603 tx=59 date='2019-09-19 15:48:04' progress=0.000552 cache=0.0MiB(58txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=54025bb678c76a60009db817ef24632494fa19d38f2b4230da8a5a71f6346662 height=59 version=0x20000000 log2_work=9.66355810 tx=60 date='2019-09-19 15:48:19' progress=0.000561 cache=0.0MiB(59txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=042d11e87e46385b06014051f584211ac8fc5fe3abbc301fa02a9fa535440424 height=60 version=0x20000000 log2_work=9.68299458 tx=61 date='2019-09-19 15:48:34' progress=0.000571 cache=0.0MiB(60txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=8b209285a11fab86daf23dc119c086563d6cc57e0899e5271b270c94bf0cb32a height=61 version=0x20000000 log2_work=9.78953364 tx=62 date='2019-09-19 15:48:49' progress=0.000580 cache=0.0MiB(61txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=4556e43581acae7ef87acacd32d37b2e93bdf443f39aeaa3f5e82794fcf1cc29 height=62 version=0x20000000 log2_work=9.79928162 tx=63 date='2019-09-19 15:49:04' progress=0.000590 cache=0.0MiB(62txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=1d1128eed7a0061ebe4e868f7be6c67282eaf86c9d53f79acb4eb74d10712c0b height=63 version=0x20000000 log2_work=9.80574387 tx=64 date='2019-09-19 15:49:19' progress=0.000599 cache=0.0MiB(63txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=a6258371135e84756876859543bb54abe79cf51a2adf2ce702fd8d5b78dcd5cf height=64 version=0x20000000 log2_work=9.84705735 tx=65 date='2019-09-19 15:49:34' progress=0.000608 cache=0.0MiB(64txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  SPORK -- hash: a59460fb13eea5a1a6f01e07b7a4ba69d641392f3e22cb8d5cf8e6495cbbfc0e id: 10004 value:   10000000 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 0b55391d2c25736279fb64125f046026b833b7021b00cafb296dcd287b72106f id: 10008 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 0cf0f08e13495f654e08b57e5c05673cd1bab7ab7d2198d50802ece16e29ef79 id: 10015 value: 4070908800 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 6525f1c1a122176edaa8299439b580e5dca25b000a501023333f1a2aadcef848 id: 10019 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 50c879a0841b5cd3c49346b235c096c885a054e4ac0f8afd0d337732992aee07 id: 10002 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 90666fd23a735a86b8f150508b1b20e3e631e0b89de6ced2bde5414531e79a8c id: 10014 value:      17000 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 7ff45555e5fe6acbc1c19e1bbc002514a45288ee07392803cc9d4c25b8c9641b id: 10005 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 815ca4a6ad852c303d6dba1542db80d9eee0e1e0bc0e315b22d73910b2343bba id: 10090 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 2b4801666c9dcc6a0b7b9fcdd3adf437a03afd3c166449a2195484840f49ac96 id: 10018 value: 4070908800 bestHeight: 64 peer=3 new
2020-02-25 07:32:39  pushing version 1702Moving 149.28.125.16:40001 to tried
2020-02-25 07:32:39 received version message: /BiblePay Core:1.5.0.3/: version 70753, blocks=30947, us=45.62.240.90:53846, peer=4
2020-02-25 07:32:39 SPORK -- hash: 7d62890f09ccf897835181aa2f5c3ff48813cdebf2c5ecac2e1fe6efbe94008c id: 10011 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 820ec77eb24c149872bcf49391234e10d1c16f1602b238a6661bf7a8171acc53 id: 10016 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:40 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 12000 fInitialDownload=1
2020-02-25 07:32:40 more getheaders (12000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:40 ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=196adb6b953dced2c60d200f1a59cbb93b3aa8879eb5f3027e19abdc62504bc3 height=65 version=0x20000000 log2_work=9.85486838 tx=66 date='2019-09-19 15:49:49' progress=0.000618 cache=0.0MiB(65txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=74379e8f191f45b64896d68d5e8b8be33fef82850b20d787c5401810a85e2a7f height=66 version=0x20000000 log2_work=9.87651695 tx=67 date='2019-09-19 15:50:05' progress=0.000627 cache=0.0MiB(66txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=675d263f69868db421cf65a289ff214c48db48cb192f05f65a380d3c9f0e0bca height=67 version=0x20000000 log2_work=9.88264305 tx=68 date='2019-09-19 15:50:20' progress=0.000636 cache=0.0MiB(67txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=4fd3c136076767986a0a02d874c3618191c86ae51b5cd1ac53625b4cc1e1995a height=68 version=0x20000000 log2_work=9.90689060 tx=69 date='2019-09-19 15:50:35' progress=0.000646 cache=0.0MiB(68txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=79d80617c48debe332ef73294fd8316d99d9001482b0178b580208f0de375362 height=69 version=0x20000000 log2_work=9.91288934 tx=70 date='2019-09-19 15:50:50' progress=0.000655 cache=0.0MiB(69txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=77c4a20d1d6f574278ae4d101eecf5b8ca31378769b46f663fc21291f8f6e272 height=70 version=0x20000000 log2_work=9.92777796 tx=71 date='2019-09-19 15:51:05' progress=0.000664 cache=0.0MiB(70txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=339c93cc309b3289c61038a534bbcc15f5f8a68fd3d90d0ddbe1bac65cfd2fae height=71 version=0x20000000 log2_work=9.95855272 tx=72 date='2019-09-19 15:51:20' progress=0.000674 cache=0.0MiB(71txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=6db29ae6ee8e1756b53ae3af09043955f8016a8265c910c739f6bc364ddf973e height=72 version=0x20000000 log2_work=9.96434087 tx=73 date='2019-09-19 15:51:35' progress=0.000683 cache=0.0MiB(72txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=51a48fc0fcb6d6352096ac6fb4e02c0f5a5014fbd09fce53e6cce0abf2655e05 height=73 version=0x20000000 log2_work=9.98441846 tx=74 date='2019-09-19 15:51:50' progress=0.000692 cache=0.0MiB(73txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=dd79ca11e9f8521931d638629caaf57b1f8406817eff930e097626de9c5ae531 height=74 version=0x20000000 log2_work=9.99152185 tx=75 date='2019-09-19 15:52:05' progress=0.000702 cache=0.0MiB(74txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=6a033ba378c2d2831824396ce815d51ff4193a1d2896829d1e3b5b92cbd8816d height=75 version=0x20000000 log2_work=10.04028972 tx=76 date='2019-09-19 15:52:20' progress=0.000711 cache=0.0MiB(75txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=36d33dc35b375955c52f577178f9450c4b36f91703da6eb3e06887f6d0cb0921 height=76 version=0x20000000 log2_work=10.04575966 tx=77 date='2019-09-19 15:52:35' progress=0.000721 cache=0.0MiB(76txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=e5b7ff0c63bcd278ef62b17d5247b9f111b91037539b335f4eefdee62549a542 height=77 version=0x20000000 log2_work=10.09143539 tx=78 date='2019-09-19 15:52:45' progress=0.000730 cache=0.0MiB(77txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=58d5e1d024470d9e07bd5f51e9c5685c0ca38fba711f1b2ba1f237efc8bd9e76 height=78 version=0x20000000 log2_work=10.09803208 tx=79 date='2019-09-19 15:52:45' progress=0.000739 cache=0.0MiB(78txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=02219965066165abbd3c67c845339b288145a2cca7b43e7ea4d2b70a048df3bd height=79 version=0x20000000 log2_work=10.21674586 tx=80 date='2019-09-19 15:52:45' progress=0.000749 cache=0.0MiB(79txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=9e09baa119a525754e44f6b57981b216e46120f300c7165ea83b4e49ff0b6088 height=80 version=0x20000000 log2_work=10.22279490 tx=81 date='2019-09-19 15:52:46' progress=0.000758 cache=0.0MiB(80txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 14000 fInitialDownload=1
2020-02-25 07:32:41 more getheaders (14000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:42 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 16000 fInitialDownload=1
2020-02-25 07:32:42 more getheaders (16000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:42 Received a POST request for / from 127.0.0.1:50752
2020-02-25 07:32:42 ThreadRPCServer method=mnsync
2020-02-25 07:32:43 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 18000 fInitialDownload=1
2020-02-25 07:32:43 more getheaders (18000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:44 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 20000 fInitialDownload=1
2020-02-25 07:32:44 more getheaders (20000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:44  pushing version 1702received version message: /BiblePay Core:1.5.0.3/: version 70753, blocks=30911, us=45.62.240.90:40001, peer=5
2020-02-25 07:32:44 added time data, samples 3, offset -39 (+0 minutes)
2020-02-25 07:32:45 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 22000 fInitialDownload=1
2020-02-25 07:32:45 more getheaders (22000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:45  pushing version 1702received version message: /BiblePay Core:1.5.0.3/: version 70753, blocks=30947, us=45.62.240.90:40001, peer=7
2020-02-25 07:32:45 added time data, samples 4, offset -52 (+0 minutes)
2020-02-25 07:32:45  pushing version 1702Moving 64.137.171.248:40001 to tried
2020-02-25 07:32:45 received version message: /BiblePay Core:1.5.0.3/: version 70753, blocks=30911, us=45.62.240.90:59934, peer=6
2020-02-25 07:32:46 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 24000 fInitialDownload=1
2020-02-25 07:32:46 more getheaders (24000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:46 SPORK -- hash: a59460fb13eea5a1a6f01e07b7a4ba69d641392f3e22cb8d5cf8e6495cbbfc0e id: 10004 value:   10000000 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 90666fd23a735a86b8f150508b1b20e3e631e0b89de6ced2bde5414531e79a8c id: 10014 value:      17000 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 90666fd23a735a86b8f150508b1b20e3e631e0b89de6ced2bde5414531e79a8c id: 10014 value:      17000 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 0b55391d2c25736279fb64125f046026b833b7021b00cafb296dcd287b72106f id: 10008 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 50c879a0841b5cd3c49346b235c096c885a054e4ac0f8afd0d337732992aee07 id: 10002 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 50c879a0841b5cd3c49346b235c096c885a054e4ac0f8afd0d337732992aee07 id: 10002 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 0cf0f08e13495f654e08b57e5c05673cd1bab7ab7d2198d50802ece16e29ef79 id: 10015 value: 4070908800 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 6525f1c1a122176edaa8299439b580e5dca25b000a501023333f1a2aadcef848 id: 10019 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 6525f1c1a122176edaa8299439b580e5dca25b000a501023333f1a2aadcef848 id: 10019 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 6525f1c1a122176edaa8299439b580e5dca25b000a501023333f1a2aadcef848 id: 10019 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: a59460fb13eea5a1a6f01e07b7a4ba69d641392f3e22cb8d5cf8e6495cbbfc0e id: 10004 value:   10000000 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: a59460fb13eea5a1a6f01e07b7a4ba69d641392f3e22cb8d5cf8e6495cbbfc0e id: 10004 value:   10000000 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 50c879a0841b5cd3c49346b235c096c885a054e4ac0f8afd0d337732992aee07 id: 10002 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 0cf0f08e13495f654e08b57e5c05673cd1bab7ab7d2198d50802ece16e29ef79 id: 10015 value: 4070908800 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 0cf0f08e13495f654e08b57e5c05673cd1bab7ab7d2198d50802ece16e29ef79 id: 10015 value: 4070908800 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 90666fd23a735a86b8f150508b1b20e3e631e0b89de6ced2bde5414531e79a8c id: 10014 value:      17000 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 7d62890f09ccf897835181aa2f5c3ff48813cdebf2c5ecac2e1fe6efbe94008c id: 10011 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 7d62890f09ccf897835181aa2f5c3ff48813cdebf2c5ecac2e1fe6efbe94008c id: 10011 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 7ff45555e5fe6acbc1c19e1bbc002514a45288ee07392803cc9d4c25b8c9641b id: 10005 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 2b4801666c9dcc6a0b7b9fcdd3adf437a03afd3c166449a2195484840f49ac96 id: 10018 value: 4070908800 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 2b4801666c9dcc6a0b7b9fcdd3adf437a03afd3c166449a2195484840f49ac96 id: 10018 value: 4070908800 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 815ca4a6ad852c303d6dba1542db80d9eee0e1e0bc0e315b22d73910b2343bba id: 10090 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 820ec77eb24c149872bcf49391234e10d1c16f1602b238a6661bf7a8171acc53 id: 10016 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 820ec77eb24c149872bcf49391234e10d1c16f1602b238a6661bf7a8171acc53 id: 10016 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 2b4801666c9dcc6a0b7b9fcdd3adf437a03afd3c166449a2195484840f49ac96 id: 10018 value: 4070908800 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 815ca4a6ad852c303d6dba1542db80d9eee0e1e0bc0e315b22d73910b2343bba id: 10090 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 815ca4a6ad852c303d6dba1542db80d9eee0e1e0bc0e315b22d73910b2343bba id: 10090 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 7d62890f09ccf897835181aa2f5c3ff48813cdebf2c5ecac2e1fe6efbe94008c id: 10011 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 7ff45555e5fe6acbc1c19e1bbc002514a45288ee07392803cc9d4c25b8c9641b id: 10005 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 7ff45555e5fe6acbc1c19e1bbc002514a45288ee07392803cc9d4c25b8c9641b id: 10005 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 820ec77eb24c149872bcf49391234e10d1c16f1602b238a6661bf7a8171acc53 id: 10016 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 0b55391d2c25736279fb64125f046026b833b7021b00cafb296dcd287b72106f id: 10008 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 0b55391d2c25736279fb64125f046026b833b7021b00cafb296dcd287b72106f id: 10008 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:47 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 26000 fInitialDownload=1
2020-02-25 07:32:47 more getheaders (26000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:47 Received a POST request for / from 127.0.0.1:50758
2020-02-25 07:32:47 ThreadRPCServer method=mnsync
2020-02-25 07:32:48 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 28000 fInitialDownload=1
2020-02-25 07:32:48 more getheaders (28000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:49 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 30000 fInitialDownload=1
2020-02-25 07:32:49 more getheaders (30000) to end to peer=3 (startheight:30947)

8. The biblepayd appears to exit

9. Control experiment, reload wallet in old account again and sync, to show we didn't mess up the OS.

Code: [Select]
> cli getblockhash 30948
26c0a305f665d85d11de7e13618012e3a5fad037400e7f70f5490b6b0c9c9e97

>cli getblockhash 30939
19a3bdb654b0f7ebc7b7bd64fde3d44d7abc94564ab21b161664025e084d71b9


Findings
Compiling from source under the old user account works fine on the server. However, using the binaries in a newly created user account gives the above errors and the wallet cannot be loaded.

Thank you sir, so it appears the 1.5.0.3 compiled binary cant sync past block 30,000... Interesting.

Ok, let me try to release a separate compile and Ill test it on one of my vms now.

Btw, I did an expiriment last night (tried to enable chainlocks in testnet) and I found that the chain immediately tried to fork - I see that not only do the supermajority of good sancs need to be enabled in testnet,  but we also need to have a quorum already in place and succeeding.  So therefore I am decommissioning all my old sancs first to get them off the network.  Im recreating my sancs now.

Ill get back to you asap.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 25, 2020, 11:22:10 AM
This is the experiment and results:

1. Use an existing server running a 1.5.0.3 wallet (compiled from source) which can sync to the top (shows hardware and OS is fine).
Code: [Select]
>uname -a
Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
(Ubuntu 18.04 upgraded from 16.04)

>lscpu
...
Model name:          Intel(R) Xeon(R) CPU           X7560  @ 2.27GHz x 4 vCPU
...
>cli getblockhash 30939
19a3bdb654b0f7ebc7b7bd64fde3d44d7abc94564ab21b161664025e084d71b9

2. stop biblepayd on old account
3. download binaries in the new user account (newly created) in separate directory

Code: [Select]
wget https://biblepay.org/biblepayd-evo-testnet-x86_64-pc-linux-gnu.tar.gz

Hash of the downloaded file
93c1a6cdbc8b1b546fe13d782cdd14014cb6c7999897ec8e91b94823002b962d

tar -xvf biblepayd-evo-testnet-x86_64-pc-linux-gnu.tar.gz
chmod +x  biblepay*

4. cli -version (to confirm deployment of binaries)

Code: [Select]
BiblePay Core RPC client version 1.5.0.3

4. biblepaytest.conf with

Code: [Select]
addnode=testnet.biblepay.org
addnode=dns1.biblepay.org
addnode=dns3.biblepay.org

rpcuser=x
rpcpassword=x
rpcallowip=127.0.0.1
daemon=1
testnet=1
debug=1

5. start biblepayd (it creates new testnet3 directory and copy of the blockchain)
6. it creates a fresh wallet so no chance of bad blocks etc
7. Errors:
Code: [Select]
error code: -28
error message:
Loading PODC Researchers
...
Loading wallet... (97.3 %)
....
error: couldn't connect to server: unknown (code -1)
(make sure server is running and you are connecting to the correct RPC port)

8. ..debug.log file output around the time of biblepayd exit

Code: [Select]
2020-02-25 07:32:17 Received a POST request for / from 127.0.0.1:50724
2020-02-25 07:32:17 ThreadRPCServer method=mnsync
2020-02-25 07:32:22 Received a POST request for / from 127.0.0.1:50730
2020-02-25 07:32:22 ThreadRPCServer method=mnsync
2020-02-25 07:32:27 Received a POST request for / from 127.0.0.1:50732
2020-02-25 07:32:27 ThreadRPCServer method=mnsync
2020-02-25 07:32:28 peer=2 using obsolete version 70216; disconnecting
2020-02-25 07:32:32 Received a POST request for / from 127.0.0.1:50744
2020-02-25 07:32:32 ThreadRPCServer method=mnsync
2020-02-25 07:32:35  pushing version 1702received version message: /BiblePay Core:1.5.0.3/: version 70753, blocks=30947, us=45.62.240.90:40001, peer=3
2020-02-25 07:32:35 debug turned on:
2020-02-25 07:32:35   thread biblepay-msghan category 1
2020-02-25 07:32:35 added time data, samples 2, offset -51 (+0 minutes)
2020-02-25 07:32:36 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 2000 fInitialDownload=1
2020-02-25 07:32:36 more getheaders (2000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:37 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 4000 fInitialDownload=1
2020-02-25 07:32:37 more getheaders (4000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:37 ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 Pre-allocating up to position 0x100000 in rev00000.dat
2020-02-25 07:32:37 UpdateTip: new best=9c223ac553eac067ad9cc119adf40e470e2eb950408775d2c3b6096010d41528 height=1 version=0x20000000 log2_work=2.00000000 tx=2 date='2019-09-19 15:33:01' progress=0.000019 cache=0.0MiB(1txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=238af87743f4d3b9f4c9169fb4ab985517785264b4d23e137643c84306e180a8 height=2 version=0x20000000 log2_work=2.58496250 tx=3 date='2019-09-19 15:33:16' progress=0.000028 cache=0.0MiB(2txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=2b6ee76068025deb173c6e8be0f414b160b3c938b37f56ef37b7b1564c84a09d height=3 version=0x20000000 log2_work=3.00000000 tx=4 date='2019-09-19 15:33:31' progress=0.000037 cache=0.0MiB(3txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=39cc5ad4f5a201cfd266c6a13fc6a8822fd7b971ae881a17b0ca32aab97277be height=4 version=0x20000000 log2_work=3.32192809 tx=5 date='2019-09-19 15:33:46' progress=0.000047 cache=0.0MiB(4txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=b19d93b185162c891d2582024abe93e6e8e87ffa9e6a9d22e88220d5f24853d5 height=5 version=0x20000000 log2_work=3.90689060 tx=6 date='2019-09-19 15:34:01' progress=0.000056 cache=0.0MiB(5txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=0bfe393a24953d7739d3a9da70c2074cb45c3e9a7161d65157a8d9d72d02893b height=6 version=0x20000000 log2_work=4.58496250 tx=7 date='2019-09-19 15:34:16' progress=0.000066 cache=0.0MiB(6txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=a4c3024fbb6090607413b6e06854b5a4991d7ce91d1f4891002f187603f3ae33 height=7 version=0x20000000 log2_work=4.85798100 tx=8 date='2019-09-19 15:34:31' progress=0.000075 cache=0.0MiB(7txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=126ad2068e4e77b671ce614779b9591fb2be5f14e21a42cacb0c00e28e38ff9e height=8 version=0x20000000 log2_work=5.52356196 tx=9 date='2019-09-19 15:34:46' progress=0.000084 cache=0.0MiB(8txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=169b7e142aa235a788f369ab89c6f3b0686bcf772b145645c337fa8d7b745d41 height=9 version=0x20000000 log2_work=5.64385619 tx=10 date='2019-09-19 15:35:01' progress=0.000094 cache=0.0MiB(9txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=1c75deb60d1cd8fdebe33259a60ee4baf98f7ea1dc78f14d59a5dcd4a855fc3c height=10 version=0x20000000 log2_work=5.97727992 tx=11 date='2019-09-19 15:35:16' progress=0.000103 cache=0.0MiB(10txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=b9432e382586d661ba8788a2987f7a02a2801597e632826480ee997baa6ff28f height=11 version=0x20000000 log2_work=6.06608919 tx=12 date='2019-09-19 15:35:31' progress=0.000112 cache=0.0MiB(11txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=6a95a72b12f328d734bb0c1f96db5f6a208ec1b277b7d63a62d4a8cf246b5f53 height=12 version=0x20000000 log2_work=6.26678654 tx=13 date='2019-09-19 15:35:46' progress=0.000122 cache=0.0MiB(12txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=544141fe4185dd6564f999fec8888d8706e0add70807da218da0a0639317e60c height=13 version=0x20000000 log2_work=6.59991284 tx=14 date='2019-09-19 15:36:01' progress=0.000131 cache=0.0MiB(13txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=2d2ab820680ce697c6a27c2822f1f96c6279aeb0b8d0197a69a48a925c5b9028 height=14 version=0x20000000 log2_work=6.65821148 tx=15 date='2019-09-19 15:36:16' progress=0.000140 cache=0.0MiB(14txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=1a3235f8c697a63257c0256323cd5826f69cbb72d3c52bf3ab924cc32af6fde9 height=15 version=0x20000000 log2_work=6.84549005 tx=16 date='2019-09-19 15:36:31' progress=0.000150 cache=0.0MiB(15txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:37 UpdateTip: new best=d89053eead9f9cf2019c87de1be982cf10c2b2b25be65bb77ccbb5cf60da8dd1 height=16 version=0x20000000 log2_work=6.90689060 tx=17 date='2019-09-19 15:36:46' progress=0.000159 cache=0.0MiB(16txo) evodb_cache=0.0MiB
2020-02-25 07:32:37 {PNB}: ACC  Received a POST request for / from 127.0.0.1:50748
2020-02-25 07:32:37 ThreadRPCServer method=mnsync
2020-02-25 07:32:38 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 6000 fInitialDownload=1
2020-02-25 07:32:38 more getheaders (6000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:38 ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=7146495d05421dd4d7119cf57c297e22458d6b624e1045c25c9a3c487ef6f9d8 height=17 version=0x20000000 log2_work=7.18982456 tx=18 date='2019-09-19 15:37:01' progress=0.000168 cache=0.0MiB(17txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=ee115f49afd3ceed1f9ea5f9022b9037daecd4ccfb1675a537db0d20cc319f84 height=18 version=0x20000000 log2_work=7.22881869 tx=19 date='2019-09-19 15:37:16' progress=0.000178 cache=0.0MiB(18txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=8b01c2d73109efc42d3b26df74ebb4b6f47bad592023fd2cbcdc65b1861a71ae height=19 version=0x20000000 log2_work=7.41785251 tx=20 date='2019-09-19 15:37:31' progress=0.000187 cache=0.0MiB(19txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=d3b7cfe27ef18576767c381a2b54815bc478370a76296f797d71ae36bf03cc62 height=20 version=0x20000000 log2_work=7.45121111 tx=21 date='2019-09-19 15:37:46' progress=0.000197 cache=0.0MiB(20txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=058b0d5d41589e36cb7374aba076d3c210e0ceee8b3eb9b5640430f491771c58 height=21 version=0x20000000 log2_work=7.61470984 tx=22 date='2019-09-19 15:38:01' progress=0.000206 cache=0.0MiB(21txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=802d2463b3bdaecc5fe815892db95ce4a3b1825290d41d76d39fb831dfca79e6 height=22 version=0x20000000 log2_work=7.64385619 tx=23 date='2019-09-19 15:38:16' progress=0.000215 cache=0.0MiB(22txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=9953e73de4d29a101bfcfd74c2a7042c2d5ec5877902ffa2801defbb3f7b4eb1 height=23 version=0x20000000 log2_work=7.75488750 tx=24 date='2019-09-19 15:38:31' progress=0.000225 cache=0.0MiB(23txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=d85ed38301f90a5681ac93d588d9bde375f495f2e72d5cbdfa6bd0cd1c8ca7ed height=24 version=0x20000000 log2_work=7.78135971 tx=25 date='2019-09-19 15:38:46' progress=0.000234 cache=0.0MiB(24txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=0d33f97d3ddc85477973e1ece454f059d899f99a53e2aca8225f373c0397cd86 height=25 version=0x20000000 log2_work=7.85798100 tx=26 date='2019-09-19 15:39:49' progress=0.000243 cache=0.0MiB(25txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=644f05f9a7d3e5601f79408f058a9b28bda146a4eadd628e113761683db80f5c height=26 version=0x20000000 log2_work=8.03891899 tx=27 date='2019-09-19 15:40:04' progress=0.000253 cache=0.0MiB(26txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=0b59e12acb0fe81a37dbcc1e81d71729276f395780a6d9c6b940623f4375caf4 height=27 version=0x20000000 log2_work=8.06608919 tx=28 date='2019-09-19 15:40:19' progress=0.000262 cache=0.0MiB(27txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=58d8a70a891a0bd3183baf0d75a73978b4f20a6a2d4530f5d4c4bce63790d99b height=28 version=0x20000000 log2_work=8.19475685 tx=29 date='2019-09-19 15:40:34' progress=0.000271 cache=0.0MiB(28txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=22a0fe6b3f80fb41bfeb221c53fbc1ff04505f7792128e38f15919fd022c3a20 height=29 version=0x20000000 log2_work=8.22400167 tx=30 date='2019-09-19 15:40:49' progress=0.000281 cache=0.0MiB(29txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=2b7bc612b2cb69c9105cab95a5138381d153d99ee0fda9778f5287df58a88797 height=30 version=0x20000000 log2_work=8.24317398 tx=31 date='2019-09-19 15:41:04' progress=0.000290 cache=0.0MiB(30txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=94c551030dcee5fa52fc418f1e8a273eb94e925450c84602c8bf38e98789b41a height=31 version=0x20000000 log2_work=8.30378075 tx=32 date='2019-09-19 15:41:19' progress=0.000299 cache=0.0MiB(31txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:38 UpdateTip: new best=fb4706c120c646c23cb7e4c9ee9e1e1781e1d8f71cbcd2f17bbedc8124ad1848 height=32 version=0x20000000 log2_work=8.32192809 tx=33 date='2019-09-19 15:41:34' progress=0.000309 cache=0.0MiB(32txo) evodb_cache=0.0MiB
2020-02-25 07:32:38 {PNB}: ACC  CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 8000 fInitialDownload=1
2020-02-25 07:32:39 more getheaders (8000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:39 ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=91e4e1c6076bfb9d03bf1f549d642bc254426c71e8d15c152aab3f77fd72bafa height=33 version=0x20000000 log2_work=8.36194377 tx=34 date='2019-09-19 15:41:49' progress=0.000318 cache=0.0MiB(33txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=7f0fb4ad6eb15674d507e0a92c3c54004df3530fe11d746f4a25dd2200f6f458 height=34 version=0x20000000 log2_work=8.45121111 tx=35 date='2019-09-19 15:42:04' progress=0.000328 cache=0.0MiB(34txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=7b81729377d3ba308318c10279f3eaf96f6db68837d82d5f2c3467c915278793 height=35 version=0x20000000 log2_work=8.46760555 tx=36 date='2019-09-19 15:42:19' progress=0.000337 cache=0.0MiB(35txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=a924bfa21d5f4163399587997b1fe54682c65e7281889529ec03f75e2ab1d419 height=36 version=0x20000000 log2_work=8.52747701 tx=37 date='2019-09-19 15:42:34' progress=0.000346 cache=0.0MiB(36txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=2e58b956975d2cb2f80fbe9d25791ad9e38cf6142953a363937a7a23fd51be69 height=37 version=0x20000000 log2_work=8.54689446 tx=38 date='2019-09-19 15:42:49' progress=0.000356 cache=0.0MiB(37txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=c27b3aa43aa465b77f4b5b34d7c74bc3d19ff03ea0cac74dbfa2fd9582e51fdd height=38 version=0x20000000 log2_work=8.66888498 tx=39 date='2019-09-19 15:43:04' progress=0.000365 cache=0.0MiB(38txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=b46840fbe5e9ef46c8ddb7bdc9e25b50493c77550cff19e6ef4b8b317ac829f3 height=39 version=0x20000000 log2_work=8.68299458 tx=40 date='2019-09-19 15:43:19' progress=0.000374 cache=0.0MiB(39txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=334aa28219438ad386a7a4e87eb2f633cce4ced15e5cc18e9828b4eabe32b6c6 height=40 version=0x20000000 log2_work=8.79116289 tx=41 date='2019-09-19 15:43:34' progress=0.000384 cache=0.0MiB(40txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=da4f541fd413398cccce5f6d9e0dbc644f9b17a051f465740fc8484a2b7ce7b9 height=41 version=0x20000000 log2_work=8.80735492 tx=42 date='2019-09-19 15:43:49' progress=0.000393 cache=0.0MiB(41txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=cbbc7e3fd74891f2e816535c0679fde81858ceff2ae9fb5bd5d17af78c44e4f8 height=42 version=0x20000000 log2_work=9.00842862 tx=43 date='2019-09-19 15:44:04' progress=0.000402 cache=0.0MiB(42txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=3b9ac1a20a201b282e88f6d1d87ab51efb6898ebe2d9ac5d45f78dd5007ebcfb height=43 version=0x20000000 log2_work=9.02236781 tx=44 date='2019-09-19 15:44:19' progress=0.000412 cache=0.0MiB(43txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=ab9a2d23f7ea54bb9b52c5c9216ff9b9d5af70abcfa1debc0900d621c50f2850 height=44 version=0x20000000 log2_work=9.03342300 tx=45 date='2019-09-19 15:44:34' progress=0.000421 cache=0.0MiB(44txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=8120a9b85934314afa09de38bd4426e1f409cdf2b51fa1e8730ee77c224d8ee4 height=45 version=0x20000000 log2_work=9.05799172 tx=46 date='2019-09-19 15:44:49' progress=0.000430 cache=0.0MiB(45txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=aa3fffe227186ba2f8708a8e2566a8fa0b8aef5476ab0e8154a4461b9c12dc47 height=46 version=0x20000000 log2_work=9.24555271 tx=47 date='2019-09-19 15:45:04' progress=0.000440 cache=0.0MiB(46txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=698e25b95048d926c45f2dc841d58cfd74163a04a7735fa8b2a7eefc61ef5916 height=47 version=0x20000000 log2_work=9.25502857 tx=48 date='2019-09-19 15:45:19' progress=0.000449 cache=0.0MiB(47txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=2e6124234f988fdcfcece29a79905eea6784ada8f8442094a3ef91bdcbf6b50b height=48 version=0x20000000 log2_work=9.28540222 tx=49 date='2019-09-19 15:45:34' progress=0.000459 cache=0.0MiB(48txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 10000 fInitialDownload=1
2020-02-25 07:32:39 more getheaders (10000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:39 ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=241b8591f93464cff00c25db841f900fb01d7642013161425bf817c84fff8479 height=49 version=0x20000000 log2_work=9.29691621 tx=50 date='2019-09-19 15:45:49' progress=0.000468 cache=0.0MiB(49txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=6aa1e8b38ea074e8133339deafb7b0d83e4565e2b37169b47aa3f0fb9fb394d9 height=50 version=0x20000000 log2_work=9.35755200 tx=51 date='2019-09-19 15:46:04' progress=0.000477 cache=0.0MiB(50txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=6057db921f2482de6c9dcddc00af4e46804de1b1501a37418fcc6cbe8d5b5a18 height=51 version=0x20000000 log2_work=9.36632221 tx=52 date='2019-09-19 15:46:19' progress=0.000487 cache=0.0MiB(51txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=dc0df33264aa68c778af06ba6f24d549f8f17046e1eaa8e019f997d5d1e14dea height=52 version=0x20000000 log2_work=9.40087944 tx=53 date='2019-09-19 15:46:34' progress=0.000496 cache=0.0MiB(52txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=8f10cec7dc3515c52ba90a612e4c82d440cbd4a99a2ab443b74a7c1be51ee90e height=53 version=0x20000000 log2_work=9.40939094 tx=54 date='2019-09-19 15:46:49' progress=0.000505 cache=0.0MiB(53txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=23cdaa4ea1065033b4c743a61fb04fb8653c21d3a39bc7e96b84ab9334aa43f9 height=54 version=0x20000000 log2_work=9.43879185 tx=55 date='2019-09-19 15:47:04' progress=0.000515 cache=0.0MiB(54txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=72ce7c4f1bf8b41c9b057da94204d929af35ee6756c7e14e1c9706c2d7c48ad6 height=55 version=0x20000000 log2_work=9.59432460 tx=56 date='2019-09-19 15:47:19' progress=0.000524 cache=0.0MiB(55txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=341c4a6f8608d9e50776f795bee87de579aee661ce208946f7c3584389b927ce height=56 version=0x20000000 log2_work=9.60547952 tx=57 date='2019-09-19 15:47:34' progress=0.000533 cache=0.0MiB(56txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=15a315723556907044d8507786644576e4b670bb44696ca017967716298ed8d7 height=57 version=0x20000000 log2_work=9.61286850 tx=58 date='2019-09-19 15:47:49' progress=0.000543 cache=0.0MiB(57txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=544ef623886523e18ef22ce0e511ac9401e6ca779c30066f077c0b66a4015b89 height=58 version=0x20000000 log2_work=9.65463603 tx=59 date='2019-09-19 15:48:04' progress=0.000552 cache=0.0MiB(58txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=54025bb678c76a60009db817ef24632494fa19d38f2b4230da8a5a71f6346662 height=59 version=0x20000000 log2_work=9.66355810 tx=60 date='2019-09-19 15:48:19' progress=0.000561 cache=0.0MiB(59txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=042d11e87e46385b06014051f584211ac8fc5fe3abbc301fa02a9fa535440424 height=60 version=0x20000000 log2_work=9.68299458 tx=61 date='2019-09-19 15:48:34' progress=0.000571 cache=0.0MiB(60txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=8b209285a11fab86daf23dc119c086563d6cc57e0899e5271b270c94bf0cb32a height=61 version=0x20000000 log2_work=9.78953364 tx=62 date='2019-09-19 15:48:49' progress=0.000580 cache=0.0MiB(61txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=4556e43581acae7ef87acacd32d37b2e93bdf443f39aeaa3f5e82794fcf1cc29 height=62 version=0x20000000 log2_work=9.79928162 tx=63 date='2019-09-19 15:49:04' progress=0.000590 cache=0.0MiB(62txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=1d1128eed7a0061ebe4e868f7be6c67282eaf86c9d53f79acb4eb74d10712c0b height=63 version=0x20000000 log2_work=9.80574387 tx=64 date='2019-09-19 15:49:19' progress=0.000599 cache=0.0MiB(63txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:39 UpdateTip: new best=a6258371135e84756876859543bb54abe79cf51a2adf2ce702fd8d5b78dcd5cf height=64 version=0x20000000 log2_work=9.84705735 tx=65 date='2019-09-19 15:49:34' progress=0.000608 cache=0.0MiB(64txo) evodb_cache=0.0MiB
2020-02-25 07:32:39 {PNB}: ACC  SPORK -- hash: a59460fb13eea5a1a6f01e07b7a4ba69d641392f3e22cb8d5cf8e6495cbbfc0e id: 10004 value:   10000000 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 0b55391d2c25736279fb64125f046026b833b7021b00cafb296dcd287b72106f id: 10008 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 0cf0f08e13495f654e08b57e5c05673cd1bab7ab7d2198d50802ece16e29ef79 id: 10015 value: 4070908800 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 6525f1c1a122176edaa8299439b580e5dca25b000a501023333f1a2aadcef848 id: 10019 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 50c879a0841b5cd3c49346b235c096c885a054e4ac0f8afd0d337732992aee07 id: 10002 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 90666fd23a735a86b8f150508b1b20e3e631e0b89de6ced2bde5414531e79a8c id: 10014 value:      17000 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 7ff45555e5fe6acbc1c19e1bbc002514a45288ee07392803cc9d4c25b8c9641b id: 10005 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 815ca4a6ad852c303d6dba1542db80d9eee0e1e0bc0e315b22d73910b2343bba id: 10090 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 2b4801666c9dcc6a0b7b9fcdd3adf437a03afd3c166449a2195484840f49ac96 id: 10018 value: 4070908800 bestHeight: 64 peer=3 new
2020-02-25 07:32:39  pushing version 1702Moving 149.28.125.16:40001 to tried
2020-02-25 07:32:39 received version message: /BiblePay Core:1.5.0.3/: version 70753, blocks=30947, us=45.62.240.90:53846, peer=4
2020-02-25 07:32:39 SPORK -- hash: 7d62890f09ccf897835181aa2f5c3ff48813cdebf2c5ecac2e1fe6efbe94008c id: 10011 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:39 SPORK -- hash: 820ec77eb24c149872bcf49391234e10d1c16f1602b238a6661bf7a8171acc53 id: 10016 value:          0 bestHeight: 64 peer=3 new
2020-02-25 07:32:40 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 12000 fInitialDownload=1
2020-02-25 07:32:40 more getheaders (12000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:40 ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=196adb6b953dced2c60d200f1a59cbb93b3aa8879eb5f3027e19abdc62504bc3 height=65 version=0x20000000 log2_work=9.85486838 tx=66 date='2019-09-19 15:49:49' progress=0.000618 cache=0.0MiB(65txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=74379e8f191f45b64896d68d5e8b8be33fef82850b20d787c5401810a85e2a7f height=66 version=0x20000000 log2_work=9.87651695 tx=67 date='2019-09-19 15:50:05' progress=0.000627 cache=0.0MiB(66txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=675d263f69868db421cf65a289ff214c48db48cb192f05f65a380d3c9f0e0bca height=67 version=0x20000000 log2_work=9.88264305 tx=68 date='2019-09-19 15:50:20' progress=0.000636 cache=0.0MiB(67txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=4fd3c136076767986a0a02d874c3618191c86ae51b5cd1ac53625b4cc1e1995a height=68 version=0x20000000 log2_work=9.90689060 tx=69 date='2019-09-19 15:50:35' progress=0.000646 cache=0.0MiB(68txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=79d80617c48debe332ef73294fd8316d99d9001482b0178b580208f0de375362 height=69 version=0x20000000 log2_work=9.91288934 tx=70 date='2019-09-19 15:50:50' progress=0.000655 cache=0.0MiB(69txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=77c4a20d1d6f574278ae4d101eecf5b8ca31378769b46f663fc21291f8f6e272 height=70 version=0x20000000 log2_work=9.92777796 tx=71 date='2019-09-19 15:51:05' progress=0.000664 cache=0.0MiB(70txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=339c93cc309b3289c61038a534bbcc15f5f8a68fd3d90d0ddbe1bac65cfd2fae height=71 version=0x20000000 log2_work=9.95855272 tx=72 date='2019-09-19 15:51:20' progress=0.000674 cache=0.0MiB(71txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=6db29ae6ee8e1756b53ae3af09043955f8016a8265c910c739f6bc364ddf973e height=72 version=0x20000000 log2_work=9.96434087 tx=73 date='2019-09-19 15:51:35' progress=0.000683 cache=0.0MiB(72txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=51a48fc0fcb6d6352096ac6fb4e02c0f5a5014fbd09fce53e6cce0abf2655e05 height=73 version=0x20000000 log2_work=9.98441846 tx=74 date='2019-09-19 15:51:50' progress=0.000692 cache=0.0MiB(73txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=dd79ca11e9f8521931d638629caaf57b1f8406817eff930e097626de9c5ae531 height=74 version=0x20000000 log2_work=9.99152185 tx=75 date='2019-09-19 15:52:05' progress=0.000702 cache=0.0MiB(74txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=6a033ba378c2d2831824396ce815d51ff4193a1d2896829d1e3b5b92cbd8816d height=75 version=0x20000000 log2_work=10.04028972 tx=76 date='2019-09-19 15:52:20' progress=0.000711 cache=0.0MiB(75txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=36d33dc35b375955c52f577178f9450c4b36f91703da6eb3e06887f6d0cb0921 height=76 version=0x20000000 log2_work=10.04575966 tx=77 date='2019-09-19 15:52:35' progress=0.000721 cache=0.0MiB(76txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=e5b7ff0c63bcd278ef62b17d5247b9f111b91037539b335f4eefdee62549a542 height=77 version=0x20000000 log2_work=10.09143539 tx=78 date='2019-09-19 15:52:45' progress=0.000730 cache=0.0MiB(77txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=58d5e1d024470d9e07bd5f51e9c5685c0ca38fba711f1b2ba1f237efc8bd9e76 height=78 version=0x20000000 log2_work=10.09803208 tx=79 date='2019-09-19 15:52:45' progress=0.000739 cache=0.0MiB(78txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=02219965066165abbd3c67c845339b288145a2cca7b43e7ea4d2b70a048df3bd height=79 version=0x20000000 log2_work=10.21674586 tx=80 date='2019-09-19 15:52:45' progress=0.000749 cache=0.0MiB(79txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-25 07:32:40 UpdateTip: new best=9e09baa119a525754e44f6b57981b216e46120f300c7165ea83b4e49ff0b6088 height=80 version=0x20000000 log2_work=10.22279490 tx=81 date='2019-09-19 15:52:46' progress=0.000758 cache=0.0MiB(80txo) evodb_cache=0.0MiB
2020-02-25 07:32:40 {PNB}: ACC  CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 14000 fInitialDownload=1
2020-02-25 07:32:41 more getheaders (14000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:42 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 16000 fInitialDownload=1
2020-02-25 07:32:42 more getheaders (16000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:42 Received a POST request for / from 127.0.0.1:50752
2020-02-25 07:32:42 ThreadRPCServer method=mnsync
2020-02-25 07:32:43 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 18000 fInitialDownload=1
2020-02-25 07:32:43 more getheaders (18000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:44 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 20000 fInitialDownload=1
2020-02-25 07:32:44 more getheaders (20000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:44  pushing version 1702received version message: /BiblePay Core:1.5.0.3/: version 70753, blocks=30911, us=45.62.240.90:40001, peer=5
2020-02-25 07:32:44 added time data, samples 3, offset -39 (+0 minutes)
2020-02-25 07:32:45 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 22000 fInitialDownload=1
2020-02-25 07:32:45 more getheaders (22000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:45  pushing version 1702received version message: /BiblePay Core:1.5.0.3/: version 70753, blocks=30947, us=45.62.240.90:40001, peer=7
2020-02-25 07:32:45 added time data, samples 4, offset -52 (+0 minutes)
2020-02-25 07:32:45  pushing version 1702Moving 64.137.171.248:40001 to tried
2020-02-25 07:32:45 received version message: /BiblePay Core:1.5.0.3/: version 70753, blocks=30911, us=45.62.240.90:59934, peer=6
2020-02-25 07:32:46 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 24000 fInitialDownload=1
2020-02-25 07:32:46 more getheaders (24000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:46 SPORK -- hash: a59460fb13eea5a1a6f01e07b7a4ba69d641392f3e22cb8d5cf8e6495cbbfc0e id: 10004 value:   10000000 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 90666fd23a735a86b8f150508b1b20e3e631e0b89de6ced2bde5414531e79a8c id: 10014 value:      17000 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 90666fd23a735a86b8f150508b1b20e3e631e0b89de6ced2bde5414531e79a8c id: 10014 value:      17000 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 0b55391d2c25736279fb64125f046026b833b7021b00cafb296dcd287b72106f id: 10008 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 50c879a0841b5cd3c49346b235c096c885a054e4ac0f8afd0d337732992aee07 id: 10002 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 50c879a0841b5cd3c49346b235c096c885a054e4ac0f8afd0d337732992aee07 id: 10002 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 0cf0f08e13495f654e08b57e5c05673cd1bab7ab7d2198d50802ece16e29ef79 id: 10015 value: 4070908800 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 6525f1c1a122176edaa8299439b580e5dca25b000a501023333f1a2aadcef848 id: 10019 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 6525f1c1a122176edaa8299439b580e5dca25b000a501023333f1a2aadcef848 id: 10019 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 6525f1c1a122176edaa8299439b580e5dca25b000a501023333f1a2aadcef848 id: 10019 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: a59460fb13eea5a1a6f01e07b7a4ba69d641392f3e22cb8d5cf8e6495cbbfc0e id: 10004 value:   10000000 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: a59460fb13eea5a1a6f01e07b7a4ba69d641392f3e22cb8d5cf8e6495cbbfc0e id: 10004 value:   10000000 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 50c879a0841b5cd3c49346b235c096c885a054e4ac0f8afd0d337732992aee07 id: 10002 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 0cf0f08e13495f654e08b57e5c05673cd1bab7ab7d2198d50802ece16e29ef79 id: 10015 value: 4070908800 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 0cf0f08e13495f654e08b57e5c05673cd1bab7ab7d2198d50802ece16e29ef79 id: 10015 value: 4070908800 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 90666fd23a735a86b8f150508b1b20e3e631e0b89de6ced2bde5414531e79a8c id: 10014 value:      17000 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 7d62890f09ccf897835181aa2f5c3ff48813cdebf2c5ecac2e1fe6efbe94008c id: 10011 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 7d62890f09ccf897835181aa2f5c3ff48813cdebf2c5ecac2e1fe6efbe94008c id: 10011 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 7ff45555e5fe6acbc1c19e1bbc002514a45288ee07392803cc9d4c25b8c9641b id: 10005 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 2b4801666c9dcc6a0b7b9fcdd3adf437a03afd3c166449a2195484840f49ac96 id: 10018 value: 4070908800 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 2b4801666c9dcc6a0b7b9fcdd3adf437a03afd3c166449a2195484840f49ac96 id: 10018 value: 4070908800 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 815ca4a6ad852c303d6dba1542db80d9eee0e1e0bc0e315b22d73910b2343bba id: 10090 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 820ec77eb24c149872bcf49391234e10d1c16f1602b238a6661bf7a8171acc53 id: 10016 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 820ec77eb24c149872bcf49391234e10d1c16f1602b238a6661bf7a8171acc53 id: 10016 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 2b4801666c9dcc6a0b7b9fcdd3adf437a03afd3c166449a2195484840f49ac96 id: 10018 value: 4070908800 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 815ca4a6ad852c303d6dba1542db80d9eee0e1e0bc0e315b22d73910b2343bba id: 10090 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 815ca4a6ad852c303d6dba1542db80d9eee0e1e0bc0e315b22d73910b2343bba id: 10090 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 7d62890f09ccf897835181aa2f5c3ff48813cdebf2c5ecac2e1fe6efbe94008c id: 10011 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 7ff45555e5fe6acbc1c19e1bbc002514a45288ee07392803cc9d4c25b8c9641b id: 10005 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 7ff45555e5fe6acbc1c19e1bbc002514a45288ee07392803cc9d4c25b8c9641b id: 10005 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:46 SPORK -- hash: 820ec77eb24c149872bcf49391234e10d1c16f1602b238a6661bf7a8171acc53 id: 10016 value:          0 bestHeight: 80 peer=4 seen
2020-02-25 07:32:46 SPORK -- hash: 0b55391d2c25736279fb64125f046026b833b7021b00cafb296dcd287b72106f id: 10008 value:          0 bestHeight: 80 peer=5 seen
2020-02-25 07:32:46 SPORK -- hash: 0b55391d2c25736279fb64125f046026b833b7021b00cafb296dcd287b72106f id: 10008 value:          0 bestHeight: 80 peer=6 seen
2020-02-25 07:32:47 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 26000 fInitialDownload=1
2020-02-25 07:32:47 more getheaders (26000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:47 Received a POST request for / from 127.0.0.1:50758
2020-02-25 07:32:47 ThreadRPCServer method=mnsync
2020-02-25 07:32:48 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 28000 fInitialDownload=1
2020-02-25 07:32:48 more getheaders (28000) to end to peer=3 (startheight:30947)
2020-02-25 07:32:49 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 30000 fInitialDownload=1
2020-02-25 07:32:49 more getheaders (30000) to end to peer=3 (startheight:30947)

8. The biblepayd appears to exit

9. Control experiment, reload wallet in old account again and sync, to show we didn't mess up the OS.

Code: [Select]
> cli getblockhash 30948
26c0a305f665d85d11de7e13618012e3a5fad037400e7f70f5490b6b0c9c9e97

>cli getblockhash 30939
19a3bdb654b0f7ebc7b7bd64fde3d44d7abc94564ab21b161664025e084d71b9


Findings
Compiling from source under the old user account works fine on the server. However, using the binaries in a newly created user account gives the above errors and the wallet cannot be loaded.

Hi Oncoapop and anyone else interested,


So to try to isolate this problem so we can convey the proper info to MIP, I added a build step to my linux build, and added a release step for testnet for Linux-64 bits:
     Linux 64 bits II (QT/biblepayd/biblepay-cli) zip:  https://biblepay.org/bbp-lin-develop-64.zip
Note, this is a zip file so please unzip it to your working directory on the VM.

So, to test this, I deployed it to one of my new sancs, unzipped it, and started biblepay with -erasechain=1 and I did sync to block 31000.
So I believe this binary is working.
Could you please confirm?

If it does work for you, that will mean we need to ask MIP to recompile linux and see if the old binary simply had a bad build, or worse if RandomX caused a problem on his build machine (thats what we need to work out for sure).  He did say RX is working in his mac.



Update on the sancs:  I have recreated 3 new sancs, and disabled the bad ones.
Lets let them burn in for 12 hours before I try to re-enable chainlocks as I dont want anyone to fork.




Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 25, 2020, 02:53:50 PM
** Compile update for 1.5.0.3 **

MIP has confirmed the prior binary was bad and wouldnt sync, and so he re-released the linux binary and confirmed the new one does sync now.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: MIP on February 26, 2020, 03:16:46 AM
** Compile update for 1.5.0.3 **

MIP has confirmed the prior binary was bad and wouldnt sync, and so he re-released the linux binary and confirmed the new one does sync now.

Thanks Rob. I basically rebuild everything from scratch, including all depends and RandomX lib, just in case.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 26, 2020, 09:28:06 AM
** Chainlocks Enabled in TestNet **

We have 7 active sancs; let's see how things go in testnet with chainlocks enabled.

I see our last GSC superblock worked correctly also. (IE the leaderboard).

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: oncoapop on February 26, 2020, 11:16:48 AM
Thanks Rob. I basically rebuild everything from scratch, including all depends and RandomX lib, just in case.

Thank you Rob and MIP.

I’ve tried the ZIP binaries method and can confirm that it works on a test account and the sanc on port 40003 is the result to prove it syncs to the top of the main chain.

I have intentionally turned the biblepayd off to see when the sanc on port 40003 gets banned.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 27, 2020, 10:07:48 AM
Thank you Rob and MIP.

I’ve tried the ZIP binaries method and can confirm that it works on a test account and the sanc on port 40003 is the result to prove it syncs to the top of the main chain.

I have intentionally turned the biblepayd off to see when the sanc on port 40003 gets banned.

Yes, I saw one of your sancs increase in POSE ban and then got revived and I think you are POSE banning 40004 now.

Everything looks OK with chainlocks running, our diff seems to remain high (.02) as our 2 miners (Earlz I think) keeps the chain running.  (Although , I would like to re-test a sync from zero right now, I'll do this now, just to ensure we sync from zero with chainlocks on).

I have one solo mining that is not in the pool (using slow-hash, 40hps) and btw, it will only get a block if the block is late (or if its extremely lucky) but I just want to point out when the block is over 30 minutes old, in the randomx environment, the target hash is reduced by 80% to allow that block to solve quickly.

So, one change request we are testing at the same time is Dash's last chainlocks update from Jan 2020 (this prevents D-dossing the sancs).  I don't think we need to do anything specific other than what we are doing as they have already released (this change) to dash-prod.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 27, 2020, 10:14:29 AM
** Orphan-Charity Pool Transparency **

So one nice thing about the future pools (at least for now, until there is a reason for things to change) is we can see the monthly income level of the charity side of the pool by tapping into the Monero receive address.  Just paste this into the pools "XMR inquiry" tab:
41s2xqGv4YLfs5MowbCwmmLgofywnhbazPEmL2jbnd7p73mtMH4XgvBbTxc6fj4jUcbxEqMFq7ANeUjktSiZYH3SCVw6uat

(Ill add the charity address to the web UI sometime today while I also add that request EarlZ put in).

So what this shows us is we have been testing for approximately 21 days, but most of the hashpower was over the last 14 days (probably from Earlz).  It shows the pool generated about $2.60 of XMR (which is pretty impressive) for orphan-charity, considering this came from just a couple people.  And remember, we only need about $20 to sponsor a Venezuelan orphan.  And on a side note, I had a call with Steve from SAI.NGO two days ago and firmed up our agreement to lock in 20-30 Venezuelan orphans next month, so that is a definite reality also. 

So, if our algorithm is working correctly it means Earlz probably mined about .26 XMR so far in testnet, is that right Earl?

I probably mined about .01 roughly.

If this particular environment scales up, we would see theoretically say, 200 miners, in June (guessing) and the .026 would be 2.60 XMR, and that would be $260 (or 13 orphans).  But lets hope for way more activity..


Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 27, 2020, 10:23:30 AM
In the NOMP rx test getting started section, under example  you could add lets say.


to add .your_worker_name after monero adress for per cpu information.

Perhaps its self explanable but its never wrong to make things easy for people that are new to this  kind of stuff.

Sure, added, it will be available on the next deploy.

Thanks.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on February 27, 2020, 01:39:58 PM
** Orphan-Charity Pool Transparency **

So one nice thing about the future pools (at least for now, until there is a reason for things to change) is we can see the monthly income level of the charity side of the pool by tapping into the Monero receive address.  Just paste this into the pools "XMR inquiry" tab:
41s2xqGv4YLfs5MowbCwmmLgofywnhbazPEmL2jbnd7p73mtMH4XgvBbTxc6fj4jUcbxEqMFq7ANeUjktSiZYH3SCVw6uat

(Ill add the charity address to the web UI sometime today while I also add that request EarlZ put in).

So what this shows us is we have been testing for approximately 21 days, but most of the hashpower was over the last 14 days (probably from Earlz).  It shows the pool generated about $2.60 of XMR (which is pretty impressive) for orphan-charity, considering this came from just a couple people.  And remember, we only need about $20 to sponsor a Venezuelan orphan.  And on a side note, I had a call with Steve from SAI.NGO two days ago and firmed up our agreement to lock in 20-30 Venezuelan orphans next month, so that is a definite reality also. 

So, if our algorithm is working correctly it means Earlz probably mined about .26 XMR so far in testnet, is that right Earl?

I probably mined about .01 roughly.

If this particular environment scales up, we would see theoretically say, 200 miners, in June (guessing) and the .026 would be 2.60 XMR, and that would be $260 (or 13 orphans).  But lets hope for way more activity..

Nothing that impressive  as 0.26 xmr but i have gotten  0.112 xmr on my test adress  for testnet here,  so around 40% charity shares from me i suppose..  Im still in the flow of setting up my miners on ubuntu,  the cpu dual miner part is easy for dual  mining not much need to know there , but im figuring out how to undervolt and stuff for my graphics cards,  well its intresting to learn new things when coming from windows and all.

I looked up charity adress you posted and it looks impressive!

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: oncoapop on February 29, 2020, 02:41:31 AM
** Chainlocks Enabled in TestNet **

We have 7 active sancs; let's see how things go in testnet with chainlocks enabled.

I see our last GSC superblock worked correctly also. (IE the leaderboard).

I have only one of my sanc that made it to block 30912 (but the block height on the NOMP pool is 31689)
The rest of my other sancs appear to be stuck on 29680 and nothing appears to be able get them to pass that block (ie sync from zero, reassess chains etc)

>cli getchaintips (from the one on block 30912)
Code: [Select]
[
  {
    "height": 31749,
    "superblock": false,
    "hash": "27c3e670d07c122c6702ae7a964a236f77b420a9c500083a8093e075cc4c6cb8",
    "difficulty": 0.01117096611785549,
    "chainwork": "00000000000000000000000000000000000000000000000000016ce13d3eec99",
    "branchlen": 837,
    "forkpoint": "c7bf513d861d05b59afd542901820122ecb4417aef84d0c5a95097b20ebf868d",
    "forkheight": 30912,
    "status": "headers-only"
  },
  {
    "height": 30912,
    "superblock": false,
    "hash": "c7bf513d861d05b59afd542901820122ecb4417aef84d0c5a95097b20ebf868d",
    "difficulty": 0.03535418162797442,
    "chainwork": "00000000000000000000000000000000000000000000000000016ce0455291bd",
    "branchlen": 0,
    "forkpoint": "c7bf513d861d05b59afd542901820122ecb4417aef84d0c5a95097b20ebf868d",
    "forkheight": 30912,
    "status": "active"
  },
  {
    "height": 30416,
    "superblock": false,
    "hash": "9da1ee9b4ca5b2f008ebfd3052692b7b076129fe48d6cddf62eec303bccab594",
    "difficulty": 0.0191308836772212,
    "chainwork": "00000000000000000000000000000000000000000000000000016cdf8bfe8b47",
    "branchlen": 1,
    "forkpoint": "49b60d1911e62bbc40c0269c1e572abcb2c611bed679977d48385c06beaf5fa2",
    "forkheight": 30415,
    "status": "valid-headers"
  },
  {
    "height": 30234,
    "superblock": false,
    "hash": "5d75d3c2bd9228add55addb36da784b3524434122f59b24041eec5b4f22f7f89",
    "difficulty": 0.011886394687722,
    "chainwork": "00000000000000000000000000000000000000000000000000016cdf2cc32730",
    "branchlen": 1,
    "forkpoint": "1f8b5ab00cd917d1407409a6ab4b32721a9873be77c3984254689ed3942c0201",
    "forkheight": 30233,
    "status": "valid-headers"
  }
]

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 29, 2020, 10:52:37 AM
I have only one of my sanc that made it to block 30912 (but the block height on the NOMP pool is 31689)
The rest of my other sancs appear to be stuck on 29680 and nothing appears to be able get them to pass that block (ie sync from zero, reassess chains etc)

>cli getchaintips (from the one on block 30912)
Code: [Select]
[
  {
    "height": 31749,
    "superblock": false,
    "hash": "27c3e670d07c122c6702ae7a964a236f77b420a9c500083a8093e075cc4c6cb8",
    "difficulty": 0.01117096611785549,
    "chainwork": "00000000000000000000000000000000000000000000000000016ce13d3eec99",
    "branchlen": 837,
    "forkpoint": "c7bf513d861d05b59afd542901820122ecb4417aef84d0c5a95097b20ebf868d",
    "forkheight": 30912,
    "status": "headers-only"
  },
  {
    "height": 30912,
    "superblock": false,
    "hash": "c7bf513d861d05b59afd542901820122ecb4417aef84d0c5a95097b20ebf868d",
    "difficulty": 0.03535418162797442,
    "chainwork": "00000000000000000000000000000000000000000000000000016ce0455291bd",
    "branchlen": 0,
    "forkpoint": "c7bf513d861d05b59afd542901820122ecb4417aef84d0c5a95097b20ebf868d",
    "forkheight": 30912,
    "status": "active"
  },
  {
    "height": 30416,
    "superblock": false,
    "hash": "9da1ee9b4ca5b2f008ebfd3052692b7b076129fe48d6cddf62eec303bccab594",
    "difficulty": 0.0191308836772212,
    "chainwork": "00000000000000000000000000000000000000000000000000016cdf8bfe8b47",
    "branchlen": 1,
    "forkpoint": "49b60d1911e62bbc40c0269c1e572abcb2c611bed679977d48385c06beaf5fa2",
    "forkheight": 30415,
    "status": "valid-headers"
  },
  {
    "height": 30234,
    "superblock": false,
    "hash": "5d75d3c2bd9228add55addb36da784b3524434122f59b24041eec5b4f22f7f89",
    "difficulty": 0.011886394687722,
    "chainwork": "00000000000000000000000000000000000000000000000000016cdf2cc32730",
    "branchlen": 1,
    "forkpoint": "1f8b5ab00cd917d1407409a6ab4b32721a9873be77c3984254689ed3942c0201",
    "forkheight": 30233,
    "status": "valid-headers"
  }
]

Yes, I see the underlying issue (dash's very strict policy for sanc-quorums to never be allowed to go out of sync, nor recover), but one thing I want to say, my sancs actually never did go out of sync.  They made it to the top height, so I assume this problem occurs when you tried to resync your sanc from zero (it shouldnt have went out of sync by itself).  Or did one of yours die by itself?

Anyway, I have added a special rule to allow us to get through this situation, and Im releasing leisure now.

If you are on the self compiled nodes you can go ahead and try to upgrade to 1.5.0.4 and resync from zero and our sancs should agree then.
Over the next 15 days or so we should clearly see if we all stay in sync, as I think the true nature will come out.  Im attempting to leave chainlocks on straight through to the end of testing.

We will also make a release for this.

So in summary, anyone who tried to re-sync from zero *after* we enabled chainlocks gets hosed at the 29680 or so height, due to the strict rules.  After the next upgrade anyone can resync but also should stay in sync with chainlocks on.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 29, 2020, 11:51:54 AM
1.5.0.4-Leisure Upgrade for TestNet

- Dont enforce LLMQ quorum til after DM height (allows sancs to die and a new farm to be recreated in testnet - should never be encountered in prod unless the coin goes through a dead period, this would allow the coin to be revived)
 

** Note: I released the windows and the " Linux 64 bits II (QT/biblepayd/biblepay-cli) zip:  https://biblepay.org/bbp-lin-develop-64.zip"  binary also.  MIP is compiling the other ones.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on February 29, 2020, 01:59:33 PM
Dear Testers,

I would appreciate any help you can provide testing our new beta foundation website also:
https://forum.biblepay.org/index.php?topic=497.msg7053#msg7053

Thanks-
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: oncoapop on March 01, 2020, 08:41:27 AM
Yes, I see the underlying issue (dash's very strict policy for sanc-quorums to never be allowed to go out of sync, nor recover), but one thing I want to say, my sancs actually never did go out of sync.  They made it to the top height, so I assume this problem occurs when you tried to resync your sanc from zero (it shouldnt have went out of sync by itself).  Or did one of yours die by itself?

Anyway, I have added a special rule to allow us to get through this situation, and Im releasing leisure now.

If you are on the self compiled nodes you can go ahead and try to upgrade to 1.5.0.4 and resync from zero and our sancs should agree then.
Over the next 15 days or so we should clearly see if we all stay in sync, as I think the true nature will come out.  Im attempting to leave chainlocks on straight through to the end of testing.

We will also make a release for this.

So in summary, anyone who tried to re-sync from zero *after* we enabled chainlocks gets hosed at the 29680 or so height, due to the strict rules.  After the next upgrade anyone can resync but also should stay in sync with chainlocks on.

Ah... got to know. I updated and rebooted my servers and somehow decided to sync from zero but I remember that at least one was already stuck on block 29680. So in production, we should never resync sancs from zero once chainlocks are in place? what would happen if by mistake we do, we have to recreate the sanc?

Anyway, I used the zip as the binaries do not appear to be ready; all my sancs are now synced to 31991 with hash 200ddb5167d7e601d0c4359f8db2a85b940d91150207ced941de7b905da784d7. Thank you.
 
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 01, 2020, 11:05:57 AM
Ah... got to know. I updated and rebooted my servers and somehow decided to sync from zero but I remember that at least one was already stuck on block 29680. So in production, we should never resync sancs from zero once chainlocks are in place? what would happen if by mistake we do, we have to recreate the sanc?

Anyway, I used the zip as the binaries do not appear to be ready; all my sancs are now synced to 31991 with hash 200ddb5167d7e601d0c4359f8db2a85b940d91150207ced941de7b905da784d7. Thank you.

Well its a complicated answer so let me try to explain (about prod, that is):

- First, prod really should not be in the same situation.  The situation arises when a supermajority of sancs all die off (which should not actually happen in prod ever since inception).  Thats the root of the argument I have with the strict dash code, they have over 4000 mn's so their assumption is they will never encounter this.  But in a smaller community like ours, we have encountered this in testnet twice already.  But no, to my knowledge this would not happen in prod because we have not lost a supermajority of sancs in prod ever since inception.
- Next, if there is ever a condition that a user discovers preventing sync from 0 (even on a sanc) we will add code to circumvent that -as that is not acceptable.
- The latest patch will ultimately get released to prod, meaning this situation would be prevented in the future in prod anyway (it allows us to set a higher DM go live height, such as equal to the RX go live height) mitigating even this from happening - and we will certainly do that for safety.

So now all we need to do is run in testnet for a couple more weeks, and without any changes in settings, we can resync our sancs from zero and verify they all sync to the top - this will just mean that chainlock quorums are actually "sticking".  Then we can feel good about how the behavior will be in prod after the rx height, as prod should mimic this exact behavior.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on March 02, 2020, 02:43:32 AM
The dual hash miner seems rock solid to me, have been running for 7 days on one ubuntu rig i set up.

Other than the things we have already talked about , eg xmr charity latency  not displaying  i still have some bbp rejects and i suppose most of them are due to the high latency for the shares..

they average around 300-600ms  the bbp shares that is.

So what do you think of setting up a european pool server Rob for when mainnet launch or too expensive?

Yeah i have no experience from pool operating or anything like that just shooting out ideas from my head.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 02, 2020, 09:06:21 AM
The dual hash miner seems rock solid to me, have been running for 7 days on one ubuntu rig i set up.

Other than the things we have already talked about , eg xmr charity latency  not displaying  i still have some bbp rejects and i suppose most of them are due to the high latency for the shares..

they average around 300-600ms  the bbp shares that is.

So what do you think of setting up a european pool server Rob for when mainnet launch or too expensive?

Yeah i have no experience from pool operating or anything like that just shooting out ideas from my head.

Oh great, thats good to hear bout the ubuntu miner - as I have only tested that minimally, so Im glad its acting as reliably as the windows miner, perfect.
Regarding the xmr-charity shares, I did fix that but I need to check the code in and release it - I will try to do that today just so we can knock that out. 

Yeah, it seems to me that all of the issues I can think of in the xmrig miner have been solved, and the pool has been running fine without any reboots.  The core wallet is now running fine in both solo mining and (I think, the sancs are OK with chainlocks, we will check that again), but to my knowledge the only feature that is not programmed yet- that we should probably tackle before we try to launch this baby  - is the pool spork enforcement reqs.  As I know we will eventually need them.  Ill try to put this feature in soon.  This just basically allows us to enforce that blocks solved in biblepay-rx in the future must come from one of our pools - this is so people cant get around mining personal blocks to circumvent giving to charity (they will all have to pool mine if difficulty is greater than say, 10 for example in prod).

As far as multiple pools, Its going to be very easy to run, at least in this first version.  Nomp can be set up on a dual core vm in about an hour.  So I think it would only cost someone $20 to run one in Europe on vultr.  However I would be looking for a volunteer to run other pools as Id like to limit myself to running one (but I will say this I will scale mine up as big as necessary, so if it starts to slow down due to having 250 miners Ill gladly add more nodes at that point and keep scaling it up) - I just mean, Id rather not be involved in running multiple domains myself.  Btw, we give out free subdomains to anyone who wants to start a european pool - for example, europa.biblepay.org - I can point that DNS to anyone who wants it.

On the bbp rejects, I did go through the pain of trying to reduce all other types (other than stale) to the point where it appears the business logic is very accurate (another words, the rejects all point to stale shares).  I believe the stales are more of a function of 'how many people are mining in testnet'.  As I imagine if we had 100 miners (in contrast to 2), I imagine that 99.9% of the shares the pool gives will not be stale.  In testnet we have this high propensity for receiving a stale share when:  Miner has asked for 10 threads of work, someone solves the block, then for the next 30 secs, the latent threads keep submitting stale shares.  In prod, we should see many more partial solutions (IE shares were submitted on low diff results - not a block solution) resulting in a higher % of non-stale, I believe. 

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 02, 2020, 01:26:35 PM
XMRig
5.6.2-Leisure Upgrade


- Expose charity XMR latency
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on March 03, 2020, 05:35:42 AM
XMRig
5.6.2-Leisure Upgrade


- Expose charity XMR latency

Been testing on w10 latest release. Looks real solid. Later tonight gonna install on ubuntu 18.04 machines aswell.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 03, 2020, 09:36:12 AM
Been testing on w10 latest release. Looks real solid. Later tonight gonna install on ubuntu 18.04 machines aswell.

Thanks, and I still have to release the latest nomp web site (with the extra parameter in the instructions)  and  look at the spork.

I wonder if we will be able to find some kind of monero forum we can post this in when we go live.  Like directly in the monero reddit.  It will be good to tiptoe in and try to be friends with monero, and not hostile.  As technically it would be best for all parties if we can help each other.  A hostile attitude would mean they would be inclined to change code to kick us out; but - if we can be friends - that would mean they help orphans and we remain stable for a long period.

I was definitely thinking bitcointalk dedicated page (like Togo suggested) for specific monero questions from new miners.

It feels to me like these new launch announcement threads dont have nearly the impact they used to.  I started one with BiblePay on cryptocointalk a while back and got like one reply, and
 it was basically someone asking me to go to work for them, etc.

But otoh, I think when we explain the dual revenue and First bitcoin branch to embrace RX, this could still be a different story.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on March 03, 2020, 02:37:31 PM
For sure things arent as heated as back in 2016, the ethereum boom and all.

But should revenue go up for miners in comes alot of new people.

Also cpu mining are getting more and more folks intrested, for example monero switching to cpu friendly randomX .  And i belive some other algos also designed for cpu only.

Yeah bitcointalk is one place but i think reddit has more new people , people asking how to do setups and all. More active if i say so.

Also i belive monero community seems to be happy sponsoring professors and mesh networking prototypes and what not. A giving/sharing community so i think most folks would be positive about what you doing here.

As for xmrig developers might add somewere " to donate xmrig developers: xmr adress:   btc adress:  .

Well you get my point.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 04, 2020, 01:00:38 PM
For sure things arent as heated as back in 2016, the ethereum boom and all.

But should revenue go up for miners in comes alot of new people.

Also cpu mining are getting more and more folks intrested, for example monero switching to cpu friendly randomX .  And i belive some other algos also designed for cpu only.

Yeah bitcointalk is one place but i think reddit has more new people , people asking how to do setups and all. More active if i say so.

Also i belive monero community seems to be happy sponsoring professors and mesh networking prototypes and what not. A giving/sharing community so i think most folks would be positive about what you doing here.

As for xmrig developers might add somewere " to donate xmrig developers: xmr adress:   btc adress:  .

Well you get my point.
Yea, good point on the traffic and stuff.  When Vitalik called me on my cell phone back then I really didn't understand the gravity of the situation - at the time he sounded like he was designing a rocket engine, but it was so advanced... it's something I'll have to discuss some time.

So yes on the donate, I did put the 'suggestion' in the code, but yes good idea to make it on the display: I added it to the next version.

10-4 on the new users, that will be very good.

So an update for everyone, I did add the spork last night, and we can test that during the next release.  I believe I will be able to unit test that change locally so no rush.
I also erased my chain and resynced my local node, and I see it made it to the top block without a problem, so I believe this latest patch is all we needed for prod.

One side note guys that could help:  If anyone wants to try mining (solo mining in the wallet) against Prod in this random-x QT wallet (not randomx mining, regular POBH mining against prod).  Just make sure this 1.5.0.4 version syncs to the top in prod and solo mines (-erasechain=1 first).  This is for our regression testing (to ensure we didnt break any existing features before the RX cutover height).  We need to see that prod masternodes can also be seen in the Sanc list, and that the governance data is visible in this branch.

Finally, I am just about ready to create a wiki page for the game plan for 'corporate whitebranding'.  The reason this ties into testnet is we could potentially start the initiative (that replaces all of biblepay's branding information with monikers).  Monikers allow CSS, logos, brand slogans, narratives, and coin phrases to be replaced with the corporations identity.  I'm just mentioning this because if the plan becomes solid, we can potentially test part of this in testnet while we wait to upgrade to RX.  On a side note, I'm still shooting for a potential end of March roll-out.  (We can't upgrade more than once per quarter due to the exchange rules).  However I also don't want to release 'too much' good information at once for BiblePay as that might rocket us accidentally up to the top 5 coins too quickly, etc.



Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: oncoapop on March 05, 2020, 01:19:55 AM
Yea, good point on the traffic and stuff.  When Vitalik called me on my cell phone back then I really didn't understand the gravity of the situation - at the time he sounded like he was designing a rocket engine, but it was so advanced... it's something I'll have to discuss some time.

So yes on the donate, I did put the 'suggestion' in the code, but yes good idea to make it on the display: I added it to the next version.

10-4 on the new users, that will be very good.

So an update for everyone, I did add the spork last night, and we can test that during the next release.  I believe I will be able to unit test that change locally so no rush.
I also erased my chain and resynced my local node, and I see it made it to the top block without a problem, so I believe this latest patch is all we needed for prod.

One side note guys that could help:  If anyone wants to try mining (solo mining in the wallet) against Prod in this random-x QT wallet (not randomx mining, regular POBH mining against prod).  Just make sure this 1.5.0.4 version syncs to the top in prod and solo mines (-erasechain=1 first).  This is for our regression testing (to ensure we didnt break any existing features before the RX cutover height).  We need to see that prod masternodes can also be seen in the Sanc list, and that the governance data is visible in this branch.

Finally, I am just about ready to create a wiki page for the game plan for 'corporate whitebranding'.  The reason this ties into testnet is we could potentially start the initiative (that replaces all of biblepay's branding information with monikers).  Monikers allow CSS, logos, brand slogans, narratives, and coin phrases to be replaced with the corporations identity.  I'm just mentioning this because if the plan becomes solid, we can potentially test part of this in testnet while we wait to upgrade to RX.  On a side note, I'm still shooting for a potential end of March roll-out.  (We can't upgrade more than once per quarter due to the exchange rules).  However I also don't want to release 'too much' good information at once for BiblePay as that might rocket us accidentally up to the top 5 coins too quickly, etc.

BiblePay Core version 1.5.0.4 (64-bit)
Windows qt

- syncs to the top of main chain
getblockhash 180368
32d69ae1ce3aec5415a01d07704f1f6253bd6e471fe636d6541b8381f2c11176
- wallet loads fine
- 186 sancs listed in sanc tab
- Leaderboard appears to be correct

-erase chain and resync - taking a very long time (will report back later)

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on March 05, 2020, 03:13:51 AM
Quote
However I also don't want to release 'too much' good information at once for BiblePay as that might rocket us accidentally up to the top 5 coins too quickly, etc.

Love the positivity  ;D
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: oncoapop on March 05, 2020, 03:37:50 AM
BiblePay Core version 1.5.0.4 (64-bit)
Windows qt

- syncs to the top of main chain
getblockhash 180368
32d69ae1ce3aec5415a01d07704f1f6253bd6e471fe636d6541b8381f2c11176
- wallet loads fine
- 186 sancs listed in sanc tab
- Leaderboard appears to be correct

-erase chain and resync - taking a very long time (will report back later)

-erase chain and resync on mainchain - ok

>cli getblockcount
180392

>cli getblockhash 180392
7b90b5fbb0cfbfd06b4c47981ebca34c7b06a909b970a979e34f4a8074c2fe0e

(Matches with CryptoID explorer)
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: oncoapop on March 05, 2020, 03:44:39 AM
-erase chain and resync on mainchain - ok

>cli getblockcount
180392

>cli getblockhash 180392
7b90b5fbb0cfbfd06b4c47981ebca34c7b06a909b970a979e34f4a8074c2fe0e

(Matches with CryptoID explorer)

BiblePay Core version 1.5.0.4 (64-bit) appears to hash on main chain

>getmininginfo

Code: [Select]
{
  "blocks": 180393,
  "currentblocksize": 1330,
  "currentblocktx": 1,
  "difficulty": 4694.69442578912,
  "errors": "",
  "pooledtx": 0,
  "chain": "main",
  "genproclimit": 4,
  "networkhashps": 537711.1247468939,
  "hashps": 3518.900343642611,
  "minerstarttime": "03-05-2020 09:41:24",
  "hashcounter": 1024,
  "pooledtx": 0,
  "chain": "main",
  "biblepay-generate": true
}
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 05, 2020, 09:16:49 AM
BiblePay Core version 1.5.0.4 (64-bit) appears to hash on main chain

>getmininginfo

Code: [Select]
{
  "blocks": 180393,
  "currentblocksize": 1330,
  "currentblocktx": 1,
  "difficulty": 4694.69442578912,
  "errors": "",
  "pooledtx": 0,
  "chain": "main",
  "genproclimit": 4,
  "networkhashps": 537711.1247468939,
  "hashps": 3518.900343642611,
  "minerstarttime": "03-05-2020 09:41:24",
  "hashcounter": 1024,
  "pooledtx": 0,
  "chain": "main",
  "biblepay-generate": true
}


Thanks!

Thats good to know!

10-4 on the sanc info, the hashing and the syncing.  I think the speed is OK (I was looking at the sync speed in prod yesterday) - IE normal.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 06, 2020, 08:30:41 AM
Dear Testers,

I would appreciate any help you can provide testing our new beta foundation website also:
https://forum.biblepay.org/index.php?topic=497.msg7053#msg7053

Thanks-

Will anyone be able to help out and test these features above?


EDIT:   Regarding corporate whitebranding, I'm adding it now; it's a huge change...  Hopefully we will have something to test within a couple days in testnet.

Edit 2: I am in the process of changing our github over to biblepay/biblepay (the way it was originally).  We will also move the data directory back to ~/.biblepay.  I know its a pain but I think for the longer term it will be clearer for everyone.  We can move away from "evolution" as that should have been considered a release (not a product) etc and I believe this has caused some confusion.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on March 06, 2020, 02:10:35 PM
I have been thinking, perhaps you could add tls for monero as option in future release?

like if we set in parameters: 
Code: [Select]
--tls   we get sent to diffrent pool option.

Also if you could  differentiate bbp rejects and xmr rejects..
I have one cpu that has some invalid xmr shares that it probably shouldnt have.
So just figured for  troubleshooting purposes.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 07, 2020, 01:26:51 PM
I have been thinking, perhaps you could add tls for monero as option in future release?

like if we set in parameters: 
Code: [Select]
--tls   we get sent to diffrent pool option.

Also if you could  differentiate bbp rejects and xmr rejects..
I have one cpu that has some invalid xmr shares that it probably shouldnt have.
So just figured for  troubleshooting purposes.

I'll look into these two issues after we release; we are preparing a release for BBP & DAC now for testnet.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 07, 2020, 05:34:50 PM
I have been thinking, perhaps you could add tls for monero as option in future release?

like if we set in parameters: 
Code: [Select]
--tls   we get sent to diffrent pool option.

Also if you could  differentiate bbp rejects and xmr rejects..
I have one cpu that has some invalid xmr shares that it probably shouldnt have.
So just figured for  troubleshooting purposes.

Hi Earl,

I havent looked into this yet, but on the second part about rejects could you please provide more info or an example, because to my knowledge, if you submit a rejected BBP share, our BBP rejects increase (as we know as the pool displays those in a separate column).
Now I havent been able to make a reject occur on the XMR side personally, but, to my knowledge the XMR rejects should increment separately and you should see those in the pool under the XMR column.

So could you provide more info, if this is something not happening in the pool or not happening in the xmrig, and if its in xmrig, what row is it missing on?
I dont need a screen shot just an example so we can pinpoint it.

Thanks.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 07, 2020, 05:42:10 PM
I have been thinking, perhaps you could add tls for monero as option in future release?

like if we set in parameters: 
Code: [Select]
--tls   we get sent to diffrent pool option.

Also if you could  differentiate bbp rejects and xmr rejects..
I have one cpu that has some invalid xmr shares that it probably shouldnt have.
So just figured for  troubleshooting purposes.

Hi Earl,

On part 1 of this:
https://xmrig.com/docs/proxy/tls

So, I'm not replying that we *cant* do it, but, instead, we just cant do it at this phase.  Here is why:  One, we have this nomp system running as a proof of concept.  Although I fully believe it will work (and probably scale), I dont want to modify nomp for TLS until we know it can handle the traffic load and does not need rewritten.  Another words, there are a couple growing pains we need to go through:  One is ensuring we dont have white hat hackers trying to circumvent the charity aspect too soon (even though we are adding the sporks first), we just may need to pull in the C version of Monero and stop using minexmr (I dont want to, Im just saying we have to keep this option open), and secondly, if nomp does not scale well, if for example if we have 2000 new XMR miners and we find nomp is sluggish, instead of adding second and third pool I might write DAC-XMR in c# again (now that I know more about stratum, and Monero).  So with these unknowns, its not worth adding TLS to nomp just yet.  So, again Im not saying no, Im just saying since all the pool traffic goes through nomp, it cant handle this yet.  Of course I will get HTTPS working on nomp first and maybe we can turn on SSL for mining first as a req baby step then revisit this after that works in prod.  We will have a github open then you can put in a new issue for this once SSL is working, cool?

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 07, 2020, 06:40:42 PM
BiblePay - DAC
1.5.0.5 - Leisure Upgrade for TestNet

- Add DAC theme, DAC Splash, DAC currency_name, DAC Github, DAC icons and images
- Add ability for wallet to pick up on startup environment program name (If DAC, theme as DAC, if BiblePay theme as BBP themes)
- Add RandomX Spork Enforcement rule

** Please use this link for Linux binaries : Linux 64 bits II (QT/biblepayd/biblepay-cli) zip:  https://biblepay.org/bbp-lin-develop-64.zip
Or, use the windows64 link in the op post for windows **

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 07, 2020, 06:47:45 PM
Test cases for DAC (1.5.0.5):

Please primarily test all these below in QT mode.  Since a lot of changes rely on graphics.

So the way this dual-branded release works is the core wallet will detect the name of the program being launched, for instance if you launch dac-qt, it realizes it is DAC.  If you launch biblepay-qt, it realizes its BBP.

If it is launched in DAC mode, you will see a different splash screen, the theme will be overridden to be DAC (and will not allow you to pick BBP themes), and everywhere in the wallet that used to say "BiblePay" should say "DAC".  Including sending coins, etc.  Please verify that is the case.

Also please launch the biblepay version and verify the old themes still work, Bezaleel still works and things still say biblepay.

The 'exec price' command should still provide the currency price (for the leaderboard).  The leaderboard should appear identical in both wallets (please check that).

To test the linux qt version, note the zip contains both 'dac-qt' and 'biblepay-qt'.  Testing those is straightforward, just run each one.
However in windows, we only released the biblepay version (due to a change that is required in the Microsoft installer for DAC.EXE, and we don't need to do that until we know the outcome of the future poll), so for now please install the windows version like normal, first test biblepay-qt.exe, then copy "biblepay-qt.exe" to "dac-qt.exe" in your windows directory, then test the DAC version.

The peers list should interoperate between the two versions, except, the DAC version advertises itself slightly different than the BBP version, but they see each other. 

The Sanctuaries list should be checked also.

By the way, in this latest release we fixed the toolbar icons for biblepay-qt (for windows and for linux).  They were not transparent now they should be transparent and fixed.

Also, just fyi, we just moved our github repo to this location: https://github.com/biblepay/biblepay/
But note:  we added an auto-redirect in from /biblepay-evolution to the new location so this means your build scripts should not really need to be updated.  (For develop or master).

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on March 08, 2020, 03:40:42 AM
Hi Earl,

On part 1 of this:
https://xmrig.com/docs/proxy/tls

So, I'm not replying that we *cant* do it, but, instead, we just cant do it at this phase.  Here is why:  One, we have this nomp system running as a proof of concept.  Although I fully believe it will work (and probably scale), I dont want to modify nomp for TLS until we know it can handle the traffic load and does not need rewritten.  Another words, there are a couple growing pains we need to go through:  One is ensuring we dont have white hat hackers trying to circumvent the charity aspect too soon (even though we are adding the sporks first), we just may need to pull in the C version of Monero and stop using minexmr (I dont want to, Im just saying we have to keep this option open), and secondly, if nomp does not scale well, if for example if we have 2000 new XMR miners and we find nomp is sluggish, instead of adding second and third pool I might write DAC-XMR in c# again (now that I know more about stratum, and Monero).  So with these unknowns, its not worth adding TLS to nomp just yet.  So, again Im not saying no, Im just saying since all the pool traffic goes through nomp, it cant handle this yet.  Of course I will get HTTPS working on nomp first and maybe we can turn on SSL for mining first as a req baby step then revisit this after that works in prod.  We will have a github open then you can put in a new issue for this once SSL is working, cool?

Yeah no problems i was just thinking, baby steps and all  8)


Anyways keep up the good work!
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 10, 2020, 08:05:53 PM
** ADDITIONAL TESTING STEP NEEDED **



I was just thinking also, since this is a *major* release (we are increasing ram footprint, switching algos, changing pools, adding randomx etc), we really should also be testing the MAC release.

Can someone please test solo mining and pool mining from a mac, and ensure biblepay-qt and biblepayd works?

I'm thinking we need to start wrapping up our testing within 7 days, so we need to do this quickly.

I also havent received any feedback on testing DAC mode yet (by anyone).

I will be rolling out the spork test tomorrow morning and testing in unit-test mode (that should be 99% reliable) then observing testnet afterwards.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: MIP on March 11, 2020, 03:44:09 AM
** ADDITIONAL TESTING STEP NEEDED **



I was just thinking also, since this is a *major* release (we are increasing ram footprint, switching algos, changing pools, adding randomx etc), we really should also be testing the MAC release.

Can someone please test solo mining and pool mining from a mac, and ensure biblepay-qt and biblepayd works?

I will start testing solo mining on macOS. So far QT version with 2 mining threads takes 949MB RAM (81MB compressed). CPU usage is consistent with the 2 threads (marks 50% on the 4 core mac)

I will report back with any findings
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: MIP on March 11, 2020, 05:24:11 AM
Mined this block so far

Code: [Select]
Status: 10 confirmations
Date: 11/03/2020 03:21
Source: Generated
Credit: 3665.44027172 tBBP (matures in 92 more blocks)
Net amount: 0.00000000 tBBP
Transaction ID: c2e2bb92dc0e747c57f55178c1ea6aded6078f1c5d6c154e87808ba683ac6808
Output index: 0
Transaction total size: 197 bytes

Generated coins must mature 102 blocks before they can be spent. When you generated this block, it was broadcast to the network to be added to the block chain. If it fails to get into the chain, its state will change to "not accepted" and it won't be spendable. This may occasionally happen if another node generates a block within a few seconds of yours.

Height: 34052
Difficulty: 0.03
Time: 03-11-2020 10:21:09
Subsidy: 3665.4403

Credit: 3665.44027172 tBBP
To: yc5ooxeM3L2So41KzhJQ2GEWmQHU26w3kg 3665.0000 BIBLEPAY

Transaction:
CTransaction(hash=c2e2bb92dc, ver=3, type=5, vin.size=1, vout.size=2, nLockTime=0, vExtraPayload.size=38)
    CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 03048500044967695e)
    CTxOut(nValue=3665.44027172, scriptPubKey=2102268878100f3f7aa982a5eb0354)
    CTxOut(nValue=6516.33826081, scriptPubKey=76a914874f7a2ed177e38b1685e4ff)
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 11, 2020, 08:30:29 AM
Mined this block so far

Code: [Select]
Status: 10 confirmations
Date: 11/03/2020 03:21
Source: Generated
Credit: 3665.44027172 tBBP (matures in 92 more blocks)
Net amount: 0.00000000 tBBP
Transaction ID: c2e2bb92dc0e747c57f55178c1ea6aded6078f1c5d6c154e87808ba683ac6808
Output index: 0
Transaction total size: 197 bytes

Generated coins must mature 102 blocks before they can be spent. When you generated this block, it was broadcast to the network to be added to the block chain. If it fails to get into the chain, its state will change to "not accepted" and it won't be spendable. This may occasionally happen if another node generates a block within a few seconds of yours.

Height: 34052
Difficulty: 0.03
Time: 03-11-2020 10:21:09
Subsidy: 3665.4403

Credit: 3665.44027172 tBBP
To: yc5ooxeM3L2So41KzhJQ2GEWmQHU26w3kg 3665.0000 BIBLEPAY

Transaction:
CTransaction(hash=c2e2bb92dc, ver=3, type=5, vin.size=1, vout.size=2, nLockTime=0, vExtraPayload.size=38)
    CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 03048500044967695e)
    CTxOut(nValue=3665.44027172, scriptPubKey=2102268878100f3f7aa982a5eb0354)
    CTxOut(nValue=6516.33826081, scriptPubKey=76a914874f7a2ed177e38b1685e4ff)

Ok, Excellent!  We needed this.

So one other thing we need for mac, can you please compile biblepay-xmrig for mac (our branch of xmrig)?  And then deploy it and let us know the name of it, and test it also?

This would ensure you can pool mine with the mac using mac xmrig :).

The pool : rxtest.biblepay.org has the correct startup info on the easy start page and the op post should be correct also.


EDIT: With the coronavirus kicking up in Europe, I realize you might be hit now, please do not put this ahead of anything that is an emergency at work.  We can always delay our go-live if need be.


Thanks!

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 11, 2020, 05:41:02 PM
So, just to summarize, we have plenty of time to test the DAC-qt side (but I still would like to see the testing done so we can confirm it works), but it is not holding up our go-live.

I just added our randomx-pools-spork, but I need to let some blocks pass before I can test it.  We should know if this works by the end of the night.

The only outstanding item I know of is the need to test xmrig on the mac.  I suppose that is not a show stopper either, because by the end of the month MIP should be around again to release that - and we can always tell people in prod the mac version will be out soon.

Can anyone think of anything else that we need to wrap up for this randomx release for a March 30th rollout?

I will make a wiki page describing how to heat mine with RandomX.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 11, 2020, 05:46:35 PM
Actually looking at the state of the sancs I see half are POSE banned; can everyone please check their sancs and see if you have not upgraded?

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 11, 2020, 06:23:55 PM
Actually looking at the state of the sancs I see half are POSE banned; can everyone please check their sancs and see if you have not upgraded?

My sancs look OK, except, one I forgot to restart - so I revived it with 'exec revivesanc sancname'.
The rest are mostly Oncoapops, I think?

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on March 12, 2020, 01:46:25 PM
The dual hash miner seems real solid to me. I have been running non stop latest version.  no problems for windows or linux/ubuntu for me.

The 10%  charity fee seem pretty much spot on when i compare hashrate normal xmrig then bbpxmrigdual for 12/24 hours.

So im looking forward mainnet launch so can save up for sanctuary.



Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 12, 2020, 04:03:51 PM
The dual hash miner seems real solid to me. I have been running non stop latest version.  no problems for windows or linux/ubuntu for me.

The 10%  charity fee seem pretty much spot on when i compare hashrate normal xmrig then bbpxmrigdual for 12/24 hours.

So im looking forward mainnet launch so can save up for sanctuary.

Thats awesome man!

Let me try to test this spork now and make some feedback.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 13, 2020, 08:37:52 AM
** Feedback **

So I'm going to spare you all the boring details.  In a nutshell, I created the spork yesterday, tested it, and the test was successful.  However it did fork a few nodes (rightly so) that were running the newest version (IE that particular block was rejected). 
But, since we have a few sancs out there who are not upgraded - we kind of have a bad consensus now in testnet.

Anyway since the test was successful, what Id like to do next is create the release for production.  I'm going to notify the exchanges of this intent to upgrade in about 12 days, release it, then I'll be back in testnet.

Since we have one more very minor thing to test in testnet Id like to make one more release here before we relax.  Then when I come back we can continue testing the final part while we wait to go live in prod.

I want to thank everyone who participated in this testing, especially:  EarlZ, and Oncoapop.  Without you two, I don't think we would have been ready to release RandomX in prod on time.
I also thank everyone else who helped:  MIP, Togo, Sun and everyone who helped in the background.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: MIP on March 14, 2020, 02:30:52 AM
I could compile our xmrig for for MacOS, please find it here

http://www.biblepay.org/xmrig_mac.zip

However it comes unsigned, so at the moment whoever wants to use it will have to disable gatekeeper to use it.
I could not test it myself yet either.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 14, 2020, 10:11:18 AM
I could compile our xmrig for for MacOS, please find it here

http://www.biblepay.org/xmrig_mac.zip

However it comes unsigned, so at the moment whoever wants to use it will have to disable gatekeeper to use it.
I could not test it myself yet either.

Thank you MIP, excuse my ignorance on the matters with Mac, as I understand the part about being able to compile it and not digitally sign it (and that the user has to disable gatekeeper).

The part I am hazy on, are you unable to test it because Gatekeeper will make your whole system insecure if you test it, or are you unable to test it because of time due to the coronavirus problems?  Another words, will anyone be able to use this or do we need to find a way to sign it?

We can't sign it with our iphone app key can we?

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: MIP on March 17, 2020, 01:23:33 AM
Thank you MIP, excuse my ignorance on the matters with Mac, as I understand the part about being able to compile it and not digitally sign it (and that the user has to disable gatekeeper).

The part I am hazy on, are you unable to test it because Gatekeeper will make your whole system insecure if you test it, or are you unable to test it because of time due to the coronavirus problems?  Another words, will anyone be able to use this or do we need to find a way to sign it?

We can't sign it with our iphone app key can we?

It's mainly lack of time for signing and for testing because of the CV emergency. I will try to create a signing script and DMG today. Without signing, anyone can use the binary but disabling the gatekeeper protection for that specific binary.
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: sunk818 on March 17, 2020, 09:36:43 AM
Are there any other requirements for the pool besides updating the code and daemon? Do I need to add a Monero wallet or anything like that?
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 17, 2020, 11:05:52 AM
Are there any other requirements for the pool besides updating the code and daemon? Do I need to add a Monero wallet or anything like that?

You would need a monero SPV prod wallet address (like a miner has), dedicated for the pool.

While you are getting that, let me see if we need any code changes to expose the address on the front page of the pool for people to see how much charity we collected.

What Im thinking is we leave it like this for 3-4 months and then reassess the situation.  If the satellite pools only collect say less than $100 per month (and successfully spend it on orphan charity for biblepay) Im not in a super hurry to re-write the whole pool in c# just yet. 

But we will need to agree on some type of liquidation plan even in this interim stage.  Im thinking about doing this:  SAI.NGO (Venezuelan orphans) has agreed to allow us to sponsor 20-30 orphans.  Once I pay for those upfront (out of my own pocket), I think I will ask Steve if he will be willing to accept XMR payments from us.
I will most likely ask you to send your monthly donation to him, and for now that will be the benefit (and of course we will give you the bios of the orphans your pool is sponsoring through SAI) so you can post those bios on one of your pool pages, etc.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 17, 2020, 11:10:06 AM
It's mainly lack of time for signing and for testing because of the CV emergency. I will try to create a signing script and DMG today. Without signing, anyone can use the binary but disabling the gatekeeper protection for that specific binary.

Ok, so you are saying people do this all the time with mac downloads.  They encounter binaries that are unsigned, but look at them as unprofessional?

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 17, 2020, 03:11:27 PM
You would need a monero SPV prod wallet address (like a miner has), dedicated for the pool.

While you are getting that, let me see if we need any code changes to expose the address on the front page of the pool for people to see how much charity we collected.

What Im thinking is we leave it like this for 3-4 months and then reassess the situation.  If the satellite pools only collect say less than $100 per month (and successfully spend it on orphan charity for biblepay) Im not in a super hurry to re-write the whole pool in c# just yet. 

But we will need to agree on some type of liquidation plan even in this interim stage.  Im thinking about doing this:  SAI.NGO (Venezuelan orphans) has agreed to allow us to sponsor 20-30 orphans.  Once I pay for those upfront (out of my own pocket), I think I will ask Steve if he will be willing to accept XMR payments from us.
I will most likely ask you to send your monthly donation to him, and for now that will be the benefit (and of course we will give you the bios of the orphans your pool is sponsoring through SAI) so you can post those bios on one of your pool pages, etc.

Btw, please don't upgrade the pool til the day before go-live, because they are not backward compatible.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 17, 2020, 08:24:00 PM
Are there any other requirements for the pool besides updating the code and daemon? Do I need to add a Monero wallet or anything like that?

Ok, so I did have to expose the XMR Charity address in the pool configuration file, that is being checked in now.

Now all, you can go to the home page of the pool (rxtest.biblepay.org) - in the 4th row under Global Stats - and see:
- The XMR Charity address (this lets people monitor the pools gains per month.  You can just paste the charity address in the XMR lookup tab btw and see the mined amount - easier than monitoring the XMR wallet balance).
- The picture of an orphan
- The suggestion that Earl made on the configuration option for the last option

Afaik, I think we are ready to go live.


Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 21, 2020, 01:35:38 PM
Ok, so I did have to expose the XMR Charity address in the pool configuration file, that is being checked in now.

Now all, you can go to the home page of the pool (rxtest.biblepay.org) - in the 4th row under Global Stats - and see:
- The XMR Charity address (this lets people monitor the pools gains per month.  You can just paste the charity address in the XMR lookup tab btw and see the mined amount - easier than monitoring the XMR wallet balance).
- The picture of an orphan
- The suggestion that Earl made on the configuration option for the last option

Afaik, I think we are ready to go live.
Test
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on March 22, 2020, 06:01:23 AM
configuring rigs so they are ready for mainnet launch ;D

2 more days right, will be intresting!
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 23, 2020, 05:24:08 PM
configuring rigs so they are ready for mainnet launch ;D

2 more days right, will be intresting!

Yeah, this should be cool!

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 24, 2020, 03:11:07 PM
Pinning this for the future in case anyone else has this issue (a silent exit by the miner after a random amount of time, especially on ryzen 1700s):
https://www.reddit.com/r/MoneroMining/comments/e4k7cq/xmrig_ryzen_7_1700_fix/f9e676q/

So there is a workaround, (Im experiencing this myself), we can make a loop in a batch file like this (pretend this is miner5.bat):

:miningloop
xmrig.exe --params
goto miningloop

I will probably be doing this myself.

And just to give a little background on the problem, first of all there is a CPU setting on some motherboards called 'opcache' that might fix the underlying issue.
But the reason we aren't trying to handle this inside the program is since the JIT machine language is generated on the fly, the actual error signal is a segfault, but in a machine language area that can't have an error catch around it - and - segfaults cause program instability if you try to program around them.  Another words the only safe way to handle this is to let the process die and restart the process at the OS level.

Hopefully not many of our users will have to do this - but I appear to be one in this category with my early version of the 1700, etc. 

I havent tried the bios change yet but Ill post if it works later.

Let's revisit this today, hang on.

Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: Rob Andrews on March 24, 2020, 03:13:45 PM
** Solution if your miner crashes when mining randomX **


Create a batch file on windows with the following

Code: [Select]
:miningloop
xmrig.exe -o rx.biblepay.org:3001 -u bbpaddress -p moneroaddress --threads=8
goto miningloop
Title: Re: BIBLEPAY - RANDOMX INTEGRATION
Post by: earlzmoade on March 25, 2020, 04:05:49 AM
** Solution if your miner crashes when mining randomX **


Create a batch file on windows with the following

Code: [Select]
:miningloop
xmrig.exe -o rx.biblepay.org:3001 -u bbpaddress -p moneroaddress --threads=8
goto miningloop

Cheers!
I have had a r5 1600 that have had some strange behaviour, will try it out.