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.

Messages - Rob Andrews

Pages: [1] 2 3 4 5 6 7 8 ... 137
Production Proposals / Re: New Exchange - Coinsbit
« on: October 19, 2019, 06:29:37 pm »
Yes, over a week ago, I applied to most of the top 50 exchanges on CoinGecko, sorry for all the emails you probably got Rob LOL, and are probably still getting (and before that I applied to 10-15 exchanges on CoinMarketCap)

Looks like I filled out listing request for Coinsbit 8 days ago, Nick reached out to me over email 4 days ago, I explained our situation up front, his standard offer seemed to be (1.5btc) and he was confused how we donated so much to charity but our budget was so low haha, I meant to email him back explaining further but it got pushed down my email list, glad he reached out to you Rob

And thanks for doing the project, we learned a lot - and with any luck we might have the best deal we ever had if they are bigger than bittrex!

Production Proposals / Re: New Exchange - Coinsbit
« on: October 19, 2019, 06:28:33 pm »
What do you see as the benefit of getting on another exchange?

Do you think additional exchange will dilute the volume?

What trade pairs are initially being offered?

Do any of the non-profits that wish to liquidate benefit from a new exchange? For example, a BBP to USD pair and easy withdrawal might streamline the process for USA non-profits?

These are good questions, and be assured that I am of course very cautious now after getting burned and seeing some of the assumptions go down the toilet.

However fortunately I also had (a short run) at success, when we were listed on bittrex with gridcoin (although, later they dropped us due to the NY SEC regulations), but, this is still a relationship that makes a stand as related to bbp.

So I feel that our non-profits would not gain much of a benefit by having us on yet another exchange, unless liquidity deepens and our price rises.
However, I don't feel that our price is diluted by being on an additional exchange; I feel adding Europe to the mix strengthens BBP in areas where we don't have traders.  I do believe the unique monthly web visits and unique accounts on coinsbit may increase our total volume, but this is speculative.

When GRC was listed on Bittrex, the price went from 30 satoshi to about 100 overnight and stayed there for as long as we were on bittrex.  So, the unique account breadth can certainly help BBP, if Coinsbit is as big or bigger than bittrex.

This is the point I feel we missed with our last deal.  I was relatively certain that the deal would be at least a lateral move (where we increase our price a few sats and are able to pay for the deal).  I didnt expect it to do absolutely nothing.

So, this is the essence of the deal, if coinsbit has "real" volume, and not "fake" volume, and "real" distinct accounts, I think it would be worth 1 btc - primarily because of how much we have at stake now - another words, this additional deal may 'average out' our last bad deals if we are lucky, and pull us out of the dumps, or at worst we go sideways and have a long back bill to pay - but gain a quality exchange for the future.


The pair would be BTC/BBP.  I sent an e-mail to Nick to double confirm this would be the case.

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 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 recommend lowering ABN to 25,000 to attract more users.  I think we can leave ABN in the code so as to help remove potential botnets.  However, it could be argued that the ABN is over-complicating BBP and it is complicating the pool (and adding requirements for unlocking wallets etc).  Lets talk about this in more detail.

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

Production Proposals / New Exchange - Coinsbit
« on: October 19, 2019, 10:07:41 am »

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

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

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

Production Proposals / cameroon-one installment 5 2019
« on: October 19, 2019, 09:55:56 am »
We sponsor 11 cameroon one children totaling $4800 per year.  We have paid $4279 and we owe $521 to be paid up through the end of 2019.

Due to our limited budget, I am asking for 700,000 (IE we will need to enter another proposal next month to cover the remainder).

Production Proposals / Payroll Oct 2019
« on: October 19, 2019, 09:46:36 am »
Since we have limited funds for payroll this month, I will only include hours for 'porting POBH to CPU-miner'; capping at 1 mil:

AMOUNT: 1 mil

Pre-Proposal Discussion / Re: Exchange Listing -
« on: October 04, 2019, 08:16:30 am »
It looks like they offered us a quote for 4 btc.

But how would we pay that fee?

I think looking at the budget, we have a deficit of about $2000 per month for the next year (as this month we had to skip the compassion payment), not enough for payroll (I have to start taking a 50% pay cut now), and also BBP owes me almost 1.9 btc for tokok still.

So I think we have a budget of more like .25 btc for a new exchange until we pay off the tokok deficit; and be candid I think the .25 would have to spread out over at least 6 months (.25 is too much for us to handle in one month even in our current condition).  In reality unless we get a really killer deal, I dont think we can afford another exchange, or any new payments unfortunately. 

Production Proposals / Re: Lower ABN Requirement?
« on: October 02, 2019, 08:50:54 pm »

So if we lower the ABN requirement, do you have any concerns that could lead to more forking? I know that was one of the concerns when you first implemented this functionality. Also would a lower ABN then lead to higher difficulties on blocks? Thoughts?

Well I have pretty great news in that dept!

