Topics

61

Archived Proposals / POOS Testnet Thread (Proof of Orphan Sponsorship - Sanctuaries) - September 2020

« on: July 19, 2020, 07:02:25 PM »

September 2020 Release


Welcome to the Biblepay September 2020 Testnet Testing thread for POOS!


In this thread we will be testing:

- POOS (Proof of Orphan Sponsorship):
     Verify the Sanctuary Owner may Sponsor a Cameroon-One Orphan (by associating this Orphan with the Sanctuary public key)
     Verify the legacy POSE ban system still POSE bans a node for lack of service
     Verify the POOS ban system will increase the ban for non-paid orphan accounts
     Verify the POOS ban system will decrease the ban once the orphan is paid for
     Verify the sanctuary cannot revive itself unless they pay the amount owed first

- Coin-Age voting:
     Verify you can vote from the Proposals UI by right clicking a proposal and voting with coin-age
     Verify you can increase the default (configurable) coin-age percentage using the biblepaytest.conf key value
     Verify the voted tally shows the correct coin-age and distinct sum of users who voted
     Verify we can vote with coin age from the RPC

- ChainLocks and DIP0008:
     Verify that testnet LLMQ quorums are forming, and advancing
     Verify testnet LLMQ locked IX transactions occur automatically, and quickly (IE test autolocks)
     Verify chainlocks locks the block (getblock hash, verify when entire block is IX locked, then it is also chainlocked)

- APM (Automatic Price Mooning)
     Verify the subsidy is 7 if an APM decrease event occurs day-over-day
     Verify the subsidy is normal if the price is unchanged, or if the APM increase event occurs day-over-day

- DWS (Dynamic Whale Staking)
     Verify the 'dws' and 'dwsquote' commands work as dedicated commands.

Additional Testing for BiblePay Unchained - added on August 6th:
First, read this guide:
https://wiki.biblepay.org/Using_Unchained


- BIPFS (Biblepay IPFS)
     Test exec bipfs_file (Upload a file into unchained).  Once the file is uploaded, verify the price, the duration, the density, and that you can navigate to the URL.
          (Verify both large and small files).
     Test exec bipfs_folder (Upload a folder into unchained).  Verify the price, duration, density, and a few URLs from the upload.
     Test uploading an encrypted file, retrieving the encrypted file (with exec bipfs_get), and re-opening the encrypted file.  Test it with a bad password also.
     Test exec bipfs_get (Download a file).
     Verify the sidechain sync height (Info Sidechain Sync Blocks).
     Verify bipfs_list (the uploaded file is now in the sidechain).

- BIPFS C# Client
     Test file upload and folder upload in the c# client.  Verify the file density, duration, and URL result, and download the asset from the URL.
     Verify the charge amount and the TXID was charged to the payment source (via API-KEY method).
   
- DWS UI
     Verify you can make a DWS burn from Send Coins Entry (these burns are always 90 days).  Verify the Quote works.


- Verify Monthly Budget changes:
     Verify as of block 55720, the sanctuary payout is 8.75% higher and the monthly governance budget is 8.75% lower











NOTE:
Most likely you will need to recreate your sanctuary, unless you see your sanctuary is POSE banned.  In that case you can revive the sanctuary with 'exec revivesanc'.


Starting Version:    1.5.1.7+


(Please ensure your version is greater than this, otherwise your testnet branch will not sync. 

We are at block  ____52500_____ as of July 21st, 2020).

BlockHash:
getblock 52500   "hash": "12287aa66bb3e29c354b276aa1738efcf93ea031c8b57d9e17ea6242252604f1"



Testnet Download Links:


Ready:
     Windows 64-bit:      https://biblepay.org/biblepayevo64develop.exe
     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


To self compile:
https://github.com/biblepay/biblepay/blob/develop/BuildBiblePay.txt





CONFIGURING FOR TESTNET:

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

Place the file in ~/.biblepay



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

