Note: If you find anything that I may have forgotten or seems dishonest, let me know. I'll try my best to not be biased.
As John Tromp summarized:
You’re protected from replay attacks if you only do PayJoins, or txs with a (zero-valued) output of yours that you never spend. The latter would be necessary to fund a wallet. Once your wallet has n regular outputs plus a never-spent “anchor”, all your sending and receiving of payments is done with PayJoin txs that consume one of your regular outputs and produce another. n would be chosen according to how many txs you may have awaiting finalization and confirmation. A few dozen would suffice for most users. In some sending cases, you may need to use multiple inputs to provide enough value, and would then also have that many outputs.
- It seems that users can achieve kernel uniqueness without consensus changes - their wallets just need to follow some simple rules
- Creation of an anchor output is basically free
- The only idea that is new is the simplest concept ever. An output that you don't spend. Then it just leverages regular PayJoin to achieve replay protection.
- Wallet restore stays the same as do child wallets (I think)
- User doesn't necessarily need to know about the existence of anchor outputs. During a transaction, the user does not need to know that it's adding an additional input for protection.
- Since anchor outputs are supposed to be 'never-spend' outputs that have
0*H + r*Gform, they could be thought of as a wallet identity because they can be signed. This also means that we could reference a public key with only 32 bits through the TXO MMR leaf index instead of its full 'address' which is 32 bytes - PayJoin transactions are currently cheaper because they add 1 more input
- PayJoin makes it unclear which of the two inputs is the sender
- It can't protect transactions that happened in the past. Only the transaction after the anchor output are protected
- An anchor could be guessed by looking at outputs that don't move (thanks David!)
- Perhaps it's possible to do some analysis of anchor inputs and PayJoin Bob's inputs (This one needs further research)
- PayJoin shows an input of the receiver to Alice and shows receiver's input with 0.5 probability to people that see the unaggregated PayJoin tx
- Adds some size to the chain. If we had a million wallet users, we would have a million anchor outputs each of which is 700 bytes of data. This could perhaps be reduced to 32 bytes but likely at a cost of privacy. It might come as a benefit of the possibility of a consensus rule to disallow their spending though (probably best to avoid changing consensus for this). We should definitely use PayJoin as the default transaction if that was the case because regular transactions with anchor outputs would become bigger than a Bitcoin transaction because of the additional anchor output.
- It needs the rule of not allowing duplicate outputs - We already have this. This is because the whole protection relies on not allowing duplicate outputs (from the latest information I have, we don't plan to support duplicate outputs)
- Even though the solution is simple, it should still be challenged and carefully checked if it opens other attacks (this is true for any change)
- Child wallets and anchor inputs - likely we would want a Child wallet to have it's own identity/anchor though in theory it could be shared if parent is trusted
- PayJoin and obfuscation techniques I find PayJoin interesting because it general, it comes at a benefit of losing the information about the money flow direction. What this exactly means and what consequences on tracing Bob (this is a different problem than money flow direction!) is unclear to me
Disclaimer: These are my claims and I could be wrong about some things.