Author: Carla Kirk-Cohen 2021-02-12 07:34:04
Published on: 2021-02-12T07:34:04+00:00
Carla proposes to re-purpose the existing error message (17) in the spec to allow for more structured errors and create a path for standardized, enriched errors going forward. Carla suggests that instead of an arbitrary string, the error message should contain an error code and optional metadata, which will enrich the context of the error. This upgrade will provide better debugging information, clearer information for the end-user, reduced risk of leaking information, and more fine-grained error handling based on the error code. To achieve this, TLV fields can be added after the data field since non-ascii values are not allowed in the error string itself. Upgraded nodes will have an improved quality of life, while older nodes will remain unaffected. The new kind of error provides an error code that tells exactly what has gone wrong and metadata pointing to the invalid sig. Carla believes that the majority of impls don't abide by the instruction in the spec indicating that senders/recipients of errors MUST fail the channel referenced in the error. With standardized sets of errors and reasonable handling, we can clear up some of the ambiguity around errors, and make it easier for everyone to follow. Carla provides a list of candidates for error codes, including signature problems, funding process, channel state machine, fee updates, connection level, and gossip.Links to various sections in the Lightning Network Lightning-rfc GitHub repository are provided to give readers more context.
Updated on: 2023-06-03T03:48:29.095507+00:00