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.


Topics - Rob Andrews

Pages: 1 2 3 4 5 [6] 7 8 9 10 11
76
Archived Proposals / Dynamic Whale Staking
« on: November 08, 2019, 05:36:06 PM »
This is a concept to be considered:  Dynamic Whale Staking.

The problem statement:  We need more users and more investors to make biblepay more popular. 

Solution:  Make a feature in BBP that allows 'latent BBP' to be 'staked' for a whale-unit reward.  Part of the goal is to make this as easy as possible; no complicated smart contracts, no daily wallet unlocks, no leaderboard, just simply buy the BBP on the exchange, load the wallet and run the command that burns the coins.


________________________________________________________
PROPOSED CHANGES TO EMISSION SCHEDULE WIKI:
https://wiki.biblepay.org/Emission_Schedule_2020
** NOTE:  THERE ARE NO NET CHANGES TO THE EMISSION TOTAL AMOUNT OR TOTAL MONEY SUPPLY,
however, the changes included here are:  A) We allow room for DWS rewards - starting in 2020 - by increasing our deflation percent from 19.5 to 20.04%, and allocating an additional maximum of 10% (of our gross monthly block reward) towards DWS rewards (This does *not* decrease the gross block reward, the sanctuary reward, or the POBH reward or the GSC contract amount).  If the DWS rewards are not used, because the DWS stake is never burned, then the BBP is never actually spent from our emissions.  (In this case the actual total money supply in BBP would be less than 5.1 B at the end of the schedule depending on how much is never spent).
________________________________________________________

Why would someone want this:  A person who is seeking cryptocurrency exposure will be looking at coins to invest in with certain characteristics.  I feel our coin has a bright future because:  Its a feel good investment (we do tithe 10% to orphan charity, so the utility of our organization works for you), we are deflationary in emissions per year, we are a HODLing community with governance meaning we have a high % locked up in sancs, and finally - the investor will be comparing ways to get more coin-unit rewards through proof-of-work or mining etc. 

Our original money supply covenant:  We will need to ensure we don't break our covenant.  This would be accomplished by allocating a percent of our emitted coins per year toward this project - in a certain band of years, IE 2020 through 2030, and increasing our deflation rate to pay for the feature.  So we would have no net changes in our total supply, but we would modify our coin emission chart to include this feature over 10 years.  In laymans terms this means we would emit 10% more total coins for 10 years, but we would increase our deflation % per year to cover the change.

Emission Changes:  In this proposal we allocate 10% more than our current annual emission rate (which is currently 612MM per year), therefore we would spend up to 5,083,333 per month on 'dynamic whale staking' deflating at our standard deflation rate (of 19.5%).  However note, this is the absolute maximum, if the product is 100% allocated.  If the feature is not used, these coins would not be emitted for whale staking.   We will also decide how much we need to increase our deflation %.


Full Safeguards:  The DWS money supply ratio would be hardcoded in the wallet for full safeguards, to ensure the wallet cannot emit more than the designated existing total plus the DWS for that month.  So, if we currently emit 50MM in a given month, the wallet would not allow more than 55MM to be emitted in a given month, due to the hard rules.  Additionally, the recipients of each DWS would need to be approved by all the sancs (the sancs who create the daily superblock would evaluate every DWS record and add it to the superblock).  So there will be no chance of a miner adding a DWS that is unauthorized. 

The core wallet will be generating the coins for the investor from the coinbase, so solvency is guaranteed.  BBP cannot go bankrupt from DWS.

Provably identifiable DWS burns:  Since DWS uses a provable burn record, it will not be possible to fake a burn, and it will be provably demonstratable that the burn address does not have a corresponding private key.  Rob will attach the mathematical proof to this proposal that shows how to create a certifiably provable burn address for Biblepay with no corresponding private key.   

-=-=-=-=-=-=-=-=-=

EDIT:  I am attaching the source code that facilitates the generation of a non-spendable-bbp address for both testnet and Prod, based on the first public key derived from an unusable private key of {0x0} (See attached file: DynamicWhaleStaking.cs).

This code creates a BBP keypair using a blank private blank key - ie hexcode {0x0} - that is a provably unspendable private key. This routine generates this public address :  B4T5ciTCkWauSqVAcVKy88ofjcSasUkSYU (This is the first public address from the 0x0 private address that is a valid spending address).  So if you send BBP to this address it will be lost forever.

=-=-=-=-=-=

Mechnical operation:

We will allow a DWS duration of between 7 and 365 days.

The dynamic-whale-reward will be quoted on the screen in 'test' mode - and will match on every biblepay client until the quote is consumed.
It will be updated block to block.

To protect the system from hogs, we will use two moving averages, annual saturation and monthly saturation.
The monthly saturation will primarily drive the quoted dynamic-whale-reward.

Full example of a DWS whale stake in action:

getdwsquote
Amount staked: 1,000,000
Dynamic-whale-unit reward: 15
This means the user would potentially receive 150,000 bbp in reward one year after the coins are burned, if bbp returns them (they are 100% at risk, and we will explain this by posting a risk notice).

