Topic: 51% can be prevented so long as all nodes agree. (Read 2820 times)
Well, if the pools do not naturally even out in popularity (with that I mean no pool has more than 30% hashrate, and the second largest pool is about as large as the largest pool) than we could try to figure out a way to punish pools that are too large for their own good.
Imagine managing a miner with 80%, competing with 3 miners with 5% each, the last 5% spread around. To keep that market share, you have to be on top of everything. Getting the best new hardware, keeping a stable power supply, keeping the personell, be alert around the clock and around the year. Even at 80%, you can be only slightly more profitable than the next miner. A slight misstep, and you loose some blocks, eroding your profit, transforming it to a loss. A chance for another miner to have a go.
If you have 80% the rest depends on your goodwill to get any profits at all. You can just ignore the other blocks and take 100% of the profits, or delay the release of your blocks until somebody else finds one and then immediately override it by sending out two blocks. Doing this you would also be the one who decides how much it would cost to use the Bitcoin network.
If you are in that position, and use it to try to launch a stealth chain fork to your advantage, you risk losing, with high probability, your investment which at this point will be hundreds of millions of USD2014.
Imagine managing a miner with 80%, competing with 3 miners with 5% each, the last 5% spread around. To keep that market share, you have to be on top of everything. Getting the best new hardware, keeping a stable power supply, keeping the personell, be alert around the clock and around the year. Even at 80%, you can be only slightly more profitable than the next miner. A slight misstep, and you loose some blocks, eroding your profit, transforming it to a loss. A chance for another miner to have a go.
If you have 80% the rest depends on your goodwill to get any profits at all. You can just ignore the other blocks and take 100% of the profits, or delay the release of your blocks until somebody else finds one and then immediately override it by sending out two blocks. Doing this you would also be the one who decides how much it would cost to use the Bitcoin network.
Why not change to just one giant pool, sort of. In a pool, the coinbase transaction has the pool's address, not the miner's address. That could be changed to output to a collective list of all miners addresses.
Congratulations, you re-invented P2Pool. Eligius does the same thing: paying the miners directly instead of paying everything to the Pool's wallet (Both examples still use the traditional approach for alt-coins).
There is a bit of a definition issue though: miners generate blocks, while hashers generate proof-of-work. We are in this crisis mainly because those two functions have been separated.
While I understand setting up merged mining may be costly and a lot of work; hashers need to understand that they have to monitor the entities they are lending their hash-power to.
LOL Except mine would be forced on you.
How? A pool could connect to p2pool (or your p2pool re-invention) and miners could choose to connect to that pool instead. PoW is by design a nearly perfectly parallel problem.
One thousand miners can appear to be a single node in any system you devise. There are some systems proposed but they involve zero knowledge proofs which prevent the (secure) sharing of mining information
You know what? I just want the devs of this cute little beta software to find a solution to a problem that I have been reading about for three and a half years. If it can't be solved then tell us there is no reasonable solution to fixing this problem.
Gavin Andresen almost did that when he said, "Bitcoin is still a work in progress, and you should only risk time or money on it that you can afford to lose." And "A malicious 51% attacker could prevent transactions or new blocks from other people getting accepted, effectively stopping all payments and shutting down the network.”
Since I'm not really fond of losing any money he is telling me to cash out. Since this happened years ago with Deepbit, it's still happening now with Ghash.IO, the devs aren't fixing it, the former lead dev says Bitcoin is very risky, I have to assume I'm being told not to buy any more Bitcoin.
p2pool isn't a solution because greed is forcing people to gravitate toward Ghash.IO. If I won the lotto, decided that I was pissed at all those bitcoiners and wanted to hurt them I might just start a 0 fee pool to capture most of the network and then shut it down. If I was a government and believed that this little charade has gone on long enough I might start a 0 fee pool to capture most of the network and then shut it down. My solution is stupid and I know it. At least I'm attempting to come up with something but I don't have any mandate to find a fix. What are the devs doing about it?
Why not change to just one giant pool, sort of. In a pool, the coinbase transaction has the pool's address, not the miner's address. That could be changed to output to a collective list of all miners addresses.
Congratulations, you re-invented P2Pool. Eligius does the same thing: paying the miners directly instead of paying everything to the Pool's wallet (Both examples still use the traditional approach for alt-coins).
There is a bit of a definition issue though: miners generate blocks, while hashers generate proof-of-work. We are in this crisis mainly because those two functions have been separated.
While I understand setting up merged mining may be costly and a lot of work; hashers need to understand that they have to monitor the entities they are lending their hash-power to.
LOL Except mine would be forced on you.
How? A pool could connect to p2pool (or your p2pool re-invention) and miners could choose to connect to that pool instead. PoW is by design a nearly perfectly parallel problem.
One thousand miners can appear to be a single node in any system you devise. There are some systems proposed but they involve zero knowledge proofs which prevent the (secure) sharing of mining information
Why not change to just one giant pool, sort of. In a pool, the coinbase transaction has the pool's address, not the miner's address. That could be changed to output to a collective list of all miners addresses.
Congratulations, you re-invented P2Pool. Eligius does the same thing: paying the miners directly instead of paying everything to the Pool's wallet (Both examples still use the traditional approach for alt-coins).
There is a bit of a definition issue though: miners generate blocks, while hashers generate proof-of-work. We are in this crisis mainly because those two functions have been separated.
While I understand setting up merged mining may be costly and a lot of work; hashers need to understand that they have to monitor the entities they are lending their hash-power to.
LOL Except mine would be forced on you.
Why not change to just one giant pool, sort of. In a pool, the coinbase transaction has the pool's address, not the miner's address. That could be changed to output to a collective list of all miners addresses.
Congratulations, you re-invented P2Pool. Eligius does the same thing: paying the miners directly instead of paying everything to the Pool's wallet (Both examples still use the traditional approach for alt-coins).
There is a bit of a definition issue though: miners generate blocks, while hashers generate proof-of-work. We are in this crisis mainly because those two functions have been separated.
While I understand setting up merged mining may be costly and a lot of work; hashers need to understand that they have to monitor the entities they are lending their hash-power to.
- snip -
What if every participating miner in the world got a proportional share of every block mined?
- snip -
What if every participating miner in the world got a proportional share of every block mined?
- snip -
You won't know who is mining.
- snip -
- snip -
I'm confused.
If nobody knows who is mining, then how does the system know what proportion to send to everyone, and who to send it to?
How did Bitcoin QT know who to send the reward to back in the old days? You enter your address. The only difference would be tracking hashrate. If QT sent the hashrate of each client to the network you would know how much each installation of QT was generating. Every node in the network would have a copy of the template and the file size of the software. At each payout it could run a check on the software to verify a random string then check its own file size and verify with the network. I said this was insane. It would be a complete overhaul of the system and require everyone to update their client at once. It's much easier to leave everything alone then to make changes, which is probably why nothing is changing. Well, except for all the competing altcoins that are being developed daily. Eventually someone will come up with a really great idea for a superior coin that fixes all of the current problems. I haven't seen it yet but it could be out there already waiting to take over.
Ok screw this. I have too much "trust" in human intelect. I should have known that barely anyone will read my post with at least half brain turned on, so here it is again, stupid proof and changed so no "trust" is involved:
Well this idea can be extended. Add in some kind of "proirity" level to nodes that nodes gain working over period of time. Priority would be assigned by whole network which is basic idea of BTC....things being decided by whole newtork.
New nodes would have low priority level which would have more restrictions (they could submit less blocks).
Higher priority level nodes would have less restrictions (they could submit more blocks than low priority nodes).
Priority is gained by submiting blocks over period of time. That would disable switching form ip to ip. How?
Her's an example.
(numbers are just figurative)
Pool A = large pool that submits 50 blocks per hour
Poll B = new, small pool that just started working and is submiting 5 block per hour
Pool A has high priority level and can submit up to 100 blocks per hour
Pool A starts growing and gets to 101 blck per hour and starts loosing BTC. They change IP after 100th block is submited to enable themselves to submit that 101th block and they become low priority pool.
Now pool A can submit only 10 blocks per hour and gain 1 extra block every day. While Pool B which is still on same IP is going great, growing slowly and gaining proiroty.
What basicly happened, Pool A shot itself in the foot and is loosing ALOT of BTC because they tried to cheat the system, while new honest pool is growing steady.
Is it now much clearer?
Well this idea can be extended. Add in some kind of "proirity" level to nodes that nodes gain working over period of time. Priority would be assigned by whole network which is basic idea of BTC....things being decided by whole newtork.
New nodes would have low priority level which would have more restrictions (they could submit less blocks).
Higher priority level nodes would have less restrictions (they could submit more blocks than low priority nodes).
Priority is gained by submiting blocks over period of time. That would disable switching form ip to ip. How?
Her's an example.
(numbers are just figurative)
Pool A = large pool that submits 50 blocks per hour
Poll B = new, small pool that just started working and is submiting 5 block per hour
Pool A has high priority level and can submit up to 100 blocks per hour
Pool A starts growing and gets to 101 blck per hour and starts loosing BTC. They change IP after 100th block is submited to enable themselves to submit that 101th block and they become low priority pool.
Now pool A can submit only 10 blocks per hour and gain 1 extra block every day. While Pool B which is still on same IP is going great, growing slowly and gaining proiroty.
What basicly happened, Pool A shot itself in the foot and is loosing ALOT of BTC because they tried to cheat the system, while new honest pool is growing steady.
Is it now much clearer?
Bitcoin has only one connection to the real world: the timestamp used to regulate the block rate. Everything else is concepts. We do not want to invent new references to the real world. We want it to float between peoples minds.
It is not necessary to worry about concentration in mining. Firstly, it is only the pools that are now concentrated, the actual miners are still well distributed. Even if also the miners should merge into a near monopoly, it is not a problem. Study monopolies in the free market as analyzed by austrian economics. Monopolies are a problem only in the presence of force in violation of human rights. Heck, you can ask Henry Ford.
Imagine managing a miner with 80%, competing with 3 miners with 5% each, the last 5% spread around. To keep that market share, you have to be on top of everything. Getting the best new hardware, keeping a stable power supply, keeping the personell, be alert around the clock and around the year. Even at 80%, you can be only slightly more profitable than the next miner. A slight misstep, and you loose some blocks, eroding your profit, transforming it to a loss. A chance for another miner to have a go.
- snip -
What if every participating miner in the world got a proportional share of every block mined?
- snip -
What if every participating miner in the world got a proportional share of every block mined?
- snip -
You won't know who is mining.
- snip -
- snip -
I'm confused.
If nobody knows who is mining, then how does the system know what proportion to send to everyone, and who to send it to?
I know this is insane.
And impossible to enforce.
How will you know who is mining? How will you know if anyone is using a different mining software?
You won't know who is mining. You'll only know that there is no control over the network. What could you do to ensure that proprietary software isn't being used? I don't know. Maybe have the node run a verify on the client at each payout like a random code filter check or possibly a call to verify random code strings against a template.
Why not change to just one giant pool, sort of.
What about making an altcoin as a prototype, in order to test the viability?
I know this is insane.
And impossible to enforce.
How will you know who is mining? How will you know if anyone is using a different mining software?
Why not change to just one giant pool, sort of. In a pool, the coinbase transaction has the pool's address, not the miner's address. That could be changed to output to a collective list of all miners addresses. If the individual miner submits a block the reward goes to the pool and the pool pays the miner based on what ever reward system criteria is set. Pools or solo miners work against each other to find the block and get the coinbase transaction and the leftover from the other transactions (the fee). What if every participating miner in the world got a proportional share of every block mined? No more pools would be allowed at all. The now defunct miner in Bitcoin QT could be reinstated and that would be the only allowed mining software. If you're not running a full node you can't mine. I know this is insane.
Ok screw this. I have too much "trust" in human intelect. I should have known that barely anyone will read my post with at least half brain turned on, so here it is again, stupid proof and changed so no "trust" is involved:
Well this idea can be extended. Add in some kind of "proirity" level to nodes that nodes gain working over period of time. Priority would be assigned by whole network which is basic idea of BTC....things being decided by whole newtork.
New nodes would have low priority level which would have more restrictions (they could submit less blocks).
Higher priority level nodes would have less restrictions (they could submit more blocks than low priority nodes).
Priority is gained by submiting blocks over period of time. That would disable switching form ip to ip. How?
Her's an example.
(numbers are just figurative)
Pool A = large pool that submits 50 blocks per hour
Poll B = new, small pool that just started working and is submiting 5 block per hour
Pool A has high priority level and can submit up to 100 blocks per hour
Pool A starts growing and gets to 101 blck per hour and starts loosing BTC. They change IP after 100th block is submited to enable themselves to submit that 101th block and they become low priority pool.
Now pool A can submit only 10 blocks per hour and gain 1 extra block every day. While Pool B which is still on same IP is going great, growing slowly and gaining proiroty.
What basicly happened, Pool A shot itself in the foot and is loosing ALOT of BTC because they tried to cheat the system, while new honest pool is growing steady.
Is it now much clearer?
Well this idea can be extended. Add in some kind of "proirity" level to nodes that nodes gain working over period of time. Priority would be assigned by whole network which is basic idea of BTC....things being decided by whole newtork.
New nodes would have low priority level which would have more restrictions (they could submit less blocks).
Higher priority level nodes would have less restrictions (they could submit more blocks than low priority nodes).
Priority is gained by submiting blocks over period of time. That would disable switching form ip to ip. How?
Her's an example.
(numbers are just figurative)
Pool A = large pool that submits 50 blocks per hour
Poll B = new, small pool that just started working and is submiting 5 block per hour
Pool A has high priority level and can submit up to 100 blocks per hour
Pool A starts growing and gets to 101 blck per hour and starts loosing BTC. They change IP after 100th block is submited to enable themselves to submit that 101th block and they become low priority pool.
Now pool A can submit only 10 blocks per hour and gain 1 extra block every day. While Pool B which is still on same IP is going great, growing slowly and gaining proiroty.
What basicly happened, Pool A shot itself in the foot and is loosing ALOT of BTC because they tried to cheat the system, while new honest pool is growing steady.
Is it now much clearer?
Interesting idea but I don't think it would work for two reasons. It doesn't seem to scale very well. When volume grows block times will need to increase and your priority system would be a bottleneck. Also, network time is based on the median time of a node's peers which is sent in the version message when peers connect. The network time is used to validate new blocks. Nodes already reject any block timestamp that is greater than 2 hours from the current network time. Currently there is no incentive to develop a method to spoof network time. You would be creating a reason to do it. If it could even be implemented in the current code, I can see a system like this really screwing something up badly.
The solution is simple: break up large pools. Anything short of that is no longer using "proof-of-work". If "Proof-of-Work" is not being used to secure the block-chain, there is no point in having it.
Break up?
First question would be "how"?
Perhaps my choice of words was poor. If the pool(s) you have your miner pointed at exceeds 25% of the hash-power, consider finding a replacement.
I you are a pool operator with more than 25% of the hash-power, consider raising fees.
The solution is simple: break up large pools. Anything short of that is no longer using "proof-of-work". If "Proof-of-Work" is not being used to secure the block-chain, there is no point in having it.
Break up?
First question would be "how"?
And let's imagine you do somehow break em. What would stop GHASH from opening "GHASH2". One pool could have 30% and second one could have 30%. If GHASH want's to attack all they need to do is change code on both pools and they are as good as one single 60% pool.
So basicly, breaking em apart doesnt do much.
Somehow forcing p2p only pool could be solution maybe?
Wont write again in this topic untill i read little bit more about subject...today was real eye opener...i tought problem was at place A when in reality it's on place B.
But i still think that it's not problem of pools, it's problem of protocol that needs to change to effectivly stop this kind of behviour, just like it stops creating coins once all coins are mined etc.
The solution is simple: break up large pools. Anything short of that is no longer using "proof-of-work". If "Proof-of-Work" is not being used to secure the block-chain, there is no point in having it.
The solution IMO, is to add in a third layer. You have the miner, the pool - and then you have the block template providers. BY connecting the block tempate providers to the miners you can verify that the pool isn't making their own blocks. Pools can then request blocks round-robin fashion from the block template providers, making sure that no one block template provider can get more than one block in succession. Pools then can have whatever hashrate they want - and if they stop using the blocktemplate providers - the mining software will disconnect from them.
Read here and please comment: https://bitcointalksearch.org/topic/a-solution-to-centralised-pool-ownership-of-the-blockchain-656008
Read here and please comment: https://bitcointalksearch.org/topic/a-solution-to-centralised-pool-ownership-of-the-blockchain-656008
There's a bit of a dilemma in all arguments involving any sort of IP address. Bitcoin is designed so that it can function over any sort of (untrusted) communication medium. Blocks get from point A to B, verified at B, yada yada. This could be by HSMM (which identifies by callsign), satellite, even carrier pigeon in the most hypothetical of situations.
Jump to: