Rob, all great points. Just some follow up questions...
1) Since Monero is anonymous digital cash, how does transparency work for donation to charity?
2) I'm confused by 10% charity aspect with XMR. Would the pools be able to mine enough XMR to equal 10% of the current BBP emission schedule?
3) xmrig and xmr-stak both have a dev fee where the miner hashes under the the dev address on a recurring schedule. Is this what you had in mind as well?
4) A pool could decline donation of XMR to charity?
5) Would the wallet or external miner be able to solo mine Monero & BBP as well?
** RandomX - Potential - Solving most of BiblePays problems at once **
I was thinking of ideas involving RandomX revenue solving some of BBPs problems last night, all credit to Jesus of course.
It came to mind that being a decentralized charity, removing the sell pressure would be absolutely huge for us, and we might be able to accomplish this (and some other things all at once).
Let us assume that we moved to a new model (phased in over a year, not at once). Let us assume that all sell pressure for orphan-charity is placed on the XMR side (IE decentralized accounts exist that receive XMR donations from mining activity). Our pools have trust levels, and are hired to liquidate the XMR once per month, and for example, spend the XMR on designated charities voted in by the sancs (IE, lets say Compassion, Cameroon One and Kairos for example).
Let us assume we : Remove the monthly charity budget (10%) and we give it back to the miners (to the POW side), we phase out POOM, and we give it back to the *POW HEAT MINING SIDE* (which is also about 10% of our coin emissions).
Now that the POW reward has increased by more than 20%, we do the following:
We create a hybrid pool for XMR + BBP, and miners have an equal chance of solving both blocks independently at 95% efficiency. However here is where it gets interesting. The pool automatically places about 10% of the mining rewards on the XMR side into one XMR charity account address as people mine.
Then at the end of the month, the pool operator liquidates it, spend it on compassion, and possibly keeps the accountability info on the pool web site under a subdomain (and over time I will work on aggregating it to accountability.biblepay.org also for a more centralized report).
Also, we tackle decentralization: The pool is opensource. The operator is decentralized. We install a trust monitor in BBP, so we can reconcile total XMR received vs spent, and verify 100% was spent on charity (per pool), and we apply this global seal of trust to each pool IE : pool1 : 100% trust, pool 2: etc, and this level can fluctuate if the owner of the pool fails to : Spend it on voted charity vendor, or Fails to collect it or liquidate it. We can place the pool list and trust level somewhere on our main web site etc.
Now what we have theoretically done is removed *all* sell pressure from BBP. At this point we would be free floating again (and without the 10% burden per month!). And our governing mantra can stay the same: 10% spent on orphan-charity, without pulling in the budget.
We also tackle the decentralization of the DAC at the same time. (On a side note, Ive been buying 3 character domain names, to potentially use in our future, for second and third branches of BBP that are rebranded- Im not talking about forking in any way, Im talking about having more than one coin with the same chain and two names; one name for a non-Christian and one name for a Christian; IE DEC.nnn and BIBLEPAY.org point to the same ticker on the exchange, BBP).
And this idea appears to support scalability as well. If our core price rises, we would have more miners; more miners would mean more flowing over to the liquidation addresses... Its interesting.
And of course, with more miners, more investors would appear also (giving us the free PR we need).
As far as mining is concerned, the miner would just connect to the pool and have a chance at earning double. The client software would automatically divert 10% of the heat-mined hashes toward orphan-charity by hashing it on the XMR side (each pool would have a unique XMR address to care for).