The great news is we found the cause of the fork (luckily because of a few smoking guns between different broken down sancs over the 3 or so we experienced).
I had a network of sancs for a while (before apollon) and I was able to run a report - similar to the sanctuary health report we have now.
Basically, our code (prior to 1447) had a gobject propagation issue - primarily because 40% of the network did not upgrade during the *last* mandatory (the one 75 days ago).

Anyway - I believe *all forking* was a result of bad GSC vote propagation.

Heres the scenario:
When the contract came up, 40% of the network who didnt have the votes didnt honor the superblock.

Another words, our ABNs work fine at any level.

The other evidence I have, is testnet is rock solid now - and it has a diff below 1.
So not only are ABNs ok at any level, but Diff is OK at any level.

On another side note, once we implement chainlocks we also wont have to worry about 51% attacks either.

So basically it should not matter.

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

Hi Everyone,

So with DSQL/Christian Spaces coming out, we have a lot related to the Develop QT wallet we can test in the DSQL thread.

Im going to keep both threads open, but I invite you all to join me here for a while:

Because we will be having a new testnet develop release tonight with some new features and you all can help test those in the bitcointalk thread.


Thats great!  I'll be back after we release this mandatory in mainnet.

Things look pretty solid in testnet so far.

Thank you. It was not working with ip:port but adding port=8080 as an extra line in the config works. Now shows ready.

Syncing was not the issue. I accidentally deleted the entire .biblepayevolution folder but I learnt my lesson from before and restored from a backup wallet.dat. So all 3 sancs synced and ready.

Thats great!  I'll be back after we release this mandatory in mainnet.

Update to non standard port not working

The sanc appears enabled on the list but is unable to connect to the non standard port.

 >sanc status
Code: [Select]
  "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
  "service": "",
  "proTxHash": "71ac8f0a0b11a7070b4aa2e1862c19a8c5d5106bc5172502ebe8ce87772afc5d",
  "collateralHash": "24ba631e105c9f1d1923fe32d9c534e51556cddb15f625a5c42d5c902c868583",
  "collateralIndex": 1,
  "dmnState": {
    "service": "",
    "registeredHeight": 6092,
    "lastPaidHeight": 6097,
    "PoSePenalty": 0,
    "PoSeRevivedHeight": -1,
    "PoSeBanHeight": -1,
    "revocationReason": 0,
    "ownerAddress": "yQkfqAeFpZzwHmpXti7avavNAu6etwCjAn",
    "votingAddress": "yQkfqAeFpZzwHmpXti7avavNAu6etwCjAn",
    "payoutAddress": "yTwJA2VCYQWpWXH8HS7UvEpqRE3Aj5ciUV",
    "pubKeyOperator": "139234c6a2d2f2f449fe5b25006fef684a5be440372756d903f1c793da49812202933c13a8d750ebeb270ea96b62480d"
  "state": "ERROR",
  "status": "Error. Could not connect to"

>sudo ufw status
Code: [Select]
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     LIMIT       Anywhere                 
8080/tcp                   ALLOW       Anywhere                 
40000/tcp                  ALLOW       Anywhere                 
9998/tcp                   ALLOW       Anywhere                 
19998/tcp                  ALLOW       Anywhere                 
40001/tcp                  ALLOW       Anywhere                 
22/tcp (v6)                LIMIT       Anywhere (v6)             
8080/tcp (v6)              ALLOW       Anywhere (v6)             
40000/tcp (v6)             ALLOW       Anywhere (v6)             
9998/tcp (v6)              ALLOW       Anywhere (v6)             
19998/tcp (v6)             ALLOW       Anywhere (v6)             
40001/tcp (v6)             ALLOW       Anywhere (v6) 

1) It appears your remote sanc node is not listening on 8080 (I tried to telnet to it).
Try to add "port=8080" to your sanctuary config file and restart it.

2) Were you able to resolve not being synced yesterday, was it a non issue?


Will instructions differ for someone who creates a sanctuary after having bought 4.55M from an exchange and want to self-host?

The upgradesanc only applies if a 4.55M sanctuary already exists but upgrading to a newer version?

I want to write a sanctuary set up guide but it is not clear what the sanctuary creation options are.

Well, its not that the instructions change based on receiving the funds, its more of which route you want to go when you create the deterministic sanc:

Route A)  If you follow the Dash instructions, they are a full page and pretty complicated. 

Route B)  We ask you to create the sanctuary the legacy way, and that allows you to implement the first phase of the deterministic sanc.  Then we ask you to run the upgradesanc command to finish it. 

One other thing to consider is Apollon is actually adding a new twist to this - they are having us add a couple RPC commands for them - one that will allow them to generate the bls privkey first and give it to the user- so there is a great chance we can make a special command that is different than upgradesanc soon, once I hear back from them.

So best bet is to wait for this info.

Hmm am i on a different chain? I seem to have lost the tBBP you sent....

I had to stop the controller wallet to lock the outputs and when i restarted ( several times), the balanced was not updated.

Im still in sync on all my nodes:


getblockhash 5888



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