Archives/lnbook
2
0
Fork 0
mirror of https://github.com/lnbook/lnbook synced 2024-11-04 18:00:26 +00:00
Code Issues Projects Releases Wiki Activity

remove unwanted file

Browse Source
This commit is contained in:
Andreas M. Antonopoulos 2021-07-20 15:11:52 +02:00
parent 1c91ddde34
commit 8254b7b1af
1 changed files with 0 additions and 165 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

165
10_onion_routing.pdf
View File

@ -1,165 +0,0 @@
1. type: PERM|1 (`invalid_realm`)
The `realm` byte was not understood by the processing node.
1. type: NODE|2 (`temporary_node_failure`)
General temporary failure of the processing node.
1. type: PERM|NODE|2 (`permanent_node_failure`)
General permanent failure of the processing node.
1. type: PERM|NODE|3 (`required_node_feature_missing`)
The processing node has a required feature which was not in this onion.
1. type: BADONION|PERM|4 (`invalid_onion_version`)
2. data:
* [`sha256`:`sha256_of_onion`]
The `version` byte was not understood by the processing node.
1. type: BADONION|PERM|5 (`invalid_onion_hmac`)
2. data:
* [`sha256`:`sha256_of_onion`]
The HMAC of the onion was incorrect when it reached the processing node.
1. type: BADONION|PERM|6 (`invalid_onion_key`)
2. data:
* [`sha256`:`sha256_of_onion`]
The ephemeral key was unparsable by the processing node.
1. type: UPDATE|7 (`temporary_channel_failure`)
2. data:
* [`u16`:`len`]
* [`len*byte`:`channel_update`]
The channel from the processing node was unable to handle this HTLC,
but may be able to handle it, or others, later.
1. type: PERM|8 (`permanent_channel_failure`)
The channel from the processing node is unable to handle any HTLCs.
1. type: PERM|9 (`required_channel_feature_missing`)
The channel from the processing node requires features not present in
the onion.
1. type: PERM|10 (`unknown_next_peer`)
The onion specified a `short_channel_id` which doesn't match any
leading from the processing node.
1. type: UPDATE|11 (`amount_below_minimum`)
2. data:
* [`u64`:`htlc_msat`]
* [`u16`:`len`]
* [`len*byte`:`channel_update`]
The HTLC amount was below the `htlc_minimum_msat` of the channel from
the processing node.
1. type: UPDATE|12 (`fee_insufficient`)
2. data:
* [`u64`:`htlc_msat`]
* [`u16`:`len`]
* [`len*byte`:`channel_update`]
The fee amount was below that required by the channel from the
processing node.
1. type: UPDATE|13 (`incorrect_cltv_expiry`)
2. data:
* [`u32`:`cltv_expiry`]
* [`u16`:`len`]
* [`len*byte`:`channel_update`]
The `cltv_expiry` does not comply with the `cltv_expiry_delta` required by
the channel from the processing node: it does not satisfy the following
requirement:
cltv_expiry - cltv_expiry_delta >= outgoing_cltv_value
1. type: UPDATE|14 (`expiry_too_soon`)
2. data:
* [`u16`:`len`]
* [`len*byte`:`channel_update`]
The CLTV expiry is too close to the current block height for safe
handling by the processing node.
1. type: PERM|15 (`incorrect_or_unknown_payment_details`)
2. data:
* [`u64`:`htlc_msat`]
* [`u32`:`height`]
The `payment_hash` is unknown to the final node, the `payment_secret` doesn't
match the `payment_hash`, the amount for that `payment_hash` is incorrect or
the CLTV expiry of the htlc is too close to the current block height for safe
handling.
The `htlc_msat` parameter is superfluous, but left in for backwards
compatibility. The value of `htlc_msat` always matches the amount specified in
the final hop onion payload. It therefore does not have any informative value to
the sender. A penultimate hop sending a different amount or expiry for the htlc
is handled through `final_incorrect_cltv_expiry` and
`final_incorrect_htlc_amount`.
The `height` parameter is set by the final node to the best known block height
at the time of receiving the htlc. This can be used by the sender to distinguish
between sending a payment with the wrong final CLTV expiry and an intermediate
hop delaying the payment so that the receiver's invoice CLTV delta requirement
is no longer met.
Note: Originally PERM|16 (`incorrect_payment_amount`) and 17
(`final_expiry_too_soon`) were used to differentiate incorrect htlc parameters
from unknown payment hash. Sadly, sending this response allows for probing
attacks whereby a node which receives an HTLC for forwarding can check guesses
as to its final destination by sending payments with the same hash but much
lower values or expiry heights to potential destinations and check the response.
Care must be taken by implementations to differentiate the previously
non-permanent case for `final_expiry_too_soon` (17) from the other, permanent
failures now represented by `incorrect_or_unknown_payment_details` (PERM|15).
1. type: 18 (`final_incorrect_cltv_expiry`)
2. data:
* [`u32`:`cltv_expiry`]
The CLTV expiry in the HTLC doesn't match the value in the onion.
1. type: 19 (`final_incorrect_htlc_amount`)
2. data:
* [`u64`:`incoming_htlc_amt`]
The amount in the HTLC doesn't match the value in the onion.
1. type: UPDATE|20 (`channel_disabled`)
2. data:
* [`u16`:`flags`]
* [`u16`:`len`]
* [`len*byte`:`channel_update`]
The channel from the processing node has been disabled.
1. type: 21 (`expiry_too_far`)
The CLTV expiry in the HTLC is too far in the future.
1. type: PERM|22 (`invalid_onion_payload`)
2. data:
* [`bigsize`:`type`]
* [`u16`:`offset`]
The decrypted onion per-hop payload was not understood by the processing node
or is incomplete. If the failure can be narrowed down to a specific tlv type in
the payload, the erring node may include that `type` and its byte `offset` in
the decrypted byte stream.
1. type: 23 (`mpp_timeout`)
The complete amount of the multi-part payment was not received within a
reasonable time.