Payjoin - bip78 crate

[Kixunil]

I noticed there's payjoin task in README, I guess it's not a priority but you may want to know that I'm working on a bip78 crate which could be helpful. Will be happy to receive a feedback on it.

Feel free to close this to de-noise if you like.

[chris-belcher]

I'm not thinking of using bip78 but instead a specific protocol for payjoins between coinswap peers. It would happen at the same time as the protocol negotiation for the coinswap itself. BIP78 uses http while teleport already has its own protocol, plus bip78 doesn't have decoy UTXOs.

More details on what I'm thinking of doing: https://gist.github.com/chris-belcher/9144bd57a91c194e332fb5ca371d0964#payjoin-with-coinswap

[Kixunil]

I wonder if BIP78 could still be used for some operations. Similarly to how I (ab)use it to open LN channels ;)

[Kixunil]

I've read the description and noticed one more attack vector: Alice could contact multiple Bobs at the same time using same UTXO. Only one transaction would confirm obviously but Alice attacks unlimited number of Bobs.

Possible mitigation: Alice also uses a fidelity bond and is required to send a signed message to Bob who then broadcasts it to known boards and waits a bit. If two conflicting messages are present Bobs abort and start ignoring the bond of Alice until it's moved. This leaks that these two participants are swapping but doesn't leak which UTXOs they are swapping so should be fine.

[Kixunil]

More thinking: I strongly believe combining receiving over BIP78 with swap is doable and even beneficial:

• Batches two operations saving fees while still being indistinguishable
• Confuses Bob who doesn't know whether all, subset of or none of the inputs belong to Alice
• Improves UX: the user doesn't have to fund the teleport wallet in a separate transaction
• Could cluster three wallets (payer, receiver/Alice, Bob) in a single transaction if defense against spying didn't require Alice signing first (not sure how to achieve it, maybe Alice having bond can be reused but it sucks that the payer may now harm Alice)

It's doable because the transaction is very similar to channel opening and channel opening is already possible today.

If the protocol is modified to enable replacing the transaction before broadcast then client can also be combined with BIP78 which would be a cool way to anonymize the change.

[chris-belcher]

I've read the description and noticed one more attack vector: Alice could contact multiple Bobs at the same time using same UTXO. Only one transaction would confirm obviously but Alice attacks unlimited number of Bobs.

I don't see how multiple Bobs changes anything? Alice can also probe the same Bob multiple times.

The defence against this I see is decoy UTXOs.

Fidelity bonds being required by Alice would also work, but really degrades the UX because it means ordinary users who take the role of Alice now need to create fidelity bonds. Also I don't think it would work as well as decoy UTXOs, since Alice still discovers Bob's UTXOs, she just has to pay for it.

[Kixunil]

Alice can send signed transaction to each Bob reusing the same UTXO. Only one of the transactions gets confirmed, so Alice only pays once. If Alice attacks 10 Bobs at once she learns 10 UTXOs for the same price as learning 1 UTXO. This works even when decoy UTXOs are used.

Alice still discovers Bob's UTXOs, she just has to pay for it.

Same applies when Alice repeats the protocol with Bob multiple times.

but really degrades the UX

Yes, maybe some privacy-conscious people would be willing to accept it?

[chris-belcher]

Ah I see! I didn't think of that attack. I think I have another solution:

The bitcoin network won't allow Alice's UTXO to be spent multiple times, even for unconfirmed transactions. So this attack works only if Alice really times it right and gets all the maker Bobs to broadcast the payjoin transaction at nearly the same time. Then Alice has to have a wide view of the network to be able to see all those conflicting unconfirmed transactions involving her own UTXO.

There is something we can do to make this attack harder: have the maker Bobs wait. Makers should pick a random time between zero and (say) 5 minutes, and broadcast the payjoin after that time. If they see a conflicting transaction on the network before they broadcast then they won't broadcast (Their bitcoin node with sendrawtransaction does this automatically anyway). This should make it really hard for an attacking Alice to get all the maker Bobs to broadcast at nearly the same time. We can choose the "5 minutes" parameter carefully, perhaps depending on how many other makers are in the offerbook, to have the success rate of the attack be as small as possible.

Another alternative to fidelity bonds that might be worth considering is proof of discrete log equivalence (PoDLE) of Alice's UTXOs, which then get shared. This is used in Joinmarket to add costs to a similar attack like this. It also degrades the UX a little bit, more than decoy UTXOs but less than fidelity bonds.

Yes, maybe some privacy-conscious people would be willing to accept it?

The reason I'm hesitant is I'd really want as many people as possible to create privacy transactions, even if they're just on the fence and don't care a huge amount but just care a little bit about privacy.

[Kixunil]

Random delay sounds good even though it also worsens UX a bit. (Strange it's not in BIP78.) Agree with making private transactions as accessible as possible.

[chris-belcher]

It shouldn't worsen UX that much, since users already have to wait for transactions to be confirmed which takes 10 minutes or even more if the user wants to save on miner fees. Plus they'll have to be random delays between transactions just to increase the anonymity set. CoinSwap will be slow (and on-chain transactions generally). Equal-Output CoinJoin and JoinMarket are already pretty slow if you use them properly like with joinmarket's tumbler script.