Bitcoin Forum
February 24, 2017, 06:00:24 AM *
News: Latest stable version of Bitcoin Core: 0.13.2  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: Preventing Pool Mining  (Read 2740 times)
itamarhason
Newbie
*
Offline Offline

Activity: 9


View Profile
June 14, 2014, 09:53:39 PM
 #1

Pool mining centralization is a serious issue. Some think this can be solved by changing the reward system (Multi PPS as an example), or by finding an ASIC resilient hash function (no known good candidate).
I would like to discuss the option of changing the protocol to prevent pool mining.

I have an idea to start with, please say what you think of it. My suggestion is to add to the header, two new fields:
  • A bitcoin public address, which owns some minimal amount M of BTCs
  • A signature of the header (excluding, of-course, this field - the signature itself) using the private key corresponding to the above public address
EDIT: Pay attention to the fact that the hash is computed on all of the header - including the above added signature field.
In addition, the mining reward should be automatically given to the above public address, and transactions involving this address as input shall be forbidden in this block (to prevent a more sophisticated share distributions).

Adding these two fields, at least naively, should prevent pool mining, since in order to mine a block, you must know the private key corresponding to the rewarded public address. (I think it could work also with M=0, but I think M>0 makes it much riskier to use any trust-based pool)

P.S. I recognize the need in pool mining (mining reward variance etc.), but I think such issues can be solved by decreasing the block time substantially (to, say, 1 second, instead of 10 minutes, using GHOST).
1487916024
Hero Member
*
Offline Offline

Posts: 1487916024

View Profile Personal Message (Offline)

Ignore
1487916024
Reply with quote  #2

1487916024
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1487916024
Hero Member
*
Offline Offline

Posts: 1487916024

View Profile Personal Message (Offline)

Ignore
1487916024
Reply with quote  #2

1487916024
Report to moderator
1487916024
Hero Member
*
Offline Offline

Posts: 1487916024

View Profile Personal Message (Offline)

Ignore
1487916024
Reply with quote  #2

1487916024
Report to moderator
bluemeanie1
Sr. Member
****
Offline Offline

Activity: 280


bluemeanie


View Profile WWW
June 15, 2014, 12:24:28 AM
 #2

One known way to prevent an incentive for a malicious 51% attack is to introduce a PoS innovation to the mining algorithm.  In other words, the more BTC you own, the less hashing you need to do.  Thus, miners would need to be stakeholders in BTC and thus creating network disruptions would be clearly against their interests.  They have 'skin in the game'.  Another effect would be that the demand for BTC would increase significantly(which would cause an increase in price).

The most well known problem with PoS is something called Nothing At Stake.  If we had hybrid algo, there is something at stake(computation resource) which does not eliminate the problem of N@S altogether but would probably effectively mitigate it.  N@S suggests that you can create many alternative timelines at once and exploit that, however with a hybrid model, these alternative timelines cost computing power(and thus introduce a net disadvantage).

I think some of these ideas about preventing mining pools are somewhat awkward.

This solution would be generally non-disruptive and most certainly would have a very positive effect on the price of BTC.

-bm

Just who IS bluemeanie?    On NXTautoDAC and a Million Stolen NXT

feel like your voice isn't being heard? PM me.   |   stole 1M NXT?
itamarhason
Newbie
*
Offline Offline

Activity: 9


View Profile
June 15, 2014, 04:45:51 AM
 #3

One known way to prevent an incentive for a malicious 51% attack is to introduce a PoS innovation to the mining algorithm.  In other words, the more BTC you own, the less hashing you need to do.  Thus, miners would need to be stakeholders in BTC and thus creating network disruptions would be clearly against their interests.  They have 'skin in the game'.
-bm

Why do you think that in a PoS/PoW hybrid system mining pools won't be created? I don't think anyone would want to rely on the fact that a pool with 51% of the PoW/PoS power would have "no incentive" to attack the system, though all of the power to do so.

Anyway, I prefer not to discuss PoS systems in this topic. Please comment on my suggestion.
bluemeanie1
Sr. Member
****
Offline Offline

Activity: 280


bluemeanie


View Profile WWW
June 15, 2014, 04:49:17 AM
 #4

One known way to prevent an incentive for a malicious 51% attack is to introduce a PoS innovation to the mining algorithm.  In other words, the more BTC you own, the less hashing you need to do.  Thus, miners would need to be stakeholders in BTC and thus creating network disruptions would be clearly against their interests.  They have 'skin in the game'.
-bm

Why do you think that in a PoS/PoW hybrid system mining pools won't be created? I don't think anyone would want to rely on the fact that a pool with 51% of the PoW/PoS power would have "no incentive" to attack the system, though all of the power to do so.


