Avatar
tanakei
78b3c1ed0a53b072fcfb8cc2e2e09cad31c9bfec869d1c8745c343d55033eea9
にゃーん

snortでNWC(nostr-wallet-connect)ができるようなのでalbyとつないでみた。

snortのウォレットから残高が確認できないな。0で見える。実際は0じゃない。

でもzapはできる。

チャネルを開く時に発行するFundingTXのUTXOを

チャネルサイズと表現したり、チャネルキャパシティと表現したりと”ゆれ”があるんだよな。

Mastering LNではチャネルキャパシティで、LNDのコンフィグなんかみるとチャネルサイズって表現したりする。

maxchansizeのパラメタ説明だと"The largest channel size (in satoshis) that we should accept. "

インボイスに含めるdescriptionが639バイトを超過する場合にdesription hash(hタグ)を使うっぽい。

インボイスにハッシュを含めるけどその639バイトを超過する本文をどうやって相手に送るかは定めてない。その意味でzapレシートのdescriptionに載せてるんだろうな。

https://github.com/lightning/bolts/blob/master/11-payment-encoding.md#tagged-fields

こうかな?

・nostrクライアント→ライトニングアドレス(LA)サーバ

zapリクエストを送る。

・LAサーバ→ライトニングノード

1.zapリクエストをハッシュ

2.zapリクエストハッシュをdescription hashとしたインボイスをノードに要求。

・ライトニングノード→LAサーバ

インボイス(description hash はzapリクエストのハッシュ)を渡す。

・LAサーバ→nostrクライアント

インボイス(略)を渡す。

<インボイスが決済される>

・LAサーバ↔ライトニングノード

zapリクエストのハッシュがdescription hashであるインボイス決済を検知。

・LAサーバ→(各リレー)

zapレシートを送信。zapレシートのdescriptionタグに決済されたインボイスのdescrition hashの元になったzapリクエストをのせる。

zapリクエストはデカイためにそのままインボイスに載せられず、hashでインボイス発行要求するんだと思われ。

これで釣れる?

預託 が相当するけどあまりみない。

カストディアルウォレットとカタカナのまま使うことが多いような。

BNPL

Buy now, Pay later (今買って、あとで支払う)

だっけ?

WoSに残高借りて先に支払い、後でデポジットなりしてウォレットに入れるとかできちゃうならそれはクレカ払いっぽくなる。

ライトニング支払いは言うなれば現金払い。

クレカ払いというツケ払いが便利なんよ。

部屋名なにがいいですか?

ビットコイン・ライトニング部でいいの?

nostr相撲部?

nostrにはいろんなチャット部屋があるんだな。

取引が成立したなら担保金の送金はFAILEDになるのが期待される動作。

送金失敗だからお金(BTC)が戻ってくる。

WoSだとQUEUEDになったりもするけど、数時間後にはFAILEDになる。

invoiceのexpiry

インボイス発行時刻+expiry(秒)を越えた後にこのインボイスを使うのはダメ、支払いを受ける側も超過したインボイスにリアクションしちゃダメよってことだった。

だからexpiry内でLN支払い開始したらこのフィールド値は関係ないな。