# Transitory Soft Forks for Consensus Cleanup Forks **URL:** \ **Category:** Protocol Design\ **Created:** [December 23, 2024, 10:04pm UTC](https://delvingbitcoin.org/t/transitory-soft-forks-for-consensus-cleanup-forks/1333 "2024-12-23T22:04:20Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![harding](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/harding/32/925_2.png) [@harding](https://delvingbitcoin.org/u/harding)\ **Post date:** [December 24, 2024, 5:42pm UTC](https://delvingbitcoin.org/t/transitory-soft-forks-for-consensus-cleanup-forks/1333/2 "2024-12-24T17:42:31Z")
> [@JeremyRubin](#): > > I’d be interested to hear others’ thoughts on whether this approach seems feasible or if there are important reasons to avoid it. Technically, I think it’s feasible and I can’t think of a reason we must avoid it. I also think it might be useful to have modern experience with transitory soft forks in case we ever again have a [BIP50](https://github.com/bitcoin/bips/blob/665712c727ee898f0e6a31eee6f1a0ecab8bae4e/bip-0050.mediawiki)-like situation where a short-duration soft fork may be useful for mitigating an emergent risk. Less technically, I got the impression before that the proposal was pretty “meh” even if I had been able to fully address all of the criticism. Quite reasonably, several champions of soft fork proposals weren’t enthusiastic about going through the effort of development, review/bikeshedding, and community consensus building for something that might, a few years later, involve additional development, review/bikeshedding, and community consensus building. I think that concern also applies to cleanup soft forks. What developer working on them wants to run the obstacle-course marathon of getting them to activation only to maybe have to run it again in a few years _for no additional benefit?_ --- _[View the full topic](https://delvingbitcoin.org/t/transitory-soft-forks-for-consensus-cleanup-forks/1333)._