Nostr Web Client

nostr:npub1nz3cd3mx4jf9paxwrdgqvchaprjdge9pj9t58mkusw74q5saajkqu0yxqu here are all the use cases of covenants (in particular CTV): https://utxos.org/uses/

techfeudalist 1y ago 💬 1

Thank you Matt 🙏

Here’s my thought process and why I push back on CTV / CAT, etc.

1. Bitcoin is our hope for the future. We can’t mess it up. We must be careful and be long-term thinkers. We can’t rush or take unnecessary risks. We’ve seen first hand how changes to ethereum have increased centralization. We don’t want to make those same mistakes for the sake of “innovation”. Which is why the ethereum devs made those changes too.

2. Any change to the core protocol is risky. Even the best devs are not omniscient. Code can have bugs and unintended side effects. For example, I believe the witness discount with segwit was a mistake and inadvertently encouraged blocks filled with jpeg spam which harmed node decentralization.

3. Because changes have unknown risks, we should only make them when we believe the change is both necessary and safe. When I say “necessary” I mean 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 we can to limit unintended side effects.

4. I believe that CTV / CAT are both unnecessary at this time and potentially dangerous.

5. I’ve explained here why I believe they are potentially dangerous

nostr:note1p90z8y2mvumnmuv3esgupt4ueqreklk8yxcf9lkvnn0gyldu88uq5xpyh6

6. Most advocates point to CTV and CAT as helping to solve bitcoin scaling and payment non-interactivity. For a variety of reasons, I believe these are nice to have but unnecessary at this time. It’s possible that we will need these features in the future but we don’t right now. There are also alternatives that devs haven’t yet explored which I believe they should do before proposing a core protocol change.

So to summarize, i do appreciate the many positive features that CTV and CAT offer. It’s just that I believe the changes are not necessary at this time and potentially dangerous.

Thanks again for the link. Happy to dive into any of these points in more detail, if you wish.

Reply to this note

Please Login to reply.

Discussion

techfeudalist 1y ago 💬 1

Matt, for point five. My client moved the note link to the bottom and not under point 5 where I put it. If you can’t find it, just let me know. 🙏

Matt Black 1y ago 💬 1

nostr:npub1ej493cmun8y9h3082spg5uvt63jgtewneve526g7e2urca2afrxqm3ndrm specifically said in his post:

"The current CTV proposal in BIP-119 has only one hashing mode, known as the DefaultCheckTemplateVerifyHash, which essentially commits to every aspect of the spending transaction in the template hash. From a practical point of view this means that in many circumstances the only available mechanism for fee payment will be CPFP. As mentioned above, this is a potential problem due to it making out-of-band fee payment a non-trivial cost savings in cases where the CTV-using transactions are small."

So he's specifically saying that out-of-band fee payment could be cost savings for small CTV-using transactions.

IMO, you could make the exact same argument for lightning force closures. Even though lightning will move to anchor outputs, which means 0 fee force closures, that will be CPFP'd thanks to "package relay". Those small transactions could have cost savings with out-of-band fee payments.

But obviously, no one is pushing against package relay. For most small transactions, out-of-band fee payments would be a small cost savings.

In fact, this statement could technically be true for any pre-signed transaction scheme. Does that mean we should never have any pre-signed transaction schemes? Hardly.

