Skip to content
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

rpc+contractcourt: merge the contractResolver state into the pendingchannels RPC response #1875

Merged
merged 5 commits into from Feb 2, 2019

Conversation

@joostjager
Copy link
Collaborator

@joostjager joostjager commented Sep 10, 2018

@joostjager joostjager force-pushed the joostjager:resolverstate branch 3 times, most recently from 6a98580 to 3d99ff9 Sep 10, 2018
@Roasbeef
Copy link
Member

@Roasbeef Roasbeef commented Dec 4, 2018

I'd like to pick this back up, with the exclusion of the commit to detect spends in the nursery. Since then, we've created the Sweeper which itself will handle this notification case. It still stands that as is, the API is blind to these HTLCs that haven't yet timed out causing much user confusion and an inability to properly track all funds throughout the timeout cycle. Even after the new sweeper changes have been merged, we'll still need this for the lifetime that the current nursery exists (and the resolvers will still report directly back to the API).

@Roasbeef Roasbeef added this to Blocked in High Priority Dec 18, 2018
@joostjager joostjager force-pushed the joostjager:resolverstate branch 3 times, most recently from 69a35fc to 288652f Jan 7, 2019
@joostjager
Copy link
Collaborator Author

@joostjager joostjager commented Jan 7, 2019

Some observations on the current reporting situation:

  • When the channel is fully closed, the close summary doesn't show any information on the recovered balance. Just the settled balance at the time of closure.
  • During pending close, only recovered balance from locked outputs is reported.
  • During pending close, recovered balance stays in the report even when contract resolvers have already finished. The data is kept in the utxonursery graduation table.
  • Some nursery report fields are unused. I removed them in commit utxonursery: remove unused report fields.

Is this the desired behaviour? Ideally I think you'd want to see:

  • In addition to the settled balance, report in the channel close summary: recovered balance, lost (to remote) balance and chain fees. These should add up to the settled balance.
  • During pending close, show limbo balance, recovered balance, lost (to remote) balance and chain fees. All reported per output. This should again add up to the settled balance. Contrary to current behaviour, also add commitment no delay outputs as recovered balance.
  • Open question is how to attribute the on-chain sweeper fee to the various inputs. One option is to make some kind of proportional calculation it the sweeper and report the per input fee back as part of the sweeper result struct.

Implementation implications:

  • Currently the channel close summary is already written before the contract resolvers finish their work. This order would need to change.
  • The point that we are working towards is to get rid of utxonursery completely. That means that all reporting should originate from the contract resolvers. Currently contract resolvers disappear after the have finished. At that point, the information on recovered/lost/fee balances is lost. To be able to keep reporting this, it should be persisted somewhere else (briefcase?). Or alternatively, contract resolvers should be kept alive until all of them have finished.
  • How to make a small first step? An option is to remove UtxoNursery.NurseryReport() and pull all data from the contract resolvers. If we don't want the changeset to get big, this would mean that reporting on recovered balance during pending close would disappear. I doubt this is a problem, as recovered balance is currently already incomplete. In exchange for this, we'd get accurate limbo balance reporting, because the source is now the contract resolver that has full information on what is going on.
@Roasbeef
Copy link
Member

@Roasbeef Roasbeef commented Jan 8, 2019

When the channel is fully closed, the close summary doesn't show any information on the recovered balance. Just the settled balance at the time of closure.

Yes we atm we only record the fully settled amount, as depending on a number of parameters (if it's batched, the fee rate, etc) we may actually sweep less than the total amount settled at closing time.

During pending close, only recovered balance from locked outputs is reported.

We report the CSV outputs, and HTLC outputs as they transition from stage 1 to stage 2. We also report the total limbo balance, and the amount of coins recovered at that given instance.

During pending close, recovered balance stays in the report even when contract resolvers have already finished. The data is kept in the utxonursery graduation table.

Yep, it's part of the base report. Only once all the outputs that were created by a channel have been resolved do we no longer report on it.

In addition to the settled balance, report in the channel close summary: recovered balance, lost (to remote) balance and chain fees. These should add up to the settled balance.

Agree this would be a good addition in order to ensure users have access to this data without doing any manual block chain crawling. I think it's out of the scope for this PR though, which should be focused on fixing the egregious blind spots.

During pending close, show limbo balance, recovered balance, lost (to remote) balance and chain fees. All reported per output. This should again add up to the settled balance. Contrary to current behavior, also add commitment no delay outputs as recovered balance.

All this but chain fees and the non delay output are already reported. Agree it would be nice to also show the confirmation status of the non-delay output as well. I don't think this would expand the scope of this PR too significantly, as arguably it's a blind spot in the current report and confirmations can take some time on mainnet.

Open question is how to attribute the on-chain sweeper fee to the various inputs.

Yeah we also have this issue where we want to account for the full amount recovered when we need to claim HTLCs on chain. I think this can be deferred from this PR and either picked up in #2075, or a sort of "fee report" message that can be requested from the sweeper (new PR all together).

Currently the channel close summary is already written before the contract resolvers finish their work. This order would need to change.

We can still write the close summary as soon as we detect a channel close, but then update the fields as we go.

At that point, the information on recovered/lost/fee balances is lost. To be able to keep reporting this, it should be persisted somewhere else (briefcase?).

Yeah so we'd basically progressively move over this state from the nursery over to the main channel arb.

@Roasbeef
Copy link
Member

@Roasbeef Roasbeef commented Jan 8, 2019

How to make a small first step?

I think the first step would be to ensure we report (via the resolver) the state of the HTLCs that haven't yet timed out. Once they timeout, they get handed off to the nursery and can be reported externally as part of the regular nursery report. Next would be to report the state of the non-delay output while it hasn't yet been fully swept. After that we'd start to store within the channel arb's log the finalized state of all resolved contracts. The final step would then be moving all accounting from the NurseryReport method into the channel arb itself.

@joostjager joostjager force-pushed the joostjager:resolverstate branch 3 times, most recently from fd9d073 to dfadff1 Jan 16, 2019
@joostjager joostjager force-pushed the joostjager:resolverstate branch 9 times, most recently from cdc1e98 to baf480f Jan 17, 2019
@joostjager joostjager changed the title rpc+contractcourt: merge the contractResolver state into the pendingchannels RPC response [DO NOT REVIEW] rpc+contractcourt: merge the contractResolver state into the pendingchannels RPC response Jan 17, 2019
@joostjager joostjager force-pushed the joostjager:resolverstate branch from baf480f to d0382b1 Jan 17, 2019
@joostjager
Copy link
Collaborator Author

@joostjager joostjager commented Jan 17, 2019

@Roasbeef It is ready for review

@joostjager joostjager requested a review from Roasbeef Jan 21, 2019
@Roasbeef Roasbeef added this to the 0.6 milestone Jan 22, 2019
Copy link
Member

@Roasbeef Roasbeef left a comment

Nice work! I like the little fix ups and refactoring along the way. No major comments, mostly style related nits. Happy to have this hole patched before we continue to overhaul the resolvers to communicate directly with the sweeper.

contractcourt/channel_arbitrator.go Show resolved Hide resolved
utxonursery.go Show resolved Hide resolved
rpcserver.go Outdated Show resolved Hide resolved
contractcourt/channel_arbitrator.go Outdated Show resolved Hide resolved
contractcourt/channel_arbitrator.go Outdated Show resolved Hide resolved
contractcourt/contract_resolvers.go Show resolved Hide resolved
contractcourt/htlc_incoming_contest_resolver.go Outdated Show resolved Hide resolved
High Priority automation moved this from Blocked to Needs review Jan 23, 2019
@joostjager joostjager force-pushed the joostjager:resolverstate branch from 49ca500 to d17a996 Jan 23, 2019
@joostjager
Copy link
Collaborator Author

@joostjager joostjager commented Jan 23, 2019

@Roasbeef PTAL

@joostjager joostjager force-pushed the joostjager:resolverstate branch from d17a996 to 3a29cb2 Jan 24, 2019
Copy link
Collaborator

@halseth halseth left a comment

Looks pretty good!

rpcserver.go Show resolved Hide resolved
contractcourt/channel_arbitrator.go Outdated Show resolved Hide resolved
contractcourt/htlc_incoming_contest_resolver.go Outdated Show resolved Hide resolved
contractcourt/htlc_outgoing_contest_resolver.go Outdated Show resolved Hide resolved
err := r.nurseryPopulateForceCloseResp(
&chanPoint, currentHeight, forceClose,
)
if err != nil {
return nil, err
}

err = r.arbitratorPopulateForceCloseResp(

This comment has been minimized.

@halseth

halseth Jan 28, 2019
Collaborator

nit: add comment

This comment has been minimized.

@joostjager

joostjager Jan 29, 2019
Author Collaborator

Comment above applies to this statement as well

contractcourt/channel_arbitrator.go Show resolved Hide resolved
contractcourt/channel_arbitrator.go Show resolved Hide resolved
contractcourt/chain_arbitrator.go Show resolved Hide resolved
contractcourt/channel_arbitrator.go Show resolved Hide resolved
contractcourt/channel_arbitrator.go Show resolved Hide resolved
@joostjager joostjager force-pushed the joostjager:resolverstate branch from 3a29cb2 to c0b19f4 Jan 29, 2019
@joostjager
Copy link
Collaborator Author

@joostjager joostjager commented Jan 29, 2019

ptal @halseth

Copy link
Member

@Roasbeef Roasbeef left a comment

LGTM 🎿

One last comments, then g2g from my PoV.

// new resolver.
c.activeResolversLock.Lock()
for i, r := range c.activeResolvers {
if r == currentContract {

This comment has been minimized.

@Roasbeef

Roasbeef Feb 1, 2019
Member

Comparing pointers makes me nervous at times, instead this can use the ResolverKey() method directly.

This comment has been minimized.

@joostjager

joostjager Feb 1, 2019
Author Collaborator

Yes valid point. Fixed and replace operation extracted to method.

joostjager added 3 commits Sep 10, 2018
Previously the arbitrator wasn't advanced to the final stage after
the last contract resolved.

Also channel arbitrator now does not ignore a log error anymore
unresolved contracts cannot be retrieved.
@joostjager joostjager force-pushed the joostjager:resolverstate branch from c0b19f4 to 8f778e0 Feb 1, 2019
joostjager added 2 commits Sep 7, 2018
In this commit we fix a reporting gap that previously existed for htlcs
that were still contested.
This commit closes a reporting gap for htlc outputs on the remote
commitment tx. Those are waited out by nursery, but were not reported
before.
@joostjager joostjager force-pushed the joostjager:resolverstate branch from 8f778e0 to ca619bf Feb 1, 2019
@joostjager
Copy link
Collaborator Author

@joostjager joostjager commented Feb 1, 2019

ptal @Roasbeef

Copy link
Member

@Roasbeef Roasbeef left a comment

LGTM 🔱

@Roasbeef Roasbeef merged commit 6032e47 into lightningnetwork:master Feb 2, 2019
1 of 2 checks passed
1 of 2 checks passed
coverage/coveralls Coverage decreased (-0.09%) to 59.162%
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
High Priority automation moved this from Needs review to Done Feb 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
High Priority
  
Done
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants