The key aspect of this strategy is relaxing the requirement for a flag to commit to a completely valid block, instead only requiring a valid block header. Miners can start mining a flag as soon as they have a valid block header and can choose to continue or abandon mining the flag if spam is detected. The distribution of hashpower between the flag and mining for a valid block should reflect miners' estimation of the cost of negative outcomes. This approach effectively neutralizes the harm caused by the attack and incorporates the work done to produce the spam into the blockchain's cumulative Proof of Work, without rewarding the spammer.The author of the proposal has created a repository for sync_flags and made some changes to it, which can be found in the repo. The author's main idea is to enhance mining decentralization by having all miners start hashing the next block simultaneously. This synchronization can be achieved through the use of sync flags, which are messages consisting of a hash of the previous block, a bitcoin address, and a nonce. Miners wait for the flag, and when it spreads through the network, they can begin hashing the next block together. To fund this proof of work, the protocol is modified to require that the block produced 10 blocks after the sync flag allocate 25% of the block reward to the address specified by the flag. Sync flags offer several advantages over optimistic mining. They reduce variance in mining profitability, eliminate SPV mined blocks and empty blocks, smooth out resource usage, alleviate the latency bottleneck on throughput, make transaction stuffing by miners either obvious or costly, and give miners a task while waiting for attractive transactions. The author addresses concerns about selfish mining, invalid block spam, payout compatibility with certain mining pools, and the impact of mandatory empty blocks on sync flags. By mining a sync flag instead, the use of Bitcoin miners for destabilizing purposes can be avoided. This approach would put miners to profitable work while they wait and create a more efficient price discovery mechanism for transactions. Transactions with high fees would have time to enter the marketplace, rather than being taken quickly because all the desirable transactions were included in the previous block. Implementing sync flags through a soft fork is feasible, although a hard fork would be more efficient. The proposed implementation requires that every block includes a transaction allocating 25% of the block reward to the address provided by the 10th previous sync flag and commits to the hash of the 1st previous sync flag.Moral Agent proposed a solution to enhance mining decentralization and reduce variance in mining profitability. The idea involves using a sync flag as a message that propagates at maximum speed through the network, triggering all miners to simultaneously start hashing the next block. The sync flag is composed of the hash of the previous block, a Bitcoin address, and a nonce. To ensure the implementation of this idea, the protocol is adjusted to mandate that the block produced 10 blocks after the sync flag allocates 25% of the block reward to the address specified by the flag. This proposal brings various benefits such as eliminating SPV mined blocks and empty blocks, reducing latency bottlenecks, making transaction stuffing costly or obvious, and providing miners with an activity while waiting for attractive transactions. A soft fork can easily implement sync flags. However, the current payout structure of non hot-wallet pools and decentralized pools may not be compatible with mining the sync flag. Instead of specifying an address for funds, including the hash of the transaction allowed to spend the sync flag output could be an alternative.In a bitcoin-dev mailing list discussion, Martijn Meijering questioned whether selfish mining of sync flags would be more likely compared to ordinary blocks. A proposal was suggested to achieve the same result as adding mandatory empty blocks by targeting Proof-of-Work (PoW) at 2 minutes to produce a flag every 2 minutes and a block every 8 minutes. The conversion rate from hashing power to reward would be the same for both flags and blocks. However, a soft fork implementing this rule would divert 20% of its hashing power to flag blocks, which legacy nodes would ignore. To win the race, the soft fork would require 55% of the hashing power. Consequently, headers-first clients would need to download more information to verify the longest chain as they would miss 20% of the PoW if they only downloaded headers.The concept of selfish mining of sync flags is introduced, where miners may selfishly mine flags and withhold them until the benefit gained from withholding is less than the mining reward. This practice could undermine decentralization, favoring only big miners capable of engaging in selfish mining. It may also encourage collusion among miners, resulting in flags being shipped only to miners with established business relationships, thereby reducing flag revenue and providing an advantage to in-group miners in main-chain mining.The idea of using a sync flag to ensure