techfeudalist on Nostr: I agree with your characterization of the risks: ones that could harm the technology ...
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 ✌️
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 ✌️