Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Be more forgiving with lnd #2842

Merged

Conversation

@rustyrussell
Copy link
Contributor

commented Jul 25, 2019

I think there are more than enough (too many?) snarky comments in the code itself, so I'll just leave it at that.

First commit is a drive-by fix for a bug I noticed.

Edit by ZmnSCPxj:

Fixes #2847

rustyrussell added some commits Jul 25, 2019

lightningd: call disconnect notifier if other side disconnected.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
lightningd: make callers of channel_set_owner do reconnection.
There's only one caller which used the flag.

As a side-effect, now we'll try reconnect even if the previous owner
was NULL (which mainly effects the case where we couldn't create the subd).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
@ZmnSCPxj
Copy link
Collaborator

left a comment

Minor comments, mostly look ok.

lightningd/channel.c Outdated Show resolved Hide resolved
@@ -5,6 +5,8 @@ msgtype,status_peer_error,0xFFF4
# This is implied if error_for_them, but master tries not to parse packets.
msgdata,status_peer_error,channel,channel_id,
msgdata,status_peer_error,desc,wirestring,
# Take a deep breath, then try reconnecting to the precious little snowflake.

This comment has been minimized.

Copy link
@ZmnSCPxj

ZmnSCPxj Jul 25, 2019

Collaborator

...

@ZmnSCPxj

This comment has been minimized.

Copy link
Collaborator

commented Jul 25, 2019

ACK 100d0d1

Though the latest commit message seems strange.

@rustyrussell rustyrussell force-pushed the rustyrussell:guilt/ignoring-errors branch from 100d0d1 to f357f9a Jul 25, 2019

@rustyrussell

This comment has been minimized.

Copy link
Contributor Author

commented Jul 25, 2019

Though the latest commit message seems strange.

Folded that comment fix into the appropriate commit and rebased.

lightningd/peer_control.c Outdated Show resolved Hide resolved

@rustyrussell rustyrussell changed the title Be more forgiving with lnd WIP: Be more forgiving with lnd Jul 25, 2019

@ZmnSCPxj

This comment has been minimized.

Copy link
Collaborator

commented Jul 25, 2019

Looks good for now. Is this still WIP?

@rustyrussell

This comment has been minimized.

Copy link
Contributor Author

commented Jul 26, 2019

OK, will rebase to clean up now and apply. Thanks!

rustyrussell added some commits Jul 26, 2019

lightningd: add slow_reconnect flag for transient failure.
We normally reconnect after 1 second: have a flag to say wait for
60.  This will be used in the next patch which handles "soft" errors.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>


Header from folded patch 'channel_fail_transient_slowretry.patch':

fixup! lightningd: add slow_reconnect flag for transient failure.

@ZmnSCPxj points out that function is unsafe, since omitting the bool
parameter still compiled.  Make it two separate functions, each
with a distinctive name so every caller has to be fixed.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
common: add peer_error flag to treat this error as "soft".
The spec says to close the channel if they send us an error, but we
need to be more lenient to preserve channels with other
implementations.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
common: detect "sync error" from lnd.
I'm deeply reluctant to do this, as I'd thought this was fixed with
recent lnd versions.  Logs below show that it continues, with channel
loss on almost every restart.

At this rate, we risk bifurcating the network.  In fact, only four
errors my node have ever been NOT "sync error".

2018-09-12T01:21:40.671Z lightningd(1263): 03e50492eab4107a773141bb419e107bda3de3d55652e6e1a41225f06a0bbf2d56 chan #3: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel b7008735ad2425ab92bcffa2f255ba93f63e0b5c685368f308e76ca0d2a30a41: sync error

2018-12-07T06:41:26.209Z lightningd(1215): 03da1c27ca77872ac5b3e568af30673e599a47a5e4497f85c7b5da42048807b3ed chan #1038: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel 48858b0d55ae982596932ceb72584d4bb31363b9ecbaa56721b158ca4d18f5f8: sync error
2018-12-07T06:41:43.707Z lightningd(1215): 0219c2f8818bd2124dcc41827b726fd486c13cdfb6edf4e1458194663fb07891c7 chan #2508: Peer permanent failure in CHANNELD_AWAITING_LOCKIN: lightning_channeld: received ERROR channel 388b653e433773d20d74a151c552df647b74e240ef983d21a6d6c5816523b858: sync error
2018-12-07T06:41:45.553Z lightningd(1215): 03e50492eab4107a773141bb419e107bda3de3d55652e6e1a41225f06a0bbf2d56 chan #1044: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel b58e9391383bfbe848da881ab9ddd9a8987c76318d421dac6f552b0d451ff957: sync error
2018-12-07T06:41:46.501Z lightningd(1215): 0390b5d4492dc2f5318e5233ab2cebf6d48914881a33ef6a9c6bcdbb433ad986d0 chan #871: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel 91f43cb6a8c37d0be237a7c491f11d9dfad48534699fb4f076b2c0cbde964424: sync error
2018-12-07T06:41:46.985Z lightningd(1215): 03e5ea100e6b1ef3959f79627cb575606b19071235c48b3e7f9808ebcd6d12e87d chan #1026: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel 6cc360db0627b19df146ccd971570c14597b22662bbc0907a233042480e50be7: sync error
2018-12-07T06:41:47.340Z lightningd(1215): 03c2abfa93eacec04721c019644584424aab2ba4dff3ac9bdab4e9c97007491dda chan #1420: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel f363d174390bf819b47e568cb5890c8e432d61c03ba0d38d7c53996679080a74: sync error
2018-12-07T06:41:47.641Z lightningd(1215): 032679fec1213e5b0a23e066c019d7b991b95c6e4d28806b9ebd1362f9e32775cf chan #1058: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel 602dc88c7f333ed88f24c6f2c760cb53fa359a4299dfab677f6a81ca33613231: sync error

2019-01-06T10:56:47.332Z lightningd(1202): 02cdf83ef8e45908b1092125d25c68dcec7751ca8d39f557775cd842e5bc127469 chan #2608: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel 17b7c895c3feb6ae5b8209ef05044b0aa125629ef1ebc2ce6b2efb27e231533b: sync error
2019-01-06T10:57:08.896Z lightningd(1202): 0219c2f8818bd2124dcc41827b726fd486c13cdfb6edf4e1458194663fb07891c7 chan #2610: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel 52d5e3717c7b4f6b06f2b7d55aa8d904a0558706e18be981c82d2c11d4bdf82c: sync error
2019-01-06T10:57:08.950Z lightningd(1202): 02ad6fb8d693dc1e4569bcedefadf5f72a931ae027dc0f0c544b34c1c6f3b9a02b chan #7185: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel 245438c15a986b53da7694114c646b77ab663d236d7928732764f5b9251cd2d1: sync error

2019-01-15T09:15:26.882Z lightningd(1191): 03a76b80027d7c067e0da77da95880faaf89e9bf87b73a7d57bd4a3f2a124b764f chan #7430: Peer permanent failure in CHANNELD_AWAITING_LOCKIN: lightning_channeld: received ERROR channel 97c1e01612faf5653af2980abdf382c0f3b24d8a5961b6a3a1eb12444cf9db2e: sync error

2019-05-02T11:32:06.511Z lightningd(14815): 036e8a8efeb26f3cffce99f462839ef6ea3b1691d569d59c402be0d3d6cef9b79c chan #7573: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel 6766b0b14013de753f9b354ce7a4b6e4756165ef970aae2650aeda990cfe5687: sync error

2019-06-12T10:38:57.503Z lightningd(1264): 024d2387409269f3b79e2708bb39b895c9f4b6a8322153af54eba487d4993bf60f chan #9607: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel 1f3111399c670dab87b4e3d7bac22865c29d4c9992df71fdce9e8893666a08bc: sync error
2019-06-12T10:41:00.435Z lightningd(1264): 02809e936f0e82dfce13bcc47c77112db068f569e1db29e7bf98bcdd68b838ee84 chan #9332: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel a31b5252be9b001f573e00310ea9098532c81322389aa8721946185b1b70ca4c: sync error
2019-06-12T10:46:23.097Z lightningd(1264): 02fcdb04f51d61dddc0481c10751173d523e3408ebe3a848a1d6cb34b1f5df6668 chan #7586: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel bd18e98f5bd56ac73e7b2eb7fd70f6dbe3a4dda1e5bebe7bf6484c3a0f6b55e7: sync error
2019-06-12T10:46:24.627Z lightningd(1264): 03bb88ccc444534da7b5b64b4f7b15e1eccb18e102db0e400d4b9cfe93763aa26d chan #9626: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel 345e89c2f0100257940aff7413c1e29786d08b0a1ea1e259d577650d18791872: sync error
2019-06-12T10:46:26.381Z lightningd(1264): 0331f80652fb840239df8dc99205792bba2e559a05469915804c08420230e23c7c chan #9677: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel d38752727ed5dab33abb06c5671e9d7d467feb469f0d249aa488f45e304221c1: sync error
2019-06-12T12:12:51.261Z lightningd(1264): 02d3366059edde4179fc0d071828b4bd726effba7225c3851f3d86a6a827f934a2 chan #9804: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel d00c9eb31bb0c1f5794804114117be3cc75a756a1e4c08099b7188a5fd9f7215: sync error

2019-06-13T03:19:28.212Z lightningd(1218): 03e5ea100e6b1ef3959f79627cb575606b19071235c48b3e7f9808ebcd6d12e87d chan #10792: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel 873a526043bbc680ea4398c7a45b9742762d782dea285c661bb90ab8f165976d: sync error
2019-06-13T06:19:52.486Z lightningd(1230): 030995c0c0217d763c2274aa6ed69a0bb85fa2f7d118f93631550f3b6219a577f5 chan #10743: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel 29157b32dd0c13bcf4f785c5527d067159e102d62516e3a00fbf2c0f33bf59ec: sync error

2019-06-14T01:25:37.598Z lightningd(1235): 02cf60741c586aa54ff24381beab1aebf45eda61a8c49b043cf1f6e203e611e581 chan #12786: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel 827472a7167ab1fecd680e4f28e1ee74bcd25d04dcdea5d1295ba381b6543661: sync error

2019-07-17T03:37:12.703Z UNUSUAL lightningd(1262): 03021c5f5f57322740e4ee6936452add19dc7ea7ccf90635f95119ab82a62ae268 chan #14764: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel 5ff0890d9f1fbb63439a7d793c28cb74c3baef8c9b610c51c64b8a6497237540: sync error
2019-07-17T03:37:14.964Z UNUSUAL lightningd(1262): 030c3f19d742ca294a55c00376b3b355c3c90d61c6b6b39554dbc7ac19b141c14f chan #14839: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel 79525ec2c4eaffb5fd6893957f330db81b7383c50d57113d5bf8ffee3c121bdc: sync error
2019-07-17T03:37:16.048Z UNUSUAL lightningd(1262): 028c1da32603fce64118e469ffe2cfeec04d1c4bd88205efb4e8b4208f77a8064e chan #14996: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: received ERROR channel 6913067c9c89404d9451df25fed1a6cc98b9d9ef801b623d5e8e90aa43ca3077: sync error

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

@rustyrussell rustyrussell force-pushed the rustyrussell:guilt/ignoring-errors branch from c8eadab to 4736cb3 Jul 26, 2019

@rustyrussell

This comment has been minimized.

Copy link
Contributor Author

commented Jul 26, 2019

Ack 4736cb3

Self-ack for rebase to solve conflict. No changes.

@rustyrussell rustyrussell requested a review from ZmnSCPxj Jul 26, 2019

@rustyrussell rustyrussell merged commit 6c7a456 into ElementsProject:master Jul 26, 2019

2 checks passed

ackbot PR ack'd by rustyrussell
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@pavlenex

This comment has been minimized.

Copy link

commented Jul 26, 2019

Thanks for the fix @rustyrussell @ZmnSCPxj
It's unfortunate, but majority of these channels has not yet been closed. I know 144 blocks is the magic number, but I now see that for nearly all of the channels it's significantly higher. Why OUR_DELAYED_RETURN_TO_WALLET happens?

I've had over $700 in channels so a word of a comfort that it'll all be okay would be great :)

