contractcourt: track best block height in chain arbitrator #5004
Conversation
| return 0, err | ||
| } | ||
|
|
||
| c.setBestBlock(height) |
There was a problem hiding this comment.
Could it happen that if ChainIO.GetBestBlock() is taking too long then we'll override a recently set best block with a smaller one here?
There was a problem hiding this comment.
Since we'll only need to go to GetBestBlock on startup of chain arb (only time when we'll have a 0 height), I don't think that this will be a problem? But I can add a check to only update if > current height to be safe?
This commit adds tracking of our best block height to the chain arbitrator, relying on our existing block dispatch goroutine to update this value. This change decreases the number of times we need to call GetBestBlock from once per channel, to a single call on startup. This call is pretty slow in bitcoind (up to 5 minutes sometimes, screm), and can slow down channel opening, so we move towards less reliance on it.
carlaKC
force-pushed
the
blockheight-contractcourt
branch
from
5b89cbe to
39241f9
Compare
|
One comment here: if |
Definitely! Opened this because there were some issues reported on slack for funding open, but a more general solution sounds like a better idea. Will look into it. |
|
Closing this out for now. Working on this with @ellemouton in #5084. |
The
GetBestBlockcall can be very slow when using bitcoind backend - up to 5 minutes as we found out in #4669.When we start up arbitrator, we get our best block height every time from this API. This can slow us down on startup, and during the funding flow because we do a fresh lookup every time, the latter affecting applications like pool which require timely responses in the funding flow (thx @C-Otto for the slack report).
This PR makes use of the single block subscription added to the chain arbitrator in #4697 to store out latest known block height, and reduce our reliance on this slow API.