Topic: [2014-06-16] GHASH.IO statement about the 51 % problem - page 3. (Read 3517 times)

Rubbish.


It is known that GHash has previously done evil.
They are currently the biggest pool.
Most people don't seem to give a crap, and will mine wherever pays them the most.

Not quite.a transaction WHITOUT confirmation is NO TRANSACTION
 UNCONFIRMID TRANSACTIONS WERE NEVER MENT TO BE SAVE AT AL!!!!
accepting 0 confirmations is accepting no safety and is not  honoring the BTC protocol.  
accepting 0 confirmations as save is plain stupid.
this is why there must be 6 CONFIRMATIONS to have a transaction!
Agian you are fudding.

Bitcoin transactions: Why it is recommended to wait for at least six confirmations?

Due to its decentralized nature, bitcoin can’t rely on a master authoritative source to prevent double-spending, when an attacker tries to spend some money more than once. Anyway, various defensive strategies have been implemented to minimize chances for such a fraudulent activity to happen in the bitcoin network.

One particular approach, described by the Bitcoin Wiki as a Brute force attack, can be attempted by an attacker with relatively high mining hashrate, but not necessarily above 50% level. The attack would follow this pattern:

1. The attacker submits a transaction to the network which pays the merchant.

2. At the same time, he will immediately start to privately mine his own blocks, where he will include the double-spending transaction instead of the one where he pays the merchant. But if he manages to find a new block, he will not broadcast it to the network.

3. The merchant will wait for 6 confirmations and then sends the product. But if the attacker managed to mine more than 6 blocks at this time, he can release his own private fork to the network, and since he has the longest chain, other nodes would accept it and the original transaction will get rejected. This way, the attacker gets both the merchant product and also his bitcoins back.

It might seem that such an attack is statistically unlikely to happen, but when we suppose, that the attacker possess for example 25% of the network hashpower, the probability that he will mine 7 blocks in a row is 0.25^7 = 0.006%. This looks like a very small probability, but with block time being 10 minutes, mining 7 block in a row will happen approximately once per four months.
Fortunately, there is another measure implemented in the Bitcoin protocol, which eliminates the possibility of such an attack. In the Protocol rules description at Bitcoin wiki, it is listed as a Rule 13 for “block” messages:

13. Reject if timestamp is the median time of the last 11 blocks or before

This can be interpreted in a following way: If the attacker will try to mine his own private blockchain fork, other nodes will almost certainly reject it, if his length is more than 6 blocks, since the timestamp of the first such mined block will be almost certainly older than the median time of the last 11 mined blocks. Replacing 6 or less blocks is possible, but when attacker tries to replace 7 or more blocks, the first one will be too old to be accepted.

TL;DR: Six bitcoin confirmations is not an arbitrary number. If payee accepts a transaction with less than six confirmations, it is possible that the attacker, even without a majority of the hashpower, can launch a brute force attack by mining his private blockchain fork and reverse the transaction. With six or more confirmations, such an attack will be rejected by the Protocol rule 13 described above.


Note for programmers: The check is implemented in the method GetMedianTimePast() and called in method AcceptBlock(), file main.cpp:

bool CBlock::AcceptBlock(CValidationState &state, CDiskBlockPos *dbp)
{
...
// Check timestamp against prev
if (GetBlockTime() GetMedianTimePast())
return state.Invalid(error("AcceptBlock() : block's timestamp is too early"));

...
}

combine this with....

FACT: A pool does not have its own hashing capacity, it instead has suppliers -- those individual and corporate miners performing the pool's mining work. A pool that is doing evil will in time lose hashing capacity as those mining there discover that the pool is harming Bitcoin and take their hashing capacity elsewhere. For a pool to try to do a 51% attack for the purpose of double spending a transaction with confirmations 6-deep means that pool would need to take the hashing capacity offline and use it to start mining a private fork. Additionally, no subsequent blocks mined on the public Bitcoin network (while the attack is occurring) would be solved by the ghash.io pool. If ghash.io's 45,000 Th/s were to go offline, that would be bad. If at the same time no blocks over the next couple hours were ghash.io's, that would be a "network event" that would indicate quite possibly that a pool is attempting a 51% attack. There are a couple hours then, at least, before this attack could be successful at reaching the six confirmations needed (as, with only 51% of the hashing capacity but the same difficulty, blocks on the private fork get solved at about one block every twenty minutes). Miners, alerted to a potential 51% attack, could start pulling their hashing capacity from the pool causing it to drop below 51% before the private fork has reached six confirmations -- thus causing the attack to fail. i.e., An attempt at double spending by the pool is not certain to succeed. The pool would be taking a gamble that it can pull off such an attack before that activity is detected or that the response by its suppliers after detection would be too little, too late.
and we are very save

