Bible Pay

Read 152775 times

  • talisman
  • Jr. Member

    • 57


    • 15
    • March 26, 2018, 07:42:24 AM
    more
Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)
« Reply #645 on: November 05, 2020, 10:01:18 AM »
Hi Rob!

Glad it was only a file format issue. I rebooted just now, and all I see on the leaderboard is you, oncoapop3, and Sakic (!) for the healing campaign. I will give it a couple hours before I bug you again :)

As for the BBP redistribution, I liked the detail and accuracy of Sun's work in the past in a similar case. Instead of members putting extra load on you, may I kindly ask Sun look into this as a whole?


1200 BBP


  • Rob Andrews
  • Administrator

    • 3883


    • 91
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)
« Reply #646 on: November 05, 2020, 10:04:22 AM »
exiting ideas :D

1000 BBP

Yes, in the end, I think BBP would best be served if we are regarded as a useful (and reliable) service - for something - that is decentralized.

You may ask, why wouldnt I just give my crypto directly to Compassion or Cameroon, but what I think we can do, and this is realistic (not a pie in the sky endeavor):
We are starting to make relationships with quality orphanages, and of course we value all of our relationships so this statement is not going against Cameroon or Compassion.
What Im saying is we need to have a decentralized list of 'orphan opportunities' for the global public, and the trust that when a donation is made to our global address the funds are dispersed without overhead to one new orphan (that we already sponsor, due to having a buffer).  If we dont sponsor the orphan we will add those new ones automatically.

So they receive an immediate result, even if they dont want a long term commitment.  The other benefit is with SAI for example we have 35+ new children (half very new) for $20 per month.  The whale(s) are paying about half for these.  This is a good example of a value add we provide (in contrast to simply paying compassion $38 per month).  The crypto user could literally send $10 per month and we would guarantee this SAI orphan is actually sponsored for 30 days.

Maybe we need to also improve our trust with the public by offering bounties to prove the existence of all of our orphans.  I added about 35 to our portfolio over the last few months no one has realized (because of the deal with SAI).  Maybe I should offer 2 mil to audit the children.  Someone should write a quarterly report with all the childrens BIOs in it, and what they did to prove these kids exist.  Im sure each orphanage could provide a blurb about the legitimacy of the children if we did that.

So anyway to expound a little further, we need to be great at a few things that makes us a certain beautiful animal in the wild, that attracts everyone.
I feel like mining was moderately interesting - novel - in the early stages and we dedicated a massive amount of time towards unique (KJV) mining, then PODC and RandomX, and so far both RX and PODC are illuminating us - as a do-good type brand, which is good, but we have absolutely nothing for the general public (we are still a niche for the hobbyist).

So other than a public interface with trust, (imagine if communities like Binance and Coinbase gave just 1% to BiblePay in the future), we need a couple more things to be working in parallel.  I have no problem jumping on one of these, but we need a couple more devs dedicated to decentralizing the other things.  Im going to work on BiblePay TV, fervently soon.

Lets imagine:
Public facing trustworthy charity giving - for orphan sponsorships that we guarantee are unique
Payment for transactions for either HTTPS-bitcoin web servers, or pay-per-view type services

I think if we pull those off this time with quality, that might be all we need.  It would earn us our place in the crypto world.

I still believe we did a great job on the older features - boinc - mining - GSC contracts - the gen3 wallet design - etc.

Anyway, on the bright side BBP has gained a massive amount of experience since 2017.
The major stride we made with efficiency, although no one realizes it is like night and day.

Look at this, in our reward schedule for our coinbase, we only pay rewards when our price is rising, and even the reward is denominated through merge mining as half XMR (thats got to be the most efficient, more efficient than DOGE), and, now our Sancs sponsor one orphan each.  (That means they are 99% efficient because they only exist if they sponsor an orphan bringing their count low).  <- This is a good foundation.



4300 BBP


  • Rob Andrews
  • Administrator

    • 3883


    • 91
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)
« Reply #647 on: November 05, 2020, 10:06:10 AM »
Hi Rob!

Glad it was only a file format issue. I rebooted just now, and all I see on the leaderboard is you, oncoapop3, and Sakic (!) for the healing campaign. I will give it a couple hours before I bug you again :)

As for the BBP redistribution, I liked the detail and accuracy of Sun's work in the past in a similar case. Instead of members putting extra load on you, may I kindly ask Sun look into this as a whole?
Sure if he wants to volunteer!  Its up to him.

