matt13black on Nostr: > That’s true, but I think you’re conflating two services. Well, technically, ...
> That’s true, but I think you’re conflating two services. Well, technically, there are three services (fast, regular, and slow). “Fast” would be an acceleration service for those who want faster transactions and willing to pay for speed. Regular would be the normal CPFP transaction. “Slow” would be a cheaper, slower service for those who don’t want to pay higher CPFP fees and are willing to wait.
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?
> What if there was a registration step where traders sent the coordinator or AMM a small amount to register their address, and the contracts published the next day by the AMM would include these registered addresses?
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).
Registration step with a coordinator is technically plausible, but in practice it’s computationally infeasible.
With CTV you need to pre-calculate all the possibility trees ahead of time.
For example, imagine you had 1 million addresses registered. You’re about to create an options contract that you want to be able to sell to any of the 1 million. So you need to precompute 1 million possibilities. Now imagine you want to allow that million to be able to also sell to any of the million registered as well. Well now you need to compute 1 million times 1 million combinations within your taproot tree script. Oh and if you want that 3rd sale to be able to sell to anyone, you need to do it again, creating infinite possibilities to compute.
On top of that, you’d need to also compute all the possible prices of the contract as well. For example dependent on the market price, it could sell for 0.01, 0.011, 0.012, 0.013 etc, etc. You’d typically have 100 possibilities for 0 to 0.1. To handle up to 1 BTC option price you’d need to compute an additional 1000 possibilities. So multiply all the previous million by another 1000 dependent on your price granularity.
So yea, you might be able to construct a transaction that is one time MEVable, but it can’t be continuously sold without infinite compute power. Additionally I highly doubt an on-chain market would ever form due to these restrictions
(Not to mention we haven’t even gotten into free option problem, since block confirmations take so long, that the potential for someone to RBF while they’re waiting for the block to confirm and they see the price move in the opposite direction makes these contracts infeasible in the first place)
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?
> What if there was a registration step where traders sent the coordinator or AMM a small amount to register their address, and the contracts published the next day by the AMM would include these registered addresses?
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).
Registration step with a coordinator is technically plausible, but in practice it’s computationally infeasible.
With CTV you need to pre-calculate all the possibility trees ahead of time.
For example, imagine you had 1 million addresses registered. You’re about to create an options contract that you want to be able to sell to any of the 1 million. So you need to precompute 1 million possibilities. Now imagine you want to allow that million to be able to also sell to any of the million registered as well. Well now you need to compute 1 million times 1 million combinations within your taproot tree script. Oh and if you want that 3rd sale to be able to sell to anyone, you need to do it again, creating infinite possibilities to compute.
On top of that, you’d need to also compute all the possible prices of the contract as well. For example dependent on the market price, it could sell for 0.01, 0.011, 0.012, 0.013 etc, etc. You’d typically have 100 possibilities for 0 to 0.1. To handle up to 1 BTC option price you’d need to compute an additional 1000 possibilities. So multiply all the previous million by another 1000 dependent on your price granularity.
So yea, you might be able to construct a transaction that is one time MEVable, but it can’t be continuously sold without infinite compute power. Additionally I highly doubt an on-chain market would ever form due to these restrictions
(Not to mention we haven’t even gotten into free option problem, since block confirmations take so long, that the potential for someone to RBF while they’re waiting for the block to confirm and they see the price move in the opposite direction makes these contracts infeasible in the first place)