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
1
Pre-Proposal Discussion / 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).   


2
Production Proposals / Jan 2020 POBH and Integrity update
« on: January 19, 2020, 09:04:03 AM »
This proposal seeks authorization to make the changes necessary to release an emergency update to fix POBH.  As it was recently reported that Marcino ported POBH into a GPU.

This proposal seeks to change and clarify the following items:

- We will add a nonce limit for POBH hashing to limit the hasher to 256 hashes per second per miner.  This can be enforced, because the block start time is known in a hard way, and the last block time is known in a hard way.  Additionally, we enforce that the only field the miner can change is the nonce and start timestamp, and any other field that is changed results in a new block being created (and this requires many calculations for chainlocks, llmq, transaction lists, and recalculation of the merkleroot). 
    *** NOTE :  We will not limit CPU mining to 256 HPS, however.  When the miner is faster, the miner will create more blocks per minute.   Automatically.  ***
- It is a given that recalculating the merkle root requires more work than calculating more POBH hashes.
- Therefore the conclusion is that this interim release will remove the GPU risk from our POBH algorithm.
- We will still work on the next generation miner after this release, therefore this is a temporary stopgap for POBH to keep it running in a quality fashion.
- We seek to    shore up our emission deflation rate to match the target emission as of Dec 2020 (http://wiki.biblepay.org/Emission_Schedule).  This means we will for the time being increase our deflation rate to .0216 aiming to match the year end emission target.  We will monitor the situation afterwards and if necessary put it back to .0167 when the target is met (in a future mandatory).  In summary we are increasing our deflation rate to ensure we emit the exact proper amount of coins in total from inception until Dec 2020. 
- We seek to fix DWS.  This requires two changes:  At the mandatory cutover height, installing new rules that increase the sensitivity of the DWU reward.  This first change ensures that as burns take place, the wallet decreases the DWU quicker (saving more of the kitty for the next user).  Additionally we seek to reduce the maximum DWU to 35% of the original design (making more available to each individual user).  To accomplish this we must also adjust the DWS emissions to match the target emission schedule (4mm per month deflating starting in 2020).  The good news is DWS phase 1 had too low of an emission set-up so this is not really an issue - it means correcting the parameter to the intended value.
We will monitor DWS emissions - and ensure globally, DWS does not materially change the total emission schedule picture.  The goal is to flush out DWS phase 1 payments, allow Phase 2 to be established and ensure all factors are correct at the end of this year - and if necessary adjust the final DWS emissions level in the Sept-Dec 2020 mandatory to match our global emission schedule and DWS schedule as outlined in the prior point.
- Update the investors on the total orphan portfolio along with what is available at compassion.  Since we technically still have compassion funds, we are still above 100 orphans per month; but we need to be clearer.
- Clarify our stance on what the DAC and Biblepay charity agent proposal is, and that it is not expected to effect our charity emission level.  Clarify that our charity emission level target is still, and is expected to be 10% per month.  Clarify the complete idea - to explain that we do not veer from launch params and
 how we seek to continually work in integrity.




 
      

3
Pre-Proposal Discussion / BiblePay as a Global Charity Agent
« on: January 14, 2020, 05:52:10 PM »
This is an idea for a real world use-case for BiblePay.  Continuing the discussion on 'dimensions of a crypto' we have established that (https://wiki.biblepay.org/Dimensions) (if given 3 dimensions: Mining,  Innovation, real-world-use-cases), we score high on Mining (PODC), high on Innovation (Dashpay etc), and low on real-world use cases.

This idea involves either being a charity broker, or a charity agent.  Similar to the way a transistor works, we would 'enable' a charitable transaction - also by providing a reward back to the donor.  This would be the reason a donor would choose BBP over going directly to the charity.

Why would BBP be favorable?  We could constantly aggregate charities providing the 'best deal' in a web resource constantly updated.  For instance, lets say Korean orphans are in desperate need, and the orphanage offers a 30% discount.  Or, if we have matching funds available.  And, with corporate matches, and partnerships we may create a partnership discount.  Also we have platform fees charged by the big leagues (9%) plus transaction fees (3%), and all of this adds up to a huge amount of overhead.  The big leagues pay serious money to vet charities.  We can leverage this by downloading charity research for vetted orgs, and keep this in the folder for the org, and only partner with vetted orgs.  This will also save BBP all of the expenses (in vetting) - if we require pre-vetted orgs vetted by third parties with recent reports.

Looking at Charity, this is a huge untapped market in global finance.  We are obviously not tapped in any way, as the American charity donations are $390 billion annually, and global cause is over a trillion $.    Therefore this is a real world endeavor, so lets set our sights higher.

Let us create use cases for this feature.

In the current scenario (POOM), we match a miner with a charity.  Currently, we spend 10% of our blockchain emissions on charity.  But, we don't attempt to negotiate any discount with our charities, we spend the retail amount ($40 per child).  And this is technically not what I'm suggesting (I do not want to slim down the profit), I simply want to create a competitive market.  What we can do is ask each new charity partner as they are vetted, to offer us a  5-10% networking fee to be approved for the account - this would end up resulting in pooled rewards for the donor  (see below) - let us call this "Discount appeal A".

Next, there are many, many examples in the corporate world of companies that match employee donations.  Sometimes 2, 3, 4 or 5* the match is available.  We need to reach out for a pilot company, and design a flow that would allow an employee to sponsor a child, and facilitate the match. 

Next, there are real world examples - constant examples of 'matched funds' available at companies such as globalgiving.  I myself have sponsored over 10 kids last year with a match (that helped 20 kids), and, once through CARE, utilized the match of a NYC donor to double my CARE contribution.  We need to locate and partner with the match.  We can use the Match funds to offer a discount on the 'available charity for donation list' page - and this will be very enticing when a user is deciding to give through us (to see a 50% match, or 50% discount on the list).

Next, there is a platform fee of roughly 8%-9% charged by companies like GlobalGiving (and also a 3% network processing fee), for every donation!  This is huge.  (https://www.globalgiving.org/aboutus/fee/) .  This means $1000 given through globalgiving actually is reduced by 12% ($120) for a net receipt to the charity of 880$!  This point is one of the biggest points here.  This means, we can appeal directly to a vetted charity, receive a network-fee discount in our negotiation of new partnership (from point A above) - to broker the transaction.

This 5-10% total discount would entice the user to give through us (instead of going through globalgiving).  Because when we list each row, we will list the BBP reward available.  Then, we give the donor a refund in BBP, at the applicable % negotiated (creating a competetitive environment for new givers).
This gives the user 3 reasons to choose us :  Donating to causes with matches, donating with programs with discounts, bbp-reward back.

Real World Example:

We partner with Cameroon-One, Compassion, and Korean-Children Institute.  Cameroon-One negotiates a 5% discount with us, Compassion 5%, and Korean 10%.  This means right off the bat, Cameroon-One drops to $38 per child (because they are looking for partnershps and quantity), while if you go directly through cameroon, you pay $40. 

Next, we locate a charitable match partner (IE the same one globalgiving uses in NY).  They usually offer a match to the 501c3 for proof of a donation.  Then we apply this to our advertising page:

Cameroon-one     $38        With Match $19.00     
Compassion           $36         With Match $18.00

Note that what would happen is an inbound donor would choose an amount of the donation, say $380, and pick Cameroon-One.
We would automatically apply the match, and donate $760 to cameroon-one.  However, cameroon-one would pay a network fee of 5% (or $38) and this would go back to the donor in the form of BBP (not fiat).  Additionally, we could also pay a percentage of our charity budget for this transaction as an additional reward (of between 1-10% see chart based on price), however this additional reward would be capped at no more than 1% per donation of our total budget (IE if we have $2000 available, only a max of $20 could be paid in this additional bonus).  So lets say the BBP price is still on the chart level where 2% is being paid for rewards, then $15.60 additional in BBP would be added.   So this donor would receive $15.60+$39=$54.60 reward in the form of BBP (our coin would not keep the profit).  A random sanctuary would facilitate the transaction (IE document it and enter it in and execute it).  This would also be tax deductible, as the payments would go directly from the donor to the charity, and BBP would extract proof-of-transaction, and save the data so we can give real world credit for this on our web site etc.


Proposed Price breaks table :
BBP Price                   Charitable Expense Amount (And Governance emission amount)
.01+                             10% to charity (100% from superblock)
.005                              7% to charity (70% of superblock)
.001                             5% to charity (50% of superblock)
.0005                           2.5% charity (25% of superblock)
.0001                           1% to charity (10% of our superblock is emitted)

This table can be refined later, but it shows that we start to limit our payroll, IT expenses, superblock payments, and charity payments down to the governed table emission level while our price is low.  So only 2.5% goes to charity while our price is .0005.  However, we give the full 10% after our price exceeds .01.

So, as a bridge for POOM if we did this, we would sign up partners well in advance, negotiate deals, test in testnet, then we would want to convert POOM back over to donor->charity individual transactions; IE children would be removed from POOM, but left in the hands of the current sponsors for individual transitioning.  The hope would be during the go live we would have at least one match available to make this transition easier (as then the price would be lower to continue those children).

Note that I feel that if we did all this we would also need a 'legacy' page for classic type orphan charity, like we had in the beginning.  For example suppose we have half of our budget available.  We could by default, allow a user to sponsor an ongoing child for N months with no hassle.  So we would have both transaction lists of agent assisted transactions and lists of sponsored orphans sourced from our overflow funds.

Im thinking we would break out the fiat / crypto into two distinct services and offer both.
Fiat transactions would work like stated above.

But we should have a "donate" process for Crypto also.
We could pilot that with our orgs that already accept crypto (as it would get very tricky to make a crypto gateway available and force a sanctuary to liquidate funds, or lose their santuary if they did not perform).

Let me show an example:

Lets assume out of 10 charities, 5 will accept BBP+BTC.  We mark these 5 as crypto enabled.
We would want the transaction to be sent from the donor directly to the charity in crypto.
Then the charity would as usual send the network fee later back to us to disperse to our user.

What I'm wondering is, will this be used by the world if we make a brand new dedicated web site for this?

I'm a little more optimistic about this than some of our previous ideas.

Additionally, this entire idea seems to completely remove sell pressure from us as a coin.
All donor payments go directly to our charities in gross dollars, they receive a fat discount back for doing it.

The donations are tax deductible because they send To 501c3 enable charities.

One interesting thing that might happen in the case of a rich donor who has $1 billion to spend, lets say Trump decides to give $1 million to Cameroon-One.
This would cause Cameroon-One to send $50,000 in BBP back to Trump.  This is interesting because they would need to buy the bbp to send it.  Our governance emission would be $20 for this tx. 



Edit:  Another element I want to add, is ensuring our emission schedule completely matches our
target schedule here:
https://wiki.biblepay.org/Emission_Schedule
So what this means is I propose we tweak our internal deflation rate target to exactly match the Dec 2020
 target emission amount.  This is not a lot, or a major change to the deflation % level, but we have emitted about 100 million extra coins as of the current date and I feel we should shore this up for our Q3 2020 mandatory - we would end up increasing the deflation from 20.04% to something like 21% for example (after running the calculation).


And finally on an unrelated note, I will need to add a different thread for this subject:  Slightly modifying the POBH internal miner.  Things are pretty good right now.  But I believe God wants it perfect (the issue I have with this is "fair weights and balances").  I dont like how we ended up with a 75% mining speed for the solo miners in the core wallet and an increase in speed in the external miner.  So, I will open a separate thread to discuss this.  I mention it because it could be hampering our heavenly backing.  So that makes it important...

And finally one more point I forgot to mention: Globalgiving.  According to their financials they are bringing in $400 million per year of donations (and charging 8% fees on those, to handle those).  What we would do is analyze the top 100 charities, create folders and vet them, and then go to make deals with them, for discounts (this is the amount in BBP the reward will be for).  Then we expose them on a new web site ranked by the deal.  Then we make Donate buttons for our donors.  Then we add the sanc facilitation process.  And the refund process.  And the matching donor partnership and deal and flow.  And in the end the hopes would be browsers from the real world would flow over to us because they stand to gain a rebate of 6% if they give through BBP, and they get to accumulate BBP (crypto exposure).




4
Production Proposals / 1 MILLION BIBLEPAY PODC GIVEAWAY
« on: January 01, 2020, 08:16:10 PM »
** 1 Million BiblePay PODC Giveaway **


Terms and conditions:

- You must be an existing PODC researcher, in the biblepay leaderboard as of January 31st, 2020
- You must be contributing to research in World Community Grid
- You must have more than 100 RAC (recent average credit)

Mechanics of picking the winner:
- At block height 173307 we will take the first 4 hex-characters of the blockhash,  equaling 1-65535 (A).  Let B = 65535 / (count of superblock researchers in the prior superblock).  Let C = A / B.  C equals the (ordinal of) the winner (by counting from left to right through the last GSC contract prior to 173307).



5
Archived Proposals / Nov 2019 payroll
« on: December 20, 2019, 07:02:46 PM »
Program PODC 2.0.
Program Kairos integration.
Fix bugs in new development in testnet branch.

Commits on Dec 8, 2019
BiblePay

@biblepay
biblepay committed 12 days ago
 
Commits on Nov 30, 2019
BiblePay

@biblepay
biblepay committed 20 days ago
 
Commits on Nov 27, 2019
1.4.8.2 - BiblePay

@biblepay
biblepay committed 23 days ago
 
Commits on Nov 24, 2019
BiblePay - TestNet

@biblepay
biblepay committed 26 days ago


Commits on Nov 23, 2019
BiblePay

@biblepay
biblepay committed 27 days ago
 
Commits on Nov 21, 2019
1.4.7.8c-Mandatory Upgrade for TestNet

@biblepay
biblepay committed 29 days ago
 
1.4.7.8b-Mandatory Upgrade for Entire TestNet

@biblepay
biblepay committed 29 days ago
 
BiblePay

@biblepay
biblepay committed 29 days ago
 
[v0.14.0.x] Update release notes with change log (dashpay#3213)

 
Merge pull request dashpay#3202 from codablock/pr_v14_backports
 
Commits on Nov 20, 2019
1.4.7.7 - Mandatory Upgrade for TestNet

@biblepay
biblepay committed on Nov 20
 
BiblePay - TestNet

@biblepay
biblepay committed on Nov 20
 


Capping @ 3mil due to our low price.


6
Archived Proposals / Kairos Childrens Fund Recurring charges Nov 2019
« on: November 30, 2019, 07:49:50 PM »
11B   Helena NARCISO   1 - EL   $20
14B   Princess CABUGNASAN   4 - EL   $20
12B   Tajana Veroso   5 - EL   $20
13B  Pepe Gabriel   12 - SHS   $25
16B   Earl Darren Chiu   5 - EL   $20
Rowena Paladar   11 - SHS   $25
12B   Dante Balansag   10 - HS   $23
10B   Jovelyn Cadusale   11 - SHS   $25
17B   Kate Rebutazo   10 - HS   $25
      $203


Andy is requesting 1,201,283 bbp to pay 9 of our children up (out of 21) to the end of 2019.

Our total portfolio contains these children at $20-$25 per month:

Eda Mae Omotong
Shane Marie Francisco
Wendy Domik
Rhyejiam Cielo Alqiza
Brent Aaron Cresencio
John Gabriel
Jill Jangin
Ruth Alos
Jacious Amil
Kate Rebutazo
Genevieve Umba
John Rendal
HELENA-NARCISO
DANTE-BALANSAG
PEPE-GABRIEL
PRINCESS-CABUGNASAN
ROWENA-PALADAR
KENT-SUAN
ANGEL-OZOA
JOVILYN-CABUSALE
MARKKIS-UMBA


Requesting 1.201MM from the foundation to pay Andy during the non-POOM to POOM bridge era.


7
Production Proposals / PODC TEAM REQUIREMENTS
« on: November 22, 2019, 11:51:35 AM »
I believe this poll is relatively self explanatory  :o , but please ask any questions if I missed something.

Thank you for voting!


8
Archived Proposals / Payroll Nov 2019
« on: November 19, 2019, 10:18:52 AM »

MainNet commits:

Commits on Nov 1, 2019
1.4.5.2-Leisure Upgrade

@biblepay
biblepay committed 18 days ago
 
Commits on Oct 30, 2019
1.4.5.1c-Leisure Upgrade

@biblepay
biblepay committed 20 days ago
 
Commits on Oct 24, 2019
1.4.5.1b-Leisure Upgrade

@biblepay
biblepay committed 26 days ago
 
Commits on Oct 23, 2019
1.4.5.1-Leisure Upgrade

@biblepay
biblepay committed 27 days ago
 
Commits on Oct 21, 2019
1.4.5.0d-Leisure Upgrade

@biblepay
biblepay committed 29 days ago
 
1.4.5.0c-Leisure Upgrade

@biblepay
biblepay committed 29 days ago
 
Commits on Oct 14, 2019
Merge pull request #22 from sunk818/patch-1

@biblepay
biblepay committed on Oct 14
 
Merge pull request #23 from sunk818/patch-2

@biblepay
biblepay committed on Oct 14
 
Commits on Oct 11, 2019
1.4.5.0b - Leisure Upgrade

@biblepay
biblepay committed on Oct 11
 
1.4.5.0-Leisure Upgrade

@biblepay
biblepay committed on Oct 11

Also I worked on NOMP for 60 hours this month.



Capping @ 3 mil due to budget constraints.


9
Pre-Proposal Discussion / MOVED: Dynamic Whale Staking
« on: November 12, 2019, 09:09:12 AM »

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




11
Active Discussions / TestNet - PODC 2.0 (Proof of Distributed Computing)
« on: November 01, 2019, 08:31:27 AM »
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







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





13
Production 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.














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





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


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