Bible Pay

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Rob Andrews

Pages: 1 2 [3] 4 5 6 7 8
31
Archived Proposals / June Payroll
« on: June 24, 2019, 06:47:28 PM »
 
@biblepay
Commits on Mar 26, 2019
1.2.0.1b-Leisure Upgrade 

@biblepay
biblepay committed on Mar 26
 
Commits on Mar 14, 2019
1.2.0.1-Mandatory Upgrade 

@biblepay
biblepay committed on Mar 14
 
1.1.9.9g-Leisure Upgrade 

@biblepay
biblepay committed on Mar 14
 
1.1.9.9f-Leisure Upgrade 

@biblepay
biblepay committed on Mar 14
 
Commits on Mar 13, 2019
1.1.9.9e-Mandatory Upgrade 

@biblepay
biblepay committed on Mar 13
 
1.1.9.9d-Mandatory Upgrade 

@biblepay
biblepay committed on Mar 13
 
1.1.9.9c-Mandatory Upgrade 

@biblepay
biblepay committed on Mar 13
 
1.1.9.9b-Mandatory Upgrade 

@biblepay
biblepay committed on Mar 13
 
1.1.9.9-TestNet Only RC 

@biblepay
biblepay committed on Mar 13
 
Commits on Mar 2, 2019
1.1.9.8-Leisure Upgrade 

@biblepay
biblepay committed on Mar 2
 3   
1.1.9.7 - Leisure Upgrade 

@biblepay
biblepay committed on Mar 2

Spent 20 hours researching the port to Dash-Evolution and discussing with MIP, and some additional time on conference calls.

Spent 160 hours working on biblepay.
160hrs * 40.00 = $6400 = 9.95M; capping @ 3.00 MM

IT Expenses:
Domain renewal for biblepay.org http://pool.biblepay.org/san/expenses/biblepayorg.png
$62 = 93,312bbp

Hosting for one year (biblepay.org):    http://pool.biblepay.org/san/expenses/hosting2019.png
$95 = 164,644 bbp

32
Archived Proposals / Kairos Childrens Fund PR Event
« on: June 13, 2019, 11:31:48 AM »
Pastor Andrew from Kairos Childrens fund is asking if we would like to have a banner at his 3 day national conference in the Philipines:

These are the packages that we are offering. Check out our website at vismin.winnegor.org
$100 : We will have 2 banners outside the hotel during the 3 day event. One more banner inside.
          The logo and tagline will be at the bottom, small, but readable from the back of the room or across the road

$50 : We will distribute small brochure about your company or product along with the packet that we give them at the beginning of the event.

$50 : We will also post a logo under 'sponsored by' on the website, with a link to the Biblepay website.

$50 : We will have your company or product mentioned at the beginning of the 1st session every day. (as a great cryptocurrency for christians.)
         + $25 : Your business / product will be announced as a major sponsor of the event

* If time permits, I will discuss biblepay with interesting people and pastors.

* We are thinking of
 - http://www.facebook.com/wimdgte
 - http://www.winnegor.org


=-=-=-=-=-=-=-=-=-=-=-=-=-


The event is being held Oct 22 through Oct 25th.

Pastor Andrew will design the pamphlet and the banner for us.


Total charge $250.00 or 625,000 bbp.



33
Archived Proposals / POOM Concept (Proof-of-Orphan-Mining)
« on: June 12, 2019, 04:57:48 PM »
June 12th, 2019

Concept:  Proof-of-Orphan-Mining (POOM)


 ** CLARIFICATION ON WHAT WE ARE VOTING ON, SANCTUARIES:
     The "Divert_50_percent_of_GSC_Budget_to_POOM" poll:

We are voting on creating an additional BiblePay GSC campaign called POOM.  This 50% poll means the budget would be capped at 450K per day.
(This would lower the POG/healing budget by 450k per day).

Each participant would receive rewards in POOM if:
- They have a credit balance with Cameroon for that Child Hex ID

Each daily reward would be capped at the exact amount of the expense.

The budget will not exceed the max 450K under any circumstances (rewards would be divided equally if we are overflowing with children).

(Please vote on the poll that you like the most - we have 3 sizes in ).


**

