Bible Pay

Read 2058 times

  • Rob Andrews
  • Administrator

    • 2123


    • 29
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Adding QT (Quantitative Tightening) to Evolution
« on: April 07, 2019, 01:58:33 pm »
QT - v1.1


This is a proposal to add an enhancement to BiblePay Evolution - and potentially test it in testnet if approved.

This feature, called QT (not to be confused with the QT Company or the QT wallet), called Quantitative Tightening, is something similar to a feature found in Goldman Sach's cryptocurrency design for their trading crypto: but in their case, they wanted the money supply to loosen when *trading* demand was low and tighten when demand was high - and they were basically trying to create a currency that was friendly to profit off of trading moves.  But, In my humble assumption, I assume this type of crypto would allow Goldman to set up trades with groups of counterparties who would then profit off of the move(s).

However at BiblePay, this feature didn't catch my eye for us as that is a different line of business, but a variant off this model did.

Instead, we are proposing that we create an algorithm where money supply (new coin issuance) dries up when the market price is below the "acceptable useful price" and normal emission operations resume when the BBP price is above the threshhold target value.

QT was partially coded by Rob as proof of concept at that time - but we got busy then we actually never discussed it in a thread (fully).

Let me first explain the algorithm and the parameters:

Market Price: This is the price in USD BBP is trading at : this is currently $0.000256 USD (1.58%) on coinmarketcap.
Acceptable Useful Price:  This is the Target price we all want BBP to trade at (IE .01 USD for example) in that case, that is 39.06* higher than where we are now.
Cumulative Deflation percent per day:  This is the Quantitative Tightening Rate per day, or the amount of decrease in our emission per day.  If this number is set to 1%, we would emit 1% less coins per day across the board.  So as an example, if we emit 1 million BBP per day on day #1, On Day #2, we would emit 990,000 coins.  On day #50, we would emit 50% less, or only 500,000 coins.  (Until the AUP is reached).  If it is never reached we stay at the CDP cap level (see next parameter) indefinitely.
Business Logic: When the AUP is breached, the Cumulative Deflation percent per day starts to Shrink in reverse by 1% per day.  So for example, if our CDP was at 60% when biblepay breached the AUP, the next day the CDR would be 59, the next 58.

CDP Tightening Cap %: If we set this figure to say 50, this means we would stop tightening at 50%, and maintain this tightening status per day until the AUR is reached.
Price Information Gathering:  The Sanctuaries will have code that makes them smart enough to pull the BBP price (from a source similar to CoinMarketCaps API), and automatically agree on this price in a smart-consensus, and they auto-vote on the price to agree.  Therefore the core wallets will all know the price of BBP per day and may display the price on the overview page and in the RPC.  We can also display the current QT level on the overview and the rpc.

Let me give a live, real world example so most questions are expelled early:

Day 1: We go live with QT and our price is .000256.
We go live with a Target price to .01 USD/BBP (via Sanc vote), a Max CDP Tighetning cap to 65%, the Daily Cumulative Tightening % to 1% and go live.

Day 2: Sancs vote on a price of .000256.  QT increases its tightening to 1%.  Coins emitted are 1% less.
...
Day #30: Sancs vote on a price of .000300.  Qt has a tightening level of 30%.  Coins emitted are 30% less.
...
Day #60: Sancs vote on a price of .000600.  Qt has a tightening level of 60%.  Coins emitted are 60% less.

Day #90:  Sancs vote on a price of .001200.  QT still has a tightening level of 60%.  Coins emitted are 60% less.

...
Day #200: Sancs vote on a price of .01101.  (QT *was* at 60% this day),
 QT realizes we have breached the target.  QT decreases to 59%.
 Coins emitted tomorrow are 59% less (IE full normal emission).

Day #201: Sancs vote on a price of .01100.  QT Was at 59%.  QT is now at 58%.

Day #202:  Sancs vote on a price of .00955.  QT realizes the price is below the AUR.  QT sets the tightening level to 59%.
...

Cycle continues forever. 



