public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV
@ 2022-04-22 19:05 alicexbt
  0 siblings, 0 replies; 26+ messages in thread
From: alicexbt @ 2022-04-22 19:05 UTC (permalink / raw)
  To: lf-lists; +Cc: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 742 bytes --]

Hi TheBlueMatt,

>> There are at least three or four separate covenants designs that have
>>> been posted to this list, and I don't see why we're even remotely
>>> talking about a specific one as something to move forward with at
>>> this point.
>>
>>> To my knowledge none of these other proposals (drafts, really) have
>>> actual implementations let alone the many sample usages that exist for
>> CTV.

> You can fix this! Don't point to something you can easily remedy in the > short-term as an argument
> for or against something in the long-term.

How can we fix this? If a proposal already fixed it, does it have some consensus or it was fixed in a different way?

/dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.

[-- Attachment #2: Type: text/html, Size: 1378 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread
* [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV
@ 2022-04-21  1:04 David A. Harding
  2022-04-21  2:05 ` Luke Dashjr
                   ` (5 more replies)
  0 siblings, 6 replies; 26+ messages in thread
From: David A. Harding @ 2022-04-21  1:04 UTC (permalink / raw)
  To: bitcoin-dev

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


^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2022-04-25  5:12 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-22 19:05 [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV alicexbt
  -- strict thread matches above, loose matches on Subject: below --
2022-04-21  1:04 David A. Harding
2022-04-21  2:05 ` Luke Dashjr
2022-04-21  3:10   ` alicexbt
2022-04-21  5:56     ` Luke Dashjr
2022-04-21  6:20       ` Jeremy Rubin
2022-04-21  6:37         ` Luke Dashjr
2022-04-21 13:10           ` Jeremy Rubin
2022-04-24 15:22     ` Peter Todd
2022-04-21 14:58 ` Matt Corallo
2022-04-21 18:06   ` David A. Harding
2022-04-21 18:39     ` Matt Corallo
2022-04-21 22:28       ` David A. Harding
2022-04-21 23:02         ` Matt Corallo
2022-04-22  1:20           ` David A. Harding
2022-04-22 18:40             ` Matt Corallo
2022-04-22 18:49               ` Corey Haddad
2022-04-22 16:48         ` James O'Beirne
2022-04-22 17:06           ` James O'Beirne
2022-04-22 16:28       ` James O'Beirne
2022-04-22 18:35         ` Matt Corallo
2022-04-21 19:08 ` Jeremy Rubin
2022-04-22  0:28 ` Anthony Towns
2022-04-22  1:44   ` David A. Harding
2022-04-22 19:57 ` Antoine Riard
2022-04-25  5:12 ` ZmnSCPxj

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox