Purchased this article lly0arc5w
teatwo
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本あたりの金額です。ここを指定しないと半分にしただけで送られがちです。
Elements/Liquidでコベナンツを作ってみた
ElementsとはLiquidなどのサイドチェーンを運用するためのソフトウェアです。Bitcoinを拡張した実装となっています。 Elementsに追加された新OPコード Elementsでは以前からビットコインにはないOPコードがいくつかあります。OP_CATとOP_CHECKSIGFROMSTACKを使うことでコベナンツを実現できますが、この方法は計算コストがかかるというデメリットがあります。そこでインプットやアウトプットを直接調べるためのOPコードが追加されました(詳細はこちら)。これらのOPコードはSegwit V1(別名P2TRアドレス)として使うことができます。例えば、OP_INSPECTOUTPUTVALUEはアウトプットの金額を参照することができ、以下のようなスクリプトを構成することで送金金額を制限できます。こちらのツールを使うことで、スクリプトの実行経過を確認することができます。 //インデックス0のアウトプットの金額を取得 OP0 OPINSPECTOUTPUTVALUE OP1 OPEQUALVERIFY //1000のリトルエンディアンを指定 <0xe8
LDP Seminar Week 1の備忘録
Chaincode labsが開催しているLDPというオンラインセミナーに参加しているので、そのWeek 1の復習を兼ねての備忘録。 Week 1はライトニングの基本的なプロトコルに関する内容で、事前に参加者には宿題が与えられるので当日までに解いておく。そして、当日その問題をグループ内でディスカッションする形式となっている。その中から一部抜粋してその問題を以下に記載する。 ・・・ 問題1 Why do we need the HTLC-Success and HTLC-Timeout transactions? Why can't we just use a sequence delay on the to_local output conditions of the HTLC itself? 回答 アリスからボブへの送金において考える。まずはアリスのコミットメントであるOffered HTLCについて。このHTLCのアウトプットの使用条件は以下の3つ ボブがプリイメジを使う CLTVによる絶対時間の経過後にアリスが自身の署名を使う ボブがrevocation keyを使う(アリスが古いコミットメントを送信した場合) ただし、CLTV経過後、アリス自身が使用する場合にはto_self_delayの相対時間も経過する必要がある(※1)。言い換えると、HTLCの有効期限が切れたのに
ご冥福をお祈りしません②
2023年(令和5年)7月12日、タレントのりゅうちぇるさんが亡くなったという報道がありました。自殺のようです。 この事実を知った時、私がまず思ったのは、「お前もか!」という驚き。 そして次に、「お前がそれやっちゃダメだろ!」という、落胆と腹立たしさが入り混じった、なんとも残念な気持ちになりました。 「誰もがありのままでいい」というメッセージを発信してきた人が、自ら命を絶ってしまった。 そこに、責任放棄のようなものを感じてしまったのは、私だけではないのではないでしょうか。 我ながら、年を取ったと感じますが、若者の自殺はこたえる。 死ぬことはないんだよ。 つらいなら、逃げたって隠れたっていい。 生きていればいいことあるんだから。 逃げたいなら、地の果てまでだって、逃げればいいじゃないか。 あらためて、冥福なんか祈らないぞ。 生きて幸福になるべきなのに。 あの世で幸せになんかなられてたまるか。 三年前にも、同じようなテーマで記事を書きました。 あなたはどう思いますか? 最後まで読んでくださって、ありがとうございました!
SLP488 FUTURE VISIONS OF LIGHTNING, GREENLIGHT & BREEZ SDK【Stephan Livera Podcast】2/2
SLP488 FUTURE VISIONS OF LIGHTNING, GREENLIGHT & BREEZ SDK【Stephan Livera Podcast】1/2
そういえば 51% 攻撃
つぶやき。ぽえむ。 そういえばモナコインの 51% 攻撃リスクって、どうなったの? という声が降ってきた気がするので。 経緯のまとめとして、(いつも詳しい)はぴるん氏の記事を読んでおくと話が判りやすいかもしれない。 この辺りから読むとショートカットになるかも。 古典的な 51 % 攻撃リスクは (NiceHash などでハッシュパワーを時間貸ししている潜在的なマイナーを含む) マイナーのハッシュパワーに大きく依存する。 上記リンク先の通りの歴史的な経緯により、攻撃に使える余剰ハッシュパワーは NiceHash から消え、事実上、モナコインのチェーンで力ずくの 51% 攻撃は困難な状況にある。 どれだけ困難なのかを定量的に示してくれるサイトがあり、参考になる。 https://www.crypto51.app/ 本稿執筆時点では、Litecoin や EthereumClassic より困難な状態。Bitcoin 並に困難なのだが…
チャネルの強制閉鎖 (Force Closure)はなぜ起きるのか?
ペイメントチャネルの二者間がオンラインでいるにもかかわらず強制閉鎖される場合があります。自分のノードだけがこの問題に悩まされているのかなと思いましたが、以下のツイートを見る限り強制閉鎖は頻繁に起きているのが現状のようです。 強制閉鎖される主な理由はHTLCのタイムアウトによるものです。なのでこのタイムアウト時間を長くすることである程度緩和できるかもしれません。以下のリンクのようにLNDはデフォルトのHTLCタイムアウト値(CLTV)が40から80ブロックへ変更されました。 タイムアウト値を長くすることで強制閉鎖を緩和できるかもしれませんが、上記のツイートにあるようにソフトウェアのバグや複数の条件が重なることで起きており、根本原因の究明は難しそうです。 ・・・</p
Purchased this article byib9o2nm