Grouping miners | Bitcointalksearch.org

VirosaGITS

legendary

Activity: 1302

Merit: 1068

Quote from: fevirfevir on December 31, 2015, 03:14:03 PM

I'll go with "uncles are cool" :-) I know it's not possible now (2 blocks simulteanously being accepted), forking and such, but I'm trying to wiggle my way around that. Will get back later once I do a proper write up. Thanks!

It would never fly, but for academic purposes you could look into merging the uncle code concept from Ethereum to Bitcoin. But it is not going to happen.

fevirfevir

newbie

Activity: 17

Merit: 10

I'll go with "uncles are cool" :-) I know it's not possible now (2 blocks simulteanously being accepted), forking and such, but I'm trying to wiggle my way around that. Will get back later once I do a proper write up. Thanks!

VirosaGITS

legendary

Activity: 1302

Merit: 1068

Quote from: fevirfevir on December 31, 2015, 02: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?

fevirfevir

newbie

Activity: 17

Merit: 10

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.

VirosaGITS

legendary

Activity: 1302

Merit: 1068

Quote from: fevirfevir on December 31, 2015, 05:50:34 AM

Hi all,

I was wondering if I could get some feedback on an idea that popped up, mining related.

I'm going to ask to make some assumptions here. The idea is that, by grouping miners, the mining process is distributed, effectively raising the amount of transactions per second. Grouping in this case is not the same as a pool, each miner in each group still would aim for his own profit. Also note that it's not about splitting the network, the P2P network remains intact, it's about distributing mining capacity.

Suppose that it would be possible to group all current Bitcoin miners (say, a protocol groups the current population of miners into two groups, group 1(g1) and group 2 (g2)), like Kademlia but with two buckets (could be more if the number of miners increase, but let's stick to two for now). Each group mines specific transactions (transactions are labelled 1 (t1) or 2 (t2) (t1s go to g1, etc)), and the same protocol also ensures that both groups can submit their found block simultaneously without creating a fork. I'm aware that's not really possible in Bitcoin's current blockchain implementation, but my question is about the grouping of miners, would that be a no-go from a centralization perspective? Thanks.

Um, okay, hold on;

If a miner is mining by itself, its solo mining, which is a no go.
If a miner is grouped with others miners and then is pointed to mining, that is a pool.

When you take x miners and you group them, you centralize those x miners.

So let me see if i understand what you are suggesting;

The BTC transaction that are not yet confirmed are put in a pool, and then groups of miners would submit their blocks, but not the same blocks as the other group. They would all simultaneously try to generate blocks, on the same chain. And all pools can submit blocks simultaneously, without creating a fork. ?

If i understood correctly, then this is my answer;
That is already, exactly how it works.

So if you want to decentralize, you'll want to make more, smaller pools instead of less, bigger pools. This is where the community is at, at the moment. The problem is that new users flock to the bigger pools, because thats a innate human response (survival) even if its a bad choice (for them, for everyone, except the pool they give their hashrate to).

fevirfevir

newbie

Activity: 17

Merit: 10

Hi all,

I was wondering if I could get some feedback on an idea that popped up, mining related.

I'm going to ask to make some assumptions here. The idea is that, by grouping miners, the mining process is distributed, effectively raising the amount of transactions per second. Grouping in this case is not the same as a pool, each miner in each group still would aim for his own profit. Also note that it's not about splitting the network, the P2P network remains intact, it's about distributing mining capacity.

Suppose that it would be possible to group all current Bitcoin miners (say, a protocol groups the current population of miners into two groups, group 1(g1) and group 2 (g2)), like Kademlia but with two buckets (could be more if the number of miners increase, but let's stick to two for now). Each group mines specific transactions (transactions are labelled 1 (t1) or 2 (t2) (t1s go to g1, etc)), and the same protocol also ensures that both groups can submit their found block simultaneously without creating a fork. I'm aware that's not really possible in Bitcoin's current blockchain implementation, but my question is about the grouping of miners, would that be a no-go from a centralization perspective? Thanks.

Topic: Grouping miners (Read 625 times)