PayJoin (P2EP) in Grin

I was playing around with a similar idea now and realized that payjoin transaction can be cheaper to store if represented a bit differently.

First we observe that if we have an input A and an output B then the private key of the B-A point does not seem to leak information about either private key of A or B. This has been mentioned a few times before on keybase and other posts.

Since both sender and receiver have their own pair (input, output) in a payjoin transaction, it means that they could both share the difference in their private keys without leaking information. This means
that a payjoin transaction could theoretically consist of:

  1. A set of inputs
  2. A set of outputs
  3. A private key for the kernel

Note that such a transaction does not have a kernel only the private key that can be merged to a kernel offset.

What’s important is that this structure keeps the monoidal property of the regular MW transaction aggregation and comes at a benefit that aggregating two payjoin transactions in such form does not add any size to the kernels because they are represented as private keys that can be merged as opposed to regular kernels.

The issue here is of course that such transactions can’t have a lock height and more importantly have no fees. @tromp mentioned that one could use this private key trick to move ‘tainted’ transaction that have 1 input and 1 output -> ObscuroJoin transaction

Payjoin has a form of 2-2 and can actually be though of as two 1-1 transactions (for which we assume sharing kernel private key is safe) that have been aggregated into a single 2-2 payjoin.

I think this means that one could create a payjoin transaction and add it to a transaction that passes by and has high fee (the strategy that John mentioned in the thread I linked) or one could share such a transaction with someone other node that is willing to pay the fees in order to gain a 2-2 obfuscation. It’s a win-win.

The benefits I see:

  • can help those that need transaction obfuscation by waiting with their payjoin transaction to catch a transaction passing by with a high fee
  • can be sold off to random people if they pay the fee for that transaction
  • theoretical maxima is a block having 1 kernel that pays for the fees and everything else is an aggregated payjoin transaction of the above form (assuming no one needed a lock height) which
    results not only in smaller chain but also better privacy because the information about the number of
    transactions is no longer that accurate due to kernels not being present.
  • it doesn’t seem to need any change to the consensus rules

The drawbacks:

  • as mentioned, Bob gives more information to Alice but makes everyone else benefit - possibly including the chain if such transaction get merged.
  • payment proofs can’t be done in the form they are done now. I suspect Alice and Bob could sign something and embed a hash in their outputs, but that would be a bit more complicated and might require them to store the UTXO and merkle proof, but I don’t really know that.

Edit: this has a fatal flaw, read the answer below

1 Like