in a hybrid PoS scenario, the miner would need to be holding BTC.  Thus, why would they want to damage the network?  pretty straightforward really.  It doesnt outright ban pools and I don't think this approach is going to work at all.

-bm

Just who IS bluemeanie?    On NXTautoDAC and a Million Stolen NXT

feel like your voice isn't being heard? PM me.   |   stole 1M NXT?
itamarhason
Newbie
*
Offline Offline

Activity: 9


View Profile
June 15, 2014, 04:56:14 AM
 #5

One known way to prevent an incentive for a malicious 51% attack is to introduce a PoS innovation to the mining algorithm.  In other words, the more BTC you own, the less hashing you need to do.  Thus, miners would need to be stakeholders in BTC and thus creating network disruptions would be clearly against their interests.  They have 'skin in the game'.
-bm

Why do you think that in a PoS/PoW hybrid system mining pools won't be created? I don't think anyone would want to rely on the fact that a pool with 51% of the PoW/PoS power would have "no incentive" to attack the system, though all of the power to do so.


in a hybrid PoS scenario, the miner would need to be holding BTC.  Thus, why would they want to damage the network?  pretty straightforward really.  It doesnt outright ban pools and I don't think this approach is going to work at all.

-bm


The pool could still have thousands of people holding both mining hardware and BTCs. The pool operator incentives are not so clear.
Anyway, please stick to the original subject. I don't want this discussion to be on PoS systems.
Zuminest
Full Member
***
Offline Offline

Activity: 175


View Profile
June 15, 2014, 05:32:10 AM
 #6

Preventing pool mining would open a can of worms for everyone that hashes that doesn't have the newest and priciest hardware. Imagine all those BFL Cubes and USB sticks going to waste! Oh noes! Smiley
DannyHamilton
Legendary
*
Offline Offline

Activity: 1708



View Profile
June 15, 2014, 06:17:28 AM
 #7

I don't understand how your proposal would prevent pool mining.

The pool creates the header, puts their address in there, and sign it.  Then they send it out to the "miners" to search for the hash.

When a "miner" solves the block, the pool broadcasts the block and gets paid.  Then in a later block, they split up the payment among all the participants.

What am I missing?  Is there something implied in your description that I didn't notice?

The quality of posts has dropped to such a low level that all users who are participating in a paid signature campaign are added to my ignore list. If you'd like a copy of the list to improve your browsing experience, you can find it here: https://bitcointalk.org/index.php?topic=973843.0 (Updated 2016-1-4)
itamarhason
Newbie
*
Offline Offline

Activity: 9


View Profile
June 15, 2014, 09:26:01 AM
 #8

I don't understand how your proposal would prevent pool mining.

The pool creates the header, puts their address in there, and sign it.  Then they send it out to the "miners" to search for the hash.

When a "miner" solves the block, the pool broadcasts the block and gets paid.  Then in a later block, they split up the payment among all the participants.

What am I missing?  Is there something implied in your description that I didn't notice?

You're missing the fact that the nonce and the merkle root are part of the header, so the pool manager cannot sign the header without counting over all nonces himself.
thebtcthe
Newbie
*
Offline Offline

Activity: 8


View Profile
June 15, 2014, 11:04:47 AM
 #9

The miner can include in the block payment transactions to the pool from another address. This does not prevent pools.
boumalo
Hero Member
*****
Offline Offline

Activity: 994


View Profile
June 15, 2014, 02:08:39 PM
 #10

If you don't allow pool mining, the amount of power to secure the network will be lower, the number of actors lower as well because the variance would be too high for most small miners

piotr_n
Legendary
*
Offline Offline

Activity: 1582


aka tonikt


View Profile WWW
June 15, 2014, 02:45:22 PM
 #11

Looking at the recent mining poll paranoia, I cannot resist the feeling that studying bitcoin mining charts may be more dangerous to a human brain than any drug known to man.

Get a life people and stop fighting imaginary problems.

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
itamarhason
Newbie
*
Offline Offline

Activity: 9


View Profile
June 15, 2014, 03:49:12 PM
 #12

If you don't allow pool mining, the amount of power to secure the network will be lower, the number of actors lower as well because the variance would be too high for most small miners

You're right that in the current system, pool mining is necessary. This is why I wrote that I think the variance problem can be solved by changing the block frequency to 1 sec, instead of 10 minutes.
itamarhason
Newbie
*
Offline Offline

Activity: 9


View Profile
June 15, 2014, 03:59:09 PM
 #13

The miner can include in the block payment transactions to the pool from another address. This does not prevent pools.
He can, but he has no incentive to do so, and the pool has no way, at least not any simple way, to make sure he does so.
itamarhason
Newbie
*
Offline Offline

