Hi @andablackwidow very good remarks. It very interesting you reach to this conclusions because they are not easy to figure out. Some time ago I also warned to the team about some of these points so they decided to make some updates in the contract to prevent these situations.

Let me expand the mechanism of the PoB consensus algorithm implemented in Koinos:

1. I mentioned previous hash, public key, and timestamp. However, it is not quite accurate. The computation of the hash uses: previous hash, "private key" of the miner, and timestamp. And the verification of the hash uses: previous hash, public key, and timestamp. So you need the private key for the creation, and public key for the verification.

2. The hash do not depend on the content of the block, only the 3 values I mentioned above. Meaning that if the miner includes different transactions in the block (trying to simulate a "nonce" with them) it will not influence the hash.

3. The hash is not the block id. The hash is part of the signature (read more about Veriable Random Function - VRF). As I said, it is calculated from previous hash, private key, and timestamp. That "previous hash" refers to the hash present in the signature of the previous block. This means that if the miner wants to compute future hashes he needs to know the "previous hash" of these future hashes, and they are computed from the private key. In conclusion, the miner needs to know the private key of the future producers.

4. If you transfer VHP from one account to another you have to wait 20 blocks before this VHP becomes "active" in the new account. This means that if the miner moves the VHP between different accounts to compute billions of potential addresses this will be not possible because the new addresses will have 0 VHP at that point in time. They have to wait 20 blocks, making impossible to perform this attack.

5. The contract also requires the registration of the public key of the producer. And this registration also takes 20 blocks to become "active". This is to prevent a similar attack where the miner computes billions of potential addresses and then registers in the contract the most convenient public key. So, again, this is not possible.

I hope this can clarify your questions.