So, since this issue already exists in Bitcoin and is only relevant to very small transactions, and since CTV can actually decentralize mining even more (https://utxos.org/uses/miningpools/), I'd argue these issues are known, and the concerns with not having CTV are actually a great risk to Bitcoin. Not having covenants, IMO, is a huge risk to Bitcoin custody centralization and people choosing not to self-custody.

CAT is an entirely different beast, and I agree that the risks are much more unknown.

https://petertodd.org/2024/covenant-dependent-layer-2-review

techfeudalist 1y ago 💬 1

Thanks for the response!

Yes, it’s not clearly worded, but I think he’s saying that for small CTV transactions, it might be more expensive to use CPFP than to make a private OOB payment to a miner. And he calls this a potential problem.

I think he’s glossing over a lot, but before we get to that, let’s do a quick sync on terminology so we can make sure we’re on the same page.

Payments to miners can be public or private. A public payment is broadcast to the entire miner network and the winning miner receives it. These public payments are perfectly fine and have no risk. The key is that every miner has access and competes on hashrate as per the incentives of the mining network.

Your example of a forced lightning closure is a good example of a public payment. CPFP is another. I have no issues with publicly broadcasted presigned transactions. I agree that these aren’t risky. (And package relay is awesome too.)

Private OOB payments are the risky ones. These are payments made via private APIs to a large miner to submit or to reprioritize a transaction.

Eg, MARA’s Slipstream API:

https://x.com/JStefanop1/status/1760764664651133162

These private OOB payments create centralizing incentives. The larger miners make disproportionately more revenue than smaller miners. The greater the private revenue opportunities, the fewer the number of miners we can expect to have.

Do you agree with the distinction between public and private payments to miners?

We can chat about that more, or we can chat about why CTV has the potential to create those risky private OOB payments.

Matt Black 1y ago 💬 1

> These public payments are perfectly fine and have no risk.

Absolutely, agreed

> Your example of a forced lightning closure is a good example of a public payment.

The example I gave with anchor outputs assumes it's a forced closure with zero fees (that's the idea behind anchor outputs). The idea with it is that you can just CPFP it rather than both parties having to estimate feerates (like they do now pre-package-relay)

I would argue that OOB payments may be cheaper here than CPFP

Why construct a whole new transaction when you can just make an OOB payment to force close your zero-fee transaction into the next block?

> These private OOB payments create centralizing incentives

I definitely agree. But also if CPFP is more expensive than OOB payments in general, then this is a concern with CPFP inevitably creating centralizing incentives in general

I guess what I'm trying to get at, is how does CTV actually make this worse? It seems that centralization forces for OOB payments would be equivalent for Lightning force-closure and CTV transactions wouldn't they?

techfeudalist 1y ago 💬 1

I agree with your note.

Yes, CTV does make it worse. Peter focused on the difference in *cost* but he didn’t discuss the difference in *time*. Transactions through a private OOB API could be much faster than propagating a regular transaction through the entire network.

CTV opens up the potential to create financial marketplaces on Bitcoin. With CTV, you can run arbitrary code on chain, with the only exception being that you need to know in advance all the ways the program can return. You can use this to trade options, make atomic swaps, etc.

To learn more:

https://bitcoin.stackexchange.com/questions/106850/is-there-anything-specific-to-the-design-of-the-sapio-language-that-makes-it-wel

It seems that most bitcoiners have the impression that CTV is just “covenants” to make channel factories and payments better. I believe this is misleading. CTV is actually an advanced NEW smart contract platform that RUNS ON CHAIN.

Are you familiar with Uniswap and all the MEV opportunities created by financial trading and arbitrage?

https://www.coindesk.com/opinion/2024/07/09/mev-has-spread-to-bitcoin-in-subtler-forms-than-on-ethereum/

So, being able to trade quickly to front-run pending transactions can be profitable. CTV exacerbates the problem because it conducts everything on chain where it is visible because of the blockchain’s transparency. This trading wouldn’t be risk if it were conducted say on Liquid and later settled on bitcoin.

That article above ends with this quote:

“A fair conclusion to the preceding technobabble is this: The more complicated the thing you’re trying to do is, the more likely MEV will occur (just like in regular ol’ finance).”

I think this is true. If we add arbitrary code execution ON CHAIN, we are in uncharted waters.

Matt Black 1y ago 💬 1

> You can use this to trade options, make atomic swaps, etc.

You can trade options now using DLCs (we pioneered this at nostr:npub1at0mlcdmkakz79zzylzn03k5ntltvhvdxhhupe53asnm5zktgwus4dwshk)

Cross-chain atomic swaps have always been infeasible due to the free option problem (folks tried building them using HTLCs back in the day):

https://medium.com/@mchammond/atomic-swaps-eebd0fa8110d

> CTV is actually an advanced NEW smart contract platform that RUNS ON CHAIN.

