Bible Pay

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Rob Andrews

Pages: 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 ... 134
106
Pre-Proposal Discussion / POOM Concept (Proof-of-Orphan-Mining)
« on: June 12, 2019, 04:57:48 pm »
June 12th, 2019

Concept:  Proof-of-Orphan-Mining (POOM)


 ** CLARIFICATION ON WHAT WE ARE VOTING ON, SANCTUARIES:
     The "Divert_50_percent_of_GSC_Budget_to_POOM" poll:

We are voting on creating an additional BiblePay GSC campaign called POOM.  This 50% poll means the budget would be capped at 450K per day.
(This would lower the POG/healing budget by 450k per day).

Each participant would receive rewards in POOM if:
- They have a credit balance with Cameroon for that Child Hex ID

Each daily reward would be capped at the exact amount of the expense.

The budget will not exceed the max 450K under any circumstances (rewards would be divided equally if we are overflowing with children).

(Please vote on the poll that you like the most - we have 3 sizes in ).


**

This concept has been discussed in various forms in the past, but I believe the reason we had no traction was the variants contained unreasonable expectations.  (Our first variation, [email protected] with orphanstats.com, required BiblePay to know personal information for each user (it required trust, contained collusion risk, and tracked personal info; and the poll indicated it was intrusive).    The second variation, asking compassion.com's IT department to create a custom API for decentralized queries, was proposed to Jimmy, CEO of Compassion - and to ciqueue - and all attempts were met with a very high resistance level ranging from not willing to hear the proposal nor have meetings nor nor creating a custom solution for us at this time).

So in light of this, this new concept places a different spin on the idea, and bends both parties a little more, revisiting the idea.  The base idea, imho, has such great potential, it would be a disgrace to ignore and drop the idea in its entirety rather than take another fresh look at re-engineering it to meet in the middle.

Some positive things have also changed in the interim; we now have GSC contracts, which facilitate a much more flexible server side environment for validating the orphan balance consensus in a decentralized way without forks.  This also provides a mechanism to reward home sponsors.

In this adjusted concept, we promote sponsorship of children at home (rather than through our governance superblock).  We do not eliminate our governance superblock; we offer POOM in addition to everything else we already have.  This has the added benefit of allowing the home miner to sponsor a home orphan and write directly to the orphan (1:1 relationship is fostered).  (Alternatively in the future, we may also allow the home user to Choose whether they want to write to the child or if they want our BiblePay-Web to write to the child- more info on this soon). 

Rob has contacted our second largest orphanage, Cameroon One, who is potentially interested in integrating with us.

In this new scenario, we simplify the API requirements, so that we integrate with a simple solution in baby step 1 (in contrast to birthing the complicated baby first, something our vendors do not want to do).  In this way we get a green light to became a partner with our valuable vendor, rather than shut down.

The first part of the concept is here:
http://wiki.biblepay.org/POOM

Part of the desire to create this pre-proposal discussion now is driven by our initial conference call.  I have a soft commitment from Todd, Director of Cameroon, and Shaun, Founder of Cameroon, and Raj (IT/Cameroon), that Cameroon will be on board with BiblePay to go forward with this design, proof of concept, testing and implementation.  (I also had a conference call discussing the IT solution, and we have a potential green light to do this).

Therefore, this proposal seeks to authorize BiblePay IT (devs) to work on this proof-of-concept, for three months, test it with Cameroon, and if it works, seeks to deploy this to production, and reward either 30%, 50%, or 70% (depending on specific sanctuary proposal entered this month) of our daily rewards out of the GSC budget, towards the sponsorship of Cameroon One children in lieu of POOM rewards, strictly for children who are sponsored through this program by miners who sponsor personal children at home through this system.  (The reason I am seeking approval of the entire program now, is it is a considerably large effort for both companies, and I want to see that we have pre-approval for this to move to production and pay production POOM rewards before we program the lions share of this).

Note, in the security section, we intend to create two rules that make this relationship much more than an oracle:

Rule 1:
When a miner wishes to sponsor a new child, they will enter a command in the wallet (IE 'sponsorchild').  When the sponsorchild command executes, they will receive a Child ID (a Cameroon One Child ID).  This will be a distinct global ID that will prevent Cameroon One from giving this child to any other donor!  Therefore, we will enforce a rule where an existing Cameroon One home donor cannot come to biblepay with an existing orphan, they must initiate the orphan through BiblePay.  During this step, Cameroon will create a childhood BIO URL for the miner, and, a tracking code in their accounting system (allowing BiblePay sanctuaries to track this childs balance as charges, and payments are made to this childs record).  We will have daily visibility of each childs balance per miner.

Rule 2:
A public method will be set-up to allow random checks for any orphan sponsored by a miner by a third party auditor (IE a normal end user can check the balance of a child and call Cameroon and check the integrity of the childs status, to ensure the child is with BiblePay).  (This is similar to what we have with Compassion), so that it will be 100% provable that sponsored children through POOM are really sponsored to BiblePay. 


Payment Mechanics:

So that we can scale to the maximum,  I propose that the payment owed to the miner is converted to a daily amount, and awarded as POG points to the miner and paid from the POG GSC budget.  This is primarily so this POOM budget is friendly to our existing POG budget (in that people sponsoring children do not abruptly take over their own program budget but instead part of the POG budget).

Example:

John Doe, Miner 001, CPK 001, Sponsors Abraham, Cameroon One Orphan #ABC, for $40.00 per month.
Since this costs John Doe $1.33 per day, (and our wallet knows the current BiblePay Price thanks to QT), this is auto-converted to 4430 bbp per day (via the GSC contract), and this BBP is diverted from the Total daily POG budget (by converting to points) and added to John Doe's GSC CPK for the day.  (This reduces the available reward for the rest of the GSC participants).
(We can discuss a separate project for POOM, which GSC certainly supports, but imho it would be better to divert POG -> POOM, more on this tomorrow).

If total orphan payments exceed GSC rewards, they then start to be split equally among all participants.

Electric:

As everyone can see, this concept has a huge potential, because it has the effect of diverting normal mining rewards over to orphan sponsorships.

Unlimited BBP Potential:

One other effect that is less obvious, and I intend to create a model for this and paste my hypothesis, is that I believe if we open up the potential sponsorship of outside orphans (as proposed here, through cameroon one) with home users (miners), via USD payment, with the tax deduction (this was confirmed with Cameroon, that the payment is tax deductible) - received by the end-user, as the BBP is remunerated back, this cycle should technically have a very positive impact on our market cap and price.  This is because our mining rewards would change into pass-through rewards (IE reimbursements) for a certain percent of our emissions.  Yes, some pass through reimbursements would be liquidated immediately to cover the costs of the orphan, but I believe a certain percent would be held by miners (IE in a sense a tax-deductible buy-and-hold of BBP).

What makes this POOM concept an attractive configuration?

Currently I view BiblePays emissions flow as:
POBH - Security - 25%
Sanc rewards - 25%
GSC (Primarily Staking/Giving) - 35%
Governance Budget - 15%

As you can see, this is a very good configuration already, but with POOM, we can potentially divert some of the Staking revenue over to fully productive orphan reward payments.  And, if the test pilot works, once we have chain locks in place, we could also potentially move some of our security budget into POOM (Optional, depending on various factors).


Decentralization:

And one of the very obvious advantages in this idea is it decentralizes biblepay, allowing us to scale (as each home miner sponsors their own personal orphan using their own funds).













107
Great news!  ChainLocks passed testing at Dash and is now deployed to Dash-Prod, this means that for BiblePay, we will be adding ChainLocks to testnet over the next 30 days!

So we held back ChainLocks in prod for our Evo release, but we expect to test ChainLocks over the next quarter and schedule it in for our September release.  At that point, we would have all of the major features and be up to date with Dash's feature set.

It also means that we will have new opportunities to explore things like Proof of Orphan Mining, since it will be impossible to attack BiblePay with a 51% attack.


108
I would guess that we need EVO sancs for this to work on mainnet?

>exec price
{
  "Command": "price",
  "consensus_price": 0,
  "qt_phase": 0,
  "qt_prior_phase": 0,
  "qt_future_phase": 0,
  "qt_enabled": false,
  "cur_price": "0.000000000000",
  "BBP/BTC": "0.000000000000",
  "BTC/USD": 0
}

I know that we have tested a host of functions in TestNet. Which of these will be active at block 123,000, please?
1. EVO wallets & EVO sancs, for sure.
2. Heat mining. Will ABN be introduced and if so, what is that going to be set at?
3. QT?

What is the roadmap for the (re-)introduction of
4. exec join campaigns? POG? Healing? Proportion of the emission?

Maybe this was announced elsewhere but sorry to have missed it. Thank you.


I'll be posting this on the forum later today after I add some of the getting started links:

https://wiki.biblepay.org/Evolution_Upgrade


Please let me know if I didnt answer any of your questions or if you have any concerns that we are missing for the public.


109
I would guess that we need EVO sancs for this to work on mainnet?

>exec price
{
  "Command": "price",
  "consensus_price": 0,
  "qt_phase": 0,
  "qt_prior_phase": 0,
  "qt_future_phase": 0,
  "qt_enabled": false,
  "cur_price": "0.000000000000",
  "BBP/BTC": "0.000000000000",
  "BTC/USD": 0
}

I know that we have tested a host of functions in TestNet. Which of these will be active at block 123,000, please?
1. EVO wallets & EVO sancs, for sure.
2. Heat mining. Will ABN be introduced and if so, what is that going to be set at?
3. QT?

What is the roadmap for the (re-)introduction of
4. exec join campaigns? POG? Healing? Proportion of the emission?

Maybe this was announced elsewhere but sorry to have missed it. Thank you.

I'm going to add the heights to this new wiki page today, and post to the bitcointalk forum, but in the mean time:
Actually at 123,000 we do a very lateral move and nothing much changes, this is the height in which we expect people to start upgrading and running Evo and mining on Evo.  At 123,001 we retire classic governance sancs, and ask all the sancs to start upgrading to 4.5MM sancs - which I expect to take a few days.

So during the first 400 blocks or so, (after 123,000) its POBH as usual.

QT does require :  QT height to pass, and 4.5MM sancs to have quorums, so that wont start for a couple thousand blocks after the go-live (Ill give exact height in the wiki page).  So yeah it will be zeroes for a while that is actually normal.

The ABN Height and Anti-gpu height is also a couple thousand blocks in the future (after 123,000) - I will also add that height to the wiki today.


110
Thank you for the EVO update
Here are the results of  testing   EVO 1.4.3.1 on MAINNET

==================================================
Code: [Select]
>exec getcampaigns
{
  "List Of": "BiblePay Campaigns",
  "campaign HEALING": "HEALING",
  "campaign POG": "POG",
  "List Of": "BiblePay CPKs",
  "member [oncoapop2]": "BDpyRr2d9kWDD7MEyyJuAJxwvJpmLEGyqr",
  "member [[email protected]]": "BEv63xKxjAvZpQMCG2dzpLU7wTCcUhpRYd",
  "member [Heb]": "BQHKwoVx4bwN8ewJvvxFXsrYVBzcPTsqvM",
  "member [evo1.4.2.8]": "BTHqzzo9rRDHYNfXqQAEtua1iKxkQz7wya",
  "List Of": "Campaign Participants"
}


>exec join POG
{
  "Command": "join",
  "Results": false,
  "Error": "Unable to sign CPK BDpyRr2d9kWDD7MEyyJuAJxwvJpmLEGyqr (Private key not available)"
}

(I did not unlock my wallet; wallet needs to be unlocked as a transaction is sent in order for it to be registered on the blockchain)

>exec join POG
{
  "Command": "join",
  "Results": true
}

>exec join HEALING
{
  "Command": "join",
  "Results": true,
  "Warning!": "Please read this guide: https://wiki.biblepay.org/BiblePay_Healing_Campaign with critical instructions before attempting Spiritual Warfare or Street Healing.  Thank you for joining the BiblePay Healing campaign. "
}

(wait for about 10-15 min)

>exec getcampaigns
{
  "List Of": "BiblePay Campaigns",
  "campaign HEALING": "HEALING",
  "campaign POG": "POG",
  "List Of": "BiblePay CPKs",
  "member [oncoapop2]": "BDpyRr2d9kWDD7MEyyJuAJxwvJpmLEGyqr",
  "member [[email protected]]": "BEv63xKxjAvZpQMCG2dzpLU7wTCcUhpRYd",
  "member [Heb]": "BQHKwoVx4bwN8ewJvvxFXsrYVBzcPTsqvM",
  "member [evo1.4.2.8]": "BTHqzzo9rRDHYNfXqQAEtua1iKxkQz7wya",
  "List Of": "Campaign Participants",
  "campaign-HEALING-member [oncoapop2]": "BDpyRr2d9kWDD7MEyyJuAJxwvJpmLEGyqr",
  "campaign-POG-member [oncoapop2]": "BDpyRr2d9kWDD7MEyyJuAJxwvJpmLEGyqr"
}

===========================================
>exec sendgscc "This is a test to see what I can enter"
{
  "Command": "sendgscc"
}
Don't know how this is supposed to work on MAINNET without EVO sancs. So we would probably not appear on the leaderboard?

>leaderboard
{
  "Prominence": "Details",
  "Healing": "Diary Entries",
  "Prominence": "Totals"
}

=======================================
Minor fixes
1. Some extra boxes can still be found under the menu items:
>Help>Command-line options and PrivateSend info


Thanks, yes, I see we set up the sporks in prod, and you have been able to join the campaign successfully, cool.
Since we don't have any 4.5MM sancs set up yet this is probably a little premature for us to test, so lets try jumping on this around block 123,200 (this is 200 blocks after the May superblock pays).  Ill jump in and help at that time also.   By block 123,100 Ill have at least 5 sancs running in Evo mode also.




111
Maybe this is a bit premature as we don't have any EVO sancs on mainnet (see health) but leaderboard output only appears on the console/cli but not in the Winx64 GUI.

>exec health
{
  "Command": "health",
  "pam_hash": "0000000000000000000000000000000000000000000000000000000000000000",
  "pam_hash_internal": "000000000000000000000000000000004c10cf0f7b47a9a04a5dcbe59b528b76",
  "WARNING": "Our internal PAM hash disagrees with the network. ",
  "govobjhash": "0000000000000000000000000000000000000000000000000000000000000000",
  "Amounts": "",
  "Addresses": "",
  "votes": 0,
  "required_votes": 10,
  "last_superblock": 121380,
  "next_superblock": 121585,
  "next_superblock_triggered": false,
  "Healthy": false,
  "GSC_Voted_In": false
}

Yeah, that is OK, because we are checking for the Evo cutover height in that Gui area, so it populate 200 blocks after the cutover height (after 123,200).

I didn't forget about the last two posts, I will still address them.

(We are doing some testing on ChainLocks in the background and readying a new phase for TestNet).

We decided in IT to keep this thread going after the Evo go live to allow us to test everything Dash has been working on in 0.14+ that won't make the BiblePay-Evo release deadline.



112
Set up of EVO on mainnet on pool. May be config is incorrect?

  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "POOL DOWN-REVERTING TO SOLO MINING; POOL DOWN-REVERTING TO SOLO MINING; POOL DOWN-REVERTING TO SOLO MINING; ",
  "gsc_errors": "",
  "poolmining": false,
  "pool_url": "https://pool.biblepay.org/",
  "required_abn_weight": 0

Config:
#Turn ON to mine
gen=1

# Pool Mining
pool=https://pool.biblepay.org/
workerid=oncoapop




Hmmm, try taking off the trailing slash on pool.  I see you created the workerid.


I will also reply to that last post asap.



113
Archived Proposals / Re: Restarting BLOOM Sponsorships - Uganda
« on: May 23, 2019, 09:53:59 am »
Thanks for the feedback. Since those 4 are covered until July (I think I must have misunderstood something in regards to them being covered until then), and there are still ample charity funds available for June, could we add about 5 kids kids to be covered in June, and then pick the most needy 2-4 in July depending on budget for an ongoing monthly sponsorship?

We still need urgently need sponsors for Sharon, Sylvia, Edrine and then 2 others who lost their most recent sponsor. They are Paul and Sarah.

As of now, we don't have any non-boarding sponsorships as we reunified all of our Sierra Leone orphans with foster or extended families. I could see if there are some kids in need in Haiti, our most recent country program we have added.

I believe all these kids in Uganda need boarding, but I'll double check with Sarah in case there are other kids who don't need boarding. If they don't, their sponsorship is $55/month.

Please let me know your thoughts tonight if you can, as I'm heading out of the country in the morning for 2 weeks and won't be able to submit a proposal.

Thanks!
April

Ok, thanks.
The primary issue we have in this environment is we have 79 total kids at about $40 per month average, and each month we bring in about 70% of our required funds (IE we are still shrinking) - so any child we add with boarding will mean we must cancel 2 of our compassion children to pay for that child (because we do not have the monthly funds currently to meet our *current* needs).

So I would really ask the community, should we sponsor a child with boarding needs and cancel two of our current children, or should we keep the kids we have?


114
I was using 1429 because I didn't know that there is new version. I didn't found any mention about new version here ;)
Now I have 1431 and here are my answers:
A) Yes, I agree 1.4.3.1 has no extra boxes in the About page
B) I've got a message from my antivirus (Avast) that the file is clear and it's working good now
C) That debug.log is still there. BUT  this debug.log is not in %appdata%. It's in install DOC folder. Here is a screenshot: https://prnt.sc/nrhg7t This file is from end of the March and here is the beginning of that file:
Code: [Select]
2019-03-29 16:54:05 BiblePay Core version 1.4.0.5
2019-03-29 16:54:05 InitParameterInteraction: parameter interaction: -externalip set -> setting -discover=0
2019-03-29 16:54:05 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2019-03-29 16:54:05 GUI: QCssParser::parseHexColor: Unknown color name '#grey'
2019-03-29 16:54:05 GUI: QCssParser::parseHexColor: Unknown color name '#yellow'
2019-03-29 16:54:05 GUI: QCssParser::parseHexColor: Unknown color name '#grey'
2019-03-29 16:54:05 ***************************************** BIBLEPAY  ***************************************************
2019-03-29 16:54:05 ProdMode: Prod 0.000000BiblePayVersion 1.4.0.5 (BiblePay Core)

It's nice that the BiblepayEvo insttall file is on main page. But I have question for Ubuntu packages. Will they be ready on Evo start? Will be there any changes in repository or the ppa:biblepay-official/mainnet remains the same? Because I'm using packages for my VPS and it wouldn't be fair to be in a disadvantage :)

And I have another wish :) It would be nice to have smart contract reward txs on wallet main page Recent transactions list, because now they are only in tx page.

Hi Orbis,

Yes, your right, I forgot to tell everyone to test 1.4.3.1, good point.  The only new feature we didnt test here was 'leaderboard'.  1.4.3.1 will also show your individual diary entries (or all diary entries).

So yes - I found that log, good find.  It will be removed in 1.4.3.2.

On that GSC rewards being enabled to be on the overview page Recent, could you please add a github issue to the new evolution branch? 

So on our RPM releases, good news and bad news.  So MIP makes the RPMs normally, but we have an issue- one of the third party components in dash-evo will not build in an RPM (its an upstream problem actually).  So here is our plan:  We will compile and release MacOSX, Win64, Win32, Ubuntu16, and Ubuntu18 binaries and deploy all of them to the web site.  So the main thing we are missing is the ability to use a PPA on linux.  We expect to have this resolved within 90 days however but its a complicated problem and MIP is actively researching it. 

Ill post when I have some more builds ready so we can verify the debug is gone.


115
Hi,
after few days I'm back and I'm testing 64bit WIN version.
It's working good, but I've had problems with install.
My antivirus report it as Dyna:BitcoinMiner-CR [PUP]||mul and moved it to Virus vault.
But after set it as "trusted" it works good, mining and GSC is working good.

And maybe I found some bug.
There are Book and Chapter option in "About Biblepay Core" window, but they aren't working.
I cannot choose anything from it and it's empty.

And Rob you still didn't remove those old March debug.log from WIN install file and it's still more than 60MB big :)

A) Testing the latest version, I click Bible | Read Bible, click a book and chapter and I see the contents, so I do not see a bug here.  Please be sure you are testing 1.4.3.1.  EDIT: 1.4.3.1 has no extra boxes in the About page - please re-test.

B)  Antivirus:  This is common with cryptos that have miners - the algorithm makes a false positive for that section, however the scan will eventually return negative once we have more than 100 downloads, so this should be solved (just like our prior versions of biblepaycore.exe).

C) On the log, I don't believe we copy the installer contents to %appdata%, are you sure this debug.log is not your log, could you please delete it and reinstall our EXE and see if we write it again?  If we do, Ill do a more in-depth search to see how we could have left that in our build process - Im 50-50 on this, could you help us by checking?  EDIT:  Please be sure this installer is the 1.4.3.1 installer.  I cleaned up the build directory before building 1.4.3.1. 
    EDIT:  I just tested 1.4.3.1 windows install - we don't write the debug.log to the %appdata% directory - please test again.


