The way I see it:

* tail emission of a fixed number of bitcoin trends towards 0 inflation and is therefore not different in the long run from a fixed supply.
* tail emission as a fixed percent of bitcoin is forever inflation. This does have an effect, but as noted by many in the "Bitcoin covenants are inevitable" email thread on the dev mailing list (which went off the rails as a discussion of blockchain security and targeting/funding of that security), doing this does increase the amount of security (all other things kept equal). However, choosing an arbitrary forever-inflation-rate does not ensure that blockchain security will always be sufficiently funded, unless we can find some upper bound on required blockchain security (in terms of percentage of total coin supply).
* Some have mentioned that people lose coins. I don't think this fact is worth considering - ie its not significant. The future rate of lost coins will decrease towards 0, and is likely already nearly 0 today.

If for some reason we determine that we *can't* sufficiently fund miners with fees alone (which I think is a very real, but unlikely possibility), then adding a percentage-based tail emission would be basically our only option. However, I agree with most that until we find that to be the case, its likely a very dangerous thing to attempt to do to bitcoin. Even tho there are reasons of economic efficiency for holders to pay some of the cost of bitcoin's security (via inflation) in addition to transactors (via fees).

I just thought of an interesting idea that could make a lightning channel a lot more secure to use, and as a consequence could lead to much larger channels, more people routing on the LN, and lower LN transaction fees. The idea is to have some script mechanism that allows strictly netrual or positive lightning channel updates using a secondary key.

1. The lightning channel would be set up such that HTLCs and commitment update scripts can be signed by a secondary key that doesn't have the ability to either send through the lightning network or route payments in a way that loses money.

2. If these HTLCs or committments need to be published on chain, they must present proof of non-negativity. For receiving transactions, this could be a condition that allows signing with the secondary key as long as the amount allocated to the user's refund address is greater than a base commitment (which would need to be presented, along with a way to revoke it if that presented base commitment is out of date).  For routing transactions, the two channels used to route through could each have HTLCs that each require presenting the other HTLC, and the script would verify that any amount lost by one channel is exceeded by the amount gained by the other channel.

3. Spending transactions must still be signed with the primary key (eg via a hardware wallet).

The benefit is that one does not expose their spending keys in a hot wallet. Receiving and routing can still be done without exposing your funds to risk of theft. The maximum damage someone can do if they compromise your secondary key is to route payments for free. The downside is that the commitment and HTLC transactions would likely be significantly larger, which would affect the size of transactions that are economical to enforce.

I'm wondering if anyone has discussed this kind of idea before and if there have been any concrete mechanisms discussed.

Something similar could be done with a hardware-wallet-like device, where it internally verifies that a lightning transaction is at-worst neutral, and only if it is does it sign using your key. This still means that your key is online, but it certainly would be a huge step up from being online on a normal machine. This also wouldn't have the downside of larger enforcement transactions. But it would require a special device.

It would be interesting if an opendime-like or hardware-wallet device could facilitate bitcoin transfers offline. This could potentially work by locking coins and swapping transactions directly via the hardware wallets, kind of like the lightning network uses off-chain pre-signed transactions.

This would necessarily require some trust in the user and/or device used. Obviously, a tampered-with device could simply double spend a number of coins. However, if the users involve trust that the hardware device is not compromised (perhaps because the company making it has a good reputation for making them secure), it should be possible to make offline transactions. If the company (or a government) goes further to deter people from double spending (either via tampered-with devices, or counterfeits), it could bolster trust in it further.

But basically, you could timelock coins into a wallet where they aren't spendable until a later date, and when you want to pay someone, you give them a transaction that gives them future ownership over those coins. The additional counterparty risk might be acceptable for small amounts when internet isn't always available. Whenever internet becomes available, the commitments could theoretically be cemented at that point to prevent any possible future double spends.

Mostly interesting musings ^

@ garlonicon
> I think that free market will settle this value somewhere in between

I hope so. Does Eltoo allow for that variable to be chosen by individual channels? I didn't think so. I think that probably the right penalty is to pay the cost of all required on-chain transactions. Eg for Eltoo, this would be the cost of 2 transactions (the cheating transaction and the revoke transaction). It makes sense for the malicious/confused party to pay for the damages. Much more beyond that is excessive, anything less than that isn't fair to the victim.

@Carlton

> maybe close your thread?

That's pretty rude dude. Not cool.

Gotcha. Well, I suppose the limitations of bitcoin Script are a bit orthogonal to the opcode I'm looking for feedback on.

@Carlton
> they're all state-update transactions, and they're all valid on-chain. That's the whole point, it wouldn't work otherwise.

All the state update transactions are valid on-chain, yes that's true. *Until* any one of them is confirmed on chain. Then none are valid. However, the refund (anti-cheating) transaction becomes valid if the confirmed transaction is an out of date state. Once the refund transaction goes through, there are no more presigned transactions that are valid - both parties have their final money from the channel and its fully closed.

> permits any updates in any order, on-chain

I don't believe that's true. You can't spend the same output twice, and all these are pre-signed transctions. What mechanism do you think is being used to allow these update transactions to be spent in "any order"? I don't think such a mechanism exists. What am I missing Carlton?

These are the kinds of obstacles I see for bitcoin in the next 10 years:

* Scaling
 * There are various bottlenecks to increasing bitcoin's blocksize, and a number of ideas for how to loosen those bottlenecks.
 * Layer 2 networks like lightning will continue to be developed and gain adoption.

* Education and Tooling
 * Coin storage education - How will most people store their coins? How will your grandma store her bitcoin? How do we teach people what is a safe way to store their bitcoin and what is not? This includes procedures for how to create and use bitcoin wallets, improved tools and services for key storage and recovery, and education around the risks of various solutions that are out there. Perhaps the community should embrace and collaborate on some wallet guides to educate people.
 * Collaborative custody tools and services. Companies like Unchained Capital and Casa are working on this kind of thing, but standards are needed and the complexity needs to come down a lot and the accessibility needs to come up.
 * Wallet vaults can massively improve the security and ease of use of cold wallets. However covenants are needed, which will require one or more new Script opcodes (eg these ones).

* Governance
 * The Bitcoin community will likely continue have debates about how to make changes to the protocol and hopefully we can converege on a sustainable mechanism that is used for more than one or two updates before being discarded (like previous methods).

* Political and legal challenges
 * As adoption reaches significant levels, its likely there will be a lot more tension in some countries around Bitcion. Some countries will embrace it, some will try to reject it by proposing and/or passing various laws.
 * Existing laws that make bitcoin hard to use (legally) in some countries will hopefully be reformed (eg the tax implications of every-day-sized transactions in the US).  
 * Mining - The amount of electricity and capital eaten up by bitcoin mining will only rise further in the next 10 years while the price is still rising faster than the coinbase reward halvings are reducing the mining rewards. The drama here will only increase, as will the pressure from people who want Bitcoin to adopt a proof of state consensus mechanism. The challenge here is doing the right thing and not caving to pressure and rushing out half-baked solutions. Perhaps the community will eventually decide a PoS consensus protocol is safe and beneficial, but we shouldn't rush to make that decision based on pressure from virtue signalers.

> What is the technical reason why bitcoin transactions can't scale?

Bitcoin can and has improved its scalability. But there are technical bottlenecks that present tradeoffs between achieving bitcoin's goals and increasing the block size (or shortenting the block time).

I wrote a paper a while back that goes through the exhaustive list of bottlenecks: https://github.com/fresheneesz/bitcoinThroughputAnalysis

> Is it technically infeasible to have a secure network while at the same time having faster transactions, without second layer solutions?

Its absolutely technically feasible to increase the transaction throughput of bitcoin. With technical innovations and hardware improvements, bitcoin's onchain throughput will increase over time. However, its a slow process.

> Can someone help me understand why we are not seeing many changes to bitcoin

Bitcoin's philosophy is slow and steady wins the race basically. The Bitcoin community has been committed to widespread buy in from people around the world before making changes. Proposals are discussed by tons of people, code changes are reviewed by tons of people, and deployments are done in a way that requires both overwhelming support from developers, reviewers, users, and miners. All this is done in as decentralized a way as possible. This process makes it substantially less likely that bugs and mistakes are introduced into the software. It makes the system more solid, secure, and reliable. It builds world trust that the Bitcoin system will continue to be solid and predictable. The trade off is that this process is slow. But its a worthy trade off I think.

> why the 10min transaction times is something which "must" occur in order to maintain security.

The paper I linked above also goes over this. Other people have mentioned it in comments too. Lower block times increase the advantage the last miner to mine a block gets, which increases pressure for miners to centralize. Decentralization of miners is key to bitcoin's blockchain security, and so we want to make sure we're designing the system to be well away from any significant miner centralization pressure.

You can think of this as related to the speed of light. Information can only travel so fast, and this puts a constraint on how quickly distantly separated entities can come to a consensus. In a decentralized network, very few entities are connected directly, and so information musts travel in many hops. This is exascerbated by the fact that your connections aren't chosen at all based on their physically proximity to you. So you have signals that can travel halfway around the world and back a number of times before consensus can be reached. 10 minutes isn't the time it takes to come to a consensus tho. The standard in bitcoin is 6 blocks - so about an hour. Even if block times were 10 seconds, however, the time to come to a consensus in the network (aka the "finalization time" - the time after your transaction has been confirmed after which you can consider it non-reversible) wouldn't be much different.

However, the time relevant to miners that matters is the time it takes for them to get the last mined block so they can start mining on it. If it took 1 minute for blocks to get to miners, that would be 10% of the time available to mine - so miners close to whoever last mined the block would have a 10% advantage. That would be bad centralization pressure. But that would be the same centralization pressure if the blocktime were 1 minute and it took 6 seconds to get to propagate the block to other miners. 6 seconds is not a lot of time for a decentralized network.

> If miners were 100x more powerful (or 100x less powerful) than they are currently, would that change the transaction time?

It would not by the way that the protocol is designed. It targets 10 minutes by adjusting the "difficulty" every two weeks. But if you're asking could we reduce the block time if miners were more powerful? The answer is also no, the block time is related to network propagation, not miner hashpower.

> Malloy closes with the exact same old state

Malloy can't close with the same state transaction twice - you can't double spend. There is a clear sequence of transactions. Each presigned uncooperative channel-close transaction is invalidated by making it possible to spend all outputs of that transaction by the counterparty. There is no back and forth possibility in curent lightning unless I have horribly misunderstood something.

I also share d5000's concerns about incentives. Currently, the cost a cheater incurs are:

A. Sending the out-of-date uncooperative channel-close transaction spends fees (presumably half of which came from the cheater, and the other half from their counterparty)

B. When the counterparty claws back the outputs, the cheater loses all their funds. This also covers the cost incurred by the counterparty in step A as a result of that transaction spending some of the counterparty's funds as fee.

With Eltoo, it looks more like:

A. Same as before.

B. Sending a newer state transaction again spends fees from both parties.

Is this corect? If so, it means that the cheater does incur a cost, but its the same cost as the cheater causes the victim to incur. So in this case, a griefer who is willing to lose as much as their victim could grief at 1 to 1 cost. This seems less than ideal.

> the scriptsig is not only in the main transaction hash but also inside the presignature

What do you mean by "the presignature"? In any case, I realized what I was missing. Right the OP_CTV call appears in the script which is what is put into ScriptSig.

>  is the redeem script the one limiting the destinations, but according to your reply it's the outputs hash in the presignature

Yes, that's right, its the commitment to the outputs that constrains the eventual destination of the coins.

> usually in a smart contract you want to make conditions that the output hashes match those coming from, for example, an exchange

What do you mean "match" here? Are you talking about transaction inputs here? Both OP_CTV and OP_CD should be able to ensure the transaction sends the coins to one of a particular set of destinations. What kind of complex conditions can't you do with bitcoin?

> All this is supposed to limit address that the outputs can be spent to by using a script, but how?

What OP_CTV actually does is limit the *transactions* that can be sent to only ones with that specific set of attributes. The set of attributes chosen is intended to ensure that there exists only a single transaction that can fulfill the template. The "outputs hash" in the list is what limits the addresses the transaction sends to.

OP_CTV is basically just one step beyond a pre-signed transaction. With presigned transactions, you require some countersigner to sign a set of transactions that become the only possible transactions you can use to utilize one or more outputs. With OP_CTV, you get rid of the need for some countersigner and can ensure that a set of transactions are the only ways to spend particular outputs.

By contrast, OP_CD is more flexible and there is flexibility allowed in the transactions that can spend outputs locked by a script that uses OP_CD.

> The BIP (119) says P2SH is unsuitable for this,

What BIP119 says is that P2SH is incompatible with OP_CTV if the opcode does end up requiring a commitment to the scriptSig hash. I must admit I don't quite understand where the hash cycle occurs there.

> so this limiting script that's supposed to act as a smart contract will be a raw redeem script?

I don't think I quite understand your question. Would you mind elaborating?

> There's also the major issue of barring simple arithmetic and crypto (hash160) differences between addresses, the scripting system can't filter addresses based on complex conditions.

Not sure I follow this either. Are you saying OP_CTV bars arithmetic? Or are you talking about bitcoin Script in general?

I have been working on a proposal for an opcode I call OP_CONSTRAINDESTINATION. The purpose of the opcode is to allow a spend-path to restrict the destination address that an output's coins can be directed to. When the destination address is something like a P2SH address, this allows step-wise covenant scripts (where one script must lead to another).

