LSPS2: Remove `option_zeroconf` requirement.

[ZmnSCPxj-jr]

It turns out that some node implementations simply cannot set option_zeroconf in the open_channel message, i.e. they have no API that lets this to be set. This prevents such implementations from being used in to implement LSPS2.

The zero-confirmation need is already expressed elsewhere in LSPS2 regarding the timing of channel_ready being done immediately after funding_signed:

Depending on the `client_trusts_lsp` from the `lsps2.buy` result,
after the client has sent `funding_signed` and the LSP is willing
to broadcast the funding transaction:

* If `client_trusts_lsp` is specified and `true`:
  * The LSP MAY wait for the client to send the preimage to the
    incoming payment via a `update_fulfill_htlc` before broadcasting
    the funding transaction.
  * The client MUST NOT wait for the LSP to broadcast the funding
    transaction before sending the preimage via a 
    `update_fulfill_htlc`.
  * The client and LSP MUST immediately send `channel_ready`.
* If `client_trusts_lsp` is unspecified or `false`:
  * The client MAY wait for the funding transaction to appear in
    its mempool or the mempool of a trusted node, or confirmed in a
    block with any depth, AND confirm that the funding transaction
    output is correct, before sending `channel_ready`.
  * The LSP MUST immediately broadcast the channel funding
    transaction and send `channel_ready`.
  * The client MAY immediately send `channel_ready` (i.e. the
    client trusts the LSP, even though the LSP does not require
    that trust).

There is thus no real need to signal option_zeroconf explicitly.

Existing LSP implementations of LSPS2 that CAN signal option_zeroconf need not change --- there is no new verbiage that option_zeroconf MUST NOT be set, so setting option_zeroconf is free for the LSP. However, clients do need to be modified to no longer check for option_zeroconf existing and announce_channel=false.

@tnull @TheBlueMatt

[JssDWt]

Which implementations cannot set option_zeroconf?

[tnull]

Which implementations cannot set option_zeroconf?

LDK doesn't allow to set it as it's a superfluous feature flag that is not required for zero conf channels. Rather than the opening party setting this flag, the receiving party needs to signal minimum_depth = 0 in their accept_channel message, as they are the ones taking on the risk.

[JssDWt]

A glance around the LND codebase makes me believe most of the zero conf code is dependent on the option_zeroconf bit being set, Which me have the feeling that compatibility between LDK<->LND may depend on this decision.

[ZmnSCPxj-jr]

As noted in Feb 15 meeting, @tnull will check if LDK can open a 0-conf channel to LND and if this is not possible, we would need to retain option_zeroconf (and LDK has to provide an API to explicitly set option_zeroconf).

[ZmnSCPxj-jr]

Updated: add anounce_channels=false back.

[tnull]

A glance around the LND codebase makes me believe most of the zero conf code is dependent on the option_zeroconf bit being set, Which me have the feeling that compatibility between LDK<->LND may depend on this decision.

No, I j ust confirmed that LND<>LDK zero conf integration still works without issues if LND is client-side. Also note the last paragraph here: https://github.com/lightningnetwork/lnd/blob/master/docs/zero_conf_channels.md#responder-requirements

[JssDWt]

No, I j ust confirmed that LND<>LDK zero conf integration still works without issues if LND is client-side. Also note the last paragraph here: https://github.com/lightningnetwork/lnd/blob/master/docs/zero_conf_channels.md#responder-requirements

Thanks for testing that! Putting the section from that paragraph here for future reference:

It is possible for the responder to set the ZeroConf flag to true even when the funder did not specify the zero-conf channel type. This will only create a zero-conf channel if the funder is a non-LND node that supports this behavior. This is for compatibility with LDK nodes. In this case, the responder must know that the funder is using an implementation that supports this behavior (like LDK). The scid-alias feature bit must also have been negotiated.

[ZmnSCPxj-jr]

Thanks @tnull hopefully we can get this merged next meeting

[SeverinAlexB]

Merged as decided in todays spec meeting.