[BOUNTY] Bitcoin blockchain monitoring site

[[Tycho]]

There is concern among bitcoiners, that pool with >50% power can exploit the network with double spending transactions. I think that someone should make a service for monitoring blockchain forks and double spending attempts. I'm pledging 50 BTC for such service; if you are concerned with this problem too, add up your pledge.

To receive award this service should provide at least

1) Real time list of blocks, including orphaned ones
2) Real time list of transactions with double spend attempts

[1713539570]

1713539570

[1713539570]

1713539570

[1713539570]

1713539570

[Miner-TE]

I'll pledge 5 BTC.

[shackleford]

+5 btc

[Veldy]

There is concern among bitcoiners, that pool with >50% power can exploit the network with double spending transactions. I think that someone should make a service for monitoring blockchain forks and double spending attempts. I'm pledging 50 BTC for such service; if you are concerned with this problem too, add up your pledge.

To receive award this service should provide at least

1) Real time list of blocks, including orphaned ones
2) Real time list of transactions with double spend attempts

The whole point is not to have a centralized authority and this sounds like it is creating one.  Doing so will destroy the very nature of bitcoin.  Instead, pools and miners need to do what they have to to make the scenario impossible [assuming Slush comes up to full capacity, work needs to be done such that at LEAST no two pools add up to much more than 50% of the computational power of the network].  If pool operators and miners don't have the will power to do this, then bitcoin is at risk.

[bitlotto]

Wouldn't it be better to add the feature to the Bitcoin software itself? (Not sure how possible this is) Otherwise, people will have to always check the site to verify. Perhaps the software could highlight the transaction in red if the money is being spent in two diverging block chains? That way the person getting the money will know and wait until it's not red before accepting it as valid.

[Veldy]

Wouldn't it be better to add the feature to the Bitcoin software itself? (Not sure how possible this is) Otherwise, people will have to always check the site to verify. Perhaps the software could highlight the transaction in red if the money is being spent in two diverging block chains? That way the person getting the money will know and wait until it's not red before accepting it as valid.

