Pages:
Author

Topic: [BOUNTY] Bitcoin blockchain monitoring site - page 2. (Read 8370 times)

full member
Activity: 238
Merit: 100
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.

Quote
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.
sr. member
Activity: 392
Merit: 250
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.
sr. member
Activity: 292
Merit: 250
I agree that this information should be freely available to the public.
legendary
Activity: 3640
Merit: 1345
Armory Developer
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.
member
Activity: 98
Merit: 10
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.
newbie
Activity: 31
Merit: 0
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?
member
Activity: 98
Merit: 10
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.
member
Activity: 98
Merit: 10
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.
newbie
Activity: 31
Merit: 0
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.
member
Activity: 98
Merit: 10
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).
hero member
Activity: 672
Merit: 500
BitLotto - best odds + best payouts + cheat-proof
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.

member
Activity: 98
Merit: 10
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.
full member
Activity: 281
Merit: 100
+5 btc
hero member
Activity: 499
Merit: 500
I'll pledge 5 BTC.
hero member
Activity: 742
Merit: 500
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
Pages:
Jump to: