Lightning Networkの場合、トランザクション署名が頻繁に発生する。 発生する契機がチャネル残高が変化する時で、中継に成功した場合だけでなく失敗した場合にも発生する。 中継ノードは四六時中署名していることになる。 もし署名がHWWでつど人がカチカチ操作してたら遅すぎて通信が成立しない。 ホットウォレットであるライトニングノードが前提のネットワークだと思う。

ウォレット 受け取る、送る、残高確認するためのアプリ だいたいそんなもん。

今日リリースされたBTCPay Server1.12.0はプラグイン周りが変わったのか、1.11から引き継げないっぽい。 本体だけdocker イメージ差し替えアプデしてみたら起動しないし。

lndhub.goを間にかませることでBTCPay Serverにアウトバウンドへのフルアクセスを回避するねらいがある。 lndhub.go自身はフルアクセスできますが、各ユーザーは(バグってなければ)できない。

BTCPay Serverとlndhub.goを同じUmbrel用Dockerブリッジに収容しとけばIPアドレス固定しなくてもコンテナ名で通信できるっぽいので良き。

lndhub.goはAlbyが開発していて、メンテもしている。

GitHub

GitHub - getAlby/lndhub.go: Accounting wrapper for the Lightning Network. It provides separate accounts for end-users. (LndHub compatible API written in Go)

Accounting wrapper for the Lightning Network. It provides separate accounts for end-users. (LndHub compatible API written in Go) - getAlby/lndhub.go

BlueWalletが開発した本家lndhubはBTCPay Serverとうまく繋がらないのでな。

Umbrel Community Store形式で自分用にlndhub.goを作った。 BTCPay Server→lndhub.go→LNDという構成にしたかった。

zap.streamでLo-Fiを聞けるとは思わなんだ。

http(s)でしゃべるchromeやsafari、edge、Firefox、Braveなどその他たくさんありますね。