Commit Graph

14 Commits

Author SHA1 Message Date
yyforyongyu
550341c036
lnwire: fix typo 2020-12-04 23:07:53 +08:00
Matheus Degiovani
44555a70ed lnwire: fix decoding for initial zero sid
This fixes a decoding error when the list of short channel ids within a
QueryShortChanIDs message started with a zero sid.

BOLT-0007 specifies that lists of short channel ids should be sorted in
ascending order. Previously, this was checked within lnwire by comparing
two consecutive sids in the list, starting at the empty (zero) sid.

This meant that a list that started with a zero sid couldn't be decoded
since the first element would _not_ be greater than the last one
(namely: also zero).

Given that one can only check for ordering starting at the second
element, we add a check to ensure the proper behavior.

A unit test is also added to ensure no future regressions on this
behavior.
2020-06-18 14:04:39 -03:00
nsa
5a03fe572f
lnwire: move zero-length queryBody check to zlib case 2020-03-03 13:58:25 -05:00
Bastien Teinturier
17200afc57
lnwire: explicitly handle empty list when encoding short chan IDs
Before this commit, both writing and reading an encoded empty set of
short channel IDs from the wire would fail. Prior to this commit, we
treated decoding an empty set as a caller error, and failed to write out
the zlib encoding of an empty set in a way that us and the other
implementations were able to read.

To fix this, rather than giving zlib an empty buffer to write out (which
results in an encoding with the zlib header data and the rest), we just
write a blank slice. When decoding, if we have an empty query body, then
we'll return a `nil` slice.

With the above changes, we'll now always write out an empty short
channel ID set as:
```
0001 (1 byte follows) || <encoding_type>
```

A new test has also been added to exercise this case for both known
encoding types.
2020-01-13 20:26:55 -08:00
Conner Fromknecht
3cc235a349
lnwire/query_short_chan_ids: assert sorted for plain encoding 2019-11-20 01:57:36 -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
Olaoluwa Osuntokun
f7436f43b2
lnwire: check length of payload in decodeShortChanIDs 2018-09-13 15:57:08 -07:00
Olaoluwa Osuntokun
6f60f139f4 multi: switch over import paths from roasbeef/* to btcsuite/* 2018-07-13 17:05:39 -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
Olaoluwa Osuntokun
23b1678266
lnwire: ensure zlib short chan id's are sorted 2018-06-25 16:16:37 -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
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
898d5ffccf
lnwire: add new QueryShortChanIDs gossip query msg 2018-05-31 16:30:50 -07:00