NostrクライアントのLN組み込み方法4-L402-

どうも、「NostrはLNがWeb統合されマネーのインターネットプロトコルとしてのビットコインが本気出す具体行動のショーケースと見做せばOK」です、こんばんは。 またまた実験的な試みがNostrで行われているのでレポートします。本シリーズはライブ感を重視しており、例によって（？）プルリクエストなどはレビュー段階なのでご承知おきください。 今回の主役はあくまでLightningNetworkの新提案（ただし以前からあるLSATからのリブランディング）となるLightning HTTP 402 Protocol（略称: L402）です。そのショーケースの一つとしてNostrが活用されているというものになります。 Lightning HTTP 402 Protocol（略称: L402）とは何か bLIPに今月挙がったプロポーザル内容です。 L402について私はまだ完全に理解した段階ではあるのですがなんとか一言で説明しようとすると「Authトークンのように"Paid"トークンをHTTPヘッダーにアタッチして有料リソースへのHTTPリクエストの受け入れ判断を行えるようにする」ものだと解釈しました。 Authenticationでは、HTTPヘッダーにAuthトークンを添付し、その検証が通ればHTTPリクエストを許可し、通らなければ401 Unauthorizedコードをエラーとして返すように定められています。<a href="https://developer.mozilla.org/ja/docs/Web/HTTP/Status/401" target="_blank" rel="no

NostrクライアントのLN組み込み方法3-Nostr Wallet Connect-

どうも、「NostrはLNがWeb統合されマネーのインターネットプロトコルとしてのビットコインが本気出す具体行動のショーケースと見做せばOK」です、こんにちは。前回まで投げ銭や有料購読の組み込み方法を見てきました。 zapsという投げ銭機能が各種クライアントに一通り実装されて活用が進んでいることで、統合は次の段階へ移り始めています。「作戦名: ウォレットをNostrクライアントに組み込め」です。今回はそちらをまとめます。 投げ銭する毎にいちいちウォレットを開いてまた元のNostrクライアントに手動で戻らないといけない is PAIN LNとNostrはインボイス文字列で繋がっているだけの疎結合ですが、投稿に投げ銭するためには何かのLNウォレットを開いて支払いをして、また元のNostrクライアントに戻る操作をユーザーが手作業でする必要があります。お試しで一回やる程度では気になりませんが普段使いしているとこれはけっこうな煩わしさを感じるUXです。特にスマホでは大変にだるい状況になります。連打できない！ 2月の実装以来、zapsは順調に定着して日々投げられています。 <img src="https://s3-ap-northeast-1.amazonaws.com/spotlight-s3-001/article/202304

続・NostrクライアントのLN組み込み方法-Zaps-

前回の続きです。 特に「Snortで試験的にノート単位に投げ銭できる機能」について。実は記事書いた直後にリリースされて慌ててw追記してたんですが追い付かないということで別記事にしました。 今回のここがすごい！ 「Snortで試験的にノート単位に投げ銭できる機能」では一つブレイクスルーが起こっています。それは「ウォレットにインボイスを放り投げた後に払い込み完了を提示できる」ようになったことです。これによりペイメントのライフサイクルが一通りカバーされたことになります。 Snortの画面 なにを当たり前のことをという向きもあるかもしれませんが、Nostrクライアントで払い込み完了を追跡することはとても難しいです。基本的にNostrとLNウォレットはまったく別のアプリケーションで両者の間を繋ぐのはインボイス文字列だけです。ウォレットもNostrからキックされずに、インボイス文字列をコピペするなりQRコードで読み取ったものを渡されるだけかもしれません。またその場でリアルタイムに処理される前提もありません。 なのでNostrクライアントでその後をトラックすることは難しく、これまではあくまで請求書を送付したり（LNインボイス）振り込み口座を提示する（LNアドレス）という一方的に放り投げてただけだったわけです。といっても魔法のようにNostrクライアントがトラッ

NostrクライアントのLN組み込み方法

Nostrクライアントは多種ありますがメジャーなものはだいたいLNの支払いが用意されています。現時点でどんな組み込み方法になっているか調べました。この記事では主にSnortを対象にしています。 LN活用場面 大きくLNアドレスとLNインボイスの2つの形式があります。 1. LNアドレスで投げ銭をセットできる LNURLのLNアドレスをセットすると、プロフィールやノート（ツイートに相当）からLN支払いができます。別クライアントのastralなどではプリミティブなLNURLの投げ銭形式（lnurl1dp68～）でもセットできます。 [追記]さらに本日、Snortで試験的にノート単位に投げ銭できる機能が追加されています。 2. LNインボイスが投稿できる 投稿でLNインボイスを貼り付ければ上記のように他の発言と同じようにタイムラインに流れます。Payボタンを押すと各自の端末にあるLNウォレットが立ち上がります。 3. DMでLNインボイスを送る メッセージにLNインボイスが組み込まれているという点では2とほぼ同じですが、ユースケースが異なります。発表されたばかりですが<a href="https://andreneves.xyz/p/the-rise-of-paid-nostr-relays?utmsource=substack&utmcampaign=postembed&utmmedium=email" target="_blank" r

