mirror of
https://github.com/ElementsProject/lightning.git
synced 2025-03-15 11:59:16 +01:00
feat(bitcoind): pass the current known block height
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 exit. 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 lightningd. Another reason to add this field and not wait the correct block in core lightning itself is because 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. Changelog-Added: Pass the current known block height down to the getchaininfo call. Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
This commit is contained in:
parent
8c02d9587d
commit
85992e6e48
6 changed files with 19 additions and 7 deletions
|
@ -1716,7 +1716,8 @@ data. Each plugin must follow the below specification for `lightningd` to operat
|
|||
### `getchaininfo`
|
||||
|
||||
Called at startup, it's used to check the network `lightningd` is operating on and to
|
||||
get the sync status of the backend.
|
||||
get the sync status of the backend. Optionally, the plugins can use `last_height` to
|
||||
make sure that the Bitcoin backend is not behind core lightning.
|
||||
|
||||
The plugin must respond to `getchaininfo` with the following fields:
|
||||
- `chain` (string), the network name as introduced in bip70
|
||||
|
|
|
@ -578,6 +578,7 @@ static void getchaininfo_callback(const char *buf, const jsmntok_t *toks,
|
|||
|
||||
void bitcoind_getchaininfo_(struct bitcoind *bitcoind,
|
||||
const bool first_call,
|
||||
const u32 height,
|
||||
void (*cb)(struct bitcoind *bitcoind,
|
||||
const char *chain,
|
||||
u32 headercount,
|
||||
|
@ -598,6 +599,7 @@ void bitcoind_getchaininfo_(struct bitcoind *bitcoind,
|
|||
req = jsonrpc_request_start(bitcoind, "getchaininfo", NULL, true,
|
||||
bitcoind->log,
|
||||
NULL, getchaininfo_callback, call);
|
||||
json_add_u32(req->stream, "last_height", height);
|
||||
jsonrpc_request_end(req);
|
||||
bitcoin_plugin_send(bitcoind, req);
|
||||
}
|
||||
|
|
|
@ -95,6 +95,7 @@ void bitcoind_getfilteredblock_(struct bitcoind *bitcoind, u32 height,
|
|||
|
||||
void bitcoind_getchaininfo_(struct bitcoind *bitcoind,
|
||||
const bool first_call,
|
||||
const u32 height,
|
||||
void (*cb)(struct bitcoind *bitcoind,
|
||||
const char *chain,
|
||||
u32 headercount,
|
||||
|
@ -102,8 +103,8 @@ void bitcoind_getchaininfo_(struct bitcoind *bitcoind,
|
|||
const bool ibd,
|
||||
const bool first_call, void *),
|
||||
void *cb_arg);
|
||||
#define bitcoind_getchaininfo(bitcoind_, first_call_, cb, arg) \
|
||||
bitcoind_getchaininfo_((bitcoind_), (first_call_), \
|
||||
#define bitcoind_getchaininfo(bitcoind_, first_call_, height_, cb, arg) \
|
||||
bitcoind_getchaininfo_((bitcoind_), (first_call_), (height_), \
|
||||
typesafe_cb_preargs(void, void *, \
|
||||
(cb), (arg), \
|
||||
struct bitcoind *, \
|
||||
|
|
|
@ -1287,7 +1287,7 @@ static void retry_check_chain(struct chain_topology *topo)
|
|||
topo->bitcoind->checkchain_timer = NULL;
|
||||
if (topo->stopping)
|
||||
return;
|
||||
bitcoind_getchaininfo(topo->bitcoind, false, check_chain, topo);
|
||||
bitcoind_getchaininfo(topo->bitcoind, false, topo->max_blockheight, check_chain, topo);
|
||||
}
|
||||
|
||||
void setup_topology(struct chain_topology *topo,
|
||||
|
@ -1306,7 +1306,7 @@ void setup_topology(struct chain_topology *topo,
|
|||
|
||||
/* Sanity checks, then topology initialization. */
|
||||
topo->bitcoind->checkchain_timer = NULL;
|
||||
bitcoind_getchaininfo(topo->bitcoind, true, check_chain, topo);
|
||||
bitcoind_getchaininfo(topo->bitcoind, true, topo->max_blockheight, check_chain, topo);
|
||||
|
||||
tal_add_destructor(topo, destroy_chain_topology);
|
||||
|
||||
|
|
|
@ -656,7 +656,15 @@ static struct command_result *getchaininfo(struct command *cmd,
|
|||
const char *buf UNUSED,
|
||||
const jsmntok_t *toks UNUSED)
|
||||
{
|
||||
if (!param(cmd, buf, toks, NULL))
|
||||
/* FIXME(vincenzopalazzo): Inside the JSON request,
|
||||
* we have the current height known from Core Lightning. Therefore,
|
||||
* we can attempt to prevent a crash if the 'getchaininfo' function returns
|
||||
* a lower height than the one we already know, by waiting for a short period.
|
||||
* However, I currently don't have a better idea on how to handle this situation. */
|
||||
u32 *height UNUSED;
|
||||
if (!param(cmd, buf, toks,
|
||||
p_req("last_height", param_number, &height),
|
||||
NULL))
|
||||
return command_param_failed();
|
||||
|
||||
start_bitcoin_cli(NULL, cmd, process_getblockchaininfo, false,
|
||||
|
|
|
@ -1759,7 +1759,7 @@ def test_bcli(node_factory, bitcoind, chainparams):
|
|||
assert 'feerate_floor' in estimates
|
||||
assert [f['blocks'] for f in estimates['feerates']] == [2, 6, 12, 100]
|
||||
|
||||
resp = l1.rpc.call("getchaininfo")
|
||||
resp = l1.rpc.call("getchaininfo", {"last_height": 0})
|
||||
assert resp["chain"] == chainparams['name']
|
||||
for field in ["headercount", "blockcount", "ibd"]:
|
||||
assert field in resp
|
||||
|
|
Loading…
Add table
Reference in a new issue