<oembed><type>rich</type><version>1.0</version><author_name>npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd</author_name><author_url>https://nostr.ae/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2022-04-20&#xA;📝 Original message:Hi all,&#xA;&#xA;The main criticisms I&#39;m aware of against CTV seem to be along the &#xA;following lines:&#xA;&#xA;1. Usage, either:&#xA;   a. It won&#39;t receive significant real-world usage, or&#xA;   b. It will be used but we&#39;ll end up using something better later&#xA;2. An unused CTV will need to be supported forever, creating extra &#xA;maintenance&#xA;    burden, increasing security surface, and making it harder to evaluate &#xA;later&#xA;    consensus change proposals due to their interactions with CTV&#xA;&#xA;Could those concerns be mitigated by making CTV an automatically &#xA;reverting&#xA;consensus change with an option to renew?  E.g., redefining OP_NOP4 as &#xA;OP_CTV&#xA;for five years from BIP119&#39;s activation date and then reverting to &#xA;OP_NOP4.&#xA;If, prior to the end of those five years, a second soft fork was &#xA;activated, it&#xA;could continue enforcing the CTV rules either for another five years or&#xA;permanently.&#xA;&#xA;This would be similar in nature to the soft fork described in BIP50 &#xA;where the&#xA;maximum block size was temporarily reduced to address the BDB locks &#xA;issue and&#xA;then allowed to return to its original value.  In Script terms, any use &#xA;of&#xA;OP_CTV would effectively be:&#xA;&#xA;     OP_IF&#xA;       &lt;arguments&gt; OP_CTV&#xA;     OP_ELSE&#xA;       &lt;5 years after activation&gt; OP_CLTV&#xA;     OP_ENDIF&#xA;&#xA;As long as we are absolutely convinced CTV will have no negative effects &#xA;on the&#xA;holders or receivers of non-CTV coins, I think an automatically &#xA;reverting soft&#xA;fork gives us some ability to experiment with new features without &#xA;committing&#xA;ourselves to live with them forever.&#xA;&#xA;The main downsides I can see are:&#xA;&#xA;1. It creates a big footgun.  Anyone who uses CTV without adequately &#xA;preparing for&#xA;    the reversion could easily lose their money.&#xA;&#xA;2. Miners would be incentivized to censor spends of the reverting&#xA;    opcode near its reversion date.  E.g., if Alice receives 100 bitcoins &#xA;to a&#xA;    script secured only by OP_CTV and attempts to spend them the day &#xA;before it&#xA;    becomes OP_NOP4, miners might prefer to skip confirming that &#xA;transaction even&#xA;    if it pays a high feerate in favor of spending her 100 bitcoins to &#xA;themselves&#xA;    the next day after reversion.&#xA;&#xA;    The degree to which this is an issue will depend on the diversity of&#xA;    hashrate and the willingness of any large percentage of hashrate to&#xA;    deliberately reorg the chain to remove confirmed transactions.  This &#xA;could be&#xA;    mitigated by having OP_CTV change to OP_RETURN, destroying any &#xA;unspent CTV-only&#xA;    coins so that any censoring miners only benefited from the (hopefully &#xA;slight)&#xA;    decrease in bitcoin currency supply.&#xA;&#xA;3. A bias towards keeping the change.  Even if it turned out very few &#xA;people&#xA;    really used CTV, I think there would be a bias at the end of five &#xA;years towards&#xA;    &#34;why not just keep it&#34;.&#xA;&#xA;4. The drama doesn&#39;t end.  Activating CTV now, or decisively not &#xA;activating it,&#xA;    may bring to an end our frequent discussions about it (though I &#xA;wouldn&#39;t&#xA;    count on that).  An automatically reverting soft fork would probably&#xA;    guarantee we&#39;ll have further consensus-level discussions about CTV in &#xA;the&#xA;    future.&#xA;&#xA;Thanks for reading.  I&#39;m curious to hear y&#39;alls thoughts,&#xA;&#xA;-Dave</html></oembed>