possible issue with explicit chan type negotiation compatibility with eclair nodes #5890

joostjager · 2021-10-24T17:53:03Z

In commit 235efc0, lightning.proto defines:

enum CommitmentType {
    /*
    A channel using the legacy commitment format having tweaked to_remote
    keys.
    */
    LEGACY = 0;

    /*
    A channel that uses the modern commitment format where the key in the
    output of the remote party does not change each state. This makes back
    up and recovery easier as when the channel is closed, the funds go
    directly to that key.
    */
    STATIC_REMOTE_KEY = 1;

    /*
    A channel that uses a commitment format that has anchor outputs on the
    commitments, allowing fee bumping after a force close transaction has
    been broadcast.
    */
    ANCHORS = 2;

    /*
    Returned when the commitment type isn't known or unavailable.
    */
    UNKNOWN_COMMITMENT_TYPE = 999;
}

But in master cac8da8 this changed to:

enum CommitmentType {
    /*
    Returned when the commitment type isn't known or unavailable.
    */
    UNKNOWN_COMMITMENT_TYPE = 0;

    /*
    A channel using the legacy commitment format having tweaked to_remote
    keys.
    */
    LEGACY = 1;

    /*
    A channel that uses the modern commitment format where the key in the
    output of the remote party does not change each state. This makes back
    up and recovery easier as when the channel is closed, the funds go
    directly to that key.
    */
    STATIC_REMOTE_KEY = 2;

    /*
    A channel that uses a commitment format that has anchor outputs on the
    commitments, allowing fee bumping after a force close transaction has
    been broadcast.
    */
    ANCHORS = 3;

    /*
    A channel that uses a commitment type that builds upon the anchors
    commitment format, but in addition requires a CLTV clause to spend outputs
    paying to the channel initiator. This is intended for use on leased channels
    to guarantee that the channel initiator has no incentives to close a leased
    channel before its maturity date.
    */
    SCRIPT_ENFORCED_LEASE = 4;
}

The text was updated successfully, but these errors were encountered:

alexbosworth · 2021-10-24T19:37:09Z

This was changed previous to the referenced commit: #5669 (comment)

Roasbeef · 2021-10-24T23:49:19Z

Yep, should be documented in the release notes. The issue is that in the prior version, the "default" type (0), points to the legacy commitment format, that we actually want to fully deprecate in future versions. This meant that with the new channel type funding option, if a user didn't specify a value, then they'd end up using the most insecure channel type.

The change moves "unknown" to zero, which lets us default that to the "most secure" channel type. As an example, this currently defaults to anchors, and later will be w/e initial taproot variants lands, etc, etc.

Note that this message wasn't used in any requests until now, it instead changed a field in a response, that also wasn't used anywhere else.

joostjager · 2021-10-25T06:58:31Z

Wasn't it an option to create a new enum just for the channel funding option?

I think the message was used in the ListChannels response. I ran into it when I used lncli v0.13.3-beta against a newer lnd version and got messed up commitment types in the response.

alexbosworth · 2021-10-25T15:31:45Z

One option would be to keep the current enum the same but deprecate it, and create a new commitment type enum for future types

Roasbeef · 2021-10-25T21:18:55Z

Wasn't it an option to create a new enum just for the channel funding option?

The old one wasn't used for any input, so we decided to just make a new version that's more fool proof. We'll follow the uptake during the rc phase, and are open to alternative PRs that affect existing applications less.

joostjager · 2021-10-27T21:27:38Z

I don't understand why you would make a breaking change if not absolutely necessary. It also isn't that a change in the response can't have serious consequences. Definitely wouldn't await the rc and risk not enough people reporting it.

C-Otto · 2021-10-28T06:42:40Z

Please make sure that this doesn't break connectivity to non-lnd nodes that don't support anchor channels. In my case:

I run lnd 0.14 (master) and have troubles opening a channel to ACINQ (despite already having two open channels). lnd complains about "unexpected channel type". My invocation attempt:

