It's NEVER a "happy note" when the community goes through another split.
Why not? In practice, it can cause less spam on BTC, and more spam on LukeCoin. Because everyone knows, that BTC can be spammed. But for LukeCoin, people are not yet sure, how fast new filters will appear, and how good they will be at censoring transactions. So, it is something to be tested.
Which means, that putting some spam on a LukeCoin will be just a new challenge. And if 1 LukeCoin will be worth for example 0.01 BTC, then putting a spammy transaction on BTC with 1 sat/vB will be as expensive, as putting the same spamming transaction on LukeCoin, but with 100 sat/vB fees. Then, LukeCoin will be treated like a testnet, where people will have plenty of coins, and many can use them only to prove, that spamming is still possible, and BIP-110 didn't solve any problems, while also creating some new ones, unknown previously, for example by blocking some future multisigs.
Many spammy transactions were created only to prove, that it is possible. And suddenly, at the moment of split, all users will get 1:1 balances on both chains, just like it was, when BCH was created, but this time, it will be a minority soft-fork. And then, I wonder, how long LukeCoin will survive, without hacking the difficulty.
By the way: it would be funny, if Proof of Work will act as The Greatest Filter in this case, censoring all unconfirmed transactions equally, from getting even a single confirmation. Because then, it would be a question, if you want a spammy chain, where your transaction can be confirmed in 10 minutes, if you pay enough fees, or if you want a chain, without any spam, where you have to wait a day or two, for getting a single confirmation for any transaction, no matter if it is a spam, or not.
Edit:
I was looking for the 961632 block number
It is implicitly stated in DeploymentMustSignalAfter function:
https://github.com/bitcoinknots/bitcoin/pull/238/changes#diff-babeb1d64c5099f72895e7ecdfde8a384c378308d41301b8fc53a3aded4ad051R60-R72/** Determine if mandatory signaling is required for a deployment at the next block */
inline bool DeploymentMustSignalAfter(const CBlockIndex* pindexPrev, const Consensus::Params& params, Consensus::DeploymentPos dep, ThresholdState state)
{
assert(Consensus::ValidDeployment(dep));
const auto& deployment = params.vDeployments[dep];
if (deployment.max_activation_height >= std::numeric_limits<int>::max()) return false;
if (state != ThresholdState::STARTED) return false; // If must_signal height is reached before start time, abstain from enforcement
const int nPeriod = params.nMinerConfirmationWindow;
const int nHeight = pindexPrev == nullptr ? 0 : pindexPrev->nHeight + 1;
return nHeight >= deployment.max_activation_height - (2 * nPeriod)
&& nHeight < deployment.max_activation_height - nPeriod;
}
Which means, that you have "max_activation_height = 965664", and then, if you subtract 2*2016 from it, you will get 961632, exactly as in BIP.
