ci/woodpecker/push/woodpecker Pipeline was successfulDetails
ci/woodpecker/tag/woodpecker Pipeline was successfulDetails
the screenlock use case is a way to restrict access to the touchscreen,
for example from children. it is in no way a security measure against
theft or prolonged physical access.
however, nd daemon will refuse to connect to a wifi, switch sysupdates
channel, set a new nodename or init lnd wallet during active screenlock
screenlock pin code can be enabled and disabled from the settings screen.
upon loss of the code, the only way to disable screenlock is to set
slock field to null in the nd daemon conf file.
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
ci/woodpecker/tag/woodpecker Pipeline was successfulDetails
the "nodename" encompasses lnd alias and OS hostname.
while the former may be seen by lightning node peers as a node name, the
latter is how the device is seen on a local network such as WiFi.
upon receiving a comm message set_nodename, nd sets both lightning node
alias and hostname to that new name while applying restrictions such as
RFC 1123 for hostnames.
the lightning alias is written to lnd config file, regenerated and
persistent, after which the lnd daemon is restarted to pick up the
changes. network host name is changed by writing the name to
/etc/hostname and issuing "hostname <newname>" shell command.
while persisting operations are atomic, the whole sequence isn't.
in the latter case an inconsistency can be eliminated by sending a
set_nodename msg again.
the nd daemon also includes the OS hostname in the settings message when
sending it to ngui.
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
the change is based on the previously added ini parser.
this makes lnd config gen more robust and allows to presist config
modifications in the future, such as changing node alias.
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
ci/woodpecker/tag/woodpecker Pipeline was successfulDetails
the daemon can now identify which state lnd is in and report to the GUI
which displays different elements on the lighting tab, based on the
reported lnd state:
- startup in progress: displays spinner
- no lightning wallet: displays a "setup" button and guides the user
through a simple workflow
- reset an operational node
this means, the UI has now minimal but functional elements for any user
equipped with a smart phone to set up the lightning node without SSHing
in or using command line in general.
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
the daemon now pretends the report is sent over to ngui on such errors.
this is a stop-gap to avoid writing errors on tty. see linked issue.
part of #30
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
the "bitcoin" name is overloaded: everything's about bitcoin here.
a less confusing name is onchain to emphasize the difference w.r.t.
lightning or any other future L2 networks.
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
ci/woodpecker/tag/woodpecker Pipeline was successfulDetails
the offending memleak printed out at program exit was introduced in
116fb3b5, specifically line 140 in src/bitcoindrpc.zig using incorrect
allocator.
while there, improved a bit overall memory handling by making sure
heap-alloc'ed messages are always deinit'ed.
another source of trouble was logging from within a sighandler: the
logger uses a thread mutex which may deadlock when the handler is
invoked by the OS.
ci/woodpecker/pr/woodpecker Pipeline was successfulDetails
ci/woodpecker/tag/woodpecker Pipeline was successfulDetails
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
a previous commit added some lightning tab implementation which
including balance details but only for lightning channels.
this commit queries lnd for a wallet balance and displays it on the
bitcoin tab since "wallet" funds are on-chain and it doesn't feel like
it belongs to the lightning tab in the UI.
while there, also improved some daemon backend code style, alightning
with the lightning implementation structures.
similarly to 2642a554, this adds an lnd HTTP client able to make some
queries like getinfo. the daemon then uses the client to compose a
lightning status report and sends it over to ngui through comms,
periodically.
there's also a client playground built on demand with
"zig build lndhc".
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
while there's lots of changes and new features in zig v0.11.0, the most
important for this project at the moment is the HTTP client.
the client is most likely what will connect to lnd lightning node to
fetch stats and info for the UI to then visualize it on "lightning" tab,
similar to the bitcoind RPC client.
see all zig 0.11 release notes here:
https://ziglang.org/download/0.11.0/release-notes.html
this adds a very simple bitcoind RPC client able to make a few queries
like the blockchain and network status. the daemon uses the client
to get the bitcoind status and sends a report through comms periodically.
there's also a little playground program which simply dumps a query
result to stderr. built on demand with "zig build btcrpc".
ci/woodpecker/pr/woodpecker Pipeline was successfulDetails
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
most troubles were due to blocking nature of child process pipe
descriptions which made comm.read loops hang in various places
under certain conditions.
this commit moves all read/writes in separate threads to be able to
always watch for sig TERM and INT, and ensures child process pipes
are closed early allowing comm.read loops to terminate.
the daemon now sends info about the system shutdown progress: a list of
important services which may require up to several minutes to stop such
as lnd lightning daemon and bitcoin core.
see next commit for how this info is displayed and used by the GUI.
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
ci/woodpecker/tag/woodpecker Pipeline was successfulDetails
passed 60 sec of no touch screen activity, daemon turns off backlight
and gui places a black "topdrop", opposite of backdrop. simply touching
the screen reactivates it immediately.
there seem to be no way to turn screen power off, so backlight plus
black topdrop is the next best.
there's no user settings to change 60 sec timeout at the moment because it
is unclear whether it's worth adding UI elements. can always do so later.
the implementation also provides means to reactivate the screen in
an event of an alert from the daemon in the future.
closes #3
alex