Cut 0.0.106 #1397
Cut 0.0.106 #1397
Conversation
CHANGELOG.md
Outdated
| * Fixed a compilation error in `ProbabilisticScorer` under `--feature=no-std` | ||
| resulting from `core` not having `f64::log10`. A log approximation is used | ||
| instead independent of feature settings (#1347). | ||
| * Fixed an integer underflow in `find_route` when |
There was a problem hiding this comment.
Hmm? I don't think there's an integer underflow in 105.
There was a problem hiding this comment.
Perhaps I misunderstood this. Does this PR fix anything in 105?
There was a problem hiding this comment.
It changes the definition of the cltv max to include the last-hop, whereas in 105 it was just a limit on all hops except the last. the new definition is likely more sensible to users, but technically its not a bugfix against 105.
Codecov Report
@@ Coverage Diff @@
## main #1397 +/- ##
==========================================
+ Coverage 90.76% 91.02% +0.26%
==========================================
Files 73 73
Lines 41195 44165 +2970
Branches 41195 44165 +2970
==========================================
+ Hits 37392 40203 +2811
- Misses 3803 3962 +159
Continue to review full report at Codecov.
|
| # 0.0.106 - 2022-03-30 | ||
|
|
||
| ## API Updates | ||
| * Minimum supported rust version (MSRV) is now 1.41.1 (#1310). |
There was a problem hiding this comment.
For now our user base is reasonable so we can follow quickly the still fast-moving rust ecosystem. Though in the future we might give a release or two of warning to our users, it can be a time-consuming task ?
There was a problem hiding this comment.
1.41 is really old - instead of trying to give warning, we instead just only use things that every major linux distro is shipping already, which means they shouldn't have to do anything to an up-to-date system :)
| * `ChannelManager::create_inbound_payment_for_hash`'s documentation has been | ||
| corrected to remove the one-year restriction on `invoice_expiry_delta_secs`, | ||
| which is only applicable to the deprecated `create_inbound_payment_legacy` | ||
| and `create_inbound_payment_for_hash_legacy` methods (#1341). |
There was a problem hiding this comment.
IMHO, it's better to announce a timeline or release number in the deprecation warning, instead to say "will be removed soon" which opens the way for interpretation and thus user bargaining. I know, for a maintainer it might be preferable to use "soon" as it give more room to adapt in function of the user base, though let's be aware it's a double-edge (Yeah the project is young, we might not have a consistent deprecation process that early).
There was a problem hiding this comment.
True, though note this isn't related to any changes for this release.
CHANGELOG.md
Outdated
| feature is on by default (#1388). | ||
| * Lightning feature `option_scid_alias` is now supported and negotiated when | ||
| opening a channel with a peer. It can be configured via | ||
| `ChannelHandshakeConfig::negotiate_scid_privacy` and is off by default. |
There was a problem hiding this comment.
"It is considered to be turn on by default in the future" ?
CHANGELOG.md
Outdated
| set to two weeks ago for the first five peers or otherwise to one hour ago | ||
| (#1382). | ||
| * `ChannelManager::timer_tick_occurred` will now timeout a received multi-path | ||
| payment (MPP) after three ticks if not received in full (#1353). |
There was a problem hiding this comment.
FYI, I think one of the use-case idea of MPP was multi-party payment where the shards would come from different senders. E.g splitting bills at a dinner. I think there is no wallet implementing that right now but time-bounding this change to 3 ticks would be likely a nuisance for that use-case ? Just for awareness, it can be changed back if multi-party MPP become a thing.
CHANGELOG.md
Outdated
| @@ -1,3 +1,112 @@ | |||
| # 0.0.106 - 2022-03-30 | |||
There was a problem hiding this comment.
Never try to predict the date, you'll jinx yourself :p
CHANGELOG.md
Outdated
|
|
||
| ## API Updates | ||
| * Minimum supported rust version (MSRV) is now 1.41.1 (#1310). | ||
| * `PhantomRouteHints`, `FixedPenaltyScorer`, and `ScoringParameters` now |
There was a problem hiding this comment.
I feel like this should be sorted almost at the end - its definitely not the most important thing in 106.
There was a problem hiding this comment.
Moved to the end. I was just going by merge order.
CHANGELOG.md
Outdated
| (#1286). The seed is also used to randomize candidate paths during route | ||
| selection (#1359). | ||
| * `PeerManager::timer_tick_occurred` will disconnect an unresponsive peer after | ||
| four ticks, corresponding to 40 seconds with the new recommendation to call |
There was a problem hiding this comment.
Oops, no, we still disconnect an unresponsive peer after 10 seconds, but we disconnect a peer that is actively sending us messages but not responding to our pings in 40 seconds. I dunno if we even really need to mention it given the "main" disconnection limit is still 10 seconds, but if we do I'd sort it further down and say something about a peer "not responding to our pings during gossip sync".
CHANGELOG.md
Outdated
| * The `lightning` crate has a `grind_signatures` feature used to produce | ||
| signatures with low r-values for more predictable transaction weight. This | ||
| feature is on by default (#1388). | ||
| * Lightning feature `option_scid_alias` is now supported and may be negotiated |
There was a problem hiding this comment.
Isn't this a bit more important than some of the "basically trivial changes" above?
There was a problem hiding this comment.
Was going by merge order but moved now along with the points on #1311. Let me know if you want anything else re-ordered. I can do something more reasonably on my own but don't want to disturb the diff order too much... probably should have made more atomic fixup commits...
| # 0.0.106 - 2022-03-30 | ||
|
|
||
| ## API Updates | ||
| * Minimum supported rust version (MSRV) is now 1.41.1 (#1310). |
There was a problem hiding this comment.
1.41 is really old - instead of trying to give warning, we instead just only use things that every major linux distro is shipping already, which means they shouldn't have to do anything to an up-to-date system :)
CHANGELOG.md
Outdated
| * Reduced time spent processing `channel_update` messages by checking | ||
| signatures after checking if no newer messages have already been processed | ||
| (#1380). | ||
| * `BackgroundProcessor` now persists `NetworkGraph` upon removing stale |
There was a problem hiding this comment.
s/upon removing stale channels/on a timer/?
There was a problem hiding this comment.
Done. Should this be split to have a bullet in API change, too?
There was a problem hiding this comment.
Oh, yea, I feel like this is an API change, not a bugfix.
CHANGELOG.md
Outdated
| * Channels open with `option_scid_alias` negotiated (enabled via | ||
| `ChannelHandshakeConfig::negotiate_scid_privacy`) will not be compatible with | ||
| prior releases (#1351). Similarly for inbound channels where the | ||
| `accept_channel` message has `ChannelTypeFeatures::supports_scid_privacy`. |
There was a problem hiding this comment.
I'd really prefer we explicitly mention the OpenChannelRequest event here - this is quite a big deal so we should be painfully explicit, unlike lots of things where we can be vague and it doesn't matter.
| (#1361). | ||
| * `RoutingMessageHandler::sync_routing_table` has been renamed `peer_connected` | ||
| (#1368). | ||
| * `MessageSendEvent::SendGossipTimestampFilter` has been added to indicate that |
There was a problem hiding this comment.
nit: I do kinda feel like we can leave out stuff that is painfully obvious what to do with it and which will cause downstream compile failures if there's anything a downstream user needs to do with it. ie this wont impact anyone, and in the off-chance it does, its obvious to them what to do and they'll get a compile failure if they dont.
There was a problem hiding this comment.
I suppose that I was thinking release notes also serve to raise awareness of new features before a user decides to upgrade.
There was a problem hiding this comment.
Sure, I don't feel strongly. Its just not clear what a user would do with this - we still exhibit the ~same (or, well, the expected, not the buggy) sync behavior users were expecting, we just have a new enum variant to send a message, but I don't think any users ever actually send manual messages today.
| (#1361). | ||
| * `RoutingMessageHandler::sync_routing_table` has been renamed `peer_connected` | ||
| (#1368). | ||
| * `MessageSendEvent::SendGossipTimestampFilter` has been added to indicate that |
There was a problem hiding this comment.
I suppose that I was thinking release notes also serve to raise awareness of new features before a user decides to upgrade.
| * Matt Corallo | ||
| * Omar Shamardy | ||
| * Viktor Tigerström | ||
| * dependabot[bot] |
There was a problem hiding this comment.
Not to hurt its feelings, but maybe dependabot doesn't need to be mentioned here?
There was a problem hiding this comment.
lol. I, for one, welcome our new robot overlords. #1322 (comment)
There was a problem hiding this comment.
I agree, bots are people, too.
|
@TheBlueMatt Let me know if you're good for me to squash |
|
Yes, feel free to. |
jkczyz
force-pushed
the
2022-03-release-0.0.106
branch
from
ea256d4 to
3b576ea
Compare
CHANGELOG.md
Outdated
| * Channels open with `option_scid_alias` negotiated (enabled via | ||
| `ChannelHandshakeConfig::negotiate_scid_privacy`) will be incompatible with | ||
| prior releases. Similarly, inbound channels accepted from an | ||
| `OpenChannelRequest` with a `channel_type` that has |
There was a problem hiding this comment.
nit: also inbound channels which have that bit and which arent manually accepted.
There was a problem hiding this comment.
Hmmm... does this mean if a peer requests option_scid_alias when opening an inbound channel, the channel will be incompatible with prior versions? Seems like the other two cases require the user to do something explicitly to become incompatible while this case would not based on my reading of the code.
There was a problem hiding this comment.
Yea, we had some brief discussion about this prior to merge. Its definitely far from ideal, the only reason we did it is no one else is going to open these channels yet (only LDK supports any of it as of yet, or will in the immediate future), and adding yet another config flag didn't feel worth it. I'm open to revisiting it, adding a config flag is trivial and we could consider it a bugfix, but I don't feel strongly.
There was a problem hiding this comment.
Don't have a strong opinion but wonder if negotiate_scid_privacy could be used. If false, send an error to the peer if requesting that channel type.
jkczyz
force-pushed
the
2022-03-release-0.0.106
branch
from
3b576ea to
2410bb6
Compare
jkczyz
force-pushed
the
2022-03-release-0.0.106
branch
from
2410bb6 to
ab960e3
Compare
| * Matt Corallo | ||
| * Omar Shamardy | ||
| * Viktor Tigerström | ||
| * dependabot[bot] |
There was a problem hiding this comment.
I agree, bots are people, too.
jkczyz
force-pushed
the
2022-03-release-0.0.106
branch
from
ab960e3 to
de8bb8d
Compare
|
Updated date to today |
No description provided.