BLS署名によるアナウンスメントフリーなDLC

L2技術「Statechains」を実装したMercury wallet

LNDのDB肥大化とチャネル強制閉鎖

DiamondHandsノードの運用をする中でたまに発生する問題が、意図しないチャネル強制閉鎖。その原因はDB肥大化によるサーバーのI/O処理の遅延およびCPUの異常な使用率。LNDのDBはbboltで、その実態はSqliteのような単一のファイル。このファイルサイズが10GB以上になれば、そりゃI/O負荷がかかるよね。サーバー負荷がかかるだけでチャネル閉鎖されるのは決済システムとして良くない。そもそもペンディング状態のHTLCがタイムアウトすることでチャネルが強制閉鎖されてしまうわけだが、タイムアウトは最短でも数時間はかかる。その数時間の間にHTLCの処理ができないほど、サーバーのレスポンスが遅いことはあるのだろうか… サーバー負荷がチャネル強制閉鎖を引き起こすことがある、という言及が以下のとおりあるので、開発者も認識しているのだろう。 https://github.com/lightningnetwork/lnd/issues/6744 ただ、サーバーがハングアップしているわけではないので、たかだか数時間のペンディング状態なHTLCを正常に処理できていないのはバグだと思うんですよね…

ライトニングネットワークにおける利己的ルーティングによる無秩序の代償

キーワード：無秩序の代償、利己的ルーティング、支配戦略、ナッシュ均衡 本記事は以下の記事の内容をまとめたものである。 はじめに 上記記事の前半では、LNでのチャネル流量の枯渇(*1)率において送金の失敗率をシミュレーションしている。後半では、送金経路選択の戦略別に送金を行い、どの戦略がもっとも全体的なコストの面で非効率かをシミュレーションしている。ゲーム理論をライトニングネットワークに適用しようとする試みであり、まだまだ未開拓な領域ではあるが、面白い分野であるので以下にその内容をまとめた。 *1 チャネル流量の枯渇：A->Bへの送金時、チャネル資金がB側へ偏ってしまい送金できない状態のこと チャネル流量の枯渇率による送金シミュレーション 図1は、チャネル流量の枯渇率を調整した5つのチャネル上でランダムに送金したシミュレーション結果である。drain:0.1はA-B間のチャネル資金が0.1対0.9であることを表しており、このチャネル上でランダムに送金をする。その結果、失敗率が80%へ収束していくことが読み取れる。チャネル流量の枯渇率が0.1と極端に偏っているのに失敗率が80%しかないのは、B→Aへの送金があることで、チャネルバランスが少しだけ改善するためである。また、drain:0.1のチャネルでは、逆方向の送金はほぼ100%成功することが直感的に分かる。この仮定の下で枯渇した方向への送金の成功率を求めると、0.1*1+0.9*x=0.2 x=11.1%となり、11%の確率で枯渇した方向への送金が成功することが分かる。 <p

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

ステーブルビットコインウォレットのアイディア

ステーブルビットコインウォレットのアイディアの1つにCFDの差金決済があります。これはビットコインをショートして、定期的に差金決済することで、額面を一定に保ちつつ、価格変動によるビットコイン量を増減させる方法です。一定間隔で清算する必要がありますが、オンチェーンだと手数料がかかりすぎるので、ライトニングネットワーク上で行うことが望ましいかと思います。 そして、その先駆けとしてバイナリーオプション取引ができるdlc.soyを公開したわけですが、これはバイナリー取引なのでCFDのような動的な差額を清算することができない、という問題がありました。 そこでライトニング⚡でCFDを可能にするアイディアを少し思いついたので以下に記載してみます。

実装しなきゃ

この数ヶ月はビットコインのメーリスやIRCを追うのにほぼ時間使ってて、何もアウトプットできていなかった... しかもベースレイヤー周りだからライトニングとはほぼ関係ない そろそろステーブルビットコインウォレットの実装に取り掛かろうかな😎 飲み会いってきま🍻

ビットコイン決済と税金

ありえないと思うけど、ビットコインが課税されつづけたら、あるコミュニティ内では換金せず匿名通貨として使われださないかな。 深く考えたことはないけど、損益がなければ課税対象にならないなら、BTCを担保にライトニングでSatoshiを借りて、それで支払いをする。借りた時点を基準価額にして支払い時の損益計算するならダメだけど、、、何かうまくいく方法ないかな。 あとは、単純にステーブルビットコインウォレット。ウォレットにはビットコインしかないけど、資産として保管するものと、通貨としてステーブルにしておくもので、残高が2面あるようなウォレットが出てくると、今の税制でも気にせずに決済できるよね。 何か質問、意見、アイディアあればコメントください 😺

OP_CAT😺とCovenants📜の備忘録

先月末に物議を醸しだしたOP_CTVを調べていくなかで、他のOPコードや暗号トリックを使ってCovenantsを実現する方法が面白かったので、以下の記事をベースに纏めてみました（以下の記事を理解した前提で記事を書いてます）。 https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html 前提 Covenantsの仕組みを理解するためには、ビットコインのトランザクションのデータ構造とスクリプトシステムを理解する必要があります。 1. トランザクションのデータ構造 トランザクションのデータ構造は以下のようになっています。inputsフィールドはさらにprev txidやscriptSigに、outpusフィールドはvalueやscriptPubkeyに細分化されています。 2. スクリプトシステム スクリプトシステムは、OPコード（命令語・機械語）を１つ１つ実行し、データをスタック領域へプッシュしたりする実行環境のことです。以下の図例は標準的なビットコインのスクリプトを実行しているもので、scriptPubkeyとscriptSigを結合し、OPコードを実行、データをスタックへプッシュしていく流れを表しています。 ビットコインを送金する場合、上記のデータ構造に沿ってデータを組み立て、それに対して署名をしscriptSigに署名をセットします。このデータをブロードキャストし、受け取ったノードが、この署名を検証する時、prev txidとprev txout-indexを参照して消費しようとしている前のトランザクションのscriptPubkeyを取得します。イメージとしては以下の図のようになります（参照元）。そして上記のスクリプトシステムに従

Speedy Trialの問題点（OP_CTVのアクティベーション方法を巡って）

異端ソフトフォークOP_CTVについての見解

ライトニングネットワークによる為替取引・資金移動の備忘録

資金移動に関しての海外サービス企業による考察は、中継者が盗むことができない仕様になっているから、資金移動ライセンスは不要と考えているみたい（記事はこちら） また、為替取引や資金移動よりも、AML/CFT（マネー・ローンダリング及びテロ資金供与対策）の方が日本含め世界のトレンドだとは思うのでとりあえず、金融庁と日銀が公開しているレポートを掲載しておく（日銀は単にブロックチェーンのスケーリング手法を紹介しているだけ） ResearchPaper_MRI_ja.pdf (fsa.go.jp) ブロックチェーン技術のスケーラビリティ問題への対応 (boj.or.jp) LNノードを運用することが規制対象になるかは分からないが、オフチェーン取引だけではあまり意味がなく、取引所やオンチェーンスワップとの接点をKYCやモニタリングすればいいんじゃないかなと、それで資金洗浄等の監視はできると思う。