Once it is on testnet, it means it is merged, and you don't have to rebase anymore. Activation is literally parametrization, i.e. setting a bunch of values in `src/kernel/chainparams.cpp` - not worth having an open PR for.

the idea of using criticality to force them rather than proactively doing them resonates with me. perhaps in the case of attack blocks that is unwise, but for the others it works.

perhaps that is the intention here though: get a fix for each of them on testnets and and ready to merge when needed (but then I guess it's "rebase-ing" or whatever for as long as it lingers...)

Scoresby

BIP54 is unnecessary or not the right way to fix these problems

It's like when congress throws a bunch of unrelated shit into a single bill as a product of horse trading, nothing good ever comes out of it.

Poinsot emphasized that there is not a particular rush around this soft fork

This supports the first point, they should be one-off as they become critical, the forcing function of criticality would make them non-contentious. Lumping them together is Core just showing it's a politburo.

bitcoin

bitdevs

Implement BIP 54 (Consensus Cleanup) without mainnet activation by darosior

> BIP54 is unnecessary or not the right way to fix these problems

It's like when congress throws a bunch of unrelated shit into a single bill as a product of horse trading, nothing good ever comes out of it.

> Poinsot emphasized that there is not a particular rush around this soft fork

This supports the first point, they should be one-off as they become critical, the forcing function of criticality would make them non-contentious. Lumping them together is Core just showing it's a politburo.