Bitcoin Forum
November 19, 2017, 01:34:42 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Would preventing pooled mining help or hurt Bitcoin?  (Read 832 times)
jnwood
Newbie
*
Offline Offline

Activity: 9


View Profile
June 08, 2014, 11:33:53 PM
 #1

I was reading the Permacoin whitepaper at http://cs.umd.edu/~amiller/permacoin.pdf which got me thinking this question.  They require a method of preventing pooled storage.  From what I understand data storage is Permacoin's equivalent of hashing power for Bitcoin.  So they tied their "proof of work" algorithm to the private key of the reward payout address.  This prevents pooling because everyone "colluding" to pool their resources must know the private key to perform the work.  So if 100 people decided to pool their resources together, then they would all have to know the private key.  So when the pool solves a block then it would become a race between the participants to send the funds to an address that they controlled individually, which effectively negates the benefit of pooling.

Bitcoin doesn't have this "limitation" because the proof of work only depends on the public key.  Only the pool operator maintains the private key and the other pool participants trust him to pay out the rewards proportionally.

So here are my questions:

1. Would it be possible to change the Bitcoin protocol to work like this?  Is it possible for the proof of work algorithm to depend on the private key of the reward payout address?  I think this would even prevent "pools" like p2pool from working as well.  It would also squeeze out small miners who would never see a payout in their lifetime.
2. If it is possible, then would there be another protocol change that could bring the small miners back in?  Some way for them to get proportional rewards without pooling with other miners?
3. In either case for #2, would this be good or bad for Bitcoin?

Bitrated user: jnwood.
1511055282
Hero Member
*
Offline Offline

Posts: 1511055282

View Profile Personal Message (Offline)

Ignore
1511055282
Reply with quote  #2

1511055282
Report to moderator
1511055282
Hero Member
*
Offline Offline

Posts: 1511055282

View Profile Personal Message (Offline)

Ignore
1511055282
Reply with quote  #2

1511055282
Report to moderator
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.
1511055282
Hero Member
*
Offline Offline

Posts: 1511055282

View Profile Personal Message (Offline)

Ignore
1511055282
Reply with quote  #2

1511055282
Report to moderator
1511055282
Hero Member
*
Offline Offline

Posts: 1511055282

View Profile Personal Message (Offline)

Ignore
1511055282
Reply with quote  #2

1511055282
Report to moderator
1511055282
Hero Member
*
Offline Offline

Posts: 1511055282

View Profile Personal Message (Offline)

Ignore
1511055282
Reply with quote  #2

1511055282
Report to moderator
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2338



View Profile
June 09, 2014, 12:06:47 AM
 #2

The end result would be that the only way to get low variance would be to invest in a hosted mining company. This would not be an improvement over pooled mining.

Bitcoin will not be compromised
jnwood
Newbie
*
Offline Offline

Activity: 9


View Profile
June 09, 2014, 12:27:27 AM
 #3

The end result would be that the only way to get low variance would be to invest in a hosted mining company. This would not be an improvement over pooled mining.

True.  At least with pooled mining people can switch pools if they suspect the pool operator of foul play.  If small miners are all squeezed out from directly participating in hashing by the protocol, then significant hashing power won't even exist outside of hosted mining companies in the first place.

Would there be any effective difference between everyone switching to p2pool (including centralized pools) and changing Bitcoin's target to 30 seconds?  From what I understand small miners are still pretty unlikely to get any mining rewards using p2pool.  20 times better than almost impossible is still pretty bad.

Bitrated user: jnwood.
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2338



View Profile
June 09, 2014, 05:01:34 AM
 #4

Would there be any effective difference between everyone switching to p2pool (including centralized pools) and changing Bitcoin's target to 30 seconds?  From what I understand small miners are still pretty unlikely to get any mining rewards using p2pool.  20 times better than almost impossible is still pretty bad.
Yes, an enormous difference, P2Pool doesn't just make the shares 20x more frequent than the blocks: you're credited for a three day long rolling window of shares, so more like a ratio of 8640.... even more than that, p2pool users mine at different share difficulties, when a node gets too many shares in the window it increases its share difficulty to make more room for smaller miners (once you've got a few hundred shares in the window more shares hardly decreases your variance— the variance is dominated by the block finding variance at that point).

Bitcoin will not be compromised
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
June 10, 2014, 03:19:40 AM
 #5

It would be very easy to design a PoW which requires knowledge of the private key.  Bitcoin will never be forked to support this but a simple solution would be to require the block to be digitally signed by the private key which corresponds to the PubKey designated in the coinbase (reward) tx.  A block which is not signed, improperly signed, or signed w/ a different key is invalid.  

It is probably not a good idea though.   Some of the largest operators use no pools (look at the unknown portion of the network) and they would be unaffected.  Another negative is that it would eliminate p2pool and direct payout pool structures (eligus) which are preferable.  It would also prevent using multisig to enable more secure mining pools.  If anything it would be a barrier to entry for smaller players and further drive mining toward large hosted systems.
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2338



View Profile
June 10, 2014, 03:54:04 AM
 #6

It would be very easy to design a PoW which requires knowledge of the private key.  Bitcoin will never be forked to support this but a simple solution would be to require the block to be digitally signed by the private key which corresponds to the PubKey designated in the coinbase (reward) tx.  A block which is not signed, improperly signed, or signed w/ a different key is invalid.  

It is probably not a good idea though.   Some of the largest operators use no pools (look at the unknown portion of the network) and they would be unaffected.  Another negative is that it would eliminate p2pool and direct payout pool structures (eligus) which are preferable.  It would also prevent using multisig to enable more secure mining pools.  If anything it would be a barrier to entry for smaller players and further drive mining toward large hosted systems.
What you described there doesn't prevent pooling, since the block could just be submitted to the pool, who could sign it.  Though a non-randomized signature could be used by using its value in the target check.

It wouldn't even necessarily need to be incompatible with multisig, since it could just support an arbitrary script.... but yea, incompatibility with pooling is worse than the alternatives you'd get instead it seems.


Bitcoin will not be compromised
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
June 10, 2014, 04:11:49 AM
 #7

What you described there doesn't prevent pooling, since the block could just be submitted to the pool, who could sign it.  Though a non-randomized signature could be used by using its value in the target check.

Sorry it is late yes that was what I was trying to indicate.  The PoW target check would be based on the signature of the block not the unsigned hash of the block (as it is now).  There would be no need for a nonce field in the block header as the blockhash could remain constant.  To provide efficient setup of the PoW the same hash could just be signed with a different k value.  As a side note, ultimately it would lead to ECDSA mining asics.  Still I agree the larger point was that I am pretty sure this would be a bad idea.  It would massively raise the "barrier to entry" for small miners.

gmaxwell I am interested if you have any ideas on what could improve the decentralization of mining.  They never will be adopted by Bitcoin, I am just curious as it has been something which has bugged me for a long time.   The major advantage* of a using a pool with a higher hashrate (i.e. GHASH over BitMinter) is reduced variance.   We can see by human behavior that most miners want to see a consistent source of revenue and if we assume that means a 95% confidence of getting at least 1 block per day that puts the lower bound of a viable pool at 3.3%  [ P(X > 1) ~= 95% when λ = 4.75,  4.75/144 = 3.3% ].  Since a miner's major cost is electricity it is somewhat illogical to have a need for rewards everyday.  As long as your actual reward approaches your expected reward in a 30 day period a smaller pool would be fine.  Still it is hard to fight human psychology so lets start from an assumption that miners are uncomfortable mining in a pool which can't provide a reward at least once a day (say 95% confidence).  Pools which fail to maintain at least 3.3% of global hashrate fail to meet the expectation of miners and thus have a net outflow of hashrate which creates a reinforcing cycle trending towards 0%.  Even pools up to 3x that (say up to 10% of global reward) struggle.  The pools above 10% usually are secure only failing due to minor attrition for non variance reasons.  The bad news is that if 10% is the viable limit then we know it isn't going to end up as 10 pools with ~10% each. 

One option which naively would seem to help would be more blocks in a day.  At 2 minutes per block, for a pool to achieve the same 95% confidence of one or more blocks per day only requires 0.7% of the global reward.  Of course lower block interval means more orphans and that means pools with better connectivity and higher hashrates are rewarded.  So changes in protocol to reduce propagation times and resource requirements would be needed. 

Another option I had considered (but would be unpopular with miners) would be a very long maturing period for coinbase rewards.  If one had to wait 90 days to get/spend (depending on if pool does direct coinbase reward) block rewards, the daily variance would be less meaningful.  Still miners have operating costs so maybe 90 days wouldn't be viable.  Still 2016 blocks (14 days) could be or maybe some mechanism where the coinbase reward matures over a period of time (i.e. x% of reward becomes spendable over y days).  The last one would require some changing to how block reward is created (maybe not creating a direct reward but rather a "token" of sorts which allowed the miner to redeem the reward over time).

Last thing I considered if what would be the impact if a p2pool type structure was native in the protocol.  Would it be more heavily adopted?  Could its usage be enforced (with majority support) and thus the precision of the block reward could be decoupled from the number of blocks.

Thoughts, errors, any other ideas?


There are other minor reasons for picking a larger pool but I am not sure if they can be overcome by protocol changes.
* Larger pools tend to be longer running pools and thus are trusted more (protocol changes that reduce operator trust requirement?)
* Larger pools tend to have better software and thus appealing user interfaces, statistics, features, charts, etc (better open source packages to share development resources and improve the quality of smaller pools ?)
* Larger pools tend to have more revenue and thus can afford more resources in the form of better servers, higher bandwidth, and better DDOS protection (protocol changes which reduce server load and improve DDOS resistance?)
* Not really a reason but miners may be ignorant and still believe a larger pool pays more ( better education? )
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!