Commit Graph

314 Commits

Author SHA1 Message Date
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
67ddb72eab
lnwire: create failure message encode/decode functions 2019-07-29 09:38:38 +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
558c8ca2a8
lnwire: export failureMessageLength constant 2019-04-30 20:13:33 -07:00
Olaoluwa Osuntokun
a508a62b8c
lnwire: add bool types to codec for SCB format 2019-03-28 17:53:44 -07:00
Olaoluwa Osuntokun
e58fa33ab0
Merge pull request #2590 from Crypt-iQ/init_message_payload_fix
lnwire: features "maxAllowedSize" fix
2019-03-21 20:58:29 -07:00
Joost Jager
652ebb1652
lnwire: add constructor for FinalExpiryTooSoon failure message 2019-03-15 10:08:29 +01:00
nsa
d09d514858 lnwire: include init prefix in MaxPayloadLength calculation 2019-02-07 13:19:54 -05:00
nsa
a460fa92b8 lnwire: change error's MaxPayloadLength to 65535 2019-02-06 20:46:38 -05:00
nsa
7a65be7f14 lnwire: features "maxAllowedSize" fix 2019-02-06 07:02:10 -05:00
Olaoluwa Osuntokun
66c80bb3c0
Merge pull request #2571 from Roasbeef/lnwire-onion-fix
lnwire: ensure we're able to decode legacy FailUnknownPaymentHash
2019-02-01 12:53:45 -08: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
5c434b17ff
lnwire: ensure even/odd features have the same base name
In this commit, we fix a bug in the way we defined our even/odd features
for a particular feature. The check for if a feature bit is part of a
pair assumes that the pair bit has the exact same name as the bit being
queried. The way we defined our feature map didn't take note of this
assumption, as a result, any attempts to require a new bit moving from
optional to required would fail since the bit would be found, but the
names differed.
2019-01-31 20:58:10 -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
Johan T. Halseth
7d34ce9d08
lnwire+multi: define HasMaxHtlc helper on msgFlags 2019-01-22 08:42:30 +01:00
Valentine Wallace
b49637fbe9
lnwire: add HtlcMaximumMsat field to ChannelUpdate
In this commit, we add a field to the ChannelUpdate
denoting the maximum HTLC we support sending over
this channel, a field which was recently added to the
spec.

This field serves multiple purposes. In the short
term, it enables nodes to signal the largest HTLC
they're willing to carry, allows light clients who
don't verify channel existence to have some guidance
when routing HTLCs, and finally may allow nodes to
preserve a portion of bandwidth at all times.

In the long term, this field can be used by
implementations of AMP to guide payment splitting,
as it becomes apparent to a node the largest possible
HTLC one can route over a particular channel.

This PR was made possible by the merge of #1825,
which enables older nodes to properly retain and
verify signatures on updates that include new fields
(like this new max HTLC field) that they haven't yet
been updated to recognize.

In addition, the new ChannelUpdate fields are added to
the lnwire fuzzing tests.

Co-authored-by: Johan T. Halseth <johanth@gmail.com>
2019-01-22 08:42:26 +01:00
Valentine Wallace
f0ba4b454c
lnwire/channel_update: add String method for ChanUpdate[Chan|Msg]Flags
In this commit, we fix the problem where it's annoying to parse a
bitfield printed out in decimal by writing a String method for the
ChanUpdate[Chan|Msg]Flags bitfield.

Co-authored-by: Johan T. Halseth <johanth@gmail.com>
2019-01-22 08:42:26 +01: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
1821773e39
lnwire: add test cases for node alias validation 2019-01-07 12:53:40 -08:00
Olaoluwa Osuntokun
0b10f4c4d8 lnwire: when reading node aliases, properly check validity
In this commit, we ensure that when we read node aliases from the wire,
we ensure that they're valid. Before this commit, we would read the raw
bytes without checking for validity which could result in us writing in
invalid node alias to disk. We've fixed this, and also updated the
quickcheck tests to generate valid strings.
2019-01-07 12:53:10 -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
f7436f43b2
lnwire: check length of payload in decodeShortChanIDs 2018-09-13 15:57:08 -07:00
Conner Fromknecht
85a2d4640f
lnwire/lnwire_test: assert nil 0-length sid reply msg 2018-09-05 20:54:06 -07:00
Conner Fromknecht
055dc233a1 lnwire/features: add required gq to local features
This commit adds the required feature name to our
set of local known features. This will allow other
peers connecting to us to set the required gossip
queries feature bit. This is required for the
subsequent commits, which instruct the server to
set the bit depending on user configured preferences.
2018-09-05 18:51:04 -07:00
Olaoluwa Osuntokun
adde6037c1
lnwire: extend quickcheck parser tests to add extra data for gossip messages 2018-09-04 20:52:42 -07: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
fa6a0a7ce9
lnwire: recognize required query sync feature bit 2018-08-23 19:36:17 -07:00
Conner Fromknecht
cf2c371042
multi: fix linting errors 2018-08-02 18:20:50 -07:00
Olaoluwa Osuntokun
6f60f139f4 multi: switch over import paths from roasbeef/* to btcsuite/* 2018-07-13 17:05:39 -07:00
Olaoluwa Osuntokun
bc5bfeb479
lnwire: fix logging for FeeInsufficient, show amt not fee
Fixes #1548.
2018-07-12 16:10:16 -07:00
Conner Fromknecht
61c2493b7d
lnwire/query_short_chan_ids: short circuit if 0 sids
In this commit, we alter the behavior of the regular
short channel id encoding, such that it returns a nil
slice if the decoded number of elements is 0. This is
done so that it matches the behavior of the zlib
decompression, allowing us to test both in using the
same corpus.
2018-07-03 17:08:40 -07:00
Conner Fromknecht
8cc217b526
lnwire/lnwire_test: use nil slice when 0 sids
Modifies the behavior of the quick test for
MsgQueryShortChanIDs, such that the generated
slice of expected short chan ids is always nil
if no elements are returned. This mimics the
behavior of the zlib decompression, where
elements are appended to the slice, instead of
assigning to preallocated slice.
2018-07-03 17:08:39 -07:00
Olaoluwa Osuntokun
23b1678266
lnwire: ensure zlib short chan id's are sorted 2018-06-25 16:16:37 -07:00
Olaoluwa Osuntokun
940b95aad7
lnwire: update testing.Quick tests to alternate between encoding types 2018-06-25 16:16:36 -07:00
Olaoluwa Osuntokun
5caf3d7310
lnwire: add new package level mutex to limit # of concurrent zlib decodings
In this commit, we add a new package level mutex. Each time we decode a
new set of chan IDs w/ zlib, we also grab this mutex. The purpose here
is to ensure that we only EVER allocate the maxZlibBufSize globally
across all peers. Otherwise, it may be possible for us to allocate up to
64 MB for _each_ peer, exposing an easy OOM attack vector.
2018-06-25 16:16:36 -07:00
Olaoluwa Osuntokun
a0e2f8dbd1 lnwire: implement zlib encode/decode for channel range queries
In this commit, we implement zlib encoding and decoding for the channel
range queries. Notably, we utilize an io.LimitedReader to ensure that we
can enforce a hard cap on the total number of bytes we'll ever allocate
in a decoding attempt.
2018-06-25 16:16:13 -07:00
Wilmer Paulino
d635994272
lnwire: add functional option that updates a node announcement's addresses 2018-06-12 18:36:28 -07:00
Olaoluwa Osuntokun
15f812b10f
lnwire: don't attempt to decode an empty/nil signature 2018-06-08 13:25:56 -07:00
Olaoluwa Osuntokun
d98d4523e1
Merge pull request #1159 from wpaulino/onion-service-support
multi: add onion services support
2018-06-04 21:46:51 -07:00
Wilmer Paulino
e5987a1ef1
lnwire: extend tests to randomly generate all types of supported addresses 2018-06-04 20:41:32 -07:00
Wilmer Paulino
850f9fbbe9
lnwire: implement serialization of onion addresses
Co-Authored-By: Eugene <crypt-iq@users.noreply.github.com>
2018-06-04 20:41:31 -07:00
Olaoluwa Osuntokun
1c8c1cba96
lnwire: only check payload for proper size if encoding type is sorted plain
In this commit, we fix a slight bug in the parsing of encoded short
channel ID's. Before this commit, we would always assume that the remote
peer was sending us the sorted+encoded variant of the short channel
ID's. In the case that they weren't (as there isn't yet a feature bit),
we would assert this check and fail early as atm we don't support any
sort of compression.
2018-06-04 16:31:22 -07:00
Olaoluwa Osuntokun
62df3cbbb8
lnwire: update tests and message code definitions for new gossip query msgs 2018-05-31 16:30:52 -07:00
Olaoluwa Osuntokun
fa9a012ac6
lnwire: add new GossipTimestampRange gossip query msg 2018-05-31 16:30:52 -07:00
Olaoluwa Osuntokun
c71d3fd5b3
lnwire: add new ReplyShortChanIDsEnd gossip query msg 2018-05-31 16:30:51 -07:00
Olaoluwa Osuntokun
898d5ffccf
lnwire: add new QueryShortChanIDs gossip query msg 2018-05-31 16:30:50 -07:00