CHANNELD_NORMAL:Received error from peer: channel d5fa53f03bdb493ba0a7c80db03944daa0b61b1e1504887140ef3526fb5b9d26: sync error
ONCHAIN:Tracking our own unilateral close
ONCHAIN:3 outputs unresolved: in 281 blocks will spend DELAYED_OUTPUT_TO_US (4797a74a87f64d01b04ea82494477612ea44d947467d8d5f466f27a63e466aa8:1) using OUR_DELAYED_RETURN_TO_WALLET
CHANNELD_NORMAL:Received error from peer: channel 47ac844a9b91f4365a4334164a3bf4f1cf688a24d1d0ff049bfecfcdb389ecc8: sync error
ONCHAIN:Tracking our own unilateral close
ONCHAIN:All outputs resolved: waiting 73 more blocks before forgetting channel
CHANNELD_NORMAL:Received error from peer: channel 388f356343c8ccb0bcbabcb96c7e7a4bfb6d4b245eeaab5f0119d0b3b252ae6d: sync error
ONCHAIN:Tracking our own unilateral close
ONCHAIN:3 outputs unresolved: in 45 blocks will spend DELAYED_OUTPUT_TO_US (703837e5110a282a5e4b6b8253e42d3f1f116afb9b21b6511a619b688148830d:1) using OUR_DELAYED_RETURN_TO_WALLET
Channel ID: 559228x858x1
Full Channel ID: f6abef2b94e60415c390f8b026ecf7e19e78d64750759efda2c92a1316fc9ef2
Status: CHANNELD SHUTTING DOWN
Ours: 0 usd
Theirs: 1,306.749879 usd
Age: 27844 blocks (6 months)
Peer: 033cfb88e57bf05550bf461878e58b08a56c4f7cc972b2428e5a35a70a0d2b25c9 (disconnected)
Funding TXID: f39efc16132ac9a2fd9e755047d6789ee1f7ec26b0f890c31504e6942befabf6
peer:
  id: 033cfb88e57bf05550bf461878e58b08a56c4f7cc972b2428e5a35a70a0d2b25c9
  connected: false