This involves both specifying particular addresses the output is allowed to send coins to, as well as constraining the amount of the fee that output is allowed to contribute to. For example, if you had an output that contains 1000 satoshi, you could specify that a maximum of ~100 sats of that output go to the miner fee and the other ~900 sats must go to one of a list of specified addresses (~ meaning approximately, because the fee is specified relative to recent median fee rates - details in the proposal).

This opcode has a few different applications, but my primary motivation for creating this opcode is to create more flexible wallet vaults, which are basically wallet setups where you can cancel a payment for a predefined period of time (sometimes called the unvaulting time). These can be used to create far more secure cold wallet setups without a lot of the downsides. Some more info for the uninitiated https://hackingdistributed.com/2016/02/26/how-to-implement-secure-bitcoin-vaults/.

To compare this opcode to OP_CHECKTEMPLATEVERIFY, wallet vaults that can be created with OP_CTV must be created in specified chunks: the address is explicitly tied to a particular utxo sent to it. To retrieve coins from the vault, the output must be spent by one of a specific set of transactions (potentially one per spend path). Outputs cannot be arbitrarily combined into a transaction, and there is no flexibility whatsoever in deciding options at the time of spending from the vault - all options must be premeditated and encoded into the address itself when sending money to the vault. This has some related foot-gun scenarios, where the wallet vault has addresses that if sent to would generally result in burning those coins, unless done in a very specific way by the owner of the vault.

By contrast, OP_CD allows a lot more flexibility because it only constrains the address to be sent to from the vault, but doesn't put additional constraints on the transaction. This means that outputs can be combined into a single transaction like you would expect in a normal transaction. It also means that external users (people who don't own the vault) can safely send money directly into the vault without coins being burned.

I have the proposal for this opcode up here: https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md . I'd love to hear what people think about it, what problems it might have that I've missed, or other issues or suggestions surrounding this. I'd also appreciate any input that would help me improve the presentation of the opcode.

Thanks!

I think the idea is an interesting one. I think it could likely work. However, the benefits are limited. Yes, you'd save some electricity, but as has been previously mentioned, miners will always be willing to spend up to the amount of the block rewards in order to mine blocks. So this wouldn't save money, because miners would buy enough extra mining equipment to offset the cost they would be spending on electricity. It would also mean that miners would use their ASICS for something else the rest of the time, if possible, which might mean that electricity isn't actually saved. In order to actually save electricity, the PoW algorithm would need to be designed such that the ASICS could not be used for other things (not sure how possible that is).

The mining scheme should be workable tho. Let me recount the way I would do this:

1. At the beginning of each retargetting period, the first block mined is basically the starting gun,

2. then everyone mines a receipt on top of that block at greatly reduced difficulty (1/2016th the difficulty) for 10 minutes,

3. as soon as anyone collects 2016 receipts (adding up to a full normal block of work) they put those receipts into a block and hash that until its been mined at the normal difficulty. This step should exist so the race continues, rather than having a point of failure of the miner that mined the first block in the retargetting period (what if they refuse to sign and broadcast a list?). Also, this ensures that its difficult to create a different list of receipts.

4. once the step 3 block has been mined, it locks in the receipts, and therefore the order of the next 2016 blocks

5. The miner who owns the first receipt in the list must include the hash of the commitment block containing that list as its previous block.

6. For each of the next 2015 blocks, the miner will basically have a time limit to mine their block (rather than racing). If they create their block within the time limit, they get to create that block. If they miss their window, the next miner in the lineup can broadcast their block on top of whatever the most recent block is.

While in normal PoW, miners are racing to mine and broadcast as fast as possible. In the pre-ordered block creation, miners actually have an incentive to wait until their time is almost up to broadcast their block, because they want to include the highest-value transactions they can (and they want as many mempool options as possible before committing to a block). However, because the next miner can skip them if they miss their window, they also have an incentive to broadcast their block well enough before their window ends that they don't risk being skipped. So miners would probably wait until say 10 seconds before their window ends to broadcast their block, but if the previous miner missed their window, they would probably broadcast ASAP (at the beginning of their window) to capture the transactions that miner missed.

An interesting thought experiment is: what should honest miners do when they see conflicting chains? Like, lets say one chain has block receipt 300 skipped but contains a block for receipt 301 and the other chain doesn't have 300 skipped but doesn't contain block 301? Which chain should that miner choose? I suppose this would be like any orphan situation where the miner would choose the chain they saw first, since they're both the same length. Maybe there isn't a problem here.

In any case, this is an interesting idea and was fun to think about. But I don't think the benefits are enough to make it worth the effort and risk of other issues.

So talking about locking spend paths after some time is a little off topic, and isn't really critical to my basic questions. I just wanted to give a clear picture of what seems relatively ideal to me. I don't mind some off topic discussion if you don't, but just wanted to point out we don't have to discuss this to come to a conclusion on the questions I'm posing about op_ctv.

> we want script authorization to be context-free and monotonic

Why is that desirable? And what do you mean by "context free"? As far as I can tell, a bitcoin output is already not context free because of time locks. But I assume you mean something different than what I'm expecting.

> does exactly what you're saying (unlocks a behavior after a specific time)

I'm sorry, I see that the phrase "time-unlock" might be a bit misleading and I also misspoke when I said "we don't have a way to unlock some behavior after some time". I actually meant that we don't have a way to *lock* some behavior after some time. I meant to describe is a (currently non-existent) opcode that would allow a spend-path to remain unlocked for a period of time (just as a time-lock locks a spend path for a period of time). So after the specified block (or relative number of blocks), the spend path would no longer be useable. This "time-unlock" opcode might be better named something like op_invalidafter, op_validbefore, or op_isbefore.

This opcode would allow ownership of an output to "switch over" from one owner to another at a specified time. Before that switch over time, there could be various ways to "reverse" the transaction by spending the output. Correct me if I'm wrong, but I don't believe this is possible with current bitcoin opcodes.

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.

I think I see what you're saying. You're saying the output would depend on the input, but the input would also depend on the output.


Well, I suppose I misspoke. I detailed the 4 cases I would like supported. Committing to an exact transaction, committing to sending to a particular address, committing to a fee, and committing to a next-locktime.

I don't understand what you mean by "hash cycle". Could you explain that further? It sounds like you're saying that if you specify the exact inputs, it would create hash cycle. Are you saying its *possible* to create this hash cycle, or a hash cycle will always happen if you specify the exact inputs?


So committing to the number of inputs is redundant if and only if you commit to the input sequence. But not if you don't want to commit to that sequence. Right? I'm trying to clarify my understanding here.



I don't understand the distinction you're making there. Restricting to "a specific number of inputs" and "programmatically selecting a number of inputs" sound identical to me. Could you give an example use case for this?


So are you telling me that, no, this isn't the fee issue Greg mentioned, then? I had already read the BIP. It doesn't seem to properly explain what the half-spend problem is, but seems to expect the reader to know what it is already. What is it? An example would help.


No. What I said translates to "I want to be able to arbitrarily restrict how the coins can be spent in whatever manner I want."


What mechanism is that?


The next transaction's locktime cannot be committed to. I assume that's what op_ctv's locktime commitment is as well.


Interesting. I'll need to watch more of the full video to really understand it.

Am I missing something, or is OP_CAT not really a thing anymore? The info here says its disabled. https://en.bitcoin.it/wiki/Script#Splice


Hmm, well that makes it sound like its not actually strictly redundant then. Why would you want to restrict a transaction to a specific number of inputs (other than 1) tho?


Is this the same problem Greg brought up in his first post, about "preventing an attacker from .. sending most of [the] value to fee?" Are you saying that if 2 CTV UTXOs that have the same script commit to specific outputs, both UTXOs will be spent for no reason (because the outputs are set in stone)?


What do you mean by "too general". What downside are you implying with that generality? The issue with op_ctv as it is is that it basically requires that outputs be spent one at a time, rather than allowing the wallet owner arbitrary ability to construct a transaction with as many inputs and to as many outputs as they want. This would make the use of a wallet that uses this construct a lot more expensive to use, and a lot less convenient.

It seems like there are a couple primary things you might want to do with an op like this:

1. Require that an output be spent with a specific transaction (ie you can commit to a hash of the whole transaction).
2. Require that an output be to a specific address (perhaps less some fee), or more generally, require that the transaction that spends the input must spend at least X coin to a specified address (or multiple specified addresses), where X is less than or equal to the input value and is specified in the covenant.
3. Require a particular locktime.

I must admit I'm not practiced in bitcoin scripting, but it seems like the types of things we might want a covenant to commit to is somewhat more limited than op_ctv is (less fields able to independently commit to) and at the same time provides more general abilities. I'm curious about your thoughts on what the above three mechanisms would be unable to do well that op_ctv can do better.


I'm very curious to hear what you mean by "by default leave the coins at rest".