Quote from: fevirfevir on December 31, 2015, 07:59:05 PM

Thanks for your response.

Apologies for the bad explanation, the word 'grouping' may be confusing here. I'm not refering to a pool, but a set of miners that is mining a particularly set of transactions (t1), each inidividual miner in that set aims to find a hash for its own block (no shared rewards, like in pools). The tricky part is when two sets of miners (different sets, that is) find a block; the protocol I'm trying to work on should be able to handle two blocks from two different sets of miners (but not two blocks from the same miners in a specific set). The assumption for now is that two blocks can be valid at the same time within the same cryptocurrency network, as long as they come from different sets (not pools) of miners.

There can only be one block #X, so if two miner find block #X, only one miner will get the block rewarded, you can't work around that, nor do you want to. (The concept of uncles is cool, however)

And the action of "grouping" miners is the action of "pooling the hashrate of several miners to work on a solution". So if you don't want to call it a pool, you can but thats what it is called.

Thus i will continue calling it a pool;

You will have your pool target a set of transaction (t1) and any other pool individually decide what set of transaction they want to include (t whatever). You will set parameters and decide which transaction you want to include depending on whats available in the mempool.

That is how it already work.

Maybe you're trying to build a concept on the misconception that if the pools were trying to include completely different transactions, they would be able to submit concurrent blocks?