(Allowed stakes can be between 100 and 1,000,000 bbp):
dws 1000000 receive_address 365 authorize true
In this case, the whales stake will be sent to the burn address;
365 days later, the whale will receive the original 1mil back, plus 150,000 in additional coins.

The reward algorithm should stabilize at a point where the stake-reward emissions average out to be the allocated projection.

Note:  The shorter term rewards are penalized by 50% divided by the span. 
So a DWU reward of 100 will only be 50 if the duration is 1 month.

75 for 6 months.  100 for 12 months.

  This will encourage DWS whales to lock the coins for longer durations, and free up more of the DWS rewards for more distinct users (because those who choose short spans will receive less rewards).  This will be accomplished by storing the duration on the burn itself, so the actual DWU reward
 will be calculatable off of the base.

Example:
Current DWU-reward level is 50 for 365 days.
DWU-reward is  37.5 for 6 months.
DWU-reward is 25 for 1 month.

User A types  : exec dws 10,000 365.  They will receive receive 10,000 + 5,000 after 365 days.

User B types  : exec dws 10,000 180.  They will receive will receive 10,000 + 1,875 in 180 days.


Target Algorithm version 1.1:

"Two saturation levels are monitored.  The Annual saturation level is comprised of the total outstanding (owed and unpaid) DWS stakes over the next 365 days.

The Monthly saturation level is comprised of the total outstanding owed over the next 30 days."


Annual and Monthly Saturation Equation:
SE_Percent = Total_Outstanding_Coins_Owed / Maximum_DWS_Reward_Amount_For_The_Period


1.  If Annual Saturation is > 95%, drop DWU reward level to zero (for quotes).
2. If Annual Saturation <= 95%, offer the inverse of the monthly saturation level as a DWU reward.

Inverse of monthly saturation level:

IA = 1.0 - Monthly_Saturation_Level

ROI quote = IA * MAX_DWS_DWU

Example:

1.  Annual saturation level is at 25%.  Monthly Saturation is at 50%.  Since IA equals 50% (for 365 days), the quote would be .50 * MAX_DWS_ROI = 100 DWU.

2.  Annual saturation level is at 25%.  Monthly Saturation is at 90%.  Since IA equals 10% (for 365 days), the quote would be .10 * MAX_DWS_ROI =  10 DWU.

3.  Annual saturation level is at 96%.  Quote = 0 DWU.

4.  Annual saturation level is at 94%.  Monthly Saturation is at 1%.  Quote = .99 * MAX_DWS = 198 DWU.

5.  Annual saturation level is at 50%.  Monthly Saturation is at 99%.  Quote = .01 * MAX_DWS = 2 DWU.

Risk Rules:  (Rules to mitigate risk):

Each burn will be audited in the memory pool before accepted (meaning a burn can be turned down by all the nodes, if for example the burn is created fraudulently, or, if the burn will result in an overage condition for BBP).
Rule 1:  Each node will check the components of the burn, to ensure they match the quote available, the duration available, and the availability of the DWS ROI.   Check the bounds for each component also.  (Otherwise if any of this fails, reject the burn).
Rule 2:  No more than 5 mil in gross stakes per day.  This will limit our exposure for GSC contracts to never pay more than 5 mil back to whales in a given day.
Rule 3:  If the Annual Saturation level > 95%, reject the DWS.
Rule 4:  Each node will re-assess the 'total whale metrics' as each transaction occurs.

Burns rejected by the memory pool will automatically refund the funds back to the sender (actually, the transaction will be rejected, the same way a conflict or a double spend is handled).

Howey-test protection, to ensure biblepay stays a utility:

We will add a warning to the DWS burn method:

Your coins are 100% at risk if burned.  This is a self directed action by you.  Type authorize to acknowledge that burning the coins results in a potential entire loss with no future expectation of profit, and biblepay will be held as a harmless utility for this self directed action.  We do not promise you an increase in value for any
 of your coins!  We do not promise to pay you back for any burned coins, and coins are 100% at risk. 




77
PODC 2.0 (Proof of Distributed Computing)



Welcome to the PODC 2.0 Testing thread.

In this thread we will be testing the Dash 0.14 branch with PODC 2.0:

(Please ensure your version is greater than this, otherwise your testnet branch will not sync.  We are at block 14,000 as of Nov 1, 2019).


Testnet Download Links:

Windows v.1.4.6.7+: https://biblepay.org/biblepayevo32develop.exe
Linux PC 32bits Daemon: https://biblepay.org/biblepayd-evo-testnet-i686-pc-linux-gnu.tar.gz
Linux QT: https://biblepay.org/biblepay-qt-evo-testnet-i686-pc-linux-gnu.tar.gz

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

Linux ARM64 daemon: https://biblepay.org/biblepayd-evo-testnet-aarch64-linux-gnu.tar.gz
Linux ARM32 daemon: https://biblepay.org/biblepayd-evo-testnet-arm-linux-gnueabihf.tar.gz
MacOS QT: https://biblepay.org/biblepaycore-evo-testnet.dmg

To self compile:
https://github.com/biblepay/biblepay-evolution/blob/master/BuildBiblePay.txt


The ETA for MainNet for PODC 2.0 is November 30th, 2019.



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




USAGE INSTRUCTIONS FOR PODC 2.0:

https://wiki.biblepay.org/PODC







78
Archived Proposals / BBP per RAC requirement for PODC2.0?
« on: October 28, 2019, 01:08:46 PM »
NOTE:

In PODC 2.0, we are creating an "external purse" meaning, that you can send extra BBP from your main wallet to your purse, and this purse will be used to stake collateral (so the wallet never needs unlocked to participate in PODC).

However:  Even with this nice feature, operations will work like this : either A or B:

A)  No BBP per rac is required.  No coin*age is required.  Nothing is spent from the purse day to day, and users may leave the computer off, run WCG/Cancer miners for a month, and receive 30 rewards.

Option B:

B)  Rac to the power of the exponent in coin-age is required.  The collateral amount is sent *daily* from the purse.  Although the wallet does *not* need to be unlocked, the core wallet does need to be running (and the POBH miner does not need to be running) - this is so the core wallet can send a PODC update once per day (with the collateral amount staked out of the external purse).

**NOTE** : The BBP-coin-age per RAC is actually expressed in Coin Age.  Meaning:  coins are re-used each day.  (Coins that are spent in a collateral Tx lose their coin age each day they are spent).   (But, these coins are sent back to your external purse, and then start to age again immediately).  So, a 20,000 BBP coin*age requirement means you need about 20,000 bbp~ in the external wallet continually to maintain rac rewards.

To give everyone an easy idea of exactly what the required coin age would be per exponent level, here is a chart:
The very left column is the exponent, and then we have each hypothetical RAC level).  The value after the equals sign is the coin-age required for that rac level (for that exponent level).

Exp: 1.3      500=3225.98 1000=7943    1300=11171.88 2100=20839.39 2900=31704.24 3700=43517.33 4500=56127.57 5300=69431.83 6100=83354.45 6900=97837.16 7700=112833.47 8500=128305.3 9300=144220.78 10100=160552.76 10900=177,277.84     21000=415,800     42000=1,023,821     80000=2,366,012

Exp: 1.43      500=7236.48 1300=28375.2 2100=56334.39 2900=89377.69 3700=126627.63 4500=167530.5 5300=211696.9 6100=258834.2 6900=308712.49 7700=361145.11 8500=415976.76 9300=473075.67 10100=532328.31 10900=593635.54

Exp: 1.56      500=16232.79 1300=72069.52 2100=152286.74 2900=251965.38 3700=368463.68 4500=500047.8 5300=645461.52 6100=803738.08 6900=974102.33 7700=1155914.02 8500=1348632.2 9300=1551791.61 10100=1764986.32 10900=1987857.9

Exp: 1.69      500=36413.24 1300=183047.7 2100=411671.32 2900=710317.67 3700=1072163.24 4500=1492550.89 5300=1968005.1 6100=2495786.44 6900=3073653.9 7700=3699723.99 8500=4372380.86 9300=5090215.66 10100=5851983.89 10900=6656574.26

Exp: 1.82      500=81681.82 1300=464918.58 2100=1112856.37 2900=2002462.34 3700=3119802.76 4500=4454990.43 5300=6000425.98 6100=7749974.97 6900=9698517.31 7700=11841674.52 8500=14175632.47 9300=16697019.96 10100=19402822.03 10900=22290316.05

Exp: 1.95      500=183227.86 1300=1180835.87 2100=3008344.89 2900=5645157.92 3700=9078066.55 4500=13297328.62 5300=18295233.04 6100=24065405.19 6900=30602416.87 7700=37901545.03 8500=45958612.12 9300=54769874.99 10100=64331944.54 10900=74641725.59


So for example, if you vote for a 1.69 exponent, this means a researcher will need 183,047 in coin-age to be rewarded for 1300 RAC.
A researcher will need 6,656,574 in daily coin-age to be rewarded for 10,900 rac. 

NOTE: If a user does not have enough, we reward the capped amount: for example if they have 36413 in coin age, the exponent is 1.69, their rac is 1500, they will receive a reward based on 500 RAC for that day (IE the capped RAC for their coin-age level).





79
Archived Proposals / BiblePay Evolution 2.0 Changes for Future Growth
« on: October 19, 2019, 01:04:03 PM »
BiblePay DSS (Decision Support System) from the CMC (Cryptocurrency economic simulation) model


In the spirit of making solid future changes for BiblePay based on strong mathematical decisions, I have written a program called the 'CryptoCurrency Economic Simulation'.

In this CES, we attempt to create a synthetic model that reverse engineers DASH's success.  In the model, we have the money supply, the emissions per day, the GetBlockSubsidy rules, the dash 7.1% deflation level, and many assumptions based on new users per day, theoretical miner count, the buying activity by miners, the buying activity by investors, the investor count, the miner liquidations per day and expenses, the governance expenditure percent, the % allocated to charity (IE the % of payroll vs charity), assumptions on whale liquidations vs price, the market cap from CMC per day, etc.

The goal is to allow the program to run and see if the model will match the actual price in history then let it create the effect(s) into the future, and therefore then allow us to plug in theoretical changes to the dash model for BiblePay, and resimulate then decide what elements of our infrastructure should be changed that will improve the future.

