Bitcoin Forum
November 20, 2017, 02:59:51 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Grouping miners  (Read 474 times)
fevirfevir
Newbie
*
Offline Offline

Activity: 17


View Profile
December 31, 2015, 10:50:34 AM
 #1

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.
1511146791
Hero Member
*
Offline Offline

Posts: 1511146791

View Profile Personal Message (Offline)

Ignore
1511146791
Reply with quote  #2

1511146791
Report to moderator
Join ICO Now A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511146791
Hero Member
*
Offline Offline

Posts: 1511146791

View Profile Personal Message (Offline)

Ignore
1511146791
Reply with quote  #2

1511146791
Report to moderator
VirosaGITS
Hero Member
*****
Offline Offline

Activity: 910


Want to save $? Use Coupon Code VOFF5 at GPUShack


View Profile
December 31, 2015, 07:35:41 PM
 #2

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).

Ethereum Mining Calculator - Simple, elegant, mobile-friendly Ethereum Mining Profitability Calculator
gpuShack mining hardware - Your one stop shop for all GPU mining related hardware! Use Coupon Code VOFF5 to save on any order.
ethOS - #ethosdistro on freenode - linux distro that mines Ethereum out-of-the-box.
fevirfevir
Newbie
*
Offline Offline

Activity: 17


View Profile
December 31, 2015, 07:59:05 PM
 #3

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
Hero Member
*****
Offline Offline

Activity: 910


Want to save $? Use Coupon Code VOFF5 at GPUShack


View Profile
December 31, 2015, 08:10:30 PM
 #4

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?

Ethereum Mining Calculator - Simple, elegant, mobile-friendly Ethereum Mining Profitability Calculator
gpuShack mining hardware - Your one stop shop for all GPU mining related hardware! Use Coupon Code VOFF5 to save on any order.
ethOS - #ethosdistro on freenode - linux distro that mines Ethereum out-of-the-box.
fevirfevir
Newbie
*
Offline Offline

Activity: 17


View Profile
December 31, 2015, 08:14:03 PM
 #5

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
Hero Member
*****
Offline Offline

Activity: 910


Want to save $? Use Coupon Code VOFF5 at GPUShack


View Profile
December 31, 2015, 10:04:46 PM
 #6

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.

Ethereum Mining Calculator - Simple, elegant, mobile-friendly Ethereum Mining Profitability Calculator
gpuShack mining hardware - Your one stop shop for all GPU mining related hardware! Use Coupon Code VOFF5 to save on any order.
ethOS - #ethosdistro on freenode - linux distro that mines Ethereum out-of-the-box.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!