Split block reward to reduce miner variance

[bg002h]

Here is an idea (that very well may be of no merit): let each block be composed of 25 mini blocks, each of which may award themselves up to ฿1. Each block accumulates the lowest hashed mini-blocks until one of the 25 hits the target for the main block...or maybe when the sum difficulty of the 25 mini-blocks hits the target would be best.

Would this make mining in smaller pools more attractive to those with hashing power?

If it's a dumb or old idea that didn't pop up in my forum search, my apologies.

[amaclin]

Would this make mining in smaller pools more attractive to those with hashing power?

Comparing with solo mining? Yes.
Comparing with mining in big pools? No.
So it is not a solution against power centralization

[sile16]

The problem is the proof of work is tied to the transaction that sends the block reward.  So, there isn't an obvious way to generate a coherent block using multiple proof of work solutions.  So, the ways to make the block reward more granular means more blocks more often.  However, there is a tradeoff as each block has additional overhead.  So if you change from 10minutes to every 1 second the amount of additional network / computation / storage would make running the protocol much more challenging.   So, there is the trade off.

[gmaxwell]

It's very similar to p2pool, though p2pool has a much larger merging window (8640 shares instead of 25) and isn't forced by the network.

(Not the sum-difficulty part— that wouldn't be progress free: it would give super-linear returns to faster miners, that part is a bad idea)

[bg002h]

The problem is the proof of work is tied to the transaction that sends the block reward.  So, there isn't an obvious way to generate a coherent block using multiple proof of work solutions.  So, the ways to make the block reward more granular means more blocks more often.  However, there is a tradeoff as each block has additional overhead.  So if you change from 10minutes to every 1 second the amount of additional network / computation / storage would make running the protocol much more challenging.   So, there is the trade off.

Why not enforce each block to have 25 coinbase tx's to different payout addresses and force the hash of each of those addresses combined with a subset of tx's in the block to be less than a specified difficulty value.  Nobody gets a payout until 25 such hashes meets a difficulty threshold.

[gmaxwell]

Why not enforce each block to have 25 coinbase tx's to different payout addresses and force the hash of each of those addresses combined with a subset of tx's in the block to be less than a specified difficulty value.  Nobody gets a payout until 25 such hashes meets a difficulty threshold.

Any kind of "You must find X (x>1) results meeting condition Y" is not progress free. Rather than being like a lottery where you win instantly by chance— even if you just make a single lucky roll— with probability linearly proportional to how much you play, these patterns accumulate work and as a result faster participants have a much more likely chance to win compared to normal mining.

If you're not seeing that, imagine an extreme case where you must have a billion difficulty-one solutions to form an acceptable block. In that case a miner with 40% hash-power would win virtually every time against a number of other miners with 10 and 20%.

[bg002h]

Why not enforce each block to have 25 coinbase tx's to different payout addresses and force the hash of each of those addresses combined with a subset of tx's in the block to be less than a specified difficulty value.  Nobody gets a payout until 25 such hashes meets a difficulty threshold.

Any kind of "You must find X (x>1) results meeting condition Y" is not progress free. Rather than being like a lottery where you win instantly by chance— even if you just make a single lucky roll— with probability linearly proportional to how much you play, these patterns accumulate work and as a result faster participants have a much more likely chance to win compared to normal mining.

If you're not seeing that, imagine an extreme case where you must have a billion difficulty-one solutions to form an acceptable block. In that case a miner with 40% hash-power would win virtually every time against a number of other miners with 10 and 20%.

Now I understand. It's easier to see in the extreme case. Thank you.

if 10 non p2p type pools control 99% of the hash rate, miners have very few choices in terms of what transaction inclusion policy they want to support with their hash power.

[bg002h]

I'm confused again. Im not asking 1 party or pool to come up with 25 solutions meeting condition Y...the idea is that those that do find 1 of the 25 solutions to broadcast them to the network...mining pool operators can incorporate those solutions on their quest for 25 or forgo them in hopes of finding their own. The probability that any one pool gets all 25 I would think would be very low...it would also make it easy for pools to join forces against a dominant pool.

Since the tx inclusion policy per block is now variable (there may be 25 separate policies per block), wouldn't that be better? We want to avoid 51% of hashing power being used in support of one transaction inclusion policy; 75% hashing power supporting 25 policies would be a good thing, right?

I see one 40% mining pool having a huge advantage over another single 10% pool (as a sum on a binomial probability distribution), but that's a slightly different scenario where work isn't shared.

[gmaxwell]

I'm confused again. Im not asking 1 party or pool to come up with 25 solutions meeting condition Y...the idea is that those that do find 1 of the 25 solutions to broadcast them to the network...

Your proposals are not very clear on the technical details. I can interpret what you're saying in multiple ways. If the work you're describing must be cumulative e.g. one building off another to ensure publication than what you're describing is basically what P2Pool already does (though it doesn't impose anything on transaction selection).  If the work is independant but a block must have a total of it, then that isn't progress free— the hypothetical 40% miner could listen to everyone elses announced shares, but horde its own jealously until it finds a block and thus have a significant advantage.

It might help to describe how you think what you're suggesting is different from what P2Pool already does.