* Stop log spam for missing tor_web_addr
In case tor is not used, we can not find a tor_web_addr key in redis db. This will prevent from spamming the journal.
* log Redis DB missing Keys as Info
* log level Redis DB
only tor as info
* feat: implement SSH CLN wallet unlock on the Blitz
* feat: implement API CLN wallet unlock on the Blitz
* feat: return error when wallet is already unlocked
* docs: update unlock-wallet docs
* fix: add more safety checks
* return 423 error on API calls if wallet locked
* check if unlock script exits with 1
* fix: call_script deprecation warning crash
closes#133
* call_script with sudo
* add call_sudo_script and use where needed
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
During startup the API will try to connect to Bitcoin Core and the
Lightning Node. If it can't connect it will check every "n" seconds
(currently 2s) and connect when available. A new SSE event
called "system_startup_info" is introduced. This event contains
all startup status information during the startup procedure.
The old wallet_locked event is obsolete.
Sample:
--------------------------
event: system_startup_info
data: {"bitcoin": "offline", "bitcoin_msg": "", "lightning": "offline", "lightning_msg": "Unable to connect to LND daemon, waiting..."}
--------------------------
event: system_startup_info
data: {"bitcoin": "done", "bitcoin_msg": "", "lightning": "offline", "lightning_msg": "Unable to connect to LND daemon, waiting..."}
--------------------------
event: system_startup_info
data: {"bitcoin": "done", "bitcoin_msg": "", "lightning": "locked", "lightning_msg": "Wallet locked, unlock it to enable full RPC access"}
--------------------------
event: system_startup_info
data: {"bitcoin": "done", "bitcoin_msg": "", "lightning": "done", "lightning_msg": ""}
--------------------------
event: system_startup_info
data: {"bitcoin": "done", "bitcoin_msg": "", "lightning": "bootstraping", "lightning_msg": "RPC not yet available"}
--------------------------
refs #97
Some remaining issues with current implementation:
Some remaining issues with current implementation:
* Some calls require shell access to lightning-cli as some gRPC calls are not yet implemented
* Getting on-chain fund flows is not as nice as it is with LND and required access to the Core Lightning SQlite database
* With current API you can only get current outputs
* High probability of bugs arising
closes#45
When someone connects to the SSE endpoint and the wallet is
locked a message with event name `wallet_lock_status` type is sent:
```js
// only sent when a new SSE connection is established and the wallet is
// locked at the same time
event: wallet_lock_status
data: {"locked": true}
```
When the wallet is unlocked either through SSH or the API, another
event is sent:
```js
// sent always when a new connection is established when the wallet
// is unlocked, or it is sent when the wallet was unlocked after
// connection was established
event: wallet_lock_status
data: {"locked": false}
```
It is always the first thing the client receives. After the unlock
event, the usual warmup data is sent.
refs #34
This avoids duplicated code with other ln implementations later on.
This also pushes LightningStatus object to the SSE channel
instead of the full LnInfo object.
refs #11
* /lightning/getbalance now returns onchain funds and channel
balances as one object
* changes to the wallet balance are now pushed through the SSE channel
