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
1
Pre-Proposal Discussion / Add Proof-Of-Orphan-Mining
« on: November 13, 2018, 11:38:51 am »
Let's all discuss the implications of proof-of-orphan-mining if added to BiblePay.

From a high level, this would allow a new user to set up the wallet for mining in a much simpler way, and reward the masses for sponsoring personal orphans.


Please see this information first:

https://wiki.biblepay.org/Concept_POOM


2
Pre-Proposal Discussion / Should we remove the BOINC Team Blacklist (PODC)?
« on: November 07, 2018, 12:19:16 pm »
If we remove the blacklist, members of Gridcoin and Byteball for example will be eligibile for PODC rewards.

3
BiblePay discussion / Integrity Of BiblePay
« on: October 21, 2018, 11:49:37 pm »
I'm adding this poll to get a general feel about our trust level as a coin, and trust level for our algorithm.


4
This is a general poll in response to a message I received where the person claimed I was not operating in a democratic manner, and in general, an attempt to gather the feel of the trust level of the community.


5
Archived Proposals / October Payroll and IT Expenses
« on: October 19, 2018, 01:14:24 pm »
To partially fund some of my own programming hours, I would like to submit Github commits for the core biblepay wallet from
May 1 2018 through June 30th 2018 (I am including two months of work this month since I spent at least 40 hours moving between the end of May and during June):

Commits on Jun 18, 2018
biblepay_sk update 

@OrbisPictus
OrbisPictus committed on Jun 18
 
Commits on Jun 16, 2018
1.1.3.1b-Leisure Upgrade 

@biblepay
biblepay committed on Jun 16
 
1.1.3.1-Leisure Upgrade 

@biblepay
biblepay committed on Jun 16
 
Commits on Jun 15, 2018
1.1.3.0 - Leisure Upgrade 

@biblepay
biblepay committed on Jun 15
 
1.1.2.8b-Leisure Upgrade 

@biblepay
biblepay committed on Jun 15
 
1.1.2.8-Leisure Upgrade 

@biblepay
biblepay committed on Jun 15
 
Commits on Jun 13, 2018
1.1.2.7-Leisure Upgrade 

@biblepay
biblepay committed on Jun 13
 
Commits on Jun 12, 2018
1.1.2.6-Leisure 

@biblepay
biblepay committed on Jun 12
 
Commits on Jun 11, 2018
1.1.2.5b-Leisure Upgrade 

@biblepay
biblepay committed on Jun 11
 
1.1.2.5 - Leisure upgrade, Testnet version for June Mandatory Release 

@biblepay
biblepay committed on Jun 11
 
Commits on May 9, 2018
1.1.2.4c-Leisure Upgrade 

@biblepay
biblepay committed on May 9

Commits on Jun 29, 2018
1.1.3.6-Leisure Upgrade 

@biblepay
biblepay committed on Jun 29
 
Commits on Jun 28, 2018
1.1.3.5b-Leisure Upgrade 

@biblepay
biblepay committed on Jun 28
 
1.1.3.5-Leisure Upgrade 

@biblepay
biblepay committed on Jun 28
 
Commits on Jun 26, 2018
1.1.3.4-Leisure Upgrade 

@biblepay
biblepay committed on Jun 26
 
Merge pull request #27 from thesnat21/master 

@biblepay
biblepay committed on Jun 26
 
Merge pull request #26 from OrbisPictus/patch-2 

@biblepay
biblepay committed on Jun 26
 
Merge pull request #18 from sunk818/patch-1 

@biblepay
biblepay committed on Jun 26
 
Merge pull request #17 from biblepay/add-code-of-conduct-1 

@biblepay
biblepay committed on Jun 26

 
Commits on Jun 20, 2018
1.1.3.3-Leisure Upgrade 

@biblepay
biblepay committed on Jun 20
 
Commits on Jun 19, 2018
1.1.3.2-Leisure 

@biblepay
biblepay committed on Jun 19

Maintained BiblePay Pool in May (as related to assisting users with writing orphans, paying for upvoted letters, and code changes
related to orphan business objects):  16 hours total


For a grand total programming time of
   (40 hrs per week * 4 weeks) = 160 hours @ 40.00 per hour = $6400 (over two months)

For a Grand Total Proposal of :  $6,400.00

Equaling:

?6471.00/.000515 (CoinMarketCap) = 12.5 million biblepay
Since I don't want to exceed 50% of the IT budget, I'll cap this proposal at 3.5 million and gift the rest to biblepay.


Thank you for your consideration.