EDIT:  One thing I didn't explain, I've been deploying the 1.4.3.0+ versions to:
https://www.biblepay.org | See the top level Downloads Menu | Evolution downloads

This might be the problem.





116
Archived Proposals / May compassion recurring sponsorships 2019
« on: May 20, 2019, 01:06:40 pm »
We currently sponsor 55 @ $2090 per month.

Requesting 3.22MM.


117
Thank you for your acknowledgement! Glad to be part of this project and the community of believers in Jesus and hence happy to help in this small way!

The UI is great and, as far as I can tell, installs and runs on Windows 10 64-bit (I needed to addnode my own classic sancs for it to find the block source) and it took quite a while to load from scratch. I have currently got it mining on the pool
http://www.purepool.org/main/miner/BFwWN5ohJLcUAn1H9urqUqaA9oqPUBJtbh/

The first one (1.4.2.8 EVO on mainnet compiled in Ubuntu 18.04) is still crunching
http://www.purepool.org/main/miner/BD9gmJ5vmPJtDewo9NyqUT7fJQgV39AW7R/

There appears some typos under "JESUS' CONCISE COMMANDMENTS"
Pure and undefiled religion before our God and Father is to care for orphans and widows in their distress, and to keep oneself from being polluted by the world. (John 1:27) - ref is actually James 1:27