state: CHANNELD_SHUTTING_DOWN
scratch_txid: 2e3b885b1af46f82551de5126789cde5d3a947ade8378b90ae167a8ca9094cde
short_channel_id: 559228x858x1
direction: 0
channel_id: f6abef2b94e60415c390f8b026ecf7e19e78d64750759efda2c92a1316fc9ef2
funding_txid: f39efc16132ac9a2fd9e755047d6789ee1f7ec26b0f890c31504e6942befabf6
private: false
funding_allocation_msat:
  02d35ad6428b083d63575e3b0ce33e06c507910c131970b07dc194953b43a9794c: 0
  033cfb88e57bf05550bf461878e58b08a56c4f7cc972b2428e5a35a70a0d2b25c9: 13437832000
funding_msat:
  02d35ad6428b083d63575e3b0ce33e06c507910c131970b07dc194953b43a9794c: 0msat
  033cfb88e57bf05550bf461878e58b08a56c4f7cc972b2428e5a35a70a0d2b25c9: 13437832000msat
msatoshi_to_us: 0
to_us_msat: 0msat
msatoshi_to_us_min: 0
min_to_us_msat: 0msat
msatoshi_to_us_max: 0
max_to_us_msat: 0msat
msatoshi_total: 13437832000
total_msat: 13437832000msat
dust_limit_satoshis: 546
dust_limit_msat: 546000msat
max_htlc_value_in_flight_msat: '18446744073709551615'
max_total_htlc_in_msat: 18446744073709551615msat
their_channel_reserve_satoshis: 134379
their_reserve_msat: 134379000msat
our_channel_reserve_satoshis: 134378
our_reserve_msat: 134378000msat
spendable_msatoshi: 0
spendable_msat: 0msat
htlc_minimum_msat: 0
minimum_htlc_in_msat: 0msat
their_to_self_delay: 144
our_to_self_delay: 1614
max_accepted_htlcs: 483
in_payments_offered: 0
in_msatoshi_offered: 0
in_offered_msat: 0msat
in_payments_fulfilled: 0
in_msatoshi_fulfilled: 0
in_fulfilled_msat: 0msat
out_payments_offered: 0
out_msatoshi_offered: 0
out_offered_msat: 0msat
out_payments_fulfilled: 0
out_msatoshi_fulfilled: 0
out_fulfilled_msat: 0msat
htlcs: []
@ZmnSCPxj

