Messages

1951

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« 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.

1952

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« 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.

1953

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« 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.

1954

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: March 02, 2020, 01:26:35 PM »

XMRig
5.6.2-Leisure Upgrade

- Expose charity XMR latency

1955

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« 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. 

1956

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« 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.

1957

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« 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-

1958

TestNet Discussion Archive / The BiblePay Foundation Web Site - BETA TESTING

« on: February 29, 2020, 12:11:58 PM »

Short Term Goals:

Expense and Revenue (Accounting reports)
Orphan collage of active orphans sponsored with clickable bios
Gospel Links / Media (Videos)
Theological articles
Prayer Blog (List of prayers that need prayed)/ Add a prayer / Prayer comments
User Account with email  - and optionally basic permissions (this is so we can notify users of a mandatory upgrade, Or, assign a user a permission-required function in the future, such as allowing a user who is responsible for adding Expenses to add an expense), but note most pages will be viewable anonymously.  User account register, edit, log in, log out.
Add blurb about mandatory upgrades to landing page/ make an actual lading page.
Site should be viewable on the mobile devices; it should also allow navigation, menus, and data entry to be possible.  Wide content and long content should not break the site.




Mid Term Goals:
Christian Dashboard:  This is a list of people you want to save.
Each person will have a status, a goal, a last step.
We will provide materials to help you achieve your goal(s) (Theological articles, illustrations, childrens cartoons, videos, etc).
We should allow each Contact to be guided through a salvation plan (IE a 10 step plan to salvation, etc).
The CRM type dashboard will summarize your ministry state, providing you a tool to become a ministry.


Long Term Goals:
Guest Pastors and Historical sermons, and pay to preach
BiblePay Charity Navigator.
This summarizes charity opportunities by magnitude descending (for our user base).  It allows outside donations to pass through to charities.
The actual design will need to be detailed in a PDF.






URL:

https://foundation.biblepay.org


NOTE: This site is still in beta, so please do not post it on our social media pages until we complete the first Prod release.


So far most of the items in "short term" have been completed - except the Christian Dashboard has not been started yet.




Test Cases for Short Term Goals (Phase 1):


- Test logging in and loggout out.  When you are logged in, you should see your e-mail address on the top right.
Note: Email addresses are not revealed to other users (they can only see your nickname).

- Test adding a prayer and viewing the prayer blog.
- Test Adding a prayer comment (IE, I'm praying for this, I feel the heartache for your family etc).  Test viewing the comments.

- Test adding an avatar to your user, and viewing the image on the blog.

- Test viewing the gospel videos, the theological articles, and the illustrations.

- Provide more landing page images, for example to replace the Lion (as ours needs replaced without the watermark etc).

- Give us any ideas to make it better.  Ideas for Christian processes are also welcome, as we want to appeal to those seeking the gospel etc.

1959

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« 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.

1960

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« 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.

1961

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« 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.

1962

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« 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..

1963

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« 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.

1964

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« 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).

1965

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« 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.