[Tycho] (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/lamp.gif) |
May 08, 2011, 09:50:09 PM |
|
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
|
Welcome to my bitcoin mining pool: https://deepbit.net - Both payment schemes (including PPS), instant payout, no invalid blocks ! ICBIT Trading platform : USD/BTC futures trading, Bitcoin difficulty futures ( NEW!). Third year in bitcoin business.
|
|
|
Miner-TE
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2011, 09:54:57 PM |
|
I'll pledge 5 BTC.
|
BTC - 1PeMMYGn7xbZjUYeaWe9ct1VV6szLS1vkD - LTC - LbtcJRJJQQBjZuHr6Wm7vtB9RnnWtRNYpq
|
|
|
|
Veldy
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 98
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 09, 2011, 01:01:57 AM |
|
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.
|
If you have found my post helpful, please donate what you feel it is worth: 18vaZ4K62WiL6W2Qoj9AE1cerfCHRaUW4x
|
|
|
bitlotto
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 09, 2011, 01:05:35 AM |
|
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.
|
*Next Draw Feb 1* BitLotto: monthly raffle (0.25 BTC per ticket) Completely transparent and impossible to manipulate who wins. TOR TOR2WEB Donations to: 1JQdiQsjhV2uJ4Y8HFtdqteJsZhv835a8J are appreciated.
|
|
|
Veldy
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 98
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 09, 2011, 01:25:53 AM |
|
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).
|
If you have found my post helpful, please donate what you feel it is worth: 18vaZ4K62WiL6W2Qoj9AE1cerfCHRaUW4x
|
|
|
Ulysses
Newbie
Offline
Activity: 31
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 09, 2011, 02:30:37 AM |
|
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
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 98
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 09, 2011, 02:38:19 AM |
|
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.
|
If you have found my post helpful, please donate what you feel it is worth: 18vaZ4K62WiL6W2Qoj9AE1cerfCHRaUW4x
|
|
|
Veldy
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 98
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 09, 2011, 02:44:23 AM |
|
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.
|
If you have found my post helpful, please donate what you feel it is worth: 18vaZ4K62WiL6W2Qoj9AE1cerfCHRaUW4x
|
|
|
Ulysses
Newbie
Offline
Activity: 31
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 09, 2011, 03:05:41 AM |
|
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
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 98
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 09, 2011, 03:09:55 AM |
|
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.
|
If you have found my post helpful, please donate what you feel it is worth: 18vaZ4K62WiL6W2Qoj9AE1cerfCHRaUW4x
|
|
|
goatpig
Legendary
Offline
Activity: 3724
Merit: 1360
Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 09, 2011, 03:13:11 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 09, 2011, 03:28:29 AM |
|
I agree that this information should be freely available to the public.
|
Don't use BIPS!
|
|
|
grndzero
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 09, 2011, 04:01:54 AM |
|
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.
|
Ubuntu Desktop x64 - HD5850 Reference - 400Mh/s w/ cgminer @ 975C/325M/1.175V - 11.6/2.1 SDK Donate if you find this helpful: 1NimouHg2acbXNfMt5waJ7ohKs2TtYHePy
|
|
|
Raulo
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 09, 2011, 10:43:51 AM |
|
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.
|
1HAoJag4C3XtAmQJAhE9FTAAJWFcrvpdLM
|
|
|
grndzero
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 09, 2011, 10:58:52 AM |
|
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?
|
Ubuntu Desktop x64 - HD5850 Reference - 400Mh/s w/ cgminer @ 975C/325M/1.175V - 11.6/2.1 SDK Donate if you find this helpful: 1NimouHg2acbXNfMt5waJ7ohKs2TtYHePy
|
|
|
Raulo
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 09, 2011, 11:36:07 AM |
|
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.
|
1HAoJag4C3XtAmQJAhE9FTAAJWFcrvpdLM
|
|
|
OverQuantum
Newbie
Offline
Activity: 4
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 18, 2011, 06:49:29 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 19, 2011, 06:54:15 AM |
|
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.
|
1HAoJag4C3XtAmQJAhE9FTAAJWFcrvpdLM
|
|
|
|
|