lncli openchannel --node_key 03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f --local_amt 49000000 --sat_per_vbyte 1 --min_confs 0 
[lncli] rpc error: code = Unknown desc = received unexpected channel type

Roasbeef · 2021-10-28T22:32:45Z

run lnd 0.14 (master) and have troubles opening a channel to ACINQ (despite already having two open channels). lnd complains about "unexpected channel type". My invocation attempt:

This is unrelated, that's due to a prior version using the wrong feature bit for new explicit channel negotiation. Are you still getting that error on the current master @C-Otto, if so then we need to investigate that further. See #5874

I don't understand why you would make a breaking change if not absolutely necessary.

The change is more future proof, as it means people don't default to known insecure or replaced channels. Before there was no way to have a "safe" default. The field wasn't used in any requests up until now, so we felt the impact wasn't as large, as say breaking an API by removing/modifying a field used as a request.

As mentioned above, if you want to propose alternatives, feel free to open a PR.

C-Otto · 2021-11-13T20:45:55Z

@Roasbeef yes, I still get the error shown above when I try to open a channel to SilentBob (02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844), which runs Eclair as far as I know.

This is with bos 11.8.2 and lnd 0.14.0-beta-rc3.

err: 
  - 503
  - UnexpectedErrorProposingChannel
  - 
    to:  02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844
    err: 
      - 503
      - UnexpectedErrorOpeningChannels
      - 
        err: 
          message: 2 UNKNOWN: received unexpected channel type
          stack: 
            - Error: 2 UNKNOWN: received unexpected channel type
            -     at Object.callErrorFromStatus (/home/bitcoin/node_modules/@grpc/grpc-js/build/src/call.js:31:26)
            -     at Object.onReceiveStatus (/home/bitcoin/node_modules/@grpc/grpc-js/build/src/client.js:331:49)
            -     at Object.onReceiveStatus (/home/bitcoin/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:299:181)
            -     at /home/bitcoin/node_modules/@grpc/grpc-js/build/src/call-stream.js:160:78
            -     at processTicksAndRejections (internal/process/task_queues.js:79:11)

C-Otto · 2021-11-14T08:35:38Z

I get this issue when SilentBob tries to open a channel to my node:

[INF] FNDG: Recv'd fundingRequest(amt=0.2 BTC, push=0 mSAT, delay=720, pendingId=f05950e58117db55e8b5230950960d5c7a91dcbb411de1842d6c8fb544df3905) from peer(02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844)
[INF] FNDG: channel type negotiation failed: explicit channel type negotiation not supported

ABAPRules · 2021-11-17T20:30:24Z

Get the same error as C-Otto also with 0.14.0-beta-rc4:

bos open 03c436af41160a355fc1ed230a64f6a64bcbd2ae50f12171d1318f9782602be601 --amount 500000

- 
  node:                        mainnet.lightningconductor.net
  channels_per_peer:           1.35
  is_accepting_large_channels: true

opening_to: 
  - mainnet.lightningconductor.net: 0.00500000

err: 
  - 503
  - UnexpectedErrorProposingChannel
  - 
    to:  03c436af41160a355fc1ed230a64f6a64bcbd2ae50f12171d1318f9782602be601
    err: 
      - 503
      - UnexpectedErrorOpeningChannels
      - 
        err: 
          message: 2 UNKNOWN: received unexpected channel type
          stack: 
            - Error: 2 UNKNOWN: received unexpected channel type
            -     at Object.callErrorFromStatus (/usr/lib/node_modules/balanceofsatoshis/node_modules/lightning/node_modules/@grpc/grpc-js/build/src/call.js:31:26)
            -     at Object.onReceiveStatus (/usr/lib/node_modules/balanceofsatoshis/node_modules/lightning/node_modules/@grpc/grpc-js/build/src/client.js:331:49)
            -     at Object.onReceiveStatus (/usr/lib/node_modules/balanceofsatoshis/node_modules/lightning/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:299:181)
            -     at /usr/lib/node_modules/balanceofsatoshis/node_modules/lightning/node_modules/@grpc/grpc-js/build/src/call-stream.js:160:78
            -     at processTicksAndRejections (internal/process/task_queues.js:77:11)

ABAPRules · 2021-11-17T22:06:09Z

Did the update to lnd 0.14.0-beta. The problem still occurs.
Tested with BOS 11.12.0, Thunderhub 0.12.31, RTL 0.11.2-beta and Zap iOS 0.5.2

Roasbeef · 2021-11-17T22:11:25Z

@C-Otto sounds like an older eclair node? That's returned if you're setting a an explicit channel type, but the other party doesn't actually have the feature bit set.

Roasbeef · 2021-11-17T22:14:09Z

@ABAPRules IIRC that node is an eclair node, you'll see that error if we didn't trigger explicit channel funding, but they sent a message that tries to utilize it.

Roasbeef · 2021-11-17T22:20:04Z

Looking into the compat issue w/ eclair, seems like a difference w.r.t when the bit is set and what the other side expects if it's signalled as optional.

viaj3ro · 2021-11-18T06:52:44Z

Operator of SilentBob here. My eclair version is the very latest: 0.6.2

Roasbeef · 2021-11-18T18:54:29Z

Ok I think I have a fix here, will fast-follow with a minor release.

vertiond · 2021-11-19T17:45:20Z

I had the same issue on v0.14.0 when opening channel to a node running c-lightning v0.10.2.

Roasbeef · 2021-11-22T19:13:37Z

@vertiond do you have logs of the error you get w/ that version of CL?

vertiond · 2021-11-22T22:28:07Z

@Roasbeef