I think this is a bit misleading, because it is not an entirely generalizable "smart contract platform" that creates a huge surface area of attack like you might see in Ethereum smart contracts. The surface area of attack is well defined, because you specify exactly what the parameters for exiting the locking script. You can create loops for example, but you must define when the loop ends. All possible states of the contract are defined ahead of time.

> Are you familiar with Uniswap and all the MEV opportunities created by financial trading and arbitrage?

As is mentioned in the article, MEV already exists on-chain on Bitcoin in the form of runes. People were sniping them right around the halving and selling at a higher price. And yet, all this activity died down, because it wasn't profitable. People learned that MEV is incredibly difficult to actually extract on Bitcoin, due to the 10 minute block times (which end up being 2 minutes or 40 minutes).

CTV does not enable an AMM to be created (CAT does, but an AMM is also extremely infeasible on Bitcoin due to the 10 minute block times once again, where slippage can be a huge concern).

What specific new MEV opportunities are opened up by CTV? In CTV you must constrain all the inputs and all the outputs, that you're committing to, so you'd have to specify ahead of time, which parties were able to snipe your transaction. It's not like anyone can try to snipe the transaction you were trying to do. And once again, even if someone specified a list of parties ahead of time, them sniping whatever type of contract is still incredible dangerous due to 10 minute block times, making it economically infeasible.

> This trading wouldn’t be risk if it were conducted say on Liquid and later settled on bitcoin.

Once again you can already do trading today of futures, options, bets using DLCs. But the key thing, is these contracts are all P2P, so there's no MEV opportunity. CTV makes DLCs better, but doesn't cause any new MEV opportunities.

I'm trying to understand exactly how someone would construct financial contracts on Bitcoin, that would be MEVable with CTV?

Matt Black 1y ago 💬 1

This thread debunks any remaining OOB concerns IMO

https://x.com/4moonsettler/status/1834337644496539779

techfeudalist 1y ago 💬 1

I don’t see how that thread debunks because it assumes a choice between one or the other. Why not both? Wouldn’t a rational actor attempt the cheaper private API transaction first? And if it didn’t complete in time, to then expand distribution, first to other private APIs and then later to public broadcast?

Also moonsettler’s analysis in the thread seems handwavy. “There is no guarantee that they would find a block in the timeframe you need it.”

Isn’t that use case dependent? What % of use cases are infeasible? And if the transaction is sent to the two biggest miners, now what % of use cases are infeasible?

Once a potential risk is identified, then proponents opine that the risk could be small. But how do they know?

I don’t know the magnitude of the risk either. How could I? To say conclusively, we would need a crystal ball to know all the ways the feature could be used or abused at any time in the future, even 100 years from now. If we get it wrong, we can’t just say “Oops!” and easily remove it.

Responses to your points:

➡️ People can trade financial contracts with DLCs.

I’m not concerned with P2P trading, with primary origination on-chain, or with secondary trading off-chain that happens independently of miners. I think the issue is secondary trading of options directly on chain.

➡️ What specific centralizing MEV is enabled by CTV?

Right now, I’m concerned about the potential for time-based and cost-based private transactions that could create centralizing MEV.

➡️ No AMM can be built with CTV / Sapio.

I think you would need to show that all AMMs must have a fundamental marketplace or contractual state that cannot be modeled by Sapio. It seems to me that if there is any possibility that there could be any secondary on-chain trading, then we can’t rule out the potential for time-based centralizing MEV through arbitrage, front-running, etc.

➡️ MEV already exists elsewhere.

Sure, but we don’t want to open the door to other abuses and make it worse. Protocol changes should do no harm.

➡️ It’s difficult to extract MEV currently.

This is a statement of what is happening today given current use cases and bitcoin’s current size and maturity. Opportunities for MEVil will change over time as new abuses develop and as bitcoin grows. Once the door is open, we can’t close it.

Matt Black 1y ago 💬 1

> I don’t see how that thread debunks because it assumes a choice between one or the other. Why not both?

So imagine you broadcast OOB to antpool which has 25% of the hashrate. That gives you an estimated average confirmation time of 40 minutes

You have a 25% chance of it being mined in 10 minutes

