Replying to Avatar L0la L33tz

Unpopular opinion, but here it goes: UX is the most important problem we need to solve for Bitcoin Privacy.

We can hate on KYC exchanges all we want, but they've got UX nailed down. We cannot expect privacy to become the norm when I have to take an hour out of my day to make a P2P trade.

Now that CASPs will start delisting privacy assets like Monero and blocking coinjoined btc with the EU's new AMLR, we're being stripped of using regulated exchanges even semi-privately. This makes P2P exchanges like BISQ Network even more important, but its of no use to regular users when you need an introductory course in computer science before understanding what's going on in the app.

Privacy will only become the norm when we make it usable for everybody. **If you're a UX designer, copywriter, or in any other way have expertise in UX design, please consider contributing BISQ:** https://github.com/bisq-network/bisq

â„šī¸ If you're not a developer, contributing to GitHub projects can be scary. It really doesn't have to be. I can't tell my asshole from a python script either, and if I can do it, you can too.

Here's how to get started:

If you find a UX issue in the BISQ app that could be improved, start by opening an issue in the BISQ github repository. Give it a clear title describing the problem you want to solve.

Add screenshots or videos to your issue showing what the problem is. If you can, add a proposal for a potential solution. Bonus points if you can add wireframes, layouts or clickdummy documentation. For reference, see npub1zqsu3ys4fragn2a5e3lgv69r4rwwhts2fserll402uzr3qeddxfsffcqrs 's work on eNuts: https://github.com/cashubtc/eNuts/issues/341 (I don't know how to tag people here but you get the idea).

In open source projects, questions are your friends. I've spent countless hours asking every dev i know absolutely insufferable questions, and I still dont know how the fuck to get out of VIM. Everybody starts somewhere, and most people are happy to help.

If you already know how to use git or github and can code a little, ask where you could find the corresponding code for your problem in your issue and offer to do a PR. If you can't, ask what assets would be needed to implement your proposal. Remember that people are nice and generally happy about new contributors, even if you're a beginner.

If you have any questions on contributing to open source projects as a non-coder, feel free to reach out anytime. My DMs are open (I think).

A separate response to a separate point:

> UX is the most important problem we need to solve for Bitcoin Privacy.

Disagree. The most important problem we need to solve for bitcoin privacy is to make it cheaper than non-privacy. Everything else follows.

(that's why focus of base chain modifications should be on changes that make higher layers achieve functional payments for all users with low costs, because decent privacy is completely natural at higher layers, whereas at base chain layer it's quite unnatural)

Reply to this note

Please Login to reply.

Discussion

I agree, but we're already doing that with CISA

CISA for privacy is a very non trivial issue. As Chris Belcher always used to point out, the simple argument "coinjoins become cheaper with CISA, therefore CISA promotes cheaper privacy" is mostly just not true, because coinjoin promotes "A is paying B, C is paying D" to happen in one transaction instead of two, but that batched transaction doesn't *by default* offer any additional privacy, because they will not modify the structure (in particular the output amounts) in a way that obfuscates the transactions. Now there are definitely counterarguments but I think that's more true than false.

And whether you get into those counterarguments or not, either way, CISA is clearly a net positive in many senses, and *at the very least* shouldn't make privacy worse (in this, I am disagreeing with https://delvingbitcoin.org/t/cisa-and-privacy/824 for example; it seems most people there argree with me)

Still, let's not jump the gun. CISA doesn't yet exist unfortunately.

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?

If I understand this correctly I agree that CISA doesn't technically address your OP. 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).

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

> 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 nostr:npub1e0z776cpe0gllgktjk54fuzv8pdfxmq6smsmh8xd7t8s7n474n9smk0txy et al. is a huge step forward

Should be 2.5,0.5 not 2,0.5 duh. Meant each input split into 2.