* CLN PaymentStatus decoding was incorrect
* don't set Amount when user passes None as the amount
* catch gRPC errors and return appropriate status codes
* clarify in docs that implementation behavior is different when
attempting to pay an already paid invoice
refs #129, refs #131
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
This really applies only to RaspiBlitz. Depending on the current
setup step there still isn't a Bitcoin Deamon or Lightning Node running.
We must defer the registration of all those handlers until later when
everything is properly setup.
Since there is a final reboot after the setup there is no need to
check in the background whether setup is finished. The API server
is restartet anyway.
refs #71
* new endpoint: /lightning/unlock-wallet
* ln endpoints return HTTP_423_LOCKED status if wallet is locked
* bootup sequence defers ln listeners setup if wallet is locked
refs #34
This call currently fetches all invoices, payments and transactions each
time the endpoint is hit. TODO: Find a better way to cache this.
Possibly it is a good idea to build this list once on startup and
keep it updatedwhen new transactions roll in.
refs #30
* password_a must now be posted in the request body as a json object
* password is now read from the .env file instead of hardcoded
* password will be checked if it is min 8 chars
* one_time_password is not yet in use and optional
* /lightning/getbalance now returns onchain funds and channel
balances as one object
* changes to the wallet balance are now pushed through the SSE channel
