fundchannel reports 'Owning subdaemon openingd died (62208)' on peer disconnect after WIRE_OPEN_CHANNEL

[vincenzopalazzo]

Issue and Steps to Reproduce

When attempting to open a channel to a peer, fundchannel fails with the low-level error:

{
   "code": -1,
   "message": "Owning subdaemon openingd died (62208)",
   "data": {
      "id": "0322d0e43b3d92d30ed187f4e101a9a9605c3ee5fc9721e6dac3ce3d7732fbb13e",
      "method": "fundchannel_start"
   }
}

Command used:

lightning-cli --lightning-dir=/home/vp/.lightning-experimental/lightning -k \
  fundchannel \
  id=0322d0e43b3d92d30ed187f4e101a9a9605c3ee5fc9721e6dac3ce3d7732fbb13e@164.92.106.32:9735 \
  amount=all \
  announce=true

The relevant logs show that the connection succeeds, openingd sends WIRE_OPEN_CHANNEL, and then the peer connection is lost while waiting for accept_channel:

2026-05-04 23:06:40.354373 plugin-spenderp mfc 8, dest 0: connect 0322d0e43b3d92d30ed187f4e101a9a9605c3ee5fc9721e6dac3ce3d7732fbb13e.
2026-05-04 23:06:40.830696 connectd Connected out, starting crypto
2026-05-04 23:06:41.248657 connectd peer_out WIRE_INIT
2026-05-04 23:06:41.318478 connectd peer_in WIRE_INIT
2026-05-04 23:06:41.319001 plugin-spenderp mfc 8, dest 0: connect done.
2026-05-04 23:06:41.371062 plugin-spenderp mfc 8, dest 0: fundchannel_start 0322d0e43b3d92d30ed187f4e101a9a9605c3ee5fc9721e6dac3ce3d7732fbb13e.
2026-05-04 23:06:41.402490 openingd-chan#55 pid 921769, msgfd 95
2026-05-04 23:06:41.403137 openingd-chan#55 funder_channel_start
2026-05-04 23:06:41.403180 openingd-chan#55 Setting their reserve to 128171sat
2026-05-04 23:06:41.403217 openingd-chan#55 peer_out WIRE_OPEN_CHANNEL
2026-05-04 23:06:41.403254 openingd-chan#55 billboard: Funding channel start: offered, now waiting for accept_channel
2026-05-04 23:06:41.986147 openingd-chan#55 Peer connection lost
2026-05-04 23:06:41.986161 chan#55 Owning subdaemon openingd died (62208)
2026-05-04 23:06:41.986173 lightningd peer_disconnected
2026-05-04 23:06:42.026250 plugin-spenderp mfc 8, dest 0: failed! fundchannel_start 0322d0e43b3d92d30ed187f4e101a9a9605c3ee5fc9721e6dac3ce3d7732fbb13e: {"code":-1,"message":"Owning subdaemon openingd died (62208)"}.

There is no peer_in WIRE_ERROR in this attempt. So this seems to be a remote disconnect after our open_channel, but the RPC error returned to the user is the internal wait status / subdaemon death:

Owning subdaemon openingd died (62208)

This is confusing because it looks like openingd crashed, while the logs indicate the controlled exit path for peer connection loss.

A previous attempt with announce=false against another peer gave a clean remote error:

They sent ERROR channel ...: private channels are not accepted

So the issue here is not that every peer policy rejection is opaque; this specific case is a disconnect/EOF surfaced as a subdaemon death.

Expected behavior: fundchannel should surface something like:

Peer connection lost while waiting for accept_channel

or:

Peer disconnected during fundchannel_start after WIRE_OPEN_CHANNEL

rather than:

Owning subdaemon openingd died (62208)

I think 62208 is the parent-visible wait status for an exit status of 243 (0xf3), i.e. the status_peer_connection_lost path, but this leaks an implementation detail to the RPC user.

getinfo output

I am running an experimental build. From the current tree:

git describe: v26.04.1-50-ga7f9aae9f
commit: a7f9aae9f
branch: claude/epic-black

lightningd --version from this checkout prints:

v25.09

I can provide the full exported logs if useful.

[vincenzopalazzo]

Additional analysis after comparing with v25.05.1 and looking at LND's channel type handling.

Important caveat: I am not sure yet that this is definitely an LND interop bug or that the remote is running LND. The observation is narrower: the failure mode is consistent with the remote rejecting the open_channel we send after the post-v25.05.1 channel-type changes.

Data points so far:

• Same command/channel open succeeds with CLN v25.05.1.
• Current/experimental gets as far as:

