Generic Smart Contracts

BIBLEPAY EVOLUTION - GENERIC SMART CONTRACTS

Generic Smart Contracts (GSC's) allow BiblePay to accomplish its goals without disrupting quality of service for our users. These contracts provide a modular abstract interface for user rewards, and exciting capabilities that are not possible in hard consensus systems.

Some of the features our GSC's include: payments based on campaigns, corporate turnkey integration, c#/stratis integration, Restful API oracles, web tipping, decentralized voting on Christian objects, Christian economy features, and more.

Generic Smart Contract Format

The GSC is split into a client server architecture. The client side user joins campaigns with a CPK (Christian Public Keypair) and competes in these campaigns for points. The server side (our Sanctuaries) assess user points and tracks user progress. Once per day, the points are converted and paid in a Generic Smart Contract. The GSC is voted on by the Sanctuaries automatically at a certain chain height.

The GSC is paid once per day as a superblock from BiblePay core, and is split among campaigns by points rewarded per campaign per user.

Sanctuaries assess the points per campaign per user, and allocate the total daily reward amount by points to participants.

CAMPAIGNS

BiblePay will support an unlimited amount of campaigns over the long term. Each campaign will have a name, a distinct purpose, and a set of rules and formulas that adhere to the GSC-Server-Abstraction-Layer.

A user joins a campaign by typing a command (see RPC commands). The user must have a Christian Public Keypair to join a campaign (see RPC commands).

Sanctuary Side

The sanctuaries will assess the points for each user, by looping through all live campaigns, and assessing the amount of points that should be assigned to each user and assigning Points.
NOTE: If multiple transactions were sent by a user in one day, the user points will be summed.

If the user has a 1 million balance in stake, the interest component will be 27 points, while the POG campaign reward=1000 points, equaling 1027 points for the day (see detailed example for more information).

Once the points are assessed at a daily quorum height, the sanctuaries will auto-vote on these points.

The daily generic smart contract will automatically convert points to BBP rewards in the superblock generator module.

Christian Economy Integration

The GSC system enables biblepay to create an exciting new campaign type for Christian economies in the future: HTML5 voting and HTML5 tipping.
In voting, it will be possible for a user to navigate to a list of Christian objects (say for instance, Orphan outgoing letters), and vote on these letters with their CPK.
The sanctuary will pick up votes for the "Orphan Letters" campaign automatically, allowing points to be rewarded in that campaign for voting activity from the 'Orphan' campaign budget.
The same can be done with any list of Christian objects, for example, a list of "Rapture video objects". As users vote on these items, the HTML5 vote will be picked up and converted to points according to the rules of the campaign.

Christian Public Keypair Reputation Score

Since an individual user will create a CPK to participate, it will be possible for the user to accumulate a reputation score, based on behavior. This will open up exciting possibilities for our network for future campaigns that reward points based on behavior. One example of negative behavior is if someone consistently votes down high quality content. If the users reputation score decreases, this user may be rewarded less share percentage in some campaigns (because activity is of low caliber).

As voting activity is assessed, the CPK will accumulate a reputation score change. Over time, it will be preferable for the user to keep the existing CPK (due to the positive reputation score) rather than create multiple keys or recreate the keypair. The reputation score may then be used to influence payout percentages in some activities, after it is established that reputation scores are accurate.

Corporate GSC Integration

A very exciting feature BiblePay will offer in our GSC system is corporate integration. This is a value add for corporations who do not want to spend hours learning blockchain programming to make cryptocurrency payments automatically.
This feature allows a corporate developer to configure a recurring or one-time payment to be made easily through the blockchain to a vendor by emitting a coinbase payment in our GSC.

Evolution Anti-BotNet Features, 51% attack prevention with ChainLocks

In Evolution, we have built in a brand new feature called ABN (anti-botnet). The original use-case for ABN stems from our mission to prevent ASIC/GPU ports, run BiblePay on commodity PCs, and create a fair mining environment without groups of monopolies forming (IE Asic monopolies) who take a large percentage of mining rewards. Even with CPU mining, we have seen some rich actors, who own 300 servers, point all the hash power at BiblePay and take an unduly large percentage of daily rewards. On one hand, we agree, they have every right to. But on the other hand, we really would like to appeal to distinct head count so as to expose more people to the Gospel. In light of this we have released ABN, which requires a certain amount of coin*age to be present in each mined block in order to mine BiblePay. What this does is quickly uses up coin*age when an attack occurs (to give an example, if you are BotNet with 50 PCs, and your wallet balance is 50,000, after solving a few blocks with high hash power your wallet will run out of coin*age and you will not be able to mine more BiblePay until coin*age increases).

The feature works like this. Our network requires an average calculated and pre-assessed static amount (posted in getmininginfo) of required coin*age and stores this in the chain. Each miner checks this number, and will search the wallet (this is all automatic) for coins totaling the requirement and place these coins in an ABN Stake transaction - and then begin mining. We do allow mining for All participants if a block is over 60 minutes old (this is so that our chain never stops if every single participant runs out of coin age).
In this way, every block mined in Evolution is sure to be solved by a normal participant and not a bot-net over time.
In addition to all of this, we have inherited Dash's 51% attack prevention system (ChainLocks). We have this feature fully merged in and ready to be released. This is an amazing addition to BiblePay, as it removes 51% attack risk by almost 100%. This is accomplished by asking our Sanctuaries to keep track of each solved block and not allow deep reorganizations once ChainLocks are live.

Deployment Timeline and Roadmap changes

For BiblePay Evolution, we will start by releasing One campaign: Proof-of-Giving. This will prove the entire GSC concept in testnet from end-to-end, with a daily smart contract being emitted, CPK users being registered and participating in the first campaign, the Sanctuaries assessing the points, Sanctuaries voting, and payments being made.

After the release of Evolution, our IT team will continue to develop the Corporate integration, additional new campaigns, and HTML5 integration.
BiblePay Architecture Changes for Reliability, Mass Development and Mass Adoption

In order to maintain a reliable environment in production, we have decided to change our current architecture. We are changing procedures to prevent or minimize production deployments that: Change consensus, or Add client-side features. Both of these things may be valuable in the long term (for example a new campaign allowing web tipping, or a gospel feature for Spiritual Warfare), but, not at the expense of the Quality of Service for those using BBP in prod, or for Exchanges or Sanctuaries.

In light of this, we have designed a new architecture where we will demarcate and abstract the core client from the Sanctuary in a way where BiblePay-IT may deploy consensus changes on the Sanctuary side only. This will be accomplished by creating a client side abstraction interface the core client will adhere to.

Our goal is that when we release Evolution, the client side contract will no longer change, and therefore updates to the sanctuary will not require upgrades for the users or exchanges.
We will accomplish this by deploying incremental updates to the sanctuaries that allow the consensus mechanism to be updated on the server side only. This means that when a new campaign is released (let us say for example, web tipping), the Sanctuaries will need to upgrade, but not the users, and the exchanges and network will not endure a hard fork. After the Sancs upgrade, web tipping will be announced and users may "join web tip campaign" and automatically receive rewards via the daily GSC.

Another large change that is occurring is our move toward an additional HTML5 GUI for new UI pages. We believes we will attract HTML5 web developers that will give us the bandwidth to build out pages such as Orphan writing, Orphan voting, Lists of Christian Objects, Embedded Christian Videos, etc. This also accomplishes our goal of not upgrading the core client during new GUI changes as these pages adhere to the new model.
Part of this change will mean that when a user navigates to a Christian Space resource, we will honor their CPK (Christian public keypair) as authentication, and this will allow the user to vote on the resource or view it , as the resource will know their voting ability and reputation score. This will allow the user to navigate into BiblePay's additional UI pages.

These exciting features are being added to BiblePay to make your user experience smoother and provide a high quality production Environment.

Modularity and Extensibility

To help remove IT development bottlenecks in the UI area, our dev team is making BiblePay-Evolution HTML work in a way where non-C++ devs (web devs) may participate in development and deploy GUI changes.
To give an example of how this will work, we have a background project with Kestrel and Sanctuaries, so that BiblePay will emit HTML5 markup from sanctuaries. This will allow webdevs to participate in: Creating Christian Spaces, building out BiblePay, and modifying BiblePay UI in a modular and extensible way, without knowing how to be a blockchain programmer.
To the end user this means we will have tens to hundreds of new pages in the wallet in Christian Spaces in the future, allowing us to vote on these objects with our CPK and therefore our reputation scores will change, and we hope the experience will be edifying for everyone, giving BiblePay a truly valuable purpose.

RoadMap Modifications

March 2019: Release Evolution to Testnet. Test normal core wallet functions: Sanctuary creation, sanctuary operation, receive/send money, proposals, etc.

Mid April 2019: Test GSCs in TestNet, ensure payments work, campaigns emit points, campaigns can be joined and unjoined, and CPKs work. Ensure the first campaign (POG) works properly.

May 2019: Finish testing Evo, release Evo to Prod. Go Live with Evo and GSC (Generic Smart Contracts) - and One Campaign in Prod! (POG).

July 2019: Finish modifications to server side GSC's, alter any business logic. Add additional Campaign if necessary.

September 2019: Release Christian spaces (Allow voting on Christian objects, allow navigation of decentralized UI by CPKs).

September 10th, 2019: Make a very important announcement regarding the future of BiblePay (IE the announcement that was promised this year) - regarding a feature that cannot be disclosed until September due to the sensitive nature of the subject. What we can say, is this item gives BiblePay the ability to be a 'serious contender' in the space.

Dec 2019: Release Corporate Integration features. This allows 3rd party sites like (Steve Cioccolanti to integrate with BiblePay), c# Payments, Reports from Stratis, and also allows us to create DOCS (decentralized orphan contracts).

Our first Campaign - POG (Proof-of-Giving)

Notes about Campaigns: A user cannot join any campaigns unless they have a CPK (A Christian-public-keypair). You only need one CPK for life. The CPK is stored in your wallet.dat so when you move to a new machine you will still have your CPK. If you want to join multiple projects, you should create ONE CPK, then join each project with the join command. You will receive an error if you do not have a CPK and attempt to join a project. (If you try to create multiple CPKs you will receive an error).

Attributes of Campaign 1 (POG):

Assessment Includes: All users with a CPK who have joined campaign "POG"

Requirements: A contribution sent to the Orphan Foundation during the last 24 hour period

Assessment: Sum of( (Coin_Amount * 1) * (Coin_Age_Days * 1) * (CubedRoot(Tithe_To_Foundation)))
Meaning: For each donation to the foundation by a participant, we will reward the participant with the most portion of the reward based on Coin_Age, but to a much lesser extent, the donation amount.

Example (One Tithe with 7 days coin age, 1,000 donation): Coin Value : 25000, Coin Age: 7 days, Donation Amount: 1,000 bbp. Points Accrued = 25000 * 7 * CubedRoot(1000^(1/3)=10) = 1,750,000 points

Example 2 (One Tithe with 3.4 days coin age, 24,000 donation): Coin Value: 25000, Coin Age: 3.4 days, Donation Amount: 24,000 bbp. Points Accrued = 25000 * 3.4 * CubedRoot(24000^(1/3)=28.84) = 2,451,400 points
More than one Tithe per day results in points being summed to the CPK-Participant.
Since One campaign exists, the entire GSC budget is allocated to one campaign, however in the future GSC budgets are split among campaigns.
The campaign points are summed and converted into Total Prominence per participant, so that a CPK may see their assessed total Prominence per user Or points per Campaign.
The Budget is divided by Prominence and converted to payment amounts in the GSC.

ADDENDUM

Campaign Examples and Payment Example

Let us assume we have 2 campaigns in BiblePay: BiblePay POG and BiblePay Interest as live campaigns.

The BiblePay interest campaign pays 1% annual interest for a users proven UTXO balance.
The BiblePay POG campaign pays a reward of (Coin*Age*CubedRoot(Tithe_To_Foundation_Amount)) for a daily foundation tithe.
(Campaign parameters are malleable and votable by sanctuary proposals - and parameters updateable by spork).

If User A belongs to both Campaign A, B, User A's miner will automatically iterate through each campaign and create a GSC-Transmission for each campaign, once per day, using the configurable percentage per campaign of balance available for GSCs, in one transaction per campaign (this prevents network spam). The GSC-client will automatically loop through campaigns joined by the user and try to participate in them.