e83782f5de
This PR: - adds all the guides (in markdown format) that is published at https://docs.corelightning.org/docs - adds a github workflow to sync any future changes made to files inside the guides folder - does not include API reference (json-rpc commands). Those will be handled in a separate PR since they're used as manpages and will require a different github workflow Note that the guides do not exactly map to their related files in doc/, since we reorganized the overall documentation structure on readme for better readability and developer experience. For example, doc/FUZZING.md and doc/HACKING.md#Testing are merged into testing.md in the new docs. As on the creation date of this PR, content from each of the legacy documents has been synced with the new docs. Until this PR gets merged, I will continue to push any updates made to the legacy documents into the new docs. If this looks reasonable, I will add a separate PR to clean up the legacy documents from doc/ (or mark them deprecated) to avoid redundant upkeep and maintenance. Changelog-None
3.3 KiB
title, slug, hidden, createdAt, updatedAt
| title | slug | hidden | createdAt | updatedAt |
|---|---|---|---|---|
| Bitcoin backend | bitcoin-backend | false | 2023-02-03T08:58:27.125Z | 2023-02-21T15:10:05.895Z |
Core Lightning communicates with the Bitcoin network through a plugin. It uses the bcli plugin by default but you can use a custom one, multiple custom ones for different operations, or write your own for your favourite Bitcoin data source!
Communication with the plugin is done through 5 JSONRPC commands, lightningd can use from 1 to 5 plugin(s) registering these 5 commands for gathering Bitcoin data. Each plugin must follow the below specification for lightningd to operate.
getchaininfo
Called at startup, it's used to check the network lightningd is operating on and to get the sync status of the backend.
The plugin must respond to getchaininfo with the following fields:
- chain (string), the network name as introduced in bip70
- headercount (number), the number of fetched block headers
- blockcount (number), the number of fetched block body
- ibd (bool), whether the backend is performing initial block download
estimatefees
Polled by lightningd to get the current feerate, all values must be passed in sat/kVB.
If fee estimation fails, the plugin must set all the fields to null.
The plugin, if fee estimation succeeds, must respond with the following fields:
- opening (number), used for funding and also misc transactions
- mutual_close (number), used for the mutual close transaction
- unilateral_close (number), used for unilateral close (/commitment) transactions
- delayed_to_us (number), used for resolving our output from our unilateral close
- htlc_resolution (number), used for resolving HTLCs after an unilateral close
- penalty (number), used for resolving revoked transactions
- min_acceptable (number), used as the minimum acceptable feerate
- max_acceptable (number), used as the maximum acceptable feerate
getrawblockbyheight
This call takes one parameter, height, which determines the block height of the block to fetch.
The plugin must set all fields to null if no block was found at the specified height.
The plugin must respond to getrawblockbyheight with the following fields:
- blockhash (string), the block hash as a hexadecimal string
- block (string), the block content as a hexadecimal string
getutxout
This call takes two parameter, the txid (string) and the vout (number) identifying the UTXO we're interested in.
The plugin must set both fields to null if the specified TXO was spent.
The plugin must respond to gettxout with the following fields:
- amount (number), the output value in sats
- script (string), the output scriptPubKey
sendrawtransaction
This call takes two parameters, a string tx representing a hex-encoded Bitcoin transaction,
and a boolean allowhighfees, which if set means suppress any high-fees check implemented in the backend, since the given transaction may have fees that are very high.
The plugin must broadcast it and respond with the following fields:
- success (boolean), which is true if the broadcast succeeded
- errmsg (string), if success is false, the reason why it failed