Variable side chain?

[sceniclife]

Hey @SChernykh,

As the current nano sidechain hasn't hit a block for 14 days and I am diving into the code base, I was wondering if it would be feasible to implement a p2pool that:

• instead of having a sidechain difficulty based off of the pool hash-rate to hit a target block time, we derive the job difficulty / block template from the miner's hash-rate
• all miners try to target say a 10 seconds block time (relative to their hash-rate)
• implement the sidechain to record the job's difficulty into the share / pool block (weight)
• reward proportionately to miners based on share difficulty POW

PPLNS window is the same for everyone in the pool (each trying for 10 second block time with their respective hash-rate). This would effectively make it so we don't have many variant sidechains (main, mini, and nano) and if the single p2pool hits a block, since shares recorded the difficulty of POW, it can reward proportionately.

This is all very high level and probably has a number of things to iron out, I am sure. Looking to make p2pool enjoyable and enticing for all.

Thoughts?
Happy holidays, happy mining!

[SChernykh]

This would result in thousands sidechain blocks per second, it's not feasible.

[sceniclife]

Could you help me understand how it would result in thousands of sidechain blocks per second?

Let me try to understand it meanwhile..
So sidechain difficulty is total hash-rate of the pool (main, mini, or nano) * block time target of the pool (10 seconds for main and mini, and 30 seconds for nano).
The block template for the pool will be created knowing that... oh I think I see.

The job difficulty, derived from the entire pool's hash-rate, is pretty high compared to a miner's hash-rate so shares would be infrequent for that miner. The block time target is for the entire pool.

In my proposal, if the job difficulty is hash-rate * block time target, yes.. the shares would explode on the sidechain.

