[WIP] Payjoins support #72
Conversation
There was a problem hiding this comment.
Typos:
- missing
toinwant most of the transactions be payjoins A 2-2 PayJoin transaction does not create a new output as opposed to a regular 1-2 transactionshould beA 2-2 PayJoin transaction does not create an additional output (in terms of total outputs) as opposed to a regular 1-2 transactionainstead ofaninwhich means that it can be thought of as an replacement- twice
payoins, missingj the transaction is built based on the defaults--> I would replacedefaultswithconfiguration settingswalllet--> remove onel
I agree that the sender-initiated flow should have payjoins disabled by default. This works well for exchanges since they would be doing this flow (if I understand correctly) and we don't want such a big player to have even more person-utxo relations. The invoice-flow should have them enabled by default to join graphs. We do need to make sure that most transactions go through the invoce-flow to really get the benefit of payjoins, so how can we achieve that?
| #### PayJoin transactions | ||
| PayJoin transactions are one possible way to break the common-input-ownership heuristic. They achieve this by having the receiver contribute some inputs to the transaction. | ||
| It might seem like payjoin transactions only benefit the sender while hurting the privacy of the receiver, but the receiver also wants to spend outputs in an input set with a mixed ownership. | ||
| Each transaction is an opportunity for the receiver to spend outputs on the input side that will have mixed owners. Doing so comes at a cost of showing the contributed receiver's |
There was a problem hiding this comment.
I would elaborate that the receiver benefits when he's the sender (so not in this transaction but in a different one). I would also add that there are benefits of doing a payjoin for the receiver directly in this transaction because the transaction graph from this output backwards is much larger with payjoins
There was a problem hiding this comment.
thanks for the comments, I think the graph theory related comments should be addressed in its own section, perhaps privacy analysis or something. I have a todo for that and will address them there 👍
| An important thing to note here is that if there are very few or no payjoins happening on the network, this same receiver could in a future transaction spend multiple inputs together and | ||
| show their spent inputs not only to the transacting party, but to everyone else as well, which seems like a worse privacy tradeoff than doing payjoins. Spending multiple inputs together | ||
| is not uncommon, so we want most of the transactions be payjoins to help us obfuscate our own inputs when we spend them. A positive side effect of doing a payjoin as a receiver is that | ||
| we consolidate some of the outputs to create an output that holds more coins, so we are less likely to come in a situation where we need to spend multiple inputs together. |
There was a problem hiding this comment.
I would add that the reduction of chains per user has the downside of converging to n (potentially one, depends on the implementation?) chains which means n transaction graphs (which in case of 1 is not good because you can then infer some info from that - eg. some output is not in your transaction graph, so you're highly unlikely to be connected with this output). So I suggest n to be big enough to not be able to infer such info (my intuition is that around 10 as it seems unlikely someone will get info of your outputs in all 10 of your transaction graphs - the probability does change though with the number of known transaction graphs though).
| is not uncommon, so we want most of the transactions be payjoins to help us obfuscate our own inputs when we spend them. A positive side effect of doing a payjoin as a receiver is that | ||
| we consolidate some of the outputs to create an output that holds more coins, so we are less likely to come in a situation where we need to spend multiple inputs together. | ||
| Having the majority of the transactions be payjoins is also beneficial for the whole network because it creates probabilistic input ownership which makes backwards chain analysis much | ||
| harder to do since we can't tell whether an input belongs to the sender of the receiver. |
There was a problem hiding this comment.
not only that, it should converge to n connected graphs (where n is pretty small, hard to guess but you get the idea), which means transaction graphs are extremely big, which is a very good thing - you want to have the graph be as big and have as many edges as possible (at least that's how it looks to me)
| Currently, PayJoin transactions are cheaper than regular transactions because they have more inputs. A 2-2 PayJoin transaction does not create a new output as opposed to a regular 1-2 transaction, | ||
| which means that it can be thought of as an replacement of the value of the current output with a new value which does not increase the UTXO set size. | ||
|
|
||
| PayJoin transactions also allow for the possibility of the receiver paying their share of fees. Whether users would find this useful is not clear yet. |
There was a problem hiding this comment.
if the receiver receives less than what he should, because he "pays" for his fees, does that count as him paying his own fees or are we strictly looking at from whose inputs the fee is paid?
There was a problem hiding this comment.
Hmm, not sure, I think the potential fee sharing is not in the scope of this RFC to avoid solving everything at once
WIP
Link to rendered text