Nostr

Unpopular opinion: I think payjoin is silly. As a receiver I will never contribute one of my utxos. There is no incentive. All my coins have been coinjoined already, and I got paid for it. All my future coins will get coinjoined anyway.

waxwing 2y ago

Not that there's anything wrong with that position but: payjoin does do something that other coinjoins aren't doing (today): creating additional obfuscation that nobody knows happened ("steganographic"). There are other reasons to do it, perhaps, but that's the main one: a different way to break blockchain analysis and make the history of your coins even more uncertain.

Also, while you may well be paid to take part in coinjoins, bear in mind that nothing is free (e.g. if you're using maker mode in joinmarket there are several limitations, especially if you *only* use maker mode).

Reply to this note

Please Login to reply.

Discussion

Dan Gould 2y ago

An opportunity to have fees subsidized in the moment of receipt is an even greater incentive. Someone else is willing to pay fees for you to transact, so consolidation or batching in that moment is cheaper than it would be without sender contribution.

waxwing 2y ago

So, I remember when we thought about it "back in the day" we sort of concluded that "well, it doesn't technically reduce the fee costs for a merchant, if they pay for their inputs in the payjoin, but it can allow them to change when they pay fees" which could end up being better for them ... the point is really tricky.

Maybe you've thought about it recently in detail (I haven't!) so you may have a more exact perspective (btw please write it down somewhere if so!).

And then there's the scenario of a non-merchant receiver (which might apply here); it might not be relevant at all, there. Now with your new scheme, that becomes a more likely scenario than it was before.

Dan Gould 2y ago

There are two opportunities unique to payjoin to reduce fees beyond opportunistic consolidation (consolodating the incoming sats w/ existing sats can share the overhead of 1 tx)

1. transaction cut-through or forwarding: if you spend the incoming sats to someone else straight away in the same tx, you are never encumbered by fees to spend a utxo since you never take one

2. Overhead. Though indeed receivers do pay to add inputs to a payjoin, the marginal cost should be less than if they were to create their own tx to spend them since the sender is paying for the overhead of the tx header, making batching even more cost effective.

I have written the mechanics of how this could be coordinated here on substack. A few enterprise wallets have expressed interest especially since it hits their bottom line.

https://payjoin.substack.com/p/interactive-payment-batching-is-better

waxwing 2y ago

Very interesting article, thanks!

I hadn't considered (1) (cut-through) at all, at least I don't remember discussing it, but I totally agree that it's a very substantial possible angle of usage, and has economic incentive, at least if payjoin is a regular thing. A lot of it interacts with output substitution though, something we didn't discuss much until the end of the BIP78 discussion (and it was mostly motivated by address types iirc). I was and remain leery of it; as you already saw recently, it requires a very "hardened" security model, if anything is slightly off it introduces theft vectors. Still, if people get things right, for sure this kind of flexibility achieves something. It's just more dangerous.

As for (2) it feels very 'meh' to me. Even the concept that a receiver-merchant saves something is dubious because it's just kind of "cheating" the sender. And gains very little percentage wise anyway. Meanwhile you can save overhead, too, if you just accept 100 normal payments and then do a batch send of them later. (i.e. normal non-payjoin batching).

Dan Gould 2y ago

I understand how 2 could be relatively insignificant, but I definitely would not describe any aspect of it as cheating. The sender can specify their minfeerate and maximumadditionalfeecontribution to pay for 0 or more receiver inputs for privacy as well as their input + the overhead. A sender won’t sign any response that isn’t within sender-defined fee parameters.

vnprc 2y ago

Excellent point, to elaborate further i believe coinjoin makers get paid a tiny amount to join but throughput is dramatically limited. To coinjoin larger amounts you will have to pay commensurate with your time preference. Payjoin opportunistically obfuscates UTXOs at time of payment. It saves on fees compared to a standard payment + coinjoin and you can measure throughout by UTXOs joined rather than amount of sats. Payjoin is also harder to ID onchain due to coinjoin requirements for fixed denominations.

Please note: I'm referring to the more traditional coinjoin protocols. Wabisabi has a different model that I am less familiar with.

vnprc 2y ago

*throughput