[2014-06-16] GHASH.IO statement about the 51 % problem

[notthematrix]

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.

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 quite.
(snip unrelated information)

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

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

[1715404593]

1715404593

[1715404593]

1715404593

[1715404593]

1715404593

[1715404593]

1715404593

[murraypaul]

this is why there must be 6 CONFIRMATIONS to have a transaction!

Rubbish.

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.

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.

[notthematrix]

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.

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 quite.
(snip unrelated information)

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

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

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

[notthematrix]

this is why there must be 6 CONFIRMATIONS to have a transaction!

Rubbish.

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.

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.

IF YOU ARE AS STUPID TO ACCEPT UNCONFIRIMED TRANSACTIONS EVRYBODY CAN DO EVIL IF THEY WANT.

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!

This is how bitcoin works stick to it or get burned , its your own risk  , give real arguments of f***k off

[murraypaul]

IF YOU ARE AS STUPID TO ACCEPT UNCONFIRIMED TRANSACTIONS EVRYBODY CAN DO EVIL IF THEY WANT.

As I asked above: But it is ok because they only attacked stupid people?
Seems like the answer is yes.

[notthematrix]

IF YOU ARE AS STUPID TO ACCEPT UNCONFIRIMED TRANSACTIONS EVRYBODY CAN DO EVIL IF THEY WANT.

As I asked above: But it is ok because they only attacked stupid people?
Seems like the answer is yes.

Yes if you take unconfirmed transactions as transactios , you ask for it.
I dont need to be ghash.io to do dubble spend a 0 confirmation anybody can do this.
the netwrk wil simply confirm the fastest transaction , so yes only stupid users will do this.
when a transaction is confirmed 6 it is save. as I explained mutiple time's.

[bryant.coleman]

Yes if you take unconfirmed transactions as transactios , you ask for it.

OK. I magine that you are the owner of a coffee shop, which has recently decided to accept Bitcoin payments. And constomer comes to you and pays with Bitcoins. Would you tell him: "Buddy, wait for 3 hours. I need to get 6 confirmations to make sure that you don't double spend your coins" ?

[murraypaul]

IF YOU ARE AS STUPID TO ACCEPT UNCONFIRIMED TRANSACTIONS EVRYBODY CAN DO EVIL IF THEY WANT.

As I asked above: But it is ok because they only attacked stupid people?
Seems like the answer is yes.

Yes if you take unconfirmed transactions as transactios , you ask for it.
I dont need to be ghash.io to do dubble spend a 0 confirmation anybody can do this.
the netwrk wil simply confirm the fastest transaction , so yes only stupid users will do this.
when a transaction is confirmed 6 it is save. as I explained mutiple time's.

And you don't think that makes GHash dishonest?

[notthematrix]

Yes if you take unconfirmed transactions as transactios , you ask for it.

OK. I magine that you are the owner of a coffee shop, which has recently decided to accept Bitcoin payments. And constomer comes to you and pays with Bitcoins. Would you tell him: "Buddy, wait for 3 hours. I need to get 6 confirmations to make sure that you don't double spend your coins" ?

A coffeeshop calculates the risk , a crediccard can also be cashed back , and money can be counterfitted.
a failed $1 transaction do to dubble spend when accepting 0 confirmations is accepible.
a $25000 transcation can wait for 6 confirmations easaly.
its a matterv risk calculation.

[notthematrix]

IF YOU ARE AS STUPID TO ACCEPT UNCONFIRIMED TRANSACTIONS EVRYBODY CAN DO EVIL IF THEY WANT.

As I asked above: But it is ok because they only attacked stupid people?
Seems like the answer is yes.

Yes if you take unconfirmed transactions as transactios , you ask for it.
I dont need to be ghash.io to do dubble spend a 0 confirmation anybody can do this.
the netwrk wil simply confirm the fastest transaction , so yes only stupid users will do this.
when a transaction is confirmed 6 it is save. as I explained mutiple time's.

And you don't think that makes GHash dishonest?

