Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 770. (Read 243376 times)

thanks both. I needed to check both of them.

Side note: immature balance will not show in getbalance, to see that use getwalletinfo.

Go to your biblepay directory (cd biblepay/src). If you are already running a daemon, type
else type the command below to start your daemon and wait till it syncs
To explore other commands enter

Hey everyone,

How do you check amount of coins in the wallet on terminal screen? I do not have gui access.

Sorry, but that's not how this works. All kinds of development for the coin can be good, plus, we need the miners, and I want new miners to be able to start mining without needing much technical knowledge.

But while I think development should be applauded, I don't think we should simply hand out money for things that were developed on a voluntary basis in the past, as I think that's the wrong approach. That's why I also have concerns regarding Togo's billing of some his activities (I think he's doing an AWESOME job btw, I just think not all of his past activities should be compensated with monetary funds).

I'm all for submitting proposals and making this coin really work. But I think we should take the forward approach instead of a backward one. I don't want to incentivise people to go out there and do stuff and try to get money for it afterwards (not that anyone did that in the past!)

So I'm all about where we want to go from here, and then allocate people and resources from the superblock to really make things happen.

I amvery excited to hear this. Is it availablenow. What about the value and other details.

This was created 2 months ago and I'm sure many in the forum used it, since I got a bunch of messages about it.

Definitely, The sanctuaries are here to decide what they deem is worthy and what's not. Would be happy to act as the first neutral proposal that gets both the votes from the sanctuaries.
"The process is more important than the outcome".

Yes, thank you Rob for taking this approach I want to be conservative concerning the orphans, and pay ahead well into the future before taking on new ones.

Is there a way to change this? As in: 'total amount of coins per month * 0.2'

I'm wondering how the superblock is filled with coins. Is it instantaneously at the moment of creation, of is it per block?

sanctuary owner maybe say no to you because they don't need mining.

[New Proposal Added]

I don't have a sanctuary yet since my coins are stuck in C-Cex, but testing out the proposals in the meantime. (Thanks Togo for the nudge)
Here's my proposal for my auto pool mining script back in October.

http://forum.biblepay.org/index.php?topic=56.msg920#msg920


Feel free to vote yes or no.
Cheers,

I've reached out to them and am awaiting a response.

How difficult would it be (other than the temporary pain of missing a month), to shift the budget from forward looking to backwards looking?

What I'm thinking is the emission structure could get the estimate wrong as you've accurately stated.  So, is there a way to shift the funds to four wallets, an Orphan Wallet, IT Wallet, PR Wallet and P2P Wallet each superblock.  Then those are the coins are available to be voted upon for 30 days, and at the end of that 30 day period (when the next superblock arrives, or more accurately at superblock -1) the wallet funds are distributed to the proposals that win?  The one issue would be trying to "save" up projects for an extra month during the transition.  But it would eliminate the risk of being too conservative with our funds (especially in the orphan fund).

I just discovered one interesting thing regarding our budgets:

I was trying to reconcile the 2.8MM coin emission in the 30 day superblock cycle for one month of charity expenses, vs. the huge amount of coins we initially sold for the very first month of existence (7MM), and I was thinking, why less than half?

It turns out the reason why is our superblocks use the assumption of maximum diff and minimum block payment, to ensure that enough BBP is held back during the period regardless of the dynamic emission level - another words, it assumes each days minimum subsidy is paid to comprise the 30 day 20% total.

So if you are trying to reconcile this 5.78MM budget for one month, its based on the minimum 5,000 BBP block minus deflation (1.5% per month) * .20.

My only concern is that our price level stays high enough to fund compassion at our current 188+ child level far into the future.  With our tithe blocks ending we basically ramped off from close to double the emission to half. 

Lets hope our price is here to stay.  So if we can maintain and grow, this emission level will be positive for our scarcity and may propel us higher.

Slovakia,

Miner Who Found Block is now being populated.




PS Anyone who noticed the external links were dissapearing: FIXED.

Thank you so very much, that has been the main thing that keeps me up at night is that we could get over-extended and unable to support the current orphans.  The upheaval in their lives would be devastating.  Thank you again.

Yes, what we can do is after I sell the compassion coins (that will probably be Jan 30 of 2018, based on when ccex comes back) or so, if we have excess, instead of sponsoring new orphans Ill prepay some orphans premiums, and Ill add a column to our "Expenses" business object so we can all see the PrepaidPremiums column, so our budget is balanced.  No new orphans, good point, done.

Will you consider on the Charity proposal the following:

1st order: Sponsor current orphans for another month.
2nd order: Repay "loan" from Dev (with accounting to help minimize critics)
3rd order: Part 1) Instead of sponsoring additional orphans, pay the current contracts forward.  Strive to have a full year pre-paid for each orphan.
3rd order: Part 2) The Compassion site says the average orphan is sponsored "usually through the school year in which the child reaches the age of 18 to 22". 
I would like to see from Compassion a breakdown by our current orphans of what age they'll need sponsorship to.  Then sponsor each of our current orphans to their full age before adding any more.

The reason for all this is I don't want to see any orphans have to be dropped if the coin price drops greatly.  Nor do I want to see their lives disrupted if the majority of MN decide they like a different charity better.

// Final Distribution: 10% Charity, 2.5% PR, 2.5% P2P, 5% for IT
so of the budget that would be 50% Charity, 12.5% PR, 12.5% P2P, 25% IT

5,789,219.786313 Total BBP this Budget cycle:

50.0% Charity = 2,894,609.89
12.5% PR        =   723,652.47
12.5% P2P       =   723,652.47
25.0% IT         = 1,447,304.94

(I rounded the decimals at the end)

Lets see:
// Final Distribution: 10% Charity, 2.5% PR, 2.5% P2P, 5% for IT
   
So I will enter a proposal for about 2.8MM coins for compassion, (thats half of the total budget, equal to the full charity budget), and when I sell them, it will be clear how much was raised (as we have the Orphan Fundraiser records in the pool), and of course, if we end up going in the black, Ill try to be more careful and only sponsor new children where the amount extends out to One Year (of premiums), so we have a buffer (we talked about that in the beginning).  This month was just a fiasco due to some issues at compassion, that is a different story.

Regarding IT, I have a recurring expense for some things, like web hosting and AWS (Storefront integration) but its not a lot of money.  Ill probably make an IT proposal for that, and one for "payroll" for myself.  Since this is a monthly budget, Im thinking about approx 60 hours, but Ill have more details later, when I make the proposal for that, Im going to attempt to make the forum link have details that link to github issues, so when we attract paid devs, I can base their payroll on commits for projects.

Yes, as far as figuring it ourself, we do have to multiply our 5.78MM superblock budget by the percents currently, but let me think of a way to streamline that.  This first month is more of a manual process.  We do have the capability however to hold proposals back from the budget, once we exceed 5.7MM in proposals.