Why isn't Payjoin the standard?
Login to reply
Replies (24)
It takes some fancy coordination to make sure that the recieve address is getting the correct expected values and that none of the participants try to double spend or not sign their txn correctly.
All while not assigning addresses to users (defeating the purpose).
It's a bit complicated for the plebs to just buy something without big brother following them.
Incentive imbalance: Payjoin senders pay mining fees for the receiver.
Don't senders usually pay the fee?
Still, hard tech problems can be solved
No, you pay your fee portion. There's not any more data than your normal transaction.
Of course, I was just offering an answer to the question.
Its an optional soft fork so since its optional in only some wallets it basically gets no adoption. It must be a protocol requirement for it to be standard, similar to ring-signatures on Monero.
Heard and thanks.
I'm still left wondering why it wouldn't be adopted then
So both wallets in the transaction need to use it?
Payjoin isn't a fork. Stop spreading blatant misinformation.
A payjoin always has at least 2 inputs, and it always consumes more data than a normal transaction.
Yes, so the incentive is to "never payjoin" as the sender and "always payjoin" as the receiver.
You are not both inputs, therefore you only pay for your portion of the transaction.
This response can be compressed to Go Fork Yourself.
You are wrong. If what you claim were actually implemented, it would create an attack vector where the sender creates a payjoin transaction at a high fee rate and burns the receiver's input.
Dude, I'm not going to argue with you suffice it to say, that's not how it works. This is not an inclient function this is a coordinated out-of-band operation. You don't just get to "set your fees." Go read this: 
How it Works | Payjoin
Learn the technical details of the payjoin protocol
Is it not a soft fork? Am I using the terminology wrong?
You're right I looked it up, I got the term wrong, optional feature not soft fork.
Yeah, at least on Cake wallet payjoin V2 requires the sender and reciever to support the feature. With v2 both don't need to be online at the same time, v1 required that both be online to process the transaction so even more niche.
By reading the responses in this thread, there's a lot of people who don't know what's happening. There's a lot of people who think they know what's happening. And then there's very few people who know what's actually happening in a payjoin.
Adoption is a lot tougher when a plurality of the users don't understand what's happening.
I really hope a lot more mobile clients start integrating payjoin but I hope as well that they implement it correctly.
I just explained how your design lets a payjoin sender could drain the receiver's wallet. Do some research before spreading misinformation:
"In exchange for the privacy benefit, the sender has to pay more fees than a normal transaction. It is a con for the sender, but a pro for the receiver, since the receiver does not have to consolidate its coin later." - @nopara73 (coinventor of payjoin)
https://nopara73.medium.com/pay-to-endpoint-56eb05d3cac6
That is not a given, the reciever can obviously include fees in their input. I don't why you feel like you can talk to me like a whiney little cunt but, it's becoming pretty annoying, especially since you continue to be incorrect. I have done an asynchronous payjoin using my own server PAYING THE FEE as a receiver. So, please shut up, thanks.
No, this is Nostr, so I don't have to shut up about you being wrong.
Payjoins are larger than normal transactions, get over it.
Blocking solves that then.