6
Archived Proposals / October recurring Compassion.com sponsorships
« on: October 13, 2018, 10:25:28 pm »
Each month we sponsor approximately 100 children at compassion.com. (309 children as of last month/ 100 as of October 15th 2018).

Rob, the lead dev pays the expense and uploads a copy of the receipt. 

The expenses can be viewed by navigating to Accountability.biblepay.org | Expenses and viewing the PDF.


All funds raised by this endeavor are spent at compassion.com, with any excess going to prepayments for the future (the prepaid amount is stored at compassion in the biblepay.org account).

To see the amounts we raised in the past by selling BBP for bitcoin see this page:
 See accountability.biblepay.org | Orphans | Orphan Fundraisers.  You can audit the total by finding the sum of all fundraisers.


I am requesting  6,000,000 bbp (which is approx $4000 - this is $200 more than our monthly base payment ($3800)).



7
Archived Proposals / Faucet Refill - pool.biblepay.org
« on: October 13, 2018, 03:53:31 pm »
Pool.biblepay.org has spent 326,100 on the faucet giveaways over the last 60 days.

75% of this activity was based on Jaap's airdrop coordination program (giving away 2000 then 1000 to new users) through the airdrop.

I am requesting 500,000 for a refill - primarily due to the expected influx of new boinc users coming in from non BiblePay teams starting October 16th 2018.


8
Archived Proposals / Helping Widows in their Distress
« on: October 13, 2018, 01:28:20 pm »
In the spirit of James 1:27, I would like to introduce BiblePay to "Hope For Widows", asking BiblePay to be kind enough to consider that we also help Widows. 

I feel that helping widows will not only help display our compassion globally, but it will also help convince God that we are listening to his commands: to be cheerful givers, and follow his commandments.  We also will be involved in something that is for women primarily (although I am not deliberately singling out females), but we will be introducing some non Christians who have never helped a widow to watch our example, and have less risk of hearing "Depart from me you workers of iniquity... I never knew you".

First I did check the top 3 (via google) Widow organizations, and I do not claim by any means that Hope for Widows is absolutely #1.  I felt after reading their FAQ about what they do for women (they comfort them in a time of grief, they talk to each other as a community and help work out each others problems, they donate money to widows who are going through financial issues), and HFW has more than 10,000 enrolled widows, but I got the feeling when I researched HFW that the money was spent efficiently (more appears to be done with each dollar, in contrast to some of the others who hold meetings in central places and require everyone to fly there etc).

Take a look at the FAQ page first before deciding, see what the widows say about HFW:
https://hopeforwidows.org/resources/widows-weve-helped/

To spearhead this initiative I feel we should start small (especially with our small budget), so let's just start at $300.00 for the month of October 2018 and also, if some would like to call HFW and do more research feel free to vet the organization, and make more recommendations on if we should increase/decrease next month based on what we accomplish.

(BTW: We will be receiving a credit this month for Compassion, so the funds for this are definitely available this month.)



Edit: 
I went ahead and donated since I was already on the web site, hopefully this will be voted in :).

http://pool.biblepay.org/san/Expenses/hfw_oct2018.pdf


9
Trading / Buying a Sanctuary
« on: October 05, 2018, 08:36:15 pm »
I'm interested in buying a sanc today - Im offering .14 BTC for 1,550,001 bbp - any takers?

My receiving address is : BBDzkakNnabm2R4Xb1bZkbNRdeTUv9VqJG


10
Archived Proposals / August 2018 IT and Payroll
« on: September 11, 2018, 11:17:40 am »
To partially fund some of my own programming hours, I would like to submit Github commits for the core biblepay wallet from
April 1 2018 through April 30th 2018:
(Note that in July I expensed March commits, and I didn't enter any payroll in August due to our low price).
Commits on Apr 24, 2018
1.1.2.4b-Leisure 

@biblepay
biblepay committed on Apr 24
 
1.1.2.4-Leisure 

@biblepay
biblepay committed on Apr 24
 
Commits on Apr 23, 2018
1.1.2.3-Leisure 

@biblepay
biblepay committed on Apr 23
 
Commits on Apr 20, 2018
1.1.2.3-Leisure 

@biblepay
biblepay committed on Apr 20
 
 
Commits on Apr 18, 2018
1.1.2.2 - Mandatory for Users, Leisure for Exchanges 

@biblepay
biblepay committed on Apr 18
 
Commits on Apr 16, 2018
Create CODE_OF_CONDUCT.md

@biblepay
biblepay committed on Apr 16
 
Commits on Apr 15, 2018
1.1.2.1-Leisure 

@biblepay
biblepay committed on Apr 15
 
Commits on Apr 14, 2018
1.1.2.0b-Leisure 

@biblepay
biblepay committed on Apr 14
 
1.1.2.0-Leisure 

@biblepay
biblepay committed on Apr 14
 
Commits on Apr 12, 2018
1.1.1.9l-Leisure 

@biblepay
biblepay committed on Apr 12
 
1.1.1.9k-Leisure 

@biblepay
biblepay committed on Apr 12
 
1.1.1.9j-Leisure 

@biblepay
biblepay committed on Apr 12
 
1.1.1.9i-Leisure 

@biblepay
biblepay committed on Apr 12
 
Commits on Apr 11, 2018
1.1.1.9h-Leisure 

@biblepay
biblepay committed on Apr 11
 
1.1.1.9g-Leisure 

@biblepay
biblepay committed on Apr 11
 
1.1.1.9f-Leisure 

@biblepay
biblepay committed on Apr 11

ommits on Apr 10, 2018
1.1.1.9e-Leisure 

@biblepay
biblepay committed on Apr 10
 
1.1.1.9d-Leisure 

@biblepay
biblepay committed on Apr 10
 
1.1.1.9c-Leisure 

@biblepay
biblepay committed on Apr 10
 
Revert "1.1.1.9b-Leisure" 

@biblepay
biblepay committed on Apr 10
 
1.1.1.9c-Leisure 

@biblepay
biblepay committed on Apr 10
 
Merge pull request #8 from svirusxxx/master 

@biblepay
biblepay committed on Apr 10
 
Merge pull request #6 from mymosh/gcc-7.2.0 

@biblepay
biblepay committed on Apr 10
 
Merge pull request #1 from nelfwarrior/patch-1 

@biblepay
biblepay committed on Apr 10
 
1.1.1.9b-Leisure 

@biblepay
biblepay committed on Apr 10
 
@biblepay
biblepay committed on Apr 10
 
Commits on Apr 5, 2018
1.1.1.9-Leisure 

@biblepay
biblepay committed on Apr 5
 
Commits on Apr 3, 2018
1.1.1.8c-Leisure 

@biblepay
biblepay committed on Apr 3
 
Commits on Apr 2, 2018
1.1.1.8b-Leisure Upgrade 

@biblepay
biblepay committed on Apr 2
 
Commits on Apr 1, 2018
1.1.1.8-Mandatory for Sancs, Leisure for Network 

@biblepay
biblepay committed on Apr 1
 
1.1.1.7-Mandatory for Sancs, Leisure for Users 

@biblepay
biblepay committed on Apr 1

For a grand total programming time of
   (40 hrs per week * 4 weeks) = 160 hours @ 40.00 per hour = $6400

Also, I would like to expense the following IT expenses for Biblepay:
Exchange e-mail inbox (1 year: for one director) $71

For a Grand Total Proposal of :  $6,471.00
Equaling:

?6471.00/.000474 (CoinMarketCap 7-21-2018) = 13.6 million biblepay
Since I don't want to exceed 50% of the IT budget, I'll cap this proposal at 3.5 million and gift the rest to biblepay.


Thank you for your consideration.

11
If the poll passes to remove the team requirement, what percentage of reward should we give to non-biblepay BOINC crunchers who fully associate their biblepay wallet with their CPID and post a valid UTXO stake for their RAC?


12
Archived Proposals / September Recurring orphanage premiums due - Compassion
« on: September 05, 2018, 08:09:18 am »
Each month we sponsor approximately 309 children at compassion.com.

Rob, the lead dev pays the expense and keeps a copy of the receipt. 

The expenses can be viewed by navigating to Accountability.biblepay.org | Expenses and viewing the PDF.


All funds raised by this endeavor are spent at compassion.com, with any excess going to prepayments for the future (the prepaid amount is stored at compassion in the biblepay.org account).

To see the amounts we raised in the past by selling BBP for bitcoin see this page:
 See accountability.biblepay.org | Orphans | Orphan Fundraisers.  You can audit the total by finding the sum of all fundraisers.


I am requesting  7,000,000 bbp (which is 25% of what we need.).

Due to our low price we will need to terminate approximately half of the sponsorships later this month.
They will be covered by Compassions continued-sponsor-insurance program.




13
All,

  We have 329 orphans sitting at risk currently with a questionable future.  I not only want to avoid attrition, I want to see growth! 

So heres an idea.  I really think we need to consider removing all the roadblocks inside Biblepay (IE Opening the Floodgates) for cancer mining.  We can consider doing this by:  Removing the Boinc team requirement (being the first cryptocurrency to not require a team for boinc), and making it easier to heat-mine.  (IE doing away with the last 4 block rule).  (We can leave in the signed by CPID rule as a lateral move preserving heat-mining security).

I feel with this change, we can test the theory that more miners = more adoption = higher price = more monthly orphan sponsorships.

Also, as Noxpost suggested, I dont see why we cant write our own boincstats report (as we will still have records of our Biblepay participating CPIDs, RAC, TotalRAC etc).  So we really only lose the "BiblePay BOINC Team" statistics in boincstats, but instead we have our own stats page.  Maybe that internal stats website is something T-Mike would like to take on for us?

So, as you can see I'm pretty zealous for success here, and want us to make a comeback.  Therefore I believe its in our best interests to vote on this change.

Proposed Changes:

- Remove Boinc Team Requirement for users participating in BiblePay PODC (this compensates users for Rosetta or World Community Grid on ANY team)
- Refactor Heat Mining Block acceptor to help minimize the possibility of forks
- Still require signed cpid per block, and CPID must not be within 3 solved blocks
- Remove the rule requiring CPID to be in the last superblock
- Work with a team member to help create our own stats report for a website and/or the pool
- Leave in UTXO requirement for Boinc Miners

Desired Outcome:

- A new boinc user who is crunching for XYZ discovers they can be compensated for Rosetta cancer mining through Biblepay.
 The new user loads our wallet, syncs, and associates their XYZ cpid with our wallet. 
(The new user still must have a required balance shown in exec totalrac to PODC mine).

- The user is able to heat mine with the signed cpid immediately, as long as the CPID has RAC > 100.

This removes most of the strange pool errors in pool.biblepay.org and purepool.


One notion is that in general, I assume BOINC users to have enough disposable income to afford expensive computers for volunteer computing, therefore I come to the conclusion they may become biblepay investors through this process.

And, to counter the theory that we are "giving away free money", consider the fact that the ones who do not become investors will sell off the coins cheap on the market and make us more rare.  So imo, this is an economic decision worth considering.

If the idea is a success, all credit to Jesus.







14
Welcome to the BiblePay Testnet thread for IPFS!

To install the latest version for testnet:
Please upgrade to v1.1.4.7+



  • Test attaching a document to a new QT Send Transaction
  • Test double clicking the transaction list and viewing the attached IPFS file hash
  • Test Opening the IPFS document link
  • Test the fee charged for BiblePay storage
  • Assess exact root cause of IPFS instability; when ipfs.io goes down, check to see if reliability is 100% when using our gateway (IE files are still always retrievable and instability is always gateway instability), we need to determine the quality level of IPFS itself

How to install IPFS on a Sanctuary (Ubuntu 64 instructions):
https://raw.githubusercontent.com/biblepay/biblepay/master/InstallingIPFS_Ubuntu64.md

How to launch biblepay-qt in testnet:
./biblepay-qt -testnet -listen=0 -masternode=0

(The listen and masternode flags are only required if you want to run Testnet side-by-side your Prod sanctuary)

Synced Verification Info:

getblockhash 53930
45aa03a87251d06b867e4fbb5e24d87970e18176d1739e609366156423a847fb


To help us isolate and assess any instability I started a gateway server (similar to ipfs.io except http:// and running on 8080):
http://ipfs.biblepay.org:8080/ipfs/QmPVMkWe7976YH22quBotbrDMV9tP4qCz9P5tndveKdeGs/hi.txt
We may want to change the biblepay links to go through this gateway to remove instability.



15
Create DAHF Algorithm for BiblePay / LOCKED - concept related to dahf
« on: August 19, 2018, 08:23:41 pm »
This thread is dedicated to the initial discussion for DAHF; Decentralized Autonomous Hedge Fund.

For a primer on the concept please read this first:
https://wiki.biblepay.org/Concept_DAHF

Some of the concepts we want to cover in this thread (resulting in a proof-of-concept program suite for testnet, and a regulatory review process) are:

A suite of programs:


Block Sync:  This program is designed to standardize financial blocks from the year 2000 on a daily basis up to the current day, with one financial block per day.  Financial blocks are synced by the sanctuaries up to the current day.  A hash algorithm is used (SHA256) to ensure each block's integrity.

Hedge Fund Options Analyzer/Sanctuary (AL):  The Hedge fund options analyzer standardizes raw market data into financial blocks and hashes the blocks.  This program does the majority of the work pertaining to the analysis of various strategies up front: such as Calendar Spread, Bear/bull Verticals, Iron-condors, Boxes, etc.

Portfolio Manager Virtual Machine (VM):  This program allows a portfolio manager to register strategies, thereby creating a virtual portfolio with certain rulesets using our very own hedge fund programming language (similar to a smart contract builder).  Some of the rules include:  The ability to go long or short a security based on richness (IE the Cost divided by the Maximum Gain), theoretical Bjerk Phi future stress test analys(es), Weighting of the contract quantity, trading on signals based on the Vix, option volatility, volume, etc.  This program gives the PM (the Portfolio Manager) a report, containing ROI per cost center, bank balance over time, and detailed trade activity.  This program runs in sanctuaries, and has the capability to emit trade signals based on short-term activity (despite the fact that most portfolios are long term - IE 2 year portfolios).

Black Boxes:  One of the goals for DAHF is to write Black Boxes, these are algorithmic option trading programs that seek to profit using specific strategies and quant (financial specialist) business logic based on a running simulation over time using actual financial data.  We are seeking one major black box per strategy.  Some of these strategies are core concepts, or quant secrets that large trading institutions (like Renaissance Technologies) use.  We are not seeking to reveal Renaissance' internal secrets, instead we are trying to recreate a similar black box that maintains similar performance.  For example, Renaissance has created a reference portfolio of long positions, in which they sub out to a bank who creates barrier options that replicates the portfolio.  In this way they can buy the barrier option and sell the reference portfolio.  They profit from the premium on each security that is short.  This is an example of a synthetic-reference arb.  We seek to create a black box for stat arb designed
 for each concept (per homogenized trading era per strategy) for Biblepay.


Initial Path for General User Investments:

We are discussing several paths of success with DAHF.  Some of these paths explore various methods of investing/liquidating investments into the fund. 

The first method, this method is preferred pending legal analysis: a normal user will buy shares of BBPHF by sending an amount to a BiblePay burn address (dedicated to the hedge fund).  This transaction will contain the users Hedge Fund ID (obtained with an RPC command prior to sending). 

BiblePay core will be modified to provide hedge fund redemptions at the current DAHF NAV rate.  The redemption is done with an RPC command. 
BiblePay core will guarantee the redemption by adding a block-exercise feature.  This feature pays the user and sends a bill to the Hedge Fund.  If the hedge fund is insolvent, the user still is paid the withdrawal, but the hedge fund relationship is terminated and is forced to close down. 

Note regarding the risk to biblepay:  Most of the risk will be removed from BiblePay itself due to multiple factors:  A) We will not be allowed to operate unless we raise a signifigant amount of capital with the prime broker, therefore the fund will most likely have enough money to pay biblepay core during a collapse.  B) During a collapse, even in the worst case scenario, the redemption value per user would be lower (due to a collapsing asset mark to market value), meaning the final payout from biblepaycore would not result in a catastrophic loss for biblepaycore.  We will provide examples of these collapse scenarios.