For Dash, the basic premise is they cap the governance emissions level per month at 10%, they have a 7.1% annual deflation level, DGW limits the payout per block when difficulty rises, and since the Masternodes lock half of the money supply up, that causes less money supply to be available, theoretically increasing the price.  A very influencing factor to growth is the amount of new users per day (augmentation and negative attrition levels).  For dash, they attract about 50,000+ miners to the coin due to the price per block payout per month.  With an electric cost of $20 per month, you can imagine that the DASH infrastructure can support this many people.  All of these people contribute to a positive impetus on the price - because some act as investors. 

One hidden aspect regarding miners other than the miner-investment relationship, and the positive word of mouth, is we must view miners as a positive expense - basically similar to payroll.  Because this data reveals that spending money on mining rewards is far different than capital expenses.  The miner will not sell the coins unless they made a profit, meaning that money spent to miners does not necessarily cause the price to drop.  The price drops when they liquidate coins to pay for electric.  However the miner may be living in the basement, where the expenses are already paid by the household.  Meaning a miner may make a substantial profit off of BBP even if they break even on paper (due to the fact that the electric is a constant given expense where they live regardless of their computer running).

Elaborating on this to be more clear, one aspect of this project is to rank each type of expense as to its ability to pull down our price.  For example, we have :  mining expenses to miners, governance to payroll, governance to charity, mining to poom, mining tithes given to POG, and QT controls (among other things).  This exercise is revealing very interesting things about our project:  Mining rewards to miners are positive - because - their liquidation requires :  psychological profit and for our price to be higher than the electric costs they spent.   Rewards to POOM otoh, immediately drop our price because the miner must sell to recoup the fiat spent (meaning POOM = 1 as far as benefit to biblepay).  Mining rewards = 9 due to word of mouth.  Mining rewards for GSC-POG appear "good", but looking deeper into these - the POG component that the miner tithed to the foundation is another problem.  This means our liquidation for those 2mil per month coins has : expanded our governance budget way beyond .10% initially designed, And worse, those coins hit the market and immediately lower our price.  Making POG also : 1 (bad for biblepay).  Governance percentages:  Although we originally designated 10% cap to charity,  with POG, we have been spending 20% on charity, and with POOM, 40% of gsc, making our monthly budget grossly overspent on charity (50%).  This "sounds" great from a charity perspective, but the problem is, we must be healthy in order to even be in business.  You cant kill the golden calf and expect to be a blessing next month if the whole calf is dead.  So, another thing this simulation reveals:  To run a tight ship and be a bigger blessing, we must take control of our charity expenses and pull the horns in and cap this at a strict 10% per month - no more - to any other budget allocation.  This will limit coins spent (other than the 10%) to not drag down our price (IE all other coins would end up in IT projects, proposals, payroll, and mining).

QT:  QT is another 'feature' that has an entirely different side of it than the proposal alludes to.  From the proposal we said, hey lets take control of our expenses, lets run a tight ship and go up in price.  However, the unintended consequences are this:  we blocked our growth.  In order to have growth (the +1 new user per day we will discuss in this thread) you must have mining expenses.  Above we show mining expenses are not bad - because they are allocated over hundreds of wallets and provide good word of mouth.  So, we ran our users off by trying to save money.  The model shows, with a stagnating attrition level of just -1 UPD, the price goes sideways, and worse, could go down once the users leave.  However, by spending more on mining, with +1 UPD, the price goes north.  (See charts with +1 UPD - Good - BBP).  So I will be recommending that we shut down QT.



Chart 1:  Dash as they are now (Good) - with positive new users per day:



Chart 2:  Dash - in a bad environment - where they increase governance % to 20%, and, with negative user growth per day:



Chart 3:  BBP - in a good environment - with 10% charity budget, and, positive user growth per day:



Chart 4:  BBP - in a bad environment - with 20% charity budget, and negative user growth per day:





Summary of Changes:


- Remove QT (Quantitative Tightening):  This increases our emission back to our original plan.  This will theoretically attract new miners and new users and new investors as word of mouth increases.

- Make each currency unit more expensive:  Back when we had PODC, each currency unit was harder to mine, because we had 300 concurrent PODC users competing in Team Biblepay for RAC.  It is clear that when user count increases *and* it becomes harder to mine, our price goes up.  Therefore we must do things that lower the barrier for miners to enter (lower ABN fees), allow difficulty to increase, and add PODC.

- Lower or remove ABN fees:  Although counter intuitive that with a rising diff, you would expect a *higher* abn, we actually want a higher diff (to make each currency unit more expensive), and we want a lower abn, to bring in as many users as possible.  It could be argued that the ABN is over-complicating BBP and it is complicating the pool (and adding requirements for unlocking wallets etc). 

I think in the spirit of simplifying BBP, it is best to disable ABN in the near future.  Sun shows below even with ABN, 30% of our blocks are solved by the same 5 CPKs.  Additionally, ABNs are requiring us to unlock wallets to mine, and complicating the pool requirements.  Without ABNs, power users will be able to create new pools.  With ABNs, power users must understand a plethora of new issues.   Im thinking they might be a net negative for us at this point. 

Recommendation:  Remove ABNs, lower heat mining rewards in the future (after chainlocks), raise PODC rewards.





- Reinstate PODC:  Although we removed PODC so as to not have as much code to support, with the above revelation on POG and its negativity for expenses and tithing, I feel we are in a good position to re-enable PODC in our GSC system.  Additionally, there are ways to remove the oracle risk, which I will discuss soon.  I think in phase 1, we can accomplish our short term goals like this:  We write new code to pull in Rosetta CPID RAC into a GSC contract.  We raise the daily GSC payout to 80% for PODC.  We reward Rosetta CPIDs for tasks from the GSC "CancerMining" budget.  We cap each CPIDs reward at a certain RAC (equal to something like 5 computers).  This *helps* prevent users with astronomical RAC from overrunning the rewards in this GSC.  (I know split cpids will occur but we protect more small users this way).    We require team BBP for cancer mining.

- Remove POG - replace with PODC:  Primarily due to users not feeling comfortable with daily tithing, *and* the POG budget being a negative related to exchange liquidation; remove it

- Keep Healing - Healing is bearing Christian fruit; and is only 5% of the daily budget; keep it

- Decrease Charity % back to 10% (Original Design) - Due to the fact that POOM was added, and POG crept in, we have essentially increased our charity budget way beyond 10%.  Its around 10% from governance plus 10% from POG plus 20% for POOM equaling about 40%.  This alone, when plugged in the model creates a death spiral for biblepay.  Its almost as if these expenses will certainly kill our price per month, and the only hope for a recovery is hitting 1 satoshi and losing 90% of our orphans.  Therefore, it is recommended we go back to our original design:  No more than 10% for charity.  How can this be?  This goes hand in hand with the DAC idea; how can we accomplish this and still be a dac?  I recommend we lower our monthly governance charity % to zero (while we pay off our current new exchange deficit), and adjust POOM to be exactly 10% of our monthly budget.  Since poom is new, it accomplishes the charity budget in a decentralized nature already (today).  We can allow compassions credit to work its way to zero and then we temporarily cancel compassion.  In the near future, depending on how POOM works, we can offer Kairos to integrate with POOM.   If POOM fails, we can then talk about  Sanctuaries  decentralizing charity expenses.    For now, this proposal proposes to :    Lower Charity superblock budget to zero, remove POG and tithing, lower Cameroon-Ones POOM budget to exactly 10% of our monthly budget.  If cameroon-one is not used up by the miners, the coins are  burned (as it is already set up now).

- Sanctuary payment/heat mining payment:  Sun asked in the forum thread if sanctuaries are getting too little due to QT & DGW.  On the DGW side, I am a fan of a decreasing reward when the diff is exceedingly high (I think Dash was correct in penalizing an inrush of large hashpower).  Aside from this, with QT removed, our rewards increase dramatically (60% more), and recently last month MIPs proposal won that increases the sanctuary payout by 10% (by decreasing heat mining 5% and decreasing pog 5% - note - this restores the sancs to the original launch parameter that was disturbed by pog).  So I feel we are OK on our current path with Sanc/heat payments.  If anything were to be considered for change in the *future*, we could consider simplifying biblepay by :  first requiring chainlocks (for increased security) then lowering the heat mining reward and raising the PODC reward.  But I feel we can postpone this idea - until after chainlocks are working successfully in prod and we regroup.


Addendum:  October 23rd, 2019:


Detailed breakdown of proposed changes to block distribution and monthly governance percentages:
https://wiki.biblepay.org/Economic_Changes_Dec_2019

From a high level, this means reducing our payments to charity sourced from the governance superblock (while we ride out our compassion credit balance).  Once compassion is close to zero credit, we will give them a 30 day notice and put them on hold.  However we still keep POOM with Cameroon One (and we approach Kairos to give them a coninuity path).  We modify the POOM GSC % down to 40% temporarily - this limits our monthly charity emission to 10% to target the above model.  This starts PODC at 60% of the GSC superblock temporarily, until the next mandatory upgrade, where we then have more leeway to increase PODC to 75% of the GSC by lowering the POBH reward.

One other attribute I would like to include:  We need to simplify BBP for the users, so while we add PODC back in - we will focus heavily on a simpler substructure - less prone to mistakes and more prone to onboarding new users.  IE think of the iPhone when we do this.  And in the end we want to clearly say:  PODC 2.0 is an Improvement!  Praise Jesus.














80
Archived Proposals / New Exchange - Coinsbit
« on: October 19, 2019, 10:07:41 AM »
All-

Togo has been searching for new exchanges lately, and out of (I would say, almost all of the top 100 exchanges we either tried to contact or have successfully reached), Coinsbit is one of the few that has replied, talked to us via email, gave us what appears to be a very good offer to be on their exchange, and appears to be a high quality partner.

First I want to say, Im more than a little dissapointed with the past deals, and it would be unprofessional for me to name any specific companies at this point.  But, let me say - Im dissapointed that we have been placed with companies during our launch that failed to meet minimum business practices of honesty and have gone out of business.  Im dissapointed we ended up paying good money for a very limited result for an exchange deal that had almost 0 volume per day and then went out of business.  And then the straw that almost broke our back, we have been unequally yoked with players who are not creating purely real volume and have lower trust scores.  I prayed about this today and asked Jesus to step in.  I have faith, that he will fix all things.

Moving on to the issue at hand, Coinsbit has a trust rating of 8.  They have 20,000 twitter followers.  They have 1+MM similarweb visits on coingecko (Ie traders/users).  They do $250MM or $20,000,000 mm normalized volume (meaning they may be bigger in volume than bittrex).
https://www.coingecko.com/en/exchanges/coinsbit#trust_score

I already explained to Nick, who btw seems to be a very nice guy and appearing to work with us (and Togo spoke to him also on discord) - that we are over budget.  He came down in price for us. 

I view this deal as basically - a very good deal, I dont want to walk away from - and as you all might imagine  - our last exchange deal for quite a while.  If we do this, we need to walk away from new exchanges for a year and pay off our deficit, unless of course God steps in and our price rises significantly over the next 6 months.

The deal is:


.50 BTC - go live right after proposal wins
.50 BTC in BBP
_______________
TOTAL Deal: 1 BTC

Rob will have to front the BTC and BBP; we get to go live by Nov 1st if we agree to these terms.





81
Archived Proposals / Lower ABN Requirement?
« on: October 02, 2019, 05:13:58 PM »
Shall we change the ABN requirements, Saints?

To be more friendly to new users?


82
Archived Proposals / September Payroll (May 2019)
« on: September 21, 2019, 10:16:11 AM »
Commits on May 31, 2019
OneClickSanctuary EVO instructions

 
 
masternode setup script for Evo

 
1.4.3.1d-Leisure Upgrade …

@biblepay
biblepay committed on May 31
 
Commits on May 27, 2019
1.4.3.1c-Leisure Upgrade …

@biblepay
biblepay committed on May 27
 
1.4.3.1b-Leisure Upgrade …

@biblepay
biblepay committed on May 27
 
1.4.3.1b-Leisure Upgrade …

@biblepay
biblepay committed on May 27
 
Commits on May 20, 2019
1.4.3.1 - Evo RC6 - fix for MacOS compile …

 
Commits on May 19, 2019
1.4.3.1 - Evo RC6 …

@biblepay
biblepay committed on May 19
 
Commits on May 18, 2019
1.4.2.9-Evo RC5 …

@biblepay
biblepay committed on May 18
 
Commits on May 17, 2019
1.4.2.9-Evo RC4 …

@biblepay
biblepay committed on May 17
 
1.4.2.9-Evo RC3 …

@biblepay
biblepay committed on May 17
 
1.4.2.9-Evo RC2 …

@biblepay
biblepay committed on May 17
 
1.4.2.9-Evo RC1 …

@biblepay
biblepay committed on May 17
 Commits on May 7, 2019
1.4.2.8b-Leisure upgrade for TestNet …

@biblepay
biblepay committed on May 7
 
1.4.2.8-Mandatory upgrade for TestNet …

@biblepay
biblepay committed on May 7
 
Commits on May 4, 2019
1.4.2.7-Mandatory Upgrade for TestNet …

@biblepay
biblepay committed on May 4
 
Commits on May 3, 2019
1.4.2.6-Mandatory Upgrade for TestNet …

@biblepay
biblepay committed on May 3
 
1.4.2.5-Mandatory Upgrade for TestNet …

@biblepay
biblepay committed on May 3
 
Merge branch 'master' into develop …

MIP
MIP committed on May 3
 
Commits on May 2, 2019
1.4.2.4-Mandatory Upgrade for TestNet …

@biblepay
biblepay committed on May 2


Capping at 1.25 MM



83
Archived Proposals / Remove Port Restriction on Hosted Sanctuaries
« on: September 15, 2019, 01:31:18 PM »
So this idea is spearheaded by Apollon and I also have heard of this idea from TheSnat before.

The idea is to remove the port restriction on sactuaries, and allow the sanc to be hosted from any port number.

Technically, we know this will work because XAP and BlockLogic (BLTG) are doing it already.

(The port restriction is this:  Dash must run on port 9999 only and if a user hosts from other than 9999, the Masternode will be rejected from the network.  For BiblePay they must run on port 40000).

Dash put the port restriction in to be more corporate friendly for Network Admins - IE - they wanted network admins to know that if port 9999 is to be open, its specifically for Dash traffic.

Initially I was slightly against the idea, when I imagined we would have one sanc per user, I figured each of us could afford the $5 hosting fee per month.

However, as we evolved I have seen another side to this situation:  During downward price spirals some of our users who are cost concious would like to run more than one sanc on a hosted VPS.  From my perspective, I changed my mind to neutral when I experienced a very bad service level with one of my last sanc hosts (not vultr), and I had to hurry and switch to Apollon (thank God they were available at the time).  What Im alluding to is, if removing the port restriction would have given me for example a path to create more instances per vultr node for example, it might have been a life saver.  (I dont mean financially for me, I mean for the sake of the GSC contracts being voted on by my nodes).

In light of this I've become neutral.  I obviously want high performance per node.

Please provide any opinions on this idea, if this will be a terrible move for some reason.

As far as Apollons perspective, they are in business to make money.  I realize our partners need to be healthy and make a profit, and if we lose our partners, we lose our ability to host sancs.  Lets think of this from all angles.

