public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [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; 38+ 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] 38+ messages in thread
* Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") > soft forks)
@ 2022-04-25 16:03 Buck O Perley
  2022-04-27  2:09 ` Billy Tetrud
  0 siblings, 1 reply; 38+ messages in thread
From: Buck O Perley @ 2022-04-25 16:03 UTC (permalink / raw)
  To: bitcoin-dev


[-- Attachment #1.1: Type: text/plain, Size: 10239 bytes --]

Just a couple of comments re-CTV vault security concerns.


1. One way to assuage the concern of the hot wallet vulnerability
is pre-program the spends such that the hot wallet can only
spend a certain amount from the hot wallet spend and the rest would
kind of be "recursive" in that it would be sent back to a
new instantiation of the CTV vault. I believe kanzure's vaults
does this w/ the non-covenant version using pre-signed transactions
(https://github.com/kanzure/python-vaults). While this doesn't
prevent the theft it caps off the total risk. I would argue that
this is strictly better than a multisig because you can also use
multisig as you normally would if you want but you have the option
if you think your hot key is secure to use that spending path.
You also get the nice benefit of learning about compromised
keys without having to risk all funds associated with that key.


2. As to how to improve UX for CTV with other proposals, I think
you get a lot of benefits when using with taproot because you can
use CTV in tapleaves to secure specific spend conditions, but can
always fall back to other off-ramps (e.g. a musig key path spend or
other script path conditions). Of course you can do this without
taproot but taproot makes this more space efficient. This idea has
been used to some effect in some recent exploration of how CTV can
help improve UX around DLCs. You could even do this to help with
the problems of not sending the right amount such that you have a
really really cold key or set of keys for example such that if you
have UTXOs that have values that can't be spent with the given CTV
commitment, then you just use that other branch.

- Buck

------- Original Message -------

> Date: Sun, 24 Apr 2022 18:03:52 -0500
> From: Billy Tetrud billy.tetrud@gmail•com
> 

> To: "Russell O'Connor" roconnor@blockstream•com, Bitcoin Protocol
> 

> Discussion bitcoin-dev@lists•linuxfoundation.org
> 

> Subject: Re: [bitcoin-dev] Vaulting (Was: Automatically reverting
> ("transitory") soft forks)
> Message-ID:
> CAGpPWDaeKYABkK+StFXoxgWEhVGzqY02KPGOFjOtt9W8UPRr1A@mail•gmail.com
> 

> Content-Type: text/plain; charset="utf-8"
> 

> @Matt
> 

> > both of which are somewhat frustrating limitations, but not security
> 

> limitations, only practical ones.
> 

> So I think the first limitation you mentioned (that if your hot wallet's
> key gets stolen you need) can be legitimately considered a security
> limitation. Not because you need to rotate your keys, but because you might
> not know your hot wallet key has been stolen. If you unvault an output to
> your hot wallet, the thief could be lying in wait, ready to steal those
> funds upon them landing. At that point, you would then know your hot wallet
> key was compromised and could rotate your vault keys in order to prevent
> further theft. However, the fact that there is a clear theft vulnerability
> is something I would say should be considered a "security limitation".
> 

> As you mentioned, this is of course also a security limitation of a hot
> wallet, so this setup definitely has a lot of advantages over a simple hot
> wallet. However, if you compare it against a multisig wallet (eg 2 of 3),
> you can see that while theft of a single key would never result in any
> theft in that setup, it could in a CTV vault. The other trade offs there
> are ones of practicality and convenience.
> 

> This isn't to say a CTV vault wouldn't be useful. Just that it has
> significant trade offs.
> 

> @Russel
> 

> > the original MES vault .. commits to the destination address during
> 

> unvaulting
> 

> I see. Looking at the MES16 paper, OP_COV isn't described clearly enough
> for me to understand that it does that. However, I can imagine how it
> might do that.
> 

> One possibility is that the intended destination is predetermined and
> hardcoded. This wouldn't be very useful, and also wouldn't be different
> than how CTV could do it, so I assume that isn't what you envisioned this
> doing.
> 

> I can imagine instead that the definition of the pattern could be specified
> as a number indicating the number of stack items in the pattern, followed
> by that number of stack items. If that's how it is done, I can see the user
> inputting an intended destination script (corresponding to the intended
> destination address) which would then be somehow rotated in to the right
> spot within the pattern, allowing the pattern to specify the coins
> eventually reaching an address with that script. However, this could be
> quite cumbersome, and would require fully specifying the scripts along the
> covenant pathways leading to a fair amount of information duplication
> (since scripts must be specified both in the covenant and in spending the
> subsequent output). Both of these things would seem to make OP_COV in
> practice quite an expensive opcode to spend with. It also means that, since
> the transactor must fully specify the script, its not possible to take
> advantage of taproot's script hiding capabilities (were it to send to a
> taproot address).
> 

> However, my assumptions might be incorrect. If you think OP_COV would be a
> useful opcode, I would encourage you to write up a complete specification.
> 

> > What ways can we build a secured vault that commits to the destination
> 

> address?
> 

> Some kind of passed-through state allows doing this. With OP_COV (if my
> assumptions above are correct), the intended destination can be passed
> through the output script pattern(s). With my own proposed
> op_pushoutputstack
> https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md,
> 

> state is passed as an attachment on the output more directly. Curious what
> you think about that proposal.
> 

> > Are there elegant ways of building secure vaults by using CTV plus
> 

> something else.
> 

> Since CTV predefines all the transactions that can happen under its
> control, passed state like this can't help because any dynamic state would
> change the template and render the CTV transaction invalid. I don't see any
> way of solving this problem for CTV.
> 

> I'm curious how you think op_cat could enable this with CTV (other than the
> cat+schnorr tricks that don't require CTV at all).
> 

> 

> 

> On Sat, Apr 23, 2022 at 2:31 PM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
> 

> > Okay, Matt explained to me the intended application of CTV vaults off
> > list, so I have a better understanding now.
> > 

> > The CTV vault scheme is designed as an improvement over the traditional
> > management of hot-wallets and cold-wallets. The CTV vault is logically on
> > the "cold-side" and lets funds be sent from the "cold" side to one's own
> > the hot wallet after the unvaulting delay. In this case, the hot wallet
> > funds are always at risk, so it isn't unexpected that those funds could be
> > stolen. After all, that is how hot wallets are today. The advantage is
> > that funds can be moved from the "cold" side without needing to dig out the
> > cold keys.
> > 

> > The MES vault scheme applies to a different scenario. In the MES case it
> > is the hot funds are inside the vault, and it is the hot key that unvaults
> > the funds and sends them to customer's addresses after a delay. If the
> > hot-key is used in any unauthorised way, then funds can be sent to the
> > address of the cold key (the MES vault actually does something fancy in
> > case of recovery, but it could be adapted to simply send funds to a cold
> > wallet).
> > 

> > The MES vault lie somewhere between "better" and "different" when compared
> > to the CTV vault. If one is unwilling to use the MES vault on the hot side
> > and have every withdrawl vetted, then, while you could use the MES design
> > on the cold side like the CTV vault, it wouldn't really offer you any
> > advantages over a CTV vault. However, if you are interested in managing
> > all your payments through a vault (as I've been imagining) then the CTV
> > vault comes across as ineffective when compared to an MES style vault.
> > 

> > On Sat, Apr 23, 2022 at 2:24 PM Matt Corallo lf-lists@mattcorallo•com
> > wrote:
> > 

> > > Still trying to make sure I understand this concern, let me know if I get
> > > this all wrong.
> > > 

> > > On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:
> > > 

> > > > It's not the attackers only choice to succeed. If an attacker steals
> > > > the hot key, then they have
> > > > the option to simply wait for the user to unvault their funds of their
> > > > own accord and then race /
> > > > outspend the users transaction with their own. Indeed, this is what we
> > > > expect would happen in the
> > > > dark forest.
> > > 

> > > Right, a key security assumption of the CTV-based vaults would be that
> > > you MUST NOT EVER withdraw
> > > more in one go than your hot wallet risk tolerance, but given that your
> > > attack isn't any worse than
> > > simply stealing the hot wallet key immediately after a withdraw.
> > > 

> > > It does have the drawback that if you ever get a hot wallet key stole you
> > > have to rotate all of your
> > > CTV outputs and your CTV outputs must never be any larger than your hot
> > > wallet risk tolerance
> > > amount, both of which are somewhat frustrating limitations, but not
> > > security limitations, only
> > > practical ones.
> > > 

> > > > And that's not even mentioning the issues already noted by the document
> > > > regarding fee management,
> > > > which would likely also benefit from a less constrained design for
> > > > covenants.
> > > 

> > > Of course I've always been in favor of a less constrained covenants
> > > design from day one for ten
> > > reasons, but that's a whole other rabbit hole :)
> > 

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread
end of thread, other threads:[~2022-04-28 23:51 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-21  1:04 [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV 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 17:25         ` [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks) Russell O'Connor
2022-04-23  4:56           ` Billy Tetrud
2022-04-23 14:02             ` Russell O'Connor
2022-04-23 18:24           ` Matt Corallo
2022-04-23 19:30             ` Russell O'Connor
2022-04-24 23:03               ` Billy Tetrud
2022-04-25 17:27                 ` Nadav Ivgi
2022-04-25 22:27                 ` Russell O'Connor
2022-04-27  1:52                   ` Billy Tetrud
2022-04-28 23:14                     ` Nadav Ivgi
2022-04-28 23:51                       ` Billy Tetrud
2022-04-22 18:35         ` [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV 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
2022-04-25 16:03 [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") > soft forks) Buck O Perley
2022-04-27  2:09 ` Billy Tetrud

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