Mining:


One novel use of the Hedge Fund Quant Algorithm we are developing will be the ability to provide another avenue for Mining!  This is exciting in the sense that we may be able to offer another use case for your CPU, as an alternative to heat mining (and in addition to PODC mining).  However, this will most likely be a mining option for windows machines with large hard drives.  This is primarily because the hedge fund suite will run in .NET, and require large hard disks. 

But what is exciting is we may theoretically be able to dedicate 1 block per hour to DAHF.  I'm monitoring the amount of trading activity DAHF produces, and theoretically with an active biblepay portfolio, we would trade approx. one asset per hour in prod.  The trading would occur in batches, so that the VM may catch up in times of backlogs.  For example, if nothing happened for 3 hours, and then all of a sudden a user solved a financial block in the third hour, this block may contain 5 transactions.  Theoretically the transactions would include opening/closing information in the biblepay blockchain, of actual OPRA codes, quantities and values affecting our hedge fund.


Benefit to Orphans


This concept was kicked around by Luke, Togo, Rob, Chad and Jaap, and we are leaning towards giving a gross 10% (of profits only) - from the hedge fund to the orphans, as a separate transaction - distinct from the core wallet - from the hedge fund only - annually at the point of time when the annual statement is being created (to avoid any short term mistakes).  The idea is that this hedge fund would always bless orphans first, then non-greedy investors would profit after.  I feel the high potential ROI could overcome the burden and that God will bless our project if we keep the children in mind first.



Pages: [1] 2 3 4