So from my perspective, this would be an interesting feature to add to Evolution.  If it becomes a bad expiriment, we can vote to turn it off via spork.  I feel that the feature gives us a chance for "free advertising" in that our price will potentially rise up the ranks, and this will cause cumulative additional interest in us.  Also, we *may* be able to help more orphans with a higher price (if QT causes more people to join, and catches on) causing a positive propensity of use of biblepay.

Btw, someone asked me back when we first discussed this idea, should we cap emissions on both the governance budget and the GSC budget and the miners and sancs, or just mining emissions?  In this revision, I feel we should tighten emissions in *all* areas, as a global tightening.  The reason I say this is for one it keeps our entire codebase clean and simple.  For two, it will add less uncertainty and less volatility to the idea.  And finally I think we could effectively govern even if the budget is shrinking (but the price is rising) without much trouble (in contrast to having a very low price and a high quantity of coins to spend each month).

So for this proposal, I propose to Code QT as a feature so we can release it to testnet and test it in Evo, and then release it with the release.

I propose a 60% max tightening cap, and a .01 price target for Biblepay, and a resurrection of Togo's Operation One-Cent along with the release of Evo.

EDIT:  This proposal has been revised to v1.1 with the following changes:
The CDP will now increase from 0-60, but reverse from 60-0 in 1% steps.


« Last Edit: April 08, 2019, 11:14:55 am by Rob Andrews »


  • strayapple
  • Newbie

    • 8


    • 1
    • September 04, 2017, 08:12:57 am
    more
Re: Adding QT (Quantitative Tightening) to Evolution
« Reply #1 on: April 08, 2019, 04:18:14 am »
I vote no. Market prices should follow the trend of BBP, not the opposite


  • inblue
  • Newbie

    • 40


    • 4
    • December 20, 2017, 03:41:42 pm
    more
Re: Adding QT (Quantitative Tightening) to Evolution
« Reply #2 on: April 08, 2019, 05:02:32 am »
I vote yes. But I would like to discuss:

Why is an instant (i.e. 24 hrs) reset to 0% better than a gradual one, like with the tightening of 1% per day? I don't think that sudden emission changes would be good/stable for the market. Why not loosen 1% per day when the AUP is reached? So it would not go 50% -> 0% in a day, but 50% -> 49% -> 48% -> ... -> 0%. And if the price falls below the threshold again, if it was on e.g. 21% at that day, it will then continue correcting from there, and not restart from 0%.

Moreover, why not go fully elastic (like a rubber band) so that when we are close to the threshold, apply only slight tightening, and when we are far away from the threshold, then apply a big modifier, regardless of the number of days passed. Something like this:

Price: 0.001, QT: -50% (doesn't matter if it's day 1 or day 100, the modifier is applied every time the price equals the set amount)
Price: 0.002, QT: -40%
Price: 0.004, QT: -30%
Price: 0.008, QT: -20%
Price: 0.016, QT: -10%
Price: 0.032, QT: 0%

Note that I set the "0% threshold" higher than the wanted price (AUP), because otherwise the modifier would be tiny (i.e. a few percent) when it's close to the AUP, so it may never reach the AUP because of the few percentages not making any real difference. Also, the tightening should be non-linear.

Compared to this, in the original proposal, I think what would happen is the miners would wait for the AUP and then they would massively sell everything for that higher price, which would, along with the instant reset to 0% tightening, plummet the price to what we started with, and then repeat the process. Or more logically, they would sell close to the AUP, which means that the AUP would be very hard to break (go higher), because of the selling pressure, since everyone knows that after the AUP is reached, the price will go down. Or it could also be manipulated of course, by whales looking for a cheaper deal, so they pump the price until AUP and then reap the benefits of buying at lower prices a few days after that. On the other hand, if we have this elasticity or something similar, there would be no such huge market swings or manipulation.


  • Rob Andrews
  • Administrator

    • 2123


    • 29
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: Adding QT (Quantitative Tightening) to Evolution
« Reply #3 on: April 08, 2019, 11:10:41 am »
I vote yes. But I would like to discuss:

Why is an instant (i.e. 24 hrs) reset to 0% better than a gradual one, like with the tightening of 1% per day? I don't think that sudden emission changes would be good/stable for the market. Why not loosen 1% per day when the AUP is reached? So it would not go 50% -> 0% in a day, but 50% -> 49% -> 48% -> ... -> 0%. And if the price falls below the threshold again, if it was on e.g. 21% at that day, it will then continue correcting from there, and not restart from 0%.

Moreover, why not go fully elastic (like a rubber band) so that when we are close to the threshold, apply only slight tightening, and when we are far away from the threshold, then apply a big modifier, regardless of the number of days passed. Something like this:

Price: 0.001, QT: -50% (doesn't matter if it's day 1 or day 100, the modifier is applied every time the price equals the set amount)
Price: 0.002, QT: -40%
Price: 0.004, QT: -30%
Price: 0.008, QT: -20%
Price: 0.016, QT: -10%
Price: 0.032, QT: 0%

Note that I set the "0% threshold" higher than the wanted price (AUP), because otherwise the modifier would be tiny (i.e. a few percent) when it's close to the AUP, so it may never reach the AUP because of the few percentages not making any real difference. Also, the tightening should be non-linear.

Compared to this, in the original proposal, I think what would happen is the miners would wait for the AUP and then they would massively sell everything for that higher price, which would, along with the instant reset to 0% tightening, plummet the price to what we started with, and then repeat the process. Or more logically, they would sell close to the AUP, which means that the AUP would be very hard to break (go higher), because of the selling pressure, since everyone knows that after the AUP is reached, the price will go down. Or it could also be manipulated of course, by whales looking for a cheaper deal, so they pump the price until AUP and then reap the benefits of buying at lower prices a few days after that. On the other hand, if we have this elasticity or something similar, there would be no such huge market swings or manipulation.

Hmm, interesting points.

Well first of all, I don't think it would be wise for us to design it to be too strong, IE to peg us to the AUP (.01 USD/bbp), as then we would be creating a stablecoin.  I think we should definitely be free to fly past .01 when that day occurs.  The 'fully elastic' idea might be too controlling.

Also, I think its important not to overcomplicate it much more, as this particular solution should give us a lot of insight to know if it works in v1.0 at all.  IE was it a success after 120 days, or did we discover something *else* that was unaccounted for.

However, I like your point about miners tending to want to crash the market as soon as the price approaches the AUP.  Thats obviously not beneficial for anyone.

So, maybe what we do is simply add one part of your idea:
When we breach the AUP, we dont do a hard reset to 0.  We only reverse and decrease by 1% per day (IE the same param used for the increase) until we finally hit 0 again (if ever).

So this system is sort of a set of training wheels that gives BBP the propensity to gravitate to .01, but instead of removing the training wheels completely we slowly lift them off. 

Biblepay is completely free when the price is above the aup for more than 60 days in this system (if it never drops below .01 again).

This doesn't complicate it too much.  I will add this rule to the OP post so people know what they are voting on.

Thanks for the improvement(s).



  • inblue
  • Newbie

    • 40


    • 4
    • December 20, 2017, 03:41:42 pm
    more
Re: Adding QT (Quantitative Tightening) to Evolution
« Reply #4 on: April 09, 2019, 12:04:05 am »
Great that you thought it's a good idea and thanks for including it in the proposal. You're right, my other suggestion is too complicated, and it's best to keep things simple.


  • thesnat21
  • Administrator

    • 164


    • 15
    • March 28, 2018, 06:37:05 pm
    more
Re: Adding QT (Quantitative Tightening) to Evolution
« Reply #5 on: April 10, 2019, 12:10:34 pm »
I'm against this.

We already have a deflationary stance month to month, and even if we reduce emissions to 0 in the current environment I don't expect this to change the price.

I worry this will ultimately mean we cannot fund any of our obligations if we are cutting mining as well as the monthly rewards.


  • Rob Andrews
  • Administrator

    • 2123


    • 29
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: Adding QT (Quantitative Tightening) to Evolution
« Reply #6 on: April 10, 2019, 12:16:09 pm »
I'm against this.

We already have a deflationary stance month to month, and even if we reduce emissions to 0 in the current environment I don't expect this to change the price.

I worry this will ultimately mean we cannot fund any of our obligations if we are cutting mining as well as the monthly rewards.

Since the #1 factor in price is the existence of supply, I believe the opposite of the first statement personally.

(For #1 to be true we would need to have 0 exchange volume).



  • sunk818
  • Sr. Member

    • 266


    • 9
    • April 24, 2018, 02:02:20 pm
Re: Adding QT (Quantitative Tightening) to Evolution
« Reply #7 on: April 10, 2019, 12:55:42 pm »
Since the #1 factor in price is the existence of supply, I believe the opposite of the first statement personally.

(For #1 to be true we would need to have 0 exchange volume).


Question 1: I thought part of why PoDC was removed partly due to the oracle issue (relying on external data sources). MakerDAO looks at 24 price feeds. How can we mitigate accuracy of price if we have so few exchanges?



Question 2: How does daily emission changes impact "monthly" proposals?


For example:


On day 1 (after monthly proposal ended), I submit a proposal to extend cryptoid explorer for 6 more months.


The daily emission reduces by 1% because we have not reached $0.01 yet according to exchange.


My proposal passes.


What is the monthly budget? Will the quantity of BBP I ask for be filled?


Maybe I don't understand, but the monthly proposal budget could be a moving number?


Question 3: What happens to the Emission Schedule chart? How do you communicate to others the economics of BiblePay if QT is implemented in production?
https://wiki.biblepay.org/Emission_Schedule


  • SEO_Account
  • Newbie

    • 4


    • 1
    • January 12, 2018, 07:33:25 pm
    more
Re: Adding QT (Quantitative Tightening) to Evolution
« Reply #8 on: April 10, 2019, 11:12:39 pm »
I'm against this.

I want to know what I am getting from my sanctuaries in BBP the price will always fluctuate you cannot control the price simply by reducing the emissions there's no guarantee that will work.


  • Rob Andrews
  • Administrator

    • 2123


    • 29
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: Adding QT (Quantitative Tightening) to Evolution
« Reply #9 on: April 12, 2019, 08:28:36 am »
I vote no. Market prices should follow the trend of BBP, not the opposite

I sort of get what you are saying but this proposal is not really the opposite, its more of a decrease in supply when the market price is below the threshhold. 
So technically we are going with the grain when people are buying.  The only time we are opposite is when they are selling and our price is below 1 cent.



  • Rob Andrews
  • Administrator

    • 2123


    • 29
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: Adding QT (Quantitative Tightening) to Evolution
« Reply #10 on: April 12, 2019, 08:31:47 am »
I'm against this.

I want to know what I am getting from my sanctuaries in BBP the price will always fluctuate you cannot control the price simply by reducing the emissions there's no guarantee that will work.
Do know this is a very slow change (not a fluctuation) - unless we are pegged to 1 cent market price.
Its more like your sanc paying 4000 bbp on day 1, and 2000 on day 50, and 1800 on day 60, then staying at 1800 until our price rises to .01. 

I realize we don't know for sure what can happen.  I'm still relatively neutral on this idea, but leaning towards wanting to try this for 6 months.






  • Rob Andrews
  • Administrator

    • 2123


    • 29
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: Adding QT (Quantitative Tightening) to Evolution
« Reply #11 on: April 12, 2019, 08:49:22 am »

Question 1: I thought part of why PoDC was removed partly due to the oracle issue (relying on external data sources). MakerDAO looks at 24 price feeds. How can we mitigate accuracy of price if we have so few exchanges?

Question 2: How does daily emission changes impact "monthly" proposals?
For example:
On day 1 (after monthly proposal ended), I submit a proposal to extend cryptoid explorer for 6 more months.
The daily emission reduces by 1% because we have not reached $0.01 yet according to exchange.
My proposal passes.

What is the monthly budget? Will the quantity of BBP I ask for be filled?

Maybe I don't understand, but the monthly proposal budget could be a moving number?


Question 3: What happens to the Emission Schedule chart? How do you communicate to others the economics of BiblePay if QT is implemented in production?
https://wiki.biblepay.org/Emission_Schedule


Question 1: I thought part of why PoDC was removed partly due to the oracle issue (relying on external data sources).

->  PODC was voted down for a lot of homogenized reasons and this was just one of the 10 or so.  I even go as far as saying 'in the right circumstances' I think PODC could work (as a specific GSC campaign percentage - if those things in that proposal were addressed). 
But on the topic of oracles specifically, I explain that more than one type of oracle exists, and some they are not all bad:
   1) A collateralized contract paying a reward based on an oracle is OK,  2) An oracle where it is provably not tamperable over time is OK, 3) An oracle that does not financially result in fraud.   #4) One that puts a lot of trust into a centralized administrator who holds the keys to the database and could result in financial fraud if coercion took place between one party and another party.
     PODC didnt completely fit as-it-was because it emitted most of our daily coinbase, and we relied on the trust of the two projects very highly.
   The QT consensus algorithm is more like #2 - its decreasing our coinbase, tampering does not result in losses, and our Evo code has a safeguard in it that takes multiple samples and is smart enough to provide continuity if one day fails.  (I also exclaim that I support a decentralized oracle for orphan contracts, under the right circumstances) meaning oracles arent bad if they are provable and dont have coercion risks.
   Regarding the source count, we are OK, because we have over 1 mil volume roughly per day, and QT takes into account the bid and the ask and calculated the midpoint, and also gets the midpoint of BTC and multiplies these, so it is extremely accurate and therefore doesnt change much (since we are usually pegged at a pretty stable bid-ask midpoint in satoshi).
   

