Longest orphaned block chain?

[Furyan]

I thought someone posted a thread with this question a few days ago, but now I can't find it.

Anyway I'm curious if anyone knows what the longest orphaned block chain has been, historically.  And on average, how long an orphan block chain will typically be before that client detects the correct longest chain and does a re-org.

I ask because I was going through the blocks that my bitcoin instance had been reporting and discovered that several of them were orphans, but had already been re-org'd with the correct block.  So it made me curious.

Anyone?

[kjj]

It is really hard to say, but I would think the longest widespread fork was 2 blocks, but a tiny minority of nodes may have seen local forks of 3, or maybe even 4 blocks.

Blockexplorer is showing 25 reorgs since block # 129453, or roughly one reorg per 667 blocks.  Any given node will, on average, see half of all forks as reorgs, so forks will be roughly twice as common as what you'd see from any one node.  This is pretty well in line with my earlier estimates of one fork per 300 blocks.

If the real rate of widespread single block forks is 1 in 300, we can expect one every other day.  Widespread double block forks would then be about 1 in 90000, or every 1.75 years or so.  Widespread triples would be every 27,000,000 blocks, or twice per millennium.

By the way, I keep putting widespread in italics because it is important.

[Furyan]

By the way, I keep putting widespread in italics because it is important.

Good point - my original question was really about widespread forks.