Do not Store up Treasures on Earth where moth and rust destroy, and where thieves break in and steal, but Store up treasures in heaven, For where your treasure is, there your heart will be also. (ref is missing - Matt 6:19,20a,21)

The "Help - About Biblepay" Tab has some unnecessary boxes at the bottom of the screen.

Ok, I fixed the bad bible reference and added the other reference.  Good find on the About page, that was pretty ugly.  Fixed.
These changes will be in the next release (probably tomorrows release).



Good point on setting up the POG & Healing campaigns in prod; I will set those up ASAP and we can at least join and see if they appear to be initialized.  We cant really test more on that yet until the GSC height passes (123,200) and we have some 4.5MM sancs running in prod (more than the min_quorum of 10 set up).


118
Loading from scratch, and seed node not found in prod-evo.


So I thought I would address these two issues separately:

1.  The loading from scratch is a little slow right now, but Evos block loader is different than classic.  Note that once the supermajority is on evo, Evo will actually transmit compact blocks (compressed) using more than one thread, so that should speed up the time for people syncing from zero at that time.

2.  Regarding being unable to find the seed node, I confirm that due to my current Evo expirimentation being on dns1-dns3, Ive caused most of the prod evo seed nodes to be down - it should not be affecting biblepay-classic however because we have more in classic.  Im currently fixing the problem, once we have those 3 up again this will be mitigaged - note that as long as an Evo node can find 1 node, it will immediately pull in the other "friends" and start syncing, so Im sure this will be resolved also.

3.  In the near future, probably around Thanksgiving, we can also create snapshots.  This will allow someone to sync in about 5 mins using a zip file and a couple clicks to get it bootstrapped (we might need a button in the wallet to make it easy to download the snapshot).


119
************************************************************************

                      THANK YOU ALL FOR TESTING BIBLEPAY - EVOLUTION

************************************************************************


Let us pray this version is the most stable and beneficial version for our Orphans and God's Kingdom.


Testing is not completely over, but I wanted to send a warm thank you to everyone who contributed in any way in this TestNet thread!



God Bless you All!


120
Thank you for your acknowledgement! Glad to be part of this project and the community of believers in Jesus and hence happy to help in this small way!

The UI is great and, as far as I can tell, installs and runs on Windows 10 64-bit (I needed to addnode my own classic sancs for it to find the block source) and it took quite a while to load from scratch. I have currently got it mining on the pool
http://www.purepool.org/main/miner/BFwWN5ohJLcUAn1H9urqUqaA9oqPUBJtbh/

The first one (1.4.2.8 EVO on mainnet compiled in Ubuntu 18.04) is still crunching
http://www.purepool.org/main/miner/BD9gmJ5vmPJtDewo9NyqUT7fJQgV39AW7R/

There appears some typos under "JESUS' CONCISE COMMANDMENTS"
Pure and undefiled religion before our God and Father is to care for orphans and widows in their distress, and to keep oneself from being polluted by the world. (John 1:27) - ref is actually James 1:27

Do not Store up Treasures on Earth where moth and rust destroy, and where thieves break in and steal, but Store up treasures in heaven, For where your treasure is, there your heart will be also. (ref is missing - Matt 6:19,20a,21)

The "Help - About Biblepay" Tab has some unnecessary boxes at the bottom of the screen.
Wow, well thank you very much kind sir!  I'm also impressed that you have created your own domain with notes.
Do I know you from anywhere or did you just recently find BiblePay?

Thats great the build is working on Win10; thanks goes to Dash for ensuring the base is cross-windows compatible (I mean registry and c++ pinvoke calls etc).

Thats awesome the two miners are still working, I did look at your first miner a couple times and that was very valuable for us.

Ok, let me fix these typos right now.  Good catch on the John 1:27, interesting.

I'll look at the unecessary boxes now also.

Thanks a lot for all your help btw, it was instrumental in creating a quality product!


Pages: 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 ... 134