Okay. What if we keep both?
sidechain difficulty = (total pool hash-rate * block time target)
job difficulty = (miner's hash-rate * block time target)

The sidechain difficulty can be used as an acceptance threshold for the pool block recording. This way everyone can be on one chain and be given jobs proportionate to their hash-rate. If the completed job's hash meets the acceptance threshold, it will be recorded on the sidechain?

Thoughts out loud:

• Doing it this way would increase number of shares generated but only the ones meeting sidechain difficulty would be accepted.
• I guess you can ask, how is this different than the 3 sidechains? Example: nano sidechain is lower, so more shares are recorded onto the chain, but the hash of nano still needs to be accepted on Monero chain (finding a block). Being a single sidechain, when the block is found, everyone with a share can eat.
• Then why did p2pool split main and mini in the first place, shouldn't everyone just stay in main? Main pool jobs were given at sidechain difficulty so it was hard for low hash to complete jobs. Solution above would allow for jobs to be completed (generating a hash) to be checked against the pool's block requirements. (similar to how the p2pool's hash probability meets the Monero network's block requirements)

Let me know if I misunderstood something!

[SChernykh]

Doing it this way would increase number of shares generated but only the ones meeting sidechain difficulty would be accepted.

"Increase" is an understatement. If every miner submits their low diff shares to the network every 10 seconds, this is O(N^2) volume of traffic. 2x the miners -> 4x the traffic, and so on (because each share from each miner must reach all other miners - classic NxN complexity). This doesn't scale, like at all. Which is why miners only submit shares that meet pool difficulty.

[sceniclife]

Yes, agree.

But that's why I said that only the shares meeting the sidechain/pool difficulty will be accepted. Miner accepts a lower diff job, calculates the hash that meets the low diff (share), then also checks that the hash meets the actual pool difficulty. If it does, then submit it?

[SChernykh]

Yes, agree.

But that's why I said that only the shares meeting the sidechain/pool difficulty will be accepted. Miner accepts a lower diff job, calculates the hash that meets the low diff (share), then also checks that the hash meets the actual pool difficulty. If it does, then submit it?

This is exactly how it works now.

[sceniclife]

Yes, I understand that is how it works right now, except we currently have 3 sidechains.

The implementation above would allow us to only need 1 sidechain.

[SChernykh]

Define exactly when the shares are submitted to the network in the implementation above, and what is the "actual pool difficulty". You will either get low hashrate miners submitting a share once every few days, or you will get a flood of shares in the network and no scalability. No way around this. This is why we have 3 sidechains now.

[sceniclife]

Hey, thanks for responding over the holidays,
You are correct that the low hash-rate miners submit rate will be low.

So
sidechain difficulty = (total pool hash-rate * block time target) is actual pool difficulty.

Let me describe a few scenarios and hopefully you can help me better understand the subject? Maybe I am misunderstanding something. In all scenarios, the sidechain difficulty is pool difficulty.

---

Scenario 1:
P2Pool only had default chain, this is pre mini sidechain split.

• Since the block template is created with the sidechain difficulty, this can result in highly difficult jobs for the low hash-rate miners in the pool. This is why we have 3 sidechains now.
• Shares that meet the sidechain difficulty are saved to the sidechain.
• Shares that meet Monero chain difficulty results in a block.
• Shares in the PPLNS window are rewarded.

---

Scenario 2:
P2Pool with 3 sidechains, default, mini, and nano.

• By splitting the miners into similar hash-rate groups, the respective sidechain difficulty is more attainable, and thus the block template jobs will also be feasible.
• Shares that meet the sidechain difficulty are saved to the sidechain.
• Shares that meet Monero chain difficulty results in a block.
• Shares in the PPLNS window are rewarded.
• However, as sidechains are separate pools, a block found in one does not reward the other.

---

Scenario 3:
P2Pool with a single sidechain, however job difficulty is not based on the sidechain difficulty, but instead on the miner's hash-rate.

• Shares that meet the sidechain difficulty are saved to the sidechain.
• Shares that meet Monero chain difficulty results in a block.
• Shares in the PPLNS window are rewarded.

---

In all three scenarios, the P2Pool sidechain difficulty is lower than the Monero chain difficulty.

Is it correct to state that a hash meeting Monero difficulty also meets the P2Pool difficulty?

In Scenario 3, I originally wanted all shares recorded. If the sidechain could handle recording all of the shares this way, this may work, right? (I understand you've stated this is not feasible)
If we keep job difficulty based on miner hash-rate, but check that the share meets sidechain difficulty, then the number of blocks recorded should drop.
The difference between Scenario 1 and Scenario 3 would be that a miner would have jobs that it could complete to generate a hash at all. In both, a low hash-rate miner share still has to meet Pool difficulty to be recorded.

In Scenario 2, a low hash-rate miner's POW is better recorded on the lower hash-rate sidechain than Scenario 1, however a hash must meet the Monero difficulty for a block to be found and anyone in the PPLNS window of that sidechain to be rewarded. Any shares not in the PPLNS window are expired, so mini and nano find blocks at a less frequent rate.

Recap:
In Scenario 1, low hash-rate miners are unlikely to compute the hash for the difficulty job at all.
In Scenario 2, low hash-rate miners can compute hashes in their sidechain, shares recorded, but that sidechain still needs to hit a block to be rewarded.
In Scenario 3, low hash-rate miners can compute hashes, sidechain difficulty is high since it is a single chain, only shares meeting that difficulty is recorded.

So maybe the difference between Scenario 2 and Scenario 3 is when a share is discarded? Scenario 2 discards when shares are outside PPLNS. Scenario 3 discards from the get-go since it does not meet sidechain difficulty, but also discards outside PPLNS for the ones that do meet sidechain difficulty. Scenario 3 will record less shares but blocks will be found more frequently.

[PolyOpenClearing]

Primary limitation in creating a more "open" system is the transaction fees (consolidation) when the miner decides to send/spend the earnings.
#388

I am currently drafting an official request for the Monero Team/Community to look into reducing or eliminating transaction fees for the very first consolidation.

[SChernykh]

Closed as this discussion is better held elsewhere, preferably on IRC. This is an issue tracker for bugs, crashes, etc.