Bible Pay

Governance => Pre-Proposal Discussion => Topic started by: Rob Andrews on January 26, 2020, 10:09:36 AM

Title: BiblePay Future Hash Algorithm for CPUs
Post by: Rob Andrews on January 26, 2020, 10:09:36 AM
Option 1 - POBH 3.0:  This means we would rewrite POBH (which has the 31,000 verses of the bible) in a way that would run slower in a GPU (than on a CPU) and be very unlikely to work on an ASIC in the future.  This appears to be possible by using .netcore's polymorphism, branching, and large initial required data streams.  In a nutshell it would take more work to move the inital calculated stream to a GPU than to perform the operation on the CPU.  The CPU is also the only way to execute the dotnetcore commands.

Option 2 - Math Prize:  Embed one of the worlds greatest math problems in the next algorithm, to give BBP a chance of winning the $1 mil prize, for example.  One example is the Reimann Zeta hypothesis, when calculating Zeta on the critical strip above 10 to the 30th power, these zeroes become extremely hard to calculate and elusive (the highest found is 10 to the 30th).  https://www.claymath.org/millennium-problems/riemann-hypothesis

Option 3 - Useful Work:  This option is similar to #1, in that our hash function would be in dotnetcore, but the difference is we would update the code occasionally using auto-upgrades.  And the code would perform some type of useful work; similar to what is done in boinc projects.  We would find a useful algorithm and use it until it needs upgraded (such as CFD, for instance that Togo recommended). 

Option 4 - RandomX and dual revenue streams for the miner:  The idea here is that we switch to the randomx hashing algorithm, for core wallet, pool and miner.  We add the ability to allow the miner to mine any randomX coin (we do this by querying the block-key which changes every 2048 blocks in all randomX coins, and making our hash algorithm solve for an *equation* rather than the diff level. )  This way, our miner can perform useful work that generates revenue, by mining XMR or another randomx coin, for instance.  However the difference is, every hash that is calculated in the randomX virtual machine would have a chance at solving the current BBP block also.  This would provide a dual revenue stream for the miner.  Theoretically, we would be a more enticing project for every randomx miner, simply because of the dual revenue.  This algorithm appears to not only be possible, but 95% efficient, meaning that each hash counts for both the primary randomx target (ONE only), plus BBP.  The theoretical algorithm we would use is :  X11(PrevBlockHash + CurrentRandomXHash) < DiffLevel(CurBBPBlock).  Note this is novel and unique in that our diff and block spacing can be in parallel to RandomX.  It also means the miner can mine any randomx pool or coin, and not need the Monero wallet for example (they will need the SPV wallet for the coin they mine).   

Title: Re: BiblePay Future Hash Algorithm for CPUs
Post by: talisman on January 26, 2020, 02:45:49 PM
Options 2 and 4 are both very appealing; but I am leaning towards Option 4 (hence my current vote).

Science is good, I love it. Yet we currently are covering enough of that with PODC, I believe.

RandomX will definitely provide us with a lot of exposure at this stage. Monero network hash rate soared from 800 MH/s to 1.2 GH/s in a month - this corresponds to several hundred thousand cpus running RandomX, even if some of them are latest Ryzen 9s. In most parts of the world, a typical 5-year-old cpu is barely breaking even at current network hashrate. Those miners would simply jump over a side benefit such as merged mining of BBP, once they are made aware.

If I am right in the sentence above, then we would see a huge spike in difficulty of BBP POW - old timers or hobby miners may kiss their BBP rewards good bye. This needs to be prevented, imho.

Another concern I have is the flippers: many of those RandomX miners that start mining BBP will prefer to liquidate BBP first, to cover some of their expenses. Remember when we could earn Obyte, Neumannium and a couple others on the side last year with PODC? I doubt anyone kept, say, their Neumanniums :)

I believe this possibility has to be taken into account (better ready than sorry, right?). The only precaution I can think of is incentivising hodling of BBP (or soft-penalising of liquidation). Coin*age requirement as in the ABN times, or proportional PODC RAC requirement for POW rewards, or even fiat donations to charity required for POW rewards, you name it. People that have to pay up front for a reward will be less likely to sell it at any cost (which kills the market). 

 
Title: Re: BiblePay Future Hash Algorithm for CPUs
Post by: sunk818 on January 26, 2020, 11:20:58 PM
It is hard for me to vote because I feel like I have incomplete information. I'm leaning toward option 3.


For now, Option 1 is not clear on how GPU & ASIC would be mitigated.


Option 2 while a cool endeavor, not sure how you secure the blockchain and work on this particular problem. If there's a numerical figure you can market periodically, then that becomes newsworthy. I also worry if GPUs can already do this and CPU crunching ends up being less useful?


