Bitcoin backend generalization #3488
Commits on Feb 11, 2020
-
-
libplugin: generalize the plugin_timer callback type
We don't take the callback result into account, so it can better be void. Having a general callback parameter is handy, because for bcli we want to pass it the struct bcli.
-
plugins/bcli: a new plugin for gathering Bitcoin data
Most is taken from lightningd/bitcoind and adapted. This currently exposes 5 commands: - `getchaininfo`, currently called at startup to check the network and whether we are on IBD. - `getrawblockbyheight`, which basically does the `getblockhash` + `getblock` trick. - `getfeerate` - `sendrawtransaction` - `getutxout`, used to gather infos about an output and currently used by `getfilteredblock` in `lightningd/bitcoind`.
-
plugins/bcli: wait for bitcoind to be warmed up at init
This is also taken and adapted from lightningd/bitcoind. The call to 'getblockchaininfo' is replaced by 'echo' as we don't make use of the result and the former can sometimes be slow (e.g. on IBD).
-
-
plugins/libplugin: don't crash if 'lightning-rpc' doesnt exist (yet)
We are going to initialize a plugin before its creation, so log as UNUSUAL instead. Also, `pay` and `fundchannel` inits are using rpc_delve(), so we need to io_new_conn() (which sets the socket as non blocking) after calling the plugin's init.
-
chaintopology: check bitcoin plugin commands at startup
Exit early if we won't be able to fully communicate with our Bitcoin backend.
-
bitcoind: allow commands to be registered by different plugins
An strmap is convenient to get a plugin given a method. Populate it while checking commands.
-
bitcoind: initialize Bitcoin-backend plugin early
We need our Bitcoin backend to be initialized, but the plugins have not yet been started at this point.
-
chaintopology: dont check bitcoin-core version at startup
The Bitcoin backend is generalized through the Bitcoin plugin and this was specific to core.
-
lightningd/chaintopology: use plugin backend to setup topology
This adds `getchaininfo` and `getrawblockbyheight` handling lightningd-side, and use them in setup_topology(). We then remove legacy bitcoind_getblockcount() (we already get the count in `getchaininfo`), bitcoind_getblockchaininfo() (it was only used in setup_topology()), and wait_for_bitcoind() (this was specific to bitcoin-core and we assume our Bitcoin backend to be functional if the plugin responds to `init`).
-
-
lightningd/bitcoind: use the Bitcoin plugin to send transactions
This restrains the informations we get about how the sending went to an errmsg as we cant rely on bitcoin-cli specific output nor its exit code.
-
lightningd/bitcoind: use getrawblockatheight for getfilteredblock
This avoids the getblockhash+getblock, and more importantly that was the last functionality making use of bitcoind_getrawblock() and bitcoin_getblockhash(), so we can also get rid of them.
-
-
lightningd/bitcoind: use the Bitcoin plugin for fee estimates
And remove bitcoin-cli interaction code, now unused.
-
lightningd/bitcoind: remove all bitcoin-cli specific code
Changelog-Added: pluggable backends for Bitcoin data queries, default still bitcoind (using bitcoin-cli).
-
lightningd: clean utxos after the topology is setup
We need our Bitcoin backend to be ready to get infos about some utxos
-
pytest: adjust mocks and logs for bitcoind
For bitcoind_fail_first: We only ever send `getblock` if we got a successful block hash from `getblockhash`, and if we can't get the block in that case it means our Bitcoin backend is faulty and we shouldnt continue. So, mock `getblockhash` instead, which is authorized to spuriously fail. For both bitcoind_fail_first and bitcoind_failure: Adapt the logs.
-
