-
Notifications
You must be signed in to change notification settings - Fork 267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extended Queries: use TLV format for optional data #1072
Extended Queries: use TLV format for optional data #1072
Conversation
Optional query extensions now use TLV instead of a custom format. Flags are encoded as varint instead of bytes as originally proposed. With the current proposal they will all fit on a single byte, but will be much easier to extends this way.
Codecov Report
@@ Coverage Diff @@
## extended-queries-optional #1072 +/- ##
=============================================================
+ Coverage 82.76% 82.76% +<.01%
=============================================================
Files 100 103 +3
Lines 7727 7776 +49
Branches 306 304 -2
=============================================================
+ Hits 6395 6436 +41
- Misses 1332 1340 +8
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just a first pass review. PR needs a merge from master, and I don't think the TLV part is properly implemented.
eclair-core/src/main/scala/fr/acinq/eclair/wire/LightningMessageTypes.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/wire/LightningMessageTypes.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/wire/LightningMessageTypes.scala
Outdated
Show resolved
Hide resolved
We add one new class for each TLV type, with specific TLV types, and encapsulate codecs.
TLVs that extend regular LN messages can be represented as a TlvStream and not an Option[TlvStream] since we don't need to explicitely terminate the stream (either by preprending its length or using a specific terminator) as we do in Onion TLVs. No TLVs simply means that the TLV stream is empty.
Checksums in ReplyChannelRange now have the same encoding as short channel ids and timestamps: one byte for the encoding type (uncompressed or zlib) followed by encoded data.
If a have a TLV stream of type MyTLV which is a subtype of TLV, and MyTLV1 and MYTLV2 are both subtypes of MyTLV then we can use stream.get[MyTLV1] to get the TLV record of type MYTLV1 (if any) in our TLV stream.
Checksums are just transmitted as a raw array, with optional compression as it would be useless here.
We will use them on mainnet as soon as lightning/bolts#557 has been merged.
eclair-core/src/main/scala/fr/acinq/eclair/wire/LightningMessageTypes.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/wire/LightningMessageTypes.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/wire/LightningMessageTypes.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/wire/LightningMessageTypes.scala
Outdated
Show resolved
Hide resolved
We remove the ugly and inefficient zipWithIndex we had before
@@ -76,7 +77,7 @@ case class NodeParams(keyManager: KeyManager, | |||
routerConf: RouterConf, | |||
socksProxy_opt: Option[Socks5ProxyParams], | |||
maxPaymentAttempts: Int) { | |||
|
|||
require(feeBase <= MilliSatoshi(0xFFFFFFFFL)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be in NodeParams.makeNodeParams
for consistency, with a human understandable message (and also a comment explaining why we have to cap the value)
Optional query extensions now use TLV instead of a custom format.
Flags are encoded as varint instead of bytes as originally proposed. With the current proposal they will all fit on a single byte, but will be much easier to extends this way.