Skip to content

Commit d57f9ad

Browse files
azuchibitschmidty
authored andcommitted
Newsletter-357:Translate into Japanese
1 parent 0614368 commit d57f9ad

File tree

1 file changed

+162
-0
lines changed

1 file changed

+162
-0
lines changed
Lines changed: 162 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,162 @@
1+
---
2+
title: 'Bitcoin Optech Newsletter #357'
3+
permalink: /ja/newsletters/2025/06/06/
4+
name: 2025-06-06-newsletter-ja
5+
slug: 2025-06-06-newsletter-ja
6+
type: newsletter
7+
layout: newsletter
8+
lang: ja
9+
---
10+
今週のニュースレターでは、古いwitnessなしでフルノードを同期させる方法の分析を共有しています。
11+
また、コンセンサスの変更に関する議論や、新しいリリースとリリース候補の発表、
12+
人気のBitcoinインフラストラクチャソフトウェアの注目すべき更新など、
13+
恒例のセクションも含まれています。
14+
15+
## ニュース
16+
17+
- **witnessなしのフルノードの同期:** Jose SKは、
18+
特定の設定で新しく起動したフルノードが、過去のブロックチェーンデータのダウンロードを回避した場合の
19+
セキュリティ上のトレードオフについての[分析][sk nowit gist]の要約をDelving Bitcoinに[投稿しました][sk nowit]
20+
Bitcoin Coreはデフォルトで、実行中のBitcoin Coreのバージョンのリリースより1〜2ヶ月以上前に作成されたブロックについて、
21+
ブロック内のスクリプトの検証をスキップする`assumevalid`設定を使用しています。
22+
またデフォルトでは無効になっていますが、多くのBitcoin Coreユーザーは、
23+
ブロックの検証後しばらくしてからそのブロックを削除する`prune`設定を使用しています(
24+
ブロックの生存期間はブロックのサイズとユーザーが選択した設定によって異なります)。
25+
26+
SKは、スクリプトの検証に使用されず最終的に削除されるため、
27+
プルーニングノードはassumevalidの対象のブロックについて、
28+
スクリプトの検証にだけ使われるwitnessデータをダウンロードしなくていいと主張しています。
29+
witnessのダウンロードをスキップすることで、「帯域幅の使用量を40%以上削減できる」
30+
と書いています。
31+
32+
Ruben Somsenは、これは少なくともセキュリティモデルに何ら化の変化をもたらすと[主張しています][somsen nowit]
33+
スクリプトは検証されませんが、ダウンロードされたデータはブロックヘッダーのマークルルートから
34+
コインベーストランザクション、そしてwitnessデータを含むコミットメントに対して検証されます。
35+
これにより、ノードが最初に同期された時点でデータが利用可能であり、
36+
破損していないことが保証されます。もし誰もデータの存在を定期的に検証しなければ、
37+
少なくとも1つのアルトコインで[発生したように][ripple loss]、データが失われる可能性があります。
38+
39+
記事の執筆時点で、この議論は継続中でした。
40+
41+
## コンセンサスの変更
42+
43+
_Bitcoinのコンセンサスルールの変更に関する提案と議論をまとめた月次セクション_
44+
45+
- **<!--quantum-computing-report-->量子コンピューターに関するレポート:**
46+
Clara Shikhelmanは、高速な量子コンピューターがBitcoinユーザーにもたらすリスク、
47+
[量子耐性][topic quantum resistance]への複数のアプローチの概要、
48+
Bitcoinプロトコルのアップグレードに伴うトレードオフの分析について、
49+
Anthony Miltonと共同執筆した[レポート][sm report]をDelving Bitcoinに[投稿しました][shikelman quantum]
50+
著者らは、400万BTCから1000万BTCが量子コンピューターによる盗難の潜在的なリスクにさらされていること、
51+
現在ある程度の緩和策があること、Bitcoinマイニングが短期的または中期的に量子コンピューターの脅威にさらされる可能性は低いこと、
52+
そしてアップグレードには幅広い合意が必要であることを明らかにしています。
53+
54+
- **没収防止のための例外付きのトランザクションweight制限:**
55+
Vojtěch Strnadは、ブロック内のほとんどのトランザクションの最大weightを制限するコンセンサス変更のアイディアを
56+
Delving Bitcoinに[投稿しました][strnad limit]。このシンプルなルールは、
57+
ブロック内で400,000 weight単位(100,000 vbyte)を超えるトランザクションは、
58+
そのブロック内でコインベーストランザクションを除いて1つのみ許可するというものです。
59+
Strnadらは、トランザクションの最大weightを制限する理由を次のように述べています:
60+
61+
- _ブロックテンプレートの最適化が容易:_
62+
[ナップサック問題][knapsack problem]に対する最適解に近い解を見つけるのは、
63+
全体の制限と比較してアイテムが小さいほど容易です。これはアイテムが小さいほど未使用のスペースが少なくなり、
64+
最終的に残るスペースが最小限に抑えられるためです。
65+
66+
- _リレーポリシーの簡素化:_ ノード間の未承認トランザクションのリレーポリシーは、
67+
帯域幅の浪費を避けるために、どのトランザクションがマイニングされるかを予測します。
68+
巨大なトランザクションは、最上位の手数料率のわずかな変化でも遅延や排除につながる可能性があるため、
69+
正確な予測を難しくします。
70+
71+
- _マイニングの集中化の回避:_ リレーフルノードがほぼすべてのトランザクションを処理できるようにすることで、
72+
特別なトランザクションのユーザーが[帯域外手数料][topic out-of-band fees]を支払う必要がなくなり、
73+
マイニングの集中化につながるリスクを回避できます。
74+
75+
Gregory Sandersは、Bitcoin Coreの12年間にわたる一貫したリレーポリシーに基づき、
76+
例外なく最大weight制限をソフトフォークするのが合理的かもしれないと[指摘しました][sanders limit]
77+
Gregory Maxwellは、ソフトフォーク前に作成されたUTXOのみを使用するトランザクションについては、
78+
没収を防ぐための例外を認めることができ、また[一時的なソフトフォーク][topic transitory soft forks]とすることで、
79+
コミュニティが更新を望まなければ制限を失効させられると[付け加え][maxwell limit]ました。
80+
81+
追加の議論では、大規模なトランザクションを求める当事者(主に短期的には[BitVM][topic acc]のユーザーなど)のニーズと、
82+
彼らが利用可能な代替アプローチがあるかどうかが検討されました。
83+
84+
- **金額と時間に基づいてUTXOセットからアウトプットを削除する:**
85+
Robin Linusは、一定期間後に金額の小さいアウトプットをUTXOセットから削除するためのソフトフォークの提案を
86+
Delving Bitcoinに[投稿しました][linus dust]。このアイディアではいくつかのバリエーションが議論され、
87+
主に以下の2つの代替案が挙げられました:
88+
89+
- _古くて経済的ではない資金を破棄する:_ 長期間使われていない少額のアウトプットは使用できなくなります。
90+
91+
- _古くて経済的ではない資金の使用には存在証明を求める:_
92+
[utreexo][topic utreexo]や同様のシステムを使用することで、
93+
トランザクションは使用するアウトプットがUTXOセットの一部であることを証明できます。
94+
古くて[経済合理性のないアウトプット][topic uneconomical outputs]は、
95+
この証明を含める必要があり、新しくて多額のアウトプットはUTXOセットに引き続き保持されます。
96+
97+
どちらの解決策も、UTXOセットの最大サイズを実質的に制限します(最小値と2100万ビットコインの制限を想定)。
98+
これを適用するために、より実用的になる可能性のあるutreexo証明の代替案など、
99+
設計の興味深い技術的側面がいくつか議論されました。
100+
101+
## リリースとリリース候補
102+
103+
_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。
104+
新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_
105+
106+
- [Core Lightning 25.05rc1][]は、この人気のLNノード実装の次期メジャーバージョンのリリース候補です。
107+
108+
- [LND 0.19.1-beta.rc1][]は、この人気のLNノード実装のメンテナンスバージョンのリリース候補です。
109+
110+
## 注目すべきコードとドキュメントの変更
111+
112+
_最近の[Bitcoin Core][bitcoin core repo][Core
113+
Lightning][core lightning repo][Eclair][eclair repo][LDK][ldk repo]
114+
[LND][lnd repo][libsecp256k1][libsecp256k1 repo][Hardware Wallet
115+
Interface (HWI)][hwi repo][Rust Bitcoin][rust bitcoin repo][BTCPay
116+
Server][btcpay server repo][BDK][bdk repo][Bitcoin Improvement
117+
Proposals(BIP)][bips repo][Lightning BOLTs][bolts repo]
118+
[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_
119+
120+
- [Bitcoin Core #32582][]では、
121+
[コンパクトブロックの再構築][topic compact block relay]のパフォーマンスを測定するための新しいログが追加されました。
122+
これは、ノードがピアに要求するトランザクション(`getblocktxn`)の合計サイズ、
123+
ノードがピアに送信する(`blocktxn`)トランザクションの数と合計サイズを追跡し、
124+
`PartiallyDownloadedBlock::InitData()`の開始時にタイムスタンプを追加することで、
125+
mempoolのルックアップ手順のみにかかる時間(高帯域幅モードと低帯域幅モードの両方)を追跡します。
126+
コンパクトブロックの再構築に関する以前の統計レポートについては、ニュースレター[#315][news315 compact]をご覧ください。
127+
128+
- [Bitcoin Core #31375][]では、[マルチプロセス][multiprocess project]バイナリである
129+
`bitcoin node``bitcoind`)、`bitcoin gui`(bitcoinqt)、`bitcoin rpc`(`bitcoin-cli
130+
-named`)をラップして実行する新しい`bitcoin -m` CLIツールが追加されました。
131+
現在、これらはモノリシックバイナリと同様に機能しますが、
132+
`-ipcbind`オプション(ニュースレター[#320][news320 ipc]参照)をサポートしています。
133+
ただし、将来の改良により、ノードランナーが異なるマシンや環境でコンポーネントを独立して起動・停止できるようになります。
134+
このPRを取り上げているBitcoin Core PR Review Clubについては、ニュースレター[#353][news353 pr review]をご覧ください。
135+
136+
- [BIPs #1483][]は、送信者と受信者が暗号化されたPSBTをメッセージの保存と転送のみを行う
137+
payjoinディレクトリサーバーに渡す、非同期サーバーレス版である[payjoin v2][topic payjoin]を提案する
138+
[BIP77][]をマージしました。ディレクトリサーバーは、ペイロードの読み取りや変更ができないため、
139+
どちらのウォレットも公開サーバーをホストしたり、同時にオンラインにしたりする必要はありません。
140+
payjoin v2の詳細については、ニュースレター[#264][news264 payjoin]をご覧ください。
141+
142+
{% include snippets/recap-ad.md when="2025-06-10 16:30" %}
143+
{% include references.md %}
144+
{% include linkers/issues.md v=2 issues="32582,31375,1483" %}
145+
[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1
146+
[ripple loss]: https://x.com/JoelKatz/status/1919233214750892305
147+
[sk nowit]: https://delvingbitcoin.org/t/witnessless-sync-for-pruned-nodes/1742/
148+
[sk nowit gist]: https://gist.github.com/JoseSK999/df0a2a014c7d9b626df1e2b19ccc7fb1
149+
[somsen nowit]: https://gist.github.com/JoseSK999/df0a2a014c7d9b626df1e2b19ccc7fb1?permalink_comment_id=5597316#gistcomment-5597316
150+
[shikelman quantum]: https://delvingbitcoin.org/t/bitcoin-and-quantum-computing/1730/
151+
[sm report]: https://chaincode.com/bitcoin-post-quantum.pdf
152+
[strnad limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/
153+
[knapsack problem]: https://ja.wikipedia.org/wiki/ナップサック問題
154+
[sanders limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/2
155+
[maxwell limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/4
156+
[linus dust]: https://delvingbitcoin.org/t/dust-expiry-clean-the-utxo-set-from-spam/1707/
157+
[lnd 0.19.1-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.1-beta.rc1
158+
[news315 compact]: /ja/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction
159+
[multiprocess project]: https://github.com/ryanofsky/bitcoin/blob/pr/ipc/doc/design/multiprocess.md
160+
[news320 ipc]: /ja/newsletters/2024/09/13/#bitcoin-core-30509
161+
[news264 payjoin]: /ja/newsletters/2023/08/16/#payjoin
162+
[news353 pr review]: /ja/newsletters/2025/05/09/#bitcoin-core-pr-review-club

0 commit comments

Comments
 (0)