2021-11-19 17:28:49.687 [DBG] RPCS: [openchannel] request to NodeKey(027aa40c28096f818a844b105d16c197b6b729bd429511900bfff142a292393826) allocation(us=2000000, them=0)
2021-11-19 17:28:49.700 [DBG] LNWL: Using minimum fee rate of 253 sat/kw
2021-11-19 17:28:49.700 [DBG] LNWL: Returning 324 sat/kw for conf target of 6
2021-11-19 17:28:49.700 [DBG] RPCS: [openchannel]: using fee of 324 sat/kw for funding tx
2021-11-19 17:28:49.700 [INF] FNDG: Initiating fundingRequest(local_amt=0.02 BTC (subtract_fees=false), push_amt=0 mSAT, chain_hash=00000008819873e925422c1ff0f99f7cc9bbb232af63a077a480a3633bee1ef6, peer=027aa40c28096f818a844b105d16c197b6b729bd429511900bfff142a292393826, min_confs=1)
2021-11-19 17:28:49.709 [DBG] LNWL: Returning 324 sat/kw for conf target of 3
2021-11-19 17:28:49.709 [INF] CHFD: Performing funding tx coin selection using 324 sat/kw as fee rate
2021-11-19 17:28:49.823 [WRN] CHFD: Unable to find funding output for shim intent: unable to create witness script, no funding keys
2021-11-19 17:28:50.062 [INF] FNDG: Target commit tx sat/kw for pendingID(f8b6f82f2b656a896c5b031b642c177bbad67d25ad7d264ac368f163a1f1ab36): 324
2021-11-19 17:28:50.062 [INF] FNDG: Dust limit for pendingID(f8b6f82f2b656a896c5b031b642c177bbad67d25ad7d264ac368f163a1f1ab36): 0.00000354 BTC
2021-11-19 17:28:50.062 [INF] FNDG: Starting funding workflow with ziibbm53g2fryptesjlltycy3gb6v536owslslvycfkfvkwmvkb77nid.onion:29735 for pending_id(f8b6f82f2b656a896c5b031b642c177bbad67d25ad7d264ac368f163a1f1ab36), committype=tweakless
2021-11-19 17:28:50.062 [DBG] PEER: Sending MsgOpenChannel(temp_chan_id=f8b6f82f2b656a896c5b031b642c177bbad67d25ad7d264ac368f163a1f1ab36, chain=00000008819873e925422c1ff0f99f7cc9bbb232af63a077a480a3633bee1ef6, csv=240, amt=0.02 BTC, push_amt=0 mSAT, reserve=0.0002 BTC, flags=1) to 027aa40c28096f818a844b105d16c197b6b729bd429511900bfff142a292393826@ziibbm53g2fryptesjlltycy3gb6v536owslslvycfkfvkwmvkb77nid.onion:29735
2021-11-19 17:28:50.062 [TRC] PEER: writeMessage to 027aa40c28096f818a844b105d16c197b6b729bd429511900bfff142a292393826@ziibbm53g2fryptesjlltycy3gb6v536owslslvycfkfvkwmvkb77nid.onion:29735: (*lnwire.OpenChannel)(0x2d44240)({
 ChainHash: (chainhash.Hash) (len=32 cap=32) 00000008819873e925422c1ff0f99f7cc9bbb232af63a077a480a3633bee1ef6,
 PendingChannelID: ([32]uint8) (len=32 cap=32) {
  00000000  f8 b6 f8 2f 2b 65 6a 89  6c 5b 03 1b 64 2c 17 7b  |.../+ej.l[..d,.{|
  00000010  ba d6 7d 25 ad 7d 26 4a  c3 68 f1 63 a1 f1 ab 36  |..}%.}&J.h.c...6|
 },
 FundingAmount: (btcutil.Amount) 0.02 BTC,
 PushAmount: (lnwire.MilliSatoshi) 0 mSAT,
 DustLimit: (btcutil.Amount) 0.00000354 BTC,
 MaxValueInFlight: (lnwire.MilliSatoshi) 1980000000 mSAT,
 ChannelReserve: (btcutil.Amount) 0.0002 BTC,
 HtlcMinimum: (lnwire.MilliSatoshi) 1 mSAT,
 FeePerKiloWeight: (uint32) 324,
 CsvDelay: (uint16) 240,
 MaxAcceptedHTLCs: (uint16) 483,
 FundingKey: (*btcec.PublicKey)(0x4490438)({
  Curve: (elliptic.Curve) <nil>,
  X: (*big.Int)(0x2c0d1c0)(79655608306648876057840660066570748973399184779438508948942885891767855036604),
  Y: (*big.Int)(0x2c0d1d0)(23901128785633931948136430128834994185046005528038698376253259502836943550614)
 }),
 RevocationPoint: (*btcec.PublicKey)(0x4490480)({
  Curve: (elliptic.Curve) <nil>,
  X: (*big.Int)(0x2c0d650)(13827192375094868333719018639583990949188139232524773076436136848665848063368),
  Y: (*big.Int)(0x2c0d660)(87821105785593308175082676004164320735547925677091520948847787965863483407061)
 }),
 PaymentPoint: (*btcec.PublicKey)(0x4490510)({
  Curve: (elliptic.Curve) <nil>,
  X: (*big.Int)(0x2c0dd10)(82162577227304350893201046728249396703502708049053262711979245541610083627315),
  Y: (*big.Int)(0x2c0dd70)(5010174780332425100742806304920013464935316162869569774004093362910866928009)
 }),
 DelayedPaymentPoint: (*btcec.PublicKey)(0x4490558)({
  Curve: (elliptic.Curve) <nil>,
  X: (*big.Int)(0x4588020)(74322642277440924320958183526076428770674844958243543802125905159267068529999),
  Y: (*big.Int)(0x4588030)(18931534274778826663742359096927396514648950675997873241025454336158478762290)
 }),
 HtlcPoint: (*btcec.PublicKey)(0x44904c8)({
  Curve: (elliptic.Curve) <nil>,
  X: (*big.Int)(0x2c0d9b0)(49794684449040959303709055182925868232393624871206415284446295892475305986715),
  Y: (*big.Int)(0x2c0d9c0)(106924970785058752754978053265033042516380484723743969925394760424947174201315)
 }),
 FirstCommitmentPoint: (*btcec.PublicKey)(0x45888a0)({
  Curve: (elliptic.Curve) <nil>,
  X: (*big.Int)(0x4588880)(95459368845682487125425338798963138253341155784070250583629986050279962182990),
  Y: (*big.Int)(0x4588890)(16325097387652432240331276859653597753386146369569664518879457037683968841475)
 }),
 ChannelFlags: (lnwire.FundingFlag) 1,
 UpfrontShutdownScript: (lnwire.DeliveryAddress) <nil>,
 ChannelType: (*lnwire.ChannelType)(<nil>),
 LeaseExpiry: (*lnwire.LeaseExpiry)(<nil>),
 ExtraData: (lnwire.ExtraOpaqueData) <nil>
})

2021-11-19 17:28:50.144 [DBG] PEER: Received QueryChannelRange(chain_hash=00000008819873e925422c1ff0f99f7cc9bbb232af63a077a480a3633bee1ef6, start_height=1, end_height=64923) from 027aa40c28096f818a844b105d16c197b6b729bd429511900bfff142a292393826@ziibbm53g2fryptesjlltycy3gb6v536owslslvycfkfvkwmvkb77nid.onion:29735
2021-11-19 17:28:50.144 [TRC] PEER: readMessage from 027aa40c28096f818a844b105d16c197b6b729bd429511900bfff142a292393826@ziibbm53g2fryptesjlltycy3gb6v536owslslvycfkfvkwmvkb77nid.onion:29735: (*lnwire.QueryChannelRange)(0x4458080)({
 ChainHash: (chainhash.Hash) (len=32 cap=32) 00000008819873e925422c1ff0f99f7cc9bbb232af63a077a480a3633bee1ef6,
 FirstBlockHeight: (uint32) 1,
 NumBlocks: (uint32) 64923,
 ExtraData: (lnwire.ExtraOpaqueData) (len=3 cap=512) {
  00000000  01 01 01                                          |...|
 }
})

2021-11-19 17:28:50.145 [INF] DISC: GossipSyncer(027aa40c28096f818a844b105d16c197b6b729bd429511900bfff142a292393826): filtering chan range: start_height=1, num_blocks=64923
2021-11-19 17:28:50.145 [INF] DISC: GossipSyncer(027aa40c28096f818a844b105d16c197b6b729bd429511900bfff142a292393826): sending final chan range chunk, size=0
2021-11-19 17:28:50.146 [DBG] PEER: Sending ReplyChannelRange(start_height=1, end_height=64923, num_chans=0, encoding=0) to 027aa40c28096f818a844b105d16c197b6b729bd429511900bfff142a292393826@ziibbm53g2fryptesjlltycy3gb6v536owslslvycfkfvkwmvkb77nid.onion:29735
2021-11-19 17:28:50.146 [TRC] PEER: writeMessage to 027aa40c28096f818a844b105d16c197b6b729bd429511900bfff142a292393826@ziibbm53g2fryptesjlltycy3gb6v536owslslvycfkfvkwmvkb77nid.onion:29735: (*lnwire.ReplyChannelRange)(0x2e8afa0)({
 ChainHash: (chainhash.Hash) (len=32 cap=32) 00000008819873e925422c1ff0f99f7cc9bbb232af63a077a480a3633bee1ef6,
 FirstBlockHeight: (uint32) 1,
 NumBlocks: (uint32) 64923,
 Complete: (uint8) 1,
 EncodingType: (lnwire.ShortChanIDEncoding) 0,
 ShortChanIDs: ([]lnwire.ShortChannelID) <nil>,
 ExtraData: (lnwire.ExtraOpaqueData) <nil>,
 noSort: (bool) false
})

