Allow peers to use `open_channel` even if both peers support dual funding

[ErikDeSmedt]

Is it possible for peers to still use v1 if they both support dual-funing?

Here is a short motivating example. I've been struggling with defining cancellable channel-opens using v2 of the channel open protocol.

I've been trying to implemnt LSPS1 as a core-lightning plug-in.

The protocol allows an LSP-client can purchase a channel from an LSP-server. The client orders the channel and pays a BOLT-11 invoice. The server should HOLD the incoming HTLC's and attempt to open the channel. The server can claim the funds once the channel has been negotiated successfully. If the channel open fails, the server should refund the HTLC.

To implement this safely, a server must ensure that a channel open is cancelled before refunding the HTLC. If this doesn't work properly the server might refund the channel and still carry the cost of opening the channel.

To implement this I've been using the fundchannel_start, fundchannel_complete and fundchannel_cancel rpc-command.

When the server receives an incoming paymnet it will

• use fundchannel_start to negotiate the channel
• construct the funding transaction
• call fundchannel_complete to secure the commitment transaction
• claim the HTLC
• call fundchannel_complete to publish the funding-transaction

This implementation is safe it ensures

• the server never publishes a funding transaction before claiming the HTLC
• the server can always publish the channel after claiming the HTLC

This implementation is working with v1 of the open_channel protocol. However, if both peers support dual_funding this approach fails.

{
   "code": 312,
   "message": "Peer negotiated `option_dual_fund`, must use `openchannel_init` not `fundchannel_start`."
}

I'd like to avoid implementing this logic twice.

• Is it possible for peers to still use v1 if they both support dual-funding?
• Is their an alternative solution to prevent me from having to implement this logic twice?

@niftynei