This comment has been minimized.

Copy link
Collaborator

commented Jul 26, 2019

Since "we" closed the channel unilaterally, it is "our" delayed output, which will be returned to our onchain wallet.

The number of blocks that you end up waiting for is set by your counterparty. So if your counterparty was the one who closed, it would be your settings that are used. This is because this is a security parameter of your counterparty: it is the number of blocks they can be offline safely for, without potentially suffering theft attempt. So your funds are locked according to how paranoid your counterparty is, not according to how paranoid you are. This is a simple consequence of having to coordinate with other people. Now of course you are not going to steal from your counterparty, but your counterparty does not know that, and as they say, don't trust, verify.

We close the channel unilaterally because the BOLT specs that is what should be done if we receive an error message, i.e. WIRE_ERROR. Unfortunately, the precious little snowflake lnd likes to throw pointless sync error messages which are (as far as we can tell) nearer to warning-level problems than true errors. lnd mostly ignores error messages from peers, apparently. So we make an exception and if we see sync error on the error message, we just disconnect, hope lnd becomes sane and fixes their bug, then reconnect later. Again, this is a simple consequence of having to live with somebody else in the same network, even though they are wrong.

For "outputs resolved" it is in your onchain funds. For "outputs unresolved" it is just a matter of waiting out the needed time. It will be OK, not to worry.

