クラウド開発環境の標準化を図るために、Google Compute Engine（GCE）を利用した開発用VMを構築した。 https://github.com/YusukeShimizu/vm-infra Mac（特にMxチップ）でビルドが困難なソフトウェアを扱う際、Linuxアーキテクチャ向けバイナリが前提となるケースが多い。そこで、専用のGCE環境をTerraformでコード化し、以下の利点を得た。 もともと https://github.com/Blockstream/greenlight のdockerが動かないことが作成したきっかけである。 blockstreamのproductはlinuxアーキテクチャ向けに開発されており、Mac上でのビルドが難しいことが多い。 GCE開発環境の主な利点 リソースの動的な調整 e2-standard-4（vCPU 4コア、メモリ16GB）などの強力なマシンを短時間で立ち上げ可能。開発の進捗や負荷に応じてスケーリングを柔軟に行う。 統一された開発環境 チーム全体で同一環境を利用し、「自分の環境では動く」問題を回避する。新規メンバーが加わった場合でも、同一の手順でVMを構築できる。 セキュアなアクセス SSH接続とIPアドレス制限を組み合わせ、堅牢なセキュリティを実現する。ソースコードや秘匿情報を安全に管理できる。 開発環境の特徴 Ubuntu 22.04 LTSベース Git、Docker、GitHub CLIなどの主要ツールをプリインストール Terraformでインフラをコード管理し、再現性を確保 VSCodeのRemote-SSHを用いたスムーズな開発体験 セットアップ手順 リポジトリのクローン Terraform構成管理用リポジトリ（例: vm-infra）を手元にクローンする。 環境変数の設定 .env ファイルを用意し、プロジェクト名やGCP認証情報などを定義する。 Terraformの実行 Terraform init → plan → apply でGCEインスタンスを自動構築する。 VSCodeでのリモート接続 Remote-SSH機能を使い、構築したGCEインスタンスへ接続。ローカルと同等の操作性が得られる。 運用上のポイント 環境変数とシークレットの安全管理 .envファイルやGoogle Cloud IAMを活用し、認証トークンや機密情報を外部に漏らさない。 コードによるインフラ運用 Terraformで定義した構成を共有し、イミュータブルな環境を維持する。トラブル発生時にも再構築が容易。 スケール調整による効率化 ビルド負荷が高いときはvCPU数を増やし、不要になれば小さいマシンへ切り替える。リソースを最適化することでコスト削減にもつながる。 まとめ Mac上で動作が難しいソフトウェアを扱う際、GCE上にLinux開発環境を構築する手法は有効である。Terraformでコード化することで環境の再現性が高まる。さらにVSCodeのRemote-SSHによる使い慣れたIDE操作を維持できる。

wallet revoveryの仕組みを改めてまとめたが、これを非エンジニアがすべて理解することは困難に感じられる。 そこで、下記のようなサービスを考えた。もし興味があれば連絡してみてほしい。 Bitcoinウォレット復旧サポートサービスのご案内 「昔作ったBitcoinウォレットの残高が取り出せない」「Seedは持っているけれどウォレットを再設置できない」といったお悩みをお持ちの方をサポートするサービスです。 当サービスでは、お客様がお持ちの**Seed（または拡張公開鍵）**をもとに、どのウォレットソフトで利用されていたかなどをヒアリングし、最適な手順で残高を復旧いたします。 サービスの特徴 安心・安全な運用 可能な限り「秘密鍵（Seed）を当方に預けず」に済む方法をご案内します。 お客様自身の環境で生成していただく**拡張公開鍵（xpub, ypub, zpubなど）**から、まずはウォッチ専用（完全に閲覧のみ）の形で、残高やトランザクションの確認のサポートを行います。 実際に送金を行う際は、お客様が秘密鍵をお持ちのウォレット上で署名を行えるよう、手順を丁寧にサポートいたします。 豊富なウォレット形式に対応 レガシーアドレス（P2PKH、1xxxx） ラップドSegWit（P2WPKH-in-P2SH、3xxxx） ネイティブSegWit（P2WPKH、bc1q系） Taproot（P2TR、bc1p系） BIP44/49/84/86など、複数の派生パスでのスキャン・復旧にも対応します。 スキャンによる漏れの防止 お客様が長期間多数のアドレスを発行していた場合でも、recoveryWindow（アドレス探索の範囲）を適切に設定することで、できる限り「取りこぼし」のない復旧を目指します。 過去の取引履歴を追跡し、未使用アドレスや高インデックスのアドレスも丁寧にチェックします。 明朗な手数料 復旧に成功した金額（=回収できたBitcoinの総額）の**10%**をサービス手数料としていただきます。 事前の調査やお見積りの段階で、復旧作業の流れや必要となるステップ・セキュリティ対策を分かりやすくご説明します。 ご利用の流れ お問合せ・事前ヒアリング まずは、ウォレットの使用状況（使用していたアプリ名、保有しているSeedの状態など）を簡単にお知らせください。 「Seedしか分からない」「拡張公開鍵をエクスポートできるか分からない」などの状況でも、分かる範囲で情報をお伝えください。 ウォッチ専用での残高・取引確認 秘密鍵（Seed）を共有いただく前に、まずはお客様が独自に生成した拡張公開鍵（xpub / ypub / zpub など）をお預かりし、ウォッチ専用の状態で、使用された可能性のあるアドレス一式を確認・スキャンします。 見つかった残高・取引の状況をご報告いたします。 最終的な復旧手続き 実際にビットコインを新規の安全なウォレットに移動させる場合、署名用の秘密鍵（Seed）が必要になります。 お客様自身のウォレットにて署名していただく方法をご案内するため、当方が秘密鍵を「預からない」形での復旧を推奨しています。 作成したトランザクション（PSBTなど）をお客様側で署名・実行していただき、復旧を完了します。 お支払い（手数料10%） 復旧した金額の10%を当方にお支払いいただきます。 実際の金額や送金方法、支払いタイミングなどは事前に合意を取った上で進めます。 セキュリティとプライバシーへの配慮 秘密鍵の取り扱い 可能な限り当方が秘密鍵（Seed）を受け取らなくても作業ができる仕組みを整えております。 スキャン情報の扱い 残高・取引状況の調査は、原則としてお客様から頂いた情報のみに基づいて行い、業務完了後は当方でも不要となったデータは責任を持って破棄します。 よくあるご質問 Q1. Seedしか分からず、ウォレット名が分かりません。大丈夫でしょうか？ A. 問題ありません。BIP44/49/84/86に準拠した複数の派生パスを試し、残高を網羅的にスキャンすることで復旧を試みます。 Q2. 途中でキャンセルすることはできますか？ A. 可能です。ただし、当方がすでに行ったスキャン作業に相応する調査費をいただく場合がございます。利用規約をご確認ください。 Q3. 復旧後、また同じようなトラブルになりたくありません。追加で学ぶ機会はありますか？ A. ウォレットのセキュリティやバックアップ方法などのご相談・教育サービスも別途ご案内しております。お気軽にご相談ください。 お問合せ メール: bruwbird@gmail.com

この手のフレームワークは無限にあり、なんでも良いと思うが、いくつか引き出しに入れておくことは重要だと感じている。 序論 認知思考の拡張および深化を実現する方法論として、カリフォルニア大学教育学部研究チームによって開発されたQ-Matrix（質問マトリクス）が注目されている。本フレームワークは36種類の質問パターンを体系化し、認知プロセスの段階的発展と分析的思考の向上に寄与することが実証されている。多様なフレームワークが存在する認知発達領域において、Q-Matrixは比較的単純な構造ながら高い汎用性を有する思考ツールとして位置づけられる。 Q-Matrixの定義と機能 Q-Matrixは、テキスト分析における表層的事実の把握を超え、因果関係、将来的展望、システム的影響などの多層的理解を促進する構造化フレームワークである。情報の整理・分類機能に加え、認知構造の体系化および議論の多角的展開を可能にする分析ツールとして機能する。 実装方法論 Q-Matrixの実装プロセスは以下の段階で構成される： テキスト分析と要約 対象テキストの中心概念および主要要素を客観的に抽出し、体系的に整理する作業を行う。 マトリクス構造の理解 6つの疑問詞（Who/What/Where/When/Why/How）と6つの助動詞（is/did/can/would/will/might）の掛け合わせにより生成される36のセルから成る基本構造を把握する。 質問生成プロセス テキストの論点に基づき、事実確認レベルから推論・予測レベルまでの段階的質問を生成する。 複雑性レベルの階層化 質問を以下の認知的複雑性に基づき分類する： レベル1: 事実確認（記憶・再生レベル） レベル2: 因果関係分析（理解・解釈レベル） レベル3/4: 仮説構築・予測（評価・創造レベル） 総合分析フレームワークの構築 生成された質問群を用いて対象テキストまたは課題の構造的かつ多角的分析を実施する。 マトリクス構造 Q-Matrixの基本構造は以下の表に示される： 時間/視点 何？ いつどこで？ どれ？ 誰？ なぜ？ どのように？ 現在 #1 (レベル1) ・〜は何か？ ・〜の意味はなんだろうか？ ・〜との違いはなんだろうか？ #2 (レベル2) ・いつだろうか？ ・どこだろうか？ #3 (レベル3) ・〜はどれなのか？ ・〜はどれにするのか？ ・〜の長所と短所はどのようなものだろうか？ #4 (レベル1) ・誰がするのだろうか？ ・誰がしているのだろうか？ ・誰にしているのだろうか？ #5 (レベル2) ・なぜそうなのか？ ・〜が重要なのはなぜだろうか？ #6 (レベル3) ・どのようにしてそうなるのか？ ・どのような仕組みなのだろう？ ・〜と〜はどのように似ているのだろうか？ 過去 #7 (レベル1) ・何をしたのか？ ・〜はなんだったか？ ・昔はどうだったのだろうか？ #8 (レベル2) ・いつだっただろうか？ ・どこだっただろうか？ #9 (レベル3) ・〜はどれだったのか？ ・〜はどれにしたのか？ ・〜の長所と短所はどのようなものだっただろうか？ #10 (レベル1) ・誰がしたのだろうか？ ・誰にしたのだろうか？ #11 (レベル2) ・なぜそうなったのか？ ・〜が重要だったのはなぜだろうか？ #12 (レベル3) ・どのようにしてそうなったのか？ ・どのような仕組みだったのだろう？ 可能性 #13 (レベル1) ・何ができるだろうか？ ・〜について最良なものはなんだろうか？ #14 (レベル2) ・いつできるだろうか？ ・どこでできるだろうか？ #15 (レベル3) ・どれができるのだろうか？ ・ほかの可能性はないだろうか？ #16 (レベル1) ・誰ができるのだろうか？ ・誰ができたのだろうか？ #17 (レベル2) ・なぜできるのだろうか？ ・なぜできたのだろうか？ ・〜が最良かもしれないのはなぜだろうか？ #18 (レベル3) ・どのようにできるのか？ ・どのようにできたのか？ 予測 #19 (レベル1) ・何がありえるか？ ・〜を解決するかもしれない方法はほかに何があるだろうか？ ・〜は〜に、どんな結果をもたらすだろうか？ #20 (レベル2) ・いつありえるか？ ・どこでありえるか？ #21 (レベル3) ・どれならありえるのだろうか？ ・ほかを選んだらどうなるだろうか？ #22 (レベル1) ・誰ならありえそうか？ ・誰ならありえたのか？ #23 (レベル2) ・なぜありえるのだろうか？ ・なぜありえたのだろうか？ #24 (レベル3) ・ほかの方法を使うとどうなるだろうか？ ・〜は、以前に学んだことや習ったことと、どのように関連しているだろうか？ 意図 #25 (レベル1) ・何をしたいのだろうか？ ・〜の意味はなんだろうか？ ・〜について、よく知っていることと、知らないことはなんだろうか？ #26 (レベル2) ・いつしたいのか？ ・どこでしたいのか？ ・時間と場所についてどうしたいのか？ #27 (レベル3) ・どの選択をしたいのだろうか？ #28 (レベル1) ・誰がしたいのか？ ・〜を誰と関係させたいのか？ #29 (レベル2) ・〜をしたいのはなぜか？ #30 (レベル3) ・〜をどのようにしたいのだろうか？ ・〜のために、〜をどう使うことができるだろうか？ 想像 #31 (レベル1) ・もし〜になったら、何が起きるだろうか？ ・〜と〜を比べたらどうなるだろうか？ #32 (レベル2) ・もし時間と場所が〜になったらどうなっただろうか？ #33 (レベル3) ・もし〜を選んだらどうなるだろうか？ #34 (レベル1) ・もし（人名）が関わったらどうなるだろうか？ #35 (レベル2) ・もし〜が原因だったらどうなるだろうか？ ・〜に賛成だろうか、それとも反対だろうか？ #36 (レベル3) ・もしほかの手段をとったらどうなるだろうか？ ・もしかが変わったらどうなるだろうか？ 理論的考察と応用 Q-Matrixの理論的基盤は以下の要素から構成される： ...

https://www.ben-evans.com/benedictevans/2024/5/4/ways-to-think-about-agi の翻訳。 llmを使い、かなり意訳している。 AGI の考え方 背景と目的 汎用人工知能（AGI）が実現すれば、あらゆる作業の自動化にとどまらず、人類の知的活動に深い変革をもたらす。たとえばコンピュータ小説『A Logic Named Joe』（1946年）では、あらゆる疑問に対して瞬時に答えを返す “ロジック” が描かれた。技術的には未確定だが、実現した場合の社会的影響は極めて大きい。 過去の興奮と失望 AI 研究の歴史では、定期的に「ブレイクスルーが近い」との期待が高まっては失望に終わり、多くの学者や専門家が当初の予測を外してきた。1970 年代の AI ブームや、繰り返し訪れた “AI ウィンター” がそれを象徴する。理論的には「数年で人間並みの機械知能が生まれる」との意見もあったが、実際は多くの未知の問題が残されていた。 不確実性の本質 AGI がいつ、どのように実現するかは誰も正確に知らない。専門家の間でも意見は割れる。LLM（大規模言語モデル）がスケールして AGI に到達する可能性はあるが、多くの未知のブレイクスルーが必要だという見方もある。根本にあるのは「知能が本質的に何であるか」という問いへの答えがまだ得られていない点であり、神学や哲学に似た議論が繰り返されている。 悲観論か楽観論か AGI による “人類滅亡” シナリオを懸念する専門家もいる。一方、AI 技術はただのソフトウェアと見る向きもある。既存の自動化が社会や産業を変えたように、AGI も新たなインパクトを与える可能性が大きい。しかし、起こりうるリスクをすべて排除することは難しい。オープンソース化が進む現状では、たとえ規制をかけても世界中で並行して開発が進むだろう。 具体例と類推 AGI のリスクを核分裂や隕石衝突になぞらえる議論もある。しかし、これらは一度起きれば確実に破滅をもたらす自然現象であり、ソフトウェアとは性質が異なる。ソフトウェアは災厄を起こす潜在力がある一方で、多大な恩恵をもたらす道具でもある。20 世紀から進行してきた自動化の多くは労働構造を変えたが、同時に多大な利便性も生んできた。 月ロケットにたとえる視点 アポロ計画では、重力とロケット工学の理論が確立していたために「ロケットを大きくすれば月に行ける」と計算で導けた。しかし、現在の AI には対応する理論モデルが存在せず、なぜ LLM が機能するのかさえ十分に分かっていない。それでもモデルは拡大し続け、何かに到達しつつあるように見える。だが、その到達点が本当に「人間を超える知能」なのかどうかは未知数である。 結論 AGI が真に実現するかどうか、あるいはいつ実現するかは確証を得られていない。悲観的なリスクを示唆する見解と、楽観的な技術開発論が同時に存在する。すべては「知能が本質的に何であるか」という未解明の問いに依存する。実現すれば大きな恩恵をもたらす可能性がある一方、取り返しのつかない被害をもたらすかもしれない。この不確実性こそが AGI 論の核心である。 人工知能 Benedict Evans 2024年5月4日

https://mastra.ai/blog/mastra-mcp からのllmを用いた意訳である AI エージェント向けツール統合の現状は混沌としている。「MCP Calendar integration」の検索結果からも明らかなように、どの実装が最適かを判断する統一基準がない。ツールの発見、インストール、設定は未解決の課題である。 Mastra では、この問題に取り組み、Anthropic の Model Context Protocol (MCP) が エージェントとツールの相互作用の将来 であると確信している。 競合する標準規格 現在、複数のアプローチが競合している： Agents.json (Wildcard) Agents.jsonは OpenAPI を拡張し、LLM 向けに API 相互作用を最適化する。開発者向け API と LLM 用 API の乖離に対処し、既存 API に文脈情報を補完する。 Composio Composioは独自仕様と豊富な統合ライブラリを提供している。最近はMCP サポートも追加し、選択肢を広げた。 Model Context Protocol (MCP) MCPは Anthropic 管理のオープンスタンダードであり、OSS コミュニティの協力で構築されている。AI アプリケーションの「USB-C ポート」として、LLM を外部ツールに接続する標準インターフェースを提供する。 MCP の課題 MCP エコシステムの主な課題は3つある： Discovery: ツール発見のための標準化された方法がない Quality: 集中管理されたレジストリや検証プロセスがない Configuration: 各プロバイダーが独自の設定スキーマを持つ Shopify CEO の Tobi Lütke はMCP を「LLM ツールの USB-C」と表現しつつも、まだプロトコルだけで「プラグ」が欠けていると指摘している。 コミュニティは Official Registry や .well-known/mcp.json などの規格で問題解決に取り組んでいる。 ...

mnemonic seedを保持していれば、ウォレットの残高をリカバリーできる。これは一見不思議だが、実際には無限に生成可能なアドレス（script pubkey）のうち、使用されたものだけを検出し、UTXOを取得する仕組みがあるためである。どのアドレスが使われたかを追跡できるからこそ、seedを頼りに残高を復元できる。 しかし、mnemonic seedを持っているのに残高が正しく復旧しないケースも存在する。また、レガシーSegWit（P2SHアドレス・3xxxx）の潜在的な危険性は誤解を生みやすい。これらを整理するために、btc walletの実装（https://github.com/btcsuite/btcwallet）を例にしながら、BIP0044/49/84/86が規定するHDウォレット構造と、ウォレットのリカバリー方法を示す。 BIPの概要と相互関係 BIP0044、BIP0049、BIP0084、BIP0086はいずれもHDウォレットの「目的（purpose）番号」を定義し、各アドレス形式を区別している。以下、それぞれの要点をまとめる。 BIP44 概要: m/44'/coin_type'/account'/change/address_index の構造を規定する汎用的HDウォレット標準。 用途: レガシーP2PKH（1xxxx）アドレスに広く利用されてきた。複数通貨・複数アカウント管理が可能。 他BIPとの関係: 新しいアドレス形式に対応するBIP49やBIP84などは、このBIP44をベースにpurpose番号を変えて並立利用できる。 BIP49 概要: m/49'/coin_type'/account'/change/address_index を使い、P2WPKH-in-P2SH（3xxxx）アドレスを定義。 目的: 互換性を重視しつつ部分的にSegWitの恩恵（手数料削減など）を得るためのラップドSegWit。 他BIPとの関係: レガシー形式（BIP44）を補完し、新しいネイティブSegWit（BIP84）へ移行する中継的役割を果たす。 BIP84 概要: m/84'/coin_type'/account'/change/address_index の構造を使い、ネイティブSegWit（bech32、bc1q…）アドレスを定義。 目的: SegWitの機能をフル活用し、より低い手数料やエラー検知の強化を実現。 他BIPとの関係: ラップドSegWit（BIP49）より進んだ純粋なSegWit。Taproot（BIP86）の前段階。 BIP86 概要: m/86'/coin_type'/account'/change/address_index を使い、Taproot（bech32m、bc1p…）アドレス（単独所有向け）を定義。 目的: Schnorr署名やMASTなどTaprootの恩恵（手数料削減・プライバシー向上）を得る。現時点ではシングルキー中心だが、将来的な拡張も想定。 他BIPとの関係: ネイティブSegWit（BIP84）より先進的なP2TR形態を扱う。purpose番号86を使い、既存形式と衝突しない。 BIP49が「legacy segwit」と呼ばれる理由 BIP49のP2WPKH-in-P2SHアドレス（3xxxx）は見た目が通常のP2SHと同じため、一般に「legacy segwit」とも呼ばれる。P2SHの場合、redeemScriptをユーザ側で保持する必要があるが、BIP49対応ウォレット（例: 多くのハードウェアウォレットなど）を使うなら、redeemScriptを個別にバックアップしなくても済む。 https://github.com/btcsuite/btcwallet/blob/master/waddrmgr/address.go#L554 アドレスインデックスとリカバリー アドレスインデックス（address_index）はウォレットが生成したアドレス数に応じて変化する。復旧時には何番目までアドレスを生成してスキャンするかを決める必要がある。btc walletでは以下のアルゴリズムにより、使用中のアドレスを取りこぼさずに効率的なブロックスキャンを行う。 sequenceDiagram participant RM as RecoveryManager participant RS as RecoveryState participant BRS as BranchRecoveryState participant BC as Blockchain Note over RM: (Resurrectで<br>既存のアドレス・UTXOを復元) loop until 全ブロックスキャン完了 RM->BC: 次のブロック(群)取得 BC-->RM: BlockBatch返却 RM->RS: State取得 RM->>BRS: ExtendHorizon()呼び出し alt horizonが不足 BRS->>BRS: horizonを拡張<br>(nextUnfound + recoveryWindow) note right of BRS: 無効インデックス数も考慮 end RM->BC: FilterBlocksRequest(生成済みアドレスを照合) BC-->RM: FilterBlocksResponse(発見されたaddrのindex) RM->>BRS: ReportFound(index) alt 新しい発見がありnextUnfoundが進む BRS->>BRS: horizon再チェック end end Note over RM: 発見された中で最も高いインデックス +<br>recoveryWindow + 無効インデックス数まで生成し続ける Resurrect 既知のアドレスやUTXOを RecoveryState に登録し、初期状態をセットする。 ExtendHorizon nextUnfound + recoveryWindow (+ 無効インデックス数) までアドレスを導出・監視対象に加えておき、取りこぼしを防ぐ。 FilterBlocks 実際にブロックをスキャンし、高いインデックスのアドレスが見つかったら ReportFound で更新し、さらに horizon を見直す。 最終的に 最も高いインデックス + recoveryWindow + 無効インデックス数まで検査し、使われている可能性のあるアドレスを漏れなく拾う。 注意 このアルゴリズムはbtc walletの実装に基づくものであり、他のウォレット実装には異なる部分があるかもしれない。 また、recoveryWindowは、250が設定されている。 一般的なユースケースでは考えづらいが、250以上、indexが連続していない場合は、リカバリーが不完全になる可能性がある。 ...

ELIP 0200の日本語訳。Elements Improvement Proposals (ELIPs) は、BitcoinのBIPに相当するElementsプロジェクトの改善提案である。 この記事はllmによる機械翻訳に基づく。誤りの可能性がある点に留意すること。 この内容はcommit hash 9f08b8168328691c1bff6e0261cebbe985f39ae4 時点のリポジトリを参照している。 ELIP: 200 Layer: Applications Title: Confidential Transactions の割引料金 Author: Byron Hambly bhambly@blockstream.com Comments-Summary: まだコメントはない Comments-URI: https://github.com/ElementsProject/elips/wiki/Comments:ELIP-0200 Status: Draft Type: Standards Track Created: 2024-06-19 License: BSD-3-Clause はじめに 概要 Confidential Transactions (CT) の取引手数料を割引する方法を提案する。これにより、ウォレットが割引手数料率を算出可能になり、ノードが割引されたCTをリレー・採掘するための要件を定義する。 Copyright 本書は3条項BSDライセンスの下で公開している。 Motivation ElementsにおけるCTは、明示的な取引よりサイズが約10倍大きい。 Pedersenコミットメントやアセットコミットメント、ECDHエフェメラルキーなどが追加され、さらにレンジプルーフとサージェクションプルーフを含むウィットネスデータが大きな要因である。 サイズが大きいほど手数料が高くなるため、ユーザがCTによるプライバシーを犠牲にし、明示的な取引を選びやすくなる可能性がある。 このELIPは、ElementsでCTを割引料金で受け入れるポリシー変更を提案し、CTと明示的な取引を同等の手数料規模に近づけ、明示的取引優先の動機を下げる。 Design Overview 新たに「discount virtual size (discountvsize)」を導入する。 明示的な取引では通常のvsizeと実質同じ値となるが、CTでは秘密出力が含まれるたびに、各出力分の重みを仮想サイズ計算の前に減少させる。 ウォレットは、この割引計算を用いて手数料を推定し、ノードはメンプールへの受け入れやピアへのメッセージングでdiscountvsizeを利用する。これによってCT取引の中継と採掘が行われる。 欠点 ディスカウントを導入すると、実際のコストは表面上の手数料率より低くなる。 既存のブロックアセンブラは先祖手数料率が高い取引から優先するため、割引CTは同じ「表面料金率」の明示的トランザクションなどより選択が遅れる。 この状態を解消するには、ブロックアセンブラ側で割引された仮想サイズを基準に手数料率を扱うよう変更が必要だが、最大料金追求よりCTのプライバシー優先を許容するというトレードオフとなる。 仕様 ウォレット ウォレットは通常の手順で取引を作成し、まずプレースホルダーの手数料出力を含める。 ダミー署名を埋め込んだ後、BIP-01411 に従い以下の式で重みを算出する: Weight = (Base transaction size * 3) + Total transaction size ...

https://d-central.tech/understanding-op_ctv-bip-119-in-bitcoin/ をinputとし、podcastfyを用いて作成したもの。 「次世代ビットコインへの扉：OP_CTVがもたらす革新とは？」 今回のポッドキャストでは、ビットコインの新提案「OP_CTV (BIP 119)」を切り口に、ビットコインがどんな未来を描こうとしているのかを探ります。秘密鍵を盗まれても即時に資金を抜かれない「ボルト（Vault）」機能や、複数人で１つのUTXOを共有できるShared UTXOによるスケーラビリティ改善など、セキュリティ・プライバシー・効率性を大幅にアップさせる可能性が語られました。 一方で、政府の“ホワイトリスト”強制への懸念や、新機能導入による複雑化・セキュリティリスクも話題に。ビットコインが一貫して大切にしてきた「慎重で分散的な進化」は、OP_CTVにも当てはまります。ソフトフォークを経たコミュニティ合意が必要なことや、新機能の意義が正しく理解されるかが鍵。ビットコインの「堅牢さ」と「革新」がどう共存していくのか、目が離せない展開です。