Quite. You've just said that they did perform a double spend attack.

Not quite.



Bitcoin transactions: Why it is recommended to wait for at least six confirmations?

Due to its decentralized nature, bitcoin can’t rely on a master authoritative source to prevent double-spending, when an attacker tries to spend some money more than once. Anyway, various defensive strategies have been implemented to minimize chances for such a fraudulent activity to happen in the bitcoin network.

One particular approach, described by the Bitcoin Wiki as a Brute force attack, can be attempted by an attacker with relatively high mining hashrate, but not necessarily above 50% level. The attack would follow this pattern:

1. The attacker submits a transaction to the network which pays the merchant.

2. At the same time, he will immediately start to privately mine his own blocks, where he will include the double-spending transaction instead of the one where he pays the merchant. But if he manages to find a new block, he will not broadcast it to the network.

3. The merchant will wait for 6 confirmations and then sends the product. But if the attacker managed to mine more than 6 blocks at this time, he can release his own private fork to the network, and since he has the longest chain, other nodes would accept it and the original transaction will get rejected. This way, the attacker gets both the merchant product and also his bitcoins back.

It might seem that such an attack is statistically unlikely to happen, but when we suppose, that the attacker possess for example 25% of the network hashpower, the probability that he will mine 7 blocks in a row is 0.25^7 = 0.006%. This looks like a very small probability, but with block time being 10 minutes, mining 7 block in a row will happen approximately once per four months.
Fortunately, there is another measure implemented in the Bitcoin protocol, which eliminates the possibility of such an attack. In the Protocol rules description at Bitcoin wiki, it is listed as a Rule 13 for “block” messages:

13. Reject if timestamp is the median time of the last 11 blocks or before

This can be interpreted in a following way: If the attacker will try to mine his own private blockchain fork, other nodes will almost certainly reject it, if his length is more than 6 blocks, since the timestamp of the first such mined block will be almost certainly older than the median time of the last 11 mined blocks. Replacing 6 or less blocks is possible, but when attacker tries to replace 7 or more blocks, the first one will be too old to be accepted.

TL;DR: Six bitcoin confirmations is not an arbitrary number. If payee accepts a transaction with less than six confirmations, it is possible that the attacker, even without a majority of the hashpower, can launch a brute force attack by mining his private blockchain fork and reverse the transaction. With six or more confirmations, such an attack will be rejected by the Protocol rule 13 described above.


Note for programmers: The check is implemented in the method GetMedianTimePast() and called in method AcceptBlock(), file main.cpp:

bool CBlock::AcceptBlock(CValidationState &state, CDiskBlockPos *dbp)
{
...
// Check timestamp against prev
if (GetBlockTime() GetMedianTimePast())
return state.Invalid(error("AcceptBlock() : block's timestamp is too early"));

...
}

So you've just agreed that they did engage in a double-spend attack? Not really FUD then, is it?
But it is ok because they only attacked stupid people?

Not until it's too late.


FACT: Just this morning ghash.io didn't find any blocks for 1.5 hours, and nobody raised an eyebrow. Later this morning they released 5 blocks in 20 minutes. They may be also be hiding their actual mining rate by releasing some blocks without telling. For instance http://blockchain.info/blocks/91.121.192.38 has only released 4 blocks, but 3 of them appeared within less than 2 hours. This strongly suggests that a lot of the unknown mining power belongs to a single entity which is frequently switching IP.

Everybody will notice the mining of a private fork!!!!