peer_out WIRE_OPEN_CHANNEL
billboard: Funding channel start: offered, now waiting for accept_channel
Peer connection lost
Owning subdaemon openingd died (62208)

• The peer used in the failing test is:
  https://mempool.space/lightning/node/0322d0e43b3d92d30ed187f4e101a9a9605c3ee5fc9721e6dac3ce3d7732fbb13e

I looked at LND's source because the advertised features look compatible with an LND-style anchor/channel-type peer. In LND, open_channel TLV type 1 is parsed as lnwire.ChannelType, and commitment type negotiation is strict: funding/commitment_type_negotiation.go uses RawFeatureVector.OnlyContains(...). For a normal public anchors-zero-fee-HTLC channel, LND accepts the channel type containing exactly:

StaticRemoteKeyRequired        bit 12
AnchorsZeroFeeHtlcTxRequired   bit 22

i.e. channel_type = [12, 22].

LND also explicitly rejects public channels if the channel type contains option_scid_alias:

case public && scid:
    err = fmt.Errorf("option-scid-alias chantype for public channel")
    f.failFundingFlow(peer, cid, err)
    return

So the concrete thing to check in CLN is whether current/experimental sends the same open_channel.tlvs.channel_type as v25.05.1. For this peer and announce=true, I would expect exactly:

channel_type = [12,22]
channel_flags = public

Suspicious bad cases would be e.g.:

[12,22,44]   # includes option_channel_type itself
[12,22,46]   # includes scid_alias on a public channel
[12,22,50]   # includes zeroconf
[13,23]      # optional bits instead of required channel-type bits

This may explain why another peer, OKX, behaves differently:
https://mempool.space/lightning/node/0294ac3e099def03c12a37e30fe5364b1223fd60069869142ef96580c8439c2e0a

OKX accepting the public channel does not disprove this hypothesis. It may be running different software, a different LND version, different channel acceptor/policy, or it may tolerate a channel type that the first peer rejects. Earlier it rejected announce=false cleanly with private channels are not accepted, then with announce=true it apparently accepts the channel. So this might be peer/software/policy-specific interop, not universally reproducible against every node.

Suggested next debug step: add/log the open_channel fields immediately before peer_write() in openingd/openingd.c and compare v25.05.1 vs current/experimental:

channel_type
channel_flags
funding_satoshis
feerate_per_kw
channel_reserve
dust_limit
htlc_minimum
max_htlc_value_in_flight
max_accepted_htlcs
to_self_delay

The main thing I want to verify first is whether v25.05.1 sends [12,22] and current/experimental sends something different. If they are identical, then this hypothesis is probably wrong and the next suspect is another changed open_channel parameter or peer policy.

[rustyrussell]

I get the same thing with 26.02.1:

$ ./devtools/decodemsg 00206fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000bfb41fd8b52facf412c574c9eb7cd8138917683c23c709b6fedeb93dcd4b26ff00000000000186a000000000000000000000000000000222ffffffffffffffff00000000000003e80000000000000000000004e20090001e03071039feecb34261d98ff251f67565e73ec043995dfedbad3ed081b5a1b4e9fb024bdb0356d8d3fab7e40976b8358d8d25688ce3bb1bc06ce57d4948b7adde51fe020fb4cf6a5af5b7ce932cdfa2c00281ba1ea36e22d8c1cd43496f7b5dcf0f843002c79ed2ab6d347561e89299c95f2e961111fc5076667f6c3a550ffd5bc5ad881b023ff08b1517cd21f5f31ea649fe2b5bd1e5ba4373cd274f0d9ee6c1d6adadd4c00393f21665e7c8d027a838534b03ba10d9821563ea1ca586d2db7ab21e71feaf450100000103401000
WIRE_OPEN_CHANNEL:
chain_hash=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
temporary_channel_id=bfb41fd8b52facf412c574c9eb7cd8138917683c23c709b6fedeb93dcd4b26ff
funding_satoshis=100000sat
push_msat=0msat
dust_limit_satoshis=546sat
max_htlc_value_in_flight_msat=18446744073709551615msat
channel_reserve_satoshis=1000sat
htlc_minimum_msat=0msat
feerate_per_kw=1250
to_self_delay=144
max_accepted_htlcs=30
funding_pubkey=03071039feecb34261d98ff251f67565e73ec043995dfedbad3ed081b5a1b4e9fb
revocation_basepoint=024bdb0356d8d3fab7e40976b8358d8d25688ce3bb1bc06ce57d4948b7adde51fe
payment_basepoint=020fb4cf6a5af5b7ce932cdfa2c00281ba1ea36e22d8c1cd43496f7b5dcf0f8430
delayed_payment_basepoint=02c79ed2ab6d347561e89299c95f2e961111fc5076667f6c3a550ffd5bc5ad881b
htlc_basepoint=023ff08b1517cd21f5f31ea649fe2b5bd1e5ba4373cd274f0d9ee6c1d6adadd4c0
first_per_commitment_point=0393f21665e7c8d027a838534b03ba10d9821563ea1ca586d2db7ab21e71feaf45
channel_flags=1
tlvs={
type=0
len=0
(msg_name=upfront_shutdown_script)
shutdown_scriptpubkey=[]
}
{
type=1
len=3
(msg_name=channel_type)
type=[401000]
}

