Description
Motivation: The C= swap-in-potentiam work-in-progress spec defines a 0-conf channel open flow, where the channel open is funded by one or more swap-in-potentiam UTXOs from the client as Alice with the LSP as Bob. The advantage of implementing the 0-conf funding flow first BEFORE implementing swaps from the swap-in-potentiam is that if the client has no channels at all yet but DOES have onchain funds in a swap-in-potentiam address, the client can immediately 0-conf-fund a channel and immediately get outbound liquidity on Lightning.
For the swap-in-potentiam 0-conf channel specifically, normally a 0-conf channel open means that the acceptor fully trusts the initiator. However, if the 0-conf channel funding is from swap-in-potentiam UTXOs only, and all swap-in-potentiam addresses have the acceptor as the Bob role and co-signer, and none of the swap-in-potentiam UTXOs are too deeply or too shallowly confirmed, then the acceptor need not trust the opener, provided the acceptor actually validates that the scriptPubKey of the funding transaction (which they sign for, as the swap-in-potentiam Bob role) matches the correct one for the channel open and therefore for the commitment transactions they make.
The scriptPubKey can be computed as soon as the two peers have exchanged open_channel and accept_channel. In LDK, the OpenChannelRquest event represents receiving the open_channel message, and the accept_inbound_channel causes accept_channel to be sent out. At accept_inbound_channel, it should be possible to know what the funding_pubkey that accept_channel will contain, and from there derive the scriptPubKey, which can then be returned to the caller.
I think it is fine to have a separate accept_inbound_channel variant, e.g. accept_inbound_channel_and_return_funding_script. However, perhaps it is simply better to have accept_inbound_channel return a Result<InboundChannelAccepted, APIError> where InboundChannelAccepted is a struct with pub fields (which can be extended later) that include the funding scriptPubKey.
In addition, swap-in-potentiam 0-conf channel funding requires #2137 or a variant of it (I believe ChannelPending event can replace the event in that PR).