I ask because I'm looking at ways to modify our pool's payout algorithm to allow almost-immediate payout (we can't afford to eat the cost of orphaned blocks the way Deepbit does) while minimizing our risk.  Seems like after 5 confirms or so we'd be reasonably certain the block would pay out so we can release the funds for it.  Do you think that's a bad conclusion to draw?  I know the network enforces a 120-confirm limit on generated coins but I wonder how overkill that is.

[kjj]

By the way, I keep putting widespread in italics because it is important.

Good point - my original question was really about widespread forks.

I ask because I'm looking at ways to modify our pool's payout algorithm to allow almost-immediate payout (we can't afford to eat the cost of orphaned blocks the way Deepbit does) while minimizing our risk.  Seems like after 5 confirms or so we'd be reasonably certain the block would pay out so we can release the funds for it.

I would expect 5 to be fine, but I would go with at least 6 anyway.  Remember that your node is the source of forks, not the recipient.

[iamzill]

By the way, I keep putting widespread in italics because it is important.

Good point - my original question was really about widespread forks.

I ask because I'm looking at ways to modify our pool's payout algorithm to allow almost-immediate payout (we can't afford to eat the cost of orphaned blocks the way Deepbit does) while minimizing our risk.  Seems like after 5 confirms or so we'd be reasonably certain the block would pay out so we can release the funds for it.  Do you think that's a bad conclusion to draw?  I know the network enforces a 120-confirm limit on generated coins but I wonder how overkill that is.

Please keep in mind that this is exactly the same "optimization" mybitcoin used, except they used 1 instead of 5.

[ribuck]

Surely the longest orphaned block chain occurred last year when the overflow bug was detected, and a new version of Bitcoin was rapidly released. Many people didn't upgrade immediately, and their now-orphaned branch of the chain kept growing.

I was away on vacation at the time, and had left my Bitcoin client running. It was happily generating useless blocks, on a block chain that had become worthless because it had less than 50% of the hashing power.

I don't know how big the orphaned chain grew, but certainly it was still going after hundreds of blocks.

More relevant though, is that it took about nine hours before the bug-free version of Bitcoin, and the chain that it generated, reached more than 50% of the hashing power.

[sadpandatech]

By the way, I keep putting widespread in italics because it is important.

Good point - my original question was really about widespread forks.

I ask because I'm looking at ways to modify our pool's payout algorithm to allow almost-immediate payout (we can't afford to eat the cost of orphaned blocks the way Deepbit does) while minimizing our risk.  Seems like after 5 confirms or so we'd be reasonably certain the block would pay out so we can release the funds for it.  Do you think that's a bad conclusion to draw?  I know the network enforces a 120-confirm limit on generated coins but I wonder how overkill that is.

Please keep in mind that this is exactly the same "optimization" mybitcoin used, except they used 1 instead of 5.

How the fuck is that even close to 'exactly'....  If I read one more fucking fud comment about mybitcoin '1 confirm' trying to spread more misinfo about how they were ripped off in that manner I am going to fucking puke. (and yes, I'm-mad-bro) p.s. accepting offers to do the foot work to track down the scums responsible.(within legal means) Some of us Americans are scary muther fuggers too...........


Now, as to the point, 6 would be a much safer bet. ;p

[iamzill]

By the way, I keep putting widespread in italics because it is important.

Good point - my original question was really about widespread forks.

I ask because I'm looking at ways to modify our pool's payout algorithm to allow almost-immediate payout (we can't afford to eat the cost of orphaned blocks the way Deepbit does) while minimizing our risk.  Seems like after 5 confirms or so we'd be reasonably certain the block would pay out so we can release the funds for it.  Do you think that's a bad conclusion to draw?  I know the network enforces a 120-confirm limit on generated coins but I wonder how overkill that is.

Please keep in mind that this is exactly the same "optimization" mybitcoin used, except they used 1 instead of 5.

How the fuck is that even close to 'exactly'....  If I read one more fucking fud comment about mybitcoin '1 confirm' trying to spread more misinfo about how they were ripped off in that manner I am going to fucking puke. (and yes, I'm-mad-bro) p.s. accepting offers to do the foot work to track down the scums responsible.(within legal means) Some of us Americans are scary muther fuggers too...........


Now, as to the point, 6 would be a much safer bet. ;p

mybitcoin only waited for 1 confirms. This is a fact. I'm sorry if you think it's FUD, but a fact is still a fact.

[kjj]

Surely the longest orphaned block chain occurred last year when the overflow bug was detected, and a new version of Bitcoin was rapidly released. Many people didn't upgrade immediately, and their now-orphaned branch of the chain kept growing.

I was away on vacation at the time, and had left my Bitcoin client running. It was happily generating useless blocks, on a block chain that had become worthless because it had less than 50% of the hashing power.

I don't know how big the orphaned chain grew, but certainly it was still going after hundreds of blocks.

More relevant though, is that it took about nine hours before the bug-free version of Bitcoin, and the chain that it generated, reached more than 50% of the hashing power.

I categorize forks into normal and abnormal.  If it wasn't clear before, my comments are only about normal forks that happen naturally because of network latency.

Because abnormal forks are, well, abnormal, I don't think there is any way to do a meaningful analysis of them.

[kjj]

mybitcoin only waited for 1 confirms. This is a fact. I'm sorry if you think it's FUD, but a fact is still a fact.

Things don't become facts just because people say them, not even if they say them often and emphatically.  And the 1 confirmation story has been questioned because no evidence to support it has ever been found.  Read this post I made a week ago (below), then go look at the block forwarding mechanisms in the code.

I don't buy his story at all, at least not the version I heard.  Here's why.  Nodes forward valid blocks.  This is obviously true in the window between accepting the block and having it overturned, but it is also true after a new longest chain has been accepted.  Hell, it is even true if the blocks are stale at the time they are received, if I recall correctly from reading the code a while back.

If his node had been fed blocks that were later overturned, his node would have shared those, and they would have spread across the entire network, meaning that we'd all have copies of them.  Certain people that have a keen interest in the block chain, like Theymos, would have noticed proof of a spend redirection attack in the wild and would have announced it widely.  I gave up on reading the crap sloshing around in the mybitcoin threads, so I might have missed it, but I'm pretty sure that I would have come across it eventually if it had been announced.

I don't necessarily think that he stole the coins, but I'm pretty sure the attack did not come through the bitcoin side of things, even if he really did count deposits after a single confirmation.

If there really had been a spend redirection attack done against mybitcoin, there would be ample evidence for it, and so far no one has presented any.  The only way for there to have been an actual attack, and no evidence found is if the attacker was able to totally isolate his node by taking full control of his network connection for several days, and faking all bitcoin traffic to it for the entire duration, all without anyone noticing.

And even then I'm not sure it could be done cleanly, because when the attacker had to transfer out, he would need to force mybitcoin's node to create outgoing transactions that didn't use any of the fake incoming transactions as inputs.

[iamzill]

mybitcoin only waited for 1 confirms. This is a fact. I'm sorry if you think it's FUD, but a fact is still a fact.

Things don't become facts just because people say them, not even if they say them often and emphatically.  And the 1 confirmation story has been questioned because no evidence to support it has ever been found.  Read this post I made a week ago (below), then go look at the block forwarding mechanisms in the code.

I don't buy his story at all, at least not the version I heard.  Here's why.  Nodes forward valid blocks.  This is obviously true in the window between accepting the block and having it overturned, but it is also true after a new longest chain has been accepted.  Hell, it is even true if the blocks are stale at the time they are received, if I recall correctly from reading the code a while back.

If his node had been fed blocks that were later overturned, his node would have shared those, and they would have spread across the entire network, meaning that we'd all have copies of them.  Certain people that have a keen interest in the block chain, like Theymos, would have noticed proof of a spend redirection attack in the wild and would have announced it widely.  I gave up on reading the crap sloshing around in the mybitcoin threads, so I might have missed it, but I'm pretty sure that I would have come across it eventually if it had been announced.

I don't necessarily think that he stole the coins, but I'm pretty sure the attack did not come through the bitcoin side of things, even if he really did count deposits after a single confirmation.

If there really had been a spend redirection attack done against mybitcoin, there would be ample evidence for it, and so far no one has presented any.  The only way for there to have been an actual attack, and no evidence found is if the attacker was able to totally isolate his node by taking full control of his network connection for several days, and faking all bitcoin traffic to it for the entire duration, all without anyone noticing.

And even then I'm not sure it could be done cleanly, because when the attacker had to transfer out, he would need to force mybitcoin's node to create outgoing transactions that didn't use any of the fake incoming transactions as inputs.

You seem to have misunderstood me. I'll list out my personal understanding of the mybitcoin attack in chronological order:
1. mybitcoin accepts deposits after only 1 confirm. This is an intentional design flaw.
2. A few people point out this security flaw, but it largely goes unnoticed.
3. mybitcoin goes down for a week. People starts worrying and seeks explanations. This security flaw gets brought up again and most people accept the explanation with no evidence that it actually happened.
4. Tom Williams comes back, claims there's been a security breach, apologizes profusely, and offers to return half of the coins.
5. Tom Williams walks away with the other half of the coins.

If you disagree with any of the above assertions, feel free to bring it up. But I have ample evidence to back up all of my claims.



Suppose Bob wants to open a new Bitcoin service. He claims he wants to speed up the processing times so he only waits for N confirmations, where N<6. In the end he can always just say "I'm so sorry guys, I thought this attack only had a 0.0000001% chance of success, but somehow the attackers made it happen. I'm will return whatever coins are remaining." and walk away with the rest of the coins. Most people won't buy this of course, but even if just 10% of the people buys this excuse, that's 10% less people with pitchforks after Bob.

Wouldn't it be far safer if Bob just N=6 like he's supposed to?

[kjj]

You seem to have misunderstood me. I'll list out my personal understanding of the mybitcoin attack in chronological order:
1. mybitcoin accepts deposits after only 1 confirm. This is an intentional design flaw.
2. A few people point out this security flaw, but it largely goes unnoticed.
3. mybitcoin goes down for a week. People starts worrying and seeks explanations. This security flaw gets brought up again and most people accept the explanation with no evidence that it actually happened.
4. Tom Williams comes back, claims there's been a security breach, apologizes profusely, and offers to return half of the coins.
5. Tom Williams walks away with the other half of the coins.

If you disagree with any of the above assertions, feel free to bring it up. But I have ample evidence to back up all of my claims.

Suppose Bob wants to open a new Bitcoin service. He claims he wants to speed up the processing times so he only waits for N confirmations, where N<6. In the end he can always just say "I'm so sorry guys, I thought this attack only had a 0.0000001% chance of success, but somehow the attackers made it happen. I'm will return whatever coins are remaining." and walk away with the rest of the coins. Most people won't buy this of course, but even if just 10% of the people buys this excuse, that's 10% less people with pitchforks after Bob.

Wouldn't it be far safer if Bob just N=6 like he's supposed to?

Ahh, I understand where you are coming from now.

Personally, I think your theory is nutty, for various reasons.  Just one reason is that I haven't seen any evidence of #5, or for the intentionality of #1.  For what it's worth, I don't really care either, so don't bother presenting whatever you have, unless it would satisfy some very high standards of evidence.

At any rate, your scenario doesn't apply here, because Furyan is looking for a way to pay his miners faster than the commonly accepted 120 block coinbase delay.  That is, he is looking to reduce the amount of trust that people need to have in him, not increase it.

[iamzill]

You seem to have misunderstood me. I'll list out my personal understanding of the mybitcoin attack in chronological order:
1. mybitcoin accepts deposits after only 1 confirm. This is an intentional design flaw.
2. A few people point out this security flaw, but it largely goes unnoticed.
3. mybitcoin goes down for a week. People starts worrying and seeks explanations. This security flaw gets brought up again and most people accept the explanation with no evidence that it actually happened.
4. Tom Williams comes back, claims there's been a security breach, apologizes profusely, and offers to return half of the coins.
5. Tom Williams walks away with the other half of the coins.

If you disagree with any of the above assertions, feel free to bring it up. But I have ample evidence to back up all of my claims.

Suppose Bob wants to open a new Bitcoin service. He claims he wants to speed up the processing times so he only waits for N confirmations, where N<6. In the end he can always just say "I'm so sorry guys, I thought this attack only had a 0.0000001% chance of success, but somehow the attackers made it happen. I'm will return whatever coins are remaining." and walk away with the rest of the coins. Most people won't buy this of course, but even if just 10% of the people buys this excuse, that's 10% less people with pitchforks after Bob.

Wouldn't it be far safer if Bob just N=6 like he's supposed to?

Ahh, I understand where you are coming from now.

Personally, I think your theory is nutty, for various reasons.  Just one reason is that I haven't seen any evidence of #5, or for the intentionality of #1.  For what it's worth, I don't really care either, so don't bother presenting whatever you have, unless it would satisfy some very high standards of evidence.

At any rate, your scenario doesn't apply here, because Furyan is looking for a way to pay his miners faster than the commonly accepted 120 block coinbase delay.  That is, he is looking to reduce the amount of trust that people need to have in him, not increase it.

I think we can both agree that not everyone got 100% of their money back, so there are still some coins missing.
I think we can both agree that there's no evidence for a double-spend attack on the hashchain, so no "hacker" could have taken the money.

If Tom Williams didn't take those coins, where are they now?

Note that Tom Williams is just a pseudonym. I used Tom Williams to denote whoever successfully perpetrated this social-engineering attack.

[kjj]

I think we can both agree that not everyone got 100% of their money back, so there are still some coins missing.
I think we can both agree that there's no evidence for a double-spend attack on the hashchain, so no "hacker" could have taken the money.

You seem to be forgetting all of the other ways to attack a website that don't involve bitcoin.

If we assume that the attacker ignored all of the eleventy billion ways to mess with a website and instead concentrated only on the cryptographically strong system that spreads evidence worldwide in a matter of seconds, then yes, I think it is pretty safe to conclude that the attacker was Tom.

If, however, the attacker was allowed to attack something other than the strongest link in the chain, then we don't really have any idea what happened.

You want to believe that mybitcoin was built to steal by a diabolical mastermind with a planning horizon of more than a year.  I think it far more likely that it was just run by a guy that didn't ever expect his website to be as tempting as it eventually became when bitcoins got to be worth several dollars each.

Keep in mind that the single confirm assumption totally makes sense at a time when bitcoins were nearly worthless and that humans are incredibly bad at assessing risk, particularly when we get away with something risky the first few times.  As an example, both Challenger and Columbia were both lost to problems that were known in advance, but not properly addressed because they didn't cause catastrophic failures on the previous launches.