> 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).
matthewjablack / Matt ₿lack ⚡️🍁 13% Bitcoiner
npub1wf…qsxhy
2024-09-26 19:00:33
in reply to nevent1q…0y9p
Author Public Key
npub1wf7w8mrzqs3uvd8wsp774462d3rtttzwetuhpmzjccgn63emy4ls5qsxhyPublished at
2024-09-26 19:00:33Event JSON
{
"id": "88d7eae8bbdaab262c3f80db6b0dc677be2624d167eab5a5db437b01be5fd625",
"pubkey": "727ce3ec620423c634ee807dead74a6c46b5ac4ecaf970ec52c6113d473b257f",
"created_at": 1727377233,
"kind": 1,
"tags": [
[
"t",
"1"
],
[
"t",
"2"
],
[
"e",
"a6abb26444d62656e63b8bf3070e98e8aa16db7c08487a22802eebc83139dc60",
"",
"root"
],
[
"e",
"c9d03be9edcfc2188029e96267ff794e73a14273e00955cd5e006bc1c425d01a",
"",
"reply"
],
[
"p",
"727ce3ec620423c634ee807dead74a6c46b5ac4ecaf970ec52c6113d473b257f"
],
[
"p",
"98a386c766ac9250f4ce1b500662fd08e4d464a1915743eedc83bd50521decac"
]
],
"content": "\u003e The term “AMM” appears 19 times in that article. 🤷♂️\n\nIt doesn't talk about AMMs in relation to CTV creating on-chain AMM-style marketplaces\n\n\u003e 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.\n\nThe 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.\n\n\u003e 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.\n\nI'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. \n\nYou run into the infinite compute problem again\n\nThe 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\n\nAll that must be precomputed. It's virtually impossible to precompute all the possible states of an AMM ahead of time.\n\nThis 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. \n\n\u003e 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.\n\nThis 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. \n\nLike the number of states you need to precompute, makes the entire thing impossible. \n\n\u003e 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.\n\nYea 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. \n\nThe BIP119 PR is probably the best resource for risks discussed:\nhttps://github.com/bitcoin/bitcoin/pull/21702\n\nFor example:\n- https://github.com/bitcoin/bitcoin/pull/21702#issuecomment-825557354\n- https://github.com/bitcoin/bitcoin/pull/21702#issuecomment-1106795814\n- https://github.com/bitcoin/bitcoin/pull/21702#issuecomment-1107666137\n- https://github.com/bitcoin/bitcoin/pull/21702#issuecomment-1129462467\n- https://github.com/bitcoin/bitcoin/pull/21702#issuecomment-1335764227\n\nMost 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). ",
"sig": "eaecfd583b1fa3e9036e2ec623a4efe46e9d38dba13e136700fa4c9018c296e95033ac119569576da2b3ee3eb987ab3e167541ec0bcb74e84d6a70be03f7288f"
}