Oddbean new post about | logout
 Question to bitcoin devs or other techies here.

Have there been thoughts about temporary soft forks?

In other words, suppose there is some potential change to bitcoin that there is some difference of opinion in even though it seems solid overall. Rather than permanently tightening the rules (which potentially requires a hard fork to undo, depending on the change), is there a case to consider a temporary soft fork instead? Eg it becomes active for the next 100,000 blocks and then will revert to the prior state for future transactions after that point unless renewed again, temporarily or maybe permanently that time depending on consensus at that point? 
 Might be possible in theory, but seems highly risky from an implementation and node consensus POV, let alone the difficulty of gaining social consensus for this type of change.

Then there’s the idea that soft forks can only tighten rules and not loosen them - I’m not sure if it’s possible to soft fork a future loosening of consensus rules.

Curious to hear what any core devs have to say. 
 Not a computer scientist but I basically read this as a “temporary suspension of the gold standard” with extra steps. But what do I know 
 That's where my thought process went 
 No dev here so feel free to ignore me. 

It sounds like one solution is roll it out on something like Litecoin or at least it used to be that way. That’s what happened with Segwit.

https://www.coindesk.com/markets/2017/05/10/litecoin-successfully-activates-segwit/ 
 I think Luke Jr wanted something like that, to reduce the blocksize to 300kb or something for a limited time.  
 Sounds like a back and forth to me, a reasonable theory nonetheless. Guess the pros will have a much better say on whether this makes sense. 
 I guess it also depends on what kind of soft fork it is because it's a new kind of tx/contract like multisig or like timelocks or covenants, temporary would be harmful I guess because you could restrict somehow how you wanted to spend your btc and then that would no longer be valid/recognized.  
 Liquid has been used for the purpose of trialing new features. 

Having a block deadline reminds me of the Ethereum bombs they have injected to force miners to upgrade. 
 No this is what the testnet is for. 
 Also this would mess up backwards compatibility.
-not a dev 
 👍 
 Mostly have been talked about for things like block size. Doing this for things doing with transaction validity has a lot of problems. Imagine we activate CTV temporarily and I have a tx spending one near the end of the term. A miner can see that and not mine it until after the term is over and then be able to take the funds because it is now anyone can spend again. 
 A temporary "rule change" that can be coded in, is an interesting idea. While the optimist inside me sees this as an excellent opportunity to establish a true type of "temporary government initiative" within the Network State, the pessimist in me argues that temporary government programs often become permanent, raising the question of whether a temporary code adjustment would truly be any different for the Network.  
 This a is a great idea. Many soft forks are backward compatible so they can easily be turned off if they are undesirable for whatever unknown reason down the line.

However, I think the issue is the getting the soft forks to activate. It now takes at least 3 years to get a BIP through. In early days there were several soft forks a year. https://image.nostr.build/c1ad9bfe7804b9564798516e9e8b45be424f6a8f8b8790306fae9e00d2ad5906.jpg  
 Sounds similar to the concept of upgrade lock-in / activation, where an update has a predetermined amount of time to gain a certain level of adoption, otherwise it fails to activate. 

Outside of that, what would be the use case for something like this, vs deploying experimental upgrades on the testnet? 
 Every BIP 300 side chain is a soft fork. Liquid BTC is in my mind the example. Faster settlement times, Two block confirmation instead of six. The 2106 problem where bitcoin ticks it’s last block is the only realistic reason to consider a hard fork, Which will eventually happen or be solved for, But ultimately it really is still a soft fork in any example of a BIP 300 protocol. 
 Kinda like depegging the dollar from the gold standard "temporarily?"  
 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020242.html 
 The "bitcoin-inquisition" signet from ajtowns should also implement David's idea for temporary or upgradable soft forks:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html 
 This is what we need in politic for new  rules and laws. 
The opportunity to cancel stupid new law after a certain time when everybody see, its useless or damaging for society. 
 Lyn, once Bitcoin gets a secure 2-way peg mechanism then almost any other blockchain can be a sidechain.
For this to happen we need BitVM to mature, and ideally OP_CAT enabled. 
Or wait for @Blockstream to implement Simplicity. 
 Temporary divergence to consensus rules alters confirmation security thus perceived value of the money. There is no implied continuity. 
 Even if it is temporary, projects will build and depend on it. Reverting will cause a shit storm. 
 Hard pass.
This is the crypto equivalent of the State making a temporary law... there are no temporary laws. 
 I like yestnets for testing. Keep the dev flow nice and the community from revolt. 
 what do you do about coins that have locked up funds using features that were deprecated?

bitcoin scripts are essentially user-defined programs, which get run/executed when the bitcoin *are spent*. there is no real going backsies once funds have been locked up to them.