2021-11-19 17:28:50.708 [DBG] PEER: Received MsgAcceptChannel(temp_chan_id=f8b6f82f2b656a896c5b031b642c177bbad67d25ad7d264ac368f163a1f1ab36, reserve=0.0002 BTC, csv=6, num_confs=1) from 027aa40c28096f818a844b105d16c197b6b729bd429511900bfff142a292393826@ziibbm53g2fryptesjlltycy3gb6v536owslslvycfkfvkwmvkb77nid.onion:29735
2021-11-19 17:28:50.709 [TRC] PEER: readMessage from 027aa40c28096f818a844b105d16c197b6b729bd429511900bfff142a292393826@ziibbm53g2fryptesjlltycy3gb6v536owslslvycfkfvkwmvkb77nid.onion:29735: (*lnwire.AcceptChannel)(0x316ba00)({
 PendingChannelID: ([32]uint8) (len=32 cap=32) {
  00000000  f8 b6 f8 2f 2b 65 6a 89  6c 5b 03 1b 64 2c 17 7b  |.../+ej.l[..d,.{|
  00000010  ba d6 7d 25 ad 7d 26 4a  c3 68 f1 63 a1 f1 ab 36  |..}%.}&J.h.c...6|
 },
 DustLimit: (btcutil.Amount) 0.00000546 BTC,
 MaxValueInFlight: (lnwire.MilliSatoshi) 18446744073709551615 mSAT,
 ChannelReserve: (btcutil.Amount) 0.0002 BTC,
 HtlcMinimum: (lnwire.MilliSatoshi) 0 mSAT,
 MinAcceptDepth: (uint32) 1,
 CsvDelay: (uint16) 6,
 MaxAcceptedHTLCs: (uint16) 483,
 FundingKey: (*btcec.PublicKey)(0x3278e30)({
  Curve: (elliptic.Curve) <nil>,
  X: (*big.Int)(0x3278e40)(3411208388839071929668821462220354875281721763034862870184792327457732651291),
  Y: (*big.Int)(0x3278e60)(30476359737272180888391327073409739715520132434138406608693048562908929944480)
 }),
 RevocationPoint: (*btcec.PublicKey)(0x3278e80)({
  Curve: (elliptic.Curve) <nil>,
  X: (*big.Int)(0x3278e90)(86528279280808228246133666751788054090684551092997898755284660789119947502575),
  Y: (*big.Int)(0x3278ea0)(61319776125218434864700507629325201550483931186792360055069002007562242211927)
 }),
 PaymentPoint: (*btcec.PublicKey)(0x3278eb0)({
  Curve: (elliptic.Curve) <nil>,
  X: (*big.Int)(0x3278ec0)(46707544588893902080211295256429746537922106203497884556652914181145783484077),
  Y: (*big.Int)(0x3278ed0)(64455889394533758194847345977654368845208508603045381485350422246245369051551)
 }),
 DelayedPaymentPoint: (*btcec.PublicKey)(0x3278ee0)({
  Curve: (elliptic.Curve) <nil>,
  X: (*big.Int)(0x3278ef0)(97497443728663045662475338775108583516857059574939908446703154202855627484347),
  Y: (*big.Int)(0x3278f00)(16937529343779493486466610648059974787329240853246836784692591840920002663098)
 }),
 HtlcPoint: (*btcec.PublicKey)(0x3278f10)({
  Curve: (elliptic.Curve) <nil>,
  X: (*big.Int)(0x3278f20)(49282130197655127077166237707419763456664576879124382190316027897365356269098),
  Y: (*big.Int)(0x3278f30)(102215002193746911672739938044685497153511999982774973704203591833687910465270)
 }),
 FirstCommitmentPoint: (*btcec.PublicKey)(0x3278f40)({
  Curve: (elliptic.Curve) <nil>,
  X: (*big.Int)(0x3278f50)(19916026631787780417769867912612582220888847341609053993042707225088108413098),
  Y: (*big.Int)(0x3278f60)(112620392056431693743777053239114683757304741231442114349427471978674361766893)
 }),
 UpfrontShutdownScript: (lnwire.DeliveryAddress) {
 },
 ChannelType: (*lnwire.ChannelType)(0x2f1d3b8)({
  features: (map[lnwire.FeatureBit]struct {}) (len=1) {
   (lnwire.FeatureBit) 12: (struct {}) {
   }
  }
 }),
 LeaseExpiry: (*lnwire.LeaseExpiry)(<nil>),
 ExtraData: (lnwire.ExtraOpaqueData) (len=6 cap=512) {
  00000000  00 00 01 02 10 00                                 |......|
 }
})