@pavlenex

This comment has been minimized.

Copy link

commented Jul 26, 2019

Perfect explanation, thanks a lot @ZmnSCPxj, all makes sense, will wait in this case.

@NicolasDorier

This comment has been minimized.

Copy link
Contributor

commented Jul 26, 2019

Can this easily be backported to the latest c-lightning version? Because this basically make c-lightning unusable even if not your fault.

I want to release a new version with this in BTCPay

@ZmnSCPxj

This comment has been minimized.

Copy link
Collaborator

commented Jul 26, 2019

@NicolasDorier possibly. I shall try later to see if these can be trivially cherry-picked on some branch on top of 0.7.1.

We have very vague plans to have a release every about 4 or 5 difficulty adjustments (because this is Bitcoin, merely human concepts like "two months" do not apply), and I believe we are about two or three difficulty achievements since last release. So maybe (very maybe) we can release 0.7.2 soon... though there is only maybe a chance of a possibility of (maybe) doing so (if possible that there is a chance). Though, there are still a number of items listed in 0.7.2 milestone. If we keep to (our not particularly agreed-upon) schedule we might have a release candidate in a difficulty adjustment or so.

@NicolasDorier

This comment has been minimized.

Copy link
Contributor

commented Jul 26, 2019

Whichever is fine for me, if you have time to make a cherry pick I will just update our fork with it. Else I will wait for 0.7.2 RC. Normally I avoid RC if possible but, a RC can't be worse than the current state :(

* <+roasbeef> andn doesn't always mean that we can't continue forwrd,
* or y'all sent the wrong info
*/
/* So while LND is sitting in the corner eating paint, back off. */

This comment has been minimized.

Copy link
@molxyz

molxyz Aug 1, 2019

Very unprofessional language there, rusty. What a shame, only to find out it's your bug and the little snowflake has to help you out.

This comment has been minimized.

Copy link
@NicolasDorier

NicolasDorier Aug 1, 2019

Contributor

Is it c-lightning bug? We close the channel unilaterally because the BOLT specs that is what should be done if we receive an error message

This comment has been minimized.

Copy link
@ZmnSCPxj

ZmnSCPxj Aug 1, 2019

Collaborator

It is both side bug.

  1. C-Lightning should reestablish quickly on reconnection.
  2. LND should not throw out error like candy.

1 above is arguably "fine" since we cannot control the resources available on every node C-Lightning can run on anyway, so some number of open channels and some level of hardware and some number of other processes running on that hardwre will experience this every now and then.

2 is harder to justify, given BOLT correctness.

This comment has been minimized.

Copy link
@molxyz

molxyz Aug 1, 2019

You all keep saying LND should make it a "soft" error or just "hang up" but rusty said "there are no "soft" errors in the protocol": #2847 (comment)
So instead of looking at your own code and questioning yourself first that maybe it's your own issue you blamed on LND and even called name...
Don't you ever ask yourself why this mass channel closing doesn't happen so often with other impls but only with c-lightning? And this issue still happens after almost two yrs. I was talking with pavlenex, aka 'bitcoinshirt', on lnd slack a few weeks ago that i opened a channel to his node and it got closed within a few minutes. He told me it hadn't happened anymore, and bam it happened again, lmao ...
I had this convo with roasbeef on the slack and here's what he said, I hope you'll read it and think about it:

image

This comment has been minimized.

Copy link
@NicolasDorier

NicolasDorier Aug 1, 2019