Option 4 like talisman alluded too... I'm worried about not enough hashing power to really make a dent and any mined Monero will not be a meaningful sum for the amount of work you put in. Then there's the time you spend with maintenance (hard forks, keeping up with Monero tech updates, updating miner, updating pool) which may or may not be a huge timesuck.


Option 3, if I understand it correctly will have some useful work like BOINC (although its not clear what it is). The part that attracts me to it is the auto-upgrade. Is this something that self evolves in the algorithm? Or introduces some sort of randomness in each new block making it difficult for GPU to replicate in real-time but easier for CPUs? A self evolving and always changing algorithm would seem like a good way to mitigate GPU/ASIC and a set-it-and-forget-it type of algo. If the hash rate goes down with each iteration of the algo, then miner rewards can go up while still maintaining network security.


I'm open to voting on any 4 -- I just would like more thoughts on each option.
Title: Re: BiblePay Future Hash Algorithm for CPUs
Post by: Rob Andrews on January 28, 2020, 09:53:07 AM
Options 2 and 4 are both very appealing; but I am leaning towards Option 4 (hence my current vote).

Science is good, I love it. Yet we currently are covering enough of that with PODC, I believe.

RandomX will definitely provide us with a lot of exposure at this stage. Monero network hash rate soared from 800 MH/s to 1.2 GH/s in a month - this corresponds to several hundred thousand cpus running RandomX, even if some of them are latest Ryzen 9s. In most parts of the world, a typical 5-year-old cpu is barely breaking even at current network hashrate. Those miners would simply jump over a side benefit such as merged mining of BBP, once they are made aware.

If I am right in the sentence above, then we would see a huge spike in difficulty of BBP POW - old timers or hobby miners may kiss their BBP rewards good bye. This needs to be prevented, imho.

Another concern I have is the flippers: many of those RandomX miners that start mining BBP will prefer to liquidate BBP first, to cover some of their expenses. Remember when we could earn Obyte, Neumannium and a couple others on the side last year with PODC? I doubt anyone kept, say, their Neumanniums :)

I believe this possibility has to be taken into account (better ready than sorry, right?). The only precaution I can think of is incentivising hodling of BBP (or soft-penalising of liquidation). Coin*age requirement as in the ABN times, or proportional PODC RAC requirement for POW rewards, or even fiat donations to charity required for POW rewards, you name it. People that have to pay up front for a reward will be less likely to sell it at any cost (which kills the market).

These are all great points.  However I even question my own logic (about the degree we should try to control the general public and free influx of mining activity) after working on the DSS model.  Although, your good point (about losing the ability to hobby mine BBP, and diff going through the roof) etc.  I think when we did have the problem of popularity in the beginning, we didn't take into account the value of the popularity - we only made the assumption the miners were selling 'golden bbp coins'.  Now of course with more experience, I see that we must regard the PR side (popularity, spreading the word) as equally important to prevent our project from dying and give us word of mouth to grow.

So that part of the equation would be:  Do we value a high difficulty and massive influx of miners and popularity more than losing the hobbyist?  I would say mostly yes, because as the total miner count rises, the net total reward of "BBP+XRP" must be able to support the mining activity. Another words there must be a reverse arb here, where a skyrocketing diff and massive influx of miners actually draws the price of BBP higher (because of the ability to sell XRP and hold BBP also).  Anyway, Im leaning towards the belief that we want the highest difficulty possible, and the most miners possible, to receive the most free PR possible.  This would simply mean a higher price for BBP equals the same reward per miner (with more miners). 

But I am not against installing some type of softer 'botnet' prevention mechanism to protect BBP, although what I am trying to avoid is anything that pollutes the ability to mine bbp without adding squirrely rules or fork risk.  Another words, ABN requires a massive amount of custom code in every pool and makes us a one off again.  Since the only possible way to mine dual bbp+xrp is through the pool, what we may be able to do is require miners to have N balance in order to mine.  The pool could potentially check the miners BBP balance.  For example if < 100,000 (on the public key) the pool disconnects.  That would require them to solo mine.  Since the new dual miner will only dual mine with an XRP+BBP pool, it would make it harder to get around that rule. 

So at this point lets try to assume what would happen.  If the word got out that you could dual mine, as you say, 10,000 miners would try to heat mine, driving up our diff.  If our price does not rise some will leave.  It will end at an equilibrium that covers the cost of mining.  If we require a balance in the mining key of 100,000 we would limit the influx, but potentially drive up our price as they come on board.

Im not completely sure which pair would be sold, I agree however that if the project has no future, and the price is > XRP per KWH, BBP would be sold.  But we are the ones with the Sancs, so I feel that it is enticing to hold the BBP side and sell XRP.  But as we know this is unpredictable.  We just need to make our project more enticing, with real features and service on top of RandomX.  (To make the sell side less appealing etc).

