Shielded CSV co-author right here.
Utilizing coinjoins in Shielded CSV to scale back on-chain price is an attention-grabbing concept. Ideally, a number of events would have the ability to produce a single joint transaction that leads to simply 64 bytes of on-chain information. Sadly, I do not see how this may be made to work with the Shielded CSV design and the reason being fairly basic to how the protocol operates. That mentioned, I don’t have a convincing argument that no client-side-validation design might ever help environment friendly coinjoins.
The on-chain price per transaction is fixed in Shielded CSV as a result of the on-chain information technically “nullifies” an account state and doesn’t spend particular person cash as we’re used to in Bitcoin. Thus, for a collaborative transaction you’d have to arrange a shared account (which is natively supported by Shielded CSV, see Part 5.1). Nonetheless, funding the shared account requires one Shielded CSV transaction per participant, defeating the aim of amortizing price by way of coinjoins.
As you observe within the feedback, with the shared account function it needs to be attainable to construct coinpool-like constructions. One complication is that apart from some eventualities (e.g., atomic swaps, see Appendix A.1.2), relying on unconfirmed transactions is insecure as a result of method blockchain reorganizations have an effect on CSV protocols that don’t leverage Bitcoin’s UTXO spending semantics. Consequently, supporting coinpool-style constructions would seemingly require further protocol options past these presently supplied by Shielded CSV, which is an attention-grabbing analysis drawback in its personal proper.