Possible Positive reason:
If less BBP is spent on hosting less is liquidated on the exchange for hosting fees to be paid

Possible Negative reason:
Will we look weak and fragile if we allow this?





84
Archived Proposals / August payroll (Apr) 2019
« on: August 17, 2019, 10:23:39 AM »
ommits on Apr 29, 2019
1.4.2.3-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 29
 
Commits on Apr 28, 2019
1.4.2.2b-Leisure Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 28
 
1.4.2.2-Mandatory upgrade for TestNet  …

@biblepay
biblepay committed on Apr 28
 
Commits on Apr 26, 2019
1.4.2.1b-Mandatory upgrade for TestNet  …

@biblepay
biblepay committed on Apr 26
 
1.4.2.1-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 26
 
Commits on Apr 25, 2019
Merge branch 'master' into develop  …

MIP
MIP committed on Apr 25
 
Commits on Apr 23, 2019
1.4.2.0-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 23
 
Merge branch 'master' into develop  …

MIP
MIP committed on Apr 23


Commits on Apr 22, 2019
1.4.1.9-Leisure upgrade for TestNet  …

@biblepay
biblepay committed on Apr 22
 
Commits on Apr 21, 2019
Merge branch 'master' into develop  …

MIP
MIP committed on Apr 21
 
Commits on Apr 20, 2019
1.4.1.8-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 20
 
Commits on Apr 18, 2019
Merge branch 'master' into develop  …

MIP
MIP committed on Apr 18
 
Commits on Apr 17, 2019
1.4.1.7 - Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 17
 
Commits on Apr 12, 2019
1.4.1.6-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 12
 
Commits on Apr 10, 2019
1.4.1.5b-Leisure Upgrade  …

@biblepay
biblepay committed on Apr 10
 
1.4.1.5-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 10
 
Commits on Apr 9, 2019
1.4.1.4-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 9
 
Commits on Apr 5, 2019
1.4.1.3-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 5
 
Merge branch 'master' into develop  …

MIP
MIP committed on Apr 5
 
Commits on Apr 4, 2019
1.4.1.2b-TestNet Mandatory Upgrade  …

@biblepay
biblepay committed on Apr 4
 
1.4.1.2-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 4
 
1.4.1.1-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 4
 
Commits on Apr 3, 2019
1.4.1.0-Leisure Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 3
 
1.4.0.9d-TestNet Leisure Upgrade  …

@biblepay
biblepay committed on Apr 3
 
Commits on Apr 2, 2019
1.4.0.9c-TestNet Mandatory Upgrade  …

@biblepay
biblepay committed on Apr 2
 
1.4.0.9b-TestNet Mandatory Upgrade  …

@biblepay
biblepay committed on Apr 2
 
1.4.0.9-TestNet Mandatory Upgrade  …

@biblepay
biblepay committed on Apr 2
 
Merge branch 'master' into develop  …

MIP
MIP committed on Apr 2
 
Commits on Apr 1, 2019
1.4.0.8-TestNet Mandatory Upgrade  …

@biblepay
biblepay committed on Apr 1


This was approx 120 hours - capping @ 1.5 MM this month due to budget constraints.


85
Archived Proposals / FUBT Exchange
« on: August 15, 2019, 06:15:22 PM »
** Deal to List BiblePay with FUBT Exchange - Hong Kong **



I've been in contact with Mr. Yue and Nick Lee from FUBT for one year about potentially listing BiblePay.

A year ago the price quote was too high (IE over 5 bitcoins).

Over the last few months, Mr. Yue had quoted me 3 BTC to list, and I told him we would continue to evaluate their platform as our next exchange and continue to save up funds for our next exchange.

Over the last week, I started talking to Nick.  Nick explained that out of the 3 BTC fee, FUBT will spend a certain amount of money on promoting a new coin (IE they reach out to 50 media companies, and blast a summary of the coin, and promote it for a certain number of days in Asia).  Nick estimates the PR to be worth around $5000~ (or up to 1btc depending on its reception level).

Recently, our coin has been reviewed by FUBT's coin quality assessment group and they consider us to be an "A" grade coin (similar to SouthXChanges ranking system).  They again approached us and re-quoted us a listing for 6btc.  I explained it is out of the ballpark.

Recently, Nick explained to me he can only guarantee the 3 btc fee for a short period of time and we may lose our discount status if we don't try to make an offer soon.

I agreed to take a look at FUBT this month and attempt to create a deal that may possibly work with BiblePay.

FUBT does approx $500 mil per day total volume according to coinmarketcap and coingecko, (not the gecko normalized volume).  From looking at a comparison between Tokok, FUBT, Bittrex and SouthXChange, FUBT appears to be about 50* bigger than southxchange.  Nick explained to me they have 2 million registered traders at FUBT. 

https://www.coingecko.com/en/exchanges/fubt
https://coinmarketcap.com/exchanges/fubt/

Estimating the size of this investment, 3btc ($35,000), I estimate that we would see a potential increase of $5 - $10,000 per day in trading volume (based on similar coins to BiblePay) and this would potentially lead to a market cap increase in BiblePay, *potentially* paying off the investment within a short duration.  (Nick tends to think we would be received well in Asia and coins like us trade more than $20K per day, but this is speculative.)