This concept has been discussed in various forms in the past, but I believe the reason we had no traction was the variants contained unreasonable expectations.  (Our first variation, [email protected] with orphanstats.com, required BiblePay to know personal information for each user (it required trust, contained collusion risk, and tracked personal info; and the poll indicated it was intrusive).    The second variation, asking compassion.com's IT department to create a custom API for decentralized queries, was proposed to Jimmy, CEO of Compassion - and to ciqueue - and all attempts were met with a very high resistance level ranging from not willing to hear the proposal nor have meetings nor nor creating a custom solution for us at this time).

So in light of this, this new concept places a different spin on the idea, and bends both parties a little more, revisiting the idea.  The base idea, imho, has such great potential, it would be a disgrace to ignore and drop the idea in its entirety rather than take another fresh look at re-engineering it to meet in the middle.

Some positive things have also changed in the interim; we now have GSC contracts, which facilitate a much more flexible server side environment for validating the orphan balance consensus in a decentralized way without forks.  This also provides a mechanism to reward home sponsors.

In this adjusted concept, we promote sponsorship of children at home (rather than through our governance superblock).  We do not eliminate our governance superblock; we offer POOM in addition to everything else we already have.  This has the added benefit of allowing the home miner to sponsor a home orphan and write directly to the orphan (1:1 relationship is fostered).  (Alternatively in the future, we may also allow the home user to Choose whether they want to write to the child or if they want our BiblePay-Web to write to the child- more info on this soon). 

Rob has contacted our second largest orphanage, Cameroon One, who is potentially interested in integrating with us.

In this new scenario, we simplify the API requirements, so that we integrate with a simple solution in baby step 1 (in contrast to birthing the complicated baby first, something our vendors do not want to do).  In this way we get a green light to became a partner with our valuable vendor, rather than shut down.

The first part of the concept is here:
http://wiki.biblepay.org/POOM

Part of the desire to create this pre-proposal discussion now is driven by our initial conference call.  I have a soft commitment from Todd, Director of Cameroon, and Shaun, Founder of Cameroon, and Raj (IT/Cameroon), that Cameroon will be on board with BiblePay to go forward with this design, proof of concept, testing and implementation.  (I also had a conference call discussing the IT solution, and we have a potential green light to do this).

Therefore, this proposal seeks to authorize BiblePay IT (devs) to work on this proof-of-concept, for three months, test it with Cameroon, and if it works, seeks to deploy this to production, and reward either 30%, 50%, or 70% (depending on specific sanctuary proposal entered this month) of our daily rewards out of the GSC budget, towards the sponsorship of Cameroon One children in lieu of POOM rewards, strictly for children who are sponsored through this program by miners who sponsor personal children at home through this system.  (The reason I am seeking approval of the entire program now, is it is a considerably large effort for both companies, and I want to see that we have pre-approval for this to move to production and pay production POOM rewards before we program the lions share of this).

Note, in the security section, we intend to create two rules that make this relationship much more than an oracle:

Rule 1:
When a miner wishes to sponsor a new child, they will enter a command in the wallet (IE 'sponsorchild').  When the sponsorchild command executes, they will receive a Child ID (a Cameroon One Child ID).  This will be a distinct global ID that will prevent Cameroon One from giving this child to any other donor!  Therefore, we will enforce a rule where an existing Cameroon One home donor cannot come to biblepay with an existing orphan, they must initiate the orphan through BiblePay.  During this step, Cameroon will create a childhood BIO URL for the miner, and, a tracking code in their accounting system (allowing BiblePay sanctuaries to track this childs balance as charges, and payments are made to this childs record).  We will have daily visibility of each childs balance per miner.

Rule 2:
A public method will be set-up to allow random checks for any orphan sponsored by a miner by a third party auditor (IE a normal end user can check the balance of a child and call Cameroon and check the integrity of the childs status, to ensure the child is with BiblePay).  (This is similar to what we have with Compassion), so that it will be 100% provable that sponsored children through POOM are really sponsored to BiblePay. 


Payment Mechanics:

So that we can scale to the maximum,  I propose that the payment owed to the miner is converted to a daily amount, and awarded as POG points to the miner and paid from the POG GSC budget.  This is primarily so this POOM budget is friendly to our existing POG budget (in that people sponsoring children do not abruptly take over their own program budget but instead part of the POG budget).

Example:

John Doe, Miner 001, CPK 001, Sponsors Abraham, Cameroon One Orphan #ABC, for $40.00 per month.
Since this costs John Doe $1.33 per day, (and our wallet knows the current BiblePay Price thanks to QT), this is auto-converted to 4430 bbp per day (via the GSC contract), and this BBP is diverted from the Total daily POG budget (by converting to points) and added to John Doe's GSC CPK for the day.  (This reduces the available reward for the rest of the GSC participants).
(We can discuss a separate project for POOM, which GSC certainly supports, but imho it would be better to divert POG -> POOM, more on this tomorrow).

If total orphan payments exceed GSC rewards, they then start to be split equally among all participants.

Electric:

As everyone can see, this concept has a huge potential, because it has the effect of diverting normal mining rewards over to orphan sponsorships.

Unlimited BBP Potential:

One other effect that is less obvious, and I intend to create a model for this and paste my hypothesis, is that I believe if we open up the potential sponsorship of outside orphans (as proposed here, through cameroon one) with home users (miners), via USD payment, with the tax deduction (this was confirmed with Cameroon, that the payment is tax deductible) - received by the end-user, as the BBP is remunerated back, this cycle should technically have a very positive impact on our market cap and price.  This is because our mining rewards would change into pass-through rewards (IE reimbursements) for a certain percent of our emissions.  Yes, some pass through reimbursements would be liquidated immediately to cover the costs of the orphan, but I believe a certain percent would be held by miners (IE in a sense a tax-deductible buy-and-hold of BBP).

What makes this POOM concept an attractive configuration?

Currently I view BiblePays emissions flow as:
POBH - Security - 25%
Sanc rewards - 25%
GSC (Primarily Staking/Giving) - 35%
Governance Budget - 15%

As you can see, this is a very good configuration already, but with POOM, we can potentially divert some of the Staking revenue over to fully productive orphan reward payments.  And, if the test pilot works, once we have chain locks in place, we could also potentially move some of our security budget into POOM (Optional, depending on various factors).


Decentralization:

And one of the very obvious advantages in this idea is it decentralizes biblepay, allowing us to scale (as each home miner sponsors their own personal orphan using their own funds).













34
Archived Proposals / May compassion recurring sponsorships 2019
« on: May 20, 2019, 01:06:40 PM »
We currently sponsor 55 @ $2090 per month.

Requesting 3.22MM.


35
Archived Proposals / May payroll (Jan)
« on: May 17, 2019, 01:38:14 PM »
1.1.8.5-Mandatory Upgrade 

@biblepay
biblepay committed on Jan 27
 5   
Commits on Jan 23, 2019
1.1.8.4b-Leisure Upgrade 

@biblepay
biblepay committed on Jan 23
 
1.1.8.4-Leisure Upgrade 

@biblepay
biblepay committed on Jan 23
 
Commits on Jan 21, 2019
1.1.8.3b-Leisure Upgrade 

@biblepay
biblepay committed on Jan 21
 
1.1.8.3-Leisure Upgrade 

@biblepay
biblepay committed on Jan 21
 
Commits on Jan 14, 2019
1.1.8.2-Leisure Upgrade 

@biblepay
biblepay committed on Jan 14
 
1.1.8.1c-Leisure Upgrade 

@biblepay
biblepay committed on Jan 14
 
Commits on Jan 13, 2019
1.1.8.1b-Leisure Upgrade 

@biblepay
biblepay committed on Jan 13
 
1.1.8.1-Leisure Upgrade 

@biblepay
biblepay committed on Jan 13
 
Commits on Jan 12, 2019
1.1.8.0b-Leisure Upgrade 

@biblepay
biblepay committed on Jan 12
 
1.1.8.0-Leisure Upgrade 

@biblepay
biblepay committed on Jan 12
 
Commits on Jan 7, 2019
1.1.7.9b-Leisure Upgrade 

@biblepay
biblepay committed on Jan 7
 
Commits on Jan 6, 2019
1.1.7.9-Leisure Upgrade 

@biblepay
biblepay committed on Jan 6
 
Commits on Jan 4, 2019
1.1.7.8q-Leisure Upgrade 

@biblepay
biblepay committed on Jan 4
 
1.1.7.8p-Leisure Upgrade 

@biblepay
biblepay committed on Jan 4
 
1.1.7.8o-Leisure Upgrade 

@biblepay
biblepay committed on Jan 4
 
1.1.7.8n-Leisure Upgrade 

@biblepay
biblepay committed on Jan 4

1.1.7.8m-Leisure Upgrade 

@biblepay
biblepay committed on Jan 4
 
1.1.7.8l-Leisure Upgrade 

@biblepay
biblepay committed on Jan 4
 
1.1.7.8k-Leisure Upgrade 

@biblepay
biblepay committed on Jan 4
 
1.1.7.8j-Leisure Upgrade 

@biblepay
biblepay committed on Jan 4
 
1.1.7.8i-Leisure Upgrade 

@biblepay
biblepay committed on Jan 4
 
Commits on Jan 3, 2019
1.1.7.8h-Leisure Upgrade 

@biblepay
biblepay committed on Jan 3
 
1.1.7.8g-Leisure Upgrade 

@biblepay
biblepay committed on Jan 3
 
1.1.7.8f-Leisure Upgrade 

@biblepay
biblepay committed on Jan 3
 
1.1.7.8e-Leisure Upgrade 

@biblepay
biblepay committed on Jan 3
 
1.1.7.8d-Leisure Upgrade 

@biblepay
biblepay committed on Jan 3
 
1.1.7.8c-Leisure Upgrade 

@biblepay
biblepay committed on Jan 3
 
1.1.7.8b - Leisure Upgrade 

@biblepay
biblepay committed on Jan 3
 
1.1.7.8-Leisure Upgrade 

@biblepay
biblepay committed on Jan 3
 
Commits on Jan 2, 2019
1.1.7.7c-Leisure Upgrade 

@biblepay
biblepay committed on Jan 2
 
1.1.7.7b-Leisure Upgrade 

@biblepay
biblepay committed on Jan 2
 
Merge branch 'master' of https://github.com/biblepay/biblepay

@biblepay
biblepay committed on Jan 2
 
1.1.7.7 - Leisure Upgrade 

@biblepay
biblepay committed on Jan 2
 
Merge pull request #63 from biblepay/develop 

@biblepay
biblepay committed on Jan 2
 
Merge branch 'master' into develop

@biblepay
biblepay committed on Jan 2
 
Commits on Jan 1, 2019
Added further error handling to Win ShellCommand in case boinccmd fails




=-=-=-=-=-=-


140 hours
Capping at 3,000,000


36
Archived Proposals / CAMEROON ONE May 2019
« on: May 17, 2019, 01:31:25 PM »
We have 11 children with cameroon one, we have donated $893 in 2019, and our annual due is $4026.00.

Requesting 5 million to shore up the deficit.


37
Archived Proposals / Whale Revival
« on: May 15, 2019, 07:40:09 PM »
I'm considering the idea of starting an Orphan Whale Fundraiser.  I'm doing this partially because I feel we as a society are entering into the end times (Matthew 6:19, do not store treasures on earth but in heaven), (Rev 3:17 Hoarding in the last days), 1 Timothy 6:17 (do good with your blessings), and therefore I feel as if I should give back my retirement account back to the orphans (or to other good causes).

Obviously, this could be done as an individual alone, but I think that if we have a chance to design this fundraiser to 'increase the impact of the deal' where it makes a positive impact for BiblePay, and also for the giver then it is better to do this as a team for biblepay than alone.

Also, I have been reaching out to two of our vendors who offer Orphan early-termination insurance, meaning that they both guarantee the orphan will not be dropped from the benefits program if we pick them up and drop them (they will be subsidized by the insurance they carry or moved to another beneficiary).  Both Compassion.com and CAMEROON ONE offer this.

As far as a personal tax deduction, I believe it will be possible to receive the deduction if you give to Cameroon One.  As they will allow the check to be sent to them, and the orphan to be in the BiblePay account.  Compassion on the other hand does not accept checks from third parties therefore the tax deduction is not possible with them.

So here is what I am thinking as a rough idea:

I ask the community for an idea of how many orphans our whales are willing to sponsor each.
I agree to match an equal amount of BBP/USD to sponsor an equal amount of orphans (IE I match the whales commitments).
BiblePay sponsors an equal amount of orphans out of that monthly superblock also.

We then increase our orphan count by 1/6th of that number (IE we adhere to our 6 month buffer).  After BiblePay can no longer afford to pay, we scale back.

So an example looks like this:

Whales 1-5 decide to sponsor 40 orphans ($1600).
Rob matches this number (40) @ $1600.
The money raised goes directly to Cameroon One and Compassion (and those that pay cameroon one receive a tax deduction receipt).
We enter a proposal for BiblePay for $1600 that month also (benefiting 40 orphans).

With this combined action, we receive total funds to sponsor 120 children / 6 months  = 20 new orphans.
That same month, we sponsor N from Cameroon and Y from Compassion (depending on how many went with Cameroon).

BiblePay assumes liability for the children at that point going forward.

Note that the whales do not receive anything back for this (except a tax deduction) and a positive experience as a cheerful giver.


Thoughts?

Also would anyone be up for this?







38
Sanctuary Discussions / Bug Bounty Program
« on: May 11, 2019, 03:33:34 PM »
If anyone finds a critical security bug in BiblePay, please start by announcing it here.

We will work with you and reward up to 2 million BBP for the bug, depending on its systemic nature.

____________________________________________________________________________________________________________________________________________________


Current Bug Bounties:

Bug Reward Type 1:
Capability to solve a proof-of-bible-hash in a GPU or ASIC:
The white-hat-hacker will need to prove to us that it is not only possible to hash a block in a GPU (or ASIC device), but the blockhash solution was obtained is also hashed in a more efficient manner than the PC.  An example would be to prove that a certain GPU and program (created by the hacker) will solve a POBH block in 1 second while the same standard-PC would take much longer to solve (IE 30 seconds for example).  (Or a similar high-efficiency scenario resulting in at least a 200% gain so as to ensure the gain is a real gain by BiblePay devs).

NOTE - You must be able to prove this attack will work against production in a reproducible way.
An example that will not be sufficient:  Creating a test environment where your GPU program can solve a theoretical bible-hash in test only.  The reason this case is not really an exploit is our POBH algo also passes in certain live network values - into the hash function in real time, such as the 'allowable maximum nonce'.  Meaning that in a test environment you are cheating if you don't take live production data into account.

An example that is valid:  A c program written by the hacker taking into account live production data and solving a POBH block in a reproducible manner that provides a financial edge to the hacker.

REWARD:  2 MILLION BBP - paid by Rob Andrews founder - Rob will only attempt to recoup the loss with a proposal after the hacker is paid and Rob will take on the risk


__________________________________________________________________________________________________________________________________________________

Bug Reward Type 2:

Capability to prove that a BiblePay GSC smart contract can leak rewards to a hacker that were not earned by the hacker through GSC projects (or, any reproducible security exploit resulting in Leaked BiblePay coins to the hacker that the hacker did not earn):

This type of bug rewards a white-hat-hacker for finding an attack vector into one of our GSC (generic smart contracts), one of our Projects (such as POG or healing) and finding a way to pull coins out of BiblePay that the hacker really did not earn. 

An example of this would be trying to create or falsify a smart contract, and "slide it by" the sanctuaries to approve it.  Or finding any way to pull coins out of an existing project that were not earned by the user.  All smart contract rewards requite coin*age from UTXOs, so it is our belief it is impossible to pull money out of one of our daily contracts that is not earned.

Please post a question if you are unsure if your hacking effort will result in payment.

REWARD: 2 MILLION BBP - Paid by Rob Andrews Founder - Rob will attempt to recoup the loss only after the hacker is paid and Rob takes on the risk

____________________________________________________________________________________________________________________________________________________

Bug Reward Type 3:

Notify us of any security bug that is found in our software, such as BEAST, Crime, HTTPS exploits, SSL exploits, ECDSA, BLS, or any upstream bug discovered by Bitcoin/Dash or a community bug.

Reward: 10K+ depending on the nature of bug - at the discretion of the devs.

____________________________________________________________________________________________________________________________________________________

39
Archived Proposals / Compassion April 2019 Recurring sponsorships
« on: April 15, 2019, 09:28:58 AM »
We sponsor 55 compassion orphans @ $2090.00 per month.

Capping @ 5MM.

40
Archived Proposals / April Payroll
« on: April 15, 2019, 09:25:17 AM »


Commits on Dec 29, 2018
1.1.7.4-Leisure Upgrade 

@biblepay
biblepay committed on Dec 29, 2018
 
Merge branch 'master' of https://github.com/biblepay/biblepay 

@biblepay
biblepay committed on Dec 29, 2018
 
1.1.7.3b-Leisure Upgrade 

@biblepay
biblepay committed on Dec 29, 2018
 
bump version to 1.1.7.3 (leisure for mainnet&testnet)

 
Merge branch 'develop' (issues and PPA scripts & doc) 

 
Issue #55 hide boincmd shell windows in Win32/64

 
Restore dash xpm files to allow Licht's ubuntu PPAs to build without  

 
Issue #62 some failure routes in SignStake might leave wallet unlocked

 
1.1.7.3-Leisure Upgrade 

@biblepay
biblepay committed on Dec 29, 2018
 
Commits on Dec 25, 2018
1.1.7.2c-Leisure Upgrade 

@biblepay
biblepay committed on Dec 25, 2018
 
Commits on Dec 24, 2018
1.1.7.2b-Leisure Upgrade 

@biblepay
biblepay committed on Dec 24, 2018


ommits on Dec 23, 2018
1.1.7.2-Leisure Upgrade (Mandatory for TestNet) 

@biblepay
biblepay committed on Dec 23, 2018
 
Commits on Dec 21, 2018
1.1.7.1-Leisure Upgrade 

@biblepay
biblepay committed on Dec 21, 2018
 
Commits on Dec 20, 2018
1.1.7.0b-Leisure Upgrade 

@biblepay
biblepay committed on Dec 20, 2018
 
Commits on Dec 19, 2018
1.1.7.0-Leisure Upgrade 

@biblepay
biblepay committed on Dec 19, 2018
 
1.1.6.9b-Leisure Upgrade 

@biblepay
biblepay committed on Dec 19, 2018
 
1.1.6.9 - Leisure Upgrade (Mandatory for TestNet) 

@biblepay
biblepay committed on Dec 19, 2018
 
Commits on Dec 17, 2018
1.1.6.8-Leisure Upgrade 

@biblepay
biblepay committed on Dec 17, 2018
 
Commits on Dec 16, 2018
1.1.6.7-Leisure Upgrade (Mandatory for TestNet) 

@biblepay
biblepay committed on Dec 16, 2018
 4   
Commits on Dec 13, 2018
1.1.6.6-Leisure Upgrade (Mandatory for TestNet) 

@biblepay
biblepay committed on Dec 13, 2018
 
1.1.6.5b-Leisure Upgrade 

@biblepay
biblepay committed on Dec 13, 2018
 
1.1.6.5-Leisure Upgrade (Mandatory for TestNet) 

@biblepay
biblepay committed on Dec 13, 2018
 
Commits on Dec 12, 2018
1.1.6.4g-Leisure Upgrade (TestNet) 

@biblepay
biblepay committed on Dec 12, 2018
 
1.1.6.4f-Leisure Upgrade 

@biblepay
biblepay committed on Dec 12, 2018
 
1.1.6.4e-Leisure Upgrade 

@biblepay
biblepay committed on Dec 12, 2018
 
1.1.6.4d-Leisure Upgrade (Mandatory for TestNet) 

@biblepay
biblepay committed on Dec 12, 2018
 

@biblepay
biblepay committed on Dec 12, 2018
 
1.1.6.4c-Leisure Upgrade (Mandatory for TestNet) 

@biblepay
biblepay committed on Dec 12, 2018
 
1.1.6.4c-Leisure Upgrade (Mandatory for TestNet)

Commits on Dec 11, 2018
1.1.6.4b-Leisure Upgrade (Mandatory for TestNet) 

@biblepay
biblepay committed on Dec 11, 2018
 
1.1.6.4-Leisure (Mandatory for TestNet) 

@biblepay
biblepay committed on Dec 11, 2018
 
Commits on Dec 8, 2018
1.1.6.3-Leisure Upgrade (Mandatory for TestNet) 

@biblepay
biblepay committed on Dec 8, 2018
 
1.1.6.2h-Leisure Upgrade(Testnet only) 

@biblepay
biblepay committed on Dec 8, 2018
 
Commits on Dec 7, 2018
1.1.6.2g-Leisure Upgrade (TestNet) 

@biblepay
biblepay committed on Dec 7, 2018
 2   
1.1.6.2f-Leisure Upgrade (TestNet only) 

@biblepay
biblepay committed on Dec 7, 2018
 
1.1.6.2e-Leisure(Testnet Only) 

@biblepay
biblepay committed on Dec 7, 2018
 
1.1.6.2d-Leisure (TestNet only) 

@biblepay
biblepay committed on Dec 7, 2018
 
Commits on Dec 6, 2018
1.1.6.2c-Leisure (testnet) 

@biblepay
biblepay committed on Dec 6, 2018
 
1.1.6.2b-Leisure (Testnet only) 

@biblepay
biblepay committed on Dec 6, 2018
 
1.1.6.2-Leisure Upgrade (Testnet only) 

@biblepay
biblepay committed on Dec 6, 2018





> 12MM, capping at 3MM


41
Archived Proposals / Side By Side Women of Uganda
« on: April 06, 2019, 10:34:22 AM »
First a little history.
We sponsored 10 orphans through BLOOM up til Dec 31, 2018.

During the beginning of the year we technically could not afford to continue to sponsor the full quantity, so we intended to scale back to at least 5 or lower this year.

We received a message from Sarah at Side by Side (this is Blooms vendor) that 'payment has been cancelled' as of 2019 (another words the children are at risk of being dropped from the boarding school) and she asked if we could do anything directly (IE would we like to step in and sponsor any of these children).

I asked which 4 would need us the most?  She listed:
Favor   
https://biblepaysponsorkids.tumblr.com/post/171309417994
Praise   
https://biblepaysponsorkids.tumblr.com/post/171309472084
Isaac   
 https://biblepaysponsorkids.tumblr.com/post/171309538169
Musigale   
https://biblepaysponsorkids.tumblr.com/post/171309583169

TheSnat and I started to train her on how to liquidate crypto, but she has not successfully finished that course (she is working with him now).

In the mean time I volunteered to step in and pay for 90 days, one-time to continue the children so that they do not have to leave the boarding school.

Note that this particular arrangement is $80 per child per month because they receive not only the normal meals and school, but also boarding.


I am requesting $320 * 3 months = $960.00 or  3,720,930bbp.


Receipt - sending wire now:
http://pool.biblepay.org/san/Expenses/sidebyside.pdf



42
Archived Proposals / Consolidation of Sanctuaries
« on: April 05, 2019, 08:33:46 PM »
Since BiblePay is moving to Evolution in June, we have the opportunity to potentially change the Sanctuary lockup requirements from 1,550,001 to another figure.

I think this would be a good time to discuss potentially changing this lockup requirement higher in order to :
- Give our investors more ROI per Sanc
- Decrease Hosting Costs
- Increase reliability per Sanc (because user may afford a higher quality host and have more time to monitor each sanc)

The obvious downside to this is a higher barrier of entry cost for the small investor.
But, with our recent downturn in price bringing a sanctuary investment to only $400, I think this is a feasible idea.

For me as an investor, I would personally lean towards consolidating so I can spend less on hosting fees.
Analyzing the effect of wasted hosting:

We currently have about 500 sancs.
Our sanc owners are spending a very high percentage of the revenue on hosting (If hosting is $10 per month, with $20 of revenue that is 50% spent on hosting).

I believe reducing the sanc count by half will not hurt biblepay (as 250 nodes are still more than enough to service our network), and, it could be argued that 250 high quality sancs are better than 500 low quality sancs (as with low quality instant sends could get lost).

Additionally over the next 5 years, even if we move to 125 sancs, our sanc count will again increase (due to more coins being emitted and a lockup ratio average of approx 50% coins become locked into sancs).

I propose that we enter 3 sanctuary proposals floating this idea with different size lockups:
1) 3 million lockup
2) 4.5 million lockup
3) 7 million lockup

