Bible Pay

Read 10463 times

  • Rob Andrews
  • Administrator

    • 4097


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
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.













« Last Edit: October 23, 2019, 10:04:45 AM by Rob Andrews »


  • sunk818
  • Global Moderator

    • 521


    • 36
    • April 24, 2018, 02:02:20 PM
    more
Re: BiblePay Evolution 2.0 Changes for Future Growth
« Reply #1 on: October 20, 2019, 01:40:21 PM »

turning off qt is a good idea.



is world community grid (wcg) a possibility instead of rosetta? there are projects that align with children, cancer (smash childhood cancer), and improving infrastructure in places where we support orphans (Africa) :
https://www.worldcommunitygrid.org/research/viewAllProjects.do?proj=comp







http://oncoapop.sdf.org/biblepaymain/emission_table.html[/font]

currently:
monthly super block 10%
mining 25%
sanctuary 25%
gsc 40%

from gsc 40%
... pog 47.5%
... poom 47.5%
... healing 5%


new proposal:
monthly super block 10%
mining 20%
sanctuary 35%
gsc 35%

from gsc 35%:
... podc 80%
... healing 5%
... poom 15%


if the new percentages are correct, does poom 15% cover the monthly 10%. it would still be shored up with monthly proposals after exchange listing fees are paid up?
BH6oxjLkyz3z8FYpvU3ZR7PTZ31Xt9DkXZ


  • talisman
  • Jr. Member

    • 59


    • 15
    • March 26, 2018, 07:42:24 AM
    more
Re: BiblePay Evolution 2.0 Changes for Future Growth
« Reply #2 on: October 20, 2019, 03:05:24 PM »
turning off qt is a good idea.



is world community grid (wcg) a possibility instead of rosetta? there are projects that align with children, cancer (smash childhood cancer), and improving infrastructure in places where we support orphans (Africa) :
https://www.worldcommunitygrid.org/research/viewAllProjects.do?proj=comp


I would second to that based on 2 facts:

1. WCG enables the user to focus his donated resources to a certain subproject of interest (AIDS, childhood cancer etc)
2. Rosetta tasks are rather memory-heavy and long-duration compared to a mix of WCG tasks, and consume more space on the harddrive.

In summary, including WCG in the mix - if PoDC returns - enables contribution from a wider range of users, from laptop owners to SBC-crunchers with freedom to associate with a certain area of research.

If only one project would be selected, then I would vote for WCG.


  • MIP
  • Sr. Member

    • 365


    • 47
    • February 13, 2018, 11:55:52 AM
    more
Re: BiblePay Evolution 2.0 Changes for Future Growth
« Reply #3 on: October 20, 2019, 04:03:13 PM »
I fully agree with each and all of the proposed items.

Great analysis and great work as usual, thank you Rob!


Re: BiblePay Evolution 2.0 Changes for Future Growth
« Reply #4 on: October 20, 2019, 04:20:15 PM »
I fully agree with each and all of the proposed items.

Great analysis and great work as usual, thank you Rob!

+1


  • sunk818
  • Global Moderator

    • 521


    • 36
    • April 24, 2018, 02:02:20 PM
    more
Re: BiblePay Evolution 2.0 Changes for Future Growth
« Reply #5 on: October 21, 2019, 05:48:39 PM »
- Lower 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.


I've been working on a graph of CPK miner. I can show you that 8 ppl are mining more than 33% of the blocks per day.


148 unique cpk. On average, only 20 CPK have gotten 3 blocks or more blocks per day.


If you want more miners (and keep them mining), more "luck" needs to be introduced into the mix. Hash power & a little a ABN can not be the sole determinants for mining a block. That's why I still feel matching hash of miner reward address to block hash will be more effective in recruiting miners and keeping miners with BiblePay. 1 in 16 chance to mine the block means another miner will get an opportunity to mine the block. This allows for block distribution to more miners and provides the positive feedback that single computer miners need. True decentralization of miners will be a big selling point (as opposed to Bitcoin, DASH, etc).


BH6oxjLkyz3z8FYpvU3ZR7PTZ31Xt9DkXZ


  • Rob Andrews
  • Administrator

    • 4097


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BiblePay Evolution 2.0 Changes for Future Growth
« Reply #6 on: October 23, 2019, 08:22:37 AM »
I would second to that based on 2 facts:

1. WCG enables the user to focus his donated resources to a certain subproject of interest (AIDS, childhood cancer etc)
2. Rosetta tasks are rather memory-heavy and long-duration compared to a mix of WCG tasks, and consume more space on the harddrive.

In summary, including WCG in the mix - if PoDC returns - enables contribution from a wider range of users, from laptop owners to SBC-crunchers with freedom to associate with a certain area of research.

If only one project would be selected, then I would vote for WCG.

Sorry, didn't realize we already had replies in this thread.

This is a good point that you and Sun make.

I remember going through this before, everything is like deja vu now.

We ran out of work units at one time in Rosetta.  IBM is bigger than Rosetta.  But Rosetta is pure cancer mining, however WCG has the other vast array of options.
(Also we have some of the integration issues with WCG, special rules).

I'll do this, when we start working on it, Ill make sure we can be generic enough to support either one, and we can discuss WCG only (as long as we can ensure we have cancer mining selected). 

But to clarify, I think we will need to start with one project - even if its WCG, as we will have a plethora of issues if we start by supporting multiple projects.

I think you guys may be correct in that WCG may be the most flexible single project for us and still be able to supply a constant supply of new work units.  With IBM behind them, we should probably experience very high uptime also.



  • Rob Andrews
  • Administrator

    • 4097


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BiblePay Evolution 2.0 Changes for Future Growth
« Reply #7 on: October 23, 2019, 08:36:24 AM »

I've been working on a graph of CPK miner. I can show you that 8 ppl are mining more than 33% of the blocks per day.


148 unique cpk. On average, only 20 CPK have gotten 3 blocks or more blocks per day.


If you want more miners (and keep them mining), more "luck" needs to be introduced into the mix. Hash power & a little a ABN can not be the sole determinants for mining a block. That's why I still feel matching hash of miner reward address to block hash will be more effective in recruiting miners and keeping miners with BiblePay. 1 in 16 chance to mine the block means another miner will get an opportunity to mine the block. This allows for block distribution to more miners and provides the positive feedback that single computer miners need. True decentralization of miners will be a big selling point (as opposed to Bitcoin, DASH, etc).





Ok so basically what you are confirming is that even our current ABN did not stop the 20 CPKs from buying enough ABNs to continually mine 33% of the blocks.

Meaning that on one hand, that gives me more of a propensity to lean toward shutting off ABN - to simplify our pools structures; as Im adding a massive amount of rules that just over complicates BBP, and makes us new user unfriendly for one (and I realize we can accomplish ABN a different way once we add PODC back into the mix).

But to clarify, on this idea about 1/16 luck-chance, I have to say there is no way to do that with hash selection algorithms.  The one you mentioned a while back from that one coin - about hashing a solution wont work (we can go through the algorithm again if you want).  (I hypothesize they went to production and got fooled later).

Let me assert this another way:  The only way to control which miners actually win a block are one of two ways:  Either you create a web front end, with a distinct user account that would be *very* painful to recreate (IE they lose something if they abandon it), or you attach the miner to a distinct authenticated key linked to another system/home address/account, something of value that is very *painful* and causes a loss to recreate it.      But the point is - you always trade some anonymity for the capaibility and that alone drives away a lot of users (adding a web front end reqt for example, or requiring a drivers license ssn no, coinbase account password, etc).  There is no anonymous way to control block selection down to 1/16 miners (none that has ever been known to me or presented to me).  If you were to say for example, lets restrict one block to each of those cpks, they would then split the cpks (so that is not a true solution).

Boinc is not a *bad* solution when we had the back-to-back rule (IE if ABN was removed and we resrict heat mined blocks to PODC RAC > 100 only for example, and then distributed them to 1/16) - thats because the CPID is what is actually *painful* to reproduce and build 1000 rac up again.  Etc. 

(UTXOs of course are like RAC, you must pay to build them up, but of course if you buy them once then we can see they get over-used and abused etc).  One great thing about RAC is it requires constant work.



  • Rob Andrews
  • Administrator

    • 4097


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BiblePay Evolution 2.0 Changes for Future Growth
« Reply #8 on: October 23, 2019, 08:57:36 AM »
turning off qt is a good idea.

is world community grid (wcg) a possibility instead of rosetta? there are projects that align with children, cancer (smash childhood cancer), and improving infrastructure in places where we support orphans (Africa) :


if the new percentages are correct, does poom 15% cover the monthly 10%. it would still be shored up with monthly proposals after exchange listing fees are paid up?


- Great point on needing clarification on proposed monthly budget percentage changes. 

      Let me create those now and edit the OP.  I will update this reply asap.


