[RFC] lightningd: pass the current known block height down to the getchaininfo call

[vincenzopalazzo]

When core lightning is asking the information about
the blockchain with getchaininfo command lightningd
know already the information about the min and max block height.

the problem is when we have a smarter Bitcoin backend that is able
to switch between different clients in some cases is helpful
give the information about current known height by lightningd and
pass it down to the plugin.

In this way, the plugin knows what is the correct known height from lightnind, and can
try to fix some problems if any exist.

This is particularly useful when you are syncing a new backend from scratch
like https://github.com/cloudhead/nakamoto and we avoid returning the
lower height from the known, and avoid the crash of core lightning.

With this information, the plugin can start to sync the chain and return
the answer back only when the chain is in sync with the current status of
lightning.

Used to fix the switch backend in https://github.com/coffee-tools/folgore

[vincenzopalazzo]

Trivial Rebase

[rustyrussell]

I think this is the wrong approach?

We should really handle blockheight below what we expect more gracefully. Possibly by just waiting for bitcoind to catch up?

[vincenzopalazzo]

We should really handle blockheight below what we expect more gracefully. Possibly by just waiting for bitcoind to catch up?

Mh, yeah, if we want to fix this in core lightning, we can try waiting for bitcoind to sync up instead of failing. However, there are some corner cases that lead me to propose this change.

Bitcoin Core is extremely slow to sync up, so the question here is, how long should we wait? The time depends on various factors.
With this approach of informing the plugin about the height, in some cases, you can start the syncing but move the execution to another backend until the previous one is ready.

The problem I want to solve is that I don't want to be left in the dark when we run getchaininfo, and I want to have the opportunity to wait for the blockchain sync or decide to dispatch the request elsewhere.

In my specific case, I was integrating a BIP 157 compatible backend, so it was very convenient to use wait_height(..). It takes a maximum of a couple of minutes, in contrast to Bitcoin Core's syncing process.

But again, I am happy to work on a solution inside core lightning if you do not think my is the correct path

[rustyrussell]

Minor changes, but also mention the new parameter in docs/PLUGINS.md?

[vincenzopalazzo]

Thanks @rustyrussell

Review applied and also commit docs updated to clarify why we are not
adding the wait height inside the core lightning itself to keep track of
these kinds of changes.

[rustyrussell]

Ack 3fc8b3e

[vincenzopalazzo]

Added the changelog inside the commit (we miss the check in the CI, if the CI fails in some previous steps) and trivial rebase!

Ack f3bfd1d