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?
1) Since Monero is anonymous digital cash, how does transparency work for donation to charity?
-> Yeah, this is a good point, but fortunately it doesn't look like it will be a showstopper. Although I was hoping we could make this entire process a little easier (than running Monero full nodes and a dedicated accountability web site), but it is what it is. If this ecosystem proves to be valuable then we can add Monero monitoring nodes. Anyway, to answer the question, it appears to be possible in this way: We would need to ensure each Pool owner adheres to a set of controls for each BBP transaction. One, they would create a Monero keypair for their pool. All *inbound* rewards would go the public address. They would dump the public viewing key (viewkey public) for the pool and have it on the website, and our accountability report would track *revenue* from that key. It says in Moneros docs, all inbound transactions can be monitored this way (but no outbound tx can be monitored). Then we would need them to create a liquidation record (similar to how I do now for all compassion liquidations), which means we would see the Expense side as well. It appears we would not lose any visibility by doing this.
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?
-> There are different ways to measure the 10%. If we are very specific, and say we currently spend 10% of all of our emitted coins for orphan-charity (meaning we raise 6 mil BBP coins per month worth $1,200 per month at current rates), or our mantra says We spend 10% of all heat-mined hashes on orphan-charity, yes on the surface a very keen accountant would realize that the latter could mean one of two different things. One, if the heat reward in BBP only goes up to 50%, then obviously only 5% is going to charity (from the gross). But thats not true if a dual-hash partnership increases mining activity from 100 miners (who spend a net total of $3K per month on electric) - if this program drives an increase in hashpower to 1000 miners, that spend a net total of $30,000 (1000 miners) per month, driving in a net charity benefit of $3,000 from hashpower alone (a 250% charity increase). So, this I think is the impetus that opens up BBP to unlimited growth; basically we create the ecosystem, watch it first, and if this is the answer we can tweak our boilerplate message to something catchy. I'm hoping that this equation, double the revenue for miners, a minimal loss in hashpower efficiency drives free PR in, and creates a scaling environment. If we had more than 1,000 miners tithing 10% to orphan charity the program would be a success. And although that isnt 10% of every emitted coin, thats still 10% to orphan charity from *two* heat mining sides (XMR + BBP). So we also have the benefit of two communities hashing for a common cause.
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?
-> Id rather cover this offline. I think we would want to raise bounties for the xmrig dev, and remove the donation in part to divert as much as possible to the orphan charity. The miner should only lose the orphan charity hashes, and get everything else (100 dual hashes to bbp and XMR, and 10 hashes goes to orphan-charity of those, and community tithes to xmrig with independent gifts).
4) A pool could decline donation of XMR to charity?
-> This has been my big concern today, and there is an answer. In prod, if difficulty is < 512, or the block is late, any pool can mine the block (or solo). If otoh, the block is not late and the diff > 512, we check our spork list of registered pools. If the pool receive address is not in the sporks, that pool is not allowed to be hashed to. I think we need to do this in order to install the trust score system for the pools. As long as the pool stays in good standing (over a 90+ rating), meaning they have liquidated all the funds , and received all the funds according to our monthly report, they stay in the spork list. They can be revoked if they fall below 90. And if they are a homegrown self compiled pool they wont get listed, unless the community votes them in (through a sanc vote).
5) Would the wallet or external miner be able to solo mine Monero & BBP as well?
-> Yes sort of. I think during the first 6 months, you will be able to solo mine, and, I already thought of the issue where we must make it the same difficulty to dual-mine or solo-mine and that is solved. There is absolutely no way to solo mine BBP faster than dual mining both XMR-BBP. So that would be pointless. And in order to implement #4, we need to add the spork-controls for pools. So I think the answer is we leave solo mining open, until we need to enforce the sporks. Once the sporks start going in then you cant solo mine a block in prod unless the diff is low (or the block is late). I think we have to do this to prevent corruption. Otoh, with the control enabled, we will certainly be able to track all revenue (as the address will be public, as to the income levels) and obviously we will see if it is spent on orphan-charity from the PDF receipts. So this entire end-to-end appears solid so far.