Thanks!


4300 BBP


  • Rob Andrews
  • Administrator

    • 3883


    • 91
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)
« Reply #648 on: November 05, 2020, 10:18:56 AM »
Do we have any other Germans here other than Dave?

https://forum.biblepay.org/index.php?topic=689.msg8794#msg8794



4300 BBP


  • Rob Andrews
  • Administrator

    • 3883


    • 91
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)
« Reply #649 on: November 05, 2020, 10:39:18 AM »
So far, here is one plan to decentralize biblepays foundation (and provide transparency for decentralized orphan sponsorships):

- Modify governance to allow a vote to Add or Delete an orphan.  An orphan would consist of 'Orphanid, Charity, Name, URL, Amount, Date Added, (and possibly gender and age but some orphanages frown on providing the gender and age - due to child trafficking regs).  When the vote succeeds we will actually store the orphan in the chain.

- Modify governance to allow adding or deleting a charity.  A charity is the Charity Name and the BBP Send to Address.

- Add an engine that is smart enough to allocate funds to a charity based on percentages of costs per sponsored orphan.

- Add a decentralized relay to bbp for the charity.  This means that BBP would automatically pay the stored charity the funds received for the month.  It would do this because we would make the global giving address a burn address, and the monthly governance payout a payment contract.  This would mean no human would actually be involved in the collection or dispursement to the charity!

- When a charity BBP address changes, the sancs would vote to delete a charity then add a charity (this would edit the record).

- Add a feature to list the children to the RPC, so that people will be encouraged to sponsor children who are waiting.

- The system would be smart enough to handle excess children (for example our SAI children are being paid for right now monthly -- but are not yet sponsored by a user).

- We would have a separate donation address for 'whale matches'.  The system would be smart enough to tally and allocate whale matches also, to reduce the price of sponsorships.

This would theoretically make us into a true DAC also.

Does this feature sound like something that would propel us to the forefront, and make us more trustworthy for Binance charity and Coinbase to donate to us?

We will definitely cover the scenarios where someone donates a LOT, or a Little:

So far the baby plan for 'A lot' is this:
- Donald Trump donates 50MM BBP for no reason to the actual orphan donation address (not the whale match address).  What would happen is due to the engine rules, is each registered charity would receive their excess payment based on the percentages and we would notify Cameroon for example, to add children (we can do this up front).  We can tell orphanages if you receive too much, add children for us.  Then that month we would add children to the portfolio using the governance system.

- Too little:
Over time we would vote to reduce our portfolio.  In the interim, our orphanages would receive less than enough to cover the monthly expenses.

AUDITING:

We could offer a quarterly bounty to audit the orphan collage.  I would like to see a PDF report for our investors that summarizes the portfolio once per quarter.  I dont mind paying 2-3 MM for this in the beginning, until we can afford to pay for it out of the governance budget again.  I think this would be a nice report to post occasionally!  Even bi-annually would be sufficient, I think to earn trust. Would anyone like to take on the first one for 2020?  Ill add a bounty for 4MM for the first one.


EXAMPLE USAGE:

Once the system is in prod, it would be advertised like this:

Give to BIBLEPAY today, and automatically sponsor an orphan:

Send 100,000 BBP to NNNNNNN and sponsor an orphan for 30 days!
Send 1MM to NNNNN and sponsor an orphan for a year!

Send 1MM to ZZZZZZ and become a matching whale, which lowers the cost of orphan sponsorships for everyone else!

Your donation will be show in our RPC report, and its impact as a percentage of our monthly sponsorships!

See our orphan collage here:
(This report would pull dynamically from BBP data, then construct its collage.  The other reports can pull from BBP core also).  This would make them all dynamic.

FAQ:

Q:  What makes a DAC any better than plain vanilla governance?
A:  With a DAC, we don't need to manually liquidate the monthly donations (leaving a point of failure between BBP operations and the trusted individual who collects the funds).  Even with a multi-sig scenario we would have a bottleneck with 2-3 individuals appointed to the post.  Also, in the scenario where we had Compassion and BLOOM, we had to manually allocate the USD and forward these liquidations over to two more people.  I believe with an automated DAC, trust will increase because we will place the impetus of processing the payment directly on the third party charity.  If a charity fails, it will be a public spectacle and BBP will sadly need to delete that charity and vote in a new charity.  It would also give us more transparency, as the children would be in the chain, then we could write more detailed reports.  No one will forget to run the monthly individual processes and pieces required to run a charity or enter the accounting records into multiple systems.






4300 BBP
« Last Edit: November 05, 2020, 11:00:27 AM by Rob Andrews »


  • talisman
  • Jr. Member

    • 57


    • 15
    • March 26, 2018, 07:42:24 AM
    more
Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)
« Reply #650 on: November 06, 2020, 07:05:13 AM »
Hi Rob,

I am afraid the fix has not propagated. Today's superblock skipped PoDC payments again, and leaderboard does not show any WCG points (for anyone).

There are several of us monitoring the PoDC payments on a daily basis, and I for one would be willing to help out if there is some sort of a watchdog and fix functionality community members could perform.

1200 BBP


  • Radar_Dude7
  • Jr. Member

    • 77


    • 15
    • April 16, 2020, 08:52:42 AM
    more
Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)
« Reply #651 on: November 06, 2020, 08:22:19 AM »
Good morning, all and TGIF!

Just to jog my memory, foundation.biblepay.org mining is the same as mining on bbp.miningpool.fun. Is that correct?

Lastly, is there any mining to be done through the wallet any longer? Or, is that deprecated now due to the use of XMRig?

Thanks and God bless!

1000 BBP


  • Rob Andrews
  • Administrator

    • 3883


    • 91
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)
« Reply #652 on: November 06, 2020, 09:03:06 AM »
Good morning, all and TGIF!

Just to jog my memory, foundation.biblepay.org mining is the same as mining on bbp.miningpool.fun. Is that correct?

Lastly, is there any mining to be done through the wallet any longer? Or, is that deprecated now due to the use of XMRig?

Thanks and God bless!

Yes, foundation.biblepay is the exact same site as bbp.miningpool (except I have some opensource, which is in the github, modules enabled and being used for gospel features and rapture dreams and tips enabled on foundation).

As far as mining in the core wallet, we do have RandomX compiled inside the core and you can solo mine from the core, but, due to the optimization and limited memory of the core, its a very slow miner, its at least 10, maybe 100* slower than the RX miner.  You may ask, why have it, there are a few good reasons.

One it keeps the chain moving if all randomx merge mining stops (IE both pools go down).  Two, it also works to fill the gaps if a pool gets blacklisted due to not paying for the orphan sponsorships from money earned.  Etc.

TGIF TO YOU TOO, BROTHER IN CHRIST!



4300 BBP


  • Rob Andrews
  • Administrator

    • 3883


    • 91
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)
« Reply #653 on: November 06, 2020, 10:07:03 AM »

Thats not good!

Alrighty let me look at this.  As far as backup options, I would think we need something like that.  I mean they will have to be trained to understand the c# code and stuff, yes.  We actually have a decentralized version of boinc assimilator in the very early version of biblepay, but it needs modified for WCG.  Anyway lets talk about that after its fixed.

Ok, its fixed now.  There were two issues.  So yesterday when I fixed it, I thought it was fixed because A) My page of cpids loaded that did not load in my test environment, and B) The leaderboard had a couple entries going in.  But in reality there was a second issue that needed fixed (a 4MB limit added that was not there before, causing c++ to not actually scan through the CPIDs), so now it is actually fixed.

We should see the leaderboard populate now as people reboot or wait 4-8 hours.



4300 BBP


  • coinsinspect
  • Jr. Member

    • 34


    • 5
    • July 25, 2018, 09:03:51 AM
    more
Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)
« Reply #654 on: November 08, 2020, 07:51:59 AM »
I am getting PODC payment again  :D

1000 BBP


  • sunk818
  • Global Moderator

    • 517


    • 36
    • April 24, 2018, 02:02:20 PM
    more
Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)
« Reply #655 on: November 10, 2020, 09:19:22 AM »
No it hasnt.   Ive put healing prayers in over the last 15 days and they showed up. 

Yes theres a new problem as of a couple days ago but its not 12 months old.

4300 BBP


I think you misunderstood what I wrote. I meant when the PoDC leaderboard was blank, I only saw healing prayer from sakic that day only.

2700 BBP
BH6oxjLkyz3z8FYpvU3ZR7PTZ31Xt9DkXZ


  • Rob Andrews
  • Administrator

    • 3883


    • 91
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)
« Reply #656 on: November 11, 2020, 09:47:46 AM »

I think you misunderstood what I wrote. I meant when the PoDC leaderboard was blank, I only saw healing prayer from sakic that day only.

2700 BBP

Yes, sorry about that, I thought you meant the same prayer has been stuck for 12 months.
Has Sakic been putting in the same prayer about his sisters knee repeatedly and getting compensated for it more than one time?



4300 BBP


  • Rob Andrews
  • Administrator

    • 3883


    • 91
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)
« Reply #657 on: November 16, 2020, 07:38:21 PM »
** Womans daughter needs Eye Surgery from Graves Disease **

So, I prayed for this womans mother about 15 months ago, and she was miraculously healed of a torn achilles tendon (so much that she is no longer on crutches).
Anyway her daughter needs eye surgery and they don't have insurance.

If anyone feels compelled to help, here is her gofundme page:
https://www.gofundme.com/f/help-my-daughter-get-her-eyes-back-to-normal?utm_medium=social&utm_source=whatsapp&utm_campaign=p_nacp+share-sheet&rcid=3cb6944605984937b669601f5f7b5701

Thanks!



4300 BBP


  • sunk818
  • Global Moderator

    • 517


    • 36
    • April 24, 2018, 02:02:20 PM
    more
Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)
« Reply #658 on: November 17, 2020, 12:31:16 AM »
This is great to see the DAC idea is becoming more concrete. Overall, I think this is a great idea and anything to automate the process into an automate process is really a beautiful solution. As a product, you could really benefit the charity, non-profit industry, and show what transparency is about. Too often, we just don't know where the money goes and it just seems like a giant black hole.  It would be easy to advertise especially unique URLs that goes to a specific child on the web site. Also, a CSV or JSON export of data will make nice reports and charts easier.


A few specific questions (not to detract from the overall idea -- just curious):


> - When a charity BBP address changes, the sancs would vote to delete a charity then add a charity (this would edit the record).

What happens to existing children recorded against the previous charity? Or are children and charity not related in that way?

> - Add an engine that is smart enough to allocate funds to a charity based on percentages of costs per sponsored orphan.

How will the accounting work if every child is a sub percentage of 100%? I wonder if it'll create accounting difficulty as opposed to fully funding each child and then the last child would receive what is remaining. Don't charities often have gap insurance to cover any dropped children?




So far, here is one plan to decentralize biblepays foundation (and provide transparency for decentralized orphan sponsorships):

- Modify governance to allow a vote to Add or Delete an orphan.  An orphan would consist of 'Orphanid, Charity, Name, URL, Amount, Date Added, (and possibly gender and age but some orphanages frown on providing the gender and age - due to child trafficking regs).  When the vote succeeds we will actually store the orphan in the chain.

- Modify governance to allow adding or deleting a charity.  A charity is the Charity Name and the BBP Send to Address.

- Add an engine that is smart enough to allocate funds to a charity based on percentages of costs per sponsored orphan.

- Add a decentralized relay to bbp for the charity.  This means that BBP would automatically pay the stored charity the funds received for the month.  It would do this because we would make the global giving address a burn address, and the monthly governance payout a payment contract.  This would mean no human would actually be involved in the collection or dispursement to the charity!

- When a charity BBP address changes, the sancs would vote to delete a charity then add a charity (this would edit the record).

- Add a feature to list the children to the RPC, so that people will be encouraged to sponsor children who are waiting.

- The system would be smart enough to handle excess children (for example our SAI children are being paid for right now monthly -- but are not yet sponsored by a user).

- We would have a separate donation address for 'whale matches'.  The system would be smart enough to tally and allocate whale matches also, to reduce the price of sponsorships.

This would theoretically make us into a true DAC also.

Does this feature sound like something that would propel us to the forefront, and make us more trustworthy for Binance charity and Coinbase to donate to us?

We will definitely cover the scenarios where someone donates a LOT, or a Little:

So far the baby plan for 'A lot' is this:
- Donald Trump donates 50MM BBP for no reason to the actual orphan donation address (not the whale match address).  What would happen is due to the engine rules, is each registered charity would receive their excess payment based on the percentages and we would notify Cameroon for example, to add children (we can do this up front).  We can tell orphanages if you receive too much, add children for us.  Then that month we would add children to the portfolio using the governance system.

- Too little:
Over time we would vote to reduce our portfolio.  In the interim, our orphanages would receive less than enough to cover the monthly expenses.

AUDITING:

We could offer a quarterly bounty to audit the orphan collage.  I would like to see a PDF report for our investors that summarizes the portfolio once per quarter.  I dont mind paying 2-3 MM for this in the beginning, until we can afford to pay for it out of the governance budget again.  I think this would be a nice report to post occasionally!  Even bi-annually would be sufficient, I think to earn trust. Would anyone like to take on the first one for 2020?  Ill add a bounty for 4MM for the first one.


EXAMPLE USAGE:

Once the system is in prod, it would be advertised like this:

Give to BIBLEPAY today, and automatically sponsor an orphan:

Send 100,000 BBP to NNNNNNN and sponsor an orphan for 30 days!
Send 1MM to NNNNN and sponsor an orphan for a year!

Send 1MM to ZZZZZZ and become a matching whale, which lowers the cost of orphan sponsorships for everyone else!

Your donation will be show in our RPC report, and its impact as a percentage of our monthly sponsorships!

See our orphan collage here:
(This report would pull dynamically from BBP data, then construct its collage.  The other reports can pull from BBP core also).  This would make them all dynamic.

FAQ:

Q:  What makes a DAC any better than plain vanilla governance?
A:  With a DAC, we don't need to manually liquidate the monthly donations (leaving a point of failure between BBP operations and the trusted individual who collects the funds).  Even with a multi-sig scenario we would have a bottleneck with 2-3 individuals appointed to the post.  Also, in the scenario where we had Compassion and BLOOM, we had to manually allocate the USD and forward these liquidations over to two more people.  I believe with an automated DAC, trust will increase because we will place the impetus of processing the payment directly on the third party charity.  If a charity fails, it will be a public spectacle and BBP will sadly need to delete that charity and vote in a new charity.  It would also give us more transparency, as the children would be in the chain, then we could write more detailed reports.  No one will forget to run the monthly individual processes and pieces required to run a charity or enter the accounting records into multiple systems.






4300 BBP


2700 BBP
« Last Edit: November 17, 2020, 12:52:15 AM by sunk818 »
BH6oxjLkyz3z8FYpvU3ZR7PTZ31Xt9DkXZ


  • Rob Andrews
  • Administrator

    • 3883


    • 91
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)
« Reply #659 on: November 17, 2020, 08:58:45 AM »
This is great to see the DAC idea is becoming more concrete. Overall, I think this is a great idea and anything to automate the process into an automate process is really a beautiful solution. As a product, you could really benefit the charity, non-profit industry, and show what transparency is about. Too often, we just don't know where the money goes and it just seems like a giant black hole.  It would be easy to advertise especially unique URLs that goes to a specific child on the web site. Also, a CSV or JSON export of data will make nice reports and charts easier.


A few specific questions (not to detract from the overall idea -- just curious):


> - When a charity BBP address changes, the sancs would vote to delete a charity then add a charity (this would edit the record).

What happens to existing children recorded against the previous charity? Or are children and charity not related in that way?

> - Add an engine that is smart enough to allocate funds to a charity based on percentages of costs per sponsored orphan.

How will the accounting work if every child is a sub percentage of 100%? I wonder if it'll create accounting difficulty as opposed to fully funding each child and then the last child would receive what is remaining. Don't charities often have gap insurance to cover any dropped children?





2700 BBP

I'm going to need to create a DAC thread for this as I realize its going not only be cleaner, but I will reply here until I release the wiki for the DAC, as I know there will be a massive amount of design required to make this work (and after thinking about the worthiness, I think it will be worth it).

Q "What happens to existing children recorded against the previous charity? Or are children and charity not related in that way?"
-> The idea of having an entity for the Charity and an entity for the Orphan, is more of an database-integrity decision.  It would let us start creating a model where we store numbers of orphans as orphans with their related info, then charity related info in the Charity entity.  At this point I think we would actually store the data in the chain, so it can work purely decentralized.  This would mean the DAC feature could say, it works entirely within the blockchain and with governance decisions.  As far as operations goes, it means if we were to vote out a charity (due to corruption detected), all the orphans would be considered invalid and would no longer get paid.  As far as reporting they would just be logically deleted, so you could "see them" on certain reports, but as Deleted.  We would no longer have to pay for those orphans if we deleted the charity.  So it would be a serious decision.  As far as editing the record, we would delete and add the same charity with the same primary key with a different address (thats if say Cameroon ones receive address changed).  That would not disturb the children because they would still refer to the same charity by name (IE if the primary key was 'cameroon-one' for the charity).


