Limits to accepting a new longest chain to prevent >50%

[roalwe]

Personally, I am not convinced it is needed.

There was so far... about 2 "emergencies" with the blockchain (that "generate a lot of bitcoins" bug, and the doublespend in the recent fork) none of which were exploited by a real malicious party.

As far as I can tell, many major banks have a less stelar record.

It doesn't seem to me that bitcoin's "the hashiest chain wins" approach is "broken", so maybe we should refrain from "fixing" it.

[1714957325]

1714957325

[1714957325]

1714957325

[1714957325]

1714957325

[1714957325]

1714957325

[CIYAM]

I do agree that we haven't seen such a threat - but it always is a nagging concern (damn it Satoshi are you sure you got it right?).

[roalwe]

I do agree that we haven't seen such a threat - but it always is a nagging concern (damn it Satoshi are you sure you got it right?).

Unless you run a bitcoin service with aspirations to eventual greatness (which  I do ), doublespends that require immense hashrates should not be a concern for you at all (unless you happen to be good at making enemies among major pool operators )

[TierNolan]

It doesn't seem to me that bitcoin's "the hashiest chain wins" approach is "broken", so maybe we should refrain from "fixing" it.

I think the main point is that no scheme can prevent a complete reversal from the genesis block.  If you have 2 chains that fork at the genesis block, then you can only compare the total POW.

However, if they fork at a later point, you could use something like proof of stake. or burn or whatever.  Only stakes from before the fork would count though.

If the coin value before the fork is distributed, then this distributed checkpointing.

[roalwe]

Errr. I thought dev-hardcoded checkpoints prevent a complete reversal even in the face of stupidly overwhelming adversary...

[TierNolan]

Errr. I thought dev-hardcoded checkpoints prevent a complete reversal even in the face of stupidly overwhelming adversary...

Yes, I mean if you didn't want central checkpointing.

[kjj]

Personally, I am not convinced it is needed.

There was so far... about 2 "emergencies" with the blockchain (that "generate a lot of bitcoins" bug, and the doublespend in the recent fork) none of which were exploited by a real malicious party.

As far as I can tell, many major banks have a less stelar record.

It doesn't seem to me that bitcoin's "the hashiest chain wins" approach is "broken", so maybe we should refrain from "fixing" it.

My issue was always that I didn't like the idea of a hidden chain attack.  If someone has a bunch of hashing power (very unlikely) and generates a chain offline, then publishes it, overturning a huge number of blocks, we pretty much just have to sit and watch.  Of course, we can then intervene after the fact to put it back.

But it seems like a better way would be to devise a scheme where the attacker would be unable to keep their longer chain secret.  That is why I like the exponential difficulty method.  Under ordinary circumstances, and even honest chain forks, the network would operate as usual.  But a high powered attacker is fighting against the clock, and people can look at the number of blocks protecting their transaction, calculate the exponential, and evaluate the risk with something more closely approaching certainty.

The cost is, however, that the notion of correctness gets a little fuzzy.  I still think that it is better to protect the network as a whole, in exchange for individual nodes needing manual intervention during some attacks.  Gmaxwell gives the opposing view, which is widely shared.  It is a really critical part of bitcoin, and won't be tweaked lightly, if ever.

[TierNolan]

What about just defining a fork more than 10k blocks from the main chain as just that, a fork.  Have the client consider both alt chains and tell the user he needs to check the internet as to which one the community considers the real one.

[gmaxwell]

What about just defining a fork more than 10k blocks from the main chain as just that, a fork.  Have the client consider both alt chains and tell the user he needs to check the internet as to which one the community considers the real one.

So, how do you prevent that from basically being the same as "everyone flip a coin?", I'm not sure what kind of guidance you could usefully give there.

I might, with enough effort and thinking into how you do something useful with the instructions there be convinced that there could be something useful along those lines— or at least, no more harmful than any other rearrangement of the titanic's deckchairs— but then there is the issue of if someone has enough computing power to create a 10k reorg, the could constantly reorg 9999 blocks over and and over again.  "This isn't any better".

If it really is only a matter of picking which color tie the corpse of Bitcoin will wear— well the software to implement anything like that itself has a cost (size, review bandwidth, vulnerability surface)— and I can't get too excited about something costly that doesn't make a real improvement. And I also think thats a general issue for these sorts of last-resort thing: if they're only attractive in a already doomed outcome its hard to justify their cost.

[TierNolan]

So, how do you prevent that from basically being the same as "everyone flip a coin?", I'm not sure what kind of guidance you could usefully give there.

"Everyone" would know which is the real chain.  It is saying that the rule in that case is that it requires manual discussion.  

You need to go to forums etc to say which is the "real" chain.

I might, with enough effort and thinking into how you do something useful with the instructions there be convinced that there could be something useful along those lines— or at least, no more harmful than any other rearrangement of the titanic's deckchairs— but then there is the issue of if someone has enough computing power to create a 10k reorg, the could constantly reorg 9999 blocks over and and over again.  "This isn't any better".

Maybe they are willing to do it once, but not over and over.  In fact, maybe even 10k is to high, perhaps the node could auto-checkpoint all blocks that are at least 24 hours old.

A 24 hour reversal inherently requires manual intervention.

You connect daily and your client tells you a reversal has happened and manual intervention is required.

95% of users would be on the historical chain.  The reversal would have to be short to not trigger the warning.