->  I will also edit the ABN section, based on current feedback, and my 'best known' information up to this point in crypto.
Most likely, the recommendation would be this:
- Simply lower the heat mining reward after chainlocks is implemented, and raise the PODC reward %.
- Alternatively we could distribute heat mined blocks by ranked RAC level breaks -- but - this is opening the coin up to a very high level of complexity and anti fork rules - and requiring us to store all the PODC data in the chain again.  With the first recommendation, we can store all the PODC data in DSQL - because, GSCs are using the SCBL (soft consensus bus logic) in contrast to HCBL. 

So, I think not only for simplicities sake but also for elegance, we should embrace the DSQL idea, and go with : PODC gets disseminated through DSQL, heat mining rewards decrease when chainlocks get enabled, ABNs are removed, PODC budget is increased.



  • Rob Andrews
  • Administrator

    • 4097


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BiblePay Evolution 2.0 Changes for Future Growth
« Reply #9 on: October 23, 2019, 09:53:07 AM »

- Great point on needing clarification on proposed monthly budget percentage changes. 

      Let me create those now and edit the OP.  I will update this reply asap.


->  I will also edit the ABN section, based on current feedback, and my 'best known' information up to this point in crypto.
Most likely, the recommendation would be this:
- Simply lower the heat mining reward after chainlocks is implemented, and raise the PODC reward %.
- Alternatively we could distribute heat mined blocks by ranked RAC level breaks -- but - this is opening the coin up to a very high level of complexity and anti fork rules - and requiring us to store all the PODC data in the chain again.  With the first recommendation, we can store all the PODC data in DSQL - because, GSCs are using the SCBL (soft consensus bus logic) in contrast to HCBL. 

So, I think not only for simplicities sake but also for elegance, we should embrace the DSQL idea, and go with : PODC gets disseminated through DSQL, heat mining rewards decrease when chainlocks get enabled, ABNs are removed, PODC budget is increased.


Ok, to clarify this proposal to be very clear, I added an "Addendum" at the end of the OP post, and this contains a wiki page, with a new proposed breakdown of the GSC percentages - for now, the interim with phase 1 of podc, and then the mandatory upgrade:
https://wiki.biblepay.org/Economic_Changes_Dec_2019

I also added one line in the ABN section - to propose that we shut off ABNs to reduce BBPs complexity and add more miners.

Both changes are highlighted in green.



  • sunk818
  • Global Moderator

    • 521


    • 36
    • April 24, 2018, 02:02:20 PM
    more
Re: BiblePay Evolution 2.0 Changes for Future Growth
« Reply #10 on: October 24, 2019, 02:03:23 PM »

Matching the last hex digit (sha256 of receiving address and sha256 of block hash) means you only have a 6.25% chance (1 out of 16) even after submitting an acceptable nonce. This by design allows other miners to submit a candidate block too. The white paper mentions other rules involved, but matching the hash of receiver address and candidate block will spread the reward around a bit more than it does now. Certainly, CPK (PoG) and CPID (PoDC) is a better way to identify miners but it comes at the cost of anonymity and depending on centralization (CPK) or anonymity (CPID).


If you consider what is required for a miner to keep mining is the reward. Someone who mines 1 block a day will keep mining versus someone finding a block only every 14 days. Already you can see that with ABN off, only a smaller handful of miner get block. At least with 125k ABN, you had more diversity since high hash power was choked out by ABN. This 1/16 idea is like in that is diversifies who gets the block.


I realize you're going with PoDC which will take the bulk of rewards, but if the remainder goes to geokats or bbp41b, that is very discouraging to the other smaller miners.


Sources:


Code is here: https://github.com/getlynx/Lynx/blob/b0ccb859ee03ee89b18d1db72ec4d4a7f4fcff77/src/lynx_rules.cpp#L280


See page 21-22 http://cdn.getlynx.io/2019-03-17_Lynx_Whitepaper_v1.1.pdf


Is the last digit value found in the coinbase address (as a hash) different from the last digit value found in the candidate block hash? If yes, the candidate block is not confirmed and not propagated to peers.
BH6oxjLkyz3z8FYpvU3ZR7PTZ31Xt9DkXZ


  • sunk818
  • Global Moderator

    • 521


    • 36
    • April 24, 2018, 02:02:20 PM
    more
Re: BiblePay Evolution 2.0 Changes for Future Growth
« Reply #11 on: October 24, 2019, 04:49:19 PM »
You also have less predictable times between blocks when difficulty is higher. This is not good for perception. Is there a blockchain problem? Why is my transaction not confirming? Is my wallet okay? If you can keep difficulty low the time between blocks should be more predictable. That's a win-win there.
BH6oxjLkyz3z8FYpvU3ZR7PTZ31Xt9DkXZ


  • Rob Andrews
  • Administrator

    • 4097


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BiblePay Evolution 2.0 Changes for Future Growth
« Reply #12 on: October 24, 2019, 11:09:07 PM »
Matching the last hex digit (sha256 of receiving address and sha256 of block hash) means you only have a 6.25% chance (1 out of 16) even after submitting an acceptable nonce. This by design allows other miners to submit a candidate block too. The white paper mentions other rules involved, but matching the hash of receiver address and candidate block will spread the reward around a bit more than it does now. Certainly, CPK (PoG) and CPID (PoDC) is a better way to identify miners but it comes at the cost of anonymity and depending on centralization (CPK) or anonymity (CPID).

If you consider what is required for a miner to keep mining is the reward. Someone who mines 1 block a day will keep mining versus someone finding a block only every 14 days. Already you can see that with ABN off, only a smaller handful of miner get block. At least with 125k ABN, you had more diversity since high hash power was choked out by ABN. This 1/16 idea is like in that is diversifies who gets the block.

I realize you're going with PoDC which will take the bulk of rewards, but if the remainder goes to geokats or bbp41b, that is very discouraging to the other smaller miners.

Sources:
Code is here: https://github.com/getlynx/Lynx/blob/b0ccb859ee03ee89b18d1db72ec4d4a7f4fcff77/src/lynx_rules.cpp#L280

See page 21-22 http://cdn.getlynx.io/2019-03-17_Lynx_Whitepaper_v1.1.pdf

Is the last digit value found in the coinbase address (as a hash) different from the last digit value found in the candidate block hash? If yes, the candidate block is not confirmed and not propagated to peers.

I remember reading over this before, and replying that I assert there is no way to limit the distribution by a blockhash scheme (unless you add in something painful to be at stake, like a built up reputation score or a built up cost or a built up work-store).

To specifically address the Lynx scheme - and the spirit of this reply is not to destroy or discredit lynx, as I respect the fact that they are trying to lower the cost of operation for each node (and -- I was into green devices and alternative energy for years myself).  However we must analyze the truth of the matter and not give way to implementing a scheme or fallacy (as algos that have a flaw or exploit risk end up lowering integrity of the crypto because then a vector would exist that allows diverting or subverting rewards to a few who are in-the-know and we would not want that stigma) - and Im sure Lynx would not want that either.