If all 3 are voted down we keep 1.55 MM.




43
EVOLUTION



Currently testing Dash 0.14 features in BiblePay v1.4.6.3+



Testnet Download Links:

Windows v.1.4.6.3+:
https://biblepay.org/biblepayevo32develop.exe


Linux PC 32bits
Daemon: https://biblepay.org/biblepayd-evo-testnet-i686-pc-linux-gnu.tar.gz
QT: https://biblepay.org/biblepay-qt-evo-testnet-i686-pc-linux-gnu.tar.gz

Linux PC 64bits
Daemon: https://biblepay.org/biblepayd-evo--testnet-x86_64-pc-linux-gnu.tar.gz
QT: https://biblepay.org/biblepay-qt-evo-testnet-i686-pc-linux-gnu.tar.gz

Linux ARM64 daemon: https://biblepay.org/biblepayd-evo-testnet-aarch64-linux-gnu.tar.gz
Linux ARM32 daemon: https://biblepay.org/biblepayd-evo-testnet-arm-linux-gnueabihf.tar.gz

MacOS QT: https://biblepay.org/biblepaycore-evo-testnet.dmg






Mac-OS QT version here:
https://www.biblepay.org/biblepaycore-testnet.dmg



The purpose of this thread is to test BiblePay-Evolution and our new GSCs.