2021-11-19 17:28:50.711 [INF] FNDG: Recv'd fundingResponse for pending_id(f8b6f82f2b656a896c5b031b642c177bbad67d25ad7d264ac368f163a1f1ab36)
2021-11-19 17:28:50.714 [DBG] FNDG: Failing funding flow for pending_id=f8b6f82f2b656a896c5b031b642c177bbad67d25ad7d264ac368f163a1f1ab36: received unexpected channel type
2021-11-19 17:28:50.714 [INF] FNDG: Cancelling funding reservation for node_key=027aa40c28096f818a844b105d16c197b6b729bd429511900bfff142a292393826, chan_id=f8b6f82f2b656a896c5b031b642c177bbad67d25ad7d264ac368f163a1f1ab36
2021-11-19 17:28:50.714 [DBG] FNDG: Sending funding error to peer (027aa40c28096f818a844b105d16c197b6b729bd429511900bfff142a292393826): (*lnwire.Error)(0x2f02750)(chan_id=f8b6f82f2b656a896c5b031b642c177bbad67d25ad7d264ac368f163a1f1ab36, err=funding failed due to internal error)

2021-11-19 17:28:50.714 [ERR] RPCS: unable to open channel to NodeKey(027aa40c28096f818a844b105d16c197b6b729bd429511900bfff142a292393826): received unexpected channel type
2021-11-19 17:28:50.714 [ERR] RPCS: [/lnrpc.Lightning/OpenChannel]: received unexpected channel type
2021-11-19 17:28:50.714 [DBG] PEER: Sending Error(chan_id=f8b6f82f2b656a896c5b031b642c177bbad67d25ad7d264ac368f163a1f1ab36, err=funding failed due to internal error) to 027aa40c28096f818a844b105d16c197b6b729bd429511900bfff142a292393826@ziibbm53g2fryptesjlltycy3gb6v536owslslvycfkfvkwmvkb77nid.onion:29735
2021-11-19 17:28:50.715 [TRC] PEER: writeMessage to 027aa40c28096f818a844b105d16c197b6b729bd429511900bfff142a292393826@ziibbm53g2fryptesjlltycy3gb6v536owslslvycfkfvkwmvkb77nid.onion:29735: (*lnwire.Error)(0x2f02750)(chan_id=f8b6f82f2b656a896c5b031b642c177bbad67d25ad7d264ac368f163a1f1ab36, err=funding failed due to internal error)

viaj3ro · 2021-11-24T06:19:11Z

This is pretty bad and needs fixing ASAP!

LND is now incompatible with eclair and c-lightning and neither side can open channels to the other!

As more and more people upgrade their LND nodes to 0.14.0 the network gets more and more partitioned! Imho the latest release should be pulled immediately until it's fixed and rereleased with a high alert note to get people to upgrade their broken v.0.14.0 versions!

Roasbeef · 2021-11-24T16:15:44Z

So in the end, lnd's validation of a new feature was too strict, this was cleared up in this to-be merged spec PR: lightning/bolts#906. Not that this only affected the newest versions of CL+eclair that shipped with this new feature.

We've prepared #6026 which bundles this fix along with others, that will be released as part of a quick-follow 0.14.1

