Bible Pay

Read 6410 times

  • oncoapop
  • Full Member

    • 138


    • 14
    • October 23, 2018, 12:31:17 PM
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #105 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.



  • Rob Andrews
  • Administrator

    • 2533


    • 42
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #106 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.



  • Rob Andrews
  • Administrator

    • 2533


    • 42
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #107 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..




  • Rob Andrews
  • Administrator

    • 2533


    • 42
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #108 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.



  • earlzmoade
  • Jr. Member

    • 68


    • 16
    • August 02, 2018, 03:22:01 AM
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #109 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!

Make your walls to doors


  • oncoapop
  • Full Member

    • 138


    • 14
    • October 23, 2018, 12:31:17 PM
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #110 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"
  }
]



  • Rob Andrews
  • Administrator

    • 2533


    • 42
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #111 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.



  • Rob Andrews
  • Administrator

    • 2533


    • 42
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #112 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.



  • Rob Andrews
  • Administrator

    • 2533


    • 42
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #113 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-


  • oncoapop
  • Full Member

    • 138


    • 14
    • October 23, 2018, 12:31:17 PM
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #114 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.
 


  • Rob Andrews
  • Administrator

    • 2533


    • 42
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #115 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.



  • earlzmoade
  • Jr. Member

    • 68


    • 16
    • August 02, 2018, 03:22:01 AM
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #116 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.

Make your walls to doors


  • Rob Andrews
  • Administrator

    • 2533


    • 42
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #117 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. 

« Last Edit: March 02, 2020, 09:13:43 AM by Rob Andrews »


  • Rob Andrews
  • Administrator

    • 2533


    • 42
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #118 on: March 02, 2020, 01:26:35 PM »
XMRig
5.6.2-Leisure Upgrade


- Expose charity XMR latency


  • earlzmoade
  • Jr. Member

    • 68


    • 16
    • August 02, 2018, 03:22:01 AM
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #119 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.

Make your walls to doors