Skip to content

fixup! Use CLTV as tie-breaker for offered htlc output sorting (#790) #1360

Merged
pm47 merged 11 commits intomasterfrom
fix-directed-htlc
Mar 31, 2020
Merged

fixup! Use CLTV as tie-breaker for offered htlc output sorting (#790) #1360
pm47 merged 11 commits intomasterfrom
fix-directed-htlc

Conversation

@pm47
Copy link
Member

@pm47 pm47 commented Mar 31, 2020

This is a follow-up to #790 with more refactoring.

@pm47 pm47 requested review from araspitzu and t-bast March 31, 2020 09:49
- check actual content instead of only success and roundtrip
- use randomized data for all fields instead of all-zero
- check the remaining data, not only the decoded value (codecs are
chained so a regression here will cause the next codec to fail)

cc @araspitzu
@araspitzu
Copy link
Contributor

I wonder if we should make a type alias or case class for Set[DirectedHtlc]. Since we often run filter/collect functions on it we could simplify the code by exposing our own filterIncoming and filterOutgoing but maybe it's an overkill.

spec.findHtlcById(htlcId, direction.opposite) match {
case Some(htlc) if direction == OUT => spec.copy(toLocal = spec.toLocal + htlc.add.amountMsat, htlcs = spec.htlcs - htlc)
case Some(htlc) if direction == IN => spec.copy(toRemote = spec.toRemote + htlc.add.amountMsat, htlcs = spec.htlcs - htlc)
def fulfillOutgoingHtlc(spec: CommitmentSpec, htlcId: Long): CommitmentSpec = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the naming becomes counter-intuitive with this refactoring.
It made sense to say fulfillHtlc(spec, OUT, id) to mean that you were the one sending the fulfill (and fulfillHtlc(spec, IN, id) when you were the one receiving the fulfill).

Now it's really weird because we're saying fulfillOutgoingHtlc for an incoming HTLC, and fulfillIncomingHtlc for an outgoing HTLC...I would reverse that: fulfillOutgoingHtlc should fulfill an HTLC you sent, and fulfillIncomingHtlc should fulfill one you received.

It's the same for the failXXX functions below.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, this file is a mess, surely we can do better.

Copy link
Member

@t-bast t-bast left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, it's much better with these partial functions

…pec.scala

Co-Authored-By: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
Copy link
Contributor

@araspitzu araspitzu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a final nit on my side but the rest is ACK

araspitzu
araspitzu previously approved these changes Mar 31, 2020
Copy link
Member

@t-bast t-bast left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want to address https://github.com/ACINQ/eclair/pull/1360/files#r400825220 right now or do you want to do it in a follow-up PR? I think the current naming of the functions is really backwards

@pm47
Copy link
Member Author

pm47 commented Mar 31, 2020

I'm not sure, tbh I started this just with 617e2e6 in mind and pulled the thread... I think if we don't have a better idea right now, let's merge this now, we can always improve later.

@t-bast
Copy link
Member

t-bast commented Mar 31, 2020

My proposal is to simply switch the names between the two functions, what do you think?

  • fulfillOutgoingHtlc is what you call when the remote sent you an UpdateFulfillHtlc
  • fulfillIncomingHtlc is what you call when you are about to send an UpdateFulfillHtlc

That sounds simple enough and coherent, is there an issue with that?
It always uses our node as the "point of view".

@codecov-io
Copy link

Codecov Report

Merging #1360 into master will increase coverage by 0.10%.
The diff coverage is 97.22%.

@@            Coverage Diff             @@
##           master    #1360      +/-   ##
==========================================
+ Coverage   86.35%   86.45%   +0.10%     
==========================================
  Files         119      119              
  Lines        9253     9259       +6     
  Branches      398      390       -8     
==========================================
+ Hits         7990     8005      +15     
+ Misses       1263     1254       -9     
Impacted Files Coverage Δ
.../fr/acinq/eclair/transactions/CommitmentSpec.scala 82.50% <92.59%> (-2.35%) ⬇️
...in/scala/fr/acinq/eclair/channel/Commitments.scala 90.90% <100.00%> (+0.15%) ⬆️
...c/main/scala/fr/acinq/eclair/channel/Helpers.scala 96.49% <100.00%> (-0.01%) ⬇️
.../eclair/payment/relay/PostRestartHtlcCleaner.scala 88.00% <100.00%> (-0.19%) ⬇️
...ain/scala/fr/acinq/eclair/wire/ChannelCodecs.scala 100.00% <100.00%> (ø)
...src/main/scala/fr/acinq/eclair/router/Router.scala 92.65% <0.00%> (+0.66%) ⬆️
...q/eclair/blockchain/electrum/ElectrumWatcher.scala 56.00% <0.00%> (+2.39%) ⬆️
...clair/blockchain/electrum/ElectrumClientPool.scala 82.79% <0.00%> (+4.30%) ⬆️

@pm47
Copy link
Member Author

pm47 commented Mar 31, 2020

My proposal is to simply switch the names between the two functions, what do you think?

That sounds entirely reasonable, done with 33977e5.

@pm47 pm47 merged commit 4875d4c into master Mar 31, 2020
@pm47 pm47 deleted the fix-directed-htlc branch March 31, 2020 16:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants