Clarify semantics of "Temporary" vs "Permanent" failures

[ProofOfKeags]

Clarify semantics of "Temporary" vs "Permanent" failures

[Roasbeef]

In the past, a "permanent failure" meant force close the channel (prior terminology of "fail"). These days, it can just mean disconnect and send a warning. The old semantics of error were to always insta force close, but that wasn't uniformly implemented. The thing we're still missing from the warning message is machine-parseable information that would actually let implementations handle the case progamratically.

Eg: today someone might reject a funding attempt if the amount is too low, then send a warning. If we add structured data there, then an implementation can know they can retry with a higher amount, or they can be given the explicit min.

[t-bast]

As I was digging into BOLT4 I was unable to figure out whether the recommended interpretation of a "permanent" failure means that the node receiving the error should never try this _____ again or if it should just not try it for the lifetime of the next operation (payment/rebalance etc.).

A permanent failure means this shouldn't be retried at all: for a channel failure, it means that channel is closing or has been closed, or the operation uses features that are not supported by this channel or this node.

However, in the event that the closing negotiation fails and the user doesn't choose to retry or force close the channel, we'd like to avoid the channel being permanently blacklisted by the network.

I don't understand how this can happen: if you initiated a shutdown, there is no going back, ever. There's no way to go back to relaying payments on a channel once one side intents to close? So this should be a permanent failure. Also, once shutdown has been initiated, both sides must issue a new channel_update with the disabled bit set, so that nodes on the network don't try to use this channel for routing.

@Roasbeef I don't understand your answer, it looks like you're talking about errors and warnings whereas this issue is dealing with Bolt 4 failures (update_fail_htlc), which is unrelated?

[ProofOfKeags]

I don't understand how this can happen: if you initiated a shutdown, there is no going back, ever.

This is far from obvious. What happens if the connection gets dropped during the negotiation process? I looked through the spec and it doesn't really say anything about this situation. I figured naively that the closure process would just get rolled back and we could reconnect and try to shutdown again..

[t-bast]

I figured naively that the closure process would just get rolled back and we could reconnect and try to shutdown again..

Yes you're right, that's exactly what happens, but that's something you MUST do. The channel_reestablish requirements say that:

A node:

- upon reconnection:
    - if it has sent a previous shutdown:
        - MUST retransmit shutdown.

So once you've sent shutdown, you're committed to closing the channel: if you disconnect and reconnect, you must re-send shutdown, which means you cannot go back to a state where you use the channel for HTLCs.

[ProofOfKeags]

Yes you're right, that's exactly what happens, but that's something you MUST do.

Can you explain why this decision was made? What does this protect against or how does it make implementation easier? It's not obvious to me why this should be a requirement.

[t-bast]

Mostly for simplicity, it is much easier to implement and test a state machine that only moves forward. There would also be weird incentives otherwise, where the other side could fail the negotiation intentionally to prevent the channel from closing, which would most likely result in a force-close, but would require more code to detect.

[ProofOfKeags]

Got it. I don't agree that it's simpler personally but that's a discussion for another day in another forum. Thanks for clarifying.