hi
i noticed you deleted you telegram account recently
why?
i am still waiting the letter and when it arrives how can i contact you?
please contact me at @AmbrogioOrfeu on telegram
Topic: Decentralized Mining & Preventing Centralization in Pools (Read 4774 times)
I have designed a new Proof-of-Stake system that requires no mining at all and therefore entirely prevents centralization of mining leaving only 51% ownership of the money supply as a means of attack.
http://bitsharestalk.org/index.php?topic=1138.msg11955#msg11955
http://bitsharestalk.org/index.php?topic=1138.msg11955#msg11955
https://en.bitcoin.it/wiki/P2Pool#Payout_logic
Incorrect. The miner can still be paid for the shares he generated which were not a block solution, because another peer might generate the block solution after. Thus the share withholding miner can parasite income off the pool while robbing the pool of his major contribution to the revenue. So this brings revenue to the miner, while parasiting on the pool. If enough shares are from attackers, this destroys the economics of the honest miners in the pool and probably destroys the pool.
So if you owned a centralized pool, it would probably be in your interest to attack all the P2Pools.
Whereas centralized pools could (in a redesigned block chain) implement Meni Rosenfeld's oblivious shares to thwart the share withholding attack.
So as I wrote upthread, P2Pool is not a sustainable nor reliable solution.
Quote
A miner with the aim to harm others could withhold the block, thereby preventing anybody from getting paid.
Incorrect. The miner can still be paid for the shares he generated which were not a block solution, because another peer might generate the block solution after. Thus the share withholding miner can parasite income off the pool while robbing the pool of his major contribution to the revenue. So this brings revenue to the miner, while parasiting on the pool. If enough shares are from attackers, this destroys the economics of the honest miners in the pool and probably destroys the pool.
So if you owned a centralized pool, it would probably be in your interest to attack all the P2Pools.
Whereas centralized pools could (in a redesigned block chain) implement Meni Rosenfeld's oblivious shares to thwart the share withholding attack.
So as I wrote upthread, P2Pool is not a sustainable nor reliable solution.
P2Pool already solved (almost?) all of these problems. Why don't you just use it? It's really great... what does it miss?
It is a great project and I advice everyone to use it.
It is a great project and I advice everyone to use it.
I thinking the pool operator (server) does so little relative to work of the pool miners that it doesn't need to charge a very high fee. Thus there isn't much ability (incentive for pool miners) to uncut competitors based on fee.
So there just needs to be a slightest incentive to encourage pool miners to seek out another pool as a pool grows large. This will encourage a poliferation of pools.
How do pool miners know that a pool server isn't cheating them by paying some of the earnings to themselves pretending to be a pool miner?
Go down that line of thought and you will discover what I am thinking.
So there just needs to be a slightest incentive to encourage pool miners to seek out another pool as a pool grows large. This will encourage a poliferation of pools.
How do pool miners know that a pool server isn't cheating them by paying some of the earnings to themselves pretending to be a pool miner?
Go down that line of thought and you will discover what I am thinking.
The only way you can prove a pool isn't cheating is by estimating the hash rate of the pool and comparing it to the number of blocks found. Unfortunately, you could probably still skim a couple of a percent this way.
Modern protocols (GBT & Stratum) both have the full coinbase transaction visible to the miners, meaning you can verify that the block being built will be paid to a certain address or has a certain message encoded in the block that identifies the pool. This allows you to audit if the pool is trying to skim blocks if certain users start seeing work without a coinbase message that identifies the pool. In the case of BTC Guild, it's both, they always pay to the same address and always include "Mined by BTC Guild" in the coinbase message.
It's not no-trust, but all it would take is a few % of users monitoring this to determine if a pool was trying to skim blocks by sending a certain % of work that doesn't include identifying marks.
How could anything less than 100% of the pool miners know if some of the coinbase transactions were to addresses not owned by pool miners who contributed shares?
Since you can never know if you are the 100% (because mining pool shares* are not recorded in the block chain), thus seems to me there is no way to verify if there is skimming or not, as bytemaster and I wrote.
*For those who don't know the terminology, a pool share is a proof-of-work hash below some threshold that is easier than the current network difficulty. It might also be a block solution.
Why don't you just use P2Pool? Is there any reason?
I was waiting for bytemaster to answer because I wanted to know his thoughts. Seems to me that you have no way to stop the Share Withholding Attack since it is decentralized. And every peer has to run more of a full client if I am not mistake. And there is a lot more overhead I believe. And perhaps also much less resistance against denial-of-service flooding. Frankly I didn't analyze for long enough to be very sure of my initial intuition which is to stay away from it.
I know it is generally impossible to enforce reputation on a 100% decentralized system. So I am intuitively skeptical of P2Pool.
Even the largest pools now represent less than 30% of the actual network hash rate.
30% sounds an extremely alarming rate to me. It's not a radical stretch of imagination to envision them getting the extra 21% power required.
I would feel much more comfortable with the strongest miner having, say, 5% of the hashpower.
Couldn't the pool validate your shares without knowing the full merkle tree? So the miner provides the PoW via the block header, plus a merkle branch which proves that the pool is paid in the coinbase transaction.
To submit a block, the pool has to have the entire raw block worth of data. So if the block is 500KB, the miner would have to upload the full 500KB being used to build the block to the pool, plus a bit of overhead for the JSON markup, assuming the miner was actually involved in building the block.
There are *some* ways to shrink this, where the pool dictates what transactions can be selected, with a tx-id integer (instead of full hash) so the miner could just upload a list of the transactions they included in the block, or a list of ones they excluded. But once the miner is introducing their own transactions from their local node that the pool wasn't originally aware of, this is no longer possible, since the pool needs to know the raw transaction.
Reading this, only understanding 30% of it 
Sincere question, maybe it was covered here but I couldn't understand it. What is the real world chance that one day in the close future (next 12 months say), somebody will do something like this 51% attack thing, or some fault will be discovered, that creates big problems for bitcoin? Is it a high risk of happening?
Sincere question, maybe it was covered here but I couldn't understand it. What is the real world chance that one day in the close future (next 12 months say), somebody will do something like this 51% attack thing, or some fault will be discovered, that creates big problems for bitcoin? Is it a high risk of happening?
A 51% is extremely unlikely. Even the largest pools now represent less than 30% of the actual network hash rate. Luck spikes make their 24-hour block percentage above 30%, but this can't be predicted and is not reliable. The 51% attack threat is having enough power to guarantee eventually you will make the longest chain as long as you keep trying. If the largest pools were DDoS'd, most of that hash rate filters down to backup pools, so the argument that you just DDoS the largest pools to make a 51% attack easier is not quite accurate.
Reading this, only understanding 30% of it
Sincere question, maybe it was covered here but I couldn't understand it. What is the real world chance that one day in the close future (next 12 months say), somebody will do something like this 51% attack thing, or some fault will be discovered, that creates big problems for bitcoin? Is it a high risk of happening?
Sincere question, maybe it was covered here but I couldn't understand it. What is the real world chance that one day in the close future (next 12 months say), somebody will do something like this 51% attack thing, or some fault will be discovered, that creates big problems for bitcoin? Is it a high risk of happening?
How about people start adopting this new mining protocol? https://en.bitcoin.it/wiki/Getblocktemplate
This allows the miner to build the block rather than the pool, so the miner can implement their own policy as to what goes into the block. This means that pool operators with a large share of hashing power cannot abuse that power to do things like exclude certain transactions from blocks, or have unreasonably high fee thresholds. The content of the block would be based on the transaction policies of the person who happened to mine it, which would have a lot of variation since each block would likely come from a different miner.
This also means that the miner who first finds the block can broadcast the block, which makes it impossible for the pool to do "selfish mining".
This allows the miner to build the block rather than the pool, so the miner can implement their own policy as to what goes into the block. This means that pool operators with a large share of hashing power cannot abuse that power to do things like exclude certain transactions from blocks, or have unreasonably high fee thresholds. The content of the block would be based on the transaction policies of the person who happened to mine it, which would have a lot of variation since each block would likely come from a different miner.
This also means that the miner who first finds the block can broadcast the block, which makes it impossible for the pool to do "selfish mining".
No pool at this time actually supports miners picking and choosing transactions with GBT. They use GBT the same way pools use stratum. They give you the block contents, you mine it. You have no say.
There is a whole new level of complication added to the Miner<->Pool dynamic when it comes to letting miners pick transactions. Specifically, the pool needs to know which transactions you're including every time you send in shares so it can validate your share results are correct. This is a MASSIVE amount of bandwidth that would be required when looking at even a 10% fraction of the pool opting for it, not to mention a large increase in stale rates for most miners since they would have to upload 300-500KB to the pool to tell them the block contents. Hell, GBT is already a complete major bandwidth hog compared to Stratum because it has to send miners the entire block contents when it pushes work instead of just a merklebranch.
Couldn't the pool validate your shares without knowing the full merkle tree? So the miner provides the PoW via the block header, plus a merkle branch which proves that the pool is paid in the coinbase transaction.
I thinking the pool operator (server) does so little relative to work of the pool miners that it doesn't need to charge a very high fee. Thus there isn't much ability (incentive for pool miners) to uncut competitors based on fee.
So there just needs to be a slightest incentive to encourage pool miners to seek out another pool as a pool grows large. This will encourage a poliferation of pools.
How do pool miners know that a pool server isn't cheating them by paying some of the earnings to themselves pretending to be a pool miner?
Go down that line of thought and you will discover what I am thinking.
So there just needs to be a slightest incentive to encourage pool miners to seek out another pool as a pool grows large. This will encourage a poliferation of pools.
How do pool miners know that a pool server isn't cheating them by paying some of the earnings to themselves pretending to be a pool miner?
Go down that line of thought and you will discover what I am thinking.
The only way you can prove a pool isn't cheating is by estimating the hash rate of the pool and comparing it to the number of blocks found. Unfortunately, you could probably still skim a couple of a percent this way.
Modern protocols (GBT & Stratum) both have the full coinbase transaction visible to the miners, meaning you can verify that the block being built will be paid to a certain address or has a certain message encoded in the block that identifies the pool. This allows you to audit if the pool is trying to skim blocks if certain users start seeing work without a coinbase message that identifies the pool. In the case of BTC Guild, it's both, they always pay to the same address and always include "Mined by BTC Guild" in the coinbase message.
It's not no-trust, but all it would take is a few % of users monitoring this to determine if a pool was trying to skim blocks by sending a certain % of work that doesn't include identifying marks.
Why don't you just use P2Pool? Is there any reason?
I thinking the pool operator (server) does so little relative to work of the pool miners that it doesn't need to charge a very high fee. Thus there isn't much ability (incentive for pool miners) to uncut competitors based on fee.
So there just needs to be a slightest incentive to encourage pool miners to seek out another pool as a pool grows large. This will encourage a poliferation of pools.
How do pool miners know that a pool server isn't cheating them by paying some of the earnings to themselves pretending to be a pool miner?
Go down that line of thought and you will discover what I am thinking.
So there just needs to be a slightest incentive to encourage pool miners to seek out another pool as a pool grows large. This will encourage a poliferation of pools.
How do pool miners know that a pool server isn't cheating them by paying some of the earnings to themselves pretending to be a pool miner?
Go down that line of thought and you will discover what I am thinking.
The only way you can prove a pool isn't cheating is by estimating the hash rate of the pool and comparing it to the number of blocks found. Unfortunately, you could probably still skim a couple of a percent this way.
I am thinking the pool operator (server) does so little relative to work of the pool miners that it doesn't need to charge a very high fee. Thus there isn't much ability (incentive for pool miners) to undercut competitors based on fee.
So there just needs to be a slightest incentive to encourage pool miners to seek out another pool as a pool grows large. This will encourage a proliferation of pools.
How do pool miners know that a pool server isn't cheating them by paying some of the earnings to themselves pretending to be a pool miner?
Go down that line of thought and you will discover what I am thinking.
So there just needs to be a slightest incentive to encourage pool miners to seek out another pool as a pool grows large. This will encourage a proliferation of pools.
How do pool miners know that a pool server isn't cheating them by paying some of the earnings to themselves pretending to be a pool miner?
Go down that line of thought and you will discover what I am thinking.
Talk about care of coin, little guy, profiteering, same share for everyone.... reminds me of communism.
Would you care so much or spend so much of energy for coin with zero value?
Would you care so much or spend so much of energy for coin with zero value?
I don't care about same share for everyone, I care about decentralizing control of transaction selection and increasing hash power relative to price paid (inflation/etc).
Talk about care of coin, little guy, profiteering, same share for everyone.... reminds me of communism.
Would you care so much or spend so much of energy for coin with zero value?
Would you care so much or spend so much of energy for coin with zero value?
I postulated that selfish-mining can be easily defeated by spying on the pools. Bytemaster, I also mentioned your proposed solution there and linked back to this thread.
No pool at this time actually supports miners picking and choosing transactions with GBT. They use GBT the same way pools use stratum. They give you the block contents, you mine it. You have no say.
There is a whole new level of complication added to the Miner<->Pool dynamic when it comes to letting miners pick transactions. Specifically, the pool needs to know which transactions you're including every time you send in shares so it can validate your share results are correct. This is a MASSIVE amount of bandwidth that would be required when looking at even a 10% fraction of the pool opting for it, not to mention a large increase in stale rates for most miners since they would have to upload 300-500KB to the pool to tell them the block contents. Hell, GBT is already a complete major bandwidth hog compared to Stratum because it has to send miners the entire block contents when it pushes work instead of just a merklebranch.
Also there is the problem when miners don't agree about which transactions should be placed in the block, i.e. a Tragedy of the Commons outcome.
It seems to me that competition will keep the pools reasonable in size if the transaction fee is cast in stone. Because as transaction volume rises, the cost of subsidizing a pool to gain market share thus increases. However, if income from transactions is significant, then the network is vulnerable to my Transactions Withholding Attack.
If we could limit the income of the pool operator and insure all the rest goes to the pool's miners, then we could surely limit the size of pools.
How about people start adopting this new mining protocol? https://en.bitcoin.it/wiki/Getblocktemplate
This allows the miner to build the block rather than the pool, so the miner can implement their own policy as to what goes into the block. This means that pool operators with a large share of hashing power cannot abuse that power to do things like exclude certain transactions from blocks, or have unreasonably high fee thresholds. The content of the block would be based on the transaction policies of the person who happened to mine it, which would have a lot of variation since each block would likely come from a different miner.
This also means that the miner who first finds the block can broadcast the block, which makes it impossible for the pool to do "selfish mining".
This allows the miner to build the block rather than the pool, so the miner can implement their own policy as to what goes into the block. This means that pool operators with a large share of hashing power cannot abuse that power to do things like exclude certain transactions from blocks, or have unreasonably high fee thresholds. The content of the block would be based on the transaction policies of the person who happened to mine it, which would have a lot of variation since each block would likely come from a different miner.
This also means that the miner who first finds the block can broadcast the block, which makes it impossible for the pool to do "selfish mining".
No pool at this time actually supports miners picking and choosing transactions with GBT. They use GBT the same way pools use stratum. They give you the block contents, you mine it. You have no say.
There is a whole new level of complication added to the Miner<->Pool dynamic when it comes to letting miners pick transactions. Specifically, the pool needs to know which transactions you're including every time you send in shares so it can validate your share results are correct. This is a MASSIVE amount of bandwidth that would be required when looking at even a 10% fraction of the pool opting for it, not to mention a large increase in stale rates for most miners since they would have to upload 300-500KB to the pool to tell them the block contents. Hell, GBT is already a complete major bandwidth hog compared to Stratum because it has to send miners the entire block contents when it pushes work instead of just a merklebranch.
Also there is the problem when miners don't agree about which transactions should be placed in the block, i.e. a Tragedy of the Commons outcome.
It seems to me that competition will keep the pools reasonable in size if the transaction fee is cast in stone. Because as transaction volume rises, the cost of subsidizing a pool to gain market share thus increases. However, if income from transactions is significant, then the network is vulnerable to my Transactions Withholding Attack.
If we could limit the income of the pool operator and insure all the rest goes to the pool's miners, then we could surely limit the size of pools.
How about people start adopting this new mining protocol? https://en.bitcoin.it/wiki/Getblocktemplate
This allows the miner to build the block rather than the pool, so the miner can implement their own policy as to what goes into the block. This means that pool operators with a large share of hashing power cannot abuse that power to do things like exclude certain transactions from blocks, or have unreasonably high fee thresholds. The content of the block would be based on the transaction policies of the person who happened to mine it, which would have a lot of variation since each block would likely come from a different miner.
This also means that the miner who first finds the block can broadcast the block, which makes it impossible for the pool to do "selfish mining".
This allows the miner to build the block rather than the pool, so the miner can implement their own policy as to what goes into the block. This means that pool operators with a large share of hashing power cannot abuse that power to do things like exclude certain transactions from blocks, or have unreasonably high fee thresholds. The content of the block would be based on the transaction policies of the person who happened to mine it, which would have a lot of variation since each block would likely come from a different miner.
This also means that the miner who first finds the block can broadcast the block, which makes it impossible for the pool to do "selfish mining".
No pool at this time actually supports miners picking and choosing transactions with GBT. They use GBT the same way pools use stratum. They give you the block contents, you mine it. You have no say.
There is a whole new level of complication added to the Miner<->Pool dynamic when it comes to letting miners pick transactions. Specifically, the pool needs to know which transactions you're including every time you send in shares so it can validate your share results are correct. This is a MASSIVE amount of bandwidth that would be required when looking at even a 10% fraction of the pool opting for it, not to mention a large increase in stale rates for most miners since they would have to upload 300-500KB to the pool to tell them the block contents. Hell, GBT is already a complete major bandwidth hog compared to Stratum because it has to send miners the entire block contents when it pushes work instead of just a merklebranch.
How about people start adopting this new mining protocol? https://en.bitcoin.it/wiki/Getblocktemplate
This allows the miner to build the block rather than the pool, so the miner can implement their own policy as to what goes into the block. This means that pool operators with a large share of hashing power cannot abuse that power to do things like exclude certain transactions from blocks, or have unreasonably high fee thresholds. The content of the block would be based on the transaction policies of the person who happened to mine it, which would have a lot of variation since each block would likely come from a different miner.
This also means that the miner who first finds the block can broadcast the block, which makes it impossible for the pool to do "selfish mining".
This allows the miner to build the block rather than the pool, so the miner can implement their own policy as to what goes into the block. This means that pool operators with a large share of hashing power cannot abuse that power to do things like exclude certain transactions from blocks, or have unreasonably high fee thresholds. The content of the block would be based on the transaction policies of the person who happened to mine it, which would have a lot of variation since each block would likely come from a different miner.
This also means that the miner who first finds the block can broadcast the block, which makes it impossible for the pool to do "selfish mining".
This works well for people running 'full nodes' but it seems most 'miners' are using specialized light-weight clients.
How about people start adopting this new mining protocol? https://en.bitcoin.it/wiki/Getblocktemplate
This allows the miner to build the block rather than the pool, so the miner can implement their own policy as to what goes into the block. This means that pool operators with a large share of hashing power cannot abuse that power to do things like exclude certain transactions from blocks, or have unreasonably high fee thresholds. The content of the block would be based on the transaction policies of the person who happened to mine it, which would have a lot of variation since each block would likely come from a different miner.
This also means that the miner who first finds the block can broadcast the block, which makes it impossible for the pool to do "selfish mining".
This allows the miner to build the block rather than the pool, so the miner can implement their own policy as to what goes into the block. This means that pool operators with a large share of hashing power cannot abuse that power to do things like exclude certain transactions from blocks, or have unreasonably high fee thresholds. The content of the block would be based on the transaction policies of the person who happened to mine it, which would have a lot of variation since each block would likely come from a different miner.
This also means that the miner who first finds the block can broadcast the block, which makes it impossible for the pool to do "selfish mining".
interesting idea...
Jump to: