Receiving with PayJoin

[Kixunil]

It'd be really nice to be able to receive with PayJoin. Currently when one sends on-chain transaction, there are actually two transactions involved - from wallet to the server and then server opening the channel. PayJoin can turn them into a single transaction.

Advantages:

1. lower fees thanks to less transactions
2. faster channel confirmation time because only one transaction needs to confirm
3. improved privacy - wallets of senders get mixed up with ACINQ funds leading to confusing chain analysis

[t-bast]

I don't think we need to go in that direction by adding explicit support (and thus custom code). We are going to replace swap-in with splice-in: that means users will be able to directly contribute their on-chain funds to their channel, without the two-transactions approach we have today (and without our node in the middle as a trusted intermediary).

When this is available, users will be completely free to provide the on-chain funds in any way they want, so they should be able to use PayJoin or any other on-chain mixing technique without Phoenix needing to understand anything about it. I think this is a more flexible and future-proof approach.

[Kixunil]

I don't believe it's possible to do safely.

A channel is 2-of-2 contract. To avoid having funds locked force close transaction has to be signed before signing funding transaction. Force close transaction still needs to know the previous txid to be constructed and signed. Txid of transaction is calculated from inputs thus inputs that will be used for funding must be known before actually performing funding. This is impossible with simple address because a wallet can not know which input will be used to pay that address.

PayJoin is currently the only specified protocol that is reasonably user-friendly and has the ability to communicate which inputs will be used before the transaction is signed. It was not originally intended for channel opening but it can be used for it in principle. Another protocol could be written that would achieve the same but that seems to be reinventing the wheel.

Of course it should be possible to combine this with splicing which would be even better.

[t-bast]

What I meant in my previous answer is that the current sequential two-transactions scheme is going to disappear anyway, so it doesn't make sense to implement a PayJoin on it now.

With splice-in, if Acinq also contributes funds (which can be automated by letting the user pay a fee for it), that will effectively be similar to a PayJoin (we'll see one on-chain tx with some inputs from the user and some inputs from Acinq, and external observers won't know what inputs contribute to what side of the channel). Would that be a good enough outcome?

[Kixunil]

You mean current two-transaction scheme will be replaced with a different two-transaction scheme?

I proposed PayJoin (the specific protocol BIP78, not the general concept) mainly to turn it into single-transaction scheme - the wallet of payer funds the channel of payee using PSBT.

I already started writing a special PayJoin server for this on top of LND but got stuck because LND needlessly requires the transaction to be signed in the last step (the devs are considering removing this restriction). I would be happy to write that server for Eclair as well if it had PSBT capability. :)

[t-bast]

You mean current two-transaction scheme will be replaced with a different two-transaction scheme?

It's better than that, with splicing the existing two-transaction scheme will be replaced by a single transaction. That's why I think this effort isn't necessary.

Right now there is:

• tx1 -> from user to acinq
• then tx2 -> from acinq to user (channel-open)

Instead there will be a single splicing (or dual funding) transaction where both user and acinq can contribute funds that will update the channel's capacity (or create a channel if you don't have one already). I'm hoping that this can entirely replace all swaps (and provide a trustless solution).

[Kixunil]

I don't see how splicing can enable signing commitment transaction before you know which input will be used for funding. Can you explain?

[t-bast]

This is explained in the interactive-tx proposal: lightning/bolts#851
You do know the inputs, the two channel participants exchange messages to collaboratively construct the transaction.

[Kixunil]

You do know the inputs

How? If I show the wallet address to someone using e.g. Wasabi how am I supposed to know which input he will use to send it to my wallet? Or rather, how can the wallet know?

I don't see anything in that proposal that suggest this being possible.

[t-bast]

The flow will change, Phoenix won't show a receiving address.
Instead Phoenix will create a PSBT, and the user will have to fund this PSBT (with any PSBT-compatible Bitcoin wallet).
Then the user will scan the updated PSBT from Phoenix which will complete the flow.
I haven't surveyed yet PSBT support from existing wallets and how easy it will be to fund a PSBT, but this is such a widely useful feature that I hope it will (eventually) be very smooth.

[Kixunil]

So it's two scans? That won't be very user-friendly. :( Current flow is very user-friendly and backwards-compatible. If PayJoin is not optimal for some reason, perhaps a new LNURL subprotocol would work?

[t-bast]

Maybe worth investigating an LN-url subprotocol. We're very early in the design phase so nothing's set in stone, but what's certain is that we want to remove the trust component in the current swap-in mechanism and splicing offers a large enough design space to achieve that.