Hi all,

The main criticisms I'm aware of against CTV seem to be along the following lines:

1. Usage, either:
  a. It won't receive significant real-world usage, or
  b. It will be used but we'll end up using something better later
2. An unused CTV will need to be supported forever, creating extra maintenance burden, increasing security surface, and making it harder to evaluate later
   consensus change proposals due to their interactions with CTV

Could those concerns be mitigated by making CTV an automatically reverting consensus change with an option to renew? E.g., redefining OP_NOP4 as OP_CTV for five years from BIP119's activation date and then reverting to OP_NOP4. If, prior to the end of those five years, a second soft fork was activated, it
could continue enforcing the CTV rules either for another five years or
permanently.

This would be similar in nature to the soft fork described in BIP50 where the maximum block size was temporarily reduced to address the BDB locks issue and then allowed to return to its original value. In Script terms, any use of
OP_CTV would effectively be:

    OP_IF
      <arguments> OP_CTV
    OP_ELSE
      <5 years after activation> OP_CLTV
    OP_ENDIF

As long as we are absolutely convinced CTV will have no negative effects on the holders or receivers of non-CTV coins, I think an automatically reverting soft fork gives us some ability to experiment with new features without committing
ourselves to live with them forever.

The main downsides I can see are:

1. It creates a big footgun. Anyone who uses CTV without adequately preparing for
   the reversion could easily lose their money.

2. Miners would be incentivized to censor spends of the reverting
opcode near its reversion date. E.g., if Alice receives 100 bitcoins to a script secured only by OP_CTV and attempts to spend them the day before it becomes OP_NOP4, miners might prefer to skip confirming that transaction even if it pays a high feerate in favor of spending her 100 bitcoins to themselves
   the next day after reversion.

   The degree to which this is an issue will depend on the diversity of
   hashrate and the willingness of any large percentage of hashrate to
deliberately reorg the chain to remove confirmed transactions. This could be mitigated by having OP_CTV change to OP_RETURN, destroying any unspent CTV-only coins so that any censoring miners only benefited from the (hopefully slight)
   decrease in bitcoin currency supply.

3. A bias towards keeping the change. Even if it turned out very few people really used CTV, I think there would be a bias at the end of five years towards
   "why not just keep it".

4. The drama doesn't end. Activating CTV now, or decisively not activating it, may bring to an end our frequent discussions about it (though I wouldn't
   count on that).  An automatically reverting soft fork would probably
guarantee we'll have further consensus-level discussions about CTV in the
   future.

Thanks for reading.  I'm curious to hear y'alls thoughts,

-Dave
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to