Quote from: jeremyrubin on January 31, 2020, 07:14:46 PM

detail to understand exactly what you want

It sounds like you're understanding what I'm trying to discuss, and I'll respond to each numbered point. Thanks for putting in the time to explain all this to me tho! I appreciate it, tho I don't want to put too much burden you since its likely that I won't understand every piece of this perfectly, and I'm fine with that.

What I'm looking for here is just a discussion of how the various use cases would be best supported. I'm not saying one op code should provide the functionality for all of them (tho I'm not saying the opposite either). I'm primarily concerned with how exactly bitcoin vaults will be created, and I'm hoping that op_ctv, another new op_code, or a combination will provide the functionality to create bitcoin vaults that can be used without extra limitations that basic wallets don't have (eg with regard to number of inputs). Also important is the efficiency of the vault (in terms of transaction size in bytes). So my goal with this thread is to understand the limitations of op_ctv as it stands with regard to bitcoin vaults, and what additional op codes might be needed to fully support the kind of bitcoin vault I'm interested in.

I can be a bit more detailed about the type of bitcoin vault I've been thinking of. An example would be a two-key wallet where any coins sent to it can be spent in arbitrary combinations with the following (and only the following) restrictions:

A. If *both* keys sign the transaction, the destination address can spend immediately.
B1. If only *one* of the two keys signs the transaction and *fewer* than 1000 blocks have passed since the transaction was mined, the output can be spent only by signing with both keys and must be spent back to the original input address using a maximum fee of X.
B2. If only *one* of the two keys signs the transaction and *greater* than or equal to 1000 blocks have passed since the transaction was mined, the destination address can spend immediately.

Coins can be spent to any destination, using any number of inputs (from this wallet or not), as long as the above restrictions are followed. Here's another description of a similar wallet setup: https://github.com/fresheneesz/TordlWalletProtocols/blob/master/experimental/singleWalletProtocols/Time-locked%203-Seed%20Cold%20Wallet.md

The above uses another non-existent concept: a time-unlock or time-switch. Currently we have relative and absolute timelocks, but we don't have a way to unlock some behavior after some time. The ability to do that would allow these bitcoin vaults to do the above in a single transaction that becomes finalized after some time (eg 1000 blocks in the above example) without any additional transaction needed. Without that, 2 transactions are needed (one transaction with a timelocked transaction who's script is similar to B1 and B2 above and then another non-timelocked transaction to the destination).

One issue I can see with B2 is that it basically requires that input constraints be composed with output constraints (ie, if you want to pay from a vault like this to a script hash). Is it possible to create a script that has a branch that requires an external script be satisfied (eg a "condition on script hash", or something like that)? Without that ability, it seems that one vault wouldn't be able to send to another vault.

One issue with op_ctv is that an output using it can't practically be used in batched transactions. In the future, I think it might become standard to batch transactions for both privacy and efficiency (as in wasabi wallet). If I'm right that's the case, then op_ctv might be relatively a very expensive op to use.

1. Gotcha, that makes sense. Regardless of the inability to commit to a transaction hash, it should be possible to create a convenant with multiple inputs for which there is only one possible transaction that spends them. Granted, I have no use case for doing specifically that with multiple inputs, so we don't need to discuss that use case. However, it sounds like op_ctv does allow doing this (only allowing one possible transaction) in the case of a single input, correct?

2. Yes, but I would like to specify additional outputs in order to support batched transactions.

3. This point is to address the first question Greg brought up in this thread. This would allow the fee specification in restriction B1 above. Without this, Greg's point was that an attacker (eg who stole one of the two keys in the wallet above) could spend your entire wallet as fee (which obviously isn't something you want to allow).

4. I don't believe I'm asking for anything new here, actually. I'm just including this for completeness. Op_ctv allows committing to the locktime of the next transaction (as opposed to the locktime of the transaction guarded by a script using op_ctv), right? That's all I'm saying here. This is not the same thing as verifying the locktime without the use of covenants.