| > Then I run my own hard fork which awards 10X block rewards to all blocks produced by me. Since your blocks violate my and everyone else's nodes' block validation rules, which among other things stipulate a fixed minting schedule (which you did not adhere to), your blocks are never accepted -- they are treated as invalid and dropped. QED your attack fails. I honestly thought you knew better before I saw your reply. > I post my forked code on github and tell everybody it's an upgrade. Since I'm intending to install "Bitcoin," it is a reasonable assumption that I know what "Bitcoin" is. So, it's possible for me to read your code, and determine that it is, in fact, not Bitcoin, because it does not have the same minting schedule. Note that knowing that the software I'm running adheres to the rules that make up "Bitcoin" is sufficient for me to bootstrap my node and validate the Bitcoin chain, assuming I am able to connect any/all public Bitcoin nodes (regardless of which fork they see). Even if I join the network while the network is partitioned, my node will eventually determine which of the partitions' forks is the canonical fork all by itself, because the rules of Bitcoin stipulate that the valid chainstate with the highest cumulative PoW is the canonical fork. However, this is not sufficient for PoS, because in PoS, someone must also tell me out of band which fork is the canonical PoS chain, should the network ever partition into two competing networks. This is because there is no way to examine the chainstate itself and determine which conflicting PoS fork is the canonical fork, even if I can reach all public PoS nodes for all forks. Each partition can plausibly claim that the other fork was rightfully slashed for being offline for a time before my node joined. Because I didn't personally see the offline behavior, I have no way of knowing which partition to trust, if any -- someone who was there to see it must tell me. That's "weak subjectivity" for you. |