Topic: BiblePay - New Coin Launch - Official Thread - page 119. (Read 119833 times)

Yupe, I saw it in the pool. Good to know the information about this orphan project.

Good Morning all-

I'm heading to the east coast in a few minutes, but I wanted to give a quick update on today's monthly sponsorship benefit auction.

The liquidity held up very well, we sold 7.2 million BBP for $2,812 USD, successfully converting it to USD with an approximate benefit to 74 new orphans.

I just added two new pieces of UI to the pool to show the activity (note: in the long term this will be moved to the orphan subdomain) but for now shows our progress. (See the Orphan reports after logging in).

The first report shows the results of the auction.

The second report shows the actively sponsored orphans - so far we only have two, because of time limitations, but you should see the list grow
 to 74 while Im on vacation.

Have a great day.

I can see a lot of giant computers mining with very high hashrate in pool. The hashrate really surprised me. I remember dev mentioned before that the pool still lock to 24 threads per worker. So, those computer are amd ryden?

Updated.

Happy_Merchant, #8 on the rich list is the pool if you want to label it:

8   B9LeH2D3pxTHcssNhgBqseJekonk1q36w8   1136122.01253080   1.56

Thanks.

Maybe you could update this part of the OP:


https://c-cex.com/?p=bbp-btc

First, let me say once again, this coin is amazing.  Great new algo that is groundbreaking, great team (hidden at this point) that has a great heart for the world.



My thought would be along these same lines.

According to https://support.compassion.com/compassion/topics/can-i-pay-in-advance-for-the-entire-year-of-sponsorship, it is possible to pay any number of months in advance.

I would think it best, due to the uncertain markets that instead of selling every batch of $40 once per month on the markets you instead offer the entire batch once per week internally to the users at market rate or slightly higher.  Then you avoid the TX fees of the exchanges and I for one would be willing to pay slightly more to enrich the program rather than the money lenders in the temple.  You could basically say (on the biblepay site or via some core functionality) "The August 1st week lot is up, it is 55,000 BBL, market rate is 9 satoshi/BBL, this lot goes to the first offer of at least 605,000 satoshi or will be sold at exchange on tomorrow"

Then, if there was enough to sponsor one child for their entire remaining term, that be done.  Otherwise, that money would float to the next week and the additional funds from that sale added...so on, and so forth until the entire term could be paid at once, minimizing the risk of starting a sponsorship that could not be completed.

I am using the computer for gaming aswell, and then i turn off cpu mining. And mine with only 2 gpu on other coins while my gpu connected to screen dont mine. So that could explain it Btw, funfact - my computer got 17 fans to stay cool :p

Would also be cool if during the month of Nov there is a small pool of additional funds for the children's Christmas gift. My family sponsors a couple children through Compassion already and i know Christmas time / Birthday is a time you can provide more than the monthly allocation. Just thinking out loud. 

Great work Dev .. I really see Colossians 3:23 being walked out here.

I dont think there is a surefire way to minimize orphan donation risk 100%, but we can probably minimize it a good amount?

the future value of BiblePay coins could be very volatile

I googled how long a sponorship lasts, and it lasts until an orphan is 18-22 years old
https://www.compassion.com/sponsor_a_child/sponsorship-faq.htm#faq-tcm:5-308790

so orphans are ages 0 to 22,

to be certain our donation would never falter, we wouldn't want to sponsor an orphan until we could pay for the whole X years worth of their full remaining sponsorship, which could be on average 11 years, or potentially more or less depending on the age distribution of orphans

Im not sure if its possible to pay up front?, and even if it was,
would it be better for the worth to be stored in coins? or exchanged into dollars?

This is all very interesting

Hi Smoosh,

Try running with setgenerate 5 for a while and see if it stays on the board.
If you have a slower processor, the shares are distributed across 10 threads and could be too hard to solve so that means a higher chance all 10 cant be solved before 15 minutes is up.  5 however will give you double the chance of staying in.

All I have to say is keep up the good work and I really think it will go upward, so orphan being dumped will not occur I hope. But of course it is really wise to think IF it go down, what could be done. What about keeping a reserve like mentionned in a previous post.

Have 2 linux machines hashing. One has a lot more power then the other but smaller one when started shows up in the account section of the pool but has since dropped off. When i run getmininginfo this is what i get. Any idea why its not showing up

./biblepay-cli getmininginfo
{
  "blocks": 3586,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 0.03282969256960386,
  "errors": "",
  "genproclimit": 10,
  "networkhashps": 263656366.7425968,
  "hashps": 4036.079335872465,
  "minerstarttime": "08-17-2017 22:40:42",
  "pooledtx": 0,
  "testnet": false,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; ",
  "poolinfo2": "RM_08-18-2017 00:42:52; RM_08-18-2017 00:44:03; RM_08-18-2017 00:43:49; RM_08-18-2017 00:43:14; RM_08-18-2017 00:43:06; RM_08-18-2017 00:45:35; RM_08-18-2017 00:46:02; RM_08-18-2017 00:44:45; RM_08-18-2017 00:43:39; ",
  "poolinfo3": "CFW 08-18-2017 00:42:50; CFW 08-18-2017 00:44:01; CFW 08-18-2017 00:43:47; CFW 08-18-2017 00:43:13; CFW 08-18-2017 00:43:05; CFW 08-18-2017 00:45:34; CFW 08-18-2017 00:46:00; CFW 08-18-2017 00:44:43; CFW 08-18-2017 00:43:37; ",
  "miningpulse": 948,
  "poolmining": true
}

Yes, a buffer is a good idea, we should think about that before next months liquidation. 

We should have some type of report we can run before the 10th or so, so we can take a look at it.

Hmm, it seems like it'd be inevitable that orphans would be dropped occasionally at that rate. Any month where less money is raised than the month before, someone would be cut.

Would it be possible to set up some sort of a buffer? Say, only 80% of the orphan foundation wallet is dumped every month, and the remaining 20% is carried over unless it's also required to be dumped to fund existing sponsorships? That'd give at least a little tolerance for normal market fluctuations.

Thanks a lot, and thanks to the others also.  This is a long road but I think once we have our slack team, we will have plenty of help in various areas.

One of my next priorities is to add an orphan subdomain for BiblePay with pages that exist with the ability to write letters to the active orphans we sponsor.  I just received a letter today from an orphan, and she said she was praying for me and my family.  I was thinking, this is one of the most underestimated functions (sort of like manning the twitter or facebook account), but, the most rewarding experience in the life of an orphan is the hope of receiving one of our letters.  I will also make an attempt to receive letters from the compassion API and import them back into biblepay (that may take a while).  I believe we can do the outgoing letters, based on looking at the interface.

So, one minor change to our flow, I was speaking to a director at compassion today about some things regarding sponsorships, and one warning she gave us is that its frowned upon to sponsor and dump a child.  I was explaining to her that we have a Group called BiblePay, and we intended on auto-sponsoring the longest waiting children, and if we could not afford to sponsor them the next month we would only sponsor as many as we could afford each month (I was thinking along the lines that our orphan foundation wallet bears $2000 one month, and $1000 the next month, IE a declining scenario).  She said it is highly recommended that we create a system with an affinity to keep paying the premiums for already sponsored children, as multiple issues happen when we drop them.  One, they are no longer the longest waiting child.  Two, it breaks their hearts.  Among other things. 

So in light of this, Im going to program this in a way that the sponsorship occurs and allows for recurring charges per orphan ID, unless we run out of money for the last orphan IDs on the list, another words, the system will distribute the orphan disbursement allocations to Orphan IDs that exist first, before sponsoring new IDs, and, if we do have less capital month over month, the remaining orphans will be dropped.

She also explained that letters to the children *may* come from the wallet, as long as the sender is BiblePay.  So we will work on that behind the scenes to make that happen.

Very good work with the pool dev. I already see a small movement on c-cex.

Lots of people can't see really significant things with development (they will realize later)

1.0.2.1d for Windows reports a fatal error at shutdown when not using the -testnet flag. Debug.log:


It started in a clean folder, I deleted everything except wallet.dat.

thanks its running now

If you want to run the qt (gui) version:

cd src
./biblepay-qt

We also have a biblepayd daemon, you can find more by googling about bitcoind if you want to run the daemon.