templateはなにが可変であり、なにが固定なのか、を整理する。 様々な場所に情報があるが、BIPに記されたpython codeを見るのが一番良い。 def ser_compact_size(l): r = b"" if l < 253: # Serialize as unsigned char r = struct.pack("B", l) elif l < 0x10000: # Serialize as unsigned char 253 followed by unsigned 2 byte integer (little endian) r = struct.pack("<BH", 253, l) elif l < 0x100000000: # Serialize as unsigned char 254 followed by unsigned 4 byte integer (little endian) r = struct.pack("<BI", 254, l) else: # Serialize as unsigned char 255 followed by unsigned 8 byte integer (little endian) r = struct.pack("<BQ", 255, l) return r def ser_string(s): return ser_compact_size(len(s)) + s class CTxOut: def serialize(self): r = b"" # serialize as signed 8 byte integer (little endian) r += struct.pack("<q", self.nValue) r += ser_string(self.scriptPubKey) return r def get_default_check_template_precomputed_data(self): result = {} # If there are no scriptSigs we do not need to precompute a hash if any(inp.scriptSig for inp in self.vin): result["scriptSigs"] = sha256(b"".join(ser_string(inp.scriptSig) for inp in self.vin)) # The same value is also pre-computed for and defined in BIP-341 and can be shared. # each nSequence is packed as 4 byte unsigned integer (little endian) result["sequences"] = sha256(b"".join(struct.pack("<I", inp.nSequence) for inp in self.vin)) # The same value is also pre-computed for and defined in BIP-341 and can be shared # See class CTxOut above for details. result["outputs"] = sha256(b"".join(out.serialize() for out in self.vout)) return result parameter precomputed must be passed in for DoS resistance def get_default_check_template_hash(self, nIn, precomputed = None): if precomputed == None: precomputed = self.get_default_check_template_precomputed_data() r = b"" # Serialize as 4 byte signed integer (little endian) r += struct.pack("<i", self.nVersion) # Serialize as 4 byte unsigned integer (little endian) r += struct.pack("<I", self.nLockTime) # we do not include the hash in the case where there is no # scriptSigs if "scriptSigs" in precomputed: r += precomputed["scriptSigs"] # Serialize as 4 byte unsigned integer (little endian) r += struct.pack("<I", len(self.vin)) r += precomputed["sequences"] # Serialize as 4 byte unsigned integer (little endian) r += struct.pack("<I", len(self.vout)) r += precomputed["outputs"] # Serialize as 4 byte unsigned integer (little endian) r += struct.pack("<I", nIn) return sha256(r) OP_CHECKTEMPLATEVERIFY（OP_CTV）は「将来使われるトランザクションの形をあらかじめ決めておき、そこから外れる支払いを無効とする」仕組みを提供する。したがって、意図しない送金や改ざんを防ぎながら、VaultやChannel Factoryのような特定用途の“Covenant”機能をシンプルかつ安全に実装できる。 ...

BIP 119の日本語訳をおいておく。 この記事は、llmにより翻訳されたものであり、内容に誤りがある可能性はある。 BIP 119は、新しいオペコード OP_CHECKTEMPLATEVERIFY を有効化することを提案しており、このブログを書いた段階で、有力な選択肢となっている。 Developer Consensus May Be Converging on a Bitcoin Soft Fork Proposal: Blockspace なお、この記事は、commit hash88c0fb9b5b7c3ed73386224c8c4ae0fd4fc3537f 時点のものとなっている。 Abstract Summary Motivation Detailed Specification デプロイ 参考実装 根拠 The DefaultCheckTemplateVerifyHash of the transaction at the current input index matches the top of the stack Committing to the version and locktime Committing to the ScriptSigs Hash インプット数へのコミット シーケンスハッシュへのコミット アウトプット数へのコミット アウトプットハッシュへのコミット 現在のインプットのインデックスへのコミット Committing to Values by Hash Using SHA256 Using Non-Tagged Hashes The Ordering of Fields 設計上のトレードオフとリスク Denial of Service and Validation Costs 永久に使用できない出力 転送アドレス NOP-Default and Recommended Standardness Rules 機能の冗長性 将来的なアップグレード CHECKTEMPLATEVERIFY バージョン OP_CHECKSIGFROMSTACKVERIFY OP_AMOUNTVERIFY OP_CAT/OP_SHA256STREAM Backwards Compatibility スクリプト互換性 References 類似した代替案について 著作権 BIP: 119 Layer: Consensus (soft fork) Title: CHECKTEMPLATEVERIFY Author: Jeremy Rubin j@rubin.io Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0119 Status: Draft Type: Standards Track Created: 2020-01-06 License: BSD-3-Clause ...