今週のニュースレターでは、BIPプロセスの変更案と、 Bitcoin Coreにパッケージリレーのサポートを追加するための計画の要約、 DNSにLNノードの情報を追加することについての議論のリンクを掲載しています。 また、サービスやクライアントソフトウェアの変更点や、Taprootへの準備方法、新しいリリースとリリース候補、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更点などの恒例のセクションも含まれています。

ニュース

  • ● BIPの拡張: Karl-Johan Almは、Bitcoin-Devメーリングリストに、 一定の安定性を達成したBIPは、小さな修正を除いて今後は変更できないという提案を投稿しました。 安定したBIPの条件の変更は、前のドキュメントを拡張した新しいBIPで行う必要があります。

    Anthony Townsは、この案に反対し、 BIPリポジトリにDraftsフォルダを設けたり、BIPのメンテナが特定の提案に付ける番号を選択することをやめるなど、 現在のプロセスに対するいくつかの代替案を提案しました。

  • ● mempoolのパッケージの受け入れとパッケージRBF: Gloria Zhaoは、 CPFPとRBFの両方の手数料の引き上げの柔軟性と信頼性を高める、 複数の関連トランザクションのパッケージリレーの設計について、 Bitcoin-Devメーリングリストに投稿しました。 初期の実装では、パッケージはBitcoin CoreのRPCインターフェースを介してのみ送信できますが、 最終的な目標は、この機能をP2Pネットワーク上で利用できるようにすることです。 Zhaoは、Bitcoin Coreのトランザクション受け入れルールの変更案を簡潔にまとめています:

    • パッケージは既にmempool内のトランザクションに含まれていることがあります。
    • パッケージは2世代、親が複数で子が１つ。
    • 手数料関連のチェックはパッケージの手数料率を使用します。これは、ウォレットがCPFPを利用するパッケージを作成できることを意味します。
    • 親は、BIP125に類似したルールのセットを持つRBF mempoolトランザクションを許可します。 これにより、CPFPとRBFの組み合わせが可能になり、トランザクションの子孫の手数料がmempoolの競合を置き換えるために支払われます。

    このメールでは、その機能の利用を想定している開発者や、変更による影響を考えている開発者からの 提案に対するフィードバックを求めています。

  • ● LNノードのDNSレコード: Andy Schroderは、Lightning-Devメーリングリストに、 ドメイン名からLNノードのIPアドレスを公開鍵を解決するためのDNSレコードのセットの使用法を標準化する提案を投稿しました。 この記事を書いている時点では、このアイディアはまだ議論されています。

サービスとクライアントソフトウェアの変更

この毎月の特集では、Bitcoinのウォレットやサービスの興味深いアップデートを取り上げています。

Taprootの準備 #14: Signetでのテスト

ブロック高709,632のTaprootのアクティベーションに向けて、 開発者やサービスプロバイダーがどのような準備をすればよいかについての週刊シリーズです。

mainnetでブロック709,632より前にTaprootを安全に使用することはできませんが、 今日、testnetまたはsignetのいずれかでTaprootを使用することはできます。 Optech taproot workbooksで行われているように、 Bitcoin Coreのregtestモードでローカルのテストネットワークを作成するのに比べて、 testnetやsignetを使用すると、自分のウォレットが他の人のウォレットとどのように相互作用するか簡単にテストできます。

この記事では、signet上でBitcoin Coreの内蔵ウォレットを使って、 Taprootトランザクションを受信したり支払いしたります。 自分のウォレットとBitcoin Coreの間で送受信をテストするのに、この手順を利用できます。

技術的には、Bitcoin Core 22.0の内蔵ウォレットを使ってTaprootトランザクションを受信および使用することは可能ですが、 代わりに、descriptorウォレットのデフォルトをTaprootにした、 Bitcoin CoreのPR #22364をビルドすることをお勧めします。 ビルドし、signetを起動します:

$ bitcoind -signet -daemon

初めてsignetを起動する場合は、ブロックチェーンを同期する必要があります。 現在は、200 MB以下のデータで、わずか1分で同期が完了します。 同期の進捗状況はgetblockchaininfo RPC使って確認できます。 同期後、descriptorウォレットを作成します:

$ bitcoin-cli -signet -named createwallet wallet_name=p4tr descriptors=true load_on_startup=true
{
  "name": "p4tr",
  "warning": "Wallet is an experimental descriptor wallet"
}

これで、bech32mアドレスを作成できます:

$ bitcoin-cli -named -signet getnewaddress address_type=bech32m
tb1p6h5fuzmnvpdthf5shf0qqjzwy7wsqc5rhmgq2ks9xrak4ry6mtrscsqvzp

このアドレスを使って、signet faucetに資金をリクエストできます。 その後、承認を待つ必要がありますが、これにはmainnetと同じように時間がかかります（通常は最大30分、 時にはそれ以上かかることもあります）。 トランザクションが確認できると、作成したP2TRスクリプトが表示されるでしょう。

$ bitcoin-cli -signet getrawtransaction 688f8c792a7b3d9cb46b95bfa5b10fe458617b758fe4100c5a1b9536bedae4cd true | jq .vout[0]
{
  "value": 0.001,
  "n": 0,
  "scriptPubKey": {
    "asm": "1 d5e89e0b73605abba690ba5e00484e279d006283bed0055a0530fb6a8c9adac7",
    "hex": "5120d5e89e0b73605abba690ba5e00484e279d006283bed0055a0530fb6a8c9adac7",
    "address": "tb1p6h5fuzmnvpdthf5shf0qqjzwy7wsqc5rhmgq2ks9xrak4ry6mtrscsqvzp",
    "type": "witness_v1_taproot"
  }
}

続いて、2つめのbech32mアドレスを作成し、そこに資金を送って支払いをテストできます。

$ bitcoin-cli -named -signet getnewaddress address_type=bech32m
tb1p53qvqxja52ge4a7dlcng6qsqggdd85fydxs4f5s3s4ndd2yrn6ns0r6uhx
$ bitcoin-cli -named -signet sendtoaddress address=tb1p53qvqxja52ge4a7dlcng6qsqggdd85fydxs4f5s3s4ndd2yrn6ns0r6uhx amount=0.00099
24083fdac05edc9dbe0bb836272601c8893e705a2b046f97193550a30d880a0c

この支払いについて、インプットの１つを確認すると、そのwitnessには64バイトの署名が1つだけ含まれています。 これはP2WPKHやその他のタイプの古いBitcoinの支払いをした場合に必要とされるwitnessよりもvbyte数が小さくなっています。

$ bitcoin-cli -signet getrawtransaction 24083fdac05edc9dbe0bb836272601c8893e705a2b046f97193550a30d880a0c true | jq .vin[0]
{
  "txid": "bd6dbd2271a95bce8a806288a751a33fc4cf2c336e52a5b98a5ded432229b6f8",
  "vout": 0,
  "scriptSig": {
    "asm": "",
    "hex": ""
  },
  "txinwitness": [
    "2a926abbc29fba46e0ba9bca45e1e747486dec748df1e07ee8d887e2532eb48e0b0bff511005eeccfe770c0c1bf880d0d06cb42861212832c5f01f7e6c40c3ce"
  ],
  "sequence": 4294967294
}

上記のコマンドをいじってみると、signetに対応しているウォレットでTaprootを使ってお金を受け取ったり、 支払ったりするのが簡単であることが分かります。

リリースとリリース候補

人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。

  • ● Bitcoin Core 0.21.2rc2は、Bitcoin Coreのメンテナンスバージョンのリリース候補です。 いくつかのバグ修正と小さな改善が含まれています。

注目すべきコードとドキュメントの変更

今週のBitcoin Core、 C-Lightning、Eclair、LND、 Rust-Lightning、libsecp256k1、 Hardware Wallet Interface (HWI)、 Rust Bitcoin、BTCPay Server、 Bitcoin Improvement Proposals（BIP）、および Lightning BOLTsの注目すべき変更点。

  • ● Eclair #1932は、BOLTs #824で定義されたAnchor Outputプロトコルの改訂版を実装し、 事前署名されたHTLC支払いはゼロ手数料になるため、手数料が盗まれることはありません。 詳細は、ニュースレター #165をご覧ください。

  • ● LND #5405は、updatechanpolicy RPCを拡張し、 現在のポリシー（または、チャネルのファンディング・トランザクションが未承認であるなどの他の問題） のため使用できないチャネルを報告するようになりました。

  • ● LND #5304により、LND自身が知らない外部権限を持つmacaroonの作成と検証が可能になりました。 この変更により、Lightning Terminalのようなツールで、1つのmacaroonを使って、 同じLNDと通信する複数のデーモン間での認証が可能になります。

  • ● Rust Bitcoin #628は、Pay to Taprootのsighash構築のサポートを追加し、 レガシー、segwit、taprootインプットのsighashキャッシュのストレージを整理しました。

  • ● Rust Bitcoin #580は、BIP37で定義された トランザクションのBloom FilterのためのP2Pメッセージをのサポートを追加しました。

  • ● Rust Bitcoin #626は、ブロックのストリップサイズ（segwitデータをすべて削除したブロック）と、 トランザクションのvbyteサイズを取得する関数を追加しました。

  • ● Rust-Lightning #1034は、現在閉鎖処理中のチャネルを含む、 チャネルの残高の完全なリストを取得するために使用できる関数を追加しました。 これにより、一部の資金が使用可能になるまで承認を待っている場合でも、 エンドユーザーのソフトウェアは一貫したユーザーの残高を表示することができます。