It takes awhile to invalidate a block [hence why Slush, BTCMine and other pools wait for 120 confirmations before payout].  Nobody would know which block is correct for a little while and in a large P2P network, the evidence of double spending [versus a timing error causing the occasional invalid block show up] may not be obvious until a period of time goes by [and the fraudulent block probably wouldn't hit the network for quite awhile after the original good block as it has to be recreated with a longer chain than the original is getting in confirmations over the same period of time (which is why > 50% power is required)].  In short, I do not think it is possible.  What is possible is for the market to prevent the ability for such an attack by means of creating more pools, securing pools, and for pools to willingly not become TOO large (meaning, willing to risk the bitcoin market for personal profit motive ... perhaps not the issue today, but now the warning is out that it can and essentially did happen, but without this attack actually occurring fortunately ... but it sure is an example of a potential dry run).

[Ulysses]

Veldy, if two pools can collude, than so can three, four and more. This risk is inherent to bitcoin design. The only solution to this problem is monitoring and notifying miners in case when pools start to double spend.

[Veldy]

Veldy, if two pools can collude, than so can three, four and more. This risk is inherent to bitcoin design. The only solution to this problem is monitoring and notifying miners in case when pools start to double spend.

Yes they can, but it becomes more and more difficult.  Further, I think it unlikely that the pool operators will be in on the collusion as it is clear to me that they would be the most heavily scrutinized after an attack.  Thus, an external attacker would have to compromise several pools if they are all smaller rather than one large pool.

[Veldy]

Veldy, if two pools can collude, than so can three, four and more. This risk is inherent to bitcoin design. The only solution to this problem is monitoring and notifying miners in case when pools start to double spend.

It appears to me that by the time double spending is detected you have two problems.  Somebody has already lost their money and it is already too late.  I am confident that an attack would be executed in seconds with the initial spend and the blocks in the pool (s) wouldn't be dispensed until the new chain was longer than the original ... so by the time it is detected it is too late.

[Ulysses]

It appears to me that by the time double spending is detected you have two problems.  Somebody has already lost their money and it is already too late.  I am confident that an attack would be executed in seconds with the initial spend and the blocks in the pool (s) wouldn't be dispensed until the new chain was longer than the original ... so by the time it is detected it is too late.

You can't do it instantly, the attacker have to recreate all the confirmed blocks. If the sum is so large, that you are afraid of double spend - than wait for enough blocks. E.g. 6 blocks = 2 hours with 50% of network.

In my opinion, monitoring for such block forks is much more important, than trying to impose cartel agreement of not having more than 50% on pool operators. If we could have such warning in clients, than it would be even better. Maybe such monitoring service should provide the API and charge a small use fee?

[Veldy]

It appears to me that by the time double spending is detected you have two problems.  Somebody has already lost their money and it is already too late.  I am confident that an attack would be executed in seconds with the initial spend and the blocks in the pool (s) wouldn't be dispensed until the new chain was longer than the original ... so by the time it is detected it is too late.

You can't do it instantly, the attacker have to recreate all the confirmed blocks. If the sum is so large, that you are afraid of double spend - than wait for enough blocks. E.g. 6 blocks = 2 hours with 50% of network.

In my opinion, monitoring for such block forks is much more important, than trying to impose cartel agreement of not having more than 50% on pool operators. If we could have such warning in clients, than it would be even better. Maybe such monitoring service should provide the API and charge a small use fee?

Its the recreated block that is actually bad, but it won't appear good until it is recreated as a longer chain than the original.  The original can be spent immediately.

[goatpig]

It appears to me that by the time double spending is detected you have two problems.  Somebody has already lost their money and it is already too late.  I am confident that an attack would be executed in seconds with the initial spend and the blocks in the pool (s) wouldn't be dispensed until the new chain was longer than the original ... so by the time it is detected it is too late.

You can't do it instantly, the attacker have to recreate all the confirmed blocks. If the sum is so large, that you are afraid of double spend - than wait for enough blocks. E.g. 6 blocks = 2 hours with 50% of network.

In my opinion, monitoring for such block forks is much more important, than trying to impose cartel agreement of not having more than 50% on pool operators. If we could have such warning in clients, than it would be even better. Maybe such monitoring service should provide the API and charge a small use fee?

It isn't so much to double spend but to hurt the Bitcoin network as a whole. I think the attack on Gox is proof enough that some people out there are willing to hurt this network.

Also, pledging 10 BTC.

[grantbdev]

I agree that this information should be freely available to the public.

[grndzero]

http://www.bitcoinmonitor.com/ is almost as close as you can get to a real time network monitor, theoretically the data gathering processes behind it would be a great place to start ...

Is orphaned block information even broadcast on the network, or is it something that is just dropped when nodes receive new block chain information?

The double spend part I have no clue how to detect.

[Raulo]

Is orphaned block information even broadcast on the network, or is it something that is just dropped when nodes receive new block chain information?

This type of forks is easy to detect. Every time it happens, bitcoin deamon prints "REORGANIZE" is debug.log. There is one every a few thousand blocks due to coincidental finding two blocks at roughly the same time.  After that miners try to add to the chain they received first. If the one that won the race is not the one you have stored as the longest in memory, the chain reorganizes. For those who has the other chain, nothing will be printed in debug.log because no reorganization takes place.

The double spend part I have no clue how to detect.

You need to look if the forked chain contains the transactions that are inconsistent with the previous chain.

Since the client requires 5 confirmations, any shorter than 5 fork cannot reverse any confirmed transactions. So detecting large forks is the very first step in finding potential problems.

I have never seen a fork longer than 1 on mainnet (I have seen some on testnet) and it is very rare by accident. I remember that on IRC someone claimed that after the very first slashdoting in July last year, the blocks were generated so quickly (and the network was smaller), there were quite a few longer than 1 accidental chain splits.

[grndzero]

This type of forks is easy to detect. Every time it happens, bitcoin deamon prints "REORGANIZE" is debug.log. There is one every a few thousand blocks due to coincidental finding two blocks at roughly the same time.  After that miners try to add to the chain they received first. If the one that won the race is not the one you have stored as the longest in memory, the chain reorganizes. For those who has the other chain, nothing will be printed in debug.log because no reorganization takes place.

 If he's asking for a program that to show all orphaned blocks on the network, will a program be able to see all orphaned block behavior on the network or only the behavior of the local node that it's pulling data from?

You need to look if the forked chain contains the transactions that are inconsistent with the previous chain.

Since the client requires 5 confirmations, any shorter than 5 fork cannot reverse any confirmed transactions. So detecting large forks is the very first step in finding potential problems.

I have never seen a fork longer than 1 on mainnet (I have seen some on testnet) and it is very rare by accident. I remember that on IRC someone claimed that after the very first slashdoting in July last year, the blocks were generated so quickly (and the network was smaller), there were quite a few longer than 1 accidental chain splits.

It sounds like a supernode could accomplish this without too much trouble since it has multiple connections to have the most up to date block chain info and can listen to all transactions like bitcoinmonitor does. Someone would just have to develop the code to identify the forks?

[Raulo]

If he's asking for a program that to show all orphaned blocks on the network, will a program be able to see all orphaned block behavior on the network or only the behavior of the local node that it's pulling data from?

Only local. But any "evil forks" has to be distributed in order to make sense. Any node that has a "good" chain will detect injection of longer "evil" chain because it will trigger reorganization. The only thing that cannot be easily detected are dying forks. A fork that is growing independently but is outrun by the main chain because such fork may never reach your node. 

It sounds like a supernode could accomplish this without too much trouble since it has multiple connections to have the most up to date block chain info and can listen to all transactions like bitcoinmonitor does. Someone would just have to develop the code to identify the forks?

It is possible. I remember theymos (owner of blockexplorer) stated he had plans to incorporate blocks forks. The only problem is that because it is so rare, it is quite difficult to debug the code. You can create forks on testnet but it is also quite troublesome.

[OverQuantum]

1) Real time list of blocks, including orphaned ones

I think, this could be also useful also estimating - how blocks to wait for considering transaction fixed in block chain.
Ex. if statistics shows, that one block is orphaned with 1% probability, 2 blocks with 0.01%, 3 blocks with 0.0001%, so it does not require to wait 4th block if you are not afraid of <0.0001% probability.

[Raulo]

I think, this could be also useful also estimating - how blocks to wait for considering transaction fixed in block chain.
Ex. if statistics shows, that one block is orphaned with 1% probability, 2 blocks with 0.01%, 3 blocks with 0.0001%, so it does not require to wait 4th block if you are not afraid of <0.0001% probability.

No, it won't. Currently orphaned blocks are accidental due to (almost) simultaneous finding a new block by two miners. Waiting for confirmations is to make sure there are no intentional chain splits. Intentional chain splits are possible with small probability even for an attacker that have <50% of hashspeed. And you won't know it until it's tried. If you have 10% of hashspeed, you will get  two blocks in a row with 1% probability. So you can reverse 1-confirmation transactions once in 100 blocks if you try. Current orphanage rate shown that nobody tried it yet but does not tell you how probable is that someone will try it.

[rezin777]

A different solution to this problem?

http://forum.bitcoin.org/index.php?topic=9137.0