Commit Graph

23 Commits

Author SHA1 Message Date
Olaoluwa Osuntokun
558c8ca2a8
lnwire: export failureMessageLength constant 2019-04-30 20:13:33 -07:00
Joost Jager
652ebb1652
lnwire: add constructor for FinalExpiryTooSoon failure message 2019-03-15 10:08:29 +01:00
Olaoluwa Osuntokun
17fd5eef07
lnwire: ensure we're able to decode legacy FailUnknownPaymentHash
In this commit, we modify the decoding of the FailUnknownPaymentHash
message to ensure we're able to fully decode the legacy serialization of
the onion error. We do this by catching the `io.EOF` error as it's
returned when _no_ bytes are read. If this is the case, then only the
error type was serialized and not also the optional amount.
2019-01-31 22:20:41 -08:00
Olaoluwa Osuntokun
c8518140ee
lnwire: update Error() method for FailUnknownPaymentHash to include amt 2019-01-29 23:03:35 -08:00
orbitalturtle
08750f180b multi: deprecate IncorrectHtlcAmount onion error
In this commit, we deprecate the `IncorrectHtlcAmount` onion error.
We'll still decode this error to use when retrying paths, but we'll no
longer send this ourselves. The `UnknownPaymentHash` error has been
amended to also include the value of the payment as well. This allows us
to worry about one less error.
2019-01-29 18:21:13 -08:00
Olaoluwa Osuntokun
f83fde8483
lnwire: ensure we precisely encode the length for onion errors w/ chan updates
In this commit we fix a compatibility issue with other implementations.
Before this commit, when writing out an onion error that includes a
`ChannelUpdate` we would use the `MaxPayloadLength` to get the length to
encode. However, a recent update has modified that to be the max
`brontide` payload length as it's possible to pad out the message with
optional fields we're unaware of. As a result, we would always write out
a length of 65KB or so. This didn't effect our parser as we ignore the
length and decode the channel update directly as we don't need the
length to do that. However, other implementations depended on the length
rather than just reading the channel update, meaning that they weren't
able to decode our onion errors that had channel updates.

In this commit we fix that by introducing a new
`writeOnionErrorChanUpdate` which will write out the precise length
instead of using the max payload size.

Fixes #2450.
2019-01-11 14:21:48 -08:00
Olaoluwa Osuntokun
4226232881
lnwire: export ReadElements and WriteElements
In this commit, we export the ReadElements and WriteElements functions.
We do this as exporting these functions makes it possible for outside
packages to define serializations which use the BOLT 1.0 wire format.
2018-12-24 19:58:06 -06:00
Joost Jager
1d97cf1229
htlcswitch+routing: implement expiry_too_far failure
In this commit we add a check to HtlcSatifiesPolicy to verify that the
time lock for the outgoing htlc that is requested in the onion packet
isn't too far in the future.

Without this check, anyone could force an unreasonably long time lock on
the forwarding node.
2018-10-15 08:51:08 +02:00
Olaoluwa Osuntokun
31e92c4ff2
lnwire: add new compatibility parsing more for onion error chan updates
In this commit, we add a compatibility mode for older version of
clightning to ensure that we're able to properly parse all their channel
updates. An older version of c-lightning would send out encapsulated
onion error message with an additional type byte. This would throw off
our parsing as we didn't expect the type byte, and so we always 2 bytes
off. In order to ensure that we're able to parse these messages and make
adjustments to our path finding, we'll first check to see if the type
byte is there, if so, then we'll snip off two bytes from the front and
continue with parsing. if the bytes aren't found, then we can proceed as
normal and parse the request.
2018-08-31 17:24:26 -07:00
Olaoluwa Osuntokun
bc5bfeb479
lnwire: fix logging for FeeInsufficient, show amt not fee
Fixes #1548.
2018-07-12 16:10:16 -07:00
practicalswift
a93736d21e multi: comprehensive typo fixes across all packages 2018-02-06 19:11:11 -08:00
Olaoluwa Osuntokun
7e54b4ae46
lnwire: if unable to parse encapsulated error, log length and raw bytes
In this commit, we add additional detail in the error return hen were’e
unable to properly decode an encapsulated error. This additional
logging was added with the goal of being able to track down a lingering
bug, where at times lnd cannot decode a TemporaryChannelFailure
message.
2017-12-26 16:17:22 +01:00
Olaoluwa Osuntokun
ef2838fdd3
lnwire: log type of failure upon decode failure 2017-12-21 11:31:15 +01:00
Olaoluwa Osuntokun
a7d846ac40
lnwire: add godoc comments for lnwire.FailureMessage 2017-10-10 22:19:20 -07:00
Olaoluwa Osuntokun
0c9384d991
lnwire: address linter error 2017-10-02 22:16:32 -07:00
Olaoluwa Osuntokun
ab4af750e0
lnwire: expand FailureMessage. Error() method to include error specific info 2017-10-02 22:14:09 -07:00
John Griffith
492f7fa52f lnwire: add Error() method to lnwire.FailureMessage 2017-10-02 22:12:24 -07:00
Olaoluwa Osuntokun
1e5949cfbb
lnwire: return more descriptive errors in DecodeFailure for onion errors 2017-09-12 17:55:25 +02:00
Olaoluwa Osuntokun
2b2a3714c1
multi: fix linter errors 2017-08-22 01:00:12 -07:00
Olaoluwa Osuntokun
1d1f9f1724
lnwire: update onion error encoding/decoding to match BOLT-0004
This commit updates the encoding/decoding for the onion errors to
properly match BOLT-0004. This commit does to major things: we increase
the max message size to 256 bytes to account for recent modifications
to the ChannelUpdate message, and also fold in the error code into the
failure message encapsulation itself.
2017-08-22 00:51:53 -07:00
Olaoluwa Osuntokun
b174ae80bf
lnwire: convert all relevant fields to use the MilliSatoshi type 2017-08-22 00:51:51 -07:00
Olaoluwa Osuntokun
a04fa76a4c
lnwire+htlcswitch: minor grammatical, formatting fixes after error PR 2017-07-14 20:08:37 -07:00
Andrey Samokhvalov
98956bc2fe lnwire: add specification onion errors
In this commit onion routing error from BOLT#4 have been added, the
initial error construction have been splitted on two parts: The first
part which contains the actual data will reside inside the lnwire
package because it contains all necessary function to decode/encode
the data. The second part obfuscation and hmac checking will resides
inside the lighting-onion package because it requires the key
generation.
2017-07-14 19:08:04 -07:00