Contributor

Maybe LND should update the BOLT before deviating from it.

This comment has been minimized.

Copy link
@ZmnSCPxj

ZmnSCPxj Aug 1, 2019

Collaborator

Again: the specs says that on receipt of error we should force-close. C-Lightning follows the BOLT standard. If LND wants to change the behavior of error it should negotiate a change in specifications first. The only reason this appears "normal" to you is because LND has a much bigger advertising budget and thereby runs 85% of the public network.

Just because some application behaves some way and is popular does not make it "correct". Follow the agreed-upon specifications or at least negotiate for a proper specifications change. LND is clearly not spec-compliant here, whereas failing a non-spec-defined timeout does not make C-Lightning incorrect.

https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#message-retransmission

The above does not mention any timeouts regarding channel_reestablish.

  1. LND is not spec-compliant 1: it imposes a time limit on channel_reestablish where none is specified.
  2. LND is not spec-compliant 2: it throws a an error with "sync error" in this case.
  3. LND is not spec compliant 3: if it receives an error with "sync error" it does not close the channel: https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md#the-error-message

The receiving node:

  • upon receiving error:
    • MUST fail the channel referred to by the error message, if that channel is with the sending node.

LND is clearly in the wrong, despite its popularity.

In any case, I will start to ignore what you say about this topic.

This comment has been minimized.

Copy link
@NicolasDorier

NicolasDorier Aug 1, 2019

Contributor

The godwin point of compatibility: LND is the Internet Explorer of BOLT

This comment has been minimized.

Copy link
@ZmnSCPxj

ZmnSCPxj Aug 1, 2019

Collaborator

LND is the Internet Explorer of BOLT

That is arguably worse than calling it "precious little snowflake".

@molxyz

This comment has been minimized.

Copy link

commented Aug 2, 2019

@ZmnSCPxj
Of course LND is not spec-compliant re: channel_reestablish if you pin it to every letter of the spec in that area. But the spec is very vague re: error. Most software have errors that users can safely ignore. Nodes can send plenty of errors every minute, it's insane to just force close every channel just because they send an error. And again, what else can be called when it is an error, but just error is a vague word that needs to be changed. There are many different types of errors and not all errors are equally fatal. The spec needs to be clarified in this area, if not, it leaves up to each impl's interpretation.

There’s a lot of errors that aren’t dire but which should be communicated to another implementation. Even then, you can mark the channel in an “error state”, and then let the user actually decide if they want to force close it or not. It's easier though to just force close it and then let user figure it out later.

I've also seen c-lightning users complain their c-lightning peers force closed on them. So it's normal for c-lightning to force close even on each other for no valid reason, I guess you think it's normal to see the network to be perpetually in force closing. How would you expect LN to function, let alone succeed, if users can't count on the software to be stable enough to hold their channels intact? And no I don't think LND is "normal because it's popular", but I regard it as more sane because LND doesn't do insane force closing on me all the time. I have disagreed and criticized LND much more than you know. I would have said the same if it was an LND dev that made such statements. And fwiw, I do respect and appreciate rusty's work for LN and Linux, he's a legend. I have tried to contribute to c-lightning as much as i could with testing, I am not a dev, only a user playing with Lightning the last 3 years and would like to see LN succeed. So to answer your accusation:

  1. The spec is not the Bible, it's not 100% perfect.
  2. The spec is not any country's laws stricly require you to obey.
  3. LND is not violating the spec in anyway. You have the choice to read it literally as the letter of the law which you then can exploit vague words to condemn others for your advantage, which is kinda sad.
  4. Or you can choose to read the spec in the spririt of the law because the spec is just a general guide to help implementations to work together, there's a more important element than the spec: the humans in this network who operate their nodes with their money who cannot afford to be force closed constantly just because you say they send an error and you need to shut them out.
  5. So, there's the spec, and then there's commonsense. Pick your choice, but don't be surprised why your software is not "popular"!

LND has a much bigger advertising budget and thereby runs 85% of the public network.

This is new to me. Do you have proof? Or you just want to throw mud in the dark?

In any case, I will start to ignore what you say about this topic.

Yes, please ignore me. I wasn't expecting to have to write to answer your accusation again, but now I've done it, I am done. It's your choice not to be open minded and listen to what users say, I totally respect that, and I do not expect to hear from you ever again. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.