Those features look fine:

$ ./devtools/features 401000
option_static_remotekey/even (compulsory)
option_anchors/even (compulsory)

If it doesn't give us an error, I don't know why it doesn't like us. Maybe it only wants large channels?

[vincenzopalazzo]

No I do not think so, I am opening the same channel of the same amount for one year now. There is something wrong that it is happening with the new release

[vincenzopalazzo]

The amount of the channel was "0.1btc", which is also big enough for an LSP

[MegalithicBTC]

We operate the LND node you're trying to open to (0267d4b206e0...), running a recent version of LND. We don't think this is a channel_type issue — our node is disconnecting you at the ping/pong layer, before open_channel is ever read.

Our logs

Every connection attempt from your node dies the same way, ~300ms after init:

2026-05-04 20:51:04.917 [INF] SRVR: New inbound connection from 10.8.0.1:33708
2026-05-04 20:51:04.917 [INF] SRVR: Finalizing connection to 0267d4b206e0...@10.8.0.1:33708, inbound=true
2026-05-04 20:51:04.918 [INF] PEER: Peer(0267d4b206e0...): Negotiated chan series queries
2026-05-04 20:51:05.224 [INF] PEER: Peer(0267d4b206e0...): unable to read message from peer: pong bytes exceeded
2026-05-04 20:51:05.224 [INF] PEER: Peer(0267d4b206e0...): disconnecting ... reason: read handler closed

Same pattern on every reconnect (20:51:04, 20:51:12, 20:52:52, 20:54:35, 21:06:32, 21:06:41, 21:14:56, 21:15:38).

Why it's not channel_type

pong bytes exceeded is LND enforcing BOLT 1: the pong must contain exactly num_pong_bytes zero bytes. LND disconnects when the pong is larger than requested. This fires on the first ping/pong after init, before open_channel is processed.

That matches your CLN symptom: socket closes silently, no peer_in WIRE_ERROR, openingd dies because the connection vanished mid-flow. A channel_type rejection would send a wire-level error, not a silent close.

Likely cause

v25.05.1 works, current/experimental doesn't. LND's pong check has been stable for several releases. Probably a regression in CLN connectd ping/pong between those tags — check whether the pong payload size exceeds what my node's ping requested.

[MegalithicBTC]

Thanks, yes, should be fixed in LND in an upcoming release: lightningnetwork/lnd@08b26b6

[daywalker90]

Those features look fine:

$ ./devtools/features 401000
option_static_remotekey/even (compulsory)
option_anchors/even (compulsory)

If it doesn't give us an error, I don't know why it doesn't like us. Maybe it only wants large channels?

I know. I check features like this and it gives me onion_messages support:

lightning-cli listnodes 0322d0e43b3d92d30ed187f4e101a9a9605c3ee5fc9721e6dac3ce3d7732fbb13e
{
   "nodes": [
      {
         "nodeid": "0322d0e43b3d92d30ed187f4e101a9a9605c3ee5fc9721e6dac3ce3d7732fbb13e",
         "alias": "Megalithic.me",
         *snip*
         "features": "8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000008020808a8a51a1",
         *snip*
      }
   ]
}

devtools/features "8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000008020808a8a51a1"
option_data_loss_protect/even (compulsory)
option_upfront_shutdown_script/odd (optional)
option_gossip_queries/odd (optional)
option_var_onion_optin/even (compulsory)
option_static_remotekey/even (compulsory)
option_payment_secret/even (compulsory)
option_basic_mpp/odd (optional)
option_support_large_channel/odd (optional)
option_anchors/odd (optional)
option_route_blinding/odd (optional)
option_shutdown_anysegwit/odd (optional)
option_amp/odd (optional)
option_onion_messages/odd (optional)
option_channel_type/odd (optional)
option_keysend/odd (optional)
option_unknown_260/odd (optional)
option_unknown_2022/odd (optional)

@MegalithicBTC you either run LND from master with onion_messages support, but not the message padding fix or maybe lndk on top?

[MegalithicBTC]

Yes, we run LNDK on most of our nodes.