Activity: 9


View Profile
June 15, 2014, 04:15:13 PM
 #14

Looking at the recent mining poll paranoia, I cannot resist the feeling that studying bitcoin mining charts may be more dangerous to a human brain than any drug known to man.

Get a life people and stop fighting imaginary problems.

I think there is a vast majority of bitcoin users who would much prefer a decentralized mining agents, over centralized mining agents.
piotr_n
Legendary
*
Offline Offline

Activity: 1582


aka tonikt


View Profile WWW
June 15, 2014, 04:54:29 PM
 #15

I think there is a vast majority of bitcoin users who would much prefer a decentralized mining agents, over centralized mining agents.
And I think none of them are an actual miners, so bitcoin does not give a shit about this "vast majority" of yours.

Why people are so keen to put their nose in things that don't concern them? Are you bored, or what?
Had miners needed "a decentralized mining agents" (whatever such creatures are), they would have invented them.
Bit it seem that centralized minimizing polls don't bother them, since most of the blocks are mined through such.
Of course they don't bother them. Why would minimizing polls bother miners, if miners are free to change the pool anytime they like?
It's not like they sign 12-month contracts with mining pools - they just chose the one that suits them best, at a specific moment in time.
And how is it any of your business?

From what I see, the only people who have problems with mining pools are those who don't mine at all - that's really funny.
But the most entertaining part is that you cannot do anything about it - and it's just so much fun to see you sweating Smiley

If you want to change the world of mining, there is only one thing you can do: start mining yourself.
But since you don't want to start mining, please at least stop whining - for your own sake.

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
itamarhason
Newbie
*
Offline Offline

Activity: 9


View Profile
June 15, 2014, 05:28:02 PM
 #16

I think there is a vast majority of bitcoin users who would much prefer a decentralized mining agents, over centralized mining agents.
And I think none of them are an actual miners, so bitcoin does not give a shit about this "vast majority" of yours.

Why people are so keen to put their nose in things that don't concern them? Are you bored, or what?
Had miners needed "a decentralized mining agents" (whatever such creatures are), they would have invented them.
Bit it seem that centralized minimizing polls don't bother them, since most of the blocks are mined through such.
Of course they don't bother them. Why would minimizing polls bother miners, if miners are free to change the pool anytime they like?
It's not like they sign 12-month contracts with mining pools - they just chose the one that suits them best, at a specific moment in time.
And how is it any of your business?

From what I see, the only people who have problems with mining pools are those who don't mine at all - that's really funny.
But the most entertaining part is that you cannot do anything about it - and it's just so much fun to see you sweating Smiley

If you want to change the world of mining, there is only one thing you can do: start mining yourself.
But since you don't want to start mining, please at least stop whining - for your own sake.

Look, suppose a change in the protocol will be accepted by the bitcoin users. In such case, the miners opinion is not relevant - they're just getting bitcoin in return to their service. I, and many others, can think that this service doesn't fit our need (due to centralization) and change the protocol accordingly. The protocol, and the value of bitcoin is determined by the users, not by the miners.
piotr_n
Legendary
*
Offline Offline

Activity: 1582


aka tonikt


View Profile WWW
June 15, 2014, 05:41:01 PM
 #17

Look, suppose a change in the protocol will be accepted by the bitcoin users. In such case, the miners opinion is not relevant
You obviously don't know how bitcoin works; how its protocol is protected and where its real value comes from.

No users, nor developers, can do a change in the bitcoin protocol without the miners accepting it - that is the very principle on which the entire currency has been build upon.

Had you tried to enforce a change in the protocol, and convinced a majority of non-mining users to start using your new software - this will create a fork and you will be left with a huge minority of the hashing power. And then how exactly is it going to be different from your current worse nightmare; the 51% attack?
It won't be - except that you would have willingly joined the party that already has far less than 50%.

In other words: if you'd try doing such a thing without changing POW function, you will jump before the wheels of the very truck that your are trying to escape from now.

At the other hand, had you decided to change the POW function, then it will not be Bitcoin anymore.
You would simply create an alternative currency, with a predefined distribution of coins.
But the old bitcoin (its miners and its price) would not even pay attention to your pathetic project.
And trust me; soon you would abandon your freshly created alternative currency and came back to bitcoin and its POW - because bitcoin is a monster that nobody can kill, while your new currency, without all this hashing power that protects our bitcoins now, would be just a vulnerable little baby that nobody wants to buy anymore.

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
DannyHamilton
Legendary
*
Offline Offline

Activity: 1708



View Profile
June 15, 2014, 07:38:13 PM
 #18

I don't understand how your proposal would prevent pool mining.

The pool creates the header, puts their address in there, and sign it.  Then they send it out to the "miners" to search for the hash.

When a "miner" solves the block, the pool broadcasts the block and gets paid.  Then in a later block, they split up the payment among all the participants.

What am I missing?  Is there something implied in your description that I didn't notice?

You're missing the fact that the nonce and the merkle root are part of the header, so the pool manager cannot sign the header without counting over all nonces himself.

Ah, I see what you are suggesting now.  Unfortunately, it wouldn't stop pooled mining at all.  All it would do is create a financial barrier to entry for small miners.

All the pool needs to do is:

  • Require a deposit from every participating miner that is at least as large as the largest blockreward
  • Issue each miner their own private key that the pool knows about.

Then the pool can monitor the blockchain to see if any coinbase transactions go to any of the addresses that were issued by the pool.  If so, the miner will be expected to allow the pool to split the reward up among the participants.  If the miner tries to "steal" the reward, then they forfeit their deposit (which will be split up among the pool participants).

The quality of posts has dropped to such a low level that all users who are participating in a paid signature campaign are added to my ignore list. If you'd like a copy of the list to improve your browsing experience, you can find it here: https://bitcointalk.org/index.php?topic=973843.0 (Updated 2016-1-4)
thebtcthe
Newbie
*
Offline Offline

Activity: 8


View Profile
June 16, 2014, 12:34:35 AM
 #19

I don't understand how your proposal would prevent pool mining.

The pool creates the header, puts their address in there, and sign it.  Then they send it out to the "miners" to search for the hash.

When a "miner" solves the block, the pool broadcasts the block and gets paid.  Then in a later block, they split up the payment among all the participants.

What am I missing?  Is there something implied in your description that I didn't notice?

You're missing the fact that the nonce and the merkle root are part of the header, so the pool manager cannot sign the header without counting over all nonces himself.

Ah, I see what you are suggesting now.  Unfortunately, it wouldn't stop pooled mining at all.  All it would do is create a financial barrier to entry for small miners.

All the pool needs to do is:

  • Require a deposit from every participating miner that is at least as large as the largest blockreward
  • Issue each miner their own private key that the pool knows about.

Then the pool can monitor the blockchain to see if any coinbase transactions go to any of the addresses that were issued by the pool.  If so, the miner will be expected to allow the pool to split the reward up among the participants.  If the miner tries to "steal" the reward, then they forfeit their deposit (which will be split up among the pool participants).
You don't even need that. In order for the individual miner to prove the pool it is doing work, it may require it to proof that it is doing work in a form that each block it produced contain transaction to pay to the pool manager. If the miner tries to cheat the pool, it will not get the pool rewards.
itamarhason
Newbie
*
Offline Offline

Activity: 9


View Profile
June 16, 2014, 05:12:45 AM
 #20

I don't understand how your proposal would prevent pool mining.

The pool creates the header, puts their address in there, and sign it.  Then they send it out to the "miners" to search for the hash.

When a "miner" solves the block, the pool broadcasts the block and gets paid.  Then in a later block, they split up the payment among all the participants.

What am I missing?  Is there something implied in your description that I didn't notice?

You're missing the fact that the nonce and the merkle root are part of the header, so the pool manager cannot sign the header without counting over all nonces himself.

Ah, I see what you are suggesting now.  Unfortunately, it wouldn't stop pooled mining at all.  All it would do is create a financial barrier to entry for small miners.

All the pool needs to do is:

  • Require a deposit from every participating miner that is at least as large as the largest blockreward
  • Issue each miner their own private key that the pool knows about.

Then the pool can monitor the blockchain to see if any coinbase transactions go to any of the addresses that were issued by the pool.  If so, the miner will be expected to allow the pool to split the reward up among the participants.  If the miner tries to "steal" the reward, then they forfeit their deposit (which will be split up among the pool participants).
You don't even need that. In order for the individual miner to prove the pool it is doing work, it may require it to proof that it is doing work in a form that each block it produced contain transaction to pay to the pool manager. If the miner tries to cheat the pool, it will not get the pool rewards.
Thanks for the comment - I think you're right. The pool manager can send the merkle root to the miners, and the miners shall prove they're doing work by finding a less difficult block (using their private key) whose header include the given Merkle Root. In the Merkle Tree corresponding to the given Merkle Root, there should be a transaction from another address of the miner to the pool manager (or all pool participants). This way, the pool manager can verfiy the miners are doing their work, and when one of them finds a block - he gets the full reward, and pays from another address to the pool.
Pages: [1] 2 »  All
  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!