記事を購入しました。 guuke01yu
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署名の
0
2
Yuya
OpenTimestamps：タイムスタンプサーバーの仕組み
OpenTimestampsは任意のファイルがある時点で存在していたことを証明する仕組みです。基本的な仕組みは、ファイルのダイジェストからマークル木のルートを計算して、その値をビットコインのトランザクションに書き込み、トランザクションがブロックに含まれるのを待ちます。これで、そのファイルは、トランザクションが含まれたブロックのヘッダーに書き込まれているタイムスタンプ時点で存在していたことを証明できます。証明するために必要なのは以下となります。 ファイルそのものとそのダイジェスト（ハッシュ） ルートから対象のファイルダイジェストがあるノードへのパスともう片方のハッシュ そのパスに含まれないトップノードのハッシュ 以下の図で、ファイルダイジェストがHBだとすると、2はHA、3はHCDとなります。 出展元はこちら OpenTimestampsでは各人がファイルダイジェストをサーバーへ送信し、サーバーはそれらのダイジェストからマークル木を構成し、そのルート値をビットコインのトランザクションへ書き込んでいます。しかし、ビットコインのブロックが生成されるまでに10分程度かかるため、使い勝手がよくありません。そこでカレンダーというサーバーを介在させることで、ユーザーはタイムスタンプを数秒で完了させることができます。このカレンダーサーバーはユーザーからのファイルダイジェストを預かり、ブロック承認された時点で構成したマークル木のデータを更新してくれます。ユーザーは後でカレンダーへアクセスして証明に必要なデータを取得することができます。 このタイムスタンプサービスは誰でも無料で使うことができます。ただし、ビットコインのブロックチェーンにデータを書き込んでいるので、その都度手数料が発生しています。こちらのサイトで確認できますが、だいたい1トランザクションで200円（2000sat）くらいみたいです。 参考OpenTimestamps: Scalable, Tr
0
1
Yuya
サトシの受け取りはバケツで
ウォレットをバケツにたとえた説明は分かりやすい。もし受け取る水がバケツから溢れる場合、バケツを大きなものと取り換える。この際、オンチェーンへの書き込みが発生する。以前までは、バケツから溢れる場合、新たにバケツを用意していたが、スプライシングを使うことでバケツを大きなものと取り換え、常に１つのバケツを保有しているだけでよい。 ※ウォレットをバケツにたとえているが正確にはチャネル <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
0
2
Yuya
GreenlightとコミットメントTX
Greenlightは、クライアント側に秘密鍵を保有しつつLNのノード管理をクラウド上で行えるBlockstream社のサービスです。LNでの2者間の残高は、署名済みコミットメントTXとしてお互いがオフライン（ローカル）で管理しています。もし相手が音信不通になればこのコミットメントTXをブロードキャストすることで資金をオンチェーン上で回収できます。 ここで疑問となるのは、Greenlightのクラウド上ではこのコミットメントTXが管理されているので、運営側はユーザーの同意なしにコミットメントTXをブロードキャストできるのでしょうか？ 答えは、できないです。コミットメントTXは署名済みではありますが、この署名済みとは、相手側の署名のみです。そのため、Greenlight上で管理されているコミットメントTXをブロードキャストするにはクライアント側で署名をする必要があります。GreenlightのFAQページにもその旨が記載されています。
0
2
100
Yuya
Greenlightのgl-clientとバージョン互換
Greenlightのgl-clientでハマった点の備忘録。Greenlightの使い方はこちらの記事を参照してみてください。 BreezSDKでGreenlightのノード登録をすると、v23.08としてCLNのインスタンスが生成される。しかし、PyPIに公開されているgl-clientはv23.05なので、BreezSDKで登録したGreenlightのノードをgl-clientで操作しようとするとバージョンの違いによってRPCがハングする。v23.08用のgl-clientを使うにはgreenlightのレポジトリをローカルに複製してビルド、インストールする必要がある。 # 複製したGreenlightのレポジトリ配下でビルド $ git clone git@github.com:Blockstream/greenlight.git $ cd greenlight $ make build-py # ビルドされたフォルダへ移動してgl-clientをインストール $ cd ./libs/gl-client-py/dist $ pip install gl_client-0.1.9-cp37-abi3-manylinux_2_27_x86_64.whl
0
0
Yuya
ビットコインがチューリング完全に対応！？任意のプログラムを実行検証する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
0
4
Yuya
LoopのMusig2によるプライバシー向上と手数料削減
Loopのこちらのリリース（2023年4月）から、デフォルトのスワップにMusig2が使われることになっていました。Musig2を使うことでよりプライバシーの向上や手数料の削減になります。以下、その概要です。 ユーザーとLoopはMusig2を使い両者の鍵を集約する。Tapleafにはプリイメジハッシュをセットする。 LoopはHodlインボイスを生成し、ユーザーが支払う。 Loopは1.で作ったP2TRアドレスへオンチェーン送金する。 ユーザーはプリイメジを公開する。 Loopはそのプリイメジを使い2.のLN送金を決済させる。 ユーザーは自身とLoopの両者が署名をしてオンチェーン資金を回収する。 もしLoopが署名をしない場合、プリイメジを使ってTapleafからオンチェーン資金を回収する。 6.はトラストポイントになりますが、最悪7.でユーザーは非協調的、アトミックにスワップを実行できます。Loopとしては協調的に署名をしなくても問題ないですが、ユーザー側の手数料削減やオンチェーンフットプリントの低減に貢献することで、サービス満足度を向上できるので、ビジネス的にやらない意味はないでしょう。
0
0
Yuya
Elements/Liquidでコベナンツを作ってみた
ElementsとはLiquidなどのサイドチェーンを運用するためのソフトウェアです。Bitcoinを拡張した実装となっています。 Elementsに追加された新OPコード Elementsでは以前からビットコインにはないOPコードがいくつかあります。OP_CATとOP_CHECKSIGFROMSTACKを使うことでコベナンツを実現できますが、この方法は計算コストがかかるというデメリットがあります。そこでインプットやアウトプットを直接調べるためのOPコードが追加されました（詳細はこちら）。これらのOPコードはSegwit V1（別名P2TRアドレス）として使うことができます。例えば、OP_INSPECTOUTPUTVALUEはアウトプットの金額を参照することができ、以下のようなスクリプトを構成することで送金金額を制限できます。こちらのツールを使うことで、スクリプトの実行経過を確認することができます。 //インデックス0のアウトプットの金額を取得 OP0 OPINSPECTOUTPUTVALUE OP1 OPEQUALVERIFY //1000のリトルエンディアンを指定 <0xe8
0
1
Yuya
Spotlightのバグ修正
「Spotlightへ投稿した記事のアクセス統計が表示されない」という問い合わせがありました。 UA廃止に伴いGA4へ移行するのを忘れてました。この1週間くらいのアクセス統計が取れてなく、ごめんなさい🙇 入出金やTwitterログインなども不具合があったので対応しました。マイニングおみくじ機能も復活しています。 コピペで他のサイトから記事の転載をする際の不具合はデザイナーの倉谷さんにも直してもらいました。ありがとうございます。（ただ、単にコピペした場合にフォーマットが引き継がれてしまう問題（？）は根本的に解決してません。フォーマットを消した状態でコピペする場合は、Ctrl + Shift + Vでお願いします。） 今後ともSpotlightは細々と継続していくのでよろしくお願いします
0
5
Yuya
RGB-Channel in Lightning
ライトニングネットワークはビットコインをオフチェーン上で送金する仕組みである。そのネットワークを構成するペイメントチャネルは2者間のビットコイン残高の状態を管理している。このチャネルの状態にビットコイン残高以外の特性を持たせようとする取り組みがいくつかある。 RGB-Channel in Lightning ビットコイン以外のトークン残高を管理できるようにするチャネル Lightning Network compatibility - RGB Docs DLC-Channel in Lightning 残高はビットコインのままだが、残高状態を更新するために必要な二者間の署名以外にオラクルの署名も有効とするチャネル DLC on Lightning. TLDR; | by Thibaut Le Guilly | Crypto Garage | Medium 今回はRGBチャネルに焦点を当ててその実用性を考察してみる。 RGBチャネルのプロコン RGBチャネルの場合、チャネル開設者がアセットを持ってさえいればよい。これはRGBチャネルのメリットである。なぜなら、RGBのオンチェーン送金では受け取り側もUTXOを事前に用意する必要があるから。RGBチャネルを開設さえすれば、受け取り側はLN上で0承認かつ低手数料で何度も送受信が可能で、アセットをオンチェーンへ引き出す際はチャネルを閉じるだけでよい。 現状のRGBチャネルは1チャネル1アセットなので、複数アセットを扱う場合、それぞれのチャネルを開設する必要がある。そのため、受け取りたいアセットのチャネルがない場合は受け取ることができない。RGBチャネルが普及する場合、特定のアセット、例えばUSDTなどのチャネルに限定的になる可能性が高い。 チャネル間を通してアセットを送金する方法は、分散ネットワーク型、ハブ＆スポーク型、ゲートウェイ型の3通りある。RGBチャネルが普及する場合、特定のアセットに限定的になる可能性が高いので、その場合は分散ネットワーク型になる可能性もあるが、取引所やLSPなどがゲートウェイとしてRGBチャネルを運用する未来像の方がイメージしやすい。
0
2
Yuya
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も同様な処理を行い、自身のペイロードからこの送金
0
2
Yuya
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の有効期限が切れたのに
2
2
Yuya
手数料ﾚｰﾄ 5.00 ｻﾄｼ/vBで完全に詰まった(´;ω;｀)
Boltzにﾁｬﾈﾙｵｰﾌﾟﾝしようとして４週間もｽﾀｯｸしていたtx。 この３日間どうにかtxを通そうとして悩んだのに。たった今mempool.spaceの一番左から 1承認まで素っ飛ばしたぞ。ちょーすっきりした！！ 便秘の人の気持ちが少しわかったぞ。 diamondhandsのtelegramやumbrelの公式の過去ﾛｸﾞみたり lightning APIﾘﾌｧﾚﾝｽしかり。 結局、何故txが通ったのかは謎だが、何かが効いたｗには違いないと思う。 そんなにbtcに詳しくない人間が何をしたのかｱﾄﾞﾚﾅﾘﾝが出ているうちに 一応ここに残しておこう。 だってこの時期に手数料ﾚｰﾄ5sat/vbで通ることまずないと思うので。 ・よくﾈｯﾄで見かけたﾋﾞｯﾄｺｲﾝﾉｰﾄﾞのMaximum Mempool Sizeの変更。1000MBへ ・ﾋﾞｯﾄｺｲﾝﾉｰﾄﾞのReplace-By-Fee (RBF) for All Transactionsの有効化 ・ﾉｰﾄﾞの再起動 ・手数料上乗せｺﾏﾝﾄﾞ lncli wallet bumpfee --sat_per_byte 手数料ﾚｰﾄ ・これで待ちの状態をみる(ｽｲｰﾌﾟってなんやねん！) lncli wallet pendingsweeps ・これでtxをﾌﾞﾛｰﾄﾞｷｬｽﾄ(どこへ？) lncli wallet publishtx ﾄﾗﾝｻﾞｸｼｮﾝの16進値 16進値はmempool.spaceのtxの詳細で閲覧できる。 色々やってpendingsw
2
3
x0x₿0x
-100
Yuya さんから投げ銭がありました。
40000
記事を購入しました。 l23zvlb3s
-100
記事を購入しました。 0ps41tvjg
-100
Yuya さんから投げ銭がありました。
110
記事を購入しました。 kdlvjsm9n
-100
Yuya さんから投げ銭がありました。
100
Yuya さんから投げ銭がありました。
100
Yuya さんから投げ銭がありました。
10000
Yuya さんから投げ銭がありました。
200
Lappへ決済しました。
-101
記事を購入しました。 o3jls3w3g
-100
Lappへ決済しました。
-101
Lappへ決済しました。
-101
Yuya さんから投げ銭がありました。
100
Lappへ決済しました。
-101