So in their case they are awarding the winner by linking the hex suffix (16) combo of the winning blockhash to the hex suffix rank of the coinbase payee address.  This sounds novel on the surface, but the fallacy is you can cancel out the 'lack of ability to mine' by hacking the algo in this way:
- Create 256 receive address keys that have unique hex suffixes - and fund each one with enough Lynx to mine
- For each blockhash to be mined, iterate through the 256 keys
- You now have a single node that can win any lynx block
However, note that this does require you to fund the 256 addresses, but, that is exactly the same scenario as you have with self-funded ABN schemes (meaning a rich miner - can buy into it).
One other problem I see with the lynx idea is it appears to be using scrypt, but running on rasberry-pis.  Meaning that a person could theoretically generate all the blockhashes in one second in a GPU (for every combination possible of their own hash/address's owned by them) and control the outcome of the network - given enough funded addresses pre-stored for the attack.

In summary, the address protection is canceled out in the fraudulent miner, leaving the algorithm with the same protection as our ABN and coin*age schemes (which is essentially a form of Proof of stake), bearing interest on the balance.

In reality, this does not solve the bot-net problem in a more novel manner than PODC.  Out of all of our ideas, so far the most efficient appears to be:  lower the heat reward so it is unprofitable to spend electric on the heat mining side, raise the PODC reward, and reward distinct CPIDs who have a RAC range of say 100 through 10000 for example.  Then if we wanted to we could distribute heat mined blocks to CPID ranges (which *do* afford some protection because CPIDs have a lot of RAC*work at stake one would lose if a hacker tried to duplicate a cpid).





  • sunk818
  • Global Moderator

    • 521


    • 36
    • April 24, 2018, 02:02:20 PM
    more
Re: BiblePay Evolution 2.0 Changes for Future Growth
« Reply #13 on: October 25, 2019, 12:30:32 AM »
That's a good analysis of Lynx Rob. The remainder BBP after PoDC will not use ABN. In lieu of ABN, what are the alternatives? How can you implement a way that uses existing blockchain data to diversify the miners and further mitigate 51% attacks? Recall that in the coinbase transaction, miners specify their own address. This change will propagate up causing all the Merkle hashes to change ensuring that no two miners are hashing the same inputs. In this scenario, I'm not sure how you can game the last two hex digits for coinbase address and block hash. I'm not married to this idea -- I'm just saying without ABN, I'd like to see a blockchain based scheme (no oracle) that will diversify who mines the reward..


If nothing changes, then it'll be a few hardware whales that mine all the blocks and discourage new members from mining. Already, I see difficulty spiking. This person only mined 1 block a day when ABN was on. Now, s/he is 2nd next to pool.biblepay.org and mines over 10% of the blocks daily: https://chainz.cryptoid.info/bbp/extraction.dws?1725459.htm
BH6oxjLkyz3z8FYpvU3ZR7PTZ31Xt9DkXZ


  • Rob Andrews
  • Administrator

    • 4097


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BiblePay Evolution 2.0 Changes for Future Growth
« Reply #14 on: October 25, 2019, 08:29:45 AM »
That's a good analysis of Lynx Rob. The remainder BBP after PoDC will not use ABN. In lieu of ABN, what are the alternatives? How can you implement a way that uses existing blockchain data to diversify the miners and further mitigate 51% attacks? Recall that in the coinbase transaction, miners specify their own address. This change will propagate up causing all the Merkle hashes to change ensuring that no two miners are hashing the same inputs. In this scenario, I'm not sure how you can game the last two hex digits for coinbase address and block hash. I'm not married to this idea -- I'm just saying without ABN, I'd like to see a blockchain based scheme (no oracle) that will diversify who mines the reward..


If nothing changes, then it'll be a few hardware whales that mine all the blocks and discourage new members from mining. Already, I see difficulty spiking. This person only mined 1 block a day when ABN was on. Now, s/he is 2nd next to pool.biblepay.org and mines over 10% of the blocks daily: https://chainz.cryptoid.info/bbp/extraction.dws?1725459.htm

I've been repeatedly trying to explain Lynx' distribution issue - and, I've explained that Lynx will not satisfy either fair distribution of rewards to miners (as a vector exists to defeat the mechanism that provides fair distribution), and that blockchain schemes for POW do not work in limiting bot-net activity.   (As I clarified above without something 'painful' being added in).   (And, remember, the downside of "painful" is a tradeoff for anonymity, hence the reluctance to add something painful in).

You explain how you believe that if a miner specifies his own address, it changes the merkle root and no two miners are hashing the same inputs.  True and false.  True that changing the address changes the merkle root but the mining scheme does not work if you break the ability to mine new transactions (you would not have a miner with a tx list because every tx changes the merkleroot also).  So I dont know what you mean; maybe you mean creating a brand new version of bitcoin with a new transaction list and new type of miner?  If so it will be subject to the same attacks in a different way - because it boils down to the last sentence above.

Regarding oracles, note that with GSC contracts pulling the data from sancs or from dsql, the oracle problem is actually in trusting the data pulled from boincs servers (they are the oracle) (not in pulling the data from our own sancs).  When I said I would discuss removing the oracle, I meant I would open up a separate thread after PODC 2.0 is released, that puts it in conversation mode (as development resources are limited, and it is still necessary to release PODC 2.0 with GSC/DSQL in a similar way that we had when we retired PODC first).  The Oracle discussion, I believe will be interesting because I have two ideas that I believe will actually completely remove oracle risk, but again this is the scope of another thread.  We must focus on shoring up BBP now in response to this specific proposal so let us discuss that separately (that is strictly the ability to gather RAC for each CPID provably, that project). 

Speaking about 'what can we do' to fairly distribute POW rewards, I dont have any other suggestion other than what I said in my prior reply to you - either lower POW rewards and raise PODC rewards, or, make the POW reward payment based on an association to the rank of the CPIDs rac.  Thats it, there are no other solutions because they dont exist, except ones that involve something 'painful' that is built up (a store of value being lost if its hacked).

In summary, this proposal brings back PODC by creating a GSC contract that rewards participants based on CPID rac levels that we gather in our DSQL database, and we store these trends daily.

POBH rewards would be lowered to the point where there is no real financial gain or loss in who mined them (making them fairly random again) because its a true statement:  a botnet that is starved of rewards will cease to exist.  Therefore a random distribution of POW rewards would start to exist.

Regarding 51% attacks:  I already mentioned at least a few times, that a prerequisite to lowering POW rewards is chainlocks.

With chainlocks there are no 51% attacks.  They make us immune to them, otherwise I would not be talking about decreasing the POW reward.
But on that subject, it is probably better just to leave them as random (so that it is never possible for certain high powered CPIDs to try to game the POW side, by being the only ones who can solve them).  After all security is so important that the entire chain relies on it.

So the recommendation here is to just eventually lower the POBH reward to 7%, leave the winners as random, and enable chainlocks simultaneously.

The rest goes back to PODC.