Q How will the accounting work if every child is a sub percentage of 100%? I wonder if it'll create accounting difficulty as opposed to fully funding each child and then the last child would receive what is remaining. Don't charities often have gap insurance to cover any dropped children?
-> First actually I believe from what Ive learned that Gap insurance is not the standard, Ive only found that compassion has it.  I dont think cameroon has it, they might have a pool of money that keeps the child safe but that would be from their goodness not from gap insurance.  I believe compassion has an actual insurance policy that pays for dropped children while they wait for a new donor.  So I believe its the exception rather than the rule. 
Lets break up accounting as a separate process from expense allocation.  I think we would have one expense allocation engine for monthly donations, and an accounting process that stores the actual debits and credits in and then a separate report that groups and summarizes them.  It would be up to us to write more rpc or pdf reports from the chain data as necessary.  But the good news is, all of the data would be in the chain forever, and it could be reported on any way they want. 

I do want to say, the big pro of a DAC vs plain vanilla (dashlike) governance is this:
Scenario A ->  Plain vanilla governance ->  Each month, beggars come begging from around the world, unvetted, and some rich already, some from rich countries, begging for money for causes for everything, and the public (who may not have an orphan but owns a masternode) votes away the money perpetually.  Then the money is spent less efficiently.
Scenario B ->  A true DAC ->  Each month, as we get smarter and smarter because of our orphanage relationships, we maintain only the most efficient orphan charities over time.  The actual sponsored orphans are maintained as long term commitments.  The random gifts given to our charity addresses allow the sancs to perpetually vote in sponsored orphans and charities who have been proven to sponsor children for the lowest cost per child month- otherwise those charities get replaced with new charities.  This gives the casual donor the understanding that when they give to BBP, they are seeing $20 equal to 30 orphan days for example.  In scenario A, they would be lucky to see $20 equal to 15 orphan days, half of the time (meaning the true # is $20 for 8 orphan days in scenario A due to waste on half of the other proposals etc).  And, I do realize Cost is not always equal to quality!  I realize that, and we certainly need to include metrics in for Quality and not just cost, for example, compassion provides school materials, relationships with pastors and leases, food, etc.  We would not simply go with SAI because they are cheaper - we really need to vet all of them and score them with multiple facets.  We need a bounty for a PDF audit also.  It would be cool to see how one scores on 5 facets. The other big pro would be the automatic distribution of donations to our charities by burn-relay.  That simply does not exist with plain vanilla governance.  (This would enable us to have a global burn address for donations, and let the user know how efficient it is to simply send BBP to one address that helps children!).


So the vision would be to create some type of live metrics also, where we can show quantifiable proof how efficient we are. 
Then finally, from other connected services like BiblePay TV, a person on a couch can click Donate $2 in BBP to sponsor an orphan for 5 days, for example etc.

I think to answer the 2nd question, how the funds would be allocated, if say for example we have 50 sponsored orphans, we would have a daily rules engine that sums up the 'whale matches' vs 'sum of donations'.  It would allocate those to the monthly pools.  Then it would divide the BBP available by allocating it to each of the charities by active orphan sponsor % (IE 80% to cameroon-one, 20% to SAI, or whatever that # currently is).  Once it has the allocation, it would convert that amount to USD and make internal accounting entries (IE credits to each charity) and store them - so basically when you run the report later by charity name, you would see the distributed amount as credit per day.  The main reason I switched to Daily, is because I have discovered the amount burned per address must be collected daily for chain safety and forwarded in the GSC superblock to the charities (so it does not pile up per month).

So I think the accounting reports would contain daily data, but of course could be summarized to monthly.

As far as changing the rules engine to pay for a certain number of children then let them drop off, I think the biggest hurdle with that is we really cannot estimate how much is coming in randomly from the global donations daily, so I think to handle a day with 10MM donated vs 100K donated, we just allocate the amount across our charities by % owed and make the accounting entries across the board.  IE across every child.  Then once per quarter, the sancs will decide if they need to drop children or add children. 





4300 BBP
« Last Edit: November 17, 2020, 09:17:38 AM by Rob Andrews »