the question is was it ghash.io it self or a  individual miner mining at that pool , you dont need a lot of hasing power to respend a unconfirmed transaction.

[murraypaul]

IF YOU ARE AS STUPID TO ACCEPT UNCONFIRIMED TRANSACTIONS EVRYBODY CAN DO EVIL IF THEY WANT.

As I asked above: But it is ok because they only attacked stupid people?
Seems like the answer is yes.

Yes if you take unconfirmed transactions as transactios , you ask for it.
I dont need to be ghash.io to do dubble spend a 0 confirmation anybody can do this.
the netwrk wil simply confirm the fastest transaction , so yes only stupid users will do this.
when a transaction is confirmed 6 it is save. as I explained mutiple time's.

And you don't think that makes GHash dishonest?

the question is was it ghash.io it self or a  individual miner mining at that pool , you dont need a lot of hasing power to respend a unconfirmed transaction.

It was (the previous owners of) GHash itself.
It is the pool which decides which transactions to include in a block, not the individual miners at the pool.
Before lecturing people on fact vs fud, shouldn't you find out what the facts are?

[CoinMode]

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

Wow, it sure did take a lot of words for you to say "Just trust GHash.IO because they aren't evil, pinky swear".

[notthematrix]

IF YOU ARE AS STUPID TO ACCEPT UNCONFIRIMED TRANSACTIONS EVRYBODY CAN DO EVIL IF THEY WANT.

As I asked above: But it is ok because they only attacked stupid people?
Seems like the answer is yes.

Yes if you take unconfirmed transactions as transactios , you ask for it.
I dont need to be ghash.io to do dubble spend a 0 confirmation anybody can do this.
the netwrk wil simply confirm the fastest transaction , so yes only stupid users will do this.
when a transaction is confirmed 6 it is save. as I explained mutiple time's.

And you don't think that makes GHash dishonest?

the question is was it ghash.io it self or a  individual miner mining at that pool , you dont need a lot of hasing power to respend a unconfirmed transaction.

It was (the previous owners of) GHash itself.
It is the pool which decides which transactions to include in a block, not the individual miners at the pool.
Before lecturing people on fact vs fud, shouldn't you find out what the facts are?

FACT is that if ghash.io did not confirm the transaction oher miner would had done!
so it does not make any sense to do this as ghash.io .
if they block a transaction some other miner will handle it and will be the fastest.
they dont own the capasity so it will be noticed in the number of winning blocks......,,
so again whats the problem'? , waiting 6 confirmations is the solution , only if you are dumb you accept 0 confiramtions.
and as I told you you cant have more then 6 blocks in one row from one miner , so it wil take a bit longer to confirm this transaction but it WILL in the end be confirmed.

[MrTeal]

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.

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.

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.

I'm curious how you think the majority of miners will notice that they are mining on a GHash.io fork instead of the main chain? Even just looking at today's stats there are periods where GHash has mined 6 blocks in a half hour, and some where they have found no blocks for an hour and a half. Even apart from the fact a large portion of GHash is their private mining pool, you're giving way too much credit to the responsiveness of most miners. While it could take a decent bit of time to reorg a 6 deep chain if they got unlucky, it would still likely happen way before enough people moved off the pool to make a difference.

[notthematrix]

I'm curious how you think the majority of miners will notice that they are mining on a GHash.io fork instead of the main chain? Even just looking at today's stats there are periods where GHash has mined 6 blocks in a half hour, and some where they have found no blocks for an hour and a half. Even apart from the fact a large portion of GHash is their private mining pool, you're giving way too much credit to the responsiveness of most miners. While it could take a decent bit of time to reorg a 6 deep chain if they got unlucky, it would still likely happen way before enough people moved off the pool to make a difference.

the number of found blocks from ghash.io will be 0 for a very long time , because it is using its power to mine a private fork
but even then every block > 6 in a row will be ignored by the prtocol!

the code can be found here

 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() <= pindexPrev->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