(Note the blocks and chainstate will sync into the ./biblepay/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

__________________________________________________________________________________________________________________________________________________________________________________________

62

Discussion and Suggestions / BIBLEPAY Wishlist

« on: July 15, 2020, 09:38:33 AM »

The purpose of this thread is to post features that you would like to request (or verify the possibility of creating) within:

BiblePay Core Wallet
Foundation.Biblepay.Org (Gospel or Pool features)
Mobile Wallet

Some examples:
A groundbreaking idea
A feature that another coin has (for example, a feature you found in the top 50 coins that we don't have)
A workflow process that would clearly provide value (example:  our Add a New Proposal page)
A gospel feature (such as our prayer request or video list etc).

Bugfix requests should still be entered as github issues here:
https://github.com/biblepay/biblepay/issues

63

Archived Proposals / Should Sanctuaries fund our Orphans?

« on: July 01, 2020, 03:44:09 PM »

I am investigating the future scenario where we require each sanctuary to fund a single orphan in order to be a paid sanctuary.

This partially comes from the complaint that our Sanctuaries are only in name only (IE, why are they called sanctuaries -- if they are nothing more than masternodes -- and they dont do anything for us?).  Why do they sit and receive rewards for doing nothing?

(I was under the impression earlier in our launch, that we would create some type of workflow, and have sanctuaries perform something fundamental, such as entering expenses or liquidating orphan funds, but in reality we never did establish a workflow like that.  I argue that making a sanc responsible for one orphan may be the key to that self enforcing workflow).  A sanctuary could be a 'safe haven' for one child.
The sanctuary purpose is to sponsor a child, write letters back and forth (if possible), and provide due diligence for our other charity endeavors.

One disappointment I currently have with the sancutary ecosystem is these investors seem to be detached from our project (I feel as if Im the lone decision maker when I vote on issues).  I would personally rather see votes originating from people with 'skin in the game' and those same people are technically the ones who care about the children.


One other problem with our current sanctuary setup is we have 250 sancs that have to pay for hosting.  Id rather see 'sancs who sponsor orphans' pay for hosting.  In that model, you gain a lot of efficiency - meaning that we have less infrastructure overhead.  (If we really do intrinsically grow then yes we have more hosting but we also have more children being supported).

So of course the pro to this idea is those that sponsor orphans will be the ones who make sanctuary ROI.

The main downside to this idea is more investor friction (harder to do things like fractional sancs).  But I argue also, that this can be addressed quite easily by modifying our turnkey fractional service to include orphan sponsorship costs.

So let me summarize what this proposal would entail:

- Each sanctuary will be required to sponsor one cameroon-one orphan
- If a sanctuary locks coins and does not sponsor an orphan, they will eventually (over 24-72 hours) get POSE banned, meaning their payment income will stop.
- If a sanctuary is in good standing (IE they do sponsor an orphan) they will not get pose banned.
- Cameroon-one will be required to paste the masternode public key inside each sponsored child BIO (which is hosted by them).
- If the sanctuary masternode pubkey is not in the bio, this means the sanctuary will be POSE banned.  Or, if the sanctuary stops paying for the child, they will be POSE banned after they fall in arrears more than 30 days late.
- Cameroon-One will remove the public key from the BIO if the account is overdue by more than 30 days.
- The Sanctuary will link themself to an orphan by typing a command in the wallet. (Or cameroon-one will add new bios in the wallet by persisting new bio-ids with pubkeys).  Either way, this will give our sanctuaries insight into checking the pubkey-bio pair during each POSE round.
- Rob would modify the foundation web site to accommodate fractional sancs with orphans attached.  Another words, investing in a fractional sanc would need to have a reward component and a cost component (the sanctuary reward minus the cost of the orphan / 30).  This would give us an "inroad" to maintain fractional sanc investors.
- We will test to ensure no more than 50% of the network can be POSE banned at a given time (this is in case a disaster scenario occurs, where Cameroon One is down and the internet is down, this means our sancs will not pose ban more than half of the network).

As far as what this looks like for investors after this potentially goes live, I believe we would see the sanctuary count drop to 40 or so.
Then the ROI for a sanctuary would be astronomical (IE 500% per year) simply due to the lack of participation.
Making it very enticing to sponsor a child and have a sanctuary (at first).
Of course, if you plot this on a graph you would see a sweet spot (where ROI is 100% per year or so) where the sanctuary count would settle on (maybe 75 sancs?).

(I dont mind making a graph later and posting it to show the effect).
But the point is, this idea does appear to offer a high scalability effect for child sponsorships.
Meaning that if we remain small we will be paying for 40-50 children organically with a low sanc count, and if we grow, obviously we have the ability to sponsor 1000-2000 if we were to take off to half of the size of Dash (who has 4,500+ masternodes) or even 10% of the size of dash based on economics.

64

Archived Proposals / Donate three water wells to villages in Pakistan

« on: June 28, 2020, 06:25:01 PM »

I ran across this project today while I was looking at clean water projects.
It struck me as cost effective for such a big impact (IE helping 200 people in a village per distinct well over a long period of time).

https://www.paaniproject.org/donate

Please check it out and let me know if there are any red flags.

Otherwise I propose that we donate two ($600) wells (for a total of $1200) to help 400 people get water.

I am seeking 6MM bbp for this project.  If there is any deficiency, I will cover the difference.

I will also donate at least one more well on top of the BBP funding (so we can do 3 wells with funding for 2).

EDIT:
We have 6.3MM in the foundation treasury.    I propose we use 6MM of those funds for this project.
I will still enter a sanctuary proposal, this way we can see if it gets upvoted first - but we will not need to use governance funds for this.)


EDIT 2:
It looks like we can have a well named after BIBLEPAY, and they will send us 20-30 pictures of the work!
https://closeup360.com/news/lakers-lebron-james-water-well-named-pakistan/


We will definitely request this!

65

Archived Proposals / Vote on Future Currency Name II

« on: June 20, 2020, 10:08:12 AM »

First I would like to say that switching our currency name from BiblePay to DAC is in the spirit of growing the community and not blocking potential users who might view us as overly religious.  We are not doing this in any way because we are ashamed of the gospel; but instead to appeal to a broader cross section of the world first.

We can still keep the bible in the wallet, and spread the Gospel of Jesus in certain specific areas (such as the doctrine section of foundation.biblepay.org) if we re-brand.

Anyway, Jesus said the Gospel is for those who are sick and or in need (not for those who are already saved and sealed).

In our last vote, our community strongly gravitated towards re-branding in contrast to having dual brands.  One of the old questions was: Should we keep both biblepay and DEC, and the supermajority felt it was not a good idea to maintain two brands. 

The supermajority liked DAC more than DEC also (hence why I have more choices up above for variations of DAC).

In light of that, this vote attempts to hone in on the recommended currency name (and see if the idea is maintained).

There are 3 tiny coins with the ticker DAC already:  Davinci Coin and DACash (DAC) and DACC - Decentralized accessible content chain (DACC).  I think what we would do is hold a separate vote for the ticker.  We could possibly make the ticker XDAC  (none are taken like that) or DACBBP.     So for example:  We would be Digital Autonomous Currency (XDAC).

I prayed about this decision and I'm not receiving any negative response about switching from BIBLEPAY, but I don't want to influence the voters, so please vote.

Finally on the Charity vs Non-Charity debate, during the last vote more people voted for autonomous currency than autonomous charity.  This is another case of keeping ourselves generic (and not pegging us to the stigma that we spend all the investors money on charity or that the price will always go down because its all spent on aid etc). 

If anyone has a variation that is even better please post it and Ill consider adding it to the list.  We own dac.ngo, dac.ong, dec.app, and coin.ngo.  I kept coin out of this because I believe its just too generic compared to dac and dec.

66

Archived Proposals / Add new charity partner - SAI.NGO

« on: June 10, 2020, 05:30:46 PM »

I had four telephone calls with Stephen, president of SAI.NGO.

I explained our mission, and how we were seeking a cost effective orphan provider, potentially below $38 per month.

We have come to an agreement to sponsor orphans at a rate of $20.00 per month, who are orphans from the streets in Venezuela who lost both parents. 

The orphanage they stay at is primarily receiving more donations for animals and veterinarians than humans at this time.  The caretakers they have are sometimes only veterinarians, who are already receiving wages from SAI to care for animals.  In this agreement, they take in the orphan and our sponsorship allows SAI to buy local food (locally sourced flour, sugar, etc at local rates) and bring it in.  They are both government audited and guidestar certified.

We have received the first 10 orphan bios: (filter by SAI.NGO):
http://foundation.biblepay.org/SponsorOrphanList

Additionally we received help on this endeavor from Costa82, who actually lives in Venezuela and is going to do additional due diligence in this matter to ensure the beneficiares receive all of our gifts and will update us with any red flags.

SAI GUIDESTAR rating:
https://www.guidestar.org/profile/81-1747993

SAI website:

https://sai.ngo

I asked Steven for a study that their org has created for one of his large donors that proves the transactional chain between donation and beneficiary; they have one available in PDF format:

** Integrity & case studies provided by SAI **:

Animals:

https://sai.ngo/wp-content/uploads/2019/11/Animals-SAI-.pdf

Orphans:

https://sai.ngo/wp-content/uploads/2019/11/SAI-Brochure-1.pdf

https://sai.ngo/donor-advised-funds-donations-daf-venezuelan/

67

Archived Proposals / Approve Budget Changes

« on: April 30, 2020, 09:17:07 PM »

In the first month of RandomX mining (April 2020), we raised approx. 1.90 XMR.
Due to the success levels of RX, I propose the following changes to our reward structure for each heat mined block:

- Retire POOM as of June 2020 (remove listchildren, cancelsponsorship, sponsorchild)
- Free up the daily GSC budget spent for POOM (240K per day, 35% of the GSC budget)
- Allocate this 240K per day into the heat mining reward (raising the heat mined reward from 2400BBP to ~3500bbp)
- Do not increase the Sanctuary reward (instead maximize the RX reward)

Part II (DWS - Dynamic Whale Staking):

I feel that DWS was very successful, and it was grabbed relatively quickly - even with the last adjustment.  I feel it gives us a fighting chance to allow outsiders to buy up the SX free coins.

I propose these changes:
- Double the DWS available emission level, so more burns will be available
- Increase our deflation rate to pay for the new level
Specifically, we would change the GetAnnualDwsReward level from .325 to .64, then we would increase our deflation level in GetBlockSubsidy.

68

TestNet Discussion Archive / June 2020 BiblePay Mandatory Upgrade - TestNet

« on: April 30, 2020, 05:16:11 PM »

June 2020 Release


Welcome to the Biblepay June 2020 Testnet Testing thread.


In this thread we will be testing:


- 'exec price' : XMR price has been added
- Sanctuary Voting :
     (This is the ability for a sanctuary to vote on a spork, and if the Vote outcome is a PASS, the spork will go into effect.  If it is a FAIL we need to see this spork fail to enter into the chain).

- Anti-Censorship-Feature (ACF)  - Although I went through the pain of coding this, releasing it and testing it, I have decided that (as I believe we as a community) will be better off with BiblePay unchained for this use case (as it is safer and does not risk bloating the governance system and the nodes).  So for safetey reasons, I have removed this and now am planning on releasing the design for Unchained.  (This is a sidechain that holds documents off-chain).

- Removing "BiblePay-Evolution" from the windows wallet and fixing the default program directory name (it is still Evolution).  This should go back to BiblePay.  Check to see if the windows installer wizard is correct.

- Test a VendorList change (Charity monero addresses in a semicolon delimited list) and a PoolList change (allowable RX pools).

- Remove POOM from the wallet (remove poom listchildren, poom pay).  Move POOM payment budget from GSC to Heat mined blocks.  Ensure these heat payments go to the heat side and not to the sanctuary.  I believe POOM causes the GSC budget to drop by 240K per day, and the mined block subsidy to rise by 1200~, and the sanc payment should stay the same.

- Any Dash changes that occurred between Jan 1,2020 and March 30th?  Ask MIP?  MIP has made me aware we need a little more time to move up to .15, because Dash has changed 1800 files!  So lets shoot for releasing .15 in September.

- The ability for a RandomX hash to be mined in a more RX compatible way (check to see if foundation.biblepay can receive a blakehash as Solution #1) (This is just a reminder note that may result in a code change in the core wallet if this streamlines the xmrig code to be 100% compatible with the xmrig branch), Checking this.  (This basically frees us from maintaining a special version of xmrig).

->  Great news, I tested pure merge-mining using the plain vanilla xmrig, and it worked.  The changes are in this version already.

- Test Marcus Antonios Russian and Ukrainian Bible viewer(s)


Starting Version:    1.5.1.0+


(Please ensure your version is greater than this, otherwise your testnet branch will not sync. 

We are at block  ____37650_____ as of May 1st, 2020).

BlockHash 37650:
573935383afc18055f0207355e49262a4243db5705d019506aac153eba5c503e


Testnet Download Links:


Ready:
     Windows 64-bit:      https://biblepay.org/biblepayevo64develop.exe
     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


To self compile:
https://github.com/biblepay/biblepay/blob/develop/BuildBiblePay.txt


Retiring (do not use these downloads):
     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






CONFIGURING FOR TESTNET:

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

Place the file in ~/.biblepay



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

(Note the blocks and chainstate will sync into the ./biblepay/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

__________________________________________________________________________________________________________________________________________________________________________________________

69

BiblePay Current Discussion / BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

« on: April 10, 2020, 12:43:05 PM »

WEBSITE | GITHUB | TEAM | ROADMAP | WHITE PAPER

FORUM | TWITTER | REDDIT | DISCORD | FACEBOOK | TELEGRAM

Language Translations



RandomX merge mining provides miners with two revenue streams, while preventing GPUs and ASICs

Launched July 23rd 2017 by Rob Andrews, with no premine and no ICO, BiblePay describes itself as a decentralized autonomous cryptocurrency that gives 10% to orphan-charity (using Sanctuary (Masternode) governance).  The project is passionate about spreading the gospel of Jesus, having the entire KJV bible compiled in its core wallet.   BiblePay (BBP) is deflationary, decreasing its emissions by 19.5% per year.

The project views itself as a utility that provides an alternative method for giving to charity. With Generic Smart Contracts, the project seeks to become the go-to wallet for Christians. In the future, the team intends to lease file space on its Sanctuaries and release corporate integration features, such as C# access to the blockchain. The BiblePay platform is a derivative of Dash-Evolution. Located in Dallas, TX, the team seeks to help orphans globally. The roadmap can be viewed at: wiki.biblepay.org/Roadmap

Interview | Podcast | Youtube | Medium | Steemit | Newsletter




Accomplishments:

- $220,000+ donated to Charity!

- 30,000+ years CPU time donated to Cancer Research!

- Sponsoring 100+ Orphans every month!

Overview:            Nutrition Information      Dimensions      BiblePay Evolution

New Features: Generic Smart Contracts (GSC) Proof of Orphan Sponsorship (POOS)

Utility:

DashPay - Instantly Buy Gift Cards with BiblePay (using Dash, InstantSend and Bitrefill)
wiki.biblepay.org/DashPay_RPC





Theology:

Left Behind Letter (for those that missed the rapture):           https://san.biblepay.org/Theology/Left%20Behind%20Letter.pdf




Download Wallet:

biblepay.org/wallet


(How to update and clean wallet?)



      

(How to verify Hash)

Windows 64 bit - biblepay.org/biblepayevo64.exe (Hash)


Mac OSX - biblepay.org/biblepaycore-evo.dmg


Linux GUI 64 bit - biblepay-qt-evo-x86_64-pc-linux-gnu.tar.gz  (Hash)

Linux CLI 64 bit - biblepayd-evo-x86_64-pc-linux-gnu.tar.gz  (Hash)



Source Code - github.com/biblepay/biblepay/blob/master/BuildBiblePay.txt


Paper - biblepaywallet.github.io


Mobile Wallet:

Android -   https://www.biblepay.org/wallet/

iOS - https://www.biblepay.org/wallet/


Mining Guides:


Proof of BibleHash
wiki.biblepay.org/POBH_Setup

Mining Pools:

• Foundation.biblepay.org:  https://foundation.biblepay.org/GettingStarted
• Miningpool.fun:  https://bbp.miningpool.fun/GettingStarted

MiningPoolStats
miningpoolstats.stream/biblepay


Earn Coins:

FreeFaucet.io:
freefaucet.io/claim/index.php?coin_name=biblepay&faucet_key=freefaucet18&claim=Claim

SouthXchange Faucet:
southxchange.com/Balance/Faucet

Healing Campaign (Diary Entries):
wiki.biblepay.org/BiblePay_Healing_Campaign

Bug Bounty Program:
forum.biblepay.org/index.php?topic=408.0

Request Funds from Monthly Budget Proposal System for your work:
forum.biblepay.org/index.php?board=5.0


Exchanges:

coinmarketcap.com/currencies/biblepay/markets/

coingecko.com/en/coins/biblepay/trading_exchanges#panel

• SouthXChange
• Vindax

Whitepaper:

• English
• German
• Chinese

Explorers:

• Chainz Explorer
• explorer.biblepay.org

Partners/Aggregators:

• Coin Lore
• Coin Data Flow

Specifications:

Launched: July 23, 2017
Algorithm: Proof of BibleHash (POBH)
Mining Strategy: CPU only (GPU/ASIC Resistant)

No Premine / No ICO

Block Target: 7 Minutes
Blocks Per Day: 205
Transaction Speed: Supports InstantSend

Max Supply: 5.2 billion BBP by year 2050

Circulation Characteristic: Deflationary
Emission Rate: -1.5% every month (19% per year compounded deflation)

Emission Schedule:
wiki.biblepay.org/Emission_Schedule

Economics:
wiki.biblepay.org/Economics


Block Reward:
https://www.biblepay.org/#Technical%20Details


Sanctuaries (Masternodes):

To reduce sell pressure on our currency, our sanctuaries now sponsor one orphan each (provably), in accordance with our POOS (proof-of-orphan-sponsorship) algorithm.

Additionally, we now liquidate raised XMR (raised through XMR-BBP merge mining) for our remaining charity expenses.

Governance & Budget System: - Understanding Governance                                                                     Collateral Requirement: 4,500,001 BBP	Statistics: - Masternodes.Online - Masternodes.Pro - MasterNodeCap - Masternode.Live - Masternodes Buzz
Setup: - Step by Step Guide - One Click Install Script - Upgrade Deterministic ____________________________	Monitoring: - NodeCheck.io

Charity:
**  We only partner with charities over 75% efficient, meaning over 75% reaches the beneficiary. **

 



Accountability:
- accountability.biblepay.org
- Public Investigation


Social:

Forum      - forum.biblepay.org
Twitter     - twitter.com/BiblePay
Reddit      - reddit.com/r/BiblePay
Discord    - discordapp.com/invite/yWgbKdM
Facebook  - facebook.com/BiblePay
Telegram  - t.me/biblepay_airdrop

            


CAUTION: "Although BiblePay has a deflationary emission schedule, there is no guarantee of positive investment returns against other major inflating currencies. Past returns are not indicative of future results. We are a utility and not a security. Please do not invest in BiblePay unless you know all of the risks of cryptocurrencies"


Original Announcement

2nd Announcement






White Paper Links:

Chinese White Paper - https://san.biblepay.org/Mission/BiblePay_WhitePaper_Chinese.pdf


Forum Rules:

1. Do not make assumptions or false statements - For example, if you are not 100% sure of a statement being fact, you must state "in my opinion... " or "I believe...", especially with technical posts that could mislead investors. 

2. Talk in a nice tone and manner, be polite and appreciative.  Avoid swearing.

3. Be willing to do work/research/experience, or Find someone who can, and assume other community members are busy.  This is a group effort.

4. Moderators may delete your post if you are argumentative or make mean spirited posts.

5. If you have a problem with the mod team or an official member of the dev team, you must post with an innocent until proven guilty attitude.  The devs aren't out to get you. If you do not receive a response, break the problem up into a simpler problem and post the question again with a positive attitude.

6.  Your primary purpose on this forum is to help others and make constructive posts.  If you are a net negative to the community we reserve the right to delete or report the posts to bitcointalk mods.

7.  Do not post anything that misleads investors.  Proofread your post before posting as it cannot be deleted for 24 hours.  If you are not sure, ask someone else first.

8.  Your posts may be deleted or you may be banned from this thread if you have a history of making offensive posts.

9.  After 3 offensive posts your future posts and/or your account may be banned at the sole discretion of one of our forum administrators.

70

Archived Proposals / Would you use a Fractional Sanctuary Investment Service?

« on: April 02, 2020, 04:26:24 PM »

Would it be useful for us to create the ability for a user with not enough collateral (to host an entire sanctuary (4.5MM)) - to instead, be able to invest in a fractional share of a sanctuary on foundation.biblepay.org?

The fractional share would pay dividends back to the hodler's based on the fraction invested.

The foundation would do this for a tiny fee (IE, probably barely more than the price of hosting).
The pro would be we could attract more outside investors into biblepay.

I believe BBP would also be able to maintain the sanctuaries, so this is  not only a turnkey hosting service but also a fractional share service.

I think if we do this we will add higher security to foundation.biblepay (2FA) and cold wallets, then I will feel better about hosting this, that is if we decide to schedule this in.

According to MNO an investor makes 45% for HODLING:
https://masternodes.online/currencies/BBP/

So if we can make this as easy - turnkey - as possible, this would be an avenue for HODLERS , or non techni grandmas, who want cryptocurrency exposure to invest where Dynamic Whale Staking failed to have the full resources available for them.

71

Archived Proposals / RandomX Giveaway for New RandomX Miners

« on: March 23, 2020, 02:27:03 PM »

***** New RandomX Welcome Gift to onboard new RandomX Miners - now 33,000 BBP ! *****



To claim the faucet reward:

1. Create an account here at our forum (forum.biblepay.org).
2. Change your profile picture to either an avatar or your picture.
3. Download and sync biblepay (v1.5.1.4+).  NOTE: This must be the DESKTOP version of biblepay, not the cell phone version.
4. Click Tools | Information | Console     
       From the RPC console type : faucetcode
5. Paste the faucet code in a post here in this thread, along with your country.
     (Optionally read more about biblepay and salvation at foundation.biblepay.org.)
6.  Start mining against foundation.biblepay.org with randomx, so we can see your address in the leaderboard.
**** BE SURE TO MINE FROM THE BIBLEPAY ADDRESS THAT begins with your 'faucetcode' above.
For example, if your faucetcode is:
BzXj5kV9LVUZGF4ipFCRmkzBbZu366grJt-1-41-89-52-131
then you will need to mine with randomX from address:
BzXj5kV9LVUZGF4ipFCRmkzBbZu366grJt

6b.  Here are the directions to mine with randomx:
https://wiki.biblepay.org/index.php?title=Upgrade_to_RandomX


Then, we will send you a reward of approximately (see OP post header) BBP if we deem you to be new and unique.

NOTE: You do not have to paste your reward address; the faucet code contains enough info for us to send your reward to you.

Thank you for using biblepay.

72

Pre-Proposal Discussion / Vote on your favorite future currency name:

« on: March 05, 2020, 10:00:20 PM »

Biblepay is currently designing a future feature - the ability to offer corporate whitebranding.

In the process of doing this we are also considering offering a DUAL BRAND (One channel for users that are not necessarily Christians, for a Global reach).  This other brand would be our parent company (For example, we could be known as DAC.ngo, our name being DIGITAL AUTONOMOUS CURRENCY.  This brand would still tithe 10% to orphan-charity (with the exact parameters of BiblePay and would share BiblePay's codebase and exchanges).  But we would have two tickers:  DAC & BBP pointing to the same underlying order book.  We would also have dual block explorers, dual forums, and dual branded randomx pools.

Or, you may vote for one new brand only (retiring biblepay).  This will give us an idea of the general feel as to what name feels the best, and if users generally like the idea of a dual brand.

In addition to the potential dual brand, we plan on using the new DAC identity to launch our charity-agent feature.  For example, if we become known as DAC, our DAC foundation website will host the charity agent partner pages and deals by magnitude descending, while biblepay acts as a website for gospel media and preaching and salvation, etc.  Basically the DAC arm would be more aligned with those talking about crypto while the BiblePay brand would have more gospel features and media that might turn away some types of traffic (for example hell videos, etc).  However, we could work together to make subtle inroads into the DAC side to try to save those users.

So hence one of the reasons for the dual coexisting brand.  I am also consulting with SX to seek approval for dual-exchange tickers.

73

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.

74

TestNet Discussion Archive / BIBLEPAY - RANDOMX INTEGRATION

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

• You get double the hashrate.  If you mined at 5,000 HPS with XMR, you will mine at 10,000 HPS with BBP+XMR.  This translates into a potential profit of almost double (minus the 10% we give to orphan-charity).
• If you generate 1 XMR per month with XMR mining alone, you stand to generate .90 XMR + 80,000 BBP for the same amount of work (the amount of BBP is speculative, based on current rates).

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

75

Archived Proposals / BiblePay Future Hash Algorithm for CPUs

« on: January 26, 2020, 10:09:36 AM »

Option 1 - POBH 3.0:  This means we would rewrite POBH (which has the 31,000 verses of the bible) in a way that would run slower in a GPU (than on a CPU) and be very unlikely to work on an ASIC in the future.  This appears to be possible by using .netcore's polymorphism, branching, and large initial required data streams.  In a nutshell it would take more work to move the inital calculated stream to a GPU than to perform the operation on the CPU.  The CPU is also the only way to execute the dotnetcore commands.

Option 2 - Math Prize:  Embed one of the worlds greatest math problems in the next algorithm, to give BBP a chance of winning the $1 mil prize, for example.  One example is the Reimann Zeta hypothesis, when calculating Zeta on the critical strip above 10 to the 30th power, these zeroes become extremely hard to calculate and elusive (the highest found is 10 to the 30th).  https://www.claymath.org/millennium-problems/riemann-hypothesis

Option 3 - Useful Work:  This option is similar to #1, in that our hash function would be in dotnetcore, but the difference is we would update the code occasionally using auto-upgrades.  And the code would perform some type of useful work; similar to what is done in boinc projects.  We would find a useful algorithm and use it until it needs upgraded (such as CFD, for instance that Togo recommended). 

Option 4 - RandomX and dual revenue streams for the miner:  The idea here is that we switch to the randomx hashing algorithm, for core wallet, pool and miner.  We add the ability to allow the miner to mine any randomX coin (we do this by querying the block-key which changes every 2048 blocks in all randomX coins, and making our hash algorithm solve for an *equation* rather than the diff level. )  This way, our miner can perform useful work that generates revenue, by mining XMR or another randomx coin, for instance.  However the difference is, every hash that is calculated in the randomX virtual machine would have a chance at solving the current BBP block also.  This would provide a dual revenue stream for the miner.  Theoretically, we would be a more enticing project for every randomx miner, simply because of the dual revenue.  This algorithm appears to not only be possible, but 95% efficient, meaning that each hash counts for both the primary randomx target (ONE only), plus BBP.  The theoretical algorithm we would use is :  X11(PrevBlockHash + CurrentRandomXHash) < DiffLevel(CurBBPBlock).  Note this is novel and unique in that our diff and block spacing can be in parallel to RandomX.  It also means the miner can mine any randomx pool or coin, and not need the Monero wallet for example (they will need the SPV wallet for the coin they mine).