thoes with more Hashing power will still dominate the network
The word dominate very strongly suggests the race misunderstanding. If I have 1% and you have 20% you will mine 20x the amount of coin I do, you will also consume 20x more power and pay 20x more for hardware (assuming we are buying the same hardware). There is no "dominate", it's all linear. 
Topic: BTCGuild is a 51% attack risk (Read 4216 times)
I know its not a race. Nore have I ever said it was a race.
I just said that thoes with more Hashing power will still dominate the network. rather if its a pool or a single person.
I just said that thoes with more Hashing power will still dominate the network. rather if its a pool or a single person.
If everyone quit pool mining at the same time and went to solo mining there will still be people that will carry a big portion of the network and then could cause an attack that could hurt the network but on the other hand a person with only a couple of GH/s would not be making anything. Thus making them stop.
You appear to be under the "mining is a race" mode of misunderstanding. Pooling does not increase your earnings (typically it decreases them somewhat), it lowers your variance— meaning it makes your payments more stable. Mining is a linear process, and having more hash power doesn't increase your income except in proportion, no more.The possibilities available are also broader than "everybody on the biggest pool" vs "everybody solo", there are many ways to completely decentralize mining itself while retaining whatever kind of payment pooling you like. (See my comment to Eleuthria about having pools just handout coinbases, and miners return shares that include the pool's requested coinbase in order to get credited)
We could even have an outcome where 100% of the _payments_ were paying into a single pooling effort with no risk to the network consensus at all. (e.g. big payment poolers participate in a P2Pool like agreement to mine coinbases which pay proportionally to the last N shares in some sub-block payment sharechain, then distribute income according to whatever payment algorithm they choose as a function of work submitted to them by miners handing them compliant coinbases. Miners just mine honestly and use their preferred payment pooler's coinbase outputs).
They very well may be true however think of it like this. Everyone that is in a pool rather that be BTCGuild or someone else has the option to be there. We are not forced to be there. Well lets look at the word forced. Technally we kinda are due to the network. If everyone quit pool mining at the same time and went to solo mining there will still be people that will carry a big portion of the network and then could cause an attack that could hurt the network but on the other hand a person with only a couple of GH/s would not be making anything. Thus making them stop. And still left with the same issue. With BtcGuild as big as it is and we know that eleuthria is not wanting to cause harm it give the small fry or beginner still hope in the now hard to get in bitcoin mining game and still make something. And thus still be a learning experiance! 
These numbers are true, there is one thing to keep in mind: Any attempt to do so *is* visible to miners. The second a pool tries to start a fork and reverse a transaction, miners can see the prevblockhash on the pool no longer matches the main bitcoin network. While this isn't unusual in the case of an orphan race, the only time it has ever happened for more than 2 blocks in a row that I can recall was when we had a hardfork starting.
It's visible only in a purely abstract way. Deepbit was frequently "eating its own tail" due to running multiple bitcoin daemons which would end up on competing forks and then load balancing miners between them (if it doesn't do this anymore its only because it doesn't solve enough blocks).Not a single person in the world noticed this until Luke-Jr, bless his occasionally trolly heart, added code to BFGMiner to refuse to mine when a pool appeared to be forking itself. But not many people run that code.
Moreover, it's only a very partial solution: Say the network is on block A, you don't include the transaction you want to conflict in A. Then then another miner solves A and the network moves on to A+1 but you stay on A. Eventually you solve A'+1+1+1 ... and with some luck reverse the transaction. Miners never see any self-forking, and so the protection in BFGminer cannot help.
Performing the attack in this way simply constrains when you can start the attack (only right after another pool found a block), it does not reduce the success rate.
Quote
Additionally, an unsuccessful attempt would be completely apparent to miner's because their earnings would plummet [unless the pool continued to pay miners for the fork blocks]. Since BTC Guild's earnings can be audited down to the block hashes that generated payouts, this would be obviously false due to the blocks that were paid not existing on the blockchain.
A number of years ago your pool delivered earning of something like 40% of expectations for months. A number of people were convinced that you were a thief because of it (that something was subtly broken, or there was some witholding attack seems like a more likely explanation, in my view), but that hasn't inhibited you from having the largest pool by far.I cannot believe that many people would notice or care about a decline in revenue on the timescale of a single day or two.
Maybe they would. But thats a big maybe to stake the future of Bitcoin on, especially with people trying to open up new markets that allow them to take short positions. A substantial successful attack would dramatically undermine confidence in Bitcoin: The existence of major hashpower consolations already defeats the security assumptions, but its a theoretical weakness and until an attack happens many don't believe what incredibly shaky ground we are on here.
Quote
BTC Guild is gaining on % of the network again, and I've stated in the past I think this is something that will always happen. A zero-sum method of earning Bitcoins will always lead to natural monopolies as people prefer to get a steady income over a lottery.
Control over mining is orthogonal with pooling payments. There is no reason that a pool couldn't simply hand out coinbase transactions to miners and credit them for any remotely sane looking shares that includes the requested coinbase transaction. The pool would then only be a consolidation of miners payments and would have no risk for consolidating control of the blockchain consensus. Miners would become miners again, and not just people selling computing services for coin.
The risk that miners would intentionally have some junk transactions that get blocks orphaned would be strictly less than the block withholding risk which cannot be eliminated, as you could still ask miners to occasionally send whole blocks.
Had Satoshi though of this in 2010 I believe we would have a very different world today.
Gah. I'm sorry to invite the offtopic deflection, I should have seen it coming. The point remains that there is enough ambiguity in "luck" to drive a bus through. A less personal example: Virtually every block mined by 50BTC for the next ~month after P2SH was orphaned, it hardly lost any hashpower and it's now one of the largest pools.
The nature of pooling encourages an arms length relationship between the hashers and the Bitcoin network. It would be in their perfect-knowledge rational best interest to behave otherwise, but it turns out perfect knoweldge is kinda expensive.
I can produce case after case of hashers behaving poorly in this respect. Counting on it to preserve security against attacks which could be over in hours— e.g. by someone trying to cause a huge negative event to make a profit off shorting Bitcoin— is unwise.
The nature of pooling encourages an arms length relationship between the hashers and the Bitcoin network. It would be in their perfect-knowledge rational best interest to behave otherwise, but it turns out perfect knoweldge is kinda expensive.
I can produce case after case of hashers behaving poorly in this respect. Counting on it to preserve security against attacks which could be over in hours— e.g. by someone trying to cause a huge negative event to make a profit off shorting Bitcoin— is unwise. 
A number of years ago your pool delivered earning of something like 40% of expectations for months. A number of people were convinced that you were a thief because of it (that something was subtly broken, or there was some witholding attack seems like a more likely explanation, in my view), but that hasn't inhibited you from having the largest pool by far.
Actually, it was only about a _5%_ difference. Vladmir sucked at math and had no idea how to do a proper statistical analysis (he was using binomial distribution), and was trying to launch a competing pool so he was slandering the largest pool that didn't charge a fee at the time.
EDIT: I think in the end his claim was BTC Guild was "stealing" 4% of the total mined. This was the difference between 100% neutral expected revenue and the actual revenue.
These numbers are true, there is one thing to keep in mind: Any attempt to do so *is* visible to miners. The second a pool tries to start a fork and reverse a transaction, miners can see the prevblockhash on the pool no longer matches the main bitcoin network. While this isn't unusual in the case of an orphan race, the only time it has ever happened for more than 2 blocks in a row that I can recall was when we had a hardfork starting.
It's visible only in a purely abstract way. Deepbit was frequently "eating its own tail" due to running multiple bitcoin daemons which would end up on competing forks and then load balancing miners between them (if it doesn't do this anymore its only because it doesn't solve enough blocks).Not a single person in the world noticed this until Luke-Jr, bless his occasionally trolly heart, added code to BFGMiner to refuse to mine when a pool appeared to be forking itself. But not many people run that code.
Moreover, it's only a very partial solution: Say the network is on block A, you don't include the transaction you want to conflict in A. Then then another miner solves A and the network moves on to A+1 but you stay on A. Eventually you solve A'+1+1+1 ... and with some luck reverse the transaction. Miners never see any self-forking, and so the protection in BFGminer cannot help.
Performing the attack in this way simply constrains when you can start the attack (only right after another pool found a block), it does not reduce the success rate.
Quote
Additionally, an unsuccessful attempt would be completely apparent to miner's because their earnings would plummet [unless the pool continued to pay miners for the fork blocks]. Since BTC Guild's earnings can be audited down to the block hashes that generated payouts, this would be obviously false due to the blocks that were paid not existing on the blockchain.
A number of years ago your pool delivered earning of something like 40% of expectations for months. A number of people were convinced that you were a thief because of it (that something was subtly broken, or there was some witholding attack seems like a more likely explanation, in my view), but that hasn't inhibited you from having the largest pool by far.I cannot believe that many people would notice or care about a decline in revenue on the timescale of a single day or two.
Maybe they would. But thats a big maybe to stake the future of Bitcoin on, especially with people trying to open up new markets that allow them to take short positions. A substantial successful attack would dramatically undermine confidence in Bitcoin: The existence of major hashpower consolations already defeats the security assumptions, but its a theoretical weakness and until an attack happens many don't believe what incredibly shaky ground we are on here.
Quote
BTC Guild is gaining on % of the network again, and I've stated in the past I think this is something that will always happen. A zero-sum method of earning Bitcoins will always lead to natural monopolies as people prefer to get a steady income over a lottery.
Control over mining is orthogonal with pooling payments. There is no reason that a pool couldn't simply hand out coinbase transactions to miners and credit them for any remotely sane looking shares that includes the requested coinbase transaction. The pool would then only be a consolidation of miners payments and would have no risk for consolidating control of the blockchain consensus. Miners would become miners again, and not just people selling computing services for coin.
The risk that miners would intentionally have some junk transactions that get blocks orphaned would be strictly less than the block withholding risk which cannot be eliminated, as you could still ask miners to occasionally send whole blocks.
Had Satoshi though of this in 2010 I believe we would have a very different world today.
Just look at KNC. they are doing there own hosting also!
http://blockorigin.pfoe.be/chart.php : 33% != 43%. Please quit using 24-hour charts that let luck massively influence the real numbers.
33% of the hashpower will successfully reverse 6 confirmations 21% of the times it attempts.
33% can successfully reverse 2 confirms 53% of the times it attempts.
"51%" isn't a magical number. Large consolidations of control over hashpower undermine the security assumptions behind Bitcoin, Satoshi was opposed to centralized pooling, for good reasons— but sadly his vision didn't see quite far enough to offer the alternatives.
I don't think it's fair to single out BTCGuild here— though it is the largest pool— because you could get to the same number through combinations of compromising a couple of the smaller ones, which for all any of you know could already be run by the same parties.
These numbers are true, there is one thing to keep in mind: Any attempt to do so *is* visible to miners. The second a pool tries to start a fork and reverse a transaction, miners can see the prevblockhash on the pool no longer matches the main bitcoin network. While this isn't unusual in the case of an orphan race, the only time it has ever happened for more than 2 blocks in a row that I can recall was when we had a hardfork starting.
Additionally, an unsuccessful attempt would be completely apparent to miner's because their earnings would plummet [unless the pool continued to pay miners for the fork blocks]. Since BTC Guild's earnings can be audited down to the block hashes that generated payouts, this would be obviously false due to the blocks that were paid not existing on the blockchain.
BTC Guild is gaining on % of the network again, and I've stated in the past I think this is something that will always happen. A zero-sum method of earning Bitcoins will always lead to natural monopolies as people prefer to get a steady income over a lottery. There is one big change coming up though that will probably prevent any single entity from becoming 51% again, and that is the emergence of private mining companies. We already have ASICMINER and GHAsh.io, which have effectively taken 25% of the network for themselves that no pool will ever be able to take. There are other similar companies coming online as well, which will take another chunk of the available network hash rate. Being private entities, this is somewhat riskier (the power of a pool can easily be removed by it's members), but they will all be competing against each other in order to keep their slice of the network.
i make more a day at slush's pool than i do at btc guild anyway
http://blockorigin.pfoe.be/chart.php : 33% != 43%. Please quit using 24-hour charts that let luck massively influence the real numbers.
33% of the hashpower will successfully reverse 6 confirmations 21% of the times it attempts.
33% can successfully reverse 2 confirms 53% of the times it attempts.
"51%" isn't a magical number. Large consolidations of control over hashpower undermine the security assumptions behind Bitcoin, Satoshi was opposed to centralized pooling, for good reasons— but sadly his vision didn't see quite far enough to offer the alternatives.
I don't think it's fair to single out BTCGuild here— though it is the largest pool— because you could get to the same number through combinations of compromising a couple of the smaller ones, which for all any of you know could already be run by the same parties.
Actually I think Ghash.IO has much higher risk, those hash power all belong to the same mining equipment maker. The diversification on btcguild is strong
quite worring about btcguil they are fine and not going to do anything bad.
you crying now just wait 2 months.
you crying now just wait 2 months.
BTC guild can voluntarily limit themselves to 40% or so to help improve safety of the overall network.
So nothing can be done?
http://blockorigin.pfoe.be/chart.php : 33% != 43%. Please quit using 24-hour charts that let luck massively influence the real numbers.
It seems to me it is not healthy for the Bitcoin community to have BTCGuild currently with 43% of the entire network hash rate and still growing. This can be a real risk to the entire blockchain if if pool becomes compromised.
Get over it. Nothing anyone can do about it.
Whoa man. Deja vu. Like, whoa.
It seems to me it is not healthy for the Bitcoin community to have BTCGuild currently with 43% of the entire network hash rate and still growing. This can be a real risk to the entire blockchain if if pool becomes compromised.
Jump to: