かんな
Bitcoin. 頭に浮かんだことを大体そのまま書くので雑です。なるべく読みやすいようにはがんばります。フィードバックお待ちしています。
ProtonMail から Hey に、ProtonVPN から Mullvad に移行したお話
数年間使っていた ProtonMail をやめて Hey に移行し、ProtonVPN をやめて Mullvad VPN に移行しました。理由は、ProtonMail と ProtonVPN が使いにくかったからです。 # ProtonMail から Hey へ Gmail から ProtonMail へ移行して数年が経っていました。ProtonMail を使っていた理由は、Google にメールの内容を読まれることがないからです。特に深い理由はありません。 私がメールクライアントでもっともよく使う機能はアーカイブです。受信トレイはきれいだと嬉しいタイプです。でもきれい至上主義者ではありません。ニュースレター系は RSS リーダーに飛ばしているので、メーラーで読むことは基本的にありません。プライベートでメールを誰かに送るという行為はほぼなく、企業やサービスへの問い合わせくらいなので、使わない機能です。モバイルアプリはよく使います。モバイルで見て、すぐアーカイブすることが多いです。メールなんてほぼゴミです。 ## ProtonMail への不満 ProtonMail の iOS アプリはアーカイブが致命的に行いづらいです。ワンタップでアーカイブすることができません。仮に設定でワンタップでアーカイブするようにできたとしても、このあと述べる Hey と比較すればどうでもよいことです。少しでもメールが溜まると、この作業がとても面倒になっていました。なので PC で複数選択してまとめてアーカイブしていました。 アーカイブしないという選択肢もあると思います。でもアーカイブしたいです。なぜなら、ほぼゴミのメールの中に、たまに、でもちょくちょく、大事なメールやあとでじっくり確認したいメールなどが紛れるので、Inbox はそういったメールが一時的に滞留する場所にしたいのです。その他はアーカイブして目に止まらないようにしたいのです。 PC でやればよいという考え方もできますが、アーカイブというタスクのためだけに、PC ブラウザでクライアントを開いて作業するというのは意味が不明です。アーカイブという本質的に意味のない作業になぜわざわざ環境と時間を制約されないといけないのでしょうか。 ## Hey のなにがいいか 移行先を探していました。最初はプライバシー重視してます系を中心に探していたのですが、ふと Hey がいいのではないかと思いました。年間 99 ドルの価値があるのかを判断するために、トライアルをはじめてみました。移行することはすぐに決まりました。 Hey には
自由を届ける
雑談シリーズです。Audrey Tang さんへのインタビューを書籍化した「自由への手紙」を読みました。なぜか最近良く本屋さんで見かける Audrey さんですね。Rebuild の ep271 はとてもよかったのでぜひ。 https://rebuild.fm/271/ この本では様々なことから「自由」になるための、Audrey さんの考え方を語られています。「自由」は私にとっては重要なキーワードなので読んでみたというわけです。結局これも夜読み始めて、良すぎて、そしてさくっと読めてしまう量なので一気に読んでしまいました。Audrey さんの考え方に触れるのは今回がほぼ初めてだったのですが、Audrey さんの考え方には、たぶん基本的には大筋だいたい合意できるタイプの方だなと思いました。ちなみに Netflix の No Rules を読んだときも、コンセプトはだいたい合意できると感じました。でも Netflix はそれを企業として実践し続けていることがすごいなと思いました。 先程も述べたように、この本では、「格差から自由になる」、「デフォルトから自由になる」というように、さまざまなテーマで自由ことを目指しています。読めばわかるのですが、自由、の他に、Open、透明性、というキーワードがいくどとなくでてきますし、言外にそれを示唆する文がちりばめられています。自由を実現するには、Open さと透明性が必要であるということです。 台湾でマスクを全国民が購入することでがきるようにするために、決済手段を決める意思決定をしたときの考え方がのっています。導入が簡単なモバイル決済ではなくて、より多くの人が利用することができる国民健康保険証を利用することを選んだといいます。それはこのような理由からです。 > セーフティーネットとは、すべての人のためのものなのですから これは Open です。Open でなければ、セーフティーネットには絶対になりえないのです。ちなみに台湾では、半年滞在すると国民健康保険証をもつことができるようです。すごいな...。でも Open という考え方を敷いていれば、当然のことなのです。 Audrey さんはこのようにいいます。 > 私は常に、「透明性」が重要になると考え、そう発言しています。 これは主に国家の透明性についてのべているようです。国民は国家のすべてを知ることができ、国家が国民のことを知るには国民の許可が必要。これは"民主主義"と呼ばれる仕組みを機能させるためには絶対に必要なことです。ので、いまは民主主義が世界のどこでも機能していません。これは民主主義がだめということではありません。よく民主主義はだめだ、的な意見も聞きますが、だめな
オルタナティブってかっこいい
なんでも好きなこと書いちゃうね researchat.fm で東浩紀さんの「ゲンロン戦記」が激推しされていたので積読していた。昨晩寝る前に開いてしまったのだが、寝る前に読んでいい本ではなく、そのまま夜通し読破したのであった。それについて頭に浮かんだことを、またここに書き下す。("書き下す"の使い方あっているのだろうか？頭にあることをそのまま文字に起こした、ぐらいの意味で使っているのだが...) この本は東さんがゲンロンの運営者(大体の期間を経営者)として振り返り、主にその失敗と成功の一部を書籍にしたものらしい。私は東さんの熱心な読者ではない。たまにテレビを含む動画媒体で見かけたり、書籍は何冊か一応読んだことがあるかも、という程度である。でもこの本はとても良かった。泣けて、熱くて、かっこよかった。 # 雑談の大切さ 先日こちらの記事でも、雑談こそがすべてということを書いたが、本書でも「誤配」のエピソードが数多く紹介されている。東さん自身も > そのような事故＝誤配こそがイノベーションやクリエーションの源だと思うのです。 とおっしゃっていて、それこそがゲンロン/ゲンロンカフェの価値なのだなと実感しました。哲学の難しい話をしている場所、という認識で、行ったことも見たこともなかったが、このような空間が増えるといいなと思った。 脱線するが、この観点から Dabel と clubhouse を比較すると私が求めているのは Dabel である。名前の話です。サービスの内容は無視しています(ただし clubhouse の UI はわりといい笑)。必要なのはコミ
オンラインおしゃべりサービスはいったいなんのために生まれたのか
最近 clubhouse が話題らしいので私の考えをたれ流します。雑に書き下しています。情報に正確性はありません。妄想です。 - 音声SNS と呼ばれるサービスのなにが新しいのか- 私はオンラインでのおしゃべり体験になにを求めるか 私は clubhouse にはまだ入れていません。clubhouse についてはなにも検索していません。clubhouse に関する知識は、RSS に流れてきた記事と Dabel での会話だけです。 Dabel/clubhouse は既存の配信サービスとは全く性質がことなります。これらは双方向のコミュニケーションで、ラジオ、Podcast、standfm系(最近はライブ共同配信？的なのができるようになったらしいが、参加してないので詳細は不明)は、配信者とリスナーという一方通行です(チャットはありますが、音声双方向ではないことが多いです。たぶん。使ったことないので適当です。)Podcast は自由なコンテンツであるので素晴らしいですが、それ以外のものは所詮サービスなので興味はありません。最近 Apple や Spotify 限定配信 Podcast とかあるようですが、それはもはや Podcast ではありません。限定は Podcast ではないし、限定に興味はありません。限定というだけで価値がないのです。 しかし、Dabel や clubhouse はサービスでクローズドですが、私は非常に関心があります。それは、これらが単なるコンテンツではなくて新しい体験(と表現するととてもあやしくてこれ以上読みたくなくなると思いますが、ぜひ読んでください)であり新しいコミュニケーションだからです。 なにか話したいときに、かんたんにオンラインで誰とでも話はじめることができるのは最高すぎます。これは突発的で偶発的な雑談という非常に価値が高いコミュニケーションを、オンラインでかんたんに発生させることができるからです。世の中雑談がすべてです。 このようなサービスに大事なのは体験の良さだと思います。ストレスなくサービスを使えるかがすべてです。機能は喋れる以外いりません。ログも不要だし、検索もできなくていいです。できてもいいけど。意識高い(のかは知らないけど)コンテンツをわざわざ聞き直すほど私たちは暇ではないはずです。自分の都合で一瞬オンラインで雑談ができる。それが如何にスムーズにストレスなく行えるかにかかっている。これは情報ソースではないのです。つねに追いかけ続けてキャッチアップしないといけないわけではないのです。したがって、いわゆるネットワーク効果(といっていいのだろうか？)的なものは働きません。誰と話すかではなく、カンタンにはなせることこそが大事なのです。むしろ知り合いなんてちょっといればいいのです。知らない全然価値観が違う人と雑談することってありますか？ここではできるんです。知らんけ
投げ銭を受ける人のプライバシーを少し改善する方法
Spotlight で投げ銭のプライバシーに関する記事を読んだので、少しだけそれを改善できる Payment Code という BIP について紹介します。 投げ銭のプライバシー問題 投げ銭を受けたい人が、自分のアドレスを公開して投げ銭を受けようとするとプライバシーの問題がある。 世界中の誰でも、そのアドレスが受け取った金額が簡単に確認できる 世界中の誰でも、そのアドレスに対して送金したアドレスが簡単に確認できる 受け取る側、送る側どちらにもプライバシー上の懸念があります。このような懸念があるため、すべての Bitcoin の受け取りは毎回アドレスを変更することが推奨されます。しかし、投げ銭を受けるためにSNS など Web 上に自分のアドレスを公開する場合は、投げ銭を受けるたびにアドレスを変更するのは簡単ではありません。 Payment Code が実現すること そこで BIP47 の Payment Code が使えます。オンチェーン技術です。 アドレスを直接公開せずに、Payment Code と呼ばれる識別子を公開する 送信者は Payment Code に対して送金することで、裏側では毎回別のアドレスに送金することができる これにより１つの Payment Code を公開するだけで、毎回受け取りアドレスを変更するという Bitcoin の慣習にならいプライバシーを少し向上することができます。 ただし、対応している Wallet を使う必要があり、メジャーなものの中では、私が知る限り Samourai Wallet しかありません。PayNym という名前でサービスを提供しています。無料です。 ではどのような仕組みか簡単に説明すると... (私の scrapbox メモ)
L2のデザインパターン
Bitcoinコントリビュータとしてビットコイン開発を推進してきたうちの1人であるPeter Todd氏による現状のL2概要についての記事が素晴らしかったので、簡単に紹介します。 https://petertodd.org/2024/covenant-dependent-layer-2-review --- L2のデザインパターンには大きく分けて２種類ある
Greenlightとチャネルの強制閉鎖
Greenlight, BreezSDKを使ったライトニング搭載ビットコインウォレットを開発中に、テスターから強制チャネル閉鎖になると報告がいくつかありました。そこでテスターからログをいただき、解析してみた結果、ビットコイン、ライトニング特有な原因であることがわかりました。以下はそのログの原因箇所を抜粋したものです。 19:08:57 : DEBUG 02c...70d-channeld-chan#1: Received commit_sig with 0 htlc sigs 19:08:59 : DEBUG 02c...70d-channeld-chan#1: sending_revoke_and_ack: HTLC REMOTE 15 = SENT_ADD_REVOCATION/RCVD_ADD_REVOCATION 19:08:59 : DEBUG 02c...70d-channeld-chan#1: revoke_and_ack made pending: commit timer 19:08:59 : DEBUG 02c...70d-channeld-chan#1: Sending master 1021 19:08:59 : UNUSUAL 02c...70d-chan#1: Deferring incoming commit until we sync ライトニングの送金は、送信者と受信者が互いにその取引に署名をします。まずは、送信者がコミットメントに対して署名をします。受信者はそれを受け取り、内容に問題がなければ、古いコミットメントを失効させます。この際、受信者は古いコミットメントがオンチェーンへブロードキャストされていないか確認する必要があります。そのためには、まずはビットコインの最新のブロック高まで同期して確認します。もしブロック高の同期が未完であれば、相手からのコミットメントを受け取ってもその処理を中断して、ブロック高の同期を待ちます。もし、この状態でアプリを閉じてしまうとどうなるか...送信者はコミットメントに署名をして受信者へ渡した状態で、これは送金が宙に浮いている状態です。この場合ライトニングでは、ある一定期間が経過すると、その中途半端な取引をオンチェーンへ展開して資金を回収するプロトコルになっています。これが所謂、チャネルの強制閉鎖です。 ウォレットを開き、支払いを受け取ろうとする。しかしブロック高の同期が完了していない場合、その取引は中途半端になる。その状態でアプリを閉じることで、一定期間経過後にチャネルが閉鎖されてしまう。これがテスターから報告のあったチャネル強制閉鎖の原因でした。 対応策は、ブロック同期が完了するまでインボイスの生成や受け取りができないようにすれば良いはずです。 GreenlightやBreezSDKといったライトニングウォレットの開発が楽になるツールがでてきても、ブロック高の同期など、ビットコインの基本的な処理が必須で、これが「
Pinning攻撃とその対策
はじめに LNにはPinning攻撃と呼ばれる攻撃手法があり、現在この攻撃を防ぐことはできないとされている。ただし、この攻撃の実行可能性はそれほど高くないとされており、またこの対策・緩和策にはビットコインのベースレイヤーの変更が必要なため、それほど急務といった感じではない。しかし、本攻撃の仕組みや対策を知っておくことに越したことはないので、以下にその概要をまとめた。 LNのトランザクション構成 LNで使用されるトランザクションには以下の5種類がある。このうち今回重要になるのが、CommitmentトランザクションとHTLCトランザクションである。 Fundingトランザクション Commitmentトランザクション HTLC-successトランザクション HTLC-timeoutトランザクション Closingトランザクション LNは１つのUTXOを2者間で共有し、両者の合意に基づき互いの残高を更新していく。更新ごとに作成するトランザクションをCommitmentトランザクションと呼ぶ。これは2者間の残高状態と送金の中継に使うHTLCを管理するもので、どちらか一方の通信が途絶えた場合でも、一方的に資金をオンチェーンで回収できるような構成になっている。このCommitmentトランザクションはFundingトランザクションをインプットに持つ。（Fundingトランザクションは2者間マルチシグアドレスをアウトプットに持つ） HTLCトランザクションは、Commitmentトランザクションをインプットに持つトランザクションである。これは、送金の中継に使われるHTLCがタイムアウトした場合、オンチェーンでその資金を回収するために必要となるトランザクションである。HTLCの送信者はHTLC-timeoutトランザクションを、受信者はHTLC-successトランザクションを保有する。 Commitmentトランザクションのアウトプットは、以下の6種類がある。 To_local To_remote To_local_anchor To_remote_anchor Offered_htlc Received_htlc Offered_htlcとReceived_htlcは以下の方法で資金回収ができる。 Offered_htlcの使用条件は、HTLC-timeo