Question 2: How does daily emission changes impact "monthly" proposals?

-> As of the last version we create the governance budget limit based on *last months* budget, so planning is possible.  So in your case, the quoted budget of say 13 mil would not change for 30 days.  (And if we were in QT of 50% for 30 days), the Next month budget would pick up that level, and only have 7 mil available, for example.


Question 3: What happens to the Emission Schedule chart? How do you communicate to others the economics of BiblePay if QT is implemented in production?
->  If this passes, I would treat this feature as exactly the same as our dynamic difficulty parameter.
We would add a paragraph to our emission schedule stating the estimated effect on the chart.
We could update the paragraph to be more exact after a year in prod (at that point we would know exactly what the ramifications were to the emissions over time).











  • thesnat21
  • Administrator

    • 164


    • 15
    • March 28, 2018, 06:37:05 pm
    more
Re: Adding QT (Quantitative Tightening) to Evolution
« Reply #12 on: April 12, 2019, 10:01:06 am »
Since the #1 factor in price is the existence of supply, I believe the opposite of the first statement personally.

(For #1 to be true we would need to have 0 exchange volume).

Someone would need to see enough value and invest enough capital to get us to ~20sat for 1c to be viable (at current btc prices).

Currently it would take someone buying 84 Million BBP to get up to that (based on sell orders).   I realize the sell orders could change, but I see more value coming from value-add / adoption than restricting supply.

If QT is implemented, and we cut our superblock to 60%,   that is 40% less we have to support our obligations.  Though currently we seem to hover around the 18m to 1sat buy orders.

I think in a more mature market, QT makes sense but given the current state of the market I worry it will do more harm than good.


Also, this is more of a broad question, but how do these limits affect the total supply of BBP?
If we cut to 60% is it gone for good, or does it get added on later in the emission schedule?
« Last Edit: April 12, 2019, 10:04:09 am by thesnat21 »


  • SEO_Account
  • Newbie

    • 4


    • 1
    • January 12, 2018, 07:33:25 pm
    more
Re: Adding QT (Quantitative Tightening) to Evolution
« Reply #13 on: April 12, 2019, 11:36:52 am »
Supply needs to be restricted naturally by believers and holders. People who invest in sanctuaries and hold the income. Artificially restricting supply does not create demand.


  • Rob Andrews
  • Administrator

    • 2123


    • 29
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: Adding QT (Quantitative Tightening) to Evolution
« Reply #14 on: April 12, 2019, 01:00:17 pm »
Supply needs to be restricted naturally by believers and holders. People who invest in sanctuaries and hold the income. Artificially restricting supply does not create demand.

Hmmm, this is a pretty good argument, possibly the best one.  I'm not convinced completely though, but I do like how you believe in emitting and hodling first.  Good point.  Lets keep this open for a little bit.