Guixを使った決定性ビルド - Develop with pleasure!
先日、Bitcoin CoreをGitian Buildを使ってビルドする記事を書いた↓ techmedia-think.hatenablog.com けど、最近以下のPRがBitcoin Coreにマージされた結果、Linux / Windows / macOSのバイナリのビルドがGNU Guixでできるようになった。 github.com GitianとGuix Gitianは元々Bitcoin Coreで再現性のあるビルドをできるよう開発されたツール。ただこのツール、VMを使ってバイナリをビルドするんだけど、Ubuntuに結構依存している。Bitcoinのような管理者のいないコードベースのエコシステムにおいては、監査可能性や透明なバイナリを提供するのが大切で、環境依存はなるべく少ない方が望ましい。 そのため既存のGitianベースのビルドの仕組みを完全に置き換えるのに、GNU Gui
Schnorr署名とOP_CATを使ったCovenants - Develop with pleasure!
Covenantsは、Bitcoinのコインの用途（送り先など）を制限するための仕組み。これまでCovenantsを導入する仕組みの提案がいくつかあったけど、2021年1月にAndrew PoelstraがSchnorr署名とOP_CATを利用したCovenantsの構成を発表しているので、その内容について見てみる↓ https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html もともと、Elementsで実装されているスタック上のアイテムの署名検証を行うOP_CHECKSIGFROMSTACK opcodeとOP_CHECKSIGを組み合わせてCovenantsを構成する方法は以前発表されていたけど、OP_CHECKSIGFROMSTACK を使わず、Schnorr署名とOP_CATで同様のことを行う構成みたい。
Berlinアップグレード前に存在した脅威の開示 - Develop with pleasure!
Ethereum Foundation Blogで公開された、先月アップグレードされたBerlin以前に存在した脅威に関する開示記事↓ blog.ethereum.org 脅威とは？ ↑の記事で取り上げられている脅威というは、処理に時間のかかるトランザクションを作成することでDoS攻撃を可能にするというもの。似たような攻撃として、上海アタックと呼ばれる攻撃が実際に2016年に行われ、gethが一時的に使えなくなるといった事態が発生した。 DoS攻撃を可能にするのは、Ethereumで成長中のステートツリーを利用したもの。このツリーはMerkle Patricia Trieと呼ばれるデータ構造で管理されている。この仕組みやボトルネックについては以前書いた↓参照。 techmedia-think.hatenablog.com 2019年に公開されたBroken Metreという論文では、遺伝的
PSBT Version 2を定義したBIP-370 - Develop with pleasure!
PSBTは、マルチパーティでBitcoinのトランザクションを構築したり、トランザクションの署名にハードウェアウォレットと連携したりする際に、共通のデータフォーマットを定義した仕様で、2017年に定義され、これまでいくつか修正が加えられてきた↓ techmedia-think.hatenablog.com そして、先日PSBTのVersion 2がBIP-370として定義された↓ https://github.com/bitcoin/bips/blob/master/bip-0370.mediawiki BIP-174のPSBTは、グローバルタイプで未署名のトランザクションを定義（PSBT_GLOBAL_UNSIGNED_TX）していたので、後からそのトランザクションにインプットやアウトプットを追加することができなかった。この問題に対応するため、BIP-370で新しいPSBT Versio
WTXIDを使ったP2Pリレーの仕様を定義したBIP-339 - Develop with pleasure!
Bitcoinでトランザクションをリレーする際は、接続中のピアに対してinvメッセージでトランザクションを通知し、相手のピアがそのトランザクションを持っていない場合、getdataメッセージでそのトランザクションデータを要求する。この際のトランザクションの識別子にはtxidが使われている。この振る舞いはSegwit導入後も同じまま。 Segwitトランザクションでは、インプットの署名データはwitnessと呼ばれる領域に移され、txidを計算する際にこのwitnessのデータは含まれない。つまりtxidはwitnessのデータにコミットしていない。このtxidとは別にwitnessのデータも含めて計算しているのがwtxid。トランザクションデータの内、唯一改変が可能なデータがインプットのscriptSigのデータだったのが、SegwitによりscriptSigは空になったので、txidのm
Bulletproofsにおける内積の証明 - Develop with pleasure!
Bulletproofsは2017年にBünzらが発表したゼロ知識証明システムの一種で、Trusted Setupを必要とせず、プルーフが非常に短く、その集約が可能であるという特性を持っている。最初はConfidential Transactionの秘匿した値がある範囲内にあることを証明するrange proofを効率的に実現するために提案されが、range proofに限らず、一般的な算術回路向けの非対話型ゼロ知識証明プロトコルとしても提案されている。 Bulletproofsがどのような仕組みでrange proofや算術回路で動作するのか見ていく前に、Bulletproofsのベースとなる内積の証明の仕組みについて理解する。 内積の証明 Bulletproofsの重要な構成要素の１つは、２つの異なるベクトルを持つPedersen Commitmentに対してベクトルの内積を計算するア
Bulletproofのrange proofに任意のデータを埋め込む方法と復元する（rewind）方法 - Develop with pleasure!
先日、Grinがウォレットリストアの際に自身のUTXOを識別するのにBulletproofsのrange proofにヒントを隠している記事を書いたけど、↓ techmedia-think.hatenablog.com 今回の記事では、リストアという限定的な利用方法だけでなく任意のデータをrange proofに埋め込む方法としてまとめてみる。 range proof生成時のメッセージの埋め込み Grin自体はRustで実装されているが、range proofの生成や検証はlibsecp256k1にBulletproofの拡張を加えたsecp256k1-zkpを使っている。range proofの生成処理はこちら。 埋め込み可能なメッセージは今のところ20バイトなので、RIPEMD160とかのハッシュ値とかが向いてる。 関係するところだけ抜き出すと、 生成者はnonceを生成する。 cha
Bulletproofsを利用したrange proofの仕組み - Develop with pleasure!
techmedia-think.hatenablog.com ↑でBulletproofsの基本となる内積の証明の仕組みについて書いたので、今回はこれがCTやMimblewimbleなどで必要とされるrange proofにどう適用されるのか見ていく。 range proofとは？ CTと同様Mimblewimbleなどでもコインの量を秘匿するのに以下のような楕円曲線を利用したPedersen Commitmentが採用されている。 C = xG + aH xはBlinding Factor（MWでは秘密鍵に該当）で、aがコインの量。コインの量をこのようなコミットメントCにすることで、外部からaの値を分からなくしている。具体的な仕組みが知りたい場合は、以前撮影したMWのGBEC動画を参照↓ goblockchain.network このようなPedersen Commitmentを使ってコ
Bulletproofsを利用したGrinのウォレットのリストア - Develop with pleasure!
BitcoinのウォレットであればほぼBIP-32のHDウォレットをサポートしているため、マスターシードさえバックアップしておけば、いつでもウォレットをリストアすることができる。Bitcoinの受け取りに使用するアドレスは全てマスターシードから導出した鍵から作られるためだ。 一方、MimblewimbleのようにPedersen Commitmentにコインをロックしている通貨の場合、ウォレットのリストアはBitcoinほど単純ではない。 基本的にMimblewimbleをサポートしている場合、UTXOは以下のような形式のPedersen Commitmentになる。 Commitment = rG + vH ここで、ブラインドファクターrが秘密鍵に該当し、vがコインの量になる。 rはBitcoinと同様マスターシードから導出可能だが、Commitmentはコインの量vを含んでいるため、v
マークルツリーを利用したハッシュベースのアキュムレータ「Utreexo」 - Develop with pleasure!
BitcoinのUTXOセットを管理するにあたって、そのストレージ要件を大幅に削減すると期待されているアキュムレータ。昨年のScaling Bitcoinでは、スタンフォード大学のBenedikt BünzがRSAを利用したアキュムレータを紹介した↓ techmedia-think.hatenablog.com ↑はその性質上Trusted Setupを必要とするという課題があり、Trusted Setupを回避するためにClass Groupを使用するという提案もあるがまだ新しい暗号プリミティブであるという課題はある。 そんな中、今回Lightning Networkのホワイトペーパーの共著者でもあるThaddeus Dryjaがマークルツリーを利用したハッシュベースのアキュムレータ「Utreexo」を発表した↓ https://eprint.iacr.org/2019/611.pdf
チェーン上で異なるコンセンサスの実行を可能にする拡張方法「Extension Block」 - Develop with pleasure!
最近、LitecoinがMimblewimbleを導入するLIP（Litecoin版BIP）が提案された↓ https://github.com/litecoin-project/lips/blob/master/lip-0002.mediawiki https://github.com/litecoin-project/lips/blob/master/lip-0003.mediawiki Litecoinは元々Bitcoinのアルトコインであるため、根本的にブロックチェーンの構造が異なるMimblewimbleを導入するのはBitcoin同様難しい。そこでLitecoinがMimblewimbleを導入するために採った方法がExtension Blockという拡張方法だ。 Auxiliary Block Extension Blockのアイディアはもともと、2013年にJohnson
bitcoin-rubyで決定性署名を生成する - Develop with pleasure!
bitcoin-rubyのP2PKHの署名のデフォルト実装 bitcoin-rubyを使ってP2PKHのUTXOを入力にしたトランザクションの署名は↓のように書ける。 require 'bitcoin' Bitcoin.network = :testnet prev_key = Bitcoin::Key.from_base58('秘密鍵') prev_tx = Bitcoin::Protocol::Tx.new('入力のOutPointのTxのrawデータ'.htb) tx = Bitcoin::Protocol::Tx.new tx.add_in(Bitcoin::Protocol::TxIn.from_hex_hash(prev_tx.hash, 1)) tx.add_out(Bitcoin::Protocol::TxOut.value_to_address(bitcoinの量, '送
184754
SchnorrのBIPドラフト↓ https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki に応用例の１つとして記載されているのが、Scnorr署名とペダーセンの検証可能な秘密分散法を利用してm-of-nのマルチシグを構成するというもので、参照論文↓ https://t.co/jMhQnovLcb をざっと読んで、どう構成なのか見てみる。 前提技術 まず、前提となる暗号技術として、以下のシャミアの閾値法、ペダーセンの検証可能な秘密分散法などについておさえとく。 以下、楕円曲線の離散対数問題を利用するため、qを巨大な素数とし、GとHを楕円曲線Eの位数qのサブグループのジェネレータ、h()を一方向ハッシュ関数とする。 シャミアの(t, n)閾値法 ベースとなるプリミティブの１つが(t, n)閾値法。これはディーラーが
BEAMが提供する監査機能 - Develop with pleasure!
MimblewimbleではPedersen Commitmentにより取引する量が秘匿され、さらにスクリプトがなくPedersen CommitmentのBlinding Factorがそのコインの所有権を証明するキーになる。そのため、Perdersen Commitmentを見ただけでは誰から誰へのいくらの送金なのかは分からない。 そんなMimblewimbleをサポートするブロックチェーンの１つがBEAMだが、BEAMではウォレットが当局向けの監査機能を提供する↓ https://github.com/BeamMW/beam/wiki/Wallet-audit ウォレットが提供する監査機能 監査機能を提供するBEAMのビジネスウォレットはどのように監査機能を実現しているのか？ 監査人向けの鍵ペア ビジネスウォレットは監査用に公開鍵/秘密鍵のペアを作成する。この鍵ペアの内、公開鍵のみが
Confidential Transactionのrange proofの仕組み - Develop with pleasure!
techmedia-think.hatenablog.com ↑でConfidential Transactionのコミットメントの作成と検証をしたので、続いてrange proofについて見てみる。 Confidential Transactionではトランザクションの各出力にコインの量ではなくコミットメント（楕円曲線上の点）がセットされるようになり、それにより取引されるコインの量が秘匿され、検証者は楕円曲線上の点を計算することで入力と出力のコインのバランスが取れていることを検証する。 ここで１つ問題になるのが、コミットメントの計算時に非常に大きな値を設定することを値をオーバーフローさせ、負の値として動作する場合。この場合マイナスのコインによりバランスの計算が行われるため、結果的に何も無いところからコインを生み出すことができてしまう。 この問題に対応するため、コミットされた各出力の値が、
Bitcoin CoreはなぜECDSA署名にLOW Rを適用するようになったのか？ - Develop with pleasure!
Bitcoinでは、送金時にトランザクションにセットする署名に、現在ECDSA署名を採用している。 秘密鍵をx、対応する公開鍵をP = xGとした場合、メッセージにｍに対するECDSA署名は以下のように作成する。 署名の作成 ランダムな値kを選択する。 点R = kGを計算する（Rが楕円曲線上の有効な点でない場合ｋの選択からやり直す）。 点Rのx座標をrとする。 を計算する。 計算した(r, s)のペアが署名のデータとなる。 これは標準的なECDSAの署名ルールだが、Bitcoin Coreの場合、ECDSA署名作成時に以下のようにいくつかルールを加えている（コンセンサスルールではないが、標準トランザクションルールに該当するものはある）。 LOW Sルール BitcoinではSegwitの導入によりTXIDに関するmalleabilityは排除されたが、ECDSAの署名自体にはmallea
The State of Atomic Swaps at Scaling Bitcoin 2018 - Develop with pleasure!
Scaling Bitcoin 2018復習シリーズ。今回は10/7のThomas Eizinger（COMITプロトコル開発してる人みたい）が発表した「The State of Atomic Swaps」の内容について見てみる↓ www.youtube.com 書き起こしは↓ http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/ Atomic Swap Atomic Swapはチェーン間で相手を信用することなく、アトミックにコインを交換するのに使用されるプロトコル。一般的なプロトコルとしてはHTLCが利用される。 アリスがBitcoinを持ち、ボブがLitecoinを持っている状態でアリスとボブはそれぞれBitcoinとLitecoinを交換したい場合、以下のような手順で相手を信用することなく各
lndで実装されているBIP-39に代わるシード管理方式「aezeed」 - Develop with pleasure!
lndでBIP-39*1の欠点を修正するために実装されたシードの新しい管理方式「aezeed」について↓読んでみた。 https://github.com/lightningnetwork/lnd/tree/master/aezeed 2018年3月のSF Bitcoin Devsで@roasbeefがlnd v0.4-betaの紹介した際にも触れられてる。 www.youtube.com docs.google.com aezeedはBIP-39の以下の欠点を修正する： バージョンの欠如 バージョン情報がない場合、ウォレットがリカバリープロセス中にどのアドレスを再導出すべきか分からない場合がある（秘密鍵や公開鍵は導出できても、そこからどのアドレス：P2PKH、P2WPKH、P2SH-P2WSHを導出すべきか決定できない）。 ウォレットの誕生日の欠如 ウォレットがいつできたかという情報がな
新しいSIGHASHフラグ「SIGHASH_NOINPUT」を定義したBIP-118 - Develop with pleasure!
現在BitcoinにはSIGHASH_ALL、SIGHASH_SINGLE、SIGHASH_NONEの３つにSIGHASH_ANYONECANPAYを組み合わせた系6バターンのSIGHASHの組み合わせがあるが↓ techmedia-think.hatenablog.com これにSIGHASH_NOINPUTという新しいSIGHASHフラグを追加しようというBIP-118が提案された↓ https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki これまでのSIGHASHフラグの署名はいずれもインプットのデータにコミットしてきた。インプットのデータは↓ OutPoint （使用するUTXOの参照先のデータ（32バイトのTXIDとそのアウトプットのインデックス4バイト）） nSequence scriptSig この内scri
署名に厳密なDERエンコーディングを適用したBIP-066 - Develop with pleasure!
techmedia-think.hatenablog.com でECDSAの署名データの改竄に遭遇したのもあり、関連して現在のBitcoinプロトコルに適用されている署名のエンコーディングルールについて定義したBIP-066の内容もおさえておく。 bips/bip-0066.mediawiki at master · bitcoin/bips · GitHub 動機 Bitcoinの参照実装では、署名検証をOpenSSLに依存しており（現在は独自実装したlibsecp256k1）、これがBitcoinのブロックの有効性を検証する暗黙的なルールになっている。しかし残念ながらOpenSSLはコンセンサスクリティカルな動作をするよう設計されておらず、その変更がBitcoinのソフトウェアに影響を及ぼす可能性がある。 特に重要な機能の１つが署名のエンコードである。最近までOpenSSLはDER標準
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