LNの料金市場の適正水準を整理する

LNの手数料の適正水準はどう見積もったらいいだろうか？ルーティングノードの収益性を算出するためにはどうアプローチすればよいだろうか？本記事ではルーティングノード運用のポジションに立ち参考になりそうな数値や計算式を整理する。 個人的な感想を先に書くと以下となる。 現在の手数料市場は収益性が低くもっと手数料が上がった方が健全である。 他の決済手段と比較すると、LN支払い料金は10000ppm（手数料1%相当）でも十分ではないか。5ホップとすると中間1ノードあたり2500ppmである。 ルーティングノードの収益性を考えると、1000ppmあれば1BTC程度の資金で年利2.8%になり半年で初期費用回収できるので十分な投資対象になると考える。 基本概念の整理 LNの料金方式 LNの手数料は送金額に応じた料率方式が主になる。（基本料金の設定もあるが1 ~ 0 satsが大半） 料率単位のppm（parts per million）は、1,000,000satsを送るときの手数料をsats金額で示したもの。 %での手数料率に変換すると1000ppm = 0.1%になる。 支払い者が払う手数料はルーティングに参加した各ノードの手数料の合計である。本稿では5ホップ（経由ノードは4つ）のルーティングがあるとすれば、各ノードの取り分は単純計算で1/4とみなす。 ルーティングノードの収益はアウトバウンドフローで発生するのでアウトバウンドキャパシティが直接的な収益資源となる。 LNの料金以外のベネフィット 本稿では料金比較だけを行うが実際の決済検討では以下のような料金以外の効用も忘れてはならない。 Bitcoin(L1)に比べると、料金の安さだけでなく、即時確定やトランザクション量のスケールという利点がある。 クレジットカードなどの集権サービスと比較した特徴はBitcoin(L1)とだいたい同じである。 24時間365日利用できる 誰でも自由に使える 信頼する第三者に対する加盟や審査や手数料率などの交渉手続きが要らない 検閲がなく匿名性が高い 逆にデメリットはオンライン前提がゆえの利用の不便さやセキュリティ面の不安さなどが挙げられる。 現在の料金相場 ルーティングノードの料金設定 sinkノードとのチャネルは500 ~ 1000ppmが多い。 routing/sourceノードとのチャネルは0 ~ 100ppmあたりのレンジになる。 リバランスする場合もsin

Multi Path Payment(MPP)で送金する

単発でumbrelから多額（数百万〜sats）の送金したい。しかし、エラーになる or 手数料ぼられる、かといって小分けにインボイスを発行するのも手間がかかる、という場面でCLIツールのlncliから一つのインボイスをMPPで送金するやり方の忘備録です。 MPPの説明はこちら。受金者は一つのインボイスで、送金者(umbrel)は複数のパスが可能になるので、例えば100万を10万×10本に分割して送金が通りやすくかつ手数料が安いルートにヒットしやすくなります。 https://lightning.engineering/posts/2020-05-07-mpp/ やり方 umbrelにログインした後に以下のコマンドを発行します。 docker exec -it lightning_lnd_1 lncli sendpayment \ --pay_req [invoice] \ --max_parts 100 \ --fee_limit 2500 \ --max_shard_size_sat 100000 \ --outgoing_chan_id 816130156246007800 コマンドの解説 4つ目はdockerのコンテナ nameです。v0.5からlndもオプションになったからか以前のlndからlightning_lnd_1に変わってました。1と付いていて怪しいのでコマンドが見つからなくなったらdocker psでnameをチェックするのがよさそうです。 pay_reqオプションにセットする値はインボイスの発行識別子です。lnbcとかで始まるアレ。 max_partsオプションでMPPを有効にします。値には分割する最大数をセットします。 fee_limitオプションは最大料金のsats指定です。これ逃すと手数料が悲しいことになるのでppmから計算して必ずセットしましょう。（1000ppmで0.1%） max_shard_size_satオプションは1本あたりの金額です。ここを指定しないと半分にしただけで送られがちです。

『Mastering the Lightning Network』を日本語訳して製本する（注:個人使用限定）