Share database blocks ?

I have a question.
I saw that everyone need to get blocks before starting to get coins.
Does it mean that these blocks are the same for everyone?
Is there a database with all of them?
So ... can I share this database with someone else to make him able to generate coins after few seconds?
I'm not sure if I have understood correctly how everything works
If I'm right ... can we share an always updated database of blocks somewhere on the official website?

I think that probably they won't be accepted by the majority of the network, that they have a different database/hash ... is it right?

While a central database, or at least a partially-completed centralized copy of a certain number of blocks would speed things up, but then, so would mass-transfer between clients (requests for 500 blocks or so instead of one blocks at a time) and the latter would implement it within the confines of the network, without needing web hosting for a copy of the block database.

Currently, I believe one could grab a copy of someone else's blk*.dat files and speed the process up that way, but it really shouldn't be needed when the same thing can be done with a few snippets of code.

A draft standard for the bitcoin wire protocol would possibly be a help here, in that it would be possible for someone C++-illiterate to see what actually is possible in the current system ;-)

EDIT: if I understand correctly, a complete false start that wouldn't disappear as soon as a client connected to the network at large would require generating as many blocks as were currently in the network, so, one individual would have to generate 57525 blocks to do major harm to the network.

It could give someone a head start in forging a block, but not really. Having a rouge starter set of blocks would be just like having each new node started from that set of blocks be a rouge node, so it should be similarly impractical to forge anything.

Good idea, but we would need some form of indicator it did that to the user, and warn the user about the potential hazards.
(Atleast, that's my idea.)

Although I'm not familiar with the specifics of the algorithm implementation in C++, I am familiar with how the verification works in general. Although the algorithm would have to be re-written, it really should be possible to verify blocks in both directions at the same time. Each block contains the hash of the previous block, but the first block contains a genesis hash, which isn't the hash of a previous block. The first time bitcoins starts, it would treat a recent hash, perhaps a one day old hash as a temporary genesis hash and quickly verify the roughly 144 blocks up to the most recent block and it would continue to verify and optionally generate new hashes. Another thread would grab a previous hash, perhaps a two day old hash and treat it as the new temporary genesis hash. It would quickly verify the roughly 144 blocks, and verify that the last hash matches the previous genesis hash. The second thread would continue verifying previous blocks until it reached the real genesis block, which I believe is defined within Bitcoin itself. As you can see, blocks are always being verified in forward direction, but the beginning point is just pushed back until it reaches the real beginning. There could even be a third thread which would start at the real genesis hash and verify blocks from there so that they meet in the middle. All three of those threads could be grouped into another thread which would be run for each different chain of blocks which it is told about from other Bitcoin peers. If more than one chain is verified as authentic, Bitcoin would calculate and compare the total amount of computing power required to create the chain and keep only the strongest chain. Off the top of my head, an easy way to calculate the strongest chain, would be to find the largest sum of the inverses of the numeric value of each hash.