Phoenix for server (2)
Phoenix for server をもう少し調べます。
phoenixd を起動し phoenix-cli で操作します。別のコマンドから操作できるということは何らかのAPIがあるということになります。 bitcoind は JSON-RPC、Core Lightning もベースは JSON-RPC(UNIX socket)でプラグインを使うなり作るなりできる。Eclair はURLにコマンドを書くので REST か。LNDは一応 gRPC で 、REST APIに変換する機構を持っています(lnd.confで有効にしないと使えなかったような)。
コマンドラインでできることは、基本的にはAPIを使って自分で実装しても同じことができます。API にないのにできるのは LND の chantools のように別経路を使う場合だけでしょう。
Pheonix for server は API ページがあり、 phoenix-cli で操作できる内容と一致しています。パスにコマンドが載っているので REST API になるのですかね。
コマンドにないのは、通知系でした。websocket と webhook があるそうです。受金に関する通知のみのようです。送金側もその場で完了できない場合があるのでどうやって確認するのかと思いましたが getoutgoingpayment を使うのでしょう。
入金の方は getincomingpayment を使うのでしょうが、こちらは引数が payment_hash でした。outgoing が payinvoice の戻り値である paymentId を使っているので不思議ですね。偶然に同じ payment_hash の invoice をもらうという心配をしているのかもしれません。
phoenix-cli の実装を見ても、パラメータをAPI用に仕立て直しているくらいです。
API を呼ぶときは Basic認証のパスワードがいるのですが、それは ./phoenix/phoenix.conf の http-password に書いてある文字列そのままです。ユーザ名は何でもよいようでした。
$ passwd=xxxxxx
$ curl http://127.0.0.1:9740/getinfo -u nayuta:$passwd
{
"nodeId": "02f916d5b......234203a9b955f9f",
"channels": [
],
"chain": "testnet",
"version": "0.1.3-d805f81"APIも少ないし、動かすのにそれほど悩むことはないと思います。
Phoenix for server の利点ですが、始めるのが楽なことでしょう。bitcoind のようなフルノードを準備しないといけないとなると、バイナリを用意して動かすのはまだよいとしてもストレージの使用量がかなり重荷になります。最初だけとはいえブロックのダウンロードが終わるまでの時間も相当なものです。LND の neutrino も軽いとはいえブロックヘッダのダウンロードは必要ですし、たまによくわからないですが同期できないときがあったりします(これなんなんでしょうね…)。
Phoenix はバックエンドとしてElectrum server を使っているので、Phoenix for server も同じはずです。フルノードではないですし、LSP しか相手ノードにならないのであれば気にしても仕方がないと思います。それが嫌な人はそもそも使わないでしょうし。
ストレージをあまり使わないところもありがたいです。testnet でチャネルも開かず立ち上げただけだとファイルは 200KBもありませんでした。
気になるところとしては、Phoenix と同じで fee でしょうか。まあしょうがないとは思うのですが。あとは fee credit ですね。この形式が受け入れられるのかどうかという点で興味があります。
