@waxwing do you have a good understanding of how stowaway (Samourai Wallet) is implemented and how this implementation compares?

@6102 No, but I am glad you pinged me here as I wanted to say something high level.

I already see a conversation on twitter developing, and on the subreddit too, where people are (imho!) thinking in the wrong way. Payjoin is *obviously* not a panacea, or more specifically, a *guarantee* of pretty much any privacy property you might want as an individual.

To give a trivial example, if a tx is *known* to be a payjoin, it reduces to two possible payment amounts (in the normal case).

... (1/n)

@6102 ... and it's for this reason that comments like "I want the option on btcpayserver to *only use payjoin* (and never fall back to "transparent") are wrong, and in a surprising way: they actually make it *worse*!

The great thing about this method is its steganographic aspect, and that will work better exactly if some people, some of the time, are not using it.

But I mean just generally, let's not lose perspective: this is a 2-party coinjoin. It is limited at the 1 tx level.
(2/n)

@6102 What I see as the overriding problem is that people want to have a mental model with a stupidly low level of complexity ("private or not private") and I think it's obvious why they want that but ... I want a pony etc etc

Things like payjoin are "privacy boost" and "fuck up blockchain analysis". Not "I'm safe now I've switched on this button". (3/3 i guess)

@waxwing spot on. The fact that some payjoin transactions are Steganographic (one output is larger than the largest of the inputs && said output cannot be constructed from a limited subset of the inputs) should not be misunderstood to mean that all payjoins are non-trivial to figure out.

@waxwing Particularly if the snowballing of the receiver utxo's is done in a non steganographic way.

@6102 yeah the snowball case is kinda funny.

I mean, academics probably won't even bother to write papers about payjoin, because there's no guarantee here to critique. Perhaps I give them too little credit though, you could write interesting stuff about the *aggregate* effect of it being used widely, that would actually be interesting.

It's still a huge step forward inasmuch as it (a) is stega (LN isn't, on-chain) and (b) creates a higher class of amount ambiguity than just change vs payment.

@waxwing @6102
It seems more viable 'solution' doesn't come in the form of some divine privacy protocol for crafting transactions, but instead a whole cornucopia of 'pretty good' steganographic transaction constructions. 'Pretty Good Transaction Privacy', if you will :p

Being able to batch multiple incoming payments together, or batch an incoming payment with an outgoing payment (as is mentioned in the btcpayserver docs), would immediately make chainalysis much less viable.

@htimsxela @6102 yeah seems that way for on-chain payments. Very uncertain how it will evolve.

@waxwing @htimsxela

I've put some thoughts down here. I think it's easy to miss the impact that default behavior can have and the resulting heuristics that can be formed.

github.com/btcpayserver/btcpay

@6102 @htimsxela yes I saw it but haven't read it yet, thanks.

Sign in to participate in the conversation
unidentified instance

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!