Topic: checkpointing the block chain (Read 9485 times)

A strong enough of a node could do *anything*, the entire point of the proof-of-work is that as the bitcoin network grows, this kind of takeover becomes; if not really impossible, increasingly and astronomicly improbable.

So a very strong node could continuously reverse the last x blocks and only allow transactions which include a transaction fee over a certain amount, right?

Total proof-of-work.

The checksum is just the hash at a single particular block such that new chains can be started and can grow, but once a client with the checksum included reaches that block block number, it won't accept any hash except the checksum.

Is that correct?

So if someone wanted to create an alternative chain with the same genesis block, they would need to checksum a block after the genesis with a different hash before they connected to the live network. If they ever reached the checksum in the official client, they would need to make sure that checksum was not included in their own Bitcoin client.

How is the strength of the chain calculated? Is it length and checksum only or does it measure a single block at difficulty 500 as more valid than ten blocks at difficulty one? I presume that it's probably length and checksum only which would mean that all transactions before the checksum are pretty well safe forever, but blocks after the checksum are only as strong as the current strength of the network until the next checksum comes along.

Rather than reject it, it could save a backup of the original and accept the new chain tentitively if it's moving back more than, say, two weeks.  So about 2000 blocks.  And it could also notify the user that it has a new blockchain that reports a reversal of fortune so far back, and give the user the chance to find out about it before accepting the new blockchain.  Odds are that if the user doesn't know what is happening, he soon will since every other user paying attention at the time will also know there is something to look into.  Bitcoin is a very well automated system, but absolute automation is not often wise.  Talented support needs to know that something is broken asap.  This is another example of a 'watchdog' process and/or function that could add security to the network.  I think that, even though this should have been submitted to the test network, the release of this mal-formed transaction has highlighted an issue fairly early in the lifespan of Bitcoin.  Which allowed the small community to respond to it quickly and effectively.  This would become much harder to do in the future, if many people start using it, since most of them will not be programmers, and many won't be paing the level of attention to the client as the beta system currently needs.

Satoshi, the checkpoint is not used to make a judgement of which chain is better, but just to make sure that very old coins will not be invalidated in the "open" part of the network.

The software could just declare that there is a checkpoint 1000 blocks back. This is an individual checkpoint for each node, and the checkpoints would move forward every time a new block arrives. The checkpoint could never move backwards.

If a longer chain, predating the checkpoint arrived, the node would reject it. This would effectively fork the currency, but so what. In practice, it would just exclude the hidden
part. The "honest" part would continue along. Too bad for those with a long hidden chain. But they chose to be offline for too long.


The network, I see, is one of a lot of online nodes, visible to anyone who wants to see them. This is the core of the network. They will communicate so often, that no one will get 1000 blocks ahead of others. They will transmit their results continously, not collect them in a batch of 1000 blocks.

Then there are potential offline nodes, dishonest nodes etc. If they suddenly show up with a very long chain, there is no reason not to reject them. Or I don't see that reason.

The public internet will never get fragmented, in a major way,for days. And bitcoin is not suitable for such a situation, even though you technically can make it so by erasing all blocks in all but one of the fragmented components after the rejoin. 

You have a manual checkpoint, you say, which exactly shows that checkpoints are possible.

There is no way for the software to automatically know if one chain is better than another except by the greatest proof-of-work.  In the design it was necessary for it to switch to a longer chain no matter how far back it has to go.

The only exception to that is the manual checkpoints I've added.  If it weren't for those, it would be able to reorg all the way back to the first block.

What is a bad chain?

Could you elaborate more on why checkpoints are bad?


 

Under such a system, a bad chain (such as the one we fixed yesterday) would get locked in if it lasted more then 10 hours. I'm sorry, but automatic checkpoints are a bad idea.

You can say that, but it would be nice to use it on a smaller scale. It is interesting to think about how to achieve this without making the system too vulnerable.
Checkpoints could be one possibility. Maybe there are others.

1) The point of Bitcoin is to be a global currency, it doesn't make sense to use Bitcoin as a replacement for a national currency
2) Block chain checkpoints are already done at each release of the client software
3) To generate a longer chain from scratch doesn't require more power (CPU time) then the network currently has, it requires more power then the network has put into the chain since the start. The current chain has had unbelievable amounts of CPU time go into generating it.

These are simply good reasons for not starting your own little separate independent bitcoin chain. For the best security stay with the main big chain. Instances such as yesterday's should be so rare you don't need to worry about them. The problem of being out powered by some other big entity is well understood and is minimized by staying with the biggest bitcoin chain there is.

Note that the current bitcoin net is still tiny and you shouldn't really rely on it yet for anything serious in my opinion.

There is some checkpointing in the code that works like that. But it is not dynamic. It only updates when the dev team decides to add a new check point. But that does validate your point.

But I learned there are some addition protections as well but I haven't read that code yet. Something like refusing chains if they change more that X hours work. It probably worth reviewing other threads to find it. Knightmb was involved in that discussion if it helps to find it.

Hi

I think it is a problem that you can never really trust that the chain will not be massively invalidated, and replaced by a longer one.

This is an issue for all but the largest instances of bitcoin. A global widespread bitcoin system wouldn't have this issue, but anyone else would.

If a small country, say Luxembourg, started a bitcoin instance for  themselves, they would never know if the German or French government would be hiding a longer chain,
just in case.

If a large bank wanted to disturb the current bitcoin system, they could just spend more CPU power than the current system, start from scratch and generate a completely new chain. They could intervene at any point including the beginning. All work so far would be invalidated. 

If a village wanted a small local payment system, they would constantly be in danger of attacks. The mafia could execute a lot of double spending, and then suddenly arrive with a long chain that invalidated all their payments, even though the merchants thought they had acquired the coins.

Anyone, bar the largest most high powered instances of bitcoin, will have this constant threat hanging over them.

The issue appears with network splits as well. After rejoining, one part completely ruins the other part, especially for coins that were present on both sides of the split to start with.

I think, there should be some guarantee that the chain will not be invalidated further back in time than a day, a month, or 100 blocks or whatever.

This problem is related to the problem of how many blocks you want to see before accept a payment (double spending problem). Satoshi has a calculation of this in the
pdf file. However, you need to know the CPU power of the visible honest part relative to the other part (p and q). The problem is that you never know how large the dishonest, or invisible, part is, because it can be hidden as long it wants to. Or it can be formed in the future. You never know.

What about this proposal? A node checkpoints blocks that are older than some threshold. The threshold could be a difficulty weighted block count, say a 100 blocks of 8 zero
bits. If a node receives a block chain that requires changing something that is older than its checkpoint, it refuses the chain. Each node would have its own checkpoint. But the honest nodes would be close. Their deviation would be small compared to the size of the threshold (100 blocks).

What would happen when two nodes disagree further back in time than the threshold of one of them. They should be considered forked currencies. One currency became two.
So the village, or Luxembourg, could ignore a hidden outside world, except for the very last part of the block chain.

The small village could use a very low threshold. The latency within the village is milliseconds. The could have block generation every 10 seconds. They could have a threshold of 5 blocks for instance. There is no valid reason, for a node, to stay hidden for that long in the village. If a computer loses its connection, it will just download the chain when it get online again; if it will tries to push a long block chain down the throat of the rest of the village, it has effectively created a new currency for itself.