matt13black on Nostr: > My point was that Peter had overlooked the other case, specifically the risk that ...
> My point was that Peter had overlooked the other case, specifically the risk that CTV could motivate people to pay for faster transactions.
Why would CTV motivate people to pay for faster transactions more than any other normal transaction? I don't see how it would create more motivation for paying OOB for faster transactions than lightning or on-chain payments.
> 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
CTV has been pretty well researched over the past 4 years since it's inception. It's gone through several iterations to make it safer. In fact there's been way more scrutiny and edge cases researched for CTV than was ever done with Taproot.
> I could imagine that this could be solved by the coordinator frequently reissuing the contracts with the current value.
The key thing here, is you can't exit the contract if your counterparty is offline. So once the DLC options contract is created, unless you've pre-signed for all the possibilities ahead of time, if your counterparty goes offline, then you can't exit, and you have to hold to expiry.
You could have dedicated market makers that take the other side of contracts, but that means the market maker can't exit if their counterparty goes offline, making this process very capital inefficient (not to mention you can't do portfolio margining obviously, since risk is defined within the DLC contract itself).
So unless you have all those pre-signed outcomes, you won't have secondary markets. But you won't have secondary markets without infinite compute.
So as much as I would like that use case to work, CTV just doesn't enable it.
CAT on the other hand would enable it, since you can commit to specific inputs and outputs, whereas with CTV you must commit to ALL inputs and outputs.
This is why CTV is actually incredibly conservative. At face value things that you think are possible, aren't actually possible. It's a very restrictive covenant scheme.
Why would CTV motivate people to pay for faster transactions more than any other normal transaction? I don't see how it would create more motivation for paying OOB for faster transactions than lightning or on-chain payments.
> 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
CTV has been pretty well researched over the past 4 years since it's inception. It's gone through several iterations to make it safer. In fact there's been way more scrutiny and edge cases researched for CTV than was ever done with Taproot.
> I could imagine that this could be solved by the coordinator frequently reissuing the contracts with the current value.
The key thing here, is you can't exit the contract if your counterparty is offline. So once the DLC options contract is created, unless you've pre-signed for all the possibilities ahead of time, if your counterparty goes offline, then you can't exit, and you have to hold to expiry.
You could have dedicated market makers that take the other side of contracts, but that means the market maker can't exit if their counterparty goes offline, making this process very capital inefficient (not to mention you can't do portfolio margining obviously, since risk is defined within the DLC contract itself).
So unless you have all those pre-signed outcomes, you won't have secondary markets. But you won't have secondary markets without infinite compute.
So as much as I would like that use case to work, CTV just doesn't enable it.
CAT on the other hand would enable it, since you can commit to specific inputs and outputs, whereas with CTV you must commit to ALL inputs and outputs.
This is why CTV is actually incredibly conservative. At face value things that you think are possible, aren't actually possible. It's a very restrictive covenant scheme.