so you have to mine more then 6 blocks in a row , this is blocked by bitcoin source code thats why its NEVER more then 6.
and then notting for a while! , its just as the code says , http://btc-base.blogspot.sk/2014/01/bitcoin-transactions-why-it-is.html
so to make this possible it has to gues blocks of other miners too , and be more then 11 blocks faster!

 13. Reject [a block] 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.

exlpains this...
so no ghash.io cant do this even if they want it.

[murraypaul]

FACT is that if ghash.io did not confirm the transaction oher miner would had done!
so it does not make any sense to do this as ghash.io .

They did it.

if they block a transaction some other miner will handle it and will be the fastest.

If they solve a block including the second transaction, the first transaction will never be confirmed by anyone, because the shared inputs will have already been spent.
And the more %age of hashing power they control, the more chance they have of doing this.

[notthematrix]

FACT is that if ghash.io did not confirm the transaction oher miner would had done!
so it does not make any sense to do this as ghash.io .

They did it.

if they block a transaction some other miner will handle it and will be the fastest.

If they solve a block including the second transaction, the first transaction will never be confirmed by anyone, because the shared inputs will have already been spent.
And the more %age of hashing power they control, the more chance they have of doing this.

well yes bit this is why you need 6 confirmations!!!!!!!!!

[murraypaul]

FACT is that if ghash.io did not confirm the transaction oher miner would had done!
so it does not make any sense to do this as ghash.io .

They did it.

if they block a transaction some other miner will handle it and will be the fastest.

If they solve a block including the second transaction, the first transaction will never be confirmed by anyone, because the shared inputs will have already been spent.
And the more %age of hashing power they control, the more chance they have of doing this.

well yes bit this is why you need 6 confirmations!!!!!!!!!

You are going a long way round in circles to avoid answering this question:

And you don't think that [double-spend attack against BetCoin] makes GHash dishonest?

[notthematrix]

FACT is that if ghash.io did not confirm the transaction oher miner would had done!
so it does not make any sense to do this as ghash.io .

They did it.

if they block a transaction some other miner will handle it and will be the fastest.

If they solve a block including the second transaction, the first transaction will never be confirmed by anyone, because the shared inputs will have already been spent.
And the more %age of hashing power they control, the more chance they have of doing this.

well yes bit this is why you need 6 confirmations!!!!!!!!!

You are going a long way round in circles to avoid answering this question:

And you don't think that [double-spend attack against BetCoin] makes GHash dishonest?

its very simple a ,miner can NEVER do 7 blocks in a row.
see rule 13 http://btc-base.blogspot.sk/2014/01/bitcoin-transactions-why-it-is.html
7 blocks is the inital transactions + 6 confirmations
at best ghash.io can do the double spend + 5 confirmations  ... the 6thx (block 7) has to be done by somone else.
if thats not done the transaction will fial back to zero!
so its that simple , one miner can max do 6 blocks in a row , thats 5 confirmations , and thats why you need at least 6 confirmations (7 blocks) to be save because the 7th block can never be done by the same miner. , its so very simple
so you can never double spend , bacause you can never make more then 6 blocks in a row , so you NEVER get a double s[end with 6 confirmations.

[murraypaul]

You are going a long way round in circles to avoid answering this question:

And you don't think that [double-spend attack against BetCoin] makes GHash dishonest?

its very simple a ,miner can NEVER do 7 blocks in a row.
see rule 13 http://btc-base.blogspot.sk/2014/01/bitcoin-transactions-why-it-is.html
7 blocks is the inital transactions + 6 confirmations
at best ghash.io can do the double spend + 5 confirmations... the 6thx (block 7) has to be done by somone else.
if thats not done the transaction will fial back to zero!
so its that simple , one miner can max do 6 blocks in a row , thats 5 confirmations , and thats why you need at least 6 confirmations (7 blocks) to be save because the 7th block can never be done by the same miner. , its so very simple

Do you think that [double-spend attack against BetCoin] makes GHash dishonest?