I think there are two different concepts of 'danger' that apply here. One is, that a "new" OP code may cause the potential for technical failures, things that could crash nodes for example by exhausting memory. Another is seen in cases like drivechains proposals, where some argue that, if the proposed change creates economic incentives to do things other than the purest model of 'miners just mine to get fees from onchain monetary transfers', then this is a danger that may be unacceptable.
I agree about the former danger, in that conservatism w.r.t. it is very necessary, but not with the latter: trying to mandate the semantics of onchain transactions is a false trail; if people want to do bitcoin transactions whose purpose is not purely the monetary transfer onchain, you are never going to be able to stop it. The problem with the argument "well there's no reason to *encourage* them, by adding new functionality!" is simply that there is, indeed, a very good reason: in order for bitcoin to be usable at large scale, it may be (and probably is) necessary to change its expressivity so that offchain transfers become significantly more powerful than today (e.g. Lightning cannot scale to the whole planet).
My intuition is that OP_CAT is more dangerous than OP_CTV w.r.t. the 1st danger, not that I really know.
I agree with your characterization of the risks: ones that could harm the technology itself, and those that could harm the network’s decentralization.
Why we should be conservative for both:
➡️ Bitcoin is not merely a technical system. It’s also a social and economic system where incentives drive behavior. Over time, the incentives will either push the system to greater decentralization or greater centralization. Satoshi’s original incentives have been pushing the system towards greater decentralization. However, if we change these incentives, we could break what he gave us.
➡️ Devs understand technical risks but they generally aren’t experts in predicting the third order effects in dynamic systems. They have a huge blind spot. We’ve seen what happens when devs play around and mess things up (ethereum, witness discount).
➡️ You’re right, we shouldn’t try to stop abusive transactions. But we should try to prevent new classes of transactions which harm decentralization. This is a hard problem which is why we must be patient, long-term thinkers.
My perspective on CAT / CTV:
➡️ Every change to the core protocol has unknown risks. Therefore we should only make a change if it is both necessary and safe. “Necessary” means solving an existential problem that we believe cannot be solved in any other way. “Safe” means that we believe it to be safe and have reduced the attack surface as narrowly as possible to limit unintended side effects.
➡️ We can’t make risky changes to fix a potential future problem (“premature optimization”). Maybe someday there will be an existential scaling crisis, but we don’t have one right now. The mempool is clearing at a few sats/vbyte.
➡️ There are also alternatives that devs haven’t yet explored. We should exhaust all reasonable alternatives before proposing a core protocol change.
➡️ Even when we have a real problem, we should wait and see whether the pain of it can motivate creative solutions without a protocol change. Necessity being the mother of invention.
➡️ Both CTV and CAT were designed to maximize capability, enabling unknown use cases where we don’t know how they might be abused. This design philosophy is inappropriate for bitcoin (the world’s money and our hope for the future). We should instead identify key use cases (vaults?) that are absolutely essential (that can only be solved with a core protocol change) and build specific solutions, scoped as narrowly as possible to prevent unintentional side effects.
Appreciate the discussion ✌️
> They open the door to future mining centralization.
Can you elaborate on how they increase mining centralization?
From what I can see, CTV actually reduces mining centralization, by making trustless coordination-free mining pools possible. Since coinbase transaction can be constructed to send funds directly to a covenant that miners can later claim their funds from in a trustless manner, it'll dramatically reduce the reliance on pool operators for larger miners.
https://utxos.org/uses/miningpools/
> Maybe someday there will be an existential scaling crisis, but we don’t have one right now. The mempool is clearing at a few sats/vbyte.
You could make the argument that the mempool is clearing at a few sats/vB because not enough people are actually practicing self-custody. Most of the activity is on centralized exchanges or ETFs. Vaults make self-custody way more feasible and safe.
> There are also alternatives that devs haven’t yet explored. We should exhaust all reasonable alternatives before proposing a core protocol change.
Yes that is true for covenants. You can "technically" simulate a covenant on Bitcoin today by locking UTXOs with a key that must be provably destroyed. Before destroying the key, you presign the unvaultiong transaction with the spending paths you wish for the covenant.
But let's be honest, the concept of needing to literally provably destroy the private key is an incredibly terrible process prone to error. And relying entirely on pre-signed transactions to get your funds back is just terrible as well. Instead of having to backup seed phrase, you need to back up pre-signed txs.
> We should instead identify key use cases (vaults?) that are absolutely essential (that can only be solved with a core protocol change) and build specific solutions, scoped as narrowly as possible to prevent unintentional side effects.
Ironically the solution that enables effective vaults (OP_VAULT) relies on OP_CTV support
IMO risks for CTV are very well defined, and every action commited to in CTV is well defined as well
Good points.
Covenants 'open the door' to doing a whole range of things *trustlessly* or *efficiently* that are currently already being done inefficiently and/or with trusted third parties...
Absolutely 🎯
This thread contains even more discussion on the topic: 👇
And generally covenants using CTV open the door to doing a whole range of things *trustlessly* and *efficiently* in a very clear and understandable manner that doesn't leave room for unknown unknowns being introduced (especially compared to CAT). Commiting to ALL inputs and outputs reduces the attack vectors substantially IMO.
nostr:note1unr7mt6w06lax85e59dyyt9gc3mcth34sy4rue26f297rlkk64yss6sz7k
Oddbean new post about login | logout