I feel this move into Asia is something BiblePay currently needs, as we trade almost exclusively in the US.  I think the 2 mil additional accounts complement our needs to a high degree.

In light of this, if the sanctuaries agree, I am offering to help this listing along with the following offer:

If this proposal is voted in and the Security Check passes (this is an internal freshdesk ticket with FUBT senior management to verify the exchange proposal is signed and agreed upon by BiblePay and FUBT):
Rob sends FUBT 3 btc from his personal account (lending BBP 3 btc)
Rob enters a 12 part proposal to recoup .25btc per month until the 3 btc is paid back

FUBT Provides:

- Listing BTC/BBP trading Pair
- 1BTC worth of promotion (Media blitz with 50 media outlets, 1-2* depending on market appreciation)
- At least 4 mandatory upgrades per year with no fees (I verified this with Nick)
- The go live would be towards the end of September 2019 and media blitz around mid September

** If anyone has anything negative to report about FUBT please report it now **



Proposal Payment dispursement breakdown:

Payment 1 of 12:
BTC @ 10567 : .25BTC * 10567 / .000724 = 3,647,790 BBP

(Note, as each month occurs I will update the remaining payments until we hit 3 btc)



86
The ABN feature reduces the liklihood of bot-net mining activity against BiblePay.

Rob wants to ensure Security is maintained and our difficulty level never falls below 5000.

Should we re-enable ABN in small steps, starting with a 1,000 BBP requirement?

Then, if difficulty remains > 5000, we can increase our ABN requirement in steps weekly maintaining diff around 10K or more.


87
Archived Proposals / Compassion June 2019 Recurring Sponsorships
« on: June 24, 2019, 09:13:39 PM »
We currently sponsor 55 children through compassion with a recurring fee of $2090.

Request 4.1MM for June.

88
Archived Proposals / June Payroll
« on: June 24, 2019, 06:47:28 PM »
 
@biblepay
Commits on Mar 26, 2019
1.2.0.1b-Leisure Upgrade  …

@biblepay
biblepay committed on Mar 26
 
Commits on Mar 14, 2019
1.2.0.1-Mandatory Upgrade  …

@biblepay
biblepay committed on Mar 14
 
1.1.9.9g-Leisure Upgrade  …

@biblepay
biblepay committed on Mar 14
 
1.1.9.9f-Leisure Upgrade  …

@biblepay
biblepay committed on Mar 14
 
Commits on Mar 13, 2019
1.1.9.9e-Mandatory Upgrade  …

@biblepay
biblepay committed on Mar 13
 
1.1.9.9d-Mandatory Upgrade  …

@biblepay
biblepay committed on Mar 13
 
1.1.9.9c-Mandatory Upgrade  …

@biblepay
biblepay committed on Mar 13
 
1.1.9.9b-Mandatory Upgrade  …

@biblepay
biblepay committed on Mar 13
 
1.1.9.9-TestNet Only RC  …

@biblepay
biblepay committed on Mar 13
 
Commits on Mar 2, 2019
1.1.9.8-Leisure Upgrade  …

@biblepay
biblepay committed on Mar 2
 3   
1.1.9.7 - Leisure Upgrade  …

@biblepay
biblepay committed on Mar 2

Spent 20 hours researching the port to Dash-Evolution and discussing with MIP, and some additional time on conference calls.

Spent 160 hours working on biblepay.
160hrs * 40.00 = $6400 = 9.95M; capping @ 3.00 MM

IT Expenses:
Domain renewal for biblepay.org http://pool.biblepay.org/san/expenses/biblepayorg.png
$62 = 93,312bbp

Hosting for one year (biblepay.org):    http://pool.biblepay.org/san/expenses/hosting2019.png
$95 = 164,644 bbp

89
Archived Proposals / Kairos Childrens Fund PR Event
« on: June 13, 2019, 11:31:48 AM »
Pastor Andrew from Kairos Childrens fund is asking if we would like to have a banner at his 3 day national conference in the Philipines:

These are the packages that we are offering. Check out our website at vismin.winnegor.org
$100 : We will have 2 banners outside the hotel during the 3 day event. One more banner inside.
          The logo and tagline will be at the bottom, small, but readable from the back of the room or across the road

$50 : We will distribute small brochure about your company or product along with the packet that we give them at the beginning of the event.

$50 : We will also post a logo under 'sponsored by' on the website, with a link to the Biblepay website.

$50 : We will have your company or product mentioned at the beginning of the 1st session every day. (as a great cryptocurrency for christians.)
         + $25 : Your business / product will be announced as a major sponsor of the event

* If time permits, I will discuss biblepay with interesting people and pastors.

* We are thinking of
 - http://www.facebook.com/wimdgte
 - http://www.winnegor.org


=-=-=-=-=-=-=-=-=-=-=-=-=-


The event is being held Oct 22 through Oct 25th.

Pastor Andrew will design the pamphlet and the banner for us.


Total charge $250.00 or 625,000 bbp.



90
Archived Proposals / 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, POOM@Home 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).













Pages: 1 2 3 4 5 [6] 7 8 9 10 11