Title: Re: BiblePay Future Hash Algorithm for CPUs
Post by: Rob Andrews on January 29, 2020, 08:03:06 AM
It is hard for me to vote because I feel like I have incomplete information. I'm leaning toward option 3.


For now, Option 1 is not clear on how GPU & ASIC would be mitigated.


Option 2 while a cool endeavor, not sure how you secure the blockchain and work on this particular problem. If there's a numerical figure you can market periodically, then that becomes newsworthy. I also worry if GPUs can already do this and CPU crunching ends up being less useful?


Option 4 like talisman alluded too... I'm worried about not enough hashing power to really make a dent and any mined Monero will not be a meaningful sum for the amount of work you put in. Then there's the time you spend with maintenance (hard forks, keeping up with Monero tech updates, updating miner, updating pool) which may or may not be a huge timesuck.


Option 3, if I understand it correctly will have some useful work like BOINC (although its not clear what it is). The part that attracts me to it is the auto-upgrade. Is this something that self evolves in the algorithm? Or introduces some sort of randomness in each new block making it difficult for GPU to replicate in real-time but easier for CPUs? A self evolving and always changing algorithm would seem like a good way to mitigate GPU/ASIC and a set-it-and-forget-it type of algo. If the hash rate goes down with each iteration of the algo, then miner rewards can go up while still maintaining network security.


I'm open to voting on any 4 -- I just would like more thoughts on each option.
So on #1, POBH 3.0, from a succinct level, citing the work of others (for example, Frank Gennari - Univ of California), and all of the research I have done so far, points to only three overarching ways to control GPUs exec speed, from overtaking CPUs:  Random branching (like randomx), Memory bottlenecks (again randomx), and IO bottlenecks (most other attempts).  The reason POBH 1.0 failed was primarily due to the shared KJV bible (allowing the gpu lanes to refer to shared pointers).  And we hashed the verses verbatim.  So the first line of defense would be to create a version of the bible, for the miner, for the hash operation, sequentially with checkpoints.  The second would be to force the miner to write also to the bible (not just read).  These two things would knock out shared pointers.  Then adding the IO bottleneck would ensure the code stays on the CPU.  The IO bottleneck means we create a streaming operation first, containing a lot of non-deterministic data up front - that would require more work to move the stream of data to the gpu and calculate it and move it back for that single hash - than to calculate it on the fly in the cpu.

On #2, all I can say is we would have worked until we found one, and ran it until the wheels fell off.  Then worked to find another one.  Yes, its possible someone else solves the prize within a couple years and then we would be back at square 1 again.

On #3, This was actually my favorite before the randomx idea.  I planned on doing #1 anyway inside #3 as a PART A.  Part B would have been something like CFD, but with an auto upgrade.  And a way to keep this fork proof (a fork virtualizer), meaning our algo could change over time.  In this case, what would prevent it from gpu and cpu would be the reliance on .netcore, which is way too big to run on a gpu, and using random branching (and since part a would contain the io bottlneck, that too). 

On #4, Im of a completely different opinion on this I believe.  Although I am worried about Monero making frequent changes, the positive thing is they would be tested by their devs (this is sort of an expansion of developer abilities, which we do need since we have a small IT dept), and they would be checked in a way where we can pull them in.  Also, we would have our own branch (we have to for stability), so we could theoretically choose to stay on the old algo.   So yes its a growing pain, but it might not be a net time-hog compared to #1,2,3 - especially since we would be *expanding* our total dev contribution (lets say with 1-3 we have 2 devs, with #4, we have 14 devs, etc).  On the dent in hashpower, I actually think the hashpower influx would be large, increasing security- its a bonus to have 1000 or so miners adding to our security level, I believe.



Title: Re: BiblePay Future Hash Algorithm for CPUs
Post by: Rob Andrews on January 29, 2020, 08:25:24 AM
** 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).


Title: Re: BiblePay Future Hash Algorithm for CPUs
Post by: sunk818 on January 29, 2020, 12:43:14 PM


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).
Title: Re: BiblePay Future Hash Algorithm for CPUs
Post by: Rob Andrews on January 30, 2020, 03:04:58 PM
And I was just thinking of one other side benefit of a Monero + BBP pair mining partnership:
We would probably end up being listed on a bigger Monero exchange, either for free or relatively easily due to the demand of the pair.

I'm liking this concept ...  Right now I'm still creating a proof of concept in a (solution project) in testnet to ensure everything works as expected.  So far so good.  There are a lot of humps, big humps, but nothing extremely bad or impossible.

For example, RandomX uses a lot of ram to review blocks.  Yes, there is a 256Meg mode, which is what Im using in biblepaycore right now.  So I'm solo mining with 4 threads and its taking up 2 gig of ram on my VM (a lot) and Im only mining at 150 HPS.  There is also a thread safety issue, which we have resolved.  There was also the problem of solving for an equation in BBP (vs the diff):  Solved.  Adding Blake256 to BBP: Solved.   Its a huge undertaking.  I still need to make my testnet pool, for the proof of concept and test out of client mining against the pool, and the dual hash.  So my goal is to make this work end-to-end by around the time the poll finishes, then if we have strong support Ill continue to make a release for testnet.

