Commit Graph

13 Commits

Author SHA1 Message Date
Conner Fromknecht
0fc506e044
lnwire/onion_error: add InvalidOnionPayload failure 2019-10-30 21:19:36 -07:00
Joost Jager
f60e4b1e14
lnwire+htlcswitch: report height for invalid payment details failure
Extends the invalid payment details failure with the new accept height
field. This allows sender to distinguish between a genuine invalid
details situation and a delay caused by intermediate nodes.
2019-09-16 10:10:20 +02:00
Joost Jager
1de08c4780
lnwire/test: fix TestFailIncorrectDetailsOptionalAmount
This test relied on specific internals of the failure encode function.
Changes to failure message pointer receiver everywhere subtly broke this
test.
2019-09-16 10:10:18 +02:00
Joost Jager
aabd68ebcd
multi: rename FailUnknownPaymentHash to FailIncorrectDetails
Align naming better with the lightning spec. Not the full name of the
failure (FailIncorrectOrUnknownPaymentDetails) is used, because this
would cause too many long lines in the code.
2019-08-08 11:04:17 +02:00
Joost Jager
c6f9517e48
lnwire+htlcswitch: only use references for failure messages
Methods on failure message types used to be defined on value receivers.
This allowed assignment of a failure message to ForwardingError both as
a value and as a pointer. This is error-prone, especially when using a
type switch.

In this commit the failure message methods are changed so that they
target pointer receivers.

Two instances where a value was assigned instead of a reference are
fixed.
2019-07-11 19:49:47 +02: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
Valentine Wallace
0fd6004958
multi: partition lnwire.ChanUpdateFlag into ChannelFlags and MessageFlags
In this commit:

* we partition lnwire.ChanUpdateFlag into two (ChanUpdateChanFlags and
ChanUpdateMsgFlags), from a uint16 to a pair of uint8's

* we rename the ChannelUpdate.Flags to ChannelFlags and add an
additional MessageFlags field, which will be used to indicate the
presence of the optional field HtlcMaximumMsat within the ChannelUpdate.

* we partition ChannelEdgePolicy.Flags into message and channel flags.
This change corresponds to the partitioning of the ChannelUpdate's Flags
field into MessageFlags and ChannelFlags.

Co-authored-by: Johan T. Halseth <johanth@gmail.com>
2019-01-22 08:42:26 +01: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
941a123ab0 lnwire: add new ExtraOpaqueData field to gossip messages
In this commit, we add a new field to all the existing gossip messages:
ExtraOpqueData. We do this, as before this commit, if we came across a
ChannelUpdate message with a set of optional fields, then we wouldn't be
able to properly parse the signatures related to the message. If we
never corrected this behavior, then we would violate the forwards
compatible principle we use when parsing existing messages.

As these messages can now be padded out to the max message size, we've
increased the MaxPayloadLength value for all of these messages.

Fixes #1814.
2018-09-04 20:52:39 -07: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
4dd108c827
lnwire: replace usage of btcec.Signature with the new lnwire.Sig type 2018-02-06 20:14:30 -08:00
Olaoluwa Osuntokun
b174ae80bf
lnwire: convert all relevant fields to use the MilliSatoshi type 2017-08-22 00:51:51 -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