I think I've discussed this type of concept previously somewhere but cannot find a link to where.
Largely, I think the following: 1) This doesn't reduce burden of maintenance and risk of consensus split, it raises it: A) as we now have a bunch of tricky code around reorgs and mempool around the time of rule de-activation. B) we need to permanently maintain the rule to validate old blocks fully 2) Most of the value of a 'temporary soft fork' is more safely captured by use of a CTV emulation server / servers, which has a more graceful degradation property of the servers simply shutting down and not authorizing new contracts, but funds not being vulnerable to theft. The model here is trust, as opposed to a timeout. 2A) The way I implemented the oracles in CTV was such that, if we wanted to, we could actually soft-fork the rules for the oracle's keys such that they would *have to* only sign CTV-valid transactions (e.g., the keys could be made public). Pretty weird model, but cool that it would enable after-the-fact trust model improvements. This could be generalized for any opcode to be emulator -> emulator consensus guaranteed -> non signature based opcode. Although I will note that I like the spirit of this, and encourage thinking more creatively about other ways to have temporary forks in Bitcoin like this. Best, Jeremy -- @JeremyRubin <https://twitter.com/JeremyRubin>
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
