サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
techmedia-think.hatenablog.com
ハードウェアウォレットからマスターシードを流出させるDark Skippyという新しい攻撃手法が最近公開された↓ https://darkskippy.com/ 悪意ある署名デバイスによる攻撃 Dark Skippyも、ハードウェアウォレットのような署名デバイスで悪意あるファームウェアが実行された場合の攻撃手法の1つ。このような状況は、 署名デバイスが改竄され、悪意あるファームウェアがロードされる ユーザーが騙されて悪意あるファームウェアをインストールする サプライチェーン攻撃により、悪意あるデバイスを購入してしまう といった原因で発生する可能性がある。 ハードウェアウォレットが侵害されている状態では、これまでも以下のような種類の攻撃が実行される可能性がある。 所定のシード攻撃 署名デバイスが攻撃者が設定した所定のシードフレーズを出力する攻撃。実際にTREZORに似せた偽のウォレットで、こ
MATT(Merkleize All The Things!)は、BitcoinのようなUTXOモデルで汎用的なスマートコントラクトを構築しようという提案の1つ↓ https://merkle.fun/ Taprootを利用したステートへのコミット EVMのようなステートツリーを持たないBitcoinで唯一管理されるステートはUTXOセットのみ。汎用的なスマートコントラクトを実現する場合、コントラクトのステートを管理する必要がある。 MATTでは、コントラクトのステートをマークルツリーで表現し、そのコミットメントをTaprootのアウトプット(P2TR)に含めるようになっている。(EVMノードがフルステートを管理しなければならないのに対し、MATTの場合ステートへのコミットメントのみが間接的にオンチェーンで管理されることになる。) ステートのマークル化 コントラクトの各ステートは、マークル
IONはMSが中心になって開発したDIDのプロトコルの1つ(did:ion)。実体は、アンカリング先のブロックチェーンにBitcoin、Content-Addressed Storage System(CAS)ノードにIPFSを用いたSidetreeプロトコルになる。この他にアンカリング先をEthereumにしてSidetreeを実装したElement(did:elem)とか、他にもFabricやAmazon QLDB、S3を使った実装もあるみたい。 今回は、そんなION(正確にはSidetree)で発行されるDIDを実際に作ってみる。 DIDの作成 Sidetreeでは、以下の3つの鍵ペアを生成する。 署名鍵:DID自体に関連付けられるメインの鍵で、DIDのユースケースにおける署名や認証に用いる鍵。 Update Key:DIDの更新とUpdate Key自体の更新に使用する鍵。 Rec
Ethereum 2.0のロードマップがだいぶ変わっていたので、久しぶりに調べてみた↓ https://tim.mirror.xyz/CHQtTJb1NDxCK41JpULL-zAJe7YOtw-m4UDw6KDju6c https://tim.mirror.xyz/sR23jU02we6zXRgsF_oTUkttL83S3vyn05vJWnnp-Lc https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer/ Ethereum 2.0とその変遷 2018年に発表されたEthereum 2.0のロードマップは、シャーディングによりEthereumのスループットを向上させるのが目的で、3つのフェーズで構成されていた。 最初のフェーズ0では、PoSベースのBeacon chainを導入する。 続くフェーズ1では、デ
japan.zdnet.com こんなニュースもあり、バックドアと言えばエドワード・スノーデンの告発でも話題になったNSA(米国家安全保障局)のバックドアを思い出した。当時は仕組みについて調べてなかったけど、どんな仕組みのバックドアだったのか今になって気になったので調べてみた。 Dual_EC_DRBG バックドアが仕込まれていたのは、NSAの推奨により一度は標準として採用された擬似乱数生成器のアルゴリズムDual Elliptic Curve Deterministic Random Bit Generator(Dual_EC_DRBG)。で、2006年にNIST SP800-90Aに組み込まれ、2013年に利用すべきではないと勧告されている。 Dual_EC_DRBGの仕様 Dual_EC_DRBGは、生成したシード値から、2つの楕円曲線上の点を使って、多数の乱数を生成する擬似乱数生成
Scaling Bitcoin 2019予習シリーズ第4弾は、カリフォルニア大学の「SeF: A Secure Fountain Architecture for Slashing Storage Costs of Blockchains」。ホワイトペーパーは↓ https://arxiv.org/pdf/1906.12140.pdf ブロックチェーンのフルノードはジェネシスブロックから始まる全てのブロックチェーンのデータをスタンドアロンで検証し、保存する唯一のノードだ。一方ブロックチェーンはチェーンが伸びるに連れてデータも成長していく。フルノードの消費リソースとしては署名検証のためのCPUリソース、ネットワーク帯域、ストレージ容量などがあるが、今回フォーカスするのはこの内のストレージコストについて。現在Bitcoinのブロックチェーンのデータは全体で215GBを超え、そのうちUTXOセッ
最近また自称サトシが登場してるみたいだったので、自称サトシになるために必要なことを調べてみた。 ecdsa - If someone wanted to pretend to be Satoshi by posting a fake signature to defraud people how could they? - Bitcoin Stack Exchange 自称サトシになるには? BitcoinのGenesis Block↓のコインを移動することができれば、それは自称ではなく間違いなく本物のサトシだが、 https://en.bitcoin.it/wiki/Genesis_block 自称サトシが証明として提供しているのは、Genesis Blockのコインの送金先である公開鍵 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a6
ECDSAの署名からどうして公開鍵が取得できるの?という聞かれて何でだろうねって話になったので調べてみた。 署名から公開鍵のセットを復元 Rubyではecdsaのgemを使えば以下のように署名と署名対象のメッセージから公開鍵を取得できる。(署名対象のメッセージはどうせなのでBitcoinで使用されているのと同じトランザクションのsighashを使用。そのためbitcoinrbのgemも利用している) 実行すると↓のように2つの公開鍵が抽出できる。 0259f6658325c4e3ca6fb38f657ffcbf4b1c45ef4f0c1dd86d5f6c0cebb0e09520 03a9255e098f4075e9ebfaf7859f459095667879db33e977fc8c91029afa8a2490 ↑のコード上の署名はこの内の0259f6658325c4e3ca6fb38f65
SchnorrのBIPドラフト↓ https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki に応用例の1つとして記載されているのが、Scnorr署名とペダーセンの検証可能な秘密分散法を利用してm-of-nのマルチシグを構成するというもので、参照論文↓ https://t.co/jMhQnovLcb をざっと読んで、どう構成なのか見てみる。 前提技術 まず、前提となる暗号技術として、以下のシャミアの閾値法、ペダーセンの検証可能な秘密分散法などについておさえとく。 以下、楕円曲線の離散対数問題を利用するため、qを巨大な素数とし、GとHを楕円曲線Eの位数qのサブグループのジェネレータ、h()を一方向ハッシュ関数とする。 シャミアの(t, n)閾値法 ベースとなるプリミティブの1つが(t, n)閾値法。これはディーラーが
LNではHTLCを使って仲介者を経由したマルチホップ決済を可能にしている。例えばアリス→キャロルのオフチェーン決済をボブとマイクを経由して行うケースでは以下のような決済フローになる。 最初に受信者のキャロルがランダムな値Rとそのハッシュ値H(R)を生成し、H(R)をアリスに渡す(invoice)。 アリスはキャロルまでの経路を決め、H(R)とタイムロックを組み合わせたHTLCトランザクションをボブとのペイメントチャネルに投げる。 仲介者はさらに経路上の隣のユーザーにHTLCを流していく。 キャロルまでHTLCが届いたら、マイクにRを明かして資金を受け取る。 今度は逆方向に終着点アリスまでRと交換に資金をセトルメントしていく。 ここでタイムロックとシークレットを組み合わせたHTLCは、以下のような条件を持つコントラクト(↑のアリスとボブで考えた場合) 3日経過する前にボブがハッシュを取るとH
Lightining Networkとの連携も含めた、「RGB」というBitcoinベースの新しいデジタルアセットプロトコルが発表された↓ github.com RGBのプロトコル仕様は、現状以下の5つのモジュールに分かれている。 RGB プロトコルのコアおよび低レベルのアセットロジックを定義。 Kaleidoscope 他のモジュールを包括しプロトコルとして相互作用するための高レベルの機能を定義。 Bifröst クライアントサイド検証の枠組みのプルーフの保存と公開について定義。 Lighting Network Integration RGBをLighting Networkに適用する(アセットに対応したルーティング、チャネルの更新、クローズなど)ために必要なBOLTの拡張などを定義。 Proofmarshal アセットに特化した形で、スケーラビリティとプライバシーを向上させる、Lig
Bitcoinのトランザクションに署名する際の、署名のスコープの仕様について読んでみる。 SIGHASHの種類 https://bitcoin.org/en/developer-guide#signature-hash-types OP_CHECKSIGが各署名から非スタック引数を抽出し評価することで、署名者はトランザクションのどの部分に署名するか決めることができるようになる。署名によりトランザクションの一部を変更から保護することで、他のユーザが自分のトランザクションを変更できるようにすることができる。 どのように署名するかはsignature hash typesと呼ばれるオプションで定義されている。現在は以下の3つの基本的なSIGHASHが利用可能。 SIGHASH_ALL (デフォルト)全ての入力と出力に署名し、署名スクリプトを除く全ての変更から保護する SIGHASH_NONE 全
Bitcoinアドレスは秘密鍵から計算した公開鍵を使って生成されるが、そのアドレスの種類は複数(P2PKH、P2WPKH、P2SHでネストしたP2WPKH)ある。いずれも同じ秘密鍵から生成可能なアドレスだが、実際にウォレットで使ってるアドレスはそのうちのどれか1つ。ただ、現在のWIF(Wallet Import Format)形式の秘密鍵では、どの種類のアドレスに関連付けられた秘密鍵なのか示すデータが存在しないので、それをわかるようにWIFフォーマットを拡張しようとBIP-178が提案された。 https://github.com/bitcoin/bips/blob/master/bip-0178.mediawiki ただほとんどのユーザーはHDウォレットを使っており、どのアドレスを導出するかはその導出仕様(BIP-44、BIP-49、BIP-84)で定義されているため、ユーザーが個別の秘
先日書いたECDSA版Scriptless Scriptsのベースとなっている署名スキームについて↓ techmedia-think.hatenablog.com 実際に2-of-2のマルチシグをScriptless Scriptsで実現するためのRubyのコードを書いてみた(仕組みについては↑の記事参照)。 事前準備としてbitcoinrbと、Paillier暗号を扱うpaillierのgemをインストールしておく。 ロックスクリプト 通常、Bitcoinスクリプトで2-of-2のマルチシグを利用する場合 2 <公開鍵1> <公開鍵2> 2 OP_CHECKMULTISIG というscriptPubkeyにコインをロックするが、Scriptless Scriptsの場合はスクリプトを使用しない(正確には署名検証だけ行う)ので、マルチシグを構成する二者間の公開鍵に資金をロックする形になる。
Scaling Bitcoin 2017のFlyClientの内容を追っていったら前提としてNiPoPoWs(Noninteractive-Proofs-of-Proof-of-Work)→ PoPoWs(Proofs of Proof of Work)と関連研究が続くので、まず最初にProofs of Proof of Workのプロトコルについて調べてみる。 Proof of Workの検証 Bitcoinのブロックチェーンでフルノードはジェネシスブロックから全てのブロックをダウンロードし、そのProof of Workが正しいか検証をすることで正しいチェーンであることを確認する。接続先のノードが偽の情報を流すことも考えられるため、複数のノードと接続し、接続先のノードによって異なるブロックチェーンが返ってくるケースでは、よりProof of Workが行われている方(長いチェーン)を正
トラストレスな双方向のオフチェーン決済を可能にするペイメントチャネルだが実用に向けてはまだ課題も多い。 techmedia-think.hatenablog.com 課題の1つにペイメントチャネルのキャパシティ(=チャネル内で決済できる金額の上限)が固定されている点がある。このためキャパシティを超える金額を送金したい場合や、2者間のチャネル決済において片一方に全ての資金が渡った後にさらに決済したい場合には、一度チャネルを閉じて、大きめのキャパシティや追加の資金を投入して新しいペイメントチャネルを構築する必要がある。チャネルを閉じて再度チャネルを開くということはクローズとオープンの2つのトランザクションをブロックに入れるためにブロードキャストする必要があり、当然各トランザクションには手数料が必要になる。 またキャパシティ以外にも取引相手のノードがクラッシュしたりオフラインになると、最終残高の
Bitcoinのブロックヘッダにはブロックに入っているトランザクションのリストにコミットするため、各トランザクションのTXIDをリーフノードにしたマークルツリーを構築し、そのマークルルートの値が入れられるようになっている。ブロックにどれだけたくさんのトランザクションが含まれていても、それらから計算されるマークルルートは32バイトの固定値で、その固定値が全てのデータセットのコミットメントになる、とても空間効率の良いデータ構造で、ブロックヘッダのマークルルート以外にも様々な使い方が提案されている。 このマークルツリーの構造の改良について、Fast Merkle Treeという新しい提案(BIP-98)が公開され↓ https://github.com/bitcoin/bips/blob/master/bip-0098.mediawiki ↓のような特徴がある。 パフォーマンスの向上 リーフノー
Atomic Swapといえば同じハッシュ関数とタイムロックの仕組みを持つブロックチェーンであれば、それぞれのチェーンの通貨をトラストレスに交換することができるプロトコルで、最近だとBitcoinやLitecoin、BitcoinとEthereumでAtomic Swapの事例が出てきている。 ハッシュのプリイメージとタイムロックの仕組みを使ったこのプロトコルの詳細は↓ techmedia-think.hatenablog.com このプロトコルでは、各チェーンで以下のようなスクリプトにコインをロックしている。 IF 2 <アリスの公開鍵> <ボブの公開鍵> 2 CHECKMULTISIGVERIFY ELSE HASH160 <H(x)> EQUAL <ボブの公開鍵> CHECKSIGVERIFY ENDIF ↑はBitconのスクリプト言語だが、Ethereumでは同様の機能を持つCo
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の量, '送
OpenSCにマイナンバーカード(JPKI)の対応がマージされていたので、OpenSCを使ってマイナンバーカードの登録情報を確認してみる。 github.com 使用したカードリーダーは↓でMacでも認識できた。 amzn.to カードに登録されているオブジェクトのリスト確認 まずカードに登録されているオブジェクトを確認してみる。 $ pkcs15-tool --dump Using reader with a card: Gemalto PC Twin Reader PKCS#15 Card [JPKI]: Version : 0 Serial number : 00000000 Manufacturer ID: JPKI Flags : PIN [User Authentication PIN] Object Flags : [0x12], modifiable ID : 01 Fla
通常のP2PKHやP2WPKHで決済をする分には特に関係ないが、P2SHベースのマルチシグやコントラクトなどで複数のユーザーによる署名が必要な場合、ユーザー間でトランザクションをやりとりしながら、各自署名を付与し、最終的にブロードキャスト可能なトランザクションを作成する必要がある。 この部分はブロックチェーン外で行われるけど、どういうフォーマットで途中のトランザクションをやり取りするかなどは、ウォレットやサービスによってそれぞれ異なる。標準仕様がないため、当然ウォレットが違えば互換性が無いのがあたり前だが、そういう部分的に署名されたトランザクションのフォーマットを標準定義しようというのが最近追加されたBIP-174↓ https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki ※ BIPが結構更新されてたので2020/01/
Bitcoin決済をしたことを証明する支払いの証明(Proof of Payment)方法について定義しているのがBIP-120↓ https://github.com/bitcoin/bips/blob/master/bip-0120.mediawiki Bitcoinによる支払いが行われたことを条件にサービスなどを提供するケースって結構あるんじゃないかなー。 (BIP-120自体はコンセンサスなどとは無関係なApplicationsレイヤーのBIPなので、デプロイなどは無い。) 動機 支払いの証明(Proof of Paymant = PoP)を利用することで以下のようなユースケースが考えられる。 ホテルなどで既に料金を支払っている場合に、そのPoPがドアの鍵になる。 オンラインのビデオサービスでビデオの代金を支払っていれば、どのデバイスでも視聴できる。 事前に支払い済みの広告。広告の
以前BIP-32の階層的決定性ウォレットについて書いたけど↓ techmedia-think.hatenablog.com このHDウォレットの階層を論理的に定義したBIP-44についてみてみる↓ https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki 動機 このBIPで提案している階層構造はとても包括的で、複数のコイン、複数のアカウントの管理に加え、アカウント毎に内部チェーン・外部チェーン、チェーン毎に何百のアドレスを管理できるようになる。 Path level このBIPでは、BIP-32のパスを以下の5つのレベルで定義する。 m / purpose' / coin_type' / account' / change / address_index ↑のアポストロフィー(')は、BIP-32の強化鍵を使用することを示
ブロックサイズを拡張について、データ量が多くなるためデータを転送する際により高いネットワーク帯域が求められるようになり、ハッシュパワーの集中が促進するのではないかという懸念がある。 より高速なリレーネットワークを活用することで、この問題を解消できるのではないかということで、Matt CoralloによりFIBRE(Fast Internet Bitcoin Relay Engine)というパブリックに利用可能なBitcoinの高速リレーネットワークが2016年7月に発表されている↓ http://bitcoinfibre.org/ 簡単に言うと、TCPだと長距離伝送する際のパケットロスが発生し、パケットの再送が必要になりネットワークの往復によるスパイクが発生するので、FEC(前方誤り訂正)のあるUDPを使って受信側のピアがロスしたパケットについて送信元に再度リクエストするのではなく、受信済
Lightning Networkのホワイトペーパーを書いたThaddeus DryjaがこないだDiscreet Log Contracts(直訳すると離散対数コントラクト?)というホワイトペーパーを公開していたので↓見てみる。 https://adiabat.github.io/dlc.pdf アブストラクト スマートコントラクトはよくBitcoinのような暗号通貨のシステムで目にするが、金融分野ではまだ広く使われていない。スマートコントラクトを実装、採用にするにあたって、最大のハードルは、スケーラビリティと通貨に関する外部データをスマートコントラクト内から取得する難しさにある。これまでコントラクトのプライバシーは別の問題だった。Discreet Log Contractsは、スケーラビリティとプライバシーの問題に対処し、外部データを提供するオラクル*1への信頼を最小限に抑えるシステム
長編のBIPで斜め読みしてたので、ちゃんと読んでみる。 bips/bip-0032.mediawiki at master · bitcoin/bips · GitHub 概要 このBIPでは階層的決定性ウォレット(HDウォレット)について説明する。 この仕様では、異なるクライアント間で交換可能な決定性ウォレットの標準化を目的としている。ここで説明するウォレットにはたくさんの機能があるが、クライアントに全ての機能のサポートを要求するものではない。 仕様は2つのパートで構成される。最初のパートで、単一のシードからキーペアのツリーを導出するためのシステムについて説明する。続くパートで、その構造を使ってウォレットを構築する方法を説明する。 動機 Bitcoin Core(Bitcoinの参照クライアント)は、ランダム生成されたキーを使用する*1。トランザクションのブロードキャスト後に毎回鍵のバッ
Bitcoinのトランザクションは10分に一度作成されるブロックに取り込まれる。最近のメモリプールの状況では10分後に取り込まれればラッキーな方で、まだ時間がかかることもよくあると思う。 その一方でECサイトや実店舗でのBitcoin決済の導入は進んでいる。リアルな店舗で決済する際に10分以上待たされてはBitcoinを使って決済しようとは思えないから、こういった店舗では、決済するトランザクションがブロードキャストされれば決済されたと判断しトランザクションがブロックに取り込まれるまで待たずに決済をしている。つまに未承認のトランザクションで決済している。 この場合、もし二重使用が発生すると店舗側は決済した金額を受け取れない事態が発生する。まぁその辺のリスクを考慮してBitcoin決済ができるのはある一定額までで、そういう事態が発生した場合は決済会社が保証などしているのだと思う。 そんな未承認
取り下げられたSegwitのアドレスフォーマットを定義したBIP-142↓ techmedia-think.hatenablog.com に変わって、新しい仕様でSegwitのアドレスフォーマットを定義したBIP-173が登録されてたので見てみる↓ bips/bip-0173.mediawiki at master · bitcoin/bips · GitHub イントロダクション 概要 このBIPでは、チェックサムが付与されたBase32フォーマットBech32と、Bech32を使ったsegwitのネイティブ出力(P2WPKHとP2WSH)のアドレスの標準について定義している。 Copyright このBIPは二条項BSDライセンス下にある。 動機 これまでBitcoinは、ダブルSHA-256をトランケートしたチェックサムを付与したBase58アドレスを使ってきた。BIP-13で定義さ
Blockstreamが新しくConfidential Assetsなる機能をリリースしていたので、どういったものなのか見てみる。 blockstream.com Open Assets ProtocolやCounterpartyやColuなどBitcoinのブロックチェーン上で、Bitcoin以外のアセットを発行・送付するプロトコルが登場しているように、同じチェーン上で複数のアセットタイプをサポートするのはブロックチェーン技術の自然な進化と考えられる。複数のアセットタイプが同一のチェーンで扱えることで、それぞれのアセットタイプで同じチェーンのセキュリティ特性を共有可能になり、マルチアセットのアトミック・スワップのような新しいユースケースが可能になる。 複数のアセットタイプをサポートするには、各トランザクションの出力にasset tagをラベル付けするだけで実現できるが、この場合ユーザがそ
次のページ
このページを最初にブックマークしてみませんか?
『Develop with pleasure!』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く