Why Nostr? What is Njump?
2024-05-18 10:51:20
in reply to

waxwing on Nostr: > Im not sure I understand your argument re cjs, is it that CISA makes batching in ...

> Im not sure I understand your argument re cjs, is it that CISA makes batching in general cheaper with cjs being a byproduct, meaning that private txs would have no economic benefit over batched txs and, assuming cjs will continue to be centrally coordinated in a fee model, cj txs continue to be less economically favorable to non-cj txs even with CISA?

Yes. Except, I don't think the coordination (centralized or not) really plays a role in this analysis. It's just that subset sum analysis works if there is no ambiguity (simplest example: inputs: (3, 7) and outputs (2,0.5,3.6,3.4)); while in theory (see Bell's number) there are always a huge number of possible interpretations *in theory*, but in practice 2 normal payments are overwhelmingly likely. The "counterarguments" I mentioned, mainly I'm thinking of at large number of utxos consumed, ambiguities start to become common. As for the last sentence: cjs are not really less economically favourable, they gain from CISA in the same way as another large tx does; the point is more: if the coinjoin is of the form of a batched payment it doesn't do anything much, whereas if you create an extra separate coinjoin in the right form to promote privacy it's an extra cost; with CISA it's just a smaller extra cost.

(Might help: i define coinjoin as any single transaction that cospends inputs of more than 1 party. see e.g. payjoin).

> Practically I think I disagree if we assume that the tx gets cheaper the bigger it gets with full aggregation – reaching sizes of 400+ inputs will likely mostly be unachievable for single signers, so i think cjs practically would have an economic benefit over non-private txs excluding fees (at least until there is non-private CISA collaboration).

Right that's another way of looking at it; if as per above coinjoin = any cospending then there's clearly a benefit to doing it, but my point is that isn't by default a "private tx". Maybe "somewhat private". By the way curious historical fact the first version of public coinjoin was by blockchain dot info and they used exactly this model, centralized, and without CISA of course - just take everyone's payments and throw them into a single big transaction. People were pretty ignorant back then 😄

> Do you have any proposals in mind that would explicitly make privacy cheaper than non-privacy?

Almost anything offchain gets this by default. *More* private and *less* expensive. LN, Ark, sidechains, rollup models etc. I remember years ago talking about this as "cutting the gordian knot of bitcoin privacy", because by default privacy techniques tend to use more space - see coinjoins, see confidential transactions; there's a natural way to create privacy by obfuscating by *adding* data. The difficulty is (1) to make offchain work *securely* is very difficult and (2) L1 always exists and so things like coinjoin IMO will always exist in some form (some level of obfuscation) but it will be at large values/sizes. As for what *that* might look like yes CISA could be involved but there's lots of ideas out there, I like a model I called "coinjoin done right" (there's a talk on youtube with that title, btc++ cdmx), based on coinjoinXT, basically trying to make coinjoin steganographic so they can't be flagged, but people are branching out and trying various things. See e.g. wabisabi for payments in coinjoin, see e.g. nothingmuch's recent work. Also just channel dual funding by et al. is a huge step forward
Author Public Key
npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7