ついてはなにも検索していません。既存の配信サービスとは全く性質がことなります。これらは双方向のコミュニケーションで、ラジオ、Podcast、standfm系(最近はライブ共同配信?的なのができるようになったらしいが、参加してないので詳細は不明)は、配信者とリスナーという一方通行です(チャットはありますが、音声双方向ではないことが多いです。使ったことないので適当です。自由なコンテンツであるので素晴らしいですが、それ以外のものは所詮サービスなので興味はありません。ないし、限定に興味はありません。限定というだけで価値がないのです。サービスでクローズドですが、私は非常に関心があります。それは、これらが単なるコンテンツではなくて新しい体験(と表現するととてもあやしくてこれ以上読みたくなくなると思いますが、ぜひ読んでください)であり新しいコミュニケーションだからです。なにか話したいときに、かんたんにオンラインで誰とでも話はじめることができるのは最高すぎます。これは突発的で偶発的な雑談という非常に価値が高いコミュニケーションを、オンラインでかんたんに発生させることができるからです。世の中雑談がすべてです。このようなサービスに大事なのは体験の良さだと思います。ストレスなくサービスを使えるかがすべてです。機能は喋れる以外いりません。ログも不要だし、検索もできなくていいです。意識高い(のかは知らないけど)コンテンツをわざわざ聞き直すほど私たちは暇ではないはずです。自分の都合で一瞬オンラインで雑談ができる。それが如何にスムーズにストレスなく行えるかにかかっている。これは情報ソースではないのです。つねに追いかけ続けてキャッチアップしないといけないわけではないのです。したがって、いわゆるネットワーク効果(といっていいのだろうか?)的なものは働きません。誰と話すかではなく、カンタンにはなせることこそが大事なのです。知り合いなんてちょっといればいいのです。知らない全然価値観が違う人と雑談することってありますか?ここではできるんです。投げ銭を受けたい人が、自分のアドレスを公開して投げ銭を受けようとするとプライバシーの問題がある。受け取る側、送る側どちらにもプライバシー上の懸念があります。受け取りは毎回アドレスを変更することが推奨されます。上に自分のアドレスを公開する場合は、投げ銭を受けるたびにアドレスを変更するのは簡単ではありません。オンチェーン技術です。慣習にならいプライバシーを少し向上することができます。いう名前でサービスを提供しています。Todd氏による現状のL2概要についての記事が素晴らしかったので、簡単に紹介します。BreezSDKを使ったライトニング搭載ビットコインウォレットを開発中に、テスターから強制チャネル閉鎖になると報告がいくつかありました。そこでテスターからログをいただき、解析してみた結果、ビットコイン、ライトニング特有な原因であることがわかりました。以下はそのログの原因箇所を抜粋したものです。ライトニングの送金は、送信者と受信者が互いにその取引に署名をします。送信者がコミットメントに対して署名をします。受信者はそれを受け取り、内容に問題がなければ、古いコミットメントを失効させます。この際、受信者は古いコミットメントがオンチェーンへブロードキャストされていないか確認する必要があります。そのためには、まずはビットコインの最新のブロック高まで同期して確認します。ブロック高の同期が未完であれば、相手からのコミットメントを受け取ってもその処理を中断して、ブロック高の同期を待ちます。この状態でアプリを閉じてしまうとどうなるか...送信者はコミットメントに署名をして受信者へ渡した状態で、これは送金が宙に浮いている状態です。この場合ライトニングでは、ある一定期間が経過すると、その中途半端な取引をオンチェーンへ展開して資金を回収するプロトコルになっています。これが所謂、チャネルの強制閉鎖です。ウォレットを開き、支払いを受け取ろうとする。ブロック高の同期が完了していない場合、その取引は中途半端になる。その状態でアプリを閉じることで、一定期間経過後にチャネルが閉鎖されてしまう。これがテスターから報告のあったチャネル強制閉鎖の原因でした。対応策は、ブロック同期が完了するまでインボイスの生成や受け取りができないようにすれば良いはずです。LNにはPinning攻撃と呼ばれる攻撃手法があり、現在この攻撃を防ぐことはできないとされている。この攻撃の実行可能性はそれほど高くないとされており、またこの対策・緩和策にはビットコインのベースレイヤーの変更が必要なため、それほど急務といった感じではない。本攻撃の仕組みや対策を知っておくことに越したことはないので、以下にその概要をまとめた。LNで使用されるトランザクションには以下の5種類がある。このうち今回重要になるのが、CommitmentトランザクションとHTLCトランザクションである。LNは1つのUTXOを2者間で共有し、両者の合意に基づき互いの残高を更新していく。更新ごとに作成するトランザクションをCommitmentトランザクションと呼ぶ。これは2者間の残高状態と送金の中継に使うHTLCを管理するもので、どちらか一方の通信が途絶えた場合でも、一方的に資金をオンチェーンで回収できるような構成になっている。このCommitmentトランザクションはFundingトランザクションをインプットに持つ。HTLCトランザクションは、Commitmentトランザクションをインプットに持つトランザクションである。これは、送金の中継に使われるHTLCがタイムアウトした場合、オンチェーンでその資金を回収するために必要となるトランザクションである。HTLCの送信者はHTLC-timeoutトランザクションを、受信者はHTLC-successトランザクションを保有する。Commitmentトランザクションのアウトプットは、以下の6種類がある。Offered_htlcとReceived_htlcは以下の方法で資金回収ができる。completed!Close。