BiblePay-Evolution is our next release (scheduled for June 2019).

It includes all of the features that Bitcoin and Dash added to Dash over the course of 2018.
Including Segwit, Security updates, Lightning network support, BIPS and DIPS, ChainLocks (51% attack prevention), Deterministic Masternodes, Non-financial transactions, the Depends Development Build environment, C++14 compatibility for devs, more reliable chain syncing, better chain reorganization code, more reliable Governance messages, more efficient messages, HD wallets, High definition display support, InstantSend improvements, and more.

In BIblePay, we have added ABN (Anti-BotNet) mining.  This is a feature that requires miners to include an ABN transaction in each of their blocks that spends coin-age according to the network coin-age requirement (see getmininginfo).

We have also added GSCs (Generic Smart Contracts) client and server side.  The GSC allows BiblePay to abstract payments away from a hard consensus to allow the business logic rules to be malleable and configured so that they do not break consensus rules.  This results in a more reliable prod environment.

Before testing, please read about our GSC's here:
https://wiki.biblepay.org/Generic_Smart_Contracts


To Download BiblePay-Evolution, look for v1.4.0.1+ for windows on this link (at first, we will stay with 32 bit builds until we get close to Prod):
https://biblepay.org/biblepaycore-1.4.0-win32-setup.exe

MIP is working on building linux and MAC builds.  If necessary I will be able to release a link for Ubuntu64 builds/linux also.

To self compile Evo:
https://github.com/biblepay/biblepay-evolution/blob/master/BuildBiblePay.txt

Let us start by testing standard core functionality in testnet.

Launching the client:

Create a biblepaytest.conf file with the following contents:
testnet=1
debug=1

Place the file in ~/.biblepayevolution

Start testnet by typing:
./biblepay-qt -conf=biblepaytest.conf

(Note the blocks and chainstate will sync into the ./biblepayevolution/testnet3 folder.

NOTE:  We are keeping BiblePay's blocks, wallet, and chainstate in its own dedicated folder until the end of the test cycle at which time we determine if it is safe to change our pointer back to legacy biblepay files (as Evolutions blocks support a new file format, compressed, and Evo's wallet format has also been upgraded), so it is safer for us to keep these separate for now. 

NOTE: This version will also work side-by-side our production nodes, it will sync blocks, send and receive coins, however it will not peer with legacy Sanctuaries (as their protocol is too old).  We will need to test creation and usage of Sancs in Prod in Evo, and upgrade all legacy Sancs with a mandatory.




Getting started with Evolution:
https://wiki.biblepay.org/Getting_Started_with_Evolution
GSC's:
https://wiki.biblepay.org/Generic_Smart_Contracts
Healing Campaign:
https://wiki.biblepay.org/BiblePay_Healing_Campaign
Street Healing:
https://wiki.biblepay.org/Street_Healing
Spiritual Warfare:
https://wiki.biblepay.org/Spiritual-Warfare-I