I'll answer the questions asap.

Title: Re: BiblePay Future Hash Algorithm for CPUs
Post by: Rob Andrews on January 30, 2020, 04:02:17 PM

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.

Title: Re: BiblePay Future Hash Algorithm for CPUs
Post by: talisman on January 31, 2020, 05:43:46 AM
Why don't we simply launch dual mining with our own RandomX pool? If a lot of RandomX miners can be attracted to this first pool offering merged mining, then the pool fees may create a revenue stream for charity even without dipping into the BBP budget.
Title: Re: BiblePay Future Hash Algorithm for CPUs
Post by: Rob Andrews on January 31, 2020, 08:53:16 AM
Why don't we simply launch dual mining with our own RandomX pool? If a lot of RandomX miners can be attracted to this first pool offering merged mining, then the pool fees may create a revenue stream for charity even without dipping into the BBP budget.

If you were for example, to start up a pool now with both RandomX and BBP, you would force your user to switch algos (meaning every hash would only count once), so its not very enticing.

If you mean, make a custom pool that supports merged mining using this new randomx-bbp-dual-mining-algo, then yes, that is exactly what Im proposing above already - a custom pool that supports dual mining and a new hashing algo in BBP.  And the pool collects revenue for charity from *XMR* hashes (not from BBP hashes).  The goal is to see if enough XMR can be collected so as to completely remove sell pressure off bbp permanently.  Later, poom could be phased out and percentages of the xmr liquidation directed to legacy charities by % etc.

In a nutshell another way to look at this is miners are donating electricity (because their household is already paying for it probably) to the pool, we convert the electricity dollars back to XMR and then further into charity dollars.  And the miners incentive in this scenario is that we give them *double* the hashpower that they would get alone (they get 5000 HPS from XMR alone, but from the BBP miner they get 9,500 hashpower).    ( I don't mean to create an argument here with anyone about basement miners :), what I am simply pointing out is yes, there are some hobby miners out there with 50K of equipment and who can afford $3K per month electric bills, but lets face it, there are probably 50,000 single machine teens out there with a nice fast machine, where the mom is paying the electric bill and the kid says, hey I can mine xmr and make $30 a month in my own personal savings account - sort of like their allowance - this I think is the source of at least half of the hashpower ).

It appears to be a win-win for everyone.  And of course that includes changing the miners hearts into more compassionate people.

EDIT:  And I just realized you might have mean, what if we use the plain-vanilla randomx algo, and start a randomx pool and accept solutions from either our miners or the randomx miners.  That would require two pool daemons, one on the height of the monero coin and one on the height of the bbp randomx chain.  Again, it would result in either miner making one hash for one coin (not two).  I think the heavenly difference above is the dual-hash algorithm that has to be added. 
Title: Re: BiblePay Future Hash Algorithm for CPUs
Post by: talisman on January 31, 2020, 10:04:11 AM
I was exactly referring to what you had in mind (dual-mining algo custom pool) - will be great to see it live !
Title: Re: BiblePay Future Hash Algorithm for CPUs
Post by: Rob Andrews on February 05, 2020, 09:24:23 AM
One other very interesting possibility I have discovered, that is being programmed in, is the ability to also pair with other randomx coins (in addition to XMR).

Although I admit this is waaay to complicated to do on the initial rollout, Im making sure that it is possible in the future.  It also complicates how we drive for charity, complicates the pool and many other things.  But the pro would work something like this:
Let us assume we are operating as a pair with XMR for 1 year (BBP+XMR) is received for hashing.  Let us assume the program is a success and we generate more XMR in charity rewards than 10% of our charity budget would have allowed (from governance) and it successfully removes the sell pressure off of BBP (and part of the mining reward pressure too!).  Let us assume our price rises to 10 satoshi.

What we could actually potentially do is partner with another randomx coin, and most likely I would ask one of our eager community members, to take on starting a separate pool with that pair.  It would work the same way as XMR, but provide a separate revenue stream for charity.  Yes, it would impact the XMR relationship, but I don't think in a negative way.  What would happen is it would get harder to mine BBP (which theoretically results in higher priced units).  So it would not necessarily be a bad thing to have more than one type of pool.

But again, this is far in the future.  The main concept here is the core wallet will be written in a generic way, allowing the solving equation to solve not only XMR but for other randomx solutions as well.  The security would still pass also - due to the same pool integration requirements.

Title: Re: BiblePay Future Hash Algorithm for CPUs
Post by: Rob Andrews on February 05, 2020, 09:24:53 AM
We are within 7 days of testing this in testnet.