Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

From: Jeremy Rubin <[email-masked]>
Date: Thu, 21 Apr 2022 14:08:36 -0500

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>