Sorry for taking so long to get to this. I have been travelling and this proposal has a long history (dating at least to an internal Blockstream discussion from Aug 2022) and I was strongly opposed to some early iterations of it. Let me try to summarize here:
In general, PSET (and PSBT) is not designed to carry secret data. There is some ambiguity here related to BIP32 paths and chaincodes, which are "private" but not secret (their publication would harm privacy but not break any cryptographic protocols). Value and blinding factors are similarly ambiguous but much closer to a cryptographic secret than to a mere privacy shield.
On the other hand, it's really hard to do multiparty protocols with confidential transactions without somehow sharing this secret data. (Eventually some form of turnkey production-ready general MPC might solve this but that's not the world we have today.) The blinding factors need to sum to 0 across the entire transaction which requires some sort of cooperation between different parties.
The base PSET protocol tries to manage this by exposing only "net sums" of blinding factors, which themselves are insufficient to open commitments, and by exposing zero-knowledge proof-of-knowledge of assets and values, allowing validators to confirm assets/values without having the ability to modify them. But if you want jointly-owned or jointly-constructed outputs this doesn't help you (by design). In the case of LiquiDEX, we want outputs where the value commitment is created by a different party than the asset commitment.
(To clarify, the ability to "modify" assets or values is not a blank check to an attacker, since the final commitments are signed by all participants. But in Mimblewimble-like schemes maybe there are no signatures, and similar for schemes where logic is enforced by covenant rather than by signature.)
The value blinding factor, if known, allows a 3rd party to replace a rangeproof, and also replace the encrypted sidechannel data in the rangeproof (which represents critical wallet backup data for the Elements wallet as well as a data exchange channel between senders and receivers of normal spends). Knowledge of the key does not let someone read encrypted data, nor can they encrypt data correctly (such that the original sender and receiver can read it). So we really don't want to expose that.
We introduced the SIGHASH_RANGEPROOF flag to prevent this sort of rangeproof malleability; but we mistakenly(?) made this flag cover both the rangeproof and surjection proof, and since the surjection proof commits to the total set of inputs, the flag is unusable in multiparty interactively-constructed transaction scenarios such as LiquiDEX. I mention this for completeness and to illustrate how complicated and hopeless this whole thing is from a security-modelling perspective.
The asset blinding factor, however, is pretty-much harmless other than the privacy loss and the risk that somebody might try to replace an asset commitment (which again, is visible and covered by signature). At least in ordinary use-cases where the blinding factor isn't pulling double-duty as a Mimblewimble key or encryption key or something. I'm not aware of any such "bad" use cases but I'm sure they are possible.
The "correct" way to do something like LiquiDEX is to use covenants. However, covenants are expensive, complicated to use and implement, and (until we deploy Simplicity) lack expressivity. So, this is another reason that this field should be in a proprietary liquidex area, but not a sufficient reason to oppose it entirely.
I think that's a roughly complete summary of the issues, as I remember them and was able to find in internal chat history.
ACK 594cbf29906250a641d6dfb35ead79d756f4c422
Sorry for taking so long to get to this. I have been travelling and this proposal has a long history (dating at least to an internal Blockstream discussion from Aug 2022) and I was strongly opposed to some early iterations of it. Let me try to summarize here:
SIGHASH_RANGEPROOFflag to prevent this sort of rangeproof malleability; but we mistakenly(?) made this flag cover both the rangeproof and surjection proof, and since the surjection proof commits to the total set of inputs, the flag is unusable in multiparty interactively-constructed transaction scenarios such as LiquiDEX. I mention this for completeness and to illustrate how complicated and hopeless this whole thing is from a security-modelling perspective.I think that's a roughly complete summary of the issues, as I remember them and was able to find in internal chat history.