Thanks very much for the prompt response and corrections. I understand this nuance and see how the steps I’ve described failed to describe it accurately. It is confusing to have combined Alice’s node and the Source of Funds in the flows. I’ve edited the original post to make a distinction.
The problem payjoin-in-potentiam solves
The whole point of swap-in-potentiam is that it is an onchain address, with onchain address rules (including miniimum confirmation depth), that can be magically spent in Lightning (after minimum confirmation depth). The inputs to the transaction should be swap-in-potentiam addresses, not outputs.
i.e. somebody else (NOT Alice!) funds the swap-in-potentiam address. That somebody else might not even know who the Bob is.
Swap-in-potentiam always posts two transactions. Funds are be confirmed into a swap address before a channel is opened. Payjoin-in-potentiam adds an optimistic case to the protocol. Alice generates a payjoin bip21 URI containing a swap-in-potentiam address, tells the source of funds about it and the source of funds starts a payjoin sending to the swap address with Bob. If alice is found NOT to be asleep before the payjoin protocol expires, Bob takes advantage of that and combines a channel open with proposed external input from the source of funds in a single transaction rather than confirming funds into a swap-in contract first and then following that confirmation with a channel opening transaction. If alice is asleep for the payjoin protocol (e.g. after 1 minute payjoin expiration), Bob broadcasts the original PSBT transaction funding the swap-in-potentiam address and can open a channel with the swap address funding after the fact. This cuts the on-chain footprint of swap-in-potentiam channel opens by about half in the best case and maintains the magic of swap-in-potentiam.
Fetching the public key from the LSP
There is no need for steps 1 and 2. Alice knows a public key controlled by Bob, namely, the node ID of Bob. Alice can generate its own keypair. The Alice pubkey is expected to be made by some form of BIP32 (HD derivation). The reason for not asking for a swap address is that it allows Alice to implement a watch-only onchain wallet using only BIP32 HD derivation.
At some point Alice does need to fetch Bob’s public key after which it can be derived. Neat. I’ve changed the post to reflect.
MuSig2
all inputs to the funding transaction MUST be those with the same LSP-as-Bob. The Alice keys can differ. For this reason, PSBT is specifically not used, instead this sub-protocol sends the inputs and the order of the outputs in a bespoke format. This also allows this sub-protocol to use MuSig2 path as current PSBT has no MuSig2 support yet.
Payjoin-in-potentiam removes this hard input requirement in the case that both Alice comes online before the payjoin window expires by using interaction. If Alice comes online before the payjoin expires, Alice can MuSig2 with Bob to create the channel output and create a transaction with external funds as input in a single transaction before funds land in a swap address. If the payjoin fails, funds still end up in the swap address and the swap-in-potentiam protocol is executed.
If I were designing a bespoke MuSig2 protocol, I’d still consider PSBT instead of something totally bespoke so that once the MuSig2 support is added to PSBT, software supporting PSBT already can quickly support swap-in-potentiam. Have you considered using the MuSig2 PSBT extension draft by Sanket and deployed by BitGo in your bespoke protocol?
I’m sure you’ve already thought deeply about how the bespoke sub-protocol operates, so please excuse my suggestions as naive if you’ve already given them thought. I know how hard protocol design can be and have only recently explored swap-in-potentiam as an avenue to make lightning onboarding cheaper and easier.