1. BIP8 uses blockheight, as opposed to timestamp. This is so that the fork can still go ahead if:

• an activation is at the "locked-in" stage (i.e. block signalling is above the threshold)
• ...but the _overall_ hashrate is falling (i.e. the necessary 2016 blocks of lock-in won't occur before the timestamp when the 12 month activation period expires)

BIP8 solves that problem by not using 12 timestamped months, but 12 months of blocks (which comes with a different trade-off: it's unlikely to be 12 actual months, and for the taproot softfork, will likely be faster, due to continuing hashrate growth). The 12 months part is just a convention, it could've been more or less (and may be in future), I think 12 was chosen simply because the segwit and CSV softforks also aloted 12 months)

2. BIP8 has a "lock-in on timeout" parameter

This means that the fork activates regardless of miner signalling level at the point the activation period expires (12 months in this case).


The continuing discussion on activation for the taproot fork revolves around whether Bitcoin 0.21.1 should be released with auto lock-in (or "LOT") set as true or false, but also whether LOT can be set as user configurable (like an enforcing version of people putting "uasf" in their user agent string during segwit activation). IMO, 0.21.1 should be shipped with LOT=true, but I understand the arguments against also. At the least, it should be possible to set in the config file.