FACT: A pool does not have its own hashing capacity, it instead has suppliers -- those individual and corporate miners performing the pool's mining work. A pool that is doing evil will in time lose hashing capacity as those mining there discover that the pool is harming Bitcoin and take their hashing capacity elsewhere. For a pool to try to do a 51% attack for the purpose of double spending a transaction with confirmations 6-deep means that pool would need to take the hashing capacity offline and use it to start mining a private fork. Additionally, no subsequent blocks mined on the public Bitcoin network (while the attack is occurring) would be solved by the ghash.io pool. If ghash.io's 45,000 Th/s were to go offline, that would be bad. If at the same time no blocks over the next couple hours were ghash.io's, that would be a "network event" that would indicate quite possibly that a pool is attempting a 51% attack. There are a couple hours then, at least, before this attack could be successful at reaching the six confirmations needed (as, with only 51% of the hashing capacity but the same difficulty, blocks on the private fork get solved at about one block every twenty minutes). Miners, alerted to a potential 51% attack, could start pulling their hashing capacity from the pool causing it to drop below 51% before the private fork has reached six confirmations -- thus causing the attack to fail. i.e., An attempt at double spending by the pool is not certain to succeed. The pool would be taking a gamble that it can pull off such an attack before that activity is detected or that the response by its suppliers after detection would be too little, too late.

---------------

Now if you have a 51% attack performed not by a pool but by an attacker with its own resources, then many of your points are valid. What that attacker would need to do is simply procure access to about $200M worth of SHA-2 ASIC hardware. Unfortunately for you in making your point -- that amount of hashing capacity likely exceeds the capacity of all the Bitcoin mining ASIC manufacturers, combined, today.

How can we be sure they're following the same rules for when it's ok to commit fraud as you? Mine are that it's never ok, but I'm painfully aware that not everybody follows my rules.

Know what, the best solution to this problem would be to ask the smaller pools to reduce their fees to 0%, at least until GHash clocks below 40%. But is it too much to ask for? If Ghash can function without any fees, then why cant BTCGuild and Discus Fish do the same?

Let's have some FUD vs. FACT now.

------------------

FUD: Double-spends: GHash actually engaged in such an attack before it reached the 51% mark, and it could do so again

FACT: Ghash.io has never committed double spending against a CONFIRMED transaction. Apparently at one time Ghash.io had committed fraud against an online gambling site by performing a Finney attack to cancel their non-winning bet transactions. This was possible because the casino recognized payment on 0/unconfirmed transactions -- something that NOBODY would recommend a merchant do for an anonymous, online service.

---------------

FUD: Mining power =50%: Double-spends against 6-confirmed transactions are certain to succeed.

FACT: A pool does not have its own hashing capacity, it instead has suppliers -- those individual and corporate miners performing the pool's mining work. A pool that is doing evil will in time lose hashing capacity as those mining there discover that the pool is harming Bitcoin and take their hashing capacity elsewhere. For a pool to try to do a 51% attack for the purpose of double spending a transaction with confirmations 6-deep means that pool would need to take the hashing capacity offline and use it to start mining a private fork. Additionally, no subsequent blocks mined on the public Bitcoin network (while the attack is occurring) would be solved by the ghash.io pool. If ghash.io's 45,000 Th/s were to go offline, that would be bad. If at the same time no blocks over the next couple hours were ghash.io's, that would be a "network event" that would indicate quite possibly that a pool is attempting a 51% attack. There are a couple hours then, at least, before this attack could be successful at reaching the six confirmations needed (as, with only 51% of the hashing capacity but the same difficulty, blocks on the private fork get solved at about one block every twenty minutes). Miners, alerted to a potential 51% attack, could start pulling their hashing capacity from the pool causing it to drop below 51% before the private fork has reached six confirmations -- thus causing the attack to fail. i.e., An attempt at double spending by the pool is not certain to succeed. The pool would be taking a gamble that it can pull off such an attack before that activity is detected or that the response by its suppliers after detection would be too little, too late.

---------------

Now if you have a 51% attack performed not by a pool but by an attacker with its own resources, then many of your points are valid. What that attacker would need to do is simply procure access to about $200M worth of SHA-2 ASIC hardware. Unfortunately for you in making your point -- that amount of hashing capacity likely exceeds the capacity of all the Bitcoin mining ASIC manufacturers, combined, today.





Bitcoin transactions: Why it is recommended to wait for at least six confirmations?

Due to its decentralized nature, bitcoin can’t rely on a master authoritative source to prevent double-spending, when an attacker tries to spend some money more than once. Anyway, various defensive strategies have been implemented to minimize chances for such a fraudulent activity to happen in the bitcoin network.

One particular approach, described by the Bitcoin Wiki as a Brute force attack, can be attempted by an attacker with relatively high mining hashrate, but not necessarily above 50% level. The attack would follow this pattern:

1. The attacker submits a transaction to the network which pays the merchant.

2. At the same time, he will immediately start to privately mine his own blocks, where he will include the double-spending transaction instead of the one where he pays the merchant. But if he manages to find a new block, he will not broadcast it to the network.

3. The merchant will wait for 6 confirmations and then sends the product. But if the attacker managed to mine more than 6 blocks at this time, he can release his own private fork to the network, and since he has the longest chain, other nodes would accept it and the original transaction will get rejected. This way, the attacker gets both the merchant product and also his bitcoins back.

It might seem that such an attack is statistically unlikely to happen, but when we suppose, that the attacker possess for example 25% of the network hashpower, the probability that he will mine 7 blocks in a row is 0.25^7 = 0.006%. This looks like a very small probability, but with block time being 10 minutes, mining 7 block in a row will happen approximately once per four months.
Fortunately, there is another measure implemented in the Bitcoin protocol, which eliminates the possibility of such an attack. In the Protocol rules description at Bitcoin wiki, it is listed as a Rule 13 for “block” messages:

13. Reject if timestamp is the median time of the last 11 blocks or before

This can be interpreted in a following way: If the attacker will try to mine his own private blockchain fork, other nodes will almost certainly reject it, if his length is more than 6 blocks, since the timestamp of the first such mined block will be almost certainly older than the median time of the last 11 mined blocks. Replacing 6 or less blocks is possible, but when attacker tries to replace 7 or more blocks, the first one will be too old to be accepted.

TL;DR: Six bitcoin confirmations is not an arbitrary number. If payee accepts a transaction with less than six confirmations, it is possible that the attacker, even without a majority of the hashpower, can launch a brute force attack by mining his private blockchain fork and reverse the transaction. With six or more confirmations, such an attack will be rejected by the Protocol rule 13 described above.


Note for programmers: The check is implemented in the method GetMedianTimePast() and called in method AcceptBlock(), file main.cpp:

bool CBlock::AcceptBlock(CValidationState &state, CDiskBlockPos *dbp)
{
...
// Check timestamp against prev
if (GetBlockTime() GetMedianTimePast())
return state.Invalid(error("AcceptBlock() : block's timestamp is too early"));

...
}


http://btc-base.blogspot.sk/2014/01/bitcoin-transactions-why-it-is.html

It is the 1.5PH that Bitfury pulled out that resulted in that drop. This whole debacle has clearly shown us who is and is not working with the credit agencies who have infiltrated the Bitcoin Foundation and are doing everything they can to try and control the whole network. If they win, they rule the world. If we win, they will be forced to play fair.

You should support this Kickstarter project. It has tons of great interviews with the best of the best in bitcoiners. https://www.kickstarter.com/projects/bitcointheendofmoney/bitcoin-the-end-of-money-as-we-know-it

Has anyone checked today's hash rate? Seems that GHash has dropped by some 2% points. May be the result of Bitfury pulling out their mining rigs. Anti-GHash guys should be happy. 

Or even better than that, why don't people who are sitting on huge mountains of coins do something useful with them like invest in or start a bitcoin business? I was a fat lazy sack-of-shit trader for a few months, sitting on thousands of dollars of coins, and then I decided to start a business for cryptocurrency instead. My life has been far more productive and happy ever since then.

You need to redistribute your power and put it to good use or else bitcoin will die. That is a guarantee. Open you eyes and get active, people, the fight for the crypto future has just begun. Be a warrior.

Let's not forget the time when GHash.IO was hacked into and sending all of the coins it earned to the hacker's wallet for three days before GHash.IO staff even noticed what was going on. This is not about trusting people or even whether they are trustworthy. This is about the simple fact that centralized power always corrupts, always, and bitcoin is supposed to be a tool of decentralization. GHash.IO is just drunk with power right now, and it will be their downfall, likely something similar to the fireworks during the fall of Mt. Gox will ensue shortly.

That is either a downright lie, or a shading of the truth, depending on how kindly you look upon them, and whether you view Cex and GHash as one entity.
Cex have admitted to previously being involved in a double-spend attack.

Another question is what happens when the government in what ever country their owners live in orders them to do something that is harmful to bitcoin and keep quiet about it? In the US this is done all the time to ISPs and other internet related companies.

Just like the Secret Meeting That Launched the Federal Reserve. The consolidation of power is inevitable. Bitcoin is doomed.