Yuya

Yuya

@ogw_yuya

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

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

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チャネルを運用する未来像の方がイメージしやすい。

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)。こうして入れ子になったデータをオニオンペイロードと呼ぶ。 Aはこのオニオンペイロードの先頭にBとのセッションキー(※1)をセットしてBへ送信する。Bはオニオンペイロードに1300バイトのゼロ埋めされたフィラーを追加して、共有鍵を使い2600バイトのペイロードを復号して(先頭1300バイトが復号され、残りの1300バイトは難読化される)、自身のペイロードを切り取る。残ったペイロードを左へシフトして、1300バイトを超過するデータを切り捨てる。Bはこのオニオンペイロードの先頭にCのためのセッションキーをセットしてCへ送信する。Cも同様にペイメントの先頭に1300バイトのフィラーを追加してから共有鍵を使いペイロードを復号して自身のペイロードを切り取る。残ったペイロードを左へシフトして、1300バイトを超過するデータを切り捨てる。Cはこのオニオンペイロードの先頭にDのためのセッションキーをセットしてDへ送信する。Dも同様な処理を行い、自身のペイロードからこの送金

手数料レート 5.00 サトシ/vBで完全に詰まった(´;ω;`)

Boltzにチャネルオープンしようとして4週間もスタックしていたtx。 この3日間どうにかtxを通そうとして悩んだのに。たった今mempool.spaceの一番左から 1承認まで素っ飛ばしたぞ。ちょーすっきりした!! 便秘の人の気持ちが少しわかったぞ。 diamondhandsのtelegramやumbrelの公式の過去ログみたり lightning APIリファレンスしかり。 結局、何故txが通ったのかは謎だが、何かが効いたwには違いないと思う。 そんなに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

tanakei purchased this article hrt6q85bh

1000

Purchased this article l23zvlb3s

-100

Namuyang purchased this article upde8nsu0

1000

Purchased this article 0ps41tvjg

-100

Yuya tipped you

110

Purchased this article kdlvjsm9n

-100

Yuya tipped you

100

Yuya tipped you

100

Yuya tipped you

10000

Anonymous purchased this article 3gt0psvnq

2000

Anonymous purchased this article ornqcqdwx

1000

Yuya tipped you

200

Sent a payment

-101

Purchased this article o3jls3w3g

-100

Sent a payment

-101

Sent a payment

-101

Yuya tipped you

100

Sent a payment

-101

Sent a payment

-101

Yuya tipped you

100

Popular stories

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

1829

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

1798

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

1095

Archives

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