Quote from: shorty34 on January 24, 2020, 09:21:59 PM

Quote from: bible_pay on January 24, 2020, 09:02:18 PM

So I've been thinking about another potential possibility for our next replacement POBH miner for heat mining.
I'm thinking of possibly using RandomX as our next POW algo and creating compatibility in BBP for merge mining XMR from BBP.

(Up til today, I was primarily considering a new POW protocol that would do some type of useful work, until the idea was considered, that the useful work might be the *mining revenue* from XMR - where miners could earn the electricity from (XMR) but still fully secure the chain with randomx). This idea made me think of the benefits of less sell pressure and more income for the miners.

Im also thinking it would open up the possibility of all XMR users to have a desire to mine and be exposed to BBP.

The way it would work is this (potentially):
- BBP adopts RandomX as its core hash algorithm
- BBP creates a new pool that is both RandomX, Monero, and BBP compatible
- Miners mine BBP with RandomX as full fledged CPU miners with more arguments in the miner (IE multiple receive addresses)
- The pool has the capability to forward 100% of the solutions into Monero using the miners supplied monero address

I've been evaluating this today, and it appears to be 100% efficient (another words, it would not be as if you are merge mining and switching between protocols with inefficient losses).

Basically, the pool miner would win the XMR round anytime the miners difficulty is below the pool target, but for every XMR hash, we would test for an equal BBP solution like this:
must equal X11(PrevBlockHash + RandomXHash) < BBP_DIFF, plus block.RandomXsource must match RandomX hash (ensuring our prevBlockHash is the one in the round), and, the core wallet ensures this randomX set meets the difficulty of the BBP block. This basically means it would be possible for BBP miners to earn 100% of the revenue from randomx hashes, while still hashing BBP with an equal chance of solving the current BBP block using the same spent hashpower for the current hash minus a tiny bit of overhead (for checking each one, which I assume to be 10% or less).

Some of the potential upsides I see to this:
- More BBP exposure
- More Revenue for the miners
- Less sell pressure
- Monero users get exposed to BBP and the gospel

I thought I would throw this out there, so if anyone has any downsides or questions please pose them. In the mean time, Ill do some thorough investigation and consider making a proof of concept for this to ensure this is feasible.

From the high level, it appears to be a good solution for us on the heat side. We would of course make the POBH verses compatible and keep the bible in, for biblical reference.

Wow - by far the most exciting idea I heard over here for a while !
Double-sided exposure on the latest cpu-favoring algo around, and more income for miners - simply great.
I have played with randomx for a bit, and it definitely puts less stress on the cpus since it typically uses half (or less than half) of the possible threads. Less heat produced = less energy wasted.

There is one risk I see, though. Merge mining tends to create sell pressure on one of the coins in the pair - if miners would rather hodl the other one (that is, if they are hodling at all). You can check out the case of LOKI and TURTLECOIN; they recently abandoned the merged mining option. The only precaution I can think of is introducing some sort of ABN requirement (perhaps even dynamically changing as diff changes) to make sure some BBP has to be locked in. Oh, that would also deter possible botnets??

Thanks, I do see the Loki + turtlecoin expiriment. I assume that Lokis market cap started dropping as turtle sold the coins on the loki side. Interesting.
Well in our case, its BBP, the flea on the back of XMR. So I guess it would be a case of miners being able to sell some XMR to recoup electric and they would hold BBP (most likely) when our price is low, and thats basically the problem we have now, since we spent so much on charity. When would it work in reverse, I suppose if we had a nice run up from this (which would be a good problem to have).

Yeah, you bring up a good point on the botnet, simply because up til now, since we are proprietary, there is no mass desire to make a botnet out of BBP with our low price, but otoh, if we did this new project, we would have 10 million potential miners with the potential of being in a botnet. I think that will be solved 90% of the way, because the reqs for us to do this require a specialized BBP miner (it cant be done with the plain old XMR miner), so that knocks out most of the botnet, but otoh we have to consider the risk of if our price is rising. Im not sure how easy we could implement ABN, but I think we can raise the bar pretty high: Must run specialized bbp miner, must pool mine to receive the merged revenue, and, we could check in the pool for something from BBP (possibly a CPID), if we want to cut down botnets that way. Great points! I dont think this part will be a showstopper either.