82.2% chance of it being mined within the hour (1-(1-0.25)^6 = 82.2)

However it could take longer than this. 96.8% chance of it being mined in 2 hours

This vs paying a high enough fee to ensure it gets in the next block.

Imagine OOB was 25% cheaper than CPFP. Would you wait longer than usual for your transaction to be mined or pay 25% more to ensure it gets in the next block? Also, if it doesn't get in within the hour, would you pay 1.5x the original cost to send it to another miner?

It seems rational actors will choose just to broadcast.

Also, in practicality, it likely wouldn't be 25% cheaper because every single OOB tx acceleration option I've seen has been substantially more expensive than just doing CPFP. Pools want to charge a premium for this service.

> I’m not concerned with P2P trading, with primary origination on-chain, or with secondary trading off-chain that happens independently of miners. I think the issue is secondary trading of options directly on chain.

> You can use this to trade options, make atomic swaps, etc.

I suspect you're referring to "decentralized options" from the utxos.org/uses/options page

To clarify, an atomic swap is a purely peer-to-peer contract

And the option contract described on the page is also peer-to-peer.

So it would not be possible for secondary trading of options directly on-chain, unless you knew the counterparties you wanted to trade with ahead of time

You would need to pre-define potential change of ownership of the sell or buy side of the contract, and specify the participants that could take the contract off your hands ahead of time, which leaves no opportunity for MEV

> I think you would need to show that all AMMs must have a fundamental marketplace or contractual state that cannot be modeled by Sapio. It seems to me that if there is any possibility that there could be any secondary on-chain trading, then we can’t rule out the potential for time-based centralizing MEV through arbitrage, front-running, etc.

The key thing with CTV, is you commit to ALL inputs, and ALL outputs

Which means all participants in a CTV commitment or string of CTV commitments, need to be known ahead of time.

By definition, an AMM needs to allow anyone to participate to take trades in either direction

Not to mention, AMM doesn't work for Runes or BRC20 tokens

There's a proposal for AMMs to work with new OP_CAT tokens, but this doesn't apply at all to CTV: https://x.com/rot13maxi/status/1833667750469804315

So in this regard CTV is extremely safe. It only enables use cases that are peer-to-peer or known-parties-to-known-parties

> MEV already exists elsewhere.

Actually with the point above that you need to specify all the parties ahead of time, I don't think MEV is a concern at all actually

If you can give me a counter-example regarding MEV I'm happy to reconsider

MEV is a concern with runes, because someone can snipe a rune in the mempool when it's being bought

But if you lock into a CTV covenant, only parties specified ahead of time in the CTV commitment can "snipe" or front-run something

techfeudalist 1y ago 💬 1

➡️ “It seems rational actors will choose just to broadcast. […] Acceleration options are more expensive.”

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.

A rational miner would offer a cheaper solution to obtain additional revenue not otherwise available. To them, it would be an option, one they could fulfill if they wanted. A rational user may be willing to wait longer for a solution that is cheaper than the default option if their transaction is not time sensitive.

➡️ “So it would not be possible for secondary trading of options directly on-chain, unless you knew the counterparties you wanted to trade with ahead of time.”

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?

I’m not particularly clever and I can see simplistic ways it might be accomplished. If I’ve learned anything in this space it’s that people are incredibly resourceful, and will find a way if the incentives are high enough.

Matt Black 1y ago 💬 1

> 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)

techfeudalist 1y ago 💬 1

➡️ “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:

nostr:note1r4tjlj5yfmpu5rkq8n8f7k3t576gaut40uf7l3yk3kwamtzcu3pq004sjk

Matt Black 1y ago 💬 2

> 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.

techfeudalist 1y ago 💬 1

➡️ “Why would CTV motivate people to pay for faster transactions more than any other normal transaction?”

It appears that it might be possible for CTV to create on-chain AMM-style marketplaces. On chain marketplaces create arbitrage opportunities which motivate people to pay for faster transactions:

https://www.coindesk.com/opinion/2024/07/09/mev-has-spread-to-bitcoin-in-subtler-forms-than-on-ethereum/

➡️ “CTV has been pretty well researched over the past 4 years since its inception.”

