- Campaign
-
Category
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から受け取ったペイロードが改ざんされて
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
スクリーンショットで見るライトニングノードのリカバリ
仮想マシン上に置いていた umbrel の実験ノードが、仮想マシンごと吹き飛んだので、LNDのリカバリを試してみました。めったにない機会なのでスクショを共有します。 在りし日の実験ノード。吹き飛んでしまったものは仕方ない。リカバリ始めます。 まずはBitcoin Node のインストール。その前にUmbrelのセットアップもあるけど今回は省略。 Lightning Node のインストール。 リカバリの方を選択。 リカバリを選んだら、シークレットワードの入力画面へ。 私の場合、ここで問題が。シークレットワードのメモが複数ある！どれが実験ノードのシークレットワードだったか分からない！幸い一つ目が当たりでしたが、下手すると何度もトライすることになるところでした。シークレットワードの管理、大事ですね。(あたりまえ) Yes！！！！ 同期が終わってからチャンネルリカバリを試してください。OK。 #reckless です。 しばらく待つとオンチェーンのBTCがウォレットに復元されていきます。 来た！ 来た来た！ オンチェーン分の復元完了 Rec
ビットコイナーは一般層へ優しくない？
DH Magazine Proリアペシリーズ ・今回も非常に興味深い内容。以下、問いかけ部分に対するリアクション ・ウェブスリースーツ組に見習って、ビットコイナーも優しくポジティブな印象を与えることが重要なフェーズだと思うか？ →前回の拙著記事のジョーさんにインスパイアされた、ビットコイナー太陽作戦は、主にアルトコイン購入層への優しさ。 よりライトな一般層へのアプローチとしても、優しさ、清潔感、明朗さなどで好印象を与えることは有効だろう。 課題としては、ビットコインへの理解度が高いという前提で上記の条件をクリアしている人材の発掘が難しいということ。当然だが、人材派遣会社や広告代理店に頼んでも無理な話。 マジョリティ受けがいい高潔なエバンジェリスト、大衆の注目を引きつける清廉なインフルエンサー、世界にも通用する若さ漲るオピニオンリーダーが、既存のビットコイナーの中から出て来れば理想的だが厳しい？ 以前の記事にも書いたが、時がくれば、アメリカなど諸外国での盛り上がりに呼応した著名人が自主的にビットコインフレンドリーな発信をするのだろうと思うが、その流れを先行的に作り出す動きこそ、DHコミュニティが志していること 個人的には、案外、これからビットコインに出会う若い世代に期待してもいいかもしれないと、考える。将棋界の藤井聡太くん、ようつべ界のちょんまげ小僧のような、一気に流れを作るムーブメントの中心人物は、いつも若者主導だし、大人が予想出来ないポイントから出現する。 現在の小中高生から、そういった存在が登場すると仮定しよう。彼らからして、おっさんおばさんな我々の世代は、急がば回れで、若年層に種蒔きをする活動こそがビットコイン普及の近道な気がしている。 以前、kojisanに提案した聖地コミュニティでのクリエイティブ活動（子供達が興味を持つ可能性があるコンテンツ作り）、YouTuberやお笑い芸人などへのオレンジピリング企画などは、その辺を意識した時間のかかる長期目線の取り組みだが、初期のコミュニティ活動として悪くはないと思う。（自分は昔から通貨の歴史からビットコインまでの系譜を絵本か漫画にしたいという密かな野望があるが、時間と才能が…） 直近の話なら、聖地を大岡山にして、東工大生オレンジピリング企画やって、理系学生達がビットコイン勉強会やサークル作るのを支援するみたいなのが早いかもしれない。 ビットコインもライトニングも、一般の人々がポジティブな話題にするには、まだまだ長い月日が必要だろう。日本円通貨危機のようなクライシスが無い限り、急激な一般普及は難しいし、UXの進化も追いついていない。 一般層は自身の生活に直接関わるような話題には敏感に反応する。ビットコイン、つまりお金や資産の話は、生活に根ざしたトピックだ。正面から語ることを避けがちな日本人の風習が邪魔しているものの、リアルな生活視点から出発することが、一般層への普及活動の糸口になる気がしている。 個人的に株式投資家コミュニティで、金融庁も絡んだ投資普及啓発を手伝っている。 最近だと、お菓子のシュリンクフレーションを切り口に、インフレーションをどう乗り切るのか？とか。ドル円チャートを見せて、日本円しか持たないリスクを考えてみようか？みたいなテーマで講演会するのだが、会社員、主婦、高齢者、学生など属性問わず、かなりの参加者集まってくる。5年10年単位で見ると確実に参加人数が増え、普及が進んだことを実感する。ちなみにそっちのコミュニティもスーツには頼ってない（笑） ビットコイン&ライトニングコミュニティにもスーツは不要だと思うが、日々の生活に直結する話題作りや、子供達へのアプローチなど、一般層への『優しさ』こそが、マス訴求へのキラーコンテンツだと思うわけです、はい。
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を強
