techfeudalist on Nostr: ➡️ “Very fair point. However if folks are okay with “slow”, what’s the ...
➡️ “Very fair point. However if folks are okay with “slow”, what’s the likelihood they’re also okay with just waiting for lower feerates for their tx to be confirmed in the first place?”
They might be, but you’ll recall that this was the risk that Peter had identified in his paper — paying for cheaper transactions. My point was that Peter had overlooked the other case, specifically the risk that CTV could motivate people to pay for faster transactions. I believe both of these cases are risks and I don’t know for certain what the magnitude is (and I don’t believe anyone can know for certain — because our assumptions are based on the past and not what people might invent in the future).
➡️ “AMMs are not possible with CTV only, because there is not sufficient transaction introspection to achieve this (aka you can’t look back at previous txs which is necessary to have the price update in an AMM).”
I could imagine that this could be solved by the coordinator frequently reissuing the contracts with the current value.
Another possibility is to somehow link specific UTXOs in chains to track state. This is abstract; hope you understand what I mean.
Reissuing the contracts frequently or creating chains of UTXOs might also address your other point on the need to recalculate the contract for all the registered addresses. Creating more contract instances may reduce the complexity of trying to cram everything into one contract.
I recognize that republishing the contracts frequently would slow down trading, but again, this is me brainstorming for five minutes. Since it’s technically possible, it becomes an optimization problem. How do we know some clever person won’t solve it?
I understand your point that it looks infeasible and doubtful that a meaningful on-chain market could arise. But I recognize that this view is based on assumptions of past events, current technology, and current maturation of the bitcoin network. I don’t think we can look at it like this. We have to think about the future — the long and unknown future. Once these protocol changes are in, we can’t easily pull them out.
I believe that if something is technically possible, a sufficiently motivated person will eventually find a way. We can’t assume that it will never happen just because it seems infeasible today.
From another thread, but additional details on why I believe we should be conservative:
They might be, but you’ll recall that this was the risk that Peter had identified in his paper — paying for cheaper transactions. My point was that Peter had overlooked the other case, specifically the risk that CTV could motivate people to pay for faster transactions. I believe both of these cases are risks and I don’t know for certain what the magnitude is (and I don’t believe anyone can know for certain — because our assumptions are based on the past and not what people might invent in the future).
➡️ “AMMs are not possible with CTV only, because there is not sufficient transaction introspection to achieve this (aka you can’t look back at previous txs which is necessary to have the price update in an AMM).”
I could imagine that this could be solved by the coordinator frequently reissuing the contracts with the current value.
Another possibility is to somehow link specific UTXOs in chains to track state. This is abstract; hope you understand what I mean.
Reissuing the contracts frequently or creating chains of UTXOs might also address your other point on the need to recalculate the contract for all the registered addresses. Creating more contract instances may reduce the complexity of trying to cram everything into one contract.
I recognize that republishing the contracts frequently would slow down trading, but again, this is me brainstorming for five minutes. Since it’s technically possible, it becomes an optimization problem. How do we know some clever person won’t solve it?
I understand your point that it looks infeasible and doubtful that a meaningful on-chain market could arise. But I recognize that this view is based on assumptions of past events, current technology, and current maturation of the bitcoin network. I don’t think we can look at it like this. We have to think about the future — the long and unknown future. Once these protocol changes are in, we can’t easily pull them out.
I believe that if something is technically possible, a sufficiently motivated person will eventually find a way. We can’t assume that it will never happen just because it seems infeasible today.
From another thread, but additional details on why I believe we should be conservative:
quoting note1r4t…4sjkI 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 ✌️