How to upgrade a legacy Sanc:
https://forum.biblepay.org/index.php?topic=391.msg5968#msg5968

How to create a deterministic sanc from scratch:
https://docs.dash.org/en/stable/masternodes/dip3-upgrade.html






** Low hassle Syncing from Zero **


EDIT:  NOTE:  Please do not use low hassle syncing in testnet after September 22nd 2019 - as we have reset the chain to block 0, please disregard the following lines.
(Keeping this here so we can port this to prod during the next release).

As our blockchain gets bigger it will be useful for us to release utilities to allow one click syncing from zero.
This first version is only for testnet and linux.  Later, I will extend this to windows and prod.

I will check this into github later, but for now, let me give manual instructions to use the script:

From your linux box:

cd ~/biblepay-evolution
(This is where your source starts, ie /src is one folder down)
wget biblepay.org/syncblocks_testnet.sh
chmod 777 syncblocks_testnet.sh

Now to get in sync for TestNet only, the script automatically deletes just the data files (dont worry, it wont delete anything else), then it pulls down the snapshot of the blocks gzipped and unzips them into the correct places (including the llmq and all necessary governance files), then its up to you re-launch the wallet.  The script does close biblepay as long as your machine supports pkill.

To sync from 0 type:
./syncblocks_testnet.sh

EDIT:

I just created a windows version and tested it on windows 7 and it works.  Will check-in during the next Develop release.



44
Archived Proposals / Compassion March 2019 Recurring Sponsorships
« on: March 22, 2019, 11:07:00 AM »
Our recurring charge is approx $2090, or 8.931MM, capping at 7MM.


45
Archived Proposals / March 2019 Payroll
« on: March 22, 2019, 10:58:53 AM »
I'm posting my commits from November 2018, because back when we started BiblePay, we didn't have a governance system until December 2017 (that is why these invoices are 4 months old) (not because our price dropped, or because we are trying to back-invoice), these have been consistently behind since the beginning.

Commits on Nov 21, 2018
Merge branch 'master' of https://github.com/biblepay/biblepay

@biblepay
biblepay committed on Nov 21, 2018
 
1.1.6.1 - Leisure Upgrade 

@biblepay
biblepay committed on Nov 21, 2018
 
Commits on Nov 19, 2018
PPA script and doc

 
1.1.6.0-Leisure 

@biblepay
biblepay committed on Nov 16, 2018
 
Merge branch 'master' of https://github.com/biblepay/biblepay

@biblepay
biblepay committed on Nov 16, 2018
 
1.1.5.9f-Leisure Upgrade 

@biblepay
biblepay committed on Nov 16, 2018
 
Merge pull request #45 from thesnat21/Add_Spork_Outputs 

Commits on Nov 14, 2018
Better detection for BOINC client and error messages per OS

 
disable boost::process ShellCommand temporarily for non MacOS until w 

 
Commits on Nov 11, 2018
boinccmd call for MacOS (https://forum.biblepay.org/index.php?topic=2 

 
Commits on Nov 2, 2018



I'm requesting 80 hrs * 40 = 3200 = 13.2MM bbp, capping @ 3.5 MM


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