Please show me where the non-technical risks were discussed. I haven’t been able to find anything other than Peter identifying the risk of cheaper OOB payments.

➡️ “The key thing here, is you can't exit the contract if your counterparty is offline. So once the DLC options contract is created[…]”

It looks like you’re now referring to DLC contracts. We were previously discussing AMM style marketplaces.

You raised the issues of how the parties could be known. I suggested that a preregistration step might work.

You raised the issue whether the prices could be known. I suggested that perhaps specific UTXOs could represent points on the hyperbolic constant product curve (x * y = k) that’s used in AMM marketplaces.

You haven’t yet shown me why it’s impossible to create AMM style marketplaces using CTV.

Matt Black 1y ago 💬 1

> It appears that it might be possible for CTV to create on-chain AMM-style marketplaces. On chain marketplaces create arbitrage opportunities which motivate people to pay for faster transactions:

That article doesn't mention AMMs at all. It mentioned inscription marketplaces, like Magic Eden, which is running today, where you need to construct a PSBT to create an "ask" for a Rune (you can't even do bids). They were talking about that creating some MEV.

> Please show me where the non-technical risks were discussed. I haven’t been able to find anything other than Peter identifying the risk of cheaper OOB payments.

Great question. Let's see what folks say:

https://x.com/matthewjablack/status/1838340344607355010

utxos.org is obviously a great resource. And mailing list for previous iterations of CTV

OpTech had some things to say: https://utxos.org/analysis/optech/

> We were previously discussing AMM style marketplaces.

AMM style marketplaces can't be built with CTV.

> I suggested that perhaps specific UTXOs could represent points on the hyperbolic constant product curve (x * y = k) that’s used in AMM marketplaces.

You can't do transaction introspection with CTV, so this isn't possible

> You haven’t yet shown me why it’s impossible to create AMM style marketplaces using CTV.

You haven't shown me how you can!

First of all, you need to do multiplication to do x * y = k. You don't have OP_MUL in Bitcoin script since it was disabled back in 2010 by Satoshi. You can emulate OP_MUL using CAT in order 1400 bytes. But you cannot emulate it with just CTV.

Bitmatrix ran into this problem when they were building an AMM on Liquid. They were able to get MUL working using OP_SUBSTR and OP_CAT:

https://medium.com/bit-matrix/technical-how-does-bitmatrix-v1-multiply-two-integers-in-the-absence-of-op-mul-a58b7a3794a3

However CTV doesn't enable MUL in any capacity. You cannot create an AMM if you cannot calculate the price after a swap occurs.

techfeudalist 1y ago 💬 1

➡️ “That article doesn't mention AMMs at all.”

The term “AMM” appears 19 times in that article. 🤷‍♂️

➡️ “You can't do transaction introspection with CTV, so this isn't possible”

You don’t need introspection if the addresses are preregistered. Scanning the address will list all the UTXOs. Once you know the UTXOs then you also know the amounts.

➡️ “First of all, you need to do multiplication to do x * y = k.”

No, you don’t need multiplication if you can determine the product in another way. You might be able to create a state machine through a chain of predefined UTXOs that represent the AMM’s balance ratio.

Specifically, I’m suggesting to model the AMM's pricing curve through output UTXOs. Each UTXO represents a specific state of the liquidity pool at a point on the curve, with predefined balances of Bitcoin and tokens.

Trades are executed by consuming a state UTXO and creating a new one corresponding to the next state along the curve, effectively moving the liquidity pool's balances according to the AMM's pricing function.

CTV would enforce that only valid state transitions can occur by committing to specific transaction templates. If input A and input B, then move to point on the curve #1. But if input A and input C, then move to point #2. You’re determining the product based on the inputs provided. It has the same effect as multiplication, just doesn’t require computation or introspection.

➡️ “Great question. Let's see what folks say”

Looks like nobody responded with any information showing the non-technical risks were considered. I still haven’t seen anything either. It’s on the proponents to show safety. It would be negligent to not fully consider all risks.

Matt Black 1y ago 💬 1

> The term “AMM” appears 19 times in that article. 🤷‍♂️

It doesn't talk about AMMs in relation to CTV creating on-chain AMM-style marketplaces

> You don’t need introspection if the addresses are preregistered. Scanning the address will list all the UTXOs. Once you know the UTXOs then you also know the amounts.

The need for introspection relates to needing to look at the previous price of the AMM, to determine what the new price should be. It doesn't matter who previously did a trade for calculating the price, just that someone did, and you can verify that someone did.

> No, you don’t need multiplication if you can determine the product in another way. You might be able to create a state machine through a chain of predefined UTXOs that represent the AMM’s balance ratio.

I'm not sure how exactly this would be done, but even if it were possible to validate or invalidate certain pathways, you would still need a ridiculous amount of compute for this. CTV commit to all inputs and outputs, so you need to compute for all the possible prices for all the possible participants ahead of time.

You run into the infinite compute problem again

The key thing with CTV, is all possible states must be known ahead of time. So AMM with price x and pool of a,b,c,d....z users

All that must be precomputed. It's virtually impossible to precompute all the possible states of an AMM ahead of time.

This is specifically because you're committing to ALL inputs and outputs. If it was only committing to a subset of inputs and outputs, then you wouldn't need to precompute all the possible states ahead of time.

> CTV would enforce that only valid state transitions can occur by committing to specific transaction templates. If input A and input B, then move to point on the curve #1. But if input A and input C, then move to point #2. You’re determining the product based on the inputs provided. It has the same effect as multiplication, just doesn’t require computation or introspection.

This is an oversimplification of all the possible states. Also there isn't a good way to add funds to the AMM. You'd need to calculate all the possible states ahead of time when folks first add funds. And you'd also have to precompute anyone on the registrar that could add funds, for any amount. You'd also need to precompute anyone being able to withdraw funds from the AMM for any amount ahead of time too.

Like the number of states you need to precompute, makes the entire thing impossible.

> Looks like nobody responded with any information showing the non-technical risks were considered. I still haven’t seen anything either. It’s on the proponents to show safety. It would be negligent to not fully consider all risks.

Yea ended up getting limited visibility on that post. The main resources I've seen have been on mailing lists. But many of them were also for old versions of CTV.

The BIP119 PR is probably the best resource for risks discussed:

https://github.com/bitcoin/bitcoin/pull/21702

For example:

- https://github.com/bitcoin/bitcoin/pull/21702#issuecomment-825557354

- https://github.com/bitcoin/bitcoin/pull/21702#issuecomment-1106795814

- https://github.com/bitcoin/bitcoin/pull/21702#issuecomment-1107666137

- https://github.com/bitcoin/bitcoin/pull/21702#issuecomment-1129462467

- https://github.com/bitcoin/bitcoin/pull/21702#issuecomment-1335764227

Most of these concerns seem to be related to getting consensus on the change or confusion about the change, and I think one concern is related to complexity (raised by John).

techfeudalist 1y ago

➡️ “It doesn't talk about AMMs in relation to CTV creating on-chain AMM-style marketplaces”

Of course not. It was explaining how AMM marketplaces create centralizing MEV.

➡️ “The need for introspection relates to needing to look at the previous price of the AMM, to determine what the new price should be.”

I explained how you might create a state machine using output UTXOs to model the AMM pricing curve. If you don’t understand the concept, you could ask an AI to explain it to you.

➡️ “I'm not sure how exactly this would be done, but even if it were possible to validate or invalidate certain pathways, you would still need a ridiculous amount of compute for this.”

You don’t fully understand the concept so you assume it must take “ridiculous” compute.

I showed how it might be possible, but it may or not be feasible. I don’t know and neither do you. The point is that nobody knows for sure and it’s likely that nobody has looked into it either.

I don’t need to prove it’s safe. The people advocating for the feature do.

➡️ The BIP119 PR is probably the best resource for risks discussed

I reviewed the links you sent. I didn’t see any analysis of non-technical risks. If I missed anything, please forward it to me.

You seem like a well-read person on the topic and you can’t seem to refer me to anyone who’s done a non-technical risk assessment.

I guess we can leave it there unless you want to discuss anything further.