Yuya

Yuya

@ogw_yuya

ちょビットコイナー nostr id: npub1l83ycz54gng3nd8suvww43fardjsca37x7z5rcwlmeqzudg027fqe9hwaa

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といったライトニングウォレットの開発が楽になるツールがでてきても、ブロック高の同期など、ビットコインの基本的な処理が必須で、これが「

Greenlightをセルフホストしてリモート署名をする⚡

GreenlightはBlockstream社が開発しているLNノードとその秘密鍵を分離して、リモート署名を可能にするサービスです。言い換えると、秘密鍵は自己管理して、LNノードをマネージドサービスとして利用することができます。LNノードと秘密鍵を分離することのメリットは以下が上げられます。 ノードの保守管理が不要となる 秘密鍵を自己管理できる(ハッキングによる資金流出リスクを低減) ウォレット開発コストが低減する Lappsの連携が容易になる 既存のモバイル用LNウォレットはLNノード自体が搭載されているものや、LDKのようなライブラリを組み合わせてLNノードをモバイル向けに実装するものが主流ですが、これはウォレットのパフォーマンスが低下したり、開発コストが高くなります。これはペイメントチャネル特有の状態管理やオニオンルーティングの経路選択など様々な処理をしなければならないからです。一方、オンチェーン専用のビットコインウォレットやメタマスク等はこの状態管理は不要で、主に送金時の署名をするだけでよいので、LNウォレットと比べると開発コストはそこまで高くありません。 Greenlightでは、ノード(ペイメントチャネルの状態管理)と秘密鍵(署名)を分離することで、開発者は署名に関する箇所だけを実装すればよく、LNノード自体を気にする必要がありません。また、ユーザーとしても秘密鍵のみ管理すればよく、LNノードの保守管理は不要になります。 基本的に秘密鍵さえ管理していれば、あとはマネージドサービスを利用するだけで、LNノードでの送受信ができますが、今回はGreenlightをマネージドからセルフホストする方法について試したことを以下に記載します。 --- 1.セットアップ Greenlightのレポジトリからソースコードをクローンして、ビルドします。ビルドにはDockerが必要です。詳細はこちらのチュートリアルを参照ください。 $ git clone git@github.com:Blockstream/greenlight.git gl-testing-tutorial $ cd gl-testing-tutorial $ make docker-image $ make build-self 一度、チュートリアルのサ

なぜCLNの送金は不安定なのか

LNDの経路探索(pathfinding)の肝はMission Controlである。これによりLNDの送金は比較的安定しており、個人的にも満足している。Mission Controlには主に2つの探索手法がある。 Apriori estimator:これは過去の送金データを元に成功確率の高い経路を探索する。未試行なホップの成功率を60%として、これをアプリオリな値としている Bimodal estimator:大半のチャネルは流量性が偏っているという前提で、成功率はチャネルサイズに比例(大きなチャネルほど成功率が高い)する 一方、CLNの送金は不安定であり、送金時間も比較的長いという感覚がある。なぜCLNの送金は不安定なのか。CLNはチャネルサイズを元に経路を探索する(LNDでいうBimodal estimator)。それに加えて、経路のランダム化や金額を小さく分割して送金するMPPなどを活用して、プライバシー重視な経路探索をする。 CLNがLNDと比べて送金が不安定な要因は、過去の送金データを保存していなことである。過去に送金が失敗した経路を区別することができないため、再度同じ経路で送金をしてしまったり、成功した経路も記録されていないため、同じ経路で送金しようとすらしない。 このため、CLNはLNDなどと比べて送金が不安定であったり、送金時間がかかったりする。しかし、現在、CLNはChannel Hintsを使った過去データからの経路探索の実装が進んでいるので、次期リリースが待ち遠しい。 https://github.com/ElementsProject/lightning/pull/7487

OP_CAT😺も不要!?ESDSA署名の長さを署名するランポート署名の提案

ビットコインの署名方式にはESDSA署名とSchnorr署名の二種類があり、pre-Taprootでは前者を、post-Taprootでは後者の方式を使いトランザクションを署名します。Schnorr署名はソフトフォークによって新たにビットコインコンセンサスに追加された新しい署名です。これらの署名にはそれぞれの特徴があり、Schnorr署名は署名の加算やバッチ検証ができます。ただし、どちらの署名も量子耐性を持っていません。 ランポート署名は量子耐性のある署名で、これまでもビットコイン界隈ではその活用方法が議論されてきました。しかし、ランポート署名を有効にするには、新しいOPコードの追加など、ソフトフォークが必要だと考えられていました。 今月Bitcoin-Devメーリングリストに、ソフトフォークなしでもランポート署名を使えるようにする提案がされました。 ランポート署名は、まず2k個のペアのランダム値を秘密鍵、そのハッシュ値を公開鍵として生成します。署名は、kビットのメッセージに対して、そのビットに対応する秘密鍵を選択します。検証は、公開鍵、メッセージ、署名を使い、署名(実際は秘密鍵)をハッシュしてメッセージのビット列に対応する公開鍵と等しいかを検証します。 今回提案されたランポート署名は、ESDSA署名の長さをランポート署名します。ESDSA署名の長さは可変で(変化する確率は1/256とかなり小さい)、OP_SIZEでこの値を取得します。この値が可変なのでOP_IFで条件分岐させるることができ、その分岐ごとにランポート署名の検証をさせます。以下はメーリスで提案された擬似コードの一部抜粋です。 PUSH ecdsaPubkey0 OP_CHECKSIG (ecdsaSig0) // Verify lamport signature on ecdsaSig0 PUSH x00, x01 if OP_SIZE (ecdsaSig0) == 59: if OP_HASH(y00) != x00: OP_RETURN else if OP_SIZE (ecdsaSig0) < 59: if OP_HASH(y01) != x01: OP_RETURN 正当なユーザーはランポート署名に使ったペアのどちらか一方の秘密鍵を公開するだけで済みます。上記の例で、ecdsaSig0のサイズが58バイトであれば、y01の秘密鍵を公開します。 一方、量子コンピュータのある世界で攻撃者はESDSA署名を偽造できたとしても、その長さが59バイトであれば、y00を公開しなければならず、この値は未知です。そのため、攻撃者は既知のy01を使うためにESDSA署名の

OpenTimestamps:タイムスタンプサーバーの仕組み

OpenTimestampsは任意のファイルがある時点で存在していたことを証明する仕組みです。基本的な仕組みは、ファイルのダイジェストからマークル木のルートを計算して、その値をビットコインのトランザクションに書き込み、トランザクションがブロックに含まれるのを待ちます。これで、そのファイルは、トランザクションが含まれたブロックのヘッダーに書き込まれているタイムスタンプ時点で存在していたことを証明できます。証明するために必要なのは以下となります。 ファイルそのものとそのダイジェスト(ハッシュ) ルートから対象のファイルダイジェストがあるノードへのパスともう片方のハッシュ そのパスに含まれないトップノードのハッシュ 以下の図で、ファイルダイジェストがHBだとすると、2はHA、3はHCDとなります。 出展元はこちら OpenTimestampsでは各人がファイルダイジェストをサーバーへ送信し、サーバーはそれらのダイジェストからマークル木を構成し、そのルート値をビットコインのトランザクションへ書き込んでいます。しかし、ビットコインのブロックが生成されるまでに10分程度かかるため、使い勝手がよくありません。そこでカレンダーというサーバーを介在させることで、ユーザーはタイムスタンプを数秒で完了させることができます。このカレンダーサーバーはユーザーからのファイルダイジェストを預かり、ブロック承認された時点で構成したマークル木のデータを更新してくれます。ユーザーは後でカレンダーへアクセスして証明に必要なデータを取得することができます。 このタイムスタンプサービスは誰でも無料で使うことができます。ただし、ビットコインのブロックチェーンにデータを書き込んでいるので、その都度手数料が発生しています。こちらのサイトで確認できますが、だいたい1トランザクションで200円(2000sat)くらいみたいです。 参考OpenTimestamps: Scalable, Tr

サトシの受け取りはバケツで

ウォレットをバケツにたとえた説明は分かりやすい。もし受け取る水がバケツから溢れる場合、バケツを大きなものと取り換える。この際、オンチェーンへの書き込みが発生する。以前までは、バケツから溢れる場合、新たにバケツを用意していたが、スプライシングを使うことでバケツを大きなものと取り換え、常に1つのバケツを保有しているだけでよい。 ※ウォレットをバケツにたとえているが正確にはチャネル <iframe id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" allowfullscreen="allowfullscreen" class="" style="position: static; visibility: visible; width: 550px; height: 417px; display: block; flex-grow: 1;" title="Twitter Tweet" src="https://platform.twitter.com/embed/Tweet.html?dnt=true&embedId=twitter-widget-0&features=eyJ0ZndfdGltZWxpbmVfbGlzdCI6eyJidWNrZXQiOltdLCJ2ZXJzaW9uIjpudWxsfSwidGZ3X2ZvbGxvd2VyX2NvdW50X3N1bnNldCI6eyJidWNrZXQiOnRydWUsInZlcnNpb24iOm51bGx9LCJ0ZndfdHdlZXRfZWRpdF9iYWNrZW5kIjp7ImJ1Y2tldCI6Im9uIiwidmVyc2lvbiI6bnVsbH0sInRmd19yZWZzcmNfc2Vzc2lvbiI6eyJidWNrZXQiOiJvbiIsInZlcnNpb24iOm51bGx9LCJ0ZndfZm9zbnJfc29mdF9pbnRlcnZlbnRpb25zX2VuYWJsZWQiOnsiYnVja2V0Ijoib24iLCJ2ZXJzaW9uIjpudWxsfSwidGZ3X21peGVkX21lZGlhXzE1ODk3Ijp7ImJ1Y2tldCI6InRyZWF0bWVudCIsInZlcnNpb24iOm51bGx9LCJ0ZndfZXhwZXJpbWVudHNfY29va2llX2V4cGlyYXRpb24iOnsiYnVja2V0IjoxMjA5NjAwLCJ2ZXJzaW9uIjpudWxsfSwidGZ3X3Nob3dfYmlyZHdhdGNoX3Bpdm90c19lbmFibGVkIjp7ImJ1Y2tldCI6Im9uIiwidmVyc2lvb

ビットコインがチューリング完全に対応!?任意のプログラムを実行検証するBitVMとは

BitVMはビットコイン上で任意のプログラムを実行したかを検証するプロトコル。現状のビットコインは限られたプログラムしか実行できないが、BitVMを使うことで任意のプログラムを実行できる。ただし、このプログラムが実行されるのはビットコイン上ではなく、オフチェーン上で実行される。その実行結果が正しいかの検証をビットコイン上で行う。もし実行結果が間違っている場合、Fraud Proofを使って資金を没収することができる、というのがBitVMの仕組み。 BitVMの提案書はページ数も少なく内容も難しくないのでこちらの原文を読むのがおすすめ。日本語での解説記事はこちら。 論理回路コミットメントという発明 BitVMではBit Value Commitmentという0または1を出力するためのプリイメジハッシュをそれぞれ構成する。これをOP_BITCOMMITMENTと呼ぶ。 #Bit Value Commitment OP_IF OP_HASH160 <hash1> OP_EUALVERIFY <1> OP_ELSE OP_HASH160 <hash0> OP_EUALVERIFY <0> OP_ENDIF 次に、NAND回路を構成するが、これは既存のビットコインスクリプトであるOP_BOOLAND, OP_NOTを使うことで簡単に構成できる。これをOP_NANDと呼ぶ。 #OP_NAND OP_BOOLAND OP_NOT OP_BITCOMMITMENTとOP_NANDを使ってLogic Gate Commitment(論理回路コミットメント)を構成する。これもプリイメジハッシュをセットすることで論理回路にコミットする。0または1に対応するプリイメジを公開することで論理回路の出力を制御することができる。 //Cのビット値をALTSTACKへ退避 OPBITCOMMITMENT OPTOALTSTACK //Bのビット値をALTSTACKへ退避 OPBITCOMMITMENT OPTOALTSTACK //Aのビット値をSTACKへセット OP_BITCOMMITMENT //Bのビット値をSTACKへセット OP_FRO

BitcoinがUTXOを採用した理由?

UTXOモデルは主に"スマコン"ではない通貨用途を目的としたブロックチェーンに採用されることが多いです。スマコンの場合はアカウントベースと呼ばれる、残高およびデータが直接アカウントと結びつくデータ形式を取ることが多いです。しかし、そのアカウントベースの方がなんとなく実装しやすそうではないですか?なぜBitcoinはその直接的な実装ではなく、UTXOモデルを考案・採用したのでしょう?UTXOには様々な利点があります。堅牢で個別的な検証可能性、mem pool内の他のtxの実行に影響されてtxの再計算をする必要がない、アカウントとの所有権の紐付けがないのでプライバシーが高い。とりわけアドレスのリユースをしなければプライバシーが高くなるのは間違いないです。以前はここら辺がUTXO採用の理由かなと考えていました。しかしビットコインのオペコードの廃止と導入の仕様を思い出すと、新しい仮説を考えることができます。つまり、もう一つ考えられる仮説は、ソフトフォークによるアップデート可能性を維持するためではないかということです。ソフトフォークでは以前のバージョンで回しているノードがアップデートをしなくてもそのまま回し続けてプロトコルに従うことができ、ノードにアップデートを強制しなくてもフォークが起きません。多くのチェーンでは機能追加改良をする時にハードフォークを辞さないケースが多いですが、Bitcoinでは初期から伝統的にソフトフォークによるアップデートで後方互換性を維持しています。多くの場合でそれは条件をきつくするのがソフトフォーク、ゆるくするのがハードフォークです。この説明が少しミスリーディングになるケースが限定的ですが少々あります。なぜBitcoinに新しい署名など新しい機能を入れてもノードがチェーンを検証できるとされているのでしょうか?実際には古いバージョンのノードは新しい機能のオペコード実行を検証せずにスキップしています。つまり、特定のオペコード実行されたUTXOが検証されていません。新しい仕様のオペコード実行は、まだ使われていないオペコード番号を利用するか、入っているけど誰にも使われていないオペコードが廃止されたのちそれを使うことができたります。そして、昔のバージョンのノードはオペコードをnopとしてスキップするため、新仕様のオペコードを実行したUTXOの所有権について追う必要がないのです。これはアカウントベースでは格段に難しく、UTXOがより向いていると言えるでしょう。サトシ(か昔のcore dev)はソフトフォークを維持し、開発への権力集中を避けながら、機能追加をするためにUTXOを考案した?考えすぎでしょうか?しかし、もしそうだとしたら、異様に考え抜かれた設計です。

yasu purchased this article vaal4lvtp

1000

yasu purchased this article 3gt0psvnq

2000

Yuya tipped you

100

ななななは purchased this article lsi01x8qs

1000

bcats purchased this article 6jphw1e6d

100

はじめ purchased this article xlco5hfc6

1000

Purchased this article yd1n6lvuk

-100

Sent a payment

-101

Sent a payment

-202

Sent a payment

-101

まくら purchased this article rvfvxcbbe

1000

Purchased this article cd51suwka

-100

Purchased this article fuwoncb7f

-100

Anonymous purchased this article lsi01x8qs

1000

Anonymous purchased this article lsi01x8qs

1000

Purchased this article vgbvha73d

-100

Sent a tip yzd0whhbr

-1000

Purchased this article yzd0whhbr

-100

Purchased this article zk01e8mmw

-100

Purchased this article y0ncery3v

-100

Popular stories

【Muun】ちょっと変わったライトニング搭載ノンカストディアルウォレット

1903

LNノードの運用益はどれぐらい?パート1

1867

LNノードの運用益はどれぐらい?パート3

1115

Archives

2024-09
2posts
2024-08
2posts
2024-05
1posts
2024-03
1posts
2023-11
1posts
2023-10
6posts
2023-09
5posts
2023-08
3posts
2023-07
2posts
2023-06
6posts
2023-05
8posts
2023-04
3posts
2023-03
1posts
2023-01
2posts
2022-12
5posts
2022-11
2posts
2022-10
2posts
2022-09
1posts
2022-08
5posts
2022-07
4posts
2022-06
1posts
2022-05
4posts
2022-04
3posts
2022-03
2posts
2022-02
3posts
2022-01
2posts
2021-10
2posts
2021-09
5posts
2021-08
5posts
2021-07
9posts
2021-06
2posts
2021-05
4posts
2021-04
9posts
2021-03
11posts
2021-02
5posts
2021-01
4posts
2020-12
8posts
2020-10
2posts
2020-09
20posts
2020-08
4posts
2020-07
5posts
2020-06
10posts
2020-05
7posts
2020-04
10posts
2020-03
3posts
2020-02
3posts
2020-01
6posts
2019-12
6posts
2019-11
5posts
2019-09
1posts
2019-08
1posts
2019-07
1posts
2019-05
4posts
2019-04
7posts
2019-03
4posts
2019-02
5posts