RGB-Channel in Lightning

ライトニングネットワークはビットコインをオフチェーン上で送金する仕組みである。そのネットワークを構成するペイメントチャネルは2者間のビットコイン残高の状態を管理している。このチャネルの状態にビットコイン残高以外の特性を持たせようとする取り組みがいくつかある。 RGB-Channel in Lightning ビットコイン以外のトークン残高を管理できるようにするチャネル Lightning Network compatibility - RGB Docs DLC-Channel in Lightning 残高はビットコインのままだが、残高状態を更新するために必要な二者間の署名以外にオラクルの署名も有効とするチャネル DLC on Lightning. TLDR; | by Thibaut Le Guilly | Crypto Garage | Medium 今回はRGBチャネルに焦点を当ててその実用性を考察してみる。 RGBチャネルのプロコン RGBチャネルの場合、チャネル開設者がアセットを持ってさえいればよい。これはRGBチャネルのメリットである。なぜなら、RGBのオンチェーン送金では受け取り側もUTXOを事前に用意する必要があるから。RGBチャネルを開設さえすれば、受け取り側はLN上で0承認かつ低手数料で何度も送受信が可能で、アセットをオンチェーンへ引き出す際はチャネルを閉じるだけでよい。 現状のRGBチャネルは1チャネル1アセットなので、複数アセットを扱う場合、それぞれのチャネルを開設する必要がある。そのため、受け取りたいアセットのチャネルがない場合は受け取ることができない。RGBチャネルが普及する場合、特定のアセット、例えばUSDTなどのチャネルに限定的になる可能性が高い。 チャネル間を通してアセットを送金する方法は、分散ネットワーク型、ハブ＆スポーク型、ゲートウェイ型の3通りある。RGBチャネルが普及する場合、特定のアセットに限定的になる可能性が高いので、その場合は分散ネットワーク型になる可能性もあるが、取引所やLSPなどがゲートウェイとしてRGBチャネルを運用する未来像の方がイメージしやすい。 ライトニングネットワークでビットコインを送金する場合でも送金手数料（ルーティング手数料）がかかり、それはBTC建てである。HTLCがオンチェーンで解決される場合も考慮すると、そのためのBTCの最小送金金額（詳細はこちらの記事を参照）も必要になってくる。RGBチャネルでアセットを送金する場合も基本的にはBTC建てで送金手数料がかかり、アセットをオンチェーンで決済できるようにするためのHTLCも必要になる。ユーザーはアセットとBTCの2種類を保有する必要があるので、使い勝手が良くない。このユーザー体験を改善する方法の1つにゲートウェイに送金手数料およびHTLCをアセット建てで支払う方法がある。 まとめ RGBチャネルを使うことで受信者はUTXOを事前に用意する必要がなくなるメリットがある一方、複数アセットを管理する場合、複数のRGBチャネルを持つ必要がある。そのため、受信者が持っていないアセットを受け取る場合、新規にチャネルを開設する必要がでてくる。RGBチャネルでアセットを送金する場合、それに係る送金手数料やHTLCのためにBTCが必要になる。そこでゲートウェイがアセットとBTCの交換サービスを提供することでユーザー体験を向上できると期待されている。

GPUtopiaで余剰GPUリソースをSatsに