alexbosworth mentioned this issue Oct 26, 2021

Remove channel type data from channels alexbosworth/lightning#47

Closed

Roasbeef changed the title ~~Breaking change to enum CommitmentType?~~ possible issue with explicit chan type negotiation compatibility with eclair nodes Nov 18, 2021

Roasbeef added this to the v0.14.1 milestone Nov 18, 2021

viaj3ro mentioned this issue Nov 24, 2021

LND v.0.14.0 is incompatible with eclair and c-lightning! Please stop distributing it!!! #6023

Closed

guggero mentioned this issue Nov 24, 2021

Rebase bugfix PRs, prepare for minor release #6026

Merged

openoms mentioned this issue Nov 24, 2021

[Update] LND v0.14.1 raspiblitz/raspiblitz#2684

Closed

guggero closed this as completed in #6026 Nov 24, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

possible issue with explicit chan type negotiation compatibility with eclair nodes #5890

possible issue with explicit chan type negotiation compatibility with eclair nodes #5890

joostjager commented Oct 24, 2021

alexbosworth commented Oct 24, 2021

Roasbeef commented Oct 24, 2021

joostjager commented Oct 25, 2021

alexbosworth commented Oct 25, 2021

Roasbeef commented Oct 25, 2021

joostjager commented Oct 27, 2021

C-Otto commented Oct 28, 2021 •

edited

Loading

Roasbeef commented Oct 28, 2021

C-Otto commented Nov 13, 2021 •

edited

Loading

C-Otto commented Nov 14, 2021 •

edited

Loading

ABAPRules commented Nov 17, 2021

ABAPRules commented Nov 17, 2021 •

edited

Loading

Roasbeef commented Nov 17, 2021 •

edited

Loading

Roasbeef commented Nov 17, 2021

Roasbeef commented Nov 17, 2021

viaj3ro commented Nov 18, 2021

Roasbeef commented Nov 18, 2021

vertiond commented Nov 19, 2021

Roasbeef commented Nov 22, 2021

vertiond commented Nov 22, 2021

viaj3ro commented Nov 24, 2021 •

edited

Loading

Roasbeef commented Nov 24, 2021 •

edited

Loading

possible issue with explicit chan type negotiation compatibility with eclair nodes #5890

possible issue with explicit chan type negotiation compatibility with eclair nodes #5890

Comments

joostjager commented Oct 24, 2021

alexbosworth commented Oct 24, 2021

Roasbeef commented Oct 24, 2021

joostjager commented Oct 25, 2021

alexbosworth commented Oct 25, 2021

Roasbeef commented Oct 25, 2021

joostjager commented Oct 27, 2021

C-Otto commented Oct 28, 2021 • edited Loading

Roasbeef commented Oct 28, 2021

C-Otto commented Nov 13, 2021 • edited Loading

C-Otto commented Nov 14, 2021 • edited Loading

ABAPRules commented Nov 17, 2021

ABAPRules commented Nov 17, 2021 • edited Loading

Roasbeef commented Nov 17, 2021 • edited Loading

Roasbeef commented Nov 17, 2021

Roasbeef commented Nov 17, 2021

viaj3ro commented Nov 18, 2021

Roasbeef commented Nov 18, 2021

vertiond commented Nov 19, 2021

Roasbeef commented Nov 22, 2021

vertiond commented Nov 22, 2021

viaj3ro commented Nov 24, 2021 • edited Loading

Roasbeef commented Nov 24, 2021 • edited Loading

C-Otto commented Oct 28, 2021 •

edited

Loading

C-Otto commented Nov 13, 2021 •

edited

Loading

C-Otto commented Nov 14, 2021 •

edited

Loading

ABAPRules commented Nov 17, 2021 •

edited

Loading

Roasbeef commented Nov 17, 2021 •

edited

Loading

viaj3ro commented Nov 24, 2021 •

edited

Loading

Roasbeef commented Nov 24, 2021 •

edited

Loading