LightningNetwork周りのサービスを探していたら面白いものを見つけたので共有です。 ETHがPoS移行してからというもの、GPUリソースを余らせているマイニング勢もいるかと思われます。 その余ったGPUリソースを売るという興味深いサービスを発見。 ブラウザ経由でWebGPUを使用し、GPUリソースを貸し出すことができます。 こんな感じ。 しばらく稼働させてみると、GTX1070で1000Sats/hに届くか届かないかくらいの収益かな。もしかするとマイニングより稼げるかもしれない！ と、喜んでいたところ…… <iframe style="position: static; visibility: visible; width: 530px; height: 671px; display: block; flex-grow: 1;" id="twitter-widget-1" scrolling="no" frameborder="0" allowtransparency="true" allowfullscreen="allowfullscreen" class="" title="Twitter Tweet" src="https://platform.twitter.com/embed/Tweet.html?dnt=true&embedId=twitter-widget-1&features=eyJ0ZndfdGltZWxpbmVfbGlzdCI6eyJidWNrZXQiOltdLCJ2ZXJzaW9uIjpudWxsfSwidGZ3X2ZvbGxvd2VyX2NvdW50X3N1bnNldCI6eyJidWNrZXQiOnRydWUsInZlcnNpb24iOm51bGx9LCJ0ZndfdHdlZXRfZWRpdF9iYWNrZW5kIjp7ImJ1Y2tldCI6Im9uIiwidmVyc2lvbiI6bnVsbH0sInRmd19yZWZzcmNfc2Vzc2lvbiI6eyJidWNrZXQiOiJvbiIsInZlcnNpb24iOm51bGx9LCJ0ZndfZm9zbnJfc29mdF9pbnRlcnZlbnRpb25zX2VuYWJsZWQiOnsiYnVja2V0Ijoib24iLCJ2ZXJzaW9uIjpudWxsfSwidGZ3X21peGVkX21lZGlhXzE1ODk3Ijp7ImJ1Y2tldCI6InRyZWF0bWVudCIsInZlcnNpb24iOm51bGx9LCJ0ZndfZXhwZXJpbWVudHNfY29va2llX2V4cGlyYXRpb24iOnsiYnVja2V0IjoxMjA5NjAwLCJ2ZXJzaW9uIjpudWxsfSwidGZ3X3Nob3dfYmlyZHdhdGNoX3Bpdm90c19lbmFibGVkIjp7ImJ1Y2tldCI6Im9uIiwidmVyc2lvbiI6bnVsbH0sInRmd19kdXBsaWNhdGVfc2NyaWJlc190b19zZXR0aW5ncyI6eyJidWNrZXQiOiJvbiIsInZlcnNpb24iOm51bGx9LCJ0ZndfdXNlX3Byb2ZpbGVfaW1hZ2Vfc2hhcGVfZW5hYmxl

SphinxプロトコルにHMACを追加する理由はリプレイ攻撃対策

ライトニングネットワーク上の送金はプライバシー向上のためにオニオンルーティングが使われている。そのプロトコルとしてSphinxプロトコルをベースとしているが、そこにHMACがなぜ追加されているのか、以下のLNメーリスに回答があったので、その備忘録。 [Lightning-dev] Reason for having HMACs in Sphinx (linuxfoundation.org) オニオンルーティングのペイロードのラップ、アウンラップについては以下のサイトが参考になるので、それをもとに以下、詳細を割愛しながら説明する。 lnbook/10_onion_routing.asciidoc at develop · lnbook/lnbook (github.com) オニオンペイロードのラップ・アンラップ オニオンペイロードは送信者によって構成される。このペイロードは1300バイトの固定長である。例えば、A→B→C→Dという経路で送信する場合、AはまずDへの情報をセットし、残りのスペースを1300バイトになるまでフィラーで埋め、Dとの共有鍵から生成したrho鍵でXORしてペイロードを暗号化（難読化）する（1）。次にCへの情報をセットし、暗号化したデータ（1）を追加する。この時、1300バイトを超過したデータは切り捨て、Cとの共有鍵から生成したrho鍵で全体を暗号化する（2）。次にBへの情報をセットし、暗号化したデータ（2）を追加する。この時も1300バイトを超過したデータは切り捨てて全体を暗号化する（3）。こうして入れ子になったデータをオニオンペイロードと呼ぶ。 Ａはこのオニオンペイロードの先頭にBとのセッションキー（※1）をセットしてBへ送信する。Bはオニオンペイロードに1300バイトのゼロ埋めされたフィラーを追加して、共有鍵を使い2600バイトのペイロードを復号して（先頭1300バイトが復号され、残りの1300バイトは難読化される）、自身のペイロードを切り取る。残ったペイロードを左へシフトして、1300バイトを超過するデータを切り捨てる。Bはこのオニオンペイロードの先頭にCのためのセッションキーをセットしてCへ送信する。Cも同様にペイメントの先頭に1300バイトのフィラーを追加してから共有鍵を使いペイロードを復号して自身のペイロードを切り取る。残ったペイロードを左へシフトして、1300バイトを超過するデータを切り捨てる。Cはこのオニオンペイロードの先頭にDのためのセッションキーをセットしてDへ送信する。Dも同様な処理を行い、自身のペイロードからこの送金は自身のものだと分かる。 ※1 セッションキーを使うことで、送信者の公開鍵を公開することなく中継者とECDHによる鍵共有が可能となる。各ホップごとのセッションキーは以下のように生成できる。送信者はオニオンペイロードを作る際、すべての鍵を事前に計算できる。また、中継者は次の中継者のための鍵生成を行う。 session_key_i = session_key_{i-1} * SHA-256(node_pubkey_{i-1} || shared_secret_{i-1}) リプレイ攻撃 送金の中継者が悪意ある行動をとるとする。まずn=1をセットして（n+1）番目のペイロードをビット反転して送信する。次のノードが最終受信者だとすればエラーは返ってこない。なぜなら、ビット反転した箇所はフィラーで埋めされた箇所だから。もしエラーが返ってきたら、nを1増加させて（n+1）番目のペイロードをビット反転して送信する。これをエラーが返ってこないところまで繰り返すことで、自分が最終受信者から何番目に位置するのかを知ることができる。 Bが悪意ある行動をとるとする。Aから受け取ったオニオンペイロードを復号してCへ送信するペイロードを作る。この時、2番目のペイロード、すなわちDへのペイロードをビット反転しておく。Cは自身のペイロードは復元できるので、そのままDへのペイロードを作り送信する。Dはそのペイロードを復元するがビット反転されているので不正なデータだと分かり、Cへエラーを返す。CはそれをBへ返す。これでBはCが最終受信者ではないと分かる。次に、nを1増加させて3番目のペイロード、すなわちフィラーで埋められている箇所をビット反転する。このペイロードはCもDも読み取らない箇所なのでDまで問題なく送信される。よってBは最終受信者から2番目に位置すると知ることができる。 リプレイ攻撃対策1: HMAC オニオンペイロードの改ざんを防ぐために、各ペイロードを暗号化したあとにHMACを付与する。上記の例だと、Bから受け取ったペイロードが改ざんされて

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の相対時間も経過する必要がある（※１）。言い換えると、HTLCの有効期限が切れたのに、この相対時間分の猶予がボブに与えられることになる。これがアリスに与える影響は、アリスが受け取った上流からのHTLCをキャンセルできなくなる、また、この時間分の遅延が上流へ及ぶことになる。 そこで、このCLTVとCTVによる時間枠を1つのHTLCに含めるのではなく、HTLC-Timeoutトランザクションという2つ目のトランザクションを作り、このトランザクションの中にアリスへのto_self_delayを入れることで、HTLCの執行猶予を無くすことができる。 ※１to_self_delayは古いコミットメントをブロードキャストした場合に相手側がrevocation keyを使い資金の没収ができるようにするための期間を設けるために必要。 次にボブのコミットメントであるReceived HTLCについて。このHTLCのアウトプットの使用条件は以下の3つ ボブがプリイメジを使う CLTVによる絶対時間の経過後にアリスが自身の署名を使う アリスがrevocation keyを使う（ボブが古いコミットメントを送信した場合） ボブがプリイメジを使う場合、今度は自身のコミットメントトランザクションなので、to_self_delayが必要になる。ここでボブがto_self_delay時間待つことになるが、この時間がcltv_expiryよりも長い可能性がある。そうなるとボブはプリイメジを知っているのに、CLTVの時間が経過後にアリスによって資金を回収されてしまう。 そこで、HTLC-Successトランザクションという2つ目のトランザクションを作り、このトランザクションのアウトプットにボブへのto_self_delayを入れる。こうすることで、cltv_expiryの有効期限が切れる前にプリイメジを使ったHTLC-Successトランザクションをブロードキャストさせる。その後、ボブへのto_self_delayを強

Eltoo: SIGHASH_ANYPREVOUTによるバインディング技術

Eltooはペイメントチャネルの残高更新の仕組みを簡素化する仕組みです。現状のライトニングネットワークに使われているペイメントチャネルはペナルティ型で、一方が不正をすると他方が全額没収することができる仕組みになっています。ペナルティ型のペイメントチャネルは、残高が更新される度にその更新に使われた鍵情報（revocation key）を保存する必要があり、データ容量を圧迫してしまいす。Eltooでは最新の残高に関するデータのみ保存するだけでよくなります。 Eltooの実現にはBIP118のSIGHASH_ANYPREVOUTと呼ばれる新しいSIGHASHタイプが必須で、ソフトフォークが必要です。Eltooの俯瞰図は以下が詳しいです（eltoo with Anyprevout and Taprootより抜粋）。またこちらの記事も日本語で詳しく解説されています。 Eltooでは、チャネルのライフサイクルを3つに分けて考えます。 セットアップ：funding_txとupdate_txを作る ネゴシエーション：update_txとsettelment_txを作る セトルメント：協調的な場合はclose_txを作り、非協調的な場合はupdate_txとsettlement_txをブロードキャストする ネゴシエーションは送金をする度に実行されます。ここで重要なのはupdate_txが消費できるtxは複数あることです。上図のUpdate:3を見ると、そのtxが消費できるtxはFunding:0、Update:1，Update:2の3つあることが分かります。現状ではtxに署名をする場合、そのtxが消費するtxをインプットとして指定する必要があります。しかしSIGHASH_ANYPREVOUTではインプットを指定することなく署名できるようになるので、どのtxに対しても有効な署名済みtxになります。そのため、もし相手がSettle:1の残高でセトルメントを実行しようと思いUpdate:1をブロードキャストしたとしても、最新の残高であるUpdate:3とそのセトルメントであるSettle:3をブロードキャストすることで不正を防ぐことができます。

ペイメントチャネルのサイズ変更をするスプライシング（Splicing）

Splicingはペイメントチャネルのサイズを変更するための仕組みです。サイズを小さくする場合はSplicing-out、大きくする場合はSplicing-inと呼んだりします。現状のLNでチャネルのサイズを変更するには、一度チャネルを閉じて開き直す必要があり、これには2つのトランザクションが必要になります。Splicingを使うことでこのトランザクションを1つに纏めることができます。さらに、というよりこれが要点ですが、Splicingでチャネルサイズを変更している間（この新しいチャネルが未承認の場合）でも、既存のチャネルでルーティングを継続することができます。 既存のチャネル（これは閉鎖中のチャネルとも呼べる）と開設中のチャネルが共存するなか、どうやってルーティングをしているかというと、既存のチャネルのコミットメントにHTLCが追加・削除される場合、開設中のチャネルにも同じ金額のHTLCを追加・削除します。このHTLCは両コミットメントに共存していますが（コミットメントはオフライン上のデータであることに注意）、HTLCがオンチェーンに展開される場合、最終的にブロックチェーンに刻まれるのはどちらか一方なので、チャネル間の残高の整合性は担保されます。 Splicingの仕様は以下リンクに詳しいです。 Splice draft (feature 62/63) by rustyrussell · Pull Request #863 · lightning/bolts (github.com) Alternative splicing specification proposal with detailed examples (github.com) また、Splicingではinteractive-txと呼ばれる新しい仕様も必要になり、その仕様は以下のリンクに詳しいです。 interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) by niftynei · Pull Request #851 · lightning/bolts (github.com) interactive-txは、チャネル開設時にOpenerだけでなくAccepterにもfunding_txのためのインプットを追加できるようにするもので、より柔軟にfunding_txを構成することが可能になります。もともとinteractive-txはdual-fundingのための仕様として策定が進められていましたがSplicingでもこの仕様を活用することになったみたいです。

umbrel の引っ越し、チャネルは開いたままで。

実験ノードの umbrel を別PC(TrueNAS SCALE に作った仮想環境)に移動したので、その忘備録。もちろん開いているチャネルはそのまま引っ越しです。 引っ越しの手順は、 1.新ノードにumbrelをインストール2.新ノードにBitcoin Nodeをインストール3.旧ノードから新ノードへブロックとチェーンステートをコピー4.新ノードに Lightning Node (LND) をインストール5.旧ノードから新ノードへ Lightning Node (LND) のデータをコピー 以下のサイトを参考にさせていただきました。というか、ほぼ以下の内容そのままです。 1.新ノードにumbrelをインストール umbrelをインストールするまでの手順はあちこちにあるので省略します。 ubuntu-22.04.3-live-server-amd64.iso 辺りをダウンロードしてUSBメモリに書き込む USBメモリから起動してubuntu server をインストール sshでログインして curl -L https://umbrel.sh | bash カブトコインさんのインストール編がいちばんまとまってるかな。 2.新ノードにBitcoin Nodeをインストール umbrel の App Store から Bitcoin Node アプリをインストールします。 3.旧ノードから新ノードへブロックとチェーンステートをコピー Bitcoin Node アプリで同期が始まり、同期割合が0.01%を超えたら、一旦新ノードのumbrelをストップします。 新ノード： sudo /path/to/umbrel/scripts/stop この後で詳しく書きますが、新ノードのログイン名がhugaの場合、 s

NP困難とライトニングネットワークの手数料関数が及ぼす計算量

以下のスレッドを読んでの備忘録。 https://bitcointalk.org/index.php?topic=5437244.0 ライトニングネットワーク（LN）での経路選択は、巡回セールスマン問題としても知られている。巡回セールスマン問題で、すべての都市を通る経路の計算をする場合、計算量はΘ(N!)なので指数関数時間となる。 そこで、LNではダイクストラ法※などの動的計画法を用いて比較的効率的に最適な経路を選択するような実装がされている。しかし、最適な経路選択するうえでも以下のような問題が指摘されている。（※計算量はΘ(E + V*log(V)) 、Eはチャネル数、Vはノード数） LNでは手数料の合計値が最小であるような経路選択が望ましい。手数料関数をf(x) = rx + b、rは手数料率（fee rate）、bは基本手数料（base fee）とする。この関数は、b = 0でない限り、線形代数的には線形ではない。線形性を有するには、 f(x+y)=a(x+y)+b=ax+ay+b=(ax+b)+(ay+b)=f(x)+f(y) を満たす必要があるが、手数料関数においてはb = 0 の場合のみである。線形性を持つ問題は数学的に解きやすいが、手数料関数にはこの性質がないため（基本手数料であるbをなくせばよい）、経路選択という最適化問題を解くことが難しくなる。 スレッド内で質問されていた手数料関数がどのくらい計算量に影響を与えるかの具体的な数値の回答はなかった。もしかしたらこちらの論文に記載されているのかもしれないがしっかりと読めていない。 余談上記の手数料関数で、f(0) = 0 だが δ→ 0 なので f(δ) → bであり、これは x = 0 において連続で、そこで 0 から b へとジャンプする不連続性を持つ。これは凸性を失うので（凸性も最適化問題を解くのに重要な性質）、手数料関数の最適解を解くのが難しいと言われる。この 0 から b へジャンプするというのもイマイチ理解できていない…

初心者向けビットコイン購入方法その２（JPYC→BTC）

初心者向けビットコイン購入方法その１（JPYC購入まで）

I HATE WORLDCOIN

競争通貨・人口問題・政治哲学に関する議論