From d683837a613c90d94d2be5e0cfda0086f9eec15c Mon Sep 17 00:00:00 2001 From: Steven Torok <79690639+TorokNRoll@users.noreply.github.com> Date: Thu, 8 May 2025 13:00:59 -0500 Subject: [PATCH 001/278] Matrix: add BitGo, fix Liana (#2305) --- _data/matrix/BitGo.yaml | 36 ++++++++++++++++++++++++++++++++++++ _data/matrix/Liana.yaml | 6 +++--- 2 files changed, 39 insertions(+), 3 deletions(-) create mode 100644 _data/matrix/BitGo.yaml diff --git a/_data/matrix/BitGo.yaml b/_data/matrix/BitGo.yaml new file mode 100644 index 0000000000..c2121fe4f9 --- /dev/null +++ b/_data/matrix/BitGo.yaml @@ -0,0 +1,36 @@ +--- +name: "BitGo" +category: "Software Wallet (L1&L2)" +keyfeatures: "Web-Based, Self-Custodial 2-of-3 Multisig Wallet and Lightning for Enterprise Customers" +homepage: "https://www.bitgo.com" + +feature: + device: "Not Applicable" + os: "Not Applicable" + web: "Yes" + hwi: "No" + default_receive: "P2WSH" + bech32: "Full Support (send & receive)" + bech32m: "Full Support (send & receive)" + segwit_change: "Yes" + full_rbf_bump_fee: "Yes" + full_rbf_cancel_txn: "No" + full_rbf_notification: "Yes" + cpfp: "Full Support (send & receive)" + descriptors: "No" + psbt_version: "V0" + psbt_export: "Yes" + psbt_update_finalize: "Yes" + musig2: "Full Support (send & receive)" + coinjoin: "No Support" + payjoin_BIP78: "No Support" + payjoin_alternate: "No Support" + payjoin_alternate_name: "" + payment_code: "No Support" + silent_payments_BIP352: "No Support" + silent_payments_dns: "No Support" + lightning_11: "Full Support (send & receive)" + lightning_12: "No Support" + lightning_12_dns: "No Support" + lightning_lnurl: "No Support" + lightning_lnurl_hrla: "No Support" diff --git a/_data/matrix/Liana.yaml b/_data/matrix/Liana.yaml index a84b3acd3a..1175a01b3d 100644 --- a/_data/matrix/Liana.yaml +++ b/_data/matrix/Liana.yaml @@ -18,9 +18,9 @@ feature: full_rbf_notification: "No" cpfp: "Full Support (send & receive)" descriptors: "Yes" - pbst_version: "V0" - pbst_export: "Yes" - pbst_update_finalize: "Yes" + psbt_version: "V0" + psbt_export: "Yes" + psbt_update_finalize: "Yes" musig2: "No Support" coinjoin: "No Support" payjoin_BIP78: "No Support" From 8fa55787499dd654ec7f36356cda027811aea20f Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Tue, 6 May 2025 19:14:52 -1000 Subject: [PATCH 002/278] Newsletters: add 353 (2025-05-09) --- .../en/newsletters/2025-05-09-newsletter.md | 123 ++++++++++++++++++ 1 file changed, 123 insertions(+) create mode 100644 _posts/en/newsletters/2025-05-09-newsletter.md diff --git a/_posts/en/newsletters/2025-05-09-newsletter.md b/_posts/en/newsletters/2025-05-09-newsletter.md new file mode 100644 index 0000000000..764c2cbb76 --- /dev/null +++ b/_posts/en/newsletters/2025-05-09-newsletter.md @@ -0,0 +1,123 @@ +--- +title: 'Bitcoin Optech Newsletter #353' +permalink: /en/newsletters/2025/05/09/ +name: 2025-05-09-newsletter +slug: 2025-05-09-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter describes a recently discovered theoretical +consensus failure vulnerability and links to a proposal to avoid reuse +of BIP32 wallet paths. Also included are our regular sections summarizing +a Bitcoin Core PR Review Club meeting, announcing new releases and +release candidates, and describing notable code changes to popular +Bitcoin infrastructure software. + +## News + +- **BIP30 consensus failure vulnerability:** Ruben Somsen [posted][somsen + bip30] to the Bitcoin-Dev mailing list about a theoretical consensus + failure that could occur now that checkpoints have been removed from + Bitcoin Core (see [Newsletter #346][news346 checkpoints]). In short, + the coinbase transactions of blocks 91722 and 91812 are [duplicated][topic duplicate transactions] in + blocks 91880 and 91842. [BIP30][] specifies that those second two + blocks should be handled the way the historic version of Bitcoin Core + handled them in 2010, which is by overwriting the earlier coinbase + entries in the UTXO set with the later duplicates. However, Somsen + notes that a reorg of either or both later blocks would result in the + duplicate entry (or entries) being removed from the UTXO set, leaving + it devoid also of the earlier entries due to the overwriting. + But, a newly started node that never saw the duplicate + transactions would still have the earlier transactions, giving it a + different UTXO set that could result in a consensus failure if either + transaction is ever spent. + + This wasn't an issue when Bitcoin Core had checkpoints as they + required all four blocks mentioned above to be part of the best + blockchain. It's not really an issue now, except in a theoretical + case where Bitcoin's proof-of-work security mechanism breaks. Several + possible solutions were discussed, such as hardcoding additional + special case logic for these two exceptions. + +- **Avoiding BIP32 path reuse:** Kevin Loaec [posted][loaec bip32reuse] + to Delving Bitcoin to discuss options for preventing the same + [BIP32][topic bip32] wallet path from being used with different + wallets, which could lead to a loss of privacy due to [output + linking][topic output linking] and a theoretical loss of security + (e.g., due to [quantum computing][topic quantum resistance]). He + suggested three possible approaches: use a randomized path, use a path + based on the wallet birthday, and use a path based on an incrementing + counter. He recommended the birthday-based approach. + + He also recommended dropping most of the [BIP48][] path elements as + unnecessary due to the increasingly widespread use of [descriptor][topic descriptors] + wallets, especially for multisig and complex script wallets. However, + Salvatore Ingala [replied][ingala bip48] to suggest keeping the _coin + type_ part of the BIP48 path as it helps ensure keys for use with + different cryptocurrencies are kept segregated, which is enforced by + some hardware signing devices. + +## Bitcoin Core PR Review Club + +*In this monthly section, we summarize a recent [Bitcoin Core PR Review +Club][] meeting, highlighting some of the important questions and +answers. Click on a question below to see a summary of the answer from +the meeting.* + +FIXME:stickies-v + +{% include functions/details-list.md + q0="FIXME" + a0="FIXME" + a0link="https://bitcoincore.reviews/31664#l-19FIXME" +%} + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [LND 0.19.0-beta.rc4][] is a release candidate for this popular LN + node. One of the major improvements that could probably use testing + is the new RBF-based fee bumping for cooperative closes. + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [Core Lightning #8227][] lsps: Add service implementation for LSPS0 + +- [Core Lightning #8162][] lightningd: allow up to 100 "slow open" channels before forgetting them. + +- [Core Lightning #8166][] lightningd: improve wait API by making details fields per-subsystem. + +- [Core Lightning #8237][] lightningd: add `short_channel_id` option to listpeerchannels. + +- [LDK #3700][] (3/3) Add Failure Reason to HTLCHandlingFailed + +- [Rust Bitcoin #4387][] bip32: overhaul error types and add a "maximum depth exceeded" error + +- [BIPs #1835][] BIP48: Add p2tr script type derivation + +- [BIPs #1800][] BIP 54: Consensus Cleanup + +- [BOLTs #1245][] Require minimally-encoded fields in BOLT 11 invoices + +{% include snippets/recap-ad.md when="2025-05-13 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="8227,8162,8166,8237,3700,4387,1835,1800,1245" %} +[lnd 0.19.0-beta.rc4]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc4 +[wuille clustrade]: https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/68 +[somsen bip30]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPv7TjZTWhgzzdps3vb0YoU3EYJwThDFhNLkf4XmmdfhbORTaw@mail.gmail.com/ +[loaec bip32reuse]: https://delvingbitcoin.org/t/avoiding-xpub-derivation-reuse-across-wallets-in-a-ux-friendly-manner/1644 +[ingala bip48]: https://delvingbitcoin.org/t/avoiding-xpub-derivation-reuse-across-wallets-in-a-ux-friendly-manner/1644/3 +[news346 checkpoints]: /en/newsletters/2025/03/21/#bitcoin-core-31649 From b8b86f8a1382cf89b66ef5fc28547b7ec812217f Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 8 May 2025 08:40:55 +0000 Subject: [PATCH 003/278] News353: add merge summaries --- _includes/references.md | 1 + .../en/newsletters/2025-05-09-newsletter.md | 75 ++++++++++++++----- 2 files changed, 58 insertions(+), 18 deletions(-) diff --git a/_includes/references.md b/_includes/references.md index 3b1d0c6347..cb73815d8a 100644 --- a/_includes/references.md +++ b/_includes/references.md @@ -94,6 +94,7 @@ for details --> {% endcomment %} [BIP49]: https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki [BIP50]: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki [BIP52]: https://github.com/bitcoin/bips/blob/master/bip-0052.mediawiki +[BIP54]: https://github.com/bitcoin/bips/blob/master/bip-0052.mediawiki [BIP61]: https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki [BIP62]: https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki [BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki diff --git a/_posts/en/newsletters/2025-05-09-newsletter.md b/_posts/en/newsletters/2025-05-09-newsletter.md index 764c2cbb76..4c52695044 100644 --- a/_posts/en/newsletters/2025-05-09-newsletter.md +++ b/_posts/en/newsletters/2025-05-09-newsletter.md @@ -94,30 +94,69 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Core Lightning #8227][] lsps: Add service implementation for LSPS0 - -- [Core Lightning #8162][] lightningd: allow up to 100 "slow open" channels before forgetting them. - -- [Core Lightning #8166][] lightningd: improve wait API by making details fields per-subsystem. - -- [Core Lightning #8237][] lightningd: add `short_channel_id` option to listpeerchannels. - -- [LDK #3700][] (3/3) Add Failure Reason to HTLCHandlingFailed - -- [Rust Bitcoin #4387][] bip32: overhaul error types and add a "maximum depth exceeded" error - -- [BIPs #1835][] BIP48: Add p2tr script type derivation - -- [BIPs #1800][] BIP 54: Consensus Cleanup - -- [BOLTs #1245][] Require minimally-encoded fields in BOLT 11 invoices +- [Core Lightning #8227][] adds Rust-based `lsps-client` and `lsps-service` + plugins that implement a communication protocol between LSP nodes and their + clients, using a JSON-RPC format over [BOLT8][] peer-to-peer messages, as + specified in [BLIP50][] (see Newsletter [#335][news335 blip50]). This lays + the foundation for implementing incoming liquidity requests as specified in + [BLIP51][], and [JIT channels][topic jit channels] as specified in [BLIP52][]. + +- [Core Lightning #8162][] updates the handling of peer-initiated pending + channel opens by retaining them indefinitely, up to a limit of the 100 most + recent. Previously, unconfirmed channel opens were forgotten after 2016 + blocks. In addition, closed channels are now held in memory to allow a node to + respond to a peer’s `channel_reestablish` message. + +- [Core Lightning #8166][] enhances the `wait` RPC command by replacing its + single `details` object with subsystem-specific objects: `invoices`, + `forwards`,`sendpays`, and [`htlcs`][topic htlc]. In addition, the `listhtlcs` + RPC now supports pagination via new `created_index` and `updated_index` fields + and the `index`, `start`, and `end` parameters. + +- [Core Lightning #8237][] adds a `short_channel_id` parameter to the + `listpeerchannels` RPC command to return only a specific channel, if provided. + +- [LDK #3700][] adds a new `failure_reason` field to the `HTLCHandlingFailed` + event to provide additional information about why the [HTLC][topic htlc] + failed, and whether the cause was local or downstream. The + `failed_next_destination` field is renamed to `failure_type` and the + `UnknownNextHop` variant is deprecated, and replaced by the more general + `InvalidForward`. + +- [Rust Bitcoin #4387][] refactors [BIP32][topic bip32] error handling by + replacing the single `bip32::Error` with separate enums for derivation, child + number/path parsing, and extended key parsing. This PR also introduces a new + `DerivationError::MaximumDepthExceeded` variant for paths exceeding 256 + levels. These API changes break the backwards compatibility. + +- [BIPs #1835][] updates [BIP48][] (see Newsletter [#135][news135 bip48]) to + reserve the script type value 3 for [taproot][topic taproot] (P2TR) + derivations in deterministic multisig wallets with the m/48' prefix, in + addition to the existing P2SH-P2WSH (1′) and P2WSH (2′) script types. + +- [BIPs #1800][] merges [BIP54][], which specifies the [consensus cleanup soft + fork][topic consensus cleanup] proposal to fix a number of long-standing + vulnerabilities in the Bitcoin protocol. See Newsletter [#348][news348 + cleanup] for a detailed description of this BIP. + +- [BOLTs #1245][] tightens [BOLT11][] by disallowing non-minimal length + encodings in invoices: the expiry (x), the [CLTV expiry delta][topic cltv + expiry delta] for the last hop (c), and feature bits (9) fields must be + serialized in minimal length without leading zeros, and readers should reject + any invoice that contains leading zeros. This change was motivated by fuzz + testing that detected that when LDK reserialize non-minimal invoices to + minimal (stripping out the extra zeros), it causes the invoice’s ECDSA + signature to fail validation. {% include snippets/recap-ad.md when="2025-05-13 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="8227,8162,8166,8237,3700,4387,1835,1800,1245" %} +{% include linkers/issues.md v=2 issues="8227,8162,8166,8237,3700,4387,1835,1800,1245,50,51,52" %} [lnd 0.19.0-beta.rc4]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc4 [wuille clustrade]: https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/68 [somsen bip30]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPv7TjZTWhgzzdps3vb0YoU3EYJwThDFhNLkf4XmmdfhbORTaw@mail.gmail.com/ [loaec bip32reuse]: https://delvingbitcoin.org/t/avoiding-xpub-derivation-reuse-across-wallets-in-a-ux-friendly-manner/1644 [ingala bip48]: https://delvingbitcoin.org/t/avoiding-xpub-derivation-reuse-across-wallets-in-a-ux-friendly-manner/1644/3 [news346 checkpoints]: /en/newsletters/2025/03/21/#bitcoin-core-31649 +[news335 blip50]: /en/newsletters/2025/01/03/#blips-52 +[news135 bip48]: /en/newsletters/2021/07/28/#bips-1072 +[news348 cleanup]: /en/newsletters/2025/04/04/#draft-bip-published-for-consensus-cleanup From 4538b0e4f5f46d326a2fde582258603a64739e22 Mon Sep 17 00:00:00 2001 From: stickies-v Date: Thu, 8 May 2025 15:50:20 +0100 Subject: [PATCH 004/278] News353: add review club --- .../en/newsletters/2025-05-09-newsletter.md | 72 +++++++++++++++++-- 1 file changed, 67 insertions(+), 5 deletions(-) diff --git a/_posts/en/newsletters/2025-05-09-newsletter.md b/_posts/en/newsletters/2025-05-09-newsletter.md index 4c52695044..984daa3bef 100644 --- a/_posts/en/newsletters/2025-05-09-newsletter.md +++ b/_posts/en/newsletters/2025-05-09-newsletter.md @@ -65,12 +65,71 @@ Club][] meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.* -FIXME:stickies-v +[Add bitcoin wrapper executable][review club 31375] is a PR by +[ryanofsky][gh ryanofsky] that introduces a new `bitcoin` binary which +can be used to discover and launch the various Bitcoin Core binaries. + +Bitcoin Core v29 shipped with 7 binaries (e.g. `bitcoind`, `bitcoin-qt` +and `bitcoin-cli`), but that number is set to [increase][Bitcoin Core +#30983] in the future when [multiprocess][multiprocess design] binaries +are shipped as well. The new `bitcoin` wrapper maps commands (e.g. +`gui`) to the correct monolithic (`bitcoin-qt`) or multiprocess +(`bitcoin-gui`) binary. In addition to discoverability, the wrapper also +provides forward compatibility so binaries can be reorganized without +the user interface changing. + +With this PR, a user can launch Bitcoin Core with `bitcoin daemon` or +`bitcoin gui`. Directly launching the `bitcoind` or `bitcoin-qt` +binaries is still possible and not affected by this PR. {% include functions/details-list.md - q0="FIXME" - a0="FIXME" - a0link="https://bitcoincore.reviews/31664#l-19FIXME" + q0="From issue #30983, four packaging strategies were listed. Which + specific drawbacks of the “side‑binaries” approach does this PR + address?" + a0="The side-binaries approach assumed by this PR involves releasing + the new multiprocess binaries alongside the existing monolithic + binaries. With this many binaries, it can be confusing for users to + find and figure out the binary they need for their purpose. This PR + takes a lot of the confusion away by providing a single entry point, + with an overview of options and a help string. One reviewer suggested + the addition of fuzzy search to facilitate this even further." + a0link="https://bitcoincore.reviews/31375#l-40" + q1="`GetExePath()` does not use `readlink(\"/proc/self/exe\")` on + Linux even though it would be more direct. What advantages does the + current implementation have? What corner cases might it miss?" + a1="There may be other non-Windows platforms that do not have the proc + filesystem. Other than that, neither the author nor guests could + identify any drawbacks of using procfs." + a1link="https://bitcoincore.reviews/31375#l-71" + q2="In `ExecCommand`, explain the purpose of the `fallback_os_search` + Boolean. Under what circumstances is it better to avoid letting the OS + search for the binary on the `PATH`?" + a2="If it looks like the wrapper executable was invoked by path (e.g. + \"/build/bin/bitcoin\") rather than by search (e.g. \"bitcoin\"), it + is assumed the user is using a local build and `fallback_os_search` is + set to `false`. This boolean is introduced to unintentionally mix + binaries from different sources. For example, if the user didn't + locally build `gui`, then `/build/bin/bitcoin gui` should not fall + back to the system installed `bitcoin-gui`. The author is considering + removing the `PATH` search entirely, and user feedback would be + helpful." + a2link="https://bitcoincore.reviews/31375#l-75" + q3="The wrapper searches `${prefix}/libexec` only when it detects that + it is running from an installed `bin/` directory. Why not always + search `libexec`?" + a3="The wrapper should be conservative about what paths it tries to + execute, and encourage standard `PREFIX/{bin,libexec}` layouts, not + encourage packagers to create nonstandard layouts or work when + binaries are arranged in unexpected ways." + a3link="https://bitcoincore.reviews/31375#l-75" + q4="The PR adds an exemption in `security-check.py` because the + wrapper contains no fortified `glibc` calls. Why does it not contain + them, and would adding a trivial `printf` to `bitcoin.cpp` break + reproducible builds under the current rules?" + a4="The wrapper binary is so simple it does not contain any calls that + can be fortified. If it does in the future, the exemption in + security-check.py can be removed." + a4link="https://bitcoincore.reviews/31375#l-117" %} ## Releases and release candidates @@ -150,7 +209,7 @@ repo], and [BINANAs][binana repo]._ {% include snippets/recap-ad.md when="2025-05-13 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="8227,8162,8166,8237,3700,4387,1835,1800,1245,50,51,52" %} +{% include linkers/issues.md v=2 issues="8227,8162,8166,8237,3700,4387,1835,1800,1245,50,51,52,30983" %} [lnd 0.19.0-beta.rc4]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc4 [wuille clustrade]: https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/68 [somsen bip30]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPv7TjZTWhgzzdps3vb0YoU3EYJwThDFhNLkf4XmmdfhbORTaw@mail.gmail.com/ @@ -160,3 +219,6 @@ repo], and [BINANAs][binana repo]._ [news335 blip50]: /en/newsletters/2025/01/03/#blips-52 [news135 bip48]: /en/newsletters/2021/07/28/#bips-1072 [news348 cleanup]: /en/newsletters/2025/04/04/#draft-bip-published-for-consensus-cleanup +[review club 31375]: https://bitcoincore.reviews/31375 +[gh ryanofsky]: https://github.com/ryanofsky +[multiprocess design]: https://github.com/bitcoin/bitcoin/blob/master/doc/design/multiprocess.md From 1d0d0bfa1c56a30d9f74888164a752e9dc4f80fa Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Fri, 9 May 2025 05:12:41 -0500 Subject: [PATCH 005/278] News353: add topics --- _topics/en/consensus-cleanup-soft-fork.md | 6 ++++-- _topics/en/duplicate-transactions.md | 3 +++ _topics/en/hd-key-generation.md | 3 +++ _topics/en/output-linking.md | 3 +++ _topics/en/responsible-disclosures.md | 3 +++ 5 files changed, 16 insertions(+), 2 deletions(-) diff --git a/_topics/en/consensus-cleanup-soft-fork.md b/_topics/en/consensus-cleanup-soft-fork.md index 64a48f700c..09c1858da2 100644 --- a/_topics/en/consensus-cleanup-soft-fork.md +++ b/_topics/en/consensus-cleanup-soft-fork.md @@ -18,8 +18,7 @@ excerpt: > ## Optional. Produces a Markdown link with either "[title][]" or ## "[title](link)" primary_sources: - - title: Draft BIP for Consensus Cleanup - link: https://github.com/darosior/bips/blob/consensus_cleanup/bip-0054.md + - title: BIP54 ## Optional. Each entry requires "title", "url", and "date". May also use "feature: ## true" to bold entry @@ -63,6 +62,9 @@ optech_mentions: - title: "Draft BIP published for consensus cleanup" url: /en/newsletters/2025/04/04/#draft-bip-published-for-consensus-cleanup + - title: "BIPs #1800 merges BIP54, which specifies the consensus cleanup soft fork proposal" + url: /en/newsletters/2025/05/09/#bips-1800 + ## Optional. Same format as "primary_sources" above see_also: - title: Soft fork activation diff --git a/_topics/en/duplicate-transactions.md b/_topics/en/duplicate-transactions.md index b025a2ffd2..c95755ec7f 100644 --- a/_topics/en/duplicate-transactions.md +++ b/_topics/en/duplicate-transactions.md @@ -39,6 +39,9 @@ optech_mentions: - title: "Consensus cleanup proposal updated to require setting coinbase lock time to previous block height" url: /en/newsletters/2025/02/07/#duplicate-transaction-fix + - title: "BIP30 consensus failure vulnerability if chain is reorged below block 91880" + url: /en/newsletters/2025/05/09/#bip30-consensus-failure-vulnerability + ## Optional. Same format as "primary_sources" above see_also: - title: Consensus cleanup soft fork diff --git a/_topics/en/hd-key-generation.md b/_topics/en/hd-key-generation.md index 2448ebf121..a0b0c4196e 100644 --- a/_topics/en/hd-key-generation.md +++ b/_topics/en/hd-key-generation.md @@ -90,6 +90,9 @@ optech_mentions: - title: "BIP328 added with a specifications BIP32-compatible MuSig2 key derivation" url: /en/newsletters/2024/07/05/#bips-1540 + - title: "Proposed scheme to prevent BIP32 path reuse to avoid output linking and other problems" + url: /en/newsletters/2025/05/09/#avoiding-bip32-path-reuse + ## Optional. Same format as "primary_sources" above see_also: - title: Output script descriptors diff --git a/_topics/en/output-linking.md b/_topics/en/output-linking.md index ba4d5fc781..1e6841c517 100644 --- a/_topics/en/output-linking.md +++ b/_topics/en/output-linking.md @@ -78,6 +78,9 @@ optech_mentions: - title: "Recommendations for unique address servers" url: /en/newsletters/2022/10/12/#recommendations-for-unique-address-servers + - title: "Proposed scheme to prevent BIP32 path reuse to avoid output linking and other problems" + url: /en/newsletters/2025/05/09/#avoiding-bip32-path-reuse + ## Optional. Same format as "primary_sources" above see_also: - title: Uneconomical outputs (dust) diff --git a/_topics/en/responsible-disclosures.md b/_topics/en/responsible-disclosures.md index b5b3bb63bb..c66d38570d 100644 --- a/_topics/en/responsible-disclosures.md +++ b/_topics/en/responsible-disclosures.md @@ -164,6 +164,9 @@ optech_mentions: - title: "Matt Morehouse responsibly disclosed a vulnerability allowing theft from LND" url: /en/newsletters/2025/03/07/#disclosure-of-fixed-lnd-vulnerability-allowing-theft + - title: "Ruben Somsen responsibly disclosed a theoretical BIP30 consensus failure vulnerability" + url: /en/newsletters/2025/05/09/#bip30-consensus-failure-vulnerability + ## Optional. Same format as "primary_sources" above see_also: - title: "Common Vulnerabilities and Exposures (CVEs)" From 840df0e3cbdf73a86a35c76ebb84526ae1fdecd4 Mon Sep 17 00:00:00 2001 From: Jiri Jakes Date: Fri, 9 May 2025 17:47:49 +0800 Subject: [PATCH 006/278] Newsletter-353: Translate into Czech --- .../cs/newsletters/2025-05-09-newsletter.md | 209 ++++++++++++++++++ 1 file changed, 209 insertions(+) create mode 100644 _posts/cs/newsletters/2025-05-09-newsletter.md diff --git a/_posts/cs/newsletters/2025-05-09-newsletter.md b/_posts/cs/newsletters/2025-05-09-newsletter.md new file mode 100644 index 0000000000..cabbc5cf21 --- /dev/null +++ b/_posts/cs/newsletters/2025-05-09-newsletter.md @@ -0,0 +1,209 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 353' +permalink: /cs/newsletters/2025/05/09/ +name: 2025-05-09-newsletter-cs +slug: 2025-05-09-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden popisuje nedávno objevenou zranitelnost teoreticky +způsobující selhání konsenzu a odkazuje na navrhovaný způsob bránící +opakovanému používání BIP32 cest v peněženkách. Též nechybí naše pravidelné +rubriky se souhrnem nedávného sezení Bitcoin Core PR Review Clubu, oznámeními +nových vydání a popisem významných změn v populárním bitcoinovém páteřním +software. + +## Novinky + +- **BIP30 a zranitelnost způsobující selhání konsenzu:** Ruben Somsen zaslal do + emailové skupiny Bitcoin-Dev [příspěvek][somsen bip30] o teoretickém selhání + konsenzu, které by mohlo nastat po nedávném odstranění checkpointů z Bitcoin + Core (viz [zpravodaj č. 346][news346 checkpoints]). Ve stručnosti: mincetvorné + transakce z bloků 91 722 a 91 812 jsou [opakovaně použité][topic duplicate + transactions] i v blocích 91 880 a 91 842. [BIP30][] určuje, že tyto dva + pozdější bloky by měly být zpracovány stejným způsobem jako v roce 2010, tedy + přepsáním dřívějších záznamů v množině UTXO. Somsen však poznamenává, že + reorganizace jednoho či obou pozdějších bloků by vyústila v odstranění + duplikovaných položek z množiny UTXO; tím by v množině nebyla ani jedna ze + čtyř položek. Avšak nově spuštěný uzel, který nikdy duplikované transakce + neviděl, by stále měl dřívější dvě transakce. Tento uzel by tedy měl jinou + množinu UTXO, což by mohlo vyvolat selhání konsenzu v případě utracení některé + z těchto transakcí. + + Dokud měl Bitcoin Core checkpointy, nepředstavovalo to problém, neboť + checkpointy vyžadovaly, aby byly všechny čtyři zmíněné bloky součástí nejlepšího + řetězce. I dnes se jedná o problém pouze v teoretickém případě, pokud + by selhal bezpečnostní mechanismus proof-of-work. Bylo diskutováno několik + možných řešení, mezi nimi například napevno zakódovat zvláštní logiku pro tyto + dvě výjimky. + +- **Jak zabránit opakovanému používání BIP32 cest:** Kevin Loaec započal + zasláním [příspěvku][loaec bip32reuse] do fóra Delving Bitcoin diskuzi o + možných způsobech zabraňování opakovaného použití stejných [BIP32][topic bip32] + cest napříč různými peněženkami, které by mohlo vést ke ztrátě soukromí kvůli + [vazbám mezi výstupy][topic output linking] a teoreticky i ke ztrátě + zabezpečení (např. pomocí [kvantových počítačů][topic quantum + resistance]). Navrhl tři možné přístupy: používání náhodných cest, používání + cest založených na čase vytvoření peněženky a používání cesty založené na + inkrementujícím čítači. Doporučil čas vytvoření peněženky. + + Dále též doporučil přestat používat většinu prvků cest dle [BIP48][], neboť + jsou již kvůli používání [deskriptorových][topic descriptors] peněženek + nepotřebné, obzvláště u peněženek s vícenásobnými podpisy nebo složitějšími + skripty. Salvatore Ingala však [navrhl][ingala bip48] zachovat _typ mince_ z + BIP48, neboť pomáhá zajistit, aby klíče pro různé kryptoměny zůstaly + oddělené. Některá hardwarová podpisová zařízení toto oddělení vynucují. + +## Bitcoin Core PR Review Club + +*V této měsíční rubrice shrnujeme nedávné sezení [Bitcoin Core PR Review Club][] a +vyzdvihujeme některé z důležitých otázek a odpovědí. Klikněte na otázku a odpověď se vám odhalí.* + +[Přidej spustitelnou pomocnou binárku bitcoin][review club 31375] („Add bitcoin +wrapper executable”) je PR od vývojáře [ryanofsky][gh ryanofsky] přinášející nový +spustitelný soubor `bitcoin`, který může být použit pro hledání a spouštění +různých programů v rámci Bitcoin Core. + +Bitcoin Core v29 obsahuje sedm binárek (např. `bitcoind`, `bitcoin-qt` a +`bitcoin-cli`), ale jejich počet se [navýší][Bitcoin Core #30983], až se Bitcoin +Core bude dodávat i ve [víceprocesové][multiprocess design] verzi. Nová binárka +`bitcoin` mapuje příkaz (např. `gui`) na správný monolitický (`bitcoin-qt`) nebo +víceprocesový (`bitcoin-gui`) program. Vedle lepšího přehledu o dostupných +programech poskytne `bitcoin` také kompatibilitu s budoucími verzemi. Programy +tak mohou být reorganizovány, aniž by se muselo změnit uživatelské rozhraní. + +S tímto PR může uživatel spustit Bitcoin Core jako `bitcoin daemon` nebo +`bitcoin gui`. Změna nemá žádný dopad na přímé spouštění pomocí `bitcoind` nebo +`bitcoin-qt`. + +{% include functions/details-list.md + q0="Z #30983 byly vyjmenovány čtyři strategie produkce balíčků. Které konkrétní + slabiny přístupu „s pomocnými binárkami” (side-binaries) toto PR adresuje?" + a0="Přístup s pomocnými binárkami, který toto PR zaujímá, předpokládá + vydání nový víceprocesových binárek spolu s existujícími monolitickými + binárkami. Pro uživatele může být obtížné najít, který z těchto spustitelných + souborů pro svůj účel potřebují. PR poskytuje jednotný vstupní bod, + který nabízí seznam možností a nápovědu. Jeden účastník sezení navrhl + přidání fuzzy hledání." + a0link="https://bitcoincore.reviews/31375#l-40" + + q1="`GetExePath()` na Linuxu nepoužívá `readlink(\"/proc/self/exe\")`, i když + by to bylo přímočařejší. Jaké výhody má současná implementace? Které okrajové + případy mohou zůstat nepokryté?" + a1="Mohou existovat i jiné newindowsovské platformy, které proc souborový systém + nemají. Kromě toho nemohli autor ani hosté najít jiné nevýhody používání procfs." + a1link="https://bitcoincore.reviews/31375#l-71" + + q2="Vysvětlete účel booleovské hodnoty `fallback_os_search` v `ExecCommand`. + Za jakých okolností je lepší nenechat OS vyhledat binárku v `PATH`?" + a2="Pokud se zdá, že byl `bitcoin` spuštěn s cestou (např. \"/build/bin/bitcoin\") + a ne s vyhledáním (tedy jako `bitcoin`), předpokládá se, že uživatel + chce použít lokální sestavení a `fallback_os_search` je nastaven na + `false`. Tato booleovská hodnota byla přidána, aby zabránila neúmyslnému + pomíchání binárek z různých zdrojů. Pokud uživatel na příklad lokálně nesestavil + `gui`, potom by se `/build/bin/bitcoin gui` nemělo pokusit spustit + `bitcoin-gui` nainstalovaný v systému. Autor zvažuje zcela odstranit hledání + v `PATH` a žádá o zpětnou vazbu." + a2link="https://bitcoincore.reviews/31375#l-75" + + q3="Nově přidaný spustitelný soubor vyhledá `${prefix}/libexec` pouze, pokud detekuje + spuštění z nainstalovaného adresáře `bin/`. Proč nehledat `libexec` vždy?" + a3="Měl by být konzervativní ve výběru cest pro spuštění a upřednostňovat + standardní `PREFIX/{bin,libexec}`. Neměl by vybízet k vytváření balíčků s + nestandardními cestami a neměl by fungovat, pokud jsou binárky + rozmístěny neočekávaně." + a3link="https://bitcoincore.reviews/31375#l-75" + + q4="PR přidává do `security-check.py` výjimku, protože spustitelný soubor + neobsahuje žádné zabezpečené volání `glibc`. Proč ne? Znamená to, že by + přidání triviálního `printf` do `bitcoin.cpp` rozbilo reprodukovatelná sestavení?" + a4="Nová binárka je tak jednoduchá, že neobsahuje žádná volání, která + by mohla být zabezpečena (fortified). Pokud by v budoucnosti taková + volání byla potřebná, výjimka by se mohla odstranit." + a4link="https://bitcoincore.reviews/31375#l-117" +%} + +## Vydání nových verzí + +*Vydání nových verzí oblíbených páteřních bitcoinových projektů. Prosíme, +zvažte upgrade či pomoc s testováním.* + +- [LND 0.19.0-beta.rc4][] je kandidátem na vydání tohoto oblíbeného LN uzlu. + Jedním významným vylepšením, které by si zasloužilo důkladné testování, je + nové schéma RBF navyšování poplatků během kooperativního zavření kanálu. + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo] a [repozitáři BINANA][binana repo]._ + +- [Core Lightning #8227][] přidává rustové pluginy `lsps-client` a `lsps-service`, + které implementují komunikační protokol mezi LSP uzly a jejich klienty. + Protokol používá JSON-RPC a [BOLT8][] peer-to-peer zprávy dle specifikace v + [BLIP50][] (viz [zpravodaj č. 335][news335 blip50]). Jedná se o základ + pro implementaci příchozích žádostí o likviditu dle [BLIP51][] a + [JIT kanálů][topic jit channels] dle [BLIP52][]. + +- [Core Lightning #8162][] bude nově trvale držet až sto probíhajících procesů + otevírání kanálů vyžádaných protistranou. Dříve byla nepotvrzená + otevření kanálů po 2 016 blocích zapomenuta. Dále jsou zavřené kanály + nově držené v paměti, aby mohl uzel reagovat na zprávu `channel_reestablish`. + +- [Core Lightning #8166][] nahrazuje v odpovědi RPC příkazu `wait` jediný + objekt `details` objektem dle dotčeného podsystému: `invoices`, `forwards`, + `sendpays` a [`htlcs`][topic htlc]. Dále přidává stránkování do `listhtlcs` + (pole `created_index`, `updated_index` a parametry `index`, `start`, `end`). + +- [Core Lightning #8237][] přidává do RPC příkazu `listpeerchannels` volitelný + parametr `short_channel_id`, který vrátí pouze konkrétní kanál. + +- [LDK #3700][] přidává do události `HTLCHandlingFailed` nové pole `failure_reason` + s dodatečnými informacemi o důvodech a původu selhání [HTLC][topic htlc]. + Pole `failed_next_destination` je přejmenováno na `failure_type` a varianta + `UnknownNextHop` je nahrazena obecnější `InvalidForward`. + +- [Rust Bitcoin #4387][] refaktoruje chyby v implementaci [BIP32][topic bip32]. + Jediný typ `bip32::Error` nahrazuje výčtovými typy vyhrazenými pro derivaci, parsování + cest a parsování rozšířených klíčů. Dále přináší variantu `DerivationError::MaximumDepthExceeded` + pro cesty mající více než 256 úrovní. Změny nejsou zpětně kompatibilní. + +- [BIPs #1835][] rezervuje v [BIP48][] (viz [zpravodaj č. 135][news135 bip48], _angl._) + typ skriptu 3' pro [taproot][topic taproot] (P2TR) v deterministických + multisig peněženkách s prefixem m/48'. Existující hodnoty jsou 1' pro + P2SH-P2WSH a 2' pro P2WSH. + +- [BIPs #1800][] začleňuje [BIP54][], který specifikuje návrh na [soft fork + pročištění konsenzu][topic consensus cleanup] opravující několik dlouhodobých + zranitelností v bitcoinovém protokolu. [Zpravodaj č. 348][news348 cleanup] + popisuje tento BIP podrobněji. + +- [BOLTs #1245][] znemožňuje používat v [BOLT11][] fakturách kódování nemající minimální + délku: expirační lhůta (`x`), [CLTV expiry delta][topic cltv expiry delta] posledního + skoku (`c`) a bity s popisem podporovaných funkcí (`9`) musí být nově serializované + s minimální délkou bez úvodních nul. Příjemci by měli faktury s úvodními nulami + odmítnout. Změna byla motivována fuzz testováním, které zjistilo, že když LDK + serializuje neminimální faktury na minimální (odstraní nadbytečné nuly), způsobuje + to selhání validace ECDSA podpisů. + +{% include snippets/recap-ad.md when="2025-05-13 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="8227,8162,8166,8237,3700,4387,1835,1800,1245,50,51,52,30983" %} +[lnd 0.19.0-beta.rc4]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc4 +[wuille clustrade]: https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/68 +[somsen bip30]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPv7TjZTWhgzzdps3vb0YoU3EYJwThDFhNLkf4XmmdfhbORTaw@mail.gmail.com/ +[loaec bip32reuse]: https://delvingbitcoin.org/t/avoiding-xpub-derivation-reuse-across-wallets-in-a-ux-friendly-manner/1644 +[ingala bip48]: https://delvingbitcoin.org/t/avoiding-xpub-derivation-reuse-across-wallets-in-a-ux-friendly-manner/1644/3 +[news346 checkpoints]: /cs/newsletters/2025/03/21/#bitcoin-core-31649 +[news335 blip50]: /cs/newsletters/2025/01/03/#blips-52 +[news135 bip48]: /en/newsletters/2021/07/28/#bips-1072 +[news348 cleanup]: /cs/newsletters/2025/04/04/#zverejnen-navrh-bipu-na-procisteni-konsenzu +[review club 31375]: https://bitcoincore.reviews/31375 +[gh ryanofsky]: https://github.com/ryanofsky +[multiprocess design]: https://github.com/bitcoin/bitcoin/blob/master/doc/design/multiprocess.md From c878db65184e579f3a00942048cd3e86ee987188 Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 9 May 2025 20:36:35 +0900 Subject: [PATCH 007/278] Newsletter-353:Translate into Japanese --- .../ja/newsletters/2025-05-09-newsletter.md | 188 ++++++++++++++++++ 1 file changed, 188 insertions(+) create mode 100644 _posts/ja/newsletters/2025-05-09-newsletter.md diff --git a/_posts/ja/newsletters/2025-05-09-newsletter.md b/_posts/ja/newsletters/2025-05-09-newsletter.md new file mode 100644 index 0000000000..a3d13b63e1 --- /dev/null +++ b/_posts/ja/newsletters/2025-05-09-newsletter.md @@ -0,0 +1,188 @@ +--- +title: 'Bitcoin Optech Newsletter #353' +permalink: /ja/newsletters/2025/05/09/ +name: 2025-05-09-newsletter-ja +slug: 2025-05-09-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、最近発見された理論上のコンセンサス障害の脆弱性と、 +BIP32ウォレットパスの再利用を回避するための提案のリンクを掲載しています。 +また、Bitcoin Core PR Review Clubミーティングの概要や、新しいリリースおよびリリース候補の発表、 +人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更点など恒例のセクションも含まれています。 + +## ニュース + +- **BIP30コンセンサス障害の脆弱性:** Ruben Somsenは、 + Bitcoin Coreからチェックポイントが削除された（[ニュースレター #346][news346 checkpoints]参照）ことで + 発生する可能性がある理論上のコンセンサス障害についてBitcoin-Devメーリングリストに[投稿しました][somsen bip30]。 + 簡単に言うと、ブロック91722と91812のコインベーストランザクションが、 + ブロック91880と91842で[重複][topic duplicate transactions]している点です。[BIP30][]では、これらの2つのブロックは、 + 2010年のBitcoin Coreの旧バージョンで処理された方法、 + つまりUTXOセット内で前のコインベースエントリーを重複する後続のエントリーで上書きする方法で処理するよう規定しています。 + しかし、Somsenは、後続ブロックのいずれか、または両方が再編成されると、 + 重複エントリーがUTXOセットから削除され、上書きにより以前のエントリーも失われてしまうと指摘しています。 + しかし、重複トランザクションを一度も確認したことのない新規ノードは、 + 以前のトランザクションを保持した状態で異なるUTXOセットを作成し、 + いずれかのトランザクションが使用された場合にコンセンサス障害につながる可能性があります。 + + Bitcoin Coreにチェックポイントがあった頃は、上記の4つのブロックがすべてベストブロックチェーンの一部である必要があったため、 + これは問題になりませんでした。現在は、BitcoinのProof of Workのセキュリティメカニズムが理論上破綻しない限り、 + 実際には問題にはなりません。これらの2つの例外に対して、追加の特殊ケースロジックをハードコードするなど、 + いくつかの解決策が議論されています。 + +- **BIP32パスの再利用の回避:** Kevin Loaecは、 + 同じ[BIP32][topic bip32]ウォレットパスが異なるウォレットで使われるのを防ぐ方法について + Delving Bitcoinに[投稿しました][loaec bip32reuse]。 + これは、[アウトプットのリンク][topic output linking]によるプライバシーの損失や、 + （[量子コンピューター][topic quantum resistance]などによる）理論的なセキュリティの損失につながる可能性があります。 + 彼は、ランダムパスの使用、ウォレットの誕生日に基づくパスの使用、 + インクリメントカウンターに基づくパスの使用という3つのアプローチを提案し、 + 誕生日ベースのアプローチを推奨しました。 + + また、[ディスクリプター][topic descriptors]ウォレット、特にマルチシグや複雑なスクリプトの普及に伴い、 + [BIP48][]のパス要素のほとんどを不要として削除することを推奨しました。 + しかし、Salvatore Ingalaは、一部のハードウェア署名デバイスによって強制されているように、 + 異なる暗号通貨で使用される鍵が分離された状態を保つのに役立つため、 + BIP48のパスの _coin type_ 部分は維持するよう[提案しました][ingala bip48]。 + +## Bitcoin Core PR Review Club + +*この毎月のセクションでは、最近の[Bitcoin Core PR Review Club][]ミーティングを要約し、 +重要な質問と回答のいくつかに焦点を当てます。 +以下の質問をクリックしてミーティングでの回答の要約を確認してください。* + +[Add bitcoin wrapper executable][review club 31375]は、 +[ryanofsky][gh ryanofsky]によるPRで、さまざまなBitcoin Coreバイナリを検出して起動するのに +使える新しい`bitcoin`バイナリを導入します。 + +Bitcoin Core v29は7つのバイナリ（`bitcoind`、`bitcoin-qt`、`bitcoin-cli`など）と一緒にリリースされましたが、 +将来[マルチプロセス][multiprocess design]バイナリもリリースされると、 +その数は[増えていきます][Bitcoin Core #30983]。新しい`bitcoin`ラッパーは、 +コマンド（`gui`など）を正しいモノリシック（`bitcoin-qt`）またはマルチプロセス（`bitcoin-gui`）バイナリにマッピングします。 +検出機能に加えて、ラッパーはユーザーインターフェースを変更することなくバイナリを再編成できるように前方互換性も提供します。 + +このPRにより、ユーザーは`bitcoin daemon`または`bitcoin gui`でBitcoin Coreを起動できます。 +`bitcoind`や`bitcoin-qt`で直接起動することも引き続き可能で、このPRによる影響はありません。 + +{% include functions/details-list.md + q0="Issue #30983では、4つのパッケージ戦略がリストアップされています。 + このPRは「サイドバイナリ」アプローチの具体的な欠点のうち、どのような点に対処しているのでしょうか？" + a0="このPRで想定されているサイドバイナリアプローチでは、 + 新しいマルチプロセスバイナリを既存のモノリシックバイナリと並行してリリースします。 + 多数のバイナリがあると、ユーザーは自分の目的のバイナリを見つけて理解するのが難しくなります。 + このPRは、オプションの概要とヘルプ文言を含む単一のエントリーポイントを提供することで、 + こうした混乱を大幅に軽減します。あるレビュアーは、これをさらに簡単にするためにあいまい検索の追加を提案しました。" + a0link="https://bitcoincore.reviews/31375#l-40" + q1="`GetExePath()`は、Linuxではより直接的な方法であるにもかかわらず、 + `readlink(\"/proc/self/exe\")`を使用しません。現在の実装にはどんな利点があるのでしょうか？ + どのようなエッジケースが見落とされる可能性があるのでしょうか？" + a1="procファイルシステムを持たない他の非Windowsプラットフォームが存在する可能性があります。 + それ以外に、作者もゲストもprocfsを使用することの欠点は特定できませんでした。" + a1link="https://bitcoincore.reviews/31375#l-71" + q2="`ExecCommand`における`fallback_os_search`ブール値の目的を説明してください。 + OSが`PATH`上のバイナリを検索させないほうが良い状況はどのような場合ですか？" + a2="ラッパー実行ファイルが検索（例：\"bitcoin\"）ではなくパス（例：\"/build/bin/bitcoin\"）で呼び出されるように見える場合、 + ユーザーがローカルビルドを使用していると想定され、`fallback_os_search`には`false`がセットされます。 + たとえば、ユーザーが`gui`をローカルでビルドしていない場合、 + `/build/bin/bitcoin gui`はシステムインストールされた`bitcoin-gui`にフォールバックするべきではありません。 + 作者は、`PATH`検索を完全に削除することを検討しており、ユーザーからのフィードバックが役立つでしょう。" + a2link="https://bitcoincore.reviews/31375#l-75" + q3="ラッパーは、インストールされた`bin/`ディレクトリから実行されていることを検知した場合のみ、 + `${prefix}/libexec`を検索します。なぜ、常に`libexec`を検索しないのでしょうか？" + a3="ラッパーは、実行しようとするパスについて保守的であるべきで、 + 標準の`PREFIX/{bin,libexec}`レイアウトを推奨すべきです。 + パッケージの作成者が非標準のレイアウトを作成したり、 + 予期しない方法で配置されたバイナリで動作したりすることを推奨すべきではありません。" + a3link="https://bitcoincore.reviews/31375#l-75" + q4="PRでは、ラッパーにFORTIFYが有効になった`glibc`呼び出しが含まれていないため、 + `security-check.py`に例外を追加しています。なぜそれらが含まれていないのでしょうか。 + また、`bitcoin.cpp`に単純な`printf`を追加すると、現在のルールでは再現可能なビルドが機能しなくなるのでしょうか？" + a4="ラッパーバイナリは非常に単純なため、FORTIFYが有効になった呼び出しは含まれていません。 + 将来的にそのような呼び出しが含まれるようになった場合は、`security-check.py`の例外を削除できます。" + a4link="https://bitcoincore.reviews/31375#l-117" +%} + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [LND 0.19.0-beta.rc4][]は、この人気のLNノードのリリース候補です。 + おそらくテストが必要な主な改善の1つは、協調クローズにおける新しいRBFベースの手数料引き上げです。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Core Lightning #8227][]は、[BLIP50][]で定義されているように（ニュースレター [#335][news335 blip50]参照）、 + [BOLT8][]ピアツーピアメッセージ上でJSON-RPC形式を用いて、 + LSPノードとそのクライアント間の通信プロトコルを実装するRustベースの + `lsps-client`および`lsps-service`プラグインを追加します。これは、 + [BLIP51][]で定義されている流動性リクエストの受信と + [BLIP52][]で定義されている[JITチャネル][topic jit channels]の実装の基盤となります。 + +- [Core Lightning #8162][]は、ピアによって開始された保留中のチャネル開設の処理を更新し、 + 最新100件まで無期限に保持するようにしました。これまでは、未承認のチャネル開設は2016ブロック後に消去されていました。 + さらに、ノードがピアの`channel_reestablish`メッセージに応答できるように、 + 閉じられたチャネルはメモリに保持されるようになりました。 + +- [Core Lightning #8166][]は、`wait` RPCコマンドを強化し、 + 単一の`details`オブジェクトをサブシステム別のオブジェクト + `invoices`、`forwards`、`sendpays`および[`htlcs`][topic htlc]に置き換えました。 + さらに、`listhtlcs` RPCは現在、新しい`created_index`と`updated_index`フィールドおよび、 + `index`、`start`、`end`パラメーターによるページネーションをサポートします。 + +- [Core Lightning #8237][]は、`listpeerchannels` RPCコマンドに + `short_channel_id`パラメーターを追加し、提供された場合に指定されたチャネルのみを返します。 + +- [LDK #3700][]は、[HTLC][topic htlc]が失敗した理由と、 + 原因がローカルか下流かについての追加情報を提供するために`HTLCHandlingFailed`イベントに + 新しい`failure_reason`フィールドを追加します。`failed_next_destination`フィールドは、 + `failure_type`に名前が変更され、`UnknownNextHop`バリアントは非推奨となり、 + より汎用的な`InvalidForward`に置き換えられました。 + +- [Rust Bitcoin #4387][]は、[BIP32][topic bip32]のエラー処理をリファクタリングし、 + 単一の`bip32::Error`を、導出、子番号/パスのパース、拡張鍵のパース毎に別々の列挙型に置き換えました。 + このPRでは、256階層を超えるパスに対して、新しく`DerivationError::MaximumDepthExceeded`バリアントも導入されています。 + これらのAPIの変更により後方互換性が損なわれます。 + +- [BIPs #1835][]は、[BIP48][]（ニュースレター [#135][news135 bip48]参照）を更新し、 + m/48'プレフィックスを持つ決定論的マルチシグウォレットにおいて、 + 既存のP2SH-P2WSH (1′)およびP2WSH (2′)スクリプトタイプに加えて、 + [Taproot][topic taproot] (P2TR)導出用のスクリプトタイプ値3を予約しました。 + +- [BIPs #1800][]は、Bitcoinプロトコルに長年存在していた複数の脆弱性を修正するための + [コンセンサスクリーンアップソフトフォーク][topic consensus cleanup]提案を定義した + [BIP54][]をマージしました。このBIPの詳細については、ニュースレター[#348][news348 cleanup]をご覧ください。 + +- [BOLTs #1245][]は、インボイスにおける非最小長エンコーディングを禁止することで + [BOLT11][]を厳格化します。有効期限（x）、最終ホップの[CLTV有効期限delta][topic cltv + expiry delta]（c）および機能ビット（9）の各フィールドは、 + 先頭にゼロを付けずに最小の長さでシリアライズする必要があり、 + 読み取り側は先頭にゼロを含むインボイスを拒否する必要があります。 + この変更は、LDKが最小長以外のインボイスを最小長に再シリアライズ（余分なゼロを削除）すると、 + インボイスのECDSA署名が署名の検証に失敗するというファジングテストの結果に基づいています。 + +{% include snippets/recap-ad.md when="2025-05-13 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="8227,8162,8166,8237,3700,4387,1835,1800,1245,30983,50,51,52" %} +[lnd 0.19.0-beta.rc4]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc4 +[wuille clustrade]: https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/68 +[somsen bip30]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPv7TjZTWhgzzdps3vb0YoU3EYJwThDFhNLkf4XmmdfhbORTaw@mail.gmail.com/ +[loaec bip32reuse]: https://delvingbitcoin.org/t/avoiding-xpub-derivation-reuse-across-wallets-in-a-ux-friendly-manner/1644 +[ingala bip48]: https://delvingbitcoin.org/t/avoiding-xpub-derivation-reuse-across-wallets-in-a-ux-friendly-manner/1644/3 +[news346 checkpoints]: /ja/newsletters/2025/03/21/#bitcoin-core-31649 +[news335 blip50]: /ja/newsletters/2025/01/03/#blips-52 +[news135 bip48]: /ja/newsletters/2021/07/28/#bips-1072 +[news348 cleanup]: /ja/newsletters/2025/04/04/#draft-bip-published-for-consensus-cleanup-bip +[review club 31375]: https://bitcoincore.reviews/31375 +[gh ryanofsky]: https://github.com/ryanofsky +[multiprocess design]: https://github.com/bitcoin/bitcoin/blob/master/doc/design/multiprocess.md From f022a1a1acbd72d608b21518187d6f948afb9326 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Fri, 9 May 2025 16:07:16 +0200 Subject: [PATCH 008/278] Newsletter 352 translate in French (#2303) Co-authored-by: Jluc-bitcoinfr Co-authored-by: Thomas Suau <125269325+tsua0002@users.noreply.github.com> --- .../fr/newsletters/2025-05-02-newsletter.md | 107 ++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 _posts/fr/newsletters/2025-05-02-newsletter.md diff --git a/_posts/fr/newsletters/2025-05-02-newsletter.md b/_posts/fr/newsletters/2025-05-02-newsletter.md new file mode 100644 index 0000000000..1bd0f1d2e2 --- /dev/null +++ b/_posts/fr/newsletters/2025-05-02-newsletter.md @@ -0,0 +1,107 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #352' +permalink: /fr/newsletters/2025/05/02/ +name: 2025-05-02-newsletter-fr +slug: 2025-05-02-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine propose des comparaisons entre différentes techniques de +linéarisation de clusters et résume brièvement les discussions sur l'augmentation ou la suppression +de la limite de taille `OP_RETURN` de Bitcoin Core. Sont également incluses nos sections régulières +annonçant de nouvelles versions et versions candidates, ainsi que le résumé des +modifications notables apportées aux logiciels d'infrastructure Bitcoin populaires. + +## Nouvelles + +- **Comparaison des techniques de linéarisation de clusters :** + Pieter Wuille a [publié][wuille clustrade] sur Delving Bitcoin à propos de certains des compromis + fondamentaux entre trois différentes techniques de linéarisation de clusters, en suivant avec des + [benchmarks][wuille clusbench] des implémentations de chacune. Plusieurs autres développeurs ont + discuté des résultats et posé des questions de clarification, auxquelles Wuille a répondu. + +- **Augmentation ou suppression de la limite de taille `OP_RETURN` de Bitcoin Core :** + dans un fil de discussion sur Bitcoin-Dev, plusieurs développeurs ont discuté de la modification ou + de la suppression de la limite par défaut de Bitcoin Core pour les sorties de porteur de données + `OP_RETURN`. Une [pull request][bitcoin core #32359] ultérieure de Bitcoin Core a vu une discussion + supplémentaire. Plutôt que de tenter de résumer l'ensemble de la discussion volumineuse, nous + résumerons ce que nous pensions être l'argument le plus convaincant pour et contre le changement. + +- *Pour augmenter (ou éliminer) la limite :* Pieter Wuille a [fait valoir][wuille opr] que la + politique de standardisation des transactions est peu susceptible d'empêcher de manière significative la + confirmation de transactions portant des données créées par des organisations bien financées qui + feront les efforts nécessaires pour envoyer les transactions directement aux mineurs. Il + ajoute que les blocs sont généralement pleins, qu'ils contiennent ou non des transactions portant + des données, donc la quantité totale de données qu'un nœud doit stocker est à peu près la même dans + les deux cas. + +- *Contre l'augmentation de la limite :* Jason Hughes a [argumenté][hughes opr] qu'augmenter la + limite rendrait plus facile le stockage de données arbitraires sur les ordinateurs exécutant des + nœuds complets, et que certaines de ces données pourraient être hautement contestables (y compris + illégales dans la plupart des juridictions). Même si le nœud chiffre les données sur le disque (voir + le [Bulletin #316][news316 blockxor]), le stockage des données et la capacité de les récupérer en + utilisant les RPC de Bitcoin Core pourraient poser problème à de nombreux utilisateurs. + +## Mises à jour et versions candidates + +_Nouvelles mises à jour et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de passer aux nouvelles versions ou d'aider à tester +les versions candidates._ + +- [LND 0.19.0-beta.rc3][] est une version candidate pour ce nœud LN populaire. L'une des + principales améliorations qui pourrait probablement nécessiter des tests est le nouveau bumping de + frais basé sur RBF pour les fermetures coopératives. + +## Changements notables dans le code et la documentation + +_Changements notables récents dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning +repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], +[Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Propositions (BIPs)][bips repo], [Lightning BOLTs][bolts repo],[Lightning BLIPs][blips repo], +[Bitcoin Inquisition][bitcoin inquisition repo], et [BINANAs][binana repo]._ + +- [Bitcoin Core #31250][] désactive la création et le chargement des portefeuilles hérités, + complétant ainsi la migration vers les portefeuilles [descriptor][topic descriptors] qui sont + devenus le standard depuis octobre 2021 (voir le Bulletin [#172][news172 descriptors]). Les fichiers + Berkeley DB utilisés par les portefeuilles hérités ne peuvent plus être chargés, et tous les tests + unitaires et fonctionnels pour ces portefeuilles sont supprimés. Certains codes de portefeuille + hérité restent, mais seront retirés dans des PRs de suivi. Bitcoin Core est toujours capable de + migrer les portefeuilles hérités vers le nouveau format de portefeuille descriptor (voir le [Bulletin + #305][news305 bdbro]). + +- [Eclair #3064][] refactorise la gestion des clés de canal en introduisant une classe + `ChannelKeys`. Chaque canal possède désormais son propre objet `ChannelKeys` qui, avec les points + d'engagement, dérive un ensemble `CommitmentKeys` pour signer les transactions d'engagement + remote/local et [HTLC][topic htlc]. La logique de fermeture forcée et la création de script/témoin + sont également mises à jour pour dépendre de `CommitmentKeys`. Auparavant, la génération de clés + était dispersée à travers plusieurs parties du code pour supporter les signataires externes, ce qui + pouvait provoquer des erreurs car elle reposait sur des noms plutôt que sur des types pour assurer que + la pubkey correcte était fournie. + +- [BTCPay Server #6684][] ajoute le support pour un sous-ensemble de politiques de portefeuille + [BIP388][] [descriptors][topic descriptors], permettant aux utilisateurs d'importer et d'exporter + à la fois des portefeuilles à signature unique et k-de-n. Il inclut les formats pris en charge par Sparrow tels + que P2PKH, P2WPKH, P2SH-P2WPKH, et P2TR, avec les variantes multisig correspondantes, à l'exception + de P2TR. L'amélioration de l'utilisation des portefeuilles multisig est l'objectif visé par cette PR. + +- [BIPs #1555][] fusionne [BIP321][], qui propose un schéma d'URI pour décrire les instructions de + paiement en bitcoin qui modernise et étend [BIP21][]. Il conserve le chemin d'adresse hérité mais + standardise l'utilisation des paramètres de requête en rendant les nouvelles méthodes de paiement + identifiables par leurs propres paramètres, et permet de laisser le champ d'adresse vide si au moins + une instruction apparaît dans un paramètre de requête. Une extension optionnelle permet de + fournir une preuve de paiement, avec des recommandations + d’intégration. + +{% include snippets/recap-ad.md when="2025-05-06 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31250,3064,6684,1555,32359" %} +[lnd 0.19.0-beta.rc3]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc3 +[wuille clustrade]: https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/68 +[wuille clusbench]: https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/73 +[hughes opr]: https://mailing-list.bitcoindevs.xyz/bitcoindev/f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n@googlegroups.com/ +[wuille opr]: https://mailing-list.bitcoindevs.xyz/bitcoindev/QMywWcEgJgWmiQzASR17Dt42oLGgG-t3bkf0vzGemDVNVnvVaD64eM34nOQHlBLv8nDmeBEyTXvBUkM2hZEfjwMTrzzoLl1_62MYPz8ZThs=@wuille.net/ +[news316 blockxor]: /fr/newsletters/2024/08/16/#bitcoin-core-28052 +[news172 descriptors]: /en/newsletters/2021/10/27/#bitcoin-core-23002 +[news305 bdbro]: /fr/newsletters/2024/05/31/#bitcoin-core-26606 From 55b48872abb340c033f3439f93b3a9645a42c301 Mon Sep 17 00:00:00 2001 From: "Zhiwei(Jeffrey) Hu" Date: Fri, 9 May 2025 13:37:45 +0800 Subject: [PATCH 009/278] Newsletter-352: translate into Chinese (#165) --- .../zh/newsletters/2025-05-02-newsletter.md | 52 +++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 _posts/zh/newsletters/2025-05-02-newsletter.md diff --git a/_posts/zh/newsletters/2025-05-02-newsletter.md b/_posts/zh/newsletters/2025-05-02-newsletter.md new file mode 100644 index 0000000000..0bdedb5bde --- /dev/null +++ b/_posts/zh/newsletters/2025-05-02-newsletter.md @@ -0,0 +1,52 @@ +--- +title: 'Bitcoin Optech Newsletter #352' +permalink: /zh/newsletters/2025/05/02/ +name: 2025-05-02-newsletter-zh +slug: 2025-05-02-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周周报链接到了不同族群线性化技术的比较，并简要总结了关于增加或移除 Bitcoin Core `OP_RETURN` 大小限制的讨论。此外，还包含了我们的常规栏目，宣布新版本和候选版本，并总结了热门比特币基础设施软件的显著变更。 + +## 新闻 + +- **族群线性化技术比较：** + Pieter Wuille 在 Delving Bitcoin 上[发帖][wuille clustrade]讨论了三种不同族群线性化技术之间的一些基本权衡，随后发布了每种技术实现的[基准测试][wuille clusbench]。其他几位开发者讨论了该结果，并提出了用于澄清的问题，Wuille 对此做出了回应。 + +- ******增加或移除 Bitcoin Core 的 `OP_RETURN` 大小限制：** + 在 Bitcoin-Dev 的一个帖子中，几位开发者讨论了更改或移除 Bitcoin Core 对 `OP_RETURN` 数据载体输出的默认限制。随后的一个 Bitcoin Core [拉取请求][bitcoin core #32359]引发了更多讨论。我们不会试图总结所有这些冗长的讨论，而是总结我们认为支持和反对该变更的最有说服力的论点。 + + - *支持增加（或取消）限制的观点：* Pieter Wuille [认为][wuille opr]，交易标准化政策不太可能显著阻止资金充足的组织所创建的携带数据的交易得到确认。这些组织会努力将交易直接发送给矿工。此外，他认为无论区块是否包含携带数据的交易，区块通常都是满的，因此节点需要存储的总数据量大致相同。 + + - *反对增加限制的观点：* Jason Hughes [认为][hughes opr]，增加限制会更容易在运行全节点的计算机上存储任意数据，其中一些数据可能非常令人反感（包括在大多数司法管辖区是非法的）。即使用户在磁盘上加密数据（参见[周报 #316][news316 blockxor]），存储这些数据以及使用 Bitcoin Core RPC 检索这些数据的能力对许多用户来说都可能存在问题。 + +## 新版本和候选版本 + +_热门比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本。_ + +- [LND 0.19.0-beta.rc3][] 是这款热门闪电网络节点的候选版本。其中一项可能需要测试的主要改进是合作关闭通道的场景中新的基于 RBF 手续费提升机制。 + +## 代码和文档的显著变更 + +_近期在 [Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案 (BIPs)][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo] 中的显著变更。_ + +- [Bitcoin Core #31250][] 禁止了旧版钱包的创建和加载，完成了向[描述符][topic descriptors]钱包的迁移，描述符钱包自 2021 年 10 月以来一直是默认选项（参见[周报 #172][news172 descriptors]）。旧版钱包使用的 Berkeley DB 文件无法再加载，所有针对旧版钱包的单元测试和功能测试均已删除。部分旧版钱包代码仍然存在，但将在后续的 PR 中移除。Bitcoin Core 仍然能够将旧版钱包迁移到新的描述符钱包格式（参见[周报 #305][news305 bdbro]）。 + +- [Eclair #3064][] 通过引入 `ChannelKeys` 类重构了通道密钥管理。现在每个通道都有自己的 `ChannelKeys` 对象，该对象与承诺点一起派生出用于签名远程/本地承诺和 [HTLC][topic htlc] 交易的 `CommitmentKeys` 集合。强制关闭逻辑和脚本/见证创建也更新为依赖 `CommitmentKeys`。以前，密钥生成分散在代码库的多个部分以支持外部签名器，这很容易出错，因为它依赖于命名而不是类型来确保提供正确的公钥。 + +- [BTCPay Server #6684][] 添加了对 [BIP388][] 钱包策略[描述符][topic descriptors]子集的支持，允许用户导入和导出单签名和 k-of-n 策略。它包括 Sparrow 支持的格式，如 P2PKH、P2WPKH、P2SH-P2WPKH 和 P2TR，以及相应的多重签名变体（P2TR 除外）。此 PR 的预期目标是改进多重签名钱包的使用。 + +- [BIPs #1555][] 合并了 [BIP321][]，该提案提出了一种用于描述比特币支付指令的 URI 方案，该方案对 [BIP21][] 进行了现代化和扩展。它保留了基于路径的旧版地址，但通过使新的支付方式可通过其自身的参数进行识别来标准化查询参数的使用，并允许在至少一个指令出现在查询参数中时将地址字段留空。它增加了一个可选扩展，用于向花费者提供支付证明，并提供了有关如何整合新支付指令的指南。 + +{% include snippets/recap-ad.md when="2025-05-06 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31250,3064,6684,1555,32359" %} +[lnd 0.19.0-beta.rc3]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc3 +[wuille clustrade]: https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/68 +[wuille clusbench]: https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/73 +[hughes opr]: https://mailing-list.bitcoindevs.xyz/bitcoindev/f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n@googlegroups.com/ +[wuille opr]: https://mailing-list.bitcoindevs.xyz/bitcoindev/QMywWcEgJgWmiQzASR17Dt42oLGgG-t3bkf0vzGemDVNVnvVaD64eM34nOQHlBLv8nDmeBEyTXvBUkM2hZEfjwMTrzzoLl1_62MYPz8ZThs=@wuille.net/ +[news316 blockxor]: /zh/newsletters/2024/08/16/#bitcoin-core-28052 +[news172 descriptors]: /zh/newsletters/2021/10/27/#bitcoin-core-23002 +[news305 bdbro]: /zh/newsletters/2024/05/31/#bitcoin-core-26606 From 7d384fe3f4d0e02ac7f46437dfbb1d1d0f4a665d Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Fri, 9 May 2025 13:26:38 -0500 Subject: [PATCH 010/278] Podcast: add 352 recap --- .../en/newsletters/2025-05-02-newsletter.md | 14 ++++++----- .../en/podcast/2025-05-06-newsletter-recap.md | 23 +++++++++++++++++++ 2 files changed, 31 insertions(+), 6 deletions(-) create mode 100644 _posts/en/podcast/2025-05-06-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-05-02-newsletter.md b/_posts/en/newsletters/2025-05-02-newsletter.md index fd5b3a1539..c4004b20f0 100644 --- a/_posts/en/newsletters/2025-05-02-newsletter.md +++ b/_posts/en/newsletters/2025-05-02-newsletter.md @@ -21,7 +21,7 @@ infrastructure software. tradeoffs between three different cluster linearization techniques, following up with [benchmarks][wuille clusbench] of implementations of each. Several other developers discussed the results and asked - clarifying questions, to which Wuille responded. + clarifying questions, to which Wuille responded. {% assign timestamp="0:41" %} - **Increasing or removing Bitcoin Core's `OP_RETURN` size limit:** in a thread on Bitcoin-Dev, several developers discussed changing or @@ -50,6 +50,8 @@ infrastructure software. ability to retrieve it using Bitcoin Core RPCs could be problematic for many users. +{% assign timestamp="6:46" %} + ## Releases and release candidates _New releases and release candidates for popular Bitcoin infrastructure @@ -58,7 +60,7 @@ release candidates._ - [LND 0.19.0-beta.rc3][] is a release candidate for this popular LN node. One of the major improvements that could probably use testing - is the new RBF-based fee bumping for cooperative closes. + is the new RBF-based fee bumping for cooperative closes. {% assign timestamp="1:01:16" %} ## Notable code and documentation changes @@ -78,7 +80,7 @@ repo], and [BINANAs][binana repo]._ loaded, and all unit and functional tests for legacy wallets are deleted. Some legacy wallet code remains, but will be removed in follow up PRs. Bitcoin Core is still able to migrate legacy wallets to the new - descriptor wallet format (see [Newsletter #305][news305 bdbro]). + descriptor wallet format (see [Newsletter #305][news305 bdbro]). {% assign timestamp="1:02:10" %} - [Eclair #3064][] refactors channel key management by introducing a `ChannelKeys` class. Each channel now has its own `ChannelKeys` object which, @@ -88,14 +90,14 @@ repo], and [BINANAs][binana repo]._ `CommitmentKeys`. Previously, key generation was scattered across several parts of the codebase to support external signers, which was prone to errors because it relied on naming rather than types to ensure the correct pubkey was - provided. + provided. {% assign timestamp="1:06:02" %} - [BTCPay Server #6684][] adds support for a subset of [BIP388][] wallet policy [descriptors][topic descriptors], allowing users to import and export both single-sig and k-of-n policies. It includes the formats supported by Sparrow such as P2PKH, P2WPKH, P2SH-P2WPKH, and P2TR, with corresponding multisig variants, except for P2TR. Improving the use of multisig wallets is the - intended goal of this PR. + intended goal of this PR. {% assign timestamp="1:07:46" %} - [BIPs #1555][] merges [BIP321][], which proposes a URI scheme for describing bitcoin payment instructions that modernizes and extends [BIP21][]. It keeps @@ -104,7 +106,7 @@ repo], and [BINANAs][binana repo]._ the address field to be left empty if at least one instruction appears in a query parameter. It adds an optional extension to provide a proof of payment to the spender, and provides guidance on how to incorporate new payment - instructions. + instructions. {% assign timestamp="1:10:34" %} {% include snippets/recap-ad.md when="2025-05-06 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-05-06-newsletter-recap.md b/_posts/en/podcast/2025-05-06-newsletter-recap.md new file mode 100644 index 0000000000..f274a4bc0b --- /dev/null +++ b/_posts/en/podcast/2025-05-06-newsletter-recap.md @@ -0,0 +1,23 @@ +--- +title: 'Bitcoin Optech Newsletter #352 Recap Podcast' +permalink: /en/podcast/2025/05/06/ +reference: /en/newsletters/2025/05/02/ +name: 2025-05-06-recap +slug: 2025-05-06-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Sjors Provoost discuss [Newsletter #352]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-4-9/399945938-44100-2-1e203ed9d64d3.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From ef30c81e18c6a8c00abc7d156a8bd619dfc5e0db Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 15 May 2025 08:31:18 -0500 Subject: [PATCH 011/278] Podcast: add 353 recap --- .../en/newsletters/2025-05-09-newsletter.md | 26 ++++++++++--------- .../en/podcast/2025-05-13-newsletter-recap.md | 24 +++++++++++++++++ 2 files changed, 38 insertions(+), 12 deletions(-) create mode 100644 _posts/en/podcast/2025-05-13-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-05-09-newsletter.md b/_posts/en/newsletters/2025-05-09-newsletter.md index 984daa3bef..2ccce2d0bb 100644 --- a/_posts/en/newsletters/2025-05-09-newsletter.md +++ b/_posts/en/newsletters/2025-05-09-newsletter.md @@ -38,7 +38,7 @@ Bitcoin infrastructure software. blockchain. It's not really an issue now, except in a theoretical case where Bitcoin's proof-of-work security mechanism breaks. Several possible solutions were discussed, such as hardcoding additional - special case logic for these two exceptions. + special case logic for these two exceptions. {% assign timestamp="0:52" %} - **Avoiding BIP32 path reuse:** Kevin Loaec [posted][loaec bip32reuse] to Delving Bitcoin to discuss options for preventing the same @@ -56,7 +56,7 @@ Bitcoin infrastructure software. Salvatore Ingala [replied][ingala bip48] to suggest keeping the _coin type_ part of the BIP48 path as it helps ensure keys for use with different cryptocurrencies are kept segregated, which is enforced by - some hardware signing devices. + some hardware signing devices. {% assign timestamp="28:33" %} ## Bitcoin Core PR Review Club @@ -132,6 +132,8 @@ binaries is still possible and not affected by this PR. a4link="https://bitcoincore.reviews/31375#l-117" %} +{% assign timestamp="16:38" %} + ## Releases and release candidates _New releases and release candidates for popular Bitcoin infrastructure @@ -140,7 +142,7 @@ release candidates._ - [LND 0.19.0-beta.rc4][] is a release candidate for this popular LN node. One of the major improvements that could probably use testing - is the new RBF-based fee bumping for cooperative closes. + is the new RBF-based fee bumping for cooperative closes. {% assign timestamp="45:01" %} ## Notable code and documentation changes @@ -158,45 +160,45 @@ repo], and [BINANAs][binana repo]._ clients, using a JSON-RPC format over [BOLT8][] peer-to-peer messages, as specified in [BLIP50][] (see Newsletter [#335][news335 blip50]). This lays the foundation for implementing incoming liquidity requests as specified in - [BLIP51][], and [JIT channels][topic jit channels] as specified in [BLIP52][]. + [BLIP51][], and [JIT channels][topic jit channels] as specified in [BLIP52][]. {% assign timestamp="45:18" %} - [Core Lightning #8162][] updates the handling of peer-initiated pending channel opens by retaining them indefinitely, up to a limit of the 100 most recent. Previously, unconfirmed channel opens were forgotten after 2016 blocks. In addition, closed channels are now held in memory to allow a node to - respond to a peer’s `channel_reestablish` message. + respond to a peer’s `channel_reestablish` message. {% assign timestamp="46:43" %} - [Core Lightning #8166][] enhances the `wait` RPC command by replacing its single `details` object with subsystem-specific objects: `invoices`, `forwards`,`sendpays`, and [`htlcs`][topic htlc]. In addition, the `listhtlcs` RPC now supports pagination via new `created_index` and `updated_index` fields - and the `index`, `start`, and `end` parameters. + and the `index`, `start`, and `end` parameters. {% assign timestamp="47:44" %} - [Core Lightning #8237][] adds a `short_channel_id` parameter to the - `listpeerchannels` RPC command to return only a specific channel, if provided. + `listpeerchannels` RPC command to return only a specific channel, if provided. {% assign timestamp="48:49" %} - [LDK #3700][] adds a new `failure_reason` field to the `HTLCHandlingFailed` event to provide additional information about why the [HTLC][topic htlc] failed, and whether the cause was local or downstream. The `failed_next_destination` field is renamed to `failure_type` and the `UnknownNextHop` variant is deprecated, and replaced by the more general - `InvalidForward`. + `InvalidForward`. {% assign timestamp="49:28" %} - [Rust Bitcoin #4387][] refactors [BIP32][topic bip32] error handling by replacing the single `bip32::Error` with separate enums for derivation, child number/path parsing, and extended key parsing. This PR also introduces a new `DerivationError::MaximumDepthExceeded` variant for paths exceeding 256 - levels. These API changes break the backwards compatibility. + levels. These API changes break the backwards compatibility. {% assign timestamp="49:55" %} - [BIPs #1835][] updates [BIP48][] (see Newsletter [#135][news135 bip48]) to reserve the script type value 3 for [taproot][topic taproot] (P2TR) derivations in deterministic multisig wallets with the m/48' prefix, in - addition to the existing P2SH-P2WSH (1′) and P2WSH (2′) script types. + addition to the existing P2SH-P2WSH (1′) and P2WSH (2′) script types. {% assign timestamp="50:15" %} - [BIPs #1800][] merges [BIP54][], which specifies the [consensus cleanup soft fork][topic consensus cleanup] proposal to fix a number of long-standing vulnerabilities in the Bitcoin protocol. See Newsletter [#348][news348 - cleanup] for a detailed description of this BIP. + cleanup] for a detailed description of this BIP. {% assign timestamp="55:03" %} - [BOLTs #1245][] tightens [BOLT11][] by disallowing non-minimal length encodings in invoices: the expiry (x), the [CLTV expiry delta][topic cltv @@ -205,7 +207,7 @@ repo], and [BINANAs][binana repo]._ any invoice that contains leading zeros. This change was motivated by fuzz testing that detected that when LDK reserialize non-minimal invoices to minimal (stripping out the extra zeros), it causes the invoice’s ECDSA - signature to fail validation. + signature to fail validation. {% assign timestamp="56:37" %} {% include snippets/recap-ad.md when="2025-05-13 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-05-13-newsletter-recap.md b/_posts/en/podcast/2025-05-13-newsletter-recap.md new file mode 100644 index 0000000000..774d334d1b --- /dev/null +++ b/_posts/en/podcast/2025-05-13-newsletter-recap.md @@ -0,0 +1,24 @@ +--- +title: 'Bitcoin Optech Newsletter #353 Recap Podcast' +permalink: /en/podcast/2025/05/13/ +reference: /en/newsletters/2025/05/09/ +name: 2025-05-13-recap +slug: 2025-05-13-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt are joined by Ruben Somsen, Salvatore +Ingala, and Stéphan Vuylsteke to discuss [Newsletter #353]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-4-15/400339013-44100-2-4aa1980b8c295.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From 8938bcd9b72c3c19ddf02379af6c442a80e0c4d2 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Tue, 13 May 2025 22:53:24 -1000 Subject: [PATCH 012/278] Newsletters: add 354 (2025-05-16) --- .../en/newsletters/2025-05-16-newsletter.md | 120 ++++++++++++++++++ 1 file changed, 120 insertions(+) create mode 100644 _posts/en/newsletters/2025-05-16-newsletter.md diff --git a/_posts/en/newsletters/2025-05-16-newsletter.md b/_posts/en/newsletters/2025-05-16-newsletter.md new file mode 100644 index 0000000000..fe2afff392 --- /dev/null +++ b/_posts/en/newsletters/2025-05-16-newsletter.md @@ -0,0 +1,120 @@ +--- +title: 'Bitcoin Optech Newsletter #354' +permalink: /en/newsletters/2025/05/16/ +name: 2025-05-16-newsletter +slug: 2025-05-16-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter describes a fixed vulnerability affecting old +versions of Bitcoin Core. Also included are our regular sections +summarizing recent discussions about changing Bitcoin's consensus rules, +announcing new releases and release candidates, and describing notable +changes to popular Bitcoin infrastructure software. + +## News + +- **Vulnerability disclosure affecting old versions of Bitcoin Core:** + Antoine Poinsot [posted][poinsot addrvuln] to the Bitcoin-Dev mailing + list to announce a vulnerability affecting Bitcoin Core versions + before 29.0. The vulnerability was originally [responsibly + disclosed][topic responsible disclosures] by Eugene Siegel along with + another closely related vulnerability described in [Newsletter + #314][news314 excess addr]. An attacker could send an excessive + number of node address advertisements to force a 32-bit identifier to + overflow, resulting in a node crash. This was partly + mitigated by limiting the number of updates to one per peer per every + ten seconds, which for the default limit of about 125 peers would + prevent overflow unless the node was continuously attacked for over 10 + years. The + vulnerability was completely fixed by using 64-bit identifiers, + starting with last month's release of Bitcoin Core 29.0. + +## Changing consensus + +_A monthly section summarizing proposals and discussion about changing +Bitcoin's consensus rules._ + +- **Proposed BIP for 64-bit arithmetic in Script:** Chris Stewart + [posted][stewart bippost] a [draft BIP][64bit bip] to the Bitcoin-Dev + mailing list that proposes upgrading Bitcoin's existing opcodes to + operate on 64-bit numeric values. This follows his previous research + (see Newsletters [#285][news285 64bit], [#290][news290 + 64bit], and [#306][news306 64bit]). In a change from some of the + earlier discussion, the new proposal uses numbers in the same + compactSize data format currently used in Bitcoin. Additional related + [discussion][stewart inout] occurred on two [threads][stewart + overflow] on Delving Bitcoin. + +- **Proposed opcodes for enabling recursive covenants through quines:** + Bram Cohen [posted][cohen quine] to Delving Bitcoin to suggest a set + of simple opcodes that would enable the creation of recursive + [covenants][topic covenants] through self-reproducing scripts + ([quines][]). Cohen describes how the opcodes could be used to create a + simple [vault][topic vaults] and mentions a more advanced system that + he's been working on. + +- **Description of benefits to BitVM from `OP_CTV` and `OP_CSFS`:** + Robin Linus [posted][linus bitvm-sf] to Delving Bitcoin about several + of the improvements to [BitVM][topic acc] that would become possible if the + proposed [OP_CTV][topic op_checktemplateverify] and [OP_CSFS][topic + op_checksigfromstack] opcodes were added to Bitcoin in a soft fork. + The benefits he describes includes increasing the number of operators + without downsides, "reducing transaction sizes by approximately 10x" + (which reduces worst-case costs), and allowing non-interactive peg-ins + for certain contracts. + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [LND 0.19.0-beta.rc4][] is a release candidate for this popular LN + node. One of the major improvements that could probably use testing + is the new RBF-based fee bumping for cooperative closes. + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [Bitcoin Core #32155][] miner: timelock the coinbase to the mined block's height + +- [Bitcoin Core #28710][] Remove the legacy wallet and BDB dependency + +- [Core Lightning #8272][] connectd: remove DNS seed lookups. + +- [LND #8330][] bitromortac/2401-bimodal-improvements + +- [Rust Bitcoin #4458][] locktimes: replace `MtpAndHeight` type with pair of `BlockMtp` and `BlockHeight` + +- [BIPs #1848][] 'jamesob-25-05-withdraw-vault' - See also https://delvingbitcoin.org/t/withdrawing-op-vault-bip-345/1670 + +- [BIPs #1841][] Adds BIP172: Define Bitcoin Subunits as Satoshis + +- [BIPs #1821][] BIP177: Redefine Bitcoin’s Base Unit + +{% include snippets/recap-ad.md when="2025-05-20 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32155,28710,8272,8330,4458,1848,1841,1821" %} +[lnd 0.19.0-beta.rc4]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc4 +[news314 excess addr]: /en/newsletters/2024/08/02/#remote-crash-by-sending-excessive-addr-messages +[stewart bippost]: https://groups.google.com/g/bitcoindev/c/j1zEky-3QEE +[64bit bip]: https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki +[news285 64bit]: /en/newsletters/2024/01/17/#proposal-for-64-bit-arithmetic-soft-fork +[news290 64bit]: /en/newsletters/2024/02/21/#continued-discussion-about-64-bit-arithmetic-and-op-inout-amount-opcode +[news306 64bit]: /en/newsletters/2024/06/07/#updates-to-proposed-soft-fork-for-64-bit-arithmetic +[stewart inout]: https://delvingbitcoin.org/t/op-inout-amount/549/4 +[stewart overflow]: https://delvingbitcoin.org/t/overflow-handling-in-script/1549 +[poinsot addrvuln]: https://mailing-list.bitcoindevs.xyz/bitcoindev/EYvwAFPNEfsQ8cVwiK-8v6ovJU43Vy-ylARiDQ_1XBXAgg_ZqWIpB6m51fAIRtI-rfTmMGvGLrOe5Utl5y9uaHySELpya2ojC7yGsXnP90s=@protonmail.com/ +[cohen quine]: https://delvingbitcoin.org/t/a-simple-approach-to-allowing-recursive-covenants-by-enabling-quines/1655/ +[linus bitvm-sf]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/ +[quines]: https://en.wikipedia.org/wiki/Quine_(computing) From db27e0c83f095d654fb6622bfde57cd8600874c9 Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 15 May 2025 08:38:20 +0000 Subject: [PATCH 013/278] News354: add merge summaries --- _includes/references.md | 4 +- .../en/newsletters/2025-05-16-newsletter.md | 74 +++++++++++++++---- 2 files changed, 62 insertions(+), 16 deletions(-) diff --git a/_includes/references.md b/_includes/references.md index cb73815d8a..27ddb66b84 100644 --- a/_includes/references.md +++ b/_includes/references.md @@ -94,7 +94,7 @@ for details --> {% endcomment %} [BIP49]: https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki [BIP50]: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki [BIP52]: https://github.com/bitcoin/bips/blob/master/bip-0052.mediawiki -[BIP54]: https://github.com/bitcoin/bips/blob/master/bip-0052.mediawiki +[BIP54]: https://github.com/bitcoin/bips/blob/master/bip-0054.md [BIP61]: https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki [BIP62]: https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki [BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki @@ -150,8 +150,10 @@ for details --> {% endcomment %} [BIP157]: https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki [BIP158]: https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki [BIP159]: https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki +[BIP172]: https://github.com/bitcoin/bips/blob/master/bip-0172.mediawiki [BIP173]: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki [BIP174]: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki +[BIP177]: https://github.com/bitcoin/bips/blob/master/bip-0177.mediawiki [BIP179]: https://github.com/bitcoin/bips/blob/master/bip-0179.mediawiki [BIP199]: https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki [BIP300]: https://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki diff --git a/_posts/en/newsletters/2025-05-16-newsletter.md b/_posts/en/newsletters/2025-05-16-newsletter.md index fe2afff392..3704436e5a 100644 --- a/_posts/en/newsletters/2025-05-16-newsletter.md +++ b/_posts/en/newsletters/2025-05-16-newsletter.md @@ -86,21 +86,63 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Bitcoin Core #32155][] miner: timelock the coinbase to the mined block's height - -- [Bitcoin Core #28710][] Remove the legacy wallet and BDB dependency - -- [Core Lightning #8272][] connectd: remove DNS seed lookups. - -- [LND #8330][] bitromortac/2401-bimodal-improvements - -- [Rust Bitcoin #4458][] locktimes: replace `MtpAndHeight` type with pair of `BlockMtp` and `BlockHeight` - -- [BIPs #1848][] 'jamesob-25-05-withdraw-vault' - See also https://delvingbitcoin.org/t/withdrawing-op-vault-bip-345/1670 - -- [BIPs #1841][] Adds BIP172: Define Bitcoin Subunits as Satoshis - -- [BIPs #1821][] BIP177: Redefine Bitcoin’s Base Unit +- [Bitcoin Core #32155][] updates the internal miner to [timelock][topic + timelocks] coinbase transactions by setting the `nLockTime` field to the + current block’s height minus one and requiring the `nSequence` field not to be + final (to enforce the timelock). Although the built-in miner isn’t typically + used on mainnet, updating it encourages mining pools to adopt these changes + early in their own software in preparation for the + [consensus cleanup][topic consensus cleanup] soft fork proposed in [BIP54][]. Timelocking coinbase + transactions solves the [duplicate transaction][topic duplicate transactions] + vulnerability, and would allow the costly [BIP30][] checks to be lifted. + +- [Bitcoin Core #28710][] removes the remaining legacy wallet code, + documentation, and related tests. This includes the legacy-only RPCs, such as + `importmulti`, `sethdseed`, `addmultisigaddress`, `importaddress`, + `importpubkey`, `dumpwallet`, `importwallet`, and `newkeypool`. As the final + step for legacy wallet removal, the BerkeleyDB dependency and related + functions are also removed. However, the bare minimum of legacy code and an + independent BDB parser (see Newsletter [#305][news305 bdb]) are retained in + order to perform wallet migration to [descriptor][topic descriptors] wallets. + +- [Core Lightning #8272][] disables the DNS seed lookup peer discovery fallback + from the connection daemon `connectd` to resolve call block issues caused by + offline DNS seeds. + +- [LND #8330][] adds a small constant (1/c) to the pathfinding bimodal + probability model to address numerical instability. In edge cases where the + calculation would otherwise fail due to rounding errors and produce a zero + probability, this regularization provides a fallback by causing the model to + revert to a uniform distribution. This resolves normalization bugs that occur + in scenarios involving very large channels or channels that don't fit a + bimodal distribution. Additionally, the model now skips unnecessary + probability calculations and automatically corrects outdated channel liquidity + observations and contradictory historical information. + +- [Rust Bitcoin #4458][] replaces the `MtpAndHeight` struct with an explicit + pair of the newly added `BlockMtp` and the already existing `BlockHeight`, + enabling better modeling of both block height and Median Time Past (MTP) + values in relative [timelocks][topic timelocks]. Unlike + `locktime::absolute::MedianTimePast`, which is constrained to values above 500 million + (roughly after 1985), `BlockMtp` can represent any 32-bit timestamp. This + makes it suitable for theoretical edge cases, such as chains with unusual + timestamps. This update also introduces `BlockMtpInterval`, and renames + `BlockInterval` to `BlockHeightInterval`. + +- [BIPs #1848][] updates the status of [BIP345][] to `Withdrawn`, as the author + [believes][obeirne vaultwithdraw] its proposed `OP_VAULT` opcode has been superseded by + [`OP_CHECKCONTRACTVERIFY`][topic matt] (OP_CCV), a more general [vault][topic vaults] design + and a new type of [covenant][topic covenants]. + +- [BIPs #1841][] merges [BIP172][], which proposes formally defining Bitcoin’s + indivisible base unit as a “satoshi,” reflecting current widespread usage and + helping standardize terminology across applications and documentation. + +- [BIPs #1821][] merges [BIP177][], which proposes redefining “bitcoin” to + represent the smallest indivisible unit (commonly referred to as 1 satoshi), + rather than 100,000,000 units. The proposal argues that aligning terminology + with the actual base unit would reduce confusion caused by arbitrary decimal + conventions. {% include snippets/recap-ad.md when="2025-05-20 16:30" %} {% include references.md %} @@ -118,3 +160,5 @@ repo], and [BINANAs][binana repo]._ [cohen quine]: https://delvingbitcoin.org/t/a-simple-approach-to-allowing-recursive-covenants-by-enabling-quines/1655/ [linus bitvm-sf]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/ [quines]: https://en.wikipedia.org/wiki/Quine_(computing) +[news305 bdb]: /en/newsletters/2024/05/31/#bitcoin-core-26606 +[obeirne vaultwithdraw]: https://delvingbitcoin.org/t/withdrawing-op-vault-bip-345/1670/ From a03c9cffecf14a4ffda0a38364eed78cf9c31958 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Fri, 16 May 2025 05:32:52 -0500 Subject: [PATCH 014/278] News354: add topics --- _topics/en/acc.md | 3 +++ _topics/en/consensus-cleanup-soft-fork.md | 3 +++ _topics/en/covenants.md | 3 +++ _topics/en/matt.md | 3 +++ _topics/en/op_checksigfromstack.md | 3 +++ _topics/en/op_checktemplateverify.md | 3 +++ 6 files changed, 18 insertions(+) diff --git a/_topics/en/acc.md b/_topics/en/acc.md index 48872d8af4..4f2cc3c37d 100644 --- a/_topics/en/acc.md +++ b/_topics/en/acc.md @@ -61,6 +61,9 @@ optech_mentions: - title: "Summary and criticism of CTV + CSFS benefits for accountable computing contracts" url: /en/newsletters/2025/04/04/#accountable-computing-contracts + - title: "Description of benefits to BitVM from `OP_CTV` and `OP_CSFS`" + url: /en/newsletters/2025/05/16/#description-of-benefits-to-bitvm-from-op-ctv-and-op-csfs + ## Optional. Same format as "primary_sources" above see_also: - title: "Merklize All The Things (MATT)" diff --git a/_topics/en/consensus-cleanup-soft-fork.md b/_topics/en/consensus-cleanup-soft-fork.md index 09c1858da2..8f87542862 100644 --- a/_topics/en/consensus-cleanup-soft-fork.md +++ b/_topics/en/consensus-cleanup-soft-fork.md @@ -65,6 +65,9 @@ optech_mentions: - title: "BIPs #1800 merges BIP54, which specifies the consensus cleanup soft fork proposal" url: /en/newsletters/2025/05/09/#bips-1800 + - title: "Bitcoin Core #32155 updates the internal miner to comply with consensus cleanup requirements" + url: /en/newsletters/2025/05/16/#bitcoin-core-32155 + ## Optional. Same format as "primary_sources" above see_also: - title: Soft fork activation diff --git a/_topics/en/covenants.md b/_topics/en/covenants.md index 59b7a3b6da..293c7e899c 100644 --- a/_topics/en/covenants.md +++ b/_topics/en/covenants.md @@ -124,6 +124,9 @@ optech_mentions: - title: "Request for a covenant to fairly distribute rewards in the Braidpool decentralized mining pool" url: /en/newsletters/2025/02/07/#request-for-a-covenant-design-supporting-braidpool + - title: "Suggestion for opcodes to enable recursive covenants through quines" + url: /en/newsletters/2025/05/16/#proposed-opcodes-for-enabling-recursive-covenants-through-quines + ## Optional. Same format as "primary_sources" above see_also: - title: An early description of covenants in Bitcoin diff --git a/_topics/en/matt.md b/_topics/en/matt.md index e7ddff5b0b..d1d0bb0217 100644 --- a/_topics/en/matt.md +++ b/_topics/en/matt.md @@ -41,6 +41,9 @@ optech_mentions: - title: "Draft CCV BIP and details about amount semantic" url: /en/newsletters/2025/04/04/#op-checkcontractverify-semantics + - title: "OP_VAULT proposal withdrawn in favor of OP_CCV" + url: /en/newsletters/2025/05/16/#bips-1848 + ## Optional. Same format as "primary_sources" above see_also: - title: Covenants diff --git a/_topics/en/op_checksigfromstack.md b/_topics/en/op_checksigfromstack.md index 07b1d0d05c..4f0196ab8d 100644 --- a/_topics/en/op_checksigfromstack.md +++ b/_topics/en/op_checksigfromstack.md @@ -79,6 +79,9 @@ optech_mentions: - title: "Summary and criticism of CTV + CSFS benefits for Ark" url: /en/newsletters/2025/04/04/#ark + - title: "Description of benefits to BitVM from `OP_CTV` and `OP_CSFS`" + url: /en/newsletters/2025/05/16/#description-of-benefits-to-bitvm-from-op-ctv-and-op-csfs + ## Optional. Same format as "primary_sources" above see_also: - title: Covenants in Elements Alpha diff --git a/_topics/en/op_checktemplateverify.md b/_topics/en/op_checktemplateverify.md index 01a3f8e52e..aa91c28d59 100644 --- a/_topics/en/op_checktemplateverify.md +++ b/_topics/en/op_checktemplateverify.md @@ -160,6 +160,9 @@ optech_mentions: - title: "Details about how Ark could make use of CTV if activated" url: /en/newsletters/2025/04/04/#benefit-of-ctv-to-ark-users + - title: "Description of benefits to BitVM from `OP_CTV` and `OP_CSFS`" + url: /en/newsletters/2025/05/16/#description-of-benefits-to-bitvm-from-op-ctv-and-op-csfs + ## Optional. Same format as "primary_sources" above see_also: - title: Covenants From e69f090d8caaaf48fe9a29672ae882bb44162007 Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 16 May 2025 19:52:57 +0900 Subject: [PATCH 015/278] Newsletter-354:Translate into Japanese --- .../ja/newsletters/2025-05-16-newsletter.md | 140 ++++++++++++++++++ 1 file changed, 140 insertions(+) create mode 100644 _posts/ja/newsletters/2025-05-16-newsletter.md diff --git a/_posts/ja/newsletters/2025-05-16-newsletter.md b/_posts/ja/newsletters/2025-05-16-newsletter.md new file mode 100644 index 0000000000..bcfaf59a22 --- /dev/null +++ b/_posts/ja/newsletters/2025-05-16-newsletter.md @@ -0,0 +1,140 @@ +--- +title: 'Bitcoin Optech Newsletter #354' +permalink: /ja/newsletters/2025/05/16/ +name: 2025-05-16-newsletter-ja +slug: 2025-05-16-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、Bitcoin Coreの旧バージョンに影響する修正済みの脆弱性について掲載しています。 +また、Bitcoinのコンセンサスルールの変更に関する最近の議論や、 +新しいリリースおよびリリース候補の発表、人気のBitcoinインフラストラクチャソフトウェアの注目すべき変更など +恒例のセクションも含まれています。 + +## ニュース + +- **Bitcoin Coreの旧バージョンに影響する脆弱性の開示:** + Antoine Poinsotは、Bitcoin Coreのバージョン29.0未満に影響をおよぼす脆弱性の発表を + Bitcoin-Devメーリングリストに[投稿しました][poinsot addrvuln]。 + この脆弱性は[ニュースレター #314][news314 excess addr]に掲載されたもともとEugene Siegelによる + 別の関連脆弱性とともに、[責任を持って開示されました][topic responsible disclosures]。 + 攻撃者は、過剰な数のノードアドレスの通知を送信することで、32-bitの識別子をオーバーフローさせ、 + ノードのクラッシュを引き起こす可能性がありました。この問題は、 + ピア毎に10秒に1回の更新に制限することで部分的に軽減されました。この制限により、 + デフォルトの制限である約125個のピアにおいては、ノードが10年以上継続的に攻撃されない限り + オーバーフローは発生しません。この脆弱性は、先月リリースされたBitcoin Core 29.0以降、 + 64-bit識別子を使用することで完全に修正されました。 + +## コンセンサスの変更 + +_Bitcoinのコンセンサスルールの変更に関する提案と議論をまとめた月次セクション_ + +- **スクリプトで64-bit演算をサポートするためのBIPの提案:** + Chris Stewartは、Bitcoinの既存のopcodeを64-bitの数値で動作するようにアップグレードすることを提案する[BIPのドラフト][64bit bip]を + Bitcoin-Devメーリングリストに[投稿しました][stewart bippost]。これは、 + 彼の以前の研究（ニュースレター[#285][news285 64bit]、[#290][news290 64bit]および[#306][news306 64bit]参照） + に基づくものです。以前の議論の一部とは異なり、新しい提案では、 + 現在Bitcoinで使われているものと同じcompactSizeデータ形式の数値を使用します。 + Delving Bitcoinの2つの[スレッド][stewart overflow]でも関連する[議論が][stewart inout]行われています。 + +- **Quineを介して再帰的なコベナンツを可能にするopcodeの提案:** Bram Cohenは、 + 自己複製スクリプト（[Quine][quines]）を介して再帰的な[コベナンツ][topic covenants]の作成を可能にする + シンプルなopcodeセットの提案をDelving Bitcoinに[投稿しました][cohen quine]。Cohenは、 + これらのopcodeを使ってシンプルな[Vault][topic vaults]を作成する方法を説明し、 + 現在開発中のより高度なシステムについても言及しています。 + +- **`OP_CTV`と`OP_CSFS`によるBitVMへのメリットの説明:** + Robin Linusは、提案中の[OP_CTV][topic op_checktemplateverify] opcodeと + [OP_CSFS][topic op_checksigfromstack] opcodeがソフトフォークで + Bitcoinに追加された場合に可能になる[BitVM][topic acc]のいくつかの改善点について + Delving Bitcoinに[投稿しました][linus bitvm-sf]。彼が説明したメリットには、 + デメリットなしにオペレーターの数を増やすこと、 + 「トランザクションサイズを約10分の1に削減」（これによりワーストケースのコストが削減される）、 + 特定のコントラクトで非対話型のペグインを可能にすることなどが含まれます。 + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [LND 0.19.0-beta.rc4][]は、この人気のLNノードのリリース候補です。 + おそらくテストが必要な主な改善の1つは、協調クローズにおける新しいRBFベースの手数料引き上げです。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Bitcoin Core #32155][]は、内部マイナーを更新し、 + `nLockTime`フィールドに現在のブロック高から1を引いた値を設定し、 + （タイムロックを適用するために）`nSequence`フィールドに非ファイナル値を設定することで、 + コインベーストランザクションを[タイムロック][topic timelocks]します。 + この組み込みマイナーは、通常mainnetでは使用されませんが、この更新により、 + マイニングプールは[BIP54][]で提案されている[コンセンサスクリーンアップ][topic consensus cleanup]ソフトフォークに備えて、 + これらの変更を彼らのソフトウェアに早期に導入することが促進されます。 + コインベーストランザクションのタイムロックは、 + [重複トランザクション][topic duplicate transactions]の脆弱性を解決し、 + コストのかかる[BIP30][]チェックを不要にします。 + +- [Bitcoin Core #28710][]は、残っていたレガシーウォレットのコード、ドキュメントおよび関連テストを削除します。 + これには、`importmulti`、`sethdseed`、`addmultisigaddress`、`importaddress`、 + `importpubkey`、`dumpwallet`、`importwallet`、`newkeypool`といったレガシー専用のRPCが含まれます。 + レガシーウォレット削除の最終ステップとして、BerkeleyDBへの依存関係と関連関数も削除されます。 + ただし、ウォレットを[ディスクリプター][topic descriptors]ウォレットに移行するために、 + 最小限のレガシーコードと独立したBDBパーサー（ニュースレター[#305][news305 bdb]参照）は残されます。 + +- [Core Lightning #8272][]は、オフラインのDNSシードによって引き起こされるコールブロック問題を解決するため、 + 接続デーモン（`connectd`）からのDNSシードのルックアップによるピア検出のフォールバックを無効にします。 + +- [LND #8330][]は、数値的な不安定性に対処するために、経路探索の二峰性確率モデルに小さな定数（1/c）を追加します。 + 丸め誤差により計算が失敗し、確率がゼロになるようなエッジケースでは、 + この正規化によりモデルが一様分布に戻ることでフォールバックを提供します。 + これにより、非常に大規模なチャネルや二峰性分布に適合しないチャネルを含むシナリオで発生する正規化バグが解決します。 + さらに、モデルは不要な確率計算をスキップし、チャネル流動性の古い観測値や矛盾する履歴情報を自動的に修正するようになりました。 + +- [Rust Bitcoin #4458][]は、`MtpAndHeight`構造体を新しく追加された`BlockMtp`と既存の + `BlockHeight`の明示的なペアに置き換えました。これにより、 + 相対[タイムロック][topic timelocks]におけるブロック高とMTP（Median Time Past）値のより適切なモデリングが可能になります。 + 5億以上（おおよそ1985年以降）の値に制限される`locktime::absolute::MedianTimePast`とは異なり、 + `BlockMtp`は任意の32-bitタイムスタンプを表現できます。 + これは通常とは異なるタイムスタンプを持つチェーンなど、理論上のエッジケースに適しています。 + このアップデートでは、`BlockMtpInterval`も導入され、 + `BlockInterval`が`BlockHeightInterval`に名称変更されました。 + +- [BIPs #1848][]は、[BIP345][]のステータスを`Withdrawn`に更新しました。 + これは、提案者が提案していた `OP_VAULT` opcodeが、より汎用的な[Vault][topic vaults]の設計と + 新しいタイプの[コベナンツ][topic covenants]である + [`OP_CHECKCONTRACTVERIFY`][topic matt]（OP_CCV）に取って代わられたと[考えている][obeirne vaultwithdraw]ためです。 + +- [BIPs #1841][]は、Bitcoinの不可分な基本単位を「satoshi」と正式に定義することを提案する + [BIP172][]をマージしました。これは現在広く使われている用語を反映し、 + アプリケーションやドキュメント全体での用語の標準化に役立ちます。 + +- [BIPs #1821][]は、「bitcoin」の定義を1億単位ではなく、 + 最小の不可分単位（一般的に1 satoshi）を表すものに再定義することを提案する[BIP177][]をマージしました。 + この提案は、用語を実際の基本単位に合わせることで、恣意的な小数点表記による混乱を軽減できると主張しています。 + +{% include snippets/recap-ad.md when="2025-05-20 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32155,28710,8272,8330,4458,1848,1841,1821" %} +[lnd 0.19.0-beta.rc4]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc4 +[news314 excess addr]: /ja/newsletters/2024/08/02/#addr +[stewart bippost]: https://groups.google.com/g/bitcoindev/c/j1zEky-3QEE +[64bit bip]: https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki +[news285 64bit]: /ja/newsletters/2024/01/17/#proposal-for-64-bit-arithmetic-soft-fork-64-bit +[news290 64bit]: /ja/newsletters/2024/02/21/#continued-discussion-about-64-bit-arithmetic-and-op-inout-amount-opcode-64-bit-op-inout-amount-opcode +[news306 64bit]: /ja/newsletters/2024/06/07/#updates-to-proposed-soft-fork-for-64-bit-arithmetic-64-bit +[stewart inout]: https://delvingbitcoin.org/t/op-inout-amount/549/4 +[stewart overflow]: https://delvingbitcoin.org/t/overflow-handling-in-script/1549 +[poinsot addrvuln]: https://mailing-list.bitcoindevs.xyz/bitcoindev/EYvwAFPNEfsQ8cVwiK-8v6ovJU43Vy-ylARiDQ_1XBXAgg_ZqWIpB6m51fAIRtI-rfTmMGvGLrOe5Utl5y9uaHySELpya2ojC7yGsXnP90s=@protonmail.com/ +[cohen quine]: https://delvingbitcoin.org/t/a-simple-approach-to-allowing-recursive-covenants-by-enabling-quines/1655/ +[linus bitvm-sf]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/ +[quines]: https://ja.wikipedia.org/wiki/クワイン_(プログラミング) +[news305 bdb]: /ja/newsletters/2024/05/31/#bitcoin-core-26606 +[obeirne vaultwithdraw]: https://delvingbitcoin.org/t/withdrawing-op-vault-bip-345/1670/ From ebb8c1b8096656c3adaba393d368fd1aa4a1d155 Mon Sep 17 00:00:00 2001 From: Jiri Jakes Date: Fri, 16 May 2025 09:09:18 +0800 Subject: [PATCH 016/278] Newsletter-354: Translate into Czech --- .../cs/newsletters/2025-05-16-newsletter.md | 155 ++++++++++++++++++ 1 file changed, 155 insertions(+) create mode 100644 _posts/cs/newsletters/2025-05-16-newsletter.md diff --git a/_posts/cs/newsletters/2025-05-16-newsletter.md b/_posts/cs/newsletters/2025-05-16-newsletter.md new file mode 100644 index 0000000000..31ac6948a2 --- /dev/null +++ b/_posts/cs/newsletters/2025-05-16-newsletter.md @@ -0,0 +1,155 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 354' +permalink: /cs/newsletters/2025/05/16/ +name: 2025-05-16-newsletter-cs +slug: 2025-05-16-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden popisuje opravenou zranitelnost postihující staré +verze Bitcoin Core. Též nechybí naše pravidelné rubriky se souhrnem +nedávných diskuzí o změnách konsenzu, oznámeními nových vydání a popisem +významných změn v populárním bitcoinovém páteřním software. + +## Novinky + +- **Odhalení zranitelnosti postihující staré verze Bitcoin Core:** + Antoine Poinsot zaslal do emailové skupiny Bitcoin-Dev [příspěvek][poinsot + addrvuln] s oznámením zranitelnosti postihující verze Bitcoin Core před + 29.0. Zranitelnost původně [zodpovědně nahlásil][topic responsible disclosures] + Eugene Siegel spolu s další, úzce související zranitelností popsanou + ve [zpravodaji č. 314][news314 excess addr]. Útočník mohl poslat + nadměrný počet oznámení adresy uzlu, který způsobil přetečení + 32bitového identifikátoru a pád uzlu. Částečné opatření spočívalo v + omezení počtu těchto zpráv na jednu za deset sekund na jedno spojení. + Tím by přetečení při výchozím počtu 125 spojení nenastalo za méně než + deset let. Zranitelnost byla zcela odstraněna použitím 64bitových + datových typů počínaje Bitcoin Core verzí 29.0 vydanou minulý měsíc. + +## Diskuze o změnách konsenzu + +_Měsíční rubrika shrnující návrhy a diskuze o změnách pravidel +bitcoinového konsenzu._ + +- **Návrh BIPu pro 64bitovou aritmetiku ve Scriptu:** Chris Stewart + zaslal do emailové skupiny Bitcoin-Dev [příspěvek][stewart bippost] + s [pracovní verzí BIPu][64bit bip], který navrhuje přidat existujícím + opkódům schopnost operovat s 64bitovými číselnými hodnotami. Návrhu předcházel + jeho výzkum (viz zpravodaje [č. 285][news285 64bit], [č. 290][news290 + 64bit] a [č. 306][news306 64bit]). Oproti návrhu v dřívější diskuzi + používají nyní čísla stejný datový formát compactSize používaný v bitcoinu. + Další související [diskuze][stewart inout] probíhala + ve dvou [vláknech][stewart overflow] ve fóru Delving Bitcoin. + +- **Návrh opkódů pro rekurzivní kovenanty pomocí quine:** + Bram Cohen zaslal do fóra Delving Bitcoin [příspěvek][cohen quine] s návrhem + sady jednoduchých opkódů, které by umožnily vytváření rekurzivních + [koventantů][topic covenants] pomocí sebereprodukujících skriptů + ([quine][quines]). Cohen popisuje, jak by mohly být tyto opkódy použité k + tvorbě jednoduché [úschovny][topic vaults] a zmiňuje další + pokročilý systém, na kterém pracuje. + +- **Popis výhod `OP_CTV` a `OP_CSFS` pro BitVM:** + Robin Linus zaslal do fóra Delving Bitcoin [příspěvek][linus bitvm-sf] + o několika vylepšeních [BitVM][topic acc], které by případné opkódy + [OP_CTV][topic op_checktemplateverify] a [OP_CSFS][topic op_checksigfromstack] + mohly přinést, pokud by byly soft forkem přidané do bitcoinu. + Mezi popsané výhody patří bezproblémové navýšení počtu operátorů, + „zhruba desetinásobné snížení velikosti transakcí” (což snižuje maximální + možné náklady) a u některých kontraktů možnost neinteraktivního peggingu. + +## Vydání nových verzí + +*Vydání nových verzí oblíbených páteřních bitcoinových projektů. Prosíme, +zvažte upgrade či pomoc s testováním.* + +- [LND 0.19.0-beta.rc4][] je kandidátem na vydání tohoto oblíbeného LN uzlu. + Jedním významným vylepšením, které by si zasloužilo důkladné testování, je + nové schéma RBF navyšování poplatků během kooperativního zavření kanálu. + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo] a [repozitáři BINANA][binana repo]._ + +- [Bitcoin Core #32155][] přidává v kódu těžby mincetvorným transakcím + [časový zámek][topic timelocks] . Nastaví pole `nLockTime` na aktuální + výšku bloku mínus jedna a bude vyžadovat, aby pole `nSequence` nebylo + finální (aby mohl být časový zámek vynucen). I když není na mainnetu + obvykle vestavěná těžba používána, tato změna by měla povzbudit těžební + pooly k implementaci těchto změn do svého software v přípravě na navrhovaný + soft fork [pročištění konsenzu][topic consensus cleanup] ([BIP54][]). + Přidání časového zámku do mincetvorných transakcí řeší zranitelnost + [duplikovaných transakcí][topic duplicate transactions] a umožní odstranit + nákladnou kontrolu dle [BIP30][]. + +- [Bitcoin Core #28710][] odstraňuje zbývající kód, dokumentaci a testy související + se zastaralými peněženkami včetně RPC volání `importmulti`, `sethdseed`, + `addmultisigaddress`, `importaddress`, `importpubkey`, `dumpwallet`, `importwallet` + a `newkeypool`. Jako finální krok odstranění podpory zastaralých peněženek je + odstraněna závislost na BerkeleyDB. Malá část kódu a nezávislý parser databáze + (viz [zpravodaj č. 305][news305 bdb]) zůstávají zachovány pro možnost provádět + migraci na [deskriptorové][topic descriptors] peněženky. + +- [Core Lightning #8272][] odstraňuje z démonu `connectd` mechanismus vyhledávání + spojení z DNS seedu. Řeší tím problémy způsobené offline DNS seedy. + +- [LND #8330][] přidává do modelu pravděpodobnosti bimodálního hledání cest + malou konstantu (1/c), která řeší numerickou nestabilitu. V okrajových případech, + kde by jinak výpočet selhal kvůli chybám zaokrouhlování nebo by byla výsledkem + nulová pravděpodobnost, poskytuje tato regularizace záložní mechanismus v podobě + návratu k rovnoměrnému rozdělení. Změna opravuje chybu normalizace, která se + objevuje ve scénářích pracujících s objemnými kanály nebo kanály, které do + bimodálního rozdělení nezapadají. Dále model přestane provádět některé nepotřebné + výpočty pravděpodobnosti a bude opravovat neaktuální data o likviditě kanálu + a rozporné historické informace. + +- [Rust Bitcoin #4458][] nahrazuje strukturu `MtpAndHeight` explicitní dvojicí + typů `BlockMtp` (nově přidaný) a `BlockHeight` (již existující). Tím umožní + lepší reprezentaci výšky bloku a mediánu času posledních 11 bloků (Median Time Past, + MTP) v relativních [časových zámcích][topic timelocks]. Na rozdíl od + `locktime::absolute::MedianTimePast`, jehož hodnota je minimálně 500 miliónů + (zhruba rok 1985), může `BlockMtp` reprezentovat jakékoliv 32bitové časové + razítko. Může být tedy použit i v teoretických okrajových případech např. + v řetězcích s neobvyklými časovými razítky. Změna dále přináší `BlockMtpInterval` + a přejmenovává `BlockInterval` na `BlockHeightInterval`. + +- [BIPs #1848][] mění stav [BIP345][] na `Withdrawn` (stažen), jelikož autor + [věří][obeirne vaultwithdraw], že jím navrhovaný opkód `OP_VAULT` byl překonán opkódem + [`OP_CHECKCONTRACTVERIFY`][topic matt] (OP_CCV), který přináší obecnější návrh + [úschoven][topic vaults] a nový typ [kovenantů][topic covenants]. + +- [BIPs #1841][] začleňuje [BIP172][], který navrhuje na základě současného hojného + používání formálně definovat „satoshi” jako nedělitelnou bázovou jednotku bitcoinu. + +- [BIPs #1821][] začleňuje [BIP177][], který navrhuje předefinovat „bitcoin” jako + nejmenší nedělitelnou jednotku (běžně nazývanou satoshi) namísto 100 000 000 + těchto jednotek. Návrh tvrdí, že sjednocení terminologie se skutečnou + bázovou jednotkou by odstranilo zmatky způsobené nahodilým formátováním + desetinných čísel. + +{% include snippets/recap-ad.md when="2025-05-20 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32155,28710,8272,8330,4458,1848,1841,1821" %} +[lnd 0.19.0-beta.rc4]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc4 +[news314 excess addr]: /cs/newsletters/2024/08/02/#zaplava-zprav-addr-zpusobuje-pad-na-dalku +[stewart bippost]: https://groups.google.com/g/bitcoindev/c/j1zEky-3QEE +[64bit bip]: https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki +[news285 64bit]: /cs/newsletters/2024/01/17/#navrh-na-soft-fork-pro-64bitovou-aritmetiku +[news290 64bit]: /cs/newsletters/2024/02/21/#pokracujici-diskuze-o-64bitove-aritmetice-a-opkodu-op-inout-amount +[news306 64bit]: /cs/newsletters/2024/06/07/#zmeny-navrhovaneho-soft-forku-pro-64bitovou-aritmetiku +[stewart inout]: https://delvingbitcoin.org/t/op-inout-amount/549/4 +[stewart overflow]: https://delvingbitcoin.org/t/overflow-handling-in-script/1549 +[poinsot addrvuln]: https://mailing-list.bitcoindevs.xyz/bitcoindev/EYvwAFPNEfsQ8cVwiK-8v6ovJU43Vy-ylARiDQ_1XBXAgg_ZqWIpB6m51fAIRtI-rfTmMGvGLrOe5Utl5y9uaHySELpya2ojC7yGsXnP90s=@protonmail.com/ +[cohen quine]: https://delvingbitcoin.org/t/a-simple-approach-to-allowing-recursive-covenants-by-enabling-quines/1655/ +[linus bitvm-sf]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/ +[quines]: https://cs.wikipedia.org/wiki/Quine_(program) +[news305 bdb]: /cs/newsletters/2024/05/31/#bitcoin-core-26606 +[obeirne vaultwithdraw]: https://delvingbitcoin.org/t/withdrawing-op-vault-bip-345/1670/ From fcabfa4dcb42699c775c93275776937ae392bd02 Mon Sep 17 00:00:00 2001 From: editor-Ajian <34365188+editor-Ajian@users.noreply.github.com> Date: Mon, 19 May 2025 14:54:41 +0800 Subject: [PATCH 017/278] News353: translate into Chinese (#166) * News353: translate into Chinese * fix format * fix some typos, wordings * Apply suggestions from code review --------- Co-authored-by: Zhiwei(Jeffrey) Hu --- .../zh/newsletters/2025-05-09-newsletter.md | 95 +++++++++++++++++++ 1 file changed, 95 insertions(+) create mode 100644 _posts/zh/newsletters/2025-05-09-newsletter.md diff --git a/_posts/zh/newsletters/2025-05-09-newsletter.md b/_posts/zh/newsletters/2025-05-09-newsletter.md new file mode 100644 index 0000000000..4ec6a66f94 --- /dev/null +++ b/_posts/zh/newsletters/2025-05-09-newsletter.md @@ -0,0 +1,95 @@ +--- +title: 'Bitcoin Optech Newsletter #353' +permalink: /zh/newsletters/2025/05/09/ +name: 2025-05-09-newsletter-zh +slug: 2025-05-09-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- + +本周的周报介绍一种最近发现的理论上的共识失败漏洞，并链接了一种避免复用 BIP35 钱包路径的提议。此外是我们的常规栏目：最近一期 Bitcoin Core PR 审核俱乐部会议的总结，软件新版本和候选版本的发行说明，以及热门的比特币基础设施软件的重大代码变更说明。 + +## 新闻 + +- **** **BIP30 共识失败漏洞**：Ruben Somsen 在 Bitcoin-Dev 邮件组中[发帖][somsen bip30]提出了一个现在（检查点已经从 Bitcoin Core 中移除，详见[周报 #346][news346 checkpoints]）可能发生的理论上的共识故障。简而言之，区块高度 9172 和 91812 的 coinbase 交易跟 91880 和 91842 的分别[重合][topic duplicate transactions]。[BIP30][] 指定这两个区块的处理方式应该跟历史版本的 Bitcoin Core 在 2010 年的处理方式一致，就是在 UTXO 集中用后来出现的重合交易覆盖掉更早的 coinbase 条目。然而，Somsen 指出，影响其中一个（或两个）区块的重组可能导致重合条目从 UTXO 集中移除，而因为先前的覆盖操作，较早的那个条目也不会留下来；但是，一个新启动的节点从未看到过覆盖交易，就依然会保留更早的交易，从而产生不一样的 UTXO 集。如果某一笔交易被花费，这可能会导致共识故障。 + + 在 Bitcoin Core 还有检查点的时候，这不是个问题，因为检查点要求上述四个区块都出现在最佳区块链上。这不会立即变成问题 —— 只是在理论上，如果比特币的工作量证明安全机制崩溃的话，才会变成现实。人们讨论了多种可能的解决方案，比如为这两个例外硬编码额外的特例逻辑。 + +- **** **避免 BIP32 路径复用**：Kevin Loaec 在 Delving Bitcoin 论坛中[发帖][loaec bip32reuse]讨论防止相同的 [BIP32][topic bip32] 钱包派生路径被不同钱包使用的办法；复用相同的路径可能导致隐私风险（因为[输出关联][topic output linking]）以及理论上的资金安全风险（例如，因为[量子计算][topic quantum resistance]的可能性）。他提出了三种可能的方法：使用随机化的路径、使用基于钱包生日的路径，以及使用基于递增计数器的路径。他建议使用基于生日的方法。 + + 他还建议抛弃大部分 [BIP48][] 派生路径元素，因为随着[描述符][topic descriptors]钱包的日渐流行（尤其在多签名钱包和复杂脚本钱包中），使用这些元素已经没有必要。不过，Salvatore Ingala 依然[建议][ingala bip48]保留 BIP48 路径的 *coin type*（资金类型）部分，因为这可以帮助保证用在不同密码货币中的密钥是有分隔的，一些硬件签名设备也是这样做的。 + +## Bitcoin Core PR 审核俱乐部 + +*在这个月度栏目中，我们会总结最近一次 [Bitcoin Core PR 审核俱乐部][Bitcoin Core PR Review Club] 会议，提炼出一些重要的问题和回答。点击问题描述可以看到会议上的回答的总结。* + +“[添加可执行的 bitcoin 封装器][review club 31375]” 是由 [ryanofsky][gh ryanofsky] 发起的一项 PR，引入了一种新的 `bitcoin` 二进制文件，可以用来发现和启动多种 Bitcoin Core 二进制文件。 + +Bitcoin Core v29 发行了 7 种二进制文件（比如，`bitcoind`、`bitcoin-qt` 和 `bitcoin-cli`），但在未来[多进程][multiprocess design]二进制文件推出的时候，这个数量还会[增加][Bitcoin Core #30983]。新的 `bitcoin` 封装器会把命令（例如 `gui`）映射成正确的整体程序（`bitcoin-qt`）或者多线程（`bitocin-gui`）二进制文件。除了探测能力，这个封装器还提供了向前兼容性（forward compatibility），所以二级制文件可以重新组织，而用户界面无需改变。 + +有了这项 PR，用户可以用 `bitcoin daemon` 或者 `bitcoin gui` 来启动 Bitcoin Core。直接启动 `bitcoind` 或者 `bitcoin-qt` 二进制文件都依然是可行的，不受本 PR 的影响。 + +{% include functions/details-list.md + q0="从 Issue #30983 的描述来看，有四种封装策略。这个 PR 所采用的 “side-binaries” 有什么缺点？" + a0="本 PR 所假设的 side-binaries 方法要求随附现有的整体程序二进制文件发行新的多进程二进制文件。当二进制文件变得这么多，用户可能就会犯难，不知道哪个二进制文件才是自己要的。本 PR 通过提供一个单一的入口来消除大部分混淆，入口可以提供选项的概述和帮助文本。其中一个审核员建议加入模糊搜索，以进一步增加它的作用。" + a0link="https://bitcoincore.reviews/31375#l-40" + q1="在 Linx 系统中，`GetExePath()` 不会使用 `readlink(\"/proc/self/exe\")` ，即使这样更加直接。那么当前的实现有什么好处？它会不会忽略了什么东西？" + a1="可能有其它非 Windows 操作系统也没有 proc 文件系统。除此之外，作者和客座都无法找出使用 procfs 的任何缺点。" + a1link="https://bitcoincore.reviews/31375#l-71" + q2="在 `ExecCommand` 中，`fallback_os_search` 布尔值有什么用？在什么情况下，最好避免让操作系统在 `PATH` 中搜索二进制文件？" + a2="如果可执行的封装器看起来是通过路径（例如 “/build/bin/bitcoin”）而不是搜索（例如 “bitcoin”）调用的，那么它就会假设用户在使用一个本地的编译，然后 `fallback_os_search` 就会设为 `false`。引入这个布尔值是为了避免以外混淆来自不同来源的二进制文件。举个例子，如果用户并没有在本地编译 `gui`，那么 `/build/bin/bitcoin/gui` 就不应该回调系统安装好的 `bitcoin-gui`。作者正在考虑完全移除 `PATH` 搜索，如果能得到用户的反馈意见就好了。" + a2link="https://bitcoincore.reviews/31375#l-75" + q3="封装器仅会在它检测到它从安装好的 `bin` 目录运行时才会搜索。为什么不是总是搜索 `libexec` 呢？" + a3="封装器对自己尝试运行的目录应该是保守的，而且鼓励使用标准的 `PREFIX/{bin,libexec}` 格式，而不鼓励程序包创建不标准的格式、或在二进制文件以预期之外的方式组织时工作。" + a3link="https://bitcoincore.reviews/31375#l-75" + q4="这个 PR 在 `security-check.py` 中添加了一个豁免，因为封装器并不包含强化的（fortified） `glibc` 调用。为什么不包含呢？向 `bitcoin.cpp` 加入一个简单的 `printf` 会在当前的规则下打破可复现的编译吗？" + a4="封装器二进制文件是非常简单的，它不包含任何可以强化的调用。如果未来加入了这样的调用，security-check.py 中的豁免可以移除。" + a4link="https://bitcoincore.reviews/31375#l-117" +%} + +## 新版本和候选版本 + +*热门的比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本。* + +- [LND 0.19.0-beta.rc4][] 是这个热门的闪电网络节点实现的一个候选版本。一个可能需要测试的重大提升是其新的适用于合作关闭场景的基于 RBF 的手续费追加。 + +## 重大的代码和文档变更 + +*本周出现重大变更的有：[Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement Proposals (BIPs)][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo]。* + +- [Core Lightning #8227][] 加入了基于 Rust 编程语言的 `lsps-client` 和 `lsps-service` 插件，实现了一种闪电服务商（LSP）节点和客户端之间的通信协议，该协议在 [BOLT8][] 点对点消息之上使用了一种 JSON-RPC 格式，如 [BLIP50][]（详见周报 [#335][news335 blip50]）。这为实现 [BLIP51][] 所述的入账流动性请求以及 [BLIP52][] 所述的 “[按需即时通道][topic jit channels]” 奠定了基础。 + +- [Core Lightning #8162][] 更新了待处理通道开启请求的处理方式：无限期保留对等节点发起的待处理通道请求，但仅保留最新的 100 个。以前，未确认的通道开启请求会在 2016 个区块后抛弃。此外，已关闭的通道也会保留在内存中，以允许节点响应对等节点的 `channel_reestablish` 消息。 + +- [Core Lightning #8166][] 加强了 `wait` RPC 命令：用子系统专属的对象（`invoices`、`forwards`、`sendpays` 以及 [`htlcs`][topic htlc]）替代了单一的 `details` 对象。此外，`listhtlcs` PRC 现在支持使用新的 `created_index` 和 `updated_index` 字段、`index` 和 `start`、`end` 参数来使用页码。 + +- [Core Lightning #8237][] 给 `listpeerchannels` PRC 命令添加了一个 `chort_channel_id` 参数，以返回一条具体的通道（如果有的话）。 + +- [LDK #3700][] 为 `HTLCHandlingFailed` 事件添加了一个新的 `failure_reason` 字段，以提供关于 [HTLC][topic htlc] 失败的额外信息，以及原因来自本地还是下游。`failed_next_destination` 字段被重命名为 `fuilure_type`； `UnknownNextHop` 变体被弃用，换成了更加通用的 `InvalidForward`。 + +- [Rust Bitcoin #4387][] 重构了 [BIP32][topic bip32] 的错误处理：将单一的 `bip32::Error` 替换成了单独的枚举，用于派生、子编号/路径解析和拓展公钥解析。这个 PR 也引入了一种新的 `DerivationError::MaximunDepthExceeded` 变体，用于超过 256 层的路径。这些 API 变更会打破后向兼容性。 + +- [BIPs #1835][] 更新了 [BIP48][]（详见周报 [#135][news135 bip48]），以在使用 m/48' 前缀的确定性多签名钱包中为 [taproot][topic taproot]（P2TR）派生保留脚本类型数值 3；现有的其它保留数值有：P2SH-P2WSH（1'）和 P2WSH（2'）。 + +- [BIPs #1800][] 合并了 [BIP54][]，该 BIP 详述了修复比特币协议中一系列长期存在的漏洞的[共识清理软分叉][topic consensus cleanup]。关于这个 BIP 的详细描述，请看周报 [#348][news348 cleanup]。 + +- [BOLTs #1245][] 通过禁止在发票中使用非最短长度编码（non-minimal length encodings），收紧了 [BOLT11][]：expiry 字段（x）、最后一跳的 [CLTV 过期差值][topic cltv expiry delta]字段（c），以及特性比特字段（9），都必须以不使用 0 开头的最短长度序列化，而读取者也应该拒绝任何包含 0 开头的发票。这一变更的动机是模糊测试发现，当 LDK 重新序列化非最短的发票为最短发票（删去额外的 0）时，发票的 ECDSA 签名无法通过验证。 + +{% include snippets/recap-ad.md when="2025-05-13 16:30" %} + +{% include references.md %} + +{% include linkers/issues.md v=2 issues="8227,8162,8166,8237,3700,4387,1835,1800,1245,50,51,52,30983" %} +[lnd 0.19.0-beta.rc4]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc4 +[wuille clustrade]: https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/68 +[somsen bip30]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPv7TjZTWhgzzdps3vb0YoU3EYJwThDFhNLkf4XmmdfhbORTaw@mail.gmail.com/ +[loaec bip32reuse]: https://delvingbitcoin.org/t/avoiding-xpub-derivation-reuse-across-wallets-in-a-ux-friendly-manner/1644 +[ingala bip48]: https://delvingbitcoin.org/t/avoiding-xpub-derivation-reuse-across-wallets-in-a-ux-friendly-manner/1644/3 +[news346 checkpoints]: /zh/newsletters/2025/03/21/#bitcoin-core-31649 +[news335 blip50]: /zh/newsletters/2025/01/03/#blips-52 +[news135 bip48]: /zh/newsletters/2021/07/28/#bips-1072 +[news348 cleanup]: /zh/newsletters/2025/04/04/#draft-bip-published-for-consensus-cleanup +[review club 31375]: https://bitcoincore.reviews/31375 +[gh ryanofsky]: https://github.com/ryanofsky +[multiprocess design]: https://github.com/bitcoin/bitcoin/blob/master/doc/design/multiprocess.md From e5b4832a442c495400c8ca4ed74ebd8ee5aca517 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Wed, 21 May 2025 10:08:16 -0500 Subject: [PATCH 018/278] Podcast: add 354 recap --- .../en/newsletters/2025-05-16-newsletter.md | 26 +++++++++---------- .../en/podcast/2025-05-20-newsletter-recap.md | 24 +++++++++++++++++ 2 files changed, 37 insertions(+), 13 deletions(-) create mode 100644 _posts/en/podcast/2025-05-20-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-05-16-newsletter.md b/_posts/en/newsletters/2025-05-16-newsletter.md index 3704436e5a..2639056609 100644 --- a/_posts/en/newsletters/2025-05-16-newsletter.md +++ b/_posts/en/newsletters/2025-05-16-newsletter.md @@ -29,7 +29,7 @@ changes to popular Bitcoin infrastructure software. prevent overflow unless the node was continuously attacked for over 10 years. The vulnerability was completely fixed by using 64-bit identifiers, - starting with last month's release of Bitcoin Core 29.0. + starting with last month's release of Bitcoin Core 29.0. {% assign timestamp="1:17" %} ## Changing consensus @@ -45,7 +45,7 @@ Bitcoin's consensus rules._ earlier discussion, the new proposal uses numbers in the same compactSize data format currently used in Bitcoin. Additional related [discussion][stewart inout] occurred on two [threads][stewart - overflow] on Delving Bitcoin. + overflow] on Delving Bitcoin. {% assign timestamp="5:28" %} - **Proposed opcodes for enabling recursive covenants through quines:** Bram Cohen [posted][cohen quine] to Delving Bitcoin to suggest a set @@ -53,7 +53,7 @@ Bitcoin's consensus rules._ [covenants][topic covenants] through self-reproducing scripts ([quines][]). Cohen describes how the opcodes could be used to create a simple [vault][topic vaults] and mentions a more advanced system that - he's been working on. + he's been working on. {% assign timestamp="23:11" %} - **Description of benefits to BitVM from `OP_CTV` and `OP_CSFS`:** Robin Linus [posted][linus bitvm-sf] to Delving Bitcoin about several @@ -63,7 +63,7 @@ Bitcoin's consensus rules._ The benefits he describes includes increasing the number of operators without downsides, "reducing transaction sizes by approximately 10x" (which reduces worst-case costs), and allowing non-interactive peg-ins - for certain contracts. + for certain contracts. {% assign timestamp="36:39" %} ## Releases and release candidates @@ -73,7 +73,7 @@ release candidates._ - [LND 0.19.0-beta.rc4][] is a release candidate for this popular LN node. One of the major improvements that could probably use testing - is the new RBF-based fee bumping for cooperative closes. + is the new RBF-based fee bumping for cooperative closes. {% assign timestamp="1:07:28" %} ## Notable code and documentation changes @@ -94,7 +94,7 @@ repo], and [BINANAs][binana repo]._ early in their own software in preparation for the [consensus cleanup][topic consensus cleanup] soft fork proposed in [BIP54][]. Timelocking coinbase transactions solves the [duplicate transaction][topic duplicate transactions] - vulnerability, and would allow the costly [BIP30][] checks to be lifted. + vulnerability, and would allow the costly [BIP30][] checks to be lifted. {% assign timestamp="1:08:27" %} - [Bitcoin Core #28710][] removes the remaining legacy wallet code, documentation, and related tests. This includes the legacy-only RPCs, such as @@ -103,11 +103,11 @@ repo], and [BINANAs][binana repo]._ step for legacy wallet removal, the BerkeleyDB dependency and related functions are also removed. However, the bare minimum of legacy code and an independent BDB parser (see Newsletter [#305][news305 bdb]) are retained in - order to perform wallet migration to [descriptor][topic descriptors] wallets. + order to perform wallet migration to [descriptor][topic descriptors] wallets. {% assign timestamp="1:09:38" %} - [Core Lightning #8272][] disables the DNS seed lookup peer discovery fallback from the connection daemon `connectd` to resolve call block issues caused by - offline DNS seeds. + offline DNS seeds. {% assign timestamp="1:13:28" %} - [LND #8330][] adds a small constant (1/c) to the pathfinding bimodal probability model to address numerical instability. In edge cases where the @@ -117,7 +117,7 @@ repo], and [BINANAs][binana repo]._ in scenarios involving very large channels or channels that don't fit a bimodal distribution. Additionally, the model now skips unnecessary probability calculations and automatically corrects outdated channel liquidity - observations and contradictory historical information. + observations and contradictory historical information. {% assign timestamp="1:14:09" %} - [Rust Bitcoin #4458][] replaces the `MtpAndHeight` struct with an explicit pair of the newly added `BlockMtp` and the already existing `BlockHeight`, @@ -127,22 +127,22 @@ repo], and [BINANAs][binana repo]._ (roughly after 1985), `BlockMtp` can represent any 32-bit timestamp. This makes it suitable for theoretical edge cases, such as chains with unusual timestamps. This update also introduces `BlockMtpInterval`, and renames - `BlockInterval` to `BlockHeightInterval`. + `BlockInterval` to `BlockHeightInterval`. {% assign timestamp="1:14:52" %} - [BIPs #1848][] updates the status of [BIP345][] to `Withdrawn`, as the author [believes][obeirne vaultwithdraw] its proposed `OP_VAULT` opcode has been superseded by [`OP_CHECKCONTRACTVERIFY`][topic matt] (OP_CCV), a more general [vault][topic vaults] design - and a new type of [covenant][topic covenants]. + and a new type of [covenant][topic covenants]. {% assign timestamp="1:04:33" %} - [BIPs #1841][] merges [BIP172][], which proposes formally defining Bitcoin’s indivisible base unit as a “satoshi,” reflecting current widespread usage and - helping standardize terminology across applications and documentation. + helping standardize terminology across applications and documentation. {% assign timestamp="1:16:25" %} - [BIPs #1821][] merges [BIP177][], which proposes redefining “bitcoin” to represent the smallest indivisible unit (commonly referred to as 1 satoshi), rather than 100,000,000 units. The proposal argues that aligning terminology with the actual base unit would reduce confusion caused by arbitrary decimal - conventions. + conventions. {% assign timestamp="1:16:42" %} {% include snippets/recap-ad.md when="2025-05-20 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-05-20-newsletter-recap.md b/_posts/en/podcast/2025-05-20-newsletter-recap.md new file mode 100644 index 0000000000..fdb6690f42 --- /dev/null +++ b/_posts/en/podcast/2025-05-20-newsletter-recap.md @@ -0,0 +1,24 @@ +--- +title: 'Bitcoin Optech Newsletter #354 Recap Podcast' +permalink: /en/podcast/2025/05/20/ +reference: /en/newsletters/2025/05/16/ +name: 2025-05-20-recap +slug: 2025-05-20-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt are joined by Eugene Siegel, Chris +Stewart, Bram Cohen, and Robin Linus to discuss [Newsletter #353]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-4-21/400730871-44100-2-1b57ae23da53d.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From 7feb11a47fe4cf70e46d73dbbad436c07f8f5700 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Wed, 21 May 2025 12:45:17 -0500 Subject: [PATCH 019/278] Podcast: 354 fixup --- _posts/en/podcast/2025-05-20-newsletter-recap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-05-20-newsletter-recap.md b/_posts/en/podcast/2025-05-20-newsletter-recap.md index fdb6690f42..fe26a1e7a0 100644 --- a/_posts/en/podcast/2025-05-20-newsletter-recap.md +++ b/_posts/en/podcast/2025-05-20-newsletter-recap.md @@ -9,7 +9,7 @@ layout: podcast-episode lang: en --- Mark “Murch” Erhardt and Mike Schmidt are joined by Eugene Siegel, Chris -Stewart, Bram Cohen, and Robin Linus to discuss [Newsletter #353]({{page.reference}}). +Stewart, Bram Cohen, and Robin Linus to discuss [Newsletter #354]({{page.reference}}). {% include functions/podcast-links.md %} From e44ea2375f86e9850be3c6202f0579df46f117d2 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 22 May 2025 15:15:26 -0500 Subject: [PATCH 020/278] Podcast: add 351 transcription --- .../en/podcast/2025-04-29-newsletter-recap.md | 940 +++++++++++++++++- 1 file changed, 939 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-04-29-newsletter-recap.md b/_posts/en/podcast/2025-04-29-newsletter-recap.md index e9d00505ba..4796a2096b 100644 --- a/_posts/en/podcast/2025-04-29-newsletter-recap.md +++ b/_posts/en/podcast/2025-04-29-newsletter-recap.md @@ -19,6 +19,944 @@ Mark “Murch” Erhardt and Mike Schmidt are joined by Jonas Nick and Salvatore ## Transcription -_transcription coming soon_ +**Mike Schmidt**: Welcome everyone to Bitcoin Optech Newsletter #351 Recap. +Today, we're going to be talking about aggregate signatures and the DahLIAS +scheme; we're going to talk about backups for wallet descriptors; we have nine +questions from the Stack Exchange; and we have our usual Releases and Notable +code segments as well. I'm Mike Schmidt, contributor at Optech and Executive +Director at Brink, funding Bitcoin open-source developers. Murch? + +**Mark Erhardt**: Hey, I'm Murch, I work at Localhost on Bitcoin stuff. + +**Mike Schmidt**: Jonas? + +**Jonas Nick**: Hello everyone, I work on cryptographic research at Blockstream. + +**Mike Schmidt**: Salvatore? + +**Salvatore Ingala**: Hi everyone, I work at Ledger on Bitcoin stuff. + +_Interactive aggregate signatures compatible with secp256k1_ + +**Mike Schmidt**: Well, thank you both for joining us as special guests to +represent your news items this week. We're going to jump right into the News +section. First news item titled, "Interactive aggregate signatures compatible +with secp256k1". Jonas, you, Tim, and Yannick published a paper titled, +"DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures", which is +an aggregate signature scheme with constant-sized signatures. Now, on this +show, Murch and I have spoken a bit about FROST, which would be k-of-n threshold +signatures and n-of-n MuSig2 multisignatures. But maybe you can help start the +conversation by distinguishing those from this category of aggregate signatures +that DahLIAS is part of. + +**Jonas Nick**: Right. All right, so DahLIAS is a cryptographic protocol and +more specifically, an interactive aggregate signature scheme. And to get an +idea for what this is, it may be helpful to look at the syntax of verification +algorithms for various signature schemes. So, for example, you have what we can +call single-sig; one representative would be a schnorr signature or the ECDSA +scheme, where the verification algorithm takes a single public key, a single +message and a single signature, and then outputs true or false, depending on +whether the signature actually was valid. In a multisignature or threshold +signature scheme, the verification algorithm takes multiple public keys, a +single message and one signature and outputs true or false. And in an aggregate +signature scheme, the verification algorithm takes multiple public keys, +multiple message, one per public key and a single signature and outputs true or +false. + +So, the difference between a multisignature or threshold signature and an +aggregate signature is that in the aggregate signature scheme, every signer +signs their own message. And to illustrate this idea, we can build a very +simple aggregate signature scheme from a single signature scheme, like schnorr +for example, and we call this the trivial signature aggregation scheme. And to +do that, we just define the aggregate signature in this trivial scheme to be the +concatenation of the individual single signatures, the single schnorr +signatures. And then, our verification algorithm for this trivial aggregate +signature scheme would just iterate through all the individual signatures, +checks that they are valid using the single signature verification scheme, and +if they are all valid, it returns true; and if one of them is invalid, it +returns false. And so, what we are interested in then is an aggregate signature +scheme that is more efficient than that. + +So, in DahLIAS, the signatures, they are constant size, meaning that they are +independent of the number of signers. And moreover, verification is twice as +fast as the trivial aggregation scheme using batch verification. And one of the +novel contributions of DahLIAS is that it works on the same curve as ECDSA and +schnorr signatures that we currently use in Bitcoin. And in that case, the +public keys are also the same as an ECDSA and schnorr, 32 or 33 bytes, and a +DahLIAS signature is always 64 bytes. Also, DahLIAS signing requires two +communication rounds, similar to MuSig2, and it supports key tweaking, so in +particular taproot commitments and BIP32. + +**Mike Schmidt**: That was a great walkthrough, even I understood it. Maybe you +can help clue us in. It's interactive, you're aggregating the signatures, +you're signing different messages. Is this what we've heard maybe discussed +previously, like this is full aggregation; this is not half aggregation, right? + +**Jonas Nick**: Yes, so there's an alternative scheme, aggregate signature +scheme, that is known as half aggregation, which is non-interactive, meaning +that there can exist some entity or some algorithm that just takes individual +schnorr signatures and outputs a half-aggregate signature. The advantage of +that is that it's non-interactive. You can just do it, just grab the +signatures, collect the signatures, output such a half-aggregate signature. But +the disadvantage is that those signatures, they are not constant size, they +depend on the number of signers. And half aggregation, as the name suggests, +means that the signature that is output by this aggregation algorithm is about +half the size as the trivial aggregate signature scheme that we discussed. + +**Mike Schmidt**: And maybe you can talk a little bit about the relation of +DahLIAS to cross-input signature aggregation (CISA). Is this the sort of +breakthrough that folks have been kind of waiting for, or what's the relation +there? + +**Jonas Nick**: Right, so the main application we have in mind for this in the +Bitcoin space is CISA, which would mean that a transaction would just have a +single aggregate signature instead of having signatures for every input. And +the advantage then of course is efficiency, because right now, you need +typically one signature per input which takes space. So, instead, you could +have one single aggregate signature for the entire transaction and if it's +invalid, the transaction is invalid. And you could introduce that via a soft +fork, but so far there does not exist a BIP draft that would exactly specify how +that would work, but it certainly seems doable with a soft fork. + +**Mark Erhardt**: So, the idea here is that each of the components or +contributors of the signature signs their own input, and it all gets aggregated +together into a single signature, which of course lends itself to the CISA. I +think one of the issues around CISA was the interaction with key tweaking or +adaptor signatures. Would it then here be the case that if you use this scheme +to sign, you can't use adaptor signatures at the same time, or at least not more +than one across all the inputs? + +**Jonas Nick**: Yeah, so that is a good question. I don't think there's a +definitive answer to that. So, half aggregation would break adaptor signatures, +sort of, at least if you would implement half aggregation. At least if the +adaptor signature would require working on the keyspend path, and if we would +only do half aggregation on the keyspend path, then half aggregation would +prevent adaptor signatures. And full aggregation like DahLIAS, as far as we +know does not prevent adaptor signatures, but it's probably true that it would +only work for one adaptor signature across those inputs. That is probably true, +but as I said, I don't think there's a definitive answer to that. It's a good +question. + +**Mark Erhardt**: A second follow-up question, you said that it could be soft +forked in. Clearly, we can create a new output type that is spendable with the +DahLIAS scheme. Is there any way to make existing outputs spendable with the +DahLIAS scheme so that it would become cheaper to spend existing UTXOs? + +**Jonas Nick**: Also good question. I haven't thought about this in a while. I +believe there are some interactions with OP_SUCCESS that make this difficult. +So, I believe the current thinking is that it would require a new segwit +version. + +**Mark Erhardt**: That's all my questions for the moment. Mike, back to you. + +**Mike Schmidt**: Jonas, what would the soft fork entail? I think folks maybe +are used to, "Hey, we got these Schnorr signatures. Wow!" There's a lot of +work that you guys did on this, but we got MuSig2 and that is a schnorr +signature, and FROST similarly. But it sounds like in this scheme, there's +actually a new type of signature involved. So, we can't just layer in +cryptographic magic on top of what we have in the protocol now, is that right? + +**Jonas Nick**: Yeah, that is because aggregate signatures, they just have a +different syntax than single signatures. And also, the verification algorithm +then looks different to regular schnorr signatures. + +**Mike Schmidt**: And I think we mentioned in the newsletter, I don't have it +right up in front of me, but something about the size and shape, or something, +would be similar to Schnorr signatures, but it won't be a Schnorr signature? + +**Jonas Nick**: Yes. So, the shape is similar. I mean, 64 bytes, same as a +schnorr signature, and it also consists of a group element and a scalar. So, +very similar to the BIP340 schnorr signatures, and public keys are the same as +we're using in schnorr signatures right now. And so, this is sort of the novel +contribution, because there have already existed aggregate signature schemes +with constant-size signatures, so very efficient at least space wise. But they +would require switching to a different curve, which of course it's not +impossible, we can upgrade Bitcoin to do that, but it would be a much more +complex upgrade to Bitcoin, and therefore harder to get consensus on and build +the libraries, and wouldn't work with the existing tooling because you have +these new types of public keys, new libraries, etc. + +**Mike Schmidt**: Now, some of the buzz recently has been around +quantum-resistant signature schemes. Does DahLIAS address that at all, or is +that just a completely separate consideration? + +**Jonas Nick**: No, it's not completely separate. So, because DahLIAS works on +the same curve as schnorr and ECDSA, it also has the same vulnerabilities if +practical quantum computers existed. So, yes, they are just as vulnerable to +quantum computers as schnorr and ECDSA signatures, because they depend on the +discrete logarithm problem, which as we know, since '94 I believe, is not +actually hard if you have this physical device that's a quantum computer. + +**Mike Schmidt**: And in the paper, you guys detail these aggregate signatures +as, this would be a building block for something like CISA, right, that you're +not getting into how would you pass around these messages on the Bitcoin Network +or some other network to actually aggregate these things together; you're just +merely providing the primitive and that would be future research, is that right? + +**Jonas Nick**: Right, yes. So, the paper is entirely focused almost on the +cryptography, and we have a little application section that kind of explains +what this could mean for Bitcoin. But since it's interactive, we only imagine +this to work on the transaction level and not the block level. So, if you +collaboratively produce a transaction, there's already some interaction +involved, because you need to parse the transaction around and then sign the +transaction. So, we imagine some of these DahLIAS protocol messages could be +added to PSBT, similar to how the how MuSig2 protocol messages have been added. +Salvatore or Murch, any other follow-up questions for Jonas? + +**Salvatore Ingala**: I have a small question. So, first of all, thanks for +doing all the hard work on the cryptography. I'm not a cryptographer myself, +but I implemented at least one of your BIPs, which is BIP327, together with the +other ones that were related to MuSig2. And in my experience, it was probably +the most enjoyable BIP to implement, because implementing the hardcore +cryptography part ended up being one of the easiest and less time-consuming for +my work at Ledger. So, thanks for that. + +**Jonas Nick**: Thanks, that's great to hear. Our BIPs tend to be relatively +long. + +**Salvatore Ingala**: Yeah, but it's good. It means I don't have to figure out +too many things by myself, which is helpful. So, related to that, the question +I have is this, that for MuSig2, you can easily define a new type of descriptor, +which is how you aggregate the keys. How would that happen in a hypothetical +soft fork to support this signature aggregation? Because at this point, now the +aggregation is no longer at the key level, but it's at the signatures level. +So, you have an idea how that would look like? + +**Jonas Nick**: Well, I guess if you have a descriptor, you somehow need to know +whether you are supposed to produce a regular schnorr signature or a DahLIAS +partial signature that will be aggregated. I think it's a good question, but I +haven't thought about that at all. + +**Mark Erhardt**: Given that the output descriptor describes the output script, +I think if we get a new output version for the DahLIAS outputs, I think that +should be compatible with the output script descriptors. + +**Salvatore Ingala**: But yeah, my understanding there is that you would kind of +have to label each key to say that this key is aggregated. And if they are in +the same transaction, there could be potentially multiple groups of keys that +are aggregated together, in theory. So, you will have to be able to somehow +identify which keys are aggregated together as well, right? + +**Jonas Nick**: So, in DahLIAS keys are not really aggregated. There's no +notion of key aggregation, really. So, I don't see exactly where the problem +would be. + +**Mark Erhardt**: So, if I may, the output script is a regular script, and then +the aggregation only happens optionally on the side of the inputs. So, if you +have several inputs, the participants probably can but don't have to aggregate +their signatures for their DahLIAS inputs. But the output script would just +need to indicate that it's a DahLIAS output script, or that's how I have been +puzzling it together so far. + +**Jonas Nick**: Yeah, that sounds reasonable. Although, I suppose depending on +how the soft fork works, if you still allow a single-signature spending, then +yeah, at the time of output creation, you shouldn't have to decide whether you +want to later spend it with an aggregate signature or just a single signature. + +**Salvatore Ingala**: Cool, thanks. + +**Mike Schmidt**: Jonas, we can wrap up that news item and we have you on +talking about aggregated signatures, and there actually was a question from the +Stack Exchange on that. So, I wanted to go a little bit out of order and ask +that question. + +_Practicality of half-aggregated schnorr signatures?_ + +The question is, "Practicality of half-aggregated schnorr signatures?" And the +person asking this question seems to be wondering if the usefulness of +half-aggregated signatures in practice is negated if all of the independent +signatures are needed anyway, to be sure that all the signatures are correct. +Is that assumption correct? Maybe you can dig into the prerequisites of that +question. + +**Jonas Nick**: Yeah, so this is a rather technical note that we have in the BIP +that the person who had this question read, but as the comments then later +showed, they missed an important word, which was 'valid'. So, what could happen +in half aggregation is that you receive a bunch of signatures, you aggregate +them, and then you verify this aggregate and it verifies. So, the verification +algorithm returns true. But that does not mean that the individual signatures +would verify if you just parse them to schnorr verification. And this sounds +like a problem, right, because an adversary maybe not having the secret keys +could maybe do that and then produce an aggregate signature, so the entire thing +would be totally broken. There wouldn't be a point of having an aggregate +signature scheme. + +So, the reason why this is not a problem is that an adversary actually cannot do +that without having first seen the valid signatures. So, what could happen is +that there are some honest, proper signers, they produce valid schnorr +signatures, and then an adversary somehow modifies them such that individually +they don't verify anymore. They would do that by adding and subtracting some +values of these signatures. But when you aggregate them and verify them, then +the signature would still verify. And this is not a problem because the signers +were honest. They have signed the actual messages and produced those +signatures. The adversary can only change these individual signatures, but they +cannot come up with such a signature on their own. There are some applications +where this could be a problem, where when you make this assumption that when you +aggregate and then verify, that the individual signatures would also verify. +So, there are some applications, potentially even applying to a potential +Bitcoin soft fork, where this could be a problem. So, it's important to +consider, but it does not break the security of this aggregate signature scheme, +at least the normal security. + +**Mike Schmidt**: Excellent. Jonas, thanks for staying on. I neglected to give +you an opportunity to provide a call to action on DahLIAS. I assume you're +looking for feedback and review, but maybe you can specify what you're looking +for from the community? + +**Jonas Nick**: Right. If people want to read this, this would be great. And +if they have feedback and also, if they want to work on an actual BIP that would +implement such a soft fork, I mean as I said, the BIP doesn't exist yet. So, +there would be some value in actually writing this. And this holds both for +full aggregation like DahLIAS, but also half aggregation. + +**Mike Schmidt**: Well, thanks for jumping on, Jonas. We understand you're a +busy man and if you need to drop, we understand. + +**Jonas Nick**: All right, thank you. I think I'm staying on. + +_Standardized backup for wallet descriptors_ + +**Mike Schmidt**: Great. Next news item titled, "Standardized backup for wallet +descriptors". Salvatore, you posted to Delving Bitcoin a post titled, "A simple +backup scheme for wallet accounts". In it, you speak about backing up wallet +descriptors, but maybe to tease out some of the motivation and some of the +background that you put into that post, I'll throw out a naïve take. Salvatore, +I thought we just needed to write down our 12 words or 24 seed words and we're +all good. Maybe get into why that isn't true, and then the digital versions of +backups that may additionally be required? + +**Salvatore Ingala**: Yeah, good point. Some people think that if they remove +the signature, like 2-of-3, all they need is two keys and they're able to spend +the policies. And sometimes the fact that this is not true ends up going viral +on Twitter and people are surprised. And the reality is that, well, you need +more because you need full knowledge of the script. That's true for something +as simple as multisig, and of course becomes even more true when you do more +complicated stuff, like what people are doing now with miniscript and all this +timelock and combining multisig with timelocks, all these kind of things. +Because, if you don't know the exact script that you need to spend a +transaction, the exact script is only committed in the transaction, but you need +to kind of sign it. So, you need to be able to reveal it on chain when you +spend a transaction. And so, if you lost that knowledge, you still control the +keys, but you are not able to produce a valid transaction spending it. + +So, this sometimes leads to these alarmist tweets about the fact that, "Oh, +multisig or miniscript or complicated policies are dangerous", which I've always +been pushing back saying like, "Well, backup is a much easier problem than +storage of secrets, like the seed, and should be treated differently". So, I +had many discussions with people over the years where I see creative solutions +like printing, for example, the descriptor on metal, the same way that they do +for the seed, which is something that I always tell people, "Well, don't, +because you're applying techniques that were designed for objects that have +different security requirements for just backups that are much different". The +reason it's different is that, I am motivated in the post that there is a +distinction between secrecy and privacy. So, while the seed is secret, because +that's what allows you to spend the funds, and so if you know the seed, +basically you're the owner of the funds. And so, for something that is secret +like this, you don't want to do digital copies. So, that's why we have hardware +signing devices, so we can keep the keys separated from where you have the +software wallet, for example. And having more keys, having more copies of this +seed in a way makes your backup more resilient, but it also makes it more +dangerous, because it means if you have multiple places where you are storing +this, someone might find it and now they're able to spend their funds. + +Instead, the descriptor, like the xpubs, even if we call it xpub because it's a +public key in terms of cryptography, it's still private information. So, it's +private in the sense that you don't want to tell it to everybody. So, it's +public in the sense that it describes what are the keys that ends up onchain, +which are the ones that then you use to actually produce the signatures for. +But still, knowledge of the xpubs or the descriptor allows people to identify +your UTXOs and your transactions onchain, so you basically lose your privacy. +And so, you want to keep it private. And here, the requirements are different, +because now, of course, attackers might still be interested in trying to find +your descriptor, but it's much less valuable than finding your seed, because it +only gives them some information about your funds, but it's not the same as +actually getting control of your funds. + +So, the way you can defend something like that is not the same that you can +apply when you are trying to defend the seed. And anyway, for descriptors, +having digital copies is unavoidable, because every time you interact with a +software wallet, you already have a digital copy on the computer, which is an +internet-connected device. So, having additional digital copies, of course it +can expose you to some more risk of having this information leaked, depending on +how you store it, but it's not as catastrophic as losing your funds. So, that +was a bit like the motivation of the scheme. + +**Mike Schmidt**: Okay, yeah, that makes a lot of sense. I'm motivated. What +do we do about it? + +**Salvatore Ingala**: So, yeah, the core idea is that, well, in a descriptor, +you have all the xpubs of all the participants in the signing policies. So, if +it's a multisignature 3-of-5, you have these five public keys. In a miniscript +wallet, again, you might have multiple spending conditions, but each of them +might have some public keys that are given by the participants. So, you already +have some public keys that are of interest. They are the public keys of the +people who are interested in knowing the descriptor. And so, if we are backing +up the descriptor, those are exactly the people you want to be able to decrypt +this descriptor. And the reason you might want to encrypt the descriptor is +because once the descriptor or the wallet policy is encrypted, you can store it +in places that are much less trusted, potentially even on the cloud or in a +public place. You can make a tweet with an encrypted descriptor and that +doesn't reveal anything, right? And so, of course, a lot of people have this +interest in encrypting the descriptor. Murch has a comment. + +**Mark Erhardt**: If you tweet the descriptor encrypted and then later it gets +spent and the public key is visible, one of them, wouldn't that allow any +observer of your tweet to decrypt your output script descriptor and therefore +see your entire wallet history? + +**Salvatore Ingala**: Yeah. So, if someone gets the public key that is used to +encrypt this descriptor, then yes, because now they become indistinguishable +from one of the legitimate decryptors of this descriptor. But it's not the same +public keys that go onchain, because in a wallet you have a descriptor, you have +the root xpub from which all the public keys are actually derived, and so -- in +fact, maybe I'll go into describing what is the scheme. + +So, in a descriptor, you have, as I said, all the xpubs that are this root of +all the keys that are derived from these xpubs, right? And each xpub kind of +belongs typically to one of the parties that are in this wallet, in this +account. And so, the trivial idea would be like, well, that's a public key. +You can just encrypt the descriptor with one of these public keys. And now, +that entity will be able to decrypt the encrypted descriptor. And now, if you +want everybody in the descriptor to be able to decrypt this, the trivial +solution would be to just do that again for each of the public keys that you +want to be able to decrypt. And it works, would even potentially work +reasonably well in practice, because the descriptors are not that big, so making +five copies or ten copies is not a huge deal. But it's kind of like it feels +redundant and computer scientists don't like redundant things. So, you can see +that there is room for optimization here. + +So, the second iteration of this is that, well, if you want all those public +keys to be able to decrypt the descriptor, you can first generate a shared +secret somehow. It can even be random. And then you encrypt this secret with +each of the public keys. And so now, each of the public keys is able to decrypt +this secret, and now you use this secret instead with normal symmetric +encryption now to encrypt the rest of the descriptor. So, in this way, the only +thing that you encrypt many times -- so basically each of the public keys that +are involved, you will have to encrypt it. And so, you have n encrypted keys in +the backup, plus a single copy of the encrypted descriptor. So, this already +solves the duplication problem, because an encryption of a public key is not +very big. And that works. + +I will say the final idea that is added to this is that, well, this could work, +but another problem is that if you're encrypting this descriptor with the public +keys that are in the descriptor, the private keys for these keys that are needed +for the decryption could be in a hot wallet, could be in a hardware signing +device. And so, that means that you will need to implement the logic for +decrypting wherever these private keys are stored. So, that, I feel like it +could be a very big problem for adoption, because now it means that before you +can use these backups, you need hardware signing devices to be able to implement +the decryption, and you need each of them to do it, so you need to define a +standard. And this would be very difficult because, like the usual +chicken-and-egg problem, there is no demand until people start using a feature, +but you need people to actually implement the feature before you can use it. + +So, the next idea is that, well, since what you want is that anybody who has the +xpub, so anybody who is a party in this descriptor, should be able to decrypt +the encrypted backup. Instead of using the xpubs as a public key in asymmetric +cryptography, we just use the xpubs as a source of entropy, as a source of +randomness. And basically, we can just generate a pseudo random key by hashing +this public key. And so, what we get is now an asymmetric secret that anybody +who knows the xpub can generate. So, if you know the xpub, hopefully you +shouldn't give the xpub to everybody if you are a part of the descriptor, but as +long as you have the xpub, now you will be able to decrypt this encrypted +descriptor. Basically, once you do that, then you can even think of making this +fully deterministic. Now you don't even need randomness. And I commented, so +there is Jonas here, so I hope I don't get burned by the actual real +cryptographer; but because here, there is only a single plain text that will be +encrypted with that secret, just having enough entropy should be enough for +having reasonable security. So, even if this violates the standard semantic +security that is used typically in cryptography, that should be safe. And Jonas +raises his hand, so I'm prepared to be roasted now! + +**Jonas Nick**: No, it's okay, just to be clear, so you're using public keys as +inputs to derive some secrets, right, for the encryption? + +**Salvatore Ingala**: Yeah, so I use in the scheme, to be more precise, I +actually haven't described exactly the scheme, I use the combination of all the +xpubs in the descriptor to generate the shared secret. And then, this is the +shared secret that I use to encrypt the descriptor. And then, this shared +secret, I encrypt with each of the individual keys that are derived from the +xpubs. + +**Hunter Beast**: And why don't you derive a secret key and use that to encrypt +the descriptor? + +**Salvatore Ingala**: You derive the secret key how? + +**Jonas Nick**: Like, each signer could derive a secret key, right, and then +encrypt it. + +**Salvatore Ingala**: Yes, that could be an alternative. But again, we go to +the problem where we need the signing devices, or whatever you're using to +produce signatures, or something where you store the keys, to implement this +feature. By moving from the asymmetric cryptography to the symmetric +cryptography, the main goal would be that basically this encryption scheme could +become a node-dependency, something the software wallet can implement without +requiring any new feature from the signing devices, because they already have +the feature of being able to export the xpubs. And in a way, I don't think that +you're really losing any significant security properties, because the people who +know the xpubs are exactly the ones who you want to be able to decrypt the +descriptors. I know that taking a public key and hashing it and using it as a +private key looks a bit dirty, but I think it can be motivated in a reasonable +way. + +**Jonas Nick**: Yeah, at least it sounds very simple. The only thing you need +is the descriptor to encrypt the xpubs. + +**Salvatore Ingala**: Yeah, exactly. It's kind of like you can make it a pure +function that gets a descriptor and gives you out the encrypted backup. + +**Jonas Nick**: And so, one thought I had was like the ciphertext, depending on +how you do it, may leak the length of the descriptor. So, if you post the +ciphertext of your huge descriptor on Twitter and then later someone sees a huge +descriptor on the blockchain, then that might be secure. + +**Salvatore Ingala**: Yeah, that's definitely true. And anyway, this is not +like a BIP proposal yet. This is more like a blueprint. I feel like my +impression is that this is kind of on the right track, so the call to action +will be like, okay, for people working on software wallets, look, if it has the +properties that you will want from a wallet backup, I will be very interested in +working together to come up with an actual real BIP. And cryptographers, please +also review if I did any wrong assumption. There is definitely more work to do +in actually making it a real BIP. Also, you want a reference implementation, it +has a test vector and everything. And also, it would be nice to see if there +are other features that people demand from this. But hopefully, there are +features, not features that would completely change the way this scheme works. +That will be the hope. + +**Mike Schmidt**: Now, there's a lot of potential stakeholders that would be +interested in something like this, so I can imagine feedback or debate on some +of this. How has the feedback been so far? + +**Salvatore Ingala**: Yeah, there have been a few replies on the post. There +was some reply from a guy named Josh on Delving, that he worked on a somewhat +related scheme, but that was only for multisig because it was based on basically +Shamir's Secret Sharing. So, in that sense, it's a little bit more complex, but +not that much more complex. But the problem is that the moment you go towards +Shamir's Secret Sharing, automatically it doesn't generalize to miniscript where +you have different spending policies. And so, I don't think there is a common +ground that works for both those two approaches, let's say. And there were some +comments from Kevin, from Wizardsardine, developers of Liana, and his concerns +are more about adding some error correction mechanism. Although my impression +is that that's more out of scope, in the sense that error correction for me, +it's more a property of the storage, where you store this, while the scheme is +about what is it that you're storing, so not how you store it. So, I think they +have two separate things because, for example, if you store a descriptor on the +cloud, it's not your concern to do error correction. Cloud backup either fails +or error correction is someone else's business. + +**Mike Schmidt**: Murch, do you have any comments or questions? Okay. So, I +guess, Salvatore, do you want to give a call to the audience of developers and +hardware wallet folks? + +**Salvatore Ingala**: Yeah, as I say, for call to action for software wallets +mostly it would be, look into it if you're interested, if it works for you. +Because so far, basically all software wallets I've seen, typically they say, +"Oh, this is your descriptor, don't lose it, copy, put it somewhere", and that's +not a great UX, I think we can do a lot better. And once we have a good, simple +mechanism for encryption and backup, things like storing it on your Google +Drive, for example, could become a lot more attractive to people, and I think +it's a reasonable approach to take. + +**Mike Schmidt**: All right, Salvatore. Thank you for joining us. Jonas, we +actually did get a question that came in during the descriptor backup discussion +from Seardsalmon saying, "What are the other curves mentioned that have Sig-Ag +theory or implementation? If I recall, there was BLS and schnorr EdDSA, not all +the curves ever, but previously mentioned in Bitcoin related research". + +**Jonas Nick**: Yeah, so I think the previous main candidate for signature +aggregation, CISA, in Bitcoin, would have been BLS signatures. They have been +around for a while. They would require a new curve. But there are also +signature aggregation schemes that rely on different assumptions that don't +really need even elliptic curves. For example, there are also signature +aggregation schemes that have assumptions based on lattices or assumptions based +on hashing. But they are typically not as concretely efficient as something +like DahLIAS. So, for example, a hash-based scheme would be interesting. I +think that is sort of future work, because that would potentially be +post-quantum, so it would be not vulnerable against a quantum computer. And +we're already assuming that SHA-256 is collision-resistant, because otherwise +Bitcoin doesn't really work, merkle tree doesn't work, etc. So, the question +is, can we build an efficient, or at least a relatively efficient, aggregate +signature scheme from that? But those schemes, they are quite complex or not +very efficient. So, that is going to be, I think, very interesting future work. + +**Mike Schmidt**: All right. Well, Salvatore, thank you for joining. You're +welcome to stick on as well. We have some Stack Exchange questions that might +be interesting, but if you need to drop, we understand. + +**Salvatore Ingala**: I'll stick around a bit. + +_What's the largest size OP_RETURN payload ever created?_ + +**Mike Schmidt**: The second Stack Exchange question this week was, "What's the +largest size OP_RETURN payload ever created?" Timely question. And Vojtěch +links to a metadata protocol transaction, Runes, which had just over 79,000 +bytes as the largest OP_RETURN. Murch, I thought that there was a limit on the +size of the OP_RETURN? + +**Mark Erhardt**: Yeah, that's a misconception that comes up occasionally. +There is a mempool policy limit, which also differs between different +implementations of the Bitcoin protocol. The Bitcoin Core limit is 83 bytes for +the output script, which gives it, I think, a payload of exactly 80 bytes. But +the limit in other clients, I think Knots is 40 bytes. The limit was never +there for the consensus rules, so because an OP_RETURN output is already +unspendable, the 10,000-byte limit that makes a script unspendable doesn't +really apply because the output is already unspendable. So, basically, I think +the limit would be 30 MB or so, which is the network message, which is of course +then limited by the transaction size, which is limited by the block size. So, +yeah, I guess you could make a block that is a whole 1 OP_RETURN, unless I'm +missing something which is quite possible. + +I did look into this transaction very briefly and mempool.space reports that it +is a Runestone, and I looked it up further by just googling the txid. +Apparently, it is the runestone for a Rune called BARRELS-OF-OIL! + +_Non-LN explanation of pay-to-anchor?_ + +**Mike Schmidt**: Yeah, I saw that on mempool.space as well. All right. Next +question from the Stack Exchange, "Non-LN explanation of pay-to-anchor?" The +person asking this is kind of saying, "Hey, pay-to-anchor (P2A) is always +entwined with LN in the way anchors are structured for LN. Can you give me an +example of P2A that's not LN and what's the rationale there? And, Murch, I +don't know if you want to get into all the rationale, but you detailed the +rationale and structure of P2A output scripts. How would you summarize? + +**Mark Erhardt**: Yeah, I think I understood that question a little different. +It just says, don't use LN lingo to explain it, but rather what is it for? So, +P2A is generally a keyless native segwit v1 output with a 2-byte witness +program, which means 'keyless' says you don't need a signature in order to spend +it. In fact, anyone can spend it just by referencing the output, and we +identify outputs uniquely by stating the txid and the vout, which we call an out +point. And, yeah, so it's native segwit v1 because it follows the pattern with +the witness program that all native segwit outputs share. This one specifically +starts with an OP_1, which indicates it's v1. And that's permitted because +taproot, when it got introduced, only encumbered 32-byte witness programs in the +v1 space; whereas when we introduced a v0 native segwit outputs, we encumbered +20 and 32 bytes and everything else was declared invalid. When we got taproot, +we only encumbered the 32 bytes and we left everything else valid to be defined +in the future. So, yeah, basically the address shows up as fees-something, +because the 2 bytes just cause that address to be derived from the output +script. And it's a valid output because all native segwit outputs are valid to +any version of Bitcoin ever. And Bitcoin Core considers it a standard +transaction when an input is spent, since 28.0. + +So, the question was specifically, how does it fit together with ephemeral dust? +Ephemeral dust is a new mempool policy in 29.0, which makes use of P2A, or not +necessarily actually; ephemeral dust just states that you can have an output +that is below the dust limit if the transaction itself is zero fee, and that is +standard for TRUC (Topologically Restricted Until Confirmation) transactions. +TRUC transactions can have a fee of zero and still be standard. And they would +only make it into the mempool if there's a second transaction that pays fees for +them that is a child transaction of the zero-fee transaction. The last, final +rule for ephemeral anchors is, if there is a transaction that spends an output +from the zero-fee transaction that has the dust output, the dust output must be +spent by that transaction. So, you can spend only the dust output or more than +one output of the transaction, but you must spend the dust and that makes it +ephemeral, because the transaction that creates the dust output does not pay +fees, so there's no incentive for any miner to ever include these, unless +someone pays them out of band. And the fees are brought with the child +transaction and the child transaction, in order to be allowed in the same +package, must spend the dust output. + +Yeah, so P2A and ephemeral dust, they do play well together. You can make +ephemeral dust transactions with the P2A output script, using TRUC transactions +as well. And then, you have a nice two-transaction package that propagates +well. + +_Up-to-date statistics about chain reorganizations?_ + +**Mike Schmidt**: Next question from the Stack Exchange, "Up-to-date statistics +about chain reorganizations?" The person asking this is more asking about the +statistics around chain reorgs, how common are two-, three-, and four-block +reorgs nowadays? They found some data sources, but they weren't sure if there +was an anomaly there because they weren't seeing any of the longer reorgs +nowadays. Murch, you helped answer this along with 0xb10c. 0xb10c posted to +the Bitcoin Data/stale-blocks repository, where he collects a bunch of stale +blocks as much as he can find, based on the nodes that he's running and the +information that he receives. You also pointed out forkmonitor.info and +fork.observer. Forkmonitor has an RSS feed of this sort of activity, and +fork.observer has a visualization based on some of their recent history. Do you +want to elaborate on any of that? + +**Mark Erhardt**: Sure. So, stale blocks have become fairly uncommon. They +used to be much more common. We would have a stale block about once per day. +And then there were a few improvements on block propagation. And from the +rumors I've heard, a bunch of mining pools updated their hardware that piloted +their mining pool. Some of the mining pools apparently were running very +low-powered devices as controllers for their mining pools, and that added +additional latency because these Raspberry Pis, and other microcomputers, would +take forever to validate the block, and that gave their mining pool more time to +work on the old template and we had stale blocks more often. So, in fact +lately, we have, I think, a one-block reorg about once every two weeks or so +roughly. So, that's exceedingly uncommon now. + +0xb10c writes here that there have been only two two-block reorgs since November +2020: one was at block height 788,686, which I think would have been about April +2023, from the top of my head; and the other one was in November 2020. So, +those two are about two-and-a-half, three years apart. So, I don't remember +when we last had a three-block or four-block reorg. Anyway, that stuff doesn't +happen that much anymore. + +**Mike Schmidt**: And if you're curious about some of the data yourself, jump +into that Bitcoin Data stale-blocks repo and you can run your own analysis on +it. Go ahead, Murch. + +**Mark Erhardt**: Oh, yeah. Also, if you're running a super-old node, like if +you started running a node in 2011 and still have the original blockchain that +you processed, the block files, 0xb10c has a tool that he publishes in this +repository, or ask him for it, but it writes out the stale blocks that your node +has seen. And that's how all the contributions of what he collects in the +stale-blocks repository have been collected, because obviously his node didn't +see all of the stale blocks and he's crowdsourcing more information. So, if you +have a super-old node and want to contribute to historic data, you could get in +touch with 0xb10c in order to help collect your stale blocks. + +**Mike Schmidt**: On the readme for the stale-blocks repository, there's a +section for contributing full stale blocks and contributing stale-block headers. +There's some shell scripts that you can run and that, I think, would be very +welcome. Good idea for call to action, Murch. + +_Are Lightning channels always P2WSH?_ + +Next question from the Stack Exchange, "Are Lightning channels always P2WSH? +Polespinasa notes, in his response, the P2TR simple taproot channels that are +something that we've discussed on the show a few times, particularly around LND +that supports P2TR on the LN, specifically edging towards their Taproot Assets +project, which relies on taproot and has the ability to have assets other than +Bitcoin using the LN. Polespinasa also noted some support, or lack of support, +from Core Lightning (CLN) who doesn't support taproot channels but does allow +you to have a P2TR address for onchain, and likewise, Eclair, that doesn't +support taproot channels yet, but they do have taproot in one of their products +for their swaproot swap protocol. + +_Child-pays-for-parent as a defense against a double spend?_ + +Next question from the Stack Exchange. Murch, you answered this one. I thought +this was kind of interesting, "Child-pays-for-parent as a defense against a +double spend?" I feel like you might do a better job of summarizing what the +person is asking for here and how CPFP comes into it. + +**Mark Erhardt**: Yeah, basically they were looking at a transaction that had a +single confirmation and they were starting to maybe ship out the product or, if +it's a digital good, handed that over already. And then, the sender of the +money would publish two blocks to reorg out this transaction and divert the +money back to themselves. And they are asking, would it now be possible to +offer a transaction that pays a humongous transaction fee in order to get their +own shorter chain used to extend to a longer chain tip and basically reorg out +the attacker again? + +So, in theory, this has been discussed quite a few times. I think AJ has a few +write-ups on this sort of topic in Delving. I haven't pulled them up yet, +unfortunately. But the general idea here is that the transaction by itself +would not propagate, of course, because in the chain tip, or in the best chain +from what all other nodes have seen, the input is spent already, right? You +would need to use the money that was sent to you via this very big transaction, +let's say 10,000 bitcoin as in the question, and you send 100 bitcoin in fees on +a child transaction from the payment that went to you on the now stale chain. +In order to see that transaction with the 100-bitcoin fee, they would have to +even consider the stale chain tip as a potential alternative history. But once +they've seen the better chain, the longer, heavier chain, they wouldn't consider +the transaction valid anymore, nodes would not forward the transaction. So, in +order for anyone to even consider this offer, this bribe so to speak, they would +have to run custom software that invalidates the last block or last few blocks, +whenever there is more than one chain tip they're aware of, in order to check +whether there would be any such bribes. At least at this point, I'm not aware +of any mining pools running all this extra overhead in order to see whether +anyone is trying to bribe them to build out a stale chain tip. + +The next problem with this approach is once the attacker sees that you're trying +to bribe the miners into double-spending the attack, the attacker can just start +to offer a bribe themselves for the miners to stay on their chain. And given +the large amount, and given that they're stealing and benefiting more already +because they have both gotten their money back and the goods, they can probably +outspend the defender, the victim of the attack, because the victim of the +attack needs to at least make back their losses, while the attacker has already +a 100% gain to start with. So, they might be able to outspend. The attacker +also is ahead already by one block, so it's much more likely for them to win, +especially if they just offer that bribe for people to extend the already best +chain tip, because that transaction does propagate. + +Finally, I don't think that miners should consider running this software, +because miners benefit indirectly from the perceived stability of the Bitcoin +Network and the reliability of confirmations. If miners actually worked on +subverting the reliability of confirmations, I could see that backfiring on the +overall value of Bitcoin, and miners being huge holders of Bitcoin would shoot +their own foot that way. + +**Mike Schmidt**: Excellent walkthrough, Murch. Folks may listen to this +scenario and also think of previous hacks that have occurred. I think there was +something with Binance at some point, where they got hacked and then there was +discussion of if there was going to be some sort of a reorg. And the reason +that this approach would not work there is because in the approach outlined by +Reggie in his question, there was actually an initial transaction that was valid +that the person being double-spent had, in order to have then a way to +incentivize the reorg. Whereas, if the funds are just stolen and there's no way +to incentivize that with CPFP, like in this example, that was never a +discussion. This approach wasn't discussed back then. + +_What values does CHECKTEMPLATEVERIFY hash?_ + +"What values does CHECKTEMPLATEVERIFY hash?" Average-gray outlined the fields +that CHECKTEMPLATEVERIFY (CTV) commits to. I actually think he used maybe some +different wording in his answer. I actually went to the BIP and took the fields +out, which is nVersion, nLockTime, input count, sequences hash, output count, +outputs hash, input index, and in some cases, scriptSig hash. + +_Why can't Lightning nodes opt to reveal channel balances for better routing efficiency?_ + +"Why can't Lightning nodes opt to reveal channel balances for better routing +efficiency?" René Pickhardt, who we've had on the show a few times before +talking about routing efficiency, explained some of the concerns. He notes the +potential staleness of the data that is being propagated through whatever means +this would be propagated, the trustworthiness of the data. So, the idea here +is, can you say what the balances are between all the channels and have that as +part of your gossip or network graph? And so, the staleness of the data, the +trustworthiness of that data, and then certain privacy implications as well. +Yeah, go ahead, Murch. + +**Mark Erhardt**: There's also the concern that if every node wants to update +the whole network on basis of every payment, that the amount of data that would +have to be sent around in the network, besides making all the payments +transparent and losing all privacy, the amount of data would just be completely +unsustainable. The channel announcements, just the existence of channels, are +something like 150 MB, or even more. That might already be a compressed graph. +Imagine if each of these were updating several times per hour, maybe several +times per minute, and making new announcements all the time. That would +probably incur quite the bandwidth cost. + +**Mike Schmidt**: Yeah, indeed. You'd have a trade-off between the bandwidth +and the staleness, I guess. You'd still have the trustworthiness and then, best +cases, privacy is completely ruined because you can see every single payment if +you saw this all real-time, I guess. And then, if you're curious about some +previous discussion from this, I think it was actually René's own, was it René's +own proposal? Yeah, from 2020 to the BOLTs repository, which is actually still +open, where he outlines this, and there's a thread over the years of some +discussion. + +**Mark Erhardt**: To be clear, I think he only proposed that it would be shared +two degrees, so to your friend and to your friend of a friend, which would of +course make the amount of data that flows much smaller. Let's say if you have +ten peers and each of your ten peers has nine additional other peers besides +you, you would only have to reach about 100 other nodes, or even less if they're +interconnected. Whereas, if you have to reach every other node in the network, +which is I believe several thousands, that would of course be much more. + +_Does post-quantum require hard fork or soft fork?_ + +**Mike Schmidt**: Last question from the Stack Exchange, "Does post-quantum +require hard fork or soft fork?" And Vojtěch answered this one. He outlined a +vision that would involve a post-quantum (PQC) signature scheme being done via a +soft fork, and then folks migrating their funds to this PQC scheme in time for +the quantum threat to actually be materialized. And then, he noted a separate +question which is, "What do you do about coins that are vulnerable, especially +publicly exposed?" And he outlines one option is to do nothing, let them be +stole by quantum attackers; and another option is making those coins unspendable +with a soft fork after a set deadline. And he outlines yet another option, +which was making those coins unspendable. I think he had one here that would be +a hard fork. Oh, he notes the only time that we would need a hard fork is if we +first wanted to make the vulnerable coins completely unspendable with a soft +fork, and then later wanting to re-enable spending with a secure signature +scheme. So, that would actually be a hard fork. I butchered that a little bit, +Murch, but maybe you can clean it up. + +**Mark Erhardt**: Yeah, you could even do this with a soft fork. You would just +freeze them for a few years and you could update that if you need more time. +But by the freeze only being time-limited, you could soft fork it and then it +would heal itself and become spendable without a hard fork. But yeah, so I was +pretty surprised. This debate has also been ongoing on the mailing list and on +Stacker News and other places, and I'm very surprised by a huge number of people +proposing or advocating for, "Just let the attacker have the coins. We should +never burn any other people's coins. Certainly, you shouldn't appropriate them +and not even burn them". I was just so surprised because among technical +contributors, the overall tenor seems to be that people say, "Well, this is a +systemic risk and we would need to burn it and there is absolutely no reason why +Bitcoin should incentivize development of quantum computers". + +So, to me personally and a few other people, it seems strange that people are +much more leaning towards, or at least in the discussions that I've read, a lot +of people are leaning towards, "It's the responsibility of the key holder to +keep their coins safe and we should never touch any other people's coins, so let +the attacker have it, because they know the key and at that point, we can't tell +whether it's the attacker or the original owner. And if there's millions of +coins going back into other hands, oh well, so be it, and we'll just have to +weather that, I don't know, tanking value or something". So, yeah, interesting +how at least a big number of social media participants come down exactly +different to me that question. + +**Mike Schmidt**: And it doesn't seem like, from what I've seen either, that +there's people that are on the fence. It seems like there's an initial gut +reaction one way or the other, and they're just on the extreme ends of it. Is +your read, when you're reading some of these discussions, that people are like, +"Hey, don't touch it, or let it be stolen. Don't force people, don't lock +people's coins involuntarily"? Is what is behind that, in your opinion, some +principle or is it that, "Hey, this quantum thing is hyped and it's not actually +ever going to happen, so therefore we don't want this precedent of speculatively +locking people's funds, because we think this quantum thing is going to happen". + +**Mark Erhardt**: Yeah, I think that's all three. So, there's people that are +saying, "Quantum's not going to happen anytime soon and we don't have to be +worried"; there are people that are saying, "We should never touch other +people's coins in principle. You should be able to go away for 25 years and +come back and your coins should be spendable. We should never plan for any sort +of collaborative action on other people's coins"; and then some mix thereof. + +_LND 0.19.0-beta.rc3_ + +**Mike Schmidt**: Moving on to the Releases and release candidates, we have LND +0.19.0-beta.rc3. We've had some version of this RC on for a while. I believe +it was #349, Murch, where you gave a nice overview of this forthcoming release. +So, I'll point people there, and we won't jump into it today. + +_Bitcoin Core #31247_ + +Notable code and documentation changes, Bitcoin Core #31247, which implements +serializing of MuSig2 PSBT fields. And maybe as a background, users who want to +coordinate on creating a transaction can use the PSBT structured data format to +pass around partial bitcoin transactions. However, with the addition of MuSig2, +the old PSBT fields were insufficient and new fields were added to the PSBT in +order to support the required MuSig2 participants being able to exchange PSBT +files with each other. And so, BIP373 specified what those MuSig2 PSBT fields +were. And now, Bitcoin Core is working towards supporting, receiving, and +spending of inputs using MuSig2 aggregate keys in the wallet. So, this PR today +that we're talking about is part of, and split off from, a broader PR to achieve +that functionality. That PR is, "Be able to receive and spend inputs involving +MuSig2 aggregate keys". + +A little slice of that was carved off for this PR that works towards that goal +by doing three things: one, it implements serialization and deserialization of +the MuSig2 PSBT fields that were specified in BIP373; it also adds the MuSig2 +fields in the decodepsbt RPC; and finally, it adds BIP373 test vectors. + +**Mark Erhardt**: Yeah. From my understanding, it still doesn't mean that, or +maybe I'm wrong about that, but I don't think that it means that the Bitcoin +Core wallet can participate in MuSig2 transactions yet with PSBT or otherwise. +I believe we're still working on support for that. + +**Mike Schmidt**: That's right. You can check out the, I don't want to call it +a parent PR, but the one that this #31247 was split off from was #29675, which I +think is the more comprehensive actual implementation that Murch is referencing. + +_LDK #3601_ + +Last PR this week, LDK #3601, which changes the way that LDK handles error +codes, specifically updating the handling of HTLC (Hash Time Locked Contract) +failure codes, error codes, and they want to now represent all possible BOLT4 +error codes. It involved changing the representation of errors from integers in +LDK to a named enumeration, and also adding previously unrepresented error +codes. And there was a bunch of internal refactoring commits as part of this PR +to facilitate those changes from the int to the enum. There's also a separate +open PR to LDK that reflects these failure reasons in the API, but that's a +follow-up PR to this one. I didn't see anything else too notable there. + +Murch, you're good? Awesome. Salvatore, thanks for hanging on and thanks for +joining us this week as a special guest. + +**Salvatore Ingala**: Thanks for having me. + +**Mike Schmidt**: Jonas dropped, but thanks to him for joining on the News and +also some of the Stack Exchange discussion. And thank you to Murch, as always, +co-host, and for you all for listening. Cheers. + +**Mark Erhardt**: Cheers. Thanks for your time. {% include references.md %} From 8dcde5d7568d0343323b2ab332ec8d4ef30bc409 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 22 May 2025 15:34:35 -0500 Subject: [PATCH 021/278] Podcast: add 352 transcription --- .../en/podcast/2025-05-06-newsletter-recap.md | 921 +++++++++++++++++- 1 file changed, 920 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-05-06-newsletter-recap.md b/_posts/en/podcast/2025-05-06-newsletter-recap.md index f274a4bc0b..a2bb915f79 100644 --- a/_posts/en/podcast/2025-05-06-newsletter-recap.md +++ b/_posts/en/podcast/2025-05-06-newsletter-recap.md @@ -18,6 +18,925 @@ Mark “Murch” Erhardt and Sjors Provoost discuss [Newsletter #352]({{page.ref ## Transcription -_transcription coming soon_ +**Mark Erhardt**: Hello and welcome to Bitcoin Optech Newsletter Recap #352. My +name is Murch and I work at Localhost Research, educating about the OP_RETURN +drama. Today, I'm joined by Sjors. Sjors, would you like to introduce +yourself? + +**Sjors Provoost**: Yes, hello I'm Sjors Provoost, I work on Bitcoin Core, based +in the Netherlands. + +_Comparison of cluster linearization techniques_ + +**Mark Erhardt**: Cool. Today, we have two news items, one Release candidate +and four Notable code and documentation changes. We'll jump into the news. The +first news item is about a comparison of cluster linearization techniques. If +you have been listening before, you probably heard us report on cluster mempool. +And Pieter Wuille had been talking a lot about how to best find the correct +order or the best order of a cluster. We reported on this before, when out of +the Bitcoin Research Week in November, a new approach was found that was more +efficient than the original currently implemented cluster mempool linearization +algorithm. And then recently, we reported on this in Newsletter #340, about 12 +weeks ago. Another researcher pointed out that they found a paper from the '70s +that described an algorithm that should be able to be used in the cluster +linearization. + +So, Pieter went down this rabbit hole and evaluated all three approaches, the +original candidate set search algorithm; and the spanning forest linearization +algorithm that came out of Bitcoin Research Week, when people realized that it +could be described as a linear programming problem and all the knapsack solvers +and so forth would be applicable; and then now, as the parametric min-flow-based +algorithm by Gallo, Grigoriadis and Tarjan or GGT. Yeah, so he goes into a +bunch of details in this Delving post and finds out that he wants to use the +spanning forest linearization, because it can be interrupted anytime. The +longer it runs, the better the result gets, but any intermediate state will be a +decent or improving state and can be used immediately as a linearization. And +other than the other two algorithms, it doesn't require budgeting, because you +can just allocate a certain amount of time for each cluster and fairly compute +and distribute your computation power between the clusters. + +So, it seems to be slightly faster than the other two approaches, or slightly +faster than GGT, and much faster than candidate set search. And, yeah, there's +more discussion on this Delving thread. Several other developers or interested +parties asked questions that are discussed. And, yeah, there will also be a +talk at BTC++ tomorrow. So, for the people that really want to dive deep, they +could try to get a copy of that talk sometime soon probably. All right. +Anything from Sjors on this one? + +**Sjors Provoost**: Yeah, so I mean first of all, I think cluster mempool is +pretty cool, but in practice I'm only following it from a distance, because I +think it will be somewhat helpful in Stratum v2, where what we want to do is +basically push templates out to miners as soon as they're better. So, of +course, when a new block comes in, you want to give miners something new to work +on. But also, if you have better fees in a mempool, you also want to give +miners a new block. And the question of, "Are fees better in a mempool?", right +now is kind of tedious to ask. You basically just create a block and then +compare it and like, "Yeah, it's better". But with Cluster Mempool, we can +probably answer this question much faster, though there's some hairy details. +Like, you created a block template before, so you know exactly how many fees are +in there. But as you just described, there's all these little algorithms that +can further and further optimize the block. So, you may get two numbers. One +is like, "We know for sure that there's this much fees in the block", but there +could be more because the algorithm is still working on it. So, then the +question is, when do you decide to send out a new block to the miners? Do you +do that when the worst case is better, when the best case is better, stuff like +that. But I'll worry about that when there's some code I can actually use. + +**Mark Erhardt**: Right. Yeah, so one of the advantages of cluster mempool will +be that block template creation should be much faster, as you can sort of divide +up the problem. You first sort all of the clusters, which are just the groups +of transactions that are related to each other through parent and child +relationships. And because you already know the best order for every cluster, +it is very easy to assemble a block-size chunk of transactions from the top by +merging the best parts of various clusters to get the block template. And, +yeah, once you have the block template, it's very easy to compare whether it's +better or worse, because you see exactly how many fees you will collect with the +block template. But of course, you still have to run the block template +creation in order to make a reliable comparison. Yeah, cool, okay. + +_Increasing or removing Bitcoin Core's `OP_RETURN` size limit_ + +Let's get to the second news item, which might come as a big surprise to +everyone right here. The second news item is, "Increasing or removing Bitcoin +Core's OP_RETURN size limit". So, the history for this one is that one +developer proposed on the mailing list that it might be time to revisit the +question of whether the OP_RETURN limit should be dropped. The email cited +especially that there was another use case of using Bitcoin's blockchain for +data availability that would be writing data to public key hashes, which then, +because they're unspendable, live in the UTXO set forever. + +**Sjors Provoost**: Can you add this to public use, as this taproot? + +**Mark Erhardt**: Okay, sorry, public key instead of public key hashes, yes. +The idea was if we had slightly larger OP_RETURN outputs and those were +standard, maybe the about-to-launch rollup could instead write to OP_RETURNs, +which then would be able to hold the entire data that they need to make quickly +and reliably available. This discussion progressed a bit on the mailing list. +There were several people that thought it was a good idea, or that the OP_RETURN +limit was no longer timely, and Peter Todd opened a PR to the Bitcoin Core +repository. This pull request was then quickly discovered by someone who +represented it as opening the door to more spam and turning Bitcoin into a +shitcoin, making it an altcoin, doing away with Bitcoin being only for payments. +And this led to, let's say, a heavy involvement of the community in the PR. So, +far so good. Sjors, any thoughts? + +**Sjors Provoost**: Yeah, it may be useful to go back a little further into +history because this debate is, I think, at least 11 years old. Like, 2014, +there's a BitMEX research blog post called, "The OP_RETURN Wars of 2014", which +kind of suggests that this stuff was behind us. And that's probably also why +maybe some people get the wrong impression when they think Bitcoin Core is just +proposing this out of the blue. It's not, it's one of those things that have +been simmering for a decade and this seemed like a good time. But if you're not +aware of that previous discussion, it can come as a surprise. + +So, back in the olden days, there was something called Counterparty, I think +they were the first ones. They started doing NFTs, that's what we call them +now, basically NFTs on the blockchain, the Rare Pepe, that sort of stuff. And +they were initially, I believe, encoding their pictures and other data as fake +public keys. This is basically in the bare multisig, so you would create a +1-of-3 or 3-of-3 multisig signature and all of the keys would be fake. And you +would basically put them all in the output of a transaction. This was quite bad +because unspendable keys means that they're going to stay in your UTXO set. And +so eventually, people were like, "Okay, can we mitigate, can we convince them +not to do this?" and the solution then was to make OP_RETURN standard. So, +OP_RETURN has existed since the beginning, it's part of consensus, you can make +them as long as you want according to the consensus rules, but they wouldn't get +relayed. + +So then, I think initially the compromise was, "Let's relay 40 bytes", because +that would be enough to do at least a hash of whatever they wanted to do, +instead of the whole picture basically. And then, well, there was a bunch of +discussion on the mailing list, probably also on GitHub, whether this limit +should be 40 or 80, and it was kind of based on the merits of the use case. So +like, "Okay, a commitment should just be 32 bytes plus a little bit more, so why +do you need 80?" And then eventually, I think that the conclusion was 80 is +fine. I believe Bitcoin Knots very early on already made it 40, but that's up +to everyone, but noticed that people were still sometimes using these bare +multisig things, because the way Counterparty was then designed was to say, +"Okay, if we need less than 80 bytes, we'll use OP_RETURN. If we need more, +we're going to use these bare multisig, this pattern". And so, this came back a +few years ago in the form of Stamps, which was basically using Counterparty. It +was basically, they were marketing it as provably unprunable, that sort of +nonsense. + +So, they used Counterparty, which as far as I know is completely unmaintained, +but it has this property of creating bare multisigs if the payload is more than +80 bytes. And so, they basically deliberately made payloads that were bigger +than 80 bytes, namely jpegs, and started growing the UTXO set at a very worrying +pace. It was already made clear there was not much you can do about it, because +even then, if we had increased the OP_RETURN limit, we could have dropped the +OP_RETURN limit back then, and we could have told the stamps people, "Hey, why +don't you just use OP_RETURN instead of these large multisigs. And then, they +probably would have said two things. One is, even if we wanted to do it, we +can't, because nobody is maintaining this software, so we can't modify +Counterparty to just always use OP_RETURN. And even if we could modify it, we +don't want to, because the whole point is to make it pollute the UTXO set. So, +in that case, you could say, "Well, then maybe there's no point in raising the +OP_RETURN limit". But that was not the only thing that happened, of course. +What to do more? + +**Mark Erhardt**: I think this is a good point to jump in with another thing +that I wanted to raise. What is mempool policy versus consensus? You mentioned +it already in your description, but do you want to take it? + +**Sjors Provoost**: Okay, yeah. So, consensus means if you're validating the +blockchain just looking at blocks, that's the rules you can enforce. Whereas +the mempool and policy basically means, "Am I going to relate this stuff or I'm +going to put it in my own mempool. And if I put it in my own mempool, I'll send +it to my peers". Those are generally the same thing. So, generally, the rules +for the mempool are more strict than the rules for consensus. So, you may not +relay things, but if they're in a block, you'll accept them anyway. Which +means, if you want to get something in a block, you'd have to go directly to a +miner. That used to be somewhat of a barrier, but that's definitely not a +barrier anymore. There's all these accelerators out there, there's even people +that are running with more permissive mempools for the sole purpose of relaying +this stuff. + +**Mark Erhardt**: Right, sorry, you had another point that you wanted to add +regarding the history? + +**Sjors Provoost**: Yeah, the stamps I think was an example of an actual +adversarial user that had as a purpose to pollute the UTXO set. But a case like +the Citrea whitepaper, that was brought up in this mailing list post that we +started with, is a case of a company using this technique of bloating the UTXO +set because standardness wasn't enough for them. They wanted to be on the safe +side, but they would be open to using OP_RETURN probably if it was made +available to them. So, there, I think it does make sense to increase the limit. +Now, in their case, increasing it to 150 bytes or so would be enough, it doesn't +have to be dropped entirely. Which then gets you into discussion of, "Okay, if +we're going to increase it to 150, do we really want to have this debate every +time?" But what I think is more important to say is that they don't seem to be +price-sensitive. If you just look at how that protocol works, and I don't +pretend to understand it, they need to put this 140-byte zero-knowledge proof on +the blockchain, they need to make absolutely sure that it ends up on the +blockchain on time. And if that costs them $1 million, well, that might be too +much. But if it costs them like $100, that's probably fine. + +So, just by giving them a discount by making OP_RETURN bigger, that's not going +to motivate them. It's really just about you give them the option and say, +"Please use this because it's nicer". So, they don't necessarily want to +destroy Bitcoin, but also, there's no monetary incentive. Whereas in the +original days with Counterparty, I think there was an economic incentive for +them to use OP_RETURN instead of the bare multisig, because it just made their +life easier and there weren't any of these accelerators. So, we just lived in a +very different world there. + +**Mark Erhardt**: Right. So, let's very briefly recap that. Citrea is some +ZK-Rollup. It produces transactions in some second-layer scheme, and then it +anchors into the blockchain, into the Bitcoin blockchain by writing these proofs +into the Bitcoin blockchain. They have come up with a scheme that is +consensus-valid and uses standard transactions right now, aka transactions that +would be accepted by the default mempool policy of most Bitcoin Core nodes that +are deployed today. And basically, the idea was, "Hey, if we increase the +OP_RETURN limit a little bit, we, as a Bitcoin community, could ask them, 'Could +you please not write into the UTXO set, and instead use this OP_RETURN output to +write your data into an output, that we can at least ignore safely after +processing the transaction?'" + +Yeah, so I think we've covered what mempool policy is. We've set the background +with the example of Citrea. And now, you said they would need about 150 bytes +for their proof. I think it's 80 bytes plus two times 32 bytes, so 144. So, +what happens at that point? What's the interesting thing right around that +number of bytes? + +**Sjors Provoost**: Well, yeah, so far, you could say this discussion might have +been very similar to the 40 versus 80 bytes thing. It's a bit of a discussion +about what's more useful, but already from a weaker negotiation point of view, +because they're going to do this thing anyway. But the elephant in the room, +which we haven't talked about, is inscriptions. And inscriptions came around, I +think it's two years ago now? I forgot, time flies. + +**Mark Erhardt**: Yeah, 27 months or so. + +**Sjors Provoost**: Somebody, for some reason, many, many years after segwit +activated, and even many years after taproot activated, realized that you can +stuff 4 MB of crap in the blockchain without violating standardness rules, by +using the witness, using a pattern. Basically, I think you say OP_IF, or with a +zero in front of it, which means it's false, so anything after OP_IF is not +executed and then you just put your data there, and then you put OP_ENDIF, +something like that. Now, you could have done this with segwit in a slightly +different way, but it doesn't matter. So, once they found out, created a whole +hype around it, people got angry. Of course, that angriness is part of the +marketing. And since then, blocks have basically been full. There've been +waves of worse and less bad. This coincided with the Stamps story I just told +you. So, that was sort of a reaction like, "Oh, these inscriptions might be +pruned. Let's just put things in the UTXO set". But that, I think, died, maybe +not. + +**Mark Erhardt**: I believe so, yeah. + +**Sjors Provoost**: So, then you're looking at, "Okay, why are we still doing +this OP_RETURN limit thing, because it's not going to make blocks smaller? +They're going to be 4 MB now, so what's the point?" It's just even a slight +motivation for people to start adding things to the UTXO set again. + +**Mark Erhardt**: Let me jump in there very briefly. You said, "It's not going +to make blocks smaller", which is funny, because of course the witness data is +discounted by 75%. So, only if you have a lot of witness data, you can have +blocks that are much bigger than 1 MB. For all the other data that is not in +the witness, the old limit holds and the bytes there come in at full weight. +So, if we write data to output scripts, like OP_RETURN does, those bytes are not +discounted and count fully towards the 1-MB limit, or I should say count as 4 +weight units towards the 4 million weight unit limit. And that means OP_RETURNs +do make the block smaller. More OP_RETURNs means less witness data and smaller +blocks. Sorry, please continue. + +**Sjors Provoost**: But they'd be four times more expensive per byte. No, I +mean, that's where we were two years ago. And so, I believe also Peter Todd at +the time just decided to open a PR and said, "You know, this is pointless. +Let's just drop this OP_RETURN limit". That created a whole bunch of drama, and +eventually that PR was abandoned based on some sneaky math, not sneaky math, +just some amazing math by you. So, maybe you want to explain that math. + +**Mark Erhardt**: Yeah, basically, an OP_RETURN requires that you create another +output. Adding another output to a transaction means that you need to have an +amount field, which is 8 bytes. Then, you need to have a byte that indicates +how long the output script is. And then, in the output script, there's 2 more +bytes of overhead and the OP_RETURN opcode itself and then a pushdata opcode +that indicates how long the data payload is. And so, at least 11 bytes of +overhead; for longer messages, it would be a bigger overhead, because the +pushdata can get bigger. But anyway, so you only have 11 bytes of overhead for +OP_RETURN. For inscriptions, you have a lot more overhead, because you have to +create an output that commits to the inscription. And then, in the input, you +have to have a scriptpath spend and have the construction that Sjors described, +which the inscription enthusiasts call 'envelope'. And overall, I think the +overhead for that is, I don't remember from the top of my head, but something +like 50 vbytes or 60 vbytes. So, altogether, the more overhead means that a +small message in an inscription is more expensive than a small message in an +OP_RETURN. But then, because the witness data is discounted by a factor 4, over +time or as the payload gets bigger, it becomes cheaper to use an inscription for +the data instead of an OP_RETURN. + +Now, my calculation back then might have had a mistake, because Vojtěch Strnad +recently redid the calculation and had a different result. But we agree that +roughly around 144 bytes or 143 bytes, the data payload becomes cheaper to do on +an inscription, and at smaller amounts it's cheaper to do an OP_RETURN. + +**Sjors Provoost**: There was a range between 80 and about 140, depending on how +you do the math, where it was still cheaper to do it in OP_RETURN than to use +inscription. So, just dropping the OP_RETURN limit would basically give about +60 extra bytes to people in a way that's cheaper than inscription, so that might +be a net harm increase. So, that didn't seem like a good idea back then. + +**Mark Erhardt**: Right, okay. + +**Sjors Provoost**: So, now we are in this new world where we're seeing people +making these bigger things, bigger than 140, or at least almost at the edge of +it, and we don't want them to do that. We really want them to not create these +extra UTXOs. And the only way to convince them to not make these extra UTXOs is +to say we need to increase the OP_RETURN limit to at least about 140. So, we've +established that we need to increase it to 140 to prevent the UTXO set from +being destroyed. We've also established that above 140, inscriptions are +cheaper anyway, so there's no incentive to use OP_RETURN. So then, the +conclusion is just drop the limit, because it is not doing anything, it's just a +bunch of extra complexity. Plus, if every time you want to increase this limit +because somebody needs slightly more for whatever their weird scheme is, you +need to have this discussion like once a year, which is also not very +productive, as we have seen. + +It was those combinations of reasons is why it made sense to just drop it. And +I get that this comes out of the blue for some people, but if you've been +following this more closely, it should make sense. + +**Mark Erhardt**: Right, and now, there's of course people that are in favor of +dropping the OP_RETURN limit. A lot of Bitcoin Core contributors seem to be +convinced that it would be a net harm reduction; and a lot of opponents appear +to think that reducing the friction for people to add data to the Bitcoin +blockchain overall will mean that it will get used a lot more and it will cause +another wave of what they call spam data transactions, and they consider this a +big change in the culture of Bitcoin, not so much in the code but rather in the +culture, that this is not being fought harder. And I think a big part of why +this debate has been blowing up so hard is because of the disconnect of one side +trying to soberly weigh the trade-offs, and maybe permit, in their perspective, +a little more data on the Bitcoin blockchain, so at least the data doesn't get +written to the UTXO set. And on the other side, people feel that the identity +of Bitcoin is being changed. + +**Sjors Provoost**: Yeah, and I guess that does get to another aspect of, how +hard should you fight spam, right? And I don't mind calling some of these +things spam, although I still think it's subjective. But I personally think +that monetary use cases should be the most important one, censorship resistance +basically. So, you could decide, as a project, to allocate a lot of resources +to saying, "Okay, let's really try and prevent people from putting arbitrary +stuff on chain". The question is, if you take that a few steps ahead, where +does that take you? And I think it takes you to, first of all, you're just +going to fail, because it is a cat-and-mouse game. And this cat-and-mouse game +really has to be played with consensus code, in my opinion. The idea of using +standardness just doesn't work, because no matter what Bitcoin Core does in its +standard rules, somebody like Peter Todd is going to release something like +Libre Relay, it's going to be accelerators, so it'll be trivial to bypass, +especially for people that are willing to spend money there anyway. And there's +the status aspect of polluting the blockchain. So, there's already a very +perverse incentive to try and break it. + +So, if consensus is your only way, now we know how much work it is to make +consensus changes, even for the most trivial and non-controversial things. So, +do we really want to put huge amounts of effort into finding consensus changes +that actually prevent people from stuffing data in the chain? I think that's +not worth the effort. And those changes would be very, very dramatic. You'd +need signatures to prove, or maybe not a whole signature, like a zero-knowledge +proof, to prove that a public key really has a corresponding private key, that a +hash really has a preimage, all those sorts of things; it will probably break +all sorts of nice use cases by accident; it would definitely make blocks bigger. +It adds a lot of complexity that I'd rather not do. And then, you can still +stuff data into blockchain, because even if you have to prove that there's a +valid private key, well now you can still grind your private key right until you +have a public key, that at least the first, say, 10 bytes, or not 10 bytes, but +the first part of the public key still represents the data that you're trying to +do and the rest is just waste. + +**Mark Erhardt**: Or you can do the same with signatures, or you can stuff data +into the sequence field, or you can stuff data into the timelock. + +**Sjors Provoost**: Yeah, but the only thing to add is, if you really want to +stop spam, I think you would literally have to have a committee that just looks +at blocks, like actual humans that look at blocks and just censor them. And +that's something we absolutely don't want to do. That would be effective. If +you had a consensus rule that says, "Hey, these people for the next five years +are now authorized to decide what is and isn't spam", that would work. That +would be absolutely terrible, but it would work. So, I think just if you look +at this game, if you really want to play it, not just virtue signal like, "Oh, +my node doesn't accept spam", no, actually play the game and actually try to win +the game, you don't like where you're going to end up. And it's a huge resource +consumption thing that I think we should be spending on other things. + +**Mark Erhardt**: Yeah, I think that a lot of people have been spending a lot of +time on the debate in the last week. I think this ties nicely into what mempool +policy is trying to achieve in the first place. And so, Gloria Zhao and I wrote +a ten-week series in Optech, I think that was one or two years ago, about +mempool policy and mempool. And the title eludes me right now, but I'll find it +in a moment. It was called, "Waiting For Confirmation", a series about mempool +and relay policy. And there, we argued that mempool police should be largely +homogenous across the network. And I think a point that has been brought up a +lot in the last week is that mempool policy should also be very closely related +to what gets mined often in blocks. + +So, the advantage of having the things in your mempool already when a block +comes in is, you will be able to very quickly validate the block. You have +already evaluated all the scripts in your transactions, and when a compact block +announcement arrives, it basically just provides a recipe how to reconstruct the +block from the transactions that you already have in your mempool. If a lot of +people have very different mempool policies than what gets mined, it means that +the compact block announcement is received and then you see, "Oh, I'm missing +two, three transactions". And that actually increases your block reconstruction +time by probably a factor 100 or so. Because now, instead of just building the +block from the transactions in your mempool, you have to ask back to the peer +that announced the block to you, "Hey, can you give me these two transactions?" +especially if these are huge data transactions or if it's many transactions that +are missing. And it just adds another 100 milliseconds, or so, maybe 150 +milliseconds, until you have received all of the remaining transaction data, and +you can reconstruct the block and validate it. + +Now, block validation times, or the latency until a block has propagated +entirely through the network, is beneficial to the largest miners, because they +win a block more often and the block propagation time only slows down their +competitors. Because the block propagation time has gotten so much smaller, we +have a lot less stale blocks. It is more fair for smaller miners to +participate, because they are behind less time from the bigger miners that more +often, on average, win; not 'on average' as in 'disproportionately', but when a +big miner wins, they immediately start mining on the next block, any miner +really, but a big miner will win more often and therefore, more often has the +advantage of not needing to wait for the next block. So, if this time is +longer, bigger miners benefit more than smaller miners. + +So, the idea is most nodes should have most transactions that are in blocks +already when the block is being announced, and that would make the block +propagation as fast as possible. Go ahead. + +**Sjors Provoost**: There's a chart on blockchain.com. I don't know if it's +still up to date. It basically looks at orphan blocks, stale blocks really, +over time, so the number of those per year. And you can see there was lots of +them in 2014 up to, I think, mid-2017, and after that, virtually none. My guess +is that they're not tracking all of them because definitely there are still +some, but it happened. + +**Mark Erhardt**: I think they stopped tracking. + +**Sjors Provoost**: Yeah it used to happen quite frequently and then it stopped +happening. And the main reason is that Bitcoin Core introduced these compact +blocks that you talked about, plus a few other optimizations. And then, if I +remember correctly, Greg Maxwell gave a talk about this, saying like, "We made +so many improvements in Bitcoin Core, but miners just didn't upgrade Bitcoin +Core. And then, for segwit, they finally did upgrade Bitcoin Core. And so, +that's why the orphan rate just dropped to the floor". So, this kind of now +looks like this made-up problem because we haven't had the problem for many +years, but we did have the problem. And mining centralization is already pretty +bad. We don't want to make it even worse by having this high orphan rate come +back, because everybody runs their own mempool. + +**Mark Erhardt**: Exactly. + +**Sjors Provoost**: It happened again, right, with full-RBF basically causing +these blocks to be inconsistent again, and that's kind of why Bitcoin Core had +to drop that option, basically make full-RBF the default. You don't want to +have multiple mempool policies living in the network, because it's disruptive. + +**Mark Erhardt**: Right. So, the blockchain.com chart I think is not +maintained, but you could look, for example, at fork.observer, which collects +similar data. Regarding the mempool policy, one of the other observations in +the context of this whole debate is that we have been recently seeing a lot more +non-standard transactions, where non-standard refers to transactions that are +not accepted to the mempool of most nodes. And so, there is of course MARA +Slipstream, but also I believe F2Pool has been mining non-standard transactions +when they receive them, and this has led to a situation where it is quite +possible to get a transaction with a larger OP_RETURN output into the +blockchain, but it won't reliably happen in the next block. So, let's say you +operate a ZK-Rollup and you have to get 140 bytes of data reliably into the next +block, you will not use OP_RETURN, because only a small portion of the entire +hashrate mines these transactions. But anyone that wants to, and can wait a +little bit, can easily get these transactions into the blockchain. + +Now, often the non-standard transactions pay a premium because they are +submitted out of band directly to miners, which leads us to another mining +centralization pressure, where the mining pools that have more manpower can put +in effort to offer a direct submission interface, can run multiple node +implementations, like Libre Relay, to receive these non-default transactions +that pay higher fees, and they will have, especially as the block subsidy tapers +off exponentially, they will eventually make more money from including these +transactions versus other mining pools that don't. So, this again would +probably benefit larger mining pools more than smaller mining pools, because +when people look who they give their non-standard transactions to get them +mined, they will look at the largest mining pools. They won't look up 20 +different mining pools and give it to the small mining pools that have maybe two +thirds of a percent of the hashrate. They'll just send it to the biggest three +and then see what happens, unless they relay on the open network, which makes +them available to everyone, which means that the fees that these transactions +pay are equally available to any block template producer. And it is much +preferable that all transactions are public information before they get mined, +so that anyone can jump in at any point in time and make a fair amount of +revenue, the same expected revenue as any other mining pool that already exists. + +**Sjors Provoost**: Yeah, sounds right. Just to add a little color there, if +you need to get it confirmed immediately, then sure, you'll send it to every +small miner out there. But if you have like a deadline of, I don't know, a day +because of some timeout mechanism, you'll just send it to the two biggest ones. +You're not going to send it to the smallest ones. + +**Mark Erhardt**: Yeah. And for statistics, I think there's been at least 20 +oversized OP_RETURN output transactions this week alone. And so, I think the +argument that a minority of nodes implementing this policy, or even a majority +of these nodes implementing the policy, has been shown not to completely forbid +it. And yeah, so many nodes implementing a policy that restricts these +transactions, and a subset of miners not including them, means an economic +disadvantage for those that don't include them and a less accurate picture of +the available fees that you're competing with when you're building your own +transactions. It would be preferable to have a homogenous mempool across the +network. + +**Sjors Provoost**: Another way to look at the mempool is that it is very good +at preventing censorship, as in even if 90% of all nodes were to censor +something, you're still going to get through that 10%. It's very nice. I think +somebody once gave a presentation, might have been in Prague, where basically +they did a game of whispers, where he would whisper a word to the people in the +first row, just one or two people, and then they would tell; half the people +should ignore it and the other half should pass it through, and then the back +row would still get the message intact, just to demonstrate what happens if only +50% of people are honest, but you can go to a lower percentage. But conversely, +if you want to censor something as a collective, that just doesn't work, again +because that 90% is unable to block things. So, being that 10% that does relay +things makes you really useful, because you help somebody evade the censorship. +But being the 90% that tries to block things is not that useful. + +**Mark Erhardt**: It's just not particularly effective, they just don't forward +the transaction. But nodes have up to 125 connections. So, if even 90% of them +don't forward it, among 125 connections, there'll be some 12 or so that do +accept and forward the transaction. + +**Sjors Provoost**: Yeah, and then there's something called preferential +peering, where somebody can just signal that they support this bigger +standardness, I think Libre Relay does that, so that if you're looking for peers +that will help you, you can actually find them. And unless you want to go in +the offensive and toss those nodes offline, you're not going to be able to +censor things. + +**Mark Erhardt**: Correct. So, there was one more aspect to this PR that +especially raised eyebrows, and that was, not only was the default for the +configuration changed to a higher limit, but the configuration option that +allows node operators to set their own limit was proposed to be removed. Also, +maybe to be clear, when something gets merged into the Bitcoin Core repository, +it'll only be released in the next release, which would be October at this +point. So, either way, we have some time to get through this debate, because +it's not going to be especially time-pressing whether it gets merged or not +before October. + +So, the removal of the configuration option that already existed especially had +some people upset, because they felt, "Well, but if I don't want these +transactions in my mempool, not only are you deciding for me that, by default, +my node should accept it, but now you're also taking away my option to remove or +to set a lower limit again". Do you have some color on that one? + +**Sjors Provoost**: Well, this is, I guess, more project philosophical. So, I +think even some contributors were not immediately happy about removing the +option. So, I can get that. I think that the argument for removing it is that, +and I think Greg Maxwell coined this term, it's a placebo. And putting a +placebo in a serious software project is, I don't think it's a good idea, and +arguably it's even not very nice to the users either. So, it depends on your +perspective, right? You can say, "Oh, it's good to have the option and I'm +happy now". But at the same time, if you're as a developer deceiving your users +into saying, "Here's a fake option, just use it, like these buttons at traffic +lights that don't do anything". Some actually do something, but that's also a +problem. So, you can argue back and forth there. I think we should not have +options that don't do anything. + +**Mark Erhardt**: Maybe we can clarify, that 'don't do anything'. + +**Sjors Provoost**: That thing that we just talked about, the censorship, it +keeps it out of the mempool. But that seems like a very strange thing to want, +because it's going to be on your computer. So, if you really, deeply care about +what is in your mempool.dat file or on your computer that doesn't seem real, +then you can say, "Well, I don't want my node to relay it", but you're going to +relay the block, so you're going to relay it, you're just not going to relay it +as part of a transaction. You know, you feel guilty about helping these +transactions propagate and you want to not do that somehow. + +**Mark Erhardt**: Right, well, so you'll download it twice. You'll download it +once when your peers propose it to you as an unconfirmed transaction. Your node +evaluates it, decides that it is to be classified as spam, drops it on the +floor. And then later, when the transaction does get included into the block +you download it again. You have the extra round trip after the block is +announced, but you get the data twice now for extra bandwidth, and then you +accept the block because it's consensus-valid and you forward the block +including the transaction anyway. Right. So, I think Greg might have called it +a placebo, but Pieter Wuille, in the mailing list, explained he thinks that +there shouldn't be a configuration option when you cannot give guidance on when +it should be used or make a recommendation for how to use it. And in this case, +I cannot make a good conscious recommendation to use this option at all. I +think it doesn't make sense, and therefore I first argued that we shouldn't have +the option. + +But meanwhile, I've been also talking to people for a whole week and I've +shifted my opinion. It feels like you're taking away an option that they +previously had, which disenfranchises people. If they insist that they want +this option, I would prefer that we only increase the limit and leave the +option, even though in my opinion, the option is not useful, potentially +slightly harmful to the node operators. + +**Sjors Provoost**: Right, that's the other thing, it's also harmful. It's not +just harmful to the node operator, because you're actually actively disrupting +the network by botching compact block relay. So, even if the option existed, it +would have to have this long disclaimer saying like, "Don't use this. Not only +are you not helping yourself, you're disrupting others, and it doesn't work". +It seems absurd to keep it around. I don't think that's a good direction to go +in. It also kind of reminds me of certain culture war things, like trigger +warnings, but it just seems wrong. And I think then the better approach is for +people to fork the project, just like Peter Todd did for his Libre Relay, just +like Luke did for Knots. It doesn't have to be Knots, it can be something much, +much simpler, where it's like, "Okay, for people who care about this issue for +whatever reason, just run this alternative client", because, yeah. It seems +like the route to go in, where this sort of thing can happen with other features +and we start spending more and more time on almost pure politics rather than +good code design. + +**Mark Erhardt**: The funniest thing about this is, if miners include these +transactions, only their block will have a disruption in the relay and get to +other miners more slowly. Therefore, only the people that do the behavior that +the filterers do not want to support, they support that the miners get a faster +head start, longer head start. + +**Sjors Provoost**: Well, in a sense, if a bigger miner is doing this, yeah, +you're essentially increasing the stale rate, which is to the advantage of the +bigger miner. + +**Mark Erhardt**: Exactly! + +**Sjors Provoost**: It's hard to explain in a README, so, yeah. + +**Mark Erhardt**: Right. I think I can at most sympathize with the argument +that reducing the friction will invite more people to use this option in future +designs or for more NFT bullshit. But yeah, that's the main argument that I can +relate to in this whole debate for the opponent side. Okay, the debate is still +ongoing. There has been a second PR opened, which keeps the option. + +**Sjors Provoost**: But deprecated. + +**Mark Erhardt**: And there's a lot of material out there now. Personally, I've +written an FAQ on Stacker News that I've linked in a few places already. So, if +you want to try to understand this situation completely, that might be a good +resource to understand, decide, or my personal opinions on it, but I think many +Bitcoin Core contributors lean similar ways. Anything else on this topic, +otherwise I think we might move on? + +**Sjors Provoost**: No, I mean, let's maybe not go into the whole meta +discussion, or maybe we should, but let's say you really don't like this change. +What do you do? Do you go on GitHub and just write really long comments; or do +you go on the mailing list and write really long comments; or do you, I don't +know? I don't think it's good to try and disrupt the whole process for this, I +mean in the sense that it slows things down. + +**Mark Erhardt**: But right. So, one of the things that happened early on was +that a lot of people started posting on the GitHub PR. GitHub doesn't scale +particularly well to conversations with hundreds of people because it's a single +thread. There's not really much in the flow of the conversation, such as, for +example, on Reddit or Stacker News, where it just splits up and people have a +specific post that they answer to, which allows many different conversations to +happen in parallel. So, GitHub got a little overwhelmed. Then the moderators +of the Bitcoin Core repository started hiding duplicate and repetitive, or +comments that didn't provide new arguments, which then of course led to people +feeling that they were being disenfranchised, because they couldn't weigh into +this topic that felt very important to them. And so, there's a whole other +dimension to how people feel that things should work about whether or not the +Bitcoin Core repository is the right place to have this sort of protest, or +whether that's a conversation that should happen in other places. And maybe, +obviously, you can have as much discussion about this on social media as you +want. The mailing list is already moderated too, but tends to let conversation +branch fine. But the GitHub repository tends to not really scale to this sort +of conversation, and it is usually the spot where people are focused on code +review. They'd rather not engage with a culture war in the Bitcoin Core GitHub +repository. + +So, I anticipate that if this happens again, it'll have a similar outcome, where +moderators will try to make the conversation more readable and limit, to some +extent, the excess unwanted comments. + +**Sjors Provoost**: It makes it hard to work. + +**Mark Erhardt**: Right, yeah, who's done any work in the last week?! + +**Sjors Provoost**: Well, people, the goal is to write code, and so the comment +should be focused on that code. Now, if you're really opposed to a change, +especially I think the main contributors should be able to let that known. But +I don't think that needs to be done in tenfold, first of all. + +**Mark Erhardt**: Or hundredfold, yeah. + +**Sjors Provoost**: Then secondly, I think even the PR at the top said, "Hey, +there was this discussion on the mailing list that talks about this topic in +general". So, I think the good thing to do there is to go to the mailing list. +But then, even there, I don't think the goal there should be to say, "Hey, I +disagree with something, I'm just going to post now on this mailing list", +without doing some work. And this gets to the question of what is the target +audience of these media? So, I think social media, like Twitter, the target +audience is everyone and everybody can have an opinion about everything. And +the way that that is managed is that you follow people or you don't follow +people, based on their signal-to-noise ratio as you perceive it. But these +mailing lists are broadcast to everyone and same with GitHub. So, we can't +follow people on a mailing list. You can only actively mute them if they're +really annoying, but it doesn't really work that way. + +So, on the mailing list, I think the target audience of the Bitcoin-Dev mailing +list is mostly developers who are working on Bitcoin-related stuff. So, not +just Bitcoin Core, but Bitcoin in general. They're working on wallets, they're +working on exchanges. These are fairly technical people, and so when a post is +put on the mailing list, it's not meant for the general public. So, that's +maybe why people felt like a little bypass, like this quick mailing post by +Antoine, was aimed at an audience that is assumed to kind of know what this is +all about and knows how to find things in the archive. And so, there's a +missing link there in communicating these changes to the general public. I +think Optech is trying to help with that. But if Optec is not the first one to +communicate it, but yet the people who don't like it, then they just basically +bypass that part. + +So, even saying to people, "Go to the mailing list", is not really complete +either, because I don't think everybody should just be writing long stories on +the mailing list either, unless they thoroughly understand this at a technical +level. And this is one of those bike-shedding situations, and not even in the +negative sense, it's one of those topics where people feel they understand it +because it sounds simple. It's just spam, it's just opportune, but there's ten +years of history and there's nuance, etc. So, the mailing list really isn't the +right place to have a normal debate either. It's not a debate for everyone on +the mailing list. So, does that mean then the normal debate should happen on +Twitter? That's kind of mean either. It's like, "Okay, we have this really +nice, exclusive venue for our super-sophisticated discussions, and if you don't +qualify for that venue, you must go to this sewage basically. + +There's probably room for more sophisticated debate. I would say the Bitcoin +Socratic Seminars are a good venue for that, where it's a little lower. I think +the bar for asking a question at a Socratic Seminar is much lower than on the +mailing list. That's I think how you should look at it. And maybe there needs +to be something in between that. But I would say, and especially because the +timeline isn't this urgent, right, we make a release once every six months; so, +I would say next time you see something on GitHub or your favorite social media +influencer talks about it, your first response should not be to comment on it. +It ideally should be to find your local Bitcoin Socratic Seminar, go there, ask +some questions, and then if you still think after asking some questions, "Hey, +this is stupid and bad", well, then it's probably a time to start speaking out +on social media. + +**Mark Erhardt**: I think that's good advice. Maybe also, I want to hook into +saying that it is a technical audience that is discussing. A lot of people have +left comments such as, "NACK", or, "I'm against this", which really doesn't +contain much argument to convince the people that are trying to come to a +conclusion for a design debate or an approach debate. Really, what is needed to +participate in this conversation is to make an argument why something is a good +change or a bad change. This argument could be rooted in culture, but it has to +be presented to the technical process, and has to convince the other +participants of the process. Just saying, "I'm against it" or not won't help +because it's not a vote. It's about trying to find a good solution. + +**Sjors Provoost**: Yeah, and I would say there were some actually useful +arguments, even on the GitHub thread, right? There was one about the issue of +contiguous data versus data with gaps in it that I thought was actually +interesting, and I almost missed it because it was buried between a million +other comments. So, if your goal is to stop something because you think it's a +bad idea, like I said, try to go through these steps. But you also don't want +people to go on there and put too much stuff on these topics, because the thing +I just advised was like, be that guy that goes to the meetup first, tries to +understand something thoroughly, and then comments. And I don't pretend to +always do that by the way, but that would be ideal. But that doesn't stop other +people from doing it. And so, you're still kind of watching this unfold. So, +then maybe the question is, what can you do about that? I don't know. But +ideally, you also want to do something about that phenomenon. If you see an +influencer link directly to GitHub and saying something like, "Go comment on +this PR", you probably want to call that influencer out for doing that, because +they're definitely disrupting the process. And even if you agree with the +influencer in question that this particular feature is bad, this is not the +right way to do it. + +**Mark Erhardt**: Yeah, you have to understand a little bit the scale of the +number of people that are involved here. If you look at, for example, on +Twitter, the biggest Bitcoin Twitter participants have on the scale of hundreds +of thousands of followers, whereas there's about probably 40 people that +full-time contribute to Bitcoin Core or part-time contribute to Bitcoin Core. + +**Sjors Provoost**: Which is a problem, right, time that they can't write code. + +**Mark Erhardt**: Right. Whenever you come to the GitHub repository and add +comments there, you can anticipate that this comment will be read by probably at +least a dozen of us. And so, please make it worth it to get the eyeballs of 12 +developers for a minute or two when you write something. Make the arguments +well-thought-out, and read up a little bit on what the state of the discussion +is before you weigh in. All right. I think we might have covered this pretty +extensively. + +**Sjors Provoost**: Listening to our preachings. + +_LND 0.19.0-beta.rc3_ + +**Mark Erhardt**: Yeah. All right. I think we'll wrap this topic at this +point. I know it was a pretty long news item, but I hope it was interesting to +you. We're getting to the next section, which is Releases and release +candidates. As the last few weeks already, we still have LND 0.19.0-beta.rc3 +and we had already covered that in more detail in Newsletter #349. So, if you +want to listen to our description of what is in this upcoming LND release, +please check out that episode. And as always, if you depend on running LND in +your infrastructure, please test the RCs, so that issues are found before people +are starting to use it, rather than after. + +_Bitcoin Core #31250_ + +Going on to the Notable code and documentation changes section, we have four of +those this week. The first one is Bitcoin Core #31250 and this one's an +exciting one. It is about disabling creation and loading of legacy wallet. I +think we've talked about the legacy wallet and the new wallet, which is the +descriptor wallet, and 'new' might be a bit of a stretch because they have been +default in Bitcoin Core since 2021. The old one, the legacy wallet, is based on +a database format called Berkeley DB. Berkeley DB has been unmaintained for ten +years or so, roughly. So, we really, really wanted to get off that, and that's +what led to the descriptor wallets that are using an SQLite database under the +hood actually. So, Berkeley DB wallets can no longer be created. They can also +not be loaded into Bitcoin Core starting with the next release. Instead, what +would happen is you would have to use the migration tool that converts your +Berkeley DB legacy wallet into a descriptor wallet. + +**Sjors Provoost**: This is not as scary as it sounds like. Bitcoin Core +wallet, if you use the GUI, there's a menu. I think it says, "Wallet migrate". + +**Mark Erhardt**: Well, the expectation should be that it just works. The +migration tool has been released for several years already and has been +extensively tested. The idea is Bitcoin Core is the forever wallet. You will +always be able to load any wallet that was created by any older version of +Bitcoin Core. And in this case, Bitcoin Core contributors wrote a read-only +version of Berkeley DB. They implemented their own Berkeley DB reader with only +the functionality that Bitcoin Core uses. And this tiny little library will +stay in Bitcoin Core so that legacy wallets will be able to be imported forever. +But starting with the next release, 30.0, you will need to migrate your wallet +to descriptors, if you haven't done so yet. Overall, this code change removes +5,600 lines of code, which is quite cool. And, yeah, if you want to read up on +the start of the migration tool, we mentioned that in Newsletter #172, so quite +some time ago. + +**Sjors Provoost**: Yeah, and then the next PR removes Berkeley DB itself and a +few leftovers, so you can't load them anymore, but there's still some +functionality hidden in the code that will go away. Just another couple of +thousand lines probably. + +**Mark Erhardt**: I think overall, it was something like 12,000 lines of code, +which in the context of the whole codebase is, I think, about 6%, 7%, because +it's around 180,000 lines of code, I think. + +**Sjors Provoost**: Yeah, but as a percentage of code that people don't +understand, it's pretty significant. Because the legacy world is one of those +things where nobody really knows how it works. So, even building a well-tested +migration tool is a huge challenge, because there was all these edge cases and +all these weird behaviors. + +_Eclair #3064_ + +**Mark Erhardt**: Right, exactly. Okay, our second PR is Eclair #3064. This +one is a refactor about channel key management. And the background here is that +the plan of Eclair was originally to use HSMs (Hardware Security Modules) and +external signers to do the signing. But over time, they changed their approach +and are now putting their entire node into a secure enclave. So, where the key +generation and key management was distributed into many different spots of the +codebase in order to allow signatures to be produced by external signers, that +is no longer necessary. And this refactor introduces a new class, called +ChannelKeys, which introduces type safety for the different types of keys, puts +all of the logic together in one spot, and that makes it easier for people to +not mix up different key types and so forth. So, it's just a big cleanup that +makes key management safer and easier to understand in Eclair. All right, +Sjors, you're not big on Eclair PRs, is that so? + +**Sjors Provoost**: I really liked Phoenix. That's the same company, but not +the same codebase. + +_BTCPay Server #6684_ + +**Mark Erhardt**: Right. Okay, third one and second last, BTCPay Server #6684 +adds support for a subset of BIP388 wallet policy descriptors. So, BIP388 only +got merged a few months ago, and describes a language that is very similar to +descriptors, that is specifically aimed to work with the limitations of hardware +signers that have very little computational power and memory. And so, BTCPay +Server here implements part of BIP388, and that allows users to import or export +single-sig and k-of-n policies, which should make it easier to use BTCPay Server +in a multisig setup. And especially, it looks like they had compatibility with +Sparrow in mind. The policies that are supported are P2PKH, P2WPKH, +P2SH-P2WPKH, and P2TR, with the corresponding multisig variants, except for +P2TR. Any other thoughts on that one? + +**Sjors Provoost**: I was going to say, I'd like to see MuSig support, but +really Bitcoin Core needs to add MuSig support and I need to review the code +that, does that so I shouldn't be complaining. + +**Mark Erhardt**: Yeah, it's been coming for a long, long time, but there's a PR +open in Bitcoin Core that implements it. + +**Sjors Provoost**: And Ledger implemented it on their device, so that means you +can actually test it against a completely independent implementation, which is +nice. It's still very, very tedious to set up such a MuSig wallet using just +RPCs. It's mind-boggling, but at least it would be nice if it actually worked, +and then we can figure out how to make it usable. + +**Mark Erhardt**: Yeah, there's been a bunch of progress in various avenues. +There's been PSBT fields added for MuSig2; there's been a description of, or a +proposal, a BIP that describes how MuSig would be used to generate wallets and +derivation paths for MuSig; and, yeah, there's an open PR to implement MuSig +support in Bitcoin Core that needs to be reviewed and then, hopefully, Bitcoin +Core will have MuSig2 support. + +_BIPs #1555_ + +Final PR that we're going to cover today is BIPs #1555. This BIP PR merges +BIP321. Now, you might wonder what is BIP321? + +**Mark Erhardt**: No, dude, I merged that just last week! And so, this has been +discussed for quite some time. The PR has been open since, or the number was +assigned in November, and it got just merged last week. So, BIP321 is an update +and extension of BIP21. BIP21 deals with the URI schemes, like when you scan a +QR code in order to make a Bitcoin payment and get the payment information, +these sorts of things had been regulated in BIP21 before that. BIP21 had been a +super-old BIP from 2012, so it turned out that a bunch of people had been using +BIP21 a little different than it had been originally specified. For example, +they just added some fields for LN into it that hadn't been described in 2012. +So, 321 on the one hand just gives an overview of how URIs are being used in the +context of Bitcoin by most wallets, provides a description of standards, and +then also describes a forward-looking approach on how new address types might be +added to the scheme. There's also now a way of providing proof of payment to +the sender. And yeah, so same author too, Matt Corallo, wrote BIP321 and also +contributed to BIP21. And, yeah, so far it's still a draft, but if you work on +a wallet that has BIP21 support, you might want to look into updating to BIP321 +support at some point. + +Well, thank you very much for joining me today, Sjors, and thank you very much +to our listeners for taking the time. Bye-bye. {% include references.md %} From 98e32c09556d47cd2f4ccf1b58a84c3a31d0c516 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Tue, 20 May 2025 16:17:48 -1000 Subject: [PATCH 022/278] Newsletters: add 355 (2025-05-23) --- .../en/newsletters/2025-05-23-newsletter.md | 72 +++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 _posts/en/newsletters/2025-05-23-newsletter.md diff --git a/_posts/en/newsletters/2025-05-23-newsletter.md b/_posts/en/newsletters/2025-05-23-newsletter.md new file mode 100644 index 0000000000..d98beb52b6 --- /dev/null +++ b/_posts/en/newsletters/2025-05-23-newsletter.md @@ -0,0 +1,72 @@ +--- +title: 'Bitcoin Optech Newsletter #355' +permalink: /en/newsletters/2025/05/23/ +name: 2025-05-23-newsletter +slug: 2025-05-23-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter includes our regular sections describing changes +to services and client software, announcing new releases and release +candidates, and summarizing recent changes to popular Bitcoin +infrastructure software. + +## News + +*No significant news this week was found in any of our [sources][].* + +## Changes to services and client software + +*In this monthly feature, we highlight interesting updates to Bitcoin +wallets and services.* + +FIXME:bitschmidty + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [LND 0.19.0-beta][] is the latest major release of this popular LN + node. Its contains many [improvements][lnd rn] and bug fixes, + including new RBF-based fee bumping for cooperative closes. + +- [Core Lightning 25.05rc1][] is a release candidate for the next major + version of this popular LN node implementation. + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [Bitcoin Core #32423][] rpc: Undeprecate rpcuser/rpcpassword, store all credentials hashed in memory + +- [Bitcoin Core #31444][] cluster mempool: add txgraph diagrams/mining/eviction + +- [Core Lightning #8140][] peer storage enable + +- [Core Lightning #8136][] channel gossip rework + +- [Core Lightning #8266][] reckless: add update command + +- [Core Lightning #8021][] interop with eclair + +- [Core Lightning #8226][] signmessage (please mention bip137 -harding) + +- [LND #9801][] peer+lnd: add new CLI option to control if we D/C on slow pongs + +{% include snippets/recap-ad.md when="2025-05-27 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32423,31444,8140,8136,8266,8021,8226,9801" %} +[lnd 0.19.0-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta +[sources]: /en/internal/sources/ +[lnd rn]: https://github.com/lightningnetwork/lnd/blob/master/docs/release-notes/release-notes-0.19.0.md +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 From d17ee3596fb18f2ae98ecad6e1748d8acb9c49a6 Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 22 May 2025 06:42:02 +0000 Subject: [PATCH 023/278] News355: add merge summaries --- .../en/newsletters/2025-05-23-newsletter.md | 83 +++++++++++++++---- 1 file changed, 67 insertions(+), 16 deletions(-) diff --git a/_posts/en/newsletters/2025-05-23-newsletter.md b/_posts/en/newsletters/2025-05-23-newsletter.md index d98beb52b6..c9a356418f 100644 --- a/_posts/en/newsletters/2025-05-23-newsletter.md +++ b/_posts/en/newsletters/2025-05-23-newsletter.md @@ -47,26 +47,77 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Bitcoin Core #32423][] rpc: Undeprecate rpcuser/rpcpassword, store all credentials hashed in memory - -- [Bitcoin Core #31444][] cluster mempool: add txgraph diagrams/mining/eviction - -- [Core Lightning #8140][] peer storage enable - -- [Core Lightning #8136][] channel gossip rework - -- [Core Lightning #8266][] reckless: add update command - -- [Core Lightning #8021][] interop with eclair - -- [Core Lightning #8226][] signmessage (please mention bip137 -harding) - -- [LND #9801][] peer+lnd: add new CLI option to control if we D/C on slow pongs +- [Bitcoin Core #32423][] removes the deprecation notice for + `rpcuser/rpcpassword` and replaces it with a security warning about storing + cleartext credentials in the configuration file. This option was originally + deprecated when `rpcauth` was introduced in [Bitcoin Core #7044][], which + supports multiple RPC users and hashes its cookie. The PR also adds a random + 16-byte salt to credentials from both methods and hashes them before they’re + stored in memory. + +- [Bitcoin Core #31444][] extends the `TxGraph` class (see Newsletter + [#348][news348 txgraph]) with three new helper functions: + `GetMainStagingDiagrams()` returns the divergences of clusters between the + main and staged feerate diagrams, `GetBlockBuilder()` iterates through graph + chunks (sub-cluster feerate-sorted groupings) from highest to lowest feerate + for optimized block construction, and `GetWorstMainChunk()` pinpoints the + lowest feerate chunk for eviction decisions. This PR is one of the final + building blocks of the full initial implementation of the [cluster mempool][topic + cluster mempool] project. + +- [Core Lightning #8140][] enables [peer storage][topic peer storage] of channel + backups by default (see Newsletter [#238][news238 storage]), making it viable + for large nodes by limiting storage to peers with current or past channels, + caching backups and peer lists in memory instead of making repeated + `listdatastore`/`listpeerchannels` calls, capping concurrent backup uploads at + two peers, skipping backups larger than 65 kB, and randomizing peer selection when + sending. + +- [Core Lightning #8136][] updates the exchange of announcement signatures to + occur when the channel is ready rather than after six blocks, to align with + the recent [BOLTs #1215][] specification update. It's still required to wait + six blocks to [announce the channel][topic channel announcements]. + +- [Core Lightning #8266][] adds an `update` command to the Reckless plugin + manager (see Newsletter [#226][news226 reckless]) that updates a specified + plugin or all installed plugins if none is specified, except those installed + from a fixed Git tag or commit. This PR also extends the `install` command to + take a source path or URL in addition to a plugin name. + +- [Core Lightning #8021][] finalizes [splicing][topic splicing] interoperability + with Eclair (see Newsletter [#331][news331 interop]) by fixing the rotation of + remote funding keys, resending `splice_locked` on channel re-establishment to + cover cases where it was originally missed (see Newsletter [#345][news345 + splicing]), relaxing the requirement that commitment-signed messages arrive in + a particular order, enabling receiving and initiating splice [RBF][topic rbf] + transactions, automatically converting outgoing [PSBTs][topic psbt] to version + 2 when needed, and other refactoring changes. + +- [Core Lightning #8226][] implements [BIP137][] by adding a new + `signmessagewithkey` RPC command that allows users to sign messages with any + key from the wallet by specifying a Bitcoin address. Previously, signing a + message with a Core Lightning key required finding the xpriv and the key + index, deriving the private key with an external library, and then signing the + message with Bitcoin Core. + +- [LND #9801][] adds a new `--no-disconnect-on-pong-failure` option, which + controls whether a peer is disconnected if a pong response is late or + mismatched. This option is set to false by default, preserving the current + behavior of LND disconnecting from a peer on a pong message failure (see + Newsletter [#275][news275 ping]); otherwise, LND would only log the event. The + PR refactors the ping watchdog to continue its loop when disconnection is + suppressed. {% include snippets/recap-ad.md when="2025-05-27 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="32423,31444,8140,8136,8266,8021,8226,9801" %} +{% include linkers/issues.md v=2 issues="32423,31444,8140,8136,8266,8021,8226,9801,7044,1215" %} [lnd 0.19.0-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta [sources]: /en/internal/sources/ [lnd rn]: https://github.com/lightningnetwork/lnd/blob/master/docs/release-notes/release-notes-0.19.0.md [Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[news348 txgraph]: /en/newsletters/2025/04/04/#bitcoin-core-31363 +[news238 storage]: /en/newsletters/2023/02/15/#core-lightning-5361 +[news226 reckless]: /en/newsletters/2022/11/16/#core-lightning-5647 +[news331 interop]: /en/newsletters/2024/11/29/#core-lightning-7719 +[news345 splicing]: /en/newsletters/2025/03/14/#eclair-3007 +[news275 ping]: /en/newsletters/2023/11/01/#lnd-7828 From a8dd02c6bfe25aa066ae792a02dc8741b3780708 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Fri, 23 May 2025 06:04:58 -0500 Subject: [PATCH 024/278] News355: add client services --- .../en/newsletters/2025-05-23-newsletter.md | 51 ++++++++++++++++++- 1 file changed, 50 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2025-05-23-newsletter.md b/_posts/en/newsletters/2025-05-23-newsletter.md index c9a356418f..9e119ea5b5 100644 --- a/_posts/en/newsletters/2025-05-23-newsletter.md +++ b/_posts/en/newsletters/2025-05-23-newsletter.md @@ -21,7 +21,41 @@ infrastructure software. *In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.* -FIXME:bitschmidty +- **Cake Wallet added payjoin v2 support:** + Cake Wallet [v4.28.0][cake wallet 4.28.0] adds [the ability][cake blog] to + receive payments using the [payjoin][topic payjoin] v2 protocol. + +- **Sparrow adds pay-to-anchor features:** + Sparrow [2.2.0][sparrow 2.2.0] displays and can send [pay-to-anchor + (P2A)][topic ephemeral anchors] outputs. + +- **Safe Wallet 1.3.0 released:** + [Safe Wallet][safe wallet github] is a desktop multisig wallet with hardware + signing device support that added [CPFP][topic cpfp] fee bumping for incoming + transactions in [1.3.0][safe wallet 1.3.0]. + +- **COLDCARD Q v1.3.2 released:** + COLDCARD Q's [v1.3.2 release][coldcard blog] includes additional multisig + [spending policy support][coldcard ccc] and new features for [sharing + sensitive data][coldcard kt]. + +- **Transaction batching using payjoin:** + [Private Pond][private pond post] is an [experimental implementation][private + pond github] of a [transaction batching][topic payment batching] service that + uses payjoin to generate smaller transactions that pay less in fees. + +- **JoinMarket Fidelity Bond Simulator:** + The [JoinMarket Fidelity Bond Simulator][jmfbs github] provides tools for + JoinMarket participants to simulate their performance in the market based on + [fidelity bonds][news161 fb]. + +- **Bitcoin opcodes documented:** + The [Opcode Explained][opcode explained website] website documents + each Bitcoin script opcode. + +- **Bitkey code open sourced:** + The Bitkey hardware signing device [announced][bitkey blog] their [source + code][bitkey github] is open-source for non-commercial uses. ## Releases and release candidates @@ -121,3 +155,18 @@ repo], and [BINANAs][binana repo]._ [news331 interop]: /en/newsletters/2024/11/29/#core-lightning-7719 [news345 splicing]: /en/newsletters/2025/03/14/#eclair-3007 [news275 ping]: /en/newsletters/2023/11/01/#lnd-7828 +[cake wallet 4.28.0]: https://github.com/cake-tech/cake_wallet/releases/tag/v4.28.0 +[cake blog]: https://blog.cakewallet.com/bitcoin-privacy-takes-a-leap-forward-cake-wallet-introduces-payjoin-v2/ +[sparrow 2.2.0]: https://github.com/sparrowwallet/sparrow/releases/tag/2.2.0 +[safe wallet github]: https://github.com/andreasgriffin/bitcoin-safe +[safe wallet 1.3.0]: https://github.com/andreasgriffin/bitcoin-safe/releases/tag/1.3.0 +[coldcard blog]: https://blog.coinkite.com/ccc-and-keyteleport/ +[coldcard ccc]: https://coldcard.com/docs/coldcard-cosigning/ +[coldcard kt]: https://github.com/Coldcard/firmware/blob/master/docs/key-teleport.md +[private pond post]: https://njump.me/naddr1qvzqqqr4gupzqg42s9gsae3lu2cketskuzfp778fh2vg9c5x3elx8ttdpzhfkk25qq2nv5nzddgxxdjtd4u9vwrdv939vmnswfzk6j85dxk +[private pond github]: https://github.com/Kukks/PrivatePond +[jmfbs github]: https://github.com/m0wer/joinmarket-fidelity-bond-simulator +[news161 fb]: /en/newsletters/2021/08/11/#implementation-of-fidelity-bonds +[opcode explained website]: https://opcodeexplained.com/ +[bitkey blog]: https://x.com/BEN0WHERE/status/1918073429791785086 +[bitkey github]: https://github.com/proto-at-block/bitkey From 76e1dc2e23e7e21393ab4956d99af3cb041f6a93 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Fri, 23 May 2025 06:06:44 -0500 Subject: [PATCH 025/278] News355: add topics --- _topics/en/payjoin.md | 3 +++ _topics/en/peer-storage.md | 3 +++ _topics/en/splicing.md | 3 +++ 3 files changed, 9 insertions(+) diff --git a/_topics/en/payjoin.md b/_topics/en/payjoin.md index 7c45a7231c..41563eadf0 100644 --- a/_topics/en/payjoin.md +++ b/_topics/en/payjoin.md @@ -110,6 +110,9 @@ optech_mentions: - title: "Rust-payjoin 0.21.0 release adds transaction cut-through capabilities" url: /en/newsletters/2025/01/24/#rust-payjoin-0-21-0-released + - title: "Cake Wallet adds payjoin v2 support" + url: /en/newsletters/2025/05/23/#cake-wallet-added-payjoin-v2-support + ## Optional. Same format as "primary_sources" above see_also: - title: BIP79 diff --git a/_topics/en/peer-storage.md b/_topics/en/peer-storage.md index 00a500db99..331db97335 100644 --- a/_topics/en/peer-storage.md +++ b/_topics/en/peer-storage.md @@ -42,6 +42,9 @@ optech_mentions: - title: "LDK #3575 implements the peer storage protocol" url: /en/newsletters/2025/02/21/#ldk-3575 + - title: "Core Lightning #8140 enables peer storage of channel backups by default" + url: /en/newsletters/2025/05/23/#core-lightning-8140 + ## Optional. Same format as "primary_sources" above # see_also: # - title: diff --git a/_topics/en/splicing.md b/_topics/en/splicing.md index 49bd656240..78f8e8900f 100644 --- a/_topics/en/splicing.md +++ b/_topics/en/splicing.md @@ -98,6 +98,9 @@ optech_mentions: - title: "LDK #3624 enables funding key rotation after successful channel splices" url: /en/newsletters/2025/03/14/#ldk-3624 + - title: "Core Lightning #8021 finalizes splicing interoperability with Eclair" + url: /en/newsletters/2025/05/23/#core-lightning-8021 + ## Optional. Same format as "primary_sources" above see_also: - title: Interactive transaction construction protocol From 92a4a0542ffa58319f519c7ae21537e36f57d234 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 22 May 2025 15:43:23 -0500 Subject: [PATCH 026/278] Podcast: add 353 transcription --- .../en/podcast/2025-05-13-newsletter-recap.md | 848 +++++++++++++++++- 1 file changed, 847 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-05-13-newsletter-recap.md b/_posts/en/podcast/2025-05-13-newsletter-recap.md index 774d334d1b..1269735030 100644 --- a/_posts/en/podcast/2025-05-13-newsletter-recap.md +++ b/_posts/en/podcast/2025-05-13-newsletter-recap.md @@ -19,6 +19,852 @@ Ingala, and Stéphan Vuylsteke to discuss [Newsletter #353]({{page.reference}}). ## Transcription -_transcription coming soon_ +**Mike Schmidt**: Welcome to Bitcoin Optech Newsletter #353 Recap. Today, we're +going to be talking about BIP30 and a potential consensus failure vulnerability; +we're going to talk about avoiding BIP32 path reuse; we have a Bitcoin Core PR +Review Club around Bitcoin Core's multiprocess project; and we have our regular +Releases and Notable code segments as well. I'm Mike Schmidt, contributor at +Optech and Executive Director at Brink. Murch? + +**Mark Erhardt**: Hi, I'm Murch, I work at Localhost. + +**Mike Schmidt**: Ruben? + +**Ruben Somsen**: Hi, I'm Ruben, I'm co-directing 2140. + +**Mike Schmidt**: Salvatore? + +**Salvatore Ingala**: Hi, I work at Ledger on Bitcoin stuff. + +**Mike Schmidt**: Stefan? + +**Stéphan Vuylsteke**: Hey, I'm stickies. I work on Bitcoin Core at Brink. + +_BIP30 consensus failure vulnerability_ + +**Mike Schmidt**: Well, thank you all for joining us for the newsletter this +week. We have a few interesting topics that we'll kick off here with, "BIP30 +consensus failure vulnerability", from the News section. In Newsletter #346, we +covered the PR to Bitcoin Core that merged the removal of checkpoints in the +code. We also had on Marco in Podcast #346, where he discussed the PR and the +background around checkpoints. This week, we're covering, Ruben, your +Bitcoin-Dev mailing list post, where you noticed that while splunking through +old blocks as part of your SwiftSync work, that BIP30 had an unresolved +consensus bug. Can you walk us through a little bit about what's going on here? + +**Ruben Somsen**: Yeah, sure. So, this is related to the checkpoints, because +the checkpoints sort of allow us to go back and reorg back to a point where this +bug becomes possible. But I think to explain the bug, I would need to explain +what BIP30 is in the first place. And with BIP30, essentially, before we had +BIP30, there was a duplicate coinbase output bug, where someone could create a +coinbase transaction, a miner, if they create a block, and then in another +block, they could create the exact same coinbase transaction and that would +create a duplicate transaction ID, because the transaction would be exactly the +same. And because of this, actually, there have been two instances of duplicate +outputs on the Bitcoin blockchain today. And BIP30 sought to somewhat resolve +that in a way that wasn't complete nor very neat. But it did so by basically, +whenever you create an output, it would say like, "Okay, well, let's check the +UTXO set, let's see if that output already exists. And if it already exists, +then it's not valid". And so, that was how BIP30 tackled this problem. + +BIP30 was activated retroactively. So, it validates all the way from genesis, +even though it didn't get implemented until 2012. And the two duplicate outputs +that we have today, they are basically marked as exceptions. So, that's the +only case where BIP30 says like, "Okay, fine, we know that these exist, so we'll +let them through, but everything else is not allowed". And BIP30 only is active +until in 2013, BIP34 activates, and there is a little caveat that BIP34 actually +has to activate for BIP30 to deactivate. And BIP34 basically says, "Hey, +instead of checking whether every output is unique, let's make sure every output +is unique by enforcing that every coinbase transaction needs to have the block +height in it", which ensures that since every block height only occurs once, +this theoretically assures that now every coinbase output is unique, and +subsequently every other output that might spend from it. So, this actually +isn't a complete fix, and that's why we had the consensus cleanup, but that's a +different story and is not really relevant for this, but I'm just pointing out +BIP34 is not perfect either, but for what we're talking about here, it doesn't +really matter. + +So, the specific bug is related to the duplicate outputs that are in the Bitcoin +blockchain. And essentially, what happens is, I'll just give a theoretical +example with easier block heights. Let's say a block height 100 of coinbase +outputs is being mined. Then at block 200, the exact same coinbase transaction, +the exact same output is being mined again. The way Bitcoin Core handled this +in the past and handles it today is that the first output gets overwritten with +the second output. And so, there should have been, in theory, two outputs, but +in practice, there is only one output in the UTXO set and this can only get +spent once. So, so far, this is actually kind of okay in the sense that it's +not ideal, the miner lost some money, but arguably it was their own fault for +creating the same coinbase outputs. Were it not for the fact that in the case +of a reorg -- so, let's say at block 200, this duplicate output was mined. Now +let's say there's a reorg back to, let's say, block 100. Well in a reorg, every +output that got created gets uncreated. And so, first the output got +overwritten, and now the output that got overwritten gets removed, and so we end +up with zero outputs in the UTXO sets. Whereas someone who just validated from +genesis until block 100 will have one output in the UTXO sets. + +So, there is a consensus discrepancy and if that output then gets spent, which +is also kind of possible, but it's an old output, so it may or may not happen. +But if it's also gets spent, then some part of the network that didn't put this +to reorg, they will say like, "Well, what's this? I don't know this output, so +that's an invalid block", whereas those who did not witness the reorg, they will +see it and they'll be like, "Sure, yeah, that's fine, the output is getting +spent". And so, that's the consensus bug. So, as luck may have it, or +depending on how you look at it, this is 2010. So, in 2010, these duplicates +happened. So, we need a reorg back to 2010 for this to actually occur; and for +this reason, it's sort of theoretical, right, because in practice this is not +going to happen. But it is kind of ugly, and it's not nice. And the other +thing is that we've had checkpoints thus far, but with the removal of the +checkpoints, this is actually when the bug sort of comes into play. + +So, one of the things we could do to fix it is we can say, well, considering +we're removing the checkpoints, we could also take that as an opportunity to fix +it right now, because removing the checkpoints is theoretically a hard fork. In +practice, it's not going to matter, but in theory, adding a checkpoint is a soft +fork, removing a soft fork is a hard fork. So, that would be one way to fix it. +And the other way to fix it, which we could opt to do later, let's say we go +ahead and the checkpoints get removed, what we could do is we could say, well, +let's not allow a reorg unless the reorg reorgs out both the transactions. So, +the first at the theoretical block 100, and the second one at block 200. So, +you say, okay, well, if you're gonna reorg back past the point of block 200, you +have to reorg back all the way to block 99. And only if you do that, then every +node will be in agreement, because now both a new node that has spun up freshly +on the network, plus someone who witnessed the reorg, both of them, they will +say like, "Okay, well, there's zero of these outputs". So, that's sort of the +alternative way of fixing it. + +**Mark Erhardt**: I caught a mistake. If they both reorg back to 99 and then +apply block 100, they both have one UTXO. + +**Ruben Somsen**: Yes. So, the consensus rule would be either you have block +100 to 200 in your consensus, or 100 to 200 is not part of the chain, so that +should solve it. So then, you cannot mine block 100. 201 is fine, but the same +block 100 cannot be mined again. + +**Mark Erhardt**: Well, it could be. You just have to reorg back past 99 and +then you could apply 100 to 150 again, and then you'd still have a synchronous +network again. You just have to go back far enough to reprocess block 100. +Isn't that what you're saying? + +**Ruben Somsen**: Yeah, but it has to be a different block 100. So, we have the +canonical chain today; do you disagree, Murch? + +**Mark Erhardt**: Yes. + +**Ruben Somsen**: Okay, well, would you want to work it out? + +**Mark Erhardt**: Yeah, sure. So, we said in block 100 and block 200, the same +transaction gets created twice with the same outputs. The problem here is, of +course, that creating the same output a second time before the first one is +spent leads to only UTXO in the UTXO set. So, if we reorg out the UTXO, we are +in trouble. And the problem is now actually twofold, I think. First, when you +go past block 200 on the way down, you reorg out the existing UTXO, and there +are zero UTXOs left. But that only applies to nodes that were past block 200 +already, and not to nodes that resync from scratch, that come from the genesis +block, because they would create the UTXO at 100 already. So, you could fix it +two ways. One way is, if you reorg below 200, you have to reorg below 100 and +reapply back up to the point that you reorg to. So, if you reorg to 199, you +would have to reprocess from 100 to 199, and then everybody would be in the same +boat. The people that come from the genesis block as well as the reorging +parties have recreated the block at 100. + +I think there's a different problem here though. When you reorg past the first +creation of the UTXO, your node will probably crash, because it's trying to +remove a UTXO that doesn't exist. + +**Ruben Somsen**: Yeah, that's not the case, that's handled as an exception. + +**Mark Erhardt**: Oh, cool, okay. + +**Ruben Somsen**: But that's a good observation. So, I think this doesn't work. +Like, you're right that you're fixing the problem, but you're fixing the problem +in a hard fork way, because there will still be nodes out there that will not +reapply -- you're basically adding the UTXO back in, in a roundabout way. And +there will be old nodes out there that will not do that, so you're hard-forking +them off the network. + +**Mark Erhardt**: Correct, okay. You're right. + +**Ruben Somsen**: Yeah. And so, that's why I arrived at the conclusion that you +want to reorg back to block 99, and then have a completely different chain from +there. And so, that allows everybody to stay together. But I think it's also +just completely reasonable to fix this in a hard fork type of way and just say +like, "Look, this is far in the past. Similar to removing the checkpoints, +let's just add that UTXO back in when the reorg occurs, and then make sure +everybody has that UTXO in the UTXO sets". That would also be a way of +resolving this. + +**Mark Erhardt**: I mean, if we're looking at this practically, if we have a +reorg of more than 15 years' of blockchain data, people can also just resync +from scratch! + +**Ruben Somsen**: Yeah, I think it's still not a soft fork. You still have that +hard fork problem that I just described, right? + +**Mark Erhardt**: Yeah, of course. + +**Ruben Somsen**: But yeah, I think this goes sort of into more of philosophical +territory of like, "Well, why are we even validating this old stuff in the first +place?" And I think, generally speaking, the way I look at that is that I think +with Bitcoin, we strive for decentralization and that includes verifying +everything, allowing for these theoretical, even though never going to happen, +reorgs. And so, I think part of the philosophy and part of the structure, just +for that reason of trying to aim for an ideal, even though we're never going to +achieve it, like it's not never going to be perfectly decentralized, +unattackable, whatever, I think striving for it is a good goal. And I think +with that in mind, I think it is perhaps good to fix something like this. But +practically speaking, it's inconsequential. + +**Mike Schmidt**: So, if we reorg back 15 or so years, it's catastrophic +already, but I guess, Ruben, you're pointing out it can be even more +catastrophic? + +**Ruben Somsen**: That's right. + +**Mike Schmidt**: And it sounds like you're advocating for a fix for more maybe +on principle or philosophy than practicality? + +**Ruben Somsen**: I'm not even strongly advocating for anything. There are two +reasons why I wrote this up now. It's because we're removing the checkpoints. +So, considering removing the checkpoints is a hard fork, this is the moment we +could fix it in a hard fork kind of way, because we're sort of doing a hard fork +already anyway. So, that's one reason. The second is to just write this up, +make sure people are aware that this is a thing, and just put it out there. I +don't have a very strong opinion on whether or not we should fix this or not, +but I just wanted to put it out there, make sure everybody is aware of it. And +I guess the second thing, because the second part of my post also just goes +into, "Well, can't we get rid of BIP30 altogether?" And the reason for that is +that with BIP30, we are checking the UTXO sets up until 2013, up until BIP34 +activates. We're checking with the UTXO set whether an output already exists. +And this is basically double the number of lookups onto the UTXO sets. + +Considering this is so far in the past, it doesn't really affect performance all +that much, but it's not a very pretty way of doing things. And it gets in the +way of alternative implementations such as utreexo, such as SwiftSync, that do +not have direct access to the UTXO sets. And I think Libbitcoin, I'm not sure +how they handle it. Well, I think what they do, which is also sort of a +different way of looking at it, but they just basically currently, they have the +checkpoints, I believe, as just saying like, "Okay, well, everything up until +the checkpoint is just valid". And so, they don't even do the BIP30 check, +because we have the checkpoint anyway. And again, I don't think it's +unreasonable, but from the philosophical perspective of, "It's nice for +everybody to check everything", I think it would be nice to check that. And so, +I have a workaround, which basically is, "Hey, let's just check every coinbase +output, check the txid, make sure it's unique, up until the 2013 point". And if +we do that, it's roughly 7 MB worth of txids, so it's not a lot. And then, you +can get rid of the UTXO set checks altogether, you could get rid of the BIP30 +code even, and you'd have to add other codes, so it's not a net win in terms of +the code. But again, this is one of those things where I think philosophically, +it's nice, it's possible, maybe we want to do it someday. + +For SwiftSync, we've got to do it anyway already, if we do want to do these +checks, or something along these lines. So, that's sort of the second part of +the post. + +**Mike Schmidt**: Murch, anything else on this item? You're good? Ruben, +thanks for jumping on and talking us through this edge case. It's interesting. + +**Ruben Somsen**: Yeah, no problem. + +**Mike Schmidt**: We appreciate your time. You're free to drop if you have +other things to do. + +**Ruben Somsen**: Yeah, I'm pretty busy, so I'm dropping out. See you guys. + +_Add bitcoin wrapper executable_ + +**Mike Schmidt**: See you. We're going to jump to the PR Review Club segment, +and so we're going to skip the second news item briefly here and jump to the PR +Review Club on, "Add bitcoin wrapper executable". This PR introduces a new +Bitcoin binary, so not bitcoind, not bitcoin-cli, but Bitcoin binary, which can +be used to discover and launch various Bitcoin Core binaries. The PR is part of +the process separation or multiprocess project. Stéphan, you are involved with +the PR Review Club. I know you didn't host this one, but I know you were +involved. How would you summarize multiprocess and this PR for our listeners? + +**Stéphan Vuylsteke**: Yeah, so I guess to start with, the purpose of this PR, +and then I'll dive deeper into multiprocess and IPC as we go along. I'm going +to keep it fairly high level. But basically, the issue is that with the +multiprocess project, we're going to be adding a few more binaries to the +already sizable list of binaries that we ship. So, how do you fix having too +many executables? You add, of course, one more executable to fix the problem, +or as in one executable to rule them all. So, diving a bit more into what that +all means, multiprocess is probably the longest running project that we have in +Bitcoin Core. It started, I believe, in 2015. And the initial goal there, and +it's changed a bit over the years, but the initial goal there was to enable +breaking up the monolithic Bitcoin Core process into multiple processes that +could talk to each other, with some stated goals being increased security by +isolating different processes, but also, for example, allowing different kinds +of scalability, allowing you to run different processes on different machines. +Maybe you want to run your bitcoind on a beefy server, and then you can run GUI +on your local machine, or any kind of other configuration. And you can even +swap different processes out for each other, so you can even customize things a +bit more. + +But more recently, multiprocess has really gotten a new breath of air with the +mining interface. So, Stratum v2 has become quite a prominent project also in +recent years. And Stratum v2 required some updates to the getblocktemplate RPC +that seemed to be quite difficult to accommodate well within the Bitcoin Core +RPC interface, without loading lots of code into Bitcoin Core codebase, which is +not ideal. So, then the proposal was made to build this interface over IPC, so +basically using multiprocess. What is IPC? IPC is inter-process communication, +which is basically the concept that multiprocess used to allow these different +processes to talk to each other. So, if you have the Bitcoin node process, the +Bitcoin wallet process and the Bitcoin GUI process, they all talk to each other +through IPC. And specifically, for multiprocess, we use the Cap'n Proto +protocol, which is an existing protocol that focuses specifically on this kind +of communication. And then, multiprocess is basically a wrapper around Cap'n +Proto. So, maybe to reduce confusion, multiprocess means both the project of +separating Bitcoin Core into multiple processes at runtime, as well as the name +of the library that wraps Cap'n Proto to do this kind of communication +technically. + +So, yeah, the mining interface has taken the forefront in recent multiprocess +efforts, which is also why in the upcoming release, we're going to start adding +multiprocess binaries as part of the release process. What does that mean? Let +me start with what it doesn't mean. It doesn't mean that we're going to have +binaries that effectively do split up Bitcoin Core into, for example, the GUI, +the wallet, and the node process. At the moment, the multiprocess and the +monolithic binaries are the exact same thing, with the only difference that the +multiprocess binaries allow communication over a unique socket, so that other +processes, such as, for example, a Stratum v2 sidecar, can talk to the Bitcoin +Core process. And let me have a quick break here before I go into the purposes +of the PR that we covered in the Review Club. Does that make sense? Should I +dive deeper into any of these components? I'm getting a thumbs up, so I'll +carry on. + +Right, so if we're going to be adding two more binaries, namely bitcoin-node and +bitcoin-gui, which are multiprocess binaries, some reviewers have raised some +fears that this might get very confusing for users as to them figuring out which +binary you should be using for their purpose, especially as we will be adding +more of these binaries in the future. So, then this PR tries to fix that by +basically adding this new top-level wrapper binary called Bitcoin, which accepts +subcommands as well as arguments and is going to figure out, based on the +arguments, which of these binaries it should launch. So, for example, if you +use this new binary and you say bitcoin-gui, then this wrapper knows that it has +to launch bitcoin-qt or bitcoin-gui, based on the parameters that you've parsed. +So, if you parse, like, -multiprocess, then this can launch the multiprocess +binary. If you don't, you can launch the monolithic binary. + +So, this is a fairly simple thing. This wrapper does not do any Bitcoin +validation logic or PTP on your node. It just really takes commands and +arguments, finds the binaries, executes them, and adds some gel to make it +easier for the user so they can more easily find which commands are available. +In the future, this can even be extended by adding, like, Fuzzy Search. If you +do a typo, or if you type in, "bitcoin-gi", instead of, "bitcoin-gui", then it +can tell you that these things are fixed. So, it makes that much more user +friendly, but also it offers the benefits for the Bitcoin Core project that we +can keep the interface stable, even when we reorganize which binaries we ship, +or how they're named, and so forth, because we have this wrapper that is the +actual interface that can do the translation and that can keep things constant +for the user. So, it gives us a bit of flexibility and freedom as well, which +is a nice benefit. + +**Mike Schmidt**: In the example of the GUI, I would type, "bitcoin gui", and +then the Bitcoin binary would do what to figure out if it's going to launch +bitcoin-qt or the multiprocess bitcoin-gui? + +**Stéphan Vuylsteke**: It just inspects if you've passed a -m argument to the +Bitcoin binary. So, that's the simple way to toggle between both options. + +**Mike Schmidt**: Okay, so it's all command-line-option-based, there isn't +something like in a config file somewhere where I say, "Hey, I always want to +use the multiprocess, or I always want to use the monolith"? + +**Stéphan Vuylsteke**: I believe that was suggested as an option for future +improvements, but I don't think that's the case at the moment, no. + +**Mike Schmidt**: Excellent. Well, we did highlight five interesting questions +for those who want to dive deeper into this particular Review Club. Those +summaries are up on the newsletter write-up, but I would also advocate folks go +to the PR Review Club and you can review the whole meeting and its dialogue +there. But also, I found that the write-ups before the meeting are +super-informative. So, if this is something that you're curious about or +worried about, or whatnot, you can check that out now. Stickies, anything else +you think people should be aware of on multiprocess and this Bitcoin executable? + +**Stéphan Vuylsteke**: I mean, give it a try, it's fairly easy if you're used to +compiling Bitcoin Core. You can check out the PR and try and compile it +yourself. It's pretty easy. See if it works for you, if the interface is +useful, then that'd be useful feedback. + +**Mike Schmidt**: And this will be in version 30? + +**Stéphan Vuylsteke**: I don't think it's tagged for version 30, so I guess it +depends on the user feedback. But if it is merged before branch-off, then yes, +it should be in 30. + +**Mike Schmidt**: Okay, cool. + +**Mark Erhardt**: Sorry, you probably said it and I missed it, but when this +ships and if it is in the 30 release, how does this change what users need to +do, if they already have scripts set up that call bitcoind in the background, or +whatever else? Would it change anything, or is it just new people that write +their new command-line arguments with bitcoin instead of bitcoind? For them, +it's going to be stable going forth? What's the practical implication? + +**Stéphan Vuylsteke**: Yeah, sorry, I forgot to mention that, so thanks for +raising it. So, at the moment, there are no plans or roadmaps to deprecate the +current binaries. So, maybe at some point in the future, bitcoind will not be a +command you can execute anymore. But for now, this is purely additional. So, +you can run Bitcoin as base node, or you can run bitcoind. Both are possible. +So, nothing should change for existing users. This is all kind of add-on extra +for people that want to use the binary. + +**Mike Schmidt**: You mentioned mining as the motivation. Maybe one more +question. In the write-up, we have the bitcoind and the GUI separated, but is +there work on this mining piece or is the mining piece something separate that +talks to Bitcoin, the daemon? + +**Stéphan Vuylsteke**: Yes, there's a couple of components there, right? So, +Bitcoin Core has interfaces and the mining IPC interface is one of those +interfaces. So, external applications or processes can, through IPC, use the +mining interface to talk to Bitcoin Core. So, a client can implement the mining +interface and then use IPC to basically communicate with Bitcoin Core to get +block templates or do something like that. So, these new multiprocess binaries +have an extra startup option called -ipcbind, which allows these external +processes to bind to them over a unique socket. So, they can actually +communicate with, for example, the mining interface. I believe at the moment, +the mining interface is the only IPC interface that is exposed through -ipcbind, +I need to double-check, but I'm fairly sure that's the only one that people can +use. + +**Mike Schmidt**: So, I can flag that I want to open up communications via IPC. +Are there binaries that Bitcoin Core will be shipping at any time soon that will +take advantage of that, or is that just up to mining folks to develop their own +for that interface? + +**Stéphan Vuylsteke**: I'm not aware of any binaries that we plan to ship that +use that soon. So, at the moment, it would just be third-party sidecars like +the Stratum v2 template provider that could use something like that. This is +short term. In longer term, anything is possible, but we're trying to not do +everything at the same time. + +**Mike Schmidt**: All right. Well, I know we have a time constraint on your +side here. So, Stéphan, thank you for joining us and representing this Review +Club this week. + +**Stéphan Vuylsteke**: You're very welcome. If folks are interested, we have a +kernel Review Club tomorrow on separating the UTXOs from certain validation +functions. So, if that interests you, then feel free to join the +bitcoincore.reviews. + +**Mike Schmidt**: And for folks that don't know, in addition to his work as a +Bitcoin Core engineer, in addition to coming on podcasts like this, he also +helps run the Review Club, and he also does the write-ups for the Bitcoin Core +Review Club for Optech each month. So, thank you, Stefan. + +**Stéphan Vuylsteke**: You're very welcome. + +_Avoiding BIP32 path reuse_ + +**Mike Schmidt**: Cheers. Jumping back to the News section, second news item, +"Avoiding BIP32 path reuse". Kevin from Liana posted to the Delving Bitcoin +forum a post titled, "Avoiding xpub+derivation reuse across wallets in a +UX-friendly manner". He and the Liana team are working on a feature for +multi-wallet support in Liana and he said he was not happy with any of the +common ways to avoid xpub reuse. Kevin couldn't join us today to represent his +idea, but Salvatore, who's familiar with the topic and also participated in the +discussion on Delving, is here to help us understand the issue, the current +solutions, and any new solutions that are being discussed. + +**Salvatore Ingala**: Hello, and I hope I do a good job in representing Kevin's +positions and ideas, because they work on software wallets, I don't. I work +more on the infrastructure that they use, but not directly on the software +wallets themselves. And so, the problem that he posted was about how to avoid +xpub reuse. So, the xpubs are basically the keys that are used when you set up +a wallet, whether it's single-signature, multisignature, or more complicated +stuff like the miniscript wallets. And so, for each of the cosigners, normally +you would provide one xpub; and so, if you have three cosigners, you will have +one xpub for each cosigner. And so, the way we derive xpubs from one seed was +originally settled with BIP32, so that we have one seed that can be used to +derive all the possible public keys and private keys that you need for all your +possible transactions that you want to be involved with the same seed. And so, +there are some other standards that evolved over time to kind of define how you +would derive keys for specific use cases. + +That worked well until people were basically doing just single-signature stuff. +And basically, all the type of wallets were uniform, the script was the same, +the only thing that changes is the xpub. And so, by just defining how you +derive the keys, which is what BIP32 calls the derivation path, that allows to +kind of know from the seed how you derive the keys that you need. So, all you +care about was this derivation path. But since Bitcoin evolved over time, and +now we move to descriptors, descriptors allowed to kind of define many possible +kinds of wallets. So, basically, now the derivation paths is no longer enough. +And so, we discussed other occasions that if you should use anything more +convenient than single-signatures, basically you have to have a backup of the +entire descriptor that describes not just all the involved xpubs, but also what +is the script exactly, so what are the spending conditions of this wallet. + +The problem still comes that, well, when you create a new wallet account with a +wallet like Liana or Sparrow, or any wallet that's multisignature, you have to +decide what xpubs you use in this wallet. And functionally, any xpub is as good +as any other xpub because they all come from the same seed, so you would be able +to sign. But there is a problem where if you reuse the same xpub for multiple +wallet accounts, maybe different wallets with different sets of people, even if +it works, it's still bad to reuse the same xpub, because the same xpub means +that the keys that you derive from this xpub will be the same. And so, in many +situations, these keys will end up onchain, and this allows an attacker to +potentially link different outputs that belong to the same entity, the same +person, even if they are in different wallet accounts formally, by just +observing the blockchain; they just see that there is the same public key in +different wallets. And so, they would notice that somehow the same entity, the +same person is involved in these two different transactions. And so, that's at +least bad for privacy, and so we want to avoid that. + +Of course, wallets have been aware of this problem for a long time. But +normally, the way to solve this problem is to either ask the user which account +you want to derive the xpub from. Maybe they have part of the derivation path +fixed, but then the account index. So, for example, in BIP44, which was +probably the first to introduce this kind of account derivation, the first three +steps of the derivation path are called 'the purpose', which is kind of +identifying what kind of wallet you're using. The coin type, which was used to +kind of distinguish if you use the same schemes for Bitcoin or for Ethereum, for +other currency, for cryptocurrency and everything, at least you can partition +keys that you use for different cryptocurrencies. And then the account index, +which is the third derivation step. And so, by using a different account index, +you're sure that you use different public keys. And so, if you make a wallet, +like when you are setting up a new wallet account in a wallet, you can ask the +user, "Okay, what account do you want to use?" And if the user is careful, they +can be sure that they don't use the same account index. But of course, this is +something that for people who are not experts, it's hard to understand what is +the account index, why do I have to choose an account index? And you know, +people who are experts, information gets lost, you might have used this account +index years ago and you don't remember. So, it's something that's not great for +UX and there is a risk of making mistakes. + +So, Kevin proposed what are different approaches to solve this problem with a +better UX, like if we don't want to ask the user what are things that we could +do. And so, one idea would be that we can keep track of all the public keys +that we used in the past, all the xpubs that we used in the past, we have some +storage somewhere. But of course, this works in theory, but then in practice, +how do you synchronize this, because you might set up a wallet account with +Liana and another wallet account with Sparrow, so there is no standard of +networks for the wallets. Also, where do you store this information? That's +also not a trivial question. And so, in general, if there are solutions that +don't require state, they are easier to manage. + +So, among the solutions that are stateless, Kevin was proposing different +solutions that are either to use completely random paths. So, anytime you +create a new account, you add a couple of the derivation steps that, say, are +completely random. And so, as long as the number of bits that's used for the +randomness is large enough, the chance that there is a collision is very low. +Probably even just a single derivation step would be enough, but maybe to be +sure, you can use two derivation steps, and that would solve the problem. +Another solution could be that you use not random, but kind of deterministic +paths. And the solution that he was suggesting was to use time as deterministic +information. So, instead of using randomness, you use the time to kind of seed +your information. Murch has a question. + +**Mark Erhardt**: If you were to use randomness, wouldn't that mean that you +need a new backup every time you create another multisig wallet, even though you +might already know all of the involved public keys and they are reused across +many wallets? Every time you introduce a new random number, you need a new +backup, right, so that seems like a big step? + +**Salvatore Ingala**: Yeah, but I would say for multisignature, you do need a +new backup for a new account you create anyway. + +**Mark Erhardt**: Okay. + +**Salvatore Ingala**: Because when creating your account, you're not going to +reuse the several points of discussion, you don't want to reuse the xpubs of the +other people either. So, everybody will provide a new xpub. And so, you have a +whole new set of xpubs that you have to store as part of the descriptor. So, +the fact that you need to backup the descriptor is kind of an assumption at this +point when you use descriptor-based wallets. And so, those are basically the +two solutions, because the other solution was to actually store state either in +the hardware wallet or in the software wallets, and synchronize them. We +discussed why that's a bit difficult. So, maybe I'll pause a moment to see. +Hopefully, I summarized all the points Kevin made in his initial post. + +**Mike Schmidt**: Yeah, that was great, super-informative, and thanks for +walking us through that, Salvatore. Yeah, so I mean, just to reiterate for the +audience, the primitives are there to provide this functionality. It's just, +how do we do this in a user-friendly manner while not having some sort of +centralized coordinator who says, "Okay, now use this derivation path because +you used this one already", which I think is the third option. Okay, so how has +the discussion gone? + +**Salvatore Ingala**: Yeah, so there was some discussion, so I raised two +concerns that are actually both relatively minor concerns. So, it was more to +be sure that the discussion is aware of these points. So, one is that in the +examples that Kevin made, he was using entirely random derivation paths, so no +longer using at all the structure that comes from BIP44 or similar BIPs. And I +suggested that actually, using at least the purpose and coin type defined in +that BIP still has a value, because partitioning different key hierarchies based +on the purpose, but especially the coin type for people who have multiple +cryptocurrencies, can still be relevant. And some other wallets in particular, +I know that Ledger does it, you can put restrictions for different applications +that are for different cryptocurrencies, so that they cannot derive keys that +are not for that coin type. So, this allows to put different access levels to +different parts of the hierarchy, so that the Ethereum app will not be able to +access the keys of the Bitcoin app, and vice versa. So, it will still be useful +to have at least those in the hierarchy because anyway, they are fixed numbers, +they are very small numbers, so it doesn't add much friction. + +The other point I made is that it would be nice to try to avoid as much as +possible to introduce randomness or entropy, because randomness is something +that introduces more information content in this backup. And the problem with +this is that this information content is not something that you are just storing +in a file. But for security, you also have to verify this information on the +device screen. So, you want to put as little information as possible there, +because if you put more information, people are more likely to not check the +information there. So, if you put a lot of randomness, for example, if you use +like three, four completely random derivation steps, each derivation step is 32 +bits of random, it's quite a big random number. And if you're not checking, if +you forget checking this number, an attacker that maybe puts malware on your +computer, the way they could steal money from you would be with a ransom attack, +where basically they trick you into registering a wallet for which you don't +actually know the derivation path, by just actually deleting the real random +numbers. So, if you don't check with your backup when you register the wallet +on the device, you might be using one of your xpubs, but it's in a place that +you don't know how to derive. And now, the attacker is the only person that +knows where the actual xpubs were derived from. So, if you have a lot of +randomness, you will not even be able to brute force where these keys came from. +And so, this kind of creates a UX issue where the registration step, which is a +security-critical moment, becomes a little bit worse in terms of UX. + +So, among the solutions that Kevin proposed, for example, I think the one based +on the date is a lot better, because the date in the example he used would be +encoded up to the second. And so, the chance that you would produce two +different xpubs in the same second is probably zero. And so, you are guaranteed +that you will never reuse an xpub. And the entropy of comparing a date on the +device screen, I would say it's less than comparing a random number. So, in +terms of information content, comparing two numbers that look like a date, it's +a lot easier than comparing two random numbers. So, that's my favorite approach +among the two. And I also tried to suggest that actually, there are good points +of trying to figure out how to keep state synchronized, because there are many +potential benefits. But I do understand that it's a much harder approach. I +mentioned that because there are other benefits for software wallets to have a +place where they can store information. For example, if you label coins that +you used in the past, this label is something that you will likely not lose. +And there are potentially other things, like other metadata associated to both +your wallets and your transactions, would be nice to have a standardized place +of storing it. And this is a small amount of data, but you would likely not +lose it. So, I think software wallet struct should actually try to solve this +problem, because it would solve many things. And in this context specifically, +it would allow to use just a very small number for the derivation path, because +you actually keep track of all the xpubs that you use. + +**Mike Schmidt**: So, it sounds like you're leaning a bit towards the date as +the unique piece? + +**Salvatore Ingala**: Yeah, I think if you want a good state, that seems the +most reasonable to me. It solves the problem in a quite nice way and doesn't +make the UX much worse in terms of registration. + +**Mike Schmidt**: Murch, do you have any thoughts? Murch is good. Salvatore, +you have folks listening that are maybe building libraries, building software, +what's the call to action here? Should they just jump in on this Delving +thread, or do you have something else? + +**Salvatore Ingala**: Yeah, like I will say, especially for people who are +thinking about Bitcoin as a product, that's a very interesting product question, +how to solve this problem, because it affects all the software wallets, +basically. So, solving it in the best possible way in terms of UX matters. It +makes everybody's experience slightly better. So, if you have ideas, definitely +respond on the post or contact Kevin and let him know what are your ideas. + +**Mike Schmidt**: Great. Salvatore, thanks for hanging on with us to cover this +news item. You're welcome to stay on, or we understand if you have things to do +and need to drop. + +**Mark Erhardt**: I was wondering actually, Salvatore, whether you had thoughts +on one of our last items here, the BIPs #1835 change to BIP48, which is about +derivation paths for multisig wallets? So, I figured we could maybe pull that +up if you want to stick around for that one, or if you're going to stick around +anyway, we could pick your brain on that later. + +**Salvatore Ingala**: Yeah, I can stick around so meanwhile I have time to read +it. + +**Mark Erhardt**: Okay. + +_LND 0.19.0-beta.rc4_ + +**Mike Schmidt**: All right, perfect. Thanks for hanging on Salvatore. Okay, +moving to the Releases and release candidates section, we have good old trusty +LND 0.19.0, this time beta.rc4. I'm going to continue to point back to Murch's +Recap in #349 of our podcast, where he did a good job of digging into this. + +_Core Lightning #8227_ + +Notable code and documentation changes, Core Lightning #8227 is a PR that +implements BLIP50. And BLIP50 was originally the Lightning Service Provider +(LSP) spec LSPS0 that specified how communication should work between a +Lightning Wallet and its LSP. And we actually discussed that BLIP, which at +that time was an LSPS spec, back in Newsletter and Podcast #251, and we had the +author of that specification, Severin Bühler, on. We noted in the newsletter +this week that the PR implementing this communication protocol, which is the +LSPS0, is related to and other specs can build upon, which this is BLIP51, which +specifies LN liquidity requests on top of LSPS0. And that's also BLIP52, which +is just-in-time (JIT) channels, which was LSPS2. And both of those BLIPs were +also covered in Podcast #251 when they were specified in the LSPS repository. + +So, you have these three LSPS specs, one defining the communication between the +Lightning Wallet and its LSP. That is being implemented here in Core Lightning +(CLN) in anticipation of building these future LSP specs on top. + +_Core Lightning #8162_ + +Core Lightning #8162 is a PR titled, "Handle closed channels better". CLN won't +forget still opening channels after 2,016 blocks, which is what it did +previously, unless there are more than 100 of them. So, it's sort of retaining +knowledge of pending open channels beyond what it did before, but with a limit +of 100. Part of the motivation for this PR, I'll quote, "Michael of Boltz told +me this long ago, that when fees spiked, some of their clients' opens got stuck. +After two weeks, their node forgot them, and when fees came back down, the opens +still failed". So, there was a little bit of the motivation there. CLN now +replies with channel_reestablish even on long-closed channels, and keeps closed +channels in memory, noting they're small, and this will allow us to efficiently +respond to re-establish them". + +_Core Lightning #8166_ + +Core Lightning #8166 is a PR titled, "Listhtlcs pagination". This PR actually +does a couple of different things. One is the pagination that I'll get to. But +the first thing in this PR is improve CLN's wait API by replacing what was +returned previously, which was just a generic details object, with something +that is more distinct. There are objects for invoice, forward, and sendpay +types now, so you're not dealing with a generic interface, and I think it's gRPC +compliant as well. In addition to that change, CLN also has this listhtlcs rpc +command that gets all of the HTLCs (Hash Time Locked Channels). Previously, +that RPC returned all the results with that command, which is still the case now +by default, I believe, but the RPC also has options to specify the maximum +number of entries that are returned. So, instead of getting 2,000 entries in +response to listhtlcs, you could chunk it and get the first 100, then the next +100, then the next 100, which is the pagination piece. + +_Core Lightning #8237_ + +Core Lightning #8237 adds an option to the listpeerchannels RPC for CLN to +search for a specific channel based on the channel's short channel identifier. +You could do something like that previously, but it was more cumbersome, so they +added this ability to parse this short_channel_id to just pull it right out of +the list of your channels. + +**Mark Erhardt**: With this whole set of CLN updates, are we about to see a CLN +release? + +**Mike Schmidt**: I suspect yes, that has been the case in the past. + +**Mark Erhardt**: Carry on! + +_LDK #3700_ + +**Mike Schmidt**: LDK #3700 adds failure_reason to LDK's HTLCHandlingFailed +events to provide additional information about why the HTLC failed. Seems +pretty straightforward. I don't remember if it was LDK in the last few weeks, +we've had similar things where routing and other error type information is being +more granularly given back to users, the API. + +_Rust Bitcoin #4387_ + +Which leads also to Rust Bitcoin #4387, which similar to the last PR, this PR +for Rust Bitcoin adds more granularity to Rust Bitcoin's handling of errors, by +adding more detailed error types beyond the previous generic error type that was +used previously. I think specifically, this was in the context of BIP32. + +_BIPs #1835_ + +BIPs #1835. Salvatore, hopefully we stalled long enough with all these LN PRs +to see if you have a perspective on this. Murch, I know you're BIPs editor, and +you may have some thoughts as well. But Salvatore, did you have a few minutes +to look at it? + +**Salvatore Ingala**: Yeah. So, BIP48 was basically kind of extending the +approach of BIP44 for multisig. And basically, what it does is that it does a +fourth hardened derivation step. So, we mentioned the first three are purpose, +coin type, and account. And so, this adds a fourth derivation step, which is +also half-dumped, which is the script type. And so, the BIP defined some script +types for the type of multisig that was used at the time the BIP was made. So, +native segwit, nested segwit, and, wait, I'm missing one, because I think I +don't see legacy in the BIP. But anyway, so basically, different types of +multisig, it doesn't really matter for this discussion. It defines a different +script type as a derivation step as a standard way. And so, this PR was about +updating it, because now there is also taproot multisig. And so, it adds a new +script type, number three, for taproot multisig. + +So, formally, also yes, it makes sense to update the PR. At the same time, I +would update the BIP. At the same time, I will say that the entire BIP is +probably a bit obsolete by now, because now that there are descriptor-based +wallets, the assumption, as we discussed before, is that you do need a backup +for the descriptor wallet, for the descriptor. Also, because this seems to be +written with the idea in mind that you will not need the backup, which is anyway +false, even in the context of multisignature, because if you lose the xpub of +one of your cosigners, then you're still not able to sign transactions, even if +you have the other public keys. So, this is something that we discussed other +times. So, this could only help you insert things where you control the keys +and you're only using multisig for redundancy. Then probably, a BIP like this +will help. But one of the valid reasons people use multisignature is that +different entities control different xpubs. So, I think it's actually a sane +assumption to write software wallets that make sure that the user will not lose +the descriptor. That's actually the safest approach. Like, it's more footgun +prone to assume that there is value in being able to recover then without having +a descriptor, rather than teaching all the time that instead, you have to have +the backup for the descriptor. So, that's my point of view on this. + +**Mike Schmidt**: Murch, you have any thoughts? + +**Mark Erhardt**: Well, just I did also take a look at the BIP just now, and it +does look like it's only wrapped segwit, native segwit, v0, multisig, and now +P2T. So really, only these three types, and it didn't even define legacy. I +think BIP48 is fairly young, it only came out in 2020, so I guess legacy was +sufficiently in the past at that point that it wasn't even defined. + +**Salvatore Ingala**: And another point is that actually, the script type, it +only says taproot, but taproot what, is it multisig? Where? Is it a +sortedmulti? I think there is multi-a and certain multi-a, I think. I don't +know if both are defined as a descriptor. There is also a MuSig, potentially. +So, you might have different approaches for multisignatures. So, still, this is +not necessarily enough information to even know the script type. + +**Mark Erhardt**: That's a very good point. And maybe the BIP editor should +have watched out a little more to notice that! If you want, I think it just got +merged a few days ago, so your comment would probably still be appreciated. + +**Salvatore Ingala**: Yeah, also I'm a bit skeptical on the whole BIP at this +point, I think! But yeah, that reminds me that actually, maybe at this point, +since this was changed to have the third script type as part of the BIP, so +Ledger devices allow to have the third script type as part of the BIP. But you +would have to ask confirmation to the user, while for the script types that were +already defined, you can do it silently. So, for uniformity, maybe I can +remember to update this for the next release of the app. + +_BIPs #1800_ + +**Mike Schmidt**: BIPs #1800 merges BIP54, which specifies the consensus cleanup +soft fork proposal. Most recently on this show, we covered the same BIP, but +when it was in draft form, and that was in Newsletter and Podcast #348, and that +was with the BIP's author. We also have a consensus cleanup soft fork page on +the Optech Topic wiki. It can point any listeners to other discussions we've +had on it over time, as well as related PRs and mailing list posts. So, take a +look there. Murch, I don't know if you want to add anything to that? + +**Mark Erhardt**: No. I mean, as usual, the BIP is merged now. It's in draft +status, which means that the author feels that the recommendation is complete +enough that it can be permanently presented to the community, but it's not moved +yet to proposed, in the sense that it's recommended for activation. So, if you +have thoughts on any part of that BIP, we're still in the comment period, so to +speak, on this proposal. I assume that it will be moved to proposed in the +coming, I don't know, weeks, months, and eventually maybe there will be a +proposal on how to activate it as well. + +_BOLTs #1245_ + +**Mike Schmidt**: Last PR this week to the BOLTs repository, BOLTs #1245, which +is a change to the LN spec's BOLT11 invoice protocol. So, during some fuzz +testing, some engineers found that there were some unnecessary leading zeros in +some BOLT11 fields, and that caused issues for LDK when they were parsing and +then reserializing an invoice, that would actually cause the invoice hashes to +change. So, this change to the spec fixes that potential issue by requiring the +minimal data length possible, which then would standardize the serialization and +deserialization for LDK, but it's probably a good idea regardless. The PR notes +that this doesn't appear to have been occurring in regular practice or in the +wild, but, "Because this hasn't happened and it breaks a straightforward way to +handle BOLT11 parsing, there's no reason to retain it. So instead here, we +simply forbid non-minimally-encoded features in BOLT11 invoices". + +Well, that's it for this week. {% include references.md %} From 372fe91df97ec28675f01a79f728fedaf48b45f7 Mon Sep 17 00:00:00 2001 From: Jiri Jakes Date: Fri, 23 May 2025 09:20:36 +0800 Subject: [PATCH 027/278] Newsletter-355: Translate into Czech --- .../cs/newsletters/2025-05-23-newsletter.md | 160 ++++++++++++++++++ 1 file changed, 160 insertions(+) create mode 100644 _posts/cs/newsletters/2025-05-23-newsletter.md diff --git a/_posts/cs/newsletters/2025-05-23-newsletter.md b/_posts/cs/newsletters/2025-05-23-newsletter.md new file mode 100644 index 0000000000..755adf1e7e --- /dev/null +++ b/_posts/cs/newsletters/2025-05-23-newsletter.md @@ -0,0 +1,160 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 355' +permalink: /cs/newsletters/2025/05/23/ +name: 2025-05-23-newsletter-cs +slug: 2025-05-23-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden přináší pravidelné rubriky s popisem nedávných změn +ve službách a klientech, oznámeními nových vydání a souhrnem nedávaných +změn v populárním bitcoinovém páteřním software. + +## Novinky + +*V našich [zdrojích][sources] jsme tento týden nenašli žádné významné novinky.* + +## Změny ve službách a klientech + +*V této měsíční rubrice upozorňujeme na zajímavé aktualizace bitcoinových +peněženek a služeb.* + +- **Cake Wallet podporuje payjoin v2:** + Cake Wallet [v4.28.0][cake wallet 4.28.0] přidává [schopnost][cake blog] + přijímat platby pomocí protokolu [payjoin][topic payjoin] v2. + +- **Sparrow přidává podporu pro pay-to-anchor:** + Sparrow [2.2.0][sparrow 2.2.0] zobrazuje a umí odesílat [pay-to-anchor + (P2A)][topic ephemeral anchors] výstupy. + +- **Vydána Safe Wallet 1.3.0:** + [Safe Wallet][safe wallet github] je desktopová multisig peněženka s podporou + hardwarových podpisových zařízení, která ve verzi [1.3.0][safe wallet 1.3.0] + přidává [CPFP][topic cpfp] navyšování poplatků příchozím transakcím. + +- **Vydána COLDCARD Q v1.3.2:** + [Vydání 1.3.2][coldcard blog] COLDCARD Q přidává další pravidla pro [multisig + utrácení][coldcard ccc] a nové možnosti [sdílení citlivých dat][coldcard kt]. + +- **Dávkování transakcí pomocí payjoinu:** + [Private Pond][private pond post] je [experimentální implementace][private + pond github] služby [dávkování transakcí][topic payment batching], která + používá payjoin ke generování menších transakcí platících nižší poplatky. + +- **JoinMarket Fidelity Bond Simulator:** + [JoinMarket Fidelity Bond Simulator][jmfbs github] poskytuje účastníkům JoinMarketu + nástroje pro simulaci úspěšnosti na trhu založeném na [finančních závazcích][news161 fb]. + +- **Dokumentace bitcoinových opkódů:** + Webová stránka [Opcode Explained][opcode explained website] poskytuje dokumentaci + každého opkódu v bitcoinovém skriptu. + +- **Kód Bitkey zpřístupněn jako open-source:** + Hardwarové podpisové zařízení Bitkey [ohlásilo][bitkey blog] dostupnost [zdrojového + kódu][bitkey github] jako open source pro nekomerční účely. + +## Vydání nových verzí + +*Vydání nových verzí oblíbených páteřních bitcoinových projektů. Prosíme, +zvažte upgrade či pomoc s testováním.* + +- [LND 0.19.0-beta][] je novým hlavním vydáním tohoto oblíbeného LN uzlu. + Obsahuje mnoho [vylepšení][lnd rn] a oprav chyb, včetně nového systému + RBF navyšování poplatků během kooperativního zavření kanálu. + +- [Core Lightning 25.05rc1][] je kandidátem na vydání příští hlavní verze této + oblíbené implementace LN uzlu. + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo] a [repozitáři BINANA][binana repo]._ + +- [Bitcoin Core #32423][] odstraňuje poznámku o zastarání `rpcuser/rpcpassword` + a nahrazuje ji bezpečnostním varováním o ukládání hesel v konfiguračním + souboru v čitelné podobě. Tato volba byla původně odsouzena k odstranění, + když byl v [Bitcoin Core #7044][] představen `rpcauth`, který podporuje + několik uživatelů RPC a hašuje cookie. PR dále přidává k heslům 16bajtovou + náhodnou sůl a před uložením do paměti je hašuje. + +- [Bitcoin Core #31444][] přidává do třídy `TxGraph` (viz [zpravodaj č. 348][news348 + txgraph]) tři pomocné funkce: `GetMainStagingDiagrams()` vrací rozdíly v clusterech + mezi hlavním a přípravným diagramem poplatků, `GetBlockBuilder()` prochází + grafem chunků (podskupiny transakcí seřazených dle poplatku) od nejvyššího poplatku + po nejnižší a `GetWorstMainChunk()` vrací chunk s nejnižším jednotkovým + poplatkem určený k vyloučení. Toto PR je jedním z posledních kroků před + kompletní implementací [mempoolu clusterů][topic cluster mempool]. + +- [Core Lightning #8140][] aktivuje ve výchozím nastavení [peer storage][topic peer storage] + pro zálohy kanálů (viz [zpravodaj č. 238][news238 storage]). PR činí tuto možnost + použitelnou i pro velké uzly, neboť omezuje množství ukládaných dat, kešuje + zálohy a seznamy spojení v paměti namísto opakovaných volání `listdatastore`/`listpeerchannels`, + omezuje současné nahrávání záloh na dvě spojení, přeskakuje zálohy větší než 65 kB + a nahodile vybírá spojení pro posílání. + +- [Core Lightning #8136][] upravuje čas výměny podpisů pro oznámení kanálu. Dříve + s výměnou čekal na šest potvrzení, nově se budou podpisy v souladu s nedávnou + změnou specifikace v [BOLTs #1215][] vyměňovat, jakmile je kanál připraven. + Na zveřejnění [oznámení kanálu][topic channel announcements] se i nadále musí + čekat šest bloků. + +- [Core Lightning #8266][] přidává nový příkaz `update` do manažeru pluginů Reckless + (viz [zpravodaj č. 226][news226 reckless], _angl._). Příkaz aktualizuje pluginy + (jeden konkrétní nebo všechny) kromě těch nainstalovaných z daného tagu nebo commitu. + PR dále rozšiřuje příkaz `install` o možnost kromě názvu pluginu předat i URL nebo cestu + ke zdrojovým kódům. + +- [Core Lightning #8021][] dokončuje interoperabilitu [splicingu][topic splicing] s Eclairem + (viz [zpravodaj č. 331][news331 interop]). Mimo jiné opravuje rotaci vzdálených klíčů a opakované + zaslání zprávy `splice_locked` při opakovaném navázání kanálu v případech, kdy se původní + zpráva ztratí (viz [zpravodaj č. 345][news345 splicing]), uvolňuje požadavky na + pořadí obdržených zpráv, umožňuje přijímat a iniciovat splicingové transakce + s [RBF][topic rbf] a automaticky převádí odchozí [PSBT][topic psbt] na verzi 2. + +- [Core Lightning #8226][] implementuje [BIP137][]. Přidává nový RPC příkaz + `signmessagewithkey`, který uživatelům umožňuje podepsat zprávy jakýmkoliv klíčem + z peněženky poskytnutím bitcoinové adresy. Dříve podepsání zprávy s Core Lightning + vyžadovalo nalézt xpriv a index klíče, odvodit soukromý klíč pomocí externí knihovny + a poté podepsat s Bitcoin Core. + +- [LND #9801][] přidává novou volbu `--no-disconnect-on-pong-failure`, která nastavuje, + zda uzel v případě pozdního nebo nesprávného pongu spojení odpojí. Tato volba je + ve výchozím stavu nastavena na false, čímž zachovává současné chování (tedy že spojení + budou odpojena, viz [zpravodaj č. 275][news275 ping]). V opačném případě LND + událost pouze zaloguje. + +{% include snippets/recap-ad.md when="2025-05-27 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32423,31444,8140,8136,8266,8021,8226,9801,7044,1215" %} +[lnd 0.19.0-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta +[sources]: /en/internal/sources/ +[lnd rn]: https://github.com/lightningnetwork/lnd/blob/master/docs/release-notes/release-notes-0.19.0.md +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[news348 txgraph]: /cs/newsletters/2025/04/04/#bitcoin-core-31363 +[news238 storage]: /cs/newsletters/2023/02/15/#core-lightning-5361 +[news226 reckless]: /en/newsletters/2022/11/16/#core-lightning-5647 +[news331 interop]: /cs/newsletters/2024/11/29/#core-lightning-7719 +[news345 splicing]: /cs/newsletters/2025/03/14/#eclair-3007 +[news275 ping]: /cs/newsletters/2023/11/01/#lnd-7828 +[cake wallet 4.28.0]: https://github.com/cake-tech/cake_wallet/releases/tag/v4.28.0 +[cake blog]: https://blog.cakewallet.com/bitcoin-privacy-takes-a-leap-forward-cake-wallet-introduces-payjoin-v2/ +[sparrow 2.2.0]: https://github.com/sparrowwallet/sparrow/releases/tag/2.2.0 +[safe wallet github]: https://github.com/andreasgriffin/bitcoin-safe +[safe wallet 1.3.0]: https://github.com/andreasgriffin/bitcoin-safe/releases/tag/1.3.0 +[coldcard blog]: https://blog.coinkite.com/ccc-and-keyteleport/ +[coldcard ccc]: https://coldcard.com/docs/coldcard-cosigning/ +[coldcard kt]: https://github.com/Coldcard/firmware/blob/master/docs/key-teleport.md +[private pond post]: https://njump.me/naddr1qvzqqqr4gupzqg42s9gsae3lu2cketskuzfp778fh2vg9c5x3elx8ttdpzhfkk25qq2nv5nzddgxxdjtd4u9vwrdv939vmnswfzk6j85dxk +[private pond github]: https://github.com/Kukks/PrivatePond +[jmfbs github]: https://github.com/m0wer/joinmarket-fidelity-bond-simulator +[news161 fb]: /en/newsletters/2021/08/11/#implementation-of-fidelity-bonds +[opcode explained website]: https://opcodeexplained.com/ +[bitkey blog]: https://x.com/BEN0WHERE/status/1918073429791785086 +[bitkey github]: https://github.com/proto-at-block/bitkey From 0954c5b38cf1914b20ba651bc979399259ef85b3 Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 23 May 2025 20:46:32 +0900 Subject: [PATCH 028/278] Newsletter-355:Translate into Japanese --- .../ja/newsletters/2025-05-23-newsletter.md | 156 ++++++++++++++++++ 1 file changed, 156 insertions(+) create mode 100644 _posts/ja/newsletters/2025-05-23-newsletter.md diff --git a/_posts/ja/newsletters/2025-05-23-newsletter.md b/_posts/ja/newsletters/2025-05-23-newsletter.md new file mode 100644 index 0000000000..a4b0da27eb --- /dev/null +++ b/_posts/ja/newsletters/2025-05-23-newsletter.md @@ -0,0 +1,156 @@ +--- +title: 'Bitcoin Optech Newsletter #355' +permalink: /ja/newsletters/2025/05/23/ +name: 2025-05-23-newsletter-ja +slug: 2025-05-23-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、サービスやクライアントソフトウェアの更新や、 +新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの最近の変更など +恒例のセクションを掲載しています。 + +## ニュース + +*今週は、どの[情報源][sources]からも重要なニュースは見つかりませんでした。* + +## サービスとクライアントソフトウェアの変更 + +*この毎月の特集では、Bitcoinのウォレットやサービスの興味深いアップデートを取り上げています。* + +- **Cake WalletがPayjoin v2をサポート:** + Cake Wallet [v4.28.0][cake wallet 4.28.0]では、 + [Payjoin][topic payjoin] v2プロトコルを使用した支払いを[受け取れる][cake blog]ようになりました。 + +- **Sparrowがpay-to-anchor機能を追加:** + Sparrow [2.2.0][sparrow 2.2.0]では、 + [P2A（pay-to-anchor）][topic ephemeral anchors]アウトプットの表示と送信が可能になりました。 + +- **Safe Wallet 1.3.0リリース:** + [Safe Wallet][safe wallet github]は、ハードウェア署名デバイスをサポートするデスクトップマルチシグウォレットで、 + [1.3.0][safe wallet 1.3.0]では受信トランザクションに[CPFP][topic cpfp]による手数料の引き上げが追加されました。 + +- **COLDCARD Q v1.3.2リリース:** + COLDCARD Q [v1.3.2 リリース][coldcard blog]には、マルチシグ[支払いポリシー][coldcard ccc]の追加サポートと、 + [機密データ共有][coldcard kt]のための新機能が含まれています。 + +- **Payjoinを使用したトランザクションのバッチ処理:** + [Private Pond][private pond post]は、Payjoinを使用して + 手数料の少ない小規模なトランザクションを生成する[トランザクションバッチ処理][topic payment batching]サービスの + [実験的な実装][private pond github]です。 + +- **JoinMarket Fidelity Bond Simulator:** + [JoinMarket Fidelity Bond Simulator][jmfbs github]は、 + JoinMarketの参加者が[Fidelity Bond][news161 fb]に基づいて + 市場でのパフォーマンスをシミュレーションするためのツールを提供します。 + +- **Bitcoin opcodeのドキュメント化:** + [Opcode Explained][opcode explained website]では、Bitcoinスクリプトの各opcodeがドキュメント化されています。 + +- **Bitkeyのコードのオープンソース化:** + ハードウェア署名デバイスBitkeyは、非商用利用向けに[ソースコード][bitkey github]を + オープンソース化すること[発表しました][bitkey blog] + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [LND 0.19.0-beta][]は、この人気のLNノードの最新のメジャーリリースです。 + これには、協調クローズにおける新しいRBFベースの手数料引き上げを含む多くの[改善][lnd rn]や + バグ修正が含まれています。 + +- [Core Lightning 25.05rc1][]は、この人気のLNノード実装の次期メジャーバージョンのリリース候補です。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Bitcoin Core #32423][]は、`rpcuser/rpcpassword`の非推奨通知を削除し、 + 設定ファイルに平文の認証情報を保存することに関するセキュリティ警告に置き換えました。 + このオプションは、複数のRPCユーザーをサポートし、cookieをハッシュする`rpcauth`が + [Bitcoin Core #7044][]で導入された際に非推奨となりました。 + また、このPRでは、両方のメソッドから取得した認証情報にランダムな16 byteのsaltを追加し、 + メモリに格納する前にハッシュします。 + +- [Bitcoin Core #31444][]は、`TxGraph`クラス（ニュースレター[#348][news348 txgraph]参照）を拡張し、 + 3つの新しいヘルパー関数を追加しました。`GetMainStagingDiagrams()`は、 + メインの手数料率ダイアグラムとステージングの手数料率ダイアグラム間のクラスターの乖離を返します。 + `GetBlockBuilder()`は、グラフチャンク（サブクラスターの手数料率でソートされたグループ）を + 手数料率の高い順に反復処理してブロックの構築を最適化します。`GetWorstMainChunk()`は、 + 排除の判断の際に、手数料率が最も低いチャンクを特定します。このPRは、 + [クラスターmempool][topic cluster mempool]プロジェクトの完全な初期実装における最終的な構成要素の1つです。 + +- [Core Lightning #8140][]は、デフォルトでチャネルバックアップの + [ピアストレージ][topic peer storage]を有効にします（ニュースレター[#238][news238 storage]参照）。 + これにより、ストレージを現在または過去のチャネルを持つピアに限定し、 + `listdatastore`/`listpeerchannels`を繰り返し呼び出す代わりに、 + バックアップとピアリストをメモリにキャッシュし、バックアップの同時アップロードの上限を2つのピアに制限し、 + 65 kBを超えるバックアップをスキップし、送信時にピアの選択をランダムにすることで、 + 大規模ノードでも実行可能になりました。 + +- [Core Lightning #8136][]は、最近の[BOLTs #1215][]仕様更新にあわせて、 + アナウンスの署名の交換を6ブロック後ではなくチャネルの準備ができた時に行われるようになりました。 + [チャネルのアナウンス][topic channel announcements]に6ブロック待つ必要があるのは変わっていません。 + +- [Core Lightning #8266][]は、Recklessプラグインマネージャー（ニュースレター[#226][news226 reckless]参照）に + `update`コマンドを追加します。このコマンドは、指定されたプラグイン、 + または指定されていない場合はインストール済みのすべてのプラグイン（ + 固定のGitタグまたはコミットからインストールされたものは除く）を更新します。 + またこのPRは、`install`コマンドを拡張し、プラグイン名に加えて、 + ソースパスまたはURLからも取得できるようにしています。 + +- [Core Lightning #8021][]は、リモートのファンディング鍵のローテンションを修正することで、 + チャネルの再確立時に`splice_locked`を再送信することで元々見逃していたケースをカバーし（ニュースレター[#345][news345 + splicing]参照）、コミットメント署名メッセージが特定の順序で到着するという要件を緩和し、 + スプライシング[RBF][topic rbf]トランザクションの受け取りと開始を可能にし、 + 必要に応じて送信[PSBT][topic psbt]をバージョン2に自動変換するなど、 + Eclairとの[スプライシング][topic splicing]の相互運用（ニュースレター[#331][news331 interop]参照）を完成させました。 + また、その他のリファクタリングも行われています。 + +- [Core Lightning #8226][]は、新しい`signmessagewithkey` RPCコマンドを追加することで、 + [BIP137][]を実装しました。このコマンドにより、ユーザーはBitcoinアドレスを指定することで、 + ウォレット内の任意の鍵でメッセージに署名できます。これまでは、Core Lightningの鍵でメッセージに署名するには、 + 外部ライブラリで秘密鍵を抽出し、Bitcoin Coreでメッセージに署名する必要がありました。 + +- [LND #9801][]では、新しい`--no-disconnect-on-pong-failure`オプションが追加されました。 + このオプションは、pong応答が遅延または不一致の場合にピアを切断するかどうかを制御します。 + デフォルトではfalseに設定されており、pongメッセージの失敗時にピアを切断するLNDの現在の動作が維持されます + （ニュースレター[#275][news275 ping]参照）。trueに設定すると、LNDはイベントをログに記録するだけです。 + このPRでは、ping watchdogをリファクタリングし、切断が抑制された場合もループを継続するようにしました。 + +{% include snippets/recap-ad.md when="2025-05-27 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32423,31444,8140,8136,8266,8021,8226,9801,7044,1215" %} +[lnd 0.19.0-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta +[sources]: /ja/internal/sources/ +[lnd rn]: https://github.com/lightningnetwork/lnd/blob/master/docs/release-notes/release-notes-0.19.0.md +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[news348 txgraph]: /ja/newsletters/2025/04/04/#bitcoin-core-31363 +[news238 storage]: /ja/newsletters/2023/02/15/#core-lightning-5361 +[news226 reckless]: /ja/newsletters/2022/11/16/#core-lightning-5647 +[news331 interop]: /ja/newsletters/2024/11/29/#core-lightning-7719 +[news345 splicing]: /ja/newsletters/2025/03/14/#eclair-3007 +[news275 ping]: /ja/newsletters/2023/11/01/#lnd-7828 +[cake wallet 4.28.0]: https://github.com/cake-tech/cake_wallet/releases/tag/v4.28.0 +[cake blog]: https://blog.cakewallet.com/bitcoin-privacy-takes-a-leap-forward-cake-wallet-introduces-payjoin-v2/ +[sparrow 2.2.0]: https://github.com/sparrowwallet/sparrow/releases/tag/2.2.0 +[safe wallet github]: https://github.com/andreasgriffin/bitcoin-safe +[safe wallet 1.3.0]: https://github.com/andreasgriffin/bitcoin-safe/releases/tag/1.3.0 +[coldcard blog]: https://blog.coinkite.com/ccc-and-keyteleport/ +[coldcard ccc]: https://coldcard.com/docs/coldcard-cosigning/ +[coldcard kt]: https://github.com/Coldcard/firmware/blob/master/docs/key-teleport.md +[private pond post]: https://njump.me/naddr1qvzqqqr4gupzqg42s9gsae3lu2cketskuzfp778fh2vg9c5x3elx8ttdpzhfkk25qq2nv5nzddgxxdjtd4u9vwrdv939vmnswfzk6j85dxk +[private pond github]: https://github.com/Kukks/PrivatePond +[jmfbs github]: https://github.com/m0wer/joinmarket-fidelity-bond-simulator +[news161 fb]: /ja/newsletters/2021/08/11/#implementation-of-fidelity-bonds-fidelity-bond +[opcode explained website]: https://opcodeexplained.com/ +[bitkey blog]: https://x.com/BEN0WHERE/status/1918073429791785086 +[bitkey github]: https://github.com/proto-at-block/bitkey \ No newline at end of file From 0aae29f014efda0032fdd24ee64ba8862dc43c18 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Sat, 24 May 2025 15:46:01 +0200 Subject: [PATCH 029/278] Newsletter 355 german (#2328) --- .../de/newsletters/2025-05-23-newsletter.md | 143 ++++++++++++++++++ 1 file changed, 143 insertions(+) create mode 100644 _posts/de/newsletters/2025-05-23-newsletter.md diff --git a/_posts/de/newsletters/2025-05-23-newsletter.md b/_posts/de/newsletters/2025-05-23-newsletter.md new file mode 100644 index 0000000000..5dd56ad04c --- /dev/null +++ b/_posts/de/newsletters/2025-05-23-newsletter.md @@ -0,0 +1,143 @@ +--- +title: 'Bitcoin Optech Newsletter #355' +permalink: /de/newsletters/2025/05/23/ +name: 2025-05-23-newsletter-de +slug: 2025-05-23-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche enthält unsere regulären Abschnitte mit Beschreibungen von Änderungen an Diensten und Client-Software, Ankündigungen neuer Veröffentlichungen und Release-Kandidaten sowie Zusammenfassungen wichtiger Änderungen an beliebter Bitcoin-Infrastruktursoftware. + +## Nachrichten + +*In dieser Woche wurden keine bedeutenden Nachrichten in unseren [Quellen][] gefunden.* + +## Änderungen an Diensten und Client-Software + +*In dieser monatlichen Rubrik stellen wir interessante Aktualisierungen von Bitcoin-Wallets und -Diensten vor.* + +- **Cake Wallet fügt Unterstützung für Payjoin v2 hinzu:** + Cake Wallet [v4.28.0][cake wallet 4.28.0] fügt [die Möglichkeit][cake blog] hinzu, + Zahlungen mit dem [Payjoin][topic payjoin] v2-Protokoll zu empfangen. + +- **Sparrow fügt Pay-to-Anchor-Funktionen hinzu:** + Sparrow [2.2.0][sparrow 2.2.0] zeigt [Pay-to-Anchor (P2A)][topic ephemeral anchors]-Outputs an und kann diese senden. + +- **Safe Wallet 1.3.0 veröffentlicht:** + [Safe Wallet][safe wallet github] ist eine Desktop-Multisig-Wallet mit Unterstützung für Hardware-Signiergeräte, + die in Version [1.3.0][safe wallet 1.3.0] [CPFP][topic cpfp] Fee-Bumping für eingehende Transaktionen hinzugefügt hat. + +- **COLDCARD Q v1.3.2 veröffentlicht:** + Der [v1.3.2 Release][coldcard blog] von COLDCARD Q umfasst zusätzliche [Unterstützung für Multisig-Ausgaberichtlinien][coldcard ccc] + und neue Funktionen zum [Teilen sensibler Daten][coldcard kt]. + +- **Transaktions-Batching mit Payjoin:** + [Private Pond][private pond post] ist eine [experimentelle Implementierung][private pond github] + eines [Transaktions-Batching][topic payment batching]-Dienstes, der Payjoin verwendet, + um kleinere Transaktionen mit geringeren Gebühren zu generieren. + +- **JoinMarket Fidelity Bond Simulator:** + Der [JoinMarket Fidelity Bond Simulator][jmfbs github] bietet Werkzeuge für JoinMarket-Teilnehmer, + um ihre Leistung im Markt auf Basis von [Fidelity Bonds][news161 fb] zu simulieren. + +- **Bitcoin-Opcodes dokumentiert:** + Die Website [Opcode Explained][opcode explained website] dokumentiert jeden Bitcoin-Script-Opcode. + +- **Bitkey-Code als Open Source veröffentlicht:** + Das Bitkey Hardware-Signiergerät [hat angekündigt][bitkey blog], dass ihr [Quellcode][bitkey github] + für nicht-kommerzielle Nutzungen als Open Source verfügbar ist. + +## Veröffentlichungen und Release-Kandidaten + +_Neue Veröffentlichungen und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie ein Upgrade auf neue Veröffentlichungen oder helfen Sie bei der Überprüfung von Release-Kandidaten._ + +- [LND 0.19.0-beta][] ist die neueste Hauptversion dieses beliebten LN-Knotens. + Sie enthält viele [Verbesserungen][lnd rn] und Fehlerbehebungen, + einschließlich neuem [RBF][topic rbf]-basierten Fee-Bumping für kooperative Schließungen. + +- [Core Lightning 25.05rc1][] ist ein Release-Kandidat für die nächste Hauptversion + dieser beliebten LN-Knoten-Implementierung. + +## Erwähnenswerte Code- und Dokumentationsänderungen + +_Nennenswerte kürzliche Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und [BINANAs][binana repo]._ + +- [Bitcoin Core #32423][] entfernt den Hinweis, dass `rpcuser/rpcpassword` als veraltet markiert ist, und ersetzt ihn durch eine Sicherheitswarnung bezüglich der Speicherung von Klartext-Anmeldedaten in der Konfigurationsdatei. Diese Option wurde ursprünglich als veraltet markiert, als `rpcauth` + in [Bitcoin Core #7044][] eingeführt wurde, welches mehrere RPC-Benutzer unterstützt und + seinen Cookie hasht. Der PR fügt außerdem ein zufälliges 16-Byte-Salt zu Anmeldedaten aus + beiden Methoden hinzu und hasht diese, bevor sie im Speicher gespeichert werden. + +- [Bitcoin Core #31444][] erweitert die `TxGraph`-Klasse (siehe Newsletter [#348][news348 txgraph]) + um drei neue Hilfsfunktionen: `GetMainStagingDiagrams()` gibt die Abweichungen von Clustern + zwischen den Haupt- und Staging-Feerate-Diagrammen zurück, `GetBlockBuilder()` iteriert durch + Graph-Chunks (nach Feerate sortierte Teilcluster-Gruppierungen) von höchster bis niedrigster + Feerate für optimierte Blockerstellung, und `GetWorstMainChunk()` identifiziert den Chunk mit + der niedrigsten Feerate für Entscheidungen zur Räumung. Dieser PR ist einer der letzten Bausteine + der vollständigen ersten Implementierung des [Cluster-Mempool][topic cluster mempool]-Projekts. + +- [Core Lightning #8140][] aktiviert standardmäßig die [Peer-Speicherung][topic peer storage] von Kanal-Sicherungen (siehe Newsletter [#238][news238 storage]) und macht sie für große Knoten praktikabel, indem die Speicherung auf Peers mit aktuellen oder früheren Kanälen begrenzt wird, Daten im Speicher zwischengespeichert werden anstatt wiederholte `listdatastore`/`listpeerchannels`-Aufrufe zu tätigen, gleichzeitige Uploads auf zwei Peers begrenzt werden, Daten größer als 65 kB übersprungen werden und beim Senden eine zufällige Auswahl der Peers getroffen wird. + +- [Core Lightning #8136][] aktualisiert den Austausch von Ankündigungssignaturen so, dass + er stattfindet, wenn der Kanal bereit ist, anstatt nach sechs Blöcken, um mit der kürzlichen + [BOLTs #1215][] Spezifikationsaktualisierung übereinzustimmen. Es ist immer noch erforderlich, + sechs Blöcke zu warten, um den [Kanal anzukündigen][topic channel announcements]. + +- [Core Lightning #8266][] fügt einen `update`-Befehl zum Reckless-Plugin-Manager hinzu + (siehe Newsletter [#226][news226 reckless]), der ein bestimmtes Plugin oder alle installierten + Plugins aktualisiert, wenn keines angegeben ist, außer solche, die von einem festen Git-Tag + oder -Commit installiert wurden. Dieser PR erweitert auch den `install`-Befehl, um einen + Quellpfad oder eine URL zusätzlich zu einem Plugin-Namen zu akzeptieren. + +- [Core Lightning #8021][] finalisiert die [Splicing][topic splicing]-Interoperabilität mit + Eclair (siehe Newsletter [#331][news331 interop]), indem die Rotation der Remote-Funding-Keys + korrigiert wird, `splice_locked` bei der Kanal-Wiederherstellung erneut gesendet wird, um Fälle + abzudecken, in denen es ursprünglich verpasst wurde (siehe Newsletter [#345][news345 splicing]), + die Anforderung gelockert wird, dass commitment-signed-Nachrichten in einer bestimmten Reihenfolge + ankommen müssen, das Empfangen und Initiieren von Splice-[RBF][topic rbf]-Transaktionen + ermöglicht wird, ausgehende [PSBTs][topic psbt] bei Bedarf automatisch in Version 2 + konvertiert werden und andere Refactoring-Änderungen vorgenommen werden. + +- [Core Lightning #8226][] implementiert [BIP137][] durch Hinzufügen eines neuen + `signmessagewithkey`-RPC-Befehls, der es Benutzern ermöglicht, Nachrichten mit einem + beliebigen Schlüssel aus der Wallet zu signieren, indem eine Bitcoin-Adresse angegeben wird. + Früher erforderte das Signieren einer Nachricht mit einem Core Lightning-Schlüssel, + den xpriv und den Schlüsselindex zu finden, den privaten Schlüssel mit einer externen + Bibliothek abzuleiten und dann die Nachricht mit Bitcoin Core zu signieren. + +- [LND #9801][] fügt eine neue Option `--no-disconnect-on-pong-failure` hinzu, die steuert, + ob ein Peer getrennt wird, wenn eine Pong-Antwort verspätet oder nicht übereinstimmend ist. + Diese Option ist standardmäßig auf false gesetzt, wodurch das aktuelle Verhalten von LND + beibehalten wird, sich bei einem Pong-Nachrichtenfehler von einem Peer zu trennen + (siehe Newsletter [#275][news275 ping]); andernfalls würde LND das Ereignis nur protokollieren. + Der PR refaktoriert den Ping-Watchdog, um seine Schleife fortzusetzen, wenn die Trennung + unterdrückt wird. + +{% include snippets/recap-ad.md when="2025-05-27 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32423,31444,8140,8136,8266,8021,8226,9801,7044,1215" %} +[lnd 0.19.0-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta +[Quellen]: /en/internal/sources/ +[lnd rn]: https://github.com/lightningnetwork/lnd/blob/master/docs/release-notes/release-notes-0.19.0.md +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[news348 txgraph]: /de/newsletters/2025/04/04/#bitcoin-core-31363 +[news238 storage]: /en/newsletters/2023/02/15/#core-lightning-5361 +[news226 reckless]: /en/newsletters/2022/11/16/#core-lightning-5647 +[news331 interop]: /en/newsletters/2024/11/29/#core-lightning-7719 +[news345 splicing]: /de/newsletters/2025/03/14/#eclair-3007 +[news275 ping]: /en/newsletters/2023/11/01/#lnd-7828 +[cake wallet 4.28.0]: https://github.com/cake-tech/cake_wallet/releases/tag/v4.28.0 +[cake blog]: https://blog.cakewallet.com/bitcoin-privacy-takes-a-leap-forward-cake-wallet-introduces-payjoin-v2/ +[sparrow 2.2.0]: https://github.com/sparrowwallet/sparrow/releases/tag/2.2.0 +[safe wallet github]: https://github.com/andreasgriffin/bitcoin-safe +[safe wallet 1.3.0]: https://github.com/andreasgriffin/bitcoin-safe/releases/tag/1.3.0 +[coldcard blog]: https://blog.coinkite.com/ccc-and-keyteleport/ +[coldcard ccc]: https://coldcard.com/docs/coldcard-cosigning/ +[coldcard kt]: https://github.com/Coldcard/firmware/blob/master/docs/key-teleport.md +[private pond post]: https://njump.me/naddr1qvzqqqr4gupzqg42s9gsae3lu2cketskuzfp778fh2vg9c5x3elx8ttdpzhfkk25qq2nv5nzddgxxdjtd4u9vwrdv939vmnswfzk6j85dxk +[private pond github]: https://github.com/Kukks/PrivatePond +[jmfbs github]: https://github.com/m0wer/joinmarket-fidelity-bond-simulator +[news161 fb]: /en/newsletters/2021/08/11/#implementation-of-fidelity-bonds +[opcode explained website]: https://opcodeexplained.com/ +[bitkey blog]: https://x.com/BEN0WHERE/status/1918073429791785086 +[bitkey github]: https://github.com/proto-at-block/bitkey From 222280462e95b2dcf4a95268cf36f8d2f39543c2 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sat, 24 May 2025 16:03:56 +0200 Subject: [PATCH 030/278] Newsletter 353 translate in French (#2312) --- .../fr/newsletters/2025-05-09-newsletter.md | 202 ++++++++++++++++++ 1 file changed, 202 insertions(+) create mode 100644 _posts/fr/newsletters/2025-05-09-newsletter.md diff --git a/_posts/fr/newsletters/2025-05-09-newsletter.md b/_posts/fr/newsletters/2025-05-09-newsletter.md new file mode 100644 index 0000000000..52a18945d8 --- /dev/null +++ b/_posts/fr/newsletters/2025-05-09-newsletter.md @@ -0,0 +1,202 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #353' +permalink: /fr/newsletters/2025/05/09/ +name: 2025-05-09-newsletter-fr +slug: 2025-05-09-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine décrit une vulnérabilité théorique de défaillance de consensus +récemment découverte et renvoie à une proposition pour éviter la réutilisation des chemins de +portefeuille BIP32. Sont également incluses nos sections régulières résumant une +réunion du Bitcoin Core PR Review Club, annonçant des mises à jour et des versions candidates, +et décrivant les changements notables dans les projets d'infrastructure Bitcoin populaires. + +## Nouvelles + +- **Vulnérabilité de défaillance de consensus BIP30 :** Ruben Somsen a [posté][somsen bip30] sur la + liste de diffusion Bitcoin-Dev à propos d'une défaillance de consensus théorique qui pourrait + survenir maintenant que les points de contrôle ont été retirés de Bitcoin Core (voir le [Bulletin + #346][news346 checkpoints]). En bref, les transactions coinbase des blocs 91722 et 91812 sont + [dupliquées][topic duplicate transactions] dans les blocs 91880 et 91842. [BIP30][] spécifie que ces + deux derniers blocs devraient être traités de la manière dont la version historique de Bitcoin Core + les a traités en 2010, c'est-à-dire en écrasant les entrées coinbase antérieures dans l'ensemble + UTXO avec les duplicatas ultérieurs. Cependant, Somsen note qu'un réordonnancement de l'un ou des + deux blocs ultérieurs résulterait dans le retrait de l'entrée dupliquée (ou des entrées) de + l'ensemble UTXO, le laissant également dépourvu des entrées antérieures en raison de l'écrasement. + Mais, un nœud nouvellement démarré qui n'a jamais vu les transactions dupliquées aurait toujours les + transactions antérieures, lui donnant un ensemble UTXO différent qui pourrait entraîner une + défaillance de consensus si l'une des deux transactions est dépensée. + + Ce n'était pas un problème lorsque Bitcoin Core avait des points de contrôle car ils exigeaient que + les quatre blocs mentionnés ci-dessus fassent partie de la meilleure blockchain. Ce n'est pas + vraiment un problème maintenant, sauf dans un cas théorique où le mécanisme de sécurité de preuve de + travail de Bitcoin se brise. Plusieurs solutions possibles ont été discutées, telles que coder en + dur une logique de cas spéciaux supplémentaires pour ces deux exceptions. + +- **Éviter la réutilisation du chemin BIP32 :** Kevin Loaec a [posté][loaec bip32reuse] sur Delving + Bitcoin pour discuter des options permettant d'éviter que le même chemin de portefeuille + [BIP32][topic bip32] soit utilisé avec différents portefeuilles, ce qui pourrait conduire à une + perte de confidentialité en raison du [lien de sortie][topic output linking] et une perte théorique + de sécurité (par exemple, en raison de [l'informatique quantique][topic quantum resistance]). Il a + suggéré trois approches possibles : utiliser un chemin aléatoire, utiliser un chemin basé sur la + date de création du portefeuille, et utiliser un chemin basé sur un compteur incrémentiel. Il a + recommandé l'approche basée sur la date de création. + + Il a également recommandé d'abandonner la plupart des éléments de chemin [BIP48][] comme inutiles en + raison de l'utilisation de plus en plus répandue des portefeuilles avec des [descripteurs][topic + descriptors], en particulier pour les portefeuilles multisig et les portefeuilles à script complexe. + Cependant, Salvatore Ingala a [répondu][ingala bip48] pour suggérer de conserver la partie _type de + monnaie_ du chemin BIP48 car elle aide à garantir que les clés utilisées avec différentes + cryptomonnaies sont conservées séparées, ce qui est appliqué par certains dispositifs de signature + matérielle. + +## Bitcoin Core PR Review Club + +*Dans cette section mensuelle, nous résumons une récente réunion du [Bitcoin Core PR Review Club][], +mettant en lumière certaines des questions importantes et des réponses. Cliquez +sur une question ci-dessous pour voir un résumé de la réponse donnée lors de la réunion.* + +[L'ajout d'un exécutable wrapper bitcoin][review club 31375] est une PR par [ryanofsky][gh +ryanofsky] qui introduit un nouveau binaire `bitcoin` qui peut être utilisé pour découvrir et lancer +les différents binaires de Bitcoin Core. + +Bitcoin Core v29 a été livré avec 7 binaires (par exemple, `bitcoind`, `bitcoin-qt` et +`bitcoin-cli`), mais ce nombre devrait [augmenter][Bitcoin Core #30983] à l'avenir lorsque les +binaires [multiprocess][multiprocess design] seront également distribués. Le nouveau wrapper +`bitcoin` mappe les commandes (par exemple, `gui`) au bon binaire monolithique (`bitcoin-qt`) ou +multiprocessus (`bitcoin-gui`). En plus de la découvrabilité, le wrapper offre également une +compatibilité vers l'avant, de sorte que les binaires peuvent être réorganisés sans que l'interface +utilisateur ne change. + +Avec cette PR, un utilisateur peut lancer Bitcoin Core avec `bitcoin daemon` ou `bitcoin gui`. +Lancer directement les binaires `bitcoind` ou `bitcoin-qt` reste possible et n'est pas affecté par +cette PR. + +{% include functions/details-list.md + q0="D'après le problème #30983, quatre stratégies de wrapper ont été listées. Quels inconvénients + spécifiques de l'approche « side-binaries » cette PR aborde-t-elle ?" + a0="L'approche des side-binaries supposée par cette PR implique de libérer les nouveaux binaires + multiprocessus aux côtés des binaires monolithiques existants. Avec autant de binaires, cela peut + être déroutant pour les utilisateurs de trouver et de comprendre le binaire dont ils ont besoin pour + leur objectif. Cette PR élimine une grande partie de la confusion en fournissant un point d'entrée + unique, avec un aperçu des options et une chaîne d'aide. Un examinateur a suggéré l'ajout d'une + recherche floue pour faciliter encore plus cela." + a0link="https://bitcoincore.reviews/31375#l-40" + q1="`GetExePath()` n'utilise pas `readlink(\"/proc/self/exe\")` sur Linux même si cela serait plus + direct. Quels avantages l'implémentation actuelle offre-t-elle ? Quels cas particuliers + pourrait-elle manquer ?" + a1="Il peut y avoir d'autres plateformes non-Windows qui n'ont pas le système de fichiers proc. À + part cela, ni l'auteur ni les invités n'ont pu identifier d'inconvénients à l'utilisation de + procfs." + a1link="https://bitcoincore.reviews/31375#l-71" + q2="Dans `ExecCommand`, expliquez le but du booléen `fallback_os_search`. Dans quelles circonstances + vaut-il mieux éviter de laisser l'OS rechercher le binaire sur le `PATH` ?" + a2="Si cela semble que l'exécutable wrapper a été invoqué par chemin (par exemple, + \"/build/bin/bitcoin\") plutôt que par recherche (par exemple, \"bitcoin\"), il est supposé que + l'utilisateur utilise une construction locale et `fallback_os_search` est défini sur `false`. Ce + booléen est introduit pour éviter de mélanger involontairement des binaires de différentes sources. + Par exemple, si l'utilisateur n'a pas construit localement `gui`, alors `/build/bin/bitcoin gui` ne + devrait pas retomber sur le `bitcoin-gui` installé sur le système. L'auteur envisage de supprimer + entièrement la recherche `PATH`, et les retours des utilisateurs seraient utiles." + a2link="https://bitcoincore.reviews/31375#l-75" + q3="Le wrapper ne recherche `${prefix}/libexec` que lorsqu'il détecte qu'il est exécuté depuis un + répertoire `bin/` installé. Pourquoi ne pas toujours rechercher `libexec` ?" + a3="Le wrapper doit être prudent quant aux chemins qu'il tente d'exécuter, et encourager les + dispositions standard `PREFIX/{bin,libexec}`, et non encourager les wrapper à créer des + dispositions non standard ou à fonctionner lorsque les binaires sont arrangés de manières + inattendues." + a3link="https://bitcoincore.reviews/31375#l-75" + q4="La PR ajoute une exemption dans `security-check.py` parce que le wrapper ne contient pas + d'appels `glibc` fortifiés. Pourquoi ne les contient-il pas, et l'ajout d'un simple `printf` à + `bitcoin.cpp` briserait-il les constructions reproductibles sous les règles actuelles ?" + a4="Le binaire du wrapper est si simple qu'il ne contient aucun appel pouvant être fortifié. S'il en + contient à l'avenir, l'exemption dans security-check.py peut être retirée." + a4link="https://bitcoincore.reviews/31375#l-117" +%} + +## Mises à jour et versions candidates + +_Nouvelles versions et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de mettre à niveau vers les nouvelles versions ou d'aider à tester les versions candidates._ + +- [LND 0.19.0-beta.rc4][] est un candidat à la sortie pour ce nœud LN populaire. L'une des + principales améliorations qui pourrait probablement nécessiter des tests est le nouveau bumping de + frais basé sur RBF pour les fermetures coopératives. + +## Changements notables dans le code et la documentation + +_Changements récents notables dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning +repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], +[Interface de Portefeuille Matériel (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [Serveur +BTCPay][btcpay server repo], [BDK][bdk repo], [Propositions d'Amélioration de Bitcoin (BIPs)][bips +repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Inquisition Bitcoin][bitcoin +inquisition repo], et [BINANAs][binana repo]._ + +- [Core Lightning #8227][] ajoute des plugins `lsps-client` et `lsps-service` basés sur Rust qui + implémentent un protocole de communication entre les nœuds LSP et leurs clients, en utilisant un + format JSON-RPC sur les messages peer-to-peer [BOLT8][], comme spécifié dans [BLIP50][] (voir + le Bulletin [#335][news335 blip50]). Cela pose les bases pour l'implémentation des demandes de + liquidité entrantes comme spécifié dans [BLIP51][], et de [canaux JIT][topic jit channels] comme + spécifié dans [BLIP52][]. + +- [Core Lightning #8162][] met à jour la gestion des ouvertures de canaux en attente initiées par + les pairs en les conservant indéfiniment, jusqu'à une limite des 100 plus récents. Auparavant, les + ouvertures de canaux non confirmées étaient oubliées après 2016 blocs. De plus, les canaux fermés + sont maintenant conservés en mémoire pour permettre à un nœud de répondre à un message + `channel_reestablish` d'un pair. + +- [Core Lightning #8166][] améliore la commande RPC `wait` en remplaçant son unique objet `details` + par des objets spécifiques aux sous-systèmes : `invoices`, + `forwards`, `sendpays` et [`htlcs`][topic htlc]. De plus, la commande RPC `listhtlcs` prend + désormais en charge la pagination via les nouveaux champs `created_index` et `updated_index` ainsi + que les paramètres `index`, `start` et `end`. + +- [Core Lightning #8237][] ajoute un paramètre `short_channel_id` à la commande RPC + `listpeerchannels` pour retourner uniquement un canal spécifique, s'il est fourni. + +- [LDK #3700][] ajoute un nouveau champ `failure_reason` à l'événement `HTLCHandlingFailed` pour + fournir des informations supplémentaires sur la raison de l'échec du [HTLC][topic htlc], et si la + cause était locale ou en aval. Le champ `failed_next_destination` est renommé en `failure_type` et + la variante `UnknownNextHop` est dépréciée, remplacée par la plus générale `InvalidForward`. + +- [Rust Bitcoin #4387][] refactorise la gestion des erreurs [BIP32][topic bip32] en remplaçant le + seul `bip32::Error` par des énumérations séparées pour la dérivation, le numéro/chemin de l'enfant + et l'analyse de la clé étendue. Cette PR introduit également une nouvelle variante + `DerivationError::MaximumDepthExceeded` pour les chemins dépassant 256 niveaux. Ces changements + d'API rompent la compatibilité ascendante. + +- [BIPs #1835][] met à jour [BIP48][] (voir le Bulletin [#135][news135 bip48]) pour réserver la + valeur de type de script 3 pour les dérivations [taproot][topic taproot] (P2TR) dans les + portefeuilles multisig déterministes avec le préfixe m/48', en plus des types de script P2SH-P2WSH + (1′) et P2WSH (2′) existants. + +- [BIPs #1800][] fusionne [BIP54][], qui spécifie la proposition de soft fork de nettoyage du + consensus [topic consensus cleanup] pour corriger un certain nombre de vulnérabilités de longue date + dans le protocole Bitcoin. Voir le Bulletin [#348][news348 cleanup] pour une description détaillée de + ce BIP. + +- [BOLTs #1245][] renforce [BOLT11][] en interdisant les encodages de longueur non minimale dans les + factures : les champs d'expiration (x), le [délai d'expiration CLTV][topic cltv expiry delta] pour + le dernier saut (c) et les bits de fonctionnalité (9) doivent être sérialisés en longueur minimale + sans zéros initiaux, et les lecteurs devraient rejeter toute facture contenant des zéros initiaux. + Ce changement a été motivé par des tests de fuzzing qui ont détecté que lorsque LDK resérialise des + factures non minimales en minimales (en supprimant les zéros supplémentaires), cela provoque l'échec + de la validation de la signature ECDSA de la facture. + +{% include snippets/recap-ad.md when="2025-05-13 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="8227,8162,8166,8237,3700,4387,1835,1800,1245,50,51,52,30983" %} +[lnd 0.19.0-beta.rc4]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc4 +[wuille clustrade]: https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/68 +[somsen bip30]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPv7TjZTWhgzzdps3vb0YoU3EYJwThDFhNLkf4XmmdfhbORTaw@mail.gmail.com/ +[loaec bip32reuse]: https://delvingbitcoin.org/t/avoiding-xpub-derivation-reuse-across-wallets-in-a-ux-friendly-manner/1644 +[ingala bip48]: https://delvingbitcoin.org/t/avoiding-xpub-derivation-reuse-across-wallets-in-a-ux-friendly-manner/1644/3 +[news346 checkpoints]: /fr/newsletters/2025/03/21/#bitcoin-core-31649 +[news335 blip50]: /fr/newsletters/2025/01/03/#blips-52 +[news135 bip48]: /en/newsletters/2021/07/28/#bips-1072 +[news348 cleanup]: /fr/newsletters/2025/04/04/#brouillon-de-bip-publie-pour-le-nettoyage-du-consensus +[review club 31375]: https://bitcoincore.reviews/31375 +[gh ryanofsky]: https://github.com/ryanofsky +[multiprocess design]: https://github.com/bitcoin/bitcoin/blob/master/doc/design/multiprocess.md From 26df15500a12e5ad6e42322345526214246e3b81 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Mon, 26 May 2025 00:24:55 +0200 Subject: [PATCH 031/278] Newsletter 354 translate in French (#2329) --- .../fr/newsletters/2025-05-16-newsletter.md | 147 ++++++++++++++++++ 1 file changed, 147 insertions(+) create mode 100644 _posts/fr/newsletters/2025-05-16-newsletter.md diff --git a/_posts/fr/newsletters/2025-05-16-newsletter.md b/_posts/fr/newsletters/2025-05-16-newsletter.md new file mode 100644 index 0000000000..25f4ab0085 --- /dev/null +++ b/_posts/fr/newsletters/2025-05-16-newsletter.md @@ -0,0 +1,147 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #354' +permalink: /fr/newsletters/2025/05/16/ +name: 2025-05-16-newsletter-fr +slug: 2025-05-16-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine décrit une vulnérabilité corrigée affectant les anciennes versions de +Bitcoin Core. Sont également incluses nos sections régulières résumant les récentes discussions sur +la modification des règles de consensus de Bitcoin, annonçant des mises à jour et des versions candidates, +et décrivant les changements notables dans les projets d'infrastructure Bitcoin populaires. + +## Nouvelles + +- **Divulgation de vulnérabilité affectant les anciennes versions de Bitcoin Core :** + Antoine Poinsot a [publié][poinsot addrvuln] sur la liste de diffusion Bitcoin-Dev pour annoncer une + vulnérabilité affectant les versions de Bitcoin Core antérieures à 29.0. La vulnérabilité a été + initialement [divulguée de manière responsable][topic responsible disclosures] par Eugene Siegel + avec une autre vulnérabilité étroitement liée décrite dans le [Bulletin #314][news314 excess + addr]. Un attaquant pourrait envoyer un nombre excessif d'avertissement d'adresse de nœud pour forcer un + identifiant 32 bits à déborder, entraînant un crash du nœud. Cela a été partiellement atténué en + limitant le nombre de mises à jour à une par pair toutes les dix secondes, ce qui, pour la limite + par défaut d'environ 125 pairs, empêcherait le débordement à moins que le nœud ne soit + continuellement attaqué pendant plus de 10 ans. La vulnérabilité a été complètement corrigée en + utilisant des identifiants 64 bits, à partir de la version de Bitcoin Core 29.0 sortie le mois + dernier. + +## Changement de consensus + +_Une section mensuelle résumant les propositions et discussions sur le changement des règles de +consensus de Bitcoin._ + +- **Proposition de BIP pour l'arithmétique 64 bits dans Script :** Chris Stewart a [publié][stewart + bippost] un [projet de BIP][64bit bip] sur la liste de diffusion Bitcoin-Dev qui propose de mettre à + niveau les opcodes existants de Bitcoin pour opérer sur des valeurs numériques 64 bits. Cela fait + suite à ses recherches précédentes (voir les Bulletins [#285][news285 64bit], [#290][news290 + 64bit], et [#306][news306 64bit]). Dans un changement par rapport à certaines des discussions + précédentes, la nouvelle proposition utilise des nombres dans le même format de données compactSize + actuellement utilisé dans Bitcoin. Des [discussions][stewart inout] connexes supplémentaires ont eu + lieu dans deux [fils][stewart overflow] sur Delving Bitcoin. + +- **Opcodes proposés pour permettre les covenants récursifs via des quines :** Bram Cohen a + [posté][cohen quine] sur Delving Bitcoin pour suggérer un ensemble d'opcodes simples qui + permettraient la création de [covenants][topic covenants] récursifs via des scripts + s'autoreproduisant ([quines][]). Cohen décrit comment les opcodes pourraient être utilisés pour + créer un [coffre-fort][topic vaults] simple et mentionne un système plus avancé sur lequel il + travaille. + +- **Description des avantages pour BitVM de `OP_CTV` et `OP_CSFS` :** Robin Linus a [posté][linus + bitvm-sf] sur Delving Bitcoin à propos de plusieurs des améliorations à [BitVM][topic acc] qui + deviendraient possibles si les [OP_CTV][topic op_checktemplateverify] et [OP_CSFS][topic + op_checksigfromstack] étaient ajoutés à Bitcoin lors d'un soft fork. Les avantages + qu'il décrit incluent l'augmentation du nombre d'opérateurs sans inconvénients, "réduisant la taille + des transactions d'environ 10x" (ce qui réduit les coûts dans le pire des cas), et permettant des + peg-ins non interactifs pour certains contrats. + +## Mises à jour et versions candidates + +_Nouvelles sorties et candidats à la sortie pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de passer aux nouvelles sorties ou d'aider à tester les candidats à la sortie._ + +- [LND 0.19.0-beta.rc4][] est un candidat à la sortie pour ce nœud LN populaire. L'une des + principales améliorations qui pourrait probablement nécessiter des tests est le nouveau bumping de + frais basé sur RBF pour les fermetures coopératives. + +## Changements notables dans le code et la documentation + +_Changements récents notables dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning +repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], +[Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], +[Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin +inquisition repo], et [BINANAs][binana repo]._ + +- [Bitcoin Core #32155][] met à jour le mineur interne pour un [blocage temporel][topic timelocks] des + transactions coinbase en réglant le champ `nLockTime` à la hauteur du bloc actuel moins un et en + exigeant que le champ `nSequence` ne soit pas final (pour faire respecter le timelock). Bien que le + mineur intégré ne soit généralement pas utilisé sur le mainnet, sa mise à jour encourage les pools + de minage à adopter ces changements tôt dans leur propre logiciel en préparation pour le soft fork + de [nettoyage du consensus][topic consensus cleanup] proposé dans [BIP54][]. Le timelock des + transactions coinbase résout la vulnérabilité des [transactions dupliquées][topic duplicate + transactions] et permettrait de lever les vérifications coûteuses de [BIP30][]. + +- [Bitcoin Core #28710][] supprime le reste du code, de la documentation et des tests du + portefeuille legacy. Cela inclut les RPCs uniquement legacy, tels que `importmulti`, `sethdseed`, + `addmultisigaddress`, `importaddress`, `importpubkey`, `dumpwallet`, `importwallet`, et + `newkeypool`. Comme dernière étape pour la suppression du portefeuille legacy, la dépendance à + BerkeleyDB et les fonctions associées sont également supprimées. Cependant, le strict minimum du + code legacy et un parser BDB indépendant (voir le Bulletin [#305][news305 bdb]) sont conservés afin + de réaliser la migration du portefeuille vers les portefeuilles avec [descripteurs][topic descriptors]. + +- [Core Lightning #8272][] désactive la recherche de pairs de secours par DNS seed du daemon de + connexion `connectd` pour résoudre les problèmes de blocage d'appel causés par des DNS seeds hors + ligne. + +- [LND #8330][] ajoute une petite constante (1/c) au modèle de probabilité bimodal de recherche de + chemin pour aborder l'instabilité numérique. Dans les cas limites où le calcul échouerait autrement + en raison d'erreurs d'arrondi et produirait une probabilité nulle, cette régularisation fournit une + solution de repli en faisant revenir le modèle à une distribution uniforme. Cela résout les bugs de + normalisation qui se produisent dans des scénarios impliquant de très grands canaux ou des canaux qui + ne correspondent pas à une distribution bimodale. De plus, le modèle évite désormais les calculs de + probabilité inutiles et corrige automatiquement les observations de liquidité de canal obsolètes et + les informations historiques contradictoires. + +- [Rust Bitcoin #4458][] remplace la structure `MtpAndHeight` par une paire explicite du `BlockMtp` + nouvellement ajouté et du `BlockHeight` déjà existant, permettant une meilleure modélisation de la + hauteur de bloc et des valeurs de Median Time Past (MTP) dans les [timelocks][topic timelocks] + relatifs. Contrairement à `locktime::absolute::MedianTimePast`, qui est limité à des valeurs + supérieures à 500 millions (approximativement après 1985), `BlockMtp` peut représenter n'importe + quel timestamp 32 bits. Cela le rend adapté pour des cas limites théoriques, tels que des chaînes + avec des timestamps inhabituels. Cette mise à jour introduit également `BlockMtpInterval`, et + renomme `BlockInterval` en `BlockHeightInterval`. + +- [BIPs #1848][] met à jour le statut de [BIP345][] en `Withdrawn`, car l'auteur [croit][obeirne + vaultwithdraw] que son opcode `OP_VAULT` proposé a été supplanté par + [`OP_CHECKCONTRACTVERIFY`][topic matt] (OP_CCV), un design de [vault][topic vaults] plus général et + un nouveau type de [covenant][topic covenants]. + +- [BIPs #1841][] fusionne [BIP172][], qui propose de définir formellement l'unité de base + indivisible de Bitcoin comme un “satoshi”, reflétant l'usage répandu actuel et aidant à standardiser + la terminologie à travers les applications et la documentation. + +- [BIPs #1821][] fusionne [BIP177][], qui propose de redéfinir “bitcoin” pour représenter l'unité + indivisible la plus petite (communément appelée 1 satoshi), plutôt que 100 000 000 unités. La + proposition argue que l'alignement de la terminologie avec l'unité de base réelle réduirait la + confusion causée par les conventions décimales arbitraires. + +{% include snippets/recap-ad.md when="2025-05-20 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32155,28710,8272,8330,4458,1848,1841,1821" %} +[lnd 0.19.0-beta.rc4]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc4 +[news314 excess addr]: /fr/newsletters/2024/08/02/#crash-a-distance-en-envoyant-des-messages-addr-excessifs +[stewart bippost]: https://groups.google.com/g/bitcoindev/c/j1zEky-3QEE +[64bit bip]: https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki +[news285 64bit]: /fr/newsletters/2024/01/17/#proposition-de-soft-fork-pour-l-arithmetique-sur-64-bits +[news290 64bit]: /fr/newsletters/2024/02/21/#discussion-continue-sur-l-arithmetique-64-bits-et-l-opcode-op-inout-amount +[news306 64bit]: /fr/newsletters/2024/06/07/#mises-a-jour-de-la-proposition-de-soft-fork-pour-l-arithmetique-64-bits +[stewart inout]: https://delvingbitcoin.org/t/op-inout-amount/549/4 +[stewart overflow]: https://delvingbitcoin.org/t/overflow-handling-in-script/1549 +[poinsot addrvuln]: https://mailing-list.bitcoindevs.xyz/bitcoindev/EYvwAFPNEfsQ8cVwiK-8v6ovJU43Vy-ylARiDQ_1XBXAgg_ZqWIpB6m51fAIRtI-rfTmMGvGLrOe5Utl5y9uaHySELpya2ojC7yGsXnP90s=@protonmail.com/ +[cohen quine]: https://delvingbitcoin.org/t/a-simple-approach-to-allowing-recursive-covenants-by-enabling-quines/1655/ +[linus bitvm-sf]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/ +[quines]: https://en.wikipedia.org/wiki/Quine_(computing) +[news305 bdb]: /fr/newsletters/2024/05/31/#bitcoin-core-26606 +[obeirne vaultwithdraw]: https://delvingbitcoin.org/t/withdrawing-op-vault-bip-345/1670/ From 4f4d1f00f8ead5b3ecd6ebd4ccd51c92b3a48b51 Mon Sep 17 00:00:00 2001 From: Murch Date: Mon, 26 May 2025 13:21:28 -0700 Subject: [PATCH 032/278] Add corrections to German Newsletter 348 (#2339) * DE-348: Accept suggestions Co-authored-by: garfiel-d --- .../de/newsletters/2025-04-04-newsletter.md | 64 +++++++++---------- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/_posts/de/newsletters/2025-04-04-newsletter.md b/_posts/de/newsletters/2025-04-04-newsletter.md index 78c89b1cdb..ac93c351b3 100644 --- a/_posts/de/newsletters/2025-04-04-newsletter.md +++ b/_posts/de/newsletters/2025-04-04-newsletter.md @@ -160,7 +160,7 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu findet, denke ich, dass die Hauptmaßnahme, die Benutzer ergreifen können, darin besteht, zu einer Taproot-Wallet zu wechseln", da diese die Möglichkeit bietet, Keypath-Ausgaben unter den aktuellen Konsensregeln zu ermöglichen, einschließlich - im Fall von [Output linking][topic output linking], aber auch Widerstand gegen + des Falles von [Output linking][topic output linking], aber auch Widerstand gegen Quanten-Diebstahl, wenn Keypath-Ausgaben später deaktiviert werden. In einem separaten Thread (siehe nächster Punkt) stellt Pieter Wuille @@ -176,7 +176,7 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu (falls dies zu einem erwarteten Risiko wird). Cruz argumentiert, "indem wir eine Frist für die Migration durchsetzen, bieten wir rechtmäßigen Eigentümern eine klare, nicht verhandelbare Gelegenheit, - ihre Gelder zu sichern [...] eine erzwungene Migration mit + ihre Gelder zu sichern [...], eine erzwungene Migration mit ausreichender Vorankündigung und robusten Schutzmaßnahmen ist sowohl realistisch als auch notwendig, um die langfristige Sicherheit von Bitcoin zu schützen." @@ -192,7 +192,7 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu - *Kritik an der CTV-Motivation:* Anthony Towns [postete][towns ctvmot] eine Kritik an der in [BIP119][] beschriebenen Motivation für CTV, - die er argumentierte, durch die Hinzufügung von CTV und CSFS zu + die, wie er argumentierte, durch die Hinzufügung von CTV und CSFS zu Bitcoin untergraben würde. Einige Tage nach Beginn der Diskussion wurde BIP119 von seinem Autor aktualisiert, um den umstrittenen Text zu entfernen; @@ -201,7 +201,7 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu von BIP119 für den Referenzwert. Einige der diskutierten Themen umfassten: - *CTV+CSFS ermöglicht die Erstellung einer perpetuellen Covenant:* - CTVs Motivation sagte: "Covenants wurden historisch gesehen als nicht + CTVs Motivation sagte: "Covenants wurden aus historischer Sicht als nicht geeignet für Bitcoin angesehen, da sie zu komplex sind und das Risiko bergen, die Fungibilität der durch sie gebundenen Coins zu verringern. Dieses BIP führt eine einfache Covenant namens @@ -213,7 +213,7 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu Towns beschreibt ein Skript, das sowohl CTV als auch CSFS verwendet, und verlinkt auf eine [Transaktion][mn recursive], die es auf dem MutinyNet [Signet][topic signet] verwendet, die nur durch das Senden des gleichen - Betrags an die Skript selbst ausgegeben werden kann. + Betrags an das Skript selbst ausgegeben werden kann. Obwohl es einige Debatten über Definitionen gab, hat der Autor von CTV zuvor eine funktional identische Konstruktion als rekursive Covenant beschrieben, und Optech folgte dieser Konvention in seiner @@ -239,14 +239,14 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu - *Werkzeuge für CTV und CSFS:* Towns [notierte][towns ctvmot], dass er es schwierig fand, bestehende Werkzeuge zu verwenden, um sein rekursives Skript zu entwickeln, was auf einen Mangel - an Bereitschaft für die Bereitstellung hinweist. Osuntokun + an Einsatzbereitschaft für die Bereitstellung hinweist. Osuntokun [sagte][osuntokun enum], dass die Werkzeuge, die er verwendet, "ziemlich einfach" seien. Weder Towns noch Osuntokun erwähnten, - welche Werkzeuge sie verwendet haben. Nadav Ivgi [stelle][ivgi minsc] + welche Werkzeuge sie verwendet haben. Nadav Ivgi [stellte][ivgi minsc] ein Beispiel mit seiner [Minsc][]-Sprache vor und sagte, dass er daran arbeitet, Minsc zu verbessern, um solche Dinge einfacher zu machen. Es unterstützt Taproot, CTV, PSBT, Deskriptoren, Miniscript, pures Script, - BIP32 und mehr. Allerdings gab er zu, dass viel davon noch nicht dokumentiert ist. + BIP32 und mehr. Allerdings gab er zu, dass vieles davon noch nicht dokumentiert ist. - *Alternativen:* Towns vergleicht CTV+CSFS mit seinem Basic Bitcoin Lisp Language ([bll][topic bll]) und [Simplicity][topic simplicity], die eine alternative @@ -267,7 +267,7 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu auf Delving Bitcoin, um vorzuschlagen, CTV und CSFS zu Bitcoin hinzuzufügen, als ersten Schritt zu weiteren Änderungen, welche die Ausdrucksfähigkeit weiter erhöhen würden. Der Großteil der Diskussion konzentrierte sich auf die - Qualifizierung der möglichen Vorteile von CTV, CSFS oder beiden zusammen. + Qualifizierung der möglichen Vorteile von CTV, CSFS oder beider zusammen. Dies umfasste: - *DLCs:* Sowohl CTV als auch CSFS können einzeln die Anzahl der benötigten @@ -281,8 +281,8 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu der sagte: "DLCs haben auf Bitcoin keine bedeutende Akzeptanz erlangt, und ihre begrenzte Verwendung scheint nicht auf Leistungsbeschränkungen zurückzuführen zu sein. " Antworten verlinkten auf andere noch funktionierende DLC-Service-Provider, - einschließlich eines, der [behauptet][lava 30m], - 30 Millionen US-Dollar an Finanzierung aufgebracht zu haben. + einschließlich einem, der [behauptet][lava 30m], + 30 Millionen US-Dollar an Finanzierung beschafft zu haben. - *Vaults:* CTV vereinfacht die Implementierung von [Vaults][topic vaults], die heute auf Bitcoin mithilfe von presigned Transaktionen und (optional) @@ -296,7 +296,7 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu [rechenschaftspflichtigen Computing-Verträgen][topic acc] wie BitVM eliminieren, indem es die aktuelle Notwendigkeit ersetzt, Script-basierte Lamport-Signaturen auszuführen. CTV könnte in der Lage sein, einige zusätzliche Signaturoperationen zu - reduzieren. Poinsot [fragt][poinsot ctvcsfs1] wieder , ob es eine signifikante + reduzieren. Poinsot [fragt][poinsot ctvcsfs1] wiederum, ob es eine signifikante Nachfrage nach BitVM gibt. Gregory Sanders [antwortet][sanders bitvm], dass er es interessant finden würde, Token in beide Richtungen zu überbrücken, als Teil der geschützten [Client-seitigen Validierung][topic client-side validation] @@ -307,7 +307,7 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu Weise zu reduzieren. - *Verbesserung im Liquid-Timelock-Skript:* James O'Beirne - [weiterleitete][obeirne liquid] Kommentare von zwei Blockstream-Ingenieuren, + [leitete][obeirne liquid] Kommentare von zwei Blockstream-Ingenieuren, dass CTV, in seinen Worten, "drastisch das [Blockstream] Liquid Timelock-Fallback-Skript verbessern würde, das eine periodische Verschiebung von Coins erfordert." @@ -328,7 +328,7 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu [SIGHASH_ANYPREVOUT][topic sighash_anyprevout] (APO) implementiert hat, [bemerkt][sanders versus], dass die CTV+CSFS-Version von LN-Symmetrie nicht so funktionsreich ist wie die APO-Version und Kompromisse erfordert. - Anthony Towns [fügt hinzu][towns nonrepo], dass niemand bekanntermaßen Sanders' + Anthony Towns [fügt hinzu][towns nonrepo], dass niemand bekannterweise Sanders' experimentellen Code für APO aktualisiert hat, um ihn auf moderner Software zu verwenden und neu eingeführte Relay-Features wie [TRUC][topic v3 transaction relay] und [ephemeral Anchors][topic ephemeral anchors] zu nutzen, geschweige denn, @@ -340,7 +340,7 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu wenn ein Soft Fork es ermöglichen würde. Zitate von zwei Core Lightning-Entwicklern (die auch Co-Autoren des Papiers sind, das wir jetzt LN-Symmetrie nennen), deuteten darauf hin, dass es - für sie eine Priorität ist. Im Vergleich dazu sagte Matt Corallo, + für sie eine Priorität ist. Im Gegensatz dazu sagte Matt Corallo, der Leitende Entwickler von LDK, [zuvor][corallo eltoo], "Ich finde [LN-Symmetrie] nicht besonders interessant in Bezug auf 'wir müssen das erledigen'". @@ -350,9 +350,9 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu Benutzererfahrung sind unbestreitbar, und es ist ohne Zweifel, dass beide [Ark]-Implementierungen CTV nutzen werden, sobald es verfügbar ist." Towns [bemerkte][towns nonrepo], dass niemand Ark mit entweder APO oder - CTV für Tests implementiert hat; Roose schrieb [Code][roose ctv-ark] - dazu kurz darauf, nannte es "erstaunlich einfach" und sagte, dass es die - IntegrationsTests der bestehenden Implementierung bestanden hat. + CTV für Tests implementiert hat; Roose schrieb kurz darauf [Code][roose ctv-ark] + dazu, nannte es "erstaunlich einfach", und sagte, dass es die + Integrationstests der bestehenden Implementierung bestanden hat. Er quantifizierte einige der Verbesserungen: Wenn sie zu CTV wechseln, "könnten wir etwa 900 Zeilen Code entfernen [...] und unser eigenes Rundprotokoll auf zwei statt drei reduzieren, @@ -381,11 +381,11 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu Wenn der Empfänger online kommt, kann er wählen, was er tun möchte: - *Ausstieg nach einer Verzögerung:* Die gesamte Kette von presigned Transaktionen - wird übertragen, um die [Joinpool][topic joinpools] (genannt Ark) zu verlassen. - Dies erfordert das Warten auf die Ablaufzeit einer Timelock, die vom Ausgeber + wird übertragen, um den [Joinpool][topic joinpools] (genannt Ark) zu verlassen. + Dies erfordert das Warten auf die Ablaufzeit eines Timelocks, der vom Ausgeber vereinbart wurde. Wenn die presigned Transaktionen zu einer angemessenen Tiefe bestätigt sind, kann der Empfänger sicher sein, dass er treuhänderische Kontrolle - über die Mittel hat. Allerdings verliert er die Vorteile, die mit der Teilnahme an einer + über die Mittel hat. Allerdings verliert er die Vorteile, die mit der Teilnahme an einem Joinpool verbunden sind, wie z.B. schnelle Abwicklung und geringere Gebühren durch UTXO-Teilung. Er muss möglicherweise auch Transaktionsgebühren zahlen, um die Kette von Transaktionen zu bestätigen. @@ -420,10 +420,10 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu Ein weiteres Designziel für Ark ist es, es Teilnehmern zu ermöglichen, LN-Zahlungen zu empfangen. In seinem ursprünglichen Beitrag und einer [Antwort][roose ctv-ark-ln] beschreibt Roose, dass bestehende Teilnehmer, - die bereits Mittel innerhalb der Joinpool haben, bis zu den Kosten einer + die bereits Mittel innerhalb des Joinpools haben, bis zu den Kosten einer On-Chain-Transaktion bestraft werden können, wenn sie die erforderliche Interaktivität für den Empfang einer LN-Zahlung nicht ausführen. - Allerdings können diejenigen, die noch keine Mittel in der Joinpool haben, + Allerdings können diejenigen, die noch keine Mittel in dem Joinpool haben, nicht bestraft werden, sodass sie die interaktiven Schritte verweigern und kostenlos Probleme für ehrliche Teilnehmer verursachen können. Dies scheint effektiv zu verhindern, dass Ark-Benutzer LN-Zahlungen empfangen können, @@ -434,18 +434,18 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu Eine Ark-Runde besteht aus einer kleinen On-Chain-Transaktion, die sich auf einen Baum von Off-Chain-Transaktionen bezieht. Dies sind presigned Transaktionen im Falle von clArk, die erfordern, dass alle Ausgeber in dieser Runde für die - Signierung verfügbar sind. Wenn CTV verfügbar wäre, kann jede Zweigstelle + Signierung verfügbar sind. Wenn CTV verfügbar wäre, könnte jede Zweigstelle im Baum von Transaktionen ihre Nachfolger mithilfe von CTV ohne Signierung verpflichten. Dies ermöglicht die Erstellung von Transaktionen sogar für Teilnehmer, die zum Zeitpunkt der Erstellung der Runde nicht verfügbar sind, mit folgenden Vorteilen: - - *In-Runde nicht-interaktive Zahlungen:* Anstatt Ark-out-of-round + - *In-Runde nicht-interaktive Zahlungen:* Anstatt mit Ark-out-of-round (arkoor)-Zahlungen, kann ein Ausgeber, der bereit ist, auf die nächste Runde zu warten, den Empfänger in der Runde bezahlen. Für den Empfänger hat dies einen großen Vorteil: Sobald die Runde zu einer angemessenen Tiefe bestätigt ist, erhält er treuhänderische Kontrolle über die empfangenen - Mittel (bis das Ablaufdatum näher kommt, zu dem Zeitpunkt kann er entweder + Mittel (bis das Ablaufdatum näherkommt, zu dem Zeitpunkt kann er entweder aussteigen oder günstig aktualisieren). Anstatt auf mehrere Bestätigungen zu warten, kann der Empfänger wählen, sofort den Anreizen zu vertrauen, die durch das Ark-Protokoll für den Server geschaffen werden, um ehrlich zu operieren @@ -500,7 +500,7 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu die auf der ausgegebenen Ausgabe platziert wurden, auf die erstellte Ausgabe zu übertragen - allgemein (aber [umstritten][towns anticov]) als [Covenant][topic covenants] im Bitcoin-Jargon bezeichnet. Der Covenant kann die Erfüllung oder Modifikation der Belastung ermöglichen, - was (respektive) den Covenant beenden oder seine Bedingungen für zukünftige Iterationen modifizieren würde. + was (jeweils) den Covenant beenden oder seine Bedingungen für zukünftige Iterationen modifizieren würde. Ingala beschreibt einige der Vorteile und Nachteile dieses Ansatzes: - *Vorteile:* native Unterstützung für Taproot, erhöht nicht die Größe von @@ -569,7 +569,7 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu Er bemerkt auch, dass er "vollständig ausgestattete Vault-Implementierungen mit `OP_CCV` plus [OP_CTV][topic op_checktemplateverify] erstellt hat, die ungefähr äquivalent sind zu [...[BIP345][]...]". Darüber hinaus sei eine Version mit reduzierter Funktionalität, die nur - `OP_CCV` verwendet, als FunktionsTest in der Bitcoin Core-Implementierung von + `OP_CCV` verwendet, als Funktionstest in der Bitcoin Core-Implementierung von `OP_CCV` implementiert worden. - **Entwurf für BIP veröffentlicht für Konsens-Reinigung:** Antoine Poinsot @@ -592,7 +592,7 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu um eine Art von [Merkle-Baum-Schwachstelle][topic merkle tree vulnerabilities] zu verhindern. - Technische Antworten waren für alle Teile des Vorschlags außer zwei positiv. + Technische Antworten waren für alle Teile des Vorschlags mit Ausnahme von zwei positiv. Der erste Einwand, der in mehreren Antworten geäußert wurde, war die Ungültigmachung von 64-Byte-Transaktionen. Die Antworten wiederholten vorherige Kritik (siehe [Newsletter #319][news319 64byte]). Es gibt eine alternative Methode, @@ -600,7 +600,7 @@ _Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu einfach für leichte (SPV) Wallets zu verwenden, aber könnte Herausforderungen für die SPV-Validierung in Smart Contracts, wie z.B. Bridges zwischen Bitcoin und anderen Systemen, darstellen. Sjors Provoost [schlug vor][provoost bridge], - dass jemand, der einen onchain-durchsetzbaren Bridge implementiert, Code bereitstellt, + dass jemand, der eine on-chain-durchsetzbare Bridge implementiert, Code bereitstellt, der den Unterschied zwischen der Annahme, dass 64-Byte-Transaktionen nicht existieren, und der Verwendung der alternativen Methode zur Verhinderung von Merkle-Baum-Schwachstellen illustriert. @@ -678,7 +678,7 @@ bleiben, wenn Knoten sich über die aktuelle Feerate uneinig sind. - [Eclair #3045][] macht das `payment_secret`-Feld im äußeren Onion-Payload optional für Single-Part-[Trampoline payments][topic trampoline payments]. Zuvor enthielt jede Trampoline-Zahlung ein `payment_secret`, -auch wenn keine [Multipath payments][topic multipath payments] (MPP) verwendet wurde. Da Zahlungsschlüssel möglicherweise +auch wenn keine [Multipath payments][topic multipath payments] (MPP) verwendet wurden. Da Zahlungsschlüssel möglicherweise erforderlich sind, wenn moderne [BOLT11][]-Rechnungen verarbeitet werden, fügt Eclair einen Dummy ein, wenn keiner bereitgestellt wird. @@ -760,4 +760,4 @@ und Blockchain-Konstanten wie deren Genesis-Hash hinzugefügt werden. [corallo eltoo]: https://x.com/TheBlueMatt/status/1857119394104500484 [bdk wallet 1.2.0]: https://github.com/bitcoindevkit/bdk/releases/tag/wallet-1.2.0 [ldk v0.1.2]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.1.2 -[news341 pr review]: /de/newsletters/2025/02/14/#bitcoin-core-pr-review-club \ No newline at end of file +[news341 pr review]: /de/newsletters/2025/02/14/#bitcoin-core-pr-review-club From 3c8cd11332e9e9d7751b82b19e6a4f60ea72ade9 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Tue, 27 May 2025 21:46:55 -1000 Subject: [PATCH 033/278] Newsletters: add 356 (2025-05-30) --- .../en/newsletters/2025-05-30-newsletter.md | 126 ++++++++++++++++++ _topics/en/attributable-failures.md | 64 +++++++++ 2 files changed, 190 insertions(+) create mode 100644 _posts/en/newsletters/2025-05-30-newsletter.md create mode 100644 _topics/en/attributable-failures.md diff --git a/_posts/en/newsletters/2025-05-30-newsletter.md b/_posts/en/newsletters/2025-05-30-newsletter.md new file mode 100644 index 0000000000..2f826158e1 --- /dev/null +++ b/_posts/en/newsletters/2025-05-30-newsletter.md @@ -0,0 +1,126 @@ +--- +title: 'Bitcoin Optech Newsletter #356' +permalink: /en/newsletters/2025/05/30/ +name: 2025-05-30-newsletter +slug: 2025-05-30-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter summarizes a discussion about the possible +effects of attributable failures on LN privacy. Also included are our +regular sections with selected questions and answers from the Bitcoin +Stack Exchange, announcements of new releases and release candidates, +and descriptions of recent changes to popular Bitcoin infrastructure +software. + +## News + +- **Do attributable failures reduce LN privacy?** Carla Kirk-Cohen + [posted][kirkcohen af] to Delving Bitcoin an analysis of the possible + consequences for the privacy of LN spenders and receivers if the + network adopts [attributable failures][topic attributable failures], + particularly telling the spender the amount of time it took to forward + a payment at each hop. Citing several papers, she describes two types + of deanonymization attacks: + + - An attacker operating one or more forwarding nodes uses timing + data to determine the number of hops used by a payment ([HTLC][topic + htlc]), which can be combined with knowledge of the topography of + the public network to narrow the set of nodes that might have been + the receiver. + + - An attacker uses an IP network traffic forwarder + ([autonomous system][]) to passively monitor traffic and combines + that with knowledge of the IP network latency between nodes (i.e., + their ping times) plus knowledge of the topography (and other + characteristics) of the public Lightning Network. + + She then describes possible solutions, including: + + - Encouraging receivers to delay acceptance of an HTLC by a small + random amount to prevent timing attacks that attempt to identify the + receiver's node. + + - Encouraging spenders to delay resending failed payments (or + [MPP][topic multipath payments] parts) by a small random amount and + by using alternative paths to prevent timing and failure attacks + attempting to identify the spender's node. + + - Increased payment splitting with MPP to make it harder to guess the + amount being spent. + + - Allowing spenders to opt-in to having their payments forwarded less + quickly, as previously proposed (see [Newsletter #208][news208 + slowln]). This could be combined with HTLC batching, which is + already implemented in LND (although the addition of a randomized + delay could enhance privacy). + + - Reducing the precision of attributable failure timestamps to avoid + penalizing forwarding nodes that add small random delays. + + Discussion from multiple participants evaluated the concerns and + proposed solutions in more detail, as well as considering other + possible attacks and mitigations. + +## Selected Q&A from Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] is one of the first places Optech +contributors look for answers to their questions---or when we have a +few spare moments to help curious or confused users. In +this monthly feature, we highlight some of the top-voted questions and +answers posted since our last update.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +FIXME:bitschmidty + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [Core Lightning 25.05rc1][] is a release candidate for the next major + version of this popular LN node implementation. + +- [LDK 0.1.3][] and [0.1.4][ldk 0.1.4] are releases of this popular + library for building LN-enabled applications. Version 0.1.3, tagged + as a release on GitHub this week but dated last month, includes the + fix for a denial-of-service attack. Version 0.1.4, the latest + release, "fixes a funds-theft vulnerability in exceeding rare cases". + Both releases also include other bug fixes. + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [Bitcoin Core #31622][] psbt: add non-default sighash types to PSBTs and unify sighash type match checking + +- [Eclair #3065][] Attributable failures Implements lightning/bolts#1044 + +- [LDK #3796][] tankyleo/2025-05-dont-dip-into-reserve + +- [BIPs #1760][] BIP 53: Disallow 64-byte transactions + +- [BIPs #1850][] murchandamus/Revert-bip48-update + +- [BIPs #1793][] BIP 443: OP_CHECKCONTRACTVERIFY + +{% include snippets/recap-ad.md when="2025-06-03 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31622,3065,3796,1760,1850,1793" %} +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[ldk 0.1.3]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.1.3 +[ldk 0.1.4]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.1.4 +[news208 slowln]: /en/newsletters/2022/07/13/#allowing-deliberately-slow-ln-payment-forwarding +[autonomous system]: https://en.wikipedia.org/wiki/Autonomous_system_(Internet) +[kirkcohen af]: https://delvingbitcoin.org/t/latency-and-privacy-in-lightning/1723 diff --git a/_topics/en/attributable-failures.md b/_topics/en/attributable-failures.md new file mode 100644 index 0000000000..b94f1eb6bd --- /dev/null +++ b/_topics/en/attributable-failures.md @@ -0,0 +1,64 @@ +--- +title: Attributable failures + +## Optional. Shorter name to use for reference style links e.g., "foo" +## will allow using the link [topic foo][]. Not case sensitive +# shortname: foo + +## Optional. An entry will be added to the topics index for each alias +#title-aliases: +# - Foo + +## Required. At least one category to which this topic belongs. See +## schema for options +topic-categories: + - Lightning Network + +## Optional. Produces a Markdown link with either "[title][]" or +## "[title](link)" +primary_sources: + - title: "BOLTs #1044: attributable failures" + link: https://github.com/lightning/bolts/pull/1044 + +## Optional. Each entry requires "title" and "url". May also use "feature: +## true" to bold entry and "date" +optech_mentions: + - title: Proposal to authenticate messages about LN payment forwarding delays + url: /en/newsletters/2019/06/19/#authenticating-messages-about-ln-delays + + - title: Updated proposal for attributing payment forwarding failures and delays + url: /en/newsletters/2022/11/02/#ln-routing-failure-attribution + + - title: "LDK #3629 improves logging of remote failures that can’t be attributed" + url: /en/newsletters/2025/03/14/#ldk-3629 + + - title: "LDK #2256 and LDK #3709 improve attributable failures" + url: /en/newsletters/2025/04/11/#ldk-2256 + + - title: Discussion about whether attributable failures reduce LN privacy + url: /en/newsletters/2025/05/30/#do-attributable-failures-reduce-ln-privacy + +## Optional. Same format as "primary_sources" above +# see_also: +# - title: +# link: + +## Optional. Force the display (true) or non-display (false) of stub +## topic notice. Default is to display if the page.content is below a +## threshold word count +#stub: false + +## Required. Use Markdown formatting. Only one paragraph. No links allowed. +## Should be less than 500 characters +excerpt: > + **Attributable failures** are LN payment forwarding failures or delays + that can be attributed to a pair of nodes (who may have one or more + channels between each other), allowing spenders to avoid using slow or + failure-prone nodes for future payments. Additional fields in LN + messages for tracking failures and delays are in the process of being + standardized as of 2025. + +--- + +{% include references.md %} +{% include linkers/issues.md issues="" %} From def9d70e40169e3e4fc9cb9ca307a365bcf54e64 Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 29 May 2025 05:16:23 +0000 Subject: [PATCH 034/278] News356: add merge summaries --- _includes/references.md | 2 + .../en/newsletters/2025-05-30-newsletter.md | 58 +++++++++++++++---- 2 files changed, 48 insertions(+), 12 deletions(-) diff --git a/_includes/references.md b/_includes/references.md index 27ddb66b84..f79aae5413 100644 --- a/_includes/references.md +++ b/_includes/references.md @@ -94,6 +94,7 @@ for details --> {% endcomment %} [BIP49]: https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki [BIP50]: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki [BIP52]: https://github.com/bitcoin/bips/blob/master/bip-0052.mediawiki +[BIP53]: https://github.com/bitcoin/bips/blob/master/bip-0053.mediawiki [BIP54]: https://github.com/bitcoin/bips/blob/master/bip-0054.md [BIP61]: https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki [BIP62]: https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki @@ -202,6 +203,7 @@ for details --> {% endcomment %} [BIP389]: https://github.com/bitcoin/bips/blob/master/bip-0389.mediawiki [BIP390]: https://github.com/bitcoin/bips/blob/master/bip-0390.mediawiki [BIP431]: https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki +[BIP443]: https://github.com/bitcoin/bips/blob/master/bip-0443.mediawiki {% for i in (1..10) %} {% assign i_padded = "0000" | append: i | slice: -4, 4 %} diff --git a/_posts/en/newsletters/2025-05-30-newsletter.md b/_posts/en/newsletters/2025-05-30-newsletter.md index 2f826158e1..a169e9d124 100644 --- a/_posts/en/newsletters/2025-05-30-newsletter.md +++ b/_posts/en/newsletters/2025-05-30-newsletter.md @@ -103,24 +103,58 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Bitcoin Core #31622][] psbt: add non-default sighash types to PSBTs and unify sighash type match checking - -- [Eclair #3065][] Attributable failures Implements lightning/bolts#1044 - -- [LDK #3796][] tankyleo/2025-05-dont-dip-into-reserve - -- [BIPs #1760][] BIP 53: Disallow 64-byte transactions - -- [BIPs #1850][] murchandamus/Revert-bip48-update - -- [BIPs #1793][] BIP 443: OP_CHECKCONTRACTVERIFY +- [Bitcoin Core #31622][] adds a signature hash (sighash) type field to + [PSBTs][topic psbt] when it is different from `SIGHASH_DEFAULT` or + `SIGHASH_ALL`. [MuSig2][topic musig] support requires everyone to sign with + the same sighash type, so this field must be present in the PSBT. + Additionally, the `descriptorprocesspsbt` RPC command is updated to use the + `SignPSBTInput` function, which ensures that the PSBT's sighash type matches + the one provided in the CLI, if applicable. + +- [Eclair #3065][] adds support for attributable failures (see Newsletter + [#224][news224 failures]) as specified in [BOLTs #1044][]. It’s disabled by + default because the specification isn't finalized, but can be enabled with the + setting `eclair.features.option_attributable_failure = optional`. + Cross-compatibility with LDK has been successfully tested, see Newsletter + [#349][news349 failures] for more information on LDK’s implementation and how + this protocol works. + +- [LDK #3796][] tightens the channel balance checks so that funders have + sufficient funds to cover the commitment transaction fee, the two 330 sat + [anchor outputs][topic anchor outputs], and the channel reserve. Previously, + funders could dip into the channel reserve funds to cover for the two anchors. + +- [BIPs #1760][] merges [BIP53][] which specifies a consensus soft-fork rule + that disallows 64-byte transactions (measured without witness data) to prevent + a type of [merkle tree vulnerability][topic merkle tree vulnerabilities] + exploitable against SPV clients. This PR proposes a similar fix to one + of the fixes included in the [consensus cleanup softfork][topic consensus cleanup]. + +- [BIPs #1850][] reverts an earlier update to [BIP48][] which reserved the + script type value 3 for [taproot][topic taproot] (P2TR) derivations (see + Newsletter [#353][news353 bip48]). This is because [tapscript][topic tapscript] + lacks `OP_CHECKMULTISIG`, so the referenced output script in [BIP67][] (which + [BIP48][] relies on) cannot be expressed in P2TR. This PR also marks + [BIP48][]’s status as `Final`, reflecting that its purpose was to define the + industry use of `m/48'` [HD wallet][topic bip32] derivation paths when the BIP + was introduced, rather than prescribe new behavior. + +- [BIPs #1793][] merges [BIP443][] which proposes the + [OP_CHECKCONTRACTVERIFY][topic matt] (OP_CCV) opcode that + allows checking that a public key (of both the outputs and the inputs) commits + to an arbitrary piece of data. See Newsletter [#348][news348 op_ccv] for more + information on this proposed [covenant][topic covenants]. {% include snippets/recap-ad.md when="2025-06-03 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="31622,3065,3796,1760,1850,1793" %} +{% include linkers/issues.md v=2 issues="31622,3065,3796,1760,1850,1793,1044" %} [Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 [ldk 0.1.3]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.1.3 [ldk 0.1.4]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.1.4 [news208 slowln]: /en/newsletters/2022/07/13/#allowing-deliberately-slow-ln-payment-forwarding [autonomous system]: https://en.wikipedia.org/wiki/Autonomous_system_(Internet) [kirkcohen af]: https://delvingbitcoin.org/t/latency-and-privacy-in-lightning/1723 +[news224 failures]: /en/newsletters/2022/11/02/#ln-routing-failure-attribution +[news349 failures]: /en/newsletters/2025/04/11/#ldk-2256 +[news353 bip48]: /en/newsletters/2025/05/09/#bips-1835 +[news348 op_ccv]: /en/newsletters/2025/04/04/#op-checkcontractverify-semantics \ No newline at end of file From de721ec3b2ee2f5c754a03696d00cee742d4d31a Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 29 May 2025 08:02:30 -0700 Subject: [PATCH 035/278] News356: add stack exchange --- .../en/newsletters/2025-05-30-newsletter.md | 42 ++++++++++++++++++- 1 file changed, 40 insertions(+), 2 deletions(-) diff --git a/_posts/en/newsletters/2025-05-30-newsletter.md b/_posts/en/newsletters/2025-05-30-newsletter.md index a169e9d124..469163d015 100644 --- a/_posts/en/newsletters/2025-05-30-newsletter.md +++ b/_posts/en/newsletters/2025-05-30-newsletter.md @@ -74,7 +74,43 @@ answers posted since our last update.* {% comment %}{% endcomment %} {% assign bse = "https://bitcoin.stackexchange.com/a/" %} -FIXME:bitschmidty +- [Which transactions get into blockreconstructionextratxn?]({{bse}}116519) + Glozow explains how the extrapool data structure (see [Newsletter #339][news339 + extrapool]) caches rejected and replaced transactions seen by the node + and lists the criteria for exclusion and eviction. + +- [Why would anyone use OP_RETURN over inscriptions, aside from fees?]({{bse}}126208) + Sjors Provoost notes that in addition to sometimes being cheaper, `OP_RETURN` + can also be used for protocols that need data to be available before a transaction + is spent, as opposed to witness data that is revealed in the spending transaction. + +- [Why is my Bitcoin node not receiving incoming connections?]({{bse}}126338) + Lightlike points out that a new node on the network can take time to have its + address widely advertised on the P2P network and that nodes will not + advertise their address until IBD has completed. + +- [How do I configure my node to filter out transactions larger than 400 bytes?]({{bse}}126347) + Antoine Poinsot confirms there is no configuration option in Bitcoin Core to + customize the maximum standard transaction size. He outlines that users + wanting to customize that value can update their source code, but warns about + potential downsides of both larger and smaller maximum values. + +- [What does "not publicly routable" node in Bitcoin Core P2P mean?]({{bse}}126225) + Pieter Wuille and Vasil Dimov provide examples of P2P connections, such as + [Tor][topic anonymity networks], that cannot be routed on the global internet + and that appear in Bitcoin Core's `netinfo` output in the "npr" bucket. + +- [Why would a node would ever relay a transaction?]({{bse}}127391) + Pieter Wuille lists benefits of relaying transactions for a node operator: + privacy when relaying your own transactions from your node, faster block + propagation if the user is mining, and improved network decentralization with + minimal incremental costs beyond just relaying blocks. + +- [Is selfish mining still an option with compact blocks and FIBRE?]({{bse}}49515) + Antoine Poinsot follows up to a 2016 question noting, "Yes, selfish mining is + still a possible optimisation even with improved block propagation. It's not + correct to conclude that selfish mining is now only a theoretical attack". He + also points to a [mining simulation][miningsimulation github] he created. ## Releases and release candidates @@ -157,4 +193,6 @@ repo], and [BINANAs][binana repo]._ [news224 failures]: /en/newsletters/2022/11/02/#ln-routing-failure-attribution [news349 failures]: /en/newsletters/2025/04/11/#ldk-2256 [news353 bip48]: /en/newsletters/2025/05/09/#bips-1835 -[news348 op_ccv]: /en/newsletters/2025/04/04/#op-checkcontractverify-semantics \ No newline at end of file +[news348 op_ccv]: /en/newsletters/2025/04/04/#op-checkcontractverify-semantics +[news339 extrapool]: /en/newsletters/2025/01/31/#updated-stats-on-compact-block-reconstruction +[miningsimulation github]: https://github.com/darosior/miningsimulation From a20e67f8eefe425e2785b55cd4c29c79c62f67d2 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Thu, 29 May 2025 21:44:40 -1000 Subject: [PATCH 036/278] News356: add topic entries (harding section) --- _topics/en/consensus-cleanup-soft-fork.md | 3 +++ _topics/en/matt.md | 3 +++ 2 files changed, 6 insertions(+) diff --git a/_topics/en/consensus-cleanup-soft-fork.md b/_topics/en/consensus-cleanup-soft-fork.md index 8f87542862..25363d78e2 100644 --- a/_topics/en/consensus-cleanup-soft-fork.md +++ b/_topics/en/consensus-cleanup-soft-fork.md @@ -68,6 +68,9 @@ optech_mentions: - title: "Bitcoin Core #32155 updates the internal miner to comply with consensus cleanup requirements" url: /en/newsletters/2025/05/16/#bitcoin-core-32155 + - title: "BIPs #1760 merges BIP53, which specifies a consensus change to forbid 64 byte transactions" + url: /en/newsletters/2025/05/30/#bips-1760 + ## Optional. Same format as "primary_sources" above see_also: - title: Soft fork activation diff --git a/_topics/en/matt.md b/_topics/en/matt.md index d1d0bb0217..76e546139d 100644 --- a/_topics/en/matt.md +++ b/_topics/en/matt.md @@ -44,6 +44,9 @@ optech_mentions: - title: "OP_VAULT proposal withdrawn in favor of OP_CCV" url: /en/newsletters/2025/05/16/#bips-1848 + - title: "BIPs #1793 merges BIP443 which proposes the OP_CHECKCONTRACTVERIFY opcode" + url: /en/newsletters/2025/05/30/#bips-1793 + ## Optional. Same format as "primary_sources" above see_also: - title: Covenants From 0cf8c47bec9a664d3aa70c68ac02d4a4ca275f36 Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 30 May 2025 21:00:10 +0900 Subject: [PATCH 037/278] Newsletter-356:Translate into Japanese --- .../ja/newsletters/2025-05-30-newsletter.md | 175 ++++++++++++++++++ 1 file changed, 175 insertions(+) create mode 100644 _posts/ja/newsletters/2025-05-30-newsletter.md diff --git a/_posts/ja/newsletters/2025-05-30-newsletter.md b/_posts/ja/newsletters/2025-05-30-newsletter.md new file mode 100644 index 0000000000..7d8caf9fa7 --- /dev/null +++ b/_posts/ja/newsletters/2025-05-30-newsletter.md @@ -0,0 +1,175 @@ +--- +title: 'Bitcoin Optech Newsletter #356' +permalink: /ja/newsletters/2025/05/30/ +name: 2025-05-30-newsletter-ja +slug: 2025-05-30-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、帰属障害がLNのプライバシーに影響を及ぼす可能性について掲載しています。 +また、Bitcoin Stack Exchangeから厳選された質問とその回答や、 +新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの最近の更新など +恒例のセクションも含まれています。 + +## ニュース + +- **帰属障害はLNのプライバシーを低下させる？** + Carla Kirk-Cohenは、ネットワークが[失敗の帰属][topic attributable failures]、 + 特に各ホップで支払いを転送するのにかかった時間を支払人に伝える場合、 + LNの支払人と受取人のプライバシーにどのような影響が及ぶ可能性があるかについての分析を + Delving Bitcoinに[投稿しました][kirkcohen af]。 + 彼女は複数の論文を引用しながら、2種類の非匿名化攻撃について説明しています: + + - 1つ以上の転送ノードを運用する攻撃者が、タイミングデータを使って + 支払い（[HTLC][topic htlc]）に使用されたホップ数を特定します。 + このデータと公開ネットワークのトポロジーに関する知識を組み合わせることで、 + 受取人の可能性があるノードのセットを絞り込むことができます。 + + - 攻撃者が、IPネットワークトラフィックフォワーダー（[自律システム][autonomous system]）を使ってトラフィックを受動的に監視し、 + ノード間のIPネットワークのレイテンシー（つまりping時間）の知識と、 + 公開ライトニングネットワークのトポロジー（およびその他の特性）に関する知識を組み合わせることができます。 + + 次に彼女は、以下の解決策を挙げています: + + - 受取人にHTLCの受け入れを小さなランダム時間分遅らせることを推奨し、 + 受取人のノードを特定しようとするタイミング攻撃を防止する。 + + - 支払人に失敗した支払い（または[MPP][topic multipath payments]の一部）の再送を + 小さなランダム時間分遅らせ、代替パスを使うことで、 + 支払人のノードを特定しようとするタイミング攻撃や失敗攻撃を防止する。 + + - MPPによる支払いの分割数を増やし、支払額の推測を困難にする。 + + - 以前の提案のように（[ニュースレター #208][news208 slowln]参照）、 + 支払人が支払いをより遅く転送されることを選択できるようにする。 + これは、LNDで既に実装されているHTLCバッチ処理と組み合わせることもできる（ + ランダム時間の遅延の追加によりプライバシーを強化できる）。 + + - 小さなランダム遅延を追加する転送ノードへのペナルティを回避するため、 + 原因となる失敗のタイムスタンプの精度を下げる。 + + 複数の参加者による議論では、懸念事項と提案された解決策をより詳細に評価し、 + その他の可能性のある攻撃と軽減策についても検討されました。 + +## Bitcoin Stack Exchangeから選ばれたQ&A + +*[Bitcoin Stack Exchange][bitcoin.se]はOptech Contributor達が疑問に対して答えを探しに（もしくは他のユーザーの質問に答える時間がある場合に）アクセスする、 +数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [どのトランザクションがblockreconstructionextratxnに取り込まれるのでしょうか？]({{bse}}116519) + Glozowは、extrapoolのデータ構造（[ニュースレター #339][news339 extrapool]参照）が、 + ノードが拒否または置換したトランザクションをどのようにキャッシュするかについて説明し、 + 除外と排除の基準をリストアップしています。 + +- [手数料は別として、なぜinscriptionよりOP_RETURNを使うのでしょうか？]({{bse}}126208) + Sjors Provoostは、`OP_RETURN`の方が安価な場合があることに加え、 + `OP_RETURN`は、使用時に開示されるwitnessデータとは対照的に、 + トランザクションが使用される前に利用可能なデータが必要なプロトコルで使えると指摘しています。 + +- [私のBitcoinノードに着信接続がないのはどうしてですか？]({{bse}}126338) + Lightlikeは、ネットワーク上の新しいノードのアドレスがP2Pネットワーク上で広く通知されるのには時間がかかる場合があり、 + ノードはIBDが完了するまでアドレスを通知しないと指摘しています。 + +- [400 byteを超えるトランザクションをフィルタリングするようにノードを設定するにはどうすればいいですか？]({{bse}}126347) + Antoine Poinsotは、Bitcoin Coreには標準トランザクションの最大サイズをカスタマイズする設定オプションがないことを確認しています。 + 彼は、その値をカスタマイズしたいユーザーはソースコードを更新できると説明していますが、 + 最大値を大きくする場合と小さくする場合の両方の潜在的なデメリットについても警告しています。 + +- [Bitcoin CoreのP2Pにおける「publicly routable」でないノードとは何を意味するのですか？]({{bse}}126225) + Pieter WuilleとVasil Dimovは、グローバルインターネット上でルーティングできず、 + Bitcoin Coreの`netinfo`出力で「npr」バケットに表示される + [Tor][topic anonymity networks]などのP2P接続の例を示しています。 + +- [なぜノードはトランザクションをリレーするのですか？]({{bse}}127391) + Pieter Wuilleは、ノードオペレーターにとってトランザクションをリレーすることの利点として、 + 自身のノードから自身のトランザクションをリレーする際のプライバシー、 + ユーザーがマイニングしている場合のブロックの伝播の高速化、 + ブロックのリレー以外の追加コストを最小限に抑えながらネットワークの分散性を向上させることを挙げています。 + +- [コンパクトブロックやFIBREでも、セルフィッシュマイニングは依然として選択肢となるのでしょうか？]({{bse}}49515) + Antoine Poinsotは、2016年の質問に続けて、「はい。セルフィッシュマイニングは、 + ブロックの伝播が改善されたとしても、依然として最適化可能な手段です。 + セルフィッシュマイニングがもはや理論上の攻撃に過ぎないと結論付けるのは間違っています」と述べています。 + 彼はまた、自身が作成した[マイニングシミュレーション][miningsimulation github]についても言及しています。 + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [Core Lightning 25.05rc1][]は、この人気のLNノード実装の次期メジャーバージョンのリリース候補です。 + +- [LDK 0.1.3][]および[0.1.4][ldk 0.1.4]は、LN対応アプリケーションを構築するための + この人気のライブラリのリリースです。バージョン0.1.3はGithub上では今週のリリースとしてタグ付けされていますが、 + リリース日は先月になっており、サービス拒否攻撃に対する修正が含まれています。 + 最新リリースであるバージョン0.1.4では「極めて稀なケースで発生する資金窃盗の脆弱性を修正」しています。 + 両リリースには、その他のバグ修正も含まれています。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Bitcoin Core #31622][]は、署名ハッシュ（sighash）タイプが + `SIGHASH_DEFAULT`または`SIGHASH_ALL`と異なる場合に、 + [PSBT][topic psbt]にそのフィールドを追加します。 + [MuSig2][topic musig]のサポートでは、全員が同じsighashタイプで署名する必要があるため、 + このフィールドはPSBTに必須です。さらに、`descriptorprocesspsbt` RPCコマンドは、 + `SignPSBTInput`関数を使用するように更新され、 + PSBTのsighashタイプがCLIで指定されたタイプと一致することを保証します（該当する場合）。 + +- [Eclair #3065][]は、[BOLTs #1044][]で定義されている + 帰属障害（ニュースレター[#224][news224 failures]参照）のサポートを追加します。 + 仕様がまだ確定していないためデフォルトでは無効になっていますが、 + `eclair.features.option_attributable_failure = optional`を設定することで有効にできます。 + LDKとの相互互換性はテスト済みです。LDKの実装とこのプロトコルの動作に関する詳細については、 + ニュースレター[#349][news349 failures]をご覧ください。 + +- [LDK #3796][]は、チャネル残高チェックを強化し、 + 資金提供者がコミットメントトランザクションの手数料、 + 2つの330 satsの[アンカーアウトプット][topic anchor outputs]、 + そしてチャネルリザーブを賄うのに十分な資金を確保できるようにします。 + これまでは、資金提供者は、2つのアンカーを賄うためにチャネルリザーブを利用できました。 + +- [BIPs #1760][]は、SPVクライアントに対して悪用可能な + [マークルツリーの脆弱性][topic merkle tree vulnerabilities]を防ぐため、 + （witnessデータを除いた）64-byteのトランザクションを禁止するコンセンサスソフトフォークルールを規定した + [BIP53][]をマージしました。このPRは、 + [コンセンサスクリーンアップソフトフォーク][topic consensus cleanup]に含まれるものと同様の修正を提案しています。 + +- [BIPs #1850][]は、[Taproot][topic taproot]（P2TR）の導出用にスクリプトタイプの値3を予約した + [BIP48][]の以前の更新（ニュースレター [#353][news353 bip48]参照）を元に戻しました。 + これは、[Tapscript][topic tapscript]に`OP_CHECKMULTISIG`がないため、 + [BIP48][]が依存する[BIP67][]で参照されているアウトプットスクリプトをP2TRで表現できないためです。 + このPRはまた[BIP48][]のステータスを`Final`としています。 + これはBIP導入時の目的が、新しい動作を規定することではなく、 + `m/48'` [HDウォレット][topic bip32]導出パスの業界における使用を定義することが目的であったことを反映しています。 + +- [BIPs #1793][]は、（アウトプットとインプット両方の）公開鍵が任意のデータにコミットしていることを確認できる + [OP_CHECKCONTRACTVERIFY][topic matt]（OP_CCV） opcodeを提案する[BIP443][]をマージしました。 + この提案された[コベナンツ][topic covenants]の詳細については、ニュースレター[#348][news348 op_ccv]をご覧ください。 + +{% include snippets/recap-ad.md when="2025-06-03 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31622,3065,3796,1760,1850,1793,1044" %} +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[ldk 0.1.3]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.1.3 +[ldk 0.1.4]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.1.4 +[news208 slowln]: /ja/newsletters/2022/07/13/#ln +[autonomous system]: https://ja.wikipedia.org/wiki/自律システム_(インターネット) +[kirkcohen af]: https://delvingbitcoin.org/t/latency-and-privacy-in-lightning/1723 +[news224 failures]: /ja/newsletters/2022/11/02/#ln +[news349 failures]: /ja/newsletters/2025/04/11/#ldk-2256 +[news353 bip48]: /ja/newsletters/2025/05/09/#bips-1835 +[news348 op_ccv]: /ja/newsletters/2025/04/04/#op-checkcontractverify +[news339 extrapool]: /ja/newsletters/2025/01/31/#updated-stats-on-compact-block-reconstruction +[miningsimulation github]: https://github.com/darosior/miningsimulation From c890d5774cc33ec13ced48bd49671c30ebebd5ef Mon Sep 17 00:00:00 2001 From: Jiri Jakes Date: Fri, 30 May 2025 19:58:39 +0800 Subject: [PATCH 038/278] Newsletter-356: Translate into Czech --- .../cs/newsletters/2025-05-30-newsletter.md | 189 ++++++++++++++++++ 1 file changed, 189 insertions(+) create mode 100644 _posts/cs/newsletters/2025-05-30-newsletter.md diff --git a/_posts/cs/newsletters/2025-05-30-newsletter.md b/_posts/cs/newsletters/2025-05-30-newsletter.md new file mode 100644 index 0000000000..62712a205a --- /dev/null +++ b/_posts/cs/newsletters/2025-05-30-newsletter.md @@ -0,0 +1,189 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 356' +permalink: /cs/newsletters/2025/05/30/ +name: 2025-05-30-newsletter-cs +slug: 2025-05-30-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden shrnuje diskuzi o možných dopadech informací +o původci chyb na soukromí v LN. Též nechybí naše pravidelné rubriky +s vybranými otázkami a odpověďmi z Bitcoin Stack Exchange, oznámeními +nových vydání a popisem nedávných změn v populárním bitcoinovém +páteřním software. + +## Novinky + +- **Snižují informace o původci chyb soukromí v LN?** Carla Kirk-Cohen + zaslala do fóra Delving Bitcoin [příspěvek][kirkcohen af] s analýzou + možných dopadů na soukromí odesílatelů a příjemců v LN, pokud by síť + začala používat [informace o původci chyb][topic attributable failures] + (attributable failures), obzvláště informování odesílatele o počtu + pokusů o přeposlání v každém skoku. Na základě několika citovaných + článků popisuje dva druhy deanonymizačních útoků: + + - Útočník provozující jeden či více přeposílajících uzlů může + měřením času určit počet skoků použitých platbou ([HTLC][topic + htlc]), což může v kombinaci se znalostí topografie veřejné sítě + zúžit seznam možných příjemců. + + - Útočník používající směrovač IP síťového provozu + ([autonomní systém][autonomous system]) může pasivně monitorovat provoz a zkombinovat ho se znalostí + latence IP sítě mezi uzly (např. měřením času ping) a topografie + veřejné sítě LN. + + Dále popisuje možná řešení, včetně: + + - vyzývání příjemců, aby zpozdili přijetí HTLC o drobný náhodný čas, + čímž by zabránili útokům měřením času k odhalení identity uzlu + příjemce. + + - vyzývání odesílatelů, aby zpozdili opakované odesílání chybných + plateb (nebo [MPP][topic multipath payments] částí) o drobný náhodný + čas a používali alternativní cesty, čímž by zabránili útokům + měřením času a vyvoláním selhání k odhalení identity uzlu odesílatele. + + - častějšího dělení platby pomocí MPP, což by ztížilo odhad celkové částky. + + - možnosti odesílatelů zpomalit přeposílání svých plateb, jak bylo již + dříve navrženo (viz [zpravodaj č. 208][news208 slowln], _angl._). + To by mohlo být zkombinováno s dávkováním HTLC, které LND již podporuje + (avšak přidání náhodného zpoždění by soukromí dále navýšilo). + + - snížení přesnosti časových razítek v informacích o původci chyby. + Tím by nebyly přeposílající uzly přidávající drobná náhodná zpoždění + penalizovány. + + Účastníci diskuze podrobněji hodnotili riziko a navrhovaná řešení a + hovořili o další možných útocích a opatřeních. + +## Vybrané otázky a odpovědi z Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] je jedním z prvních míst, kde hledají +přispěvatelé Optechu odpovědi na své otázky a kde – najdou-li volnou chvíli – +pomáhají zvědavým či zmateným uživatelům. V této měsíční rubrice nabízíme +některé z otázek a odpovědí, které obdržely vysoký počet hlasů.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Jak se transakce dostanou do blockreconstructionextratxn?]({{bse}}116519) + Glozow vysvětluje, jak datová struktura extrapoolu (viz [zpravodaj č. 339][news339 + extrapool]) kešuje odmítnuté a nahrazené transakce, které uzel obdržel, + a vysvětluje kritéria pro jejich zamítání a vylučování. + +- [Proč by někdo používal OP_RETURN namísto inscriptions (kromě poplatků)?]({{bse}}126208) + Sjors Provoost poznamenává, že kromě nižších nákladů může být `OP_RETURN` + používán v protokolech, které vyžadují, aby byla data dostupná před utracením + transakce a ne – jako v případě dat witnessu – odhalena až v utrácející transakci. + +- [Proč nemá můj bitcoinový uzel žádná příchozí spojení?]({{bse}}126338) + Lightlike vysvětluje, že může trvat, než se adresa nového uzlu dostatečně + propaguje v P2P síti a že uzly nezačnou svou adresu šířit, dokud není + dokončeno úvodní stahování bloků. + +- [Jak můžu nastavit svůj uzel, aby filtroval transakce větší než 400 bajtů?]({{bse}}126347) + Antoine Poinsot potvrzuje, že v Bitcoin Core není žádná volba pro vlastní + nastavení maximální velikosti standardních transakcí. Dodává, že uživatelé, + kteří chtějí tuto hodnotu upravit, mohou změnit zdrojové kódy. Upozorňuje + však na potenciální nevýhody vyšších i nižších hodnot. + +- [Co v Bitcoin Core P2P znamená „not publicly routable”?]({{bse}}126225) + Pieter Wuille a Vasil Dimov poskytují příklady P2P spojení, jako je + na příklad [Tor][topic anonymity networks], která nemohou být v globálním + internetu použita pro směrování a která se nacházejí v oddílu „npr“ ve výstupu + `netinfo` v Bitcoin Core. + +- [Proč by měl uzel přeposílat transakce?]({{bse}}127391) + Pieter Wuille vyjmenovává výhody, které provozovatelovi uzlu přeposílání + transakcí nabízí: soukromí během zveřejňování vlastních transakcí, + rychlejší propagace bloků pro těžící uzly a vyšší míra decentralizace + sítě. To vše s jen mírnými náklady nad rámec pouhého přeposílání bloků. + +- [Je sobecká těžba stále možná i s kompaktními bloky a FIBRE?]({{bse}}49515) + Antoine Poinsot dodává k otázce z roku 2016: „Ano, sobecká těžba je stále + možnou optimalizací i přes vylepšenou propagaci bloků. Není správné považovat + sobeckou těžbu již za pouze teoretický útok.” Dále odkazuje na svou + [simulaci těžby][miningsimulation github]. + +## Vydání nových verzí + +*Vydání nových verzí oblíbených páteřních bitcoinových projektů. Prosíme, +zvažte upgrade či pomoc s testováním.* + +- [Core Lightning 25.05rc1][] je kandidátem na vydání další hlavní verze této + oblíbené implementace LN uzlu. + +- [LDK 0.1.3][] a [0.1.4][ldk 0.1.4] jsou vydáními této populární knihovny + pro budování aplikací s LN. Verze 0.1.3, otagována jako vydání na GitHubu + tento týden ale datovaná minulý měsíc, obsahuje opravu útoku odepřením + služby. Verze 0.1.4, nejnovější vydání, „opravuje zranitelnost umožňující + v extrémně vzácných případech krádež prostředků.” Obě vydání obsahují + i další opravy. + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo] a [repozitáři BINANA][binana repo]._ + +- [Bitcoin Core #31622][] přidává do [PSBT][topic psbt] pole druhu haše podpisu + (sighash), je-li odlišné od `SIGHASH_DEFAULT` či `SIGHASH_ALL`. Podpora pro + [MuSig2][topic musig] vyžaduje, aby všichni podepsali stejným druhem haše, + proto musí v PSBT toto pole být přítomné. Dále bude RPC `descriptorprocesspsbt` + používat funkci `SignPSBTInput`, která zajistí, aby druh haše v PSBT + odpovídal volbě poskytnuté v CLI. + +- [Eclair #3065][] přidává podporu informací o původci selhání (attributable failures, + viz [zpravodaj č. 224][news224 failures], _angl._) dle specifikace v [BOLTs #1044][]. + Ve výchozím nastavení je neaktivní, protože specifikace není ještě finalizována, + může být aktivována nastavením volby `eclair.​features.​option_attributable_failure` na `optional`. + Úspěšně otestována byla kompatibilita s LDK; [zpravodaj č. 349][news349 failures] + poskytuje o implementaci v LDK a fungování protokolu více informací. + +- [LDK #3796][] zpřísňuje kontrolu zůstatku kanálu, aby měla zakládající strana + dostatečné prostředky na pokrytí poplatku commitment transakce, dvou 330satových + [anchor výstupů][topic anchor outputs] a rezervy kanálu. Dříve bylo možné + pro zaplacení dvou anchorů sáhnout do rezerv kanálu. + +- [BIPs #1760][] začleňuje [BIP53][], který specifikuje soft fork konsenzu + zakazující 64bajtové transakce (bez dat witnessu). Toto pravidlo zabrání + jednomu druhu [zranitelnosti Merkleova stromu][topic merkle tree vulnerabilities], + které lze zneužít proti SPV klientům. PR navrhuje podobnou opravu jako + soft fork [pročištění konsenzu][topic consensus cleanup]. + +- [BIPs #1850][] odstraňuje nedávnou změnu [BIP48][], která rezervovala hodnotu + typu skriptu 3 pro [taprootové][topic taproot] (P2TR) derivace (viz + [zpravodaj č. 353][news353 bip48]). Důvodem je, že [tapscript][topic tapscript] + nepodporuje `OP_CHECKMULTISIG`, a proto výstupní skript v [BIP67][] (na kterém + [BIP48][] závisí) nemůže být v P2TR vyjádřen. PR dále mění stav [BIP48][] na `Final`, + čímž indikuje, že jeho účelem bylo definovat používání derivačních cest (`m/48'`) + v [hierarchických deterministických peněženkách][topic bip32] v době představení + BIPu a ne předepisovat nové chování. + +- [BIPs #1793][] začleňuje [BIP443][] navrhující opkód [OP_CHECKCONTRACTVERIFY][topic + matt] (OP_CCV). Ten umožňuje ověřit, zda nějaký veřejný klíč (vstupů či výstupů) + zavazuje nějakým libovolným datům. Viz též [zpravodaj č. 348][news348 op_ccv], který + o tomto navrhovaném [kovenantu][topic covenants] poskytuje další informace. + +{% include snippets/recap-ad.md when="2025-06-03 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31622,3065,3796,1760,1850,1793,1044" %} +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[ldk 0.1.3]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.1.3 +[ldk 0.1.4]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.1.4 +[news208 slowln]: /en/newsletters/2022/07/13/#allowing-deliberately-slow-ln-payment-forwarding +[autonomous system]: https://cs.wikipedia.org/wiki/Autonomn%C3%AD_syst%C3%A9m +[kirkcohen af]: https://delvingbitcoin.org/t/latency-and-privacy-in-lightning/1723 +[news224 failures]: /en/newsletters/2022/11/02/#ln-routing-failure-attribution +[news349 failures]: /cs/newsletters/2025/04/11/#ldk-2256 +[news353 bip48]: /cs/newsletters/2025/05/09/#bips-1835 +[news348 op_ccv]: /cs/newsletters/2025/04/04/#semantika-op-checkcontractverify +[news339 extrapool]: /cs/newsletters/2025/01/31/#aktualizovane-statistiky-rekonstruovani-kompaktnich-bloku +[miningsimulation github]: https://github.com/darosior/miningsimulation From b32cacdee3c5478f210646a7319778e25e885ab3 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Fri, 30 May 2025 23:18:12 +0200 Subject: [PATCH 039/278] Newsletter 355 translate in French --- .../fr/newsletters/2025-05-23-newsletter.md | 163 ++++++++++++++++++ 1 file changed, 163 insertions(+) create mode 100644 _posts/fr/newsletters/2025-05-23-newsletter.md diff --git a/_posts/fr/newsletters/2025-05-23-newsletter.md b/_posts/fr/newsletters/2025-05-23-newsletter.md new file mode 100644 index 0000000000..6de8b7e69e --- /dev/null +++ b/_posts/fr/newsletters/2025-05-23-newsletter.md @@ -0,0 +1,163 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #355' +permalink: /fr/newsletters/2025/05/23/ +name: 2025-05-23-newsletter-fr +slug: 2025-05-23-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine inclut nos sections habituelles décrivant les changements apportés +aux services et aux logiciels clients, annonçant des mises à jour et des versions candidates, et +résumant les changements récents apportés aux logiciels d'infrastructure Bitcoin populaires. + +## Nouvelles + +*Aucune nouvelle significative cette semaine n'a été trouvée dans aucune de nos [sources][].* + +## Changements dans les services et les logiciels clients + +*Dans cette rubrique mensuelle, nous mettons en lumière des mises à jour intéressantes des +portefeuilles et services Bitcoin.* + +- **Cake Wallet a ajouté le support de payjoin v2 :** + Cake Wallet [v4.28.0][cake wallet 4.28.0] ajoute [la capacité][cake blog] de + recevoir des paiements en utilisant le protocole [payjoin][topic payjoin] v2. + +- **Sparrow ajoute des fonctionnalités pay-to-anchor :** + Sparrow [2.2.0][sparrow 2.2.0] affiche et peut envoyer des sorties [pay-to-anchor + (P2A)][topic ephemeral anchors]. + +- **Safe Wallet 1.3.0 publié :** + [Safe Wallet][safe wallet github] est un portefeuille multisig de bureau avec support de dispositif + de signature matériel qui a ajouté le bumping de frais [CPFP][topic cpfp] pour les transactions + entrantes dans [1.3.0][safe wallet 1.3.0]. + +- **COLDCARD Q v1.3.2 publié :** + La version [v1.3.2 de COLDCARD Q][coldcard blog] inclut un support de politique de dépense multisig + supplémentaire et de nouvelles fonctionnalités pour [partager des données sensibles][coldcard kt]. + +- **Regroupement de transactions utilisant payjoin :** + [Private Pond][private pond post] est une [implémentation expérimentale][private + pond github] d'un service de [regroupement de transactions][topic payment + batching] qui utilise payjoin pour générer des transactions plus petites qui paient moins de frais. + +- **Simulateur de Fidelity Bond JoinMarket :** + Le [JoinMarket Fidelity Bond Simulator][jmfbs github] fournit des outils pour les participants de + JoinMarket pour simuler leur performance sur le marché basée sur les [fidelity bonds][news161 fb]. + +- **Documentation des opcodes Bitcoin :** + Le site web [Opcode Explained][opcode explained website] documente chaque opcode du script Bitcoin. + +- **Code de Bitkey rendu open source :** + Le dispositif de signature matériel Bitkey [a annoncé][bitkey blog] que leur [code source][bitkey + github] est open-source pour des usages non commerciaux. + +## Mises à jour et versions candidates + +_Nouvelles versions et candidates à la sortie pour les projets d'infrastructure Bitcoin populaires. +Veuillez envisager de mettre à niveau vers les nouvelles versions ou d'aider à tester les candidates +à la sortie._ + +- [LND 0.19.0-beta][] est la dernière version majeure de ce nœud LN populaire. Elle contient de + nombreuses [améliorations][lnd rn] et corrections de bugs, y compris le nouveau bumping de frais + basé sur RBF pour les fermetures coopératives. + +- [Core Lightning 25.05rc1][] est un candidat à la sortie pour la prochaine version majeure de + cette implémentation de nœud LN populaire. + +## Changements notables dans le code et la documentation + +_Changements notables récents dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning +repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware WalletInterface (HWI)][hwi repo], +[Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], +[Propositions d'Amélioration de Bitcoin (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Inquisition Bitcoin][bitcoin inquisition repo], et [BINANAs][binana +repo]._ + +- [Bitcoin Core #32423][] supprime l'avis de dépréciation pour `rpcuser/rpcpassword` et le remplace + par un avertissement de sécurité concernant le stockage des identifiants en clair dans le fichier de + configuration. Cette option avait été initialement dépréciée lorsque `rpcauth` a été introduit dans + [Bitcoin Core #7044][], qui prend en charge plusieurs utilisateurs RPC et hache son cookie. La PR + ajoute également un grain de sel aléatoire de 16 octets aux identifiants des deux méthodes et les + hash avant qu'ils ne soient stockés en mémoire. + +- [Bitcoin Core #31444][] étend la classe `TxGraph` (voir le Bulletin [#348][news348 txgraph]) avec + trois nouvelles fonctions d'aide : `GetMainStagingDiagrams()` retourne les divergences de clusters + entre les diagrammes de taux de frais principaux et de mise en scène, `GetBlockBuilder()` itère à + travers des morceaux de graphique (groupements triés par taux de frais en sous-cluster) du plus + élevé au plus bas taux de frais pour une construction de bloc optimisée, et `GetWorstMainChunk()` + identifie le morceau au taux de frais le plus bas pour les décisions d'éviction. Cette PR est l'un + des derniers éléments de construction de l'implémentation initiale complète du projet de [mempool en + cluster][topic cluster mempool]. + +- [Core Lightning #8140][] active le [stockage par les pairs][topic peer storage] des + sauvegardes de canaux par défaut (voir le Bulletin [#238][news238 storage]), le rendant viable pour + les grands nœuds en limitant le stockage aux pairs ayant des canaux actuels ou passés, en mettant en + cache les sauvegardes et les listes de pairs en mémoire au lieu de faire des appels répétés à + `listdatastore`/`listpeerchannels`, en plafonnant les téléchargements de sauvegarde concurrents à + deux pairs, en sautant les sauvegardes de plus de 65 kB, et en randomisant la sélection des pairs + lors de l'envoi. + +- [Core Lightning #8136][] met à jour l'échange de signatures d'annonce pour qu'il se produise + lorsque le canal est prêt plutôt qu'après six blocs, pour s'aligner sur la récente mise à jour de la + spécification [BOLTs #1215][]. Il est toujours nécessaire d'attendre six blocs pour [annoncer le + canal][topic channel announcements]. + +- [Core Lightning #8266][] ajoute une commande `update` au gestionnaire de plugins Reckless (voir + le Bulletin [#226][news226 reckless]) qui met à jour un plugin spécifié ou tous les plugins installés + si aucun n'est spécifié, à l'exception de ceux installés à partir d'un tag Git fixe ou d'un commit. + Cette PR étend également la commande `install` pour prendre un chemin source ou une URL en plus d'un + nom de plugin. + +- [Core Lightning #8021][] finalise l'interopérabilité de [splicing][topic splicing] avec Eclair + (voir le Bulletin [#331][news331 interop]) en corrigeant la rotation des clés de financement à + distance, en renvoyant `splice_locked` lors du réétablissement du canal pour couvrir les cas où + il était initialement manqué (voir le Bulletin [#345][news345 splicing]), en assouplissant l'exigence + que les messages signés d'engagement arrivent dans + un ordre particulier, permettant de recevoir et d'initier des transactions de raccordement + [RBF][topic rbf], convertissant automatiquement les [PSBTs][topic psbt] sortants en version 2 + lorsque nécessaire, ainsi que d'autres modifications de refactoring. + +- [Core Lightning #8226][] implémente [BIP137][] en ajoutant une nouvelle commande RPC + `signmessagewithkey` qui permet aux utilisateurs de signer des messages avec n'importe quelle clé du + portefeuille en spécifiant une adresse Bitcoin. Auparavant, signer un message avec une clé Core + Lightning nécessitait de trouver le xpriv et l'index de la clé, de dériver la clé privée avec une + bibliothèque externe, puis de signer le message avec Bitcoin Core. + +- [LND #9801][] ajoute une nouvelle option `--no-disconnect-on-pong-failure`, qui contrôle si un + pair est déconnecté si une réponse pong est tardive ou ne correspond pas. Cette option est définie + sur false par défaut, préservant le comportement actuel de LND qui se déconnecte d'un pair en cas + d'échec du message pong (voir le Bulletin [#275][news275 ping]) ; autrement, LND ne ferait que + consigner l'événement. La PR refactorise le chien de garde ping pour continuer sa boucle lorsque la + déconnexion est supprimée. + +{% include snippets/recap-ad.md when="2025-05-27 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32423,31444,8140,8136,8266,8021,8226,9801,7044,1215" %} +[lnd 0.19.0-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta +[sources]: /en/internal/sources/ +[lnd rn]: https://github.com/lightningnetwork/lnd/blob/master/docs/release-notes/release-notes-0.19.0.md +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[news348 txgraph]: /fr/newsletters/2025/04/04/#bitcoin-core-31363 +[news238 storage]: /fr/newsletters/2023/02/15/#core-lightning-5361 +[news226 reckless]: /fr/newsletters/2022/11/16/#core-lightning-5647 +[news331 interop]: /fr/newsletters/2024/11/29/#core-lightning-7719 +[news345 splicing]: /fr/newsletters/2025/03/14/#eclair-3007 +[news275 ping]: /fr/newsletters/2023/11/01/#lnd-7828 +[cake wallet 4.28.0]: https://github.com/cake-tech/cake_wallet/releases/tag/v4.28.0 +[cake blog]: https://blog.cakewallet.com/bitcoin-privacy-takes-a-leap-forward-cake-wallet-introduces-payjoin-v2/ +[sparrow 2.2.0]: https://github.com/sparrowwallet/sparrow/releases/tag/2.2.0 +[safe wallet github]: https://github.com/andreasgriffin/bitcoin-safe +[safe wallet 1.3.0]: https://github.com/andreasgriffin/bitcoin-safe/releases/tag/1.3.0 +[coldcard blog]: https://blog.coinkite.com/ccc-and-keyteleport/ +[coldcard ccc]: https://coldcard.com/docs/coldcard-cosigning/ +[coldcard kt]: https://github.com/Coldcard/firmware/blob/master/docs/key-teleport.md +[private pond post]: https://njump.me/naddr1qvzqqqr4gupzqg42s9gsae3lu2cketskuzfp778fh2vg9c5x3elx8ttdpzhfkk25qq2nv5nzddgxxdjtd4u9vwrdv939vmnswfzk6j85dxk +[private pond github]: https://github.com/Kukks/PrivatePond +[jmfbs github]: https://github.com/m0wer/joinmarket-fidelity-bond-simulator +[news161 fb]: /en/newsletters/2021/08/11/#implementation-of-fidelity-bonds +[opcode explained website]: https://opcodeexplained.com/ +[bitkey blog]: https://x.com/BEN0WHERE/status/1918073429791785086 +[bitkey github]: https://github.com/proto-at-block/bitkey From 74f2290843e528a24eaf66344e4523db0a8511ff Mon Sep 17 00:00:00 2001 From: BitTom Date: Sat, 31 May 2025 05:20:45 +0800 Subject: [PATCH 040/278] Newsletter-185: translate into Chinese (#2331) --- .../zh/newsletters/2022-02-02-newsletter.md | 61 +++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 _posts/zh/newsletters/2022-02-02-newsletter.md diff --git a/_posts/zh/newsletters/2022-02-02-newsletter.md b/_posts/zh/newsletters/2022-02-02-newsletter.md new file mode 100644 index 0000000000..caafe9f410 --- /dev/null +++ b/_posts/zh/newsletters/2022-02-02-newsletter.md @@ -0,0 +1,61 @@ +--- +title: 'Bitcoin Optech Newsletter #185' +permalink: /zh/newsletters/2022/02/02/ +name: 2022-02-02-newsletter-zh +slug: 2022-02-02-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周 Newsletter 描述了对提议中的 `OP_CHECKTEMPLATEVERIFY`（CTV） 操作码对 Discreet Log Contracts（DLC） 的影响所做的分析，并总结了关于通过修改 tapscript 以同时支持 CTV 和 `SIGHASH_ANYPREVOUT` 的替代方案的讨论。此外，还照例包含了新版本发布公告以及流行比特币基础设施软件的值得注意的变更。 + +## 新闻 + +- ******通过修改脚本提高 DLC 效率：** + Lloyd Fournier 在 DLC-Dev 和 Bitcoin-Dev 邮件列表[发帖][fournier ctv dlc]，说明提议中的 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]（CTV） 操作码如何能够显著减少创建某些 Discreet Log Contracts（DLC） 所需的签名数量，并减少其他一些操作的数量。 + + 简而言之，对于合约的每一种可能终态——例如 Alice 获得 1 BTC、Bob 获得 2 BTC——现有的 DLC 需要为该状态创建一个独立的[签名适配器][topic adaptor signatures]。许多合约会定义大量可能的终态，例如关于未来比特币价格的合约，将价格四舍五入到最接近的美元，并且即便是相对短期的合约也需要覆盖数千美元的价格范围。这就要求参与方创建、交换并存储数千个部分签名。 + + Fournier 建议，使用 CTV 在一个 [tapleaf][topic tapscript] 中生成这成千上万种可能状态，并在链上提交输出。CTV 通过散列承诺输出，各方可以快速且按需地自行计算所有可能状态的散列，从而最小化计算量、数据交换和数据存储。虽然仍需要一些签名，但数量被大幅减少。对于使用多个预言机（例如汇率合约的多个价格数据源）的合约而言，还可以进一步简化流程，减少所需数据量。 + + Jonas Nick [指出][nick apo dlc]，使用提议中的 [SIGHASH_ANYPREVOUT][topic sighash_anyprevout] 签名哈希模式也可以实现类似的优化（我们补充，接下来新闻条目中介绍的替代方案同样可行）。 + +- ******可组合的 CTV 和 APO 替代方案：** + Russell O'Connor 在 Bitcoin-Dev 邮件列表[发帖][oconnor txhash]，提出通过软分叉为比特币 [Tapscript][topic tapscript] 语言新增两个操作码的想法。tapscript 可以使用新的 `OP_TXHASH` 操作码指定应序列化并散列一笔支出交易的哪些部分，然后将散列摘要压入求值栈以供后续操作码使用。新的 [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack]（CSFS） 操作码（此前已有提议）允许 tapscript 指定公钥，并要求对栈上的特定数据——例如 `OP_TXHASH` 计算出的交易摘要——进行相应签名。 + + O'Connor 解释了这两个操作码如何能够模拟早先的两项软分叉提案，[SIGHASH_ANYPREVOUT][topic sighash_anyprevout]（APO，见 [BIP118][]）和 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]（CTV，见 [BIP119][]）。在某些场景下，这种模拟可能不如直接使用 CTV 或 APO 高效，但 `OP_TXHASH` 与 `OP_CSFS` 可以保持 Tapscript 语言的简洁，并为未来脚本编写者提供更大的灵活性，尤其是在与诸如 [OP_CAT][] 等其他简单 tapscript 扩展结合使用时。 + + 在一则[回复][towns pop_sigdata]中，Anthony Towns 提出了使用其他替代操作码的类似思路。 + + 截至撰写本文时，相关讨论仍在积极进行中。我们预计将在后续 Newsletter 中再次关注该主题。 + +## 发布与候选发布 + +*面向流行比特币基础设施项目的新版本发布与候选发布。请考虑升级到新版本，或协助测试候选发布。* + +- [BTCPay Server 1.4.2][] 是新的 1.4.x 系列中的最新发布版本，改进了登录认证并包含若干[用户界面改进][btcpay ui blog]。 +- [BDK 0.16.0][] 发布，带来若干漏洞修复和小幅改进。 +- [Eclair 0.7.0][] 为重大版本，新增对[锚定输出][topic anchor outputs]、转发[洋葱消息][topic onion messages]以及在生产环境中使用 PostgreSQL 数据库的支持。 +- [LND 0.14.2-beta.rc1][lnd 0.14.2-beta] 为维护版本的候选发布，包含若干漏洞修复和少量改进。 + +## 值得注意的代码与文档变更 + +*本周在 [Bitcoin Core][bitcoin core repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[硬件钱包接口（HWI）][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中的值得注意的变更。* + +- [Bitcoin Core #23201][] 通过允许钱包用户指定最大权重而非求解数据，改进了使用外部输入为交易提供资金的能力（此前见 [Newsletter #170][news170 external inputs]）。这使得应用能够使用 `fundrawtransaction`、`send` 和 `walletfundpsbt` RPC 对包含非标准输出（如 [HTLCs][topic htlc]，这是 LN 客户端在 [Newsletter #184][news184 eclair auto bump] 中描述的要求）的交易进行手续费提升。 +- [Eclair #2141][] 改进了自动手续费提升机制（此前见 [Newsletter #184][news184 eclair auto bump]），当钱包中的 UTXO 数量较少时，会选择更激进的确认目标。在这种情况下，让手续费提升交易尽快确认对于在进一步强制关闭时保持钱包的 UTXO 数量至关重要。关于 Eclair 使用的锚定输出风格手续费提升的更多细节见[此处][topic anchor outputs]。 +- [BTCPay Server #3341][] 允许用户在通过 LN 请求退款时配置 [BOLT11][] 到期时间，不再固定为之前的 30 天默认值。 + +{% include references.md %} +{% include linkers/issues.md issues="23201,2141,3341" %} +[btcpay server 1.4.2]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.4.2 +[bdk 0.16.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.16.0 +[eclair 0.7.0]: https://github.com/ACINQ/eclair/releases/tag/v0.7.0 +[lnd 0.14.2-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.14.2-beta.rc1 +[btcpay ui blog]: https://blog.btcpayserver.org/btcpay-server-1-4-0/ +[fournier ctv dlc]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html +[nick apo dlc]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019812.html +[oconnor txhash]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html +[towns pop_sigdata]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019819.html +[news184 eclair auto bump]: /zh/newsletters/2022/01/26/#eclair-2113 +[news170 external inputs]: /zh/newsletters/2021/10/13/#bitcoin-core-17211 From 242ba6a06e67c963d431624d588a73dcae050ea5 Mon Sep 17 00:00:00 2001 From: Octoshi <125779328+cryptozyu@users.noreply.github.com> Date: Mon, 26 May 2025 14:29:19 +0800 Subject: [PATCH 041/278] newsletter-354: translate into Chinese (#167) * newsletter-354: translate into Chinese * fix format --------- Co-authored-by: Zhiwei(Jeffrey) Hu --- .../zh/newsletters/2025-05-16-newsletter.md | 68 +++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 _posts/zh/newsletters/2025-05-16-newsletter.md diff --git a/_posts/zh/newsletters/2025-05-16-newsletter.md b/_posts/zh/newsletters/2025-05-16-newsletter.md new file mode 100644 index 0000000000..be29966f63 --- /dev/null +++ b/_posts/zh/newsletters/2025-05-16-newsletter.md @@ -0,0 +1,68 @@ +--- +title: 'Bitcoin Optech Newsletter #354' +permalink: /zh/newsletters/2025/05/16/ +name: 2025-05-16-newsletter-zh +slug: 2025-05-16-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的周报描述了一个影响旧版本 Bitcoin Core 的已修复漏洞。此外还包括我们的常规部分：总结了近期关于更改比特币共识规则的讨论、新版本和候选版本的公告，以及对热门比特币基础设施软件的重大变更介绍。 + +## 新闻 + +- ******影响旧版本 Bitcoin Core 的漏洞披露：** Antoine Poinsot 在 Bitcoin-Dev 邮件列表上[发布][poinsot addrvuln]了一个影响 29.0 之前版本 Bitcoin Core 的漏洞公告。该漏洞最初由 Eugene Siegel [负责任地披露][topic responsible disclosures]，同时还有另一个在[周报 #314][news314 excess addr]中描述的密切相关的漏洞。攻击者可以发送过多的节点地址广告，迫使 32 位标识符溢出，导致节点崩溃。这一问题部分通过限制每个对等节点每十秒钟只能更新一次来缓解，对于默认约 125 个对等节点的限制，除非节点被持续攻击超过 10 年，否则不会发生溢出。 该漏洞已在上个月发布的 Bitcoin Core 29.0 中通过使用 64 位标识符完全修复。 + +## 共识变更 + +_每月一次的总结比特币共识规则变更提案和讨论的栏目。_ + +- ******Script 中 64 位算术的 BIP 提案：** Chris Stewart 向 Bitcoin-Dev 邮件列表[发布][stewart bippost]了一个[草案 BIP][64bit bip]，提议将比特币现有的操作码升级为支持 64 位数值操作。这是他之前研究的延续（参见周报 [#285][news285 64bit]、[#290][news290 64bit] 和 [#306][news306 64bit]）。与早期讨论的一些变化不同，新提案使用与比特币当前使用的相同 compactSize 数据格式的数字。相关的额外[讨论][stewart inout]发生在 Delving Bitcoin 上的两个[主题][stewart overflow]中。 + +- ******通过自我复制脚本启用递归限制条款的操作码提案：** Bram Cohen 在 Delving Bitcoin 上[发布][cohen quine]了一组简单操作码的建议，这些操作码将通过自我复制脚本（[quines][]）实现递归[限制条款][topic covenants]的创建。Cohen 描述了如何使用这些操作码创建一个简单的[保管库][topic vaults]，并提到了他正在开发的一个更高级的系统。 + +- ******BitVM 从 `OP_CTV` 和 `OP_CSFS` 获得的好处描述：** Robin Linus 在 Delving Bitcoin 上[发布][linus bitvm-sf]了关于如果在软分叉中向比特币添加提议的 [OP_CTV][topic op_checktemplateverify] 和 [OP_CSFS][topic op_checksigfromstack] 操作码，[BitVM][topic acc] 可能获得的几项改进。他描述的好处包括增加操作符数量而没有缺点，“将交易大小减少约 10 倍”（降低最坏情况下的成本），以及允许某些合约的非交互式 peg-in。 + +## 版本和候选版本 + +*热门的比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本。* + +- [LND 0.19.0-beta.rc4][] 是这个热门的闪电网络节点的候选版本。可能需要测试的主要改进之一是在合作关闭场景中新的基于 RBF 的手续费提升。 + +## 重大的代码和文档变更 + +*本周的重大变更有：[Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface（HWI）][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement Proposals（BIPs）][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo]。* + +- [Bitcoin Core #32155][] 更新了内部矿工，通过将 `nLockTime` 字段设置为当前区块高度减一并要求 `nSequence` 字段不是最终值（以强制执行时间锁定）来对 coinbase 交易进行[时间锁定][topic timelocks]。虽然内置矿工通常不在主网上使用，但更新它鼓励矿池在自己的软件中尽早采用这些变更，为 [BIP54][] 中提出的[共识清理][topic consensus cleanup]软分叉做准备。对 coinbase 交易进行时间锁定解决了[重复交易][topic duplicate transactions]漏洞，并将允许取消成本高昂的 [BIP30][] 检查。 + +- [Bitcoin Core #28710][] 移除了剩余的传统钱包代码、文档和相关测试。这包括仅限传统钱包的 RPC，如 `importmulti`、`sethdseed`、`addmultisigaddress`、`importaddress`、`importpubkey`、`dumpwallet`、`importwallet` 和 `newkeypool`。作为移除传统钱包的最后一步，BerkeleyDB 依赖和相关函数也被移除。然而，为了执行钱包迁移到[描述符][topic descriptors]钱包，保留了最少量的传统代码和一个独立的 BDB 解析器（参见周报 [#305][news305 bdb]）。 + +- [Core Lightning #8272][] 禁用了连接守护进程 `connectd` 中的 DNS 种子查询对等节点发现回退，以解决由离线 DNS 种子引起的调用阻塞问题。 + +- [LND #8330][] 在路径查找双峰概率模型中添加了一个小常数（1/c）以解决数值不稳定问题。在由于舍入错误而导致计算失败并产生零概率的边缘情况下，这种正则化通过使模型恢复为均匀分布提供了一个回退方案。这解决了在涉及非常大的通道或不符合双峰分布的通道的场景中出现的归一化错误。此外，该模型现在跳过不必要的概率计算，并自动纠正过时的通道流动性观察和矛盾的历史信息。 + +- [Rust Bitcoin #4458][] 用新添加的 `BlockMtp` 和已有的 `BlockHeight` 的显式对替换了 `MtpAndHeight` 结构，使得在相对[时间锁][topic timelocks]中能更好地建模区块高度和中位时间过去（MTP）值。与 `locktime::absolute::MedianTimePast`（限制为 5 亿以上的值，大约 1985 年之后）不同，`BlockMtp` 可以表示任何 32 位时间戳。这使其适用于理论边缘情况，例如具有不寻常时间戳的链。此更新还引入了 `BlockMtpInterval`，并将 `BlockInterval` 重命名为 `BlockHeightInterval`。 + +- [BIPs #1848][] 将 [BIP345][] 的状态更新为 `Withdrawn`，因为作者[认为][obeirne vaultwithdraw]其提出的 `OP_VAULT` 操作码已被 [`OP_CHECKCONTRACTVERIFY`][topic matt]（OP_CCV）所取代，后者是一种更通用的[保管库][topic vaults]设计和一种新型[限制条款][topic covenants]。 + +- [BIPs #1841][] 合并了 [BIP172][]，该提案建议正式将比特币的不可分割基本单位定义为“聪”（satoshi），反映当前广泛使用的情况，并帮助在应用程序和文档中标准化术语。 + +- [BIPs #1821][] 合并了 [BIP177][]，该提案建议将“bitcoin”重新定义为表示最小的不可分割单位（通常称为 1 聪），而不是 100,000,000 个单位。该提案认为，将术语与实际基本单位对齐将减少由任意小数约定引起的混淆。 + +{% include references.md %} +{% include linkers/issues.md v=2 issues="32155,28710,8272,8330,4458,1848,1841,1821" %} +[lnd 0.19.0-beta.rc4]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc4 +[news314 excess addr]: /zh/newsletters/2024/08/02/#addr +[stewart bippost]: https://groups.google.com/g/bitcoindev/c/j1zEky-3QEE +[64bit bip]: https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki +[news285 64bit]: /zh/newsletters/2024/01/17/#proposal-for-64-bit-arithmetic-soft-fork-64 +[news290 64bit]: /zh/newsletters/2024/02/21/#continued-discussion-about-64-bit-arithmetic-and-op-inout-amount-opcode-64-op-inout-amount +[news306 64bit]: /zh/newsletters/2024/06/07/#updates-to-proposed-soft-fork-for-64-bit-arithmetic +[stewart inout]: https://delvingbitcoin.org/t/op-inout-amount/549/4 +[stewart overflow]: https://delvingbitcoin.org/t/overflow-handling-in-script/1549 +[poinsot addrvuln]: https://mailing-list.bitcoindevs.xyz/bitcoindev/EYvwAFPNEfsQ8cVwiK-8v6ovJU43Vy-ylARiDQ_1XBXAgg_ZqWIpB6m51fAIRtI-rfTmMGvGLrOe5Utl5y9uaHySELpya2ojC7yGsXnP90s=@protonmail.com/ +[cohen quine]: https://delvingbitcoin.org/t/a-simple-approach-to-allowing-recursive-covenants-by-enabling-quines/1655/ +[linus bitvm-sf]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/ +[quines]: https://zh.wikipedia.org/wiki/%E8%87%AA%E7%94%A2%E7%94%9F%E7%A8%8B%E5%BC%8F +[news305 bdb]: /zh/newsletters/2024/05/31/#bitcoin-core-26606 +[obeirne vaultwithdraw]: https://delvingbitcoin.org/t/withdrawing-op-vault-bip-345/1670/ From c051e2bdfaeb43d0691fcc09218ff8e554cd68c0 Mon Sep 17 00:00:00 2001 From: Steven Torok <79690639+TorokNRoll@users.noreply.github.com> Date: Mon, 2 Jun 2025 15:52:12 +0200 Subject: [PATCH 042/278] Matrix Checkbox Labels & Podcast (#2338) --- _layouts/podcast.md | 2 +- en/matrix.md | 28 +++++++++++++++++++++------- index.md | 7 +++---- 3 files changed, 25 insertions(+), 12 deletions(-) diff --git a/_layouts/podcast.md b/_layouts/podcast.md index 5e590acdd6..0fe070ab16 100644 --- a/_layouts/podcast.md +++ b/_layouts/podcast.md @@ -14,7 +14,7 @@ layout: default

Podcast

-Join Bitcoin Optech as we discuss Bitcoin and Lightning technology each week and review our newsletters. +Join us for the weekly Bitcoin Optech Recap on Riverside at 16:30 UTC as we discuss Bitcoin and Lightning technology and review our newsletters. {% include functions/podcast-links.md %} diff --git a/en/matrix.md b/en/matrix.md index 0b847f1e53..253623b97d 100644 --- a/en/matrix.md +++ b/en/matrix.md @@ -89,16 +89,30 @@ th, td { Select features to display:
-  Platform
-  Hardware Wallet Interface
-  Fee Bumping
-  Descriptors
-  Multi-Party (PSBT, MuSig2, Coinjoin, Payjoin)
+   +   +   +   +  
-  Payment Codes, Silent Payments
-  Lightning
+   +   Legend:
diff --git a/index.md b/index.md index 92bc4fd9d7..6b2da059e0 100644 --- a/index.md +++ b/index.md @@ -11,10 +11,9 @@ layout: home Bitcoin Optech helps Bitcoin users and businesses integrate scaling technologies. -We provide [workshops][], [weekly -newsletters][], [case studies and -announcements][blog], [analysis of Bitcoin software and -services][matrix], a [podcast][], and help facilitate improved relations between +We provide [weekly newsletters][], a [podcast][], [case studies and +announcements][blog], [analyses of Bitcoin software and +services][matrix], [workshops][] and help to facilitate improved relations between businesses and the open source community. From e7f9b7f9af9022e326d935a56b749a89ec9c1072 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Mon, 2 Jun 2025 16:40:25 +0200 Subject: [PATCH 043/278] Newsletter 349 german (#2342) Co-authored-by: garfiel-d --- .../de/newsletters/2025-04-11-newsletter.md | 105 ++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 _posts/de/newsletters/2025-04-11-newsletter.md diff --git a/_posts/de/newsletters/2025-04-11-newsletter.md b/_posts/de/newsletters/2025-04-11-newsletter.md new file mode 100644 index 0000000000..bd90576fa8 --- /dev/null +++ b/_posts/de/newsletters/2025-04-11-newsletter.md @@ -0,0 +1,105 @@ +--- +title: 'Bitcoin Optech Newsletter #349' +permalink: /de/newsletters/2025/04/11/ +name: 2025-04-11-newsletter-de +slug: 2025-04-11-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche beschreibt einen Vorschlag zur Beschleunigung des Initial Block Download (IBD) von Bitcoin Core, mit einer Proof-of-Concept-Implementierung, die etwa eine 5-fache Beschleunigung gegenüber den Standard-Einstellungen von Bitcoin Core zeigt. Ebenfalls enthalten sind unsere regulären Abschnitte mit einer Zusammenfassung eines Bitcoin Core PR Review Club Meetings, Ankündigungen neuer Releases und Release-Kandidaten sowie Beschreibungen wichtiger Änderungen an populärer Bitcoin-Infrastruktur. + +## Nachrichten + +- **SwiftSync-Beschleunigung für Initial Block Download:** Sebastian Falbesoner [veröffentlichte][falbesoner ss1] auf Delving Bitcoin eine Beispielimplementierung und Performance-Ergebnisse für _SwiftSync_, eine Idee, die von Ruben Somsen während eines kürzlichen Bitcoin Core Entwicklermeetings [vorgeschlagen][somsen ssgist] und später [auf der Mailingliste gepostet][somsen ssml] wurde. Die [aktuellsten Ergebnisse][falbesoner ss2] im Thread zeigen eine 5,28-fache Beschleunigung des _Initial Block Downloads_ (IBD) gegenüber den Standard-IBD-Einstellungen von Bitcoin Core (die [assumevalid][] aber nicht [assumeUTXO][topic assumeutxo] verwenden), wodurch die anfängliche Synchronisationszeit von etwa 41 Stunden auf etwa 8 Stunden reduziert wird. + + Vor der Verwendung von SwiftSync erstellt jemand, der seinen Knoten bereits bis zu einem aktuellen Block synchronisiert hat, eine _Hints-Datei_, die angibt, welche Transaktionsausgänge im UTXO-Set zu diesem Block enthalten sein werden (d.h. welche Ausgänge unspent sind). Diese Datei kann für die aktuelle UTXO-Set-Größe effizient auf einige hundert Megabyte komprimiert werden. Die Datei gibt auch an, bei welchem Block sie generiert wurde, den wir als _terminalen SwiftSync-Block_ bezeichnen. + + Der Nutzer, der SwiftSync durchführt, lädt die Hints-Datei herunter und verwendet sie beim Verarbeiten jedes Blocks vor dem terminalen SwiftSync-Block, um nur solche Outputs in der UTXO-Datenbank zu speichern, die laut Hints-Datei im UTXO-Set verbleiben werden, wenn der terminale SwiftSync-Block erreicht ist. Dadurch wird die Anzahl der Einträge, die während des IBD in die UTXO-Datenbank eingefügt und später wieder entfernt werden, massiv reduziert. + + Um sicherzustellen, dass die Hints-Datei korrekt ist, wird jeder erzeugte Output, der nicht in der UTXO-Datenbank gespeichert wird, zu einem [kryptographischen Akkumulator][cryptographic accumulator] hinzugefügt. Jeder ausgegebene Output wird aus dem Akkumulator entfernt. Wenn der Knoten den terminalen SwiftSync-Block erreicht, stellt er sicher, dass der Akkumulator leer ist, was bedeutet, dass jeder gesehene Output später ausgegeben wurde. Falls das nicht zutrifft, war die Hints-Datei fehlerhaft und der IBD muss ohne SwiftSync erneut durchgeführt werden. So müssen Nutzer dem Ersteller der Hints-Datei nicht vertrauen – eine bösartige Datei kann keinen falschen UTXO-Zustand erzeugen, sondern nur einige Stunden Rechenzeit verschwenden. + + Eine zusätzliche Eigenschaft von SwiftSync, die noch nicht implementiert ist, ist die parallele Validierung von Blöcken während des IBD. Dies ist möglich, weil assumevalid die Skripte älterer Blöcke nicht prüft, Einträge vor dem terminalen SwiftSync-Block nie aus der UTXO-Datenbank entfernt werden und der verwendete Akkumulator nur die Nettoeffekte von hinzugefügten (erzeugten) und entfernten (ausgegebenen) Outputs verfolgt. Dadurch entfallen Abhängigkeiten zwischen Blöcken vor dem terminalen SwiftSync-Block. Parallele Validierung während des IBD ist auch ein Feature von [Utreexo][topic utreexo] aus ähnlichen Gründen. + + Die Diskussion beleuchtete mehrere Aspekte des Vorschlags. Falbesoners ursprüngliche Implementierung nutzte den [MuHash][]-Akkumulator (siehe [Newsletter #123][news123 muhash]), der [als resistent][wuille muhash] gegen den [generalisierten Geburtstagsangriff][generalized birthday attack] gilt. Somsen [beschrieb][somsen ss1] einen alternativen Ansatz, der schneller sein könnte. Falbesoner zweifelte an der kryptographischen Sicherheit des alternativen Ansatzes, implementierte ihn aber dennoch aufgrund seiner Einfachheit und stellte fest, dass SwiftSync dadurch weiter beschleunigt wurde. + + James O'Beirne [fragte][obeirne ss], ob SwiftSync sinnvoll ist, da assumeUTXO eine noch größere Beschleunigung bietet. Somsen [antwortete][somsen ss2], dass SwiftSync die Hintergrundvalidierung von assumeUTXO beschleunigt und somit eine sinnvolle Ergänzung für assumeUTXO-Nutzer ist. Außerdem merkt er an, dass jeder, der die für assumeUTXO benötigten Daten (die UTXO-Datenbank zu einem bestimmten Block) herunterlädt, keine separate Hints-Datei benötigt, wenn er denselben Block als terminalen SwiftSync-Block verwendet. + + Vojtěch Strnad, 0xB10C und Somsen [diskutierten][b10c ss] die Komprimierung der Hints-Datei, mit einer erwarteten Einsparung von etwa 75 %, wodurch die Testdatei (für Block 850.900) auf etwa 88 MB schrumpft. + + Die Diskussion war zum Zeitpunkt des Schreibens noch im Gange. {% assign timestamp="0:34" %} + +## Bitcoin Core PR Review Club + +*In diesem monatlichen Abschnitt fassen wir ein aktuelles [Bitcoin Core PR Review Club][]-Meeting zusammen, und heben einige wichtige Fragen und Antworten hervor. Klicken Sie auf eine Frage, um eine Zusammenfassung der Antwort aus dem Meeting zu sehen.* + +[Add Fee rate Forecaster Manager][review club 31664] ist ein PR von [ismaelsadeeq][gh ismaelsadeeq], der die Logik zur Transaktionsgebühr-Vorhersage (auch [Schätzung][topic fee estimation] genannt) verbessert. Es führt eine neue `ForecasterManager`-Klasse ein, bei der mehrere `Forecaster` registriert werden können. Der bestehende `CBlockPolicyEstimator` (der nur bestätigte Transaktionen betrachtet) wird zu einem solchen Forecaster umgebaut, aber insbesondere wird ein neuer `MemPoolForecaster` eingeführt. `MemPoolForecaster` berücksichtigt unbestätigte Transaktionen im Mempool und kann daher schneller auf Änderungen der Feerate reagieren. + +{% include functions/details-list.md + q0="Warum heißt das neue System „Forecaster“ und „ForecasterManager“ statt „Estimator“ und „Fee Estimation Manager“?" + a0=" Das System zeigt an, was in Zukunft passieren wird. Dafür benutzt es aktuelle und vergangene Daten. Ein Forecaster ist anders als ein Estimator. Ein Forecaster zeigt zukünftige Ereignisse an. Das ist die prädiktive Natur dieses Systems. Und es zeigt Unsicherheits-/Risikolevels an. Im Gegensatz zu einem Estimator, der aktuelle Bedingungen mit Zufall approximiert, projiziert ein Forecaster zukünftige Ereignisse, was der prädiktiven Natur dieses Systems und seiner Ausgabe von Unsicherheits-/Risikolevels entspricht." + a0link="https://bitcoincore.reviews/31664#l-19" + + q1="Warum wird `CBlockPolicyEstimator` nicht so geändert, dass er eine Referenz auf den Mempool hält, ähnlich wie in PR #12966? Was ist der aktuelle Ansatz und warum ist er besser als eine Referenz auf den Mempool zu halten? (Hinweis: siehe PR #28368)" + a1="`CBlockPolicyEstimator` erbt von `CValidationInterface` und implementiert dessen virtuelle Methoden `TransactionAddedToMempool`, `TransactionRemovedFromMempool` und `MempoolTransactionsRemovedForBlock`. Das gibt `CBlockPolicyEstimator` alle nötigen Mempool-Informationen, ohne unnötig eng an den Mempool gekoppelt zu sein." + a1link="https://bitcoincore.reviews/31664#l-26" + + q2="Was sind die Vor- und Nachteile der neuen Architektur im Vergleich zu einer direkten Änderung von `CBlockPolicyEstimator`?" + a2="Die neue Architektur mit einer `FeeRateForecasterManager`-Klasse, bei der mehrere `Forecaster` registriert werden können, ist modularer, besser testbar und erzwingt eine bessere Trennung der Verantwortlichkeiten. Sie ermöglicht es, später einfach neue Vorhersagestrategien einzubinden. Das geht auf Kosten von etwas mehr Code und potenziell verwirrten Nutzern bezüglich der zu verwendenden Schätzmethode." + a2link="https://bitcoincore.reviews/31664#l-43" +%} + +{% assign timestamp="29:33" %} + +## Veröffentlichungen und Release-Kandidaten + +_Neue Veröffentlichungen und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie ein Upgrade auf neue Versionen oder helfen Sie bei der Testung von Release-Kandidaten._ + +- [Core Lightning 25.02.1][] ist ein Wartungsrelease für die aktuelle Hauptversion dieses beliebten LN-Knotens, das mehrere Fehlerbehebungen enthält. {% assign timestamp="46:54" %} + +- [Core Lightning 24.11.2][] ist ein Wartungsrelease für eine frühere Hauptversion dieses beliebten LN-Knotens. Es enthält mehrere Fehlerbehebungen, einige davon sind die gleichen wie in Version 25.02.1. {% assign timestamp="47:03" %} + +- [BTCPay Server 2.1.0][] ist ein Major Release dieser selbstgehosteten Zahlungsabwicklungssoftware. Es enthält Breaking Changes für Nutzer einiger Altcoins, Verbesserungen für [RBF][topic rbf] und [CPFP][topic cpfp] Fee-Bumping sowie einen besseren Ablauf für Multisig, wenn alle Signierer BTCPay Server verwenden. {% assign timestamp="48:14" %} + +- [Bitcoin Core 29.0rc3][] ist ein Release-Kandidat für die nächste Hauptversion des dominierenden Full Nodes im Netzwerk. Siehe den [Version 29 Testleitfaden][bcc29 testing guide]. {% assign timestamp="49:25" %} + +- [LND 0.19.0-beta.rc2][] ist ein Release-Kandidat für diesen beliebten LN-Knoten. Eine der wichtigsten Verbesserungen, die getestet werden sollten, ist das neue RBF-basierte Fee-Bumping für kooperative Schließungen. {% assign timestamp="51:21" %} + +## Wichtige Code- und Dokumentationsänderungen + +_Bedeutende kürzliche Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und [BINANAs][binana repo]._ + +- [LDK #2256][] und [LDK #3709][] verbessern die Zuordenbarkeit von Fehlern (siehe [Newsletter #224][news224 failures]), wie in [BOLTs #1044][] spezifiziert, indem sie ein optionales `attribution_data`-Feld zur `UpdateFailHTLC`-Struktur und die `AttributionData`-Struktur einführen. In diesem Protokoll fügt jeder weiterleitende Knoten der Fehlermeldung ein `hop_payload`-Flag, ein Dauerfeld (wie lange der Knoten das HTLC gehalten hat) und HMACs für verschiedene angenommene Positionen in der Route hinzu. Wenn ein Knoten die Fehlermeldung beschädigt, hilft die Abweichung in der HMAC-Kette, das Knoten-Paar zu identifizieren, zwischen dem dies geschah. {% assign timestamp="53:52" %} + +- [LND #9669][] stuft [Simple Taproot Channels][topic simple taproot channels] so zurück, dass immer der Legacy-Cooperative-Close-Flow verwendet wird, auch wenn der [RBF][topic rbf] Cooperative-Close-Flow (siehe [Newsletter #347][news347 coop]) konfiguriert ist. Zuvor konnte ein Knoten, bei dem beide Features konfiguriert waren, nicht starten. {% assign timestamp="56:16" %} + +- [Rust Bitcoin #4302][] fügt der Script-Builder-API eine neue Methode `push_relative_lock_time()` hinzu, die einen relativen [Timelock][topic timelocks] als Parameter nimmt, und depreziert `push_sequence()`, die eine rohe Sequenznummer als Parameter nimmt. Diese Änderung behebt eine potenzielle Verwirrung, bei der Entwickler versehentlich eine rohe Sequenznummer in Skripte einfügen, anstatt eines relativen Timelock-Wertes, der dann mit `CHECKSEQUENCEVERIFY` gegen die Sequenznummer eines Inputs geprüft wird. {% assign timestamp="57:24" %} + +{% include snippets/recap-ad.md when="2025-04-15 15:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="2256,3709,9669,4302,1044" %} +[bitcoin core 29.0rc3]: https://bitcoincore.org/bin/bitcoin-core-29.0/ +[bcc29 testing guide]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/29.0-Release-Candidate-Testing-Guide +[lnd 0.19.0-beta.rc2]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc2 +[wuille muhash]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014337.html +[falbesoner ss1]: https://delvingbitcoin.org/t/ibd-booster-speeding-up-ibd-with-pre-generated-hints-poc/1562/ +[somsen ssgist]: https://gist.github.com/RubenSomsen/a61a37d14182ccd78760e477c78133cd +[falbesoner ss2]: https://delvingbitcoin.org/t/ibd-booster-speeding-up-ibd-with-pre-generated-hints-poc/1562/7 +[assumevalid]: https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks +[cryptographic accumulator]: https://en.wikipedia.org/wiki/Accumulator_(cryptography) +[news123 muhash]: /en/newsletters/2020/11/11/#bitcoin-core-pr-review-club +[muhash]: https://cseweb.ucsd.edu/~mihir/papers/inchash.pdf +[generalized birthday attack]: https://www.iacr.org/archive/crypto2002/24420288/24420288.pdf +[somsen ss1]: https://delvingbitcoin.org/t/ibd-booster-speeding-up-ibd-with-pre-generated-hints-poc/1562/2 +[obeirne ss]: https://delvingbitcoin.org/t/ibd-booster-speeding-up-ibd-with-pre-generated-hints-poc/1562/5 +[somsen ss2]: https://delvingbitcoin.org/t/ibd-booster-speeding-up-ibd-with-pre-generated-hints-poc/1562/6 +[b10c ss]: https://delvingbitcoin.org/t/ibd-booster-speeding-up-ibd-with-pre-generated-hints-poc/1562/4 +[somsen ssml]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPv7TjaM0tfbcBTRa0_713Bk6Y9jr+ShOC1KZi2V3V2zooTXyg@mail.gmail.com/T/#u +[core lightning 25.02.1]: https://github.com/ElementsProject/lightning/releases/tag/v25.02.1 +[core lightning 24.11.2]: https://github.com/ElementsProject/lightning/releases/tag/v24.11.2 +[btcpay server 2.1.0]: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.1.0 +[news224 failures]: /de/newsletters/2022/11/02/#zuordnung-von-ln-routing-fehlern +[news347 coop]: /de/newsletters/2025/03/28/#lnd-8453 +[review club 31664]: https://bitcoincore.reviews/31664 +[gh ismaelsadeeq]: https://github.com/ismaelsadeeq +[forecastresult compare]: https://github.com/bitcoin-core-review-club/bitcoin/commit/1e6ce06bf34eb3179f807efbddb0e9bca2d27f28#diff-5baaa59bccb2c7365d516b648dea557eb50e63837de71531dc460dbcc62eb9adR74-R77 From b2fde35717145af227ef97babd08aa28b83abe19 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Mon, 2 Jun 2025 11:54:35 -0500 Subject: [PATCH 044/278] Podcast: add 355 recap --- .../en/newsletters/2025-05-23-newsletter.md | 36 +++++++++---------- .../en/podcast/2025-05-27-newsletter-recap.md | 23 ++++++++++++ 2 files changed, 41 insertions(+), 18 deletions(-) create mode 100644 _posts/en/podcast/2025-05-27-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-05-23-newsletter.md b/_posts/en/newsletters/2025-05-23-newsletter.md index 9e119ea5b5..acd6b2f3f8 100644 --- a/_posts/en/newsletters/2025-05-23-newsletter.md +++ b/_posts/en/newsletters/2025-05-23-newsletter.md @@ -23,39 +23,39 @@ wallets and services.* - **Cake Wallet added payjoin v2 support:** Cake Wallet [v4.28.0][cake wallet 4.28.0] adds [the ability][cake blog] to - receive payments using the [payjoin][topic payjoin] v2 protocol. + receive payments using the [payjoin][topic payjoin] v2 protocol. {% assign timestamp="2:38" %} - **Sparrow adds pay-to-anchor features:** Sparrow [2.2.0][sparrow 2.2.0] displays and can send [pay-to-anchor - (P2A)][topic ephemeral anchors] outputs. + (P2A)][topic ephemeral anchors] outputs. {% assign timestamp="6:37" %} - **Safe Wallet 1.3.0 released:** [Safe Wallet][safe wallet github] is a desktop multisig wallet with hardware signing device support that added [CPFP][topic cpfp] fee bumping for incoming - transactions in [1.3.0][safe wallet 1.3.0]. + transactions in [1.3.0][safe wallet 1.3.0]. {% assign timestamp="8:00" %} - **COLDCARD Q v1.3.2 released:** COLDCARD Q's [v1.3.2 release][coldcard blog] includes additional multisig [spending policy support][coldcard ccc] and new features for [sharing - sensitive data][coldcard kt]. + sensitive data][coldcard kt]. {% assign timestamp="9:15" %} - **Transaction batching using payjoin:** [Private Pond][private pond post] is an [experimental implementation][private pond github] of a [transaction batching][topic payment batching] service that - uses payjoin to generate smaller transactions that pay less in fees. + uses payjoin to generate smaller transactions that pay less in fees. {% assign timestamp="19:07" %} - **JoinMarket Fidelity Bond Simulator:** The [JoinMarket Fidelity Bond Simulator][jmfbs github] provides tools for JoinMarket participants to simulate their performance in the market based on - [fidelity bonds][news161 fb]. + [fidelity bonds][news161 fb]. {% assign timestamp="20:45" %} - **Bitcoin opcodes documented:** The [Opcode Explained][opcode explained website] website documents - each Bitcoin script opcode. + each Bitcoin script opcode. {% assign timestamp="26:39" %} - **Bitkey code open sourced:** The Bitkey hardware signing device [announced][bitkey blog] their [source - code][bitkey github] is open-source for non-commercial uses. + code][bitkey github] is open-source for non-commercial uses. {% assign timestamp="27:59" %} ## Releases and release candidates @@ -65,10 +65,10 @@ release candidates._ - [LND 0.19.0-beta][] is the latest major release of this popular LN node. Its contains many [improvements][lnd rn] and bug fixes, - including new RBF-based fee bumping for cooperative closes. + including new RBF-based fee bumping for cooperative closes. {% assign timestamp="33:43" %} - [Core Lightning 25.05rc1][] is a release candidate for the next major - version of this popular LN node implementation. + version of this popular LN node implementation. {% assign timestamp="40:12" %} ## Notable code and documentation changes @@ -87,7 +87,7 @@ repo], and [BINANAs][binana repo]._ deprecated when `rpcauth` was introduced in [Bitcoin Core #7044][], which supports multiple RPC users and hashes its cookie. The PR also adds a random 16-byte salt to credentials from both methods and hashes them before they’re - stored in memory. + stored in memory. {% assign timestamp="46:47" %} - [Bitcoin Core #31444][] extends the `TxGraph` class (see Newsletter [#348][news348 txgraph]) with three new helper functions: @@ -97,7 +97,7 @@ repo], and [BINANAs][binana repo]._ for optimized block construction, and `GetWorstMainChunk()` pinpoints the lowest feerate chunk for eviction decisions. This PR is one of the final building blocks of the full initial implementation of the [cluster mempool][topic - cluster mempool] project. + cluster mempool] project. {% assign timestamp="49:51" %} - [Core Lightning #8140][] enables [peer storage][topic peer storage] of channel backups by default (see Newsletter [#238][news238 storage]), making it viable @@ -105,18 +105,18 @@ repo], and [BINANAs][binana repo]._ caching backups and peer lists in memory instead of making repeated `listdatastore`/`listpeerchannels` calls, capping concurrent backup uploads at two peers, skipping backups larger than 65 kB, and randomizing peer selection when - sending. + sending. {% assign timestamp="52:08" %} - [Core Lightning #8136][] updates the exchange of announcement signatures to occur when the channel is ready rather than after six blocks, to align with the recent [BOLTs #1215][] specification update. It's still required to wait - six blocks to [announce the channel][topic channel announcements]. + six blocks to [announce the channel][topic channel announcements]. {% assign timestamp="54:16" %} - [Core Lightning #8266][] adds an `update` command to the Reckless plugin manager (see Newsletter [#226][news226 reckless]) that updates a specified plugin or all installed plugins if none is specified, except those installed from a fixed Git tag or commit. This PR also extends the `install` command to - take a source path or URL in addition to a plugin name. + take a source path or URL in addition to a plugin name. {% assign timestamp="55:52" %} - [Core Lightning #8021][] finalizes [splicing][topic splicing] interoperability with Eclair (see Newsletter [#331][news331 interop]) by fixing the rotation of @@ -125,14 +125,14 @@ repo], and [BINANAs][binana repo]._ splicing]), relaxing the requirement that commitment-signed messages arrive in a particular order, enabling receiving and initiating splice [RBF][topic rbf] transactions, automatically converting outgoing [PSBTs][topic psbt] to version - 2 when needed, and other refactoring changes. + 2 when needed, and other refactoring changes. {% assign timestamp="58:38" %} - [Core Lightning #8226][] implements [BIP137][] by adding a new `signmessagewithkey` RPC command that allows users to sign messages with any key from the wallet by specifying a Bitcoin address. Previously, signing a message with a Core Lightning key required finding the xpriv and the key index, deriving the private key with an external library, and then signing the - message with Bitcoin Core. + message with Bitcoin Core. {% assign timestamp="1:01:29" %} - [LND #9801][] adds a new `--no-disconnect-on-pong-failure` option, which controls whether a peer is disconnected if a pong response is late or @@ -140,7 +140,7 @@ repo], and [BINANAs][binana repo]._ behavior of LND disconnecting from a peer on a pong message failure (see Newsletter [#275][news275 ping]); otherwise, LND would only log the event. The PR refactors the ping watchdog to continue its loop when disconnection is - suppressed. + suppressed. {% assign timestamp="1:02:54" %} {% include snippets/recap-ad.md when="2025-05-27 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-05-27-newsletter-recap.md b/_posts/en/podcast/2025-05-27-newsletter-recap.md new file mode 100644 index 0000000000..a65268bd3f --- /dev/null +++ b/_posts/en/podcast/2025-05-27-newsletter-recap.md @@ -0,0 +1,23 @@ +--- +title: 'Bitcoin Optech Newsletter #355 Recap Podcast' +permalink: /en/podcast/2025/05/27/ +reference: /en/newsletters/2025/05/23/ +name: 2025-05-27-recap +slug: 2025-05-27-recap +type: podcast +layout: podcast-episode +lang: en +--- +Dave Harding is joined by Alex Myers and Rodolfo Novak to discuss [Newsletter #355]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-5-2/401443098-44100-2-83c29b547d91e.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From ecf5f340e04c0534350b8bb418a78c5bb83c632f Mon Sep 17 00:00:00 2001 From: Walpurga03 Date: Mon, 2 Jun 2025 22:34:04 +0200 Subject: [PATCH 045/278] Add German newsletter 352 --- STYLE-DE.md | 3 +- .../de/newsletters/2025-05-02-newsletter.md | 56 +++++++++++++++++++ 2 files changed, 58 insertions(+), 1 deletion(-) create mode 100644 _posts/de/newsletters/2025-05-02-newsletter.md diff --git a/STYLE-DE.md b/STYLE-DE.md index d1523cbaae..7e2ee910c7 100644 --- a/STYLE-DE.md +++ b/STYLE-DE.md @@ -62,7 +62,7 @@ deutschen Bitcoin-Szene etabliert haben. Für einige Begriffe werden folgende | lightning network | Lightning Netzwerk | | | | node | Knoten | Node | | | relay | Weiterleitung | | | -| output | Ausgabe | Output | Im Kontext von UTXO | +| input/output | | | | | silent payment | Stille Zahlung | | | | UTXO | | | Genus Maskulinum | | wallet | Wallet | Geldbörse | Genus Neutrum | @@ -73,6 +73,7 @@ deutschen Bitcoin-Szene etabliert haben. Für einige Begriffe werden folgende | Tapscript | | | | | Orakel-Bestätigung | | | | | Timelock | | | | +| non-custodial | non-custodial | nicht-verwahrt | ist im deutschsprachigen Raum etablierte | ### Nicht übersetzte Begriffe diff --git a/_posts/de/newsletters/2025-05-02-newsletter.md b/_posts/de/newsletters/2025-05-02-newsletter.md new file mode 100644 index 0000000000..acd373dba7 --- /dev/null +++ b/_posts/de/newsletters/2025-05-02-newsletter.md @@ -0,0 +1,56 @@ +--- +title: 'Bitcoin Optech Newsletter #352' +permalink: /de/newsletters/2025/05/02/ +name: 2025-05-02-newsletter-de +slug: 2025-05-02-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche verweist auf Vergleiche verschiedener Cluster-Linearisationstechniken und fasst kurz die Diskussion über die Erhöhung oder Abschaffung des `OP_RETURN`-Größenlimits in Bitcoin Core zusammen. Ebenfalls enthalten sind unsere regulären Abschnitte mit Ankündigungen neuer Releases und Release-Kandidaten sowie Zusammenfassungen wichtiger Änderungen an populärer Bitcoin-Infrastruktur. + +## Nachrichten + +- **Vergleich von Cluster-Linearisationstechniken:** + Pieter Wuille [veröffentlichte][wuille clustrade] auf Delving Bitcoin einige grundlegende Abwägungen zwischen drei verschiedenen Cluster-Linearisationstechniken und ergänzte dies durch [Benchmarks][wuille clusbench] der jeweiligen Implementierungen. Mehrere andere Entwickler diskutierten die Ergebnisse und stellten Rückfragen, auf die Wuille antwortete. {% assign timestamp="0:41" %} + +- **Erhöhung oder Abschaffung des `OP_RETURN`-Größenlimits in Bitcoin Core:** + In einem Thread auf der Bitcoin-Dev-Mailingliste diskutierten mehrere Entwickler, das Standardlimit für `OP_RETURN`-Data-Carrier-Outputs in Bitcoin Core zu ändern oder ganz abzuschaffen. Eine nachfolgende [Pull-Request-Diskussion][bitcoin core #32359] brachte weitere Argumente. Anstatt die gesamte umfangreiche Diskussion zusammenzufassen, stellen wir das aus unserer Sicht überzeugendste Argument für und gegen die Änderung vor. + + - *Für die Erhöhung (oder Abschaffung) des Limits:* + Pieter Wuille [argumentierte][wuille opr], dass die Standardness-Policy von Transaktionen kaum verhindern kann, dass gut finanzierte Organisationen Daten tragende Transaktionen direkt an Miner senden und so in Blöcke bringen. Außerdem seien Blöcke ohnehin meist voll, egal ob sie Daten enthalten oder nicht, sodass sich die Gesamtmenge der zu speichernden Daten für einen Knoten kaum ändert. + + - *Gegen die Erhöhung des Limits:* + Jason Hughes [argumentierte][hughes opr], dass eine Erhöhung des Limits es einfacher machen würde, beliebige Daten auf Rechnern zu speichern, die Full Knoten betreiben – darunter auch potenziell anstößige oder in vielen Ländern illegale Inhalte. Selbst wenn der Knoten die Daten auf der Festplatte verschlüsselt (siehe [Newsletter #316][news316 blockxor]), könnte das Speichern und Abrufen solcher Daten über Bitcoin Core RPCs für viele Nutzer problematisch sein. + +{% assign timestamp="6:46" %} + +## Veröffentlichungen und Release-Kandidaten + +_Neue Veröffentlichungen und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie ein Upgrade auf neue Versionen oder helfen Sie bei der Testung von Release-Kandidaten._ + +- [LND 0.19.0-beta.rc3][] ist ein Release-Kandidat für diesen beliebten LN-Knoten. Eine der wichtigsten Verbesserungen, die getestet werden sollten, ist das neue RBF-basierte Fee-Bumping für kooperative Schließungen. {% assign timestamp="1:01:16" %} + +## Wichtige Code- und Dokumentationsänderungen + +_Bedeutende kürzliche Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und [BINANAs][binana repo]._ + +- [Bitcoin Core #31250][] deaktiviert die Erstellung und das Laden von Legacy-Wallets und schließt damit die Migration zu [Deskriptor][topic descriptors]-Wallets ab, die seit Oktober 2021 Standard sind (siehe Newsletter [#172][news172 descriptors]). Berkeley DB-Dateien von Legacy-Wallets können nicht mehr geladen werden, und alle Unit- und Funktionstests für Legacy-Wallets werden entfernt. Ein Teil des Legacy-Wallet-Codes bleibt noch erhalten, wird aber in Folge-PRs entfernt. Bitcoin Core kann weiterhin Legacy-Wallets in das neue Deskriptor-Wallet-Format migrieren (siehe [Newsletter #305][news305 bdbro]). {% assign timestamp="1:02:10" %} + +- [Eclair #3064][] überarbeitet das Channel-Key-Management durch Einführung einer `ChannelKeys`-Klasse. Jeder Channel hat nun ein eigenes `ChannelKeys`-Objekt, das zusammen mit den Commitment-Points ein `CommitmentKeys`-Set für die Signierung von Remote/Local-Commitment- und [HTLC][topic htlc]-Transaktionen ableitet. Die Logik für Zwangsschließungen und das Erstellen von Script/Witness wird ebenfalls angepasst. Zuvor war die Schlüsselerzeugung auf mehrere Teile des Codes verteilt, was fehleranfällig war, da die richtige Pubkey-Übergabe nicht typgesichert war. {% assign timestamp="1:06:02" %} + +- [BTCPay Server #6684][] fügt Unterstützung für einen Teil der [BIP388][]-Wallet-Policy-[Deskriptoren][topic descriptors] hinzu, sodass Nutzer sowohl Single-Sig- als auch k-of-n-Policies importieren und exportieren können. Unterstützt werden die von Sparrow verwendeten Formate wie P2PKH, P2WPKH, P2SH-P2WPKH und P2TR sowie die entsprechenden Multisig-Varianten (außer P2TR). Ziel dieses PR ist die Verbesserung der Multisig-Wallet-Nutzung. {% assign timestamp="1:07:46" %} + +- [BIPs #1555][] merged [BIP321][], das ein URI-Schema für Bitcoin-Zahlungsanweisungen vorschlägt, das [BIP21][] modernisiert und erweitert. Es behält den alten pfadbasierten Adressstil bei, standardisiert aber die Nutzung von Query-Parametern, sodass neue Zahlungsarten über eigene Parameter identifiziert werden können. Das Adressfeld kann leer bleiben, wenn mindestens eine Anweisung als Query-Parameter angegeben ist. Optional kann ein Zahlungsnachweis für den Sender bereitgestellt werden, und es gibt Hinweise zur Integration neuer Zahlungsanweisungen. {% assign timestamp="1:10:34" %} + +{% include snippets/recap-ad.md when="2025-05-06 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31250,3064,6684,1555,32359" %} +[lnd 0.19.0-beta.rc3]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc3 +[wuille clustrade]: https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/68 +[wuille clusbench]: https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/73 +[hughes opr]: https://mailing-list.bitcoindevs.xyz/bitcoindev/f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n@googlegroups.com/ +[wuille opr]: https://mailing-list.bitcoindevs.xyz/bitcoindev/QMywWcEgJgWmiQzASR17Dt42oLGgG-t3bkf0vzGemDVNVnvVaD64eM34nOQHlBLv8nDmeBEyTXvBUkM2hZEfjwMTrzzoLl1_62MYPz8ZThs=@wuille.net/ +[news316 blockxor]: /en/newsletters/2024/08/16/#bitcoin-core-28052 +[news172 descriptors]: /en/newsletters/2021/10/27/#bitcoin-core-23002 +[news305 bdbro]: /en/newsletters/2024/05/31/#bitcoin-core-26606 From d58652cfe37fc3e34c12219d5adb2d3bd974617d Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Mon, 2 Jun 2025 13:04:58 -0500 Subject: [PATCH 046/278] Podcast: add 354 transcription --- .../en/podcast/2025-05-20-newsletter-recap.md | 1226 ++++++++++++++++- 1 file changed, 1225 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-05-20-newsletter-recap.md b/_posts/en/podcast/2025-05-20-newsletter-recap.md index fe26a1e7a0..ee67acd887 100644 --- a/_posts/en/podcast/2025-05-20-newsletter-recap.md +++ b/_posts/en/podcast/2025-05-20-newsletter-recap.md @@ -19,6 +19,1230 @@ Stewart, Bram Cohen, and Robin Linus to discuss [Newsletter #354]({{page.referen ## Transcription -_transcription coming soon_ + +**Mike Schmidt**: Welcome everyone to Bitcoin Optech Newsletter #354 Recap on +Riverside. Today, we're going to talk about a Bitcoin Core vulnerability that's +been recently disclosed; we have a draft BIP for 64-bit arithmetic in Bitcoin; +we have a new approach to recursive covenants; we're going to talk about the +benefits to BitVM from the CTV (CHECKTEMPLATEVERIFY) and CSFS +(CHECKSIGFROMSTACK) proposals; and we have our usual Releases and Notable code +segments as well. I'm Mike Schmidt, Optech contributor and Brink Executive +Director. Murch? + +**Mark Erhardt**: Hi, I'm Murch, I work at Localhost and on Bitcoin stuff. + +**Mike Schmidt**: Eugene? + +**Eugene Siegel**: I'm Eugene, I work on Bitcoin Core and I'm supported by +Brink. + +**Mike Schmidt**: Chris? + +**Chris Stewart**: Hi, my name is Chris Stewart and I'm an independent +researcher on Bitcoin. + +**Mike Schmidt**: Bram? + +**Bram Cohen**: I'm Bram Cohen, I created BitTorrent back in the day and I'm +working on a blockchain gaming project. + +**Mike Schmidt**: Robin? + +**Robin Linus**: Hi, I'm Robin, I work at ZeroSync on BitVM and I'm also the +Bitcoin researcher at Stanford. + +_Vulnerability disclosure affecting old versions of Bitcoin Core_ + +**Mike Schmidt**: Awesome. Thank you all for joining us to represent your work +and ideas this week. We have one news item, which is titled, "Vulnerability +disclosure affecting old versions of Bitcoin Core". Antoine hosted a +vulnerability disclosure to the Bitcoin-Dev mailing list in accordance with +Bitcoin Core's recent security disclosure policy. The vulnerability is of low +severity and was fixed in Bitcoin Core 29.0. So, versions before that are +affected. Eugene, awesome that you found this bug and were able to join us +today. What did you find this time? + +**Eugene Siegel**: So, it's the same bug as was reported earlier. It's just +that Pieter Wuille introduced rate limiting. And so now, if you wait enough +time, you can overflow the 32-bit counter to defeat the rate limiting, over the +course of maybe a year. And it's laid out in the in the disclosure that if you +have, like, 1,000 peers connecting and they're spamming you with addr messages +this entire time, it would take a very long time for your node to crash. So, it +is a very low severity bug. So, yeah, the fix was done by Martin and it was a +change from 32-bit counter in the AddrMan to a 64-bit counter. + +**Mike Schmidt**: So, it's low severity in that it would take a long time to +occur and many parties doing something for a long period of time, but obviously +the fact that it would crash is severe, but it's just sort of a less likely to +happen type scenario. + +**Eugene Siegel**: Right. And so, it is very unlikely to happen, it would take +a very long time. And I believe your node would have to be up the entire time. +So, if you restarted it to do, like, an upgrade to 29.0, the attacker's progress +is basically lost. And there was actually one way to trigger the crash that +wasn't really laid out in the disclosure by Antoine. And it was that if you +gave a peer the addr permission flag, you could crash them as well, but that +requires social engineering. But anyways, the issue is fixed now completely. + +**Mike Schmidt**: Okay. And for those curious about what Eugene was referencing +about this other issue, it was in Newsletter #314, that we covered the 'before +22.0 disclosures' in Bitcoin Core, and I believe, Eugene, were you on for that +one? + +**Eugene Siegel**: I don't think I was. + +**Mike Schmidt**: Okay. Yeah, I guess, Murch, it was you and I talking about +that particular one. How did you find this particular vulnerability? + +**Eugene Siegel**: That one, I had literally printed out the AddrMan file and +then just read it line by line. I think we could have written a test, or I +could have written a test, where you have a single node getting spammed over the +course of some amount of time. The issue here is that a fuzzer would not catch +this, because you're sending many addr messages, and when we're writing fuzzers, +we're trying to optimize for very quick execution. And so, something like a +fuzz test would not have caught this, at least how they're currently written. + +**Mike Schmidt**: Murch, any questions or follow-up? All right, great. Eugene, +thanks for joining us today. You're welcome to stay on for the rest of the +discussion, or if you have things to do, we understand, and you're free to drop. + +**Eugene Siegel**: I'm going to drop. + +_Proposed BIP for 64-bit arithmetic in Script_ + +**Mike Schmidt**: We're going to move to our monthly segment on Changing +consensus this week. First one is titled, "Proposed BIP for 64-bit arithmetic +in script". Chris, we've talked about this a few times with you. We +highlighted your ideas on adding 64-bit numbers to Bitcoin Script in Newsletters +#285, #290, and #306. And I think we had you on as a guest for Podcast #285 and +#290 as well. But this week, we covered your post to the Bitcoin-Dev mailing +list about a draft BIP for a soft fork proposal for doing operations on 64-bit +numbers in Bitcoin. In your email, you noted, "The purpose for this BIP is to +lay the groundwork for introducing amounts to script. This document takes no +opinion on how this is done". Maybe you can remind us why we would want +something like amounts in script, and then maybe you can jump into some of the +BIP details? + +**Chris Stewart**: Yeah. So, allowing amounts in script would allow us to do +interesting contracting schemes. Like, for instance, any covenant scheme has +two components to it. The first component is usually restricting where the +funds go, and the second part of any covenant scheme is how much of the funds +are going there. So, I'm interested in the latter part, how much of the funds +are going to a specific place. And to be able to do that programmably, we've +got to be able to introduce logic, either in validation.cpp or in the +interpreter itself, of restricting how much funds can flow places. I think in +the 64-bit proposal, I have I think four different proposals that are currently +out there as soft fork proposals for laying out how to do different amount locks +in Bitcoin. One is OP_INOUT_AMOUNT, another one is OP_CTV, which is pretty +popular. Let's see, I'm blanking on the other two right now, but they're in the +document. And 64-bit arithmetic has been talked about for a while now, +introducing it into script. I think it's actually cited in BIP341 or 342, the +tapscript document, that a future proposal we may want to add. And I think that +since a variety of soft fork proposals now have actually introduced 64-bit +support in small ways, such as OP_VAULT, James O'Beirne and Greg Sanders' BIP, +and like I said earlier, OP_CTV. + +I thought I'd factor all this stuff out, put it into a single document, and +hopefully kind of encapsulate and modularize this precision enhancement in +Bitcoin. And that's what I've done with that, posting it to the Bitcoin mailing +list and putting together the draft BIP proposal. + +**Mike Schmidt**: Bram or Robin, I don't know if you, as fellow scriptors, have +any feedback on Chris's general idea or if you had a chance to check out the +draft BIP? + +**Bram Cohen**: I slightly embarrassingly was not really aware that Bitcoin +didn't really have good integer math support already. + +**Chris Stewart**: And Bram, you're not alone. Right now, the supported +precision is 231-1. And to support satoshi mathematical values, we +need a 51-bit precision, if I remember correctly. So, 64-bit gets us to be able +to support the precision that would be required for doing math on satoshis. +Rusty Russell, who has a kind of competing proposal, I'd call it, called the +Great Script Restoration Project, he claims that 64-bit arithmetic could be done +in the current script in a very ugly and, let's say, ingenious way. I've not +checked it myself to make sure that this proof of concept is possible. However, +I don't think that should prevent us from just natively supporting 64-bit +arithmetic. There are, again, like I said, competing proposals for expanding +precision to arbitrary amounts. I'm not necessarily against those. My BIP, the +purpose is to be simple, straightforward, to the point, and hopefully not +controversial, and could be pulled into a wider soft fork deployment if it makes +sense, for instance, deploying one of these covenant opcodes. + +**Bram Cohen**: Yeah, you can kind of hack it with OP_CAT just by putting zeros, +or whatever. + +**Chris Stewart**: Yeah, and I took a holistic approach to this proposal, like +all of the currently supported opcodes, such as OP_ADD, OP_SUB, OP_GREATER_THAN, +all those comparison opcodes work with them. This proposal, they've all been +upgraded to support 64-bit arithmetic, so it would be a very holistic, +everything now supports the same precision, rather than kind of a piecemeal +approach, which is kind of what OP_VAULT was doing with introducing their +Revault amount onto the stack. + +**Robin Linus**: I'm actually painfully aware of the limits of arithmetic in +Bitcoin Script. For BitVM, we have implemented 256-bit field multiplication +using just addition. And that's like, I think, 70,000 opcodes or so for +multiplication. And so, the first thing I wondered, does your BIP support +multiplication? + +**Chris Stewart**: It does not support -- did you enable this by OP_MUL, or is +that what you're kind of thinking, an OP_MUL opcode, or are you thinking about a +specific? No. So, again, I'm a big believer BIPs should be about one thing, +one simple thing. I think OP_MUL could be enabled based off of this BIP if it +was necessary, but I do view them as two separate things, and I like to keep +BIPs simple, and hopefully that invites less contention into one specific BIP. + +**Robin Linus**: I would still reduce our multiplication from 70k opcodes down +to roughly 35k opcodes, I guess. So, it's still a win. + +**Chris Stewart**: Yeah, that sounds like a win to me. + +**Mike Schmidt**: Speaking of controversy or not, Chris, how has the feedback +been to the mailing list post and the draft BIP? + +**Chris Stewart**: I think when I last was on Optech, there was a lot more +controversy, because I had, let's say, a wider scope to this BIP proposal, such +as reworking the serialization format, did we do signed versus unsigned numbers +for instance; Bitcoin Script currently supports signed numbers. There's some +people that want to do just unsigned numbers. I got rid of all of the signed +versus unsigned stuff, or reworking the serialization format, in hopes to +reducing the amount of controversy that could be introduced to oppose the PR. +So, now it strictly extends the precision. I have not had as much feedback on +the mailing list about just this proposal that I posted last week. I've had a +few people ask about the Great Script Restoration Project and why not go that +direction. I am not aware of that being worked on currently. I have reached +out to Rusty and I've not got a reply back. So, it's kind of unclear to me what +the state of that project is. And that's the main feedback that I've got so +far. + +**Robin Linus**: How do you deal with overflows? Currently in Bitcoin Script, +if a 4-byte number overflows, it becomes a 5-byte number, and then you cannot +use it in arithmetic opcodes anymore. + +**Chris Stewart**: We retain the overflow semantics. I actually have a +Delving-Bitcoin post about reworking the overflow semantics. If you're +interested in that topic, please check it out. It has not got any responses +yet. I think the Elements project is taking an interesting approach to dealing +with overflows. The overflow handling was actually in my original +Delving-Bitcoin post about 12 to 18 months ago, and I got rid of it because I +just wanted to focus strictly on extending precision to just support as wide an +amount of use cases as possible that's being asked for today. However, I think +if we were going to do a soft fork deployment with this BIP in it, maybe it +makes sense to rework overflow semantics in a separate BIP and deploy them +together. This BIP that I currently have drafted excludes reworking overflow +semantics, but I do think it's a separate topic to be broached and probably will +invite more controversy, unfortunately. + +**Robin Linus**: Do you have a suggestion for other overflow semantics? + +**Chris Stewart**: I'm a personal fan of the Elements overflow semantics. What +they do is after every arithmetic operation, they push a boolean value onto the +stack indicating if there was an overflow or not. That means, so maybe the +downsides, if you want to look at it as this, is you've got to wrap everything +in an OP_IF, OP_ELSE, or that kind of logic, or you've got OP_DROPs everywhere +if you want to be writing unsafe code. I think we should, as Bitcoin protocol +developers, we should give developers the tools to be able to write safe code if +they want to. And if they want to just vibe code or YOLO it, or whatever the +kids are calling it these days, they can. However, if you're serious about +things, hopefully we can provide tools for those people to do things in a safe +way. + +**Mark Erhardt**: Why would you not just fail if it overflows? + +**Chris Stewart**: I think in that case -- I just don't think we should make +such broad assumptions of people's use cases. Maybe in certain cases there've +been overflows, they want to do other logic. And if you give people an OP_TRUE +on the stack or an OP_FALSE on the stack, you put it in the hands of the +developer to handle that case, rather than us dictating to developers, "This is +the way it must be done. You must fail if it overflows". + +**Mark Erhardt**: It does introduce a lot of extra crud into the script though. +And if it just fails for overflows because it's, well, underdefined or not +possible, I think it might fit better with the Bitcoin philosophy that +calculations should mostly happen outside of the on-protocol script. But yeah, +I haven't looked too deeply into this, this just popped up. + +**Bram Cohen**: In general, you want it to be safe by default and whatever's +running onchain, it's speed running whatever it is that it's trying to +accomplish, because you worked it out beforehand. + +**Chris Stewart**: And I mean, this is getting a little off topic to this, but I +would love to have this discussion on Delving Bitcoin if you guys have accounts. +I do have an overflow topic on there, has not received any responses. It pulled +out all of the overflow replies that I got on the original 64-bit arithmetic +post and tried to consolidate them into one place and to get an idea of where +people stand on overflow stuff. And I think there should be a healthy debate +had around this. If a BIP comes out of it, that's great, or maybe we just roll +with what we have right now with the proposal, the 64-bit proposal that I +currently have. I'm rolling with what we just have now because maybe there's +some controversy and we haven't come to consensus on how to best do this, and +that's kind of the feedback that I'm hearing on this call at the moment. + +**Mike Schmidt**: Murch, any other follow-up? Oh, sorry, go ahead, Robin. + +**Robin Linus**: I just said I prefer the current semantics in comparison to two +items. That would make our life harder. + +**Mark Erhardt**: Could you maybe explain what the current semantics are? + +**Chris Stewart**: So, right now, we support up to, I think it's 232 +bits of precision for OP_RANDs. So, you can consume 232 bits of +precision for an OP_RAND. However, the result of an opcode can be up to +basically 264, and you can have that as a result. However, you +cannot consume that result with another opcode. You would fail with a very +cryptic error, "Script unknown error", is how it's phrased, and your script +would terminate execution and validation would fail. So, this proposal, the +64-bit proposal, extends those numbers so that OP_RANDs can now be +264 bits, and then results of opcodes could be up to +2128-1, I believe. Check the document for the exact ranges. + +**Mark Erhardt**: Also, taking a step back, regarding deployment, how would this +be a soft fork? Is it only enabled for a new version of tapscript, or how do +you make sure that this doesn't break existing software, which would not be able +to handle more than 32-bit? + +**Chris Stewart**: So, my understanding of tapscript is anytime a new opcode is +introduced, you can redefine opcode semantics, existing opcode semantics, +keyword there, so such as OP_ADD. You could redefine OP_ADD's existing -- +sorry, semantics with a new opcode to be 64 bits of precision. So, just let's +say hypothetically, we want to introduce this with OP_CTV. And we roll out +OP_CTV, we deploy it in tapscript, which is the key point here. There are +proposals to deploy OP_CTV as an OP_NOP, which I do not support. But let's +assume we're deploying it as part of tapscript. We can then rework precision of +the existing arithmetic opcodes to be 64 bits with this new OP_SUCCESS semantic +used in tapscript. + +**Mark Erhardt**: Okay, so it would only apply to new opcodes and therefore, +nobody else would be handling those opcodes in a failing manner anyway, and that +way it could be a soft fork? + +**Chris Stewart**: That's exactly right. And you know, you'd certainly succeed +in tapscript if you come across an OP_SUCCESS opcode that you don't understand. +So, we would leverage that. + +**Mike Schmidt**: Great discussion. Chris, thanks for joining us and +representing your ideas. We look forward to seeing how this progresses on +Delving as well. + +**Chris Stewart**: If I can segue as well, a bit, I'm curious about Bram's +proposal. I believe, Bram, in your proposal you have an amount semantic or an +amount lock in your proposal. Is that accurate? + +**Bram Cohen**: Well, you could avoid doing arithmetic because it's probably, in +the normal case, usually just giving the same amount over and over again. But +yeah, there are places where you would want to divide by two and do other bits +of logic on that thing. So, yeah, when you're playing a game, you have payouts. +So, if the payout is just simply win-loss to one side or the other, then it's +straightforward, because you can just repeat the amount that you got. But in +many games, the payout is not strictly one way or the other, it's somewhere in +the middle. And you definitely want to be able to do arithmetic for that. + +**Chris Stewart**: Cool, and then so with the amount semantic here, so say with +CTV, sometimes you do this hash-based kind of covenant where you lock the amount +by a hash essentially. With your proposal, is it touching the script itself, +the amount semantics, or is it just using like a hash-based lock? + +**Bram Cohen**: Well, my proposal is not fully baked! But there's kind of two +differences from OP_CTV. One is an approach and one is a very subtle thing +about the semantics of it. So, in terms of approach, OP_CTVC has this idea that +you're hashing quite a bit of stuff together, because you're just going to +presign it in advance, so the amount of stuff that you're hashing together +doesn't really matter. But if you're trying to make a script to use that +dynamically, it becomes a problem, because if it only cares about one thing, it +needs to be told all the other things and calculate the hash itself. So, I'm +proposing that you be able to say, "I'm going to assert that I have one output", +you're only talking about one output now. And you say, "It's a P2WSH, and +here's its scripthash, and this is its amount", and that's what you're stating. +So, that way, you can have dynamic logic about covenants that's only really +worrying about its one path that it's taking through covenant land into the +future, and not having to think about all this other stuff that might be going +on at the same time. + +The other subtle semantic point is that if this is done twice, it should require +two outputs. So, if you have two different things, both of which make the same +claim as to there being an output with the same format, that means there needs +to be two of them, not one of them. You could work around it if you don't have +that requirement, but it's a really good idea to have that in there, or security +problems can happen very easily. + +**Mark Erhardt**: All right. Maybe let's take all a step back and, Mike, did +you want to introduce the topic that we've already jumped in the middle of? + +_Proposed opcodes for enabling recursive covenants through quines_ + +**Mike Schmidt**: Yeah, we kind of started there, but I'll say the Changing +consensus title here so that we have a place to put the show notes, and whatnot, +"Proposed opcodes for enabling recursive covenants through quines". Bram, you +posted to Delving Bitcoin about the idea we started discussing here, which is, +"An idea for how to add a few simple opcodes to Bitcoin Script which would allow +for recursive covenants to be implemented in a natural and straightforward way". +Let's maybe high-level 10,000 foot, what is your idea and what is a quine? + +**Bram Cohen**: All right. So, I've been working on blockchain gaming, +specifically playing games like poker over state channels, which is not quite +possible in Bitcoin today. It's close, it's not quite there. So, the question +is for that exact use case, what is the minimum set of opcodes you'd need to be +able to add to Bitcoin Script to allow that to be implemented, which I have a +pretty good idea of now, because I'm almost shipping this project, building this +thing. And it turns out, when you're doing this, writing quines is very central +to it. So, a quine, for those who have forgotten this ridiculous exercise they +learned in their introductory computer science classes, is a program that +outputs itself verbatim. And there's a fundamental trick to doing this, where +it's given a copy of itself. + +So, to write one in something like Bitcoin Script, you write a program which +assumes that a string that is itself is sitting on the stack already. And then, +it takes that thing and modifies it to plop that string itself onto the stack +before running it, and then run the actual thing it was given. And that thing +itself is then a quine; that resulting program is then a thing that outputs +exactly itself. You've doubled its size in the process of doing it. But this +is a very fundamental trick when you want to have a recursive covenant. And it +turns out if you just use OP_CAT and the slightly dumbed-down OP_CTV, maybe you +could pull it off with OP_CTV, I'm not 100% sure, you can write recursive +covenants actually pretty straightforwardly this way, and you can have fairly +sophisticated logic without actually adding in loops to Bitcoin logic or +anything, because in some sense you have loops. It's just you need to restart +at the beginning, you need to spend the coin, and then when that one gets +executed, it's starting over at the beginning again. + +So, the proposal I gave is trying to be a little more clever than just saying, +"Hey, you can do this using OP_CAT and maybe sort of OP_CTV. I'm proposing kind +of a dumbed-down variance of those, where there's something that is like OP_CTV, +but is just making a specification about a single output of the transaction that +it's in. It also has the semantic change about what happens if there's two of +them, that if there's two of them, that means you need to have two outputs. But +that's the thing that's like OP_CTV. And then, the other thing is this thing +that's like OP_CAT, almost, sort of, but it's hashing it, it's doing incremental +hashing. So, it has update and digest. That way, rather than having to plop a +copy of the entire program on the stack, you have to plop a copy of the partway +hashed thing up to its end on the stack. + +Then, there's another thing I'm suggesting where it's important here that you be +able to modify a script to prepend stuff to it. Now, if you're using OP_CAT, +it's pretty easy to either append or prepend logic onto a Bitcoin Script. It's +hard to modify a Bitcoin Script in general, but prepending and appending are +straightforward. If you're doing this trick with incremental hashing of things, +so you don't need a complete copy for quining, that runs into the problem that +you're adding to the end of the string, so that will naturally append, and what +you really want is to prepend. So, I'm suggesting further having an opcode that +has to be the first one that says, "Okay, this sounds weird, but the entire rest +of the script, all the bytes are in reverse order". And that way, when you are +appending to the end of the program as a string, you're prepending instructions +that are going to be executed onto it. + +It turns out if you put these things together, it requires some clever +programming to do. But it turns out this does not bloat up your programs all +that much or make them terribly big and complicated. This is sufficient to have +game coins. The Lightning-style channels can't quite support full-state channel +support in Bitcoin, and it's not really to do with the channels themselves. +It's to do with what they output, that they can output HTLCs (Hash Time Locked +Contracts) because Bitcoin Script supports HTLCs, but they can't output game +coins, because Bitcoin Script doesn't quite support game coins. So, this is +enough to make it so that you can have actual game coins. + +**Mark Erhardt**: Game coins being another asset here that is being created, or +what? + +**Bram Cohen**: Game coin is a very covenant-restricted thing, which is a game +in progress. So, it's a coin where it's your turn so you spend it, and now it's +my turn and now I spend that output, and then we alternate outputs until the +game is done, and then the rewards are divvied out to us. + +**Mark Erhardt**: Okay, basically a state tracker? + +**Bram Cohen**: Yes. It turns out it's a really good idea for it to +optimistically accept state updates that the two sites give, and then make it so +that there's a slashing operation if someone attempts to cheat. + +**Mark Erhardt**: Okay, given that we have other people here that are a little +more into the covenants debate, do you want to translate for us? + +**Bram Cohen**: Who'd you ask that to? + +**Mark Erhardt**: I was hoping Robin maybe, but he was not chomping at the bit, +I guess. + +**Robin Linus**: Translate what? + +**Mark Erhardt**: Well, I thought that you having thought about BitVM so much +more, probably had a better take or gut reaction or thoughts on this proposal +than I would. + +**Robin Linus**: Well, I have a couple of high-level thoughts. I think first of +all, it is probably possible to implement poker on Bitcoin as it is today. I +would bet that this is true. The other thing is, are you thinking about +two-party poker or multi-party poker? + +**Bram Cohen**: Oh, this is strictly heads-up. I don't even know how to make +state channels work properly with more than two participants. + +**Robin Linus**: I think for multi-party poker, the fundamental issue is even +harder, because even if you can implement everything perfectly, then your +biggest problem is that you don't want the parties to collude. + +**Bram Cohen**: Yeah, even collusion at the state channel level, I don't know +how to do. There's this research on envy-free cake-cutting that terrifies me. +I don't know enough. + +**Robin Linus**: If they share information about their cards, like let's say 10 +people and 9 of them are colluding, then you have -- + +**Bram Cohen**: Oh, yeah, that's at the game level. + +**Robin Linus**: I think that's unsolvable in the blockchain setting. + +**Bram Cohen**: Yeah, right, but even the number of messages necessary to stop +collusion at the state channel level, I don't know how to fix that either. So, +it gets ridiculous very fast. Part of the idea here is to make it so we can +avoid BitVM-style stuff so that you can have just a few simple instructions of +not big scripts that do exactly what you want, and not have to do these hacks to +allow things in Bitcoin Script. + +**Robin Linus**: I think there are also cryptography hacks, like you can shuffle +cards using cryptography. + +**Bram Cohen**: Oh, yeah, I'm implementing poker and it turns out nearly all the +difficulties in mental poker have to do with card-replacement value. So, I'm +just implementing a poker variant that uses an infinite deck! + +**Robin Linus**: Oh, I see. + +**Bram Cohen**: So, I could just use commit and reveal. Except that actually +hints at if you want to implement the real thing, there's so few cards used in +Hold'em, especially with just two players, that you could do normal commit and +reveal, but do collaborative computation a priori before each hand to find out +if you'll have a card collision in that hand. And if you will, you just skip +it. And that makes it so all the onchain stuff is really super-cheap and +straightforward. And people have claimed to me that it would be totally +practical to do this with SHA256. I tried running some things and even their +benchmarks were not very encouraging on that, but maybe someone will figure out +how to make that work in the future. + +**Mike Schmidt**: Yeah, so the use case that you're tackling here is Satoshi's +vision, which is poker and Bitcoin. + +**Bram Cohen**: Yeah. + +**Mike Schmidt**: Have you given thought, like how generalizable is this +approach? It sounds like it's generalizable, but given the fact that we're +focused on this state channel of games … + +**Bram Cohen**: Yeah, a game is a very special case of a two-player protocol, so +this general concept of, "We're going to have a protocol that's spoken between +the two of us that's turn-based that does something, and we're going to do it +over a state channel. And then, if there's an issue, we'll do it onchain". But +even when we're doing it onchain, the two parties don't introduce every single +thing that they're doing onchain, they just declare the state updates onchain +that are optimistically accepted, and then you can slash the other person if +they try to cheat. And that is the one and only time there's an actual reveal +of the actual logic of how this thing works in the thing. This is a very kind +of powerful and general set of concepts. It's very fundamental to the whole +thing. A lot of why I'm doing this is to learn stuff about state channels just +in general. And those concepts are all very programmatic tricks. They don't +involve adding much of anything to the underlying logic. That's why I'm +proposing some very simple stuff that enables a lot of things, because it turns +out a little bit of programming trickery can really go a long way here. + +**Mike Schmidt**: And the fact that there's no external data, right? There's +randomness, I guess, in the cards, as you were mentioning, but you're not +relying on price data or anything. + +**Bram Cohen**: Randomness is done using commit and reveal. So, I will say, +"Okay, I'm thinking of some random junk and here's its hash". And then you say, +"Okay, well, here's my random junk". And now I reveal my preimage and we hash +that together, and that's our randomness. And neither of us could control that +very well unless we colluded for it to not be very random, but we're both trying +to make it random against the other person. So, that's this very fundamental +technique for having randomness in games. It's just that poker itself has +card-replacement value, which gets really involved, what needs to happen there. +But basic randomness is pretty simple and straightforward. But yes, this +doesn't require outside information. If you wanted to include outside +information, you would either need it to be signed by somebody else, and CSFS is +really super-useful there. And if you want to play a game that involves words, +it's very, very helpful to have CSFS, because then a third party can sign things +attesting to what words are allowable words in the game that you're playing, and +that's very helpful. So, CSFS, I believe, is just a really useful and good +thing, just in general. + +But yeah, anything more than that, like interacting with something else onchain +in real time, would require some pretty involved notion of coins having +capabilities and being able to prove their capabilities to other ones, and +things like that. There are things like that that can be done, but that's a +couple orders of magnitude more stuff to add to Bitcoin Script to make that +possible. + +**Mike Schmidt**: Chris, given your background in DLCs, do you have any thoughts +on this idea? + +**Chris Stewart**: Yeah, I mean, I get that DLC do require a lot of coordination +for defining the outcomes up front. I guess my question would be, I'm guessing +you don't need to enumerate the possible outcomes up front, you don't need to +exchange a bunch of digital signatures or adapter signatures? + +**Bram Cohen**: Well, kind of the point here is you can't enumerate the outcomes +up front. If you can enumerate everything, then Bitcoin Script, as it is today, +is sufficient. The problem is, what if you're playing this very free-form game +where you have no clue what's going to happen in the future? + +**Chris Stewart**: And your explanation makes sense of why DLCs wouldn't work in +this case, Bram. + +**Bram Cohen**: Yeah. + +**Mike Schmidt**: All right. We've had a few fun discussions already. Bram, do +you want to hang on and talk about BitVM? It's up to you. + +**Bram Cohen**: Yeah, I've got a few minutes here. + +_Description of benefits to BitVM from `OP_CTV` and `OP_CSFS`_ + +**Mike Schmidt**: Okay. All right, great. Well, there's our segue, " +Description of benefits to BitVM from OP_CTV and OP_CSFS". Robin, you posted to +Delving Bitcoin about how BitVM could be potentially improved if we get the CTV +and CSFS soft forks activated. Maybe to frame things a bit for listeners, you +can give listeners a quick reminder of what BitVM is, what BitVM bridges are, +and then we can get into how they might be improved with these proposals. + +**Robin Linus**: Okay, BitVM is essentially a scheme to enable arbitrary +computation on top of Bitcoin, but it's actually not generally useful. Maybe we +could implement poker with it, but the main use case I see it for is bridges. +So, we want to bridge the BTC asset to different systems, to like side chains, +to roll ups, to stuff like ZK coins, and so on. And yeah, BitVM is enabling +that essentially by enabling a SNARK verifier on Bitcoin, so you can verify +these super-powerful proofs. Just maybe not everybody knows what a SNARK is. A +SNARK is like a proof of validity and they are quite miraculous, because they +essentially allow you to compress infinite amount of computation into a succinct +proof. And that is great for blockchain scalability and it's, in the altcoin +world, the hot topic. And since Bitcoin is so hard to change, we don't have a +SNARK verifier on Bitcoin yet, but BitVM essentially enables a clunky workaround +that allows us to verify SNARKs on Bitcoin. And that allows us to build bridges +and that allows us to bridge the BTC asset to second layers or to other systems +in general. + +BitVM fundamentally relies on covenants. Currently, we emulate these covenants +with a trusted setup. So, there's like a trusted setup where you have like a +large MuSig, like an n-of-n multisig, and you have to trust that committee that +they're actually honest and that at least one of them deletes their keys after +the ceremony. If that is the case, then the covenant is really safe. However, +it is clunky. Even if there is an honest party in the covenant committee, then +you still have that problem that you need that committee to set up the entire +contract. That is just clunky and makes the system harder to set up. It's +something that we would love to get rid of. Also, of course, the trust +assumption is not nice. + +CTV seems to allow to get rid of that trusted setup. Initially, I thought it's +not possible, because CTV is designed to be so simple, and I thought it's not +possible that we can use it for our use case. But Jeremy, he showed me quite a +clever trick to emulate it, probably. I'm not entirely sure if it will actually +work out in practice, but it's looking good. So, the thing is, we need a +special type of covenants, namely covenants that commit to sibling inputs, and +that essentially expresses, "I have an input", let's call it input A, and that +input A is only spendable in conjunction with input B. And that is because in +BitVM, we represent state in UTXOs. The existence of a UTXO represents a +particular state in our system. And for example, having UTXOs representing +state means you can make transactions conditional, to be spendable only if that +particular state was reached. This is essentially this thing where we have +input A is only spendable with input B, means you can spend this input only if a +particular state was reached, which is represented by input B. + +A very simple example for that is in our bridges, you can just simply withdraw +money from the bridge if nobody challenged your withdrawal request. You make a +withdrawal request that creates a UTXO and to challenge you, they spend that +UTXO. And if nobody challenged you, then it means this UTXO has been unspent +and that means no challenge occurred, and that means you can just go down the +happy path and just withdraw money from the bridge. If somebody spent that +particular UTXO, you cannot go down the happy path because you're missing that +input B. And then you have to go down the unhappy path and actually provide +your proof, and then you go to this challenge game where you actually run the +stack verifier. + +Now, CTV was designed to be super-simple. It essentially just commits to +transaction outputs. It does not commit to any transaction inputs. In general, +you cannot commit to your own input because that would create a hash cycle. So, +CTV just omits all of the inputs, because that's the most simple thing that you +can do. And that's the reason why we thought we cannot do this input committing +covenants with CTV. And now, here comes the trick. CTV does commit to the +scriptSig of all inputs. That is for some malleability issue. I don't want to +go too much into detail, but the fact is CTV does commit to the scriptSig of all +inputs. And now, the interesting thing is that if in our sibling we provide a +signature in its scriptSig, then we essentially commit to that signature. And +since that signature commits to the input, we can commit to the sibling. Does +that make sense? + +**Mark Erhardt**: Sorry, I'm a little confused at one thing you said. You said +that it is impossible to commit to your own input because that would lead to a +hash cycle. How could you commit to the scriptSig, which signs the input then? +That seems weird. + +**Robin Linus**: You go to the scriptSig of your sibling. So, you have to make +it spendable with input B and input B has a signature, and in input A you commit +to the signature of input B. + +**Mark Erhardt**: And does it send the same transaction? + +**Robin Linus**: Yeah, this is how we try to make it atomic, how to make input A +only spendable in conjunction with input B. + +**Mark Erhardt**: I see. Carry on. + +**Chris Stewart**: Sorry, I have a question related. So, you say scriptSig. +Are you using scriptSig and witness interchangeably or are you very +intentionally saying scriptSig? + +**Robin Linus**: I'm very intentionally saying scriptSig. It would not work +with witness. For that malleability thing, CTV only commits to the scriptSigs, +it does not commit to the witness data. So, it only commits to scriptSig, and +that means also our input B, like input A and input B, the input B would have to +be either a P2SH input or a legacy input. + +**Chris Stewart**: Okay, that's what I was getting. + +**Bram Cohen**: Yeah, if you know the entire transaction that you're signing, in +principle you could say, "I need to look at a reveal of that and check the +signature", and then the reveal of it gives me this whole scratch area that +everything can use to communicate with each other, because the transaction can +have just junk in it. + +**Robin Linus**: Yeah, I think that's what we're currently doing. I'm not sure +if I understood you correctly, but currently we are just presigning the +transactions. This is how we emulate the covenants. We know up front how the +transaction would look like, so we can presign it. + +**Bram Cohen**: Yeah, yeah. I mean, for having communication with another +thing… I'm thinking dynamically, if it was being done dynamically, where you +didn't have to enumerate everything in advance. + +**Robin Linus**: Yeah, that's actually a drawback of the project we currently +have, that we have to know specifically which transactions everybody will use +and which inputs they will have. And it propagates backwards through the entire +graph of transactions, so we have to know every specific input and you cannot +change anything about it. That leads to all kinds of dependencies that are +actually not very nice in practice. + +**Bram Cohen**: Yeah, I think the proposal that I made would dovetail pretty +nicely with this, actually. It's just an approach. + +**Robin Linus**: Sure, if you have more sophisticated ways to do covenants, you +can do it more dynamic. But currently, we're doing it this way. And CTV does +allow it to make it slightly better, but once you have to commit to the +signature, you already commit again to a txid and the txid represents the entire +graph of transactions. + +**Bram Cohen**: Right. Yeah, you wind up rapidly going into why we really want +capabilities now. The most straightforward way to implement capabilities is to +basically have backwards-pointing covenants. You have these scripts that put +restrictions on what they can do, and you just assert that your parent had that +thing or something else's parent had that thing, so you can recursively +determine that it originally was generated by what it was supposed to have +originally been generated by. That requires a lot of stuff to be added. But to +even start saying things like that, you need to be able to piecemeal say very +specific things about the transaction that you're a part of, and what your own +scriptSig is and what other things scriptSigs are as well. + +**Robin Linus**: Maybe I'll finish the story quickly. So, we now have seen a +way, we have input A and we have input B, and now in input A we have CTV. And +that CTV hash commits to a signature in input B, in the scriptSig of input B. +And now, we thought everything is great and I made that post and everybody in +the BitVM community was super-excited that we can finally do that. And yeah, I +made that post on Delving Bitcoin. And then Anthony Towns came along and he +completely ripped it apart, because the funny thing is, we wanted to use a P2SH +output. But there is that thing that it turns out that you can spend this input +A with a totally different input B if that input B is a legacy script input. +And that is because we cannot commit to a specific script type for input B. We +cannot force that input B is actually a P2SH input. + +That means somebody can just use a legacy script input and replace that input B +with some input B prime that is a legacy script input. And that means the +redeem script that is in the scriptSig of that to which we committed in using +CTV, this redeem script is now interpreted as just a regular data push. It's +just an arbitrary byte string on the stack. And that means you can just drop +it. + +**Mark Erhardt**: When you say legacy, do you mean bare outputs? + +**Robin Linus**: Yes. + +**Mark Erhardt**: Oh, okay. I thought you were talking about P2PKH and it was +really confusing. + +**Robin Linus**: No, that's the point that you have the entire script in the +input, in the pubkey script. Is it called pubkey script, right? That's the +name for it. + +**Mark Erhardt**: I usually say output script and input script because I find +those terms much clearer than scriptSig and scriptPubKey. So, maybe just to lay +out what was confusing me. So, legacy often refers to P2PKH in internet lingo. +So, I thought that your input B was either supposed to be a P2PKH or a P2SH +input. And with P2SH, of course, in the scriptSig, you push the redeem script. +So, in the P2SH output, you commit to a redeem script and that has to be shown +then in the input script, and usually requires signatures or other script +arguments in order to make it pass. And I'm still not 100% sure whether you +only commit to the signature or the entire input script, but presumably the +entire input script with CTV. And now I was confused. How would you ever +replace a P2SH output with a P2PKH output? That didn't make sense to me, and +that's where you lost me. So, we're talking about P2SH and bare script? + +**Robin Linus**: P2S outputs, essentially. Yeah. + +**Chris Stewart**: And the thing is, Robin, can you just say again, quick, what +the data is in input B? I follow you with the clever thing that AJ Towns points +out, but what is that data meant to verify in BitVM again, in input B? + +**Robin Linus**: Yeah, well very general, it's just we want to make input A only +spendable with input B. That is the high-level primitive that we need in a +couple of places. + +**Mark Erhardt**: You use the existence of input B as a marker for being in a +specific state in the BitVM, right? So, if the input doesn't exist, you can't +use input A, because input B has to be spent with it. And thus, if you are not +in that state, you simply cannot use input A. + +**Chris Stewart**: So, then you could fraudulently say input B exists if input +B's output script was not a P2SH script. Is that correct? + +**Robin Linus**: Yeah, kind of. So, maybe just to make it a bit more concrete, +why we want that, input A would be the deposit, the money that is actually in +the bridge, and input B would be some state that represents, "Yeah, you are +actually allowed to take the money out of the bridge right now". So, you can +execute this withdrawal transaction only if input B exists, which represents you +are allowed to take it. And now, the thing is we cannot really commit to the +txid of input B. We can only indirectly commit to it by committing to a +signature to it. However, we cannot really enforce that the signature is +interpreted as a signature. We thought we can enforce that, but it's not the +case, because you can just replace the P2SH input, which certainly would +interpret it as a signature. And you replace that with a bare script input, +which can interpret it as it wants. It can just interpret it as arbitrary data +and then it can just drop it and it doesn't have to use it as a signature. And +that totally bypasses the entire hack. So, input B becomes more or less +arbitrary as long as it is a legacy script. + +**Chris Stewart**: Okay, that clarifies it for me. Thanks, Robin. + +**Robin Linus**: And now, the next hack, how to fix it. That's again Jeremy's +magic, is that we can kind of fix it by using legacy script for input B, or bare +script for input B. And that is essentially possible because we can have +non-standard, let me call it legacy script, that's just the word that I'm using. +We can use non-standard legacy script, and in non-standard legacy script, we can +use non-push opcodes in the unlocking script. Usually, you can only provide +just data in the unlocking script, but in legacy script you can also have +opcodes. You can have CHECKSIG for example, which is kind of weird. Usually, +you don't want that in the unlocking script. It's kind of absurd. It usually +doesn't make any sense to have any other opcode than signature data pushes and +stuff like that in the unlocking script. But it is allowed in legacy script, in +non-standard legacy script. And that means it would always be a signature +check; no matter what kind of input you feed into it, it would always be a +signature check. And that means the signature has to be validated and then +re-enables our hack essentially. + +**Mark Erhardt**: So, just to try to follow, you are committing to a specific +input script with the actual withdrawal, and usually the input script can of +course be provided arbitrarily by the spender, it just has to fulfill the output +script. And then, you wouldn't be able to rely that they actually end up using +an OP_CHECKSIG in the input script. But since the other output actually commits +to a specific input script, you can expect this specific input script to be used +in the other input, and therefore it will be forced to be an OP_CHECKSIG in +there. Is that roughly it? + +**Robin Linus**: Yeah. + +**Mark Erhardt**: Okay. + +**Robin Linus**: You essentially commit to that OP_CHECKSIG opcode in CTV now, +in the CTV hash. + +**Mark Erhardt**: We've been trying for a decade to get rid of bare scripts, but +it's interesting that that ends up being the solution here. + +**Robin Linus**: If we would get rid of bare script, then you would solve the +other issue. Then, we could use P2SH again, because you can't attack it with +anything else other than bare script. + +**Mark Erhardt**: That is an interesting proposal. That would, of course, be +confiscatory, which would get a whole other crowd up in arms and raising +pitchforks. + +**Bram Cohen**: It seems like this would be relatively easy to fix just via a +number of different methods if you could extend Bitcoin Script to be able to +make just more assertions about the inputs to the transaction. + +**Mark Erhardt**: Yeah, maybe we should just replace Bitcoin Script! + +**Robin Linus**: Yeah, that's what Anthony Towns says all the time! + +**Mark Erhardt**: All right, all right. I think we really got into the details +here. Can we maybe dive or undive a little bit and track back towards the +surface? I think you were explaining what BitVM is and then -- bye, Chris -- +and yeah, I'm not entirely sure how we got here. + +**Robin Linus**: I don't know. But the other thing that I haven't mentioned yet +is CSFS, and CSFS makes BitVM way more efficient in general, because currently +we're using these lamport signatures to introduce state into Bitcoin Script. +Essentially, that works such that party A signs some value using lamport +signatures, and then party B can observe the signature in the blockchain and use +it in their script to set a particular value to exactly the value that party A +signed. + +**Bram Cohen**: You're post-quantum already. + +**Robin Linus**: Yeah, BitVM is post quantum! Actually, it's not at all. + +**Mark Erhardt**: Not really, but okay. + +**Robin Linus**: I'm using taproot so you can just break them, right? + +**Mark Erhardt**: Yeah, you can just spend it with a keypath. + +**Robin Linus**: It's just compressed a lot by using CSFS. You'd get a factor +of 10 roughly. You would get more, but we can only sign 32-bit values. CSFS +allows to sign arbitrary values, 32 bytes, or whatever you want. But since we +want to work on these messages, we want to use them in arithmetic opcodes, we +are restricted to 32-bit messages. So, that's why we only get roughly a 10X +improvement. + +**Mark Erhardt**: So, it sounds like you're going to write another blogpost next +week, how 64-bit arithmetic would also be beneficial to BitVM. + +**Robin Linus**: Oh, yeah, it would certainly be beneficial, yeah, in particular +with CSFS. + +**Mark Erhardt**: All right, so maybe going a little more overview here. So, +Bram needs OP_CAT definitely and would also love OP_CSFS in order to be able to +play poker on the Bitcoin blockchain. And BitVM would love OP_CTV. You can +defend yourself in a sec. + +**Robin Linus**: Just give me a sec. + +**Mark Erhardt**: And BitVM would benefit also from all the things we've +discussed, OP_CTV, OP_CSFS, 64-Bit arithmetic. Generally, the thing is just +script is so limited right now that if you're trying to do anything more +abstract, it tends to really blow the opcodes up. Sorry, Bram, what were you +going to say? + +**Bram Cohen**: Yeah, I'm advocating for a slightly dumbed-down thing actually, +because you don't need full-blown OP_CAT. And OP_CTV might be just a little bit +off for what I'm proposing doing. + +**Mark Erhardt**: Right. So, Robin explained the benefits for BitVM, and BitVM +itself would, of course, allow all sorts of layer 2 construction sidechains, +rollups and so forth. Mike, did you have more to tie this all together? + +**Mike Schmidt**: No, I think you did a good job summarizing. It sounds like +there is this scriptSig hack that Jeremy informed Robin about, that CTV could be +used to benefit BitVM. But AJ countered, pointing out downsides to that +approach. But then, Jeremy came back in with another way to remedy that +downside. And so, there are benefits that remain in that approach. And then, +Robin got into some of the concrete improvements also that CSFS brings to BitVM +as well, which are outside, I guess, of that hack, or that scriptSig hack in +that concern, but benefits remain. + +**Mark Erhardt**: Actually, I do have a follow up question for Robin. So, bare +script, of course, would mean that the transactions are non-standard at that +point, right? So, would you propose that one specific construction would become +standard, or have you thought about how that would be eventually used on a +network, or is that too far away yet? + +**Robin Linus**: Yeah, we rely in a couple of ways on non-standard transactions, +so that requirement isn't that bad. In particular for these two transactions, +it's the case that they are not really time-critical. So, if it would take a +very long time to get them in, it's still fine. So, you can go to Slipstream, +or whatever, even though they only have 5% hashing power. So, yeah, but of +course it's not nice that they're non-standard. We try to work around the +non-standardness as much as possible, but in that case, it seems impossible. +So, if I could propose a change, then I'd rather make bare script deprecated. + +**Mark Erhardt**: Okay. Wait, could you say that again? If you had the choice +between OP_CTV and OP_CSFS or making bare script outputs invalid, you'd prefer +making bare script invalid? + +**Robin Linus**: That wouldn't be an either/or choice for me. Certainly, I +would choose CTV, but the bare script thing is completely irrelevant for us +without CTV. + +**Mark Erhardt**: Okay, so basically you'd like all three of them. Make bare +scripts invalid, or…? + +**Robin Linus**: Well, I think it would be quite contentious, because I think +what you could argue for is that you disallow to spend to a bear script, but +spending from is confiscating money, right, and then people will go mad. + +**Mark Erhardt**: Well, there is this theoretic problem that someone could have +a presigned transaction that spends to a bare sig. But yeah, I'm more with the +people that say, making presigned transactions that are set more than one year +into the future seems just very unreliable, and I don't think that people +actually entrusted huge amounts of money to that sort of script. + +**Robin Linus**: Hopefully not. + +**Mark Erhardt**: All right. It sounds like we covered our Changing consensus +section pretty well this time. Did anyone have any calls to action or anything +to add to this? + +**Robin Linus**: Yeah, activate CTV and CSFS, it's time. Stop talking about +OP_RETURN, stop talking about sats versus bitcoins or sats versus bits. Let's +talk about covenants. + +**Mark Erhardt**: Okay. I absolutely agree about, "Stop talking about +OP_RETURN"! And all the other things, yeah, I think they would be more +productive. + +**Bram Cohen**: I'm not so sure about OP_CTV, because I think it might not do +exactly the right thing. I think it might be just a little bit off. + +**Robin Linus**: We can do another round of bike shedding for two or three +years, or just activate CTV now and most people will be kind of happy. I +wouldn't be super-happy, but it's way better than what we have so far. So, it's +it would be cool. But of course, we can also argue about activating OP_TXHASH +session instead, but I think that would take another two years. + +**Bram Cohen**: It's possible that Jeremy or someone could get go deep in the +weeds of exactly what OP_CTV does today and point out to me that there's some +hack for doing exactly what I'm wanting, but I really don't know about that. + +_BIPs #1848_ + +**Mark Erhardt**: While I have you both here, have either of you looked at +CHECKCONTRACTVERIFY (CCV) previously known as MATT? Well, because OP_VAULT has +been mentioned a few times, and maybe I can pull it up very briefly, Mike, but +we do have a BIPs update at the bottom, which is BIPs #1848, and it actually +moves OP_VAULT, BIP345, to withdrawn. And the argument of the OP_VAULT authors +here is that OP_CCV, a new BIP that just got merged, does almost all the things +OP_VAULT does and does it better. So, they throw their support to OP_CCV. So, +if you haven't looked at it yet, maybe that one would be interesting to you as +well. + +**Bram Cohen**: Oh, I should probably also emphasize that for the tricks I'm +talking about, it does turn out that the bytes of this script are in reverse +order thing, and being able to reverse the bytes in a script so that you can cat +it or hash it properly is important for that. I know that sounds really weird, +but that actually does something meaningful. + +**Mark Erhardt**: Robin, did you have any thoughts on CCV? + +**Robin Linus**: Yeah, I think it's a cool proposal. I actually cited it in the +BitVM whitepaper. It was kind of an inspiration for BitVM. I think that would +make everything way easier, of course. Then we could get totally rid of BitVM. +BitVM is just a clunky workaround to enable things that should actually be +activated by proper soft forks. And so, I would be happy if I would have not to +write crazy scripts anymore, like 70,000 opcodes for multiplication. So, +between CTV and CSFS, you actually want CCV? + +**Robin Linus**: Yeah, I mean there are always two dimensions, right? There is, +on the one hand, the dimension of how much does it enable in practice, like the +technical dimension, essentially; and on the other hand, there's the political +dimension. And I feel like the political dimension, it's just way more likely +that we can get CTV than CCV. I think we need a lot of bike shedding first. + +**Mark Erhardt**: It is of course way younger and there's a few little things +that need to be fleshed out still. I think nobody's really heard about it yet, +and so forth. Okay, all right. Maybe we can move on to the Releases and +release candidates section. Mike? + +**Mike Schmidt**: Yeah, that sounds good. + +**Robin Linus**: Unfortunately, I need to drop. + +**Mike Schmidt**: Yeah, thanks for joining us, Robin. Thanks for joining us, +Bram. + +**Robin Linus**: Thanks for having me. Bye. + +**Bram Cohen**: Bye. + +_LND 0.19.0-beta.rc4_ + +**Mike Schmidt**: Releases and release candidates. We have LND 0.19.0-beta.rc4. +And I actually saw this morning that as of a couple of days ago, there's LND +0.19.0-beta.rc5. From what I can tell, the delta between those two RCs look to +me like just an update in the release notes, but the update in the release notes +is a breaking change, noting that the lncli listchannels and lncli +closedchannels commands, the output from those has changed. They renamed the +channel chan_id field, which was actually the short channel identifier, to scid. +So, if you're using LND and you're parsing output looking for chan_id, you might +want to take a look at that as it's a breaking change. And for summary of the +rest of that release, check back to Podcast #349 where we went through that +verbally. + +_Bitcoin Core #32155_ + +Notable code and documentation changes. Bitcoin Core #32155, which is a PR +titled, "Miner: timelock the coinbase to the mined block's height". Murch, why +do we want to timelock the coinbase transaction to the block height? + +**Mark Erhardt**: I have not looked too deeply into this PR, but it seems +obvious that this is related to the consensus cleanup proposal as it introduces +the semantics required by the consensus cleanup into Bitcoin Core now. So, if +you were to build a block with Bitcoin Core, which doesn't really happen because +you'd be CPU mining and it doesn't really give you a block on the mainchain, now +the format of the coinbase transaction would be correct regarding the consensus +cleanup. This is, of course, permitted already because it's a soft fork, so I +read it as a demonstration of how coinbase transactions should be shaped with +the consensus cleanup hopefully coming up sometime in the next decades. + +_Bitcoin Core #28710_ + +**Mike Schmidt**: Perfect. Bitcoin Core #28710, PR titled, "Remove the legacy +wallet and BDB dependency". This PR is the final step of the legacy wallet and +Berkeley DB Removal Project, tracking issue #20160 for those following along at +home. That project began in 2020 with two related goals: first, phasing out the +legacy wallet type in favor of descriptor wallets; and along with that, but +slightly tangential, is the second goal, which is to remove the Berkeley DB +wallet storage format in favor of SQLite. The project has had dozens of commits +over these last five years, and this particular PR removes a bunch of the legacy +wallet RPCs, documentation around them, and tests around them. And so, right +now, only a bare minimum of the legacy wallet code remains in the Bitcoin Core +project, and that is in order to perform wallet migrations from a potentially +old legacy wallet that someone might have, to the new version in the future. +And the PR noted, "The migration code will probably be around for a long +time/forever". Murch? + +**Mark Erhardt**: Yeah, hopefully forever. The point is Bitcoin Core has the +forever wallet and if you have funds in a legacy wallet, we wouldn't want you to +need to try and dig up an ancient version of Bitcoin Core in order to be able to +open your wallet. So, Ava actually wrote an implementation of Berkeley DB, a +read-only implementation that only implements the things that we actually need +in Bitcoin Core, that can read legacy wallets and transfer them into descriptor +wallets. After this has been merged, you cannot create legacy wallets anymore +with Bitcoin Core. And you will also not be able to load legacy wallets at all +anymore, except to migrate them. So, we are now in the total +only-descriptor-wallets territory with Bitcoin Core releases. Well, coming with +the next Bitcoin Core 30.0 in October, you will only have descriptor wallets +that are running on in Bitcoin Core wallet. + +Berkeley DB was an open-source wallet until, I think, 2013 or so, when it was +purchased by Oracle and taken private, closed source. So, we have long wanted +to get rid of that. It's been basically unmaintained for over ten years. So, +being able to just have a read-only implementation that we control ourselves +cleans that up nicely for us. And yeah, overall, descriptor wallets just have a +better format, it uses SQLite under the hood instead of Berkeley DB, and it has +the descriptor format, which is a better way of describing xpubs, because you +get all the information in one description. So, overall, this is all for the +better. And I think it removed something like 12,000 lines of code from Bitcoin +Core, which Bitcoin Core is, I think, about 180,000 lines of code. 12,000 is a +significant chunk of that. And yeah, it's a lot of this really, really old code +that we're very happy not to have to look at anymore. + +_Core Lightning #8272_ + +**Mike Schmidt**: Core Lightning #8272 is a PR that removes DNS seeds for peer +lookups as a fallback. So, in Core Lightning (CLN), one of the commits in this +PR notes that, "DNS seeds have been down/offline for a while, and this code, +which is blocking, has been a source of trouble. We should probably use a +canned set of known nodes if we want to bootstrap". So, that is what this PR +does, and it also fixes an issue where CLN could potentially have multiple +reconnects attempting at the same time, which also causes issues. + +_LND #8330_ + +LND #8330 titled, "Bimodal pathfinding probability improvements". The PR fixes +an estimating issue when routing, when the channel capacity is more than 1 +million sats. It also adds a fallback probability that is used if the bimodal +pathfinding model is not applicable. And finally, "Fixes are added such that +the probability is evaluated quicker and to be more accurate in outdated +scenarios". I think it closes two or three different issues that were open in +LND. So, if you're curious about more of the details there, check out the PR. + +_Rust Bitcoin #4458_ + +Rust Bitcoin #4458. This is a PR around lock times in Rust Bitcoin. It's a +change to the API to break what was one variable or one type, which is +MtpAndHeight, into two different separate types instead. So, instead of one +type that represents both the median time past and the block height, there's two +separate types now. And while conceptually this is a simple idea of just +splitting one variable into its two component pieces, it was, according to the +author, "A more involved PR than I had expected". And there's a bunch of +interesting internal details and considerations around the change that I don't +think it's worth getting into on this podcast, but check out the PR description +and commit messages. And I should also note that it is a breaking change to the +API, but the author notes, "I believe the resulting API is much more consistent +and discoverable". + +_BIPs #1848_ + +BIPS #1848, we talked about this one a little bit earlier. Do you want to call +that a closed case, Murch? + +**Mark Erhardt**: Yeah, well, just BIP345, the OP_VAULT BIP, was updated to +withdrawn again, and OP_CCV, a new BIP, I think it was 443, just got merged. I +think it'll be in the next newsletter. + +_BIPs #1841_ + +**Mike Schmidt**: Two more BIPs PRs. We have #1841, which merges BIP172. +Murch, I know, as our BIPs editor, you've taken a look at these. What are we +trying to achieve here, and maybe you want to tie in BIP177, which is a BIPs PR +as well? + +_BIPs #1821_ + +**Mark Erhardt**: Yeah, let me start with BIPs #1821. It's kind of funny that +all three of these are in reverse order of time. So, #1821 adds BIP177, a +fairly new informational BIP. This is proposing that we should essentially +re-label what we call bitcoins in Bitcoin. The original definition of a bitcoin +is 100,000 of the atomic units in Bitcoin. Of course, at the protocol level, +Satoshi did call these atoms in the code. So, they're unsplittable integer +values that we use at the protocol level. Colloquially, today they're called +satoshis. So, this informational BIP proposes that we should stop calling 100 +million of the atoms 'bitcoin'. We should instead call the atoms themselves +bitcoin. So, essentially it is asking the community to start referring to what +we call today's satoshis as bitcoins. + +Naturally, people have very strong feelings about that and have been already +debating that on social media. And I believe that BIP172, another BIP that came +out very briefly after, was a reaction to BIP177, where it instead proposes +another informational BIP, which formally defines satoshis as the correct term +for the atoms in the Bitcoin protocol, and describes how to use the term and how +Bitcoin amounts should be formatted when talking about satoshis. So, basically, +BIP172 and BIP177 are directly opposing here, and probably only one of them can +be adopted by the community. As of yet, they're both drafts. So, argue away +and please don't argue in the BIPs repository. + +**Mike Schmidt**: I have to ask you, as somebody who's authored a terminology +BIP, what is your personal opinion? + +**Mark Erhardt**: Well, to correct that, I have a draft that I haven't even +opened a PR to the BIPs repository for a terminology BIP, which I really should +write, or finish writing at some point. I think it will be very difficult to +herd cats in the way that an organically adopted term gets replaced. I do get +the point that people are making that if we could magically switch over and just +start calling atoms of the Bitcoin protocol 'bitcoins' instead of 'satoshis', +that might be an overall better world to be in because it gets rid of the unit +bias. On the other hand, it gets to really, really large numbers for amounts +that we currently see quite frequently. Like a bitcoin is then 100 million +bitcoins in that new world. If you are talking about several hundred bitcoins +or something, it becomes billions. And even small amounts, like $1, is +currently around, I don't know, 980-or-so sats, or bitcoins in that proposed +world. I think it takes a very open mind to just jump in and consider what that +new world would look like and whether that would be a better world. And if +people agree on that, I think there's a whole other debate whether the +transition from the current use of the terms to that new world is doable. And I +think that's where most of my gripes come from. + +I could see that there's arguments for, if we were in a position to have already +adopted the new terminology, that it would be a better world. But I think the +transition there would be extremely confusing and difficult. It would mean +updating every software, it would mean updating the understanding of everyone's +person, how much value a bitcoin roughly would be. I think that's the part that +most people are concerned about, not the final outcome as much. + +**Mike Schmidt**: Well, we'll see what the social medias think about these +ideas, as well as the idea of BIPs. That's also been something people have +discussed. + +**Mark Erhardt**: Yeah, right. In this context, BIP176 has gotten some more +attention recently again. This is an older BIP, I believe by Jimmy Song, that +just tried to formally introduce the term 'bits' for 100 satoshis, and sort of +advocated for the adoption of that term. And yeah, so BIP172, 176, and 177 are +all in the repository now. Feel free to read there. Please do note, the BIPs +repository neither collects nor tracks, nor is the place to discuss whether or +not proposals will be adopted. They're merely a place to present your proposals +when they're reasonably mature and on topic. + +**Mike Schmidt**: Well said. Well, we want to thank our special guests, Robin, +Bram, Chris, and Eugene for joining us today and talking about the work that +they've been doing and the research they've been executing. Thank you to Murch +as co-host, and for everyone for listening this week. Cheers. + +**Mark Erhardt**: Thank you for your time. {% include references.md %} From 12d54d214c76b7e47775567e2b7f01d4a2f4fc25 Mon Sep 17 00:00:00 2001 From: Walpurga03 Date: Sun, 25 May 2025 11:32:02 +0200 Subject: [PATCH 047/278] Add German translation for newsletter 350 Also: Add standard section headings to STYLE-DE.md for consistency Co-authored-by: garfiel-d Co-authored-by: Mike Schmidt --- STYLE-DE.md | 12 +++ .../de/newsletters/2025-04-18-newsletter.md | 96 +++++++++++++++++++ 2 files changed, 108 insertions(+) create mode 100644 _posts/de/newsletters/2025-04-18-newsletter.md diff --git a/STYLE-DE.md b/STYLE-DE.md index d1523cbaae..3192554c76 100644 --- a/STYLE-DE.md +++ b/STYLE-DE.md @@ -5,6 +5,18 @@ Die deutsche Übersetzung von Optech Inhalten sollte wo immer möglich den Regeln des englischen [Hauptleitfaden](STYLE.md) folgen. +## Abschnittsüberschriften (Standardübersetzungen) + +| Englisch | Deutsch | +|-------------------------------------------|----------------------------------------------| +| News | Nachrichten | +| Changes to services and client software | Änderungen an Diensten und Client-Software | +| Releases and release candidates | Veröffentlichungen und Release-Kandidaten | +| Notable code and documentation changes | Wichtige Code- und Dokumentationsänderungen | +| Selected Q&A from Bitcoin Stack Exchange | Ausgewählte Fragen & Antworten von Bitcoin Stack Exchange | +| Correction | Korrektur | +| Consensus changes | Konsensänderungen | + ## Vokabular ### Eigennamen diff --git a/_posts/de/newsletters/2025-04-18-newsletter.md b/_posts/de/newsletters/2025-04-18-newsletter.md new file mode 100644 index 0000000000..dad99b65a3 --- /dev/null +++ b/_posts/de/newsletters/2025-04-18-newsletter.md @@ -0,0 +1,96 @@ +--- +title: 'Bitcoin Optech Newsletter #350' +permalink: /de/newsletters/2025/04/18/ +name: 2025-04-18-newsletter-de +slug: 2025-04-18-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche enthält unsere regulären Abschnitte mit Beschreibungen aktueller Änderungen an Diensten und Client-Software, Ankündigungen neuer Releases und Release-Kandidaten sowie Zusammenfassungen wichtiger Änderungen an beliebter Bitcoin-Infrastruktur-Software. Außerdem gibt es eine Korrektur zu einigen Details aus unserem Bericht der letzten Woche über SwiftSync. + +## Nachrichten + +*In dieser Woche wurden in unseren [Quellen][] keine bedeutenden Nachrichten gefunden.* + +## Änderungen an Diensten und Client-Software + +*In dieser monatlichen Rubrik stellen wir interessante Aktualisierungen von Bitcoin-Wallets und -Diensten vor.* + +- **Bitcoin Knots Version 28.1.knots20250305 veröffentlicht:** + Dieser [Release][knots 28.1] von Bitcoin Knots unterstützt das [Signieren von Nachrichten][topic generic signmessage] für Segwit- oder Taproot-Adressen sowie die Verifizierung von [BIP137][], [BIP322][] und Electrum-signierten Nachrichten, neben weiteren Änderungen. + +- **PSBTv2 Explorer angekündigt:** + Der [Bitcoin PSBTv2 Explorer][bip370 website] ermöglicht die Inspektion von [PSBTs][topic psbt], die im Version-2-Datenformat kodiert sind. + +- **LNbits v1.0.0 veröffentlicht:** + Die [LNbits][lnbits github] Software bietet Buchhaltung und zusätzliche Funktionen auf Basis verschiedener Lightning Network Wallets. + +- **The Mempool Open Source Project® v3.2.0 veröffentlicht:** + Der [v3.2.0 Release][mempool 3.2.0] fügt Unterstützung für [v3-Transaktionen][topic v3 transaction relay], Anchor Outputs, das Broadcasting von [1P1C-Paketen][topic package relay], die Visualisierung von Stratum-Miningpool-Jobs und weitere Funktionen hinzu. + +- **Coinbase MPC-Bibliothek veröffentlicht:** + Das [Coinbase MPC][coinbase mpc blog] Projekt ist eine [C++-Bibliothek][coinbase mpc github] zur Sicherung von Schlüsseln für Multi-Party-Computing (MPC)-Schemata, einschließlich einer eigenen secp256k1-Implementierung. + +- **Lightning Network Liquiditäts-Tool veröffentlicht:** + [Hydrus][hydrus github] nutzt den Zustand des LN-Netzwerks, einschließlich vergangener Performance, um Lightning-Kanäle für LND automatisch zu öffnen und zu schließen. Es unterstützt auch [Batching][topic payment batching]. + +- **Versioned Storage Service angekündigt:** + Das [Versioned Storage Service (VSS) Framework][vss blog] ist eine Open-Source-Cloudspeicherlösung für Lightning- und Bitcoin-Wallet-State-Daten mit Fokus auf non-custodial Wallets. + +- **Fuzz-Testing-Tool für Bitcoin-Knoten:** + [Fuzzamoto][fuzzamoto github] ist ein Framework, um mit Fuzz-Testing Fehler in verschiedenen Bitcoin-Protokollimplementierungen über externe Schnittstellen wie P2P und RPC zu finden. + +- **Bitcoin Control Board Komponenten Open Source:** + Braiins [kündigte][braiins tweet] die Open-Source-Verfügbarkeit einiger Hardware- und Software-Komponenten ihres BCB100-Mining-Control-Boards an. + +## Veröffentlichungen und Release-Kandidaten + +_Neue Veröffentlichungen und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie ein Upgrade auf neue Versionen oder helfen Sie bei der Testung von Release-Kandidaten._ + +- [Bitcoin Core 29.0][] ist die neueste Hauptversion des vorherrschenden Full Nodes im Netzwerk. Die [Release Notes][bcc rn] beschreiben mehrere bedeutende Verbesserungen: Ersatz der standardmäßig deaktivierten UPnP-Funktion (die in der Vergangenheit für einige Sicherheitslücken verantwortlich war) durch eine NAT-PMP-Option (ebenfalls standardmäßig deaktiviert), verbessertes Abrufen von Elternteilen verwaister Transaktionen zur Erhöhung der Zuverlässigkeit des aktuellen [Package Relay][topic package relay] in Bitcoin Core, etwas mehr Platz in Standard-Blockvorlagen (was potenziell die Miner-Einnahmen verbessert), Verbesserungen zur Vermeidung versehentlicher [Timewarps][topic time warp] für Miner, die andernfalls Einnahmeverluste riskieren könnten, falls Timewarps in einem [zukünftigen Soft Fork][topic consensus cleanup] verboten werden, und eine Migration des Build-Systems von autotools zu cmake. + +- [LND 0.19.0-beta.rc2][] ist ein Release-Kandidat für diesen beliebten LN-Knoten. Eine der wichtigsten Verbesserungen, die wahrscheinlich getestet werden sollte, ist das neue RBF-basierte Fee-Bumping für kooperative Schließungen. + +## Wichtige Code- und Dokumentationsänderungen + +_Nennenswerte kürzliche Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und [BINANAs][binana repo]._ + +- [LDK #3593][] ermöglicht es Nutzern, einen [BOLT12][topic offers] Zahlungsnachweis zu liefern, indem die BOLT12-Rechnung im `PaymentSent`-Event nach Abschluss einer Zahlung enthalten ist. Dies wird durch das Hinzufügen des Feldes `bolt12` zum Enum `PendingOutboundPayment::Retryable` erreicht, das dann an das `PaymentSent`-Event angehängt werden kann. + +- [BOLTs #1242][] macht das [Payment Secret][topic payment secrets] für [BOLT11][]-Rechnungszahlungen verpflichtend, indem von Lesern (Zahlern) verlangt wird, eine Zahlung zu verweigern, wenn das Feld `s` (Payment Secret) fehlt. Zuvor war es nur für Schreiber (Empfänger) verpflichtend, und Leser konnten `s`-Felder mit falscher Länge ignorieren (siehe Newsletter [#163][news163 secret]). Dieser PR aktualisiert auch das Payment Secret Feature auf den Status `ASSUMED` in [BOLT9][]. + +## Korrektur + +Der Bericht der letzten Woche über [SwiftSync][news349 ss] enthielt mehrere Fehler und verwirrende Aussagen. + +- *Kein kryptografischer Akkumulator verwendet:* Wir beschrieben SwiftSync als Verwendung eines kryptografischen Akkumulators, was nicht korrekt ist. Ein kryptografischer Akkumulator würde es ermöglichen zu testen, ob ein bestimmter Transaktionsoutput (TXO) Teil einer Menge ist. SwiftSync benötigt das nicht. Stattdessen wird ein Wert, der einen TXO repräsentiert, beim Erstellen zum Aggregat addiert und beim Ausgeben (Verbrauchen) subtrahiert. Nach Durchführung dieses Vorgangs für alle TXOs, die vor dem SwiftSync-Endblock ausgegeben werden sollten, prüft der Knoten, ob das Aggregat null ist – was bedeutet, dass alle erstellten TXOs später ausgegeben wurden. + +- *Parallele Blockvalidierung erfordert kein assumevalid:* Wir beschrieben einen Weg, wie parallele Validierung mit SwiftSync funktionieren könnte, bei dem Skripte bis zum Endblock von SwiftSync nicht validiert werden – ähnlich wie Bitcoin Core heute während des Initial Syncs mit _assumevalid_. Allerdings könnten frühere Skripte mit SwiftSync validiert werden, was wahrscheinlich Änderungen am Bitcoin-P2P-Protokoll erfordern würde, um optional zusätzliche Daten mit Blöcken zu übertragen. Bitcoin Core Knoten speichern diese Daten bereits für jeden Block, den sie ebenfalls speichern, daher glauben wir nicht, dass das Hinzufügen einer P2P-Nachrichtenerweiterung schwierig wäre, falls erwartet wird, dass viele Leute SwiftSync mit deaktiviertem assumevalid nutzen wollen. + +- *Parallele Blockvalidierung aus anderen Gründen als bei Utreexo:* Wir schrieben, dass SwiftSync Blöcke aus ähnlichen Gründen wie [Utreexo][topic utreexo] parallel validieren kann, aber beide gehen unterschiedlich vor. Utreexo validiert einen Block (oder eine Serie von Blöcken zur Effizienzsteigerung), indem es mit einem Commitment zum UTXO-Set beginnt, alle Änderungen am UTXO-Set durchführt und ein Commitment zum neuen UTXO-Set erzeugt. Dadurch kann die Validierungsarbeit nach CPU-Threads aufgeteilt werden; z.B. validiert ein Thread die ersten tausend Blöcke und ein anderer Thread die zweiten tausend Blöcke. Am Ende der Validierung prüft der Knoten, ob das Commitment am Ende der ersten tausend Blöcke mit dem Commitment übereinstimmt, mit dem er für die zweiten tausend Blöcke gestartet ist. + + SwiftSync verwendet einen Aggregatzustand, der Subtraktion vor Addition erlaubt. Angenommen, ein TXO wird in Block 1 erstellt und in Block 2 ausgegeben. Wenn wir Block 2 zuerst verarbeiten, subtrahieren wir die Darstellung des TXO vom Aggregat. Wenn wir später Block 1 verarbeiten, addieren wir die Darstellung des TXO zum Aggregat. Der Nettoeffekt ist null, was am Ende der SwiftSync-Validierung überprüft wird. + +Wir entschuldigen uns bei unseren Lesern für unsere Fehler und danken Ruben Somsen für den Hinweis darauf. + +{% include snippets/recap-ad.md when="2025-04-22 15:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="3593,1242" %} +[bitcoin core 29.0]: https://bitcoincore.org/bin/bitcoin-core-29.0/ +[bcc29 testing guide]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/29.0-Release-Candidate-Testing-Guide +[lnd 0.19.0-beta.rc2]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc2 +[Quellen]: /en/internal/sources/ +[news349 ss]: /de/newsletters/2025/04/11/#swiftsync-beschleunigung-fur-initial-block-download +[bcc rn]: https://bitcoincore.org/en/releases/29.0/ +[knots 28.1]: https://github.com/bitcoinknots/bitcoin/releases/tag/v28.1.knots20250305 +[bip370 website]: https://bip370.org/ +[lnbits github]: https://github.com/lnbits/lnbits +[mempool 3.2.0]: https://github.com/mempool/mempool/releases/tag/v3.2.0 +[coinbase mpc blog]: https://www.coinbase.com/blog/innovation-matters-coinbase-breaks-new-ground-with-mpc-security-technology +[coinbase mpc github]: https://github.com/coinbase/cb-mpc +[hydrus github]: https://github.com/aftermath2/hydrus +[vss blog]: https://lightningdevkit.org/blog/announcing-vss/ +[fuzzamoto github]: https://github.com/dergoegge/fuzzamoto +[braiins tweet]: https://x.com/BraiinsMining/status/1904601547855573458 +[news163 secret]: /en/newsletters/2021/08/25/#bolts-887 From a6abec561aeafb1a5f2ef7d0e6e3f3def9656dd3 Mon Sep 17 00:00:00 2001 From: BitTom Date: Tue, 3 Jun 2025 21:07:46 +0800 Subject: [PATCH 048/278] Newsletter-186: translate into Chinese (#2332) --- .../zh/newsletters/2022-02-09-newsletter.md | 78 +++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 _posts/zh/newsletters/2022-02-09-newsletter.md diff --git a/_posts/zh/newsletters/2022-02-09-newsletter.md b/_posts/zh/newsletters/2022-02-09-newsletter.md new file mode 100644 index 0000000000..d9d03861fd --- /dev/null +++ b/_posts/zh/newsletters/2022-02-09-newsletter.md @@ -0,0 +1,78 @@ +--- +title: 'Bitcoin Optech Newsletter #186' +permalink: /zh/newsletters/2022/02/09/ +name: 2022-02-09-newsletter-zh +slug: 2022-02-09-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周 Newsletter 描述了关于修改 Replace-by-Fee（RBF） 交易中继策略的讨论，并照例包含 Bitcoin Core PR 审查俱乐部会议摘要、新版本与候选发布公告，以及流行比特币基础设施项目的值得注意的变更说明。 + +## 新闻 + +- ******关于 RBF 策略的讨论：** + Gloria Zhao 在 Bitcoin-Dev 邮件列表发起了[讨论][zhao rbf]，主题为 Replace-by-Fee（RBF） 策略。她的邮件首先回顾了当前策略的背景，列举了多年来发现的若干问题（例如[交易固定][topic transaction pinning]攻击），分析了该策略对钱包用户界面的影响，随后提出了若干可能的改进方案。邮件重点关注基于“下一块模板”上下文来评估交易替换的想法—即矿工在尝试完成工作量证明时会创建并承诺的拟议区块。通过评估替换对下一块模板的影响，矿工能够无需启发式方法就确定替换是否能为其带来更多手续费收入。多位开发者对 Zhao 的总结与提案进行了回复，并提出了额外或替代的修改建议。 + + 截至撰写本文时，讨论仍在进行中。 + +## Bitcoin Core PR 审查俱乐部 + +*在此月度栏目中，我们总结最近一次 [Bitcoin Core PR Review Club][] 会议的要点，并列出部分重要问答。点击下方任意问题可查看会议答案概要。* + +[添加用法示例][reviews 748]是 Elichai Turkel 的一个拉取请求，用于为 ECDSA 签名、schnorr 签名以及 ECDH 密钥交换添加用法示例。这是审查俱乐部首次讨论 libsecp256k1 的拉取请求。与会者讨论了高质量随机源的重要性，逐步走查示例代码，并就 libsecp256k1 的一般性问题进行交流。 + +{% include functions/details-list.md + q0="为什么示例代码要展示如何获取随机数？" + a0="本库中许多密码学方案的安全性依赖于密钥、随机数（nonce）与盐值保持秘密/随机。如果攻击者能够猜测或影响我们的随机数源返回的值，他们就可能伪造签名、获知我们试图保密的信息、猜出密钥等。因此，实现密码学方案的难点往往在于获取随机数。用法示例正是为了突显这一事实。" + a0link="https://bitcoincore.reviews/libsecp256k1-748#l-99" + + q1="为用户推荐获取随机数的方法是否合适？" + a1="libsecp256k1 的主要用户 Bitcoin Core 有自己的随机数算法，综合了操作系统、P2P 网络接收的消息以及其他熵源。对于必须“自备熵源”的其他用户来说，推荐可能会有所帮助，因为可靠的随机数源至关重要，而操作系统文档并不总是清晰。确实存在维护成本，因为推荐可能会随着操作系统支持变化或漏洞披露而过时，但预计这一成本很小，因为相关 API 更新极不频繁。" + a1link="https://bitcoincore.reviews/libsecp256k1-748#l-120" + + q2="能否直接跟随 PR 中新增的示例？是否缺少任何内容？" + a2="与会者分享了编译和运行示例、使用调试器、将示例代码与 Bitcoin Core 用法对比、并为非比特币用户考虑用户体验的经历。 +一位与会者指出，在生成 schnorr 签名后未进行验证与 Bitcoin Core 代码及 [BIP340][] 的建议不符。另一位与会者建议在 `secp256k1_ecdsa_sign` 之前演示 `secp256k1_sha256` 的使用，因为忘记对消息进行哈希可能成为潜在的用户陷阱。" + a2link="https://bitcoincore.reviews/libsecp256k1-748#l-193" + + q3="如果用户忘记执行诸如签后验证、调用 `seckey_verify` 或随机化上下文等操作，会发生什么？" + a3="在最坏情况下，如果实现存在缺陷，签名后忘记验证可能导致意外生成无效签名。随机生成密钥后忘记调用 `seckey_verify` 意味着存在（极小的）概率生成无效密钥。随机化上下文旨在防御侧信道攻击——它会对中间值进行盲化，这些中间值不会影响最终结果，但可能被利用以获取操作信息。" + a3link="https://bitcoincore.reviews/libsecp256k1-748#l-226" +%} + +## 发布与候选发布 + +*面向流行比特币基础设施项目的新版本发布与候选发布。请考虑升级到新版本，或协助测试候选发布。* + +- [LND 0.14.2-beta][LND 0.14.2-beta]是一次维护版本更新，包含若干漏洞修复及少量改进。 + +## 值得注意的代码与文档变更 + +*本周在 [Bitcoin Core][bitcoin core repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[硬件钱包接口（HWI）][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中的值得注意的变更。* + +- [Bitcoin Core #23508][Bitcoin Core #23508] 将软分叉部署状态信息从 `getblockchaininfo` 移至新的 `getdeploymentinfo` RPC，同时支持按特定区块高度查询部署状态，而非仅限链尖。 + +- [Bitcoin Core #21851][Bitcoin Core #21851] 为 arm64-apple-darwin（Apple M1） 平台添加构建支持。随着变更合并，社区可在下一个版本中期待可用的 M1 二进制文件。 + +- [Bitcoin Core #16795][Bitcoin Core #16795] 更新 `getrawtransaction`、`gettxout`、`decoderawtransaction` 与 `decodescript` RPC，使其在解码任意 scriptPubKey 时返回推断出的[输出脚本描述符][topic descriptors]。 + +- [LND #6226][LND #6226] 将通过遗留 `SendPayment`、`SendPaymentSync` 与 `QueryRoutes` RPC 创建的 LN 路由支付默认手续费设为 5%。使用新版 `SendPaymentV2` RPC 发送的支付默认手续费为 0%，基本上要求用户显式指定。另一合并的拉取请求 [LND #6234][LND #6234] 将通过遗留 RPC 发送且金额低于 1,000 satoshi 的支付默认手续费设为 100%。 + +- [LND #6177][LND #6177] 允许 [HTLC][topic HTLC] 拦截器的使用者指定 HTLC 失败的原因，使拦截器在测试 LND 上层软件处理失败情形时更加实用。 + +- [LDK #1227][LDK #1227] 改进路由查找逻辑，纳入已知的历史支付失败/成功信息。这些信息用于推断通道余额的上限与下限，从而在评估路由时为路由查找逻辑提供更准确的成功概率。这实现了 René Pickhardt 等人在之前多期 Newsletter（包括 [#142][news142 pps]、[#163][news163 pickhardt richter paper] 与 [#172][news172 cl4771]）中提到的部分想法。 + +- [HWI #549][HWI #549] 添加对 [PSBT][topic psbt] 版本 2 的支持（见 [BIP370][]）。当使用仅原生支持 v0 PSBT 的设备（如现有 Coldcard 硬件签名设备）时，v2 PSBT 会被转换为 v0 PSBT。 + +- [HWI #544][] 为 Trezor 硬件签名设备添加接收与支出 [taproot][topic taproot] 付款的支持。 + + +{% include references.md %} +{% include linkers/issues.md v=1 issues="23508,21851,16795,6226,6234,6177,1227,549,544" %} +[lnd 0.14.2-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.14.2-beta +[zhao rbf]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html +[news163 pickhardt richter paper]: /zh/newsletters/2021/08/25/#zero-base-fee-ln-discussion +[news142 pps]: /zh/newsletters/2021/03/31/#paper-on-probabilistic-path-selection +[news172 cl4771]: /zh/newsletters/2021/10/27/#c-lightning-4771 +[reviews 748]: https://bitcoincore.reviews/libsecp256k1-748 From 41bdd981f1ee58b7449cd45bb5dfe0baeed47698 Mon Sep 17 00:00:00 2001 From: "Zhiwei(Jeffrey) Hu" Date: Tue, 3 Jun 2025 09:21:33 +0800 Subject: [PATCH 049/278] Newsletter-355: translate into Chinese (#168) --- .../zh/newsletters/2025-05-23-newsletter.md | 99 +++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 _posts/zh/newsletters/2025-05-23-newsletter.md diff --git a/_posts/zh/newsletters/2025-05-23-newsletter.md b/_posts/zh/newsletters/2025-05-23-newsletter.md new file mode 100644 index 0000000000..4a86e43718 --- /dev/null +++ b/_posts/zh/newsletters/2025-05-23-newsletter.md @@ -0,0 +1,99 @@ +--- +title: 'Bitcoin Optech Newsletter #355' +permalink: /zh/newsletters/2025/05/23/ +name: 2025-05-23-newsletter-zh +slug: 2025-05-23-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的周报包括我们的常规部分，描述服务和客户端软件的变更、宣布新版本和候选版本，以及总结热门比特币基础设施软件的近期变更。 + +## 新闻 + +*本周在我们的任何[来源][sources]中都没有发现重大新闻。* + +## 服务和客户端软件的变更 + +*在这个月度栏目中，我们重点介绍比特币钱包和服务的有意思的更新。* + +- ******Cake Wallet 添加 payjoin v2 支持：** + Cake Wallet [v4.28.0][cake wallet 4.28.0] 添加了[功能][cake blog]，可以使用 [payjoin][topic payjoin] v2 协议接收支付。 + +- ******Sparrow 添加支付到锚点功能：** + Sparrow [2.2.0][sparrow 2.2.0] 可以显示并发送[支付到锚点（P2A）][topic ephemeral anchors]输出。 + +- ******Safe Wallet 1.3.0 发布：** + [Safe Wallet][safe wallet github] 是一个支持硬件签名设备的多签桌面钱包，在 [1.3.0][safe wallet 1.3.0] 版本中为入账交易添加了 [CPFP][topic cpfp] 手续费追加功能。 + +- ******COLDCARD Q v1.3.2 发布：** + COLDCARD Q 的 [v1.3.2 版本][coldcard blog] 包括额外的多签[花费策略支持][coldcard ccc]和用于[共享敏感数据][coldcard kt]的新功能。 + +- ******使用 payjoin 进行交易批处理：** + [Private Pond][private pond post] 是一个[实验性实现][private pond github]，提供[交易批处理][topic payment batching]服务，使用 payjoin 生成更小且手续费更低的交易。 + +- ******JoinMarket Fidelity 债券模拟器：** + [JoinMarket Fidelity 债券模拟器][jmfbs github] 为 JoinMarket 参与者提供工具，基于 [Fidelity 债券][news161 fb]模拟他们在市场中的表现。 + +- ******比特币操作码文档：** + [Opcode Explained][opcode explained website] 网站记录了每个比特币脚本操作码。 + +- ******Bitkey 代码开源：** + Bitkey 硬件签名设备[宣布][bitkey blog]其[源代码][bitkey github]对非商业用途开源。 + +## 发布和候选版本 + +*热门比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本。* + +- [LND 0.19.0-beta][] 是这个热门闪电网络节点的最新主要版本。它包含许多[改进][lnd rn]和错误修复，包括基于 RBF 的合作式关闭手续费追加功能。 + +- [Core Lightning 25.05rc1][] 是这个热门闪电网络节点实现的下一个主要版本的候选版本。 + +## 值得注意的代码和文档变更 + +*[Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[硬件钱包接口 (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案 (BIPs)][bips repo]、[闪电网络 BOLTs][bolts repo]、[闪电网络 BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo] 的近期值得注意的变更。* + +- [Bitcoin Core #32423][] 移除了对 `rpcuser/rpcpassword` 的弃用通知，替换为关于在配置文件中存储明文凭证的安全警告。当 [Bitcoin Core #7044][] 引入 `rpcauth` 时，该选项最初被弃用，后者支持多个 RPC 用户并对 cookie 进行哈希处理。该 PR 还为两种方法的凭证添加了随机 16 字节盐值，并在存储到内存前进行哈希处理。 + +- [Bitcoin Core #31444][] 扩展了 `TxGraph` 类（参见周报 [#348][news348 txgraph]），添加了三个新的辅助函数：`GetMainStagingDiagrams()` 返回主图和暂存图之间族群的差异，`GetBlockBuilder()` 从高到低遍历图块（子族群手续费率排序分组）以优化区块构建，`GetWorstMainChunk()` 定位最低手续费率块以用于驱逐决策。该 PR 是[族群交易池][topic cluster mempool]项目完整初始实现的最后构建块之一。 + +- [Core Lightning #8140][] 默认启用通道备份的[对等节点存储][topic peer storage]（参见周报 [#238][news238 storage]），通过限制存储到当前或过去有通道的对等节点，在内存中缓存备份和对等节点列表而不是重复调用 `listdatastore`/`listpeerchannels`，将并发备份上传限制为两个对等节点，跳过大于 65 kB 的备份，并在发送时随机选择对等节点，使其适用于大型节点。 + +- [Core Lightning #8136][] 更新了公告签名的交换时机，从等待六个区块后改为通道就绪时，以符合最近的 [BOLTs #1215][] 规范更新。仍然需要等待六个区块才能[公告通道][topic channel announcements]。 + +- [Core Lightning #8266][] 为 Reckless 插件管理器（参见周报 [#226][news226 reckless]）添加了 `update` 命令，可以更新指定的插件或所有已安装的插件（如果未指定），但跳过从固定 Git 标签或提交安装的插件。该 PR 还扩展了 `install` 命令，除了插件名称外还可以接受源路径或 URL。 + +- [Core Lightning #8021][] 完成了与 Eclair 的[拼接][topic splicing]互操作性（参见周报 [#331][news331 interop]）。实现方式是通过修复远程注资密钥的轮换，在通道重新建立时重新发送 `splice_locked` 以覆盖原始遗漏的情况（参见周报 [#345][news345 splicing]），放宽对承诺签名消息到达顺序的要求，启用接收和发起拼接 [RBF][topic rbf] 交易，在需要时自动将出站 [PSBTs][topic psbt] 转换为版本 2，以及其他重构更改。 + +- [Core Lightning #8226][] 通过添加新的 `signmessagewithkey` RPC 命令实现 [BIP137][]，允许用户通过指定比特币地址使用钱包中的任何密钥签名消息。以前，使用 Core Lightning 密钥签名消息需要找到 xpriv 和密钥索引，使用外部库派生私钥，然后使用 Bitcoin Core 签名消息。 + +- [LND #9801][] 添加了新的 `--no-disconnect-on-pong-failure` 选项，用于控制在对等节点的 pong 响应延迟或不匹配时是否断开连接。该选项默认为 false，保持 LND 在 pong 消息失败时断开对等节点连接的当前行为（参见周报 [#275][news275 ping]）；否则，LND 只会记录该事件。该 PR 重构了 ping 看门狗，在抑制断开连接时继续其循环。 + +{% include snippets/recap-ad.md when="2025-05-27 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32423,31444,8140,8136,8266,8021,8226,9801,7044,1215" %} +[lnd 0.19.0-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta +[sources]: /en/internal/sources/ +[lnd rn]: https://github.com/lightningnetwork/lnd/blob/master/docs/release-notes/release-notes-0.19.0.md +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[news348 txgraph]: /zh/newsletters/2025/04/04/#bitcoin-core-31363 +[news238 storage]: /zh/newsletters/2023/02/15/#core-lightning-5361 +[news226 reckless]: /zh/newsletters/2022/11/16/#core-lightning-5647 +[news331 interop]: /zh/newsletters/2024/11/29/#core-lightning-7719 +[news345 splicing]: /zh/newsletters/2025/03/14/#eclair-3007 +[news275 ping]: /zh/newsletters/2023/11/01/#lnd-7828 +[cake wallet 4.28.0]: https://github.com/cake-tech/cake_wallet/releases/tag/v4.28.0 +[cake blog]: https://blog.cakewallet.com/bitcoin-privacy-takes-a-leap-forward-cake-wallet-introduces-payjoin-v2/ +[sparrow 2.2.0]: https://github.com/sparrowwallet/sparrow/releases/tag/2.2.0 +[safe wallet github]: https://github.com/andreasgriffin/bitcoin-safe +[safe wallet 1.3.0]: https://github.com/andreasgriffin/bitcoin-safe/releases/tag/1.3.0 +[coldcard blog]: https://blog.coinkite.com/ccc-and-keyteleport/ +[coldcard ccc]: https://coldcard.com/docs/coldcard-cosigning/ +[coldcard kt]: https://github.com/Coldcard/firmware/blob/master/docs/key-teleport.md +[private pond post]: https://njump.me/naddr1qvzqqqr4gupzqg42s9gsae3lu2cketskuzfp778fh2vg9c5x3elx8ttdpzhfkk25qq2nv5nzddgxxdjtd4u9vwrdv939vmnswfzk6j85dxk +[private pond github]: https://github.com/Kukks/PrivatePond +[jmfbs github]: https://github.com/m0wer/joinmarket-fidelity-bond-simulator +[news161 fb]: /zh/newsletters/2021/08/11/#implementation-of-fidelity-bonds +[opcode explained website]: https://opcodeexplained.com/ +[bitkey blog]: https://x.com/BEN0WHERE/status/1918073429791785086 +[bitkey github]: https://github.com/proto-at-block/bitkey From 6177f3a8b246aa78ea670f39f3719f82916c6b28 Mon Sep 17 00:00:00 2001 From: nervana21 <205626986+nervana21@users.noreply.github.com> Date: Sat, 17 May 2025 03:37:17 -0400 Subject: [PATCH 050/278] Update duplicate-transactions.md Fix typo --- _topics/en/duplicate-transactions.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_topics/en/duplicate-transactions.md b/_topics/en/duplicate-transactions.md index c95755ec7f..c05091fdb4 100644 --- a/_topics/en/duplicate-transactions.md +++ b/_topics/en/duplicate-transactions.md @@ -99,8 +99,8 @@ impossible. The [BIP30][] soft fork limited the damage by forbidding any transaction in a new block from having the same txid as a partly unspent previous -transaction. A later soft fork [BIP34][] attempted to fix the problem -entirely by requiring each coinbase transaction include unique data, +transaction. A later soft fork, [BIP34][], attempted to fix the problem +entirely by requiring each coinbase transaction to include unique data, ensuring it was a unique transaction with a unique txid. Unfortunately, it was later discovered that some pre-BIP34 blocks contained the unique data necessary for a later block to pass the BIP34 rule, called the From 9410f22f6c8ee2d708fb3f1d24d0598c640f7099 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Tue, 3 Jun 2025 15:46:11 -0500 Subject: [PATCH 051/278] Podcast: add 356 recap --- .../en/newsletters/2025-05-30-newsletter.md | 32 +++++++++---------- .../en/podcast/2025-06-03-newsletter-recap.md | 24 ++++++++++++++ 2 files changed, 40 insertions(+), 16 deletions(-) create mode 100644 _posts/en/podcast/2025-06-03-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-05-30-newsletter.md b/_posts/en/newsletters/2025-05-30-newsletter.md index 469163d015..c94069478e 100644 --- a/_posts/en/newsletters/2025-05-30-newsletter.md +++ b/_posts/en/newsletters/2025-05-30-newsletter.md @@ -61,7 +61,7 @@ software. Discussion from multiple participants evaluated the concerns and proposed solutions in more detail, as well as considering other - possible attacks and mitigations. + possible attacks and mitigations. {% assign timestamp="0:57" %} ## Selected Q&A from Bitcoin Stack Exchange @@ -77,40 +77,40 @@ answers posted since our last update.* - [Which transactions get into blockreconstructionextratxn?]({{bse}}116519) Glozow explains how the extrapool data structure (see [Newsletter #339][news339 extrapool]) caches rejected and replaced transactions seen by the node - and lists the criteria for exclusion and eviction. + and lists the criteria for exclusion and eviction. {% assign timestamp="40:40" %} - [Why would anyone use OP_RETURN over inscriptions, aside from fees?]({{bse}}126208) Sjors Provoost notes that in addition to sometimes being cheaper, `OP_RETURN` can also be used for protocols that need data to be available before a transaction - is spent, as opposed to witness data that is revealed in the spending transaction. + is spent, as opposed to witness data that is revealed in the spending transaction. {% assign timestamp="46:47" %} - [Why is my Bitcoin node not receiving incoming connections?]({{bse}}126338) Lightlike points out that a new node on the network can take time to have its address widely advertised on the P2P network and that nodes will not - advertise their address until IBD has completed. + advertise their address until IBD has completed. {% assign timestamp="48:25" %} - [How do I configure my node to filter out transactions larger than 400 bytes?]({{bse}}126347) Antoine Poinsot confirms there is no configuration option in Bitcoin Core to customize the maximum standard transaction size. He outlines that users wanting to customize that value can update their source code, but warns about - potential downsides of both larger and smaller maximum values. + potential downsides of both larger and smaller maximum values. {% assign timestamp="49:44" %} - [What does "not publicly routable" node in Bitcoin Core P2P mean?]({{bse}}126225) Pieter Wuille and Vasil Dimov provide examples of P2P connections, such as [Tor][topic anonymity networks], that cannot be routed on the global internet - and that appear in Bitcoin Core's `netinfo` output in the "npr" bucket. + and that appear in Bitcoin Core's `netinfo` output in the "npr" bucket. {% assign timestamp="52:21" %} - [Why would a node would ever relay a transaction?]({{bse}}127391) Pieter Wuille lists benefits of relaying transactions for a node operator: privacy when relaying your own transactions from your node, faster block propagation if the user is mining, and improved network decentralization with - minimal incremental costs beyond just relaying blocks. + minimal incremental costs beyond just relaying blocks. {% assign timestamp="52:46" %} - [Is selfish mining still an option with compact blocks and FIBRE?]({{bse}}49515) Antoine Poinsot follows up to a 2016 question noting, "Yes, selfish mining is still a possible optimisation even with improved block propagation. It's not correct to conclude that selfish mining is now only a theoretical attack". He - also points to a [mining simulation][miningsimulation github] he created. + also points to a [mining simulation][miningsimulation github] he created. {% assign timestamp="55:00" %} ## Releases and release candidates @@ -119,14 +119,14 @@ projects. Please consider upgrading to new releases or helping to test release candidates._ - [Core Lightning 25.05rc1][] is a release candidate for the next major - version of this popular LN node implementation. + version of this popular LN node implementation. {% assign timestamp="57:25" %} - [LDK 0.1.3][] and [0.1.4][ldk 0.1.4] are releases of this popular library for building LN-enabled applications. Version 0.1.3, tagged as a release on GitHub this week but dated last month, includes the fix for a denial-of-service attack. Version 0.1.4, the latest release, "fixes a funds-theft vulnerability in exceeding rare cases". - Both releases also include other bug fixes. + Both releases also include other bug fixes. {% assign timestamp="57:56" %} ## Notable code and documentation changes @@ -145,7 +145,7 @@ repo], and [BINANAs][binana repo]._ the same sighash type, so this field must be present in the PSBT. Additionally, the `descriptorprocesspsbt` RPC command is updated to use the `SignPSBTInput` function, which ensures that the PSBT's sighash type matches - the one provided in the CLI, if applicable. + the one provided in the CLI, if applicable. {% assign timestamp="1:00:32" %} - [Eclair #3065][] adds support for attributable failures (see Newsletter [#224][news224 failures]) as specified in [BOLTs #1044][]. It’s disabled by @@ -153,18 +153,18 @@ repo], and [BINANAs][binana repo]._ setting `eclair.features.option_attributable_failure = optional`. Cross-compatibility with LDK has been successfully tested, see Newsletter [#349][news349 failures] for more information on LDK’s implementation and how - this protocol works. + this protocol works. {% assign timestamp="37:15" %} - [LDK #3796][] tightens the channel balance checks so that funders have sufficient funds to cover the commitment transaction fee, the two 330 sat [anchor outputs][topic anchor outputs], and the channel reserve. Previously, - funders could dip into the channel reserve funds to cover for the two anchors. + funders could dip into the channel reserve funds to cover for the two anchors. {% assign timestamp="1:03:04" %} - [BIPs #1760][] merges [BIP53][] which specifies a consensus soft-fork rule that disallows 64-byte transactions (measured without witness data) to prevent a type of [merkle tree vulnerability][topic merkle tree vulnerabilities] exploitable against SPV clients. This PR proposes a similar fix to one - of the fixes included in the [consensus cleanup softfork][topic consensus cleanup]. + of the fixes included in the [consensus cleanup softfork][topic consensus cleanup]. {% assign timestamp="1:03:40" %} - [BIPs #1850][] reverts an earlier update to [BIP48][] which reserved the script type value 3 for [taproot][topic taproot] (P2TR) derivations (see @@ -173,13 +173,13 @@ repo], and [BINANAs][binana repo]._ [BIP48][] relies on) cannot be expressed in P2TR. This PR also marks [BIP48][]’s status as `Final`, reflecting that its purpose was to define the industry use of `m/48'` [HD wallet][topic bip32] derivation paths when the BIP - was introduced, rather than prescribe new behavior. + was introduced, rather than prescribe new behavior. {% assign timestamp="1:06:13" %} - [BIPs #1793][] merges [BIP443][] which proposes the [OP_CHECKCONTRACTVERIFY][topic matt] (OP_CCV) opcode that allows checking that a public key (of both the outputs and the inputs) commits to an arbitrary piece of data. See Newsletter [#348][news348 op_ccv] for more - information on this proposed [covenant][topic covenants]. + information on this proposed [covenant][topic covenants]. {% assign timestamp="1:09:05" %} {% include snippets/recap-ad.md when="2025-06-03 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-06-03-newsletter-recap.md b/_posts/en/podcast/2025-06-03-newsletter-recap.md new file mode 100644 index 0000000000..7c3c143ddd --- /dev/null +++ b/_posts/en/podcast/2025-06-03-newsletter-recap.md @@ -0,0 +1,24 @@ +--- +title: 'Bitcoin Optech Newsletter #356 Recap Podcast' +permalink: /en/podcast/2025/06/03/ +reference: /en/newsletters/2025/05/30/ +name: 2025-06-03-recap +slug: 2025-06-03-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt are joined by Carla Kirk-Cohen, Joost +Jager, and Elias Rohrer to discuss [Newsletter #356]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-5-3/401522428-44100-2-77051dca84d02.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From fde74520abc1c8820baa72166cc63905d5c5926c Mon Sep 17 00:00:00 2001 From: Walpurga03 Date: Wed, 4 Jun 2025 19:33:11 +0200 Subject: [PATCH 052/278] newsletter 351 into german --- .../de/newsletters/2025-04-25-newsletter.md | 78 +++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 _posts/de/newsletters/2025-04-25-newsletter.md diff --git a/_posts/de/newsletters/2025-04-25-newsletter.md b/_posts/de/newsletters/2025-04-25-newsletter.md new file mode 100644 index 0000000000..a07d5d36af --- /dev/null +++ b/_posts/de/newsletters/2025-04-25-newsletter.md @@ -0,0 +1,78 @@ +--- +title: 'Bitcoin Optech Newsletter #351' +permalink: /de/newsletters/2025/04/25/ +name: 2025-04-25-newsletter-de +slug: 2025-04-25-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche kündigt ein neues Aggregat-Signaturprotokoll an, das mit secp256k1 kompatibel ist, und beschreibt ein standardisiertes Backup-Schema für Wallet-Deskriptoren. Ebenfalls enthalten sind unsere regulären Abschnitte mit Zusammenfassungen aktueller Fragen und Antworten von Bitcoin Stack Exchange, Ankündigungen neuer Releases und Release-Kandidaten sowie Beschreibungen wichtiger Änderungen an populärer Bitcoin-Infrastruktur. + +## Nachrichten + +- **Interaktive Aggregat-Signaturen kompatibel mit secp256k1:** Jonas Nick, Tim Ruffing und Yannick Seurin [veröffentlichten][nrs dahlias] in der Bitcoin-Dev-Mailingliste einen Hinweis auf ein [Paper][dahlias paper], das sie über die Erstellung von 64-Byte-Aggregat-Signaturen geschrieben haben, die mit den bereits in Bitcoin verwendeten kryptographischen Primitiven kompatibel sind. Aggregat-Signaturen sind die kryptographische Voraussetzung für [Cross-Input Signature Aggregation][topic cisa] (CISA), ein vorgeschlagenes Feature für Bitcoin, das die Größe von Transaktionen mit mehreren Inputs reduzieren könnte. Dadurch würden die Kosten vieler verschiedener Arten von Ausgaben sinken – einschließlich datenschutzfreundlicher Ausgaben durch [Coinjoins][topic coinjoin] und [Payjoins][topic payjoin]. + + Zusätzlich zu einem Aggregat-Signaturschema wie dem von den Autoren vorgeschlagenen DahLIAS-Schema würde die Unterstützung von CISA in Bitcoin eine Konsensänderung erfordern. Mögliche Wechselwirkungen zwischen Signaturaggregation und anderen vorgeschlagenen Konsensänderungen könnten weitere Untersuchungen erfordern. {% assign timestamp="0:50" %} + +- **Standardisiertes Backup für Wallet-Deskriptoren:** Salvatore Ingala [veröffentlichte][ingala backdes] auf Delving Bitcoin eine Zusammenfassung verschiedener Abwägungen beim Backup von Wallet-[Deskriptoren][topic descriptors] und ein vorgeschlagenes Schema, das für viele verschiedene Wallet-Typen nützlich sein sollte, einschließlich solcher mit komplexen Skripten. Sein Schema verschlüsselt Deskriptoren mit einem deterministisch generierten 32-Byte-Geheimnis. Für jeden öffentlichen Schlüssel (oder Extended Public Key) im Deskriptor wird eine Kopie des Geheimnisses mit einer Variante des öffentlichen Schlüssels XOR-verknüpft, wodurch _n_ 32-Byte-Geheimnisverschlüsselungen für _n_ öffentliche Schlüssel entstehen. Jeder, der einen der im Deskriptor verwendeten öffentlichen Schlüssel kennt, kann diesen mit der 32-Byte-Geheimnisverschlüsselung XORen, um das 32-Byte-Geheimnis zu erhalten, das den Deskriptor entschlüsseln kann. Dieses einfache und effiziente Schema ermöglicht es, viele verschlüsselte Kopien eines Deskriptors auf verschiedenen Medien und an verschiedenen Orten zu speichern und dann mit dem [BIP32-Wallet-Seed][topic bip32] den eigenen xpub zu generieren, mit dem sich der Deskriptor im Notfall wiederherstellen lässt. {% assign timestamp="21:34" %} + +## Ausgewählte Q&A von Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] ist einer der ersten Orte, an denen Optech-Mitwirkende nach Antworten suchen – oder wenn wir ein paar Minuten Zeit haben, um neugierigen oder ratlosen Nutzern zu helfen. In dieser monatlichen Rubrik heben wir einige der am höchsten bewerteten Fragen und Antworten hervor, die seit unserem letzten Update gepostet wurden.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Wie praktikabel sind halbaggregierte Schnorr-Signaturen?]({{bse}}125982) + Fjahr erläutert, warum unabhängige, nicht aggregierte Signaturen nicht erforderlich sind, um eine halbaggregierte Signatur bei [Cross-Input Signature Aggregation (CISA)][topic cisa] zu validieren, und warum nicht aggregierte Signaturen tatsächlich problematisch sein können. {% assign timestamp="17:16" %} + +- [Was ist die größte jemals erstellte OP_RETURN-Payload?]({{bse}}126131) + Vojtěch Strnad [verlinkt][op_return tx] auf eine Runes-[Meta-Protokoll][topic client-side validation]-Transaktion mit 79.870 Bytes als größtem `OP_RETURN`. {% assign timestamp="41:17" %} + +- [Nicht-LN-Erklärung zu Pay-to-Anchor?]({{bse}}126098) + Murch erläutert die Motivation und Struktur von [Pay-to-Anchor (P2A)][topic ephemeral anchors]-Ausgabe-Skripten. {% assign timestamp="43:29" %} + +- [Aktuelle Statistiken zu Chain Reorganizations?]({{bse}}126019) + 0xb10c und Murch nennen Quellen für Reorg-Daten, darunter das [stale-blocks][stale-blocks github]-Repository, die Website [forkmonitor.info][] und die Website [fork.observer][]. {% assign timestamp="48:08" %} + +- [Sind Lightning-Channels immer P2WSH?]({{bse}}125967) + Polespinasa weist auf die laufende Entwicklung von P2TR-[Simple Taproot Channels][topic simple taproot channels] hin und fasst die aktuelle Unterstützung in Lightning-Implementierungen zusammen. {% assign timestamp="52:33" %} + +- [Child-pays-for-parent als Verteidigung gegen Double-Spend?]({{bse}}126056) + Murch listet Komplikationen bei der Verwendung einer hoch gebührenbehafteten [CPFP][topic cpfp]-Child-Transaktion auf, um eine Blockchain-Reorg als Verteidigung gegen einen bereits bestätigten Double-Spend zu incentivieren. {% assign timestamp="53:40" %} + +- [Welche Werte hasht CHECKTEMPLATEVERIFY?]({{bse}}126133) + Average-gray beschreibt die Felder, auf die [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] verpflichtet: nVersion, nLockTime, Input-Anzahl, Sequences-Hash, Output-Anzahl, Outputs-Hash, Input-Index und in manchen Fällen der ScriptSig-Hash. {% assign timestamp="59:06" %} + +- [Warum können Lightning-Knoten nicht einfach Channel-Bilanzen offenlegen, um Routing-Effizienz zu verbessern?]({{bse}}125985) + Rene Pickhardt erklärt Bedenken hinsichtlich der Aktualität und Vertrauenswürdigkeit der Daten, Datenschutzaspekte und verweist auf einen [ähnlichen Vorschlag][BOLTs #780] aus dem Jahr 2020. {% assign timestamp="59:32" %} + +- [Erfordert Post-Quantum einen Hard Fork oder Soft Fork?]({{bse}}126122) + Vojtěch Strnad skizziert einen Ansatz, wie ein [Post-Quantum][topic quantum resistance] (PQC)-Signaturschema per [Soft Fork aktiviert][topic soft fork activation] werden könnte und wie ein Hard oder Soft Fork quantenanfällige Coins sperren könnte. {% assign timestamp="1:02:27" %} + +## Veröffentlichungen und Release-Kandidaten + +_Neue Veröffentlichungen und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie ein Upgrade auf neue Versionen oder helfen Sie bei der Testung von Release-Kandidaten._ + +- [LND 0.19.0-beta.rc3][] ist ein Release-Kandidat für diesen beliebten LN-Knoten. Eine der wichtigsten Verbesserungen, die getestet werden sollten, ist das neue RBF-basierte Fee-Bumping für kooperative Schließungen. {% assign timestamp="1:07:39" %} + +## Wichtige Code- und Dokumentationsänderungen + +_Bedeutende kürzliche Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und [BINANAs][binana repo]._ + +- [Bitcoin Core #31247][] fügt Unterstützung für das Serialisieren und Parsen von [MuSig2][topic musig]-[PSBT][topic psbt]-Feldern gemäß [BIP373][] hinzu, damit Wallets [MuSig2][topic musig]-Inputs signieren und ausgeben können. Auf der Input-Seite besteht dies aus einem Feld mit den Teilnehmer-Pubkeys, einem separaten Public-Nonce-Feld und einem separaten Partial-Signature-Feld für jeden Signer. Auf der Output-Seite ist es ein einzelnes Feld mit den Teilnehmer-Pubkeys für das neue UTXO. {% assign timestamp="1:07:58" %} + +- [LDK #3601][] fügt ein neues `LocalHTLCFailureReason`-Enum hinzu, das jeden Standard-[BOLT4][]-Fehlercode abbildet, zusammen mit einigen Varianten, die dem Nutzer zusätzliche Informationen liefern, die zuvor aus Datenschutzgründen entfernt wurden. {% assign timestamp="1:10:14" %} + +{% include snippets/recap-ad.md when="2025-04-29 15:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31247,3601,780" %} +[lnd 0.19.0-beta.rc3]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc3 +[nrs dahlias]: https://mailing-list.bitcoindevs.xyz/bitcoindev/be3813bf-467d-4880-9383-2a0b0223e7e5@gmail.com/ +[dahlias paper]: https://eprint.iacr.org/2025/692.pdf +[ingala backdes]: https://delvingbitcoin.org/t/a-simple-backup-scheme-for-wallet-accounts/1607 +[op_return tx]: https://mempool.space/tx/fd3c5762e882489a62da3ba75a04ed283543bfc15737e3d6576042810ab553bc +[stale-blocks github]: https://github.com/bitcoin-data/stale-blocks +[forkmonitor.info]: https://forkmonitor.info/nodes/btc +[fork.observer]: https://fork.observer/ From 674dc4701f85d838e64eb5d19e64e8552794f419 Mon Sep 17 00:00:00 2001 From: Murch Date: Wed, 4 Jun 2025 11:42:12 -0700 Subject: [PATCH 053/278] DE-351: Remove recap timestamps from German newsletter I replaced all the timestamps by using the string editor with a regular expression: ``` $ sed -i 's/ {.*timestamp.*}//' _posts/de/newsletters/2025-04-25-newsletter.md ``` --- .../de/newsletters/2025-04-25-newsletter.md | 29 +++++++++---------- 1 file changed, 14 insertions(+), 15 deletions(-) diff --git a/_posts/de/newsletters/2025-04-25-newsletter.md b/_posts/de/newsletters/2025-04-25-newsletter.md index a07d5d36af..29abcf4340 100644 --- a/_posts/de/newsletters/2025-04-25-newsletter.md +++ b/_posts/de/newsletters/2025-04-25-newsletter.md @@ -13,9 +13,9 @@ Der Newsletter dieser Woche kündigt ein neues Aggregat-Signaturprotokoll an, da - **Interaktive Aggregat-Signaturen kompatibel mit secp256k1:** Jonas Nick, Tim Ruffing und Yannick Seurin [veröffentlichten][nrs dahlias] in der Bitcoin-Dev-Mailingliste einen Hinweis auf ein [Paper][dahlias paper], das sie über die Erstellung von 64-Byte-Aggregat-Signaturen geschrieben haben, die mit den bereits in Bitcoin verwendeten kryptographischen Primitiven kompatibel sind. Aggregat-Signaturen sind die kryptographische Voraussetzung für [Cross-Input Signature Aggregation][topic cisa] (CISA), ein vorgeschlagenes Feature für Bitcoin, das die Größe von Transaktionen mit mehreren Inputs reduzieren könnte. Dadurch würden die Kosten vieler verschiedener Arten von Ausgaben sinken – einschließlich datenschutzfreundlicher Ausgaben durch [Coinjoins][topic coinjoin] und [Payjoins][topic payjoin]. - Zusätzlich zu einem Aggregat-Signaturschema wie dem von den Autoren vorgeschlagenen DahLIAS-Schema würde die Unterstützung von CISA in Bitcoin eine Konsensänderung erfordern. Mögliche Wechselwirkungen zwischen Signaturaggregation und anderen vorgeschlagenen Konsensänderungen könnten weitere Untersuchungen erfordern. {% assign timestamp="0:50" %} + Zusätzlich zu einem Aggregat-Signaturschema wie dem von den Autoren vorgeschlagenen DahLIAS-Schema würde die Unterstützung von CISA in Bitcoin eine Konsensänderung erfordern. Mögliche Wechselwirkungen zwischen Signaturaggregation und anderen vorgeschlagenen Konsensänderungen könnten weitere Untersuchungen erfordern. -- **Standardisiertes Backup für Wallet-Deskriptoren:** Salvatore Ingala [veröffentlichte][ingala backdes] auf Delving Bitcoin eine Zusammenfassung verschiedener Abwägungen beim Backup von Wallet-[Deskriptoren][topic descriptors] und ein vorgeschlagenes Schema, das für viele verschiedene Wallet-Typen nützlich sein sollte, einschließlich solcher mit komplexen Skripten. Sein Schema verschlüsselt Deskriptoren mit einem deterministisch generierten 32-Byte-Geheimnis. Für jeden öffentlichen Schlüssel (oder Extended Public Key) im Deskriptor wird eine Kopie des Geheimnisses mit einer Variante des öffentlichen Schlüssels XOR-verknüpft, wodurch _n_ 32-Byte-Geheimnisverschlüsselungen für _n_ öffentliche Schlüssel entstehen. Jeder, der einen der im Deskriptor verwendeten öffentlichen Schlüssel kennt, kann diesen mit der 32-Byte-Geheimnisverschlüsselung XORen, um das 32-Byte-Geheimnis zu erhalten, das den Deskriptor entschlüsseln kann. Dieses einfache und effiziente Schema ermöglicht es, viele verschlüsselte Kopien eines Deskriptors auf verschiedenen Medien und an verschiedenen Orten zu speichern und dann mit dem [BIP32-Wallet-Seed][topic bip32] den eigenen xpub zu generieren, mit dem sich der Deskriptor im Notfall wiederherstellen lässt. {% assign timestamp="21:34" %} +- **Standardisiertes Backup für Wallet-Deskriptoren:** Salvatore Ingala [veröffentlichte][ingala backdes] auf Delving Bitcoin eine Zusammenfassung verschiedener Abwägungen beim Backup von Wallet-[Deskriptoren][topic descriptors] und ein vorgeschlagenes Schema, das für viele verschiedene Wallet-Typen nützlich sein sollte, einschließlich solcher mit komplexen Skripten. Sein Schema verschlüsselt Deskriptoren mit einem deterministisch generierten 32-Byte-Geheimnis. Für jeden öffentlichen Schlüssel (oder Extended Public Key) im Deskriptor wird eine Kopie des Geheimnisses mit einer Variante des öffentlichen Schlüssels XOR-verknüpft, wodurch _n_ 32-Byte-Geheimnisverschlüsselungen für _n_ öffentliche Schlüssel entstehen. Jeder, der einen der im Deskriptor verwendeten öffentlichen Schlüssel kennt, kann diesen mit der 32-Byte-Geheimnisverschlüsselung XORen, um das 32-Byte-Geheimnis zu erhalten, das den Deskriptor entschlüsseln kann. Dieses einfache und effiziente Schema ermöglicht es, viele verschlüsselte Kopien eines Deskriptors auf verschiedenen Medien und an verschiedenen Orten zu speichern und dann mit dem [BIP32-Wallet-Seed][topic bip32] den eigenen xpub zu generieren, mit dem sich der Deskriptor im Notfall wiederherstellen lässt. ## Ausgewählte Q&A von Bitcoin Stack Exchange @@ -25,47 +25,46 @@ Der Newsletter dieser Woche kündigt ein neues Aggregat-Signaturprotokoll an, da {% assign bse = "https://bitcoin.stackexchange.com/a/" %} - [Wie praktikabel sind halbaggregierte Schnorr-Signaturen?]({{bse}}125982) - Fjahr erläutert, warum unabhängige, nicht aggregierte Signaturen nicht erforderlich sind, um eine halbaggregierte Signatur bei [Cross-Input Signature Aggregation (CISA)][topic cisa] zu validieren, und warum nicht aggregierte Signaturen tatsächlich problematisch sein können. {% assign timestamp="17:16" %} + Fjahr erläutert, warum unabhängige, nicht aggregierte Signaturen nicht erforderlich sind, um eine halbaggregierte Signatur bei [Cross-Input Signature Aggregation (CISA)][topic cisa] zu validieren, und warum nicht aggregierte Signaturen tatsächlich problematisch sein können. - [Was ist die größte jemals erstellte OP_RETURN-Payload?]({{bse}}126131) - Vojtěch Strnad [verlinkt][op_return tx] auf eine Runes-[Meta-Protokoll][topic client-side validation]-Transaktion mit 79.870 Bytes als größtem `OP_RETURN`. {% assign timestamp="41:17" %} + Vojtěch Strnad [verlinkt][op_return tx] auf eine Runes-[Meta-Protokoll][topic client-side validation]-Transaktion mit 79.870 Bytes als größtem `OP_RETURN`. - [Nicht-LN-Erklärung zu Pay-to-Anchor?]({{bse}}126098) - Murch erläutert die Motivation und Struktur von [Pay-to-Anchor (P2A)][topic ephemeral anchors]-Ausgabe-Skripten. {% assign timestamp="43:29" %} + Murch erläutert die Motivation und Struktur von [Pay-to-Anchor (P2A)][topic ephemeral anchors]-Ausgabe-Skripten. - [Aktuelle Statistiken zu Chain Reorganizations?]({{bse}}126019) - 0xb10c und Murch nennen Quellen für Reorg-Daten, darunter das [stale-blocks][stale-blocks github]-Repository, die Website [forkmonitor.info][] und die Website [fork.observer][]. {% assign timestamp="48:08" %} + 0xb10c und Murch nennen Quellen für Reorg-Daten, darunter das [stale-blocks][stale-blocks github]-Repository, die Website [forkmonitor.info][] und die Website [fork.observer][]. - [Sind Lightning-Channels immer P2WSH?]({{bse}}125967) - Polespinasa weist auf die laufende Entwicklung von P2TR-[Simple Taproot Channels][topic simple taproot channels] hin und fasst die aktuelle Unterstützung in Lightning-Implementierungen zusammen. {% assign timestamp="52:33" %} + Polespinasa weist auf die laufende Entwicklung von P2TR-[Simple Taproot Channels][topic simple taproot channels] hin und fasst die aktuelle Unterstützung in Lightning-Implementierungen zusammen. - [Child-pays-for-parent als Verteidigung gegen Double-Spend?]({{bse}}126056) - Murch listet Komplikationen bei der Verwendung einer hoch gebührenbehafteten [CPFP][topic cpfp]-Child-Transaktion auf, um eine Blockchain-Reorg als Verteidigung gegen einen bereits bestätigten Double-Spend zu incentivieren. {% assign timestamp="53:40" %} + Murch listet Komplikationen bei der Verwendung einer hoch gebührenbehafteten [CPFP][topic cpfp]-Child-Transaktion auf, um eine Blockchain-Reorg als Verteidigung gegen einen bereits bestätigten Double-Spend zu incentivieren. - [Welche Werte hasht CHECKTEMPLATEVERIFY?]({{bse}}126133) - Average-gray beschreibt die Felder, auf die [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] verpflichtet: nVersion, nLockTime, Input-Anzahl, Sequences-Hash, Output-Anzahl, Outputs-Hash, Input-Index und in manchen Fällen der ScriptSig-Hash. {% assign timestamp="59:06" %} + Average-gray beschreibt die Felder, auf die [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] verpflichtet: nVersion, nLockTime, Input-Anzahl, Sequences-Hash, Output-Anzahl, Outputs-Hash, Input-Index und in manchen Fällen der ScriptSig-Hash. - [Warum können Lightning-Knoten nicht einfach Channel-Bilanzen offenlegen, um Routing-Effizienz zu verbessern?]({{bse}}125985) - Rene Pickhardt erklärt Bedenken hinsichtlich der Aktualität und Vertrauenswürdigkeit der Daten, Datenschutzaspekte und verweist auf einen [ähnlichen Vorschlag][BOLTs #780] aus dem Jahr 2020. {% assign timestamp="59:32" %} + Rene Pickhardt erklärt Bedenken hinsichtlich der Aktualität und Vertrauenswürdigkeit der Daten, Datenschutzaspekte und verweist auf einen [ähnlichen Vorschlag][BOLTs #780] aus dem Jahr 2020. - [Erfordert Post-Quantum einen Hard Fork oder Soft Fork?]({{bse}}126122) - Vojtěch Strnad skizziert einen Ansatz, wie ein [Post-Quantum][topic quantum resistance] (PQC)-Signaturschema per [Soft Fork aktiviert][topic soft fork activation] werden könnte und wie ein Hard oder Soft Fork quantenanfällige Coins sperren könnte. {% assign timestamp="1:02:27" %} + Vojtěch Strnad skizziert einen Ansatz, wie ein [Post-Quantum][topic quantum resistance] (PQC)-Signaturschema per [Soft Fork aktiviert][topic soft fork activation] werden könnte und wie ein Hard oder Soft Fork quantenanfällige Coins sperren könnte. ## Veröffentlichungen und Release-Kandidaten _Neue Veröffentlichungen und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie ein Upgrade auf neue Versionen oder helfen Sie bei der Testung von Release-Kandidaten._ -- [LND 0.19.0-beta.rc3][] ist ein Release-Kandidat für diesen beliebten LN-Knoten. Eine der wichtigsten Verbesserungen, die getestet werden sollten, ist das neue RBF-basierte Fee-Bumping für kooperative Schließungen. {% assign timestamp="1:07:39" %} +- [LND 0.19.0-beta.rc3][] ist ein Release-Kandidat für diesen beliebten LN-Knoten. Eine der wichtigsten Verbesserungen, die getestet werden sollten, ist das neue RBF-basierte Fee-Bumping für kooperative Schließungen. ## Wichtige Code- und Dokumentationsänderungen _Bedeutende kürzliche Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und [BINANAs][binana repo]._ -- [Bitcoin Core #31247][] fügt Unterstützung für das Serialisieren und Parsen von [MuSig2][topic musig]-[PSBT][topic psbt]-Feldern gemäß [BIP373][] hinzu, damit Wallets [MuSig2][topic musig]-Inputs signieren und ausgeben können. Auf der Input-Seite besteht dies aus einem Feld mit den Teilnehmer-Pubkeys, einem separaten Public-Nonce-Feld und einem separaten Partial-Signature-Feld für jeden Signer. Auf der Output-Seite ist es ein einzelnes Feld mit den Teilnehmer-Pubkeys für das neue UTXO. {% assign timestamp="1:07:58" %} +- [Bitcoin Core #31247][] fügt Unterstützung für das Serialisieren und Parsen von [MuSig2][topic musig]-[PSBT][topic psbt]-Feldern gemäß [BIP373][] hinzu, damit Wallets [MuSig2][topic musig]-Inputs signieren und ausgeben können. Auf der Input-Seite besteht dies aus einem Feld mit den Teilnehmer-Pubkeys, einem separaten Public-Nonce-Feld und einem separaten Partial-Signature-Feld für jeden Signer. Auf der Output-Seite ist es ein einzelnes Feld mit den Teilnehmer-Pubkeys für das neue UTXO. -- [LDK #3601][] fügt ein neues `LocalHTLCFailureReason`-Enum hinzu, das jeden Standard-[BOLT4][]-Fehlercode abbildet, zusammen mit einigen Varianten, die dem Nutzer zusätzliche Informationen liefern, die zuvor aus Datenschutzgründen entfernt wurden. {% assign timestamp="1:10:14" %} +- [LDK #3601][] fügt ein neues `LocalHTLCFailureReason`-Enum hinzu, das jeden Standard-[BOLT4][]-Fehlercode abbildet, zusammen mit einigen Varianten, die dem Nutzer zusätzliche Informationen liefern, die zuvor aus Datenschutzgründen entfernt wurden. -{% include snippets/recap-ad.md when="2025-04-29 15:30" %} {% include references.md %} {% include linkers/issues.md v=2 issues="31247,3601,780" %} [lnd 0.19.0-beta.rc3]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc3 From e78dcbcf5faacbae5e565d97b47d3e48b3864af9 Mon Sep 17 00:00:00 2001 From: Murch Date: Wed, 4 Jun 2025 12:54:01 -0700 Subject: [PATCH 054/278] DE-352: Remove timestamps --- _posts/de/newsletters/2025-05-02-newsletter.md | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/_posts/de/newsletters/2025-05-02-newsletter.md b/_posts/de/newsletters/2025-05-02-newsletter.md index acd373dba7..bc4ff5c60d 100644 --- a/_posts/de/newsletters/2025-05-02-newsletter.md +++ b/_posts/de/newsletters/2025-05-02-newsletter.md @@ -12,7 +12,7 @@ Der Newsletter dieser Woche verweist auf Vergleiche verschiedener Cluster-Linear ## Nachrichten - **Vergleich von Cluster-Linearisationstechniken:** - Pieter Wuille [veröffentlichte][wuille clustrade] auf Delving Bitcoin einige grundlegende Abwägungen zwischen drei verschiedenen Cluster-Linearisationstechniken und ergänzte dies durch [Benchmarks][wuille clusbench] der jeweiligen Implementierungen. Mehrere andere Entwickler diskutierten die Ergebnisse und stellten Rückfragen, auf die Wuille antwortete. {% assign timestamp="0:41" %} + Pieter Wuille [veröffentlichte][wuille clustrade] auf Delving Bitcoin einige grundlegende Abwägungen zwischen drei verschiedenen Cluster-Linearisationstechniken und ergänzte dies durch [Benchmarks][wuille clusbench] der jeweiligen Implementierungen. Mehrere andere Entwickler diskutierten die Ergebnisse und stellten Rückfragen, auf die Wuille antwortete. - **Erhöhung oder Abschaffung des `OP_RETURN`-Größenlimits in Bitcoin Core:** In einem Thread auf der Bitcoin-Dev-Mailingliste diskutierten mehrere Entwickler, das Standardlimit für `OP_RETURN`-Data-Carrier-Outputs in Bitcoin Core zu ändern oder ganz abzuschaffen. Eine nachfolgende [Pull-Request-Diskussion][bitcoin core #32359] brachte weitere Argumente. Anstatt die gesamte umfangreiche Diskussion zusammenzufassen, stellen wir das aus unserer Sicht überzeugendste Argument für und gegen die Änderung vor. @@ -23,27 +23,25 @@ Der Newsletter dieser Woche verweist auf Vergleiche verschiedener Cluster-Linear - *Gegen die Erhöhung des Limits:* Jason Hughes [argumentierte][hughes opr], dass eine Erhöhung des Limits es einfacher machen würde, beliebige Daten auf Rechnern zu speichern, die Full Knoten betreiben – darunter auch potenziell anstößige oder in vielen Ländern illegale Inhalte. Selbst wenn der Knoten die Daten auf der Festplatte verschlüsselt (siehe [Newsletter #316][news316 blockxor]), könnte das Speichern und Abrufen solcher Daten über Bitcoin Core RPCs für viele Nutzer problematisch sein. -{% assign timestamp="6:46" %} ## Veröffentlichungen und Release-Kandidaten _Neue Veröffentlichungen und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie ein Upgrade auf neue Versionen oder helfen Sie bei der Testung von Release-Kandidaten._ -- [LND 0.19.0-beta.rc3][] ist ein Release-Kandidat für diesen beliebten LN-Knoten. Eine der wichtigsten Verbesserungen, die getestet werden sollten, ist das neue RBF-basierte Fee-Bumping für kooperative Schließungen. {% assign timestamp="1:01:16" %} +- [LND 0.19.0-beta.rc3][] ist ein Release-Kandidat für diesen beliebten LN-Knoten. Eine der wichtigsten Verbesserungen, die getestet werden sollten, ist das neue RBF-basierte Fee-Bumping für kooperative Schließungen. ## Wichtige Code- und Dokumentationsänderungen _Bedeutende kürzliche Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und [BINANAs][binana repo]._ -- [Bitcoin Core #31250][] deaktiviert die Erstellung und das Laden von Legacy-Wallets und schließt damit die Migration zu [Deskriptor][topic descriptors]-Wallets ab, die seit Oktober 2021 Standard sind (siehe Newsletter [#172][news172 descriptors]). Berkeley DB-Dateien von Legacy-Wallets können nicht mehr geladen werden, und alle Unit- und Funktionstests für Legacy-Wallets werden entfernt. Ein Teil des Legacy-Wallet-Codes bleibt noch erhalten, wird aber in Folge-PRs entfernt. Bitcoin Core kann weiterhin Legacy-Wallets in das neue Deskriptor-Wallet-Format migrieren (siehe [Newsletter #305][news305 bdbro]). {% assign timestamp="1:02:10" %} +- [Bitcoin Core #31250][] deaktiviert die Erstellung und das Laden von Legacy-Wallets und schließt damit die Migration zu [Deskriptor][topic descriptors]-Wallets ab, die seit Oktober 2021 Standard sind (siehe Newsletter [#172][news172 descriptors]). Berkeley DB-Dateien von Legacy-Wallets können nicht mehr geladen werden, und alle Unit- und Funktionstests für Legacy-Wallets werden entfernt. Ein Teil des Legacy-Wallet-Codes bleibt noch erhalten, wird aber in Folge-PRs entfernt. Bitcoin Core kann weiterhin Legacy-Wallets in das neue Deskriptor-Wallet-Format migrieren (siehe [Newsletter #305][news305 bdbro]). -- [Eclair #3064][] überarbeitet das Channel-Key-Management durch Einführung einer `ChannelKeys`-Klasse. Jeder Channel hat nun ein eigenes `ChannelKeys`-Objekt, das zusammen mit den Commitment-Points ein `CommitmentKeys`-Set für die Signierung von Remote/Local-Commitment- und [HTLC][topic htlc]-Transaktionen ableitet. Die Logik für Zwangsschließungen und das Erstellen von Script/Witness wird ebenfalls angepasst. Zuvor war die Schlüsselerzeugung auf mehrere Teile des Codes verteilt, was fehleranfällig war, da die richtige Pubkey-Übergabe nicht typgesichert war. {% assign timestamp="1:06:02" %} +- [Eclair #3064][] überarbeitet das Channel-Key-Management durch Einführung einer `ChannelKeys`-Klasse. Jeder Channel hat nun ein eigenes `ChannelKeys`-Objekt, das zusammen mit den Commitment-Points ein `CommitmentKeys`-Set für die Signierung von Remote/Local-Commitment- und [HTLC][topic htlc]-Transaktionen ableitet. Die Logik für Zwangsschließungen und das Erstellen von Script/Witness wird ebenfalls angepasst. Zuvor war die Schlüsselerzeugung auf mehrere Teile des Codes verteilt, was fehleranfällig war, da die richtige Pubkey-Übergabe nicht typgesichert war. -- [BTCPay Server #6684][] fügt Unterstützung für einen Teil der [BIP388][]-Wallet-Policy-[Deskriptoren][topic descriptors] hinzu, sodass Nutzer sowohl Single-Sig- als auch k-of-n-Policies importieren und exportieren können. Unterstützt werden die von Sparrow verwendeten Formate wie P2PKH, P2WPKH, P2SH-P2WPKH und P2TR sowie die entsprechenden Multisig-Varianten (außer P2TR). Ziel dieses PR ist die Verbesserung der Multisig-Wallet-Nutzung. {% assign timestamp="1:07:46" %} +- [BTCPay Server #6684][] fügt Unterstützung für einen Teil der [BIP388][]-Wallet-Policy-[Deskriptoren][topic descriptors] hinzu, sodass Nutzer sowohl Single-Sig- als auch k-of-n-Policies importieren und exportieren können. Unterstützt werden die von Sparrow verwendeten Formate wie P2PKH, P2WPKH, P2SH-P2WPKH und P2TR sowie die entsprechenden Multisig-Varianten (außer P2TR). Ziel dieses PR ist die Verbesserung der Multisig-Wallet-Nutzung. -- [BIPs #1555][] merged [BIP321][], das ein URI-Schema für Bitcoin-Zahlungsanweisungen vorschlägt, das [BIP21][] modernisiert und erweitert. Es behält den alten pfadbasierten Adressstil bei, standardisiert aber die Nutzung von Query-Parametern, sodass neue Zahlungsarten über eigene Parameter identifiziert werden können. Das Adressfeld kann leer bleiben, wenn mindestens eine Anweisung als Query-Parameter angegeben ist. Optional kann ein Zahlungsnachweis für den Sender bereitgestellt werden, und es gibt Hinweise zur Integration neuer Zahlungsanweisungen. {% assign timestamp="1:10:34" %} +- [BIPs #1555][] merged [BIP321][], das ein URI-Schema für Bitcoin-Zahlungsanweisungen vorschlägt, das [BIP21][] modernisiert und erweitert. Es behält den alten pfadbasierten Adressstil bei, standardisiert aber die Nutzung von Query-Parametern, sodass neue Zahlungsarten über eigene Parameter identifiziert werden können. Das Adressfeld kann leer bleiben, wenn mindestens eine Anweisung als Query-Parameter angegeben ist. Optional kann ein Zahlungsnachweis für den Sender bereitgestellt werden, und es gibt Hinweise zur Integration neuer Zahlungsanweisungen. -{% include snippets/recap-ad.md when="2025-05-06 16:30" %} {% include references.md %} {% include linkers/issues.md v=2 issues="31250,3064,6684,1555,32359" %} [lnd 0.19.0-beta.rc3]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc3 From 11449579c0a8c45622cf858c5f3c60958e1ea385 Mon Sep 17 00:00:00 2001 From: Walpurga03 Date: Wed, 4 Jun 2025 21:54:35 +0200 Subject: [PATCH 055/278] Newsletter 353 translate into German --- .../de/newsletters/2025-05-09-newsletter.md | 94 +++++++++++++++++++ 1 file changed, 94 insertions(+) create mode 100644 _posts/de/newsletters/2025-05-09-newsletter.md diff --git a/_posts/de/newsletters/2025-05-09-newsletter.md b/_posts/de/newsletters/2025-05-09-newsletter.md new file mode 100644 index 0000000000..44c23de3d8 --- /dev/null +++ b/_posts/de/newsletters/2025-05-09-newsletter.md @@ -0,0 +1,94 @@ +--- +title: 'Bitcoin Optech Newsletter #353' +permalink: /de/newsletters/2025/05/09/ +name: 2025-05-09-newsletter-de +slug: 2025-05-09-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Dieser Newsletter beschreibt eine kürzlich entdeckte theoretische Konsensfehler-Sicherheitslücke und verweist auf einen Vorschlag, die Wiederverwendung von BIP32-Wallet-Pfaden zu vermeiden. Außerdem gibt es wie gewohnt Zusammenfassungen eines Bitcoin Core PR Review Club Meetings, Ankündigungen neuer Releases und Release-Kandidaten sowie bemerkenswerte Code-Änderungen in populärer Bitcoin-Infrastruktur-Software. + +## Nachrichten + +- **BIP30-Konsensfehler-Sicherheitslücke:** Ruben Somsen [berichtete][somsen bip30] auf der Bitcoin-Dev-Mailingliste über eine theoretische Konsensfehler-Situation, die nun auftreten könnte, nachdem Checkpoints aus Bitcoin Core entfernt wurden (siehe [Newsletter #346][news346 checkpoints]). Kurz gesagt: Die Coinbase-Transaktionen der Blöcke 91722 und 91812 sind [dupliziert][topic duplicate transactions] in den Blöcken 91880 und 91842. [BIP30][] legt fest, dass diese beiden Blöcke so behandelt werden sollen, wie es die historische Version von Bitcoin Core 2010 tat, indem die früheren Coinbase-Einträge im UTXO-Set durch die späteren Duplikate überschrieben werden. Somsen merkt jedoch an, dass eine Reorganisation eines oder beider späteren Blöcke dazu führen würde, dass der doppelte Eintrag (oder die Einträge) aus dem UTXO-Set entfernt werden, wodurch auch die früheren Einträge fehlen würden. Ein neu gestarteter Knoten, der die doppelten Transaktionen nie gesehen hat, hätte jedoch noch die früheren Transaktionen, was zu einem unterschiedlichen UTXO-Set führen könnte und im Falle einer Ausgabe zu einem Konsensfehler führen kann. + + Solange Bitcoin Core Checkpoints hatte, war das kein Problem, da diese alle vier genannten Blöcke als Teil der besten Blockchain erforderten. Jetzt ist es nur noch ein theoretisches Problem, außer im Fall, dass der Proof-of-Work-Sicherheitsmechanismus von Bitcoin versagt. Es wurden mehrere mögliche Lösungen diskutiert, z.B. das Hardcoden zusätzlicher Sonderfälle für diese beiden Ausnahmen. {% assign timestamp="0:52" %} + +- **Vermeidung von BIP32-Pfad-Wiederverwendung:** Kevin Loaec [diskutierte][loaec bip32reuse] auf Delving Bitcoin verschiedene Möglichkeiten, zu verhindern, dass derselbe [BIP32][topic bip32] Wallet-Pfad mit unterschiedlichen Wallets verwendet wird, was zu einem Verlust der Privatsphäre durch [Output Linking][topic output linking] und theoretisch auch zu einem Sicherheitsverlust (z.B. durch [Quantencomputer][topic quantum resistance]) führen könnte. Er schlug drei Ansätze vor: einen zufälligen Pfad, einen Pfad basierend auf dem Wallet-Geburtstag und einen Pfad mit einem inkrementierenden Zähler. Er empfahl den Ansatz mit dem Geburtstag. + + Außerdem empfahl er, die meisten der [BIP48][]-Pfad-Elemente wegzulassen, da durch die zunehmende Nutzung von [Descriptor][topic descriptors] Wallets, insbesondere für Multisig und komplexe Script-Wallets, diese nicht mehr nötig seien. Salvatore Ingala [antwortete][ingala bip48] jedoch, dass das _coin type_-Element im BIP48-Pfad beibehalten werden sollte, da es hilft, Schlüssel für verschiedene Kryptowährungen zu trennen, was von einigen Hardware-Signiergeräten erzwungen wird. {% assign timestamp="28:33" %} + +## Bitcoin Core PR Review Club + +*In diesem monatlichen Abschnitt fassen wir ein aktuelles [Bitcoin Core PR Review Club][]-Meeting zusammen und heben wichtige Fragen und Antworten hervor. Klicke auf eine Frage, um eine Zusammenfassung der Antwort aus dem Meeting zu sehen.* + +[Bitcoin-Wrapper-Executable hinzufügen][review club 31375] ist ein PR von [ryanofsky][gh ryanofsky], der ein neues `bitcoin`-Binary einführt, mit dem verschiedene Bitcoin Core Binaries gefunden und gestartet werden können. + +Bitcoin Core v29 wurde mit 7 Binaries ausgeliefert (z.B. `bitcoind`, `bitcoin-qt` und `bitcoin-cli`), aber diese Zahl wird in Zukunft [steigen][Bitcoin Core #30983], wenn auch [Multiprozess][multiprocess design] Binaries ausgeliefert werden. Der neue `bitcoin`-Wrapper ordnet Befehle (z.B. `gui`) dem richtigen monolithischen (`bitcoin-qt`) oder Multiprozess-(`bitcoin-gui`) Binary zu. Neben der besseren Auffindbarkeit sorgt der Wrapper auch für Forward-Kompatibilität, sodass Binaries reorganisiert werden können, ohne dass sich die Benutzeroberfläche ändert. + +Mit diesem PR kann ein Nutzer Bitcoin Core mit `bitcoin daemon` oder `bitcoin gui` starten. Das direkte Starten der Binaries `bitcoind` oder `bitcoin-qt` ist weiterhin möglich und von diesem PR nicht betroffen. + +{% include functions/details-list.md + q0="Im Issue #30983 wurden vier Packaging-Strategien aufgelistet. Welche spezifischen Nachteile des „Side‑Binaries“-Ansatzes adressiert dieser PR?" + a0="Der Side-Binaries-Ansatz, wie in diesem PR angenommen, sieht vor, die neuen Multiprozess-Binaries neben den bestehenden monolithischen Binaries zu veröffentlichen. Bei so vielen Binaries kann es für Nutzer verwirrend sein, das richtige Binary für ihren Zweck zu finden. Dieser PR nimmt viel von dieser Verwirrung, indem er einen einzigen Einstiegspunkt mit einer Übersicht der Optionen und einer Hilfeseite bietet. Ein Reviewer schlug außerdem die Ergänzung einer Fuzzy-Suche vor, um dies weiter zu erleichtern." + a0link="https://bitcoincore.reviews/31375#l-40" + q1="`GetExePath()` verwendet unter Linux nicht `readlink(\"/proc/self/exe\")`, obwohl das direkter wäre. Welche Vorteile hat die aktuelle Implementierung? Welche Randfälle könnten übersehen werden?" + a1="Es könnte andere Nicht-Windows-Plattformen geben, die kein proc-Dateisystem haben. Abgesehen davon konnten weder der Autor noch die Gäste Nachteile bei der Verwendung von procfs identifizieren." + a1link="https://bitcoincore.reviews/31375#l-71" + q2="Erkläre in `ExecCommand` den Zweck des Booleans `fallback_os_search`. Unter welchen Umständen ist es besser, das Suchen des Binaries durch das Betriebssystem auf dem `PATH` zu vermeiden?" + a2="Wenn es so aussieht, als ob das Wrapper-Executable per Pfad (z.B. \"/build/bin/bitcoin\") und nicht per Suche (z.B. \"bitcoin\") aufgerufen wurde, wird angenommen, dass der Nutzer einen lokalen Build verwendet, und `fallback_os_search` wird auf `false` gesetzt. Dieses Boolean wurde eingeführt, um zu verhindern, dass Binaries aus verschiedenen Quellen unbeabsichtigt gemischt werden. Zum Beispiel: Wenn der Nutzer `gui` nicht lokal gebaut hat, sollte `/build/bin/bitcoin gui` nicht auf das systemweit installierte `bitcoin-gui` zurückfallen. Der Autor erwägt, die `PATH`-Suche ganz zu entfernen, und Nutzerfeedback wäre hilfreich." + a2link="https://bitcoincore.reviews/31375#l-75" + q3="Der Wrapper durchsucht `${prefix}/libexec` nur, wenn er erkennt, dass er aus einem installierten `bin/`-Verzeichnis läuft. Warum wird nicht immer `libexec` durchsucht?" + a3="Der Wrapper sollte vorsichtig sein, welche Pfade er ausführt, und Standard-Layouts wie `PREFIX/{bin,libexec}` fördern, statt Packager zu ermutigen, unübliche Layouts zu erstellen oder zu unterstützen, wenn Binaries unerwartet angeordnet sind." + a3link="https://bitcoincore.reviews/31375#l-75" + q4="Der PR fügt eine Ausnahme in `security-check.py` hinzu, weil der Wrapper keine gehärteten `glibc`-Aufrufe enthält. Warum enthält er diese nicht, und würde das Hinzufügen eines trivialen `printf` zu `bitcoin.cpp` reproduzierbare Builds unter den aktuellen Regeln brechen?" + a4="Das Wrapper-Binary ist so einfach, dass es keine Aufrufe enthält, die gehärtet werden können. Falls dies in Zukunft der Fall ist, kann die Ausnahme in security-check.py entfernt werden." + a4link="https://bitcoincore.reviews/31375#l-117" +%} + +{% assign timestamp="16:38" %} + +## Veröffentlichungen und Release-Kandidaten + +_Neue Releases und Release-Kandidaten für populäre Bitcoin-Infrastrukturprojekte. Bitte erwäge, auf neue Releases zu aktualisieren oder Release-Kandidaten zu testen._ + +- [LND 0.19.0-beta.rc4][] ist ein Release-Kandidat für diesen populären LN-Knoten. Eine der wichtigsten Verbesserungen, die getestet werden sollte, ist das neue RBF-basierte Fee-Bumping für kooperative Channel-Schließungen. {% assign timestamp="45:01" %} + +## Wichtige Code- und Dokumentationsänderungen + +_Bemerkenswerte aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und [BINANAs][binana repo]._ + +- [Core Lightning #8227][] fügt Rust-basierte `lsps-client`- und `lsps-service`-Plugins hinzu, die ein Kommunikationsprotokoll zwischen LSP-Knoten und deren Clients implementieren. Sie verwenden ein JSON-RPC-Format über [BOLT8][] Peer-to-Peer-Nachrichten, wie in [BLIP50][] spezifiziert (siehe Newsletter [#335][news335 blip50]). Dies legt die Grundlage für die Implementierung eingehender Liquiditätsanfragen gemäß [BLIP51][] und [JIT-Channels][topic jit channels] gemäß [BLIP52][]. {% assign timestamp="45:18" %} + +- [Core Lightning #8162][] aktualisiert die Behandlung von von Peers initiierten, ausstehenden Channel-Öffnungen, indem sie unbegrenzt (bis zu den 100 neuesten) gespeichert werden. Zuvor wurden unbestätigte Channel-Öffnungen nach 2016 Blöcken vergessen. Zusätzlich werden geschlossene Channels nun im Speicher gehalten, damit ein Knoten auf die `channel_reestablish`-Nachricht eines Peers reagieren kann. {% assign timestamp="46:43" %} + +- [Core Lightning #8166][] verbessert den `wait`-RPC-Befehl, indem das einzelne `details`-Objekt durch subsystemspezifische Objekte ersetzt wird: `invoices`, `forwards`, `sendpays` und [`htlcs`][topic htlc]. Außerdem unterstützt der RPC-Befehl `listhtlcs` jetzt Paginierung über neue Felder `created_index` und `updated_index` sowie die Parameter `index`, `start` und `end`. {% assign timestamp="47:44" %} + +- [Core Lightning #8237][] ergänzt den RPC-Befehl `listpeerchannels` um einen `short_channel_id`-Parameter, um nur einen bestimmten Channel zurückzugeben, falls angegeben. {% assign timestamp="48:49" %} + +- [LDK #3700][] fügt dem Event `HTLCHandlingFailed` ein neues Feld `failure_reason` hinzu, das zusätzliche Informationen darüber liefert, warum das [HTLC][topic htlc] fehlgeschlagen ist und ob die Ursache lokal oder downstream lag. Das Feld `failed_next_destination` wird in `failure_type` umbenannt und die Variante `UnknownNextHop` wird zugunsten der allgemeineren Variante `InvalidForward` als veraltet markiert. {% assign timestamp="49:28" %} + +- [Rust Bitcoin #4387][] überarbeitet das Fehlerhandling von [BIP32][topic bip32], indem der bisherige einzelne `bip32::Error` durch separate Enums für Ableitung, Child-Nummer/Pfad-Parsing und Extended-Key-Parsing ersetzt wird. Außerdem wird eine neue Variante `DerivationError::MaximumDepthExceeded` für Pfade mit mehr als 256 Ebenen eingeführt. Diese API-Änderungen sind nicht abwärtskompatibel. {% assign timestamp="49:55" %} + +- [BIPs #1835][] aktualisiert [BIP48][] (siehe Newsletter [#135][news135 bip48]), um den Skripttyp-Wert 3 für [taproot][topic taproot] (P2TR)-Ableitungen in deterministischen Multisig-Wallets mit dem Präfix m/48' zu reservieren, zusätzlich zu den bestehenden Skripttypen P2SH-P2WSH (1′) und P2WSH (2′). {% assign timestamp="50:15" %} + +- [BIPs #1800][] merged [BIP54][], das den [Consensus Cleanup Soft Fork][topic consensus cleanup] spezifiziert, um eine Reihe langjähriger Schwachstellen im Bitcoin-Protokoll zu beheben. Siehe Newsletter [#348][news348 cleanup] für eine ausführliche Beschreibung dieses BIPs. {% assign timestamp="55:03" %} + +- [BOLTs #1245][] verschärft [BOLT11][], indem nicht-minimale Längen-Codierungen in Rechnungen verboten werden: Das Ablaufdatum (x), das [CLTV expiry delta][topic cltv expiry delta] für den letzten Hop (c) und die Feature-Bits (9) müssen in minimaler Länge ohne führende Nullen serialisiert werden, und Leser sollten jede Rechnung ablehnen, die führende Nullen enthält. Diese Änderung wurde durch Fuzz-Tests motiviert, die zeigten, dass beim Reserialisieren nicht-minimaler Rechnungen durch LDK die ECDSA-Signatur der Rechnung fehlschlägt. {% assign timestamp="56:37" %} + +{% include snippets/recap-ad.md when="2025-05-13 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="8227,8162,8166,8237,3700,4387,1835,1800,1245,50,51,52,30983" %} +[lnd 0.19.0-beta.rc4]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc4 +[wuille clustrade]: https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/68 +[somsen bip30]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPv7TjZTWhgzzdps3vb0YoU3EYJwThDFhNLkf4XmmdfhbORTaw@mail.gmail.com/ +[loaec bip32reuse]: https://delvingbitcoin.org/t/avoiding-xpub-derivation-reuse-across-wallets-in-a-ux-friendly-manner/1644 +[ingala bip48]: https://delvingbitcoin.org/t/avoiding-xpub-derivation-reuse-across-wallets-in-a-ux-friendly-manner/1644/3 +[news346 checkpoints]: /de/newsletters/2025/03/21/#bitcoin-core-31649 +[news335 blip50]: /en/newsletters/2025/01/03/#blips-52 +[news135 bip48]: /en/newsletters/2021/07/28/#bips-1072 +[news348 cleanup]: /de/newsletters/2025/04/04/#draft-bip-published-for-consensus-cleanup +[review club 31375]: https://bitcoincore.reviews/31375 +[gh ryanofsky]: https://github.com/ryanofsky +[multiprocess design]: https://github.com/bitcoin/bitcoin/blob/master/doc/design/multiprocess.md \ No newline at end of file From 15c356468d2c81f98050ad4b016963d144141a60 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Tue, 3 Jun 2025 20:50:41 -1000 Subject: [PATCH 056/278] Newsletters: add 357 (2025-06-06) --- .../en/newsletters/2025-06-06-newsletter.md | 169 ++++++++++++++++++ 1 file changed, 169 insertions(+) create mode 100644 _posts/en/newsletters/2025-06-06-newsletter.md diff --git a/_posts/en/newsletters/2025-06-06-newsletter.md b/_posts/en/newsletters/2025-06-06-newsletter.md new file mode 100644 index 0000000000..7ea5ba6920 --- /dev/null +++ b/_posts/en/newsletters/2025-06-06-newsletter.md @@ -0,0 +1,169 @@ +--- +title: 'Bitcoin Optech Newsletter #357' +permalink: /en/newsletters/2025/06/06/ +name: 2025-06-06-newsletter +slug: 2025-06-06-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter shares an analysis about syncing full nodes +without old witnesses. Also included are our regular sections with +descriptions of discussions about changing consensus, announcements of +new releases and release candidates, and summaries of notable changes to +popular Bitcoin infrastructure software. + +## News + +- **Syncing full nodes without witnesses:** Jose SK [posted][sk nowit] + to Delving Bitcoin a summary of an [analysis][sk nowit gist] he + performed about the security tradeoffs of allowing newly started full + nodes with a particular configuration to avoid downloading some + historic blockchain data. By default, Bitcoin Core nodes use the + `assumevalid` configuration setting that skips validation of scripts + in blocks created more than a month or two before the release of the + version of Bitcoin Core being run. Although disabled by default, many + users of Bitcoin Core also set a `prune` configuration setting that + deletes blocks some time after validating them (how long blocks are + kept depends on the size of the blocks and the specific setting selected + by the user). + + SK argues that witness data, which is only used for validating + scripts, should not be downloaded by pruned nodes for assumevalid + blocks because they won't use it for validating scripts and will + eventually delete it. Skipping witness download "can cut + bandwidth usage by over 40%," he writes. + + Ruben Somsen [argues][somsen nowit] that this changes the security + model to some degree. Although scripts aren't validated, the + downloaded data is validated against the commitment from the block + header merkle root to the coinbase transaction to the witness data. + This ensures the data was available and uncorrupted at the time the + node was initially synced. If nobody routinely validates the + existence of the data, it could conceivably be lost, as [has + happened][ripple loss] to at least one altcoin. + + The discussion was ongoing at the time of writing. + +## Changing consensus + +_A monthly section summarizing proposals and discussion about changing +Bitcoin's consensus rules._ + +- **Quantum computing report:** Clara Shikhelman [posted][shikelman + quantum] to Delving Bitcoin the summary of a [report][sm report] she + co-authored with Anthony Milton about the risks to Bitcoin users of + fast quantum computers, an overview of several pathways to [quantum + resistance][topic quantum resistance], and an analysis of tradeoffs + involved in upgrading the Bitcoin protocol. The authors find 4 to 10 + million BTC are potentially vulnerable to quantum theft, some + mitigation now is possible, Bitcoin mining is unlikely to be + threatened by quantum computing in the short or medium term, and + upgrading requires widespread agreement. + +- **Transaction weight limit with exception to prevent confiscation:** + Vojtěch Strnad [posted][strnad limit] to Delving Bitcoin to propose + the idea for a consensus change to limit the maximum weight of most + transactions in a block. The simple rule would only allow a transaction + larger than 400,000 weight units (100,000 vbytes) in a block if it was + the only transaction in that block besides the coinbase transaction. + Strnad and others described the motivation for limiting the maximum + transaction weight: + + - _Easier block template optimization:_ it's easier to find a + near-optimal solution to the [knapsack problem][] the smaller the + items are compared to the overall limit. This is partly + due to minimizing the amount of space left over at the end, with + smaller items leaving less unused space. + + - _Easier relay policy:_ the policy for relaying unconfirmed + transactions between nodes predicts what transactions will be + mined in order to avoid wasting bandwidth. Giant transactions make + accurate predictions harder as even a small change in the top feerate can cause + them to be delayed or evicted. + + - _Avoiding mining centralization:_ ensuring relaying full nodes are + able to handle almost all transactions prevents users of special + transactions from needing to pay [out-of-band fees][topic + out-of-band fees], which can lead to mining centralization. + + Gregory Sanders [noted][sanders limit] it might be reasonable to + simply soft fork a maximum weight limit without any exceptions based + on Bitcoin Core's 12 years of consistent relay policy. Gregory + Maxwell [added][maxwell limit] that transactions spending only UTXOs + created before the soft fork could be allowed an exception to prevent + confiscation, and that a [transitory soft fork][topic transitory soft + forks] would allow the restriction to expire if the + community decided not to renew it. + + Additional discussion examined the needs of parties wanting + large transactions, mainly [BitVM][topic acc] users in the near term, + and whether alternative approaches were available to them. + +- **Removing outputs from the UTXO set based on value and time:** Robin + Linus [posted][linus dust] to Delving Bitcoin to propose a soft fork + for removing low-value outputs from the UTXO set after some + time. Several variations on the idea were discussed, with the two + main alternatives being: + + - _Destroy old uneconomic funds:_ small value outputs that had not + been spent for a long time would become unspendable. + + - _Require old uneconomic funds to be spent with a proof of existence:_ + [utreexo][topic utreexo] or a similar system could be used to allow + a transaction to prove that the outputs it spends are part of the + UTXO set. Old and [uneconomical outputs][topic uneconomical outputs] would + need to include this proof, but newer and higher-value outputs would + still be stored in the UTXO set. + + Either solution would effectively limit the maximum size of the UTXO + set (assuming a minimum value and the 21 million bitcoin limit). + Several interesting technical aspects of a design were discussed, + including alternatives to utreexo proofs for this application that + could be more practical. + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [Core Lightning 25.05rc1][] is a release candidate for the next major + version of this popular LN node implementation. + +- [LND 0.19.1-beta.rc1][] is a release candidate for a maintenance + version of this popular LN node implementation. + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [Bitcoin Core #32582][] log: Additional compact block logging + +- [Bitcoin Core #31375][] multiprocess: Add bitcoin wrapper executable + +- [BIPs #1483][] BIP 77: Async Payjoin + +{% include snippets/recap-ad.md when="2025-06-10 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32582,31375,1483" %} +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[ripple loss]: https://x.com/JoelKatz/status/1919233214750892305 +[sk nowit]: https://delvingbitcoin.org/t/witnessless-sync-for-pruned-nodes/1742/ +[sk nowit gist]: https://gist.github.com/JoseSK999/df0a2a014c7d9b626df1e2b19ccc7fb1 +[somsen nowit]: https://gist.github.com/JoseSK999/df0a2a014c7d9b626df1e2b19ccc7fb1?permalink_comment_id=5597316#gistcomment-5597316 +[shikelman quantum]: https://delvingbitcoin.org/t/bitcoin-and-quantum-computing/1730/ +[sm report]: https://chaincode.com/bitcoin-post-quantum.pdf +[strnad limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/ +[knapsack problem]: https://en.wikipedia.org/wiki/Knapsack_problem +[sanders limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/2 +[maxwell limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/4 +[linus dust]: https://delvingbitcoin.org/t/dust-expiry-clean-the-utxo-set-from-spam/1707/ +[lnd 0.19.1-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.1-beta.rc1 From 14255e0c326501076c83b085c0e332640807d9bc Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 5 Jun 2025 01:47:42 +0000 Subject: [PATCH 057/278] News357: add merge summaries --- _includes/references.md | 1 + .../en/newsletters/2025-06-06-newsletter.md | 36 ++++++++++++++++--- 2 files changed, 32 insertions(+), 5 deletions(-) diff --git a/_includes/references.md b/_includes/references.md index f79aae5413..ae1b3a3069 100644 --- a/_includes/references.md +++ b/_includes/references.md @@ -107,6 +107,7 @@ for details --> {% endcomment %} [BIP71]: https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki [BIP72]: https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki [BIP75]: https://github.com/bitcoin/bips/blob/master/bip-0075.mediawiki +[BIP77]: https://github.com/bitcoin/bips/blob/master/bip-0077.md [BIP78]: https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki [BIP79]: https://github.com/bitcoin/bips/blob/master/bip-0079.mediawiki [BIP84]: https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki diff --git a/_posts/en/newsletters/2025-06-06-newsletter.md b/_posts/en/newsletters/2025-06-06-newsletter.md index 7ea5ba6920..cfb60b524c 100644 --- a/_posts/en/newsletters/2025-06-06-newsletter.md +++ b/_posts/en/newsletters/2025-06-06-newsletter.md @@ -145,11 +145,32 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Bitcoin Core #32582][] log: Additional compact block logging - -- [Bitcoin Core #31375][] multiprocess: Add bitcoin wrapper executable - -- [BIPs #1483][] BIP 77: Async Payjoin +- [Bitcoin Core #32582][] adds new logging to measure the performance of + [compact block reconstruction][topic compact block relay] by tracking the + total size of transactions that a node requests from its peers + (`getblocktxn`), the number and total size of transactions that a node sends + to its peers (`blocktxn`), and adding a timestamp at the start of + `PartiallyDownloadedBlock::InitData()` to track how long the mempool lookup + step alone takes (in both high and low-bandwidth modes). See Newsletter + [#315][news315 compact] for a previous statistics report on compact block + reconstruction. + +- [Bitcoin Core #31375][] adds a new `bitcoin -m` CLI tool that wraps and + executes the [multiprocess][multiprocess project] binaries `bitcoin node` + (`bitcoind`), `bitcoin gui` (`bitcoinqt`), `bitcoin rpc` (`bitcoin-cli + -named`). Currently, these function in the same way as the monolithic + binaries, except they support the `-ipcbind` option (see Newsletter + [#320][news320 ipc]), but future improvements will enable a node runner to + start and stop components independently on different machines and + environments. See [Newsletter #353][news353 pr review] for a Bitcoin Core PR + Review Club covering this PR. + +- [BIPs #1483][] merges [BIP77][] which proposes [payjoin v2][topic payjoin], an + asynchronous serverless variant in which the sender and receiver hand their + encrypted PSBTs to a payjoin directory server that only stores and forwards + messages. As the directory cannot read or alter the payloads, neither wallet + needs to host a public server or be online at the same time. See Newsletter + [#264][news264 payjoin] for additional context on payjoin v2. {% include snippets/recap-ad.md when="2025-06-10 16:30" %} {% include references.md %} @@ -167,3 +188,8 @@ repo], and [BINANAs][binana repo]._ [maxwell limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/4 [linus dust]: https://delvingbitcoin.org/t/dust-expiry-clean-the-utxo-set-from-spam/1707/ [lnd 0.19.1-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.1-beta.rc1 +[news315 compact]: /en/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction +[multiprocess project]: https://github.com/ryanofsky/bitcoin/blob/pr/ipc/doc/design/multiprocess.md +[news320 ipc]: /en/newsletters/2024/09/13/#bitcoin-core-30509 +[news264 payjoin]: /en/newsletters/2023/08/16/#serverless-payjoin +[news353 pr review]: /en/newsletters/2025/05/09/#bitcoin-core-pr-review-club From 0614368bcc95e67599d7fef74ae0552eaf20c707 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Fri, 6 Jun 2025 07:11:02 -0500 Subject: [PATCH 058/278] News357: add topics --- _topics/en/acc.md | 3 +++ _topics/en/compact-block-relay.md | 3 +++ _topics/en/out-of-band-fees.md | 3 +++ _topics/en/payjoin.md | 4 ++++ _topics/en/quantum-resistance.md | 3 +++ _topics/en/segregated-witness.md | 3 +++ _topics/en/transitory-soft-forks.md | 3 +++ _topics/en/uneconomical-outputs.md | 3 +++ _topics/en/utreexo.md | 3 +++ 9 files changed, 28 insertions(+) diff --git a/_topics/en/acc.md b/_topics/en/acc.md index 4f2cc3c37d..32c11302f0 100644 --- a/_topics/en/acc.md +++ b/_topics/en/acc.md @@ -64,6 +64,9 @@ optech_mentions: - title: "Description of benefits to BitVM from `OP_CTV` and `OP_CSFS`" url: /en/newsletters/2025/05/16/#description-of-benefits-to-bitvm-from-op-ctv-and-op-csfs + - title: Discussion about transaction weight limit in response to large BitVM transactions + url: /en/newsletters/2025/06/06/#transaction-weight-limit-with-exception-to-prevent-confiscation + ## Optional. Same format as "primary_sources" above see_also: - title: "Merklize All The Things (MATT)" diff --git a/_topics/en/compact-block-relay.md b/_topics/en/compact-block-relay.md index fe725275d6..4685d06ff1 100644 --- a/_topics/en/compact-block-relay.md +++ b/_topics/en/compact-block-relay.md @@ -66,6 +66,9 @@ optech_mentions: - title: "Renewed discussion about compact block reconstruction success rates" url: /en/newsletters/2025/01/31/#updated-stats-on-compact-block-reconstruction + - title: "Bitcoin Core #32582 adds logging to measure performance of compact block reconstruction" + url: /en/newsletters/2025/06/06/#bitcoin-core-32582 + ## Optional. Same format as "primary_sources" above # see_also: # - title: diff --git a/_topics/en/out-of-band-fees.md b/_topics/en/out-of-band-fees.md index 8dda4a30c3..c5d4cec514 100644 --- a/_topics/en/out-of-band-fees.md +++ b/_topics/en/out-of-band-fees.md @@ -40,6 +40,9 @@ optech_mentions: - title: "Frequent use of exogenous fees may risk mining decentralization due to out-of-band fees" url: /en/newsletters/2024/01/10/#frequent-use-of-exogenous-fees-may-risk-mining-decentralization + - title: Soft fork to limit transaction weight proposed to prevent a cause of out-of-band fees + url: /en/newsletters/2025/06/06/#transaction-weight-limit-with-exception-to-prevent-confiscation + ## Optional. Same format as "primary_sources" above see_also: - title: Fee sniping diff --git a/_topics/en/payjoin.md b/_topics/en/payjoin.md index 41563eadf0..b540c95000 100644 --- a/_topics/en/payjoin.md +++ b/_topics/en/payjoin.md @@ -22,6 +22,7 @@ excerpt: > ## "[title](link)" primary_sources: - title: BIP78 + - title: BIP77 ## Optional. Each entry requires "title", "url", and "date". May also use "feature: ## true" to bold entry @@ -113,6 +114,9 @@ optech_mentions: - title: "Cake Wallet adds payjoin v2 support" url: /en/newsletters/2025/05/23/#cake-wallet-added-payjoin-v2-support + - title: "BIPs #1483 merges BIP77 which proposes payjoin v2, an asynchronous serverless variant" + url: /en/newsletters/2025/06/06/#bips-1483 + ## Optional. Same format as "primary_sources" above see_also: - title: BIP79 diff --git a/_topics/en/quantum-resistance.md b/_topics/en/quantum-resistance.md index cd8de83cdb..23195af724 100644 --- a/_topics/en/quantum-resistance.md +++ b/_topics/en/quantum-resistance.md @@ -73,6 +73,9 @@ optech_mentions: - title: "Draft BIP for destroying quantum-insecure bitcoins" url: /en/newsletters/2025/04/04/#draft-bip-for-destroying-quantum-insecure-bitcoins + - title: Report about quantum computing and Bitcoin + url: /en/newsletters/2025/06/06/#quantum-computing-report + ## Optional. Same format as "primary_sources" above see_also: - title: Taproot diff --git a/_topics/en/segregated-witness.md b/_topics/en/segregated-witness.md index b907401735..93e133e8c2 100644 --- a/_topics/en/segregated-witness.md +++ b/_topics/en/segregated-witness.md @@ -59,6 +59,9 @@ optech_mentions: - title: "Bitcoin Core #21009 removes logic needed to upgrade a pre-segwit node to segwit" url: /en/newsletters/2021/05/05/#bitcoin-core-21009 + - title: Analysis of syncing full nodes without downloading old witnesses + url: /en/newsletters/2025/06/06/#syncing-full-nodes-without-witnesses + ## Optional. Same format as "primary_sources" above see_also: - title: Taproot diff --git a/_topics/en/transitory-soft-forks.md b/_topics/en/transitory-soft-forks.md index e39c8b48d4..2eb4e5c05f 100644 --- a/_topics/en/transitory-soft-forks.md +++ b/_topics/en/transitory-soft-forks.md @@ -35,6 +35,9 @@ optech_mentions: - title: Transitory soft fork for disabling EC operations due to perceived quantum computer risks url: /en/newsletters/2025/01/03/#quantum-computer-upgrade-path + - title: Transitory soft fork suggested for transaction weight limit + url: /en/newsletters/2025/06/06/#transaction-weight-limit-with-exception-to-prevent-confiscation + ## Optional. Same format as "primary_sources" above # see_also: # - title: diff --git a/_topics/en/uneconomical-outputs.md b/_topics/en/uneconomical-outputs.md index 568082b66c..54fdef51a4 100644 --- a/_topics/en/uneconomical-outputs.md +++ b/_topics/en/uneconomical-outputs.md @@ -72,6 +72,9 @@ optech_mentions: - title: "Bitcoin Core PR Review Club about exempting ephemeral anchors from the dust limit" url: /en/newsletters/2024/11/08/#bitcoin-core-pr-review-club + - title: "Proposal for removing uneconomical outputs from the stored UTXO set" + url: /en/newsletters/2025/06/06/#removing-outputs-from-the-utxo-set-based-on-value-and-time + ## Optional. Same format as "primary_sources" above see_also: - title: Dust attacks (output linking) diff --git a/_topics/en/utreexo.md b/_topics/en/utreexo.md index 84b5d31192..d29e12acc3 100644 --- a/_topics/en/utreexo.md +++ b/_topics/en/utreexo.md @@ -52,6 +52,9 @@ optech_mentions: - title: "SwiftSync faster sync allows parallel block validation, similar to Utreexo" url: /en/newsletters/2025/04/11/#swiftsync-speedup-for-initial-block-download + - title: Discussion of alternatives to Utreexo for proving UTXO existence without a UTXO set + url: /en/newsletters/2025/06/06/#removing-outputs-from-the-utxo-set-based-on-value-and-time + ## Optional. Same format as "primary_sources" above see_also: - title: Uneconomical outputs From d57f9ad6cf84160afb39c96586604626975a9d21 Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 6 Jun 2025 21:33:20 +0900 Subject: [PATCH 059/278] Newsletter-357:Translate into Japanese --- .../ja/newsletters/2025-06-06-newsletter.md | 162 ++++++++++++++++++ 1 file changed, 162 insertions(+) create mode 100644 _posts/ja/newsletters/2025-06-06-newsletter.md diff --git a/_posts/ja/newsletters/2025-06-06-newsletter.md b/_posts/ja/newsletters/2025-06-06-newsletter.md new file mode 100644 index 0000000000..7d03dc588c --- /dev/null +++ b/_posts/ja/newsletters/2025-06-06-newsletter.md @@ -0,0 +1,162 @@ +--- +title: 'Bitcoin Optech Newsletter #357' +permalink: /ja/newsletters/2025/06/06/ +name: 2025-06-06-newsletter-ja +slug: 2025-06-06-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、古いwitnessなしでフルノードを同期させる方法の分析を共有しています。 +また、コンセンサスの変更に関する議論や、新しいリリースとリリース候補の発表、 +人気のBitcoinインフラストラクチャソフトウェアの注目すべき更新など、 +恒例のセクションも含まれています。 + +## ニュース + +- **witnessなしのフルノードの同期:** Jose SKは、 + 特定の設定で新しく起動したフルノードが、過去のブロックチェーンデータのダウンロードを回避した場合の + セキュリティ上のトレードオフについての[分析][sk nowit gist]の要約をDelving Bitcoinに[投稿しました][sk nowit]。 + Bitcoin Coreはデフォルトで、実行中のBitcoin Coreのバージョンのリリースより1〜2ヶ月以上前に作成されたブロックについて、 + ブロック内のスクリプトの検証をスキップする`assumevalid`設定を使用しています。 + またデフォルトでは無効になっていますが、多くのBitcoin Coreユーザーは、 + ブロックの検証後しばらくしてからそのブロックを削除する`prune`設定を使用しています（ + ブロックの生存期間はブロックのサイズとユーザーが選択した設定によって異なります）。 + + SKは、スクリプトの検証に使用されず最終的に削除されるため、 + プルーニングノードはassumevalidの対象のブロックについて、 + スクリプトの検証にだけ使われるwitnessデータをダウンロードしなくていいと主張しています。 + witnessのダウンロードをスキップすることで、「帯域幅の使用量を40%以上削減できる」 + と書いています。 + + Ruben Somsenは、これは少なくともセキュリティモデルに何ら化の変化をもたらすと[主張しています][somsen nowit]。 + スクリプトは検証されませんが、ダウンロードされたデータはブロックヘッダーのマークルルートから + コインベーストランザクション、そしてwitnessデータを含むコミットメントに対して検証されます。 + これにより、ノードが最初に同期された時点でデータが利用可能であり、 + 破損していないことが保証されます。もし誰もデータの存在を定期的に検証しなければ、 + 少なくとも１つのアルトコインで[発生したように][ripple loss]、データが失われる可能性があります。 + + 記事の執筆時点で、この議論は継続中でした。 + +## コンセンサスの変更 + +_Bitcoinのコンセンサスルールの変更に関する提案と議論をまとめた月次セクション_ + +- **量子コンピューターに関するレポート:** + Clara Shikhelmanは、高速な量子コンピューターがBitcoinユーザーにもたらすリスク、 + [量子耐性][topic quantum resistance]への複数のアプローチの概要、 + Bitcoinプロトコルのアップグレードに伴うトレードオフの分析について、 + Anthony Miltonと共同執筆した[レポート][sm report]をDelving Bitcoinに[投稿しました][shikelman quantum]。 + 著者らは、400万BTCから1000万BTCが量子コンピューターによる盗難の潜在的なリスクにさらされていること、 + 現在ある程度の緩和策があること、Bitcoinマイニングが短期的または中期的に量子コンピューターの脅威にさらされる可能性は低いこと、 + そしてアップグレードには幅広い合意が必要であることを明らかにしています。 + +- **没収防止のための例外付きのトランザクションweight制限:** + Vojtěch Strnadは、ブロック内のほとんどのトランザクションの最大weightを制限するコンセンサス変更のアイディアを + Delving Bitcoinに[投稿しました][strnad limit]。このシンプルなルールは、 + ブロック内で400,000 weight単位（100,000 vbyte）を超えるトランザクションは、 + そのブロック内でコインベーストランザクションを除いて1つのみ許可するというものです。 + Strnadらは、トランザクションの最大weightを制限する理由を次のように述べています: + + - _ブロックテンプレートの最適化が容易:_ + [ナップサック問題][knapsack problem]に対する最適解に近い解を見つけるのは、 + 全体の制限と比較してアイテムが小さいほど容易です。これはアイテムが小さいほど未使用のスペースが少なくなり、 + 最終的に残るスペースが最小限に抑えられるためです。 + + - _リレーポリシーの簡素化:_ ノード間の未承認トランザクションのリレーポリシーは、 + 帯域幅の浪費を避けるために、どのトランザクションがマイニングされるかを予測します。 + 巨大なトランザクションは、最上位の手数料率のわずかな変化でも遅延や排除につながる可能性があるため、 + 正確な予測を難しくします。 + + - _マイニングの集中化の回避:_ リレーフルノードがほぼすべてのトランザクションを処理できるようにすることで、 + 特別なトランザクションのユーザーが[帯域外手数料][topic out-of-band fees]を支払う必要がなくなり、 + マイニングの集中化につながるリスクを回避できます。 + + Gregory Sandersは、Bitcoin Coreの12年間にわたる一貫したリレーポリシーに基づき、 + 例外なく最大weight制限をソフトフォークするのが合理的かもしれないと[指摘しました][sanders limit]。 + Gregory Maxwellは、ソフトフォーク前に作成されたUTXOのみを使用するトランザクションについては、 + 没収を防ぐための例外を認めることができ、また[一時的なソフトフォーク][topic transitory soft forks]とすることで、 + コミュニティが更新を望まなければ制限を失効させられると[付け加え][maxwell limit]ました。 + + 追加の議論では、大規模なトランザクションを求める当事者（主に短期的には[BitVM][topic acc]のユーザーなど）のニーズと、 + 彼らが利用可能な代替アプローチがあるかどうかが検討されました。 + +- **金額と時間に基づいてUTXOセットからアウトプットを削除する:** + Robin Linusは、一定期間後に金額の小さいアウトプットをUTXOセットから削除するためのソフトフォークの提案を + Delving Bitcoinに[投稿しました][linus dust]。このアイディアではいくつかのバリエーションが議論され、 + 主に以下の2つの代替案が挙げられました: + + - _古くて経済的ではない資金を破棄する:_ 長期間使われていない少額のアウトプットは使用できなくなります。 + + - _古くて経済的ではない資金の使用には存在証明を求める:_ + [utreexo][topic utreexo]や同様のシステムを使用することで、 + トランザクションは使用するアウトプットがUTXOセットの一部であることを証明できます。 + 古くて[経済合理性のないアウトプット][topic uneconomical outputs]は、 + この証明を含める必要があり、新しくて多額のアウトプットはUTXOセットに引き続き保持されます。 + + どちらの解決策も、UTXOセットの最大サイズを実質的に制限します（最小値と2100万ビットコインの制限を想定）。 + これを適用するために、より実用的になる可能性のあるutreexo証明の代替案など、 + 設計の興味深い技術的側面がいくつか議論されました。 + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [Core Lightning 25.05rc1][]は、この人気のLNノード実装の次期メジャーバージョンのリリース候補です。 + +- [LND 0.19.1-beta.rc1][]は、この人気のLNノード実装のメンテナンスバージョンのリリース候補です。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Bitcoin Core #32582][]では、 + [コンパクトブロックの再構築][topic compact block relay]のパフォーマンスを測定するための新しいログが追加されました。 + これは、ノードがピアに要求するトランザクション（`getblocktxn`）の合計サイズ、 + ノードがピアに送信する（`blocktxn`）トランザクションの数と合計サイズを追跡し、 + `PartiallyDownloadedBlock::InitData()`の開始時にタイムスタンプを追加することで、 + mempoolのルックアップ手順のみにかかる時間（高帯域幅モードと低帯域幅モードの両方）を追跡します。 + コンパクトブロックの再構築に関する以前の統計レポートについては、ニュースレター[#315][news315 compact]をご覧ください。 + +- [Bitcoin Core #31375][]では、[マルチプロセス][multiprocess project]バイナリである + `bitcoin node`（`bitcoind`）、`bitcoin gui`（bitcoinqt）、`bitcoin rpc`（`bitcoin-cli + -named`）をラップして実行する新しい`bitcoin -m` CLIツールが追加されました。 + 現在、これらはモノリシックバイナリと同様に機能しますが、 + `-ipcbind`オプション（ニュースレター[#320][news320 ipc]参照）をサポートしています。 + ただし、将来の改良により、ノードランナーが異なるマシンや環境でコンポーネントを独立して起動・停止できるようになります。 + このPRを取り上げているBitcoin Core PR Review Clubについては、ニュースレター[#353][news353 pr review]をご覧ください。 + +- [BIPs #1483][]は、送信者と受信者が暗号化されたPSBTをメッセージの保存と転送のみを行う + payjoinディレクトリサーバーに渡す、非同期サーバーレス版である[payjoin v2][topic payjoin]を提案する + [BIP77][]をマージしました。ディレクトリサーバーは、ペイロードの読み取りや変更ができないため、 + どちらのウォレットも公開サーバーをホストしたり、同時にオンラインにしたりする必要はありません。 + payjoin v2の詳細については、ニュースレター[#264][news264 payjoin]をご覧ください。 + +{% include snippets/recap-ad.md when="2025-06-10 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32582,31375,1483" %} +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[ripple loss]: https://x.com/JoelKatz/status/1919233214750892305 +[sk nowit]: https://delvingbitcoin.org/t/witnessless-sync-for-pruned-nodes/1742/ +[sk nowit gist]: https://gist.github.com/JoseSK999/df0a2a014c7d9b626df1e2b19ccc7fb1 +[somsen nowit]: https://gist.github.com/JoseSK999/df0a2a014c7d9b626df1e2b19ccc7fb1?permalink_comment_id=5597316#gistcomment-5597316 +[shikelman quantum]: https://delvingbitcoin.org/t/bitcoin-and-quantum-computing/1730/ +[sm report]: https://chaincode.com/bitcoin-post-quantum.pdf +[strnad limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/ +[knapsack problem]: https://ja.wikipedia.org/wiki/ナップサック問題 +[sanders limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/2 +[maxwell limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/4 +[linus dust]: https://delvingbitcoin.org/t/dust-expiry-clean-the-utxo-set-from-spam/1707/ +[lnd 0.19.1-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.1-beta.rc1 +[news315 compact]: /ja/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction +[multiprocess project]: https://github.com/ryanofsky/bitcoin/blob/pr/ipc/doc/design/multiprocess.md +[news320 ipc]: /ja/newsletters/2024/09/13/#bitcoin-core-30509 +[news264 payjoin]: /ja/newsletters/2023/08/16/#payjoin +[news353 pr review]: /ja/newsletters/2025/05/09/#bitcoin-core-pr-review-club \ No newline at end of file From 3a1ffb341f1ad7c63cfc759ff8fdaad57b808205 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Fri, 6 Jun 2025 16:06:19 +0200 Subject: [PATCH 060/278] Update _posts/de/newsletters/2025-04-25-newsletter.md Co-authored-by: garfiel-d --- _posts/de/newsletters/2025-04-25-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/de/newsletters/2025-04-25-newsletter.md b/_posts/de/newsletters/2025-04-25-newsletter.md index 29abcf4340..66a32efdd3 100644 --- a/_posts/de/newsletters/2025-04-25-newsletter.md +++ b/_posts/de/newsletters/2025-04-25-newsletter.md @@ -13,7 +13,7 @@ Der Newsletter dieser Woche kündigt ein neues Aggregat-Signaturprotokoll an, da - **Interaktive Aggregat-Signaturen kompatibel mit secp256k1:** Jonas Nick, Tim Ruffing und Yannick Seurin [veröffentlichten][nrs dahlias] in der Bitcoin-Dev-Mailingliste einen Hinweis auf ein [Paper][dahlias paper], das sie über die Erstellung von 64-Byte-Aggregat-Signaturen geschrieben haben, die mit den bereits in Bitcoin verwendeten kryptographischen Primitiven kompatibel sind. Aggregat-Signaturen sind die kryptographische Voraussetzung für [Cross-Input Signature Aggregation][topic cisa] (CISA), ein vorgeschlagenes Feature für Bitcoin, das die Größe von Transaktionen mit mehreren Inputs reduzieren könnte. Dadurch würden die Kosten vieler verschiedener Arten von Ausgaben sinken – einschließlich datenschutzfreundlicher Ausgaben durch [Coinjoins][topic coinjoin] und [Payjoins][topic payjoin]. - Zusätzlich zu einem Aggregat-Signaturschema wie dem von den Autoren vorgeschlagenen DahLIAS-Schema würde die Unterstützung von CISA in Bitcoin eine Konsensänderung erfordern. Mögliche Wechselwirkungen zwischen Signaturaggregation und anderen vorgeschlagenen Konsensänderungen könnten weitere Untersuchungen erfordern. + Zusätzlich zu einem Aggregat-Signaturschema, wie dem von den Autoren vorgeschlagenen DahLIAS-Schema, würde die Unterstützung von CISA in Bitcoin eine Konsensänderung erfordern. Mögliche Wechselwirkungen zwischen Signaturaggregation und anderen vorgeschlagenen Konsensänderungen könnten weitere Untersuchungen erfordern. - **Standardisiertes Backup für Wallet-Deskriptoren:** Salvatore Ingala [veröffentlichte][ingala backdes] auf Delving Bitcoin eine Zusammenfassung verschiedener Abwägungen beim Backup von Wallet-[Deskriptoren][topic descriptors] und ein vorgeschlagenes Schema, das für viele verschiedene Wallet-Typen nützlich sein sollte, einschließlich solcher mit komplexen Skripten. Sein Schema verschlüsselt Deskriptoren mit einem deterministisch generierten 32-Byte-Geheimnis. Für jeden öffentlichen Schlüssel (oder Extended Public Key) im Deskriptor wird eine Kopie des Geheimnisses mit einer Variante des öffentlichen Schlüssels XOR-verknüpft, wodurch _n_ 32-Byte-Geheimnisverschlüsselungen für _n_ öffentliche Schlüssel entstehen. Jeder, der einen der im Deskriptor verwendeten öffentlichen Schlüssel kennt, kann diesen mit der 32-Byte-Geheimnisverschlüsselung XORen, um das 32-Byte-Geheimnis zu erhalten, das den Deskriptor entschlüsseln kann. Dieses einfache und effiziente Schema ermöglicht es, viele verschlüsselte Kopien eines Deskriptors auf verschiedenen Medien und an verschiedenen Orten zu speichern und dann mit dem [BIP32-Wallet-Seed][topic bip32] den eigenen xpub zu generieren, mit dem sich der Deskriptor im Notfall wiederherstellen lässt. From 0dc786917dc7c1eae914931ff39a09699ae99880 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Fri, 6 Jun 2025 16:06:27 +0200 Subject: [PATCH 061/278] Update _posts/de/newsletters/2025-04-25-newsletter.md Co-authored-by: garfiel-d --- _posts/de/newsletters/2025-04-25-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/de/newsletters/2025-04-25-newsletter.md b/_posts/de/newsletters/2025-04-25-newsletter.md index 66a32efdd3..77b83b2a74 100644 --- a/_posts/de/newsletters/2025-04-25-newsletter.md +++ b/_posts/de/newsletters/2025-04-25-newsletter.md @@ -61,7 +61,7 @@ _Neue Veröffentlichungen und Release-Kandidaten für beliebte Bitcoin-Infrastru _Bedeutende kürzliche Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und [BINANAs][binana repo]._ -- [Bitcoin Core #31247][] fügt Unterstützung für das Serialisieren und Parsen von [MuSig2][topic musig]-[PSBT][topic psbt]-Feldern gemäß [BIP373][] hinzu, damit Wallets [MuSig2][topic musig]-Inputs signieren und ausgeben können. Auf der Input-Seite besteht dies aus einem Feld mit den Teilnehmer-Pubkeys, einem separaten Public-Nonce-Feld und einem separaten Partial-Signature-Feld für jeden Signer. Auf der Output-Seite ist es ein einzelnes Feld mit den Teilnehmer-Pubkeys für das neue UTXO. +- [Bitcoin Core #31247][] fügt Unterstützung für das Serialisieren und Parsen von [MuSig2][topic musig]-[PSBT][topic psbt]-Feldern gemäß [BIP373][] hinzu, damit Wallets [MuSig2][topic musig]-Inputs signieren und ausgeben können. Auf der Input-Seite besteht diese aus einem Feld mit den Teilnehmer-Pubkeys, einem separaten Public-Nonce-Feld und einem separaten Partial-Signature-Feld für jeden Signer. Auf der Output-Seite ist es ein einzelnes Feld mit den Teilnehmer-Pubkeys für das neue UTXO. - [LDK #3601][] fügt ein neues `LocalHTLCFailureReason`-Enum hinzu, das jeden Standard-[BOLT4][]-Fehlercode abbildet, zusammen mit einigen Varianten, die dem Nutzer zusätzliche Informationen liefern, die zuvor aus Datenschutzgründen entfernt wurden. From c1fafe935018afd39bf73c0d6c4fea986fc13375 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Fri, 6 Jun 2025 16:54:07 +0200 Subject: [PATCH 062/278] Update _posts/de/newsletters/2025-05-02-newsletter.md Co-authored-by: garfiel-d --- _posts/de/newsletters/2025-05-02-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/de/newsletters/2025-05-02-newsletter.md b/_posts/de/newsletters/2025-05-02-newsletter.md index bc4ff5c60d..7a27ca855f 100644 --- a/_posts/de/newsletters/2025-05-02-newsletter.md +++ b/_posts/de/newsletters/2025-05-02-newsletter.md @@ -7,7 +7,7 @@ type: newsletter layout: newsletter lang: de --- -Der Newsletter dieser Woche verweist auf Vergleiche verschiedener Cluster-Linearisationstechniken und fasst kurz die Diskussion über die Erhöhung oder Abschaffung des `OP_RETURN`-Größenlimits in Bitcoin Core zusammen. Ebenfalls enthalten sind unsere regulären Abschnitte mit Ankündigungen neuer Releases und Release-Kandidaten sowie Zusammenfassungen wichtiger Änderungen an populärer Bitcoin-Infrastruktur. +Der Newsletter dieser Woche verweist auf Vergleiche verschiedener Cluster-Linearisierungstechniken und fasst kurz die Diskussion über die Erhöhung oder Abschaffung des `OP_RETURN`-Größenlimits in Bitcoin Core zusammen. Ebenfalls enthalten sind unsere regulären Abschnitte mit Ankündigungen neuer Releases und Release-Kandidaten sowie Zusammenfassungen wichtiger Änderungen an populärer Bitcoin-Infrastruktur. ## Nachrichten From dfb68290880c4d787190564534be742bacab8ec9 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Fri, 6 Jun 2025 16:54:17 +0200 Subject: [PATCH 063/278] Update _posts/de/newsletters/2025-05-02-newsletter.md Co-authored-by: garfiel-d --- _posts/de/newsletters/2025-05-02-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/de/newsletters/2025-05-02-newsletter.md b/_posts/de/newsletters/2025-05-02-newsletter.md index 7a27ca855f..7f0ee6dd41 100644 --- a/_posts/de/newsletters/2025-05-02-newsletter.md +++ b/_posts/de/newsletters/2025-05-02-newsletter.md @@ -12,7 +12,7 @@ Der Newsletter dieser Woche verweist auf Vergleiche verschiedener Cluster-Linear ## Nachrichten - **Vergleich von Cluster-Linearisationstechniken:** - Pieter Wuille [veröffentlichte][wuille clustrade] auf Delving Bitcoin einige grundlegende Abwägungen zwischen drei verschiedenen Cluster-Linearisationstechniken und ergänzte dies durch [Benchmarks][wuille clusbench] der jeweiligen Implementierungen. Mehrere andere Entwickler diskutierten die Ergebnisse und stellten Rückfragen, auf die Wuille antwortete. + Pieter Wuille [veröffentlichte][wuille clustrade] auf Delving Bitcoin einige grundlegende Abwägungen zwischen drei verschiedenen Cluster-Linearisierungstechniken und ergänzte dies durch [Benchmarks][wuille clusbench] der jeweiligen Implementierungen. Mehrere andere Entwickler diskutierten die Ergebnisse und stellten Rückfragen, auf die Wuille antwortete. - **Erhöhung oder Abschaffung des `OP_RETURN`-Größenlimits in Bitcoin Core:** In einem Thread auf der Bitcoin-Dev-Mailingliste diskutierten mehrere Entwickler, das Standardlimit für `OP_RETURN`-Data-Carrier-Outputs in Bitcoin Core zu ändern oder ganz abzuschaffen. Eine nachfolgende [Pull-Request-Diskussion][bitcoin core #32359] brachte weitere Argumente. Anstatt die gesamte umfangreiche Diskussion zusammenzufassen, stellen wir das aus unserer Sicht überzeugendste Argument für und gegen die Änderung vor. From 513d36b4cb7815cff05030e7e80043540313cd65 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Fri, 6 Jun 2025 16:54:27 +0200 Subject: [PATCH 064/278] Update _posts/de/newsletters/2025-05-02-newsletter.md Co-authored-by: garfiel-d --- _posts/de/newsletters/2025-05-02-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/de/newsletters/2025-05-02-newsletter.md b/_posts/de/newsletters/2025-05-02-newsletter.md index 7f0ee6dd41..b99dac191a 100644 --- a/_posts/de/newsletters/2025-05-02-newsletter.md +++ b/_posts/de/newsletters/2025-05-02-newsletter.md @@ -18,7 +18,7 @@ Der Newsletter dieser Woche verweist auf Vergleiche verschiedener Cluster-Linear In einem Thread auf der Bitcoin-Dev-Mailingliste diskutierten mehrere Entwickler, das Standardlimit für `OP_RETURN`-Data-Carrier-Outputs in Bitcoin Core zu ändern oder ganz abzuschaffen. Eine nachfolgende [Pull-Request-Diskussion][bitcoin core #32359] brachte weitere Argumente. Anstatt die gesamte umfangreiche Diskussion zusammenzufassen, stellen wir das aus unserer Sicht überzeugendste Argument für und gegen die Änderung vor. - *Für die Erhöhung (oder Abschaffung) des Limits:* - Pieter Wuille [argumentierte][wuille opr], dass die Standardness-Policy von Transaktionen kaum verhindern kann, dass gut finanzierte Organisationen Daten tragende Transaktionen direkt an Miner senden und so in Blöcke bringen. Außerdem seien Blöcke ohnehin meist voll, egal ob sie Daten enthalten oder nicht, sodass sich die Gesamtmenge der zu speichernden Daten für einen Knoten kaum ändert. + Pieter Wuille [argumentierte][wuille opr], dass die Standardness-Policy von Transaktionen kaum verhindern kann, dass gut finanzierte Organisationen datentragende Transaktionen direkt an Miner senden und so in Blöcke bringen. Außerdem seien Blöcke ohnehin meist voll, egal ob sie Daten enthalten oder nicht, sodass sich die Gesamtmenge der zu speichernden Daten für einen Knoten kaum ändert. - *Gegen die Erhöhung des Limits:* Jason Hughes [argumentierte][hughes opr], dass eine Erhöhung des Limits es einfacher machen würde, beliebige Daten auf Rechnern zu speichern, die Full Knoten betreiben – darunter auch potenziell anstößige oder in vielen Ländern illegale Inhalte. Selbst wenn der Knoten die Daten auf der Festplatte verschlüsselt (siehe [Newsletter #316][news316 blockxor]), könnte das Speichern und Abrufen solcher Daten über Bitcoin Core RPCs für viele Nutzer problematisch sein. From f436e9831f3f4adff72d36d78a89ba17dcd2e832 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Fri, 6 Jun 2025 16:54:40 +0200 Subject: [PATCH 065/278] Update _posts/de/newsletters/2025-05-02-newsletter.md Co-authored-by: garfiel-d --- _posts/de/newsletters/2025-05-02-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/de/newsletters/2025-05-02-newsletter.md b/_posts/de/newsletters/2025-05-02-newsletter.md index b99dac191a..23ae5740d6 100644 --- a/_posts/de/newsletters/2025-05-02-newsletter.md +++ b/_posts/de/newsletters/2025-05-02-newsletter.md @@ -11,7 +11,7 @@ Der Newsletter dieser Woche verweist auf Vergleiche verschiedener Cluster-Linear ## Nachrichten -- **Vergleich von Cluster-Linearisationstechniken:** +- **Vergleich von Cluster-Linearisierungstechniken:** Pieter Wuille [veröffentlichte][wuille clustrade] auf Delving Bitcoin einige grundlegende Abwägungen zwischen drei verschiedenen Cluster-Linearisierungstechniken und ergänzte dies durch [Benchmarks][wuille clusbench] der jeweiligen Implementierungen. Mehrere andere Entwickler diskutierten die Ergebnisse und stellten Rückfragen, auf die Wuille antwortete. - **Erhöhung oder Abschaffung des `OP_RETURN`-Größenlimits in Bitcoin Core:** From c5ee486668bef94ea3754aba82780e862f053539 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Fri, 6 Jun 2025 16:55:02 +0200 Subject: [PATCH 066/278] Update _posts/de/newsletters/2025-05-02-newsletter.md Co-authored-by: garfiel-d --- _posts/de/newsletters/2025-05-02-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/de/newsletters/2025-05-02-newsletter.md b/_posts/de/newsletters/2025-05-02-newsletter.md index 23ae5740d6..ea65bb7747 100644 --- a/_posts/de/newsletters/2025-05-02-newsletter.md +++ b/_posts/de/newsletters/2025-05-02-newsletter.md @@ -21,7 +21,7 @@ Der Newsletter dieser Woche verweist auf Vergleiche verschiedener Cluster-Linear Pieter Wuille [argumentierte][wuille opr], dass die Standardness-Policy von Transaktionen kaum verhindern kann, dass gut finanzierte Organisationen datentragende Transaktionen direkt an Miner senden und so in Blöcke bringen. Außerdem seien Blöcke ohnehin meist voll, egal ob sie Daten enthalten oder nicht, sodass sich die Gesamtmenge der zu speichernden Daten für einen Knoten kaum ändert. - *Gegen die Erhöhung des Limits:* - Jason Hughes [argumentierte][hughes opr], dass eine Erhöhung des Limits es einfacher machen würde, beliebige Daten auf Rechnern zu speichern, die Full Knoten betreiben – darunter auch potenziell anstößige oder in vielen Ländern illegale Inhalte. Selbst wenn der Knoten die Daten auf der Festplatte verschlüsselt (siehe [Newsletter #316][news316 blockxor]), könnte das Speichern und Abrufen solcher Daten über Bitcoin Core RPCs für viele Nutzer problematisch sein. + Jason Hughes [argumentierte][hughes opr], dass eine Erhöhung des Limits es einfacher machen würde, beliebige Daten auf Rechnern zu speichern, die Full Nodes betreiben – darunter auch potenziell anstößige oder in vielen Ländern illegale Inhalte. Selbst wenn der Knoten die Daten auf der Festplatte verschlüsselt (siehe [Newsletter #316][news316 blockxor]), könnte das Speichern und Abrufen solcher Daten über Bitcoin Core RPCs für viele Nutzer problematisch sein. ## Veröffentlichungen und Release-Kandidaten From c7fe2ea89e9aa487a00a843a87c15a3ec7cbedd7 Mon Sep 17 00:00:00 2001 From: Walpurga03 Date: Fri, 6 Jun 2025 17:20:44 +0200 Subject: [PATCH 067/278] drop the timestamps --- .../de/newsletters/2025-05-09-newsletter.md | 26 +++++++++---------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/_posts/de/newsletters/2025-05-09-newsletter.md b/_posts/de/newsletters/2025-05-09-newsletter.md index 44c23de3d8..8eaf1d6fcd 100644 --- a/_posts/de/newsletters/2025-05-09-newsletter.md +++ b/_posts/de/newsletters/2025-05-09-newsletter.md @@ -13,11 +13,11 @@ Dieser Newsletter beschreibt eine kürzlich entdeckte theoretische Konsensfehler - **BIP30-Konsensfehler-Sicherheitslücke:** Ruben Somsen [berichtete][somsen bip30] auf der Bitcoin-Dev-Mailingliste über eine theoretische Konsensfehler-Situation, die nun auftreten könnte, nachdem Checkpoints aus Bitcoin Core entfernt wurden (siehe [Newsletter #346][news346 checkpoints]). Kurz gesagt: Die Coinbase-Transaktionen der Blöcke 91722 und 91812 sind [dupliziert][topic duplicate transactions] in den Blöcken 91880 und 91842. [BIP30][] legt fest, dass diese beiden Blöcke so behandelt werden sollen, wie es die historische Version von Bitcoin Core 2010 tat, indem die früheren Coinbase-Einträge im UTXO-Set durch die späteren Duplikate überschrieben werden. Somsen merkt jedoch an, dass eine Reorganisation eines oder beider späteren Blöcke dazu führen würde, dass der doppelte Eintrag (oder die Einträge) aus dem UTXO-Set entfernt werden, wodurch auch die früheren Einträge fehlen würden. Ein neu gestarteter Knoten, der die doppelten Transaktionen nie gesehen hat, hätte jedoch noch die früheren Transaktionen, was zu einem unterschiedlichen UTXO-Set führen könnte und im Falle einer Ausgabe zu einem Konsensfehler führen kann. - Solange Bitcoin Core Checkpoints hatte, war das kein Problem, da diese alle vier genannten Blöcke als Teil der besten Blockchain erforderten. Jetzt ist es nur noch ein theoretisches Problem, außer im Fall, dass der Proof-of-Work-Sicherheitsmechanismus von Bitcoin versagt. Es wurden mehrere mögliche Lösungen diskutiert, z.B. das Hardcoden zusätzlicher Sonderfälle für diese beiden Ausnahmen. {% assign timestamp="0:52" %} + Solange Bitcoin Core Checkpoints hatte, war das kein Problem, da diese alle vier genannten Blöcke als Teil der besten Blockchain erforderten. Jetzt ist es nur noch ein theoretisches Problem, außer im Fall, dass der Proof-of-Work-Sicherheitsmechanismus von Bitcoin versagt. Es wurden mehrere mögliche Lösungen diskutiert, z.B. das Hardcoden zusätzlicher Sonderfälle für diese beiden Ausnahmen. - **Vermeidung von BIP32-Pfad-Wiederverwendung:** Kevin Loaec [diskutierte][loaec bip32reuse] auf Delving Bitcoin verschiedene Möglichkeiten, zu verhindern, dass derselbe [BIP32][topic bip32] Wallet-Pfad mit unterschiedlichen Wallets verwendet wird, was zu einem Verlust der Privatsphäre durch [Output Linking][topic output linking] und theoretisch auch zu einem Sicherheitsverlust (z.B. durch [Quantencomputer][topic quantum resistance]) führen könnte. Er schlug drei Ansätze vor: einen zufälligen Pfad, einen Pfad basierend auf dem Wallet-Geburtstag und einen Pfad mit einem inkrementierenden Zähler. Er empfahl den Ansatz mit dem Geburtstag. - Außerdem empfahl er, die meisten der [BIP48][]-Pfad-Elemente wegzulassen, da durch die zunehmende Nutzung von [Descriptor][topic descriptors] Wallets, insbesondere für Multisig und komplexe Script-Wallets, diese nicht mehr nötig seien. Salvatore Ingala [antwortete][ingala bip48] jedoch, dass das _coin type_-Element im BIP48-Pfad beibehalten werden sollte, da es hilft, Schlüssel für verschiedene Kryptowährungen zu trennen, was von einigen Hardware-Signiergeräten erzwungen wird. {% assign timestamp="28:33" %} + Außerdem empfahl er, die meisten der [BIP48][]-Pfad-Elemente wegzulassen, da durch die zunehmende Nutzung von [Descriptor][topic descriptors] Wallets, insbesondere für Multisig und komplexe Script-Wallets, diese nicht mehr nötig seien. Salvatore Ingala [antwortete][ingala bip48] jedoch, dass das _coin type_-Element im BIP48-Pfad beibehalten werden sollte, da es hilft, Schlüssel für verschiedene Kryptowährungen zu trennen, was von einigen Hardware-Signiergeräten erzwungen wird. ## Bitcoin Core PR Review Club @@ -47,35 +47,33 @@ Mit diesem PR kann ein Nutzer Bitcoin Core mit `bitcoin daemon` oder `bitcoin gu a4link="https://bitcoincore.reviews/31375#l-117" %} -{% assign timestamp="16:38" %} - ## Veröffentlichungen und Release-Kandidaten _Neue Releases und Release-Kandidaten für populäre Bitcoin-Infrastrukturprojekte. Bitte erwäge, auf neue Releases zu aktualisieren oder Release-Kandidaten zu testen._ -- [LND 0.19.0-beta.rc4][] ist ein Release-Kandidat für diesen populären LN-Knoten. Eine der wichtigsten Verbesserungen, die getestet werden sollte, ist das neue RBF-basierte Fee-Bumping für kooperative Channel-Schließungen. {% assign timestamp="45:01" %} +- [LND 0.19.0-beta.rc4][] ist ein Release-Kandidat für diesen populären LN-Knoten. Eine der wichtigsten Verbesserungen, die getestet werden sollte, ist das neue RBF-basierte Fee-Bumping für kooperative Channel-Schließungen. ## Wichtige Code- und Dokumentationsänderungen _Bemerkenswerte aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und [BINANAs][binana repo]._ -- [Core Lightning #8227][] fügt Rust-basierte `lsps-client`- und `lsps-service`-Plugins hinzu, die ein Kommunikationsprotokoll zwischen LSP-Knoten und deren Clients implementieren. Sie verwenden ein JSON-RPC-Format über [BOLT8][] Peer-to-Peer-Nachrichten, wie in [BLIP50][] spezifiziert (siehe Newsletter [#335][news335 blip50]). Dies legt die Grundlage für die Implementierung eingehender Liquiditätsanfragen gemäß [BLIP51][] und [JIT-Channels][topic jit channels] gemäß [BLIP52][]. {% assign timestamp="45:18" %} +- [Core Lightning #8227][] fügt Rust-basierte `lsps-client`- und `lsps-service`-Plugins hinzu, die ein Kommunikationsprotokoll zwischen LSP-Knoten und deren Clients implementieren. Sie verwenden ein JSON-RPC-Format über [BOLT8][] Peer-to-Peer-Nachrichten, wie in [BLIP50][] spezifiziert (siehe Newsletter [#335][news335 blip50]). Dies legt die Grundlage für die Implementierung eingehender Liquiditätsanfragen gemäß [BLIP51][] und [JIT-Channels][topic jit channels] gemäß [BLIP52][]. -- [Core Lightning #8162][] aktualisiert die Behandlung von von Peers initiierten, ausstehenden Channel-Öffnungen, indem sie unbegrenzt (bis zu den 100 neuesten) gespeichert werden. Zuvor wurden unbestätigte Channel-Öffnungen nach 2016 Blöcken vergessen. Zusätzlich werden geschlossene Channels nun im Speicher gehalten, damit ein Knoten auf die `channel_reestablish`-Nachricht eines Peers reagieren kann. {% assign timestamp="46:43" %} +- [Core Lightning #8162][] aktualisiert die Behandlung von Peers initiierten, ausstehenden Channel-Öffnungen, indem sie unbegrenzt (bis zu den 100 neuesten) gespeichert werden. Zuvor wurden unbestätigte Channel-Öffnungen nach 2016 Blöcken vergessen. Zusätzlich werden geschlossene Channels nun im Speicher gehalten, damit ein Knoten auf die `channel_reestablish`-Nachricht eines Peers reagieren kann. -- [Core Lightning #8166][] verbessert den `wait`-RPC-Befehl, indem das einzelne `details`-Objekt durch subsystemspezifische Objekte ersetzt wird: `invoices`, `forwards`, `sendpays` und [`htlcs`][topic htlc]. Außerdem unterstützt der RPC-Befehl `listhtlcs` jetzt Paginierung über neue Felder `created_index` und `updated_index` sowie die Parameter `index`, `start` und `end`. {% assign timestamp="47:44" %} +- [Core Lightning #8166][] verbessert den `wait`-RPC-Befehl, indem das einzelne `details`-Objekt durch subsystemspezifische Objekte ersetzt wird: `invoices`, `forwards`, `sendpays` und [`htlcs`][topic htlc]. Außerdem unterstützt der RPC-Befehl `listhtlcs` jetzt Paginierung über neue Felder `created_index` und `updated_index` sowie die Parameter `index`, `start` und `end`. -- [Core Lightning #8237][] ergänzt den RPC-Befehl `listpeerchannels` um einen `short_channel_id`-Parameter, um nur einen bestimmten Channel zurückzugeben, falls angegeben. {% assign timestamp="48:49" %} +- [Core Lightning #8237][] ergänzt den RPC-Befehl `listpeerchannels` um einen `short_channel_id`-Parameter, um nur einen bestimmten Channel zurückzugeben, falls angegeben. -- [LDK #3700][] fügt dem Event `HTLCHandlingFailed` ein neues Feld `failure_reason` hinzu, das zusätzliche Informationen darüber liefert, warum das [HTLC][topic htlc] fehlgeschlagen ist und ob die Ursache lokal oder downstream lag. Das Feld `failed_next_destination` wird in `failure_type` umbenannt und die Variante `UnknownNextHop` wird zugunsten der allgemeineren Variante `InvalidForward` als veraltet markiert. {% assign timestamp="49:28" %} +- [LDK #3700][] fügt dem Event `HTLCHandlingFailed` ein neues Feld `failure_reason` hinzu, das zusätzliche Informationen darüber liefert, warum das [HTLC][topic htlc] fehlgeschlagen ist und ob die Ursache lokal oder downstream lag. Das Feld `failed_next_destination` wird in `failure_type` umbenannt und die Variante `UnknownNextHop` wird zugunsten der allgemeineren Variante `InvalidForward` als veraltet markiert. -- [Rust Bitcoin #4387][] überarbeitet das Fehlerhandling von [BIP32][topic bip32], indem der bisherige einzelne `bip32::Error` durch separate Enums für Ableitung, Child-Nummer/Pfad-Parsing und Extended-Key-Parsing ersetzt wird. Außerdem wird eine neue Variante `DerivationError::MaximumDepthExceeded` für Pfade mit mehr als 256 Ebenen eingeführt. Diese API-Änderungen sind nicht abwärtskompatibel. {% assign timestamp="49:55" %} +- [Rust Bitcoin #4387][] überarbeitet das Fehlerhandling von [BIP32][topic bip32], indem der bisherige einzelne `bip32::Error` durch separate Enums für Ableitung, Child-Nummer/Pfad-Parsing und Extended-Key-Parsing ersetzt wird. Außerdem wird eine neue Variante `DerivationError::MaximumDepthExceeded` für Pfade mit mehr als 256 Ebenen eingeführt. Diese API-Änderungen sind nicht abwärtskompatibel. -- [BIPs #1835][] aktualisiert [BIP48][] (siehe Newsletter [#135][news135 bip48]), um den Skripttyp-Wert 3 für [taproot][topic taproot] (P2TR)-Ableitungen in deterministischen Multisig-Wallets mit dem Präfix m/48' zu reservieren, zusätzlich zu den bestehenden Skripttypen P2SH-P2WSH (1′) und P2WSH (2′). {% assign timestamp="50:15" %} +- [BIPs #1835][] aktualisiert [BIP48][] (siehe Newsletter [#135][news135 bip48]), um den Skripttyp-Wert 3 für [taproot][topic taproot] (P2TR)-Ableitungen in deterministischen Multisig-Wallets mit dem Präfix m/48' zu reservieren, zusätzlich zu den bestehenden Skripttypen P2SH-P2WSH (1′) und P2WSH (2′). -- [BIPs #1800][] merged [BIP54][], das den [Consensus Cleanup Soft Fork][topic consensus cleanup] spezifiziert, um eine Reihe langjähriger Schwachstellen im Bitcoin-Protokoll zu beheben. Siehe Newsletter [#348][news348 cleanup] für eine ausführliche Beschreibung dieses BIPs. {% assign timestamp="55:03" %} +- [BIPs #1800][] merged [BIP54][], das den [Consensus Cleanup Soft Fork][topic consensus cleanup] spezifiziert, um eine Reihe langjähriger Schwachstellen im Bitcoin-Protokoll zu beheben. Siehe Newsletter [#348][news348 cleanup] für eine ausführliche Beschreibung dieses BIPs. -- [BOLTs #1245][] verschärft [BOLT11][], indem nicht-minimale Längen-Codierungen in Rechnungen verboten werden: Das Ablaufdatum (x), das [CLTV expiry delta][topic cltv expiry delta] für den letzten Hop (c) und die Feature-Bits (9) müssen in minimaler Länge ohne führende Nullen serialisiert werden, und Leser sollten jede Rechnung ablehnen, die führende Nullen enthält. Diese Änderung wurde durch Fuzz-Tests motiviert, die zeigten, dass beim Reserialisieren nicht-minimaler Rechnungen durch LDK die ECDSA-Signatur der Rechnung fehlschlägt. {% assign timestamp="56:37" %} +- [BOLTs #1245][] verschärft [BOLT11][], indem nicht-minimale Längen-Codierungen in Rechnungen verboten werden: Das Ablaufdatum (x), das [CLTV expiry delta][topic cltv expiry delta] für den letzten Hop (c) und die Feature-Bits (9) müssen in minimaler Länge ohne führende Nullen serialisiert werden, und Leser sollten jede Rechnung ablehnen, die führende Nullen enthält. Diese Änderung wurde durch Fuzz-Tests motiviert, die zeigten, dass beim Reserialisieren nicht-minimaler Rechnungen durch LDK die ECDSA-Signatur der Rechnung fehlschlägt. {% include snippets/recap-ad.md when="2025-05-13 16:30" %} {% include references.md %} From 97d3a6ff88b7aa0c3ed911bc14bb4fe1cb96c972 Mon Sep 17 00:00:00 2001 From: Walpurga03 Date: Fri, 6 Jun 2025 17:47:51 +0200 Subject: [PATCH 068/278] newsletter 356 clean the commits --- .../de/newsletters/2025-05-30-newsletter.md | 96 +++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 _posts/de/newsletters/2025-05-30-newsletter.md diff --git a/_posts/de/newsletters/2025-05-30-newsletter.md b/_posts/de/newsletters/2025-05-30-newsletter.md new file mode 100644 index 0000000000..fa20ed0a26 --- /dev/null +++ b/_posts/de/newsletters/2025-05-30-newsletter.md @@ -0,0 +1,96 @@ +--- +title: 'Bitcoin Optech Newsletter #356' +permalink: /de/newsletters/2025/05/30/ +name: 2025-05-30-newsletter-de +slug: 2025-05-30-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche fasst eine Diskussion über die möglichen Auswirkungen von zuordenbaren Fehlern auf die Privatsphäre im Lightning Netzwerk (LN) zusammen. Ebenfalls enthalten sind unsere regulären Abschnitte mit ausgewählten Fragen und Antworten von Bitcoin Stack Exchange, Ankündigungen neuer Releases und Release-Kandidaten sowie Beschreibungen aktueller Änderungen an beliebter Bitcoin-Infrastruktur-Software. + +## Nachrichten + +- **Beeinträchtigen zuordenbare Fehler die Privatsphäre im Lightning Netzwerk?** Carla Kirk-Cohen [veröffentlichte][kirkcohen af] auf Delving Bitcoin eine Analyse der möglichen Folgen für die Privatsphäre von LN-Zahlenden und -Empfangenden, falls das Netzwerk [zuordenbare Fehler][topic attributable failures] einführt – insbesondere, wenn dem Zahlenden die Weiterleitungszeit an jedem Hop mitgeteilt wird. Unter Bezugnahme auf mehrere Arbeiten beschreibt sie zwei Arten von Deanonymisierungsangriffen: + + - Ein Angreifer, der einen oder mehrere Weiterleitungsknoten betreibt, nutzt Zeitdaten, um die Anzahl der Hops einer Zahlung ([HTLC][topic htlc]) zu bestimmen. Kombiniert mit Kenntnissen über die Topologie des öffentlichen Netzwerks kann dies die Menge möglicher Empfänger einschränken. + + - Ein Angreifer verwendet einen IP-Netzwerk-Traffic-Forwarder ([autonomous system][]) zur passiven Überwachung des Traffics und kombiniert dies mit Kenntnissen über die IP-Latenz zwischen Knoten (Ping-Zeiten) sowie der Topologie und anderen Eigenschaften des öffentlichen Lightning Netzwerks. + + Sie beschreibt dann mögliche Gegenmaßnahmen, darunter: + + - Empfangende sollten das Akzeptieren eines HTLC um eine kleine, zufällige Zeit verzögern, um Timing-Angriffe zu erschweren, die den Empfänger identifizieren wollen. + - Zahlende sollten das erneute Senden fehlgeschlagener Zahlungen (oder [MPP][topic multipath payments]-Teile) um eine kleine, zufällige Zeit verzögern und alternative Pfade nutzen, um Timing- und Fehlerangriffe zu erschweren, die den Zahlenden identifizieren wollen. + - Mehr Zahlungssplitting mit MPP, um es schwieriger zu machen, den ausgegebenen Betrag zu erraten. + - Zahlenden erlauben, sich für eine langsamere Weiterleitung ihrer Zahlungen zu entscheiden, wie zuvor vorgeschlagen (siehe [Newsletter #208][news208 slowln]). Dies könnte mit HTLC-Batching kombiniert werden, das in LND bereits implementiert ist (eine zusätzliche zufällige Verzögerung könnte die Privatsphäre weiter erhöhen). + - Die Genauigkeit der Zeitstempel von zuordenbaren Fehlern verringern, um Weiterleitungsknoten, die kleine Zufallsverzögerungen einbauen, nicht zu benachteiligen. + + Die Diskussion verschiedener Teilnehmer bewertete die Bedenken und vorgeschlagenen Gegenmaßnahmen im Detail und betrachtete weitere mögliche Angriffe und Gegenmaßnahmen. + +## Ausgewählte Fragen & Antworten von Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] ist eine der ersten Anlaufstellen für Optech-Mitwirkende, wenn sie Antworten suchen – oder wenn wir ein paar Minuten Zeit haben, um neugierigen oder ratlosen Nutzern zu helfen. In dieser monatlichen Rubrik heben wir einige der am höchsten bewerteten Fragen und Antworten seit unserem letzten Update hervor.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Welche Transaktionen gelangen in blockreconstructionextratxn?]({{bse}}116519) + Glozow erklärt, wie die Extrapool-Datenstruktur (siehe [Newsletter #339][news339 extrapool]) abgelehnte und ersetzte Transaktionen, die vom Knoten gesehen wurden, zwischenspeichert und listet die Kriterien für Ausschluss und Entfernung auf. + +- [Warum sollte jemand OP_RETURN anstelle von Inscriptions verwenden, abgesehen von den Gebühren?]({{bse}}126208) + Sjors Provoost merkt an, dass `OP_RETURN` nicht nur manchmal günstiger ist, sondern auch für Protokolle genutzt werden kann, die Daten benötigen, die vor dem Ausgeben einer Transaktion verfügbar sind – im Gegensatz zu Witness-Daten, die erst bei der Ausgabe offenbart werden. + +- [Warum erhält mein Bitcoin-Knoten keine eingehenden Verbindungen?]({{bse}}126338) + Lightlike weist darauf hin, dass es bei einem neuen Knoten im Netzwerk einige Zeit dauern kann, bis seine Adresse im P2P-Netzwerk weit verbreitet ist, und dass Knoten ihre Adresse erst bewerben, wenn der Initial Block Download (IBD) abgeschlossen ist. + +- [Wie konfiguriere ich meinen Knoten so, dass er Transaktionen größer als 400 Byte herausfiltert?]({{bse}}126347) + Antoine Poinsot bestätigt, dass es in Bitcoin Core keine Konfigurationsoption gibt, um die maximale Standard-Transaktionsgröße anzupassen. Er erläutert, dass Nutzer, die diesen Wert anpassen möchten, den Quellcode ändern können, warnt aber vor möglichen Nachteilen sowohl bei größeren als auch bei kleineren Maximalwerten. + +- [Was bedeutet „not publicly routable“ node im Bitcoin Core P2P?]({{bse}}126225) + Pieter Wuille und Vasil Dimov geben Beispiele für P2P-Verbindungen, wie etwa [Tor][topic anonymity networks], die nicht über das globale Internet geroutet werden können und im `netinfo`-Output von Bitcoin Core im „npr“-Bucket erscheinen. + +- [Warum sollte ein Knoten überhaupt eine Transaktion weiterleiten?]({{bse}}127391) + Pieter Wuille listet Vorteile für Betreiber auf, die Transaktionen weiterleiten: Privatsphäre beim Weiterleiten eigener Transaktionen, schnellere Blockverbreitung beim Mining und verbesserte Dezentralisierung des Netzwerks bei minimalen Zusatzkosten gegenüber dem bloßen Weiterleiten von Blöcken. + +- [Ist Selfish Mining mit Compact Blocks und FIBRE immer noch möglich?]({{bse}}49515) + Antoine Poinsot antwortet auf eine Frage von 2016 und stellt klar: „Ja, Selfish Mining ist auch mit verbesserter Blockverbreitung weiterhin eine mögliche Optimierung. Es ist nicht korrekt zu sagen, dass Selfish Mining jetzt nur noch ein theoretischer Angriff ist.“ Er verweist außerdem auf eine von ihm erstellte [Mining-Simulation][miningsimulation github]. + +## Veröffentlichungen und Release-Kandidaten + +_Neue Veröffentlichungen und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie ein Upgrade auf neue Versionen oder helfen Sie bei der Testung von Release-Kandidaten._ + +- [Core Lightning 25.05rc1][] ist ein Release-Kandidat für die nächste Hauptversion dieser beliebten LN-Knoten-Implementierung. + +- [LDK 0.1.3][] und [0.1.4][ldk 0.1.4] sind Releases dieser beliebten Bibliothek zum Bau von LN-fähigen Anwendungen. Version 0.1.3, diese Woche als Release auf GitHub getaggt, aber letzten Monat datiert, enthält den Fix für einen Denial-of-Service-Angriff. Version 0.1.4, das aktuellste Release, „behebt eine Funds-Theft-Schwachstelle in extrem seltenen Fällen“. Beide Releases enthalten weitere Fehlerbehebungen. + +## Wichtige Code- und Dokumentationsänderungen + +_Bedeutende kürzliche Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und [BINANAs][binana repo]._ + +- [Bitcoin Core #31622][] fügt ein Signature-Hash-(sighash)-Typfeld zu [PSBTs][topic psbt] hinzu, wenn dieser Wert von `SIGHASH_DEFAULT` oder `SIGHASH_ALL` abweicht. [MuSig2][topic musig] erfordert, dass alle mit demselben Sighash-Typ signieren, daher muss dieses Feld in der PSBT vorhanden sein. Zusätzlich wird der RPC-Befehl `descriptorprocesspsbt` aktualisiert, sodass er die Funktion `SignPSBTInput` verwendet, die sicherstellt, dass der Sighash-Typ der PSBT mit dem in der CLI angegebenen Wert übereinstimmt, falls zutreffend. + +- [Eclair #3065][] fügt Unterstützung für zuordenbare Fehler (siehe [Newsletter #224][news224 failures]) gemäß [BOLTs #1044][] hinzu. Diese Funktion ist standardmäßig deaktiviert, da die Spezifikation noch nicht final ist, kann aber mit der Einstellung `eclair.features.option_attributable_failure = optional` aktiviert werden. Die Kompatibilität mit LDK wurde erfolgreich getestet, siehe [Newsletter #349][news349 failures] für weitere Informationen zur LDK-Implementierung und zum Protokoll. + +- [LDK #3796][] verschärft die Überprüfung des Channel-Guthabens, sodass Finanzierer genügend Kapital für die Commitment-Transaktionsgebühr, die beiden 330 sat [Anchor Outputs][topic anchor outputs] und die Channel-Reserve haben müssen. Zuvor konnten Finanzierer auf die Channel-Reserve zurückgreifen, um die beiden Anchor Outputs zu decken. + +- [BIPs #1760][] merged [BIP53][], das eine Konsens-Softfork-Regel spezifiziert, die 64-Byte-Transaktionen (ohne Witness-Daten gemessen) verbietet, um eine Art von [Merkle-Baum-Schwachstelle][topic merkle tree vulnerabilities] zu verhindern, die gegen SPV-Clients ausnutzbar wäre. Dieser PR schlägt eine ähnliche Korrektur wie eine der im [Consensus Cleanup Softfork][topic consensus cleanup] enthaltenen Korrekturen vor. + +- [BIPs #1850][] macht eine frühere Änderung an [BIP48][] rückgängig, die den Script-Typ-Wert 3 für [Taproot][topic taproot] (P2TR)-Ableitungen reserviert hatte (siehe [Newsletter #353][news353 bip48]). Grund ist, dass [Tapscript][topic tapscript] kein `OP_CHECKMULTISIG` unterstützt, sodass das in [BIP67][] referenzierte Output-Skript (auf das sich [BIP48][] stützt) nicht als P2TR ausgedrückt werden kann. Der PR markiert außerdem den Status von [BIP48][] als „Final“, um widerzuspiegeln, dass der Zweck des BIPs die Definition der Branchenverwendung von `m/48'`-[HD wallet][topic bip32]-Ableitungspfaden war, nicht die Vorgabe neuen Verhaltens. + +- [BIPs #1793][] merged [BIP443][], das den [OP_CHECKCONTRACTVERIFY][topic matt] (OP_CCV)-Opcode vorschlägt, mit dem überprüft werden kann, dass ein öffentlicher Schlüssel (sowohl von Outputs als auch Inputs) auf beliebige Daten verpflichtet. Siehe [Newsletter #348][news348 op_ccv] für weitere Informationen zu diesem vorgeschlagenen [Covenant][topic covenants]. + +{% include snippets/recap-ad.md when="2025-06-03 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31622,3065,3796,1760,1850,1793,1044" %} +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[ldk 0.1.3]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.1.3 +[ldk 0.1.4]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.1.4 +[news208 slowln]: /en/newsletters/2022/07/13/#allowing-deliberately-slow-ln-payment-forwarding +[autonomous system]: https://en.wikipedia.org/wiki/Autonomous_system_(Internet) +[kirkcohen af]: https://delvingbitcoin.org/t/latency-and-privacy-in-lightning/1723 +[news224 failures]: /de/newsletters/2022/11/02/#zuordnung-von-ln-routing-fehlern +[news349 failures]: /en/newsletters/2025/04/11/#ldk-2256 +[news353 bip48]: /en/newsletters/2025/05/09/#bips-1835 +[news348 op_ccv]: /de/newsletters/2025/04/04/#op-checkcontractverify-semantik +[news339 extrapool]: /de/newsletters/2025/01/31/#aktualisierte-statistiken-zur-kompaktblock-rekonstruktion +[miningsimulation github]: https://github.com/darosior/miningsimulationq \ No newline at end of file From 941b9bfb34298b245635a28be465b02fe88b855f Mon Sep 17 00:00:00 2001 From: Walpurga03 Date: Fri, 6 Jun 2025 18:30:49 +0200 Subject: [PATCH 069/278] fix the anker link --- _posts/de/newsletters/2025-05-09-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/de/newsletters/2025-05-09-newsletter.md b/_posts/de/newsletters/2025-05-09-newsletter.md index 8eaf1d6fcd..aab2991461 100644 --- a/_posts/de/newsletters/2025-05-09-newsletter.md +++ b/_posts/de/newsletters/2025-05-09-newsletter.md @@ -86,7 +86,7 @@ _Bemerkenswerte aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], [Core [news346 checkpoints]: /de/newsletters/2025/03/21/#bitcoin-core-31649 [news335 blip50]: /en/newsletters/2025/01/03/#blips-52 [news135 bip48]: /en/newsletters/2021/07/28/#bips-1072 -[news348 cleanup]: /de/newsletters/2025/04/04/#draft-bip-published-for-consensus-cleanup +[news348 cleanup]: /de/newsletters/2025/04/04/#entwurf-fur-bip-veroffentlicht-fur-konsens-reinigung [review club 31375]: https://bitcoincore.reviews/31375 [gh ryanofsky]: https://github.com/ryanofsky [multiprocess design]: https://github.com/bitcoin/bitcoin/blob/master/doc/design/multiprocess.md \ No newline at end of file From b9bd8bcd38f9683b4c2e24cda2f6cb65a3b3a851 Mon Sep 17 00:00:00 2001 From: Walpurga03 Date: Fri, 6 Jun 2025 19:23:52 +0200 Subject: [PATCH 070/278] 354-newsletter-german --- STYLE-DE.md | 10 ++- .../de/newsletters/2025-05-16-newsletter.md | 73 +++++++++++++++++++ 2 files changed, 82 insertions(+), 1 deletion(-) create mode 100644 _posts/de/newsletters/2025-05-16-newsletter.md diff --git a/STYLE-DE.md b/STYLE-DE.md index 3192554c76..cee65b4a7a 100644 --- a/STYLE-DE.md +++ b/STYLE-DE.md @@ -161,4 +161,12 @@ deutschen Bitcoin-Szene etabliert haben. Für einige Begriffe werden folgende ### Maßeinheiten -Siehe [Hauptleitfaden](STYLE.md). \ No newline at end of file +Siehe [Hauptleitfaden](STYLE.md). + +### Nicht zu übersetzende Begriffe und Ausnahmen + +| Englischer Ausdruck | Nicht übersetzen, wenn ... | Beispiel/Anmerkung | +|----------------------|-----------------------------------------------------------------|----------------------------------------------------| +| Full Node /Full Nodes| immer | Nicht als "Vollknoten" übersetzen | +| output / input | im Zusammenhang mit UTXO (z.B. "UTXO output", "UTXO input") | Nicht als "Ausgabe/Eingabe" übersetzen | +| non-custodial | immer | Nicht als "nicht-verwahrt" übersetzen | \ No newline at end of file diff --git a/_posts/de/newsletters/2025-05-16-newsletter.md b/_posts/de/newsletters/2025-05-16-newsletter.md new file mode 100644 index 0000000000..251152d370 --- /dev/null +++ b/_posts/de/newsletters/2025-05-16-newsletter.md @@ -0,0 +1,73 @@ +--- +title: 'Bitcoin Optech Newsletter #354' +permalink: /de/newsletters/2025/05/16/ +name: 2025-05-16-newsletter-de +slug: 2025-05-16-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche beschreibt eine behobene Schwachstelle, die ältere Versionen von Bitcoin Core betrifft. Ebenfalls enthalten sind unsere regulären Abschnitte mit Zusammenfassungen aktueller Diskussionen über Änderungen der Bitcoin-Konsensregeln, Ankündigungen neuer Releases und Release-Kandidaten sowie Beschreibungen wichtiger Änderungen an populärer Bitcoin-Infrastruktur. + +## Nachrichten + +- **Offenlegung einer Schwachstelle in alten Versionen von Bitcoin Core:** + Antoine Poinsot [berichtete][poinsot addrvuln] auf der Bitcoin-Dev-Mailingliste über eine Schwachstelle, die Bitcoin Core-Versionen vor 29.0 betrifft. Die Schwachstelle wurde ursprünglich von Eugene Siegel [verantwortungsvoll gemeldet][topic responsible disclosures], zusammen mit einer weiteren, eng verwandten Schwachstelle, die in [Newsletter #314][news314 excess addr] beschrieben wurde. Ein Angreifer konnte eine übermäßige Anzahl von Knoten-Adressanzeigen senden, um einen 32-Bit-Identifier zum Überlaufen zu bringen, was zu einem Absturz des Knotens führte. Dies wurde teilweise dadurch entschärft, dass die Anzahl der Updates auf eins pro Peer alle zehn Sekunden begrenzt wurde, was bei etwa 125 Peers im Standardfall ein Überlaufen nur dann ermöglicht hätte, wenn der Knoten über mehr als 10 Jahre kontinuierlich angegriffen worden wäre. Die Schwachstelle wurde vollständig behoben, indem ab Version 29.0 von Bitcoin Core 64-Bit-Identifier verwendet werden. + +## Änderungen am Konsens + +_Ein monatlicher Abschnitt mit Zusammenfassungen von Vorschlägen und Diskussionen zu Änderungen der Bitcoin-Konsensregeln._ + +- **Vorgeschlagenes BIP für 64-Bit-Arithmetik in Script:** + Chris Stewart [veröffentlichte][stewart bippost] auf der Bitcoin-Dev-Mailingliste einen [BIP-Entwurf][64bit bip], der vorschlägt, die bestehenden Opcodes von Bitcoin so zu erweitern, dass sie mit 64-Bit-Zahlen arbeiten. Dies folgt auf seine frühere Forschung (siehe Newsletter [#285][news285 64bit], [#290][news290 64bit] und [#306][news306 64bit]). Im Unterschied zu früheren Diskussionen verwendet der neue Vorschlag Zahlen im gleichen compactSize-Datenformat, das derzeit in Bitcoin genutzt wird. Weitere [Diskussionen][stewart inout] dazu fanden in zwei [Threads][stewart overflow] auf Delving Bitcoin statt. + +- **Vorgeschlagene Opcodes für rekursive Covenants mittels Quines:** + Auf Delving Bitcoin [schlug][cohen quine] Bram Cohen eine Reihe einfacher Opcodes vor, mit denen sich rekursive [Covenants][topic covenants] durch selbstreproduzierende Skripte ([Quines][]) erstellen ließen. Cohen beschreibt, wie die Opcodes genutzt werden könnten, um einen einfachen [Vault][topic vaults] zu bauen, und erwähnt ein fortgeschritteneres System, an dem er arbeitet. + +- **Beschreibung der Vorteile für BitVM durch `OP_CTV` und `OP_CSFS`:** + Robin Linus [beschrieb][linus bitvm-sf] auf Delving Bitcoin mehrere Verbesserungen für [BitVM][topic acc], die durch die vorgeschlagenen Opcodes [OP_CTV][topic op_checktemplateverify] und [OP_CSFS][topic op_checksigfromstack] per Soft Fork möglich würden. Zu den Vorteilen zählen eine höhere Anzahl von Operatoren ohne Nachteile, „etwa 10-fach kleinere Transaktionen“ (was die Worst-Case-Kosten reduziert) und die Möglichkeit nicht-interaktiver Peg-ins für bestimmte Verträge. + +## Veröffentlichungen und Release-Kandidaten + +_Neue Veröffentlichungen und Release-Kandidaten für populäre Bitcoin-Infrastrukturprojekte. Bitte erwäge, auf neue Releases zu aktualisieren oder Release-Kandidaten zu testen._ + +- [LND 0.19.0-beta.rc4][] ist ein Release-Kandidat für diesen populären LN-Knoten. Eine der wichtigsten Verbesserungen, die getestet werden sollte, ist das neue RBF-basierte Fee-Bumping für kooperative Channel-Schließungen. + +## Wichtige Code- und Dokumentationsänderungen + +_Wichtige aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und [BINANAs][binana repo]._ + +- [Bitcoin Core #32155][] aktualisiert den internen Miner, sodass Coinbase-Transaktionen per [Timelock][topic timelocks] versehen werden, indem das Feld `nLockTime` auf die aktuelle Blockhöhe minus eins gesetzt und das Feld `nSequence` nicht final gesetzt wird (um das Timelock zu erzwingen). Obwohl der eingebaute Miner normalerweise nicht im Mainnet verwendet wird, sollen Mining-Pools durch dieses Update frühzeitig zur Übernahme dieser Änderungen in ihrer eigenen Software motiviert werden – als Vorbereitung auf den vorgeschlagenen [Consensus Cleanup][topic consensus cleanup] Soft Fork ([BIP54][]). Das Timelocking von Coinbase-Transaktionen löst die [Duplicate Transaction][topic duplicate transactions]-Schwachstelle und würde erlauben, die aufwändigen [BIP30][]-Prüfungen zu entfernen. + +- [Bitcoin Core #28710][] entfernt den verbleibenden Legacy-Wallet-Code, die zugehörige Dokumentation und Tests. Dazu gehören die ausschließlich für Legacy-Wallets bestimmten RPCs wie `importmulti`, `sethdseed`, `addmultisigaddress`, `importaddress`, `importpubkey`, `dumpwallet`, `importwallet` und `newkeypool`. Als letzter Schritt für die Entfernung der Legacy-Wallets werden auch die BerkeleyDB-Abhängigkeit und zugehörige Funktionen entfernt. Das absolute Minimum an Legacy-Code und ein unabhängiger BDB-Parser (siehe Newsletter [#305][news305 bdb]) bleiben jedoch erhalten, um die Migration zu [Descriptor][topic descriptors]-Wallets zu ermöglichen. + +- [Core Lightning #8272][] deaktiviert das DNS-Seed-Lookup-Fallback für die Peer-Discovery im Verbindungs-Daemon `connectd`, um Blockierungsprobleme durch Offline-DNS-Seeds zu vermeiden. + +- [LND #8330][] fügt dem bimodalen Wahrscheinlichkeitsmodell für das Pathfinding eine kleine Konstante (1/c) hinzu, um numerische Instabilitäten zu beheben. In Randfällen, in denen die Berechnung sonst aufgrund von Rundungsfehlern fehlschlagen und eine Wahrscheinlichkeit von Null liefern würde, sorgt diese Regularisierung dafür, dass das Modell auf eine Gleichverteilung zurückfällt. Damit werden Normalisierungsfehler behoben, die bei sehr großen Channels oder solchen auftreten, die nicht in eine bimodale Verteilung passen. Außerdem überspringt das Modell jetzt unnötige Wahrscheinlichkeitsberechnungen und korrigiert automatisch veraltete Channel-Liquiditätsbeobachtungen und widersprüchliche historische Informationen. + +- [Rust Bitcoin #4458][] ersetzt die Struktur `MtpAndHeight` durch ein explizites Paar aus dem neu hinzugefügten `BlockMtp` und dem bereits existierenden `BlockHeight`, um Blockhöhe und Median Time Past (MTP) bei relativen [Timelocks][topic timelocks] besser modellieren zu können. Im Gegensatz zu `locktime::absolute::MedianTimePast`, das auf Werte über 500 Millionen (etwa nach 1985) beschränkt ist, kann `BlockMtp` jeden 32-Bit-Timestamp darstellen. Das macht ihn geeignet für theoretische Spezialfälle, wie Chains mit ungewöhnlichen Zeitstempeln. Das Update führt außerdem `BlockMtpInterval` ein und benennt `BlockInterval` in `BlockHeightInterval` um. + +- [BIPs #1848][] aktualisiert den Status von [BIP345][] auf „Withdrawn“, da der Autor [glaubt][obeirne vaultwithdraw], dass der vorgeschlagene Opcode `OP_VAULT` durch [`OP_CHECKCONTRACTVERIFY`][topic matt] (OP_CCV), ein allgemeineres [Vault][topic vaults]-Design und eine neue Art von [Covenant][topic covenants] ersetzt wurde. + +- [BIPs #1841][] merged [BIP172][], das vorschlägt, die unteilbare Basiseinheit von Bitcoin als „Satoshi“ formell zu definieren, um die aktuelle, weit verbreitete Nutzung widerzuspiegeln und die Terminologie in Anwendungen und Dokumentation zu standardisieren. + +- [BIPs #1821][] merged [BIP177][], das vorschlägt, „Bitcoin“ als die kleinste unteilbare Einheit (üblicherweise als 1 Satoshi bezeichnet) und nicht mehr als 100.000.000 Einheiten zu definieren. Das Ziel ist, die Terminologie an die tatsächliche Basiseinheit anzupassen und Verwirrung durch willkürliche Dezimal-Konventionen zu vermeiden. + +{% include snippets/recap-ad.md when="2025-05-20 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32155,28710,8272,8330,4458,1848,1841,1821" %} +[lnd 0.19.0-beta.rc4]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc4 +[news314 excess addr]: /en/newsletters/2024/08/02/#remote-crash-by-sending-excessive-addr-messages +[stewart bippost]: https://groups.google.com/g/bitcoindev/c/j1zEky-3QEE +[64bit bip]: https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki +[news285 64bit]: /en/newsletters/2024/01/17/#proposal-for-64-bit-arithmetic-soft-fork +[news290 64bit]: /en/newsletters/2024/02/21/#continued-discussion-about-64-bit-arithmetic-and-op-inout-amount-opcode +[news306 64bit]: /en/newsletters/2024/06/07/#updates-to-proposed-soft-fork-for-64-bit-arithmetic +[stewart inout]: https://delvingbitcoin.org/t/op-inout-amount/549/4 +[stewart overflow]: https://delvingbitcoin.org/t/overflow-handling-in-script/1549 +[poinsot addrvuln]: https://mailing-list.bitcoindevs.xyz/bitcoindev/EYvwAFPNEfsQ8cVwiK-8v6ovJU43Vy-ylARiDQ_1XBXAgg_ZqWIpB6m51fAIRtI-rfTmMGvGLrOe5Utl5y9uaHySELpya2ojC7yGsXnP90s=@protonmail.com/ +[cohen quine]: https://delvingbitcoin.org/t/a-simple-approach-to-allowing-recursive-covenants-by-enabling-quines/1655/ +[linus bitvm-sf]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/ +[quines]: https://en.wikipedia.org/wiki/Quine_(computing) +[news305 bdb]: /en/newsletters/2024/05/31/#bitcoin-core-26606 +[obeirne vaultwithdraw]: https://delvingbitcoin.org/t/withdrawing-op-vault-bip-345/1670/ From 140a508244e96461386a13ec66b980b5724e9d8c Mon Sep 17 00:00:00 2001 From: Walpurga03 Date: Sat, 7 Jun 2025 09:45:19 +0200 Subject: [PATCH 071/278] upgedated STYLE-DE-> Node,output/input --- STYLE-DE.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/STYLE-DE.md b/STYLE-DE.md index cee65b4a7a..76bbd7df71 100644 --- a/STYLE-DE.md +++ b/STYLE-DE.md @@ -72,9 +72,8 @@ deutschen Bitcoin-Szene etabliert haben. Für einige Begriffe werden folgende | funds | Kapital | | | | HTLC | | | Genus Maskulinum | | lightning network | Lightning Netzwerk | | | -| node | Knoten | Node | | +| node | Knoten | Node | Full Node wird nicht übersetzt | | relay | Weiterleitung | | | -| output | Ausgabe | Output | Im Kontext von UTXO | | silent payment | Stille Zahlung | | | | UTXO | | | Genus Maskulinum | | wallet | Wallet | Geldbörse | Genus Neutrum | From 25efc7dd846c335cbbb4d34d8e5fcaf62815dd80 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Sat, 7 Jun 2025 15:46:59 +0200 Subject: [PATCH 072/278] Update _posts/de/newsletters/2025-05-16-newsletter.md Co-authored-by: garfiel-d --- _posts/de/newsletters/2025-05-16-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/de/newsletters/2025-05-16-newsletter.md b/_posts/de/newsletters/2025-05-16-newsletter.md index 251152d370..cc6b878e04 100644 --- a/_posts/de/newsletters/2025-05-16-newsletter.md +++ b/_posts/de/newsletters/2025-05-16-newsletter.md @@ -47,7 +47,7 @@ _Wichtige aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], [Core Light - [Rust Bitcoin #4458][] ersetzt die Struktur `MtpAndHeight` durch ein explizites Paar aus dem neu hinzugefügten `BlockMtp` und dem bereits existierenden `BlockHeight`, um Blockhöhe und Median Time Past (MTP) bei relativen [Timelocks][topic timelocks] besser modellieren zu können. Im Gegensatz zu `locktime::absolute::MedianTimePast`, das auf Werte über 500 Millionen (etwa nach 1985) beschränkt ist, kann `BlockMtp` jeden 32-Bit-Timestamp darstellen. Das macht ihn geeignet für theoretische Spezialfälle, wie Chains mit ungewöhnlichen Zeitstempeln. Das Update führt außerdem `BlockMtpInterval` ein und benennt `BlockInterval` in `BlockHeightInterval` um. -- [BIPs #1848][] aktualisiert den Status von [BIP345][] auf „Withdrawn“, da der Autor [glaubt][obeirne vaultwithdraw], dass der vorgeschlagene Opcode `OP_VAULT` durch [`OP_CHECKCONTRACTVERIFY`][topic matt] (OP_CCV), ein allgemeineres [Vault][topic vaults]-Design und eine neue Art von [Covenant][topic covenants] ersetzt wurde. +- [BIPs #1848][] aktualisiert den Status von [BIP345][] auf „Withdrawn“, da der Autor [glaubt][obeirne vaultwithdraw], dass der vorgeschlagene Opcode `OP_VAULT` durch [`OP_CHECKCONTRACTVERIFY`][topic matt] (OP_CCV), ein allgemeineres [Vault][topic vaults]-Design und eine neue Art von [Covenant][topic covenants] verdrängt wurde. - [BIPs #1841][] merged [BIP172][], das vorschlägt, die unteilbare Basiseinheit von Bitcoin als „Satoshi“ formell zu definieren, um die aktuelle, weit verbreitete Nutzung widerzuspiegeln und die Terminologie in Anwendungen und Dokumentation zu standardisieren. From a58df174257e931a1590bfad6107fe606a30c271 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Sat, 7 Jun 2025 15:47:09 +0200 Subject: [PATCH 073/278] Update _posts/de/newsletters/2025-05-16-newsletter.md Co-authored-by: garfiel-d --- _posts/de/newsletters/2025-05-16-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/de/newsletters/2025-05-16-newsletter.md b/_posts/de/newsletters/2025-05-16-newsletter.md index cc6b878e04..15aeeda670 100644 --- a/_posts/de/newsletters/2025-05-16-newsletter.md +++ b/_posts/de/newsletters/2025-05-16-newsletter.md @@ -37,7 +37,7 @@ _Neue Veröffentlichungen und Release-Kandidaten für populäre Bitcoin-Infrastr _Wichtige aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und [BINANAs][binana repo]._ -- [Bitcoin Core #32155][] aktualisiert den internen Miner, sodass Coinbase-Transaktionen per [Timelock][topic timelocks] versehen werden, indem das Feld `nLockTime` auf die aktuelle Blockhöhe minus eins gesetzt und das Feld `nSequence` nicht final gesetzt wird (um das Timelock zu erzwingen). Obwohl der eingebaute Miner normalerweise nicht im Mainnet verwendet wird, sollen Mining-Pools durch dieses Update frühzeitig zur Übernahme dieser Änderungen in ihrer eigenen Software motiviert werden – als Vorbereitung auf den vorgeschlagenen [Consensus Cleanup][topic consensus cleanup] Soft Fork ([BIP54][]). Das Timelocking von Coinbase-Transaktionen löst die [Duplicate Transaction][topic duplicate transactions]-Schwachstelle und würde erlauben, die aufwändigen [BIP30][]-Prüfungen zu entfernen. +- [Bitcoin Core #32155][] aktualisiert den internen Miner, sodass Coinbase-Transaktionen mit [Timelocks][topic timelocks] versehen werden, indem das Feld `nLockTime` auf die aktuelle Blockhöhe minus eins gesetzt und das Feld `nSequence` nicht final gesetzt wird (um das Timelock zu erzwingen). Obwohl der eingebaute Miner normalerweise nicht im Mainnet verwendet wird, sollen Mining-Pools durch dieses Update frühzeitig zur Übernahme dieser Änderungen in ihrer eigenen Software motiviert werden – als Vorbereitung auf den vorgeschlagenen [Consensus Cleanup][topic consensus cleanup] Soft Fork ([BIP54][]). Das Timelocking von Coinbase-Transaktionen löst die [Duplicate Transaction][topic duplicate transactions]-Schwachstelle und würde erlauben, die aufwändigen [BIP30][]-Prüfungen zu entfernen. - [Bitcoin Core #28710][] entfernt den verbleibenden Legacy-Wallet-Code, die zugehörige Dokumentation und Tests. Dazu gehören die ausschließlich für Legacy-Wallets bestimmten RPCs wie `importmulti`, `sethdseed`, `addmultisigaddress`, `importaddress`, `importpubkey`, `dumpwallet`, `importwallet` und `newkeypool`. Als letzter Schritt für die Entfernung der Legacy-Wallets werden auch die BerkeleyDB-Abhängigkeit und zugehörige Funktionen entfernt. Das absolute Minimum an Legacy-Code und ein unabhängiger BDB-Parser (siehe Newsletter [#305][news305 bdb]) bleiben jedoch erhalten, um die Migration zu [Descriptor][topic descriptors]-Wallets zu ermöglichen. From 74ac920a42af185076b4d9171dfb6a4430852105 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Sat, 7 Jun 2025 15:47:23 +0200 Subject: [PATCH 074/278] Update _posts/de/newsletters/2025-05-16-newsletter.md Co-authored-by: garfiel-d --- _posts/de/newsletters/2025-05-16-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/de/newsletters/2025-05-16-newsletter.md b/_posts/de/newsletters/2025-05-16-newsletter.md index 15aeeda670..b00242d189 100644 --- a/_posts/de/newsletters/2025-05-16-newsletter.md +++ b/_posts/de/newsletters/2025-05-16-newsletter.md @@ -12,7 +12,7 @@ Der Newsletter dieser Woche beschreibt eine behobene Schwachstelle, die ältere ## Nachrichten - **Offenlegung einer Schwachstelle in alten Versionen von Bitcoin Core:** - Antoine Poinsot [berichtete][poinsot addrvuln] auf der Bitcoin-Dev-Mailingliste über eine Schwachstelle, die Bitcoin Core-Versionen vor 29.0 betrifft. Die Schwachstelle wurde ursprünglich von Eugene Siegel [verantwortungsvoll gemeldet][topic responsible disclosures], zusammen mit einer weiteren, eng verwandten Schwachstelle, die in [Newsletter #314][news314 excess addr] beschrieben wurde. Ein Angreifer konnte eine übermäßige Anzahl von Knoten-Adressanzeigen senden, um einen 32-Bit-Identifier zum Überlaufen zu bringen, was zu einem Absturz des Knotens führte. Dies wurde teilweise dadurch entschärft, dass die Anzahl der Updates auf eins pro Peer alle zehn Sekunden begrenzt wurde, was bei etwa 125 Peers im Standardfall ein Überlaufen nur dann ermöglicht hätte, wenn der Knoten über mehr als 10 Jahre kontinuierlich angegriffen worden wäre. Die Schwachstelle wurde vollständig behoben, indem ab Version 29.0 von Bitcoin Core 64-Bit-Identifier verwendet werden. + Antoine Poinsot [berichtete][poinsot addrvuln] auf der Bitcoin-Dev-Mailingliste über eine Schwachstelle, die Bitcoin Core-Versionen vor 29.0 betrifft. Die Schwachstelle wurde ursprünglich von Eugene Siegel [verantwortungsvoll gemeldet][topic responsible disclosures], zusammen mit einer weiteren, eng verwandten Schwachstelle, die in [Newsletter #314][news314 excess addr] beschrieben wurde. Ein Angreifer konnte eine übermäßige Anzahl von Knoten-Adressanzeigen senden, um einen 32-Bit-Identifier zum Überlaufen zu bringen, was zu einem Absturz des Knotens führte. Dies wurde teilweise dadurch entschärft, dass die Anzahl der Updates auf eines pro Peer alle zehn Sekunden begrenzt wurde, was bei etwa 125 Peers im Standardfall ein Überlaufen nur dann ermöglicht hätte, wenn der Knoten über mehr als 10 Jahre kontinuierlich angegriffen worden wäre. Die Schwachstelle wurde vollständig behoben, indem ab Version 29.0 von Bitcoin Core 64-Bit-Identifier verwendet werden. ## Änderungen am Konsens From 8d4ef39885434b3a490718bf68cead0c2f95792d Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Sun, 8 Jun 2025 19:10:15 +0200 Subject: [PATCH 075/278] Update _posts/de/newsletters/2025-05-16-newsletter.md Co-authored-by: garfiel-d --- _posts/de/newsletters/2025-05-16-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/de/newsletters/2025-05-16-newsletter.md b/_posts/de/newsletters/2025-05-16-newsletter.md index b00242d189..06596b8afb 100644 --- a/_posts/de/newsletters/2025-05-16-newsletter.md +++ b/_posts/de/newsletters/2025-05-16-newsletter.md @@ -27,7 +27,7 @@ _Ein monatlicher Abschnitt mit Zusammenfassungen von Vorschlägen und Diskussion - **Beschreibung der Vorteile für BitVM durch `OP_CTV` und `OP_CSFS`:** Robin Linus [beschrieb][linus bitvm-sf] auf Delving Bitcoin mehrere Verbesserungen für [BitVM][topic acc], die durch die vorgeschlagenen Opcodes [OP_CTV][topic op_checktemplateverify] und [OP_CSFS][topic op_checksigfromstack] per Soft Fork möglich würden. Zu den Vorteilen zählen eine höhere Anzahl von Operatoren ohne Nachteile, „etwa 10-fach kleinere Transaktionen“ (was die Worst-Case-Kosten reduziert) und die Möglichkeit nicht-interaktiver Peg-ins für bestimmte Verträge. -## Veröffentlichungen und Release-Kandidaten +## Releases und Release-Kandidaten _Neue Veröffentlichungen und Release-Kandidaten für populäre Bitcoin-Infrastrukturprojekte. Bitte erwäge, auf neue Releases zu aktualisieren oder Release-Kandidaten zu testen._ From 12ed593cd33b15738cb1647c09aa23f77c6687d6 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Sun, 8 Jun 2025 19:10:20 +0200 Subject: [PATCH 076/278] Update _posts/de/newsletters/2025-05-16-newsletter.md Co-authored-by: garfiel-d --- _posts/de/newsletters/2025-05-16-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/de/newsletters/2025-05-16-newsletter.md b/_posts/de/newsletters/2025-05-16-newsletter.md index 06596b8afb..958a9fc1ed 100644 --- a/_posts/de/newsletters/2025-05-16-newsletter.md +++ b/_posts/de/newsletters/2025-05-16-newsletter.md @@ -29,7 +29,7 @@ _Ein monatlicher Abschnitt mit Zusammenfassungen von Vorschlägen und Diskussion ## Releases und Release-Kandidaten -_Neue Veröffentlichungen und Release-Kandidaten für populäre Bitcoin-Infrastrukturprojekte. Bitte erwäge, auf neue Releases zu aktualisieren oder Release-Kandidaten zu testen._ +_Neue Releases und Release-Kandidaten für populäre Bitcoin-Infrastrukturprojekte. Bitte erwäge, auf neue Releases zu aktualisieren oder Release-Kandidaten zu testen._ - [LND 0.19.0-beta.rc4][] ist ein Release-Kandidat für diesen populären LN-Knoten. Eine der wichtigsten Verbesserungen, die getestet werden sollte, ist das neue RBF-basierte Fee-Bumping für kooperative Channel-Schließungen. From 1f377c3e6eb024b2810c321aa5887fdb2d53c74e Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Tue, 10 Jun 2025 17:55:54 +0200 Subject: [PATCH 077/278] Newsletter 357 german (#2358) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * newsletter-357-german * shorten the line length * change link news353 pr review to en * change from veröffentlichung to releases * Aktualisieren der STYLE-DE: - 1. Konsistenz überprüfen, - 2. bevorzugte Übersetzungen verwenden, - 3. englische Begriffe, die nicht übersetzt wurden. newslette 357 fetch/merge upstream/master * update text --- STYLE-DE.md | 242 +++++++----------- .../de/newsletters/2025-06-06-newsletter.md | 174 +++++++++++++ 2 files changed, 265 insertions(+), 151 deletions(-) create mode 100644 _posts/de/newsletters/2025-06-06-newsletter.md diff --git a/STYLE-DE.md b/STYLE-DE.md index f26aa4323b..3b755c48be 100644 --- a/STYLE-DE.md +++ b/STYLE-DE.md @@ -2,171 +2,111 @@ ## Grundsätzliches -Die deutsche Übersetzung von Optech Inhalten sollte wo immer möglich den Regeln -des englischen [Hauptleitfaden](STYLE.md) folgen. +Die deutsche Übersetzung von Optech-Inhalten sollte möglichst den Regeln des englischen [Hauptleitfaden](STYLE.md) folgen. + +--- ## Abschnittsüberschriften (Standardübersetzungen) -| Englisch | Deutsch | -|-------------------------------------------|----------------------------------------------| -| News | Nachrichten | -| Changes to services and client software | Änderungen an Diensten und Client-Software | -| Releases and release candidates | Veröffentlichungen und Release-Kandidaten | -| Notable code and documentation changes | Wichtige Code- und Dokumentationsänderungen | -| Selected Q&A from Bitcoin Stack Exchange | Ausgewählte Fragen & Antworten von Bitcoin Stack Exchange | -| Correction | Korrektur | -| Consensus changes | Konsensänderungen | +| Englisch | Deutsch | +|------------------------------------------|-----------------------------------------------------------| +| News | Nachrichten | +| Changes to services and client software | Änderungen an Diensten und Client-Software | +| Releases and release candidates | Releases und Release-Kandidaten | +| Notable code and documentation changes | Wichtige Code- und Dokumentationsänderungen | +| Selected Q&A from Bitcoin Stack Exchange | Ausgewählte Fragen & Antworten von Bitcoin Stack Exchange | +| Correction | Korrektur | +| Consensus changes | Konsensänderungen | + +--- ## Vokabular ### Eigennamen -Wie im Hauptleitfaden beschrieben, werden auch in der deutschen Übersetzung -Eigennamen groß geschrieben. +Eigennamen werden wie im Hauptleitfaden groß geschrieben. ### Gebräuchliche Substantive -Anders als im Englischen, wird, mit Ausnahme der unten aufgelisteten Begriffe, -der erste Buchstabe von gebräuchlichen Substantiven groß geschrieben. +Im Deutschen werden Substantive groß geschrieben. - Bech32 - Bitcoin (die Währung) - BIPxxx -### Abkürzungen - -Siehe [Hauptleitfaden](STYLE.md). - -#### Nicht eingeführte Abkürzungen - -Siehe [Hauptleitfaden](STYLE.md). - -#### Unzulässige Begriffe und Abkürzungen - -Siehe [Hauptleitfaden](STYLE.md). - ### Zusammengesetzte Begriffe -Zusammengesetzte Fremdwörter sollten, zwecks besserer Lesbarkeit, nach -Möglichkeit mit Bindestrich geschrieben werden. Siehe dazu auch [Duden, D41](https://www.duden.de/sprachwissen/rechtschreibregeln/fremdwoerter#D41) - -### Rechtschreibung - -Übersetzungen sollten den Regeln der neuen deutschen Rechtschreibung folgen. - -### Bevorzugte Begriffe für deutsche Übersetzung - -Wo sinnvoll und verständnisfördernd sollten Fachbegriffe nur dann übersetzt, -und Fremd- bzw. Lehnwörter nur dann verwendet werden, wenn sich diese in der -deutschen Bitcoin-Szene etabliert haben. Für einige Begriffe werden folgende -Übersetzungen bevorzugt: - -| Englischer Ausdruck | Bevorzugt | Zu vermeiden | Anmerkungen | -|-----------------------------------|-------------------------------|----------------------|-------------------------------------------| -| blinded transaction | verdeckte Zahlung | | | -| Countersign | Countersign | | Eigenname des Verfahrens | -| channel | Channel | Kanal | | -| derivation path | Ableitungspfad | | | -| descriptor | Deskriptor | | | -| dual funding | beidseitige Finanzierung | | | -| fee | Gebühr | | | -| funds | Kapital | | | -| HTLC | | | Genus Maskulinum | -| lightning network | Lightning Netzwerk | | | -| node | Knoten | Node | Full Node wird nicht übersetzt | -| relay | Weiterleitung | | | -| silent payment | Stille Zahlung | | | -| UTXO | | | Genus Maskulinum | -| wallet | Wallet | Geldbörse | Genus Neutrum | -| work | Arbeitsnachweis | Arbeit | Im Kontext von PoW | -| nothing up my sleeve (NUMS)-Punkt | | | | -| Scriptpath | | | | -| Tapleaf | | | | -| Tapscript | | | | -| Orakel-Bestätigung | | | | -| Timelock | | | | -| non-custodial | non-custodial | nicht-verwahrt | ist im deutschsprachigen Raum etablierte | - -### Nicht übersetzte Begriffe - -#### Mining und Pool-Begriffe - -| Englischer Ausdruck | Begründung | -|-------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------| -| Pool-Miner | ist ein etablierter Fachbegriff | -| Mining | etablierter Fachbegriff | -| Pool | etablierter Fachbegriff | -| E-Cash-Shares | wurde von "E-Cash-Anteile" korrigiert | -| Pay-per-Last-N-Shares | technischer Begriff | -| PPLNS | "Pay-Per-Last-N-Shares", ein Auszahlungssystem bei Mining-Pools, bei dem die letzten N Shares für die Berechnung der Auszahlung verwendet werden | -| TIDES | Name des Systems | -| FPPS | "Full Pay-Per-Share", ein Auszahlungssystem, das die volle Blockbelohnung (inkl. Gebühren) pro Share auszahlt | -| Proxy | technischer Begriff | - -#### Lightning Network & DLC Begriffe - -| Englischer Ausdruck | Begründung | -|-------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------| -| LN | "Lightning Network", ein Layer-2-Protokoll für schnelle Bitcoin-Transaktionen | -| DLC | "Discreet Log Contract", ein Protokoll für Bitcoin-basierte Smart Contracts | -| Offchain | beschreibt Transaktionen außerhalb der Blockchain | -| On-Chain | beschreibt Transaktionen auf der Blockchain | -| HTLC | "Hash Time-Locked Contract", ein Vertragskonstrukt für sichere Zahlungsweiterleitung im Lightning Network | -| Oracle | technischer Begriff | -| Simple Taproot Channels | Lightning Network Typ | - -#### Software & Entwicklung - -| Englischer Ausdruck | Begründung | -|-------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------| -| Release | etablierter Begriff | -| Release-Kandidaten | teilweise etablierter Begriff | -| LDK | "Lightning Development Kit", eine Bibliothek zur Entwicklung von Lightning-Network-Anwendungen | -| Wallet | etablierter Begriff | -| LSPS | "Lightning Service Provider Specification", ein Standard für Lightning Network Dienstleister | -| Human Readable Names | technischer Begriff | -| Core Lightning | Produktname | -| Eclair | Produktname | -| BTCPay Server | Produktname | -| BDK | Produktname | -| Rust Bitcoin | Produktname | -| PR | "Pull Request", eine Funktion von Git/GitHub, bei der ein Entwickler eine Änderung an einem Repository vorschlägt | - -#### Protokolle & Standards - -| Englischer Ausdruck | Begründung | -|-------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------| -| BIP | "Bitcoin Improvement Proposal", standardisierte Vorschläge zur Verbesserung des Bitcoin-Protokolls | -| BOLT | "Basis of Lightning Technology", die technischen Spezifikationen des Lightning Networks | -| BLIP | "Bitcoin Lightning Improvement Proposal", Verbesserungsvorschläge für das Lightning Network | -| PSBT | "Partially Signed Bitcoin Transaction", ein Format für teilweise signierte Bitcoin-Transaktionen | -| DLEQ | "Discrete Logarithm Equality", ein kryptographischer Beweis für die Gleichheit diskreter Logarithmen | -| Splice | technischer Begriff | -| Short Channel Identifier(SCID)| technischer Begriff | -| BIP331 | Abkürzung für ein spezifisches Bitcoin Improvement Proposal | -| OP_CHECKTEMPLATEVERIFY (CTV) | spezifischer Opcode im Bitcoin-Protokoll | -| CTV | "Check Template Verify", siehe oben OP_CHECKTEMPLATEVERIFY | - -#### Plattformen & Listen - -| Englischer Ausdruck | Begründung | -|-------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------| -| Delving Bitcoin | Name der Plattform | -| DLC-Dev | Name der Mailingliste | - -#### Entwicklungsbegriffe - -| Englischer Ausdruck | Begründung | -|-------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------| -| merged | Git/GitHub Terminologie | - -### Maßeinheiten - -Siehe [Hauptleitfaden](STYLE.md). - -### Nicht zu übersetzende Begriffe und Ausnahmen - -| Englischer Ausdruck | Nicht übersetzen, wenn ... | Beispiel/Anmerkung | -|----------------------|-----------------------------------------------------------------|----------------------------------------------------| -| Full Node /Full Nodes| immer | Nicht als "Vollknoten" übersetzen | -| output / input | im Zusammenhang mit UTXO (z.B. "UTXO output", "UTXO input") | Nicht als "Ausgabe/Eingabe" übersetzen | -| non-custodial | immer | Nicht als "nicht-verwahrt" übersetzen | \ No newline at end of file + +Fremdwörter möglichst mit Bindestrich schreiben (siehe [Duden, D41](https://www.duden.de/sprachwissen/rechtschreibregeln/fremdwoerter#D41)). + + +## Bevorzugte Begriffe für deutsche Übersetzung + +| Englisch | Bevorzugt (DE) | Zu vermeiden | Anmerkung/Kommentar | +|-------------------------|--------------------------|----------------------|------------------------------------------| +| blinded transaction | verdeckte Zahlung | | | +| derivation path | Ableitungspfad | | | +| descriptor | Deskriptor | | | +| dual funding | beidseitige Finanzierung | | | +| fee | Gebühr | | | +| funds | Kapital | | | +| lightning network | Lightning Netzwerk | | | +| node | Knoten | Node | Full Node wird nicht übersetzt | +| relay | Weiterleitung | | | +| silent payment | Stille Zahlung | | | +| work | Arbeitsnachweis | Arbeit | Im Kontext von PoW | + +--- + +## Nicht übersetzte Begriffe und Ausnahmen + +| Englischer Ausdruck | Kontext / Anmerkung | +|------------------------------- |-----------------------------------------------------| +| BDK | Produktname | +| BIP(mit nummer) | Protokoll-/Standardbegriff | +| BLIP | Protokoll-/Standardbegriff | +| BTCPay Server | Produktname | +| Channel | Etablierter Fachbegriff | +| Core Lightning | Produktname | +| Countersign | Eigenname des Verfahrens | +| Delving Bitcoin | Plattform-/Listenname | +| DLC | Layer-2/Smart-Contract/Transaktionsbegriff | +| DLC-Dev | Plattform-/Listenname | +| E-Cash-Shares | Korrigiert von "E-Cash-Anteile" | +| Eclair | Produktname | +| FPPS | Technischer Begriff/Auszahlungssystem | +| Full Node / Full Nodes | Immer im Original belassen | +| HTLC | Immer im Original belassen | +| Human Readable Names | Produkt-/Technikname | +| LDK | Produkt-/Technikname | +| LN | Layer-2/Smart-Contract/Transaktionsbegriff | +| LSPS | Produkt-/Technikname | +| Mining | Etablierter Fachbegriff | +| On-Chain | Layer-2/Smart-Contract/Transaktionsbegriff | +| OP_CHECKTEMPLATEVERIFY (CTV) | Protokoll-/Standardbegriff | +| Oracle | Lightning/DLC-Technik | +| output / input (bei UTXO) | Nur im UTXO-Kontext nicht übersetzen | +| Pay-per-Last-N-Shares | Technische Begriffe/Auszahlungssysteme | +| Pool | Etablierter Fachbegriff | +| Pool-Miner | Etablierter Fachbegriff | +| PR | Git/GitHub-Terminologie | +| Proxy | Technischer Begriff | +| PSBT | Protokoll-/Standardbegriff | +| PPLNS | Technischer Begriff/Auszahlungssystem | +| Release | Softwarebegriff | +| Releases | Softwarebegriff | +| Rust Bitcoin | Produktname | +| SCID | Protokoll-/Standardbegriff | +| Simple Taproot Channels | Lightning/DLC-Technik | +| Splice | Protokoll-/Standardbegriff | +| TIDES | Name des Systems | +| UTXO | Immer im Original belassen | +| Wallet | Produkt-/Technikname | +| merged | Git/GitHub-Terminologie | +| non-custodial | Immer im Original belassen, ist etabliert | +| Offchain | Layer-2/Smart-Contract/Transaktionsbegriff | + +--- + +## Maßeinheiten + +Siehe [Hauptleitfaden](STYLE.md). \ No newline at end of file diff --git a/_posts/de/newsletters/2025-06-06-newsletter.md b/_posts/de/newsletters/2025-06-06-newsletter.md new file mode 100644 index 0000000000..28fe40cf2c --- /dev/null +++ b/_posts/de/newsletters/2025-06-06-newsletter.md @@ -0,0 +1,174 @@ +--- +title: 'Bitcoin Optech Newsletter #357' +permalink: /de/newsletters/2025/06/06/ +name: 2025-06-06-newsletter-de +slug: 2025-06-06-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche enthält eine Analyse zum Synchronisieren von Full Nodes +ohne alte Witness-Daten. Ebenfalls enthalten sind unsere regulären Abschnitte mit +Beschreibungen von Diskussionen zu Konsensänderungen, Ankündigungen neuer +Releases und Release-Kandidaten sowie Zusammenfassungen wichtiger +Änderungen an populärer Bitcoin-Infrastruktur. + +## Nachrichten + +- **Synchronisation von Full Nodes ohne Witness-Daten:** + Jose SK [veröffentlichte][sk nowit] auf Delving Bitcoin eine Zusammenfassung einer + [Analyse][sk nowit gist], in der er die Sicherheitsabwägungen untersucht, wenn neu + gestartete Full Nodes mit einer bestimmten Konfiguration auf das Herunterladen einiger + historischer Blockchain-Daten verzichten. Standardmäßig verwenden Bitcoin-Core-Knoten die + `assumevalid`-Konfiguration. Diese überspringt die Validierung von Scripts in Blöcken, + die mehr als ein oder zwei Monate vor der aktuell ausgeführten Version von Bitcoin Core + erstellt wurden. Viele Nutzer aktivieren außerdem die `prune`-Option, die Blöcke nach der + Validierung nach einer gewissen Zeit löscht. Wie lange Blöcke aufbewahrt werden, + hängt von der Blockgröße und der gewählten Einstellung ab. + + SK argumentiert, dass Witness-Daten, die nur zur Script-Validierung benötigt werden, + von geprunten Knoten für assumevalid-Blöcke nicht heruntergeladen werden sollten, + da sie nicht zur Script-Validierung genutzt und später ohnehin gelöscht werden. + Das Überspringen des Witness-Downloads „kann den Bandbreitenverbrauch um über 40 % + reduzieren“, schreibt er. + + Ruben Somsen [argumentiert][somsen nowit], dass dies das Sicherheitsmodell in gewissem + Maße verändert. Auch wenn Scripts nicht validiert werden, wird die heruntergeladene + Datenmenge gegen das Commitment vom Blockheader-Merkel-Root zur Coinbase-Transaktion + bis zu den Witness-Daten geprüft. Das stellt sicher, dass die Daten zum Zeitpunkt der + ersten Synchronisation verfügbar und unverfälscht waren. Wenn jedoch niemand regelmäßig + die Existenz dieser Daten prüft, könnten sie verloren gehen – wie es + [bei mindestens einem Altcoin][ripple loss] bereits passiert ist. + + Die Diskussion war zum Zeitpunkt des Schreibens noch im Gange. + +## Änderungen am Konsens + +_Ein monatlicher Abschnitt mit Zusammenfassungen von Vorschlägen und Diskussionen zu Änderungen der Bitcoin-Konsensregeln._ + +- **Bericht zu Quantencomputing:** Clara Shikhelman [veröffentlichte][shikelman quantum] + auf Delving Bitcoin die Zusammenfassung eines [Berichts][sm report], den sie gemeinsam + mit Anthony Milton verfasst hat. Darin geht es um Risiken für Bitcoin-Nutzer durch schnelle + Quantencomputer, einen Überblick über verschiedene Wege zur + [Quantenresistenz][topic quantum resistance] und eine Analyse der Abwägungen bei einer + Protokollumstellung. Die Autoren schätzen, dass 4 bis 10 Millionen BTC potenziell durch + Quantenangriffe gefährdet sind, einige Maßnahmen bereits jetzt möglich sind, Bitcoin-Mining + kurzfristig und mittelfristig aber nicht bedroht ist und ein Upgrade breite Zustimmung erfordert. + +- **Transaktionsgewicht-Limit mit Ausnahme zur Vermeidung von Konfiskation:** Vojtěch Strnad + [schlug][strnad limit] auf Delving Bitcoin eine Konsensänderung vor, die das maximale + Gewicht der meisten Transaktionen in einem Block begrenzt. Die einfache Regel: + Nur wenn eine Transaktion (außer der Coinbase) die einzige im Block ist, darf + sie größer als 400.000 Weight Units (100.000 vbytes) sein. Strnad und andere + nannten folgende Gründe für diese Begrenzung: + + - _Einfachere Blocktemplate-Optimierung:_ Je kleiner die einzelnen Transaktionen + im Vergleich zum Gesamtlimit sind, desto leichter lässt sich eine nahezu optimale + Lösung für das [Knapsack-Problem][knapsack problem] finden. Dadurch bleibt weniger + Platz ungenutzt. + + - _Einfachere Relay-Policy:_ Die Policy für das Weiterleiten unbestätigter + Transaktionen zwischen Knoten sagt vorher, welche Transaktionen gemined werden. + Sehr große Transaktionen erschweren diese Vorhersage, da schon kleine Änderungen + an der Top-Feerate zu Verzögerungen oder zum Entfernen führen können. + + - _Vermeidung von Mining-Zentralisierung:_ Wenn relayende Full Nodes fast alle + Transaktionen weiterleiten können, müssen Nutzer spezieller Transaktionen keine + [Out-of-Band-Fees][topic out-of-band fees] zahlen, was Mining-Zentralisierung + verhindern hilft. + + Gregory Sanders [merkte an][sanders limit], dass es auch sinnvoll sein könnte, + einfach per Soft Fork ein maximales Gewichtslimit ohne Ausnahmen einzuführen, + da Bitcoin Core seit 12 Jahren eine konsistente Relay-Policy hat. Gregory Maxwell + [fügte hinzu][maxwell limit], dass Transaktionen, die nur UTXOs ausgeben, die vor + dem Soft Fork entstanden sind, eine Ausnahme erhalten könnten, um Konfiskation zu + verhindern. Ein [transitorischer Soft Fork][topic transitory soft forks] + könnte die Einschränkung zudem automatisch auslaufen lassen, falls die + Community sie nicht verlängern möchte. + + Weitere Diskussionen befassten sich mit den Bedürfnissen von Nutzern großer + Transaktionen, insbesondere [BitVM][topic acc], und möglichen Alternativen. + +- **Entfernen von Outputs aus dem UTXO-Set basierend auf Wert und Zeit:** Robin Linus + [schlug][linus dust] auf Delving Bitcoin einen Soft Fork vor, um Outputs mit geringem + Wert nach einer gewissen Zeit aus dem UTXO-Set zu entfernen. Diskutiert wurden zwei + Hauptvarianten: + + - _Alte, unwirtschaftliche Funds zerstören:_ Kleine Outputs, die lange nicht + ausgegeben wurden, werden unspendable. + + - _Alte, unwirtschaftliche Funds nur mit Existenzbeweis ausgeben:_ + [utreexo][topic utreexo] oder ein ähnliches System könnte genutzt werden, + damit Transaktionen beweisen können, + dass die ausgegebenen Outputs Teil des UTXO-Sets sind. Alte und + [unwirtschaftliche Outputs][topic uneconomical outputs] müssten diesen Beweis liefern, + neuere und höherwertige Outputs würden weiterhin im UTXO-Set gespeichert. + + Beide Lösungen würden die maximale Größe des UTXO-Sets effektiv begrenzen + (bei Mindestwert und 21 Millionen Bitcoin). Es wurden verschiedene technische + Aspekte und Alternativen zu utreexo-Proofs für diesen Anwendungsfall diskutiert. + +## Releases und Release-Kandidaten + +_Neue Releases und Release-Kandidaten für populäre Bitcoin-Infrastrukturprojekte. +Bitte erwäge, auf neue Releases zu aktualisieren oder Release-Kandidaten zu testen._ + +- [Core Lightning 25.05rc1][] ist ein Release-Kandidat für die nächste Hauptversion dieser +beliebten LN-Knoten-Implementierung. + +- [LND 0.19.1-beta.rc1][] ist ein Release-Kandidat für eine Wartungsversion dieser +beliebten LN-Knoten-Implementierung. + +## Wichtige Code- und Dokumentationsänderungen + +_Bemerkenswerte aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], +[Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], +[libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], +[Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], +[Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und [BINANAs][binana repo]._ + +- [Bitcoin Core #32582][] fügt neues Logging hinzu, um die Performance der +[Compact-Block-Rekonstruktion][topic compact block relay] zu messen: Es werden die +Gesamtgröße der von Peers angeforderten Transaktionen (`getblocktxn`), die Anzahl und +Gesamtgröße der an Peers gesendeten Transaktionen (`blocktxn`) sowie ein Timestamp am Start von +`PartiallyDownloadedBlock::InitData()` geloggt, um die Dauer des Mempool-Lookups zu messen +(sowohl im High- als auch im Low-Bandwidth-Modus). Siehe Newsletter [#315][news315 compact] +für einen früheren Statistikbericht zur Compact-Block-Rekonstruktion. + +- [Bitcoin Core #31375][] fügt ein neues CLI-Tool `bitcoin -m` hinzu, das die +[Multiprozess][multiprocess project]-Binaries `bitcoin node` (`bitcoind`), +`bitcoin gui` (`bitcoinqt`), `bitcoin rpc` (`bitcoin-cli -named`) kapselt und ausführt. +Aktuell funktionieren diese wie die monolithischen Binaries, unterstützen aber die Option +`-ipcbind` (siehe Newsletter [#320][news320 ipc]). Zukünftige Verbesserungen werden es ermöglichen, +Knoten-Komponenten unabhängig auf verschiedenen Maschinen und Umgebungen zu starten und zu stoppen. +Siehe [Newsletter #353][news353 pr review] für einen Bitcoin Core PR Review Club zu diesem PR. + +- [BIPs #1483][] merged [BIP77][], das [Payjoin v2][topic payjoin] vorschlägt – eine asynchrone, +serverlose Variante, bei der Sender und Empfänger ihre verschlüsselten PSBTs an einen +Payjoin-Directory-Server übergeben, der nur Nachrichten speichert und weiterleitet. +Da das Directory die Payloads weder lesen noch verändern kann, muss keine Wallet einen öffentlichen +Server betreiben oder gleichzeitig online sein. Siehe Newsletter [#264][news264 payjoin] +für weitere Informationen zu Payjoin v2. + +{% include snippets/recap-ad.md when="2025-06-10 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32582,31375,1483" %} +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[ripple loss]: https://x.com/JoelKatz/status/1919233214750892305 +[sk nowit]: https://delvingbitcoin.org/t/witnessless-sync-for-pruned-nodes/1742/ +[sk nowit gist]: https://gist.github.com/JoseSK999/df0a2a014c7d9b626df1e2b19ccc7fb1 +[somsen nowit]: https://gist.github.com/JoseSK999/df0a2a014c7d9b626df1e2b19ccc7fb1?permalink_comment_id=5597316#gistcomment-5597316 +[shikelman quantum]: https://delvingbitcoin.org/t/bitcoin-and-quantum-computing/1730/ +[sm report]: https://chaincode.com/bitcoin-post-quantum.pdf +[strnad limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/ +[knapsack problem]: https://en.wikipedia.org/wiki/Knapsack_problem +[sanders limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/2 +[maxwell limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/4 +[linus dust]: https://delvingbitcoin.org/t/dust-expiry-clean-the-utxo-set-from-spam/1707/ +[lnd 0.19.1-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.1-beta.rc1 +[news315 compact]: /en/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction +[multiprocess project]: https://github.com/ryanofsky/bitcoin/blob/pr/ipc/doc/design/multiprocess.md +[news320 ipc]: /en/newsletters/2024/09/13/#bitcoin-core-30509 +[news264 payjoin]: /en/newsletters/2023/08/16/#serverless-payjoin +[news353 pr review]: /de/newsletters/2025/05/09/#bitcoin-core-pr-review-club From 3d7ec0969298861fa16f3d18e1608c64ec16d8ff Mon Sep 17 00:00:00 2001 From: editor-Ajian <34365188+editor-Ajian@users.noreply.github.com> Date: Wed, 11 Jun 2025 12:31:54 +0800 Subject: [PATCH 078/278] translate newsletter#356 into zh-cn (#169) * translate newsletter#356 into zh-cn * fix typo & style * fix a typo --------- Co-authored-by: Zhiwei(Jeffrey) Hu --- .../zh/newsletters/2025-05-30-newsletter.md | 94 +++++++++++++++++++ 1 file changed, 94 insertions(+) create mode 100644 _posts/zh/newsletters/2025-05-30-newsletter.md diff --git a/_posts/zh/newsletters/2025-05-30-newsletter.md b/_posts/zh/newsletters/2025-05-30-newsletter.md new file mode 100644 index 0000000000..f234327fdf --- /dev/null +++ b/_posts/zh/newsletters/2025-05-30-newsletter.md @@ -0,0 +1,94 @@ +--- +title: 'Bitcoin Optech Newsletter #356' +permalink: /zh/newsletters/2025/05/30/ +name: 2025-05-30-newsletter-zh +slug: 2025-05-30-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- + +本周的新闻部分总结了一段关于故障可归因机制对闪电网络隐私性的可能影响的讨论。此外是我们的常规栏目：来自 Bitcoin Stack Exchange 网站的精选问答、软件的新版本和候选版本发行公告，还有热门的比特币基础设施软件的近期变更的讲解。 + +## 新闻 + +- **故障归因机制会削弱闪电网络的隐私性吗？**Carla Kirk-Cohen 在 Delving Bitcoin 论坛[发布][kirkcohen af]了一份分析，讨论了如果闪电网络采用了故障归因机制（[attributable failures][topic attributable failures]）（尤其是告知发送者转发支付的每一跳花费了多少时间），对发送者和接收者的隐私性可能有什么样的影响。她引用了多份论文，介绍了两种去匿名化攻击： + + * 攻击者操作一个或多个转发节点，使用时机数据来确定一笔支付（[HTLC][topic htlc]）使用了多少跳；再结合对公开网络的拓扑的知识，就可以缩小可能的接收者的范围。 + + * 攻击者使用一个 IP 网络流量转发器（自治系统，[autonomous system][]）从而被动地监控流量，然后结合对节点之间 IP 网络时延知识（比如说它们的 ping 时间）以及对闪电网络公开拓扑（以及其它特征）的知识。 + + 然后，她介绍了可能的解决方案，包括： + + * 鼓励接收者以随机的短时间延迟来接受一个 HTLC，从而防止尝试定位接收者节点的时机攻击尝试。 + + * 鼓励发送者以随机的短时间延迟来推迟重新发送失败的交易（或者 “多路径支付（[MPP][topic multipath payments]）” 的碎片）、并使用替代性路径，以防止尝试定位发送者节点的时机攻击和故障攻击。 + + * 增加 MPP 中的支付碎片数量，让花费数额的猜测变得更困难。 + + * 允许发送者选择性让自己的支付转发慢一些，如之前的提议（详见[周报 #208][news208 slowln]）。这可以跟 HTLC 批处理相结合，后者在 LND 中已经实现了（虽然加入随机的时延依然能增强隐私性）。 + + * 降低故障归因中的时间戳的精度，以避免惩罚添加了随机短时延的转发节点。 + + 来自多位参与者的讨论更细致地评估了担忧事项和作者所提议的解决方案，还考虑了其它可能的攻击和缓解措施。 + +## 来自 Bitcoin Stack Exchange 的精选问答 + +*[Bitcoin Stack Exchange][bitcoin.se] 是 Optech 的贡献者们有困惑时寻找答案的首选之地，也是他们有闲暇时会帮助好奇和困惑用户的地方。在这个月度栏目中，我们会列出自上次出刊以来出现的一些高票的问题和回答。* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [哪些交易会进入 blockreconstructionextratxn？]({{bse}}116519) Glozow 解释了 extrapool 数据结构是如何缓存被节点拒绝的交易和节点观察到的替换交易的（详见[周报 #339][news339 extrapool]），并列出了排除交易和驱逐交易的依据。 + +- [除了交易手续费因素外，为什么人们会使用 OP_RETURN 而非铭文？]({{bse}}126208) Sjors Provoost 指出，除了有些时候 `OP_RETURN` 更加便宜之外，它还能用在需要保证数据在交易被花费前可得的协议中，而铭刻（inscriptions）用到了见证数据，在花费交易中才会公开。 + +- [为什么我的比特币节点收不到入站连接？]({{bse}}126338) Lightlike 指出，刚加入网络的节点可能需要一些时间才能将自己的网络地址广泛告知给 P2P 网络，而且，在初始化区块下载还未完成之前，节点是不会广告自己的地址的。 + +- [有办法配置我的节点过滤掉体积大于 400 字节的交易吗？]({{bse}}126347) Antoine Poinsot 确认了，Bitcoin Core 中没有配置选项可以定制化设定标准交易的体积上限。他指出，希望定制化这个数值的用户可以修改软件的源代码，但提醒了过大或过小的交易体积上限会带来的可能缺点。 + +- [Bitcoin Core 点对点连接中的 “不可公开路由的” 节点是什么意思？]({{bse}}126225) Pieter Wuille 和 Vasil Dimov 提供了不能在全球互联网中路由的 P2P 连接（例如 [Tor][topic anonymity networks]）的例子，以及出现在 Bitcoin Core 的 “npr” 桶中的 `netinfo` 输出中的例子。 + +- [节点究竟为什么要转发交易呢？]({{bse}}127391) Pieter Wuille 列出了转发交易对节点操作者的好处：隐私性（在你使用自己的节点转发自己的交易时就体现出来）、更快的区块传播速度（如果用户挖矿的话），以及提升网络的去中心化；在转发区块的基础成本之上，只需极小的增量成本，就可以获得这些好处。 + +- [有了致密区块和 FIBRE，“自私挖矿” 依然是可行的攻击吗？]({{bse}}49515) Antoine Poinsot 回答这个于 2016 年提出的问题时指出，“没错，自私挖矿依然是一种可行的策略，即使区块传播速度已经得到提升。断定自私挖矿只在理论上能够成立是不正确的。”他也附带了一个他创建的[挖矿模拟器][miningsimulation github]。 + +## 软件的新版本和候选版本 + +*热门的比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本。* + +- [Core Lightning 25.05rc1][] 是一个这个流行的闪电节点实现的下一个主要版本的候选发行。 + +- [LDK 0.1.3][] 和 [0.1.4][ldk 0.1.4] 是这个用于构建闪电网络赋能应用的热门库的新版本。0.1.3 版本的发布时间是上个月，但本周才在 GitHub 上标记发行，包含了漏洞修复。0.1.4 版本是最新版本，“修复了一个在极其罕见的情形中会导致资金被盗的漏洞”。两个版本都包含了其它 bug 修复。 + +## 显著的代码和说明书变更 + +*本周出现重大变更的有：[Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement Proposals (BIPs)][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo]。* + +- [BINANAs][binana repo] 向 [PSBTs][topic psbt] 添加了一种签名哈希模式（sighash）类型字段，用在 sighash 不是 `SIGHASH_DEFAULT` 和 `SIGHASH_ALL` 的时候。[MuSig2][topic musig] 要求每个签名人都使用相同的签名哈希模式，所以这个字段必须出现在 PSBT 中。此外，`descriptorprocesspsbt` RPC 命令更新成使用 `SignPSBTInput` 函数，这保证了 PSBT 的签名哈希类型与在命令行中提供的一致（如果有的话）。 + +- [Eclair #3065][] 添加了对故障归因机制（详见周报 [#224][news224 failures]）的支持，如 [BOLTs #1044][] 所述。在默认设置中这是禁用的，因为其规范尚未敲定，但可以通过设定 `eclair.features.option_attributable_failure = optional` 来启用。与 LDK 的交叉兼容性已经测试成功；关于 LDK 的实现以及这个协议如何工作，详见周报 [#349][news349 failures]。 + +- [LDK #3796][] 收紧了通道余额检查，从而让注资者拥有充分的资金来覆盖承诺交易的手续费以及两个价值 330 聪的[锚点输出][topic anchor outputs]，以及通道保证金。以前，注资者可以动用通道保证金来生成两个锚点输出。 + +- [BIPs #1760][] 合并了 [BIP53][]，该 BIP 详述了一种共识软分叉规则，会禁用 64 字节长的交易（以不含见证数据的形态度量），以禁止一种针对 SPV 客户端的可利用的[默克尔树漏洞][topic merkle tree vulnerabilities]。这一 PR 提出了一种跟[“共识清理” 软分叉][topic consensus cleanup]所包含的一种修复措施类似的做法。 + +- [BIPs #1850][] 逆转了早前对 [BIP48][] 的一项更新，该更新将 “脚本类型” 的数值 “3” 保留给 [taproot][topic taproot]（P2TR）的变种（详见周报 [#353][news353 bip48]）。这是因为 [tapscript][topic tapscript] 没有 `OP_CHECKMULTISIG` 操作码，所以 [BIP67][] 中的参考输出脚本（也正是 [BIP48][] 所依赖的）并不能用 P2TR 表达出来。这一 PR 也将 [BIP48][] 的状态标记为 `Final`（定稿），反映出它的目的与引入它的时候保持不变 —— 定义 `m/48’` [HD 钱包][topic bip32]派生路径的行业用法，而不是规定新的行为。 + +- [BIPs #1793][] 合并了 [BIP443][]，该 BIP 提议了 [OP_CHECKCONTRACTVERIFY][topic matt]（OP_CCV）操作码，以允许检查一个公钥（不论来自输出还是输入）承诺了一段任意的数据。回顾周报 [#348][news348 op_ccv] 以了解这种[限制条款][topic covenants] 提议的更多信息。 + +{% include references.md %} +{% include linkers/issues.md v=2 issues="31622,3065,3796,1760,1850,1793,1044" %} + +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[ldk 0.1.3]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.1.3 +[ldk 0.1.4]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.1.4 +[news208 slowln]: /zh/newsletters/2022/07/13/#allowing-deliberately-slow-ln-payment-forwarding +[autonomous system]: https://zh.wikipedia.org/wiki/%E8%87%AA%E6%B2%BB%E7%B3%BB%E7%BB%9F +[kirkcohen af]: https://delvingbitcoin.org/t/latency-and-privacy-in-lightning/1723 +[news224 failures]: /zh/newsletters/2022/11/02/#ln-routing-failure-attribution +[news349 failures]: /zh/newsletters/2025/04/11/#ldk-2256 +[news353 bip48]: /zh/newsletters/2025/05/09/#bips-1835 +[news348 op_ccv]: /zh/newsletters/2025/04/04/#op-checkcontractverify-semantics +[news339 extrapool]: /zh/newsletters/2025/01/31/#updated-stats-on-compact-block-reconstruction +[miningsimulation github]: https://github.com/darosior/miningsimulation From eaf4d97e85ef59c3eed8974dbc09a8d493292a1e Mon Sep 17 00:00:00 2001 From: BitTom Date: Wed, 11 Jun 2025 21:28:39 +0800 Subject: [PATCH 079/278] Newsletter-187: translate into Chinese (#2334) --- .../zh/newsletters/2022-02-16-newsletter.md | 57 +++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 _posts/zh/newsletters/2022-02-16-newsletter.md diff --git a/_posts/zh/newsletters/2022-02-16-newsletter.md b/_posts/zh/newsletters/2022-02-16-newsletter.md new file mode 100644 index 0000000000..9a78cb9625 --- /dev/null +++ b/_posts/zh/newsletters/2022-02-16-newsletter.md @@ -0,0 +1,57 @@ +--- +title: 'Bitcoin Optech Newsletter #187' +permalink: /zh/newsletters/2022/02/16/ +name: 2022-02-16-newsletter-zh +slug: 2022-02-16-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的 Newsletter 描述了围绕比特币契约的持续讨论，并包含我们常规的版块，概述了服务和客户端软件的变化，以及流行比特币基础设施软件的值得注意的变更。 + +## 新闻 + +- ******简化版 `OP_TXHASH` 的替代方案：** 在关于启用[契约][topic covenants]的操作码（参见 [Newsletter #185][news185 composable]）的持续讨论中，Rusty Russell [提议][russell op_tx]，`OP_TXHASH` 所提供的功能可以通过现有的 `OP_SHA256` 操作码加上一个新的 `OP_TX` 操作码来实现，后者接受与 `OP_TXHASH` 相同的输入。新的操作码会将支出交易中的序列化字段暴露给 [tapscript][topic tapscript]。脚本随后可以直接检测这些字段（例如：交易版本号是否大于 1？），或者对数据进行哈希并与此前提议的 [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] 操作码验证的签名进行比较。 + +## 服务与客户端软件的变更 + +*在这个每月专栏中，我们会重点介绍比特币钱包和服务的有趣更新。* + +- ******Blockchain.com Wallet 新增 taproot 发送功能：** Android 版 Blockchain.com Wallet 的 [v202201.2.0(18481)][blockchain.com v202201.2.0(18481)] 现已支持向 [bech32m][topic bech32] 地址发送。在撰写本文时，iOS 版本尚未支持向 bech32m 地址发送。 + +- ******Sensei 闪电网络节点实现发布：** 处于 beta 阶段的 [Sensei][sensei website] 基于 [Bitcoin Dev Kit (BDK)][bdk website] 与 [Lightning Dev Kit (LDK)][ldk website] 构建。目前该节点需要 Bitcoin Core 与 Electrum Server，未来计划支持更多后端选项。 + +- ******BitMEX 新增 taproot 发送功能：** BitMEX 在最近的[博客文章][bitmex blog]中宣布已支持 bech32m 提现。文章还指出，73% 的 [BitMEX 用户充值][news141 bitmex bech32 receive]使用 P2WSH 输出，可节省约 65% 的手续费。 + +- ******BitBox02 新增 taproot 发送功能：** [v9.9.0 - Multi][bitbox02 v9.9.0 multi] 和 [v9.9.0 - Bitcoin-only][bitbox02 v9.9.0 bitcoin] 两个版本都已支持向 bech32m 地址发送。 + +- ******Fulcrum 1.6.0 提升性能：** 地址索引软件 Fulcrum 在 [1.6.0 版本][fulcrum 1.6.0]中加入了[性能改进][sparrow docs performance]。 + +- ******Kraken 公布储备证明方案：** Kraken [详细介绍][kraken por]其包含受信审计方的储备证明方案，同时指出其不足并计划未来改进。Kraken 通过数字签名证明链上地址归属，生成用户账户余额的默克尔树，邀请审计方证明链上余额大于账户总额，并提供工具让用户验证自己的余额已包含在该树中。 + +## 值得注意的代码与文档变更 + +*本周 [Bitcoin Core][bitcoin core repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]的值得注意的变更。* + +- [Eclair #2164][Eclair #2164] 在多个场景中改进了对特性位的处理。特别是，要求强制但非发票特性的发票将不再被拒绝，因为缺乏对非发票特性的支持并不会影响发票的兑付能力。 + +- [BTCPay Server #3395][BTCPay Server #3395] 为发票收到的付款和钱包发送的交易新增了 [CPFP（Child Pays For Parent）][topic cpfp] 手续费加速支持。 + +- [BIPs #1279][BIPs #1279] 更新了 [BIP322][] 关于通用 Signmessage 协议的规范，补充了若干说明及测试向量。 + + +{% include references.md %} +{% include linkers/issues.md v=1 issues="2164,3395,1279" %} +[russell op_tx]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019871.html +[news185 composable]: /zh/newsletters/2022/02/02/#composable-alternatives-to-ctv-and-apo +[blockchain.com v202201.2.0(18481)]: https://github.com/blockchain/My-Wallet-V3-Android/releases/tag/v202201.2.0(18481) +[sensei website]: https://l2.technology/sensei +[bdk website]: https://bitcoindevkit.org/ +[ldk website]: https://lightningdevkit.org/ +[bitmex blog]: https://blog.bitmex.com/bitmex-supports-sending-to-taproot-addresses/ +[news141 bitmex bech32 receive]: /zh/newsletters/2021/03/24/#bitmex-announces-bech32-support +[bitbox02 v9.9.0 multi]: https://github.com/digitalbitbox/bitbox02-firmware/releases/tag/firmware%2Fv9.9.0 +[bitbox02 v9.9.0 bitcoin]: https://github.com/digitalbitbox/bitbox02-firmware/releases/tag/firmware-btc-only%2Fv9.9.0 +[fulcrum 1.6.0]: https://github.com/cculianu/Fulcrum/releases/tag/v1.6.0 +[sparrow docs performance]: https://www.sparrowwallet.com/docs/server-performance.html +[kraken por]: https://www.kraken.com/proof-of-reserves From c8c8958f28e23f949e7e43a3ddc2b3acf1bd5aa6 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Wed, 11 Jun 2025 15:46:10 +0200 Subject: [PATCH 080/278] Newsletter 356 translate in French (#2359) --- .../fr/newsletters/2025-05-30-newsletter.md | 185 ++++++++++++++++++ 1 file changed, 185 insertions(+) create mode 100644 _posts/fr/newsletters/2025-05-30-newsletter.md diff --git a/_posts/fr/newsletters/2025-05-30-newsletter.md b/_posts/fr/newsletters/2025-05-30-newsletter.md new file mode 100644 index 0000000000..f5b9856885 --- /dev/null +++ b/_posts/fr/newsletters/2025-05-30-newsletter.md @@ -0,0 +1,185 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #356' +permalink: /fr/newsletters/2025/05/30/ +name: 2025-05-30-newsletter-fr +slug: 2025-05-30-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +La newsletter de cette semaine résume une discussion sur les effets possibles des échecs +attribuables sur la confidentialité du LN. Sont également inclus nos sections régulières avec des +questions et réponses sélectionnées du Bitcoin Stack Exchange, des annonces de nouvelles versions et +candidates à la sortie, ainsi que des descriptions des changements récents dans les logiciels +d'infrastructure Bitcoin populaires. + +## Nouvelles + +- **Les échecs attribuables réduisent-ils la confidentialité du LN ?** Carla Kirk-Cohen a + [posté][kirkcohen af] sur Delving Bitcoin une analyse des conséquences possibles pour la + confidentialité des dépensiers et des receveurs du LN si le réseau adopte les [échecs + attribuables][topic attributable failures], en particulier en informant le dépensier du temps qu'il + a fallu pour transférer un paiement à chaque saut. Citant plusieurs articles, elle décrit deux types + d'attaques de désanonymisation : + + - Un attaquant exploitant un ou plusieurs nœuds de transfert utilise les données de temps pour + déterminer le nombre de sauts utilisés par un paiement ([HTLC][topic htlc]), ce qui peut être + combiné avec la connaissance de la topographie du réseau public pour réduire l'ensemble des nœuds + qui auraient pu être le receveur. + + - Un attaquant utilise un achemineur de trafic réseau IP + ([système autonome][]) pour surveiller passivement le trafic et combine cela avec la connaissance de la latence du réseau IP entre les + nœuds (c'est-à-dire, leurs temps de ping) plus la connaissance de la topographie (et d'autres + caractéristiques) du réseau Lightning public. + + Elle décrit ensuite des solutions possibles, incluant : + + - Encourager les receveurs à retarder l'acceptation d'un HTLC d'une petite quantité aléatoire pour + prévenir les attaques de timing tentant d'identifier le nœud du receveur. + + - Encourager les dépensiers à retarder le renvoi des paiements échoués (ou des parties de + [MPP][topic multipath payments]) d'une petite quantité aléatoire et en utilisant des chemins + alternatifs pour prévenir les attaques de timing et d'échec tentant d'identifier le nœud du + dépensier. + + - Augmenter la division des paiements avec MPP pour rendre plus difficile la devinette du montant + dépensé. + + - Permettre aux dépensiers de choisir de faire acheminer leurs paiements moins rapidement, comme + précédemment proposé (voir le [Bulletin #208][news208 slowln]). Cela pourrait être combiné avec le + regroupement de HTLC, qui est déjà implémenté dans LND (bien que l'ajout d'un délai aléatoire + pourrait améliorer la confidentialité). + + - Réduire la précision des horodatages des échecs attribuables pour éviter de pénaliser les nœuds de + transfert qui ajoutent de petits délais aléatoires. + + La discussion de plusieurs participants a évalué les préoccupations et les solutions proposées plus + en détail, ainsi que la considération d'autres attaques possibles et des atténuations. + +## Questions et réponses sélectionnées de Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] est l'un des premiers endroits où les contributeurs d'Optech +cherchent des réponses à leurs questions---ou quand nous avons quelques moments libres pour aider +les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous mettons en lumière certaines +des questions et réponses les mieux votées postées depuis notre dernière mise à jour.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Quelles transactions sont incluses dans blockreconstructionextratxn ?]({{bse}}116519) Glozow + explique comment la structure de données extrapool (voir le [Bulletin #339][news339 extrapool]) met + en cache les transactions rejetées et remplacées vues par le nœud et énumère les critères + d'exclusion et d'éviction. + +- [Pourquoi quelqu'un utiliserait OP_RETURN plutôt que des inscriptions, à part pour les frais?]({{bse}}126208) + Sjors Provoost note qu'en plus d'être parfois moins cher, `OP_RETURN` peut + également être utilisé pour des protocoles nécessitant que les données soient disponibles avant + qu'une transaction soit dépensée, contrairement aux données de témoin qui sont révélées dans la + transaction de dépense. + +- [Pourquoi mon nœud Bitcoin ne reçoit-il pas de connexions entrantes ?]({{bse}}126338) Lightlike + souligne qu'un nouveau nœud sur le réseau peut prendre du temps pour que son adresse soit largement + diffusée sur le réseau P2P et que les nœuds n'annonceront pas leur adresse tant que l'IBD n'est pas + terminée. + +- [Comment configurer mon nœud pour filtrer les transactions de plus de 400 octets ?]({{bse}}126347) + Antoine Poinsot confirme qu'il n'existe pas d'option de configuration dans Bitcoin Core pour + personnaliser la taille maximale standard d'une transaction. Il explique que les utilisateurs + souhaitant personnaliser cette valeur peuvent mettre à jour leur code source, mais met en garde + contre les inconvénients potentiels des valeurs maximales plus grandes ou plus petites. + +- [Que signifie un nœud "non routable publiquement" dans le P2P de Bitcoin Core ?]({{bse}}126225) + Pieter Wuille et Vasil Dimov fournissent des exemples de connexions P2P, telles que [Tor][topic + anonymity networks], qui ne peuvent pas être routées sur l'internet global et qui apparaissent dans + la sortie `netinfo` de Bitcoin Core dans le seau "npr". + +- [Pourquoi un nœud ne relayerait-il jamais une transaction ?]({{bse}}127391) Pieter Wuille énumère les + avantages du relais de transactions pour un opérateur de nœud : la confidentialité lors du relais de + vos propres transactions depuis votre nœud, une propagation de bloc plus rapide si l'utilisateur + fait de l'extraction, et une amélioration de la décentralisation du réseau avec des coûts + incrémentiels minimaux au-delà du simple relais de blocs. + +- [Le minage égoïste est-il toujours une option avec les blocs compacts et FIBRE ?]({{bse}}49515) + Antoine Poinsot répond à une question de 2016 en notant, "Oui, le minage égoïste est toujours une + optimisation possible même avec une amélioration de la propagation des blocs. Il n'est pas correct + de conclure que le minage égoïste est maintenant seulement une attaque théorique". Il pointe + également vers une [simulation de minage][miningsimulation github] qu'il a créée. + +## Mises à jour et versions candidates + +_Nouvelles mises à jour et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de passer aux nouvelles versions ou d'aider à tester +les versions candidates._ + +- [Core Lightning 25.05rc1][] est un candidat à la sortie pour la prochaine version majeure de cette + implémentation populaire de nœud LN. + +- [LDK 0.1.3][] et [0.1.4][ldk 0.1.4] sont des sorties de cette bibliothèque populaire pour la + construction d'applications activées par LN. La version 0.1.3, taguée + comme une publication sur GitHub cette semaine mais datée du mois dernier, inclut le correctif pour + une attaque par déni de service. La version 0.1.4, la dernière publication, "corrige une + vulnérabilité de vol de fonds dans des cas extrêmement rares". Ces deux versions incluent également + d'autres corrections de bugs. + +## Changements de code et de documentation notables + +_Changements récents notables dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core +lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], +[libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust +bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Propositions d'Amélioration de +Bitcoin (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], +[Inquisition Bitcoin][bitcoin inquisition repo], et [BINANAs][binana repo]._ + +- [Bitcoin Core #31622][] ajoute un champ de type de hachage de signature (sighash) à [PSBTs][topic + psbt] quand il est différent de `SIGHASH_DEFAULT` ou `SIGHASH_ALL`. Le support de [MuSig2][topic + musig] nécessite que tout le monde signe avec le même type de sighash, donc ce champ doit être + présent dans le PSBT. De plus, la commande RPC `descriptorprocesspsbt` est mise à jour pour utiliser + la fonction `SignPSBTInput`, qui assure que le type de sighash du PSBT correspond à celui fourni + dans le CLI, le cas échéant. + +- [Eclair #3065][] ajoute le support pour les échecs attribuables (voir le Bulletin [#224][news224 + failures]) tel que spécifié dans [BOLTs #1044][]. Il est désactivé par défaut car la spécification + n'est pas finalisée, mais peut être activé avec le paramètre + `eclair.features.option_attributable_failure = optional`. La compatibilité croisée avec LDK a été + testée avec succès, voir le Bulletin [#349][news349 failures] pour plus d'informations sur + l'implémentation de LDK et le fonctionnement de ce protocole. + +- [LDK #3796][] renforce les vérifications du solde du canal pour que les financeurs aient + suffisamment de fonds pour couvrir les frais de transaction d'engagement, les deux [sorties + d'ancrage][topic anchor outputs] de 330 sat, et la réserve du canal. Auparavant, les + financeurs pouvaient puiser dans les fonds de réserve du canal pour couvrir les deux ancrages. + +- [BIPs #1760][] fusionne [BIP53][] qui spécifie une règle de soft-fork de consensus interdisant les + transactions de 64 octets (mesurées sans les données de témoin) pour prévenir un type de + [vulnérabilité de l'arbre de Merkle][topic merkle tree vulnerabilities] exploitable contre les + clients SPV. Cette PR propose une solution similaire à l'une des corrections incluses dans le + [consensus cleanup softfork][topic consensus cleanup]. + +- [BIPs #1850][] revient sur une mise à jour antérieure de [BIP48][] qui réservait la valeur de type + de script 3 pour les dérivations [taproot][topic taproot] (P2TR) (voir + le Bulletin [#353][news353 bip48]). Cela est dû au fait que [tapscript][topic tapscript] manque de + `OP_CHECKMULTISIG`, donc le script de sortie référencé dans [BIP67][] (sur lequel [BIP48][] repose) + ne peut pas être exprimé dans P2TR. Cette PR marque également le statut de [BIP48][] comme `Final`, + reflétant que son but était de définir l'utilisation industrielle des chemins de dérivation de + [portefeuille HD][topic bip32] `m/48'` lorsque le BIP a été introduit, plutôt que de prescrire un + nouveau comportement. + +- [BIPs #1793][] fusionne [BIP443][] qui propose l'opcode [OP_CHECKCONTRACTVERIFY][topic matt] + (OP_CCV) qui permet de vérifier qu'une clé publique (tant des sorties que des entrées) s'engage sur + un morceau de données arbitraire. Voir le Bulletin [#348][news348 op_ccv] pour plus d'informations + sur cette proposition de [covenant][topic covenants]. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="31622,3065,3796,1760,1850,1793,1044" %} +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[ldk 0.1.3]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.1.3 +[ldk 0.1.4]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.1.4 +[news208 slowln]: /en/newsletters/2022/07/13/#allowing-deliberately-slow-ln-payment-forwarding +[système autonome]: https://en.wikipedia.org/wiki/Autonomous_system_(Internet) +[kirkcohen af]: https://delvingbitcoin.org/t/latency-and-privacy-in-lightning/1723 +[news224 failures]: /fr/newsletters/2022/11/02/#attribution-de-l-echec-du-routage-ln +[news349 failures]: /fr/newsletters/2025/04/11/#ldk-2256 +[news353 bip48]: /fr/newsletters/2025/05/09/#bips-1835 +[news348 op_ccv]: /fr/newsletters/2025/04/04/#semantique-de-op-checkcontractverify +[news339 extrapool]: /fr/newsletters/2025/01/31/#statistiques-mises-a-jour-sur-la-reconstruction-de-blocs-compacts +[miningsimulation github]: https://github.com/darosior/miningsimulation \ No newline at end of file From 6a95d2e6fa419178dc5ac1070de15b3d3900869a Mon Sep 17 00:00:00 2001 From: BitTom Date: Wed, 11 Jun 2025 21:48:19 +0800 Subject: [PATCH 081/278] Newsletter-188: translate into Chinese (#2335) --- .../zh/newsletters/2022-02-23-newsletter.md | 68 +++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 _posts/zh/newsletters/2022-02-23-newsletter.md diff --git a/_posts/zh/newsletters/2022-02-23-newsletter.md b/_posts/zh/newsletters/2022-02-23-newsletter.md new file mode 100644 index 0000000000..aec683135e --- /dev/null +++ b/_posts/zh/newsletters/2022-02-23-newsletter.md @@ -0,0 +1,68 @@ +--- +title: 'Bitcoin Optech Newsletter #188' +permalink: /zh/newsletters/2022/02/23/ +name: 2022-02-23-newsletter-zh +slug: 2022-02-23-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周 Newsletter 总结了关于手续费追加与交易手续费赞助的讨论，描述了一项更新版 LN gossip 线路协议的提案，并宣传了一个用于测试 `OP_CHECKTEMPLATEVERIFY` 的 signet。此外，我们照例收录了 Bitcoin Stack Exchange 精选问答以及值得注意的比特币基础设施项目变更说明。 + +## 新闻 + +- ******手续费追加与交易手续费赞助：** 继几周前启动的 replace-by-fee（RBF）讨论（参见 [Newsletter #186][news186 rbf]）之后，本周 James O'Beirne [发起][obeirne bump]了关于手续费追加的讨论。O'Beirne 特别担心，一些正在被提议的交易中继策略变更会使用户和钱包开发者更难使用手续费追加。作为替代，他希望重新审视[交易手续费赞助][topic fee sponsorship]（此前在 [Newsletter #116][news116 sponsorship] 中介绍过）。 + + 这些想法在邮件列表上引发了大量讨论，许多回复提到了实现手续费赞助所面临的挑战。 + +- ******更新版 LN gossip 提案：** Rusty Russell 在 Lightning-Dev 邮件列表上[发布][russell gossip] 了一份详细提案，提出一套新的 LN gossip 消息，类似于他 2019 年在 [Newsletter #55][news55 gossip] 中描述的提案。新提案使用 [BIP340][] 形式的 [schnorr 签名][topic schnorr signatures]以及[仅 x 坐标公钥][news72 xonly]，并在现有 LN gossip 协议基础上做了许多简化。该协议用于广播可用于路由的公共通道信息；更新后的协议设计旨在最大化效率，尤其是在与类似 [erlay][topic erlay] 的基于 [minisketch][topic minisketch] 的高效 gossip 协议结合使用时。 + +- ******CTV signet：** Jeremy Rubin [发布][rubin ctv signet]了启用 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] 的 [signet][topic signet] 参数和代码。这简化了对该提议 opcode 的公开实验，并使不同软件之间的兼容性测试更加容易。 + +## Bitcoin Stack Exchange 精选问答 + +*[Bitcoin Stack Exchange][bitcoin.se] 是许多 Optech 贡献者寻找答案的首选之地——或在我们有空时帮助好奇或困惑用户的场所。在这一月度专栏中，我们重点介绍自上次更新以来获得高票的部分问答。* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- ****[补贴结束且无交易的区块是否仍会包含 coinbase 交易？]({{bse}}112193) + Pieter Wuille 解释，每个区块都必须包含 coinbase 交易，而每笔交易必须至少包含一个输入和一个输出，因此即使一个区块没有区块奖励（无手续费且无补贴），仍需至少有一个零值输出。 + +- ****[如果脚本无效，创世区块如何能包含任意数据？]({{bse}}112439) + Pieter Wuille 列举了创世区块 coinbase 中 “Chancellor...” 文本推送有效的原因。首先，[创世区块][bitcoin se 13122]在定义上就是有效的；其次，coinbase 输入脚本从不执行；第三，对于非 taproot 输入，执行后栈中只剩一个元素的要求仅是策略规则，而非共识规则；最后，该策略规则仅适用于输入脚本与对应输出脚本共同执行后的最终栈，而 coinbase 交易的输入没有对应输出脚本，因此该策略不适用。Wuille 还指出，创世区块不可花费的原因与此讨论无关，而在于最初的 Bitcoin 软件[未将创世区块][bitcoin github genesis]写入其内部数据库。 + +- ****[什么是 Feeler 连接？何时使用？]({{bse}}112247) + 用户 vnprc 解释了 Bitcoin Core 的 [feeler 连接][chaincode p2p]的作用。它是一条临时的出站连接，区别于默认的 8 条出站连接和 2 条仅区块出站连接。Feeler 连接用于测试来自 gossip 网络的潜在新节点，以及测试之前无法连接、但可能被逐出的节点。 + +- ****[OP_RETURN 交易不会存储在 chainstate 数据库中吗？]({{bse}}112312) + Antoine Poinsot 指出，由于 `OP_RETURN` 输出是[不可花费的][bitcoin github unspendable]，因此不会存储在 [chainstate 目录][bitcoin docs data]中。 + +## 值得注意的代码与文档变更 + +*本周在 [Bitcoin Core][bitcoin core repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中的值得注意的变更：* + +- [Bitcoin Core #24307][] 为 `getwalletinfo` RPC 的结果对象扩展了 `external_signer` 字段。该字段指示钱包是否配置为使用外部签名器，例如硬件签名设备。 + +- [C-Lightning #5010][] 新增语言绑定生成工具 `MsgGen` 以及 Rust RPC 客户端 `cln-rpc`。`MsgGen` 解析 C-Lightning 的 JSON-RPC 架构，并生成 `cln-rpc` 使用的 Rust 绑定，以正确调用 C-Lightning 的 JSON-RPC 接口。 + +- [LDK #1199][] 添加了对 “phantom node payments” 的支持，即由多个节点中的任意一个接收的支付，可用于负载均衡。这需要创建带有 [BOLT11][] 路径提示的 LN 发票，这些提示指向同一个不存在的（“phantom”）节点。在每条路径中，到达 phantom 节点之前的最后一跳是真实节点，它知道 phantom 节点的密钥，可用于解密并重建[无状态发票][topic stateless invoices]（参见 [Newsletter #181][news181 rl1177]），从而接受该支付的 [HTLC][topic htlc]。 + + {:.center} + ![phantom 节点路径提示示意图](/img/posts/2022-02-phantom-node-payments.dot.png) + +{% include references.md %} +{% include linkers/issues.md v=1 issues="24307,5010,1199," %} +[news186 rbf]: /zh/newsletters/2022/02/09/#discussion-about-rbf-policy +[obeirne bump]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html +[news116 sponsorship]: /zh/newsletters/2020/09/23/#transaction-fee-sponsorship +[russell gossip]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003470.html +[news72 xonly]: /zh/newsletters/2019/11/13/#taproot-review-discussion-and-related-information +[news55 gossip]: /zh/newsletters/2019/07/17/#gossip-update-proposal +[rubin ctv signet]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019925.html +[news181 rl1177]: /zh/newsletters/2022/01/05/#rust-lightning-1177 +[bitcoin se 13122]: https://bitcoin.stackexchange.com/a/13123/87121 +[bitcoin github genesis]: https://github.com/bitcoin/bitcoin/blob/9546a977d354b2ec6cd8455538e68fe4ba343a44/src/main.cpp#L1668 +[chaincode p2p]: https://residency.chaincode.com/presentations/bitcoin/ethan_heilman_p2p.pdf#page=18 +[bitcoin github unspendable]: https://github.com/bitcoin/bitcoin/blob/280a7777d3a368101d667a80ebc536e95abb2f8c/src/script/script.h#L539-L547 +[bitcoin docs data]: https://github.com/bitcoin/bitcoin/blob/master/doc/files.md#data-directory-layout From 46cb4953391164acf96cd89c1aa1bca561e8007c Mon Sep 17 00:00:00 2001 From: Murch Date: Wed, 11 Jun 2025 13:50:57 -0700 Subject: [PATCH 082/278] Remove redirects to Chinese translation --- zh/about.md | 1 - zh/workshops.md | 1 - 2 files changed, 2 deletions(-) diff --git a/zh/about.md b/zh/about.md index b437e56837..e0d04e8922 100644 --- a/zh/about.md +++ b/zh/about.md @@ -2,7 +2,6 @@ layout: page title: About permalink: /zh/about/ -redirect_from: /about --- Bitcoin Operations Technology Group（简称 Optech）致力于将最好的开源技术和技术手段引入使用比特币的企业，以降低成本并改善客户体验。 diff --git a/zh/workshops.md b/zh/workshops.md index e5b09cb30b..ac98439eac 100644 --- a/zh/workshops.md +++ b/zh/workshops.md @@ -2,7 +2,6 @@ layout: page title: Workshops permalink: /zh/workshops/ -redirect_from: /workshops --- 比特币 Optech 将举办一系列研讨会，将比特币工程师聚集在一起，讨论实施扩容技术的方式和挑战。每个研讨会都会根据参与的会员公司及其面临的具体扩容挑战进行定制。 From 904f222937eb04b32cdffe8fbc83418a86e0b851 Mon Sep 17 00:00:00 2001 From: Luis Schwab Date: Fri, 6 Jun 2025 23:01:58 -0300 Subject: [PATCH 083/278] feat(pt): add Portuguese scaffolding --- _config.yml | 2 ++ pt/about.md | 53 +++++++++++++++++++++++++++++++ pt/blog.md | 9 ++++++ pt/newsletters.md | 9 ++++++ pt/publications.md | 18 +++++++++++ pt/workshops.md | 78 ++++++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 169 insertions(+) create mode 100644 pt/about.md create mode 100644 pt/blog.md create mode 100644 pt/newsletters.md create mode 100644 pt/publications.md create mode 100644 pt/workshops.md diff --git a/_config.yml b/_config.yml index c65111a3e6..3ce8a22284 100644 --- a/_config.yml +++ b/_config.yml @@ -84,5 +84,7 @@ languages: name: German - code: fr name: French + - code: pt + name: Portuguese ## In-text aliases trb: "709,632" # TapRoot Block (activation) diff --git a/pt/about.md b/pt/about.md new file mode 100644 index 0000000000..ad10453fdc --- /dev/null +++ b/pt/about.md @@ -0,0 +1,53 @@ +--- +layout: page +title: Sobre +permalink: /pt/about/ +--- + +O Grupo de Tecnologia de Operações Bitcoin (Optech) trabalha para trazer as +melhores tecnologias e técnicas de código aberto para empresas que utilizam +Bitcoin, a fim de reduzir custos e melhorar as experiências dos clientes. + +Um foco inicial para o grupo é trabalhar com suas organizações membros para +reduzir os tamanhos das transações e minimizar o efeito de aumentos +subsequentes nas taxas de transação. Fornecemos workshops, newsletters +semanais, estudos de caso, anúncios, um podcast, e ajudamos a facilitar +relações aprimoradas entre empresas e a comunidade de código aberto. + +[workshops]: /pt/workshops +[newsletters semanais]: /pt/newsletters/ +[blog]: /pt/blog/ +[podcast]: /pt/podcast/ + +Se você é um engenheiro ou gerente em uma empresa Bitcoin ou um contribuidor de +código aberto e gostaria de fazer parte disso, entre em contato conosco em +[info@bitcoinops.org](mailto:info@bitcoinops.org). + +## Financiamento + +A Optech não existe para obter lucro, e todos os materiais e documentação produzidos +são liberados sob a licença MIT. + +O financiamento inicial foi fornecido por Wences Casares e John Pfeffer para cobrir +contratados externos e despesas incidentais. + +Nossas generosas empresas membros pagam uma contribuição anual para cobrir despesas. + +## Contribuidores da Optech + +Todo material produzido pela Bitcoin Optech é de código aberto e liberado sob a +licença MIT. Qualquer pessoa é bem-vinda para contribuir abrindo issues e +pull requests, revisando newsletters e outros materiais, e contribuindo com traduções. +Nossos contribuidores mais regulares são: + +{% assign contributors = site.data.contributors.contributors | sort: "name" %} +{% include contributors.html id="contributors" %} + +{% include sponsors.html %} + +## Ex-Contribuidores da Optech + +Agradecemos a todos os nossos ex-contribuidores por seus esforços. + +{% assign contributors = site.data.contributors.contributors_alum | sort: "name" %} +{% include contributors.html id="contributors_alum" %} \ No newline at end of file diff --git a/pt/blog.md b/pt/blog.md new file mode 100644 index 0000000000..96f98d7491 --- /dev/null +++ b/pt/blog.md @@ -0,0 +1,9 @@ +--- +layout: blog +lang: pt +title: Blog +name: blog +permalink: /pt/blog/ +share: false +version: 1 +--- \ No newline at end of file diff --git a/pt/newsletters.md b/pt/newsletters.md new file mode 100644 index 0000000000..37f86aea8d --- /dev/null +++ b/pt/newsletters.md @@ -0,0 +1,9 @@ +--- +layout: newsletters +lang: pt +title: Newsletters +name: newsletters +permalink: /pt/newsletters/ +share: false +version: 1 +--- \ No newline at end of file diff --git a/pt/publications.md b/pt/publications.md new file mode 100644 index 0000000000..8d60502492 --- /dev/null +++ b/pt/publications.md @@ -0,0 +1,18 @@ +--- +layout: publications +lang: pt +title: Publicações +name: publicações +permalink: /pt/publications/ +share: false +version: 1 +--- +- [Newsletters][]: Um resumo semanal de notícias sobre desenvolvimento do Bitcoin e LN. + +- [Posts do Blog][]: Atualizações ocasionais e material de referência da equipe Optech. + +- [Episódios do Podcast][]: Discussões em áudio sobre nossas newsletters. + +[posts do blog]: /pt/blog/ +[newsletters]: /pt/newsletters/ +[episódios do podcast]: /en/podcast/ diff --git a/pt/workshops.md b/pt/workshops.md new file mode 100644 index 0000000000..736d0c69e0 --- /dev/null +++ b/pt/workshops.md @@ -0,0 +1,78 @@ +--- +layout: page +title: Workshops +permalink: /pt/workshops/ +--- + +A Bitcoin Optech realizará uma série de workshops para reunir engenheiros do +Bitcoin para discutir abordagens e desafios na implementação de tecnologias +para escalabilidade. Cada workshop será adaptado às empresas membros +participantes e aos desafios específicos de escalabilidade que elas estão enfrentando. + +Se você tiver alguma solicitação ou sugestão para futuros eventos de workshop, +por favor [entre em contato conosco](mailto:info@bitcoinops.org). + +## Workshops #3, #4 e #5 - Seminários Schnorr e Taproot {#taproot-workshop} + +- São Francisco, 24 de setembro de 2019 +- Nova York, 27 de setembro de 2019 +- Londres, 5 de fevereiro de 2020 + +*Assinaturas Schnorr* e *Taproot* são mudanças propostas para o protocolo Bitcoin que +prometem grandes melhorias em privacidade, fungibilidade, escalabilidade e funcionalidade. + +A Bitcoin Optech hospedou dois workshops no formato de seminário que incluíram uma +mistura de apresentações, exercícios de programação e discussões, e deram aos +engenheiros das empresas membros uma compreensão de como essas novas tecnologias +funcionam e como podem ser aplicadas aos seus produtos e serviços. Os workshops +também forneceram aos engenheiros uma oportunidade de participar do processo de +feedback enquanto essas tecnologias ainda estão na fase de proposta. + +[Todo o material dos workshops][taproot workshop blog post] +está disponível neste site, para que os engenheiros possam aprender sobre as propostas +Schnorr/Taproot em casa. + +## Workshop #2 - Paris, 12-13 de novembro de 2018 + +A Bitcoin Optech realizou nosso segundo workshop de mesa redonda em Paris nos dias +12-13 de novembro de 2018. O formato foi o mesmo do primeiro workshop em São Francisco. + +Estiveram presentes 24 engenheiros de empresas de Bitcoin e projetos de código aberto. + +#### Tópicos + +- Replace-by-Fee vs. Child-Pays-for-Parent como técnicas de substituição de taxa +- Transações Bitcoin Parcialmente Assinadas (PSBTs)([BIP 174](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki)) +- [Descritores de script de saída (Output Descriptors)](https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82) para interoperabilidade de carteiras +- Integração de carteiras Lightning e aplicações para exchanges +- Abordagens para seleção e consolidação de moedas + +#### Agradecimentos + +Obrigado à Ledger por hospedar o workshop e ajudar com a organização. + +## Workshop #1 - São Francisco, 17 de julho de 2018 + +A Bitcoin Optech realizou nosso primeiro workshop de mesa redonda em São Francisco no dia 17 de julho de 2018: + +- Os tópicos foram discutidos em formato de mesa redonda no qual cada participante teve uma oportunidade igual de se envolver. + +- Cada tópico teve um moderador e alguém responsável pelas anotações. O moderador foi responsável por uma breve introdução de um tópico e manter a discussão no caminho certo e no tempo. + +- Para garantir que os participantes se sentissem confortáveis para falar livremente, as notas e itens de ação foram distribuídos aos participantes, mas não além disso. Os participantes foram livres para compartilhar detalhes da discussão internamente em suas empresas e publicamente, mas não atribuíram nenhuma declaração particular a um determinado indivíduo (Regras da Casa Chatham). + +Estiveram presentes 14 engenheiros de empresas de Bitcoin da Área da Baía de São Francisco e projetos de código aberto. + +#### Tópicos + +- Seleção de moedas +- Estimativa de taxa, RBF, melhores práticas CPFP +- Comunidade e comunicação Optech + +#### Agradecimentos + +Obrigado à Square por hospedar o workshop e à Coinbase por ajudar com a organização. + +{% include references.md %} + +[taproot workshop blog post]: /en/schorr-taproot-workshop/ \ No newline at end of file From d898e59bc2218da68cab29c19dc0705f0703c6d3 Mon Sep 17 00:00:00 2001 From: Luis Schwab Date: Fri, 6 Jun 2025 23:03:02 -0300 Subject: [PATCH 084/278] feat(pt): add Portuguese translation for Newsletter 357 --- .../pt/newsletters/2025-06-06-newsletter.md | 195 ++++++++++++++++++ 1 file changed, 195 insertions(+) create mode 100644 _posts/pt/newsletters/2025-06-06-newsletter.md diff --git a/_posts/pt/newsletters/2025-06-06-newsletter.md b/_posts/pt/newsletters/2025-06-06-newsletter.md new file mode 100644 index 0000000000..717f7e743a --- /dev/null +++ b/_posts/pt/newsletters/2025-06-06-newsletter.md @@ -0,0 +1,195 @@ +--- +title: 'Newsletter Bitcoin Optech #357' +permalink: /pt/newsletters/2025/06/06/ +name: 2025-06-06-newsletter-pt +slug: 2025-06-06-newsletter-pt +type: newsletter +layout: newsletter +lang: pt +--- + +A newsletter desta semana compartilha uma análise sobre sincronização de full-nodes +sem witness antigas. Também incluídas estão nossas seções regulares com +descrições de discussões sobre mudanças de consenso, anúncios de +novos lançamentos e candidatos a lançamento, e resumos de mudanças notáveis em +software popular de infraestrutura do Bitcoin. + +## Notícias + +- **Sincronizando nós completos sem dados de testemunha (witness):** Jose SK [postou][sk nowit] + no Delving Bitcoin um resumo de uma [análise][sk nowit gist] que ele + fez sobre os tradeoffs de segurança de permitir que nós completos recém-iniciados + com uma configuração em particular evitem baixar alguns + dados da blockchain. Por padrão, nós Bitcoin Core usam a + configuração `assumevalid` que pula a validação de scripts + em blocos criados mais de um mês ou dois antes do lançamento da + versão do Bitcoin Core sendo executada. Embora desabilitado por padrão, muitos + usuários do Bitcoin Core também definem uma configuração `prune` que + exclui blocos algum tempo após validá-los (por quanto tempo os blocos são + mantidos depende do tamanho dos blocos e da configuração específica selecionada + pelo usuário). + + SK argumenta que dados de testemunha (witness), que são usados apenas para validar + scripts, não deveriam ser baixados por nós prunados para blocos `assumevalid` + porque eles não os usarão para validar scripts e eventualmente serão excluídos. + Pular o download de testemunhas "pode reduzir o uso de banda em mais de 40%", ele escreve. + + Ruben Somsen [argumenta][somsen nowit] que isso muda o modelo de segurança + até certo ponto. Embora scripts não sejam validados, os + dados baixados são validados contra o commitment da raiz merkle do cabeçalho do bloco + para a transação coinbase para os dados da testemunha. + Isso garante que os dados estavam disponíveis e não corrompidos no momento em que o + nó foi inicialmente sincronizado. Se ninguém rotineiramente valida a + existência dos dados, eles poderiam eventualmente ser perdidos, como [aconteceu][ripple loss] + com pelo menos uma altcoin. + + A discussão estava em andamento no momento da escrita. + +## Mudando consenso + +_Uma seção mensal resumindo propostas e discussões sobre mudanças +nas regras de consenso do Bitcoin._ + +- **Relatório de computação quântica:** Clara Shikhelman [postou][shikhelman + quantum] no Delving Bitcoin o resumo de um [relatório][sm report] que ela + co-autorou com Anthony Milton sobre os riscos para usuários Bitcoin de + computadores quânticos rápidos, uma visão geral de várias vias para [resistência + quântica][topic quantum resistance], e uma análise de _tradeoffs_ + envolvidos na atualização do protocolo do Bitcoin. Os autores encontraram 4 a 10 + milhões de BTC potencialmente vulneráveis a roubo quântico, alguma + mitigação é agora possível, e é improvável que a mineração do Bitcoin seja + ameaçada pela computação quântica no curto ou médio prazo, e + atualizar requer acordo generalizado. + +- **Limite de peso de transação com exceção para prevenir confisco:** + Vojtěch Strnad [postou][strnad limit] no Delving Bitcoin a proposta de uma + ideia de mudança de consenso para limitar o peso máximo da maioria + das transações em um bloco. A regra simples apenas permitiria uma transação + maior que 400.000 unidades de peso (100.000 vbytes) em um bloco se fosse + a única transação naquele bloco além da transação coinbase. + Strnad e outros descreveram a motivação para limitar o peso máximo + da transação: + + - _Otimização de template de bloco mais fácil:_ é mais fácil encontrar uma + solução quase ótima para o [problema da mochila][] quanto menores forem os + itens comparados ao limite geral. Isso é parcialmente + devido à minimização da quantidade de espaço sobrado no final, com + itens menores deixando menos espaço não utilizado. + + - _Política de retransmissão mais fácil:_ a política para retransmitir transações não confirmadas + entre nós prevê quais transações serão + mineradas para evitar desperdiçar largura de banda. Transações gigantes tornam + previsões precisas mais difíceis, pois mesmo uma pequena mudança na taxa de topo pode causar + que sejam atrasadas ou removidas. + + - _Evitando centralização de mineração:_ garantir que nós completos de retransmissão sejam + capazes de lidar com quase todas as transações impede que usuários de transações especiais + precisem pagar [taxas fora de banda][topic + out-of-band fees], o que pode levar à centralização de mineração. + + Gregory Sanders [notou][sanders limit] que poderia ser razoável + simplesmente fazer um soft fork de limite de peso máximo sem exceções baseado + na política de retransmissão consistente de 12 anos do Bitcoin Core. Gregory + Maxwell [adicionou][maxwell limit] que transações gastando apenas UTXOs + criados antes do soft fork poderiam ter uma exceção permitida para prevenir + confisco, e que um [soft fork transitório][topic transitory soft + forks] permitiria que a restrição expirasse se a + comunidade decidisse não renová-la. + + Uma discussão adicional examinou as necessidades de partes querendo + transações grandes, principalmente usuários [BitVM][topic acc] no curto prazo, + e se abordagens alternativas estavam disponíveis para eles. + +- **Removendo saídas do conjunto UTXO baseado em valor e tempo:** Robin + Linus [postou][linus dust] no Delving Bitcoin para propor um soft fork + para remover saídas de baixo valor do conjunto UTXO após algum + tempo. Várias variações da ideia foram discutidas, sendo as duas + principais alternativas: + + - _Destruir fundos antigos não econômicos:_ saídas de pequeno valor que não + foram gastas por muito tempo se tornariam ingastáveis. + + - _Requerer que fundos antigos não econômicos sejam gastos com prova de existência:_ + [utreexo][topic utreexo] ou um sistema similar poderia ser usado para permitir + que uma transação prove que as saídas que ela gasta são parte do + UTXO set. Saídas antigas e [não econômicas][topic uneconomical outputs] precisariam + incluir esta prova, mas saídas mais novas e de maior valor ainda seriam + armazenadas no conjunto UTXO. + + Qualquer solução efetivamente limitaria o tamanho máximo do conjunto UTXO + (assumindo um valor mínimo e o limite de 21 milhões de bitcoins). + Vários aspectos técnicos interessantes de um design foram discutidos, + incluindo alternativas às provas Utreexo para esta aplicação que + poderiam ser mais práticas. + +## Lançamentos e candidatos a lançamento + +_Novos lançamentos e candidatos a lançamento para projetos populares de infraestrutura +do Bitcoin. Por favor, considere atualizar para novos lançamentos ou ajudar a testar +candidatos a lançamento._ + +- [Core Lightning 25.05rc1][] é um candidato a lançamento para a próxima versão principal + desta implementação popular de nó LN. + +- [LND 0.19.1-beta.rc1][] é um candidato a lançamento para uma versão de manutenção + desta implementação popular de nó LN. + +## Mudanças notáveis em código e documentação + +_Mudanças recentes notáveis no [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], e [BINANAs][binana repo]._ + +- [Bitcoin Core #32582][] adiciona novo logging para medir o desempenho da + [reconstrução de bloco compacto][topic compact block relay] rastreando o + tamanho total de transações que um nó solicita de seus pares + (`getblocktxn`), o número e tamanho total de transações que um nó envia + para seus pares (`blocktxn`), e adicionando um timestamp no início de + `PartiallyDownloadedBlock::InitData()` para rastrear quanto tempo apenas o passo + de busca no mempool leva (em modos de alta e baixa largura de banda). Veja Newsletter + [#315][news315 compact] para um relatório de estatísticas anterior sobre reconstrução + de bloco compacto. + +- [Bitcoin Core #31375][] adiciona uma nova ferramenta CLI `bitcoin -m` que envolve e + executa os binários [multiprocesso][multiprocess project] `bitcoin node` + (`bitcoind`), `bitcoin gui` (`bitcoinqt`), `bitcoin rpc` (`bitcoin-cli + -named`). Atualmente, estes funcionam da mesma forma que os + binários monolíticos, exceto que suportam a opção `-ipcbind` (veja Newsletter + [#320][news320 ipc]), mas melhorias futuras permitirão que um operador de nó + inicie e pare componentes independentemente em diferentes máquinas e + ambientes. Veja [Newsletter #353][news353 pr review] para um Bitcoin Core PR + Review Club cobrindo este PR. + +- [BIPs #1483][] incorpora [BIP77][] que propõe [payjoin v2][topic payjoin], uma + variante assíncrona sem servidor na qual o remetente e receptor entregam seus + PSBTs criptografados para um servidor de diretório payjoin que apenas armazena e encaminha + mensagens. Como o diretório não pode ler ou alterar as cargas úteis, nenhuma carteira + precisa hospedar um servidor público ou estar online ao mesmo tempo. Veja Newsletter + [#264][news264 payjoin] para contexto adicional sobre payjoin v2. + +{% include snippets/recap-ad.md when="2025-06-10 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32582,31375,1483" %} +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[ripple loss]: https://x.com/JoelKatz/status/1919233214750892305 +[sk nowit]: https://delvingbitcoin.org/t/witnessless-sync-for-pruned-nodes/1742/ +[sk nowit gist]: https://gist.github.com/JoseSK999/df0a2a014c7d9b626df1e2b19ccc7fb1 +[somsen nowit]: https://gist.github.com/JoseSK999/df0a2a014c7d9b626df1e2b19ccc7fb1?permalink_comment_id=5597316#gistcomment-5597316 +[shikhelman quantum]: https://delvingbitcoin.org/t/bitcoin-and-quantum-computing/1730/ +[sm report]: https://chaincode.com/bitcoin-post-quantum.pdf +[strnad limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/ +[problema da mochila]: https://en.wikipedia.org/wiki/Knapsack_problem +[sanders limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/2 +[maxwell limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/4 +[linus dust]: https://delvingbitcoin.org/t/dust-expiry-clean-the-utxo-set-from-spam/1707/ +[lnd 0.19.1-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.1-beta.rc1 +[news315 compact]: /en/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction +[multiprocess project]: https://github.com/ryanofsky/bitcoin/blob/pr/ipc/doc/design/multiprocess.md +[news320 ipc]: /en/newsletters/2024/09/13/#bitcoin-core-30509 +[news264 payjoin]: /en/newsletters/2023/08/16/#serverless-payjoin +[news353 pr review]: /en/newsletters/2025/05/09/#bitcoin-core-pr-review-club \ No newline at end of file From 75c351aa7c77a1f7dd2962b41534044eecbcfad5 Mon Sep 17 00:00:00 2001 From: BitTom Date: Thu, 12 Jun 2025 21:24:17 +0800 Subject: [PATCH 085/278] Newsletter-189: translate into Chinese (#2336) --- .../zh/newsletters/2022-03-02-newsletter.md | 56 +++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 _posts/zh/newsletters/2022-03-02-newsletter.md diff --git a/_posts/zh/newsletters/2022-03-02-newsletter.md b/_posts/zh/newsletters/2022-03-02-newsletter.md new file mode 100644 index 0000000000..912f5a004f --- /dev/null +++ b/_posts/zh/newsletters/2022-03-02-newsletter.md @@ -0,0 +1,56 @@ +--- +title: 'Bitcoin Optech Newsletter #189' +permalink: /zh/newsletters/2022/03/02/ +name: 2022-03-02-newsletter-zh +slug: 2022-03-02-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周 Newsletter 介绍了新提议的 `OP_EVICT` opcode，并照例附上新版本与候选发布摘要以及值得注意的比特币基础设施软件变更。 + +## 新闻 + +- ******提议简化共享 UTXO 所有权的 opcode：** 开发者 ZmnSCPxj 在 Bitcoin-Dev 邮件列表[发布][zmnscpxj op_evict]了 `OP_EVICT` opcode 的提案，用以替代[此前提议的][news166 tluv] `OP_TAPLEAF_UPDATE_VERIFY`（TLUV）opcode。与 TLUV 类似，`OP_EVICT` 聚焦于多于两名用户共同拥有单个 UTXO 的场景，例如 [joinpools][topic joinpools]、[channel factories][topic channel factories] 以及某些[契约][topic covenants]。 + 为了理解 `OP_EVICT` 的工作方式，设想一个 joinpool，其中单个 UTXO 由 Alice、Bob、Carol 和 Dan 四位用户共同控制。 + + 目前，这四位用户可以创建一个 P2TR（taproot）输出，其 keypath 花费允许他们使用类似 [MuSig2][topic musig] 的协议，只要所有人共同参与签名即可高效支配该输出。但如果 Dan 离线或作恶，Alice、Bob 与 Carol 想要继续保持 joinpool 的隐私与效率优势，就只能事先与 Dan 准备一棵预签名交易树——并非所有交易都一定要用到，但必须都已准备好才能确保完全的容错能力。 + + {:.center} + [![使用预签名交易在无需信任地退出 joinpool 时所产生的组合爆炸示意图](/img/posts/2022-03-combinatorial-txes.dot.png)](/img/posts/2022-03-combinatorial-txes.dot.png) + + 随着共享 UTXO 的用户数量增加，需要创建的预签名交易数量呈组合式激增，使得这种方案极度缺乏可扩展性（仅 10 位用户就需预签超过一百万笔交易）。其他提议的 opcode，如 TLUV 和 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]，可消除这种组合爆炸。`OP_EVICT` 达成了同样目的，并且 ZmnSCPxj 建议在此用例下它相比上述 opcode 可能更优，因为在移除共享 UTXO 成员时所需的链上数据更少。 + + 如果 `OP_EVICT` 通过软分叉被加入，每位成员可向其他成员共享自己的公钥及其针对某个输出（例如 Alice 1 BTC、Bob 2 BTC 等）所做的签名。在获取所有成员的公钥与签名后，大家即可“无需信任”地构造一个地址，以两种方式花费资金： + + 1. 使用前述 taproot keypath 花费； + 2. 使用包含 `OP_EVICT` opcode 的 [tapscript][topic tapscript] scriptpath 花费。 + +
若要逐出 Dan，opcode 将接收以下参数： + + - ******共享公钥：** 整个群组的共享公钥，可通过对模板的单字节引用进行高效传递； + - ******逐出数量：** 要创建的 joinpool 退出输出数量（此例为 1）； + - ******逐出输出：** 针对该输出（即 Dan 的退出输出）提供其索引位置与 Dan 对其的签名。Dan 的公钥与其签名的输出中所用的公钥相同； + - ******未被逐出者的签名：** 对于共享公钥中扣除逐出输出所用公钥后的公钥，提供一个签名。换言之，由剩余成员（此例中为 Alice、Bob 与 Carol）提供的签名。 + + 这样，Alice、Bob 与 Carol 可在任何时间创建一笔交易来花费该群组 UTXO，而无需 Dan 的配合：他们在交易中加入 Dan 之前已签名的输出及其签名，再由 Alice、Bob 与 Carol 动态对整笔支出交易进行签名（该签名覆盖他们选择支付的手续费并按其意愿分配剩余资金）。 + + 截至撰写时，`OP_EVICT` 在邮件列表上获得了适度讨论，尚未出现重大疑虑，但热度似乎与去年 TLUV 提案相仿——均不算高。 + +## 发布与候选发布 + +*面向热门比特币基础设施项目的新版本与候选发布。请考虑升级至最新版本或协助测试候选版本。* + +- [BTCPay Server 1.4.6][] 是这款支付处理软件的最新发布版本。自 Optech 上次覆盖的版本以来，新增了对 [CPFP][topic cpfp] 手续费追加的支持、对 LN URL 更多特性的支持，以及多项 UI 改进。 + +## 值得注意的代码与文档变更 + +*本周在 [Bitcoin Core][bitcoin core repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中的值得注意变更：* + +- [HWI #550][] 为 Ledger 硬件签名设备的最新可加载比特币固件提供支持，该固件原生支持版本 2 [部分签名的比特币交易][topic psbt]以及一部分[输出脚本描述符][topic descriptors]。 + +{% include references.md %} +{% include linkers/issues.md v=1 issues="550" %} +[btcpay server 1.4.6]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.4.6 +[zmnscpxj op_evict]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html +[news166 tluv]: /zh/newsletters/2021/09/15/#covenant-opcode-proposal From a5344cf9327c48f0c5e92060c1add6e985f1a302 Mon Sep 17 00:00:00 2001 From: BitTom Date: Thu, 12 Jun 2025 21:26:21 +0800 Subject: [PATCH 086/278] Newsletter-190: translate into Chinese (#2337) --- .../zh/newsletters/2022-03-09-newsletter.md | 115 ++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 _posts/zh/newsletters/2022-03-09-newsletter.md diff --git a/_posts/zh/newsletters/2022-03-09-newsletter.md b/_posts/zh/newsletters/2022-03-09-newsletter.md new file mode 100644 index 0000000000..749abdc118 --- /dev/null +++ b/_posts/zh/newsletters/2022-03-09-newsletter.md @@ -0,0 +1,115 @@ +--- +title: 'Bitcoin Optech Newsletter #190' +permalink: /zh/newsletters/2022/03/09/ +name: 2022-03-09-newsletter-zh +slug: 2022-03-09-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的 Newsletter 描述了关于未来软分叉应该在多大程度上提升 Bitcoin Script 与 Tapscript 语言表达能力的多方面讨论，并总结了一项向洋葱消息转发带宽收费的提议。文末照例包含 Bitcoin Core PR 审查俱乐部会议摘要、新版软件发布与候选发布公告，以及对流行比特币基础设施项目“值得注意的”代码与文档变更的介绍。 + +## News + +- ******限制 Script 语言表达能力：** + 在 Bitcoin-Dev 邮件列表上，由于向 Script 提议新增 `OP_TXHASH` 或 `OP_TX` 操作码（见 Newsletter [#185][news185 optxhash] 与 [#187][news187 optx]），衍生出了若干子讨论。Jeremy Rubin [指出][rubin recurse]，这些提议（可能再结合如 [OP_CAT 操作码][OP_CAT]等其他操作码提案）或将允许创建递归[契约][topic covenants]——也就是随后重花这些比特币或与其合并的任何比特币时，交易都必须永久满足的条件。[有人][harding recurse]询问是否有人担心在比特币中允许递归契约，下面总结了一些最“值得注意的”担忧： + + - *****渐进式丧失抗审查性：* 贡献者 Shinobi [重申][shinobi recurse]他在 [Newsletter #157][news157 csfs] 中提出过的担忧，即递归契约可能让强大的第三方控制其当前掌握的任意币后续的花费。例如，政府可以（通过立法）要求其公民只接受政府之后可没收的币（由比特币共识规则强制实施）。 + + 对 Shinobi 帖子的[回复][aj reply]以及另一位开发者的[回应][darosior reply]呼应了[一年前][harding altcoin]的论点：用户切换到具有同样第三方控制要求的替代加密货币（altcoin）或类似侧链的结构，同样也可能导致抗审查性的逐步丧失。 + + - *****鼓励不必要的计算：* 开发者 James O'Beirne [表达][obeirne reply]了担忧，认为过度提升 Bitcoin Script 或 [Tapscript][topic tapscript] 的表达能力，会鼓励创建包含多于花费授权所必需操作的脚本。理想情况下，任何 UTXO（币）今天都可以用一条简洁的证明来花费，例如 64 字节的 [schnorr 签名][topic schnorr signatures]。比特币已允许更复杂的脚本来创建合约，如多签合约与 LN 之类协议，但这种能力也可能被滥用于在脚本中加入并非合约必要的操作。例如，比特币过去曾因被精心设计以重复消耗大量 CPU 或内存的交易而面临[拒绝服务风险][cve-2013-2292]。O'Beirne 担心增加表达能力既可能产生新的 DoS 向量，也可能导致程序员编写未优化、消耗节点资源超出必要的脚本。 + + - *****引入图灵完备性：* 开发者 ZmnSCPxj [批评][zmn turing]允许创建*故意*递归契约的操作码，也可能导致*意外*创建递归契约。投入递归契约的资金，无论故意还是意外，都再也无法与普通比特币完全同质化。ZmnSCPxj 将此担忧置于[图灵完备性][turing completeness]与[停机问题][halting problem]的语境下阐述。 + + - *****促成 drivechain：* 在前述图灵完备性的论点基础上，ZmnSCPxj 进一步[主张][zmn drivechains]，提升 Script 表达能力还会促成类似 [BIP300][] 所述的[侧链][topic sidechains]（drivechains）的实现，而多位 Bitcoin 开发者曾[指出][towns drivechains]这可能导致用户资金损失或抗审查性下降。如果比特币经济体中不够多的节点选择运行全节点并强制执行 drivechain 规则，那么 drivechain 用户可能丢失资金；但若经济体中大部分节点都选择执行 drivechain 规则，则其他想保持共识的用户就得验证该 drivechain 的全部数据，事实上在未经过显式软分叉修改比特币规则的情况下，把 drivechain 纳入了比特币。 + + 该子话题展开了长时间讨论，产生了一个[衍生线程][drivechains vs ln]，比较在多数算力试图窃币时 drivechain 与 LN 的安全性。 + +- ******为洋葱消息付费：** + Olaoluwa Osuntokun 本周在 Lightning-Dev 邮件列表[发帖][osuntokun bandwidth]，讨论让节点为其发送[洋葱消息][topic onion messages]所用带宽付费的可能性。此前提议的洋葱消息协议允许一个节点沿 LN 路径向另一节点发送消息，而无需使用 [HTLC][topic htlc]。与基于 keysend 的 HTLC 消息相比，洋葱消息的主要优势在于无需临时锁定比特币，从而更省成本且更灵活（例如即便双方之间没有通道，也能发送洋葱消息）。然而发送洋葱消息没有直接的经济成本，也令一些开发者担心其被用于在 LN 上免费转发流量，增加运营 LN 节点的开销，并激励大量节点关闭洋葱消息转发功能。如果洋葱消息被用于节点之间的重要通信（如[报价][topic offers]提案），此问题尤为严重。 + + Osuntokun 提议节点可预付其希望使用的洋葱消息带宽。例如，Alice 想通过 Bob 与 Carol 向 Zed 转发 10 kB 数据，她首先使用[AMP][topic amp] 向 Bob 与 Carol 预付各自按节点公布费率计的至少 10 kB 带宽费。在支付时，Alice 向他们各注册一个唯一会话 ID，并在请求他们转发的加密消息中包含该 ID。如果 Alice 预付金额足以覆盖消息带宽消耗，Bob 与 Carol 就会协助把消息转发给 Zed。 + + Rusty Russell[回复][russell reply]并提出数点批评，主要包括： + + - *****HTLC 当前已基本免费：* 针对“洋葱消息免费转发”担忧的主要反驳是，使用 HTLC 本就可以在 LN 上几乎免费转发流量。[^htlcs-essentially-free] 但尚不确定这种情况能否永久维持——许多修复[通道阻塞攻击][topic channel jamming attacks]的提案都建议对失败的 HTLC 收费，而这正是目前可用于免费传输数据的手段。 + + - *****会话标识符削弱隐私：* 在前述例子中，Alice 在 Bob 与 Carol 处注册的会话 ID 让两者可以知道哪些消息源自同一用户。若无会话 ID，他们无法分辨消息是否来自同一用户，或是来自多位使用同一路径片段的不同用户。Russell 指出，他在洋葱消息研究过程中考虑过盲化令牌，但担心“很快会变得复杂”。 + + Russell 因此建议，仅对节点转发的洋葱消息数量进行速率限制（针对不同类别的对等体设定不同上限）。 + +## Bitcoin Core PR Review Club + +*在本月度板块中，我们总结一次最近的 [Bitcoin Core PR Review Club][] 会议，突出其中的重要问答。点击下面的问题可查看会议答案摘要。* + +[向监听非默认端口的节点建立 p2p 连接][reviews 23542] 是 Vasil Dimov 的一个 PR，用于移除在出站节点选择中对 8333 端口的优待。参与者讨论了 Bitcoin Core 的自动连接行为、没有默认端口的网络优势，以及避开特定端口的理由。 + +{% include functions/details-list.md + q0="默认端口 8333 获得优待的历史原因是什么？" + a0="该行为自始即存在，但中本聪的动机尚不确定。常见传闻称此举可避免通过 gossip 地址来利用比特币网络对某服务发起 DoS，但这并非真实的历史原因。另一种说法是，默认端口有助于防止攻击者仅用一个 IP 地址配合多个端口（即我们现在所说的 [eclipse 攻击][topic eclipse attacks]）就控制节点的 IP 地址表和 P2P 连接。" + a0link="https://bitcoincore.reviews/23542#l-43" + + q1="移除端口 8333 的优待有什么好处？" + a1="最初用于过滤并存储潜在对等体 IP 地址的方法并不如今日这般复杂；我们现在按地址的 netgroup、AS、来源对等体等限制存储的 IP 数量，也对处理和转发的地址总量进行速率限制。鉴于对地址管理器（addrman）和地址转发所做的这些改进，该优待对防止 eclipse 与 DoS 攻击几乎已无影响。此外，偏好默认端口意味着几乎不会连接到监听非默认端口的节点。这也是一个隐私泄露点，本地网络管理员只需监测 8333 端口即可轻松识别比特币流量。若某政府想要封禁比特币，要求 ISP 记录或阻止单一端口的流量，比监测所有连接数据来识别比特币流量要容易得多。" + a1link="https://bitcoincore.reviews/23542#l-72" + + q2="在此次修改前，自动连接确实会倾向跳过非默认端口，但并非绝对不连。在哪些情况下节点仍会连接此类对等体？" + a2="在自动连接逻辑中，节点会尝试随机选取地址管理器中的地址进行连接。如果 50 次尝试均未成功，它就会开始考虑非默认端口的地址。有参与者指出，功能测试中的节点也不使用默认端口，但随后有人指出这些连接是人工手动建立的，而非自动出站连接。" + a2link="https://bitcoincore.reviews/23542#l-123" + + q3="合并该 PR 后，默认端口仍在 Bitcoin Core 中扮演什么角色？" + a3="当未指定端口时，会使用默认端口。这对 DNS 种子尤为重要，新节点需通过它们来为地址管理器引导地址。若要彻底移除“默认端口”概念，则需寻找替代方案，因为 DNS 旨在把域名解析为 IP 地址，而非提供服务的地址与端口。" + a3link="https://bitcoincore.reviews/23542#l-137" + + q4="为什么允许调用方向 CServiceHash 传入 salt，并在提交 [d0abce9][salt commit] 中以 CServiceHash(0, 0) 初始化？" + a4="节点大约每 24 小时公告自己的地址，每个节点还会 gossip 所获传闻地址，帮助网络发现新对等体。该代码使用 IP 地址与当前时间的哈希，随机挑选一到两个对等体转发最近接收的地址。但我们不希望仅通过多次发送同一地址就能提升其传播概率，因此大家使用相同的 salt (0, 0) 与按天取整的时间戳。" + a4link="https://bitcoincore.reviews/23542#l-197" +%} + +## 发布与候选发布 + +*流行比特币基础设施项目的新版本与候选版本。请考虑升级到新版本，或帮助测试候选版本。* + +- [LDK 0.0.105][] 新增对幻影节点支付的支持（见 [Newsletter #188][news188 phantom]）以及更好的概率付款路径寻找（见 [Newsletter #186][news186 pp]），同时还带来多项其他功能与缺陷修复（包括[两个潜在的 DoS 漏洞][rl dos]）。 + +## “值得注意的”代码与文档变更 + +*本周在 [Bitcoin Core][bitcoin core repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中的“值得注意的”变更。* + +- [Bitcoin Core #23542][] 移除了 Bitcoin Core 仅连接至默认端口（主网 8333）的偏好。现在，Bitcoin Core 会连接除少数被其他服务占用的端口外的任何端口。8333 仍是 Bitcoin Core 本地绑定的默认端口，因此仅当节点修改默认端口时，才会公告自己接受其他端口的连接。关于此变更的更多信息，可参阅本期 Newsletter 前文 *Bitcoin Core PR 审查俱乐部* 的摘要。 + +- [BDK #537][] 将钱包地址缓存重构为公共方法。此前，确保钱包内部数据库已加载并缓存地址只能通过内部函数实现——这意味着离线钱包无法保证数据库已经加载地址。此补丁使离线钱包用于多签签名以及验证找零地址等场景成为可能。相关地，[BDK #522][] 添加了内部地址 API，方便应用创建将一个输出拆分成多个小输出的交易。 + +## 脚注 + +[^htlcs-essentially-free]: + 当用户 Alice 通过路由节点 Bob 与 Carol 把基于 HTLC 的 keysend 消息转发给用户 Zed 时，Alice 可构造一个没有已知先像的哈希，使 HTLC 注定失败，从而 Bob 与 Carol 都拿不到钱。Alice 发送此类消息所承担的唯一成本，是她（若由她创建）创建通道的费用及随后关闭通道（若由她承担）时的费用——再加上如果攻击者盗取其 LN 热钱包私钥或其他可能危及通道的数据的风险。对于一个安全且无漏洞、有长期通道的节点而言，这些成本应当基本为零，因此基于 HTLC 的 keysend 消息当前可视作免费。 + +{% include references.md %} +{% include linkers/issues.md v=1 issues="23542,522,537" %} +[ldk 0.0.105]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.105#security +[news185 optxhash]: /zh/newsletters/2022/02/02/#composable-alternatives-to-ctv-and-apo +[news187 optx]: /zh/newsletters/2022/02/16/#simplified-alternative-to-op-txhash +[rubin recurse]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019872.html +[shinobi recurse]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019891.html +[news157 csfs]: /zh/newsletters/2021/07/14/#request-for-op-checksigfromstack-design-suggestions +[darosior reply]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019892.html +[aj reply]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019923.html +[harding altcoin]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019203.html +[obeirne reply]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019890.html +[cve-2013-2292]: /en/topics/cve/#CVE-2013-2292 +[zmn turing]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019928.html +[zmn drivechains]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019976.html +[turing completeness]: https://en.wikipedia.org/wiki/Turing_completeness +[halting problem]: https://en.wikipedia.org/wiki/Halting_problem +[towns drivechains]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019984.html +[drivechains vs ln]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019991.html +[osuntokun bandwidth]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003498.html +[russell reply]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003499.html +[harding recurse]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019885.html +[rl dos]: https://github.com/lightningdevkit/rust-lightning/blob/main/CHANGELOG.md#security +[news188 phantom]: /zh/newsletters/2022/02/23/#ldk-1199 +[news186 pp]: /zh/newsletters/2022/02/09/#ldk-1227 +[salt commit]: https://github.com/bitcoin-core-review-club/bitcoin/commit/d0abce9a50dd4f507e3a30348eabffb7552471d5 +[reviews 23542]: https://bitcoincore.reviews/23542 From 44350d9df59ed9fd3fe70ab311d1e830ff310133 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 12 Jun 2025 08:55:05 -0500 Subject: [PATCH 087/278] Blog: BTSE post update --- _includes/articles/dong-btse-operation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_includes/articles/dong-btse-operation.md b/_includes/articles/dong-btse-operation.md index 67456e486b..2d0630b7c7 100644 --- a/_includes/articles/dong-btse-operation.md +++ b/_includes/articles/dong-btse-operation.md @@ -3,7 +3,7 @@ [BTSE](https://www.btse.com/en/home) uses segwit, BIP32 HD wallets, and multisig key management to reduce their operational burdens and improve fund safety. For this Optech field report, we interviewed BTSE staff to learn how their exchange operations have benefited from these Bitcoin technologies. -BIP32 is a widely-implemented [standard][BIP32] that describes how to deterministically derive arbitrarily-many new public keys [from a single extended public key](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Unsecure_money_receiver_NmisubHsub0), even if the corresponding private key is kept offline. Without BIP32, the burden of securely storing private keys would incentivize reuse of public keys and addresses, leading to [problems](https://en.bitcoin.it/wiki/Address_reuse) that include exchange front-running and user loss of privacy. Speaking about the operational advantages of cold wallet deposits for users, BTSE's CEO Jonathan Leong notes that "if the hot wallet keys are compromised, addresses for all users would have to be re-generated, and inevitably some users would continue to send funds to their old addresses." +BIP32 is a widely-implemented [standard][BIP32] that describes how to deterministically derive arbitrarily-many new public keys [from a single extended public key](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Unsecure_money_receiver_NmisubHsub0), even if the corresponding private key is kept offline. Without BIP32, the burden of securely storing private keys would incentivize reuse of public keys and addresses, leading to [problems](https://en.bitcoin.it/wiki/Address_reuse) that include exchange front-running and user loss of privacy. Speaking about the operational advantages of cold wallet deposits for users, BTSE's CEO notes that "if the hot wallet keys are compromised, addresses for all users would have to be re-generated, and inevitably some users would continue to send funds to their old addresses." Although exchanges using BIP32 can keep their private key offline, that private key is still a single point of failure. Happily, they can lessen the impact of compromise of any one single key by constructing a k-of-n multisig address with each of the n public keys derived from a different extended public key. What BTSE achieves with this combination is on-the-fly generation of arbitrarily-many addresses that all deposit straight into a multisig cold wallet without needing to touch the private keys. From 21a5f9fd4759f1eca8426bbda92455a7db86a2be Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 12 Jun 2025 12:18:34 -0500 Subject: [PATCH 088/278] Podcast: add 357 recap --- .../en/newsletters/2025-06-06-newsletter.md | 18 +++++++------- .../en/podcast/2025-06-10-newsletter-recap.md | 24 +++++++++++++++++++ 2 files changed, 33 insertions(+), 9 deletions(-) create mode 100644 _posts/en/podcast/2025-06-10-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-06-06-newsletter.md b/_posts/en/newsletters/2025-06-06-newsletter.md index cfb60b524c..c903798c85 100644 --- a/_posts/en/newsletters/2025-06-06-newsletter.md +++ b/_posts/en/newsletters/2025-06-06-newsletter.md @@ -43,7 +43,7 @@ popular Bitcoin infrastructure software. existence of the data, it could conceivably be lost, as [has happened][ripple loss] to at least one altcoin. - The discussion was ongoing at the time of writing. + The discussion was ongoing at the time of writing. {% assign timestamp="1:30" %} ## Changing consensus @@ -59,7 +59,7 @@ Bitcoin's consensus rules._ million BTC are potentially vulnerable to quantum theft, some mitigation now is possible, Bitcoin mining is unlikely to be threatened by quantum computing in the short or medium term, and - upgrading requires widespread agreement. + upgrading requires widespread agreement. {% assign timestamp="17:38" %} - **Transaction weight limit with exception to prevent confiscation:** Vojtěch Strnad [posted][strnad limit] to Delving Bitcoin to propose @@ -98,7 +98,7 @@ Bitcoin's consensus rules._ Additional discussion examined the needs of parties wanting large transactions, mainly [BitVM][topic acc] users in the near term, - and whether alternative approaches were available to them. + and whether alternative approaches were available to them. {% assign timestamp="41:49" %} - **Removing outputs from the UTXO set based on value and time:** Robin Linus [posted][linus dust] to Delving Bitcoin to propose a soft fork @@ -120,7 +120,7 @@ Bitcoin's consensus rules._ set (assuming a minimum value and the 21 million bitcoin limit). Several interesting technical aspects of a design were discussed, including alternatives to utreexo proofs for this application that - could be more practical. + could be more practical. {% assign timestamp="53:47" %} ## Releases and release candidates @@ -129,10 +129,10 @@ projects. Please consider upgrading to new releases or helping to test release candidates._ - [Core Lightning 25.05rc1][] is a release candidate for the next major - version of this popular LN node implementation. + version of this popular LN node implementation. {% assign timestamp="1:07:45" %} - [LND 0.19.1-beta.rc1][] is a release candidate for a maintenance - version of this popular LN node implementation. + version of this popular LN node implementation. {% assign timestamp="1:08:02" %} ## Notable code and documentation changes @@ -153,7 +153,7 @@ repo], and [BINANAs][binana repo]._ `PartiallyDownloadedBlock::InitData()` to track how long the mempool lookup step alone takes (in both high and low-bandwidth modes). See Newsletter [#315][news315 compact] for a previous statistics report on compact block - reconstruction. + reconstruction. {% assign timestamp="1:09:08" %} - [Bitcoin Core #31375][] adds a new `bitcoin -m` CLI tool that wraps and executes the [multiprocess][multiprocess project] binaries `bitcoin node` @@ -163,14 +163,14 @@ repo], and [BINANAs][binana repo]._ [#320][news320 ipc]), but future improvements will enable a node runner to start and stop components independently on different machines and environments. See [Newsletter #353][news353 pr review] for a Bitcoin Core PR - Review Club covering this PR. + Review Club covering this PR. {% assign timestamp="1:11:07" %} - [BIPs #1483][] merges [BIP77][] which proposes [payjoin v2][topic payjoin], an asynchronous serverless variant in which the sender and receiver hand their encrypted PSBTs to a payjoin directory server that only stores and forwards messages. As the directory cannot read or alter the payloads, neither wallet needs to host a public server or be online at the same time. See Newsletter - [#264][news264 payjoin] for additional context on payjoin v2. + [#264][news264 payjoin] for additional context on payjoin v2. {% assign timestamp="1:14:16" %} {% include snippets/recap-ad.md when="2025-06-10 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-06-10-newsletter-recap.md b/_posts/en/podcast/2025-06-10-newsletter-recap.md new file mode 100644 index 0000000000..2d72db540e --- /dev/null +++ b/_posts/en/podcast/2025-06-10-newsletter-recap.md @@ -0,0 +1,24 @@ +--- +title: 'Bitcoin Optech Newsletter #357 Recap Podcast' +permalink: /en/podcast/2025/06/10/ +reference: /en/newsletters/2025/06/06/ +name: 2025-06-10-recap +slug: 2025-06-10-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt are joined by Jose SK, Clara Shikhelman, +Vojtěch Strnad, Robin Linus, and Dan Gould to discuss [Newsletter #357]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-5-12/402052376-44100-2-c5f2f42f2a6b7.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From b842e39439928e088e476d788bbcc20080f1ac9a Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Tue, 10 Jun 2025 23:08:35 -1000 Subject: [PATCH 089/278] Newsletters: add 358 (2025-06-13) --- .../en/newsletters/2025-06-13-newsletter.md | 162 ++++++++++++++++++ 1 file changed, 162 insertions(+) create mode 100644 _posts/en/newsletters/2025-06-13-newsletter.md diff --git a/_posts/en/newsletters/2025-06-13-newsletter.md b/_posts/en/newsletters/2025-06-13-newsletter.md new file mode 100644 index 0000000000..be2b7d167f --- /dev/null +++ b/_posts/en/newsletters/2025-06-13-newsletter.md @@ -0,0 +1,162 @@ +--- +title: 'Bitcoin Optech Newsletter #358' +permalink: /en/newsletters/2025/06/13/ +name: 2025-06-13-newsletter +slug: 2025-06-13-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter describes how the selfish mining danger threshold +can be calculated, summarizes an idea about preventing filtering of high +feerate transactions, seeks feedback about a proposed change to BIP390 +`musig()` descriptors, and announces a new library for encrypting +descriptors. Also included are our regular sections with the summary of +a Bitcoin Core PR Review Club, announcements of new releases and release +candidates, and descriptions of recent changes to popular Bitcoin +infrastructure projects. + +## News + +- **Calculating the selfish mining danger threshold:** Antoine Poinsot + [posted][poinsot selfish] to Delving Bitcoin an expansion of the math + from the 2013 [paper][es selfish] that gave the [selfish mining + attack][topic selfish mining] its name (although the attack was + [previously described][bytecoin selfish] in 2010). He also provided a + simplified mining and block relay + [simulator][darosior/miningsimulation] that allows experimenting with + the attack. He focuses on reproducing one of the conclusions of the + 2013 paper: that a dishonest miner (or a cartel of well-connected + miners) controlling 33% of the total network hashrate, with no additional + advantages, can become marginally more profitable on a long term basis + than the miners controlling 67% of the hashrate. This is + achieved by the 33% miner selectively delaying the announcement of some of + the new blocks it finds. As the dishonest miner's hashrate increases + above 33%, it becomes even more profitable until it exceeds 50% + hashrate and can prevent its competitors from keeping any new + blocks on the best blockchain. + + We did not carefully review Poinsot's post, but his approach appeared + sound to us and we would recommend it to anyone interested in + validating the math or gaining a better understanding of it. + +- **Relay censorship resistance through top mempool set reconciliation:** + Peter Todd [posted][todd feerec] to the Bitcoin-Dev mailing list about + a mechanism that would allow nodes to drop peers that are filtering + high-feerate transactions. The mechanism depends on [cluster + mempool][topic cluster mempool] and a set reconciliation mechanism + such as that used by [erlay][topic erlay]. A node would use cluster + mempool to calculate its most profitable set of unconfirmed + transactions that could fit within (for example) 8,000,000 weight units (a + maximum of 8 MB). Each of the node's peers would also calculate their top + 8 MWU of unconfirmed transactions. Using a highly efficient + algorithm, such as [minisketch][topic minisketch], the node would + reconcile its set of transactions with each of its peers. In doing + so, it would learn exactly what transactions each peer has in the top + of its mempool. Then the node would periodically drop the connection + to whichever peer had the least profitable mempool on average. + + By dropping the least profitable connections, the node would + eventually find peers that were least likely to filter out + high-feerate transactions. Todd mentioned that he hopes to work on an + implementation after cluster mempool support is merged into Bitcoin + Core. He credited the idea to Gregory Maxwell and others; Optech + first mentioned the underlying idea in [Newsletter #9][news9 + reconcile]. + +- **Updating BIP390 to allow duplicate participant keys in `musig()` expressions:** + Ava Chow [posted][chow dupsig] to the Bitcoin-Dev mailing list to ask + if anyone objected to updating [BIP390][] to allow `musig()` + expressions in [output script descriptors][topic descriptors] to + contain the same participant public key more than once. This would + simplify implementation and is explicitly allowed by the [BIP327][] + specification of [MuSig2][topic musig]. As of this writing, no one has + objected, and Chow has opened a [pull request][bips #1867] to change + the BIP390 specification. + +- **Descriptor encryption library:** Josh Doman [posted][doman descrypt] + to Delving Bitcoin to announce a library he's built that encrypts the + sensitive parts of an [output script descriptor][topic descriptors] or + [miniscript][topic miniscript] to the public keys contained within it. + He describes what information is needed to decrypt: + + > - If your wallet requires 2-of-3 keys to spend, it will require + > exactly 2-of-3 keys to decrypt. + > + > - If your wallet uses a complex miniscript policy like “Either 2 + > keys OR (a timelock AND another key)”, encryption follows the same + > structure, as if all timelocks and hash-locks are satisfied. + + This differs from the encrypted descriptor backup scheme discussed in + [Newsletter #351][news351 salvacrypt], in which knowledge of any + public key contained within the descriptor allows decryption of the + descriptor. Doman argues that his scheme provides better privacy for + cases where the encrypted descriptor is being backed up to a public or + semi-public source, such as a blockchain. + +## Bitcoin Core PR Review Club + +*In this monthly section, we summarize a recent [Bitcoin Core PR Review +Club][] meeting, highlighting some of the important questions and +answers. Click on a question below to see a summary of the answer from +the meeting.* + +FIXME:stickies-v + +{% include functions/details-list.md + q0="FIXME" + a0="FIXME" + a0link="https://bitcoincore.reviews/31375#l-40FIXME" +%} + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [Core Lightning 25.05rc1][] is a release candidate for the next major + version of this popular LN node implementation. + +- [LND 0.19.1-beta][] is a release of a maintenance version of this + popular LN node implementation. It [contains][lnd rn] multiple bug + fixes. + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [Bitcoin Core #32406][] policy: uncap datacarrier by default + +- [LDK #3793][] Implement `start_batch` message batching + +- [LDK #3792][] Channel Establishment for V3 Channels + +- [LND #9127][] Add the option on path creator to specify the incoming channel on blinded path + +- [LND #9858][] peer+feature: start to signal the prod rbf coop close bit + +- [BOLTs #1243][] Clarify Mandatory Field Length Requirements (#1243) + +{% include snippets/recap-ad.md when="2025-06-17 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32406,3793,3792,9127,1867,9858,1243" %} +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[lnd 0.19.1-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.1-beta +[poinsot selfish]: https://delvingbitcoin.org/t/where-does-the-33-33-threshold-for-selfish-mining-come-from/1757 +[bytecoin selfish]: https://bitcointalk.org/index.php?topic=2227.msg30083#msg30083 +[darosior/miningsimulation]: https://github.com/darosior/miningsimulation +[todd feerec]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aDWfDI03I-Rakopb@petertodd.org/ +[news9 reconcile]: /en/newsletters/2018/08/21/#bandwidth-efficient-set-reconciliation-protocol-for-transactions +[chow dupsig]: https://mailing-list.bitcoindevs.xyz/bitcoindev/08dbeffd-64ec-4ade-b297-6d2cbeb5401c@achow101.com/ +[doman descrypt]: https://delvingbitcoin.org/t/rust-descriptor-encrypt-encrypt-any-descriptor-such-that-only-authorized-spenders-can-decrypt/1750/ +[news351 salvacrypt]: /en/newsletters/2025/04/25/#standardized-backup-for-wallet-descriptors +[es selfish]: https://arxiv.org/pdf/1311.0243 +[lnd rn]: https://github.com/lightningnetwork/lnd/blob/v0.19.1-beta/docs/release-notes/release-notes-0.19.1.md From 5659bc98b2888d8bf884f221838fcbb1c56e28bc Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 12 Jun 2025 06:30:32 +0000 Subject: [PATCH 090/278] News358: add merge summaries --- .../en/newsletters/2025-06-13-newsletter.md | 62 +++++++++++++++---- 1 file changed, 51 insertions(+), 11 deletions(-) diff --git a/_posts/en/newsletters/2025-06-13-newsletter.md b/_posts/en/newsletters/2025-06-13-newsletter.md index be2b7d167f..2fb31a8825 100644 --- a/_posts/en/newsletters/2025-06-13-newsletter.md +++ b/_posts/en/newsletters/2025-06-13-newsletter.md @@ -133,17 +133,54 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Bitcoin Core #32406][] policy: uncap datacarrier by default - -- [LDK #3793][] Implement `start_batch` message batching - -- [LDK #3792][] Channel Establishment for V3 Channels - -- [LND #9127][] Add the option on path creator to specify the incoming channel on blinded path - -- [LND #9858][] peer+feature: start to signal the prod rbf coop close bit - -- [BOLTs #1243][] Clarify Mandatory Field Length Requirements (#1243) +- [Bitcoin Core #32406][] uncaps the `OP_RETURN` output size limit + (standardness rule) by raising the default `-datacarriersize` setting + from 83 to 100,000 bytes (the maximum transaction size limit). The + `-datacarrier` and `-datacarriersize` options remain, but are marked + as deprecated and are expected to be removed in an undetermined future release. + Additionally, this PR also lifts the one-per-transaction policy + restriction for OP_RETURN outputs, and the size limit is now allocated + across all such outputs in a transaction. See [Newsletter + #352][news352 opreturn] for additional context on this change. + +- [LDK #3793][] adds a new `start_batch` message that signals peers to + treat the next `n` (`batch_size`) messages as a single logical unit. + It also updates `PeerManager` to rely on this for `commitment_signed` + messages during [splicing][topic splicing], rather than adding a TLV + and a `batch_size` field to each message in the batch. This is an + attempt to allow additional LN protocol messages to be batched rather + than only `commitment_signed` messages, which is the only batching + defined in the LN specification. + +- [LDK #3792][] introduces initial support for [v3 commitment + transactions][topic v3 commitments] (see [Newsletter #325][news325 + v3]) that rely on [TRUC transactions][topic v3 transaction relay] and + [ephemeral anchors][topic ephemeral anchors], behind a test flag. A + node now rejects any `open_channel` proposal that sets a non-zero + feerate, ensures that it never initiates such channels itself, and + stops automatically accepting v3 channels to first reserve a UTXO for + later fee-bumping. The PR also lowers the per-channel [HTLC][topic + htlc] limit from 483 to 114 because TRUC transactions must remain + under 10 kvB. + +- [LND #9127][] adds a `--blinded_path_incoming_channel_list` option to + the `lncli addinvoice` command, allowing a recipient to embed one or + more (for multiple hops) preferred channel IDs for the payer to + attempt to forward through on a [blinded path][topic rv routing]. + +- [LND #9858][] begins signaling the production feature bit 61 for the + [RBF][topic rbf] cooperative close flow (see [Newsletter #347][news347 + rbf]) to properly enable interoperability with Eclair. It retains the + staging bit 161 to maintain interoperability with nodes testing the + feature. + +- [BOLTs #1243][] updates the [BOLT11][] specification to indicate that + a reader (sender) must not pay an invoice if a mandatory field, such + as p (payment hash), h (description hash), or s (secret), has an + incorrect length. Previously, nodes could ignore this issue. This PR + also adds a note to the Examples section explaining that [Low R + signatures][topic low-r grinding], even if they save one byte of + space, are not enforced in the specification. {% include snippets/recap-ad.md when="2025-06-17 16:30" %} {% include references.md %} @@ -160,3 +197,6 @@ repo], and [BINANAs][binana repo]._ [news351 salvacrypt]: /en/newsletters/2025/04/25/#standardized-backup-for-wallet-descriptors [es selfish]: https://arxiv.org/pdf/1311.0243 [lnd rn]: https://github.com/lightningnetwork/lnd/blob/v0.19.1-beta/docs/release-notes/release-notes-0.19.1.md +[news352 opreturn]: /en/newsletters/2025/05/02/#increasing-or-removing-bitcoin-core-s-op-return-size-limit +[news325 v3]: /en/newsletters/2024/10/18/#version-3-commitment-transactions +[news347 rbf]: /en/newsletters/2025/03/28/#lnd-8453 From 724e8a4bae32d668c50a8adf361a6f8b7c694e25 Mon Sep 17 00:00:00 2001 From: stickies-v Date: Thu, 12 Jun 2025 22:09:28 +0100 Subject: [PATCH 091/278] News358: add review club --- .../en/newsletters/2025-06-13-newsletter.md | 80 +++++++++++++++++-- 1 file changed, 73 insertions(+), 7 deletions(-) diff --git a/_posts/en/newsletters/2025-06-13-newsletter.md b/_posts/en/newsletters/2025-06-13-newsletter.md index 2fb31a8825..da09488512 100644 --- a/_posts/en/newsletters/2025-06-13-newsletter.md +++ b/_posts/en/newsletters/2025-06-13-newsletter.md @@ -83,8 +83,8 @@ infrastructure projects. > - If your wallet requires 2-of-3 keys to spend, it will require > exactly 2-of-3 keys to decrypt. > - > - If your wallet uses a complex miniscript policy like “Either 2 - > keys OR (a timelock AND another key)”, encryption follows the same + > - If your wallet uses a complex miniscript policy like "Either 2 + > keys OR (a timelock AND another key)", encryption follows the same > structure, as if all timelocks and hash-locks are satisfied. This differs from the encrypted descriptor backup scheme discussed in @@ -101,12 +101,73 @@ Club][] meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.* -FIXME:stickies-v +[Separate UTXO set access from validation functions][review club 32317] +is a PR by [TheCharlatan][gh thecharlatan] that allows calling +validation functions by passing just the required UTXOs, instead of +requiring the complete UTXO set. It is part of the [`bitcoinkernel` +project][Bitcoin Core #27587], and is an important step to make the +library more usable for full-node implementations that do not implement +a UTXO set, such as [Utreexo][topic utreexo] or [SwiftSync][somsen +swiftsync] nodes (see [Newsletter #349][news349 swiftsync]). + +In the first 4 commits, this PR reduces coupling between transaction +validation functions and the UTXO set by requiring the caller to first +fetch the `Coin`s or `CTxOut`s they require and passing those to the +validation function, instead of letting the validation function access +the UTXO set directly. + +In subsequent commits, the dependency of `ConnectBlock()` on the UTXO set +is removed entirely by carving out the remaining logic that requires UTXO +set interaction into a separate `SpendBlock()` method. {% include functions/details-list.md - q0="FIXME" - a0="FIXME" - a0link="https://bitcoincore.reviews/31375#l-40FIXME" + q0="Why is carving out the new `SpendBlock()` function from + `ConnectBlock()` helpful for this PR? How would you compare the + purpose of the two functions?" + a0="The `ConnectBlock()` function originally performed both block + validation and UTXO set modifications. This refactor splits these + responsibilities: `ConnectBlock()` is now only responsible for + validation logic that doesn't require the UTXO set, while the new + `SpendBlock()` function handles all UTXO set interactions. This allows + a caller to use `ConnectBlock()` to do block validation without a UTXO + set." + a0link="https://bitcoincore.reviews/32317#l-37" + + q1="Do you see another benefit of this decoupling, besides allowing + kernel usage without a UTXO set?" + a1="Besides enabling kernel usage for projects without a UTXO set, + this decoupling makes the code easier to test in isolation and simpler + to maintain. One reviewer also notes that removing the need for UTXO + set access opens the door for validating blocks in parallel, which is + an important feature of SwiftSync." + a1link="https://bitcoincore.reviews/32317#l-64" + + q2="`SpendBlock()` takes a `CBlock block`, `CBlockIndex pindex` and + `uint256 block_hash` parameter, all referencing the block being spent. + Why do we need 3 parameters to do that?" + a2="Validation code is performance-critical, it affects important + parameters such as block propagation speed. Calculating the block hash + from a `CBlock` or `CBlockIndex` is not free, because the value is not + cached. For that reason, the author decided to prioritize performance + by passing an already calculated `block_hash` as a separate parameter. + Similarly, the `pindex` could be fetched from the block index, but this + would involve an additional map lookup that is not strictly necessary. +
_Note: the author later [changed][32317 updated approach] the + approach, removing the `block_hash` performance optimization._" + a2link="https://bitcoincore.reviews/32317#l-97" + + q3="The first commits in this PR refactor `CCoinsViewCache` out of the + function signature of a couple of validation functions. Does + `CCoinsViewCache` hold the entire UTXO set? Why is that (not) a + problem? Does this PR change that behaviour?" + a3="`CCoinsViewCache` does not hold the entire UTXO set; it is an + in-memory cache that sits in front of `CCoinsViewDB`, which stores the + full UTXO set on disk. If a requested coin is not in the cache, it + must be fetched from disk. This PR does not change this caching + behavior itself. By removing `CCoinsViewCache` from function + signatures, it makes the UTXO dependency explicit, requiring the + caller to fetch coins before calling the validation function." + a3link="https://bitcoincore.reviews/32317#l-116" %} ## Releases and release candidates @@ -184,7 +245,7 @@ repo], and [BINANAs][binana repo]._ {% include snippets/recap-ad.md when="2025-06-17 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="32406,3793,3792,9127,1867,9858,1243" %} +{% include linkers/issues.md v=2 issues="32406,3793,3792,9127,1867,9858,1243,27587" %} [Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 [lnd 0.19.1-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.1-beta [poinsot selfish]: https://delvingbitcoin.org/t/where-does-the-33-33-threshold-for-selfish-mining-come-from/1757 @@ -200,3 +261,8 @@ repo], and [BINANAs][binana repo]._ [news352 opreturn]: /en/newsletters/2025/05/02/#increasing-or-removing-bitcoin-core-s-op-return-size-limit [news325 v3]: /en/newsletters/2024/10/18/#version-3-commitment-transactions [news347 rbf]: /en/newsletters/2025/03/28/#lnd-8453 +[review club 32317]: https://bitcoincore.reviews/32317 +[gh thecharlatan]: https://github.com/TheCharlatan +[somsen swiftsync]: https://gist.github.com/RubenSomsen/a61a37d14182ccd78760e477c78133cd +[32317 updated approach]: https://github.com/bitcoin/bitcoin/pull/32317#issuecomment-2883841466 +[news349 swiftsync]: /en/newsletters/2025/04/11/#swiftsync-speedup-for-initial-block-download From c6fde1eea8788fb9add1fd4c554eadb7b87686f1 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Fri, 13 Jun 2025 04:57:37 -0500 Subject: [PATCH 092/278] News358: add topics --- _topics/en/cluster-mempool.md | 4 ++ _topics/en/low-r-grinding.md | 3 + _topics/en/minisketch.md | 6 ++ _topics/en/output-script-descriptors.md | 3 + _topics/en/selfish-mining.md | 94 +++++++++++++++++++++++++ _topics/en/v3-commitments.md | 3 + 6 files changed, 113 insertions(+) create mode 100644 _topics/en/selfish-mining.md diff --git a/_topics/en/cluster-mempool.md b/_topics/en/cluster-mempool.md index e53b987152..57a618acdb 100644 --- a/_topics/en/cluster-mempool.md +++ b/_topics/en/cluster-mempool.md @@ -90,9 +90,13 @@ optech_mentions: - title: "Discovery of previous research for finding optimal cluster linearization" url: /en/newsletters/2025/02/07/#discovery-of-previous-research-for-finding-optimal-cluster-linearization + - title: "Comparison of cluster linearization techniques" url: /en/newsletters/2025/05/02/#comparison-of-cluster-linearization-techniques + - title: "Relay censorship resistance using cluster mempool and efficient set reconciliation" + url: /en/newsletters/2025/06/13/#relay-censorship-resistance-through-top-mempool-set-reconciliation + ## Optional. Same format as "primary_sources" above see_also: - title: Package relay diff --git a/_topics/en/low-r-grinding.md b/_topics/en/low-r-grinding.md index 174b4c7c6f..d467ca628f 100644 --- a/_topics/en/low-r-grinding.md +++ b/_topics/en/low-r-grinding.md @@ -37,6 +37,9 @@ optech_mentions: - title: "BDK #779 adds support for creating low-r signatures" url: /en/newsletters/2022/11/02/#bdk-779 + - title: "BOLTs #1243 updates BOLT11 to specify handling of low-r signatures on invoices" + url: /en/newsletters/2025/06/13/#bolts-1243 + ## Optional. Same format as "primary_sources" above see_also: - title: What is signature grinding? diff --git a/_topics/en/minisketch.md b/_topics/en/minisketch.md index a9eae814d2..917925fd0c 100644 --- a/_topics/en/minisketch.md +++ b/_topics/en/minisketch.md @@ -38,6 +38,12 @@ optech_mentions: - title: Research into interaction between LN rate limiting and minisketch gossiping url: /en/newsletters/2022/05/04/#ln-gossip-rate-limiting + - title: "Relay censorship resistance using cluster mempool and efficient set reconciliation" + url: /en/newsletters/2025/06/13/#relay-censorship-resistance-through-top-mempool-set-reconciliation + + - title: "New library for encrypting descriptors and miniscript to the included public keys" + url: /en/newsletters/2025/06/13/#descriptor-encryption-library + ## Optional. Same format as "primary_sources" above see_also: - title: Erlay diff --git a/_topics/en/output-script-descriptors.md b/_topics/en/output-script-descriptors.md index 3888274414..a418bd337d 100644 --- a/_topics/en/output-script-descriptors.md +++ b/_topics/en/output-script-descriptors.md @@ -197,6 +197,9 @@ optech_mentions: - title: "Proposed standard for backing up wallet descriptors" url: /en/newsletters/2025/04/25/#standardized-backup-for-wallet-descriptors + - title: "New library for encrypting descriptors and miniscript to the included public keys" + url: /en/newsletters/2025/06/13/#descriptor-encryption-library + ## Optional. Same format as "primary_sources" above see_also: - title: Miniscript diff --git a/_topics/en/selfish-mining.md b/_topics/en/selfish-mining.md new file mode 100644 index 0000000000..21b3aa0c05 --- /dev/null +++ b/_topics/en/selfish-mining.md @@ -0,0 +1,94 @@ +--- +title: Selfish mining + +## Optional. Shorter name to use for reference style links e.g., "foo" +## will allow using the link [topic foo][]. Not case sensitive +# shortname: foo + +## Optional. An entry will be added to the topics index for each alias +#title-aliases: +# - Foo + +## Required. At least one category to which this topic belongs. See +## schema for options +topic-categories: + - Mining + - Security Problems + +## Optional. Produces a Markdown link with either "[title][]" or +## "[title](link)" +primary_sources: + - title: "Mining Cartel Attack (2010)" + link: https://bitcointalk.org/index.php?topic=2227.msg30083#msg30083 + + - title: "Majority is not Enough (2013)" + link: https://arxiv.org/pdf/1311.0243 + +## Optional. Each entry requires "title" and "url". May also use "feature: +## true" to bold entry and "date" +optech_mentions: + - title: "Bitcoin Core #27278 improves logging that could indicate a selfish mining attack or other concerns" + url: /en/newsletters/2023/03/29/#bitcoin-core-27278 + + - title: "Discussion about weak block relay and unintentional selfish mining" + url: /en/newsletters/2024/04/24/#weak-blocks-proof-of-concept-implementation + + - title: "Selfish mining still possible despite centralized and decentralized block relay improvements" + url: /en/newsletters/2025/05/30/#is-selfish-mining-still-an-option-with-compact-blocks-and-fibre + + - title: Calculating the selfish mining danger threshold + url: /en/newsletters/2025/06/13/#calculating-the-selfish-mining-danger-threshold + +## Optional. Same format as "primary_sources" above +# see_also: +# - title: +# link: + +## Optional. Force the display (true) or non-display (false) of stub +## topic notice. Default is to display if the page.content is below a +## threshold word count +#stub: false + +## Required. Use Markdown formatting. Only one paragraph. No links allowed. +## Should be less than 500 characters +excerpt: > + **Selfish mining** allows a miner (or cartel of miners) controlling + less than a majority of hashrate to keep more block reward per unit of + work than the majority of honest miners. This effectively allows the + sub-majority to dictate block inclusion policy, including censoring + transactions. + +--- +The attack was first publicly [described][bytecoin sm] in 2010. It +later obtained its name _selfish mining_ from a 2013 [paper][es sm]. In +the form of attack requiring the fewest assumptions, the [math][poinsot +sm] shows that a miner with 1/3 of total network hashrate can obtain +marginally more block reward per unit of work than the other 2/3 of +honest miners. As the selfish miner increases hashrate towards 1/2 of +the network total, their block reward ratio increases. If they +consistently obtain more than 1/2 of the network total hashrate, they +can prevent other miners from keeping any blocks on the best chain, +allowing them to obtain all block reward and censor any transaction. + +There is no known practical solution to selfish mining for Bitcoin, +beyond attempting to ensure no miner or cartel of miners obtains 1/3 or +more of total hashrate. + +It is possible for selfish mining to occur accidentally, such as when +several large hashrate miners have low-latency connections to each other +but high-latency connections to the rest of the network. There were +indications that such accidental selfish mining occasionally occurred in +2015 when significant Bitcoin mining was located in China and that +country's [firewall][great firewall] contributed significant latency to +block propagation. Mitigating this concern, as +well as addressing other problems, inspired the development of +centralized block relay solutions (such as FIBRE and FALCON) and +decentralized block relay improvements (such as [compact block +relay][topic compact block relay]). + +{% include references.md %} +{% include linkers/issues.md issues="" %} +[great firewall]: https://en.wikipedia.org/wiki/Great_Firewall +[bytecoin sm]: https://bitcointalk.org/index.php?topic=2227.msg30083#msg30083 +[es sm]: https://arxiv.org/pdf/1311.0243 +[poinsot sm]: https://delvingbitcoin.org/t/where-does-the-33-33-threshold-for-selfish-mining-come-from/1757 diff --git a/_topics/en/v3-commitments.md b/_topics/en/v3-commitments.md index 996e4a8f35..ddf5a73445 100644 --- a/_topics/en/v3-commitments.md +++ b/_topics/en/v3-commitments.md @@ -35,6 +35,9 @@ optech_mentions: - title: Using v3 commitments to allow mobile wallets to settle channels without extra UTXOs url: /en/newsletters/2025/02/21/#allowing-mobile-wallets-to-settle-channels-without-extra-utxos + - title: "LDK #3792 introduces initial support for v3 commitment transactions" + url: /en/newsletters/2025/06/13/#ldk-3792 + ## Optional. Same format as "primary_sources" above see_also: - title: Channel commitment upgrades From 4680ab69b1d06d58edcf43bd33cbcc1697ce389a Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 13 Jun 2025 19:32:26 +0900 Subject: [PATCH 093/278] Newsletter-358:Translate into Japanese --- .../ja/newsletters/2025-06-13-newsletter.md | 222 ++++++++++++++++++ 1 file changed, 222 insertions(+) create mode 100644 _posts/ja/newsletters/2025-06-13-newsletter.md diff --git a/_posts/ja/newsletters/2025-06-13-newsletter.md b/_posts/ja/newsletters/2025-06-13-newsletter.md new file mode 100644 index 0000000000..944d7eee01 --- /dev/null +++ b/_posts/ja/newsletters/2025-06-13-newsletter.md @@ -0,0 +1,222 @@ +--- +title: 'Bitcoin Optech Newsletter #358' +permalink: /ja/newsletters/2025/06/13/ +name: 2025-06-13-newsletter-ja +slug: 2025-06-13-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、セルフィッシュマイニングの危険閾値の計算方法や、 +高手数料率のトランザクションのフィルタリングの防止に関するアイディアのまとめ、 +BIP390`musig()`ディスクリプターの変更案に関するフィードバックの募集、 +ディスクリプター暗号化用の新しいライブラリの発表を掲載しています。また、 +Bitcoin Core PR Review Clubの概要や、新しいリリースとリリース候補の発表、 +そして人気のBitcoinインフラストラクチャプロジェクトの最近の更新など、恒例のセクションも含まれています。 + +## ニュース + +- **セルフィッシュマイニングの危険閾値の計算:** + Antoine Poinsotは、[セルフィッシュマイニング攻撃][topic selfish mining]の名称の由来となった + 2013年の[論文][es selfish]の数式（ただし、この攻撃自体は2010年に[既に説明されていました][bytecoin selfish]）を + 拡張した記事をDelving Bitcoinに[投稿しました][poinsot selfish]。 + 彼はまた、この攻撃を実験するための簡略化された + マイニングおよびブロックリレー[シミュレーター][darosior/miningsimulation]も提供しています。 + 彼は、2013年の論文の結論の1つを再現することに焦点を当てています。 + それは、ネットワーク全体のハッシュレートの33%を制御する不正なマイナー（または強力な繋がりがあるマイナーのカルテル）は、 + その他の追加の優位性がなくても、ハッシュレートの67%を制御するマイナーよりも、 + 長期的にわずかながら利益を上げることができるというものです。 + これは33%のマイナーが、発見した新しいブロックの一部のアナウンスを選択的に遅らせることで実現されます。 + 不正なマイナーのハッシュレートが33%を超えると、その収益性はさらに高まり、 + 最終的には50%のハッシュレートを超えて、競合他社がベストブロックチェーン上に新しいブロックを保持できないようにすることができます。 + + Poinsotの投稿を詳しくレビューしたわけではありませんが、彼のアプローチは妥当であるように思われ、 + 数学的な検証や理解を深めたいと考えている方には、ぜひお勧めします。 + +- **上位のmempoolのセット調整によるリレーの検閲耐性:** + Peter Toddは、高手数料率のトランザクションをフィルタリングしているピアを + ノードが切断できるようにするメカニズムについてBitcoin-Devメーリングリストに[投稿しました][todd feerec]。 + このメカニズムは、[クラスターmempool][topic cluster mempool]と、 + [erlay][topic erlay]で使用されているようなセット調整メカニズムに依存します。 + ノードは、クラスターmempoolを使って、（たとえば）8,000,000 weight単位（最大8MB）に収まる、 + 最も収益性の高い未承認トランザクションのセットを計算します。 + ノードの各ピアも、未承認トランザクションの上位8 MWUを計算します。 + [minisketch][topic minisketch]などの効率的なアルゴリズムを使って、 + ノードはピアとトランザクションのセットを調整します。これにより、 + 各ピアのmempoolの上位にどのようなトランザクションがあるかを正確に学習します。 + その後、ノードは平均して収益性の低いmempoolを持つピアとの接続を定期的に切断します。 + + 収益性の低い接続を切断することで、ノードは最終的に、 + 高手数料率のトランザクションをフィルタリングする可能性が最も低いピアを見つけることができるでしょう。 + Toddは、クラスターmempoolのサポートがBitcoin Coreにマージされた後で実装に取り組みたいと述べました。 + 彼はこのアイディアはGregory Maxwellらの功績だと述べており、 + Optechは基本的なアイディアについて[ニュースレター #9][news9 reconcile]で初めて言及しました。 + +- **`musig()`式で参加者の鍵の重複を許可するようBIP390を更新:** + Ava Chowは、[アウトプットスクリプトディスクリプター][topic descriptors]内の + `musig()`式で同じ参加者の公開鍵を複数使用できるように[BIP390][]を更新することに反対する人がいるかどうかを + Bitcoin-Devメーリングリストで[尋ねました][chow dupsig]。 + これは、実装を簡素化し、[MuSig2][topic musig]の仕様である[BIP327][]では明示的に許可されています。 + この記事の執筆時点では反対意見はなく、ChowはBIP390の仕様を変更する[プルリクエスト][bips #1867]を公開しました。 + +- **ディスクリプター暗号化ライブラリ:** + Josh Domanは、[アウトプットスクリプトディスクリプター][topic descriptors]または + [miniscript][topic miniscript]の機密部分を、そこに含まれる公開鍵で暗号化するライブラリを作成したことを + Delving Bitcoinで[発表しました][doman descrypt]。 + 彼は、復号に必要な情報について説明しています: + + > - 使用する際にウォレットが2-of-3の鍵を求める場合、復号にも正確に2-of-3の鍵が必要になります。 + > + > - ウォレットが「2つの鍵 OR タイムロックと別の鍵」のような複雑なminiscriptポリシーを使用している場合は、 + > すべてのタイムロックやハッシュロックが満たされているかのように、暗号化も同じ構造に従います。 + + これは、[ニュースレター #351][news351 salvacrypt]で説明した暗号化ディスクリプターバックアップ方式とは異なります。 + その方式では、ディスクリプター内に含まれる任意の公開鍵の知識があれば、ディスクリプターを復号できます。 + Domanは、この方式は、暗号化ディスクリプターがブロックチェーンなどの公開または半公開のソースにバックアップされている場合に、 + より優れたプライバシーを提供すると主張しています。 + +## Bitcoin Core PR Review Club + +*この毎月のセクションでは、最近の[Bitcoin Core PR Review Club][]ミーティングを要約し、 +重要な質問と回答のいくつかに焦点を当てます。 +以下の質問をクリックしてミーティングでの回答の要約を確認してください。* + +[Separate UTXO set access from validation functions][review club 32317]は、 +[TheCharlatan][gh thecharlatan]によるPRで、UTXOセット全体を要求するのではなく、 +必要なUTXOのみを渡すことで検証関数を呼び出せるようにします。 +これは、[`bitcoinkernel`プロジェクト][Bitcoin Core #27587]の一部で、 +[Utreexo][topic utreexo]ノードや +[SwiftSync][somsen swiftsync]ノード（[ニュースレター #349][news349 swiftsync]参照）など、 +UTXOセットを実装していないフルノード実装において、ライブラリをより使いやすくするための重要なステップです。 + +最初の4つのコミットでは、このPRにより、検証関数がUTXOセットに直接アクセスするのではなく、 +呼び出し側が必要な`Coin`または`CTxOut`をまず取得し、それらを検証関数に渡すことで、 +トランザクション検証関数とUTXOセット間の結合を低減します。 + +それ以降のコミットでは、UTXOセットとのやりとりを必要とする残りのロジックを +別の`SpendBlock()`メソッドに分離することで、`ConnectBlock()`のUTXOセットへの依存を完全に解消します。 + +{% include functions/details-list.md +q0="このPRで、`ConnectBlock()`関数から新しい`SpendBlock()`関数を切り離すことがなぜ役立つのですか？ +2つの関数の目的をどのように比較しますか？" +a0="`ConnectBlock()`関数は、もともとブロックの検証とUTXOセットの変更の両方を実行していました。 +このリファクタリングにより、これらの役割が分割されます。`ConnectBlock()`関数は、 +UTXOセットを必要としない検証ロジックのみを担当し、新しい`SpendBlock()`関数は +UTXOセットとのすべてのやりとりを処理します。これにより、呼び出し元は、 +`ConnectBlock()`を使ってUTXOセットなしでブロックの検証を行えます。" +a0link="https://bitcoincore.reviews/32317#l-37" + +q1="UTXOセットなしでカーネルを使用できるようになること以外に、この分離に別の利点はありますか？" +a1="UTXOセットの無いプロジェクトでカーネルを使用できるようになることに加えて、 +この分離により、コードを個別にテストしやすくなり、保守も容易になります。 +あるレビュアーは、UTXOセットへのアクセスが不要になることで、 +SwiftSyncの重要な機能であるブロックの並列検証が可能になると指摘しています。" +a1link="https://bitcoincore.reviews/32317#l-64" + +q2="`SpendBlock()`は、`CBlock block`および`CBlockIndex pindex`、 +`uint256 block_hash`パラメーターを受け取ります。これらはすべて使用されるブロックを参照します。 +なぜ3つのパラメーターが必要なのでしょうか？" +a2="検証コードはパフォーマンスが重要であり、ブロックの伝播速度などの重要なパラメーターに影響します。 +`CBlock`や`CBlockIndex`からブロックハッシュを計算すると、値がキャッシュされないためコストがかかります。 +そのため、作者はパフォーマンスを優先し、計算済みの`block_hash`を別のパラメーターとして渡すことにしました。 +同様に、`pindex`をブロックインデックスから取得することもできますが、 +これは厳密には必要のない追加のマップ検索を必要とします。 +
_注: 作者は後にアプローチを[変更し][32317 updated approach]、 +`block_hash`のパフォーマンス最適化を削除しました。_" +a2link="https://bitcoincore.reviews/32317#l-97" + +q3="このPRの最初のコミットでは、`CCoinsViewCache`をいくつかの検証関数の関数シグネチャからリファクタリングしています。 +`CCoinsViewCache`はUTXOセット全体を保持しているのでしょうか？なぜそれが問題になるのか（あるいは問題にならないのか）？ +このPRは、その動作を変更しますか？" +a3="`CCoinsViewCache`はUTXOセット全体を保持するわけではありません。 +これは、UTXOセット全体をディスクに保存する`CCoinsViewDB`の前に位置するメモリ内のキャッシュです。 +要求されたコインがキャッシュにない場合は、ディスクから取得する必要があります。 +このPRは、キャッシュの動作自体を変更するものではありません。関数シグネチャから +`CCoinsViewCache`を削除することで、UTXOセットへの依存関係を明示し、 +呼び出し元は検証関数を呼び出す前にコインを取得する必要があります。" +a3link="https://bitcoincore.reviews/32317#l-116" +%} + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [Core Lightning 25.05rc1][]は、この人気のLNノード実装の次期メジャーバージョンのリリース候補です。 + +- [LND 0.19.1-beta][]は、この人気のLNノード実装のメンテナンスバージョンのリリースです。 + 複数のバグ修正が[含まれています][lnd rn]。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Bitcoin Core #32406][]は、デフォルトの`-datacarriersize`の設定を83から + 100,000 byte（トランザクションの最大サイズ制限）に引き上げることで、 + `OP_RETURN`アウトプットのサイズ制限（標準ルール）の上限を解除します。 + `-datacarrier`および`-datacarriersize`オプションは引き続き使用できますが、 + 非推奨としてマークされており、将来のリリース（未定）で削除される可能性があります。 + さらに、このPRにより、OP_RETURNアウトプットはトランザクションに付き1つというポリシー制限も解除され、 + サイズ制限はトランザクション内のすべてのアウトプットに割り当てられるようになりました。 + この変更に関する詳細は、[ニュースレター #352][news352 opreturn]をご覧ください。 + +- [LDK #3793][]は、ピアに次の`n`個(`batch_size`)のメッセージを単一の論理単位として扱うように指示する + 新しい`start_batch`メッセージを追加します。また、`PeerManager`を更新し、 + [スプライシング][topic splicing]中の`commitment_signed`メッセージについて、 + バッチ内の各メッセージにTLVと`batch_size`フィールドを追加するのではなく、このメッセージに依存するようにしています。 + これは、LN仕様で定義されている唯一のバッチ処理である`commitment_signed`メッセージだけでなく、 + 追加のLNプロトコルメッセージのバッチ処理を可能にする試みです。 + +- [LDK #3792][]は、[TRUCトランザクション][topic v3 transaction relay]と + [エフェメラルアンカー][topic ephemeral anchors]に依存する + [v3コミットメント トランザクション][topic v3 commitments]（[ニュースレター #325][news325 v3]参照）の初期サポートを、 + テストフラグの下、導入します。ノードは、ゼロ以外の手数料率を設定する`open_channel`提案を拒否し、 + そのようなチャネルを自分から開始しないことを保証し、 + 後の手数料引き上げのためにまずUTXOを確保するためにv3チャネルを自動的に受け入れるのを停止します。 + このPRではまた、TRUCトランザクションは10 kvB未満でなければならないため、 + チャネルあたりの[HTLC][topic htlc]数の制限が483から114に引き下げられました。 + +- [LND #9127][]では、`lncli addinvoice`コマンドに`--blinded_path_incoming_channel_list`オプションが追加されました。 + これにより、受取人は、支払人が[ブラインドパス][topic rv routing]で転送を試みるための + 1つ以上（複数のホップの場合）の優先チャネルIDを埋め込むことができます。 + +- [LND #9858][]は、[RBF][topic rbf]による協調クローズフロー（[ニュースレター #347][news347 rbf]参照）の + プロダクション機能ビット61のシグナリングを開始し、Eclairとの相互運用性を適切に実現します。 + この機能をテストするノードとの相互運用性を維持するため、ステージングビット161は保持されます。 + +- [BOLTs #1243][]は、[BOLT11][]仕様を更新し、p（ペイメントハッシュ）、 + h（説明のハッシュ）、s（シークレット）などの必須フィールドの長さが正しくない場合、 + 読み取り人（支払人）はインボイスの支払いを行ってはならないことを示しました。 + これまでは、ノードはこの問題を無視できました。このPRではまた、 + [Low R署名][topic low-r grinding]は1 byteのスペースを節約できるが、 + 仕様では強制されないことを説明する注記をサンプルセクションに追加しています。 + +{% include snippets/recap-ad.md when="2025-06-17 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32406,3793,3792,9127,1867,9858,1243,27587" %} +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[lnd 0.19.1-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.1-beta +[poinsot selfish]: https://delvingbitcoin.org/t/where-does-the-33-33-threshold-for-selfish-mining-come-from/1757 +[bytecoin selfish]: https://bitcointalk.org/index.php?topic=2227.msg30083#msg30083 +[lnd rn]: https://github.com/lightningnetwork/lnd/blob/v0.19.1-beta/docs/release-notes/release-notes-0.19.1.md +[darosior/miningsimulation]: https://github.com/darosior/miningsimulation +[todd feerec]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aDWfDI03I-Rakopb@petertodd.org/ +[news9 reconcile]: /en/newsletters/2018/08/21/#bandwidth-efficient-set-reconciliation-protocol-for-transactions +[chow dupsig]: https://mailing-list.bitcoindevs.xyz/bitcoindev/08dbeffd-64ec-4ade-b297-6d2cbeb5401c@achow101.com/ +[doman descrypt]: https://delvingbitcoin.org/t/rust-descriptor-encrypt-encrypt-any-descriptor-such-that-only-authorized-spenders-can-decrypt/1750/ +[news351 salvacrypt]: /ja/newsletters/2025/04/25/#standardized-backup-for-wallet-descriptors +[es selfish]: https://arxiv.org/pdf/1311.0243 +[news352 opreturn]: /ja/newsletters/2025/05/02/#bitcoin-core-op-return +[news325 v3]: /ja/newsletters/2024/10/18/#version-3-commitment-transactions-3 +[news347 rbf]: /ja/newsletters/2025/03/28/#lnd-8453 +[review club 32317]: https://bitcoincore.reviews/32317 +[gh thecharlatan]: https://github.com/TheCharlatan +[somsen swiftsync]: https://gist.github.com/RubenSomsen/a61a37d14182ccd78760e477c78133cd +[32317 updated approach]: https://github.com/bitcoin/bitcoin/pull/32317#issuecomment-2883841466 +[news349 swiftsync]: /ja/newsletters/2025/04/11/#swiftsync From 585dbfdfc95a2c8d931e8cd0020ad146524b4545 Mon Sep 17 00:00:00 2001 From: BitTom Date: Fri, 13 Jun 2025 07:44:10 +0800 Subject: [PATCH 094/278] Newsletter-191: translate into Chinese --- .../zh/newsletters/2022-03-16-newsletter.md | 63 +++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 _posts/zh/newsletters/2022-03-16-newsletter.md diff --git a/_posts/zh/newsletters/2022-03-16-newsletter.md b/_posts/zh/newsletters/2022-03-16-newsletter.md new file mode 100644 index 0000000000..a9ed1e4d02 --- /dev/null +++ b/_posts/zh/newsletters/2022-03-16-newsletter.md @@ -0,0 +1,63 @@ +--- +title: 'Bitcoin Optech Newsletter #191' +permalink: /zh/newsletters/2022/03/16/ +name: 2022-03-16-newsletter-zh +slug: 2022-03-16-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周 Newsletter 描述了扩展或替换 Bitcoin Script 的新 opcode 的提案，总结了最近关于改进 RBF 政策的讨论，并链接了对 `OP_CHECKTEMPLATEVERIFY` opcode 持续进行的工作。此外，还包括我们的常规版块，介绍热门比特币基础设施项目的值得注意的变更。 + +## 新闻 + +- ******对 Bitcoin Script 的扩展与替代：** + 几位开发者在 Bitcoin-Dev 邮件列表上讨论了改进 Bitcoin 的 Script 和 [tapscript][topic tapscript] 语言的想法；收款方通过这些脚本语言来指定其日后如何证明自己已授权花费相应的比特币。 + + - *****循环（折叠）：* 开发者 ZmnSCPxj [描述][zmnscpxj fold]了一条名为 `OP_FOLD` 的 opcode 提案，用以在 Bitcoin Script 中实现类似循环的行为。他提出了一系列约束，确保循环不会消耗超出 Bitcoin Script 与 tapscript 目前允许的 CPU 或内存——同时通过消除脚本中的重复代码来减少带宽占用。 + + - *****使用 Chia Lisp：* Anthony Towns [发布][towns btc-lisp]了一项提议，计划为 Bitcoin 引入一种基于 [Chia Lisp][]（Chia 山寨币所使用的 Lisp 方言）的变体。这将成为传统 Bitcoin Script 与 tapscript 的一种全然不同的替代方案，并可带来与先前提出的 [Simplicity][topic simplicity] 类似的“重新起步”优势。Towns 提出的替代方案——“Binary Tree Coded Script” 或 “btc-script”——据称比 Simplicity 更易于理解和使用，但可能更难以进行形式化验证。 + +- ******改进 RBF 政策的想法：** + Gloria Zhao [发布][zhao rbf]了在伦敦举行的 [CoreDev.Tech][] 会议以及相关讨论中，关于 Replace-by-Fee（RBF）政策的总结。主要观点是尝试限制用于转发交易及其替代交易的最大资源消耗，例如在特定时间窗口内限制可转发的相关交易数量。 + + Zhao 还在另一份 [gist][daftuar limits] 中概述了允许交易自行建议其子孙交易限制的讨论。例如，一笔交易可以建议将其及其子孙在内存池中可占用的最大空间限制为 1,000 vbytes，而非默认的 100,000 vbytes。这样可降低诚实方在应对最坏情况下的[交易固定][topic transaction pinning]攻击时需要花费的成本。 + + 此外，Zhao 正寻求对一套算法的反馈，该算法用于在当前内存池状态下计算一笔交易对矿工的价值，从而使节点软件在是否接受替代交易的决策上更加灵活。 + +- ******持续的 CTV 讨论：** + 如 [Newsletter #183][news183 ctv meeting] 所述，围绕提议的 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]（CTV）opcode 的会议仍在继续，Jeremy Rubin 提供了会议摘要：[1][news183 ctv meeting]、[2][ctv2]、[3][ctv3]、[4][ctv4]、[5][ctv5]。此外，上周 James O'Beirne [发布][obeirne vault]了基于 CTV 的[保险库][topic vaults]的代码和设计文档。 + +## 值得注意的代码和文档更改 + +*本周在 [Bitcoin Core][bitcoin core repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中的值得注意的变更。* + +- [Bitcoin Core #24198][] 扩展了 `listsinceblock`、`listtransactions` 与 `gettransaction` 这三个 RPC，新增 `wtxid` 字段，用于包含每笔交易的见证交易标识符（Witness Transaction Identifier），该标识符在 [BIP141][] 中进行了定义。 + +- [Bitcoin Core #24043][Bitcoin Core #24043] 新增 `multi_a` 与 `sortedmulti_a` [描述符][topic descriptors]，可使用 [tapscript][topic tapscript] 的 `OP_CHECKSIGADD` opcode 来创建支出授权策略，而非旧版 Script 中的 `OP_CHECKMULTISIG` 与 `OP_CHECKMULTISIGVERIFY`。更多背景可参阅 [Newsletter #46][news46 csa] 中关于 tapscript 这一特性的介绍。 + +- [Bitcoin Core #24304][Bitcoin Core #24304] 添加了新的演示可执行文件 `bitcoin-chainstate`。该程序接受一个 Bitcoin Core 数据目录与一个区块作为输入，对区块进行验证并将其写入数据目录。虽然该工具本身用处有限，但它为 [libbitcoinkernel][bitcoin core #24303] 项目奠定了基础，后续可为其他项目提供与 Bitcoin Core 完全一致的区块和交易验证功能库。 + +- [C-Lightning #5068][C-Lightning #5068] 将 C-Lightning 每天为单个节点中继的 [BOLT7][] `node_announcement` 消息最小数量从 1 条提升至 2 条，以减轻节点更换 IP 地址或因维护而短暂离线所带来的一些问题。 + +- [BIPs #1269][BIPs #1269] 将 [BIP326][] 指派给一项建议：即便协议不需要，依然为 [taproot][topic taproot] 交易设置 nSequence，以便在需要共识强制的 [BIP68][] nSequence 值时提高隐私性。BIP326 还描述了如何利用 nSequence 为当前通过交易 locktime 字段实现的[反手续费抢先攻击][topic fee sniping]保护提供一种替代方案。关于最初的邮件列表提案，可参阅 [Newsletter #153][news153 nseq]。 + + + +{% include references.md %} +{% include linkers/issues.md v=1 issues="24198,24043,24304,24303,5068,1269" %} +[news46 csa]: /zh/newsletters/2019/05/14/#new-script-based-multisig-semantics +[zmnscpxj fold]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/020021.html +[towns btc-lisp]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020036.html +[lisp]: https://en.wikipedia.org/wiki/Lisp_(programming_language) +[chia lisp]: https://chialisp.com/ +[zhao rbf]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020095.html +[daftuar limits]: https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4058140#gistcomment-4058140 +[news183 ctv meeting]: /zh/newsletters/2022/01/19/#irc-meeting +[ctv2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019855.html +[ctv3]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019874.html +[ctv4]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019974.html +[ctv5]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020086.html +[obeirne vault]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020067.html +[coredev.tech]: https://coredev.tech/ +[news153 nseq]: /zh/newsletters/2021/06/16/#bip-proposed-for-wallets-to-set-nsequence-by-default-on-taproot-transactions From b5bea5cdf5beaf3c2de3edbfa0a4167bdbcf3e7b Mon Sep 17 00:00:00 2001 From: BitTom Date: Fri, 13 Jun 2025 20:35:53 +0800 Subject: [PATCH 095/278] Newsletter-192: translate into Chinese (#2368) --- .../zh/newsletters/2022-03-23-newsletter.md | 75 +++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 _posts/zh/newsletters/2022-03-23-newsletter.md diff --git a/_posts/zh/newsletters/2022-03-23-newsletter.md b/_posts/zh/newsletters/2022-03-23-newsletter.md new file mode 100644 index 0000000000..4998b3978a --- /dev/null +++ b/_posts/zh/newsletters/2022-03-23-newsletter.md @@ -0,0 +1,75 @@ +--- +title: 'Bitcoin Optech Newsletter #192' +permalink: /zh/newsletters/2022/03/23/ +name: 2022-03-23-newsletter-zh +slug: 2022-03-23-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的 Newsletter 概述了关于 speedy trial 软分叉激活机制的讨论，并链接到针对 LN 路径寻找算法的优化更新。此外，我们照例提供了对服务和客户端软件最近更改的描述、新版发布与候选发布的公告，以及对流行比特币基础设施软件值得注意的更改摘要。 + +## 新闻 + +- ******speedy trial 讨论：** 在最近一次关于提议中的 OP_CHECKTEMPLATEVERIFY opcode 的会议纪要中提到 speedy trial 软分叉激活方法，该内容随后被拆分出来，在 Bitcoin-Dev 邮件列表上单独开设了讨论线程，因为 Jorge Timón 表达了对在他认为具有争议的软分叉上使用 speedy trial 的担忧。Russell O'Connor 解释了这些担忧此前已如何得到解决。Anthony Towns 进一步描述了反对者如何抵制利用 speedy trial 激活一个他们并不希望发生的软分叉。 + +- ******支付路径算法更新：** René Pickhardt 在 Lightning-Dev 邮件列表中发帖表示，他为去年与 Stefan Richter 发布的路径寻找算法找到了计算效率更高的近似实现。关于该算法的早期讨论可见 Newsletter #163。Pickhardt 的邮件还提出了一些可以提高快速支付成功率的方法，例如实现 [stuckless 支付][news53 stuckless]，以及按照[多篇][boomerang]学术[论文][spear]中的提议，允许[可退款的超额支付][news86 boomerang]。 + +## 服务和客户端软件的更改 + +*在这一月度栏目中，我们重点介绍比特币钱包与服务的有趣更新。* + +- ******Coinswap 实现 Teleport Transactions 发布：** 在最近的 Bitcoin-Dev 邮件列表[帖子][belcher teleport]中，Chris Belcher 公布了实现 [coinswap][topic coinswap] 协议的 Teleport Transactions alpha 版 [0.1][teleport transactions 0.1]。 + +- ******JoinMarket 新增 taproot 转账：** [JoinMarket v0.9.5][joinmarket v0.9.5] 增加了向 [bech32m][topic bech32] 地址发送资金的能力。 + +- ******Mercury Wallet 增加 RBF（Replace-by-Fee） 支持：** 面向 Mercury [statechain][topic statechains] 的钱包发布了 [v0.6.5][mercury v0.6.5]，其中为提现交易引入了 RBF（Replace-by-Fee） 替换功能。 + +- ******Hexa Wallet 新增闪电网络支持：** 移动端钱包 Hexa 在 [v2.0.71 版本][hexa v2.0.71] 中为运行自有 LND 节点的用户加入了闪电网络功能。 + +- ******Sparrow 新增 BIP47 支持：** [Sparrow 1.6.0][sparrow 1.6.0]（以及后续的 1.6.1 与 1.6.2 版本）为 [BIP47][] 可重复使用的付款码及相关功能提供了支持，并[介绍了这些功能][sparrow wallet tweet]。 + +## 发布与候选发布 + +*面向流行比特币基础设施项目的新版本发布与候选发布。请考虑升级到新版本或协助测试候选版本。* + +- [HWI 2.1.0-rc.1][HWI 2.1.0-rc.1] 是 HWI 的一个候选发布，新增了对多款硬件签名设备的 taproot 支持，并包含其他改进和漏洞修复。 + +## 值得注意的代码与文档变更 + +*本周在 [Bitcoin Core][bitcoin core repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中的值得注意的变更。* + +- [Eclair #2203][Eclair #2203] 添加了额外的配置参数，使用户可以为[未公开通道][topic unannounced channels]指定与公开通道默认值不同的最小资金金额。 + +- [LDK #1311][LDK #1311] 实现了 [BOLTs #910][] 中提议的短通道标识符（SCID） `alias` 字段，允许节点请求其对等方使用任意值而非锚定通道的链上交易所派生的值来标识通道。这有助于通过防止 SCID 向第三方泄露节点创建了哪些交易来提升隐私，并且在 Newsletter #156 中描述的可选零确认通道（有时称为 *turbo channels*）规范里也被提议使用。 + +- [LDK #1286][LDK #1286] 按 [BOLT7 的推荐][bolt7 route rec]，为用于路由付款的 CLTV（`OP_CHECKLOCKTIMEVERIFY`）值增加了偏移量。这使得观察到部分支付过程的实体（例如中继该支付的节点）更难准确猜测哪个节点可能是最终收款人。 + +- [HWI #584][HWI #584] 在使用 BitBox02 硬件签名设备的最新固件版本时，加入了向 [bech32m][topic bech32] 地址付款的支持。 + +- [HWI #581][HWI #581] 在使用未来固件版本的 Trezor 时，禁用了包含外部输入（例如在 [coinjoin][topic coinjoin] 中）的交易签名支持。该拉取请求紧随一次固件更新之后，该更新破坏了 HWI 先前用于实现此支持的变通方案。后续拉取请求（[HWI #590][HWI #590]）显示 Trezor 正在研究为用户提供签署此类交易的途径。 + +- [BDK #515][BDK #515] 开始在内部数据库中保留已花费的交易输出，这对于创建[替换交易][topic rbf]很有用，并简化了对 [BIP47][] 可重复使用付款码的[持续实现][bdk #549]。 + + +{% include references.md %} +{% include linkers/issues.md v=1 issues="2203,1311,910,1286,584,581,515,549,590" %} +[hwi 2.1.0-rc.1]: https://github.com/bitcoin-core/HWI/releases/tag/2.1.0-rc.1 +[bolt7 route rec]: https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#recommendations-for-routing +[oconnor st]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020106.html +[timon st]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020102.html +[towns st]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020127.html +[pickhardt payment delivery]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-March/003510.html +[news163 pp]: /zh/newsletters/2021/08/25/#zero-base-fee-ln-discussion +[news53 stuckless]: /zh/newsletters/2019/07/03/#stuckless-payments +[spear]: https://dl.acm.org/doi/10.1145/3479722.3480997 +[news156 zcc]: /zh/newsletters/2021/07/07/#zero-conf-channel-opens +[boomerang]: https://arxiv.org/pdf/1910.01834.pdf +[news86 boomerang]: /zh/newsletters/2020/02/26/#boomerang-redundancy-improves-latency-and-throughput-in-payment-channel-networks +[belcher teleport]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/020026.html +[teleport transactions 0.1]: https://github.com/bitcoin-teleport/teleport-transactions/releases/tag/0.1 +[joinmarket v0.9.5]: https://github.com/JoinMarket-Org/joinmarket-clientserver/releases/tag/v0.9.5 +[mercury v0.6.5]: https://github.com/layer2tech/mercury-wallet/releases/tag/v0.6.5 +[hexa v2.0.71]: https://github.com/bithyve/hexa/releases/tag/v2.0.71 +[sparrow 1.6.0]: https://github.com/sparrowwallet/sparrow/releases/tag/1.6.0 +[sparrow wallet tweet]: https://twitter.com/SparrowWallet/status/1504458210366922759 From bb1f13a74adc55dda626b0a277250961001c367a Mon Sep 17 00:00:00 2001 From: Tulio Albuquerque Date: Fri, 13 Jun 2025 19:34:50 -0300 Subject: [PATCH 096/278] feat: adds initial Portuguese style guide (#2363) * feat: adds initial portuguese style guide * fix: remove 'deutsch' word from style-pt Co-authored-by: Mark "Murch" Erhardt * feat: update the guide style to match the style-de and fixe some translations * fix: remove german words * fix: removes 'mit nummer'german expression and unused topic header * Drop trailing space --------- Co-authored-by: Mark "Murch" Erhardt --- STYLE-PT.md | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 STYLE-PT.md diff --git a/STYLE-PT.md b/STYLE-PT.md new file mode 100644 index 0000000000..cb954f219f --- /dev/null +++ b/STYLE-PT.md @@ -0,0 +1,87 @@ +# Optech Style Guide para Traduções em português + +## Básico + +A tradução para português de conteúdos do Optech devem seguir as regres o [Guia principal](STYLE.md) sempre que possivel. + +## Títulos de seção (traduções padrão) + +| Inglês | Português | +|------------------------------------------|--------------------------------------------------------------| +| News | Notícias | +| Changes to services and client software | Alterações nos serviços e software do cliente | +| Notable code and documentation changes | Alterações importantes de código e documentação | +| Selected Q&A from Bitcoin Stack Exchange | Perguntas e respostas selecionadas do Bitcoin Stack Exchange | +| Correction | Correção | +| Consensus changes | Mudanças de consenso | + +## Vocabulário + +### nomes próprios + +Os nomes próprios devem ser capitalizados como no guia principal. + +## Termos preferidos para tradução para a lingua portuguesa + +| Inglês | Preferido (PT) | Evitar | Observações | +|-------------------------|--------------------------|----------------------|------------------------------------------| +| channel | canal | | | +| fee | taxa | | | +| funds | fundos | | | +| input/output | entrada/saida | | | +| lightning network | Rede Lightning | | | +| node | Nó | Node | Full-node não é traduzido | +| proof of work | prova de trabalho | | | +| wallet | carteira | | | + +## Termos e exceções não traduzidos + +| Inglês | Contexto / observações | +|------------------------------- |-----------------------------------------------------------| +| BDK | Nome do produto | +| BIP(número) | Protocolo/Termo técnico | +| BLIP | Protocolo/Termo técnico | +| BTCPay Server | Nome do produto | +| Channel | Termo técnico estabelecido | +| Core Lightning | Nome do produto | +| Delving Bitcoin | Plataforma / Nome de newsletter | +| DLC | Camada 2 / Contrato Inteligente / Conceito de Transação | +| DLC-Dev | Plataforma / Nome de newsletter | +| Derivation path | Termo técnico | +| Descriptor | Termo técnico | +| dual funding | Termo técnico | +| Eclair | Nome do produto | +| FPPS | Termo técnico / Sistema de pagamento | +| Full Node / Full Nodes | Sempre deixado no original | +| HTLC | Sempre deixado no original | +| Human Readable Names | Termo técnico | +| LDK | Nome do produto | +| LN | Camada 2 / Contrato Inteligente / Conceito de Transação | +| LSP | Nome do produto | +| Mining | Termo técnico estabelecido | +| On-Chain | Camada 2 / Contrato Inteligente / Conceito de Transação | +| OP_CHECKTEMPLATEVERIFY (CTV) | Termo tecnico de protocolo | +| Oracle | Lightning/Tecnologia DLC | +| Pay-per-Last-N-Shares | Termos técnicos / Sistemas de pagamento | +| Pool | Termo técnico estabelecido | +| Pool-Miner | Termo técnico estabelecido | +| PR | Terminologia do Git/GitHub | +| Proxy | Termo técnico estabelecido | +| PSBT | Termo tecnico de protocolo | +| PPLNS | Termo técnico / Sistema de pagamento | +| Release | Termo de software | +| Releases | Termo de software | +| Rust Bitcoin | Nome do produto | +| SCID | Protocolo/Termo técnico | +| Simple Taproot Channels | Lightning/Tecnologia DLC | +| Splice | Protocolo/Termo técnico | +| TIDES | Nome do sistema | +| UTXO | Termo técnico estabelecido | +| merged | Terminologia do Git/GitHub | +| Offchain | Layer-2/Smart-Contract/Conceito de Transação | + +--- + +### Unidades de medida + +Ver [Guia principal](STYLE.md). \ No newline at end of file From e740cf7b0eaf0a752c3bd483a586161b78de3907 Mon Sep 17 00:00:00 2001 From: Walpurga03 Date: Sat, 14 Jun 2025 11:20:10 +0200 Subject: [PATCH 097/278] Update internal links and anchors to point to German translations in #356 & #339 --- _posts/de/newsletters/2025-01-31-newsletter.md | 4 ++-- _posts/de/newsletters/2025-05-30-newsletter.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/_posts/de/newsletters/2025-01-31-newsletter.md b/_posts/de/newsletters/2025-01-31-newsletter.md index ffdca48929..344d2ea570 100644 --- a/_posts/de/newsletters/2025-01-31-newsletter.md +++ b/_posts/de/newsletters/2025-01-31-newsletter.md @@ -256,14 +256,14 @@ _Wichtige aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], [Core Light [miningpool.observer]: https://miningpool.observer/template-and-block [b10c cb]: https://delvingbitcoin.org/t/stats-on-compact-block-reconstructions/1052/5 [news315 cb]: /en/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction -[news338 orphan]: /en/newsletters/2025/01/24/#bitcoin-core-31397 +[news338 orphan]: /de/newsletters/2025/01/24/#bitcoin-core-31397 [news274 cycle]: /en/newsletters/2023/10/25/#replacement-cycling-vulnerability-against-htlcs [ldk v0.1.1]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.1.1 [morehouse ldk-dos]: https://delvingbitcoin.org/t/disclosure-ldk-duplicate-htlc-force-close-griefing/1410 [news281 griefing]: /en/newsletters/2023/12/13/#discussion-about-griefing-liquidity-ads [news238 peer]: /en/newsletters/2023/02/15/#core-lightning-5361 [news335 peer]: /en/newsletters/2025/01/03/#eclair-2888 -[news338 psbtv2]: /en/newsletters/2025/01/24/#psbtv2-integration-testing +[news338 psbtv2]: /de/newsletters/2025/01/24/#psbtv2-integrationstests [mempool genesis block]: https://mempool.space/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f [policy series]: /en/blog/waiting-for-confirmation/#policy-for-protection-of-node-resources [news316 xor]: /en/newsletters/2024/08/16/#bitcoin-core-28052 diff --git a/_posts/de/newsletters/2025-05-30-newsletter.md b/_posts/de/newsletters/2025-05-30-newsletter.md index fa20ed0a26..07dfb8cb41 100644 --- a/_posts/de/newsletters/2025-05-30-newsletter.md +++ b/_posts/de/newsletters/2025-05-30-newsletter.md @@ -90,7 +90,7 @@ _Bedeutende kürzliche Änderungen in [Bitcoin Core][bitcoin core repo], [Core L [kirkcohen af]: https://delvingbitcoin.org/t/latency-and-privacy-in-lightning/1723 [news224 failures]: /de/newsletters/2022/11/02/#zuordnung-von-ln-routing-fehlern [news349 failures]: /en/newsletters/2025/04/11/#ldk-2256 -[news353 bip48]: /en/newsletters/2025/05/09/#bips-1835 +[news353 bip48]: /de/newsletters/2025/05/09/#bips-1835 [news348 op_ccv]: /de/newsletters/2025/04/04/#op-checkcontractverify-semantik [news339 extrapool]: /de/newsletters/2025/01/31/#aktualisierte-statistiken-zur-kompaktblock-rekonstruktion [miningsimulation github]: https://github.com/darosior/miningsimulationq \ No newline at end of file From b6570d3faae0480b49ded903d4acc05ea1687da2 Mon Sep 17 00:00:00 2001 From: BitTom Date: Sat, 14 Jun 2025 18:46:12 +0800 Subject: [PATCH 098/278] Newsletter-193: translate into Chinese (#2369) --- .../zh/newsletters/2022-03-30-newsletter.md | 95 +++++++++++++++++++ 1 file changed, 95 insertions(+) create mode 100644 _posts/zh/newsletters/2022-03-30-newsletter.md diff --git a/_posts/zh/newsletters/2022-03-30-newsletter.md b/_posts/zh/newsletters/2022-03-30-newsletter.md new file mode 100644 index 0000000000..d21c70bd15 --- /dev/null +++ b/_posts/zh/newsletters/2022-03-30-newsletter.md @@ -0,0 +1,95 @@ +--- +title: 'Bitcoin Optech Newsletter #193' +permalink: /zh/newsletters/2022/03/30/ +name: 2022-03-30-newsletter-zh +slug: 2022-03-30-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的 Newsletter 介绍了一项提议：Bitcoin Core 允许在其内存池中替换交易见证，并总结了有关更新 LN gossip 协议的持续讨论。此外，我们的常规栏目还包括 Bitcoin Stack Exchange 精选问答、新版本和候选版本的公告，以及对热门比特币基础设施项目值得注意的变更描述。 + +## 新闻 + +- ******交易见证替换：** + Larry Ruane 在 [Bitcoin-Dev 邮件列表][ruane witrep]上征求意见，讨论是否允许用见证更小（因此 wtxid 不同）但 txid 相同的交易来替换原有交易。Ruane 想了解目前是否已有应用会创建见证大小可能变化的交易（例如从 [taproot][topic taproot] 脚本路径支出切换到密钥路径支出），而其他交易细节（例如输出地址或金额）保持不变。 + + 如果现有或拟议中的应用能够从见证替换中获益，Ruane 还希望了解见证需要缩小多少才应允许替换。要求缩小幅度越大，可被替换的交易就越少——从而在最坏情况下限制攻击者浪费节点带宽。但如果要求过高，也会阻止应用通过见证替换获得较小或中等程度的节省。 + +- ******关于更新 LN gossip 协议的持续讨论：** + 正如 [Newsletter #188][news188 gossip] 所报道，LN 协议开发者正在讨论如何修订用来播报可用支付通道信息的 LN gossip 协议。本周出现了两个活跃的讨论线程： + + - *****重大更新：* + 在对 Rusty Russell 上月提出的[重大更新方案][russell gossip2]的[回应][osuntokun gossip1.1]中，Olaoluwa Osuntokun 多次表达了对该方案中一项内容的担忧——它会在链上资金与特定 LN 通道之间引入可信否认。这一特性也会让非 LN 用户更容易宣称某些并不存在的通道存在，从而削弱付款方在网络中找到有效路径并向收款节点付款的能力。 + + - *****小幅更新：* + Osuntokun 提出了另一份[更小范围的更新提案][osuntokun gossip2]，主要目的是支持基于 taproot 的通道。该提案使用 [MuSig2][topic musig]，通过单个签名即可证明与四个公钥（两个节点标识公钥、两个通道支出公钥）相关的授权，并可能要求通道建立交易可使用 MuSig2 进行支出。 + + 他还建议在通道公告消息中增加一条 SPV 部分默克尔分支证明，用于证明通道建立交易已被纳入某个区块，从而使轻客户端无需下载包含该交易的整个区块就能验证其存在。 + +## Bitcoin Stack Exchange 精选问答 + +*[Bitcoin Stack Exchange][bitcoin.se] 是 Optech 贡献者寻找答案的首选之地之一——当我们有空时也会在那里帮助求助用户。在这一月度专栏中，我们精选自上次更新以来得票最高的一些问答。* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- ****[地址重用的优缺点是什么？]({{bse}}112955) + RedGrittyBrick 与 Pieter Wuille 列举了地址重用的弊端，包括隐私影响以及关于公钥暴露的可争议问题。Wuille 补充指出，虽然生成新地址没有额外的经济成本，但会增加钱包软件、备份和可用性方面的复杂度。 + +- ****[什么是仅区块中继连接，它有何用途？]({{bse}}112828) + 用户 vnprc 将仅区块中继连接描述为只转发区块信息而不转发交易或潜在对等节点网络地址的连接。这类连接通过增加确定比特币网络拓扑图难度来帮助抵御分区（亦称为 [eclipse][topic eclipse attacks]）攻击。vnprc 还介绍了锚定连接——一种节点重启后仍会保持的仅区块中继连接，可进一步抵抗 eclipse 攻击。 + +- ****[除了难度调整之外，时间戳还有其他用途吗？]({{bse}}112929) + Pieter Wuille 解释了区块头 `nTime` 时间戳字段的限制（必须大于 [Median Time Past (MTP)][news146 mtp]，且不得超过未来两小时），并指出区块时间戳用于[难度][wiki difficulty]计算和交易 [timelocks][topic timelocks]。 + +- ****[尝试花费带 timelock 的 UTXO 时是如何被拒绝的？]({{bse}}112989) + Pieter Wuille 区分了通过交易字段 `nLockTime` 进行的锁定时间与通过 Script 的 [`OP_CHECKLOCKTIMEVERIFY`][BIP65] 操作码强制的 timelock。 + +## 发布与候选发布 + +*热门比特币基础设施项目的新版本与候选版本。请考虑升级至新版本，或帮助测试候选版本。* + +- [BDK 0.17.0][BDK 0.17.0] + 这是用于构建比特币钱包的库的新版本。此次改进使钱包即便离线也更容易派生地址。 + +- [Bitcoin Core 23.0 RC2][Bitcoin Core 23.0 RC2] + 这是这一主流全节点软件下一主要版本的候选发布。[草案发行说明][bcc23 rn]列出了多项改进，鼓励高级用户与系统管理员在最终发布前进行[测试][test guide]。 + +- [LND 0.14.3-beta.rc1][LND 0.14.3-beta.rc1] + 这一候选版本为这款流行的 LN 节点软件带来了数个错误修复。 + +## 值得注意的代码与文档变更 + +*本周在 [Bitcoin Core][bitcoin core repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[硬件钱包接口 (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]项目中的值得注意变更。* + +- [C-Lightning #5078][C-Lightning #5078] + 该变更使节点能够更高效地使用与同一对等节点建立的多条通道，包括在路由消息指定的通道不可用或效果不佳时，改用同一对等节点的其他通道来转发付款。 + +- [C-Lightning #5103][C-Lightning #5103] + 新增 `setchannel` 命令，可设置特定通道的路由费率、最小付款金额和最大付款金额。此命令取代已弃用的 `setchannelfee`。 + +- [C-Lightning #5058][C-Lightning #5058] + 移除了对原始固定长度洋葱数据格式的支持，该格式也在 [BOLTs #962][BOLTs #962] 中被提议从 LN 规范中删除。可变长度格式在近三年前已被[加入规范][bolts #619]。BOLTs #962 PR 中提到的网络扫描结果显示，在超过 17,000 个公开节点中，只有 5 个节点仍未支持该格式。 + +- [LND #5476][LND #5476] + 更新了 `GetTransactions` 与 `SubscribeTransactions` RPC 结果，新增关于输出的详细信息，包括支付金额与脚本，以及该地址（脚本）是否属于内部钱包。 + +- [LND #6232][LND #6232] + 新增一项配置，可要求所有 [HTLCs][topic htlc] 都由注册在 HTLC 拦截器挂钩上的插件处理。这确保在 HTLC 拦截器有机会注册之前，不会接受或拒绝任何 HTLC。HTLC 拦截器允许调用外部程序来检查 HTLC（付款）并决定是否接受或拒绝。 + + +{% include references.md %} +{% include linkers/issues.md v=1 issues="5078,5103,5058,962,619,5476,6232" %} +[bitcoin core 23.0 rc2]: https://bitcoincore.org/bin/bitcoin-core-23.0/ +[bdk 0.17.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.17.0 +[lnd 0.14.3-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.14.3-beta.rc1 +[bcc23 rn]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/23.0-Release-Notes-draft +[ruane witrep]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020167.html +[osuntokun gossip2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-March/003526.html +[osuntokun gossip1.1]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-March/003527.html +[news188 gossip]: /zh/newsletters/2022/02/23/#updated-ln-gossip-proposal +[russell gossip2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003470.html +[test guide]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/23.0-Release-Candidate-Testing-Guide +[wiki difficulty]: https://en.bitcoin.it/wiki/Difficulty +[news146 mtp]: /zh/newsletters/2021/04/28/#what-are-the-different-contexts-where-mtp-is-used-in-bitcoin From 25b6fbd8ef255d32490235ba7b3babadc80bb92e Mon Sep 17 00:00:00 2001 From: BitTom Date: Sat, 14 Jun 2025 18:53:20 +0800 Subject: [PATCH 099/278] Newsletter-194: translate into Chinese (#2370) --- .../zh/newsletters/2022-04-06-newsletter.md | 97 +++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 _posts/zh/newsletters/2022-04-06-newsletter.md diff --git a/_posts/zh/newsletters/2022-04-06-newsletter.md b/_posts/zh/newsletters/2022-04-06-newsletter.md new file mode 100644 index 0000000000..f58f3c5259 --- /dev/null +++ b/_posts/zh/newsletters/2022-04-06-newsletter.md @@ -0,0 +1,97 @@ +--- +title: 'Bitcoin Optech Newsletter #194' +permalink: /zh/newsletters/2022/04/06/ +name: 2022-04-06-newsletter-zh +slug: 2022-04-06-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的 Newsletter 描述了解除关联的可重用地址的提案，总结了 WabiSabi 协议如何作为增强版 payjoin 的替代方案，审视了在 DLC 规范中添加通信标准的讨论，并关注了关于更新 LN 承诺格式的再度讨论。文末附有常规板块，概述了新软件发布与候选版本，并描述了流行的比特币基础设施软件的值得注意的更改。 + +## 新闻 + +- ******可解除关联的可重用地址：** + Ruben Somsen 向 Bitcoin-Dev 邮件列表提交了一份[提案][somsen silpay]，允许向一个公共标识符（“地址”）付款而无需在链上直接使用该标识符。例如，Alice 生成一个由公钥构成的标识符并张贴在她的网站上。Bob 能够使用自己的某个私钥将 Alice 的公钥转换成一个新的比特币地址，并以此地址向 Alice 付款。只有 Alice 和 Bob 掌握足够的信息来确认该地址是支付给 Alice 的——且只有 Alice 拥有花费该地址上资金所必需的私钥。如果 Carol 之后访问 Alice 的网站并复用 Alice 的公共标识符，她将派生出一个不同的地址来支付 Alice，而 Bob 以及任何其他第三方都无法直接判断该地址属于 Alice。 + + 之前的解除关联可重用地址方案（例如 [BIP47][BIP47] 可重用支付码以及尚未发表的 BIP63 隐匿地址）依赖于支付方与接收方在区块链之外进行通信，或依赖包含额外数据、成本高于常规支付的链上交易。相比之下，Somsen 的 *silent payments* 提案在链上并不需要比普通交易更多的开销。 + + Silent payments 的最大缺点是接收方需要在每个新出块时扫描每一笔交易，以检测是否收到付款。全节点本就会扫描区块中的交易，但该方案还要求节点维护大量交易的父交易信息——这并不是多数全节点目前的默认行为，且可能需要显著额外的 I/O 操作及 CPU 开销。从备份恢复钱包也可能变得繁重。虽然 Somsen 描述了一些可降低负担的折衷方案，但该方案似乎并不适用于想要接收付款的大多数轻量钱包。不过，几乎所有钱包都能仅用少量代码就添加发送 silent payment 的支持，而不会带来明显的资源需求增长。这意味着方案的成本主要由最需要其增强隐私性的用户来承担，尤其是那些无法或不愿通过其他手段避免[地址重用][topic output linking]的用户。 + + Somsen 目前寻求对该提案的反馈，包括其密码学安全性的分析，以及在不显著削弱隐私优势的前提下，降低接收方资源消耗的任何建议。 + +- ******WabiSabi 作为 payjoin 的替代方案：** + 数周前，Wasabi 钱包及其 [coinjoin][topic coinjoin] 实现的开发者在 Bitcoin-Dev 邮件列表上[宣布][wasabi2]了新版本，并支持在 [Newsletter #102][news102 wabisabi] 中描述的 WabiSabi 协议。先前使用的 Chaumian coinjoin 协议允许输入金额任意，但输出金额固定；改进后的 WabiSabi 协议则允许输入与输出金额均为任意值（仍需满足最大交易尺寸、遵守[粉尘限制][topic uneconomical outputs]等约束）。 + + 本周，Max Hillebrand [发布][hillebrand wormhole]了如何将 WabiSabi 协议用作 [payjoin][topic payjoin] 替代方案的说明。在标准 payjoin 中，付款方与收款方都会向同一笔交易贡献输入并各自接收输出。虽然双方都会得知对方的输入与输出，但链上的所有权信息被打乱，从而为参与 payjoin 的用户及其他多输入交易带来混淆。Hillebrand 提出的 wormhole 2.0 协议将利用 WabiSabi 确保付款方与收款方互不知晓对方的输入或输出（前提是同一次 WabiSabi coinjoin 中还有其他尊重保密性的参与者）。这将提供更高的隐私性，但需要使用实现 WabiSabi 的软件并等待协调完成一次 WabiSabi coinjoin 交易。 + +- ******DLC 消息与网络通信：** + Thibaut Le Guilly 在 DLC-Dev 邮件列表上[发帖][leguilly dlcmsg]，讨论改进不同 DLC 实现之间通信的方法。目前，各实现使用多种不同方式来寻找并与其他 DLC 节点通信，这些差异导致使用不同实现的节点无法互操作。Le Guilly 指出，制定 DLC 标准的目的正是为了实现互操作，因此他建议将相关细节加入标准。 + + 讨论涉及多个具体细节。Le Guilly 希望在可能的情况下复用 LN 规范（闪电网络规范（BOLTs））中的元素。这引出了近期一项关于升级 LN 通道公告的提案（见 [Newsletter #193][news193 major update]），该提案允许使用任意 UTXO 进行抗洪泛滥 DoS 保护（而不仅限于看起来像 LN 建立交易的 UTXO），从而使 DLC 及其他二层协议也能使用同样的 Anti-DoS 机制。 + +- ******更新 LN 承诺：** + Olaoluwa Osuntokun 本周在 Lightning-Dev 邮件列表[发帖][osuntokun dyncom]，作为他先前关于[升级通道承诺格式][topic channel commitment upgrades]（或升级影响承诺交易的任何设置）提案的跟进，相关摘要见 [Newsletter #108][news108 upcom]。目标是在为通道添加诸如[使用 taproot 功能][zmn post]等新特性时，仍能保持通道开放。 + + Osuntokun 的提案与 [BOLTs #868][] 中描述的替代方案形成对比，后者已在 C-Lightning 中进行实验性实现，并在 [Newsletter #152][news152 cl4532] 中提及。一个值得注意的差异是，Osuntokun 的方案在仍可能提出新支付（[HTLCs][topic htlc]）的同时升级通道，而 BOLTs #868 提案则规定了在升级期间必须保持安静期。 + +## 发布与候选发布 + +*新版本与候选版本的比特币基础设施项目。请考虑升级到新版本，或帮助测试候选版本。* + +- [Bitcoin Core 23.0 RC2][] 是该主流全节点软件下一主要版本的候选发布。[草稿发布说明][bcc23 rn]列出了多项改进，鼓励高级用户与系统管理员在正式发布前先行[测试][test guide]。 + +- [LND 0.14.3-beta.rc1][] 是这一流行 LN 节点软件的候选版本，包含若干漏洞修复。 + +- [C-Lightning 0.11.0rc1][] 是这一流行 LN 节点软件下一主要版本的候选发布。 + +## 值得注意的代码与文档更改 + +*本周在 [Bitcoin Core][bitcoin core repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中的值得注意的更改。* + +- [Bitcoin Core #24118][] 新增 RPC `sendall`，可将钱包中的余额全部发送给单一收款地址。该调用可通过选项指定额外收款人、限定钱包 UTXO 集的子集作为输入，或在跳过粉尘输出而非留零碎 UTXO 的情况下最大化收款金额。因此，`sendall` 为实现其他 `send*` RPC 中 `fSubtractFeeAmount` 参数的部分应用场景提供了便捷替代，但当收款方需承担手续费时，`fSubtractFeeAmount` 仍是最佳选择。 + +- [Bitcoin Core #23536][] 设定验证规则，只要启用 segwit，就始终强制执行 [taproot][topic taproot]（包括对历史区块的验证，除去区块 692261，其中包含在 taproot 激活前花费 v1 见证输出的交易）。这一*埋入式部署*已在 P2SH 与 segwit 软分叉中采用（参见 [Newsletter #60][news60 buried]）；它简化了测试与代码审查，降低了部署代码中潜在漏洞的风险，并为极端场景（节点下载到 taproot 未激活的另类最高工作量链）提供双保险。 + +- [Bitcoin Core #24555][] 与 [Bitcoin Core #24710][] 添加了关于在 CJDNS 网络上运行 Bitcoin Core 的[文档][cjdns.md]（见 [Newsletter #175][news175 cjdns]）。 + +- [C-Lightning #5013][] 增加了通过 gRPC 且使用 mTLS 认证来管理节点的功能。 + +- [C-Lightning #5121][] 为 `invoice` RPC 新增 `deschash` 参数，可在 [BOLT11][] 发票中包含任意数据的哈希，而非简短描述字符串。这可通过 [LNURL][] 等方案在 BOLT11 受限之外的信道中传递大型描述（例如图片）。 + +- [Eclair #2196][] 新增 `channelbalances` API，用于列出节点所有通道的余额，包括已被禁用的通道。 + +- [LND #6263][] 为 LND 钱包添加了 [taproot][topic taproot] 密钥路径支出支持，可在默认 [signet][topic signet] 上进行测试。 + +- [Libsecp256k1 #1089][] 将 `secp256k1_schnorrsig_sign()` 函数重命名为 `..._sign32()`，以更清晰地表明该函数用于签名 32 字节消息（例如 SHA256 摘要）。这与可签名任意长度消息的 `secp256k1_schnorrsig_sign_custom()` 形成对比，更多讨论见 [Newsletter #157][news157 schnorrsig]。 + +- [Rust Bitcoin #909][] 通过传入特定脚本路径被使用的概率，使用 [huffman coding][] 来创建最优 taproot 脚本路径树。 + +- [LDK #1388][] 默认支持通过寻找可更紧凑编码的值来创建平均更小的 ECDSA 签名，这一流程此前已在 Bitcoin Core 与 C-Lightning 钱包中实现（见 [Newsletters #8][news8 lowr] 与 [#71][news71 lowr]）。这种[低 R 值磨碎][topic low-r grinding] 在链上交易中可为每个 LDK 对等方节省约 0.125 vbyte。 + + +{% include references.md %} +{% include linkers/issues.md v=1 issues="868,24118,23536,24555,5013,5121,2196,6263,1089,909,1388,24710" %} +[bitcoin core 23.0 rc2]: https://bitcoincore.org/bin/bitcoin-core-23.0/ +[bcc23 rn]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/23.0-Release-Notes-draft +[test guide]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/23.0-Release-Candidate-Testing-Guide +[lnd 0.14.3-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.14.3-beta.rc1 +[C-Lightning 0.11.0rc1]: https://github.com/ElementsProject/lightning/releases/tag/v0.11.0rc1 +[news157 schnorrsig]: /zh/newsletters/2021/07/14/#libsecp256k1-844 +[news8 lowr]: /zh/newsletters/2018/08/14/#bitcoin-core-wallet-to-begin-only-creating-low-r-signatures +[news71 lowr]: /zh/newsletters/2019/11/06/#c-lightning-3220 +[news108 upcom]: /zh/newsletters/2020/07/29/#upgrading-channel-commitment-formats +[news152 cl4532]: /zh/newsletters/2021/06/09/#c-lightning-4532 +[zmn post]: /zh/newsletters/2021/09/01/#准备-taproot-11使用-taproot-的闪电网络 +[osuntokun dyncom]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-March/003531.html +[somsen silpay]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020180.html +[wasabi2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020032.html +[news102 wabisabi]: /zh/newsletters/2020/06/17/#wabisabi-coordinated-coinjoins-with-arbitrary-output-values +[hillebrand wormhole]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020186.html +[leguilly dlcmsg]: https://mailmanlists.org/pipermail/dlc-dev/2022-March/000135.html +[news193 major update]: /zh/newsletters/2022/03/30/#major-update +[lnurl]: https://github.com/fiatjaf/lnurl-rfc +[huffman coding]: https://en.wikipedia.org/wiki/Huffman_coding +[news60 buried]: /zh/newsletters/2019/08/21/#hardcoded-previous-soft-fork-activation-blocks +[news175 cjdns]: /zh/newsletters/2021/11/17/#bitcoin-core-23077 +[cjdns.md]: https://github.com/bitcoin/bitcoin/blob/6a02355ae9/doc/cjdns.md From 145e6aa0afba1afe455e29f29891b63e3bb40b45 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Mon, 16 Jun 2025 12:20:14 +0200 Subject: [PATCH 100/278] Newsletter 358 german and update STYLE-de (#2380) Co-authored-by: garfiel-d --- STYLE-DE.md | 100 ++++--- .../de/newsletters/2025-06-13-newsletter.md | 253 ++++++++++++++++++ 2 files changed, 302 insertions(+), 51 deletions(-) create mode 100644 _posts/de/newsletters/2025-06-13-newsletter.md diff --git a/STYLE-DE.md b/STYLE-DE.md index 3b755c48be..0ed87ffc1a 100644 --- a/STYLE-DE.md +++ b/STYLE-DE.md @@ -59,54 +59,52 @@ Fremdwörter möglichst mit Bindestrich schreiben (siehe [Duden, D41](https://ww ## Nicht übersetzte Begriffe und Ausnahmen -| Englischer Ausdruck | Kontext / Anmerkung | -|------------------------------- |-----------------------------------------------------| -| BDK | Produktname | -| BIP(mit nummer) | Protokoll-/Standardbegriff | -| BLIP | Protokoll-/Standardbegriff | -| BTCPay Server | Produktname | -| Channel | Etablierter Fachbegriff | -| Core Lightning | Produktname | -| Countersign | Eigenname des Verfahrens | -| Delving Bitcoin | Plattform-/Listenname | -| DLC | Layer-2/Smart-Contract/Transaktionsbegriff | -| DLC-Dev | Plattform-/Listenname | -| E-Cash-Shares | Korrigiert von "E-Cash-Anteile" | -| Eclair | Produktname | -| FPPS | Technischer Begriff/Auszahlungssystem | -| Full Node / Full Nodes | Immer im Original belassen | -| HTLC | Immer im Original belassen | -| Human Readable Names | Produkt-/Technikname | -| LDK | Produkt-/Technikname | -| LN | Layer-2/Smart-Contract/Transaktionsbegriff | -| LSPS | Produkt-/Technikname | -| Mining | Etablierter Fachbegriff | -| On-Chain | Layer-2/Smart-Contract/Transaktionsbegriff | -| OP_CHECKTEMPLATEVERIFY (CTV) | Protokoll-/Standardbegriff | -| Oracle | Lightning/DLC-Technik | -| output / input (bei UTXO) | Nur im UTXO-Kontext nicht übersetzen | -| Pay-per-Last-N-Shares | Technische Begriffe/Auszahlungssysteme | -| Pool | Etablierter Fachbegriff | -| Pool-Miner | Etablierter Fachbegriff | -| PR | Git/GitHub-Terminologie | -| Proxy | Technischer Begriff | -| PSBT | Protokoll-/Standardbegriff | -| PPLNS | Technischer Begriff/Auszahlungssystem | -| Release | Softwarebegriff | -| Releases | Softwarebegriff | -| Rust Bitcoin | Produktname | -| SCID | Protokoll-/Standardbegriff | -| Simple Taproot Channels | Lightning/DLC-Technik | -| Splice | Protokoll-/Standardbegriff | -| TIDES | Name des Systems | -| UTXO | Immer im Original belassen | -| Wallet | Produkt-/Technikname | -| merged | Git/GitHub-Terminologie | -| non-custodial | Immer im Original belassen, ist etabliert | -| Offchain | Layer-2/Smart-Contract/Transaktionsbegriff | - ---- - -## Maßeinheiten - -Siehe [Hauptleitfaden](STYLE.md). \ No newline at end of file +| Englischer Ausdruck | Kontext / Anmerkung | Genus | +|------------------------------- |-----------------------------------------------------|----------------------------| +| BDK | Produktname | | +| BIP(mit nummer) | Protokoll-/Standardbegriff | | +| BLIP | Protokoll-/Standardbegriff | | +| BTCPay Server | Produktname | Maskulinum | +| Channel | Etablierter Fachbegriff | Maskulinum | +| coin / coins | Coin ist im Kontext ein Fachbegriff | Maskulinum | +| Core Lightning | Produktname | | +| Countersign | Eigenname des Verfahrens | Neutrum | +| Delving Bitcoin | Plattform-/Listenname | | +| DLC | Layer-2/Smart-Contract/Transaktionsbegriff | | +| DLC-Dev | Plattform-/Listenname | | +| E-Cash-Share | Korrigiert von "E-Cash-Anteil" | Maskulinum | +| Eclair | Produktname | | +| FPPS | Technischer Begriff/Auszahlungssystem | | +| Full Node / Full Nodes | Immer im Original belassen | | +| HTLC | Immer im Original belassen | | +| Human Readable Names | Produkt-/Technikname | | +| LDK | Produkt-/Technikname | | +| LN | Layer-2/Smart-Contract/Transaktionsbegriff | | +| LSPS | Produkt-/Technikname | | +| merged | Git/GitHub-Terminologie | | +| Mining | Etablierter Fachbegriff | Femininum | +| non-custodial | Immer im Original belassen, ist etabliert | | +| Offchain | Layer-2/Smart-Contract/Transaktionsbegriff | | +| On-Chain | Layer-2/Smart-Contract/Transaktionsbegriff | | +| OP_CHECKTEMPLATEVERIFY (CTV) | Protokoll-/Standardbegriff | | +| Oracle | Lightning/DLC-Technik | | +| output / input (bei UTXO) | Nur im UTXO-Kontext nicht übersetzen | Maskulinum | +| Pay-per-Last-N-Shares | Technische Begriffe/Auszahlungssysteme | | +| Pool | Etablierter Fachbegriff | Maskulinum | +| Pool-Miner | Etablierter Fachbegriff | Maskulinum | +| PR | Git/GitHub-Terminologie | Maskulinum | +| Proxy | Technischer Begriff | Maskulinum | +| PSBT | Protokoll-/Standardbegriff | | +| PPLNS | Technischer Begriff/Auszahlungssystem | | +| Release | Softwarebegriff | Neutrum | +| Reviewer | Softwarebegriff | Maskulinum | +| Rust Bitcoin | Produktname | | +| SCID | Protokoll-/Standardbegriff | | +| Simple Taproot Channels | Lightning/DLC-Technik | | +| Splice | Protokoll-/Standardbegriff | | +| Splicing | Protokoll-/Standardbegriff | Neutrum | +| TIDES | Name des Systems | | +| UTXO | Immer im Original belassen | | +| Wallet | Produkt-/Technikname | | + +--- \ No newline at end of file diff --git a/_posts/de/newsletters/2025-06-13-newsletter.md b/_posts/de/newsletters/2025-06-13-newsletter.md new file mode 100644 index 0000000000..9f712108e9 --- /dev/null +++ b/_posts/de/newsletters/2025-06-13-newsletter.md @@ -0,0 +1,253 @@ +--- +title: 'Bitcoin Optech Newsletter #358' +permalink: /de/newsletters/2025/06/13/ +name: 2025-06-13-newsletter-de +slug: 2025-06-13-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche beschreibt, wie der Schwellenwert für die Gefahr von +Selfish Mining berechnet werden kann, fasst eine Idee zur Verhinderung des +Herausfilterns von Transaktionen mit hoher Gebühr zusammen, bittet um Feedback +zu einer vorgeschlagenen Änderung an BIP390-`musig()`-Deskriptoren und kündigt +eine neue Bibliothek zur Verschlüsselung von Deskriptoren an. Ebenfalls enthalten +sind unsere regulären Abschnitte mit der Zusammenfassung eines Bitcoin Core PR +Review Clubs, Ankündigungen neuer Releases und Release-Kandidaten sowie +Beschreibungen aktueller Änderungen an populärer Bitcoin-Infrastruktur. + +## Nachrichten + +- **Berechnung des Schwellenwerts für Selfish Mining:** + Antoine Poinsot [veröffentlichte][poinsot selfish] auf Delving Bitcoin eine + Erweiterung der Mathematik aus dem [Paper von 2013][es selfish], das dem + [Selfish-Mining-Angriff][topic selfish mining] seinen Namen gab (obwohl der + Angriff bereits [2010 beschrieben][bytecoin selfish] wurde). Er stellte außerdem + einen vereinfachten Mining- und Block-Relay-[Simulator][darosior/miningsimulation] + bereit, mit dem man mit dem Angriff experimentieren kann. Im Fokus steht die + Reproduktion einer der Schlussfolgerungen des Papers von 2013: Ein unehrlicher + Miner (oder ein Kartell gut vernetzter Miner), der 33 % der gesamten + Netzwerk-Hashrate kontrolliert (ohne weitere Vorteile), kann auf lange Sicht + marginal profitabler werden als die Miner mit den restlichen 67 % der Hashrate. + Dies wird erreicht, indem der 33 %-Miner die Bekanntgabe einiger neu gefundener + Blöcke selektiv verzögert. Steigt die Hashrate des unehrlichen Miners über 33 %, + wird der Angriff noch profitabler, bis er bei über 50 % die Konkurrenz vollständig + vom besten Blockchain-Zweig verdrängen kann. + + Wir haben Poinsots Beitrag nicht im Detail geprüft, sein Ansatz erscheint uns jedoch fundiert. + Wir empfehlen ihn allen, die sich für die Mathematik interessieren und sie nachvollziehen + oder besser verstehen möchten. + +- **Zensurresistenz beim Relay durch Top-Mempool-Set-Abgleichungen:** + Peter Todd [schrieb][todd feerec] auf der Bitcoin-Dev-Mailingliste über einen + Mechanismus, mit dem Knoten Peers aussortieren könnten, die Transaktionen mit + hoher Gebühr herausfiltern. Der Mechanismus basiert auf [Cluster Mempool][topic + cluster mempool] und einem Set-Abgleich (Reconciliation) wie bei [Erlay][topic + erlay]. Ein Knoten würde mit Cluster Mempool die profitabelste Menge + unbestätigter Transaktionen berechnen, die z.B. in 8.000.000 Weight Units + (maximal 8 MB) passen. Jeder Peer berechnet ebenfalls seine Top-8-MWU + unbestätigter Transaktionen. Mit einem effizienten Algorithmus wie + [minisketch][topic minisketch] gleicht der Knoten seine Transaktionsmenge mit + jedem Peer ab und erfährt so, welche Transaktionen jeder Peer im oberen Bereich + seines Mempools hat. Anschließend trennt der Knoten regelmäßig die Verbindung zu + dem Peer, dessen Mempool im Durchschnitt am wenigsten profitabel ist. + + Durch das Entfernen der am wenigsten profitablen Verbindungen findet der Knoten + schließlich Peers, die am wenigsten dazu neigen, Transaktionen mit hoher Gebühr + herauszufiltern. Todd plant, an einer Implementierung zu arbeiten, sobald Cluster + Mempool in Bitcoin Core integriert ist. Die Idee stammt von Gregory Maxwell und + anderen; Optech erwähnte das Grundprinzip erstmals in [Newsletter #9][news9 + reconcile]. + +- **BIP390-Update: Doppelte Teilnehmer-Schlüssel in `musig()`-Ausdrücken erlauben:** + Ava Chow [fragte][chow dupsig] auf der Bitcoin-Dev-Mailingliste, ob es Einwände + dagegen gibt, [BIP390][] so zu ändern, dass `musig()`-Ausdrücke in [Output Script + Deskriptoren][topic descriptors] denselben Teilnehmer-Public-Key mehrfach + enthalten dürfen. Das vereinfacht die Implementierung und ist explizit durch die + [BIP327][]-Spezifikation von [MuSig2][topic musig] erlaubt. Bis Redaktionsschluss + gab es keine Einwände, und Chow hat einen [Pull Request][bips #1867] zur Änderung + der BIP390-Spezifikation eingereicht. + +- **Bibliothek zur Verschlüsselung von Deskriptoren:** + Josh Doman [kündigte][doman descrypt] auf Delving Bitcoin eine Bibliothek an, die + sensible Teile eines [Output Script Deskriptors][topic descriptors] oder + [Miniscripts][topic miniscript] für die darin enthaltenen Public Keys verschlüsselt. + + Er beschreibt, welche Informationen zum Entschlüsseln benötigt werden: + + > - Wenn deine Wallet 2-von-3 Schlüsseln zum Ausgeben verlangt, werden genau + > 2-von-3 Schlüssel zum Entschlüsseln benötigt. + > + > - Wenn deine Wallet eine komplexe Miniscript-Policy wie „Entweder 2 Schlüssel + > ODER (ein Timelock UND ein weiterer Schlüssel)“ verwendet, folgt die + > Verschlüsselung derselben Struktur, als wären alle Timelocks und Hash-Locks + > erfüllt. + + Dies unterscheidet sich vom in [Newsletter #351][news351 salvacrypt] diskutierten + Backup-Schema, bei dem jeder Public Key im Deskriptor zur Entschlüsselung genügt. + Doman argumentiert, dass sein Ansatz mehr Privatsphäre bietet, wenn der + verschlüsselte Deskriptor z.B. öffentlich oder halböffentlich (etwa auf einer + Blockchain) gesichert wird. + +## Bitcoin Core PR Review Club + +*In diesem monatlichen Abschnitt fassen wir ein aktuelles [Bitcoin Core PR Review +Club][]-Meeting zusammen und heben wichtige Fragen und Antworten hervor. Ein Klick +auf eine Frage zeigt die Zusammenfassung der Antwort aus dem Meeting.* + +[Separate UTXO set access from validation functions][review club 32317] ist ein PR +von [TheCharlatan][gh thecharlatan], der es ermöglicht, Validierungsfunktionen +aufzurufen, indem nur die benötigten UTXOs übergeben werden, statt das komplette +UTXO-Set vorauszusetzen. Dies ist Teil des [`bitcoinkernel`-Projekts][Bitcoin Core +#27587] und ein wichtiger Schritt, um die Bibliothek für Full-Node-Implementierungen +nutzbar zu machen, die kein UTXO-Set implementieren, wie z.B. [Utreexo][topic +utreexo] oder [SwiftSync][somsen swiftsync] Knoten (siehe [Newsletter #349][news349 +swiftsync]). + +In den ersten vier Commits reduziert dieser PR die Kopplung zwischen +Transaktionsvalidierungsfunktionen und dem UTXO-Set, indem der Aufrufer die +benötigten `Coin`s oder `CTxOut`s selbst holen und an die Validierungsfunktion +übergeben muss, statt dass diese direkt auf das UTXO-Set zugreift. + +In späteren Commits wird die Abhängigkeit von `ConnectBlock()` zum UTXO-Set +vollständig entfernt, indem die verbleibende Logik, die UTXO-Set-Interaktion +benötigt, in eine eigene Methode `SpendBlock()` ausgelagert wird. + +{% comment %} +Die Fragen und Antworten aus dem Review Club werden wie im Original übernommen, +da sie für das technische Verständnis wichtig sind. +{% endcomment %} + +{% include functions/details-list.md + q0="Warum ist das Auslagern der neuen `SpendBlock()`-Funktion aus `ConnectBlock()` + für diesen PR hilfreich? Wie würdest du den Zweck der beiden Funktionen vergleichen?" + a0="Die Funktion `ConnectBlock()` führte ursprünglich sowohl die Blockvalidierung + als auch die Modifikation des UTXO-Sets durch. Dieses Refactoring trennt diese + Verantwortlichkeiten: `ConnectBlock()` ist jetzt nur noch für die Validierungslogik + zuständig, die kein UTXO-Set benötigt, während die neue Funktion `SpendBlock()` + alle Interaktionen mit dem UTXO-Set übernimmt. Dadurch kann ein Aufrufer + `ConnectBlock()` zur Blockvalidierung verwenden, ohne ein UTXO-Set zu benötigen." + a0link="https://bitcoincore.reviews/32317#l-37" + + q1="Siehst du einen weiteren Vorteil dieser Entkopplung, außer der Ermöglichung + der Kernel-Nutzung ohne UTXO-Set?" + a1="Neben der Ermöglichung der Kernel-Nutzung für Projekte ohne UTXO-Set + erleichtert diese Entkopplung das Testen des Codes in Isolation und vereinfacht die Wartung. + Ein Reviewer merkt auch an, dass die Beseitigung der Notwendigkeit für den Zugriff + auf das UTXO-Set die parallele Validierung von Blöcken ermöglicht, was ein wichtiges + Merkmal von SwiftSync ist." + a1link="https://bitcoincore.reviews/32317#l-64" + + q2="`SpendBlock()` benötigt einen `CBlock block`, `CBlockIndex pindex` und + `uint256 block_hash` Parameter, die alle auf den ausgegebenen Block verweisen. + Warum benötigen wir 3 Parameter dafür?" + a2="Validierungscode ist leistungskritisch, er beeinflusst wichtige + Parameter wie die Blockverbreitungsgeschwindigkeit. Den Blockhash + aus einem `CBlock` oder `CBlockIndex` zu berechnen, ist nicht umsonst, da der Wert nicht + zwischengespeichert wird. Aus diesem Grund hat der Autor beschlossen, die Leistung + zu priorisieren, indem er einen bereits berechneten `block_hash` als separaten Parameter übergibt. + Ebenso könnte `pindex` aus dem Blockindex abgerufen werden, + dies würde jedoch eine zusätzliche Map-Abfrage erfordern, der nicht unbedingt notwendig ist. +
_Hinweis: Der Autor hat später den + Ansatz [geändert][32317 updated approach], indem er die `block_hash`-Leistungsoptimierung entfernt hat._" + a2link="https://bitcoincore.reviews/32317#l-97" + + q3="Die ersten Commits in diesem PR refaktorisieren `CCoinsViewCache` aus der + Funktionssignatur einiger Validierungsfunktionen. Hält + `CCoinsViewCache` das gesamte UTXO-Set? Warum ist das (nicht) ein + Problem? Ändert sich durch diesen PR dieses Verhalten?" + a3="`CCoinsViewCache` hält nicht das gesamte UTXO-Set; es ist ein + Zwischenspeicher im Speicher, der vor `CCoinsViewDB` sitzt, welche das + vollständige UTXO-Set auf der Festplatte speichert. Wenn ein angeforderter + Coin nicht im Cache ist, muss sie von der Festplatte abgerufen werden. + Dieser PR ändert nicht das Caching Verhalten selbst. Durch das Entfernen von + `CCoinsViewCache` aus den Funktionssignaturen wird die UTXO-Abhängigkeit explizit, + was den Aufrufer verpflichtet, die Coins vor dem Aufruf der Validierungsfunktion abzurufen." + a3link="https://bitcoincore.reviews/32317#l-116" +%} + +## Releases und Release-Kandidaten + +_Neue Releases und Release-Kandidaten für populäre Bitcoin-Infrastrukturprojekte. +Bitte erwäge, auf neue Releases zu aktualisieren oder Release-Kandidaten zu testen._ + +- [Core Lightning 25.05rc1][] ist ein Release-Kandidat für die nächste Hauptversion + dieser beliebten LN-Knoten-Implementierung. + +- [LND 0.19.1-beta][] ist ein Release dieser beliebten LN-Knoten-Implementierung und + enthält [mehrere Fehlerbehebungen][lnd rn]. + +## Wichtige Code- und Dokumentationsänderungen + +_Bemerkenswerte aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd +repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi +repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], +[BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning +BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin +inquisition repo] und [BINANAs][binana repo]._ + +- [Bitcoin Core #32406][] hebt das Größenlimit für `OP_RETURN`-Outputs + (Standardness-Regel) auf, indem die Standardeinstellung für `-datacarriersize` + von 83 auf 100.000 Bytes (das maximale Transaktionsgrößenlimit) erhöht wird. + Die Optionen `-datacarrier` und `-datacarriersize` bleiben erhalten, sind aber + als veraltet markiert und werden in einer zukünftigen Version entfernt. Außerdem + wird die Beschränkung auf ein `OP_RETURN` pro Transaktion aufgehoben; das + Größenlimit gilt nun für alle `OP_RETURN`-Outputs einer Transaktion zusammen. + Siehe [Newsletter #352][news352 opreturn] für weitere Hintergründe. + +- [LDK #3793][] fügt eine neue Nachricht `start_batch` hinzu, die Peers signalisiert, + die nächsten `n` (`batch_size`) Nachrichten als eine logische Einheit zu behandeln. + Außerdem wird `PeerManager` so angepasst, dass dies für `commitment_signed`-Nachrichten + beim [Splicing][topic splicing] genutzt wird, statt für jede Nachricht ein TLV- und + `batch_size`-Feld zu verwenden. Ziel ist es, auch weitere LN-Protokollnachrichten zu + bündeln, nicht nur `commitment_signed`, wie es die LN-Spezifikation vorsieht. + +- [LDK #3792][] führt erste Unterstützung für [v3 Commitment-Transaktionen][topic v3 + commitments] (siehe [Newsletter #325][news325 v3]) ein, die auf [TRUC-Transaktionen][topic + v3 transaction relay] und [ephemeralen Anchors][topic ephemeral anchors] basieren + (hinter einem Test-Flag). Ein Knoten lehnt jetzt `open_channel`-Vorschläge mit nicht-null + Feerate ab, initiiert selbst keine solchen Channels mehr und akzeptiert v3-Channels erst, + nachdem ein UTXO für spätere Fee-Bumps reserviert wurde. Außerdem wird das pro-Channel- + [HTLC][topic htlc]-Limit von 483 auf 114 gesenkt, da TRUC-Transaktionen unter 10 kB + bleiben müssen. + +- [LND #9127][] fügt der Option `lncli addinvoice` den Parameter + `--blinded_path_incoming_channel_list` hinzu, mit dem ein Empfänger eine oder mehrere + bevorzugte Channel-IDs für den Zahler angeben kann, die beim Routing über einen + [Blinded Path][topic rv routing] bevorzugt werden sollen. + +- [LND #9858][] beginnt, das Produktions-Feature-Bit 61 für den [RBF][topic rbf]- + Cooperative-Close-Flow (siehe [Newsletter #347][news347 rbf]) zu signalisieren, um die + Interoperabilität mit Eclair zu ermöglichen. Das Staging-Bit 161 bleibt erhalten, um die + Interoperabilität mit Test-Knoten sicherzustellen. + +- [BOLTs #1243][] aktualisiert die [BOLT11][]-Spezifikation dahingehend, dass ein Reader + (Sender) eine Rechnung nicht bezahlen darf, wenn ein Pflichtfeld wie p (Payment Hash), + h (Description Hash) oder s (Secret) die falsche Länge hat. Zuvor konnten Knoten dieses + Problem ignorieren. Außerdem wird im Examples-Abschnitt ergänzt, dass [Low-R-Signaturen][topic + low-r grinding], auch wenn sie ein Byte sparen, nicht vorgeschrieben sind. + +{% include snippets/recap-ad.md when="2025-06-17 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32406,3793,3792,9127,1867,9858,1243,27587" %} +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[lnd 0.19.1-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.1-beta +[poinsot selfish]: https://delvingbitcoin.org/t/where-does-the-33-33-threshold-for-selfish-mining-come-from/1757 +[bytecoin selfish]: https://bitcointalk.org/index.php?topic=2227.msg30083#msg30083 +[darosior/miningsimulation]: https://github.com/darosior/miningsimulation +[todd feerec]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aDWfDI03I-Rakopb@petertodd.org/ +[news9 reconcile]: /en/newsletters/2018/08/21/#bandwidth-efficient-set-reconciliation-protocol-for-transactions +[chow dupsig]: https://mailing-list.bitcoindevs.xyz/bitcoindev/08dbeffd-64ec-4ade-b297-6d2cbeb5401c@achow101.com/ +[doman descrypt]: https://delvingbitcoin.org/t/rust-descriptor-encrypt-encrypt-any-descriptor-such-that-only-authorized-spenders-can-decrypt/1750/ +[news351 salvacrypt]: /de/newsletters/2025/04/25/#standardisiertes-backup-fur-wallet-deskriptoren +[es selfish]: https://arxiv.org/pdf/1311.0243 +[lnd rn]: https://github.com/lightningnetwork/lnd/blob/v0.19.1-beta/docs/release-notes/release-notes-0.19.1.md +[news352 opreturn]: /de/newsletters/2025/05/02/#erhohung-oder-abschaffung-des-op-return-grossenlimits-in-bitcoin-core +[news325 v3]: /en/newsletters/2024/10/18/#version-3-commitment-transactions +[news347 rbf]: /de/newsletters/2025/03/28/#lnd-8453 +[review club 32317]: https://bitcoincore.reviews/32317 +[gh thecharlatan]: https://github.com/TheCharlatan +[somsen swiftsync]: https://gist.github.com/RubenSomsen/a61a37d14182ccd78760e477c78133cd +[32317 updated approach]: https://github.com/bitcoin/bitcoin/pull/32317#issuecomment-2883841466 +[news349 swiftsync]: /de/newsletters/2025/04/11/#swiftsync-beschleunigung-fur-initial-block-download From c4b4b3f51c9b04c6ffc587215f2ea8042ed9778a Mon Sep 17 00:00:00 2001 From: Octoshi <125779328+cryptozyu@users.noreply.github.com> Date: Mon, 16 Jun 2025 09:56:10 +0800 Subject: [PATCH 101/278] newsletter-357: translate into Chinese (#170) * newsletter-357: translate into Chinese * fix format & some words --------- Co-authored-by: Zhiwei(Jeffrey) Hu --- .../zh/newsletters/2025-06-06-newsletter.md | 86 +++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 _posts/zh/newsletters/2025-06-06-newsletter.md diff --git a/_posts/zh/newsletters/2025-06-06-newsletter.md b/_posts/zh/newsletters/2025-06-06-newsletter.md new file mode 100644 index 0000000000..e034066ae5 --- /dev/null +++ b/_posts/zh/newsletters/2025-06-06-newsletter.md @@ -0,0 +1,86 @@ +--- +title: 'Bitcoin Optech Newsletter #357' +permalink: /zh/newsletters/2025/06/06/ +name: 2025-06-06-newsletter-zh +slug: 2025-06-06-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的周报分享了一篇关于不需要旧见证数据同步全节点的分析。此外还包括我们的常规部分：总结了关于更改比特币共识规则的讨论、新版本和候选版本的公告，以及对热门比特币基础设施软件的重大变更介绍。 + +## 新闻 + +- **不需要见证数据同步全节点：** Jose SK 在 Delving Bitcoin 上[发布][sk nowit]了他进行的一项[分析][sk nowit gist]的总结，该分析关于允许新启动的具有特定配置的全节点避免下载某些历史区块链数据的安全权衡。默认情况下，Bitcoin Core 节点使用 `assumevalid` 配置设置，跳过对在运行的 Bitcoin Core 版本发布前一两个月创建的区块中的脚本进行验证。虽然默认禁用，但许多 Bitcoin Core 用户也设置了 `prune` 配置，在验证区块后的一段时间删除这些区块（区块保留多长时间取决于区块的大小和用户选择的具体设置）。 + + SK 认为，仅用于验证脚本的见证数据不应该由剪枝节点下载用于 assumevalid 区块，因为它们不会用它来验证脚本，并且最终会删除它。他写道，跳过见证数据下载“可以减少超过 40% 的带宽使用”。 + + Ruben Somsen [认为][somsen nowit]这在某种程度上改变了安全模型。虽然脚本没有被验证，但下载的数据是根据区块头默克尔根到 coinbase 交易再到见证数据的承诺进行验证的。这确保了数据在节点最初同步时是可用且未损坏的。如果没有人定期验证数据的存在，它可能会丢失，就像至少一种山寨币[已经发生过][ripple loss]的那样。 + + 在撰写本文时，讨论仍在进行中。 + +## 共识变更 + +_每月一次的总结比特币共识规则变更提案和讨论的栏目。_ + +- **量子计算报告：** Clara Shikhelman 在 Delving Bitcoin 上[发布][shikelman quantum]了她与 Anthony Milton 共同撰写的一份[报告][sm report]的总结，该报告涉及快速量子计算机对比特币用户的风险、几种[量子抵抗][topic quantum resistance]途径的概述，以及升级比特币协议所涉及的权衡分析。作者发现有 400 万到 1000 万 BTC 可能容易受到量子盗窃的威胁，现在可以进行一些缓解措施，比特币挖矿在短期或中期内不太可能受到量子计算的威胁，并且升级需要广泛的共识。 + +- **带有防止被没收例外的交易重量限制：** Vojtěch Strnad 在 Delving Bitcoin 上[发布][strnad limit]了一个共识变更的想法，限制区块中大多数交易的最大重量。这个简单的规则只允许一个区块中有一个大于 400000 重量单位（100000 vbytes）的交易，前提是它是该区块中除 coinbase 交易外的唯一交易。Strnad 和其他人描述了限制最大交易重量的动机： + + * _更容易的区块模板优化：_ 与整体限制相比，项目越小，找到[背包问题][knapsack problem]的近似最优解就越容易。这部分是由于最小化最后剩余空间的数量，较小的项目留下的未使用空间更少。 + + * _更简单的中继策略：_ 节点之间中继未确认交易的策略预测哪些交易将被挖出，以避免浪费带宽。巨型交易使得准确预测变得更加困难，因为即使顶部费率的微小变化也可能导致它们被延迟或驱逐。 + + * _避免挖矿中心化：_ 确保中继全节点能够处理几乎所有交易，防止特殊交易的用户需要支付[协议外手续费用][topic out-of-band fees]，这可能导致挖矿中心化。 + + Gregory Sanders [指出][sanders limit]，基于 Bitcoin Core 12 年一贯的中继策略，简单地软分叉一个最大重量限制而不设任何例外可能是合理的。Gregory Maxwell [补充说][maxwell limit]，只花费软分叉前创建的 UTXO 的交易可以允许例外以防止没收，并且[临时软分叉][topic transitory soft forks]将允许限制在社区决定不更新时过期。 + + 额外的讨论研究了需要大型交易的各方的需求，主要是近期的 [BitVM][topic acc] 用户，以及他们是否有可用的替代方法。 + +- ******基于价值和时间从 UTXO 集中移除输出：** Robin Linus 在 Delving Bitcoin 上[发布][linus dust]了一个软分叉提案，用于在一段时间后从 UTXO 集中移除低价值输出。讨论了该想法的几种变体，主要有两种替代方案： + + * _销毁旧的不经济资金：_ 长时间未花费的小额输出将变得不可花费。 + + * _要求旧的不经济资金与存在证明一起花费：_ [utreexo][topic utreexo] 或类似系统可用于允许交易证明它花费的输出是 UTXO 集的一部分。旧的和[不经济的输出][topic uneconomical outputs]需要包含这个证明，但较新和较高价值的输出仍将存储在 UTXO 集中。 + + 任何一种解决方案都将有效限制 UTXO 集的最大大小（假设有最小值和 2100 万比特币限制）。讨论了设计的几个有趣的技术方面，包括在这种应用中可能更实用的 utreexo 证明的替代方案。 + +## 新版本和候选版本 + +*热门比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本。* + +- [Core Lightning 25.05rc1][] 是这个热门的闪电网络节点实现的下一个主要版本的候选版本。 + +- [LND 0.19.1-beta.rc1][] 是这个热门的闪电网络节点实现的维护版本的候选版本。 + +## 重大的代码和文档变更 + +*本周的重大变更有：[Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface（HWI）][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement Proposals（BIPs）][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo]。* + +- [Bitcoin Core #32582][] 添加了新的日志记录来测量[致密区块重建][topic compact block relay]的性能，通过跟踪节点从其对等节点请求的交易总大小（`getblocktxn`），节点发送给其对等节点的交易数量和总大小（`blocktxn`），并在 `PartiallyDownloadedBlock::InitData()` 开始时添加时间戳，以跟踪仅交易池查找步骤需要多长时间（在高带宽和低带宽模式下）。参见周报 [#315][news315 compact] 了解之前关于致密区块重建的统计报告。 + +- [Bitcoin Core #31375][] 添加了一个新的 `bitcoin -m` CLI 工具，它包装并执行[多进程][multiprocess project]二进制文件 `bitcoin node`（`bitcoind`）、`bitcoin gui`（`bitcoinqt`）、`bitcoin rpc`（`bitcoin-cli -named`）。目前，这些功能与单体二进制文件的方式相同，只是它们支持 `-ipcbind` 选项（参见周报 [#320][news320 ipc]），但未来的改进将使节点运行者能够在不同的机器和环境中独立启动和停止组件。参见[周报 #353][news353 pr review] 了解涵盖此 PR 的 Bitcoin Core PR 审核俱乐部。 + +- [BIPs #1483][] 合并了 [BIP77][]，该提案提出了 [payjoin v2][topic payjoin]，一种异步无服务器变体，其中发送者和接收者将其加密的 PSBT 交给一个 payjoin 目录服务器，该服务器只存储和转发消息。由于目录无法读取或更改有效载荷，因此任何一个钱包都不需要托管公共服务器或同时在线。参见周报 [#264][news264 payjoin] 了解关于 payjoin v2 的更多背景。 + +{% include snippets/recap-ad.md when="2025-06-10 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32582,31375,1483" %} +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[ripple loss]: https://x.com/JoelKatz/status/1919233214750892305 +[sk nowit]: https://delvingbitcoin.org/t/witnessless-sync-for-pruned-nodes/1742/ +[sk nowit gist]: https://gist.github.com/JoseSK999/df0a2a014c7d9b626df1e2b19ccc7fb1 +[somsen nowit]: https://gist.github.com/JoseSK999/df0a2a014c7d9b626df1e2b19ccc7fb1?permalink_comment_id=5597316#gistcomment-5597316 +[shikelman quantum]: https://delvingbitcoin.org/t/bitcoin-and-quantum-computing/1730/ +[sm report]: https://chaincode.com/bitcoin-post-quantum.pdf +[strnad limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/ +[knapsack problem]: https://zh.wikipedia.org/wiki/%E8%83%8C%E5%8C%85%E9%97%AE%E9%A2%98 +[sanders limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/2 +[maxwell limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/4 +[linus dust]: https://delvingbitcoin.org/t/dust-expiry-clean-the-utxo-set-from-spam/1707/ +[lnd 0.19.1-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.1-beta.rc1 +[news315 compact]: /zh/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction +[multiprocess project]: https://github.com/ryanofsky/bitcoin/blob/pr/ipc/doc/design/multiprocess.md +[news320 ipc]: /zh/newsletters/2024/09/13/#bitcoin-core-30509 +[news264 payjoin]: /zh/newsletters/2023/08/16/#serverless-payjoin-payjoin +[news353 pr review]: /zh/newsletters/2025/05/09/#bitcoin-core-pr-审核俱乐部 \ No newline at end of file From e4ee05387975a66b1c67154f67c38d9c612550f6 Mon Sep 17 00:00:00 2001 From: BitTom Date: Mon, 16 Jun 2025 22:08:11 +0800 Subject: [PATCH 102/278] Newsletter-195: translate into Chinese (#2371) --- .../zh/newsletters/2022-04-13-newsletter.md | 96 +++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 _posts/zh/newsletters/2022-04-13-newsletter.md diff --git a/_posts/zh/newsletters/2022-04-13-newsletter.md b/_posts/zh/newsletters/2022-04-13-newsletter.md new file mode 100644 index 0000000000..d14dae17ca --- /dev/null +++ b/_posts/zh/newsletters/2022-04-13-newsletter.md @@ -0,0 +1,96 @@ +--- +title: 'Bitcoin Optech Newsletter #195' +permalink: /zh/newsletters/2022/04/13/ +name: 2022-04-13-newsletter-zh +slug: 2022-04-13-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周 Newsletter 描述了一种在比特币交易和 LN 支付中转移非比特币代币的协议，并链接到了一个关于 MuSig2 多签名协议的拟议 BIP。我们的常规栏目还包括一场 Bitcoin Core PR 审查俱乐部会议的摘要、最新的软件发布与候选发布公告，以及流行比特币基础设施软件值得注意的变更说明。 + +## 新闻 + +- ******可转移代币方案：** + Olaoluwa Osuntokun [发布][osuntokun taro]到 Bitcoin-Dev 和 Lightning-Dev 邮件列表，提出了一组 *Taro* 协议的 BIP 草案，该协议允许用户在比特币区块链上记录非比特币代币的创建与转移。例如，Alice 可以发行 100 枚代币，向 Bob 转移 50 枚，而 Bob 又可以用其中 25 枚代币与 Carol 交换 10 BTC。该思路与此前在比特币上实现的方案类似，但在细节上有所不同，例如复用了 [taproot][topic taproot] 的若干设计元素以减少需要编写的新代码量，并通过使用 merkle 树来减少证明某些操作已发生时需传输的数据量。 + + Taro [旨在][gentry taro]与 LN 配合，用于可路由的链下转移。与此前在 LN 上进行跨资产转移的方案相似，仅用于路由支付的中间节点无需了解 Taro 协议或所转移资产的细节——它们只需像处理其他 LN 支付一样传递 BTC 即可。 + + 该想法本周在邮件列表上获得了适度的讨论。 + +- ******MuSig2 提案 BIP：** + Jonas Nick、Tim Ruffing 和 Elliott Jin [发布][nick musig2]了一个[拟议的 BIP][musig2 bip]至 Bitcoin-Dev 邮件列表，介绍了 [MuSig2][topic musig] 这一[多签名][topic multisignature]协议，用于创建公钥与签名。多个由不同方或软件控制的私钥可以使用 MuSig2 衍生聚合公钥，而无需各方之间共享任何私密信息。随后，也可以生成聚合签名，同样无需共享私密信息。对于第三方来说，聚合公钥与聚合签名看起来就像普通公钥与 [schnorr 签名][topic schnorr signatures]，因此不会泄露参与聚合的方数或私钥数量，相比链上多签在隐私性上具有优势。 + + MuSig2 在几乎所有设想的应用中都优于最初的 MuSig 提案（现称 *MuSig1*）。与替代方案 MuSig-DN（deterministic nonce）相比，MuSig2 更易于实现，但二者之间存在一些取舍，应用开发者在选择协议时可能希望加以权衡。 + +## Bitcoin Core PR 审查俱乐部 + +*在本月栏目中，我们总结最近一次 [Bitcoin Core PR Review Club][] 会议，突出一些重要的问答。点击下面的问题可查看会议回答的摘要。* + +[通过发送额外的 getheaders 消息防止区块索引指纹识别][reviews 24571] 是 Niklas Gögge 的一个拉取请求，旨在防止通过区块索引对节点进行指纹识别。 + +{% include functions/details-list.md + + q0="区块索引是什么，它有什么用途？" + a0="区块索引是在内存中的一个索引，用于查找区块头以及磁盘上区块数据的位置。它可能会保留多条分支（即包含过时区块头）的区块“树”，以便在发生重组时能够适应。" + a0link="https://bitcoincore.reviews/24571#l-17" + + q1="我们应不应该在区块索引中保留过时区块？为什么？" + a1="当存在多条分支时，保留它们的索引可以使节点在最多工作量链发生变化时迅速切换分支。一些与会者指出，保留非常旧的过时区块可能意义不大，因为发生重组的概率极低。然而，这些区块头占用的存储空间非常小，并且因为节点在存储之前会检查工作量证明，所以攻击者若想通过发送有效工作量证明的过时区块头来耗尽节点资源，其成本会非常高。" + a1link="https://bitcoincore.reviews/24571#l-68" + + q2="描述一种利用节点区块索引进行指纹识别的攻击。" + a2="在 IBD（初始区块下载）期间，节点只会请求并下载属于其在初始区块头同步过程中了解到的最多工作量链的区块。因此，其区块索引中的过时区块通常是在 IBD 之后挖出的，但这可能自然变化，也可能被拥有大量旧过时区块头的攻击者操纵。攻击者若持有包含区块头 H 和 H+1 的过时分支，可以向节点发送 H+1。若节点在其区块索引中没有 H，它会通过 `getdata` 消息请求 H；如果已经拥有 H，则不会请求。" + a2link="https://bitcoincore.reviews/24571#l-75" + + q3="为何防止节点指纹识别很重要？" + a3="节点运营者可能采取多种技术来隐藏其节点的 IP 地址，例如使用 Tor。然而，如果攻击者能够将同一节点在 IPv4 和 Tor 网络上的地址相关联，这些隐私收益就会被削弱或抵消。如果一个节点仅运行在 Tor 上，指纹识别也可能被用来将属于同一节点的多个 Tor 地址关联起来，或在节点切换到 IPv4 时识别该节点。" + a3link="https://bitcoincore.reviews/24571#l-84" +%} + +## 发布与候选发布 + +*面向主流比特币基础设施项目的新版本与候选版本。请考虑升级至新版本，或协助测试候选版本。* + +- [LDK 0.0.106][LDK 0.0.106] 是这个 LN 节点库的最新发布。该版本增加了对 [BOLTs #910][] 中提出的通道标识 `alias` 字段的支持，LDK 在某些场合利用它来提升隐私，并包含若干其他特性与错误修复。 + +- [BTCPay Server 1.4.9][BTCPay Server 1.4.9] 是这款流行支付处理软件的最新发布。 + +- [Bitcoin Core 23.0 RC4][Bitcoin Core 23.0 RC4] 是这一主流全节点软件的候选版本。其[草案发布说明][bcc23 rn]列出了多项改进，鼓励高级用户和系统管理员在最终发布前进行[测试][test guide]。 + +- [LND 0.14.3-beta.rc1][LND 0.14.3-beta.rc1] 是这款流行 LN 节点软件的候选版本，包含若干错误修复。 + +- [Core Lightning 0.11.0rc1][Core Lightning 0.11.0rc1] 是这款流行 LN 节点软件的下一主版本候选发布。 + +## 值得注意的代码与文档修改 + +*本周在 [Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]及[闪电网络规范（BOLTs）][bolts repo]中的值得注意的变更。* + +- [Bitcoin Core #24152][] 通过引入[包费率][package feerate]并以其替代单笔交易费率，允许在“子交易带未确认父交易”的包中使用 CPFP（Child-Pays-For-Parent）手续费提升。如 [Newsletter #186][news186 package] 所述，这是提升 CPFP 和 RBF（Replace-By-Fee）手续费提升灵活性与可靠性的一系列修改的一部分。该补丁还[首先验证单笔交易][validates individual transactions first]，以避免出现“父为子付费”或“兄弟交易互付费”等与激励不兼容的策略。 + +- [Bitcoin Core #24098][] 更新了 `/rest/headers/` 与 `/rest/blockfilterheaders/` RPC，使其可使用查询参数（例如 `?count=`）来替代端点参数（例如 `//`）。文档也已更新，鼓励优先使用查询参数。 + +- [Bitcoin Core #24147][] 为 [miniscript][topic miniscript] 增加了后端支持。后续的 PR [#24148][bitcoin core #24148] 与 [#24149][bitcoin core #24149] 若被合并，将分别为[输出脚本描述符][topic descriptors]和钱包签名逻辑加入 miniscript 支持。 + +- [Core Lightning #5165][] 将 C-Lightning 项目更名为 [Core Lightning][core lightning repo]，简称 CLN。 + +- [Core Lightning #5086][] 增加了在付款中附加 `option_payment_metadata` 发票数据的能力，为[无状态发票][topic stateless invoices]提供了付款方支持；接收方支持尚未在本 PR 中加入 CLN。 + + +{% include references.md %} +{% include linkers/issues.md v=2 issues="24152,24098,24147,24148,24149,5165,5086,910" %} +[bitcoin core 23.0 rc4]: https://bitcoincore.org/bin/bitcoin-core-23.0/ +[bcc23 rn]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/23.0-Release-Notes-draft +[test guide]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/23.0-Release-Candidate-Testing-Guide +[lnd 0.14.3-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.14.3-beta.rc1 +[core lightning 0.11.0rc1]: https://github.com/ElementsProject/lightning/releases/tag/v0.11.0rc1 +[gentry taro]: https://lightning.engineering/posts/2022-4-5-taro-launch/ +[osuntokun taro]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003539.html +[nick musig2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020198.html +[musig2 bip]: https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki +[ldk 0.0.106]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.106 +[btcpay server 1.4.9]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.4.9 +[reviews 24571]: https://bitcoincore.reviews/24571 +[news186 package]: /zh/newsletters/2021/09/22/#package-mempool-acceptance-and-package-rbf +[package feerate]: https://gist.github.com/glozow/dc4e9d5c5b14ade7cdfac40f43adb18a#fee-related-checks-use-package-feerate +[validates individual transactions first]: https://gist.github.com/glozow/dc4e9d5c5b14ade7cdfac40f43adb18a#always-try-individual-submission-first From 405ef86f01fdb0b5eb822ef41f42ecc88ef53c6b Mon Sep 17 00:00:00 2001 From: BitTom Date: Mon, 16 Jun 2025 22:09:55 +0800 Subject: [PATCH 103/278] Newsletter-196: translate into Chinese (#2372) --- .../zh/newsletters/2022-04-20-newsletter.md | 69 +++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 _posts/zh/newsletters/2022-04-20-newsletter.md diff --git a/_posts/zh/newsletters/2022-04-20-newsletter.md b/_posts/zh/newsletters/2022-04-20-newsletter.md new file mode 100644 index 0000000000..21f798c5aa --- /dev/null +++ b/_posts/zh/newsletters/2022-04-20-newsletter.md @@ -0,0 +1,69 @@ +--- +title: 'Bitcoin Optech Newsletter #196' +permalink: /zh/newsletters/2022/04/20/ +name: 2022-04-20-newsletter-zh +slug: 2022-04-20-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周 Newsletter 总结了关于在 Bitcoin 中允许量子安全密钥交换的讨论，并包含我们常规的版块，介绍服务和客户端软件的值得注意的更改、发布与候选发布以及流行的比特币基础设施软件。 + +## 新闻 + +- ******量子安全密钥交换：** Erik Aronesty 在 Bitcoin-Dev 邮件列表上发起了关于[量子抗性][topic quantum resistance]——当出现快速量子计算机（QC）时保持 Bitcoin 安全——的[讨论线程][aronesty qc]。预测认为，快速 QC 能够在不知道原始私钥的情况下生成与比特币公钥对应的签名，使得拥有快速 QC 的人可以花费属于他人的比特币。很少有安全研究人员认为快速 QC 是短期威胁，但如果有任何方法能够在不显著干扰现有 Bitcoin 用途的情况下消除这一隐患，那么就值得被考虑。 + + Aronesty 建议允许用户接收支付到由量子安全算法保护的公钥——同时也可使用现有风格的 Bitcoin 公钥来保护这些比特币，这样在两种密钥算法中都被发现可利用的漏洞之前，任何比特币都无法因为密码学密钥失效而被盗。这将需要一次软分叉共识变更，并且在最坏情况下可能会减少每个区块中可用的有效交易数量，因为量子安全见证数据比 Bitcoin 当前使用的 ECDSA 和 schnorr 签名见证数据更大。 + + Lloyd Fournier [建议][fournier qc]开发一种标准化方案，使 taproot 输出能够除了其常规 schnorr 公钥之外，还承诺量子安全公钥。量子安全公钥目前可能无法被花费，但如果 Bitcoin 用户开始更加担心即将到来的快速 QC，他们可以选择通过软分叉添加一项要求使用量子安全支出路径的共识变更。Fournier 还建议将问题和可能的解决方案[记录][qc issue]在 [BitcoinProblems.org][] 上，供当前和未来的研究人员及开发者参考。 + +## 服务和客户端软件的更改 + +*在这一月度栏目中，我们重点介绍 Bitcoin 钱包和服务的有趣更新。* + +- ******Bitcoin.com 新增 segwit 发送：** 在一次[近期更新][bitcoin.com segwit]中，Bitcoin.com 钱包现已支持向原生 segwit（bech32）地址发送比特币。 +- ******Kraken 新增 Lightning 支持：** Kraken 使用 LND，已经[支持][kraken lightning]通过闪电网络进行最高 0.1 BTC 的充值和提现。 +- ******Cash App 新增 Lightning 收款支持：** 在此前新增[闪电网络发送功能][news183 cash app ln send]之后，Cash App 现已上线让用户通过闪电网络收款的能力。Cash App 的 LN 功能基于 [Lightning Development Kit (LDK)][ldk website]。 +- ******BitPay 新增 Lightning 收款支持：** 支付处理商 BitPay [宣布][bitpay lightning]其商户可接受 LN 支付。 + +## 发布与候选发布 + +*流行的比特币基础设施项目的新版本与候选版本。请考虑升级到新版本或帮助测试候选版本。* + +- [LND 0.14.3-beta][LND 0.14.3-beta] 是该热门 LN 节点软件的一个包含多项错误修复的版本。 + +- [Bitcoin Core 23.0 RC5][Bitcoin Core 23.0 RC5] 是此主要全节点软件的下一个主要版本的候选版本。[草拟版发布说明][bcc23 rn]列出了多项改进，鼓励高级用户和系统管理员在最终发布前进行[测试][test guide]。 + +- [Core Lightning 0.11.0rc3][Core Lightning 0.11.0rc3] 是该热门 LN 节点软件的下一个主要版本的候选版本。 + +## 值得注意的代码与文档变更 + +*本周在 [Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中的值得注意的变更。* + +- [LND #5810][LND #5810] 实现了对支付元数据的发送支持。如果发票包含支付元数据，发送方将把该数据编码为一个 TLV 记录发送给接收方。这是朝着解锁[无状态发票][topic stateless invoices]迈出的又一步，无状态发票允许接收方在支付尝试到达时重新生成发票，从而无需信任地存储展示给潜在发送方的发票。 + +- [LND #6212][LND #6212] 阻止 HTLC 在以下情况下通过 HTLC 拦截器发送到外部进程：如果接受该 HTLC 可能需要通道立即或在短时间内链上关闭。当 HTLC 的过期高度接近最近看到的区块时，会发生这种情况。 + +- [LND #6024][LND #6024] 添加了一个 `time_pref` 路径寻找参数，可用于在通过被认为更有可能转发支付（更快）的通道和收取更少手续费的通道之间进行权衡。 + +- [LND #6385][LND #6385] 移除了在构造新支付时使用最初 LN 协议洋葱包格式的选项，现要求用户创建 TLV 风格的洋葱包。TLV 洋葱包在 2019 年加入协议（参见 [Newsletter #55][news55 tlv]），并在所有 LN 软件中已成为默认格式超过两年。其它 LN 软件也在进行类似变更以移除旧洋葱包格式支持，例如 [Newsletter #158][news158 cl4646] 报道的 Core Lightning 更新。 + + +{% include references.md %} +{% include linkers/issues.md v=2 issues="5810,6212,6024,6385" %} +[bitcoin core 23.0 rc5]: https://bitcoincore.org/bin/bitcoin-core-23.0/ +[bcc23 rn]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/23.0-Release-Notes-draft +[test guide]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/23.0-Release-Candidate-Testing-Guide +[lnd 0.14.3-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.14.3-beta +[core lightning 0.11.0rc3]: https://github.com/ElementsProject/lightning/releases/tag/v0.11.0rc3 +[aronesty qc]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020209.html +[fournier qc]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020214.html +[qc issue]: https://github.com/bitcoin-problems/bitcoin-problems.github.io/issues/4 +[bitcoinproblems.org]: https://bitcoinproblems.org/ +[news55 tlv]: /zh/newsletters/2019/07/17/#bolts-607 +[news158 cl4646]: /zh/newsletters/2021/07/21/#c-lightning-4646 +[bitcoin.com segwit]: https://support.bitcoin.com/en/articles/3919131-can-i-send-to-a-bc1-address +[kraken lightning]: https://blog.kraken.com/post/13502/kraken-now-supports-instant-lightning-network-btc-transactions/ +[news183 cash app ln send]: /zh/newsletters/2022/01/19/#cash-app-adds-lightning-support +[ldk website]: https://lightningdevkit.org/ +[bitpay lightning]: https://bitpay.com/blog/bitpay-supports-lightning-network-payments/ From 3c065bda16640a80d05a82fe36c2785cc0fe0d9f Mon Sep 17 00:00:00 2001 From: BitTom Date: Tue, 17 Jun 2025 18:08:06 +0800 Subject: [PATCH 104/278] Newsletter-197: translate into Chinese (#2373) --- .../zh/newsletters/2022-04-27-newsletter.md | 112 ++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 _posts/zh/newsletters/2022-04-27-newsletter.md diff --git a/_posts/zh/newsletters/2022-04-27-newsletter.md b/_posts/zh/newsletters/2022-04-27-newsletter.md new file mode 100644 index 0000000000..48243ef64b --- /dev/null +++ b/_posts/zh/newsletters/2022-04-27-newsletter.md @@ -0,0 +1,112 @@ +--- +title: 'Bitcoin Optech Newsletter #197' +permalink: /zh/newsletters/2022/04/27/ +name: 2022-04-27-newsletter-zh +slug: 2022-04-27-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的 Newsletter 总结了关于激活 `OP_CHECKTEMPLATEVERIFY` 的讨论，并照例收录了 Bitcoin Stack Exchange 精选问答、最新的软件发布与候选发布，以及热门比特币基础设施软件的近期变更。 + +## News + +- ******关于激活 CTV 的讨论：** + Jeremy Rubin [发帖][rubin ctv-st]到 Bitcoin-Dev 邮件列表，介绍了他计划发布的一款软件。该软件允许矿工开始表示他们是否打算执行提议中的 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]（CTV）操作码所定义的 [BIP119][] 规则。如果在接下来的若干个 2,016 个区块（约两周）的难度调整周期中，有 90% 的区块给出积极信号，那么任何运行 Rubin 软件的用户将从 11 月初左右开始自行强制执行 CTV 的规则。 + + Rubin 详细阐述了他认为比特币用户如今可能希望激活 CTV 的多项理由，例如： + + - *****一致性：* CTV 拥有稳定的规范与实现 + - *****普及度：* 社区内不少知名个人与机构支持 CTV + - *****可行性：* 目前尚无意见认为 CTV 会破坏比特币任何重要且被广泛期望的属性 + - *****需求性：* CTV 能提供用户需要的功能，例如基于[契约][topic covenants]的[保险库][topic vaults] + + 在邮件列表中，十余位开发者回复了 Rubin 的邮件或在其他线程中讨论。我们无法完整概述所有值得注意的回复，以下摘录的是部分颇具启发性的观点： + + - ****Anthony Towns [分析][towns ctv signet]了 CTV [Signet 测试网][topic signet]上的交易。几乎所有交易似乎均由同一套软件（[Sapio][Sapio]）构建，这可能意味着公众对 CTV 的探索仍然有限。他进一步指出，引入新的共识规则会给所有比特币用户带来风险——即便是那些不打算使用该新功能的人——因此有必要向不采用者提供公开的证据，证明该功能“对他人来说足够有价值，足以抵偿这些风险”。在这篇帖子之后，又有[更多实验][fiatjaf vault]在 CTV Signet 上进行。 + + - ****Matt Corallo 也[提出][corallo ctv cost]，改变共识规则会为所有人带来显著成本，因此我们只有在确信某项提议能提供最大价值时才应当尝试软分叉。就契约而言，Corallo 希望看到“最灵活、最有用，并且最好是私密”的设计。他[随后表示][corallo not clear]：“就我所见，目前还不清楚 CTV 是否真的一个优秀的选项。” + + - ****Russell O'Connor 在 #bitcoin-wizards IRC 中[指出][oconnor wizards]，使用 CTV 的某些方式无法通过现有比特币地址格式（如 base58check、[Bech32][topic bech32] 或 bech32m）表达。以 *裸脚本*（直接出现在 scriptPubKey 中的脚本）方式使用 CTV 将要求钱包开发者仅在其内部交易中使用裸 CTV，或者编写专用工具来传递通常包含于地址中的信息。另一种选择是，钱包若想在某些场景下使用 CTV（例如 [保险库][topic vaults]），可以先接收至承诺未来使用裸 CTV 的 P2TR 地址。 + O'Connor 关于地址限制的讨论被 Towns [提及][towns bare]于邮件列表。O'Connor 又[回复][oconnor bare]了更多细节，并指出如果裸 CTV 不包含在 BIP119 规范内，他会提倡一种更简单、更易组合（更容易与其他操作码结合以构建有用脚本）的不同设计——尽管他更偏好更通用的 `OP_TXHASH` 设计（见 [Newsletter #185][news185 txhash]）。Rubin [回应][rubin bare]了数点反驳意见。 + + - ****David Harding [转述][harding transitory]了一个担忧：CTV 也许在长期内不会被广泛使用，要么是因为其应用场景未能实现，要么是因为其他契约构造可以更好地满足主流需求。这将使未来的共识代码开发者不得不永久维护 CTV 代码，并分析其与后续提议共识变更的潜在交互。Harding 建议暂时向比特币中加入 CTV，为期五年，在此期间收集实际使用数据，然后自动禁用 CTV，除非五年后的比特币用户决定值得保留。没有回应者支持此方案，多数人认为其成本过高或收益过低。同时有人指出，未来若想完全验证 CTV 处于激活状态期间产生的区块，仍然需要 CTV 校验代码，因此即便五年后禁用该操作码，也可能仍需永久维护其代码。 + + - ****Antoine “Darosior” Poinsot [请求][darosior apo]就激活略经修改的 [BIP118][] `SIGHASH_ANYPREVOUT`（[APO][topic sighash_anyprevout]）而非 CTV，或至少先于 CTV 激活 APO，征求意见。该修改版本的 APO 可模拟 CTV 的能力，但在某些应用中成本更高。激活 APO 还将使其可用于其最初设想的用途——为 LN 引入拟议中的 [Eltoo][topic eltoo] 层，借此实现更高效且（有人认为）更安全的通道状态更新。 + + - ****James O'Beirne [提出][obeirne benchmark]，他基于 CTV 的 [simple vault][] 设计可作为评估不同契约方案的基准，因为它简单，并且在他看来若能投入生产使用，能够显著提升许多比特币用户的安全性。Darosior 首个接受此挑战，将 simple vault 代码[移植][darosior vault]到了 `SIGHASH_ANYPREVOUT` 的实现上。 + + 截至本文撰写时，邮件列表上的讨论仍十分活跃。关于 CTV 与契约技术的有趣对话还出现在 Twitter、IRC、Telegram 等多个渠道。我们鼓励这些讨论的参与者将任何重要见解分享到 Bitcoin-Dev 邮件列表。 + + 在上述讨论之后，Jeremy Rubin [宣布][rubin path forward]他不会立即发布可让 CTV 激活的软件二进制版本，而是将评估收到的反馈，并与其他 CTV 支持者合作，可能提出修订后的激活计划。Optech 将在之后的 Newsletter 中继续跟进该话题。 + +## Bitcoin Stack Exchange 精选问答 + +*[Bitcoin Stack Exchange][bitcoin.se] 是许多 Optech 贡献者寻找答案的首选之地；当我们有空时，也会在此帮助有疑问的用户。在本月专栏中，我们汇总了自上次更新以来收到高票的部分问答。* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- ****[secp256k1 曲线中的生成元点 G 是如何选取的？]({{bse}}113116) + Pieter Wuille 提到，虽然关于常数[生成元点 G][se 29904] 的确切选取缘由并未公开，但其具备的一个不寻常属性或许能暗示其构造方式。 + +- ****[P2P 消息有效载荷的最大、现实尺寸是多少？]({{bse}}113059) + 0xb10c 询问是否存在大小为 `MAX_SIZE`（32 MB）的有效 [P2P 消息][p2p messages]。Pieter Wuille 解释说，`MAX_PROTOCOL_MESSAGE_LENGTH`（4 MB，[segwit 调整][Bitcoin Core #8149]将其从 [2 MB][Bitcoin Core #5843] 增至 4 MB）才是真正限制入站消息大小，以防范拒绝服务攻击。 + +- ****[有没有证据表明“陈旧区块”数量减少？]({{bse}}113413) + Lightlike 引用了 [KIT statistics][] 网站上一张历史区块传播时间图，并指出[致密区块中继][topic compact block relay]（[BIP152][]，最初实现在 [#8068][Bitcoin Core #8068] 中）是导致[陈旧区块][se 5866]频率随时间下降的因素之一。 + + {:.center} + ![区块传播延迟历史图](/img/posts/2022-04-block-propagation-delay.png) + +- ****[coinbase 交易的输入字段是否包含 VOUT？]({{bse}}113392) + Pieter Wuille 概述了 coinbase 交易输入的要求：前序输出哈希必须为 `0000000000000000000000000000000000000000000000000000000000000000`，前序输出索引必须为 `ffffffff`，`scriptSig` 长度必须在 2–100 字节之间，并且自 [BIP34][] 起 `scriptSig` 还必须以区块高度开头。 + +## 发布与候选发布 + +*热门比特币基础设施项目的新版本与候选版本。请考虑升级到新版或帮助测试候选版本。* + +- [Bitcoin Core 23.0][] 是这一主流全节点软件的下一主要版本。[发行说明][bcc23 rn]罗列了多项改进，包括：对新钱包默认启用[描述符][topic descriptors]钱包；描述符钱包现已轻松支持使用 [taproot][topic taproot] 的 [bech32m][topic bech32] 地址收款。 + +- [Core Lightning 0.11.0][] 是这一热门闪电网络节点软件的下一个主要版本。除其他功能与修复外，新版本支持与同一对等节点建立多条活动通道，并支持支付[无状态发票][topic stateless invoices]。 + +- [Rust-Bitcoin 0.28][] 为该比特币库的最新版本。最显著的变化是加入对 taproot 的支持，并改进了相关 API（例如 [PSBTs][topic psbt]）。更多改进与修复详见[发行说明][rb28 rn]。 + +## 值得注意的代码与文档变更 + +*本周在 [Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中的值得注意的变更。* + +- [LND #5157][] 新增 `--addpeer` 启动选项，可在启动时与指定节点建立对等连接。 + +- [LND #6414][] 在启用的情况下开始在节点公告中声明对 keysend [自发支付][topic spontaneous payments]的支持。LND 自 2019 年起便已支持 keysend，但最初并无法让节点宣告自身支持。其他 LN 节点软件在节点公告中已添加此功能，此次合并的拉取请求让 LND 与之保持一致。 + + +{% include references.md %} +{% include linkers/issues.md v=2 issues="5157,6414,5843,8149,8068" %} +[bitcoin core 23.0]: https://bitcoincore.org/bin/bitcoin-core-23.0/ +[bcc23 rn]: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-23.0.md +[core lightning 0.11.0]: https://github.com/ElementsProject/lightning/releases/tag/v0.11.0.1 +[rust-bitcoin 0.28]: https://github.com/rust-bitcoin/rust-bitcoin/releases/tag/0.28.0 +[rb28 rn]: https://github.com/rust-bitcoin/rust-bitcoin/blob/master/CHANGELOG.md#028---2022-04-20-the-taproot-release +[rubin ctv-st]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020233.html +[towns ctv signet]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020234.html +[sapio]: https://learn.sapio-lang.org/ +[corallo ctv cost]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020263.html +[corallo not clear]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020289.html +[oconnor wizards]: https://gnusha.org/bitcoin-wizards/2022-04-19.log +[towns bare]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020245.html +[oconnor bare]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020256.html +[rubin bare]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020260.html +[harding transitory]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020242.html +[darosior apo]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020276.html +[obeirne benchmark]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020280.html +[simple vault]: https://github.com/jamesob/simple-ctv-vault +[news185 txhash]: /zh/newsletters/2022/02/02/#composable-alternatives-to-ctv-and-apo +[fiatjaf vault]: https://twitter.com/fiatjaf/status/1517836181240782850 +[rubin path forward]: https://twitter.com/JeremyRubin/status/1518477022439247872 +[darosior vault]: https://twitter.com/darosior/status/1518961471702642689 +[se 29904]: https://bitcoin.stackexchange.com/questions/29904/ +[p2p messages]: https://developer.bitcoin.org/reference/p2p_networking.html#data-messages +[bitcoin protocol 4mb]: https://github.com/bitcoin/bitcoin/commit/2b1f6f9ccf36f1e0a2c9d99154e1642f796d7c2b +[KIT statistics]: https://www.dsn.kastel.kit.edu/bitcoin/index.html +[se 5866]: https://bitcoin.stackexchange.com/a/5866/87121 From 484223e8a58577860e947edc308f7d60b64c369e Mon Sep 17 00:00:00 2001 From: BitTom Date: Tue, 17 Jun 2025 18:09:51 +0800 Subject: [PATCH 105/278] Newsletter-198: translate into Chinese (#2374) --- .../zh/newsletters/2022-05-04-newsletter.md | 88 +++++++++++++++++++ 1 file changed, 88 insertions(+) create mode 100644 _posts/zh/newsletters/2022-05-04-newsletter.md diff --git a/_posts/zh/newsletters/2022-05-04-newsletter.md b/_posts/zh/newsletters/2022-05-04-newsletter.md new file mode 100644 index 0000000000..2b51bb37a7 --- /dev/null +++ b/_posts/zh/newsletters/2022-05-04-newsletter.md @@ -0,0 +1,88 @@ +--- +title: 'Bitcoin Optech Newsletter #198' +permalink: /zh/newsletters/2022/05/04/ +name: 2022-05-04-newsletter-zh +slug: 2022-05-04-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的 Newsletter 概述了关于实现 MuSig2 的一篇帖子，传达了对部分旧版 LN 实现影响的安全问题的负责任披露，讨论了通过交易信号来衡量对共识变更支持度的提案，并考察了速率限制对更高带宽效率的 LN gossip 的影响。文末照例总结了新的软件发布与候选发布，以及值得注意的比特币基础设施项目变更。 + +## 新闻 + +- ******MuSig2 实现说明：** Olaoluwa Osuntokun 在 [MuSig2][topic musig] 草案 BIP（见 [Newsletter #195][news195 musig2]）下[回复][osuntokun musig2]了他与他人在 btcd 与 LND 中实现 MuSig2 时得到的经验： + + - *****与 BIP86 的交互：* 由 [BIP32 HD 钱包][topic bip32]且实现了 [BIP86][] 的密钥，遵循 [BIP341][] 的建议，通过对自身哈希进行微调来创建仅限密钥路径的密钥。这样可以防止该密钥被用于[多签][topic multisignature]，从而阻止参与者暗中嵌入自己控制的脚本路径支出选项并窃取全部资金。然而，如果多签参与者确实希望包含脚本路径支出选项，他们需要彼此共享未微调版本的密钥。 + + Osuntokun 建议 BIP86 的实现同时返回原始密钥（内部密钥）和微调后的密钥（输出密钥），以便调用函数根据上下文选择合适的密钥。 + + - *****与脚本路径支出的交互：* 用于脚本路径支出的密钥有类似问题：要使用脚本路径，支出者必须知道内部密钥。因此实现应返回内部密钥，以便其他需要它的代码可以调用。 + + - *****最终签名者的快捷方式：* Osuntokun 还请求澄清 BIP 中的一段描述：只有最终签名者可以使用确定性随机数或质量较低的随机源来生成其签名随机值。Brandon Black [回复][black musig2]解释了该段落的动机——他们有一个签名者难以安全地管理常规 MuSig2 会话，但可以始终被用作最终签名者。 + +- ******衡量用户对共识变更支持度：** Keagan McClelland 在 Bitcoin-Dev 邮件列表[发帖][mcclelland measure]，提出与[之前的提案][bishop signal]类似的方案，旨在让交易通过信号表示其是否[支持][topic soft fork activation]某项共识规则变更。邮件线程中还讨论了若干相关的情感测量思路，但都存在问题，例如[技术上的挑战][aronesty signal parse scripts]、显著[降低][grant signal chainalysis]用户隐私、[偏向][tetrud signal favor]比特币经济的某些部分，或是使先投票者[处于不利地位][ivgi signal hodl voting]。 + + 与以往讨论该主题时一样，参与者普遍认为目前尚无足够能被大多数人接受的方法，来为改变比特币共识规则提供有效参考。 + +- ******LN 锚定输出安全问题：** Bastien Teinturier 在 Lightning-Dev 邮件列表[发布][teinturier security]了一则其此前已向 LN 实现维护者负责任披露的安全公告。该问题影响旧版 Core Lightning（开启实验特性时）和 LND。仍在使用 Teinturier 帖子中提到版本的用户强烈建议立即升级。 + + 在引入[锚定输出][topic anchor outputs]之前，被撤销的 [HTLC][topic HTLC] 交易仅包含一个输出，因此大多数实现只尝试领取那一个输出。LN 的锚定输出新设计允许将多个已撤销的 HTLC 输出合并到一笔交易中，但前提是实现必须领取该交易中的所有相关输出。若在 HTLC 的时间锁到期前未能领取全部输出，广播被撤销 HTLC 的一方可窃取剩余资金。Teinturier 在为 Eclair 实现锚定输出时测试了其他 LN 实现并发现了此漏洞。 + + 与之前一项锚定输出相关攻击（见 [Newsletter #115][news115 fee stealing]）类似，问题似乎与在保留对 `SIGHASH_ALL` 的兼容支持的同时，新增 `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` 签名方式有关。 + +- ******LN gossip 速率限制：** Alex Myers 在 Lightning-Dev 邮件列表[发帖][myers recon]，介绍了他使用 [minisketch][topic minisketch] 集合对账来减少节点获取 LN 通道图更新时带宽消耗的研究。其方法假设所有节点对几乎全部公共通道拥有几乎相同的信息。某节点可从其完整的公共网络图生成一个 minisketch 并发送给所有对等方，对等方可用此 minisketch 找到自上次对账以来的网络更新。这与 [erlay][topic erlay] 协议在比特币 P2P 网络中仅发送最近几秒钟内（新的未确认交易）更新的拟议用法不同。 + + 在所有公共通道上进行对账的挑战在于要求所有 LN 节点拥有相同信息。任何会导致节点之间通道图长期不一致的过滤，都会造成带宽开销或协议失败。Matt Corallo [建议][corallo recon]可以将 erlay 模式应用到 LN——若仅同步新信息，就无需担心持久差异，尽管过滤规则差异过大仍可能导致带宽浪费或对账失败。Myers 担心仅发送更新需要维护大量状态——Bitcoin Core 节点需为每个对等方维护独立状态以避免重复发送更新。而在全部通道上对账可以免除逐节点状态，大幅简化 gossip 管理实现。 + + 截至本文撰写时，关于这些方案权衡的讨论仍在继续。 + +## 发布与候选发布 + +*面向热门比特币基础设施项目的新发布与候选发布。请考虑升级到新版本，或帮助测试候选版本。* + +- ****[BTCPay Server 1.5.1][] 发布，这是一款流行的自托管支付处理软件的新版本，新增主页仪表盘、新的 [transfer processors][btcpay server #3476] 功能，并支持自动批准拉取付款和退款。 + +- ****[BDK 0.18.0][] 发布，这是该钱包库的新版本，包含其依赖 rust-miniscript 的[关键安全修复][minimalif bug]，并带来若干改进和小幅错误修复。 + +## 值得注意的代码与文档变更 + +*本周在 [Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]上值得注意的变更。* + +- [Bitcoin Core #18554][] 默认阻止同一 Bitcoin Core 钱包文件被用于多个完全独立的区块链。当 Bitcoin Core 在扫描新区块以查找其钱包相关交易时，会在钱包中记录该区块头的哈希。此 PR 检查最近一次记录的扫描区块是否与当前使用的区块链具有相同的[创世区块][genesis block]。若否，则返回错误，除非设置了新的 `-walletcrosschain` 配置选项。该变更可防止专用于某网络（例如 mainnet）的钱包被用于另一网络（如 testnet），从而降低意外资金损失或隐私泄露风险。此变更仅影响 Bitcoin Core 内部钱包的用户，其他比特币钱包软件不受影响。 + +- [Bitcoin Core #24322][] 是将共识引擎抽离为独立库的更大工作的一部分。此 PR 新增了 `libbitcoinkernel` 库，列出了 `bitcoin-chainstate` 可执行文件（首次出现在 [Bitcoin Core #24304][] 中）需要链接的所有源文件。其中包括一些乍看与共识无关的文件，揭示了当前 Bitcoin Core 共识引擎的依赖关系。后续工作将继续把共识逻辑模块化，并逐步将这些文件移出 `libbitcoinkernel`。 + +- [Bitcoin Core #21726][] 允许即便在修剪模式下也能维护 coinstats 索引。Coinstats 在每个区块记录 UTXO 状态的 MuHash 摘要，从而可验证 [assumeUTXO][topic assumeutxo] 状态。此前该功能仅保证在存储完整区块链的归档全节点可用。此合并的 PR 使启用 `-coinstatsindex` 配置选项的修剪全节点也能提供该信息。 + +- [BDK #557][] 新增 “最旧优先” 找零选择算法。目前共有四种算法：Branch and Bound（BnB）、Single Random Draw（SRD）、最旧优先和最大优先。默认情况下 BDK 先使用 BnB，若无解则回退到 SRD。 + +- [LDK #1425][] 增加对[大额通道][topic large channels]（“wumbo 通道”）的支持，可用于高价值支付。 + +- [LND #6064][] 新增 `bitcoind.config` 与 `bitcoind.rpccookie` 配置选项，用于指定非默认的配置文件与 RPC cookie 路径。 + +- [LND #6361][] 更新 `signrpc` 方法，可使用 [MuSig2][topic musig] 算法创建签名。详细信息见该合并 PR 中的[文档][lnd6361 doc]。请注意，MuSig2 支持仍属实验性质，若 MuSig2 拟议 BIP 有重大调整（见 [Newsletter #195][news195 musig2]），实现也可能随之变更。 + +- [BOLTs #981][] 从规范中移除了对 LN 网络图查询及结果进行压缩的能力。由于压缩功能几乎未被使用，移除它可降低 LN 实现的复杂度和依赖数量。 + + +{% include references.md %} +{% include linkers/issues.md v=2 issues="18554,24322,21726,6064,557,981,6361,1425,3476,24304" %} +[tetrud signal favor]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020350.html +[ivgi signal hodl voting]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020364.html +[aronesty signal parse scripts]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020354.html +[grant signal chainalysis]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020355.html +[bishop signal]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020346.html +[news115 fee stealing]: /zh/newsletters/2020/09/16/#stealing-onchain-fees-from-ln-htlcs +[osuntokun musig2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020361.html +[news195 musig2]: /zh/newsletters/2022/04/13/#musig2-proposed-bip +[black musig2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020371.html +[mcclelland measure]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020344.html +[teinturier security]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003561.html +[myers recon]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003551.html +[corallo recon]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003556.html +[genesis block]: https://en.bitcoin.it/wiki/Genesis_block +[btcpay server 1.5.1]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.5.1 +[minimalif bug]: https://bitcoindevkit.org/blog/miniscript-vulnerability/ +[bdk 0.18.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.18.0 +[lnd6361 doc]: https://github.com/guggero/lnd/blob/93e069f3bd4cdb2198a0ff158b6f8f43a649e476/docs/musig2.md From 1db7bebc7c4002666ddb2d35e0b38d4ea64619f9 Mon Sep 17 00:00:00 2001 From: BitTom Date: Tue, 17 Jun 2025 18:16:42 +0800 Subject: [PATCH 106/278] Newsletter-199: translate into Chinese (#2375) --- .../zh/newsletters/2022-05-11-newsletter.md | 51 +++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 _posts/zh/newsletters/2022-05-11-newsletter.md diff --git a/_posts/zh/newsletters/2022-05-11-newsletter.md b/_posts/zh/newsletters/2022-05-11-newsletter.md new file mode 100644 index 0000000000..b35b0f49bd --- /dev/null +++ b/_posts/zh/newsletters/2022-05-11-newsletter.md @@ -0,0 +1,51 @@ +--- +title: 'Bitcoin Optech Newsletter #199' +permalink: /zh/newsletters/2022/05/11/ +name: 2022-05-11-newsletter-zh +slug: 2022-05-11-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的简短 Newsletter 总结了一次 Bitcoin Core PR 审查俱乐部会议，并描述了 Rust Bitcoin 的一次更新。 + +## 新闻 + +本周没有重要新闻。我们之前已经报道的话题，包括 [OP_CHECKTEMPLATEVERIFY 操作码][topic op_checktemplateverify]和 [SIGHASH_ANYPREVOUT][topic sighash_anyprevout]，收到了更多评论——但大部分讨论要么是非技术性的，要么是关于一些我们认为对广大读者并不重要的细节。在本期 Newsletter 编辑期间，开发者邮件列表收到几篇有趣的帖子；我们将在下周详细介绍它们。 + +## Bitcoin Core PR 审查俱乐部 + +*本月专栏，我们总结了最近一次 [Bitcoin Core PR 审查俱乐部][Bitcoin Core PR Review Club] 的会议，突出一些重要问题与解答。点击下面的问题可查看会议回答摘要。* + +[通过修剪阻挡器改进裁剪节点上的索引][review club pr] 是 Fabian Jahr 提交的一个 PR，引入了一种新的方法来决定何时可以安全地从区块存储中裁剪区块。该新方法使得裁剪节点能够维护 Coinstats 索引，并移除了验证模块对索引相关代码的依赖。 + +{% include functions/details-list.md + + q0="Bitcoin Core 目前有哪些索引，它们各自的作用是什么？" + a0="一个节点最多可以维护三种可选索引，以帮助高效地从磁盘检索数据。交易索引（`-txindex`）将交易哈希映射到包含该交易的区块。区块过滤器索引（`-blockfilterindex`）为每个区块索引 BIP157 区块过滤器。Coinstats 索引（`-coinstatsindex`）存储 UTXO 集的统计信息。" + a0link="https://bitcoincore.reviews/21726#l-28" + + q1="什么是循环依赖？为什么我们要尽量避免循环依赖？" + a1="当两个代码模块彼此都离不开对方才能工作时，就存在循环依赖。循环依赖本身不是安全问题，但它意味着代码组织不良，并通过增加单独构建、使用和测试特定模块或功能的难度来阻碍开发。" + a1link="https://bitcoincore.reviews/21726#l-44" + + q2="在 [此提交][review club commit]中引入的修剪阻挡器是如何工作的？" + a2="该 PR 引入了一张“修剪锁”列表，为每个索引记录必须保留的最早区块高度。在 `CChainState::FlushStateToDisk` 中，当节点决定要裁剪哪些区块时，它会避免裁剪高度高于这些值的区块。每当某个索引更新其已知的最佳区块高度时，相应的修剪锁也会被更新。" + a2link="https://bitcoincore.reviews/21726#l-68" + + q3="与旧方法相比，这种修剪方式的优缺点是什么？" + a3="此前，`CChainState::FlushStateToDisk` 中的逻辑会向索引查询其最佳高度，以确定停止裁剪的区块位置；因此索引与验证逻辑相互依赖。现在，修剪锁被主动计算，可能计算得更频繁，但验证过程不再需要查询索引。" + a3link="https://bitcoincore.reviews/21726#l-92" +%} + +## Notable code and documentation changes + +*本周 [Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]的值得注意的代码和文档更改。* + +- [Rust Bitcoin #716][Rust Bitcoin #716] 新增了 `amount::Display`，一种可配置的显示类型，用于面向用户的金额或其他数值表达。该补丁默认将所有数字表示压缩到最小宽度，从而减少多余的零，这些多余的零会让 [BIP21][BIP21] URI 不必要地变长，常常导致二维码尺寸更大或更难扫描。 + + +{% include references.md %} +{% include linkers/issues.md v=2 issues="716" %} +[review club commit]: https://github.com/bitcoin-core-review-club/bitcoin/commit/527ef4463b23ab8c80b8502cd833d64245c5cfc4 +[review club pr]: https://bitcoincore.reviews/21726 From 184089d427dfe8a2e8056bf67600940f2fb988a9 Mon Sep 17 00:00:00 2001 From: BitTom Date: Tue, 17 Jun 2025 18:27:38 +0800 Subject: [PATCH 107/278] Newsletter-200: translate into Chinese (#2376) --- .../zh/newsletters/2022-05-18-newsletter.md | 434 ++++++++++++++++++ 1 file changed, 434 insertions(+) create mode 100644 _posts/zh/newsletters/2022-05-18-newsletter.md diff --git a/_posts/zh/newsletters/2022-05-18-newsletter.md b/_posts/zh/newsletters/2022-05-18-newsletter.md new file mode 100644 index 0000000000..2d2982f4de --- /dev/null +++ b/_posts/zh/newsletters/2022-05-18-newsletter.md @@ -0,0 +1,434 @@ +--- +title: 'Bitcoin Optech Newsletter #200' +permalink: /zh/newsletters/2022/05/18/ +name: 2022-05-18-newsletter-zh +slug: 2022-05-18-newsletter-zh +type: newsletter +layout: newsletter +lang: zh + +praise: + - url: https://twitter.com/jonatack/status/1379839115676561408 + author: Jon Atack + title: Bitcoin Developer + text: "@bitcoinoptech topics are a good first place to start" + + - url: https://twitter.com/stephanlivera/status/1342674949392093186 + author: Stephan Livera + title: Managing Director at Swan Bitcoin and Podcaster + # alternative: @bitcoinoptech newsletter is must subscribe / https://twitter.com/stephanlivera/status/1199520746252296192 + text: "Great and perhaps less well known resource for people learning more about Bitcoin tech: [the] @bitcoinoptech topics pages: https://bitcoinops.org/en/topics/" + + - url: https://twitter.com/lopp/status/1342123233210998784 + author: Jameson Lopp + title: Co-founder and CTO at Casa + text: | + Ignoramus: "Bitcoin stopped innovating; development is stalled!" + + Me: "@bitcoinoptech's annual high level review of developments + won't even fully render in my email client because it's too long." + + - url: https://twitter.com/jlppfeffer/status/1324761477694267393 + author: John Pfeffer + title: Entrepreneur and investor + text: "Immense admiration for the talented and passionate developers dedicated to building #bitcoin. It’s a privilege to support @meshcollider, Antoine Riard, @bitcoinoptech, @mitDCI, dev training...and more to come soon! Please join me in supporting #btc development!" + + - url: https://twitter.com/haegwankim/status/1314503620910436353 + author: Haegwan Kim + text: | + P.S. I want to appreciate developers, educators, and miners who run and improve the network every day. + + Folks at @lightning, @ChaincodeLabs, @CryptoGarageInc , + @Blockstream, @bitcoinoptech, and many many contributors + are doing amazing things. + + I really thank you all. + + - url: https://twitter.com/TheGuySwann/status/1302029639112691719 + author: Guy Swann + title: Host of Bitcoin Audible + text: | + Just wanted to say a thanks to the @bitcoinoptech team for their newsletter. + + It saves me a TON of time going through chats and emails to just hit the main developments & easily dig deeper into anything particularly relevant or interesting.✊ + + - url: https://twitter.com/HillebrandMax/status/1299315892543725568 + author: Max Hillebrand + title: Free Software Entrepreneur + text: | + Wow - @bitcoinoptech has 25+ contributors!! + + The highest quality of #Bitcoin news - peer reviewed by high caliber free software contributors! + + Thanks to all the supporters. 🔥🚀 + + - url: https://twitter.com/flip_abagnale/status/1298094514159181824 + author: Flip Abagnale + text: | + We [at Bitcoin Magazine] do our best to distill the hard stuff, + but @bitcoinoptech is pretty hard to beat if you’re looking for + the raw goods. + + It’s my favorite non-BM content by far and one of the few + newsletters that stay in my inbox until I can actually spend + proper time on it. + + - url: https://twitter.com/softsimon_/status/1296739713286459398 + author: "@softsimon" + title: Creator of Mempool.Space + text: 'Bitcoin Optech @bitcoinoptech has a great overview of what is being worked on currently in Bitcoin. It really shows how much that is actually happening in the Bitcoin space and kills the notion that Bitcoin is "stale old tech". https://bitcoinops.org/en/topic-dates/' + + - url: https://twitter.com/veriphibtc/status/1293602911910600707 + author: Veriphi + text: "Our whole team is honored to be included in the most respected and advanced technical #bitcoin newsletter that is @bitcoinoptech" + + - url: https://twitter.com/river/status/1268624838161305601 + author: River Financial + text: "The @bitcoinoptech newsletter presents cutting-edge developments and updates in #Bitcoin each week." + + - url: https://twitter.com/Bitcoin/status/1268171489011998720 + author: "@Bitcoin" + text: "The 100th issue of @bitcoinoptech was just published. [...] It's one of the best technical newsletters in Bitcoin." + + - url: https://twitter.com/kallerosenbaum/status/1429793328623755265 + author: Kalle Rosenbaum + title: Author of Grokking Bitcoin + text: "This writeup by [...] @bitcoinoptech explains why nonce reuse in a multisig setup is bad and also the challenges in avoiding it. It really helped me understand the issue better. Thanks!" + + - url: https://twitter.com/michaelfolkson/status/1254733781233209344 + author: Michael Folkson + text: "I'm assuming everyone knows about the excellent @bitcoinoptech newsletter by now. But did you know it has a topics page indexed by topic name, event and part of Bitcoin system it impacts? https://bitcoinops.org/en/topic-categories/" + + - url: https://twitter.com/BitcoinMagazine/status/1229834232861724672 + author: Bitcoin Magazine + text: "Bitcoin Optech (@bitcoinoptech) was founded in 2018 to bridge the worlds of open-source development and companies. They have come a long way since inception." + + - url: https://twitter.com/AlyseKilleen/status/1138921268185407489 + author: Alyse Killeen + title: Founding Partner, Stillmark + text: "While the consumer market grows and infrastructure advances, work to catalyze enterprise adoption of (a) protocol upgrades and (b) the techniques that allow service providers to operate more efficiently and better serve the growing market, is underway via @bitcoinoptech" + + - url: https://twitter.com/aantonop/status/1133785460650721280 + author: Andreas M. Antonopoulos + title: Author of *Mastering Bitcoin* and co-author of *Mastering the Lightning Network* + text: "The Bitcoin Optech (@bitcoinoptech) newsletter continues to deliver interesting and detailed content. I just read the [latest] one and it was great." + + - url: https://twitter.com/renepickhardt/status/1120702153985875973 + author: Rene Pickhardt + title: Bitcoin and Lightning Network Developer + text: "Once again I enjoyed @bitcoinoptech newsletter [...] This is the most informative and best resource and overview for developers and educators." + + - url: https://twitter.com/Leishman/status/1082288630297751552 + author: Alexander Leishman + title: Founder, River Financial + text: "I'd also highly recommend @bitcoinoptech :)" + + - url: https://twitter.com/SDWouters/status/1082930342053462016 + author: Sam Wouters + title: Bitcoin Educator + text: "A great example of why Game Theory is so important, in the latest edition of @bitcoinoptech" + + - url: https://twitter.com/BuckPerley/status/1078791035864707079 + author: Buck Perley + title: Engineer at Unchained Capital + text: "Incredible roundup of all the major developments in Bitcoin and Lightning during 2018 from the excellent @bitcoinoptech newsletter. Month by month walk through with links. Makes for a nice weekend reading list!" + + - url: https://twitter.com/zackvoell/status/1064937176922841091 + author: Zack Voell + text: "Really, @bitcoinoptech is essential reading material for every bitcoiner." + + - url: https://twitter.com/RobertSpigler/status/1058780917685239810 + author: Robert Spigler + title: OpSec consultant + text: "@bitcoinoptech is an incredibly valuable community project and the greater the percentage of the wider ecosystem that is involved and learning best practices, the better" + + - url: https://twitter.com/carl_dong/status/1057721562449633280 + author: Carl Dong + title: Bitcoin Core developer at Chaincode Labs + text: "I think efforts like @bitcoinoptech are improving communication, but we need more!" + + - url: https://twitter.com/LucasNuzzi/status/1228417230989340673 + author: Lucas Nuzzi + title: Head of R&D at CoinMetrics.io + text: | + Don't you love finding amazing educational resources out of nowhere? + + My #1 project this weekend will be @bitcoinoptech's workshop on taproot, which I only recently discovered. + + - url: https://twitter.com/pwuille/status/1220507061026344960 + author: Pieter Wuille + title: Bitcoin Developer at Chaincode Labs + text: "Thanks to everyone who helped us get here: co-authors @ajtowns, @n1ckler, and @real_or_random, everyone who contributed to the document, the participants in the @bitcoinoptech workshops and structured review, Greg Maxwell for the original idea, and many others." + + - url: https://twitter.com/_JustinMoon_/status/1219347584789176325 + author: Justin Moon + text: "@bitcoinoptech wrote a very nice year-in-review newsletter" + + - url: https://twitter.com/lightcoin/status/1218260416171847680 + author: John Light + title: Human Rights Foundation ZK-Rollup Research Fellow + text: "one of the few newsletters I read every issue of, consistently. thanks @bitcoinoptech" + + - url: https://twitter.com/jmcorgan/status/1217480526006644736 + author: Johnathan Corgan + text: "Giving a shout out to Bitcoin Optech, who (among other things) chronicle technical development in Bitcoin. No hype, no drama, just great information about advances in using and deploying Bitcoin. @bitcoinoptech" + + - url: https://twitter.com/LeahWald/status/1215464602214883329 + author: Leah Wald + title: CEO at Valkyrie Investments + text: "Important piece by @bitcoinoptech summarizing & cataloging notable coding developments" + + - url: https://twitter.com/Excellion/status/1211075163732631553 + author: Samson Mow + title: CEO of Jan3 + text: "Nice write up @bitcoinoptech. 👍" + + - url: https://twitter.com/hfangca/status/1211002573282394112 + author: Hong Fang + title: CEO of OKCoin + text: "Great summary for the year 👍 @bitcoinoptech" + + - url: https://twitter.com/SamouraiWallet/status/1163877643932065793 + author: Samourai Wallet + text: "Great work to the @bitcoinoptech team on a comprehensive job well done with the compatibility matrix." + + - url: https://twitter.com/moneyball/status/1522260482538627077 + author: Steve Lee + title: Lead at Spiral + text: "@bitcoinoptech had a nice writeup of LDK's approach in February https://bitcoinops.org/en/newsletters/2022/02/23/#ldk-1199" + + - url: https://twitter.com/SomsenRuben/status/1511679367688200193 + author: Ruben Somsen + title: Bitcoin Sorcerer and co-host of The Unhashed Podcast + text: "As always, @bitcoinoptech provides an expertly crafted summary [...]" + + - url: https://twitter.com/theinstagibbs/status/1511413286167851014 + author: Gregory Sanders + title: Bitcoin Developer + text: "@bitcoinoptech is a great resource" + + - url: https://twitter.com/SahilC0/status/1501703542393946115 + author: Sahil Chaturvedi + title: Product Designer at Unchained Capital + text: "trying to read less twitter and more @bitcoinoptech" + + - url: https://twitter.com/gckaloudis/status/1476196134745948169 + author: George Kaloudis + title: Research Analyst for CoinDesk + text: "@bitcoinoptech is honestly amazing" + + - url: https://twitter.com/TYonClubhouse/status/1473793982408716289 + author: Terrence Yang + text: "Thank you @bitcoinoptech, one of the best organizations in Bitcoin, focused on helping the rest of us use Bitcoin and be better Bitcoiners!" + + - url: https://twitter.com/actuallyCarlaKC/status/1473660532959985669 + author: Carla Kirk-Cohen + title: Independent LN Developer and Board Member at Brink, ₿trust, and Qala + text: "Get a head start on your New Years resolution to keep up with the wonderful world of Bitcoin development by reading @bitcoinoptech’s 2021 year in review 🌟" + + - url: https://twitter.com/CardCoinsCo/status/1468783314404261894 + author: CardCoins + text: "Another great newsletter. Thanks @bitcoinoptech !" + + - url: https://twitter.com/realtbast/status/1468553191243591683 + author: Bastien Teinturier + title: VP of Engineering at ACINQ + text: "As always, thanks for this newsletter!" + + - url: https://twitter.com/ChartsBtc/status/1466071392449818629 + author: "@ChartsBTC" + text: | + Follow @bitcoinoptech and subscribe to the free newsletter for true signal. I don't understand all of it, but it keeps me bullish regardless of what the market is doing. + + - url: https://twitter.com/satsie/status/1458436050091745286 + author: Stacie Waleyko + title: Engineering at Casa + text: "The taproot series has been an invaluable resource for understanding not only the big picture, but also the technical details. Ty to everyone that contributed to this!" + + - url: https://twitter.com/remyers_/status/1455955655651729415 + author: Richard Myers + text: "I recommend the video series from @bitcoinoptech for understanding Taproot, in particular the interactive colab notebook from @digi_james is very helpful for understanding how to use tapscript." + + - url: https://twitter.com/nvk/status/1455681554047545352 + author: Rodolfo Novak + title: "CEO and Co-Founder of Coinkite" + text: | + Follow @bitcoinoptech and sign up for their news letter, 5-9 signal. + + Very few sources of bitcoin technical information are this well summarized and explained. + + Do it now, so that you don’t forget 😉 + + - url: https://twitter.com/Kristian_Kho/status/1452201573799632896 + author: Kristian Kho + text: | + There’s plenty of newsletters around crypto stuff to keep you up to date. + + One of the ones I’ve religiously followed has been @bitcoinoptech. + + highly recommended if you hold some btc and wants to see real work being done to make the protocol better. + + - url: https://twitter.com/ElleMouton/status/1418108253096095745 + author: Elle Mouton + title: Engineer, Lightning Labs + text: | + A bit behind on Taproot? There is still time and luckily for you + @bitcoinoptech has a GREAT workshop that will bring you up to + speed: https://github.com/bitcoinops/taproot-workshop/ + + Can highly recommend. It goes through all the building blocks + you need. Go do iiiiiiiit 💪 #Bitcoin #taproot + + - url: https://twitter.com/Empact/status/1403702689737871362 + author: Ben Woosley + title: Bitcoin Core Developer and Senior Developer at Unchained Capital + text: "@bitcoinoptech does a good job explaining the tech to a technical integrators audience, I would watch their workshop" + + - url: https://twitter.com/RajarshiMaitra/status/1398931136714182656 + author: Rajarshi Maitra + text: "[...] it's almost a full time job trying to summarise what's happening everywhere. That's what guys at @bitcoinoptech does, so just following their news letters will give good enough understandings." + +--- +本周 Newsletter 总结了关于在 Bitcoin 的 Script 语言中加入最小改动以启用递归契约的讨论，考察了经修订的 `OP_TX` 操作码提案，并回顾了将输出脚本描述符适配到硬件签名设备的研究。此外，我们照例提供了服务和客户端软件的最新变更、发布与候选发布，以及流行 Bitcoin 基础设施软件的值得注意的代码与文档更新。 +另外，我们共同庆祝 Optech 发布第 200 期常规 Newsletter。 + +## 新闻 + +- ******启用 `OP_CAT` 何时会允许递归契约？** + 在 Bitcoin-Dev 邮件列表关于重新加入 2010 年被移除的 [OP_CAT][op_cat] 操作码的讨论中，开发者 ZmnSCPxj [声称][zmnscpxj cat1]，只有当 `OP_CAT` 与提议中的 `OP_TX`（见 [Newsletter #187][news187 op_tx]）、[OP_CHECKSIGFROMSTACK][topic op_checksigfromstack]（CSFS）或类似功能结合使用时，才能实现不可逃避的递归[契约][topic covenants]——即使用 Bitcoin 共识规则保证合同收到的所有比特币只能再次支付给同一合同。 + + 递归契约依赖于被称为 *交易内省* 的技术，即操作码可以分析执行该操作码的交易的部分内容。现有操作码 `OP_CHECKSIG`、[BIP65][] `OP_CHECKLOCKTIMEVERIFY` 和 [BIP112][] `OP_CHECKSEQUENCEVERIFY` 提供有限的内省能力。提议中的 TX 和 CSFS 操作码则可以灵活地内省交易的所有部分，包括下一输出（支付金额和地址）以及 *prevout*（上一输出，已接收金额和当前用于授权支出的脚本）。 + + 如果某个操作码或其他脚本特性被用来确保 prevout 与下一输出完全相同，就可以创建最简单的递归契约。然而，prevout 并不是交易的直接组成部分——它必须从区块链中获取——因此需要在交易中包含 prevout 的副本以便与下一输出进行比较。进一步地，在 Bitcoin 交易的多个部分使用哈希函数似乎阻止了 prevout 脚本直接与下一输出脚本比较；因此，需要从组成元素动态构造 prevout、下一输出或二者——这就是为什么提议的连接操作码（CAT）或类似结构对于递归契约是必要的。 + + 在 [taproot][topic taproot] 出现之前，在交易中包含 prevout 副本的最高效方式通常是将其作为类似数字签名的授权数据提供。如果 prevout 的副本与签名一起提供，就可以通过对交易见证进行内省来检查它，这需要像 TX 或 CSFS 这样的灵活内省机制。提议中的 CTV 与 APO 脚本变更也允许内省下一输出，但它们几乎不能内省见证，因此看起来即便与 CAT 结合也无法创建递归契约。 + + Nadav Ivgi [回复][ivgi cat]称，也可以把构造 prevout 所需的信息副本直接放入 prevout 本身（即在它还是下一输出时就加入该信息）。在创建递归契约时，这仍然需要 CAT 来绕过哈希问题，但这意味着以输出内省为重点的 CTV 与 APO 与 CAT 结合后同样能够创建递归契约。结合 taproot 的特性，Ivgi 还认为通过下一输出验证 prevout 会让契约脚本更易编写，并提供了两个有趣的递归契约示例链接。 + + ZmnSCPxj [同意][zmnscpxj cat2] Ivgi 的分析，并再次表达了他对在 Bitcoin 上启用递归契约风险的担忧（见 [Newsletter #190][news190 recurse]），不过他也在[随后帖子][zmnscpxj cat3]中指出，“【仅供参考】递归契约或许是安全的，因为它们实际上并非[图灵完备][Turing-complete]”。 + + Russell O'Connor 还[引用][oconnor cat]了 Andrew Poelstra 的一篇[帖子][poelstra cat]（见 [Newsletter #134][news134 cat]），其中描述了仅凭 CAT 与已有 Bitcoin 特性即可创建非递归契约的强大能力——并且在理论上，如果 CAT 被重新加入 Bitcoin，也可能仅凭它自身创建递归契约。 + + 以上讨论均围绕对 Bitcoin 的新增提案展开，因此对当前已部署的 Bitcoin 系统状态没有任何影响。 + +- ******OP_TX 提案更新：** + 如 [Newsletter #187][news187 op_tx] 所述，Rusty Russell 提出了 `OP_TX` 操作码（基于先前的提案），允许 [tapscript][topic tapscript] 将执行该脚本的交易的选定部分压栈。例如，Alice 可以将比特币接收至包含 `OP_TX(SELECT_LOCKTIME)` 的脚本，以把支出交易的 locktime 压栈。借助 TX 的通用交易内省功能，Alice 可以复现 `OP_CHECKLOCKTIMEVERIFY`（CLTV）的专用内省能力，例如 `OP_TX(SELECT_LOCKTIME) OP_GREATERTHAN OP_VERIFY`。 + + 在上述示例中使用 CLTV 所占 vbyte 少于使用 TX，但 TX 的灵活性可用于检查 Bitcoin 目前无法内省的交易其他部分。TX 还可能内省交易之外、但完整节点在验证交易时需要的数据。按最初提案，TX 被[标记][rubin op_tx recursive]为可启用递归契约，而递归契约目前似乎存在争议（见 [Newsletter #190][news190 recov]）。 + + 本周，Russell [提出][russell op_tx] 了受限版本的 TX，仅允许访问 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]（CTV）所使用的字段，且仅采用 CTV 所消耗的同一哈希摘要格式。[BIP119][] CTV 专门设计为无法与任何现有 Script 特性组合创建递归契约，因此受限 TX 应提供同等功能且同样不会启用递归契约。 + + 此外，受限 TX 设计为未来软分叉可轻松扩展其内省功能，包括在有共识时可选启用递归契约的特性。截至撰写时，已有两位开发者建议通过稍作扩展来使用 TX： + + - *****改进的保险库原语：* + Russell 的提案建议扩展，以便将交易每个输出的 satoshi 数量压栈。Brandon Black [建议][black op_tx]再包括每个 prevout（输入）金额，这将简化创建[保险库][topic vaults]。Black 特别提议复制数月前 `OP_TAPLEAF_UPDATE_VERIFY`（TLUV）提案中的 `OP_IN_OUT_AMOUNT` 操作码能力（见 [Newsletter #166][news166 tluv]）。 + + - *****利用交易内省防止 RBF（RBF）固定攻击：* + Gregory Sanders [指出][sanders op_tx]，基于 [SIGHASH_ANYPREVOUT][topic sighash_anyprevout] 操作码的 [Eltoo][topic eltoo] 层可能因与 [BIP125][] 规则 #3 交互而易受[交易固定][topic transaction pinning]攻击（见 [Newsletter #27][news27 eltoo]）。Sanders 建议让 TX 能够将交易权重（大小）压栈，参与者即可对 eltoo 通道中的交易设定最大尺寸限制，消除依赖膨胀交易大小的一类固定攻击风险。这与 [Newsletter #191][news191 pinning] 中提到的防止 CPFP（CPFP）固定的想法在概念上相似。 + +- ******为硬件签名设备适配 miniscript 与输出脚本描述符：** + Salvatore Ingala 在 Bitcoin-Dev 邮件列表[发布][ingala desc]了他为硬件签名设备实现[输出脚本描述符][topic descriptors]（描述符）与 [miniscript][topic miniscript] 的工作。他指出，签名设备尤其关注策略验证——用户需要了解批准交易后会发生什么，但又不应被提示过多无关信息，以确保资金安全。由于许多签名设备的屏幕尺寸较小且验证信息困难，如何尽可能紧凑地显示信息也很重要。Ingala 提出若干针对描述符的改进建议来解决这些问题： + + - *****策略注册：* + 在设置签名设备时，用户应使用设备验证其首选策略。对于具有持久存储的设备，应将已注册策略保存至设备；对于无存储的设备，设备应返回加密安全的注册证明，使得每次启动设备时可快速重新加载该证明和策略。提案未详细说明策略应如何在设备上注册，但引用了 [BIP129][] 安全多签设置（见 [Newsletter #136][news136 sms]）。 + + - *****密钥占位符：* + Ingala 建议允许策略定义简短占位符来替代在描述符中重复出现的 [BIP32][] 扩展密钥，在解释策略时再用 BIP32 信息替换占位符。这既能显著减小策略字节大小，也能提高人类可读性。Ingala 亦提出了描述符中常用字符串的数个简写。 + + - *****降低表达能力：* + 目前仅支持描述符的一个子集；如有需求，后续可添加其他功能。这有助于简化实现。 + + 截至目前，该提案已在邮件列表上获得一些讨论。 + +## 服务和客户端软件的更改 + +*本月特写：我们关注 Bitcoin 钱包与服务的有趣更新。* + +- ******MyCitadel Wallet 发布：** + [MyCitadel Wallet][] 是一款桌面 Bitcoin、闪电网络与 [RGB][] 钱包，支持多签、[PSBTs][topic psbt]、segwit、taproot、[timelocks][topic timelocks]、硬件签名设备、[描述符][topic descriptors]等功能。 + +- ******Tauros 交易所支持闪电网络：** + 墨西哥交易所 [Tauros][] 宣布已支持闪电网络充值与提现。 + +- ******Lightning Multiplexer 发布：** + 支持 LND 的 Lightning Multiplexer（[lnmux][]）软件通过在入站支付中允许故障转移场景提高闪电网络支付可靠性。更多详情见 [Bottlepay 博文][lnmux blog]。 + +- ******Coldcard 新增 taproot 转账：** + [最新 Coldcard 固件][coldcard upgrade]（Mk4 5.0.3，Mk3 4.1.5）已支持向 [bech32m][topic bech32] 地址发送。 + +## 发布与候选发布 + +*流行 Bitcoin 基础设施项目的新版本与候选发布。请考虑升级到新版本或协助测试候选发布。* + +- [LND 0.15.0-beta.rc1][]：此流行闪电网络节点的下一主版本候选发布。 + +## 值得注意的代码与文档变更 + +*本周在 [Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中的值得注意的变更。* + +- [Bitcoin Core #22235][]：新增脚本可直接从源代码中定义的配置选项生成示例 `bitcoin.conf` 文件。此改动使得未来 Bitcoin Core 发行版可以预装 bitcoin.conf 文件，而无需另行维护配置选项状态的“第二来源”。 + +- [LND #6450][]：新增对支出 [taproot][topic taproot] 输出的 [PSBTs][topic psbt] 签名支持。 + +- [LND #6345][]：允许 LND 通过反复轮询 Bitcoin Core 获取新交易与区块更新，而不是通过 ZMQ 接收推送更新。 + +- [BIPs #1309][]：更新了 [BIP119][] 的 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] 示例实现。此前示例包含用 C++ 编写的 Bitcoin Core 操作码实现代码，新示例改为伪 Python，并补充了如何避免在简单实现中可能遭遇的拒绝服务攻击的额外信息，该问题此前已在 Bitcoin-Dev 邮件列表讨论（见 [Newsletter #183][news183 dos]）。 + +## 庆祝 Optech Newsletter #200 + +每当 Newsletter 累积至 50 期，我们都会花一点时间回顾 Optech 的主要成果。我们这样做，一方面是帮助读者了解我们提供的全部资源，另一方面也是吸引捐赠，以支持我们继续产出有用内容。当然，还有一点点原因是：自豪。 + +我们并非出于个人虚荣而自夸，而是因为 Optech 的每一位贡献者本身都是其他贡献者的忠实粉丝。与优秀的同事一起协作是一种美好体验，而这些特别的 Newsletter 章节正是我们得以公开表达彼此赞赏之处。 + +今年，我们决定换个方式。我们想给你们——读者——一个机会，让你们分享对 Optech 贡献者的欣赏。在没有进行任何征集的情况下，我们就在 Twitter 上找到了数十、甚至数百条暖心评价。精彩评论多到难以尽数刊登，因此我们仅选取过去四年中点赞数最高的 {{page.praise | size}} 条。 + +在下方可以看到这些评论。但首先，我们要感谢过去一年中的主要贡献者——Adam Jonas、Carl Dong、David A. Harding、Gloria Zhao、John Newbery、Mark Erhardt、Mike Schmidt 以及 Shigeyuki Azuchi——同时也感谢[众多支持者][supporters]，包括我们的[创始赞助人][founding sponsors] Wences Casares、John Pfeffer 和 Alex Morcos。 + +{% assign sorted_praise = page.praise | sort_natural: "author" %} +{% for comment in sorted_praise %} +
+ + {{comment.text | default: 'TODO'}} + +
+ + {:.right} + ---[{{comment.author | default: 'TODO'}}]({{comment.url | default: 'TODO'}}) + {% if comment.title %}
{{comment.title}}{% endif %}
+ +{% endfor %} + + +{% include references.md %} +{% include linkers/issues.md v=2 issues="22235,6450,6345,1309" %} +[lnd 0.15.0-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.15.0-beta.rc1 +[news27 eltoo]: /zh/newsletters/2018/12/28/#四月 +[news166 tluv]: /zh/newsletters/2021/09/15/#amount-introspection +[news190 recov]: /zh/newsletters/2022/03/09/#limiting-script-language-expressiveness +[rubin op_tx recursive]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019872.html +[minsc 1/3]: https://min.sc/#c=%24alice%20%3D%20A%3B%0A%24bob%20%3D%20B%3B%0A%24carol%20%3D%20C%3B%0A%0Apk%28%24alice%29%20%7C%7C%20pk%28%24bob%29%20%7C%7C%20pk%28%24carol%29 +[news136 sms]: /zh/newsletters/2021/02/17/#securely-setting-up-multisig-wallets +[news183 dos]: /zh/newsletters/2022/01/19/#mailing-list-discussion +[zmnscpxj cat1]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020434.html +[news187 op_tx]: /zh/newsletters/2022/02/16/#simplified-alternative-to-op-txhash +[ivgi cat]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020442.html +[zmnscpxj cat2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020441.html +[oconnor cat]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020467.html +[poelstra cat]: https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html +[news190 recurse]: /zh/newsletters/2022/03/09/#introduction-of-turing-completeness +[zmnscpxj cat3]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020462.html +[news134 cat]: /zh/newsletters/2021/02/03/#replicating-op-checksigfromstack-with-bip340-and-op-cat +[turing-complete]: https://en.wikipedia.org/wiki/Turing_completeness +[russell op_tx]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020450.html +[black op_tx]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020454.html +[sanders op_tx]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020458.html +[ingala desc]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020423.html +[supporters]: /#supporters +[founding sponsors]: /en/about/#founding-sponsors +[news191 pinning]: /zh/newsletters/2022/03/16/#ideas-for-improving-rbf-policy +[MyCitadel Wallet]: https://github.com/mycitadel/mycitadel-desktop +[RGB]: https://www.rgbfaq.com/what-is-rgb +[Tauros]: https://tauros.io/ +[lnmux]: https://github.com/bottlepay/lnmux +[lnmux blog]: https://bottlepay.com/blog/multiplexer/ +[coldcard upgrade]: https://coldcard.com/docs/upgrade From 64bc4ac5bc3e6a5b11a6b43c27ac93af1bc32101 Mon Sep 17 00:00:00 2001 From: BitTom Date: Tue, 17 Jun 2025 18:31:38 +0800 Subject: [PATCH 108/278] Newsletter-201: translate into Chinese (#2377) --- .../zh/newsletters/2022-05-25-newsletter.md | 107 ++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 _posts/zh/newsletters/2022-05-25-newsletter.md diff --git a/_posts/zh/newsletters/2022-05-25-newsletter.md b/_posts/zh/newsletters/2022-05-25-newsletter.md new file mode 100644 index 0000000000..4e19877fd6 --- /dev/null +++ b/_posts/zh/newsletters/2022-05-25-newsletter.md @@ -0,0 +1,107 @@ +--- +title: 'Bitcoin Optech Newsletter #201' +permalink: /zh/newsletters/2022/05/25/ +name: 2022-05-25-newsletter-zh +slug: 2022-05-25-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周 Newsletter 总结了一份关于包中继的 BIP 草案，并概述了在比特币契约设计中与矿工可提取价值（MEV）相关的担忧。我们照例还包括了 Bitcoin Stack Exchange 精选问答、最新发布与候选发布公告，以及流行比特币基础设施软件的值得注意的变更描述。 + +## 新闻 + +- ******包中继提案：** Gloria Zhao [发布][zhao package]了一份关于[包中继][topic package relay]的 BIP 草案。该特性能够显著提升 [CPFP（Child-Pays-For-Parent）][topic cpfp] 手段的可靠性，确保子交易能够为其父交易贡献手续费以获得确认。LN 等若干合约协议已经依赖可靠的 CPFP 手段，因而包中继将改善它们的安全性和可用性。该草案提议在比特币 P2P 协议中新增四条消息： + + - `sendpackages`：允许两个节点协商各自支持的包接受特性。 + - `getpckgtxns`：请求之前已作为包宣布的交易。 + - `pckgtxns`：发送属于某个包的交易。 + - `pckginfo1`：提供一个交易包的信息，包括交易数量、每笔交易的标识符（wtxid）、交易总体积（weight）以及总手续费。包的费率可通过手续费除以 weight 计算得到。 + + 此外，现有的 `inv` 与 `getdata` 消息被加入新的 inv 类型 `MSG_PCKG1`。节点可以用它告诉对端自己愿意发送某笔交易的 `pckginfo1`，对端随后可据此请求该交易的 `pckginfo1`。 + + 借助这些消息，节点可通过 `inv(MSG_PCKG1)` 告诉对端其可能希望接收某笔交易的 `pckginfo1`，例如该交易是低费率未确认父交易的高费率子交易，而对端原本可能忽视它。一旦对端请求 `pckginfo1`，即可利用其中的信息判断自己是否确实需要该包，并获知验证高费率子交易所需下载的 wtxid。随后，可使用 `getpckgtxns` 请求具体交易，并在 `pckgtxns` 消息中收到。 + + 虽然 [BIP 草案][bip-package-relay]仅聚焦协议本身，Zhao 的邮件提供了更多背景，简要描述了被认定为不足的替代设计，并链接到一份含更多细节的[演示文稿][zhao preso]。 + +- ******矿工可提取价值讨论：** 开发者 /dev/fd0 [发布][fd0 ctv9]了第九次关于 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]（CTV）的 IRC 会议摘要。在该会议讨论的若干主题中，Jeremy Rubin 列举了他听到的关于递归[契约][topic covenants]（CTV 本身并不启用递归契约）的一些担忧。其中之一是递归契约可能会产生远超简单交易选择算法（如 Bitcoin Core 所实现）的 Miner Extractable Value（MEV）。 + + 在使用公开链上交易协议的以太坊及相关协议中，MEV 已成为一个突出问题——矿工可以抢先执行交易。例如，假设下一区块中有如下两笔未确认交易： + + * Alice 以 1 ETH 的价格将资产 *x* 卖给 Bob + * Bob 以 2 ETH 的价格将 *x* 卖给 Carol（Bob 获利 1 ETH） + +
如果这两笔交换通过公开链上协议完成，矿工就能绕过 Bob，示例如下： + + * Alice 以 1 ETH 的价格将资产 *x* 卖给矿工 Mallory + * 矿工 Mallory 以 2 ETH 的价格将 *x* 卖给 Carol（Mallory 获利 1 ETH，Bob 一无所获） + +
这不仅损害了 Bob，也给网络带来多重问题。首先，矿工需要寻找 MEV 机会。简单示例易于发现，但更复杂的机会往往需要计算密集型算法。捕获 MEV 所需的计算量与矿工算力无关，因此两名矿工合并即可把寻找 MEV 的计算开销减半——这种规模经济鼓励了挖矿中心化，并可能使网络更易遭受交易审查。BitMex Research 的一份 [报告][bitmex flashbots] 称，在撰写报告时，约 90% 的以太坊算力正使用一家集中服务来撮合此类 MEV 交易。为了收益最大化，该服务可能会阻止矿工打包竞争交易；若其被 100%（或超过 50% 并允许回滚链）矿工使用，实质上就获得了审查交易的能力。 + + 第二个问题是，即便 Mallory 打包了包含 1 ETH MEV 的区块，其他矿工仍可重挖区块以将该 MEV 据为己有。这种重新挖矿的压力加剧了[手续费狙击][topic fee sniping]，在最严重的情况下会令确认分数失去判断交易终局性的意义，从而削弱工作量证明保护网络的能力。 + + 比特币采用 UTXO 而非以太坊式账户体系，使得那些特别易受 MEV 影响的协议更难实现。然而在 CTV 会议上，Jeremy Rubin 指出递归契约可更轻松地在比特币 UTXO 之上实现账户系统，从而增加 MEV 在未来比特币协议设计中成为重大问题的可能性。 + + 针对 /dev/fd0 的邮件列表摘要，开发者 ZmnSCPxj 建议我们仅采纳鼓励链上隐私最大化的机制。隐私可以让矿工无法获取执行 MEV 所需的信息。截至本期 Newsletter 撰写时，邮件列表上尚未出现后续评论，但从 Twitter 等处的讨论可以看出，开发者越来越多地在比特币协议设计中考虑 MEV 的影响。 + +## Bitcoin Stack Exchange 精选问答 + +*[Bitcoin Stack Exchange][bitcoin.se] 是许多 Optech 贡献者寻求答案的首选之地——或在闲暇时帮助好奇、困惑用户。当月度更新到来，我们会精选一些高票问题与答案。]* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- ****[将助记词按字母序排列会损失多少熵？]({{bse}}113432) + HansBKK 想知道如果把 12 或 24 词种子按字母序排序，会损失多少熵。Pieter Wuille 通过可能性数量、熵值、暴力破解平均猜测次数等多项指标，分别分析了 12 与 24 词组合，并指出了单词可重复等因素的考量。 + +- ****[使用 PSBT 进行 Taproot 签名：如何确定签名方式？]({{bse}}113489) + Guggero 列出了在 taproot 中提供有效 [schnorr 签名][topic schnorr signatures]的三种方式：带有 [BIP86][] 承诺的 keypath 支付、带脚本树根承诺的 keypath 支付，以及 scriptpath 支付。Andrew Chow 确认了 Guggero 对每种签名方式在 [PSBT][topic psbt] 中标识方法的概述。 + +- ****[更快区块会如何导致挖矿中心化？]({{bse}}113505) + Murch 解释了更短出块时间如何导致更频繁的重组，以及在区块传播延迟的背景下，这如何使大型矿工受益。 + +- ****[在选币上下文中，“浪费指标”是什么意思？]({{bse}}113622) + Murch 说明，在花费时，Bitcoin Core 使用[浪费指标][news165 waste]作为“当前费率下输入集合手续费与在假设的长期费率下花费同一输入的手续费之差”的衡量。该启发式用于评估分支绑定（BnB）、单次随机抽取（SRD）与背包算法产生的[选币][topic coin selection]方案。 + +- ****[为什么 `OP_CHECKMULTISIG` 不兼容 schnorr 签名的批量验证？]({{bse}}113816) + Pieter Wuille 指出，由于 [`OP_CHECKMULTISIG`][wiki op_checkmultisig] 并未指明哪份签名对应哪些公钥，它与批量验证不兼容，这也[促使][bip342 fn4] BIP342 引入新的 `OP_CHECKSIGADD` 操作码。 + +## 发布与候选发布 + +*流行比特币基础设施项目的新版本与候选版本。请考虑升级至新版本，或帮助测试候选版本。* + +- [Core Lightning 0.11.1][] 是一个错误修复版本，解决了导致单边通道关闭交易被不必要广播的问题，以及导致 C-Lightning 节点崩溃的另一问题。 + +- [LND 0.15.0-beta.rc3][] 是这一流行 LN 节点下一个主要版本的候选发布。 + +## 值得注意的代码与文档变更 + +*本周 [Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]的值得注意变更。* + +- [Bitcoin Core #20799][] + 该版本允许向不支持 segwit 的节点更快、更节省带宽地中继区块与交易。版本 2 仍保持启用，可向支持 segwit 的节点进行快速高效中继。 + +- [LND #6529][] + 允许在不重新生成的情况下限制已创建 macaroon（认证令牌）的权限。此前若需改变权限，必须生成新 macaroon。 + +- [LND #6524][] + 这将提示未来使用 aezeed 备份恢复资金的软件扫描钱包接收的 [taproot][topic taproot] 输出。 + +## 特别感谢 + +除常规 Newsletter 贡献者外，我们特别感谢 Jeremy Rubin 本周就 MEV 话题提供的额外细节。如有错误或遗漏，仍由我们自行负责。 + + +{% include references.md %} +{% include linkers/issues.md v=2 issues="20799,6529,6524" %} +[lnd 0.15.0-beta.rc3]: https://github.com/lightningnetwork/lnd/releases/tag/v0.15.0-beta.rc3 +[Core Lightning 0.11.1]: https://github.com/ElementsProject/lightning/releases/tag/v0.11.1 +[zhao package]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html +[bip-package-relay]: https://github.com/bitcoin/bips/pull/1324 +[zhao preso]: https://docs.google.com/presentation/d/1B__KlZO1VzxJGx-0DYChlWawaEmGJ9EGApEzrHqZpQc/edit#slide=id.p +[fd0 ctv9]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020501.html +[ctv9]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020501.html +[bitmex flashbots]: https://blog.bitmex.com/flashbots/ +[news165 waste]: /zh/newsletters/2021/09/08/#bitcoin-core-22009 +[wiki op_checkmultisig]: https://en.bitcoin.it/wiki/OP_CHECKMULTISIG +[bip342 fn4]: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_note-4 From 95b11c73ca79fb7ec1371142defd6449a068bfdb Mon Sep 17 00:00:00 2001 From: BitTom Date: Tue, 17 Jun 2025 18:33:00 +0800 Subject: [PATCH 109/278] Newsletter-202 translate into Chinese (#2378) --- .../zh/newsletters/2022-06-01-newsletter.md | 42 +++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 _posts/zh/newsletters/2022-06-01-newsletter.md diff --git a/_posts/zh/newsletters/2022-06-01-newsletter.md b/_posts/zh/newsletters/2022-06-01-newsletter.md new file mode 100644 index 0000000000..8b70c79f8b --- /dev/null +++ b/_posts/zh/newsletters/2022-06-01-newsletter.md @@ -0,0 +1,42 @@ +--- +title: 'Bitcoin Optech Newsletter #202' +permalink: /zh/newsletters/2022/06/01/ +name: 2022-06-01-newsletter-zh +slug: 2022-06-01-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周 Newsletter 介绍了开发者在静默支付上的实验，并照例列出了新版本发布与候选发布的摘要，以及热门比特币基础设施软件的值得注意的更改。 + +## 新闻 + +- ******关于静默支付的实验：** 根据 [Newsletter #194][news194 silent] 的描述，静默支付使得可以向某个公共标识符（“地址”）付款，而不会在公共记录中暴露该地址被付款的事实。本周，开发者 w0xlt 在 Bitcoin-Dev 邮件列表上[发布][w0xlt post]了一篇针对默认 [signet][topic signet] 生成静默支付地址的[教程][sp tutorial]，该教程基于 Bitcoin Core 的一个[概念验证实现][bitcoin core #24897]。包括流行钱包作者在内的多位开发者正在讨论该提案的其他细节，其中包括[为其创建地址格式][sp address]。 + +## 发布与候选发布 + +*针对流行比特币基础设施项目的新版本与候选版本。请考虑升级到新版本或协助测试候选版本。* + +- [HWI 2.1.1][HWI 2.1.1] 修复了影响 Ledger 和 Trezor 设备的两个小问题，并新增对 Ledger Nano S Plus 的支持。 + +- [LND 0.15.0-beta.rc3][LND 0.15.0-beta.rc3] 是这一流行 LN 节点的下一个主要版本的候选发布。 + +## 值得注意的代码与文档更改 + +*本周在 [Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]上的值得注意的更改。* + +- [BTCPay Server #3772][BTCPay Server #3772] 允许用户在发布前为线上测试启用实验性功能。 + +- [BTCPay Server #3744][BTCPay Server #3744] 新增一项功能，可将钱包交易导出为 CSV 或 JSON 格式。 + +- [BOLTs #968][BOLTs #968] 为使用 Bitcoin testnet 和 signet 的节点添加了默认的 TCP 端口。 + + +{% include references.md %} +{% include linkers/issues.md v=2 issues="3772,3744,968,24897" %} +[lnd 0.15.0-beta.rc3]: https://github.com/lightningnetwork/lnd/releases/tag/v0.15.0-beta.rc3 +[hwi 2.1.1]: https://github.com/bitcoin-core/HWI/releases/tag/2.1.1 +[news194 silent]: /zh/newsletters/2022/04/06/#delinked-reusable-addresses +[w0xlt post]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020513.html +[sp tutorial]: https://gist.github.com/w0xlt/72390ded95dd797594f80baba5d2e6ee +[sp address]: https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8?permalink_comment_id=4177027#gistcomment-4177027 From b8e88a6388a2d5e41dabe85e5ca31eff8961183e Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Tue, 17 Jun 2025 14:44:28 -0500 Subject: [PATCH 110/278] Podcast: add 358 recap --- .../en/newsletters/2025-06-13-newsletter.md | 26 +++++++++---------- .../en/podcast/2025-06-17-newsletter-recap.md | 24 +++++++++++++++++ 2 files changed, 37 insertions(+), 13 deletions(-) create mode 100644 _posts/en/podcast/2025-06-17-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-06-13-newsletter.md b/_posts/en/newsletters/2025-06-13-newsletter.md index da09488512..6727e5b00c 100644 --- a/_posts/en/newsletters/2025-06-13-newsletter.md +++ b/_posts/en/newsletters/2025-06-13-newsletter.md @@ -38,7 +38,7 @@ infrastructure projects. We did not carefully review Poinsot's post, but his approach appeared sound to us and we would recommend it to anyone interested in - validating the math or gaining a better understanding of it. + validating the math or gaining a better understanding of it. {% assign timestamp="0:52" %} - **Relay censorship resistance through top mempool set reconciliation:** Peter Todd [posted][todd feerec] to the Bitcoin-Dev mailing list about @@ -62,7 +62,7 @@ infrastructure projects. implementation after cluster mempool support is merged into Bitcoin Core. He credited the idea to Gregory Maxwell and others; Optech first mentioned the underlying idea in [Newsletter #9][news9 - reconcile]. + reconcile]. {% assign timestamp="59:26" %} - **Updating BIP390 to allow duplicate participant keys in `musig()` expressions:** Ava Chow [posted][chow dupsig] to the Bitcoin-Dev mailing list to ask @@ -72,7 +72,7 @@ infrastructure projects. simplify implementation and is explicitly allowed by the [BIP327][] specification of [MuSig2][topic musig]. As of this writing, no one has objected, and Chow has opened a [pull request][bips #1867] to change - the BIP390 specification. + the BIP390 specification. {% assign timestamp="55:50" %} - **Descriptor encryption library:** Josh Doman [posted][doman descrypt] to Delving Bitcoin to announce a library he's built that encrypts the @@ -92,7 +92,7 @@ infrastructure projects. public key contained within the descriptor allows decryption of the descriptor. Doman argues that his scheme provides better privacy for cases where the encrypted descriptor is being backed up to a public or - semi-public source, such as a blockchain. + semi-public source, such as a blockchain. {% assign timestamp="31:35" %} ## Bitcoin Core PR Review Club @@ -118,7 +118,7 @@ the UTXO set directly. In subsequent commits, the dependency of `ConnectBlock()` on the UTXO set is removed entirely by carving out the remaining logic that requires UTXO -set interaction into a separate `SpendBlock()` method. +set interaction into a separate `SpendBlock()` method. {% assign timestamp="43:05" %} {% include functions/details-list.md q0="Why is carving out the new `SpendBlock()` function from @@ -177,11 +177,11 @@ projects. Please consider upgrading to new releases or helping to test release candidates._ - [Core Lightning 25.05rc1][] is a release candidate for the next major - version of this popular LN node implementation. + version of this popular LN node implementation. {% assign timestamp="58:25" %} - [LND 0.19.1-beta][] is a release of a maintenance version of this popular LN node implementation. It [contains][lnd rn] multiple bug - fixes. + fixes. {% assign timestamp="58:38" %} ## Notable code and documentation changes @@ -202,7 +202,7 @@ repo], and [BINANAs][binana repo]._ Additionally, this PR also lifts the one-per-transaction policy restriction for OP_RETURN outputs, and the size limit is now allocated across all such outputs in a transaction. See [Newsletter - #352][news352 opreturn] for additional context on this change. + #352][news352 opreturn] for additional context on this change. {% assign timestamp="19:54" %} - [LDK #3793][] adds a new `start_batch` message that signals peers to treat the next `n` (`batch_size`) messages as a single logical unit. @@ -211,7 +211,7 @@ repo], and [BINANAs][binana repo]._ and a `batch_size` field to each message in the batch. This is an attempt to allow additional LN protocol messages to be batched rather than only `commitment_signed` messages, which is the only batching - defined in the LN specification. + defined in the LN specification. {% assign timestamp="1:14:21" %} - [LDK #3792][] introduces initial support for [v3 commitment transactions][topic v3 commitments] (see [Newsletter #325][news325 @@ -222,18 +222,18 @@ repo], and [BINANAs][binana repo]._ stops automatically accepting v3 channels to first reserve a UTXO for later fee-bumping. The PR also lowers the per-channel [HTLC][topic htlc] limit from 483 to 114 because TRUC transactions must remain - under 10 kvB. + under 10 kvB. {% assign timestamp="1:14:59" %} - [LND #9127][] adds a `--blinded_path_incoming_channel_list` option to the `lncli addinvoice` command, allowing a recipient to embed one or more (for multiple hops) preferred channel IDs for the payer to - attempt to forward through on a [blinded path][topic rv routing]. + attempt to forward through on a [blinded path][topic rv routing]. {% assign timestamp="1:18:38" %} - [LND #9858][] begins signaling the production feature bit 61 for the [RBF][topic rbf] cooperative close flow (see [Newsletter #347][news347 rbf]) to properly enable interoperability with Eclair. It retains the staging bit 161 to maintain interoperability with nodes testing the - feature. + feature. {% assign timestamp="1:20:04" %} - [BOLTs #1243][] updates the [BOLT11][] specification to indicate that a reader (sender) must not pay an invoice if a mandatory field, such @@ -241,7 +241,7 @@ repo], and [BINANAs][binana repo]._ incorrect length. Previously, nodes could ignore this issue. This PR also adds a note to the Examples section explaining that [Low R signatures][topic low-r grinding], even if they save one byte of - space, are not enforced in the specification. + space, are not enforced in the specification. {% assign timestamp="1:21:49" %} {% include snippets/recap-ad.md when="2025-06-17 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-06-17-newsletter-recap.md b/_posts/en/podcast/2025-06-17-newsletter-recap.md new file mode 100644 index 0000000000..0926eb375c --- /dev/null +++ b/_posts/en/podcast/2025-06-17-newsletter-recap.md @@ -0,0 +1,24 @@ +--- +title: 'Bitcoin Optech Newsletter #358 Recap Podcast' +permalink: /en/podcast/2025/06/17/ +reference: /en/newsletters/2025/06/13/ +name: 2025-06-17-recap +slug: 2025-06-17-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt are joined by Antoine Poinsot, Peter Todd, +Josh Doman, and TheCharlatan to discuss [Newsletter #358]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-5-17/402348085-44100-2-e516e54c780c1.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From 6f38d8b869a21ae58f10d069b5f6989dd0baa750 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 19 Jun 2025 11:31:51 -0500 Subject: [PATCH 111/278] Podcast: add 355 transcription --- .../en/podcast/2025-05-27-newsletter-recap.md | 940 +++++++++++++++++- 1 file changed, 939 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-05-27-newsletter-recap.md b/_posts/en/podcast/2025-05-27-newsletter-recap.md index a65268bd3f..1ec6f6a128 100644 --- a/_posts/en/podcast/2025-05-27-newsletter-recap.md +++ b/_posts/en/podcast/2025-05-27-newsletter-recap.md @@ -18,6 +18,944 @@ Dave Harding is joined by Alex Myers and Rodolfo Novak to discuss [Newsletter #3 ## Transcription -_transcription coming soon_ +**Dave Harding**: Welcome to the Recap for Bitcoin Optech Newsletter #355. +Today, we're going to talk about some recent Changes to services, client +software, and popular Bitcoin infrastructure software. Your regular hosts, Mike +and Murch, are at a conference this week, so I'll be hosting today. I'm Dave +Harding, co-author of the Optech Newsletter and the third edition of Mastering +Bitcoin. We have two great guests today. The first is Alex Myers, who will +talk us through a spate of recent changes to Core Lightning (CLN). Alex, could +you please introduce yourself? + +**Alex Myers**: Sure, yeah. I've been a CLN engineer for a few years now. +Mostly, I work on the gossip protocol side of things, and I also work on +reckless, which is our plugin manager. My background is more in electrical +engineering than CS, but I got so enamored with the LN that I kind of couldn't +stay away. So, yeah, I've really been enjoying my time contributing CLN and +working with the ecosystem. + +**Dave Harding**: That's great. And our second guest today is Rodolfo Novak, +known to many as NVK. He'll be talking about a recently added feature to +COLDCARD, and we'll lean on him throughout this episode for his deep knowledge +of what everyone else is building too. NVK, would you like to introduce +yourself? + +**Rodolfo Novak**: Hey, so yeah, NVK, I founded Coinkite. We've been making +Bitcoin security devices and hardware for, I don't know, 15 years now. And +yeah, that's what I do. People know it for COLDCARD, BLOCKCLOCK and TAPSIGNER, +and other things like that. + +**Dave Harding**: Okay, great. Those are our two guests. So, we're going to +just jump right into the newsletter. The first section we usually have is News, +but we didn't actually find any significant news this week. And I actually +think that's kind of great, not just because I'm lazy and I don't want to +actually write stuff, but also because I think it means people are out there +building stuff. Between the big announcements that we cover, the protocol +changes, the theory about Bitcoin, we actually need people to be doing the +actual day-to-day building. And that's kind of what this newsletter is about. +We're going to be looking at the changes to products, like what Rodolfo is +building, we're going to be looking at changes to code, stuff like what Alex is +doing, that actual stuff that has to get done when we're not sitting around +talking about, well, I won't say what we've been talking about lately, but that +stuff. + +_Cake Wallet added payjoin v2 support_ + +So, going on to our next section, it's Changes to services and client software. +And we had eight this week. The first one is Cake Wallet. It's added payjoin +v2 support. So, the original payjoin is a protocol that allows a wallet that's +about to receive a payment to communicate with the spender who's about to send +the payment, and they can actually include some extra inputs into the +transaction to break up the heuristics that companies use to try to track who +owns bitcoins. + +V2 payjoin is a protocol that allows you to do that without the receiver acting +as a server, so previously they had to run a server. So, it was great for like +BTCPay because they already have an HTTP server running. But for other wallets, +it was hard if you're just using your regular consumer wallet. So, v2 payjoin +protocol allows a third party to act as the server, in a sense, as a relay +server. They don't learn any information, they just learn that people are +connecting through them, and allows people to use this really great privacy +protocol. So, Rodolfo, Alex, you have any comments you want to add on that? + +**Alex Myers**: I'd love to see more adoption of payjoin. I want to break all +the heuristics, that's kind of my goal, so I love that it does that. Also, I +think just managing your UTXOs by providing that input, you kind of limit the +growth of your wallet change. So, I think it's a win all around. I don't deal +too much with payjoin, but I love to see it. + +**Rodolfo Novak**: Yeah, I mean it's super-cool. Same thing I echo, I really +wish we would see more adoption. I wonder if maybe LN wallets could start using +it for funding channels, and maybe there is a path there. On the store side as +a merchant, it's really hard to sort of implement a solution that does find +other payjoiners to join, there is a bit of a chicken and egg issue there. So, +I think maybe starting with things that have a lot of users, like LN wallets, +might be a cool place to start, because they have to fund it, right? They have +to deposit something, either by themselves or by whatever magic of liquidity +happens. So, I don't know, that's super-cool. + +**Alex Myers**: So, LN does have a dual-funded transactions in which both +parties contribute an input and you get effectively a payjoin there. But like +you said, the hard part is the marketplace for it. So, like with CLN, we've got +liquidity ads where you can advertise in your node announcement, that's the +gossip message that says, "Hey, here's my node, if you want to connect to me, +this is where to reach me", and all of that. And you can list like what rates +you're willing to -- if you want to contribute, like, half of a channel capacity +to a channel open, you can say, "Hey, I'm willing to contribute up to this +amount. And this is the maximum fee that I'll charge you if you want to use +this channel to receive on", that sort of thing. But yeah, it is hard to create +that marketplace where you can discover other people who want to create a +payjoin. + +**Rodolfo Novak**: Yeah, it's like some automation there, some, "Check a box if +you want to participate", kind of thing in a high volume of users sort of system +would be pretty cool. + +**Alex Myers**: Yeah, so I've been running it on my node for a few years now, +and it was experimental for most of that time, but I've had a few people open +channels, dual-funded, so it's nice to see there's a few people interested in +checking out the new features. But yeah, I'd love to see more of it. + +_Sparrow adds pay-to-anchor features_ + +**Dave Harding**: Okay, moving on to the next item, we have, "Sparrow adds +pay-to-Anchor features". So, pay-to-anchor (P2A) is a specially formatted +output to a transaction that signals to the Bitcoin Network that it's meant for +fee bumping. For that reason, we allow it to be an exception to some rules in +some cases. Sparrow is a great wallet if you want to play around with some +advanced Bitcoin features. It's a really nicely done wallet, I think. And it's +great that they've added support for this, both you can send it, you can also +display it in their transaction explorer thing to see what's going on. So, if +you got a weirdly formatted transaction, now you'll learn that it's got a P2A +output. And if you want to create it, I don't know there's going to be a lot of +demand to create these in Sparrow wallet, what do I know? They're mainly used +for transaction packages. So, we see them a lot in proposals for upgrades to +the LN, where transaction packages can be really important for unilateral +closes. But I don't know how often you're going to see them in typical end user +onchain transactions, but you have the option now in Sparrow wallet, so that's a +great thing. Any colour, guys? + +**Rodolfo Novak**: I'm just happy that Craig added a total amount for send to +multisig. + +_Safe Wallet 1.3.0 released_ + +**Dave Harding**: Oh, okay. Nice. Okay, moving on to our next item, Safe +Wallet. Safe Wallet, they have hardware device support in that wallet. And +their new feature in this one that we've noted is a CPFP fee bumping. So, this +is kind of the base feature you get before P2A, and it's great. It allows you, +when you receive a payment, to increase its priority by bumping the fee on and +create a child transaction that pays extra fee. And this encourages miners, +through the Bitcoin Protocol, it's an incentive to include that transaction. +You can also use CPFP on your own outgoing transactions if you don't want to +change them. Although often in that case, it's better to use RBF, because +you'll save a bit on fees and should accomplish the same result. But CPFP is +the only option you have when receiving a transaction from someone else +normally. And so, it's a great addition. Any comments on CPFP? + +**Alex Myers**: I guess it makes sense for a multisig wallet. It's going to be +a lot more pain to do the RBF and you might not have access to one of the keys. +So, sure, having more options is always nice for the user. + +_COLDCARD Q v1.3.2 released_ + +**Dave Harding**: That's true, that's a really good point. And then moving on +to our next item. So, we have a new version of COLDCARD and I'm just going to +let Rodolfo take it away. Tell us what's new in here. I know a headline +feature, at least for me, and I'm really excited about it. So, tell us,Rodolfo. + +**Rodolfo Novak**: Well, go for it! I'm just here to answer questions. + +**Dave Harding**: Okay, well, the headline support for me is this new upgraded +multisig spending policy support. And as I understand it, please correct me if +I'm wrong, you can set up one of your COLDCARDs in a multisig, maybe multiple, +but I know for one, to have a policy for what it's going to sign. And I believe +that's pretty much automated signing, right? Like, once you get it, get the +policy set up and you can just set it to PSBT and it'll just sign it for you if +it matches the policy, is that correct? + +**Rodolfo Novak**: That's right. And there's a bit of port-knocking sort of +mentality there. So, it's not visible to an attacker that may be beside you. +So, unless the PSBT contains the xpub of the COLDCARD extra key, the policy key, +it's not displayed. And you can choose to have it set up, you choose the +velocity, you choose maybe it's a whitelist of addresses, that's a very common +use. There's also 2FA. So, it's essentially like Web OTP. So, you just scan +the web with a 2FA token, and you can also authorize that way. So, right now, +this is sort of a pigeonhole to 2-of-3. And we're looking into adding this +feature for a single-sig as well. Always a little bit reluctant to do something +like that, because there is a limitation to how much a device can be secured by +one key. But there is a lot of people who need this for their spending wallets +or for medium-sized amounts. If you're not too concerned about laser fault +injection, then I think it's sufficient security. + +I'm super-excited about this. We spent a few years trying to figure out, how +can we create more serverless, higher thresholds of signatures for people to +operate on the field, especially because now people don't live in the same place +anymore, people are traveling, people are nomads. And the codename for this +feature was 'Travel wallet'. And we wanted to just make something that creates +a bit of a higher threshold of safety first for people to spend. I would not +put your life savings on it, but it is definitely up there with most +server-based solutions in terms of actual practical security. Yeah, and that's +where it goes on that feature. + +**Dave Harding**: That's really great. When I was doing the digital nomad thing +before COVID, that was a real concern of mine. It was trying to figure out how +to transport my bitcoins safely so that I could access them when I was +traveling, but other people couldn't. So, I mean I just love this feature. I +think it also maybe enters sort of the vault conversation. + +**Rodolfo Novak**: That's right. + +**Dave Harding**: Stuff like this is what people want. They want ways to secure +their bitcoins that's very easy to use. You set up this policy and you just +forget about it, except you can spend, right? So, great. + +**Rodolfo Novak**: There was some inspiration based on OP_VAULT by Jameson. And +if we're going to get covenants on Bitcoin or not, that's a completely +different, massive tangent. But the reality is, we need spending policies, +right? You can't exist in a financial, secure universe without, at a minimum, a +velocity limit or whitelisting. And again, we just keep on breaking it down, +like how can we make this happen to people without having to call a server, +because the server is often the problem, especially when you're trying to be +sovereign, right? You can't realistically leave a server running somewhere and +just expect it to be there. I think this in conjunction with, say, decaying +multisig on miniscript, so maybe this is where the funds go to in case your +miniscript decaying fails or progresses, depending on how you want to look at +it. There's a lot of permutations that this can happen. + +There's also the business use case, right? A lot of people in offices, you +have, say, two founders and they need to operate. So, one founder has key A, +the other one has key B, and then both have key C, because you can use the same +key in two COLDCARDS. So, both COLDCARDs can have spending policies set for key +C. And that's really cool, because now at least you also have some auditability +because you know which key spent, if it was key A or key B plus key C. So, the +two founders are able to spend on a limitation that they decide together. +There's some trust involved, of course, but then if they want to spend over the +limit and they're both traveling, they can just sign together with key A and key +B. That's a super-cool thing. And that ties into the other feature, the key +teleport feature. + +**Dave Harding**: Yeah, tell us about it. + +**Rodolfo Novak**: So, again, based on this idea that people no longer are at a +single location anymore, really joining that sovereign individual kind of +mindset. I wanted a way to send a secret to somebody else where I don't trust +the phone, I don't trust the computer and I don't trust the comms. Those three +places, nobody in their right mind trusts anymore. That's why we do AirGap +things. But if we assume in this trust model that the AirGap device is secure, +because it's already holding the secrets anyways, how can we create a simple +tunnel between the two so that it can send a secret. And another aspect of that +was, how can I do that without needing again a server, or a server that is +something that the two agree on, right? I mean, everything's a server, but I'm +getting that. So, in a phone call, a video call, can I send, say for example, +key C to a coworker, COLDCARD; could I send him an SSH key because there is an +emergency with the server; or could I send him a truly secret message without +trusting the computer or the phone? + +That's what key teleport essentially achieves, is this very, very hardened, +secure comms between two COLDCARDs via a untrusted channel. And really, all you +have to do is the receiver essentially shows a QR code on a call, or you could +do NFC with a website that we created, and you can run that web on your own +computer if you want as well. It's open-source code for you to do that. And +you share this QR, which is essentially like a public key for a whole Diffie +session, protected by a small password, because some trade-off there on the ease +of use and really is just for the privacy of that disposable key, which is +already disposable anyways. So, essentially you exchange the secret over a +different channel in case you have somebody watching that channel and you don't +want them to see the public key of that session. And then, the other party can +send you anything from their COLDCARD, including the COLDCARD itself, by sending +the full backup of that COLDCARD. So, you can teleport to that COLDCARD. + +I think it's a very elegant, simple solution. We really tried to keep it to +non-novel cryptography and in our usual way, just sort of bang it out there, +uses BBQr or I get NFC with this very simple spec. I use it a lot like when I +have to help people set up COLDCARDs with BIP85 seeds, or friends, family, +colleagues need to recover a seed from some different hard wallet that they just +transferred to a whole COLDCARD that I told them to get, and then they send it +to me and help them discover whatever horrible derivation path they had. You +know, the usual problems that Bitcoin ownership has. I think this is a +super-cool feature. + +**Dave Harding**: Yeah, that sounds really cool. I like that it sounds like +something I could give to my dad, you know, I could give to somebody who is not +super-nerdy about modern security technology, and they could just use it. Like +if you and I had to send a message, we could probably find a way to do it. But +anybody else, they could just go out and buy a COLDCARD and we could just trade +messages. That's pretty awesome. Thank you for doing that. That's a great +feature add. + +_Transaction batching using payjoin_ + +So, I'm just going to keep moving on to the next item. And that next item is, +"Transaction batching using payjoin". So, there's an experimental +implementation of a transaction batching service. I think this is here. This +is kind of designed to allow multiple people to batch their transactions +together, kind of like a coinjoin, but for sending payments. And it has what +they're calling a payjoin thing. So, the receivers can also participate in the +transaction batching. So, that's pretty cool. It looks very experimental to +me. It's explicitly says in the documentation, "Don't use this in production", +so that's a good sign that you shouldn't. But it does seem like a nice path +forward for companies, organizations that are making multiple payouts a day to +different people. They can set up this batching service and say, "Hey, Alex, +Rodolfo at 5.00pm today, you're going to get a payment. But if you want, you +can also contribute inputs to this and just boost your privacy". So, I mean +that's great, I hope people use that, and it's using the payjoin protocol. So, +we talked about this earlier, as we get more support for that in software, +hopefully this will become more and more of an option for people. Any comments? + +**Alex Myers**: Yeah, it's great to see people playing with these sorts of +things and releasing this batching system. So, this is the first I've seen of +it, but it looks exciting. + +_JoinMarket Fidelity Bond Simulator_ + +**Dave Harding**: Yeah, I didn't hear about it until Mike put it in the +newsletter. So, happy about that myself. Our next item is, "JoinMarket +Fidelity Bond Simulator". So, JoinMarket is a coinjoin implementation that +doesn't use server coordination. So, Wasabi and old Samourai, they used a +server-coordinated coinjoin. JoinMarket is P2P. But because it's P2P, they +have problems with DoS attacks. People can offer and say, "Hey, I'd be happy to +merge my coins with you". And then, you go to them and you tell them about your +coins, because they need to know your coins in order to create a coinjoin. And +then they're like, "Okay, well, I'm not going to create a transaction with you +anymore, I'm not going to sign. And so, they learn that you're trying to get +privacy, and you do this through Tor, and whatnot, but they might learn stuff +about you. + +To help cut down on that kind of problem, JoinMarket introduced fidelity bonds a +while ago, and that's a time locked bond. So, you take your money and you spend +it to yourself but in the future. Until that future point, you can't spend it. +So, there's a time value of money. So, you're losing access to your money and +that's kind of a cost, but it's not a cost that's borne by anybody. You don't +have to pay fees. I think you're actually in the JoinMarket, you're actually +also allowed to destroy bitcoins. And so, somebody has created a bond simulator +there. So, for X amount of bitcoins that you put into this time locked +contract, how much money are you expected to make through maker fees in joint +market? + +So, I should have explained, joint market as a P2P protocol also has makers and +takers. So, makers are people who probably want privacy, but they also want to +earn fees, and they're willing to be patient and sit around and keep their +bitcoins liquid for you to come in for a coinjoin. And then, takers are people +who want privacy right now. So, they have bitcoins, they want to break that +transaction history, so they can go and find a maker and do a coinjoin with them +and get the privacy right away. And often, you want to do that several times, +so you'll do your coinjoin with several different makers, either in a single +transaction or a series of transactions. And the makers are the ones who are +advertising their service by creating these fidelity pods. So, this simulator +just helps you find that sweet spot between how long are you going to lock up +your bitcoins and how much money are you going to make; because if you lock them +up for too long and you don't make much money, it's not worth it. So, I think +this is a great piece of software. Any comments from you guys? + +**Rodolfo Novak**: So, part of our corporate strategy involves JoinMarket, and +we believe that you shouldn't reveal your coin pools essentially to vendors when +you pay them in bitcoin. And we found that there is a lot of FUD with +JoinMarket. It's just because, I guess, there is less visibility because there +is no centralized coordinator. But it is surprising how much liquidity there is +at it. It just may not be at that specific moment you look at the index. You +can put in quite a lot of funds through it. There is some leakage. +Unfortunately, the leakage is heavy on the taker side, just because of the sheer +amount of, you're going to have to do a minimum of seven rounds. And if you +want that to move, then you're going to have to pay fees on top of the +percentage. + +But the maker side is surprisingly good. And if you lower your fees enough, +which many people do, the leakage is nearly zero. You might actually make a +buck. Also, personally, I recommend people just target neutral, just because if +they're doing this lawfully speaking with a tax bullshit participation in the +thinking, it's a lot easier accounting-wise if you have a neutral outcome. And +what we're missing now really is just better UI for it. Right now, if you want +to do it well, you have to use a terminal. But I do highly recommend people +stop being afraid of it and use it. It's perfectly good to do so, and there's +liquidity. + +**Dave Harding**: Yeah, I think it's a great piece of software. Go ahead, Alex. + +**Alex Myers**: I don't have too much to add. I just like to see tools like +this that bring a little bit more data to the table so that you understand +what's going on behind the scenes. I think, especially in LN, we have a problem +where we focus on privacy, but it's kind of to the detriment of protocols where +it's a little bit opaque, like how much usage and details like that are +occurring. So, I'm always for tools like this that help people understand a +little bit about the trade-offs and what they can expect. + +**Dave Harding**: Yeah, it is great. And I do hear you about how privacy, it +makes it hard to celebrate our wins. Like, exactly how much liquidity is in the +LN? I don't know. There's private channels and stuff. + +**Alex Myers**: And I think the private channels actually probably dwarf the +public ones, if we're being honest. So, we have no idea. + +_Bitcoin opcodes documented_ + +**Dave Harding**: Right. So, there's a downside. Obviously, we all want +privacy. We just wish we could have everything, right, we can have our cake and +eat it too. Moving on to the next item. There's a new website here called +Opcode Explained, and it documents each script opcode, and they also have a +tutorial to help show you how Bitcoin Script works, which depending on how you +learned how to program, it could be a bit of a brain twist. If you're more +familiar with the lower-level stuff, it's just like that's how it is. But if +you only learned Python, you might need a little bit of tutorial there. So, +it's great. For each of the opcodes, you just pull up the thing and it tells +you what the opcode number is, what the representation looks like. So, if +you're trying to decode some hex script, which if you get really into Bitcoin, +you will, and you actually start to read that stuff pretty well, I think. And +then, what it does, and they have an example. So, it's a really nice website +that just helps you through this stuff. Up until this point, I've used the +Bitcoin wiki. I think the page is named 'Script', and it has a list of all the +opcodes. This is a lot nicer, especially if you're learning it and you don't +know what's there already. So, kudos to whoever created this. Any comments, +guys? I think we'll just move on. + +_Bitkey code open sourced_ + +And the last one is, the Bitkey code is open-sourced. And I think I've seen +Rodolfo talk about the difference between open source and free software on +Twitter. So, this is open source in the sense that their code is viewable, but +they have a restriction for non-commercial use. And I think that's basically +what you guys do with COLDCARD too, is that correct? + +**Rodolfo Novak**: Yeah. So, it's a very complicated topic. The OSI has a +different take on this, but essentially, I believe they use the same license +that we did, which is MIT. It's extremely permissive license. Due to +commercial issues with bad actors, we decided to add a commercial restriction on +the device. So, the users are protected, they can do whatever they want. They +can copy, they can change, they can give it to their friends, they can sell to +their friends, whatever. It really is just a protection against people taking +advantage of the open nature of the device. + +I think the difference is, the Bitkey hardware device has that license, but +Bitkey is not quite the hardware wallet, it's more like a backup device. There +is a server which is a holder of one key, and I think there is an app as well. +So, it's sort of like one of the legs is open, the other legs are complicated. + +**Dave Harding**: Okay, 'Complicated'. That's a good description, I think. Did +you want to say something else? + +**Alex Myers**: It's nice to see some progress and moving in this direction. I +guess personally, I'm more excited about fully open source, because then you +encourage external contributors that might not have volunteered their time to +review source code. Otherwise, yeah, it's nice to see. It's nice to see some +progress in this direction. + +**Dave Harding**: I agree, it's nice that you can go and do the source code. +So, if you're starting to have a problem or you're concerned, I know somebody +who found a flaw in a hardware wallet. They did, what is it, RFC, I can't +remember, 3757 for ECDSA deterministic nonce. They had actually inverted one of +the operations so the deterministic nonce wasn't matching the thing and somebody +was able to go and look at the source code and figure out what was going on, +because it was just generating these wrong nonces. It didn't realize it was +just -- anyway, so that's nice. I also would love to see purely free software, +but I understand that there's other constraints out there. + +**Alex Myers**: You know, it's one of those things that's a real shame. You'd +think all users would be concerned about this sort of thing and be kind of +clamoring for at least having accessible source code here to review for +themselves. But at the end of the day, you send out surveys. I remember there +was one for the Jade and they were talking about anti-exfiltration and some fun +new crypto features. And the major takeaway was that the features that users +were actually clamoring for was like, "I want more color options for the case", +that sort of thing. + +**Rodolfo Novak**: We've been doing open-source Bitcoin stuff for literally +ever, right? And we find that like 99.99% of the time is like, "Please don't +contribute to my codebase because your security suggestion is bad". That +happens a lot. And we find that the majority of the people who have a stake in +the game, right, they're holding reasonable amounts of funds and devices, they +will contribute regardless of the license. And you get those; every time we +release new software, we get emails, PGP emails, "Hey, why did you change this?" +or, "Why did you do that?" It is kind of fascinating. A lot of that action +happens quietly. Yeah, it's tricky. And at the end of the day, users really +want practical things, right? + +I think that the biggest advantage, at least just focusing solely on security, +not the ethical preferences of the licenses, is the reproducible code. Because, +people wanting or not, when it comes to complicated things, we do rely on the +few who can understand. And if they trust that that signature matches, and you +can check that it builds to that, it is a total superpower. I mean, it's hard +to convey that to get to that level without reproducible builds, you have to go +into a military facility and have like three people to essentially review each +commit, and then there's three people who review the commits of the three people +who review the commits. It's super-cool, so props to them for making that at +least open for review. + +_LND 0.19.0-beta_ + +**Dave Harding**: Yeah, yeah, that's great. Okay, we're going to move on to the +Releases and release candidates section. So, we have a new release, it's LND +0.19.0-beta. This is the latest major release of LND. I made some notes here +for what the major features are. I don't know, Alex, is there anything in this +release that you saw that excited you? You don't work on LND, but for +interoperability or anything else, is there anything that you said, "Oh, I'm so +happy that they got that out there"? + +**Alex Myers**: I'm reading the release notes now. + +**Dave Harding**: Okay. Well, then I'll go through my notes real quick. + +**Alex Myers**: Okay. + +**Dave Harding**: The big one for me is they added support for the RBF +cooperative closed flow, which I think is also supported by Eclair and maybe +LDK. I'm not sure that CLN supports that one yet. What this does is it allows +the node, who's requesting the channel be closed in a cooperative scenario, to +say, "This is how much fee I want the cooperative closed transaction to pay and +I'm willing to pay it out of my side of the channel". And the other side is +like, "Great, you're going to pay the fee and get this channel closed. That's +perfect for me". So, it's a nice fee and you can actually, as the name implies, +you can use it for RBF. So, the channel, they created a cooperative closed +transaction and it hasn't confirmed in a reasonable amount of time, the party +requesting close can say, "Okay, well, let's bump the fee. And again, the +additional fee's coming out of my side of the channel". So, we can use RBF for +cooperative closes, rather than having to use something like CPFP. And CPFP +just requires more bytes onchain, which requires paying more fee overall. So, +it's a nice feature. + +Another feature they have in this new release is archiving of their channel +backups. I don't exactly understand what's going on here. I'm guessing it's +just tracking what backups you've made. This is by default off, so you're not +using it by default, but if you need it, it's there. Another feature that +excites me is they have experimental HTLC (Hash Time Locked Contract) +endorsement signaling. This is something that ultimately we may want to use to +prevent channel jamming attacks, which are a concern that Rusty brought up, I +think, seven, eight years ago, pretty early in LN development, that we haven't +quite solved. It hasn't yet, as far as I know, been a major problem, but it is +an outstanding concern. HTLC endorsement is not an entire solution for it, but +it's a great mitigation. LND is not using it directly here, they're just making +the signals and allowing it to be used for research purposes. They're not +changing how anything is routing in this release. + +**Alex Myers**: Yeah, that's a difficult one. I can actually speak to that a +little bit. I followed Carla and Clara's work on it, and Matt Morehouse was +also a major contributor to running some of the channel-jamming scenarios. +Yeah, that one's going to take a while to roll out, because as you say, you need +all the parties to support that endorsement bit. But then, you can actually use +it to kind of bucket your HTLCs into endorsed and non-endorsed. And so, the +idea is that you can start applying back pressure under a jamming scenario and +you still have some open HTLC slots available for those endorsed HTLCs that you +say, "Hey, I've got some reputation with both of these peers, so I'll give you +guys a little bit of preferential treatment at the moment". But yeah, it's +exciting to see some progress on that. I think it is something that we should +be devoting some resources to, but like you say, it's not really a silver +bullet. But it's definitely a lot better than not being prepared at all for +such a scenario. Yeah, so this is kind of the first step in supporting that. + +**Dave Harding**: I think Eclair has also started doing the experimental +signaling without any routing changes or forwarding changes. And the final +thing I called out in my notes was, they have initial support for the quiescence +protocol, which I believe every other implementation already supports. And +that's for channel splicing, that's part of channel splicing, and it also will +help with dynamic commitments, which I know is a major hobby project of +roasbeef. And dynamic commitments are the ability to upgrade the format of the +channel-funding transaction without closing the channel. The quiescence +protocol, it's just one node says, "Okay, let's not add any more payments to +this channel. Let's settle it, get it into a state where we can do an important +operation, and then un-quiescence it". I don't think it's a word, but we try. +So, I'm really glad to see that they're doing this. I'm hoping that they'll get +splicing support. I think we have splicing support also in every other +implementation. I'm not sure about LDK, but I think we have it there too. So, +that's great. + +**Alex Myers**: All I can say is I know CLN and Eclair have interoperability +now, and there were a lot of edge cases for re-establishing channels that were +just really easy to overlook, so that was kind of a long road in fleshing out +that spec there. But kudos to Dusty for spearheading that. + +**Dave Harding**: Did you see anything else in the notes that you wanted to +comment on, Alex, for + +**Alex Myers**: LND? No, I think you covered it pretty well. + +**Dave Harding**: Okay. Rodolfo, anything you want to say about LND? + +**Rodolfo Novak**: Oh, dude, I am Lightning-complicated! No, +it's awesome, things are moving. We've been playing with phoenixd to just check +it out, and Lightning is great for clearing. For payments, it's tricky, but I'm +loving the progress. + +_Core Lightning 25.05rc1_ + +**Dave Harding**: Great, great. And then, we're going to move on to, we have an +RC. We have Core Lightning 25.05rc1. Alex, what's going on? + +**Alex Myers**: Yeah, so I thought it was going to be a small release, but we've +got a few features. Let's see. Rusty worked a bit on reducing the latency of +commit and revoke messages, so we got a little speed up in performance there. I +added a couple features to reckless, which is our plugin manager. I was +actually working on archiving a plugin that Christian Decker had written a while +ago, historian, that just archives all of the gossip traffic that it sees. And +just continuously pushing these updates to my node to test them live, I realized +that our infrastructure was a little bit lacking there. So, yeah, we've got an +update command that you can just run reckless update, and it will go through all +of your reckless installed plugins. And so, long as you didn't ask for a +specific tag or commit when you installed it, it'll just update to the latest +with the same source. + +Let's see. We've got some askrene fixes. That's still a little bit new. So, +that's René Pickhardt's min cost flow solver, when we're doing payments and we +need to create a route. Rusty's xpay plugin relies on that, and it's had really +good performance, as far as from my own personal experience at least, I don't +know if other users would agree as well. But yeah, it leans heavily on askrene +internally. So, it's nice that it is getting those kinks worked out with each +release. Let's see. the listhtlcs API has pagination support, so that's nice +for developers. And then Peter Neuroth has been starting work on an LSPS client +and server. So, this is if you want to be able to offer a Just-In-Time (JIT) +channel, or something like that. This is still in the early development, so +he's just got the transport layer worked out now. But the idea is to be able to +support that in the future, so you can basically be your own LSP from your CLN +node. I think that's really exciting. So, anyone who's interested in that +should definitely look into a little bit and see what he's working on. + +Let's see. We had a feature request from, I think it was the guys at Ocean +Mining, wanted a signmessagewithkey, so that you can sign an arbitrary message +with your wallet. That's in this release. And then, let's see. Yeah, we've +got the splicing updates for Eclair interoperability. Oh, and actually, one of +the big ones is peer storage was an experimental feature. And that lets you +back up your emergency recover or static channel backup, depending upon the +naming convention you use. It lets you back that up with a peer. So, there's +this message where you can basically say, "Hey, here's this blob of up to 64k of +data". And when you initially connect to that peer, they reply with your blob. +And you can use that to validate, make sure that you have the latest state. If +you somehow lost state, they'll actually reply to that first thing and you can +start an emergency recovery process. So, anyhow, this was an experimental +feature for the last couple years and it's now been merged into the spec. So, +this is now on by default. And we were able to settle on the finer feature flag +to use there, and just polished up a few of the things for larger nodes, make +sure that it scales reasonably, and that sort of thing. Yeah, this feature has +graduated to the big time now, so it's nice to see. Oh, you're muted. + +**Dave Harding**: Thank you. That sounds great. That's a very nice release. +We will cover, I think, at least one of those things a little bit more. We had +the peer storage that was pretty late in the release process. So, we actually +have that in our merges below. I think peer storage is great. It's a really +nice use of the protocol. Do you know if there's been any work on, I think +Thomas V, I can't remember his name, from Electrum proposed a pure storage with +penalty if you didn't provide the latest state? We covered that, I don't know, +a year-and-a-half ago in the newsletter. I don't know, did you hear anything +about that? + +**Alex Myers**: No, I haven't heard anything lately about that. But yeah, +that's interesting as well. I don't know, it gets kind of complicated, the +incentives. This isn't really meant to be like an end-all and just totally +solve your backup problems, but I think for the average home node runner that +doesn't have serious funds and doesn't have hundreds of channels open, it's +definitely a nice feature to have that doesn't have a major cost to implement +it, and it provides you something. I think if you have a serious node, you have +more backup options, you could run a Postgres database with replication, and +that sort of thing. So, there's definitely more appropriate options for major +nodes out there. But just for spinning up a small node with a few channels, +this should provide a fairly decent option for most people, I think. + +_Bitcoin Core #32423_ + +**Dave Harding**: That's great. Okay, thank you, Alex, so much for giving us +that rundown. We really appreciate that. We're going to move on to the Notable +code and documentation changes. We're going to start off with Bitcoin Core +#32423. This is a rare thing to happen. It removes the deprecation notice for +the RPC password configuration options. This is a way to add a plain text +username and password to your configuration file in Bitcoin Core. It still is a +way to do that. It's been supported since, I believe, the original RPC +implementation for Bitcoin Core, which was added sometime around the time that +Satoshi left, I believe. And the idea there was that sticking a plain text +password in a text file on your file system is not the most secure thing to do. +So, tools were added and additional configuration added to add a hashed password +to your configuration file, a hashed username password combination. So, you +could authenticate with that. + +However, even though it's not the best security idea, it's also not the worst, +because you really want to keep your file system secure for lots of other +reasons. And people have continued to use it and the developers are like, +"Well, we've been talking about removing this for a long time but we haven't. +People are still using it. It's not the worst idea". So, they decided to +remove the deprecation notice and they're just going to keep it. So, I thought +this was really worth calling out. The tools for using a hashed username and +password, they're still there, you can still use it. If you're a little bit +more security conscious, you should. But it's nice to see developers change +their mind, because sometimes that can be hard. So, that's great. Any comments +on that, you guys? + +**Rodolfo Novak**: I mean, if I remember right, this was the one that a lot of +people's coins were being taken way back then by RPC. Was this the one or no? +Was it the auto password? + +**Dave Harding**: I don't think it's the auto password either. I think, was +that people using the SSL authentication? So, they were doing it over the +network. + +**Rodolfo Novak**: I remember something with RPC and the password way, way, way +back then. But anyways, I mean, yeah, it's nice to see a little improvement +there. + +**Dave Harding**: Yeah, I think it's often the case that if they have local file +system access, they probably have other access to steal your coins in another +way. So, that's why it's not the worst idea to use this. But you could be more +secure if you want to be. + +**Alex Myers**: Deprecations are hard, especially with all the downstream users. + +**Rodolfo Novak**: People even keep coins on Bitcoin Core wallet, generally +speaking, it's very rare. I mean, sure, there is some folks that are extremely +more technical than most people, but it's very hard for me to find people who +are using Core directly as their wallet too. So, there is that. + +**Alex Myers**: Got to agree with that. + +_Bitcoin Core #31444_ + +**Dave Harding**: Okay. Moving on to the next item, we have Bitcoin Core +#31444, and that extends a class related to cluster mempool. I won't go into +details here, but this is one of the last major PRs, we hope, for cluster +mempool support in Bitcoin Core. That will still be experimental for a while. +The way it's likely to go out is that it's going to be turned on by default when +it goes out, because it's not worth having the code for both cluster mempool and +non-cluster mempool in the same codebase. But Pieter Wuille has been adding all +the function necessary for it in the background, and this is the last one of +those. So, I suspect the developers are going to be building with the cluster +mempool, they're probably just going to have a branch, they're going to work on +it over there, and that's great. Cluster mempool is really exciting. The end +user, it's probably not going to change how you use Bitcoin or what you see, but +it's going to be really great for the developers because it gives them tools to +improve mempool policy in the future. + +We've covered cluster mempool quite a lot in previous newsletters and previous +recap podcasts, so I won't go too much in detail here, but I am excited to see +this get closer and closer to the end line, and also at the point now that we +can start to use it in experimental settings, people could start to run, not +yet, not with this PR, but we're getting close, but people could start to run +cluster mempool nodes and compare the performance of that to a traditional node. +And when we're at parity, we can switch over to that and then start building on +the guarantees that cluster mempool gives us for mempool policy. Any comments +on that, Rodolfo, Alex? + +**Alex Myers**: Love to see some progress here. Yeah, it's been a long time +working on cluster mempool, so yeah, I'm excited for it. Don't have too much +else to add. + +**Rodolfo Novak**: Yeah, same. + +_Core Lightning #8140_ + +**Dave Harding**: Yeah, okay. Great. And now we have five PRs from CLN. The +first one of these, Alex I think has already been talking about. It's Core +Lightning #8140. It enables peer storage of channel backups by default. Alex, +you want to say anything more about it? I know you already said a bit. + +**Alex Myers**: Yeah, I guess I already talked a bit about peer storage and the +emergency recover feature. I guess the only other thing to add is that it's +really nice when we have new features like this. I can actually search through +all of the public node announcements and see which features are offered by the +nodes. And so, I can use this one specifically to see how many people are +running the latest master or RC and testing that out. So, working on this +release cycle, we try to give a couple of weeks of testing before we finalize +the release. And sometimes, I've wondered in the past how many people -- I know +there's at least a few crazy people that run master or that want to be on the +bleeding edge and test out these latest features. But because we have that +privacy guarantee, you can't really know for sure who all is running which +software. Actually, now though we can, because when you set this new feature +bit and you look at it in conjunction with the other features that CLN supports, +you can actually tell, I can see that, you know, 12 people are out there running +the RC or master right now. So, that's also like really convenient for me +personally. + +**Dave Harding**: That's great, that's great. Actually, that reminds me of an +earlier part of our conversation, we were talking about how many people use +Bitcoin Core. And every once in a while, Bitcoin Core changes the features its +wallet uses. So, it'll start opting into RBF, or whatnot. And I think the last +time they did that, it was only about 6% of all transactions were created by +Bitcoin Core, which is higher than I would expect. I suspect a lot of those are +services using Bitcoin Core. I know like Eclair uses Bitcoin Core in the +background, other stuff like that, but still it's really impressive. + +_Core Lightning #8136_ + +Okay, our next one here is Core Lightning #8136, and our description here says, +"Updates the exchange of announcement signatures to occur when the channel is +ready, rather than after six blocks". And my understanding of this is the two +participants in the channel are exchanging their announcement signatures right +away now. But you still can't announce it to random peers, your other network +participants, until six blocks. + +**Alex Myers**: Exactly, yeah. So, I think Eclair pushed for this update to the +spec. So, this is for your channel announcement when you're ready to send it +out. But the channel for most implementations has already been usable for +several blocks. I think three is a common number. You can actually configure +this yourself in your config file. But just from a state machine level, it's +easier to reason about if we say, "Hey, this is sufficient depth for us, I'm +willing to exchange signatures". From the protocol standpoint, you still have +to wait for the standard six blocks before you can relay the announcement. So, +yeah, that's just a clarification there. This particular PR, though, it was +really nice to rework our state machine, and there's like a lot more assurances +that the state transitions are all correct. So, yeah, I think there's some +benefits to the codebase there as well. + +_Core Lightning #8266_ + +**Dave Harding**: That's great. Core Lightning #8266, it adds an update command +to the reckless plugin manager. I think you've also talked a little bit about +this. And I would just quickly add that I think that's wonderful, because once +you have more than two plugins updating them seems like a huge pain. Do you +have anything else you want to add about that? + +**Alex Myers**: No. I'd love more people to test it out and see if there's any +edge cases that I missed, that sort of thing. But no, it's really satisfying to +run it and just go through all those plugins, and the node works. So, yeah, +give it a try. + +**Dave Harding**: Our notes here say you also extended the install command from +reckless to take a source path or a URL. So, people who want a plugin that's +not in the registry, I guess, can also now get it. + +**Alex Myers**: Exactly, so if you have a local source, so this is the thing +that I wanted as I was tweaking this historian plugin, I've got a local copy, +and I want to test out these changes. So, I can just reckless install and parse +the path in it. It kind of infers the name, so you've got the directory name +for your plugin, but then you've got the entry point, which is the executable +that you're actually going to run. So, reckless does some things to infer what +the entry point is from what's in that directory. But yeah, it's just one more +quality-of-life feature to make it a little bit easier to test things out. + +**Dave Harding**: Right, great, and I know you guys have been building CLN on a +very plugin-heavy design. It didn't used to be the case, but maybe three or +four years ago, I guess Rusty and Christian started to really use plugins, and +now you guys are doing everything as plugins. + +**Alex Myers**: Yeah, exactly. They're really first-class citizens, and yeah, +you can really extend what's possible through the use of plugins. So, yeah, I +don't know, I'm always excited to see new plugins. Interestingly, one of the +ways that I've seen this feature used, reckless, and I've got a lot of feedback, +is there's a guy who's got lnplay.live. And it's a way that you can spin up a +bunch of LN nodes on a test network or just a local network. But you can +basically demo everything. And he's integrated reckless so that you can use it +by RPC to install and try out new plugins and see what happens. + +_Core Lightning #8021_ + +**Dave Harding**: Nice. Moving on to our next item, we have Core +Lightning#8021. It says, "Finalizes splicing interoperability with Eclair". +So, I guess this is Dusty's work, and with compatibility with Eclair, it's +eligible for spec inclusion now, I believe. So, that's really exciting to have +years of work hopefully getting to the spec. + +**Alex Myers**: Exactly. Yeah, and it's difficult because that PR in particular +was such a moving target. There was just a lot of things that we didn't know +were missing. So, it'll be really nice to see that slow down and then get +merged. So, this one also allows you to RBF a splicing transaction. It doesn't +have a great user interface for that, but basically if you try to perform a +splice on a channel with an existing splice, it creates an RBF transaction for +the first splice, and you can just kind of chain these together. It keeps track +of all the state on the back end, and it's got to be a little bit wild how it +does it. But yeah, it's impressive. + +**Dave Harding**: That's great. I really like splicing. Users are going to +love it. I think they already love it because they're using it with Eclair now. +I think Eclair has it on by default for people who are using it. + +**Alex Myers**: Exactly. Yeah, Phoenix wallet users. + +**Rodolfo Novak**: For the privacy, it really is nice. + +**Dave Harding**: Yeah, the privacy is nice too, that you kind of get that same +thing we were talking about with payjoin and with dual funding. For splice-ins, +you get the heuristics there. And for the splice outs, I guess you can get +privacy there too because you're spending from an LN channel, and that might not +be clear from a heuristic standpoint. I'd have to think about that harder. But +for the splice-ins, it's very nice. You get that same benefit. + +**Rodolfo Novak**: Yeah, for the inwards, yeah. For the out, I mean it really +depends on your trade model here. I mean, if you're not like trying to fight +like a state actor somewhere, you're just trying to find some privacy against +vendors, or whatever, it's a huge improvement. + +**Dave Harding**: That's great. And again, glad to see it get closer to +eligibility for spec, or at the point of spec inclusion probably. So, hopefully +the other implementations will agree that it's good to go and it will be in the +spec. And again, we saw earlier that LND is making some progress with the +support of quiescence to get it into their implementation too. And again, I +believe LDK has done some support work as well. + +_Core Lightning #8226_ + +And then, our final item here, which we also have talked a little bit before, +it's Core Lightning #8226. It implements BIP137, which is kind of a +documentation for the traditional signmessage protocol, although I think it's +got some tweaks to it over what Bitcoin Core implemented way back in 2011 for +the first time. So, yeah, Alex, tell us about signmessagewithkey. + +**Alex Myers**: Yeah, well this was just a user-requested feature, or a +downstream implementation requesting this. I think it was, again, Ocean Mining +that would have found this useful for users to basically use a public key and +basically be able to sign messages that way. And I think it follows the +Electrum standard, which is kind of the most widely adopted one. But yeah, +testing this out with Sparrow, you can use this RPC and it'll validate your +signed message. Previously, if you wanted to do the same thing, it was a long +chain of events of installing additional libraries and external RPC calls, and +everything. So, yeah, I hope this solves some problems for people. + +_LND #9801_ + +**Dave Harding**: Yeah, that's great. And our final PR is from LND, this is +#9801. This adds a new default option. It's --no-disconnect-on-pong-failure. +So, LN nodes can send, and I think the recommendation's every 30 seconds, a ping +between themselves, just to make sure the other peer is still connected, because +you don't want to start trying to send forward a payment to a disconnected node. +And the reason for that is once you try sending that payment, you kind of have +to assume the other person received it, even if they don't confirm that they +received it. Once you send it out there, you have to act like that happened and +you might have to force close. So, if they go offline, well, nothing is +happening. You can just let them sit offline for a long time. If you don't +have any pending payments, you don't care. It's just a matter of eventually, +you might want your money back to open a new channel. But if there are pending +payments, you might be forced to force close a channel within a relatively short +amount of time. And so, you don't want to send a payment to somebody that you +know is offline, because again you're going to have to assume that it went +through. Because if they did see it, they could steal money from you if you +don't make that assumption. + +So, again, LN, the nodes, they send ping messages and they reply with pong +messages. And this is LND adding an option that says they're not going to +disconnect the peer if they receive a late pong message, or if it is somehow +corrupted. And the justification of this in the PR is that we're just having +some people with problems with this. They say that sometimes the TCP channel +gets backed up or something. I don't know. And so, they've added this option +for people who don't want to disconnect their peer. And I guess you're going to +see that some LND nodes have thousands of channels, and I can see how that could +be a problem. If you have a brief delay in your connection and you disconnect a +thousand channels, reconnecting them could be a major pain. So, I'm guessing +that's what this is here for. + +I don't think it worries about the safety guarantees, this is not going to +change the safety guarantees in the sense that if you do send a message to a +disconnected channel and you didn't know it was disconnected, you're just going +to have to force close that channel later on. So, there's a bit of a trade-off +here. But if you're an LND node, you can run this option. It's not going to +change your safety guarantees, it just might change the number of force closures +you have. And it's probably something that they'll just default off. They're +going to test in practice. So, I think it's good. Any comments, Alex? + +**Alex Myers**: Yeah, I think the vast majority of users won't really need to be +concerned with this setting. But it's one of those that if you need it, you +probably really do need it. So, it's nice to have it available. It's also +probably nice, we've got a number of features that I kind of don't know how much +use they get in the real world, but for our black-box CI testing, some of them +are really useful to have in trying to recreate problematic scenarios and just +trying to debug. So, it's one of those that I like to see that sort of +configuration option available. + +**Dave Harding**: Yeah, and that brings us to the end of the newsletter. Any +final comments Rodolfo, Alex? + +**Rodolfo Novak**: Not really, man. It's fun. Learned a lot about Lightning, +new stuff that I haven't heard in a while. You can find me on the +bitcoin.review pod and the stuff we make. + +**Alex Myers**: Yeah, I mean it's nice to see people building things. I don't +think the pace has slowed down by the length of the newsletter. So, yeah, +thanks for letting me review it with you. + +**Dave Harding**: Thank you. Thank you both for joining me, I learned a lot +too. So, have a great day and to our audience, you all have a great day too. + +**Alex Myers**: All right, cheers. {% include references.md %} From fa39ef4d97d215edfdd5df32ae72553c8e0ee687 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 19 Jun 2025 11:42:07 -0500 Subject: [PATCH 112/278] Podcast: add 356 transcription --- .../en/podcast/2025-06-03-newsletter-recap.md | 988 +++++++++++++++++- 1 file changed, 987 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-06-03-newsletter-recap.md b/_posts/en/podcast/2025-06-03-newsletter-recap.md index 7c3c143ddd..6849e53a4a 100644 --- a/_posts/en/podcast/2025-06-03-newsletter-recap.md +++ b/_posts/en/podcast/2025-06-03-newsletter-recap.md @@ -19,6 +19,992 @@ Jager, and Elias Rohrer to discuss [Newsletter #356]({{page.reference}}). ## Transcription -_transcription coming soon_ +**Mike Schmidt**: Welcome everyone to Bitcoin Optech Newsletter #356 Recap on +Riverside. Today, we're going to be talking about whether attributing LN +failures is bad for privacy; a bunch of Stack Exchange questions, a lot of them +about the Bitcoin P2P Network; and we have our regular Releases and Notable code +segments as well. I'm Mike Schmidt, contributor at Optech and Executive +Director at Brink. Murch? + +**Mark Erhardt**: Hi, I'm Murch. I work at Localhost Research. + +**Mike Schmidt**: Carla? + +**Carla Kirk-Cohen**: Hi, I'm Carla, I work on Lightning Protocol at Chaincode +Labs. + +**Mike Schmidt**: Joost? + +**Joost Jager**: I'm Joost, I work on Lightning Development at Spiral. + +**Mike Schmidt**: Elias? + +**Elias Rohrer**: Hi, I'm Elias, I work on LDK and back in 2020, I authored a +paper on Lightning privacy. + +_Do attributable failures reduce LN privacy?_ + +**Mike Schmidt**: Awesome. Thank you, three special guests, for joining us. +You are all three going to contribute to our news item this week, which is, "Do +attributable failures reduce LN privacy?" Carla, you posted to Delving a post, +actually about being nerd-sniped after an LN spec meeting. It sounds like you +dove into some of the interplay between attributing these failures to privacy, +so the interplay between these two things. Maybe before we jump into the +privacy implications, can you or one of our other esteemed guests explain, what +are attributable failures in LN and why would we want them to begin with? And +then, we can understand why they're there and then what the implications are +from a privacy perspective. + +**Carla Kirk-Cohen**: Sure, I think I'll swing that to Joost because he's the +author of the PR. + +**Joost Jager**: Okay, I can comment on that. So, attributable failures, the +word already says it. Currently in LN, there are non-attributable failures. +So, if you have a multi-hop path, it is possible for a node to return basically +garbage data to its predecessor and they do all their transformation, +encryption, etc, etc. But when it ends up at the sender, the sender is just not +able to make anything of it. So, they know that the HTLC (Hash Time Locked +Contract) failed because it was released, but they don't know where the failure +happened. And the problem of that is that they also cannot apply a specific +penalty to the node where it failed. So, there's multiple ways to deal with +that. Some nodes, they just penalize the whole path, but if you do that, you +quickly run out of nodes. + +Yeah, that is the problem, it has existed forever. It's not widely exploited, +but could be in a way. Routing nodes could, for example, use this to hide +themselves if they have no liquidity, and then just return random data and then +hope the penalty will be less than when they would have honestly reported what +the problem was. So, that is attributable failures. It adds something to the +messages being passed back so that even if one of those nodes returns random +data, the other ones put HMACs (Hash-based Message Authentication Code), so sort +of like signatures on them to allow the sender to identify why the corruption +happened. And then, when we were getting those nodes to do something more +sophisticated with the failure message anyway, the idea came up to then let them +also add a bit of data into it while they're at it anyway. And that data is the +HTLC hold time. So, nodes on the path, each is going to report how long they +held the HTLC. And this can help the sender to identify the fast nodes and +possibly prefer those in future pathfinding. So, it's two features bundled +together just because they affect the same area. + +**Mike Schmidt**: When reporting the time that they held the HTLC, is that +something that is verifiable, or is that just gentlemen's agreement? + +**Joost Jager**: It is verifiable to the point that the sender can take their +own measurements, so they know for sure how long the HTLC was in flight. And +then all these nodes, they report how long they held it, so there is an upper +bound to that. And it is in each of these nodes' interests that the sender +applies the penalty properly. So, they apply either to the incoming or the +outgoing side, and it's in their interest so that it is as realistic as +possible, because if they would report different times, they can report whatever +they want obviously, it's a voluntary thing. It could be that one channel is +penalized, which they don't want, because that is not the slow channel; the fast +channels could be penalized. So, the idea is that there is some game theory +around it that makes all these nodes report the actual hold time. + +**Mike Schmidt**: Okay, great. Now we have a little bit of background of why +these things are being worked on, why there's value in attributing these +failures or delays as well. What's the downside? + +**Joost Jager**: I'm going to hand over to someone else, I think. + +**Carla Kirk-Cohen**: Yeah, I can pick that up. So, the reason this Delving +post came about is that we kind of got all the way to the end of the cycle with +attributable failures. They're implemented in Eclair, they're implemented in +LDK, they've achieved interop, the spec PR is pretty close. And when we +discussed merging it, this concern about how these reported hold times would +affect privacy on LN came up in the spec meeting. And the question was, "Should +we report exact hold times or should we change the way that we encode these hold +times, so that we can protect some minimal amounts of latency on the network?" +So, instead of saying, "I held this for 3 milliseconds, I held this for 5 +milliseconds", you'd say, "I held it for 100, 200, or 300 milliseconds", so +change that encoding to be buckets of time rather than an exact period of time. + +The reason given was that we need to have some degree of forwarding delay in the +network. So, when you receive an HTLC, you don't just send it on immediately, +you actually hold it for a small period of time to help protect the privacy of +the network. And I was really interested in this because I'd kind of never +heard of it. And we threw out this 100-millisecond value, which was a very +upsetting thing to me, because I don't like randomly hand-waved numbers. So, I +kind of fell down this hole of reading a bunch of papers and really trying to +come to understand the different types of privacy. I wasted a week, well, +debatably wasted, but I spent a week on it. Now, I seem to be consuming +everyone else's time with it, so it's a very efficient nerd snipe. + +But the idea is that attackers can try to watch payments flowing through the +network, either as an LN node who's making a forward, or as a higher-level +network attacker, someone who's actually responsible for transferring the +messages of the internet layer that the LN exists on top of. And there's +various types of attacks, which maybe we can get into in more detail, where the +timing of payments plays a role. And the concern is that, well, if we just +trivially report everyone's latency, it makes some of these attacks easier to +do. + +**Mike Schmidt**: Carla, you outlined the two types of attacks that we +highlighted in the newsletter. One was an attacker operating one or more +forwarding nodes, and maybe a more sophisticated high-level attacker that's at +sort of the IP network level observing some of these attacks, is that right? + +**Carla Kirk-Cohen**: Yeah, that's right. I think I'll throw it to Elias to +talk about the idea of an on-path attacker because this is where he wrote his +paper and it's really nicely explained there. So, he can walk through on-path +and then I'll chat a bit about off-path after that. + +**Elias Rohrer**: Cool. Yeah, so the idea of an on-path attacker is pretty +simple. And by the way, it doesn't have to be a forwarding node, it could be +actually the sender, because in the post-BOLT12 world with blinded paths, we +actually have something to protect there, because the sender doesn't always know +the receiver. That wasn't the case when we wrote that paper back then. So +basically, the attacker model was a forwarding node on the path that is chosen +by the sender. And the idea is there that as a first step, basically, the +adversary would create a timing model of the network and basically would measure +out in some way how the hops are interconnected, how long it would take to route +over a certain route. And you can create arbitrary large datasets by probing, +or there comes the first aspect of attributable failures. In the current +proposal, a potential adversary might get these timing measurements for free by +these reports, that is one part of it. And then, based on this timing model, +they could then, when a payment is forwarded over them, take a measurement of +the time from actually sending the updated HTLC message, so the HTLC forward +out, and then receiving a fail or a fulfill message for that message. And by +doing that, they could learn basically how many hops, or according to their +model basically, how far they are away from the receiver, or according to their +probabilistic model, would do a maximum likelihood estimation, what is the +likeliest endpoint of that payment that was just forwarded. So, that is the +idea of that attack essentially. + +We could show that under certain circumstances, that actually works rather +nicely, and then proposed that forwarding delay would be one vector of +mitigation that we could take to mitigate that attack. + +**Carla Kirk-Cohen**: And just to add a little bit on that we spoke about in +this post, I thought it was interesting that we're using a forwarding delay here +because really, the person who is most incentivized to look after their privacy +is the receiver. But here, you're relying on forwarding nodes to do that for +you, right? And not only are you relying on forwarding nodes, you also, as a +receiver, don't really know how many hops the sender took to reach you. That is +by design. And this kind of delay only works, I hope I've explained this well, +but if you add on sufficient latency that when that attacker goes and looks at +their latency model, they think, "Oh, this person could be two hops away or they +could be three". It creates an anonymity set by adding this latency ambiguity. +And if the sender happens to be one or two hops away from you, say it's the +sender, one node, and then you, you're not actually able to add enough delay, +because maybe each of these forwarding hops is adding a little bit, but when it +reaches you on a shorter path, it doesn't really add up to something that +creates that ambiguity for the attacker, right? + +So, one of the things that's come out of this, I think we spoke about this +yesterday in our latest spec meeting, is the idea of shifting this delay to the +recipient who is much more incentivized to actually hold onto the HTLC, even +though it means there's the tiny possibility that they might have to deal with +an onchain event or their peer going offline. It seems much more reasonable for +that person, who cares about their privacy, to be the one to hold onto it. And +Elias has just opened up a draft PR to the spec with some recommendations so +that we can think better about that on-path case and have better privacy for +receivers who choose to add that delay. + +**Elias Rohrer**: Yeah, so the idea of that PR is that the receiver could take +basically the large part of that delay and could also make better estimations +how much delay there needs to be, because it's added once basically or the +largest part once. And then still, we probably need some forwarding delay, some +randomized delay there, for the other attack model that we get later, but also +generally it's still good to introduce some noise into the network in general. +And by the way, it's not only good for privacy reasons, but basically any LN +node does batching of HTLCs and some kind of batch delay anyways for +I/O-efficiency reasons basically. + +So, the idea of that is basically, if we add the most part of that delay on the +receiver end, we can reduce the forwarding delay that needs to happen in the +network a bit, but we still want to keep the incentive there to actually add +some forwarding delay, because for at least for the other attack model, we need +that, and also for the on-path attack in some cases. And that is maybe how the +second part, where this relates back to attributable failures, because the +discussion was mostly around, do we want to incentivize basically dropping any +forwarding delay, or should basically that attribution, when it reports back +forwarding delays, should there be a threshold or some kind of bucketing so that +you would only report forwarding delays over a certain threshold to essentially +allow forwarding nodes to still apply some forwarding delay without fearing to +be penalized for it. That is basically the discussion that arose. + +**Mike Schmidt**: It's amazing how complicated something that's seemingly +straightforward, do it as fast as possible, LN is fast payments. But yes, +there's always trade-offs. I guess the trade-off here a bit for the end user, +is it going to be even noticeable, these additionally-reported delays, or do you +think from a UX perspective it's not noticeable? + +**Joost Jager**: It depends on how much we're adding. First we talked about, I +think, 100 milliseconds, but yesterday it was more like 400 milliseconds. And +if it's a per hop, then yeah, it might be noticeable. And for me, it is also +important to keep in mind that the future might be different. Maybe some use +case emerges where people just want to have like a 50-millisecond payment for +some reason. Yeah, I feel strongly about not adding constraints to the protocol +to make that impossible to measure. I think that is what we're talking about a +lot, like does it actually matter to have this thresholding; will people notice; +what does it mean for the future? + +**Carla Kirk-Cohen**: I can give a few numbers that we threw around in the spec +meeting yesterday. So, a very badly researched number that represents the +amount of delay you can have before the human eye actually notices that +something is a delay is around 100 milliseconds, which is a pretty small number. +Yesterday, someone threw out that tap-to-pay takes just under a second right +now, or when it originally rolled out rather, but I haven't looked that number +up, so take it as you will. But in LN, we need three round trips to add and +remove an HTLC, so to do the whole update_add, and send a commitment signature, +and then do the same on the way back and revoke everything; we need three round +trips, three networking round trips. + +These are kind of hand-waved numbers, but I think it's reasonable to say that a +very good latency is 15 milliseconds, you're co-located in a data centre in the +same place; a reasonable middling latency is maybe 50 to 100; and then, if +you're running on Tor, you're looking at 300 to 600 milliseconds, and that's per +round trip. So, this is something I realized looking at this, that this +100-millisecond number isn't real for us, really. Three round trips, even at +the fastest, fastest latency, that's like 45 milliseconds, that's for a single +hop, right? So, the minute you have a two-hop payment, which hopefully, most +payments in LN aren't just a single hop, there's not much point to that, you're +already starting to hit that 100 milliseconds. And then, if you have regular +nodes that are not in the same physical location, think about 50 milliseconds +round trip, that's 150 per hop. So, even me sending to Mike, if my node's in +Europe and yours is in the US, we're done, it's over 100 milliseconds. + +It's not very clear to me what that number should be, which makes this kind of +difficult. We can't really say what is latency that people will care about. Is +it just as fast as possible; or is it like, this isn't the Visa network and we +need to pick a more reasonable value? But I think this whole discussion, it's +just very difficult to design protocols for people that you don't really get +feedback from, and you can't. And, as it turns out, I'm sure the Bitcoin +developers are pretty familiar with that, but we kind of have this back and +forth of like, "Oh, privacy loves a crowd and we need to design for privacy". +But what if one user wants really fast payments? The answer is we don't really +know. So, how do we design the best in between, which is conscious of privacy, +but also doesn't restrict use cases? + +I think Joost's comment that he doesn't want to restrict the protocol, that is +that if we go with this block encoding of, say, 100, 200, 300 batches, which +probably isn't the number we'll use, but to roll this out on the network, we +would deploy this, people would have to upgrade their nodes to really use this +feature properly. Every single node in your route has to be, well, not +everyone, but you want your full route to upgrade. And it's really not trivial +to change once we've deployed it, I think. We'd have to add a feature bit, we'd +have to change the TLV (Type-Length-Value), we'd again have to go through this +spec review writing process, everyone has to upgrade. This is a thing that +would take realistically two years to happen, so we do want to try and get it +right now. But what right means is difficult to say. + +**Elias Rohrer**: So, on what you just said about having no feedback from users, +the issue with privacy is of course always that privacy and security, users +don't care too much about them or even see them as a hindrance in their UX, +because it slows things down or, I don't know, they have to enter passwords and +everything is annoying, until they're gone and they have severe consequences. +And privacy in particular is this hard thing, because you can't really measure +it until you basically see the consequences of the anonymization attacks a few +years down the line. I mean, there are well-known examples by this where, +before they happened, you wouldn't have thought, and then the whole Snowden Five +Eyes revelation thing comes around and you're like, "Wow, this is not +tinfoil-head material, this actually happened. And this kind of example happens +over and over again. That is why it's always hard, basically, to argue also for +privacy preserving technologies, because it's essentially hard to estimate how +much protection you need until you actually know that that you failed at some +point. + +**Mike Schmidt**: I have a question about, we talked about the end users and +it's hard to get feedback from them. One constituency here are also the routing +nodes and I'm curious, I don't run a routing node, so does the topology of the +network change with this sort of introduction of additional latency, or is that +a non-factor for those kind of people? + +**Carla Kirk-Cohen**: I think Elias has made the very good point earlier that +for some nodes, you will already want this type of batching, because every time +you add an HTLC, you have to write to disk in LN, so you remember your latest +state and all your signatures, and everything like that. So, if you're a node +that has HTLCs flying through you, you're probably going to have batching +anyway. Right now, I think LND has 50 milliseconds. So, if an HTLC arrives, it +starts a timer of 50 milliseconds. If a few more arrive in that time, they'll +all be sent out together once the batch is through. But if nothing arrives in +time, it's just the single one that goes out. So, for very small delays, people +do have some incentive because they want to batch anyway. You don't want every +single payment just writing to disk and wearing out your hard drive. But for +larger values, it's less clear. + +This is also another concern that if we create this market for LN fast routing, +is everyone just going to go and patch their LN node and turn off any sort of +privacy preserving delay? Because it is something that we're saying, "Hey, you +should be doing this", but even leaving pathfinding totally out of it, if you're +an ultra-competitive LN routing node, maybe you just want to turn this batching +off so that stuff clears as fast as humanly possible and you can have the best +return on your capital. I don't think we're necessarily there in terms of +volume right now, but it is a difficult thing of like, this is a public good, +right? Privacy is a public good and forwarding nodes would need to not turn off +that public good for these things to work. + +**Elias Rohrer**: Yeah, and so the discussion around that, especially given that +the default on LND is a fixed 50 milliseconds, it could be argued that this is +not too far off. So, if they were to make that randomized and maybe 50 to 100, +or something like that, that could be good enough if we also add receiver-side +delays, which LDK already does. So, the discussion is not so much, do we want +to tremendously slow down LN more than it already is? Basically, it's more +about adding a bit more randomness, and then the discussion about attributable +failures is, do we want to create that incentive to push that number down over +time, or is that kind of dangerous because we want to encourage maintaining this +forwarding delay basically? + +**Joost Jager**: Yeah, I think something I wanted to say about all this is also +that what we're trying to do or what is being proposed is to push something onto +users through code or through the protocol that they may not want, so trying to +come up with an encoding that doesn't allow you to encode very low values. And +I have severe doubts whether that will actually succeed in the long run, because +it does resemble to me the whole OP_RETURN thing and the filtering. + +**Mike Schmidt**: Don't say it! + +**Joost Jager**: I do want to say it, yeah, I think it's very similar. It's +like trying to accomplish something through that, but there's also workarounds, +and is this a winning strategy in the end? And in particular in LN, I think, if +you have a way to maybe in a way invite adversaries almost, like let's say we +would do this, we would be totally transparent about latency, it becomes easier +for people to build that latency map, and then we might have a problem. And if +there's a problem there in terms of privacy, we might try to solve it. Whereas +if we now just put some tape on it, just do a bit of rounding on the whole times +and move on with the next, more exciting LN topic, maybe it's also a missed +opportunity to fix this in the early stages, and we run into it again at a later +stage, and might regret that we haven't been so inviting from the very start. +And I see the analogy with hodl invoices. They were also a topic of debate when +we were working on that. People didn't really want hodl invoices because it was +bad for the network. But in the end, it could have been done always and +probably would have been built in by users themselves, because it enables cool +use cases. So, also there, I thought it was much better to just be open about +it, just add it, let them do whatever, and if it's a problem, then fix it in a +more robust way. + +**Carla Kirk-Cohen**: And I'll spend three years working on that, fixing it in a +more robust way! + +**Joost Jager**: Yeah. I think here actually, there's a word for this, like in +biology, where continuous stress makes stuff stronger. I think we're not in the +stage where we should avoid stress because now it's still fairly small. And +this looks like a great opportunity to find a better way to combine very low +latency with privacy. And I don't know what the solution looks like, but to me, +this type of filtering is not it. + +**Carla Kirk-Cohen**: It definitely stood out to me, reading through all of +this, that we actually do need to know more about the off-path case, right? +Because I'm pretty satisfied, and it seems to be rough-ish consensus in +yesterday's meeting, that if we add these receiver delays, we should be okay, +more or less, with the on-path case. But the off-path case is a lot more +nebulous and less understood to me. So, I think I can back it up a bit and talk +about how that works, because we haven't really covered it, and then maybe go +into it a bit. But the idea of the off-path case is you have someone who can +see the messages that you send over the internet, right? Typically, this would +be a malicious, autonomous system who's part of the infrastructure of the +internet. And I think the paper I read, something like 70% of the LN is in the +top five autonomous systems. So, we're relatively centralized on the internet +layer. I think Bitcoin has looked at this as well in the past, but as much as +we call ourselves protocol developers, we actually exist on top of another +protocol. + +So, if we have this surveilling entity that's sort of on that layer, on the +internet layer, what they do, instead of forwarding HTLCs, is that they look at +the messages that LN nodes are sending each other. And right now, those are +very identifiable, because we don't pad our messages. So, the commitment dance +of a few messages going back and forth, you see 1,400 bytes going this way, then +you see 900-odd going that way, and it's an incredibly identifiable dance, +right? And you're sort of this top-layer network adversary who sees me and +Murch do that dance, and then I turn around and I do it with Elias, and Elias +turns around and does it with Mike. And it's very clear to this person that +this HTLC has moved through the network. And I'm not totally sure about this, +but even when we do add padding, so say all of our messages are the same size, +there's still this really distinct direction that these messages flow in. So, +it's really challenging to hide this from a very high-level network adversary. + +The one way that you could do that is through something called constant bitrate, +which is essentially, we're always sending messages to each other and half of +them are fake all the time, but that's incredibly bandwidth expensive, right? +So, that's probably not something LN would do, I would think, but tl;dr, it's +very difficult to hide those messages from that kind of adversary. And in the +attack that I looked at very specifically, what these adversaries would do, it's +actually really cool, is you find these chains of HTLCs and you're not seeing +the whole payment, but you are seeing all of these chains of messages sort of +ticking through the network, right? And you use those to establish sort of a +start and end point of your route. And you do some clever efficiency steps to +wipe out nodes that couldn't possibly have sent this payment. So, like, if the +minimum value sendable is bigger than someone else's channel, you know they +couldn't possibly have used that channel. And then, you take your individual +path that you've observed on the network and you run pathfinding between every +single node on every single other side. So, you do tons and tons of using the +exact pathfinding that LND would have used, for example. And then if you do +pathfinding between here and here, and the path doesn't go over the route that +you observed, you throw those people away. And because our pathfinding is very +deterministic, you're able to identify a sender and receiver almost through +their pathfinding rather than through this incomplete path. + +This paper does note that if we had a bit more chaos in our pathfinding, so if +between two nodes, we'd return different paths every time, this reduction of +that anonymity set would be much more difficult, because they say, I think the +medium size of those anonymity sets was around 10,000. So, they really have to +do a lot of work with laying that down from 10,000 to a smaller number. And +this is the one network level attack that we know of. I think what was pointed +out yesterday is that even though this is -- because my feeling was like, "Oh, +well, this attack very specifically depends on pathfinding". So, if we were to +make much more privacy, where it changes to our pathfinding, maybe it wouldn't +matter that people can create these chains so much. But I've kind of come +around to the opinion raised yesterday that just because this one paper has this +one technique of taking these partial paths and doing a de-anonymization step, +it doesn't mean that there aren't others. It just means that that paper hasn't +been written and we need a bit more research into these types of attacks to +understand them. + +So, it seems to me that if people are able to make these chains, they probably +can do some funny privacy things, but we have no idea what those are right now. +And where the timing feeds back into this, I think, is that when you have that +high-level network adversary, if you have batching, more than one HTLC will be +moving at a time, ideally. It's like, okay, you send this and you wait 50 +milliseconds, and in that time another one arrives, and then they split out at +the same time. And so, you're much less capable of seeing this sort of ding, +ding, ding through the network without forwarding delays, because it's so +instant that you can just trivially see it. + +What I think is really difficult here is that the batching delay that you need +depends on the traffic that you have. If you have tons of HTLCs arriving all +the time, then it matters much less, because you're covered by all this traffic +going everywhere. But if you route HTLCs once a day, if you route one payment a +day, there is no delay that will help you, because it's just a single packet +without cover traffic or something made up to protect you. + +**Mark Erhardt**: Yeah, I think you mentioned something similar before with +decoy traffic, but what if there were a modicum of decoy traffic? Every time +you receive an HTLC, you send out packages to two other peers, so it's at least +1-of-3, giving it sort of an exponential growth; and if you get a decoy package, +people throw out one or two decoy packages to others? Is that +bandwidth-prohibitive, or have you considered that? + +**Carla Kirk-Cohen**: I don't know. Honestly, right before this, I was trying +to remember what was wrong with Dandelion on the Bitcoin layer, because I'm +like, "Can we have, like, DandeLightning? Maybe that would work, and it just +spreads out and provides a bit more cover without too much bandwidth use. But I +haven't thought about it more than the five minutes before this call. + +**Mark Erhardt**: Yeah. So, Dandelion, the problem was that you behave +differently whether you have heard the transaction in your regular mempool, or +if you've heard it over Dandelion. And it would basically mean that you need to +keep track of all of the transactions that you've heard about via Dandelion for +each peer, which would mean that you basically multiply your mempool size, +because you need to have a private mempool for every peer that you have, in +addition of your regular mempool. And it opened up a dust surface. But here, +we wouldn't have that problem, because we actually are routing only on a single +path. So, we would only need to retain the information in that one direction. + +**Elias Rohrer**: Yeah, I think the first step for mitigating this is actually +message padding, which we definitely should do, hopefully also soon. I think +that there will be some research going on how much message padding or what the +best approach to message padding is. So, do we need to pad all messages to the +same length? Is random padding enough basically, and also exploring how much +traffic overhead will there be just from introducing message padding? That's +the first thing, so that an adversary that can only see the message; packet +sizes can't infer the message in the encrypted packets. And then, the next step +after that will be indeed to explore if some kind of cover traffic basically +will be reasonable. I mean, if we already do batching, for example, in LND, it +would make sense to even talk about that. I mean, these basic concepts have +been studied very, very well in the whole Mixnet literature, with different +Poisson mixing and time-mixing approaches, like Loopix, and so on. So, I think +there could be a lot of lessons that we could learn and just take from that, +basically. + +But yeah, I think the first step will actually be message padding, and then see +how much traffic increase that will already introduce. + +**Carla Kirk-Cohen**: Do you think that with message padding, we're in a better +place in terms of the direction of those messages, because I fielded that also? +One of the papers hinted at the fact that even that might be enough. + +**Elias Rohrer**: Yeah, I mean, yes. So, this will be an issue. I think we're +like, if you can't really discern which types of packets you're seeing as an +adversary and they look all the same to you, it will be quite a bit harder for +sure just to classify them. But yes, you could still see -- I mean, what the +adversary sees is always a three-tuple, right, a sender, receiver, and basically +payload length or encrypted packet data, basically. So, if you see then bursts +of messages going one way or just a specific exchange of commitment sign, revoke +and ack,, could leak some information, but then again a single HTLC handshake +might not be the only thing going on, even over a single connection at any given +time. So, just having some additional noise in there, some pings going on, some +gossip being propagated, whatever, could be enough to really throw off, +hopefully, some of these heuristics, but we really don't know how much +mitigation we have. And if we would, for example, add some additional pings, +that might be already enough once we have message padding. I shouldn't say +'enough'; might go a long way, because we don't know what adversary we're +talking about basically. + +**Carla Kirk-Cohen**: I'd imagine also, once you have padded messages, it makes +covered traffic way easier, because just a few things could throw off detecting +that dance. + +**Elias Rohrer**: Yeah, or put it differently, if you don't have padded +messages, there is no reason to even start adding cover traffic. + +**Carla Kirk-Cohen**: Correct, yeah. + +_Eclair #3065_ + +**Mike Schmidt**: Any other follow-up questions or discussion for the group? +There's one related PR from later in the newsletter, but it's just tangentially +related. It's Eclair #3065, which adds support for attributable failures, which +we just spoke about in the news item here. It's disabled by default because the +spec isn't finalized, but cross compatibility with LDK has been successfully +tested. I don't think anyone is directly involved with that. But I guess maybe +to distinguish, the attributable failures is something that is being +implemented, and the question here is the privacy implications and whether +there's delays introduced, right, which is more of a question mark still? + +**Carla Kirk-Cohen**: Well, right now the Failures PR has these hold times +expressed in milliseconds, so they're coupled. So, the question now is, would +we go back and change the spec and then change both of the implementations and +redo interrupt to have this different encoding on the whole time? And it's +disabled by default because the specification isn't finalized. Interestingly, +sometimes what we do when we're doing interrupt and we're still wanting to merge +things is we add 100 to values. So, we have message numbers and TLV numbers. +And when we're working on stuff and the spec is in process, we'll say, "Okay, +instead of this being TLV number 1, it's TLV number 101", and that gives us a +bit of flexibility of like, okay, once we actually hit the button on the spec, +we can then just switch to a new TLV type, and just throw away whatever maybe +needed to change without needing to do a big migration, or something like that. + +But I believe that isn't the case here. So, it is just using the regular number +and has been merged, but it is off by default. So, hopefully no one runs into +it. But that would be an implementation detail for Eclair, right, that if there +is a big change and they need to handle it, they need to do some sort of +migration. But given that this isn't really widely supported work, I wouldn't +see it being much of an issue right now. + +**Joost Jager**: But it is interesting that they already did the work that they +merged; LDK merged, LND PR is in progress, and there's also something open for +C-Lightning (CLN). So, yeah, there seems to be actually, I would say, a lot of +support for the feature. It's just a discussion about what to do with the +expression of the hold times. That's something to decide on. Yeah, they merged +optimistically with TLV type 1, but of course if this is not what we want, they +can just switch to 3 and then it's fine again. I do remember now where the 100 +millisecond came from, right? This is because it's experimental, isn't it? No, +I thought it was. No, it was the old human eye, but yeah. + +**Joost Jager**: Everything plus 100 now? + +**Carla Kirk-Cohen**: Yeah. + +**Mike Schmidt**: Well, excellent. We will be reporting on any further +discussions on this, I'm sure, in the newsletter, and maybe have you folks back +to discuss further. But it was great having all three of you on. I thought it +was a great discussion, even if Murch and I aren't LN experts, it was great to +listen. So, thank you all for your time. You guys are welcome to hang on, or +free to drop if you have other things to do. + +**Carla Kirk-Cohen**: I'm going to drop. Nice to see you guys. Thanks for the +invitation. + +**Mike Schmidt**: Moving on to our monthly segment on Bitcoin Stack Exchange +questions, we have a handful, a lot of these P2P this month. + +_Which transactions get into blockreconstructionextratxn?_ + +First one, "Which transactions get into blockreconstructionextratxn?" which is +the flag, I believe, for the size of what I've heard referred to as the +'extrapool data structure'. And Gloria answered this one, sort of outlining +that that structure caches both rejected and replaced transactions that the +local node has seen. And she also listed the criteria for exclusion and +eviction from that data structure. I believe it's 100-transaction size cache +with a max size of 100k, and it's a first-in, first-out data structure. Murch, +have you played around with the extrapool? + +**Mark Erhardt**: I have not played around with the extrapool, but I was just +looking a little bit at the code around there. And then, I actually had to ask +back because I wanted to know what the size limit is for transactions that we do +allow in the extra cache. And it turns out that that is 100,000 bytes, which is +actually smaller than the standard transaction weight, and it also doesn't apply +to replace transactions. So, it's a little odd in several ways. So, for +example, big transactions just aren't kept in this cache. It's also only 100. +There were some ideas of people with stricter mempool policies maybe using the +extra cache to retain the transactions, because when you get a block, it does +check in the recent rejects whether transactions are in there, before getting +them again from peers. Well, it's starting to look like you'll at least have to +touch several different spots in the code in order to implement that. + +**Mike Schmidt**: Yeah, I think that's probably why it bubbled up. I believe +some of the pro filter people were saying that propagation wasn't delayed +because the transactions were held but not relayed, which is, I guess, exactly +what this data structure achieves. I guess the question is, based on size and +the limit and the eviction criteria, how useful in a day-to-day operation a +cache of that size would actually be? + +**Mark Erhardt**: I mean, it also stores invalid transactions. So, someone +sending you invalid stuff will also churn this filter. So, since we apparently +have reached a point where node operators are running their nodes in a more +antagonistic manner than ever before, we recently heard that one node +implementation is trying to eclipse another flavor of Bitcoin nodes. I think if +people are starting to rely on this for better block processing, we might also +see someone churn the extrapool. I'm not trying to give people ideas here, +please don't do this! + +**Mike Schmidt**: So, that part stuck out to me, the invalid. So, it would make +sense that I would cache something like a replacement transaction, because based +on the time of when a miner might see something, that might include some version +of the replaced transaction, and I have the one that they happened to see, even +if I saw a more recent one, let's say, that makes sense. And the +restrictiveness on policy also makes sense for the reasons we sort of outlined. +Why would we keep an -- is there an intention behind that, or...? + +**Mark Erhardt**: I'm wondering whether it's only invalid transactions that, for +example, had missing inputs, or something like that, so either because the input +was already spent in a larger transaction that we have, so a double spend would +be invalid if it's not a valid replacement. But other than that, yeah, always +invalid transactions that could never be valid, just it's strange that they +would land in this pool. So, I think I don't understand this spot in the +codebase well enough to explain that better. + +**Mike Schmidt**: One of our listeners after, I think it was you and Sjors, did +the episode that included the OP_RETURN news item. One of our listeners pointed +out that, I think Sjors had said that a Knots node would drop a transaction on +the floor. And I guess correctly pointed out, depending on the size of the +transaction, that potentially it's not dropped directly on the floor, maybe it's +just pushed to the edge of a counter until another few transactions come in, and +then it falls on the floor. + +**Mark Erhardt**: Right, yeah. So, I think I heard some people make the +argument, "Oh, we could just increase the size of the extrapool and then keep a +lot more of these transactions. That way we don't propagate them, we have them +when the block comes in", and that would achieve exactly what they want. But I +would just point out that it was not designed for that. So, if you want to do +that, you might want to design an actual data structure that does this. Or I +think I might just turn off the relay on the transactions you don't want to +relay and keep them in my own mempool. But I guess if you don't want a +transaction in your mempool, that will not solve your problem. + +_Why would anyone use OP_RETURN over inscriptions, aside from fees?_ + +Next question from the Stack Exchange, related, "Why would anyone use OP_RETURN +over inscriptions, aside from fees? Okay, so you can stuff data in the witness +which has the witness discount, or you can stuff it in an OP_RETURN which does +not have the discount. And so, Sjors is sort of taking the fee part of this off +the table. And he explains that in addition to sometimes being cheaper, +OP_RETURN outputs can also be used for protocols that need data available before +a transaction is spent; whereas if you put things in the witness data, that's +revealed during the spending of the transaction. Go ahead. + +**Mark Erhardt**: Also, it depends on what exactly is in the witness data. You +could, of course, make a transaction that is equivalent but has a different +witness structure that also satisfies the input. So, you might not be able to +rely on witness data before the transaction is confirmed. This is not true for +inscriptions, of course, where the output requires the input to be spent with a +scriptpath that includes the inscription, I think. I guess it could maybe also +be spent with a keypath spend. Yeah, right. So, witness data is malleable +until confirmed, whereas OP_RETURN data is assigned by the signatures and +therefore not malleable, assuming the transaction goes through, which of course +would be another way how witness data doesn't become available permanently. + +_Why is my Bitcoin node not receiving incoming connections?_ + +**Mike Schmidt**: "Why is my Bitcoin node not receiving incoming connections?" +another P2P question. Lightlike points out that a new node on the network can +take some time to have its address widely advertised in the P2P Network. I +believe he said that was on the order of potentially hours. And that also, +nodes will not advertise their address on the P2P network until Initial Block +Download (IBD) has completed. So, if you fire up a node, I guess you have to +wait till IBD is done until your address is socialized on the network, is that +right? But, Murch, why would we want that, because isn't that the time where I +really, really want a lot of connections? + +**Mark Erhardt**: I mean, we only download stuff from outbound peers. So, I +think either way, most people will not make outbound connections to nodes that +are not at the chain tip, because they want recent data. So, we're just, at +that point, not very useful to other peers. So, advertising ourselves would +just not really serve a purpose. So, our nodes only advertise their services +once they caught up to the chain tip. + +_How do I configure my node to filter out transactions larger than 400 bytes?_ + +**Mike Schmidt**: "How do I configure my node to filter out transactions larger +than 400 bytes?" And Antoine Poinsot pointed out that there's no configuration +option or command line option in Bitcoin Core to customize the maximum standard +transaction size. So, obviously you could do that in the code yourself and +build that. But he did then went on to outline that if you did want to +customize that in the source code, there's potential downsides for both larger +and smaller maximum value settings. + +**Mark Erhardt**: I mean, you're just trying to make your node worse, I guess. +I really don't understand why you would want to do this. And yeah, I guess it +might be interesting to talk more to this person, because I think there's a +misunderstanding about the goal rather than the approach. So, the main issue +here is, of course, transactions under 400 bytes are probably a small subset of +what we have in our mempool. And if you have a few inputs, you get easily over +400 bytes. I think probably two inputs, three inputs can get you there. And +so, I think they mentioned somewhere that they want to see LN transactions, but +nothing else, and I'm not sure whether LN transactions would always be under 400 +bytes. Commitment transactions are a little more complicated. There's 2-of-2 +multisig going on there, and so forth. Even though the v-size might be under +400 bytes, with the signatures and the witness stack, you could probably -- +yeah, anyway. + +There's a reason why this is not a config option. I don't think it's a good +idea to play around with it unless you've thoroughly studied what you're trying +to achieve. And if your concern really is that you need to keep your mempool +small, but you're reliant on seeing LN transactions, I think it would be more +useful to just use a slightly more powerful computer. + +**Mike Schmidt**: I think I missed the LN focus of that person. So, that's an +interesting angle. + +**Mark Erhardt**: That was in the comments under Antoine's answer. + +_What does not publicly routable node in Bitcoin Core P2P mean?_ + +**Mike Schmidt**: "What does 'not publicly routable' node in Bitcoin P2P mean?" +And this was answered by Pieter Wuille and Vasil, who provided examples of P2P +connections, such as Tor, that cannot be routed on the global internet and that +appear in Bitcoin Core's netinfo output under an 'npr' or 'not publicly +routable' bucket when viewing your connections. + +_Why would a node would ever relay a transaction?_ + +"Why would a node ever relay a transaction?" So, we're not talking about +relaying transactions of 400 bytes, just why would my node relay any +transactions? Pieter Wuille answered this one and he listed a few benefits of +relaying transactions for an individual node operator. One is privacy when +relaying your own transactions from your own node. So, if you saw a node that +didn't relay any transactions, and then all of a sudden one came out, you could +maybe infer that that was that node's transaction. So, there's a privacy +implication there. Faster block propagation, if the user is using that node and +is mining. And finally, improved network decentralization with minimal +incremental costs beyond those of just relaying blocks. I think the implication +there is that with compact blocks, you're already collecting all these +transactions. And if you're just doing blocks-only and not relaying in the +transactions, it's actually a minimal amount of incremental usage, according to +Pieter. Go ahead. + +**Mark Erhardt**: Right. So, the first is also a problem if you're running in +blocks-only mode. You're basically identifying if you send a transaction out, +it's the only transaction ever that comes out of your node, and that indicates +clearly probably you're the originator of that one. And I think the other one +could be sort of a little bit of a tragedy of the comments. If you're so keen +on saving a few bytes of bandwidth that you're not forwarding transactions, you +might be able to get away with that. If everyone does it, we just won't have +transactions propagate through the network anymore. Then, miners don't get +transactions, then it doesn't work for anyone. And so, yeah, I guess you don't +get paid for it, but it's understood to be part of what you're trying to do, is +get the best transactions to the miners in order to make sure that the network +works when you want to use it. + +_Is selfish mining still an option with compact blocks and FIBRE?_ + +**Mike Schmidt**: Last question from the Stack Exchange is actually a 2016 +question, which is, "Is selfish mining still an option with compact blocks and +FIBRE?" And Antoine Poinsot followed up to that old question and he noted, and +I'll quote him, "Yes, selfish mining is still a possible optimisation, even with +improved block propagation. It's not correct to conclude that selfish mining is +now only a theoretical attack". And I think there's some interesting +information in that quote, but he also pointed to a mining simulation that he +created that can articulate some of this. I thought that that was worth +mentioning. + +**Mark Erhardt**: Yeah, I think the interesting point is, if there are ever two +competing chain tips on the network, of course most miners will build on the one +that they saw first, or, well their own usually. If they found one they try to +build on their own mining pool's reward in order to make sure that it makes its +way into the longest chain. But the funny thing about this is if you have, I +think it was 33% of the hashrate, even if you always lose races, so when there's +two chain tips, you always lose, I think at 33%, just building on your own +blocks always generates more revenue than not doing so. So, yeah, any mining +pool over 33% or any mining pool conglomerate that works on the same block +templates over 33% should be eyed with suspicion. + +**Mike Schmidt**: Yeah, I think that's referencing the 2013 paper that was +linked to in Antoine's answer. So, if you're curious more about what Murch was +talking about there, refer back to that. + +**Mark Erhardt**: There's also been a few papers that follow up on this and that +look more at how the exact border shifts, if you assume that they win some of +the races or have other advantages and it's even slightly lower than 33%, I +think. + +_Core Lightning 25.05rc1_ + +**Mike Schmidt**: Releases and release candidates. Core Lightning 25.05rc1. +This is a CLN release candidate that Dave Harding covered last week in Podcast +#355 with Alex Myers, who's actually a CLN engineer, and they also went through +several of the CLN PRs that went into the release of this release in the Notable +code segment last week. So, lots of CLN stuff. Refer back to last week's +podcast I think, unless, Murch, you had anything to add. + +_LDK 0.1.3 and 0.1.4_ + +LDK 0.1.3 and LDK 0.1.4, we mentioned something in the newsletter about this, +but it appears that the timing of the tagging was off here. So, I guess we're +covering both of these releases today. 0.1.3 included a couple of bug fixes and +a security item. One bug fix was around BOLT12, where multiple InvoicesReceived +messages were being generated when a sender sends redundant messages to improve +success rates. But now, only one is generated for each matching a pending +outbound payment. The second bug was a bug fixed around LDK's router that fixed +some spurious multipath payment failures. And then, the security item for 0.1.3 +was that it fixed a DoS vulnerability, which caused potential crashing of an LDK +node if an attacker had access to a valid BOLT12offer. So, those are all +security or bug fixes as far as I'm concerned, but they've sort of bucketed them +into two bug fixes and one security item. + +Similarly, for the 0.1.4 release for LDK, there were two fixes around LDK's +synchronous persistence feature. The first fix was a fix for a deserialization +issue. You're welcome to look into the release notes for the details of that, +but it seemed quite complicated. I thought I would just leave it at that. And +then, the second one was a fix also around synchronous persistence, and it was +resulting in channels potentially hanging in some situations when receiving +multipart payments. And then, the security item related to 0.1.4 was a fix for +a potential, but far-fetched case of fund theft vulnerability. And I'll read +from the release notes here, " If an LDK-based node funds an anchor channel to a +malicious peer, and that peer sets the channel reserve on the LDK-based node to +zero, the LDK node could overdraw its total balance upon increasing the feerate +of the commitment transaction. If the malicious peer forwards HTLCs through the +LDK node, this could leave the LDK node with no valid commitment transaction to +broadcast to claim its part of the forwarded HTLC". + +So, a lot of bug fixes in LDK over these two versions. Anything to add, Murch? + +_Bitcoin Core #31622_ + +Notable code and documentation changes. Bitcoin Core #31622 is a change to +Bitcoin Core's handling of PSBTs. Previous to this PR, Bitcoin Core wouldn't +add in the sighash (signature hash) field to PSBTs at all. After this PR, +Bitcoin Core will now add the sighash field to a PSBT when signing with any +sighash, other than SIGHASH_DEFAULT or SIGHASH_ALL. That's actually required +for folks using MuSig2, because all the signers need to sign using the same +sighash type. And in addition to that change, there's also a change in this PR +to make sure that the same sighash type is used for signing as was in the PSBT, +a check that was done in some places in the code previously, but not in all +situations. And what was called out here was descriptorprocesspsbt RPC not +previously doing that check. + +Murch, I have a question for you on the BIP side of things. This is maybe a +little bit in the weeds, but PSBTv2 has a PSBT_GLOBAL_TX_MODIFIABLE, which is a +bit field. Is that what the sighash is in PSBT, or is there a separate field +for it? + +**Mark Erhardt**: No, so the sighash is basically the transaction commitment as +a derivative of all the inputs and outputs and amounts, and so forth, that +compose the transaction. It is de facto the message that you're signing in the +cryptographic signature triple, which is message, signature, and public key. +So, what we call here the sighash is declaring how you compose the message that +you're signing, which parts of the transaction you used to compose it. And +yeah, so whether the transaction is still modifiable is a previous step. As +soon as people start signing it, it's usually not modifiable anymore, or at +least everybody has to sign again. + +_Eclair #3065_ + +**Mike Schmidt**: Thanks, Murch. The Eclair PR we had discussed earlier in the +newsletter, so refer back to that if you're listening here looking for an Eclair +PR, but that they added attributable failures as specified in BOLTs #1044. + +_LDK #3796_ + +LDK 3796, titled very descriptively, "Do not dip into the funder's reserve to +cover the two anchors". So, that pretty much sums it up. But before this PR, +LDK would allow the funder to dip into its channel reserve to pay for the two +330-satoshi anchors. But now LDK reserves at least 1000 satoshis so that the +two 330 anchors won't overdraw on that reserve. + +_BIPs #1760_ + +We have three BIPs PRs to round off the newsletter. BIP #1760 which merges +BIP53. Murch, what is BIP53. Murch, what is BIP53? + +**Mark Erhardt**: So, BIP53 proposes to disallow 64-byte transactions, and +people that have been following along the consensus cleanup discussion will +notice that this is also an item that's in the consensus cleanup BIP. This BIP +was proposed before the consensus cleanup BIP and got also finished to a +sufficient degree and is now merged. I think that they have some overlap, and +it's not entirely clear to me which one of the two, or if both of them would +activate, or whether they're 100% compatible. But this is basically taking a +slice out of the consensus cleanup and proposing, in another way, to disallow +the 64-byte transactions, which of course are related to the merkle tree, well, +under-defined-ness, the vulnerability of merkle trees to fake transactions. + +**Mike Schmidt**: It would seem to me if there's a few different changes in a +soft fork, that if maybe one or more were highly controversial, that that would +be a good reason to maybe split off other pieces of that soft fork into smaller +pieces to get activated. But it doesn't seem to me in this case that the +consensus cleanup, any of the components of that are controversial to that +degree. Would you agree with that? + +**Mark Erhardt**: Yeah, I think there was a little bit of duplicated work here, +and it may have come out of some miscommunication, where someone wanted to help +and was told by third parties that they could do something to help, and then +that actually duplicated other work that was being done. It may have also +helped get the consensus cleanup BIP out a little quicker. So, definitely more +people talked about it. I don't think it's a total loss, but at this point it's +a little unclear to me what's going to happen here next. But presumably they'll +be wrapped into one and deployed eventually, if we ever manage to deploy the +consensus cleanup stuff. + +_BIPs #1850_ + +**Mike Schmidt**: BIPs #1850 reverts an earlier update to BIP48, which reserved +the script type value 3 for taproot, which I believe it's been just a couple +weeks ago, in Newsletter #353, where we discussed that. What went wrong here, +Murch, or did something go wrong? + +**Mark Erhardt**: So, BIP48 describes a way of constructing multisig outputs, +and it was defined for P2SH and P2WSH, I think, and it uses OP_CHECKMULTISIG +construction. And what I learned later was that it was more descriptive than +prescriptive. It was something that was already widely used that finally +someone took and wrote up into a BIP in order to document it. And so, a couple +of weeks ago, someone said, "Let's also add P2TR to BIP48", which had a passage +that said, "Hey, if you want to add more output types, just amend this BIP and +add them", and that got reviewed and merged. But then I also reviewed it again +a little later and realized that, well, that doesn't work because tapscript does +not have OP_CHECKMULTISIG. OP_CHECKMULTISIG would not be stable for the batched +signature validation, and therefore it uses OP_CHECKSIGADD instead. + +So, I found that for P2TR, BIP48-style outputs didn't make sense and were +underspecified. So, I suggested that we actually roll back the addition of P2TR +and move BIP48 to final, because presumably there's not going to be another +output type that would be compatible with BIP48. And given that it was already +just describing a widely deployed industry, well, standard, I guess, adding to +it later now would make all these implementers of BIP48 incompatible with the +existing standard. So, really, I think it's at a point where if we added +another one, we should write a new BIP for it. So, when people declare they're +compatible with BIP48, it's clear and it's not another new question to the old +one, or the new and amended one. So, anyway, we cleaned that up and returned it +to the prior version and moved the BIP to final. + +_BIPs #1793_ + +**Mike Schmidt**: Last PR this week, BIPs #1793, which merges BIP443, which +specifies OP_CHECKCONTRACTVERIFY (OP_CCV). + +**Mark Erhardt**: Yeah, I mean we've had Salvatore on quite a few times here to +talk about OP_CCV. The BIP has made so much progress that we felt that we +should merge it in draft status. There's still a couple of open to-dos about +what exactly the sigop costs would be of the CCV opcode, and some other minor +details, minor in the sense that the work is in the research and deciding, and +the writing of it is probably pretty small. Anyway, I would encourage people +that are interested in covenants and/or vaults that they take a good look at +this and provide feedback so that Salvatore can keep moving forward this BIP if +they're interested in that happening. + +**Mike Schmidt**: We have talked with Salvatore a few times, even early on in +MATT, when this was sort of in its MATT phases, now CCV. I think the most +comprehensive to-date version of the discussion would be in Newsletter, mostly +Podcast #348, where we had Salvatore on, and that was for the Changing consensus +segment. So, we had a bunch of consensus script people on, going back and forth +about a variety of topics, including one on CCV. So, check back to that if you +want to learn more about what Salvatore is up to. Seems like a lot of folks +that I've spoken with are excited about this proposal, even if it's more +immature than some of the other covenants-related software proposals. So, if +you're curious, check back to that episode and check out the BIP as well. + +**Mark Erhardt**: I might say that I think it's one of the covenant proposals +that's worked out pretty far actually. And it's also one that has been worked +on for years and developed further and further. So, well, there's a lot of +covenant proposals floating around and some of them may be less mature, but I +think I would categorize this one as actually closer to deployable than some +other ones. + +**Mike Schmidt**: I think that's fair. Thanks for chiming in on that. Well, we +want to thank our special guests Elias, Joost and Carla for joining us this week +to talk about LN stuff, that was great. And thank you, Murch, for co-hosting +and everyone else for listening. Cheers. + +**Mark Erhardt**: Thanks for your time. {% include references.md %} From e7f960a461cf159baab2cd20f219d0c8efd70ab8 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Tue, 17 Jun 2025 20:57:45 -1000 Subject: [PATCH 113/278] Newsletters: add 359 (2025-06-20) --- .../en/newsletters/2025-06-20-newsletter.md | 136 ++++++++++++++++++ 1 file changed, 136 insertions(+) create mode 100644 _posts/en/newsletters/2025-06-20-newsletter.md diff --git a/_posts/en/newsletters/2025-06-20-newsletter.md b/_posts/en/newsletters/2025-06-20-newsletter.md new file mode 100644 index 0000000000..366d2c8498 --- /dev/null +++ b/_posts/en/newsletters/2025-06-20-newsletter.md @@ -0,0 +1,136 @@ +--- +title: 'Bitcoin Optech Newsletter #359' +permalink: /en/newsletters/2025/06/20/ +name: 2025-06-20-newsletter +slug: 2025-06-20-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter describes a proposal to limit public +participation in Bitcoin Core repositories, announces a significant +improvements to BitVM-style contracts, and summarizes research into +LN channel rebalancing. Also included are our regular sections +summarizing recent changes to clients and services, announcing new +releases and release candidates, and describing recent changes to popular +Bitcoin infrastructure software. + +## News + +- **Proposal to restrict access to Bitcoin Core Project discussion:** + Bryan Bishop [posted][bishop priv] to the Bitcoin-Dev mailing list to + suggest that the Bitcoin Core Project limit the public's ability to + participate in project discussions in order to reduce the amount of + disruption caused by non-contributors. He called this + "privatizing Bitcoin Core", + points to examples of this privatization already happening on an ad + hoc basis in private offices with multiple Bitcoin Core contributors, + and warns that in-person privatization leaves out remote contributors. + + Bishop's post suggests a method for online privatization, but + Antoine Poinsot [questioned][poinsot priv] whether that method would + achieve the goal. Poinsot also suggested that many private + office discussions might occur not out of fear of public reproach but + because of "the natural advantages of in-person discussions". + + Several replies suggested that making major changes is + probably not warranted at this time but that stronger moderation of + comments on the repository might alleviate the most + significant type of disruption. However, other replies noted several + challenges with stronger moderation. + + Poinsot, Sebastian "The Charlatan" Kung, and Russell Yanofsky---the only highly + active Bitcoin Core contributors to reply to the thread as of the time + of writing---[indicated][kung priv] either [that][yanofsky priv] they don't think a major + change is necessary or that any changes should be made incrementally + over time. + +- **Improvements to BitVM-style contracts:** Robin Linus [posted][linus + bitvm3] to Delving Bitcoin to announce a significant reduction in the + amount of onchain space required by [BitVM][topic acc]-style + contracts. Based on an [idea][rubin garbled] by Jeremy Rubin that + builds on new cryptographic primitives, the new approach "reduces the + onchain cost of a dispute by over 1,000 times compared to the previous + design", with disprove transactions being "just 200 bytes". + + However, Linus's paper notes the tradeoff for this approach: it + "requires a multi-terabyte offchain data setup". The paper gives an + example of a SNARK verifier circuit with about 5 billion gates and + reasonable security parameters requiring a 5 TB offchain setup, 56 kB + onchain transaction to assert the result, and minimal onchain + transaction (~200 B) in the case that a party needs to prove the + assertion was invalid. + +- **Channel rebalancing research:** Rene Pickhardt [posted][pickhardt + rebalance] to Delving Bitcoin thoughts about rebalancing channels + to maximize the rate of successful payments across + the whole network. His ideas can be compared to approaches that look + at smaller groups of channels, such as [friend-of-a-friend + rebalancing][topic jit routing] (see [Newsletter #54][news54 foaf + rebalance]). + + Pickhardt notes that there are several challenges to a global approach and + asks interested parties to answer a few questions, such as whether + this approach is worth pursuing and how to address certain + implementation details. + +## Changes to services and client software + +*In this monthly feature, we highlight interesting updates to Bitcoin +wallets and services.* + +FIXME:bitschmidty + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [Core Lightning 25.05][] is a release of the next major + version of this popular LN node implementation. It reduces the + latency of relaying and resolving payments, improves fee + management, provides [splicing][topic splicing] support compatible + with Eclair, and enables [peer storage][topic peer storage] by + default. Note: its [release documentation][core lightning 25.05] + contains a warning for users of the `--experimental-splicing` + configuration option. + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [Eclair #3110][] Increase channel spent delay to 72 blocks + +- [Eclair #3101][] Parse offers and pay offers with currency + +- [LDK #3817][] Revert attribution of failures + +- [LDK #3623][] adi2011/peer-storage/encrypt-decrypt + +- [BTCPay Server #6755][] feat(wallet): enhance Coin Selection with advanced filters and improved UX + +- [Rust libsecp256k1 #798][] completes the [MuSig2][topic musig] + implementation in the library, giving downstream projects access to a + robust [scriptless multisignature][topic multisignature] protocol. + +{% include snippets/recap-ad.md when="2025-06-24 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="3110,3101,3817,3623,6755" %} +[Core Lightning 25.05]: https://github.com/ElementsProject/lightning/releases/tag/v25.05 +[bishop priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com/ +[poinsot priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235xaDlhg35nY8Zn7g1siy3IADHvSHyCcgTHrJorMKcDzZg=@protonmail.com/ +[kung priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/58813483-7351-487e-8f7f-82fb18a4c808n@googlegroups.com/ +[linus bitvm3]: https://delvingbitcoin.org/t/garbled-circuits-and-bitvm3/1773 +[rubin garbled]: https://rubin.io/bitcoin/2025/04/04/delbrag/ +[pickhardt rebalance]: https://delvingbitcoin.org/t/research-update-a-geometric-approach-for-optimal-channel-rebalancing/1768 +[rust libsecp256k1 #798]: https://github.com/rust-bitcoin/rust-secp256k1/pull/798 +[news54 foaf rebalance]: /en/newsletters/2019/07/10/#brainstorming-just-in-time-routing-and-free-channel-rebalancing +[yanofsky priv]: https://github.com/bitcoin-core/meta/issues/19#issuecomment-2961177626 From add57ea8e8626eca46ba1467119e23e7ef2afd9f Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Wed, 18 Jun 2025 15:21:12 -0500 Subject: [PATCH 114/278] News359: add client services --- .../en/newsletters/2025-06-20-newsletter.md | 24 ++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2025-06-20-newsletter.md b/_posts/en/newsletters/2025-06-20-newsletter.md index 366d2c8498..ef70a62a86 100644 --- a/_posts/en/newsletters/2025-06-20-newsletter.md +++ b/_posts/en/newsletters/2025-06-20-newsletter.md @@ -79,7 +79,24 @@ Bitcoin infrastructure software. *In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.* -FIXME:bitschmidty +- **Cove v1.0.0 released:** + Recent Cove [releases][cove github] include coin control support and + additional [BIP329][] wallet label features. + +- **Liana v11.0 released:** + Recent [releases][liana github] of Liana include features for multiple + wallets, additional coin control features, and more hardware signing device + support, among other features. + +- **Stratum v2 STARK proof demo:** + StarkWare [demonstrated][starkware tweet] a [modified Stratum v2 mining + client][starkware sv2] using a STARK proof to prove that a block's fees + belongs to a valid block template without revealing the transactions in the + block. + +- **Breez SDK adds BOLT12 and BIP353:** + Breez SDK Nodeless [0.9.0][breez github] adds support for receiving using + [BOLT12][] and [BIP353]. ## Releases and release candidates @@ -134,3 +151,8 @@ repo], and [BINANAs][binana repo]._ [rust libsecp256k1 #798]: https://github.com/rust-bitcoin/rust-secp256k1/pull/798 [news54 foaf rebalance]: /en/newsletters/2019/07/10/#brainstorming-just-in-time-routing-and-free-channel-rebalancing [yanofsky priv]: https://github.com/bitcoin-core/meta/issues/19#issuecomment-2961177626 +[cove github]: https://github.com/bitcoinppl/cove/releases +[liana github]: https://github.com/wizardsardine/liana/releases +[breez github]: https://github.com/breez/breez-sdk-liquid/releases/tag/0.9.0 +[starkware tweet]: https://x.com/dimahledba/status/1935354385795592491 +[starkware sv2]: https://github.com/keep-starknet-strange/stratum From 1a1c561de921cde48d04cbf5aaa43515ea9bff79 Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 19 Jun 2025 12:53:05 +0000 Subject: [PATCH 115/278] News359: add merge summaries --- .../en/newsletters/2025-06-20-newsletter.md | 56 ++++++++++++++----- 1 file changed, 42 insertions(+), 14 deletions(-) diff --git a/_posts/en/newsletters/2025-06-20-newsletter.md b/_posts/en/newsletters/2025-06-20-newsletter.md index ef70a62a86..a5737fd84b 100644 --- a/_posts/en/newsletters/2025-06-20-newsletter.md +++ b/_posts/en/newsletters/2025-06-20-newsletter.md @@ -124,23 +124,48 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Eclair #3110][] Increase channel spent delay to 72 blocks - -- [Eclair #3101][] Parse offers and pay offers with currency - -- [LDK #3817][] Revert attribution of failures - -- [LDK #3623][] adi2011/peer-storage/encrypt-decrypt - -- [BTCPay Server #6755][] feat(wallet): enhance Coin Selection with advanced filters and improved UX - -- [Rust libsecp256k1 #798][] completes the [MuSig2][topic musig] - implementation in the library, giving downstream projects access to a - robust [scriptless multisignature][topic multisignature] protocol. +- [Eclair #3110][] raises the delay for marking a channel as closed after its + funding output is spent from 12 (see Newsletter [#337][news337 delay]) to 72 + blocks as specified in [BOLTs #1270][], to allow for the propagation of a + [splice][topic splicing] update. It was increased because some implementations + default to 8 confirmations before sending `splice_locked` and allow node + operators to raise that threshold, so 12 blocks proved too short. The delay is + now configurable for testing purposes and to allow node operators to wait + longer. + +- [Eclair #3101][] introduces the `parseoffer` RPC, which decodes [BOLT12 + offer][topic offers] fields into a human-readable format, allowing users to + view the amount before passing it to the `payoffer` RPC. The latter is + extended to accept an amount specified in a fiat currency. + +- [LDK #3817][] rolls back support for [attributable failures][topic attributable failures] (see Newsletter + [#349][news349 attributable]) by placing it under a test-only flag. This + disables the peer penalization logic and removes the feature TLV from failure + [onion messages][topic onion messages]. Nodes that hadn’t upgraded yet were + wrongly penalized, showing that broader network adoption is necessary for it + to work properly. + +- [LDK #3623][] extends [peer storage][topic peer storage] (see Newsletter + [#342][news342 peer]) to provide automatic, encrypted peer backups. Each + block, `ChainMonitor` packages the data from a versioned, timestamped, and serialized + `ChannelMonitor` structure into an `OurPeerStorage` blob. Then, it encrypts the + data and raises a `SendPeerStorage` event to relay the blob as a + `peer_storage` message to every channel peer. Additionally, `ChannelManager` + is updated to handle `peer_storage_retrieval` requests by triggering a new + blob send. + +- [BTCPay Server #6755][] enhances the coin control + user interface with new minimum and maximum amount filters, before and after + creation date filters, a help section for the filters, a "select all" UTXO + checkbox, and large page size options (100, 200 or 500 UTXOs). + +- [Rust libsecp256k1 #798][] completes the [MuSig2][topic musig] implementation + in the library, giving downstream projects access to a robust [scriptless + multisignature][topic multisignature] protocol. {% include snippets/recap-ad.md when="2025-06-24 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="3110,3101,3817,3623,6755" %} +{% include linkers/issues.md v=2 issues="3110,3101,3817,3623,6755,1270" %} [Core Lightning 25.05]: https://github.com/ElementsProject/lightning/releases/tag/v25.05 [bishop priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com/ [poinsot priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235xaDlhg35nY8Zn7g1siy3IADHvSHyCcgTHrJorMKcDzZg=@protonmail.com/ @@ -156,3 +181,6 @@ repo], and [BINANAs][binana repo]._ [breez github]: https://github.com/breez/breez-sdk-liquid/releases/tag/0.9.0 [starkware tweet]: https://x.com/dimahledba/status/1935354385795592491 [starkware sv2]: https://github.com/keep-starknet-strange/stratum +[news337 delay]: /en/newsletters/2025/01/17/#eclair-2936 +[news349 attributable]: /en/newsletters/2025/04/11/#ldk-2256 +[news342 peer]:/en/newsletters/2025/02/21/#ldk-3575 From 5176c3ddf089767864943767c6987f22b49963a6 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Fri, 20 Jun 2025 05:02:54 -0500 Subject: [PATCH 116/278] News359: add topics --- _topics/en/acc.md | 3 +++ _topics/en/attributable-failures.md | 3 +++ _topics/en/musig.md | 3 +++ _topics/en/peer-storage.md | 3 +++ _topics/en/pooled-mining.md | 3 +++ 5 files changed, 15 insertions(+) diff --git a/_topics/en/acc.md b/_topics/en/acc.md index 32c11302f0..bd8a93038c 100644 --- a/_topics/en/acc.md +++ b/_topics/en/acc.md @@ -67,6 +67,9 @@ optech_mentions: - title: Discussion about transaction weight limit in response to large BitVM transactions url: /en/newsletters/2025/06/06/#transaction-weight-limit-with-exception-to-prevent-confiscation + - title: "Improvments to BitVM-style contracts allowing disprove transactions to be just 200 bytes" + url: /en/newsletters/2025/06/20/#improvements-to-bitvm-style-contracts + ## Optional. Same format as "primary_sources" above see_also: - title: "Merklize All The Things (MATT)" diff --git a/_topics/en/attributable-failures.md b/_topics/en/attributable-failures.md index b94f1eb6bd..e35c58e2a1 100644 --- a/_topics/en/attributable-failures.md +++ b/_topics/en/attributable-failures.md @@ -38,6 +38,9 @@ optech_mentions: - title: Discussion about whether attributable failures reduce LN privacy url: /en/newsletters/2025/05/30/#do-attributable-failures-reduce-ln-privacy + - title: "LDK #3817 puts attributable failures under a test-only flag until broader adoption is achieved" + url: /en/newsletters/2025/06/20/#ldk-3817 + ## Optional. Same format as "primary_sources" above # see_also: # - title: diff --git a/_topics/en/musig.md b/_topics/en/musig.md index 8a7c5fd80a..9953b55188 100644 --- a/_topics/en/musig.md +++ b/_topics/en/musig.md @@ -160,6 +160,9 @@ optech_mentions: - title: "Lightning Loop begins using MuSig2" url: /en/newsletters/2025/02/21/#lightning-loop-moves-to-musig2 + - title: "Rust libsecp256k1 #798 completes its MuSig2 implementation" + url: /en/newsletters/2025/06/20/#rust-libsecp256k1-798 + ## Optional. Same format as "primary_sources" above see_also: - title: Scriptless multisignatures diff --git a/_topics/en/peer-storage.md b/_topics/en/peer-storage.md index 331db97335..dd2c6dceb3 100644 --- a/_topics/en/peer-storage.md +++ b/_topics/en/peer-storage.md @@ -45,6 +45,9 @@ optech_mentions: - title: "Core Lightning #8140 enables peer storage of channel backups by default" url: /en/newsletters/2025/05/23/#core-lightning-8140 + - title: "LDK #3623 extends its peer storage support to provide automatic and encrypted peer backups" + url: /en/newsletters/2025/06/20/#ldk-3623 + ## Optional. Same format as "primary_sources" above # see_also: # - title: diff --git a/_topics/en/pooled-mining.md b/_topics/en/pooled-mining.md index 9fd7f7611a..15e381b639 100644 --- a/_topics/en/pooled-mining.md +++ b/_topics/en/pooled-mining.md @@ -92,6 +92,9 @@ optech_mentions: - title: "DMND pool launches Stratum v2 pooled mining" url: /en/newsletters/2025/03/21/#dmnd-launching-pooled-mining + - title: "Stratum v2 STARK proof demo for private block template fee reporting" + url: /en/newsletters/2025/06/20/#stratum-v2-stark-proof-demo + ## Optional. Same format as "primary_sources" above #see_also: # - title: From 719920ebdbfc8ca47f1b45850eb6a113a34053c3 Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 20 Jun 2025 20:24:08 +0900 Subject: [PATCH 117/278] Newsletter-359:Translate into Japanese --- .../ja/newsletters/2025-06-20-newsletter.md | 156 ++++++++++++++++++ 1 file changed, 156 insertions(+) create mode 100644 _posts/ja/newsletters/2025-06-20-newsletter.md diff --git a/_posts/ja/newsletters/2025-06-20-newsletter.md b/_posts/ja/newsletters/2025-06-20-newsletter.md new file mode 100644 index 0000000000..c2a79caf15 --- /dev/null +++ b/_posts/ja/newsletters/2025-06-20-newsletter.md @@ -0,0 +1,156 @@ +--- +title: 'Bitcoin Optech Newsletter #359' +permalink: /ja/newsletters/2025/06/20/ +name: 2025-06-20-newsletter-ja +slug: 2025-06-20-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、Bitcoin Coreリポジトリへの一般参加を制限する提案と、 +BitVMスタイルのコントラクトの大幅な改良の発表、LNチャネルのリバランスに関する研究の概要を掲載しています。 +また、クライアントとサービスの最近の更新や、新しいリリースとリリース候補の発表、 +人気のBitcoinインフラストラクチャソフトウェアの最近の更新など、恒例のセクションも含まれています。 + +## ニュース + +- **Bitcoin Coreプロジェクトの議論へのアクセス制限の提案:** + Bryan Bishopは、非コントリビューターによる混乱を軽減するために、 + Bitcoin Coreプロジェクトがプロジェクトの議論への一般参加者の参加を制限する提案を + Bitcoin-Devメーリングリストに[投稿しました][bishop priv]。 + 彼はこれを「Bitcoin Coreのプライベート化」と呼び、 + 複数のBitcoin Coreコントリビューターがいるプライベートオフィスで + 既にアドホックに行われているプライベート化の例を挙げ、 + 対面でのプライベート化は遠隔地のコントリビューターを除外してしまう可能性があると警告しました。 + + Bishopの投稿では、オンラインでのプライベート化を提案していますが、 + Antoine Poinsotはその方法が目的を達成できるかどうか[疑問視][poinsot priv]しています。 + Poinsotはまた、多くのプライベートオフィスでの話し合いは、 + 世間からの非難を恐れているのではなく、「対面での話し合いの自然な利点」により行われているのではないかと示唆しました。 + + いくつかの返信では、現時点では大幅な変更はおそらく必要ないが、 + リポジトリのコメントのモデレーションを強化することで、最も重大なタイプの混乱を軽減できる可能性があると提案されました。 + しかし、他の返信では、より協力なモデレーションにはいくつかの課題があることが指摘されました。 + + （執筆時点でこのスレッドに返信したアクティブなBitcoin Coreコントリビューターである） + Poinsot、Sebastian "The Charlatan" KungおよびRussell Yanofskyは、 + 大きな変更は必要ないと[考えている][kung priv]か、変更は時間をかけて段階的に行うべきだと[示しました][yanofsky priv]。 + +- **BitVMスタイルのコントラクトの改良:** Robin Linusは、 + [BitVM][topic acc]スタイルのコントラクトに必要なオンチェーンスペースの大幅な削減の発表を + Delving Bitcoinに[投稿しました][linus bitvm3]。新しい暗号プリミティブに基づく + Jeremy Rubinの[アイディア][rubin garbled]を基に、 + この新しいアプローチは「以前の設計と比較して、紛争時のオンチェーンコストを1,000倍以上削減」し、 + 反証トランザクションは「わずか200 byte」になります。 + + しかし、Linusの論文では、このアプローチのトレードオフとして、 + 「数TBのオフチェーンデータのセットアップが必要」であると指摘しています。 + 論文では、約50億個のゲートと妥当なセキュリティパラメーターを備えたSNARK検証回路の例が示されています。 + これには5 TBのオフチェーンセットアップ、結果のアサーションに必要な56 kBのオンチェーントランザクション、 + そして当事者がアサーションの無効性を証明する必要がある場合の最小限のオンチェーントランザクション（約200 byte）が必要です。 + +- **チャネルリバランスの研究:** + Rene Pickhardtは、ネットワーク全体の支払い成功率を最大化するためのチャネルリバランスに関する考察を + Delving Bitcoinに[投稿しました][pickhardt rebalance]。彼のアイディアは、 + [friend-of-a-friendリバランス][topic jit routing]（[ニュースレター #54][news54 foaf rebalance]参照）のような、 + チャネルの小規模グループを対象としたアプローチと比較することができます。 + + Pickhardtは、グローバルアプローチにはいくつかの課題があると指摘し、 + このアプローチを追求する価値があるのか、特定の実装の詳細にどのように対処すべきかなど、 + 関心のある関係者にいくつかの質問への回答を求めています。 + +## サービスとクライアントソフトウェアの変更 + +*この毎月の特集では、Bitcoinのウォレットやサービスの興味深いアップデートを取り上げています。* + +- **Cove v1.0.0リリース:** + 最近のCoveの[リリース][cove github]には、コインコントロールのサポートと、 + [BIP329][]ウォレットラベル機能が追加されました。 + +- **Liana v11.0リリース:** + 最近のLianaの[リリース][liana github]には、マルチウォレット機能、 + コインコントロール機能の追加、ハードウェア署名デバイスのサポートの強化などが含まれています。 + +- **Stratum v2 STARK証明のデモ:** + StarkWareは、ブロック内のトランザクションを明かすことなく、 + ブロックの手数料が有効なブロックテンプレートに属していることを証明するために、 + STARK証明を用いた[改良版Stratum v2マイニングクライアント][starkware sv2]の[デモ][starkware tweet]を行いました。 + +- **Breez SDKがBOLT12とBIP353を追加:** + Breez SDK Nodeless [0.9.0][breez github]では、[BOLT12][]と[BIP353]を使った受取のサポートが追加されました。 + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [Core Lightning 25.05][]は、この人気のLNノード実装の次期メジャーバージョンのリリースです。 + 支払いのリレーと解決のレイテンシーを短縮し、手数料管理を改善し、 + Eclairと互換性のある[スプライシング][topic splicing]をサポートし、 + [ピアストレージ][topic peer storage]をデフォルトで有効化します。 + 注：[リリースドキュメント][core lightning 25.05]には、 + `--experimental-splicing`設定オプションを使用するユーザーへの警告が記載されています。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Eclair #3110][]では、ファンディングアウトプットが使用された後、 + チャネルをクローズとマークするまでの遅延を12ブロック（ニュースレター[#337][news337 delay]参照）から + [BOLTs #1270][]で規定されている72ブロックに引き上げ、[スプライシング][topic splicing]の更新の伝播を可能にします。 + この遅延が引き上げられたのは、一部の実装では、`splice_locked`を送信する前にデフォルトで8承認が必要とされており、 + ノードオペレーターがその閾値を引き上げることができるため、12ブロックでは短すぎることが判明したからです。 + この遅延はテスト目的で設定可能になり、ノードオペレーターがより長く待機できるようになりました。 + +- [Eclair #3101][]では、[BOLT12 offer][topic offers]フィールドを人が読める形式にデコードする`parseoffer` + RPCが導入されました。これにより、ユーザーは`payoffer` RPCに渡す前に金額を確認できます。 + `payoffer` RPCは、法定通貨で指定された金額を受け入れるように拡張されています。 + +- [LDK #3817][]は、[失敗の帰属][topic attributable failures]（ニュースレター[#349][news349 attributable]参照） + のサポートをテスト専用フラグに設定してロールバックしました。これにより、 + ピアペナルティロジックが無効化され、失敗の[onionメッセージ][topic onion messages]から機能TLVが削除されました。 + まだアップグレードしていないノードが誤ってペナルティを受けていたため、 + この機能が適切に動作するには、より広範なネットワーク導入が必要であることが示されています。 + +- [LDK #3623][]は、[ピアストレージ][topic peer storage]（ニュースレター[#342][news342 peer]参照）を拡張し、 + 自動暗号化ピアバックアップを提供します。各ブロックで、`ChainMonitor`はバージョン管理され、タイムスタンプが付けられ、 + シリアライズされた`ChannelMonitor`構造体のデータを`OurPeerStorage`ブロブにパッケージします。 + そして、そのデータを暗号化し、`SendPeerStorage`イベントを発生させて、 + そのブロブを`peer_storage`メッセージとして各チャネルピアにリレーします。さらに、 + `ChannelManager`が更新され、`peer_storage_retrieval`リクエストを処理できるように、 + 新しいブロブ送信をトリガーします。 + +- [BTCPay Server #6755][]は、コイン管理ユーザーインターフェースを強化し、 + 新しい最小・最大額フィルター、作成日前後フィルター、フィルター用のヘルプセクション、 + 「すべて選択」UTXOチェックボックス、そして大きなページサイズオプション（100、200または500 UTXO）を追加しました。 + +- [Rust libsecp256k1 #798][]は、ライブラリ内の[MuSig2][topic musig]実装を完了させ、 + 下流のプロジェクトが堅牢な[スクリプトレスマルチシグ][topic multisignature]プロトコルにアクセスできるようにしました。 + +{% include snippets/recap-ad.md when="2025-06-24 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="3110,3101,3817,3623,6755,1270" %} +[Core Lightning 25.05]: https://github.com/ElementsProject/lightning/releases/tag/v25.05 +[bishop priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com/ +[poinsot priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235xaDlhg35nY8Zn7g1siy3IADHvSHyCcgTHrJorMKcDzZg=@protonmail.com/ +[kung priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/58813483-7351-487e-8f7f-82fb18a4c808n@googlegroups.com/ +[linus bitvm3]: https://delvingbitcoin.org/t/garbled-circuits-and-bitvm3/1773 +[rubin garbled]: https://rubin.io/bitcoin/2025/04/04/delbrag/ +[pickhardt rebalance]: https://delvingbitcoin.org/t/research-update-a-geometric-approach-for-optimal-channel-rebalancing/1768 +[rust libsecp256k1 #798]: https://github.com/rust-bitcoin/rust-secp256k1/pull/798 +[news54 foaf rebalance]: /en/newsletters/2019/07/10/#brainstorming-just-in-time-routing-and-free-channel-rebalancing +[yanofsky priv]: https://github.com/bitcoin-core/meta/issues/19#issuecomment-2961177626 +[cove github]: https://github.com/bitcoinppl/cove/releases +[liana github]: https://github.com/wizardsardine/liana/releases +[breez github]: https://github.com/breez/breez-sdk-liquid/releases/tag/0.9.0 +[starkware tweet]: https://x.com/dimahledba/status/1935354385795592491 +[starkware sv2]: https://github.com/keep-starknet-strange/stratum +[news337 delay]: /ja/newsletters/2025/01/17/#eclair-2936 +[news349 attributable]: /ja/newsletters/2025/04/11/#ldk-2256 +[news342 peer]:/ja/newsletters/2025/02/21/#ldk-3575 From 539063b71635fdbe801af17002253593f79ed2a6 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sat, 21 Jun 2025 11:25:48 +0200 Subject: [PATCH 118/278] Create 2025-06-06-newsletter.md --- .../fr/newsletters/2025-06-06-newsletter.md | 180 ++++++++++++++++++ 1 file changed, 180 insertions(+) create mode 100644 _posts/fr/newsletters/2025-06-06-newsletter.md diff --git a/_posts/fr/newsletters/2025-06-06-newsletter.md b/_posts/fr/newsletters/2025-06-06-newsletter.md new file mode 100644 index 0000000000..4125c5dd1e --- /dev/null +++ b/_posts/fr/newsletters/2025-06-06-newsletter.md @@ -0,0 +1,180 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #357' +permalink: /fr/newsletters/2025/06/06/ +name: 2025-06-06-newsletter-fr +slug: 2025-06-06-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +La newsletter de cette semaine partage une analyse sur la synchronisation des nœuds complets sans +anciens témoins. Sont également incluses nos sections régulières avec des descriptions des +discussions sur le changement de consensus, annonçant de nouvelles versions et versions candidates, +et décrivant les changements notables apportés aux logiciels d'infrastructure Bitcoin populaires. + +## Nouvelles + +- **Synchronisation des nœuds complets sans témoins :** Jose SK a [publié][sk nowit] sur Delving + Bitcoin un résumé d'une [analyse][sk nowit gist] qu'il a réalisée concernant les compromis de + sécurité permettant aux nœuds complets nouvellement démarrés avec une configuration particulière + d'éviter de télécharger certaines données historiques de la blockchain. Par défaut, les nœuds + Bitcoin Core utilisent le paramètre de configuration `assumevalid` qui saute la validation des + scripts dans les blocs créés plus d'un mois ou deux avant la sortie de la version de Bitcoin Core + utilisée. Bien que désactivé par défaut, de nombreux utilisateurs de Bitcoin Core définissent + également un paramètre de configuration `prune` qui supprime les blocs un certain temps après les + avoir validés (la durée de conservation des blocs dépend de la taille des blocs et du paramètre + spécifique sélectionné par l'utilisateur). + + SK soutient que les données de témoins, qui sont uniquement utilisées pour la validation des + scripts, ne devraient pas être téléchargées par les nœuds élagués pour les blocs assumevalid car ils + ne les utiliseront pas pour valider les scripts et finiront par les supprimer. Omettre le + téléchargement des témoins "peut réduire l'utilisation de la bande passante de plus de 40 %", + écrit-il. + + Ruben Somsen [soutient][somsen nowit] que cela change le modèle de sécurité dans une certaine + mesure. Bien que les scripts ne soient pas validés, les données téléchargées sont validées contre + l'engagement du merkle root de l'en-tête du bloc à la transaction coinbase jusqu'aux données du + témoin. Cela garantit que les données étaient disponibles et non corrompues au moment où le nœud a + été synchronisé initialement. Si personne ne valide régulièrement l'existence des données, il + pourraient être concevable qu'elles soient perdues, comme cela [s'est produit][ripple loss] + pour au moins un altcoin. + + La discussion était en cours au moment de la rédaction. + +## Modification du consensus + +_Une nouvelle section mensuelle résumant les propositions et discussions sur la modification des +règles de consensus de Bitcoin._ + +- **Rapport sur l'informatique quantique :** Clara Shikhelman a [publié][shikelman quantum] sur + Delving Bitcoin le résumé d'un [rapport][sm report] qu'elle a co-écrit avec Anthony Milton sur les + risques pour les utilisateurs de Bitcoin des ordinateurs quantiques rapides, un aperçu de plusieurs + voies vers la [résistance quantique][topic quantum resistance], et une analyse des compromis + impliqués dans la mise à niveau du protocole Bitcoin. Les auteurs trouvent que 4 à 10 millions de + BTC sont potentiellement vulnérables au vol quantique, certaines mesures d'atténuation sont + possibles maintenant, l'exploitation minière de Bitcoin est peu susceptible d'être menacée par + l'informatique quantique à court ou moyen terme, et la mise à niveau nécessite un large accord. + +- **Limite de poids de transaction avec exception pour prévenir la confiscation :** Vojtěch Strnad a + [publié][strnad limit] sur Delving Bitcoin pour proposer l'idée d'un changement de consensus pour + limiter le poids maximum de la plupart des transactions dans un bloc. La règle simple ne permettrait + qu'une transaction de plus de 400 000 unités de poids (100 000 vbytes) dans un bloc s'il était la seule transaction dans + ce bloc à part la transaction coinbase. Strnad et d'autres ont décrit la motivation pour limiter le + poids maximum de la transaction : + + - _Optimisation plus facile du modèle de bloc :_ il est plus facile de trouver une solution presque + optimale au [problème du sac à dos][] lorsque les éléments sont plus petits par rapport à la limite + globale. Cela est en partie dû à la minimisation de la quantité d'espace restant à la fin, avec des + éléments plus petits laissant moins d'espace inutilisé. + + - _Politique de relais plus facile :_ la politique pour le relais des transactions non confirmées + entre les nœuds prédit quelles transactions seront minées afin d'éviter le gaspillage de bande + passante. Les transactions géantes rendent les prédictions précises plus difficiles car même un + petit changement dans le taux de frais le plus élevé peut les faire retarder ou être évincées. + + - _Éviter la centralisation de l'extraction :_ s'assurer que les nœuds complets de relais peuvent + gérer presque toutes les transactions empêche les utilisateurs de transactions spéciales de devoir + payer des [frais hors bande][topic out-of-band fees], ce qui peut conduire à la centralisation de + l'extraction. + + Gregory Sanders [a noté][sanders limit] qu'il pourrait être raisonnable de simplement appliquer une + limite maximale de poids par un soft fork sans aucune exception basée sur les 12 années de politique + de relais cohérente de Bitcoin Core. Gregory Maxwell [a ajouté][maxwell limit] que les transactions + dépensant uniquement des UTXOs créés avant le soft fork pourraient être autorisées une exception + pour prévenir la confiscation, et qu'un [soft fork transitoire][topic transitory soft forks] + permettrait à la restriction d'expirer si la communauté décidait de ne pas la renouveler. + + Des discussions supplémentaires ont examiné les besoins des parties souhaitant de grandes + transactions, principalement les utilisateurs de [BitVM][topic acc] à court terme, et si des + approches alternatives étaient disponibles pour eux. + +- **Suppression des sorties de l'ensemble UTXO basée sur la valeur et le temps :** Robin Linus [a + posté][linus dust] sur Delving Bitcoin pour proposer un soft fork pour retirer les sorties de faible + valeur de l'ensemble UTXO après un certain temps. Plusieurs variations de l'idée ont été discutées, + les deux principales alternatives étant : + + - _Détruire les fonds économiquement non rentables anciens :_ les sorties de petite valeur qui + n'avaient pas été dépensées pendant longtemps deviendraient inexploitables. + + - _Exiger que les fonds économiquement non rentables anciens soient dépensés avec une preuve + d'existence :_ [utreexo][topic utreexo] ou un système similaire pourrait être utilisé pour permettre + à une transaction de prouver que les sorties qu'elle dépense font partie de l'ensemble UTXO. Les + sorties anciennes et [économiquement non rentables][topic uneconomical outputs] devraient inclure + cette preuve, mais les sorties plus récentes et de plus grande valeur seraient toujours stockées + dans l'ensemble UTXO. + + L'une ou l'autre solution limiterait efficacement la taille maximale de l'ensemble UTXO (en + supposant une valeur minimale et la limite de 21 millions de bitcoins). Plusieurs aspects techniques + intéressants d'une conception ont été discutés, y compris des alternatives aux preuves utreexo pour + cette application qui pourraient être plus pratiques. + +## Mises à jour et versions candidates + +_Nouvelles mises à jour et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de passer aux nouvelles versions ou d'aider à tester +les versions candidates._ + +- [Core Lightning 25.05rc1][] est un candidat à la sortie pour la prochaine version majeure + version de cette populaire implémentation de nœud LN. + +- [LND 0.19.1-beta.rc1][] est un candidat à la version pour une maintenance + version de cette populaire implémentation de nœud LN. + +## Changements de code et de documentation notables + +_Changements récents notables dans [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Interface de Portefeuille Matériel (HWI)][hwi +repo], [Rust Bitcoin][rust bitcoin repo], [Serveur BTCPay][btcpay server repo], [BDK][bdk repo], +[Propositions d'Amélioration de Bitcoin (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Inquisition Bitcoin][bitcoin inquisition +repo], et [BINANAs][binana repo]._ + +- [Bitcoin Core #32582][] ajoute de nouveaux journaux pour mesurer la performance de + [reconstruction de bloc compact][topic compact block relay] en suivant la + taille totale des transactions qu'un nœud demande à ses pairs + (`getblocktxn`), le nombre et la taille totale des transactions qu'un nœud envoie + à ses pairs (`blocktxn`), et ajoutant un horodatage au début de + `PartiallyDownloadedBlock::InitData()` pour suivre combien de temps l'étape de recherche dans le + mempool prend seule (dans les modes à bande passante élevée et faible). Voir le Bulletin + [#315][news315 compact] pour un rapport de statistiques précédent sur la reconstruction de bloc + compact. + +- [Bitcoin Core #31375][] ajoute un nouvel outil CLI `bitcoin -m` qui enveloppe et + exécute les binaires [multiprocess][multiprocess project] `bitcoin node` + (`bitcoind`), `bitcoin gui` (`bitcoinqt`), `bitcoin rpc` (`bitcoin-cli-named`). + Actuellement, ceux-ci fonctionnent de la même manière que les binaires monolithiques, sauf + qu'ils prennent en charge l'option `-ipcbind` (voir le Bulletin + [#320][news320 ipc]), mais les améliorations futures permettront à un opérateur de nœud de + démarrer et arrêter les composants indépendamment sur différentes machines et + environnements. Voir le [Bulletin #353][news353 pr review] dans la section Bitcoin Core PR + Review Club couvrant ce point. + +- [BIPs #1483][] fusionne [BIP77][] qui propose [payjoin v2][topic payjoin], une + variante asynchrone sans serveur dans laquelle l'expéditeur et le récepteur passent leurs + PSBTs chiffrés à un serveur annuaire payjoin qui stocke et transmet uniquement + les messages. Comme l'annuaire ne peut ni lire ni modifier les charges utiles, aucun des + portefeuilles n'a besoin d'héberger un serveur public ou d'être en ligne en même temps. + Voir le Bulletin [#264][news264 payjoin] pour un contexte supplémentaire sur payjoin v2. + +{% include snippets/recap-ad.md when="2025-06-10 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32582,31375,1483" %} +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[ripple loss]: https://x.com/JoelKatz/status/1919233214750892305 +[sk nowit]: https://delvingbitcoin.org/t/witnessless-sync-for-pruned-nodes/1742/ +[sk nowit gist]: https://gist.github.com/JoseSK999/df0a2a014c7d9b626df1e2b19ccc7fb1 +[somsen nowit]: https://gist.github.com/JoseSK999/df0a2a014c7d9b626df1e2b19ccc7fb1?permalink_comment_id=5597316#gistcomment-5597316 +[shikelman quantum]: https://delvingbitcoin.org/t/bitcoin-et-le-calcul-quantique/1730/ +[sm report]: https://chaincode.com/bitcoin-post-quantum.pdf +[strnad limit]: https://delvingbitcoin.org/t/limite-de-poids-de-transaction-non-confiscatoire/1732/ +[problème du sac à dos]: https://fr.wikipedia.org/wiki/Probl%C3%A8me_du_sac_%C3%A0_dos +[sanders limit]: https://delvingbitcoin.org/t/limite-de-poids-de-transaction-non-confiscatoire/1732/2 +[maxwell limit]: https://delvingbitcoin.org/t/limite-de-poids-de-transaction-non-confiscatoire/1732/4 +[linus dust]: https://delvingbitcoin.org/t/expiry-de-la-poussière-nettoyer-lensemble-utxo-des-spams/1707/ +[lnd 0.19.1-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.1-beta.rc1 +[news315 compact]: /fr/newsletters/2024/08/09/#statistiques-sur-la-reconstruction-de-blocs-compacts +[multiprocess project]: https://github.com/ryanofsky/bitcoin/blob/pr/ipc/doc/design/multiprocess.md +[news320 ipc]: /fr/newsletters/2024/09/13/#bitcoin-core-30509 +[news264 payjoin]: /fr/newsletters/2023/08/16/#payjoin-sans-serveur +[news353 pr review]: /fr/newsletters/2025/05/09/#club-de-revue-de-pr-bitcoin-core \ No newline at end of file From fcb8c0192bb8651ee57e8a0f91a55aa981c09026 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sat, 21 Jun 2025 11:30:39 +0200 Subject: [PATCH 119/278] Update 2025-06-06-newsletter.md --- _posts/fr/newsletters/2025-06-06-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/fr/newsletters/2025-06-06-newsletter.md b/_posts/fr/newsletters/2025-06-06-newsletter.md index 4125c5dd1e..2e03ce9ae6 100644 --- a/_posts/fr/newsletters/2025-06-06-newsletter.md +++ b/_posts/fr/newsletters/2025-06-06-newsletter.md @@ -177,4 +177,4 @@ repo], et [BINANAs][binana repo]._ [multiprocess project]: https://github.com/ryanofsky/bitcoin/blob/pr/ipc/doc/design/multiprocess.md [news320 ipc]: /fr/newsletters/2024/09/13/#bitcoin-core-30509 [news264 payjoin]: /fr/newsletters/2023/08/16/#payjoin-sans-serveur -[news353 pr review]: /fr/newsletters/2025/05/09/#club-de-revue-de-pr-bitcoin-core \ No newline at end of file +[news353 pr review]: /fr/newsletters/2025/05/09/#bitcoin-core-pr-review-club \ No newline at end of file From b8c246ac6c26887394cbafceb6f386a215e5e185 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sat, 21 Jun 2025 14:07:24 +0200 Subject: [PATCH 120/278] Create 2025-06-13-newsletter.md --- .../fr/newsletters/2025-06-13-newsletter.md | 232 ++++++++++++++++++ 1 file changed, 232 insertions(+) create mode 100644 _posts/fr/newsletters/2025-06-13-newsletter.md diff --git a/_posts/fr/newsletters/2025-06-13-newsletter.md b/_posts/fr/newsletters/2025-06-13-newsletter.md new file mode 100644 index 0000000000..0502d28bac --- /dev/null +++ b/_posts/fr/newsletters/2025-06-13-newsletter.md @@ -0,0 +1,232 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #358' +permalink: /fr/newsletters/2025/06/13/ +name: 2025-06-13-newsletter-fr +slug: 2025-06-13-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +La newsletter de cette semaine décrit comment le seuil de danger du minage égoïste peut être +calculé, résume une idée pour prévenir le filtrage des transactions à frais élevés, sollicite des +retours sur une proposition de modification du BIP390 de descripteur `musig()`, et annonce une nouvelle +bibliothèque pour le chiffrement des descripteurs. Sont également inclus nos sections régulières +avec le résumé d'un Bitcoin Core PR Review Club, les annonces de nouvelles versions et candidates à +la sortie, et les descriptions des changements récents dans les projets d'infrastructure Bitcoin +populaires. + +## Nouvelles + +- **Calcul du seuil de danger du minage égoïste :** Antoine Poinsot a [publié][poinsot selfish] sur + Delving Bitcoin une expansion des calculs de l'article de 2013 [paper][es selfish] qui a donné + son nom à l'[attaque par minage égoïste][topic selfish mining] (bien que l'attaque ait été + [précédemment décrite][bytecoin selfish] en 2010). Il a également fourni un + [simulateur][darosior/miningsimulation] de minage et de relais de blocs simplifié qui permet + d'expérimenter avec l'attaque. Il se concentre sur la reproduction d'une des conclusions de + l'article de 2013 : qu'un mineur malhonnête (ou un cartel de mineurs bien connectés) contrôlant 33 % + du hashrate total du réseau, sans avantages supplémentaires, peut devenir marginalement plus + rentable à long terme que les mineurs contrôlant 67 % du hashrate. Ceci est réalisé en retardant + sélectivement l'annonce de certains des nouveaux blocs qu'il trouve. À mesure que le hashrate du + mineur malhonnête augmente au-dessus de 33 %, il devient encore plus rentable jusqu'à ce qu'il + dépasse 50 % du hashrate et puisse empêcher ses concurrents de conserver de nouveaux blocs sur la + meilleure blockchain. + + Nous n'avons pas examiné attentivement le post de Poinsot, mais son approche nous a semblé solide et + nous la recommanderions à quiconque intéressé à valider les calculs ou à mieux les comprendre. + +- **Résistance à la censure de relais par réconciliation de l'ensemble supérieur du mempool :** + Peter Todd a [posté][todd feerec] sur la liste de diffusion Bitcoin-Dev à propos d'un mécanisme qui + permettrait aux nœuds de se déconnecter des pairs qui filtrent les transactions à frais élevés. Le + mécanisme dépend du [mempool en cluster][topic cluster mempool] et d'un mécanisme de réconciliation + d'ensemble tel que celui utilisé par [erlay][topic erlay]. Un nœud utiliserait le mempool en cluster + pour calculer son ensemble de transactions non confirmées le plus rentable qui pourrait tenir dans + (par exemple) 8 000 000 d'unités de poids (un maximum de 8 MB). Chacun des pairs du nœud calculerait + également ses 8 MWU supérieurs de transactions non confirmées. En utilisant un algorithme hautement + efficace, tel que [minisketch][topic minisketch], le nœud réconcilierait son ensemble de + transactions avec chacun de ses pairs. Ce faisant, il apprendrait exactement quelles transactions + chaque pair a dans le haut de son mempool. Ensuite, le nœud se déconnecterait périodiquement du pair + ayant en moyenne le mempool le moins rentable. + + En se déconnectant des connexions les moins rentables, le nœud aurait + finalement trouvé des pairs qui étaient les moins susceptibles de filtrer les transactions à frais + élevés. Todd a mentionné qu'il espère travailler sur une implémentation après que le support du + mempool en cluster soit intégré dans Bitcoin Core. Il a attribué l'idée à Gregory Maxwell et à d'autres; + Optech a mentionné pour la première fois l'idée sous-jacente dans le [Bulletin #9][news9 reconcile]. + +- **Mise à jour de BIP390 pour permettre des clés de participants dupliquées dans les expressions `musig()`:** + Ava Chow a [posté][chow dupsig] sur la liste de diffusion Bitcoin-Dev pour demander si quelqu'un + s'opposait à la mise à jour de [BIP390][] pour permettre aux expressions `musig()` dans les + [descripteurs de script de sortie][topic descriptors] de contenir la même clé publique de + participant plus d'une fois. Cela simplifierait l'implémentation et est explicitement autorisé par + la spécification [BIP327][] de [MuSig2][topic musig]. À l'heure actuelle, personne ne s'est opposé, + et Chow a ouvert une [pull request][bips #1867] pour changer la spécification de BIP390. + +- **Bibliothèque de chiffrement de descripteur :** Josh Doman a [posté][doman descrypt] sur Delving + Bitcoin pour annoncer une bibliothèque qu'il a construite qui chiffre les parties sensibles d'un + [descripteur de script de sortie][topic descriptors] ou [miniscript][topic miniscript] aux clés + publiques contenues en son sein. Il décrit les informations nécessaires pour déchiffrer : + + > - Si votre portefeuille nécessite 2 clés sur 3 pour dépenser, il nécessitera exactement 2 clés sur + 3 pour déchiffrer. + > + > - Si votre portefeuille utilise une politique miniscript complexe comme "Soit 2 clés OU (un + timelock ET une autre clé)", le chiffrement suit la même structure, comme si tous les timelocks et + hash-locks sont satisfaits. + + Cela diffère du schéma de sauvegarde de descripteur chiffré discuté dans le [Bulletin #351][news351 + salvacrypt], dans lequel la connaissance de n'importe quelle clé publique contenue dans le + descripteur permet le déchiffrement du descripteur. Doman argue que son schéma offre une meilleure + confidentialité pour les cas où le descripteur chiffré est sauvegardé sur une source publique ou + semi-publique, comme une blockchain. + +## Bitcoin Core PR Review Club + +*Dans cette section mensuelle, nous résumons une récente réunion du [Bitcoin Core PR Review Club][], +en soulignant certaines des questions et réponses importantes. Cliquez sur une question ci-dessous +pour voir un résumé de la réponse de la réunion.* + +[Séparer l'accès à l'ensemble UTXO des fonctions de validation][review club 32317] est un PR de +[TheCharlatan][gh thecharlatan] qui permet d'appeler des fonctions de validation en passant juste +les UTXOs requis, au lieu de nécessiter l'ensemble UTXO complet. Il fait partie du projet +[`bitcoinkernel`][Bitcoin Core #27587], et est une étape importante pour rendre la bibliothèque plus +utilisable pour les implémentations de nœuds complets qui n'implémentent pas un ensemble UTXO, comme +les nœuds [Utreexo][topic utreexo] ou [SwiftSync][somsen swiftsync] (voir le [Bulletin #349][news349 +swiftsync]). + +Dans les 4 premiers commits, ce PR réduit le couplage entre les fonctions de validation des +transactions et l'ensemble UTXO en exigeant que l'appelant récupère d'abord les `Coin`s ou `CTxOut`s +dont ils ont besoin et en les passant à la fonction de validation, au lieu de permettre à la +fonction de validation d'accéder directement à l'ensemble UTXO. +Dans les commits suivants, la dépendance de `ConnectBlock()` par rapport à l'ensemble UTXO est +entièrement supprimée en extrayant la logique restante nécessitant une interaction avec l'ensemble +UTXO dans une méthode séparée `SpendBlock()`. + +{% include functions/details-list.md + q0="Pourquoi est-il utile d'extraire la nouvelle fonction `SpendBlock()` de `ConnectBlock()` pour + cette PR ? Comment compareriez-vous le but des deux fonctions ?" + a0="La fonction `ConnectBlock()` effectuait à l'origine à la fois la validation des blocs et les + modifications de l'ensemble UTXO. Cette refactortorisation divise ces responsabilités : `ConnectBlock()` est + maintenant uniquement responsable de la logique de validation qui ne nécessite pas l'ensemble UTXO, + tandis que la nouvelle fonction `SpendBlock()` gère toutes les interactions avec l'ensemble UTXO. + Cela permet à un appelant d'utiliser `ConnectBlock()` pour effectuer la validation des blocs sans un + ensemble UTXO." + a0link="https://bitcoincore.reviews/32317#l-37" + + q1="Voyez-vous un autre avantage à cette séparation, à part permettre l'utilisation du noyau sans un + ensemble UTXO ?" + a1="Outre la possibilité d'utiliser le noyau pour des projets sans ensemble UTXO, cette séparation + rend le code plus facile à tester isolément et plus simple à maintenir. Un examinateur note + également que la suppression de la nécessité d'accéder à l'ensemble UTXO ouvre la porte à la + validation des blocs en parallèle, ce qui est une caractéristique importante de SwiftSync." + a1link="https://bitcoincore.reviews/32317#l-64" + + q2="`SpendBlock()` prend un `CBlock block`, `CBlockIndex pindex` et `uint256 block_hash` en + paramètres, tous faisant référence au bloc dépensé. Pourquoi avons-nous besoin de 3 paramètres pour + cela ?" + a2="Le code de validation est critique en termes de performance, il affecte des paramètres + importants tels que la vitesse de propagation des blocs. Calculer le hash d'un bloc à partir d'un + `CBlock` ou d'un `CBlockIndex` n'est pas gratuit, car la valeur n'est pas mise en cache. Pour cette + raison, l'auteur a décidé de prioriser la performance en passant un `block_hash` déjà calculé comme + paramètre séparé. De même, le `pindex` pourrait être récupéré à partir de l'index des blocs, mais + cela impliquerait une recherche supplémentaire dans une map qui n'est pas strictement nécessaire. +
_Note : l'auteur a plus tard [changé][32317 updated approach] l'approche, en supprimant + l'optimisation de performance `block_hash`._" + a2link="https://bitcoincore.reviews/32317#l-97" + + q3="Les premiers commits de cette PR refactorisent `CCoinsViewCache` hors de la signature de + fonction de plusieurs fonctions de validation. Est-ce que `CCoinsViewCache` contient l'ensemble UTXO + complet ? Pourquoi est-ce (ou pas) un problème ? Cette PR change-t-elle ce comportement ?" + a3="`CCoinsViewCache` ne contient pas l'ensemble UTXO complet ; c'est un cache en mémoire qui se + trouve devant `CCoinsViewDB`, qui stocke l'ensemble UTXO complet sur le disque. Si une pièce demandée + n'est pas dans le cache, elle doit être récupérée depuis le disque. Cette PR ne change pas ce + comportement de mise en cache en soi. En retirant `CCoinsViewCache` des signatures de fonction, cela + rend la dépendance UTXO explicite, nécessitant que l'appelant récupère les pièces avant d'appeler la + fonction de validation." + a3link="https://bitcoincore.reviews/32317#l-116"%} +%} + +## Mises à jour et versions candidates + +_Nouvelles versions et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de mettre à niveau vers les nouvelles versions ou d'aider à tester les versions candidates._ + +- [Core Lightning 25.05rc1][] est un candidat à la version pour la prochaine version majeure de + cette implémentation populaire de nœud LN. + +- [LND 0.19.1-beta][] est une version de maintenance de cette implémentation populaire de nœud LN. + Elle [contient][lnd rn] de multiples corrections de bugs. + +## Changements de code et de documentation notables + +_Changements récents dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core +lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], +[libsecp256k1][libsecp256k1 repo], [Interface de Portefeuille Matériel (HWI)][hwi repo], [Rust +Bitcoin][rust bitcoin repo], [Serveur BTCPay][btcpay server repo], [BDK][bdk repo], [Propositions +d'Amélioration de Bitcoin (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips +repo], [Inquisition Bitcoin][bitcoin inquisition repo], et [BINANAs][binana repo]._ + +- [Bitcoin Core #32406][] supprime la limite de taille de sortie `OP_RETURN` (règle de + standardisation) en augmentant le paramètre `-datacarriersize` par défaut de 83 à 100 000 octets (la + limite de taille maximale de transaction). Les options `-datacarrier` et `-datacarriersize` restent, + mais sont marquées comme obsolètes et devraient être retirées dans une future version non + déterminée. De plus, ce PR lève également la restriction de politique d'une par transaction pour les + sorties OP_RETURN, et la limite de taille est maintenant allouée à travers toutes ces sorties dans + une transaction. Voir le [Bulletin #352][news352 opreturn] pour un contexte supplémentaire sur ce + changement. + +- [LDK #3793][] ajoute un nouveau message `start_batch` qui signale aux pairs de traiter les `n` + messages suivants (`batch_size`) comme une seule unité logique. Il met également à jour + `PeerManager` pour s'appuyer sur cela pour les messages `commitment_signed` pendant le + [splicing][topic splicing], plutôt que d'ajouter un TLV et un champ `batch_size` à chaque message + dans le lot. C'est une tentative de permettre à des messages de protocole LN supplémentaires d'être + regroupés plutôt que seulement les messages `commitment_signed`, qui sont les seuls regroupements + définis dans la spécification LN. + +- [LDK #3792][] introduit un support initial pour les [transactions d'engagement v3][topic v3 + commitments] (voir le [Bulletin #325][news325 v3]) qui s'appuient sur les [transactions TRUC][topic + v3 transaction relay] et les [ancres éphémères][topic ephemeral anchors], derrière un drapeau de + test. Un nœud rejette maintenant toute proposition `open_channel` qui définit un taux de frais non + nul, s'assure qu'il n'initie jamais de tels canaux lui-même, et arrête d'accepter automatiquement + les canaux v3 pour d'abord réserver un UTXO pour une augmentation de frais ultérieure. Le PR abaisse + également la limite [HTLC][topic htlc] par canal de 483 à 114 parce que les transactions TRUC + doivent rester en dessous de 10 kvB. + + - [LND #9127][] ajoute une option `--blinded_path_incoming_channel_list` à la commande `lncli addinvoice`, + permettant à un destinataire d'intégrer un ou plusieurs (pour de multiples sauts) ID de + canaux préférés pour que le payeur tente de les emprunter via un [chemin aveuglé][topic rv routing]. + +- [LND #9858][] commence à signaler le bit de fonctionnalité de production 61 pour le flux de + fermeture coopérative [RBF][topic rbf] (voir le [Bulletin #347][news347 rbf]) pour permettre une + interopérabilité correcte avec Eclair. Il conserve le bit de mise en scène 161 pour maintenir + l'interopérabilité avec les nœuds testant la fonctionnalité. + +- [BOLTs #1243][] met à jour la spécification [BOLT11][] pour indiquer qu'un lecteur (expéditeur) ne + doit pas payer une facture si un champ obligatoire, tel que p (hash de paiement), h (hash de + description), ou s (secret), a une longueur incorrecte. Auparavant, les nœuds pouvaient ignorer ce + problème. Cette PR ajoute également une note à la section Exemples expliquant que les [signatures + Low R][topic low-r grinding], même si elles économisent un octet d'espace, ne sont pas imposées dans + la spécification. + +{% include snippets/recap-ad.md when="2025-06-17 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32406,3793,3792,9127,1867,9858,1243,27587" %} +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[lnd 0.19.1-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.1-beta +[poinsot selfish]: https://delvingbitcoin.org/t/where-does-the-33-33-threshold-for-selfish-mining-come-from/1757 +[bytecoin selfish]: https://bitcointalk.org/index.php?topic=2227.msg30083#msg30083 +[darosior/miningsimulation]: https://github.com/darosior/miningsimulation +[todd feerec]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aDWfDI03I-Rakopb@petertodd.org/ +[news9 reconcile]: /en/newsletters/2018/08/21/#bandwidth-efficient-set-reconciliation-protocol-for-transactions +[chow dupsig]: https://mailing-list.bitcoindevs.xyz/bitcoindev/08dbeffd-64ec-4ade-b297-6d2cbeb5401c@achow101.com/ +[doman descrypt]: https://delvingbitcoin.org/t/rust-descriptor-encrypt-encrypt-any-descriptor-such-that-only-authorized-spenders-can-decrypt/1750/ +[news351 salvacrypt]: /fr/newsletters/2025/04/25/#sauvegarde-standardisee-pour-les-descripteurs-de-portefeuille +[es selfish]: https://arxiv.org/pdf/1311.0243 +[lnd rn]: https://github.com/lightningnetwork/lnd/blob/v0.19.1-beta/docs/release-notes/release-notes-0.19.1.md +[news352 opreturn]: /fr/newsletters/2025/05/02/#augmentation-ou-suppression-de-la-limite-de-taille-op-return-de-bitcoin-core +[news325 v3] : /fr/newsletters/2024/10/18/#transactions-d-engagement-de-version-3 +[news347 rbf] : /fr/newsletters/2025/03/28/#lnd-8453 +[club de révision 32317] : https://bitcoincore.reviews/32317 +[gh thecharlatan] : https://github.com/TheCharlatan +[somsen swiftsync] : https://gist.github.com/RubenSomsen/a61a37d14182ccd78760e477c78133cd +[approche mise à jour 32317] : https://github.com/bitcoin/bitcoin/pull/32317#issuecomment-2883841466 +[news349 swiftsync] : /fr/newsletters/2025/04/11/#acceleration-swiftsync-pour-le-telechargement-initial-des-blocs \ No newline at end of file From 4b263874550071bbbb979c60a85c2c5b4558b325 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sat, 21 Jun 2025 14:52:16 +0200 Subject: [PATCH 121/278] Update 2025-06-13-newsletter.md --- _posts/fr/newsletters/2025-06-13-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/fr/newsletters/2025-06-13-newsletter.md b/_posts/fr/newsletters/2025-06-13-newsletter.md index 0502d28bac..76238ff750 100644 --- a/_posts/fr/newsletters/2025-06-13-newsletter.md +++ b/_posts/fr/newsletters/2025-06-13-newsletter.md @@ -142,7 +142,7 @@ UTXO dans une méthode séparée `SpendBlock()`. comportement de mise en cache en soi. En retirant `CCoinsViewCache` des signatures de fonction, cela rend la dépendance UTXO explicite, nécessitant que l'appelant récupère les pièces avant d'appeler la fonction de validation." - a3link="https://bitcoincore.reviews/32317#l-116"%} + a3link="https://bitcoincore.reviews/32317#l-116"%}" %} ## Mises à jour et versions candidates From 251ec16866e145681abace9fe06cd385b20dd5bf Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sat, 21 Jun 2025 15:11:12 +0200 Subject: [PATCH 122/278] Update 2025-06-13-newsletter.md --- _posts/fr/newsletters/2025-06-13-newsletter.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/_posts/fr/newsletters/2025-06-13-newsletter.md b/_posts/fr/newsletters/2025-06-13-newsletter.md index 76238ff750..04604279bd 100644 --- a/_posts/fr/newsletters/2025-06-13-newsletter.md +++ b/_posts/fr/newsletters/2025-06-13-newsletter.md @@ -223,10 +223,10 @@ repo], [Inquisition Bitcoin][bitcoin inquisition repo], et [BINANAs][binana repo [es selfish]: https://arxiv.org/pdf/1311.0243 [lnd rn]: https://github.com/lightningnetwork/lnd/blob/v0.19.1-beta/docs/release-notes/release-notes-0.19.1.md [news352 opreturn]: /fr/newsletters/2025/05/02/#augmentation-ou-suppression-de-la-limite-de-taille-op-return-de-bitcoin-core -[news325 v3] : /fr/newsletters/2024/10/18/#transactions-d-engagement-de-version-3 -[news347 rbf] : /fr/newsletters/2025/03/28/#lnd-8453 -[club de révision 32317] : https://bitcoincore.reviews/32317 -[gh thecharlatan] : https://github.com/TheCharlatan -[somsen swiftsync] : https://gist.github.com/RubenSomsen/a61a37d14182ccd78760e477c78133cd -[approche mise à jour 32317] : https://github.com/bitcoin/bitcoin/pull/32317#issuecomment-2883841466 -[news349 swiftsync] : /fr/newsletters/2025/04/11/#acceleration-swiftsync-pour-le-telechargement-initial-des-blocs \ No newline at end of file +[news325 v3]: /fr/newsletters/2024/10/18/#transactions-d-engagement-de-version-3 +[news347 rbf]: /fr/newsletters/2025/03/28/#lnd-8453 +[club de révision 32317]: https://bitcoincore.reviews/32317 +[gh thecharlatan]: https://github.com/TheCharlatan +[somsen swiftsync]: https://gist.github.com/RubenSomsen/a61a37d14182ccd78760e477c78133cd +[approche mise à jour 32317]: https://github.com/bitcoin/bitcoin/pull/32317#issuecomment-2883841466 +[news349 swiftsync]: /fr/newsletters/2025/04/11/#acceleration-swiftsync-pour-le-telechargement-initial-des-blocs \ No newline at end of file From fe2e6c140baca91fa2723b283f95d77dec3f2499 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sat, 21 Jun 2025 15:21:17 +0200 Subject: [PATCH 123/278] Update 2025-06-13-newsletter.md --- _posts/fr/newsletters/2025-06-13-newsletter.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_posts/fr/newsletters/2025-06-13-newsletter.md b/_posts/fr/newsletters/2025-06-13-newsletter.md index 04604279bd..6d9d39e760 100644 --- a/_posts/fr/newsletters/2025-06-13-newsletter.md +++ b/_posts/fr/newsletters/2025-06-13-newsletter.md @@ -225,8 +225,8 @@ repo], [Inquisition Bitcoin][bitcoin inquisition repo], et [BINANAs][binana repo [news352 opreturn]: /fr/newsletters/2025/05/02/#augmentation-ou-suppression-de-la-limite-de-taille-op-return-de-bitcoin-core [news325 v3]: /fr/newsletters/2024/10/18/#transactions-d-engagement-de-version-3 [news347 rbf]: /fr/newsletters/2025/03/28/#lnd-8453 -[club de révision 32317]: https://bitcoincore.reviews/32317 +[review club 32317]: https://bitcoincore.reviews/32317 [gh thecharlatan]: https://github.com/TheCharlatan [somsen swiftsync]: https://gist.github.com/RubenSomsen/a61a37d14182ccd78760e477c78133cd -[approche mise à jour 32317]: https://github.com/bitcoin/bitcoin/pull/32317#issuecomment-2883841466 +[32317 updated approach]: https://github.com/bitcoin/bitcoin/pull/32317#issuecomment-2883841466 [news349 swiftsync]: /fr/newsletters/2025/04/11/#acceleration-swiftsync-pour-le-telechargement-initial-des-blocs \ No newline at end of file From 398002f9896239489b3aae7623dbe109fc807a87 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Mon, 23 Jun 2025 12:21:45 +0200 Subject: [PATCH 124/278] Newsletter 359 translate in French (#2391) --- .../fr/newsletters/2025-06-20-newsletter.md | 172 ++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 _posts/fr/newsletters/2025-06-20-newsletter.md diff --git a/_posts/fr/newsletters/2025-06-20-newsletter.md b/_posts/fr/newsletters/2025-06-20-newsletter.md new file mode 100644 index 0000000000..593886ea9a --- /dev/null +++ b/_posts/fr/newsletters/2025-06-20-newsletter.md @@ -0,0 +1,172 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #359' +permalink: /fr/newsletters/2025/06/20/ +name: 2025-06-20-newsletter-fr +slug: 2025-06-20-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +La newsletter de cette semaine décrit une proposition visant à limiter la participation du public +dans les dépôts de Bitcoin Core, annonce des améliorations significatives pour les contrats de style +BitVM, et résume la recherche sur le rééquilibrage des canaux LN. Sont également incluses nos +sections régulières résumant les changements récents apportés aux clients et services, les +annonces de nouvelles versions et de candidats à la publication, et les résumés des modifications +notables apportées aux logiciels d'infrastructure Bitcoin populaires. + +## Nouvelles + +- **Proposition pour restreindre l'accès à la discussion du projet Bitcoin Core :** + Bryan Bishop a [posté][bishop priv] sur la liste de diffusion Bitcoin-Dev pour + suggérer que le projet Bitcoin Core limite la capacité du public à + participer aux discussions du projet afin de réduire la quantité + de perturbations causées par les non-contributeurs. Il a appelé cela + "privatiser Bitcoin Core", + pointant des exemples de cette privatisation se produisant déjà sur une base ad + hoc dans des bureaux privés avec plusieurs contributeurs de Bitcoin Core, + et avertit que la privatisation en personne exclut les contributeurs à distance. + + Le post de Bishop suggère une méthode pour la privatisation en ligne, mais + Antoine Poinsot a [questionné][poinsot priv] si cette méthode + atteindrait l'objectif. Poinsot a également suggéré que de nombreuses discussions en bureau privé + pourraient se produire non pas par peur du reproche public mais + en raison des "avantages naturels des discussions en personne". + + Plusieurs réponses ont suggéré que faire des changements majeurs n'est + probablement pas justifié à ce moment mais qu'une modération plus forte des + commentaires sur le dépôt pourrait atténuer le type le plus + significatif de perturbation. Cependant, d'autres réponses ont noté plusieurs + défis liés à une modération plus forte. + + Poinsot, Sebastian "The Charlatan" Kung, et Russell Yanofsky---les seuls contributeurs très + actifs de Bitcoin Core à répondre au fil jusqu'à la rédaction de cet article---[ont indiqué][kung + priv] soit [que][yanofsky priv] ils ne pensent pas qu'un changement majeur soit nécessaire, soit que + tout changement devrait se faire progressivement au fil du temps. + +- **Améliorations des contrats de style BitVM :** Robin Linus a [posté][linus + bitvm3] sur Delving Bitcoin pour annoncer une réduction significative de la + quantité d'espace sur la chaîne requise par les contrats de style [BitVM][topic acc]. + Basé sur une [idée][rubin garbled] de Jeremy Rubin qui + s'appuie sur de nouveaux primitives cryptographiques, la nouvelle approche "réduit le + coût sur la chaîne d'un litige de plus de 1 000 fois par rapport à la conception précédente", avec + des transactions de réfutation étant "juste de 200 octets". + + Cependant, le document de Linus note le compromis pour cette approche : elle + "nécessite une configuration de données offchain de plusieurs téraoctets". Le document donne un + exemple d'un circuit vérificateur SNARK avec environ 5 milliards de portes et + des paramètres de sécurité raisonnables nécessitant une configuration offchain de 5 To, 56 kB + de transaction onchain pour affirmer le résultat, et une transaction onchain minimale + (~200 B) dans le cas où une partie doit prouver que l'affirmation était invalide. + +- **Recherche sur le rééquilibrage des canaux :** Rene Pickhardt a [posté][pickhardt + rebalance] sur Delving Bitcoin ses réflexions sur le rééquilibrage des canaux + pour maximiser le taux de paiements réussis à travers + le réseau entier. Ses idées peuvent être comparées à des approches qui examinent des groupes plus + petits de canaux, tels que le [rééquilibrage entre amis][topic jit routing] (voir le [Bulletin + #54][news54 foaf rebalance]). + + Pickhardt note qu'il existe plusieurs défis à une approche globale et demande aux parties + intéressées de répondre à quelques questions, telles que si cette approche vaut la peine d'être + poursuivie et comment aborder certains détails de mise en œuvre. + +## Changements dans les services et logiciels clients + +*Dans cette rubrique mensuelle, nous mettons en lumière des mises à jour intéressantes des +portefeuilles et services Bitcoin.* + +- **Cove v1.0.0 publié :** + Les récentes [versions][cove github] de Cove incluent le support du contrôle des pièces et des + fonctionnalités supplémentaires de libellé de portefeuille [BIP329][]. + +- **Liana v11.0 publié :** + Les récentes [versions][liana github] de Liana incluent des fonctionnalités pour plusieurs + portefeuilles, des fonctionnalités de contrôle des pièces supplémentaires, et plus de support pour + les dispositifs de signature matérielle, parmi d'autres fonctionnalités. + +- **Démonstration de preuve STARK Stratum v2 :** + StarkWare a [démontré][starkware tweet] un client de minage [Stratum v2 modifié][starkware sv2] + utilisant une preuve STARK pour prouver que les frais d'un bloc appartiennent à un modèle de bloc + valide sans révéler les transactions dans le bloc. + +- **Breez SDK ajoute BOLT12 et BIP353 :** + Breez SDK Nodeless [0.9.0][breez github] ajoute le support pour la réception en utilisant [BOLT12][] + et [BIP353]. + +## Mises à jour et versions candidates + +_Nouvelles versions et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de mettre à niveau vers les nouvelles versions ou d'aider à tester les versions candidates._ + +- [Core Lightning 25.05][] est une sortie de la prochaine version majeure de cette implémentation + populaire de nœud LN. Elle réduit la latence de transmission et de résolution des paiements, + améliore la gestion des frais, fournit un support de [splicing][topic splicing] compatible avec + Eclair, et active le [stockage des pairs][topic peer storage] par défaut. Note : sa [documentation + de sortie][core lightning 25.05] contient un avertissement pour les utilisateurs de l'option de + configuration `--experimental-splicing`. + +## Changements notables dans le code et la documentation + +_Changements notables récents dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core +lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], +[libsecp256k1][libsecp256k1 repo], [Interface de Portefeuille Matériel (HWI)][hwi repo], [Rust +Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Propositions +d'Amélioration de Bitcoin (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips +repo], [Inquisition Bitcoin][bitcoin inquisition repo], et [BINANAs][binana repo]._ + +- [Eclair #3110][] augmente le délai pour marquer un canal comme fermé après que sa sortie de + financement est dépensée de 12 (voir le Bulletin [#337][news337 delay]) à 72 blocs comme spécifié + dans [BOLTs #1270][], pour permettre la propagation d'une mise à jour de [splice][topic splicing]. + Il a été augmenté parce que certaines implémentations par défaut, attendent 8 confirmations + avant d'envoyer `splice_locked` et permettre aux opérateurs de + nœuds d'augmenter ce seuil, donc 12 blocs se sont avérés trop courts. Le délai est maintenant + configurable à des fins de test et pour permettre aux opérateurs de nœuds d'attendre plus longtemps. + +- [Eclair #3101][] introduit le RPC `parseoffer`, qui décode les champs d'[offre BOLT12][topic + offers] en un format lisible par l'homme, permettant aux utilisateurs de voir le montant avant de le + passer au RPC `payoffer`. Ce dernier est étendu pour accepter un montant spécifié dans une devise + fiat. + +- [LDK #3817][] revient sur le support des [échecs attribuables][topic attributable failures] (voir + le Bulletin [#349][news349 attributable]) en le plaçant sous un drapeau de test uniquement. Cela + désactive la logique de pénalisation des pairs et retire la fonctionnalité TLV des messages d'échec + en [onion][topic onion messages]. Les nœuds qui n'avaient pas encore été mis à jour étaient pénalisés à + tort, montrant qu'une adoption plus large du réseau est nécessaire pour que cela fonctionne correctement. + +- [LDK #3623][] étend le [stockage de pairs][topic peer storage] (voir le Bulletin [#342][news342 + peer]) pour fournir des sauvegardes de pairs automatiques et cryptées. À chaque bloc, `ChainMonitor` + emballe les données d'une structure `ChannelMonitor` versionnée, horodatée et sérialisée dans un + blob `OurPeerStorage`. Ensuite, il crypte les données et déclenche un événement `SendPeerStorage` + pour relayer le blob comme un message `peer_storage` à chaque pair de canal. De plus, + `ChannelManager` est mis à jour pour gérer les demandes de `peer_storage_retrieval` en déclenchant + un nouvel envoi de blob. + +- [BTCPay Server #6755][] améliore l'interface utilisateur de contrôle des pièces avec de nouveaux + filtres de montant minimum et maximum, des filtres de date de création avant et après, une section + d'aide pour les filtres, une case à cocher "sélectionner tout" pour les UTXO, et des options de + taille de page importante (100, 200 ou 500 UTXO). + +- [Rust libsecp256k1 #798][] complète l'implémentation de [MuSig2][topic musig] dans la + bibliothèque, donnant aux projets en aval accès à un protocole de [multisignature sans script][topic + multisignature] robuste. + +{% include snippets/recap-ad.md when="2025-06-24 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="3110,3101,3817,3623,6755,1270" %} +[Core Lightning 25.05]: https://github.com/ElementsProject/lightning/releases/tag/v25.05 +[bishop priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com/ +[poinsot priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235xaDlhg35nY8Zn7g1siy3IADHvSHyCcgTHrJorMKcDzZg=@protonmail.com/ +[kung priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/58813483-7351-487e-8f7f-82fb18a4c808n@googlegroups.com/ +[linus bitvm3]: https://delvingbitcoin.org/t/garbled-circuits-and-bitvm3/1773 +[rubin garbled]: https://rubin.io/bitcoin/2025/04/04/delbrag/ +[pickhardt rebalance]: https://delvingbitcoin.org/t/research-update-a-geometric-approach-for-optimal-channel-rebalancing/1768 +[rust libsecp256k1 #798]: https://github.com/rust-bitcoin/rust-secp256k1/pull/798 +[news54 foaf rebalance]: /en/newsletters/2019/07/10/#brainstorming-just-in-time-routing-and-free-channel-rebalancing +[yanofsky priv]: https://github.com/bitcoin-core/meta/issues/19#issuecomment-2961177626 +[cove github]: https://github.com/bitcoinppl/cove/releases +[liana github]: https://github.com/wizardsardine/liana/releases +[breez github]: https://github.com/breez/breez-sdk-liquid/releases/tag/0.9.0 +[starkware tweet]: https://x.com/dimahledba/status/1935354385795592491 +[starkware sv2]: https://github.com/keep-starknet-strange/stratum +[news337 delay]: /fr/newsletters/2025/01/17/#eclair-2936 +[news349 attributable]: /fr/newsletters/2025/04/11/#ldk-2256 +[news342 peer]: /fr/newsletters/2025/02/21/#ldk-3575 \ No newline at end of file From 1250ab2ce0acf7d0212451541e895b18434385ae Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Mon, 23 Jun 2025 12:23:44 +0200 Subject: [PATCH 125/278] Newsletter 359 translate in German (#2392) Co-authored-by: garfiel-d --- .../de/newsletters/2025-06-20-newsletter.md | 196 ++++++++++++++++++ 1 file changed, 196 insertions(+) create mode 100644 _posts/de/newsletters/2025-06-20-newsletter.md diff --git a/_posts/de/newsletters/2025-06-20-newsletter.md b/_posts/de/newsletters/2025-06-20-newsletter.md new file mode 100644 index 0000000000..ded3205d3d --- /dev/null +++ b/_posts/de/newsletters/2025-06-20-newsletter.md @@ -0,0 +1,196 @@ +--- +title: 'Bitcoin Optech Newsletter #359' +permalink: /de/newsletters/2025/06/20/ +name: 2025-06-20-newsletter-de +slug: 2025-06-20-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche beschreibt einen Vorschlag, die öffentliche +Teilnahme an den Bitcoin-Core-Repositories zu beschränken, kündigt eine +signifikante Verbesserung bei BitVM-artigen Verträgen an und fasst die +Forschung zum Rebalancing von LN-Channels zusammen. Ebenfalls enthalten +sind unsere regulären Abschnitte mit Zusammenfassungen der jüngsten +Änderungen an Clients und Diensten, Ankündigungen neuer Releases und +Release-Kandidaten sowie Beschreibungen der jüngsten Änderungen an +populärer Bitcoin-Infrastruktursoftware. + +## Nachrichten + +- **Vorschlag zur Beschränkung des Zugangs zur Diskussion im Bitcoin-Core-Projekt:** + Bryan Bishop [postete][bishop priv] in der Bitcoin-Dev-Mailingliste den + Vorschlag, dass das Bitcoin-Core-Projekt die Möglichkeit der Öffentlichkeit + zur Teilnahme an Projekt-Diskussionen einschränken sollte, um die durch + Nicht-Beitragende verursachten Störungen zu reduzieren. Er nannte dies die + „Privatisierung von Bitcoin Core“, verweist auf Beispiele, bei denen diese + Privatisierung bereits ad hoc in privaten Büros mit mehreren + Bitcoin-Core-Mitwirkenden stattfindet, und warnt davor, dass eine + persönliche Privatisierung entfernte Mitwirkende ausschließt. + + Bishops Beitrag schlägt eine Methode zur Online-Privatisierung vor, aber + Antoine Poinsot [stellte in Frage][poinsot priv], ob diese Methode das Ziel + erreichen würde. Poinsot legte auch nahe, dass viele private Bürodiskussionen + nicht aus Angst vor öffentlicher Kritik stattfinden könnten, sondern wegen + der „natürlichen Vorteile von persönlichen Diskussionen“. + + Mehrere Antworten deuteten darauf hin, dass größere Änderungen derzeit + wahrscheinlich nicht gerechtfertigt sind, aber eine stärkere Moderation von + Kommentaren im Repository die bedeutendste Art von Störung lindern könnte. + Andere Antworten wiesen jedoch auf mehrere Herausforderungen bei einer + stärkeren Moderation hin. + + Poinsot, Sebastian „The Charlatan“ Kung und Russell Yanofsky – die einzigen + sehr aktiven Bitcoin-Core-Mitwirkenden, die zum Zeitpunkt des Schreibens auf + den Thread geantwortet haben – [gaben entweder an][kung priv], + [dass][yanofsky priv] sie keine größere Änderung für notwendig halten oder + dass alle Änderungen schrittweise im Laufe der Zeit vorgenommen werden + sollten. + +- **Verbesserungen bei BitVM-artigen Verträgen:** + Robin Linus [postete][linus bitvm3] auf Delving Bitcoin, um eine signifikante + Reduzierung des On-Chain-Speicherplatzes anzukündigen, der für + [BitVM][topic acc]-artige Verträge benötigt wird. Basierend auf einer + [Idee][rubin garbled] von Jeremy Rubin, die auf neuen kryptografischen + Grundbausteinen aufbaut, reduziert der neue Ansatz „die On-Chain-Kosten eines + Streitfalls um mehr als das 1.000-fache im Vergleich zum vorherigen Design“, + wobei Widerlegungstransaktionen „nur 200 Bytes“ groß sind. + + Allerdings weist Linus' Paper auf den Kompromiss dieses Ansatzes hin: Er + „erfordert ein Multi-Terabyte-Off-Chain-Daten-Setup“. Das Paper gibt ein + Beispiel für eine SNARK-Verifizierer-Schaltung mit etwa 5 Milliarden Gattern + und vernünftigen Sicherheitsparametern, die ein 5 TB Off-Chain-Setup, eine + 56 kB On-Chain-Transaktion zur Bestätigung des Ergebnisses und eine minimale + On-Chain-Transaktion (~200 B) erfordert, falls eine Partei beweisen muss, + dass die Bestätigung ungültig war. + +- **Forschung zum Channel-Rebalancing:** + Rene Pickhardt [postete][pickhardt rebalance] auf Delving Bitcoin Gedanken + zum Rebalancing von Channels, um die Rate erfolgreicher Zahlungen im + gesamten Netzwerk zu maximieren. Seine Ideen können mit Ansätzen verglichen + werden, die kleinere Gruppen von Channels betrachten, wie z.B. das + [Friend-of-a-Friend-Rebalancing][topic jit routing] (siehe + [Newsletter #54][news54 foaf rebalance]). + + Pickhardt stellt fest, dass es bei einem globalen Ansatz mehrere + Herausforderungen gibt, und bittet Interessierte, einige Fragen zu + beantworten, z.B. ob dieser Ansatz verfolgenswert ist und wie bestimmte + Implementierungsdetails angegangen werden können. + +## Änderungen an Diensten und Client-Software + +*In diesem monatlichen Abschnitt heben wir interessante Updates für +Bitcoin-Wallets und -Dienste hervor.* + +- **Cove v1.0.0 veröffentlicht:** + Die jüngsten Cove-[Releases][cove github] beinhalten + Coin-Control-Unterstützung und zusätzliche + [BIP329][]-Wallet-Label-Funktionen. + +- **Liana v11.0 veröffentlicht:** + Die jüngsten [Releases][liana github] von Liana beinhalten Funktionen für + mehrere Wallets, zusätzliche Coin-Control-Funktionen und mehr Unterstützung + für Hardware-Signiergeräte, neben anderen Funktionen. + +- **Stratum v2 STARK-Proof-Demo:** + StarkWare [demonstrierte][starkware tweet] einen [modifizierten Stratum v2 + Mining-Client][starkware sv2], der einen STARK-Proof verwendet, um zu + beweisen, dass die Gebühren eines Blocks zu einem gültigen Block-Template + gehören, ohne die Transaktionen im Block preiszugeben. + +- **Breez SDK fügt BOLT12 und BIP353 hinzu:** + Breez SDK Nodeless [0.9.0][breez github] fügt Unterstützung für den Empfang + mit [BOLT12][] und [BIP353] hinzu. + +## Releases und Release-Kandidaten + +*Neue Releases und Release-Kandidaten für populäre +Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie, auf neue Releases zu +aktualisieren oder beim Testen von Release-Kandidaten zu helfen.* + +- [Core Lightning 25.05][] ist ein Release der nächsten Hauptversion dieser + populären LN-Knoten-Implementierung. Es reduziert die Latenz bei der + Weiterleitung und Auflösung von Zahlungen, verbessert das Gebührenmanagement, + bietet mit Eclair kompatible [Splicing][topic splicing]-Unterstützung und + aktiviert standardmäßig [Peer Storage][topic peer storage]. Hinweis: Die + [Release-Dokumentation][core lightning 25.05] enthält eine Warnung für + Benutzer der Konfigurationsoption `--experimental-splicing`. + +## Wichtige Code- und Dokumentationsänderungen + +*Bemerkenswerte aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], +[Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], +[BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], +[Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin +Inquisition][bitcoin inquisition repo] und [BINANAs][binana repo].* + +- [Eclair #3110][] erhöht die Verzögerung für das Markieren eines Channels als + geschlossen, nachdem sein Finanzierungs-Output ausgegeben wurde, von 12 + (siehe Newsletter [#337][news337 delay]) auf 72 Blöcke, wie in [BOLTs + #1270][] spezifiziert, um die Verbreitung eines [Splicing][topic + splicing]-Updates zu ermöglichen. Sie wurde erhöht, weil einige + Implementierungen standardmäßig 8 Bestätigungen abwarten, bevor sie + `splice_locked` senden, und es Knoten-Betreibern erlauben, diesen + Schwellenwert zu erhöhen, sodass sich 12 Blöcke als zu kurz erwiesen. Die + Verzögerung ist jetzt zu Testzwecken konfigurierbar und ermöglicht es + Knoten-Betreibern, länger zu warten. + +- [Eclair #3101][] führt den `parseoffer`-RPC ein, der [BOLT12-Offer][topic + offers]-Felder in ein menschenlesbares Format dekodiert, sodass Benutzer den + Betrag anzeigen können, bevor sie ihn an den `payoffer`-RPC übergeben. + Letzterer wird erweitert, um einen in einer Fiat-Währung angegebenen Betrag + zu akzeptieren. + +- [LDK #3817][] rollt die Unterstützung für [attributable failures(zurechenbare Fehler)][topic + attributable failures] (siehe Newsletter [#349][news349 attributable]) + zurück, indem sie unter ein reines Test-Flag gestellt wird. Dies deaktiviert + die Peer-Bestrafungslogik und entfernt das Feature-TLV aus den + Fehler [onion-messages][topic onion messages]. Knoten, die noch nicht + aktualisiert hatten, wurden fälschlicherweise bestraft, was zeigt, dass eine + breitere Netzwerkakzeptanz erforderlich ist, damit es ordnungsgemäß + funktioniert. + +- [LDK #3623][] erweitert [Peer Storage][topic peer storage] (siehe Newsletter + [#342][news342 peer]), um automatische, verschlüsselte Peer-Backups + bereitzustellen. Für jeden Block verpackt `ChainMonitor` die Daten aus einer + versionierten, mit Zeitstempel versehenen und serialisierten + `ChannelMonitor`-Struktur in ein `OurPeerStorage`-Blob. Dann verschlüsselt + sie die Daten und löst ein `SendPeerStorage`-Ereignis aus, um das Blob als + `peer_storage`-Nachricht an jeden Channel-Peer weiterzuleiten. Zusätzlich + wird `ChannelManager` aktualisiert, um `peer_storage_retrieval`-Anfragen zu + bearbeiten, indem ein neuer Blob-Versand ausgelöst wird. + +- [BTCPay Server #6755][] verbessert die Coin-Control-Benutzeroberfläche mit + neuen Filtern für Mindest- und Höchstbeträge, Filtern für vor und nach dem + Erstellungsdatum, einem Hilfebereich für die Filter, einem „Alle + auswählen“-Kontrollkästchen für UTXOs und Optionen für große Seitengrößen + (100, 200 oder 500 UTXOs). + +- [Rust libsecp256k1 #798][] vervollständigt die [MuSig2][topic + musig]-Implementierung in der Bibliothek und gibt nachgelagerten Projekten + Zugang zu einem robusten [skriptlosen Multisignatur][topic + multisignature]-Protokoll. + +{% include snippets/recap-ad.md when="2025-06-24 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="3110,3101,3817,3623,6755,1270" %} +[Core Lightning 25.05]: https://github.com/ElementsProject/lightning/releases/tag/v25.05 +[bishop priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com/ +[poinsot priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235xaDlhg35nY8Zn7g1siy3IADHvSHyCcgTHrJorMKcDzZg=@protonmail.com/ +[kung priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/58813483-7351-487e-8f7f-82fb18a4c808n@googlegroups.com/ +[linus bitvm3]: https://delvingbitcoin.org/t/garbled-circuits-and-bitvm3/1773 +[rubin garbled]: https://rubin.io/bitcoin/2025/04/04/delbrag/ +[pickhardt rebalance]: https://delvingbitcoin.org/t/research-update-a-geometric-approach-for-optimal-channel-rebalancing/1768 +[rust libsecp256k1 #798]: https://github.com/rust-bitcoin/rust-secp256k1/pull/798 +[news54 foaf rebalance]: /en/newsletters/2019/07/10/#brainstorming-just-in-time-routing-and-free-channel-rebalancing +[yanofsky priv]: https://github.com/bitcoin-core/meta/issues/19#issuecomment-2961177626 +[cove github]: https://github.com/bitcoinppl/cove/releases +[liana github]: https://github.com/wizardsardine/liana/releases +[breez github]: https://github.com/breez/breez-sdk-liquid/releases/tag/0.9.0 +[starkware tweet]: https://x.com/dimahledba/status/1935354385795592491 +[starkware sv2]: https://github.com/keep-starknet-strange/stratum +[news337 delay]: /de/newsletters/2025/01/17/#eclair-2936 +[news349 attributable]: /de/newsletters/2025/04/11/#ldk-2256 +[news342 peer]:/de/newsletters/2025/02/21/#ldk-3575 \ No newline at end of file From 32e1757ec4016dc75c187d66f504a05d1899738b Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Tue, 24 Jun 2025 15:58:58 -0500 Subject: [PATCH 126/278] Podcast: add 359 recap --- .../en/newsletters/2025-06-20-newsletter.md | 28 +++++++++---------- .../en/podcast/2025-06-24-newsletter-recap.md | 24 ++++++++++++++++ 2 files changed, 38 insertions(+), 14 deletions(-) create mode 100644 _posts/en/podcast/2025-06-24-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-06-20-newsletter.md b/_posts/en/newsletters/2025-06-20-newsletter.md index a5737fd84b..9f95946a36 100644 --- a/_posts/en/newsletters/2025-06-20-newsletter.md +++ b/_posts/en/newsletters/2025-06-20-newsletter.md @@ -43,7 +43,7 @@ Bitcoin infrastructure software. active Bitcoin Core contributors to reply to the thread as of the time of writing---[indicated][kung priv] either [that][yanofsky priv] they don't think a major change is necessary or that any changes should be made incrementally - over time. + over time. {% assign timestamp="1:11" %} - **Improvements to BitVM-style contracts:** Robin Linus [posted][linus bitvm3] to Delving Bitcoin to announce a significant reduction in the @@ -59,7 +59,7 @@ Bitcoin infrastructure software. reasonable security parameters requiring a 5 TB offchain setup, 56 kB onchain transaction to assert the result, and minimal onchain transaction (~200 B) in the case that a party needs to prove the - assertion was invalid. + assertion was invalid. {% assign timestamp="21:17" %} - **Channel rebalancing research:** Rene Pickhardt [posted][pickhardt rebalance] to Delving Bitcoin thoughts about rebalancing channels @@ -72,7 +72,7 @@ Bitcoin infrastructure software. Pickhardt notes that there are several challenges to a global approach and asks interested parties to answer a few questions, such as whether this approach is worth pursuing and how to address certain - implementation details. + implementation details. {% assign timestamp="41:57" %} ## Changes to services and client software @@ -81,22 +81,22 @@ wallets and services.* - **Cove v1.0.0 released:** Recent Cove [releases][cove github] include coin control support and - additional [BIP329][] wallet label features. + additional [BIP329][] wallet label features. {% assign timestamp="1:03:58" %} - **Liana v11.0 released:** Recent [releases][liana github] of Liana include features for multiple wallets, additional coin control features, and more hardware signing device - support, among other features. + support, among other features. {% assign timestamp="1:04:59" %} - **Stratum v2 STARK proof demo:** StarkWare [demonstrated][starkware tweet] a [modified Stratum v2 mining client][starkware sv2] using a STARK proof to prove that a block's fees belongs to a valid block template without revealing the transactions in the - block. + block. {% assign timestamp="1:06:48" %} - **Breez SDK adds BOLT12 and BIP353:** Breez SDK Nodeless [0.9.0][breez github] adds support for receiving using - [BOLT12][] and [BIP353]. + [BOLT12][] and [BIP353]. {% assign timestamp="1:08:41" %} ## Releases and release candidates @@ -111,7 +111,7 @@ release candidates._ with Eclair, and enables [peer storage][topic peer storage] by default. Note: its [release documentation][core lightning 25.05] contains a warning for users of the `--experimental-splicing` - configuration option. + configuration option. {% assign timestamp="1:09:51" %} ## Notable code and documentation changes @@ -131,19 +131,19 @@ repo], and [BINANAs][binana repo]._ default to 8 confirmations before sending `splice_locked` and allow node operators to raise that threshold, so 12 blocks proved too short. The delay is now configurable for testing purposes and to allow node operators to wait - longer. + longer. {% assign timestamp="1:11:32" %} - [Eclair #3101][] introduces the `parseoffer` RPC, which decodes [BOLT12 offer][topic offers] fields into a human-readable format, allowing users to view the amount before passing it to the `payoffer` RPC. The latter is - extended to accept an amount specified in a fiat currency. + extended to accept an amount specified in a fiat currency. {% assign timestamp="1:12:41" %} - [LDK #3817][] rolls back support for [attributable failures][topic attributable failures] (see Newsletter [#349][news349 attributable]) by placing it under a test-only flag. This disables the peer penalization logic and removes the feature TLV from failure [onion messages][topic onion messages]. Nodes that hadn’t upgraded yet were wrongly penalized, showing that broader network adoption is necessary for it - to work properly. + to work properly. {% assign timestamp="1:13:35" %} - [LDK #3623][] extends [peer storage][topic peer storage] (see Newsletter [#342][news342 peer]) to provide automatic, encrypted peer backups. Each @@ -152,16 +152,16 @@ repo], and [BINANAs][binana repo]._ data and raises a `SendPeerStorage` event to relay the blob as a `peer_storage` message to every channel peer. Additionally, `ChannelManager` is updated to handle `peer_storage_retrieval` requests by triggering a new - blob send. + blob send. {% assign timestamp="1:14:04" %} - [BTCPay Server #6755][] enhances the coin control user interface with new minimum and maximum amount filters, before and after creation date filters, a help section for the filters, a "select all" UTXO - checkbox, and large page size options (100, 200 or 500 UTXOs). + checkbox, and large page size options (100, 200 or 500 UTXOs). {% assign timestamp="1:15:11" %} - [Rust libsecp256k1 #798][] completes the [MuSig2][topic musig] implementation in the library, giving downstream projects access to a robust [scriptless - multisignature][topic multisignature] protocol. + multisignature][topic multisignature] protocol. {% assign timestamp="1:15:54" %} {% include snippets/recap-ad.md when="2025-06-24 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-06-24-newsletter-recap.md b/_posts/en/podcast/2025-06-24-newsletter-recap.md new file mode 100644 index 0000000000..0d7980d717 --- /dev/null +++ b/_posts/en/podcast/2025-06-24-newsletter-recap.md @@ -0,0 +1,24 @@ +--- +title: 'Bitcoin Optech Newsletter #359 Recap Podcast' +permalink: /en/podcast/2025/06/24/ +reference: /en/newsletters/2025/06/20/ +name: 2025-06-24-recap +slug: 2025-06-24-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt are joined by Bryan Bishop, Robin Linus, +and Rene Pickhardt to discuss [Newsletter #359]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-5-24/402749274-44100-2-f07cb660491b5.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From 20c4ec20dcb2480f5ec72bebc530a3a890296f7a Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Tue, 24 Jun 2025 03:41:11 -1000 Subject: [PATCH 127/278] Newsletters: add 360 (2025-06-27) --- .../en/newsletters/2025-06-27-newsletter.md | 99 +++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 _posts/en/newsletters/2025-06-27-newsletter.md diff --git a/_posts/en/newsletters/2025-06-27-newsletter.md b/_posts/en/newsletters/2025-06-27-newsletter.md new file mode 100644 index 0000000000..94ff136103 --- /dev/null +++ b/_posts/en/newsletters/2025-06-27-newsletter.md @@ -0,0 +1,99 @@ +--- +title: 'Bitcoin Optech Newsletter #360' +permalink: /en/newsletters/2025/06/27/ +name: 2025-06-27-newsletter +slug: 2025-06-27-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter summarizes research about fingerprinting full +nodes using P2P protocol messages and seeks feedback about possibly +removing support for `H` in BIP32 paths in the BIP380 specification of +descriptors. Also included are our regular sections summarizing top +questions and answers on the Bitcoin Stack Exchange, announcing new +releases and release candidates, and describing notable changes to +popular Bitcoin infrastructure software. + +## News + +- **Fingerprinting nodes using `addr` messages:** Daniela Brozzoni + [posted][brozzoni addr] to Delving Bitcoin about research she conducted with + developer Naiyoma into identifying the same node on multiple networks + using the `addr` messages it sends. Nodes send P2P protocol `addr` + (address) messages to their peers to advertise other potential nodes, + allowing peers to find each other using a decentralized gossip system. + However, Brozzoni and Naiyoma were able to fingerprint individual + nodes using details from their specific address messages, allowing + them to identify the same node running on multiple networks (such as + IPv4 and [Tor][topic anonymity networks]). + + The researchers suggest two possible mitigations: removing timestamps + from address messages or, if the timestamps are kept, randomizing them + slightly to make them less specific to particular nodes. + +- **Does any software use `H` in descriptors?** Ava Chow [posted][chow hard] to + the Bitcoin-Dev mailing list to ask whether any software generates + descriptors using uppercase-H to indicate a hardened [BIP32][topic + bip32] key derivation step. If not, the [BIP380][] specification of + [output script descriptors][topic descriptors] may be modified to only + allow lowercase-h and `'` to be used to indicate hardening. Chow + notes that, although BIP32 allows uppercase-H, the BIP380 + specification previously included a test that forbids using uppercase-H + and that Bitcoin Core currently does not accept uppercase-H. + +## Selected Q&A from Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] is one of the first places Optech +contributors look for answers to their questions---or when we have a +few spare moments to help curious or confused users. In +this monthly feature, we highlight some of the top-voted questions and +answers posted since our last update.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +FIXME:bitschmidty + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [Bitcoin Core 28.2][] is a maintenance release for the previous + release series of the predominant full node implementation. It + contains multiple bug fixes. + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [Bitcoin Core #31981][] Add checkBlock() to Mining interface + +- [Eclair #3109][] Prepare attribution data for trampoline payments + +- [LND #9950][] starius/describegraph-authproofs2 + +- [LDK #3868][] joostjager/coarse-hold-times + +- [LDK #3873][] jkczyz/2025-06-splice-locked-fixes + +- [Libsecp256k1 #1678][] cmake: add a helper for linking into static libs + +- [BIPs #1803][], [#1871][bips #1871], [#1867][bips #1867], and + [#1866][bips #1866] quapka/hardened-indicator achow101/desc-clarifications achow101/390-clarifications rkrux/musig-multipath + +{% include snippets/recap-ad.md when="2025-07-01 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31981,3109,9950,3868,3873,1678,1803,1871,1867,1866" %} +[bitcoin core 28.2]: https://bitcoincore.org/bin/bitcoin-core-28.2/ +[brozzoni addr]: https://delvingbitcoin.org/t/fingerprinting-nodes-via-addr-requests/1786/ +[chow hard]: https://mailing-list.bitcoindevs.xyz/bitcoindev/848d3d4b-94a5-4e7c-b178-62cf5015b65f@achow101.com/T/#u From 67deda8414c72f0207345dd54364878267b9bc5f Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Wed, 25 Jun 2025 09:58:10 -0500 Subject: [PATCH 128/278] News360: add stack exchange --- .../en/newsletters/2025-06-27-newsletter.md | 26 +++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/_posts/en/newsletters/2025-06-27-newsletter.md b/_posts/en/newsletters/2025-06-27-newsletter.md index 94ff136103..26b7e49ed1 100644 --- a/_posts/en/newsletters/2025-06-27-newsletter.md +++ b/_posts/en/newsletters/2025-06-27-newsletter.md @@ -53,7 +53,28 @@ answers posted since our last update.* {% comment %}{% endcomment %} {% assign bse = "https://bitcoin.stackexchange.com/a/" %} -FIXME:bitschmidty +- [Is there any way to block Bitcoin Knots nodes as my peers?]({{bse}}127456) + Vojtěch Strnad provides an approach to blocking peers based on user-agent strings + using two Bitcoin Core RPCs but discourages such an approach and points to a + related [Bitcoin Core GitHub issue][Bitcoin Core #30036] with similar discouragement. + +- [What does OP_CAT do with integers?]({{bse}}127436) + Pieter Wuille explains that Bitcoin Script stack elements do not contain data + type information and different opcodes interpret the stack element's bytes in + different ways. + +- [Async Block Relaying With Compact Block Relay (BIP152)]({{bse}}127420) + User bca-0353f40e outlines Bitcoin Core's handling of [compact blocks][topic + compact block relay] and estimates the impact of missing transactions on block + propagation. + +- [Why is attacker revenue in selfish mining disproportional to its hash-power?]({{bse}}53030) + Antoine Poinsot follows up on this and [another]({{bse}}125682) older [selfish + mining][topic selfish mining] question, pointing out, "The difficulty + adjustment does not take stale blocks into account, which means that + decreasing competing miners' effective hashrate increases a miner's profits + (on a long enough time scale) as much as increasing his own" (see [Newsletter + #358][news358 selfish mining]). ## Releases and release candidates @@ -93,7 +114,8 @@ repo], and [BINANAs][binana repo]._ {% include snippets/recap-ad.md when="2025-07-01 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="31981,3109,9950,3868,3873,1678,1803,1871,1867,1866" %} +{% include linkers/issues.md v=2 issues="31981,3109,9950,3868,3873,1678,1803,1871,1867,1866,30036" %} [bitcoin core 28.2]: https://bitcoincore.org/bin/bitcoin-core-28.2/ [brozzoni addr]: https://delvingbitcoin.org/t/fingerprinting-nodes-via-addr-requests/1786/ [chow hard]: https://mailing-list.bitcoindevs.xyz/bitcoindev/848d3d4b-94a5-4e7c-b178-62cf5015b65f@achow101.com/T/#u +[news358 selfish mining]: /en/newsletters/2025/06/13/#calculating-the-selfish-mining-danger-threshold From 7dce4874d377889e2b20f76f739a4ad226040202 Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Fri, 27 Jun 2025 04:52:35 -0500 Subject: [PATCH 129/278] News360: merge summaries --- .../en/newsletters/2025-06-27-newsletter.md | 68 +++++++++++++++---- 1 file changed, 53 insertions(+), 15 deletions(-) diff --git a/_posts/en/newsletters/2025-06-27-newsletter.md b/_posts/en/newsletters/2025-06-27-newsletter.md index 26b7e49ed1..86be009856 100644 --- a/_posts/en/newsletters/2025-06-27-newsletter.md +++ b/_posts/en/newsletters/2025-06-27-newsletter.md @@ -97,25 +97,63 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Bitcoin Core #31981][] Add checkBlock() to Mining interface - -- [Eclair #3109][] Prepare attribution data for trampoline payments - -- [LND #9950][] starius/describegraph-authproofs2 - -- [LDK #3868][] joostjager/coarse-hold-times - -- [LDK #3873][] jkczyz/2025-06-splice-locked-fixes - -- [Libsecp256k1 #1678][] cmake: add a helper for linking into static libs - -- [BIPs #1803][], [#1871][bips #1871], [#1867][bips #1867], and - [#1866][bips #1866] quapka/hardened-indicator achow101/desc-clarifications achow101/390-clarifications rkrux/musig-multipath +- [Bitcoin Core #31981][] adds a `checkBlock` method to the inter-process + communication (IPC) `Mining` interface (see Newsletter [#310][news310 ipc]) + that performs the same validity checks as the `getblocktemplate` RPC in + `proposal` mode. This enables mining pools using [Stratum v2][topic pooled + mining] to validate block templates provided by miners via the faster IPC + interface, rather than serialising up to 4 MB of JSON through RPC. The + proof-of-work and merkle root checks can be disabled in the options. + +- [Eclair #3109][] extends its [attributable failures][topic attributable failures] support (see Newsletter + [#356][news356 failures]) to [trampoline payments][topic trampoline payments]. + A trampoline node now decrypts and stores the part of the attribution payload + intended for it and prepares the remaining blob for the next trampoline hop. + This PR does not implement the relay of the attribution data for trampoline + nodes, which is expected in a follow-up PR. + +- [LND #9950][] adds a new `include_auth_proof` flag to the `DescribeGraph`, + `GetNodeInfo` and `GetChanInfo` RPCs and to their corresponding `lncli` + commands. Including this flag returns the [channel announcement][topic channel + announcements] signatures, allowing validation of channel details + by third-party software. + +- [LDK #3868][] reduces the precision of the [HTLC][topic htlc] hold time for + [attributable failure][topic attributable failures] (see Newsletter [#349][news349 attributable]) payloads + from 1-millisecond to 100-millisecond units, to mitigate timing-fingerprint + leaks. This aligns LDK with the latest updates to the [BOLTs #1044][] draft. + +- [LDK #3873][] raises the delay for forgetting a Short Channel Identifier + (SCID) after its funding output is spent from 12 to 144 blocks to allow for + the propagation of a [splice][topic splicing] update. This is double the + 72-block delay introduced in [BOLTs #1270][] that was implemented by Eclair + (see Newsletter [#359][news359 eclair]). This PR also implements additional + changes to the `splice_locked` message exchange process. + +- [Libsecp256k1 #1678][] adds a `secp256k1_objs` CMake interface library that + exposes all the library’s object files to allow parent projects, such as + Bitcoin Core’s planned [libbitcoinkernel][libbitcoinkernel project], to link + those objects directly into their own static libraries. This solves the + problem of CMake lacking a native mechanism to link static libraries into + another and spares downstream users from providing their own `libsecp256k1` + binary. + +- [BIPs #1803][] clarifies [BIP380][]’s [descriptor][topic descriptors] grammar + by allowing all common hardened-path markers, while [#1871][bips #1871], + [#1867][bips #1867], and [#1866][bips #1866] refine [BIP390][]’s + [MuSig2][topic musig] descriptors by tightening key path rules, permitting + repeated participant keys, and explicitly restricting multipath child + derivations. {% include snippets/recap-ad.md when="2025-07-01 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="31981,3109,9950,3868,3873,1678,1803,1871,1867,1866,30036" %} +{% include linkers/issues.md v=2 issues="31981,3109,9950,3868,3873,1678,1803,1871,1867,1866,30036,1044,1270" %} [bitcoin core 28.2]: https://bitcoincore.org/bin/bitcoin-core-28.2/ [brozzoni addr]: https://delvingbitcoin.org/t/fingerprinting-nodes-via-addr-requests/1786/ [chow hard]: https://mailing-list.bitcoindevs.xyz/bitcoindev/848d3d4b-94a5-4e7c-b178-62cf5015b65f@achow101.com/T/#u [news358 selfish mining]: /en/newsletters/2025/06/13/#calculating-the-selfish-mining-danger-threshold +[news310 ipc]: /en/newsletters/2024/07/05/#bitcoin-core-30200 +[news356 failures]: /en/newsletters/2025/05/30/#eclair-3065 +[news349 attributable]: /en/newsletters/2025/04/11/#ldk-2256 +[news359 eclair]: /en/newsletters/2025/06/20/#eclair-3110 +[libbitcoinkernel project]: https://github.com/bitcoin/bitcoin/issues/27587 From a1c826cbddb115f8b5727687d222289bea85c80c Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Fri, 27 Jun 2025 04:49:44 -0500 Subject: [PATCH 130/278] News360: add topics --- _topics/en/anonymity-networks.md | 3 +++ _topics/en/attributable-failures.md | 6 ++++++ _topics/en/trampoline-payments.md | 3 +++ 3 files changed, 12 insertions(+) diff --git a/_topics/en/anonymity-networks.md b/_topics/en/anonymity-networks.md index fb5ab104bb..539c5ce50a 100644 --- a/_topics/en/anonymity-networks.md +++ b/_topics/en/anonymity-networks.md @@ -115,6 +115,9 @@ optech_mentions: - title: "DNS seeding for nodes on anonymity networks" url: /en/newsletters/2024/09/20/#dns-seeding-for-non-ip-addresses + - title: "Fingerprinting nodes on anonymity networks using P2P addr messages" + url: /en/newsletters/2025/06/27/#fingerprinting-nodes-using-addr-messages + ## Optional. Same format as "primary_sources" above see_also: - title: Dandelion diff --git a/_topics/en/attributable-failures.md b/_topics/en/attributable-failures.md index e35c58e2a1..0c60d34a26 100644 --- a/_topics/en/attributable-failures.md +++ b/_topics/en/attributable-failures.md @@ -41,6 +41,12 @@ optech_mentions: - title: "LDK #3817 puts attributable failures under a test-only flag until broader adoption is achieved" url: /en/newsletters/2025/06/20/#ldk-3817 + - title: "Eclair #3109 extends its attributable failures support to trampoline payments" + url: /en/newsletters/2025/06/27/#eclair-3109 + + - title: "LDK #3868 reduces the precision of HTLC hold time for attributable failures from 1ms to 100ms units" + url: /en/newsletters/2025/06/27/#ldk-3868 + ## Optional. Same format as "primary_sources" above # see_also: # - title: diff --git a/_topics/en/trampoline-payments.md b/_topics/en/trampoline-payments.md index d2ba873f63..2475d7d312 100644 --- a/_topics/en/trampoline-payments.md +++ b/_topics/en/trampoline-payments.md @@ -64,6 +64,9 @@ optech_mentions: - title: "LDK #3670 adds support for handling and receiving trampoline payments" url: /en/newsletters/2025/04/04/#ldk-3670 + - title: "Eclair #3109 extends its attributable failures support to trampoline payments" + url: /en/newsletters/2025/06/27/#eclair-3109 + ## Optional. Same format as "primary_sources" above see_also: - title: "BOLTs PR #654: Trampoline Routing" From e6f457f464233228c89c581a5b45e4678705498f Mon Sep 17 00:00:00 2001 From: shigeyuki azuchi Date: Fri, 27 Jun 2025 22:11:24 +0900 Subject: [PATCH 131/278] Newsletter-360:Translate into Japanese (#2395) --- .../ja/newsletters/2025-06-27-newsletter.md | 136 ++++++++++++++++++ 1 file changed, 136 insertions(+) create mode 100644 _posts/ja/newsletters/2025-06-27-newsletter.md diff --git a/_posts/ja/newsletters/2025-06-27-newsletter.md b/_posts/ja/newsletters/2025-06-27-newsletter.md new file mode 100644 index 0000000000..9e38504830 --- /dev/null +++ b/_posts/ja/newsletters/2025-06-27-newsletter.md @@ -0,0 +1,136 @@ +--- +title: 'Bitcoin Optech Newsletter #360' +permalink: /ja/newsletters/2025/06/27/ +name: 2025-06-27-newsletter-ja +slug: 2025-06-27-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、P2Pプロトコルのメッセージを使ったフルノードのフィンガープリンティングに関する研究と、 +BIP380のディスクリプター仕様におけるBIP32パスで`H`のサポートを削除する可能性についてのフィードバックについて掲載しています。 +また、Bitcoin Stack Exchangeで人気の質問とその回答のまとめや、 +新しいリリースとリリース候補の発表、人気のBitcoinインフラストラクチャソフトウェアの注目すべき更新など +恒例のセクションも掲載しています。 + +## ニュース + +- **`addr`メッセージを使用したノードのフィンガープリンティング:** Daniela Brozzoniは、 + 開発者のNaiyomaと共に行った研究についてDelving Bitcoinに[投稿しました][brozzoni addr]。 + この研究では、ノードが送信する`addr`（アドレス）メッセージを使用して、 + 複数のネットワーク上で同じノードを識別することができました。 + ノードは、P2Pプロトコルの`addr`（アドレス）メッセージをピアに送信することで、 + 他の潜在的なノードをアナウンスし、ピアが分散型のゴシップシステムを使用してお互いを見つけられるようにしています。 + しかし、BrozzoniとNaiyomaは、個々のノード固有のアドレスメッセージの詳細を使ってフィンガープリンティングを行い、 + 複数のネットワーク（IPv4と[Tor][topic anonymity networks]など）上で動作する同一ノードを識別することに成功しました。 + + 研究者らは、２つの可能な緩和策を提案しています: アドレスメッセージからタイムスタンプを削除するか、 + タイムスタンプを残す場合は、特定のノードに固有にならないようにタイムスタンプをわずかにランダム化することです。 + +- **ディスクリプターで`H`を使用しているソフトウェアはありますか？** Ava Chow は、 + 強化導出の[BIP32][topic bip32]鍵導出ステップを示すために大文字のHを使ってディスクリプターを生成するソフトウェアがあるかどうかを + Bitcoin-Devメーリングリストで[尋ねました][chow hard]。もしない場合は、 + [アウトプットスクリプトディスクリプター][topic descriptors]の[BIP380][]仕様は、 + 強化導出を示すために小文字のhと`'`のみを使用するように変更される可能性があります。 + Chowは、BIP32では大文字のHが許可されているものの、BIP380には以前、 + 大文字のHの使用を禁止するテストが含まれており、Bitcoin Coreは現在大文字のHを受け入れていないことを指摘しています。 + +## Bitcoin Stack Exchangeから選ばれたQ&A + +*[Bitcoin Stack Exchange][bitcoin.se]はOptech Contributor達が疑問に対して答えを探しに（もしくは他のユーザーの質問に答える時間がある場合に）アクセスする、 +数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Bitcoin Knotsノードをピアとしてブロックする方法はありますか？]({{bse}}127456) + Vojtěch Strnadは、Bitcoin Coreの2つのRPCを使って + ユーザーエージェントの文字列に基づいてピアをブロックする方法を提供していますが、 + この方法は推奨されておらず、同様の非推奨事項を指摘する関連する[Bitcoin CoreのGitHubの課題][Bitcoin Core #30036]も示されています。 + +- [OP_CATは整数をどのように処理しますか？]({{bse}}127436) + Pieter Wuilleは、Bitcoin Scriptのスタック要素にはデータの型情報が含まれておらず、 + opcodeによってスタック要素のbyteの解釈方法が異なると指摘しています。 + +- [コンパクトブロックリレーによる非同期ブロックリレー（BIP152）について]({{bse}}127420) + ユーザーbca-0353f40eは、Bitcoin Coreの[コンパクトブロック][topic compact block relay]の処理を概説し、 + 欠落したトランザクションがブロックの伝播に与える影響を推定しています。 + +- [セルフィッシュマイニングにおける攻撃者の収益がハッシュパワーに不相応なのはなぜですか？]({{bse}}53030) + Antoine Poinsotは、これと[別の]({{bse}}125682) 古い[セルフィッシュマイニング][topic selfish mining]の質問をフォローアップし、 + 「難易度調整はステイルブロックを考慮しないため、競合するマイナーの実効ハッシュレートを下げると、 + （十分に長い時間スケールで）自身のハッシュレートを増加させるのと同じくらいマイナーの利益を増加させる」 + と指摘しています（[ニュースレター #358][news358 selfish mining]参照）。 + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [Bitcoin Core 28.2][]は、主要なフルノード実装の以前のリリースシリーズのメンテナンスリリースです。 + これには複数のバグ修正が含まれています。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Bitcoin Core #31981][]は、プロセス間通信（IPC）`Mining`インターフェース（ニュースレター [#310][news310 ipc]参照）に + `checkBlock`メソッドを追加します。このメソッドは、`proposal`モードの`getblocktemplate` + RPCと同じ有効性チェックを実行します。これにより、[Stratum v2][topic pooled mining]を使用するマイニングプールは、 + 最大4MBのJSONをRPC経由でシリアライズするのではなく、 + より高速なIPCインターフェースを介してマイナーから提供されたブロックテンプレートを検証できるようになります。 + Proof-of-Workとマークルルートのチェックはオプションで無効化できます。 + +- [Eclair #3109][]は、[失敗の帰属][topic attributable failures]のサポート（ + ニュースレター[#356][news356 failures]参照）を[トランポリンペイメント][topic trampoline payments]に拡張しました。 + トランポリンノードは、自身に割り当てられた帰属のペイロードの一部を復号して保存し、 + 残りのBLOBを次のトランポリンホップ用に準備するようになりました。このPRは、 + トランポリンノードの帰属データのリレーを実装していません。これは後続のPRで予定されています。 + +- [LND #9950][]は、`DescribeGraph`および`GetNodeInfo`、`GetChanInfo` RPCと + それらに対応する`lncli`コマンドに新しい`include_auth_proof`フラグを追加します。 + このフラグを含めると、[チャネルアナウンス][topic channel announcements]の署名が返され、 + サードパーティソフトウェアによるチャネルの詳細な検証が可能になります。 + +- [LDK #3868][]は、タイミングフィンガープリンティングを軽減するため、 + [失敗の帰属][topic attributable failures]（ニュースレター[#349][news349 attributable]参照）のペイロードの + [HTLC][topic htlc]のホールド時間の精度を1ミリ秒単位から100ミリ秒単位に削減します。 + これにより、LDKは[BOLTs #1044][]ドラフトの最新のアップデートに準拠します。 + +- [LDK #3873][]は、[スプライシング][topic splicing]の更新を伝播できるようにするため、 + ファンディングアウトプットが使用された後にSCID（Short Channel Identifier）を忘れるまでの遅延を + 12ブロックから144ブロックに引き上げます。これは、Eclairが実装した[BOLTs #1270][]で導入された + 72ブロックの遅延（ニュースレター[#359][news359 eclair]参照）の2倍です。 + このPRでは、`splice_locked`メッセージ交換プロセスにも追加の変更が実装されています。 + +- [Libsecp256k1 #1678][]は、ライブラリのすべてのオブジェクトファイルを公開する + `secp256k1_objs` CMakeインターフェースライブラリを追加し、 + Bitcoin Coreで計画されている[libbitcoinkernel][libbitcoinkernel project]などの親プロジェクトから + これらのオブジェクトを自分の静的ライブラリに直接リンクできるようにします。 + これは、CMakeが静的ライブラリを別のライブラリにリンクするネイティブなメカニズムを欠いている問題を解決し、 + 下流ストリームのユーザーが独自の`libsecp256k1`バイナリを提供する必要をなくします。 + +- [BIPs #1803][]は、すべての一般的な強化導出パスマーカーを許可することで、 + [BIP380][]の[ディスクリプター][topic descriptors]の文法を明確にし、 + [#1871][bips #1871]、[#1867][bips #1867]および[#1866][bips #1866]は、 + key-pathルールを厳格化し、参加者の鍵の繰り返しを許可し、マルチパス子導出を明示的に制限することで、 + [BIP390][]の[MuSig2][topic musig]ディスクリプターを改良します。 + +{% include snippets/recap-ad.md when="2025-07-01 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31981,3109,9950,3868,3873,1678,1803,1871,1867,1866,30036,1044,1270" %} +[bitcoin core 28.2]: https://bitcoincore.org/bin/bitcoin-core-28.2/ +[brozzoni addr]: https://delvingbitcoin.org/t/fingerprinting-nodes-via-addr-requests/1786/ +[chow hard]: https://mailing-list.bitcoindevs.xyz/bitcoindev/848d3d4b-94a5-4e7c-b178-62cf5015b65f@achow101.com/T/#u +[news358 selfish mining]: /ja/newsletters/2025/06/13/#calculating-the-selfish-mining-danger-threshold +[news310 ipc]: /ja/newsletters/2024/07/05/#bitcoin-core-30200 +[news356 failures]: /ja/newsletters/2025/05/30/#eclair-3065 +[news349 attributable]: /ja/newsletters/2025/04/11/#ldk-2256 +[news359 eclair]: /ja/newsletters/2025/06/20/#eclair-3110 +[libbitcoinkernel project]: https://github.com/bitcoin/bitcoin/issues/27587 From d342bb0a7f2434ef7b8bca58b53ee0b253e98ce2 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Fri, 27 Jun 2025 09:23:20 -0500 Subject: [PATCH 132/278] Podcast: add 357 transcription --- .../en/podcast/2025-06-10-newsletter-recap.md | 1287 ++++++++++++++++- 1 file changed, 1286 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-06-10-newsletter-recap.md b/_posts/en/podcast/2025-06-10-newsletter-recap.md index 2d72db540e..4724f6005e 100644 --- a/_posts/en/podcast/2025-06-10-newsletter-recap.md +++ b/_posts/en/podcast/2025-06-10-newsletter-recap.md @@ -19,6 +19,1291 @@ Vojtěch Strnad, Robin Linus, and Dan Gould to discuss [Newsletter #357]({{page. ## Transcription -_transcription coming soon_ +**Mike Schmidt**: Welcome everyone to Bitcoin Optech Newsletter #357 Recap. +Today, we're going to be talking about sinking full nodes without witnesses; we +have our monthly segment on Changing consensus that has three items this month. +One is covering a quantum computing report, we're also going to discuss an idea +for a consensus change to limit the maximum weight of transactions in a block, +and we're also going to talk about age-based expiration for dust outputs in the +UTXO set, along with our normal Releases and Notable code segments. I'm Mike +Schmidt, contributor at Optech and Executive Director at Brink. Murch? + +**Mark Erhardt**: Hi, I'm Murch, I work at localhost research on Bitcoin. + +**Mike Schmidt**: Jose? + +**Jose SK**: Hi, I'm Jose, I'm working currently on the Floresta lightweight +utreexo node. + +**Mike Schmidt**: Clara. + +**Clara Shikhelman**: Hi, I'm Clara and I'm a researcher at Chaincode Labs. + +**Mike Schmidt**: Vojtěch? + +**Vojtěch Strnad**: Hi, I'm Vojtěch, I'm a Bitcoin enthusiast and a free-time +educator. + +**Mike Schmidt**: Robin. + +**Robin Linus**: Hi, I'm Robin, and I work on BitVM and I'm doing a PhD on +Bitcoin at Stanford. + +**Mike Schmidt**: Amazing, thank you all for joining us. Murch was saying +before the show, he's excited about this one. We've got a lot of interesting +topics and I think we're specifically excited because you all are here to help +represent the work that you're doing. So, we'll jump into our News section. + +_Syncing full nodes without witnesses_ + +We have one item this week, "Syncing full nodes without witnesses". Jose, you +posted to Delving Bitcoin a post titled, "Witnessless Sync for Pruned Nodes". +In that post, you summarize some analysis of skipping assumevalid witness +downloads for pruned nodes, and you also conclude that there could be a +reduction in bandwidth usage by more than 40% during IBD (Initial Block +Download) that could be possible. Maybe, Jose, you can briefly explain some of +the background concepts, like assumevalid and pruned nodes, and then we can get +into how they can come together to realize the benefits that you outlined? + +**Jose SK**: Yeah, so the first time, I think the first time that this was +discussed, it was in 2016 in a bitcoincore.org post, where they were listing the +benefits of segwit. And then we saw one of those potential benefits, which was +simply that we could skip downloading the witnesses for some kind of lightweight +nodes or nodes that are skipping stream or signature validation, right? But at +the time, there wasn't such a thing as assumevalid. There were checkpoints. +So, we were skipping, as far as I know, we were skipping the signature +validation until the checkpoint. But then, that was kind of limited and I think +it has been removed recently, the checkpoint thing. But anyway, assumevalid was +actually introduced in 2017, in the same year as segwit. After that, nobody +thought, no, I don't know if thought, but I haven't seen anywhere after segwit +was activated. The idea was you need to simply skip downloading these witnesses +that we are already knowing they are valid, right, because of assumevalid. + +So, the background of this whole thing was two years ago, in Bitcoin Stack +Exchange, I simply asked a question, I thought it was a dumb question, which is +basically, "Why are we downloading the witnesses for these assumevalid blocks +for pruned nodes?" because these pruned nodes will download this data and not +check it, because they use assumevalid, which is on by default. They will +simply not verify these witnesses and then remove them, drop them. So, I simply +asked that. Pieter Wuille answered, actually that would be possible. But the +problem is that actually, we are doing some checks with those witnesses +currently. It is not like we can simply skip them currently, because we need +them for the resource limit checks, the sigops, size, and even the block weight, +because block weight depends on the witnesses, so we need them for that. Also, +for the witness commitment, we need to check the commitment in the coinbase +transaction. Another check, which is that the node legacy input can have +witnesses. I think those are all the things that we are doing with the +witnesses currently that are not covered by assumevalid. But he said that we +could actually cover those things in assumevalid. It is not like it's a really +big chain for assumevalid. It does seem trivial things to cover with +assumevalid. And if we did that, we could have a really big cut in bandwidth, +because witnesses currently are taking a big part of the block. + +After that post, from Bitcoin Stack Exchange, there was a PR in Bitcoin and +there was a discussion. Many people agreed with the idea, but there were some +concerns about the data availability stuff. But, the number is actually from +comment, Pieter Wuille said that in the last 100,000 blocks, 43% of the data was +witnesses, and that was two years ago. So, I don't know actually what would be +the number currently, but probably like 40%, or something like that, or more. +Murch is in. + +**Mark Erhardt**: Well, given all the inscription data, I think the witnesses +are a lot more of the block right now. Well, at least in the last few years. + +**Jose SK**: Yeah, probably more. That's why I say probably more than 40%. + +**Robin Linus**: Shouldn't it be, like, 75%, since 1 MB is transaction data and +3 MB is witness data? + +**Jose SK**: In the extreme case, you mean, right? + +**Mark Erhardt**: In the extreme case, 4 MB of witness data would fill a 1 MB +block. But really, we only have something like 1.3 MB to 1.6 MB in most blocks. +So, witness data is much less than almost all of the block. + +**Jose SK**: For that famous block, that was a full inscription, 4 MB, that +would be for this kind of witnessless thing, no, that would be empty, basically. +So, yeah, that was the background, basically. Because of the data availability +concern, that PR didn't progress anymore. Currently, it is up for grabs. So, +yeah, that's two years ago, right? So, I think it was two weeks ago, I don't +know why, I thought about this again. And I said, okay, let's try to think +about this again, like is this really a problem to not allow these witnesses? +And I tried to write some kind of reasoning. I was just reasoning about that. +And what I found is what I have written in that post and also published it in +Delving Bitcoin. + +**Mark Erhardt**: Yeah, let me try to summarize a little bit again. Assumevalid +skips the script verification, but it still does all the checks where it hashes +the transaction data and thus ensures that the txid is what was committed to in +blocks. And it also, I think in the original, hashes the witnesses and checks +that the witness commitments in the coinbase transaction works. Obviously, we +don't check the scripts in the witness section for validity, because we're +skipping the script checks in assumevalid. So, what happens specifically on +pruned nodes is, we download all the witness data and then we just hash it and +check that it is there, and throw it away as soon as the block is more than two +days in the past, and we prune it away. So, basically, 40% of the bandwidth is +just spent on checking that witness txid matches the commitment in the block. +But if you are assuming that the script was valid because it's buried so deep in +the blockchain, you may as well trust that the coinbase was validly committing +to a witness that was present when the transaction came. So, the security +assumption change is fairly small, except that you do not actively check that +the witness data is still available on the network. Is that roughly a good +summary? + +**Jose SK**: Yes. Not only the hashing thing, but we also need to check the +resource limit stuff. But yeah. + +**Mark Erhardt**: So, you implemented this and I think you wrote that it was +easier than you expected? + +**Jose SK**: No, there's already a Bitcoin Core PR. + +**Mark Erhardt**: Oh, you didn't implement it, you just reviewed it? + +**Jose SK**: I just gave a bit of feedback. I have nothing to do with that PR, +I mean in terms of code. + +**Mark Erhardt**: Oh, okay, I misunderstood that then. Okay, so you're +basically just bringing up the discussion again, and you had this discussion +with Ruben, and he argued that the security assumptions are changed slightly, +because we now no longer check the availability of the data, but just trust that +it was available, similar to how we trust that the scripts were valid. What +else did you find out? Do you think we should still move forward with this? + +**Jose SK**: What I found is that, so the concern is that we are not checking +the availability. But what I actually found is that if the witnesses were +missing in the block, and Bitcoin Core auditors and reviewers and developers saw +that block without the witnesses, if they thought the scripts were valid, they +would be lying, right, because if an input doesn't have the witness, the script +evaluation fails. So, in some way we are saying here that actually +availability, at least in some point in the past, it was needed for the scripts +to be valid, because the missing witness means it is an invalid script +evaluation. So, that's what I'm saying. I'm saying that assumevalid is +covering the one-time availability check. We know that if we are trusting +assumevalid, we know that these witnesses were available, because assumevalid is +already stating they are valid and so they were available. It is a +precondition. It cannot be valid without them being there. + +**Mark Erhardt**: Right, I agree. To steelman Ruben's argument, as I understand +it, I think he also argues that we do not check whether the witnesses are still +available on the network now, as in, do people have copies of the whole +blockchain? But maybe that is an assumption we can make with several 10,000 +full nodes on the network! + +**Jose SK**: Yeah, but the behavior is the same for any regular pruned node, +because imagine you have your pruned node, imagine it is assumevalid zero, like +you are validating everything, downloading everything, you are checking +availability once, which is during IBD. You download the whole blockchain and +then you discard everything, and then you don't need to, each year, redownload +the whole blockchain to check if that data is still available in the network. +Pruned nodes, as far as I know, they don't require checking availability. You +check it once, that's why I say the one-time availability check at IBD, and then +you can run that node for five years, seven, whatever. It seems enough to check +it once. That's the current assumption, as far as I know, for any pruned node. +So, what I'm saying with the assumevalid thing, it is the same thing, the same +trust assumption. We know this data was available at some point in the past, so +maybe five years or whatever, but it is the same thing for any regular pruned +node. + +**Mark Erhardt**: Okay, all right. Do you have a call to action or something +else to summarize? Otherwise, I think we can move on from this topic. + +**Jose SK**: Call to action, I hadn't thought of that. + +**Mark Erhardt**: So, for example, a call to action could be, you still think +this could be attractive for node operators that want to bootstrap a pruned node +in an environment where bandwidth is very expensive, for example, so that would +be a good reason to push for this. And if your argument, that it has very small +changes to the security assumptions, is convincing to other people, that might +be a good option to have maybe not a default option, but an option to have a +lower-bandwidth bootstrapping mechanism, and someone should pick it up again. + +**Jose SK**: Yeah, like the post is trying to reason about that, but I agree +completely that a more conservative solution would be to simply, if you want to +speed up IBD time, the most conservative solution would be to redownload the +witness data, but after your sync, right? So, at least IBD time is smaller, but +then you check, or I would argue you recheck the witness availability later once +you are synced. + +**Mark Erhardt**: That is starting to sound a lot like assumeUTXO. + +**Jose SK**: Yeah, the same, yeah. + +**Robin Linus**: Do we actually know how much of the time in IBD is spent +downloading and checking the witness data? Because as far as I know, the +biggest component of an assumevalid node is looking up UTXOs in the UTXO +database. So, I'm not sure if the speed-up in IBD would be worth it for such a +pretty major change from my point of view? + +**Jose SK**: Yeah, that's a very good point. + +**Robin Linus**: And also, if bandwidth is really expensive for you, then the +bandwidth minus 40% is still going to be pretty expensive. + +**Jose SK**: Yes. + +**Robin Linus**: So, in that case, assumeUTXO is probably much better for you. + +**Jose SK**: Yeah, in most cases, yeah. If your bottleneck is the database +stuff, the input-output operations, yeah, definitely, it will not be a +significant change. But maybe for, yeah, if you have some sort of accumulator, +like utreexo, then in that case, likely this will be an improvement, yeah, a big +improvement. + +**Mark Erhardt**: All right. I think we'll wrap this topic now and move on to +the next one. Thank you for your research, Jose. + +**Mike Schmidt**: Yeah, thanks, Jose, for joining us. You're free to drop if +you have other things to do. Thanks for joining us, though. + +_Quantum computing report_ + +We're going to move to our Changing Consensus monthly segment, and that means +we're going to talk about quantum this week. There is a quantum computing +report that was published recently. Clara, you posted to Delving a summary of +that report, that you and Anthony Milton authored, and it's titled, "Bitcoin and +Quantum Computing: Current Status and Future Directions". Quantum and Bitcoin +has been a hot topic recently, but what does your research actually show? + +**Clara Shikhelman**: So, this report is more a systemization of knowledge. We +just wanted to gather, in one, place pretty much what we know and where do we +stand, what people are looking at right now. So, what we know is that if +quantum computing will happen, and especially cryptographically-relevant quantum +computers will appear, this is going to be a problem for Bitcoin, because all of +our signing schemes right now would be broken. So, the level, not all UTXOs are +as scalable as each other, there are some differences there. We give some +explanation about this in the report. We also talk a bit about mining, which we +should probably be less worried about, just because of the difficulty of quantum +mining competing with ASICs, and so on. But I still think it's very interesting +and a potentially fruitful research topic, but it's definitely not at the same +urgency as anything that has to do with signatures. + +We talk about what, in general, other entities believe the timeline will be. +This predicting the future is a very, very difficult kind of hobby, but all we +can do is say what people that research this are thinking. We also discussed +what signatures and what potential changes are available right now. But as this +is a very hot research topic outside of Bitcoin in general, in academia and so +on, we're getting better and better signatures, better and better schemes. So, +there's a bit of a game here. The longer we wait, the better infrastructure we +can build, the more trust we have in these new schemes. On the other hand, if +we believe that quantum computers are coming at some point, we need to act. And +then, we talk about the acting and the 'at some point'. + +So, we suggest two possible timelines. One is the slower, more comprehensive, +where we take about seven years to research everything very carefully, do the +implementation, slowly move to quantum-secure signatures, and so on. And given +the assumptions right now by NIST and other entities, this is well within the +framework of when they expect any relevant quantum computers to appear. But +sometimes there's like this jump forward, this burst. So, the second timeline, +which we think will take approximately two years, including the migration of +UTXOs, this can happen much, much quicker and it's a dual track. So, we can +jump from one to the other, depending on our assumption, how things develop. +So, these are the main things we talk about in the report. + +**Mark Erhardt**: How would the two approaches significantly differ? + +**Clara Shikhelman**: The two approaches, so for example, if for some reason +tomorrow there's a big jump on the engineering level that allows quantum +computers, we have to say, okay, we just need to choose the best available +signature that we have right now. Maybe it will not offer multisignature, maybe +it will be much larger. Right now, it will have to be much larger. The +verification will be slower, but we just choose something, we implement this. +All of the UTXOs that are immediately vulnerable, so UTXOs that have their +public key on the blockchain, not hashed. So, all of this needs to immediately +move, and then we need to have other migration decisions made. So, this goes +for both timelines, but this means we need to decide right now what do we do +with immigration. And the big question, which is the philosophical question +that we talk about a bit is, what do we do with UTXOs that don't move, can't +move because the keys are lost, or for any other reason; what do we do in this +kind of situation? Again, this is a decision that will need to be made hastily +in this more quick timeline, which to be honest, I don't think, if I had to bet, +I would not put a lot of money on this. But I also don't bet that my plane will +crash, but I learn my emergency exits, so it's good to have it there. + +**Mark Erhardt**: Right. So, the two-year approach would focus on moving the +vulnerable coins first, would just have to be a fairly simple proposal that can +be implemented very quickly. What would the comprehensive approach look like? +Presumably, since it's such a hot topic, the signature schemes are currently +evolving very quickly still. I think since we saw the first draft of BIP360, +we've seen a lot of discussion about different signature schemes, eventually +even the recommendation by NIST now for the first post-quantum algorithms. So, +do you think that in a few years, we might actually get post-quantum schemes +that are not prohibitively huge? + +**Clara Shikhelman**: It's possible. It's difficult to tell, so there's no +reason for it not to happen. There's no mathematical limit that alludes to the +fact that quantum signatures need to be huge. So, I do expect things to get +better and better, but again, this is very, very difficult to guess or +guesstimate how quickly the schemes will get smaller or more efficient. +Sometimes, the verification time is a problem. But I think in the more +comprehensive track, we'll take longer to study more deeply the suggestions. +Bitcoin does not usually follow NIST schemes, like libsecp is not NIST. There +are other things being worked on inside academia, and so on. So, there's going +to be a pretty long phase where we all sit down, carefully read the papers, +understand. For example, we want multisigs, we want all of the cool +functionality that taproot offers. And then, if we want to step away from that, +then we want to offer similar functionality, and so on. + +**Mark Erhardt**: Sorry, I have a follow-up question. You said that about 4 +million bitcoin you estimate are immediately vulnerable by their public keys +being known. Oh, sorry. + +**Clara Shikhelman**: And we're doing some follow-up work on this number, which +might be larger. + +**Mark Erhardt**: Right. So, this is, of course, reused addresses that are +based on hashing, which then have published a public key in inputs and other +schemes that are already with a public key present on the output side, which is +P2PKH or P2TR, for example. Have you also looked at the number of UTXOs that +hold these coins compared to just the amount of bitcoin? How much of the block +space would that take? + +**Clara Shikhelman**: So, we have, and actually my co-author, Anthony Milton, is +now also checking other exposures of public key. For example, when forks +happened and people suddenly owned bitcoin and also UTXOs all in Bitcoin Cash, +and so on, for some reason some of them decided to get rid of these altcoins, +but by doing so, exposed the public key and it's available there. So, we're +still working out a more comprehensive number. But back to your question, it +really depends on how much block space will we give to that. But this is +something, at the best case, we're talking about months, at the worst case it +can go on for years. + +**Mark Erhardt**: Right. For example, one could implement new protocol rules +that prefer spending of these old coin types and forbid sending money to them in +the future, in order to make sure that things only move out of the vulnerable +state, but not into it anymore. But if it were really dire and needed to happen +very quickly and the quantum schemes are huge because, say, the output scripts +required several kB of output script to create the post-quantum locks, then of +course maybe this would have to be paired with a block-size increase or +extension block sort of scheme, or something where we can store all that. + +**Clara Shikhelman**: Yeah, some kind of discount or something like that would +be probably considered. But again, this will need to be a hasty decision only +in the very unlikely case that tomorrow morning … And this is very important to +say, we don't have quantum supremacy for anything relevant at all. So, I know +you're welcome to come back to New York and make me eat my invisible hat, but I +would be very surprised if we'll need to use the quick scheme. But again, it's +good to have it there. + +**Mark Erhardt**: Right. Okay, last question from me for the moment. We've +seen a number of different proposals being put out there on the mailing list, +and also some BIP drafts coming up, I know of at least three BIP drafts in the +BIPs repository. Have you also looked at what the current state of art of +proposals for Bitcoin are? + +**Clara Shikhelman**: So, in general, we gave a quick overview, but the bottom +line is that everything is very, very early stage. There's a lot more work to +be done, a lot of research to be done. There is some research that is +happening. Research in general is a very quiet process. So, there are a few +people sitting at home reading papers and staring at whiteboards. And sometimes +they join the discussion, but sometimes they're just doing the responsible thing +of taking the time and studying the subject deeply before moving forward. So, I +think at this point we can say that everything is very, very early stage. + +**Mark Erhardt**: Cool. Would anyone else like to chime in on this topic? + +**Mike Schmidt**: I have a quick question. Clara, part of this is around when +it comes, when it's here. How do we know when it's here? How do we identify +that it's happening or could be happening? It's not going to be a binary thing, +right? So, what does your mind say about that? + +**Clara Shikhelman**: So, I think maybe the correct question is, how do we know +that it's coming soon? Because if it's already here, in many senses, it's too +late. But I think that a good sign would be quantum computers showing some +supremacy compared to whatever classical computer we have right now, on a +problem that is not designed specifically to be better for quantum computers and +irrelevant for anything else. So, I think this would be the first sign. We'll +say, "Okay, so this is really happening, this is not just PR conversations, this +is not just funding being moved from place to place. We have an actual +scientific proof that we have a quantum computer that is better than a classical +one". + +**Mike Schmidt**: I see. So, it would be sort of a proxy. So, there's this +other puzzle or thing that quantum computers are solving, it's not, "Oh, +Satoshi's coins moved", it's something outside of Bitcoin that we could say, +"Okay, if they're there, then they're getting close to being here"? + +**Clara Shikhelman**: Yeah, then maybe we need to move quicker. There's a bunch +of quantum canaries of different qualities floating around there. But I would +start worrying much more, losing some sleep at the moment, that we'll have a +computer showing quantum supremacy. That being said, this doesn't mean that we +should just sit at home, sip our beers and not do anything. I think we should +continue doing what we're doing now, which is very carefully studying the +problem and preparing for that day. And sudden movements have a cost, because +new cryptographic schemes, we don't have the trust in them, we don't know that +they can't be broken. So, it's very healthy to give it a while, to allow some +PhD student to break the scheme, get their tenured position, and then we'll use +a different one. + +**Mark Erhardt**: I think Robin was trying to chime in. Robin? + +**Robin Linus**: Yeah, I've actually got lots of questions. The first question +I had was, I think all these schemes are based on lattice problems. + +**Clara Shikhelman**: Not all of them, but the most prominent ones are. + +**Robin Linus**: I think all the ones that are not one-time signatures, is that +true? + +**Clara Shikhelman**: That's an excellent question. I'm literally looking. So, +there are some hash-based. + +**Robin Linus**: Yeah, like Winternitz and Lamport. + +**Clara Shikhelman**: Yeah. So, some of them are one time. I'm not sure that +all of them, but yeah. There's also isogeny, yeah. + +**Robin Linus**: I was wondering, there was that paper, I think it was called, +"Quantum algorithms for lattice problems". There was a guy who said he found a +quantum algorithm to break the hardness of lattice algorithms with quantum +computers. I think the paper was retracted because they found a bug in the +paper, but I think I've heard quite a few cryptographers saying that it might be +possible to fix that bug, and then lattice-based crypto would not be considered +post-quantum anymore. So, is that a concern? Or do we have a fallback? + +**Clara Shikhelman**: So, I think it's a great point to what was said earlier. +That's why waiting is very healthy. That's why we don't want to go for +something right now and then it will be broken. There are some other options, +as I said, like things based on hashes, isogeny, and so on, but it's a very +active research topic. So, I couldn't say right now. If you said, "Okay, right +now, choose a scheme. We have to go with something. Decide", I would first of +all point to, I am not a quantum cryptographer, so I would talk to somebody who +has the right education. But also, I think there are options that are +considered feasible, but not perfect, not exciting, and we're waiting both for +better things to come up, and also to make sure that the other things are not +broken. I think I know what paper you're referring to. Let's see if they can +fix it and then all of the lattice things go out of the window. But to the best +of my knowledge, this is not the case right now. + +**Robin Linus**: But I think the paper still, how do you say, disrupted the +confidence in lattice-based crypto a lot. + +**Clara Shikhelman**: Yeah. So, honestly, we'll just have to wait and see and +give some time. Because in general, in cryptography, we sort of trust that +something can't be broken because nobody broke it. You never know. + +**Mark Erhardt**: One counter-question, what recent breakthroughs or milestones +have been reached by quantum that would sort of illustrate that it is making +progress? I remember a couple of years ago that there was a news headline that +quantum had factored 21, and that doesn't seem super scary if we're looking at +these sort of numbers that would need to be factored to break DLCs. + +**Robin Linus**: I think it also exploited some special structure in 21. + +**Clara Shikhelman**: So, I think the past year or so, there were things from +Microsoft with their Majorana-based quantum computers, and so on, that point to +different structures, different ways to build quantum computers. I think, yeah, +there were a bunch of announcements from Google also, there's Willow, but there +was nothing there that you can say, "Okay, this is the real thing". That's +where we are right now. + +**Mark Erhardt**: All right, so I can still continue sipping my beer and say +that quantum seems more like the cold fusion of computer science to me. + +**Clara Shikhelman**: I think that's an exaggeration. I wouldn't go to the +level of, "It's cold fusion, it's not happening and it's never going to happen", +because a lot of really smart people are getting a lot of money to do this, and +maybe they can. And there are some very prominent people, like Scott Aaronson, +who was really on the front of, "It's all FUD and it's not happening anytime +soon". And then recently he said, "Okay, this is a time to change the message +and we need to have a plan". So, enjoy your beer, but keep posted, be part of +the discussions, because maybe it won't, but maybe it will. + +**Mark Erhardt**: Okay. Robin, did you have maybe one more question or so? +Make it count. + +**Robin Linus**: One more question. I could ask the heretic question, but I +think the more interesting question is about stock aggregation. That's maybe +not another interesting topic, that we can just aggregate all these signatures +that are too large into one STARK and maybe save the block size this way? + +**Clara Shikhelman**: Yes, maybe. So, in general, like STARKs offer a lot of +functionality and it can help with this, but then it can allow for other things +to happen on the blockchain. And people have different thoughts about Bitcoin +in general, and should it happen, should it not? So, there's the question of, +do we want to allow a broader functionality that helps with quantum, but also +with potentially meme coins? + +**Robin Linus**: I think they are two different questions, no? On the one hand, +the question if we would want a STARK verify, like essentially OP_STARKVERIFY in +Bitcoin Script that would allow us to do a general verification of programs; or +if we just use it for witness compression? + +**Clara Shikhelman**: Okay, yes, sorry, I thought your question is, do we want +to allow OP_STARK, OP_CAT, and so on? + +**Robin Linus**: For witness compression, because these signatures are so huge +and we could get around that if we would just compress them into one single one +per block. + +**Clara Shikhelman**: I know there is some works and some thoughts on that, but +then you do want to do this carefully, because I'm not sure there's a way to do +this only for quantum signatures and not for other things. So, again, we need +to tread carefully and decide what is it exactly that we want to put on the +blockchain. + +**Mark Erhardt**: All right. Thank you very much for this great overview. +Clara, do you have any more summary or call to action that you want to add to +the segment? + +**Clara Shikhelman**: So, I think the call to action is, I can't shout it any +louder, do not reuse addresses. And if quantum computing is the thing that will +make you stop reusing addresses, so be it, stop reusing addresses. Beyond that, +I think there's work and discussion to be made. So, if you're a cryptographer, +especially quantum cryptography, come on board, there's a lot to be done. And +there is, of course, the philosophical dilemma of, what are we going to do in +the case of quantum computers with UTXOs that did not migrate? And I think this +is a very interesting discussion that we need to understand deeper. And then, +it would be good to get all of this discussion out of the way, just in case +we'll need to act quickly. So, there's a bunch of research topics and +discussion topics out there. But if you'll take one thing, do not reuse +addresses. + +**Mike Schmidt**: Clara, thanks for posting this research, summarizing it, and +joining us today to talk about it. It's an important topic and I'm glad we have +smart people like you aggregating this information together for us. Thanks for +your time. + +**Clara Shikhelman**: It's been a pleasure. + +_Transaction weight limit with exception to prevent confiscation_ + +Next item from the Changing consensus segment is titled, "Transaction weight +limit with exception to prevent confiscation. Vojtěch, you posted to Delving +Bitcoin, "Non-confiscatory Transaction Weight Limit". Maybe you can explain a +little bit of the motivation for your post, and also wanting to limit +transactions' weight at the consensus level? + +**Vojtěch Strnad**: Sure. So, as you probably know, there is a policy rule in +Bitcoin Core, and other nodes probably as well, that limits the maximum weight +of a transaction to 100 kvB. And we recently went through the exercise of +learning that when people start bypassing a policy rule, then we could just turn +it off, as just happened with OP_RETURN. But in this case, it would not be a +good idea. For example, the weight limit ensures that -- well, let me go to +pre-segwit inputs, which have a quadratic hashing problem. This means that when +you, for example, create a transaction that has 10 times as many inputs, then +it's 100 times as difficult to verify. This is one of the reasons that we have +this limit in the first place. + +Another reason is that block template building gets more difficult the larger +transactions you have. Ideally, you want a lot of small transactions to be able +to construct a semi-optimal template. And the more larger transactions you +have, the more computational power you have to invest to get to a somewhat +optimal result. Actually, the whole problem is, I think, what's known as +NP-complete. So, there is actually not a known solution that would create fast, +optimal templates. And very recently, a couple of mining pools announced that +they would be bypassing this policy rule for the purposes of BitVM transactions, +which have to be very large because BitVM scripts are very large. + +So, what do we do here? Some people would be apparently okay with just making +the policy limits a consensus rule, basically killing BitVM in its infancy. I +thought we could create a sort of carve-out to allow at least one oversized +transaction in a block, but with the provision that it would be the only +transaction in a block. This has a very good reason, because if you allow one +big transaction, then again, block building becomes difficult again. But if you +allow just one, then block building is basically you try the normal block +building process, and then you look at the highest fee oversized transaction, +and you just pick whatever gives you more fees. But there are more problems +with this approach, as I mentioned in my original post and other people +mentioned. + +**Mark Erhardt**: All right. And that sounds like a very good summary already. +I heard BitVM, so I think I'll first ask Robin whether he wants to chime in on +this topic. + +**Robin Linus**: Yeah. So, we are fully aware of the fact that these huge +transactions are a bit crazy. And we are working on an optimization using +double circuits, and they would allow us to get rid of these crazy transactions. +And the craziest transactions that we would have then would be 70 kB, and the +rest would be just standard transactions. Actually, 70 kB is also standard, I +think, so it wouldn't be that bad anymore. It's a huge pain for ourselves to +have these huge transactions. We actually don't want to execute them ever. +Probably they never have to get executed because it's just in case somebody +cheats. But if they cheat, they will lose a lot of money, so they probably +won't do it. So, most likely we won't ever execute them, but in the current +design, it isn't necessary that it would be possible to execute them. But +hopefully we get rid of that. + +**Mark Erhardt**: Right. So, you're not strictly opposed, you're saying, Robin, +because hopefully in the long run, this is not really a limitation of BitVM that +it needs whole blocks of data. Also, you could probably split up your data into +multiple standard transactions. No? Okay, never mind then. Vojtěch, you say +that using the 100,000 vB as an outright limit has some pushback. Do you want +to elaborate why we shouldn't have no exception? + +**Vojtěch Strnad**: Well, the first reason is, as you already know, there are +known use cases for such large transactions. And although they might be able to +optimize to a smaller size, that might not be the case with every possible +future use case. And we probably don't want to close the door forever to +something that could turn out to be actually really helpful in scaling Bitcoin. +So, actually Greg Maxwell chimed in to say that this limit could just expire +after, like, n years. And if by then a use case for large transactions +appeared, we could just let it expire; and if not, we could do another soft fork +to extend it, which is, well, I mean nobody likes soft forks, especially not +recurring. But it's an idea, it's something we can consider. + +**Mark Erhardt**: It would make sense if you think that perhaps we will find +pressing needs for larger transactions in the long run. I have another related +question, which is, the current average transaction size is 340 vbytes. Why do +we even need such a high limit as 100,000 vbytes? Shouldn't we then even soft +fork in a smaller limit that makes it even more likely that people are building +optimal templates with low computational cost? + +**Vojtěch Strnad**: Well, for example, another use case for very large scripts +is huge multisigs, which I don't know who needs, like, 500-of-600 multisig, but +the protocol allows it and since we now allow it, it would look pretty bad if we +removed this option, because people today might be already building with this +option in mind and they wouldn't want to see it removed. + +**Mark Erhardt**: So, even though BitVM was identified as a likely antagonist of +this change, BitVM representative here says it's probably not a big deal. Is +there any other pushback towards this so far, or has it just not hit the news +cycle yet? + +**Vojtěch Strnad**: Well, for example, there have been very large transactions +embedding large jpegs, for example. And even though there are very few people +who would actually be impacted by not being able to do this again, again there's +a kind of rule in soft forks that we don't disallow any existing functionality. +And especially, we try to go around making transactions invalid that people may +already have signed and just not broadcasted yet. For example, if you look at +the reasoning behind the recent consensus cleanup revival from Antoine, he went +to great lengths to make sure this doesn't happen. For example, this proposal +doesn't include the weight limit. It instead proposes a signature limit that's +very generous but still makes the worst case for block validation a lot better. + +**Mark Erhardt**: All right, cool. So, does anyone else want to chime in here +still? + +**Mike Schmidt**: Vojtěch, you may have already articulated this and I missed +it, but what is the challenge that's introduced by having these large +transactions when building a block? + +**Vojtěch Strnad**: It's just that the algorithm for packing blocks optimally +works better. The heuristics work better if there are a lot of small +transactions, because we are not using an optimal algorithm. As I said, that's +NP-complete, that's exponential time, or whatever, so we are using a heuristic +approach that is fast but non-optimal, and it's less optimal if you have large +transactions. + +**Mark Erhardt**: Right. This is about the tail effect when you pack a block. +As soon as you hit the first transaction that has a high enough feerate to be +considered but doesn't fit into the block, you have to compare that with +removing other transactions that were already selected and instead, picking this +bigger transaction. So, where previously with the heuristic, you can basically +just walk down the list of the highest feerate transactions until you have a +full block, as soon as you hit a transaction that is larger than the remainder +of the block, it becomes a 'try all possible combinations' problem, and that is +very expensive to evaluate. + +**Mike Schmidt**: And that goes for cluster mempool as well; cluster mempool +solves this? + +**Mark Erhardt**: That is correct. + +**Vojtěch Strnad**: No, cluster mempool just solves the ancestor and descendant +relationships, but this problem with large transactions is present even when +there are no relationships between those transactions you're mining. + +**Mike Schmidt**: Vojtěch, thank you for joining us. You're welcome to hang on. +We've got one more Changing consensus item, and then we have our Releases and +Notable code segment. + +_Removing outputs from the UTXO set based on value and time_ + +Last Changing consensus item, "Removing outputs from the UTXO set based on value +and time". Robin, your Delving Post proposes a soft fork for removing low-value +outputs from the UTXO set and we can remove them after a certain period of time. +I think all else equal, we all want a smaller UTXO set for Bitcoin, since it +makes running a node easier. In fact, witness discount is one example of a +change previously to incentivize the spending of UTXOs instead of creating them. +But what you're talking about in this post is a little different from that. Can +you get into the origin of and the issues with these low-value outputs, and how +you might see removing them from the UTXO set? + +**Robin Linus**: Yeah, the guys from mempool.space, they published some +interesting statistics about the UTXO set. Essentially, it says that since +ordinals started in, I think, 2023 or something, the amount of UTXOs doubled +from like 90 million to 180 million, or even more. And the serialized size of +the UTXO set even tripled from roughly 4 GB to almost 12 GB. And half of the +UTXO set are dust UTXOs, so they are values of below 500 sats, or something. +And I think it's fair to consider them spam. Also, if you look at the +characteristic that they are hardly ever spent, most of these UTXOs, they get +created and they remain in the UTXO set forever. Maybe at some point in the +future, for some reason, they all get spent at once and we are getting rid of +them, but it's quite likely to assume that they will never get spent. And yeah, +it's a growing problem. And there are all these weird protocols that +incentivize the creation of dust UTXOs for ordinals things, and like all kinds +of means of some meme tokens, all kinds of stuff that is not the core mission of +Bitcoin, I would say. And yeah, that raises the question if we can do something +about it. + +In particular, the entire OP_RETURN drama, I would call it, was started by the +question of Citrea inscribing unspendable outputs into the UTXO set essentially +for proof of publication. So, they use it as a data publication layer, which is +also not very nice. So, I wondered if there is a way to get rid of these spam +UTXOs in some elegant way that wouldn't be too much of an invasive change. My +first idea was just to have an expiry date. So, essentially you take the amount +and then you subtract the UTXO age times the dust limit, or something. So, you +take some formula that essentially tells you when a UTXO expires. And once the +UTXO expires, you just remove it from the UTXO set and it becomes unspendable. +So, that was the first idea. I posted it on Twitter and very quickly, people +wanted to kill me, because they said it's like confiscation maybe! Like, "We +cannot confiscate people's money no matter how many sats; every sat counts and +we should not touch people's money". So, I thought a little bit more about it. + +Also, I talked to Luke Dashjr and he told me that we could just have some kind +of accumulator scheme, and then you could make them spendable after. To explain +it better, UTXOs would still expire, but they would not become unspendable, but +they would be moved into that accumulator. And then, you could spend them by +providing an inclusion proof for your UTXO in that accumulator. And then, yeah, +essentially they are still spendable, but the burden of storing them or the +burden of proving them shifts to the user, away from everyone to that individual +user. And it turns out that we already have a TXO accumulator scheme in +Bitcoin, because the blockchain in itself is actually an accumulator. Since we +already have merkle trees in every block and since everybody's storing the +header chain, we can essentially just use merkle inclusion proofs, the ones that +already exist, to prove inclusion of particular UTXOs in the blockchain. + +So, the only thing that would be missing then would be to prove unspentness. We +could just have quite a compact scheme that would essentially just be a pointer +into the blockchain. So, we would have essentially the block height, then the +transaction index, and then the output index. And this triple would uniquely +identify every UTXO or every TXO in the chain. And then you could just store +sets of these numbers to have all the expired UTXOs or to represent all the +expired UTXOs. And this set can be stored quite compactly. We could compress +it down to, let's say, 200 bytes without too much engineering, because they are +very low entropy. + +**Mark Erhardt**: Sorry, 200 bytes per pruned UTXO? + +**Robin Linus**: In total, sorry. + +**Mark Erhardt**: Oh, okay. I was going to say that's bigger than the UTXO +itself! + +**Robin Linus**: No, no, sorry, that was maybe a bit confusing. I meant for +these 5 GB of dust UTXOs that are currently in the UTXO set, we could compress +them down to roughly 200 MB. + +**Mark Erhardt**: I see, okay. So, basically the idea is if you have very low +value UTXOs, after some amount of time passes and the UTXO has not been moved, +we would add them to an accumulator or some data structure and people can later +spend them, but now they have to add proof. Wouldn't that make it even more +unlikely that they're spent, because now it takes more data to spend them? + +**Robin Linus**: Maybe, but that would be less of a burden because it's way more +compact, like you reduce it down to, I don't know, 5% of the data essentially. +Also, the other thing is that with a very high probability, these UTXOs just +will never get spent in the first place. So, if 99% of them never get spent, we +maybe move the needle to like 99.9%, but this is just negligible actually. + +**Mark Erhardt**: I mean, very likely, all the Sochi spam, for example, with the +1 sat outputs that were spammed at a bunch of different addresses, those are +just economically unspendable at pretty much any feerate. Even if a transaction +only costs 1 sat, making a transaction eats up the entire UTXO amount. So, +there is a limit under which transactions are completely unexpected to be ever +spent. I'm not sure, so the mempool.space UTXO report identified that, I +believe, 49.1% of all UTXOs are 1000 sats or less. So, this is still +significantly above the dust limit for some of the output types. For P2TRto +output, the dust limit is 330 sats, and that's counting how much it would cost +to create the output and spend the UTXO at 3 sats/vB. So, in actuality, to +spend a P2TR keypath output is only 58.5. No, yes, 58.5. Yeah, go ahead. + +**Robin Linus**: I think something like that, but you're right that 1,000 sats +is more than the dust limit for many output types. However, I think they also +published a more, like, fine-grainer statistic and it shows essentially the same +that even for, like, if you look at the specific output types, roughly 50% of +the UTXO set is exactly the dust limit. + +**Mark Erhardt**: We do have to see that since Christmas, about 17 million of +the UTXOs have been consolidated from 187 million to 170 million now. Of +course, we would hope that other people also see that trend, but clearly a lot +don't because we wouldn't have empty blocks if people were consolidating, even +at minimum feerate. So, yeah, to me it makes a lot of sense to say this is such +a tiny amount, and clearly nobody is even spending this at minimum feerate, so +maybe we can just burn it. However, as we know, a lot of bitcoiners are +extremely sensitive regarding confiscation or burning-nation and even for +minuscule amounts like 1 sat, will go to war. + +**Robin Linus**: Yeah, also there's another type of outputs which are provably +unspendable or most likely unspendable, because people are just inscribing +STAMPS, they're inscribing images into the UTXO set and they're doing it +purposefully to spam the UTXO set or to make them unprunable. And all of them +will never get spent because people just don't have the keys to spend them. + +**Mark Erhardt**: I think that is incorrect actually, because STAMPS very +deliberately uses a 1-of-3 multisig scheme, where 2 of the pubkeys are data +carriers, and the 1 pubkey is a key in the wallet, because that way they can +threaten that they would be able to spend it and you actually cannot delete them +from the UTXO set. It's part of their scheme. + +**Robin Linus**: Interesting, yeah. + +**Mark Erhardt**: It's the way to be as annoying as possible. + +**Mike Schmidt**: Diabolical. + +**Robin Linus**: Yeah. With Dust Expiry, you could get rid of them. + +**Mark Erhardt**: You could, yes. I mean, obviously, the people that have +received dust amounts that are not tied to any other sort of asset or +sentimental value are not as perturbed about this. Like, someone losing 1 sat +that they would have to spend 100 sats to ever spend is probably not going to +lose sleep over that. But some people have been using very small amounts to +store inscriptions or ordinals or pictures or Colored Coins protocol, or who +knows what. And of course, for people not running these out-of-band or +client-side validation protocols, they wouldn't be aware of this special meaning +of these UTXOs. So, pruning them away might be considered an attack by these +out-of-band schemers. But looking at the landscape of the OP_RETURN debate in +the past few years, this might be immensely popular with many bitcoiners! + +**Robin Linus**: Yeah, ironically, many people attacked me for it. It was also, +from a PR perspective, really bad to first post the idea of burning the coins +and then coming up with the second one, because people just stopped reading at +'burn' and then they thought I'm the Devil, and then it doesn't matter anymore +what else I said! + +**Mark Erhardt**: Yeah, I know that feeling. + +**Mike Schmidt**: I assume harkening back to our previous topic on quantum, +within that discussion, there's the 'let quantum computers steal these +unmigrated coins' and then there's the 'burn them'. I assume, Robin, you would +be on the side of burning them then, because that would essentially achieve this +goal eventually if that were to happen? + +**Robin Linus**: I don't understand that debate. I would have to dig deeper +into it. I'm not quite sure what the pros and cons are for burning and not +burning it. So, I can't really make a statement about that. + +**Mark Erhardt**: I think that's also not necessarily true, because some of +those UTXOs -- oh, I guess if it's dusting of addresses that had been used +before, it's always address reuse, and yes, they would get burned. But you +could still receive very small amounts to fresh addresses that are hash-based. +So, you could theoretically have some tiny amounts that are not +quantum-vulnerable. + +**Mike Schmidt**: Robin, any parting words, calls to action? + +**Robin Linus**: If you're interested in that, go on Delving Bitcoin and comment +on the thread. For me, it was just a simple idea that I wrote down. I'm not +really working on it. I don't invest that much time actually. I thought it's +just worth writing it down. + +**Mike Schmidt**: Well, Robin, thanks for joining us and opining on not just +this item, but some of the other items as well. We appreciate your time. + +**Robin Linus**: Thanks for having me. + +_Core Lightning 25.05rc1_ + +**Mike Schmidt**: Releases and release candidates, we have two this week. First +one, Core Lightning 25.05rc1, which we covered in depth when Dave had on Alex +Myers a few weeks ago, and that was in #355 podcast. So, check that out for a +comprehensive deep dive by somebody who's involved with the project. + +_LND 0.19.1-beta.rc1_ + +The second release was LND 0.19.1-beta.rc1. We covered the major release, which +was LND 0.19.0-beta in Newsletter and Podcast #355 as well, and this is a minor +follow-up release with some bug fixes. There is a memory leak that was fixed, a +serialization bug around writing a backup file, there's a case where bumpfee +didn't give an error response, they fixed the case where LND would crash related +to running on some 32-bit systems. And then, there was a couple of fixes +related to the rbf-coop-close that they launched in 0.19, one where a peer would +not disconnect properly, and another error where the correct production feature +bit for rbf-coop-closes wasn't being sent. And actually, I don't think that was +a bug, I think that was actually just a feature change in this minor release +that they perhaps forgot in the 0.19.0 release. Murch, did you notice anything +else? All right. + +_Bitcoin Core #32582_ + +Notable code and documentation changes. We have Bitcoin Core #32582, which adds +additional compact block logging to help measure performance of compact block +reconstruction. This PR is related to a Delving post by 0xB10C that we covered +back in Newsletter #315 around compact block reconstruction statistics and some +analysis and data around that. Murch and I discussed that data in Podcast #315, +so if you're curious, jump back to that. The change in this PR now logs +additional information around the total size of transactions that a node +requests from its peers, the number and total size of transactions that a node +sends to its peers, and a timestamp to track how long the mempool lookup step +takes. So, these are all, from what I saw, logging statements in the code. And +so, folks who are going to run the forthcoming version will have access to that +additional log information and be able to run additional statistics, like 0xB10C +did last year. Murch? + +**Mark Erhardt**: Yeah, so David has been looking at the impact of compact block +relay slowing down, and also whether it might make it faster if some of the last +transactions received by nodes before the block arrives were to be sent along +with the block announcement directly. So, I think this is just related to the +work he is doing in order to establish the exact impact and the experiments he's +running, and then why not upstream it and make delogging available to anyone +that wants to look at it. So, yeah, this is a tiny code change. It just adds +eight lines of code, or actually modifies four and adds a few, and just gives a +little more insight in the quality of compact block relay. + +_Bitcoin Core #31375_ + +**Mike Schmidt**: Bitcoin Core #31375 adds a new binary executable named +bitcoin-m, which can be used to discover and launch the various other existing +Bitcoin Core binaries. This PR is actually part of the multiprocess effort +within Bitcoin Core to provide separate binaries for things like the GUI or +node. + +**Mark Erhardt**: This is a PR from end of last year. This is related to the +multiprocess. We're talking about PR #31375. This is part of the multiprocess +project, and as we've debated or discussed in previous versions, the idea of +multiprocess is to split up the Bitcoin Core binary into multiple different +binaries that run in separate processes. Currently, everything runs in one +process. So, for example, when a new block comes in, the wallet will be frozen +for a moment until the block is processed completely. And the idea here is that +you could, for example, separate the node, the GUI, and the RPC client. +Specifically with this new binary, that is a wrapper for the multiprocess +binaries, you can start with bitcoin-m in order to parse which ones of the other +binaries you want to start. Or I think I'm misstating that, sorry. If you call +bitcoin-m, it will start in the multiprocess mode, whereas with just bitcoin, +it'll start the regular old bitcoind. + +As far as I'm aware so far, only the RPC for -ipcbind works differently, and +there is still ongoing work that will enable to make these different processes +run on separate machines, or to be able to start and stop them independently. +So, right now, even though there are multiple processes, I think that everything +would start or stop together when you kick it off. Anyway, this is probably the +longest-running project that is still being actively developed, the multiprocess +thing. We're pretty excited that it's coming along like this. If you want to +understand all the changes and new features, I would suggest that you take +another look at #31375. Presumably, it has release notes that state all of the +relevant information in detail. + +**Mike Schmidt**: The only other thing that I would add, if you can hear me, is +we covered this PR in the PR Review Club segment last month, in the Newsletter +#353, and we had stickies-v from the PR Review Club in Podcast #353, where we +got into some of the more nitty-gritty details of the PR. + +_BIPs #1483_ + +BIPs #1483 merged BIP77 titled, "Async Payjoin". Murch, you want to introduce +our special guest that we didn't previously introduce? + +**Mark Erhardt**: Yeah. Hi, Dan, thank you for joining us. Do you want to +introduce yourself? + +**Dan Gould**: Hi, Murch, hi, Mike. Thanks for having me guys. Yeah, I'm +working on payjoin for a long while. This BIP PR is almost two years coming +along, so it's great to see it merged. + +**Mark Erhardt**: Yeah, I'm very excited. This has been a huge effort by you, +and meanwhile there's I think four or five people part-time or full-time working +on payjoin-related topics. Do you maybe, I think we've talked about this a +little bit already, but I think it's been maybe some 90 episodes or so. So, how +about you give us a little overview again, what exactly maybe payjoin is, how it +differs from the prior payjoin approach, and where we're at? + +**Dan Gould**: Wow, I can't believe it's been 90 episodes. We've definitely +been cranking along. Like you said, there are a number of people working +full-time and part-time and volunteer on Payjoin Dev Kit now to bring this stuff +to the world. But first, let's get through why that matters, why we have +payjoin. So, I think the best frame to view payjoin through is the one of +batching, because people know, through the scaling growing pains that Bitcoin +had, that the exchanges needed to batch outputs in order to reduce the overhead +that it took to make payments, to make transfers, because it cost too much for +people. What the exchanges did though only let them batch outputs of +transactions, because they controlled the whole transaction. If two people, one +on each side of the transaction, maybe one sending us a value and receiving some +value, both batch their inputs and outputs, then you have payjoin. Payjoin is +basically the mechanism to coordinate that kind of batch. + +So, this idea has been around for a while and these transactions that batch +inputs and outputs can be created in all sorts of different ways, both with this +old synchronous payjoin protocol, and even in Lightning, and even before that +with some manual construction where you just pass around transaction data and +come up with a valid transaction. + +**Mark Erhardt**: Let me maybe just jump in very quickly. So, the efficiency +gain of batching payments is, when you make a payment in a single transaction by +itself, you need at least one input and usually you need a change output where +you send to yourself and you have the transaction header. So, you have one +input, one header, one output as overhead for creating one payment output. If +you make many payments in parallel with many different transactions, you pay +always this overhead. If you instead make one transaction, you might have one +or a few inputs, many payment outputs, still only one transaction header, and +still only one change output. So, you can save on the overhead, not of course +on the outputs you want to create, which are the intended goal of the +transaction. + +With payjoin now, when the sender and the receiver collaborate to build a +transaction, you can batch payments with receiving, or you can parse through +payments and you can sort of skip the step where you first receive it and then +consolidate the UTXO later, or spend it in another transaction, by having the +receiver and the sender add inputs and then create a single change output that +goes to the receiver, while also potentially making some payments. + +**Dan Gould**: Yeah, I second all of that, Murch. The important thing to +remember with the savings from batching, the most important thing I think, is +often forgotten, which is that you're not just sharing the transaction overhead, +but you're also reducing the number of inputs you need to spend to enact your +payments. And the input is really the expensive part of the transactions, on +the order of ten times more expensive than the header itself. So, when we can +do more creative batching that allows us to reduce the number of outputs we +create, that reduces the burden of inputs we'll have to spend later. And the +really neat thing that gets a lot of people excited about payjoin is that having +multiple different parties contribute inputs to a transaction breaks this common +input heuristic, where a third-party observer could assume that all the inputs +to a transaction came from one person. And this is a privacy problem that +Satoshi singled out in the whitepaper as something that was kind of necessary +from his design. But payjoin breaks that. + +In the past, what's thought of as payjoin, this coordination mechanism to make +these batches, was a synchronous protocol where I sent a message to someone I +wanted to send to. They would add their input and respond with a message, and +this needed to happen on HTTP synchronously, both people needed to be online. +This BIP77 protocol makes it so that the receiver doesn't need to run a server +and the sender and receiver don't need to be online. This can all happen using +an untrusted third-party server. And we add some improvements to metadata, +privacy, and encrypt messages by default and don't require TLS dependencies. +It's an upgrade focused on adoption. + +**Mark Erhardt**: That sounds super-attractive. Whereas previously, if you +wanted to run or create payjoins, you run your own server, you didn't have all +the payment or all the communication rails to communicate that you wanted to do +a payjoin, and adoption is minuscule. I think BTCPay Server has it. Is there +any other projects that implemented the prior versions of payjoin? + +**Dan Gould**: To receive, I think it was just BTCPay and the JoinMarket client. + +**Mark Erhardt**: Right. So, now, by having the directory where people store +the payment, the PSBT that encodes the payjoin they want to create, and I +believe the directory can actually not read the payload, it is encrypted from +the sender to the receiver and the directory is just serving the space but +cannot interact or even observe what is being negotiated between payer and +receiver, that makes it a lot simpler for any sort of client to implement +payjoin support. + +**Dan Gould**: That's right, Murch. The untrusted directory sees only an 8 kB +blob of random data effectively for each message. So, all the messages look the +same. And in order to interact with the directory, you use an Oblivious HTTP +server so that the directory doesn't even know your IP address. And this makes +it so that the directory doesn't have the ability to link senders and receivers +together, or even link IP addresses to particular people doing payjoins? + +**Mark Erhardt**: Yeah, so I would argue that not just this makes it so much +simpler to implement in wallets, but also PSBTs have come a long way since +payjoin v1 was proposed. We have other standardization schemes like, yeah, I +think PSBT is actually the biggest, but it is much more established by wallets +in general to participate in multiparty transactions or multi-signer +transactions, people who want to sign transactions between their hardware +devices and an online device that tracks the wallet. So, all of the +infrastructure to make this happen has been built out a lot more than it used +to. + +**Dan Gould**: Yeah, three huge things on this point. One is that the Oblivious +HTTP does the metadata hiding without Tor. So, it actually just works in the +web browser even. If you can do some basic encryption using cryptographic +primitives that are used by any software that uses Bitcoin, then you have the +ability to send the network messages, as long as you can send HTTP. The second +thing is that, like you said, PSBT is everywhere. So, basically, any sort of +Bitcoin wallet library is able to do this. And the third is that the +asynchronous operation has a benefit, I think, beyond what's really talked about +in public, which is that a lot of these payment processors, say you're an +exchange and you want to adopt this to cut through withdrawal to user deposits, +you want to batch these transactions together so you can save even more money on +the type of batching you do already, your payment processing system is probably +asynchronous. It might not necessarily be offline, but you probably have some +manual authorization that goes through. + +So, a big part of why we ended up building this robust async system was so that +we could be used with the payment processors. You'd be surprised how difficult +it is. Well, maybe you wouldn't be surprised, but I think the world at large +would be surprised how difficult it is to get a synchronous endpoint to be +served by an exchange where there's all this logic happening in the background. +So, like I said, everything serves so that the payjoin protocol can be adopted +all over the place by using the Payjoin Dev Kit. + +**Mark Erhardt**: So, you're saying that this saves cost and that's the primary +purpose? + +**Dan Gould**: I think that's the most attractive purpose. I think a lot of +people want to adopt this because of the privacy benefits, of course. You see +it, the early adopters were Bull Bitcoin Mobile, who has plans to integrate with +their exchange. This is public, Francis will go and tweet about this. And you +have Cake Wallet, who's really interested in the privacy aspects of it. So, +they rolled out payjoin v2, the async payjoin, in their mobile wallet. And it's +all interoperable, backwards-compatible with the synchronous payjoin of old. +But I think for those businesses to stay competitive, you have to support +batching going forward. And I think payjoin is just the next iteration of +batching. And as a consequence, we can have a privacy-by-default upgrade, where +maybe you don't have perfect privacy, but payjoin makes it so that the most +aggressive surveillance practices, dragnet surveillance practices, are +significantly less effective than they used to be, even if just some of the +volume on the network is using this technique. + +**Mark Erhardt**: Yeah. So, by breaking the common input ownership heuristic, +which was described by Satoshi in the whitepaper saying, "If you see a +transaction, very likely all the inputs must have been controlled by the same +party", and even if there's just a number of transactions that break this +heuristic, it will sow some doubt about this heuristic, and clustering just +addresses based on the common input ownership heuristic will be less reliable. +It'll increase the effort to do onchain surveillance. + +**Dan Gould**: Which is important, particularly as bitcoin gets adopted as +money, because having this clustering available brings a lot of risk to bitcoin +holders for something like a wrench attack. If you're transferring money to a +counterparty and that counterparty can cluster your whole wallet, figure out how +much money you have, figure out the people you're doing business with, they +might be able to profile an individual as a particularly lucrative target for +attack. So, having some basic privacy makes it more attractive and convenient +to use bitcoin as money, especially self-custody, where otherwise maybe you'd +say, "Oh, I need to put all my money in the exchange, all my bitcoin, I need to +use a custodian, because they give me that level of protection”. + +**Mark Erhardt**: I would also argue that it's extremely attractive for people +accepting onchain payments, because one of the things that leaks is volume of +business and it leaks information about their business patterns and success to +their competitors; and making it slightly more private on how much money flows +through their business might also be attractive from the business and receiver +side. + +**Dan Gould**: Agreed. + +**Mark Erhardt**: So, let's back out a little bit. You said there's these +directory servers and pretty much anyone could run one of them, and then if I +run a client that connects to a directory, would I be able to get to verify that +all these privacy properties hold as discussed? + +**Dan Gould**: So, anyone can run the directory because the source code is all +at github.com/payjoin/rust-payjoin. You'll see the directory there. You spin +it up and provision TLS and someone can connect to it through an Oblivious HTTP +relay. The clients do all of the privacy-preserving measures. So, your client, +if it is a correct client, if you use Payjoin Dev Kit, or hopefully we see some +alternative clients now that the BIP is merged and people have a spec to build +to, but if you have a proper client, the client is doing the encryption and +encapsulation through Oblivious HTTP so that the payload you send is exactly +uniform with all of the other payloads, and you don't have to worry that a +directory is malicious. You're not trusting the directory to preserve your +privacy. + +**Mark Erhardt**: If the payload is limited to 8 kB, does that mean you can only +create small transactions? + +**Dan Gould**: For the time being, with our current iteration, that is the case. +This is on the order of tens of inputs; I think hundreds of inputs would be very +hard. But it's possible to append messages through multiple mailboxes. It's +something we haven't implemented yet. I think it's important to note for +transparency that if you use v1, you're sending an unencrypted payload, so the +directory would be able to see that you're giving it to a third party. This is +a limitation of the v1 protocol. However, in that protocol, the v2 receiver +that's backwards-compatible with the v1 sender will disable output substitution +so money can't be stolen, but the directory could see that there's an original +PSBT that gets upgraded to a payjoin. So, you don't have the same privacy. The +common input ownership heuristic isn't broken from the perspective of the +directory, but this is kind of a limitation of v1 that's already there. + +**Mark Erhardt**: Right. So, you're saying that while you're fully +backward-compatible with v1, if you're implementing this just now, go +straightaway, just implement v2, you get all of the bells and whistles of the v2 +protocol? + +**Dan Gould**: Definitely. + +**Mark Erhardt**: So, you said that there is now work on the Payjoin Dev Kit. +Do you want to talk maybe a moment about that? + +**Dan Gould**: I'd love to. So, Payjoin Dev Kit is exactly what it sounds like. +It's a software development kit that lets you plug payjoin into whatever wallet +you have. So, it's just pure functions with the machinery to validate the PSBT +you get from your wallet, package it into a nice network message, and send it to +the directory so that your counterparty can receive it and handle all the +errors. All the main code is in Rust and we have foreign language bindings +through FFI. Right now, our Flutter bindings are the furthest along because +Bull Bitcoin and Cake needed them. We've also got some Python bindings, but +we're actively recruiting someone to help with the FFI bindings so that we can +have this correct implementation of Rust delivered across languages. And I +think for reference, it's kind of attractive to people to understand that this +is also actually how even Signal works. They've got this core, correct +Rust-type state machine, and then all of their mobile implementations, desktop +implementations are foreign language bindings that bind back into that one +really well-tested code path. + +**Mark Erhardt**: That sounds cool. So, now that the BIP is merged, what are +the next steps? How are you anticipating that payjoin moves forward? + +**Dan Gould**: There are so many! I wish it was one thing, you know? So, like +I said, the foreign function interface bindings, the Payjoin Dev Kit, making +that robust, getting the documentation out there, having other people actually +do the integrations on their own is a huge part of what we're doing. But even +below that, making the library ergonomic so that you can't shoot yourself in the +foot is definitely our number one priority. Getting the Rust to a point where +you can just have it in your UI, we tell you exactly what to present to your +users, we tell you exactly which tick boxes to give them, is what we're rolling +out in our next release. So, if you use the Bull Bitcoin or the Cake Wallet +implementations, you might see that they're a little limited and you're not +entirely sure what's happening under the hood. And we want to expose a little +bit more of that status to the end user wallets. + +Then, once we have those two things, once we have the correct state machine that +exposes the status, once we have the foreign language interface, then it really +comes to the hard work of integrations, where we are working with wallets and +service providers and institutions to get this into their hands and make sure +everything works for them with support. + +**Mark Erhardt**: I just had a random thought. So, payjoin is specifically +aimed at two parties collaborating, I believe, a sender and a receiver. Would +it be thinkable that multiple parties build a transaction using payjoin? + +**Dan Gould**: It would. There's actually a hidden feature in Payjoin Dev Kit +that lets you do this with multiple senders right now to one receiver. So, if +you had, like, four different senders, the receiver can wait until it gets a +number of them and then respond to all of them for signatures. This requires +more communication, it's not just one round of communication. We intend to -- +when I say 'we', I'm talking about all of us working on Payjoin Dev Kit, we've +got a great team -- we intend to keep this asynchronous so that it can be +robust. But I think in the future, you might be able to think of this as sort +of a pseudo, like a pre-mempool of its own, where you have your PSBT, your +transaction intent that you want to communicate with everyone else who's willing +to make a batch. And you can get benefits from that, which is maybe someone's +willing to pay for a little bit of privacy, maybe you're going to get a better +feerate from delaying and batching with a whole bunch of people. So, your +effective fee is less for the same output. + +This is on the horizon. We do need help with research to this end. We're +really focusing on what we just merged after two years, getting this into +wallets. But I think the future does hold a special place for multiparty +payjoin. + +**Mark Erhardt**: Cool, that sounds exciting. Are you then worried about people +talking about limiting the size of transactions? We discussed this earlier, I +don't know if you had joined already. + +**Dan Gould**: It depends to what extent, right? I don't know the orders of +magnitude. Maybe I wasn't paying attention. + +**Mark Erhardt**: Sorry, this is a little out of the leftfield, but we were +discussing earlier about a proposal to reduce the transaction size limit to the +current standard size limit. Vojtěch was talking about his proposal in that +regard. So, currently the proposal says the maximum standard transaction size +would become a consensus limit, so 100 kvB, which of course is a lot bigger than +the current 8 kB that you were talking about. + +**Dan Gould**: Yeah, I think you can still get significant improvements when it +comes to batching at the size of 100 kvB. But yeah, I don't know how popular +such a proposal would be in the first place. So, need I even worry about it? +I'm not sure. + +**Mark Erhardt**: All right. I think we've covered both the asynchronous +payjoin proposal, or payjoin v2, quite extensively. The BIP is BIP77. It is +now available in your favorite BIP websites, and of course the BIP's repository +itself. And so, do you have any other parting words or calls to action? + +**Dan Gould**: I want to shout out all the people that have supported the +project, both financially and with development effort. They're many. And I +think if you're interested in contributing, then we definitely need some help +with FFI and we need some help with research. Get in touch at payjoin.org, +you'll find our contact information. + +**Mark Erhardt**: Thank you very much for sticking around so long and for this +comprehensive overview of BIP77. All right, I think that wraps our newsletter +today. I would like to thank my co-host, Mike, and all of our guests, Jose, +Clara, Vojtěch, Robin and Dan. Thank you again for your time and I'll hear you +next week. {% include references.md %} From 4f9cc5a3ca63e0d2658cd3a38f71f0666efe9daa Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Mon, 30 Jun 2025 12:15:06 -0500 Subject: [PATCH 133/278] Podcast: add 358 transcription --- .../en/podcast/2025-06-17-newsletter-recap.md | 1115 ++++++++++++++++- 1 file changed, 1114 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-06-17-newsletter-recap.md b/_posts/en/podcast/2025-06-17-newsletter-recap.md index 0926eb375c..64995cb02b 100644 --- a/_posts/en/podcast/2025-06-17-newsletter-recap.md +++ b/_posts/en/podcast/2025-06-17-newsletter-recap.md @@ -19,6 +19,1119 @@ Josh Doman, and TheCharlatan to discuss [Newsletter #358]({{page.reference}}). ## Transcription -_transcription coming soon_ +**Mike Schmidt**: Welcome to Optech Newsletter #358 Recap. We're going to talk +today about selfish mining, transaction relay censorship resistance, we have +updates to BIP390, the MuSig descriptor spec, we have a discussion about a +library for encrypting descriptors, a PR Review Club covering the bitcoinkernel +project, and our usual Releases and Notable code segments. I'm joined by my +co-host, Murch today, and we have some special guests. Antoine? + +**Antoine Poinsot**: Hey, my name is Antoine Poinsot, I work at Chaincode Labs. + +**Mike Schmidt**: Josh? + +**Josh Doman**: Hi, my name is Josh Doman, I'm an independent developer. + +**Mike Schmidt**: Charlatan? + +**TheCharlatan**: Hi, I'm TheCharlatan, and I work on Bitcoin Core. + +_Calculating the selfish mining danger threshold_ + +**Mike Schmidt**: Thank you all for joining us this week. We have a few news +items that you all are a part of, and so we'll jump into that right now, +starting with, "Calculating the selfish mining danger threshold". Antoine, you +posted to Delving Bitcoin a post titled, "Where does the 33.33% threshold for +selfish mining come from?" And maybe for our listeners, we can frame things a +little bit first. Maybe first, what is selfish mining? + +**Antoine Poinsot**: Selfish mining is a strategy that a miner can follow that +consists in strategically withholding blocks when they find a block. So, in +this case, when I mean a miner, I mean essentially a mining pool, or of course a +very big solo miner. And by default, Bitcoin Core nodes are going to broadcast +a block as soon as a miner finds it. And a selfish miner is going to diverge +from this basic strategy, that is optimal up to a certain threshold, in the hope +of actually finding a higher proportion of blocks compared to the hashrate, the +share of the network hashrate it controls. + +**Mike Schmidt**: All right, great. And so, can you get into some of the +previous research on selfish mining, and then what you and Clara jumped into +when you got a little deeper into that? + +**Antoine Poinsot**: So, something akin to selfish mining was discussed very +early on in Bitcoin Talk in 2010, and it was later formalized and laid out in +details in a 2013 research paper, which described the strategy, which is the +paper I linked to and I studied with Clara, and that my write-up is based on. +This research paper was pretty seminal, because it not only demonstrated that it +was possible for a miner to follow a more optimal strategy than the "honest" +one, rather let's say the default one, if they can sibyl the network, which is +if they can get their block to propagate faster than everybody else; but also, +if they do not have this ability, the strategy is more optimal past a certain +threshold and after enough time. Then, selfish mining was later studied more +and more after this paper, which opened up a whole lot of research, and there +were many papers with slightly tweaked selfish mining strategies. I'm not +familiar with every one of them, but there is some more optimal strategies that +depend on other conditions and other parameters. But I was more interested in +getting the intuition and verifying the math behind the actual basic strategy +of, "I do not have a privileged access to the P2P Network. I can still follow +independently, without coordinating with anybody else, a strategy that is going +to guarantee me finding more blocks after enough time". + +**Mike Schmidt**: Can you explain the privileged status or the sybling the +network for faster propagation? How does that come into it? Is this to +mitigate chances of orphan, or something else? + +**Mark Erhardt**: Yeah, exactly, to mitigate the probability that you get a +stale block. So, the intuition behind selfish mining is that you are going to +try to cause more stale blocks to the rest of miners on the network than you +have to yourself. Because mining in Bitcoin is a zero-sum game, you can +increase your gain by making your competition fail more rather than improving +yourself. Like, both strategies are equivalent. And it is a zero-sum game +because of the difficulty adjustments which is, let's say you have 40% of the +network hashrates and you have a stale rate of, I don't know, 25%, and then you +cause to the rest of the network, the 60% of the rest of the hashrate, you cause +them to have, I don't know, a 50% stale rate, then the network as large is going +to only find, as I said here, is only going to find 60% of the blocks it should +have found within two weeks. So, it's going to take longer to find these +blocks, so the difficulty is going to readjust to take the stale rate into +account. And once the difficulty readjusts, you're just going to have a higher +proportion of the actual blocks found, because you have a lower stale rate. + +So, yeah, selfish mining is all about stale rate. And just to answer your +question from Mike then, Murch, and then to answer your previous question about +the propagation, how it plays into this, is that you're often going to end up in +a race in selfish mining, whereby some other miner in the network found a block, +they propagated to the rest of the network and you had a block that you had not +propagated. And you learn that actually this other miner found a block and so +you want to propagate your own private block to the rest of the network as soon +as possible, and this other miner obviously wants to do the same. And there is +a race parameter in the selfish mining paper which guides the assumption of the +share of the network you can get your block first before the other miner can get +to them. And if you can get your block first to them, it means that they will +start mining on top of your blocks, which increases the likelihood that the +other miner is going to go stale and not you. + +**Mark Erhardt**: Sorry, you said that the rest of the network would have a +stale rate of 60%, while the selfish miner would have a stale rate of 25%. How +can a miner that is in the minority have a lower stale rate than the rest of the +network? I would have assumed that the stale rate would be higher on the +selfish miner, but it would still work out for them in general. + +**Antoine Poinsot**: Yeah, so the numbers I stated were just arbitrary to just +illustrate the zero-sum game of the difficulty adjustment. But this is how, if +you run the simulation that I provided in my post, you will see that the selfish +miner has a lower rate. And this is because the selfish miner is not announcing +its blocks by default, which is a lot like the honest -- all the other miners +are assumed to follow the default strategy of always publishing their blocks. +If they don't, well then the model does not take that into account. And in this +case, you can think of multiple scenarios. + +**Mark Erhardt**: Sorry, I think I just got it. May I jump in? So, the stale +rate only applies to cases where there is two competing blocks. And in the case +that there are competing blocks, it goes well in 75% of the cases for the +attacker and 40% for the defender. Is that what you were … no? Okay, sorry. + +**Antoine Poinsot**: No, the stale rate is over a period, you're going to find +very, very high stale rates for it. That's why we say that selfish mining would +be obvious if one miner starts following it, because massive stale rates and a +lot of reorgs on the network. And tl;dr, the reason why the selfish miner +imposes a higher set stale rate than the others is that the others are going to +waste the hashrate mining on blocks that are guaranteed to go stale when a +selfish miner manages to find a longer chain. So, you can think about it like +the paper does by describing the various situations you can end up in. A +selfish miner is always going to, when he finds the block, he just puts it on +the side privately. He never announces it by default, which is if the selfish +miner finds a second block on top of his private block, then he's guaranteed +that as soon as someone publishes a block, he's just going to reorg it out, +which is for the whole time that the rest of the network is trying to find this +block that is guaranteed to go stale. And this is why, because the rest of the +network is not keeping it private and doing the same to the selfish miner. The +selfish miner is taking advantage that the rest of the network is telling him, +"Hey, I have that many blocks, I have that many", and then the selfish miner has +knowledge of how much advance it has compared to the rest of the network. And +that's why it allows the selfish miner to strategically release the blocks that +he withheld and cause a higher stale rate. + +**Mark Erhardt**: Right, of course. The attack only starts if the attacker +finds the first block, and this just randomly happens. And since it's a +progress-free competition, it's the same as time zero for everyone else, they +are still working on the same height. So, let's say an attacker has 40%, just +as you earlier said, now they have a 40% chance to find the next block before +everyone else finds this block. That's not true. 40%, they find the next block +while 60%, the others find a block. So, it's almost two-thirds the chance of +succeeding at that point, right? + +**Antoine Poinsot**: Yeah. So, you can simplify this by just saying that when +the honest network is finding a block, the miner is just going to change step +and start mining on top of this block. So, at any point in time, the selfish +miner has 16% chances of finding two blocks in a row. As soon as they find two +blocks in a row, they're guaranteed that the rest of the miner is wasting their +hashrate mining on a stale block. + +**Mark Erhardt**: And the simulation assumes now that he always loses races, or +that he wins some of the races? + +**Antoine Poinsot**: The simulation is for the worst case and my study is for +the worst case for the selfish miner, which is he always loses all races; that +is, in the event that he finds a block, keeps it private, but does not find a +second block on top of it, and then the rest of the network finds a block. +There is a 1-block race. And in this case, the selfish miner is propagated as +soon as possible, or its the same. And in this case, we just assume that the +only miner mining on top of the selfish miner's block is itself, nobody else. +Everybody else is mining on top of the "honest block". I don't like to assign +honest business to this, because it's a possible strategy. + +**Mark Erhardt**: So, what spurred this renewed interest in selfish mining? + +**Antoine Poinsot**: I don't know. I guess I always just thought I understood +it and I didn't. And then I went to the paper and I wanted to study the math +and I couldn't, but I have the chance of being at Chaincode and I have a math +PhD sitting next to me. So, I was like, "Clara, can you explain me the math in +the paper?" And so, we went through the math together and I got a better grasp +of it, so I wanted to share. + +**Mark Erhardt**: Well, okay, let's say the motivation might have been that two +miners together have, or one mining pool plus all the mining pools that appear +to work on the same block template has 41% of the hashrate. + +**Antoine Poinsot**: Yeah, ANTPOOL could clearly pull up selfish mining. It's +unclear why they don't start doing it. It's also the case that the model does +not describe, what if multiple selfish miners appear at the same time, because +let's say that, I don't know, in response to this, Foundry and MARA joined +forces to do the same, they would be past the threshold, where they are able to +do the same. And in this case, I tried to run it on my simulation, it was doing +random stuff. So, it's pretty unclear. So, the uncertainty certainly plays a +big part, but it's also the case that the mining subsidy is decreasing +exponentially, so we should expect miners to start playing games at some point, +I think. + +**Mark Erhardt**: Two selfish miners with both over 30% sounds quite horrible, +because only less than a third of the hashrate would then announce naturally, +and then almost always get reorged by two blocks immediately. So, that sounds +like a ton of reorgs. That sounds like a very unstable network. + +**Antoine Poinsot**: Yeah, and also, which is the argument that is put forth in +the paper, is that the selfish mining pool is going to find a lot more blocks +than its hashrate at the expense of the smaller pool. So, miners on the smaller +pools are going to have to switch pool or go belly up. The operation won't be +able to continue if they just cannot pay the bill. So, it's really going to +lead to an equilibrium, a large, big pool. And maybe in the case of two selfish +miners, maybe two large, big pools, but I don't know, I have not studied. + +**Mark Erhardt**: I think it would maybe even lead to basically a majority +attack, because the other selfish miner does not announce blocks either. So, +they would only announce if something is broadcast. So, I don't even know what +would happen if the selfish miner is in the absolute majority. Would they ever +publish a blog? Anyway, this sounds fascinating. So, what were your learnings? + +**Antoine Poinsot**: That it's real, I guess. This is a strategy. There is +some uncertainty attached to actually pulling it up on the main network. You +don't get revenues from it immediately. You need to wait after the difficulty +adjust and it would be very obvious. + +**Mark Erhardt**: I mean, you'll have standard revenue at least, right? You +find 40% of the blocks before you start attacking, and then you will still have +the same absolute count of blocks found, but probably the fees would -- yeah, +yes, of course. + +**Antoine Poinsot**: No, you inflict to yourself some stale rate. + +**Mark Erhardt**: Oh, right, okay. You actually do lower your revenue +temporarily? Right. Okay, fair. + +**Antoine Poinsot**: In the long run. So, you've got some costs, some +short-term costs, you've got some certainty, and you've got probably an angry +Bitcoin community, but I don't think that's a big argument, because it's unclear +also how we would fix it as well. + +**Mike Schmidt**: Yeah, that's what I was going to say. We're bitcoiners and we +want to do something about this. It sounds like there's no magic. + +**Antoine Poinsot**: There has been research on the topic. And one obvious +thing is to take stale blocks into account in the difficulty adjustments, which +is a hard fork, and might also create perverse incentives for other reasons. +For instance, we have seen some altcoins that were playing with different +difficulty adjustments, calculations and rewards calculations. For instance, +Ethereum had this anchor blocks that they took into account, but then they +didn't take into account for the difficulty adjustments, so it didn't prevent +selfish mining. But then, it still incentivized anchor mining, which was, you +had the strategy on Ethereum at the very beginning where you could just mine +anchor blocks instead of mining the main blocks, and it was more profitable for +a miner. So, yes, it's probably something we don't want to really have to +touch. But probably we should have a plan in case it happens. + +**Mark Erhardt**: Although there's been more research since then and there's +some interesting proposals I saw. One of the two authors of the 2013 paper, +Ittay Eyal, I think, had, what was it called, Colored Chain proposal, that we +talked about at the Bitcoin Research Week. But anyway. + +**Antoine Poinsot**: Yeah, I don't remember how it works, but I did hear about +it as well. + +**Mike Schmidt**: All right, Antoine, thanks for jumping on and explaining the +summary of that research for us. We don't have Peter Todd here for the next +news item, but I did pencil in a Notable code diversion for Bitcoin Core #32406. +Antoine, you want to hang on for that one? + +**Antoine Poinsot**: That's the OP_RETURN one, right? + +**Mike Schmidt**: Yes. + +**Antoine Poinsot**: Sure. + +_Bitcoin Core #32406_ + +**Mike Schmidt**: Yeah, okay. So, #32406 removes the existing 83-byte OP_RETURN +limit by raising the default data carrier size while keeping the data carrier +options and marking them as deprecated. So, for reference and for listeners, +Murch, you and Sjors spoke about a lot of discussion around this PR in +Newsletter #352, we covered it; and Podcast #352, you and Sjors went through +that for about an hour or so. So, listeners can go back to that to hear that +chat if they haven't already listened. But, Antoine, since then, I think the +dust has settled, the PR's merged. What's your perspective on this PR? How +would you summarize any updates since a few weeks ago for our listeners? + +**Antoine Poinsot**: I'm not sure what to say. Yeah, the PR was merged. It was +pretty obvious given the wide consensus that were around this PR from all +Bitcoin Core contributors. It's going to be released in the next version, the +next Bitcoin Core version, which is going to be 30.0, which, Murch, I think is +expected in three months, something like that? + +**Mark Erhardt**: October. + +**Antoine Poinsot**: Okay, so four months. And yeah, I think we probably won't +talk about it much at this point. I don't think it's going to have much effect, +if only to avoid the perverse incentives that it was setting for people that +just want to rely on it for their timely transactions. Yeah, I don't have much +to say, to be honest. + +**Mike Schmidt**: Murch, it looks like you want to say something. + +**Mark Erhardt**: Yeah, well, I've been following the debate a lot. I've also +spent a lot of time talking to various people that had concerns around this PR. +My takeaway was that first of all, I still think that this policy is pretty much +a nothing burger. A lot of people misunderstand that this is only a mempool +policy change, which means it affects only what unconfirmed transactions are +being accepted to the mempool of Bitcoin Core nodes and being relayed to their +peers. I think a lot of people misunderstood that even though something like +99.5% of all nodes on the network were not forwarding large OP_RETURN +transactions, we've seen over 10,000 OP_RETURN transactions that break this +limit in recent blocks. So, I think we see that the narrative that having a +mempool policy broadly adopted, almost absolutely adopted, does not prevent +these transactions to be in blocks. Sure, they only get mined by two miners +currently, or two mining pools I should say, and these two mining pools earn +more on their block templates due to being able to include these juicier +transactions, so it is rational for them to include them. They're consensus +valid after all, so the blocks will propagate just fine. + +I think that one of the things that bothered me a bit was that the effectiveness +of not including these transactions in your own mempool was heavily overstated. +We see them get included at minimum feerate in whatever block is mined next by +some miner that includes them. So, I think the policy does only hamper the +other miners from having an equal footing in earning revenue. Either way, the +other thing that a lot of people were concerned about was that this would +immensely increase block sizes, and it cannot increase block sizes because +OP_RETURN data lives in outputs, and outputs are non-witness data, so they have +a weight of 4 weight units per byte. And if you fill a block with non-witness +data, blocks cannot be more than 1 MB. + +So, finally, it's only more economic to create OP_RETURN outputs up to about 140 +bytes before the existing inscription construction is cheaper. And I think the +concern that we'll see humongous OP_RETURNS all the time is overblown. We will +see some because people are doing BitVM and other second-layer constructions +that rely on humongous commitments in transactions, and they're just going out +of band. They even have signed agreements already with mining pools that they +will be able to get their transactions mined. So, I think the obvious choice is +just to accept these into the mempools so that all mining pools will include +them and have an equal footing, even if it means that there will be minusculely +more data moved towards OP_RETURNS from other ways of including data in blocks, +or maybe even a little bit of extra data being included. Because overall, we've +just talked about selfish mining. We talked about how two block template +creators create about 71% of all blocks. If we want smaller mining pools to +have the best chance to participate in the mining ecosystem, we are going to +have to try to make it as fair as possible to them. + +So, I don't know. The whole debate seems just fueled by the other side being +very invested in it, and us being not that invested in it, because it just +doesn't feel like that big of a deal. But yeah, so it got merged. Finally, I +had one final takeaway that's important. A ton of people approached me and said +that they were less upset about the limit increasing, but more upset about the +option going away and them not being able to control what is in their mempool. +Now, I think that is a little bit of an unnecessary option for people that just +run nodes at home. But one thing that actually convinced me was, people that +want to move forward and build their own block templates, and do not want to +include large OP_RETURNS, can use this option to control what is in their block +template. So, I think I'll continue to argue that we don't remove it in the +next version after 30, so 31. If people continue to have that sentiment, it is +deprecated in the sense that developers are suggesting that you don't use it +unless you know exactly what you're doing, because we think that it's overall +better for the health of the network if you accept large OP_RETURNS and forward +them to small miners. But if you do wish, I assume that the option will stay +probably for another version or two at least. + +Anyway, that's my takeaway. Yes it got merged because it had very broad support +by Bitcoin Core developers, and I think also most of the technical community was +very convinced after they actually engaged with the arguments. But we should do +a better job of explaining stuff to the broader ecosystem. + +**Antoine Poinsot**: I have two things to add to this, besides that I disagree +with regard to the option, but I won't die on this hill, I think it's fine if it +stays. You mentioned mining centralization. I think it's worth underlining +that if we have, in Bitcoin, structural forces that just push to having miners +that control more than half of the hashrate, then Bitcoin is worthless. Like +the entire point of Bitcoin is censorship-resistant transactions. If one person +decides whether you get your transaction in or not, it has no purpose. It's +just a very expensive way of doing something that could be done much more +efficiently. And then, which is interesting, because the company that has been +financing this whole communication operation against Bitcoin Core for this +change has claimed that were mining more decentralized, it would not be an +issue. And I think it's a big confusion, because if you just go through the +thought experiment of a completely decentralized mining, then people that just +want to get their transaction just mine blocks to get their transaction in. And +there is no more such thing as limiting transaction based on mempool policy, +right? So, the more mining was decentralized, the less the mempool policy +matters. + +**Mark Erhardt**: I feel like you're skipping a few steps in that line of +argument. Sure, if people wanted specific transactions to be mined and they +could go and mine a block, they would get it in, of course, if it's consensus +valid. But also, to mine a block is a significant investment. So, if they were +trying to do it and not succeeding, they would just spend a lot of money on it. +I'm not sure if that's really an effective way of getting your own transactions +mined. + +**Antoine Poinsot**: Yeah, I might say what I mean is that the Bitcoin Core +standardness is relevant to Bitcoin just because of how centralized mining has +been and because a few actors have been respecting the Bitcoin Core standardness +rules. The more actors you would have, the more likely it would be that one of +them would just stop respecting it. So, the more decentralized the mining, the +less the central decision of Bitcoin Core on standardness matters. That was my +point. It's not as easy as just saying anyone could be drafting a block. It's +just on a spectrum, it would be much easier if you have more diversity. + +Then the other point was, yeah, well, maybe not worth rehashing this. So, yeah, +that's all. + +**Mike Schmidt**: Antoine, thanks for hanging on for that Notable code +diversion. We understand if you have other things to do, and you're welcome to +stay if you'd like. + +**Antoine Poinsot**: Thanks for having me. + +_Descriptor encryption library_ + +**Mike Schmidt**: All right. Our next item was, "Relay censorship resistance", +but Peter's not here. I'm going to stall for him by skipping a little bit out +of order here, and we will go to, "Descriptor encryption library". Josh, you +posted to Delving Bitcoin about your descriptor encrypt Rust library for +encrypting wallet descriptors. Maybe before we get into the library, can you +explain a little bit about your motivation for wanting to encrypt wallet +descriptors? + +**Josh Doman**: Sure. Thanks for having me. I am relatively new to Bitcoin and +the way that I got comfortable initially with the idea of self-custody was when +I learned about multisigs. And so, I went through this process of setting up a +multisig, and at the end of the process, I was surprised to learn that my seed +phrases were not enough to actually recover my funds. I was using one of the +service providers that do collaborative custody, and it was a really shocking +kind of scary user experience to be thrust at the end of the page with this +scary thing you've never seen before, that you also need a backup somewhere and +you don't know what it is. And so, my motivation was to find a way to backup +that data in a public format so that people don't need to back up offline +anything but their seed phrases to help improve that user experience and make it +a little bit safer. Because a lot of people are scared off today from +multisigs, based on things they see on Twitter about how you can lose your +money. So, that was my initial motivation. + +I built kind of a proof of concept over a week or so earlier this year that only +worked for standard multisigs, that lets you basically encrypt it and then store +it as an inscription on the blockchain, which I know there's a lot of different +people with different opinions about whether that's something that's appropriate +to do or not. But for me, it solved my problem because I could make a one-time +payment and not have to worry about it ever again. The horror of it though is +finding a way to encrypt descriptors such that you cannot decrypt it without +having enough keys to spend the funds. And so, that's what this library does. + +I was motivated for a couple of key reasons. I spoke with notmandatory, who +encouraged me. That was pretty cool. He said, "You should make this a Rust +library so that wallets could integrate it". And then, I also saw a post that's +independent of what I had built by salvatoshi, who had devised his own +encryption scheme that was simpler than this. It only encrypts the descriptor +with one of the keys in the descriptor. So, if you have one key, you can +decrypt it. And I wanted to flesh out my approach, which is a little bit more +robust and better for certain use cases, especially if things are stored in +public, or if for whatever reason you want to store your descriptor next to your +seed phrase, but you don't want someone to be able to see how much funds you +have. And so, this is also my project for the Bitcoin 2025 hackathon, and so +those are my motivations for building this. + +**Mike Schmidt**: Okay, great. Yeah, go ahead, Murch. + +**Mark Erhardt**: So, basically the idea is usually when you have a multisig, +let's say 2-of-3 multisig, you require two private keys in order to spend, but +of course you need all three public keys in order to be able to recover what +your UTXOs actually were, plus the information how the multisig was constructed, +which usually has some derivation path information, and so forth. So, this has +been a problem for a long time. People have been confused for years about, "Oh, +I have two of my keys. Can I get my funds back?" No, you can't, because you +don't have the third public key. So, the standard solution to this was usually +that with the file that backs up your private key, you also store a description +of your wallet. And this got way easier with descriptors, because previously +with the xpubs, you actually didn't have information about what the keys were +used in, what output scripts, because it only encoded the key information. + +So, what I'm gathering here is instead of just storing the descriptor +information next to one of the key backups and with every one of your key +backups, you are encrypting it. And other than salvatoshi, where you need a +single key to decrypt it, which means if anyone gets one of your backups, they +can see both the key and re-derive the descriptor and therefore see all of your +funds, this one requires them to have a spending quorum in order to see it. +What's this about putting it in the blockchain for backup? + +**Josh Doman**: I would say that each to their own. I think that this is +clearly a very sensitive topic, and a lot of people are against putting anything +that's not payment-related data in the blockchain. One of the reasons why I +felt that this was kosher is that I do consider it payment-related data. I need +this data to spend my funds. And various projects, like utreexo, require users +to back up other data that if they're running a light client, that today already +exists on that blockchain. So, that's the philosophical approach for why I +think it's okay. I think that the answer to your question is you don't have to +back it up on the blockchain, and this library does not dictate you do so. This +is purely a library to very efficiently encode the descriptor data, minimum +number of bytes, and encrypt it. You can store it wherever you like. + +Now one of the reasons why putting it on the Bitcoin blockchain is useful is it +makes recovery much simpler, especially for people who maybe are your heirs or +people who don't know where to look. Because it's in a fairly well-recognized +place where you can easily access that data by downloading the blockchain, users +can scan it and find it if they have enough keys. Whereas if you store this +data, let's say in Google Drive, well, they might delete it, or maybe your heirs +don't know how to access it, they don't know where it is. And so, that's the +reason why I think that putting it on the blockchain could make sense if you're +willing to spend the money. I think it's also worth saying that the cost of +doing so is finite in terms of the number of vbytes, meaning that if you can +afford to make a multisig transaction or a transaction with a more complex +descriptor, you can almost certainly afford to put that data onchain if you want +to do so. Because, for example, a 2-of-3 descriptor encrypted, if you were to +put it in the witness data, it's only about 100 vbytes. And so, I don't know if +that helps answer your question. + +**Mark Erhardt**: Yeah, thank you. So, I understand the privacy part of someone +finding one of your backups, and let's say it's a seed phrase and it's a file +that's stored next to it, or a written-out descriptor for getting the +construction of your wallet back. So, you lose privacy if any one of your +backups is compromised. But so you're saying, why not just store your +compactly-encoded backup with these files? That would still satisfy it. So, it +isn't necessary for people to put it on the blockchain. They can just store +their seed phrase together with this encrypted descriptor package. + +**Josh Doman**: Yes, I would say that's certainly true. I would say there's two +benefits to putting it on the blockchain if you want to do so. The first is you +can still use decoy setups. So, while it's true if you encrypt it and you store +it next to your seed phrase, they might not be able to see how much money you +have in it, but they'll know that it's part of a more complex setup, which some +users might care about. And second, and I think it's also worth saying that I +think it's important to build for all types of users; people have different +types of wants and needs. And I think that for some people, they would prefer +to minimize their cost and put it right next to their seed phrase and print it +out and figure out how to do that. I think that for other people, like people +of my parent's generation, etc, it's already complex enough to learn how Bitcoin +works. They buy this hardware wallet, they download it, tells them how to put +their seed phrase on, they understand how that works. Cool. I think that if +there was a simple, in their wallet, press a button, pay a little fee, and now +they don't have to really even learn too much about what the descriptor is, I +think that there would be some interest in that solution for some people. It +certainly is something that I want for myself, and that's enough reason for me +to build this. + +**Mark Erhardt**: Maybe one more follow-up. So, if that is a standard function +in wallets, how could just importing the file that is stored next to the seed +phrase not also be a standard function? Downloading the whole blockchain, +scanning all of the inscriptions seems a lot more complex or time-consuming than +being able to import the file through a standard that's implemented by many +wallets. + +**Josh Doman**: That's true. So, in the post, I mentioned that if you do want +to store it on the blockchain, what you should do is attach a 4-byte hash of +each combination of fingerprints that can be used to spend the funds. That way, +you can then have an indexer that can be run by myself or you could build it +yourself, or also, you can use a centralized service. And all you need to do is +connect your devices and press recover. So, that's actually how I built the +original service, the multisigbackup.com that I released a few months ago, is I +have this thing running in the background, it's open-source. I haven't built +that for this version, but if there is demand, I can do that. But that's how I +imagine it would work, users would just connect their devices that they know +they have, press recover, and then they can access their money. + +**Mike Schmidt**: Josh, thanks for coming on and representing your ideas on the +show today. You're welcome to stay on it, but if you have other things to do, +we understand and you're free to drop. + +**Josh Doman**: Thanks, Mike. + +_Separate UTXO set access from validation functions_ + +**Mike Schmidt**: Murch, I'm going to jump to the PR Review Club section because +we have a special guest waiting in the wings. Bitcoin Core PR Review Club, this +month, "Separate UTXO access from validation functions". Sebastian, this is +your PR, which is currently still open on the repository and in the process of +getting review and feedback. And it's part of the bitcoinkernel project. Maybe +for listeners who aren't familiar yet, maybe you can give your elevator pitch +summary of the kernel project, then we can jump into the PR? + +**TheCharlatan**: Sure. The kernel project is the attempt of isolating the +validation rules that are currently contained inside Bitcoin Core and putting +them into a separate library. And then, as the penultimate goal, we would +publish this library as part of a Bitcoin Core release, and other projects would +be able to use this validation library to either reimplement their own full +nodes or access Bitcoin Core data structures easier. + +**Mike Schmidt**: All right, excellent. Okay, so we have the context now of the +kernel project. Why do we want to separate the UTXO set from validation +functions? + +**TheCharlatan**: Yeah, so this is kind of part of a longer effort, and I guess +the first step towards that effort. So, one of the more interesting clients +that one could build on top of a kernel library would be a utreexo client. And +in utreexo, you would ideally not like to maintain a full copy of Bitcoin's +chainstate. But for security reasons, you also probably don't want to +re-implement the entire block validation logic that Bitcoin Core contains. So, +the middle road is what this PR intends to implement, by isolating out the +chainstate from the rest of validation. + +**Mike Schmidt**: So, is this a strictly refactor PR; you're just sort of moving +things behind the scenes and ideally nothing would change for users, but the +library would have additional capabilities for these other clients in the +future, like utreexo? + +**TheCharlatan**: It is not a strict refactor, but it gets kind of close to it. +So, there are some changes to the order of validation operations, and we do +introduce some new assumptions of when data structures are in a certain state. +But overall, the changes are mostly move-only. + +**Mike Schmidt**: How nervous does making those sorts of assumptions and changes +make you with regards to the files you're touching here? + +**TheCharlatan**: That's a tricky question, I guess. But I think the scope of +the change is kind of limited, because it doesn't introduce any new logic. And +when you review it, you can pretty clearly see how the logic gets moved around. +So, I don't think there's much possibility for some foot guns that might be +introduced through this change. + +**Mike Schmidt**: One of the questions in the PR Review Club session has to do +with, there was a question for the audience and participants in the Review Club +about where you might have concerns about performance. Are there performance +implications in this PR, positive or negative? + +**TheCharlatan**: Yeah, so what the change does, it preloads all the coins that +are being spent in a block at the beginning of validation, and then uses this +preload directly for the rest of its validation operations. And what the code +did so far is it would cache these coins into a map and then do a map lookup for +the coins for every operation. So, then there is a small speed-up there, +because we don't do this map lookup every time, but it is kind of insignificant. + +**Mike Schmidt**: How would you summarize, I was just trying to pull up the +tracking issue for the kernel project, because I like to give that to folks +because I like to follow along. But how would you verbally summarize progress +on kernel and where we're at and what the next big pieces are? + +**TheCharlatan**: Yeah, so I think the project is currently at a point where +most of the changes for isolating out parts that we really don't want in the +kernel are kind of done. And we're now more in a phase where we're doing +changes to bring features through a potential future kernel API to potential +future users. So, we're more trying to figure out what the use cases are and +how we can make the library useful for people. + +**Mike Schmidt**: What is or is not in kernel? Because I think I saw people +arguing about if there were mempool things; it sounds like we're abstracting +away UTXO set in this scenario; what's in or not in that people might not be +familiar with? + +**TheCharlatan**: Yeah, so there's two sides to that question. One is what is +actually being compiled code-wise into the kernel library, and that is currently +all the block validation logic and the mempool. So, all the policy logic is in +there too. Then, I also have a proposed API for the library, and that so far +only includes script and block validation features, as well as functions to read +data from the various data structures that we have in Bitcoin Core. + +**Mike Schmidt**: Do you see, is mempool going to be in there in the final +state, do you think? Would that be like a separate component? Or how do you +think about that? + +**TheCharlatan**: It's an open debate at the moment, but I would like the +mempool to be split out of it. I think if we want to realize the full potential +of what this library has to offer to alternative implementations, we should +probably not make them build on how we exactly implement policy and mempool +rules in Bitcoin Core. At the same time, it's kind of weighing off of allowing +full flexibility, but also realizing that the way we've implemented the mempool +in Bitcoin Core is pretty solid, and re-implementing all of that logic might +also be challenging for alternative clients, like utreexo. + +**Mike Schmidt**: I see. And so, that was going to be my question, what's the +argument to keep it if you're saying like, "Yeah, we can really pare it down and +people can build their own structures on top". I guess the counter to that is, +"Mempool is secure and strong and we don't want to reimplement it". Is that the +argument against? + +**TheCharlatan**: Yeah, basically. But I mean, for example, in the Knots case, +where they do want to implement all these extra policy rules, and probably have +some kind of stable interface that they can use to implement these rules against +that doesn't change all the time, so they don't have to rebase all the time and +maybe do a mistake on one of those rebases. So, that might be an argument for +at least making the policy rules a bit more pluggable. + +**Mike Schmidt**: Murch, do you have any questions for Sebastian? + +**Mark Erhardt**: Actually one, yes. I've seen multiple mentions lately again +in the context of the kernel project, that the Electrum server ecosystem is +quite muddled. There are three different implementations that have all taken +multiple approaches to implement the Electrum protocol with different features. +How easy would it be to build an Electrum replacement on kernel? + +**TheCharlatan**: Yeah, that's basically the reason for the other bigger PR I +have open at the moment against Bitcoin Core, which would allow, for example, an +Electrum indexer to read Bitcoin Core's block data through the kernel library +while Bitcoin Core is running and doing validation tasks simultaneously. So, +I'm not fully convinced yet if re-architecturing some of our internal storage to +allow these kind of parallel tasks on our data is the right approach here, but +it is definitely interesting. I think it could bring pretty significant +performance boosts to these external indexes. + +**Mike Schmidt**: Murch, for reference, we had on Eric Voskuil to talk about +libbitcoin and some of the parallelization versus Bitcoin Core's current UTXO +model of ordering, that we just published that podcast this morning. And +Sebastian, I think, was also on the line listening to at least some of that. + +**Mark Erhardt**: Oh, I was wondering who that was. You mean Brink? + +**Mike Schmidt**: Yeah, yeah, sorry Brink. Yeah, so if listeners are curious +about that side conversation, you can find that on brink.dev or our YouTube +channel. Charlatan, really appreciate your work on this project and always try +to get discussions going about that wherever possible on the show. How would +you leave the audience with any sort of call to action or something to chew on +with regards to kernel? + +**TheCharlatan**: Yeah, so I have the kernel API PR open, which surfaces a C API +for the kernel library. And it now has wrappers in four different languages, so +in C++, in Rust, in Python, and in Go. And, yeah, it would be cool if people +could try that out, see what they can build with it, if they can build their own +full nodes with it, just experiment with it a bit. It's definitely fun to do. +So, I've also implemented my own Rust full node with the kernel library. + +**Mike Schmidt**: And I think the natural inclination is to go to implementing a +full node, which is obviously very cool, but somewhat intensive. But I know +folks like, I think, Abubakar have used the kernel to do fee estimation or fee +analysis that was a lot quicker than sort of parsing the blocks straightaway. +So, there's a lot of other things that you can do, other than trying to roll +your own node. + +**TheCharlatan**: Yeah, building out data analysis tools is pretty fun too. The +cool thing is, with the way the API is laid out, parsing it to a thread pool or +some thread pool worker framework that just massively parallelizes reading from +disk, or similar I/O tasks, makes reading data from the blockchain really fast. +So, if you just plug that at the start of your analytics pipeline, that could +really speed up things for you. + +_Updating BIP390 to allow duplicate participant keys in `musig()` expressions_ + +**Mike Schmidt**: Next news item is titled, "Updating BIP390 to allow duplicate +participant keys in musig() expressions". Murch? + +**Mark Erhardt**: Right. So, Ava Chow, who's been working on implementing MuSig +and PSBT in Bitcoin Core, has written a bunch of the corresponding BIPs. BIP390 +is the BIP that specifies how to create output descriptors for MuSig2 outputs, +or MuSig2-based outputs. And one of the things that were in BIP390 was that it +was forbidden to reuse the same participant public key more than once in MuSig2 +output script descriptors. Then, when she got to actually implementing that, +she found that it was quite complicated to implement, and now is wondering, is +there actually a problem that is being solved by not allowing repetition of the +same public key? And so, there's a mailing-list post and this PR where this is +being discussed. And so, far it seems that MuSig2 explicitly allows reuse of +keys. + +One concern was reuse keys in the context of deterministic nonces, but MuSig2 +generally advises against deterministic nonces in this context anyway. And +then, yeah, so far it sounds to me like nobody has found a major issue with +repeating keys. The PRs and mailing list discussions are still open in order if +you, listener, have some concerns or thoughts on this topic, please chime in. +Otherwise, BIP390 will be probably updated to allow implementation of output +script descriptors with repeated participant public keys. And, yeah, so it's +still unclear to me and Ava stated as much why anyone ever would want to do this +with duplicate keys. But if there is no problem with it, BIP390 will be amended +to allow it. + +**Mike Schmidt**: Thanks, Murch. It sounds like Peter might join us. But as +the show must go on, we can jump to the Releases and release candidates for the +time being. + +_Core Lightning 25.05rc1_ + +Core Lightning 25.05rc1. We've had this on for a few weeks. It was best done +by Dave and Alex in Podcast #355 where they went through that release. + +_LND 0.19.1-beta_ + +LND 0.19.1-beta. We covered this minor LND release last week, in #357, when it +was in its RC form, and we went through a bunch of the bugs and fixes in there. +So, refer back to Podcast #357 on that. And that wraps up the Releases and +release candidates section. And we can actually jump back to the news section +because who do we have on the line? You want to introduce yourself? + +**Peter Todd**: Yeah, let's see. Can you hear me? + +**Mike Schmidt**: Yeah, I can hear you. + +**Peter Todd**: But yeah, I'm Peter Todd, known for talking about Bitcoin a lot, +very occasionally actually doing real work. + +_Relay censorship resistance through top mempool set reconciliation_ + +**Mike Schmidt**: Thanks for joining us, Peter. We stalled just enough for you +to be able to join us for the, "Relay censorship resistance through top mempool +set reconciliation". Peter, you posted to the Bitcoin-Dev mailing list a post +titled, "Censorship Resistant Transaction Relay - Taking out the garbage(man)". +I think it might be good for you to explain what's been going on with your Libre +Relay nodes and these garbageman nodes, so that listeners can understand the +context for what you get into in this post. People may have heard of Libre +Relay, probably haven't heard of garbageman. I'm not sure, maybe you can just +set the battlefield for us before we get into strategy. + +**Peter Todd**: Yeah, so Libre Relay uses a strategy I've used for many years +now, which is basically if you have relay rules that allow transactions that +other people don't, the way that you make your rules actually achieve anything +is by finding other peers with the same rules as you do, the same more Libre +rules as you do, and peering with them. Now the case of Libra Relay, frankly +Libra Relay is mostly a project to make a point that Bitcoin Core can't get away +with trying to go and tighten relay rules to stop transactions people actually +want mined. And notably, of course, one thing it does do is it relays OP_RETURN +transactions that were above what was previously in Bitcoin Core's limit. And +then, it also allows transactions that use the annex in a standard way. + +But anyway, the point is garbageman, that is a project that doesn't like this +more Libre relaying rules. And what they want, what they've been trying to do +is a sybil attack against Libre Relay by pretending to be a Libre Relay node, +but not actually relaying the transactions that Libre Relay would. When I say +pretending, the trick that Libre Relay uses, as well as my previous full-RBF +peering nodes, was we just advertise the service bit. And then, we connect to +other nodes also advertising the service bit. I forgot off the top of my head +what the number is. It's like number 30 or something, but you know. + +**Mark Erhardt**: 23, I think. + +**Peter Todd**: Yeah, 29, 23, whatever it is. But as you point out, that chunk +of service bits was something I basically got allocated, if you will, for +"non-standard uses" and experimental uses many, many years ago. But of course, +when I say allocated, the problem with service bits is you can go on, you know, +there is no way to verify directly that a bit actually means that someone's +going to relay your transactions, and that's why garbage man is potentially +effective. And in my post, I did go talk a little bit about you know how many +nodes that have to run for a certain amount of success, and so on. But to get +to our point here, the proposal for what I posted on the Bitcoin-Dev mailing +list is to basically use the same mechanism we use right now to prevent sybil +attacks against block relaying, namely you figure out if a peer is relaying +something better than what you have right now, and if so, you switch. And then +periodically, you drop the worst peer. Now with blocks, you can do that with +chain height; with fees, it's a little more complex, but basically you can do +this with total fees. How many total fees is your peer advertising that would +get into, say, the next one or two blocks? And if one peer is less than others, +well, drop that peer. And then periodically, just try a new peer at random and +see if they're doing better. + +As long as you do this consistently, eventually you're gonna find a peer that +isn't blocking the transactions you want to see and you'll get, over time, more +and more peers that have the same relay policy as you, thus defeating this kind +of attempt at blocking transactions. + +**Mark Erhardt**: Okay, I have a couple of questions, (a) I was wrong, it's bit +29; (b) the one question I had is, how do you manage to get comparable results +from all of your peers? Do you send the request for their top two blocks at the +same time, or how are the results comparable? Because otherwise, a node that +had more time to collect transactions since the last block might have just more +good transactions. So, the later you are asked for it, the better you would +look in this comparison. + +**Peter Todd**: Yeah, I mean I think these are all questions that will get +answered when someone actually tries to implement this for real. I'd say the +biggest challenge to doing this is currently without cluster mempool, it's hard +to just quickly compute what would be, say, the next block or two worth of +transactions. And once cluster mempool is implemented and in Bitcoin Core, then +it becomes easier to make that calculation. And I think you're absolutely +right. If I have a node that had recently turned on and was missing a lot of +transactions, it may very well be the case that peers implementing this method +would tend to go drop it until it got more transactions, which I think is okay. +From their point of view, this is indeed a peer that is not very useful yet, and +it may take time for it to get enough transactions to be useful. + +**Mark Erhardt**: Right, that was going to be my follow-up question. How do you +rejoin the network if all of the peers were running this protocol? If you spin +up a new node, you'll always be the least useful and you'd have no way to get +new transactions because you don't have peers, so you wouldn't get better. +Wouldn't that potentially make it impossible for people to bootstrap new peers? + +**Peter Todd**: Well, this question actually gets down to a subtlety of what we +mean by useful. You see, there is actually two different types of relay we're +talking about here. One is sending transactions to peers, and getting +transactions from peers. And to do this properly in a way that actually defeats +censorship, you actually need to only consider the transactions a node sends to +you, not the other way around. A good example is, in fact, garbageman's already +implemented this, if I give you a transaction and then you give it me back, that +is not an example of you doing effective relaying, or at least it's not proof +that you are. Proof that you're doing effective relaying is if you give me a +transaction that I did not give you in the first place. And it's likely that a +way to make this work, in reality, is to think more of relaying as actually a +unidirectional thing; I send out to nodes and then I receive stuff from nodes, +and you would only use this technique on the receiving side. + +I want to make an important point here, which is I don't see this being as a +replacement for all transaction relaying. I see this as being a backup +mechanism to ensure that even transactions that may be censored still do get +relayed. So, one way to implement this might be to have a separate set of relay +peers, where we only use this mechanism and we do not in fact use a more +standard INV mechanism. But these are all questions that need to be explored +more. The purpose of my mailing list post was not to say, "Hey, here's the +solution". Here is a class of solutions that look promising and obviously more +research is needed. + +**Mark Erhardt**: Right, that makes sense. + +**Mike Schmidt**: You mentioned cluster mempool as a piece of interesting +technology that we talk about in the show pretty regularly. I don't think I saw +in your post, but it is in our summary, but I do think you made reference to the +broad category, set reconciliation. We mentioned Erlay and minisketch. Is this +something that you're actively working on or just soliciting ideas from +implementing some of this stuff? + +**Peter Todd**: Well, so something I want to make clear here in case I haven't +already is, this mailing list post, none of the ideas in it are really mine. +Mostly that comes from a discussion I had with Greg Maxwell about set +reconciliation and how it could be used for this purpose. So, I personally am +not working on this, although depending on how things go, I might in fact be the +person who does more work on this precisely and implement this. We'll see what +happens. My understanding is currently a lot of the harder code for set +reconciliation has already been written. What's left is integration of existing +code into the actual logic to do this for the mempool for real. But I haven't +personally looked at this in detail, so I can't authoritatively say anything on +that. + +**Mark Erhardt**: I actually have looked a little more at this. So, what is +being referenced here is the Erlay idea. Erlay is a protocol for reconciling +what you will be announcing to your peers, what new transactions. So, instead +of always immediately announcing new transactions as they become available in +your inventory, you would occasionally just compare notes with other peers about +what you will be telling each other about, and then much more efficiently but at +a larger cadence, get these announcements settled with all of your peers. The +idea is that this would allow you to have much more peers for less overall +bandwidth use. And the trade-off with that is you do want still some peers that +just do regular announcements, because otherwise it would slow down how quickly +you learn about new transactions. + +So, this reconciliation mechanism uses something called minisketch where it uses +Moon Math to compare and calculate all of the pieces of data that would be +announced to each other. And I think what Peter is proposing, it could instead +of comparing the announcements with each other, be used to compare the txids of +the transactions in the top two blocks. + +**Peter Todd**: Yeah. And I should say, again, this may be something that you +do in parallel to other efforts to use Erlay, this isn't necessarily an +either/or. But I think that the key thing to say there is, why you would want +to do this mechanism is just so that you could efficiently say, "Hey, this guy +claims that he can provide me with this much fees, yet he has not done so, thus +I will go ban him for lying". + +**Mike Schmidt**: Peter, have you thought about, it seems like there's been some +back and forth between these two implementations trying to trick each other, +etc, and you're proposing potentially this way. Is there a counter to this +approach that the garbageman folks might be able to get around something like +this? + +**Peter Todd**: Well, so I'd point out, I mean this hasn't really been a +back-and-forth situation at all. In fact, if anything, I have not taken really +obvious steps that could make garbageman less effective, because I'd rather see +it get to the point where it actually did have some effects. That would be +useful to understand how that actually plays on reality, because at the moment, +there just don't seem to be enough garbageman nodes of any impact at all; they +would have to run far more than are currently running. One example being how +this might happen is, for instance, if Bitcoin Knots added this by default, and +my understanding is Luke Dashjr isn't very interested in doing that, because +there's obvious legal issues around this too. But let's say hypothetically they +did. Well, then as far as I know, assuming this type of relay became was +possible to implement in the way that I think it is, I don't know of any counter +to it. Now, certainly, garbageman spinning up a bunch of nodes might make it +take longer for a new node to actually be effective at relaying, but given time, +because effectively the entire network is eventually searched for peers, +assuming that people actually need these transactions to happen and thus there +is that signal, that costly signal, relaying will work. + +So, yeah, I mean it seems to be a very effective approach, but as always, it has +to actually be implemented and better understood to know whether or not that's +true. + +**Mark Erhardt**: Yeah, I think that if you actually only did this with a subset +of your nodes every block, once or so, and you did it roughly at the same time +with all of the peers that were selected for this reconciliation step, you would +sort of get a signal which, let's say you do it with 20 out of your 125 peers +once every 10 minutes, you'd be able to get rid of one of your 125 peers per +block. So, you'd cycle through 150-ish peers per day. And eventually, that +would lead to you having more peers that have a good mempool. And we also have +to note that most of the transactions included in the next block were only +broadcast in the last ten minutes. So, actually, even if you're only online for +a few hours, you tend to have a very decent mempool. And maybe the concern +about new nodes joining is not that dire, because there's enough nodes that +they'll cycle through them for many hours, so they should have a good mempool at +some point. + +**Peter Todd**: Yeah, the calculation I did on the mailing list, if I remember +correctly, was basically assuming you do this process, say, every three minutes. +Dropping one not-so-useful peer every three minutes basically means that with +current numbers, you would end up having your best peers in, I think, something +like two days, which isn't great, but it's not terrible either. So, I think +that's a pretty good improvement on the potential status quo of garbageman +actually working. + +**Mike Schmidt**: Peter, thanks for hopping on and joining us. Oh, do you have +one more thing to say? + +**Peter Todd**: Yeah, I'll just point out one last thing, which is, despite all +this discussion we had, something to point out is that garbageman is only really +effective by itself for nodes that only make outgoing connections. Because +nodes that accept incoming connections, one brute-force way to defeat it is to +just spin up nodes that have an enormous number of outgoing connections. So, +whether or not anyone actually bothers to go and do this remains to be seen. +But anyway, thanks for having me on. + +**Mike Schmidt**: Yeah, thanks again Peter. Cheers. + +**Peter Todd**: All right, bye. + +_LDK #3793_ + +**Mike Schmidt**: Jumping back to the Notable code segment, which we started +earlier, we went through Bitcoin Core #32406 on the OP_RETURN limit size +earlier. So, we'll jump next to LDK #3793, which implements a new message +batching approach using start_batch messages. Previously, LDK used a custom +batching approach. However, the LN splicing specification has recently been +updated to use these start_batch messages, which treat a series of messages +together as one logical message. I'm hoping at some point we'll get a splicing +or an LN person on to dig into that a little bit more, but that was my takeaway. + +_LDK #3792_ + +LDK #3792 introduces initial support for v3 commitment transactions. Murch? + +**Mark Erhardt**: Yeah, I heard the trigger word here. So, we've been talking a +ton about TRUC (Topologically Restricted Until Confirmation) transactions, which +use v3 to signal that they would like to opt into the topology restrictions +until confirmed. And we've also, I think, mentioned ephemeral anchors. So, +this PR in LDK hides behind a test flag, a by-default-off new option to start +creating commitment transactions that have a fee of zero by using TRUC +transactions and ephemeral anchors. And the idea here is, so we've, in the past +years, had a lot of LN channels close, especially when the feerates spiked, +because when two LN nodes disagree on what the new fee for a commitment +transaction should be, the outcome can be that they disagree and close the +channel instead, because the side that was paying the fees doesn't want to +increase and the other side demands higher fees. + +One other solution in this context was that whoever wants to pay more fees can +pay the fees but the other party will not pay the fees. And the TRUC +transaction approach is the more elegant one, which means you can make +commitment transactions, which is the transaction that is used to make a +unilateral close at zero fees. And then, when you actually close a channel +using the commitment transaction, you bring the fees with the child transaction +that is attached via the ephemeral anchor. So, from looking at this PR a little +bit, my understanding is it is now available in LDK, or rather in the next +release of LDK, and it is not on by default. If you do turn it on, your node +will attempt to ask your peer whether the channel that you're trying to create +would work as a zero-fee commitment transaction if the peer also supports this. +And then, the two will together create this TRUC and ephemeral-anchor-based +commitment transaction. + +One downside of these channels is that the HTLC (Hash Time Locked Contract) +limit will be reduced, because TRUC transactions are limited to 10,000 vbytes, +the parent, and 1,000, the child. But we're talking about the commitment +transaction, which is the parent transaction in this pair of transactions, and +with the 10,000-vbyte limit, you can fit fewer HTLCs, so they're limiting the +HTLC to 114 instead of 483. And, yeah, so pretty cool to see this out in the +wild. I hope by the end of the year that we will have this more broadly adopted +across the LN implementations, and that hopefully will significantly reduce the +difficulty of running your own LN Node. + +**Mike Schmidt**: I know BlueMatt, who is on the LDK team, is super excited +about these zero-fee commitment transactions. So, obviously, it seems like +they're one of the ones leading the way here. So, thanks for summarizing that, +Murch. + +_LND #9127_ + +LND #9127 adds an option to LND's addinvoice command when using blinded paths, +for the user to be able to include which channels they prefer to receive the +payment on. So, the option allows multiple channels and can be extended to +multiple hops leading to the node. And there was an issue that was motivating +this change that noted that it actually allows the user, the LND user, to +specify paying over a specific channel, which gives that LND user an extra +liquidity control lever. So, you can sort of quasi route things by specifying +these channels. + +**Mark Erhardt**: Just seeing this summary, I wonder whether there's a privacy +issue here. If you provide a single blinded path, you're just advocating or +you're revealing that you're in the vicinity of the entry node. But if you +provide multiple different entry nodes, you're revealing that you're in the +intersection of the vicinities of these entry nodes. So, I'm wondering whether +you you're sort of giving information to triangulate. + +**Mike Schmidt**: Yeah, that's a good point. You may be having more liquidity +benefits, but privacy hits. And I didn't see that in the notes, but I also +wasn't looking for it, but that's a good point, Murch. + +_LND #9858_ + +LND #9858. This was actually part of the 0.19.1-beta release that we discussed +last week, which is actually now out. After this change, LND will correctly +signal support on the P2P network for RBF cooperative close feature, including +the appropriate production feature bit, which in this case is 61 for RBF +cooperative closing support. So, I think previously it was either in the +non-productive state or they just hadn't turned on signalling for the feature. + +**Mark Erhardt**: It sounds to me that they were only using it as a testing +feature before, and now it's a production feature, which would indicate that +it's more mature. I also note that it has an odd bit, which means that it is +not mandatory because it's okay to be odd. And so, mandatory features that you +will require your peer to have if you have them are the even numbers, and the +odd numbers are bits that are optional that you can have and it's fine if your +peer doesn't. + +**Mike Schmidt**: And the production are under 100, and the staging versions is +the same number with '1' in front of it. Is that right? So, for example, the +production for the RBF closing support is 61, but the staging bit, I think, is +161. + +**Mark Erhardt**: That sounds reasonable. Also, I was only guessing at the +prior thing. And so, if someone disagrees, please let us know! + +_BOLTs #1243_ + +**Mike Schmidt**: Last PR this week to the BOLTs repository, #1243, which makes +a change to the BOLT11 invoice protocol specification. It actually clarifies +that a mandatory field that is present, but has an incorrect length, that +invoice should actually be failed instead of skipping that field. Previously, +it was ambiguous about how that should be handled. So, this PR corrects that +ambiguity that was present in the spec previously. Murch, I don't recall, but +it feels like we covered perhaps LND or LDK, who ran into an issue with this, in +a previous podcast discussion. I couldn't immediately bring it in for reference +for the listeners, but I think we did talk about something like this. And the +issue here was actually surfaced via some differential fuzz testing between +different implementations. And so, we applaud that fuzz testing work from Bruno +who surfaced that originally. Anything else, Murch? + +**Mark Erhardt**: I think we got everything. + +**Mike Schmidt**: All right. + +**Mark Erhardt**: It was a lot of jumping around today! + +**Mike Schmidt**: It'll be fun editing for the timestamps, and all of that. All +right, well, thank you to TheCharlatan, to Josh, Peter Todd, Antoine for joining +us this week, and thank you, Murch, for co-hosting. + +**Mark Erhardt**: We'll hear you next time. Cheers. {% include references.md %} From 4467f29ab138bc45292477d3377a0a009a697fbf Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Tue, 1 Jul 2025 00:08:47 +0200 Subject: [PATCH 134/278] Newsletter 360 de (#2398) * Translate Newsletter #360 to German * Translate Newsletter #360 to German * fix link * Update _posts/de/newsletters/2025-06-27-newsletter.md Co-authored-by: garfiel-d * Update _posts/de/newsletters/2025-06-27-newsletter.md Co-authored-by: garfiel-d * Update _posts/de/newsletters/2025-06-27-newsletter.md Co-authored-by: garfiel-d * Update _posts/de/newsletters/2025-06-27-newsletter.md Co-authored-by: garfiel-d * Update _posts/de/newsletters/2025-06-27-newsletter.md Co-authored-by: garfiel-d * Update _posts/de/newsletters/2025-06-27-newsletter.md Co-authored-by: Mark "Murch" Erhardt --------- Co-authored-by: garfiel-d Co-authored-by: Mark "Murch" Erhardt --- .../de/newsletters/2025-06-27-newsletter.md | 160 ++++++++++++++++++ 1 file changed, 160 insertions(+) create mode 100644 _posts/de/newsletters/2025-06-27-newsletter.md diff --git a/_posts/de/newsletters/2025-06-27-newsletter.md b/_posts/de/newsletters/2025-06-27-newsletter.md new file mode 100644 index 0000000000..0a99785731 --- /dev/null +++ b/_posts/de/newsletters/2025-06-27-newsletter.md @@ -0,0 +1,160 @@ +--- +title: 'Bitcoin Optech Newsletter #360' +permalink: /de/newsletters/2025/06/27/ +name: 2025-06-27-newsletter-de +slug: 2025-06-27-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche fasst Forschungen zur Identifizierung von Full Nodes mittels +P2P-Protokoll-Nachrichten zusammen und bittet um Feedback zur möglichen Entfernung der +Unterstützung für `H` in BIP32-Pfaden in der BIP380-Spezifikation von Deskriptoren. +Ebenfalls enthalten sind unsere regulären Abschnitte mit Zusammenfassungen der wichtigsten +Fragen und Antworten auf der Bitcoin Stack Exchange, Ankündigungen neuer Releases und +Release-Kandidaten sowie Beschreibungen bemerkenswerter Änderungen an populärer +Bitcoin-Infrastruktursoftware. + +## Nachrichten + +- **Identifizierung von Knoten mittels `addr`-Nachrichten:** + Daniela Brozzoni [postete][brozzoni addr] auf Delving Bitcoin über Forschungen, die sie + zusammen mit der Entwicklerin Naiyoma durchführte, um denselben Knoten in mehreren Netzwerken + anhand der von ihm gesendeten `addr`-Nachrichten zu identifizieren. Knoten senden + P2P-Protokoll-`addr`-(Adress-)Nachrichten an ihre Peers, um andere potenzielle Knoten + zu bewerben und es Peers zu ermöglichen, sich über ein dezentrales Gossip-System zu + finden. Brozzoni und Naiyoma konnten jedoch einzelne Knoten anhand von Details aus + ihren spezifischen Adressnachrichten eindeutig identifizieren, was es ihnen ermöglichte, + denselben Knoten zu erkennen, der in mehreren Netzwerken läuft (wie IPv4 und + [Tor][topic anonymity networks]). + + Die Forscher schlagen zwei mögliche Gegenmaßnahmen vor: das Entfernen von Zeitstempeln + aus Adressnachrichten oder, falls die Zeitstempel beibehalten werden, diese leicht zu + randomisieren, um sie weniger spezifisch für bestimmte Knoten zu machen. + +- **Verwendet irgendeine Software `H` in Deskriptoren?** + Ava Chow [postete][chow hard] in der Bitcoin-Dev-Mailingliste die Frage, ob irgendeine + Software Deskriptoren mit Großbuchstaben-H generiert, um einen gehärteten + [BIP32][topic bip32]-Schlüssel-Ableitungsschritt anzuzeigen. Falls nicht, könnte die + [BIP380][]-Spezifikation von [Output Script Deskriptoren][topic descriptors] so + modifiziert werden, dass nur Kleinbuchstaben-h und `'` zur Anzeige der Härtung + verwendet werden dürfen. Chow bemerkt, dass, obwohl BIP32 Großbuchstaben-H erlaubt, + die BIP380-Spezifikation zuvor einen Test enthielt, der die Verwendung von + Großbuchstaben-H verbietet, und Bitcoin Core derzeit Großbuchstaben-H nicht akzeptiert. + +## Ausgewählte Fragen & Antworten von Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] ist einer der ersten Orte, an denen die +Optech-Mitwirkenden nach Antworten auf ihre Fragen suchen – oder, wenn wir etwas Zeit +haben, um neugierige oder verwirrte Nutzer zu unterstützen. In diesem monatlichen +Abschnitt heben wir einige der bestbewerteten Fragen und Antworten hervor, die seit +unserem letzten Update gepostet wurden.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Gibt es eine Möglichkeit, Bitcoin Knots-Knoten als meine Peers zu blockieren?]({{bse}}127456) + Vojtěch Strnad bietet einen Ansatz zum Blockieren von Peers basierend auf + User-Agent-Strings mit zwei Bitcoin Core RPCs, rät jedoch von einem solchen Ansatz ab + und verweist auf ein verwandtes [Bitcoin Core GitHub Issue][Bitcoin Core #30036] mit + ähnlicher Abratung. + +- [Was macht OP_CAT mit Ganzzahlen?]({{bse}}127436) + Pieter Wuille erklärt, dass Bitcoin Script Stack-Elemente keine Datentypinformationen + enthalten und verschiedene Opcodes die Bytes des Stack-Elements auf unterschiedliche + Weise interpretieren. + +- [Asynchrones Block-Relay mit Compact Block Relay (BIP152)]({{bse}}127420) + Benutzer bca-0353f40e skizziert Bitcoin Cores Behandlung von [Compact Blocks][topic + compact block relay] und schätzt die Auswirkungen fehlender Transaktionen auf die + Blockpropagation. + +- [Warum sind Angreifer-Einnahmen beim Selfish Mining disproportional zu ihrer Hash-Power?]({{bse}}53030) + Antoine Poinsot geht weiter auf diese und [eine andere]({{bse}}125682) ältere [Selfish + Mining][topic selfish mining]-Frage ein und weist darauf hin: „Die Schwierigkeitsanpassung + berücksichtigt verwaiste Blöcke nicht, was bedeutet, dass die Verringerung der + effektiven Hashrate konkurrierender Miner die Gewinne eines Miners (über einen + ausreichend langen Zeitraum) genauso stark erhöht wie die Erhöhung seiner eigenen“ + (siehe [Newsletter #358][news358 selfish mining]). + +## Releases und Release-Kandidaten + +*Neue Releases und Release-Kandidaten für populäre Bitcoin-Infrastrukturprojekte. +Bitte erwägen Sie, auf neue Releases zu aktualisieren oder beim Testen von +Release-Kandidaten zu helfen.* + +- [Bitcoin Core 28.2][] ist ein Wartungs-Release für die vorherige Release-Serie der + vorherrschenden Full-Node-Implementierung. Es enthält mehrere Fehlerbehebungen. + +## Wichtige Code- und Dokumentationsänderungen + +*Bemerkenswerte aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], +[libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], +[Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], +[Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und +[BINANAs][binana repo].* + +- [Bitcoin Core #31981][] fügt eine `checkBlock`-Methode zur Inter-Process-Communication + (IPC) `Mining`-Schnittstelle hinzu (siehe Newsletter [#310][news310 ipc]), die + dieselben Gültigkeitsprüfungen wie der `getblocktemplate`-RPC im `proposal`-Modus + durchführt. Dies ermöglicht es Mining-Pools, die [Stratum v2][topic pooled mining] + verwenden, Block-Templates von Minern über die schnellere IPC-Schnittstelle zu + validieren, anstatt bis zu 4 MB JSON über RPC zu serialisieren. Die Proof-of-Work- + und Merkle-Root-Prüfungen können in den Optionen deaktiviert werden. + +- [Eclair #3109][] erweitert seine Unterstützung für [attributable failures][topic + attributable failures] (siehe Newsletter [#356][news356 failures]) auf [Trampoline + Payments][topic trampoline payments]. Ein Trampoline-Knoten entschlüsselt und + speichert nun den für ihn bestimmten Teil der Attributions-Payload und bereitet den + verbleibenden Blob für den nächsten Trampoline-Hop vor. Dieser PR implementiert nicht + die Weiterleitung der Attributionsdaten für Trampoline-Knoten, was in einem + Follow-up-PR erwartet wird. + +- [LND #9950][] fügt ein neues `include_auth_proof`-Flag zu den `DescribeGraph`-, + `GetNodeInfo`- und `GetChanInfo`-RPCs und zu ihren entsprechenden `lncli`-Befehlen + hinzu. Die Einbeziehung dieses Flags gibt die [Channel-Announcement][topic channel + announcements]-Signaturen zurück, was die Validierung von Channel-Details durch + Drittanbieter-Software ermöglicht. + +- [LDK #3868][] reduziert die Präzision der [HTLC][topic htlc]-Haltezeit für + [attributable failure][topic attributable failures]-Payloads (siehe Newsletter + [#349][news349 attributable]) von 1-Millisekunden- auf 100-Millisekunden-Einheiten, + um Timing-Fingerprint-Lecks zu mindern. Dies bringt LDK mit den neuesten Updates zum + [BOLTs #1044][]-Entwurf in Einklang. + +- [LDK #3873][] erhöht die Verzögerung für das Vergessen eines Short Channel Identifiers + (SCID), nachdem sein Finanzierungs-Output ausgegeben wurde, von 12 auf 144 Blöcke, um + die Verbreitung eines [Splicing][topic splicing]-Updates zu ermöglichen. Dies ist das + Doppelte der 72-Block-Verzögerung, die in [BOLTs #1270][] eingeführt und von Eclair + implementiert wurde (siehe Newsletter [#359][news359 eclair]). Dieser PR implementiert + auch zusätzliche Änderungen am `splice_locked`-Nachrichtenaustauschprozess. + +- [Libsecp256k1 #1678][] fügt eine `secp256k1_objs` CMake-Interface-Bibliothek hinzu, + die alle Objektdateien der Bibliothek bereitstellt, um es übergeordneten Projekten wie + Bitcoin Cores geplantem [libbitcoinkernel][libbitcoinkernel project] zu ermöglichen, + diese Objekte direkt in ihre eigenen statischen Bibliotheken zu verlinken. Dies löst + das Problem, dass CMake keinen nativen Mechanismus zum Verlinken statischer + Bibliotheken in eine andere hat, und erspart nachgelagerten Nutzern die Bereitstellung + ihrer eigenen `libsecp256k1`-Binärdatei. + +- [BIPs #1803][] klärt die [BIP380][]-[Deskriptor][topic descriptors]-Grammatik, indem + alle gängigen gehärteten Pfad-Markierungen erlaubt werden, während [#1871][bips #1871], + [#1867][bips #1867] und [#1866][bips #1866] [BIP390][]s [MuSig2][topic + musig]-Deskriptoren verfeinern, indem Schlüsselpfad-Regeln verschärft, wiederholte + Teilnehmerschlüssel erlaubt und Multipath-Kind-Ableitungen explizit eingeschränkt + werden. + +{% include snippets/recap-ad.md when="2025-07-01 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31981,3109,9950,3868,3873,1678,1803,1871,1867,1866,30036,1044,1270" %} +[bitcoin core 28.2]: https://bitcoincore.org/bin/bitcoin-core-28.2/ +[brozzoni addr]: https://delvingbitcoin.org/t/fingerprinting-nodes-via-addr-requests/1786/ +[chow hard]: https://mailing-list.bitcoindevs.xyz/bitcoindev/848d3d4b-94a5-4e7c-b178-62cf5015b65f@achow101.com/T/#u +[news358 selfish mining]: /de/newsletters/2025/06/13/#berechnung-des-schwellenwerts-fur-selfish-mining +[news310 ipc]: /en/newsletters/2024/07/05/#bitcoin-core-30200 +[news356 failures]: /de/newsletters/2025/05/30/#eclair-3065 +[news349 attributable]: /de/newsletters/2025/04/11/#ldk-2256 +[news359 eclair]: /de/newsletters/2025/06/20/#eclair-3110 +[libbitcoinkernel project]: https://github.com/bitcoin/bitcoin/issues/27587 From 666a5bfd177ca35e23d42008e834b86f69363de9 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Tue, 1 Jul 2025 13:38:40 -0500 Subject: [PATCH 135/278] Podcast: add 360 recap --- .../en/newsletters/2025-06-27-newsletter.md | 28 +++++++++---------- .../en/podcast/2025-07-01-newsletter-recap.md | 24 ++++++++++++++++ 2 files changed, 38 insertions(+), 14 deletions(-) create mode 100644 _posts/en/podcast/2025-07-01-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-06-27-newsletter.md b/_posts/en/newsletters/2025-06-27-newsletter.md index 86be009856..163d420d51 100644 --- a/_posts/en/newsletters/2025-06-27-newsletter.md +++ b/_posts/en/newsletters/2025-06-27-newsletter.md @@ -30,7 +30,7 @@ popular Bitcoin infrastructure software. The researchers suggest two possible mitigations: removing timestamps from address messages or, if the timestamps are kept, randomizing them - slightly to make them less specific to particular nodes. + slightly to make them less specific to particular nodes. {% assign timestamp="1:00" %} - **Does any software use `H` in descriptors?** Ava Chow [posted][chow hard] to the Bitcoin-Dev mailing list to ask whether any software generates @@ -40,7 +40,7 @@ popular Bitcoin infrastructure software. allow lowercase-h and `'` to be used to indicate hardening. Chow notes that, although BIP32 allows uppercase-H, the BIP380 specification previously included a test that forbids using uppercase-H - and that Bitcoin Core currently does not accept uppercase-H. + and that Bitcoin Core currently does not accept uppercase-H. {% assign timestamp="29:36" %} ## Selected Q&A from Bitcoin Stack Exchange @@ -56,17 +56,17 @@ answers posted since our last update.* - [Is there any way to block Bitcoin Knots nodes as my peers?]({{bse}}127456) Vojtěch Strnad provides an approach to blocking peers based on user-agent strings using two Bitcoin Core RPCs but discourages such an approach and points to a - related [Bitcoin Core GitHub issue][Bitcoin Core #30036] with similar discouragement. + related [Bitcoin Core GitHub issue][Bitcoin Core #30036] with similar discouragement. {% assign timestamp="33:42" %} - [What does OP_CAT do with integers?]({{bse}}127436) Pieter Wuille explains that Bitcoin Script stack elements do not contain data type information and different opcodes interpret the stack element's bytes in - different ways. + different ways. {% assign timestamp="42:00" %} - [Async Block Relaying With Compact Block Relay (BIP152)]({{bse}}127420) User bca-0353f40e outlines Bitcoin Core's handling of [compact blocks][topic compact block relay] and estimates the impact of missing transactions on block - propagation. + propagation. {% assign timestamp="43:03" %} - [Why is attacker revenue in selfish mining disproportional to its hash-power?]({{bse}}53030) Antoine Poinsot follows up on this and [another]({{bse}}125682) older [selfish @@ -74,7 +74,7 @@ answers posted since our last update.* adjustment does not take stale blocks into account, which means that decreasing competing miners' effective hashrate increases a miner's profits (on a long enough time scale) as much as increasing his own" (see [Newsletter - #358][news358 selfish mining]). + #358][news358 selfish mining]). {% assign timestamp="52:47" %} ## Releases and release candidates @@ -84,7 +84,7 @@ release candidates._ - [Bitcoin Core 28.2][] is a maintenance release for the previous release series of the predominant full node implementation. It - contains multiple bug fixes. + contains multiple bug fixes. {% assign timestamp="57:51" %} ## Notable code and documentation changes @@ -103,32 +103,32 @@ repo], and [BINANAs][binana repo]._ `proposal` mode. This enables mining pools using [Stratum v2][topic pooled mining] to validate block templates provided by miners via the faster IPC interface, rather than serialising up to 4 MB of JSON through RPC. The - proof-of-work and merkle root checks can be disabled in the options. + proof-of-work and merkle root checks can be disabled in the options. {% assign timestamp="59:21" %} - [Eclair #3109][] extends its [attributable failures][topic attributable failures] support (see Newsletter [#356][news356 failures]) to [trampoline payments][topic trampoline payments]. A trampoline node now decrypts and stores the part of the attribution payload intended for it and prepares the remaining blob for the next trampoline hop. This PR does not implement the relay of the attribution data for trampoline - nodes, which is expected in a follow-up PR. + nodes, which is expected in a follow-up PR. {% assign timestamp="1:00:48" %} - [LND #9950][] adds a new `include_auth_proof` flag to the `DescribeGraph`, `GetNodeInfo` and `GetChanInfo` RPCs and to their corresponding `lncli` commands. Including this flag returns the [channel announcement][topic channel announcements] signatures, allowing validation of channel details - by third-party software. + by third-party software. {% assign timestamp="1:01:31" %} - [LDK #3868][] reduces the precision of the [HTLC][topic htlc] hold time for [attributable failure][topic attributable failures] (see Newsletter [#349][news349 attributable]) payloads from 1-millisecond to 100-millisecond units, to mitigate timing-fingerprint - leaks. This aligns LDK with the latest updates to the [BOLTs #1044][] draft. + leaks. This aligns LDK with the latest updates to the [BOLTs #1044][] draft. {% assign timestamp="1:01:56" %} - [LDK #3873][] raises the delay for forgetting a Short Channel Identifier (SCID) after its funding output is spent from 12 to 144 blocks to allow for the propagation of a [splice][topic splicing] update. This is double the 72-block delay introduced in [BOLTs #1270][] that was implemented by Eclair (see Newsletter [#359][news359 eclair]). This PR also implements additional - changes to the `splice_locked` message exchange process. + changes to the `splice_locked` message exchange process. {% assign timestamp="1:03:10" %} - [Libsecp256k1 #1678][] adds a `secp256k1_objs` CMake interface library that exposes all the library’s object files to allow parent projects, such as @@ -136,14 +136,14 @@ repo], and [BINANAs][binana repo]._ those objects directly into their own static libraries. This solves the problem of CMake lacking a native mechanism to link static libraries into another and spares downstream users from providing their own `libsecp256k1` - binary. + binary. {% assign timestamp="1:04:11" %} - [BIPs #1803][] clarifies [BIP380][]’s [descriptor][topic descriptors] grammar by allowing all common hardened-path markers, while [#1871][bips #1871], [#1867][bips #1867], and [#1866][bips #1866] refine [BIP390][]’s [MuSig2][topic musig] descriptors by tightening key path rules, permitting repeated participant keys, and explicitly restricting multipath child - derivations. + derivations. {% assign timestamp="1:06:21" %} {% include snippets/recap-ad.md when="2025-07-01 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-07-01-newsletter-recap.md b/_posts/en/podcast/2025-07-01-newsletter-recap.md new file mode 100644 index 0000000000..c23d5f1aa8 --- /dev/null +++ b/_posts/en/podcast/2025-07-01-newsletter-recap.md @@ -0,0 +1,24 @@ +--- +title: 'Bitcoin Optech Newsletter #360 Recap Podcast' +permalink: /en/podcast/2025/07/01/ +reference: /en/newsletters/2025/06/27/ +name: 2025-07-01-recap +slug: 2025-07-01-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt are joined by Daniela Brozzoni +and Naiyoma to discuss [Newsletter #360]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-6-1/403141721-44100-2-d842a37a4ade1.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From 191c94400a68b727513c6587ce06c4ce2fe064d7 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Wed, 2 Jul 2025 19:37:40 +0200 Subject: [PATCH 136/278] Newletter 360 translate in French (#2401) --- .../fr/newsletters/2025-06-27-newsletter.md | 146 ++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 _posts/fr/newsletters/2025-06-27-newsletter.md diff --git a/_posts/fr/newsletters/2025-06-27-newsletter.md b/_posts/fr/newsletters/2025-06-27-newsletter.md new file mode 100644 index 0000000000..8077bbf6a2 --- /dev/null +++ b/_posts/fr/newsletters/2025-06-27-newsletter.md @@ -0,0 +1,146 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #360' +permalink: /fr/newsletters/2025/06/27/ +name: 2025-06-27-newsletter-fr +slug: 2025-06-27-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +La newsletter de cette semaine résume une recherche sur l'identification des nœuds complets en +utilisant les messages du protocole P2P et sollicite des retours sur la possibilité de supprimer le +support de `H` dans les chemins BIP32 dans la spécification BIP380 des descripteurs. +Sont également incluses nos sections régulières résumant les récentes questions et réponses de Bitcoin +Stack Exchange, annoncant de nouvelles versions et des candidats à la publication, ainsi que les résumés +des modifications notables apportées aux logiciels d'infrastructure Bitcoin populaires. + +## Actualités + +- **Identification des nœuds utilisant les messages `addr` :** Daniela Brozzoni a [publié][brozzoni + addr] sur Delving Bitcoin à propos d'une recherche qu'elle a menée avec le développeur Naiyoma pour + identifier le même nœud sur plusieurs réseaux en utilisant les messages `addr` qu'il envoie. Les + nœuds envoient des messages `addr` (adresse) du protocole P2P à leurs pairs pour faire la publicité + d'autres nœuds potentiels, permettant aux pairs de se trouver les uns les autres en utilisant un + système de diffusion décentralisé. Cependant, Brozzoni et Naiyoma ont réussi à identifier des nœuds + individuels en utilisant des détails de leurs messages d'adresse spécifiques, leur permettant + d'identifier le même nœud fonctionnant sur plusieurs réseaux (tels que IPv4 et [Tor][topic anonymity + networks]). + + Les chercheurs suggèrent deux atténuations possibles : supprimer les horodatages des messages + d'adresse ou, si les horodatages sont conservés, les randomiser légèrement pour les rendre moins + spécifiques à des nœuds particuliers. + +- **Un logiciel utilise-t-il `H` dans les descripteurs ?** Ava Chow a [posté][chow hard] sur la + liste de diffusion Bitcoin-Dev pour demander si un logiciel génère des descripteurs en utilisant le + H majuscule pour indiquer une étape de dérivation de clé [BIP32][topic bip32] renforcée. Si ce n'est + pas le cas, la spécification [BIP380][] des [descripteurs de script de sortie][topic descriptors] + pourrait être modifiée pour n'autoriser que le h minuscule et `'` pour indiquer le renforcement. + Chow note que, bien que BIP32 autorise le H majuscule, la spécification BIP380 incluait précédemment + un test interdisant l'utilisation du H majuscule et que Bitcoin Core n'accepte actuellement pas le H + majuscule. + +## Questions et réponses sélectionnées du Bitcoin Stack Exchange + +*[Le Bitcoin Stack Exchange][bitcoin.se] est l'un des premiers endroits où les contributeurs +d'Optech cherchent des réponses à leurs questions---ou quand nous avons quelques moments libres pour +aider les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous mettons en lumière +certaines des questions et réponses les mieux votées publiées depuis notre dernière mise à jour.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Existe-t-il un moyen de bloquer les nœuds Bitcoin Knots en tant que mes pairs ?]({{bse}}127456) + Vojtěch Strnad fournit une approche pour bloquer les pairs basée sur les chaînes d'agent utilisateur + en utilisant deux RPCs de Bitcoin Core mais décourage une telle approche et pointe vers un [problème + GitHub de Bitcoin Core][Bitcoin Core #30036] avec un découragement similaire. + +- [Que fait OP_CAT avec les entiers ?]({{bse}}127436) + Pieter Wuille explique que les éléments de pile de Bitcoin Script ne contiennent pas d'informations + sur le type de données et que différents opcodes interprètent les octets des éléments de pile de + différentes manières. + +- [Relais de blocs asynchrone avec Compact Block Relay (BIP152)]({{bse}}127420) + L'utilisateur bca-0353f40e décrit le traitement des [blocs compacts][topic compact block relay] par + Bitcoin Core et estime l'impact des transactions manquantes sur la propagation des blocs. + +- [Pourquoi les revenus d'un attaquant dans le minage égoïste sont-ils disproportionnés par rapport à sa puissance de hachage ?]({{bse}}53030) + Antoine Poinsot poursuit sur ce sujet et [une autre]({{bse}}125682) question plus ancienne sur le + [minage égoïste][topic selfish mining], en soulignant, "L'ajustement de la difficulté ne prend pas + en compte les blocs obsolètes, ce qui signifie que diminuer le taux de hachage effectif des mineurs + concurrents augmente les profits d'un mineur (sur une échelle de temps suffisamment longue) autant + qu'augmenter le sien" (voir le [Bulletin #358][news358 selfish mining]). + +## Mises à jour et versions candidates + +_Nouvelles mises-à-jours et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de mettre à niveau vers les nouvelles mises-à-jour ou d'aider à tester les versions candidates._ + +- [Bitcoin Core 28.2][] est une version de maintenance pour la série de versions précédente de + l'implémentation de nœud complet prédominante. Elle contient de multiples corrections de bugs. + +## Changements notables dans le code et la documentation + +_Changements récents notables dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning +repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], +[Interface de Portefeuille Matériel (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Propositions d'Amélioration de Bitcoin (BIPs)][bips +repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Inquisition Bitcoin][bitcoin +inquisition repo], et [BINANAs][binana repo]._ + +- [Bitcoin Core #31981][] ajoute une méthode `checkBlock` à l'interface de communication + inter-processus (IPC) `Mining` (voir le Bulletin [#310][news310 ipc]) qui effectue les mêmes + vérifications de validité que la RPC `getblocktemplate` en mode `proposal`. Cela permet aux pools de + minage utilisant [Stratum v2][topic pooled mining] de valider les modèles de blocs fournis par les + mineurs via l'interface IPC plus rapide, plutôt que de sérialiser jusqu'à 4 Mo de JSON via RPC. Les + vérifications de la preuve de travail et de la racine de Merkle peuvent être désactivées dans les + options. + +- [Eclair #3109][] étend son support des [échecs attribuables][topic attributable failures] (voir + le Bulletin [#356][news356 failures]) aux [paiements trampoline][topic trampoline payments]. Un nœud + trampoline maintenant déchiffre et stocke la partie de la charge utile d'attribution qui lui est + destinée et prépare le reste du blob pour le prochain saut trampoline. Cette PR n'implémente pas la + transmission des données d'attribution pour les nœuds trampoline, ce qui est prévu dans une PR + ultérieure. + +- [LND #9950][] ajoute un nouveau drapeau `include_auth_proof` aux RPC `DescribeGraph`, + `GetNodeInfo` et `GetChanInfo` et à leurs commandes `lncli` correspondantes. Inclure ce drapeau + retourne les signatures d'[annonce de canal][topic channel announcements], permettant la validation + des détails du canal par des logiciels tiers. + +- [LDK #3868][] réduit la précision du temps de maintien [HTLC][topic htlc] pour les charges utiles + d'[échec attribuable][topic attributable failures] (voir le Bulletin [#349][news349 attributable]). + de 1 milliseconde à 100 millisecondes, pour atténuer les fuites d'empreintes temporelles. Cela + aligne LDK avec les dernières mises à jour du brouillon du [BOLTs #1044][]. + +- [LDK #3873][] augmente le délai pour oublier un Identifiant de Canal Court (SCID) après que son + financement soit dépensé de 12 à 144 blocs pour permettre la propagation d'une mise à jour de + [splice][topic splicing]. Cela représente le double du délai de 72 blocs introduit dans [BOLTs + #1270][] qui a été mis en œuvre par Eclair (voir le Bulletin [#359][news359 eclair]). Cette PR + implémente également des changements supplémentaires dans le processus d'échange de messages + `splice_locked`. + +- [Libsecp256k1 #1678][] ajoute une bibliothèque d'interface CMake `secp256k1_objs` qui expose tous + les fichiers objet de la bibliothèque pour permettre aux projets parents, tels que le [projet + libbitcoinkernel][libbitcoinkernel project] prévu par Bitcoin Core, de lier ces objets directement + dans leurs propres bibliothèques statiques. Cela résout le problème de l'absence d'un mécanisme + natif dans CMake pour lier des bibliothèques statiques entre elles et épargne aux utilisateurs en + aval de fournir leur propre binaire `libsecp256k1`. + +- [BIPs #1803][] clarifie la grammaire des [descripteurs][topic descriptors] de [BIP380][] en + autorisant tous les marqueurs de chemin sécurisé communs, tandis que [#1871][bips #1871], + [#1867][bips #1867], et [#1866][bips #1866] affinent les descripteurs [MuSig2][topic musig] de + [BIP390][] en resserrant les règles des chemins de clés, en permettant des clés de participants + répétées, et en restreignant explicitement les dérivations d'enfants multipath. + +{% include snippets/recap-ad.md when="2025-07-01 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31981,3109,9950,3868,3873,1678,1803,1871,1867,1866,30036,1044,1270" %} +[bitcoin core 28.2]: https://bitcoincore.org/bin/bitcoin-core-28.2/ +[brozzoni addr]: https://delvingbitcoin.org/t/fingerprinting-nodes-via-addr-requests/1786/ +[chow hard]: https://mailing-list.bitcoindevs.xyz/bitcoindev/848d3d4b-94a5-4e7c-b178-62cf5015b65f@achow101.com/T/#u +[news358 selfish mining]: /fr/newsletters/2025/06/13/#calcul-du-seuil-de-danger-du-minage-egoiste +[news310 ipc]: /fr/newsletters/2024/07/05/#bitcoin-core-30200 +[news356 failures]: /fr/newsletters/2025/05/30/#eclair-3065 +[news349 attributable]: /fr/newsletters/2025/04/11/#ldk-2256 +[news359 eclair]: /fr/newsletters/2025/06/20/#eclair-3110 +[libbitcoinkernel project]: https://github.com/bitcoin/bitcoin/issues/27587 \ No newline at end of file From 2c5e90de46da71d583c0e428c09d06ac564409da Mon Sep 17 00:00:00 2001 From: "Zhiwei(Jeffrey) Hu" Date: Thu, 3 Jul 2025 13:43:37 +0800 Subject: [PATCH 137/278] Newsletter-358: translate into Chinese (#171) * Newsletter-358: translate into Chinese * Apply suggestions from code review Co-authored-by: editor-Ajian <34365188+editor-Ajian@users.noreply.github.com> --------- Co-authored-by: editor-Ajian <34365188+editor-Ajian@users.noreply.github.com> --- .../zh/newsletters/2025-06-13-newsletter.md | 109 ++++++++++++++++++ 1 file changed, 109 insertions(+) create mode 100644 _posts/zh/newsletters/2025-06-13-newsletter.md diff --git a/_posts/zh/newsletters/2025-06-13-newsletter.md b/_posts/zh/newsletters/2025-06-13-newsletter.md new file mode 100644 index 0000000000..dca9588ca6 --- /dev/null +++ b/_posts/zh/newsletters/2025-06-13-newsletter.md @@ -0,0 +1,109 @@ +--- +title: 'Bitcoin Optech Newsletter #358' +permalink: /zh/newsletters/2025/06/13/ +name: 2025-06-13-newsletter-zh +slug: 2025-06-13-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- + +本周的周报描述了如何计算自私挖矿的危险阈值，总结了一个关于防止过滤高手续费率交易的想法，寻求对 BIP390 `musig()` 描述符的拟议变更的反馈，并宣布了一个用于加密描述符的新库。此外还包括我们的常规栏目：Bitcoin Core PR 审查俱乐部的总结、新版本和候选版本的公告，以及对热门比特币基础设施项目近期变更的描述。 + +## 新闻 + +- **计算自私挖矿的危险阈值：** Antoine Poinsot 在 Delving Bitcoin 上[发帖][poinsot selfish]，扩展了 2013 年[论文][es selfish]中的数学内容。该论文使[自私挖矿攻击][topic selfish mining]得以命名（尽管该攻击在 2010 年就[被描述过][bytecoin selfish]）。Antoine 还提供了一个简化的挖矿和区块传播[模拟器][darosior/miningsimulation]，允许对该攻击进行实验。他专注于重现 2013 年论文的一个结论：控制总网络算力 33% 的不诚实矿工（或联系紧密的矿工卡特尔），在没有额外优势的情况下，可以在长期基础上比总计控制 67% 算力的其他单打独斗的矿工获得边际更高的利润。这是通过 33% 矿工选择性地延迟宣布其发现的一些新区块来实现的。随着不诚实矿工的算力增加到 33% 以上，它变得更加有利可图，直到超过 50% 算力，其可以阻止竞争对手在最佳区块链上留下任何新区块。 + + 我们没有仔细审查 Poinsot 的帖子，但他的方法对我们来说似乎是合理的，我们建议任何有兴趣验证数学或更好地理解它的人阅读。 + +- **通过头部交易池集合协调实现中继的抗审查性：** Peter Todd 在 Bitcoin-Dev 邮件列表中[发布][todd feerec]了一个机制，该机制将允许节点断开过滤高手续费率交易的对等节点。该机制依赖于[族群交易池][topic cluster mempool]和集合协调机制，如 [erlay][topic erlay] 使用的机制。节点将使用[族群交易池][topic cluster mempool]来计算其最有利可图的未确认交易集合，这些交易可以适合（例如）8,000,000 权重单位（最大 8 MB）。节点的每个对等节点也会计算其前 8 MWU 的未确认交易。使用高效的算法，如 [minisketch][topic minisketch]，节点将与其每个对等节点协调其交易集合。这样做时，它将确切地了解每个对等节点在其交易池顶部拥有哪些交易。然后节点将定期断开与平均交易池利润最低的对等节点。 + + 通过断开利润最低的对等节点，节点最终会找到最不可能过滤掉高手续费率交易的对等节点。Todd 提到，他希望在与族群交易池支持合并到 Bitcoin Core 后在其实现上继续工作。他将这个想法归功于 Gregory Maxwell 和其他人；Optech 在[周报 #9][news9 reconcile]中首次提到了该基本想法。 + +- ******更新 BIP390 以允许在 `musig()` 表达式中重复参与者密钥：** Ava Chow 在 Bitcoin-Dev 邮件列表中[发布][chow dupsig]询问是否有人反对更新 [BIP390][] 以允许[输出脚本描述符][topic descriptors]中的 `musig()` 表达式包含同一参与者公钥多次。这将简化实现，并且 [BIP327][] 的 [MuSig2][topic musig] 规范明确允许。截至本文撰写时，没有人反对，Chow 已经打开了一个[拉取请求][bips #1867]来更改 BIP390 规范。 + +- **描述符加密库：** Josh Doman 在 Delving Bitcoin 上[发布][doman descrypt]宣布了他构建的一个库，该库将[输出脚本描述符][topic descriptors]或 [miniscript][topic miniscript] 的敏感部分加密到其中包含的公钥。他描述了解密所需的信息： + + > - 如果你的钱包需要 2-of-3 密钥来花费，它将需要恰好 2-of-3 密钥来解密。 + > + > - 如果你的钱包使用复杂的 miniscript 策略，如“要么 2 个密钥，要么（时间锁和另一个密钥）”，加密遵循相同的结构，就好像所有时间锁和哈希锁都满足一样。 + + 这与[周报 #351][news351 salvacrypt]中讨论的加密描述符备份方案不同，在该方案中，了解描述符中包含的任何公钥都允许解密描述符。Doman 认为，他的方案为加密描述符备份到公共或半公共源（如区块链）的情况提供了更好的隐私性。 + +## Bitcoin Core PR 审查俱乐部 + +*在这个月度栏目中，我们总结最近的 [Bitcoin Core PR 审查俱乐部][Bitcoin Core PR Review +Club]会议，高亮了一些重要的问题和答案。点击下面的问题查看会议中答案的摘要。* + +[分离 UTXO 集合访问与验证函数][review club 32317]是由 [TheCharlatan][gh thecharlatan] 提出的 PR，它允许通过仅传递所需的 UTXO 来调用验证函数，而不是要求完整的 UTXO 集合。这是 [`bitcoinkernel` 项目][Bitcoin Core #27587]的一部分，是使库对不实现 UTXO 集合的完整节点实现（如 [Utreexo][topic utreexo] 或 [SwiftSync][somsen swiftsync] 节点（参见[周报 #349][news349 swiftsync]））更可用的重要步骤。 + +在前 4 个提交中，此 PR 通过要求调用者首先获取他们需要的 `Coin`s 或 `CTxOut`s 并将这些传递给验证函数，而不是让验证函数直接访问 UTXO 集合，减少了交易验证函数与 UTXO 集合之间的耦合。 + +在后续提交中，通过将需要 UTXO 集合交互的剩余逻辑分离到单独的 `SpendBlock()` 方法中，完全移除了 `ConnectBlock()` 对 UTXO 集合的依赖。 + +{% include functions/details-list.md + q0="为什么从 `ConnectBlock()` 中分离出新的 `SpendBlock()` 函数对这个 PR 有帮助？你会如何比较这两个函数的用途？" + a0="`ConnectBlock()` 函数最初执行区块验证和 UTXO 集合修改。这次重构分离了这些职责：`ConnectBlock()` 现在只负责不需要 UTXO 集合的验证逻辑，而新的 `SpendBlock()` 函数处理所有 UTXO 集合交互。这允许调用者使用 `ConnectBlock()` 在没有 UTXO 集合的情况下进行区块验证。" + a0link="https://bitcoincore.reviews/32317#l-37" + + q1="除了允许在没有 UTXO 集合的情况下使用内核之外，你看到这种解耦的另一个好处吗？" + a1="除了为没有 UTXO 集合的项目启用内核使用外，这种解耦使代码更容易独立测试和更简单维护。一位审查者还指出，移除对 UTXO 集合访问的需求为并行验证区块打开了大门，这是 SwiftSync 的重要功能。" + a1link="https://bitcoincore.reviews/32317#l-64" + + q2="`SpendBlock()` 接受 `CBlock block`、`CBlockIndex pindex` 和 `uint256 block_hash` 参数，都引用被花费的区块。为什么我们需要 3 个参数来做这件事？" + a2="验证代码是性能关键的，它影响重要参数，如区块传播速度。从 `CBlock` 或 `CBlockIndex` 计算区块哈希不是免费的，因为该值没有被缓存。因此，作者决定通过传递已经计算的 `block_hash` 作为单独参数来优先考虑性能。类似地，`pindex` 可以从区块索引获取，但这将涉及额外的映射查找，这不是严格必要的。 +
_注意：作者后来[改变了][32317 updated approach]方法，移除了 `block_hash` 性能优化。_" + a2link="https://bitcoincore.reviews/32317#l-97" + + q3="此 PR 中的前几个提交将 `CCoinsViewCache` 从几个验证函数的函数签名中重构出来。`CCoinsViewCache` 是否持有整个 UTXO 集合？为什么这（不）是一个问题？这个 PR 是否改变了这种行为？" + a3="`CCoinsViewCache` 不持有整个 UTXO 集合；它是一个内存缓存，位于 `CCoinsViewDB` 前面，后者在磁盘上存储完整的 UTXO 集合。如果请求的币不在缓存中，就必须从磁盘获取。此 PR 本身不改变这种缓存行为。通过从函数签名中移除 `CCoinsViewCache`，它使 UTXO 依赖变得明确，要求调用者在调用验证函数之前获取币。" + a3link="https://bitcoincore.reviews/32317#l-116" +%} + +## 发布和候选版本 + +*热门比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本。* + +- [Core Lightning 25.05rc1][] 是这个热门闪电网络节点实现的下一个主要版本的候选版本。 + +- [LND 0.19.1-beta][] 是这个热门闪电网络节点实现的维护版本。它[包含][lnd rn]多个错误修复。 + +## 显著的代码和文档变更 + +*[Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[硬件钱包接口 (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案 (BIPs)][bips repo]、[闪电网络 BOLTs][bolts repo]、[闪电网络 BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo] 的近期显著变更。* + +- [Bitcoin Core #32406][] 取消了 `OP_RETURN` 输出大小限制（标准性规则），将默认 `-datacarriersize` 设置从 83 字节提高到 100,000 字节（最大交易大小限制）。`-datacarrier` 和 `-datacarriersize` 选项仍然存在，但被标记为已弃用，预计在未确定的未来版本中被移除。此外，此 PR 还取消了一笔交易只允许一个 OP_RETURN 输出的转发限制，现在交易中的所有此类输出共享同一个大小限制。有关此变更的更多关联内容，请参见[周报 #352][news352 opreturn]。 + +- [LDK #3793][] 添加了一个新的 `start_batch` 消息，向对等节点发出信号，将接下来的 `n`（`batch_size`）个消息作为单个逻辑单元处理。它还更新了 `PeerManager` 以在[拼接][topic splicing]期间依赖于此来处理 `commitment_signed` 消息，而不是向批次中的每个消息添加 TLV 和 `batch_size` 字段。这是尝试允许额外的闪电网络协议消息被批处理，而不仅仅是 `commitment_signed` 消息（它是闪电网络规范中定义的唯一批处理）。 + +- [LDK #3792][] 引入了对 [v3 承诺交易][topic v3 commitments]（参见[周报 #325][news325 v3]）的初始支持，这些交易依赖于 [TRUC 交易][topic v3 transaction relay] 和[临时锚点][topic ephemeral anchors]；此特性需要在启动时设置测试标签才能动用。节点现在拒绝任何设置非零手续费率的 `open_channel` 提议，确保它自己永远不会发起这样的通道，并停止自动接受 v3 通道以首先为后续手续费追加保留 UTXO。该 PR 还将每通道 [HTLC][topic htlc] 限制从 483 降低到 114，因为 TRUC 交易必须保持在 10 kvB 以下。 + +- [LND #9127][] 为 `lncli addinvoice` 命令添加了 `--blinded_path_incoming_channel_list` 选项，允许接收者嵌入一个或多个（用于多跳）首选通道 ID，供付款人尝试在[盲路径][topic rv routing]上转发。 + +- [LND #9858][] 开始为 [RBF][topic rbf] 合作式关闭流程（参见[周报 #347][news347 rbf]）发出生产功能位 61 信号，以正确启用与 Eclair 的互操作性。它保留了暂存位 161 以维持与测试该功能的节点的互操作性。 + +- [BOLTs #1243][] 更新了 [BOLT11][] 规范，指出如果强制字段（如 p（支付哈希）、h（描述哈希）或 s（秘密））长度不正确，读取者（发送者）不得支付发票。以前，节点可以忽略这个问题。此 PR 还在示例部分添加了一个注释：规范不强制执行 [Low R 签名][topic low-r grinding]，尽管它可以节省一个字节的空间。 + +{% include snippets/recap-ad.md when="2025-06-17 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32406,3793,3792,9127,1867,9858,1243,27587" %} +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[lnd 0.19.1-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.1-beta +[poinsot selfish]: https://delvingbitcoin.org/t/where-does-the-33-33-threshold-for-selfish-mining-come-from/1757 +[bytecoin selfish]: https://bitcointalk.org/index.php?topic=2227.msg30083#msg30083 +[darosior/miningsimulation]: https://github.com/darosior/miningsimulation +[todd feerec]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aDWfDI03I-Rakopb@petertodd.org/ +[news9 reconcile]: /zh/newsletters/2018/08/21/#bandwidth-efficient-set-reconciliation-protocol-for-transactions +[chow dupsig]: https://mailing-list.bitcoindevs.xyz/bitcoindev/08dbeffd-64ec-4ade-b297-6d2cbeb5401c@achow101.com/ +[doman descrypt]: https://delvingbitcoin.org/t/rust-descriptor-encrypt-encrypt-any-descriptor-such-that-only-authorized-spenders-can-decrypt/1750/ +[news351 salvacrypt]: /zh/newsletters/2025/04/25/#standardized-backup-for-wallet-descriptors +[es selfish]: https://arxiv.org/pdf/1311.0243 +[lnd rn]: https://github.com/lightningnetwork/lnd/blob/v0.19.1-beta/docs/release-notes/release-notes-0.19.1.md +[news352 opreturn]: /zh/newsletters/2025/05/02/#increasing-or-removing-bitcoin-core-s-op-return-size-limit +[news325 v3]: /zh/newsletters/2024/10/18/#version-3-commitment-transactions +[news347 rbf]: /zh/newsletters/2025/03/28/#lnd-8453 +[review club 32317]: https://bitcoincore.reviews/32317 +[gh thecharlatan]: https://github.com/TheCharlatan +[somsen swiftsync]: https://gist.github.com/RubenSomsen/a61a37d14182ccd78760e477c78133cd +[32317 updated approach]: https://github.com/bitcoin/bitcoin/pull/32317#issuecomment-2883841466 +[news349 swiftsync]: /zh/newsletters/2025/04/11/#swiftsync-speedup-for-initial-block-download-swiftsync From d6fc8f4bec6495ca559ae6caa943512162b6096d Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 3 Jul 2025 09:10:04 -0500 Subject: [PATCH 138/278] Podcast: add 359 transcription --- .../en/podcast/2025-06-24-newsletter-recap.md | 1056 ++++++++++++++++- 1 file changed, 1055 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-06-24-newsletter-recap.md b/_posts/en/podcast/2025-06-24-newsletter-recap.md index 0d7980d717..0b701aa896 100644 --- a/_posts/en/podcast/2025-06-24-newsletter-recap.md +++ b/_posts/en/podcast/2025-06-24-newsletter-recap.md @@ -19,6 +19,1060 @@ and Rene Pickhardt to discuss [Newsletter #359]({{page.reference}}). ## Transcription -_transcription coming soon_ +**Mike Schmidt**: Welcome to Bitcoin Optech Recap #359. Today, we're going to +be talking about restricting access to the Bitcoin Core project discussion, we +have garbled circuits in BitVM3, an update on a Lightning channel balancing +research, and we have four ecosystem software updates that we're going to get +into. Murch and I are joined this week by three special guests. Brian, do you +want to introduce yourself? + +**Bryan Bishop**: Yeah, I'm Bryan Bishop, Bitcoin Core Contributor, background +programming, started the Bank, done startups, write code, build products. + +**Mike Schmidt**: Robin? + +**Robin Linus**: Hi, I'm Robin Linus, I'm the creator of BitVM. I work at +ZeroSync, and I'm doing a PhD on Bitcoin at Stanford, and I like to say I'm the +Bitcoin researcher at Stanford. + +**Mike Schmidt**: René? + +**René Pickhardt**: Yeah, I'm an LN researcher and thinking a lot about LN +reliability and liquidity management. + +_Proposal to restrict access to Bitcoin Core Project discussion_ + +**Mike Schmidt**: Great. Thank you three for joining Murch and I this week. +We're going to jump in and just go sequentially, starting with the News section. +We have three items. First one, "Proposal to restrict access to Bitcoin Core +Project discussion". Bitcoin Core development is currently done in public on +GitHub, which is great for transparency, but also means that there can be noise, +brigading, and potentially social pressure on contributors to that project. +Bryan, you recently posted to the Bitcoin-Dev Mailing List about an idea to move +development to a private, membership-based collaboration space while keeping the +code open. Bryan, what do you see as the core problem you're solving, pun +intended, and why make this case now? + +**Bryan Bishop**: Well, so the core idea here, yes, pun intended indeed, is that +there needs to be a closed space exclusively reserved for software development +purposes. And anyone on the internet can currently create their own private +communities or closed spaces, and there is no ability for anyone + +anywhere to prohibit this or stop people from privately communicating with each +other. And the observation here though is that there is quite a spectrum from +totally closed spaces to completely open spaces. On one extreme end, a +completely closed private space is one that no one is able to read and no one is +able to access or use; and on the other extreme is a completely open space where +everyone can read it and everyone can write to it. + +Right now, I would say the Bitcoin Core Project is a little bit closer to the +side of the spectrum where everyone can read it and everyone can write to it, at +least for comments, issues, code review and PRs on the GitHub project page. And +this has been a persistent issue for Bitcoin Core developers because of having +this ability for public right without moderation, basically means that one of +the primary spaces where Bitcoin Core developers go to collaborate with each +other is also public right with no moderation and no delay. And so, what if, +and bear with me, what if we chose to try experiments where we did not do that? +What if, for example, people could register, and then after registering, there +is a delay before their first comment can be posted? Or what if they register +and their profile is approved by one or more other existing people, or +something, in the project and things like that. And this is mainly around the +ability to write comments, issues, or other posting capabilities. + +This is not to say that we should eliminate, for example, open-source code, or +disallow people from reviewing code, or even reading comments or issues that are +posted. It's solely that we can choose to make a closed space that has +different rules other than what the defaults that GitHub provides. + +**Mike Schmidt**: And the timing of this is very close to one of the recent +kerfuffles on GitHub around OP_RETURN, the OP_RETURN PR specifically, although +there's obviously been a bunch of discussions outside of the GitHub repository, +but a lot of those then spilled into the GitHub PR itself, being somewhat +distracting for the contributors. I assume that this is sort of your solution +or reaction to that? + +**Bryan Bishop**: Well, a little bit. I guess I should have listened to the +Optech Recap podcast more often, because I was not aware that this was such a +popular issue outside of GitHub. From my perspective, I was following PRs and +issues and discussions in the Bitcoin development community and there was a +bunch of irrelevant things posted on a PR. And I was like, "Well, that's weird. +We should just probably, instead of deleting comments after they're posted, we +should probably just invite people to make comments instead". And when I posted +my proposal, I'm starting to get the sense that there's something I was unaware +of, possibly through Twitter, or X, that I didn't understand the full extent of. +And that's still a little bit confusing to me. + +The responses to my post have been quite bifurcated. Developers read it and go, +"Oh, that's interesting. And yeah, maybe that's useful. Or maybe there's some +sort of incremental thing we could do. Or it might not be totally necessary", +which is interesting feedback. And then, on the other hand, on x.com, I got +responses such as, "This is the most terrible idea I've ever heard of, and +everyone should be able to post to the developers' areas no matter what", which +was also interesting feedback, which if you do believe that, if that is +something you very strongly believe, that everyone should be able to write +comments everywhere that developers do their work, if someone really believes +that, I would suggest formalizing that, such as write a document, set of +principles or something. I don't happen to believe it, but I'm sure some people +do and according to the x.com reactions, a few people might. + +**Mike Schmidt**: Well, we have a Bitcoin Core contributor here on the call and +I wanted to see, Murch, if you had any feedback on the idea or any of the points +we've touched on so far. + +**Mark Erhardt**: Well, I'm fascinated that you say you weren't aware of how +popular this topic was outside of GitHub, because that was something that was +occupying a lot of my time in the last month. + +**Bryan Bishop**: I work very hard to insulate myself from certain social media +effects, and I'm not always successful. + +**Mark Erhardt**: That is really funny. Because it was such an overwhelming +drain on my attention in the past month that I congratulate you on your success +of insulating yourself. Either way, I think there's multiple things here. One +is a lot of people seem to have a very strong feeling about how much of Bitcoin +Core ownership they should have. And on the one hand, I think our project is +very successful, in the sense that if people want to share in the process, that +is a good thing. I think that a lot of developers work on building the project +that they are interested in having, and this happens to also be something a lot +of other people are interested in, but there's no direct ownership of the +community on the time of the contributors. So, there's a very odd dynamic in +that sense. + +I think it would sometimes be nice to be able to have a delay, or like a +mitigation of the worst brigading. Nobody really benefits when 200 new comments +are added to a PR in a couple of days and most of them are repetitive and do not +add new information. But occasionally, we do get outside people that show up +for the first time and then end up sticking around, or have just some valuable +insight on a singular topic. So fully insulating it, I think, probably takes a +bit away from the interactive nature of how the project's set up right now. But +yeah, I think the main problem was just how popular the topic was in general, +even outside of GitHub. The GitHub interaction was only sort of the tip of the +iceberg. I'm not sure if that would actually help much at all. It is still a +conversation that needs to be had with the community. So, if the community +conversation happens outside anyway and someone just takes a screenshot of a PR +and then gets hundreds of people riled up and talking about this, it helps if +someone, say, takes the role of a developer advocate, or just one of the +developers feels like they need to chime in and explain. + +So, yes, it would definitely help the people that don't want to have those +conversations to help insulate them, but it's also a signal that we need to talk +more to each other when this sort of brigading happens. So, I don't, I don't +know whether the effort of instituting changes to our workflow like that would +be worth it because it's, well, every half year or so, one of the PR blows up +like that. So, I don't know, that's from the top of my head. + +**Mike Schmidt**: Bryan, we have the mailing list where people can opine and +discuss things that is in particular pieces of code or PR. Where would you +imagine, or what are some ideas of where you'd imagine that the more external to +Bitcoin Core contributor people would take their feedback and or grievances on a +particular PR? What venue would that occur in, in your mind? + +**Bryan Bishop**: It's a great question. And what's really funny is, ever since +becoming one of the BIP editors, or probably before as well, there's this very +interesting tension where from a BIP editor perspective and BIPs repository +perspective, often the thing to say is, "Well, go to the mailing list with that +idea". And as a mailing list moderator, I have to say, "Well, don't post that +on the mailing list. This is a bad email, this is dumb, or this is a noise", or +something, "go post it somewhere else". And I don't say, "Well, go post it on +BIPs", but essentially the message is, "Go post it somewhere else". And so, I +would say the general solution though is that thankfully, this is the internet, +the World Wide Web, and anyone can create new communities or forums, or anything +they want, to aggregate people to talk about things that they want to talk +about. I don't think it's necessarily the role of the Bitcoin Core Project to +necessarily host that platform for hosting those discussions. + +Now, I would also add that, for example, both BIPs and the mailing list are not +Bitcoin-Core-hosted either, certainly adjacent. There are certainly related +people involved and are participating in both. But in general, the concept of +free speech in our different countries does not require people to host the +speech of others. And thankfully, there are ways of creating other platforms to +post whatever you want. And so, one question, one way to interpret your +question, Mike, is, am I interested in hosting those discussions? Me +personally, not really. Am I interested in reading them sometimes? Yeah, I +suppose so. I don't know though. It's not necessarily the Bitcoin-Development +mailing list, right, because the mailing list is supposed to be about Bitcoin +development. + +**Mike Schmidt**: Any two cents on that, Murch? I know obviously, Twitter was a +big part of the most recent discussion around OP_RETURN. It's very hard to +collate those ideas that are in various Twitter threads into something that you +can point at and discuss. Stacker News was one that had some discussion as well +that I think, Murch, you were participating in. I don't know, did any of those +feel like they were productive places for the community to opine? + +**Mark Erhardt**: I thought that the Stacker News thread answered a lot of +questions, but maybe it was too one-sided. I don't think that it helped really +inform. One of the biggest things that hasn't really been addressed at all is +that one side basically has produced some 30 or so podcasts on this topic, and I +don't think that there was maybe one from the other side, or maybe a couple. +But there was just a huge imbalance in how invested people felt on this topic. +And essentially, the area of discussion in the podcast sphere self-replicated, +and a lot of the talking points that I find completely absurd got propagated +like mad, and I guess people listen to podcasts a lot more than they actually go +to GitHub or read the mailing list or Stacker News. So, in the end, I still +feel that most of the people just never really even engage with the +counterarguments and are very upset. + +But yeah, I agree that you don't have to host a conversation if you don't want +to. It is certainly not the right place for hundreds of people to come in and +shout at each other in our workplace. That just is not productive. And I know +numerous Bitcoin Core contributors just immediately muted the thread and did not +look at it at all. But yeah, the nice thing about it is it's sort of central. +It's at least a place where people would see a response potentially, because +with the wholly distributed conversation in podcasts that usually only have one +guest on that talks about one side of the issue, it just doesn't really lead to +an informed community. So, I don't know. It's a terrible place, but maybe not +the worst outcome out of all, because at least stuff gets seen there. I don't +know, I rambled, sorry. + +**Mike Schmidt**: I did pull out what I thought was some interesting comments +from TheCharlatan on Bryan's post, and I'll quote a couple of those here, +because I just thought they were interesting. The Charlatan said, "The +perceived brigading did not impede the project from making progress on the +issue. It led to a rare moment of alignment in the form of a common statement, +brought more eyes to reviewing the PR, and finally led to a resolution of the +question. The discussion was also focused on the two PRs and did not impede +progress on the other 300-plus others". And he goes on to say, "It also shows +that our organization is still the same scrappy, loose collective of individuals +with individual approaches and opinions capable of tolerating dissent. If I +were to choose a client to run my money on, these are all soft qualities I'd +look out for". No need to respond to that, I just feel like I wanted to add +that in. Bryan, anything that you'd say in closing out this discussion? + +**Bryan Bishop**: Well, one observation I'll make, and first of all, I don't +think I can disagree with the quotes you just read. Yes, it is true that the +project continues, and everything. That's great. It seems like there's a +number of different issues that are either being confused or coming to the +surface here, just between questions about how Bitcoin Core developers work +together, the role of developers interfacing with the public, and then the +public's role in what they want to do or hear about, or what happens when people +are upset, or they have an opinion that they want to express, or what happens if +there's misinformation? Who's responsible for that, or who is responsible for +correcting it, or responding to the outrage? + +I don't have any answers to any of these issues or questions, but they might be +separate issues and separate topics. And by more carefully structuring our +inquiries into these matters, we might be able to at least come to certain +conclusions. For example, I think from my email, one very interesting idea that +came up multiple times was the idea of, "Well, Bryan, your proposal was very +strong. What if we try something smaller?" It would be nice to be able to +experiment with different ideas more quickly and trying different strategies, +and if they don't work, we can cancel it or we can undo it, or something. For +example, moderating and delaying new posts, or trying a different experiment, +such as all new posts by new members that have never posted before get delayed +by one hour, what about two hours, what about one day, or something? And if we +can just try different experiments, and whether we try them on the Bitcoin Core +GitHub repository or not, whether they're tried in different areas or different +places on the internet, I think that ability to experiment and see whether that +benefits us and benefits the work that we're trying to do is a good outcome. + +**Mark Erhardt**: Yes. But one of the points that really got people upset was +this sort of experimentation. There were some new approaches to moderation +tried in this PR specifically. A bunch of comments got hidden for repeating +already discussed points or for personal attacks, and a few people even got +banned for personal attacks. And they, of course, then turned around and said, +"See, they're censoring my speech". And as you might think of bitcoiners, that +got them really going. And so, there is just several levels of delicate +communication here, where people just are looking for points to score. And for +example, delaying comments by a day, I think it might be cleaner to just prevent +people from posting than to delay their posts or hide them or delete them, +because not being able to post might be less aggravating than posting but then +not being visible or removed. So, I don't know. I'd certainly love for the +overall situation to improve, but I just find it very hard to know what the +actual solution is here. + +**Bryan Bishop**: Yeah, I wish I had answers for you. + +**Mike Schmidt**: Well, Bryan, thanks for coming on and talking about some of +these ideas and experiments, and representing your mailing-list post. We +appreciate your time. We understand if you need to drop. + +**Bryan Bishop**: Yeah, thanks for having me. + +_Improvements to BitVM-style contracts_ + +**Mike Schmidt**: Next news item, "Improvements to BitVM-style contracts". +Robin, you posted to Delving Bitcoin about BitVM3, a new BitVM approach using +something called "Garbled Circuits". This approach makes SNARK verification on +Bitcoin over 1,000 times more efficient than BitVM2, but maybe you can walk us +through what BitVM3 is, and how it improves on the most recent prior design in +BitVM2. + +**Robin Linus**: Sure. First, maybe a quick recap of how BitVM2 works. BitVM2 +is doing optimistic verification of SNARKs. SNARK proofs are these magical +proof systems that essentially allow us to compress infinite amounts of +computation into a very succinct proof, and they are super-great for second +layers, for bridging Bitcoin to rollups to sidechains, and essentially +trust-minimized bridges. And, yeah, these trust-minimized bridges, they are +essentially enabled by SNARK verifiers, by Bitcoin being able of verifying a +SNARK. Ideally, we would do that in Bitcoin Script, but unfortunately, that's +not possible in Bitcoin Script today, so we are doing this optimistic +verification. In BitVM2, that's essentially using optimistic computation. + +So, you have these two roles. You have like an operator who operates the +bridge, and then you have challengers that can challenge the actions of the +operator. And if the operator wants to do a peg-out, he has to commit to a +SNARK proof that proves the validity of his peg-out. And then, every challenger +can read this proof from the chain and verify it offchain, and if it's +incorrect, they can challenge the operator. And in Bitvm2, the problem is this +so-called assert transaction that the operator has to do is roughly 4 MB, and +also the disprove transaction that the challenger has to do is also 4 MB. So, +it's quite a large transaction. And even worse is that the operator has to lock +collateral to essentially make a bet that they bet nobody can disprove them. And +if you can disprove them, then the operator pays you to disprove them. And this +collateral is quite large, it's on the order of $10,000 to $15,000, and that +makes BitVM2 bridges very clunky and expensive. + +Now, the idea of garbled circuits is to minimize these transactions by a factor +of like 10,000 or something; both the assert transaction and the disprove +transactions become way smaller. The assert transaction is reduced from 4 MB to +roughly 50 kB, and the disprove transaction is reduced from 4 MB down to roughly +200 bytes. So, that's a huge game changer, in particular because the collateral +is for the disprove transaction, and now it's just 200 bytes instead of 4 MB. +So, you don't need any collateral at all anymore. So, yeah, that makes it +orders of magnitude more cheaper. + +**Mike Schmidt**: Robin, why don't you need the collateral anymore? Isn't there +still some funds at stake if someone is not telling the truth? + +**Robin Linus**: No, there should be some small collateral that is painful for +the operator to lose, but there is no collateral required to execute this huge +transaction anymore.. + +**Mike Schmidt**: Got it. + +**Mark Erhardt**: Previously, they'd have to buy a whole block or even several +blocks, and at certain feerates, that would be very expensive for 200 bytes. +That's much cheaper. So, just the cost to create the disprove transaction is +much smaller. But you do want some sort of collateral in the sense that +punishment for making false claims is executed, right, like the penalty +transaction on LN? + +**Robin Linus**: Yeah, exactly. So, there is some disincentive to lie, but it +can be just orders of magnitude cheaper than buying a whole block of block +space. Yeah, and how does that work? Well, it works with some very magical +tool called garbled circuits. And first of all, I have to give credits to +Jeremy Rubin and also to Liam Eagan, and I think also Sergio Lerner has been +working on that. Multiple teams independently of each other have been figuring +out this solution, and now the entire BitVM Alliance has pivoted to this new +approach, and we are exploring in parallel multiple different approaches of how +to make it as practical as possible. But it was definitely Jeremy Rubin who +kind of popularized it. He garbled-circuit-pilled me, and then I was just +mind-blown. And then I garbled-circuit-pilled everyone else. And yeah, how +does that work? + +Well, first of all, we can picture that garbled circuit as just like a black +box, and that black box allows us to verify a SNARK, and this black box is +communicated offchain. So, the operator sets up this black box and then sends +it, or publishes it such that every challenger can download it. And then during +peg-out, the operator has to assert again to a proof. So, they publish a proof +in the chain, and then everybody can read that proof and feed it into the black +box, into the garbled circuit. And now, the interesting thing is they can +validate that proof in the garbled circuit and they will get a result, either +true or false. The proof is either true or false, it's correct or incorrect. +And if it's incorrect, they learn a secret, and they learn that secret only if +the proof was incorrect. So, that secret essentially acts as a fraud proof. + +If you know that secret, that means the operator published an incorrect proof, +and this makes it extremely cheap to disprove the operator, because you just +need to publish that secret onchain and then you have disproven the operator. +You don't have to execute the entire SNARK, or you don't have to verify the +entire SNARK onchain anymore. You just feed that SNARK into that black box and +if the SNARK is incorrect, then you learn that secret which represents false, +and that is sufficient to disprove or to falsify any incorrect SNARK proof. +That is essentially the magic how it works. And since all the other computation +is now offchain, it becomes extremely efficient onchain. Onchain, we just need +to commit to the proof, or the operator has to commit to the proof and +essentially sign it. They have to sign every bit of it, so it's still like 50 +kB or something, but that's it, we don't need anything else. + +This makes everything way more efficient but there are still some challenges to +it. The big problem is what's the size of the garbled circuit? Garbled +circuits have been invented, I think, in 1997 or something, so they're already +quite old. And there is that standard scheme called Yao style circuits after +the guy, Yao, who invented it. And if you apply just that simple scheme, then +you end up with a garbled circuit that is roughly 500 GB, or something. But +this 500 GB is not enough. You also have to prove that this circuit is actually +correct, because I give you 500 GB of something, but you have no idea what it +is. You have to be sure that this is actually representing a SNARK verifier and +that if I give you a SNARK, then you can actually verify the SNARK with that +garbled circuit. So, you essentially need another SNARK to verify that this +garbled circuit is actually representing the circuit that I claim. And, yeah, +proving 500 GB of garbling tables is extremely expensive. And usually, in the +SNARK/STARK world, we can just outsource computation. We can just rent huge GPU +clusters, and most of these big proving companies, like RISC Zero and SP1, they +have optimized all of that, and it's essentially their business model to sell a +compute to people. + +However, here we have the problem that we are computing on private data. If I +give that garbled circuit, including that secret, to a proving service, then I +have to tell them my secret, essentially making them a trusted party. So, we +don't want that. And in particular, we don't want all operators to use the same +proving service because then it would become a single source of failure; all +operators would now have to trust that one proving service to not leak their +secret. So, we would like proving to be efficient enough that every operator +can just do it on their own computer. And this is where the entire complexity +starts. How do we make these garbled circuits efficient enough such that you +can easily prove them as an operator who doesn't want to invest more than, I +don't know, $2,000 or $5,000 or something? And this is essentially the research +problem that everybody's working on right now. And there are different ways to +do that. + +A very interesting result that we had was from Citrea, from Hakan, the Head of +Research at Citrea. He figured out a way to change the transaction graph such +that we can have a one-time setup. So, we just need a single setup for +arbitrary many peg-ins. That's already changed quite a lot, because even if the +setup is quite expensive and takes let's say a month or even two months, it +would be kind of viable because we have to do it only once and then we can use +it forever for arbitrary many peg-ins, and that would be kind of okay-ish. So, +that would be a solution, even of course a painful solution, but at least it +would be practical to some degree. And, yeah, then there are all kinds of other +solutions or other approaches that people are exploring. + +The Bitvm3 solution that I published is based on RSA, and it has a couple of +cool properties. First of all, you can essentially send the circuit in plain +text, and then the challengers can just verify it in plain text. And then, you +can re-blind it very cheaply such that you only have to prove that the +re-blinding was correct, and they still know that the underlying structure is +the same that they verified in plain text. And this kind of bypasses the most +expensive part, namely the proving. You don't have to prove the correctness of +the circuit anymore. You don't need a zero-knowledge proof anymore to prove the +circuit, you just give the circuit in plain text and they convince themselves +that that circuit is actually correct. And in the naive solution, that's +roughly 5 TB. The good thing is that this 5 TB would be for arbitrary many +re-blinding, so it's just a one-time cost, but it's still 5 TB, and that's a lot +of data that every operator would have to send around. Also, every challenger +would have to store these 5 TB, and then it becomes quite expensive. + +There's a solution for that. I'm working on a solution for that, or I think I +found a solution for that, I guess, is the most correct way to put it. And +that's essentially about reusing subcircuits. You have a subcircuit in +particular for feed multiplications, because a SNARK verifier is essentially +roughly 30,000 feed multiplications. So, if you would have a subcircuit for feed +multiplication, you can just reuse it 30,000 times and that would reduce the +circuit size by roughly a factor of 30,000. And that is indeed possible with +that garbled circuit approach. I think I found a solution for that, or I did +find a solution for it, but I don't have a security proof yet, so it might be +broken. I'm not entirely sure if that optimization works, so I don't want to +promise too much, but it seems quite promising. And so far, nobody was able to +break it. But the only problem might be that I haven't shown it to people who +are smart enough to break it. So, I don't want to promise too much, but it's +definitely a very exciting area of research, or direction of research. And this +would bring the entire circuit size down to 2 GB, and that would essentially +solve the communication problem and the proving problem at the same time. + +Also, just to mention the other directions that other people are working on, +Jeremy Rubin came up with an idea he calls delbrag, 'garbled' spelled backwards, +'delbrag', That is essentially an optimistic way of verification. You just +claim that your circuit is correct, but you also commit to a taproot, which +essentially encodes every gate of the circuit. And if any of the gates is +incorrect, then you can disprove them onchain. However, that is reintroducing +the problem of the collateral, because you have to execute a transaction that is +roughly on the size of 100 kB, or something, to make this disprove. So, you +have to put up collateral again to execute a 100-kB transaction, or to be able +to execute a 100-kB transaction if somebody is lying. So, that's not optimal. + +Then Liam Eagan, he is working on a thing called designated verifier. Usually, +a SNARK is such that I publish a SNARK and then everybody can verify it +independently. He's using a designated verifier, where just verification is +essentially permission; you have a permission set of verifiers who can verify +the SNARK. That is of course a drawback, but you gain a lot from that because +the circuit becomes much simpler. It's a 1,000-times or 10,000-times simpler +circuit when you have these designated verifiers. And the other solution is cut +and choose, which is essentially I don't send you one circuit, I send you like +50 circuits, and then you just open some of them, or you ask me to open some of +them, and then you just keep the remaining ones. And that is essentially the +most simple way. But of course, it comes at the expense of more communication +complexity, but the verification becomes quite cheap. And, yeah, if you're +willing to just send a lot of data around, then this is the most simple approach +and it's relying on the least complex cryptography. + +**Mike Schmidt**: Murch, I saw you were going to say something there. + +**Mark Erhardt**: Well, I tried. But I was wondering. So, SNARKs, I think the +first time I heard more about SNARKs was with Zcash and famously, their setup +required a trusted setup and it required numerous parties to promise that at +least one of them actually destroyed their secret data that they contributed. +Do I understand right that this SNARK setup would not have that sort of trusted +setup, but rather it's basically transparent and everybody just verifies that +the circuit is correct. + +**Robin Linus**: No. This is another level of complexity, like what particular +proof system are you using? And you're right that sometimes SNARKs is used as +the umbrella term, but others use it as SNARKs, and then there are STARKs, and +the 'T' in STARKs are the transparent SNARKs. They have a transparent setup, +which requires no trusted party. Yeah, there is that huge trade-off, like +SNARKs are much, much smaller. Just to give you an order of magnitude, SNARKs +can be as small as 128 bytes can prove arbitrary complex statements, like +constant size. No matter how complex your statement, it's always 128 bytes, so +just two Bitcoin signatures, which is quite miraculous actually. And STARKs, +the transparent version, they're different sizes and you can compress them to +multiple degrees, but they are roughly on the order of, even if you compress +them a lot, 50 kB. So, they're almost 1,000 times larger. + +**Mark Erhardt**: So, could you just clarify, for the setup of BitVM3 that you +described now, would that be a trusted setup? You said that there's the worry +about not revealing the secret to the big computation provider? + +**Robin Linus**: Oh, that's two levels here, right? We have on the one hand the +proof system, and in general we have that question, are we using a proof system +with a trusted setup, or are we using a trustless setup? And this is in general +the question, like how big is the data that you have to inscribe into the chain +when you want to publish that proof? And then, there is the question about the +garbled circuit, and the garbled circuit can be completely trustless, so it +doesn't introduce another trusted party. Of course, you can outsource it to +some proving service, and so on, then you would introduce a trusted party, but +we are working on solutions that they would be completely trustless. But to use +that trusted version of SNARKs, or these STARKs, you would have to use bigger +assert transactions, and they would become roughly by a factor of 1,000 bigger. +So, that's essentially not possible, because a SNARK is already 50 kB and if you +would increase it by a factor of 1,000 -- + +**Mark Erhardt**: Yeah, you'd have to buy 50 blocks of data, or something, and +that sounds prohibitive in cost, or depending if you can put it in witness data +and split it up less obviously. If it all has to be one chunk, it just doesn't +fit. + +**Robin Linus**: Maybe you can do some tricks, like these STARKs, they do +multiple queries and you can add some proof of work (PoW) essentially to it. +And if you spend like, I don't know, $50,000 on PoW, then you can do way, way +fewer queries; instead of 50 queries, you can get away with like 7 queries, or +something, and then your proof becomes proportionally smaller. And then, you +might be able to fit it into a single block. But yeah, it becomes much more +expensive to generate the proof. + +**Mike Schmidt**: Wild. It sounds like there's still research to be done here. +This is a fairly leading-edge or bleeding-edge sort of research that you and +some of your, I guess, peers in the BitVM space are working towards. I feel +like I even understood some of what you said today, so I think you did a good +job of explaining it, Robin. What's the call to action here? I guess if folks +are using some flavor of BitVM and want to be familiar with the latest, I mean, +your post basically references BitVM3 and Jeremy Rubin's paper, so I guess folks +should be familiar with that. I assume all of the other participants in the +Alliance are also already all familiar with these discussions as well. What +else would you have people do? + +**Robin Linus**: We have quite an active Telegram channel. I think it's called +bitVM_chat. You can join it and people are always happy to geek out about +garbled circuits, BitVM and Bitcoin Script in general. + +**Mike Schmidt**: Okay, awesome. Anything else on your side, Murch? Alright, +Robin, thanks for joining us yet again. We really appreciate your time and you +coming on and chatting with us about these. You can imagine Murch and I trying +to go through this without you. + +**Robin Linus**: Thanks again. + +_Channel rebalancing research_ + +**Mike Schmidt**: Our final news item this week is, "Channel rebalancing +research". René, you recently posted to Delving Bitcoin about your latest +research and associated notebook titled, "A Geometric Approach to Optimal +Channel Rebalancing", and this research builds on some of your earlier work on +payment channel networks, and also explores whether globally-coordinated +liquidity replenishment could improve LN routing success, especially, and you +get into it in your post, if you start with a heavily depleted LN setup. René, +maybe you can walk us through your optimization approach and what results may +imply for folks operating LN nodes? + +**René Pickhardt**: Yeah, sure, of course. So, as most people will probably +know, for the last year, I have been working on a mathematical model, a +mathematical theory of payment channel networks. And most of the time, the +results that I've provided were basically limitations showing boundaries of what +is possible on the LN. This new result is actually a much more positive result, +as it shows what we can actually achieve with these techniques. For many years, +I think people had the intuitive understanding that routing and liquidity +management are somehow connected problems. And now, with this mathematical +theory of payment channel networks, we have the tools to actually express these +problems with the same mathematical formulation and just see that there are two +sides of the basically same metal. + +The main idea that people have been doing previously is to say, if their +channels deplete, maybe we can do a circular rebalancing. Not everybody pursues +these ideas. I have to say some people prefer to play with fees or to play with +control valves of limiting their max_htlc size, but some people are trying to +basically do offchain rebalancing by sending sats on a channel where they have a +lot of liquidity, in a circular fashion through the network to themselves, to a +channel where they don't have enough liquidity. And this game of circular +rebalancing has this problem that when I rebalance my channels, I might +unbalance some other people's channels, and vice versa, of course. So, we're +all playing against each other. What has previously been discussed on this +podcast was that also in routing, the selfish behavior is actually one of the +reasons why the network depletes so heavily. And while depletion in itself is +not limiting the fact of whether a payment can be conducted between two nodes, +it makes it much harder for sending nodes to find the route. So, as a node +operator, what you could do is you could try to undeplete those channels, which +improves the reliability of those payments that are actually possible and +feasible on the network. + +So, what this framework does is it looks at this channel replenishment problem, +but not in the manner of circular rebalancing, but it looks at what happens if +all the nodes would coordinate in order to find that liquidity state that is +most beneficial for all the wishes of all the wishes of all the node operators. +And the wishes can be announced by the node operators themselves. So, in this +notebook, I just used the same wish from every operator which was, "Please do a +50-50 balance split on all channels", but that does not have to be the case; I, +as a node operator, could observe my channels and be like, "Hey, on this +channel, I always want full liquidity; on that channel, I really don't want +liquidity". And all those node operators could announce their wishes, and then +you use the math to basically compute the liquidity state that is geometrically +closest to the wish that is announced by all of the node operators. + +What I could show is that there are substantial improvements in liquidity if +you, for example, take this 50-50 balance split wish, and it is actually +possible to achieve states that are very close to the desired state for +everyone. + +**Mike Schmidt**: Is the benefit here for folks sending? You're talking about +node operators sort of expressing a preference and then getting together and +reorganizing liquidity accordingly. I assume that's for the benefit of routing +payments, or how do you decide the success? You have this 50-50 split in +liquidity, but are node operators also wanting to capture fees, for example, or +how do you factor in the bigger picture node operator wishes? + +**René Pickhardt**: The main problem that we see on the LN is if a sending node +wants to send out a payment, they have to make several attempts to actually +deliver the payment. And one of the main reasons is that in their path +selection, they occasionally select channels that are depleted. And when they +do so, what this means is that the node operators on this path cannot earn the +fees, even though they may have the liquidity, because downstream, one node +operator doesn't have the necessary liquidity to complete the payment. And fees +on the LN are only paid if the payment successfully is being routed. So, if +node operators increase the reliability of their node, what this means is that +they actually earn the fees when the payment requests are being made through +them, so this is one advantage to the node operators. + +Another advantage is if you look at channel depletion, channel depletion usually +occurs because there's high demand in those channels. When you do reverse +logistics and a channel replenishment protocol, you basically reverse the +natural flow through the network. As we have discussed last time in the +podcast, usually within cycles, there is a natural rotation, which means the +liquidity is always towards one end of those channels in a cycle. So, for those +node operators, economically, it may make sense to undeplete those channels, +because there's already a lot of demand in the other direction. But since many +channels are part of many different circles, it's sometimes not so clear how to +do that. And this is where my research basically starts to ask the question. +So, instead of identifying three cycles where I'm in and identifying the +rotational flow in those cycles, I can just observe my channel and be like, +"Hey, usually on this channel, I like that, and other people can care for their +own channels". + +So, I want to reiterate on the fact that while in the research, because it's a +simulation, I use this 50-50 split; it does not have to be that 50-50 split. It +could actually be depletion in the exact opposite direction, because you see, +"Hey, I always want full liquidity on that channel", which would mean if +occasionally a payment would go in the other direction, well, yes, then the +channel was depleted. But usually, a node operator would only want that +liquidity on that side if the channel has a certain direction in which routing +requests are coming in. + +**Mark Erhardt**: So, it sounds like you would want to find a route where every +party wants the funds to move in one direction, and then everybody would improve +their local liquidity, and that would make every party participating in the +routing happy. But of course, channel balances are private by design and it's +an important property of the LN to keep the channel balances at least fuzzy and +maybe not transparent at all times. So, how would people know where to find the +liquidity for these multi-benefit rebalancings? + +**René Pickhardt**: Yes, so I mean that is one of the problems. I mean there +are several issues with this approach that I think I also mentioned in the blog +article. The nodes that coordinate on this, the easiest way for them to do this +was if they would share their liquidity information, in particular to also solve +the math problem of how to optimally distribute the liquidity among the nodes. +You could have a lightning service provider that manages liquidity for many +nodes and could be a central coordinator. That wouldn't be a part of a protocol +solution, but nobody would prove it. It's similar to the discussion that we had +about discussions on Bitcoin Core, whether they should be privatized or not. I +mean, you cannot forbid people to create services like this. So, you could have +a central coordinator who gets the liquidity information, solves the problem for +the nodes, and basically tells the nodes where to rebalance with whom. This +network of nodes would be a highly reliable subnetwork of the LN. + +**Mark Erhardt**: Could it be possible, usually when you make payments, you +indicate you want this to happen right now, you offer fees, and so forth, that +you sort of have a, "Please only participate in this payment if it's to your +benefit", type of payment offer. And then, you could just shoot out proposed +cycle rebalancing, where every party does not take fees and they only +participate if it's to their benefit. And since you're not really time-pressed +to get it done and you're just looking around, "Hey, would that be a more +private variant?" Well, it is sort of like probing, but it would just be cycles +to yourself where you ask, "Hey, is this to your benefit too?" and then, +"Participate, please". + +**René Pickhardt**: I mean, yes, you could think of something like this to +improve privacy. I mean, the main issue and problem here, if people decide that +they are interested in a solution like this, is how to make this as a +distributed protocol. A solution like yours would certainly be interesting. +And one of the benefits of this particular research is that with this research, +we know the gold standard and how good the best solution is, so that if we would +try an approach like yours, Murch, we could test how close to the optimal +solution is your approach, right? So, if for example, I mean I'm just making up +numbers, your approach would be, let's say 99% accurate. Well, I mean that is a +really, really good solution, right? And we could know this because we would +know the optimal solution, at least in a simulation. + +But I have to make one thing clear here. The idea of this rebalancing is not to +do it in single cycles. So, if I am a node, what I could do is I could say, +"Hey, I'm sending out 100,000 satoshis on three channels. I'm receiving 300,000 +satoshis on another channel. I'm sending out another 200,000 satoshis on the +next channel". The only thing that has to happen is that all those numbers add +up to zero; I have to receive as many sats as I'm sending out. But the way how +I'm doing this is not in single cycles anymore. So, even the solution that I +provide, dissecting it into cycles is non-trivial. + +**Mark Erhardt**: Right, because there's of course a huge degree of complexity +here, because every node has many different channels and you basically want to +cherry-pick out of many, many different channels which ones should participate, +because they're all moving in the same direction. So, you do need a good +overview of the local network. Maybe there's a smart, cryptographic, +zero-knowledge sort of approach where people can dump their information and it +drops off routes without telling anyone the actual balances. But for the time +being, it sounds like the theoretic optimum would require full transparency. + +**René Pickhardt**: Yes and no. I mean, one solution that is somewhat in the +middle is that you could basically announce, "These are my 100 channels, and on +those 50 channels, I want that many sats of liquidity inbound; and on those +channels, I want that many sats outbound, and this is my wish for rebalancing". +This doesn't tell you, "Oh, yeah, the channel is empty and this is everything". +I mean, of course, if you want the full liquidity, the full capacity, then it +tells you the channel is empty and you want to have it full again. But you +could basically choose those numbers. I mean you're not guaranteed that you get +those numbers. In this optimal solution, it could even be that for a single +node on a single channel, the situation becomes exactly against their wish, +because it's overall still the closest solution to the global problem. That +being said, it's highly unlikely because the wishes of the operators should +somehow naturally go towards each other. And even if that happens locally, I +mean as soon as a channel is depleted, you would re-trigger the replenishment +thing, and then you would get some liquidity back. + +**Mark Erhardt**: There has been a lot of talk in the past about upfront fees. +I was wondering, you said currently channels only get paid when the payment goes +through and that's a problem. With upfront fees, there will be a very small, +but a small payment to even participate just in an attempt. Do you think that +that would help with the situation, because (a) there's more financial incentive +to pick the best route first; and (b) it provides a little bit of money in a +channel in the direction that you want more liquidity in the future? + +**René Pickhardt**: Yeah, so I don't have a good answer to this, to be frank. +If you look at how I have conducted my research in the past, I have studied the +routing problem quite a bit and now the liquidity management problem. And one +particular area that I haven't studied well yet is the fee problem, like +generally how to choose fees, what is the dynamics there, how is everything +happening. I know that there's a lot of game theory involved there and it is my +understanding that upfront fees would certainly change certain things and +incentives. For me it's not even clear that the upfront fees stay tiny. I +mean, I do understand that currently the idea of the upfront fee is to be tiny, +but that doesn't have to be the case. You could make it larger. I mean, as +soon as you have it in the protocol, nobody forbids you to charge a high upfront +fee and make the other fee tiny. So, yeah, I don't know how upfront fees would +really change the dynamics here. + +Of course, if upfront fees are being charged, I would assume that users would +expect routing notes to have the liquidity. I mean, if I pay you upfront, I +would expect you to deliver my payment. So, given that we go in the direction +of upfront fees, if I was just the user, I'd be like, "You'd better provide +reliability". + +**Mark Erhardt**: Sure, but that doesn't make any promises about the +further-down-the-route hops. I mean, I might take the upfront payment and have +the liquidity, but the next hop might not. + +**René Pickhardt**: They took the fee and should have the liquidity, right? + +**Mark Erhardt**: Sure, but I still pay all the hops before the hop that doesn't +have liquidity. + +**René Pickhardt**: True, yeah. So, what I'm basically saying is, I don't even +know if users would adopt to an upfront-fee setting if the reliability in the +network is not much higher, because it's a gamble. I mean, if every hop is a +50-50 chance, because almost half of the channels are being depleted, then it's +really hard to make the case for upfront fees, unless you do a probabilistic +setting where you say, "Yeah, I expect to pay that many upfront fees for +nothing". + +**Mark Erhardt**: Yeah, I guess. + +**René Pickhardt**: But as I said, I haven't studied it properly, right, so I +mean I shouldn't speculate around this. + +**Mark Erhardt**: I also need to correct myself. Upfront fees would not move +fees in the channel that doesn't have sufficient funds. They would move fees in +the channel before that. So, I was incorrect in my prior statement. So, back +to your actual main research. You say that it is computationally very expensive +to find these rebalancing multi-benefit situations and it requires a lot of +data. So, what is your current situation? I think you're saying you'd like +input on whether this is worth pursuing? + +**René Pickhardt**: Yes. So, I think the main question that I'm putting out to +the community is, we know that we have reliability issues on the LN, and we do +have some ways of how to mitigate them. Roughly a month ago, I put out a post +to Delving Bitcoin where I showed all the various approaches that exist. Some +of them include severe protocol changes; some of them are more applications on +the LN; some of them are more best practices; some of them are maybe +philosophically wanted, some of them not. What I can show here is that the +general idea of offchain channel rebalancement certainly does make a difference. +It improves the LN in the sense of, right now when we try to make a payment and +we can't deliver the payment, we don't know if the network doesn't have enough +liquidity in general to deliver the payment, or if we have just hit depleted +channels all the time. If you apply my results and a payment fails, the +likelihood that the network is just not able to provide enough liquidity is much +higher. So, then we could actually do an onchain transaction to fix this, +right, so we would have much better semantics of why a payment really fails. + +So, we know that this approach is helpful for the network, but it's really, +really hard to make a decentralized protocol out of this. We could try to do +that, but if people then say, "Yeah, we don't want to go in this direction +anyway for other reasons", well, then we shouldn't, right, because it's hard by +itself anyway. So, this is one of the questions, and this is something where I +would really love to have community input because, I mean of course, I can now +spend half a year to try to come up with a reasonable protocol. But given that +we already know the trade-offs at this point, I think it would be much nicer if +there was some feedback of, "Is it worthwhile pursuing or not?" And then, it's +still not clear if we can find a decentralized protocol that is very close to +the optimal solution, because the optimal solution currently only works with +perfect coordination or a central coordinator, which is perfect coordination. + +**Mike Schmidt**: That sort of leads into my usual wrap-up question, which +you've sort of already answered, which is calls to action for the community. +You've outlined some questions here. You have three also in your Delving post, +open questions for the community. So, I would encourage folks to take a look at +that if they're interested in the topic. There's also the notebook and +associated code for folks to experiment with. So, if folks are curious about +this topic, there's plenty of content and code and simulations to dig into. +Anything else you'd add, René? + +**René Pickhardt**: I'd highly encourage LSPs and node operators that do not +only operate one node to try these ideas with their network of nodes. Because +the general gist with this is, if you control a sub-network of the LN, this +network could be much more reliable than the rest of the LN if you apply these +research results to your own subnet of nodes. Of course, if the entire network +would adapt, this would be even more beneficial, but it can be adapted by a +subsection. And I mean, this would improve the service of those LSPs, but it +would also improve the overall reliability of the network. So, yeah, from that +perspective, I highly encourage people who run nodes to take a look at these. +And if you have feedback and questions, of course, you can always reach out. As +long as I'm able to open-sourcely talk about stuff, I mean, I don't have to +mention your name or so, but I mean, I'm doing research on the open-source side. + +**Mike Schmidt**: Thank you for your time, thank you for hanging on for your +news item later in the show, René. We appreciate that. We understand if you +have other things to do and need to drop. + +**René Pickhardt**: Thanks for the invitation and for all the work that you're +putting in communicating all the updates. + +**Mike Schmidt**: Appreciate that, René. Thank you. We have our monthly +segment on Changes to services and client software next. It was a slower month +compared to previous months. I think we've been in the 10 to 12 range. We have +four pieces that we're highlighting this month. + +_Cove v1.0.0 released_ + +First one, Cove v1.0.0 is released. Cove Wallet in its recent releases, I think +it was 0.5 and 0.5.1, included features around coin control support and also +BIP329 wallet label features. Murch, other than being proud of me for not +linking to the coin selection topic because this is coin control, any thoughts? + +**Mark Erhardt**: No. I just looked a little bit at the release notes and it +looks like this wallet is moving pretty quickly. There have been something like +four releases in the past month. So, they seem to be picking up their features. +I haven't looked too much into it though. + +**Mike Schmidt**: Yeah, there's a lot of good Bitcoin tech in there already, and +I think there might have been a page on their GitHub that also outlines things +to come. So, maybe check out that wallet if that's something that you're +interested in toying around with. + +_Liana v11.0 released_ + +Liana v11.0 released. We covered many of the Liana early versions, but it's +been a while since we covered Liana recently. So, in a few of their recent +releases, Liana included multi-wallet support. They also included additional +coin control features, additional support for hardware signing devices, and +other features as well. So, definitely if you haven't looked into Liana in the +last many months or years since we talked more about them, check out what they +have going on. + +**Mark Erhardt**: I see that coin control features and coin selection features +are very popular again. And I would remind people that recently, we've been +seeing a few transactions get confirmed below 1 sat/vB (satoshi per vbyte) on +the network. So, it looks like at least two mining pools are now not even +enforcing minimum relay transaction feerates. So, if you are looking to +consolidate, you might even be able to do so at low feerates. And that's +especially relevant in the context of wallets like Liana, where after some time +out, the security of your UTXOs degrades, or not degrades, but falls back to +lower security levels on purpose, and you might want to move your coins +occasionally. So, filters like being able to filter by a minimum confirmation +amount or a confirmation count can be very useful to make some targeted +consolidation transactions and refresh. + +**Mike Schmidt**: And we actually get into a BTCPay Server later on that has +added those exact features to filter for UTXOs based on certain criteria. + +_Stratum v2 STARK proof demo_ + +Stratum v2 STARK proof demo. StarkWare demonstrated a modified Stratum v2 +mining client that actually uses a STARK proof to prove that a block's fees +belong to a valid block template, without revealing the transactions in the +block. So, Stratum v2 does have this ability for you to not disclose the +transactions that you're mining on, if you're mining under the Stratum v2 +protocol. But my understanding, it was an open problem of whether those blocks +fees' associated with those transactions. And so, that was sort of an open +problem that Stratum v2 folks had somewhere in their repository. And now, the +StarkWare folks have actually done essentially a zero-knowledge proof to prove +that those fees are part of a valid block template without revealing the +transactions, which seems cool. + +**Mark Erhardt**: Yeah, I think so far, the solution was that the mining pool +would have to sample a share occasionally from the miner, randomly say, "Oh, you +just submitted a share, please show me that one". And then, would have to check +that all of the transactions listed in the template are available and accurately +represented, and that the coinbase transaction is valid. And that would incur a +large overhead for the mining pool. So, being able to prove in a succinct proof +that your block is valid and the fees you're stating are correct, would probably +make it both more efficient and more reliable for mining pools to offer this. + +_Breez SDK adds BOLT12 and BIP353_ + +**Mike Schmidt**: Last piece of software this week, Breez SDK adds BOLT12 and +BIP353. Breez SDK has a couple of different variations. This is specific to +the nodeless variant. And in 0.9.0, that nodeless variant added support for +receiving using BOLT12 offers, and also support for BIP353, which is DNS payment +instructions, which specify human readable names, which is cool, I love that. +And the nodeless variant of Breez SDK actually uses the liquid network sidechain +to facilitate some of their operations. + +**Mark Erhardt**: Yeah, I remain very excited about sort of the contact book +without address reuse coming to Bitcoin payments with BIP353, BOLT and silent +payments. You can repeatedly pay people without reusing addresses and, yeah, it +pops up everywhere, it's great. + +_Core Lightning 25.05_ + +**Mike Schmidt**: Yeah, it's a nice usability enhancement. Releases and release +candidates, we have Core Lightning 25.05. I pulled out a few notable things +that I'll just go through quickly, and then point to the podcast with Alex. The +first one is that commit and revoke message handling is now faster, meaning +quicker payment settlement and more responsive channels. Also, the reckless +plugin can now auto update any plugins that are already installed via reckless +update, which makes plugin management easier. There's also additional +functionality for splicing interoperability with Eclair, and splice RBF +features. Core Lightning (CLN) has also added peer storage, which went from an +experimental feature to default, which improves peer reconnection and latency +associated with that. Also, improved anchor fee calculations, a fix to askrene +routing when using high-capacity channels, and officially, this will be my last +time that I point to our #355 Recap Podcast with Alex Myers, that he and Dave +went into more in-depth with these features. So, I figured I'd give a shout out +since the release is official. Let's still check back to Alex talking about +some of this. + +**Mark Erhardt**: I also thought that the name of this release is very funny, +"Satoshi's OP_RETURN Opinion"! And I noticed that one of the new contributors +to CLN in this release is a familiar name. Jiri Jakes, our Czech translator for +the Optech Newsletter, appears to have contributed to this release. So, that's +cool. + +_Eclair #3110_ + +**Mike Schmidt**: Oh, that's awesome. Yeah, I didn't pick up on that. Cool. +Notable code and documentation changes. Eclair #3110 is a PR titled, "Increased +channel spent delay to 72 blocks". So, previously Eclair would wait just 12 +blocks before considering that a channel was closed after its funding output was +spent. But a change to the splicing specification now recommends 72 blocks, so +that a splice can propagate the network. T-bast actually noted in that BOLTs +PR, changing that to 72 that, "The channel can keep its history in path finding +scoring/reputation, which is important". So, they want to keep the continuity +of the channel, even if you're splicing in funds. And so, that's why they +increased that to 72 blocks. And similarly, echoed in the draft release notes +for this PR is, "When we detect that a remote channel has been spent onchain, we +wait for 72 blocks before removing it from the graph. If it was a splice +instead of a close, we will be able to simply update the channel in our graph +and keep its reputation". + +_Eclair #3101_ + +Eclair #3101 adds a parse offer RPC, so that Eclair users can read the BOLT12 +offer amount among other fields. Eclair also allows paying offers with a +currency other than BTC. In the tests that I saw as part of this PR, for +example, euros was included as the currency that was used. I don't exactly +understand how that mechanism works, but it was mentioned in our write-up as +well as the PR and is in the test. So, I don't know how that conversion works. + +**Mark Erhardt**: Yeah, that sounds curious. How would the exchange rate be +calculated on the fly and agreed upon? So, anyway. + +**Mike Schmidt**: Maybe we can dog-ear that for the next time we have t-bast on, +which has been a while. Usually, we have them on fairly regularly. + +_LDK #3817_ + +LDK #3817 rolls back support for attributable failures, that we covered in +Newsletter and Podcast #349 when they were originally put in. And the author of +this PR noted that, "Until a sufficient number of nodes on the network has +upgraded, it's not possible to use attribution data to assign blame. Otherwise, +nodes that have not upgraded yet would already receive penalties". + +_LDK #3623_ + +LDK #3623 is part two of LDK's peer storage features, adding new peer storage +features to LDK. Previously, LDK would store peer data and send the data back +when reconnecting. With this VR, LDK will now also send peer storage +information to all channel peers whenever a new block is mined. And there's +also logic to decrypt peer storage based on requests from a peer. There are +also further PRs planned around peer storage to come as well, as indicated in +the PR discussion. + +**Mark Erhardt**: Every block? Do you remember how much the peer storage was +allowed to be? It was like a few kB, or so? + +**Mike Schmidt**: The size? Yeah, I don't recall. + +**Mark Erhardt**: Well, so if it's like 10 kB and we have 144 blocks, that's, +well, still only a little more than an MB. Never mind, that's fine, but just +interesting! + +_BTCPay Server #6755_ + +**Mike Schmidt**: BTCPay Server #6755 is a PR that, "Enhances the coin selection +interface in the wallet by introducing advanced filtering options and improving +usability". Obviously, they meant coin control interface, although they are +doing manual coin selection, I guess is fine. So, there are now filters in +BTCPay Server for minimum amount, maximum amount, and creation date of the UTXO. +I saw the interface, they had a nice video in the PR that showed there's +essentially a text box, and that text box will parse these different filter +syntaxes, and then the resulting UTXOs will show up in a table below. + +_Rust libsecp256k1 #798_ + +Rust libsecp256k1 #798. So, I don't think we've covered Rust libsecp256k1, but +it is a wrapper around secp, the cryptographic C library that we cover more +often in the newsletter. And this PR addresses a bunch of follow-ups around +that wrapper's library's MuSig2 implementation, and officially completes Rust's +secp implementation of MuSig2. So, there was a follow-up PR before this one, +and then there was the original implementation, but they are now calling this +the official support for MuSig2 in Rust secp. + +**Mark Erhardt**: So, that means of course, is BDK using Rust secp probably, and +probably LDK? So, it sounds like this will downstream and we'll get all of that +stuff eventually also in the SDKs for Lightning and wallets. + +**Mike Schmidt**: The exciting thing when BDK originally came out is that these +sorts of things would be proliferated, these pieces of Bitcoin tech would roll +out a little bit quicker, because you wouldn't have all these different hundreds +of wallets having to implement it, right? So, yeah, if it gets in BDK and folks +use it, you'll get to see more adoption. + +**Mark Erhardt**: Yeah, well, it's only been, what is it now, three-and-a-half +years since taproot, so good to see MuSig2 support roll out to that extent. +There's now also BIPs for descriptors with MuSig2 and key derivation with +MuSig2. PSBT v2 is getting more adopted. We are seeing some hardware wallets +implement support. Maybe we'll get music to channels eventually on LN. So, +we'll see. It'll get there eventually. + +**Mike Schmidt**: We want to thank our guests this week, Bryan Bishop, Robin and +René for joining us. Murch, thanks for hosting this week and for you all for +listening. + +**Mark Erhardt**: Hear you next time. {% include references.md %} From 4f80488487a72a4ad8ff40a6f07c4077719a006f Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Tue, 1 Jul 2025 20:39:14 -1000 Subject: [PATCH 139/278] Newsletters: add 361 (2025-07-04) --- .../en/newsletters/2025-07-04-newsletter.md | 441 ++++++++++++++++++ 1 file changed, 441 insertions(+) create mode 100644 _posts/en/newsletters/2025-07-04-newsletter.md diff --git a/_posts/en/newsletters/2025-07-04-newsletter.md b/_posts/en/newsletters/2025-07-04-newsletter.md new file mode 100644 index 0000000000..21c43e061b --- /dev/null +++ b/_posts/en/newsletters/2025-07-04-newsletter.md @@ -0,0 +1,441 @@ +--- +title: 'Bitcoin Optech Newsletter #361' +permalink: /en/newsletters/2025/07/04/ +name: 2025-07-04-newsletter +slug: 2025-07-04-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter describes a proposal to separate the network connections +and peer management used for onion message relay from those used for +HTLC relay in LN. Also included are our regular sections summarizing +discussion about changing Bitcoin's consensus and listing recent changes +to popular Bitcoin infrastructure software. + +## News + +- **Separating onion message relay from HTLC relay:** Olaluwa Osuntokun + [posted][osuntokun onion] to Delving Bitcoin about allowing nodes to + use separate connections for relaying [onion messages][topic onion messages] than they + use for relaying [HTLCs][topic htlc]. Although separate connections may + currently be possible, such as in the case of direct relay (see + Newsletters [#283][news283 oniondirect] and [#304][news304 + onionreply]), Osuntokun suggests that separate connections + should always be an option, allowing nodes to have a different set of + peers for onion messages from the set of peers they use for relaying + payments. He makes several arguments in support of this alternative + approach: it more clearly separates concerns, nodes can cheaply + support a greater density of onion message peers than channel peers + (as channels cost money to create), separation may allow deployment of + privacy-improving key rotation, and separation may allow faster + delivery of onion messages due to not being blocked by the + HTLC commitment communication protocol. Osuntokun provides specific + details about the proposed protocol. + + A concern of several replying developers was how the network for onion + messages could allow + nodes to be flooded by an excessive number of peers. In current + onion message implementations, each node only typically maintains + connections with its channel partners. Creating the UTXO to fund a + channel costs money (onchain fees and opportunity cost) and is unique + to the node and the channel partner; in short, it is + one-UTXO-one-connection. Even if onion message connections had to be + backed by onchain funds, a single UTXO could be used to open + connections to every public LN node: one-UTXO-thousands-of-connections. + + Although at least one respondent was supportive of Osuntokun's + proposal, several respondents so far mentioned concern about the + denial of service risk. Discussion was ongoing at the time of + writing. + +## Changing consensus + +_A monthly section summarizing proposals and discussion about changing +Bitcoin's consensus rules._ + +- **CTV+CSFS advantages for PTLCs:** developers continued a previous + discussion (see [Newsletter #348][news348 ctvstep]) about the benefits + of [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (CTV), + [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (CSFS), + or both together for various deployed and imagined protocols. Of + particular interest, Gregory Sanders [wrote][sanders ptlc] that CTV+CSFS "would + accelerate updating [LN] to [PTLCs][topic ptlc], even if [LN-Symmetry][topic eltoo] per-se + is never adopted. Re-bindable signatures just makes life so much less + of a headache when stacking protocols." Sjors Provoost [asked][provoost ptlc] for + details and Sanders [replied][sanders ptlc2] with a [link][sanders gist] to his previous + research into LN messaging changes for PTLCs (see [Newsletter + #268][news268 ptlc]), adding that "PTLCs on today's protocols [are] by + no means impossible, but with rebindable signatures it just gets + significantly simpler." + + Anthony Towns additionally [mentioned][towns ptlc] that "there’s also a lack of + tooling/standardisation for doing a PTLC reveal in combination with a + [musig][topic musig] 2-of-2 (which would be efficient on-chain), or even general + tx signatures (ie `x CHECKSIGVERIFY y CHECKSIG`). [...] This would + require [adaptor signature][topic adaptor signatures] support for musig2, and that’s not part + of the spec and was [removed][libsecp256k1 #1479] from the secp256k1 + implementation. Doing it less efficiently as a separate adaptor + signature would work too, but even plain adaptor signatures for + [schnorr sigs][topic schnorr signatures] also isn’t available in secp256k1. These also aren’t + included even in the more experimental secp256k1-zkp project. [...] If + the tooling were ready, I could see PTLC support being added [...] but + I don’t think anyone considers it a high enough priority to put in the + work to get the crypto stuff standardised and polished. [...] Having + [CAT][topic op_cat]+CSFS available would avoid the tooling issue, at a cost in + on-chain efficiency. [...] I think with only CSFS available you + continue having similar tooling problems, because you need to use + adaptor signatures to prevent your counterparty from choosing a + different R value for the signature. These issues are independent of + the update complexity and peer protocol updates Gregory Sanders + describes above." + +- **Vault output script descriptor:** Sjors Provoost [posted][provoost ctvdesc] to + Delving Bitcoin to discuss how the recovery information for a wallet + using [vaults][topic vaults] could be specified using an [output script + descriptor][topic descriptors]. In particular, he focused on vaults based on + [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (CTV), such as those provided by James + O'Beirne's [simple-ctv-vault][] proof-of-concept implementation (see + [Newsletter #191][news191 simple-ctv-vault]). + + Provoost cited a [comment][ingala vaultdesc] from a previous discussion by Salvatore + Ingala that said, "my general take is that descriptors are the wrong + tool for this purpose"---a sentiment Sanket Kanjalkar [agreed with][kanjalkar vaultdesc1] + in the current thread but [found][kanjalkar vaultdesc2] a potential workaround for. + Kanjalkar described a variant CTV-based vault where funds are + deposited into a more typical descriptor and, from there, are moved + into a CTV vault. This avoids a situation that could lead naive users + into losing money and also allows the creation of a descriptor that + assumes all funds paid to the typical descriptor are moved into a vault using the + same settings every time. This would allow the CTV vault descriptor + to be succinct and complete without any contortions to the descriptor + language. + +- **Continued discussion about CTV+CSFS advantages for BitVM:** developers + continued the previous discussion (see [Newsletter #354][news354 + bitvm]) about how the availability of [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (CTV) + and [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (CSFS) opcodes could "reduce + [BitVM] transaction sizes by approximately 10x" and allow non-interactive + peg-ins. Anthony Towns [identified][towns ctvbitvm] a vulnerability in the original + proposed contract; he and several other developers described + workarounds. Additional discussion looked at the advantages of using + the proposed [OP_TXHASH][] opcode rather than CTV. Chris Stewart + [implemented][stewart ctvimp] some of the discussed ideas using Bitcoin Core's test + software, validating those parts of the discussion and providing + concrete examples for reviewers. + +- **Open letter about CTV and CSFS:** James O'Beirne [posted][obeirne letter] an open + letter to the Bitcoin-Dev mailing signed by 66 individuals (as of this writing), + many of them contributors to Bitcoin-related projects. The letter + "asks Bitcoin Core contributors to prioritize the review and + integration of [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (CTV) and + [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (CSFS) within the next six months." The + thread contains over 60 replies. Some technical highlights include: + + - *Concerns and alternatives to legacy support:* [BIP119][] specifies + CTV for both witness script v1 ([tapscript][topic tapscript]) and legacy script. + Gregory Sanders [writes][sanders legacy] that "legacy script support [...] + considerably increases review surface for no known capability gain + and no known savings for protocols." O'Beirne [replied][obeirne legacy] that + legacy script support could save about 8 vbytes in some cases, but + Sanders [linked][sanders p2ctv] to his previous pay-to-CTV (P2CTV) proposal and + proof-of-concept implementation that makes this savings available in + witness script. + + - *Limits of CTV-only vault support:* signatory Jameson Lopp [noted][lopp ctvvaults] + that he's "most interested in [vaults][topic vaults]," starting a discussion about + the set of properties CTV vaults would provide, how they compare to + vaults deployable today using presigned transactions, and whether + they provide a meaningful improvement in security (especially + compared to more advanced vaults that would require additional + consensus changes). Key takeaways from this discussion included: + + - *Address reuse danger:* both presigned and CTV vaults must prevent + users from reusing vaulting addresses or funds are likely to be + lost. One way this can be accomplished is by a two-step vaulting + procedure requiring two onchain transactions to deposit funds into + the vault. More advanced vaults requiring additional consensus + changes would not have this problem, allowing deposits even to a + reused address (although that would, of course, [reduce + privacy][topic output linking]). + + - *Theft of staged funds:* both presigned and CTV vaults allow theft + of authorized withdrawals. For example, vault user Bob wants to + pay 1 BTC to Alice. With presigned and CTV vaults, Bob uses the + following procedure: + + - Withdraws 1 BTC (plus possibly fees) from his vault to a staging + address. + + - Waits the amount of time defined by the vault. + + - Transfers 1 BTC to Alice. + + If Mallory has stolen Bob's staging key, she can steal the 1 BTC + after the withdrawal completes but before the transaction to Alice + confirms. However, even if Mallory also compromises the + withdrawal key, she cannot steal any funds remaining in the vault + because Bob can interrupt any pending withdrawal and redirect the funds + to a _safe address_ protected by an ultra-secure key (or keys). + + More advanced vaults do not require the staging step: Bob's + withdrawal could only go to either Alice or the safe address. + This prevents Mallory from being able to steal funds between the + withdrawal and spend steps. + + - *Key deletion:* an advantage of CTV-based vaults over presigned + vaults is that they don't require deleting private keys to ensure + that the set of presigned transactions are the only spending options + available. However, Gregory Maxwell [noted][maxwell autodelete] that it's simple to + design software to delete a key immediately after signing the + transactions without ever exposing the private key to users. No + hardware signing devices are known to support this directly at present, + although at least one device supports it via manual user + intervention---but it's also the case that no hardware supports CTV even for testing at + present (to the best of our knowledge). More advanced vaults + would share the keyless advantage of CTV but would also require + integration into software and hardware. + + - *Static state:* a claimed advantage of CTV-based vaults over + presigned vaults is that it might be possible to compute all + information necessary to recover the wallet from a static backup, + such as an [output script descriptor][topic descriptors]. However, there has + already been work on presigned vaults that also allow static + backups by storing the non-deterministic parts of presigned state + in the onchain transactions themselves (see [Newsletter + #255][news255 presig vault state]). Optech believes more advanced + vaults could also be recovered from static state, but we had not + verified this by press time. + + - *Responses from Bitcoin Core contributors:* as of this writing, four + individuals Optech recognizes as currently active Bitcoin Core + contributors responded to the letter on the mailing list. They + said: + + - [Gregory Sanders][sanders ctvcom]: "This letter is asking for feedback from the + technical community and this is my feedback. Undeployed BIPs that + have not received any updates in years is generally not a sign of + proposal health, and certainly not a foundation to reject + technical advice from someone who's paid close attention. I + reject this framing, the raising of the bar of changes to this + proposal to only egregious breaks, and I obviously reject a + time-based ultimatum for BIP119 as-is. I still think CTV (again + in the capability sense) + CSFS are worthy of consideration, but + this is a surefire way to sink it." + + - [Anthony Towns][towns ctvcom]: "From my perspective, the CTV discussion has + missed important steps, and instead of those steps being taken, + advocates have been attempting to use public pressure to force + adoption on an 'accelerated timeline' pretty much continuously for + at least three years now. I've tried to help CTV advocates take + the steps I believe they've missed, but it's mostly resulted in + silence or insults rather than anything constructive. At least + from where I sit, this is just creating incentive problems, not + solving them." + + - [Antoine Poinsot][poinsot ctvcom]: "The effect of this letter has been, as could + have been expected, a major setback in making progress on this + proposal (or more broadly this bundle of capabilities). I am not + sure how we bounce back from this, but it necessarily involves + someone standing up and actually doing the work of addressing + technical feedback from the community and demonstrating (real) use + cases. The way forward must be by building consensus on the basis + of strong objective, technical, arguments. Not with a bunch of + people stating interest and nobody acting up and helping the + proposal move forward." + + - [Sjors Provoost][provoost ctvcom]: "Let me also speak a bit to my own motivation. + Vaults appear to be the only feature enabled by the proposal that + I personally find important enough to work on. [...] Up until + quite recently it seemed to me that the momentum for vaults was in + OP_VAULT, which in turn would require OP_CTV. But a single + purpose op code is not ideal, so this project didn't seem to be + going anywhere. [...] Conversely, I don't oppose CTV + CSFS; I + haven't seen an argument that they're harmful. Since there's + little MeVil potential, I could also imagine other developers + carefully developing and rolling out these changes. I would just + keep an eye on the process. What I _would_ oppose is a Python + based alternative implementation and activation client like + co-signer Paul Sztorc proposed." + + - *Signatory statements:* signers of the letter also clarified their + intentions in follow-up statements: + + - [James O'Beirne][obeirne ctvcom]: "everyone who signed explicitly wants to see the + imminent review, integration, and activation planning for CTV+CSFS + specifically." + + - [Andrew Poelstra][poelstra ctvcom]: "Early drafts of the letter did ask for actual + integration and even activation, but I did not sign any of those + early drafts. It was not until the language was weakened to be + about priorities and planning (and to be a "respectful ask" rather + some sort of demand) that I signed on." + + - [Steven Roose][roose ctvcom]: "[The letter] merely asks Core contributors to put + this proposal on their agenda with some urgency. No threats, no + hard words. Given that only a handful of Core contributors had + thus far participated in the conversation on the proposal + elsewhere, it seemed like a suitable next step to communicate that + we want Core contributors to provide their position within this + conversation. I strongly stand against an approach involving + independent activation clients and I think the sentiment of this + e-mail aligns with the preference of having Core be involved in + any deployment of protocol upgrades." + + - [Harsha Goli][goli ctvcom]: "Most people signed because they really had no idea + what the next step ought to be, and the pressure for transaction + commitments was so much so that a bad option (piling of a sign-on + letter) was more optimal than inaction. In conversations prior to + the letter going out (facilitated by my industry survey), I only + received admonishment of the letter from many of the signatories. + I actually don't know of a single person who considered it as an + explicitly good idea. And still they signed. There's signal in + that." + +- **OP_CAT enables Winternitz signatures:** developer Conduition + [posted][conduition winternitz] to the Bitcoin-Dev mailing list a [prototype + implementation][conduition impl] that uses the proposed [OP_CAT][topic op_cat] opcode and other + Script instructions to allow [quantum-resistant][topic quantum + resistance] signatures using the Winternitz protocol to be + verified by consensus logic. Conduition's implementation requires + almost 8,000 bytes for the key, signature, and script (most of which + is subject to the witness discount, reducing onchain weight to about + 2,000 vbytes). This is about 8,000 vbytes smaller than another + `OP_CAT`-based quantum-resistant [Lamport signature][] scheme + [previously proposed][rubin lamport] by Jeremy Rubin. + +- **Commit/reveal function for post-quantum recovery:** Tadge Dryja + [posted][dryja fawkes] to the Bitcoin-Dev mailing list a method for allowing + individuals to spend UTXOs using [quantum-vulnerable][topic quantum + resistance] signature algorithms even if fast quantum computers would + otherwise allow redirecting (stealing) the output of any attempted spend. + This would require a soft fork and is a variation of a previous proposal by + Tim Ruffing (see [Newsletter #348][news348 fawkes]). + + To spend an output in Dryja's scheme, the spender creates a commitment + to three pieces of data: + + 1. A hash of the public key corresponding to the private key that + controls the funds, `h(pubkey)`. This is called the _address + identifier_. + + 2. A hash of the public key and the txid of the transaction the spender + wants to eventually broadcast, `h(pubkey, txid)`. This is called + the _sequence dependent proof_. + + 3. The txid of the eventual transaction. This is called the + _commitment txid_. + + None of this information reveals the underlying public key, which in + this scheme is assumed to only be known to the person controlling the + UTXO. + + The three-part commitment is broadcast in a transaction using a + quantum-secure algorithm, e.g. as an `OP_RETURN` output. At this + point an attacker could attempt to broadcast their own commitment + using the same address identifier but a different commitment txid that + spends the funds to the attacker's wallet. However, there is no way + for the attacker to generate a valid sequence dependent proof given + that they don't know the underlying public key. This won't be + immediately obvious to full verification nodes, but they will be able + to reject the attacker's commitment after the UTXO owner reveals the + public key. + + After the commitment confirms to a suitable depth, the spender reveals + the full transaction matching the commitment txid. Full nodes verify + the public key matches the address identifier and that, in combination + with the txid, it matches the sequence dependent proof. At this + point, full nodes purge all but the oldest (most deeply confirmed) + commitments for that address identifier. Only the first-confirmed + txid for that address identifier with a valid sequence-dependent proof + can be resolved into a confirmed transaction. + + Dryja goes into additional details about how this scheme could be + deployed as a soft fork, how the commitment byte could be + reduced by half, and what users and software today can do to prepare + for using this scheme---as well as limitations in this scheme for + users of both scripted and [scriptless multisignatures][topic multisignature]. + +- **OP_TXHASH variant with support for transaction sponsorship:** Steven + Roose [posted][roose txsighash] to Delving Bitcoin about a variation on `OP_TXHASH` + called `TXSIGHASH` that extends 64-byte [schnorr signatures][topic schnorr signatures] with + additional bytes to indicate what fields in the transaction (or + related transactions) the signature commits to. In addition to the + previously proposed commitment fields for `OP_TXHASH`, Roose notes + that the signature could commit to an earlier transaction in the block + using an efficient form of [transaction sponsorship][topic fee sponsorship] (see + [Newsletter #295][news295 sponsor]). He then analyzes the onchain costs of this + mechanism compared to existing [CPFP][topic cpfp] and a previous sponsorship + proposal, concluding: "With [`TXSIGHASH`] stacking, the cost in + virtual bytes of each stacked transaction can even be lower than their + original cost without a sponsor included [...] Additionally, all + inputs are “simple” key-spends, meaning that they could be aggregated + if [CISA][topic cisa] were to be deployed." + + As of this writing, the post had not received any public replies. + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [Bitcoin Coer #32540][] rest: fetch spent transaction outputs by blockhash + +- [Bitcoin Core #32638][] blocks: force hash validations on disk read + +- [Bitcoin Core #32819][] cap max values for 32-bit + +- [LDK #3618][] Async recipient-side of static invoice server + +{% include snippets/recap-ad.md when="2025-07-08 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32540,32638,32819,3618,1479" %} +[news255 presig vault state]: /en/newsletters/2023/06/14/#discussion-about-the-taproot-annex +[news348 ctvstep]: /en/newsletters/2025/04/04/#ctv-csfs-benefits +[news268 ptlc]: /en/newsletters/2023/09/13/#ln-messaging-changes-for-ptlcs +[news191 simple-ctv-vault]: /en/newsletters/2022/03/16/#continued-ctv-discussion +[news354 bitvm]: /en/newsletters/2025/05/16/#description-of-benefits-to-bitvm-from-op-ctv-and-op-csfs +[rubin lamport]: https://gnusha.org/pi/bitcoindev/CAD5xwhgzR8e5r1e4H-5EH2mSsE1V39dd06+TgYniFnXFSBqLxw@mail.gmail.com/ +[osuntokun onion]: https://delvingbitcoin.org/t/reimagining-onion-messages-as-an-overlay-layer/1799/ +[news283 oniondirect]: /en/newsletters/2024/01/03/#ldk-2723 +[news304 onionreply]: /en/newsletters/2024/05/24/#core-lightning-7304 +[sanders ptlc]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/7 +[provoost ptlc]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/80 +[sanders ptlc2]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/81 +[sanders gist]: https://gist.github.com/instagibbs/1d02d0251640c250ceea1c66665ec163 +[towns ptlc]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/82 +[provoost ctvdesc]: https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766/ +[simple-ctv-vault]: https://github.com/jamesob/simple-ctv-vault +[ingala vaultdesc]: https://github.com/bitcoin/bips/pull/1793#issuecomment-2749295131 +[kanjalkar vaultdesc1]: https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766/3 +[kanjalkar vaultdesc2]: https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766/9 +[towns ctvbitvm]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/8 +[op_txhash]: /en/newsletters/2022/02/02/#composable-alternatives-to-ctv-and-apo +[stewart ctvimp]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/25 +[obeirne letter]: https://mailing-list.bitcoindevs.xyz/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com/ +[sanders legacy]: https://mailing-list.bitcoindevs.xyz/bitcoindev/b17d0544-d292-4b4d-98c6-fa8dc4ef573cn@googlegroups.com/ +[obeirne legacy]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPfvXfKEgA0RCvxR=mP70sfvpzTphTZGidy=JuSK8f1WnM9xYA@mail.gmail.com/ +[sanders p2ctv]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/72?u=harding +[lopp ctvvaults]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CADL_X_fxwKLdst9tYQqabUsJgu47xhCbwpmyq97ZB-SLWQC9Xw@mail.gmail.com/ +[maxwell autodelete]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAAS2fgSmmDmEhi3y39MgQj+pKCbksMoVmV_SgQmqMOqfWY_QLg@mail.gmail.com/ +[sanders ctvcom]: https://groups.google.com/g/bitcoindev/c/KJF6A55DPJ8/m/XVhyLCJiBQAJ +[towns ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aEu8CqGH0lX5cBRD@erisian.com.au/ +[poinsot ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/GLGZ3rEDfqaW8jAfIA6ac78uQzjEdYQaJf3ER9gd4e-wBXsiS2NK0wAj8LWK8VHf7w6Zru3IKbtDU5NM102jD8wMjjw8y7FmiDtQIy9U7Y4=@protonmail.com/ +[provoost ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/0B7CEBEE-FB2B-41CF-9347-B9C1C246B94D@sprovoost.nl/ +[obeirne ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPfvXfLc5-=UVpcvYrC=VP7rLRroFviLTjPQfeqMQesjziL=CQ@mail.gmail.com/ +[poelstra ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aEsvtpiLWoDsfZrN@mail.wpsoftware.net/ +[roose ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/035f8b9c-9711-4edb-9d01-bef4a96320e1@roose.io/ +[goli ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/mc0q6r14.59407778-1eb1-4e57-bcf2-c781d6f70b01@we.are.superhuman.com/ +[conduition winternitz]: https://mailing-list.bitcoindevs.xyz/bitcoindev/uCSokD_EM3XBQBiVIEeju5mPOy2OU-TTAQaavyo0Zs8s2GhAdokhJXLFpcBpG9cKF03dNZfq2kqO-PpxXouSIHsDosjYhdBGkFArC5yIHU0=@proton.me/ +[conduition impl]: https://gist.github.com/conduition/c6fd78e90c21f669fad7e3b5fe113182 +[lamport signature]: https://en.wikipedia.org/wiki/Lamport_signature +[dryja fawkes]: https://mailing-list.bitcoindevs.xyz/bitcoindev/cc2f8908-f6fa-45aa-93d7-6f926f9ba627n@googlegroups.com/ +[news348 fawkes]: /en/newsletters/2025/04/04/#securely-proving-utxo-ownership-by-revealing-a-sha256-preimage +[roose txsighash]: https://delvingbitcoin.org/t/jit-fees-with-txhash-comparing-options-for-sponsorring-and-stacking/1760 +[news295 sponsor]: /en/newsletters/2024/03/27/#transaction-fee-sponsorship-improvements From 0c8c627590de54370f68af31161cc23eeea6847a Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 3 Jul 2025 04:03:47 +0000 Subject: [PATCH 140/278] News361: merge summaries --- .../en/newsletters/2025-07-04-newsletter.md | 35 ++++++++++++++----- 1 file changed, 27 insertions(+), 8 deletions(-) diff --git a/_posts/en/newsletters/2025-07-04-newsletter.md b/_posts/en/newsletters/2025-07-04-newsletter.md index 21c43e061b..b5ceae7673 100644 --- a/_posts/en/newsletters/2025-07-04-newsletter.md +++ b/_posts/en/newsletters/2025-07-04-newsletter.md @@ -385,17 +385,36 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Bitcoin Coer #32540][] rest: fetch spent transaction outputs by blockhash - -- [Bitcoin Core #32638][] blocks: force hash validations on disk read - -- [Bitcoin Core #32819][] cap max values for 32-bit - -- [LDK #3618][] Async recipient-side of static invoice server +- [Bitcoin Core #32540][] introduces the `/rest/spenttxouts/BLOCKHASH` REST + endpoint, which returns a list of spent transaction outputs (prevouts) for a + specified block, primarily in a compact binary (.bin) format but also in .json + and .hex variants. Although it was previously possible to do this with the + `/rest/block/BLOCKHASH.json` endpoint, the new endpoint improves the + performance of external indexers by eliminating JSON serialization overhead. + +- [Bitcoin Core #32638][] adds validation to ensure that any block read from + disk matches the expected block hash, catching bit rot and index mix-ups that + could have gone unnoticed previously. Thanks to the header-hash cache + introduced in [Bitcoin Core #32487][], this extra check is virtually + overhead-free. + +- [Bitcoin Core #32819][] and [#32530][Bitcoin Core #32530] set the maximum + values for the `-maxmempool` and `-dbcache` startup parameters to 500 MB and 1 + GB respectively, on 32-bit systems. Since this architecture has a total RAM + limit of 4 GB, values higher than the new limits could cause out of memory + (OOM) incidents. + +- [LDK #3618][] implements the client-side logic for [async payments][topic + async payments], allowing an offline recipient node to prearrange [BOLT12 + offers][topic offers] and static invoices with an always-online helper LSP + node. The PR introduces an async receive offer cache inside `ChannelManager` + that builds, stores, and persists offers and invoices. It also defines the new + onion messages and hooks needed to communicate with the LSP and threads the + state machine through the `OffersMessageFlow`. {% include snippets/recap-ad.md when="2025-07-08 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="32540,32638,32819,3618,1479" %} +{% include linkers/issues.md v=2 issues="32540,32638,32819,3618,1479,32487,32530" %} [news255 presig vault state]: /en/newsletters/2023/06/14/#discussion-about-the-taproot-annex [news348 ctvstep]: /en/newsletters/2025/04/04/#ctv-csfs-benefits [news268 ptlc]: /en/newsletters/2023/09/13/#ln-messaging-changes-for-ptlcs From aa050635a42bdf4b49ef9246dd652b926fb3343d Mon Sep 17 00:00:00 2001 From: azuchi Date: Sat, 5 Jul 2025 00:38:20 +0900 Subject: [PATCH 141/278] Newsletter-361:Translate into Japanese --- _includes/snippets/recap-ad.md | 8 +- .../ja/newsletters/2025-07-04-newsletter.md | 362 ++++++++++++++++++ 2 files changed, 366 insertions(+), 4 deletions(-) create mode 100644 _posts/ja/newsletters/2025-07-04-newsletter.md diff --git a/_includes/snippets/recap-ad.md b/_includes/snippets/recap-ad.md index 6f4090cdf6..f73e083405 100644 --- a/_includes/snippets/recap-ad.md +++ b/_includes/snippets/recap-ad.md @@ -52,10 +52,10 @@ disponible sur notre page de [podcasts][podcast]. ## もっと知りたいですか？ -このニュースレターで言及されたトピックについてもっと議論したい方は、 （ニュース -レターが公開された翌日の）木曜日の{{recap_formatted_time_utc}} UTCから -[Riverside.fm][]で毎週開催されているBitcoin Optech Recapにご参加ください。この議 -論は録画もされ、[ポッドキャスト][podcast]ページからご覧いただけます。 +このニュースレターで言及されたトピックについてもっと議論したい方は、 +{{recap_formatted_time_utc}} UTCに +[Riverside.fm][]で毎週配信されているBitcoin Optech Recapにご参加ください。 +この議論は録画もされ、[ポッドキャスト][podcast]ページからご覧いただけます。 {% when "zh" %} diff --git a/_posts/ja/newsletters/2025-07-04-newsletter.md b/_posts/ja/newsletters/2025-07-04-newsletter.md new file mode 100644 index 0000000000..104cee8338 --- /dev/null +++ b/_posts/ja/newsletters/2025-07-04-newsletter.md @@ -0,0 +1,362 @@ +--- +title: 'Bitcoin Optech Newsletter #361' +permalink: /ja/newsletters/2025/07/04/ +name: 2025-07-04-newsletter-ja +slug: 2025-07-04-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、LNにおけるOnionメッセージリレーで使用されるネットワーク接続とピア管理を、 +HTLCリレーで使用されるものと分離する提案を掲載しています。また、Bitcoinのコンセンサスの変更に関する議論や、 +人気のBitcoinインフラストラクチャソフトウェアの最近の更新など、恒例のセクションも含まれています。 + +## ニュース + +- **OnionメッセージとHTLCリレーの分離:** Olaluwa Osuntokunは、 + ノードが[Onionメッセージ][topic onion messages]のリレーと、 + [HTLC][topic htlc]のリレーに、それぞれ別の接続を使用できるようにすることについて + Delving Bitcoinに[投稿しました][osuntokun onion]。直接リレーの場合のように（ + ニュースレター [#283][news283 oniondirect]および[#304][news304 onionreply]参照）、 + 現在でも別々の接続が可能な場合もありますが、Osuntokunは、分離した接続を常にオプションとして利用可能にし、 + ノードが支払いのリレーに使用するピアのセットとは異なるOnionメッセージ用のピアのセットを持てるようにすることを提案しています。 + 彼は、この代替アプローチを支持するいくつかの論点を挙げています: + 関心事をより明確に分離できること、ノードはチャネルピアよりも高密度なOnionメッセージピアを安価にサポートできること（ + チャネルの作成にはコストがかかるため）、分離によりプライバシー向上のための鍵ローテションを導入できること、 + HTLCコミットメント通信プロトコルによってブロックされる必要がないためOnionメッセージの配信速度が向上する可能性があること。 + Osuntokunは、提案されたプロトコルについて、詳細な情報を提供しています。 + + 回答した開発者の何人かが懸念していたのは、Onionメッセージのネットワークが、 + 過剰な数のピアによるノードへのフラッディングをどのように防ぐかという点でした。 + 現在のOnionメッセージの実装では、各ノードは通常、チャネルパートナーとの接続のみを保持しています。 + チャネルに資金を提供するUTXOの作成には費用（オンチェーン手数料と機会費用）がかかり、 + ノードとチャネルパートナーに固有のものです。つまり、1つのUTXOに対して1つの接続が確立されます。 + 仮に、Onionメッセージの接続がオンチェーン資金で裏付けられる場合でも、 + 1つのUTXOですべての公開LNノードへの接続を確立できます。つまり、1つのUTXOで数千の接続が確立されるということです。 + + 少なくとも1人の回答者はOsuntokunの提案を支持していましたが、 + これまでのところ複数の回答者がサービス拒否リスクへの懸念を表明しています。 + この記事の執筆時点では、議論は継続中でした。 + +## コンセンサスの変更 + +_Bitcoinのコンセンサスルールの変更に関する提案と議論をまとめた月次セクション_ + +- **PTLCにおけるCTV+CSFSの利点:** 開発者たちは、さまざまな展開済みおよび想定されるプロトコルにおける + [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (CTV)と + [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (CSFS)、 + あるいはその両方による利点について、以前の議論（[ニュースレター #348][news348 ctvstep]参照）を続けました。 + 特に興味深いのは、Gregory SandersがCTV+CSFSについて「たとえ + [LN-Symmetry][topic eltoo]自体が採用されなくても、CTV+CSFSは + LNを[PTLC][topic ptlc]に更新するのを加速させるでしょう。 + 再バインド可能な署名は、プロトコルを積み重ねる際の負担を大幅に軽減します」と[述べています][sanders ptlc]。 + Sjors Provoostが詳細を[尋ねた][provoost ptlc]ところ、Sandersは[返信で][sanders ptlc2] + PTLCのLNメッセージの変更に関する以前の研究（[ニュースレター #268][news268 ptlc]参照）の[リンク][sanders gist]を提供し、 + 「現在のプロトコルでもPTLCは決して不可能ではないが、再バインド可能な署名があれば大幅にシンプルになる」と付け加えました。 + + Anthony Townsは、さらに次のように[言及しました][towns ptlc]。 + 「PTLCでの開示を[musig][topic musig] 2-of-2（オンチェーンでは効率的）と組み合わせて行うための + ツールや標準も不足しています。また、（`x CHECKSIGVERIFY y CHECKSIG`のような） + 一般的なトランザクションの署名でさえも同様です。[...]これには、musig2用の[アダプター署名][topic adaptor signatures]が必要ですが、 + それは仕様には含まれておらず、secp256k1の実装から[削除されました][libsecp256k1 #1479]。 + 効率は低くなるものの別にアダプター署名として実現することは可能ですが、 + [Schnorr署名][topic schnorr signatures]用の単純なアダプター署名さえsecp256k1では利用できません。 + これらは実験的なsecp256k1-zkpプロジェクトにも含まれていません。[...] + ツールが準備されていれば、PTLCのサポートが追加される可能性はありますが[...] + 暗号関連の標準化と洗練に注力するほどの優先度が高いと考える人はいないと思います。[...] + [CAT][topic op_cat]+CSFSが利用可能であればツールの問題は回避できますが、 + オンチェーンの効率性は犠牲になります。[...]CSFSのみが利用可能な場合は、 + 相手方が署名に必要なRの値を選択するのを防ぐためアダプター署名を使用する必要があり、 + 同様のツールの問題が引き続き発生するでしょう。これらの問題は、 + Gregory Sandersが説明した更新の複雑さやピアプロトコルの更新とは無関係です。」 + +- **Vaultアウトプットスクリプトディスクリプター:** Sjors Provoostは、 + [Vault][topic vaults]を使用するウォレットのリカバリー情報を + [アウトプットスクリプトディスクリプター][topic descriptors]を使って指定する方法を + Delving Bitcoinに[投稿しました][provoost ctvdesc]。特に、James O'Beirneの + [simple-ctv-vault][]概念実証実装（[ニュースレター #191][news191 simple-ctv-vault]参照）で提供されているような + [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (CTV)ベースのVaultに焦点を当てました。 + + Provoostは、Salvatore Ingalaの「私の見解では、ディスクリプターはこの目的には適用さないツールです」 + という[コメント][ingala vaultdesc]を引用しました。 + Sanket Kanjalkarは現在のスレッドでこの意見に[同意し][kanjalkar vaultdesc1]ましたが、回避策を[発見しました][kanjalkar vaultdesc2]。 + Kanjalkarは、資金をより一般的なディスクリプターにデポジットし、 + そこからCTV Vaultに移動させる、CTVベースのVault版について説明しました。 + これにより、知識の浅いユーザーが資金を失う可能性のある状況を回避できるだけでなく、 + 標準的なディスクリプターへのすべての資金が毎回同じ設定でVaultに移動されることを前提とした + ディスクリプターの作成が可能になります。これによりCTV Vaultディスクリプターは、 + ディスクリプター言語に無理な変更を加えることなく、簡潔で完全なものになります。 + +- **BitVMにおけるCTV+CSFSの利点に関する議論の続き:** 開発者たちは、 + [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (CTV)および + [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (CSFS) opcodeの利用により、 + 「BitVMのトランザクションサイズを約1/10に削減」し、非対話型のペグインを可能にする方法について、 + 以前の議論（[ニュースレター #354][news354 bitvm]参照）を続けました。 + Anthony Townsは、当初提案されたコントラクトの脆弱性を[指摘][towns ctvbitvm]し、 + 彼と他の開発者たちは回避策を説明しました。CTVではなく提案中の + [OP_TXHASH][]を使用する利点が追加で議論されました。Chris Stewartは、 + Bitcoin Coreのテストソフトウェアを使って、議論されたアイディアのいくつかを[実装し][stewart ctvimp]、 + 議論の該当部分を検証し、レビュー担当者に具体的な例を提供しました。 + +- **CTVとCSFSに関する公開書簡:** James O'Beirneは、 + Bitcoin-Devメーリングリストに公開書簡を投稿しました。 + これには（本稿執筆時点で）66名の署名が寄せられており、その多くはBitcoin関連プロジェクトのコントリビューターです。 + この書簡は「Bitcoin Coreのコントリビューターに対し、今後6ヶ月以内に + [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (CTV)と + [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (CSFS)のレビューと + 統合を優先するよう要請」しています。このスレッドには60件以上の返信が寄せられています。 + いくつかの技術的なハイライトは次のとおりです: + + - *レガシーサポートに関する懸念と代替案:* + [BIP119][]は、witness script v1（[Tapscript][topic tapscript]）と + レガシースクリプトの両方でCTVを定義しています。Gregory Sandersは、 + 「レガシースクリプトのサポートは[...]レビューの対象領域を大幅に拡大する一方で、 + プロトコルの機能向上やコスト削減の効果は不明です」と[述べています][sanders legacy]。 + O'Beirneは、レガシースクリプトのサポートで場合によっては約8vbyteを節約できる可能性があると[返信][obeirne legacy]しましたが、 + Sandersはこの節約をwitness scriptで可能にする彼の以前のP2CTV（pay-to-CTV）提案と + 概念実証の実装を[リンクしました][sanders p2ctv]。 + + - *CTVのみのVautlサポートの限界:* 署名者のJameson Loppは、「[Vault][topic vaults]に最も関心がある」と[述べ][lopp ctvvaults]、 + CTV Vaultが提供する特性、現在事前署名トランザクションを使って導入可能なVaultとの比較、 + （特にコンセンサスの変更を必要とする高度なVaultと比較して）セキュリティが実質的に向上するかどうかについて議論を始めました。 + この議論による主な要点は以下のとおりです: + + - *アドレス再利用の危険性:* 事前署名VaultもCTV Vaultもどちらも、 + ユーザーがVaultアドレスを再利用できないようにする必要があり、そうしないと資金が失われる可能性があります。 + これを実現する方法の1つは、Vaultに資金をデポジットするのに2つのオンチェーントランザクションが必要になる + 2段階のVault手順です。追加のコンセンサスの変更を必要とする高度なVaultはこの問題を持たず、 + 再利用されたアドレスへのデポジットも可能です（ただし、当然ながら[プライバシーは低下します][topic output linking]）。 + + - *ステージング資金の盗難:* 事前署名VaultもCTV Vaultも + 認可された引き出しの盗難が可能です。たとえば、Vaultユーザーのボブがアリスに1 BTC支払うとします。 + 事前署名VaultとCTV Vaultでは、ボブは以下の手順で支払いを行います: + + - 自分のVaultから1 BTC（場合によっては手数料も）をステージングアドレスに引き出します。 + + - Vaultで定義された時間待機します。 + + - 1 BTCをアリスに送金します。 + + マロリーがボブのステージング鍵を盗んだ場合、引き出しが完了してからアリスへのトランザクションが承認されるまでの間に、 + マロリーは1 BTCを盗むことができます。しかしマロリーが引き出し用の鍵を盗んだとしても、 + ボブは保留中の引き出しを中断し、超安全な鍵（または複数の鍵）で保護された安全なアドレスに資金をリダイレクトできるため、 + マロリーはVaultに残っている資金を盗むことはできません。 + + より高度なVaultでは、ステージングの手順は不要です。ボブの引き出しは、 + アリスまたは安全なアドレスのいずれかにしか送れません。これにより、 + マロリーは引き出しと支払いの間で資金を盗むことができなくなります。 + + - *鍵の削除:* 事前署名Vaultに対するCTVベースのVaultの利点の1つは、 + 事前署名済みのトランザクションセットのみが利用可能なオプションであることを保証するために、 + 秘密鍵を削除する必要がないことです。しかし、Gregory Maxwellは、 + トランザクションに署名した直後に鍵を削除し、ユーザーに秘密鍵を公開しないソフトウェアを設計するのは簡単だと + [指摘しています][maxwell autodelete]。現在、これを直接サポートするハードウェア署名デバイスは確認されていませんが、 + 少なくとも1つのデバイスがユーザーの手動操作によりこれをサポートしています。しかし、 + （私たちの知る限り）現在、テスト用であってもCTVをサポートするハードウェアはありません。 + より高度なVaultはCTVのキーレスの利点を共有しますが、ソフトウェアとハーウェアへの統合も必要になります。 + + - *静的な状態:* 事前署名Vaultに対するCTVベースのVaultの利点の1つは、 + 静的バックアップからウォレットを復元するために必要なすべての情報（ + [アウトプットスクリプトディスクリプター][topic descriptors]など）を計算できる可能性があることです。 + しかし、事前署名された状態の非決定論的なパーツをオンチェーントランザクション自体に保存することで + 静的バックアップを可能にする事前署名Vaultに関する研究も既に行われています（[ニュースレター #255][news255 presig vault state]参照）。 + Optechは、より高度なVaultであれば静的な状態から復元できると考えていますが、 + 本記事の執筆時点では検証できていません。 + + - *Bitcoin Coreコントリビューターからの回答:* この記事の執筆時点で、 + Optechが現在アクティブなBitcoin Coreコントリビューターと認識している4名が、 + メーリングリストの書簡に回答しました。彼らは次のように述べています: + + - [Gregory Sanders][sanders ctvcom]: 「この書簡は技術コミュニティからのフィードバックを求めるものであり、 + これは私からのフィードバックです。何年も更新されていない未展開のBIPは、 + 一般的に健全な提案の兆候ではなく、細心の注意を払ってきた人からの技術アドバイスを拒否する根拠にはなりません。 + 私はこの枠組み、この提案への変更の基準を重大な破壊のみに引き上げること、 + そしてBIP119を現状のまま期限付きで終了させることに反対します。私は依然として + （機能的な意味で）CTV＋CSFSは検討に値すると考えていますが、これはBIP119を頓挫させる確実な方法です。」 + + - [Anthony Towns][towns ctvcom]: 「私の見解では、 + CTVの議論は重要なステップを逃しており、それらのステップを踏む代わりに、 + 推進派は少なくとも3年間、世論の圧力を利用して「早期導入」を強制しようとし続けています。 + 私は、CTV推進派が見落としていると思われるステップを踏めるよう支援してきましたが、 + 建設的な成果は得られず、沈黙や侮辱を受けるだけでした。少なくとも私の立場からすると、 + これはインセンティブの問題を悪化させているだけで、解決にはつながっていないように思います。」 + + - [Antoine Poinsot][poinsot ctvcom]: 「この書簡の影響は、予想どおり、 + この提案（あるいはより広義には、この一連の機能）の進捗に大きな後退をもたらしました。 + この状況からどのように立て直すかは分かりませんが、誰かが立ち上がり、 + コミュニティからの技術的なフィードバックに実際に対応し、 + （実際の）ユースケースを示す作業が不可欠です。前進するには、 + 客観的かつ技術的な強力な議論に基づいて合意形成する必要があります。 + 多くの人が関心を表明するだけで、誰も行動を起こさず、提案の前進を支援しないという状況ではだめです。」 + + - [Sjors Provoost][provoost ctvcom]: 「私自身の動機についても少し触れさせてください。 + Vaultは、この提案によって可能になる機能の中で、個人的に取り組む価値があると感じている唯一の機能のように思います。 + [...]つい最近まで、Vaultの勢いはOP_VAULTにあり、そのためにはOP_CTVが必要になるように思えました。 + しかし、単一の目的のopcodeというのは理想的なではないため、このプロジェクトは進展が無いように思えました。 + [...]一方で、CTV + CSFSには反対しません。これらが有害だという主張は聞いたことがありません。 + MeVilの可能性がほとんどないので、他の開発者がこれらの変更を慎重に開発して展開することも想像できます。 + 私はそのプロセスを注視するだけです。私が反対するのは、共同署名者のPaul Sztorcが提案したような、 + Pythonベースの代替実装とアクティベーションクライアントです。」 + + - *署名者の声明:* 書簡の署名者もその後の声明で彼らの意図を明確にしました: + + - [James O'Beirne][obeirne ctvcom]: 「署名した全員が、CTV+CSFSについて、 + 早期のレビュー、統合、そしてアクティベーション計画を明確に確認したいと考えています。」 + + - [Andrew Poelstra][poelstra ctvcom]: 「書簡の初期のドラフトでは、 + 実際の統合、さらにはアクティベーションまでを求めていましたが、私はいずれの初期ドラフトにも署名しませんでした。 + 優先順位と計画に関する表現（そして、ある種の要求ではなく「敬意ある依頼」）へと弱められた後、ようやく署名しました。」 + + - [Steven Roose][roose ctvcom]: 「この書簡は単にCoreコントリビューターに対し、 + この提案をある程度の緊急性を持って議題に載せることを求めているだけです。脅しや厳しい言葉もありません。 + これまでこの提案に関する他の議論に参加したCoreコントリビューターはごくわずかだったため、 + Coreコントリビューターにこの議論における立場を表明してほしいという意思を伝えるのが適切な次のステップだと思いました。 + 私は、独立したアクティベーションクライアント含むアプローチには強く反対しており、 + このメールの趣旨は、プロトコルアップグレードの展開にCoreが関与することを望むという私たちの考えと一致している思っています。」 + + - [Harsha Goli][goli ctvcom]: 「ほとんどの人が署名したのは、次のステップがどうあるべきか全く分からなかったからです。 + トランザクションコミットメントに対するプレッシャーがあまりにも大きかったため、 + （署名付きの書簡という）悪手でも、何もしないよりましだと判断したのです。 + （私の業界調査で促進された）書簡が送られる前の話し合いでは、署名者の多くから、この文書について警告する声しかありませんでした。 + 実際、この書簡を明確に良いアイディアだと考えた人は一人もいません。それでも署名しました。そこにシグナルがあるんです。」 + +- **OP_CATが可能にするWinternitz署名:** 開発者のConduitionは、 + 提案中の[OP_CAT][topic op_cat] opcodeと他のスクリプト命令を用いて、 + Winternitzプロトコルを使用した[量子耐性][topic quantum resistance]署名をコンセンサスロジックで検証する + [プロトタイプ実装][conduition impl]をBitcoin-Devメーリングリストに[投稿しました][conduition winternitz]。 + Conduitionの実装では、鍵、署名、スクリプトで約8,000 byteを必要とします（その大部分はwitnessディスカウントの対象となり、 + オンチェーンweightは約2,000 vbyteになります）。これは、Jeremy Rubinが[以前提案した][rubin lamport] + `OP_CAT`ベースの別の量子耐性[ランポート署名][Lamport signature]方式よりも、約8,000 vbyte小さいものです。 + +- **ポスト量子リカバリーのためのコミット/開示機能:** Tadge Dryjaは、 + 高速な量子コンピューターが支払いに使用されようとしているアウトプットをリダイレクト（盗むことが）できる場合でも、 + [量子脆弱][topic quantum resistance]な署名アルゴリズムを使用してUTXOを使用できるようにする方法を + Bitcoin-Devメーリングリストに[投稿しました][dryja fawkes]。 + これにはソフトフォークが必要で、Tim Ruffingによる以前の提案（[ニュースレター #348][news348 fawkes]参照）の変形版です。 + + Dryjaのスキームでアウトプットを使用するには、支払人は3つのデータへのコミットメントを作成します: + + 1. 資金を管理する秘密鍵に対応する公開鍵のハッシュ`h(pubkey)`。これを _アドレス識別子_ と呼びます。 + + 2. 公開鍵と支払人が最終的にブロードキャストしたいトランザクションのtxidとハッシュ`h(pubkey, txid)`。 + これを _シーケンス依存証明_ と呼びます。 + + 3. 最終的なトランザクションのtxid。これを _コミットメントtxid_ と呼びます。 + + これらの情報はいずれも、基礎となる公開鍵を明かすものではありません。この方式では、 + UTXOを管理する人物だけが公開鍵を知っていると仮定します。 + + 3つのパーツで構成されるコミットメントは、量子安全なアルゴリズムを用いたトランザクション（たとえば、 + `OP_RETURN`アウトプット）でブロードキャストされます。この時点で、 + 攻撃者は同じアドレス識別子と異なるコミットメントtxidを使って、 + 攻撃者のウォレットに資金を送金する独自のコミットメントをブロードキャストしようとする可能性があります。 + しかし、攻撃者はベースとなる公会鍵を知らないため、有効なシーケンス依存証明を生成することはできません。 + これは完全な検証ノードですぐには分かりませんが、UTXOの所有者が公開鍵を明かした後で、 + 攻撃者のコミットメントを拒否することができます。 + + コミットメントが適切な深さまで承認された後、支払人はコミットメントtxidと一致する完全なトランザクションを公開します。 + フルノードは、公開鍵がアドレス識別子と一致し、txidと組み合わせてシーケンス依存証明と一致することを検証します。 + この時点で、フルノードはそのアドレス識別子に対する最も古い（最も深く承認された）コミットメント以外をすべて削除します。 + 有効なシーケンス依存証明を持つそのアドレス識別子で最初に承認されたtxidのみが、承認済みトランザクションとして解決できます。 + + Dryjaは、このスキームをソフトフォークとして展開する方法、 + コミットメントバイトを半分に削減する方法、そして現在のユーザーとソフトウェアがこのスキームの使用に備えてできること、 + そしてスクリプト型および[スクリプトレスマルチシグ][topic multisignature]のユーザーにとっての + このスキームの制限についてさらに詳しく説明しています。 + +- **トランザクションスポンサーシップをサポートするOP_TXHASHの変形版:** Steven Rooseは、 + `OP_TXHASH`の変形版である`TXSIGHASH`についてDelving Bitcoinに[投稿しました][roose txsighash]。 + これは、64 byteの[Schnorr署名][topic schnorr signatures]を拡張し、 + 署名がトランザクション（または関連トランザクション）のどのフィールドにコミットするかを示すbyteを追加します。 + Rooseは、`OP_TXHASH`に以前提案されたコミットメントフィールドに加えて、 + 効率的な形式の[トランザクションスポンサーシップ][topic fee sponsorship]（[ニュースレター #295][news295 sponsor]参照）を使用して + ブロック内のそれより前のトランザクションに署名をコミットできると指摘しています。 + そして、このメカニズムのオンチェーンコストを既存の[CPFP][topic cpfp]や + 以前のスポンサーシップの提案と比較して分析し、次のように結論づけています: 「 + [`TXSIGHASH`]スタッキングでは、スタックされた各トランザクションの仮想byteコストは、 + スポンサーを含まない元のコストよりもさらに低くなる可能性があります。[...] + さらに、すべてのインプットは単純なkey-spendであるため、[CISA][topic cisa]が導入されれば集約できます。」 + + この記事の執筆時点では、この投稿への返信はありませんでした。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Bitcoin Core #32540][]では、`/rest/spenttxouts/BLOCKHASH` RESTエンドポイントが導入されました。 + このエンドポイントは、指定されたブロックで使用されたトランザクションアウトプット（prevouts）のリストを、 + 主にコンパクトなバイナリ（.bin）形式、また.jsonおよび.hex形式で返します。 + これまでも、`/rest/block/BLOCKHASH.json`エンドポイントで同様の処理が可能でしたが、 + この新しいエンドポイントでは、JSONシリアライゼーションのオーバーヘッドが排除されるため、 + 外部のインデクサーのパフォーマンスが向上します。 + +- [Bitcoin Core #32638][]では、ディスクから読み込まれたブロックが + 期待されるブロックハッシュと一致することを確認する検証機能が追加され、 + これまで検出できなかったビット腐敗やインデックスの混同を検出できるようになります。 + [Bitcoin Core #32487][]で導入されたヘッダーハッシュキャッシュのおかげで、 + この追加チェックには実質オーバーヘッドはありません。 + +- [Bitcoin Core #32819][]および[#32530][Bitcoin Core #32530]は、 + 32-bitシステムにおいて、起動パラメーター`-maxmempool`と`-dbcache`の最大値をそれぞれ + 500MBと1GBに設定しました。このアーキテクチャのRAMの総上限は4GBであるため、 + 新しい制限を超える値を設定すると、メモリ不足（OOM）が発生する可能性があります。 + +- [LDK #3618][]は、[非同期支払い][topic async payments]用のクライアント側のロジックを実装し、 + オフラインの受信ノードが常時オンラインのヘルパーLSPノードを使用して[BOLT12 + オファー][topic offers]と静的インボイスを事前に準備できるようにします。 + このPRは、`ChannelManager`内に、オファーとインボイスを構築、保存および永続化する非同期受信オファーキャッシュを導入します。 + また、LSPとの通信に必要な新しいOnionメッセージとフックを定義し、 + ステートマシンを`OffersMessageFlow`に組み込みます。 + +{% include snippets/recap-ad.md when="2025-07-08 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32540,32638,32819,3618,32487,32530,1479" %} +[news255 presig vault state]: /ja/newsletters/2023/06/14/#taproot-annex +[news348 ctvstep]: /ja/newsletters/2025/04/04/#ctv-csfs +[news268 ptlc]: /ja/newsletters/2023/09/13/#ptlc-ln +[news191 simple-ctv-vault]: /ja/newsletters/2022/03/16/#ctv +[news354 bitvm]: /ja/newsletters/2025/05/16/#op-ctv-op-csfs-bitvm +[rubin lamport]: https://gnusha.org/pi/bitcoindev/CAD5xwhgzR8e5r1e4H-5EH2mSsE1V39dd06+TgYniFnXFSBqLxw@mail.gmail.com/ +[osuntokun onion]: https://delvingbitcoin.org/t/reimagining-onion-messages-as-an-overlay-layer/1799/ +[news283 oniondirect]: /ja/newsletters/2024/01/03/#ldk-2723 +[news304 onionreply]: /ja/newsletters/2024/05/24/#core-lightning-7304 +[sanders ptlc]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/7 +[provoost ptlc]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/80 +[sanders ptlc2]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/81 +[sanders gist]: https://gist.github.com/instagibbs/1d02d0251640c250ceea1c66665ec163 +[towns ptlc]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/82 +[provoost ctvdesc]: https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766/ +[simple-ctv-vault]: https://github.com/jamesob/simple-ctv-vault +[ingala vaultdesc]: https://github.com/bitcoin/bips/pull/1793#issuecomment-2749295131 +[kanjalkar vaultdesc1]: https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766/3 +[kanjalkar vaultdesc2]: https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766/9 +[towns ctvbitvm]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/8 +[op_txhash]: /ja/newsletters/2022/02/02/#ctv-apo +[stewart ctvimp]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/25 +[obeirne letter]: https://mailing-list.bitcoindevs.xyz/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com/ +[sanders legacy]: https://mailing-list.bitcoindevs.xyz/bitcoindev/b17d0544-d292-4b4d-98c6-fa8dc4ef573cn@googlegroups.com/ +[obeirne legacy]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPfvXfKEgA0RCvxR=mP70sfvpzTphTZGidy=JuSK8f1WnM9xYA@mail.gmail.com/ +[sanders p2ctv]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/72?u=harding +[lopp ctvvaults]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CADL_X_fxwKLdst9tYQqabUsJgu47xhCbwpmyq97ZB-SLWQC9Xw@mail.gmail.com/ +[maxwell autodelete]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAAS2fgSmmDmEhi3y39MgQj+pKCbksMoVmV_SgQmqMOqfWY_QLg@mail.gmail.com/ +[sanders ctvcom]: https://groups.google.com/g/bitcoindev/c/KJF6A55DPJ8/m/XVhyLCJiBQAJ +[towns ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aEu8CqGH0lX5cBRD@erisian.com.au/ +[poinsot ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/GLGZ3rEDfqaW8jAfIA6ac78uQzjEdYQaJf3ER9gd4e-wBXsiS2NK0wAj8LWK8VHf7w6Zru3IKbtDU5NM102jD8wMjjw8y7FmiDtQIy9U7Y4=@protonmail.com/ +[provoost ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/0B7CEBEE-FB2B-41CF-9347-B9C1C246B94D@sprovoost.nl/ +[obeirne ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPfvXfLc5-=UVpcvYrC=VP7rLRroFviLTjPQfeqMQesjziL=CQ@mail.gmail.com/ +[poelstra ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aEsvtpiLWoDsfZrN@mail.wpsoftware.net/ +[roose ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/035f8b9c-9711-4edb-9d01-bef4a96320e1@roose.io/ +[goli ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/mc0q6r14.59407778-1eb1-4e57-bcf2-c781d6f70b01@we.are.superhuman.com/ +[conduition winternitz]: https://mailing-list.bitcoindevs.xyz/bitcoindev/uCSokD_EM3XBQBiVIEeju5mPOy2OU-TTAQaavyo0Zs8s2GhAdokhJXLFpcBpG9cKF03dNZfq2kqO-PpxXouSIHsDosjYhdBGkFArC5yIHU0=@proton.me/ +[conduition impl]: https://gist.github.com/conduition/c6fd78e90c21f669fad7e3b5fe113182 +[lamport signature]: https://ja.wikipedia.org/wiki/ランポート署名 +[dryja fawkes]: https://mailing-list.bitcoindevs.xyz/bitcoindev/cc2f8908-f6fa-45aa-93d7-6f926f9ba627n@googlegroups.com/ +[news348 fawkes]: /ja/newsletters/2025/04/04/#sha256-utxo +[roose txsighash]: https://delvingbitcoin.org/t/jit-fees-with-txhash-comparing-options-for-sponsorring-and-stacking/1760 +[news295 sponsor]: /ja/newsletters/2024/03/27/#transaction-fee-sponsorship-improvements From 5aea7a959ec9b93e1db42398c9b294dfc5e651a7 Mon Sep 17 00:00:00 2001 From: editor-Ajian <34365188+editor-Ajian@users.noreply.github.com> Date: Fri, 4 Jul 2025 17:58:01 +0800 Subject: [PATCH 142/278] newsletter359zh-cn (#172) * newsletter359zh-cn * fix format --------- Co-authored-by: Zhiwei(Jeffrey) Hu --- .../zh/newsletters/2025-06-20-newsletter.md | 84 +++++++++++++++++++ 1 file changed, 84 insertions(+) create mode 100644 _posts/zh/newsletters/2025-06-20-newsletter.md diff --git a/_posts/zh/newsletters/2025-06-20-newsletter.md b/_posts/zh/newsletters/2025-06-20-newsletter.md new file mode 100644 index 0000000000..eb9ebc671b --- /dev/null +++ b/_posts/zh/newsletters/2025-06-20-newsletter.md @@ -0,0 +1,84 @@ +--- +title: 'Bitcoin Optech Newsletter #359' +permalink: /zh/newsletters/2025/06/20/ +name: 2025-06-20-newsletter-zh +slug: 2025-06-20-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- + +本周的新闻部分介绍了一个在 Bitcoin Core 代码库中限制公开参与的提议、宣布了一个对 BitVM 式合约的重大改进，并总结了对闪电通道再平衡的研究。此外是我们的常规栏目：客户端和服务端软件近期的变更总结、软件新版本和候选版本的公告、热门的比特币基础设施软件的近期变更介绍。 + +## 新闻 + +- **** **限制对 Bitcoin Core 项目访问的提议和讨论**：Bryan Bishop 在 Bitcoin-Dev 邮件组中[发帖][bishop priv]建议 Bitcoin Core 项目限制公众参与项目讨论的能力，以减少由非贡献者带来的干扰。他称之为 “私密化 Bitcoin Core”，并指出了这种私密化已经作为一种权宜之计、在多位 Bitcoin Core 贡献者的私人办公室中发生的例子，并警告说，面对面的私密化会疏远远程贡献者。 + + Bishop 的帖子提出了一种线上私密化的方法，但 Antoine Poinsot [质疑][poinsot priv]这种办法能否实现目标。Poinsot 还指出，许多私人办公室讨论之所以发生，可能并不是因为对公开批评的畏惧，而是因为 “面对面讨论的天然优势”。 + + 多个回复都指出，此时作出重大变更可能是不合理的，但对库中的评论作出更强力的调节也许能缓解破坏力最大的干扰类型。不过，其它回复也指出了更强力调节将面临的一些挑战。 + + Poinsot、Sebastian "The Charlatan" Kung 和 Russell Yanofsky —— 截至本刊撰写之时，回复此帖的人中仅有的几位高度活跃的 Bitcoin Core 贡献者 —— [表示][kung priv]要么[不认为][yanofsky priv]重大变更是必要的，要么任何变更都应该渐进施行。 + +- **** **BitVM 式合约的重大提升**：Robin Linus 在 Delving Bitcoin 中[宣布][linus bitvm3]， [BitVM][topic acc] 式合约在所要求的链上空间数量上取得重大削减。基于 Jeremy Rubin 的一个[想法][rubin garbled]、开发出新的密码学原语后，新方法 “相比于原有的设计，将争议解决的链上开销降低了超过 1000 倍”，反证交易 “只有 200 字节大小”。 + + 不过，Linus 的论文也指出了这一方法的取舍：它 “的启动设置需要几 TB 的链下数据”。论文给出了一个 SNARK 验证器电路的例子，由 500 万个逻辑门组成，而合理的安全参数需要 5 TB 的链下数据；见证结果需要 56 kB 的链上交易，在一方需要证明这样的结果无效的情形中，只需要提交极小的链上交易（约 200 B）。 + +- **** **通道再平衡研究**：Rene Pickhardt 在 Delving Bitcoin 论坛中[发布][pickhardt rebalance]了关于再平衡通道来最大化整个网络的支付成功率的想法。他的想法可以跟关注更小的通道集群的想法（比如 “[朋友的朋友再平衡][topic jit routing]”，详见 [周报 #54][news54 foaf rebalance]）相比较。 + + Pickhardt 指出全局方法面临许多挑战，并请求感兴趣的参与者回答几个问题，比如这个方法是否值得追求、如何解决特定的实现细节。 + +## 服务端和客户端软件的变更 + +*在这个月度栏目中，我们会列出比特币钱包和服务的有趣更新。* + +- **** **Cove v1.0.0 发布**：Cove 的[最新版本][cove github]加入了钱币控制功能以及 [BIP329][] 钱包标签特性。 + +- **** **Liana v11.0 发布**：Liana 的[最新版本][liana github]加入了多钱包特性、钱币控制特性以及对更多硬件签名器的支持；此外还新增了别的特性。 + +- **** **Stratum v2 STARK 证明演示**：StarkWare [演示][starkware tweet]了一个[修改后的 Stratum v2 挖矿客户端][starkware sv2]，使用一个 SATRK 证据来证明属于一个有效的区块模板的手续费，而不必揭开这个区块中的交易。 + +- **** **Breez SDK 加入了 BOLT12 和 BIP353**：Breez SDK Nodeless [0.9.0][breez github] 添加了使用 [BOLT12][] 和 [BIP353][] 来收款的特性。 + +## 新版本和候选版本 + +*热门的比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本。* + +- [Core Lightning 25.05][] 是这个热门的闪电节点实现的下一个主要版本的候选发行。该版本降低了转发和解析支付的时延、增强了手续费管理、提供了跟 Eclair 兼容的 “[通道拼接][topic splicing]” 特性，并默认启用[对等节点存储协议][topic peer storage]。注意：其[发行说明书][core lightning 25.05]包含了一个对使用 `--experimental-splicing` 配置选项的用户的警告。 + +## 显著的代码和说明书变更 + +*本周出现重大变更的有：[Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement Proposals (BIPs)][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo]。* + +- [Eclair #3110][] 将标记一条通道为关闭的时延从其注资输出被花费之后的 12 个区块（详见周报 [#337][news337 delay]）提高到 72 个区块，如 [BOLTs #1270][] 所指定的，以允许[拼接][topic splicing]更新的传播。提高这一数值，是因为一些实现在发送 `splice_locked` 之前默认要等待 8 个区块，而且允许节点运营者提高这个门槛，所以 12 个区块已经被证明是太短了。当前，这一数值在测试用途中是可以配置的，以允许节点运营者等待更长时间。 + +- [Eclair #3101][] 引入了 `parseoffer` PRC，它会解码 [BOLT12 offer][topic offers] 为明文可读的格式，从而用户可以在将 offer 传递给 `payoffer` PRC 之前看到支付的数额。后者已经扩展成接受以法币单位指定的数额。 + +- [LDK #3817][] 撤回了对 “[可归因故障][topic attributable failures]”（详见周报 [#349][news349 attributable]）的支持，仅在 test-only 的启动标签下才可使用。这禁用了对等节点的惩罚逻辑，并从传递故障的[洋葱消息][topic onion messages]中移除了特性 TLV。尚未升级的节点被错误地惩罚了，表明更广泛的网络采用是这种技术正常工作的前提。 + +- [LDK #3623][] 拓展了[对等节点存储协议][topic peer storage]（详见周报 [#342][news342 peer]）以提供自动化的、加密的对等节点备份。每过一个区块，`ChainMonitor` 都会将来自一个带有版本、时间戳且被序列化的 `ChannelMonitor` 结构体的数据打包成一个 `OurPeerStorage` 包裹。然后，它会加密这个数据，并唤起一个 `SendPeerStorage` 事件、将这个包裹作为一条 `peer_storage` 消息转发给每一条通道的对等节点。此外，`ChannelManager` 更新为通过触发一次新的包裹发送来处理 `peer_storage_retrieval` 请求。 + +- [BTCPay Server #6755][] 强化了钱币控制的用户界面：添加了新的最小数额和最大数额过滤器、创建 早于/晚于 某日期过滤器、这些过滤器的帮助选项、UTXO “全选” 选择框，以及页面大小选择（100 条、200 条或 500 条 UTXO）。 + +- [Rust libsecp256k1 #798][] 在库中完成了 [MuSig2][topic musig] 实现，为下游项目给出了使用一种健壮的[无脚本多签名][topic multisignature]协议的方法。 + +{% include references.md %} +{% include linkers/issues.md v=2 issues="3110,3101,3817,3623,6755,1270" %} +[Core Lightning 25.05]: https://github.com/ElementsProject/lightning/releases/tag/v25.05 +[bishop priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com/ +[poinsot priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235xaDlhg35nY8Zn7g1siy3IADHvSHyCcgTHrJorMKcDzZg=@protonmail.com/ +[kung priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/58813483-7351-487e-8f7f-82fb18a4c808n@googlegroups.com/ +[linus bitvm3]: https://delvingbitcoin.org/t/garbled-circuits-and-bitvm3/1773 +[rubin garbled]: https://rubin.io/bitcoin/2025/04/04/delbrag/ +[pickhardt rebalance]: https://delvingbitcoin.org/t/research-update-a-geometric-approach-for-optimal-channel-rebalancing/1768 +[rust libsecp256k1 #798]: https://github.com/rust-bitcoin/rust-secp256k1/pull/798 +[news54 foaf rebalance]: /zh/newsletters/2019/07/10/#brainstorming-just-in-time-routing-and-free-channel-rebalancing +[yanofsky priv]: https://github.com/bitcoin-core/meta/issues/19#issuecomment-2961177626 +[cove github]: https://github.com/bitcoinppl/cove/releases +[liana github]: https://github.com/wizardsardine/liana/releases +[breez github]: https://github.com/breez/breez-sdk-liquid/releases/tag/0.9.0 +[starkware tweet]: https://x.com/dimahledba/status/1935354385795592491 +[starkware sv2]: https://github.com/keep-starknet-strange/stratum +[news337 delay]: /zh/newsletters/2025/01/17/#eclair-2936 +[news349 attributable]: /zh/newsletters/2025/04/11/#ldk-2256 +[news342 peer]:/zh/newsletters/2025/02/21/#ldk-3575 From 7193525d96f6ff7b2efb010c63dd106b17009f11 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Sun, 6 Jul 2025 06:33:08 -0500 Subject: [PATCH 143/278] Podcast: add 360 transcription --- .../en/podcast/2025-07-01-newsletter-recap.md | 864 +++++++++++++++++- 1 file changed, 863 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-07-01-newsletter-recap.md b/_posts/en/podcast/2025-07-01-newsletter-recap.md index c23d5f1aa8..b990c2de78 100644 --- a/_posts/en/podcast/2025-07-01-newsletter-recap.md +++ b/_posts/en/podcast/2025-07-01-newsletter-recap.md @@ -19,6 +19,868 @@ and Naiyoma to discuss [Newsletter #360]({{page.reference}}). ## Transcription -_transcription coming soon_ +**Mike Schmidt**: Welcome everyone to Bitcoin Optech Newsletter #360 Recap. +Today, we're going to be talking about fingerprinting Bitcoin Core nodes on the +Bitcoin Network; we're going to talk about descriptors and BIP380; we have some +questions from the Stack Exchange about blocking Knots nodes, OP_CAT, compact +blocks and selfish mining. This week, Murch and I are joined by two guests. +Daniela, do you want to introduce yourself? + +**Daniela Brozzoni**: Yeah, hi everyone. I'm Daniela Brozzoni, I work on +Bitcoin Core full-time. I have a grant from HRF and OpenSats, and I've been in +the Bitcoin space for a while. I've worked on many different projects, so you +might have heard of me already. I'm so happy to be here. So, yeah, hi +everyone. + +_Fingerprinting nodes using `addr` messages_ + +**Mike Schmidt**: Excellent, thanks for your time. I know we had Naiyoma on a +minute ago. I think she dropped. Maybe when she gets back in, she can +introduce herself, but we'll jump into your related news item here, which is the +first one from the newsletter titled, "Fingerprinting nodes using addr +messages". Daniela, you posted to Delving Bitcoin about some fingerprinting +research that you and Naiyoma had conducted. It's been a while since we covered +what fingerprinting of nodes on the network is. I think Murch has given some +good explanations in the past, but maybe perhaps as a lead-in for the audience, +to give them some context, you can explain that high-level concept of +fingerprinting first, and then we can get into the specific fingerprinting +technique that you used in this research that you published? + +**Daniela Brozzoni**: Yes, of course. So, the main protagonists here are nodes +that are running on multiple networks. So, for example, if you have a Bitcoin +node and you run it on Clearnet on Tor, that's the kind of network that we're +trying to fingerprint. And in general, in theory let's say, this node that is +running on Clearnet on Tor for the Bitcoin Network, it appears as two separate +nodes. The network shouldn't know that it's actually the same one. They just +see an IP address, an onion address, and they have no clue. They shouldn't have +a clue that it's actually the same one. But there's various ways to actually +find out, and one of them is what we're going to actually look into today. And +so, what we're able to do is we were able to find that some nodes, they seem +different, but in reality, behind those two interfaces, there was just one node. + +**Mike Schmidt**: Okay, excellent. Now how exactly can you figure that out? +Maybe we can get into the technique now. So, we understand that there's the +ability to use some information to identify that a node is both addresses on the +network, okay, so how can you do something like that? + +**Daniela Brozzoni**: Yes, absolutely. So, our focus was actually to show that +it's possible. And if you look into it, you won't really find a lot of results +like, "Oh, we fingerprinted thousands of nodes", because we didn't want to lift +everyone's privacy, but we wanted to show that it's possible and relatively +easy. And this fingerprint attack uses addr messages, which are some messages +that the Bitcoin nodes send in the network. So, obviously there's a Bitcoin +Network and nodes that connect to that need to know the network addresses of +other nodes so that they can choose better peers if they need to, add some +connections. And so, the network has a whole way of communicating addresses to +each other. And one way to do that is through getaddr and addr messages. So, +getaddr is a message that is used to say, "Hey, peer, please, can you send me +some network addresses?" And so, for example, when one node initiates a +connection to a peer, they will send them a getaddr message, just so they can +get to know other network addresses in the network. + +The response to that getaddr is an addr message, which is what we were mostly +looking into in this research. And an addr message is composed of usually 1,000 +addresses that are paired with a timestamp. So, if I send you an addr message, +it will contain 1,000 network addresses; for every address, a timestamp. That +timestamp has various meanings, but it's usually we mean it as a 'last seen'. +So, last time I've heard about that node in the network, last time I've +connected to it, there's various usage, but last seen is a good way to summarize +it, I think. But when you have the same node that runs on multiple networks and +you start looking into the addr messages, you will notice that they're not +identical, but they're similar because their timestamps are often similar. + +So, let's say I'm a node, I'm running on Clearnet and on Tor, and I get asked on +Clearnet and on Tor, I receive a getaddr, so I need to send addresses back. I +won't send the same exact addr message, but I will, in both cases, reply with +1,000 addresses. And if one address ends up in both responses, it will have the +same timestamp. So, what we did is we basically looked at addr responses from +various nodes, and looking at the similarities in address and timestamps, we +were able to say, "Okay, these two nodes, they're probably unrelated. These two +instead, they're probably the same. These two, I'm pretty sure they're the +same". + +**Mark Erhardt**: So, basically, you look at the response that you get from +another peer when you ask it to give you more addresses of nodes on the network. +And if the timestamps for the last seen for those peers, or the other nodes that +are being parsed, matches across two nodes that are in different networks, very +likely that indicates that it's actually the same node on two networks. I was +wondering, why do we even want to parse that information? What does it add? +It's untrusted, right? They could just parse us whatever they want. Why not +just parse the addresses in the first place? + +**Daniela Brozzoni**: Yes, absolutely. That's actually something that we have +wondered as well, because one of the solutions we were thinking about is, okay, +can we just remove timestamps? But before that, let's look into a bit more what +they are, and then, yeah, then maybe we might remove them. So, every node has +an internal state and it's a structure that it's called addrman; it means +address manager. And so, the addrman of nodes contains all the addresses and a +timestamp. Then it's interpreted as a last seen, and it's used by Bitcoin Core +as a sign of how fresh an address is. So, if the last seen of an address is +five minutes ago, then the address is quite fresh, and so it probably means that +the node is still up and running. While if I have an address with the timestamp +that is one month ago, then maybe, I already know it's not that fresh. Maybe +the node is not there anymore. I don't know really. So, Bitcoin Core nodes +have this internal state and they use timestamps to make some decisions. + +But then there's also timestamps on the P2P network. So, yeah, when a peer +tells me about all the network addresses they know, they send me some +timestamps, but I don't trust them. As I said, they're unverified. If I were a +malicious peer, I could just send anyone addresses with just random numbers, +random timestamps or very old timestamps. So, Bitcoin Core has some guards in +place, I would say, so that if I receive an address with a timestamp, first of +all I check that the timestamp makes sense, I check that it's not in the future, +that it's not too much in the past. If it is, I will set it to a random +default. I think it's about a few days ago. But yeah, internally timestamps, +although they are used to choose, for example, which addresses evict from the +address manager, they're not used to make life-and-death choices. They're not +used to decide which peer to connect to, for example. They're just used to get +an idea of how fresh an address is and they're refreshed in various ways. + +So, when I connect to a peer, if the timestamp I have in the addrman is old, I +will just update it. By old, I think it's older than 20 minutes ago. Not sure, +I will have to double-check. So, there's some ways to refresh that. If I see +an address on the network because the peer is self-announcing their address, I +will refresh their timestamp. But in general, they're not used to make very +important decisions because they come from an untrusted source, which is our +peers in the P2P network. + +**Mark Erhardt**: So, I'm wondering, do we sort by timestamp and select by +timestamp for what we parse to other peers, or do we randomly sample +disregarding the timestamp? + +**Daniela Brozzoni**: It's randomly sampled. There are still some conditions. +I don't remember exactly, but the timestamp can be too old. So, if it's, I +think it's more than 30 days old, I won't send that to my peers. Another +important thing that Bitcoin Core has is a cache that is per network. So, +before Bitcoin Core 0.21, this cache didn't exist. So, whatever getaddr you +would receive, you would just pick 1,000 addresses from your addrman and reply +with that. So, an attacker could just spin up a lot of nodes, connect to the +victim, continue asking getaddr with newer nodes, and the victim would just +basically say all the addresses in their addrman. That was obviously a privacy +leak that by itself, maybe not so bad, but you could mix it with other privacy +leaks and it could be problematic. + +So, what Bitcoin Core has right now, it's a cache. So, every about 24 hours, it +gets refreshed. And so, 1,000 addresses get decided randomly and they get into +this cache. And every time the node receives a getaddr request, it will send +that cache as a response. So, if you connect it to my node, and you would ask a +getaddr ten times today, even from different nodes, etc, you would still receive +exactly the same response, because there's a cache to actually protect, to avoid +leaking too many addresses. And how addresses get into that cache is we just +pick them randomly and we make sure not to send too old addresses. + +**Mike Schmidt**: We have Naiyoma now who's been able to join us. Naiyoma, do +you want to introduce yourself quickly, and then we can get your thoughts on +this research you put together? + +**Naiyoma**: Yeah, sure. Hi everyone, my name is Naiyoma and I'm also a Bitcoin +Core contributor. And together with Daniela, we did work on this attack, trying +to recreate it. Yeah, I think from what I've heard, Daniela has mostly covered +a big bunch of what we are up to. Yeah, so at the moment, from the surface, we +can say, okay, timestamps don't really play a big role, and yes, we can try and +remove them. But it's also kind of difficult to determine, okay, does that mean +that then we are not able to tell which addresses are terrible or haven't been +connected to the network for too long? And what exactly does that mean for the +network? Because we're also trying to avoid a scenario where a node could be +connected to a lot of peers that are just not in the network anymore. So, those +are also some of the things that we're thinking about. + +**Mark Erhardt**: Yeah, maybe related to that is, so our nodes make eight +regular outbound connections, two-blocks-only connections, and there's the +feeler connection, which exactly goes through the unverified nodes and just +tries to ping, "Does a Bitcoin node respond on this IP", and then to refresh the +timestamps or see whether these addresses are useful. So, I think we just +sample, randomly give 1,000, and then the peer who receives the getaddr message, +they have to verify that data themselves. So, from what it sounds like and what +you two have described, I'm very curious whether there's any redeeming qualities +for parsing the timestamps at all. + +**Daniela Brozzoni**: One thing that I just remembered that Martin commented is +that timestamps are useful when nodes self-announce. So, I think once a day, +not sure, but every now and then, nodes just self-announce in the network. They +say, "This is my address", and they put a timestamp near that address because +they use an addr message. And in this way, the address of new nodes, it gets +around in the network. This message is sent. And for example, let's say I'm +Daniela, I want to self-announce, I derive my network IP and my timestamp, I +send it to all my peers. Then my peers, some of them will relay this message, +some of them won't. So, that message will get to my peers' peers. And in this +way, it will continue just going around in the network. But of course, we don't +want to flood the network with my address. So, what nodes do is when they +self-announce, they set the timestamp to the time when they self-announce, so to +right now, and the peers relay the self-announcement only if it's less than ten +minutes older. So, for ten minutes, my address will just go around in the +network, and after ten minutes, peers will just stop relaying it so that they +don't flood the entire network. + +So, in this specific case, timestamps are useful. So, we can just say, okay, +from now on, the addr message doesn't have the timestamp anymore, because it's +also used in this self-announcement phase. However, we could maybe think about +substituting them in the addrman. Instead of having a timestamp, maybe having +some other variables. Maybe when we're applying to a getaddr, we can think +about having some nice defaults that don't leak that much info about our +networks. + +**Mark Erhardt**: Sorry, go ahead. + +**Naiyoma**: Yeah. So, in regards to Martin's comment as well, this was +definitely one of those circumstances where we were thinking, okay, we might use +nLastSuccess, which is a variable, or nLastTry, I think. So, yeah, that's what +we wanted to test next, like substituting nTime with some of these other +variables and check the performance of our peers in the network. + +**Mike Schmidt**: We touched on one of the mitigations that we mentioned in the +newsletter, which was removing the timestamps completely. And I think we're +sort of getting into maybe other potential mitigations. One that we mentioned +in the newsletter was to keep the timestamps, but randomize them somewhat so +that this tech isn't as obvious, I guess. Maybe, Naiyoma, do you want to +comment on that particular mitigation and the other ones you're looking into? + +**Naiyoma**: Yeah, so that's the obvious one and that's the first one we thought +about. So, we are thinking as a node is replying inside the cache response, +then we could randomize within a few days, so not just a few hours because that +wouldn't work, or a few seconds. So, we choose days range and then randomize. +So, if for dual node at home, let's say it's in IPv4 and Tor, that essentially +means that we are going to randomize for the two different networks. So, each +cache interface network is going to reply with different peer timestamps that +have been randomized. So, the chances of us having that overlap of address +timestamps, like being similar, is almost completely eliminated. + +**Mark Erhardt**: So, if you randomize them, you're of course losing the +information about how old things are, to some degree. I mean, it would affect +the newer, very recent addresses more than it would affect the old addresses +because, if it's 25 days or 30 days, that's probably not a huge difference; but +if it's an hour versus three days, that might affect how quickly something is +picked up. I was wondering now, going back to the self-announcement mechanism, +when you self-announce, you're only sending very few addresses, I think maybe +only your address by itself, and then you want the timestamp to actually be +accurate in order to give a small window in which it is actively relayed to +peers. But the peers that receive your self-announcement, do they forward the +solitary address as well, or do they pack it into the bigger announcements? + +**Daniela Brozzoni**: I have to say, I don't remember. I should double-check. + +**Mark Erhardt**: Sorry, I'm trying to put you on the spot here! + +**Naiyoma**: Yeah, I'm also not very sure about that. + +**Mark Erhardt**: Okay, sorry, back to randomizing the addresses. How would +that benefit or be better than just, say, whenever you create a getaddr cache, +you set all the addresses to the date at which you created the cache plus 24 +hours, and then until you update your addr cache, that's the timestamp that you +use, so everything is one day old. And then, after 24 hours, it's almost 48 +hours and then you update your cache and everything's 24 hours old again. Since +we're not relying on it and these big packages don't have that ten-minute window +for self-announcements, do we lose a lot? Is randomizing really better? + +**Daniela Brozzoni**: I'm not sure really. I think so. One thing we really +want to do is to gather feedback from other devs. So, this is actually really +useful. I think you have a preference and that makes a lot of sense. I think +randomizing might just be a bit easier, like a smaller change to the code. But +in both cases, we would really need to study how this would affect the network, +how older nodes might react to this, for example. So, yeah, I think there's +still a lot of open questions. The idea of removing timestamps, it's not +something we just came up. It's something we saw in, I think, an IRC meeting +from 2020, and so Bitcoin developers saying, "Oh, we could just remove +timestamps". So, yeah, it's definitely something that we need to think about +more and we're looking for input on that. But they don't seem to provide that +much value. So, removing them could be definitely an option. + +**Mike Schmidt**: It's interesting. We have a PR later in the newsletter on a +topic we've covered previously, which is also time-related fingerprint leaks and +involving timing on the LN, that we'll get to later. So, this is not the same, +but time-related fingerprinting for Bitcoin nodes. So, Murch, anything you'd +like to add? + +**Mark Erhardt**: I had one more question actually. So, let's assume that there +were no fingerprint-y timestamp data on our getaddr messages anymore, and we are +still running a node on Clearnet and Tor. I assume we have significantly more +than 1,000 nodes. Wouldn't we still leak that it's the same node just by having +an extraordinary overlap in our random 1,000 nodes that we announce? Have you +looked into whether, even without timestamp data, nodes would be +fingerprintable; like, having a node that is on both networks versus having two +random nodes on Clearnet and Tor, can you distinguish them without timestamps? + +**Naiyoma**: Yeah. I think if we were to remove the element of okay, now we +don't have timestamps, there are other metadata that we could use that still +exists in other responses. So, in that way, we can say, okay, we can still come +up with some form of overlap of peers, but we found, okay, so nodes will share a +couple of peers, right? But remember that the 1,000 is a random set from like +20,000, right? So, the assumption is you can have your node and I can have my +node and we can share peers. But even though we can share, like, maybe I'd say +like 40% peers, the chances of these peers also having the same timestamp is +almost always really low. So, that's why we ended up with, okay, timestamp is a +good way to tell that these peers are coming from the exact same addrman. But +yeah, there's still a chance that someone can be able to create an overlap using +the other metadata that we get from addrman. + +**Mark Erhardt**: Okay, so more research is needed. This is the lowest hanging +fruit. It's really easy to tell what nodes are active on both networks with the +timestamp. Without the timestamp, it might still be possible, but harder. Do +you have an idea what the next fingerprint would be after timestamps? "No", is +fine answer here, of course! + +**Naiyoma**: There's actually an open issue on GitHub of how you can fingerprint +dual home nodes just using other factors. So, that's why we're like, it's not +just timestamps, there are other ways that you can achieve this attack, in other +ways. + +**Mark Erhardt**: Awesome. Thank you. + +**Daniela Brozzoni**: Yeah, I'm also thinking you can probably fingerprint very +easily a new node if it has a really, really small addrman, because the addr +response will give up to 1,000 addresses, but not more than 23% of the addrman +size. However, I don't know how weak it is for nodes to fill their addrman. +So, maybe it takes them ten minutes to get to more than 5,000 addresses, I don't +know. And so, maybe it's a fingerprinting attack, but it might be that you have +a very small window to do that, and so it's not really possible. Yeah, now I'm +really interested in looking into if we found nodes with less than 1,000 +addresses in the addrman to match them up, so thank you! + +**Mark Erhardt**: Well, I'm glad to hear that you have some new ideas for +further research. + +**Mike Schmidt**: Well, it sounds like there's some open research to be done. +Daniela has solicited also from the audience if this is something that you're +interested in to provide some feedback as well. Any other parting words for the +audience before we move on? + +**Daniela Brozzoni**: I think there's something we haven't discussed, which is +something me and Naiyoma have talked about a lot. So, I'll let her reply, which +is, "Why bother?" So, when we change Bitcoin Core, we wanted to have a good +reason for doing that. So, why is this attack important? Why should you care? +Why should we even fix it? Yeah, I'll let Naiyoma reply to this, if that's +okay. + +**Naiyoma**: Yeah, sure. So, I would say first of all, there's a chance that +some people are running dual home nodes, and they don't know that you can think +you're on Tor only, and so you're really private, but there's also a chance that +maybe your node is also on IPv4. And so, that's also a big issue, at least on +my end. Daniela, I don't know if you have something to add on to that. + +**Daniela Brozzoni**: Yeah, one thing I was thinking about is that if there's +networks that have very few node bridges, so let's say you have a certain +network and 99% of the nodes connected to the network are only connected to that +network, and there's a few nodes that are connected to that network and IPv4 and +Tor, blah, blah, blah. Then you have very few bridges and you might, with this +attack, be able to identify them and attack them, which might mean try to +partition the network. It might mean try to just connect to them to see +metadata and see things, data, information, right? And also, to build on top of +what Naomi just said, I think maybe by itself, I don't consider this to be the +most critical attack. However, when it's about privacy leaks, you need to +consider that privacy leaks can sum up. So, maybe just this privacy leak, it's +not that much, but with other privacy leaks, that it might mean that you get a +leak which is way bigger. + +**Mark Erhardt**: Yeah. Let's say, for example, you're running an LN node only +on Tor, but your Bitcoin Core node is identifiable and leaks your IP address. +Now, people know exactly what area of the world you live in and perhaps even +more, can identify even further, like your county or whatever. Actually, I was +about to ask another question that you already sort of touched on. Why would +you not just propagate addresses from the network that you're on? So, on the +Tor network, why don't you just announce other Tor nodes and on the Clearnet, +why don't you -- like, if you only announced nodes on the same network as you're +operating on, that would mean zero overlap. + +**Daniela Brozzoni**: Yes, something I don't know. I guess it might be because +you risk some partitioning attacks, but it's something that I was wondering too, +which is why do we have only one address manager and not separate ones? I'm +sure there's a reason, but I have some more research to do for sure into the +code. + +**Mark Erhardt**: Yeah, I was thinking for a small network like I2P, which has, +I think, only a dozen or several dozen nodes; they need to be announced on other +networks to be found. But other than that, I was actually wondering whether +that would also be a solution. Or if the proportion of nodes that you announce +from the same network is significantly higher than the general node population, +that might help. Anyway, I think we're getting really into the details here. + +**Mike Schmidt**: No, that was a great discussion. Thank you both for your +time, Daniela and Naiyoma. You're welcome to hang on or you're free to drop if +you have other things you're working on. + +**Daniela Brozzoni**: Absolutely. I will have to drop, but thanks a lot for +having me and we'll chat soon. + +**Mike Schmidt**: Cheers. + +**Daniela Brozzoni**: Thank you. Bye. + +**Naiyoma**: Thank you as well. I'll just stay in and listen to the rest of the +podcast. + +_Does any software use `H` in descriptors?_ + +**Mike Schmidt**: Great. Our second news item this week is titled, "Does any +software use H in descriptors?" This news item was motivated by Ava Chow, who +posted to the Bitcoin-Dev mailing list, to see if there are any implementations +of descriptors that output descriptors with this capital-H as a hardened +indicator, or permit input of capital-H as a hardened indicator. Murch, I teed +this one up. I was hoping you can elaborate more on what exactly is going on +here with this capital-H. + +**Mark Erhardt**: Yeah, I think the background was, originally the notation used +a single quotation mark to indicate hardened derivation. But of course, +descriptors are used as strings on RPCs and in exchange formats. So, because +single quotation marks are also one of the things that can be used to delimit +strings, that needs to be escaped, and how exactly to escape strings in RPC +commands has been a pain point for some time. And I think that's where the H +got introduced as an alternative mechanism of denoting the hardened derivation. +Now, I think that maybe the thinking around capital- and lowercase-h was that if +it is encoded as a QR code, all capital letters is slightly more compact. And +so, being able to do both might have been just an encoding advantage, but +apparently there was some confusion here. I think it was BIP380, both indicated +that capital-H was allowed, but then had a test vector as an invalid example for +a descriptor with a capital-H. And then also, Bitcoin Core's implementation +does not accept the capital-H, it only accepts a lowercase-h as a hardened +derivation marker. + +_BIPs #1803_ + +So, actually, I said we should leave it in order, but we do have a change later. +It's really an item that refers to several BIPs repository changes, but one of +them talks exactly about this. So, apparently a group of researchers found this +discrepancy where BIP380 says that capital-H is allowed, but then in the test +vectors, gave it as an invalid example. And a change was merged to make that +consistent and move the invalid example to the valid samples instead. But that +seems to have kicked off this conversation that Ava started, which is, does +anyone actually use this? Because currently, Bitcoin Core doesn't accept it; +other BIPs were expecting that this is not allowed; and if nobody actually uses +it and no project has implemented it, as in maybe they can read it, but they +wouldn't write it themselves, it would be safe to only use lowercase. And I +think that's the underlying question here. Ava wants to know, "Is there any +Bitcoin project that uses capital-H as a hardened derivation marker in their +export format, and if not, maybe can we just settle on only using lowercase?" + +So, if you have information on that, if your project implements capital-H as the +export format for hardened derivation, please chime in on the mailing list. + +_Is there any way to block Bitcoin Knots nodes as my peers?_ + +**Mike Schmidt**: Excellent, thanks, Murch. Moving to our monthly segment on +Stack Exchange questions. First one, "Is there any way to block Bitcoin Knots +nodes as my peers?" And I think this person was asking about Bitcoin Knots, but +the answer obviously applies to other node software on the P2P Network. Vojtěch +responded, he actually provided the RPCs that you could string together to +continuously do something like this, by looking at the user agent and then +essentially blocking that particular node, and then continuing that process in a +looping fashion. But he goes on to discourage that such approach, and he also +points to a related Bitcoin Core GitHub issue that also has similar +discouragement from a bunch of people. This was an issue on Bitcoin Core. It's +#30036, "Possible to ban clients by name?" which was actually from over a year +ago. Go ahead, Murch. + +**Mark Erhardt**: Yeah, so what they're talking about here is the user agent. +User agent is a field in the version handshake, I think, or however. Well, +anyway, it's something a peer tells you about themselves. And this user agent +is not very reliable at all. You're literally just trusting whatever the other +node says it is. So, I think it is a terrible idea to start shaping your peer +population just based on the user agent. Well, it might make sense in some +cases where there's spy nodes that exhibit a specific user agent that you don't +want to be connected to. But given that Knots is now something like 13% of the +listening nodes, it could potentially really disrupt the network connectivity if +all the Knots nodes disconnected Core nodes, and vice versa. I think that that +would just make the network worse. And I would push back a little bit on the +motivation or rationale why you would want to disconnect all Knots nodes. + +There was another big discussion about a ban list recently on social media, +where someone put together a list of all the nodes that announced that they're +Knots right now, and put together a script to disconnect them all. I don't +think that that is a useful thing to do and would discourage that. I understand +that emotions are running high in the whole debate recently, but we really, +really care about our outbound peers, we select our outbound peers, they need to +be fairly decent nodes. We constantly reassess and then connect to better +outbound peers if we find better ones, and your node is doing that by itself +already. You don't necessarily need to manually tune that all the time. And +for the inbounds, we do get a bunch of benefits from the inbounds. Inbound +connections are essentially equivalent to outbound connections, except in +transaction announcement and a few other P2P behaviors. I think also during the +sync, we rely more on the outbound peers than the inbound peers. But you're +basically allowing anyone to be an inbound peer to you. A lot of those peers +will be light clients and maybe also pruned nodes, or yeah. + +So, if you have a bunch of inbound nodes that are Knots, or other +implementations like btcd or libbitcoin or Bcoin, or whatever else is out there, +that doesn't really hurt your node. It provides a diversity in peers. So, for +example, if some peer is affected by a consensus failure and not progressing on +the blockchain, which could happen to any implementation, then you still have a +good connectivity by being connected to a diverse set of nodes. So, yes, you +could just getpeerinfo, grep for the user agent string, and if the string, +"Knots", appears in there, call disconnectnode with that IP. But I mean, I +don't think it's a good idea or worth your time. + +**Mike Schmidt**: Are the protections that are already in Bitcoin Core for +misbehaving peers or if a peer is providing good or bad information to you, is +that enough to handle what I think is the concern from these people, which is +that a Knots node is not going to give me high fee-paying transactions +potentially because they're spam? I can see how that could be a concern because +you're potentially missing some of the unconfirmed transactions, but does the +current scoring of peers handle things like that? + +**Mark Erhardt**: Well, regarding high fee transactions, not specifically yet. +There's been another conversation, which we reported on in last week's Recap, +about specifically filtering for the peers that give you the highest value +transactions, which is more of an early conversation right now. But generally, +we do of course kick off nodes that give us invalid data. We also protect nodes +that are very useful to us. So, the nodes that gave us a block the quickest +recently or that announced new transactions to us tend to be protected from +being evicted when we disconnect something. Nodes that are less useful are more +likely to be disconnected. We also protect our nodes across different regions +of the internet, so that we are not connected to all nodes in one data center, +for example. But yeah, it's pretty robust against all this. + +I think a second thing that I heard people be concerned about, "Well, if Knots +nodes download transactions with data in them and then discard them, and then +download the block from me later with these transactions again, then I'm wasting +bandwidth, because I'm sending them more data than they need". I think that was +one concern. And then the other that, "They're not going to give me all +transactions that I might be interested in". But again, if you're a listening +node, your node makes up to 125 connections, and only one of those connections +needs to give you a transaction for you to receive it. And, well, if you're a +listening node, very clearly you do have some excess bandwidth that you're +willing to share with the network. Otherwise, you would be running a +non-listening node or a blocks-only node to save bandwidth, or limiting your +-maxuploadtarget or using other strategies. + +So, if you're sharing your node to, I don't know, LN nodes and other light +clients to download from you, why not other full nodes, even if they have a +strange mempool policy from your node's perspective? + +_What does OP_CAT do with integers?_ + +**Mike Schmidt**: Next question from the Stack Exchange, "What does OP_CAT do +with integers?" The person asking this question was reviewing the OP_CAT BIP, +and noted that it stated something along the lines of, "Given the stack +elements, and there's two stack elements, OP_CAT will push those two stack +elements onto the stack". And the person asking this question said that that +makes sense if those are both byte vectors, but what happens if one or both of +the top elements are integers? And Pieter Wuille responded that Bitcoin Script +only has one type of stack element, which is byte vectors. And then, it's on +the operators or the opcodes to interpret those set of bytes in the way that +that particular opcode is meant to be used. And he also outlines a few unusual +examples of the encoding of integers. Just might be interesting for people to +dig in and look at that if they're curious. + +_Async Block Relaying With Compact Block Relay (BIP152)_ + +"Async Block Relaying With Compact Block Relay). And this is from user BCA, and +then some hex, who both asked the question and answered the question. And this +person provided a figure from the BIP to show how compact block relay works and +then jumps into some of the processes, threads that are spawned and what they're +doing. And I think what was interesting here was they did some analysis on what +would happen if there were missing transactions, how does that impact block +propagations? They have a table in their answer here on Stack Exchange showing +if there's 0% missing transactions, what's the orphan rate? If there's 100% +missing transactions, what's the corresponding propagation time and orphan rate +as well? I don't know if that table is correct, but I thought it was an +interesting answer. Did you take a look at that one, Murch? + +**Mark Erhardt**: Only very briefly, but I know that there's a bunch of other +work in this context currently. I know that one Bitcoin Core contributor is +currently looking into finally implementing, so when you announce a compact +block, you're basically just giving the recipe for people to rebuild the block, +right? You're just saying, "Here's the short ids for all the transactions in +the block in this order". And then another peer, if they have all of these +transactions in their mempool, they can just recombine the block from their +mempool and validate it immediately, without you actually sending the +transaction data again. But if there's even just one transaction missing, they +have to make a round trip and ask back from the peer that announced, "Hey, give +me that missing transaction". + +So, even when compact blocks was proposed as a BIP, one of the future works that +was proposed was, "Well, what if we just send along the transactions that we +expect for our peer to be missing?" I remind you that all the nodes remember +what announcements have gone over the wire on every peer connection. So, for, +every peer, you remember whether either the other side or you have announced a +transaction already. So, you know exactly which transactions the peer is +probably missing, or even more likely you can just give them the transactions +that you were missing and expect that they will be missing them too; because if +they had announced them to you, you wouldn't have been missing them in the first +place. So, there is some work on making compact block announcements slightly +better by including missing transactions, which of course especially works for +small transactions. If you have very large transactions, these packages will +quickly get too big for the standard package size that is allowed in TCP +messages, and then you would get additional round trips anyway. + +So, I don't know if this person that was asking and answering this question is +also engaged in the same research right now, but it is reminiscent of a broader +conversation that is going on right now. So, anyway, the interesting thing is +that if you are missing even only just one transaction, your propagation time +almost doubles; whereas if you miss 10% of your transactions, it's hardly any +longer than missing just one transaction. I think that that's something that +jumped out from the answer. + +**Mike Schmidt**: It sounds like what you outlined there as a work in progress, +sending the transactions along, how does that work if everyone's doing that to +you? Are you now getting potentially, if you have a few missing transactions, +you'll I guess get more bandwidth, because all your peers, if they happen to see +the compact block before you, they're all going to send those extra five +transactions together to you; is that how that would work? + +**Mark Erhardt**: Well, it would if all of our peers were designated compact +block relayers. So, what we actually do is when a peer gives us blocks quickly, +we designate them and tell them, "Hey, I would like you to be a compact block +relay node for me. Could you please, in the future, send me them in the +high-bandwidth mode?" But we only do this, I think, to two or three peers. So, +yes, if you got a compact block announcement from several peers at the same +time, they might send you those couple of transactions extra more than once, but +generally we already limit the number of peers that we ask to do that for us. +And yeah, so specifically, compact block announcements are, I think, usually +around 2 kB or so with all the short ids. And TCP packages, I don't know a ton +about this, but some people around me have been talking about this recently. + +Apparently TCP packages are highly variable, depending on how you route your +connection between two nodes. But they tend to be between less than compact +block relays and slightly more than compact block announcements. And so, +there's only a little bit of room anyway if you want to get it in a single round +trip, how much you can package. So, if there is a small transaction missing or +something, you might be able to push it through in the same TCP package. If a +big transaction is missing, you'll get round trips anyway. + +**Mike Schmidt**: Okay, Murch, sorry, I have two more questions on this topic. +One, and I think I know the answer, but with differing-sized mempools, it may be +that you think your peer has it and they no longer have it. I guess you +wouldn't send it then and then they would just request it, you'd fall back to +the normal mechanism; is that right? + +**Mark Erhardt**: Well, okay, let's dive very briefly into that scenario. You +have a peer that has a way smaller mempool than you. And what they would kick +out of their mempool though is still at the bottom of their mempool. So, +hopefully, if the miners are building the expected blocks that are feerate +optimized or fee optimized, they would be picking transactions from the top of +the block, and those transactions would most likely not be among the ones that +are being evicted, even if you have a smaller mempool. It might be, of course, +that over some time, transactions got added, you built up a little bit of a +backlog, and then there's a series of fast blocks, and your peer's mempool is +emptied out or reaches the point where it previously had been evicting, then you +might run into the scenario. But generally, that's one of the reasons why it's +good for nodes to have similar homogenous mempools, is that they have similar +stuff and then blocks propagate very quickly. + +**Mike Schmidt**: Okay, my last follow-up for now on this. With Knots not +holding in their mempool some of these spam transactions, but you know you sent +that to them, it sounds like they would not benefit as much if there were spam +in the blocks as a non-filtering peer would then, right? Because you would have +thought, "I'm not going to send this transaction along because I already sent it +to them a little while ago", but little did you know that they were actually +discarding that. So, they wouldn't benefit as much from this type of this +optimization that it sounds like people are working on. + +**Mark Erhardt**: I mean, I think compact blocks just probably doesn't work for +them generally. Like, they just will always have a round trip if they kick out +spam. So, they always have round trips to get the missing transactions, and +then need to wait for the block to fully validate before forwarding it. So, +basically, my suspicion would be that among Knots nodes, blocks propagate about +a factor 2 slower. + +**Mike Schmidt**: I won't bother you anymore about compact block relay for a +while. Thank you. + +**Mark Erhardt**: Well, I mean maybe we should have someone on that actually +knows what they're talking about! + +**Mike Schmidt**: You shared some insights into work that is being done that we +haven't covered yet, so I'm curious about it. + +_Why is attacker revenue in selfish mining disproportional to its hash-power?_ + +All right, last question from the Stack Exchange, "Why is attacker revenue in +selfish mining disproportional to its hash-power?" Had a few questions and +discussions about selfish mining recently. Antoine Poinsot followed up to that +question that I just framed, as well as another older selfish mining question. +And one quote that we put in here for the newsletter, that was somewhat common +between both of those, is Antoine says, "The difficulty adjustment does not take +stale blocks into account, which means that decreasing competing miners' +effective hashrate increases a miner's profits (on a long enough timescale) as +much as increasing his own profit". We've linked to both of those questions. I +think there was one last month on selfish mining as well. We also had on +Antoine, and I believe that was #358. Yeah, we had him on in #358. We had a +news item where he came on and talked about selfish mining as well. So, a lot +of selfish mining discussion. Murch, anything you'd add there? + +**Mark Erhardt**: I think we might want to jump in on why this is the case in +the first place. So, let's say a 30% miner starts selfish mining. They will +simply not announce blocks right when they find them. And let's assume they +lose every race. So, if someone else finds a block, they just simply withheld +their block and it's lost. So, basically, this hashrate has disappeared from +the network and if they find a second block, they announce it. So, this is the +case, of course, in about 9% of the blocks. So, you basically reduce the 30% +hashrate that was contributing to the network to 9% making actual progress. So, +in the case that the 9% succeed, which is when they find two blocks in a row, +that's 30% and then 30% again, so they find two blocks before anyone else finds +a block, in that case, they waste all of the hashrate of the rest of the +network. Because if there's a single block found, they just publish their two +blocks and everybody else was wasting their bandwidth. + +So, generally, just the interval in which the blockchain makes progress goes up +and it's actually worse than a zero-sum game, because there's now less block +space to go around for everyone, presumably the feerates are going to go up +because people are competing with their bids on buying less block space, and +then eventually there's a difficulty adjustment. So, the difficulty adjustment +will be based on how much progress the blockchain has made, well, how long it +took to find the last 2,016 blocks, right? And so, since the intervals were +bigger in which the blocks actually increased heights, the difficulty will drop. +And now, the miner is reducing the progress other miners are making by orphaning +some of their progress occasionally, and it is taking its own hashrate out of +the total progress. So, overall, when it resets to the new difficulty, they +have a higher than proportional share of the block rewards, while everybody else +has a lower proportional share, because now it goes back to a zero-sum game that +the whole reward is distributed to the active miners, but the selfish miner is +getting more than 30% of the block rewards. And the transaction fees are higher +and everybody else is getting slightly less than their relative proportion of +the block rewards and fees. So, yeah, any miner above 30% should be eyed with +suspicion. + +**Mike Schmidt**: We would see such a behavior on the network, right? You would +see these pairs of blocks coming out, I guess, disproportionately to what it +would be if they weren't selfish mining, right? So, it would be identifiable. + +**Mark Erhardt**: Yeah, it would be very obvious that it's happening. + +**Mike Schmidt**: So, you could say bad things about them on the internet if you +wanted to, but I don't remember if we had a takeaway with Antoine about what +could be done other than shaming them. + +**Mark Erhardt**: Not much, I think. + +_Bitcoin Core 28.2_ + +**Mike Schmidt**: Okay. Please don't do that. Releases and release candidates. +We have Bitcoin Core v28.2, which is a maintenance release. It contains seven +changes to the build system, two updates to tests, two documentation updates, +and two small refactors. I didn't see anything that was notable. Murch, you +might be more familiar and have something. Sounds like no. So, take a look at +those bug fixes, see if that's something that you want to incorporate into your +release cycle, at least as part of your rotation if you're using multiple nodes. +Yeah, go ahead. + +**Mark Erhardt**: Maybe just to be clear, if you are on 28.1, you would likely +want to upgrade to 28.2 because there's no changes to the RPCs or to the +behaviors or anything unless there was a bug fix. So, if you're worried about +breaking your integration by upgrading a major version, that generally does not +apply to that degree to minor versions which are just bug fixes. So, you +usually would want to be on the latest minor version of the release branch that +you're following. But, well, unless there's something big in there that hasn't +been announced yet, or anything like that, you shouldn't be too worried about +not immediately upgrading either. + +_Bitcoin Core #31981_ + +**Mike Schmidt**: And in most of these by volume are build system changes as +well. Notable code and documentation changes. Bitcoin core #31981 adds a +checkBlock method to the inter-process communication, or IPC, mining interface. +IPC, as a reminder, is a way to communicate with Bitcoin Core binaries in a +lower latency/faster way than using the equivalent RPC methods. And IPC is a +newer way to communicate with Bitcoin Core. We actually covered the IPC bind +option being added to Bitcoin Core in Newsletter #320, and the IPC wrapper for +the mining interface in Newsletter #323. This particular PR adds this new +checkBlock method to the mining IPC interface that we covered previously. And +so, some client application, for example, mining software like Stratum v2 can +now use this checkBlock IPC function to check block validity; whereas +previously, the Stratum v2 or other client software could achieve something +similar with RPC calls, but because RPC is less efficient, you would actually +have to serialize the data into JSON. It was slower, which obviously for +something like mining, or that requires other performance considerations, is not +ideal. So, there's now an IPC version to do something similar that you could +cobble together with RPC. + +_Eclair #3109_ + +Eclair #3109. This prepares Eclair for using attributable failures for +trampoline payments specifically. Attributable failures are a way to sort of +diagnose a pair of nodes as the cause of a forwarding failure or a delay in +forwarding. And so, this PR for Eclair allows Eclair, when it's serving as a +trampoline node, to now process this failure attribution data by unwrapping the +attribution data using its shared secrets, and then using the remaining +information as attribution data for the next trampoline node. But this PR does +not yet relay that attribution data. + +_LND #9950_ + +LND #9950 adds an include_auth_proof flag to various RPC and CLI commands. And +when that particular flag is set, when calling those RPCs, those RPCs will +include additional fields in the result, specifically the signatures from +channel announcements will be included in various RPCs that have that flag. + +_LDK #3868_ + +LDK #3868 brings LDK in line with the open BOLTs PR for the attribution data +spec. And the idea here is that timing of payments can be analyzed by +adversaries to negatively impact privacy. And did we cover this previously? +No, that was the other one. So, if an LN node just trivially reports everyone's +latency, it makes some sorts of attacks easier to do. So, they've put these +latency into buckets based on 100 milliseconds. And this is what was updated in +the LN spec around attributable failures, and now LDK is implementing that +change, it's in the BOLTs spec. We actually had a very in-depth conversation +with a variety of the folks intimately familiar with this discussion. We had +the, "Do attributable failures reduce LN privacy?" discussion back in Podcast +#356. We had Carla Kirk-Cohen on, we had Joost, we had Elias Rohrer, all +talking about whether these delays impact privacy and how the bucketing could +potentially happen. And now you see some of that going into the BOLT spec, now +you see some of that going into LDK here. + +_LDK #3873_ + +LDK #3873 raises the delay for marking a channel as closed after the funding +output is spent. Used to be you could do that after 12 blocks. LDK here has +changed that to 144 blocks to wait, and this allows time for a splice to +propagate the network. We covered a similar PR last week to Eclair. And the +difference in the Eclair PR and this LDK PR is that Eclair used 72 blocks and +LDK is using 144 blocks, which is double that. And actually, in the LN BOLTs +draft around routing gossip that covers this particular value, the current draft +PR says, "Should forget a channel after 72-block delay". I didn't immediately +see a rationale for why there was this larger 144 value in LDK, so I won't +speculate other than to just note it's double what Eclair's doing, and what the +BOLTs draft has currently. + +_Libsecp256k1 #1678_ + +Secp256k1, this is PR #1678, and it adds an interface library so that secp can +be more easily incorporated into other projects. And I wanted to quote +something from the PR here. Person opening this PR says, "Parent projects, +Bitcoin Core in this case, may wish to include secp256k1 in another static +library, for example libbitcoinkernel, so that users are not forced to bring +their own static libsecp256k1. Unfortunately, CMake, which is the build system, +lacks the machinery to link or combine one static library into another. To work +around this, secp256k1_objs, like objects, is exposed as an interface library, +which parent projects can link into static libraries". Murch, if I'm +understanding that correctly, the kernel project is using secp, they don't want +to have a separate binary that they're pointing to, they actually want to have +the source code distributed as part of the kernel. And in order to do that in +build system land and CMake land, you needed to sort of add this wrapper around +it. I'll use the word 'wrapper'; they called it an interface library, so that +you can essentially embed secp into the kernel. Do I have that right? + +**Mark Erhardt**: That's what it sounds like. It might also be relevant for the +project that wraps libbitcoinkernel. So, if libbitcoinkernel has compiled +libsecp256k1, it would probably also be interesting to be available to the +wrapper, like whatever, maybe somebody finally goes and builds a replacement for +Electrum with libbitcoinkernel and they want to, I don't know, scan for silent +payments using libsecp, then it would be silly to have the same library wrapped, +or included twice rather than just once. That's what it sounds like, but I'm +speculating. + +_BIPs #1803_ + +**Mike Schmidt**: Last PR this week is to the BIPs repository, #1803. We talked +about this a little bit earlier. I don't know if you want to elaborate, Murch, +on clarifying BIP380's descriptor grammar? + +**Mark Erhardt**: Yeah, again, the PR that I mentioned earlier, some research +group found that BIP380 had an inconsistency where it explicitly allowed +uppercase-H as a marker for hardened derivation, but then in the test vectors +for invalid examples, it had an example where the uppercase-H was not permitted. +So, this PR moves this test vector to the valid examples. There are also three +other PRs here that deal with slight amendments to descriptors. And I think +there was a clarification on what is exactly permitted with the derivation based +on MuSig2 keys. And, yeah, so if you're implementing key derivation, there's +been a little bit of movement in the BIPs 380 through 390. You might want to +take a look, but it's edge cases, so generally, hopefully that doesn't impact +your project. + +**Mike Schmidt**: That wraps up the newsletter for this week. We want to thank +Naiyoma and Daniela for joining us, and, Murch, thank you for co-hosting. And +thank you all for listening. We'll hear you next week. + +**Mark Erhardt**: Hear you next week. {% include references.md %} From 4c278e0050d205a9406567663d3fa4ddfb84a29f Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Tue, 8 Jul 2025 11:55:44 +0200 Subject: [PATCH 144/278] Newsletter-361: Translate into German (#2408) Co-authored-by: garfiel-d --- .../de/newsletters/2025-07-04-newsletter.md | 357 ++++++++++++++++++ 1 file changed, 357 insertions(+) create mode 100644 _posts/de/newsletters/2025-07-04-newsletter.md diff --git a/_posts/de/newsletters/2025-07-04-newsletter.md b/_posts/de/newsletters/2025-07-04-newsletter.md new file mode 100644 index 0000000000..d84d7ff8c1 --- /dev/null +++ b/_posts/de/newsletters/2025-07-04-newsletter.md @@ -0,0 +1,357 @@ +--- +title: 'Bitcoin Optech Newsletter #361' +permalink: /de/newsletters/2025/07/04/ +name: 2025-07-04-newsletter-de +slug: 2025-07-04-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche beschreibt einen Vorschlag, die Netzwerkverbindungen und das +Peer-Management für Onion-Message-Weiterleitung von denen für HTLC-Weiterleitung im LN zu trennen. +Ebenfalls enthalten sind unsere regulären Abschnitte mit Zusammenfassungen zu Diskussionen über +Konsensänderungen in Bitcoin sowie Beschreibungen aktueller Änderungen an populärer +Bitcoin-Infrastruktursoftware. + +## Nachrichten + +- **Trennung von Onion-Message- und HTLC-Weiterleitung:** Olaluwa Osuntokun + [postete][osuntokun onion] auf Delving Bitcoin einen Vorschlag, Knoten zu erlauben, + separate Verbindungen für die Weiterleitung von [Onion Messages][topic onion messages] + zu nutzen, statt dieselben wie für [HTLCs][topic htlc]. Obwohl dies bereits möglich + ist, etwa bei direkter Weiterleitung (siehe Newsletter [#283][news283 oniondirect] + und [#304][news304 onionreply]), schlägt Osuntokun vor, dass getrennte Verbindungen + immer möglich sein sollten. So könnten Knoten für Onion Messages ein anderes Set an + Peers nutzen als für Zahlungen. Vorteile wären klarere Trennung der Aufgaben, + günstigere Unterstützung vieler Onion-Message-Peers (Channels kosten onchain-Gebühren), + bessere Privatsphäre durch Schlüsselrotation und schnellere Zustellung von Onion + Messages, da sie nicht durch das HTLC-Protokoll blockiert werden. Osuntokun liefert + Details zum vorgeschlagenen Protokoll. + + Einige Entwickler äußerten Bedenken, dass ein Onion-Message-Netzwerk Knoten mit zu + vielen Peers fluten könnte. Aktuell haben Knoten meist nur Verbindungen zu ihren + Channel-Partnern. Das Erstellen eines UTXO für einen Channel kostet Geld und ist + eindeutig für Knoten und Partner – also ein UTXO pro Verbindung. Selbst wenn + Onion-Message-Verbindungen onchain abgesichert werden müssten, könnte ein UTXO für + tausende Verbindungen genutzt werden. + + Mindestens ein Teilnehmer unterstützte Osuntokuns Vorschlag, mehrere äußerten aber + Bedenken wegen DoS-Risiken. Die Diskussion war zum Redaktionsschluss noch im Gange. + +## Konsensänderungen + +_Ein monatlicher Abschnitt mit Zusammenfassungen zu Vorschlägen und Diskussionen über +Konsensänderungen in Bitcoin._ + +- **CTV+CSFS-Vorteile für PTLCs:** Entwickler setzten eine frühere Diskussion (siehe + [Newsletter #348][news348 ctvstep]) über die Vorteile von [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] + (CTV), [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (CSFS) oder beide für verschiedene + Protokolle fort. Besonders interessant: Gregory Sanders [schrieb][sanders ptlc], dass CTV+CSFS + „das Update des [LN] auf [PTLCs][topic ptlc] beschleunigen würde, selbst wenn [LN-Symmetry][topic eltoo] + nie übernommen wird. Re-bindable Signaturen vereinfachen das Stapeln von Protokollen erheblich.“ + Sjors Provoost [fragte][provoost ptlc] nach Details, Sanders [antwortete][sanders ptlc2] mit + einem [Link][sanders gist] zu früheren Forschungsergebnissen (siehe [Newsletter #268][news268 ptlc]) und + ergänzte, dass PTLCs mit heutigen Protokollen zwar möglich, aber mit rebindable (flexibel neu zuzuweisenden Signaturen) + deutlich einfacher wären. + + Anthony Towns [merkte zusätzlich an][towns ptlc], dass es auch an Werkzeugen und Standardisierung fehlt, + um eine PTLC-Offenlegung in Kombination mit einer [MuSig][topic musig] 2-von-2-Signatur (was onchain effizient wäre) + oder sogar mit allgemeinen Transaktionssignaturen (z.B. `x CHECKSIGVERIFY y CHECKSIG`) durchzuführen. + Dafür wäre Unterstützung für [Adaptor-Signaturen][topic adaptor signatures] in MuSig2 nötig, die aber weder Teil + der Spezifikation sind noch in secp256k1 implementiert wurden (sie wurden [entfernt][libsecp256k1 #1479]). + Weniger effizient wäre es, eine separate Adaptor-Signatur zu verwenden, aber selbst einfache Adaptor-Signaturen + für [Schnorr-Signaturen][topic schnorr signatures] sind in secp256k1 nicht verfügbar. Auch im experimentellen + secp256k1-zkp-Projekt sind sie nicht enthalten. Sobald das Tooling bereit ist, könnte der PTLC-Support hinzugefügt + werden. Derzeit hält es jedoch offenbar niemand für prioritär genug, um die Kryptografie zu standardisieren und zu + optimieren. Mit [CAT][topic op_cat]+CSFS könnte man das Tooling-Problem umgehen, allerdings auf Kosten der + Onchain-Effizienz. Mit nur CSFS bestehen die Tooling-Probleme weiterhin, da Adaptor-Signaturen nötig sind, um zu + verhindern, dass der Gegenpart einen anderen R-Wert für die Signatur wählt. Diese Probleme sind unabhängig von der + Update-Komplexität und den Peer-Protokoll-Änderungen, die Gregory Sanders oben beschreibt. + +- **Vault-Output-Script-Deskriptor:** Sjors Provoost [postete][provoost ctvdesc] auf Delving + Bitcoin zur Diskussion, wie die Wiederherstellungsinformationen für eine Wallet mit + [Vaults][topic vaults] per [Output Script Deskriptor][topic descriptors] spezifiziert werden + könnten. Im Fokus standen Vaults auf Basis von [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] + (CTV), wie sie James O'Beirnes [simple-ctv-vault][] (siehe [Newsletter #191][news191 simple-ctv-vault]) + implementiert. + + Provoost zitierte einen [Kommentar][ingala vaultdesc] von Salvatore Ingala, der meinte, + Deskriptoren seien das falsche Werkzeug für diesen Zweck – eine Meinung, die Sanket + Kanjalkar [teilte][kanjalkar vaultdesc1], aber [einen Workaround][kanjalkar vaultdesc2] + fand: Ein Vault, bei dem Kapital zunächst in einen normalen Deskriptor eingezahlt und + dann in einen CTV-Vault verschoben wird. So können Nutzer nicht versehentlich Geld + verlieren, und der CTV-Vault-Deskriptor bleibt einfach und vollständig. + +- **Weitere Diskussion zu CTV+CSFS-Vorteilen für BitVM:** Entwickler setzten die frühere + Diskussion (siehe [Newsletter #354][news354 bitvm]) fort, wie [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] + (CTV) und [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (CSFS) BitVM-Transaktionsgrößen + um etwa das 10-fache reduzieren und nicht-interaktive Peg-ins ermöglichen könnten. + Anthony Towns [identifizierte][towns ctvbitvm] eine Schwachstelle im ursprünglichen + Vertragsvorschlag; er und andere Entwickler beschrieben Workarounds. Weitere Diskussionen + drehten sich um Vorteile des vorgeschlagenen [OP_TXHASH][]-Opcodes gegenüber CTV. + Chris Stewart [implementierte][stewart ctvimp] einige Ideen mit Bitcoin Core-Testsoftware. + +- **Offener Brief zu CTV und CSFS:** James O'Beirne [postete][obeirne letter] einen offenen + Brief an die Bitcoin-Dev-Mailingliste, unterzeichnet von 66 Personen (Stand Redaktionsschluss), + viele davon Bitcoin-Entwickler. Der Brief fordert, dass Bitcoin-Core-Mitwirkende die + Überprüfung und Integration von [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (CTV) + und [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (CSFS) in den nächsten sechs Monaten + priorisieren. Der Thread enthält über 60 Antworten. Einige technische Highlights: + + - *Bedenken und Alternativen zu Legacy-Support:* [BIP119][] spezifiziert CTV für + Witness Script v1 ([Tapscript][topic tapscript]) und Legacy Script. Gregory Sanders + [schreibt][sanders legacy], dass Legacy-Support die Prüfoberfläche unnötig vergrößert, + ohne Mehrwert. O'Beirne [entgegnet][obeirne legacy], dass Legacy-Support in manchen + Fällen 8 vbytes sparen kann, Sanders [verweist][sanders p2ctv] auf eine P2CTV- + Implementierung, die diese Ersparnis auch im Witness Script ermöglicht. + + - *Grenzen von CTV-only-Vaults:* Jameson Lopp [merkte an][lopp ctvvaults], dass er + besonders an [Vaults][topic vaults] interessiert ist, und diskutierte, welche + Eigenschaften CTV-Vaults bieten, wie sie sich von Vaults mit presig-Transaktionen + unterscheiden und ob sie echte Sicherheitsgewinne bringen. Wichtige Erkenntnisse: + + - *Adresswiederverwendung:* Sowohl presig- als auch CTV-Vaults müssen verhindern, + dass Nutzer Vault-Adressen wiederverwenden, da sonst Kapitalverlust droht. Eine + Möglichkeit ist ein zweistufiges Verfahren mit zwei Onchain-Transaktionen, um + Kapital in den Vault einzuzahlen. Fortgeschrittene Vaults, die zusätzliche + Konsensänderungen benötigen, hätten dieses Problem nicht und erlauben Einzahlungen + auch auf wiederverwendete Adressen (was allerdings die + [Privatsphäre verringert][topic output linking]). + + - *Diebstahl gestaffelter Gelder:* Beide Vault-Arten erlauben den Diebstahl + autorisierter Auszahlungen. Beispiel: Vault-Nutzer Bob möchte 1 BTC an Alice + zahlen. Mit presig- und CTV-Vaults nutzt Bob folgendes Verfahren: + + - Er zieht 1 BTC (ggf. plus Gebühren) aus seinem Vault auf eine Zwischenadresse ab. + + - Er wartet die vom Vault definierte Zeit ab. + + - Er transferiert 1 BTC an Alice. + + Wenn Mallory Bobs Schlüssel für die Zwischenadresse gestohlen hat, kann sie den + 1 BTC nach Abschluss der Auszahlung, aber vor Bestätigung der Transaktion an Alice + stehlen. Selbst wenn Mallory auch den Auszahlungsschlüssel kompromittiert, kann sie + kein Kapital mehr aus dem Vault stehlen, da Bob jede ausstehende Auszahlung + abbrechen und die Mittel auf eine sichere Adresse mit einem besonders geschützten + Schlüssel umleiten kann. + + Fortgeschrittene Vaults benötigen keinen Zwischenstopp + mehr: Bobs Auszahlung kann nur an Alice oder die sichere Adresse gehen. Das + verhindert, dass Mallory zwischen Auszahlung und Ausgabe Kapital stehlen kann. + - *Key-Deletion:* Vorteil von CTV-Vaults ist, dass keine privaten Schlüssel gelöscht + werden müssen, um sicherzustellen, dass nur die presig-Transaktionen ausgegeben + werden können. Gregory Maxwell [merkt an][maxwell autodelete], dass es einfach ist, + Software so zu gestalten, dass der Schlüssel direkt nach dem Signieren gelöscht + wird, ohne ihn dem Nutzer preiszugeben. Aktuell ist kein Hardware-Signiergerät + bekannt, das dies direkt unterstützt, eines unterstützt es manuell. Allerdings + unterstützt auch kein Hardwaregerät CTV, selbst zu Testzwecken nicht. Fortgeschrittene + Vaults hätten ebenfalls diesen Vorteil, müssten aber in Software und Hardware + integriert werden. + + - *Statischer Zustand:* Ein behaupteter Vorteil von CTV-Vaults gegenüber presig-Vaults + ist, dass sich alle Informationen zur Wiederherstellung der Wallet aus einem + statischen Backup (z.B. einem Output Script Deskriptor) berechnen lassen könnten. + Es gibt jedoch bereits presig-Vaults, die ebenfalls statische Backups erlauben, + indem sie die nicht-deterministischen Teile des presig-Zustands in den Onchain- + Transaktionen selbst speichern (siehe [Newsletter #255][news255 presig vault state]). + Optech geht davon aus, dass auch fortgeschrittene Vaults aus statischem Zustand + wiederhergestellt werden könnten, konnte dies aber bis Redaktionsschluss nicht + verifizieren. + - *Antworten von Bitcoin-Core-Mitwirkenden:* Zum Zeitpunkt des Schreibens antworteten vier + von Optech als aktiv anerkannte Bitcoin-Core-Mitwirkende auf den Brief in der Mailingliste. + Sie sagten: + + - [Gregory Sanders][sanders ctvcom]: „Dieser Brief bittet um Feedback aus der technischen + Community und das ist mein Feedback. Nicht implementierte BIPs, die seit Jahren nicht + aktualisiert wurden, sind generell kein Zeichen für einen gesunden Vorschlag und + sicher keine Grundlage, technische Ratschläge von jemandem abzulehnen, der sich intensiv + damit beschäftigt hat. Ich lehne dieses Framing, die Anhebung der Hürde für Änderungen + an diesem Vorschlag auf nur noch grobe Fehler und natürlich ein zeitbasiertes Ultimatum + für BIP119 ab. Ich halte CTV (im Sinne der Fähigkeiten) + CSFS weiterhin für prüfenswert, + aber das ist ein sicherer Weg, es zu versenken.“ + + - [Anthony Towns][towns ctvcom]: „Aus meiner Sicht hat die CTV-Diskussion wichtige Schritte + ausgelassen, und statt diese nachzuholen, versuchen Befürworter seit mindestens drei + Jahren, durch öffentlichen Druck eine beschleunigte Umsetzung zu erzwingen. Ich habe + versucht, CTV-Befürwortern bei den fehlenden Schritten zu helfen, aber meist führte das + zu Schweigen oder Beleidigungen statt zu etwas Konstruktivem. Für mich schafft das nur + Anreizprobleme, löst sie aber nicht.“ + + - [Antoine Poinsot][poinsot ctvcom]: „Die Wirkung dieses Briefs war, wie zu erwarten, + ein erheblicher Rückschritt beim Fortschritt dieses Vorschlags (oder allgemein dieses + Bündels an Fähigkeiten). Ich weiß nicht, wie wir davon zurückkommen, aber es erfordert + unbedingt, dass jemand aufsteht und tatsächlich die Arbeit macht, technisches Feedback + aus der Community zu adressieren und echte Anwendungsfälle zu demonstrieren. Der Weg + nach vorn muss auf Konsensbildung durch starke objektive, technische Argumente basieren, + nicht durch viele Interessensbekundungen ohne aktives Vorantreiben des Vorschlags.“ + + - [Sjors Provoost][provoost ctvcom]: „Ich möchte auch meine eigene Motivation darlegen. + Vaults scheinen das einzige Feature zu sein, das durch den Vorschlag ermöglicht wird, + das ich persönlich wichtig genug finde, um daran zu arbeiten. [...] Bis vor kurzem + schien mir, dass der Schwung für Vaults bei OP_VAULT lag, was wiederum OP_CTV erfordern + würde. Aber ein einzelner, zweckgebundener Opcode ist nicht ideal, daher schien dieses + Projekt nicht voranzukommen. [...] Andererseits habe ich nichts gegen CTV + CSFS; ich + habe kein Argument gesehen, dass sie schädlich wären. Da das MeVil-Potenzial gering ist, + kann ich mir vorstellen, dass andere Entwickler diese Änderungen vorsichtig entwickeln + und einführen. Ich würde den Prozess nur beobachten. Was ich ablehnen würde, ist eine + alternative Python-Implementierung und ein Aktivierungsclient wie von Co-Signer Paul + Sztorc vorgeschlagen.“ + + - *Statements der Unterzeichner:* Die Unterzeichner des Briefs präzisierten ihre Absichten + in Folgebeiträgen: + - [James O'Beirne][obeirne ctvcom]: „Alle Unterzeichner wollen ausdrücklich die zeitnahe + Überprüfung, Integration und Aktivierungsplanung speziell für CTV+CSFS sehen.“ + + - [Andrew Poelstra][poelstra ctvcom]: „Frühere Entwürfe des Briefs forderten tatsächlich + Integration und sogar Aktivierung, aber ich habe keinen dieser frühen Entwürfe + unterzeichnet. Erst als die Formulierung auf Priorisierung und Planung (und eine + 'respektvolle Bitte' statt einer Forderung) abgeschwächt wurde, habe ich unterschrieben.“ + + - [Steven Roose][roose ctvcom]: „[Der Brief] bittet Core-Mitwirkende lediglich, diesen + Vorschlag mit einer gewissen Dringlichkeit auf ihre Agenda zu setzen. Keine Drohungen, + keine harten Worte. Da bisher nur wenige Core-Mitwirkende an der Diskussion teilgenommen + hatten, schien es ein sinnvoller nächster Schritt, sie um eine Positionierung zu bitten. + Ich lehne einen Ansatz mit unabhängigen Aktivierungsclients entschieden ab und denke, die + Haltung dieser E-Mail entspricht der Präferenz, dass Core bei Protokoll- + Upgrades eingebunden ist.“ + + - [Harsha Goli][goli ctvcom]: „Die meisten haben unterschrieben, weil sie wirklich nicht + wussten, was der nächste Schritt sein sollte, und der Druck für Transaktions-Commitments + so groß war, dass eine schlechte Option (Unterschriftenaktion) besser erschien als + Untätigkeit. In Vorgesprächen (ermittelt durch meine Branchenumfrage) erhielt ich von + vielen Unterzeichnern nur Ermahnungen zum Brief. Ich kenne tatsächlich niemanden, der + ihn explizit für eine gute Idee hielt. Und trotzdem haben sie unterschrieben. Das ist + ein Signal.“ + +- **OP_CAT ermöglicht Winternitz-Signaturen:** Entwickler Conduition [postete][conduition winternitz] + auf der Bitcoin-Dev-Mailingliste eine [Prototyp-Implementierung][conduition impl], die mit dem + vorgeschlagenen [OP_CAT][topic op_cat]-Opcode und weiteren Script-Befehlen + quantenresistente Signaturen nach dem Winternitz-Protokoll durch Konsenslogik verifizierbar macht. + Die Implementierung benötigt fast 8.000 Bytes für Schlüssel, Signatur und Script (wobei der Großteil + durch den Witness-Discount auf etwa 2.000 vbytes onchain reduziert wird). Das ist etwa 8.000 vbytes + kleiner als ein anderes, zuvor von Jeremy Rubin [vorgeschlagenes][rubin lamport], auf `OP_CAT` basierendes, quantenresistentes + [Lamport-Signaturverfahren][rubin lamport]. + +- **Commit/Reveal-Funktion für Post-Quantum-Recovery:** Tadge Dryja [postete][dryja fawkes] auf + der Bitcoin-Dev-Mailingliste eine Methode, wie man UTXOs mit [quantenanfälligen][topic quantum + resistance] Signaturalgorithmen + auch dann sicher ausgeben kann, wenn schnelle Quantencomputer es sonst erlauben würden, die Ausgabe + einer Transaktion umzuleiten (zu stehlen). Dies würde einen Soft Fork erfordern und ist eine Variante + eines früheren Vorschlags von Tim Ruffing (siehe [Newsletter #348][news348 fawkes]). + + Um einen Output in Dryjas Schema auszugeben, erstellt der Ausgebende ein Commitment zu drei Daten: + + 1. Ein Hash des Public Keys, der zum Private Key gehört, der die Mittel kontrolliert, `h(pubkey)`. + Dies ist der _Address Identifier_. + + 2. Ein Hash aus Public Key und der txid der Transaktion, die der Ausgebende letztlich senden will, + `h(pubkey, txid)`. Dies ist der _Sequence Dependent Proof_. + + 3. Die txid der geplanten Transaktion. Dies ist die _Commitment txid_. + + Keine dieser Informationen gibt den zugrundeliegenden Public Key preis, der in diesem Schema nur dem + Besitzer des UTXO bekannt ist. + + Das dreiteilige Commitment wird in einer Transaktion mit einem quantensicheren Algorithmus, z.B. als + `OP_RETURN`-Output, veröffentlicht. Ein Angreifer könnte versuchen, ein eigenes Commitment mit demselben + Address Identifier, aber einer anderen Commitment-txid zu senden, das die Mittel an seine eigene Wallet + leitet. Da er aber den Public Key nicht kennt, kann er keinen gültigen Sequence Dependent Proof erzeugen. + Das ist für Full Nodes zunächst nicht offensichtlich, aber sie können das Angreifer-Commitment ablehnen, + sobald der UTXO-Besitzer den Public Key offenlegt. + + Nach ausreichender Bestätigung des Commitments offenbart der Ausgebende die vollständige Transaktion, + die zur Commitment-txid passt. Full Nodes prüfen, ob der Public Key zum Address Identifier passt und + ob er zusammen mit der txid dem Sequence Dependent Proof entspricht. Dann löschen Full Nodes alle + Commitments für diesen Address Identifier bis auf das älteste (am tiefsten bestätigte). Nur die zuerst + bestätigte txid mit gültigem Sequence Dependent Proof kann in eine bestätigte Transaktion aufgelöst werden. + + Dryja beschreibt weitere Details, wie dieses Schema als Soft Fork eingeführt werden könnte, wie das + Commitment-Byte halbiert werden kann und was Nutzer und Software heute tun können, um sich auf das + Verfahren vorzubereiten – sowie Einschränkungen für Nutzer von Script- und [Scriptless-Multisignaturen][topic multisignature]. + +- **OP_TXHASH-Variante mit Sponsorship:** Steven Roose [postete][roose txsighash] auf Delving + Bitcoin über eine Variante von `OP_TXHASH` namens `TXSIGHASH`, die 64-Byte-[Schnorr-Signaturen][topic schnorr signatures] + um zusätzliche Bytes erweitert, um festzulegen, auf welche Felder in der Transaktion (oder in + verwandten Transaktionen) sich die Signatur bezieht. Neben den bisher vorgeschlagenen Commitment-Feldern + für `OP_TXHASH` merkt Roose an, dass die Signatur auch auf eine frühere Transaktion im Block committen + könnte, was eine effiziente Form von [Transaction Sponsorship][topic fee sponsorship] ermöglicht + (siehe [Newsletter #295][news295 sponsor]). Er analysiert die Onchain-Kosten dieses Mechanismus im + Vergleich zu bestehendem [CPFP][topic cpfp] und einem früheren Sponsorship-Vorschlag und kommt zu dem Schluss: + „Mit [TXSIGHASH] Stacking können die Kosten in virtuellen Bytes jeder gestapelten Transaktion sogar + niedriger sein als ihre ursprünglichen Kosten ohne Sponsor. [...] Außerdem sind alle Inputs einfache + Key-Spends, was bedeutet, dass sie mit [CISA][topic cisa] aggregiert werden könnten.“ + + Zum Redaktionsschluss gab es noch keine öffentlichen Antworten auf den Beitrag. + +## Wichtige Code- und Dokumentationsänderungen + +_Bemerkenswerte aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], +[Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], +[Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], +[Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und [BINANAs][binana repo]._ + +- [Bitcoin Core #32540][] führt den REST-Endpunkt `/rest/spenttxouts/BLOCKHASH` ein, der + eine Liste ausgegebener Transaction Outputs (Prevouts) für einen Block liefert, primär + im kompakten Binärformat, aber auch als JSON und Hex. Das verbessert die Performance + externer Indexer. + +- [Bitcoin Core #32638][] prüft, ob jeder gelesene Block von der Festplatte zum erwarteten + Blockhash passt, um Bitrot und Index-Verwechslungen zu erkennen. Dank Header-Hash-Cache + (siehe [Bitcoin Core #32487][]) ist diese Prüfung praktisch ohne Overhead. + +- [Bitcoin Core #32819][] und [#32530][Bitcoin Core #32530] setzen die Maximalwerte für + `-maxmempool` und `-dbcache` auf 500 MB bzw. 1 GB auf 32-Bit-Systemen. Höhere Werte + könnten zu OOM-Fehlern führen. + +- [LDK #3618][] implementiert die Client-Logik für [Async Payments][topic async payments], + sodass ein Offline-Empfänger [BOLT12 Offers][topic offers] und statische Rechnungen mit + einem immer-online LSP vorbereiten kann. Der PR führt einen Async-Offer-Cache im + `ChannelManager` ein und definiert neue Onion-Messages und Hooks für die Kommunikation + mit dem LSP und integriert die Zustandsmaschine in den `OffersMessageFlow`. + +{% include snippets/recap-ad.md when="2025-07-08 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32540,32638,32819,3618,1479,32487,32530" %} +[news255 presig vault state]: /en/newsletters/2023/06/14/#discussion-about-the-taproot-annex +[news348 ctvstep]: /de/newsletters/2025/04/04/#vorteile-von-ctv-csfs +[news268 ptlc]: /en/newsletters/2023/09/13/#ln-messaging-changes-for-ptlcs +[news191 simple-ctv-vault]: /en/newsletters/2022/03/16/#continued-ctv-discussion +[news354 bitvm]: /de/newsletters/2025/05/16/#beschreibung-der-vorteile-fur-bitvm-durch-op-ctv-und-op-csfs +[rubin lamport]: https://gnusha.org/pi/bitcoindev/CAD5xwhgzR8e5r1e4H-5EH2mSsE1V39dd06+TgYniFnXFSBqLxw@mail.gmail.com/ +[osuntokun onion]: https://delvingbitcoin.org/t/reimagining-onion-messages-as-an-overlay-layer/1799/ +[news283 oniondirect]: /en/newsletters/2024/01/03/#ldk-2723 +[news304 onionreply]: /en/newsletters/2024/05/24/#core-lightning-7304 +[sanders ptlc]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/7 +[provoost ptlc]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/80 +[sanders ptlc2]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/81 +[sanders gist]: https://gist.github.com/instagibbs/1d02d0251640c250ceea1c66665ec163 +[towns ptlc]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/82 +[provoost ctvdesc]: https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766/ +[simple-ctv-vault]: https://github.com/jamesob/simple-ctv-vault +[ingala vaultdesc]: https://github.com/bitcoin/bips/pull/1793#issuecomment-2749295131 +[kanjalkar vaultdesc1]: https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766/3 +[kanjalkar vaultdesc2]: https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766/9 +[towns ctvbitvm]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/8 +[op_txhash]: /en/newsletters/2022/02/02/#composable-alternatives-to-ctv-and-apo +[stewart ctvimp]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/25 +[obeirne letter]: https://mailing-list.bitcoindevs.xyz/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com/ +[sanders legacy]: https://mailing-list.bitcoindevs.xyz/bitcoindev/b17d0544-d292-4b4d-98c6-fa8dc4ef573cn@googlegroups.com/ +[obeirne legacy]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPfvXfKEgA0RCvxR=mP70sfvpzTphTZGidy=JuSK8f1WnM9xYA@mail.gmail.com/ +[sanders p2ctv]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/72?u=harding +[lopp ctvvaults]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CADL_X_fxwKLdst9tYQqabUsJgu47xhCbwpmyq97ZB-SLWQC9Xw@mail.gmail.com/ +[maxwell autodelete]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAAS2fgSmmDmEhi3y39MgQj+pKCbksMoVmV_SgQmqMOqfWY_QLg@mail.gmail.com/ +[sanders ctvcom]: https://groups.google.com/g/bitcoindev/c/KJF6A55DPJ8/m/XVhyLCJiBQAJ +[towns ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aEu8CqGH0lX5cBRD@erisian.com.au/ +[poinsot ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/GLGZ3rEDfqaW8jAfIA6ac78uQzjEdYQaJf3ER9gd4e-wBXsiS2NK0wAj8LWK8VHf7w6Zru3IKbtDU5NM102jD8wMjjw8y7FmiDtQIy9U7Y4=@protonmail.com/ +[provoost ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/0B7CEBEE-FB2B-41CF-9347-B9C1C246B94D@sprovoost.nl/ +[obeirne ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPfvXfLc5-=UVpcvYrC=VP7rLRroFviLTjPQfeqMQesjziL=CQ@mail.gmail.com/ +[poelstra ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aEsvtpiLWoDsfZrN@mail.wpsoftware.net/ +[roose ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/035f8b9c-9711-4edb-9d01-bef4a96320e1@roose.io/ +[goli ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/mc0q6r14.59407778-1eb1-4e57-bcf2-c781d6f70b01@we.are.superhuman.com/ +[conduition winternitz]: https://mailing-list.bitcoindevs.xyz/bitcoindev/uCSokD_EM3XBQBiVIEeju5mPOy2OU-TTAQaavyo0Zs8s2GhAdokhJXLFpcBpG9cKF03dNZfq2kqO-PpxXouSIHsDosjYhdBGkFArC5yIHU0=@proton.me/ +[conduition impl]: https://gist.github.com/conduition/c6fd78e90c21f669fad7e3b5fe113182 +[lamport signature]: https://en.wikipedia.org/wiki/Lamport_signature +[dryja fawkes]: https://mailing-list.bitcoindevs.xyz/bitcoindev/cc2f8908-f6fa-45aa-93d7-6f926f9ba627n@googlegroups.com/ +[news348 fawkes]: /de/newsletters/2025/04/04/#sicherer-nachweis-des-utxo-besitzes-durch-offenlegung-eines-sha256-preimages +[roose txsighash]: https://delvingbitcoin.org/t/jit-fees-with-txhash-comparing-options-for-sponsorring-und-stacking/1760 +[news295 sponsor]: /en/newsletters/2024/03/27/#transaction-fee-sponsorship-improvements \ No newline at end of file From 64ccfc40ed0a35efa6aaff77eb57c64b290ce23c Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 10 Jul 2025 09:11:58 -0500 Subject: [PATCH 145/278] Podcast: add 361 recap --- .../en/newsletters/2025-07-04-newsletter.md | 24 ++++++++++--------- .../en/podcast/2025-07-08-newsletter-recap.md | 24 +++++++++++++++++++ 2 files changed, 37 insertions(+), 11 deletions(-) create mode 100644 _posts/en/podcast/2025-07-08-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-07-04-newsletter.md b/_posts/en/newsletters/2025-07-04-newsletter.md index b5ceae7673..eb15ad3e3d 100644 --- a/_posts/en/newsletters/2025-07-04-newsletter.md +++ b/_posts/en/newsletters/2025-07-04-newsletter.md @@ -47,7 +47,7 @@ to popular Bitcoin infrastructure software. Although at least one respondent was supportive of Osuntokun's proposal, several respondents so far mentioned concern about the denial of service risk. Discussion was ongoing at the time of - writing. + writing. {% assign timestamp="2:06" %} ## Changing consensus @@ -88,7 +88,7 @@ Bitcoin's consensus rules._ adaptor signatures to prevent your counterparty from choosing a different R value for the signature. These issues are independent of the update complexity and peer protocol updates Gregory Sanders - describes above." + describes above." {% assign timestamp="5:45" %} - **Vault output script descriptor:** Sjors Provoost [posted][provoost ctvdesc] to Delving Bitcoin to discuss how the recovery information for a wallet @@ -109,7 +109,7 @@ Bitcoin's consensus rules._ assumes all funds paid to the typical descriptor are moved into a vault using the same settings every time. This would allow the CTV vault descriptor to be succinct and complete without any contortions to the descriptor - language. + language. {% assign timestamp="15:21" %} - **Continued discussion about CTV+CSFS advantages for BitVM:** developers continued the previous discussion (see [Newsletter #354][news354 @@ -122,7 +122,7 @@ Bitcoin's consensus rules._ the proposed [OP_TXHASH][] opcode rather than CTV. Chris Stewart [implemented][stewart ctvimp] some of the discussed ideas using Bitcoin Core's test software, validating those parts of the discussion and providing - concrete examples for reviewers. + concrete examples for reviewers. {% assign timestamp="22:57" %} - **Open letter about CTV and CSFS:** James O'Beirne [posted][obeirne letter] an open letter to the Bitcoin-Dev mailing signed by 66 individuals (as of this writing), @@ -132,6 +132,8 @@ Bitcoin's consensus rules._ [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (CSFS) within the next six months." The thread contains over 60 replies. Some technical highlights include: + {% assign timestamp="27:59" %} + - *Concerns and alternatives to legacy support:* [BIP119][] specifies CTV for both witness script v1 ([tapscript][topic tapscript]) and legacy script. Gregory Sanders [writes][sanders legacy] that "legacy script support [...] @@ -302,7 +304,7 @@ Bitcoin's consensus rules._ is subject to the witness discount, reducing onchain weight to about 2,000 vbytes). This is about 8,000 vbytes smaller than another `OP_CAT`-based quantum-resistant [Lamport signature][] scheme - [previously proposed][rubin lamport] by Jeremy Rubin. + [previously proposed][rubin lamport] by Jeremy Rubin. {% assign timestamp="1:12:27" %} - **Commit/reveal function for post-quantum recovery:** Tadge Dryja [posted][dryja fawkes] to the Bitcoin-Dev mailing list a method for allowing @@ -354,7 +356,7 @@ Bitcoin's consensus rules._ deployed as a soft fork, how the commitment byte could be reduced by half, and what users and software today can do to prepare for using this scheme---as well as limitations in this scheme for - users of both scripted and [scriptless multisignatures][topic multisignature]. + users of both scripted and [scriptless multisignatures][topic multisignature]. {% assign timestamp="1:22:46" %} - **OP_TXHASH variant with support for transaction sponsorship:** Steven Roose [posted][roose txsighash] to Delving Bitcoin about a variation on `OP_TXHASH` @@ -372,7 +374,7 @@ Bitcoin's consensus rules._ inputs are “simple” key-spends, meaning that they could be aggregated if [CISA][topic cisa] were to be deployed." - As of this writing, the post had not received any public replies. + As of this writing, the post had not received any public replies. {% assign timestamp="1:53:31" %} ## Notable code and documentation changes @@ -390,19 +392,19 @@ repo], and [BINANAs][binana repo]._ specified block, primarily in a compact binary (.bin) format but also in .json and .hex variants. Although it was previously possible to do this with the `/rest/block/BLOCKHASH.json` endpoint, the new endpoint improves the - performance of external indexers by eliminating JSON serialization overhead. + performance of external indexers by eliminating JSON serialization overhead. {% assign timestamp="2:13:29" %} - [Bitcoin Core #32638][] adds validation to ensure that any block read from disk matches the expected block hash, catching bit rot and index mix-ups that could have gone unnoticed previously. Thanks to the header-hash cache introduced in [Bitcoin Core #32487][], this extra check is virtually - overhead-free. + overhead-free. {% assign timestamp="2:14:47" %} - [Bitcoin Core #32819][] and [#32530][Bitcoin Core #32530] set the maximum values for the `-maxmempool` and `-dbcache` startup parameters to 500 MB and 1 GB respectively, on 32-bit systems. Since this architecture has a total RAM limit of 4 GB, values higher than the new limits could cause out of memory - (OOM) incidents. + (OOM) incidents. {% assign timestamp="2:15:25" %} - [LDK #3618][] implements the client-side logic for [async payments][topic async payments], allowing an offline recipient node to prearrange [BOLT12 @@ -410,7 +412,7 @@ repo], and [BINANAs][binana repo]._ node. The PR introduces an async receive offer cache inside `ChannelManager` that builds, stores, and persists offers and invoices. It also defines the new onion messages and hooks needed to communicate with the LSP and threads the - state machine through the `OffersMessageFlow`. + state machine through the `OffersMessageFlow`. {% assign timestamp="2:17:41" %} {% include snippets/recap-ad.md when="2025-07-08 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-07-08-newsletter-recap.md b/_posts/en/podcast/2025-07-08-newsletter-recap.md new file mode 100644 index 0000000000..50a89bb6f8 --- /dev/null +++ b/_posts/en/podcast/2025-07-08-newsletter-recap.md @@ -0,0 +1,24 @@ +--- +title: 'Bitcoin Optech Newsletter #361 Recap Podcast' +permalink: /en/podcast/2025/07/08/ +reference: /en/newsletters/2025/07/04/ +name: 2025-07-08-recap +slug: 2025-07-08-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt are joined by Sanket Kanjalkar, Jonas +Nick, Tadge Dryja, Steven Roose, and Brandon Black to discuss [Newsletter #361]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-6-10/403676003-44100-2-064497dec3d96.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From ec1d0e7f2187df4450117d5c3a544744636405c8 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Mon, 7 Jul 2025 20:10:46 -1000 Subject: [PATCH 146/278] Newsletter: add 362 (2025-07-11) --- .../en/newsletters/2025-07-11-newsletter.md | 76 +++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 _posts/en/newsletters/2025-07-11-newsletter.md diff --git a/_posts/en/newsletters/2025-07-11-newsletter.md b/_posts/en/newsletters/2025-07-11-newsletter.md new file mode 100644 index 0000000000..7649675b48 --- /dev/null +++ b/_posts/en/newsletters/2025-07-11-newsletter.md @@ -0,0 +1,76 @@ +--- +title: 'Bitcoin Optech Newsletter #362' +permalink: /en/newsletters/2025/07/11/ +name: 2025-07-11-newsletter +slug: 2025-07-11-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter briefly describes a new library allowing output +script descriptors to be compressed for use in QR codes. Also included +are our regular sections summarizing a Bitcoin Core PR Review Club +meeting, announcing new releases and release candidates, and describing +notable changes to popular Bitcoin infrastructure software. + +## News + +- **Compressed descriptors:** Josh Doman [posted][dorman descom] to + Delving Bitcoin to announce a [library][descriptor-codec] he's written + that encodes [output script descriptors][topic descriptors] into a + binary format that reduces their size by about 40%. This can be + especially useful when descriptors are backed up using QR codes. His + post goes into the details of the encoding and mentions that he plans + to incorporate the compression into his encrypted descriptors backup + library (see [Newsletter #358][news358 descencrypt]). + +## Bitcoin Core PR Review Club + +*In this monthly section, we summarize a recent [Bitcoin Core PR Review +Club][] meeting, highlighting some of the important questions and +answers. Click on a question below to see a summary of the answer from +the meeting.* + +FIXME:stickies-v + +{% include functions/details-list.md + q0="FIXME" + a0="FIXME" + a0link="https://bitcoincore.reviews/32317#l-37FIXME" +%} + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [LND v0.19.2-beta.rc2][] is a release candidate for a maintenance + version of this popular LN node. + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [Core Lightning #8377][] + - BOLT11: Make payment secret field ('s') mandatory + - bolt11: don't accept wrong-length p, h, s or n fields. + +- [BDK #1957][] feat(electrum): optimize merkle proof validation with batching + +- [BIPs #1888][] 380: Disallow H as a hardened indicator + +{% include snippets/recap-ad.md when="2025-07-15 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="8377,1957,1888" %} +[LND v0.19.2-beta.rc2]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.2-beta.rc2 +[news358 descencrypt]: /en/newsletters/2025/06/13/#descriptor-encryption-library +[dorman descom]: https://delvingbitcoin.org/t/a-rust-library-to-encode-descriptors-with-a-30-40-size-reduction/1804 +[descriptor-codec]: https://github.com/joshdoman/descriptor-codec From c6f019a517cd420587abf1e1c24f427f774a60d5 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Fri, 11 Jul 2025 03:36:51 -0500 Subject: [PATCH 147/278] News361,362: add topics --- _topics/en/acc.md | 3 +++ _topics/en/async-payments.md | 3 +++ _topics/en/onion-messages.md | 3 +++ _topics/en/op_cat.md | 3 +++ _topics/en/op_checksigfromstack.md | 9 +++++++++ _topics/en/op_checktemplateverify.md | 9 +++++++++ _topics/en/output-script-descriptors.md | 6 ++++++ _topics/en/ptlc.md | 3 +++ _topics/en/quantum-resistance.md | 6 ++++++ _topics/en/vaults.md | 6 ++++++ 10 files changed, 51 insertions(+) diff --git a/_topics/en/acc.md b/_topics/en/acc.md index bd8a93038c..da58c519dc 100644 --- a/_topics/en/acc.md +++ b/_topics/en/acc.md @@ -70,6 +70,9 @@ optech_mentions: - title: "Improvments to BitVM-style contracts allowing disprove transactions to be just 200 bytes" url: /en/newsletters/2025/06/20/#improvements-to-bitvm-style-contracts + - title: "Continued discussion about CTV+CSFS advantages for BitVM" + url: /en/newsletters/2025/07/04/#continued-discussion-about-ctv-csfs-advantages-for-bitvm + ## Optional. Same format as "primary_sources" above see_also: - title: "Merklize All The Things (MATT)" diff --git a/_topics/en/async-payments.md b/_topics/en/async-payments.md index 88aef767b0..b7c3ecc759 100644 --- a/_topics/en/async-payments.md +++ b/_topics/en/async-payments.md @@ -60,6 +60,9 @@ optech_mentions: - title: "LDK #3140 adds support for paying static BOLT12 invoices to send async payments" url: /en/newsletters/2024/09/20/#ldk-3140 + - title: "LDK #3618 implements the client-side logic for async payments" + url: /en/newsletters/2025/07/04/#ldk-3618 + ## Optional. Same format as "primary_sources" above see_also: - title: Trampoline payments diff --git a/_topics/en/onion-messages.md b/_topics/en/onion-messages.md index fc29f432f5..6e83c5a438 100644 --- a/_topics/en/onion-messages.md +++ b/_topics/en/onion-messages.md @@ -98,6 +98,9 @@ optech_mentions: - title: "Eclair #2865 enables waking up a disconnected mobile peer for async payments or onion messages" url: /en/newsletters/2024/09/06/#eclair-2865 + - title: "Discussion about separating onion message relay from HTLC relay" + url: /en/newsletters/2025/07/04/#separating-onion-message-relay-from-htlc-relay + ## Optional. Same format as "primary_sources" above see_also: - title: Blinded paths diff --git a/_topics/en/op_cat.md b/_topics/en/op_cat.md index 4d2d1c3e52..fa2c61440a 100644 --- a/_topics/en/op_cat.md +++ b/_topics/en/op_cat.md @@ -78,6 +78,9 @@ optech_mentions: - title: "Creating contract-level relative timelocks and Chia-style singletons with `OP_CAT`" url: /en/newsletters/2025/01/10/#contract-level-relative-timelocks + - title: "Prototype implementation of Winternitz signatures for Bitcoin using `OP_CAT`" + url: /en/newsletters/2025/07/04/#op-cat-enables-winternitz-signatures + ## Optional. Same format as "primary_sources" above see_also: - title: OP_CHECKSIGFROMSTACK diff --git a/_topics/en/op_checksigfromstack.md b/_topics/en/op_checksigfromstack.md index 4f0196ab8d..1a23c29c97 100644 --- a/_topics/en/op_checksigfromstack.md +++ b/_topics/en/op_checksigfromstack.md @@ -82,6 +82,15 @@ optech_mentions: - title: "Description of benefits to BitVM from `OP_CTV` and `OP_CSFS`" url: /en/newsletters/2025/05/16/#description-of-benefits-to-bitvm-from-op-ctv-and-op-csfs + - title: "Claim that `OP_CTV` and `OP_CSFS` would provide advantages for using PTLCs" + url: /en/newsletters/2025/07/04/#ctv-csfs-advantages-for-ptlcs + + - title: "Continued discussion about CTV+CSFS advantages for BitVM" + url: /en/newsletters/2025/07/04/#continued-discussion-about-ctv-csfs-advantages-for-bitvm + + - title: "Discussion of open letter about CTV and CSFS" + url: /en/newsletters/2025/07/04/#open-letter-about-ctv-and-csfs + ## Optional. Same format as "primary_sources" above see_also: - title: Covenants in Elements Alpha diff --git a/_topics/en/op_checktemplateverify.md b/_topics/en/op_checktemplateverify.md index aa91c28d59..72affec557 100644 --- a/_topics/en/op_checktemplateverify.md +++ b/_topics/en/op_checktemplateverify.md @@ -163,6 +163,15 @@ optech_mentions: - title: "Description of benefits to BitVM from `OP_CTV` and `OP_CSFS`" url: /en/newsletters/2025/05/16/#description-of-benefits-to-bitvm-from-op-ctv-and-op-csfs + - title: "Claim that `OP_CTV` and `OP_CSFS` would provide advantages for using PTLCs" + url: /en/newsletters/2025/07/04/#ctv-csfs-advantages-for-ptlcs + + - title: "Continued discussion about CTV+CSFS advantages for BitVM" + url: /en/newsletters/2025/07/04/#continued-discussion-about-ctv-csfs-advantages-for-bitvm + + - title: "Discussion of open letter about CTV and CSFS" + url: /en/newsletters/2025/07/04/#open-letter-about-ctv-and-csfs + ## Optional. Same format as "primary_sources" above see_also: - title: Covenants diff --git a/_topics/en/output-script-descriptors.md b/_topics/en/output-script-descriptors.md index a418bd337d..0258776761 100644 --- a/_topics/en/output-script-descriptors.md +++ b/_topics/en/output-script-descriptors.md @@ -200,6 +200,12 @@ optech_mentions: - title: "New library for encrypting descriptors and miniscript to the included public keys" url: /en/newsletters/2025/06/13/#descriptor-encryption-library + - title: "New library for compressing descriptors and miniscript" + url: /en/newsletters/2025/07/11/#compressed-descriptors + + - title: "Brainstorming how to use output script descriptors for CTV-style vaults" + url: /en/newsletters/2025/07/04/#vault-output-script-descriptor + ## Optional. Same format as "primary_sources" above see_also: - title: Miniscript diff --git a/_topics/en/ptlc.md b/_topics/en/ptlc.md index b4ab0e60a9..1028d2268d 100644 --- a/_topics/en/ptlc.md +++ b/_topics/en/ptlc.md @@ -82,6 +82,9 @@ optech_mentions: - title: "LN developer discussion of upgrade paths to using PTLCs" url: /en/newsletters/2024/10/18/#ptlcs + - title: "Claim that `OP_CTV` and `OP_CSFS` would provide advantages for using PTLCs" + url: /en/newsletters/2025/07/04/#ctv-csfs-advantages-for-ptlcs + ## Optional. Same format as "primary_sources" above see_also: - title: Hash Time Locked Contract (HTLC) diff --git a/_topics/en/quantum-resistance.md b/_topics/en/quantum-resistance.md index 23195af724..e9e66fe323 100644 --- a/_topics/en/quantum-resistance.md +++ b/_topics/en/quantum-resistance.md @@ -76,6 +76,12 @@ optech_mentions: - title: Report about quantum computing and Bitcoin url: /en/newsletters/2025/06/06/#quantum-computing-report + - title: "Prototype implementation of Winternitz signatures for Bitcoin using `OP_CAT`" + url: /en/newsletters/2025/07/04/#op-cat-enables-winternitz-signatures + + - title: "Commit/reveal function for post-quantum recovery of insecure bitcoins" + url: /en/newsletters/2025/07/04/#commit-reveal-function-for-post-quantum-recovery + ## Optional. Same format as "primary_sources" above see_also: - title: Taproot diff --git a/_topics/en/vaults.md b/_topics/en/vaults.md index 05355d214f..2287098754 100644 --- a/_topics/en/vaults.md +++ b/_topics/en/vaults.md @@ -107,6 +107,12 @@ optech_mentions: - title: "Proposed CTV enhancement opcodes for more flexible vaults and accountable computing" url: /en/newsletters/2025/01/03/#ctv-enhancement-opcodes + - title: "Brainstorming how to use output script descriptors for CTV-style vaults" + url: /en/newsletters/2025/07/04/#vault-output-script-descriptor + + - title: "Comparison of vaults created with presigned transactinos, CTV, or other methods" + url: /en/newsletters/2025/07/04/#limits-of-ctv-only-vault-support + ## Optional. Same format as "primary_sources" above see_also: - title: Python-vaults From ae5ef3f5ec568a20b8f62a95dfd7b35333e2dc1d Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 10 Jul 2025 07:54:47 +0000 Subject: [PATCH 148/278] News362: add merge summaries --- .../en/newsletters/2025-07-11-newsletter.md | 30 +++++++++++++++---- 1 file changed, 25 insertions(+), 5 deletions(-) diff --git a/_posts/en/newsletters/2025-07-11-newsletter.md b/_posts/en/newsletters/2025-07-11-newsletter.md index 7649675b48..e7bfe0896c 100644 --- a/_posts/en/newsletters/2025-07-11-newsletter.md +++ b/_posts/en/newsletters/2025-07-11-newsletter.md @@ -59,13 +59,29 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Core Lightning #8377][] - - BOLT11: Make payment secret field ('s') mandatory - - bolt11: don't accept wrong-length p, h, s or n fields. +- [Core Lightning #8377][] tightens [BOLT11][] invoice parsing + requirements by mandating that senders not pay an invoice if a + [payment secret][topic payment secrets] is missing or if a mandatory + field such as p (payment hash), h (description hash), or s (secret), + has an incorrect length. These changes are made to align with the + recent specification updates (see Newsletters [#350][news350 bolts] + and [#358][news358 bolts]). -- [BDK #1957][] feat(electrum): optimize merkle proof validation with batching +- [BDK #1957][] introduces RPC batching for transaction history, merkle + proofs, and block header requests to optimize full scan and sync + performance with an Electrum backend. This PR also adds anchor caching + to skip Simple Payment Verification (SPV) (see Newsletter + [#312][news312 spv]) revalidation during a sync. Using sample data, + the author observed performance improvements of 8.14 seconds to 2.59 + seconds with RPC call batching on a full scan and of 1.37 seconds to + 0.85 seconds with caching during a sync. -- [BIPs #1888][] 380: Disallow H as a hardened indicator +- [BIPs #1888][] removes `H` as a hardened-path marker from [BIP380][], + leaving just the canonical `h` and the alternative `'`. The recent + Newsletter [#360][news360 bip380] had noted that grammar was clarified + to allow all three markers, but since few (if any) descriptor + implementations actually support it (neither Bitcoin Core nor + rust-miniscript do), the specification is tightened to disallow it. {% include snippets/recap-ad.md when="2025-07-15 16:30" %} {% include references.md %} @@ -74,3 +90,7 @@ repo], and [BINANAs][binana repo]._ [news358 descencrypt]: /en/newsletters/2025/06/13/#descriptor-encryption-library [dorman descom]: https://delvingbitcoin.org/t/a-rust-library-to-encode-descriptors-with-a-30-40-size-reduction/1804 [descriptor-codec]: https://github.com/joshdoman/descriptor-codec +[news350 bolts]: /en/newsletters/2025/04/18/#bolts-1242 +[news358 bolts]: /en/newsletters/2025/06/13/#bolts-1243 +[news312 spv]: /en/newsletters/2024/07/19/#bdk-1489 +[news360 bip380]: /en/newsletters/2025/06/27/#bips-1803 From 441eead031ec50d760cae8b05cd7fb1fddd452b3 Mon Sep 17 00:00:00 2001 From: stickies-v Date: Thu, 10 Jul 2025 15:33:58 +0100 Subject: [PATCH 149/278] News362: add review club --- .../en/newsletters/2025-07-11-newsletter.md | 57 +++++++++++++++++-- 1 file changed, 53 insertions(+), 4 deletions(-) diff --git a/_posts/en/newsletters/2025-07-11-newsletter.md b/_posts/en/newsletters/2025-07-11-newsletter.md index e7bfe0896c..40098d4be1 100644 --- a/_posts/en/newsletters/2025-07-11-newsletter.md +++ b/_posts/en/newsletters/2025-07-11-newsletter.md @@ -31,12 +31,57 @@ Club][] meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.* -FIXME:stickies-v +[Improve TxOrphanage denial of service bounds][review club 31829] is a +PR by [glozow][gh glozow] that changes `TxOrphanage` eviction logic to +guarantee each peer the resources for at least 1 maximum-size package +worth of orphan resolution. These new guarantees significantly improve +[1-parent-1-child opportunistic package relay][1p1c relay], +especially (but not only) under adversarial conditions. + +The PR modifies existing global orphanage limits, and introduces new +per-peer ones. Together, they protect against both excessive memory +usage and computational exhaustion. The PR also replaces the +random eviction approach with an algorithmic one, calculating a per-peer +DoS Score. + +_Note: the PR has undergone [a few significant changes][review club +31829 changes] since the Review Club, most importantly using a latency +score limit instead of an announcement limit._ {% include functions/details-list.md - q0="FIXME" - a0="FIXME" - a0link="https://bitcoincore.reviews/32317#l-37FIXME" + q0="Why is the current TxOrphanage global maximum size limit of 100 + transactions with random eviction problematic?" + a0="It allows a malicious peer to flood a node with orphan + transactions, eventually causing all legitimate transactions from + other peers to be evicted. This can be used to prevent opportunistic + 1-parent-1-child transaction relay from succeeding, since the child wouldn't + be able to stay in the orphanage for long." + a0link="https://bitcoincore.reviews/31829#l-12" + q1="How does the new eviction algorithm work at a high level?" + a1="Eviction is no longer random. The algorithm identifies the + “worst-behaving” peer based on a “DoS score” and evicts the oldest + transaction announcement from that peer. This protects well-behaved + peers from having their transactions' children evicted by a + misbehaving peer." + a1link="https://bitcoincore.reviews/31829#l-19" + q2="Why is it desirable to allow peers to exceed their individual + limits while the global limits are not reached?" + a2="Peers may be using more resources simply because they are a + helpful peer, who's broadcasting useful transactions such as CPFPs." + a2link="https://bitcoincore.reviews/31829#l-25" + q3="The new algorithm evicts announcements instead of transactions. + What is the difference and why does it matter?" + a3="An announcement is a pair of a transaction and the peer who sent + it. By evicting announcements, a malicious peer cannot evict a + transaction that was also sent by an honest peer." + a3link="https://bitcoincore.reviews/31829#l-34" + q4="What is a peer’s “DoS Score” and how is it calculated?" + a4="A peer's DoS score is the maximum of its “memory score” (memory + used / memory reserved) and “CPU score” (announcements made / + announcement limit). Using a single combined score simplifies eviction + logic into a single loop that targets the peer most aggressively + exceeding either of its limits." + a4link="https://bitcoincore.reviews/31829#l-133" %} ## Releases and release candidates @@ -94,3 +139,7 @@ repo], and [BINANAs][binana repo]._ [news358 bolts]: /en/newsletters/2025/06/13/#bolts-1243 [news312 spv]: /en/newsletters/2024/07/19/#bdk-1489 [news360 bip380]: /en/newsletters/2025/06/27/#bips-1803 +[review club 31829]: https://bitcoincore.reviews/31829 +[gh glozow]: https://github.com/glozow +[review club 31829 changes]: https://github.com/bitcoin/bitcoin/pull/31829#issuecomment-3046495307 +[1p1c relay]: /en/bitcoin-core-28-wallet-integration-guide/#one-parent-one-child-1p1c-relay From 6c5a8069f89ad53669485ef1d66a5d4f015f0c4f Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 11 Jul 2025 20:11:39 +0900 Subject: [PATCH 150/278] Newsletter-362:Translate into Japanese --- .../ja/newsletters/2025-07-11-newsletter.md | 123 ++++++++++++++++++ 1 file changed, 123 insertions(+) create mode 100644 _posts/ja/newsletters/2025-07-11-newsletter.md diff --git a/_posts/ja/newsletters/2025-07-11-newsletter.md b/_posts/ja/newsletters/2025-07-11-newsletter.md new file mode 100644 index 0000000000..c89a7d79ad --- /dev/null +++ b/_posts/ja/newsletters/2025-07-11-newsletter.md @@ -0,0 +1,123 @@ +--- +title: 'Bitcoin Optech Newsletter #362' +permalink: /ja/newsletters/2025/07/11/ +name: 2025-07-11-newsletter-ja +slug: 2025-07-11-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、QRコードで使用するためにアウトプットスクリプトディスクリプターを +圧縮できる新しいライブラリについて掲載しています。また、Bitcoin Core PR Review Clubミーティングの概要や、 +新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき更新など、 +恒例のセクションも含まれています。 + +## ニュース + +- **圧縮ディスクリプター:** Josh Domanが + [アウトプットスクリプトディスクリプター][topic descriptors]をバイナリ形式にエンコードして + サイズを約40%削減する[ライブラリ][descriptor-codec]をDelving Bitcoinで[発表しました][dorman descom]。 + これはディスクリプターをQRコードを使ってバックアップするのに便利です。 + 彼の投稿では、エンコード方法の詳細が説明されており、 + この圧縮機能を暗号化ディスクリプターバックアップライブラリ（[ニュースレター #358][news358 descencrypt]参照）に + 組み込む予定であると言及されています。 + +## Bitcoin Core PR Review Club + +*この毎月のセクションでは、最近の[Bitcoin Core PR Review Club][]ミーティングを要約し、 +重要な質問と回答のいくつかに焦点を当てます。 +以下の質問をクリックしてミーティングでの回答の要約を確認してください。* + +[Improve TxOrphanage denial of service bounds][review club 31829]は、 +[glozow][gh glozow]によるPRで、`TxOrphanage`の排除ロジックを変更し、 +各ピアに少なくとも最大サイズ1パッケージ分のオーファンの解決に必要なリソースを保証するようにします。 +この新しい保証により、[1P1C（1-parent-1-child）パッケージリレー][1p1c relay]が大幅に改善され、 +特に（ただしこれに限定されませんが）敵対的な状況下で顕著になります。 + +このPRは、既存のグローバルなオーファン制限を変更し、ピア毎に新しい制限を導入します。 +これらを組み合わせることで、過剰なメモリの使用と計算能力の枯渇の両方から保護します。 +また、このPRはランダムな排除アプローチを、アルゴリズムによるアプローチに置き換え、 +ピア毎にDoSスコアを計算します。 + +_注: このPRはReview Clubのミーティング以降に、[いくつかの重要な変更が行われています][review club 31829 changes]。 +最も重要なのは、アナウンスの制限ではなくレイテンシースコア制限を使用していることです。_ + +{% include functions/details-list.md + q0="現在のTxOrphanageのグローバル最大サイズ制限である100トランザクションとランダムな排除には、なぜ問題があるのですか？" + a0="悪意のあるピアがオーファントランザクションを大量にノードに送りつけ、 + 最終的に他のピアからの正当なトランザクションをすべて排除させてしまう可能性があります。 + これは、子がオーファン状態に長く留まることができなくなり、1P1Cトランザクションリレーの成功を阻止するのに使用できます。" + a0link="https://bitcoincore.reviews/31829#l-12" + q1="新しい排除アルゴリズムはどのように機能しますか？" + a1="排除はランダムではなくなります。新しいアルゴリズムは、 + 「DoSスコア」に基づいて「最も動作の悪い」ピアを特定し、 + そのピアから送られた最も古いトランザクションの通知を排除します。 + これにより、動作不良のピアによって正常な動作のピアのトランザクションの子が排除されるのを防ぎます。" + a1link="https://bitcoincore.reviews/31829#l-19" + q2="グローバル制限に達していない間、ピアが個別の制限を超えるのを許可するのが望ましいのはなぜですか？" + a2="ピアがより多くのリソースを使用しているのは、単にそのピアがCPFPなどの有用なトランザクションをブロードキャストしている + 有用なピアである可能性があります。" + a2link="https://bitcoincore.reviews/31829#l-25" + q3="新しいアルゴリズムはトランザクションではなくアナウンスを排除します。その違いは何で、なぜ重要なのですか？" + a3="アナウンスは、トランザクションとそれを送信したピアのペアです。アナウンスを排除することで、 + 悪意あるピアは、正直なピアから送信されたトランザクションを排除できなくなります。" + a3link="https://bitcoincore.reviews/31829#l-34" + q4="ピアの「DoS」スコアとは何ですか？どのように計算されますか？" + a4="ピアのDoSスコアは、「メモリスコア」（メモリ使用量/メモリ確保量）と + 「CPUスコア」（アナウンス回数/アナウンス制限）の最大値です。 + 単一の複合スコアを使用することで、排除ロジックが単一のループに簡素化され、 + いずれかの制限を最も積極的に超過しているピアをターゲットにできます。" + a4link="https://bitcoincore.reviews/31829#l-133" +%} + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [LND v0.19.2-beta.rc2][]は、この人気のLNノードのメンテナンスバージョンのリリース候補です。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Core Lightning #8377][]は、[BOLT11][]インボイスのパース要件を厳格化し、 + [ペイメントシークレット][topic payment secrets]が欠落している場合、またはp（ペイメントハッシュ）、 + h（説明ハッシュ）、s（シークレット）などの必須フィールドの長さが正しくない場合、 + 送信者にインボイスへの支払いをしないように義務付けています。これらの変更は、 + 最近の仕様の更新（ニュースレター[#350][news350 bolts]および[#358][news358 bolts]参照）に合わせて行われました。 + +- [BDK #1957][]は、トランザクション履歴、マークルプルーフおよびブロックヘッダーの要求に対するRPCバッチ処理を導入し、 + Electrumバックエンドを使用したフルスキャンと同期のパフォーマンスを最適化します。 + このPRはまた、同期中にSPV（Simple Payment Verification）の再検証（ニュースレター[#312][news312 spv]参照）をスキップするためのアンカーキャッシュも追加されています。 + サンプルデータを使用した結果、作者はフルスキャン時にRPC呼び出しのバッチ処理により8.14秒から2.59秒、 + 同期時にキャッシュ処理により1.37秒から0.85秒のパフォーマンスの向上を確認しました。 + +- [BIPs #1888][]は、[BIP380][]から強化導出パスのマーカーとして`H`を削除し、 + 標準的な`h`と`'`のみを残しました。最近のニュースレター[#360][news360 bip380]では、 + 文法が明確化され3つのマーカーすべてが使用可能になったと掲載していましたが、 + 実際にはこれをサポートしているディスクリプター実装は（あったとしても）ほとんどないため + （Bitcoin Coreもrust-miniscriptもサポートしていません）、 + 仕様が厳格化され使用不可となりました。 + +{% include snippets/recap-ad.md when="2025-07-15 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="8377,1957,1888" %} +[LND v0.19.2-beta.rc2]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.2-beta.rc2 +[news358 descencrypt]: /ja/newsletters/2025/06/13/#descriptor-encryption-library +[dorman descom]: https://delvingbitcoin.org/t/a-rust-library-to-encode-descriptors-with-a-30-40-size-reduction/1804 +[descriptor-codec]: https://github.com/joshdoman/descriptor-codec +[news350 bolts]: /ja/newsletters/2025/04/18/#bolts-1242 +[news358 bolts]: /ja/newsletters/2025/06/13/#bolts-1243 +[news312 spv]: /ja/newsletters/2024/07/19/#bdk-1489 +[news360 bip380]: /ja/newsletters/2025/06/27/#bips-1803 +[review club 31829]: https://bitcoincore.reviews/31829 +[gh glozow]: https://github.com/glozow +[review club 31829 changes]: https://github.com/bitcoin/bitcoin/pull/31829#issuecomment-3046495307 +[1p1c relay]: /ja/bitcoin-core-28-wallet-integration-guide/#1p1cone-parent-one-childリレー From c7d95cb4e75c9964c63863c6c8725490e272a63f Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Wed, 16 Jul 2025 09:15:16 -0500 Subject: [PATCH 151/278] Podcast: add 362 recap --- .../en/newsletters/2025-07-11-newsletter.md | 12 ++++++---- .../en/podcast/2025-07-15-newsletter-recap.md | 23 +++++++++++++++++++ 2 files changed, 30 insertions(+), 5 deletions(-) create mode 100644 _posts/en/podcast/2025-07-15-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-07-11-newsletter.md b/_posts/en/newsletters/2025-07-11-newsletter.md index 40098d4be1..6499a3face 100644 --- a/_posts/en/newsletters/2025-07-11-newsletter.md +++ b/_posts/en/newsletters/2025-07-11-newsletter.md @@ -22,7 +22,7 @@ notable changes to popular Bitcoin infrastructure software. especially useful when descriptors are backed up using QR codes. His post goes into the details of the encoding and mentions that he plans to incorporate the compression into his encrypted descriptors backup - library (see [Newsletter #358][news358 descencrypt]). + library (see [Newsletter #358][news358 descencrypt]). {% assign timestamp="0:34" %} ## Bitcoin Core PR Review Club @@ -84,6 +84,8 @@ score limit instead of an announcement limit._ a4link="https://bitcoincore.reviews/31829#l-133" %} +{% assign timestamp="9:14" %} + ## Releases and release candidates _New releases and release candidates for popular Bitcoin infrastructure @@ -91,7 +93,7 @@ projects. Please consider upgrading to new releases or helping to test release candidates._ - [LND v0.19.2-beta.rc2][] is a release candidate for a maintenance - version of this popular LN node. + version of this popular LN node. {% assign timestamp="46:22" %} ## Notable code and documentation changes @@ -110,7 +112,7 @@ repo], and [BINANAs][binana repo]._ field such as p (payment hash), h (description hash), or s (secret), has an incorrect length. These changes are made to align with the recent specification updates (see Newsletters [#350][news350 bolts] - and [#358][news358 bolts]). + and [#358][news358 bolts]). {% assign timestamp="47:17" %} - [BDK #1957][] introduces RPC batching for transaction history, merkle proofs, and block header requests to optimize full scan and sync @@ -119,14 +121,14 @@ repo], and [BINANAs][binana repo]._ [#312][news312 spv]) revalidation during a sync. Using sample data, the author observed performance improvements of 8.14 seconds to 2.59 seconds with RPC call batching on a full scan and of 1.37 seconds to - 0.85 seconds with caching during a sync. + 0.85 seconds with caching during a sync. {% assign timestamp="50:41" %} - [BIPs #1888][] removes `H` as a hardened-path marker from [BIP380][], leaving just the canonical `h` and the alternative `'`. The recent Newsletter [#360][news360 bip380] had noted that grammar was clarified to allow all three markers, but since few (if any) descriptor implementations actually support it (neither Bitcoin Core nor - rust-miniscript do), the specification is tightened to disallow it. + rust-miniscript do), the specification is tightened to disallow it. {% assign timestamp="51:18" %} {% include snippets/recap-ad.md when="2025-07-15 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-07-15-newsletter-recap.md b/_posts/en/podcast/2025-07-15-newsletter-recap.md new file mode 100644 index 0000000000..654f8719c3 --- /dev/null +++ b/_posts/en/podcast/2025-07-15-newsletter-recap.md @@ -0,0 +1,23 @@ +--- +title: 'Bitcoin Optech Newsletter #362 Recap Podcast' +permalink: /en/podcast/2025/07/15/ +reference: /en/newsletters/2025/07/11/ +name: 2025-07-15-recap +slug: 2025-07-15-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt are joined by Josh Doman and Gloria Zhao to discuss [Newsletter #362]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-6-16/404017715-44100-2-53811b06043be.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From 4d11d886aef4390d0e5887f454bf3fda75470326 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Wed, 16 Jul 2025 19:00:43 +0200 Subject: [PATCH 152/278] Add German translation of Newsletter #362 (#2414) * Add German translation of Newsletter #362 * Update _posts/de/newsletters/2025-07-11-newsletter.md Co-authored-by: garfiel-d * Update _posts/de/newsletters/2025-07-11-newsletter.md Co-authored-by: garfiel-d * Update _posts/de/newsletters/2025-07-11-newsletter.md Co-authored-by: garfiel-d * Update _posts/de/newsletters/2025-07-11-newsletter.md Co-authored-by: Mark "Murch" Erhardt --------- Co-authored-by: garfiel-d Co-authored-by: Mark "Murch" Erhardt --- .../de/newsletters/2025-07-11-newsletter.md | 104 ++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 _posts/de/newsletters/2025-07-11-newsletter.md diff --git a/_posts/de/newsletters/2025-07-11-newsletter.md b/_posts/de/newsletters/2025-07-11-newsletter.md new file mode 100644 index 0000000000..ed9d1d24e2 --- /dev/null +++ b/_posts/de/newsletters/2025-07-11-newsletter.md @@ -0,0 +1,104 @@ +--- +title: 'Bitcoin Optech Newsletter #362' +permalink: /de/newsletters/2025/07/11/ +name: 2025-07-11-newsletter-de +slug: 2025-07-11-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche beschreibt kurz eine neue Bibliothek, die es ermöglicht, Output-Script-Deskriptoren für die Verwendung in QR-Codes zu +komprimieren. Ebenfalls enthalten sind unsere regulären Abschnitte mit einer Zusammenfassung eines Bitcoin Core PR Review Club Meetings, der +Ankündigung neuer Releases und Release-Kandidaten und der Beschreibung wichtiger Änderungen an beliebter Bitcoin-Infrastruktursoftware. + +## Nachrichten + +- **Komprimierte Deskriptoren:** Josh Doman [postete][dorman descom] auf Delving Bitcoin, um eine [Bibliothek][descriptor-codec] anzukündigen, + die er geschrieben hat und die [Output-Script-Deskriptoren][topic descriptors] in ein binäres Format kodiert, das ihre Größe um etwa 40% + reduziert. Dies kann besonders nützlich sein, wenn Deskriptoren mittels QR-Codes gesichert werden. Sein Beitrag erläutert die Details der + Kodierung und erwähnt, dass er plant, die Komprimierung in seine Bibliothek für verschlüsselte Deskriptor-Backups zu integrieren + (siehe [Newsletter #358][news358 descencrypt]). + +## Bitcoin Core PR Review Club + +*In diesem monatlichen Abschnitt fassen wir ein kürzliches [Bitcoin Core PR Review Club][] Meeting zusammen und heben einige der wichtigen Fragen +und Antworten hervor. Klicken Sie auf eine Frage unten, um eine Zusammenfassung der Antwort aus dem Meeting zu sehen.* + +[Improve TxOrphanage denial of service bounds][review club 31829] ist ein PR von [glozow][gh glozow], der die `TxOrphanage`-Eviction-Logik +ändert, um jedem Peer die Ressourcen für mindestens 1 Paket maximaler Größe für die Orphan-Auflösung zu garantieren. Diese neuen Garantien +verbessern die [1-parent-1-child opportunistische Paket-Weiterleitung][1p1c relay] erheblich, insbesondere (aber nicht nur) unter widrigen Bedingungen, wenn +Angreifer versuchen, das System zu stören. + +Der PR modifiziert bestehende globale Orphanage-Limits und führt neue Per-Peer-Limits ein. Zusammen schützen sie sowohl vor übermäßiger +Speichernutzung als auch vor rechnerischer Erschöpfung. Der PR ersetzt auch den zufälligen Eviction-Ansatz durch einen algorithmischen und +berechnet einen Per-Peer-DoS-Score. + +_Hinweis: Der PR hat [einige bedeutende Änderungen][review club 31829 changes] seit dem Review Club durchlaufen, wobei die wichtigste in der Verwendung +eines Latenz-Score-Limits anstelle eines Announcement-Limits besteht._ + +{% include functions/details-list.md + q0="Warum ist das aktuelle globale TxOrphanage-Maximum von 100 Transaktionen mit zufälliger Eviction problematisch?" + a0="Es ermöglicht einem bösartigen Peer, einen Knoten mit Orphan-Transaktionen zu überlasten und schließlich alle legitimen Transaktionen anderer Peers zu verdrängen. Dies kann genutzt werden, um die opportunistische 1-parent-1-child-Transaktions-Weiterleitung am Erfolg zu hindern, da die Kind-Transaktion nicht lange im temporären Speicher (Orphanage) bleiben könnte." + a0link="https://bitcoincore.reviews/31829#l-12" + q1="Wie funktioniert der Eviction-Algorithmus auf hoher Ebene?" + a1="Eviction ist nicht mehr zufällig. Der Algorithmus identifiziert den \"schlechtesten\" Peer basierend auf einem \"DoS-Score\" und verdrängt die älteste Transaktionsankündigung von diesem Peer. Dies schützt wohlverhaltende Peers davor, dass ihre Transaktions-Kinder von einem fehlverhaltenden Peer verdrängt werden." + a1link="https://bitcoincore.reviews/31829#l-19" + q2="Warum ist es wünschenswert, Peers zu erlauben, ihre individuellen Limits zu überschreiten, während die globalen Limits nicht erreicht sind?" + a2="Peers verwenden möglicherweise mehr Ressourcen, einfach weil sie ein hilfreicher Peer sind, der nützliche Transaktionen wie CPFPs weiterleitet." + a2link="https://bitcoincore.reviews/31829#l-25" + q3="Der neue Algorithmus verdrängt Ankündigungen anstelle von Transaktionen. Was ist der Unterschied und warum ist das wichtig?" + a3="Eine Ankündigung ist ein Paar aus einer Transaktion und dem Peer, der sie gesendet hat. Durch das Verdrängen von Ankündigungen kann ein bösartiger Peer keine Transaktion verdrängen, die auch von einem ehrlichen Peer gesendet wurde." + a3link="https://bitcoincore.reviews/31829#l-34" + q4="Was ist der \"DoS-Score\" eines Peers und wie wird er berechnet?" + a4="Der DoS-Score eines Peers ist das Maximum seines \"Speicher-Scores\" (verwendeter Speicher / reservierter Speicher) und \"CPU-Scores\" (Anzahl der gesendeten Ankündigungen / Ankündigungslimit). Die Verwendung eines einzigen kombinierten Scores vereinfacht die Eviction-Logik zu einer einzigen Schleife, die den Peer anvisiert, der am aggressivsten eines seiner Limits überschreitet." + a4link="https://bitcoincore.reviews/31829#l-133" +%} + + + + +## Releases und Release-Kandidaten + +_Neue Releases und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie ein Upgrade auf neue Releases oder helfen Sie +beim Testen von Release-Kandidaten._ + +- [LND v0.19.2-beta.rc2][] ist ein Release-Kandidat für eine Wartungsversion dieses beliebten LN-Knotens. + +## Wichtige Code- und Dokumentationsänderungen + +_Wichtige kürzliche Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], [Eclair][eclair repo], +[LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], +[BTCPay Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], und [BINANAs][binana repo]._ + +- [Core Lightning #8377][] verschärft die [BOLT11][]-Invoice-Parsing-Anforderungen, indem es vorschreibt, dass Sender eine Invoice nicht + bezahlen, wenn ein [Payment Secret][topic payment secrets] fehlt oder wenn ein Pflichtfeld wie p (Payment Hash), h (Description Hash) oder + s (Secret) eine falsche Länge hat. Diese Änderungen werden vorgenommen, um sich an die kürzlichen Spezifikations-Updates anzupassen + (siehe Newsletter [#350][news350 bolts] und [#358][news358 bolts]). + +- [BDK #1957][] führt RPC-Batching für Transaktionshistorie, Merkle-Beweise und Block-Header-Anfragen ein, um die Full-Scan- und + Sync-Performance mit einem Electrum-Backend zu optimieren. Dieser PR fügt auch Anchor-Caching hinzu, um Simple Payment Verification (SPV) + (siehe Newsletter [#312][news312 spv]) Revalidierung während eines Syncs zu überspringen. Mit Beispieldaten beobachtete der Autor + Performance-Verbesserungen von 8,14 Sekunden auf 2,59 Sekunden mit RPC-Call-Batching bei einem Full Scan und von 1,37 Sekunden auf + 0,85 Sekunden mit Caching während eines Syncs. + +- [BIPs #1888][] entfernt `H` als Hardened-Path-Marker aus [BIP380][] und lässt nur das kanonische `h` und die Alternative `'` übrig. + Der kürzliche Newsletter [#360][news360 bip380] hatte angemerkt, dass die Grammatik klargestellt wurde, um alle drei Marker zu erlauben, + aber da wenige (wenn überhaupt) Deskriptor-Implementierungen dies tatsächlich unterstützen (weder Bitcoin Core noch rust-miniscript tun es), + wird die Spezifikation verschärft, um dies zu verbieten. + +{% include snippets/recap-ad.md when="2025-07-15 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="8377,1957,1888" %} +[LND v0.19.2-beta.rc2]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.2-beta.rc2 +[news358 descencrypt]: /de/newsletters/2025/06/13/#bibliothek-zur-verschlusselung-von-deskriptoren +[dorman descom]: https://delvingbitcoin.org/t/a-rust-library-to-encode-descriptors-with-a-30-40-size-reduction/1804 +[descriptor-codec]: https://github.com/joshdoman/descriptor-codec +[news350 bolts]: /de/newsletters/2025/04/18/#bolts-1242 +[news358 bolts]: /de/newsletters/2025/06/13/#bolts-1243 +[news312 spv]: /en/newsletters/2024/07/19/#bdk-1489 +[news360 bip380]: /de/newsletters/2025/06/27/#bips-1803 +[review club 31829]: https://bitcoincore.reviews/31829 +[gh glozow]: https://github.com/glozow +[review club 31829 changes]: https://github.com/bitcoin/bitcoin/pull/31829#issuecomment-3046495307 +[1p1c relay]: /en/bitcoin-core-28-wallet-integration-guide/#one-parent-one-child-1p1c-relay From e0bdacd5279b56b0148ded192e537a43fbdf615b Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Mon, 14 Jul 2025 12:52:29 -1000 Subject: [PATCH 153/278] Newsletters: add 363 (2026-07-18) --- .../en/newsletters/2025-07-18-newsletter.md | 67 +++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 _posts/en/newsletters/2025-07-18-newsletter.md diff --git a/_posts/en/newsletters/2025-07-18-newsletter.md b/_posts/en/newsletters/2025-07-18-newsletter.md new file mode 100644 index 0000000000..d1214c78e7 --- /dev/null +++ b/_posts/en/newsletters/2025-07-18-newsletter.md @@ -0,0 +1,67 @@ +--- +title: 'Bitcoin Optech Newsletter #363' +permalink: /en/newsletters/2025/07/18/ +name: 2025-07-18-newsletter +slug: 2025-07-18-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter includes our regular sections summarizing updates +to services and client software, announcing new releases and release +candidates, and describing notable changes to popular Bitcoin +infrastructure software. + +## News + +_No significant news this week was found in any of our [sources][]._ + +## Changes to services and client software + +*In this monthly feature, we highlight interesting updates to Bitcoin +wallets and services.* + +FIXME:bitschmidty + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [LND v0.19.2-beta][] is the release of a maintenance + version of this popular LN node. It "contains important bug fixes and + performance improvements." + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [Bitcoin Core #32604][] log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError + +- [Bitcoin Core #32618][] wallet: Remove ISMINE_WATCHONLY and watchonly from RPCs + +- [Bitcoin Core #31553][] cluster mempool: add TxGraph reorg functionality + +- [Core Lightning #7725][] logs: A basic javascript log viewer + +- [Eclair #2716][] Endorse htlc and local reputation + +- [LDK #3628][] Static invoice server + +- [LDK #3890][] Use `cost / path amt limit` as the pathfinding score, not `cost` + +- [LND #10001][] Enable quiescence in production and add timeout config + +{% include snippets/recap-ad.md when="2025-07-22 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32604,32618,31553,7725,2716,3628,3890,10001" %} +[LND v0.19.2-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.2-beta +[sources]: /en/internal/sources/ From 560ea8ac45e8bd51dad0c444ad1e882532fc88e5 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Wed, 16 Jul 2025 11:02:05 -0500 Subject: [PATCH 154/278] News363: add client services --- .../en/newsletters/2025-07-18-newsletter.md | 26 ++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2025-07-18-newsletter.md b/_posts/en/newsletters/2025-07-18-newsletter.md index d1214c78e7..9e34421e34 100644 --- a/_posts/en/newsletters/2025-07-18-newsletter.md +++ b/_posts/en/newsletters/2025-07-18-newsletter.md @@ -21,7 +21,27 @@ _No significant news this week was found in any of our [sources][]._ *In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.* -FIXME:bitschmidty +- **Floresta v0.8.0 released:** + The [Floresta v0.8.0][floresta v0.8.0] release of this [Utreexo][topic utreexo] node adds support for [version 2 P2P + transport (BIP324)][topic v2 p2p transport], [testnet4][topic testnet], + enhanced metrics and monitoring, among other features and bugfixes. + +- **RGB v0.12 announced:** + The RGB v0.12 [blog post][rgb blog] announces the release of RBG's consensus + layer for RGB's [client-side validated][topic client-side validation] smart + contracts on Bitcoin testnet and mainnet. + +- **FROST signing device available:** + [Frostsnap][frostsnap website] signing devices support k-of-n [threshold signing][topic + threshold signature] using the FROST protocol, with only a single signature on chain. + +- **Gemini adds taproot support:** + Gemini Exchange and Gemini Custody add support for sending (withdrawing) to + [taproot][topic taproot] addresses. + +- **Electrum 4.6.0 released:** + [Electrum 4.6.0][electrum 4.6.0] adds support for [submarine swaps][topic + submarine swaps] using nostr for discoverability. ## Releases and release candidates @@ -65,3 +85,7 @@ repo], and [BINANAs][binana repo]._ {% include linkers/issues.md v=2 issues="32604,32618,31553,7725,2716,3628,3890,10001" %} [LND v0.19.2-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.2-beta [sources]: /en/internal/sources/ +[floresta v0.8.0]: https://github.com/vinteumorg/Floresta/releases/tag/v0.8.0 +[rgb blog]: https://rgb.tech/blog/release-v0-12-consensus/ +[frostsnap website]: https://frostsnap.com/ +[electrum 4.6.0]: https://github.com/spesmilo/electrum/releases/tag/4.6.0 From 902538efef395a5b812dbb44b2e9b82493d5bddd Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 17 Jul 2025 05:45:47 +0000 Subject: [PATCH 155/278] News363: add merge summaries --- .../en/newsletters/2025-07-18-newsletter.md | 82 +++++++++++++++---- 1 file changed, 67 insertions(+), 15 deletions(-) diff --git a/_posts/en/newsletters/2025-07-18-newsletter.md b/_posts/en/newsletters/2025-07-18-newsletter.md index 9e34421e34..07c8f9c0df 100644 --- a/_posts/en/newsletters/2025-07-18-newsletter.md +++ b/_posts/en/newsletters/2025-07-18-newsletter.md @@ -64,21 +64,71 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Bitcoin Core #32604][] log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError - -- [Bitcoin Core #32618][] wallet: Remove ISMINE_WATCHONLY and watchonly from RPCs - -- [Bitcoin Core #31553][] cluster mempool: add TxGraph reorg functionality - -- [Core Lightning #7725][] logs: A basic javascript log viewer - -- [Eclair #2716][] Endorse htlc and local reputation - -- [LDK #3628][] Static invoice server - -- [LDK #3890][] Use `cost / path amt limit` as the pathfinding score, not `cost` - -- [LND #10001][] Enable quiescence in production and add timeout config +- [Bitcoin Core #32604][] rate-limits unconditional logging to disk such as for + `LogPrintf`, `LogInfo`, `LogWarning` and `LogError` to mitigate disk-filling + attacks by giving each source location a 1 MB per hour quota. All log lines + are prefixed with an asterisk (*) when any source location is suppressed. + Console output, logs with an explicit category argument, and `UpdateTip` + Initial Block Download (IBD) messages are exempt from rate limits. When the + quota resets, Core prints the number of bytes that were dropped. + +- [Bitcoin Core #32618][] removes the `include_watchonly` option and its + variants, as well as the `iswatchonly` field from all wallet RPCs because + [descriptor][topic descriptors] wallets don’t support mixing watch-only and + spendable descriptors. Previously, users could import a watch-only address or + script into a legacy spending wallet. However, legacy wallets have now been + removed. + +- [Bitcoin Core #31553][] adds block reorg handling to the [cluster + mempool][topic cluster mempool] project by introducing the `TxGraph::Trim()` + function. When a reorg reintroduces previously confirmed transactions to the + mempool and the resulting combined cluster exceeds cluster count or weight + policy limits, `Trim()` builds a feerate-ordered, dependency‑respecting, + rudimentary linearization. If adding a transaction would breach a limit, that + transaction and all its descendants are dropped. + +- [Core Lightning #7725][] adds a lightweight JavaScript log viewer that loads + CLN log files in a browser and allows users to filter messages by daemon, + type, channel, or regex. This tool adds minimal repository maintenance + overhead while improving the debugging experience for developers and node + runners. + +- [Eclair #2716][] implements a local peer-reputation system for [HTLC + endorsement][topic htlc endorsement] that tracks the routing fees earned by + each incoming peer versus the fees that should have been earned based on the + liquidity and [HTLC][topic htlc] slots used. Successful payments result in a + perfect score, failed payments lower it, and HTLCs that remain pending past + the configured threshold are heavily penalized. When forwarding, the node + includes its current peer score in the `update_add_htlc` endorsement TLV (see + Newsletter [#315][news315 htlc]). Operators can adjust the reputation decay + (`half-life`), the stuck payment threshold (`max-relay-duration`), the penalty + weight for stuck HTLCs (`pending-multiplier`), or simply disable the + reputation system entirely in the configuration. This PR primarily collects + data to improve [channel jamming attack][topic channel jamming attacks] + research and does not yet implement penalties. + +- [LDK #3628][] implements the server-side logic for [async payments][topic + async payments], allowing an LSP node to provide [BOLT12][topic offers] static + invoices on behalf of an often-offline recipient. The LSP node can accept + `ServeStaticInvoice` messages from the recipient, store the provided static + invoices, and respond to payer invoice requests by searching for and returning + the cached invoice via [blinded paths][topic rv routing]. + +- [LDK #3890][] changes the way it scores routes in its pathfinding algorithm by + considering total cost divided by channel amount limit (cost per sat of usable + capacity) instead of considering only the raw total cost. This biases the + selection toward higher-capacity routes and reduces excessive [MPP][topic + multipath payments] sharding, resulting in a higher payment success rate. + Although the change overly penalizes small channels, this tradeoff is + preferable to previous excessive sharding. + +- [LND #10001][] enables the quiescence protocol in production (see Newsletter + [#332][news332 quiescence]) and adds a new configuration value + `--htlcswitch.quiescencetimeout`, which specifies the maximum duration for + which a channel can be quiescent. The value ensures that dependent protocols, + such as [dynamic commitments][topic channel commitment upgrades], finish + within the timeout period. The default value is 60 seconds, and the minimum + value is 30 seconds. {% include snippets/recap-ad.md when="2025-07-22 16:30" %} {% include references.md %} @@ -89,3 +139,5 @@ repo], and [BINANAs][binana repo]._ [rgb blog]: https://rgb.tech/blog/release-v0-12-consensus/ [frostsnap website]: https://frostsnap.com/ [electrum 4.6.0]: https://github.com/spesmilo/electrum/releases/tag/4.6.0 +[news315 htlc]: /en/newsletters/2024/08/09/#eclair-2884 +[news332 quiescence]: /en/newsletters/2024/12/06/#lnd-8270 From 0ed66b6cdba425d4f8925cf8af8df24790c94c1e Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Fri, 18 Jul 2025 06:46:10 -0700 Subject: [PATCH 156/278] News363: add topics --- _topics/en/async-payments.md | 3 +++ _topics/en/cluster-mempool.md | 3 +++ _topics/en/htlc-endorsement.md | 3 +++ _topics/en/submarine-swaps.md | 3 +++ _topics/en/threshold-signature.md | 3 +++ 5 files changed, 15 insertions(+) diff --git a/_topics/en/async-payments.md b/_topics/en/async-payments.md index b7c3ecc759..97bc57d2d7 100644 --- a/_topics/en/async-payments.md +++ b/_topics/en/async-payments.md @@ -63,6 +63,9 @@ optech_mentions: - title: "LDK #3618 implements the client-side logic for async payments" url: /en/newsletters/2025/07/04/#ldk-3618 + - title: "LDK #3628 implements the server-side logic for async payments" + url: /en/newsletters/2025/07/18/#ldk-3628 + ## Optional. Same format as "primary_sources" above see_also: - title: Trampoline payments diff --git a/_topics/en/cluster-mempool.md b/_topics/en/cluster-mempool.md index 57a618acdb..89f0d37a6c 100644 --- a/_topics/en/cluster-mempool.md +++ b/_topics/en/cluster-mempool.md @@ -97,6 +97,9 @@ optech_mentions: - title: "Relay censorship resistance using cluster mempool and efficient set reconciliation" url: /en/newsletters/2025/06/13/#relay-censorship-resistance-through-top-mempool-set-reconciliation + - title: "Bitcoin Core #31553 adds block reorg handling to the cluster mempool project" + url: /en/newsletters/2025/07/18/#bitcoin-core-31553 + ## Optional. Same format as "primary_sources" above see_also: - title: Package relay diff --git a/_topics/en/htlc-endorsement.md b/_topics/en/htlc-endorsement.md index 26b3730b86..fc27b09b02 100644 --- a/_topics/en/htlc-endorsement.md +++ b/_topics/en/htlc-endorsement.md @@ -65,6 +65,9 @@ optech_mentions: - title: "LND #8390 introduces support for setting and relaying an experimental HTLC endorsement" url: /en/newsletters/2024/12/06/#lnd-8390 + - title: "Eclair #2716 implements a reputation system for HTLC endorsement that tracks per-peer routing fees" + url: /en/newsletters/2025/07/18/#eclair-2716 + ## Optional. Same format as "primary_sources" above see_also: - title: Channel jamming attacks diff --git a/_topics/en/submarine-swaps.md b/_topics/en/submarine-swaps.md index 2fa5537d42..9196e6b0ae 100644 --- a/_topics/en/submarine-swaps.md +++ b/_topics/en/submarine-swaps.md @@ -37,6 +37,9 @@ optech_mentions: - title: Proposal to extend BOLT11 invoices to allow requesting prepayment for submarine swaps url: /en/newsletters/2023/06/21/#submarine-swaps + - title: "Electrum 4.6.0 adds support for submarine swaps using nostr for discoverability" + url: /en/newsletters/2025/07/18/#electrum-4-6-0-released + ## Optional. Same format as "primary_sources" above see_also: - title: Splicing diff --git a/_topics/en/threshold-signature.md b/_topics/en/threshold-signature.md index 1126fe1cdc..2cf48b170f 100644 --- a/_topics/en/threshold-signature.md +++ b/_topics/en/threshold-signature.md @@ -64,6 +64,9 @@ optech_mentions: - title: "FROSTR library for k-of-n signing and key management on nostr" url: /en/newsletters/2025/03/21/#frostr-protocol-announced + - title: "Frostsnap signing devices support k-of-n threshold signing" + url: /en/newsletters/2025/07/18/#frost-signing-device-available + ## Optional. Same format as "primary_sources" above see_also: - title: Scriptless multisignature From 685966de4658023d9fcc226f6954c6f3388b01ea Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 18 Jul 2025 23:06:38 +0900 Subject: [PATCH 157/278] Newsletter-363:Translate into Japanese --- .../ja/newsletters/2025-07-18-newsletter.md | 125 ++++++++++++++++++ 1 file changed, 125 insertions(+) create mode 100644 _posts/ja/newsletters/2025-07-18-newsletter.md diff --git a/_posts/ja/newsletters/2025-07-18-newsletter.md b/_posts/ja/newsletters/2025-07-18-newsletter.md new file mode 100644 index 0000000000..fd48ded57e --- /dev/null +++ b/_posts/ja/newsletters/2025-07-18-newsletter.md @@ -0,0 +1,125 @@ +--- +title: 'Bitcoin Optech Newsletter #363' +permalink: /ja/newsletters/2025/07/18/ +name: 2025-07-18-newsletter-ja +slug: 2025-07-18-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、サービスとクライアントの更新の概要、新しいリリースとリリース候補の発表、 +人気のBitcoinインフラストラクチャソフトウェアの注目すべき更新など、恒例のセクションを掲載しています。 + +## ニュース + +_今週は、どの[情報源][sources]からも重要なニュースは見つかりませんでした。_ + +## サービスとクライアントソフトウェアの変更 + +*この毎月の特集では、Bitcoinのウォレットやサービスの興味深いアップデートを取り上げています。* + +- **Floresta v0.8.0リリース:** + [Utreexo][topic utreexo]ノードの[Floresta v0.8.0][floresta v0.8.0]リリースでは、 + [バージョン2 P2Pトランスポート(BIP324)][topic v2 p2p transport]、 + [testnet4][topic testnet]のサポートや、メトリクスとモニタリングの機能強化、 + その他多くの機能追加とバグ修正が行われました。 + +- **RGB v0.12を発表:** + RGB v0.12の[ブログ記事][rgb blog]では、Bitcoinのtestnetとmainnetで、 + [クライアントサイド検証済み][topic client-side validation]のRGBスマートコントラクト用の + RGBコンセンサスレイヤーがリリースされたことが発表されました。 + +- **FROST署名デバイスが利用可能に:** + [Frostsnap][frostsnap website]署名デバイスは、オンチェーンでは単一の署名のみで済む、 + FROSTプロトコルを使用したk-of-nの[閾値署名][topic threshold signature]をサポートしました。 + +- **GeminiがTaprootをサポート:** + Gemini ExchangeとGemini Custodyは、[Taproot][topic taproot]アドレスへの送金（引き出し）をサポートしました。 + +- **Electrum 4.6.0リリース:** + [Electrum 4.6.0][electrum 4.6.0]では、 + 検出にnostrを用いた[サブマリンスワップ][topic submarine swaps]がサポートされました。 + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [LND v0.19.2-beta][]は、この人気のLNノードのメンテナンスバージョンのリリースです。 + これには、「重要なバグ修正とパフォーマンスの改善が含まれています」 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Bitcoin Core #32604][]は、`LogPrintf`、`LogInfo`、`LogWarning`、`LogError`などの + ディスクへの無条件ログ出力をレート制限し、各ソースロケーションに1時間あたり1MBのクォータを設定することで、 + ディスク容量オーバーの攻撃を軽減します。ソースロケーションが抑制されている場合、 + すべてのログの行の先頭にアスタリスク(*)が付きます。コンソール出力や、 + 明示的なカテゴリ引数を持つログ、`UpdateTip`初期ブロックダウンロード（IBD）メッセージはレート制限の対象外です。 + クォータがリセットされると、Coreはドロップされたbyte数を出力します。 + +- [Bitcoin Core #32618][]は、すべてのウォレットRPCから、`include_watchonly`およびその派生オプションと + `iswatchonly`フィールドを削除します。これは[ディスクリプター][topic descriptors]ウォレットが + 監視専用のディスクリプターと支払いに使用可能なディスクリプターの混在をサポートしていないためです。 + これまでは、ユーザーは監視専用アドレスやスクリプトをレガシー支払いウォレットにインポートできましたが、 + レガシーウォレットは削除されました。 + +- [Bitcoin Core #31553][]は、`TxGraph::Trim()`関数を導入することで、 + [クラスターmempool][topic cluster mempool]プロジェクトにブロックの再編成処理機能を追加します。 + 再編成によって以前承認されたトランザクションがmempoolに再導入され、 + 結果として得られるクラスターがクラスター数もしくはウェイトポリシーの制限を超えると、 + `Trim()`は手数料率順で依存関係を考慮した基本的なリニアライゼーションを構築します。 + トランザクションの追加が制限を超える場合、そのトランザクションとそのすべての子孫は削除されます。 + +- [Core Lightning #7725][]は、軽量なJavaScriptログビューアを追加します。 + これはブラウザでCLNログファイルを読み込み、ユーザーがデーモン、タイプ、チャネルまたは正規表現で + メッセージをフィルタリングできるようにします。このツールは、リポジトリメンテナンスのオーバーヘッドを最小限に抑えながら、 + 開発者とノード実行者のデバッグ体験を向上させます。 + +- [Eclair #2716][]は、[HTLCエンドースメント][topic htlc endorsement]用に + ローカルピアレピュテーションシステムを実装します。このシステムは、各着信ピアが獲得したルーティング手数料と、 + 使用された流動性と[HTLC][topic htlc]スロットに基づいて獲得されるべき手数料を追跡します。 + 支払いが成功するとスコアは満点になり、失敗するとスコアは下がり、 + 設定された閾値を超えて保留中のHTLCには重いペナルティが課せられます。 + 転送時に、ノードは現在のピアスコアを`update_add_htlc`エンドースメントTLV（ニュースレター + [#315][news315 htlc]参照）に含めます。オペレーターは、 + レピュテーションの減衰（`half-life`）、スタック支払い閾値（`max-relay-duration`）、 + スタックHTLCのペナルティウェイト（`pending-multiplier`）を調整するか、 + 設定でレビュテーションシステムを完全に無効にできます。このPRは主に、 + [チャネルジャミング攻撃][topic channel jamming attacks]の研究を改良するためのデータを収集し、 + まだペナルティは実装していません。 + +- [LDK #3628][]は、[非同期支払い][topic async payments]用のサーバーサイドロジックを実装し、 + LSPノードが頻繁にオフラインになる受取人に代わって[BOLT12][topic offers]静的インボイスを提供できるようにします。 + LSPノードは、受取人からの`ServeStaticInvoice`メッセージを受け入れ、提供された静的インボイスを保持し、 + [ブラインドパス][topic rv routing]を介してキャッシュされたインボイスを検索して返すことで支払人のインボイス要求に応答できます。 + +- [LDK #3890][]は、経路探索アルゴリズムでの経路の評価方法を変更し、 + 総コストのみを考慮するのではなく、総コストをチャネル量制限（使用可能な容量のsatあたりのコスト）で割った値を考慮するようになりました。 + これにより、選択はより大容量の経路に偏り、過剰な[MPP][topic multipath payments]シャーディングが減り、 + 結果として支払いの成功率が向上します。この変更により、小規模なチャネルに過度なペナルティが課せられますが、 + このトレードオフはこれまでの過剰なシャーディングよりも好ましいものです。 + +- [LND #10001][]では、運用環境で静止プロトコル（ニュースレター[#332][news332 quiescence]参照）が有効になり、 + チャネルが静止状態を維持できる最大期間を指定する新しい設定値`--htlcswitch.quiescencetimeout`が追加されました。 + この値により、[ダイナミックコミットメント][topic channel commitment upgrades]などの依存プロトコルが + タイムアウト期間内に完了することが保証されます。デフォルト値は60秒、最小値は30秒です。 + +{% include snippets/recap-ad.md when="2025-07-22 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32604,32618,31553,7725,2716,3628,3890,10001" %} +[LND v0.19.2-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.2-beta +[sources]: /ja/internal/sources/ +[floresta v0.8.0]: https://github.com/vinteumorg/Floresta/releases/tag/v0.8.0 +[rgb blog]: https://rgb.tech/blog/release-v0-12-consensus/ +[frostsnap website]: https://frostsnap.com/ +[electrum 4.6.0]: https://github.com/spesmilo/electrum/releases/tag/4.6.0 +[news315 htlc]: /ja/newsletters/2024/08/09/#eclair-2884 +[news332 quiescence]: /ja/newsletters/2024/12/06/#lnd-8270 \ No newline at end of file From bc3a6b946b041ec32558aa7e2a49a065596255b6 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sat, 19 Jul 2025 14:43:16 +0200 Subject: [PATCH 158/278] Newsletter 361 translate in French (#2409) --- .../fr/newsletters/2025-07-04-newsletter.md | 405 ++++++++++++++++++ 1 file changed, 405 insertions(+) create mode 100644 _posts/fr/newsletters/2025-07-04-newsletter.md diff --git a/_posts/fr/newsletters/2025-07-04-newsletter.md b/_posts/fr/newsletters/2025-07-04-newsletter.md new file mode 100644 index 0000000000..28bf26db51 --- /dev/null +++ b/_posts/fr/newsletters/2025-07-04-newsletter.md @@ -0,0 +1,405 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #361' +permalink: /fr/newsletters/2025/07/04/ +name: 2025-07-04-newsletter-fr +slug: 2025-07-04-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine décrit une proposition visant à séparer les connexions réseau et la +gestion des pairs utilisées pour la transmission de messages onion de celles utilisées pour la +transmission de HTLC dans LN. Sont également incluses nos sections régulières résumant les +discussions sur la modification du consensus de Bitcoin et listant les changements récents apportés +aux logiciels d'infrastructure Bitcoin populaires. + +## Nouvelles + +- **Séparation de la transmission de messages onion de la transmission de HTLC :** Olaluwa Osuntokun + a [posté][osuntokun onion] sur Delving Bitcoin concernant la possibilité pour les nœuds d'utiliser + des connexions séparées pour relayer les [messages onion][topic onion messages] de celles qu'ils + utilisent pour relayer les [HTLC][topic htlc]. Bien que des connexions séparées soient actuellement + possibles, comme dans le cas du relais direct (voir les bulletins [#283][news283 oniondirect] et + [#304][news304 onionreply]), Osuntokun suggère que des connexions séparées devraient toujours être + une option, permettant aux nœuds d'avoir un ensemble différent de pairs pour les messages onion de + l'ensemble des pairs qu'ils utilisent pour relayer les paiements. Il avance plusieurs arguments en + faveur de cette approche alternative : cela sépare plus clairement les préoccupations, les nœuds + peuvent soutenir à moindre coût une plus grande densité de pairs pour les messages onion que pour + les pairs de canaux (car les canaux coûtent de l'argent à créer), la séparation peut permettre le + déploiement d'une rotation de clés améliorant la confidentialité, et la séparation peut permettre + une livraison plus rapide des messages onion car ils ne seraient pas bloqués par le protocole de + communication d'engagement HTLC. Osuntokun fournit des détails spécifiques sur le protocole proposé. + + Une préoccupation de plusieurs développeurs ayant répondu était la manière dont le réseau pour les + messages onion pourrait permettre aux nœuds d'être inondés par un nombre excessif de pairs. Dans les + implémentations actuelles de messages onion, chaque nœud ne maintient généralement des connexions + qu'avec ses partenaires de canal. Créer l'UTXO pour financer un canal coûte de l'argent (frais + onchain et coût d'opportunité) et est unique au nœud et au partenaire de canal ; en bref, c'est + une-UTXO-une-connexion. Même si les connexions de messages onion devaient être soutenues par des + fonds onchain, une seule UTXO pourrait être utilisé pour ouvrir des connexions avec chaque nœud LN + public : une-UTXO-des milliers-de-connexions. + + Bien qu'au moins un répondant ait soutenu la proposition d'Osuntokun, plusieurs répondants ont + jusqu'à présent exprimé leur préoccupation concernant le risque de déni de service. La discussion + était en cours au moment de la rédaction. + +## Modification du consensus + +_Une nouvelle section mensuelle résumant les propositions et discussions sur la modification des +règles de consensus de Bitcoin._ + +- **Avantages de CTV+CSFS pour les PTLC :** les développeurs ont poursuivi une discussion précédente + (voir le [Bulletin #348][news348 ctvstep]) sur les avantages de [OP_CHECKTEMPLATEVERIFY][topic + op_checktemplateverify] (CTV), [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (CSFS), ou les + deux ensemble pour divers protocoles déployés et imaginés. D'un intérêt particulier, Gregory Sanders + a [écrit][sanders ptlc] que CTV+CSFS "accélérerait la mise à jour de [LN] vers [PTLCs][topic ptlc], + même si [LN-Symmetry][topic eltoo] en soi + n'est jamais adopté. Les signatures réaffectables rendent la vie tellement moins compliquée + lorsqu'on empile des protocoles." Sjors Provoost a [demandé][provoost ptlc] des détails et Sanders a + [répondu][sanders ptlc2] avec un [lien][sanders gist] vers ses recherches précédentes sur les + changements de messagerie LN pour les PTLCs (voir le [Bulletin #268][news268 ptlc]), ajoutant que + "les PTLCs sur les protocoles actuels ne sont pas du tout impossibles, mais avec des signatures + réaffectables, cela devient significativement plus simple." + + Anthony Towns a également [mentionné][towns ptlc] qu'"il y a aussi un manque + d'outils/standardisation pour réaliser une révélation PTLC en combinaison avec un [musig][topic + musig] 2-de-2 (ce qui serait efficace onchain), ou même des signatures de transactions + générales (ie `x CHECKSIGVERIFY y CHECKSIG`). [...] Cela nécessiterait un support de [signature + adaptative][topic adaptor signatures] pour musig2, et cela ne fait pas partie des spécifications et + a été [retiré][libsecp256k1 #1479] de l'implémentation secp256k1. Le faire moins efficacement comme + une signature adaptative séparée fonctionnerait aussi, mais même les signatures adaptatives simples + pour les [signatures schnorr][topic schnorr signatures] ne sont également pas disponibles dans + secp256k1. Elles ne sont même pas incluses dans le projet secp256k1-zkp plus expérimental. [...] Si + les outils étaient prêts, je pourrais voir le support PTLC être ajouté [...] mais je ne pense pas + que quiconque considère cela comme une priorité suffisamment élevée pour effectuer le travail + nécessaire pour standardiser et polir les aspects cryptographiques. [...] Avoir [CAT][topic + op_cat]+CSFS disponible éviterait le problème d'outils, au prix d'une efficacité onchain. + [...] Je pense qu'avec seulement CSFS disponible, vous continuez à avoir des problèmes d'outils + similaires, parce que vous devez utiliser des signatures adaptatives pour empêcher votre + contrepartie de choisir une valeur R différente pour la signature. Ces problèmes sont indépendants + de la complexité de la mise à jour et des mises à jour du protocole pair que Gregory Sanders décrit + ci-dessus." + +- **Descripteur de script de sortie de coffre :** Sjors Provoost a [posté][provoost ctvdesc] sur + Delving Bitcoin pour discuter de la manière dont les informations de récupération pour un + portefeuille utilisant des [coffres][topic vaults] pourraient être spécifiées à l'aide d'un + [descripteur de script de sortie][topic descriptors]. En particulier, il s'est concentré sur les + coffres basés sur [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (CTV), tels que ceux + fournis par la mise en œuvre de preuve de concept [simple-ctv-vault][] de James O'Beirne (voir + le [Bulletin #191][news191 simple-ctv-vault]). + + Provoost a cité un [commentaire][ingala vaultdesc] d'une discussion précédente par Salvatore Ingala + qui disait, "mon avis général est que les descripteurs ne sont pas l'outil approprié pour ce + but"---un sentiment avec lequel Sanket Kanjalkar [était d'accord][kanjalkar vaultdesc1] dans le fil + actuel mais [a trouvé][kanjalkar vaultdesc2] une solution potentielle. Kanjalkar a décrit une + variante de coffre basée sur CTV où les fonds sont déposés dans un descripteur plus typique et, de + là, sont déplacés + dans un coffre CTV. Cela évite une situation qui pourrait conduire les utilisateurs naïfs à perdre + de l'argent et permet également la création d'un descripteur qui suppose que tous les fonds versés + au descripteur typique sont déplacés dans un coffre en utilisant les mêmes paramètres à chaque fois. + Cela permettrait au descripteur du coffre CTV d'être succinct et complet sans aucune contorsion à la + langue des descripteurs. + +- **Discussion continue sur les avantages de CTV+CSFS pour BitVM :** les développeurs ont poursuivi + la discussion précédente (voir le [Bulletin #354][news354 bitvm]) sur la manière dont la + disponibilité des opcodes [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (CTV) et + [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (CSFS) pourrait "réduire les tailles de + transaction [BitVM] d'environ 10x" et permettre des peg-ins non interactifs. Anthony Towns a + [identifié][towns ctvbitvm] une vulnérabilité dans le contrat original proposé ; lui et plusieurs + autres développeurs ont décrit des solutions de contournement. Des discussions supplémentaires ont + examiné les avantages de l'utilisation du opcode [OP_TXHASH][] proposé plutôt que CTV. Chris Stewart + a [implémenté][stewart ctvimp] certaines des idées discutées en utilisant le logiciel de test de + Bitcoin Core, validant ces parties de la discussion et fournissant des exemples concrets pour les + examinateurs. + +- **Lettre ouverte à propos de CTV et CSFS :** James O'Beirne a [posté][obeirne letter] une lettre + ouverte à la mailing list Bitcoin-Dev signée par 66 individus (au moment de la rédaction), beaucoup + d'entre eux contributeurs à des projets liés à Bitcoin. La lettre "demande aux contributeurs de + Bitcoin Core de prioriser la revue et l'intégration de [OP_CHECKTEMPLATEVERIFY][topic + op_checktemplateverify] (CTV) et [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (CSFS) dans les + six prochains mois." Le fil contient plus de 60 réponses. Quelques points techniques saillants + incluent : + + - *Préoccupations et alternatives au support legacy :* [BIP119][] spécifie CTV pour les scripts + témoins v1 ([tapscript][topic tapscript]) et le script legacy. Gregory Sanders [écrit][sanders + legacy] que "le support du script legacy [...] augmente considérablement la surface de révision sans + gain de capacité connu et sans économies connues pour les protocoles." O'Beirne [a répondu][obeirne + legacy] que le support du script legacy pourrait économiser environ 8 vbytes dans certains cas, mais + Sanders a [lié][sanders p2ctv] à sa proposition précédente de pay-to-CTV (P2CTV) et à + l'implémentation de preuve de concept qui rend cette économie disponible dans le script témoin. + + - *Limites du support uniquement par CTV des coffres :* le signataire Jameson Lopp a [noté][lopp + ctvvaults] qu'il est "le plus intéressé par [les coffres][topic vaults]," lançant une discussion sur + l'ensemble des propriétés que les coffres CTV fourniraient, comment ils se comparent aux coffres + déployables aujourd'hui en utilisant des transactions pré-signées, et s'ils fournissent une + amélioration significative de la sécurité (surtout comparés aux coffres plus avancés qui + nécessiteraient des changements de consensus supplémentaires). Les points clés de cette discussion + incluaient : + + - *Danger de la réutilisation d'adresse :* les coffres pré-signés et CTV doivent empêcher les + utilisateurs de réutiliser les adresses de coffrage ou les fonds risquent d'être perdus. Une manière + d'accomplir cela peut être réalisée par un processus de coffrage en deux étapes. + procédure nécessitant deux transactions onchain pour déposer des fonds dans le coffre. Les coffres + plus avancés nécessitant des changements de consensus supplémentaires n'auraient pas ce problème, + permettant des dépôts même à une adresse réutilisée (bien que cela réduirait, bien sûr, la + [confidentialité][topic output linking]). + + - *Vol de fonds en attente :* les coffres avec signatures anticipées et CTV permettent le vol de + retraits autorisés. Par exemple, l'utilisateur du coffre, Bob, veut payer 1 BTC à Alice. Avec les + coffres à signatures anticipées et CTV, Bob suit la procédure suivante : + + - Retire 1 BTC (plus éventuellement les frais) de son coffre vers une adresse de mise en scène. + + - Attend le temps défini par le coffre. + + - Transfère 1 BTC à Alice. + + Si Mallory a volé la clé de mise en scène de Bob, elle peut voler le 1 BTC après que le retrait soit + complet mais avant que la transaction à Alice ne soit confirmée. Cependant, même si Mallory + compromet également la clé de retrait, elle ne peut pas voler de fonds restants dans le coffre parce + que Bob peut interrompre tout retrait en attente et rediriger les fonds vers une _adresse sûre_ + protégée par une clé ultra-sécurisée (ou des clés). + + Les coffres plus avancés ne nécessitent pas l'étape de mise en scène : le retrait de Bob ne pourrait + aller qu'à Alice ou à l'adresse sûre. Cela empêche Mallory de pouvoir voler des fonds entre les + étapes de retrait et de dépense. + + - *Suppression de clé :* un avantage des coffres basés sur CTV par rapport aux coffres à signatures + anticipées est qu'ils ne nécessitent pas de supprimer des clés privées pour garantir que l'ensemble + des transactions signées à l'avance sont les seules options de dépense disponibles. Cependant, + Gregory Maxwell [a noté][maxwell autodelete] qu'il est simple de concevoir un logiciel pour + supprimer une clé immédiatement après avoir signé les transactions sans jamais exposer la clé privée + aux utilisateurs. Aucun dispositif de signature matérielle n'est connu pour supporter cela + directement à l'heure actuelle, bien qu'au moins un dispositif le supporte via une intervention + manuelle de l'utilisateur---mais c'est aussi le cas qu'aucun matériel ne supporte CTV même pour les + tests à l'heure actuelle (à notre connaissance). Les coffres plus avancés partageraient l'avantage + sans clé de CTV mais nécessiteraient également une intégration dans le logiciel et le matériel. + + - *État statique :* un avantage revendiqué des coffres basés sur CTV par rapport aux coffres à + signatures anticipées est qu'il pourrait être possible de calculer toutes les informations + nécessaires pour récupérer le portefeuille à partir d'une sauvegarde statique, telle qu'un + [descripteur de script de sortie][topic descriptors]. Cependant, il y a déjà eu des travaux sur les + coffres à signatures anticipées qui permettent également des sauvegardes statiques en stockant les + parties non déterministes de l'état signé à l'avance dans les transactions onchain elles-mêmes (voir + le [Bulletin #255][news255 presig vault state]). Optech croit que les coffres plus avancés pourraient + également être récupérés à partir d'un état statique, mais nous n'avions pas vérifié cela avant la + publication. + + - *Réponses des contributeurs de Bitcoin Core :* à l'heure où nous écrivons ces lignes, quatre + individus qu'Optech reconnaît comme contributeurs actifs de Bitcoin Core ont répondu à la lettre sur + la liste de diffusion. Ils ont dit : + + - [Gregory Sanders][sanders ctvcom] : "Cette lettre demande des retours de la communauté technique + et voici mon retour. Les BIP non déployés qui n'ont pas reçu de mises à jour depuis des années ne + sont généralement pas un signe de + la santé de la proposition, et certainement pas une base pour rejeter les conseils techniques de + quelqu'un qui a prêté une attention particulière. Je rejette cette interprétation, l'élévation du + niveau des changements à cette proposition pour ne concerner que les ruptures flagrantes, et je + rejette évidemment un ultimatum basé sur le temps pour BIP119 tel quel. Je pense toujours que CTV + (encore dans le sens de la capacité) + CSFS méritent d'être considérés, mais c'est une manière + infaillible de le couler." + + - [Anthony Towns][towns ctvcom]: "De mon point de vue, la discussion sur CTV a manqué des étapes + importantes, et au lieu que ces étapes soient franchies, les défenseurs ont tenté d'utiliser la + pression publique pour forcer l'adoption selon un 'calendrier accéléré' pratiquement sans + interruption depuis au moins trois ans maintenant. J'ai essayé d'aider les défenseurs de CTV à + franchir les étapes que je crois qu'ils ont manquées, mais cela a principalement abouti à du silence + ou des insultes plutôt qu'à quelque chose de constructif. Au moins de là où je me trouve, cela crée + juste des problèmes d'incitation, sans les résoudre." + + - [Antoine Poinsot][poinsot ctvcom]: "L'effet de cette lettre a été, comme on aurait pu s'y + attendre, un recul majeur dans la progression de cette proposition (ou plus largement de ce faisceau + de capacités). Je ne suis pas sûr de la manière dont nous pouvons rebondir après cela, mais cela + implique nécessairement que quelqu'un se lève et fasse réellement le travail d'adresser le retour + technique de la communauté et de démontrer (de vrais) cas d'utilisation. La voie à suivre doit être + de construire un consensus sur la base d'arguments techniques objectifs et solides. Pas avec un + groupe de personnes exprimant leur intérêt et personne ne passant à l'action et aidant la + proposition à avancer." + + - [Sjors Provoost][provoost ctvcom]: "Permettez-moi également de parler un peu de ma propre + motivation. Les coffres-forts semblent être la seule fonctionnalité activée par la proposition que + je trouve personnellement assez importante pour travailler dessus. [...] Jusqu'à tout récemment, il + me semblait que l'élan pour les coffres-forts était dans OP_VAULT, qui à son tour nécessiterait + OP_CTV. Mais un code opérationnel à usage unique n'est pas idéal, donc ce projet ne semblait pas + aller quelque part. [...] Inversement, je ne m'oppose pas à CTV + CSFS ; je n'ai vu aucun argument + indiquant qu'ils sont nuisibles. Puisqu'il y a peu de potentiel MeVil, je pourrais aussi imaginer + d'autres développeurs développer et déployer ces changements avec prudence. Je garderais juste un + œil sur le processus. Ce que j'_opposerais_ serait une implémentation alternative basée sur Python + et un client d'activation comme Paul Sztorc a proposé." + + - *Déclarations des signataires :* les signataires de la lettre ont également clarifié leurs + intentions dans des déclarations ultérieures : + + - [James O'Beirne][obeirne ctvcom]: "tous ceux qui ont signé veulent explicitement voir la revue + imminente, l'intégration et la planification de l'activation pour CTV+CSFS spécifiquement." + + - [Andrew Poelstra][poelstra ctvcom]: "Les premières ébauches de la lettre demandaient effectivement + l'intégration et même l'activation, mais je n'ai signé aucune de ces premières ébauches. Ce n'est + que lorsque le langage a été atténué pour parler de priorités et de planification (et pour être une + "demande respectueuse" plutôt qu'une sorte d'exigence) que j'ai signé." + + - [Steven Roose][roose ctvcom] : "[La lettre] demande simplement aux contributeurs principaux de + mettre cette proposition à l'ordre du jour avec une certaine urgence. Pas de menaces, pas de mots + durs. Étant donné que seulement quelques contributeurs principaux avaient jusqu'à présent participé + à la conversation sur la proposition ailleurs, il semblait être une étape appropriée de communiquer + que nous voulons que les contributeurs principaux fournissent leur position dans cette conversation. + Je suis fermement opposé à une approche impliquant des clients d'activation indépendants et je pense + que le sentiment de cet e-mail s'aligne sur la préférence d'avoir Core impliqué dans tout + déploiement de mises à niveau de protocole." + + - [Harsha Goli][goli ctvcom] : "La plupart des gens ont signé parce qu'ils n'avaient vraiment aucune + idée de quelle devrait être la prochaine étape, et la pression pour les engagements de transaction + était telle qu'une mauvaise option (accumulation d'une lettre de signature) était plus optimale que + l'inaction. Dans les conversations avant l'envoi de la lettre (facilitées par mon enquête dans + l'industrie), je n'ai reçu que des réprimandes de la lettre de la part de nombreux signataires. Je + ne connais en fait pas une seule personne qui l'a considérée comme une bonne idée explicitement. Et + pourtant, ils ont signé. Il y a un signal dans cela." + +- **OP_CAT permet les signatures Winternitz :** le développeur Conduition a [posté][conduition + winternitz] sur la liste de diffusion Bitcoin-Dev un [prototypr d'implémentation][conduition impl] + qui utilise le code d'opération proposé [OP_CAT][topic op_cat] et d'autres instructions Script pour + permettre aux signatures [résistantes aux quantiques][topic quantum resistance] utilisant le + protocole Winternitz d'être vérifiées par la logique de consensus. L'implémentation de Conduition + nécessite presque 8 000 octets pour la clé, la signature et le script (dont la plupart est soumis à + la réduction de poids du témoin, réduisant le poids onchain à environ 2 000 vbytes). Cela représente + environ 8 000 vbytes de moins qu'un autre schéma de [signature Lamport][lamport signature] basé sur `OP_CAT` et + [précédemment proposé][rubin lamport] par Jeremy Rubin. + +- **Fonction de commit/reveal pour la récupération post-quantique :** Tadge Dryja a [posté][dryja + fawkes] sur la liste de diffusion Bitcoin-Dev une méthode permettant aux individus de dépenser des + UTXOs en utilisant des algorithmes de signature [vulnérables aux quantiques][topic quantum + resistance] même si des ordinateurs quantiques rapides permettraient autrement de rediriger (voler) + le résultat de toute tentative de dépense. Cela nécessiterait un soft fork et est une variation + d'une proposition précédente de Tim Ruffing (voir le [Bulletin #348][news348 fawkes]). + + Pour dépenser une sortie dans le schéma de Dryja, le dépensier crée un engagement envers trois + pièces d'informations : + + 1. Un hash de la clé publique correspondant à la clé privée qui contrôle les fonds, `h(pubkey)`. + Cela s'appelle l'_identifiant d'adresse_. + + 2. Un hash de la clé publique et du txid de la transaction que le dépensier souhaite éventuellement + diffuser, `h(pubkey, txid)`. Cela s'appelle la _preuve dépendante de la séquence_. + + 3. Le txid de la transaction éventuelle. Cela s'appelle le _txid d'engagement_. + + Aucune de ces informations ne révèle la clé publique sous-jacente, qui dans + ce schéma est supposé être connu uniquement de la personne contrôlant le UTXO. + + Le triple engagement est diffusé dans une transaction en utilisant un algorithme sécurisé contre les + attaques quantiques, par exemple comme une sortie `OP_RETURN`. À ce moment, un attaquant pourrait + tenter de diffuser son propre engagement en utilisant le même identifiant d'adresse mais un txid + d'engagement différent qui dépense les fonds vers le portefeuille de l'attaquant. Cependant, il n'y + a aucun moyen pour l'attaquant de générer une preuve séquentielle valide étant donné qu'il ne + connaît pas la clé publique sous-jacente. Cela ne sera pas immédiatement évident pour les nœuds de + vérification complète, mais ils seront capables de rejeter l'engagement de l'attaquant après que le + propriétaire de l'UTXO révèle la clé publique. + + Après que l'engagement se confirme à une profondeur appropriée, le dépensier révèle la transaction + complète correspondant au txid d'engagement. Les nœuds complets vérifient que la clé publique + correspond à l'identifiant d'adresse et que, en combinaison avec le txid, elle correspond à la + preuve dépendante de la séquence. À ce moment, les nœuds complets purgent tous les engagements sauf + le plus ancien (le plus profondément confirmé) pour cet identifiant d'adresse. Seul le premier txid + confirmé pour cet identifiant d'adresse avec une preuve dépendante de la séquence valide peut être + résolu en une transaction confirmée. + + Dryja donne des détails supplémentaires sur la manière dont ce schéma pourrait être déployé comme un + soft fork, comment l'octet d'engagement pourrait être réduit de moitié, et ce que les utilisateurs + et les logiciels d'aujourd'hui peuvent faire pour se préparer à utiliser ce schéma---ainsi que les + limitations de ce schéma pour les utilisateurs des [multisignatures scriptées][topic multisignature]. + +- **Variante OP_TXHASH avec support pour le parrainage de transaction :** Steven Roose a + [posté][roose txsighash] sur Delving Bitcoin à propos d'une variation sur `OP_TXHASH` appelée + `TXSIGHASH` qui étend les signatures [schnorr][topic schnorr signatures] de 64 octets avec des + octets supplémentaires pour indiquer à quels champs dans la transaction (ou transactions liées) la + signature s'engage. En plus des champs d'engagement proposés précédemment pour `OP_TXHASH`, Roose + note que la signature pourrait s'engager sur une transaction antérieure dans le bloc en utilisant + une forme efficace de [parrainage de transaction][topic fee sponsorship] (voir le [Bulletin + #295][news295 sponsor]). Il analyse ensuite les coûts onchain de ce mécanisme par rapport au + [CPFP][topic cpfp] existant et une proposition de parrainage précédente, concluant : "Avec + l'empilement [`TXSIGHASH`], le coût en octets virtuels de chaque transaction empilée peut même être + inférieur à leur coût original sans sponsor inclus [...] De plus, toutes les entrées sont des + dépenses de clé « simples », ce qui signifie qu'elles pourraient être agrégées si [CISA][topic cisa] + était déployé." + + À l'heure de la rédaction, le post n'avait reçu aucune réponse publique. + +## Changements notables dans le code et la documentation + +_Changements notables récents dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning +repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], +[Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement] +Propositions (BIPs)][bips repo], [Lightning BOLTs][bolts repo],[Lightning BLIPs][blips repo], +[Bitcoin Inquisition][bitcoin inquisition repo], et [BINANAs][binana repo]._ + +- [Bitcoin Core #32540][] introduit le point de terminaison REST `/rest/spenttxouts/BLOCKHASH`, qui + retourne une liste des sorties de transactions dépensées (prevouts) pour un bloc spécifié, + principalement dans un format binaire compact (.bin) mais aussi en variantes .json et .hex. Bien + qu'il était précédemment possible de faire cela avec le point de terminaison + `/rest/block/BLOCKHASH.json`, le nouveau point de terminaison améliore la performance des indexeurs + externes en éliminant la surcharge de la sérialisation JSON. + +- [Bitcoin Core #32638][] ajoute une validation pour s'assurer que tout bloc lu depuis le disque + correspond au hash de bloc attendu, détectant ainsi la corruption de données et les confusions + d'index qui auraient pu passer inaperçues auparavant. Grâce au cache de hash d'en-tête introduit + dans [Bitcoin Core #32487][], cette vérification supplémentaire est pratiquement sans surcoût. + +- [Bitcoin Core #32819][] et [#32530][Bitcoin Core #32530] fixent les valeurs maximales pour les + paramètres de démarrage `-maxmempool` et `-dbcache` à 500 Mo et 1 Go respectivement, sur les + systèmes 32 bits. Étant donné que cette architecture a une limite totale de RAM de 4 Go, des valeurs + supérieures aux nouvelles limites pourraient provoquer des incidents de manque de mémoire (OOM). + +- [LDK #3618][] implémente la logique côté client pour les [paiements asynchrones][topic async + payments], permettant à un nœud destinataire hors ligne de préarranger des [offres BOLT12][topic + offers] et des factures statiques avec un nœud LSP toujours en ligne. La PR introduit un cache + d'offres de réception asynchrone à l'intérieur de `ChannelManager` qui construit, stocke et fait persister + les offres et les factures. Elle définit également les nouveaux messages onion et les hook + nécessaires pour communiquer avec le LSP et intègre la machine à états dans le `OffersMessageFlow`. + +{% include snippets/recap-ad.md when="2025-07-08 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32540,32638,32819,3618,1479,32487,32530" %} +[news255 presig vault state]: /fr/newsletters/2023/06/14/#discussion-sur-les-annexes-a-taproot +[news348 ctvstep]: /fr/newsletters/2025/04/04/#avantages-ctv-csfs +[news268 ptlc]: /fr/newsletters/2023/09/13/#changements-de-messagerie-ln-pour-les-ptlc +[news191 simple-ctv-vault]: /en/newsletters/2022/03/16/#continued-ctv-discussion +[news354 bitvm]: /fr/newsletters/2025/05/16/#description-des-avantages-pour-bitvm-de-op-ctv-et-op-csfs +[rubin lamport]: https://gnusha.org/pi/bitcoindev/CAD5xwhgzR8e5r1e4H-5EH2mSsE1V39dd06+TgYniFnXFSBqLxw@mail.gmail.com/ +[osuntokun onion]: https://delvingbitcoin.org/t/reimagining-onion-messages-as-an-overlay-layer/1799/ +[news283 oniondirect]: /fr/newsletters/2024/01/03/#ldk-2723 +[news304 onionreply]: /fr/newsletters/2024/05/24/#core-lightning-7304 +[sanders ptlc]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/7 +[provoost ptlc]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/80 +[sanders ptlc2]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/81 +[sanders gist]: https://gist.github.com/instagibbs/1d02d0251640c250ceea1c66665ec163 +[towns ptlc]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/82 +[provoost ctvdesc]: https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766/ +[simple-ctv-vault]: https://github.com/jamesob/simple-ctv-vault +[ingala vaultdesc]: https://github.com/bitcoin/bips/pull/1793#issuecomment-2749295131 +[kanjalkar vaultdesc1]: https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766/3 +[kanjalkar vaultdesc2]: https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766/9 +[towns ctvbitvm]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/8 +[op_txhash]: /en/newsletters/2022/02/02/#composable-alternatives-to-ctv-and-apo +[stewart ctvimp]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/25 +[obeirne letter]: https://mailing-list.bitcoindevs.xyz/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com/ +[sanders legacy]: https://mailing-list.bitcoindevs.xyz/bitcoindev/b17d0544-d292-4b4d-98c6-fa8dc4ef573cn@googlegroups.com/ +[obeirne legacy]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPfvXfKEgA0RCvxR=mP70sfvpzTphTZGidy=JuSK8f1WnM9xYA@mail.gmail.com/ +[sanders p2ctv]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/72?u=harding +[lopp ctvvaults]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CADL_X_fxwKLdst9tYQqabUsJgu47xhCbwpmyq97ZB-SLWQC9Xw@mail.gmail.com/ +[maxwell autodelete]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAAS2fgSmmDmEhi3y39MgQj+pKCbksMoVmV_SgQmqMOqfWY_QLg@mail.gmail.com/ +[sanders ctvcom]: https://groups.google.com/g/bitcoindev/c/KJF6A55DPJ8/m/XVhyLCJiBQAJ +[towns ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aEu8CqGH0lX5cBRD@erisian.com.au/ +[poinsot ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/GLGZ3rEDfqaW8jAfIA6ac78uQzjEdYQaJf3ER9gd4e-wBXsiS2NK0wAj8LWK8VHf7w6Zru3IKbtDU5NM102jD8wMjjw8y7FmiDtQIy9U7Y4=@protonmail.com/ +[provoost ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/0B7CEBEE-FB2B-41CF-9347-B9C1C246B94D@sprovoost.nl/ +[obeirne ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPfvXfLc5-=UVpcvYrC=VP7rLRroFviLTjPQfeqMQesjziL=CQ@mail.gmail.com/ +[poelstra ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aEsvtpiLWoDsfZrN@mail.wpsoftware.net/ +[roose ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/035f8b9c-9711-4edb-9d01-bef4a96320e1@roose.io/ +[goli ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/mc0q6r14.59407778-1eb1-4e57-bcf2-c781d6f70b01@we.are.superhuman.com/ +[conduition winternitz]: https://mailing-list.bitcoindevs.xyz/bitcoindev/uCSokD_EM3XBQBiVIEeju5mPOy2OU-TTAQaavyo0Zs8s2GhAdokhJXLFpcBpG9cKF03dNZfq2kqO-PpxXouSIHsDosjYhdBGkFArC5yIHU0=@proton.me/ +[conduition impl]: https://gist.github.com/conduition/c6fd78e90c21f669fad7e3b5fe113182 +[lamport signature]: https://en.wikipedia.org/wiki/Lamport_signature +[dryja fawkes]: https://mailing-list.bitcoindevs.xyz/bitcoindev/cc2f8908-f6fa-45aa-93d7-6f926f9ba627n@googlegroups.com/ +[news348 fawkes]: /fr/newsletters/2025/04/04/#prouver-de-maniere-securisee-la-propriete-d-une-utxo-en-revelant-une-preimage-sha256 +[roose txsighash]: https://delvingbitcoin.org/t/jit-fees-with-txhash-comparing-options-for-sponsorring-and-stacking/1760 +[news295 sponsor]: /fr/newsletters/2024/03/27/#ameliorations-du-parrainage-des-frais-de-transaction From be565327566205fdc02ed7e9593a816b86734340 Mon Sep 17 00:00:00 2001 From: Octoshi <125779328+cryptozyu@users.noreply.github.com> Date: Mon, 14 Jul 2025 11:02:15 +0800 Subject: [PATCH 159/278] newsletter-360: translate into Chinese (#173) * newsletter-360: translate into Chinese * fix format & some content --------- Co-authored-by: Zhiwei(Jeffrey) Hu --- .../zh/newsletters/2025-06-27-newsletter.md | 74 +++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 _posts/zh/newsletters/2025-06-27-newsletter.md diff --git a/_posts/zh/newsletters/2025-06-27-newsletter.md b/_posts/zh/newsletters/2025-06-27-newsletter.md new file mode 100644 index 0000000000..73c5a8a4c7 --- /dev/null +++ b/_posts/zh/newsletters/2025-06-27-newsletter.md @@ -0,0 +1,74 @@ +--- +title: 'Bitcoin Optech Newsletter #360' +permalink: /zh/newsletters/2025/06/27/ +name: 2025-06-27-newsletter-zh +slug: 2025-06-27-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的周报总结了关于使用 P2P 协议消息对全节点进行指纹识别的研究，并就可能在 BIP380 描述符规范中移除对 BIP32 路径中 `H` 的支持寻求反馈。此外还包括我们的常规部分：总结了 Bitcoin Stack Exchange 上的热门问答、新版本和候选版本的公告，以及对热门比特币基础设施软件的重大变更介绍。 + +## 新闻 + +- ******使用 `addr` 消息对节点进行指纹识别：** Daniela Brozzoni 在 Delving Bitcoin 上[发布][brozzoni addr]了她与开发者 Naiyoma 进行的研究，该研究关于使用节点发送的 `addr` 消息在多个网络上识别同一个节点。节点向其对等节点发送 P2P 协议 `addr`（地址）消息来广告其他潜在节点，允许对等节点使用去中心化的 gossip 系统找到彼此。然而，Brozzoni 和 Naiyoma 能够使用其特定地址消息的详细信息对单个节点进行指纹识别，使他们能够识别在多个网络（如 IPv4 和 [Tor][topic anonymity networks]）上运行的同一个节点。 + + 研究人员建议了两种可能的缓解措施：从地址消息中移除时间戳，或者如果保留时间戳，则稍微随机化它们以使其对特定节点的特异性降低。 + +- ******是否有软件在描述符中使用 `H`？** Ava Chow 在 Bitcoin-Dev 邮件列表上[发布][chow hard]询问是否有任何软件生成使用大写 H 来表示强化 [BIP32][topic bip32] 密钥派生步骤的描述符。如果没有，[输出脚本描述符][topic descriptors]的 [BIP380][] 规范可能会被修改为只允许使用小写 h 和 `'` 来表示强化。Chow 指出，虽然 BIP32 允许大写 H，但 BIP380 规范之前包含了一个禁止使用大写 H 的测试，并且 Bitcoin Core 目前不接受大写 H。 + +## Bitcoin Stack Exchange 的精选问答 + +*[Bitcoin Stack Exchange][bitcoin.se] 是 Optech 贡献者寻找问题答案的首选之地之一，也是我们有闲暇时会给好奇和困惑的用户帮忙的地方。在这个月度栏目中，我们会列举自上次出刊以来出现的一些高票的问题和答案。* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [有什么方法可以阻止 Bitcoin Knots 节点作为我的对等节点吗？]({{bse}}127456) + Vojtěch Strnad 提供了一种基于用户代理字符串使用两个 Bitcoin Core RPC 阻止对等节点的方法，但不鼓励这种方法，并指向了一个相关的 [Bitcoin Core GitHub issue][Bitcoin Core #30036]，其中也有类似的不鼓励意见。 + +- [OP_CAT 对整数如何操作？]({{bse}}127436) + Pieter Wuille 解释说 Bitcoin Script 堆栈元素不包含数据类型信息，不同的操作码以不同的方式解释堆栈元素的字节。 + +- [使用致密区块中继的异步区块中继（BIP152）]({{bse}}127420) + 用户 bca-0353f40e 概述了 Bitcoin Core 对[致密区块][topic compact block relay]的处理，并估计了缺失交易对区块传播的影响。 + +- [为什么自私挖矿中攻击者的收入与其算力不成比例？]({{bse}}53030) + Antoine Poinsot 跟进了这个和[另一个]({{bse}}125682)较早的[自私挖矿][topic selfish mining]问题，指出“难度调整不考虑陈旧区块，这意味着降低竞争矿工的有效算力会增加矿工的利润（在足够长的时间尺度上），就像增加自己的算力一样”，（参见[周报 #358][news358 selfish mining]）。 + +## 新版本和候选版本 + +*热门比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本。* + +- [Bitcoin Core 28.2][] 是主流全节点实现的前一个发布系列的维护版本。它包含多个错误修复。 + +## 重大的代码和文档变更 + +*本周的重大变更有：[Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface（HWI）][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement Proposals（BIPs）][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo]。* + +- [Bitcoin Core #31981][] 向进程间通信（IPC）`Mining` 接口（参见周报 [#310][news310 ipc]）添加了一个 `checkBlock` 方法，该方法执行与 `proposal` 模式下的 `getblocktemplate` RPC 相同的有效性检查。这使得使用 [Stratum v2][topic pooled mining] 的矿池能够通过更快的 IPC 接口验证矿工提供的区块模板，而不是通过 RPC 序列化多达 4 MB 的 JSON。可以在选项中禁用工作量证明和默克尔根检查。 + +- [Eclair #3109][] 将其[可归因故障][topic attributable failures]支持（参见周报 [#356][news356 failures]）扩展到[蹦床支付][topic trampoline payments]。蹦床节点现在解密并存储为其准备的归因载荷部分，并为下一个蹦床跳跃准备剩余的数据块。此 PR 不实现蹦床节点的归因数据中继，这预计在后续 PR 中实现。 + +- [LND #9950][] 向 `DescribeGraph`、`GetNodeInfo` 和 `GetChanInfo` RPC 以及它们对应的 `lncli` 命令添加了一个新的 `include_auth_proof` 标志。包含此标志会返回[通道公告][topic channel announcements]签名，允许第三方软件验证通道详细信息。 + +- [LDK #3868][] 将[可归因故障][topic attributable failures]（参见周报 [#349][news349 attributable]）载荷的 [HTLC][topic htlc] 持有时间精度从 1 毫秒单位降低到 100 毫秒单位，以减轻时序指纹泄露。这使 LDK 与 [BOLTs #1044][] 草案的最新更新保持一致。 + +- [LDK #3873][] 将在注资输出被花费后忘记短通道标识符（SCID）的延迟从 12 个区块增加到 144 个区块，以允许[通道拼接][topic splicing]更新的传播。这是 [BOLTs #1270][] 中引入的 72 个区块延迟的两倍，Eclair 已实现该延迟（参见周报 [#359][news359 eclair]）。此 PR 还实现了对 `splice_locked` 消息交换过程的额外更改。 + +- [Libsecp256k1 #1678][] 添加了一个 `secp256k1_objs` CMake 接口库，该库公开了库的所有目标文件，以允许父项目（如 Bitcoin Core 计划的 [libbitcoinkernel][libbitcoinkernel project]）将这些目标直接链接到它们自己的静态库中。这解决了 CMake 缺乏将静态库链接到另一个静态库的原生机制的问题，并使下游用户免于提供自己的 `libsecp256k1` 二进制文件。 + +- [BIPs #1803][] 通过允许所有常见的强化路径标记来澄清 [BIP380][] 的[描述符][topic descriptors]语法，而 [#1871][bips #1871]、[#1867][bips #1867] 和 [#1866][bips #1866] 通过收紧密钥路径规则、允许重复参与者密钥和明确限制多路径子派生来完善 [BIP390][] 的 [MuSig2][topic musig] 描述符。 + +{% include snippets/recap-ad.md when="2025-07-01 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31981,3109,9950,3868,3873,1678,1803,1871,1867,1866,30036,1044,1270" %} +[bitcoin core 28.2]: https://bitcoincore.org/bin/bitcoin-core-28.2/ +[brozzoni addr]: https://delvingbitcoin.org/t/fingerprinting-nodes-via-addr-requests/1786/ +[chow hard]: https://mailing-list.bitcoindevs.xyz/bitcoindev/848d3d4b-94a5-4e7c-b178-62cf5015b65f@achow101.com/T/#u +[news358 selfish mining]: /zh/newsletters/2025/06/13/#calculating-the-selfish-mining-danger-threshold +[news310 ipc]: /zh/newsletters/2024/07/05/#bitcoin-core-30200 +[news356 failures]: /zh/newsletters/2025/05/30/#eclair-3065 +[news349 attributable]: /zh/newsletters/2025/04/11/#ldk-2256 +[news359 eclair]: /zh/newsletters/2025/06/20/#eclair-3110 +[libbitcoinkernel project]: https://github.com/bitcoin/bitcoin/issues/27587 From 54ea5c8d1178da0476560d0eb299c8332a34925b Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sat, 19 Jul 2025 15:06:57 +0200 Subject: [PATCH 160/278] Newsletter 362 translate in French (#2413) --- .../fr/newsletters/2025-07-11-newsletter.md | 134 ++++++++++++++++++ 1 file changed, 134 insertions(+) create mode 100644 _posts/fr/newsletters/2025-07-11-newsletter.md diff --git a/_posts/fr/newsletters/2025-07-11-newsletter.md b/_posts/fr/newsletters/2025-07-11-newsletter.md new file mode 100644 index 0000000000..8bc23389a4 --- /dev/null +++ b/_posts/fr/newsletters/2025-07-11-newsletter.md @@ -0,0 +1,134 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #362' +permalink: /fr/newsletters/2025/07/11/ +name: 2025-07-11-newsletter-fr +slug: 2025-07-11-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +La newsletter de cette semaine décrit brièvement une nouvelle bibliothèque permettant de compresser +les descripteurs de script de sortie pour une utilisation dans les codes QR. Sont également incluses +nos sections régulières résumant une +réunion du Bitcoin Core PR Review Club, annonçant des mises à jour et des versions candidates, +et décrivant les changements notables dans les projets d'infrastructure Bitcoin populaires. + +## Nouvelles + +- **Descripteurs compressés :** Josh Doman a [publié][dorman descom] sur Delving Bitcoin pour + annoncer une [bibliothèque][descriptor-codec] qu'il a écrite qui encode les [descripteurs de script + de sortie][topic descriptors] dans un format binaire qui réduit leur taille d'environ 40%. Cela peut + être particulièrement utile lorsque les descripteurs sont sauvegardés à l'aide de codes QR. Son post + entre dans les détails de l'encodage et mentionne qu'il prévoit d'incorporer la compression dans sa + bibliothèque de sauvegarde de descripteurs chiffrés (voir le [Bulletin #358][news358 descencrypt]). + +## Bitcoin Core PR Review Club + +*Dans cette section mensuelle, nous résumons une récente réunion du [Bitcoin Core PR Review Club][], +mettant en lumière certaines des questions importantes et des réponses. Cliquez +sur une question ci-dessous pour voir un résumé de la réponse donnée lors de la réunion.* + +[Améliorer les limites de déni de service de TxOrphanage][review club 31829] est un PR par +[glozow][gh glozow] qui change la logique d'éviction de `TxOrphanage` pour garantir à chaque pair +les ressources pour au moins 1 paquet de taille maximale pour la résolution d'orphelins. Ces +nouvelles garanties améliorent significativement le relai de paquets opportunistes +1-parent-1-enfant [1p1c relay], surtout (mais pas seulement) dans des conditions adverses. + +Le PR modifie les limites globales existantes de l'orphelinat et introduit de nouvelles limites par +pair. Ensemble, elles protègent contre une utilisation excessive de la mémoire et l'épuisement +computationnel. Le PR remplace également l'approche d'éviction aléatoire par une algorithmique, +calculant un score de DoS par pair. + +_Note : le PR a subi [quelques changements significatifs][review club 31829 changes] depuis le +Review Club, le plus important étant l'utilisation d'une limite de score de latence au lieu d'une +limite d'annonce._ + +{% include functions/details-list.md + q0="Pourquoi la limite actuelle de taille maximale globale de TxOrphanage de 100 transactions avec + éviction aléatoire est-elle problématique ?" + a0="Elle permet à un pair malveillant de submerger un nœud avec des transactions orphelines, + finissant par causer l'éviction de toutes les transactions légitimes d'autres pairs. Cela peut être + utilisé pour empêcher la réussite du relais de transactions opportunistes 1-parent-1-enfant, puisque + l'enfant ne pourrait pas rester longtemps dans l'orphelinat." + a0link="https://bitcoincore.reviews/31829#l-12" + q1="Comment fonctionne le nouvel algorithme d'éviction à un haut niveau ?" + a1="L'éviction n'est plus aléatoire. L'algorithme identifie le pair se comportant le « pire » basé + sur un « score de DoS » et évince l'annonce de transaction la plus ancienne de ce pair. Cela protège + les pairs se comportant bien de voir les enfants de leurs transactions évictés par un pair se comportant + mal." + a1link="https://bitcoincore.reviews/31829#l-19" + q2="Pourquoi est-il souhaitable de permettre aux pairs de dépasser leurs limites individuelles ?" + a2="Les pairs peuvent utiliser plus de + ressources simplement parce qu'ils sont un + pair utile, qui diffuse des transactions utiles telles que les CPFPs." + a2link="https://bitcoincore.reviews/31829#l-25" + q3="Le nouvel algorithme évince les annonces au lieu des transactions. + Quelle est la différence et pourquoi est-ce important ?" + a3="Une annonce est une paire composée d'une transaction et du pair qui l'a + envoyée. En évinçant les annonces, un pair malveillant ne peut pas évincer une + transaction qui a également été envoyée par un pair honnête." + a3link="https://bitcoincore.reviews/31829#l-34" + q4="Qu'est-ce que le “DoS Score” d'un pair et comment est-il calculé ?" + a4="Le DoS score d'un pair est le maximum entre son “score de mémoire” (mémoire + utilisée / mémoire réservée) et son “score CPU” (annonces faites / + limite d'annonces). Utiliser un score combiné unique simplifie la logique d'éviction + en une seule boucle qui cible le pair dépassant le plus agressivement l'une ou l'autre de ses + limites." + a4link="https://bitcoincore.reviews/31829#l-133" +%} + +## Mises à jour et versions candidates + +_Nouvelles versions et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de mettre à niveau vers les nouvelles versions ou d'aider à tester les versions candidates._ + +- [LND v0.19.2-beta.rc2][] est un candidat à la sortie pour une version de maintenance de ce nœud LN + populaire. + +## Changements notables dans le code et la documentation + +_Changements récents notables dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning +repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Interface de Portefeuille Matériel (HWI)][hwi +repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Propositions d'Amélioration de Bitcoin (BIPs)][bips +repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Inquisition Bitcoin][bitcoin inquisition repo], et [BINANAs][binana +repo]._ + +- [Core Lightning #8377][] renforce les exigences de parsing des factures [BOLT11][] en mandatant + que les expéditeurs ne paient pas une facture si un [secret de paiement][topic payment secrets] est + manquant ou si un champ obligatoire tel que p (hash de paiement), h (hash de description), ou s + (secret), a une longueur incorrecte. Ces changements sont faits pour s'aligner sur les mises à jour + récentes de la spécification (voir les Bulletins [#350][news350 bolts] et [#358][news358 bolts]). + +- [BDK #1957][] introduit le regroupement RPC pour l'historique des transactions, les preuves de + Merkle, et les demandes d'en-tête de bloc pour optimiser la performance de scan complet et de + synchronisation avec un backend Electrum. Ce PR ajoute également la mise en cache des ancres pour + sauter la revalidation de la Vérification Simple de Paiement (SPV) (voir le Bulletin [#312][news312 + spv]) pendant une synchronisation. En utilisant des données d'exemple, l'auteur a observé des + améliorations de performance de 8,14 secondes à 2,59 secondes avec le regroupement d'appels RPC sur + un scan complet et de 1,37 secondes à 0,85 secondes avec la mise en cache pendant une + synchronisation. + +- [BIPs #1888][] retire `H` comme marqueur de chemin renforcé de [BIP380][], ne laissant que le `h` + canonique et l'alternative `'`. Le récent Bulletin [#360][news360 bip380] avait noté que la grammaire + avait été clarifiée pour permettre les trois marqueurs, mais puisque peu (voire aucun) des implémentations de + descripteur ne le supportent réellement (ni Bitcoin Core ni rust-miniscript ne le font), la spécification + est resserrée pour l'interdire. + +{% include snippets/recap-ad.md when="2025-07-15 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="8377,1957,1888" %} +[LND v0.19.2-beta.rc2]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.2-beta.rc2 +[news358 descencrypt]: /fr/newsletters/2025/06/13/#bibliotheque-de-chiffrement-de-descripteur +[dorman descom]: https://delvingbitcoin.org/t/a-rust-library-to-encode-descriptors-with-a-30-40-size-reduction/1804 +[descriptor-codec]: https://github.com/joshdoman/descriptor-codec +[news350 bolts]: /fr/newsletters/2025/04/18/#bolts-1242 +[news358 bolts]: /fr/newsletters/2025/06/13/#bolts-1243 +[news312 spv]: /fr/newsletters/2024/07/19/#bdk-1489 +[news360 bip380]: /fr/newsletters/2025/06/27/#bips-1803 +[review club 31829]: https://bitcoincore.reviews/31829 +[gh glozow]: https://github.com/glozow +[review club 31829 changes]: https://github.com/bitcoin/bitcoin/pull/31829#issuecomment-3046495307 +[1p1c relay]: /fr/bitcoin-core-28-wallet-integration-guide/#relais-un-parent-un-enfant-1p1c From 5dbcfc0458a8b54ef95b1d2be17be6d27e93f4aa Mon Sep 17 00:00:00 2001 From: Jiri Jakes Date: Sat, 19 Jul 2025 08:12:09 +0800 Subject: [PATCH 161/278] Newsletter-357: Translate into Czech --- .../cs/newsletters/2025-06-06-newsletter.md | 182 ++++++++++++++++++ 1 file changed, 182 insertions(+) create mode 100644 _posts/cs/newsletters/2025-06-06-newsletter.md diff --git a/_posts/cs/newsletters/2025-06-06-newsletter.md b/_posts/cs/newsletters/2025-06-06-newsletter.md new file mode 100644 index 0000000000..2f2fd88ac7 --- /dev/null +++ b/_posts/cs/newsletters/2025-06-06-newsletter.md @@ -0,0 +1,182 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 357' +permalink: /cs/newsletters/2025/06/06/ +name: 2025-06-06-newsletter-cs +slug: 2025-06-06-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden sdílí analýzu synchronizace plných uzlů bez +starých witnessů. Též nechybí naše pravidelné rubriky s popisem +diskuzí o změnách konsenzu, oznámeními nových vydání a souhrnem +významných změn v populárním bitcoinovém páteřním software. + +## Novinky + +- **Synchronizace plného uzlu bez witnessů:** Jose SK zaslal do fóra + Delving Bitcoin [příspěvek][sk nowit] se souhrnem své [analýzy][sk nowit gist] + o bezpečnostních kompromisech v prostředí, kde by mohly nově spuštěné plné uzly + v určité konfiguraci přeskočit některá historická data v blockchainu. + Ve výchozím nastavení používají uzly Bitcoin Core konfiguraci `assumevalid`, + která přeskočí validaci skriptů v blocích vytvořených více než měsíc či dva + před vydáním spouštěné verze Bitcoin Core. Mnoho uživatelů Bitcoin Core + dále nastaví volbu `prune` (ve výchozím nastavení vypnutou), která smaže + bloky po určité době od jejich validace (tato doba závisí na velikosti bloků + a uživatelově nastavení). + + SK tvrdí, že data witnessů, která jsou nezbytná pouze pro validaci skriptů, + by neměla být ořezanými uzly u assumevalid bloků stahována, protože + nebudou pro validaci skriptů použita a nakonec budou smazána. Přeskočení + stahování witnessů může dle něj „snížit využívání šířky pásma o více než + 40 %.” + + Ruben Somsen [tvrdí][somsen nowit], že tento návrh do určité míry mění + bezpečnostní model. I když nejsou skripty validovány, stahovaná data + jsou ověřována oproti commitmentu z Merkleova kořene z hlavičky bloku. + To zajišťuje, že jsou data v době úvodního stahování dostupná a nepoškozená. + Pokud by nikdo pravidelně existenci dat nevalidoval, mohla by nakonec + být ztracená, což se již [stalo][ripple loss] nejméně jednomu altcoinu. + + Diskuze v době psaní nadále probíhala. + +## Diskuze o změnách konsenzu + +_Měsíční rubrika shrnující návrhy a diskuze o změnách pravidel +bitcoinového konsenzu._ + +- **Zpráva o kvantových počítačích:** Clara Shikhelman zaslala do fóra + Delving Bitcoin [příspěvek][shikelman quantum] se souhrnem [zprávy][sm + report], kterou sepsala spolu s Anthonym Miltonem, o hrozbách + kvantových počítačů bitcoinovým uživatelům, s přehledem několika možných + cest ke [kvantové odolnosti][topic quantum resistance] a s analýzou + kompromisů upgradu bitcoinového protokolu. Autoři zjistili, že 4 až 10 miliónů + BTC jsou potenciálně zranitelné vůči kvantové krádeži, že nějaká opatření + jsou dnes již možná, že těžbu bitcoinů kvantové počítače v blízké + i středně vzdálené budoucnosti nejspíše neohrozí a že upgrade bude + vyžadovat široký souhlas. + +- **Váhový limit transakcí s výjimkami zabraňujícími konfiskacím:** + Vojtěch Strnad zaslal do fóra Delving Bitcoin [příspěvek][strnad limit] + s návrhem na změnu konsenzu omezující maximální velikost většiny + transakcí v bloku. Toto jednoduché pravidlo by povolilo transakci + větší než 400 000 váhových jednotek (100 000 vbyte) v bloku pouze, + pokud by to byla jediná transakce v bloku (vedle mincetvorné transakce). + Strnad a další popisují motivace stojící za omezením maximální váhy: + + - _Jednodušší optimalizace šablon bloku:_ čím menší jsou položky v porovnání + s celkovým limitem, tím snazší je nalézt téměř optimální + řešení [problému batohu][knapsack problem]. Zčásti je to díky minimalizaci + prostoru zbylému na konci, neboť menší položky zanechají méně nevyužitého + prostoru. + + - _Jednodušší pravidla přeposílání:_ pravidla přeposílání nepotvrzených + transakcí mezi uzly předpovídají, které transakce budou vytěžené, čímž + zabraňují plýtvání šířkou pásma. Obrovské transakce ztěžují přesné + předpovídání, neboť i drobná změna horního jednotkového poplatku + jim může způsobit zpoždění nebo vyloučení. + + - _Obrana před centralizací těžby:_ jsou-li přeposílající plné + uzly schopné zpracovat téměř všechny transakce, je zajištěno, + že uživatelé neobvyklých transakcí nemusí platit [poplatky bokem][topic + out-of-band fees], které mohou vést k centralizaci těžby. + + Gregory Sanders [poznamenal][sanders limit], že by na základě 12 let konzistentních + pravidel přeposílání Bitcoin Core mohlo být rozumné jednoduše soft forkem + stanovit maximální váhový limit bez jakýchkoliv výjimek. Gregory Maxwell + [dodal][maxwell limit], že transakce, které utrácejí pouze UTXO vytvořená + před soft forkem, by mohla mít udělenou výjimku a že by [přechodný soft fork][topic + transitory soft forks] těmto restrikcím umožnil expirovat, pokud + by se komunita rozhodla soft fork neobnovit. + + Další diskuze zkoumala potřeby jednotlivých stran používat velké transakce (hlavně + uživatelé [BitVM][topic acc]) a zda-li jsou dostupné alternativní přístupy. + +- **Odstranění výstupů z množiny UTXO dle hodnoty a doby:** Robin + Linus zaslal do fóra Delving Bitcoin [příspěvek][linus dust] s návrhem + soft forku, který by po nějaké době odstraňoval z množiny UTXO výstupy + s nízkými hodnotami. Bylo diskutováno několik variací této myšlenky, + mezi které patřilo: + + - _Zničení starých neekonomických prostředků:_ výstupy s malými hodnotami, + které nebyly dlouho utraceny, by mohly být neutratitelné. + + - _Požadavek, aby staré neekonomické prostředky dodaly při utracení důkaz existence:_ + [utreexo][topic utreexo] nebo podobný systém by mohly být použité k přiložení + dokladu, že výstupy utrácené transakcí jsou součástí množiny UTXO. + Staré a [neekonomické výstupy][topic uneconomical outputs] by tento doklad + musely přiložit, avšak novější nebo hodnotnější výstupy by byly i nadále uložené + v množině UTXO. + + Kterékoliv z řešení by efektivně omezilo maximální velikost množiny UTXO + (za předpokladu minimální hodnoty a 21miliónového limitu). Bylo diskutováno + několik zajímavých technických aspektů návrhu, včetně praktičtějších alternativ + k utreexo dokladům. + +## Vydání nových verzí + +*Vydání nových verzí oblíbených páteřních bitcoinových projektů. Prosíme, +zvažte upgrade či pomoc s testováním.* + +- [Core Lightning 25.05rc1][] je kandidátem na vydání příští hlavní verze této oblíbené + implementace LN uzlu. + +- [LND 0.19.1-beta.rc1][] je kandidátem na vydání údržbové verze této populární + implementace LN uzlu. + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo] a [repozitáři BINANA][binana repo]._ + +- [Bitcoin Core #32582][] přidává nové logovací zprávy pro měření výkonnosti + [rekonstrukce kompaktních bloků][topic compact block relay]. Sleduje celkovou + velikost transakcí, které uzel od svých spojení vyžádá (`getblocktxn`) a počet + a celkovou velikost transakcí, které uzel svým spojením posílá (`blocktxn`). + Dále pro sledování doby vyhledávání v mempoolu přidává časové razítko na + začátek `PartiallyDownloadedBlock::InitData()`. [Zpravodaj č. 315][news315 compact] + popisuje zprávu o statistikách rekonstrukce kompaktních bloků. + +- [Bitcoin Core #31375][] přidává CLI nástroj `bitcoin -m`, který obaluje a spouští + [multiprocesové][multiprocess project] binárky `bitcoin node` + (`bitcoind`), `bitcoin gui` (`bitcoinqt`) a `bitcoin rpc` (`bitcoin-cli + -named`). V současnosti fungují tyto příkazy stejně jako monolitické binárky + (kromě aktivované volby `-ipcbind`, viz [zpravodaj č. 320][news320 ipc]), avšak + budoucí verze umožní spouštět jednotlivé komponenty nezávisle na odlišných + strojích a v různých prostředích. [Zpravodaj č. 353][news353 pr review] + popisuje sezení Bitcoin Core PR Review Clubu zabývající se tímto PR. + +- [BIPs #1483][] začleňuje [BIP77][], který navrhuje [payjoin v2][topic payjoin]. + V této asynchronní bezserverové verzi odesílatel a příjemce poskytnou + zašifrovaná PSBT serveru poskytujícímu payjoinový adresář; tento server + pouze ukládá a přeposílá zprávy. Jelikož adresář nemůže číst ani měnit datový + obsah zpráv, nemusí ani jedna peněženka hostovat veřejný server ani být současně + online. Více podrobností o payjoin v2 poskytuje [zpravodaj č. 264][news264 payjoin]. + +{% include snippets/recap-ad.md when="2025-06-10 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32582,31375,1483" %} +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[ripple loss]: https://x.com/JoelKatz/status/1919233214750892305 +[sk nowit]: https://delvingbitcoin.org/t/witnessless-sync-for-pruned-nodes/1742/ +[sk nowit gist]: https://gist.github.com/JoseSK999/df0a2a014c7d9b626df1e2b19ccc7fb1 +[somsen nowit]: https://gist.github.com/JoseSK999/df0a2a014c7d9b626df1e2b19ccc7fb1?permalink_comment_id=5597316#gistcomment-5597316 +[shikelman quantum]: https://delvingbitcoin.org/t/bitcoin-and-quantum-computing/1730/ +[sm report]: https://chaincode.com/bitcoin-post-quantum.pdf +[strnad limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/ +[knapsack problem]: https://cs.wikipedia.org/wiki/Probl%C3%A9m_batohu +[sanders limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/2 +[maxwell limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/4 +[linus dust]: https://delvingbitcoin.org/t/dust-expiry-clean-the-utxo-set-from-spam/1707/ +[lnd 0.19.1-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.1-beta.rc1 +[news315 compact]: /cs/newsletters/2024/08/09/#statistika-rekonstruovani-kompaktnich-bloku +[multiprocess project]: https://github.com/ryanofsky/bitcoin/blob/pr/ipc/doc/design/multiprocess.md +[news320 ipc]: /cs/newsletters/2024/09/13/#bitcoin-core-30509 +[news264 payjoin]: /cs/newsletters/2023/08/16/#bezserverovy-payjoin +[news353 pr review]: /cs/newsletters/2025/05/09/#bitcoin-core-pr-review-club From 23e6ab7ab993859fc6c3d7945b3094a66d009f25 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sat, 19 Jul 2025 19:00:03 +0200 Subject: [PATCH 162/278] Create 2025-07-18-newsletter.md --- .../fr/newsletters/2025-07-18-newsletter.md | 137 ++++++++++++++++++ 1 file changed, 137 insertions(+) create mode 100644 _posts/fr/newsletters/2025-07-18-newsletter.md diff --git a/_posts/fr/newsletters/2025-07-18-newsletter.md b/_posts/fr/newsletters/2025-07-18-newsletter.md new file mode 100644 index 0000000000..d66671f242 --- /dev/null +++ b/_posts/fr/newsletters/2025-07-18-newsletter.md @@ -0,0 +1,137 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #363' +permalink: /fr/newsletters/2025/07/18/ +name: 2025-07-18-newsletter-fr +slug: 2025-07-18-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +La newsletter de cette semaine inclut nos +sections régulières résumant les changements récents apportés aux clients et services, les +annonces de nouvelles versions et de candidats à la publication, et les résumés des modifications +notables apportées aux logiciels d'infrastructure Bitcoin populaires. + +## Nouvelles + +_Aucune nouvelle significative cette semaine n'a été trouvée dans nos [sources][]._ + +## Changements dans les services et logiciels clients + +*Dans cette rubrique mensuelle, nous mettons en lumière des mises à jour intéressantes des +portefeuilles et services Bitcoin.* + +- **Floresta v0.8.0 lancé :** + La version [Floresta v0.8.0][floresta v0.8.0] de ce nœud [Utreexo][topic utreexo] ajoute le support + pour le [transport P2P version 2 (BIP324)][topic v2 p2p transport], [testnet4][topic testnet], des + métriques et une surveillance améliorées, parmi d'autres fonctionnalités et corrections de bugs. + +- **RGB v0.12 annoncé :** + Le [billet de blog][rgb blog] RGB v0.12 annonce la sortie de la couche de consensus de RBG pour les + contrats intelligents [validés côté client][topic client-side validation] de RGB sur le testnet et + le mainnet de Bitcoin. + +- **Dispositif de signature FROST disponible :** + Les dispositifs de signature [Frostsnap][frostsnap website] prennent en charge la [signature à seuil][topic + threshold signature]k-de-n utilisant le protocole FROST, avec seulement une signature unique sur la chaîne. + +- **Gemini ajoute le support de taproot :** + Gemini Exchange et Gemini Custody ajoutent le support pour l'envoi (retrait) vers des adresses + [taproot][topic taproot]. + +- **Electrum 4.6.0 lancé :** + [Electrum 4.6.0][electrum 4.6.0] ajoute le support pour les [échanges sous-marins][topic submarine + swaps] utilisant nostr pour la découvrabilité. + +## Mises à jour et versions candidates + +_Nouvelles versions et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de mettre à niveau vers les nouvelles versions ou d'aider à tester les versions candidates._ + +- [LND v0.19.2-beta][] est la sortie d'une version de maintenance de ce nœud LN populaire. Elle + contient des corrections de bugs importants et des améliorations de performance. + +## Changements notables dans le code et la documentation + +_Changements notables récents dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning +repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], +[Interface de Portefeuille Matériel (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Propositions d'Amélioration de Bitcoin (BIPs)][bips +repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Inquisition Bitcoin][bitcoin +inquisition repo], et [BINANAs][binana repo]._ + +- [Bitcoin Core #32604][] limite le taux de journalisation inconditionnelle sur disque tel que pour + `LogPrintf`, `LogInfo`, `LogWarning` et `LogError` pour atténuer le remplissage du disque et les + attaques en attribuant à chaque source un quota de 1 Mo par heure. Toutes les lignes de journal sont + préfixées d'un astérisque (*) lorsque la localisation d'une source est supprimée. + Les sorties console, les journaux avec un argument de catégorie explicite et les messages + `UpdateTip` Initial Block Download (IBD) sont exemptés des limites de taux. Lorsque le + quota est réinitialisé, Core affiche le nombre d'octets qui ont été supprimés. + +- [Bitcoin Core #32618][] supprime l'option `include_watchonly` et ses + variantes, ainsi que le champ `iswatchonly` de tous les RPCs du portefeuille car + les portefeuilles [descriptor][topic descriptors] ne supportent pas la combinaison des descripteurs + watch-only et dépensables. Auparavant, les utilisateurs pouvaient importer une adresse ou + un script watch-only dans un portefeuille de dépenses legacy. Cependant, les portefeuilles legacy + ont maintenant été supprimés. + +- [Bitcoin Core #31553][] ajoute la gestion des réorganisations de blocs au projet [cluster + mempool][topic cluster mempool] en introduisant la fonction `TxGraph::Trim()`. + Lorsqu'une réorganisation réintroduit des transactions précédemment confirmées dans le mempool et + que le cluster combiné résultant dépasse les limites de nombre ou de poids de cluster, `Trim()` + construit une linéarisation rudimentaire, ordonnée par frais, respectant les dépendances. Si l'ajout + d'une transaction devait dépasser une limite, cette transaction et tous ses descendants sont + supprimés. + +- [Core Lightning #7725][] ajoute une visionneuse de journaux JavaScript légère qui charge + les fichiers de journal CLN dans un navigateur et permet aux utilisateurs de filtrer les messages + par daemon, type, canal, ou regex. Cet outil ajoute un surcroît minimal de maintenance au dépôt + tout en améliorant l'expérience de débogage pour les développeurs et les opérateurs de nœuds. + +- [Eclair #2716][] implémente un système de réputation locale pour les pairs pour [HTLC + endorsement][topic htlc endorsement] qui suit les frais de routage gagnés par + chaque pair entrant par rapport aux frais qui auraient dû être gagnés en fonction de la + liquidité et des emplacements [HTLC][topic htlc] utilisés. Les paiements réussis résultent en un + score parfait, les paiements échoués le diminuent, et les HTLC qui restent en attente au-delà + du seuil configuré sont fortement pénalisés. Lors du transfert, le nœud + inclut son score de pair actuel dans l'endorsement TLV `update_add_htlc` (voir + le Bulletin [#315][news315 htlc]). Les opérateurs peuvent ajuster la dégradation de la réputation + (`half-life`), le seuil de paiement bloqué (`max-relay-duration`), le poids de la pénalité pour les + HTLC bloqués (`pending-multiplier`), ou simplement désactiver le + système de réputation entièrement dans la configuration. Cette PR collecte principalement + des données pour améliorer la recherche sur les [attaques de blocage de canal][topic channel jamming + attacks] et n'implémente pas encore de pénalités. + +- [LDK #3628][] implémente la logique côté serveur pour les [paiements asynchrones][topic + async payments], permettant à un nœud LSP de fournir des factures statiques [BOLT12][topic offers] + au nom d'un destinataire souvent hors ligne. Le nœud LSP peut accepter + les messages `ServeStaticInvoice` du destinataire, stocker les factures statiques fournies, et + répondre aux demandes de facture du payeur en recherchant et en retournant + la facture mise en cache via les [chemins aveuglés][topic rv routing]. + +- [LDK #3890][] change la manière dont il évalue les routes dans son algorithme de recherche de + chemin en considérant le coût total divisé par la limite de montant du canal (coût par sat de capacité + utilisable) au lieu de considérer uniquement le coût total brut. Cela biaise la + sélection vers des routes de plus grande capacité et réduit l'utilisation excessive de le sharding + [MPP][topic multipath payments], résultant en un taux de succès de paiement plus élevé. Bien + que le changement pénalise excessivement les petits canaux, ce compromis est préférable au sharding + excessif précédent. + +- [LND #10001][] active le protocole de quiescence en production (voir le Bulletin [#332][news332 + quiescence]) et ajoute une nouvelle valeur de configuration `--htlcswitch.quiescencetimeout`, qui + spécifie la durée maximale pendant laquelle un canal peut être quiescent. La valeur assure que les + protocoles dépendants, tels que les [engagements dynamiques][topic channel commitment upgrades], se + terminent dans la période de timeout. La valeur par défaut est de 60 secondes, et la valeur minimale + est de 30 secondes. + +{% include snippets/recap-ad.md when="2025-07-22 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32604,32618,31553,7725,2716,3628,3890,10001" %} +[LND v0.19.2-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.2-beta +[sources]: /en/internal/sources/ +[floresta v0.8.0]: https://github.com/vinteumorg/Floresta/releases/tag/v0.8.0 +[rgb blog]: https://rgb.tech/blog/release-v0-12-consensus/ +[frostsnap website]: https://frostsnap.com/ +[electrum 4.6.0]: https://github.com/spesmilo/electrum/releases/tag/4.6.0 +[news315 htlc]: /fr/newsletters/2024/08/09/#eclair-2884 +[news332 quiescence]: /fr/newsletters/2024/12/06/#lnd-8270 From 2b25d021065988d3dafc0102626144d64290e449 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Tue, 22 Jul 2025 16:11:37 +0200 Subject: [PATCH 163/278] Add German translation of Newsletter #363 (#2422) Co-authored-by: garfiel-d --- .../de/newsletters/2025-07-18-newsletter.md | 85 +++++++++++++++++++ 1 file changed, 85 insertions(+) create mode 100644 _posts/de/newsletters/2025-07-18-newsletter.md diff --git a/_posts/de/newsletters/2025-07-18-newsletter.md b/_posts/de/newsletters/2025-07-18-newsletter.md new file mode 100644 index 0000000000..5fa7292e76 --- /dev/null +++ b/_posts/de/newsletters/2025-07-18-newsletter.md @@ -0,0 +1,85 @@ +--- +title: 'Bitcoin Optech Newsletter #363' +permalink: /de/newsletters/2025/07/18/ +name: 2025-07-18-newsletter-de +slug: 2025-07-18-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche enthält wie gewohnt unsere regelmäßigen Abschnitte mit Zusammenfassungen +zu Updates bei Diensten und Client-Software, der Ankündigung neuer Releases und Release-Kandidaten +sowie einer Übersicht wichtiger Änderungen an beliebter Bitcoin-Infrastruktur-Software. + +## Nachrichten + +_In dieser Woche wurden in unseren [Quellen][] keine besonderen Nachrichten gefunden._ + +## Änderungen an Diensten und Client-Software + +*In diesem monatlichen Abschnitt stellen wir interessante Neuerungen bei Bitcoin-Wallets und +-Diensten vor.* + +- **Floresta v0.8.0 veröffentlicht:** + Das [Floresta v0.8.0][floresta v0.8.0] Release dieses [Utreexo][topic utreexo] Knotens unterstützt nun [Version 2 P2P-Transport (BIP324)][topic v2 p2p transport], + [testnet4][topic testnet], erweiterte Metriken und Monitoring sowie weitere Funktionen und Fehlerbehebungen. + +- **RGB v0.12 angekündigt:** + Der [Blogpost zu RGB v0.12][rgb blog] kündigt die Veröffentlichung der Konsensschicht für RGBs [clientseitig validierte][topic client-side validation] Smart Contracts + auf Bitcoin-Testnet und Mainnet an. + +- **FROST-Signiergerät verfügbar:** + [Frostsnap][frostsnap website] Signiergeräte unterstützen k-aus-n [Threshold-Signaturen][topic threshold signature] mit dem FROST-Protokoll, wobei nur eine einzige + Signatur on-chain erscheint. + +- **Gemini unterstützt Taproot:** + Gemini Exchange und Gemini Custody unterstützen nun das Senden (Abheben) an [Taproot][topic taproot] Adressen. + +- **Electrum 4.6.0 veröffentlicht:** + [Electrum 4.6.0][electrum 4.6.0] bietet jetzt Unterstützung für [Submarine Swaps][topic submarine swaps] mit nostr zur Auffindbarkeit. + +## Releases und Release-Kandidaten + +_Neue Releases und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie ein Upgrade auf neue Releases oder helfen Sie beim Testen von +Release-Kandidaten._ + +- [LND v0.19.2-beta][] ist das Release einer Wartungsversion dieses beliebten LN-Knotens. Es "enthält wichtige Fehlerbehebungen und + Leistungsverbesserungen." + +## Wichtige Code- und Dokumentationsänderungen + +_Wichtige kürzliche Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], +[libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], +[Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und +[BINANAs][binana repo]._ + +- [Bitcoin Core #32604][] begrenzt das bedingungslose Schreiben von Logs auf die Festplatte, z.B. für `LogPrintf`, `LogInfo`, `LogWarning` und `LogError`, um Angriffe zu verhindern, bei denen die Festplatte gefüllt wird. Jeder Ursprungsort erhält ein Kontingent von 1 MB pro Stunde. Alle Logzeilen werden mit einem Stern (*) versehen, wenn ein Ursprungsort unterdrückt wird. Konsolenausgaben, Logs mit explizitem Kategorie-Argument und `UpdateTip`-Meldungen beim Initial Block Download (IBD) sind von der Begrenzung ausgenommen. Wenn das Kontingent zurückgesetzt wird, gibt Core die Anzahl der verworfenen Bytes aus. + +- [Bitcoin Core #32618][] entfernt die Option `include_watchonly` und ihre Varianten sowie das Feld `iswatchonly` aus allen Wallet-RPCs, da [Deskriptor][topic descriptors]-Wallets keine Mischung aus Watch-only- und ausgebbaren Deskriptoren unterstützen. Zuvor konnten Nutzer eine Watch-only-Adresse oder ein Skript in eine Legacy-Wallet importieren. Legacy-Wallets wurden nun entfernt. + +- [Bitcoin Core #31553][] fügt dem [Cluster-Mempool][topic cluster mempool] Projekt eine Behandlung von Block-Reorgs hinzu, indem die Funktion + `TxGraph::Trim()` eingeführt wird. Wenn durch eine Blockchain-Neuordnung (Reorg) bereits bestätigte Transaktionen wieder in den Mempool + gelangen und dadurch die erlaubte Anzahl oder das Gewicht eines Transaktions-Clusters überschritten wird, sortiert die Funktion `Trim()` die + Transaktionen nach Gebühr und Abhängigkeiten. Sie entfernt dann alle Transaktionen (und deren Nachfolger), die das Limit überschreiten. + +- [Core Lightning #7725][] fügt einen leichtgewichtigen JavaScript-Logviewer hinzu, der CLN-Logdateien im Browser lädt und es Nutzern ermöglicht, Nachrichten nach Daemon, Typ, Channel oder Regex zu filtern. Dieses Tool erhöht den Wartungsaufwand des Repos nur minimal und verbessert das Debugging für Entwickler und Knoten-Betreiber. + +- [Eclair #2716][] implementiert ein lokales Peer-Reputationssystem für [HTLC-Endorsements][topic htlc endorsement], das die durch jeden eingehenden Peer verdienten Routing-Gebühren im Vergleich zu den Gebühren verfolgt, die basierend auf Liquidität und [HTLC][topic htlc]-Slots hätten verdient werden sollen. Erfolgreiche Zahlungen führen zu einer perfekten Bewertung, fehlgeschlagene Zahlungen senken sie, und HTLCs, die nach Ablauf der konfigurierten Schwelle noch ausstehen, werden stark bestraft. Beim Weiterleiten gibt der Knoten seine aktuelle Peer-Bewertung im `update_add_htlc` Endorsement-TLV an (siehe Newsletter [#315][news315 htlc]). Betreiber können den Reputationsverfall (`half-life`), die Schwelle für festsitzende Zahlungen (`max-relay-duration`), das Strafgewicht für festsitzende HTLCs (`pending-multiplier`) anpassen oder das System komplett deaktivieren. Dieser PR sammelt primär Daten zur Verbesserung der Forschung zu [Channel Jamming Attacks][topic channel jamming attacks] und implementiert noch keine Strafen. + +- [LDK #3628][] implementiert die Serverlogik für [asynchrone Zahlungen][topic async payments], sodass ein LSP-Knoten [BOLT12][topic offers] statische Rechnungen im Namen eines Empfängers bereitstellen kann, der häufig offline ist. Der LSP-Knoten kann `ServeStaticInvoice`-Nachrichten vom Empfänger annehmen, die bereitgestellten Rechnungen speichern und auf Zahlungsanfragen des Zahlers reagieren, indem er die gespeicherte Rechnung über [Blinded Paths][topic rv routing] zurückgibt. + +- [LDK #3890][] ändert die Bewertung von Routen im Pfadfindungsalgorithmus, indem die Gesamtkosten durch das Kanalbetragslimit (Kosten pro nutzbarem Sat) geteilt werden, anstatt nur die Gesamtkosten zu betrachten. Dies bevorzugt Routen mit höherer Kapazität und reduziert übermäßiges [MPP][topic multipath payments] Sharding, was zu einer höheren Erfolgsquote bei Zahlungen führt. Obwohl die Änderung kleine Kanäle übermäßig benachteiligt, ist dieser Kompromiss besser als das bisherige starke Sharding. + +- [LND #10001][] aktiviert das Quieszenz-Protokoll in der Produktion (siehe Newsletter [#332][news332 quiescence]) und fügt einen neuen Konfigurationswert `--htlcswitch.quiescencetimeout` hinzu, der die maximale Dauer angibt, für die ein Channel quieszent sein kann. Der Wert stellt sicher, dass abhängige Protokolle wie [dynamische Commitments][topic channel commitment upgrades] innerhalb des Zeitlimits abgeschlossen werden. Der Standardwert beträgt 60 Sekunden, das Minimum 30 Sekunden. + +{% include snippets/recap-ad.md when="2025-07-22 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32604,32618,31553,7725,2716,3628,3890,10001" %} +[LND v0.19.2-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.2-beta +[Quellen]: /en/internal/sources/ +[floresta v0.8.0]: https://github.com/vinteumorg/Floresta/releases/tag/v0.8.0 +[rgb blog]: https://rgb.tech/blog/release-v0-12-consensus/ +[frostsnap website]: https://frostsnap.com/ +[electrum 4.6.0]: https://github.com/spesmilo/electrum/releases/tag/4.6.0 +[news315 htlc]: /en/newsletters/2024/08/09/#eclair-2884 +[news332 quiescence]: /en/newsletters/2024/12/06/#lnd-8270 From e85330884833a9ef11ae6c9518a1228e90414dbd Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Tue, 22 Jul 2025 13:43:04 -0500 Subject: [PATCH 164/278] Podcast: add 363 recap --- .../en/newsletters/2025-07-18-newsletter.md | 28 +++++++++---------- .../en/podcast/2025-07-22-newsletter-recap.md | 23 +++++++++++++++ 2 files changed, 37 insertions(+), 14 deletions(-) create mode 100644 _posts/en/podcast/2025-07-22-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-07-18-newsletter.md b/_posts/en/newsletters/2025-07-18-newsletter.md index 07c8f9c0df..6b315ac3be 100644 --- a/_posts/en/newsletters/2025-07-18-newsletter.md +++ b/_posts/en/newsletters/2025-07-18-newsletter.md @@ -24,24 +24,24 @@ wallets and services.* - **Floresta v0.8.0 released:** The [Floresta v0.8.0][floresta v0.8.0] release of this [Utreexo][topic utreexo] node adds support for [version 2 P2P transport (BIP324)][topic v2 p2p transport], [testnet4][topic testnet], - enhanced metrics and monitoring, among other features and bugfixes. + enhanced metrics and monitoring, among other features and bugfixes. {% assign timestamp="0:45" %} - **RGB v0.12 announced:** The RGB v0.12 [blog post][rgb blog] announces the release of RBG's consensus layer for RGB's [client-side validated][topic client-side validation] smart - contracts on Bitcoin testnet and mainnet. + contracts on Bitcoin testnet and mainnet. {% assign timestamp="20:38" %} - **FROST signing device available:** [Frostsnap][frostsnap website] signing devices support k-of-n [threshold signing][topic - threshold signature] using the FROST protocol, with only a single signature on chain. + threshold signature] using the FROST protocol, with only a single signature on chain. {% assign timestamp="25:34" %} - **Gemini adds taproot support:** Gemini Exchange and Gemini Custody add support for sending (withdrawing) to - [taproot][topic taproot] addresses. + [taproot][topic taproot] addresses. {% assign timestamp="29:44" %} - **Electrum 4.6.0 released:** [Electrum 4.6.0][electrum 4.6.0] adds support for [submarine swaps][topic - submarine swaps] using nostr for discoverability. + submarine swaps] using nostr for discoverability. {% assign timestamp="38:14" %} ## Releases and release candidates @@ -51,7 +51,7 @@ release candidates._ - [LND v0.19.2-beta][] is the release of a maintenance version of this popular LN node. It "contains important bug fixes and - performance improvements." + performance improvements." {% assign timestamp="38:51" %} ## Notable code and documentation changes @@ -70,14 +70,14 @@ repo], and [BINANAs][binana repo]._ are prefixed with an asterisk (*) when any source location is suppressed. Console output, logs with an explicit category argument, and `UpdateTip` Initial Block Download (IBD) messages are exempt from rate limits. When the - quota resets, Core prints the number of bytes that were dropped. + quota resets, Core prints the number of bytes that were dropped. {% assign timestamp="39:38" %} - [Bitcoin Core #32618][] removes the `include_watchonly` option and its variants, as well as the `iswatchonly` field from all wallet RPCs because [descriptor][topic descriptors] wallets don’t support mixing watch-only and spendable descriptors. Previously, users could import a watch-only address or script into a legacy spending wallet. However, legacy wallets have now been - removed. + removed. {% assign timestamp="40:55" %} - [Bitcoin Core #31553][] adds block reorg handling to the [cluster mempool][topic cluster mempool] project by introducing the `TxGraph::Trim()` @@ -85,13 +85,13 @@ repo], and [BINANAs][binana repo]._ mempool and the resulting combined cluster exceeds cluster count or weight policy limits, `Trim()` builds a feerate-ordered, dependency‑respecting, rudimentary linearization. If adding a transaction would breach a limit, that - transaction and all its descendants are dropped. + transaction and all its descendants are dropped. {% assign timestamp="43:03" %} - [Core Lightning #7725][] adds a lightweight JavaScript log viewer that loads CLN log files in a browser and allows users to filter messages by daemon, type, channel, or regex. This tool adds minimal repository maintenance overhead while improving the debugging experience for developers and node - runners. + runners. {% assign timestamp="46:53" %} - [Eclair #2716][] implements a local peer-reputation system for [HTLC endorsement][topic htlc endorsement] that tracks the routing fees earned by @@ -105,14 +105,14 @@ repo], and [BINANAs][binana repo]._ weight for stuck HTLCs (`pending-multiplier`), or simply disable the reputation system entirely in the configuration. This PR primarily collects data to improve [channel jamming attack][topic channel jamming attacks] - research and does not yet implement penalties. + research and does not yet implement penalties. {% assign timestamp="47:23" %} - [LDK #3628][] implements the server-side logic for [async payments][topic async payments], allowing an LSP node to provide [BOLT12][topic offers] static invoices on behalf of an often-offline recipient. The LSP node can accept `ServeStaticInvoice` messages from the recipient, store the provided static invoices, and respond to payer invoice requests by searching for and returning - the cached invoice via [blinded paths][topic rv routing]. + the cached invoice via [blinded paths][topic rv routing]. {% assign timestamp="52:19" %} - [LDK #3890][] changes the way it scores routes in its pathfinding algorithm by considering total cost divided by channel amount limit (cost per sat of usable @@ -120,7 +120,7 @@ repo], and [BINANAs][binana repo]._ selection toward higher-capacity routes and reduces excessive [MPP][topic multipath payments] sharding, resulting in a higher payment success rate. Although the change overly penalizes small channels, this tradeoff is - preferable to previous excessive sharding. + preferable to previous excessive sharding. {% assign timestamp="53:22" %} - [LND #10001][] enables the quiescence protocol in production (see Newsletter [#332][news332 quiescence]) and adds a new configuration value @@ -128,7 +128,7 @@ repo], and [BINANAs][binana repo]._ which a channel can be quiescent. The value ensures that dependent protocols, such as [dynamic commitments][topic channel commitment upgrades], finish within the timeout period. The default value is 60 seconds, and the minimum - value is 30 seconds. + value is 30 seconds. {% assign timestamp="54:30" %} {% include snippets/recap-ad.md when="2025-07-22 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-07-22-newsletter-recap.md b/_posts/en/podcast/2025-07-22-newsletter-recap.md new file mode 100644 index 0000000000..7a6ab69bc1 --- /dev/null +++ b/_posts/en/podcast/2025-07-22-newsletter-recap.md @@ -0,0 +1,23 @@ +--- +title: 'Bitcoin Optech Newsletter #363 Recap Podcast' +permalink: /en/podcast/2025/07/22/ +reference: /en/newsletters/2025/07/18/ +name: 2025-07-22-recap +slug: 2025-07-22-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt are joined by Davidson Souza to discuss [Newsletter #363]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-6-22/404359539-44100-2-df272ca6989b2.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From 9283bd4d010539a8ea01475a73f6f2088fe91c67 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Tue, 22 Jul 2025 12:53:57 -0500 Subject: [PATCH 165/278] News363: client service fixup --- _posts/en/newsletters/2025-07-18-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2025-07-18-newsletter.md b/_posts/en/newsletters/2025-07-18-newsletter.md index 6b315ac3be..8341e805b4 100644 --- a/_posts/en/newsletters/2025-07-18-newsletter.md +++ b/_posts/en/newsletters/2025-07-18-newsletter.md @@ -27,7 +27,7 @@ wallets and services.* enhanced metrics and monitoring, among other features and bugfixes. {% assign timestamp="0:45" %} - **RGB v0.12 announced:** - The RGB v0.12 [blog post][rgb blog] announces the release of RBG's consensus + The RGB v0.12 [blog post][rgb blog] announces the release of RGB's consensus layer for RGB's [client-side validated][topic client-side validation] smart contracts on Bitcoin testnet and mainnet. {% assign timestamp="20:38" %} From d890355b50365c331b6429071cf02284e23eff33 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Wed, 23 Jul 2025 10:55:19 -0500 Subject: [PATCH 166/278] Podcast: add 361 transcription --- .../en/podcast/2025-07-08-newsletter-recap.md | 1968 ++++++++++++++++- 1 file changed, 1967 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-07-08-newsletter-recap.md b/_posts/en/podcast/2025-07-08-newsletter-recap.md index 50a89bb6f8..bf21160974 100644 --- a/_posts/en/podcast/2025-07-08-newsletter-recap.md +++ b/_posts/en/podcast/2025-07-08-newsletter-recap.md @@ -19,6 +19,1972 @@ Nick, Tadge Dryja, Steven Roose, and Brandon Black to discuss [Newsletter #361]( ## Transcription -_transcription coming soon_ +**Mike Schmidt**: Quick disclaimer this week, we recorded the podcast in two +different recording sessions. And so, in one session, we had Sanket, Jonas +Nick, and Tadge; and in a separate recording, we had Rearden and Steven Roose. +And so, if you're wondering why certain guests aren't opining on certain items, +it's because we had two different sessions and we edited all together in a +little bit out-of-order way in order to accommodate the order of the newsletter. + +Welcome everyone to Bitcoin Optech Newsletter #361 Recap. Today, we're going to +talk about decoupling onion messages from the LN channel topology, and we have +our monthly segment on Changing consensus, where we have discussions about CTV +(CHECKTEMPLATEVERIFY) and CSFS (CHECKSIGFROMSTACK) with regards to PTLCs (Point +Time Locked Contracts); CTV+CSFS and BitVM; the CTV+CSFS open letter; the +TXSIGHASH proposal. And we have two items on quantum resistance and also a +discussion on vault descriptors. Murch and I are joined this week by a handful +of guests. Sanket? + +**Sanket Kanjalkar**: Hey, hello. + +**Mike Schmidt**: You want to say a few words about yourself? + +**Sanket Kanjalkar**: Yeah, sure. Hi, my name is Sanket, avid bitcoiner. I +used to work with Jonas at Blockstream Research for about three-and-a-half +years, working on mostly scripting side of things along with cryptography. Now +I work at Block. + +**Mike Schmidt**: Jonas? + +**Jonas Nick**: Hey, I work in the Blockstream Research group and I'm mainly +focused on cryptographic problems. + +**Mike Schmidt**: Rearden? + +**Brandon Black**: Hi there. Yeah, I'm Rearden and I try to do Bitcoin +education and self-custody research. It's kind of my thing these days. + +**Mike Schmidt**: Steven? + +**Steven Roose**: Hi, Steven Roose, currently building Ark at Second. + +**Mike Schmidt**: Tadge will be joining us shortly as well. We'll have him +introduce himself when he gets here. + +_Separating onion message relay from HTLC relay_ + +"Separating onion message relay from HTLC relay". Roasbeef posted to Delving +Bitcoin a post titled, "Reimagining Onion Messages as an Overlay Layer". In his +post, he proposes separating the connections and paths that onion messages can +take from the topology of Lightning channels in the LN. So, right now when you +send an onion message, the message is being routed along channels just like a +payment would be routed. And roasbeef sort of outlined some motivation for +wanting to separate those or some downsides for them being bolted together as +they are. He noted some of those downsides include the coupling. He noted, +"Bolting the onion message graph onto the channel graph, we force the onion +message graph to operate a graph of larger diameter than the solution +necessitates. If onion messaging were instead on an overlay layer, a more +compact messaging graph would emerge". So, what he's saying is, maybe you're +routing through five different paths along the way for a payment, but does an +onion message really require five hops? And I think his conclusion is no, but +we'll get into that in a minute. + +He uses the example of BOLT12 offers, where if a single node along the path +doesn't support the protocol, then the onion message can't be transmitted. And +that means that the client needs to fall back to directly connecting to the +recipient to send their request messages, which he notes is bad for privacy as +well as bad for UX in the form of delays. He also points out that currently, +onion messages can reuse identification keys of a channel peer indefinitely, +which doesn't allow for changing those keys, which degrades the privacy of onion +messages over time. And he also points out that channel-related activity can +currently block the processing of onion messages, although in the Delving +thread, I believe that there was some pushback on that point in particular. So, +to solve these issues, roasbeef's plan is to start a new onion message network +separate from any channels, that is built up from the existing gossip network. +And that alternate onion message network can actually run in parallel with the +existing onion message network and could allow for quicker experimentation and +innovation of some of these newer proposed LN features, because you'd +potentially have a tighter group of people who are more interested in keeping +that up to date. And so, they would maybe be 1% the size of the existing LN, +was one of the numbers I saw thrown out. And so, that maybe you can iterate +faster on some of this new tech. + +So, that was the problem as he saw it and the solution as he saw it. And I +think that the main objection, and we outlined this in the newsletter as well, +is that currently, coupling the channel and onion message together means that +onion messages benefit from the DoS resistance that's built into having a +channel and putting your funds at stake, opening the channel, all of that. +Whereas if you just allow any LN node to be messaging any other LN node, you +lose that DoS protection. So, I think that was the main objection that we +noted, and that I also saw on the thread, and discussion seems to be ongoing. + +_CTV+CSFS advantages for PTLCs_ + +"CTV+CSFS advantages for PTLCs". This is actually an item that's a continuation +of a discussion that, Steven, you've started. This was a few weeks ago. It was +a Delving post titled, "CTV+CSFS: Can we reach consensus on a first step towards +covenants?" You posted that to Delving, and we covered that in Newsletter #348 +in its initial carnation. I saw there's a ton of new responses there since. +But in your original post, you outlined benefits to DLCs, Vaults, BitVM, and +somewhat related to this week's item, LN-Symmetry. In the recent discussion on +the thread, Greg Sanders actually pointed out that even if LN-Symmetry isn't +adopted, that having CTV+CSFS available could still accelerate a move towards +PTLCs. He noted that PTLCs are possible today, but with re-bindable signatures, +it actually gets significantly simpler. We could probably recap what PTLCs are, +but also, does anybody want to explain what re-bindable signatures are and how +that's related to PTLCs? + +**Brandon Black**: I'll take the rebindable signatures part there. + +**Mike Schmidt**: Thank goodness! + +**Brandon Black**: So, in Bitcoin right now, all of the ways that we can sign a +transaction using OP_CHECKSIG, OP_CHECKMULTISIG, OP_CHECKSIGADD, all of those +and their variants require that some at least one previous output's txid and +outpoint, or and vout, are signed. And so, that means that that signature is +bound to a specific output from the UTXO set. Now with either APO +(SIGHASH_ANYPREVOUT) sighash mode, or with CSFS and CTV, we can then sign a +transaction in a way where none of the previous outpoints are signed. Now, that +signature can be used with any output that has the matching script, essentially, +the matching required signature. It doesn't have to have a specific output from +the UTXO set. So, now it's re-bindable. You could have two outputs in the UTXO +set, and either one could be spent with that signature. That would be dangerous +in certain cases, but it's also super-advantageous in certain protocols, +especially LN and DLCs, and things like that, where you might need to have a +signature that can be used in different scenarios along the protocol with a +different output as the input to that transaction. + +**Mark Erhardt**: Yeah, so I picked the quoted person's brain this morning to +try and figure out what they meant, and my understanding now is that the problem +with PTLCs would be that now, instead of just one party signing the commitment +transaction of the other party, each time an HTLC (Hash Time Locked Contract) is +added to the commitment transaction, it would have to of course be both sides, +because PTLCs are MuSig signatures and MuSig requires signatures from both +parties. And it would require that these signatures are updated each time, I +think, when the transaction is updated. So, instead of signing each new +commitment transaction once by the party, that Alice signs Bob's and Bob signs +Alice's, so the other parties commitment transaction is presigned, now both +parties would have to sign both commitment transactions on every update per +PTLC. + +With the re-bindable signature, it would become a single re-bindable signature +for both sides for the lifetime of the PTLC. So, you'd sign off on a PTLC once +when it's added and as long as that PTLC is on the transaction, that signature +would be fine, and that would make it a lot simpler to adopt PTLCs. Please +correct me. That's my very uneducated understanding. + +**Brandon Black**: One nuance in there is that it's not just because it's +MuSig2. Even if it's two single-signatures, the same property exists. Because +it doesn't matter that it's a MuSig2 signature or it's a 2 single-signatures, +either way with PTLCs, you need to update the signatures if the underlying +commitment transaction changes, unless you have re-bindable signatures, and then +you don't have to update them. So, it's not specific to MuSig2, it's because +it's a two-party thing with a specific point, or in the case of single-sig, two +separate specific points for the PTLC, because the PTLCs are bound to a point, +not a hash. + +**Mark Erhardt**: Right, but I mean PTLCs only work because it is a point and +therefore a single-sig signature, right, or am I misunderstanding something? +Otherwise, you'd need a taproot branch, like a script tree leaf script, right? + +**Brandon Black**: Yeah, correct. You can do PTLCs with single-sig in a tapleaf +branch. And basically, one signer is a plain signature, one signer is an +adaptor sig, on each side of the commitment tree. So, you still use an adaptor +sig like you would in the MuSig variant, except instead of a two-party adaptor +sig that does the whole thing, it's a regular signature for one party and an +adaptor sig for the other party inside of a scriptpath. So, it can work with or +without MuSig2 and with or without re-bindable signatures. If you have MuSig2 +and re-bindable signatures, it is definitely simpler in two dimensions. + +**Mark Erhardt**: I see. Thank you. + +**Mike Schmidt**: Okay. So, it is possible today, as Greg points out, but as +both of you have illustrated, I think that that would be even higher +interactivity and number of things that we're storing and going back and forth +with. So, these improvements would cut down on that and keep it a simple +protocol. + +**Brandon Black**: The one thing that I found really interesting in reviewing +this this morning is that there's this weird trade-off space in here of +simplicity of the transactions and scripts versus interactivity. So, if you add +MuSig2, that adds a round trip. In most cases, there are ways to mitigate that, +but in general, MuSig2 adds a round trip versus the two single-signatures. But +of course, the two single-signatures have this weird thing with one party +signing a full sig, the other party doing adaptor sig and kind of swapping +those, but it's less interactive. And then, adding re-bindable signatures just +reduces the interactivity. So, we could say that re-bindable signatures are an +unmitigated benefit to PTLCs. MuSig2 is a nuanced trade-off to it. + +**Mark Erhardt**: So, the news item was largely about how tooling was missing +for that sort of PTLC work. My understanding is that building such tooling +would be significantly easier also with the re-bindable signatures, because +you'd have less overhead, or is that wrong? I see some skeptical looks. + +**Brandon Black**: I think the main tooling that is missing is around the +adaptor sigs themselves. And unfortunately, that's needed in either case. I +think it is a little bit simpler because you don't have to have these two +different sets of adaptor signatures. One set of adaptor signatures that are +re-bindable applies to both sides of the commitment transaction. The thing +that's missing is there's not great tooling in, like, libsecp for adaptor +signatures. That would be the big kind of tooling lift. + +**Steven Roose**: Yeah, I wanted to say the same thing. + +**Mike Schmidt**: And, Murch, I think we covered the MuSig module that went into +secp256k1, I think, in the last few weeks, and explicitly noted that that +adaptor signature support was dropped as part of that as well. So, unfortunate +there, and I think AJ pointed out that even the more experimental secp ZKP +project, which has some other goodies in it, doesn't have adaptor signature +support either. So, sad face there. The only other thing that I pulled out +from the discussion was just Greg pointing to an artifact that he had created a +while ago, which was this idea of what LN message changes would be needed to +support PTLCs. And so, he pointed to it just there. I know he did a lot of +work on LN-Symmetry and he's sort of pointing to these artifacts that he's left +along the way, if people are revisiting them in the case you have with PTLCs. + +**Brandon Black**: One thing worth noting in that, just fun, I know we've talked +before on this podcast about LN-Symmetry. So, yeah, we can do PTLCs without +LN-Symmetry, or we can do them with. Because LN-Symmetry doesn't have the two +sides of the commitment transaction chain that we have to sign for, you get +another layer of simplicity in your PTLCs if you have LN-Symmetry, because +you're only signing for the one update transaction, and both parties just have +to sign that one transaction, and you're done with your PTLC versus with the +current LN-Penalty, there's two sides of the channel that both have to get +signed with the PTLC. So, it's kind of neat to see going through Greg's gist +here that he linked, "Oh, if you get re-bindable signatures, it gets this much +simpler. And then if you get re-bindable signatures and LN-Symmetry, it's down +to basically just send the PTLC and we're done". + +_Vault output script descriptor_ + +**Mike Schmidt**: Moving to, "Vault output script descriptor". Sjors posted to +the Delving Bitcoin forum to discuss the idea of a CTV vault output descriptor. +He referenced James O'Beirne's simple-ctv-vault design that uses the CTV opcode +to create a vault implementation to store bitcoins that require multiple +transactions in order to be spent. He noted, "For any vault construction to be +useful in wallets, it needs to either fit in the existing BIP380 output +descriptor paradigm or develop an alternative." Sanket, you replied in the +thread and you also noted you were working on an alternate CTV vault +construction. Maybe, can you help us understand why a vault descriptor would be +a hard thing? + +**Sanket Kanjalkar**: Yeah, for listeners, I guess everyone is primarily aware, +but to recap, of Sjors' first statement, which was, "Why do we even need +descriptors?" We have been having discussions about, "We need CAT, we need +VAULT", but when you actually try and implement one of these things, you slowly +come to realize that, we need standard tooling on top of this to make it work. +And as Sjors also commented in the same thread, it's been six years since +descriptors were started, like we started talking about them, but now they are +sort of in a good place in Bitcoin world. So, if we want to use the newer +primitives, we want wallets to index the points, we want backups for those +things. And descriptors just solve these problems and are nicely integrated in +all of the tooling that we have. So, it's good to have them incorporated in +this language. + +So far, how most descriptors work is you have a logical spending condition, +which is like, "Give me a multisig. I need, if I have three of these keys, I +can spend from them". Or importantly, the most important property that we have +is we can create the output address or output script from a descriptor, and that +allows us to make the same property which either apply for the newer +instructions, like CTV for example, because they rely on transaction structures +like previous output or sequence locktime, they don't necessarily fit in the +same language that we have currently. We have to have some sort of additional +information we supply as a part of when we describe how to look for the outputs. +So, that's I guess the first part. And to that end, Sjors initially commented +on the approach in which we can look up for funds in a descriptor, with +parameters for how we get the CTV transaction exactly. It's stated assumptions +on how we want to look out for sequence locktimes, and how the nesting should +work in one particular construction. + +That, and I think one alternate implementation, which is easier to implement, +can be instead of indexing the CTV funds itself, if we index the incoming +deposit, if we have like a mini-standard withdraw from vaults, you have a +staging area that you withdraw funds from. Cold area goes to staging area, you +can cancel funds from there, and those funds go back up into hot area. But to +simplify construction and implementation, if we add an additional constraint, +which is that funds don't directly go into the cold wallet, but instead go into +this staging area, and the wallet implementation themselves can manage how to do +the CTV, how to put in the exact amounts of CTV outputs, because if you put in +the incorrect amounts, funds may be at risk of theft. So, the alternate design +would be for depositing funds, you also deposit them in the staging area and +have the special wallet instruction having them indexed by looking at previous +outpoint, which is like a standard descriptor, which can be any one of the +descriptors, and that always sends funds to CTV output. So, yeah, any +questions? + +**Mike Schmidt**: Yeah, so it sounds like based on the original James O'Beirne +simple CTV vault design, there was going to be cumbersome tooling around that +sort of a vault implementation. And so, you've come up with an alternate vault +implementation that I don't fully understand the trade-offs, but it sounds like +the tooling around that sort of a vault would be a little bit better, and that +would include something like descriptor capabilities. Do I have that right? + +**Sanket Kanjalkar**: Yeah, the exact trade-off would be easy tooling, but you +cannot deposit directly into the vault. You have to deposit into a vault +wallet, and then that switch additionally comes into the cold area. It's not +the best of designs, but if you want something that works today, then you can +work with it. It's really useful if you are slowly stacking funds, instead of +depositing a large chunk all at once. So, if you want a working thing today +without dealing with all of the mess that integrating CTV, or like CTV inside +the descriptor language concept, you can work with it. + +**Mike Schmidt**: Murch, do you have any questions for Sanket or comments? No, +Jonas or Tadge? So, Sanket, it sounds like there's a couple things here. One +is, you have this additional prototype of vaulting that you've put out. I don't +know if you're looking for feedback on that or just other ideas around tooling +or descriptors for some of these potential coming vaults, if CTV is something +that the community activates. I guess I'm just looking for any sort of calls to +action you might have for listeners. + +**Sanket Kanjalkar**: Yeah, it's a call to action for listeners. And to me, I +think AJ has been quite an advocate at this point, as we have been discussing a +lot about future opcodes. And assuming we have opcodes, then the next step that +comes up is like, how do you build wallets from those? And how do you build +wallets that go beyond a simple prototype, which is like, how do you integrate +those into descriptor language? How do backups work? And you also need to +answer these types of questions if you have, yeah. And the discussion's +implementation details quickly get hairy, so should also figure that out before +you make one strong decision. + +_Continued discussion about CTV+CSFS advantages for BitVM_ + +**Mike Schmidt**: "Continued discussion about CTV+CSFS advantages for BitVM". +So, this item follows up on a different Delving thread that we covered +previously, "How CTV+CSFS improves BitVM bridges", and that was posted by Robin +Linus, and we covered that in Newsletter #354. And actually, in Podcast #354, +we had on Robin, and he covered that original post and the ideas which involved +how CTV could help BitVM by increasing the number of operators without +downsides, I think he said reducing transaction sizes by something like 10x and +also allowing non-interactive pay gains to these bridges. And it so happened +that in that podcast, we actually ended up covering much of this updated +discussion that we're covering this week in the newsletter. Just due to timing, +a bunch of the discussion happened after the newsletter was published and before +we had the podcast. So, Robin actually got us up to date on a lot of this +already, including AJ Towns finding a bug in the original proposed contract; +Jeremy Rubin coming up with a revised construction to work around that; Robin +pointing out another issue with the construction in that you need inputs from +two different transactions. + +But something since that podcast was that Chris Stewart came up with a Python +prototype implementation of the original construction, and also some attempts at +also implementing some of the workaround suggestions that we just discussed. +For all of that, except for the Chris Stewart part, I would refer listeners back +to that Podcast #354, where we had Robin, sort of top of mind, fresh discussion +talking about these things. I'll pause there if anybody has anything to add, +but then I want to loop in Steven real quick. Okay, Steven, your OP_TXHASH +proposal was actually mentioned as a potential alternative to CTV here. I +didn't see you comment in this specific Delving thread, but did you get a chance +to think about that? + +**Steven Roose**: Yeah, I replied to the email that was sent out following the +CTV+CSFS openly-signed letter on the Bitcoin mailing list. There was also some +discussion there on TXHASH and why not going all the way towards TXHASH. I +think it's a question of stopping point, right, like where do we stop? Like, if +we have TXHASH, we can also talk about CAT, we can also talk about a lot of +other things. And I think just many of the things that go beyond CTV+CSFS just +haven't had the review, haven't had the actual compelling use cases worked out +on what this additional functionality actually gives in terms of additional +functionality, and also what are the risks, what are unfavorable results of +enabling this more logic? So, I mean even though I'm obviously the author of +TXHASH and I obviously think it's a very useful and very powerful primitive, I +wouldn't want to make the statement that I think it's anywhere ready to be +included or to be put on the roadmap. It definitely needs a lot of protocol +review, it needs a lot of people thinking about how it would be used and if it's +actually suitable for those use cases. Because in general terms, you can think +about, "Oh, we can do this, we can do that". But is it actually an ergonomic +opcode? Is it actually doing the exact things that we need? + +It's by nature a very opinionated opcode, so it definitely needs many people to +look at, because there's many different ways to implement the specifics. And I +just think that we have very compelling reasons to have something like CTV+CSFS, +while the additional benefits of adding the additional complexity of TXHASH are +not that obvious. So, I think we need to put a stopping point somewhere, and I +think it's just like TXHASH just doesn't make it in there. That's what I also +argued on the mailing list. + +**Brandon Black**: And so, you have two TXHASH fanboys here in the talk. I've +been helping Steven with the BIP for TXHAS as well for quite a while. I think +it's a great eventual. And one of the other things that's really great about +working on TXHASH is that with TXHASH, we can expose all parts of the +transaction to use in script. And then, we can start kind of prototyping +scripts, how would I use this part of the transaction in a script? And then, so +there's two paths we go from there. We might decide that, "Oh, there's these +three bits of the transaction that we keep using when we're implementing test +things with TXHASH". We keep using the amounts or the prevouts, or whatever it +is, and then we can make opcodes for those. Or we find that each time we go to +a new script with TXHASH, we use a different part of the transaction. And then, +the right thing to do is to go to the full TXHASH, because we're finding that +all of those different specifiers is used in different scripts. + +So, the having TXHASH out there as a thing to play with in scripts is super, +super-helpful, even if it actually maybe never comes into Bitcoin Scripting +itself. + +_Open letter about CTV and CSFS_ + +**Mike Schmidt**: "Open letter about CTV and CSFS". So, James O'Beirne posted +to the Bitcoin-Dev mailing list. This was a letter signed by dozens of Bitcoin +developers that quote, "Asks Bitcoin Core contributors to prioritize the review +and integration of CTV and CSFS within the next six months". And there's been a +bunch of replies, as you can imagine, to something like that. But of the +replies to that initial email, we highlighted in the newsletter three categories +of responses. The first set were technical highlights, and there were two +there, although there's some subpoints, but concerns about making CTV available +in legacy script, and also limitations of CTV-based vaults. I'll pause there +for feedback before we get into some of the responses from Bitcoin Core +contributors. What's the concern about having CTV in legacy script? + +**Brandon Black**: I don't know if there's a concern so much as changing legacy +script always has implications. NOPs are a very limited resource. CTV and +legacy script would use up a legacy script NOP. We can't, as Bitcoin protocol +developers, predict the full future of Bitcoin. We're trying to build Bitcoin +to be a 1,000-year technology for money, and those NOPs are kind of a precious +resource. Whereas tapscript OP_SUCCESS opcodes, there's tons of those. We also +have script versions in tapscript, we can make more script versions and reuse +the same OP_SUCCESSes for different things. So, I think there's a, "Is CTV +worth using one of these very scarce upgrade hooks, or is it something that we +should use only in the less scarce upgrade hooks?" I can really make arguments +either way, I don't have personally a strong feeling on this. I do have a +preference essentially to use the code as it is. We've been playing with that +code for a long time, it's been active in test networks for a long time. But I +think valid arguments exist to say that CTV is not worth a NOP in the +post-tapscript world. + +**Mike Schmidt**: Okay, so go ahead, Steven. + +**Steven Roose**: I think it goes beyond spending the NOP. I think there's a +lot of people who are very wary or cautious of changing legacy script behavior, +because it's a very not so well understood part of the consensus engine. +There's a lot of DoS problems that have been solved over the years with going to +segwit and tapscript. So, as a community, we shouldn't really encourage people +to use the legacy scripts because there's all kinds of things that could happen, +and we should be trying to kind of soft deprecate it a little bit. I think it +has very different opcode limits or signature limits, and all that kind of +stuff. So, we should have people use what is the latest, which is tapscript, +which has a lot better DoS protections. And personally, I don't think the +reasons for having it in legacy script are very compelling. The only really +compelling reason or interaction with legacy script is using Script6 to do all +kinds of weird stuff in the BitVM world. I'm not sure if that's the latest +still. But for real, not hacked applications, I don't think the legacy script +usage is meaningfully different than just using tapscript. So, then the +argument is, why would we open up this box of changing legacy script that we +don't really understand and we don't really want people to use anymore? I mean, +I think that's mostly part of the argument made by the opponents. + +One of the main arguments that people use in favor of legacy script is using +bare CTV, which means that you can send directly to a CTV. I'm personally not +convinced it's very useful. The only real use case of that is congestion +control, which is also a very controversial use case. I think every use case +that I've seen that uses CTV uses it combined with some kind of alternative +paths, where you have either just CTV or some kind of alternative path, and that +just doesn't work with bare CTV. So, then you never really use this. So, what +we're building with Ark and I think what people are building with LN-symmetry +and DLCs would always use CTV plus some kind of other alternative path, and then +you just can't use bare CTV. So, I haven't seen a compelling reason to have +bare CTV or CTV. + +**Brandon Black**: That's exactly the question is, are there use cases where +you're going to have a series of transactions where you want exactly one +possible spend path and that spend path is a CTV. And it's a little bit thin. +Congestion control trees are the one thing that's been shown. And then, is that +realistically a thing, that whether it be miners or exchanges or anybody is +going to use? That's a little weak. + +**Mark Erhardt**: In this context, there was the proposal of pay-to-CTV (P2CTV). +Does one of you have an overview of what's that about and wants to explain how +that would also save those 8 bytes that bare CTV would save? + +**Steven Roose**: Yeah, I think P2CTV is just a rework of bare CTV without using +the legacy script context, so then we don't open this box, but we still keep the +functionality. I think the same question is there, like is the use case +compelling for this, because then we would be using another segwit version? I +think it's the same question without the dimension of, should we open the box; +but then only the dimension of, is it actually useful? + +**Brandon Black**: One thing to just throw out there, a lot of the concerns with +legacy script are specifically around the legacy script sighash modes. They +have the quadratic hashing problems, and a lot of the other DoS stuff comes in +specifically because of the sighash modes. And of course, CTV uses segwit-style +hash components to build its hash, so it does not have those same problems. So, +I think the argument that, "Oh, we're opening the box of legacy script that has +these DoS", is a little thin as well, which is why I fall on that. I don't +care, put it in legacy, don't; it doesn't really matter. We're really not +opening those danger boxes in legacy scripts to add this opcode. + +**Mike Schmidt**: The second technical highlight from the newsletter was around +limitations of CTV-based vaults. I think this was Jameson Lopp who pointed out +a few things: one, address reuse being bad, we all know, but specifically in +this vault setup; theft of staged funds; key deletion being not as hard as +people maybe outlined, and Gregory Maxwell noted a simple approach to that; and +also one of the advantages of CTV-based vault being static state, but there's +potentially other ways to achieve that without CTV. We have bullets on each of +these from the newsletter, but I'll open it up for Steven and Rearden to comment +on the validity of those. Any feedback on that? + +**Steven Roose**: I mean, I think I can summarize whatever was written or +whatever has been argued before, is that it's very opinionated, right? So, many +people have the opinion that any meaningful vault construction that's actually +adding real security is not possible with just CTV, and you would need something +else like a vault, or something like CCV (CHECKCONTRACTVERIFY) where you have +the ability to actually convey state from one UTXO to the next, which CTV +doesn't give you. And so, then some people find it not really honest if people +use the vault arguments as a reason to activate CTV, because they say, +"Actually, you cannot really make vaults with CTV". I haven't looked too deeply +into the construction that people have actually used. I think it's mostly +presigned transaction-based vaults, and then just make them less interactive +with CTV. But they have a lot of limitations and a lot of foot guns, but I +don't really know the latest on that. + +**Brandon Black**: I can add a little bit more there. The simple thing is +exactly what's been discussed here, is that CTV, all it does is it gives you the +exact same vault features as a presigned vault. There's not a difference there, +except you don't have to create and delete key material and then save presigned +transactions to get that functionality. So, is that a benefit worth pursuing +for this vaulting use case? I'm not sure it is. I think Jameson said, you +know, they talked about in the thread about we really want something like CCV or +OP_VAULT. But then, I think we can also say some people in the world use +presigned transaction vaults. It seems to be only people that are bespoke +writing their own software to do so that use presigned vaults, it's not a +commercially available product. I think, I forget, someone made it and tried to +make a commercial product out of it. It didn't go anywhere. Would CTV move the +needle and bring maybe more people to using that same vault structure, just +without the creating ephemeral keys and deleting them? I don't know. But it is +an improvement in that status for vaults. It's just not the point where we +could now make this a commercial, recommended practice. + +**Mike Schmidt**: So, the next category of responses that we categorized for the +newsletter were responses from Bitcoin Core contributors. So, the first two +items we talked about were more technical discussion-related. These are a +little bit softer. I summarized the summary quotes here. We had Greg Sanders. +He was disagreeing about that the bar for changes or objections being only +egregious breaks. He disagreed with that bar and thought that there could be +other objections. And he also rejected a time-based ultimatum, but noted +CTV+CSFS are worth considering. + +AJ Towns commented that he thinks the CTV discussion has missed important steps, +including steps he has advised CTV proponents to take, and that the letter is +creating incentive problems, not solving incentive problems. And Antoine +Poinsot said that he sees the effect of the letter as a major setback in making +progress, and recommended someone do the work of addressing technical feedback +from the community and demonstrate use cases. And finally, Sjors was saying +that vaults were the only interesting feature enabled by the soft fork that he +would personally work on, and that he doesn't oppose the soft fork and hasn't +seen an argument that it is harmful. + +So, well, I don't know if there are other Bitcoin Core contributor responses, +but those are the ones that we highlighted this week in the newsletter. Maybe +we can pause there. Steven or Rearden or Murch, do you guys have comments on +that feedback? + +**Steven Roose**: Well, Murch, you want to go? Yeah, I wanted to say, I felt +that there was more drama created by that letter than should have been created +or that many of the writers intended to create. There was a lot of talk about +threats or just intentions that were, for some reason, for some people, +interpreted in the letter that I think for many of the signers were not there. +I know for a fact that earlier versions of the letter included way more hard +wording about an actual ultimatum or an actual, yeah, an ultimatum, and that +those versions of the letter were NACKED by several of the signers, and then a +softer version was created. I didn't personally feel like there was an +ultimatum, I didn't personally feel like it was an attack. It was more like, +"Hey, we want people to look at this". + +I think a bulk of the opinion or response or argumentation from Core against the +push of the letter is that several Core contributors have in the past +participated in the conversations around, and have highlighted some part of the +process that they feel is lacking. And I think most of their critique is that +many of the letter signers are not actually trying to address the things that +Core contributors would want to see addressed, and they're just signing a letter +and not really doing the work. I think both sides have had valid arguments. I +don't think letter signers had bad intent or wanted to put ultimatum. It's +possible that some of them might, but I think at least myself and the people +that I interact with that I know also signed the letter didn't have those +intentions. I mean, I consider it a little bit of an unfortunate turn of +events, but yeah, that's my take. + +**Mike Schmidt**: Rearden, did you have a comment? Rearden, you're a signer as +well, yes? + +**Brandon Black**: Yeah, I'm a signer as well. I responded on the mailing list +with one of my takes, which is essentially, there's a few dimensions to this +that are going on at the same time. So, I think that writing a letter like +this, and I think also the things that I've done, I've stirred the pot a bit at +times on X and elsewhere about consensus changes for Bitcoin. And I think that +improvements to a complex, globally-distributed network with high software risks +and lots of money resting on it, that's maintained by a small group of dedicated +contributors, there's a lot of things that have to happen. And one of the +things relates to essentially the social energy around something. And so, a +letter like this is partially about saying, "Hey, here's some social energy +around this, see the energy". And that then is meant to encourage a response to +the energy that's out there. + +But then, as Steven pointed out, that energy can be interpreted in a way that +looks more like a threat than a positive energy. And then, there's a lot of +dimensions to this, and there's many ways to look at it. And we are living in a +global world of many. There's not one Bitcoin community, I guess, is what I'm +trying to say here. There's a bunch of different Bitcoin communities that are +having literally different experiences of the world, of this letter, of +everything going on. And so, that's the world we're living in. And the other +thing I want to say, just one last comment here, is the letter was, as Steven +said, deliberately rephrased to not include any kind of an ultimatum. It was +trying to say, "Look, we think that one of the important tasks that Core should +be doing is reviewing consensus changes that are active, and essentially, +there's not some strict process". So, Anthony likes to say they haven't done +the process that I suggested. Well, not everyone wants to go through your +Inquisition process. I love that you built Inquisition, that's a really cool +thing, but there isn't a written-down process for how to get changes into +Bitcoin. So, maybe people want to do changes in a different way. + +Sorry, I got off track for what I wanted to say. The short thing I wanted to +say is that there's not an ultimatum in the letter. And I think that's an +acknowledgement that if Core does not address the potential for needed consensus +changes, it will be necessarily the case that there will be an alternative +software implementation that does address the need for consensus changes. +That's not a threat. We've seen that in other open-source projects over the +decades. The Xorg fork comes to mind as a time when that has happened. If a +project stops responding to the needs of that project, the project forks. It +will happen. + +**Mark Erhardt**: Let me jump in here briefly. So, I would like to point out +that in the letter it very specifically says, "We respectfully ask Bitcoin Core +contributors to prioritize the review and integration of CTV … within the next +six months". That is a very explicit request for a timeline and an action, +which I feel, just to the integration into the codebase, is a request to do +something within the timeframe. Just responding to some looks here. + +**Brandon Black**: I don't read the letter that way. + +**Mark Erhardt**: It literally has that sentence in there, "Do this in the next +six months"! + +**Brandon Black**: "Prioritize". + +**Steven Roose**: "We would like you to prioritize doing this in the next six +months". + +**Brandon Black**: Right, not 'do' it in the next six months, 'prioritize' it in +the next six months. + +**Mark Erhardt**: Well, as we can see, there is already some disagreement on how +to read that sentence! Anyway, this is the sentence that seems to surface this +controversy. The other thing that I wanted to point out here is I feel that +obviously, the work on introspection opcodes and the integration thereof into +the Bitcoin Core codebase is something that only appeals to a subset of the +Bitcoin Core contributors. And I believe that many of these contributors have +been around to talk about many of these proposals. I'm thinking exactly of the +people that have been responding, but also others like Ava Chow is on the record +of being happy to help people work on a PR to propose this sort of work into +Bitcoin Core. And I think there's not really an active pushback on working on +these things, but rather that it is competing for attention with other work +people are already doing. And from my perspective, as well as others that have +stated here, I think there is also an onus on the proponents of this letter. + +There's 60 signatories of this letter, and a subset of these are people that +have worked on the Bitcoin Core codebase before, that very much would be capable +of reviewing and demonstrating use cases of CTV that have not put in the time or +effort here. This is true for many people to a lesser degree. Many of the +signatories would perfectly be capable of writing up a blogpost how CTV would +change their product or their project, or something. I know there's a lot of +discussions on Twitter or forums or chat groups, but I don't see most of these +signatories putting in any effort beyond signing this letter, where I would say, +"Oh, I see that you're putting your own effort for the effort that you're +demanding other people take out of their priorities". + +**Brandon Black**: So, I'm curious. I mean, I'm a signatory and I've been going +to Bitcoin conferences speaking, demonstrating use cases in talks for the last +three years. + +**Mark Erhardt**: I'm not talking about you, definitely not. + +**Brandon Black**: But what would it look like if people were doing this, when +many of the signatories are doing this, myself included? + +**Mark Erhardt**: Well, I think it's a very small count of the signatories that +are doing this. So, basically, what I'm saying is you were talking about social +energy earlier and we've had a few soft forks in the many past years, but only +very few. And there's sort of a sense of the energy around a proposal. Sort of +people are excited about it because something immediately generates a lot of +excitement, and people are excited because other people are excited. And just, +there are some people that are excited, but not excited to the degree where they +actually drop other stuff and work on 'really this needs to happen' sort of +excited. So, my argument is people are not that excited about CTV because +people are not that excited about CTV, which is weird, but that's sort of how it +often feels to me. So, I'm in the camp that I haven't seen any strong arguments +against CTV, especially CTV+CSFS has had growing support in the last few months, +I've seen. I think that the debate has been more productive lately, maybe also +instigated by this letter, even though many people were complaining, I think +mostly because all sides have good arguments in this conversation, I think. And +just because there's so many people talking for one side here, I want to give a +broader picture here, right? + +But I feel like this swelling excitement that begets more excitement threshold +just isn't present, and I think people could help grow that by being more +invested in their support for CTV, like actually going out there and saying, +"Look, I spent a couple of afternoons writing up in detail how this would change +my product, my project. This is exciting, this is how it actually would make +stuff better", present company excluded, because I know that you two have been +very involved in this discussion. So, please don't feel that I'm talking about +you, but I'm very much talking about, I think by count, the majority of the +signatories of that letter. + +**Brandon Black**: I think this is such a great topic. I want to respond to one +part of what you were saying, which is the energy there was for previous soft +forks. Christian Decker made an amazing point when I met him for the first time +last year in Austin, and I just thought it was so important. And it's something +that we overlook about the taproot soft fork process, which is that a lot of +what people were excited about with taproot didn't actually exist. And a lot of +it, of a subset of that, wasn't even possible with the final choice of things +included in taproot. So, there was excitement about taproot, partially because +people believed things that were not true about it. And one of the things that +I think the CTV+CSFS proponents have done a very, very careful job with is not +letting that happen with this, not letting people get excited about something +that it won't actually offer, as you see in this vault conversation. + +So, I think that that's part of why we don't see that groundswell from the +broader kind of less technical users is because unlike with taproot, those users +aren't getting excited about things that can't actually be happening. We could +be out there saying, "Vaults are going to be amazing with CTV". That would be a +lie, and we had that kind of thing with taproot. So, I think it's a difficult +thing. + +**Mark Erhardt**: I think that's a fair point. I think you're especially +referring to cross input signature aggregation in this context, and MuSig being +of course still in the works as taproot was already being deployed. But I think +that also, yes, you are correct that people have not been talking about vaults +as much in the context of CTV, but vaults, for a very long time, was the key +selling point for CTV. So, in a way, yes, but in the past, that was exactly the +case. + +**Brandon Black**: Anyway, so I guess the point there is just that it's +super-important, I think, for Bitcoin's future that we not do what happened with +taproot, we don't let that happen. I think people like Steven, myself, and a +lot of the other CTV advocates have been doing something that is exactly what +Christian would recommend, which is not letting that vault, "Oh, vaults are +going to be amazing", not letting that be the driving thing that gets CTV in, +because that would be essentially an accidental technical lie to the community +again. So, I'm glad of where things are. As you said, there is growing support +right now. I also think there's this difficult thing that goes on, where a lot +of work has been done that shows great use cases for CTV. And people say, "But +I haven't seen it", because it's on this platform and not that platform; it was +in a talk, not a blogpost. I don't know what to do about that. As I said, we +have a bunch of different Bitcoin communities and we live each in our own little +Bitcoin community. + +**Mike Schmidt**: Well, I mean that's an interesting point, that last point. + +**Mark Erhardt**: I think, explain it like I'm 5 in Bitcoin Magazine that really +shares excitement of why we absolutely need to have CTV. Then you've managed to +actually raise the excitement to the surface level of the Bitcoin community, the +broader superset of Bitcoin. + +**Steven Roose**: I wanted to touch on some other dimension other than showing +excitement, showing use cases. I think one other dimension that the letter kind +of implied for myself, and I don't know to what extent for other signers as +well, is that there's this argument and this notion that Bitcoin is a protocol, +Bitcoin is not an implementation. Bitcoin Core is not Bitcoin, right, it's an +implementation of Bitcoin. And the excitement-building and protocol-building +and proposal-building should happen first on the protocol level, right? It +should happen in the broader Bitcoin technical community, everyone building +applications, building libraries, building tooling, building wallets, and stuff +like that. And only when there's clear consensus on, "This is what we want", it +should move into implementations, and Bitcoin Core is just one of the +implementations. But personally, I mean I feel there's only one real +implementation. People talk about Knots, especially in the recent OP_RETURN +drama, but Bitcoin Core is basically the one implementation that Bitcoin has. + +I think one of the messages that the letter conveyed is like, "Hey, we know that +there's broader Bitcoin protocol, Bitcoin, but we want you people, Core +contributors, to be included in this conversation", right? Because many people +feel like, okay, the application-developer people, people building second +layers, they are excited about this, they want this. I mean, they have for +themselves built a convincing case that this is good. But I think many people +have this feeling like, okay, Core has been maybe purposefully, maybe not, +trying to not participate too much in this conversation. Some of the +contributors have been, but I think many of them have just steered away from +participating in consensus in general. And I think one of the messages in the +letter was like, "Hey, everyone, we want Core to drive this. We don't want to +do an alternative client. We want Core to be the primary driver, not Core, the +team, but Core implementation, of future consensus changes in general", right? +We don't want to do alternative client shenanigans, UASFs, and all that, without +having Core behind those decisions. + +I think, I mean in my opinion, that's a positive thing. I think being all +behind the same implementation is good. Otherwise, it would become a lot of +fighting and potential fork drama, and all that. And yeah, I thought that was +one of the positive aspects in this message. It's like, "Hey, Core, we want to +include you in this conversation, we want your feedback. We want to know from +you what needs to be done for you as a team, or as an implementation, to help +drive the next soft fork". + +**Mike Schmidt**: Murch, I see your hand up. + +**Mark Erhardt**: Yeah, I was still pondering how to phrase this. I think this +leaves a little bit of a taste of, yes, it would be great for Core to comment +more on this, but one of the main critiques that came out of Core contributors' +responses was, "Well, we've been commenting on this for years and you're not +addressing our feedback". So, I think there's sort of this standoff here, where +the application developers are saying, "We would like Core to have a bigger +share in this", but they're not saying exactly what they expect out of Core. +And it almost sounds like you're asking for a Core contributor to stand up and +start championing it, which is weird, because why would you ask someone else to +do the work for you if you can't convince yourself to invest the time to do it? +Whereas, on the other hand, Core feels like we've been addressing this, we've +been commenting on this, and our feedback is not being picked up. + +So, clearly there's not really clear understanding from either side of what the +other side is looking for. So, I think there is several signatories on that +letter of people that have familiarity with the Bitcoin Core codebase to the +degree that they at least would be able to, say, take up Ava's offer to get the +technical expertise on how to work on the PR, but to work on the PR themselves +with the support and review of Bitcoin Core contributors. I just don't see +someone that is maybe interested to review it, to stand up and champion it for +the CTV proponents. So, I think that that's sort of what's missing, someone +from the signatories that actually wants to be the prime author of the PR. +Whereas, yeah, I think it came across. + +**Brandon Black**: I'm confused. James has open PRs for both CTV and CSFS +against the Core repository. So, what do you mean someone to do it? James is +doing it, it's there, the PR's open for review. + +**Mark Erhardt**: I don't want to get too much into the consistency of these +sorts of proposals, but it's sort of really ebb and flow. Like, yes, there's a +lot of work for a few weeks and then some proposals are opened and then review +feedback sits, or they start doing other stuff again. I think that just someone +needs to consistently work on it if they want to see it done, and I think it's +unlikely for someone that is not a direct proponent to pick up that mantle. +That's what I'm saying. + +**Brandon Black**: Interesting, yeah. I mean, I'm one of the people who's +opened these PRs and gotten feedback. So, I can speak for myself as a signer of +the letter and someone who's done that. The feedback that I got was, I think +there was one piece of feedback that I did not address that was about the code +itself, and the rest was not about the code itself, but about, "You should have +other applications already done". Anthony Towns, of course, saying, "You should +have this in Inquisition first". I didn't get feedback on the code, I didn't +get feedback on PR, I got feedback on, "There should be other applications", or, +"This should go in Inquisition first". So, there's this very strange thing that +happens, "Oh, people are responding to the feedback, but the feedback isn't +actually about the PR I opened". So, that's, I think, one of the things that is +reflected in why this letter came into existence, is that kind of loop that +people get stuck in. + +Then the other thing worth mentioning, and this is why I called out that the +word was 'prioritize' in the letter, and you had a different reading than me, +which helps explain a lot of the drama around it. So, that's good, thinking +about how English works. It's kind of a terrible language. But that, to me, +what I would love to see personally, as a signer of the letter, is that on the +list of Core's priorities, somewhere in that top ten priorities list, should be, +"Consensus improvements to Bitcoin". And right now, "Consensus improvements to +Bitcoin", is not on Core's priority list at all. That's what I meant when I +signed a letter saying, "We want Core to prioritize this in the next six +months". Consensus changes should be one of the top priorities of Bitcoin +Core's overall project priority list, and it's not even on there. + +**Mike Schmidt**: A couple of things that I wanted to highlight at the high +level here, and it touches on some things that Murch said and Rearden said, +including the prioritization list or not. Obviously, that's really +individual-based, but the communication between what is now sort of two groups +that used to be one group, you would expect things like this. I've sort of +joked to Murch over these last few years when we do these shows about, "Hey, +every other week there's another covenants proposal". We would sort of joke +about it. But behind that is like, how is Core supposed to prioritize that when +some of the authors of these proposals don't even know what the other proposals +are? And I think one thing that comes out of this letter, to me, clarifies +that, "Oh, okay, this appears to be, the group of people who are most interested +in putting most time on protocol work, specifically around script, sort of agree +now". Like, the thing that we were sort of joking about, that it would be great +if the protocol people agreed between themselves before anybody did anything, it +does seem with Rearden, who I believe said OP_CAT is getting activated, and +Steven, who has a competing TXHASH proposal, are saying, "CTV+CSFS". + +So, it seems like what's come out of the protocol sphere is some consensus in +that group, which I think is an interesting question to have answered. And I +think that's what the letter serves, at least in my interpretation. And then, I +think that the second thing is, given now that there's these two groups, with +some overlap of course, what is the way that one group should communicate with +the other group? And that is both ways, but I think the bigger concern is the +protocol folks communicating with Core, like, what are we supposed to say and +when? And obviously, this letter maybe had pieces that were useful and not +according to that communication, but it's entirely predictable that this sort of +thing would happen, that there'd be a little bit of friction in the +communication, when it's not sure what should be said or when, because these +groups used to be one group and so the communication was maybe a little bit +tighter. And so, just two things that I've seen high level on that. + +**Mark Erhardt**: Yeah, I was going to ask, Steven, you seem to want to chime +in, but okay. I have one more maybe instigating question. It feels a little +bit that some of the signers don't actually want CTV. It's just sort of maybe +the least common denominator, "Maybe that's something we could get now, so +better than nothing". How would you say is the dynamic here? Is CTV+CSFS sort +of what people want, or is it just at least better than nothing? What's the +dynamic? + +**Steven Roose**: I think definitely the direction of CTV+CSFS is what people +want. I mean, that's at least a feeling I have, whether it's like, there's +implementation details, obviously, should we do tapscript only; should we do +bare; should we do like whatever; those kinds of things? But I think what the +letter conveyed is just like Mike said, there used to be a lot of wildly +different proposals, like CCV, TXHASH, vaults, all that kind of stuff. And what +this letter conveys is, okay, whatever else might be interesting in the long +term, what we think should be first, because it gives significant benefit for +the amount of work that it would require, is to do this first, something that is +related to templating and signing messages, right, something like that in the +broad sense. Because the ideas are very old, like CSFS has been in Liquid for a +long time, CTV has been around for a long time, also the idea, so like this is +mature enough, it's not risky and the benefits that it gives are significant +enough. And of course, obviously people will have ideas that, "Okay, we should +also do this, we should also do this", but maybe not now, because the time is +not right and we don't have enough use cases built up for those additional +things. At least, that's the position I'm in and I believe many people are. + +**Mark Erhardt**: Okay, slight curve ball. TXHASH, we've talked a little bit +about already as a more general, broader take of CTV, I think. And we've also +touched on CCV five times in the past. So, I've recently merged CCV to the BIPs +repository. I think that CCV has been making deliberate but good progress, and +is doing a good job of sort of explaining exactly what problem it is solving. +And so, for example, in the context of vaults earlier, people said that CCV +would allow to transport state from one UTXO to another, different from CTV. +So, I just wanted to pick both of your brains for if you could have CCV next +week or CTV+CSFS, or maybe CCV+CSFS, to make it fair, what would you think about +that, compared to CTV+CSFS? + +**Brandon Black**: I'm a huge supporter of CCV. I've been pushing whenever I +see him, Salvatore, to finish kind of the -- he's great. He really was focused +on the Merklize All The Things (MATT) broader framework for Bitcoin contracting. +And I was like, "Come on, finish the CCV-based piece of that!" Anyway, so I'm a +huge fan. The thing that I will say is that CTV+CSFS have a lot less potential +for controversy around them than CCV. And one of the things that I +demonstrated, just I did a while ago, OP_VAULT quines, is that any proposal that +has the ability to transport state, as Steven said, like CCV does, opens up a +new category of potential for MEV, or centralizing MEV, that is not present in +something like CTV+CSFS. So, my opinion, and the reason I'm a signer on the +letter, is that CTV+CSFS are about the most we can do without doing a huge +amount of additional analysis on the risks of additional contract types. + +That said, Jeremy Rubin would disagree with me, and so I want to represent his +position here as well, because I think it's important, as the author of CTV. +And he would say that because CTV+CSFS can let you unroll a contract, especially +with taproot, with arbitrary numbers of branches, and as deeply as you would +like, you can have millions of steps, there is less difference than people think +between CTV, CSFS, and CTV, CSFS, CCV. So, there's that position as well. I do +think the difference is material, and I think there's a lot of analysis that +needs to be done before we do something like CCV, that doesn't need to be done +for CTV+CSFS, and that's why I really support CTV+CSFS as a step right now. It +improves a whole bunch of things, from PTLCs, DLCs, BitVMs, whatever we're +working on. It's hard to find a protocol that CTV+CSFS doesn't offer some +improvement to. And then, I think we should keep working towards CCV, doing +more analysis. That seems similar to TXHASH, something that we want to kind of +go deeper on before we would act. + +**Steven Roose**: I'd like to say two things, maybe three. First, the question +was, "How does CTV+CSFS compare with only CCV and CSFS?" I think, and please +correct me if I'm wrong, I think CCV itself doesn't really give any +introspection other than the contracts that is the actual state that it's trying +to convey. So, you cannot fix other things, like outputs or inputs, and stuff +like that, that something like CTV gives you. So, it's not really replaceable. +So, CCV makes sense on top of the other two, not really as a replacement of CTV. + +The second thing I want to say is that CTV does two things. The main thing it +does is it moves the state from one UTXO to the next using this contract hash +and the tweak using taproot, and that's certainly useful, and you can do a lot +of things with that, even though it's only 32 bytes of state. You can build +trees and actually, it's very powerful to just move 32 bytes of state from one +place to the next. But in order to make this ergonomic, to build stuff like +vaults or to build contracts, where not just state but also money, because it's +Bitcoin, moves around, is you also need to somehow look at the amounts of the +different inputs and outputs of a transaction. So, CCV also has some semantics +around that, and I think it's a little bit opinionated in the way of how should +the amounts be handled. + +There's been some feedback on the initial approach that Salvatore took, because +the semantics basically break out of the single input context, and then it +becomes a little bit of a technical discussion. But usually, inputs are +verified as like a script that is on the output, and then the input provides +witnesses to the script, and then you do some validation. And usually, the +context is only the input itself. But to make meaningful vaults, where you can +use multiple inputs and then create multiple outputs, you need to look outside +of your input, like, what are other inputs in this transaction doing? And +that's something we don't really do a lot, other than sighashes today. And so, +the way that Salvatore did this was a little bit controversial, or at least +there was some feedback on. Maybe we can do this in a cleaner way, that we +don't have to do this cross-transaction context execution. And I'm not saying +the way he did it was wrong, I'm not saying the critique is justified, but I +think it's just more opinionated still, and there's some review that can be done +that just isn't the case with the concepts of CTV+CSFS, that are more +well-defined already. And we're like, this is conceptually the way to do it +without that much opinion or bike shedding. Yeah. + +Oh, and then, yeah, I think I missed the third thing that I wanted to say. I +think it was included in the second! + +**Mike Schmidt**: Well, the third section of things that we highlighted in this +item were signers and clarifying their intentions. But Steven and Rearden, +we've had you firsthand to clarify yours. We also highlighted James and +Poelstra and Harsha's comments, but given we've sort of had a good discussion on +this item, is there anything else that you all would add, based on what they've +said, or anything else that we should say before we close out this item? + +**Brandon Black**: I'm so glad we talked about this topic. It's +super-important. Thank you guys. + +_OP_CAT enables Winternitz signatures_ + +**Mike Schmidt**: Next item, "OP_CAT enables Winternitz signatures". User, +Conduition, posted to the Bitcoin-Dev mailing list about a prototype +implementation that he created using OP_CAT to allow Winternitz +quantum-resistant signatures. Jonas, you've posted about some of your work on +Winternitz one-time signatures, or WOTS, I guess it's called. I think you were +doing stuff with great script restoration (GSR) in the past. AJ Towns had +something that he prototyped in Bullish for Winternitz. Is Winternitz some sort +of quantum Schelling point at this point? + +**Jonas Nick**: Yes, I think for context, the overall question is how do we make +Bitcoin spends post-quantum secure? And one way to do that would be to have a +post-quantum signature verification in script. And as far as we know with +today's Bitcoin script, that's not possible. So, one possible approach would be +to introduce a new opcode, similar to CSV (CHECKSIGVERIFY) that just verifies a +post-quantum signature. And another approach is to implement a post-quantum +signature verification algorithm within Bitcoin Script under the assumption that +some additional opcode has been added to Bitcoin Script. And it has been shown +that you can actually implement such a verification scheme if just the OP_CAT +opcode was introduced to Bitcoin script. And now, the more specific research +question is, how large would a Bitcoin Script, a witness be if you want to +implement a post-quantum verification on in Bitcoin Script. And so far, there +was Jeremy Rubin who popularized the idea of implementing so-called Lamport +signatures in Bitcoin Script with OP_CAT. And now, Conduition improved on that +by implementing so-called Winternitz signatures in Bitcoin Script. And his +witness is about 8,000 bytes and Jeremy Rubin's was about 10,500 bytes. + +My sort of implementation of this was not based on a CAT-enabled Bitcoin Script, +but rather on the GSR. And interestingly, that witness was much, much larger. +It was about 24,000 bytes, so more than double the size of Jeremy Rubin's +approach. And the reason is that I implemented a variant of Winternitz, which +has some different cryptographic assumptions, but I believe those assumptions +aren't really necessary for Bitcoin, at least right now. + +**Mike Schmidt**: Is that the collision resistance? + +**Jonas Nick**: Right, so let's maybe give a little bit more context then. When +you have a signature scheme, you can base it on various cryptographic +assumptions, and the hash-based signature schemes, they can be based on, for +example, collision resistance, like the original Winternitz proposal, or, for +example, a stronger assumption, which is called preimage resistance. And what +you want is ideally to not rely on those weaker assumptions, right, you want to +rely on stronger assumptions. + +**Brandon Black**: Sorry, Jonas, just to be clear, the pr-image resistance is a +weaker assumption, right? + +**Jonas Nick**: Oh, right, I should say, yeah. + +**Brandon Black**: It's like weaker and stronger are sort of backwards in some +sense. + +**Jonas Nick**: Right. So, yeah, you want to base your cryptographic security +on weaker assumptions. And so, Conduition's Winternitz implementation is based +on the stronger assumption, collision resistance, whereas my implementation was +based on the weaker assumption, preimage resistance. But, if you look at +Bitcoin, we already very much rely on collision resistance of SHA256. So, for +example, in the transaction merkle tree or in the blockchain itself, so if that +were broken, then we have chain splits and worse problems than just signature +verification. So, I think this approach of basing it solely on collision +resistance, I guess there are also some variants of collision resistance that +might be worth looking into, but it seems like it's definitely a fine approach. + +**Mike Schmidt**: You said that your implementation used GSR, but did you also +with it, because that also turns back on CAT, right, did you use CAT within +that? + +**Jonas Nick**: Yes. It uses CAT and it uses a couple of others. So, most +importantly probably, it uses OP_XOR, it's not available in regular script, and +which simplifies things in my implementation. + +**Mike Schmidt**: Tadge or Murch, any questions for Jonas? + +**Tadge Dryja**: No, I think it sort of makes sense. And yeah, I agree that if +you're really saying, "Okay, we only are going to base on preimage resistance", +there's a lot of changes. I don't even know how you'd change Bitcoin to work +that way. + +**Jonas Nick**: I think this approach, or at least Conduition showed to me, at +least, that this approach of doing post-quantum signature verification within +script is not too far-fetched, because the witness size is still only 8 kB. I +would have expected it to be larger actually, also given my own experiments. +So, I think this is really interesting and so continuing on that work, the +question is, how optimal can we get? There was a suggestion also from AJ Towns, +who I think mentioned some 10% improvement, or so. + +**Mike Schmidt**: Now, I don't want to put you on the spot, Jonas, but if you +know, with BIP360, I think there's a variety of quantum signature schemes +proposed as part of that bundle. How big are those, if you know off the top of +your head, or approximately how big? + +**Jonas Nick**: So, first of all, I think BIP360 was changed significantly in +the last week. So, I don't think those signature schemes are even part of +BIP360 anymore. But anyway, so when talking about post-quantum signature +schemes, there's sort of different roles and different assumptions that these +are based. And Winternitz Lamport signatures, they're also so-called hash-based +signature schemes and they are known to be large. But the advantage of that is +that they are only based on assumptions that we already use in Bitcoin, kind of, +because we already rely on collision resistance of SHA256, as we said, so they +wouldn't add any new assumptions. But there are other cryptographic assumptions +that you would potentially be able to introduce to Bitcoin which result in much +smaller signatures. So, depending on the assumption, it's between maybe 200 +bytes and 2,000 for the other class of signature schemes. + +**Mike Schmidt**: Okay, yeah. + +**Jonas Nick**: And just for comparison, the schnorr signature is 64 bytes, so +it's still the smallest. + +**Mike Schmidt**: Great. Jonas, I know sort of you're representing Conduition's +work here, but maybe in the bigger picture, is there a call to action for folks +who might be in the audience on this sort of topic? It seems like maybe only a +few people understand this sort of thing, but I'll give you an opportunity +either way. + +**Jonas Nick**: Well, yeah, as I said, how far can we go? How small can the +script be? Can we reduce it to, I don't know, 4,000? I don't know. It might +be an interesting question. Perhaps not, but I think at least we can probably +reduce it by a little bit. I think Conduition, he said that he's not a script +wizard, which I don't really believe him, otherwise he wouldn't have written his +script in the first place. + +**Mike Schmidt**: All right, Jonas, thanks for joining us. You're welcome to +hang on as we talk about the commit/reveal scheme from Tadge here. Otherwise, +if you need to drop... + +**Mark Erhardt**: Maybe just as a short insertion, I was pulling up BIP360 in +the background here and it was recently rewritten by Ethan Heilman, or not +rewritten, heavily edited I should say. I think that the P2QRH +(pay-to-quantum-resistant-hash) output type -- this is a very brief +investigation -- but it says 135 vbytes for the witness of the proposed P2QRH +input. So, that would be not that much bigger than P2TR. + +**Jonas Nick**: If I understand correctly, the idea of the updated P2QRH is +essentially, put the taproot merkle tree in the output directly. So, what is +missing from there is then an opcode or something, or OP_CAT, that actually does +the post-quantum signature verification, right? + +**Tadge Dryja**: Yeah, I think that's sort of the overhead. And then, the +signature size is in addition to that 100-something vbytes. + +_Commit/reveal function for post-quantum recovery_ + +**Mike Schmidt**: Next item from the newsletter, "Commit/reveal function for +post-quantum recovery". Taj, you posted to the Bitcoin-Dev mailing list an +email about a post-quantum scheme for spending bitcoins, even from +quantum-vulnerable addresses, using a commit/reveal scheme. I'll let you lay +the land however you want, but I think we've talked about quantum signatures and +things like that, so folks may not be familiar with what a commit/reveal scheme +is more generally, but feel free to take this wherever you'd like. + +**Tadge Dryja**: Sure, it's maybe counterintuitive, like on the one hand, I +think it's a cool idea. It's also not really a good idea in that it's not like, +"Hey, this is great. This is how Bitcoin should work". It's more of a, "This +is a way we can survive", if a quantum computer shows up next month and we don't +really know what kind of signature scheme and there's tons of coins that are +just sort of out there. This could work and it and it saves Bitcoin from dying +and it is usable; it's not great, though, there's a whole bunch of downsides. +But the idea is you can sort of keep using Bitcoin without any post-quantum +signature scheme with just using this sort of commit/reveal mechanism. And +basically, that commit/reveal mechanism just uses OP_RETURN and hash functions. +And I guess, I think you're looking at the collision resistance of it. I +actually think it might just be preimage resistance. + +But yeah, basically what the dumbed-down version that doesn't really work well, +although does sort of work, is imagine if before you wanted to create a +transaction in Bitcoin, you first had to post an OP_RETURN of its txid. And +right now, you don't, obviously. You can just create a transaction, have the +input signed, have new outputs, throw it into the mempool, send it to people, +it'll eventually get to a miner, and it gets mined and it works great. But you +could imagine a soft fork where all the current rules are still the same, but +you say, "No, anytime I see a transaction in the mempool or anytime I see a +transaction in a block, I first look up in a table of OP_RETURNs I've already +seen. So, every OP_RETURN I see, I sort of add this to a map or a key value +store". And I say, "Okay, now if I see a new transaction, I first look it up in +this map. And if the txid is already there, great, valid. If the txid is not +there, that's invalid. I don't accept that transaction". And that gives you +the idea. So, the actual mechanism is a bit more complex. There's sort of +three values instead of just the one txid. But the txid gives a good intuition +of how it would work. + +The part that's counterintuitive is your public key becomes your secret. So, +this doesn't work if you've reused addresses, right? If you've used an address +multiple times, everyone knows what the public key is. And also, it works with +taproot, but it gets a lot more complex. But if you just think of like P2PKH or +P2WPKH, you generate a pubkey, you hash it, that's your address, people send to +that hash. And then, when you want to spend, you reveal not just your +signature, but you also reveal the pubkey for the first time. And so, what +protects you is that the quantum attacker, you assume a quantum attacker that's +got a great quantum computer can immediately, as soon as it sees a public key, +can sort of snap of a finger generate the private key for that pubkey and then +forge a signature. It's a totally valid signature at that point. So, a slow +quantum attacker, people say, "Well, maybe the pubkey hash is enough security, +because if you post a transaction, it might take them a day to find your private +key from your public key, and then you can get your transaction confirmed and +then it's too late for them". That might work, but this is a way to make this +timing such that even if the quantum attacker has immediate access to your +private key, it doesn't matter because the OP_RETURN happens first. + +The idea is you construct your transaction, you know where you want to send the +money, you look at what that txid looks like, you then commit the txid in an +OP_RETURN. And that txid doesn't really tell anyone anything. Even if you have +a quantum computer and you look at the txid, even if you know everything about +what the, you know, you have a specific person you're trying to target and +you're saying, "Okay, I know that Murch is going to spend his UTXO here and he's +gonna send it to his other UTXO and I want to try to malleate that transaction +and send it to myself instead". Just seeing the txid doesn't give you the +pubkey and doesn't give you any useful information. And so, what it does is +once that txid is confirmed as an OP_RETURN, you now can't change where it's +going. Once that transaction is posted, I can now try to create my own txid in +an OP_RETURN and front run that way. And that's what the actual two hashes are +to make it so that you don't have that problem at all. + +But this is the basic mechanism. That's the good part. The good part is if you +haven't reused addresses, and you have pubkey hash addresses or taproot with an +asterisk, the way you'd do it with taproot is you need an inner key as well. +Your inner key of your taproot output becomes sort of like the pubkey in a +pubkey hash system. So, that's a little more complex. But what would be nice +about this is that, okay, quantum computer shows up, you can still move your +coins and your coins are safe, even if a quantum computer shows up and we don't +have any new Winternitz or quantum-secure signature system. The problem is +then, how do you get the OP_RETURN in? And that's actually the biggest problem +is, okay, we need this commitment, but we don't have a way to make normal +signatures. The only transactions right now that don't use signatures, that can +put OP_RETURNs, are coinbase transactions. So basically, if this did happen and +we're unprepared, it would be like, "Okay, I need to get OP_RETURNs in. I need +some out-of-band way to give this to miners", which is bad, but is less bad than +Bitcoin dying completely, in that you'd need to find a way to say, "Okay, I need +to get an OP_RETURN to a miner or really anyone else that can make a +transaction". + +So, what you could do is say, "Hey, I will gather 100 OP_RETURNs, txids, from my +friends, and then put that in my transaction, and then give that txid to a +miner". So, it doesn't have to be so bad as directly going to miners, you can +sort of give it to friends. But it is this sort of out-of-band, you know, the +normal mempool broadcast mechanism is no longer enough. It's semi-trusted in +that it's not trusted, but it's spammable, like how do you know that this +OP_RETURN is going to give you anything? There's no fee attached to it because +it's not a transaction, and so on. So, that's sort of the downside. But it +seems survivable, you know, so maybe if this happens and then for a month, +Bitcoin is in this sort of degraded mode where mempool doesn't work as normal +and you need to get these OP_RETURN commitments out first. But then, Bitcoin +still sort of works. + +I can sort of finish up, I guess, before questions, of it actually can keep +working even after you have a quantum signature scheme. So, one of the things I +want to write a little bit more about in this is imagine there's a Winternitz +scheme or something that's got, I don't know, 16-kB signatures. You could say +you could imagine a wallet that says, "Okay, I'm going to keep one Winternitz +output. And I'm also going to keep a bunch of UTXOs that are just regular +P2WPKH. And when I want to spend, I'm going to have my one big signature, but I +can also move a larger amount of different UTXOs with the small, essentially +tiny signatures". You can also get rid of signatures completely. You could +have an output type that was just, "Here's a hash, and if you know the preimage, +it's spendable", and then you spend it, you know, commit to the spending +conditions with this OP_RETURN thing and then spend it that way. And then your +signatures, in theory, could be 16 bytes, because you're only relying on +preimage resistance of SHA256. So, you can have a 16-byte preimage and then you +get the 32 at hash, with a bunch of overhead, like the 32-byte OP_RETURN as well +as the amortized size of this quantum-secure signature, this Winternitz +signature. + +But it could be useful even long term with a quantum signature, because it's so +much potentially smaller. If we have a cool quantum signature system that's a +couple of hundred bytes and everyone just uses it, then probably that's fine. +But if we are in a system where we are constrained by witness bytes and the +quantum-resistant signatures are quite large on the order of kilobytes, then it +could make sense to keep using this as well. It gets a little complex, but now +you have this very small signature scheme that's still usable alongside a +quantum-resistant signature scheme. So, I don't know if you guys have questions +or if that makes sense, but yeah, I want to write more about it. It's something +that I posted about a month ago and then people have responses, and I have this +whole thread of notes and I need to post again to the mailing list. + +**Mike Schmidt**: Well, I have questions, but I would be remiss if I didn't let +Jonas ask something that maybe is on his mind. + +**Jonas Nick**: I actually have a couple of questions. I think this is a +really, really interesting scheme. So, one thing I was wondering immediately +is, so you would introduce a new, very significant data structure to Bitcoin +implementations that stores this OP_RETURN data. So, what sort of data +structure are you envisioning? It should be append only, right, and past +lookups? + +**Tadge Dryja**: Yeah. So, that's the other. The part I explained, which is +just commit to txid and OP_RETURN. The actual thing I wrote has three hashes: +one is the txid; one is this commitment proving you know the public key that +helps protect against this front running attack that I mentioned, but didn't +explain very well; and then, the third is a hash of the pubkey that is with a +different hash function, whether it's keyed or some other thing, than the pubkey +hash we use in addresses. And that becomes sort of the key for which you're +storing this key value store. So, yeah, the data structure, if you just do +txids, it gets pretty bad, because now you've got this giant structure that you +need very quick access to, to verify any transaction. What you'd have instead +is you'd commit to the hash of the pubkey being used, but again, a different +hash function, so it does not look like the address. Imagine you prepend the +word 'post-quantum', or something, and then hash. But what that lets nodes do +is they say, "Okay, that's my entry". If it's a key value store, if you're just +using LevelDB again, that's your additional key. + +So, you say, "Okay, here's the 64-byte commitment, and here's the 32 or probably +16 is fine, but let's say it's a 32-byte key, where I'm storing it in". And +what's nice about that is once you learn the pubkey, you can delete that. But +it is still a problem in that people can spam arbitrary data and then you're +going to have to store that. I think it's bad, but I think that's sort of what +we're dealing with today, in that people can make fake pubkeys and you've got to +put that in your UTXO set and you're stuck with it. But yeah, so the idea is +this additional hash of the pubkey keys it so that it's a very quick lookup, so +that it's like, once you see a public key in the transaction, you say, "Okay, +have I seen that public key in a commitment before?" and you can very quickly +look it up if you have or not. And also, if there are attacks where people are +trying to collide and multiple people are making different commitments claiming +to have the same pubkey hash, you do need to store all those. + +But once the reveal happens, if it ever does, you can delete them all. And you +know that, okay, there were, you know, 20 conflicting commitments to different +transactions with this one pubkey, but once I see the pubkey, I can decrypt them +all essentially and know which one is valid and only store one of them. Or, if +that one valid one that happened was the transaction itself revealing the +pubkey, then I can delete the whole thing. Or, the thing is, if you delete the +whole thing, then you might have to store it again if someone makes it, so you +probably want to leave a little tombstone of that key so that if someone ever +tries to make another commitment with that key, you're like, "No, that key's +already been used and there's been a commit/reveal". + +So, yeah, that part's a little ugly. I don't think in terms of scalability, +it's any worse than the existing UTXO set. But yeah, you would introduce this +new sort of key value store. You'd probably shove it in the same LevelDB, make +it look a lot like the UTXO set, it's got very similar properties. So, that's +the thing there; not great, but doable. + +**Jonas Nick**: Yeah, that makes sense. I think, so since we have we were on +the topic of collision resistance versus preimage resistance, I think it relies +on collision resistance because in general, the attacker has control over the +txid because we do sort of transactions collaboratively, right? So, you can at +least select outputs, etc. So, it would be possible for them to produce two +messages and then if they hash to the same value then ... + +**Tadge Dryja**: Well, so multisig is a whole other story with this. Multisig +sort of becomes 1-of-m with this scheme. Like, if you have, say, a LN channel +and you have a 2-of-2 multisig, both parties know each other's public keys. +With this scheme, it essentially becomes one event, either party can try to grab +the whole thing, which is not great. There are ways and you could create a +system where you'd have to change the output types in Lightning, which is +totally doable with today's script, where you use pubkey hashes instead of +pubkeys. You could do it, but at that point, you're changing things enough that +why not just introduce an actual Winternitz scheme or hash-based Lamport scheme, +or something. But you could do that so that, let's say you're using non-taproot +LN channels that are P2WSH, and within that witness script, there's two pubkeys. +What you'd have to do instead is have two pubkey hashes within that script. And +then you can say, "Okay, I need a signature from both of these pubkey hashes". +The question is, is it worth it? Since you're going to have to change all the +LN software, why not change it? Like, let's just get an actual +quantum-resistant scheme. But you could adapt it to that. + +So, this saves most coins, because most coins are in single scheme. Or if it is +multisig, a lot of times it's pretty cooperative multisig, where if it's an +exchange or something and they have three or four keys, well, even if the +security degrades to only needing one of those three or four keys, probably it's +still okay. Because if the alternative is all these coins are destroyed or all +these coins are stolen by a quantum attacker, then, yeah, some security +degradation and loss of utility is okay. + +**Jonas Nick**: Yeah, right. That makes sense. And a final question, you +mentioned in the beginning that you don't think it's a great idea. So, what +specifically did you mean? + +**Tadge Dryja**: Well, I guess it's like, I don't want to advertise it. It's +like, "Oh, everything's solved. We don't have to work on quantum-resistant +signatures". Or like, "There, no problem". Because if you use this, it's a +much worse user experience. It's like, okay, how do I get the commitment? +Also, now your transactions have got multiple steps that are probably separated +by hours. So, it's slower. You know, it's worse. So, in that sense, it's bad. +It's not like, "Oh, this is going to make Bitcoin better and easier". I hope +quantum computers never show up and we never have to use this. But if a quantum +computer does show up, this is vastly better than, you know, the coins are +destroyed or stolen. It's like, even if you haven't thought about this, if you +have some old coins from ten years ago in a beta pubkey hash output that you've +never used, you can use this, and it's a soft fork, and we'll probably soft fork +something like this in. And these decade old coins are now securely movable +years after the quantum computer shows up. + +So, that part is great. But for actual usability, it's like, no, we definitely +need other stuff as well. So, I want it to be a backup plan, not a like, "Hey, +we don't need any BIP360 or other quantum stuff. This is it". So, that's what +I mean by it's bad. It's actually good, but it's like, use this as a backup, +use this when other things are broken. + +**Jonas Nick**: Okay, cool, next? + +**Mike Schmidt**: It seems like this would eliminate this rush for everybody to +migrate to a quantum-safe address, right? + +**Tadge Dryja**: Yeah. + +**Mike Schmidt**: Yeah. So, you lose that rush, although anybody who doesn't +have a scriptpath spend, it sounds like, or if they have an ancient P2PK +address, or something like that, those folks would need to rush before this soft +fork activates, because those would become unspendable or stealable, or +whatever. + +**Tadge Dryja**: Yeah, so it would be like taproot with no scriptpath, or it +doesn't even have a scriptpath; inner key, I guess, would be a problem. So, +you'd want to encourage wallets to say, okay, either have some kind of actual +P2QRH, or something, or just have taproot with some kind of inner key and some +kind of script spend, even if the script spend is just like a different pubkey, +right? That's totally fine, and that would make it secure with this system. +Yeah. And then, P2PK is old enough that I'm guessing most of those will be +either stolen or destroyed, and I have a very strong hypothesis of which will +happen of those. But anyway, those are probably mostly lost keys and not a lot +will happen. + +The big one is P2PKH and P2WPKH with reused addresses. There's a lot of coins +there, and those are vulnerable. So, the recommendation there is just move your +keys to non-reused, you know, single-use addresses and you're good. You can do +that today, and that has been the recommendation since day one. + +**Mark Erhardt**: Yeah, you should do that today. Blockspace is basically free +right now. Even, especially with the last few weeks, people being able to get +transactions below minimum relay transaction fee into blocks. This is a great +time to consolidate funds that are in reused addresses or P2PK. + +**Tadge Dryja**: Yeah, and so this is probably a motivation to do that, in that +this is a scheme which, I don't know, I think hopefully we don't have to use +this, or we may end up using something like this, hopefully have years before we +have to worry about it. But it is a kind of thing where you can activate this +after the quantum computer shows up, after you've got proof that a quantum +computer exists, and we're like, "Hey, quantum computer has stolen a couple of +thousand coins". And then, you can activate it and say, "Okay, well, those +couple of thousand coins, that sucks, but that's what happened". And then, it's +locked in. And then, all those people with reused addresses, it's too late. +Either you're going to get stolen or the coins are going to be frozen, depending +on how that how that works out. Neither are good. And so, it's sort of like, +yeah, you should move them now. And there's a real risk if you're worried about +quantum computers happening. + +I'm personally not so worried. I'm thinking it's very unlikely it'll happen +anytime soon. But it's like, hey, even if it's like a 1 in 1,000 chance, that's +something worth mitigating, and that's something worth looking at. So, yeah, if +it's possible, people who have wallets that reuse addresses, or people who have +coins that have reused addresses, now's a great time to move them, and then +given this protocol, we're pretty sure that even if you have a quantum computer, +and you just have a P2WPKH address that hasn't been reused, you're pretty much +safe. So, that's my recommendation. Okay, go ahead, sorry. + +**Mike Schmidt**: Tadge, what's your canary in the coal mine of where this would +be like, "Oh boy, we're going to have to think about turning something like this +on"? Would it be coins mysteriously moving and people complaining about it on +Twitter? Is it adjacent research on quantum, where people are able to break +things that are getting close to similar to… + +**Tadge Dryja**: I mean, to me, we don't have to get too much into it, but like +run Shor's algorithm at all once on any number, I'm not an expert, but I have +written... People say, "Oh, they factor the number 15", and yeah, kind of. If +you read the paper, the circuit they used had the numbers three and five in the +circuit in the hardware. So, it was really more of a verification than a +factoring. And as far as I'm aware, Shor's algorithm with the quantum Fourier +transform (QFT) and the thing that would kill ECDSA or any secp stuff, has not +been run on a physical quantum computer. So, if that were to happen, even for a +very small modulus, or whatever, then it would be like, "Oh, it's real". Maybe +we're still years out, but that's significant progress. + +But I also in the post wrote that you can have a sort of proof of quantum +computer, where basically you just look and if there's these two opcodes, which +I think it's OP_SHA256, OP_CHECKSIG, and if any transaction has that and is +valid, that means someone hashed something and then verified a signature with +that hashed output being the pubkey. And as far as I know, that means that +either the hash function is broken or the elliptic curve thing is broken, +because you're interpreting this 32-byte hash output as the x coordinate of an +elliptic curve point and then verifying a signature from that. And so, that +sort of means like, "Hey, quantum computers exist". There may be better proof +of quantum computers, but I think that's a good way to activate these kinds of +things, because then you're sure like, "Hey, a quantum computer has proven +itself". + +The downside there is, well, what if it's a bad guy and they don't want to prove +themselves and they just want to steal coins, right? It doesn't work. But it +might be a good guy, right? It might be someone's like, "Hey, I got the first +quantum computer and I'm this big lab at this big university, and here's a cool +proof. We're going to just hash some random thing, get a SHA256 output, and +then find the discrete log of that point that we just hashed, and prove we have +a quantum computer that way. So, if we do have that, then it's sort of a nice, +easy, like, "Okay, quantum computer exists", and that's consensus verifiable. +You can put that into a transaction, and then everyone in Bitcoin sees it, and +every node auto enforces, given that. But yeah, but hopefully that's also not +what happens, because we have enough time that we're pretty sure years ahead of +time. But these are sort of the emergency options if it does come to that. + +**Mike Schmidt**: Talk a little bit about multiple inputs. If I understand +correctly, only the first pubkey in the transaction works with the scheme, do I +have that right? + +**Tadge Dryja**: Yeah, you don't need more than one, so you can do multiple +inputs and only have one commitment and one pubkey reveal, and I just set it to +the be the first one. But you could get more complicated than this. I think +this is like a good stepping-off point. If we actually start writing a BIP, +then you could probably get more complicated and say, "Okay, how do we deal with +multiple inputs?" The thing is, it's pretty brittle, in that if you make one +commitment and you're like, "Oh no, wait, I want to change my transaction", like +there's no RBF, there's no things like that, because there aren't really fees. +So, it's pretty brittle, so I just stuck with whatever is simplest. But yeah, +right now the idea is just the first input has the commitment and the other +inputs sort of are along for the ride. + +**Mike Schmidt**: I'm curious about one thing that you dropped in there. You +said you had a strong inclination, or I forget the word you used, on whether the +community's going to burn these coins or get them stolen. + +**Tadge Dryja**: Yeah, to me, I can see how there's a moral debate, but I think +in practice that freeze or destroy, or whatever you want to call, is going to +win. Because if you actually had a quantum computer and it was actually +grabbing people's coins, let's say there was deep disagreement and there was +people saying, "No, we can't just freeze and destroy all those coins. That's +millions of coins that'll just be disappeared", and the other side says, "No, we +have to, they're just being stolen", that's a soft fork to disable elliptic +curve signatures at that point. So, you could say, "We're disabling elliptic +curve signatures, other than with this commit/reveal scheme", right, to keep +backwards compatibility. That would be a soft fork. And if there were a deep +disagreement, you would have a chain split. And if that chain split were to +happen, I would totally side with the fork that disables ECDSA, because on the +other side, you've got millions of coins being stolen and presumably liquidated. +And on the destroy side, you've got a bunch of coins being destroyed and the +total number of coins decreasing rapidly. So, it's just like one will be worth +so much more than the other. I don't see how the 'let the quantum attacker +steal coins' side could really maintain being a viable coin. I don't know, +that's just my prediction of what would happen. + +**Mike Schmidt**: Makes sense. Jonas or Murch, any other? + +**Mark Erhardt**: I just had a small comment and I've been searching in the +background. My recollection is that there is actually the Binance cold wallet +which is heavily reused. It's one of the most reused addresses, and I think it +was looking up for trying to find the number. But if I recall it, there's at +least 100,000 coins in there, and if not millions. So, in the case that a +post-quantum computer arrives, I don't think that there's been statements, "Oh, +all the 50 bitcoin P2PK outputs would sort of act as an early warning sign". +Well, if someone can break any key, I think the key that I would start breaking +is significantly more valuable than 50 bitcoins! + +**Tadge Dryja**: Right, yeah. So, the real thing is we've got to bug Binance, +"Don't reuse addresses", then they don't have this problem. But yeah, because +that would be the first attack, right? If you're a good guy, you say, "Hey, I'm +just going to prove that the quantum computer exists and that I can break +secp256k1, and then that's great. Some nice person showed that this is a real +threat and we have to deal with it. But if it's a bad guy saying, "No, I'm just +going to take Binance's reused address. They've got 500,000 coins on one key". + +**Mark Erhardt**: I mean, there'd be also the question whether there's a better +game theoretic approach, where you can steal coins that might not be as easily +verified to be stolen. + +**Tadge Dryja**: Oh, that would be a big mess, right? Because then if it's +identified very quickly, you could say, "Hey, all miners", and Binance probably +knows a bunch of miners, "Hey, miners, revert this transaction and do this other +transaction instead". It could be messy. + +**Mark Erhardt**: Oh, yeah, we remember that discussion happening after, who was +hacked? Was it Binance? Someone was hacked and several hundred bitcoins were +stolen and they were like, "Oh, we should roll back the chain", and they started +thinking about that a day later or so. So, more than 100 blocks had passed, and +people were like, "No, man!" + +**Tadge Dryja**: Yeah, this one's even more, because it's like, "Hey, this is a +fundamental assumption of Bitcoin from day one that has now been violated". You +have a much stronger argument. It's not just, "I screwed up", it's, "Bitcoin +itself is broken. We should roll back". So, I don't know. Best case is, try +to avoid those scenarios from happening and get people to not reuse addresses. + +**Mike Schmidt**: Well, I assume the Binance executives that listen to the +Optech podcast will digest this and adjust their scheme accordingly. + +**Tadge Dryja**: Yeah, because it's very low cost, right? There's no additional +fees. The software complexity, it's not much harder with a hierarchical wallet +to just not reuse addresses. So, it hopefully is a pretty easy change that +could potentially save their entire… + +**Mark Erhardt**: 250,000, I just found it. + +**Tadge Dryja**: That seems worth it, you know? + +**Mark Erhardt**: Just $27 billion right now. + +**Mike Schmidt**: All right. + +**Tadge Dryja**: Yeah, I'll help. I mean, give me a very small cut and I will +totally write the software. + +_OP_TXHASH variant with support for transaction sponsorship_ + +**Mike Schmidt**: "OP_TXHASH variant with support for transaction sponsorship". +Steven, you posted to Delving Bitcoin JIT (just-in-time) fees with TXHASH, +comparing options for sponsoring and stacking. In it, you compare managing +transaction fees using CPFP, transaction sponsors, and a new construction based +on TXHASH that you call TXSIGHASH. What did you come up with? + +**Steven Roose**: Yeah, so that's a totally different topic. Yeah, so this has +been one of like, while designing TXHASH together with Rearden, going back and +forth on the different design ideas, there's some obvious things that you can do +with it. But I had never put in the actual effort and time in seeing how would +the construction actually look and how would they compare with alternative +constructions, especially with how to pay fees for existing transactions, which +currently we do with CPFP. So, we have these anchor outputs and then people pay +fees externally by making a transaction, spending a transaction. And there's +been an alternative proposal, called Sponsors, where you can create a +transaction that says, "I want to also include this other transaction for my +transaction to be valid", so that you can effectively add fees also for that +transaction. With TXHASH, you can do this in an entirely different way. And I +wanted to basically look at the constructions, how do they compare when it comes +to bytes and when it comes to interactivity to actually create those +constructions. And then, to touch a little bit on the TXSIGHASH, it was a name +I never used before. + +So, what TXHASH does is it gives you a way to pick some parts of the transaction +that you want to put in a hash. And we already do this in Bitcoin. When you +sign a transaction, you sign what we call a sighash, and the sighash basically +takes your transaction, hashes it, and then you sign a message over that. But +obviously, it doesn't sign the entire transaction. Obviously, it cannot sign +the signature, for example. So, the sighash only signs parts of the +transaction. And currently, we have a little bit of flexibility of what part of +the transaction that we want, but we have very limited flexibility. So, you +have SIGHASH_ALL, SIGHASH_SINGLE, SIGHASH_NONE, which kind of lets you pick the +outputs that you want to cover in your sighash. And then, it also has this +feature called ANYONECANPAY, which gives you a little bit of flexibility on what +you want on the input side. But the flexibility is very limited. You only have +these two dimensions that you can do. And then, you pick one and you hash this +and then you sign that hash and that's your signature. + +So, with TXHASH, originally it's just in opcodes where you can create such a +hash, but with full flexibility, you can basically pick anything you want from +the transaction, "I want these fields, I want these outputs, I want these +inputs", etc. And then, this hash gets put on the stack and you can do +basically two things with this hash on the stack. You can either compare it +with some other hash that has been predefined beforehand, and that way you can +assert certain properties of the transaction, "These properties need to be +exactly this, because they need to be exactly the same as this hash that I +created beforehand". Or you can make a signature over this hash using the +opcode CSFS. But when we are doing signature over hashes, that's kind of +similar like a sighash. + +So, the natural evolution of TXHASH would be to create a new sighash system, +where you directly use the transaction field selector, I call it, from TXHASH to +do a signature without having to do the opcode that puts it on the stack. And +then, the other opcode that does the signature, you could basically make it a +native sighash so that you can do directly the signatures, and then you can use +it, for example, in taproot keyspends, where then you don't have to do +scriptpaths and you don't have to create the actual script but you can directly +create a keyspend signature, provide the tx field selector that you want to use +to create the hash, and then sign that hash. And then, you can get full +flexibility in your sighash. You can do stuff like ANYPREVOUT (APO), which is +another sighash mode that has been proposed before, where you can have more +flexibility over the input side. But then, you can basically have full +flexibility, like everything you want. + +So, I just dubbed this thing TXSIGHASH. I think many people who are familiar +with these protocols and how Bitcoin works would kind of understand what it +means. It's not exactly spec'd out byte for byte, but it's using the TXHASH +construction to build a sighash alternative so that you can do keyspends and you +can maybe also use it for the OP_CHECKSIG, or something like that, in the +scriptpaths. So, that's the TXSIGHASH construction summarized. And then, in +this post, I kind of use this construction, because it's a little bit more fair +than having to waste the bytes for doing tapscripts, and then compare how you +could use this construction to do things like paying fees, I call it JIT, for +your transaction. To what level of detail should I go? I'm not really sure. + +But so, the fact that CPFP, it's very flexible, right, because you just have +this empty output and you can then do whatever you want with this output. But +it also wastes a lot of bytes because you need to create a second transaction, +spending this input, creating an empty output. An output costs a lot of bytes, +an input costs a lot of bytes. And then, you need to create an additional input +to actually put money in the child. So, it's a very flexible construction, but +it uses a lot of bytes. Then, Sponsors would be a little bit better, because +you don't need these anchor outputs anymore. You can just create any +transaction and then a Sponsor transaction below it that just somehow, in a very +efficient way, mentions the previous transaction and says, "This transaction +also needs to be there". So, then you can already cut a lot of the bytes used +for CPFP, you don't need to output anymore, you don't need the additional input +anymore. + +But with TXSIGHASH or TXHASH, you can actually be a little bit more efficient, +because the sponsor transaction, you can actually merge it into the same +transaction that is the actual transaction you're trying to pay for. It cuts a +few more bytes compared with Sponsors, but it also does an additional thing +where it's very easy and flexible to sponsor multiple transactions at the same +time. Sponsors also has something like that, but you need to spend a few bytes +per each transaction that you're sponsoring. So, it grows linear, even though +it's not very fast linear, but it's still linear. While with TXHASH, it's just +the same cost, there's no growth with more transactions that you're paying. So, +with TXSIGHAS, you can create signatures that only cover your inputs and +outputs. And then, someone else that also did that, your transaction can just +be stacked into this other transaction making a single transaction. Because all +the signatures basically only cover the inputs and the outputs, it doesn't cover +the rest of the transaction. So then, when multiple people do that, when for +example you want to pay for multiple of your transactions, let's say three, you +can just take the three transactions into a single transaction and then add one +more input and one more output. And then, this one covers all of the previous +ones without additional bytes. + +Then, another next step to do this, so this is already a very byte-efficient way +to do paying for fees after the fact, especially if the transactions are yours, +so then you can just create the signatures yourself. But then, it also allows +for a scheme where a third party could pay the fees for all these people in a +way where the interactivity is manageable, right? I mean, we can do it right +now, for example with coinjoins, coinjoin rounds. People also constructively, +collaboratively make a big transaction, but it's super-interactive because +everyone needs to sign everything from everyone else. While with the TXSIGHASH +construction, everyone can just create a fixed set of signatures once, and then +the coordinator who puts it all together and pays the fees can basically use the +building blocks that people have sent him, make the transaction at the fee. And +that's, I think, a very powerful construction, especially since it's +non-interactive. I see Murch wants to raise a point. + +**Mark Erhardt**: I wanted to ask back whether I properly understand something. +So, with this TXSIGHASH commitment to other transactions being already confirmed +in a block before this transaction, do the owners or senders of the original +transaction get a way of signing off on that or not? Can anyone do it? It +sounded for me like you needed some signature from someone, but it sounds like +anyone can attach to any other transaction, is that right? + +**Steven Roose**: Yes, if they're assigned using the TXSIGHASH semantics that +only cover their inputs and outputs. + +**Brandon Black**: One slight clarification, just to make sure everyone is +clear, with TXSIGHASH, it's not actually separate transactions earlier in the +block. That's the Sponsors method. In the Sponsors method, there are actual +whole bitcoin transactions with the transaction header, and those are required +by the Sponsor transaction. With the TXSIGHASH method, it's just one +transaction header, and there's groups of inputs and outputs that get stacked in +there. And then, there's the last input and output from the sponsor equivalent, +which is the payer of the fees. But it's all one transaction that goes into the +block, is one thing. + +**Mark Erhardt**: Okay. So, maybe let me ask differently. So, one of the +biggest concerns with the Sponsors proposal was that it basically creates +unfettered pinning attacks. Anyone can attach fees to anything, which allows +anyone to fuck with the order of transactions, and thus make it a headache to +find out what is going to go next. Especially if you can sponsor multiple +transactions, it becomes very, very complicated to calculate what is the highest +priority item to include in blocks next. And I think this is also true here in +this context. Could you clarify? + +**Steven Roose**: Yeah, so one of the caveats, obviously, of this proposal or of +this idea in construction is that it significantly changes the way we look at +the mempool. Because transactions are no longer transactions that are kind of +immutable right now, transactions are kind of stable. Like, if a transaction is +made, it's not easy to just fiddle with it and make a different transaction +that's equally valid. And with this proposal, if people would be using like, "I +only sign my own input and my own outputs", constructions, people could mix and +match and people could make different constructions, and it would obviously be +more vulnerable to pinning attacks and all kinds of shenanigans. So, it would +definitely require a lot of thinking on how do we structure the mempool in ways +that is more compatible with these kind of constructions. If you're doing only +opt-in kind of things like, "Oh, we're doing this in some kind of construction +where, in the end, I will always have control over this in some other way", then +it's kind of fine. Like, for example, if after the fact you have a hook where +you can say, "Okay, now I can say I only use this", then it would be kind of +safe. Maybe in constructions where you know up front that you're going to use a +certain stacker, like an external party who's going to pay your fees, maybe +there's also ways to make it more safe if you already know that you're going to +do this. + +But yeah, I mean it's a different box that we open. It's like mempool policy +becomes a different beast. It's no longer nodes of transactions, but nodes of +things. But I've talked about this with some people who have deeper knowledge +of mempool policy, and I was pleasantly surprised that they wouldn't think it +would be that much more crazy. I was like, "Doesn't it break everything?" It +doesn't necessarily break everything, even though you can create a lot of the +transactions that are kind of similar. They still would be in the same cluster. +So, when we would finally get cluster mempool, which is, I think, a super-great +improvement to mempool design in general, they would still all be in the same +cluster, right, because they share the same inputs and outputs. So, then you're +not creating an explosion of different transactions, they would still be in the +same cluster. And then, just the best version, based on whatever algorithm you +would use inside your cluster, would be picked. + +**Mark Erhardt**: Sorry, but, but you could have multiple transactions that +tried to bump either competing or the same transactions. And then, depending on +what goes into blocks, that would, for example, change how much fees seem to +push for other transactions that are still left. Or if you have multiple +competing transactions that sponsor things in different clusters, they combine +clusters. I just don't see how this is true. I don't know who you've talked +to, but it seems to me that exactly the issues that raise concerns with sponsors +apply here. So, I was thinking, how about if the sender of the original +transaction that is being sponsored in some way had to sign the new transaction? +Like, yes, you can create a transaction that doesn't need to change the prior +transaction, but the signers of the prior transaction have to get their +signature in, like the signature is added into the sponsoring transaction. That +way, you get the opt-in at the second transaction's creation. Then I could see +how it is not problematic. But if anyone can just attach their transaction to +the confirmation of existing transactions in the mempool, I think it is going to +make mempool completely complicated, and it creates new dimensions of pinning. + +**Steven Roose**: Well, I'm not incredibly familiar with the algorithms used in +cluster mempool in the current form and shape, so I cannot comment too much. +One thing that's definitely true is it definitely covers the same ground as +transaction sponsors, but it's way more efficient and way more powerful than +transaction sponsors is. So, if we can work around those things in the context +of transaction sponsors, obviously this scheme could be considered as a better +or a more efficient proposal, or an alternative to transaction sponsors, given +the same category of problems that need to be solved. + +**Mike Schmidt**: And Steven, it's not multiple transactions, it's one, right? + +**Steven Roose**: I mean, yeah, but if you can make ABC plus Sponsor, you can +also make AB plus Sponsor, you can also make AC… + +**Mike Schmidt**: Right, but I think Murch made the point that... + +**Mark Erhardt**: And you can make A plus B apostrophe and C as a sponsor next +to ABC being sponsored, and so forth, and it could become a very +high-dimensional problem to solve. I think it might also fuck with TRUC +(Topologically Restricted Until Confirmation) transactions. + +**Steven Roose**: I'm not sure if TRUC would still be very relevant in this +case. I think TRUC is mostly about CPFP. I mean, yeah, you could combine them +in different ways. I'm not sure. + +**Mark Erhardt**: Right. But for example, TRUC appears in the context of +sibling eviction, because TRUC transactions can only have one unconfirmed parent +or unconfirmed child. So, if a new unconfirmed child is added to an unconfirmed +parent transaction, regardless of whether they're spending the same UTXOs, they +will evict each other under TRUC paradigm. Now, add in sponsorship, this +definitely becomes more dimensional than just two transaction packages. Anyway, +I think we're getting a little in the weeds here. Either of you wanted to add +anything else? + +**Brandon Black**: Yeah, I had a question for Steven that I've been meaning to +ask. Actually, I have two, sorry. First one, hopefully, is a simple one. Did +you analyze CPFP imagining that we had the ability of a multi-parent TRUC, or +did you analyze it just with a one-to-one when you were doing the comparison? + +**Steven Roose**: I think I did, yeah. I did. I have it in my table. But I +mean, CPFP is just always really bad when it comes to bytes. Because every +parent will have an output, which is like 30, 38, 40 bytes, well, how much is +it? + +**Mark Erhardt**: Yeah, it's 11 bytes with P2A. + +**Steven Roose**: Oh, with P2A, okay. Yeah, that's true. You have now P2A. + +**Mark Erhardt**: And then, the input script isn't empty, but of course you +still have the outpoint and the sequence. So, it's 41 bytes on the input side +and 11 on the output side. So, 52 bytes in total. + +**Steven Roose**: So, you still have 52 bytes per child or parent, I'm sorry, +which you wouldn't have with either Sponsors, or I think with Sponsors, you also +have a fixed amount of bytes. I think it's something like, depending on, I was +looking at the different constructions, because the initial constructions for +Sponsors had 32 bytes per transaction, which is obviously not super-efficient. +I think right now it has some kind of efficient way to refer to relative indexes +above yourself, and then you can hash those together in some kind of sighash, +and then it was only a handful of bytes per transaction. And with the TXSIGHASH +approach, you would have no bytes per transaction. + +**Brandon Black**: Cool. And then, my other question was, have you looked at a +way… I remember, I think in your post, you mentioned that to do this with +TXSIGHASH, the proposers of these bundles, these sub-transactions, would have to +sign them in many ways so they can be relocated relative to other inputs. Did +you do much analysis on what would change in the TXHASH proposal to allow it to +be signed in just one way, and there's like some kind of a way to delineate my +inputs or my outputs that could be anywhere; did you look at that at all? + +**Steven Roose**: No. I mean, so I can detail what you talked about. So, +because if all transactions would be just one input, one output, or two input, +two outputs, it would be very easy, because you can always just sign, "This is +my input and this is my output", and it's right next to me, right? It's at the +same index. If I'm input five, my output is also output five. But because not +all transactions are like that, some transactions are two input, one output, +some random mismatch of data, to solve that and to allow an external party to +combine these bundles together, you basically sign for multiple possible +locations of your output relative to your input. So, if you have three inputs +and one output, you basically sign 100 different offsets so you can say, "My +output is at the same output plus one, plus two, plus three", and you sign a +whole bunch of these. It creates this kind of bundle that you can then send to +the coordinator who's going to pay your fees. And he can then, for each of the +different bundles, pick the right one so that it fits into the place. + +So, what Rearden was asking is, "Is it possible to extend or make the TXHASH +construction more flexible that you wouldn't have to have multiple signatures +and you can just have one, and then somehow, in some kind of place in the +witness, the coordinator provides the index and says, "Okay, actually this guy +signed for this output so you should look there'?" No, I haven't. I think it +might actually be possible, yeah. So, the answer is, I didn't look into it. +But it's actually a very good idea, because it might actually be very simple. +It might actually just plug in the number and just the signature would work, and +that would be really cool. I did note in my text that it was a very naïve, a +very simple, simplistic stacking proposal. It was not really the core of the +idea that I wanted to convey in that post. So, I didn't make it more efficient, +it's very inefficient, you need to provide hundreds of signatures and it's only +somehow flexible. But it's definitely a design space that has a lot of +potential if TXSIGHASH would be a thing and if stacking would be a thing that +people want to do. + +_Bitcoin Core #32540_ + +**Mike Schmidt**: Moving to the notable code and documentation changes this +week, we have Bitcoin Core #32540, which adds a REST endpoint, or function, to +fetch all of the spent transaction outputs in a given block. So, software or +services that provide indexes on that sort of data, for example, they use that +data and they get that information from Bitcoin Core currently. And there are +ways to get that data from Bitcoin Core currently from another REST endpoint. +But that REST endpoint, all of the data is converted to JSON, so the performance +is relatively slow. So, one of the developers working on those indexing +services actually opened up this PR in which he added a new endpoint that +supports the data coming back not only in JSON, but also in binary and hex +formats as well. And I think he did some data that he put into the PR and noted +that this new endpoint, in binary format, is about 70 times faster than the +existing REST endpoint that uses JSON. The new endpoint is named spenttxouts, +and the existing endpoint that I was referencing is just the block endpoint. +And that, to my knowledge, still remains. + +_Bitcoin Core #32638_ + +Bitcoin Core #32638. This PR adds a check in Bitcoin Core that when Core is +reading blocks off of the disks, it actually requires that the block hash from +the disk matches the expected block hash. So, you need to actually provide the +block hash yourself. And now, there will be a check that when I read this off +the disk, it actually does match that block hash that you expected it to be, +which helps prevent failures caused by corrupted disk or data failures. I don't +know if you have anything to add to that, Murch. + +_Bitcoin Core #32819 and #32530_ + +Bitcoin Core #32819 and Bitcoin Core #32530. The #32819 is actually just the +release note for #32530, and #32530 adds a hard limit to -maxmempool, and also +to -dbcache, those startup parameters. Specifically on 32-bit operating +systems, there are two hard limits placed on them. For -maxmempool, it's +limited to 500 MB on 32-bit systems, and -dbcache is limited to 1 GB on 32-bit +systems. The risk here was that if a user was providing that startup option and +chose a limit that was too large, either of those values being too large could +potentially run into an out-of-memory error at some unknown point after starting +the node. So, that's obviously undesirable, and some sort of limit would help +mitigate that. Although it wasn't clear to me and I'm not sure, Murch, if +you're familiar with why these exact values were chosen. + +**Mark Erhardt**: I'm not familiar with why these exact values were chosen. +With the 32-bit system being limited to using 4 GB of RAM, if you even set the +maximum of both of these, that would only amount to 1.5 GB and leaves enough for +operating system and some other processes to run. So, I think that would make +sense as a limit. I think, well, the mempool is usually limited to 300 MB, so +allowing up to 500 is a slight increase, but nothing too major. And the +-dbcache is, of course, much more relevant to trying to catch up a node to the +chain tip. The -dbcache is used to store the UTXO, so it needs to be read +quickly during synchronization. So, having 1 GB there might be a significant +improvement over the default value of 500 MB, so allowing a bigger value there +makes more sense. That's all I have. + +_LDK #3618_ + +**Mike Schmidt**: Last PR this week, LDK #3618, which builds towards LDK's async +payment capabilities, implementing the recipient side of LDK's static invoice +server protocol. So, sending bitcoin to someone offline isn't an issue, we all +do that; but with Lightning, sending to someone who is offline requires the +third party due to Lightning's interactivity requirements, thus the idea of +async payments in Lightning. And with this particular PR, there was a note, "As +part of being an async recipient, we need to interactively build an offer and +static invoice with an always-online node that will serve static invoices on our +behalf in response to invoice requests from payers". Later in the PR, they also +went on to say, "While users could build this invoice manually, the plan is for +LDK to automatically build it for them using onion messages. Here", in this PR, +"we implement the client side of the linked protocol". And the linked protocol +that was referenced in that description is actually a Google document outlining +LDK static invoice server flows. So, they've documented this flow for how to +generate these static invoices and how to have a client-server interactivity for +that, and they're implementing the client side of that now. All of this to roll +into their async payment capabilities, tracking issue #2298 on the LDK repo. + +So, that's it, Murch, for this week. I think we can wrap up. We'll just thank +all of our guests this week, as we had many, and thank you for doing multiple +recording sessions with me, Murch, and for everyone for listening. Cheers. {% include references.md %} From 682bc942d928cbf47caab49c96b57e49b63185d6 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Wed, 23 Jul 2025 11:09:24 -0500 Subject: [PATCH 167/278] Podcast: add 362 transcription --- .../en/podcast/2025-07-15-newsletter-recap.md | 731 +++++++++++++++++- 1 file changed, 730 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-07-15-newsletter-recap.md b/_posts/en/podcast/2025-07-15-newsletter-recap.md index 654f8719c3..4beb62eab0 100644 --- a/_posts/en/podcast/2025-07-15-newsletter-recap.md +++ b/_posts/en/podcast/2025-07-15-newsletter-recap.md @@ -18,6 +18,735 @@ Mark “Murch” Erhardt and Mike Schmidt are joined by Josh Doman and Gloria Zh ## Transcription -_transcription coming soon_ +**Mike Schmidt**: Welcome everyone to Bitcoin Optech Newsletter #362 Recap. +Today, we're going to be talking about compressing script scripters; we have a +PR Review Club about orphans and Bitcoin Core; and we have our usual Releases +and Notable code segments. Murch and I are joined this week by Josh Doman. +Josh, you want to introduce yourself? + +**Josh Doman**: Thanks for having me. I'm Josh Doman, I'm an independent +developer. + +_Compressed descriptors_ + +**Mike Schmidt**: Thanks for joining us. We may be joined by Gloria later in +the recording, and we'll have her introduce herself when she joins us. We have +one News item this week titled, "Compressed Descriptors". Josh, we had you on +the show when we covered your descriptor encryption library in Newsletter #358. +And well, it turns out that part of the encoding approach that you used for that +descriptor encrypt library can be used as the base of an encoding scheme to cut +down on storage size of wallet descriptors as well. Can you tell us what you've +been working on here? + +**Josh Doman**: Yeah, that's right. So, for context, I released this encryption +library a few weeks ago, which had two components. It had an encoding component +to actually encode the descriptor, and then there was an encryption component. +And it turns out that just the idea of encoding it to reduce its size by 30%, +40% is useful in and of itself. And so, I saw a comment by, I don't know how to +pronounce his name, Sjors, in the context of talking about capital H in +descriptors, and he was referencing how that might be useful perhaps to create +smaller QR codes. And that kind of gave me the inspiration to say, okay, maybe +it'd be useful just to have a smaller descriptor format for QR codes, or for +other types of data formats, like maybe sharing over NFC, where you have a +limited number of bytes you can use. + +So, I created a separate library, called descriptor-codec, where you can parse +in a string descriptor and it will encode it in a much more compact format that +saves about 30% or 40% bytes, using variable length encoding, and also just by +not having to use base58 encoding for the xpubs, things like that. And I +released that. I also released a companion little toy website, called +descriptorqr.org, where you can generate QR codes from descriptors and scan +them. And so, that's what the library does and that's how it works. + +**Mark Erhardt**: Okay, first question. Can the website be run offline? + +**Josh Doman**: You can build a website offline, yes. It's available on GitHub. + +**Mark Erhardt**: Because, of course, you're working for a triple-letter agency +and storing all the descriptors with the IP addresses, which would be the +natural reaction of bitcoiners! + +**Josh Doman**: Of course. I would also note that if you don't want to even +generate a QR code, you can use the descriptor-codec library as a command line +tool, and you don't have to worry about anything going over the internet. + +**Mark Erhardt**: Okay, that's helpful, of course. So, the output script +descriptors, of course, are a better backup for wallets because they get rid of +the separation of xpubs and script composition, and have it all together. What +made you say, "Oh, I really need to store this as a QR code?" + +**Josh Doman**: Well, it's a great question. Our last discussion was about this +encryption library, and you presented some very good perspectives on why someone +might not want to necessarily encrypt their descriptor or store it on a +blockchain at all. And I felt that that was perfectly reasonable, and I think +that many people still want to back up their descriptors offline, right? You +might want to print it out on paper and store it next to your seed phrases. And +if you print it out as a human-readable string, it'd be hard to take that back +into your software later to be able to access your funds. Alternatively, you +could just run it through a run-of-the-mill QR code generator, right? The +downside of that is, depending on how large your descriptor is, that QR code +might be very, very large, it might be harder to print out, it might be harder +to scan. And so, if we can just encode it to reduce the size, that's free byte +savings, makes it easier to print out, sparser, it's easier to scan, that seems +like a win all around. + +**Mark Erhardt**: Right, that sounds very reasonable. So, I assume you looked +at things like how exactly the encoding goes, probably only use capital letters, +because that's more efficient for QR codes? + +**Josh Doman**: I don't quite understand your question. Could you repeat that? + +**Mark Erhardt**: What did you use for the encoding, and what's your approach? + +**Josh Doman**: Understood. So, every component of the descriptor is given a +byte tag. And so, what the encoder does is it moves along and if it sees, for +example, a witness scripthash, it gives it the witness scripthash tag and it +moves along the descriptor in that way. P2TR, the tapleaves are given bytes, +etc. And then, if it sees things like, for example, derivation paths, those +will be encoded using variable length encoding. If it sees things like a block +height, that will be a variable length encoding. And it's using in the +background the Rust miniscript library to do all this. So, that's an incredibly +useful library. It wouldn't have been possible so easily without it, because it +fully enumerates all possible descriptors. And so, every type of descriptor is +handled by the encoding scheme. And in the future, if new types of descriptors +become possible, if we have a soft fork, or things like that, then that will +need to be incorporated into this library as a tag. + +**Mike Schmidt**: I have two related questions. One, is anyone else doing +something like this? And related, is the goal here to eventually have this be a +BIP to coordinate the production and consumption of these things by other +softwares as well? + +**Josh Doman**: That's a good question. I am not familiar with other tools +right now to encode descriptors in this way. If they exist, that would be news +to me. But I'd be very interested to see what people have built. Whether or +not it should belong as a BIP, I think it depends on whether there's community +interest in that. This is a useful tool to make things smaller. If you're +going to parse things over machine to machine, it's not necessarily as useful +for human-readable descriptors. If there's interest from that, from the +industry, then yeah, I think it'd be great for this to turn into something like +a BIP, but I'm not going to propose that unless there's interest from others. + +**Mike Schmidt**: Well, that leads to my next question, which was, is there +interest from the community? Maybe more generally, what's the feedback been? I +saw Maxim Orlovsky replied, but I'm not sure if you had feedback outside of that +Delving Bitcoin thread. + +**Josh Doman**: Yeah, I haven't received a great deal of feedback online. I +personally, as I said, use this in my encryption tool, which did receive a +little bit more feedback. That placed second at the Bitcoin 25 Hackathon. +People seemed pretty interested by that software. I also could imagine that +salvatoshi's encryption scheme, which is different than mine, could also +potentially benefit from something like this, if the goal is to represent things +in a more compact format. But I have not received feedback from wallet +manufacturers or software providers, but I also haven't reached out to those +people yet. + +**Mike Schmidt**: Murch, any other questions? + +**Mark Erhardt**: I think I'm good, thank you. + +**Mike Schmidt**: Josh, we obviously noted the Delving post in the write-up. We +have you on here to get exposure to the idea. If somebody's interested in this, +I assume that you would just want feedback on that Delving thread, or are you +looking for other things from potential listeners? + +**Josh Doman**: Yeah, please give feedback on the Delving thread, I'd love to +hear what you think. And if there's ways that I can improve it, I'd love to +hear that too. + +**Mike Schmidt**: Great, Josh, thank you for your time, thanks for joining us. +You're welcome to hang on if you want. + +**Josh Doman**: Thanks for having me. + +_Improve TxOrphanage denial of service bounds_ + +**Mike Schmidt**: Moving to our monthly segment on a Bitcoin Core PR Review Club +meeting. This month we highlighted the, "Improve TxOrphanage denial of service +bounds", PR and we have the author of this PR as well as the host of the PR +Review Club from a few weeks ago. Gloria has joined us. Gloria, you missed the +intro portion, so maybe you want to just intro yourself for folks who should +know you. + +**Gloria Zhao**: Hi, yeah, sorry I was late. I got distracted at lunch talking +about things like this PR. I work on Bitcoin Core at Chaincode Labs. A lot of +what I work on is transaction relay and mempool things. And this kind of +long-running project that you may or may not have heard of, because we've talked +a lot about it on Optech, is package relay. We have some different components +of it that are in right now and some that are still in the works. And one +long-running portion of it has been orphan resolution. And part of orphan +resolution is this data structure that we use to temporarily store these +transactions while we are waiting for… yes, Murch? + +**Mark Erhardt**: What's an orphan? + +**Gloria Zhao**: Okay, sure, okay. I always forget how much context I give it. +So, an orphan transaction is, from the perspective of a particular node trying +to validate this transaction, one that has missing inputs. So, usually this +will happen when a transaction spends from an unconfirmed transaction that you +haven't received yet. It is also possible that it spends completely +non-existent UTXOs that somebody just made up. There's no way to tell the +difference between these two scenarios. But because we do often run into the +scenario of just missing a parent, because we just came online or they announced +it to us a long time ago and you forgot about it… no, that doesn't make sense. +It could be spending a low-feerate parent that they just didn't send to us +because we had sent them a fee filter. And this is kind of like a package relay +scenario. We want the ability to handle these cases. + +Actually, the orphanage has existed since Satoshi era times. It used to hold +more than just transactions that were orphans or missing input specifically. I +think maybe that has diverged into multiple data structures. But yeah, it's a +separate data structure from the mempool, which is the transactions that we have +already validated and have considered to be consensus and policy valid, and we +think these are probably going to be mined in a future block. So, mempool has +indexes on feerates and whatnot, whereas the orphanage is just a really +best-guess, best-effort data structure. And the primary concern there is DoS. +So, prior to, I think, 2012 actually, the orphanage didn't even have bounds! +And yeah, that's pretty bad. In many ways, 2012 Bitcoin nodes were pretty +vulnerable to DoS. + +So, the solution at the time was to just cap it at 100 and then evict a random +one when… well, actually, it initially evicted by txid order, just the order of +the data structure, which was using the hash of the transaction. And then, they +later changed it to be like a little RNG within your node's logic, not like a +cryptographically secure source of entropy, but just a way for you to randomly +evict transactions that your peer wouldn't be able to anticipate the order of. +But still, it has this problem where it's optimized really well for DoS, but it +is extremely churnable and, in the presence of adversaries, then completely +useless. Because if you can imagine, if I'm using the orphanage as this, you +can think of it as like a temporary workspace to make it possible to download +packages and receive them. Today, we have this opportunistic logic where if +there's a low feerate parent and we happen to have held on to the child +transaction in the orphanage, we'll go ahead and submit those as a package. And +this is enough to, in normal cases, allow packages to propagate. But of course, +the P2P network, we shouldn't assume it to be this very nice environment where +people are only sending valid transactions, right? And so, we've been aware of +this. It's not a vulnerability per se, it's just a known limitation of the fact +that we use this opportunistic data structure that is much more heavily +optimized for DoS than it is for fairness amongst peers. + +So, this project, which I think I started maybe six months ago or so, was to +address a lot of these limitations and create a DoS protection mechanism that +was a lot more comprehensive. So, for example, if a lot of peers are sending +you the same orphan, you probably shouldn't need to count the memory usage of +that transaction multiple times, right? But at the same time, because we build +these indexes of each announcement and we also have indexes on the inputs of the +transactions, how do we account for the additional computational complexity, or +additional latency even, of handling transactions that are very large and have a +lot of inputs and etc? + +**Mark Erhardt**: All right, let me recap a little bit. So, we learned that +orphans are transactions for which we don't know some of the inputs. And that +means of course that we, for example, don't know the feerate of the transaction +because we don't know how much money comes in. And we use this +opportunistically to do package relay, because if we have a child and then learn +about the parent, and they happen to only work as a package where the parent is +maybe too low feerate, we can submit them to our mempool tests together. So, +previously we had just one single orphanage and we randomly evicted one whenever +it overflowed. It was limited to 100, I think, and to 100,000 vbytes? + +**Gloria Zhao**: Yeah. + +**Mark Erhardt**: Right. So, if someone just sent us a bunch of made-up +transactions with inputs that didn't exist, we would drop everything on the +floor over time. And now, you're saying that instead of just randomly keeping +everything in one bucket and randomly dropping stuff, we use announcements where +we remember who told us about what, and we can have announcements from multiple +people for the same transaction. Is that right? + +**Gloria Zhao**: Yeah. So, we define a way of measuring DoS in multiple +categories, including memory and latency or computation for each transaction, as +well as each peer, and globally for the orphanage. And so, this allows us to +create a more fair mechanism. And the accounting is such that when multiple +peers announce the same thing, they're not double-counted, unless we really need +the space, or whatever. And so, the algorithm is, when we're at the global +limit, we will look at which peer is DoSsiest on any of the metrics, and then +we'll evict their oldest transactions first. So, there's no randomness anymore, +but this is kind of the sensible thing to do in an honest or a dishonest case +is, you know, it's fine to just do oldest first. + +**Mark Erhardt**: Right. So, if that were also announced by another peer for +whom it was not the oldest, we wouldn't drop it, but we drop just the oldest +announcement, right? + +**Gloria Zhao**: Yeah. + +**Mark Erhardt**: So, we have to continue evicting until we drop under our +global limit though? + +**Gloria Zhao**: Exactly. That's good and bad. It's good in that no peer can +affect the evictions of another peer's orphans, because if somebody else has +announced it, then we'll still hold on to it. The downside is you might go +through quite a few rounds of eviction before you actually find something that +doesn't have a duplicate to evict. And so, the PR has a number of benchmarks to +handle these kinds of worst-case scenarios to see kind of what the potential +latency is. If everybody announces the same stuff randomly, but it just so +happens that their last transaction is the unique one of something else, what +happens if you have to delete basically everything before you get to something +that actually makes a dent in the memory limit? And of course, that's why we +have more than just a memory-loss score for these transactions. We also do keep +track of the total number of announcements, and that's not a deduplicated thing. +That's every peer plus orphan counts as one. And we actually also add input +count to that. So, transactions with a ton of inputs will have a pretty large +impact on our outpoints index. And so, we make sure to keep those down. + +We picked a ratio that was chosen after some benchmarking and analysis of, it +wasn't profiling per se, but an analysis of how long it takes for us to update +each data structure within the orphanage comparatively. + +**Mark Erhardt**: So, if we have multiple honest or non-malicious peers and one +malicious peer, they might send us a bunch of big transactions with lots of +inputs that actually, some of which might be made-up. And the other +announcements from other peers probably get resolved more quickly, because once +they announce an orphan to us, we would ask back, "Hey, can you also give me the +parent? I don't know about it". And as soon as, of course, parent and child +are present, we can just submit them as a package. So, does that mean that the +opportunistic 1p1c (one-parent-one-child package) relay should be way more +robust in this context now? + +**Gloria Zhao**: Yeah, way, way, way more robust. So, with the total cap-100 +thing, you could just have one inbound peer that is just flooding you with +orphans and causing enough churn where nothing really stays in the orphanage +longer than a second, and that could be enough for you to have requested the +parent, it comes, and then you've already forgotten about the child, so this +whole thing is kaput. But yeah, here's another thing, is we wanted to optimize +for the normal case as well. So, you could have one peer that's sending you a +bunch of stuff and because they're an attacker… but you could also just have one +peer that is a good outbound of yours that happens to be the most helpful +transaction relay peer because, I don't know, you're in Palo Alto and they're in +Fremont, or whatever, and your ping times are just so fast, they're the first +ones to give you the orphans and the parents all the time. In that case, they +might be an honest peer that is using the whole orphanage, and we didn't want to +limit those peers. If there's no attackers, you have the space available, you +should be able to give the peer as much space as they are helpfully using, and +only evict when you actually reach the capacity, you actually reach the limit +that you set as the DoS limit. + +**Mark Erhardt**: Right. But if they are an honest peer that just happens to +send you a lot of orphans and resolves them, they would also reduce their memory +load again as soon as they send the parents, right? + +**Gloria Zhao**: Yes, exactly. + +**Mark Erhardt**: So, do you also track the historical record, "They sent me +orphans and resolved them", or would that maybe be part of the scoring? + +**Gloria Zhao**: We do not in this PR. So, the original idea I had was to do +this kind of token bucket mechanism, where everybody starts out with the same +number of tokens -- they're not real tokens, they're just counters, they're +integers -- tokens for how much space or how much of each metric you're allowed +to use. And then, the more useful you are, these tokens will replenish. +Whereas, if you keep sending orphans that don't end up being useful at all, then +gradually those tokens are not returned to those peers and you eventually go to +zero. + +**Mark Erhardt**: Right, but if multiple people announced to you, you'd have to +give back and call them useful announcements anyway for everyone, right? + +**Gloria Zhao**: Yeah, exactly. And it's not entirely clear how fair this is, +given that you could have policy differences with your peers, you could have +received things out of order for other reasons. Like, there are completely +benign reasons for why somebody's orphan might not pan out. And one layer +removed at just the 'how we choose our peers' layer, we have these kinds of +eviction preferences where we have a lot of inbounds, we'll rotate them. A peer +that's like never been useful to us in terms of giving transactions, we might +select them for eviction sooner than another one that we are actively having a +dialogue and giving each other useful data with. So, yeah, the token bucket +idea did not seem necessary. I think we are still thinking about potentially +having different limits for outbounds versus inbounds, just because we +inherently are much more selective and assume better behavior from outbounds, +because we choose who our outbounds are; instead of inbounds are people who +connected to us. So, we should basically assume that they're all attackers when +we're designing this data structure, whereas outbounds, we can kind of be a +little more generous towards. + +But yeah, it's a good point. There's room for I think baking in more reactivity +to different behaviors with peers. I think in terms of timers, for example, in +the transaction relay mechanisms, so not the orphanage, we could kind of give +peers more or less time to respond to things or before we retry with other +peers, for example, based on how they have responded in the past. + +**Mark Erhardt**: So, we discussed earlier that the original limit was 100,000 +vB (vbytes). And I saw in the description of the PR Review Club that now +there's a limit of 100,000 vB per peer. Does that mean that our orphanage is +now up to 12.5 MB big? + +**Gloria Zhao**: So, it's 101,000 vB per peer. Well, actually that would +translate to up to 404,000 bytes, because if it's all witness data, I mean, a +normal transaction isn't 100% witness data, but the cap is actually closer to +400 bytes in terms of memory usage. You have to add that multiplier to vbytes. +Yeah, so the potential memory usage has gone up by a little bit. So, if you +think about the original limit being 100 transactions times, let's just call it +400, you get to 40 MB. That was the original worst case, right? And now we are +doing it as a multiplier of the number of peers. So, the default is 125. It's +more like 10 if you don't do inbounds. But 125 times 404 is like, it's higher +than 40 MB, but it's only higher by a little bit. + +**Mark Erhardt**: Right. Sorry, I thought that previously the limit was 100 +transactions or 101 kilo-vbytes (kvB), but it's 100 times 101. + +**Gloria Zhao**: Yeah. + +**Mark Erhardt**: So, yeah, that used to be a little over 40 MB because of +witness data. And now, with 125 peers, so it's like a quarter more or so, +50-something MB maximum. Of course, that would be if the transactions were +completely witness data, which is unlikely, and all of our peers were filling +our orphanage, which also seems pretty unlikely, unless we're being attacked by +not just one peer. Okay, so yeah, go ahead. + +**Gloria Zhao**: I just want to add, since we're talking about memory and have +this document of a bunch of things we could do to the orphanage, and one of them +is the way that transaction data is stored in memory is pretty inefficient. +It's actually, I think, more than double what the serialized size of that +transaction could be. And of course, we have all these other data structures, +like the outpoints index that I was talking about, where I was like, in the +worst-case block, where you have like 27,000 inputs or something, this data +structure is even bigger than the main one. So, yeah, that's not the exact +number, the 50 and the 40 that we were just talking about, it's actually higher. +But we were thinking this is first of all very tolerable for how modern +computers run Bitcoin nodes today, and because it's quite similar to the +original value. But there are things that we could do to make this much more +compact. + +If we wanted to, for example, increase the limits without really increasing the +limits, we could be like, "Let's store orphans in serialized form", and build a +custom kind of shared pointer thing within the orphanage to better utilize the +space, and thus be able to increase the global limit without really increasing +the global limit. Yeah, I just wanted to add that. Might be interesting. + +**Mark Erhardt**: Okay, I have one more question. So, in the past couple +months, we've been talking a lot about different node types that may have +diverging mempool policies. So, assuming that all of the node populations were +running this new TxOrphanage, but there were two groups of nodes that had vastly +diverging mempool policies, how, would you say, does that change how +transactions get propagated on a network and may still be in the orphanage when +blocks come in or not? + +**Gloria Zhao**: So, in the singleton transactions realm, there's no difference, +because orphanage is just when you're missing inputs. So, I guess this would +mostly impact situations where you have policy differences, some nodes consider +a transaction invalid, and some nodes will reject it based on their policy and +some people accept it. Maybe these transactions get spent by unconfirmed +children, and then those are propagated to the nodes that rejected them. They +would say it's missing inputs, they would request it from the originating nodes. +Yeah, you would waste a little bit of bandwidth where you're re-downloading this +invalid transaction. And then you'd reject it immediately, because it's in your +rejections cache for not meeting policy. + +**Mark Erhardt**: Wouldn't you be able to tell that from the txid already? + +**Gloria Zhao**: No. I mean, the vast majority of transactions are segwit, +right, particularly the ones that these nodes are rejecting for policy reasons. +But this is true. + +**Mark Erhardt**: Oh my God, are you thinking of a concrete set of nodes? + +**Gloria Zhao**: Like, in the 90s% of transactions are segwit. And of course, +when you're missing an input, you only know the parent by its txid. + +**Mark Erhardt**:** **So, because the witness txid could have changed, if we +rejected something based on its witness data, we would still have to download +the same txid, because we don't know if the witness data might have changed. +There might be two ways of spending the same output, say a keypath spend and an +inscription, and we just don't like the transaction with the inscription, but +yeah, okay, I see. All right. + +**Gloria Zhao**: Yeah. But so, the good thing is that you would probably +download again but you wouldn't validate it again. So, it would be not great +for your bandwidth but, well, not 'not great', as in there would be a slight +difference in how much bandwidth is used. But because of the rejection caching +that we do, if you receive the same transaction again, you won't look at it +twice. + +**Mike Schmidt**: Is the rejection caching the same as this extra pool that I've +heard this label, or is that something different? + +**Gloria Zhao**: It's different. So, we have an extra pool which contains +transactions that we've rejected or replaced that we'll keep around just in case +they confirm in a block, and we can use that to reconstruct the compact block. +The rejections cache, we don't hold onto the transactions. It's just a rolling +Bloom filter of the wtxids of transactions that we have rejected. So, as Murch +mentioned, definitely not a txid, because that would be very problematic if +someone could send us a transaction with a different witness, we'd reject it, +and then we'd just reject all versions of that transaction by txid. So, we +throw rejected wtxids into this rolling Bloom filter. It has like a 1 in 1 +million probability of doing a false positive, but in general it's very compact +but fairly reliable for us to say like, "Hey, have I seen this transaction +before? Should I just throw it, drop it on the floor?" And so, we'll do that +to save our computation from being wasted. But like I said, that's different +from whether or not we'll redownload the transaction. + +**Mark Erhardt**: Right, so if someone could send us a transaction with a broken +witness and we would reject the txid, that would be problematic because witness +data is actually malleable. But I think we covered that earlier in this news +recap, maybe 100 episodes ago! + +**Mike Schmidt**: You and Murch talked about the size of this data structure +being capped. I also see that in the write-up for this Review Club, there's +also a limit that has been changed on the default announcement limit going from +100 to 3,000. Can you talk about the announcement limit and the rationales +behind 3,000? + +**Gloria Zhao**: Sure. So, one could say the original announcement limit, we +never enforced an announcement limit, but we allow 100 unique transactions, +right? And then, we have a set of announcers for each on master. We already +keep track of multiple announcers. And I guess, 100 times 125 is the effective +announcement limit on master, although in practice, I imagine must be a lot +lower. So, yeah, with the worst-case scenario I mentioned before, which is that +all of the oldest transactions from every peer is a duplicate of another +announcement from another peer, then we're going to be erasing, like we always +pick the DoSsiest peer, right? We evict one. Then we pick the next DoSsiest +peer, we evict one. And then we're just evicting round robin until we get to +the very last transactions, and we finally find one that's unique, and we +actually can free up memory by deleting this transaction. This is kind of the +worst-case scenario we can contrive for the new eviction policy. + +So, it would be pretty bad if we had no announcement limit. It probably +wouldn't happen in practice, but we could have this really, really awful +pathological case. And so, basically what we did was we wrote a benchmark for +this, and we used 125, I think we used 125; we used a realistic number of peers +and then we benchmarked the worst case to fit within our memory limits, but to +see what is the overall latency of this worst-case scenario. And we basically +wanted to bring it to a millisecond or a couple of milliseconds. That seemed +acceptable for something that can happen very regularly within one message that +you process from a peer on the P2P network. And then, we also tried to create a +nice, easy-to-reason-about limit per peer. And so, what we came up with was 24 +per peer at a time, unique, so total 3,000 if you have 125 peers. And the 24 is +like this magical number where if we think about the worst-case, single, honest +transaction that you might be working on with a peer, what's the most amount of +missing inputs transactions you might have with this peer that's relevant to one +transaction, and that's 24. So, you have like this one missing transaction and +then 24 transactions that spend from it. That's the default policy limit, is a +descendant package of size 25. + +So, this kind of neatly encompassed like, "Okay, everybody can be announcing one +descendant package guaranteed at a time". And also, if we have this crazy +scenario where everybody has the exact same thing except for the last couple +transactions, it would take us less than a few milliseconds to actually run this +eviction algorithm. + +**Mark Erhardt**: So, of course, if you had a transaction with 24 parents and +one child, that would still also be in the current ancestor limit. But would we +ever then ask back for all 24 parents? + +**Gloria Zhao**: No, because the child is the only one that can possibly be +missing unconfirmed inputs. + +**Mark Erhardt**: No, sorry. Someone announces an orphan to me and it has 24 +unknown inputs. Would I ask for all 24 inputs, the parent transactions? + +**Gloria Zhao**: Yes. + +**Mark Erhardt**: Okay. But do we then also submit that as a package? I +thought it was only for 1p1c. + +**Gloria Zhao**: No. So, orphan resolution has existed a long time before 1p1c +has. The 1p1c logic is just specifically for the case where the parents are low +feerate. So, the network doesn't really have any support for 24 parents being +bumped by one child. It's just, if you just came out of IBD and these 24 +parents had been circulated a few minutes ago, and somebody spends from all of +them and you receive a child and you're like, "Oh, sorry guys, I wasn't here +when you guys broadcast the parents, could you just send them to me please?" +That's a scenario that's been around for a really long time. So, yeah, if all +of them are low feerate, we're out of luck, sorry. Still working on the +arbitrary package validation stuff. But if it's just 1p1c, then… + +**Mark Erhardt**: So, if 23 are high feerate and one is low feerate, it will +still work? + +**Gloria Zhao**: Unfortunately not, but I have a PR that disables that stupid +restriction. It truly is an unnecessary restriction that was put in there in +2022, or something. I had a PR out for like a year to remove it. But yeah, if +you want to review that, that'd be great. + +**Mark Erhardt**: All right, so these are all my questions. Back to you, Mike. +Yeah, I think we did a good job diving deep and it's great. I mean, that's a PR +Review Club, that's what we're supposed to do. Gloria, is there anything that +you'd want to say to tie all of this work on the orphanage lately? The +orphanage has become more of a load-bearing data structure than it has in the +past. Do you want to tie that back to the work that you're doing in this bigger +picture that you mentioned earlier in the chat on package relay? Maybe just +spell out, why exactly is the orphanage becoming so load-bearing recently? + +**Gloria Zhao**: Yeah, I like the term 'load-bearing'. I think that's a good +way to describe it. I feel the same way about the extra pools. We have these +opportunistic data structures. Yeah, they're best effort, but unfortunately, +completely unreliable. And while we can't make them completely robust, like +100% guaranteed, whatever, we can do a lot better than just 100 and you evict +one. Yeah, so in the greater package relay kind of picture, package relay is +all about making transaction relay more efficient, and the P2P marketplace of +transaction broadcast an efficient one. And I think package relay, as written +in the BIP, has a couple different use cases. One is to try to get rid of +txid-based relay, which we talked about, actually about witness malleation, why +trying to talk about transactions with your peers using the txid relay is really +problematic, because it's not specific enough for you to really be able to not +have to re-download things over and over again. Because if it's by txid, you +have to basically always be optimistic that this time I download it, it will be +a valid version of it. But if peers only talk to each other via wtxid, then you +wouldn't have this problem. + +So, that's one use case of package relay, which requires the orphanage. And +that's why it's so relevant to package relay is… sorry, orphan resolution right +now is the only time that we need to talk about txids in the transaction relay +functionality of peers. It's the only time we still use it. But if we were to +just have a protocol where we asked people, "Hey, can you give me the ancestors, +but do it by wtxid? I know what the txids are and I know I'm missing at least n +of them. Can you just tell me the wtxids, and then I'll work on downloading +those?" + +Then, the other one is for fee bumping, right? We have this very deep-rooted +limitation where, because we don't analyze packages at a time, we miss +transactions that are going to be bumped but aren't enough by themselves. And +that's also, as we've implemented it today, this situation where we're reactive, +right? We're like, "Hey, I got a low-feerate transaction, I'm missing +something", or, "I got an orphan transaction. It must be bumping something, but +I'm missing that data". Being able to store that in this load-bearing data +structure makes all this way, way more reliable. And so, orphan resolution is +something that makes package relay so, so, so much more useful. And I had been +thinking of it as like a nice-to-have after package relay, but it really does +change the game, I think, if you're able to guarantee that you're going to +remember at least a few transactions per peer, because the nature of package +relay is you have to remember something. It's like you have a transaction that +requires something else, whether it's a bumping thing or if it's a missing +parent. Having this place to store unvalidated data is really useful. And so, +all of these changes that we're making are very useful to package relay. And I +think after this is done, we're basically going to be working on arbitrary +package validation. And then, hopefully we can get something a lot bigger than +1p1c in a year's time. + +**Mike Schmidt**: Excellent. Murch, anything else before we wrap up PR review? +Gloria, thank you for joining. I think this was much more productive with you +joining us than me and Murch worrying about having to do this without you, so +thank you for your time. + +**Gloria Zhao**: Thanks so much for having me. + +_LND v0.19.2-beta.rc2_ + +**Mike Schmidt**: Cheers. Releases and release candidates. We have LND +v0.19.2-beta.rc2. I think the rc1 also came out late last week, but I don't +think that we covered it in the newsletter. This rc2 includes ten bug fixes. +It also adds support in LND for testnet4 and signet peer seed services. So, +previously they had testnet and mainnet, but not testnet4 and signet. So, you +can now find peers in LND that way. It also adds a database cleanup that will, +"Lower disk and memory requirements for nodes significantly". So, that's an +optional database migration. And then, there's also other features as well. +So, check out the Release Notes for details on those ten bug fixes and those +other features. + +_Core Lightning #8377_ + +Notable code and documentation changes. Core Lightning #8377. This is a PR +that implements some of the recent changes to the BOLT spec that we covered +previously. The first change to the BOLT spec implemented here is the change to +make the payment secret field, which is s, mandatory in BOLT11 invoices. The +advantage of that is that it prevents payment probing attacks by requiring all +invoices to include those payment secrets. We covered that change to the BOLT +repository, which #1242, and that was in Newsletter #350. And then, the second +change is that Core Lightning (CLN) will now enforce that a sender must not pay +a BOLT11 invoice if a mandatory field has an incorrect length. And this change +was in the BOLTs PR #1243, and it clarified that a mandatory field that is +present but has an incorrect length, that the invoice should actually be failed +instead of skipping that field. Previously, it was ambiguous about how that +should be handled. Yeah, go ahead, Murch. + +**Mark Erhardt**: I was wondering, you said that this changes probing. How does +it change probing? Did you read more up on that? + +**Mike Schmidt**: So, the requirement that all invoices include payment secrets. +Now, if you double-click on that, I return null, I don't have an answer for why +those payment secrets prevent probing attacks. + +**Mark Erhardt**: So, I think the payment secret would only become relevant in +the last hop, where the recipient receives the multi-hop contract, and then they +would parse out the innermost onion. + +**Mike Schmidt**: Sorry, there's a piece from the PR that I can pull out, "The +payment secret prevents intermediate nodes in the payment path from probing for +the destination by generating their own payment onions". + +**Mark Erhardt**: Okay, so if an intermediate node malleates the multi-hop +payment, they can learn something. I was going to say, if the sender is +probing, often they will try to find information about an intermediate hop, and +they would learn whether the intermediate hop has sufficient funds to forward by +whether or not the probe passes the intermediate node and comes back from +downstream, or is returned by the intermediate node. So, I was surprised that +it would affect probing. But yeah, so if it means that the intermediate hub is +malleating something and then checking whether the neighbor is the recipient, +that would make more sense. + +**Mike Schmidt**: Yeah. And that last component of the BOLT11 invoice changes, +about the mandatory field being present and having to have the correct length +and not just skipping that field, we talked about that. That was in Newsletter +and Podcast #358. + +_BDK #1957_ + +BDK1957#. This PR improves the performance of syncing and full scans when using +the Electrum backend. Specifically, the full scan time was cut by about 50%, +and those performance improvements were achieved by a combination of batching +RPC calls and also caching certain RPC calls, which cut down on the network +traffic, the need to round-trip, while also eliminating any redundant work as +well. So, a performance optimization there if you're using Electrum as your +backend. + +_BIPs #1888_ + +BIPs #1888, this harkens back to some discussions we've had recently, one in +Newsletter #360, talking about H, as the capital H, as the hardened derivation +path marker in BIP380. Murch, as our resident BIP editor, what's going on here? + +**Mark Erhardt**: Okay, so 380 is a BIP that deals with descriptors and +specifically with, I think, derivation from various types of descriptors. And +originally, BIP380 introduced capital H as a second alternative for the hardened +derivation marker. So, hardened derivation is a derivation step where you need +to have the private key in order to derive the child, rather than unhardened +where you simply need the public key in order to derive a child. So, for +example, if you have an xpub and it has a hardened derivation step below, those +additional keys cannot be derived by other people that only know the xpub; they +need the private key. Traditionally, the marker to symbolize that was a single +quotation mark. And now, of course, with strings, the quotation mark often +delimits the end of a string. And this is sort of an RPC interface hazard, +because if people put their string arguments or parameters for RPC calls in +single quotes instead of double quotes, the single quote, as a hardened +derivation marker, would end the string there, so it has to be escaped. And I +think a lot of people struggle with the RPC for what exactly needs to be escaped +and what doesn't. + +So, I believe the lowercase h was introduced as an alternative hardened +derivation marker, in order to make this problem go away, where we don't delimit +strings accidentally with single quotation marks. I don't exactly know how the +uppercase H came to pass, but it might be because people were thinking about QR +codes being more efficiently encodable if you have only numbers and uppercase +letters. And that was also what I was bringing up with Josh earlier. So, +there's a different QR code encoding mode that has a smaller alphabet, so it +makes more compact QR codes, ie the grid is smaller in the QR code, which means +that it's easier to scan. So, that uses only uppercase and maybe people were +thinking about, "Well, eventually output script descriptors might be represented +as QR codes for import or export. And in that case, we might want to be able to +use uppercase". + +However, there was an inconsistency where the test vectors forbid uppercase H, +but the text of the BIP specifically introduced it as a second alternative +hardened derivation marker. So, this was recently fixed when someone discovered +it. And specifically, this is now fixed, because apparently nobody has been +implementing the uppercase H as a hardened derivation marker, and so it is just +being dropped; you don't use the uppercase H anymore. If your implementation or +project handles this differently, there was a discussion on the mailing list, +and I know that we've also relayed the message here before. If someone is using +uppercase H as the hardened derivation marker, please speak up, because +otherwise this is dropped from the BIP now. And yeah, well, at least Bitcoin +Core and Rust miniscript do not do it right now, so, to our knowledge, we are +safe to drop it. Anyway, this is just to bring everything into consistency and +make it a little simpler. And if that doesn't affect you, that's fine. + +**Mike Schmidt**: Yeah, reach out if it does. I believe there was a +mailing-list post on it and we obviously reference the newsletter where we +talked about that, and we have the BIPs #1888 here for you to come squeal. +Thanks for summarizing that, Murch. Thank you to our guests, Gloria and Josh, +and my co-host, Murch, and you all for listening. Cheers. + +**Mark Erhardt**: Cheers. {% include references.md %} From c2f5ee911863a5b3db36697b7bb787d7e8baec6f Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Tue, 22 Jul 2025 21:31:53 -1000 Subject: [PATCH 168/278] Newsletters: add 364 (2025-07-25) --- .../en/newsletters/2025-07-25-newsletter.md | 143 ++++++++++++++++++ 1 file changed, 143 insertions(+) create mode 100644 _posts/en/newsletters/2025-07-25-newsletter.md diff --git a/_posts/en/newsletters/2025-07-25-newsletter.md b/_posts/en/newsletters/2025-07-25-newsletter.md new file mode 100644 index 0000000000..f06ca578a3 --- /dev/null +++ b/_posts/en/newsletters/2025-07-25-newsletter.md @@ -0,0 +1,143 @@ +--- +title: 'Bitcoin Optech Newsletter #364' +permalink: /en/newsletters/2025/07/25/ +name: 2025-07-25-newsletter +slug: 2025-07-25-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter summarizes a vulnerability affecting old versions +of LND, describes an idea for improving privacy when using co-signer +services, and examines the impact of switching to quantum-resistant +signature algorithms on HD wallets, scriptless multisig, and silent +payments. Also included are our regular sections summarizing popular +questions and answers on the Bitcoin Stack Exchange, announcing new +releases and release candidates, and describing notable changes to +popular Bitcoin infrastructure software. + +## News + +- **LND gossip filter DoS vulnerability:** Matt Morehouse + [posted][morehouse gosvuln] to Delving Bitcoin about a vulnerability + affecting past versions of LND that he previously [responsibly + disclosed][topic responsible disclosures]. An attacker could + repeatedly request historic gossip messages from an LND node until it + ran out of memory and was terminated. The vulnerability was fixed in + LND 0.18.3, released September 2024. + +- **Chain code withholding for multisig scripts:** Jurvis Tan + [posted][tan ccw] to Delving Bitcoin about research he performed with + Jesse Posner into improving the privacy and security of multisig + collaborative custody. In a typical collaborative custody service, a + 2-of-3 multisig may be used with the three keys being: + + - A user _hot key_ that is stored on a networked device and signs + transactions for the user (either manually or through software + automation). + + - A provider hot key that is stored on a separate networked device + under the exclusive control of the provider. The key only signs + transactions according to a policy previously defined by the user, + such as only allowing spending up to _x_ BTC a day. + + - A user _cold key_ that is stored offline and is only used if either + the user hot key is lost or the provider ceases signing authorized + transactions. + + Although the above configuration can provide a significant boost to + security, the setup method almost always used involves the user + sharing with the provider the [BIP32 extended public keys][topic + bip32] for the user's hot and cold wallets. This allows the + provider to detect all funds received by the user's wallet and to track + all spends of those funds even if the user spends without provider + assistance. Several ways to mitigate this privacy loss have + previously been described, but they are either incompatible with + typical use (e.g. using separate tapleaves) or complex (e.g. requiring + [MPC][]). Tan and Posner describe a simple alternative: + + - The provider generates half of a BIP32 HD extended key (just + the key part). They give the public key to the user. + + - The user generates the other half (the chain code). They keep this + private. + + When receiving funds, the user can combine the two halves to create an + extended public key (xpub) and then derive multisig addresses as + usual. The provider doesn't know the chain code, preventing them + from deriving the xpub or discovering the address. + + When spending funds, the user can derive from the chain code the + necessary _tweak_ that the provider needs to combine with their + private key to create a valid signature. They simply share + this tweak with the provider. The provider can't learning anything + from the tweak except that it's valid for spending from the specific + scriptPubKey that received funds. + + Some providers may require that the change output for a spending + transaction sends the money back to the same script template. Tan's + post describes how this can easily be accomplished. + +- **Research indicates common Bitcoin primitives are compatible with quantum-resistant signature algorithms:** + Jesse Posner [posted][posner qc] to Delving Bitcoin several links to + research papers that indicate that [quantum-resistant][topic quantum + resistance] signature algorithms provide comparable primitives to + those currently used in Bitcoin for [BIP32 HD wallets][topic bip32], + [silent payment addresses][topic silent payments], [scriptless + multisignatures][topic multisignature], and [scriptless threshold + signatures][topic threshold signature]. + +## Selected Q&A from Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] is one of the first places Optech +contributors look for answers to their questions---or when we have a +few spare moments to help curious or confused users. In +this monthly feature, we highlight some of the top-voted questions and +answers posted since our last update.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +FIXME:bitschmidty + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [Libsecp256k1 v0.7.0][] is a release of this library containing + cryptographic primitives compatible with Bitcoin. It contains a few + small changes that break API/ABI compatibility with previous releases. + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [Bitcoin Core #32521][] policy: make pathological transactions packed with legacy sigops non-standard + +- [Bitcoin Core #31829][] p2p: improve TxOrphanage denial of service bounds + +- [LDK #3801][] joostjager/fulfill-hold-times + +- [LDK #3842][] Add Shared Input support in interactive TX construction + +- [BIPs #1890][] Specify lexicographical order for fragment params + +- [BOLTs #1232][] Add `channel_type` context to Bolt9 + +{% include snippets/recap-ad.md when="2025-07-29 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32521,31829,3801,3842,1890,1232" %} +[morehouse gosvuln]: https://delvingbitcoin.org/t/disclosure-lnd-gossip-timestamp-filter-dos/1859 +[tan ccw]: https://delvingbitcoin.org/t/chain-code-delegation-private-access-control-for-bitcoin-keys/1837 +[mpc]: https://en.wikipedia.org/wiki/Secure_multi-party_computation +[posner qc]: https://delvingbitcoin.org/t/post-quantum-hd-wallets-silent-payments-key-aggregation-and-threshold-signatures/1854 +[Libsecp256k1 v0.7.0]: https://github.com/bitcoin-core/secp256k1/releases/tag/v0.7.0 From 14635e786d80baba1964e002a051291617495cc9 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Wed, 23 Jul 2025 10:02:49 -0500 Subject: [PATCH 169/278] News364: add stack exchange --- _posts/en/newsletters/2025-07-25-newsletter.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2025-07-25-newsletter.md b/_posts/en/newsletters/2025-07-25-newsletter.md index f06ca578a3..d1215a82d2 100644 --- a/_posts/en/newsletters/2025-07-25-newsletter.md +++ b/_posts/en/newsletters/2025-07-25-newsletter.md @@ -98,7 +98,18 @@ answers posted since our last update.* {% comment %}{% endcomment %} {% assign bse = "https://bitcoin.stackexchange.com/a/" %} -FIXME:bitschmidty +- [How does Bitcoin Core handle reorgs larger than 10 blocks?]({{bse}}127512) + TheCharlatan links to Bitcoin Core code that handles chain reorganizations by + only re-adding a maximum of 10 blocks worth of transactions to the mempool. + +- [Advantages of a signing device over an encrypted drive?]({{bse}}127596) + RedGrittyBrick points out that data on an encrypted drive can be extracted + while the drive is unencrypted whereas hardware signing devices are designed to + prevent this data extraction attack. + +- [Spending a taproot output through the keypath and scriptpath?]({{bse}}127601) + Antoine Poinsot details how the use of merkle trees, key tweaks, and leaf + scripts achieve taproot's keypath and scriptpath spending capabilities. ## Releases and release candidates From 9a00a8c5a1ea44472ea804680f6c683ebe6c86c6 Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 24 Jul 2025 09:34:02 +0000 Subject: [PATCH 170/278] News364: add merge summaries --- .../en/newsletters/2025-07-25-newsletter.md | 63 +++++++++++++++---- 1 file changed, 51 insertions(+), 12 deletions(-) diff --git a/_posts/en/newsletters/2025-07-25-newsletter.md b/_posts/en/newsletters/2025-07-25-newsletter.md index d1215a82d2..4f865fc71c 100644 --- a/_posts/en/newsletters/2025-07-25-newsletter.md +++ b/_posts/en/newsletters/2025-07-25-newsletter.md @@ -109,7 +109,7 @@ answers posted since our last update.* - [Spending a taproot output through the keypath and scriptpath?]({{bse}}127601) Antoine Poinsot details how the use of merkle trees, key tweaks, and leaf - scripts achieve taproot's keypath and scriptpath spending capabilities. + scripts achieves taproot's keypath and scriptpath spending capabilities. ## Releases and release candidates @@ -132,17 +132,49 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Bitcoin Core #32521][] policy: make pathological transactions packed with legacy sigops non-standard - -- [Bitcoin Core #31829][] p2p: improve TxOrphanage denial of service bounds - -- [LDK #3801][] joostjager/fulfill-hold-times - -- [LDK #3842][] Add Shared Input support in interactive TX construction - -- [BIPs #1890][] Specify lexicographical order for fragment params - -- [BOLTs #1232][] Add `channel_type` context to Bolt9 +- [Bitcoin Core #32521][] makes legacy transactions with more than 2500 + signature operations (sigops) non-standard in preparation for a potential + [consensus cleanup soft fork][topic consensus cleanup] upgrade that would + enforce the limit at the consensus level. If the softfork took place without + this change, miners who don’t upgrade could become targets of trivial DoS + attacks. See Newsletter [#340][news340 sigops] for additional details on the + legacy input sigops limit. + +- [Bitcoin Core #31829][] adds resource limits to the orphan transaction + handler, `TxOrphanage` (See Newsletter [#304][news304 orphan]), to preserve + opportunistic one-parent-one-child (1p1c) [package relay][topic package relay] + in the face of DoS spam attacks. Four limits are enforced: a global cap + of 3,000 orphan announcements (to minimize CPU and latency cost), a proportional per‑peer + orphan announcements cap, a per‑peer weight reservation of 24 × 400 kWU, and a + variable global memory cap. When any limit is exceeded, the node evicts the + oldest orphan announcement from the peer that has used the most CPU or memory + relative to its allowance (highest Peer DoS Score). The PR also deletes the + `‑maxorphantxs` option (default 100), whose policy of evicting random + announcements allowed attackers to replace the entire orphan set and render + [1p1c relay][1p1c relay] useless. See also [Newsletter #362][news362 + orphan]. + +- [LDK #3801][] extends [attributable failures][topic attributable failures] to + the payment success path by recording how long a node holds an [HTLC][topic + htlc] and propagating those hold‑time values upstream in the attribution + payload. Previously, LDK only tracked hold times for failed payments (see + Newsletter [#349][news349 attributable]). + +- [LDK #3842][] extends its [interactive transaction construction][topic dual + funding] state machine (See Newsletter [#295][news295 dual]) to handle the + signing coordination for shared inputs in [splicing][topic splicing] + transactions. The `prevtx` field of the `TxAddInput` message is made optional + to reduce memory usage and simplify validation. + +- [BIPs #1890][] changes the separator parameter from `+` to `-` in [BIP77][] + because some HTML 2.0 URI libraries treat `+` as if it is a blank space. In + addition, fragment parameters must now be ordered lexicographically, rather + than in reverse, to simplify the async [payjoin][topic payjoin] protocol. + +- [BOLTs #1232][] makes the `channel_type` field (see Newsletter [#165][news165 + type]) mandatory when opening a channel because every implementation enforces + it. This PR also updates [BOLT9][] by adding a new context type `T` for + features that can be included in the `channel_type` field. {% include snippets/recap-ad.md when="2025-07-29 16:30" %} {% include references.md %} @@ -152,3 +184,10 @@ repo], and [BINANAs][binana repo]._ [mpc]: https://en.wikipedia.org/wiki/Secure_multi-party_computation [posner qc]: https://delvingbitcoin.org/t/post-quantum-hd-wallets-silent-payments-key-aggregation-and-threshold-signatures/1854 [Libsecp256k1 v0.7.0]: https://github.com/bitcoin-core/secp256k1/releases/tag/v0.7.0 +[news340 sigops]: /en/newsletters/2025/02/07/#introduce-legacy-input-sigops-limit +[news304 orphan]: /en/newsletters/2024/05/24/#bitcoin-core-30000 +[1p1c relay]: /en/bitcoin-core-28-wallet-integration-guide/#one-parent-one-child-1p1c-relay +[news349 attributable]: /en/newsletters/2025/04/11/#ldk-2256 +[news295 dual]: /en/newsletters/2024/03/27/#ldk-2419 +[news165 type]: /en/newsletters/2021/09/08/#bolts-880 +[news362 orphan]: /en/newsletters/2025/07/11/#bitcoin-core-pr-review-club From f271caccb6716a048cf18456e244d5028cf137e0 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Fri, 25 Jul 2025 06:46:08 -0500 Subject: [PATCH 171/278] News364: add topics --- _topics/en/attributable-failures.md | 3 +++ _topics/en/consensus-cleanup-soft-fork.md | 3 +++ _topics/en/hd-key-generation.md | 3 +++ _topics/en/package-relay.md | 3 +++ _topics/en/quantum-resistance.md | 3 +++ _topics/en/responsible-disclosures.md | 3 +++ 6 files changed, 18 insertions(+) diff --git a/_topics/en/attributable-failures.md b/_topics/en/attributable-failures.md index 0c60d34a26..799dd55cb1 100644 --- a/_topics/en/attributable-failures.md +++ b/_topics/en/attributable-failures.md @@ -47,6 +47,9 @@ optech_mentions: - title: "LDK #3868 reduces the precision of HTLC hold time for attributable failures from 1ms to 100ms units" url: /en/newsletters/2025/06/27/#ldk-3868 + - title: "LDK #3801 extends attributable failures to the payment success path" + url: /en/newsletters/2025/07/25/#ldk-3801 + ## Optional. Same format as "primary_sources" above # see_also: # - title: diff --git a/_topics/en/consensus-cleanup-soft-fork.md b/_topics/en/consensus-cleanup-soft-fork.md index 25363d78e2..12dd982405 100644 --- a/_topics/en/consensus-cleanup-soft-fork.md +++ b/_topics/en/consensus-cleanup-soft-fork.md @@ -71,6 +71,9 @@ optech_mentions: - title: "BIPs #1760 merges BIP53, which specifies a consensus change to forbid 64 byte transactions" url: /en/newsletters/2025/05/30/#bips-1760 + - title: "Bitcoin Core #32521 makes legacy transactions with more than 2500 sigops non-standard" + url: /en/newsletters/2025/07/25/#bitcoin-core-32521 + ## Optional. Same format as "primary_sources" above see_also: - title: Soft fork activation diff --git a/_topics/en/hd-key-generation.md b/_topics/en/hd-key-generation.md index a0b0c4196e..587d8c5f9f 100644 --- a/_topics/en/hd-key-generation.md +++ b/_topics/en/hd-key-generation.md @@ -93,6 +93,9 @@ optech_mentions: - title: "Proposed scheme to prevent BIP32 path reuse to avoid output linking and other problems" url: /en/newsletters/2025/05/09/#avoiding-bip32-path-reuse + - title: "Chain code withholding to improve privacy when using co-signer services" + url: /en/newsletters/2025/07/25/#chain-code-withholding-for-multisig-scripts + ## Optional. Same format as "primary_sources" above see_also: - title: Output script descriptors diff --git a/_topics/en/package-relay.md b/_topics/en/package-relay.md index 050f8db225..0746227d18 100644 --- a/_topics/en/package-relay.md +++ b/_topics/en/package-relay.md @@ -137,6 +137,9 @@ optech_mentions: - title: "Eclair #2963 implements one-parent-one-child (1p1c) package relay" url: /en/newsletters/2025/04/04/#eclair-2963 + - title: "Bitcoin Core #31829 limits orphan transaction relay to preserve 1p1c package relay from DoS attacks" + url: /en/newsletters/2025/07/25/#bitcoin-core-31829 + ## Optional. Same format as "primary_sources" above see_also: - title: CPFP fee bumping diff --git a/_topics/en/quantum-resistance.md b/_topics/en/quantum-resistance.md index e9e66fe323..92c8f1f5d6 100644 --- a/_topics/en/quantum-resistance.md +++ b/_topics/en/quantum-resistance.md @@ -82,6 +82,9 @@ optech_mentions: - title: "Commit/reveal function for post-quantum recovery of insecure bitcoins" url: /en/newsletters/2025/07/04/#commit-reveal-function-for-post-quantum-recovery + - title: "Research indicates many Bitcoin primitives are compatible with quantum-resistant signatures" + url: /en/newsletters/2025/07/25/#research-indicates-common-bitcoin-primitives-are-compatible-with-quantum-resistant-signature-algorithms + ## Optional. Same format as "primary_sources" above see_also: - title: Taproot diff --git a/_topics/en/responsible-disclosures.md b/_topics/en/responsible-disclosures.md index c66d38570d..cabf028adb 100644 --- a/_topics/en/responsible-disclosures.md +++ b/_topics/en/responsible-disclosures.md @@ -167,6 +167,9 @@ optech_mentions: - title: "Ruben Somsen responsibly disclosed a theoretical BIP30 consensus failure vulnerability" url: /en/newsletters/2025/05/09/#bip30-consensus-failure-vulnerability + - title: "Matt Morehouse responsibly disclosed a DoS vulnerability affecting LND" + url: /en/newsletters/2025/07/25/#lnd-gossip-filter-dos-vulnerability + ## Optional. Same format as "primary_sources" above see_also: - title: "Common Vulnerabilities and Exposures (CVEs)" From 98ff6da205b8388bd3b75236f152dcab953e38e5 Mon Sep 17 00:00:00 2001 From: shigeyuki azuchi Date: Sat, 26 Jul 2025 21:03:19 +0900 Subject: [PATCH 172/278] Newsletter-364:Translate into Japanese (#2428) --- .../ja/newsletters/2025-07-25-newsletter.md | 162 ++++++++++++++++++ 1 file changed, 162 insertions(+) create mode 100644 _posts/ja/newsletters/2025-07-25-newsletter.md diff --git a/_posts/ja/newsletters/2025-07-25-newsletter.md b/_posts/ja/newsletters/2025-07-25-newsletter.md new file mode 100644 index 0000000000..b847bb38f8 --- /dev/null +++ b/_posts/ja/newsletters/2025-07-25-newsletter.md @@ -0,0 +1,162 @@ +--- +title: 'Bitcoin Optech Newsletter #364' +permalink: /ja/newsletters/2025/07/25/ +name: 2025-07-25-newsletter-ja +slug: 2025-07-25-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、旧バージョンのLNDに影響する脆弱性の概要と、 +共同署名サービス利用時のプライバシーの向上策、量子耐性署名アルゴリズムへの移行が +HDウォレットやスクリプトレスマルチシグ、サイレントペイメントに与える影響について掲載しています。 +また、Bitcoin Stack Exchangeで人気の質問とその回答や、新しいリリースとリリース候補の発表、 +人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき更新に関する恒例のセクションも含まれています。 + +## ニュース + +- **LNDのゴシップフィルターのDoS脆弱性:** Matt Morehouseは、 + 以前[責任を持って開示した][topic responsible disclosures]LNDの旧バージョンに影響する脆弱性について、 + Delving Bitcoinに[投稿しました][morehouse gosvuln]。攻撃者は、 + LNDノードがメモリ不足に陥って終了するまで、過去のゴシップメッセージを繰り返し要求することができました。 + この脆弱性は、2024年9月にリリースされたLND 0.18.3で修正されました。 + +- **マルチシグスクリプトのためのチェーンコードの秘匿:** + Jurvis Tanは、Jesse Posnerと共同で行ったマルチシグ共同カストディのプライバシーとセキュリティ向上に関する研究について + Delving Bitcoinに[投稿しました][tan ccw]。一般的な共同カストディサービスでは、 + 以下の３つの鍵を用いた2-of-3のマルチシグが使用されます: + + - ユーザーの _ホットキー_：ネットワーク接続されたデバイスに保存され、 + ユーザーのためにトランザクションに署名します（手動またはソフトウェアにより自動で） + + - プロバイダーのホットキー：プロバイダーが排他的に管理する別のネットワーク接続デバイスに保存されています。 + この鍵は１日に _x_ BTCまでの支払いのみを許可するなど、ユーザが事前に定義したポリシーに従ってトランザクションに署名します。 + + - ユーザーの _コールドキー_：オフラインで保存され、ユーザーのホットキーが失われた場合、 + またはプロバイダーが承認されたトランザクションへの署名を停止した場合にのみ使用されます。 + + 上記の構成は、セキュリティを大幅に強化できますが、ほとんどの場合、 + ユーザーがプロバイダーとユーザーのホットウォレットとコールドウォレットの + [BIP32拡張公開鍵][topic bip32]を共有するという設定方法が採用されています。 + これにより、プロバイダーはユーザーのウォレットに入金されたすべての資金を検出し、 + ユーザーがプロバイダーの支援なしに支払いをした場合でも、それらの資金のすべての支払いを追跡できます。 + このプライバシーの損失を軽減する方法は、これまでにいくつか提案されていますが、 + それらは通常の用途には適さない（例：個別のtapleafを使用する）か、 + 複雑（例：[MPC][]を必要とする）です。TanとPosnerは、シンプルな代替案を説明しています: + + - プロバイダーはBIP32HD拡張鍵の半分（鍵部分）のみを生成し、公開鍵をユーザーに渡します。 + + - ユーザーは残りの半分（チェーンコード）を生成し、これは秘密にしておきます。 + + 資金を受け取る際は、ユーザーは２つのパーツを組み合わせて拡張公開鍵（xpub）を作成し、 + 通常どおりマルチシグアドレスを導出します。プロバイダーはチェーンコードを知らないため、 + xpubを導出したりアドレスを発見することはできません。 + + 資金を使用する際は、ユーザーはチェーンコードから必要な _調整値_ を導出します。 + プロバイダーは、この調整値を秘密鍵と組み合わせて有効な署名を作成します。 + ユーザーは単にこの調整値をプロバイダーと共有するだけです。プロバイダーは、 + 調整値が資金を受け取った特定のscriptPubKeyからの支払いに有効であるということ以外、 + 調整値から何も知ることはできません。 + + 一部のプロバイダーは、支払いトランザクションのお釣り用のアウトプットで、 + 資金を同じスクリプトテンプレートに送り返すよう要求する場合があります。 + Tanの投稿では、これを簡単に実現する方法が説明されています。 + +- **研究によりBitcoinの一般的なプリミティブが量子耐性署名アルゴリズムと互換性があることが示される:** + Jesse Posnerは、[量子耐性][topic quantum resistance]署名アルゴリズムが、 + 現在Bitcoinで使用されている[BIP32 HDウォレット][topic bip32]、[サイレントペイメントアドレス][topic silent payments]、 + [スクリプトレスマルチシグアドレス][topic multisignature]、 + [スクリプトレス閾値署名][topic threshold signature]と同等のプリミティブを提供することを示す研究論文のいくつかのリンクを + Delving Bitcoinに[投稿しました][posner qc]。 + +## Bitcoin Stack Exchangeから選ばれたQ&A + +*[Bitcoin Stack Exchange][bitcoin.se]はOptech Contributor達が疑問に対して答えを探しに（もしくは他のユーザーの質問に答える時間がある場合に）アクセスする、 +数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Bitcoin Coreは、10ブロックを超える再編成をどのように処理しますか？]({{bse}}127512) + TheCharlatanは、最大10ブロック分のトランザクションのみをmempoolに再追加することでチェーンの再編成を処理する + Bitcoin Coreのコードのリンクを提供しています。 + +- [暗号化ドライブと比較した署名デバイスの利点は何ですか？]({{bse}}127596) + RedGrittyBrickは、暗号化ドライブ上のデータは暗号化されていない状態でも抽出可能であるのに対し、 + ハードウェア署名デバイスはこのようなデータ抽出攻撃を防ぐように設計されていると指摘しています。 + +- [Taprootアウトプットはkeypathとscriptpathを介して使用できる？]({{bse}}127601) + Antoine Poinsotは、マークルツリー、鍵の調整、リーフスクリプトを使用して + どのようにTaprootのkeypath支払いとscriptpath支払いが実現されているかを詳しく説明しています。 + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [Libsecp256k1 v0.7.0][]は、Bitcoinと互換性のある暗号プリミティブを含むこのライブラリのリリースです。 + これまでのリリースとのAPI/ABI互換性を損なういくつかのの小さな変更が含まれています。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Bitcoin Core #32521][]は、2500を超える署名操作（sigops）を含むレガシートランザクションを非標準とします。 + これは、[コンセンサスクリーンアップソフトフォーク][topic consensus cleanup]のアップグレードによって + コンセンサスレベルで制限が適用される可能性があるためです。この変更なしにソフトフォークが行われた場合、 + アップグレードを行っていないマイナーは軽微なDoS攻撃の標的になる可能性があります。 + レガシーインプットのsigops制限の詳細については、ニュースレター[#340][news340 sigops]をご覧ください。 + +- [Bitcoin Core #31829][]は、オーファントランザクションハンドラーである`TxOrphanage`（ニュースレター + [#304][news304 orphan]参照）にリソース制限を追加し、DoSスパム攻撃に対しても + 1P1C（one-parent-one-child）[パッケージリレー][topic package relay]を維持します。 + 適用される制限は４つあります。（CPUと遅延コストを最小化するための）3,000オーファンアナウンスのグローバル上限、 + ピアごとのオーファンアナウンスの比例上限、ピアごとの 24 × 400 kWUの予約ウェイト、 + 可変のグローバルメモリ上限です。いずれかの制限を超えると、ノードは、 + 許容量と比較して最も多くのCPUまはたメモリを使用した（ピアDoSスコアが最も高い）ピアから、 + 最も古いオーファンアナウンスを削除します。またこのPRでは、 + ランダムにアナウンスを削除するポリシーが、オーファンセット全体を置き換えることで[1P1Cリレー][1p1c relay]を無効にすることを可能にしていた + `‑maxorphantxs`オプション（デフォルト 100）を削除します。[ニュースレター #362][news362 + orphan]もご覧ください。 + +- [LDK #3801][]は、ノードが[HTLC][topic htlc]を保持している時間を記録し、 + その保持期間値を[失敗の帰属][topic attributable failures]のペイロードの上流に伝播するすることで、 + 支払い成功パスに失敗の帰属を拡張します。これまでは、 + LDKは失敗した支払いの保持期間のみを追跡していました（ニュースレター[#349][news349 attributable]参照）。 + +- [LDK #3842][]は、[インタラクティブなトランザクション構築][topic dual funding]ステートマシン（ニュースレター + [#295][news295 dual]参照）を拡張し、[スプライシング][topic splicing]トランザクションにおける + 共有インプットの署名の調整を処理します。`TxAddInput`メッセージの`prevtx`フィールドは、 + メモリ使用量を削減し、検証を簡単にするためにオプションになりました。 + +- [BIPs #1890][]は、一部のHTML 2.0 URIライブラリが`+`を空白スペースとして扱うため、 + [BIP77][]のセパレーターパラメーターを`+`から`-`に変更します。さらに、 + 非同期[Payjoin][topic payjoin]プロトコルを簡単にするために、 + フラグメントパラメーターは辞書の逆順ではなく、辞書順に並べる必要があります。 + +- [BOLTs #1232][]は、すべての実装で強制されているため、 + チャネルを開く際に`channel_type`フィールド（ニュースレター[#165][news165 type]参照）を必須にします。 + このPRはまた、[BOLT9][]を更新し、`channel_type`フィールドに含めることができる + 機能用の新しいコンテキストタイプ`T`を追加しています。 + +{% include snippets/recap-ad.md when="2025-07-29 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32521,31829,3801,3842,1890,1232" %} +[morehouse gosvuln]: https://delvingbitcoin.org/t/disclosure-lnd-gossip-timestamp-filter-dos/1859 +[tan ccw]: https://delvingbitcoin.org/t/chain-code-delegation-private-access-control-for-bitcoin-keys/1837 +[mpc]: https://ja.wikipedia.org/wiki/秘匿マルチパーティ計算 +[posner qc]: https://delvingbitcoin.org/t/post-quantum-hd-wallets-silent-payments-key-aggregation-and-threshold-signatures/1854 +[Libsecp256k1 v0.7.0]: https://github.com/bitcoin-core/secp256k1/releases/tag/v0.7.0 +[news340 sigops]: /ja/newsletters/2025/02/07/#sigops +[news304 orphan]: /ja/newsletters/2024/05/24/#bitcoin-core-30000 +[1p1c relay]: /ja/bitcoin-core-28-wallet-integration-guide/#1p1cone-parent-one-childリレー +[news349 attributable]: /ja/newsletters/2025/04/11/#ldk-2256 +[news295 dual]: /ja/newsletters/2024/03/27/#ldk-2419 +[news165 type]: /ja/newsletters/2021/09/08/#bolts-880 +[news362 orphan]: /ja/newsletters/2025/07/11/#bitcoin-core-pr-review-club \ No newline at end of file From ed388d2f4625526cdf7c153ade6cf3bae2d12c94 Mon Sep 17 00:00:00 2001 From: Walpurga03 Date: Sun, 27 Jul 2025 14:56:55 +0200 Subject: [PATCH 173/278] Newsletter 364 Translate into German --- .../de/newsletters/2025-07-25-newsletter.md | 186 ++++++++++++++++++ 1 file changed, 186 insertions(+) create mode 100644 _posts/de/newsletters/2025-07-25-newsletter.md diff --git a/_posts/de/newsletters/2025-07-25-newsletter.md b/_posts/de/newsletters/2025-07-25-newsletter.md new file mode 100644 index 0000000000..c7986af2c2 --- /dev/null +++ b/_posts/de/newsletters/2025-07-25-newsletter.md @@ -0,0 +1,186 @@ +--- +title: 'Bitcoin Optech Newsletter #364' +permalink: /de/newsletters/2025/07/25/ +name: 2025-07-25-newsletter-de +slug: 2025-07-25-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche fasst eine Schwachstelle zusammen, die ältere +Versionen von LND betrifft, beschreibt eine Idee zur Verbesserung der +Privatsphäre bei der Nutzung von Co-Signer-Diensten und untersucht die +Auswirkungen des Wechsels zu quantenresistenten Signaturalgorithmen auf +HD-Wallets, scriptlose Multisignaturen und Silent Payments. +Wie gewohnt enthält der Newsletter unsere regelmäßigen Abschnitte mit +Zusammenfassungen beliebter Fragen und Antworten aus Bitcoin Stack Exchange, +der Ankündigung neuer Releases und Release-Kandidaten sowie einer Übersicht +wichtiger Änderungen an beliebter Bitcoin-Infrastruktur-Software. + +## Nachrichten + +- **LND Gossip-Filter-DoS-Sicherheitslücke:** Matt Morehouse + [berichtete][morehouse gosvuln] auf Delving Bitcoin über eine Schwachstelle, + die frühere Versionen von LND betraf und die er zuvor [verantwortungsvoll + gemeldet][topic responsible disclosures] hatte. Ein Angreifer konnte wiederholt + historische Gossip-Nachrichten von einem LND-Knoten anfordern, bis der Speicher + erschöpft war und der Knoten beendet wurde. Die Schwachstelle wurde in LND + Version 0.18.3 behoben, die im September 2024 veröffentlicht wurde. + +- **Chain-Code-Vorenthaltung bei Multisig-Skripten:** Jurvis Tan + [berichtete][tan ccw] auf Delving Bitcoin über Forschung, die er gemeinsam mit + Jesse Posner zur Verbesserung der Privatsphäre und Sicherheit bei gemeinsamer + Multisig-Verwahrung durchgeführt hat. In einem typischen Custody-Service wird + häufig eine 2-aus-3-Multisig verwendet, wobei die drei Schlüssel sind: + + - Ein Nutzer-"Hot Key", der auf einem mit dem Netzwerk verbundenen Gerät + gespeichert ist und Transaktionen für den Nutzer signiert (manuell oder per + Software). + + - Ein Anbieter-"Hot Key", der auf einem separaten Gerät unter exklusiver + Kontrolle des Anbieters liegt. Dieser Schlüssel signiert Transaktionen nur + gemäß einer zuvor vom Nutzer festgelegten Policy, z.B. maximal _x_ BTC pro Tag. + + - Ein Nutzer-"Cold Key", der offline gespeichert ist und nur verwendet wird, + falls der Hot Key verloren geht oder der Anbieter keine autorisierten + Transaktionen mehr signiert. + + Obwohl diese Konfiguration die Sicherheit deutlich erhöht, wird bei der + Einrichtung fast immer verlangt, dass der Nutzer dem Anbieter die [BIP32 + Extended Public Keys][topic bip32] seiner Hot- und Cold-Wallets mitteilt. So + kann der Anbieter alle eingehenden Zahlungen und Ausgaben des Nutzers + nachverfolgen, auch wenn der Nutzer ohne Anbieter agiert. Es wurden bereits + mehrere Ansätze zur Verbesserung der Privatsphäre beschrieben, die aber entweder + mit typischer Nutzung inkompatibel sind (z.B. separate Tapleaves) oder komplex + (z.B. [MPC][]). Tan und Posner schlagen eine einfache Alternative vor: + + - Der Anbieter generiert die Hälfte eines BIP32-HD-Extended-Keys (nur den + Schlüsselteil) und übergibt den öffentlichen Schlüssel an den Nutzer. + + - Der Nutzer generiert die andere Hälfte (die Chain Code) und behält diese + privat. + + Beim Empfang von Zahlungen kann der Nutzer beide Hälften kombinieren, um einen + Extended Public Key (xpub) zu erstellen und wie gewohnt Multisig-Adressen + abzuleiten. Der Anbieter kennt den Chain Code nicht und kann daher weder den + xpub ableiten noch die Adresse herausfinden. + + Beim Ausgeben kann der Nutzer aus dem Chain Code das nötige "Tweak" ableiten, + das der Anbieter mit seinem privaten Schlüssel kombinieren muss, um eine + gültige Signatur zu erzeugen. Der Nutzer teilt dem Anbieter einfach das Tweak + mit. Der Anbieter erfährt daraus nur, dass es für die jeweilige + scriptPubKey-Ausgabe gültig ist. + + Manche Anbieter verlangen, dass das Wechselgeld bei einer Transaktion wieder an + das gleiche Skript-Template gesendet wird. Tans Beitrag beschreibt, wie dies + einfach umgesetzt werden kann. + +- **Forschungsergebnisse deuten darauf hin, dass Bitcoin-Grundfunktionen mit quantenresistenten Signaturalgorithmen kompatibel sind:** + Jesse Posner [veröffentlichte][posner qc] auf Delving Bitcoin mehrere Links zu + Forschungsarbeiten, die darauf hinweisen, dass [quantenresistente][topic quantum + resistance] Signaturalgorithmen vergleichbare Grundfunktionen wie die aktuell in + Bitcoin verwendeten bieten – etwa für [BIP32-HD-Wallets][topic bip32], + [Silent Payment Adressen][topic silent payments], [scriptlose Multisignaturen][topic multisignature] + und [scriptlose Threshold-Signaturen][topic threshold signature]. + +## Ausgewählte Fragen & Antworten von Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] ist eine der ersten Anlaufstellen für Optech- +Mitwirkende, wenn sie Antworten auf ihre Fragen suchen – oder wenn sie ein paar +Minuten Zeit haben, um neugierigen oder ratlosen Nutzern zu helfen. In diesem +monatlichen Abschnitt stellen wir einige der am höchsten bewerteten Fragen und +Antworten vor, die seit unserem letzten Update gepostet wurden.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Wie geht Bitcoin Core mit Reorgs von mehr als 10 Blöcken um?]({{bse}}127512) + TheCharlatan verweist auf Bitcoin-Core-Code, der Chain-Reorganisationen so + behandelt, dass maximal 10 Blöcke an Transaktionen wieder in den Mempool + aufgenommen werden. + +- [Vorteile eines Signiergeräts gegenüber einer verschlüsselten Festplatte?]({{bse}}127596) + RedGrittyBrick hebt hervor, dass Daten auf einer verschlüsselten Festplatte + extrahiert werden können, solange die Festplatte entschlüsselt ist, während + Hardware-Signiergeräte genau solche Angriffe verhindern sollen. + +- [Ausgabe eines Taproot-Outputs über Keypath und Scriptpath?]({{bse}}127601) + Antoine Poinsot erklärt, wie Merkle-Bäume, Key-Tweaks und Leaf-Skripte + Taproots Keypath- und Scriptpath-Ausgabefähigkeiten ermöglichen. + +## Releases und Release-Kandidaten + +_Neue Releases und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. +Bitte erwägen Sie ein Upgrade auf neue Releases oder helfen Sie beim Testen von +Release-Kandidaten._ + +- [Libsecp256k1 v0.7.0][] ist ein Release dieser Bibliothek mit + kryptografischen Grundfunktionen für Bitcoin. Es enthält einige kleine + Änderungen, die nicht mit früheren Versionen kompatibel sind. + +## Wichtige Code- und Dokumentationsänderungen + +_Wichtige kürzliche Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], +[Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], +[Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], +[BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und [BINANAs][binana repo]._ + +- [Bitcoin Core #32521][] macht Legacy-Transaktionen mit mehr als 2.500 + Signaturoperationen (sigops) nicht-standardkonform, um einen möglichen + [Consensus-Cleanup-Softfork][topic consensus cleanup] vorzubereiten, der das + Limit auf Konsensebene durchsetzt. Ohne diese Änderung könnten Miner, die + nicht aktualisieren, Ziel trivialer DoS-Angriffe werden. Weitere Details zum + Legacy-Sigops-Limit finden sich im Newsletter [#340][news340 sigops]. + +- [Bitcoin Core #31829][] fügt dem Orphan-Transaktionshandler `TxOrphanage` + (siehe Newsletter [#304][news304 orphan]) Ressourcenlimits hinzu, um die + opportunistische One-Parent-One-Child-(1p1c)-[Package-Relay][topic package relay] + gegen DoS-Spam-Angriffe zu schützen. Es gelten vier Limits: ein globales Limit + von 3.000 Orphan-Ankündigungen (zur Minimierung von CPU- und Latenzkosten), + ein proportionales Peer-Limit, eine Peer-Gewichtsreservierung von 24 × 400 kWU + und ein variables globales Speicherlimit. Wird ein Limit überschritten, entfernt + der Knoten die älteste Orphan-Ankündigung vom Peer mit dem höchsten DoS-Score. + Die PR entfernt außerdem die Option `-maxorphantxs` (Standard: 100), deren + zufällige Entfernung von Ankündigungen Angreifern erlaubte, das gesamte Orphan- + Set zu ersetzen und das 1p1c-Relay nutzlos zu machen. Siehe auch Newsletter + [#362][news362 orphan]. + +- [LDK #3801][] erweitert [attributable failures][topic attributable failures] + auf erfolgreiche Zahlungen, indem aufgezeichnet wird, wie lange ein Knoten ein + [HTLC][topic htlc] hält und diese Haltezeiten im Attribution-Payload nach oben + weitergibt. Zuvor wurden Haltezeiten nur für fehlgeschlagene Zahlungen + erfasst (siehe Newsletter [#349][news349 attributable]). + +- [LDK #3842][] erweitert die [interaktive Transaktionskonstruktion][topic dual + funding] (siehe Newsletter [#295][news295 dual]) um die Signaturkoordination + für gemeinsame Inputs in [Splicing][topic splicing]-Transaktionen. Das Feld + `prevtx` der `TxAddInput`-Nachricht ist nun optional, um Speicher zu sparen + und die Validierung zu vereinfachen. + +- [BIPs #1890][] ändert das Trennzeichen von `+` zu `-` in [BIP77][], da manche + HTML-2.0-URI-Bibliotheken `+` als Leerzeichen interpretieren. Außerdem müssen + Fragment-Parameter nun lexikografisch statt rückwärts sortiert werden, um das + asynchrone [Payjoin][topic payjoin]-Protokoll zu vereinfachen. + +- [BOLTs #1232][] macht das Feld `channel_type` (siehe Newsletter [#165][news165 + type]) beim Öffnen eines Channels verpflichtend, da jede Implementierung es + erzwingt. Die PR aktualisiert außerdem [BOLT9][] und fügt einen neuen + Kontexttyp `T` für Features hinzu, die im Feld `channel_type` enthalten sein + können. + +{% include snippets/recap-ad.md when="2025-07-29 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32521,31829,3801,3842,1890,1232" %} +[morehouse gosvuln]: https://delvingbitcoin.org/t/disclosure-lnd-gossip-timestamp-filter-dos/1859 +[tan ccw]: https://delvingbitcoin.org/t/chain-code-delegation-private-access-control-for-bitcoin-keys/1837 +[mpc]: https://en.wikipedia.org/wiki/Secure_multi-party_computation +[posner qc]: https://delvingbitcoin.org/t/post-quantum-hd-wallets-silent-payments-key-aggregation-and-threshold-signatures/1854 +[Libsecp256k1 v0.7.0]: https://github.com/bitcoin-core/secp256k1/releases/tag/v0.7.0 +[news340 sigops]: /de/newsletters/2025/02/07/#einfuhrung-einer-legacy-eingabe-sigops-begrenzung +[news304 orphan]: /en/newsletters/2024/05/24/#bitcoin-core-30000 +[1p1c relay]: /en/bitcoin-core-28-wallet-integration-guide/#one-parent-one-child-1p1c-relay +[news349 attributable]: /de/newsletters/2025/04/11/#ldk-2256 +[news295 dual]: /en/newsletters/2024/03/27/#ldk-2419 +[news165 type]: /en/newsletters/2021/09/08/#bolts-880 +[news362 orphan]: /de/newsletters/2025/07/11/#bitcoin-core-pr-review-club From 42710b0ae6fcf049cd49983fcca3d551b03842a9 Mon Sep 17 00:00:00 2001 From: Jiri Jakes Date: Sun, 27 Jul 2025 13:27:28 +0800 Subject: [PATCH 174/278] Newsletter-358: Translate into Czech --- .../cs/newsletters/2025-06-13-newsletter.md | 245 ++++++++++++++++++ 1 file changed, 245 insertions(+) create mode 100644 _posts/cs/newsletters/2025-06-13-newsletter.md diff --git a/_posts/cs/newsletters/2025-06-13-newsletter.md b/_posts/cs/newsletters/2025-06-13-newsletter.md new file mode 100644 index 0000000000..f63bb3073b --- /dev/null +++ b/_posts/cs/newsletters/2025-06-13-newsletter.md @@ -0,0 +1,245 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 358' +permalink: /cs/newsletters/2025/06/13/ +name: 2025-06-13-newsletter-cs +slug: 2025-06-13-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden popisuje, jak lze vypočítat práh nebezpečí sobecké +těžby, shrnuje nápad na zabraňování filtrování transakcí s vysokými +poplatky, žádá o zpětnou vazbu k návrhu na změnu `musig()` v BIP390 +deskriptorech a ohlašuje novou knihovnu pro šifrování deskriptorů. +Též nechybí naše pravidelné rubriky se souhrnem sezení Bitcoin Core PR +Review Clubu, oznámeními nových vydání a popisem nedávných změn v populárních +bitcoinových páteřních projektech. + +## Novinky + +- **Výpočet prahu sobecké těžby:** Antoine Poinsot + zaslal do fóra Delving Bitcoin [příspěvek][poinsot selfish], ve kterém + rozšiřuje matematický základ z [článku][es selfish] z roku 2013, který + dal své jméno [útoku sobeckou těžbou][topic selfish mining] (i když + samotný útok byl [popsán][bytecoin selfish] již v roce 2010). Dále poskytuje + zjednodušený [simulátor][darosior/miningsimulation] těžby a přeposílání + bloků, který umožňuje s útokem experimentovat. Soustředí se na zopakování + jednoho ze závěrů článku: že nepoctivý těžař (nebo kartel propojených + těžařů) ovládající 33 % celkového hashrate bez dalších výsad může v dlouhodobém + výhledu vydělávat nepatrně více než těžaři ovládající 67 % hashrate. + 33% menšina toho dosáhne tím, že bude cíleně zpožďovat oznámení některých + nově nalezených bloků. S hashratem zvyšujícím se nad 33 % se činnost + stává více a více profitabilní, až přesáhne 50% hashrate a může zabránit + ostatním účastníkům v připojování jejich bloků. + + Poinsotův příspěvek jsme podrobně neanalyzovali, ale jeho přístup se + nám jevil rozumný a doporučili bychom ho k přečtení každému se zájmem + získat lepší porozumění. + +- **Synchronizace vrcholu mempoolu pro odolnost vůči cenzuře :** + Peter Todd zaslal do emailové skupiny Bitcoin-Dev [příspěvek][todd feerec] + o mechanismu, který by uzlům umožnil zahazovat spojení, která filtrují + transakce s vysokými poplatky. Tento mechanismus závisí na [mempoolu + clusterů][topic cluster mempool] a mechanismu synchronizování množin + (set reconciliation) jako např. v [erlay][topic erlay]. Uzel by pomocí + mempoolu clusterů vypočítal nejvýhodnější množinu nepotvrzených transakcí, + které by se mohly vměstnat do (na příklad) 8 000 000 váhových jednotek + (maximum 8 MB). Každé ze spojení uzlu by též vypočítalo horních + 8 000 000 váhových jednotek nepotvrzených transakcí. Pomocí efektivního + algoritmu jako [minisketch][topic minisketch] by mohl uzel synchronizovat + svou množinu transakcí se svými spojeními. Tím by se přesně dozvěděl, + které transakce mají spojení na vrcholu svých mempoolů. Uzel by + pravidelně odpojoval spojení, která mají v průměru nejméně profitabilní + mempool. + + Zbavením se nejméně profitabilních spojení by uzel postupně našel taková + spojení, která by nejméně pravděpodobně filtrovala transakce s vysokými + poplatky. Todd doufá, že bude moci po začlenění mempoolu clusterů do + Bitcoin Core na implementaci pracovat. Nápad přisuzuje Gregorymu Maxwellovi + a jiným. Optech myšlenku poprvé zmínil ve [zpravodaji č. 9][news9 + reconcile] (_angl._). + +- **Opakovaný veřejný klíč v `musig()` v BIP390:** + Ava Chow zaslala do emailové skupiny Bitcoin-Dev [příspěvek][chow dupsig] + s dotazem, zda-li by někdo namítal, aby [BIP390][] umožňoval výrazům `musig()` + v [deskriptorech výstupních skriptů][topic descriptors] obsahovat stejný + veřejný klíč více než jednou. Vedlo by to k jednodušší implementaci + a je to explicitně povoleno ve specifikaci [MuSig2][topic musig] v [BIP327][]. + V době psaní zpravodaje námitky nikdo nevyjádřil a Chow tedy otevřela + pro změnu specifikace BIP390 nový [pull request][bips #1867]. + +- **Knihovna pro šifrování deskriptorů:** Josh Doman zaslal do fóra Delving + Bitcoin [příspěvek][doman descrypt] s ohlášením své knihovny, která + přítomnými veřejnými klíči šifruje citlivé části [deskriptoru výstupních + skriptů][topic descriptors] nebo [miniscriptu][topic miniscript]. + Popisuje, které informace jsou potřebné k dešifrování: + + > - Pokud tvoje peněženka vyžaduje k utracení 2-ze-3 klíčů, bude potřebovat + > přesně 2-ze-3 klíčů k dešifrování. + > + > - Pokud tvoje peněženka používá komplexní mininiscriptová pravidla jako + > „buď 2 klíče NEBO (časový zámek A jiný klíč),“ šifrování následuje + > stejnou strukturu, jako by byly všechny časové zámky uspokojené. + + Tento návrh se liší od schématu záloh diskutovaných ve [zpravodaji + č. 351][news351 salvacrypt], kde znalost kteréhokoliv veřejného klíče + z deskriptoru postačovala k jeho dešifrování. Doman tvrdí, že jeho + schéma poskytuje více soukromí v případech, kdy je šifrovaný + deskriptor zálohován ve veřejných či poloveřejných zdrojích, jako je + blockchain. + +## Bitcoin Core PR Review Club + +*V této měsíční rubrice shrnujeme nedávné sezení [Bitcoin Core PR Review Club][] a +vyzdvihujeme některé z důležitých otázek a odpovědí. Klikněte na otázku a odpověď se vám odhalí.* + +[Vyčleň z validačních funkcí přístup do množiny UTXO][review club 32317] +(„Separate UTXO set access from validation functions”) je PR od [TheCharlatan][gh +thecharlatan], které umožňuje volat validační funkce předáním pouze vyžadovaných +UTXO namísto celé množiny UTXO. Jedná se o součást projektu +[`bitcoinkernel`][Bitcoin Core #27587], která je důležitým krokem na cestě k +použitelnosti knihovny pro implementace plného uzlu, které neimplementují +množinu UTXO, jako jsou [Utreexo][topic utreexo] nebo [SwiftSync][somsen swiftsync] +(viz [zpravodaj č. 349][news349 swiftsync]). + +V prvních čtyřech commitech snižuje PR závislost mezi funkcemi provádějícími +validaci transakcí a množinou UTXO. Nově vyžaduje, aby volající funkce +nejprve načetla potřebné objekty `Coin` nebo `CTxOut` a potom je předala +validační funkci (dříve validační funkce sama přímo přistupovala do +množiny UTXO.) + +Následné commity závislost `ConnectBlock()` na množině UTXO odstraňují +kompletně. Za tímto účelem extrahují zbývající logiku, která potřebuje +s množinou UTXO pracovat, do metody `SpendBlock()`. + +{% include functions/details-list.md + q0="Proč je v tomto PR oddělení nové funkce `SpendBlock()` z `ConnectBlock()` + užitečné? Jak byste porovnali smysl těchto dvou funkcí?" + a0="Funkce `ConnectBlock()` původně prováděla validaci bloku i změny + množiny UTXO. Tento refaktoring obě zodpovědnosti odděluje: + `ConnectBlock()` nově obsahuje pouze logiku validace, která množinu UTXO + nepotřebuje, a nová funkce `SpendBlock()` obstarává veškerou interakci s UTXO + množinou. Díky tomu je možné provést validaci bloku pomocí `ConnectBlock()` + bez množiny UTXO." + a0link="https://bitcoincore.reviews/32317#l-37" + + q1="Jaké další výhody tohoto oddělení vidíte?" + a1="Vedle možnosti používat jádro v projektech bez množiny UTXO + usnadňuje toto oddělení testování a údržbu. Jeden účastník + též poznamenal, že odstranění potřeby přístupu k množině UTXO + otevírá dveře k paralelní validaci bloků, což je důležitá funkce + SwiftSyncu." + a1link="https://bitcoincore.reviews/32317#l-64" + + q2="`SpendBlock()` má parametry `CBlock block`, `CBlockIndex pindex` + a `uint256 block_hash`, všechny odkazující na utrácený blok. Proč + k tomu potřebujeme tři parametry?" + a2="Kód validace je z hlediska výkonnosti kritický, neboť má dopad + na příklad na rychlost propagace bloků. Počítání haše bloku z + `CBlock` nebo `CBlockIndex` není zadarmo, protože hodnota se nekešuje. + Proto se autor rozhodl upřednostnit výkonnost tím, že předává již spočítaný + haš bloku jako samotný parametr. Podobně by mohl být i `pindex` získán + z indexu bloku, ale to by znamenalo nadbytečné vyhledání v mapě navíc. +
_Poznámka: autor později přístup [změnil][32317 updated approach] + a `block_hash`odstranil._" + a2link="https://bitcoincore.reviews/32317#l-97" + + q3="První commit tohoto PR odstraňuje `CCoinsViewCache` ze signatury + několika validačních funkcí. Drží `CCoinsViewCache` celou množinu UTXO? + Proč to je/není problém? Mění PR toto chování?" + a3="`CCoinsViewCache` nedrží celou množinu UTXO; jedná se o mezipaměť, která + je umístěna před `CCoinsViewDB`, která ukládá celou množinu UTXO na disk. + Pokud není požadovaná mince v mezipaměti, musí být načtena z disku. + Toto PR samotné chování kešování nemění. Odstraněním `CCoinsViewCache` ze + signatur je závislost na UTXO explicitní, jelikož od volající funkce + požaduje, aby mince před voláním validační funkce sama načetla." + a3link="https://bitcoincore.reviews/32317#l-116" +%} + +## Vydání nových verzí + +*Vydání nových verzí oblíbených páteřních bitcoinových projektů. Prosíme, +zvažte upgrade či pomoc s testováním.* + +- [Core Lightning 25.05rc1][] je kandidátem na vydání příští hlavní verze této oblíbené + implementace LN uzlu. + +- [LND 0.19.1-beta][] je kandidátem na vydání údržbové verze této populární + implementace LN uzlu. [Obahuje][lnd rn] opravy několika chyb. + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo] a [repozitáři BINANA][binana repo]._ + +- [Bitcoin Core #32406][] odstraňuje omezení velikosti `OP_RETURN` výstupu + (pravidlo standardnosti). Navyšuje výchozí nastavení `-datacarriersize` + z 83 na 100 000 bajtů (nejvyšší možná velikost transakce). Volby + `-datacarrier` a `-datacarriersize` zůstávají zachované, jsou však + označené jako zastaralé a očekává se jejich odstranění v nějakém + budoucím vydání. Dále toto PR odstraňuje omezení jednoho + `OP_RETURN` výstupu na transakci a stanovuje omezení velikosti na + všechny takové výstupy. [Zpravodaj č. 352][news352 opreturn] přináší + další informace o této změně. + +- [LDK #3793][] přidává novou zprávu `start_batch`, která signalizuje spojením, + aby považovala příštích `n` (`batch_size`) zpráv za jedinou logickou jednotku. + Dále aktualizuje `PeerManager`, aby používal tuto zprávu pro zprávy + `commitment_signed` namísto přidávání TLV a `batch_size` do každé jednotlivé + zprávy. Jedná se o pokus umožnit dávkování i jiným zprávám LN protokolu. + +- [LDK #3792][] přináší úvodní podporu (za testovacím příznakem) [v3 commitment + transakcí][topic v3 commitments] (viz [zpravodaj č. 325][news325 v3]), + která spoléhá na [TRUC transakce][topic v3 transaction relay] a [dočasné + anchory][topic ephemeral anchors]. Uzel bude nově odmítat návrhy + `open_channel`, které nastavují nenulový jednotkový poplatek, ujistí se, + že nikdy podobné kanály nebude sám navrhovat a přestane automaticky + akceptovat v3 kanály, dokud nejprve nezarezervuje UTXO pro pozdější + navyšování poplatků. PR dále snižuje [HTLC][topic htlc] limit na kanál + z 483 na 114, protože TRUC transakce musí zůstat pod 10 kvB. + +- [LND #9127][] přidává do příkazu `lncli addinvoice` volbu + `--blinded_path_incoming_channel_list`, která příjemci umožní přidat jeden + či více preferovaných kanálů, přes které by odesílatel mohl směrovat [zaslepenou + cestu][topic rv routing]. + +- [LND #9858][] signalizuje produkční feature bit 61 pro kooperativní zavírání kanálu + s [RBF][topic rbf] (viz též [zpravodaj č. 347][news347 rbf]). Tím zajistí + fungování s Eclairem. Zachovává testovací bit 161 pro uzly testující tuto + funkcionalitu. + +- [BOLTs #1243][] mění ve specifikaci [BOLT11][] nakládání s poli faktury. Nově odesílatel + nesmí platit fakturu, pokud nemají povinná pole jako `p` (platební haš), `h` (haš popisky) + nebo `s` (tajný kód) správnou délku. Dříve mohl uzel tyto problémy ignorovat. + Změna dále mezi příklady přidává poznámku vysvětlující, že [podpisy s nižším R][topic + low-r grinding] nejsou specifikací vynucované, i když šetří jeden bajt. + +{% include snippets/recap-ad.md when="2025-06-17 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32406,3793,3792,9127,1867,9858,1243,27587" %} +[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1 +[lnd 0.19.1-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.1-beta +[poinsot selfish]: https://delvingbitcoin.org/t/where-does-the-33-33-threshold-for-selfish-mining-come-from/1757 +[bytecoin selfish]: https://bitcointalk.org/index.php?topic=2227.msg30083#msg30083 +[darosior/miningsimulation]: https://github.com/darosior/miningsimulation +[todd feerec]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aDWfDI03I-Rakopb@petertodd.org/ +[news9 reconcile]: /en/newsletters/2018/08/21/#bandwidth-efficient-set-reconciliation-protocol-for-transactions +[chow dupsig]: https://mailing-list.bitcoindevs.xyz/bitcoindev/08dbeffd-64ec-4ade-b297-6d2cbeb5401c@achow101.com/ +[doman descrypt]: https://delvingbitcoin.org/t/rust-descriptor-encrypt-encrypt-any-descriptor-such-that-only-authorized-spenders-can-decrypt/1750/ +[news351 salvacrypt]: /cs/newsletters/2025/04/25/#standardizovane-zalohovani-deskriptoru-penezenek +[es selfish]: https://arxiv.org/pdf/1311.0243 +[lnd rn]: https://github.com/lightningnetwork/lnd/blob/v0.19.1-beta/docs/release-notes/release-notes-0.19.1.md +[news352 opreturn]: /cs/newsletters/2025/05/02/#navyseni-ci-odstraneni-omezeni-velikosti-op-return-v-bitcoin-core +[news325 v3]: /cs/newsletters/2024/10/18/#commitment-transakce-verze-3 +[news347 rbf]: /cs/newsletters/2025/03/28/#lnd-8453 +[review club 32317]: https://bitcoincore.reviews/32317 +[gh thecharlatan]: https://github.com/TheCharlatan +[somsen swiftsync]: https://gist.github.com/RubenSomsen/a61a37d14182ccd78760e477c78133cd +[32317 updated approach]: https://github.com/bitcoin/bitcoin/pull/32317#issuecomment-2883841466 +[news349 swiftsync]: /cs/newsletters/2025/04/11/#swiftsync-urychlujici-uvodni-stahovani-bloku From 0fe30e70d6b8031bf7972327f9788063dd3db165 Mon Sep 17 00:00:00 2001 From: Jiri Jakes Date: Sun, 27 Jul 2025 16:10:10 +0800 Subject: [PATCH 175/278] Newsletter-359: Translate into Czech --- .../cs/newsletters/2025-06-20-newsletter.md | 176 ++++++++++++++++++ 1 file changed, 176 insertions(+) create mode 100644 _posts/cs/newsletters/2025-06-20-newsletter.md diff --git a/_posts/cs/newsletters/2025-06-20-newsletter.md b/_posts/cs/newsletters/2025-06-20-newsletter.md new file mode 100644 index 0000000000..81b015af42 --- /dev/null +++ b/_posts/cs/newsletters/2025-06-20-newsletter.md @@ -0,0 +1,176 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 359' +permalink: /cs/newsletters/2025/06/20/ +name: 2025-06-20-newsletter-cs +slug: 2025-06-20-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden popisuje návrh na omezení veřejné účasti +v repozitářích Bicoin Core, oznamuje významné zlepšení kontraktů +ve stylu BitVM a shrnuje výzkum rebalancování LN kanálů. Též nechybí +naše pravidelné rubriky se souhrnem nedávných změn ve službách +a klientech, oznámeními nových vydání a popisem významných změn +v populárním bitcoinovém páteřním software. + +## Novinky + +- **Návrh na zpřísnění přístupu do diskuzí v Bitcoin Core Project:** + Bryan Bishop zaslal do emailové skupiny Bitcoin-Dev [příspěvek][bishop priv] + s návrhem, aby Bitcoin Core Project omezil možnost veřejnosti + účastnit se diskuzí v projektu. Cílem je snížit množství + narušování pořádku způsobeného nepřispěvateli. Nazval to „privatizací Bitcoin + Core.” Poukazuje na příklady podobné privatizace, která se děje + v soukromých kancelářích s více přispěvateli, avšak varuje, že + privatizace v osobních setkáních vylučuje přispěvatele pracující + na dálku. + + Bishopův příspěvek navrhuje metodu online privatizace, avšak + Antoine Poinsot [pochybuje][poinsot priv], zda by jeho metoda dosáhla + cíle. Poinsot se též domnívá, že mnoho diskuzí se může odehrávat + v soukromých kancelářích ne ze strachu z veřejné kritiky, ale kvůli + „přirozeným výhodám diskutování osobně.” + + Někteří reagující se domnívají, že velké změny nejsou teď pravděpodobně + odůvodněné, ale přísnější moderování komentářů v repozitáři by mohlo + zmírnit nejčastější druh narušování. Jiné odpovědi však poukázaly + na obtíže přísnějšího moderování. + + Poinsot, Sebastian „The Charlatan” Kung a Russell Yanofsky – jediní + výrazně aktivní přispěvatelé do Bitcoin Core, kteří se v době psaní + zpravodaje debaty účastnili – [naznačili][kung priv], že buď se + [nedomnívají][yanofsky priv], že jsou velké změny nutné, nebo že by + jakékoliv změny měly proběhnout postupně. + +- **Vylepšení kontraktů ve stylu BitVM:** Robin Linus zaslal do fóra + Delving Bitcoin [příspěvek][linus bitvm3] s oznámením výrazné redukce + množství onchain prostoru vyžadovaného kontrakty typu [BitVM][topic acc]. + Nápad je založen na [myšlence][rubin garbled] Jeremyho Rubina, + která staví na nových kryptografických primitivech. Nový přístup + „snižuje onchain náklady řešení rozporů více než tisíckrát + v porovnání s předchozím designem.” Zpochybňující transakce mají + „pouze 200 bajtů.” + + Linusův článek však poznamenává, že přístup „vyžaduje několikaterabajtovou + přípravu offchain.” Článek poskytuje příklad SNARKového obvodu pro + ověřování se zhruba pěti miliardami hradel a dostatečnými bezpečnostními + parametry, který na úvod vyžaduje pět terabajtů offchain dat, 56kB + onchain transakci pro oznámení výsledku a minimální onchain transakci + (kolem 200 bajtů) v případě, kdy některá strana potřebuje doložit, + že výsledek byl nevalidní. + +- **Výzkum rebalancování kanálů:** René Pickhardt zaslal do fóra Delving + Bitcoin [příspěvek][pickhardt rebalance] s myšlenkou na rebalancování + kanálů pro maximalizaci počtu úspěšných plateb v celé síti. + Nápad lze porovnat s podobnými, které nahlížejí pouze na menší + skupiny kanálů, například [friend-of-a-friend rebalancing][topic jit routing] + (viz [zpravodaj č. 54][news54 foaf rebalance], _angl._). + + Pickhardt poznamenává, že v případě celé sítě existuje několik + složitých problémů a klade zájemcům několik otázek, mimo jiné + zda-li má smysl v tomto přístupu pokračovat či jak řešit některé + implementační detaily. + +## Změny ve službách a klientech + +*V této měsíční rubrice upozorňujeme na zajímavé aktualizace bitcoinových +peněženek a služeb.* + +- **Vydán Cove v1.0.0:** + Nedávné [vydání][cove github] Cove obsahuje podporu výběru mincí a + dodatečné funkce štítků peněženek dle [BIP329][]. + +- **Vydána Liana v11.0:** + Nedávné [vydání][liana github] Liany obsahuje mimo jiné možnost mít několik peněženek, + dodatečné funkce výběru mincí a podporu více hardwarových podpisových zařízení. + +- **Ukázka dokladu Stratum v2 STARK:** + StarkWare [ukázal][starkware tweet], jak jejich [upravený těžební Stratum + v2 klient][starkware sv2] používá STARK doklady k prokázání, že poplatky + z bloku patří validní šabloně bloku, aniž by odhalil jeho transakce. + +- **Breez SDK přidává BOLT12 a BIP353:** + Breez SDK Nodeless [0.9.0][breez github] přidává podporu pro příjem + pomocí [BOLT12][] a [BIP353][]. + +## Vydání nových verzí + +*Vydání nových verzí oblíbených páteřních bitcoinových projektů. Prosíme, +zvažte upgrade či pomoc s testováním.* + +- [Core Lightning 25.05][] je vydáním hlavní verze této oblíbené implementace + LN uzlu. Snižuje latenci přeposílání a urovnání plateb, zlepšuje správu + poplatků, poskytuje podporu [splicingu][topic splicing] kompatibilní + s Eclairem a ve výchozím stavu má aktivovaný [peer storage][topic peer storage]. + Poznámka: [dokumentace k vydání][core lightning 25.05] obsahuje varování + pro uživatele konfigurační volby `--experimental-splicing`. + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo] a [repozitáři BINANA][binana repo]._ + +- [Eclair #3110][] prodlužuje čekací dobu, než označí kanál za zavřený po + utracení zakládajícího výstupu, ze 12 (viz [zpravodaj č. 337][news337 delay]) + na 72 bloků dle specifikace v [BOLTs #1270][]. Tato změna umožní propagaci + [splicu][topic splicing]. Čekací doba byla navýšena, protože některé implementace + čekají ve výchozím stavu na osm konfirmací, než odešlou `splice_locked`, a + umožňují provozovatelům tento práh navýšit. 12 bloků se proto ukázalo jako + nedostatečných. Čekací doba je pro testovací účely konfigurovatelná + a umožňuje provozovatelům čekat déle. + +- [Eclair #3101][] přináší RPC volání `parseoffer`, které dekóduje pole [BOLT12 + nabídek][topic offers] do čitelného formátu. Tím umožní uživatelům prohlédnout + částku před tím, než nabídku předají volání `payoffer`. To navíc nově může + akceptovat částku specifikovanou ve fiat měně. + +- [LDK #3817][] stahuje podporu [informací o původci chyb][topic attributable + failures] (attributable failures, viz [zpravodaj č. 349][news349 attributable]) + a schovává ji za testovací příznak. Tím bude logika penalizací spojení neaktivní + a příslušné TLV odstraněno z [onion zpráv][topic onion messages]. Uzly, které + zatím neupgradovaly, byly nesprávně penalizované. Ukázalo se tak, že širší + osvojení sítí je pro správnou funkci potřebné. + +- [LDK #3623][] rozšiřuje [peer storage][topic peer storage] (viz [zpravodaj č. 342][news342 + peer]) o automatické rozesílání šifrovaných záloh. Po každém bloku zabalí + `ChainMonitor` příslušná data do `OurPeerStorage`. Nato data zašifruje a + vyvolá událost `SendPeerStorage`, po které se data zprávou `peer_storage` + rozešlou druhým stranám všech kanálů. `ChannelManager` také nově umí + zpracovat `peer_storage_retrieval` požadavky. + +- [BTCPay Server #6755][] zlepšuje uživatelské rozhraní výběru mincí o nový filtr + nejmenší a nejvyšší částky a data, přidává filtrům nápovědu, zaškrtávací políčko + pro výběr všech UTXO a volbu velikosti stránky (100, 200 či 500 UTXO). + +- [Rust libsecp256k1 #798][] dokončuje implementaci [MuSig2][topic musig], čímž + nabízí klientským projektům přístup k robustnímu protokolu [bezskriptových + vícenásobných podpisů][topic multisignature]. + +{% include snippets/recap-ad.md when="2025-06-24 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="3110,3101,3817,3623,6755,1270" %} +[Core Lightning 25.05]: https://github.com/ElementsProject/lightning/releases/tag/v25.05 +[bishop priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com/ +[poinsot priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235xaDlhg35nY8Zn7g1siy3IADHvSHyCcgTHrJorMKcDzZg=@protonmail.com/ +[kung priv]: https://mailing-list.bitcoindevs.xyz/bitcoindev/58813483-7351-487e-8f7f-82fb18a4c808n@googlegroups.com/ +[linus bitvm3]: https://delvingbitcoin.org/t/garbled-circuits-and-bitvm3/1773 +[rubin garbled]: https://rubin.io/bitcoin/2025/04/04/delbrag/ +[pickhardt rebalance]: https://delvingbitcoin.org/t/research-update-a-geometric-approach-for-optimal-channel-rebalancing/1768 +[rust libsecp256k1 #798]: https://github.com/rust-bitcoin/rust-secp256k1/pull/798 +[news54 foaf rebalance]: /en/newsletters/2019/07/10/#brainstorming-just-in-time-routing-and-free-channel-rebalancing +[yanofsky priv]: https://github.com/bitcoin-core/meta/issues/19#issuecomment-2961177626 +[cove github]: https://github.com/bitcoinppl/cove/releases +[liana github]: https://github.com/wizardsardine/liana/releases +[breez github]: https://github.com/breez/breez-sdk-liquid/releases/tag/0.9.0 +[starkware tweet]: https://x.com/dimahledba/status/1935354385795592491 +[starkware sv2]: https://github.com/keep-starknet-strange/stratum +[news337 delay]: /cs/newsletters/2025/01/17/#eclair-2936 +[news349 attributable]: /cs/newsletters/2025/04/11/#ldk-2256 +[news342 peer]:/cs/newsletters/2025/02/21/#ldk-3575 From 4dac774cb90a5a8389d3d4268b93f6f8c6f06c6f Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Mon, 28 Jul 2025 15:21:52 +0200 Subject: [PATCH 176/278] Newsletter 364 translate in French (#2429) --- .../fr/newsletters/2025-07-25-newsletter.md | 179 ++++++++++++++++++ 1 file changed, 179 insertions(+) create mode 100644 _posts/fr/newsletters/2025-07-25-newsletter.md diff --git a/_posts/fr/newsletters/2025-07-25-newsletter.md b/_posts/fr/newsletters/2025-07-25-newsletter.md new file mode 100644 index 0000000000..7ad6c59f59 --- /dev/null +++ b/_posts/fr/newsletters/2025-07-25-newsletter.md @@ -0,0 +1,179 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #364' +permalink: /fr/newsletters/2025/07/25/ +name: 2025-07-25-newsletter-fr +slug: 2025-07-25-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +La newsletter de cette semaine résume une vulnérabilité affectant d'anciennes versions de LND, +décrit une idée pour améliorer la confidentialité lors de l'utilisation de services de +co-signataires, et examine l'impact du passage à des algorithmes de signature résistants aux +quantiques sur les portefeuilles HD, le multisig sans script, et les paiements silencieux. +Sont également incluses nos sections régulières résumant les récentes questions et réponses de Bitcoin +Stack Exchange, annoncant de nouvelles versions et des candidats à la publication, ainsi que les +résumés des modifications notables apportées aux logiciels d'infrastructure Bitcoin populaires. + +## Nouvelles + +- **Vulnérabilité de DoS du filtre de gossip de LND :** Matt Morehouse a [publié][morehouse gosvuln] + sur Delving Bitcoin concernant une vulnérabilité affectant les versions passées de LND qu'il avait + précédemment [divulguée de manière responsable][topic responsible disclosures]. Un attaquant + pourrait demander à répétition des messages de l'historique de gossip à un nœud LND jusqu'à ce qu'il + manque de mémoire et se coupe. La vulnérabilité a été corrigée dans LND 0.18.3, publié en + septembre 2024. + +- **Rétention du code de chaîne pour les scripts multisig :** Jurvis Tan a [posté][tan ccw] sur + Delving Bitcoin à propos de recherches qu'il a effectuées avec Jesse Posner pour améliorer la + confidentialité et la sécurité de la garde collaborative multisig. Dans un service de garde + collaborative typique, un multisig 2-sur-3 peut être utilisé avec les trois clés étant : + + - Une _clé chaude utilisateur_ qui est stockée sur un appareil connecté au réseau et signe les + transactions pour l'utilisateur (soit manuellement, soit par automatisation logicielle). + + - Une clé chaude du fournisseur qui est stockée sur un appareil connecté au réseau séparé sous le + contrôle exclusif du fournisseur. La clé ne signe les transactions selon une politique précédemment + définie par l'utilisateur, comme permettant seulement des dépenses jusqu'à _x_ BTC par jour. + + - Une _clé froide utilisateur_ qui est stockée hors ligne et est utilisée seulement si la clé chaude + de l'utilisateur est perdue ou si le fournisseur cesse de signer les transactions autorisées. + + Bien que la configuration ci-dessus puisse fournir un renforcement significatif de la sécurité, la + méthode de configuration presque toujours utilisée implique que l'utilisateur partage avec le + fournisseur les [clés publiques étendues BIP32][topic bip32] pour les portefeuilles chaud et froid + de l'utilisateur. Cela permet au fournisseur de détecter tous les fonds reçus par le portefeuille de + l'utilisateur et de suivre toutes les dépenses de ces fonds même si l'utilisateur dépense sans + l'assistance du fournisseur. Plusieurs moyens de mitiger cette perte de confidentialité ont été + précédemment décrits, mais ils sont soit incompatibles avec l'utilisation typique (par exemple, en + utilisant des tapleaves distinctes) soit complexes (par exemple, nécessitant [MPC][]). Tan et + Posner décrivent une alternative simple : + + - Le fournisseur génère la moitié d'une clé étendue HD BIP32 (juste la partie clé). Ils donnent la + clé publique à l'utilisateur. + + - L'utilisateur génère l'autre moitié (le code de chaîne). Ils gardent cela privé. + + Lors de la réception de fonds, l'utilisateur peut combiner les deux moitiés pour créer une clé + publique étendue (xpub) puis dériver des adresses multisig comme d'habitude. Le fournisseur ne + connaissant pas le code de chaîne, il est empêché de dériver l'xpub ou de découvrir l'adresse. + + Lors de la dépense de fonds, l'utilisateur peut dériver du code de chaîne avec + l'ajustement nécessaire que le fournisseur doit combiner avec sa clé privée pour créer une signature + valide. Ils partagent simplement cet ajustement avec le fournisseur. Le fournisseur ne peut rien + apprendre de l'ajustement, sauf qu'il est valide pour dépenser depuis le scriptPubKey spécifique qui + a reçu des fonds. + + Certains fournisseurs peuvent exiger que la sortie de monnaie rendue d'une transaction de dépense + renvoie l'argent au même modèle de script. Le post de Tan décrit comment cela peut être facilement + accompli. + +- **La recherche indique que les primitives Bitcoin communes sont compatibles avec les algorithmes de signature résistants aux quantiques :** + Jesse Posner a [posté][posner qc] sur Delving Bitcoin plusieurs liens vers des articles de recherche + qui indiquent que les algorithmes de signature [résistants aux quantiques][topic quantum resistance] + fournissent des primitives comparables à celles actuellement utilisées dans Bitcoin pour les + [portefeuilles HD BIP32][topic bip32], les [adresses de paiement silencieuses][topic silent + payments], les [multisignatures sans script][topic multisignature], et les [signatures de seuil sans + script][topic threshold signature]. + +## Questions et réponses sélectionnées de Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] est l'un des premiers endroits où les contributeurs d'Optech +cherchent des réponses à leurs questions - ou quand nous avons quelques moments libres pour aider +les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous mettons en lumière certaines +des questions et réponses les mieux votées postées depuis notre dernière mise à jour.* + + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + + +- [Comment Bitcoin Core gère-t-il les réorganisations de chaîne de plus de 10 blocs ?]({{bse}}127512) + TheCharlatan lie au code de Bitcoin Core qui gère les réorganisations de chaîne en ne réajoutant + qu'un maximum de 10 blocs de transactions au mempool. + +- [Avantages d'un dispositif de signature par rapport à un disque crypté ?]({{bse}}127596) + RedGrittyBrick souligne que les données sur un disque crypté peuvent être extraites tandis que le + disque est déchiffré alors que les dispositifs de signature matérielle sont conçus pour empêcher + cette attaque d'extraction de données. + +- [Dépenser une sortie taproot via le keypath et le scriptpath ?]({{bse}}127601) + Antoine Poinsot détaille comment l'utilisation d'arbres de Merkle, d'ajustements de clé et de + tapscript permet d'atteindre les capacités de dépense de taproot via le keypath et le + scriptpath. + +## Mises à jour et versions candidates + +_Nouvelles mises-à-jours et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de mettre à niveau vers les nouvelles mises-à-jour ou d'aider à tester les versions candidates._ + +- [Libsecp256k1 v0.7.0][] est une sortie de cette bibliothèque contenant des primitives + cryptographiques compatibles avec Bitcoin. Elle contient quelques petits changements qui rompent la + compatibilité API/ABI avec les versions précédentes. + +## Changements notables dans le code et la documentation + +_Changements récents notables dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core +lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], +[libsecp256k1][libsecp256k1 repo], [Interface de Portefeuille Matériel (HWI)][hwi repo], [Rust +Bitcoin][rust bitcoin repo], [Serveur BTCPay][btcpay server repo], [BDK][bdk repo], [Propositions +d'Amélioration de Bitcoin (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] et [BINANAs][binana +repo]._ + +- [Bitcoin Core #32521][] rend les transactions héritées avec plus de 2500 opérations de signature + (sigops) non standard en préparation pour une potentielle mise à niveau de [soft fork de nettoyage + de consensus][topic consensus cleanup] qui imposerait la limite au niveau du consensus. Si le soft + fork avait lieu sans ce changement, les mineurs qui ne mettent pas à jour pourraient devenir des + cibles d'attaques DoS triviales. Voir le Bulletin [#340][news340 sigops] pour plus de détails sur + la limite des sigops d'entrée héritée. + +- [Bitcoin Core #31829][] ajoute des limites de ressources au gestionnaire de transactions + orphelines, `TxOrphanage` (Voir le Bulletin [#304][news304 orphan]), pour préserver le [relais de + paquets][topic package relay] opportuniste un-parent-un-enfant (1p1c) face aux + attaques de spam DoS. Quatre limites sont imposées : un plafond global de 3 000 annonces orphelines + (pour minimiser le coût en CPU et en latence), un plafond d'annonces orphelines par pair + proportionnel, une réservation de poids par pair de 24 × 400 kWU, et un plafond de mémoire global + variable. Lorsqu'une limite est dépassée, le nœud évince l'annonce orpheline la plus ancienne du + pair qui a utilisé le plus de CPU ou de mémoire par rapport à son allocation (score Peer DoS le plus + élevé). La PR supprime également l'option `‑maxorphantxs` (par défaut 100), dont la politique + d'éviction d'annonces aléatoires permettait aux attaquants de remplacer l'ensemble des orphelins et + de rendre le relais [1p1c][1p1c relay] inutile. Voir également le Bulletin [#362][news362 orphan]. + +- [LDK #3801][] étend les [échecs attribuables][topic attributable failures] au chemin de réussite + de paiement en enregistrant combien de temps un nœud détient un [HTLC][topic htlc] et en propageant + ces valeurs de temps de détention en amont dans la charge utile d'attribution. Auparavant, LDK ne + suivait les temps de détention que pour les paiements échoués (voir le Bulletin [#349][news349 + attributable]). + +- [LDK #3842][] étend sa machine d'état de [construction de transaction interactive][topic dual + funding] (Voir le Bulletin [#295][news295 dual]) pour gérer la coordination de signature pour les + entrées partagées dans les transactions de [splicing][topic splicing]. Le champ `prevtx` du message + `TxAddInput` est rendu optionnel pour réduire l'utilisation de la mémoire et simplifier la + validation. + +- [BIPs #1890][] change le paramètre séparateur de `+` à `-` dans [BIP77][] parce que certaines + bibliothèques URI HTML 2.0 traitent `+` comme s'il s'agissait d'un espace blanc. De plus, les + paramètres de fragment doivent maintenant être ordonnés lexicographiquement, plutôt qu'à l'envers, + pour simplifier le protocole [payjoin][topic payjoin] asynchrone. + +- [BOLTs #1232][] rend le champ `channel_type` (voir le Bulletin [#165][news165 type]) obligatoire + lors de l'ouverture d'un canal car chaque implémentation l'impose. Cette PR met également à jour + [BOLT9][] en ajoutant un nouveau type de contexte `T` pour les fonctionnalités qui peuvent être + incluses dans le champ `channel_type`. + +{% include snippets/recap-ad.md when="2025-07-29 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32521,31829,3801,3842,1890,1232" %} +[morehouse gosvuln]: https://delvingbitcoin.org/t/disclosure-lnd-gossip-timestamp-filter-dos/1859 +[tan ccw]: https://delvingbitcoin.org/t/chain-code-delegation-private-access-control-for-bitcoin-keys/1837 +[mpc]: https://en.wikipedia.org/wiki/Secure_multi-party_computation +[posner qc]: https://delvingbitcoin.org/t/post-quantum-hd-wallets-silent-payments-key-aggregation-and-threshold-signatures/1854 +[Libsecp256k1 v0.7.0]: https://github.com/bitcoin-core/secp256k1/releases/tag/v0.7.0 +[news340 sigops]: /fr/newsletters/2025/02/07/#introduire-une-limite-de-sigops-pour-les-entrees-legacy +[news304 orphan]: /fr/newsletters/2024/05/24/#bitcoin-core-30000 +[1p1c relay]: /fr/bitcoin-core-28-wallet-integration-guide/#relais-un-parent-un-enfant-1p1c +[news349 attributable]: /fr/newsletters/2025/04/11/#ldk-2256 +[news295 dual]: /fr/newsletters/2024/03/27/#ldk-2419 +[news165 type]: /en/newsletters/2021/09/08/#bolts-880 +[news362 orphan]: /fr/newsletters/2025/07/11/#bitcoin-core-pr-review-club \ No newline at end of file From 50058606eb188a6fb7424e703966ada228884d75 Mon Sep 17 00:00:00 2001 From: "Zhiwei(Jeffrey) Hu" Date: Wed, 30 Jul 2025 18:21:57 +0800 Subject: [PATCH 177/278] Newsletter-361: translate into Chinese (#2416) --- .../zh/newsletters/2025-07-04-newsletter.md | 159 ++++++++++++++++++ 1 file changed, 159 insertions(+) create mode 100644 _posts/zh/newsletters/2025-07-04-newsletter.md diff --git a/_posts/zh/newsletters/2025-07-04-newsletter.md b/_posts/zh/newsletters/2025-07-04-newsletter.md new file mode 100644 index 0000000000..de25fdd087 --- /dev/null +++ b/_posts/zh/newsletters/2025-07-04-newsletter.md @@ -0,0 +1,159 @@ +--- +title: 'Bitcoin Optech Newsletter #361' +permalink: /zh/newsletters/2025/07/04/ +name: 2025-07-04-newsletter-zh +slug: 2025-07-04-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的周报描述了一个提案，建议将用于洋葱消息中继的网络连接和对等节点管理与用于闪电网络中 HTLC 中继的分开。此外，还包括我们常规的部分，摘要了关于改变比特币共识的讨论，并列出了最近对流行比特币基础设施软件的更改。 + +## 新闻 + +- ******将洋葱消息中继与 HTLC 中继分开：** Olaluwa Osuntokun 在 Delving Bitcoin 上[发布][osuntokun onion]了关于允许节点使用不同的连接来中继[洋葱消息][topic onion messages]而不是用于中继[HTLC][topic htlc]的建议。虽然目前可能已经可以使用不同的连接，例如在直接中继的情况下（参见周报 [#283][news283 oniondirect]和 [#304][news304 onionreply]），Osuntokun 建议始终可以选择使用不同的连接，允许节点为洋葱消息拥有一组不同的对等节点，而不是用于中继支付的对等节点。他为这种替代方法提供了几个支持论点：它更清晰地分离了关注点，节点可以以更低的成本支持更高密度的洋葱消息对等节点，而不是通道对等节点（因为通道需要花费资金来创建），分离可能允许部署隐私改进的密钥轮换，并且分离可能允许洋葱消息的更快传递，因为不会被 HTLC 承诺通信协议阻塞。Osuntokun 提供了关于提议协议的具体细节。 + + 几位回复的开发者担心洋葱消息网络如何允许节点被过多的对等节点淹没。在当前的洋葱消息实现中，每个节点通常只与其通道合作伙伴保持连接。创建用于资助通道的 UTXO 需要花费资金（链上费用和机会成本），并且是节点和通道合作伙伴独有的；简而言之，它是 1 UTXO 对 1 连接。即使洋葱消息连接必须由链上资金支持，单个 UTXO 也可以用于与每个公共闪电网络节点建立连接：1 UTXO 对数千连接。 + + 尽管至少有一位回复者支持 Osuntokun 的提议，但到目前为止，几位回复者提到对拒绝服务风险的担忧。讨论在撰写本文时仍在进行中。 + +## 改变共识 + +_每月一节，摘要关于改变比特币共识规则的提案和讨论。_ + +- ******CTV+CSFS 对 PTLC 的优势：** 开发者继续之前的讨论（参见[周报 #348][news348 ctvstep]），关于[OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (CTV)、[OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (CSFS) 或两者结合对各种已部署和设想协议的好处。特别感兴趣的是，Gregory Sanders [写道][sanders ptlc]，CTV+CSFS “将加速[闪电网络]更新到[PTLCs][topic ptlc]，即使 [LN-Symmetry][topic eltoo] 本身未被采用。可重新绑定的签名在堆叠协议时可以不那么头疼。” Sjors Provoost [询问][provoost ptlc]了细节，Sanders [回复][sanders ptlc2]并附上了他之前关于 LN 消息为 PTLCs 修改的研究的[链接][sanders gist]（参见[周报 #268][news268 ptlc]），并补充说“在今天的协议上实现 PTLCs 并非不可能，但有了可重新绑定的签名，它就变得简单得多。” + + Anthony Towns 还[提到][towns ptlc]，“还缺乏工具/标准化来结合[多重签名][topic musig] 2-of-2 进行 PTLC 揭示（这在链上会很高效），甚至是一般的交易签名（即 `x CHECKSIGVERIFY y CHECKSIG`）。[...] 这需要 musig2 的适配器签名支持，而这不在规范中，并且已从 secp256k1 实现中[移除][libsecp256k1 #1479]。以较低效率作为单独的适配器签名也可以工作，但即使是普通的适配器签名对于 [schnorr 签名][topic schnorr signatures]在 secp256k1 中也不可用。这些也没有包括在更实验性的 secp256k1-zkp 项目中。[...] 如果工具准备就绪，我可以看到 PTLC 支持被添加[...] 但我不认为有人觉得这会是一个高优先级事项，而去投入工作来使加密内容标准化和完善。[...] 如果 [CAT][topic op_cat]+CSFS 可用，就能避免工具问题，成本仅与链上效率有关。[...] 仅有 CSFS 可用时，你仍然会遇到类似的工具问题，因为你需要使用适配器签名来防止你的对手为签名选择不同的 R 值。这些问题与 Gregory Sanders 上述描述的更新复杂性和对等协议更新无关。” + +- ******保险库输出脚本描述符：** Sjors Provoost [发布][provoost ctvdesc]到 Delving Bitcoin，讨论如何使用[保险库][topic vaults]的钱包恢复信息可以使用[输出脚本描述符][topic descriptors]来指定。特别是，他重点讨论了基于 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (CTV) 的保险库，例如 James O'Beirne 的[simple-ctv-vault][] 概念验证实现（参见[周报 #191][news191 simple-ctv-vault]）。 + + Provoost 引用了 Salvatore Ingala 在之前讨论中的[评论][ingala vaultdesc]，他说：“我的总体看法是，描述符不是用于这个目的的正确工具”——Sanket Kanjalkar 在当前讨论帖中[同意][kanjalkar vaultdesc1]这一观点，但[找到了][kanjalkar vaultdesc2]一个潜在的解决方法。Kanjalkar 描述了一种变体 CTV 基础的保险库，其中资金被存入一个更典型的描述符，然后从那里转移到 CTV 保险库。这避免了可能导致不熟练的用户丢失资金的情况，并且还允许创建一个假设所有支付给典型描述符的资金都使用相同设置每次转移到保险库的描述符。这将允许 CTV 保险库描述符简洁而完整，而无需对描述符语言进行任何修改。 + +- ******关于 CTV+CSFS 对 BitVM 优势的持续讨论：** 开发者继续之前的讨论（参见[周报 #354][news354 bitvm]），关于[OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (CTV) 和[OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (CSFS) 操作码如何“将 [BitVM] 交易大小减少约 10 倍”并允许非交互式的 peg-ins。Anthony Towns [识别][towns ctvbitvm]了原始提议合约中的一个漏洞；他和其他几位开发者描述了解决方法。额外的讨论着眼于使用提议的 [OP_TXHASH][] 操作码相较于 CTV 的优势。Chris Stewart 使用 Bitcoin Core 的测试软件[实现][stewart ctvimp]了一些讨论的想法，验证了讨论的那些部分并为审阅者提供了具体示例。 + +- ******关于 CTV 和 CSFS 的公开信：** James O'Beirne [发布][obeirne letter]了一封公开信给 Bitcoin-Dev 邮件列表，由 66 人（截至撰写本文时）签署，其中许多人是比特币相关项目的贡献者。信中“要求 Bitcoin Core 贡献者在接下来的六个月内优先审核和整合 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (CTV) 和 [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (CSFS)。” 该讨论包含超过 60 条回复。一些技术亮点包括： + + - *对遗留支持的担忧和替代方案：* [BIP119][] 指定了 CTV 用于见证脚本 v1（[tapscript][topic tapscript]）和遗留脚本。Gregory Sanders [写道][sanders legacy]，“遗留脚本支持[...]显著增加了审核面，没有已知的能力增益，也没有已知的协议节省。” O'Beirne [回复][obeirne legacy]，遗留脚本支持在某些情况下可以节省大约 8 vbytes，但 Sanders [链接][sanders p2ctv]到他之前的 pay-to-CTV (P2CTV) 提议和概念验证实现，使这种节省在见证脚本中可用。 + + - *仅 CTV 保险库支持的限制：* 签署者 Jameson Lopp [指出][lopp ctvvaults]，他“最感兴趣的是[保险库][topic vaults]，”开始了一场关于 CTV 保险库将提供的属性集、它们与今天使用预签名交易可部署的保险库的比较，以及它们是否在安全性上提供了有意义的改进（尤其是与需要额外共识更改的更高级保险库相比）的讨论。该讨论的关键要点包括： + + - *地址重用的危险：* 预签名和 CTV 保险库都必须防止用户重用保险库地址，否则资金可能会丢失。可以通过两步保险库程序来实现这一点，要求两次链上交易将资金存入保险库。需要额外共识更改的更高级保险库不会有这个问题，允许即使是重用地址的存款（尽管这当然会[降低隐私][topic output linking]）。 + + - *分阶段资金的盗窃：* 预签名和 CTV 保险库都允许授权取款的盗窃。例如，保险库用户 Bob 想要支付 1 BTC 给 Alice。使用预签名和 CTV 保险库，Bob 使用以下程序： + + - 从他的保险库中提取 1 BTC（加上可能的费用）到一个临时等待地址。 + + - 等待保险库定义的时间。 + + - 转账 1 BTC 给 Alice。 + + 如果 Mallory 窃取了 Bob 等待地址的密钥，她可以在取款完成后但在转账给 Alice 确认之前窃取 1 BTC。然而，即使 Mallory 也窃取了取款密钥，她也无法窃取保险库中剩余的资金，因为 Bob 可以中断任何待处理的取款并将资金重定向到由超安全密钥（或密钥）保护的_安全地址_。 + + 更高级的保险库不需要该等待步骤：Bob 的取款只能去 Alice 或安全地址。这防止了 Mallory 能够在取款和支出步骤之间窃取资金。 + + - *密钥删除：* CTV 基础保险库相对于预签名保险库的一个优势是，它们不需要删除私钥以确保预签名交易集是唯一可用的支出选项。然而，Gregory Maxwell [指出][maxwell autodelete]，设计软件以在签署交易后立即删除密钥而不向用户暴露私钥是简单的。目前没有已知的硬件签名设备直接支持这一点，尽管至少有一个设备通过手动用户干预支持这一点——但同样，（据我们所知）即使是测试目前也没有硬件支持 CTV。更高级的保险库将共享 CTV 的无密钥优势，但也需要集成到软件和硬件中。 + + - *静态状态：* 基于 CTV 的保险库相对于预签名保险库的一个声称的优势是，可能可以从静态备份中计算出恢复钱包所需的所有信息，例如[输出脚本描述符][topic descriptors]。然而，已经有关于预签名保险库的工作，也允许通过在链上交易中存储预签名状态的非确定性部分来实现静态备份（参见[周报 #255][news255 presig vault state]）。Optech 认为更高级的保险库也可以从静态状态恢复，但我们在截稿时尚未验证这一点。 + + - *来自 Bitcoin Core 贡献者的回复：* 截至撰写本文时，Optech 识别的四位目前活跃的 Bitcoin Core 贡献者在邮件列表中回复了这封信。他们说： + + - [Gregory Sanders][sanders ctvcom]：“这封信向技术社区征求反馈意见，而这是我的反馈意见。未部署的 BIP 多年来没有收到任何更新，通常不是提案健康的标志，当然也不是拒绝来自密切关注的人的技术建议的论据。我拒绝这种框架，它是将对该提案的更改门槛提高到仅存明显的破坏，并且我显然拒绝对 BIP119 的时间限制。我仍然认为 CTV（再次在能力意义上）+ CSFS 值得考虑，但这种方式肯定会让它失败。” + + - [Anthony Towns][towns ctvcom]：“从我的角度来看，CTV 讨论丢失了一些重要步骤，取而代之的是倡导者一直试图使用公众压力强迫采用‘加速时间表’，至少在过去三年中一直如此。我试图帮助 CTV 倡导者们采用我认为他们遗失的步骤，但这主要带来的是沉默或侮辱，而不是任何建设性的东西。至少从我的角度来看，这只是创造了激励问题，而不是解决它们。” + + - [Antoine Poinsot][poinsot ctvcom]：“这封信的效果是，正如预期的那样，在推进这个提案（或更广泛的能力捆绑）方面造成了重大挫折。我不确定我们如何从中反弹，但这必然涉及到有人要站出来，实际做出回应社区的技术反馈并展示（真实的）用例。前进的道路必须是通过在强有力的客观、技术论据的基础上建立共识。不是一群人表示兴趣，而没有人站出来帮助提案向前推进。” + + - [Sjors Provoost][provoost ctvcom]：“让我也谈谈我自己的动机。保险库似乎是提案启用的唯一功能，我个人认为重要到值得为之工作。[...] 直到最近，我似乎认为保险库的势头在于 OP_VAULT，而这反过来又需要 OP_CTV。但单一目的的操作码并不理想，所以这个项目似乎没有进展。[...] 相反，我不反对 CTV + CSFS；我没有看到它们有害的论据。由于几乎没有 MeVil 潜力，我也可以想象其他开发者小心地开发和推出这些更改。我只会关注这个过程。我_会_反对的是像共同签署人 Paul Sztorc 提议的基于 Python 的替代实现和激活客户端。” + + - *签署者声明：* 信的签署者在后续声明中也澄清了他们的意图： + + - [James O'Beirne][obeirne ctvcom]：“每个签署者都明确希望看到 CTV+CSFS 的将被审核、整合和激活计划。” + + - [Andrew Poelstra][poelstra ctvcom]：“该封信的早期草案确实要求实际整合甚至激活，但我没有签署任何这些早期草案。在用语被减弱为关于优先级和计划（并且是一个‘礼貌的请求’而不是某种要求）时，我才签署的。” + + - [Steven Roose][roose ctvcom]：“[这封信]只是要求 Core 贡献者以某种紧迫性将此提案列入议程。没有威胁，没有严厉的话。鉴于到目前为止只有少数 Core 贡献者参与了其他地方的提案对话，这似乎是一个合适的下一步，以传达我们希望 Core 贡献者在此对话中提供他们的立场。我强烈反对涉及独立激活客户端的方法，我认为这封电子邮件的情感与希望 Core 参与任何协议升级部署的偏好一致。” + + - [Harsha Goli][goli ctvcom]：“大多数人签署是因为他们真的不知道下一步应该是什么，而交易承诺的压力如此之大，以至于一个糟糕的选择（签署信）比不作为更优。在信件发出前的对话中（由我的行业调查促成），我只收到许多签署者对信的责备。我实际上不知道有任何一个人明确认为这是一个好主意。即便如此，他们还是签了名。这其中暗藏玄机。” + +- ******OP_CAT 启用 Winternitz 签名：** 开发者 Conduition 在 Bitcoin-Dev 邮件列表上[发布][conduition winternitz]了一个[原型实现][conduition impl]，使用提议的 [OP_CAT][topic op_cat] 操作码和其他脚本指令，允许使用 Winternitz 协议的[量子抗性][topic quantum resistance]签名由共识逻辑验证。Conduition 的实现需要近 8,000 字节的密钥、签名和脚本（大部分受见证折扣影响，减少链上重量到约 2,000 vbytes）。这比 Jeremy Rubin 之前提议的另一个基于 `OP_CAT` 的量子抗性[Lamport 签名][Lamport signature]方案小约 8,000 vbytes。 + +- ******用于后量子恢复的承诺/揭示功能：** Tadge Dryja 在 Bitcoin-Dev 邮件列表上[发布][dryja fawkes]了一种方法，允许个人使用[对量子脆弱][topic quantum resistance]的签名算法花费 UTXO，即使快速量子计算机会允许重定向（窃取）任何尝试花费的输出。这需要一个软分叉，并且是 Tim Ruffing 之前提议的变体（参见[周报 #348][news348 fawkes]）。 + + 在 Dryja 的方案中，花费者创建了对三部分数据的承诺： + + 1. 控制资金的私钥对应的公钥的哈希，`h(pubkey)`。这被称为_地址标识符_。 + + 2. 公钥和花费者想要最终广播的交易的 txid 的哈希，`h(pubkey, txid)`。这被称为_序列依赖证明_。 + + 3. 最终交易的 txid。这被称为_承诺 txid_。 + + 这些信息都没有揭示底层公钥，在这个方案中，假设只有控制 UTXO 的人知道。 + + 三部分承诺使用量子安全算法广播在交易中，例如作为 `OP_RETURN` 输出。在这一点上，攻击者可以尝试使用相同的地址标识符但不同的承诺 txid 广播他们自己的承诺，将资金转移到攻击者的钱包。然而，攻击者无法生成有效的序列依赖证明，因为他们不知道底层公钥。这对全验证节点来说不会立即显而易见，但在 UTXO 所有者揭示公钥后，他们将能够拒绝攻击者的承诺。 + + 在承诺确认到适当深度后，花费者揭示与承诺 txid 匹配的完整交易。全节点验证公钥与地址标识符匹配，并且结合 txid，它与序列依赖证明匹配。此刻，全节点移除该地址标识符的除了最早（最深确认）的承诺以外的其他承诺。只有第一个确认的 txid 对于该地址标识符具有有效的序列依赖证明可以解析为确认交易。 + + Dryja 详细介绍了如何将此方案作为软分叉部署，如何将承诺字节减少一半，以及今天的用户和软件可以做些什么来准备使用此方案——以及此方案对使用脚本和[无脚本多重签名][topic multisignature]的用户的限制。 + +- ******支持交易赞助的 OP_TXHASH 变体：** Steven Roose 在 Delving Bitcoin 上[发布][roose txsighash]了一个名为 `TXSIGHASH` 的 `OP_TXHASH` 变体，扩展了 64 字节的 [schnorr 签名][topic schnorr signatures]，附加字节以指示签名承诺的交易字段（或相关交易）。除了 `OP_TXHASH` 先前提议的承诺字段外，Roose 指出签名可以使用一种高效的[交易赞助][topic fee sponsorship]形式承诺到区块中的早期交易（参见[周报 #295][news295 sponsor]）。然后他分析了这种机制相对于现有 [CPFP][topic cpfp] 和之前的赞助提议的链上成本，得出结论：“使用 [`TXSIGHASH`] 堆叠，每个堆叠交易的虚拟字节成本甚至可以低于没有赞助的原始成本[...]此外，所有输入都是‘简单’的密钥花费，这意味着如果 [CISA][topic cisa] 被部署，它们可以被聚合。” + + 截至撰写本文时，帖子尚未收到任何公开回复。 + +## 重要代码和文档更改 + +_[Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[硬件钱包接口 (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案 (BIPs)][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo]中的重要近期更改。_ + +- [Bitcoin Core #32540][] 引入了 `/rest/spenttxouts/BLOCKHASH` REST 端点，返回指定区块的已花费交易输出（prevouts）列表，主要以紧凑的二进制（.bin）格式，但也有 .json 和 .hex 变体。虽然以前可以使用 `/rest/block/BLOCKHASH.json` 端点做到这一点，但新端点通过消除 JSON 序列化开销提高了外部索引器的性能。 + +- [Bitcoin Core #32638][] 添加了验证，以确保从磁盘读取的任何区块与预期的区块哈希匹配，捕捉可能以前未被注意到的比特腐败和索引混淆。由于在 [Bitcoin Core #32487][] 中引入的头哈希缓存，这个额外的检查几乎没有开销。 + +- [Bitcoin Core #32819][] 和 [#32530][Bitcoin Core #32530] 将 `-maxmempool` 和 `-dbcache` 启动参数的最大值分别设置为 500 MB 和 1 GB，在 32 位系统上。由于该架构的总 RAM 限制为 4 GB，高于新限制的值可能导致内存不足（OOM）事件。 + +- [LDK #3618][] 实现了[异步支付][topic async payments]的客户端逻辑，允许离线接收节点与始终在线的辅助 LSP 节点预先安排 [BOLT12 offer][topic offers]和静态发票。PR 在 `ChannelManager` 中引入了一个异步接收 offer 的缓存，构建、存储和持久化要约和发票。它还定义了与 LSP 通信所需的新洋葱消息和钩子，并通过 `OffersMessageFlow` 线程化状态机。 + +{% include snippets/recap-ad.md when="2025-07-08 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32540,32638,32819,3618,1479,32487,32530" %} +[news255 presig vault state]: /zh/newsletters/2023/06/14/#discussion-about-the-taproot-annex-taproot-annex +[news348 ctvstep]: /zh/newsletters/2025/04/04/#ctv-csfs-benefits +[news268 ptlc]: /zh/newsletters/2023/09/13/#ptlc-ln +[news191 simple-ctv-vault]: /zh/newsletters/2022/03/16/#continued-ctv-discussion +[news354 bitvm]: /zh/newsletters/2025/05/16/#description-of-benefits-to-bitvm-from-op-ctv-and-op-csfs +[rubin lamport]: https://gnusha.org/pi/bitcoindev/CAD5xwhgzR8e5r1e4H-5EH2mSsE1V39dd06+TgYniFnXFSBqLxw@mail.gmail.com/ +[osuntokun onion]: https://delvingbitcoin.org/t/reimagining-onion-messages-as-an-overlay-layer/1799/ +[news283 oniondirect]: /zh/newsletters/2024/01/03/#ldk-2723 +[news304 onionreply]: /zh/newsletters/2024/05/24/#core-lightning-7304 +[sanders ptlc]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/7 +[provoost ptlc]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/80 +[sanders ptlc2]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/81 +[sanders gist]: https://gist.github.com/instagibbs/1d02d0251640c250ceea1c66665ec163 +[towns ptlc]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/82 +[provoost ctvdesc]: https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766/ +[simple-ctv-vault]: https://github.com/jamesob/simple-ctv-vault +[ingala vaultdesc]: https://github.com/bitcoin/bips/pull/1793#issuecomment-2749295131 +[kanjalkar vaultdesc1]: https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766/3 +[kanjalkar vaultdesc2]: https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766/9 +[towns ctvbitvm]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/8 +[op_txhash]: /zh/newsletters/2022/02/02/#composable-alternatives-to-ctv-and-apo +[stewart ctvimp]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/25 +[obeirne letter]: https://mailing-list.bitcoindevs.xyz/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com/ +[sanders legacy]: https://mailing-list.bitcoindevs.xyz/bitcoindev/b17d0544-d292-4b4d-98c6-fa8dc4ef573cn@googlegroups.com/ +[obeirne legacy]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPfvXfKEgA0RCvxR=mP70sfvpzTphTZGidy=JuSK8f1WnM9xYA@mail.gmail.com/ +[sanders p2ctv]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/72?u=harding +[lopp ctvvaults]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CADL_X_fxwKLdst9tYQqabUsJgu47xhCbwpmyq97ZB-SLWQC9Xw@mail.gmail.com/ +[maxwell autodelete]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAAS2fgSmmDmEhi3y39MgQj+pKCbksMoVmV_SgQmqMOqfWY_QLg@mail.gmail.com/ +[sanders ctvcom]: https://groups.google.com/g/bitcoindev/c/KJF6A55DPJ8/m/XVhyLCJiBQAJ +[towns ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aEu8CqGH0lX5cBRD@erisian.com.au/ +[poinsot ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/GLGZ3rEDfqaW8jAfIA6ac78uQzjEdYQaJf3ER9gd4e-wBXsiS2NK0wAj8LWK8VHf7w6Zru3IKbtDU5NM102jD8wMjjw8y7FmiDtQIy9U7Y4=@protonmail.com/ +[provoost ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/0B7CEBEE-FB2B-41CF-9347-B9C1C246B94D@sprovoost.nl/ +[obeirne ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAPfvXfLc5-=UVpcvYrC=VP7rLRroFviLTjPQfeqMQesjziL=CQ@mail.gmail.com/ +[poelstra ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aEsvtpiLWoDsfZrN@mail.wpsoftware.net/ +[roose ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/035f8b9c-9711-4edb-9d01-bef4a96320e1@roose.io/ +[goli ctvcom]: https://mailing-list.bitcoindevs.xyz/bitcoindev/mc0q6r14.59407778-1eb1-4e57-bcf2-c781d6f70b01@we.are.superhuman.com/ +[conduition winternitz]: https://mailing-list.bitcoindevs.xyz/bitcoindev/uCSokD_EM3XBQBiVIEeju5mPOy2OU-TTAQaavyo0Zs8s2GhAdokhJXLFpcBpG9cKF03dNZfq2kqO-PpxXouSIHsDosjYhdBGkFArC5yIHU0=@proton.me/ +[conduition impl]: https://gist.github.com/conduition/c6fd78e90c21f669fad7e3b5fe113182 +[lamport signature]: https://en.wikipedia.org/wiki/Lamport_signature +[dryja fawkes]: https://mailing-list.bitcoindevs.xyz/bitcoindev/cc2f8908-f6fa-45aa-93d7-6f926f9ba627n@googlegroups.com/ +[news348 fawkes]: /zh/newsletters/2025/04/04/#securely-proving-utxo-ownership-by-revealing-a-sha256-preimage +[roose txsighash]: https://delvingbitcoin.org/t/jit-fees-with-txhash-comparing-options-for-sponsorring-and-stacking/1760 +[news295 sponsor]: /zh/newsletters/2024/03/27/#transaction-fee-sponsorship-improvements From 095e3c99533982764cbc64bdc2839fd1693ef205 Mon Sep 17 00:00:00 2001 From: Jiri Jakes Date: Mon, 28 Jul 2025 06:32:27 +0800 Subject: [PATCH 178/278] Newsletter-360: Translate into Czech --- .../cs/newsletters/2025-06-27-newsletter.md | 151 ++++++++++++++++++ 1 file changed, 151 insertions(+) create mode 100644 _posts/cs/newsletters/2025-06-27-newsletter.md diff --git a/_posts/cs/newsletters/2025-06-27-newsletter.md b/_posts/cs/newsletters/2025-06-27-newsletter.md new file mode 100644 index 0000000000..06d24be3f1 --- /dev/null +++ b/_posts/cs/newsletters/2025-06-27-newsletter.md @@ -0,0 +1,151 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 360' +permalink: /cs/newsletters/2025/06/27/ +name: 2025-06-27-newsletter-cs +slug: 2025-06-27-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden shrnuje výzkum identifikace plných uzlů pomocí zpráv +P2P protokolu a žádá o zpětnou vazbu ke zvažovanému odstranění podpory +pro `H` v BIP32 cestách v BIP380 specifikaci deskriptorů. Též nechybí +naše pravidelné rubriky se souhrnem nejoblíbenějších otázek a odpovědí +z Bitcoin Stack Exchange, oznámeními nových vydání a popisem významných +změn v populárním bitcoinovém páteřním software. + +## Novinky + +- **Detekce uzlů pomocí zpráv `addr`:** Daniela Brozzoni + zaslala do fóra Delving Bitcoin [příspěvek][brozzoni addr] o výzkumu, + který provedla s vývojářem Naiyoma. Výzkum se týkal identifikace + stejného uzlu napříč sítěmi na základě zasílaných zpráv `addr`. + Uzly v rámci decentralizovaného gossip systému posílají zprávy + `addr` svým spojením, aby je informovaly o dalších známých uzlech, + čímž uzlům pomáhají se navzájem najít. Brozzoni a Naiyoma však byli + schopni detekovat jednotlivé uzly díky drobnostem v jejich `addr` + zprávách. To jim pomohlo identifikovat uzel provozovaný ve více + různých sítích (jako IPv4 a [Tor][topic anonymity networks]). + + Výzkumníci navrhují dvě možná opatření: odstranit ze zpráv časová + razítka, nebo je mírně náhodně upravit, aby nebyla příliš specifická. + +- **Používá některý software v deskriptorech `H`?** Ava Chow zaslala do emailové + skupiny Bitcoin-Dev [příspěvek][chow hard] s dotazem, zda nějaký software + generuje deskriptory používající velké `H` k indikaci hardened derivace + potomka dle [BIP32][topic bip32]. Pokud ne, bude možné upravit [BIP380][], + specifikaci [deskriptorů výstupních skriptů][topic descriptors], aby povolovala + pouze malé `h` a `'`. Chow poznamenává, že ačkoliv BIP32 velké `H` umožňuje, + BIP380 dříve obsahovala test, který použití velkého `H` vylučoval. Bitcoin + Core v současnosti velké `H` též neakceptuje. + +## Vybrané otázky a odpovědi z Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] je jedním z prvních míst, kde hledají +přispěvatelé Optechu odpovědi na své otázky a kde – najdou-li volnou chvíli – +pomáhají zvědavým či zmateným uživatelům. V této měsíční rubrice nabízíme +některé z otázek a odpovědí, které obdržely vysoký počet hlasů.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Existuje způsob, jak uzlu zakázat spojení s Bitcoin Knots?]({{bse}}127456) + Vojtěch Strnad poskytuje možnost blokování spojení na základě názvu + klienta pomocí dvou RPC Bitcoin Core, avšak od podobného přístupu odrazuje + a poukazuje na související [tiket][Bitcoin Core #30036] v projektu Bitcoin + Core. + +- [Co OP_CAT dělá s celými čísly?]({{bse}}127436) + Pieter Wuille vysvětluje, že položky v zásobníku Bitcoin Scriptu neobsahují + informace a datových typech. Různé opkódy interpretují bajty v zásobníku + různými způsoby. + +- [Asynchronní přeposílání bloků a přeposílání kompaktních bloků (BIP152)]({{bse}}127420) + Uživatel bca-0353f40e ukazuje, jako Bitcoin Core nakládá s [kompaktními bloky][topic + compact block relay] a odhaduje, jaký dopad mají chybějící transakce na propagaci + bloků. + +- [Proč není útočníkova odměna v sobecké těžbě úměrná jeho hashrate?]({{bse}}53030) + Antoine Poinsot přidává reakci k této a [jiné]({{bse}}125682) starší otázce ohledně + [sobecké těžby][topic selfish mining]. Poznamenává, že „úprava obtížnosti + nebere v potaz zastaralé bloky, což znamená, že snižující se efektivní hashrate + konkurence zvyšuje těžařovy výdělky (v dostatečně dlouhém časovém měřítku) stejně + jako jeho vlastní“ (viz [zpravodaj č. 358][news358 selfish mining]). + +## Vydání nových verzí + +*Vydání nových verzí oblíbených páteřních bitcoinových projektů. Prosíme, +zvažte upgrade či pomoc s testováním.* + +- [Bitcoin Core 28.2][] je údržbové vydání předchozí série této + převládající implementace plného uzlu. Obsahuj opravy několika chyb. + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo] a [repozitáři BINANA][binana repo]._ + +- [Bitcoin Core #31981][] přidává do rozhraní `Mining` (viz [zpravodaj + č. 310][news310 ipc]) meziprocesové komunikace (IPC) metodu `checkBlock`, + který provádí stejné kontroly jako RPC `getblocktemplate` v režimu + `proposal`. Těžební pooly tím mohou použít [Stratum v2][topic pooled + mining] pro validaci šablon bloků poskytnutých těžaři přes rychlejší + IPC rozhraní, než je posílání po RPC až 4 MB dat serializovaných do JSON. + Kontroly proof of work a kořene Merkleova stromu mohou být vypnuty. + +- [Eclair #3109][] rozšiřuje podporu [informací o původci chyb][topic attributable + failures] (attributable failures, viz [zpravodaj č. 356][news356 failures]) + na [trampolínové platby][topic trampoline payments]. Trampolínový uzel nově + dešifruje a uloží část informací o původci chyby, která je určená pro něj, + a připraví data pro další skok. Toto PR zatím neimplementuje samotné přeposílání + dat o původci chyb dalším skokům v trampolínové cestě. + +- [LND #9950][] přidává do RPC `DescribeGraph`, `GetNodeInfo` a `GetChanInfo` + a jim odpovídajících `lncli` příkazů příznak `include_auth_proof`. Ten vrátí + podpisy [oznámení kanálu][topic channel announcements], které mohou + být použité jiným software k validaci podrobností o kanálech. + +- [LDK #3868][] snižuje přesnost měření času pro držení [HTLC][topic htlc] pro + [informace o původci chyb][topic attributable failures] (viz [zpravodaj č. + 349][news349 attributable]) z jednomilisekundových jednotek na stomilisekundové. + Cílem je bránit detekci prováděním otisků. Změna byla provedena po nedávné + aktualizaci návrhu [BOLTs #1044][]. + +- [LDK #3873][] navyšuje časovou prodlevu před zapomenutím krátkého identifikátoru + kanálu (SCID) z 12 na 144 bloků poté, co je utracen zakládající výstup. + Cílem je zlepšit propagaci [spliců][topic splicing]. Jedná se o dvojnásobek + hodnoty v Eclair (viz [zpravodaj č. 359][news359 eclair]). PR dále přidává + další změny ve výměně zpráv `splice_locked`. + +- [Libsecp256k1 #1678][] přidává do CMake `secp256k1_objs`, které zveřejňuje všechny + objektové soubory této knihovny. Díky tomu je mohou rodičovské projekty jako + plánovaný [libbitcoinkernel][libbitcoinkernel project] v Bitcoin Core + linkovat napřímo do svých vlastních statických knihoven. Jedná se o řešení + chybějícího nativního mechanismu pro linkování statických knihoven v CMake, + díky kterému nemusí jiné projekty poskytovat vlastní sestavení `libsecp256k1`. + +- [BIPs #1803][] povoluje v gramatice [deskriptorů][topic descriptors] v [BIP380][] + všechny běžně používané značky pro hardened potomky BIP32 derivační cesty. + Dále [#1871][bips #1871], [#1867][bips #1867] a [#1866][bips #1866] upravují + deskriptory [MuSig2][topic musig] v [BIP390][]: zpřísňují pravidla specifikování + klíčů, povolují opakované veřejné klíče a explicitně zakazují vícenásobné derivace + potomků. + +{% include snippets/recap-ad.md when="2025-07-01 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31981,3109,9950,3868,3873,1678,1803,1871,1867,1866,30036,1044,1270" %} +[bitcoin core 28.2]: https://bitcoincore.org/bin/bitcoin-core-28.2/ +[brozzoni addr]: https://delvingbitcoin.org/t/fingerprinting-nodes-via-addr-requests/1786/ +[chow hard]: https://mailing-list.bitcoindevs.xyz/bitcoindev/848d3d4b-94a5-4e7c-b178-62cf5015b65f@achow101.com/T/#u +[news358 selfish mining]: /cs/newsletters/2025/06/13/#vypocet-prahu-sobecke-tezby +[news310 ipc]: /cs/newsletters/2024/07/05/#bitcoin-core-30200 +[news356 failures]: /cs/newsletters/2025/05/30/#eclair-3065 +[news349 attributable]: /cs/newsletters/2025/04/11/#ldk-2256 +[news359 eclair]: /cs/newsletters/2025/06/20/#eclair-3110 +[libbitcoinkernel project]: https://github.com/bitcoin/bitcoin/issues/27587 From 92e34f5c4ab3284f8a1f4e61c7a17d2550db3082 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 31 Jul 2025 10:10:42 -0500 Subject: [PATCH 179/278] Podcast: add 364 recap --- .../en/newsletters/2025-07-25-newsletter.md | 26 +++++++++---------- .../en/podcast/2025-07-29-newsletter-recap.md | 23 ++++++++++++++++ 2 files changed, 36 insertions(+), 13 deletions(-) create mode 100644 _posts/en/podcast/2025-07-29-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-07-25-newsletter.md b/_posts/en/newsletters/2025-07-25-newsletter.md index 4f865fc71c..27fbb9ec40 100644 --- a/_posts/en/newsletters/2025-07-25-newsletter.md +++ b/_posts/en/newsletters/2025-07-25-newsletter.md @@ -24,7 +24,7 @@ popular Bitcoin infrastructure software. disclosed][topic responsible disclosures]. An attacker could repeatedly request historic gossip messages from an LND node until it ran out of memory and was terminated. The vulnerability was fixed in - LND 0.18.3, released September 2024. + LND 0.18.3, released September 2024. {% assign timestamp="0:53" %} - **Chain code withholding for multisig scripts:** Jurvis Tan [posted][tan ccw] to Delving Bitcoin about research he performed with @@ -76,7 +76,7 @@ popular Bitcoin infrastructure software. Some providers may require that the change output for a spending transaction sends the money back to the same script template. Tan's - post describes how this can easily be accomplished. + post describes how this can easily be accomplished. {% assign timestamp="15:16" %} - **Research indicates common Bitcoin primitives are compatible with quantum-resistant signature algorithms:** Jesse Posner [posted][posner qc] to Delving Bitcoin several links to @@ -85,7 +85,7 @@ popular Bitcoin infrastructure software. those currently used in Bitcoin for [BIP32 HD wallets][topic bip32], [silent payment addresses][topic silent payments], [scriptless multisignatures][topic multisignature], and [scriptless threshold - signatures][topic threshold signature]. + signatures][topic threshold signature]. {% assign timestamp="38:46" %} ## Selected Q&A from Bitcoin Stack Exchange @@ -100,16 +100,16 @@ answers posted since our last update.* - [How does Bitcoin Core handle reorgs larger than 10 blocks?]({{bse}}127512) TheCharlatan links to Bitcoin Core code that handles chain reorganizations by - only re-adding a maximum of 10 blocks worth of transactions to the mempool. + only re-adding a maximum of 10 blocks worth of transactions to the mempool. {% assign timestamp="57:36" %} - [Advantages of a signing device over an encrypted drive?]({{bse}}127596) RedGrittyBrick points out that data on an encrypted drive can be extracted while the drive is unencrypted whereas hardware signing devices are designed to - prevent this data extraction attack. + prevent this data extraction attack. {% assign timestamp="1:01:29" %} - [Spending a taproot output through the keypath and scriptpath?]({{bse}}127601) Antoine Poinsot details how the use of merkle trees, key tweaks, and leaf - scripts achieves taproot's keypath and scriptpath spending capabilities. + scripts achieves taproot's keypath and scriptpath spending capabilities. {% assign timestamp="1:03:21" %} ## Releases and release candidates @@ -119,7 +119,7 @@ release candidates._ - [Libsecp256k1 v0.7.0][] is a release of this library containing cryptographic primitives compatible with Bitcoin. It contains a few - small changes that break API/ABI compatibility with previous releases. + small changes that break API/ABI compatibility with previous releases. {% assign timestamp="1:04:36" %} ## Notable code and documentation changes @@ -138,7 +138,7 @@ repo], and [BINANAs][binana repo]._ enforce the limit at the consensus level. If the softfork took place without this change, miners who don’t upgrade could become targets of trivial DoS attacks. See Newsletter [#340][news340 sigops] for additional details on the - legacy input sigops limit. + legacy input sigops limit. {% assign timestamp="1:05:16" %} - [Bitcoin Core #31829][] adds resource limits to the orphan transaction handler, `TxOrphanage` (See Newsletter [#304][news304 orphan]), to preserve @@ -152,29 +152,29 @@ repo], and [BINANAs][binana repo]._ `‑maxorphantxs` option (default 100), whose policy of evicting random announcements allowed attackers to replace the entire orphan set and render [1p1c relay][1p1c relay] useless. See also [Newsletter #362][news362 - orphan]. + orphan]. {% assign timestamp="1:15:00" %} - [LDK #3801][] extends [attributable failures][topic attributable failures] to the payment success path by recording how long a node holds an [HTLC][topic htlc] and propagating those hold‑time values upstream in the attribution payload. Previously, LDK only tracked hold times for failed payments (see - Newsletter [#349][news349 attributable]). + Newsletter [#349][news349 attributable]). {% assign timestamp="1:19:51" %} - [LDK #3842][] extends its [interactive transaction construction][topic dual funding] state machine (See Newsletter [#295][news295 dual]) to handle the signing coordination for shared inputs in [splicing][topic splicing] transactions. The `prevtx` field of the `TxAddInput` message is made optional - to reduce memory usage and simplify validation. + to reduce memory usage and simplify validation. {% assign timestamp="1:21:11" %} - [BIPs #1890][] changes the separator parameter from `+` to `-` in [BIP77][] because some HTML 2.0 URI libraries treat `+` as if it is a blank space. In addition, fragment parameters must now be ordered lexicographically, rather - than in reverse, to simplify the async [payjoin][topic payjoin] protocol. + than in reverse, to simplify the async [payjoin][topic payjoin] protocol. {% assign timestamp="1:21:57" %} - [BOLTs #1232][] makes the `channel_type` field (see Newsletter [#165][news165 type]) mandatory when opening a channel because every implementation enforces it. This PR also updates [BOLT9][] by adding a new context type `T` for - features that can be included in the `channel_type` field. + features that can be included in the `channel_type` field. {% assign timestamp="1:23:53" %} {% include snippets/recap-ad.md when="2025-07-29 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-07-29-newsletter-recap.md b/_posts/en/podcast/2025-07-29-newsletter-recap.md new file mode 100644 index 0000000000..215879ed97 --- /dev/null +++ b/_posts/en/podcast/2025-07-29-newsletter-recap.md @@ -0,0 +1,23 @@ +--- +title: 'Bitcoin Optech Newsletter #364 Recap Podcast' +permalink: /en/podcast/2025/07/29/ +reference: /en/newsletters/2025/07/25/ +name: 2025-07-29-recap +slug: 2025-07-29-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt are joined by Matt Morehouse and Jesse Posner to discuss [Newsletter #364]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-6-31/404891918-44100-2-eb6b0d281c481.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From 77532d8cbc1f1e56ffe5173d1ec7ad7da2068ded Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Wed, 30 Jul 2025 01:34:59 -1000 Subject: [PATCH 180/278] Newsletters: add 365 (2025-08-01) --- .../en/newsletters/2025-08-01-newsletter.md | 224 ++++++++++++++++++ 1 file changed, 224 insertions(+) create mode 100644 _posts/en/newsletters/2025-08-01-newsletter.md diff --git a/_posts/en/newsletters/2025-08-01-newsletter.md b/_posts/en/newsletters/2025-08-01-newsletter.md new file mode 100644 index 0000000000..351e33cd9a --- /dev/null +++ b/_posts/en/newsletters/2025-08-01-newsletter.md @@ -0,0 +1,224 @@ +--- +title: 'Bitcoin Optech Newsletter #365' +permalink: /en/newsletters/2025/08/01/ +name: 2025-08-01-newsletter +slug: 2025-08-01-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter summarizes the results of a test of compact block +relay prefilling and links to a mempool-based fee estimation library. +Also included are our regular sections summarizing discussion about +changing Bitcoin's consensus rules, announcing new releases and release +candidates, and describing notable changes to popular Bitcoin +infrastructure software. + +## News + +- **Testing compact block prefilling:** David Gumberg [replied][gumberg + prefilling] to a Delving Bitcoin thread about compact block + reconstruction efficiency (previously covered in Newsletters + [#315][news315 cb] and [#339][news339 cb]) with a summary of the + results he obtained testing [compact block relay][topic compact block + relay] _prefilling_---a node pre-emptively relaying some or all + transactions in a new block to its peers when it thinks the peers may + not already have those transactions. Gumberg's post is detailed and + links to a Jupyter notebook to allow others to experiment for themselves. + Key takeaways include: + + - Considered independently of network transport, a simple rule for + determining which transactions to prefill increased the rate of + successful block reconstructions from about 62% to about 98%. + + - When considering network transport, some prefills may have resulted + in an extra round trip---negating any benefit in that case and + possibly degrading performance slightly. However, many prefills + could have been constructed to avoid the problem, increasing the + likely reconstruction rate to about 93% and still supporting further + improvements. + +- **Mempool-based fee estimation library:** Lauren Shareshian + [posted][shareshian estimation] to Delving Bitcoin to announce a + library for [fee estimation][topic fee estimation] developed by Block. + Unlike some other fee estimation tools, it solely uses the flow of + transactions into a node's mempool as the basis of its estimates. + The post compares the library, Augur, to several fee estimation + services and finds that Augur has a low miss rate (i.e., over 85% of + transactions confirm within their intended window) and a low average + overestimation rate (i.e., transactions overpay fees by only about 16% + more than necessary). + + Abubakar Sadiq Ismail [replied][ismail estimation] to the Delving + thread and also started an informative [issue][augur #3] on the Augur + repository for examining some of the assumptions used by the library. + +## Changing consensus + +_A monthly section summarizing proposals and discussion about changing +Bitcoin's consensus rules._ + +- **Migration from quantum-vulnerable outputs:** Jameson Lopp + [posted][lopp qmig] to the Bitcoin-Dev mailing list a three-step + proposal for phasing out spending from [quantum-vulnerable + outputs][topic quantum resistance]. + + - Three years after consensus activation of the [BIP360][] + quantum-resistant signature scheme (or an alternative scheme), a + soft fork would reject transactions with outputs paying + quantum-vulnerable addresses. Only spends to quantum-resistant + outputs would be allowed. + + - Two years later, a second soft fork would reject spends from + quantum-vulnerable outputs. Any funds remaining in + quantum-vulnerable outputs would become unspendable. + + - Optionally, at some undefined later time, a consensus change could + allow spending from quantum-vulnerable outputs using a + quantum-resistant proof scheme (see [Newsletter #361][news361 pqcr] + for an example). + + Most of the discussion in the thread largely repeated prior + discussions about whether it was necessary to prevent people from + spending quantum-vulnerable bitcoins before it was certain + a quantum computer fast enough to steal them existed (see [Newsletter + #348][news348 destroy]). Reasonable arguments were made on both sides + and we expect that debate to continue. + +- **Taproot-native `OP_TEMPLATEHASH` proposal:** Greg Sanders + [posted][sanders th] to Bitcoin-Dev mailing list a proposal to add three opcodes to + [tapscript][topic tapscript]. Two of the opcodes are the previously + proposed [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] and + `OP_INTERNALKEY` (see [Newsletter #285][news285 ik]). The final + opcode is `OP_TEMPLATEHASH`, a taproot-native variation on + [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (`OP_CTV`) with + the following differences highlighted by the authors: + + - No changes to legacy (pre-segwit) scripts. See + [Newsletter #361][news361 ctvlegacy] for prior discussion about this + alternative. + + - The data that is hashed (and the order it is hashed in) is very + similar to the data hashed for signatures to commit to in + [taproot][topic taproot], simplifying implementation for any + software that already supports taproot. + + - It commits to the taproot [annex][topic annex], which `OP_CTV` does + not. One way this can be used is to ensure some data is published + as part of a transaction, such as data used in a contract protocol + to allow a counterparty to recover from publication of an old state. + + - It redefines an `OP_SUCCESSx` opcode rather than an `OP_NOPx` + opcode. Soft forks redefining `OP_NOPx` opcodes must be `VERIFY` + opcodes that mark the transaction invalid if they fail. Redefinitions + of `OP_SUCCESSx` opcodes can simply place either `1` (success) or + `0` (failure) on the stack after execution; this allows them to be + used directly in cases where redefined `OP_NOPx` redefinitions would + need to be wrapped by conditionals such as `OP_IF` + statements. + + - "It prevents surprising inputs with ... `scriptSig`" (see + [Newsletter #361][news361 bitvm]). + + Brandon Black [replied][black th] with a comparison of the proposal to + his earlier LNHANCE bundle proposal (see [Newsletter #285][news285 + ik]) and found it comparable in most ways, although he noted that it + is less efficient in onchain space for _congestion control_ (a form of + delayed [payment batching][topic payment batching]). + +- **Proposal to allow longer relative timelocks:** developer Pyth + [posted][pyth timelock] to Delving Bitcoin to suggest allowing + [BIP68][] relative timelocks to be extended from their current maximum + of about one year to a new maximum of about ten years. This would + require a soft fork and the use of an additional bit from the + transaction input _sequence_ field. + + Fabian Jahr [replied][jahr timelock] with a concern that + [timelocks][topic timelocks] too far in the future could lead to a + loss of funds, such as due to the development of quantum computers + (or, we add, the deployment of quantum defense protocols such as + Jameson Lopp's proposal described earlier in this newsletter). Steven + Roose [noted][roose timelock] that far-future timelocks are already + possible using other time lock mechanisms (such as presigned + transactions and [BIP65 CLTV][bip65]), and Pyth added that their + desired use case is for a wallet recovery path where the long timelock + would only be used if the primary path became unavailable and the + alternative would be permanent loss of the funds anyway. + +- **Security against quantum computers with taproot as a commitment scheme:** + Tim Ruffing [posted][ruffing qtr] a link to a [paper][ruffing paper] + he wrote analyzing the security of [taproot][topic taproot] + commitments against manipulation by quantum computers. He examines + whether taproot commitments to tapleaves would continue to possess the + _binding_ and _hiding_ properties it has against classical + computers. He concludes that: + + > A quantum attacker needs to perform at least 2^81 evaluations of + > SHA256 to create a Taproot output and be able to open it to an + > unexpected Merkle root with probability 1/2. If the attacker has + > only quantum machines whose longest sequence of SHA256 computations + > is limited to 2^20, then the attacker needs at least 2^92 of these + > machines to get a success probability of 1/2. + + If taproot commitments are secure against manipulation by quantum + computers, then quantum resistance can be added to Bitcoin by + disabling keypath spends and adding quantum-resistant + signature-checking opcodes to [tapscript][topic tapscript]. A recent + update to [BIP360][] pay-to-quantum-resistant-hash that Ethan Heilman + [posted][heilman bip360] to the Bitcoin-Dev mailing + list makes exactly this change. + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [Bitcoin Core 29.1rc1][] is a release candidate for a maintenance + version of the predominant full node software. + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [Bitcoin Core #29954][] RPC: Return `permitbaremultisig` and `maxdatacarriersize` in `getmempoolinfo` + +- [Bitcoin Core #33004][] Enable `-natpmp` by default + +- [LDK #3246][] Enable Creation of Offers and Refunds Without Blinded Path + +- [LDK #3892][] offer: make the merkle tree signature public + +- [LDK #3662][] LSPS5 implementation + +{% include snippets/recap-ad.md when="2025-08-05 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="29954,33004,3246,3892,3662" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[augur #3]: https://github.com/block/bitcoin-augur/issues/3 +[news315 cb]: /en/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction +[news339 cb]: /en/newsletters/2025/01/31/#updated-stats-on-compact-block-reconstruction +[gumberg prefilling]: https://delvingbitcoin.org/t/stats-on-compact-block-reconstructions/1052/34 +[shareshian estimation]: https://delvingbitcoin.org/t/augur-block-s-open-source-bitcoin-fee-estimation-library/1848/ +[ismail estimation]: https://delvingbitcoin.org/t/augur-block-s-open-source-bitcoin-fee-estimation-library/1848/2 +[news361 pqcr]: /en/newsletters/2025/07/04/#commit-reveal-function-for-post-quantum-recovery +[sanders th]: https://mailing-list.bitcoindevs.xyz/bitcoindev/26b96fb1-d916-474a-bd23-920becc3412cn@googlegroups.com/ +[news285 ik]: /en/newsletters/2024/01/17/#new-lnhance-combination-soft-fork-proposed +[news361 ctvlegacy]: /en/newsletters/2025/07/04/#concerns-and-alternatives-to-legacy-support +[pyth timelock]: https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818/ +[jahr timelock]: https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818/2 +[roose timelock]: https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818/3 +[ruffing qtr]: https://mailing-list.bitcoindevs.xyz/bitcoindev/bee6b897379b9ae0c3d48f53d40a6d70fe7915f0.camel@real-or-random.org/ +[ruffing paper]: https://eprint.iacr.org/2025/1307 +[heilman bip360]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAEM=y+W=rtU2PLmHve6pUVkMQQmqT67KOg=9hp5oMspuHrgMow@mail.gmail.com/ +[lopp qmig]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CADL_X_fpv-aXBxX+eJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q@mail.gmail.com/ +[news348 destroy]: /en/newsletters/2025/04/04/#should-vulnerable-bitcoins-be-destroyed +[black th]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aG9FEHF1lZlK6d0E@console/ +[news361 bitvm]: /en/newsletters/2025/07/04/#continued-discussion-about-ctv-csfs-advantages-for-bitvm From 61ca5409c64ecdae2945743f7e2cad29e9888182 Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 31 Jul 2025 06:50:47 +0000 Subject: [PATCH 181/278] News365: add merge summaries --- .../en/newsletters/2025-08-01-newsletter.md | 46 +++++++++++++++---- 1 file changed, 36 insertions(+), 10 deletions(-) diff --git a/_posts/en/newsletters/2025-08-01-newsletter.md b/_posts/en/newsletters/2025-08-01-newsletter.md index 351e33cd9a..1cfb966cf0 100644 --- a/_posts/en/newsletters/2025-08-01-newsletter.md +++ b/_posts/en/newsletters/2025-08-01-newsletter.md @@ -188,19 +188,42 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Bitcoin Core #29954][] RPC: Return `permitbaremultisig` and `maxdatacarriersize` in `getmempoolinfo` - -- [Bitcoin Core #33004][] Enable `-natpmp` by default - -- [LDK #3246][] Enable Creation of Offers and Refunds Without Blinded Path - -- [LDK #3892][] offer: make the merkle tree signature public - -- [LDK #3662][] LSPS5 implementation +- [Bitcoin Core #29954][] extends the `getmempoolinfo` RPC by adding two relay + policy fields to its response object: `permitbaremultisig` (whether the node + relays bare multisig outputs) and `maxdatacarriersize` (the maximum aggregate + bytes allowed in OP_RETURN outputs for a transaction in the mempool). Other + policy flags, such as [`fullrbf`][topic rbf] and `minrelaytxfee`, were already + exposed, so these additions allow for a complete relay policy snapshot. + +- [Bitcoin Core #33004][] enables the `-natpmp` option by default, allowing + automatic port forwarding via the [Port Control Protocol (PCP)][pcp] with a + fallback to the [NAT Port Mapping Protocol (NAT-PMP)][natpmp] (see Newsletter + [#323][news323 natpmp]). A listening node behind a router that supports either + PCP or NAT-PMP becomes reachable without manual configuration. + +- [LDK #3246][] enables the creation of [BOLT12 offers][topic offers] and + refunds without a [blinded path][topic rv routing] by using the offer’s + `signing_pubkey` as the destination. The `create_offer_builder` and + `create_refund_builder` functions now delegate blinded path creation to + `MessageRouter::create_blinded_paths`, where a caller can generate a compact + path by passing `DefaultMessageRouter`, a full-length pubkey path with + `NodeIdMessageRouter`, or no path at all with `NullMessageRouter`. + +- [LDK #3892][] exposes the merkle tree signature of [BOLT12][topic offers] + invoices publicly, enabling developers to build CLI tools or other software to + verify the signature or recreate invoices. This PR also adds an `OfferId` + field to BOLT12 invoices to track the originating offer. + +- [LDK #3662][] implements [BLIPs #55][], also known as LSPS05, which defines + how clients can register for webhooks via an endpoint to receive push + notifications from an LSP. The API exposes additional endpoints that enable + clients to list all webhook registrations or remove a specific one. This can + be useful for clients to get notified when receiving an [async payment][topic + async payments]. {% include snippets/recap-ad.md when="2025-08-05 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="29954,33004,3246,3892,3662" %} +{% include linkers/issues.md v=2 issues="29954,33004,3246,3892,3662,55" %} [bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ [augur #3]: https://github.com/block/bitcoin-augur/issues/3 [news315 cb]: /en/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction @@ -222,3 +245,6 @@ repo], and [BINANAs][binana repo]._ [news348 destroy]: /en/newsletters/2025/04/04/#should-vulnerable-bitcoins-be-destroyed [black th]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aG9FEHF1lZlK6d0E@console/ [news361 bitvm]: /en/newsletters/2025/07/04/#continued-discussion-about-ctv-csfs-advantages-for-bitvm +[news323 natpmp]: /en/newsletters/2024/10/04/#bitcoin-core-30043 +[pcp]: https://datatracker.ietf.org/doc/html/rfc6887 +[natpmp]: https://datatracker.ietf.org/doc/html/rfc6886 From 6aac7b21bd139dbf32f60dc3ae45e8a3dd446f94 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Fri, 1 Aug 2025 06:25:42 -0500 Subject: [PATCH 182/278] News365: add topics --- _topics/en/annex.md | 3 +++ _topics/en/compact-block-relay.md | 3 +++ _topics/en/fee-estimation.md | 3 +++ _topics/en/op_checktemplateverify.md | 3 +++ _topics/en/quantum-resistance.md | 6 ++++++ _topics/en/taproot.md | 3 +++ _topics/en/timelocks.md | 3 +++ 7 files changed, 24 insertions(+) diff --git a/_topics/en/annex.md b/_topics/en/annex.md index 213e2ca0b0..a85eb7b67f 100644 --- a/_topics/en/annex.md +++ b/_topics/en/annex.md @@ -35,6 +35,9 @@ optech_mentions: - title: Plan to begin relaying transactions with certain taproot annexes in Libre Relay url: /en/newsletters/2025/03/28/#plan-to-relay-certain-taproot-annexes + - title: "Proposed `OP_TEMPLATEHASH` would commit to transaction details, including annex" + url: /en/newsletters/2025/08/01/#taproot-native-op-templatehash-proposal + ## Optional. Same format as "primary_sources" above see_also: - title: Taproot diff --git a/_topics/en/compact-block-relay.md b/_topics/en/compact-block-relay.md index 4685d06ff1..627d544728 100644 --- a/_topics/en/compact-block-relay.md +++ b/_topics/en/compact-block-relay.md @@ -69,6 +69,9 @@ optech_mentions: - title: "Bitcoin Core #32582 adds logging to measure performance of compact block reconstruction" url: /en/newsletters/2025/06/06/#bitcoin-core-32582 + - title: "Results from testing compact block relay prefilling" + url: /en/newsletters/2025/08/01/#testing-compact-block-prefilling + ## Optional. Same format as "primary_sources" above # see_also: # - title: diff --git a/_topics/en/fee-estimation.md b/_topics/en/fee-estimation.md index e8e623304d..c215635924 100644 --- a/_topics/en/fee-estimation.md +++ b/_topics/en/fee-estimation.md @@ -65,6 +65,9 @@ optech_mentions: - title: "PR Review Club about improved feerate forecasting for Bitcoin Core" url: /en/newsletters/2025/04/11/#bitcoin-core-pr-review-club + - title: "Publication of a mempool-based fee estimation library" + url: /en/newsletters/2025/08/01/#mempool-based-fee-estimation-library + ## Optional. Same format as "primary_sources" above see_also: - title: Coin selection diff --git a/_topics/en/op_checktemplateverify.md b/_topics/en/op_checktemplateverify.md index 72affec557..0cb62bfa64 100644 --- a/_topics/en/op_checktemplateverify.md +++ b/_topics/en/op_checktemplateverify.md @@ -172,6 +172,9 @@ optech_mentions: - title: "Discussion of open letter about CTV and CSFS" url: /en/newsletters/2025/07/04/#open-letter-about-ctv-and-csfs + - title: "`OP_TEMPLATEHASH` proposal as an alternative to CTV" + url: /en/newsletters/2025/08/01/#taproot-native-op-templatehash-proposal + ## Optional. Same format as "primary_sources" above see_also: - title: Covenants diff --git a/_topics/en/quantum-resistance.md b/_topics/en/quantum-resistance.md index 92c8f1f5d6..78d33eccc9 100644 --- a/_topics/en/quantum-resistance.md +++ b/_topics/en/quantum-resistance.md @@ -85,6 +85,12 @@ optech_mentions: - title: "Research indicates many Bitcoin primitives are compatible with quantum-resistant signatures" url: /en/newsletters/2025/07/25/#research-indicates-common-bitcoin-primitives-are-compatible-with-quantum-resistant-signature-algorithms + - title: "Discussion about forcing migration from quantum-vulnerable outputs" + url: /en/newsletters/2025/08/01/#migration-from-quantum-vulnerable-outputs + + - title: "Paper analyzes the security of taproot commitments against quantum computers" + url: /en/newsletters/2025/08/01/#security-against-quantum-computers-with-taproot-as-a-commitment-scheme + ## Optional. Same format as "primary_sources" above see_also: - title: Taproot diff --git a/_topics/en/taproot.md b/_topics/en/taproot.md index 95b77ed360..b27546104b 100644 --- a/_topics/en/taproot.md +++ b/_topics/en/taproot.md @@ -248,6 +248,9 @@ optech_mentions: - title: "Core Lightning #7800 sets P2TR as the default script for anchor output spends and unilateral closes" url: /en/newsletters/2024/11/22/#core-lightning-7800 + - title: "Paper analyzes the security of taproot commitments against quantum computers" + url: /en/newsletters/2025/08/01/#security-against-quantum-computers-with-taproot-as-a-commitment-scheme + ## Optional see_also: - title: MAST diff --git a/_topics/en/timelocks.md b/_topics/en/timelocks.md index 1a17e723d0..aad4c23b7d 100644 --- a/_topics/en/timelocks.md +++ b/_topics/en/timelocks.md @@ -76,6 +76,9 @@ optech_mentions: - title: "Discussion about whether timelocked quantum-vulnerable bitcoins should be destroyed to prevent theft" url: /en/newsletters/2025/04/04/#should-vulnerable-bitcoins-be-destroyed + - title: "Proposal to allow longer relative timelocks" + url: /en/newsletters/2025/08/01/#proposal-to-allow-longer-relative-timelocks + ## Optional. Same format as "primary_sources" above see_also: - title: HTLCs From f6bdc759bb919eab102f4f39ed8f12cc4e63ef4a Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 1 Aug 2025 20:44:05 +0900 Subject: [PATCH 183/278] Newsletter-365:Translate into Japanese --- .../ja/newsletters/2025-08-01-newsletter.md | 210 ++++++++++++++++++ 1 file changed, 210 insertions(+) create mode 100644 _posts/ja/newsletters/2025-08-01-newsletter.md diff --git a/_posts/ja/newsletters/2025-08-01-newsletter.md b/_posts/ja/newsletters/2025-08-01-newsletter.md new file mode 100644 index 0000000000..9e486e85ec --- /dev/null +++ b/_posts/ja/newsletters/2025-08-01-newsletter.md @@ -0,0 +1,210 @@ +--- +title: 'Bitcoin Optech Newsletter #365' +permalink: /ja/newsletters/2025/08/01/ +name: 2025-08-01-newsletter-ja +slug: 2025-08-01-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、コンパクトブロックリレーのプレフィリングテストの結果と、 +mempoolベースの手数料推定ライブラリのリンクを掲載しています。 +また、Bitcoinのコンセンサスルールの変更に関する議論のまとめや、 +新しいリリースおよびリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき更新など、 +恒例のセクションも含まれています。 + +## ニュース + +- **コンパクトブロックのプレフィリングのテスト:** + David Gumbergは、（以前ニュースレター[#315][news315 cb]と[#339][news339 cb]で取り上げた） + コンパクトブロックの再構築率に関するDelving Bitcoinのスレッドに、 + [コンパクトブロックリレー][topic compact block relay]の _プレフィリング_ + をテストして得られた結果の概要を[返信しました][gumberg prefilling]。 + プレフィリングとは、ノードが新しいブロック内のトランザクションの一部または全部を、 + ピアがまだそれらのトランザクションを持っていない可能性があると判断した場合に、 + 事前にピアにリレーすることです。Gumbergの投稿は詳細で、他の人が自分で実験できるように + Jupyter Notebookのリンクも含まれています。主なポイントは以下のとおりです: + + - ネットワーク転送を考慮しない場合、どのトランザクションをプレフィリングするか決定する単純なルールにより、 + ブロック再構築の成功率が約62%から約98%に向上しました。 + + - ネットワーク転送を考慮した場合、一部のプレフィリングにより追加のラウンドトリップが発生する可能性があり、 + その場合は利点が打ち消され、パフォーマンスがわずかに低下する可能性があります。 + しかし、この問題を回避するために多数のプレフィリングを行うことで、 + 再構築率は93%にまで向上し、さらなる改善の余地も残しています。 + +- **mempoolベースの手数料推定ライブラリ:** Lauren Shareshianは、 + Block社が開発した[手数料推定][topic fee estimation]ライブラリを + Delving Bitcoinで[発表しました][shareshian estimation]。他の手数料推定ツールとは異なり、 + このライブラリはノードのmempoolへのトランザクションフローのみを推定基準にしています。 + 投稿では、この「Augur」ライブラリを複数の手数料推定サービスと比較し、 + Augurはミス率（トランザクションの85%以上が想定された時間内で承認される）が低く、 + 平均過大推定率（トランザクションが必要以上に支払う手数料が約16%程度）も低いことが示されました。 + + Abubakar Sadiq Ismailは、Delvingのスレッドに[返信し][ismail estimation]、 + Augurのリポジトリで、このライブラリで使用されているいくつかの仮定について検証する有益な[issue][augur #3]を公開しました。 + +## コンセンサスの変更 + +_Bitcoinのコンセンサスルールの変更に関する提案と議論をまとめた月次セクション_ + +- **量子脆弱なアウトプットからの移行:** + Jameson Loppは、[量子脆弱なアウトプット][topic quantum resistance]の使用を段階的に廃止するための + 3段階の提案をBitcoin-Devメーリングリストに[投稿しました][lopp qmig]。 + + - [BIP360][]量子耐性署名スキーム（または代替スキーム）のコンセンサスの有効化から3年後、 + ソフトフォークにより量子脆弱なアドレスに支払いをするトランザクションを拒否します。 + 量子耐性のあるアウトプットへの支払いのみが許可されます。 + + - 2年後、2回めのソフトフォークにより、量子脆弱なアウトプットからの支払いが拒否されます。 + これにより、量子脆弱なアウトプットに残っている資金は使用できなくなります。 + + - オプションで、その後のコンセンサスの変更により、 + 耐量子証明スキームを用いて（たとえば[ニュースレター #361][news361 pqcr]の内容など） + 量子脆弱なアウトプットからの支払いが許可される可能性があります。 + + スレッドでの議論の大部分は、量子脆弱なビットコインを盗むのに十分な速度の量子コンピューターが存在することが判明するまで、 + 量子コンピューターに脆弱なビットコインの使用を阻止する必要があるかどうかという、 + 以前の議論の繰り返しでした（[ニュースレター #348][news348 destroy]参照）。 + 双方から合理的な議論がなされ、この議論は今後も続くと予想されます。 + +- **Taprootネイティブな`OP_TEMPLATEHASH`提案:** Greg Sandersは、 + [Tapscript][topic tapscript]に3つのopcodeを追加する提案を + Bitcoin-Devメーリングリストに[投稿しました][sanders th]。 + そのうち2つは、以前提案された[OP_CHECKSIGFROMSTACK][topic op_checksigfromstack]と + `OP_INTERNALKEY`（[ニュースレター #285][news285 ik]参照）です。3つめのopcodeは`OP_TEMPLATEHASH`で、 + [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (`OP_CTV`)のTaprootネイティブ版で、 + 以下の違いが強調されています: + + - （segwit以前の）レガシースクリプトは変更しません。この代替案に関する以前の議論については、 + [ニュースレター #361][news361 ctvlegacy]をご覧ください。 + + - ハッシュされるデータ（およびハッシュされる順序）は、 + [Taproot][topic taproot]で署名でコミットするためにハッシュされるデータと似ているため、 + 既にTaprootをサポートしているソフトウェアの実装を簡単にします。 + + - `OP_CTV`とは異なり、Taprootの[annex][topic annex]にコミットします。 + これを使用する1つの方法は、 + 古い状態の公開によりカウンターパーティがリカバリーできるようにコントラクトプロトコルで使用されるデータなど、 + 一部のデータがトランザクションの一部として公開されることを保証することです。 + + - `OP_NOPx` opcodeではなく、`OP_SUCCESSx` opcodeを再定義します。 + `OP_NOPx` opcodeを再定義するソフトフォークは、 + opcodeの評価が失敗した場合にトランザクションを無効としてマークする`VERIFY` opcodeである必要があります。 + `OP_SUCCESSx` opcodeの再定義は、実行後にスタックに`1`（成功）または`0`（失敗）のいずれかを配置するだけで済みます。 + これにより、再定義された`OP_NOPx` opcodeが`OP_IF`などの条件句でラップする必要がある場合でも、 + 直接使用できるようになります。 + + - 「... `scriptSig`で予期しない入力を防止します」（[ニュースレター #361][news361 bitvm]参照）。 + + Brandon Blackは、この提案を以前のLNHANCEバンドル提案（[ニュースレター #285][news285 ik]参照）と[比較し][black th]、 + ほとんどの点で同等であると評価しましたが、オンチェーンスペースにおける + _輻輳制御_ （遅延[支払いバッチ処理][topic payment batching]）の効率性が低いと指摘しました。 + +- **より長い相対タイムロックを許可する提案:** + 開発者のPythは、[BIP68][]の相対タイムロックを現在の最大約1年から最大約10年に延長する提案を + Delving Bitcoinに[投稿しました][pyth timelock]。これにはソフトフォークと、 + トランザクションインプットの _sequence_ フィールドから追加bitの使用が必要になります。 + + Fabian Jahrは、あまりに遠い将来の[タイムロック][topic timelocks]は、量子コンピューターの開発（あるいは、 + 前述したJameson Loppの提案のような量子防御プロトコルの導入）などによる + 資金の損失につながる可能性があると懸念を[示しました][jahr timelock]。 + Steven Rooseは、他のタイムロックメカニズム（事前署名トランザクションや[BIP65 CLTV][bip65]など）を使用することで、 + 遠い将来のタイムロックは既に可能だと[指摘し][roose timelock]、Pythは、 + 望ましいユースケースはウォレットのリカバリーパスであり、 + プライマリーパスが利用できなくなった場合にのみ長いタイムロックを使用し、 + 代替手段がなければ資金の永久的な損失となる状況での利用を想定していると付け加えました。 + +- **コミットメントスキームとしてTaprootを用いた量子コンピューターに対するセキュリティ:** + Tim Ruffingは、量子コンピューターによる改竄に対する[Taproot][topic taproot]コミットメントの + 安全性を分析した[論文][ruffing paper]のリンクを[投稿しました][ruffing qtr]。 + 彼は、Taprootコミットメントが、従来のコンピューターに対して持つ _拘束性（binding）_ と + _秘匿性（hiding）_ を今後も維持できるかどうかを検証しています。 + 彼は次のように結論づけています: + + > 量子攻撃者がTaprootアウトプットを作成し、 + > それを1/2の確率で予期しないマークルルートに展開することができるようにするには、 + > 少なくとも2^81回のSHA256を実行する必要があります。 + > 攻撃者がSHA256計算の最長シーケンスが2^20に制限された量子マシンしか持っていない場合、 + > 攻撃者は1/2の成功確率を得るために少なくとも2^92台のマシンが必要です。 + + Taprootコミットメントが量子コンピューターによる改竄に対して安全であれば、 + keypath支払いを無効化し、[Tapscript][topic tapscript]に量子耐性のある署名検証opcodeを追加することで、 + Bitcoinに量子耐性を追加できます。Ethan HeilmanがBitcoin-Devメーリングリストに[投稿した][heilman bip360] + [BIP360][] pay-to-quantum-resistant-hashの最近のアップデートでは、まさにこの変更が行われています。 + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [Bitcoin Core 29.1rc1][]は、主要なフルノードソフトウェアのメンテナンスバージョンのリリース候補です。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Bitcoin Core #29954][]は、`getmempoolinfo` RPCを拡張し、 + レスポンスオブジェクトに2つのリレーポリシーフィールド：`permitbaremultisig` + （ノードがベアマルチシグをリレーするかどうか）と`maxdatacarriersize`（ + mempool内のトランザクションのOP_RETURNアウトプットで許可される最大byte数）を追加しました。 + [`fullrbf`][topic rbf]や`minrelaytxfee`などの他のポリシーフラグは既に公開されているため、 + これらの追加によりリレーポリシーの完全なスナップショットが可能になります。 + +- [Bitcoin Core #33004][]は、`-natpmp`オプションをデフォルトで有効にし、 + [PCP（ポート制御プロトコル）][pcp]による自動ポート転送と、 + [NAT-PMP（NAT Port Mapping Protocol）][natpmp]へのフォールバックを可能にします（ニュースレター + [#323][news323 natpmp]参照）。PCPまたはNAT-PMPをサポートするルーターの配下にある待受ノードは、 + 手動設定なしでアクセス可能になります。 + +- [LDK #3246][]は、オファーの`signing_pubkey`を宛先として使用することで、 + [ブラインドパス][topic rv routing]なしで[BOLT12 オファー][topic offers]と払い戻しを作成できるようにします。 + `create_offer_builder`関数と`create_refund_builder`関数は、ブラインドパスの作成を + `MessageRouter::create_blinded_paths`に委譲するようになりました。 + これにより、呼び出し元は、`DefaultMessageRouter`でコンパクトパスを生成したり、 + `NodeIdMessageRouter`で完全な長さの公開鍵パスを生成したり、 + `NullMessageRouter`でパスを生成しないようにすることができます。 + +- [LDK #3892][]は、[BOLT12][topic offers]インボイスのマークルツリー署名を公開し、 + 開発者がCLIツールやその他のソフトウェアを構築して、インボイスを再作成できるようにします。 + このPRはまた、元のオファーを追跡するためにBOLT12インボイスに`OfferId`フィールドを追加します。 + +- [LDK #3662][]は、（LSPS05としても知られる）[BLIPs #55][]を実装し、 + クライアントがLSPからプッシュ通知を受け取るためにエンドポイント経由でウェブフックを登録する方法を定義しています。 + APIは、クライアントがすべてのウェブフックをリストしたり登録したり、特定のウェブフックを削除したりできる + 追加のエンドポイントを公開します。これは、クライアントが[非同期支払い][topic + async payments]を受信する際に通知を受け取るのに便利です。 + +{% include snippets/recap-ad.md when="2025-08-05 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="29954,33004,3246,3892,3662,55" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[augur #3]: https://github.com/block/bitcoin-augur/issues/3 +[news315 cb]: /ja/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction +[news339 cb]: /ja/newsletters/2025/01/31/#updated-stats-on-compact-block-reconstruction +[news323 natpmp]: /ja/newsletters/2024/10/04/#bitcoin-core-30043 +[pcp]: https://datatracker.ietf.org/doc/html/rfc6887 +[natpmp]: https://datatracker.ietf.org/doc/html/rfc6886 +[gumberg prefilling]: https://delvingbitcoin.org/t/stats-on-compact-block-reconstructions/1052/34 +[shareshian estimation]: https://delvingbitcoin.org/t/augur-block-s-open-source-bitcoin-fee-estimation-library/1848/ +[ismail estimation]: https://delvingbitcoin.org/t/augur-block-s-open-source-bitcoin-fee-estimation-library/1848/2 +[news361 pqcr]: /ja/newsletters/2025/07/04/#commit-reveal-function-for-post-quantum-recovery +[sanders th]: https://mailing-list.bitcoindevs.xyz/bitcoindev/26b96fb1-d916-474a-bd23-920becc3412cn@googlegroups.com/ +[news285 ik]: /ja/newsletters/2024/01/17/#lnhance +[news361 ctvlegacy]: /ja/newsletters/2025/07/04/#concerns-and-alternatives-to-legacy-support +[pyth timelock]: https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818/ +[jahr timelock]: https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818/2 +[roose timelock]: https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818/3 +[ruffing qtr]: https://mailing-list.bitcoindevs.xyz/bitcoindev/bee6b897379b9ae0c3d48f53d40a6d70fe7915f0.camel@real-or-random.org/ +[ruffing paper]: https://eprint.iacr.org/2025/1307 +[heilman bip360]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAEM=y+W=rtU2PLmHve6pUVkMQQmqT67KOg=9hp5oMspuHrgMow@mail.gmail.com/ +[lopp qmig]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CADL_X_fpv-aXBxX+eJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q@mail.gmail.com/ +[news348 destroy]: /ja/newsletters/2025/04/04/#should-vulnerable-bitcoins-be-destroyed +[black th]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aG9FEHF1lZlK6d0E@console/ +[news361 bitvm]: /ja/newsletters/2025/07/04/#bitvm-ctv-csfs \ No newline at end of file From 895de38583b5736a1dfe7ea6f4e66c1ceedfd0f3 Mon Sep 17 00:00:00 2001 From: editor-Ajian <34365188+editor-Ajian@users.noreply.github.com> Date: Thu, 31 Jul 2025 16:19:34 +0800 Subject: [PATCH 184/278] translate newletter362 into zh-cn (#175) * translate newletter362 into zh-cn * fix format & words --------- Co-authored-by: Zhiwei(Jeffrey) Hu --- .../zh/newsletters/2025-07-11-newsletter.md | 74 +++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 _posts/zh/newsletters/2025-07-11-newsletter.md diff --git a/_posts/zh/newsletters/2025-07-11-newsletter.md b/_posts/zh/newsletters/2025-07-11-newsletter.md new file mode 100644 index 0000000000..e570ea877f --- /dev/null +++ b/_posts/zh/newsletters/2025-07-11-newsletter.md @@ -0,0 +1,74 @@ +--- +title: 'Bitcoin Optech Newsletter #362' +permalink: /zh/newsletters/2025/07/11/ +name: 2025-07-11-newsletter-zh +slug: 2025-07-11-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- + +本周的新闻部分简述了一个新的库，允许输出脚本描述符被压缩、用在 QR 码中。此外是我们的常规栏目：Bitcoin Core PR 审核俱乐部会议的总结、软件的新版本和候选版本的发行公告、热门的比特币基础设施软件的重大变更介绍。 + +## 新闻 + +- **压缩的描述符**：Josh Doman 在 Delving Bitcoin 中[宣布][dorman descom]了他编写的一个[库][descriptor-codec]，可以将[输出脚本描述符][topic descriptors]编码成一种二进制格式、将体积缩小 40%。这可能是非常有用的，如果我们想用 QR 码来备份描述符的话。他的帖子详细介绍了编码的细节，并提到了他计划将这种压缩方案整合到自己的描述符加密备份库中（详见 [周报 #358][news358 descencrypt]）。 + +## Bitcoin Core RP 审核俱乐部 + +*在这个阅读栏目中，我们总结最近一期 [Bitcoin Core PR 审核俱乐部][Bitcoin Core PR Review Club]会议，并突出一些重要的问题和回答。点击问题描述可见到会议上答案的总结。* + +[增强 TxOrphanage 拒绝服务限制][review club 31829] 是由 [glozow][gh glozow] 提出的一项 PR，改变 `TxOrphanage` 的驱逐逻辑，以保证为每个对等节点保留了能够解决至少 1 个最大体积交易包的资源。这些新的保证显著优化了 “[相机的 1 父 1 子交易包转发][1p1c relay]” 特性，尤其是在敌意条件下（但不限于此）。 + +这个 PR 修改了现有的全局孤儿交易限制，并引入新的逐对等节点限制。两者的结合防止了过量的内存使用和计算资源耗尽。这个 PR 也用一种计算各对等节点 DoS 分数的算法取代了随机驱逐算法。 + +*注意：自该次审核俱乐部会议以来，这项 PR 又发生了[少量重大的变更][review club 31829 changes]，其中最重要的是使用一种延迟分数限制，而不是宣告次数限制。* + +{% include functions/details-list.md + q0="当前的 100 笔交易的 TxOrphanage 全局体积限制和随机驱逐算法有什么缺点？" + a0="它让一个恶意的对等节点可以用孤儿交易冲垮一个节点，最终导致受害者节点处来自其它对等节点的所有合法交易都被驱逐。这种攻击可被用来阻止相机的 1 父 1 子交易转发，因为子交易无法长时间保存在孤儿交易池。" + a0link="https://bitcoincore.reviews/31829#l-12" + q1="总体上，这种新的驱逐算法是如何工作的？" + a1="驱逐不再是随机的。该算法会基于一种 “DoS 分数” 来瞄准 “行为最恶劣” 的对等节点，然后驱逐来自该对等节点的最早的交易宣告。这保护了来自行为良好的对等节点的交易的子交易，使之不受恶劣的对等节点影响。" + a1link="https://bitcoincore.reviews/31829#l-19" + q2="为什么在还没有达到全局上限的时候，允许对等节点超出自己的局部限制是可取的？" + a2="对等节点可能仅仅因为自己乐于助人（正在广播有用的交易，比如 CPFP）而使用更多资源。" + a2link="https://bitcoincore.reviews/31829#l-25" + q3="新算法驱逐的对象是宣告消息而不是交易。这有什么区别？这个区别何以重要？" + a3="宣告消息包含了一对信息：一笔交易和发送它的对等节点。因为驱逐的是宣告消息，恶意的对等节点就无法影响由诚实节点发来的交易。" + a3link="https://bitcoincore.reviews/31829#l-34" + q4="什么是对等节点的 “DoS 分数”，如何计算这个分数？" + a4="一个对等节点的 DoS 分数是它的 “内存分数” 和 “CPU 分数” 中的最大值。内存分数是用掉的内存数量除以为之保留的内存数量；CPU 分数则是实际宣告的消息数量除以宣告消息的数量限制。使用一个单一的合并分数，可以将驱逐逻辑简化为单个循环，瞄准那些最激进地超过某一个限制的对等节点。" + a4link="https://bitcoincore.reviews/31829#l-133" +%} + +## 新版本和候选版本 + +*热门比特币基础设施项目的新版本和候选版本。请考虑升级到新版本，或帮助测试候选版本。* + +- [LND v0.19.2-beta.rc2][] 是这个热门的闪电网络节点实现的一个维护版本的候选发行。 + +## 重大的代码和文档变更 + +*本周出现重大变更的有：[Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement Proposals (BIPs)][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo]。* + +- [Core Lightning #8377][] 收紧了 [BOLT11][] 发票的解析要求：让支付发送者不要支付缺失了[支付秘密][topic payment secrets]和强制字段（比如 `p`支付哈希值、`h`描述哈希值、`s`秘密值）的数值长度不正确的发票。这些变化跟近期的协议变更保持一致（详见周报 [#350][news350 bolts] 和 [#358][news358 bolts]）。 + +- [BDK #1957][] 为交易历史、默克尔证据以及区块头请求引入了 RPC 批量处理，以优化使用一个 Electrum 后端时完全扫码和同步的性能。这个 PR 也添加了锚点缓存以跳过同步期间对“简单支付验证（SPV）” 的重新验证。使用样本数据，作者观察到，在完全扫描期间，使用 RPC 调用批处理使性能表现从 8.14 秒上升到 2.59 秒；而在同步期间使用缓存使性能表现从 1.37 秒上升到 0.85 秒。 + +- [BIPs #1888][] 从 [BIP380][] 中移除了 `H` 作为硬化路径标记，只留下一贯使用的 `h` 和替代性的 `'` 。最近的周报 [#360][news360 bip380] 已经指出，出于清晰，语法曾经允许这三种标记，但因为很少（甚至没有）描述符实现真的支持（Bitcoin Core 和 rust-miniscript 都不支持），所以规范收紧为禁止它。 + +{% include references.md %} +{% include linkers/issues.md v=2 issues="8377,1957,1888" %} +[LND v0.19.2-beta.rc2]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.2-beta.rc2 +[news358 descencrypt]: /zh/newsletters/2025/06/13/#descriptor-encryption-library +[dorman descom]: https://delvingbitcoin.org/t/a-rust-library-to-encode-descriptors-with-a-30-40-size-reduction/1804 +[descriptor-codec]: https://github.com/joshdoman/descriptor-codec +[news350 bolts]: /zh/newsletters/2025/04/18/#bolts-1242 +[news358 bolts]: /zh/newsletters/2025/06/13/#bolts-1243 +[news312 spv]: /zh/newsletters/2024/07/19/#bdk-1489 +[news360 bip380]: /zh/newsletters/2025/06/27/#bips-1803 +[review club 31829]: https://bitcoincore.reviews/31829 +[gh glozow]: https://github.com/glozow +[review club 31829 changes]: https://github.com/bitcoin/bitcoin/pull/31829#issuecomment-3046495307 +[1p1c relay]: /zh/bitcoin-core-28-wallet-integration-guide/#一父一子交易1p1c中继 From 2728971f0611a07230b8236089277f7b1752e2de Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Mon, 4 Aug 2025 11:27:12 -0500 Subject: [PATCH 185/278] Style: newsletter linking --- STYLE.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/STYLE.md b/STYLE.md index c8363adc3f..26520e6f16 100644 --- a/STYLE.md +++ b/STYLE.md @@ -213,3 +213,7 @@ spelled the same. confirmation](/en/topics/version-3-transaction-relay/) (TRUC). Preferred: topologically restricted until confirmation ([TRUC](/en/topics/version-3-transaction-relay/)). + +- **Newsletter linking:** when linking to previous newsletters, prefer link text + as "[Newsletter #nnn]" when it is one newsletter being referenced and + "Newsletter [#nnn], [#nnn], [#nnn]" when more than one being referenced. From 5aeb43f7857404f91b25be06e7def9fb6704f91d Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Tue, 5 Aug 2025 22:51:27 +0200 Subject: [PATCH 186/278] newsletter-365-german (#2443) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * de: continued translation of newsletter #365; updated STYLE-DE.md with newsletter reference convention; fixed two link anchors in English original * Update _posts/de/newsletters/2025-08-01-newsletter.md Co-authored-by: garfiel-d * Update _posts/de/newsletters/2025-08-01-newsletter.md Co-authored-by: garfiel-d * Update _posts/de/newsletters/2025-08-01-newsletter.md Co-authored-by: garfiel-d * Update _posts/de/newsletters/2025-08-01-newsletter.md Co-authored-by: garfiel-d * Update _posts/de/newsletters/2025-08-01-newsletter.md Co-authored-by: garfiel-d * Update _posts/de/newsletters/2025-08-01-newsletter.md Co-authored-by: garfiel-d * Update _posts/de/newsletters/2025-08-01-newsletter.md Co-authored-by: Mark "Murch" Erhardt * Update _posts/de/newsletters/2025-08-01-newsletter.md Co-authored-by: Mark "Murch" Erhardt * Update _posts/de/newsletters/2025-08-01-newsletter.md Co-authored-by: Mark "Murch" Erhardt * Update _posts/de/newsletters/2025-08-01-newsletter.md Co-authored-by: Mark "Murch" Erhardt * Update _posts/de/newsletters/2025-08-01-newsletter.md Co-authored-by: Mark "Murch" Erhardt * Update _posts/de/newsletters/2025-08-01-newsletter.md Co-authored-by: Mark "Murch" Erhardt * Update _posts/de/newsletters/2025-08-01-newsletter.md Co-authored-by: Mark "Murch" Erhardt * update STYLE-de und ich werde den Listenlink in einer separaten PR veröffentlichen --------- Co-authored-by: garfiel-d Co-authored-by: Mark "Murch" Erhardt --- STYLE-DE.md | 15 +- .../de/newsletters/2025-08-01-newsletter.md | 229 ++++++++++++++++++ 2 files changed, 243 insertions(+), 1 deletion(-) create mode 100644 _posts/de/newsletters/2025-08-01-newsletter.md diff --git a/STYLE-DE.md b/STYLE-DE.md index 0ed87ffc1a..1b9d3f4513 100644 --- a/STYLE-DE.md +++ b/STYLE-DE.md @@ -1,5 +1,17 @@ # Optech Style Guide für deutsche Übersetzungen +## Referenzierung von Newslettern + +Beim Verweis auf einen einzelnen Newsletter wird die Form „[Newsletter #nnn]“ verwendet, z. B.: + +> (siehe auch [Newsletter #315][news315 cb]) + +Bei Verweisen auf mehrere Newsletter werden die Nummern mit Kommas getrennt, z. B.: + +> (siehe Newsletter [#315], [#339] und [#361]) + +Diese Konvention gilt sowohl im Fließtext als auch in Aufzählungen. Die Referenzlinks werden wie im englischen Original am Ende der Datei gepflegt. + ## Grundsätzliches Die deutsche Übersetzung von Optech-Inhalten sollte möglichst den Regeln des englischen [Hauptleitfaden](STYLE.md) folgen. @@ -50,9 +62,9 @@ Fremdwörter möglichst mit Bindestrich schreiben (siehe [Duden, D41](https://ww | fee | Gebühr | | | | funds | Kapital | | | | lightning network | Lightning Netzwerk | | | +| listening node | empfangender Knoten | lauschender Knoten | "lauschend" hat Konnotation des Abhörens | | node | Knoten | Node | Full Node wird nicht übersetzt | | relay | Weiterleitung | | | -| silent payment | Stille Zahlung | | | | work | Arbeitsnachweis | Arbeit | Im Kontext von PoW | --- @@ -100,6 +112,7 @@ Fremdwörter möglichst mit Bindestrich schreiben (siehe [Duden, D41](https://ww | Reviewer | Softwarebegriff | Maskulinum | | Rust Bitcoin | Produktname | | | SCID | Protokoll-/Standardbegriff | | +| Silent payment | Standardbegriff | | | Simple Taproot Channels | Lightning/DLC-Technik | | | Splice | Protokoll-/Standardbegriff | | | Splicing | Protokoll-/Standardbegriff | Neutrum | diff --git a/_posts/de/newsletters/2025-08-01-newsletter.md b/_posts/de/newsletters/2025-08-01-newsletter.md new file mode 100644 index 0000000000..bb5c08009a --- /dev/null +++ b/_posts/de/newsletters/2025-08-01-newsletter.md @@ -0,0 +1,229 @@ +--- +title: 'Bitcoin Optech Newsletter #365' +permalink: /de/newsletters/2025/08/01/ +name: 2025-08-01-newsletter-de +slug: 2025-08-01-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche fasst die Ergebnisse eines Tests zum Prefilling beim +Compact-Block-Relay zusammen und verweist auf eine mempool-basierte Bibliothek +zur Gebührenabschätzung. Wie gewohnt enthält der Newsletter unsere regelmäßigen +Abschnitte mit Zusammenfassungen zu Diskussionen über Änderungen der +Konsensregeln von Bitcoin, der Ankündigung neuer Releases und Release-Kandidaten +sowie einer Übersicht wichtiger Änderungen an beliebter Bitcoin-Infrastruktur-Software. + +## Nachrichten + +- **Test zu Compact-Block-Prefilling:** David Gumberg [antwortete][gumberg prefilling] + in einem Delving-Bitcoin-Thread zur Effizienz der Compact-Block-Rekonstruktion + (siehe auch Newsletter [#315][news315 cb] und [#339][news339 cb]) mit einer + Zusammenfassung seiner Testergebnisse zum [Compact-Block-Relay][topic compact block relay] + und dem sogenannten Prefilling. Dabei sendet ein Knoten proaktiv einige oder alle + Transaktionen eines neuen Blocks an seine Peers, wenn er annimmt, dass diese die + Transaktionen noch nicht haben. Gumbergs Beitrag ist ausführlich und enthält einen + Link zu einem Jupyter-Notebook, mit dem andere selbst experimentieren können. Die + wichtigsten Erkenntnisse: + + - Unabhängig vom Netzwerktransport erhöhte eine einfache Regel zur Auswahl der + zu prefillenden Transaktionen die Erfolgsrate der Blockrekonstruktion von etwa + 62 % auf etwa 98 %. + + - Unter Berücksichtigung des Netzwerktransports führten einige Prefills zu einem + zusätzlichen Roundtrip, was den Vorteil in diesen Fällen aufhob und die Leistung + leicht verschlechterte. Viele Prefills hätten jedoch so konstruiert werden können, + dass das Problem vermieden wird, wodurch die Rekonstruktionsrate auf etwa 93 % + steigt und weitere Verbesserungen möglich bleiben. + +- **Mempool-basierte Gebührenabschätzungs-Bibliothek:** Lauren Shareshian + [kündigte][shareshian estimation] auf Delving Bitcoin eine von Block entwickelte + Bibliothek zur [Gebührenabschätzung][topic fee estimation] an. Im Gegensatz zu + anderen Tools nutzt sie ausschließlich den Zufluss von Transaktionen in den + Mempool eines Knotens als Grundlage für ihre Schätzungen. Im Beitrag wird die + Bibliothek „Augur“ mit mehreren anderen Gebührenabschätzungsdiensten verglichen + und festgestellt, dass Augur eine niedrige Fehlerrate (über 85 % der + Transaktionen werden im gewünschten Zeitfenster bestätigt) und eine geringe + durchschnittliche Überschätzung (Transaktionen zahlen im Schnitt nur etwa 16 % zu + viel Gebühr) aufweist. + + Abubakar Sadiq Ismail [antwortete][ismail estimation] im Delving-Thread und + eröffnete zudem ein informatives [Issue][augur #3] im Augur-Repository, um einige + der in der Bibliothek verwendeten Annahmen zu untersuchen. + +## Konsensänderungen + +_Monatlicher Abschnitt mit Zusammenfassungen zu Vorschlägen und Diskussionen über Änderungen der +Bitcoin-Konsensregeln._ + +- **Migration von quantenanfälligen Outputs:** Jameson Lopp + [veröffentlichte][lopp qmig] in der Bitcoin-Dev-Mailingliste einen dreistufigen + Vorschlag, um das Ausgeben von [quantenanfälligen Outputs][topic quantum resistance] + schrittweise zu beenden. + + - Drei Jahre nach der Konsensaktivierung des + [BIP360][]-Signaturschemas (oder eines alternativen quantenresistenten Schemas) + würde ein Softfork Transaktionen mit Ausgaben an quantenanfällige Adressen ablehnen. + Nur Ausgaben an quantenresistente Outputs wären dann erlaubt. + + - Zwei Jahre später würde ein zweiter Softfork das Ausgeben von + quantenanfälligen Outputs vollständig verbieten. Alle verbleibenden + Mittel auf solchen Outputs wären dann nicht mehr ausgebbar. + + - Optional könnte zu einem späteren, noch nicht definierten Zeitpunkt + eine Konsensänderung das Ausgeben von quantenanfälligen Outputs mit + einem quantenresistenten Nachweisverfahren erlauben (siehe + [Newsletter #361][news361 pqcr] für ein Beispiel). + + Ein Großteil der Diskussion im Thread wiederholte frühere Debatten darüber, + ob es notwendig ist, das Ausgeben von quantenanfälligen Bitcoins zu verhindern, + bevor sicher ist, dass ein ausreichend leistungsfähiger Quantencomputer existiert + (siehe [Newsletter #348][news348 destroy]). Für beide Seiten wurden nachvollziehbare + Argumente vorgebracht, und es ist zu erwarten, dass diese Debatte weitergeführt wird. + +- **Taproot-nativer `OP_TEMPLATEHASH`-Vorschlag:** Greg Sanders + [veröffentlichte][sanders th] in der Bitcoin-Dev-Mailingliste einen Vorschlag, + drei neue Opcodes zu [Tapscript][topic tapscript] hinzuzufügen. Zwei davon sind die + bereits vorgeschlagenen [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] und + `OP_INTERNALKEY` (siehe [Newsletter #285][news285 ik]). Der dritte Opcode ist + `OP_TEMPLATEHASH`, eine taproot-native Variante von + [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (`OP_CTV`) mit folgenden, + von den Autoren hervorgehobenen Unterschieden: + + - Keine Änderungen an Legacy-Skripten (vor Segwit). Siehe + [Newsletter #361][news361 ctvlegacy] für frühere Diskussionen zu dieser Alternative. + + - Die zu hashenden Daten (und deren Reihenfolge) ähneln stark denen, die für Signaturen + in [Taproot][topic taproot] verwendet werden. Das vereinfacht die Implementierung für + Software, die Taproot bereits unterstützt. + + - Es bindet den Taproot + [Annex][topic annex] ein, was `OP_CTV` nicht tut. + Damit kann z.B. sichergestellt werden, dass bestimmte Daten als Teil einer + Transaktion veröffentlicht werden – etwa für Protokolle, die einer Gegenpartei + die Wiederherstellung nach der Veröffentlichung eines alten Zustands ermöglichen. + + - Es wird ein `OP_SUCCESSx`-Opcode statt eines `OP_NOPx`-Opcodes redefiniert. + Softforks, die `OP_NOPx`-Opcodes neu belegen, müssen als `VERIFY`-Opcodes + implementiert werden, die eine Transaktion bei Fehlschlag ungültig machen. + Redefinitionen von `OP_SUCCESSx` können einfach `1` (Erfolg) oder `0` (Fehlschlag) + auf den Stack legen. Dadurch können sie auch dort direkt verwendet werden, wo bei + `OP_NOPx`-Redefinitionen zusätzliche Bedingungen wie `OP_IF` nötig wären. + + - „Es verhindert unerwartete Eingaben mit ... `scriptSig`“ (siehe + [Newsletter #361][news361 bitvm]). + + Brandon Black [antwortete][black th] mit einem Vergleich des Vorschlags zu seinem + früheren LNHANCE-Bundle-Vorschlag (siehe [Newsletter #285][news285 ik]) und stellte + fest, dass beide in den meisten Punkten vergleichbar sind. Allerdings merkte er an, + dass der neue Vorschlag für _Congestion Control_ (eine Form des verzögerten + [Payment Batchings][topic payment batching]) weniger effizient im Onchain-Speicherbedarf ist. + +- **Vorschlag für längere relative Timelocks:** Entwickler Pyth + [schlug][pyth timelock] auf Delving Bitcoin vor, die [BIP68][]-basierten relativen Timelocks + von derzeit maximal etwa einem Jahr auf bis zu zehn Jahre zu verlängern. Dies würde einen + Softfork und die Nutzung eines zusätzlichen Bits im _sequence_-Feld des Transaktionseingangs + erfordern. + + Fabian Jahr [antwortete][jahr timelock] mit dem Hinweis, dass zu weit in die Zukunft + reichende [Timelocks][topic timelocks] zu einem Verlust von Geldern führen könnten, etwa + durch die Entwicklung von Quantencomputern (oder, ergänzen wir, durch die Einführung von + Quantenabwehr-Protokollen wie dem weiter oben beschriebenen Vorschlag von Jameson Lopp). + Steven Roose [merkte an][roose timelock], dass weit in der Zukunft liegende Timelocks + bereits heute mit anderen Mechanismen möglich sind (z.B. mit vorab signierten + Transaktionen und [BIP65 CLTV][bip65]). Pyth ergänzte, dass der gewünschte Anwendungsfall + ein Wallet-Wiederherstellungspfad sei, bei dem der lange Timelock nur genutzt würde, wenn + der Hauptpfad nicht mehr verfügbar ist und die Alternative ohnehin der dauerhafte Verlust + der Mittel wäre. + +- **Sicherheit gegen Quantencomputer mit Taproot als Commitment-Schema:** + Tim Ruffing [veröffentlichte][ruffing qtr] einen Link zu einem [Paper][ruffing paper], + in dem er die Sicherheit von [Taproot][topic taproot]-Commitments gegen Manipulation + durch Quantencomputer analysiert. Er untersucht, ob Taproot-Commitments zu Tapleaves + weiterhin die _Bindungs_- und _Verbergungseigenschaften_ besitzen, die sie auch gegen + klassische Computer haben. Sein Fazit: + + > Ein Quantenangreifer müsste mindestens 2^81 SHA256-Auswertungen durchführen, um ein + > Taproot-Output zu erzeugen und es mit einer Wahrscheinlichkeit von 1/2 zu einem + > unerwarteten Merkle-Root öffnen zu können. Falls der Angreifer nur Quantenmaschinen + > besitzt, deren längste SHA256-Berechnungskette auf 2^20 begrenzt ist, benötigt er + > mindestens 2^92 solcher Maschinen, um eine Erfolgswahrscheinlichkeit von 1/2 zu erreichen. + + Wenn Taproot-Commitments gegen Manipulation durch Quantencomputer sicher sind, könnte + Bitcoin quantenresistent gemacht werden, indem Keypath-Spends deaktiviert und + quantenresistente Signatur-OpCodes zu [Tapscript][topic tapscript] hinzugefügt werden. + Ein aktuelles Update zu [BIP360][] pay-to-quantum-resistant-hash, das Ethan Heilman + [veröffentlichte][heilman bip360], schlägt einen neuen Ausgabentyp vor, der P2TR ähnelt aber die Möglichkeit des Keypath-Spend entfernt. + +## Releases und Release-Kandidaten + +_Neue Releases und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie, +auf neue Versionen zu aktualisieren oder bei der Testung von Release-Kandidaten zu helfen._ + +- [Bitcoin Core 29.1rc1][] ist ein Release-Kandidat für eine Wartungsversion der führenden Full-Node-Software. + + +## Bedeutende Code- und Dokumentationsänderungen + +_Bedeutende aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], +[Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], +[Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], +[Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und [BINANAs][binana repo]._ + +- [Bitcoin Core #29954][] erweitert das `getmempoolinfo`-RPC um zwei neue Relay-Policy-Felder: + `permitbaremultisig` (ob der Knoten bare Multisig-Outputs weiterleitet) und + `maxdatacarriersize` (maximale Gesamtanzahl an Bytes in OP_RETURN-Outputs pro Transaktion im Mempool). + Andere Policy-Flags wie [`fullrbf`][topic rbf] und `minrelaytxfee` waren bereits verfügbar, sodass diese + Ergänzungen nun eine vollständige Übersicht der Relay-Policy ermöglichen. + +- [Bitcoin Core #33004][] aktiviert die Option `-natpmp` standardmäßig, wodurch automatische + Portweiterleitung über das [Port Control Protocol (PCP)][pcp] mit Fallback auf das + [NAT Port Mapping Protocol (NAT-PMP)][natpmp] ermöglicht wird (siehe + [Newsletter #323][news323 natpmp]). Ein empfangender Knoten hinter einem Router, der PCP oder NAT-PMP + unterstützt, wird dadurch ohne manuelle Konfiguration erreichbar. + +- [LDK #3246][] ermöglicht die Erstellung von [BOLT12-Angeboten][topic offers] und Rückerstattungen + ohne [Blinded Path][topic rv routing], indem der `signing_pubkey` des Angebots als Ziel verwendet wird. + Die Funktionen `create_offer_builder` und `create_refund_builder` delegieren die Erstellung des Blinded Paths + nun an `MessageRouter::create_blinded_paths`. Ein Aufrufer kann so einen kompakten Pfad mit + `DefaultMessageRouter`, einen vollständigen Pubkey-Pfad mit `NodeIdMessageRouter` oder gar keinen Pfad mit + `NullMessageRouter` erzeugen. + +- [LDK #3892][] macht die Merkle-Tree-Signatur von [BOLT12][topic offers]-Rechnungen öffentlich + zugänglich. Dadurch können Entwickler CLI-Tools oder andere Software bauen, um die Signatur zu + überprüfen oder Rechnungen zu rekonstruieren. Außerdem wird mit diesem PR ein `OfferId`-Feld zu + BOLT12-Rechnungen hinzugefügt, um das ursprüngliche Angebot nachzuverfolgen. + +- [LDK #3662][] implementiert [BLIPs #55][], auch bekannt als LSPS05. Damit können Clients + sich über einen Endpunkt für Webhooks registrieren, um Push-Benachrichtigungen von einem LSP zu erhalten. + Die API stellt zusätzliche Endpunkte bereit, mit denen Clients alle Webhook-Registrierungen auflisten oder + eine bestimmte entfernen können. Das ist nützlich, um z.B. beim Empfang einer [asynchronen Zahlung][topic async payments] + benachrichtigt zu werden. + +{% include snippets/recap-ad.md when="2025-08-05 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="29954,33004,3246,3892,3662,55" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[augur #3]: https://github.com/block/bitcoin-augur/issues/3 +[news315 cb]: /en/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction +[news339 cb]: /de/newsletters/2025/01/31/#aktualisierte-statistiken-zur-kompaktblock-rekonstruktion +[gumberg prefilling]: https://delvingbitcoin.org/t/stats-on-compact-block-reconstructions/1052/34 +[shareshian estimation]: https://delvingbitcoin.org/t/augur-block-s-open-source-bitcoin-fee-estimation-library/1848/ +[ismail estimation]: https://delvingbitcoin.org/t/augur-block-s-open-source-bitcoin-fee-estimation-library/1848/2 +[news361 pqcr]: /de/newsletters/2025/07/04/#commit-reveal-funktion-fur-post-quantum-recovery +[sanders th]: https://mailing-list.bitcoindevs.xyz/bitcoindev/26b96fb1-d916-474a-bd23-920becc3412cn@googlegroups.com/ +[news285 ik]: /en/newsletters/2024/01/17/#new-lnhance-combination-soft-fork-proposed +[news361 ctvlegacy]: /de/newsletters/2025/07/04/#bedenken-und-alternativen-zu-legacy-support +[pyth timelock]: https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818/ +[jahr timelock]: https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818/2 +[roose timelock]: https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818/3 +[ruffing qtr]: https://mailing-list.bitcoindevs.xyz/bitcoindev/bee6b897379b9ae0c3d48f53d40a6d70fe7915f0.camel@real-or-random.org/ +[ruffing paper]: https://eprint.iacr.org/2025/1307 +[heilman bip360]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAEM=y+W=rtU2PLmHve6pUVkMQQmqT67KOg=9hp5oMspuHrgMow@mail.gmail.com/ +[lopp qmig]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CADL_X_fpv-aXBxX+eJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q@mail.gmail.com/ +[news348 destroy]: /de/newsletters/2025/04/04/#sollten-gefahrdete-bitcoins-vernichtet-werden +[black th]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aG9FEHF1lZlK6d0E@console/ +[news361 bitvm]: /de/newsletters/2025/07/04/#weitere-diskussion-zu-ctv-csfs-vorteilen-fur-bitvm +[news323 natpmp]: /en/newsletters/2024/10/04/#bitcoin-core-30043 +[pcp]: https://datatracker.ietf.org/doc/html/rfc6887 +[natpmp]: https://datatracker.ietf.org/doc/html/rfc6886 From cac5705856a29152d43cfec740191a7a3a9fdec4 Mon Sep 17 00:00:00 2001 From: Walpurga03 Date: Tue, 5 Aug 2025 19:45:39 +0200 Subject: [PATCH 187/278] Fix unintended anchor creation in Newsletter #365 Having a link in the first line turns the bullet point into an anchor which is not expected here. Shifting the link to BIP360 to the next line removes the anchor. --- _posts/en/newsletters/2025-08-01-newsletter.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/_posts/en/newsletters/2025-08-01-newsletter.md b/_posts/en/newsletters/2025-08-01-newsletter.md index 1cfb966cf0..f60b8cc8ed 100644 --- a/_posts/en/newsletters/2025-08-01-newsletter.md +++ b/_posts/en/newsletters/2025-08-01-newsletter.md @@ -63,9 +63,9 @@ Bitcoin's consensus rules._ proposal for phasing out spending from [quantum-vulnerable outputs][topic quantum resistance]. - - Three years after consensus activation of the [BIP360][] - quantum-resistant signature scheme (or an alternative scheme), a - soft fork would reject transactions with outputs paying + - Three years after consensus activation of the + [BIP360][] quantum-resistant signature scheme (or an alternative scheme), + a soft fork would reject transactions with outputs paying quantum-vulnerable addresses. Only spends to quantum-resistant outputs would be allowed. @@ -103,7 +103,8 @@ Bitcoin's consensus rules._ [taproot][topic taproot], simplifying implementation for any software that already supports taproot. - - It commits to the taproot [annex][topic annex], which `OP_CTV` does + - It commits to the taproot + [annex][topic annex], which `OP_CTV` does not. One way this can be used is to ensure some data is published as part of a transaction, such as data used in a contract protocol to allow a counterparty to recover from publication of an old state. From a7666646052e396a4b02c891eeeadd9661330569 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Mon, 4 Aug 2025 08:57:06 -0500 Subject: [PATCH 188/278] Topic: CSV RGB link updates --- _topics/en/client-side-validation.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/_topics/en/client-side-validation.md b/_topics/en/client-side-validation.md index db65927914..d4f5f62a18 100644 --- a/_topics/en/client-side-validation.md +++ b/_topics/en/client-side-validation.md @@ -23,6 +23,9 @@ primary_sources: - title: "Shielded CSV: Private and Efficient Client-Side Validation" link: https://github.com/ShieldedCSV/ShieldedCSV/releases/latest/download/shieldedcsv.pdf + - title: "RGB I.0: Scalable Consensus for Client-Side Validated Smart Contracts" + link: https://yellowpaper.rgb.tech/ + ## Optional. Each entry requires "title" and "url". May also use "feature: ## true" to bold entry and "date" optech_mentions: @@ -47,6 +50,9 @@ optech_mentions: - title: "LND #8960 adds custom channel functionality for taproot assets" url: /en/newsletters/2024/10/11/#lnd-8960 + - title: "RGB v0.12 announced" + url: /en/newsletters/2025/07/18/#rgb-v0-12-announced + ## Optional. Same format as "primary_sources" above see_also: - title: "Pay to Contract (P2C)" From 0bc1725e04ec2c031252a2b2b9dca4da68f6f64b Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Wed, 6 Aug 2025 10:34:05 -0500 Subject: [PATCH 189/278] Podcast: add 365 recap --- .../en/newsletters/2025-08-01-newsletter.md | 24 ++++++++++--------- .../en/podcast/2025-08-05-newsletter-recap.md | 24 +++++++++++++++++++ 2 files changed, 37 insertions(+), 11 deletions(-) create mode 100644 _posts/en/podcast/2025-08-05-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-08-01-newsletter.md b/_posts/en/newsletters/2025-08-01-newsletter.md index f60b8cc8ed..2c57a946d3 100644 --- a/_posts/en/newsletters/2025-08-01-newsletter.md +++ b/_posts/en/newsletters/2025-08-01-newsletter.md @@ -38,6 +38,8 @@ infrastructure software. likely reconstruction rate to about 93% and still supporting further improvements. + {% assign timestamp="1:13:00" %} + - **Mempool-based fee estimation library:** Lauren Shareshian [posted][shareshian estimation] to Delving Bitcoin to announce a library for [fee estimation][topic fee estimation] developed by Block. @@ -51,7 +53,7 @@ infrastructure software. Abubakar Sadiq Ismail [replied][ismail estimation] to the Delving thread and also started an informative [issue][augur #3] on the Augur - repository for examining some of the assumptions used by the library. + repository for examining some of the assumptions used by the library. {% assign timestamp="1:33:53" %} ## Changing consensus @@ -83,7 +85,7 @@ Bitcoin's consensus rules._ spending quantum-vulnerable bitcoins before it was certain a quantum computer fast enough to steal them existed (see [Newsletter #348][news348 destroy]). Reasonable arguments were made on both sides - and we expect that debate to continue. + and we expect that debate to continue. {% assign timestamp="49:17" %} - **Taproot-native `OP_TEMPLATEHASH` proposal:** Greg Sanders [posted][sanders th] to Bitcoin-Dev mailing list a proposal to add three opcodes to @@ -125,7 +127,7 @@ Bitcoin's consensus rules._ his earlier LNHANCE bundle proposal (see [Newsletter #285][news285 ik]) and found it comparable in most ways, although he noted that it is less efficient in onchain space for _congestion control_ (a form of - delayed [payment batching][topic payment batching]). + delayed [payment batching][topic payment batching]). {% assign timestamp="1:13" %} - **Proposal to allow longer relative timelocks:** developer Pyth [posted][pyth timelock] to Delving Bitcoin to suggest allowing @@ -144,7 +146,7 @@ Bitcoin's consensus rules._ transactions and [BIP65 CLTV][bip65]), and Pyth added that their desired use case is for a wallet recovery path where the long timelock would only be used if the primary path became unavailable and the - alternative would be permanent loss of the funds anyway. + alternative would be permanent loss of the funds anyway. {% assign timestamp="12:57" %} - **Security against quantum computers with taproot as a commitment scheme:** Tim Ruffing [posted][ruffing qtr] a link to a [paper][ruffing paper] @@ -167,7 +169,7 @@ Bitcoin's consensus rules._ signature-checking opcodes to [tapscript][topic tapscript]. A recent update to [BIP360][] pay-to-quantum-resistant-hash that Ethan Heilman [posted][heilman bip360] to the Bitcoin-Dev mailing - list makes exactly this change. + list makes exactly this change. {% assign timestamp="23:48" %} ## Releases and release candidates @@ -176,7 +178,7 @@ projects. Please consider upgrading to new releases or helping to test release candidates._ - [Bitcoin Core 29.1rc1][] is a release candidate for a maintenance - version of the predominant full node software. + version of the predominant full node software. {% assign timestamp="1:46:55" %} ## Notable code and documentation changes @@ -194,13 +196,13 @@ repo], and [BINANAs][binana repo]._ relays bare multisig outputs) and `maxdatacarriersize` (the maximum aggregate bytes allowed in OP_RETURN outputs for a transaction in the mempool). Other policy flags, such as [`fullrbf`][topic rbf] and `minrelaytxfee`, were already - exposed, so these additions allow for a complete relay policy snapshot. + exposed, so these additions allow for a complete relay policy snapshot. {% assign timestamp="1:48:12" %} - [Bitcoin Core #33004][] enables the `-natpmp` option by default, allowing automatic port forwarding via the [Port Control Protocol (PCP)][pcp] with a fallback to the [NAT Port Mapping Protocol (NAT-PMP)][natpmp] (see Newsletter [#323][news323 natpmp]). A listening node behind a router that supports either - PCP or NAT-PMP becomes reachable without manual configuration. + PCP or NAT-PMP becomes reachable without manual configuration. {% assign timestamp="1:49:13" %} - [LDK #3246][] enables the creation of [BOLT12 offers][topic offers] and refunds without a [blinded path][topic rv routing] by using the offer’s @@ -208,19 +210,19 @@ repo], and [BINANAs][binana repo]._ `create_refund_builder` functions now delegate blinded path creation to `MessageRouter::create_blinded_paths`, where a caller can generate a compact path by passing `DefaultMessageRouter`, a full-length pubkey path with - `NodeIdMessageRouter`, or no path at all with `NullMessageRouter`. + `NodeIdMessageRouter`, or no path at all with `NullMessageRouter`. {% assign timestamp="1:52:37" %} - [LDK #3892][] exposes the merkle tree signature of [BOLT12][topic offers] invoices publicly, enabling developers to build CLI tools or other software to verify the signature or recreate invoices. This PR also adds an `OfferId` - field to BOLT12 invoices to track the originating offer. + field to BOLT12 invoices to track the originating offer. {% assign timestamp="1:53:35" %} - [LDK #3662][] implements [BLIPs #55][], also known as LSPS05, which defines how clients can register for webhooks via an endpoint to receive push notifications from an LSP. The API exposes additional endpoints that enable clients to list all webhook registrations or remove a specific one. This can be useful for clients to get notified when receiving an [async payment][topic - async payments]. + async payments]. {% assign timestamp="1:54:31" %} {% include snippets/recap-ad.md when="2025-08-05 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-08-05-newsletter-recap.md b/_posts/en/podcast/2025-08-05-newsletter-recap.md new file mode 100644 index 0000000000..43bda6578e --- /dev/null +++ b/_posts/en/podcast/2025-08-05-newsletter-recap.md @@ -0,0 +1,24 @@ +--- +title: 'Bitcoin Optech Newsletter #365 Recap Podcast' +permalink: /en/podcast/2025/08/05/ +reference: /en/newsletters/2025/08/01/ +name: 2025-08-05-recap +slug: 2025-08-05-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt are joined by David Gumberg, Lauren +Shareshian, Jameson Lopp, Steven Roose, and Tim Ruffing to discuss [Newsletter #365]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-7-6/405222600-44100-2-baed90fd0025c.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From c92a0d76a7301fc1b2cd30ac5956c86d50363493 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Thu, 7 Aug 2025 17:28:32 +0200 Subject: [PATCH 190/278] ja: Fix unintended anchor creation at three locations in Newsletter #365 (#2450) * ja: Fix unintended anchor creation at three locations in Newsletter #365 Having a link in the first line turns the bullet point into an anchor which is not expected here. Shifting the link to the next line at three locations removes the anchor. * ja: Fix unintended anchor creation at three locations in Newsletter #365 Having a link in the first line turns the bullet point into an anchor which is not expected here. Shifting the link to the next line at three locations removes the anchor. * <- [x] Key-Management ( Generierung/Import ) --> * Update _posts/ja/newsletters/2025-08-01-newsletter.md Co-authored-by: shigeyuki azuchi --------- Co-authored-by: shigeyuki azuchi --- _posts/ja/newsletters/2025-08-01-newsletter.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/_posts/ja/newsletters/2025-08-01-newsletter.md b/_posts/ja/newsletters/2025-08-01-newsletter.md index 9e486e85ec..6f6c6aec46 100644 --- a/_posts/ja/newsletters/2025-08-01-newsletter.md +++ b/_posts/ja/newsletters/2025-08-01-newsletter.md @@ -52,7 +52,8 @@ _Bitcoinのコンセンサスルールの変更に関する提案と議論をま Jameson Loppは、[量子脆弱なアウトプット][topic quantum resistance]の使用を段階的に廃止するための 3段階の提案をBitcoin-Devメーリングリストに[投稿しました][lopp qmig]。 - - [BIP360][]量子耐性署名スキーム（または代替スキーム）のコンセンサスの有効化から3年後、 + - + [BIP360][]量子耐性署名スキーム（または代替スキーム）のコンセンサスの有効化から3年後、 ソフトフォークにより量子脆弱なアドレスに支払いをするトランザクションを拒否します。 量子耐性のあるアウトプットへの支払いのみが許可されます。 @@ -83,7 +84,8 @@ _Bitcoinのコンセンサスルールの変更に関する提案と議論をま [Taproot][topic taproot]で署名でコミットするためにハッシュされるデータと似ているため、 既にTaprootをサポートしているソフトウェアの実装を簡単にします。 - - `OP_CTV`とは異なり、Taprootの[annex][topic annex]にコミットします。 + - `OP_CTV`とは異なり、Taprootの + [annex][topic annex]にコミットします。 これを使用する1つの方法は、 古い状態の公開によりカウンターパーティがリカバリーできるようにコントラクトプロトコルで使用されるデータなど、 一部のデータがトランザクションの一部として公開されることを保証することです。 @@ -95,7 +97,8 @@ _Bitcoinのコンセンサスルールの変更に関する提案と議論をま これにより、再定義された`OP_NOPx` opcodeが`OP_IF`などの条件句でラップする必要がある場合でも、 直接使用できるようになります。 - - 「... `scriptSig`で予期しない入力を防止します」（[ニュースレター #361][news361 bitvm]参照）。 + - 「... `scriptSig`で予期しない入力を防止します + （[ニュースレター #361][news361 bitvm]参照）。 Brandon Blackは、この提案を以前のLNHANCEバンドル提案（[ニュースレター #285][news285 ik]参照）と[比較し][black th]、 ほとんどの点で同等であると評価しましたが、オンチェーンスペースにおける From aea8e0142b4f8553e97f25cf9d9ed4a1f1602815 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 7 Aug 2025 11:46:13 -0500 Subject: [PATCH 191/278] Podcast: add 363 transcription --- .../en/podcast/2025-07-22-newsletter-recap.md | 734 +++++++++++++++++- 1 file changed, 733 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-07-22-newsletter-recap.md b/_posts/en/podcast/2025-07-22-newsletter-recap.md index 7a6ab69bc1..0256eb0287 100644 --- a/_posts/en/podcast/2025-07-22-newsletter-recap.md +++ b/_posts/en/podcast/2025-07-22-newsletter-recap.md @@ -18,6 +18,738 @@ Mark “Murch” Erhardt and Mike Schmidt are joined by Davidson Souza to discus ## Transcription -_transcription coming soon_ +**Mike Schmidt**: Welcome to Bitcoin Optech Newsletter #363 Recap. Today, we're +going to talk about the utreexo node, Floresta; we're going to talk about the +RGB v0.12 announcement; we're going to cover a FROST signing device, among other +ecosystem software updates; and we also have our usual Notable code and Release +segments. Murch and I are joined this week by Davidson. Davidson, do you want +to introduce yourself? + +**Davidson Souza**: Yeah, hi, I'm Davidson, I am a grantee from Vinteum from +Brazil, and I'm working on Floresta, which we'll talk about in a short time. +So, yeah, thanks for having me. + +_Floresta v0.8.0 released_ + +**Mike Schmidt**: Excellent, thanks for joining us this week. We don't have any +news items this week, so we're going to move right to our monthly segment on +Changes to services and client software. And first in the list is for you, +Davidson, Floresta v0.8.0 being released. We gave a brief overview of the +release, but maybe, Davidson, you just want to remind folks what is Floresta and +probably also what is utreexo, just as an overview. + +**Davidson Souza**: Okay, right. So, Floresta is a project I've been working +for the last three years. It started as a research project, but now it's +getting more traction and becoming an actual thing. But we wanted to basically +answer the question, can we make better light clients that have better security +and privacy, but are still lightweight compared to a full node? Because I +basically noticed that in Bitcoin, either you have the full node, Bitcoin Core, +running on your machine, then you have like an electro-indexer, have to install +a ton of software to get it running for connecting your wallet, which is not +very newbie-friendly and also requires extra hardware. It's always cumbersome. +And as a result of that, last time I checked, the amount of full nodes we had, +both listening and not listening, is pretty much the same we had in 2017, so +about 100k nodes. But on the other side, you have the light clients, but most +of the light clients, they are basically client server in weird performance. +And that's not great, that's not why Bitcoin exists. We need Bitcoin because +you can validate everything, you can especially validate your own transactions. +You can do that locally, so you have better privacy. + +So, I started working on this project to see what are the limits of light +clients. And one of the key features, which is something I started working on, +like the start of my grant, that was what I was working with, which is utreexo. +So, in Bitcoin, the only context that you need, so the only previous information +you need to carry over to validate a block that's not in the block itself, are +the UTXO set and the chain of headers. The chain of headers is super-small so +it doesn't matter. The UTXO set is the big problem because you cannot prune it, +you cannot throw it away like you can with blocks. And it's kind of big. It's +not huge like the blockchain, but it has a problem that you are constantly +accessing the UTXO set in random ways. And for lower-end SSDs or for HDs, this +is terrible. If you ever try to run a Bitcoin node in an HD or a lower-end SSD, +you probably realize that it takes up to months to work, even with a beefy CPU. +And this is because of all these I/O operations from your node. + +Utreexo makes a trade-off where instead of having the full UTXO set, you have +something we call an accumulator, a cryptographic accumulator. Right now, the +accumulator is less than 1 kB, it's super-small, it fits like the CPU's cache. +And the trade-off is that whenever you are checking a transaction or a block, +you receive some extra information proving to you that this UTXO being spent +belongs to that accumulator, so it is inside the UTXO set. And those proofs are +served to you by your peers. We have already clients that can serve those. The +idea is that in the future, Bitcoin Core could at least serve those proofs. +There is still some debates about whether Bitcoin Core should be utreexo, which +we call CSN, which is the lightweight version of utreexo. But at least the +possibility of serving proofs to others, I think, there are no people against +it. And then, you can just store super-small context. + +For mainnet right now, I have one Floresta running here on the machine I'm +talking to, and it consumes like 178 MB of disk and 200 MB of RAM, so it's like +nothing. And we've successfully experimented that on smartphones. And even the +smallest device, we have the record right now from a friend of mine, and it's a +LicheeRV. It's like a super-tiny RISC-V machine that has two cores. I think +it's 200 MB RISC-V cores, 400 MB of RAM and 2 GB of SSD off an SD card. And it +can run on anything, and we have different security models for how you can make, +for example, IBD (Initial Block Download). We have three ways you can perform +this: we have the explicit way, which is just download every block and validate +them; we have something that's along the lines of assumeUTXO, but with one +difference that you don't need to download the huge assumeUTXO file that you +need to with Core, because the utreexo accumulator gains less than 1 kB. So, +it's in the binary already. + +There is one that I think is the first implementation of it. It's an old +proposal by Ruben Somsen called Proof-of-Work (PoW) Fraud Proofs. It can skip +IBD for a cost that's basically, like, the bandwidth that you use is almost the +same as a normal SPV. But the trust assumption here is that you have at least +one honest peer, and at least some percent of the hashrate is honest, and this +percentage can be much smaller than the normal 51% that we have with SPVs. It's +hard to pin a number because of variance, but the number of peers that need to +be attacking you to make you, like, accept an invalid block needs to be over +90%. So, over 90% of the hashrate needs to be colluding to attack clients that +have this PoW Fraud Proof. And this is only for IBD. So, after your IBD, you +can check every single block. + +**Mike Schmidt**: Davidson, what are the names of those nodes that are serving +up the proofs to these light clients? I forget the name historically. + +**Davidson Souza**: You can be like a utreexo archive node, which means that you +have proofs for every single block in history. But right now, because wallets +still don't keep utreexo proofs for their own UTXOs, we have something called +the bridge nodes. The bridge nodes have the entire UTXO set in a special +format, which is the whole forest, and they can generate proofs for everything. +You don't necessarily need to be a bridge node to serve proofs. You can be a +utreexo archive node. So, you have proof for blocks, but you don't have the +accumulator in those big states, like with all the UTXOs. Ideally, we could in +the future, if utreexo gets traction, we could drop the bridge nodes, but that +will require some support from clients. + +**Mike Schmidt**: So, maybe transitioning to one of the v0.8.0 items that I saw, +which is the encrypted transport BIP324, what communications are being encrypted +then from the light client to the bridge nodes, light client to the archival +nodes? + +**Davidson Souza**: Yeah, Floresta works the exact same way that a normal node +would when it comes to P2P. So, it appears as if other Bitcoin software, it can +connect with Bitcoin Core, it can connect with btcd, which utreexod, which you +guys already covered, which is the bridge node implementation we have now, it +connects with them, it can talk normal Bitcoin P2P protocol, you can ask for +blocks, transactions, compact block filters, anything that a node would, we can +ask for. And we recently got this new improvement for P2P v2 and in this +context, the P2P v2 does exactly the same it does in Core or any other full node +implementation. + +**Mike Schmidt**: Okay, that makes sense. What else would you like to highlight +from this release specifically or utreexo and Floresta more broadly? + +**Davidson Souza**: Yeah, so one thing we're trying to do and we have made some +progress in this release is allowing applications that already have some +infrastructure to integrate Floresta, because Floresta is also a library. So, +we've built a BDK for a Hackathon I participated in. Our team built a BDK-based +wallet, mobile wallet, so that we run on your phone. And the idea is that any +mobile wallet could use Floresta, it's very simple, it's like four lines of code +that needs to change and you have Floresta running in your background. This is +one thing that I've been trying to do since the beginning. We have integrated +Electrum Server and watch-only wallet exactly for this reason. So, we are now +implementing all the RPCs from Bitcoin Core and we are making integration tests +to make sure that Floresta and Core are talking the exact same protocol. +Because applications, for example, some people from like node-in-a-box +implementations told me that they would love to have a lightweight version of +their product, because they see, especially in the third world, people want to +have some node, but the hardware that needs to run their products is still very +expensive. And living in Brazil, I know this. So, a lighter version of their +hardware would be very nice. But they need to have the same JSON RPC +implementation of Bitcoin Core, because this is the way that this software is +made to work. Like, you can swap out the Bitcoin implementation, but you need +to implement the exact same RPC. + +So, we've made progress on this and there is still a long way to go, but we are +making progress. And testing, we are working a lot on testing to make sure that +nothing is broken, the consensus implementation is working. We recently we have +a grantee from OpenSats that's working very hard on this question of testing or +implementation of Bitcoin. He recently took a lot of test cases from Bitcoin +Core, and we're now using Bitcoin Core's own tests to make sure that our code +also works with this. And we're working on this as well. We've been making +some progress on the compact block filter integration. It still has some +low-hanging fruits that I would like to address, but it's not the main priority +right now. But we do support block filters for re-scanning your wallet after +you IBD. You can add a descriptor or an export or an address, and tell Floresta +to go back and look for transactions related to that address or those addresses. +So, yeah, there's a lot on this release. + +**Mike Schmidt**: One thing that we also highlighted in the quick newsletter +write-up was some additional features around monitoring and collecting metrics. +Do you want to talk about that? + +**Davidson Souza**: All right, yeah. We have Prometheus, which is like a +monitoring system that you can export some statistics about your running +software. I think right now, we have one for the average time that takes to +validate blocks; some about P2P messaging, like how long does our peers take to +respond; what messages are we sending the most. So, there is like a lot of +small statistics about your node that's running that you can export to +Prometheus and use something like Grafana to make a dashboard and see those +statistics rendered in a nice dashboard. + +**Mike Schmidt**: Cool. Go ahead, Murch. + +**Mark Erhardt**: Yeah, so you said that Floresta would be able to support +especially light client wallets. Do I understand right that it would +essentially be a plugin replacement for something like BDK, or is it another +layer? What does it exactly replace, the backend blockchain, +bring-your-own-blockchain part, or is it more of a translation layer? + +**Davidson Souza**: Yes, exactly, the bringing-the-blockchain part. By the way, +we have a fellow from Intune that's working on integration for BDK and Floresta. +So, in the future, people using BDK will be able to use Floresta as the chain +source provider. So, you'll be making all the validation that Floresta does and +all the local syncing, and all without changing anything. You just instantiate +Floresta, parse it through your BDK wallet and everything will work under the +hood for you. + +**Mark Erhardt**: Right. So, if BDK integrates with Floresta and Floresta is +dependent on having the proofs, I assume that when you are asking for +transactions or UTXOs or blocks, it would get the proofs; and then, how would +the wallet know which proofs to retain? That would be on BDK to tell the +Floresta layer, or how would that interaction work? + +**Davidson Souza**: Well, right now the way we do this, the wallet doesn't +necessarily need to follow those proofs because they are only using consensus +parts, which is entirely in the side of Floresta. But if you want to change +into the bridge-less network, which is the network I say that we don't need +bridge, we will need a way to tell Floresta that it needs to follow those proofs +and BDK would have this integrate, like some hook, something that it would call +to tell Floresta to follow them. And possibly, we haven't thought about that +interface yet, but I've talked about this with Evan Lin, which is one of the +main developers of BDK, and he said that he absolutely thinks that BDK should +support utreexo. And by the way, we have a Rust implementation of utreexo. +It's very fast, very well-tested. So, it will be very easy to integrate this. + +**Mark Erhardt**: In danger of repeating something from earlier, you said that +the on-disk footprint is much smaller, but I was wondering about the bandwidth +footprint. I would assume that requiring the proofs and downloading more data, +this would probably only happen for the transactions that the wallet is +interested in. But how does the bandwidth use compare? + +**Davidson Souza**: Actually, when you download the block, you download all the +proofs, because you need to validate all the UTXOs. The proof is interesting +because it can go as bad as 100% overhead. So, if a block is 1 MB, then you +have 2 MB. I don't think it can go worse than 100%, but this is something +that's in the paper and we are working now. All UTXOs in Bitcoin, they follow a +very interesting pattern where they are more likely to be spent right after +being created. And as they get older, the likelihood of them being spent goes +down in a Poisson distribution. So, what we're doing is, even with a few +hundred MB of cache, you can save, like, 60% of bandwidth, because even though +your cache is tiny, it always rotates, so you are always recycling that cache. +And you keep, let's say, the last 100 blocks' worth of UTXOs, like UTXOs that +have been created in the last 100 blocks that will be spent within the next 100 +blocks. You keep those, you don't ask for those in the P2P. And Calvin, who is +working more on this, he told me that you can go as low as like 40% or 30% +overhead. So, a 1 MB block, 300 kB of proof. + +So, I think it's an okay trade-off. It's not huge in terms of a block, and it's +144 blocks every day, so a few hundred MB. + +**Mike Schmidt**: Davison, you mentioned utreexod, and I think we covered a beta +release from them just a little over a year ago. Do you have any visibility +into how that has been progressing? + +**Davidson Souza**: Yeah, Calvin is working hard on this P2P optimization I +talked about, and he's doing more experiments. And we'll probably sync up +releases, because we changed the way proofs are propagated in the network, and +both clients need to speak the same protocol. So, we may sync the releases when +it comes out. I think it's almost done, he had some very interesting results. +He told that the implementation is very sound, it's working, there are no +obvious bugs. So, he's been working on that, and there are also some new +features upstream. For example, recently, btcd merged P2P v2 as well, so the +next release will also be packed with some very nice stuff. He's only holding +back on releasing something exactly because there is all this research going on +about P2P caching. This is why you haven't heard any release from him, but he's +very active working on this, like profiling stuff, measuring. He and Tadge came +up with a caching algorithm for optional caching, and it's now implemented and +working. So, yeah, it's going great. And I hear that in the next couple of +weeks or months, there will be BIPs as well. + +**Mike Schmidt**: I can imagine some listeners wanting to play around with +Floresta, and maybe you can provide those listeners just, is there a one-stop +shop if somebody wants to start prototyping something using Floresta? What's +the best place for them to go? + +**Davidson Souza**: Yeah, we have excellent documentation. You should go to +GitHub and go to the Floresta main crate. You'll see lots of examples, and we +also have an mdBook explaining the internals if you wanted to get more about how +it works internally. And because Floresta's broken down to multiple crates, and +one implements the chain part, one implements the P2P part, one implements the +compact block filters part, you can combine different crates together and +assemble what you want, and they are all well-documented there, the API. I also +have some examples of using it for example as a backend for Core Lightning +(CLN), for using with Lightning. So, you can find those either in the Vinteum +repository, which is where Floresta lives, or in my personal GitHub; it's just +my name, Davidson Souza. + +**Mike Schmidt**: Seems like it would be a great project for people to fire up a +weekend proof of concept for something that they're working on. So, yeah, +thanks project for people to that and, Davidson, thanks for your time joining us +today. You're welcome to hang on for the rest of the newsletter or you're free +to drop. + +**Davidson Souza**: Sure. I'll hang on more. + +_RGB v0.12 announced_ + +**Mike Schmidt**: RGB v0.12 announced, and this is an RGB blogpost that we +referenced in the write-up that officially announces the release of RGB's +consensus layer with RGB's client-side validated smart contracts available now +on testnet and mainnet. So, they've solidified what they're calling consensus +for their client-side validation protocol. In their blogpost, they outlined a +few categories of things that have been worked on over the last eight months +when they've been doing some protocol redesign, including being ready for +zero-knowledge proofs, greatly simplifying the protocol itself. They noted, +"RGB has so far been notoriously infamous for the protocol complexity", but +v0.12 should simplify a lot of that. And there's a bunch of details in the +blogpost that I'm glossing over here, as they're probably too in the weeds for +this discussion. + +There's also a section on specifically payment improvements including invoicing, +multiple asset contracts, payment scripts, and also better support for chain +reorganizations. There's also a whole category of performance. They've really +focused on bringing their performance up to production level, and they get into +some of the optimizations that they've made there. And then the final category +of things that they highlighted in this release was just broader test suite +coverage. So, they have integration tests, not just happy paths, but also +attack scenarios that they've provided unit test coverage for. Murch, I sort of +jumped right into it, but we didn't really talk about client-side validated +smart contracts. I don't know if you have anything to add though. + +**Mark Erhardt**: Oh, basically that means that you put on a set of colored +glasses and when you view the blockchain through those, and maybe also receive +some additional out-of-band information, activity on the blockchain can have +additional meaning in this colored world. So, you sort of build an additional +layer on top to provide context for some of the activity. So, my understanding +is that with the RGB v0.12 RC, this is, according to their blog post, a +consensus release, or de-consensus release. And the worry was that with +client-side validation, if the consensus changes, it might break forward +compatibility of smart contracts. So, after they have released their consensus, +it should no longer break smart contracts. They were suggesting to any users +that any smart contracts that are already deployed should be redeployed for this +version. + +They've also called for developers that want to integrate this release into +their products that they would be happy to support them, and were indicating +that the full release of v0.12 would follow after some developers have +integrated it into their products, probably to make sure that this ossifying +consensus release is tested by implementers and made sure that actually there +doesn't have to be any other change before it's fully released. Did that cover +your question, Mike? + +**Mike Schmidt**: Yeah, I think so. I'd also point folks who are curious about +more, there's a client-side validation topic on the Optech wiki. So, when Murch +is talking about those colored glasses that these protocols use, you can think +of RGB of having one color-tinted glass for their protocol. There's also +taproot assets that sort of has a different set of glasses, and then we've +recently talked with Jonas Nick about Shielded CSV, which is another flavor of +glasses, to mix my metaphors. And so, check out the topics for the general +category of client-side validated protocols, and you can also dig into some news +that we've had over those different protocols over the years. + +_FROST signing device available_ + +**Mike Schmidt**: FROST signing device available. We've talked a bit about +FROST and its ability to have threshold signature schemes that actually end up +as a single-signature on chain. But now we have a signing device that supports +that threshold signing using the FROST protocol. And it's called Frostsnap, and +I think we've had some folks from there on in the past, I think when they were +doing software-related FROST things, but now they have actual signing devices +that you can put together to do FROST thresholds signing. Unfortunately, we +weren't able to get anyone from Frostsnap on the show, but I do have a few notes +offline that I received after I let them know that we're going to talk about +this. + +So, the device is actually for early adopters, and they're calling this +Frostsnap Frontier. The Frostsnap team thinks that they have a good working +product, but they want to start sharing that now with folks who are maybe more +bleeding-edge-type users to join them in their exploration of this space. The +Frostsnap Frontier is focused on getting people to not store their wealth in a +single hardware device that's in their house, for example, and I think that they +are really wanting folks to buy more than one of these. I think there's packs +of like three and five that you can use, and then you can set up your threshold +scheme accordingly. And then, each of those devices has its own backup, which +is a Shamir share, and then a threshold of them restores the wallet without even +needing descriptor backups. + +They noted that everything is open source, it's all in Rust, there is a user +interface, there's a wallet that's based on BDK, they can do PSBT signing as +well. So, if you don't trust their wallet, you can use something like Sparrow +and coordinate via scanning PSBTs. And I think all these Frostsnap Frontier +devices go through the phone that speaks to the various signing device +components, but I'm not totally sure on that. Murch, did you get a chance to +double-click into Frostsnap? + +**Mark Erhardt**: I saw a little bit of the coverage, I think last year, and I +think it's really cool that you just plug them into each other, and then as soon +as it notices that it has a sufficient quorum, it just creates the signature. +And it sounds like they've really thought about the UX, because even while you +might be working on a 3-of-5, or whatever, once three devices are there, even +without descriptor backups or anything like that, your three devices can sign +for the UTXOs. So, just making this hardware and plugging the keys into each +other is kind of cyberpunk! + +**Mike Schmidt**: Yeah, if you look at some of the videos that I've seen on +social media, the profile of the device is interesting. It sort of looks like +the face of a watch almost. And then, you can plug a series of these into each +other to do the threshold signing. So, if you have a 3-of-5 or something, you +can plug three in and it'll sign for you if you lose the other two. So, pretty +cool. You end up with that single-signature on chain, but you're actually doing +threshold multisig behind. So, I think that's pretty cool. Folks are probably +familiar with MuSig, but in the MuSig case, you need to have all five, you know, +5-of-5, and you get that one signature on chain. So, this is a cool way that I +think maybe older bitcoiners are familiar with doing the 3-of-5, and things like +that, so you can do that now with a lot less space used on chain. + +_Gemini adds taproot support_ + +**Mike Schmidt**: Gemini adds taproot support. This goes for both the Gemini +Exchange as well as the Gemini Custody service. They both added support for +being able to send or withdraw, in the case of exchanges and custody, to taproot +addresses, so that's great. I know, Murch, you were tracking that alongside us +with the whentaproot website. You scooped us. + +**Mark Erhardt**: I did, yes. Someone working at Gemini reported that to us in +May, I think. So, Gemini's had sending to P2TR output support since May. I +thought it would also be fun to look a little bit at taproot adoption. It's +been almost 200,000 blocks since taproot activated. We're getting close to four +years, which will be in November. So, while taproot is the most common type of +UTXO now in our network, clearly because various Colored Coin protocols use P2TR +outputs preferentially in the last couple of years, there's a very small amount +of bitcoin held in P2TR outputs. It's only 156,000 bitcoin as of last week, +which is about 0.8% of the supply. + +But this adoption has changed since the start of the year, especially when the +mempool emptied and people started doing some UTXO management and cleaning up +their wallets maybe a little bit after the fees have come down. So, the UTXO +set peaked in December at about 187.2 million UTXOs. Maybe it was .3, sorry. +And now it's about 166 million. So, we're down 21 million UTXOs from the peak. +And UTXOs are slightly up, but mostly P2WPKH and P2PKH are down together 16 +million UTXOs. So, while some of the other parts were being discussed, I was +just looking up numbers from last year. Last year in March, I believe, let me +double-check; yes, in March last year, there were only 60,000 bitcoin in taproot +addresses, so we're up almost 100,000 since then. So, I think that maybe a few +more people are now rolling out taproot. + +Unfortunately, some of the biggest businesses in Bitcoin still don't support +sending to taproot outputs, for example, crypto.com and Binance, who really +should think about getting into gear. Yeah, anyway, that's maybe a little +update on whentaproot. + +**Mike Schmidt**: And so, I suppose as taproot rolls out to more service +providers and there's more innovation, like Frostsnap and things like that, +taking advantage of schnorr signatures and taproot, as it percolates out, +perhaps those numbers continue to go up with adoption of service providers and +signing devices and features like that. + +**Mark Erhardt**: I'm also still waiting for silent payments to be implemented +in Bitcoin Core. It's out on a few other wallets, but that would make P2TR have +some unique functionality. Of course, coming from the Quantum Summit last week, +if you subscribe to the threat of quantum computers, one downside is of course +that P2TR outputs directly reveal a public key which could be used for quantum +decryption to find the private key. Personally, I felt that everything we heard +from researchers in the field and the general story, we still have quite a few +years until we really have to be afraid of quantum computers threatening quantum +decryption, but I think it's a good time to start talking a little bit about it. +So, in my opinion, we're still good to amp up the P2TR adoption. + +**Mike Schmidt**: And isn't, related to quantum, Murch, one of the schemes, I +think it was BlueMatt, and I don't know if it has a fancy name or anything, but +sort of having an escape hatch in a taproot script path, so that if there is +this quantum breakthrough and you can reverse a public key into a private key, +in theory if it were a settled upon scheme to hide this in the taproot +scriptpath like that, the threat of quantum could actually increase people +adopting taproot for that reason, at least on that one access. What are your +thoughts on that? + +**Mark Erhardt**: Yeah, I think that in that context, it would be nice to start +putting scriptpath spending conditions on all of your taproot outputs so that if +we ever get into the position where the appearance of a +cryptographically-relevant quantum computer makes an appearance, we would +disable the keypath spending, or let's say there is proposals for disabling the +keypath spend in order to make it hard for quantum computer operators to +misappropriate coins, and then you'd have to fall back to some sort of other +proof. These seem to be based either on the wallet derivation rules or on +scriptpaths. BIP360, which is the BIP that tries to paint a path towards a +quantum-resistant output type, is also working in that regard. They propose a +new output script type that has the scriptpath spending for taproot, but not the +keypath spending, which makes scriptpath spending a little cheaper in their +proposal. But then of course, the cheapest variant, which is the keypath spend, +wouldn't be available anymore. + +So, at the Quantum Summit also, I thought that the proposal that Tadge made was +directionally very interesting. He talked about something he called LifeRaft, +and the idea there would be that you sort of can publish information to the +blockchain that proves that you are holding the private key or can derive +additional sibling keys, or whatever. And then later, when you show the +transaction, you can only spend it in conjunction with the prior commitment, +which would mean you sort of have to know ahead of -- well, this would allow you +to spend by committing to what you'll reveal later and this is hash protected, +so it would be quantum-resistant. And a very appealing property of this +proposal is that if the output scripts have scriptpaths or have the properties +we need for LifeRaft, we wouldn't need any additional complexity or output types +in order to have a way of quantum-resistant spending, should that ever happen. +Personally, I think we might be some decades away of that actually becoming a +threat, but it's good to talk about this stuff. + +**Mike Schmidt**: Well, as we see with taproot adoption that we just talked +about, sometimes things can take longer than we think to roll out to the +community. Although, I suppose if quantum is maybe a bit of a bigger flame +underneath people's butts to move, then maybe nice features of taproot might be. +But that all remains to be seen. It's all speculative now in the quantum world. + +_Electrum 4.6.0 released_ + +Our last piece of software that we highlighted this month was Electrum 4.6.0 +being released. And in addition to updates to their particular Lightning +implementation and some other things we called out, they're adding support for +submarine swaps, and they actually used Nostr to discover potential peers to do +these swaps with. So, you can swap onchain bitcoin for Lightning channel +bitcoin, or vice versa, using submarine swaps and Electrum with this latest +release. + +_LND v0.19.2-beta_ + +Releases and release candidates, LND v0.19.2-beta. We covered 0.19.2-beta.rc2 +last week, and looking at the release notes for the beta now, I think that our +coverage last week in Podcast #362 still stands in terms of highlighting the +features in this release. You can refer back to that podcast for more, but a +couple of headline features were the database migration to speed up performance +and signet/testnet4 peer seed support and a bunch of bug fixes. The release +also made a point to say 'important' bug fixes, so I wanted to reiterate that +word, 'important', for anyone who's running LND. + +_Bitcoin Core #32604_ + +Notable code and documentation changes. Bitcoin Core #32604, mitigating +disk-filling attacks. Murch? + +**Mark Erhardt**: Yeah, so I looked a little bit at this. Apparently, this is +trying to deal with attacks where you would cause a node to just fill the disk +with excessive logging, and it introduces a limit of 1 MB per logging source per +hour. And that way, if some activity starts that causes a node to excessively +log, it would just start omitting some of the logs and indicate in the log that +one of the sources is being suppressed by adding asterisks. And the console +output or manual logging that have explicit arguments and things like that are +exempt. So, the most important logs should always go through, and especially +logs that you specifically configured, from what I understand. And yeah, just +making it more robust, I guess. + +_Bitcoin Core #32618_ + +**Mike Schmidt**: Bitcoin Core #32618, removing watch-only wallet functionality. +Murch? + +**Mark Erhardt**: Yeah, so in the legacy wallet, it was permitted to have both +spendable and derivation instructions next to watch-only derivation +instructions. And that posed some interesting problems, like if you do coin +selection and you have some watch-only coins selected and some spendable coins +selected, how do you distinguish them? How do you manage all of this mixed +state? Then, you might only need to create a PSBT so you can get the additional +signatures from the signing device or second computer that has the actual keys, +and so forth. The descriptive wallets that we've had for a few years now take a +radically different approach, where they do not permit the mixing of watch-only +and spendable coins. So, a wallet is either watch-only or spendable directly by +this device. And that simplifies a lot of these concerns where you either know +you're only creating a raw transaction that still needs to be signed later, or +you're creating a finalized transaction directly in your transaction building. + +So, this PR, now that the legacy wallet has been removed recently, obviously +there is still a migration path, but just we do not create new legacy wallets, +and when we load them, we can only migrate them to a descriptive wallet at this +point. Yeah, anyway, the descriptive wallets do not mix the functionality. +That makes a lot of things a lot simpler and this PR cleans up a lot of that +code that is no longer necessary to address the complexity of mixing. + +_Bitcoin Core #31553_ + +**Mike Schmidt**: Bitcoin Core #31553, adding reorg functionality to cluster +mempool. + +**Mark Erhardt**: Yeah, okay. So, we've talked about cluster mempool a couple +of times before. One of the new things that comes with cluster mempool is that +previously, we were limiting ancestors and descendants of transactions, but now +we limit transaction clusters because that is what sort of bounds the +computational complexity for finding out what we want to keep. So, if you have +a reorg, a bunch of transactions might get pushed back into the mempool. And +that could, for example, combine some clusters that were separated, like two +transactions spending from an ancestor transaction that were in separate +clusters would become part of one bigger cluster if the ancestor gets added back +into the mempool. Whenever this would violate the cluster limit, we get a +little problem, because we don't want to have clusters bigger than the cluster +limit in our mempool, because it might get computationally expensive to find out +how to linearize that and what to include in blocks, etc. + +So, what this PR does is whenever a bunch of transactions are added back to the +mempool, it looks at the candidate clusters and for any oversized candidate +clusters, it trims them down to the cluster limit. It does this here by +linearizing each cluster individually and then sort of merge-sorting them by +picking the highest feerate chunk that does not have unmet dependencies into the +filtered cluster or trimmed cluster until a cluster limit is hit, and whenever a +transaction exceeds the limits, it is trimmed with all of its descendants. So, +for example, with the prior example that I suggested where an ancestor was added +back and maybe we had two clusters that were full-sized before and now they +become one cluster, it would just use the linearizations of those two clusters +it had and start adding them back to one big cluster, and then drop whenever it +exceeds the limit from either one or the other cluster the lowest feerate +chunks. This is of course consistent now with the order in which we will build +blocks, because the chunks with the lowest feerates are the ones that are going +to be the least interesting for building blocks until, well, they come back up +and everything before them has been mined. + +Yeah, so cluster mempool is progressing. I think there's still some work to be +done to fully integrate it with mempool, like a lot of the low-level stuff is +there now, but it's not yet fully integrated and replacing the old mempool +design. So, as we're coming up to feature fees for the next release, it's +getting exciting of whether it's going to be in the next release or in the +second next release. + +_Core Lightning #7725_ + +**Mike Schmidt**: I see, okay, so we're getting down to the wire here of cluster +mempools going to be in or not. Core Lightning #7725. This one's pretty +straightforward. This PR adds a web page to the repository that can be used to +view and interact with log files from CLN. It has some filter and search +capabilities, and maybe it's just a nice quality of life feature for our CLN +folks. There's a little bit of back and forth on whether that should be in the +CLN repository or not, but they did merge it and there's a little video in the +description, if you click through, to see someone interacting with the log. + +_Eclair #2716_ + +Eclair #2716 is a PR titled, "Endorse HTLC and local reputation". The PR adds +three things and I'm going to enumerate them here and tap in Murch in a minute. +But the first one is, it implements the experimental endorsement signaling that +was specified in BLIP4, which is basically just a lightweight mechanism and it +can be reversed as well if it doesn't work, to assess various reputation +algorithms. Maybe now I'll tap in Murch. Murch, why do we need a reputation +metric on the LN? + +**Mark Erhardt**: Yeah, this is for channel jamming mitigation. So, +specifically, jamming could be used to find out exactly how the balances are +distributed on a channel, or to just reduce some nodes' capacity of forwarding +by locking up all of their funds. The HTLC (Hash Time Locked Contract) +endorsements are specifically supposed to help with the slow jamming, where you +just hold a lot of funds on a channel until the HTLC times out in order to +reduce the capacity of the channel owner. The fast jamming is mitigated by +upfront fees. So, if you just do a lot of probing, a lot of back and forth +where you build up HTLCs but never spend anything, if you have to pay upfront +fees for building up HTLCs, that will introduce a cost and reduce the incentive +for that sort of behavior. For the slow jamming, the idea is as you continue to +interact with another node, you learn which nodes send HTLCs and they get +quickly finalized and the funds are freed up again. And as that happens, your +peers build up some reputation with you and you limit, I think it was half of +your capacity and half of your channels, sorry, HTLC slots only to peers that +have reputation. + +If I remember correctly, the direction in which the endorsement was assigned +recently turned around to fix a bug. Originally, nodes would endorse an HTLC to +their downstream peer. As they forward it, they would say, "Hey, I think this +is coming from a good source, please treat it as a reputable HTLC". And I think +that was turned around. So, now when nodes receive an HTLC that has the +reputable marker, they check whether they considered the sender reputable and +then forward it as such or don't. Anyway, the idea is that this should help +with mitigating slow jamming. + +**Mike Schmidt**: Thanks for that sidebar, Murch. So, the experimental +endorsement signaling was part one of this PR. Part two was an implementation +of the local reputation system. Basically, it's defined as how much the peer +node paid the local node in fees, divided by how much they should have paid the +Eclair node for the liquidity slots that they blocked. And then, there's +scoring based on that, successful payment scoring 100, and anything other than +success scores some penalty weighting. And there's also the confidence that the +HTLC will be fulfilled is also transmitted to the next node, and there are eight +different endorsement levels. I think there's just 100 divided by 8 are the +different ranges. And then, there's also a few different knobs in Eclair for +operators to customize some of the reputation scoring mechanisms, in terms of +the different aspects across the reputation score. And so, that reputation +system is number two. + +Then, number three, this PR adds a limit on the number of small HTLCs per +channel, "We allow just a very few small HTLCs per channel. So, it's not +possible to block large HTLCs using only small HTLCs". It should be emphasized +that this PR, the focus here is to collect data to improve the types of attacks, +or data to research against the type of attacks that Murch outlined, channel +jamming attacks, and does not yet implement any penalties. + +_LDK #3628_ + +LDK #3628 further builds towards LDK's async payment capabilities that would +allow someone offline to receive LN payments. In Newsletter and Podcast #361, +we actually covered LDK's client-side implementation of their static invoice +server protocol. And that protocol basically allows coordination between +potentially offline receiver with an always-on server that would then serve +static invoices on the receiver's behalf. So, in #361 we talked about the +client side of that. And then this week, we're covering the server-side +component of that coordination, and this PR implements LDK static invoice server +flow protocol that we also talked about in Newsletter and Podcast #361. So, now +you have the client side, you have the server side, so it looks like it's +getting closer. If you want to see how close LDK's async payment capabilities +are, check out their tracking issue #2298 on the LDK repo. + +_LDK #3890_ + +LDK #3890 changes the way LDK scores routes in its pathfinding algorithm. So, +previously, LDK only considered the total cost in fees. Now, it considers the +total cost divided by the channel amount limit, which is essentially the cost +per sat of usable capacity. And this new approach will slightly bias +pathfinding towards higher-capacity routes, but it has the advantage of reducing +excessive multipath payment sharding and results in a higher payment success +rate. On the flipside of that, the change now overly penalizes smaller +channels, but it was noted in the PR that the trade-off is preferable to the +previous excessive multipart payment sharding. In the PR, it was noted, +"Several users have reported that we often attempt far too many MPP parts". So, +based on that feedback that LDK devs heard, they tweaked their scoring in the +pathfinding algorithm. + +_LND #10001_ + +Last PR this week, LND #10001, which allows LND's quiescence protocol to be used +in production/mainnet. Quiescence, as a reminder, is essentially when you have +an LN channel, the two parties to that channel say, "Hey, we're going to pause +and we're going to do something fairly drastic to this channel and we don't want +any activity going through the channel during that time". So, that pause is, +quiescence, essentially the way I think about it as sort of a pause in the +channel activity. And one example that we have used in previous podcasts to +explain that is the need for pausing during a splice, so when someone's splicing +in or out of a channel. There's also another reason that you might want to +pause the channel or quiesce the channel, which is dynamic commitments, also +referred to as channel commitment upgrades, which would allow LN to upgrade +channel types on the fly without having to close the channel and then reopen the +channel using a different commitment type. So, for example, perhaps allowing a +move from existing legacy P2WSH format to a taproot-based channel without having +to close the channel out. + +So, this PR also adds a configuration value for how long that timeout is. So, +obviously you're pausing, you can't pause indefinitely. It defaults to 60 +seconds, but doesn't allow anything less than 30 seconds. So, I guess if you're +pausing, it's going to be at least 30 seconds. So, any dependent operations +like dynamic commitments or splicing have to finish their operations under this +timeout value. Otherwise, I think the node will disconnect, is the behavior. +Yeah, Murch. + +**Mark Erhardt**: I thought it was funny that you said 'legacy' to P2WSH. So, +we've been waiting for a very long time for LN channels to switch to P2TR +channel, what was it, funding outputs? Yes. I think that's still in the works. +There's also a lot of discussion recently again how P2TR would be easier if some +of the introspection opcodes that people are talking about were present for PTLC +(Point Time Locked Contract) adoption and re-bindable signatures. We talked +about that two weeks ago or so. Anyway, it's hopefully happening at some point +that we do get P2TR channels, which would make it a lot easier for LN channels +to not stick out like a sore thumb on blockchain data, because in the happy +path, they just look like a P2TR single-sig. But yeah, we'll report when that +happens. + +**Mike Schmidt**: That's it for the newsletter this week. Davidson, thanks for +joining us and hanging on for the newsletter. We appreciated your time earlier. + +**Davidson Souza**: Yeah, thanks for having me, guys. + +**Mike Schmidt**: And, Murch, thanks for co-hosting and for all you for +listening. We'll hear you next week. + +**Mark Erhardt**: Hear you next week. {% include references.md %} From c4aa36ca47106a6632cd10e6abb1a980691b15c2 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 7 Aug 2025 12:03:37 -0500 Subject: [PATCH 192/278] Podcast: add 364 transcription --- .../en/podcast/2025-07-29-newsletter-recap.md | 1058 ++++++++++++++++- 1 file changed, 1057 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-07-29-newsletter-recap.md b/_posts/en/podcast/2025-07-29-newsletter-recap.md index 215879ed97..0ea3f0eab6 100644 --- a/_posts/en/podcast/2025-07-29-newsletter-recap.md +++ b/_posts/en/podcast/2025-07-29-newsletter-recap.md @@ -18,6 +18,1062 @@ Mark “Murch” Erhardt and Mike Schmidt are joined by Matt Morehouse and Jesse ## Transcription -_transcription coming soon_ +**Mike Schmidt**: Welcome everyone to Bitcoin Optech Newsletter #364 Recap. +Today, we're going to talk about an LND vulnerability related to gossip; we're +going to talk about a technique that allows custodians to enforce spending +policies without having an xpub; we want to talk about post-quantum signature +schemes and how they could support things that we like, like HD wallets, silent +payments, and other wallet primitives that we have today; we have three Stack +Exchange questions; and then we have our regular Notable code and Release +segments. Murch and I are joined this week by Matt Morehouse. Hey, Matt. + +**Matt Morehouse**: Hey, folks. + +**Mike Schmidt**: And Jesse Posner. Jesse, how are you doing? + +**Jesse Posner**: Good, happy to be here. + +**Mike Schmidt**: We're lucky to have both of you to help us cover the news this +week. We have three news items that you both are involved with. + +_LND gossip filter DoS vulnerability_ + +The first one titled, "LND gossip filter DoS vulnerability". Matt, you posted +to the Delving-Bitcoin Forum about a disclosure of a vulnerability in LND around +gossiping. What exactly did you find? + +**Matt Morehouse**: So, this vulnerability affects LND versions 0.18.2 and +below, and it basically causes the LND node to run out of memory and either +crash or hang. The vulnerability itself is pretty easy to understand. In the +LN protocol, there's this message called the 'gossip timestamp filter', and this +message is something you send to your peers to basically tell them you want to +receive gossip within a certain range of timestamps. And this could be gossip +that's received in the future and you want them to forward it to you, or it +could be gossip that they received at some point in the past and you're asking +them to load that gossip from their database and send it to you. Now, this is +fundamentally an asymmetrical interaction. So, the gossip timestamp filter is a +40-byte message, but the amount of gossip you're requesting from the peer could +be several megabytes. And so, it's very critical that LN implementations are +careful in how they handle this, so that they don't use too many resources. + +Unfortunately, LND was not careful in this regard, and they did just the +simplest way of handling this message you could think of. They loaded all the +requests of gossip into memory at the same time, and then attempted to send it +all immediately to the peer. And what this meant is, it was very trivial for an +attacker to just send a whole bunch of gossip timestamp filters and cause LND to +run out of memory. And that's the entire vulnerability. LND 0.18.3 included a +mitigation for this, where they basically limited the global number of gossip +timestamp filters that they would service at the same time. They didn't really +fix any of the large memory usage per request, but this global limit is enough +to prevent LND from running out of the memory. + +**Mike Schmidt**: Did I see that there was another attempted mitigation as well? + +**Matt Morehouse**: Yeah, so the first attempt at fixing this, it could be +easily bypassed. So, it was a per-peer limit originally. But unfortunately, +it's very easy for an attacker to imitate different peers by just setting a +different node ID when they connect to you. And so, this mitigation could be +easily bypassed just by changing your node ID on each connection attempt. + +**Mike Schmidt**: Because it doesn't have to be a channel peer that is +requesting this information, right? So, you can spawn up as many of these as +you want. + +**Matt Morehouse**: Exactly. You don't have to open a channel at all. The +attack is zero cost. + +**Mike Schmidt**: Okay, so previously there was no limit on rate-limiting the +number of these requests, or the potential, I guess, size that you would be +returning or amount of work that would need to be done per each request, but now +there is a limit on the number of requests, is that right? + +**Matt Morehouse**: Yeah, so there's still no rate-limiting on how fast they +will send the messages to you, but there is a limit to how many gossip timestamp +filter requests they're going to respond to at any given time. So, once that +limit is hit, then any other gossip timestamp filter messages just get queued, +and they don't respond to them until some point in the future when they have +more bandwidth. + +**Mike Schmidt**: And I saw that in your write-up, you also noted that you set +up a test for this. How long did it take for you to crash the LND node in your +testing, and maybe what was the size of that machine? + +**Matt Morehouse**: Yeah, so I set up a small machine with 8 GB of RAM, 2 GB of +swap, and the RAM pretty much ran out immediately once I started the attack. +And once that happened, it started swapping, and the LND node became basically +inoperable, it was just super-super-slow. I wouldn't feel safe if my node was +swapping like that, because there's no guarantee it's going to respond to revoke +commitment transactions being mined, or things like that, in a timely manner. +But I kept doing the attack and it took two hours after swapping started for the +process to actually be killed by the operating system. + +**Mike Schmidt**: Was there an interesting story in how you found this +particular vulnerability? + +**Matt Morehouse**: Not really. So, I was just looking at the code and I didn't +have to look very hard to find this. I don't think this vulnerability is very +difficult for people to understand or even notice. I think any experienced +engineer would be able to spot this. So, that makes me extra concerned about +code quality in general. If I wasn't even really trying to find a vulnerability +here and I saw it, that's kind of scary to me. + +**Mike Schmidt**: Well, I guess the call to action for folks here is if you're +running an older version affected by this vulnerability, you should be +upgrading. And any other takeaways you think here, Matt? + +**Matt Morehouse**: I keep saying this, but I think there needs to be more +investment in security for LN in general. So, this vulnerability was introduced +seven years ago and I think back then, LN was kind of in its infancy. And I +think it's totally understandable that people were trying to just get something +shipped that worked. But I think this sort of mindset has carried over even +till today. And I'd really like to see more security development or +security-focused development, because things like this could totally destroy the +reputation of the LN. I mean, if you think about it, this vulnerability +affected all LND nodes. LND is 90%-plus of public routing nodes on the LN +today. And if an attacker had exploited this, the whole network could have been +brought to its knees basically, and no one would have been able to route +payments and people's funds would have been at risk, people could have had money +stolen from them because their nodes weren't online to punish revoke commitment +transactions. And you know, what does this do to a user who's trying LN for the +first time, and then all of a sudden, they can't make any payments or they lost +funds somehow, or whatever? They're never going to want to come back to LN +again. + +This is my major concern, is that eventually something like this is going to +happen and what's the impact going to be on Lightning, what's the impact going +to be on Bitcoin adoption as a whole? I'd really like to see all the +implementations investing in more security type work and more careful +engineering of how they develop these new features and things like that. It's +definitely slower development to do, but I think this is the right way to go +long term. And if your company is building their entire business model around +Lightning, some large-scale attack like this could really, really hurt your +business. And so, you should be considering getting ahead of this and trying to +prevent major security catastrophes like this from happening. + +**Mike Schmidt**: We've had you on before, Matt, as well as other disclosure +individuals, who have gone through what it would take to execute a particular +exploit. And based on what you've said here, this one could have a high impact, +but also fairly easy to execute, right? You can imagine just a little script +that could do something like this across the network. So, yeah, I share your +concerns and I guess in second, that encouragement of bolstering Lightning +implementation security. Murch, any thoughts? + +**Mark Erhardt**: Yeah, maybe a little earlier would have fit better, but I was +trying to understand the vulnerability a little better. So, the messages that +were being repeated were the gossip messages, and you could just basically +duplicate the same messages, or were you asking for updates more often than you +needed? Could you explain in a little more detail how the attack worked, +assuming that it's safe to explain in detail, because it's been fixed for a year +now? + +**Matt Morehouse**: Yeah so this gossip timestamp filter message, it sounds like +it's just a filter like, "Only send me this gossip that you get in the future". +There's actually a second purpose to it where you can, if you set a timestamp +sometime in the past, then you're asking the node to load all its gossip from +its database that's newer than that timestamp and send it to you, and that's +where the vulnerability here is, is you request a whole bunch of gossip all at +once. And if the node just blindly responds to that and sends all that gossip +to you, now they're using a ton of memory and a ton of bandwidth to do that. +So, this could be easily exploited for LND by just sending a whole bunch of +these gossip timestamp filters and LND would load all the gossip every single +time and run out of memory. + +**Mark Erhardt**: I see. So, the malicious attacker would simply ask, "Send me +all the gossip", and it could ask for the same gossip multiple times, there's no +deduplication or anything; like, there could be ten of these queued from the +same peer? + +**Matt Morehouse**: Yeah, absolutely. So, the spec actually says that a new +gossip timestamp filter that comes in should replace any previous ones, but LND, +to this day, has not implemented that. And, well, they used to handle all of +them at the same time, and now they will handle the first five of them and then +they will start queuing them after that. But even if LND did do this, like the +spec suggests, it still doesn't fix the vulnerability because you can have many +different peers all requesting gossip. And they don't replace each other's +filters, they just replace their own. So, that also ties into your first +attempt at the mitigation was at this per-peer level, but you could bypass it by +just pretending to be many different peers. + +**Mark Erhardt**: So, it sounds like even if you do queue it, it would be still +a bandwidth-wasting attack that exists here? + +**Matt Morehouse**: Yes, and so actually it's funny you bring that up, because +that's something LND is dealing with right now, kind of the aftereffects of +fixing it this way. So, they recently implemented some rate limits that were +maybe a little overly conservative. And then just by the natural traffic, where +people were requesting this sort of historical gossip data, they started hitting +those rate limits and then peers were disconnecting, because they thought the +connection was idle, and they were running into issues this way. And if they +had fixed this originally by instead of just limiting how many gossip timestamp +filters they handle at once, if instead they had fixed this by loading less +gossip into memory at a time and just sending it every now and then and kind of +trickling the gossip that way, I think they probably would have avoided the +issues they're seeing now. It's hard to know for sure but I think that's the +main source of their pain right now that they're dealing with, is they're +spending way too much outlying bandwidth on gossip as a result of the gossip +timestamp filter handling. + +**Mike Schmidt**: Matt, one of the things that comes to my mind is, okay, this +is one implementation that is handling this poorly and in the spec maybe doesn't +even address this type of concern. So, did you try the other implementations? + +**Matt Morehouse**: I've looked at the other implementations and I don't think +any of them have this vulnerability. They're all more careful about how they +handle gossip timestamp filter. They do this more of a trickle of gossip +instead of just sending it all at once, and none of them just load it all into +memory. They always load a few messages at a time and then when they have +outgoing bandwidth available, they'll send those messages to the peer, which I +think is the intended way to implement this. I don't think normally you would +respond to the gossip. The idea behind gossip is not that you send all the +gossip at once, it's that over time you converge on a full understanding of the +network just by collecting gossip here and there, and so on. I think, yeah, it +only seems to be affecting LND because of the way that they handle this message. + +**Mike Schmidt**: Got it. Well, Matt, thank you for joining us. We appreciate +your time in explaining this item for us. + +**Matt Morehouse**: Absolutely, thanks for having me, guys. + +_Chain code withholding for multisig scripts_ + +**Mike Schmidt**: Next item from the news section titled, "Chain code +withholding for multisig scripts". Jesse, you and Jurvis have been working on +research to improve privacy and security of collaborative custody. You can take +this any way you want, but I thought maybe one way to start would be you can +explain what are the existing issues with privacy and security in today's +setups? + +**Jesse Posner**: Yeah, absolutely. So, I think one thing that is really scary +for anybody who is a self-custody user is the idea of your balance and your home +address, that data being leaked, because that could make you a target at your +home. And when we look at how the collaborative custodians operate right now, +in most instances, they have that data in their databases. So, they know +people's billing addresses, they might know their shipping addresses, they might +know information about their emergency contacts, and they also know their +customer balances. And in some cases, this is more deliberate because they want +to know this information for analytics or customer support, so they'll have the +entire descriptor that they just store outright. But let's say a collaborative +custodian doesn't want to know its customer's balances. There's not a +straightforward way to not have that information by virtue of the fact that they +hold one of the keys in a multisig. + +So, when we look at how multisig works outside of taproot, whenever you spend a +multisig UTXO, you reveal all the public keys that are involved in the multisig, +even the ones that aren't participating. So, a collaborative custodian, if they +wanted to find their customer transactions, they could use their xpub to derive +child keys and then scan the blockchain and look for any of their child public +keys. If they show up in the blockchain, they would know that's a customer +transaction, even if they weren't involved in signing. So, that's kind of the +core issue. And then, there's an additional issue, which is what if we wanted +to keep transaction data private even when the collaborative custodian is +signing, which is an even higher bar for privacy? So, those were the two main +motivations behind this idea. And then in the course of it, we realized there's +some cool security benefits in addition to the privacy benefits as well. + +**Mike Schmidt**: Just so I'm clear, the privacy part makes sense. We wrote +'security' as well, but that seems like it's a physical security thing more than +any sort of cryptographical or otherwise security, right? + +**Jesse Posner**: Actually, there is sort of a cryptography security component +as well. And so, with encryption, we have this idea of forward and future +secrecy. Like, this is something, for example, that Signal provides, where if +one of the secrets is leaked in a Signal chat, it only decrypts a single +message. It can't decrypt any of the past messages and it can't decrypt any of +the future messages. And so, we end up getting a similar attribute with chain +code delegation, where if a collaborative custodian's private key is leaked, if +they don't have a chain code, that private key is actually not usable to spend +any UTXOs, because not only do you need the private key, you need to know the +public keys you need to sign for, and you need to know how to tweak the private +key to sign for those child public keys. So, let's say a custodian learns a +BIP32 tweak or ten BIP32 tweaks, and so their private key and some set of tweaks +is leaked simultaneously. Then, the only UTXOs that could be signed for with +that data is the UTXOs that are tied to those tweaks. And any UTXOs that were +created before or after would not be spendable. So, we noticed this as a cool +benefit of this technique, even though it wasn't part of the original +motivation. + +**Mike Schmidt**: I think it might be helpful for people if we remind everybody +what the chain code is and not the office in New York. + +**Jesse Posner**: Yeah, absolutely. So, you have this thing called an xpub, +which is really useful, because with a single static data structure, you can +derive many, many public keys. And of course, in Bitcoin, we're always trying +to avoid address reuse. And so, this makes it really easy for a wallet to +generate many, many addresses or many, many keys with a single piece of public +data or private data. There's an xpriv and xpub, one for the private keys, one +for the public keys. So, what the xpub consists of is you have a standard +public key and then you have this additional 32 bytes of random data that we +call the chain code. And basically, if you concatenate those two things, you +have an xpub. And the public key is your kind of root of the system. And then +the chain code gives you a method to tweak that public key and derive child keys +with it. And so, the problem is if a collaborative custodian has an xpub, they +can derive the whole key tree and they can see all these different child keys. +But if they only have half of the xpub, they only have the public key part and +not the chain code part, they can sign, but they can't derive child public key, +and so they wouldn't be able to identify them on the blockchain. And if we +combine that with blind signing, they wouldn't even be able to identify +signatures that they were involved with as well. + +**Mike Schmidt**: Maybe a quick sidebar, I know we're going to talk about +quantum in a second, but one of the concerns with quantum is that you've shared +your xpub with services or providers that may now have the public keys in their +database or wherever, and if they are malicious or get hacked, that those public +keys that you thought were not publicly available, are. Does this scheme also +help with that? + +**Jesse Posner**: Yeah, I mean, it makes it so that it's less likely those +public keys are going to leak, because they're not sitting in a third-party +database. And so, yeah, I mean, even if you're not engaging in address reuse, +even if you're using a hashed key-based address scheme, if your xpub leaks or +any of your public keys leak, then that puts those UTXOs at risk for a quantum +attack. So, the less exposure of that data, the less likely that it will leak. +And so, one way we can do this is with taproot. If we want the kind of weaker +privacy property, which is basically if I don't use the collaborative custodian +for signing, because a lot of the shape of the systems oftentimes is that maybe +you have, let's say, a 2-of-3 where a third key is held with a collaborative +custodian, and that's only used for emergencies or for recovery purposes. But +most of the time, you're just using your own keys. And so, a nice property we +would have is in the default case where I'm not using the collaborative +custodians key, I sign with my own keys and they won't be able to recognize +those transactions on the blockchain. And only in the rare case would I have to +use the collaborative custodians key and then they would only learn about that +transaction. Although in practice, if you're using it for recovery, it's +probably going to be a sweep transaction and they're probably going to learn +your whole UTXO set in the process, wouldn't necessarily be persistent in their +database. + +But in general, it'd be nice to have this property where I can sign in a way +that's more private, if available, and then only in emergencies would I sign in +a way that's less private. And we could do that with this chain code delegation +technique, or you can do that with taproot. Because with taproot, when you use +a given spending path, it doesn't reveal all the different spending paths, all +the different scripts. It only reveals the one that you used. So, that's +another way of getting this property. However, if in addition we want to have +it so that even the custodian doesn't learn the transactions that they are +involved with, then taproot alone is not sufficient; we would still need to use +this technique. And so, this would have to be layered on with chain-code +delegation, so they don't see their own public keys, and a blind schnorr +signature, so they can't actually recognize the nonce commitment or the +signature on chain or the message that's being signed. + +Then, there's an additional technique, called predicate blind signatures, where +if a custodian needs to enforce a policy, maybe like a time delay or a screening +for like OFAC'd addresses or something like that, you could attach a +zero-knowledge proof (ZKP) that asserts that the policy predicates have passed, +so they can verify their policies. They don't learn the transaction data, they +don't learn the balances. And so, even with taproot, if you want that kind of +full privacy case, this technique is still quite useful. + +**Mark Erhardt**: Yeah, that's what I was going to throw in. With taproot, +you'd still have to decouple or split up the descriptor. This is pretty cool. +So, yes, we never want address reuse. Address reuse has only downsides +essentially, except for a tiny little bit of convenience in some cases. +Especially in the context of quantum, if we're going to talk about that soon, +address reuse actually makes your coins vulnerable for long-range attacks, +because if your public key is on the chain, which is the case only after +spending for many of the existing output types, for some it's also the case for +all as soon as you're being paid; but with address reuse, if you reuse a +hash-based address, your public key is on the chain and a hypothetical quantum +attacker would be able to attack your public key and decrypt the private key +from that quantum decrypt. + +So, I really like the idea of splitting up the chain code from the public key, +making the xpub two separate things. The downside, of course, is many of the +services that you show usually show you the balance that you have onchain. So, +it would also require additional work from the service provider that they find +ways in which you can retrieve your balances from the service without revealing +to the service what your balances are. So, that might be possible with some +client-side block filtering but it would require more bandwidth, more +computation on the side of the client, and it also would require that the backup +of the output descriptor that is being used happens client side, or maybe an +encrypted backup is left with the service provider. So, as so often, the +trade-off for more security and more privacy is less convenient, a more +complicated scheme, and a little more overhead for the service provider as well. +I think it's a great idea, but as usual, there's trade-offs. + +**Jesse Posner**: Yeah, those are absolutely some great caveats to point out and +are absolutely valid. + +**Mike Schmidt**: Jesse, you mentioned in your write-up, well, we talked about +the potential spending paths in tapscript, and you also mentioned in your +write-up the use of MPC, or you also mentioned FROST as a potential solution to +the problem. Can you tell us why those aren't great ideas, or are they? + +**Jesse Posner**: They are, yeah. Nick Farrell has a great post about how FROST +can similarly kind of solve this privacy problem for the collaborative +custodians. And it's also a similar technique, where the chain code is not +known by the collaborative custodian. In an MPC world, so in a non-MPC +multisig, each signer has their own xpub, has their own chain code for their set +of keys. But in a FROST world, there's a single chain code because in a FROST +world, there's only one public key. There's multiple signers, but just a single +public key, and the private key is split between them all. So, that also means +there's only one chain code. So, it kind of more naturally lends itself to the +idea, well, maybe not all the signers need to know the chain code. And as part +of the FROST protocol, and also I think, yeah, the same technique is used in +MuSig, due to the linearity of the schnorr signature, the BIP32 tweak can be +added at the end during the aggregation phase. And so, the signers themselves, +the challenge hashes they use have to have the full public key for the child key +that they're signing for. But when they use their private key or their share of +a private key, they don't have to sign with the BIP32 tweak itself, they can +just sign with the root private key. And then, somebody else can add the tweak +into the signature due to the linearity of schnorr at the end of the process. + +So, that is why with FROST, or with MuSig, it does this nicely where you can +have some signer that doesn't know the chain code. They're given a challenge +hash to sign or they're told what the public key is when they sign, and then +their tweak is added after the fact. And if they weren't involved in the +signature, because they don't have the chain code, they wouldn't be able to +recognize it on chain. + +**Mark Erhardt**: May I put you on the spot? I was just wondering. So, one of +the value-adds of having a distributed signing setup is that the other parties +could be configured to only sign blindly or for small amounts. If the +participants no longer learn what amounts are flowing because they're blinded, +you are essentially making a request from your co-signer that they sign via your +device, and it may be the same device that also controls the original key. Now, +you're just making a request to a service, they blindly sign whatever you send +them. Aren't you reducing your security from 2-of-3 to where one of them is +conditional and to 1-of-3? + +**Jesse Posner**: Yeah, I mean I don't know if it's a full reduction to 1-of-3 +because they might be able to authenticate who you are. I mean, it's definitely +a weakening, there's no doubt about that, and there's a substantial security +issue if they'll just sign anything that's given to them. And so, there's two +different ways to deal with that. One is that when you do ask the signer to +sign, they don't do it blindly. You give them the transaction, they can verify +the details, and if they're not involved, they wouldn't be able to recognize +these transactions onchain. But when they are involved, then they do learn the +data. And so, that's one approach, or the other approach is this ZKP approach, +where whatever the signer needs to know is asserted with a ZKP, and that way +they can parse their policies. + +Now, the thing about ZKPs is generating them with a mobile client is not +necessarily going to be practical, could take a couple of minutes and drain a +bunch of battery life, and all of that. They're getting more efficient over +time, and so that might at some point become, at least with the kind of general +purpose ZK proving systems, like a SNARK or a STARK, if there are specific +policies where you don't need a general-purpose ZK, it could potentially be made +much more efficient and be generated on a client. But the kind of easy mode is +to use a general-purpose system, where you can assert any arbitrary statement +about the transaction whatsoever. One thing that really also makes it difficult +is you're asserting a statement about the preimage to a hash. And so, usually +you'd need the more heavy machinery of like a SNARK in order to make statements +about preimages as they relate to hashes. So, it works great if you have a +desktop client and a more powerful CPU. If you want to do this on a mobile +phone, then you could run into performance issues. + +**Mark Erhardt**: Right. That's some good thoughts right there. So, it sounds +like something that would be great. How do we incentivize service providers to +actually adopt this sort of scheme, because if we don't demand it, I am not sure +it's on top of their to-do list? + +**Jesse Posner**: Yeah. I mean, I think customers asking for it. I think +hopefully we're going to see a collaborative custodian introduce this, because +it could be a good competitive advantage to say, "Hey, why don't you use our +service instead of the other person's service, because you're going to be a lot +safer?" And I think wrench attacks are some of the scariest things that we have +to deal with as bitcoiners. So, from a customer perspective, I'm going to want +to use a service that takes that attack seriously and doesn't put myself and my +family at risk to use the service. And so, if we can even just get one company +to come out and use this technique, that's really going to encourage everybody +else to get on board, because I think a lot of customers are going to value this +feature quite highly. + +**Mark Erhardt**: Yeah, I think so too. Sorry, Mike, go ahead. + +**Mike Schmidt**: Jesse, we should give you an opportunity, if you want to, to +talk about what you're working on and if it's related to this at all. + +**Jesse Posner**: Yeah, thank you. Yeah, me and my co-founder, Erik Cason, we +started a company a few months ago called Vora, where we're focused on a lot of +the problems we've seen with self-custody, including related to wrench attacks +or government seizure or key loss, which are basically the three main risks that +you think about as a self-custody user. And so, we are building an integrated +hardware wallet, full node and home security system all in a single package, and +we've got some cool cryptography and recovery techniques and hardware +innovations. But one of the main things we're focused on is, we are going to +deliver this full-stack chain-code delegation, blind schnorr signatures, and +predicate blind signing with the ZKPs. And because our integrated node and +hardware wallet is a desktop-class server with a high-end CPU, we can generate +the ZKPs, we aren't dealing with mobile clients. And because there's a full +node, because this is the other place where data can leak, even if you do all of +this stuff, if you're querying your blockchain data from a third party and +you're not running your own full node, that's another place where your balance +information and your transaction information can leak. + +So, to really get the full safety as a self-custody user, you need this stack of +you need your own node, and if you're dealing with a collaborative custodian, +you need the chain-code delegation, blind signing, and all of that stuff +together. And so, we're working hard to provide that and to ship something to +customers so that they can feel safe even when they're securing high-value +amounts of bitcoin. + +**Mike Schmidt**: Very cool, Jesse. Anything else you want to say on this item, +either Murch or Jesse, before we move to the next Jesse item? Okay. + +**Jesse Posner**: Yeah, I think that covers it. + +_Research indicates common Bitcoin primitives are compatible with +quantum-resistant signature algorithms_ + +**Mike Schmidt**: Great. Third news item this week, "Research indicates common +Bitcoin primitives are compatible with quantum-resistant signature algorithms". +Jesse, we have you again for this news item. There's been a lot of chatter +recently about quantum and Bitcoin. Some of the chatter includes which +post-quantum signature scheme Bitcoin might move to if quantum computers +appeared. With some of these hash-based schemes, it seems like we might lose a +lot of the niceties that we might be used to in wallets, like HD wallets, MuSig, +FROST, etc. But you've dug into some of the research and at least for some of +the lattice-based post-quantum schemes, maybe we can keep some of those goodies. + +**Jesse Posner**: Yeah, exactly. So, I was recently at the Bitcoin Quantum +Summit at Presidio Bitcoin and encourage folks to check out the videos. There's +a lot of great talks. But it really got me thinking about post-quantum +cryptography. And one of the things that I heard a lot of people lamenting +about it is, "Hey, if we have to go to this post-quantum world, we're going to +have to give up some of our favorite techniques in Bitcoin. We're going to have +to give up our BIP32 key tweaks and our HD wallets, we're going to have to give +up silent payments, we're going to have to let go of adapter signatures, we're +going to have to let go of MuSig, FROST. And all of these techniques kind of +use the same sort of tricks, which is with ECC public keys, we can tweak public +keys and that ends up having a relationship to the corresponding private key, +because there's a mathematical geometric structure that is intact, even when +you're modifying public keys, that that translates down to the private key +level. And so, this is this beautiful, powerful technique that we're able to +use for all these different tools that have become fundamental to Bitcoin. So, +we do not want to have to let these go and give them up. + +So, I did a little bit of digging. I'm not an expert in post-quantum +cryptography. I'd like to become one at some point, but I'm just starting to +establish, to zoom out and just kind of think about in principle or in theory, +is there a way that we're going to be able to bring these techniques over into a +post-quantum world? And as you mentioned, Mike, there's a couple of different +post-quantum proposals on the table. So, there's BIP360, which is proposing a +post-quantum address scheme. And in the BIP, it identifies two of what they +believe are the most promising post-quantum signature types. And one of them is +a hash-based technique called SPHINCS. And then, the other is this MLDSA that +uses lattices for its post-quantum cryptography. And with the hash-based +technique, it's going to be very difficult, if not impossible, to have similar +types of features with those signature types, because hashes destroy the +mathematical structure of what they're hashing. And so, if you modify a hash, +it's not really going to have any relationship back to the preimage of the hash. + +However, lattices do have a mathematical structure that is preserved. And with +lattice cryptography, we have these random points in this high-dimensional +field, and then you're trying to find these very convoluted vector paths to the +point. So, the point is kind of like the public key, and the vector path is +kind of like the private key. And so, if you tweak the public key, you do get a +change to the underlying path that you get to the new key in a proportional way. +And so, it felt like, just looking at it from a very high level, that we have +enough structure here that we should be able to have some analogous techniques. +And so, I started doing some digging to see, are there any papers out there that +have explored this? And it turns out it's a very hot area of research for +post-quantum cryptographers, and there's been a number of papers. There's a +paper that specifically introduces an HD wallet, BIP32-style scheme built on +lattices, and has stealth addresses. So, it has silent-payment-style public +identifiers where a sender can derive an address that is only known to them and +the receiver. And then, there's some other papers that have MuSig-style key +aggregation. And then, there's even a paper that does FROST-style threshold +signing. + +We're still at the early stages of this research, and if the mathematicians are +already discovering these techniques, I think it's very promising that we're +going to have more discoveries here that will have better efficiencies, improved +properties, and that the cryptographers of Bitcoin should not be discouraged by +post-quantum, that there's still going to be a lot of room for creativity and +bringing in all the kinds of techniques that we know and love. So, that was the +main purpose of this post, is to start a conversation around that. + +**Mark Erhardt**: All right, I want to throw a little cold water. Yes, sounds +good. So, BIP360 was recently overhauled. The BIP360 proposal now is a little +condensed to proposing a new output type that is very similar to taproot +outputs, but does not allow a keypath spend. So, by having only a scriptpath +spend component that is hash-based, it would be immune to long-range attacks, +unless of course they are reused. Don't reuse addresses, please. They do +discuss a little bit two different types of post-quantum safe signature schemes, +however they no longer propose one. They are working currently on a second BIP +that would make a recommendation in this regard. Now, I am not at all a +cryptographer but my understanding is there are two different schemes, because +they want to have a fallback in case one of them gets broken. + +One of them is based on lattices. So, that would be potentially, down the road, +compatible with all the good things that Jesse has described to us. The big +issue there is lattice cryptography is based on new cryptographic assumptions +that are fairly young. There have been some breakthroughs in how to break them. +This is generally still pretty nascent cryptography. There are now some +standards approved by NIST, but in the first round of those standard +submissions, some of these proposals were broken on the first weekend. So, even +if they are currently approved, there might be some of them that still get +broken. The nice advantage of the lattice-based cryptography, as far as I +understand, is that they can be way more performant and they can use way smaller +signature and public-key sizes. So, I don't have the numbers on top of my head, +but I think it was Falcon that is interesting at this point. And it's barely +one-digit multiple in size from current output types; whereas the hash-based +signatures are more like factor-100 bigger, or maybe let's say 50. + +But the other fallback is based on hashes. So, I think that was SPHINCS. You +correct me, Jesse, you know all this better. But these would be way, way bigger +and they would be more expensive to calculate. However, they make fewer +cryptographic assumptions, up to none, compared to what we have already. So, +the downside there of course would be that all of that would not be compatible +with the goodies that Jesse just described. So, I would imagine that it might +be difficult to have a scheme that's based on not reusing addresses, where I +guess you could have a construction where you have a merkle tree with script +leaves, where one has the Falcon signature that is performant that might be +based on MuSig or based on FROST or other goodies with derived addresses, no +address reuse. But then, the second leaf would always be the same two keys and +both of them would be ginormous and both people have to sign with like a 4-kB +signature in order to make that transaction work. So, yes, but there is some +caveats there. + +Again, I was also at the Quantum Summit a couple weeks ago, there is some debate +about how quickly this is impending upon us. I know nothing about quantum +computers, but from what the experts said, it sounded more like we'll find out +in the next five years to me. We'll know more in the next five years how +quickly it's coming, not it's going to be here in five years, but what do I +know? And about the whole cryptography thing, since it is such a hot topic +right now for cryptographers, for people that have business in cryptocurrencies, +and so forth, I think the speed at which stuff is being discovered is only +accelerating. So, hopefully in the next five years, as we are watching this, +unless other people are convinced to do otherwise and do more than I will be +doing in the next five years, they will hopefully have better schemes by then, +hopefully schemes that are compatible with these good derivation paths and key +aggregation schemes and threshold signature schemes, and we'll have a better +idea of what we want to do. + +Regardless of that, I would like to invite all of you to actually read BIP360 +and other proposals that are being brought up, because this is a conversation +that is happening right now. And even if we're not going to have to react +urgently to a cryptographically-relevant quantum computer in the next five +years, one thing that we really need to debate is, if we had to, what would be +our proposal that we have in the drawer that we can get going in the next six +months, and what needs to happen with the other coins that don't move, because +there's millions of coins, between 4 and 8 million coins probably lost, so these +will not move. A lot of them are on P2PK output types, and a bunch of them are +on reused addresses. So, for these coins that do not move, what is the +appropriate handling of that? Should they be frozen and based on something like +the Life Raft proposal from the Quantum Summit recoverable, that might only work +for a subset of keys because some of them might not have any scriptpath spending +or might not be derived from a BIP32 style address? Or should they just be up +for grabs for anyone, because quantum computers are great for humanity and the +Bitcoin Network wants to subsidize that, even if there is no benefit to the +Bitcoin community to invite people to misappropriate funds otherwise? + +That's the debate that we need to be having in the next couple of years. It's +been ongoing on Delving, on the mailing list. You might have seen some podcasts +or blogposts that also dip their toes into that, but that might be a topic you +want to also look at. + +**Mike Schmidt**: Jesse, from what you've said, I think I know the answer, but +you mentioned all this innovation and schemes that are being built on lattices. +I suppose that the amount of innovation on the hash-based schemes is zero +because, like you said, the whole point of the hash is that it is obfuscating +the underlying information. And so, there's no research being done there and in +theory, nothing can be done on that front, or…? + +**Jesse Posner**: Yeah, I think I think this SPHINCS scheme is kind of old, or +at least based on some older techniques, and is a little bit more settled. But +there may be some MPC tricks that we can do with hashes, and there was a little +bit of discussion at the summit about that. But you could potentially have +multiple parties contributing to building a hash where none of them knows the +full preimage, and they're using some kind of MPC to collaboratively construct +these things. So, I think that's basically the only opportunity we'd have to be +able to kind of extend the techniques we apply to the SPHINCS-style signature. +I don't think we'd get the full array of everything we want to be able to do, +but we would be able to get some kind of multisig, multiparty schemes that +probably could be done with MPC. + +**Mike Schmidt**: Anything else to say on this topic, Jesse? + +**Jesse Posner**: Yeah, I mean I just think it's a little bit risky as a +mathematician or a cryptographer to put too much time into this, because like +Murch said, we don't even know if it's going to be viable. One thing that is +unfortunate or just a feature of these systems is that we rely on hard +cryptographic problems and we don't have proofs that the problems are hard. All +we have is time that nobody's come up with an efficient solution within some +segment of time. And if it hasn't been done in 10 years or 20 years, we build +confidence that it can't be done. So, there's no efficient solution that's been +found to the lattice hard problems, but not that much time has been built in +yet. And one day we could wake up and somebody's found an efficient solution, +not only with a quantum computer, but even with a classical computer, there +could be efficient solutions lurking out there. + +So, you could spend tons and tons of time figuring out BIP32 and FROST for +lattices, and then all that work disappears. But it's also a great opportunity +to do something new and innovative and it very well might hold up, and it very +well might become a critical part of the future of Bitcoin. And if you're a +cryptographer that's just getting maybe a little bit bored of elliptic curves +and schnorr signatures and ECDSA, it's a whole new world of mathematics that +lattices opens up with a lot of fun puzzles and things to think about. And I +just think for me, the main takeaway is let's not get discouraged about the +post-quantum future. Let's stay excited, let's stay inspired, let's stay +creative about what might be possible, even if we have to move to that world. +Because there's going to continue to be innovation and new ideas, and we're +going to continue to be able to build great things with Bitcoin, and we +shouldn't think of that as just sort of the end of the road. And so, that's my +main takeaway. + +**Mike Schmidt**: Nice way to wrap up, Jesse. Thank you for your time on both +of these news items. We appreciate you joining us. + +**Jesse Posner**: Yeah, this this was fun. Thanks for having me. + +**Mike Schmidt**: Cheers. + +**Jesse Posner**: See you. + +**Mike Schmidt**: Moving on to the monthly segment we have on Q&A from the Stack +Exchange. We have just three this month. Sorry, Murch. + +**Mark Erhardt**: First, let me jump in right there. People, you've got to feed +the beast. All of you are just talking to AIs now in order to learn about +Bitcoin stuff. Sure, there is the mailing list and maybe, for example, the +transcripts from this podcast that might get consumed and used for training +eventually. But I'm low-level sure that also all of Stack Exchange was consumed +to train all of your LLMs. So, for all the new topics, if you stop asking +questions to Stack Exchange, our LLMs will stop learning. So, feed the beast! + +_How does Bitcoin Core handle reorgs larger than 10 blocks?_ + +**Mike Schmidt**: Well, it's funny you mentioned that because this first Stack +Exchange question was, "How does Bitcoin Core handle reorgs larger than 10 +blocks? And TheCharlatan answered and pointed to a section of the Bitcoin Core +code that handles reorganizations and has this maximum of 10 blocks' worth of +transactions that are re-added to the mempool. But I wanted to dig deeper, and +I did ask the AIs this one, and they had no idea what the 10-block consideration +would be in Bitcoin Core, when I was even giving it more and more hints about +re-adding transactions to the mempool. So, I should actually follow up to that +question or ask a separate question but maybe, Murch, you know the answer. +Let's say that there's a 15-block reorg, so 10 blocks' worth of transactions are +going to be re-added. + +**Mark Erhardt**: I think I just noticed this this morning, so it's not fixed +yet, but I think there's a misunderstanding here. I believe that transactions +are only added back if the reorg is not more than 10 blocks. If the reorg is +more than 10 blocks, no transactions are added back to the mempool, is my +understanding. I will double-check this later, I might be wrong on this one. +So, the concern I think probably is, you can fit about 6,000 transactions into a +block I think, or maybe I'm off. Usually there are like 3,500 transactions per +block or so. And so, if you go back 10 blocks, you'll add back something like +35,000 transactions to the mempool. And I think the concern is that you would +just basically flush out all the unconfirmed transactions that are still +waiting. So, when you're reorging, you are reorging to a chain that has more +weight, right? + +If you're reorging 10 blocks, you're reorging to a chain that probably has 11 +blocks. If the other chain also includes transactions, most likely almost all +of these transactions will also be confirmed in the other chain tip. Now, the +easiest way to verify that would be by putting them in the mempool, by using +this already verified script and so on, but we would lose all of our unconfirmed +transactions, they would get flushed out. I think with 35,000 transactions, +you'd probably eliminate a third or half of the mempool on default settings that +would just get dropped on the floor. + +So, I think the trade-off here is if you are reorging more, instead of putting +it back in the mempool, you process those blocks in full and get all the data +for the blocks from peers, and that way maintain the content of your mempool. +But also again, I'm mostly speculating here. I know speculation shouldn't be +spoken about. + +**Mike Schmidt**: You should ask on the Stack Exchange, Murch, or ask and +answer. + +**Mark Erhardt**: Well, first I'd have to find out what the actual answer is. +But that seems to be the most likely concern. You'd have all this data churn in +your memory and then most of it would be confirmed immediately again, and then +you'd forget about all these other unconfirmed transactions that are still +waiting. + +_Advantages of a signing device over an encrypted drive?_ + +**Mike Schmidt**: Yeah, that makes sense. I guess, stay tuned, listeners, for +next month's Stack Exchange where we might update the answer here. Second +question from the Stack Exchange, "Advantages of a signing device over an +encrypted drive?" This person was wondering, "Hey, I have an encrypted drive +that achieves the same thing as these fancy Bitcoin hardware signing devices or +hardware wallets". And RedGrittyBrick points out that one main difference +between using an encrypted drive versus a hardware wallet is that when you +unencrypt your drive, everything, all of the data is sitting there unencrypted. +And when you have a hardware signing device, they're specifically designed to +not unencrypt and have available that data for someone to steal from you. So, +this sort of key extraction or private data extraction attack is what hardware +devices are designed to help mitigate. + +**Mark Erhardt**: Right. By a hardware security module, like an HSM, or just +the signing devices that people use at home, they are deliberately built exactly +to resist this sort of vulnerability by having a very minor or small interface +that is well controlled. You can only get certain actions from the hardware +signer like, "Sign this message. Yes, it is actually me, I authenticated this +request", or whatever, and then you get a signature just for that transaction +you provided. You can usually not exfiltrate the key material at all. But if +you're just looking at an encrypted hard drive, the hard drive, when it's +mounted and decrypted so you can use it, is readable by the operating system. +So, when there's malware on the operating system, it can read that hard drive. + +_Spending a taproot output through the keypath and scriptpath?_ + +**Mike Schmidt**: Last question from the Stack Exchange, "Spending a taproot +output through the keypath and scriptpath?" And I think we talk about this a +lot on the podcast and in the newsletter. We talk about scriptpath and keypath +spends, but I just thought that this answer was a good refresher for folks +potentially. So, Antoine Poinsot answered and included a diagram from +learnmeabitcoin.com, which I thought was helpful to visualize the different +pieces of the structure when we say scriptpath, what all does that mean when we +talk about leafs, what does that look like? And there's a cool visualization +there. So, I thought we just point people to that to refresh themselves when +we're talking about scriptpath and keypath spins. + +**Mark Erhardt**: Also, a shout out to Greg. His website, learnmeabitcoin is +awesome if you want to understand how actually the output types work or key +derivation, and that sort of topics. There is even multiple level like, explain +it to a beginner, explain it advanced, explain it to an expert. Frankly, I look +up stuff there occasionally and it's amazing. + +_Libsecp256k1 v0.7.0_ + +**Mike Schmidt**: Releases and release candidates, libsecp256k1 v0.7.0. This is +noted that it's primarily a maintenance release. But along with some internal +fixes in secp, it also includes some changes that affect the public API, +including removing previously deprecated function aliases, and also some small +changes to the data types of existing fields in the API. So, check out the +release notes for any details. If you're using secp, you should probably always +be checking those release notes. Yeah, that's it on secp. + +_Bitcoin Core #32521_ + +Notable code and documentation changes, Bitcoin Core #32521. This is a PR +titled, "Policy: make pathological transactions packed with legacy sigops +non-standard". Murch, we've had Antoine on to talk about the consensus cleanup. +This appears to be related to that, but maybe you can sort of explain how this +is something that we should consider doing just before consensus cleanup, or if +there even is or is not consensus cleanup? + +**Mark Erhardt**: Right. So, when we introduced the block weight limit instead +of the block size limit, we created a single metric by which the block was +limited that was stricter than the block size limit, but in a different way in +an area that legacy nodes wouldn't consider part of the block, you were actually +allowed to write more data. Now you'd think that transactions are only limited +by block weight, and that is true for all of the output types that people +regularly use. But there's actually a second limit that makes it a +multi-dimensional problem that people usually never run into. But it is +possible to run into the sigop limit for standard transactions. Now, the sigops +are sort of a loose translation of how much cryptographical computations need to +be done to verify a transaction. Like, OP_CHECKSIG is one signature operation +in that sense. Other operations have a weight to how much they count into +sigops. So, for example, OP_CHECKMULTISIG counts as 80 sigops in this limit, +because an OP_CHECKMULTISIG could have up to 20 keys and that's expensive to +verify, and legacy outputs are multiplied by 4 generally. So, OP_CHECKMULTISIG +counts like 20, but if it appears in legacy code, it counts as 80. + +So, if there's a limit in blocks for how many sigops you're allowed to have, and +I think that, was it F2Pool ran into this limit a few years ago, when they had +blocks full of stamps. And, yeah, do you have more details on that one? + +**Mike Schmidt**: Oh, no, I didn't see it was stamps, but I was actually +bringing that up while you were talking, because I knew that people may be +familiar with the sigops limit at the terms of blocks because there was invalid +blocks from F2Pool. + +**Mark Erhardt**: I think it was a couple of years ago, or so, F2Pool mined two +blocks that were invalid because they exceeded the sigop limit for blocks while +being within the weight limit. So, just for the people that weren't aware, +there is the second limit that usually never gets hit by the most commonly used +output types, because their sigop budget is something like 40 weight units per +sigop, or whatever, and usually it is always way lower for standard output +types. The weight dominates so much that it is not a concern. If you're doing +not stupid stuff but stranger stuff like multisigs and legacy code, you can hit +this limit. + +So, back to our original question. The problem is, if we're going to make +transactions with an excessive amount of sigops invalid, as in they cannot be +mined in blocks because it will make the block invalid and the miner loses +money, miners that haven't upgraded yet and mine blocks might create invalid +blocks if someone spams these invalid transactions on the network and they +appear standard to them and they appear in the blocks that these un-upgraded +miners mine. So, we wouldn't want miners that are a little slow on the update +to build blocks that bring a bunch of un-upgraded nodes on a chain that will not +persist because it's invalid to the majority of the network; and we don't want +the miners to lose money either. So, before activating the great consensus +cleanup that invalidates these transactions for good, we would want to make them +non-standard so any miners that are at least running a few versions earlier and +maybe not the upgraded version yet, but have upgraded at some point, they would +not include these in their blocks. And the nodes would not propagate them, +would not keep them in their mempools. They would still follow a chain if a +miner mined it, but if miners don't mine it, it would be safer. + +So, this is the context that I understand this to come from. It looks to me +like it got merged before the feature freeze of 30.0. So, the next version, +Bitcoin Core 30.0 is going to have this limit and makes these pathological +transactions non-standard. So, nodes would not propagate them, nodes by default +would not include them in their blocks. This is also one of the things that +miners probably won't want to manually change and pick up transactions for +because, yeah, they are intended to go consensus-invalid eventually, so probably +don't want to collect them. + +**Mike Schmidt**: Do you know if a transaction like this has been mined on +mainnet in the mainchain? + +**Mark Erhardt**: I believe that Antoine posted a list of all the transactions +that would be in conflict with this limit, and I think it's in the PR, one sec. +No, maybe it was somewhere else, maybe it was in the mailing-list post. Yeah, +here it is. Looks like maybe 40 transactions or so. Yeah, there have been +some, but generally it doesn't look like stuff people usually do a lot. + +**Mike Schmidt**: And we want to limit this because there are certain +shenanigans that people can put together that would result in a very slow +validating transaction or block, is that the...? + +**Mark Erhardt**: Right. So, the context for the introduction of this limit is +people could create blocks that are extremely slow to validate. This would be a +big problem for people that run low computationally-capable devices like +microcomputers, Raspberry Pis and stuff like that. It would also be a concern +for other miners, where the miner of the block that is this attack block would +gain a lead time on the other miners, or maybe even crash their nodes, make them +incapable of following the best chain, and thus increase their own relative +hashrate to the total network. So, I think that Antoine has been researching +the worst possible blocks for a couple of years. His conclusion is that by +limiting the sigops, a transaction is allowed to have these attack blocks +essentially become mitigated to a degree where they are slow, but not +concerningly slow. So, this is sort of the lowest limit that he felt made it +mostly safe, but is high enough that it will never be hit by any common or +non-pathological transactions. So, just transactions that are deliberately +created to be slow to validate would even meet this limit. + +**Mike Schmidt**: We covered some of that discussion about the great consensus +cleanup soft fork and the adaptation of it that Antoine came out with back in +February, and that was Newsletter #340. So, if you're curious, some of the +details about the consensus cleanup, but also some of the thinking that went +into this particular discussion that is now being rolled out in policy, check +#340 for that. + +_Bitcoin Core #31829_ + +Next PR, Bitcoin Core #31829, a PR titled, "Improve TxOrphanage denial of +service bounds". Murch, we spoke with Gloria in Podcast #362, because this PR +happened to be highlighted in the PR Review Club, and she was kind enough to +come on. And you and her had a great conversation about all things orphanage +and all kinds of tangents we went on with her, which was great. Do you have a +tl;dr on this one? + +**Mark Erhardt**: Sure. Yeah, I guess I can. So, the bigger context is that +Gloria has been working on package relay for several years, might be almost five +now. And the idea is currently, we only propagate transactions separately by +themselves. But often, transactions may only be attractive to be included in +mempools and blocks as groups, because a child transaction might be paying for +the parent transaction and the parent transaction by itself doesn't seem +attractive at all, and previously may have poorly propagated in the network, but +with the child would have been attractive enough to be included in the next +block. In the future, it would also be amazing if we were able to propagate +multiple parents with one child, for example, or multiple children together with +one parent that overall make it attractive to include the entire group together. + +So, in this context, last release, no two releases ago, I think even, 28, +included something called the opportunistic one-parent-one-child package relay +(1p1c). So, if you got an announcement of a parent transaction and the parent +transaction was denied entry into the mempool due to a low feerate, and then +someone announced a child transaction to you and the child transaction is +obviously an orphan, and we can't even figure out the feerate of the orphan +without knowing the parent, but the parent was only denied entry to the mempool +due to a low feerate, then we would now consider these two as a package together +and see if parent and child together would be attractive to include in the +mempool. This relies on transactions being in the orphanage, which is a data +storage where we keep transactions that are missing inputs. And when we receive +such a child for which we missed the input, we would ask the relayer for the +parent transaction, and then we can do the test whether they're as attractive as +a package. + +This was not very robust necessarily in the face of antagonists, because an +antagonist could just broadcast a bunch of different transactions that are +missing inputs and churn the orphanage, and then people would lose these +transactions maybe before they hear about a parent. So, #31829 introduces a +restructuring of the limits of the orphanage. Where we previously only allowed +100 transactions, we now allow transactions per peer; and where we used to just +randomly evict one of the orphans whenever we got a new orphan, we now look at +who's been sending us the most data, are they DoSing us? The node that is +sending us the most stuff that is just sticking around and not getting +processed, those announcements are evicted first, and that should make it more +robust for this use case for opportunistic 1p1c. And, yeah, I think the overall +limit goes up a little bit. We'll use now, I think, up to, what was it? 1 MB +or so per peer. But overall, it just is a rework on how the orphanage works in +order to make it more robust against this orphanage churning attack. + +**Mike Schmidt**: Makes a lot of sense. The orphanage is being used in more use +cases now, so it should be a little bit more robust. And so, adding these +limits helps protect against attacks on that orphanage. Those are also more +likely to happen given that the orphanage is being used more now. + +_LDK #3801_ + +LDK #3801 adds to LDK's implementation of the attributable failures bolt +feature. Previously, LDK would log some information when an HTLC (Hash Time +Locked Contract) failed, for example, information about the failure, the +different positions in the attempted route, as well as how long nodes held the +HTLC. So, that set of failure information was in line with BOLTs #1044 that +specified and does specify the attribution data LN protocol feature that we've +talked about previously. But the PR this week adds those HTLC hold times, not +just to the failed payments that we'd covered previously, but also to successful +payments. And originally the idea of including this data in successful payments +was a separate BOLTs PR, but has since been combined with the original +attribution data BOLT PR. And I think we've talked about this on the show, but +the hold time information is represented in hundreds of milliseconds. So, the +two in there would actually be 200 milliseconds. And we discussed, I think, +with some folks about why there is that sort of rounding and bucketing that goes +on for potentially privacy purposes. + +_LDK #3842_ + +LDK #3842 is a PR titled, "Add Shared Input support in interactive TX +construction". It's a PR that's part of LDK support for splicing. One +requirement of splicing is the ability to work with a channel peer to construct +a transaction together. And part of jointly constructing that transaction is +the back-and-forth negotiation with the other party, which is not included in +this PR. But what is included in this PR is the ability for LDK to handle the +idea or notion of shared transaction inputs at all. And so, that's what this PR +does. It includes a bunch of plumbing work to support that in LDK's data +structures and workflow. + +_BIPs #1890_ + +BIPs #1890 updates the async payjoin BIP, which is BIP77. Murch, I saw you +commenting and reviewing in that PR to the BIPs repo. What are we changing here +about async payjoin? + +**Mark Erhardt**: Right. So, async payjoin relies on a bunch of data being +exchanged through basically URLs, and a bunch of unique resource identifier +libraries were treating a + basically as a stand-in for spaces. This was +pointed out by some presumably people implementing BIP77. There have so far +only been two full implementations of it, I think. So, after conferring with +the projects that had already implemented asynchronous payjoin, BIP77, this +structuring of how the parameters and the URIs were separated was changed from a ++ to a - so that this would be in line with the libraries that were treating it +not spec-conform, but very commonly as a blank space. And, yeah, so this is +basically just a very natural small improvement due to people starting to +implement the BIP and finding out that there might be something that can be done +differently. And all of the parties that have been implementing it already have +adopted this change. + +So, if you're implementing BIP77, check the change log. There's a small change +there, but it shouldn't be hard to implement. + +_BOLTs #1232_ + +**Mike Schmidt**: Last PR this week, BOLTs #1232, which updates the LN spec to +treat the option channel_type feature as assumed. So, the channel_type can, for +example, be used to signal support for zero-conf channels, "Hey, we're going to +do an anchor output", or other features. And so, maybe this quote from t-bast +will help, "This feature has become more and more useful as we've introduced +various channel commitment formats, and has been introduced more than three +years ago. It should be safe to assume that every implementation sets this TLV +field". And so, that was from the PR itself. Basically, this has been around, +basically all the implementations support it. So, change it from basically +optional to assumed, or I'll interpret that as required, although I assume +there's a reason for it be calling assumed. So, that is an assumed thing now on +the LN as of BOLTs #1232. + +We want to thank our guests, Jesse and Matt, for joining us this week. Murch, I +thank you for joining as a co-host, and for everyone for listening. We'll hear +you next week. + +**Mark Erhardt**: Hear you next week. {% include references.md %} From 968f7dc0c5c8bda5a6cf3f4cbb75e6223341e898 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Tue, 5 Aug 2025 21:57:54 -1000 Subject: [PATCH 193/278] Newsletters: add 366 (2025-08-08) --- .../en/newsletters/2025-08-08-newsletter.md | 170 ++++++++++++++++++ 1 file changed, 170 insertions(+) create mode 100644 _posts/en/newsletters/2025-08-08-newsletter.md diff --git a/_posts/en/newsletters/2025-08-08-newsletter.md b/_posts/en/newsletters/2025-08-08-newsletter.md new file mode 100644 index 0000000000..82220bc08c --- /dev/null +++ b/_posts/en/newsletters/2025-08-08-newsletter.md @@ -0,0 +1,170 @@ +--- +title: 'Bitcoin Optech Newsletter #366' +permalink: /en/newsletters/2025/08/08/ +name: 2025-08-08-newsletter +slug: 2025-08-08-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter announces draft BIPs for Utreexo, summarizes +continued discussion about lowering the minimum transaction relay +feerate, and describes a proposal to allow nodes to share their block +templates to mitigate problems with divergent mempool policies. Also +included are our regular sections summarizing a Bitcoin Core PR Review +Club meeting, announcing new releases and release candidates, and +describing notable changes to popular Bitcoin infrastructure projects. +We also include a correction to last week's newsletter and a +recommendation to readers. + +## News + +- **Draft BIPs proposed for Utreexo:** Calvin Kim [posted][kim bips] to + the Bitcoin-Dev mailing list to announce three draft BIPs co-authored + by him along with Tadge Dryja and Davidson Souza about the + [Utreexo][topic utreexo] validation model. The [first BIP][ubip1] + specifies the structure of the Utreexo accumulator, which allows a + node to store an easily updated commitment to the full UTXO set in as + little as "just a few kilobytes". The [second BIP][ubip2] specifies + how a full node can validate new blocks and transactions using the + accumulator rather than a traditional set of spent transaction outputs + (STXOs, used in early Bitcoin Core and current libbitcoin) or unspent + transaction outputs (UTXOs, used in current Bitcoin Core). The [third + BIP][ubip3] specifies the changes to the Bitcoin P2P protocol that + allow transferring the additional data need for Utreexo validation. + + The authors are seeking conceptual review and will be updating the + draft BIPs based on further developments. + +- **Continued discussion about lowering the minimum relay feerate:** + Gloria Zhao [posted][zhao minfee] to Delving Bitcoin about lowering + the [default minimum relay feerate][topic default minimum transaction + relay feerates] by 90% to 0.1 sat/vbyte. She encouraged conceptual + discussion about the idea and how it might affect other software. For + concerns specific to Bitcoin Core, she linked to a [pull + request][bitcoin core #33106]. + +- **Peer block template sharing to mitigate problems with divergent mempool policies:** + Anthony Towns [posted][towns tempshare] to Delving Bitcoin to suggest + full node peers occasionally send each other their current template + for the next block using [compact block relay][topic compact block + relay] encoding. The receiving peer could then request any + transactions from the template that it was missing, either adding them + to the local mempool or storing them in a cache. This would allow + peers with divergent mempool policies to share transactions despite + their differences. It provides an alternative to a previous proposal + that suggested using _weak blocks_ (see [Newsletter #299][news299 weak + blocks]). Towns published a [proof-of-concept implementation][towns + tempshare poc]. + +## Bitcoin Core PR Review Club + +*In this monthly section, we summarize a recent [Bitcoin Core PR Review +Club][] meeting, highlighting some of the important questions and +answers. Click on a question below to see a summary of the answer from +the meeting.* + +FIXME:stickies-v + +{% include functions/details-list.md + q0="FIXME" + a0="FIXME" + a0link="https://bitcoincore.reviews/31829#l-12FIXME" +%} + +## Optech recommends + +[Bitcoin++ Insider][] has begun publishing reader-funded news about +technical Bitcoin topics. Two of their free weekly newsletters, _Last +Week in Bitcoin_ and _This Week in Bitcoin Core_, may be especially +interesting to regular readers of the Optech newsletter. + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [LND v0.19.3-beta.rc1][] is a release candidate for a maintenance version for this popular LN + node implementation containing "important bug fixes". Most notably, + "an optional migration [...] lowers disk and memory requirements for + nodes significantly." + +- [BTCPay Server 2.2.0][] is a release of this popular self-hosted payment + solution. It adds support for wallet policies and [miniscript][topic + miniscript], provides additional support for transaction fee + management and monitoring, and includes several other new improvements + and bug fixes. + +- [Bitcoin Core 29.1rc1][] is a release candidate for a maintenance + version of the predominant full node software. + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [Bitcoin Core #32941][] p2p: TxOrphanage revamp cleanups + +- [Bitcoin Core #31385][] package validation: relax the package-not-child-with-unconfirmed-parents rule + +- [Bitcoin Core #31244][] descriptors: MuSig2 + +- [Bitcoin Core #30635][] rpc: add optional blockhash to waitfornewblock, unhide wait methods in help + +- [Bitcoin Core #28944][] wallet, rpc: add anti-fee-sniping to `send` and `sendall` + +- [Eclair #3133][] Add outgoing reputation + +- [LND #10097][] Roasbeef/gossip-block-fix + +- [LND #9625][] Add deletecanceledinvoice RPC call + +- [Rust Bitcoin #4730][] p2p: Add formal `Alert` type + +- [BLIPs #55][] Webhook Registration (LSPS5) (#55) + +## Correction + +In [last week's newsletter][news365 p2qrh], we incorrectly described the +updated version of [BIP360][], _pay to quantum-resistant hash_, as +"making exactly the change" that Tim Ruffing showed was secure in his +[recent paper][ruffing paper]. What BIP360 actually does is replace the elliptic +curve commitment to a SHA256-based merkle root (plus a keypath +alternative) with a SHA256 commitment directly to the merkle root. Ruffing's paper showed that +taproot, as currently used, is secure if a quantum-resistant signature +scheme were added to the [tapscript][topic tapscript] language and +keypath spends were disabled. BIP360 instead requires that wallets upgrade +to a variant on taproot (albeit, a trivial variant), eliminates the +keypath mechanism from its variant, and describes the addition of a +quantum-resistant signature scheme to the scripting language used in its +tapleaves. Although Ruffing's paper does not apply to the variant of +taproot proposed in BIP360, the security of this variant (when viewed as +a commitment) follows immediately from the security of the merkle tree. + +We apologize for the error and thank Tim Ruffing for notifying us about +our mistake. + +{% include snippets/recap-ad.md when="2025-08-12 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="33106,32941,31385,31244,30635,28944,3133,10097,9625,4730,55" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[bitcoin++ insider]: https://insider.btcpp.dev/ +[news365 p2qrh]: /en/newsletters/2025/08/01/#security-against-quantum-computers-with-taproot-as-a-commitment-scheme +[zhao minfee]: https://delvingbitcoin.org/t/changing-the-minimum-relay-feerate/1886/ +[towns tempshare]: https://delvingbitcoin.org/t/sharing-block-templates/1906 +[towns tempshare poc]: https://github.com/ajtowns/bitcoin/commit/ee12518a4a5e8932175ee57c8f1ad116f675d089 +[news299 weak blocks]: /en/newsletters/2024/04/24/#weak-blocks-proof-of-concept-implementation +[ruffing paper]: https://eprint.iacr.org/2025/1307 +[kim bips]: https://mailing-list.bitcoindevs.xyz/bitcoindev/3452b63c-ff2b-4dd9-90ee-83fd9cedcf4an@googlegroups.com/ +[ubip1]: https://github.com/utreexo/biptreexo/blob/7ae65222ba82423c1a3f2edd6396c0e32679aa37/utreexo-accumulator-bip.md +[ubip2]: https://github.com/utreexo/biptreexo/blob/7ae65222ba82423c1a3f2edd6396c0e32679aa37/utreexo-validation-bip.md +[ubip3]: https://github.com/utreexo/biptreexo/blob/7ae65222ba82423c1a3f2edd6396c0e32679aa37/utreexo-p2p-bip.md +[btcpay server 2.2.0]: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.2.0 +[lnd v0.19.3-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta.rc1 From 0d1acc9e638a117fca72de49fc9899791dddf337 Mon Sep 17 00:00:00 2001 From: stickies-v Date: Wed, 6 Aug 2025 21:40:35 +0100 Subject: [PATCH 194/278] News366: add review club --- .../en/newsletters/2025-08-08-newsletter.md | 87 ++++++++++++++++++- 1 file changed, 83 insertions(+), 4 deletions(-) diff --git a/_posts/en/newsletters/2025-08-08-newsletter.md b/_posts/en/newsletters/2025-08-08-newsletter.md index 82220bc08c..db4ba197c0 100644 --- a/_posts/en/newsletters/2025-08-08-newsletter.md +++ b/_posts/en/newsletters/2025-08-08-newsletter.md @@ -64,12 +64,89 @@ Club][] meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.* -FIXME:stickies-v +[Add exportwatchonlywallet RPC to export a watchonly version of a +wallet][review club 32489] is a PR by [achow101][gh achow101] that +reduces the amount of manual work required to create a watch-only +wallet. Before this change, users had to do that by typing or +scripting `importdescriptors` RPC calls, copying address labels, etc. + +Besides public [descriptors][topic descriptors], the +export also contains: +- caches containing derived xpubs when necessary, e.g., in case of + hardened derivation paths +- address book entries, wallet flags and user labels +- all historical wallet transactions so rescans are unnecessary + +The exported wallet database can then be imported with the +`restorewallet` RPC. + {% include functions/details-list.md - q0="FIXME" - a0="FIXME" - a0link="https://bitcoincore.reviews/31829#l-12FIXME" + q0="Why can’t the existing `IsRange()`/`IsSingleType()` information tell + us whether a descriptor can be expanded on the watch-only side? + Explain the logic behind `CanSelfExpand()` for a) a hardened + `wpkh(xpub/0h/*)` path and b) a `pkh(pubkey)` descriptor." + a0="`IsRange()` and `IsSingleType()` were insufficient because they + don't check for hardened derivation, which requires private keys + unavailable in a watch-only wallet. `CanSelfExpand()` was added to + recursively search for hardened paths; if it finds one, it returns + `false`, signaling that a pre-populated cache must be exported for the + watch-only wallet to derive addresses. A `pkh(pubkey)` descriptor is + not ranged and has no derivation, so it can always self-expand." + a0link="https://bitcoincore.reviews/32489#l-27" + + q1="`ExportWatchOnlyWallet` only copies the descriptor cache if + `!desc->CanSelfExpand()`. What exactly is stored in that cache? How + could an incomplete cache affect address derivation on the watch-only + wallet?" + a1="The cache stores `CExtPubKey` objects for descriptors with + hardened derivation paths, which are pre-derived on the spending + wallet. If this cache is incomplete, the watch-only wallet cannot + derive the missing addresses because it lacks the necessary private + keys. This would cause it to fail to see transactions sent to those + addresses, leading to an incorrect balance." + a1link="https://bitcoincore.reviews/32489#l-52" + + q2="The exporter sets `create_flags = GetWalletFlags() | + WALLET_FLAG_DISABLE_PRIVATE_KEYS`. Why is it important to preserve the + original flags (e.g. `AVOID_REUSE`) instead of clearing everything and + starting fresh?" + a2="Preserving flags ensures behavioral consistency between the + spending and watch-only wallets. For example, the `AVOID_REUSE` flag + affects which coins are considered available for spending. Not + preserving it would cause the watch-only wallet to report a different + available balance than the main wallet, leading to user confusion." + a2link="https://bitcoincore.reviews/32489#l-68" + + q3="Why does the exporter read the locator from the source wallet and + write it verbatim into the new wallet instead of letting the new + wallet start from block 0?" + a3="The block locator is copied to tell the new watch-only wallet + where to resume scanning the blockchain for new transactions, + preventing the need for a complete rescan." + a3link="https://bitcoincore.reviews/32489#l-93" + + q4="Consider a multisig descriptor `wsh(multi(2,xpub1,xpub2))`. If one + cosigner exports a watch-only wallet and shares it with a third party, + what new information does that third party learn compared to just + giving them the descriptor strings?" + a4="The watch-only wallet data includes additional metadata such as + address book, wallet flags and coin-control labels. For wallets with + hardened derivation, the third party can only get information about + historical and future transactions through the watch-only wallet + export." + a4link="https://bitcoincore.reviews/32489#l-100" + + q5="In `wallet_exported_watchonly.py`, why does the test call + `wallet.keypoolrefill(100)` before checking spendability across the + online/offline pair?" + a5="The `keypoolrefill(100)` call forces the offline (spending) wallet + to pre-derive 100 keys for its hardened descriptors, populating its + cache. This cache is then included in the export, allowing the online + watch-only wallet to generate those 100 addresses. It also ensures the + offline wallet will recognize these addresses when it receives a PSBT + to sign." + a5link="https://bitcoincore.reviews/32489#l-122" %} ## Optech recommends @@ -168,3 +245,5 @@ our mistake. [ubip3]: https://github.com/utreexo/biptreexo/blob/7ae65222ba82423c1a3f2edd6396c0e32679aa37/utreexo-p2p-bip.md [btcpay server 2.2.0]: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.2.0 [lnd v0.19.3-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta.rc1 +[review club 32489]: https://bitcoincore.reviews/32489 +[gh achow101]: https://github.com/achow101 From 57ba6514d24e0c76e01a24e984e2d13fb22defbb Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 7 Aug 2025 08:19:13 +0000 Subject: [PATCH 195/278] News366: add merge summaries --- .../en/newsletters/2025-08-08-newsletter.md | 87 +++++++++++++++---- 1 file changed, 68 insertions(+), 19 deletions(-) diff --git a/_posts/en/newsletters/2025-08-08-newsletter.md b/_posts/en/newsletters/2025-08-08-newsletter.md index db4ba197c0..9b07ae063b 100644 --- a/_posts/en/newsletters/2025-08-08-newsletter.md +++ b/_posts/en/newsletters/2025-08-08-newsletter.md @@ -187,25 +187,67 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Bitcoin Core #32941][] p2p: TxOrphanage revamp cleanups - -- [Bitcoin Core #31385][] package validation: relax the package-not-child-with-unconfirmed-parents rule - -- [Bitcoin Core #31244][] descriptors: MuSig2 - -- [Bitcoin Core #30635][] rpc: add optional blockhash to waitfornewblock, unhide wait methods in help - -- [Bitcoin Core #28944][] wallet, rpc: add anti-fee-sniping to `send` and `sendall` - -- [Eclair #3133][] Add outgoing reputation - -- [LND #10097][] Roasbeef/gossip-block-fix - -- [LND #9625][] Add deletecanceledinvoice RPC call - -- [Rust Bitcoin #4730][] p2p: Add formal `Alert` type - -- [BLIPs #55][] Webhook Registration (LSPS5) (#55) +- [Bitcoin Core #32941][] completes the overhaul of `TxOrphanage` (see + [Newsletter #364][news364 orphan]) by enabling automatic trimming of the + orphanage whenever its limits are exceeded. + It adds a warning for `maxorphantx` users to inform them that it is obsolete. + This PR solidifies opportunistic + one-parent-one-child (1p1c) [package relay][topic package relay]. + +- [Bitcoin Core #31385][] relaxes the + `package-not-child-with-unconfirmed-parents` rule of the `submitpackage` RPC + to improve 1p1c [package relay][topic package relay] usage. Packages + no longer need to include the parents that are already in the node's mempool. + +- [Bitcoin Core #31244][] implements the parsing of [MuSig2][topic musig] + [descriptors][topic descriptors] as defined in [BIP390][], which is required + for receiving and spending inputs from [taproot][topic taproot] addresses with + MuSig2 aggregate keys. + +- [Bitcoin Core #30635][] begins displaying the `waitfornewblock`, + `waitforblock`, and `waitforblockheight` RPCs in the help command + response, indicating that they're meant for regular users. This PR + also adds an optional `current_tip` argument to the `waitfornewblock` + RPC, to mitigate against race conditions by specifying the block hash + of the current chain tip. + +- [Bitcoin Core #28944][] adds anti-[fee sniping][topic fee sniping] protection + to transactions sent with the `send` and `sendall` RPC commands by adding a + random tip-relative [locktime][topic timelocks] if one is not already + specified. + +- [Eclair #3133][] extends its [HTLC endorsement][topic htlc endorsement] local + peer-reputation system (see [Newsletter #363][news363 reputation]) to score the + reputation of outgoing peers, just like for incoming peers. Eclair now would + consider a good reputation in both directions when forwarding an HTLC, but + doesn’t implement penalties yet. Scoring outgoing peers is necessary to + prevent sink attacks (see [Newsletter #322][news322 sink]), a specific type of + [channel jamming attack][topic channel jamming attacks]. + +- [LND #10097][] introduces an asynchronous, per-peer queue for backlog + [gossip][topic channel announcements] requests (`GossipTimestampRange`) to + eliminate the risk of deadlocks when a peer sends too many requests at once. + If a peer sends a request before the previous one finishes, the additional + message is quietly dropped. A new `gossip.filter-concurrency` setting (default + 5) is added to limit the number of concurrent workers across all peers. The PR + also adds documentation explaining how all gossip rate limit configuration + settings work. + +- [LND #9625][] adds a `deletecanceledinvoice` RPC command (and its `lncli` + equivalent) that allows users to remove canceled [BOLT11][] invoices (see + [Newsletter #33][news33 canceled]) by providing their payment hash. + +- [Rust Bitcoin #4730][] adds an `Alert` type wrapper for the [final alert][] + message that notifies peers running a vulnerable version of Bitcoin Core + (before 0.12.1) that their alert system is insecure. Satoshi introduced the + alert system to notify users of significant network events, but it was + [retired][] in version 0.12.1, except for the final alert message. + +- [BLIPs #55][] adds [BLIP55][] to specify how mobile clients can register for + webhooks via an endpoint to receive push notifications from an LSP. This + protocol is useful for clients to get notified when receiving an [async + payment][topic async payments], and was recently implemented in LDK (See + [Newsletter #365][news365 webhook]). ## Correction @@ -247,3 +289,10 @@ our mistake. [lnd v0.19.3-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta.rc1 [review club 32489]: https://bitcoincore.reviews/32489 [gh achow101]: https://github.com/achow101 +[news363 reputation]: /en/newsletters/2025/07/18/#eclair-2716 +[news322 sink]: /en/newsletters/2024/09/27/#hybrid-jamming-mitigation-testing-and-changes +[news33 canceled]: /en/newsletters/2019/02/12/#lnd-2457 +[final alert]: https://bitcoin.org/en/release/v0.14.0#final-alert +[retired]: https://bitcoin.org/en/alert/2016-11-01-alert-retirement#updates +[news365 webhook]: /en/newsletters/2025/08/01/#ldk-3662 +[news364 orphan]: /en/newsletters/2025/07/25/#bitcoin-core-31829 \ No newline at end of file From 596af827c902c74d5936e7a593e0b2abe049d127 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Fri, 8 Aug 2025 08:01:28 -0500 Subject: [PATCH 196/278] News366: add topics --- _topics/en/compact-block-relay.md | 3 +++ _topics/en/default-minimum-transaction-relay-feerates.md | 3 +++ _topics/en/musig.md | 3 +++ _topics/en/utreexo.md | 3 +++ 4 files changed, 12 insertions(+) diff --git a/_topics/en/compact-block-relay.md b/_topics/en/compact-block-relay.md index 627d544728..73ab7cec5e 100644 --- a/_topics/en/compact-block-relay.md +++ b/_topics/en/compact-block-relay.md @@ -72,6 +72,9 @@ optech_mentions: - title: "Results from testing compact block relay prefilling" url: /en/newsletters/2025/08/01/#testing-compact-block-prefilling + - title: Peer block template sharing proposed to improve compact block performance with divergent mempools + url: /en/newsletters/2025/08/08/#peer-block-template-sharing-to-mitigate-problems-with-divergent-mempool-policies + ## Optional. Same format as "primary_sources" above # see_also: # - title: diff --git a/_topics/en/default-minimum-transaction-relay-feerates.md b/_topics/en/default-minimum-transaction-relay-feerates.md index 2bbb5a67a9..014e93b27e 100644 --- a/_topics/en/default-minimum-transaction-relay-feerates.md +++ b/_topics/en/default-minimum-transaction-relay-feerates.md @@ -44,6 +44,9 @@ optech_mentions: - title: Renewed discussion about lowering the default minimum transaction relay feerate url: /en/newsletters/2025/02/07/#discussion-about-lowering-the-minimum-transaction-relay-feerate + - title: Continued discussion about lowering the default minimum transaction relay feerate + url: /en/newsletters/2025/08/08/#continued-discussion-about-lowering-the-minimum-relay-feerate + ## Optional. Same format as "primary_sources" above see_also: - title: Package relay diff --git a/_topics/en/musig.md b/_topics/en/musig.md index 9953b55188..df92943e3e 100644 --- a/_topics/en/musig.md +++ b/_topics/en/musig.md @@ -163,6 +163,9 @@ optech_mentions: - title: "Rust libsecp256k1 #798 completes its MuSig2 implementation" url: /en/newsletters/2025/06/20/#rust-libsecp256k1-798 + - title: "Bitcoin Core #31244 implements the parsing of MuSig2 descriptors as defined in BIP390" + url: /en/newsletters/2025/08/08/#bitcoin-core-31244 + ## Optional. Same format as "primary_sources" above see_also: - title: Scriptless multisignatures diff --git a/_topics/en/utreexo.md b/_topics/en/utreexo.md index d29e12acc3..75f19cb5f7 100644 --- a/_topics/en/utreexo.md +++ b/_topics/en/utreexo.md @@ -55,6 +55,9 @@ optech_mentions: - title: Discussion of alternatives to Utreexo for proving UTXO existence without a UTXO set url: /en/newsletters/2025/06/06/#removing-outputs-from-the-utxo-set-based-on-value-and-time + - title: "Draft BIPs published with specifications for Utreexo accumulator, validation, and P2P protocol" + url: /en/newsletters/2025/08/08/#draft-bips-proposed-for-utreexo + ## Optional. Same format as "primary_sources" above see_also: - title: Uneconomical outputs From 894459c4df33ec908f8d846d2e1e5990f772e3d8 Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 8 Aug 2025 22:42:17 +0900 Subject: [PATCH 197/278] Newsletter-366:Translate into Japanese --- .../ja/newsletters/2025-08-08-newsletter.md | 250 ++++++++++++++++++ 1 file changed, 250 insertions(+) create mode 100644 _posts/ja/newsletters/2025-08-08-newsletter.md diff --git a/_posts/ja/newsletters/2025-08-08-newsletter.md b/_posts/ja/newsletters/2025-08-08-newsletter.md new file mode 100644 index 0000000000..73378a0657 --- /dev/null +++ b/_posts/ja/newsletters/2025-08-08-newsletter.md @@ -0,0 +1,250 @@ +--- +title: 'Bitcoin Optech Newsletter #366' +permalink: /ja/newsletters/2025/08/08/ +name: 2025-08-08-newsletter-ja +slug: 2025-08-08-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、UtreexoのBIPドラフトの発表と、 +最小トランザクションリレー手数料率の引き下げに関する継続議論、 +mempoolポリシーの相違による問題を軽減するためにノードがブロックテンプレートを共有できるようにする提案を掲載しています。 +また、Bitcoin Core PR Review Clubミーティングの概要や、新しいリリースとリリース候補の発表、 +人気のBitcoinインフラストラクチャプロジェクトの注目すべき更新など恒例のセクションも含まれています。 +さらに、先週のニュースレターの訂正と読者へのお勧めも掲載しています。 + +## ニュース + +- **UtreexoのBIPドラフトの提案:** Calvin Kimは、Tadge DryjaおよびDavidson Souzaと共同で作成した + [Utreexo][topic utreexo]検証モデルに関する3つのBIPドラフトをBitcoin-Devメーリングリストに[投稿しました][kim bips]。 + [最初のBIP][ubip1]は、Utreexoアキュムレーターの構造を規定しています。 + このアキュムレーターにより、ノードはわずか数KBで、完全なUTXOセットへのコミットメントを簡単に更新、保存できます。 + [2つめのBIP][ubip2]は、従来の使用済みトランザクションアウトプット（STXO、初期のBitcoin Coreとlibbitcoinで使用）や + 未使用トランザクションアウトプット（UTXO：現在のBitcoin Coreで使用）ではなく、 + アキュムレーターを使用してフルノードが新しいブロックとトランザクションを検証する方法を規定しています。 + [3つめのBIP][ubip3]は、Utreexoの検証に必要な追加データの転送を可能にするBitcoinのP2Pプロトコルの変更を規定しています。 + + 著者たちは概念的なレビューを求めており、今後の進展に基づいてBIPドラフトを更新する予定です。 + +- **最小リレー手数料率の引き下げに関する議論の続き:** + Gloria Zhaoは、[デフォルトの最小リレー手数料率][topic default minimum transaction relay feerates]を + 90％引き下げて0.1 sat/vbyteにするという案についてDelving Bitcoinに[投稿しました][zhao minfee]。 + 彼女は、このアイディアのコンセプトと、他のソフトウェアに与える影響についての議論を促しました。 + Bitcoin Core固有の懸念事項については、[プリリクエスト][bitcoin core #33106]のリンクを示しました。 + +- **mempoolポリシーの相違による問題を軽減するためのピアのブロックテンプレートの共有:** + Anthony Townsは、フルノードピアが[コンパクトブロックリレー][topic compact block relay] + エンコーディングを使って、次のブロック用の現在のテンプレートを定期的に相互に送信する提案を + Delving Bitcoinに[投稿しました][towns tempshare]。受信側のピアは、 + テンプレート内の不足しているトランザクションを要求でき、それらをローカルのmempoolに追加するか、 + キャッシュに格納することができます。これによりmempoolポリシーが異なるピア同士でも、 + ポリシーの違いにかかわらずトランザクションを共有できるようになります。 + これは以前提案された弱ブロックを使用する方法（[ニュースレター #299][news299 weak blocks]参照）の代替になります。 + Townsは、[概念実証の実装][towns tempshare poc]も公開しました。 + +## Bitcoin Core PR Review Club + +*この毎月のセクションでは、最近の[Bitcoin Core PR Review Club][]ミーティングを要約し、 +重要な質問と回答のいくつかに焦点を当てます。 +以下の質問をクリックしてミーティングでの回答の要約を確認してください。* + +[Add exportwatchonlywallet RPC to export a watchonly version of a +wallet][review club 32489]は、[achow101][gh achow101]によるPRで、 +監視専用ウォレットの作成に必要な手作業が削減されます。この変更以前は、 +`importdescriptors` RPC呼び出しを入力またはスクリプト化したり、 +アドレスラベルをコピーしたりする必要がありました。 + +公開[ディスクリプター][topic descriptors]に加えて、エクスポートされるものには以下が含まれます: +- 必要に応じて導出されたxpubを含むキャッシュ（例：強化導出される導出パスの場合） +- アドレス帳のエントリー、ウォレットフラグ、ユーザーラベル +- 過去のすべてのウォレットトランザクション（再スキャンは不要） + +エクスポートされたウォレットデータベースは、`restorewallet` RPCを使ってインポートできます。 + +{% include functions/details-list.md + q0="なぜ既存の`IsRange()`/`IsSingleType()`情報では、ディスクリプターが監視専用側で + 展開可能かどうかを判断できないのですか？ + a) 強化導出用の`wpkh(xpub/0h/*)`パスと + b) `pkh(pubkey)`ディスクリプターについて、`CanSelfExpand()`のロジックを説明してください。" + a0="`IsRange()`と`IsSingleType()`は、強化導出のチェックをしないため不十分でした。 + 強化導出には監視専用ウォレットでは利用できない秘密鍵が必要になります。 + `CanSelfExpand()`は強化導出パスを再帰的に検索するために追加されました。 + 強化導出パスが見つかった場合は`false`を返し、監視専用ウォレットがアドレスを導出するには + 事前に設定されたキャッシュをエクスポートする必要があることを示します。 + `pkh(pubkey)`ディスクリプターは範囲指定されておらず、導出もないため、 + 常に自己展開可能です" + a0link="https://bitcoincore.reviews/32489#l-27" + + q1="`ExportWatchOnlyWallet`は、`!desc->CanSelfExpand()`の場合のみディスクリプターキャッシュをコピーします。 + そのキャッシュには具体的に何が格納されていますか？キャッシュが不完全だと、 + 監視専用ウォレットのアドレス導出にどのような影響がありますか？" + a1="キャッシュには、強化導出パスを持つディスクリプター用の`CExtPubKey`オブジェクトが格納されており、 + これらは支払い用のウォレットで事前に導出されています。 + キャッシュが不完全な場合、監視専用ウォレットは必要な秘密鍵を持たないため、 + 不足しているアドレスを導出できません。これにより、それらのアドレスに送信されたトランザクションを認識できず、 + 残高が正しく表示されなくなります。" + a1link="https://bitcoincore.reviews/32489#l-52" + + q2="エクスポーターは`create_flags = GetWalletFlags() | WALLET_FLAG_DISABLE_PRIVATE_KEYS`を設定します。 + なぜすべてクリアして新しく始めるのではなく、元のフラグ（例：`AVOID_REUSE`）を保持するのが重要なのですか？" + a2="フラグを保持することで、支払い用のウォレットと監視専用ウォレット間の動作の一貫性が確保されます。 + たとえば、`AVOID_REUSE`フラグは、どのコインが支払いに利用可能と見なされるかに影響します。 + これを保持しないと、監視専用ウォレットがメインとウォレットとは異なる利用可能残高を報告し、 + ユーザーに混乱を招くことになります。" + a2link="https://bitcoincore.reviews/32489#l-68" + + q3="なぜエクスポーターは新しいウォレットをブロック0から開始させるのではなく、 + ソースウォレットからロケーターを読み取って新しいウォレットにそのまま書き込むのですか？" + a3="ブロックロケーターをコピーすることで、新しい監視専用ウォレットが + ブロックチェーンの新しいトランザクションのスキャンを開始する場所を伝え、 + 完全な再スキャンの必要性を回避します。" + a3link="https://bitcoincore.reviews/32489#l-93" + + q4="マルチシグディスクリプター`wsh(multi(2,xpub1,xpub2))`を考えてみましょう。 + 1人の共同署名者が監視専用ウォレットをエクスポートして第三者と共有した場合、 + 単にディスクリプター文字列を提供する場合と比べて、その第三者はどのような新しい情報を得ますか？" + a4="監視専用ウォレットのデータには、アドレス帳、ウォレットフラグ、 + コイン管理ラベルなどの追加のメタデータが含まれています。強化導出ウォレットの場合、 + 第三者は監視専用ウォレットのエクスポートを通じてのみ、過去および将来のトランザクションに関する情報を取得でききます。" + a4link="https://bitcoincore.reviews/32489#l-100" + + q5="`wallet_exported_watchonly.py`では、なぜテストはオンライン/オフラインのペアで + 支払い可能性をチェックする前に、`wallet.keypoolrefill(100)`を呼び出すのですか？" + a5="`keypoolrefill(100)`呼び出しは、オフライン（支払い）ウォレットに + 強化ディスクリプター用に100個の鍵を事前に導出させ、キャッシュに入力します。 + このキャッシュはその後のエクスポートに含まれ、 + オンラインの監視専用ウォレットがそれら100個のアドレスを生成できるようになります。 + また、オフラインウォレットが署名するPSBTを受信した際に、これらのアドレスを認識できるようになります。" + a5link="https://bitcoincore.reviews/32489#l-122" +%} + +## Optechのお勧め + +[Bitcoin++ Insider][]は、読者から資金提供を受けてBitcoinの技術的なトピックに関するニュースの配信を始めました。 +無料の週刊ニュースレター「Last Week in Bitcoin」と +「This Week in Bitcoin Core」は、Optechのニュースレターの定期購読者にとって特に興味深い内容となるでしょう。 + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [LND v0.19.3-beta.rc1][]は、この人気のLNノード実装のメンテナンスバージョンのリリース候補で、 + 「重要なバグ修正」が含まれています。最も注目すべきは、「オプションの移行で[...] + ノードのディスクおよびメモリ要件が大幅に削減される」ことです。 + +- [BTCPay Server 2.2.0][]は、このセルフホスト型ペイメントソリューションのリリースです。 + ウォレットポリシーと[miniscript][topic miniscript]のサポートが追加され、 + トランザクション手数料の管理と監視に対する追加サポートが提供され、 + その他いくつかの新しい改善とバグ修正も含まれています。 + +- [Bitcoin Core 29.1rc1][]は、主要なフルノードソフトウェアのメンテナンスバージョンのリリース候補です。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Bitcoin Core #32941][]は、制限を超えた際のOrphanageの自動トリミングを有効にして + `TxOrphanage`のオーバーホール（[ニュースレター #364][news364 orphan]参照）を完了します。 + `maxorphantx`のユーザーに対して、それが廃止されたことを通知する警告も追加します。 + このPRは、機会的な1P1C（one-parent-one-child）[パッケージリレー][topic package relay]を確実なものにします。 + +- [Bitcoin Core #31385][]は、`submitpackage` RPCの + `package-not-child-with-unconfirmed-parents`ルールを緩和し、 + 1P1C[パッケージリレー][topic package relay]の使用法を改善します。 + パッケージは、ノードのmempoolに既に存在する親を含める必要がなくなりました。 + +- [Bitcoin Core #31244][]は、[BIP390][]で定義されている[MuSig2][topic musig] + [ディスクリプター][topic descriptors]のパースを実装します。 + これは、MuSig2集約鍵を持つ[Taproot][topic taproot]アドレスからの受け取りとインプットの使用の際に必要です。 + +- [Bitcoin Core #30635][]では、helpコマンドの応答に + `waitfornewblock`、`waitforblock`、`waitforblockheight` RPCが表示されるようになり、 + これらが一般ユーザー向けであることが示されます。またこのPRでは、 + `waitfornewblock` RPCにオプションの`current_tip`引数が追加され、 + 現在のチェーンの先端のブロックハッシュを指定することで、競合状態を軽減します。 + +- [Bitcoin Core #28944][]は、`send` RPCコマンドおよび`sendall` + RPCコマンドで送信されるトランザクションに、まだ指定されていない場合は、 + ランダムな先頭相対[ロックタイム][topic timelocks]を追加することで、 + [手数料スナイピング][topic fee sniping]防止保護を追加します。 + +- [Eclair #3133][]は、[HTLCエンドースメント][topic htlc endorsement]の + ローカルピアレピュテーションシステム（[ニュースレター #363][news363 reputation]参照）を拡張し、 + 着信ピアと同様に発信ピアのレビュテーションもスコアリングします。 + EclairはHTLCを転送する際に両方向で良いレピュテーションを考慮するようになりましたが、 + まだペナルティは実装していません。発信ピアのスコアリングは、 + [チャネルジャミング攻撃][topic channel jamming attacks]の特定の種類である + シンク攻撃（[ニュースレター #322][news322 sink]参照）を防ぐために必要です。 + +- [LND #10097][]は、ピアが一度に多くのリクエストを送信した際のデッドロックのリスクを排除するために、 + バックログ[ゴシップ][topic channel announcements]リクエスト（`GossipTimestampRange`）用の + 非同期なピア毎のキューを導入します。ピアが前のリクエストが完了する前にリクエストを送信した場合、 + 追加のメッセージは自動的に破棄されます。すべてのピアにわたる同時ワーカー数を制限するために + 新しく`gossip.filter-concurrency`設定（デフォルト5）が追加されます。このPRはまた、 + すべてのゴシップレート制限設定の動作を説明するドキュメントも追加しています。 + +- [LND #9625][]は、ペイメントハッシュを提供することで、ユーザーがキャンセルされた + [BOLT11][]インボイス（[ニュースレター #33][news33 canceled]参照）を削除できる + `deletecanceledinvoice` RPCコマンド（および同等の`lncli`）を追加します。 + +- [Rust Bitcoin #4730][]は、脆弱なバージョンのBitcoin Core（0.12.1未満）を実行しているピアに、 + 彼らのアラートシステムが安全でないことを通知する[最終アラート][final alert]メッセージ用の + `Alert`型ラッパーを追加します。satoshiは重要なネットワークイベントをユーザーに通知するために + アラートシステムを導入しましたが、最終アラートメッセージを除いて、 + バージョン0.12.1で[廃止されました][retired]。 + +- [BLIPs #55][]は、モバイルクライアントがLSPからプッシュ通知を受信するために + エンドポイント経由でウェブフックに登録する方法を定義する[BLIP55][]を追加します。 + このプロトコルは、クライアントが[非同期支払い][topic async payments]を受信した際に通知を受け取るのに便利で、 + 最近LDKに実装されました（[ニュースレター #365][news365 webhook]参照）。 + +## 訂正 + +[先週のニュースレター][news365 p2qrh]で、[BIP360][] _pay to quantum-resistant hash_ +の更新版について、Tim Ruffingが[論文][ruffing paper]で安全性を示した変更を +「まさにこの変更が行われています」と誤って説明していました。 +BIP360が実際に行っているのは、SHA256ベースのマークルルート（プラスkeypathの代替）への楕円曲線コミットメントを +マークルルートへのSHA256コミットメントに直接置き換えることです。Ruffingの論文が示したのは、 +現在使用されているTaprootは、[Tapscript][topic tapscript]言語に量子耐性署名スキームが追加され、 +keypath支払いが無効化されれば安全であるということでした。 +一方、BIP360は、ウォレットにTaprootの（些細な）変種へのアップグレードを要求し、 +その変種からkeypathメカニズムを削除し、そのTapleafで使用されるスクリプト言語に量子耐性署名スキームの追加するものです。 +Ruffingの論文はBIP360で提案されたtaprootの変種には適用されませんが、 +この変種の安全性（コミットメントとして見た場合）は、マークルツリーの安全性から直接導かれます。 + +誤りについてお詫び申し上げます。また、私たちのミスについて指摘くださったTim Ruffingに感謝します。 + +{% include snippets/recap-ad.md when="2025-08-12 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="33106,32941,31385,31244,30635,28944,3133,10097,9625,4730,55" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[bitcoin++ insider]: https://insider.btcpp.dev/ +[news365 p2qrh]: /ja/newsletters/2025/08/01/#taproot +[zhao minfee]: https://delvingbitcoin.org/t/changing-the-minimum-relay-feerate/1886/ +[towns tempshare]: https://delvingbitcoin.org/t/sharing-block-templates/1906 +[towns tempshare poc]: https://github.com/ajtowns/bitcoin/commit/ee12518a4a5e8932175ee57c8f1ad116f675d089 +[news299 weak blocks]: /ja/newsletters/2024/04/24/#weak-blocks-proof-of-concept-implementation +[ruffing paper]: https://eprint.iacr.org/2025/1307 +[kim bips]: https://mailing-list.bitcoindevs.xyz/bitcoindev/3452b63c-ff2b-4dd9-90ee-83fd9cedcf4an@googlegroups.com/ +[ubip1]: https://github.com/utreexo/biptreexo/blob/7ae65222ba82423c1a3f2edd6396c0e32679aa37/utreexo-accumulator-bip.md +[ubip2]: https://github.com/utreexo/biptreexo/blob/7ae65222ba82423c1a3f2edd6396c0e32679aa37/utreexo-validation-bip.md +[ubip3]: https://github.com/utreexo/biptreexo/blob/7ae65222ba82423c1a3f2edd6396c0e32679aa37/utreexo-p2p-bip.md +[btcpay server 2.2.0]: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.2.0 +[lnd v0.19.3-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta.rc1 +[review club 32489]: https://bitcoincore.reviews/32489 +[gh achow101]: https://github.com/achow101 +[news363 reputation]: /ja/newsletters/2025/07/18/#eclair-2716 +[news322 sink]: /ja/newsletters/2024/09/27/#hybrid-jamming-mitigation-testing-and-changes +[news33 canceled]: /en/newsletters/2019/02/12/#lnd-2457 +[final alert]: https://bitcoin.org/en/release/v0.14.0#final-alert +[retired]: https://bitcoin.org/en/alert/2016-11-01-alert-retirement#updates +[news365 webhook]: /ja/newsletters/2025/08/01/#ldk-3662 +[news364 orphan]: /ja/newsletters/2025/07/25/#bitcoin-core-31829 \ No newline at end of file From 7dfa7549760a6388959bca54e7f4a23fa100daf6 Mon Sep 17 00:00:00 2001 From: "Zhiwei(Jeffrey) Hu" Date: Fri, 8 Aug 2025 22:19:38 +0800 Subject: [PATCH 198/278] Newsletter-363: translate into Chinese (#2440) --- .../zh/newsletters/2025-07-18-newsletter.md | 71 +++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 _posts/zh/newsletters/2025-07-18-newsletter.md diff --git a/_posts/zh/newsletters/2025-07-18-newsletter.md b/_posts/zh/newsletters/2025-07-18-newsletter.md new file mode 100644 index 0000000000..f74fc6e57b --- /dev/null +++ b/_posts/zh/newsletters/2025-07-18-newsletter.md @@ -0,0 +1,71 @@ +--- +title: 'Bitcoin Optech Newsletter #363' +permalink: /zh/newsletters/2025/07/18/ +name: 2025-07-18-newsletter-zh +slug: 2025-07-18-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的周报包括我们的常规部分：总结了服务和客户端软件的更新、新版本和候选版本的公告，以及对热门比特币基础设施软件的重大变更介绍。 + +## 新闻 + +_本周在我们的[来源][sources]中没有发现重大新闻。_ + +## 服务和客户端软件变更 + +*在这个月度专题中，我们会重点介绍比特币钱包和服务的有趣更新。* + +- ******Floresta v0.8.0 发布：** + [Floresta v0.8.0][floresta v0.8.0] 版本的这个 [Utreexo][topic utreexo] 节点增加了对 [P2P 传输协议第 2 版 (BIP324)][topic v2 p2p transport]、[testnet4][topic testnet] 的支持，增强了指标和监控功能，以及其他功能和错误修复。 + +- ******RGB v0.12 发布：** + RGB v0.12 [博客文章][rgb blog] 宣布发布了 RGB 的共识层，用于比特币测试网和主网上的 RGB [客户端验证][topic client-side validation] 智能合约。 + +- ******FROST 签名设备可用：** + [Frostsnap][frostsnap website] 签名设备支持使用 FROST 协议的 k-of-n [阈值签名][topic threshold signature]，在链上只需一个签名。 + +- ******Gemini 增加 taproot 支持：** + Gemini 交易所和 Gemini 托管服务增加了对发送（提款）到 [taproot][topic taproot] 地址的支持。 + +- ******Electrum 4.6.0 发布：** + [Electrum 4.6.0][electrum 4.6.0] 增加了对[潜水艇互换][topic submarine swaps] 的支持，使用 nostr 进行发现。 + +## 新版本和候选版本 + +*热门比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本。* + +- [LND v0.19.2-beta][] 是这个热门闪电网络节点的维护版本。它“包含重要的错误修复和性能改进”。 + +## 重大的代码和文档变更 + +*本周的重大变更有：[Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface（HWI）][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement Proposals（BIPs）][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo]。* + +- [Bitcoin Core #32604][] 对无条件写入磁盘的日志（如 `LogPrintf`、`LogInfo`、`LogWarning` 和 `LogError`）进行了速率限制，通过给每个源代码位置每小时 1 MB 的配额来减轻磁盘填充攻击。当任何源代码位置被抑制时，所有日志行前面都会加上星号 (*)。控制台输出、带有显式类别参数的日志以及初始区块下载 (IBD) 的 `UpdateTip` 消息不受速率限制。当配额重置时，Core 会打印被丢弃的字节数。 + +- [Bitcoin Core #32618][] 移除了 `include_watchonly` 选项及其变体，以及所有钱包 RPC 中的 `iswatchonly` 字段，因为[描述符][topic descriptors]钱包不支持混合使用只读和可花费描述符。以前，用户可以将只读地址或脚本导入到传统支出钱包中。然而，传统钱包现在已被移除。 + +- [Bitcoin Core #31553][] 通过引入 `TxGraph::Trim()` 函数，为[族群交易池][topic cluster mempool]项目添加了区块重组处理功能。当重组将先前确认的交易重新引入交易池，且结果组合的族群超过族群数量或权重策略限制时，`Trim()` 会构建一个按费率排序、尊重依赖关系的基本线性化。如果添加交易会违反限制，则该交易及其所有后代都会被丢弃。 + +- [Core Lightning #7725][] 添加了一个轻量级 JavaScript 日志查看器，可在浏览器中加载 CLN 日志文件，并允许用户按守护进程、类型、通道或正则表达式过滤消息。这个工具在提高开发人员和节点运营者的调试体验的同时，最小化了存储库维护开销。 + +- [Eclair #2716][] 为 [HTLC 背书][topic htlc endorsement] 实现了一个本地对等节点声誉系统，该系统跟踪每个入账对等节点赚取的路由费用与基于所使用的流动性和 [HTLC][topic htlc] 槽位应该赚取的费用。成功的支付会得到完美分数，失败的支付会降低分数，而超过配置阈值仍处于待处理状态的 HTLC 会受到严重惩罚。在转发时，节点会在 `update_add_htlc` 背书 TLV 中包含其当前对等节点分数（参见周报 [#315][news315 htlc]）。运营者可以在配置中调整声誉衰减（`half-life`）、卡住支付阈值（`max-relay-duration`）、卡住 HTLC 的惩罚权重（`pending-multiplier`），或者完全禁用声誉系统。这个 PR 主要是收集数据以改进[通道阻塞攻击][topic channel jamming attacks]研究，尚未实施惩罚措施。 + +- [LDK #3628][] 实现了[异步支付][topic async payments]的服务器端逻辑，允许 LSP 节点代表经常离线的接收者提供 [BOLT12][topic offers] 静态发票。LSP 节点可以接受来自接收者的 `ServeStaticInvoice` 消息，存储提供的静态发票，并通过搜索并通过[盲路径][topic rv routing]返回缓存的发票来响应付款人的发票请求。 + +- [LDK #3890][] 改变了其路径查找算法中的路由评分方式，考虑总成本除以通道金额限制（每可用容量 sat 的成本），而不是仅考虑原始总成本。这使选择偏向于更高容量的路由，并减少了过度的 [MPP][topic multipath payments] 分片，从而提高了支付成功率。尽管这一变化过度惩罚了小通道，但与之前的过度分片相比，这种权衡是更可取的。 + +- [LND #10001][] 在生产环境中启用了 “通道静默（quiescence）” 协议（参见周报 [#332][news332 quiescence]），并添加了一个新的配置值 `--htlcswitch.quiescencetimeout`，该值指定通道可以保持静默状态的最大持续时间。该值确保依赖的协议，如[动态承诺][topic channel commitment upgrades]，在超时期限内完成。默认值为 60 秒，最小值为 30 秒。 + +{% include snippets/recap-ad.md when="2025-07-22 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32604,32618,31553,7725,2716,3628,3890,10001" %} +[LND v0.19.2-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.2-beta +[sources]: /en/internal/sources/ +[floresta v0.8.0]: https://github.com/vinteumorg/Floresta/releases/tag/v0.8.0 +[rgb blog]: https://rgb.tech/blog/release-v0-12-consensus/ +[frostsnap website]: https://frostsnap.com/ +[electrum 4.6.0]: https://github.com/spesmilo/electrum/releases/tag/4.6.0 +[news315 htlc]: /zh/newsletters/2024/08/09/#eclair-2884 +[news332 quiescence]: /zh/newsletters/2024/12/06/#lnd-8270 \ No newline at end of file From 4d60b43ca1d78ba4afb947c38b5a0356b5014562 Mon Sep 17 00:00:00 2001 From: "Zhiwei(Jeffrey) Hu" Date: Fri, 8 Aug 2025 11:15:48 +0800 Subject: [PATCH 199/278] Newsletter-364: translate into Chinese (#177) * Newsletter-364: translate into Chinese * fix link --- .../zh/newsletters/2025-07-25-newsletter.md | 91 +++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 _posts/zh/newsletters/2025-07-25-newsletter.md diff --git a/_posts/zh/newsletters/2025-07-25-newsletter.md b/_posts/zh/newsletters/2025-07-25-newsletter.md new file mode 100644 index 0000000000..51ca7113fb --- /dev/null +++ b/_posts/zh/newsletters/2025-07-25-newsletter.md @@ -0,0 +1,91 @@ +--- +title: 'Bitcoin Optech Newsletter #364' +permalink: /zh/newsletters/2025/07/25/ +name: 2025-07-25-newsletter-zh +slug: 2025-07-25-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的周报总结了影响旧版本 LND 的漏洞，描述了在使用协同签名服务时改善隐私的想法，并检视了切换到抗量子签名算法对 HD 钱包、无脚本多重签名和静默支付的影响。此外还包括我们的常规栏目：总结了 Bitcoin Stack Exchange 上的热门问答、宣布新版本和候选版本，以及对热门比特币基础设施软件的重大变更介绍。 + +## 新闻 + +- ******LND gossip 过滤器 DoS 漏洞：** Matt Morehouse 在 Delving Bitcoin 上[发布][morehouse gosvuln]了关于影响旧版本 LND 的漏洞，他之前已经[尽责披露][topic responsible disclosures]了该漏洞。攻击者可以反复请求 LND 节点的历史 gossip 消息，直到节点内存耗尽并被终止。该漏洞已在 2024 年 9 月发布的 LND 0.18.3 中修复。 + +- ******多重签名脚本的链码隐藏：** Jurvis Tan 在 Delving Bitcoin 上[发布][tan ccw]了他与 Jesse Posner 进行的研究，该研究关于改善多重签名协作托管的隐私和安全性。在典型的协作托管服务中，可能使用 2-of-3 多重签名，三个密钥分别是： + + - 用户_热密钥_，存储在联网设备上，为用户签名交易（手动或通过软件自动化）。 + + - 服务提供商热密钥，存储在提供商专门控制的独立联网设备上。该密钥只根据用户之前定义的策略签名交易，比如每天只允许花费不超过 _x_ BTC。 + + - 用户_冷密钥_，离线存储，只有在用户热密钥丢失或提供商停止签名授权交易时才使用。 + + 虽然上述配置可以显著提高安全性，但几乎总在使用的设置方法涉及用户与提供商共享用户热钱包和冷钱包的 [BIP32 扩展公钥][topic bip32]。这允许提供商检测用户钱包收到的所有资金，并跟踪这些资金的所有花费，即使用户在没有提供商协助的情况下花费。之前已经描述了几种缓解这种隐私损失的方法，但它们要么与典型使用不兼容（例如使用单独的 tapleave），要么复杂（例如需要 [MPC][]）。Tan 和 Posner 描述了一个简单的替代方案： + + - 提供商生成 BIP32 HD 扩展密钥的一半（仅密钥部分）。他们将公钥给用户。 + + - 用户生成另一半（链码）。他们保持这个私有。 + + 当接收资金时，用户可以组合两个部分来创建扩展公钥（xpub），然后像往常一样派生多重签名地址。提供商不知道链码，无法派生 xpub 或发现地址。 + + 当花费资金时，用户可以从链码派生出提供商需要与其私钥结合以创建有效签名的必要_调整值_。他们只需与提供商分享这个调整值。提供商除了知道它对从特定 scriptPubKey 收到资金的花费有效外，无法从调整值中获知到其他任何信息。 + + 一些提供商可能要求花费交易的找零输出将钱发送回相同的脚本模板。Tan 的帖子描述了如何轻松实现这一点。 + +- ******研究指出常见的比特币原语与抗量子签名算法兼容：** Jesse Posner 在 Delving Bitcoin 上[发布][posner qc]了几个研究论文链接，这些论文表明[抗量子][topic quantum resistance]签名算法提供了可比拟于当前用在比特币 [BIP32 HD 钱包][topic bip32]、[静默支付地址][topic silent payments]、[无脚本多重签名][topic multisignature]和[无脚本阈值签名][topic threshold signature]的原语。 + +## Bitcoin Stack Exchange 精选问答 + +*[Bitcoin Stack Exchange][bitcoin.se] 是 Optech 贡献者首先查找答案的地方---或者当我们有空闲时间帮助好奇或困惑的用户。在 +这个每月功能中，我们突出显示一些投票最多的问题和答案，这些答案自上次更新以来发布。* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Bitcoin Core 如何处理大于 10 个区块的重组？]({{bse}}127512) + TheCharlatan 链接到了 Bitcoin Core 的代码，该代码通过仅重新添加最多 10 个区块的交易来处理链重组。 + +- [签名设备相对于加密驱动器的优势是什么？]({{bse}}127596) + RedGrittyBrick 指出，加密驱动器上的数据可以在驱动器未加密时提取，而硬件签名设备设计用于防止这种数据提取攻击。 + +- [通过密钥路径和脚本路径花费 taproot 输出？]({{bse}}127601) + Antoine Poinsot 详细说明了如何通过 merkle 树、密钥调整值和叶子脚本来实现 taproot 的密钥路径和脚本路径花费的能力。 + +## 发布和候选版本 + +_新版本和候选版本，用于流行的比特币基础设施项目。请考虑升级到新版本或帮助测试候选版本。_ + +- [Libsecp256k1 v0.7.0][] 是这个包含兼容比特币的密码学原语的库的一个发布。它包含一些小的更改，与之前版本的 API/ABI 不兼容。 + +## 显著代码和文档变更 + +_最近在 [Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[硬件钱包接口 (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案 (BIPs)][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo]和 [BINANAs][binana repo]._ + +- [Bitcoin Core #32521][] 使多于 2500 个签名操作（sigops）的旧交易成为非标准交易，为潜在的[共识清理软分叉][topic consensus cleanup]升级做准备，该升级将在共识级别强制执行限制。如果未来的软分叉不包含此项变更，不升级的矿工可能会被轻而易举的 DoS 所攻击。请参阅周报 [#340][news340 sigops] 了解有关旧输入 sigops 限制的更多详细信息。 + +- [Bitcoin Core #31829][] 在对孤儿交易的处理程序 `TxOrphanage`（请参阅周报 [#304][news304 orphan]）中添加了资源限制，以在 DoS 垃圾交易攻击中保留机会性的单父单子（1p1c）[包中继][topic package relay]。四个限制会被强制要求：全局上限为 3,000 个孤儿交易公告（以最小化 CPU 和延迟成本）、按对等节点比例的孤儿交易公告上限、每个对等节点权重预留 24 × 400 kWU、可变全局内存上限。当任何限制超出时，节点会驱逐来自使用最多 CPU 或内存的对等节点的最早孤立公告（最高的节点 DoS 分数）。PR 还删除了 `‑maxorphantxs` 选项（默认 100），其驱逐随机公告的政策允许攻击者替换整个孤立集并使 [1p1c 中继][1p1c relay] 无用。另请参阅 [周报 #362][news362 orphan]。 + +- [LDK #3801][] 扩展了[可归因失败][topic attributable failures]到支付成功路径，记录节点持有 [HTLC][topic htlc] 的时间并向上游在属性负载中传播这些持有时间值。以前，LDK 仅跟踪失败支付的持有时间（请参阅周报 [#349][news349 attributable]）。 + +- [LDK #3842][] 扩展了其[交互式交易构建][topic dual funding]的状态机（请参阅周报 [#295][news295 dual]）以处理[拼接][topic splicing]交易中的共享输入签名协调。`TxAddInput` 消息的 `prevtx` 字段变为可选，以减少内存使用并简化验证。 + +- [BIPs #1890][] 将分隔符参数从 `+` 更改为 `-` 在 [BIP77][] 中，因为一些 HTML 2.0 URI 库将 `+` 视为空白。此外，片段参数现在必须按字典顺序排列，而不是反向，以简化异步 [payjoin][topic payjoin] 协议。 + +- [BOLTs #1232][] 使 `channel_type` 字段（请参阅周报 [#165][news165 type]）在打开通道时成为必需，因为每个实现都强制执行它。此 PR 还更新了 [BOLT9][] ，通过添加一个新的上下文类型 `T` 来包含可以包含在 `channel_type` 字段中的功能。 + +{% include snippets/recap-ad.md when="2025-07-29 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32521,31829,3801,3842,1890,1232" %} +[morehouse gosvuln]: https://delvingbitcoin.org/t/disclosure-lnd-gossip-timestamp-filter-dos/1859 +[tan ccw]: https://delvingbitcoin.org/t/chain-code-delegation-private-access-control-for-bitcoin-keys/1837 +[mpc]: https://zh.wikipedia.org/wiki/%E5%AE%89%E5%85%A8%E5%A4%9A%E6%96%B9%E8%AE%A1%E7%AE%97 +[posner qc]: https://delvingbitcoin.org/t/post-quantum-hd-wallets-silent-payments-key-aggregation-and-threshold-signatures/1854 +[Libsecp256k1 v0.7.0]: https://github.com/bitcoin-core/secp256k1/releases/tag/v0.7.0 +[news340 sigops]: /zh/newsletters/2025/02/07/#introduce-legacy-input-sigops-limit-sigops +[news304 orphan]: /zh/newsletters/2024/05/24/#bitcoin-core-30000 +[1p1c relay]: /zh/bitcoin-core-28-wallet-integration-guide/#一父一子交易1p1c中继 +[news349 attributable]: /zh/newsletters/2025/04/11/#ldk-2256 +[news295 dual]: /zh/newsletters/2024/03/27/#ldk-2419 +[news165 type]: /zh/newsletters/2021/09/08/#bolts-880 +[news362 orphan]: /zh/newsletters/2025/07/11/#bitcoin-core-rp-审核俱乐部 From c494c25af58771ccc1fd0f2e1a1764cdf0650c4e Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Sun, 10 Aug 2025 07:31:23 -0500 Subject: [PATCH 200/278] Podcast: add 365 transcription --- .../en/podcast/2025-08-05-newsletter-recap.md | 1505 ++++++++++++++++- 1 file changed, 1504 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-08-05-newsletter-recap.md b/_posts/en/podcast/2025-08-05-newsletter-recap.md index 43bda6578e..13ed0cde3a 100644 --- a/_posts/en/podcast/2025-08-05-newsletter-recap.md +++ b/_posts/en/podcast/2025-08-05-newsletter-recap.md @@ -19,6 +19,1509 @@ Shareshian, Jameson Lopp, Steven Roose, and Tim Ruffing to discuss [Newsletter # ## Transcription -_transcription coming soon_ +**Mike Schmidt**: Welcome everyone to Bitcoin Optech Newsletter #365 Recap. +Today, we're going to talk about research into compact block performance, fee +estimation using just the mempool, and we have our monthly segment on Changing +consensus that is going to cover a couple of quantum discussions, the idea of +longer timelocks, and the OP_TEMPLATEHASH proposal. Murch and I are joined this +week by David Gumberg. David, you want to introduce yourself? + +**David Gumberg**: Hi, I'm David Gumberg, I work at Localhost Research on +Bitcoin Core. + +**Mike Schmidt**: Jameson? + +**Jameson Lopp**: Hi, I do Bitcoin stuff. + +**Mike Schmidt**: You're on the right podcast then. Steven? + +**Steven Roose**: Hi, I'm Steven Roose, I'm building Ark at Second. + +**Mike Schmidt**: Tim? + +**Tim Ruffing**: Hi, I'm an applied cryptographer at Blockstream, working on all +kinds of cryptography stuff in Bitcoin. + +_Taproot-native `OP_TEMPLATEHASH` proposal_ + +**Mike Schmidt**: Great of you all to join us, thank you for your time. If +you're following along with the newsletter at home, we're going to go a little +bit out of order in deference to our guests in different time zones. So, we're +going to jump into the Changing consensus segment, and we're going to talk +about, "Taproot-native OP_TEMPLATEHASH proposal". Greg Sanders posted to the +Bitcoin-Dev mailing list about a software proposal he's been working on with +Antoine Poinsot and Steven Roose. Steven's joined us today to explain the +proposal. Steven, at first glance this looks like the CTV +(OP_CHECKTEMPLATEVERIFY) and CSFS (OP_CHECKSIGFROMSTACK) proposal that's been +batted around recently, but with OP_INTERNALKAY added. Or similarly, the +LNHANCE proposal with the OP_PAIR commit removed. Is that an oversimplification +and maybe we can get into some of the deltas? + +**Steven Roose**: I think that's more or less correct, yes. Yeah, you can go +ahead if you want to give more intro, or I can go. + +**Mike Schmidt**: No, I think that's good. I mean, that's just how I see some +of the discussions at a high level going, but I think maybe you can help educate +us on why a variant of both of those is maybe the preferred route in your +opinion. + +**Steven Roose**: Yeah. So, I think it boils down to two major motivations. +One of them was that we wanted to limit the effect that future soft forks have +on legacy scripting capabilities, and we wanted to limit all our functionality +to just the tapscript context, which has already some other issues resolved that +the other script contexts would have. So, then the OP_TEMPLATEHASH opcode would +only work in the tapscript context, just as the other ones that we're proposing. +And instead of checking a hash, which is what you only can do if you're +replacing an OP_NOP, we can actually directly put the template hash on the +stack, which then comes to the second motivation, making it a lot more efficient +to do re-bindable signatures. So, re-bindable signatures originally come from +the APO, or ANYPREVOUT proposal, and you can do re-bindable signatures using CTV +and CSFS directly, but you would have to post a public key on the stack and you +would have to post a CTV hash on the stack, or in your witness, which would cost +you something like 66 bytes. + +So, with this change proposal, you don't have to put those things on the stack, +you don't have to provide them in the witness, but you can get them on the stack +directly from the script. So, you can get your internal key, which saves you 33 +bytes, and you can get your template hash, which saves you 33 bytes. So, I +think that's the in-a-nutshell summary of the improvements that we're trying to +make, mostly based on feedback from talking with various people over the last +few months. + +**Mike Schmidt**: For that first motivation, Steven, is the reason to not have +it in multiple script context just a maintenance thing, or help us understand +why only in tapscript? + +**Steven Roose**: Well, I mean first of all, it helps us have INTERNALKEY and +TEMPLATEHASH, right, which otherwise we wouldn't have; but also, the other +script contexts are kind of a lot harder to reason about because they have very +weird limitations on how you can abuse things in weird ways, while the tapscript +context already has like a lot more sanity limitations put in place. Segwit +also has more than legacies, so we've been improving over time and extending the +things you can do with this legacy context just opens up a whole, like, giant +review surface of how this can be exploited, given the low limitations or +constraints that these contexts already have. So, I think the tendency that +we're trying to do, also with the consensus cleanup, is to even further limit +those legacy contexts just to prevent abuse. Of course, we cannot deprecate +them because people are still using them, but we want to keep supporting the +legacy, like the actual use cases of this context, but then restrain people that +can potentially use them for abusing validation time of nodes, and stuff like +that. + +So, just limiting the scope to tapscript makes it a lot easier to reason about, +like this is exactly what you can do. This is the context that everyone's kind +of thinking and reasoning about lately, and then we don't have to go back in +time and say like, "Oh, yeah, but in this context, we don't have this +limitation", so, then maybe we can do stuff like this. I think that's mostly +the motivation. Also, we shouldn't be providing motivations for people to go +again, use the old context, right? Tapscript should be the most modern version +of Bitcoin Script and it should be what people should be using for building +their applications on Bitcoin. If there's issues with taproot and things that +people want to have from the previous context, maybe we should think about that +and then maybe iterate and improve further. + +**Mike Schmidt**: Well, what is lost by removing it from legacy script? I +think, was there some discussion of the congestion control idea being less +efficient? Is that the main thing? + +**Steven Roose**: Yeah, so there's two things. One thing is the congestion +control thing. I spent an entire conference asking people if they could come up +with good reasons to have congestion control, or to have bare CTV basically, and +the only reason was congestion control. And I haven't really felt much +enthusiasm around the congestion-control idea. I don't think it will be very +useful. It's still possible to do with this latest proposal, but it's just +going to be a little bit more costly. But I don't really see why application +developers would want to use congestion control. The second thing that you can +do is this weird trick that the BitVM people figured out, using some weird +convoluted hack with the scriptSig and P2SH, to somehow commit a certain piece +of scriptSig into your template hash, or to commit to certain inputs by +committing to the scriptSig that it's going to have to put into the input, so +that one of the BitVM transactions can actually commit to the input that's going +to be used alongside. Yeah, I mean I would prefer not to motivate that +specifically, but it's a very ugly trick that they came up with. They were +definitely not using the opcodes the way that they were intended to. + +So, obviously input commitments are useful and we should do them in a way that +is meant for them and not find some weird ugly hack, because scriptSigs are +something that shouldn't be used anymore and are obviously deprecated in +tapscript context. + +**Jameson Lopp**: You're saying we shouldn't be tricking the nodes? + +**Steven Roose**: Exactly. So, I mean it's not like we kicked this out, it's +just that scriptSigs are just not allowed in tapscript context. So, if you're +using this -- well, no, I mean in theory you could have a scriptSig on the other +one, but we're just not committing to them. Yeah, no further comment, I guess. + +**Mike Schmidt**: I think this proposal commits to the taproot annex, which CTV +does not. + +**Steven Roose**: Oh, yes. + +**Mike Schmidt**: What are the implications of that? + +**Steven Roose**: Yeah, that's a good other thing that I forgot to mention. So, +we're also committing to the annex. Basically, because we went back to the +drawing boards with a new opcode, we could just revisit what CTV was committing +to. And we also considered, for example, the input amounts. But there's some +problems with that that could make funds get black-holed if you do something +silly or something not entirely correct, and there doesn't seem to be much +benefit for the annex, yeah. So, the annex is a new thing that was introduced +with Taproot, and it doesn't really have any use cases yet, other than putting +JPEGs. But since all the current tapscript signature hashes are committing to +the annex, it seems like the purpose of the annex in the future will be that it +should be for data that should be committed in some way, because everything else +is also committing to it. So, then it seems logical that any committing to a +next transaction scheme or any re-bindable signature scheme would also commit to +the annex so that it's compatible with any future upgrade that we will give, or +any future meaning we will give to the annex. + +I think some people are using the annex for proof of concepts of LN-Symmetry, +where they're putting some extra data, and I think for that it would be +beneficial if it was committed as well. + +**Mark Erhardt**: Have you gotten any feedback from the prior CTV proponents? +How is it going over? + +**Steven Roose**: Well, my memory is failing me for most of what's happening on +the mailing-list thread. I think most of the feedback was, "Well, but CTV could +do the same thing". But I guess the responses were not saying that the things +that were proposed until now were not useful, we're just trying to incrementally +improve them a little bit. I think most of the feedback was kind of normal and +as we expected, like, "This is just a better version. Let's just keep +improving". We also -- well, I'm saying we; Greg and Antoine did a lot of work +in doing the test, like a lot of functional tests in the Bitcoin framework to +see the interactions of the different pieces that are committed. So, yeah, I +think the work is being continued. We're talking with some people to change the +LN-Symmetry proof of concepts to using this proposal. I'm currently quite busy +with trying to ship our Ark implementation for mainnet, but we're also thinking +of doing a proof of concept of one of those new Ark designs, like hArk and Erk, +using this proposal. So, yeah, I think the work is just continuing, reviewing +the latest and trying to see how it can be used in applications. + +**Mike Schmidt**: Steven, anything else on this item before we wrap up? + +**Steven Roose**: I don't think so. + +**Mike Schmidt**: Okay. Oh, Murch has something. + +**Mark Erhardt**: Actually, so we talked a little bit about how having native +CTV would have allowed congestion control. I think that there was also a +proposal of introducing a new output type, like a native CTV, if that was really +desired. So, that would get the efficiency that adding it to legacy would have +done, is that right, or what is the idea there? + +**Steven Roose**: Yeah, we pondered the idea of having an additional output type +that does direct CTV, but we were ourselves not convinced that it was useful. +But I think we wrote some kind of draft BIP how it could be designed, and then +we just put it out there and said, "If people think this is very useful, people +really want this, they should provide some motivation and really support for why +we should have it", but ourselves, we're not convinced. + +**Mike Schmidt**: All right. Well, if you're interested in the proposal, check +out the mailing-list discussion. There's been a good amount of back and forth, +including Rearden Code, who was a champion of LNHANCE, which has had some +similarities, saying good things about this proposal. So, opine on that so we +can move along or not accordingly. And we'll move along. + +_Proposal to allow longer relative timelocks_ + +Steven, we have another item that you had commented on that we don't have a +guest for titled, "Proposal to allow longer relative timelocks", and this was +based on a Delving Post by user Pyth, suggesting that that BIP68 relative +timelocks could be extended from what they are today, with a max of about a +year, to a new maximum of about ten years. Pyth mentioned that the motivation +for his post was feedback that he saw from Liana Wallet users, that were +wondering why the limit exists and saying that they wanted longer limits. And +if I understand correctly, Liana has sort of a degrading multisig approach to +their wallets, which can allow things like inheritance. But I think also, that +means you need to roll the coins over periodically. So, I think that's probably +some of the pushback from that particular user base. I think Blockstream does +something similar with the federation funds as well. Go ahead, Murch. + +**Mark Erhardt**: Yeah, so I think what they do is that the user with the +service can spend it immediately, but then when the user loses access to some of +their keys, there is a fallback with fewer of the user keys and the service to +recover. And then, there's a long-term recovery, where only the service can +recover it in case the user loses access to all of their key material. And I +think especially that last one would be interesting to push out further than one +year. + +**Jameson Lopp**: Yeah. I mean, I have a lot of thoughts on this because I want +to say I started talking about the issues of practical implementation of +timelocks in 2020. I gave a talk at MIT, specifically entitled, "The problems +of non-deterministic data in Bitcoin Script and all of the follow-on effects of +that". What that was really getting at though is that you have two different +forms of timelocks, if we're about actually preventing money from being spent +until certain conditions or a certain time has passed. You've got your absolute +timelocks, where you put an actual timestamp or block height, and there's really +no limitations to that. You could timelock your coins to a block height that's +100 years in the future, though I would recommend against doing that for a +variety of reasons; or the relative timelock, which basically says, "Okay, +whatever block height at which this UTXO was created, you cannot spend it until +so many other blocks have gone past", and I think that it's roughly 18 months, +is the current max of relative timelocks. + +So, the downside of using an absolute timelock is that you essentially break +having a deterministic wallet. And what I mean from that is you're putting some +number into your descriptor for your wallet. And that's all fine and well until +you want to change whatever that lock is. You essentially have to create a +whole other logical wallet, which will have a different wallet descriptor, and +this starts making backing up your wallets more onerous. It starts hearkening +us back to the days when we would have to regularly back up our wallets. So, if +you were changing your locktime every so often to push it out further, that +would become a problem. But then, the flip side is with these relative +timelocks, as you said, you have to start churning the UTXOs whenever that +happens. + +The problem with both of these is that it basically makes the wallet more +interactive from the user perspective. On one side, it's more interactive +because you have to start backing it up more; on the other side, it's more +interactive because you have to start rolling your UTXOs. Now, I think that we +should allow more than 18-month timelocks, but I do think that going beyond +probably 5 to 10 years is when things get dicey. And this actually kind of +rolls into what we'll talk about later with quantum computing, or just general +existential threats to the ecosystem that might require people to move their +money faster than that. + +**Tim Ruffing**: I wonder why this limit was introduced or is even there. I +mean, I have no idea, but does anyone know? + +**Jameson Lopp**: I think the limit has to be with how many bytes are being +used, right? + +**Steven Roose**: Okay, yeah. It's just because you can't express the number +in… + +**Tim Ruffing**: Yeah. I think it's a purely technical limitation. + +**Mark Erhardt**: Yeah. It's 65,575, or whatever. + +**Tim Ruffing**: Yeah, okay. I tend to agree that 18 months is not a lot. + +**Mike Schmidt**: But really, it just came down to how many bits of the end +sequence were going to be hijacked for this purpose, I guess. + +**Steven Roose**: Yeah, exactly. + +**Mike Schmidt**: Steven, what were your comments on the Delving thread? What +are your thoughts on this? + +**Steven Roose**: I think the proposal was actually very well put out. So, the +way the nSequence field works is, so what you do when you express a relative +timelock is you add a certain value to your input. And then, that value will +express how much time needs to have passed since the coin that you're spending +has existed, has been created. And currently, we allocated the first 16 bits, I +think, to be an indicator of how the other 16 bits should be interpreted. And +then, the only mod that we actually created for that was that the other 16 bits +would be created, it would be number of blocks or a timestamp, something like +that. So, that that made the limitation to be the 16 bits. And what the +proposal just proposed is to use another of the bits in the first 16 to +indicate, use the last 16 bits but multiply it with 8 so that you only have a +granularity of 8, so you can only do 8, 16, 32, stuff like that. But then you +can go 8 times as far. + +So, the design is very simple. It's very similar to how the relative timelock +works right now, it's just that if a user specifies a certain amount of years, +you will just have to round instead of to a block, which is 10 minutes to 8 +blocks, which is 80 minutes. And the questions are there, like what multipliers +should we use? Obviously, multipliers of powers of 2 are cheaper or easier to +implement, so he could have chosen 4, 8, 16. I think 8 is kind of a sweet spot +where we get to around 10 years, slightly over 10 years. It could have been 20 +years if we doubled it again. Another technical question that I mentioned was +if you just say that in the new scheme, you multiply by 8, in the old scheme, +you just multiply by 1, you just take the normal number. That means that for +all the multiples of 8 within the first year, you have two different options to +represent the new timelock, right? You can either use the old version or the +new version. + +So, one way to avoid this ambiguity is to just only allow the longer scheme +beyond the first 18 months. So, then we could actually go to 11 or 12 years. +But his argument against this approach was that if you do it like this, both of +the two schemes have to coexist still in all our code bases, otherwise we could +just deprecate or totally forget about the old scheme and only use the new +scheme. So, there's arguments on both sides, I don't really have a strong +opinion there. But yeah, I think the proposal was fairly straightforward and +clean, and I think it makes total sense. I don't think there's any danger. I +mean, the argument that you can lock up your coins for too long and it can be +dangerous for quantum-related things, it's kind of a difficult argument to make +because you can already do it. Like Jameson mentioned, you can already put an +absolute timelock somewhere 100 years in the future. Obviously, not many people +are doing that, while if people are going to be very customarily putting things +15 years or 10 years in the future, it could become a little bit more cumbersome +to actually deal with people practically doing these things. But I think that's +up to the wallet implementers to guide their users to pick sane values, by +basically either just limiting it for them or putting some warning if they go +beyond 10 years, or something like that. I think those are just UX arguments, +not really protocol arguments. + +**Mark Erhardt**: Thanks. Could you repeat again? So, a single bit would be +used to indicate whether the rest of the 16 bits are interpreted with a factor 8 +or not, was that what you said, or does it add bits? + +**Steven Roose**: No, I don't think it adds bits. It just does the same +division where half of it is the actual value and the other half is the bit +flags. And then it just picks another bit flag in the first half and then +reassigns the value of the latter half. I think it's like that. + +**Mark Erhardt**: Oh, so the first 8 bits would be whether something is +multiplied in the rest of the bits. I'm not sure I entirely fully understood. + +**Steven Roose**: Aren't sequences 32 bits? + +**Mark Erhardt**: Oh, you are right. Yes, of course. + +**Steven Roose**: Yeah. So, we have 16-bit values, which is why we can go up +to, I think, 65,000. + +**Mark Erhardt**: Right, okay. Yeah. So, correction on the times 65,535 blocks +for the block-based one and 65,535 times 512 seconds. And the former, the +block-based one, is about 455 days and the latter one is about 388 days. So, +it's about 15 months in the block-based one and 12.5 months for the time-based +one. + +**Steven Roose**: These are the old ones, right? Yeah. So, then you would just +multiply by 8 for the new proposed mechanism. I don't think I have much more to +add. + +**Mike Schmidt**: We can move along. Steven, thanks for joining us, we +appreciate your time. + +**Steven Roose**: Yeah, thanks for scheduling me first! + +_Security against quantum computers with taproot as a commitment scheme_ + +**Mike Schmidt**: No problem. "Security against quantum computers with taproot +as a commitment scheme". Tim, you posted to the Bitcoin-Dev mailing list an +email titled, "Taproot is post-quantum secure when restricted to script-path +spends", and maybe one quote I'll pull out to kick things off here is, "It +appears to be a common assumption on this list that an attacker can't break +scriptpath spends, but I'm not aware that a convincing justification for this +assumption has been presented by anyone before". So, I threw that out there, +that's sort of the framing. So, yeah, I mean, there was a Quantum Summit a few +weeks ago and I think, yeah, your quote sort of embodies that, that the +assumption was that scriptpath spends can't be broken by a quantum attacker. +But you've done some rigor around that analysis. Do you want to talk about +that? + +**Tim Ruffing**: Right. So, I think your introduction is pretty much to the +point. So, I mean if we want to upgrade to post-quantum signatures, there's at +least one thing we need to do at some point. We need to add support for those +post-quantum signatures somewhere, right? This is the obvious part. And then, +maybe in a second step, and I think we need to do this and I know at least +Jameson here also thinks there needs to be a second step, where we disable ECDSA +and schnorr signatures, or spending using ECDSA and schnorr signatures, or the +old, in a sense, the legacy at that point, discrete-logarithm-based schemes, +because at some point they will be insecure, assuming that there will be a +sufficiently powerful quantum computer. Why we need to do this is more like a +social or philosophical or monetary question maybe. But I think I don't want to +go into that discussion here too much, I think, but I just want to refer to +Jameson's great blogpost, I think. Feel free to chime in. But yeah, I don't +think a world where someone with a quantum computer can just steal all the coins +is a great world for Bitcoin. So, let's maybe assume for now we need these two +steps. We need to introduce post-quantum signature support, then give some time +for people to move their coins to post-quantum UTXOs, or at least UTXOs that +would support post-quantum signature spending. And then, at some point later, +hopefully before large quantum computers are available, we disable spending +using discrete logarithm signatures. + +One way to do this, or to do this first step of adding quantum signature support +is to add it within tapscript. And this idea, I think it's kind of one of the +obvious ways to do it, and this idea has been floating around, it has been +spelled out explicitly by Matt Corallo, I think, earlier this year or even the +end of last year on Bitcoin Dev. If you ask me, the advantage of this approach +is that the entire ecosystem can continue using taproot for a while. We can +keep the nice benefits of taproot. Schnorr signatures, they're short, they're +compact. We have multisigs, maybe I'm a bit biased here. But yeah, we created +all these nice things and we want to keep using them for a bit. And in +particular, this gives us more time to do research and experimentation and +development, and whatever, on post-quantum solutions, because if you look at the +research side, we have some post-quantum signature schemes now, but they have +huge signature sizes, they have huge public keys maybe. Okay, you could hash +them, but everything is a bit less efficient or extremely less efficient +depending on your point of view. And also, they lack a lot of advanced +functionality, like multisigs, for example, or public derivation is a hard thing +to do. + +So, the idea would be, if you took that approach, the idea is you add +post-quantum signature support now by adding opcodes to tapscript, +CHECKSIGPOSTQUANTUMVERIFY maybe, something like that. So, you have opcodes for +that in tapscript. And then, if you now receive new coins, you can still +continue using schnorr-based keypath spends for a while, but you also commit to +a script in your tapscript tree that enables spending via post-quantum +signature. And this means that essentially you have a fallback. So, if now, at +this point, we would keep all spending, or spending using ECDSA and schnorr, +then you could pull out that script and then do scriptpath spends using a +post-quantum signature. And yeah, this was the long introduction. + +But what the paper now basically shows is just that this approach is secure. +So, even if at that point, if you disabled the DL-based spending because we +think there is a sufficiently large quantum computer, we know that, of course at +this point, the quantum computer can't break keypath spends anymore just because +they're disabled. But also, what the paper shows is that, and hopefully with +some rigor, that the attacker at that point can't break scriptpath spends. What +would it mean to break a scriptpath spend? Well, one obvious way is to break +the bindingness of what I call the taproot commitment, so basically, take your +auto key and open it to some merkle root or to some script that wasn't even in +there. And this of course would be very bad, right? If I can open your taproot +UTXO, your taproot outputs to any script I want, then I can impose any +conditions so I could spend it and just steal it. + +So far, I think people have assumed that this is kind of secure because it uses +hash functions, and hash functions tend to be post-quantum secure. But I felt +the need to have really rigorous arguments, because I believe in improvable +security. And I think if we make cryptographic changes to Bitcoin, we should +have various kinds of evidence that they're secure. And one kind of evidence is +cryptographic security proof. + +**Jameson Lopp**: Now, I guess is it fair to say, it's secure against long range +attacks as long as the funds haven't been spent, right? + +**Tim Ruffing**: I think that's fair, but I wouldn't see why it wouldn't be +secure against short-range attacks also. + +**Mark Erhardt**: Well, with address reuse. + +**Jameson Lopp**: Yeah. Well, once you spend the funds, you're exposing +everything about the scriptpath spender. + +**Tim Ruffing**: Yeah, okay. In a world where you don't disable DL-based +spending, you say? Because my working assumption is now that at some point in +the future, you will disable spending via schnorr signatures or spending via +ECDSA, and then it doesn't really matter if you revealed your public key before, +because breaking it isn't worth anything for the attacker. + +**Jameson Lopp**: Gotcha. + +**Tim Ruffing**: But right, if you don't do this, then I think your conclusion +makes sense, yeah. + +**Mark Erhardt**: Right. So, you talked a little bit about your idea how we +could introduce post-quantum secure signature schemes, but I wanted to put it +into the broader context. So, BIP360 has been a proposal that has been evolving +over the last year or so, and the latest iteration is that BIP360 proposes now a +new output scheme that would be very similar to taproot, but essentially only +have a scriptpath spending way and remove the keypath spending. It would make +the scriptpath spending slightly more efficient, but that would allow users to +continue using tapscript in this new output scheme, and then in parallel, also +add leaves to their tree, which are post-quantum safe. So, they would have a +way of spending, even after cryptographically-relevant quantum computers arrive, +a way of spending with the post-quantum signatures. But before that, they could +use the scriptpath spend, which would still be bigger than a keypath spend in +taproot, but it would be much more block-space efficient than the post-quantum +signature schemes, which are humongous in comparison. Currently, something like +the smallest are 50 times bigger or so than what we're using right now. + +So, you're saying, why not just put it into tapscript directly and allow P2TR to +have post-quantum signature schemes, and then users could on their own time do +the same thing. They'd create new outputs that under the hood have both +scriptpath spending leaves with post-quantum security and without. And then, +once cryptographically-relevant quantum computers arrive, we disable the keypath +spending on P2TR, and then people would be able to just start using the +post-quantum-safe leaves. + +One thing that has come up in this context is that people have been complaining, +"Oh, but then you can't see how much coins are post-quantum save or not, because +it's actually hidden under the hood". And some people have been arguing, +"That's the point. We don't want outputs to look differently". Others have +been arguing, "But it would make it very easy to have a different output type so +we know what outputs to lock for good". + +**Tim Ruffing**: I think that's kind of an orthogonal question at least. I +mean, in terms of privacy, you can always voluntarily review data, right? I +think your description is very accurate of that approach, but even in that +approach, if you want to add a flag to the new UTXOs, of course you can do it by +setting a bit or by increasing the taproot version, or something like that. +Yeah, indeed. + +**Mark Erhardt**: Right. Yeah, so you're saying this is obviously not +necessarily something you have to decide, but I think it's very interesting in +the context of BIP360 that you're saying, "Well, we can just do it in taproot. +It's slightly less efficient on the scriptpaths for block space, but other than +that, we get it immediately with P2TR already. It would be a smaller soft fork +maybe. And the security proof, of course, is very welcome. + +**Tim Ruffing**: Yeah, I think that's a very accurate description. And in that +sense, the BIP360 proposal, at least the updated version, isn't too far from my, +I wouldn't call it my proposal, but from the upgrade path I had mentioned. It's +just that I think if you have taproot keypath spending now, why disable it now +if you can prove that it's secure? And one maybe governance kind of argument is +that I think at the moment, there are many proposals and there's not so much +pressure. I mean, post-quantum is now a topic everyone talks about, but I feel +like some external pressure could be necessary to actually agree on a soft fork +or even on a hard fork, or whatever upgrade we want to do in the future. And +this may sound a bit stupid, but this is an argument to procrastinate on this, +because if we keep using the stuff we currently can do, then this allows for +pressure to build up, and this will maybe make it easier in the future to agree +on a change, just because then we are all in the same boat in the end and some +change is better than no change. + +**Mark Erhardt**: Jameson, you've been thinking a lot about post-quantum +security lately, and I think you've been at least building your proposal on the +idea that sending to P2TR and other quantum-vulnerable output types would be +restricted first. So, having a distinct output type for the post-quantum safe +scripts would be helpful in introducing that step. Do you have comments at this +point? + +**Jameson Lopp**: Yeah, from that perspective, I think it would be preferable if +you want to have a more gradual migration. Really, what I've been thinking +about for the past five months or so is more of just the game theory of all of +this. I was thinking about the philosophy and morality stuff as well, but +ultimately my conclusion that I ended up writing up back in March was that it's +the game theory and then the incentives that I think are going to matter the +most. And there will be a lot of conflict because of ideological clashes and +the fact that one way or another, if quantum computing ends up posing a real +threat, there will be a violation of properties of Bitcoin that people consider +to be inviolable. So, I'm not a cryptographer and I'm not opining upon how long +we have. I'm also not a quantum computing expert. All I know is that the +general interest in quantum computing and advancing quantum computing seems to +be picking up. And I know that the ability to upgrade Bitcoin and coordinate is +becoming harder and harder, and the process of doing so is becoming slower and +slower. And just the divergence of those two things is what causes me concern. + +So, if we're talking about a problem that may not arise for a decade or longer, +I think it's still prudent to start talking about how we might approach this +problem because it's going to be a huge coordination nightmare, especially +because it would be unprecedented in the sense that we've never had a protocol +change before that required people to actually move their money to change the +properties by which they were locking their money. And that's why the BIP that +I have been working on is not so much about the cryptography because, quite +frankly, as Tim said, a lot of the current options are pretty terrible, and +hopefully we can develop better ones before it becomes an issue. But it's +really more about how we would go about creating incentives in game theory that +are the best possible outcome for having to go through this process. + +**Mark Erhardt**: Let me jump in real quick. So, we were talking about the +security against quantum computers with Tim, and we've sort of gradually segued +now into the other changing consensus topic by Jameson, which is a new BIP about +migration from quantum-vulnerable outputs. So, I just wanted to quickly give +Tim a chance. Did you have any wrap up that you wanted to add to your topic, +because then we'll start with Jameson's. + +**Tim Ruffing**: No, nothing really from my side. I think in particular, your +last summary was very accurate, but just let me add one comment to what Jameson +said. It's interesting that you said you're not a cryptographer and then you +added you're not a quantum computing expert, because that's what I always say, +"People, don't ask the cryptographers!" I mean, they're the wrong people to +make predictions. But anyway, I believe it's very hard to predict the future +that holds for everyone, including cryptographers and quantum computer +researchers and engineers. + +**Mark Erhardt**: All right. Thank you. + +**Mike Schmidt**: One quick tangent for you, Tim, before we move on. You +referenced BlueMatt's post at the end of last year titled, "Trivial QC +signatures with clean upgrade path", where he suggests that you could +essentially have the scriptpath and if things go awry with quantum, then you +could use that as a quantum spendable if the keypath is disabled. Does this +quantum signature scheme need to be decided before something like that hook is +made available, or could the semantics of such a scriptpath hook be agreed upon +and then the particular scheme implemented later? + +**Tim Ruffing**: Yeah, I think that's another one of the hard questions. I +think from purely a technical point of view, what you could do is just decide on +a public key type now. So, maybe take a hash-based scheme. Of course, if you +look at the signature scheme, it comes with a key generation algorithm, comes +with assigning algorithms, comes with a verification algorithm. But in +practice, if you improve schemes because there's more research, and so on, what +you typically improve is how verification works, how a signature looks maybe, +but not how the public key looks. So, there might be a possibility to say, from +a technical point of view, "Okay, we just commit to a key that looks like this". +And maybe currently, there is some scheme there, but we could hope for further +improvements in the future, so that at the point when we actually have to +produce signatures, the scheme or the techniques behind it have been improved. +But that's vague in various ways. So, it's already vague when I say it, because +it depends on future improvements. + +In a sense, maybe this goes into too much detail, but also I think it varies a +bit depending on what cryptographic assumptions you want to use. The key for a +hash-based scheme is probably the root of some kind of merkle-tree-like thing. +And here, the tree structure really depends on what you can do with the +signature. So, you probably, if you use a hash-based scheme, it doesn't really +make sense to leave the scheme unspecified. It could make more sense in other +types of signatures, maybe lattice-based or zero-knowledge-based signatures, +because there you have just more flexibility to play around with the signature +algorithm and make improvements in the future. + +But just from a maybe implementation or confidence user perspective point of +view, I think if we add a way now to commit to post-quantum public keys, we +should also enable a way to give post-quantum signatures on the chain, because +otherwise it's not really convincing to the ecosystem, right? It's like, okay, +there is some way to commit on a key and I could even do this now. I mean, I +can have a hidden script in my tree that I don't reveal. So, we don't need any +consensus change at all to do this now. But that's exactly the problem, because +if I start doing that now, it's just my hope that the ecosystem will converge on +my methods, and I think this is just too vague. So, I think just from that +point of view, it just totally makes sense to, if we add the scheme now, we also +implement it and fully activate it so people could use it if they really want +to. + +But there's one thing I may want to add. There could be some way in between +where we say, okay, some of these particular hash-based schemes, which are +conservative, are few-times signature schemes. So, we can give a few +signatures, maybe let's say 8 or 16, or something like that, and after you have +created this many number of signatures using your private key, you can't create +any more signatures without losing security. We could do something like this to +maybe say, okay, maybe we commit in a way that we have an 8-time signature +scheme where you can do 8 signatures, and then you have 8 slots that you reserve +for future schemes that you can add to Bitcoin and you just delegate to those +schemes. So, maybe we add the 8-time signature scheme; maybe in one slot, we +already now add something like SPHINCS+, just to name one thing that is kind of +pretty conservative; but then we could say, okay, in the future, we now have +another scheme that we are confident in and that we like, and we add this to +basically the second slot. And then, what users then could do is just to use +this 8-time signature scheme in the future to sign a public key of the second +slot scheme. And basically, we have 8 slots, we have a few chances to improve +or get things wrong. + +This is just a vague idea that I had in my mind. I may want to spell this out +in the future, but this might be a middle way. + +**Mark Erhardt**: Yeah, Tim, I was going to say you're creating proposals here +on the fly. How about you write some of them up? I hear we have currently four +quantum-related BIPs, or five even, at various degrees of maturity. We +absolutely need more competition. + +**Tim Ruffing**: I agree. + +_Migration from quantum-vulnerable outputs_ + +**Mark Erhardt**: All right. I think we've delved quite deeply into this topic. +Thank you, Tim, for joining us. I hope you feel better soon. And then, sorry +for putting you back on the back burner, Jameson, I think we're going to dive +into your proposal now. We sort of had an introduction already, but, Mike, did +you have something prepared that you wanted to say? + +**Mike Schmidt**: Just a quick one. Jameson, you posted a post-quantum +migration proposal to the Bitcoin-Dev mailing list. What is your three-step +plan? + +**Jameson Lopp**: Right. So, I'm skipping the hard part here, which is actually +getting consensus to determine that quantum computing is a sufficient threat +that we need post-quantum cryptography, and then bike-shedding over which +post-quantum signature scheme is the least terrible. And I'm instead looking +forward and saying, okay, this BIP is going to start under the assumption that +we have done that, that we have implemented post-quantum cryptography. How do +we then deal with all of the incentive issues to get people to migrate, because +this is an unprecedented problem where we've never had a protocol change before +that is done under the assumption that people need to adopt it as quickly as +possible for their own safety and for the security of the ecosystem at large? +So, essentially this says, okay, we've activated some post-quantum scheme. What +do we then do with regard to making the migration more gradual and palatable, +and understanding that there's no way to email every Bitcoin user, there's no +way to message everyone who's using Bitcoin saying, "Hey, you need to upgrade +the security of your funds". + +So, I figure the first step that makes sense towards this type of migration +would be that we only really allow for funds to be spent out of legacy scripts +to a quantum-secure output. So, basically that means at some point, say several +years, we're saying three years is the suggestion after we activate this +post-quantum cryptography, and we give people those three years to start +implementing it essentially for the protocol change to matriculate throughout +the ecosystem; and then, at the three-year mark, if you are sending money to +what would be considered a quantum-vulnerable output type, then we reject that, +we just don't allow that transaction to happen. The idea being that if someone +is trying to send money and their bitcoin transactions are getting rejected, +that is going to essentially force them to educate themselves as to what is +going on, and then they will understand the incentives around why they need to +upgrade their security. + +So then, more controversially, we're suggesting that two years after that, so +five years after activating post-quantum cryptography, that we then start +rejecting any transactions that are spending funds out of a quantum-vulnerable +script. So, current idea being that we essentially look for any of the opcodes +that are using ECDSA, like OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, so +on and so forth, and of course this is arguably the most controversial aspect of +this proposal, because this would essentially prevent people from being able to +spend money if they had not upgraded it. So, in an attempt to remediate that, +and this is where more research and development is going to be required, is can +we then have a third step, preferably a third step that activates at the same +time as the second phase, which is that we do allow people with +quantum-vulnerable funds to spend their money if they also provide some +additional quantum-safe proof that the funds belong to them and have not been +reverse-engineered by an attacker. + +There's a variety of ways that this could occur. The one that we were leaning +towards is maybe some sort of zero-knowledge proof. But essentially, I think +that whatever proof it would end up being, it would essentially have to be a +proof that you have a hierarchical deterministic wallet and that you are able to +independently derive the private key that you're spending from, from a root +private key. So, that's going to require additional research to figure out how +feasible it is, but it certainly seems theoretically possible. And that would +allow us to somewhat remediate the issue that there still could be people that +get locked out of their funds in the long term. Essentially, this would still +likely create the permanent locking of any really, really, really old, non-HD +wallet funds, because there's just no other data that exists that you would be +able to provide publicly to the network to show that the wallet was yours and +not an attacker. + +**Mark Erhardt**: Yeah, this would generally not work for anyone that uses a +bag-of-keys sort of wallet, which Bitcoin Core had, I think, before 2013. And +likely a lot of the P2PK outputs from the first reward epoch with the 50-bitcoin +block subsidy would not be new wallets in that sense that they could prove +anything about these P2PK outputs. + +**Jameson Lopp**: Some might say, "Why three years, five years?" so on and so +forth. These are arbitrary numbers that we could argue about. I would argue +that it doesn't really make sense to me, and I don't believe that we would end +up implementing some sort of novel, new post-quantum cryptography, unless it was +deemed it was going to be truly necessary. So, I doubt that we would activate +something several decades before a cryptographically-relevant quantum computer +came along. Also, there's an ongoing debate as to whether or not doing this in +an opt-in only fashion is sufficient. I think that's where a lot of the crux of +the argument is for locking or freezing vulnerable funds. Is it sufficient if +we give people the ability to voluntarily secure their own funds, if a +non-trivial part of the ecosystem does not upgrade in time? And we all know +human nature and procrastination. Are you going to be happy, as a bitcoin user, +that your funds are quantum secure if so much bitcoin ends up re-entering +circulation and getting dumped that the value of your holdings gets totally +crushed? That's, I think, what a lot of this comes down to. And then, what are +all of the ripple effects throughout the rest of the ecosystem if such an event +occurs? + +**Mark Erhardt**: There's also just the question of how much confidence people +would have in a system where, say, a quarter of all bitcoins are up for +misappropriation and not owned by the people spending them, with basically no +way of properly distinguishing them or alternatively introducing a fungibility +issue. So, this might be a fork event or all sorts of other ways that the +Bitcoin ecosystem could be severely damaged. + +**Mike Schmidt**: Jameson, question for you. It seems like the timeframes of +your proposal kick off at the time that a quantum-resistant signature scheme is +activated on Bitcoin mainnet, which sort of then means that it puts a lot of +pressure on activating that scheme to be an accurate indication of if quantum is +going to be here; whereas I could see there being different bars, right, where +one bar is, "Hey, we have a scheme, it looks like this thing could happen", but +then like, "Okay, quantum is here. Now there's a higher bar, and now we're +going to execute the next phases of your proposal", if you want to think about +it like that. But in the way you have it, sort of the bars are the same. Once +we even put the idea of a quantum-resistance signature scheme out there, we've +now signed up for locking coins. I don't know, I think there's been some +discussion, I think, on your proposal on the mailing list and maybe you can +digest that for the audience of how you think about that? + +**Jameson Lopp**: Yeah, well, so one aspect of it is, at least currently, all of +the post-quantum cryptography is terrible, it has so many terrible trade-offs. +I don't know why anyone would even want to entertain implementing it unless they +really thought that this was a true threat to the entire ecosystem. Maybe +something much better will come along that will make more sense that it would be +an opt-in only thing, and it's actually quite efficient and we're not losing a +lot of the other functionality that we currently have with the protocol. +There's a number of different ways that this could go as well, which I haven't +really dug into too much, but sort of on the opposite extreme is that it's +feasible to come up with an alternative activation and accelerated timetable in +the event that something does occur that makes a cryptographically-relevant +quantum computer appear much sooner on the horizon, or even if we just have +actual cryptographic proof of such a computer existing. + +That's one of the things that we talked about at the Quantum Summit a few weeks +ago, was essentially offering a triggering mechanism at the protocol level. It +would be fairly trivial for someone with a quantum computer to be able to prove +that they had a quantum computer. The bigger problem is, does the game theory +work out such that someone who had that ability would be benevolent enough to +prove it to the ecosystem that they were a threat and that we need to guard +against it? + +**Mark Erhardt**: Yeah. I wanted to jump in, tying back to what Tim was talking +about. So, if Tim says, "Why not just put a post-quantum signature scheme into +tapscript as a fallback mechanism that people can start opting in?" I think that +would, of course, not qualify as the, "We're actually convinced that post +quantum is really going to happen sometime soon to trigger Jameson's proposal", +or at least it seems obvious to me that's not the same things you guys are +talking about. But, Tim, did you want to chime in on this? + +**Tim Ruffing**: Yeah, I guess you're right. These are different approaches and +I think they both are meaningful. And I think if you ask me, I mean I tend to +work on the cryptographic questions because this is where my expertise is. But +I feel like those in the end are not even the hard questions in a sense. At +least we have post-quantum signatures right now. We have some schemes, they may +not be great, but we have them. We also have proposals on how to do the +upgrade, but I feel like this is where most of the discussion will happen, in +particular because everyone tends to have an opinion. I feel like for your +proposal, I think that's a very reasonable thing to do. I'm just not sure if +people would want to agree on this again, like if they don't know that the +quantum computer will be shortly available, whatever 'short' means. So, it goes +back to maybe what has been said before, that at the point you start the +timeline, you have to commit on the deadline where we do the moves. And if we +are talking about the time frame of a few years, it's even hard to predict what +will be there in three weeks, and it's even harder to predict what quantum +computers will be able to do in three years. + +I could imagine that in an optimal world, I would love to see this migration +path being the one that's used, but I'm just not super-convinced that we can +agree on a soft fork that says, "Okay, from now on, we just start the clock and +in three years, the deadline". + +**Mark Erhardt**: Yeah, that reminds me of one of the conclusions I had from the +Quantum Summit, which was that the hardest part is actually trying to gauge the +viability of cryptographically-relevant quantum computers and the timelines of +those. One of the quantum computer experts that was attending made a salient +point about, "Well, in the next five years, we'll probably get good updates on +the timeline". And hopefully, that means that they are not going to be here in +the next five years, but that is one of the questions that are hard to answer. + +**Tim Ruffing**: But even that is a meta prediction about the future, right? +And maybe, let me maybe add one anchor to that again, maybe a bit of a technical +one, but you could say that the upgrade strategy that I've been talking about is +a bit more conservative, literally because it keeps the full taproot +functionality. But this is not even true from a technical point of view, at +least given the current post-quantum schemes that are out there, because what +people tend to overlook is, at least with hash-based signatures and everybody +now talks about hash-based signatures, is that we can't have public derivation. +And this already changes how wallets work. So, even this, there will be +pressure and procrastination. + +**Mark Erhardt**: Let me jump in very briefly. So, last week I believe, we had +Jesse Posner on, who had spent some time doing research on which of the current +wallet patterns are available with various post-quantum schemes. And one of the +conclusions that he had was that a lot of the BIP32-like derivation, MuSig, +FROST, and so on, would be compatible with lattice-based signature schemes, +which of course make more cryptographic assumptions and therefore are +potentially more vulnerable to be broken in the near- or long-term future. But +he also thought that some of the derivation wallet schemes might be possible for +the hash-based signatures, if I remember right. So, what I was thinking is, +wouldn't you be able to craft an output script descriptor that has a tree with +regularly derived scriptpath spends that are DL-based (discrete-log-based) and +then have a static post-quantum scheme next to it, where the post-quantum scheme +is there and yes, you'll have to reuse the script leaf a few times if you have +multiple UTXOs? But you could basically have, in parallel, an output script +that looks different every time, whereas it has a static post-quantum fallback, +giving you privacy in the default case where it's not needed yet, but giving you +a default back for post-quantum if you need it. + +**Tim Ruffing**: Yeah, you could, and this is maybe a totally reasonable path in +the middle. So, the problem here is that to construct the UTXO, you need to +have all of the involved public keys, right? So, if you have a DL public key +that can be used at least now for spending, you may have multiple maybe +post-quantum public keys, depending on what schemes we add. I mean, it's not +crazy to add multiple ones to see what works out best in the future. But the +issue is to compute the UTXO, to compute the address, you need to know all of +these public keys. And so, this idea of, "Okay, let's add multiple schemes and +let's wait a bit and see which ones get broken and which not and which ones +would get improvements", doesn't really work out in every last bit. But what +you could do is let's say now, yeah, this is basically really what you said. +So, maybe let's say the hash-based schemes are very conservative, so let's add a +hash-based scheme now. And what people can do is have a static script where +they can spend their UTXOs using a hash-based signature, with the idea that it's +really just a fallback in case everything breaks down and we are not quick +enough adding more solutions, and with the drawback then that if you really +reveal that script, at least the public key in there will be the same for your +entire wallet. So, you kind of link all your coins together. + +The alternative is, of course, you can also, if you have a hardware wallet, you +can make it export a million keys. You can do that, but it's just it doesn't +fit the current API model of what wallets do, so it may be hard to get a wallet +to do this. + +**Jameson Lopp**: I think it is preferable if we can give people wallets that +have multiple signature schemes behind them, but you still inevitably will run +into the question of, "Okay, when do we disable a given signature scheme?" So, +I think there's two main paths. One is, do we aim for a gradual, slow, more +smooth migration path, because we know that it's going to take probably many, +many years to actually get the UTXO set migrated; and then the other, which I +don't think has really been discussed as much is, what are the potential +emergency break-glass scenarios of cut off all spending of vulnerable coins in +any vulnerable signature schemes, and then basically require people to either +only use the post-quantum cryptography schemes or to use some sort of other +quantum-safe proof of wallet ownership? + +**Tim Ruffing**: Yeah, indeed, I fully agree. So, maybe add one more thing to +what I was saying. So, you could commit to static hash-based public key nodes, +this is a merge set, but also commit to maybe a lattice-based scheme. And I +just wanted to mention that also, other assumptions may allow public +derivations, for example, zero-knowledge-based schemes. There's a variant of +Picnic, for example, which is an MPC-in-the-head-based scheme that also enables +public verification and public derivation. And we haven't really looked into +other assumptions. But yeah, I mean it's totally feasible to add multiple ones, +modular auto engineering complexity, but it's really what Jameson said, there's +no precedent for this. So, it may sound crazy to add multiple schemes at once +because you're not sure, but if you think about it, we never had an event like +this before or a situation like this before, so maybe it's not that crazy. + +**Mark Erhardt**: To break the lance for that approach, one of the things we've +been hearing about at the Quantum Summit was that a lot of other ecosystem +participants were sort of pushing for something to happen to address this +potential future problem. Having an opt-in mechanism that people can use +already, even while we consider quantum computers to maybe not be super-pressing +yet, would demonstrate that the ecosystem is starting to react to the topic. + +**Mike Schmidt**: Well, it's an interesting set of discussions around quantum. +Tim and Jameson, thank you both for joining for these two this week. I'm sure +we'll have more and look forward to talking to both of you about it in the +future. Thank you for your time. + +**Jameson Lopp**: Thanks for having me. + +_Testing compact block prefilling_ + +**Mike Schmidt**: Jumping back up to the news section, we have two news items +this week. The first one is titled, "Testing compact block prefilling. David, +you posted a follow-up or reply on a Delving thread about compact block +reconstructions that we covered previously, initiated by 0xB10C. In that +original post, 0xB10C looked at how using compact blocks, or as Murch likes to +say, passing around block table of contents, instead of full blocks, how that +performs statistically over a period of few months. And in your reply, which I +feel like I'm doing a disservice calling what you wrote a reply as it's quite +robust, but you detailed a bunch of research that you conducted on prefilling. +Can you maybe explain what prefilling is in the context of compact blocks? + +**David Gumberg**: Yeah, so the compact block message, to use Murch's metaphor, +includes a table of contents of the transactions that the node receiving the +announcement needs to have in order to perform the reconstruction. And if a +node that receives a compact block announcement is missing any of the +transactions in the compact block, it has to perform a round trip to request +those transactions and receive them. The original compact block proposal +includes a prefill section in the compact block announcement, where a node +that's sending a compact block announcement could include transactions that a +peer might care about. And today, in Bitcoin Core, we only use the prefill +section of the message to prefill the coinbase transaction, which peers always +won't know about until the block is announced. + +A few months ago, 0xB10C proposed and wrote a branch of Bitcoin Core that tries +to predict the set of transactions that a peer won't have, and send those along +in the prefill section of the compact block announcement. And if we can get the +prefill right and send the right transactions that our peer would have been +missing, we can prevent altogether this extra round trip. The approach that +0xB10C used was to prefill the set of transactions that we didn't know about +when we received a block. So, when you receive a compact block, whatever +transactions in there that you had to request from your peer, you'll pass along +in the prefill to the next peer. And if you're receiving a block that's been +prefilled, you'll also look inside the prefill and see which of these did I +actually need, and you'll pass those along to your peer when you announce a +compact block to them. + +There were some questions raised on the Delving post. So, there are some +trade-offs here between bandwidth and latency. And there's one particular +hiccup, which is that the Bitcoin P2P Network is over TCP sockets. And in TCP, +there's a little bit of a complication, which is that we can't just send as much +data we want over the wire without incurring an additional round trip. I +detailed this in the post, but basically there are these TCP window sizes, and +if we send messages that are too big, then an extra round trip will be required +anyways. And so, what I wanted to do research about was basically whether or +not 0xB10C's prefilling approach could be -- well, first of all how effective it +was, I wanted to observe that; and second of all, whether or not the prefills +would actually fit within the TCP window. And I also outlined in the post why, +if we ever exceed the window, we were better off not doing the prefilling in the +first place, because we pay an extra round trip and we might as well have let +the peer ask us for the transactions that they were missing. + +So, basically what I observed, so what I did was I connected one node that was +prefilling the compact blocks that it was announcing. It was running 0xB10C's +branch. And the other node, I made it so that it would basically only listen to +compact block announcements from this peer. And I just gathered some data. And +so, the baseline that I observed, over about 20 days, of reconstruction rate for +a normal node was 62%. So, 62% of the time in this particular node, when it +received a compact block announcement, it did not have to request additional +transactions and pay an extra round trip. But 39% of the time, it had to pay an +extra round trip to complete reconstruction. And looking back to the beginning +of 0xB10C's post, he shows some data about what block reconstruction times look +like, when you need to do a round trip and when you don't need to do a round +trip. And when you don't need to do a round trip, it takes on the order of 15 +milliseconds to do reconstruction; and when you need to, it takes somewhere +around 150 milliseconds, obviously depending on your connection to the peer. + +**Mark Erhardt**: To be fair, one should maybe also include the time that it +takes to get the data the first time. So, the round trip obviously adds a +message back to the sender and another message from the sender to the receiver. +So, presumably the first reconstruction is 15 milliseconds plus something like +75 milliseconds or so? + +**David Gumberg**: Yeah, exactly, something like that. So, that metric comes +from some logging that Bitcoin Core does, and we don't know what's on the other +side. So, we don't know how long it took from the peer announcing the compact +block to us beginning the reconstruction process. We don't have that timing. +But that figure that I just showed, yeah, that has that caveat, which is that it +doesn't include that half-round-trip latency for us. So, maybe a better way to +put it is something like that when we need to do a round trip, reconstruction +gets about 150 milliseconds worse than whatever it is. + +**Jameson Lopp**: I can say that from my own logging with my Satoshi node, the +median peer ping is about 50 to 60 milliseconds. + +**David Gumberg**: Yeah. So, that would be on the order of 100 extra +milliseconds. And it's even slightly worse because compact block announcements +are done really, really early in the validation loop. So, even before you've +fully validated a block and checked all the signatures, you're sending out +compact blocks as fast as possible. But when I receive a compact block and then +I request the rest of the transactions from you, that request has to wait in +line for the block to get fully validated. It's just like, it doesn't get this +kind of special hot-case treatment. So, there's other small effects that add on +to why latency gets worse in that case. + +For comparison, what I observed on the node receiving prefilled blocks was that, +kind of as expected, these are two Bitcoin Core nodes that are basically running +the exact same mempool policy, these two nodes were in the same data center, +they're very well connected to each other, very low latency. So, this figure +kind of comes with that caveat, which is that not all nodes will have this +strong of a tendency to converge. + +**Mark Erhardt**: Sorry, they are in the same data center, and the round trip +still adds 150 milliseconds? Is that right, do I understand that? + +**David Gumberg**: No. + +**Mark Erhardt**: Okay, sorry. + +**David Gumberg**: The 150-millisecond data, that comes from 0xB10C, and he +observed that on mainnet with some of his nodes. In this observation, I didn't +do anything with round trip times. I just was trying to reason about when we +did and when we didn't have to pay for a round trip, whether or not we did, not +how long it took. But that, I think, is the next step of work, to actually put +two distant nodes so we can get real latency data. + +**Mark Erhardt**: Okay, let me jump in briefly. So, the idea is basically the +fastest way nodes propagate block announcements is giving a recipe how to +compile the content of the block from another node's own mempool. It's +basically just an ingredient list and the header. And we do this specifically +with, I think, three peers that we say, "Hey, you're giving me stuff pretty +quickly. I'll declare you my high-bandwidth, compact block relay node. You can +send me blocks even before you finish validating them". So, we don't do this +always, otherwise that might actually cost more bandwidth. But in this context, +now you're proposing rather than just giving the ingredient list and the header, +I'm also going to send you a few transactions that I had to ask back about +before I could forward the block. In this context first, would maybe also +including some of the transactions that you just learned seconds before hearing +about the block make sense, if you have space in the prefilled block? Have you +looked at that? + +**David Gumberg**: No, I haven't looked at that. So, what I observed was with +this kind of really primitive prefilling, only using this one heuristic, that +the node receiving the prefills was able to reconstruct 98% of blocks. So, the +reason it's not 100% in this case, even though they're running the same mempool +policy, is probably because of a scenario like what you're talking about. So, I +do think that would be worth looking at, yeah. + +**Mark Erhardt**: Well, if you're saying that you already get 98% +reconstruction, whereas you measured 62% before without the prefilling, maybe +the simple heuristic is already sufficient. And sure, maybe we could do even a +little better, but it might also make it worse because we're now sending more +data that is unnecessary often. So, you've been testing for 20 days. I saw +your write-up in Delving. People that are interested in this topic, this is a +thorough work of all sorts of statistics and a detailed description of the +approach. If you are interested in the topic, give it a read, it's well worth +it. So, what are the future steps? What's going on next? + +**David Gumberg**: I just want to add one more caveat to that 98% figure, which +is important, which is that that is unbounded prefilling, but in reality we're +going to have to bound the size of prefilling. And the estimate that I got was +something like 93% once we bound the prefilling to the TCP window. And there's +work to be done to maybe get that number higher, to be smarter about which +transactions we choose to include. So, there is a lot of future work here. +Like I said, I didn't really think about propagation times. I was just trying +to focus on whether or not we had to do a round trip. And so, one of the things +I want to think about more is how to go from thinking about point-to-point +latency, like node hearing about compact block and reconstructing it, to +thinking about how that impacts networkwide propagation. I think there's a lot +of further work there, and I think there's more work to be done. + +I think the next experiment is going to involve actually doing prefills bounded +to the TCP window. And then, I also hope to do maybe some work using the warnet +tool to maybe set up some scenarios that have more than just two nodes, because +the experimental setup I described really only works when you kind of have two. +And I want to try some more, I guess, contrived scenarios to see how this +performs. + +**Mark Erhardt**: Thank you for the thorough description, and thank you for your +patience sticking around so long. + +**David Gumberg**: Thank you. + +**Mike Schmidt**: Mike, did you have more? Just maybe a comment that I saw +earlier. It was on Gloria's PR to change the relay fee. I think 0xB10C posted +some data with a bunch of red in it, indicating nearly 1 MB of data to +reconstruct the block, due to a lot of below-1-sat/vB (satoshi per virtual byte) +transactions being mined, but not necessarily being fully relayed. Probably can +get into that in a future discussion as well, but it touches a little bit on +your work, David. Yeah, Murch? + +**Mark Erhardt**: I think actually it's sort of orthogonal. So, with that sort +of amount of data, we wouldn't be able to solve it with a prefill. What this +shows is how brittle compact block relay is, in the sense that it only really +works when mempool policies are somewhat cohesive and a lot of nodes already +have almost all of the transactions that are in the block. So, in the +sub-1-sat/vbyte summer that we're seeing right now, where suddenly a few people +convinced miners to start mining transactions that were paying less than 1 +sat/vB, which had been the minimum relay transaction feerate for almost a +decade, they first started out with only one or two mining pools doing that and +there was sufficient demand that it appeared on mempool.space quickly thereafter +in their visualization of the mempool. And people started doing a poor-man's +version of preferential peering by just sending around a list of listening nodes +that would accept transactions below 1 sat/vB. And fast-forward a few weeks +later, 80% of the hashrate is mining transactions below 1 sat/vB. + +So, there is currently work in Bitcoin Core to address this discrepancy between +what we're seeing getting mined with what we're relaying by default in Bitcoin +Core. The feature freeze is coming up in a few weeks, so the idea would be if +we can manage to process this PR in time, maybe in the 30.0 release, this +hashrate preference and what is being relayed on the network and the defaults in +Bitcoin Core would match up again. And then of course, David's work on +prefilling would be relevant in that context again, but before that, prefilling +is probably limited to, I think, less than 10 kB, usually even less than that. +So, with us seeing blocks requiring almost 0.8 MB of additional data to be +constructed, I think we're going to see hugely increased latency for the moment +on the network between the nodes that do not participate in forwarding such +small feerate transactions; and unfortunately, prefilling wouldn't do much in +that context. David, back to you. + +**David Gumberg**: Yeah. And I mean, presumably, I think part of the incentive +for miners to run this policy is to have fast reconstruction as well. It's part +of the equation there. Yeah, I think that prefilling doesn't solve that kind of +a major divergence between mempool policy and economic activity, but I do think +it can fix two things. One is small inter-release divergence, so the lag +between the Bitcoin core release being cut and lots of people running that is +huge. So, it takes a long time to react to economic activity diverging from +mempool activity. So, this is just like a little bit of a pressure-release +valve, or prefilling would be just a small pressure-release valve there. And it +would also kind of address one thing that there's nothing Bitcoin Core or any +implementation of Bitcoin can do anything about, which is private mempool +transactions, which we hope remain a small proportion. + +**Mark Erhardt**: Actually, one more follow-up question in this context. Would +nodes that are not upgraded be able to receive such a prefilled block, or does +that require new network messages or something like that? + +**David Gumberg**: Yeah. So, everything was implemented about prefilling except +for picking which transactions to prefill. There's a comment in there like, +"Come up with some heuristic for the transactions we'll prefill". But yeah, the +node that received prefills in my experiment wasn't modified in any way, except +for to only listen to compact block announcements from this one peer and some +additional logging, but otherwise it was a default node. And my node that was +doing prefilling was sending out prefilled blocks to lots of random public +nodes. And as long as they were running Bitcoin Core, well, yeah, they were +able to process all the prefilled transactions and got the benefits of those +reconstruction times. + +**Mark Erhardt**: Sorry, you're creating more questions. What would happen for +other implementations? Would they be upset about getting a prefilled block? + +**David Gumberg**: Well, presumably, if they've implemented compact blocks and +they're doing the compact-block handshake where they're telling you they support +compact blocks, and then they're asking you to send them high-bandwidth blocks, +then I would assume or hope that they have also -- and the fact is that they +already had to implement prefilling to receive the coinbase transactions. So, I +would assume that every existing implementation of compact blocks would be able +to handle prefilled transactions. + +**Mark Erhardt**: Awesome. Thank you for your work on this. + +**David Gumberg**: Thank you. + +**Mike Schmidt**: I encourage folks, like Murch said, to check out the Delving +reply that David packed a lot of information into. It's a good read. David, +thanks for hanging on, thanks for your time, thanks for joining us. + +**David Gumberg**: Thank you guys very much. Appreciate it. + +**Mike Schmidt**: Well, we have one guest who didn't introduce herself earlier +who's joined us, and thank you, Lauren, for hanging on. Do you want to +introduce yourself for folks, and then I'll frame up the news item? + +**Lauren Shareshian**: Sure, thanks for having me. My name is Lauren Shareshian +and I work on the Bitcoin custody team at Block. + +_Mempool-based fee estimation library_ + +**Mike Schmidt**: Excellent. Well, thanks for joining us and I apologize. We +had a big newsletter this week, but we're glad you're here. The news item is +titled, "Mempool-based fee estimation library". Lauren, you posted to the +Delvin-Bitcoin forum a post titled, "Augur: Block's Open Source Bitcoin Fee +Estimation Library". And in that post, you outline how your mempool-based fee +estimator works. Lauren, what have you built? + +**Lauren Shareshian**: Yeah, we released Augur. It means, "To predict the +future from omens". And maybe I can start out explaining what originally +motivated the project. In the past, we had relied on various external APIs for +our fee estimates. And some of these providers had experienced pretty large +outages lasting days to weeks. And so, we really wanted to increase the +resiliency of our system by building an internal tool instead. And as we were +choosing the internal tool to build, we noticed that WhatTheFee was giving us +the best estimates. And generously, Felix Weis had shared on GitHub the code +that powers the WhatTheFee estimates. They were in a pretty informal Python +notebook format, so it took some time for my team to get them production-ready +and convert them to Kotlin, which is what my team uses. And we also increased +the frequency of the estimate updates. And since Felix's shared code was so +helpful, we wanted to open-source ours as well. + +So, we created the main library, Augur, as well as a reference implementation +for it. And when we posted that on Delving, almost immediately we got feedback +that it'd be helpful to post the benchmarking tool as well. So, my colleague, +Steven, got that out like two weeks ago. And it includes our benchmarking +script plus six months' worth of provider data that we've been benchmarking +against. We think the tool will be helpful because it keeps track of a few +different metrics, and so different folks might care to optimize different +values. So, if your biggest concern is getting confirmed as soon as possible, +then maybe you want to minimize your miss rate; whereas if your biggest concern +is saving money, maybe you want to minimize your overpayment. At Block, we've +been mostly keeping track of a composite metric that takes into account both +miss rate and overpayment, because we don't want to overcharge customers, but we +also need their transactions to get confirmed in a timely manner. + +So, for our quickest confirmation tier, Augur has been getting 85% of +transactions confirmed on time, while only overpaying 16% on average. + +**Mike Schmidt**: Now that website, Lauren, that you mentioned is whatthefee.io +by Felix, and you mentioned that that served as maybe the scaffolding for what +you guys came up with, and you also now have some data behind some of this +benchmarking that you're putting out. I saw also that you and Abubakar were +going back and forth. Abubakar has been doing some Bitcoin-Core-related fee +estimation work. What discussions did you and Abubakar have in terms of +approaches or questions? + +**Lauren Shareshian**: Yeah, he's been super-helpful. We basically are +considering getting things kind of in parity with WhatTheFee and getting our +benchmarking tool set up; we're kind of considering the beta version. And now +that we have the tool set up and the algorithm in place, we can iterate to make +it better. And so, Abubakar, one thing he said he was playing around with was +porting the ideas of Augur into a mempool-based forecaster in Bitcoin Core, +which we thought was super-cool. And then, he also suggested that we should try +benchmarking against newer versions of Bitcoin Core since the default mode is +economical now. So, we're going to start working on that soon. That was +another really helpful suggestion from him. So, yeah, the feedback we've got on +Delving has given us new paths to go down and we've been super-appreciative of +the feedback. + +**Mike Schmidt**: Are there particularities of Block's setup that inform how you +think about fee estimation? I assume you have many users doing transactions or +withdrawals and you can batch those and you can do fee management with CPFP or +RBF. And as people go through what you've written up, is the way that you guys +approach it after looking at that research different on your back end? + +**Lauren Shareshian**: Yeah, that's a great question. So, we do have fee +bumping and batching and all the other things in place. I guess this Augur tool +is trying to minimize the use for the fee bumping and fancier things, right? +We're just trying to get a good first estimate, but then fee bump if we need to. +And then, I suppose another thing that maybe is unique to us or maybe not is +that we have various withdrawal tiers, like standard, rush, priority, and so a +user can choose how fast they need their transactions confirmed. And so, that's +why you'll see in our API output there's various block targets, because we need +several different block targets for our various tiers, as well as different +confidence levels. So, if you really need to be conservative, maybe you'll go +with a higher confidence level; if you really want to save money, maybe you'll +go with a lower confidence level. We've typically been using the 80% confidence +level, which I think is what WhatTheFee uses as well. + +**Mike Schmidt**: Murch, you have questions? + +**Mark Erhardt**: Well, I guess many, but so the first block target is +notoriously difficult, because of course we have no idea when the next block +will be found. Bitcoin Core has, for the longest time, only I think given an +estimate starting with two blocks from now because of that reason. So, you +described that you use the flow of transactions into your mempool as a predictor +of how much other transactions you'll be competing with by the time it's most +probable the next block is found. Could you go a little bit into that? + +**Lauren Shareshian**: Yeah, and to your point about one block, our minimum +block target that we give output for is three blocks, because we're not really +set up to simulate mining partial blocks. And so, yeah, to go a bit more detail +in the algorithm, we start out by putting everything in the mempool into buckets +by feerate. And so, as a super-simplified example, maybe the cheapest bucket +would contain all the transactions from 1 to 2 sats/vB, and the second cheapest +bucket would be 2 to 3 sats/vB. These aren't the exact bucket thresholds +because we actually use a log scale to provide more precision at the lower fee +levels, but for example purposes, it's fine. And then, we also keep track of +what's flowed into the mempool recently. So, if I continue with this simplified +example, then maybe there's 100 transactions currently in the cheapest bucket +tier. But we've been noticing that an extra transaction comes in each minute at +that cheapest bucket tier. Then, we think there's probably going to be, well, +100 plus 10, 110 transactions in that cheapest bucket 10 minutes from now. + +Disclaimer, our assumption currently is actually a little bit simpler than that, +because what we do is we just have the recent inflow during a typical block as +additional weight. So, let's say we think there'll be 10 in that cheapest +bucket that'll come in over the course of a block, and we have 100 in there at +the beginning of the block. We're just going to assume that 105 are in there +for the block, which means we'd be overestimating at the beginning of the block +and underestimating at the end of the block. So, this is one example of where +we feel like we have a beta version, and now we can iterate. We'd like to see +if we can make that scaler a bit more dynamic. And then, just to finish off the +gist of the algorithm, we assume miners will choose the most expensive rates +first. So, we go down each bucket, starting from the most expensive, add their +weights until the block size is reached. This will give us the cheapest feerate +that actually made it into the block. + +Then, the randomness component of how often blocks get mined, that's where the +Poisson distribution comes into play. And so, on average, three blocks get +mined every 30 minutes, but if you need to be more conservative, maybe you're +going to assume that only one block will get mined in that time. And that's +kind of why we can't do less than three blocks, because we can't assume that +less than one block is getting mined with our current algorithm. We're not +doing decimal values of a block getting mined. So, yeah, that's the basic, just +the algorithm, and it's why you see various confidence levels in our output. + +**Mark Erhardt**: So, we know about multiple other mempool-based feerate +estimation methods. You had in your blogpost a comparison with some of the +popular ones, such as mempool.space. Did you compare notes with anyone else +besides Abubakar and Felix? + +**Lauren Shareshian**: No, those were the only folks. I'm actually pretty new +to the Bitcoin community, so I haven't met folks on other teams just yet. + +**Mark Erhardt**: Okay. And notoriously Bitcoin Core, well, this is why +Abubakar is working on fee estimation, because Bitcoin Core's feerate estimation +is not currently something that we pride ourselves on. Did you do any +comparisons? I think you mentioned that you did comparisons with Bitcoin Core, +but could you get into the details laid on us? + +**Lauren Shareshian**: No, we actually want to. So, one thing that he +recommended is doing a comparison against Bitcoin Core, a newer version. And +so, we're working on that now, although there's actually kind of some internal +debate on my team about like, if comparing a mempool-based estimator to Bitcoin +Core, is that comparing like apples to apples or apples to oranges? Are they so +different that like you shouldn't compare them in the first place? Someone's +expressed that idea on my team. So, we do want to do it, but we haven't done it +yet. + +**Mark Erhardt**: Yeah. So, for context, Bitcoin Core uses a feerate estimate +that's purely based on the historic speed at which transactions leave the +mempool. So, it only uses transactions that the node saw in its own mempool and +measures how long it took from them arriving to getting mined. So, it's a very +different approach than looking at what is currently in the mempool and getting +added and projecting from there. Well, that's what I had on the top of my head. +Mike, do you have anything else? + +**Mike Schmidt**: Yeah, just I wanted to encourage folks, the post on Delving +links to the open-source code from Lauren and her team. There is also reference +to a public API endpoint that you can query. The source code for WhatTheFee is +linked there. There is a post from Abubakar that's referenced, and there is a +post from Block's engineering team that is referenced. So, there's a ton of +information about this for folks who are curious about this kind of discussion +to dig deeper. Lauren, is there anything that you'd like to have as a call to +action for folks, or something to wrap up? + +**Lauren Shareshian**: Yeah, the feedback we've gotten so far we've appreciated +so much. So, anything else, we'd appreciate as well. Thank you so much. + +**Mark Erhardt**: Well, thank you for your time. + +**Mike Schmidt**: We appreciate your time, and yeah, you're welcome to hang on +for the rest of the newsletter or you're free to drop obviously if you have +other things to do. + +**Lauren Shareshian**: All right, thanks. Bye. + +_Bitcoin Core 29.1rc1_ + +**Mike Schmidt**: Releases and release candidates. We have Bitcoin Core +29.1rc1, and there was a few notable items that I saw in the release notes here. +Murch, you probably have some as well. But in terms of notable changes, at the +top is mempool policy. We covered Bitcoin Core PR #32521 previously, which +essentially limits the pathological transactions in legacy sigops. Those are +non-standard now. We covered that, I forget which week that was, but that was a +recent discussion. We also talked about the dbcache values for 32-bit operating +systems and why it's a good idea to cap those and the bad things that can happen +if you don't. There's over a dozen tests, a dozen build-related PRs, a dozen +doc-related PRs. Did you see anything else in there, Murch? + +**Mark Erhardt**: No, that's a great summary. Maybe the one thing that I +noticed was in the, oh, sorry, no, I'm mixing this up with one of the PRs below. +Never mind, sorry! + +_Bitcoin Core #29954_ + +**Mike Schmidt**: Sure, Notable code and documentation changes. Bitcoin Core +#29954, which adds two fields to Bitcoin Core's getmempoolinfo RPC. So, calling +Bitcoin Core's getmempoolinfo RPC returns a bunch of information about the +mempool, including size, memory usage, total fees, etc. But also returns relay +settings, like fullrbf and the node's minimum relay fee for transactions. This +PR that we're covering this week will also include two new relay settings. One +for permitbaremultisig, which is a true and false based on if the node's mempool +accepts transactions that are bare multisig outputs; and a second field will be +returned from that RPC, which is maxdatacarriersize, which is the number of +OP_RETURN bytes that the node will allow in the mempool. + +**Mark Erhardt**: And that was the PR that I was thinking of. + +_Bitcoin Core #33004_ + +**Mike Schmidt**: Got it. Bitcoin Core #33004 will now default Bitcoin Core +nodes to automatically open ports on the node's network router to allow for +inbound connections. When you run your Bitcoin Core node at home, for example, +you'll see outbound connections; but unless you configure your router to open +ports to go to your node, you won't see any inbound connections. And in earlier +versions of Bitcoin Core, this automatic port-opening feature was available and +used the miniupnp library. But after multiple vulnerabilities involving that +miniupnp library, including remote code execution attacks, the feature was +disabled. You can check out on our CVEs Topic Page and search for miniupnp to +see a few of those that we've covered. But last year, Bitcoin Core merged PR +#30043, and that was an in-house implementation that achieved a similar feature +of opening router ports. And that feature at the time, last year, was disabled +by default, partially waiting on additional testing. + +Well, this PR today is simply enabling that in-house port-forwarding feature in +Bitcoin Core by default. One thing I'll quote from the description, "The upside +of turning this feature on by default is, if most ISP default provided router +support is supported by default, a much more diverse P2P network will emerge. +The downside is an increased attack surface. A vulnerability affecting only +listening nodes would now expose people's node at home". Murch, any thoughts? + +**Mark Erhardt**: Well, people have been long worried about the low count of +Bitcoin nodes. And one of those related topics there is, how many listening +nodes are there in the first place, or how many nodes are there, because we can +obviously only easily find the listening nodes? So, if more nodes by default +were able to accept inbound connections by opening these ports on their routers +or ISPs enabled by this protocol, we might see a huge jump in listening nodes as +this feature rolls out to people. I believe that by default, all nodes start in +listening node, and of course listening nodes have a little bit more bandwidth +consumption because they, for example, help peers bootstrap with the blockchain +and serve light clients. But it would also distribute that traffic that is +currently only on the currently visible listening nodes to to these new nodes +that would come online. So, hopefully this would just make the Bitcoin Network +overall more robust if more nodes appear on the network with listening +capability. + +_LDK #3246_ + +**Mike Schmidt**: LDK #3246 is a PR titled, "Enable Creation of Offers and +Refunds Without Blinded Path". Now, LDK already has the ability to handle +BOLT12 offers and refunds without blinded paths, but until this PR, there wasn't +an easy way to create them. So, this PR gives LDK users full control over how +the blinded message path is constructed, including the option to omit the +blinded path entirely. Discussion of the PR noted, "This is also useful for +testing or when alternate privacy strategies are needed." + +**Mark Erhardt**: It's really neat to see how over time, all of these little +parts fall into place. And who knows, well, I don't know the exact timeline, +but hopefully by the end of the year or next year, we'll broadly have blinded +path and BOL12 offer support across the ecosystem. + +_LDK #3892_ + +**Mike Schmidt**: LDK #3892, this PR includes two commits. The first adds an +OfferId to all BOLT12 invoices, linking invoices to their originating offers. +And then, the second commit makes the BOLT12 offer merkle tree signature +available in the public API. Now, for that second piece, it could be a useful +feature for developers that are building command line BOLT12 offer tools that +need to verify the signature of BOLT12 invoices or recreate invoices. And +another noted use case was learning tools, where having that information would +be helpful. And there was some slight back and forth on whether this particular +API, public API for the offer merkle tree, should be something within LDK, but +they ultimately decided that it was. + +_LDK #3662_ + +Last PR this week, LDK #3662, which implements LSPS05, which is Lightning +Service Provider specification number 5, which is also the Bitcoin Lightning +Improvement Proposal 55 or BLIP55. Both of those specs detail how LSPs should +handle webhooks. That's usually something used when the LSP is interacting with +a usually mobile device and usually a mobile wallet, and needs to send a +notification to that mobile client without the mobile client having to +continuously pull the LSP for updates. So, you provide a URL that can be +essentially pinged when certain activity happens. Some examples of those such +push notifications might include an incoming payment, a BOLT onion message, +changes to the LSP that they're making in terms of liquidity for that particular +user, and then there's some other examples as well. And this LDK PR is actually +a complete implementation of that LSPS05 spec, although I did see some minor +follow-up related PRs. It was all done in one bang. + +I think that's it for this week, Murch. Just about two hours. + +**Mark Erhardt**: Yeah, big one. + +**Mike Schmidt**: Well, we want to thank our guests for joining us, Tim, Steven, +Jameson, Lauren, and David for their time, some of them hanging on and listening +to the podcast along with you all. And thank you to Murch as co-host this week +for taking time out of his day for you all and for you all for listening. + +**Mark Erhardt**: Hear you soon. {% include references.md %} From 499406d45b6b0ba9f716fec58576148a796d82bc Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Mon, 11 Aug 2025 20:26:15 +0200 Subject: [PATCH 201/278] translate newsletter 366 into german (#2456) Co-authored-by: garfiel-d --- .../de/newsletters/2025-08-08-newsletter.md | 289 ++++++++++++++++++ 1 file changed, 289 insertions(+) create mode 100644 _posts/de/newsletters/2025-08-08-newsletter.md diff --git a/_posts/de/newsletters/2025-08-08-newsletter.md b/_posts/de/newsletters/2025-08-08-newsletter.md new file mode 100644 index 0000000000..bcc5b686a3 --- /dev/null +++ b/_posts/de/newsletters/2025-08-08-newsletter.md @@ -0,0 +1,289 @@ +--- +title: 'Bitcoin Optech Newsletter #366' +permalink: /de/newsletters/2025/08/08/ +name: 2025-08-08-newsletter-de +slug: 2025-08-08-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche kündigt Entwürfe für BIPs zu Utreexo an, fasst die +anhaltende Diskussion über die Senkung der minimalen Transaktions-Relay-Gebühr +zusammen und beschreibt einen Vorschlag, der es Knoten ermöglicht, ihre +Block-Templates zu teilen, um Probleme mit unterschiedlichen Mempool-Richtlinien +zu mildern. Außerdem enthalten sind unsere regelmäßigen Abschnitte mit einer +Zusammenfassung eines Bitcoin Core PR Review Club Meetings, der Ankündigung neuer +Releases und Release-Kandidaten sowie einer Beschreibung wichtiger Änderungen +an beliebter Bitcoin-Infrastruktur-Software. Wir fügen auch eine Korrektur zum +Newsletter der letzten Woche und eine Empfehlung für unsere Leser hinzu. + +## Nachrichten + +- **Entwürfe für BIPs zu Utreexo vorgeschlagen:** Calvin Kim [veröffentlichte][kim bips] + in der Bitcoin-Dev-Mailingliste drei Entwürfe für BIPs, die er gemeinsam mit + Tadge Dryja und Davidson Souza über das [Utreexo][topic utreexo]-Validierungsmodell + verfasst hat. Der [erste BIP][ubip1] spezifiziert die Struktur des Utreexo-Akkumulators, + der es einem Knoten ermöglicht, ein einfach aktualisierbares Commitment zum + vollständigen UTXO-Set in nur "wenigen Kilobytes" zu speichern. Der [zweite BIP][ubip2] + spezifiziert, wie ein Full Node neue Blöcke und Transaktionen mit dem Akkumulator + validieren kann, anstatt mit einem traditionellen Set von ausgegebenen + Transaktions-Outputs (STXOs, verwendet in frühem Bitcoin Core und aktuellem libbitcoin) + oder nicht ausgegebenen Transaktions-Outputs (UTXOs, verwendet in aktuellem + Bitcoin Core). Der [dritte BIP][ubip3] spezifiziert die Änderungen am Bitcoin-P2P-Protokoll, + der die Übertragung der zusätzlichen Daten ermöglichen, die für die Utreexo-Validierung + benötigt werden. + + Die Autoren suchen ein konzeptionelles Review und werden die Entwürfe der BIPs + basierend auf weiteren Entwicklungen aktualisieren. + +- **Anhaltende Diskussion über die Senkung der minimalen Relay-Gebühr:** + Gloria Zhao [veröffentlichte][zhao minfee] auf Delving Bitcoin einen Beitrag über + die Senkung der [default minimum relay feerate][topic default minimum transaction relay feerates] + um 90% auf 0,1 sat/vbyte. Sie ermutigte zu einer konzeptionellen Diskussion über + die Idee und darüber, wie sie andere Software beeinflussen könnte. Für Bedenken + spezifisch zu Bitcoin Core verwies sie auf einen [Pull Request][bitcoin core #33106]. + +- **Peer-Block-Template-Sharing zur Milderung von Mempool-Richtlinien-Problemen:** Anthony Towns [veröffentlichte][towns tempshare] auf + Delving Bitcoin den Vorschlag, dass Full-Node-Peers sich gelegentlich ihre + aktuellen Templates für den nächsten Block unter Verwendung der + [Compact-Block-Relay][topic compact block relay]-Kodierung zusenden. Der + empfangende Peer könnte dann alle Transaktionen aus dem Template anfordern, + die ihm fehlen, und sie entweder zum lokalen Mempool hinzufügen oder in einem + Cache speichern. Dies würde es Peers mit unterschiedlichen Mempool-Richtlinien + ermöglichen, Transaktionen trotz ihrer Unterschiede zu teilen. Es bietet eine + Alternative zu einem früheren Vorschlag, der die Verwendung von _Weak Blocks_ + vorschlug (siehe [Newsletter #299][news299 weak blocks]). Towns veröffentlichte + eine [Proof-of-Concept-Implementierung][towns tempshare poc]. + +## Bitcoin Core PR Review Club + +*In diesem monatlichen Abschnitt fassen wir ein kürzliches [Bitcoin Core PR Review +Club][] Meeting zusammen und heben einige der wichtigen Fragen und Antworten hervor. +Klicken Sie auf eine Frage unten, um eine Zusammenfassung der Antwort aus dem Meeting +zu sehen.* + +[Add exportwatchonlywallet RPC to export a watchonly version of a +wallet][review club 32489] ist ein PR von [achow101][gh achow101], der die Menge +der manuellen Arbeit reduziert, die zum Erstellen einer Watch-Only-Wallet erforderlich +ist. Vor dieser Änderung mussten Benutzer dies durch Eingabe oder Skripting von +`importdescriptors`-RPC-Aufrufen, Kopieren von Adresslabels usw. erledigen. + +Neben öffentlichen [Deskriptoren][topic descriptors] enthält der Export auch: +- Caches mit abgeleiteten xpubs wenn nötig, z.B. bei gehärteten Ableitungspfaden +- Adressbuch-Einträge, Wallet-Flags und Benutzer-Labels +- alle historischen Wallet-Transaktionen, sodass Rescans unnötig sind + +Die exportierte Wallet-Datenbank kann dann mit dem `restorewallet`-RPC importiert werden. + +{% include functions/details-list.md + q0="Warum können die bestehenden `IsRange()`/`IsSingleType()`-Informationen + uns nicht sagen, ob ein Deskriptor auf der Watch-Only-Seite erweitert werden kann? + Erklären Sie die Logik hinter `CanSelfExpand()` für a) einen gehärteten + `wpkh(xpub/0h/*)`-Pfad und b) einen `pkh(pubkey)`-Deskriptor." + a0="`IsRange()` und `IsSingleType()` waren unzureichend, weil sie + nicht auf gehärtete Ableitung prüfen, die private Schlüssel erfordert, + die in einer Watch-Only-Wallet nicht verfügbar sind. `CanSelfExpand()` wurde hinzugefügt, + um rekursiv nach gehärteten Pfaden zu suchen; wenn es einen findet, gibt es + `false` zurück und signalisiert, dass ein vorab gefüllter Cache für die + Watch-Only-Wallet exportiert werden muss, um Adressen abzuleiten. Ein `pkh(pubkey)`-Deskriptor + ist nicht ranged und hat keine Ableitung, daher kann er sich immer selbst erweitern." + a0link="https://bitcoincore.reviews/32489#l-27" + + q1="`ExportWatchOnlyWallet` kopiert den Deskriptor-Cache nur, wenn + `!desc->CanSelfExpand()`. Was genau wird in diesem Cache gespeichert? Wie + könnte ein unvollständiger Cache die Adressableitung auf der Watch-Only-Wallet beeinträchtigen?" + a1="Der Cache speichert `CExtPubKey`-Objekte für Deskriptoren mit + gehärteten Ableitungspfaden, die auf der ausgabenfähigen Wallet vorab abgeleitet werden. + Wenn dieser Cache unvollständig ist, kann die Watch-Only-Wallet die fehlenden Adressen + nicht ableiten, weil ihr die notwendigen privaten Schlüssel fehlen. Dies würde dazu führen, + dass sie Transaktionen an diese Adressen nicht sieht, was zu einem falschen Guthaben führt." + a1link="https://bitcoincore.reviews/32489#l-52" + + q2="Der Exporter setzt `create_flags = GetWalletFlags() | + WALLET_FLAG_DISABLE_PRIVATE_KEYS`. Warum ist es wichtig, die ursprünglichen + Flags (z.B. `AVOID_REUSE`) zu bewahren, anstatt alles zu löschen und + neu zu beginnen?" + a2="Das Bewahren der Flags stellt Verhaltenskonsistenz zwischen der + ausgabenfähigen und der Watch-Only-Wallet sicher. Zum Beispiel beeinflusst das `AVOID_REUSE`-Flag, + welche Coins als verfügbar für Ausgaben betrachtet werden. Wenn es nicht bewahrt wird, + würde die Watch-Only-Wallet ein anderes verfügbares Guthaben melden als die Haupt-Wallet, + was zu Benutzerverwirrung führt." + a2link="https://bitcoincore.reviews/32489#l-68" + + q3="Warum liest der Exporter den Locator aus der Quell-Wallet und + schreibt ihn wörtlich in die neue Wallet, anstatt die neue Wallet + von Block 0 starten zu lassen?" + a3="Der Block-Locator wird kopiert, um der neuen Watch-Only-Wallet zu sagen, + wo sie das Scannen der Blockchain nach neuen Transaktionen fortsetzen soll, + wodurch die Notwendigkeit eines vollständigen Rescans verhindert wird." + a3link="https://bitcoincore.reviews/32489#l-93" + + q4="Betrachten Sie einen Multisig-Deskriptor `wsh(multi(2,xpub1,xpub2))`. Wenn ein + Mitunterzeichner eine Watch-Only-Wallet exportiert und sie mit einem Dritten teilt, + welche neuen Informationen lernt dieser Dritte im Vergleich dazu, ihm nur + die Deskriptor-Strings zu geben?" + a4="Die Watch-Only-Wallet-Daten enthalten zusätzliche Metadaten wie + Adressbuch, Wallet-Flags und Coin-Control-Labels. Für Wallets mit + gehärteter Ableitung kann der Dritte nur Informationen über + historische und zukünftige Transaktionen durch den Watch-Only-Wallet-Export erhalten." + a4link="https://bitcoincore.reviews/32489#l-100" + + q5="In `wallet_exported_watchonly.py`, warum ruft der Test + `wallet.keypoolrefill(100)` auf, bevor er die Ausgabefähigkeit über das + Online/Offline-Paar prüft?" + a5="Der `keypoolrefill(100)`-Aufruf zwingt die Offline-(Ausgaben-)Wallet, + 100 Schlüssel für ihre gehärteten Deskriptoren vorab abzuleiten und ihren + Cache zu füllen. Dieser Cache wird dann in den Export einbezogen, wodurch die Online + Watch-Only-Wallet diese 100 Adressen generieren kann. Es stellt auch sicher, dass die + Offline-Wallet diese Adressen erkennt, wenn sie eine PSBT zum Signieren erhält." + a5link="https://bitcoincore.reviews/32489#l-122" +%} + +## Optech empfiehlt + +[Bitcoin++ Insider][] hat damit begonnen, leserfinanzierte Nachrichten über +technische Bitcoin-Themen zu veröffentlichen. Zwei ihrer kostenlosen wöchentlichen +Newsletter, _Last Week in Bitcoin_ und _This Week in Bitcoin Core_, könnten +besonders interessant für regelmäßige Leser des Optech-Newsletters sein. + +## Releases und Release-Kandidaten + +_Neue Releases und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. +Bitte erwägen Sie, auf neue Versionen zu aktualisieren oder bei der Testung von +Release-Kandidaten zu helfen._ + +- [LND v0.19.3-beta.rc1][] ist ein Release-Kandidat für eine Wartungsversion dieser + beliebten LN-Knoten-Implementierung, die "wichtige Bugfixes" enthält. Besonders + erwähnenswert ist "eine optionale Migration [...], die Festplatten- und Speicheranforderungen + für Knoten erheblich senkt". + +- [BTCPay Server 2.2.0][] ist ein Release dieser beliebten selbst gehosteten + Zahlungslösung. Es fügt Unterstützung für Wallet-Richtlinien und [Miniscript][topic miniscript] + hinzu, bietet zusätzliche Unterstützung für Transaktionsgebühren-Management und + -Überwachung und beinhaltet mehrere andere neue Verbesserungen und Bugfixes. + +- [Bitcoin Core 29.1rc1][] ist ein Release-Kandidat für eine Wartungsversion der + führenden Full-Node-Software. + +## Wichtige Code- und Dokumentationsänderungen + +_Wichtige aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo] und [BINANAs][binana repo]._ + +- [Bitcoin Core #32941][] vervollständigt die Überarbeitung von `TxOrphanage` (siehe + [Newsletter #364][news364 orphan]), indem es das automatische Trimmen des + Orphanage aktiviert, wann immer dessen Limits überschritten werden. + Es fügt eine Warnung für `maxorphantx`-Benutzer hinzu, um sie darüber zu informieren, + dass es veraltet ist. Dieser PR festigt das opportunistische + One-Parent-One-Child (1p1c) [Package Relay][topic package relay]. + +- [Bitcoin Core #31385][] lockert die + `package-not-child-with-unconfirmed-parents`-Regel des `submitpackage`-RPC, + um die Nutzung von 1p1c [Package Relay][topic package relay] zu verbessern. Pakete + müssen nicht mehr die Eltern-Transaktionen enthalten, die bereits im Mempool des Knotens sind. + +- [Bitcoin Core #31244][] implementiert das Parsen von + [MuSig2][topic musig][Deskriptoren][topic descriptors] wie in [BIP390][] + definiert, was erforderlich ist + für das Empfangen und Ausgeben von Inputs von [Taproot][topic taproot]-Adressen mit + MuSig2-Aggregatschlüsseln. + +- [Bitcoin Core #30635][] beginnt damit, die `waitfornewblock`, + `waitforblock` und `waitforblockheight` RPCs in der Antwort auf den Hilfe-Befehl + anzuzeigen, was signalisiert, dass sie für normale Benutzer gedacht sind. Dieser PR + fügt auch ein optionales `current_tip`-Argument zum `waitfornewblock`-RPC hinzu, + um Race Conditions entgegenzuwirken, indem der Block-Hash der aktuellen Chain-Spitze + spezifiziert wird. + +- [Bitcoin Core #28944][] fügt Anti-[Fee Sniping][topic fee sniping]-Schutz + zu Transaktionen hinzu, die mit den `send`- und `sendall`-RPC-Kommandos gesendet werden, + indem eine zufällige spitzen-bezogene [Locktime][topic timelocks] hinzugefügt wird, + falls noch keine spezifiziert ist. + +- [Eclair #3133][] erweitert sein [HTLC-Endorsement][topic htlc endorsement] lokales + Peer-Reputations-System (siehe [Newsletter #363][news363 reputation]), um die + Reputation von ausgehenden Peers zu bewerten, genau wie bei eingehenden Peers. + Eclair würde nun eine gute Reputation in beide Richtungen berücksichtigen, wenn + ein HTLC weitergeleitet wird, implementiert aber noch keine Strafen. Die Bewertung + ausgehender Peers ist notwendig, um Sink-Attacken zu verhindern (siehe + [Newsletter #322][news322 sink]), eine spezifische Art von + [Channel Jamming Attack][topic channel jamming attacks]. + +- [LND #10097][] führt eine asynchrone, peer-spezifische Warteschlange für Backlog + [Gossip][topic channel announcements]-Anfragen (`GossipTimestampRange`) ein, um + das Risiko von Deadlocks zu eliminieren, wenn ein Peer zu viele Anfragen auf einmal sendet. + Falls ein Peer eine Anfrage sendet, bevor die vorherige abgeschlossen ist, wird die + zusätzliche Nachricht stillschweigend verworfen. Eine neue `gossip.filter-concurrency`-Einstellung + (Standard 5) wird hinzugefügt, um die Anzahl gleichzeitiger Worker über alle Peers hinweg + zu begrenzen. Der PR fügt auch Dokumentation hinzu, die erklärt, wie alle + Gossip-Rate-Limit-Konfigurationseinstellungen funktionieren. + +- [LND #9625][] fügt ein `deletecanceledinvoice`-RPC-Kommando (und sein `lncli`-Äquivalent) + hinzu, das es Benutzern ermöglicht, stornierte [BOLT11][]-Rechnungen zu entfernen (siehe + [Newsletter #33][news33 canceled]), indem sie deren Payment-Hash angeben. + +- [Rust Bitcoin #4730][] fügt einen `Alert`-Typ-Wrapper für die [finale Alert][final alert]-Nachricht + hinzu, die Peers mit einer verwundbaren Version von Bitcoin Core (vor 0.12.1) + benachrichtigt, dass ihr Alert-System unsicher ist. Satoshi führte das Alert-System + ein, um Benutzer über bedeutende Netzwerk-Ereignisse zu informieren, aber es wurde + in Version 0.12.1 [eingestellt][retired], außer für die finale Alert-Nachricht. + +- [BLIPs #55][] fügt [BLIP55][] hinzu, um zu spezifizieren, wie mobile Clients sich + für Webhooks über einen Endpunkt registrieren können, um Push-Benachrichtigungen + von einem LSP zu erhalten. Dieses Protokoll ist nützlich für Clients, um benachrichtigt + zu werden, wenn sie eine [asynchrone Zahlung][topic async payments] erhalten, und + wurde kürzlich in LDK implementiert (siehe [Newsletter #365][news365 webhook]). + +## Korrektur + +Im [Newsletter der letzten Woche][news365 p2qrh] haben wir fälschlicherweise die +aktualisierte Version von [BIP360][], _Pay to Quantum-Resistant Hash_, als +"genau die Änderung machend" beschrieben, die Tim Ruffing in seinem +[kürzlichen Paper][ruffing paper] als sicher gezeigt hat. Was BIP360 tatsächlich macht, +ist das Ersetzen des elliptischen Kurven-Commitments zu einer SHA256-basierten +Merkle-Root (plus einer Keypath-Alternative) durch ein SHA256-Commitment direkt +zur Merkle-Root. Ruffings Paper zeigte, dass Taproot, wie es derzeit verwendet wird, +sicher ist, wenn ein quantum-resistentes Signaturschema zur [Tapscript][topic tapscript]-Sprache +hinzugefügt und Keypath-Ausgaben deaktiviert würden. BIP360 erfordert stattdessen, +dass Wallets auf eine Variante von Taproot upgraden (wenn auch eine triviale Variante), +eliminiert den Keypath-Mechanismus aus seiner Variante und beschreibt das Hinzufügen +eines quantum-resistenten Signaturschemas zur Skriptsprache, die in seinen Tapleaves +verwendet wird. Obwohl Ruffings Paper nicht auf die in BIP360 vorgeschlagene +Taproot-Variante anwendbar ist, folgt die Sicherheit dieser Variante (wenn als +Commitment betrachtet) unmittelbar aus der Sicherheit des Merkle-Baums. + +Wir entschuldigen uns für den Fehler und danken Tim Ruffing dafür, dass er uns +auf unseren Fehler aufmerksam gemacht hat. + +{% include snippets/recap-ad.md when="2025-08-12 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="33106,32941,31385,31244,30635,28944,3133,10097,9625,4730,55" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[bitcoin++ insider]: https://insider.btcpp.dev/ +[news365 p2qrh]: /de/newsletters/2025/08/01/#sicherheit-gegen-quantencomputer-mit-taproot-als-commitment-schema +[zhao minfee]: https://delvingbitcoin.org/t/changing-the-minimum-relay-feerate/1886/ +[towns tempshare]: https://delvingbitcoin.org/t/sharing-block-templates/1906 +[towns tempshare poc]: https://github.com/ajtowns/bitcoin/commit/ee12518a4a5e8932175ee57c8f1ad116f675d089 +[news299 weak blocks]: /en/newsletters/2024/04/24/#weak-blocks-proof-of-concept-implementation +[ruffing paper]: https://eprint.iacr.org/2025/1307 +[kim bips]: https://mailing-list.bitcoindevs.xyz/bitcoindev/3452b63c-ff2b-4dd9-90ee-83fd9cedcf4an@googlegroups.com/ +[ubip1]: https://github.com/utreexo/biptreexo/blob/7ae65222ba82423c1a3f2edd6396c0e32679aa37/utreexo-accumulator-bip.md +[ubip2]: https://github.com/utreexo/biptreexo/blob/7ae65222ba82423c1a3f2edd6396c0e32679aa37/utreexo-validation-bip.md +[ubip3]: https://github.com/utreexo/biptreexo/blob/7ae65222ba82423c1a3f2edd6396c0e32679aa37/utreexo-p2p-bip.md +[btcpay server 2.2.0]: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.2.0 +[lnd v0.19.3-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta.rc1 +[review club 32489]: https://bitcoincore.reviews/32489 +[gh achow101]: https://github.com/achow101 +[news363 reputation]: /de/newsletters/2025/07/18/#eclair-2716 +[news322 sink]: /en/newsletters/2024/09/27/#hybrid-jamming-mitigation-testing-and-changes +[news33 canceled]: /en/newsletters/2019/02/12/#lnd-2457 +[final alert]: https://bitcoin.org/en/release/v0.14.0#final-alert +[retired]: https://bitcoin.org/en/alert/2016-11-01-alert-retirement#updates +[news365 webhook]: /de/newsletters/2025/08/01/#ldk-3662 +[news364 orphan]: /de/newsletters/2025/07/25/#bitcoin-core-31829 \ No newline at end of file From 3a6b313483c96ede393de156dd655cab2716d62a Mon Sep 17 00:00:00 2001 From: editor-Ajian <34365188+editor-Ajian@users.noreply.github.com> Date: Wed, 13 Aug 2025 14:12:02 +0800 Subject: [PATCH 202/278] translate newsletter#365 into ZH-CN (#178) * translate newsletter#365 into ZH-CN * update format * Update _posts/zh/newsletters/2025-08-01-newsletter.md Co-authored-by: Zhiwei(Jeffrey) Hu * Update _posts/zh/newsletters/2025-08-01-newsletter.md Co-authored-by: Zhiwei(Jeffrey) Hu * Update _posts/zh/newsletters/2025-08-01-newsletter.md Co-authored-by: Zhiwei(Jeffrey) Hu * Update _posts/zh/newsletters/2025-08-01-newsletter.md Co-authored-by: Zhiwei(Jeffrey) Hu * Update _posts/zh/newsletters/2025-08-01-newsletter.md Co-authored-by: Zhiwei(Jeffrey) Hu --------- Co-authored-by: Zhiwei(Jeffrey) Hu --- .../zh/newsletters/2025-08-01-newsletter.md | 108 ++++++++++++++++++ 1 file changed, 108 insertions(+) create mode 100644 _posts/zh/newsletters/2025-08-01-newsletter.md diff --git a/_posts/zh/newsletters/2025-08-01-newsletter.md b/_posts/zh/newsletters/2025-08-01-newsletter.md new file mode 100644 index 0000000000..d99971d599 --- /dev/null +++ b/_posts/zh/newsletters/2025-08-01-newsletter.md @@ -0,0 +1,108 @@ +--- +title: 'Bitcoin Optech Newsletter #365' +permalink: /zh/newsletters/2025/08/01/ +name: 2025-08-01-newsletter-zh +slug: 2025-08-01-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- + +本周的新闻部分总结了致密区块中继预填充的测试结果，并链接到了一个基于交易池的手续费估算代码库。此外是我们的常规栏目：总结关于比特币共识规则变更的讨论、软件新版本和测试版本的发行公告，以及流行的比特币基础设施软件的变更介绍。 + +## 新闻 + +- **致密区块预填充测试**：David Gumberg 在 Delving Bitcoin 论坛的一个关于 “致密区块（compact block）” 重构效率的帖子（周报 [#315][news315 cb] 和 [#339][news339 cb] 曾介绍）中[回复][gumberg prefilling]了他从[致密区块中继][topic compact block relay] *预填充* 测试中得到的结果 —— 预填充指的是，当一个节点认为其对等节点可能还不知晓下一个区块将包含的交易时，就抢先把这些交易转发给他们。Gumberg 的帖子非常详细，并且链接了一个 Jupyter 笔记，所以其他人也能自己做实验。要点包括： + + * 在不考虑网络流量时，一个确定要预填充什么交易的简单规则可以将区块重新构造的成功率从 62% 提高到大约 98% 。 + + * 在考虑网络流量时，一些预填充可能会导致额外的通信轮次 —— 这就打消了所有的好处，而且可能会稍微削弱性能。不过，可以通过构造许多预填充来避免这个问题，从而将重新构造的成功率提高到 93%，并且还可以进一步提升。 + +- **基于交易池的手续费估计器代码库**：Lauren Shareshian 在 Delving Bitcoin 论坛中[发帖][shareshian estimation]宣布了一个由 Block 开发的[手续费估算器][topic fee estimation]代码库。与别的一些手续费估计工具不同的是，该代码库只使用进入一个节点的交易池的交易流作为估计的基础。帖子比较了该库（Augur）和多个手续费估计服务，发现 Augur 的失手概率较低（即，超过 85% 的交易在其预计的时间窗口内确认），而且平均高估概率也较低（即，平均来说，交易只比必要水平多付了 16%）。 + + Abrbakar Sadiq Ismail [回复][ismail estimation]了这个帖子，并且在 Augur 代码库中打开了一个信息沟通 [issue][augur #3]，用于检验该库所用的部分假设。 + +## 共识变更 + +*这个月度栏目会总结关于变更比特币共识规则的提议和讨论。* + +- **从量子脆弱的输出迁移**：Jameson Lopp 在 Bitcoin-Dev 邮件组中[发帖][lopp qmig]，提出了一个分成三个步骤、逐渐取消[量子脆弱输出][topic quantum resistance]的提议。 + + * 在 [BIP360][] 量子抗性签名方案（或替代性方案）激活共识的三年之后，激活一个软分叉，从此拒绝支付到量子脆弱地址的交易。只能支付给量子抗性输出。 + + * 再过两年，激活第二个软分叉，拒绝从量子敏感地址花费的交易。任何留在量子脆弱输出中的资金，从此都将不可再花费。 + + * 可选，在不确定的未来，再激活一次共识变更，允许量子脆弱输出中的资金使用一种量子抗性证据方案来花费（[周报 #361][news361 pqcr] 提出了一个例子）。 + + 该帖子的大部分内容是重复此前关于何以在量子计算机足够快之前就必须阻止人们从量子敏感的输出中花费的讨论（详见 [周报 #348][news348 destroy]）。双方都提出了合理的论证，我们希望辩论能够继续。 + +- ******Taproot 原生的 `OP_TEMPLATEHASH` 提议**：Greg Sanders 在 Bitcoin-Dev 邮件组中[发布][sanders th]了一个向 [tapscript][topic tapscript] 添加三个操作码的提议。其中两个是此前已被提议的 [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] 和 `OP_INTERNALKEY`（详见 [周报 #285][news285 ik]）。最后一个是 `OP_TEMPLATEHASH`，是 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] 的 Taproot 原生变种；作者指出原版与变种有以下区别： + + * 不改动传统（隔离见证前）脚本。此前关于这一抉择的讨论见[周报 #361][news361 ctvlegacy]。 + + * 被哈希的数据（以及哈希的顺序）非常类似于为在 [taproot][topic taproot] 承诺的签名而哈希的数据，简化了任何已经支持 taproot 的软件的实现。 + + * 它会承诺 taproot 附言（[annex][topic annex]），而 `OP_CTV` 不会。它的一种用法是，可以用来保证一些数据会作为交易的一部分，比如用在合约式协议中、允许对手方从旧状态的发布中复原的数据。 + + * 它重新定义了一种 `OP_SUCCESSx` 操作码，而不是一种 `OP_NOPx` 操作码。重新定义 `OP_NOPx` 操作码的软分叉必然是 `VERIFY` 操作码，在执行失败时就将交易标记为无效。而重新定义 `OP_SUCCESSx` 操作码的软分叉可以直接在执行后在堆栈中放置 `1`（表示成功）或者 `0`（表示失败）；这让它们在一些情形下可以直接使用，而重新定义的 `OP_NOPx` 则必须用 `OP_IF` 语句这样的条件来封装。 + + * “它防止了与 …… `scriptSig` 一起造成的惊吓”（详见[周报 #361][news361 bitvm]） + + Brandon Black 在[回复][black th]中将该提议与他早先的 LNHANCE 捆绑提议（详见[周报 #285][news285 ik]）相比较，发现两者在绝大部分方面是类型的，虽然他指出，该提议在 *拥堵控制*（一种形式的推迟[支付批量处理][topic payment batching]）用法中链上空间效率较差。 + +- **允许更长时间的相对时间锁**：开发者 Pyth 在 Delving Bitcoin 论坛中[发帖][pyth timelock]建议允许 [BIP68][] 相对时间锁的最大长度从当前的 1 年延长到大约 10 年。这将需要一次软分叉，还要在交易输入的 *sequence* 字段使用额外的一个比特。 + + Fabian Jahr [回复][jahr timelock]了让[时间锁][topic timelocks]变得太长可能导致资金损失的顾虑，比如，因为量子计算机的开发（或者，我们补充一句，因为上文所述的 Jameson Lopp 的量子抵抗协议的开发）。Steven Roose [指出][roose timelock]，长时间时间锁已经能够使用其它时间锁机制来做到了（比如，使用预签名交易和 [BIP65 CLTV][bip65]）。而 Pyth 补充说，它们的目标用途是一条钱包复原路径：长时间锁只会在主要路径变得不可用时派上用场，此时，另一种结局只剩资金永久丢失了。 + +- ******使用 taproot 作为一种承诺方案，安全抵抗量子计算机**：Tim Ruffing 的[帖子][ruffing qtr]链接了一篇他撰写的[论文][ruffing paper]，分析了 [taproot][topic taproot] 承诺抵抗量子计算机篡改的安全性。他检验了 [tapscript][topic tapscript] 的 taproot 承诺是否还能继续持有像对抗传统计算机那样的 *绑定* 和 *隐藏* 属性。他的结论是： + + > 量子攻击者需要执行至少 2^81 次 SHA256 求值，才能以 1/2 的概率创建一个 Taproot 输出、并用意料之外的默克尔根来打开这个输出。如果攻击者的量子计算机的 SHA256 计算的最长序列限制在 2^20 ，那么 TA 需要至少 2^92 台这样的机器，才能让成功率达到 1/2 。 + + 如果 taproot 承诺可以抵抗量子计算机的篡改，那么只需禁用 taproot 密钥花费、向 [tapscript][topic tapscript] 添加抗量子签名检查操作码，就可以向比特币添加量子抗性。Ethan Heilma 在 Bitcoin-Dev 邮件组中发布的[帖子][heilman bip360]，对 [BIP360][] “支付到量子抗性哈希值” 的最新更新，作出的正是这样的变更。 + +## 新版本和候选版本 + +*流行的比特币基础设施项目的新版本和候选版本。请考虑升级到新版本，或帮助测试候选版本。* + +- [Bitcoin Core 29.1rc1][] 是这个主流的全节点软件的维护版本的候选发行。 + +## 重要的代码和说明书变更 + +*本周出现重大变更的有：[Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement Proposals (BIPs)][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo]。* + +- [Bitcoin Core #29954][] 通过加入两个转发策略字段到其响应对象中，延申了 `getmempoolinfo` RPC：`permitbaremultisig`（节点是否转发裸多签名输出）和 `maxdatacarriersite`（交易池中一笔交易的 OP_RETURN 输出可允许的合并最大字节量）。其他策略标签，比如 [`fullrbf`][topic rbf] 和 `minrelaytxfee`，已经暴露了，所以添加的字段实现了完整的转发策略快照。 + +- [Bitcoin Core #33004][] 默认启用 `-natpmp` 选项，允许通过 “端口控制协议（[PCP][pcp]）” 的自动端口转发，并带有 “NAT 端口映射协议（59）”的后备机制（详见周报[#323][news323 natpmp]）。在支持 PCP 或 NAT-PMP 的路由器背后的监听节点，都可访问，无需手动配置。 + +- [LDK #3246][] 允许使用 offer 的 `signing_pubkey` 作为目的地、不使用[盲化路径][topic rv routing]来创建 [ BOLT12 Offer][topic offers] 和退款。`create_offer_builder` 和 `create_refund_builder` 函数现在将盲化路径的创建委托给 `MessageRouter::create_blinded_paths`；在其中，调用者可以通过传入 `DefaultMessageRouter` 来生成一条紧凑的路径、传入 `NodeIdMessageRouter` 来生成全长度的公钥路径，或传入 `NodeIdMessageRouter` 来生成空路径。 + +- [LDK #3892][] 将 [BOLT12][topic offers] 发票的默克尔树签名公开暴露，允许开发者构建命令行工具或其他软件来验证签名和重新创建发票。这项 PR 还添加了一个 `OfferId` 字段到 BOLT12 发票中，以跟踪源头 offer 。 + +- [LDK #3662][] 实现了 [BLIPs #55][]，也被称作 “LSPS05”，它定义了客户端如何通过一个端点（endpoint）来注册 webhook，从而可以接收来自一个 LSP 的通知。这个 API 暴露了额外的端点，让客户端可以列出所有的 webhook 注册，还可以移除具体的一个。在接收[异步支付][topic async payments]时，获得通知到客户端来说很有用。 + +{% include references.md %} +{% include linkers/issues.md v=2 issues="29954,33004,3246,3892,3662,55" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[augur #3]: https://github.com/block/bitcoin-augur/issues/3 +[news315 cb]: /zh/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction +[news339 cb]: /zh/newsletters/2025/01/31/#updated-stats-on-compact-block-reconstruction +[gumberg prefilling]: https://delvingbitcoin.org/t/stats-on-compact-block-reconstructions/1052/34 +[shareshian estimation]: https://delvingbitcoin.org/t/augur-block-s-open-source-bitcoin-fee-estimation-library/1848/ +[ismail estimation]: https://delvingbitcoin.org/t/augur-block-s-open-source-bitcoin-fee-estimation-library/1848/2 +[news361 pqcr]: /zh/newsletters/2025/07/04/#commit-reveal-function-for-post-quantum-recovery +[sanders th]: https://mailing-list.bitcoindevs.xyz/bitcoindev/26b96fb1-d916-474a-bd23-920becc3412cn@googlegroups.com/ +[news285 ik]: /zh/newsletters/2024/01/17/#lnhance +[news361 ctvlegacy]: /zh/newsletters/2025/07/04/#concerns-and-alternatives-to-legacy-support +[pyth timelock]: https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818/ +[jahr timelock]: https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818/2 +[roose timelock]: https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818/3 +[ruffing qtr]: https://mailing-list.bitcoindevs.xyz/bitcoindev/bee6b897379b9ae0c3d48f53d40a6d70fe7915f0.camel@real-or-random.org/ +[ruffing paper]: https://eprint.iacr.org/2025/1307 +[heilman bip360]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAEM=y+W=rtU2PLmHve6pUVkMQQmqT67KOg=9hp5oMspuHrgMow@mail.gmail.com/ +[lopp qmig]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CADL_X_fpv-aXBxX+eJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q@mail.gmail.com/ +[news348 destroy]: /zh/newsletters/2025/04/04/#should-vulnerable-bitcoins-be-destroyed +[black th]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aG9FEHF1lZlK6d0E@console/ +[news361 bitvm]: /zh/newsletters/2025/07/04/#continued-discussion-about-ctv-csfs-advantages-for-bitvm +[news323 natpmp]: /zh/newsletters/2024/10/04/#bitcoin-core-30043 +[pcp]: https://datatracker.ietf.org/doc/html/rfc6887 +[natpmp]: https://datatracker.ietf.org/doc/html/rfc6886 From 0c544b9ec524818d70351cc8b47b17cd9f934639 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Wed, 13 Aug 2025 11:33:13 -0500 Subject: [PATCH 203/278] Podcast: add 366 recap --- .../en/newsletters/2025-08-08-newsletter.md | 43 ++++++++++--------- .../en/podcast/2025-08-12-newsletter-recap.md | 24 +++++++++++ 2 files changed, 46 insertions(+), 21 deletions(-) create mode 100644 _posts/en/podcast/2025-08-12-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-08-08-newsletter.md b/_posts/en/newsletters/2025-08-08-newsletter.md index 9b07ae063b..e0d39e3c73 100644 --- a/_posts/en/newsletters/2025-08-08-newsletter.md +++ b/_posts/en/newsletters/2025-08-08-newsletter.md @@ -34,7 +34,7 @@ recommendation to readers. allow transferring the additional data need for Utreexo validation. The authors are seeking conceptual review and will be updating the - draft BIPs based on further developments. + draft BIPs based on further developments. {% assign timestamp="1:03" %} - **Continued discussion about lowering the minimum relay feerate:** Gloria Zhao [posted][zhao minfee] to Delving Bitcoin about lowering @@ -42,7 +42,7 @@ recommendation to readers. relay feerates] by 90% to 0.1 sat/vbyte. She encouraged conceptual discussion about the idea and how it might affect other software. For concerns specific to Bitcoin Core, she linked to a [pull - request][bitcoin core #33106]. + request][bitcoin core #33106]. {% assign timestamp="23:43" %} - **Peer block template sharing to mitigate problems with divergent mempool policies:** Anthony Towns [posted][towns tempshare] to Delving Bitcoin to suggest @@ -55,7 +55,7 @@ recommendation to readers. their differences. It provides an alternative to a previous proposal that suggested using _weak blocks_ (see [Newsletter #299][news299 weak blocks]). Towns published a [proof-of-concept implementation][towns - tempshare poc]. + tempshare poc]. {% assign timestamp="52:27" %} ## Bitcoin Core PR Review Club @@ -64,8 +64,8 @@ Club][] meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.* -[Add exportwatchonlywallet RPC to export a watchonly version of a -wallet][review club 32489] is a PR by [achow101][gh achow101] that +[Add exportwatchonlywallet RPC to export a watchonly version of a wallet][review club 32489] +is a PR by [achow101][gh achow101] that reduces the amount of manual work required to create a watch-only wallet. Before this change, users had to do that by typing or scripting `importdescriptors` RPC calls, copying address labels, etc. @@ -80,7 +80,6 @@ export also contains: The exported wallet database can then be imported with the `restorewallet` RPC. - {% include functions/details-list.md q0="Why can’t the existing `IsRange()`/`IsSingleType()` information tell us whether a descriptor can be expanded on the watch-only side? @@ -149,12 +148,14 @@ The exported wallet database can then be imported with the a5link="https://bitcoincore.reviews/32489#l-122" %} +{% assign timestamp="1:11:41" %} + ## Optech recommends [Bitcoin++ Insider][] has begun publishing reader-funded news about technical Bitcoin topics. Two of their free weekly newsletters, _Last Week in Bitcoin_ and _This Week in Bitcoin Core_, may be especially -interesting to regular readers of the Optech newsletter. +interesting to regular readers of the Optech newsletter. {% assign timestamp="1:15:50" %} ## Releases and release candidates @@ -165,16 +166,16 @@ release candidates._ - [LND v0.19.3-beta.rc1][] is a release candidate for a maintenance version for this popular LN node implementation containing "important bug fixes". Most notably, "an optional migration [...] lowers disk and memory requirements for - nodes significantly." + nodes significantly." {% assign timestamp="1:17:04" %} - [BTCPay Server 2.2.0][] is a release of this popular self-hosted payment solution. It adds support for wallet policies and [miniscript][topic miniscript], provides additional support for transaction fee management and monitoring, and includes several other new improvements - and bug fixes. + and bug fixes. {% assign timestamp="1:17:44" %} - [Bitcoin Core 29.1rc1][] is a release candidate for a maintenance - version of the predominant full node software. + version of the predominant full node software. {% assign timestamp="1:18:13" %} ## Notable code and documentation changes @@ -192,29 +193,29 @@ repo], and [BINANAs][binana repo]._ orphanage whenever its limits are exceeded. It adds a warning for `maxorphantx` users to inform them that it is obsolete. This PR solidifies opportunistic - one-parent-one-child (1p1c) [package relay][topic package relay]. + one-parent-one-child (1p1c) [package relay][topic package relay]. {% assign timestamp="1:21:11" %} - [Bitcoin Core #31385][] relaxes the `package-not-child-with-unconfirmed-parents` rule of the `submitpackage` RPC to improve 1p1c [package relay][topic package relay] usage. Packages - no longer need to include the parents that are already in the node's mempool. + no longer need to include the parents that are already in the node's mempool. {% assign timestamp="1:24:06" %} - [Bitcoin Core #31244][] implements the parsing of [MuSig2][topic musig] [descriptors][topic descriptors] as defined in [BIP390][], which is required for receiving and spending inputs from [taproot][topic taproot] addresses with - MuSig2 aggregate keys. + MuSig2 aggregate keys. {% assign timestamp="1:26:38" %} - [Bitcoin Core #30635][] begins displaying the `waitfornewblock`, `waitforblock`, and `waitforblockheight` RPCs in the help command response, indicating that they're meant for regular users. This PR also adds an optional `current_tip` argument to the `waitfornewblock` RPC, to mitigate against race conditions by specifying the block hash - of the current chain tip. + of the current chain tip. {% assign timestamp="1:29:54" %} - [Bitcoin Core #28944][] adds anti-[fee sniping][topic fee sniping] protection to transactions sent with the `send` and `sendall` RPC commands by adding a random tip-relative [locktime][topic timelocks] if one is not already - specified. + specified. {% assign timestamp="1:32:29" %} - [Eclair #3133][] extends its [HTLC endorsement][topic htlc endorsement] local peer-reputation system (see [Newsletter #363][news363 reputation]) to score the @@ -222,7 +223,7 @@ repo], and [BINANAs][binana repo]._ consider a good reputation in both directions when forwarding an HTLC, but doesn’t implement penalties yet. Scoring outgoing peers is necessary to prevent sink attacks (see [Newsletter #322][news322 sink]), a specific type of - [channel jamming attack][topic channel jamming attacks]. + [channel jamming attack][topic channel jamming attacks]. {% assign timestamp="1:35:08" %} - [LND #10097][] introduces an asynchronous, per-peer queue for backlog [gossip][topic channel announcements] requests (`GossipTimestampRange`) to @@ -231,23 +232,23 @@ repo], and [BINANAs][binana repo]._ message is quietly dropped. A new `gossip.filter-concurrency` setting (default 5) is added to limit the number of concurrent workers across all peers. The PR also adds documentation explaining how all gossip rate limit configuration - settings work. + settings work. {% assign timestamp="1:36:23" %} - [LND #9625][] adds a `deletecanceledinvoice` RPC command (and its `lncli` equivalent) that allows users to remove canceled [BOLT11][] invoices (see - [Newsletter #33][news33 canceled]) by providing their payment hash. + [Newsletter #33][news33 canceled]) by providing their payment hash. {% assign timestamp="1:38:12" %} - [Rust Bitcoin #4730][] adds an `Alert` type wrapper for the [final alert][] message that notifies peers running a vulnerable version of Bitcoin Core (before 0.12.1) that their alert system is insecure. Satoshi introduced the alert system to notify users of significant network events, but it was - [retired][] in version 0.12.1, except for the final alert message. + [retired][] in version 0.12.1, except for the final alert message. {% assign timestamp="1:38:43" %} - [BLIPs #55][] adds [BLIP55][] to specify how mobile clients can register for webhooks via an endpoint to receive push notifications from an LSP. This protocol is useful for clients to get notified when receiving an [async payment][topic async payments], and was recently implemented in LDK (See - [Newsletter #365][news365 webhook]). + [Newsletter #365][news365 webhook]). {% assign timestamp="1:40:57" %} ## Correction @@ -268,7 +269,7 @@ taproot proposed in BIP360, the security of this variant (when viewed as a commitment) follows immediately from the security of the merkle tree. We apologize for the error and thank Tim Ruffing for notifying us about -our mistake. +our mistake. {% assign timestamp="1:42:03" %} {% include snippets/recap-ad.md when="2025-08-12 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-08-12-newsletter-recap.md b/_posts/en/podcast/2025-08-12-newsletter-recap.md new file mode 100644 index 0000000000..4e4889d990 --- /dev/null +++ b/_posts/en/podcast/2025-08-12-newsletter-recap.md @@ -0,0 +1,24 @@ +--- +title: 'Bitcoin Optech Newsletter #366 Recap Podcast' +permalink: /en/podcast/2025/08/12/ +reference: /en/newsletters/2025/08/08/ +name: 2025-08-12-recap +slug: 2025-08-12-recap +type: podcast +layout: podcast-episode +lang: en +--- +Gloria Zhao and Mike Schmidt are joined by Tadge Dryja and Anthony Towns to discuss +[Newsletter #366]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-7-13/405609342-44100-2-47f0d9e5e9be6.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From 4905ca31b0a5227fe8c1732149dc4ef347feb103 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Wed, 13 Aug 2025 20:27:14 -1000 Subject: [PATCH 204/278] Newsletters: add 367 (2025-08-15) --- .../en/newsletters/2025-08-15-newsletter.md | 55 +++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 _posts/en/newsletters/2025-08-15-newsletter.md diff --git a/_posts/en/newsletters/2025-08-15-newsletter.md b/_posts/en/newsletters/2025-08-15-newsletter.md new file mode 100644 index 0000000000..92bec76c2e --- /dev/null +++ b/_posts/en/newsletters/2025-08-15-newsletter.md @@ -0,0 +1,55 @@ +--- +title: 'Bitcoin Optech Newsletter #367' +permalink: /en/newsletters/2025/08/15/ +name: 2025-08-15-newsletter +slug: 2025-08-15-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter includes our regular sections announcing new +release candidates and summarizing notable changes to popular Bitcoin +infrastructure software. + +## News + +_No significant news this week was found in any of our [sources][optech sources]._ + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [LND v0.19.3-beta.rc1][] is a release candidate for a maintenance + version for this popular LN node implementation containing "important + bug fixes". Most notably, "an optional migration [...] lowers disk + and memory requirements for nodes significantly." + +- [Bitcoin Core 29.1rc1][] is a release candidate for a maintenance + version of the predominant full node software. + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [Bitcoin Core #33050][] net, validation: don't punish peers for consensus-invalid txs + +- [Bitcoin Core #32473][] Introduce per-txin sighash midstate cache for legacy/p2sh/segwitv0 scripts + +- [Bitcoin Core #33077][] kernel: create monolithic kernel static library + +- [Core Lightning #8389][] lightningd: make option_channel_type compulsory. + +{% include snippets/recap-ad.md when="2025-08-19 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="33050,32473,33077,8389" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[lnd v0.19.3-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta.rc1 From b38d154c583cf3d8881635ef620eb5bd2b50e999 Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Fri, 15 Aug 2025 05:27:03 +0000 Subject: [PATCH 205/278] News367: add merge summaries --- .../en/newsletters/2025-08-15-newsletter.md | 34 ++++++++++++++++--- 1 file changed, 30 insertions(+), 4 deletions(-) diff --git a/_posts/en/newsletters/2025-08-15-newsletter.md b/_posts/en/newsletters/2025-08-15-newsletter.md index 92bec76c2e..8c44916329 100644 --- a/_posts/en/newsletters/2025-08-15-newsletter.md +++ b/_posts/en/newsletters/2025-08-15-newsletter.md @@ -40,16 +40,42 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Bitcoin Core #33050][] net, validation: don't punish peers for consensus-invalid txs +- [Bitcoin Core #33050][] removes peer discouragement (see Newsletter + [#309][news309 peer]) for consensus-invalid transactions because its DoS + protection was ineffective. An attacker could circumvent the protection by + spamming policy-invalid transactions without penalty. This update eliminates + the need for double script validation because it is no longer necessary to + distinguish between consensus and standardness failures, saving CPU costs. -- [Bitcoin Core #32473][] Introduce per-txin sighash midstate cache for legacy/p2sh/segwitv0 scripts +- [Bitcoin Core #32473][] introduces a per-input cache for sighash + pre-computation to the script interpreter for legacy (e.g. baremultisig), + P2SH, P2WSH (and incidentally P2WPKH) inputs to reduce the impact of quadratic + hashing attacks in standard transactions. Core caches an almost finished hash + computed just before appending the sighash byte to reduce repeated hashing for + standard multisig transactions and similar patterns. Another signature in the + same input with the same sighash mode that commits to the same portion of the + script can reuse most of the work. It is enabled in both policy (mempool) and + consensus (block) validation. [Taproot][topic taproot] inputs already have + that behavior by default, so this update doesn't need to be applied to them. -- [Bitcoin Core #33077][] kernel: create monolithic kernel static library +- [Bitcoin Core #33077][] creates a monolithic static library + [`libbitcoinkernel.a`][libbitcoinkernel project] that bundles all the object + files of its private dependencies into a single archive, allowing downstream + projects to link to just this one file. See [Newsletter #360][news360 kernel] + for related `libsecp256k1` groundwork. -- [Core Lightning #8389][] lightningd: make option_channel_type compulsory. +- [Core Lightning #8389][] makes the `channel_type` field mandatory when opening + a channel, aligning with a recent specification update (see [Newsletter + #364][news364 spec]). The RPC commands `fundchannel` and `fundchannel_start` + now report a channel type with the [zero-conf channel][topic zero-conf + channels] option when a zero `minimum_depth` implies it. {% include snippets/recap-ad.md when="2025-08-19 16:30" %} {% include references.md %} {% include linkers/issues.md v=2 issues="33050,32473,33077,8389" %} [bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ [lnd v0.19.3-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta.rc1 +[news309 peer]: /en/newsletters/2024/06/28/#bitcoin-core-29575 +[news360 kernel]: /en/newsletters/2025/06/27/#libsecp256k1-1678 +[libbitcoinkernel project]: https://github.com/bitcoin/bitcoin/issues/27587 +[news364 spec]: /en/newsletters/2025/07/25/#bolts-1232 From 50a0522ffef688af2da6db4cd7cf04386c5811e3 Mon Sep 17 00:00:00 2001 From: azuchi Date: Sat, 16 Aug 2025 16:09:09 +0900 Subject: [PATCH 206/278] Newsletter-367:Translate into Japanese --- .../ja/newsletters/2025-08-15-newsletter.md | 74 +++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 _posts/ja/newsletters/2025-08-15-newsletter.md diff --git a/_posts/ja/newsletters/2025-08-15-newsletter.md b/_posts/ja/newsletters/2025-08-15-newsletter.md new file mode 100644 index 0000000000..140866098a --- /dev/null +++ b/_posts/ja/newsletters/2025-08-15-newsletter.md @@ -0,0 +1,74 @@ +--- +title: 'Bitcoin Optech Newsletter #367' +permalink: /ja/newsletters/2025/08/15/ +name: 2025-08-15-newsletter-ja +slug: 2025-08-15-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、新しいリリース候補の発表や +人気のBitcoinインフラストラクチャソフトウェアの注目すべき更新など +恒例のセクションを掲載しています。 + +## ニュース + +_今週は、どの[情報源][optech sources]からも重要なニュースは見つかりませんでした。_ + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [LND v0.19.3-beta.rc1][]は、この人気のLNノード実装のメンテナンスバージョンのリリース候補で、 + 「重要なバグ修正」が含まれています。最も注目すべきは、「オプションの移行で[…] + ノードのディスクおよびメモリ要件が大幅に削減される」ことです。 + +- [Bitcoin Core 29.1rc1][]は、主要なフルノードソフトウェアのメンテナンスバージョンのリリース候補です。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Bitcoin Core #33050][]は、コンセンサスが無効なトランザクションに対する + ピアの排除機能（ニュースレター[#309][news309 peer]参照）を削除しました。 + これは、DoSの保護が効果的でなかったためです。攻撃者は、ポリシー上無効なトランザクションをスパムすることで、 + ペナルティなしでこの保護を回避できました。このアップデートにより、 + コンセンサスの失敗と標準（ポリシー）の失敗を区別する必要がなくなったため、 + スクリプトの二重検証が不要になり、CPUコストを削減できます。 + +- [Bitcoin Core #32473][]は、標準トランザクションに対する二次的なハッシュ計算攻撃の影響を軽減するため、 + スクリプトインタプリタに、レガシー（例：ベアマルチシグ）、P2SH、P2WSH（そしてついでにP2WPKH）インプットに対する + sighashの事前計算用のインプット毎のキャッシュを導入します。Coreは、 + 標準的なマルチシグトランザクションや同様のパターンでのハッシュ計算の繰り返しを削減するために、 + sighashバイトを追加する直前までに計算されたほぼ完成済みのハッシュをキャッシュします。 + 同じインプットの別の署名で、同じsighashモードを使用し、スクリプトの同じパーツにコミットするものは、 + 計算の大部分を再利用できます。これはポリシー（mempool）とコンセンサス（ブロック）の両方の検証で有効になっています。 + [Taproot][topic taproot]のインプットは、デフォルトでこの動作を既にしているため、 + このアップデートを適用する必要はありません。 + +- [Bitcoin Core #33077][]は、プライベートな依存関係のすべてのオブジェクトファイルを + 単一のアーカイブにバンドルする、モノリシックな静的ライブラリ[`libbitcoinkernel.a`][libbitcoinkernel project]を作成し、 + 下流のプロジェクトが、この1つのファイルのみにリンクできるようにします。 + 関連する`libsecp256k1`の基盤については、[ニュースレター #360][news360 kernel]をご覧ください。 + +- [Core Lightning #8389][]は、最近の仕様の更新（[ニュースレター #364][news364 spec]参照）に合わせて、 + チャネルを開く際に`channel_type`フィールドを必須にします。RPCコマンド`fundchannel`および + `fundchannel_start`は、`minimum_depth`が0の場合に、 + [ゼロ承認チャネル][topic zero-conf channels]オプションのチャネルタイプを報告するようになります。 + +{% include snippets/recap-ad.md when="2025-08-19 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="33050,32473,33077,8389" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[lnd v0.19.3-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta.rc1 +[news309 peer]: /ja/newsletters/2024/06/28/#bitcoin-core-29575 +[news360 kernel]: /ja/newsletters/2025/06/27/#libsecp256k1-1678 +[libbitcoinkernel project]: https://github.com/bitcoin/bitcoin/issues/27587 +[news364 spec]: /ja/newsletters/2025/07/25/#bolts-1232 From 472a3cf854a533db2f5e828ba4e49a10b83a4857 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Mon, 18 Aug 2025 21:36:08 +0200 Subject: [PATCH 207/278] newsletter(367): fix newsletter reference style (#2465) --- _posts/en/newsletters/2025-08-15-newsletter.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/_posts/en/newsletters/2025-08-15-newsletter.md b/_posts/en/newsletters/2025-08-15-newsletter.md index 8c44916329..5772a64010 100644 --- a/_posts/en/newsletters/2025-08-15-newsletter.md +++ b/_posts/en/newsletters/2025-08-15-newsletter.md @@ -40,8 +40,9 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Bitcoin Core #33050][] removes peer discouragement (see Newsletter - [#309][news309 peer]) for consensus-invalid transactions because its DoS +- [Bitcoin Core #33050][] removes peer discouragement (see [Newsletter + #309][news309 peer]) for consensus-invalid transactions because its DoS + protection was ineffective. An attacker could circumvent the protection by protection was ineffective. An attacker could circumvent the protection by spamming policy-invalid transactions without penalty. This update eliminates the need for double script validation because it is no longer necessary to From 606558c537a0a93ca36d5040ecf595df417089a8 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Mon, 18 Aug 2025 21:38:32 +0200 Subject: [PATCH 208/278] Newsletter 365 translate in French (#2458) --- .../fr/newsletters/2025-08-01-newsletter.md | 222 ++++++++++++++++++ 1 file changed, 222 insertions(+) create mode 100644 _posts/fr/newsletters/2025-08-01-newsletter.md diff --git a/_posts/fr/newsletters/2025-08-01-newsletter.md b/_posts/fr/newsletters/2025-08-01-newsletter.md new file mode 100644 index 0000000000..3fe6d003f9 --- /dev/null +++ b/_posts/fr/newsletters/2025-08-01-newsletter.md @@ -0,0 +1,222 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #365' +permalink: /fr/newsletters/2025/08/01/ +name: 2025-08-01-newsletter-fr +slug: 2025-08-01-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine résume les résultats d'un test de préremplissage de bloc compact et +fournit un lien vers une bibliothèque d'estimation des frais basée sur le mempool. +Sont également incluses nos sections régulières résumant les récentes discussions sur +la modification des règles de consensus de Bitcoin, annonçant des mises à jour et des versions candidates, +et décrivant les changements notables dans les projets d'infrastructure Bitcoin populaires. + +## Nouvelles + +- **Test du préremplissage de bloc compact :** David Gumberg a [répondu][gumberg prefilling] à un + fil de discussion Delving Bitcoin sur l'efficacité de la reconstruction de bloc compact + (précédemment couverte dans les Bulletins [315][news315 cb] et [339][news339 cb]) avec un résumé + des résultats qu'il a obtenus en testant le [relais de bloc compact][topic compact block relay] + _préremplir_---une node relayant de manière préventive certaines ou toutes les transactions + d'un nouveau bloc à ses pairs lorsqu'elle pense que les pairs peuvent ne pas déjà avoir ces + transactions. Le post de Gumberg est détaillé et fournit un lien vers un cahier Jupyter pour + permettre à d'autres d'expérimenter par eux-mêmes. Les points clés incluent : + + - Considéré indépendamment du transport réseau, une règle simple pour déterminer quelles + transactions préremplir a augmenté le taux de reconstructions de blocs réussies d'environ 62% à + environ 98%. + + - Lors de la prise en compte du transport réseau, certains préremplissages peuvent avoir résulté en + un aller-retour supplémentaire---annulant tout bénéfice dans ce cas et possiblement dégradant + légèrement la performance. Cependant, de nombreux préremplissages auraient pu être construits pour + éviter le problème, augmentant le taux de reconstruction probable à environ 93% et soutenant encore + des améliorations. + +- **Bibliothèque d'estimation des frais basée sur le mempool :** Lauren Shareshian a + [posté][shareshian estimation] sur Delving Bitcoin pour annoncer une bibliothèque pour l'[estimation + des frais][topic fee estimation] développée par Block. Contrairement à certains autres outils + d'estimation des frais, elle utilise uniquement le flux de transactions entrant dans le mempool d'un + nœud comme base de ses estimations. Le post compare la bibliothèque, Augur, à plusieurs services + d'estimation des frais et trouve qu'Augur a un faible taux d'échec (c'est-à-dire, plus de 85% des + transactions se confirment dans leur fenêtre prévue) et un faible taux de surestimation moyen + (c'est-à-dire, les transactions paient des frais supérieurs d'environ 16% à ce qui est nécessaire). + + Abubakar Sadiq Ismail a [répondu][ismail estimation] au fil Delving et a également commencé un + [problème][augur #3] informatif sur le dépôt Augur pour examiner certaines des hypothèses utilisées + par la bibliothèque. + +## Modification du consensus + +_Une nouvelle section mensuelle résumant les propositions et discussions sur la modification des +règles de consensus de Bitcoin._ + +- **Migration à partir des sorties vulnérables aux quantiques :** Jameson Lopp a [posté][lopp qmig] + sur la liste de diffusion Bitcoin-Dev une proposition en trois étapes pour éliminer progressivement + les dépenses à partir des [sorties vulnérables aux quantiques][topic quantum resistance]. + + - Trois ans après l'activation par consensus du schéma de signature résistant aux quantiques + [BIP360][] (ou un schéma alternatif), un soft fork rejetterait les transactions avec des sorties + payant des adresses vulnérables au quantique. Seules les dépenses vers des sorties résistantes au quantique + seraient autorisées. + + - Deux ans plus tard, un second soft fork rejetterait les dépenses provenant de sorties vulnérables + au quantique. Tout fond restant dans des sorties vulnérables au quantique deviendrait inutilisable. + + - Optionnellement, à un moment non défini ultérieurement, un changement de consensus pourrait + permettre les dépenses depuis des sorties vulnérables aux quantique en utilisant un schéma de preuve + résistant aux quantique (voir le [Bulletin #361][news361 pqcr] pour un exemple). + + La plupart des discussions dans le fil de discussion ont largement répété les discussions + précédentes sur la nécessité d'empêcher les gens de dépenser des bitcoins vulnérables aux quantique + avant qu'il soit certain qu'un ordinateur quantique assez rapide pour les voler existait (voir le + [Bulletin 348][news348 destroy]). Des arguments raisonnables ont été avancés des deux côtés et + nous devons nous attendre à ce que ce débat continue. + +- **Proposition de `OP_TEMPLATEHASH` natif à Taproot :** Greg Sanders a [posté][sanders th] sur la + liste de diffusion Bitcoin-Dev une proposition pour ajouter trois opcodes à [tapscript][topic + tapscript]. Deux des opcodes sont les [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] et + `OP_INTERNALKEY` précédemment proposés (voir le [Bulletin 285][news285 ik]). Le dernier opcode est + `OP_TEMPLATEHASH`, une variation native à taproot de [OP_CHECKTEMPLATEVERIFY][topic + op_checktemplateverify] (`OP_CTV`) avec les différences suivantes soulignées par les auteurs : + + - Pas de changements pour les scripts legacy (pré-segwit). + Voir le [Bulletin #361][news361 ctvlegacy] + pour une précédente discussion sur cette alternative. + + - Les données qui sont hashées (et l'ordre dans lequel elles sont hashées) sont très similaires aux + données hashées pour les signatures afin de s'engager dans [taproot][topic taproot], simplifiant + l'implémentation pour tout logiciel qui supporte déjà taproot. + + - Cela s'engage sur l'[annexe][topic annex] de taproot, ce que `OP_CTV` ne fait pas. Une manière + d'utiliser cela est de s'assurer que certaines données sont publiées dans le cadre d'une + transaction, comme des données utilisées dans un protocole de contrat pour permettre à une + contrepartie de se récupérer de la publication d'un ancien état. + + - Cela redéfinit un opcode `OP_SUCCESSx` plutôt qu'un opcode `OP_NOPx`. Les soft forks redéfinissant + les opcodes `OP_NOPx` doivent être des opcodes `VERIFY` qui marquent la transaction comme invalide + s'ils échouent. Les redéfinitions d'opcodes `OP_SUCCESSx` peuvent simplement placer soit `1` + (succès) soit `0` (échec) sur la pile après exécution ; cela leur permet d'être utilisés directement + dans des cas où les redéfinitions de `OP_NOPx` devraient être enveloppées par des conditionnels tels + que les instructions `OP_IF`. + + - "Cela empêche de surprendre les entrées avec ... `scriptSig`" + (voir le [Bulletin #361][news361 bitvm] ). + + Brandon Black a [répondu][black th] avec une comparaison de la proposition à sa précédente + proposition de bundle LNHANCE (voir le [Bulletin 285][news285 ik]) et l'a trouvée comparable à bien + des égards, bien qu'il ait noté qu'elle est moins efficace en espace onchain pour le _contrôle de + congestion_ (une forme de paiement différé de [regroupement des paiements][topic payment batching]). + +- **Proposition pour permettre des timelocks relatifs plus longs :** le développeur Pyth a + [posté][pyth timelock] sur Delving Bitcoin pour suggérer de permettre aux timelocks relatifs + [BIP68][] d'être étendus de leur maximum actuel d'environ un an à un nouveau maximum d'environ dix + ans. Cela nécessiterait un soft fork et l'utilisation d'un bit supplémentaire du champ _sequence_ de + l'entrée de transaction. + + Fabian Jahr a [répondu][jahr timelock] avec une préoccupation que des [timelocks][topic timelocks] + trop éloignés dans le futur pourraient conduire à une perte de fonds, comme en raison du + développement des ordinateurs quantiques (ou, nous ajoutons, le déploiement de protocoles de défense + quantique tels que la proposition de Jameson Lopp décrite plus tôt dans ce bulletin). Steven + Roose a [noté][roose timelock] que des timelocks très éloignés dans le futur sont déjà possibles en + utilisant d'autres mécanismes de verrouillage temporel (tels que les transactions pré-signées et + [BIP65 CLTV][bip65]), et Pyth a ajouté que leur cas d'utilisation souhaité est pour un chemin de + récupération de portefeuille où le long timelock ne serait utilisé que si le chemin principal + devenait indisponible et l'alternative serait de toute façon la perte permanente des fonds. + +- **Sécurité contre les ordinateurs quantiques avec taproot comme schéma d'engagement :** Tim + Ruffing a [posté][ruffing qtr] un lien vers un [papier][ruffing paper] qu'il a écrit analysant la + sécurité des engagements [taproot][topic taproot] contre la manipulation par des ordinateurs + quantiques. Il examine si les engagements taproot aux tapleaves continueraient de posséder les + propriétés de _liaison_ et de _masquage_ qu'ils ont contre les ordinateurs classiques. Il conclut + que : + > Un attaquant quantique doit effectuer au moins 2^81 évaluations de + > SHA256 pour créer une sortie Taproot et être capable de l'ouvrir à une + > racine Merkle inattendue avec une probabilité de 1/2. Si l'attaquant + > dispose uniquement de machines quantiques dont la plus longue séquence de calculs SHA256 + > est limitée à 2^20, alors l'attaquant a besoin d'au moins 2^92 de ces + > machines pour obtenir une probabilité de succès de 1/2. + + Si les engagements taproot sont sécurisés contre la manipulation par des ordinateurs quantiques, + alors la résistance quantique peut être ajoutée à Bitcoin en désactivant les dépenses de chemin de + clé et en ajoutant des opcodes de vérification de signature résistants aux quantiques à + [tapscript][topic tapscript]. Une mise à jour récente à [BIP360][] pay-to-quantum-resistant-hash + qu'Ethan Heilman a [posté][heilman bip360] sur la mailing list Bitcoin-Dev fait exactement ce + changement. + +## Mises à jour et versions candidates + +_Nouvelles versions et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de mettre à niveau vers les nouvelles versions ou d'aider à tester les versions candidates._ + +- [Bitcoin Core 29.1rc1][] est un candidat à la sortie pour une version de maintenance du logiciel + de nœud complet prédominant. + +## Changements notables dans le code et la documentation + +_Changements notables récents dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core +lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware WalletInterface (HWI)][hwi repo], +[Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Bitcoin +Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips +repo], [Bitcoin Inquisition][bitcoin inquisition repo], et [BINANAs][binana repo]._ + +- [Bitcoin Core #29954][] étend le RPC `getmempoolinfo` en ajoutant deux champs de politique de + relais à son objet de réponse : `permitbaremultisig` (si le nœud relaie les sorties multisig nues) + et `maxdatacarriersize` (le nombre maximal d'octets agrégés autorisés dans les sorties OP_RETURN + pour une transaction dans le mempool). D'autres drapeaux de politique, tels que [`fullrbf`][topic + rbf] et `minrelaytxfee`, étaient déjà exposés, donc ces ajouts permettent d'avoir un aperçu complet + de la politique de relais. + +- [Bitcoin Core #33004][] active par défaut l'option `-natpmp`, permettant le transfert automatique + de port via le [Port Control Protocol (PCP)][pcp] avec un recours au [NAT Port Mapping Protocol + (NAT-PMP)][natpmp] (voir le Bulletin [323][news323 natpmp]). Un nœud en écoute derrière un routeur + qui supporte soit PCP soit NAT-PMP devient accessible sans configuration manuelle. + +- [LDK #3246][] permet la création d'offres [BOLT12][topic offers] et de remboursements sans un + [chemin aveuglé][topic rv routing] en utilisant le `signing_pubkey` de l'offre comme destination. + Les fonctions `create_offer_builder` et `create_refund_builder` délèguent désormais la création de + chemin aveuglé à `MessageRouter::create_blinded_paths`, où un appelant peut générer un chemin + compact en passant `DefaultMessageRouter`, un chemin de pubkey de longueur complète avec + `NodeIdMessageRouter`, ou aucun chemin du tout avec `NullMessageRouter`. + +- [LDK #3892][] expose publiquement la signature de l'arbre de Merkle des factures [BOLT12][topic + offers], permettant aux développeurs de construire des outils CLI ou d'autres logiciels pour + vérifier la signature ou recréer des factures. Cette PR ajoute également un champ `OfferId` aux + factures BOLT12 pour suivre l'offre d'origine. + +- [LDK #3662][] implémente [BLIPs #55][], également connu sous le nom de LSPS05, qui définit comment + les clients peuvent s'inscrire à des webhooks via un point de terminaison pour recevoir des + notifications push d'un LSP. L'API expose des points de terminaison supplémentaires qui permettent + aux clients de lister toutes les inscriptions de webhook ou de supprimer une inscription spécifique. + Cela peut être utile pour les clients afin d'être notifiés lors de la réception d'un [paiement + asynchrone][topic async payments]. + +{% include snippets/recap-ad.md when="2025-08-05 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="29954,33004,3246,3892,3662,55" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[augur #3]: https://github.com/block/bitcoin-augur/issues/3 +[news315 cb]: /fr/newsletters/2024/08/09/#statistiques-sur-la-reconstruction-de-blocs-compacts +[news339 cb]: /fr/newsletters/2025/01/31/#statistiques-mises-a-jour-sur-la-reconstruction-de-blocs-compacts +[gumberg prefilling]: https://delvingbitcoin.org/t/stats-on-compact-block-reconstructions/1052/34 +[shareshian estimation]: https://delvingbitcoin.org/t/augur-block-s-open-source-bitcoin-fee-estimation-library/1848/ +[ismail estimation]: https://delvingbitcoin.org/t/augur-block-s-open-source-bitcoin-fee-estimation-library/1848/2 +[news361 pqcr]: /fr/newsletters/2025/07/04/#fonction-de-commit-reveal-pour-la-recuperation-post-quantique +[sanders th]: https://mailing-list.bitcoindevs.xyz/bitcoindev/26b96fb1-d916-474a-bd23-920becc3412cn@googlegroups.com/ +[news285 ik]: /fr/newsletters/2024/01/17/#nouvelle-proposition-de-soft-fork-combinant-lnhance +[news361 ctvlegacy]: /fr/newsletters/2025/07/04/#preoccupations-et-alternatives-au-support-legacy +[pyth timelock]: https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818/ +[jahr timelock]: https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818/2 +[roose timelock]: https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818/3 +[ruffing qtr]: https://mailing-list.bitcoindevs.xyz/bitcoindev/bee6b897379b9ae0c3d48f53d40a6d70fe7915f0.camel@real-or-random.org/ +[ruffing paper]: https://eprint.iacr.org/2025/1307 +[heilman bip360]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAEM=y+W=rtU2PLmHve6pUVkMQQmqT67KOg=9hp5oMspuHrgMow@mail.gmail.com/ +[lopp qmig]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CADL_X_fpv-aXBxX+eJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q@mail.gmail.com/ +[news348 destroy]: /fr/newsletters/2025/04/04/#faut-il-detruire-les-bitcoins-vulnerables +[black th]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aG9FEHF1lZlK6d0E@console/ +[news361 bitvm]: /fr/newsletters/2025/07/04/#discussion-continue-sur-les-avantages-de-ctv-csfs-pour-bitvm +[news323 natpmp]: /fr/newsletters/2024/10/04/#bitcoin-core-30043 +[pcp]: https://datatracker.ietf.org/doc/html/rfc6887 +[natpmp]: https://datatracker.ietf.org/doc/html/rfc6886 \ No newline at end of file From 864ac36a64320b32b5d319d91b4a1db797e636a6 Mon Sep 17 00:00:00 2001 From: "Mark \"Murch\" Erhardt" Date: Mon, 18 Aug 2025 13:23:39 -0700 Subject: [PATCH 209/278] News367: Remove duplicate line (#2466) * News367: Remove duplicate line * News367ja: Fix Newsletter link style --- _posts/en/newsletters/2025-08-15-newsletter.md | 1 - _posts/ja/newsletters/2025-08-15-newsletter.md | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/_posts/en/newsletters/2025-08-15-newsletter.md b/_posts/en/newsletters/2025-08-15-newsletter.md index 5772a64010..2d8b8eb531 100644 --- a/_posts/en/newsletters/2025-08-15-newsletter.md +++ b/_posts/en/newsletters/2025-08-15-newsletter.md @@ -43,7 +43,6 @@ repo], and [BINANAs][binana repo]._ - [Bitcoin Core #33050][] removes peer discouragement (see [Newsletter #309][news309 peer]) for consensus-invalid transactions because its DoS protection was ineffective. An attacker could circumvent the protection by - protection was ineffective. An attacker could circumvent the protection by spamming policy-invalid transactions without penalty. This update eliminates the need for double script validation because it is no longer necessary to distinguish between consensus and standardness failures, saving CPU costs. diff --git a/_posts/ja/newsletters/2025-08-15-newsletter.md b/_posts/ja/newsletters/2025-08-15-newsletter.md index 140866098a..19f7cfd2ad 100644 --- a/_posts/ja/newsletters/2025-08-15-newsletter.md +++ b/_posts/ja/newsletters/2025-08-15-newsletter.md @@ -37,7 +37,7 @@ Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 [Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ - [Bitcoin Core #33050][]は、コンセンサスが無効なトランザクションに対する - ピアの排除機能（ニュースレター[#309][news309 peer]参照）を削除しました。 + ピアの排除機能（[ニュースレター #309][news309 peer]参照）を削除しました。 これは、DoSの保護が効果的でなかったためです。攻撃者は、ポリシー上無効なトランザクションをスパムすることで、 ペナルティなしでこの保護を回避できました。このアップデートにより、 コンセンサスの失敗と標準（ポリシー）の失敗を区別する必要がなくなったため、 From 4b2752b10930fcf9ab0f45b44d71844f16eb3fca Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Tue, 19 Aug 2025 16:09:08 +0200 Subject: [PATCH 210/278] Newsletter 366 translate in French (#2460) --- .../fr/newsletters/2025-08-08-newsletter.md | 268 ++++++++++++++++++ 1 file changed, 268 insertions(+) create mode 100644 _posts/fr/newsletters/2025-08-08-newsletter.md diff --git a/_posts/fr/newsletters/2025-08-08-newsletter.md b/_posts/fr/newsletters/2025-08-08-newsletter.md new file mode 100644 index 0000000000..4a7d19d383 --- /dev/null +++ b/_posts/fr/newsletters/2025-08-08-newsletter.md @@ -0,0 +1,268 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #366' +permalink: /fr/newsletters/2025/08/08/ +name: 2025-08-08-newsletter-fr +slug: 2025-08-08-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine annonce des BIPs en version draft pour Utreexo, résume la discussion +continue sur la baisse du taux minimal de frais de transaction pour la diffusion, et décrit une +proposition permettant aux nœuds de partager leurs modèles de bloc pour atténuer les problèmes liés +aux politiques divergentes de mempool. Sont également incluses nos sections régulières résumant une +réunion du Bitcoin Core PR Review Club, annonçant des mises à jour et des versions candidates, +et décrivant les changements notables dans les projets d'infrastructure Bitcoin populaires. Nous +incluons aussi une correction à la newsletter de la semaine dernière et une recommandation pour nos +lecteurs. + +## Nouvelles + +- **BIPs en version draft proposés pour Utreexo :** Calvin Kim a [publié][kim bips] sur la liste de + diffusion Bitcoin-Dev pour annoncer trois BIPs en version draft co-écrits par lui-même avec Tadge + Dryja et Davidson Souza sur le modèle de validation [Utreexo][topic utreexo]. Le [premier + BIP][ubip1] spécifie la structure de l'accumulateur Utreexo, qui permet à un nœud de stocker un + engagement facilement mis à jour pour l'ensemble complet des UTXO en "juste quelques kilo-octets". + Le [deuxième BIP][ubip2] spécifie comment un nœud complet peut valider de nouveaux blocs et + transactions en utilisant l'accumulateur plutôt qu'un ensemble traditionnel de sorties de + transactions dépensées (STXOs, utilisées dans les premières versions de Bitcoin Core et actuellement + dans libbitcoin) ou de sorties de transactions non dépensées (UTXOs, utilisées dans la version + actuelle de Bitcoin Core). Le [troisième BIP][ubip3] spécifie les changements au protocole P2P + Bitcoin qui permettent de transférer les données supplémentaires nécessaires pour la validation + Utreexo. + + Les auteurs recherchent une revue conceptuelle et mettront à jour les BIPs en version draft basés + sur les développements futurs. + +- **Discussion continue sur la baisse du taux minimal de frais de diffusion :** Gloria Zhao a + [posté][zhao minfee] sur Delving Bitcoin à propos de la baisse du [taux minimal de frais de + diffusion par défaut][topic default minimum transaction relay feerates] de 90% à 0.1 sat/vbyte. Elle + a encouragé une discussion conceptuelle sur l'idée et son impact potentiel sur d'autres logiciels. + Pour les préoccupations spécifiques à Bitcoin Core, elle a renvoyé à une [PR][bitcoin + core #33106]. + +- **Partage de modèle de bloc entre pairs pour atténuer les problèmes liés aux politiques de mempool divergentes :** + Anthony Towns a [posté][towns tempshare] sur Delving Bitcoin pour suggérer que les + pairs de nœuds complets s'envoient occasionnellement leur modèle actuel pour le prochain bloc en + utilisant l'encodage [compact block relay][topic compact block relay]. Le pair récepteur pourrait + alors demander toutes les transactions du modèle qu'il lui manque, les ajoutant soit au mempool + local soit les stockant dans un cache. Cela permettrait aux pairs avec des politiques de mempool + divergentes de partager des transactions malgré leurs différences. Cela offre une alternative à une + proposition précédente qui suggérait l'utilisation de _weak blocks_ (voir le [Bulletin #299][news299 + weak blocks]). Towns a publié une [implémentation de preuve de concept][towns tempshare poc]. + +## Bitcoin Core PR Review Club + +*Dans cette section mensuelle, nous résumons une récente réunion du [Bitcoin Core PR Review Club][], +en soulignant certaines des questions et réponses importantes. Cliquez sur une question ci-dessous +pour voir un résumé de la réponse de la réunion.* + +[Ajouter l'exportwatchonlywallet RPC pour exporter une version watch-only d'un portefeuille][review +club 32489] est une PR par [achow101][gh achow101] qui réduit la quantité de travail manuel +nécessaire pour créer un portefeuille watch-only. Avant ce changement, les utilisateurs devaient le +faire en tapant ou en scriptant des appels RPC `importdescriptors`, en copiant des étiquettes +d'adresse, etc. + +Outre les [descriptors][topic descriptors] publics, l'exportation contient également : +- des caches contenant des xpubs dérivés lorsque nécessaire, par exemple, en cas de chemins de + dérivation durcis +- des entrées de carnet d'adresses, des drapeaux de portefeuille et des étiquettes utilisateur +- toutes les transactions historiques du portefeuille afin que les rescans ne soient pas nécessaires + +La base de données du portefeuille exporté peut ensuite être importée avec le RPC `restorewallet`. + + +{% include functions/details-list.md + q0="Pourquoi les informations existantes `IsRange()`/`IsSingleType()` ne peuvent-elles pas nous dire + si un descripteur peut être étendu du côté watch-only ? Expliquez la logique derrière + `CanSelfExpand()` pour a) un chemin `wpkh(xpub/0h/*)` durci et b) un descripteur `pkh(pubkey)`." + a0="`IsRange()` et `IsSingleType()` étaient insuffisants car ils ne vérifient pas la dérivation + durcie, qui nécessite des clés privées indisponibles dans un portefeuille watch-only. + `CanSelfExpand()` a été ajouté pour rechercher de manière récursive des chemins durcis ; s'il en + trouve un, il retourne `false`, signalant qu'un cache pré-rempli doit être exporté pour que le + portefeuille watch-only puisse dériver des adresses. Un descripteur `pkh(pubkey)` n'est pas étendu + et n'a pas de dérivation, donc il peut toujours s'auto-étendre." + a0link="https://bitcoincore.reviews/32489#l-27" + + q1="`ExportWatchOnlyWallet` ne copie le cache du descripteur que si `!desc->CanSelfExpand()`. Que + contient exactement ce cache ? Comment un cache incomplet pourrait-il affecter la dérivation + d'adresse sur le portefeuille watch-only ?" + a1="Le cache stocke des objets `CExtPubKey` pour les descripteurs avec des chemins de dérivation + durcis, qui sont pré-dérivés sur le portefeuille dépensier. Si ce cache est incomplet, le + portefeuille watch-only ne peut pas dériver les adresses manquantes car il manque les clés privées + nécessaires. Cela l'empêcherait de voir les transactions envoyées à ces adresses, conduisant à un + solde incorrect." + a1link="https://bitcoincore.reviews/32489#l-52" + + q2="L'exportateur définit `create_flags = GetWalletFlags() | WALLET_FLAG_DISABLE_PRIVATE_KEYS`. + Pourquoi est-il important de préserver les drapeaux originaux (par exemple, `AVOID_REUSE`) au lieu + de tout effacer et de recommencer à zéro ?" + a2="Préserver les drapeaux assure une cohérence comportementale entre les portefeuilles dépensier et + watch-only. Par exemple, le drapeau `AVOID_REUSE` affecte quelles pièces sont considérées + disponibles pour dépenser. Ne pas le préserver ferait que le portefeuille watch-only signalerait un + solde disponible différent de celui du portefeuille principal, conduisant à une confusion pour + l'utilisateur." + a2link="https://bitcoincore.reviews/32489#l-68" + + q3="Pourquoi l'exportateur lit-il le localisateur depuis le portefeuille source et + le copie-t-il tel quel dans le nouveau portefeuille au lieu de laisser le nouveau + portefeuille démarrer à partir du bloc 0 ?" + a3="Le localisateur de bloc est copié afin d'indiquer au nouveau portefeuille en lecture seule + où reprendre l'analyse de la blockchain pour les nouvelles transactions, + évitant ainsi la nécessité d'une nouvelle analyse complète." + a3link="https://bitcoincore.reviews/32489#l-93" + + q4="Considérons un descripteur multisig `wsh(multi(2,xpub1,xpub2))`. Si l'un des + cosignataires exporte un portefeuille en lecture seule et le partage avec un tiers, + quelles nouvelles informations ce tiers obtient-il par rapport au simple fait de + lui fournir les chaînes de descripteurs ?" + a4="Les données du portefeuille en lecture seule comprennent des métadonnées supplémentaires telles que le + carnet d'adresses, les indicateurs du portefeuille et les étiquettes de contrôle des pièces. Pour les portefeuilles avec une + dérivation renforcée, le tiers ne peut obtenir que des informations sur les + transactions historiques et futures via l'exportation du portefeuille en lecture seule." + a4link="https://bitcoincore.reviews/32489#l-100" + + q5="Dans `wallet_exported_watchonly.py`, pourquoi le test appelle-t-il + `wallet.keypoolrefill(100)` avant de vérifier la dépensabilité sur la + paire en ligne/hors ligne ?" + a5="L'appel `keypoolrefill(100)` force le portefeuille hors ligne (de dépense) + à dériver au préalable 100 clés pour ses descripteurs renforcés, remplissant ainsi son + cache. Ce cache est ensuite inclus dans l'exportation, ce qui permet au portefeuille en ligne + en lecture seule de générer ces 100 adresses. Il garantit également que le + portefeuille hors ligne reconnaîtra ces adresses lorsqu'il recevra un PSBT à signer." + a5link="https://bitcoincore.reviews/32489#l-122" +%} + +## Optech recommande + +[Bitcoin++ Insider][] a commencé à publier des nouvelles financées par les lecteurs sur des sujets +techniques liés à Bitcoin. Deux de leurs bulletins hebdomadaires gratuits, _Last Week in Bitcoin_ et +_This Week in Bitcoin Core_, pourraient particulièrement intéresser les lecteurs réguliers de la +newsletter Optech. + +## Mises à jour et versions candidates + +_Nouvelles versions et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de mettre à niveau vers les nouvelles versions ou d'aider à tester les versions candidates._ + +- [LND v0.19.3-beta.rc1][] est un candidat à la sortie pour une version de maintenance de cette + implémentation populaire de nœud LN contenant "des corrections de bugs importants". Plus + notablement, "une migration optionnelle [...] réduit significativement les besoins en disque et en + mémoire pour les nœuds." + +- [BTCPay Server 2.2.0][] est une sortie de cette solution de paiement auto-hébergée populaire. Elle + ajoute le support pour les politiques de portefeuille et [miniscript][topic miniscript], fournit un + support supplémentaire pour la gestion et le suivi des frais de transaction, et inclut plusieurs + autres nouvelles améliorations et corrections de bugs. + +- [Bitcoin Core 29.1rc1][] est un candidat à la sortie pour une version de maintenance du logiciel + de nœud complet prédominant. + +## Changements notables dans le code et la documentation + +_Changements notables récents dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning +repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], +[Interface de Portefeuille Matériel (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Propositions d'Amélioration de Bitcoin (BIPs)][bips +repo], [Lightning BOLTs][bolts repo],_ +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], et [BINANAs][binana repo]. + +- [Bitcoin Core #32941][] complète la révision de `TxOrphanage` (voir le [Bulletin #364][news364 + orphan]) en activant la réduction automatique de l'orphelinat lorsque ses limites sont dépassées. Il + ajoute un avertissement pour les utilisateurs de `maxorphantx` pour les informer qu'il est obsolète. + Ce PR consolide le relais de paquets opportuniste un-parent-un-enfant (1p1c) [package relay][topic + package relay]. + +- [Bitcoin Core #31385][] assouplit la règle `package-not-child-with-unconfirmed-parents` de la RPC + `submitpackage` pour améliorer l'utilisation du relais de paquets 1p1c [package relay][topic package + relay]. Les paquets n'ont plus besoin d'inclure les parents qui sont déjà dans le mempool du nœud. + +- [Bitcoin Core #31244][] implémente l'analyse des [descripteurs][topic descriptors] [MuSig2][topic + musig] tels que définis dans [BIP390][], ce qui est nécessaire pour recevoir et dépenser des entrées + d'adresses [taproot][topic taproot] avec des clés agrégées MuSig2. + +- [Bitcoin Core #30635][] commence à afficher les RPC `waitfornewblock`, `waitforblock`, et + `waitforblockheight` dans la réponse de la commande d'aide, indiquant qu'ils sont destinés aux + utilisateurs réguliers. Ce PR ajoute également un argument `current_tip` optionnel à la RPC + `waitfornewblock`, pour atténuer les conditions de concurrence en spécifiant le hash du bloc de la + pointe actuelle de la chaîne. + +- [Bitcoin Core #28944][] ajoute une protection anti-[fee sniping][topic fee sniping] aux + transactions envoyées avec les commandes RPC `send` et `sendall` en ajoutant un [locktime][topic + timelocks] aléatoire relatif au tip si un n'est pas déjà spécifié. + +- [Eclair #3133][] étend son système de réputation locale des pairs pour l'[endorsement HTLC][topic + htlc endorsement] (voir le [Bulletin #363][news363 reputation]) pour évaluer la réputation des pairs + sortants, tout comme pour les pairs entrants. Eclair considérerait désormais une bonne réputation + dans les deux directions lors du transfert d'un HTLC, mais n'implémente pas encore de pénalités. + Évaluer les pairs sortants est nécessaire pour prévenir les attaques par évier (voir le [Bulletin + #322][news322 sink]), un type spécifique d'[attaque de blocage de canal][topic channel jamming + attacks]. + +- [LND #10097][] introduit une file d'attente asynchrone, par pair, pour les demandes de + [gossip][topic channel announcements] en attente (`GossipTimestampRange`) pour éliminer le risque de + blocages lorsque un pair envoie trop de demandes à la fois. Si un pair envoie une demande avant que + la précédente ne soit terminée, le message supplémentaire est discrètement ignoré. Un nouveau + paramètre `gossip.filter-concurrency` (valeur par défaut 5) est ajouté pour limiter le nombre de + travailleurs concurrents pour tous les pairs. Le PR ajoute également de la documentation expliquant + comment fonctionnent tous les paramètres de configuration de limitation de taux pour le gossip. + +- [LND #9625][] ajoute une commande RPC `deletecanceledinvoice` (et son équivalent `lncli`) qui + permet aux utilisateurs de supprimer les factures [BOLT11][] annulées (voir le [Bulletin #33][news33 + canceled]) en fournissant leur hash de paiement. + +- [Rust Bitcoin #4730][] ajoute un type `Alert` enveloppe pour l'[alerte finale][] + message qui notifie les pairs utilisant une version vulnérable de Bitcoin Core (avant la version + 0.12.1) que leur système d'alerte est non sécurisé. Satoshi a introduit le système d'alerte pour + notifier les utilisateurs d'événements significatifs du réseau, mais il a été [retiré][] dans la + version 0.12.1, à l'exception du message d'alerte final. + +- [BLIPs #55][] ajoute [BLIP55][] pour spécifier comment les clients mobiles peuvent s'inscrire pour + des webhooks via un point d'accès pour recevoir des notifications push d'un LSP. Ce protocole est + utile pour les clients afin d'être notifiés lors de la réception d'un [paiement asynchrone][topic + async payments], et a récemment été implémenté dans LDK (Voir le [Bulletin #365][news365 webhook]). + +## Correction + +Dans [le bulletin de la semaine dernière][news365 p2qrh], nous avons incorrectement décrit la +version mise à jour de [BIP360][], _pay to quantum-resistant hash_, comme "faisant exactement le +changement" que Tim Ruffing a montré être sécurisé dans son [article récent][ruffing paper]. Ce que +BIP360 fait réellement, c'est remplacer l'engagement de courbe elliptique envers une racine de +merkle basée sur SHA256 (plus une alternative de chemin de clé) par un engagement SHA256 directement +envers la racine de merkle. L'article de Ruffing a montré que taproot, tel qu'utilisé actuellement, +est sécurisé si un schéma de signature résistant aux quantiques était ajouté au langage +[tapscript][topic tapscript] et que les dépenses de chemin de clé étaient désactivées. BIP360 exige +à la place que les portefeuilles passent à une variante de taproot (quoique, une variante triviale), +élimine le mécanisme de chemin de clé de sa variante, et décrit l'ajout d'un schéma de signature +résistant aux quantiques au langage de script utilisé dans ses tapleaves. Bien que l'article de +Ruffing ne s'applique pas à la variante de taproot proposée dans BIP360, la sécurité de cette +variante (vue comme un engagement) découle immédiatement de la sécurité de l'arbre de merkle. + +Nous nous excusons pour l'erreur et remercions Tim Ruffing de nous avoir informés de notre erreur. + +{% include snippets/recap-ad.md when="2025-08-12 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="33106,32941,31385,31244,30635,28944,3133,10097,9625,4730,55" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[bitcoin++ insider]: https://insider.btcpp.dev/ +[news365 p2qrh]: /fr/newsletters/2025/08/01/#securite-contre-les-ordinateurs-quantiques-avec-taproot-comme-schema-d-engagement +[zhao minfee]: https://delvingbitcoin.org/t/changing-the-minimum-relay-feerate/1886/ +[towns tempshare]: https://delvingbitcoin.org/t/sharing-block-templates/1906 +[towns tempshare poc]: https://github.com/ajtowns/bitcoin/commit/ee12518a4a5e8932175ee57c8f1ad116f675d089 +[news299 weak blocks]: /fr/newsletters/2024/04/24/#implementation-de-preuve-de-concept-pour-les-blocs-faibles +[ruffing paper]: https://eprint.iacr.org/2025/1307 +[kim bips]: https://mailing-list.bitcoindevs.xyz/bitcoindev/3452b63c-ff2b-4dd9-90ee-83fd9cedcf4an@googlegroups.com/ +[ubip1]: https://github.com/utreexo/biptreexo/blob/7ae65222ba82423c1a3f2edd6396c0e32679aa37/utreexo-accumulator-bip.md +[ubip2]: https://github.com/utreexo/biptreexo/blob/7ae65222ba82423c1a3f2edd6396c0e32679aa37/utreexo-validation-bip.md +[ubip3]: https://github.com/utreexo/biptreexo/blob/7ae65222ba82423c1a3f2edd6396c0e32679aa37/utreexo-p2p-bip.md +[btcpay server 2.2.0]: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.2.0 +[lnd v0.19.3-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta.rc1 +[review club 32489]: https://bitcoincore.reviews/32489 +[gh achow101]: https://github.com/achow101 +[news363 reputation]: /fr/newsletters/2025/07/18/#eclair-2716 +[news322 sink]: /fr/newsletters/2024/09/27/#tests-et-changements-de-mitigation-du-brouillage-hybride +[news33 canceled]: /en/newsletters/2019/02/12/#lnd-2457 +[alerte finale]: https://bitcoin.org/en/release/v0.14.0#final-alert +[retiré]: https://bitcoin.org/en/alert/2016-11-01-alert-retirement#updates +[news365 webhook]: /fr/newsletters/2025/08/01/#ldk-3662 +[news364 orphan]: /fr/newsletters/2025/07/25/#bitcoin-core-31829 \ No newline at end of file From 72db8fd7724af1752264cab907c69d23cb13d090 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Tue, 19 Aug 2025 16:11:08 +0200 Subject: [PATCH 211/278] newsletter 367 translate into german (#2464) --- .../de/newsletters/2025-08-15-newsletter.md | 80 +++++++++++++++++++ 1 file changed, 80 insertions(+) create mode 100644 _posts/de/newsletters/2025-08-15-newsletter.md diff --git a/_posts/de/newsletters/2025-08-15-newsletter.md b/_posts/de/newsletters/2025-08-15-newsletter.md new file mode 100644 index 0000000000..cd53514038 --- /dev/null +++ b/_posts/de/newsletters/2025-08-15-newsletter.md @@ -0,0 +1,80 @@ +--- +title: 'Bitcoin Optech Newsletter #367' +permalink: /de/newsletters/2025/08/15/ +name: 2025-08-15-newsletter-de +slug: 2025-08-15-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche enthält unsere üblichen Abschnitte zur +Ankündigung neuer Release-Kandidaten und zur Zusammenfassung wichtiger +Änderungen an populärer Bitcoin-Infrastruktur-Software. + +## Nachrichten + +_In unseren [Quellen][optech sources] wurden diese Woche keine nennenswerten +Neuigkeiten gefunden._ + +## Releases und Release-Kandidaten + +_Neue Releases und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. +Bitte erwägen Sie, auf neue Versionen zu aktualisieren oder beim Testen von +Release-Kandidaten zu helfen._ + +- [LND v0.19.3-beta.rc1][] ist ein Release-Kandidat für eine Wartungsversion + dieser beliebten LN-Knoten-Implementierung, der "wichtige Bugfixes" enthält. + Besonders erwähnenswert ist "eine optionale Migration [...], die Festplatten- + und Speicheranforderungen für Knoten erheblich senkt." + +- [Bitcoin Core 29.1rc1][] ist ein Release-Kandidat für eine Wartungsversion der + führenden Full-Node-Software. + +## Bedeutende Code- und Dokumentationsänderungen + +_Bedeutende aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], +[Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], +[Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], +[BDK][bdk repo], [BIPs][bips repo], [BOLTs][bolts repo], +[BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und +[BINANAs][binana repo]._ + +- [Bitcoin Core #33050][] entfernt das Peer-Discouragement (siehe [Newsletter + #309][news309 peer]) für konsensus-invalide Transaktionen, da der + zugehörige DoS-Schutz unwirksam war. Ein Angreifer konnte den Schutz durch + Spam mit policy-invaliden Transaktionen umgehen. Dadurch, dass nicht mehr zwischen dem Scheitern an Konsensregeln und Mempool-Richtlinien unterschieden wird, macht das Update doppelte + Script-Validierung überflüssig und spart CPU-Ressourcen. + +- [Bitcoin Core #32473][] führt einen pro-Input-Cache zur Vorausberechnung von + Sighash-Werten im Script-Interpreter für Legacy- (z. B. baremultisig), P2SH, + P2WSH (und implizit P2WPKH)-Inputs ein, um die Auswirkungen quadratischer + Hashing-Angriffe auf Standard-Transaktionen zu reduzieren. Core cached + nahezu fertige Hashes kurz vor dem Anhängen des Sighash-Bytes, sodass + wiederholte Hash-Berechnungen für Standard-Multisig-Transaktionen größtenteils + vermieden werden. Die Änderung ist in Policy (Mempool) und Consensus (Block) + aktiviert. [Taproot][topic taproot]-Inputs zeigen dieses Verhalten bereits + standardmäßig. + +- [Bitcoin Core #33077][] erzeugt eine monolithische statische Bibliothek + `libbitcoinkernel.a`, die alle Objektdateien privater Abhängigkeiten in einem + Archiv bündelt, sodass Downstream-Projekte nur noch gegen diese einzelne + Datei linken müssen. Siehe [Newsletter #360][news360 kernel] für zugehörige + `libsecp256k1`-Vorarbeiten. + +- [Core Lightning #8389][] macht das Feld `channel_type` beim Öffnen eines + Channels verpflichtend, in Einklang mit einer aktuellen Spezifikations- + änderung (siehe [Newsletter #364][news364 spec]). Die RPC-Kommandos + `fundchannel` und `fundchannel_start` melden nun den Channel-Typ inkl. der + Option für [zero-conf channels][topic zero-conf channels], wenn ein + Mindest-Depth von 0 dies impliziert. + +{% include snippets/recap-ad.md when="2025-08-19 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="33050,32473,33077,8389" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[lnd v0.19.3-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta.rc1 +[news309 peer]: /en/newsletters/2024/06/28/#bitcoin-core-29575 +[news360 kernel]: /de/newsletters/2025/06/27/#libsecp256k1-1678 +[libbitcoinkernel project]: https://github.com/bitcoin/bitcoin/issues/27587 +[news364 spec]: /de/newsletters/2025/07/25/#bolts-1232 From f6715a53d46884a561e547388898a115ac85ea89 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Tue, 19 Aug 2025 13:01:01 -0500 Subject: [PATCH 212/278] Podcast: add 367 recap --- .../en/newsletters/2025-08-15-newsletter.md | 12 +++++----- .../en/podcast/2025-08-19-newsletter-recap.md | 23 +++++++++++++++++++ 2 files changed, 29 insertions(+), 6 deletions(-) create mode 100644 _posts/en/podcast/2025-08-19-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-08-15-newsletter.md b/_posts/en/newsletters/2025-08-15-newsletter.md index 2d8b8eb531..4709555e3d 100644 --- a/_posts/en/newsletters/2025-08-15-newsletter.md +++ b/_posts/en/newsletters/2025-08-15-newsletter.md @@ -24,10 +24,10 @@ release candidates._ - [LND v0.19.3-beta.rc1][] is a release candidate for a maintenance version for this popular LN node implementation containing "important bug fixes". Most notably, "an optional migration [...] lowers disk - and memory requirements for nodes significantly." + and memory requirements for nodes significantly." {% assign timestamp="0:19" %} - [Bitcoin Core 29.1rc1][] is a release candidate for a maintenance - version of the predominant full node software. + version of the predominant full node software. {% assign timestamp="0:46" %} ## Notable code and documentation changes @@ -45,7 +45,7 @@ repo], and [BINANAs][binana repo]._ protection was ineffective. An attacker could circumvent the protection by spamming policy-invalid transactions without penalty. This update eliminates the need for double script validation because it is no longer necessary to - distinguish between consensus and standardness failures, saving CPU costs. + distinguish between consensus and standardness failures, saving CPU costs. {% assign timestamp="2:38" %} - [Bitcoin Core #32473][] introduces a per-input cache for sighash pre-computation to the script interpreter for legacy (e.g. baremultisig), @@ -56,19 +56,19 @@ repo], and [BINANAs][binana repo]._ same input with the same sighash mode that commits to the same portion of the script can reuse most of the work. It is enabled in both policy (mempool) and consensus (block) validation. [Taproot][topic taproot] inputs already have - that behavior by default, so this update doesn't need to be applied to them. + that behavior by default, so this update doesn't need to be applied to them. {% assign timestamp="11:04" %} - [Bitcoin Core #33077][] creates a monolithic static library [`libbitcoinkernel.a`][libbitcoinkernel project] that bundles all the object files of its private dependencies into a single archive, allowing downstream projects to link to just this one file. See [Newsletter #360][news360 kernel] - for related `libsecp256k1` groundwork. + for related `libsecp256k1` groundwork. {% assign timestamp="17:57" %} - [Core Lightning #8389][] makes the `channel_type` field mandatory when opening a channel, aligning with a recent specification update (see [Newsletter #364][news364 spec]). The RPC commands `fundchannel` and `fundchannel_start` now report a channel type with the [zero-conf channel][topic zero-conf - channels] option when a zero `minimum_depth` implies it. + channels] option when a zero `minimum_depth` implies it. {% assign timestamp="22:03" %} {% include snippets/recap-ad.md when="2025-08-19 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-08-19-newsletter-recap.md b/_posts/en/podcast/2025-08-19-newsletter-recap.md new file mode 100644 index 0000000000..49aeec9655 --- /dev/null +++ b/_posts/en/podcast/2025-08-19-newsletter-recap.md @@ -0,0 +1,23 @@ +--- +title: 'Bitcoin Optech Newsletter #367 Recap Podcast' +permalink: /en/podcast/2025/08/19/ +reference: /en/newsletters/2025/08/15/ +name: 2025-08-19-recap +slug: 2025-08-19-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt discuss [Newsletter #367]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-7-19/405929742-44100-2-98de920f2e5c8.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From 3ae8370e959abf95ed487834729061b2c7c4f2c8 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Wed, 20 Aug 2025 01:30:57 -1000 Subject: [PATCH 213/278] Newsletters: add 368 (2025-08-22) --- .../en/newsletters/2025-08-22-newsletter.md | 142 ++++++++++++++++++ 1 file changed, 142 insertions(+) create mode 100644 _posts/en/newsletters/2025-08-22-newsletter.md diff --git a/_posts/en/newsletters/2025-08-22-newsletter.md b/_posts/en/newsletters/2025-08-22-newsletter.md new file mode 100644 index 0000000000..a2b01cf947 --- /dev/null +++ b/_posts/en/newsletters/2025-08-22-newsletter.md @@ -0,0 +1,142 @@ +--- +title: 'Bitcoin Optech Newsletter #368' +permalink: /en/newsletters/2025/08/22/ +name: 2025-08-22-newsletter +slug: 2025-08-22-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter summarizes a draft BIP for block template sharing +between full nodes and announces a library that allows trusted +delegation of script evaluation (including for features not available in +Bitcoin's native scripting languages). Also included are our regular +sections describing recent updates to services and client software, +announcing new releases and release candidates, and summarizing notable +changes to popular Bitcoin infrastructure software. + +## News + +- **Draft BIP for block template sharing:** Anthony Towns [posted][towns + bipshare] to the Bitcoin-Dev mailing list the [draft][towns bipdraft] + of a BIP for how nodes can communicate to their peers the transactions + they would attempt to mine in their next block (see [Newsletter + #366][news366 templshare]). This allows the node to share + transactions it will accept via its mempool and mining policy that its + peers might normally reject by their own policy, allowing those peers + to cache those transactions in case they are mined (which improves + [compact block relay][topic compact block relay] effectiveness). The + transactions in a node's block template are usually the most + profitable unconfirmed transactions known to that node, so peers that + previously rejected those transactions for policy reasons might also + find them worthy of additional consideration. + + The protocol specified in the draft BIP is simple. Shortly after a + connection with a peer is initiated, the node sends a `sendtemplate` + message indicating to the peer that it is willing to send block + templates. At any later time, the peer can request a template with a + `gettemplate` message. In response to the request, the node replies + with a `template` message that contains a list of short transaction + identifiers using the same format as a [BIP152][] compact block + message. The peer can then request any transactions it wants by + including the short identifier in a `sendtransactions` message (also + as in BIP152). The draft BIP allows templates to be up to slightly + more than twice the size of the current maximum block weight limit. + + A Delving Bitcoin [thread][delshare] about template sharing saw + additional discussion this week about how to improve the bandwidth + efficiency of the proposal. Ideas discussed included only sending + only the [difference][towns templdiff] since the previous template (an + estimated 90% bandwidth savings), using a [set reconciliation][jahr + templerlay] protocol such as that enabled by [minisketch][topic + minisketch] (allowing much larger templates to be shared efficiently), + and using Golomb-Rice [encoding][wuille templgr] on the templates + similar to [compact block filters][topic compact block filters] (an + estimated 25% efficiency). + +- **Trusted delegation of script evaluation:** Josh Doman [posted][doman + tee] to Delving Bitcoin about a library he's written that uses a + _trusted execution environment_ ([TEE][]) that will only sign a + [taproot][topic taproot] keypath spend if the transaction containing + that spend satisfies a script. The script can contain opcodes that + are not currently active on Bitcoin today or a completely different + form of script (e.g. [Simplicity][topic simplicity] or [bll][topic + bll]). + + This approach requires those receiving funds to the script to trust + the TEE---both that it will still be available to sign in the future + and that it will only sign a spend that satisfies its encumbrance + script---but it allows rapid experimentation with proposed new + features for Bitcoin with actual monetary value. To reduce trust in + the TEE remaining available, a backup spend path can be included; for + example, a [timelocked][topic timelocks] path that allows a participant + to unilaterally spend their funds a year after entrusting them to the + TEE. + + The library is designed for use with the Amazon Web Services (AWS) + Nitro enclave. + +## Changes to services and client software + +*In this monthly feature, we highlight interesting updates to Bitcoin +wallets and services.* + +FIXME:bitschmidty + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [LND v0.19.3-beta][] is a release candidate for a maintenance + version for this popular LN node implementation containing "important + bug fixes". Most notably, "an optional migration [...] lowers disk + and memory requirements for nodes significantly." + +- [Bitcoin Core 29.1rc1][] is a release candidate for a maintenance + version of the predominant full node software. + +- [Core Lightning v25.09rc2][] is a release candidate for a new major + version of this popular LN node implementation. + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [Bitcoin Core #32896][] wallet, rpc: add v3 transaction creation and wallet support + +- [Bitcoin Core #33106][] policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee + +- [Core Lightning #8467][] xpay: add option to pay bip353. + +- [Core Lightning #8354][] xpay: add `pay_part_start` and `pay_part_end` notifications. + +- [Eclair #3103][] Simple taproot channels + +- [Eclair #3134][] Use actual CLTV delta for reputation + +- [LDK #3897][] adi2011/peer-storage/serialise-deserialise + +{% include snippets/recap-ad.md when="2025-08-26 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32896,33106,8467,8354,3103,3134,3897" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[lnd v0.19.3-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta +[core lightning v25.09rc2]: https://github.com/ElementsProject/lightning/releases/tag/v25.09rc2 +[towns bipshare]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aJvZwR_bPeT4LaH6@erisian.com.au/ +[towns bipdraft]: https://github.com/ajtowns/bips/blob/202508-sendtemplate/bip-ajtowns-sendtemplate.md +[news366 templshare]: /en/newsletters/2025/08/08/#peer-block-template-sharing-to-mitigate-problems-with-divergent-mempool-policies +[delshare]: https://delvingbitcoin.org/t/sharing-block-templates/1906/13 +[towns templdiff]: https://delvingbitcoin.org/t/sharing-block-templates/1906/7 +[jahr templerlay]: https://delvingbitcoin.org/t/sharing-block-templates/1906/6 +[wuille templgr]: https://delvingbitcoin.org/t/sharing-block-templates/1906/9 +[doman tee]: https://delvingbitcoin.org/t/confidential-script-emulate-soft-forks-using-stateless-tees/1918/ +[tee]: https://en.wikipedia.org/wiki/Trusted_execution_environment From c7e32eb741e9e43c49a94f12f4eeb2d6bc65bf8f Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 21 Aug 2025 08:11:17 +0000 Subject: [PATCH 214/278] News368: add merge summaries --- .../en/newsletters/2025-08-22-newsletter.md | 73 +++++++++++++++---- 1 file changed, 59 insertions(+), 14 deletions(-) diff --git a/_posts/en/newsletters/2025-08-22-newsletter.md b/_posts/en/newsletters/2025-08-22-newsletter.md index a2b01cf947..85d8f97da2 100644 --- a/_posts/en/newsletters/2025-08-22-newsletter.md +++ b/_posts/en/newsletters/2025-08-22-newsletter.md @@ -111,23 +111,66 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Bitcoin Core #32896][] wallet, rpc: add v3 transaction creation and wallet support - -- [Bitcoin Core #33106][] policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee - -- [Core Lightning #8467][] xpay: add option to pay bip353. - -- [Core Lightning #8354][] xpay: add `pay_part_start` and `pay_part_end` notifications. - -- [Eclair #3103][] Simple taproot channels - -- [Eclair #3134][] Use actual CLTV delta for reputation - -- [LDK #3897][] adi2011/peer-storage/serialise-deserialise +- [Bitcoin Core #32896][] introduces support for creating and spending + unconfirmed Topologically Restricted Until Confirmation ([TRUC][topic v3 + transaction relay]) transactions by adding a `version` parameter to the + following RPCs: `createrawtransaction`, `createpsbt`, `send`, `sendall`, and + `walletcreatefundedpsbt`. The wallet enforces the TRUC transaction + restrictions for weight limit, sibling conflict, and incompatibility between + unconfirmed TRUC and non-TRUC transactions. + +- [Bitcoin Core #33106][] lowers the default `blockmintxfee` to 1 sat/kvB (the + minimum possible), and the default [`minrelaytxfee`][topic default minimum + transaction relay feerates] and `incrementalrelayfee` to 100 sat/kvB (0.1 + sat/vB). While these values can be configured, users are advised to adjust the + `minrelaytxfee` and `incrementalrelayfee` values together. Other minimum + feerates remain unchanged, but the default wallet minimum feerates are + expected to be lowered in a future version. The motivations for this change + range from considerable growth in the number of blocks mined with sub 1 sat/vB + transactions and the number of pools mining these transactions to an increase + in the Bitcoin exchange rate. + +- [Core Lightning #8467][] extends `xpay` (see [Newsletter #330][news330 xpay]) + by adding support for paying [BIP353][] Human Readable Names (HRN) (e.g. + satoshi@bitcoin.com) and enabling it to pay [BOLT12 offers][topic offers] + directly, removing the need to run the `fetchinvoice` command first. Under the + hood, `xpay` fetches the payment instructions using the `fetchbip353` RPC + command from the `cln-bip353` plugin introduced in [Core Lightning #8362][]. + +- [Core Lightning #8354][] starts publishing `pay_part_start` and `pay_part_end` + event notifications for the status of specific payment parts sent with + [MPP][topic multipath payments]. The `pay_part_end` notification indicates the + duration of the payment and whether it was successful or failed. If the + payment fails, an error message is provided and, if the error onion isn’t + corrupted, additional information on the failure is given, such as the source + of the error and the failure code. + +- [Eclair #3103][] introduces support for [simple taproot channels][topic simple + taproot channels], leveraging [MuSig2][topic musig] scriptless + [multisignature][topic multisignature] signing to reduce transaction weight + consumption by 15% and improve transaction privacy. Funding transactions and + cooperative closures are indistinguishable from other [P2TR][topic taproot] + transactions. This PR also includes support for [dual funding][topic dual + funding] and [splicing][topic splicing] in simple taproot channels, and + enables [channel commitment upgrades][topic channel commitment upgrades] to + the new taproot format during a splice transaction. + +- [Eclair #3134][] replaces the penalty weight multiplier for stuck + [HTLCs][topic htlc] with the [CLTV expiry delta][topic cltv expiry delta] when + scoring [HTLC endorsement][topic htlc endorsement] peer reputation (see + [Newsletter #363][news363 reputation]), to better reflect how long a stuck + HTLC will tie up liquidity. To mitigate the outsized penalty of stuck HTLCs + with a maximum CLTV expiry delta, this PR adjusts the reputation decay + parameter (`half-life`) from 15 to 30 days and the stuck payment threshold + (`max-relay-duration`) from 12 seconds to 5 minutes. + +- [LDK #3897][] extends its [peer storage][topic peer storage] implementation by + detecting lost channel state during backup retrieval, by deserializing the + peer’s copy and comparing it to the local state. {% include snippets/recap-ad.md when="2025-08-26 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="32896,33106,8467,8354,3103,3134,3897" %} +{% include linkers/issues.md v=2 issues="32896,33106,8467,8354,3103,3134,3897,8362" %} [bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ [lnd v0.19.3-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta [core lightning v25.09rc2]: https://github.com/ElementsProject/lightning/releases/tag/v25.09rc2 @@ -140,3 +183,5 @@ repo], and [BINANAs][binana repo]._ [wuille templgr]: https://delvingbitcoin.org/t/sharing-block-templates/1906/9 [doman tee]: https://delvingbitcoin.org/t/confidential-script-emulate-soft-forks-using-stateless-tees/1918/ [tee]: https://en.wikipedia.org/wiki/Trusted_execution_environment +[news330 xpay]: /en/newsletters/2024/11/22/#core-lightning-7799 +[news363 reputation]: /en/newsletters/2025/07/18/#eclair-2716 From 94a4fdbf4fcd1af178779aaf4c194d4c00b04840 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 21 Aug 2025 11:45:48 -0500 Subject: [PATCH 215/278] News368: add client service --- .../en/newsletters/2025-08-22-newsletter.md | 59 ++++++++++++++++++- 1 file changed, 58 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2025-08-22-newsletter.md b/_posts/en/newsletters/2025-08-22-newsletter.md index 85d8f97da2..10e01a954f 100644 --- a/_posts/en/newsletters/2025-08-22-newsletter.md +++ b/_posts/en/newsletters/2025-08-22-newsletter.md @@ -81,7 +81,48 @@ changes to popular Bitcoin infrastructure software. *In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.* -FIXME:bitschmidty +- **ZEUS v0.11.3 released:** + The [v0.11.3][zeus v0.11.3] release includes improvements to peer + management, [BOLT12][topic offers], and [submarine swap][topic submarine swaps] + features. + +- **Rust Utreexo resources:** + Abdelhamid Bakhta [posted][abdel tweet] Rust-based resources for + [Utreexo][topic utreexo], including interactive [educational + materials][rustreexo webapp] and [WASM bindings][rustreexo wasm]. + +- **Peer-observer tooling and call to action:** + 0xB10C [posted][b10c blog] about the motivation, architecture, code, + supporting libraries, and findings of his [peer-observer][peer-observer + github] project. He seeks to build "A loose, decentralized group of people who + share the interest of monitoring the Bitcoin Network. A collective to enable + sharing of ideas, discussion, data, tools, insights, and more." + +- **Bitcoin Core Kernel-based node announced:** + Bitcoin backbone was [announced][bitcoin backbone] as a demonstration of using + the [Bitcoin Core Kernel][kernel blog] library as the foundation of a Bitcoin node. + +- **SimplicityHL released:** + [SimplicityHL][simplcityhl github] is a Rust-like programming language that + compiles to the lower-level [Simplicity][simplicity] language [recently + activated][simplicity post] on Liquid. For further reading, see the [related + Delving thread][simplicityhl delving]. + +- **LSP plugin for BTCPay Server:** + The [LSP plugin][lsp btcpay github] implements client-side features of + [BLIP51][], the specification for inbound channels, into BTCPay Server. + +- **Proto mining hardware and software announced:** + Proto [announced][proto blog] new Bitcoin mining hardware and open source + mining software, built with previous [community feedback][news260 mdk]. + +- **Oracle resolution demo using CSFS:** + Abdelhamid Bakhta [posted][abdel tweet2] a demonstration of an oracle using + [CSFS][topic op_checksigfromstack], nostr, and MutinyNet to sign an + attestation of an event's outcome. + +- **Relai adds taproot support:** + Relai added support for sending to [taproot][topic taproot] addresses. ## Releases and release candidates @@ -185,3 +226,19 @@ repo], and [BINANAs][binana repo]._ [tee]: https://en.wikipedia.org/wiki/Trusted_execution_environment [news330 xpay]: /en/newsletters/2024/11/22/#core-lightning-7799 [news363 reputation]: /en/newsletters/2025/07/18/#eclair-2716 +[zeus v0.11.3]: https://github.com/ZeusLN/zeus/releases/tag/v0.11.3 +[abdel tweet]: https://x.com/dimahledba/status/1951213485104181669 +[rustreexo webapp]: https://rustreexo-playground.starkwarebitcoin.dev/ +[rustreexo wasm]: https://github.com/AbdelStark/rustreexo-wasm +[b10c blog]: https://b10c.me/projects/024-peer-observer/ +[peer-observer github]: https://github.com/0xB10C/peer-observer +[bitcoin backbone]: https://mailing-list.bitcoindevs.xyz/bitcoindev/9812cde0-7bbb-41a6-8e3b-8a5d446c1b3cn@googlegroups.com +[kernel blog]: https://thecharlatan.ch/Kernel/ +[simplcityhl github]: https://github.com/BlockstreamResearch/SimplicityHL +[simplicity]: https://blockstream.com/simplicity.pdf +[simplicityhl delving]: https://delvingbitcoin.org/t/writing-simplicity-programs-with-simplicityhl/1900 +[simplicity post]: https://blog.blockstream.com/simplicity-launches-on-liquid-mainnet/ +[lsp btcpay github]: https://github.com/MegalithicBTC/BTCPayserver-LSPS1 +[proto blog]: https://proto.xyz/blog/posts/proto-rig-and-proto-fleet-a-paradigm-shift +[news260 mdk]: /en/newsletters/2023/07/19/#mining-development-kit-call-for-feedback +[abdel tweet2]: https://x.com/dimahledba/status/1946223544234659877 From 411ce9df2b1bf0ecdbefd603aedde13a46d1af5a Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Fri, 22 Aug 2025 04:54:59 -0500 Subject: [PATCH 216/278] News368: add topics --- _topics/en/compact-block-relay.md | 3 +++ _topics/en/default-minimum-transaction-relay-feerates.md | 3 +++ _topics/en/dual-funding.md | 3 +++ _topics/en/miniscript.md | 3 +++ _topics/en/minisketch.md | 4 ++-- _topics/en/simple-taproot-channels.md | 3 +++ _topics/en/simplicity.md | 3 +++ _topics/en/splicing.md | 3 +++ _topics/en/version-3-transaction-relay.md | 3 +++ 9 files changed, 26 insertions(+), 2 deletions(-) diff --git a/_topics/en/compact-block-relay.md b/_topics/en/compact-block-relay.md index 73ab7cec5e..7cd8617af2 100644 --- a/_topics/en/compact-block-relay.md +++ b/_topics/en/compact-block-relay.md @@ -75,6 +75,9 @@ optech_mentions: - title: Peer block template sharing proposed to improve compact block performance with divergent mempools url: /en/newsletters/2025/08/08/#peer-block-template-sharing-to-mitigate-problems-with-divergent-mempool-policies + - title: Draft BIP and additional discussion of block template sharing to improve compact block effectiveness + url: /en/newsletters/2025/08/22/#draft-bip-for-block-template-sharing + ## Optional. Same format as "primary_sources" above # see_also: # - title: diff --git a/_topics/en/default-minimum-transaction-relay-feerates.md b/_topics/en/default-minimum-transaction-relay-feerates.md index 014e93b27e..44c8110abd 100644 --- a/_topics/en/default-minimum-transaction-relay-feerates.md +++ b/_topics/en/default-minimum-transaction-relay-feerates.md @@ -47,6 +47,9 @@ optech_mentions: - title: Continued discussion about lowering the default minimum transaction relay feerate url: /en/newsletters/2025/08/08/#continued-discussion-about-lowering-the-minimum-relay-feerate + - title: "Bitcoin Core #33106 lowers the default minimum relay fee from 1 sat/vbyte to 0.1 sat/vbyte" + url: /en/newsletters/2025/08/22/#bitcoin-core-33106 + ## Optional. Same format as "primary_sources" above see_also: - title: Package relay diff --git a/_topics/en/dual-funding.md b/_topics/en/dual-funding.md index 6f3a09e4fc..56c90bda67 100644 --- a/_topics/en/dual-funding.md +++ b/_topics/en/dual-funding.md @@ -138,6 +138,9 @@ optech_mentions: - title: "LDK #3137 adds support for accepting peer-initiated dual-funded channels" url: /en/newsletters/2024/11/29/#core-lightning-7719 + - title: "Eclair #3103 adds support for dual funding and splicing in simple taproot channels" + url: /en/newsletters/2025/08/22/#eclair-3103 + ## Optional. Same format as "primary_sources" above see_also: - title: Liquidity advertisements diff --git a/_topics/en/miniscript.md b/_topics/en/miniscript.md index 5648e700bd..de1ea83b2a 100644 --- a/_topics/en/miniscript.md +++ b/_topics/en/miniscript.md @@ -97,6 +97,9 @@ optech_mentions: - title: "BIP379 added with a specification for Miniscript" url: /en/newsletters/2024/07/05/#bips-1610 + - title: "New library for encrypting descriptors and miniscript to the included public keys" + url: /en/newsletters/2025/06/13/#descriptor-encryption-library + ## Optional. Same format as "primary_sources" above see_also: - title: "Miniscript: streamlined Bitcoin scripting" diff --git a/_topics/en/minisketch.md b/_topics/en/minisketch.md index 917925fd0c..7d9be096f1 100644 --- a/_topics/en/minisketch.md +++ b/_topics/en/minisketch.md @@ -41,8 +41,8 @@ optech_mentions: - title: "Relay censorship resistance using cluster mempool and efficient set reconciliation" url: /en/newsletters/2025/06/13/#relay-censorship-resistance-through-top-mempool-set-reconciliation - - title: "New library for encrypting descriptors and miniscript to the included public keys" - url: /en/newsletters/2025/06/13/#descriptor-encryption-library + - title: Discussion about using minisketch to improve efficiency of block template sharing + url: /en/newsletters/2025/08/22/#draft-bip-for-block-template-sharing ## Optional. Same format as "primary_sources" above see_also: diff --git a/_topics/en/simple-taproot-channels.md b/_topics/en/simple-taproot-channels.md index 65cfffde4d..d0327bb329 100644 --- a/_topics/en/simple-taproot-channels.md +++ b/_topics/en/simple-taproot-channels.md @@ -59,6 +59,9 @@ optech_mentions: - title: "LND #9669 downgrades simple taproot channels to always use the legacy cooperative close flow" url: /en/newsletters/2025/04/11/#lnd-9669 + - title: "Eclair #3103 adds support for simple taproot channels" + url: /en/newsletters/2025/08/22/#eclair-3103 + ## Optional. Same format as "primary_sources" above see_also: - title: Taproot diff --git a/_topics/en/simplicity.md b/_topics/en/simplicity.md index a80e080f6d..94b5284cd0 100644 --- a/_topics/en/simplicity.md +++ b/_topics/en/simplicity.md @@ -51,6 +51,9 @@ optech_mentions: - title: "Flexible coin earmarks probably compatible with Simplicity" url: /en/newsletters/2024/11/29/#flexible-coin-earmarks + - title: "SimplicityHL released to allow compiling Rust-like programs to Simplicity script" + url: /en/newsletters/2025/08/22/#simplicityhl-released + ## Optional. Same format as "primary_sources" above see_also: - title: "Simplicity: A New Language for Blockchains" diff --git a/_topics/en/splicing.md b/_topics/en/splicing.md index 78f8e8900f..dc5dc028ba 100644 --- a/_topics/en/splicing.md +++ b/_topics/en/splicing.md @@ -101,6 +101,9 @@ optech_mentions: - title: "Core Lightning #8021 finalizes splicing interoperability with Eclair" url: /en/newsletters/2025/05/23/#core-lightning-8021 + - title: "Eclair #3103 adds support for dual funding and splicing in simple taproot channels" + url: /en/newsletters/2025/08/22/#eclair-3103 + ## Optional. Same format as "primary_sources" above see_also: - title: Interactive transaction construction protocol diff --git a/_topics/en/version-3-transaction-relay.md b/_topics/en/version-3-transaction-relay.md index 902a872602..8ca604610d 100644 --- a/_topics/en/version-3-transaction-relay.md +++ b/_topics/en/version-3-transaction-relay.md @@ -110,6 +110,9 @@ optech_mentions: - title: "Rust Bitcoin #3450 adds the ability to opt-in to TRUC transactions" url: /en/newsletters/2024/10/18/#rust-bitcoin-3450 + - title: "Bitcoin Core #32896 extends several RPCs to support creating and spending TRUC transactions" + url: /en/newsletters/2025/08/22/#bitcoin-core-32896 + ## Optional. Same format as "primary_sources" above see_also: - title: Transaction pinning From ab1a00dbc675b4ae24526a253378e7c2af88e293 Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 22 Aug 2025 21:48:43 +0900 Subject: [PATCH 217/278] Newsletter-368:Translate into Japanese --- .../ja/newsletters/2025-08-22-newsletter.md | 210 ++++++++++++++++++ 1 file changed, 210 insertions(+) create mode 100644 _posts/ja/newsletters/2025-08-22-newsletter.md diff --git a/_posts/ja/newsletters/2025-08-22-newsletter.md b/_posts/ja/newsletters/2025-08-22-newsletter.md new file mode 100644 index 0000000000..df53fe512a --- /dev/null +++ b/_posts/ja/newsletters/2025-08-22-newsletter.md @@ -0,0 +1,210 @@ +--- +title: 'Bitcoin Optech Newsletter #368' +permalink: /ja/newsletters/2025/08/22/ +name: 2025-08-22-newsletter-ja +slug: 2025-08-22-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、フルノード間でブロックテンプレートを共有するためのBIPドラフトと、 +スクリプト評価の信頼する委任を可能にするライブラリ（Bitcoinのネイティブスクリプト言語ではできない機能を含む）の発表を +掲載しています。また、サービスとクライアントソフトウェアの最近のアップデートや、 +新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき更新など、 +恒例のセクションも含まれています。 + +## ニュース + +- **ブロックテンプレート共有のためのBIPドラフト:** Anthony Townsは、 + ノードが次のブロックでマイニングしようとしているトランザクションをピアに伝える方法（ + [ニュースレター #366][news366 templshare]参照）についてのBIPの + [ドラフト][towns bipdraft]をBitcoin-Devメーリングリストに[投稿しました][towns bipshare]。 + これにより、ノードが自身のmempoolおよびマイニングポリシーで受け入れるトランザクションを、 + 通常であればピアが自身のポリシーにより拒否する可能性のある場合でも共有できます。 + これによりピアは、これらのトランザクションがマイニングされた場合に備えてトランザクションをキャッシュすることができます（ + これにより、[コンパクトブロックリレー][topic compact block relay]の効率が向上します）。 + ノードのブロックテンプレートに含まれるトランザクションは通常、 + そのノードが認識している未承認トランザクションの中で最も収益性が高いため、 + これまでポリシー上の理由でこれらのトランザクションを拒否していたピアも、 + これらのトランザクションを改めて検討する価値があると判断する可能性があります。 + + BIPのドラフトで規定されているプロトコルはシンプルです。ピアとの接続の開始直後に、 + ノードはブロックテンプレートを送信する意思があることを示す、 + `sendtemplate`メッセージを送信します。その後、ピアは、 + `gettemplate`メッセージでテンプレートを要求できます。その要求への応答として、 + ノードは[BIP152][]のコンパクトブロックメッセージと同じ形式の短いトランザクション識別子のリストを含む + `template`メッセージで応答します。ピアは、（BIP152と同様に） + `sendtransactions`メッセージにその短い識別子を含めることで、必要なトランザクションを要求できます。 + BIPドラフトでは、テンプレートのサイズは、現在の最大ブロックウェイト制限の2倍よりわずかに大きいサイズまで許容されています。 + + テンプレートの共有に関するDelving Bitcoinの[スレッド][delshare]では、 + 今週、提案の帯域幅効率を向上させる方法について追加の議論が行われました。 + 議論されたアイディアには、前回のテンプレートとの[差分のみ][towns templdiff]を送信する案（推定90%の帯域幅の節約）、 + （より大きなテンプレートを効率的に共有可能な）[minisketch][topic minisketch]で有効になる + [セット調整][jahr templerlay]プロトコルを使用する案、 + [コンパクトブロックフィルター][topic compact block filters]と同様にテンプレートに + ゴロム・ライス[符号][wuille templgr]を使用する案（推定25%の効率化）などがありました。 + +- **スクリプト評価を信頼する委任:** + Josh Domanは、自身が作成したライブラリについてDelving Bitcoinに[投稿しました][doman tee]。 + このライブラリは[TEE][]（_Trusted Execution Environment_）を使用し、 + 支払いを含むトランザクションがスクリプトを満たす場合にのみ、 + [Taproot][topic taproot]のkeypath支払いに署名をします。 + このスクリプトには、現在Bitcoinでアクティブでないopcodeや、完全に異なる形式のスクリプト（ + [Simplicity][topic simplicity]や[bll][topic bll]など）を含めることができます。 + + このアプローチでは、スクリプトに資金を送信する側がTEEを信頼する必要があります。 + つまり、将来署名のために利用可能であること、そして制約スクリプトを満たす支払いにのみ署名することを信頼する必要があります。 + しかし、これにより実際の金銭的価値を持ちながら、Bitcoinの新機能提案を実験することが可能になります。 + TEEが利用可能であり続けることへの信頼を減らすため、バックアップの支払いパスを含めることができます。 + たとえば、参加者がTEEに資金を預託してから1年後に一方的に資金を使用できるようにする[タイムロック][topic timelocks]パスなどです。 + + このライブラリは、AWS（Amazon Web Services）のNitroエンクレーブの使用を想定して設計されています。 + +## サービスとクライアントソフトウェアの変更 + +*この毎月の特集では、Bitcoinのウォレットやサービスの興味深いアップデートを取り上げています。* + +- **ZEUS v0.11.3リリース:** + [v0.11.3][zeus v0.11.3]リリースには、ピア管理の改善、[BOLT12][topic offers]および + [サブマリンスワップ][topic submarine swaps]機能が含まれています。 + +- **RustのUtreexoリソース:** + Abdelhamid Bakhtaは、インタラクティブな[教材][rustreexo webapp]や + [WASMバインディング][rustreexo wasm]を含む、[Utreexo][topic utreexo]用のRustベースのリソースを[投稿しました][abdel tweet]。 + +- **Peer-observerツールと行動の呼びかけ:** + 0xB10Cは、自身の[peer-observer][peer-observer github]プロジェクトの動機、 + アーキテクチャ、コード、サポートライブラリ、調査結果について[投稿しました][b10c blog]。 + 彼は、「Bitcoinネットワークの監視という共通の関心を持つ、緩やかで分散化されたグループ。 + アイディア、議論、データ、ツール、洞察などを共有できる共同体」の構築を目指しています。 + +- **Bitcoin Core Kernelベースノードの発表:** + [Bitcoin Core Kernel][kernel blog]ライブラリをBitcoinノードの基盤として使用するデモとして、 + Bitcoin backboneが[発表されました][bitcoin backbone]。 + +- **SimplicityHLリリース:** + [SimplicityHL][simplcityhl github]は、Rustライクなプログラミング言語で、 + Liquidで[最近有効化された][simplicity post]低レベル言語[Simplicity][simplicity]にコンパイルされます。 + 詳細については、[関連するDelvingのスレッド][simplicityhl delving]をご覧ください。 + +- **BTCPay Server用のLSPプラグイン:** + [LSPプラグイン][lsp btcpay github]は、インバウンドチャネル用の仕様である + [BLIP51][]のクライアント側の機能をBTCPay Serverに実装します。 + +- **Protoマイニングハードウェアおよびソフトウェアの発表:** + Protoは、これまでの[コミュニティからのフィードバック][news260 mdk]に基づいて構築された、 + 新しいBitcoinマイニングハードウェアとオープンソースのマイニングソフトウェアを[発表しました][proto blog]。 + +- **CSFSを使用したオラクル解決のデモ:** + Abdelhamid Bakhtaは、[CSFS][topic op_checksigfromstack]、nostr、 + MutinyNetを使用してイベントの結果のアテステーションに署名するオラクルのデモを[投稿しました][abdel tweet2]。 + +- **RelaiがTaprootをサポート:** + Relaiが[Taproot][topic taproot]アドレスへの送信をサポートしました。 + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [LND v0.19.3-beta][]は、この人気のLNノード実装のメンテナンスバージョンのリリースで、 + 「重要なバグ修正」が含まれています。最も注目すべきは、 + 「オプションの移行で[…] ノードのディスクおよびメモリ要件が大幅に削減される」ことです。 + +- [Bitcoin Core 29.1rc1][]は、主要なフルノードソフトウェアのメンテナンスバージョンのリリース候補です。 + +- [Core Lightning v25.09rc2][]は、この人気のLNノード実装の新しいメジャーバージョンのリリース候補です。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Bitcoin Core #32896][]では、`createrawtransaction`、`createpsbt`、`send`、 + `sendall`、`walletcreatefundedpsbt`の各RPCに`version`パラメーターを追加することで、 + 未承認の[TRUC][topic v3 transaction relay]（Topologically Restricted Until Confirmation）トランザクションの作成と使用をサポートします。 + ウォレットは、ウェイト制限、兄弟の競合、未承認TRUCトランザクションと非TRUCトランザクション間の非互換性に関する + TRUCトランザクションの制限を適用します。 + +- [Bitcoin Core #33106][]では、デフォルトの`blockmintxfee`が1 sat/kvB（最小値）に引き下げられ、 + デフォルトの[`minrelaytxfee`][topic default minimum transaction relay feerates]と + `incrementalrelayfee`が100 sat/kvB（0.1 sat/vB）に引き下げられました。 + これらの値は設定が可能ですが、`minrelaytxfee`と`incrementalrelayfee`の値は合わせるように調整することをお勧めします。 + その他の最低手数料率は変更ありませんが、ウォレットのデフォルトの最低手数料率は将来のバージョンで引き下げられる予定です。 + この変更の理由は、1 sat/vB未満のトランザクションをマイニングするブロック数と、 + これらのトランザクションをマイニングするプール数の増加から、Bitcoinの為替レートの上昇まで多岐にわたります。 + +- [Core Lightning #8467][]は、`xpay`（[ニュースレター #330][news330 xpay]参照）を拡張し、 + （satoshi@bitcoin.comのような）[BIP353][] HRN（Human Readable Names）への支払いをサポートし、 + [BOLT12オファー][topic offers]への直接支払いも可能にすることで、 + `fetchinvoice`コマンドを最初に実行する必要がなくりました。内部的には、 + `xpay`は[Core Lightning #8362][]で導入された`cln-bip353`プラグインの + `fetchbip353` RPCコマンドを使って支払い指示を取得します。 + +- [Core Lightning #8354][]は、[MPP][topic multipath payments]で送信された + 特定の支払いのパーツのステータスに関する`pay_part_start`および`pay_part_end`イベント通知の発行を始めます。 + `pay_part_end`通知は、支払いの所要時間と、支払いが成功したか失敗したかを示します。 + 支払いが失敗した場合はエラーメッセージが表示され、エラーOnionが破損していない場合は、 + エラーの原因や失敗コードなどの追加情報が提供されます。 + +- [Eclair #3103][]は、[Simple Taproot Channel][topic simple taproot channels]のサポートを導入し、 + [MuSig2][topic musig]スクリプトレス[マルチシグ][topic multisignature]を活用することで、 + トランザクションのウェイト消費を15%削減し、トランザクションのプライバシーを向上させます。 + ファンディングトランザクションと、協調クローズは、他の[P2TR][topic taproot]トランザクションと区別が付きません。 + このPRはまた、Simple Taproot Channelにおける[デュアルファンディング][topic dual funding]と + [スプライシング][topic splicing]のサポートも含まれており、 + スプライシングトランザクション中に新しいTaproot形式への + [チャネルコミットメントのアップグレード][topic channel commitment upgrades]を可能にします。 + +- [Eclair #3134][]は、[HTLCエンドースメント][topic htlc endorsement]のピアレピュテーション（ + [ニュースレター #363][news363 reputation]参照）のスコアリング時に、 + スタックした[HTLC][topic htlc]のペナルティウェイト乗数を + [CLTV expiry delta][topic cltv expiry delta]に置き換え、 + スタックしたHTLCが流動性を拘束する期間をより適切に反映します。 + 最大CLTV expiry deltaを持つスタックしたHTLCへの過大なペナルティを軽減するため、 + このPRはレピュテーションの減衰パラメーター（`half-life`）を15日から30日に、 + スタック支払いのしきい値（`max-relay-duration`）を12秒から5分に調整します。 + +- [LDK #3897][]は、バックアップ取得中に失われたチャネル状態を検出することで、 + [ピアストレージ][topic peer storage]の実装を拡張します。これは、ピアのコピーをデシリアライズし、 + ローカルの状態と比較することで行われます。 + +{% include snippets/recap-ad.md when="2025-08-26 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32896,33106,8467,8354,3103,3134,3897,8362" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[lnd v0.19.3-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta +[core lightning v25.09rc2]: https://github.com/ElementsProject/lightning/releases/tag/v25.09rc2 +[towns bipshare]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aJvZwR_bPeT4LaH6@erisian.com.au/ +[towns bipdraft]: https://github.com/ajtowns/bips/blob/202508-sendtemplate/bip-ajtowns-sendtemplate.md +[news366 templshare]: /ja/newsletters/2025/08/08/#mempool +[delshare]: https://delvingbitcoin.org/t/sharing-block-templates/1906/13 +[towns templdiff]: https://delvingbitcoin.org/t/sharing-block-templates/1906/7 +[jahr templerlay]: https://delvingbitcoin.org/t/sharing-block-templates/1906/6 +[wuille templgr]: https://delvingbitcoin.org/t/sharing-block-templates/1906/9 +[doman tee]: https://delvingbitcoin.org/t/confidential-script-emulate-soft-forks-using-stateless-tees/1918/ +[tee]: https://en.wikipedia.org/wiki/Trusted_execution_environment +[news330 xpay]: /ja/newsletters/2024/11/22/#core-lightning-7799 +[news363 reputation]: /ja/newsletters/2025/07/18/#eclair-2716 +[zeus v0.11.3]: https://github.com/ZeusLN/zeus/releases/tag/v0.11.3 +[abdel tweet]: https://x.com/dimahledba/status/1951213485104181669 +[rustreexo webapp]: https://rustreexo-playground.starkwarebitcoin.dev/ +[rustreexo wasm]: https://github.com/AbdelStark/rustreexo-wasm +[b10c blog]: https://b10c.me/projects/024-peer-observer/ +[peer-observer github]: https://github.com/0xB10C/peer-observer +[bitcoin backbone]: https://mailing-list.bitcoindevs.xyz/bitcoindev/9812cde0-7bbb-41a6-8e3b-8a5d446c1b3cn@googlegroups.com +[kernel blog]: https://thecharlatan.ch/Kernel/ +[simplcityhl github]: https://github.com/BlockstreamResearch/SimplicityHL +[simplicity]: https://blockstream.com/simplicity.pdf +[simplicityhl delving]: https://delvingbitcoin.org/t/writing-simplicity-programs-with-simplicityhl/1900 +[simplicity post]: https://blog.blockstream.com/simplicity-launches-on-liquid-mainnet/ +[lsp btcpay github]: https://github.com/MegalithicBTC/BTCPayserver-LSPS1 +[proto blog]: https://proto.xyz/blog/posts/proto-rig-and-proto-fleet-a-paradigm-shift +[news260 mdk]: /ja/newsletters/2023/07/19/#mining-development-kit +[abdel tweet2]: https://x.com/dimahledba/status/1946223544234659877 From 5c4cedb54c56b45ee16181c66a41a7c39821801c Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 22 Aug 2025 21:49:48 +0900 Subject: [PATCH 218/278] Newsletter-368:fixup release candidate to release --- _posts/en/newsletters/2025-08-22-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2025-08-22-newsletter.md b/_posts/en/newsletters/2025-08-22-newsletter.md index 10e01a954f..b5f3b40b02 100644 --- a/_posts/en/newsletters/2025-08-22-newsletter.md +++ b/_posts/en/newsletters/2025-08-22-newsletter.md @@ -130,7 +130,7 @@ _New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates._ -- [LND v0.19.3-beta][] is a release candidate for a maintenance +- [LND v0.19.3-beta][] is a release for a maintenance version for this popular LN node implementation containing "important bug fixes". Most notably, "an optional migration [...] lowers disk and memory requirements for nodes significantly." From bdf0ac84b28fbfeb08bdfe38d1157b36e14713e8 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Fri, 22 Aug 2025 09:09:19 -0500 Subject: [PATCH 219/278] Podcast: add 366 transcription --- .../en/podcast/2025-08-12-newsletter-recap.md | 1463 ++++++++++++++++- 1 file changed, 1462 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-08-12-newsletter-recap.md b/_posts/en/podcast/2025-08-12-newsletter-recap.md index 4e4889d990..50e756cdc3 100644 --- a/_posts/en/podcast/2025-08-12-newsletter-recap.md +++ b/_posts/en/podcast/2025-08-12-newsletter-recap.md @@ -19,6 +19,1467 @@ Gloria Zhao and Mike Schmidt are joined by Tadge Dryja and Anthony Towns to disc ## Transcription -_transcription coming soon_ +**Mike Schmidt**: Welcome everyone to Bitcoin Optech Newsletter #366 Recap. +Today, we're going to be talking about draft BIPs for Utreexo; we're going to +talk about lowering the minimum relay feerate in Bitcoin Core; we're going to +talk about how sharing block templates can cut down on block propagation times +in a mempool-divergent Bitcoin Network; we have a Bitcoin Core PR Review Club on +watch-only functionality in Bitcoin Core's wallet; we have an Optech +recommendation, and also a correction to get to, in addition to our regular +Releases and Notable code segments. Today, I'm joined by Gloria, who's not only +a guest for today, but also my co-host. Gloria, say hi. + +**Gloria Zhao**: Hi. + +**Mike Schmidt**: And we have two news item guests as well. Tadge has joined us +today. Hey Tadge. + +**Tadge Dryja**: Hello, how's it going? + +**Mike Schmidt**: AJ. + +**Anthony Towns**: Howdy, how are you doing? + +_Draft BIPs proposed for Utreexo_ + +**Mike Schmidt**: Thank you both for joining us to represent your ideas here. +We're going to jump right into one of those, getting right into the news item, +"Draft BIPs proposed for Utreexo". Calvin Kim posted links of three BIPs to the +Bitcoin-Dev mailing list. All three BIPs are around the Utreexo project. One +is Utreexo's accumulator data structure; the second one is full node validation +using the accumulator rather than a full UTXO set; and the last one is P2P +changes to move extra data that Utreexo needs. These BIPs were authored by +Calvin, who posted to Bitcoin-Dev Mailing List; also, Davidson, who we had on +recently talking about Floresta on the show; and Tadge, the originator of +Utreexo idea, who has joined us today. Tadge, it must feel good to get these +BIP drafts out into the world. + +**Tadge Dryja**: Yeah, definitely. It's been a long time and it was great +writing them, because we realized how many things were like, "Oh, wait, we +haven't implemented this. We've sort of talked about that, but not actually +defined it". So, I think it's pretty well defined now, although there's +definitely a couple areas where we have implementations and specifications, but +it's like, "That could be better", and maybe we'll revise before it takes over. +But to the extent that there's any consensus-breaking changes, which is not even +really a consensus change, I think it's pretty set now. + +**Mike Schmidt**: How would you explain, like maybe give us a two-minute mental +model of the accumulator and how we can get the UTXO commitment down to such a +small size? I think that's one of the core pieces of this, right? + +**Tadge Dryja**: So, if people are familiar with merkle trees, the way a block +header commits to all the transactions in a block is with a merkle tree. And +you use this very similar technique in Utreexo to say, okay, a node will store a +commitment to all the UTXOs. And similarly, you can make proofs, right? Like, +in Bitcoin, we can make what's generally called SPV proofs, proofs that a +transaction is within a block, but we don't really do that much. I don't know +if there's anything in Bitcoin Core that still does that. I think it's mostly +removed. And similarly, in Utreexo, you don't actually make proofs generally. +It's sort of you're storing it because you computed it yourself. So, one of the +big confusion points is it's not a UTXO set commitment, right? It's not like +the miners now commit to a UTXO set and you can then sort of verify against +that. There's no consensus change. So, it's basically just replacing your +database with a smaller cryptographic accumulator, basically merkle roots, and +then you can verify transactions against that. + +**Mike Schmidt**: Okay, that makes sense. I don't know if you want to break -- +are there things that are notable, you think, for the audience within each one +of these BIPs, or maybe things that have significantly changed since you've had +more discussion going around Utreexo? + +**Tadge Dryja**: Sure. I guess, as general motivation, people debate a lot +about the block size and its 4 million weight units, or whatever, and you look +at the blockchain and its 700, 800 GB, or whatever it is now, and that gets a +lot of attention. But actually, if you're working on this, it's not that +important compared to the UTXO set size, which is much more limiting and slows +things down and more of a concern. And so, this addresses that, this doesn't +address block size, although you can think of it as a retroactive block size +increase if you want to, if you want to get people riled up, because the extra +messaging is, now you need proofs alongside your historic transactions. So, +yeah, we split it up into the accumulator design, which is sort of a modified, +more complex merkle tree that doesn't just have one merkle root. It's got a +bunch of merkle roots, but still is pretty small. I think it never gets over 1 +or 2 kB; and then, the validation, which is saying, okay, if you're a node that +does this, you have just these merkle roots, and someone wants to give you a +transaction or a block and prove that this is valid so that you're doing the +same exact validation as regular, full Bitcoin Core, here's how you do that, how +you verify these proofs, and stuff; and then, the P2P messages, which is one of +the things that took the longest and this is the most complex because there are +so many optimizations we can make. + +So, these proofs initially seem pretty big and it potentially about doubles the +size of IBD (Initial Block Download), which seems bad, but you can compact them +quite a bit. Because if you look at how Bitcoin works today, and this is +totally heuristic, this is not a provable property of the system. But if you +look at Bitcoin today and you look at like how old UTXOs are when they get +spent, it's a very power-law distribution, where the most common age for UTXO +being spent is zero blocks, that it's created and destroyed in the same block. +And then, the second most common age is one block. And I think it's like half +of UTXOs that are being spent are spent within six blocks of them being created, +something like that. And there's also a big spike at six, because everyone, for +whatever reason, waits six blocks and then spends their coins. + +So, just because of those properties, which could change in theory, but it's +been pretty consistent for the ten-plus years we're looking at this, if you cash +a little bit, if you say, "Okay, I'm not storing the full UTXO set, I'm not +storing all these things. But hey, I will store stuff from the last few blocks, +because I know it's so likely to be spent", then your proofs can dramatically +get smaller in size. And so, there's a bunch of messages to how to deal with +that, like, "Oh, I only need a partial proof for this transaction or this +block", and that gets kind of complicated. So, we don't deal with compact +blocks right now. That would be another thing we'd have to, you know, "How +would Utreexo work with compact blocks?" It would, but that's not defined yet. +We'd have to work on a revision to it later. So, the complex part ends up being +the P2P stuff, which I think people can identify with. A lot of people now are +working on P2P messages and mempool stuff, where it hadn't been as looked at +five, ten years ago, and now it's like, "Oh wait, this P2P stuff's kind of +tricky". + +**Mike Schmidt**: You talked about P2P, and you maybe touched on this briefly, +but maybe we can double-click into it, the different types of nodes? And then, +maybe even just clarifying for people which of those, are they all on the +Bitcoin Network? Are we talking about sending Bitcoin P2P messages? Are they +all sending Bitcoin P2P messages? Or is there some sort of side network of +Utreexo nodes that are communicating some side information, or maybe just +elaborate on all that? + +**Tadge Dryja**: Yeah, you can think of it as a side network, but it speaks +mainly the same protocol as regular Bitcoin on port 8333 or P2P v2 as well. But +it is an extra sort of network flag, and actually there's two extra network +flags. So, you can think of it sort of like, I guess one similar thing was the +block filters, where you can have nodes that say, "Hey, I have I have block +filters and I will send those to you", and you have an extra message for that. +Or like the old, I think it's deprecated, bloom filters, where a node that was +like an SPV node that wasn't a full node, but still spoke the regular Bitcoin +protocol, could connect to a full node and say, "Hey, here's a bloom filter, +please filter blocks when you send them to me". And that full node would then +take a block, match it against the bloom filter, only send certain transactions. +That worked sort of, but it didn't really work well, and I think people got rid +of it because it was actually a pretty heavy load on the nodes CPU. So, that's +one of the things we worked on to make sure that the nodes doing the serving, +it's very lightweight for them; and if there's work to be done, have the +validating client do the work. + +But yeah, so there's two flags. One is node Utreexo, where it's got these +proofs. And basically, that means if you're going to send inv messages, if +you're going to say, "Hey, I have a transaction", and then you give the +transaction to the other person, you need to give these hash-based proofs if +they request it. And then, the other is, I think it's called 'node Utreexo +archive' or no, did we call it network? It's weird, because in regular Bitcoin, +node network means you have all the historical blocks. I don't really know why +the word 'network' means that but it does. And I don't think we actually called +it 'node Utreexo network', I think we called it 'Utreexo archive', because +that's a better word for it. But if people will say, "Hey, let's change it to +'network' to be in keeping with the other messages", sure. And that means you +have proofs for historical blocks. And those are separate because they're +already sort of separate in regular Bitcoin nodes. You can have the full UTXO +set and propagate transactions, but not have historic blocks. And so, we wanted +to keep that separate as well. + +It's also separate in that you can have Utreexo proofs for old blocks, like +blocks ten years ago, but not actually have those old blocks. That's a little +weird, but it actually seems pretty useful, because if you have all these old +proofs, it's getting close to a TB. And similarly with Bitcoin, if you have all +the archive blocks from 15 years, it's getting close to a TB, 700, 800 GB. And +so, it's actually, in terms of the code, very easy to separate those things. +They don't need to be stuck together on the same computer, right? So, if you're +a Utreexo proof node, you can say, "I don't actually have block 300,000, but +I've got the proof for it", and you can go get block 300,000 from someone else +who's running regular, unmodified Bitcoin Core. And for the validators and for +the servers, it seems really easy to do that. So, it's like, yeah, why not have +that ability? It's easy to run both at the same time, on the same computer, but +it's also easy to have them separate. And that means that if you only have like +a 1-TB SSD and you want to run an archive node and serve blocks or proofs to +someone, you can do that this way. + +**Gloria Zhao**: So, if you're a Utreexo node, in IBD you would look for these +archival Utreexo nodes? + +**Tadge Dryja**: Yes. + +**Gloria Zhao**: And then, when you're out of IBD, you would look for the other +kind that can give you proofs closer to the tip but don't necessarily have the +full data? + +**Tadge Dryja**: Yeah. The normal ones will give you like in-mempool proofs, +and that's fairly small. And then, the other ones will have the sort of +archive. It's similar to how when you're doing IBD, I don't actually know if +Core does this, I don't think so, but when you're doing IBD, you don't need to +connect to a normal node. I mean, I don't think there's any nodes that only +have historic blocks and don't give you invs and new transactions and have a +mempool. I guess you could do that, but I don't think anyone has. But yeah, +you can have those two things separate. And we haven't separated it either. We +just put the messages in because it was like, in theory, you could do it, you +can have all these different combinations of functionality in a node. We +haven't coded it though. + +**Gloria Zhao**: I guess you could have a blocks-only today that advertises node +network, and then when you're out of IBD, you do a network limited. + +**Tadge Dryja**: Yeah, so you can do that. I mean, I'm not going to program +that, I don't know if anyone else is, but it's like if someone wanted to, you +know… It's just when we're thinking of the spec, yeah, you need to have an +implementation, but you don't need to have an implementation of all the possible +things you could do with the spec, I guess. And so, part of it was, it's not +really any more complex to let these sorts of options open. And I sort of worry +about, having worked on LN ten years ago, there's a lot of things that when you +start making a protocol, you're like, "Oh man, don't screw it up in the +beginning", because then you're sort of stuck with things for a decade. So, +it's like try to make it pretty extensible, pretty flexible, pretty simple. And +who knows? And maybe this doesn't take off and no one really ends up using it. +Hopefully people use it though. And it probably will be the case that people +use a very strict subset where it's like, every node that's archived also has +both blocks and proofs. And you'll have both those flags at the same time. +Okay, that's fine. But if anyone wanted to, the code would probably work with +those separate. + +**Gloria Zhao**: I guess you would include this if you find you have a shortage +of archival nodes, right? Like, I don't know what incentives people have to run +these, you know. I assume there's some of them. And I guess because not +everybody needs the full archival stuff, splitting that into two different +services can help make those slots available for people who actually need it. + +**Tadge Dryja**: Yeah, I guess. Yeah. So, it's just like regular Bitcoin Core +nodes, there's no incentive to have node network and serve blocks. And it seems +to work. I don't even know what the metric of like, how do we even detect if +that's becoming scarce, if it's hard to IBD? I don't know. But yeah, there's +same idea, you know, there's no incentives and you just hope some people run it. +But in Utreexo, there's similarly this sort of bridge node functionality where +-- sorry, I haven't talked about. + +There's regular nodes they can do post-IBD and there's the archive nodes, and +then there's also, not specified in the messages, but you need some nodes that +have the full UTXO set and can sort of translate and say, "I'm going to take +regular mempool transactions, stick a proof onto them and send them over to +Utreexo nodes with the proof". In theory, if everyone used Utreexo and every +wallet supported it, you wouldn't need this, because every wallet would just +stick a proof onto the transactions it was creating. But that's almost +certainly never going to happen, and certainly isn't the case now. And so, you +need these sort of nodes to bridge and put proofs on. And some people don't +like this, it's like, "Oh, this kind of a weak link". And so, I don't think +it's that big of a problem, but we recognize that, yeah, if you take out all the +bridge nodes, you do sort of split these two networks, and all the Utreexo nodes +won't be able to validate anymore, right? They won't validate current +transactions. + +So, we made it so that the bridge nodes don't advertise themselves as such, +right? They're running full validation, full UTXO set Bitcoin nodes at the same +time that they're running the Utreexo accumulator, but they don't tell each +side. From the Utreexo nodes, they just say, "Yeah, I'm a Utreexo node", and to +other normal nodes, they say, "Yeah, I'm a normal Bitcoin node". So, that's how +sort of, you only need a few of them. And then once you have these +proof-carrying transactions, those can propagate among non-bridge nodes that run +Utreexo. + +**Mike Schmidt**: AJ, do you have thoughts on Utreexo that you'd like to share? + +**Anthony Towns**: So, the bridge nodes need to do a lot more processing than +the archival nodes, right, because they need to update the proofs as the state +gets updated? Is that still right? + +**Tadge Dryja**: Yes. Well, so they need to do more than the archive because +the archive doesn't even have any currently changing proofs. But they do the +same amount of CPU work as any validating node, since when a block comes in, you +sort of automatically update all your proofs. So, bridge node, CPU wise, it's +very simple. There's a bit more disk I/O, but it's pretty manageable. So, that +was basically why we used the design we did in Utreexo, is because there's a lot +of cooler accumulator designs and people are like, "Oh, use RSA accumulators", +or this kind of thing. And the problem there is the bridge nodes updating the +proofs is expensive, whereas with this one, updating the proofs is very cheap. + +**Anthony Towns**: And so, you have a bridge node running somewhere now with +what sort of hardware does that run on? + +**Tadge Dryja**: Oh, I mean any computer that can run Bitcoin Core now can run +it. It adds, I don't know, a few percent CPU. But in the space to have the +full proof thing for a bridge node, it's 20 GB, 30 GB. You know, there's some +size, and that's 20 GB, 30 GB in more of a LevelDB kind of thing than a flat +files. So, it's some and it's bigger than the UTXO set, but it's not too bad. +It seems to be on the order of running a current Bitcoin full node. + +**Anthony Towns**: So, it increases UTXO size by factor 3 or 4, or something +like that, I guess, or 2 or 3, maybe? + +**Tadge Dryja**: Yeah, and that's because we're using LevelDB. I know there's +better ways to do this that would reduce that overhead to be about double, but +right now, we're using just a regular key-value store for it. Yeah, so +basically, if you can run Bitcoin Core current full node, not even archive, with +a computer today and it's not really taxing on that computer, you should +definitely be able to run a bridge node. And that's our goal anyway. + +**Anthony Towns**: And the code is currently in Go or Rust or something, right? + +**Tadge Dryja**: Yeah, all of the bridge node stuff is in Go and we've been +using btcd. We could add stuff to Core to have like an extra bridge node +functionality, but the hard part is changing Core to not use LevelDB would be a +big thing. And so, what we're really interested in now is there's +libbitcoinkernel, which does seem to allow … because we're using btcd, but it +would be great to be able to import Bitcoin's sort of consensus engine and say, +"Hey, here's a block and here's a UTXO viewpoint that we've, you know, that's +the part we've generated. Tell us if this block is valid or not", and then not +have to use a different implementation for the block validation. I think that's +something we are working on. + +**Anthony Towns**: Sure. And so, if someone wanted to run this and fire it up +the btcd-based implementation, how long would IBD take on a regular computer? + +**Tadge Dryja**: So, if you want to become like a proof node that has proof +archives, it's currently really slow. We need to make that faster. It takes a +couple of days. + +**Anthony Towns**: How slow is really slow? Like a week, a month? + +**Tadge Dryja**: I think it's like four or five days. So, significantly slower. +It's the kind of thing where we know how to do it, it's just there's a lot of +interesting algorithmic things here that we could fix. But a lot of it is just +like, let's get something that works that we can get progress and get people +looking at it. And then for a Utreexo node that doesn't have archive and +doesn't have all this abridged node, I think it's not too much slower than Core +today. It's still slower, which is unfortunate, and that's mostly because of +the btcd stuff and signature validation. So, it'd be great to use something +like libbitcoinkernel, which could potentially speed it up. + +We did do this thing, I think it was like two years ago, where we split it up +and we had, I think, four different computers doing IBD at once. And we sort of +said, "Okay, this computer does blocks zero to 300,000; this one does 300,000 to +500,000", which is something you can do pretty easily with Utreexo because the +entire state fits in one TCP packet. So, you can sort of send a worker computer +like, "Hey, validate these 1,000 blocks", and then it just gives you a thumbs up +or thumbs down. And then, I think we did IBD. It was sort of a stunt, but it's +like, "Oh, we got IBD to work in two hours, cool!" But yeah, I don't know how +practical it is, but yeah, so the current implementation is still a bit slower. +But it seems that in theory, potentially it could get faster, because you're not +bottlenecked by disk I/O with LevelDB. + +**Anthony Towns**: Cool. + +**Mike Schmidt**: Tadge, the work is out in the world now. Any feedback so far +and what are next steps? What can listeners do who are technically curious, +etc? + +**Tadge Dryja**: Yeah, definitely take a look at the specs and you can try +running it. Definitely don't put all your money on it, it's not robust, but we +definitely want other people to come work on it and look at it. I think it's a +cool thing as maybe a long-term thing, but it does seem like long term, it's +like, "Well, how big is UTXO set going to grow? Will this become a problem?" +And it's nice to have this thing where it's like, "Oh, we have a solution and +we're working on it and making it better". So, hopefully, definitely want +people to take a look and give comments. And we have a Utreexo call on Jitsi +every Monday morning, US Eastern time, or Monday evening in Asia. So, +definitely want more people to join and ask questions and try to work on it. + +**Mike Schmidt**: Go ahead, Gloria. + +**Gloria Zhao**: Is there anything in particular that you're looking for +feedback on, like a particular problem, and you're wondering if there's a +solution or if it's worth solving or what stability things? + +**Mike Schmidt**: Yeah, not so much in the specs, although if there's some +things in the specs where people are like, "Hey, this is a bad idea because this +will be annoying for other people", or something, then sure. In the +implementation, there's definitely a lot of stuff where we're just like, "I +don't know, let's use a hash map and map all these things", and it gets really +ugly and there's all these garbage collectors. And it's like, we know that's +bad, but it's just like, I don't know, is there a better algorithm for this? +Because we have these big merkle trees and we want some efficient representation +with pointers of partial merkle trees and stuff. And there's definitely ways to +do it, but anyway, we can do it sort of the easy way now. So, +implementation-wise, I think there's some interesting, kind of cool algorithm-y +things that people could look at. So, yeah, that's one thing, if people have +cool ideas. And it seems like the kind of thing where if you knew what you're +doing and had a good idea for the algorithm, you could be like, "Oh, hey, this +is now 10 times faster". It's like, "Oh, great". + +**Mike Schmidt**: Tadge, we're going to talk about relay and mempool if you want +to hang out, otherwise we appreciate you joining. All right, cool. + +**Tadge Dryja**: I'll stay on. + +_Continued discussion about lowering the minimum relay feerate_ + +**Mike Schmidt**: Second news item, "Continued discussion about lowering the +minimum relay feerate". Gloria, you posted to Delving discussing lowering the +minimum relay feerate. Maybe I'll let you frame it up. What motivated this +discussion and your associated PR to Bitcoin Core to actually make the changes? + +**Gloria Zhao**: So, yeah, I think for the past few years, people have asked +about this a lot. So, the minimum relay feerate hasn't been touched for about +ten years, and people often ask me like, "Oh, can we lower that, because it's +getting kind of expensive". And I think it never felt like something worth +thinking about, because I think we've got a real problem if fees continue to be +really, really, really low in the long term. So, I think based on that alone, I +always thought of it as a low-urgency or low-priority policy to look at if we +ever needed to reconsider it. And I imagine you guys have talked about this on +Optech for the past month or so, but there's a lot of sub-1-sat/vB (satoshi per +virtual byte) transactions that are being relayed and mined. I was hearing like +80% to 85% of miners from a tweet. I didn't verify that. But the thing that +made it very urgent in my mind was seeing 0xB10C's stats on compact block +reconstruction, where I think the numbers were for 70% of blocks, it requires an +extra round trip to get those transactions, and it's 800 kB on average for those +blocks. And I think we're seeing about 100,000 transactions that are below 1 +sat/vB per day or so. And so, this became a lot more urgent. + +I don't know that it's kind of, you know, it's kind of dumb that miners are +doing this, but that was the motivation. And Robin Linus had opened a PR to +Bitcoin Core, and there were a few things wrong with the request and there +wasn't kind of the standards that we might have for changing a default policy +setting. So, I kind of took the mic from him, I guess -- sorry, Robin -- and +wanted to open a proper PR with tests and everything, and then start this +mailing-list discussion, because it's something that needs to be discussed. And +AJ provided some really good framing for how to choose an exact number I think +for PRs like this. Often the difficult part is like, "All right, we agree, the +current number is bad. What should the new number be?" And I don't know if, +AJ, you want to jump in and talk about your calculations for the comparison with +using EC2 bandwidth costs? + +**Anthony Towns**: Sure. When I started reading the PR, my thought was much +more on keeping minor fees at some sort of level that would have a reasonable +relationship to the block reward subsidy, because that's the long-term view. +But looking back on the PRs, particularly the last one that updated the min fee, +Matt's reasoning was much more focused on the effective cost of sending a +transaction, the effective bandwidth cost of sending a transaction across the +network, because that's the cost you're incurring when you relay a transaction. +You send it to one person, they send it to 8 or 100 other people, each of which +send it on to their peers. And everyone who sends that on is incurring a small +bandwidth cost for their VPS provider or for their home node not being able to +download Netflix movies quite as fast. And the thing with that cost is it's +distributed amongst everyone that's using Bitcoin, but it's kind of benefiting +the people making the transactions who are only sending a few bytes of data +rather than the MBs that it ends up being when you copy the transactions across +100,000 nodes. + +So, back when the feerate was dropped to the 1 sat/vB, the comparison was to EC2 +prices and how much it would cost to basically send the same amount of data via, +I guess, relatively expensive EC2 data rates. And doing the same calculation +now, obviously Bitcoin is much more valuable, so every satoshi is much more +valuable, so that changes the rate a bit. But the same formula works +independently of that, and it's just a relationship between the price of +Bitcoin, the cost of bandwidth and the number of nodes on the P2P Network. And +that kind of gives you a rough formula for what a reasonable rate is, that if +someone was able to use sending a transaction to attack the network, then you +don't want that to be cheaper than just attacking the network directly. So, +that seems like a good metric to me. + +**Gloria Zhao**: Yeah. So, I think we landed on somewhere between, I want to +say 35 and 100 satoshis per kvB being the range that would make sense. So, just +picked 100 as a nice round number that would be easy to reason about. And then, +I collected some stats on what kinds of transactions we're seeing that are under +1 sat/vB to see if like 0.1 would capture all of them, or if most of them are +actually even below that, because then this wouldn't really help with compact +block reconstruction. And 97% of these really low feerate transactions are at +or above 0.1, which is the threshold that we set in the PR. And then the other +3%, the vast majority are zero. So, I was kind of guessing that either that's a +package, a TRUC (Topologically Restricted Until Confirmation) package, or the +miner's own transactions. So, maybe it's actually even higher than 97% that +would be captured by the 0.1 sat/vB new filter. And we can't lower it to zero +anyway, so it doesn't really make sense to make it go down further to +accommodate those. + +I guess there was some discussion on the Delving post. One of the topics was +like, "Oh, what if we add proof of work to transactions? Would this address the +same thing that min relay feerate is going for?" Tadge seems to have some +opinions. I thought it was not really something you can ask wallets to do, like +signing devices to do. But I guess since you talked about bridge nodes, maybe +you could have bridge nodes that like add work to things, but why the heck would +they do that? + +**Tadge Dryja**: Feels like that's what the fees are there for. So, you're +paying someone else to do the work, but yeah. + +**Anthony Towns**: You could add, with segregated witness transactions, you +could add proof of work to the txid and then sign it afterwards, which only +changes the wtxid and doesn't invalidate the proof of work. So, that would be +technically possible. But the problem with it is that proof of work is +centralized amongst people who own ASICs, and so that really advantages a small +number of people who might then want to spam the network or otherwise control +it, as opposed to random people who just want to make transactions. So, that +seems pretty obnoxious to me. + +**Gloria Zhao**: I think it's maybe the kind of idea you come up with when +you're working on the P2P code that does, and you're like, "Oh, the difference +between these transactions and blocks is one of them has work and the other one +doesn't. We should just have them both require work". + +**Anthony Towns**: Yeah. So, the old thing we used to have was priority +transactions, where you don't have to pay a fee or you don't have to pay as much +fee if you're spending a really old transaction, like if you're spending a +really old UTXO. So, that was based on Bitcoin Days Destroyed, I think. So, if +you had 2 bitcoin sitting around for three months, then that's 180 Bitcoin Days +Destroyed when you spend it. And that's a different sort of proof of work, kind +of like a proof of hodl, I guess, that you could also use, but that doesn't +benefit miners at all. So, it's not really economically aligned to their +self-interest. So, we had that functionality and it went away because miners +weren't using it anymore. + +**Tadge Dryja**: It was great while it lasted. You could make really cheap +transactions, but yeah. + +**Mike Schmidt**: Gloria, I have a few questions for you. You mentioned you +can't drop it to zero. Can you outline why? + +**Gloria Zhao**: Well, as AJ talked about, the purpose of this particular policy +is to account for the fact that each node on the network and the network as a +whole incurs a cost for relaying the signed, confirmed transaction. And let's +say your goal was to make the network waste bandwidth on this, you should incur +a cost that is kind of proportional/more expensive than the cost to the network. +And so, we have this minimum bar where even if there's changes in demand, we +don't relay transactions that are below this threshold, at least by default in +Bitcoin Core. Because transaction relay has this magnified effect, as AJ was +talking about. You send it to one node, they send it to all their peers, and +use all their peers. And so, that's why we multiply the amount of bandwidth, or +the amount of the serialized size of this transaction by something that is a +function of the number of nodes on the network to calculate this bandwidth cost. + +**Mike Schmidt**: So, you're Gloria, protector of node runners! + +**Gloria Zhao**: Awesome! Well, I didn't invent this policy, I think Satoshi +did! + +**Mike Schmidt**: Would you say that this change is rushed? + +**Gloria Zhao**: Yeah, I mean, yes, because it's kind of urgent. I think people +have pointed this out where they're like, "Oh, why are you rushing changes? +This should be done slow and steady", or whatever. Well, it has a pretty +significant impact on the network from a block relay perspective. So, it kind +of jumped up in the priority queue. I don't think it means we should just +blindly choose numbers, but that's why you start the discussion, right, and +encourage people to give feedback. Yeah, we can own it. It's being prioritized +because it's high priority. + +**Mike Schmidt**: I'll piggyback on that with my other question, and I have a +few more. Does the fact that there's so many of these transactions now and +Bitcoin Core is essentially blind to them, does that mean you want to backport +this to previous versions? + +**Gloria Zhao**: Yeah, so we had a chat about this at the IRC meeting last week, +because usually policy changes are considered like features. Are they? Well, +for the most part, it depends. Like TRUC, for example, was not backported, it's +more a feature really, or package stuff. Sorry? + +**Anthony Towns**: TRUC is a bit more complicated, and 1p1c +(one-parent-one-child package relay), and stuff. That's harder to backport. + +**Gloria Zhao**: That's true, yeah. But I guess we can also get to this later +for the 29.1 RC, but this is, I think, problematic enough where you'd consider +it a bug that older nodes are not able to download blocks as quickly as they +could due to current network conditions. So, yeah. + +**Tadge Dryja**: Would you say, like, if someone's running older software, you +can just edit Bitcoin.conf and set your min tx relay. Would you recommend, or +are you making other changes as well? Or is it like, "Hey, if you're running +0.27, you can't upgrade for some reason, just reduce the min tx relay fee in +your conf file, and it should fix it mostly"? + +**Gloria Zhao**: I think I would recommend that, yeah. + +**Anthony Towns**: For what it's worth, I've done that on my node, which I guess +is fairly well known. I've seen it in some of the nodes that will relay +sub-1-sat/vB things if you're trying to do a transaction and you need to get it +out there. And looking at my compact block relay logs from that, I'm mostly not +seeing the same 800-kB extra bunch of transaction roundtrip stuff, but I am +still seeing 1, 4, 8, 5 transactions needing to be requested in an extra +roundtrip. So, even running a pretty well-known node for that isn't getting me +enough connectivity to get all those transactions in my mempool first, to do the +one-shot reconstruction of the compact blocks, which is a bit disappointing. I +don't think it's taking very long to do the round trip so I don't think it's +having that huge an impact on block relay, but it's getting it down so we're +doing it the way that we expect. Seems a fair bit better still. + +**Gloria Zhao**: So, you're thinking that handful of transactions you're still +missing are just not getting to you before the block because so little of the +network is doing this? + +**Anthony Towns**: So, either the transactions are getting to a miner either +directly, or the network's just a little bit not connected well enough or +something, or else maybe people are doing double spend. So, I'm getting one +version of a transaction, the miner's getting another, and so obviously I'm not +getting the miner's version because I've already got one at the same feerate, so +it doesn't RBF, or something. I don't know, I haven't looked into it in that +detail. So, yeah, I'm getting like 1, 16, 2, 1, 14, 1, 1. And then, on the +blocks that are above 1 sat/vB min fee, I'm just getting them directly with zero +transactions that need to be requested. + +**Mike Schmidt**: I have more questions for you, Gloria. What about setting the +minimum relay fees dynamically? + +**Gloria Zhao**: Yeah, I think I saw a comment from David this morning about +that. There's some concern about this value being basically a conversion rate +between BTC to bandwidth costs. And I think there were like feelings of +ickiness around having that hard-coded, or something. And my response was +essentially that there are a lot of hard-coded things. Well, there are several +hard-coded things in Bitcoin Core that are designed to kind of ground it in +economic reality or state of computer processing reality. Like the header sync +parameters, we have the script that we run to generate those parameters that are +like, "Oh, we think an attacker can hash headers this quickly, because a current +Ryzen blah, blah, blah processor, we benchmarked it and we can do this many +hashes per second", or something like that. And that's sort of the name of a +processor. And obviously that will change over time, but these are things that +change so slowly and gradually that it wouldn't even be nearly as much as our +headers params or the same params or the hard-coded seeds for peers, things like +that. So, I think it's very normal to do that. + +I don't think this is something that should change very often. I think it +should be grounded in reality, and hopefully change more than every ten years, +hopefully slightly more responsive. But no, I don't think it's appropriate to +move it up and down. Like, policy getting stricter, for example, should be a +more involved process because it can cause people with certain applications and +assumptions that they're making when they're broadcasting transactions, it can +make those assumptions break. And then, suddenly they can't broadcast their +transactions on the network. So, making things stricter shouldn't really be +done willy-nilly. And so, yeah, I don't really think we should be turning the +style every release or something. + +**Anthony Towns**: I'll add a comment to that, and that is that, I mean we do +have the mempool minfeerate, which is dynamic, based on how much of a backlog of +transactions there are. So, once the mempool fills up and we start evicting the +cheapest transactions, we'll bump the minimum feerate up to whatever the level +is that we evicted transactions from. So, the parameter that we've got here is +really doing two things. It's setting a minimum when there's basically no +competition for block space. So, before the 100 sat/kvB summer came in, we had +a whole bunch of basically empty blocks, which I mean is fine, but is also not +getting much value from the blocks that are coming through. And so, if this +setting is blocking that, then maybe it's worth dropping. + +In a future where we've got a huge backlog, fees are driving miners' rewards, +then maybe the mempool min fee is enough to keep some lower bound there, and we +don't need this setting at all and could drop it to zero. I mean, the node +software works if you drop it to zero, you just get random trash that's never +going to be mined in your mempool, so it's not that useful. And the other thing +is, you could have a setting that does this differently. So, instead of saying, +"We won't ever do something that costs 0.01 sat/vB", you could say, "We'll allow +some transactions through, but we'll rate-limit them so that there aren't too +many and we don't get a DoS flood of our bandwidth", or whatever. But that +would be a much more complicated change to the logic that you can't just rush +through in response to, "This is what the network's doing", and we want to make +it work with what people are actually doing on the network. So, that's my +thoughts anyway. + +**Mike Schmidt**: Gloria, what has the feedback been on Delving and on the PR? +I see a lot of ACKs on the PR, for example, but I do see some NACKs. What's the +steelman objection to this change? Is it specific to the nuances of your +approach or is it a NACK conceptually? What's the steelman against this? + +**Gloria Zhao**: I don't want to mischaracterize, but I think some of the more +common NACKs that I see are that the really low feerate transactions are spammy +and I guess it's kind of the filtering crowd, the people who want Bitcoin Core's +default policy to be stricter in order to try to limit the transactions that end +up being confirmed on the network. And we've had this debate many, many times. +Bitcoin Core isn't able to control what gets mined or what ends up onchain. +It's part of the piece of the puzzle in terms of being able to relay +transactions on the network. But the fact that we see so many transactions that +are filtered by Bitcoin Core's policy, I think is proof that it's not really an +ability that Bitcoin Core has. So, I think that's the main objection. + +I think another one is maybe the formulation of, "Oh, the price has changed and +that has impacted what we think the new numbers should be". I think maybe +people are object to the idea of price having a role in the protocol, or +something like that. And I mean, I think because of what this policy is +supposed to do, it's a translation from what resources are consumed by the +network and translating that to a cost to the attacker. And so, it should be +grounded in reality. + +**Tadge Dryja**: Maybe to respond to some of the people, am I correct in saying +that it's not the case that the people like yourself are like, "Oh, we're +reducing it by 10X". You're not happy about it, right? Because for me, it's +like, "Oh, yeah, we've got do this", but it's not good. It's sort of because +long term, it's like, "Yeah, this is real low. I don't see how this is going to +fund mining after new coins stop coming out", kind of thing; is that your take +on it? + +**Gloria Zhao**: Exactly. Two years ago when people would ask me this and +they're like, "Oh, can we lower it?" I'm like, "Why would we? Blocks are +always full and mempools haven't cleared in months, I don't think this is ever +going to be relevant". And then of course, now it is relevant again. But I +think that's really not a good thing that we're thinking about what the lower +end of fees should look like. The problems you'd think we would be solving at +this point, when the subsidy is going down and down, is things like package +relay and making sure fee bumping is efficient, because I really didn't think we +would get to this point where we're like, "Oh, the really cheap ones when +there's no competition, we might as well have some extra sats because otherwise +it's empty space". This is really bad. I don't want the network to be full of +these kinds of transactions, but it's similar to data stuffing as well. It's +not really what we should -- I didn't think we would be here. + +**Tadge Dryja**: So, it's sort of like, hopefully we won't really have to think +about this problem long term because there will be much higher fees and stuff, +yeah. + +**Gloria Zhao**: Yeah. I mean, so I guess this is the case. So, right now with +the package relay rules, unless it's a TRUC transaction, it does have to be +above the minimum relay feerate. So, this does make package relay maybe +slightly more potent because you can now be bumping something that is 0.1 sat/vB +instead of 1 sat/vB. So, there's that, but yeah, it's not very exciting. + +**Tadge Dryja**: Does it also change the definition of dust in some way? + +**Gloria Zhao**: No. The dust feerate is separate from the minimum relay +feerate. Yeah, we're actually changing three minimum feerates in Bitcoin Core +that are tied to each other, but dust isn't one of them. I think dust should go +up over time. + +**Anthony Towns**: So, changing the dust, like the dust amount gets baked into +like LN protocols and stuff in that you have to specify in the LN negotiation +that it's an error if you make an output that is below the dust amount. So, +changing the dust amount, particularly ever moving it up, is pretty scary for +breaking all that sort of software. And for me, that also makes it harder to +take it down, because if you take it down too far and want to bring it back up, +if anyone's relied on that, then that's a breaking change for them, which is +kind of obnoxious. So, that's a, "Let's leave this well enough alone as far as +possible", for me. + +**Gloria Zhao**: That's true. Yeah, I think dust is also kind of, it's not +really what's the absolute minimum that a transaction could be, it's more like +what can we reliably say will get consolidated or can get consolidated at some +point. So, I don't think it's quite the same. + +**Anthony Towns**: But of course, if we have Utreexo everywhere, then the dust +amount doesn't matter. It can just go away entirely, right? + +**Gloria Zhao**: There you go. Yeah. But it's also like, I don't know, one +thing I was trying to say in the PR originally, and then I ended up deleting it +because I don't know if it made any sense, is at some point, if all of the miner +reward is fees, then there is an amount that will never really make sense. +Like, as a function of the amount that you could transact within a block, dust +is almost, okay, maybe this doesn't make any sense, but you can only have so +many transactions per block and all of the rewards come from fees. So, it feels +like at that point, dust should go up. I don't know if this makes any sense, +but anyway. + +**Anthony Towns**: That might be the same sort of thing as the mempool min fee +going up, it's just something that people do for their own self-interest rather +than something the code needs to enforce at that point, because if you're paying +lots of fees and Bitcoin's really valuable, you don't want to burn some sats to +something that you're never going to be able to spend. And you don't need +software to tell you that, you're just a sensible person because that's how you +got into Bitcoin in the first place. So, maybe that's too optimistic. + +**Mike Schmidt**: Very optimistic. Gloria, anything you want to wrap up with or +calls to action? + +**Gloria Zhao**: No, we've noodled on this quite a long time. We can move on. + +_Peer block template sharing to mitigate problems with divergent mempool policies_ + +**Mike Schmidt**: Great. Last news item this week, "Peer block template sharing +to mitigate problems with divergent mempool policies". AJ, you posted to +Delving a write-up about peers sharing block templates. You pointed out the +trend of diverging mempool policies over time and resulting impact on compact +block relay, and some of the research from 0xB10C. You then go on to put forth +block template sharing as a potential solution. What is block template sharing? + +**Anthony Towns**: Okay, so when we have the mempool, that is a consistent +collection of transactions that could go in future blocks based on what the +current tip is. So, we don't have conflicting transactions, obviously we don't +have invalid transactions, we don't have transactions that don't match whatever +our block building policy would be. And so, that's where you get into the +divergent mental policy. So, if I were building a block and I didn't want to +include large OP_RETURNS or low-fee things or inscriptions, or whatever policies +I might have for the blocks I build, then that policy then reflects in the +mempool and they're just transactions I won't accept or relay. But obviously, +what my policy for building blocks is doesn't necessarily match other people's +policy for building blocks. And so, they may well accept transactions that I +won't. If they do that and they win a block, then when that block gets relayed, +I won't be able to cheaply reconstruct it because I don't have all the +transactions in it. And that's how the compact block relay stuff slows down. +And it doesn't slow down that much, it's just, "Here's the block that you need +to do and a hint as to how to reconstruct it". "Oh, I can't reconstruct it +because I'm missing these transactions. Can you give me them?" "Yeah, okay, +I've got the transactions". + +But when I'm sitting in the network and I've got whatever my policy is, I'm +connected to a bunch of other nodes that might have other policies. And if +blocks are coming in from people who share my peers' policies, so if I've got +some Knots neighbors and Ocean wins a block, then there's a fairly good chance +that maybe the Knots nodes that I'm paired with will have a similar policy to +the Ocean miner that built the next block. Or if I have a Libre node, a Libre +Relay here, then maybe that's got a pretty close-matching policy to what MARA +pool might be mining for their block if that's what comes in next. + +So, the idea is that instead of just relaying the transactions and building up a +mempool, also relay what my guess of the next block is. So, I'll make a guess +of the next block and I'll make a template of that and I'll allow my peers to +request that template and store it. So, If I've got the Libre Relay peer and I +request their template, then I might get some transactions with large OP_RETURNS +or with really low feerates, or that had been bumped by RBFr instead of RBF that +I would have rejected but they would have accepted. And that's a relatively +scalable way of doing it, because it's only 4 MB worth of transactions from each +peer, rather than 300 MB of mempool from each peer. + +So, the idea is that if we can get an idea of what all my peers' templates would +be doing, then there's a much higher probability, even if mempools' policies are +divergent, that I'll have the transactions for whatever miner builds the next +block, and thus be able to reconstruct the compact block straightaway. Okay, +did that make any sense, what are the questions from that? + +**Mike Schmidt**: I have a question from that. What happens when I'm a Knots +node runner and I request from a Libre Relay and I get all this stuff. Do I +say, "Oh, this might actually happen so I might as well retain it this time", +even though I didn't retain it when it was potentially circulating the network +previously; like, is there a specific data structure that this would go into +that would be more liberal then, or how would that work? + +**Anthony Towns**: Yeah, exactly. So, a Knots peer gets a template from a Libre +Relay peer with very different relay policies, and the Libre Relay peer might +have a template that includes a bunch of transactions Knots already rejected. +So, the Knots node might look through those transactions and see if it can now +accept any of them into its mempool, but all these ones it rejected before it +won't accept. So, it just keeps those around for, say, two to five minutes +until it requests the next new template from that node. So, the idea is that it +has a separate data structure from the mempool that keeps each of these +templates, but also kind of de-dupes the transactions that are already in the +mempool, so it's not wasting too much space, and de-dupes the transactions that +are in other peers' templates as well. + +**Gloria Zhao**: So, when you're constructing the template that you're going to +send to your peers, do you ever use the transactions from your peers' templates +or just what's in your mempool? I guess it'd be difficult to take other +people's templates. + +**Anthony Towns**: So, the idea is you get the template from another person, you +treat that as if they'd relayed the transactions to you, try adding them to your +mempool. If they go into your mempool, you relay them on to other people in the +normal transaction relay manner. But the ones that don't make it into your +mempool, you just keep those in reserve in case they're going to come in the +next block anyway. + +**Mike Schmidt**: Isn't that what the extra pool is somewhat, or obviously +proposing something bigger than that, and then communication of block templates +is different, but it makes me think of that data structure? + +**Anthony Towns**: There's a, there's a thing called vExtra transactions, which +is also used to improve complex block reconstruction. I think it's 100, or I'm +not sure how many transactions go into it; I think it's 100, but it is just +everything from the mempool. So, if something gets RBFd, then that'll get stuck +into it, even if it's a low feerate transaction that's not likely to get into a +block. So, it's good for basically a handful of recent transactions that might +make it into blocks, but it's not spectacularly reliable. And yeah, in the way +the code's written, it uses the exact same mechanism that that does to access +the transactions from these templates when doing the compact block +reconstruction. + +**Gloria Zhao**: How do you store the templates? Because I imagine we could +repurpose the new orphanage structure to do this so that you could de-duplicate +across peers, you could rate-limit and make sure that like you are keeping -- +how do you rate-limit this? + +**Anthony Towns**: So, it's rate-limited because a peer requests a template +rather than the templates getting sent. So, my current settings are, I generate +a template every 30 seconds so that it's relatively recent, but I only request a +template from a peer every two minutes. + +**Gloria Zhao**: So, if you get ten requests from different peers, you'd serve +the cached one in any 30-second period? + +**Anthony Towns**: Yes + +**Gloria Zhao**: I see. + +**Anthony Towns**: With a little bit of adjustment for, we have a whole thing +where we don't immediately announce transactions that make it into our mempool +to peers. And so, I've got the same delay essentially for sending a template +that might include the same transactions to peers who haven't heard it via inv +yet. But other than that little note, yeah, every 30 seconds they get the most +recent one if they want to request it. + +**Gloria Zhao**: Did you consider using minisketch instead of compact blocks? +Because if you're both interested in each other's templates, especially if it's +going to be a similar template, it might be worth the bandwidth savings. + +**Anthony Towns**: I spent five seconds thinking about it, but this was inspired +by Greg Sanders' weak block relay thing, where his idea was that when miners get +a high work share that's not quite enough for an actual block, they relay that +as well, and we use that as a cache of what transactions might be mined soon. +And that was via compact blocks, because it's a block. So, I have not thought +what that would look like in minisketch or what the CPU or bandwidth for it is. +The challenges, or possible drawback, is that you're not necessarily expecting +your templates to align. They might, in which case it's great, but they might +not. And then, maybe you're wasting bandwidth or CPU continually deciding, "All +right, these transactions are missing, these ones aren't", but maybe you're +reconciling it to their last template that you had rather than your template, +and that would be okay. I don't know, interesting. Do you know what the size +of the reconciliation is? I guess it's configurable, isn't it? + +**Gloria Zhao**: Yeah. When you request a sketch, you specify the capacity. +So, you could give them your inv send size or you could give them your block +template size, like the number of transactions in your block template, for +example. Or it's like an upper bound on what you think the difference is going +to look like. + +**Anthony Towns**: I'm not sure how you start that off as cleanly as with +compact blocks. Like, if you connect to a new peer and you don't know what +template to expect, with compact blocks it's just the fixed 20 kB or so message +to get the short IDs of all the transactions. Yeah, I don't know, that's +probably worth exploring. + +**Gloria Zhao**: Can this slow down reconstruction? Because I think the way we +do reconstruction is we'll calculate the short IDs of all the transactions that +might be in the compact block, and then we see which matches. So, if we have a +lot more transactions that we might potentially be looking at, can this slow +that down at all? + +**Anthony Towns**: Yeah. So, we iterate through the entire mempool to check, +calculating the short IDs of everything in the mempool and matching. And having +done that, we then do the same thing through the extra transactions, which would +be where these templates fit in. And compared to the size of the mempool, I +think a full mempool is more of a hit on number of transactions you're +calculating things for. And the other thing is that you're only ever doing the +calculation over the wtxid, not the full transaction, so that makes things a +little bit quicker than it might otherwise seem. + +**Gloria Zhao**: Would we request just from our outbounds, I guess? + +**Anthony Towns**: That's all I do at the moment, because if every outbound is +attacking you and giving you 4 MB templates of garbage, then that's 24 MB, 32 MB +of extra memory that you're sitting on. But if you were doing that for every +inbound as well, that's like 400 MB of data potentially. And so, I've had some +thoughts about just keeping the top of the templates for those and having some +sort of memory bound for it, so that if everyone's giving the same template, +then you can keep all of it because you're de-duping and kind of aggregating the +cost across all the peers that are giving you the template. And if someone's +giving you a completely different prediction, then maybe you keep the top 30 kB +of it, or something, rather than the top MB of it. But that got too complicated +to implement for a prototype. So, it's just outbounds for now. + +**Gloria Zhao**: Makes sense. + +**Mike Schmidt**: You mentioned Greg's discussion recently on weak blocks. Can +you explain why I would want to get an indication from just a random peer of +what they would build, as opposed to somebody who's putting proof of work behind +it and might actually come up with a block, what they see as a candidate block? + +**Anthony Towns**: Oh, so the drawback for me for weak blocks is twofold. One +is that the obviously weak blocks, you're going to get more weak blocks if you +have more hash power. So, that's going to be biased to the pools that have the +most hash power. And that means that if a small pool is doing some weird +transaction stuff, then their blocks are going to be slower because they're not +likely to get a weak block with the transactions that they're going to include. +And I want an approach that's effective for low-hashrate pools or low-hashrate +miners, rather than just advantaging high-hashrate miners. And this isn't +perfect for that because it's advantaging the policies that are most popular on +the network. So, if you have a moderate hashrate and are getting blocks, but +barely anyone on the network is sharing your node policy, then maybe no one's +getting to see your templates or similar templates to what you're producing. +And this isn't helping there, but this is the best I've come up with so far for +that. + +The other disadvantage with weak blocks is that they just keep coming through in +time. So, if you've got ten minutes between actual blocks, and you have ten +weak blocks, like your target is ten weak blocks per block, then odds-on you'll +get a weak block nine minutes before the block and eight minutes before the +block and seven minutes before the block, except much more randomly than that. +And that weak block that's nine minutes old isn't really, is probably not doing +that much good for your prediction of what's going to come right now. And also, +weak blocks are likely to cluster and have long lags between them the same way +that regular blocks do, which I mean is better than nothing but doesn't seem +ideal either. And if you're not doing proof of work, then you can just get them +on a timed basis, which as long as you have some way of not getting a billion +blocks from everyone on the network, which is why it's only doing for peers and +you're not relaying these on further, then having something that is close to now +that miners are likely to actually be working on seems better. + +**Mike Schmidt**: That makes a lot of sense. Thanks, AJ. + +**Anthony Towns**: Okay. So, the other two things for it is that it also makes +it easier to populate your mempool when you just bring up a node, either because +you've been doing IBD or because your node was down for a couple of days. So, +currently if you do that, you'll see new transactions that come in, but you +won't see transactions that have been sitting in the mempool for an hour. +Whereas with this, you'll get those sent through on your template, you can add +them to your mempool and you're up and running straight away. So, I think +that's a kind of fun win, which both gets you compact block stuff working as +well. But as well as that, if you're running a mining pool or a DATUM or a +Stratum v2 node, it means you can start generating proper templates yourself +that are realistic and not missing transactions and have a competitive feerate +straightaway. And I've forgotten whatever the other thing was. + +**Mike Schmidt**: Gloria, any other questions for AJ? + +**Gloria Zhao**: Not really. I think I'll look at the implementation, it's +cool. + +**Anthony Towns**: Yeah, so I've got a more limited implementation, which just +generates and serves templates, rather than requesting and making use of them, +which I think would be interesting to possibly get in the next release that's +coming up way too soon, because that would allow a bit more experimentation on +policies for getting templates. So, I've got a write up of that, which I'll +post pretty soon. + +**Gloria Zhao**: Well, by next release, you mean 31 or 30? + +**Anthony Towns**: 30, yeah. + +**Gloria Zhao**: I have seven days! + +**Anthony Towns**: Yeah. I've got a BIP write-up now and a PR, which I'll get +out. + +**Mike Schmidt**: Oh, wow, breaking news! If somebody who's listening wants to +see your proof of concept or maybe just run it and get some logs and data, play +around with it, where should they go to find that? + +**Anthony Towns**: So, you look at the Optech Newsletter, there should be a link +to the Delving post, which has got links to the prototype code that's currently +there. You'll need to run two nodes to get any use of that, because you need +one that provides a template and one that requests a template to see what's +going on. Because there's not anything on the network doing this, your node +that provides the template will need to be running a little while to actually +have a mempool that's got transactions in it to go into the template. But +otherwise, yeah, that works straightaway. + +**Mike Schmidt**: Cool. All right, AJ, thanks for joining us. We appreciate +your time. + +**Anthony Towns**: You're welcome. + +_Add exportwatchonlywallet RPC to export a watchonly version of a wallet_ + +**Mike Schmidt**: Moving on to our monthly segment on a Bitcoin Core PR Review +Club. This month, we highlighted the, "Add exportwatchonlywallet RPC", which is +an RPC that exports a watch-only version of a wallet file with descriptors. +Gloria, I don't think you hosted this particular Review Club, but I know you +were involved. Maybe you want to help elaborate on this. At first, I thought +it seemed like a fairly straightforward from the explanation PR, but there's +actually quite a lot going on here in the Review Club. + +**Gloria Zhao**: Yeah, it turns out that a wallet's a lot more than a bag of +keys or a bag of descriptors. I think maybe there was a version of this that +existed for legacy wallets, like non-descriptor wallets in the past, but +definitely not anymore. The use case is you want to export your watch-only +wallet or you want to export your wallet in a watch-only format so that you +would be able to see all your transactions and calculate your balance and look +at your addresses, and things like that, somewhere else that doesn't have your +keys. But the wallet file includes a lot more than just those addresses and +descriptors. You have address labels, you have certain settings on the wallet +that can actually impact what the calculation of your available balance is, such +as avoid reuse. So, even though you're not going to be constructing or signing +transactions on this watch-only wallet that you import, if you have an output +marked as avoid reuse, for example, because you already spent from that address +and you don't want to spend from it again to reveal links between your coins, +then that is deducted from your available balance. So, there's different +balances that will show when you ask your wallet, "How much money do I have?" +But it will show up in some of them, but not others. + +So, as an example, avoid reuse is an example of a wallet setting that you do +want to export along with all the other information, in order to have the exact +same wallet if you are to import this or restore this wallet file elsewhere. +So, yeah, that's I guess an example of kind of the edge cases and more +complicated details for capturing everything in this exportwatchonlywallet RPC. + +**Mike Schmidt**: How would you do it before? Would you get a full export and +have to kind of parse through there to figure out what to take out to send to +watch only, and then that's obviously error-prone if you include additional +information in there? + +**Gloria Zhao**: Yeah, yeah, good question. I think you could export all the +descriptors. But if you wanted all this metadata, like the labels and the flags +and stuff, you would have to manually do that. I want to say there was a way to +get all those settings, so maybe you could write a script for it, but that's +definitely not as good as just calling a couple of RPCs. + +**Mike Schmidt**: Excellent. + +**Gloria Zhao**: Yeah, I don't know all the details because I didn't host this +one. + +**Mike Schmidt**: Well, I am checking now. It looks like the PR is still open. +So, if folks are curious about wallet stuff, we didn't touch on it, but there's +a series of questions that we have in the newsletter write-up that get quite +technical, in addition to the PR Review Club normally very robust write-up as +well. So, if wallet is something that you're interested in and approachable to +you, you should jump in and dig into the details there. + +**Gloria Zhao**: Yeah, it will help you appreciate how complicated it is. + +_Optech recommends_ + +**Mike Schmidt**: We actually had a segment that we haven't had in a while, a +short segment called Optech recommends, in the newsletter this week. This was a +call out to the Bitcoin++ Insider publication. They've been publishing a few +different series on their Substack recently, including a segment called, "Last +Week in Bitcoin" and another segment called, "This Week in Bitcoin Core" that we +mentioned in the newsletter this week, which may be of interest to Optech +readers and Optech Recap enjoyers. They also have a technical take series and +recent things there include SPHINCS+, which is some of the quantum-resistant +signature stuff, Cashu, F2Pool and Marathon mining taproot annexes, to give you +a flavor of that series. And then, there's also a Scaling Bitcoin series that +had recent publications on BitVM-based bridges, private Bitcoin payments, and +statechains. So, if that kind of stuff is interesting to you, check out +Bitcoin++ Insider. + +_LND v0.19.3-beta.rc1_ + +Releases and release candidates. We have three this week. LND 0.19.3-beta.rc1, +this contains a handful of bug fixes. One is around gossip, which we actually +get to in the Notable code segment. That's actually the related fix, so I'll +save that one. And there's some other fixes. There's changes in the gossip +message rates, also related to what we've talked about previously and we'll talk +about later for LND PR in the Notable code segment; and then, there's some +changes around sweeping anchors to prevent pinning. So, this is just a release +candidate. So, please check it out, test it out, provide feedback to that team. + +_BTCPay Server 2.2.0_ + +BTCPay Server 2.2.0 adds support for wallet policies and miniscript, and also +adds feerate and fee information in a bunch of new areas of the user interface +for BTCPay Server. Obviously, the normal features and improvements as well as +bug fixes are in there as well, but those are the ones that I thought were most +applicable to Optech readers. + +_Bitcoin Core 29.1rc1_ + +And we have Bitcoin Core 29.1rc1. I think it was last week Murch and I pulled +out a few things that we thought were interesting but, Gloria, as a maintainer, +are there particular things that you'd like to highlight for the audience that +will be in there and that they should be aware of? + +**Gloria Zhao**: Fairly normal, I think. There's some fixes for 32-bit systems +and some CMake build things that got fixed, since this was the first release +that was built with CMake. I guess the biggest thing is the, what's it called, +BIP54, is it? The very large legacy sigop transactions are non-standard, and +that's part of the consensus cleanup. So, if you imagine that consensus soft +fork activating like two years from now, or something, and you hadn't updated to +32, or whatever it is. And so, these transactions with more than 2,500 legacy +sigops are now consensus-invalid. This 29.1 will at least not be accepting them +into mempool. So, if I guess a miner is running 29.1, when that soft fork +activates, they're not going to be publishing blocks with invalid transactions. +And if you're non-mining, you're not going to be accepting these transactions +that are newly consensus-invalid. And so, that's a 'forward compatible in case +of soft fork' change that is more significant in the 29.1 list? + +**Mike Schmidt**: Yeah, I think that was Bitcoin Core #32521, and you'll have to +just search that on Google with site:bitcoinops.org. But we did talk about that +in the newsletter and the podcast as well as the dbcache values for 32-bit +operating systems and why it's a good idea to cap some of those things. + +**Gloria Zhao**: Yeah, and 2,500 legacy sigops is pretty rare. I think Antoine +had an analyst post that listed all of them, and there's maybe a dozen or so in +the last 15 years. + +**Mike Schmidt**: I think the word I've seen is 'pathological', you have to be +wanting to mess around with this. + +**Gloria Zhao**: Yeah. It's it's probably not going to be a meaningful change +in practice, but it's there for a good reason. + +_Bitcoin Core #32941_ + +**Mike Schmidt**: Notable code and documentation changes. Bitcoin Core #32941, +"Orphanage revamp cleanups". Gloria, this is your PR. What's the latest in the +fortification of the orphanage? + +**Gloria Zhao**: Well, this is the last PR in that project, at least for a +while. It's mostly follow-ups to the last one, which we talked about maybe two +or three Optech Recaps ago, newsletters ago. Yeah, mostly little fix-ups. One +of them was to have the orphanage automatically trim itself so that you could +have a check that it's never oversized, and that just makes all the tests a bit +stronger. But it's not a behavior change in practice. We were trimming it, +it's just that the caller was trimming it instead of just adding things to it. +So, yeah, orphanage is in better shape than it was before. I think I still +remember AJ moving it to its own module, like five years ago? I feel like +orphanage has changed so much. I think it was in the original Satoshi client as +this map that had everything in it, no size limit, that kind of thing. And now +it's quite a bit more robust. + +So, now we're pretty much done with most of the P2P stuff for package relay, and +we still need to accept the package validation stuff to have arbitrary packages +and to handle package RBF, and a lot of that's dependent on cluster mempool. +And then afterwards, it's pretty much just adding support for the package relay +messages, because now we see an orphan, we can put it in orphanage and request +the package information, and have some confidence that it's not going to fall +out of the orphanage as soon as we get the list of transactions we need to +download. And we have all of the efforts to make sure we try to resolve these +orphans. So, we ask all of the peers that we can ask for the package from. So, +I think we've covered almost all of the more difficult pieces of the P2P logic +for package relay, and we just need to stitch it all together, after we figure +out package RBF, of course, which is a very easy problem. + +_Bitcoin Core #31385_ + +**Mike Schmidt**: Well, speaking of packages, the next PR this week, Bitcoin +Core #31385, relaxes some of the validation rules around packages of +transactions. Gloria, this is also your PR. Maybe, can you remind us of the +current rules around packages and why we might want to change those at all? + +**Gloria Zhao**: Sure. So, the current requirement for the submitpackage RPC, +current as in, in all of the releases that are out, package has to be filed with +unconfirmed parents. So, it has to be child-plus-parents shaped. There can't +be any transactions that aren't a parent of the last transaction. They can be +parents of each other as long as they're also direct parents of the last +transaction. And the part that's removed in this PR is that all of the +unconfirmed parents have to be present, which is in hindsight a silly rule. But +basically, now, if you have a package where some of the parents are already in +the mempool, it won't get rejected if you leave those out, which makes perfect +sense. So, now you can actually, in the P2P code, which is they just have to be +1p1c, if you have a 1p1c that attaches to other things, you can broadcast that. +So, it does make a difference, but it's just removing a thing that was in the +way before. It didn't really do much. + +**Mike Schmidt**: As we're going through these Bitcoin Core PRs, maybe it's a +good time to remind listeners of the release schedule and whether these PRs are +in the next version or is that time passed; maybe just some people know if +they're going to get this soon maybe or not. + +**Gloria Zhao**: These will be in the next version, unless we revert them for +whatever reason. All the features that are merged from now until next week will +make it in. I think we do branch off like a month from now and then it'll come +out in October-ish. + +_Bitcoin Core #31244_ + +**Mike Schmidt**: Great. Bitcoin Core #31244. This is a PR that implements the +parsing of BIP390 MuSig descriptors. It's actually part of Bitcoin Core's +MuSig2 efforts that has the tracking issue -- I love tracking issues -- #31246. +So, if you're curious about the broader MuSig2 efforts in Bitcoin Core, check +out #31246. And this PR is actually split off from a bigger PR titled, "Be able +to receive and spend inputs involving MuSig2 aggregate keys". Gloria, did you +have more on this one? + +**Gloria Zhao**: Sure. Yeah, I think we can now receive but not send MuSig. +So, if you generated a MuSig address with some friends and you had this +aggregated public key and you guys received money to it, you would now be able +to import that as a descriptor and see that you've received money, but you +wouldn't be able to spend it yet. So, the aggregate key looks exactly like any +other single-sig taproot key, and the signature also looks just like any +single-sig schnorr signature, and you can import it into your wallet, but you +won't be able to spend it. You don't have the ability to create the signatures +to aggregate, or I think you also don't have the ability to generate the nonces +and stuff to create the partial, yeah. + +**Anthony Towns**: This was just the parsing, not the sending or the receiving, +I thought. I thought those were in the PR that it was split off from. + +**Gloria Zhao**: So, when you import it, does the wallet not rescan to see what +has been received? + +**Anthony Towns**: I got the impression this was just the parsing, not even the +importing. I might be wrong. + +**Gloria Zhao**: It might be, I don't know. + +**Mike Schmidt**: It's titled, "Parsing", and it's split off from the +send/receive. So, maybe it's just strictly the parsing piece. If only there +was a tracking issue! + +**Gloria Zhao**: When I messaged achow, she said we can receive but not send. +So, that's going to throw her under the bus! + +**Mike Schmidt**: All right. + +**Gloria Zhao**: Maybe it's somewhat nuanced, like you can see that you received +stuff, but I don't know where you draw the line. + +**Anthony Towns**: If you can add it to the wallet, then you can track it. + +**Gloria Zhao**: I imagine if you can parse, then you can import, right, the +descriptor? I said, "So, we could import a descriptor for our MuSig and see +that we received BTC to it?" And she said, "Yes". + +_Bitcoin Core #30635_ + +**Mike Schmidt**: Okay, that's pretty authoritative. Bitcoin Core #30635. This +unhides three RPCs, waitfornewblock, waitforblock, waitforblockheight. What do +these do and why were they hidden before? + +**Gloria Zhao**: Things are usually hidden because we don't expect anyone to be +interested in them, but we made them so that we can write tests. It's pretty +useful to be able to wait for the next block to come in, right? You write a +test that's like, "Oh, you broadcast these, you have this miner do this", and +then you assert that the node does this, but only after receiving the block and +processing it. So, it's pretty useful for testing. But I imagine in the real +world, you have a lot of other options for encoding something that is triggered +by a new block. But yeah, I can't really speak to what people were thinking. +But yeah, I guess now they are unhidden. I mean, you were always able to use +them, it's just that they weren't advertised to the users. + +**Mike Schmidt**: Yeah, it's not listed in the help. So, that's the definition, +I guess, of hidden. And it sounds like, I mean, yeah, it's just for testing, +right? I don't know of any use cases that come to mind for waiting. + +**Gloria Zhao**: Maybe if you're a miner and want to wait for your own block? + +**Anthony Towns**: Well, if you get a new block in, you want to immediately get +a new template to work on probably. And so, this would give you that indication +that a new block's come in without having to call for it. I think you can use +ZMQ for it. + +**Mike Schmidt**: Yeah, that's what I was thinking. + +**Gloria Zhao**: Right, so you're almost getting a notification instead of +pulling. Yeah, that's pretty good. And then, there's the adding the argument +for the tip. So, I guess, I don't know if this is useful in real life, unless +you're expecting multiple blocks at a time. But in tests, for example, I +think... + +**Anthony Towns**: I think if you do the request immediately after a block's +come in because you're just unlucky, then you won't see the notification that +the block has just come in. + +**Gloria Zhao**: Right, okay. So, if you parse in a current tip and it's like, +"Oh, I already know about that. Here you go", you would just… + +**Anthony Towns**: You'd Immediately get a response to say, "No, that's not the +current tip". + +**Gloria Zhao**: Makes sense. Cool. + +_Bitcoin Core #28944_ + +**Mike Schmidt**: Bitcoin Core #28944, adding anti-fee sniping to send and +sendall RPCs. Gloria, I've got two questions here. One, what is this anti-fee +sniping? And second, I thought Bitcoin Core had anti-fee sniping for like a +decade? + +**Gloria Zhao**: Yeah, well fee sniping I think is mostly a very +far-into-the-future concern, where fees are such a large part of the block +reward that hopefully you might run into a situation where the miner is deciding +what they should mine and they see that there's not a lot of transactions, ie +transaction fees available to gain as a result of building on top of the current +tip. But if they reorg and remine some of the past transactions, then that +multiplied by the risk or probability of them not actually having the rest of +the network build on this block that they built as a reorg, they somehow +calculate that it would be worth it for them to actually not extend the current +tip, but to try to remine a previous one. So, that's very scary, and there are +a few mitigations. I think the Optech Topics page has an excellent summary of +the problem and the proposed solutions. And something that Bitcoin Core has had +for a long time is anti-fee sniping and wallet/RPC stuff, where you just set the +locktime of the transaction so that it only becomes consensus-valid at this +block height. So, if you were to reorg back, it would not be valid anymore. + +**Mike Schmidt**: So, the juicy transaction fees are safe from reorging miners, +especially in a future state where there's higher incentive to do that, because +the subsidy's out? + +**Gloria Zhao**: Correct, yeah. I think this has existed for a while, but maybe +just not for these two particular RPCs, send and sendall. + +_Eclair #3133_ + +**Mike Schmidt**: Okay. My memory didn't fail me. This has existed, just not +for those RPCs, okay. Eclair #3133 adds to Eclair's support of peer reputation +by adding reputation for outgoing peers. A couple of weeks ago, we covered a +similar PR from Eclair that added reputation-tracking-related metrics for +incoming peers. The idea here is to use reputation of a node's neighbors to +decide if an HTLC (Hash Time Locked Contract) should be relayed or not, and it's +part of a broader set of mitigations against channel-jamming attacks, where +attackers can attempt to either take up all the HTLC slots or all of a channel's +liquidity. It's basically a type of DoS attack. So, we've gone through a lot +of research with folks on anti-channel jamming ideas. This peer reputation is +one of them, and Eclair has implemented both ends of that now. And as of this +PR, Eclair now considers reputation in both directions when forwarding an HTLC. +But at this point, and I think this is planned in the future potentially, +there's no penalties implemented yet. It's just merely collecting data at this +point. + +_LND #10097_ + +LND #10097, a short tangent here. Matt Morehouse joined us in Podcast #364, +where we discussed a DoS vulnerability that he had found in LND. And that DoS +vulnerability was specifically around LND's handling of gossip. So, recently, +over some period of time after that migration, there's been continued rework of +LND's gossip-handling architecture. And it appears that this PR is part of that +ongoing re-architecting work, not specifically for that bug, but as a result of +re-architecting the gossip, there's been other challenges that have come up and +this PR attempts to address some of that. + +It adds an asynchronous processing queue for these range filters for gossip, +which were the problem in that bug we discussed a couple of weeks ago with Matt. +It can prevent blocking issues and also improve performance, especially under +heavier load. And then also, when the queue is full now, they drop messages, +whereas before they would just try to execute that whole thing, which was the +DoS vulnerability. This PR also provides an option to limit how many of these +gossip filter request operations can be running simultaneously. So, another DoS +mitigation and a lever that you can play with. And one thing that I saw in the +PR and in the files was actually this gossip rate-limiting markdown file that +details all of LND's gossip-handling approach, the different options that node +operators can use to modify those gossiping behaviors. Quite a robust document +that's included as part of this PR. + +_LND #9625_ + +LND #9625 adds an RPC to delete an invoice that had previously been canceled +from LND's database. The main use case here would seem to be just cleaning up +the database of unneeded entries. And this was possible to delete these +canceled invoices previously, but it was less straightforward than this new RPC, +required more work, and may have not fit in the existing workflows for LND's +users and developers very well. + +_Rust Bitcoin #4730_ + +Rust Bitcoin #4730 adds the Alert Bitcoin P2P message. Gloria, blast from the +past, the P2P alert message type has been deprecated for some time. Maybe for +listeners, in the early years of Bitcoin Core, or maybe just Bitcoin development +at that time, Satoshi for example had the keys to be able to send alert messages +to nodes, maybe a notice of a critical bug or a security incident or urgent +software updates, etc. But in 2016, I believe it was, Bitcoin Core developers +decided, "Hey, that's a bad idea. You shouldn't have a decentralized system +that has privileged users able to send alert messages on the Bitcoin Network", +so it was removed. But in the interest of thoroughness, Rust Bitcoin has +implemented this Alert P2P message in this PR in the form of sending the final +alert message that was sent from that key, which is, "Urgent alert key +compromised, upgrade required", I believe. Yeah, I hope I got all that right. +But that was like a little bit of Bitcoin lore there. + +**Gloria Zhao**: Yeah, wait, so we still have that, right? We still send the +final alert just in case there's really old nodes and we need to tell them that +the alert queue is compromised. Like, I think this is still in Core and we +can't remove it. + +**Anthony Towns**: It's still there as long as the version of the node we +connect to is old enough that it hasn't dropped support for it. + +**Gloria Zhao**: Right. And we wouldn't ever remove it from the codebase just +in case, right? + +**Anthony Towns**: I mean, it's one, two, three, four lines of code, or five +lines if you count the comment. + +**Gloria Zhao**: Yeah. + +**Mike Schmidt**: So, deprecated in terms of new uses, but retains that final +message, which is what Rust Bitcoin has done here as well. + +**Anthony Towns**: Yeah, they have a lot more lines of code for it. + +_BLIPs #55_ + +**Mike Schmidt**: Well, they're apparently thorough. Last PR this week, BLIPs +#55, adds BLIP55, which is also known as LSPS5, Lightning Service Provider +Specification 5. This is the specification that we spoke about last week when +LDK implemented BLIP55. But as a reminder, it's a way for an LSP server to set +up to be able to send push notifications to a client device, usually a mobile +device, when something happens, for example receiving a payment, and there's a +mobile LN wallet that isn't always online. You can sort of register a webhook, +and the LSP will send a message to that webhook which, in the case of a mobile +device, might do a push alert and let somebody know that they got a payment, +that the LSP's changed the liquidity, or an onion message, or some other such +message as well. So, LSPS5/BLIPs #55 is the specification for that sort of +webhook. + +_Correction_ + +And we have a correction in addition to an Optech recommends, we also have a +rare correction as well. We noted that in last week's newsletter, when we were +talking about BIP360, which is the pay to quantum-resistant hash, we were +referencing that as making the change that Tim Ruffing had outlined in his +recent paper. But there is a difference there. I think Tim Ruffing was +outlining that it could just disable keypath spends in existing taproot +addresses, whereas BIP360 actually has a new taproot-based output type that also +removes keypath, but it would be actually a different type of address. And +that's what this correction gets into. AJ, you may have more to piggyback on +that. AJ doesn't. Okay, good, that means I didn't say anything too wrong. +Gloria, anything that you want to add to that? All right. + +Well, AJ, thanks for joining, Tadge had to drop off. AJ, appreciate you hanging +on at God knows what time. Gloria, thank you for jumping on and co-hosting. + +**Gloria Zhao**: My pleasure. Hope I was a satisfactory stand-in for Murch. + +**Mike Schmidt**: It was great. I mean, we love Murch, but couldn't have asked +for a better week for Murch to take off since you participated in every segment +of the newsletter! We appreciate it. And thank you all for listening. Cheers. + +**Gloria Zhao**: Thank you. + +**Anthony Towns**: Thanks, Mike. {% include references.md %} From b4525ffc0e418eed13fe1cec9583e8ad0309d444 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Fri, 22 Aug 2025 09:23:12 -0500 Subject: [PATCH 220/278] Podcast: add 367 recap --- .../en/podcast/2025-08-19-newsletter-recap.md | 310 +++++++++++++++++- 1 file changed, 309 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-08-19-newsletter-recap.md b/_posts/en/podcast/2025-08-19-newsletter-recap.md index 49aeec9655..c5d221d527 100644 --- a/_posts/en/podcast/2025-08-19-newsletter-recap.md +++ b/_posts/en/podcast/2025-08-19-newsletter-recap.md @@ -18,6 +18,314 @@ Mark “Murch” Erhardt and Mike Schmidt discuss [Newsletter #367]({{page.refer ## Transcription -_transcription coming soon_ +**Mike Schmidt**: Welcome everyone to Optech Newsletter #367 Recap. Today, +we're going to cover two release candidates and four PRs. We have no guests +this week, so it's just going to be Murch and I, and there's also no news this +week. So, we're going to go right into the Releases and release candidates +segment. + +_LND v0.19.3-beta.rc1_ + +LND 0.19.3-beta.rc1, which is an RC for LND that we covered last week. And +actually, last week, when we covered some of the contents of this RC, there were +actually some gossip-related changes related to the RC that we also covered in +the Notable code segment. So, if you're curious about that, refer back to #366 +Podcast. + +_Bitcoin Core 29.1rc1_ + +Bitcoin Core 29.1rc1 is an RC that we covered last week and the week before. +Last week, it was Gloria and I talking about it, and two weeks ago, Murch and I +covered it as well. So, I would refer back to that those materials. Murch, +anything to add on that release? + +**Mark Erhardt**: No, not really. + +**Mike Schmidt**: Okay. + +**Mark Erhardt**: I think we already covered that this one makes the +pathological legacy transactions with a large count of sigops non-standard. I +think that's still the biggest and most interesting. + +**Mike Schmidt**: Yeah, I think that's the big one. So, I guess if you're doing +the extremely pathological things, check out this RC to make sure that it +breaks. + +**Mark Erhardt**: I think there's been only a dozen or a couple of dozen +transactions in the whole history of Bitcoin that were above this, and they are +very deliberately doing weird stuff. + +**Mike Schmidt**: And they were all Core developers messing around! + +**Mark Erhardt**: Maybe, I don't know. The other one that I saw was that that +maxmempool and dbcache are being capped on, was it 32-bit systems, or whatever, +which I guess shouldn't really affect people much anymore. + +**Mike Schmidt**: And if you look at what's in that RC, you can reference some +of the PRs, and I think we've covered many of them in previous shows. I didn't +list them all out here, but we did cover that dbcache default, and we covered +the pathological transactions PR as well. So, if you want to dig into some of +that a little bit deeper, maybe cross-reference the Optech Newsletter with the +PRs that are in this RC. + +_Bitcoin Core #33050_ + +Notable code and documentation changes. Bitcoin Core #33050 titled, "Don't +punish peers for consensus-invalid txs". Maybe some background here and, Murch, +you can chime in if you have something to add. But so, if you're running a node +and your node's peer misbehaves, for example sending invalid blocks or headers +or a variety of other misbehaving type things, Bitcoin Core will discourage that +node; discouraging meaning disconnecting from that node and not connecting at +least outbound to that node for, I believe, 24 hours. Although I think it will +accept an inbound. So, you're essentially slapping that node on the wrist for +misbehaving, at least in terms of your node's operation. This discouragement or +punishment can apply for standardness rule violations as well as consensus +violations. So, this PR is no longer going to punish peers for relaying +consensus-invalid transactions to the node. + +So, there's two big parts of this PR. The first part, and there's three commits +but two of them have the meat of the changes, one is a test-related one. The +first is eliminating the punishment or discouragement for consensus-invalid. +And the rationale there is that what an attacker could do, so in an +adversarial-minded scenario, they could make a non-standard and +consensus-invalid transaction. And due to the way that the discouragement is +processed, it would hit the non-standard check first and thus you'd be able to +bypass the consensus check. And so, because that's possible, the consensus +check is kind of not doing what was originally intended, and so that's why AJ +has proposed to remove it. + +I have those quotes up now that I wanted to bring up earlier. AJ says, "Do not +discourage nodes, even when they send us consensus-invalid transactions, because +we do not discourage nodes for transactions we consider non-standard. We don't +get any DoS protection from this check in adversarial scenarios, so remove the +check entirely to simplify the code and reduce the risk of splitting the network +due to changes in transaction relay policy". And sipa actually chimed in with a +comment, I'm taking these a bit out of order just because I think they logically +make sense, but sipa chimes in saying, "I agree that the current ability to +distinguish consensus versus standardness failures doesn't really achieve much. +It is not the case that consensus invalidity is inherently harmful to us in +terms of DoS potential more than non-standardness violations, and attackers +today can already mask any consensus invalidity by causing a non-standardness to +be detected first, evading the punishment". So, that was sort of back to what I +was trying to articulate earlier. Murch, I said something earlier that I think +is now incorrect after having reread this and spit it out. There is no +discouragement when standardness rules are violated? + +**Mark Erhardt**: So, the behavior in that regard changed a few times in the +past years. It used to be that we would have a score for each peer, how much +they have misbehaved, and then only ban or discourage them after they accumulate +a certain amount of score. So, basically we would allow them to do stuff that +we don't like several times, depending on what they did, and that was recently +changed to either immediately lead to a ban or disconnect, or by leading to no +discouragement at all. Okay, so this discouragement meant that if we got a new +peer request to connect, we would disconnect the peer that we wanted to +discourage first. They were not getting banned or disconnected immediately, +they would just be the first to be disconnected next time we disconnect someone. +And I think that we might still sort of do that, but I don't remember 100%. I +do know that the whole ban score thing was discontinued. We just either +immediately disconnect or don't do anything. And yeah, with the regard to the +consensus and standardness checks, my understanding is now that we just get a +single pass of all the checks, so it'll be computationally a little faster. And +yeah, so it's basically a code improvement, dropping some unnecessary code, +making it a little faster, and it does not increase the dust surface, because we +still do the checks, but all together, I think. + +**Mike Schmidt**: Yeah, if you're parsing only once, then you're only doing one +set of checks versus two, and that was the second part of the PR, is removing +that second pass of checks, which has a performance benefit. I believe that +there is a PR that's tracking IBD (Initial Block Download) performance, and I +think it referenced this PR as one of the things that is improving IBD +performance. Sipa says one more thing that I think would be interesting to wrap +up with, "So, it seems the benefit of this distinction", and I think he's +referring to the standardness versus consensus distinction, "is largely so we +can kick peers with diverging consensus rules. That is worthwhile, but we have +other measures that take care of this already, disconnecting ones that give +invalid blocks and actively seeking out more connections when we don't learn +about a new block for a while". + +**Mark Erhardt**: Right, so you could send consensus-invalid transactions, for +example if you have not upgraded to a soft fork, some soft fork activated, +you're still on an old version and someone gives you a transaction that used to +be valid, but is no longer valid. If you forward that, then you would be +basically running a legitimate node, not attacking or anything, but still +sending a consensus-invalid transaction. And we might not want to disconnect +our peer just for running an outdated client, right? But if someone sends us an +invalid block, that is definitely a sign of something being wrong. So, either, +well I guess we could have the same issue with an upgraded node in a soft fork +scenario. Someone mined an invalid block according to the new rules and this +peer propagated it. So, if someone did that, we could probably split off a lot +of the outdated nodes that way, like there would be a rift between the outdated +nodes that accept the new block and the upgraded nodes that do not. But for +transactions, that's all a little less clear, because transaction data is a +little more lenient. You can do more stuff in it, they're not proof-of-work +covered. We also don't have propagation guarantees like we have for blocks. We +only do our best effort on forwarding transactions. So, anyway, making it +faster to go through transactions is worthwhile. + +**Mike Schmidt**: Murch mentioned some of the history around this behavior in +Bitcoin Core and actually, one of the follow-up comments AJ posted in the PR +referenced several of historical PRs and their interplay in this discouragement +and in this discussion, including some of the edge considerations around soft +fork timing and things like that. So, if you're curious, dig into that comment +by AJ and follow all those historical PRs to get up-to-date. + +_Bitcoin Core #32473_ + +Bitcoin Core #32473, introducing per-txin sighash (signature hash) midstate +cache. Murch? + +**Mark Erhardt**: So, when we validate transactions, we have to check that the +signatures actually commit to the correct transaction. And we do that by +crafting something we call a sighash, which is not confusing at all because it's +not a hash of a signature, but actually more of a commitment to the data in the +transaction. So, this sighash is basically, in the default case, composed of +the list of inputs, the list of outputs, the amounts, and some other data, but +not the signature data. And we calculate this separately for each input that is +being checked and signed, because every input has to commit to all the other +inputs and all the outputs. And if you, for example, had two inputs that spent +from the same output script, you wouldn't want the same signature to be valid +for both. You wouldn't want someone to be able to just take the signature of +the first input and pack it on the second input, right? That would be terrible. + +So, these sighashes are not just calculated per input, but actually they are +calculated when we run OP_CHECKSIG. So, if you, for example, had OP_CHECKSIG +multiple times in a script in a complex spending condition, this would be +calculated multiple times. And this is especially terrible if these scripts are +big already, because a lot of data needs to be hashed. Well, all of this is +really fast still unless we're talking about huge things. But for example, if +you're building a transaction deliberately that has a ton of OP_CHECKSIGs in the +script and the script itself is large, you get a compounding effect and it +really takes a while to validate that. What this PR does is it introduces a +cache for the mostly calculated sighash before the parts that are specific to +the current signature are added. So, this stays the same for all of the +transactions signatures in the same input. So, if you have multiple signatures +in one input, we can reuse this calculation, most of it, and just pull it from +the cache instead. + +So, this PR is only for legacy transactions, as in everything before taproot +actually. And so, yeah, we cache most of the sighash calculation per input. +So, if we have the same input and the same sighash type, because if you have +different sighash types, this cache will not work because, for example, +ANYONECANPAY, or something, would be a different commitment than the default +commitment, right? The SIGHASH_SINGLE or SIGHASH_ALL commits to different +inputs. So, this cache would only apply for the same sighash type and only per +input. Oops, sorry, I talked too loudly, my microphone was oversteering! Yeah, +anyway I meandered a little bit. Did it become clear? + +**Mike Schmidt**: Yeah, yeah, I think that makes sense. Interestingly, these +last two PRs were both tagged with the validation label in GitHub. + +**Mark Erhardt**: Yeah, oh, I wanted to mention something. You were talking +about IP, IBD performance. IBD performance is going to look like it's going to +be really nicely improving in the next release. I saw some estimations that +with several IBD improvements coming, currently it's already over 20% faster. + +**Mike Schmidt**: I saw something about that too from l0rinc, yeah. + +**Mark Erhardt**: Yeah, exactly. + +**Mike Schmidt**: Yeah. That's great to see. Obviously, there's a lot of +discussion about Core developers and their 'what have you done late lately for +me as a node runner?' And if you look at 20%, that's obviously a big number for +a project that's been around for this many years. And if you then dig into, +like I saw that there was a gist or something, the tracking issue for the +performance improvements, and I think there was like a dozen there that were +being tracked. And you drill into the work that goes into each one of those, I +mean this is not tweaking a database setting to get that 20% improvement. So, +there's a lot of work that goes into it. + +**Mark Erhardt**: Yeah, there's been a lot of benchmarking and testing and a few +people have been really looking at flame graphs and performance analytics, where +exactly the time is spent. I think we talked to l0rinc recently that he found, +for example, that when you XOR the blocks so that they are obfuscated on the +disk, if you just pick larger chunks of the data, it becomes significantly +faster. And a few other, like the code changes. Some of these code changes are +just a couple of lines, but regardless of that, weeks of work went into testing, +looking at what exactly the performance improvements are, analyzing the code +segments, where the performance losses are, and then, yeah, the result might be +a two-line code change and a bunch of tests. But yeah, so there's been a ton of +work on IBD performance in the past few years, also by other people like Andrew +Toth, and a bunch of that is coming in the next release. + +_Bitcoin Core #33077_ + +**Mike Schmidt**: Bitcoin Core #33077, which is part of the Bitcoin kernel +project, which is the effort of Bitcoin Core to modularize consensus, including +critical components of Bitcoin Core, like block validation, transaction +validation, header rules, etc, into a separate library. The project has also +been referred to as libbitcoinkernel and includes an API that, I believe, the +API is currently a work in progress, but a way for you to interface with that +logic. So, this PR is part of that broader project, but the PR this week is +titled, "Kernel: create monolithic kernel static library". Prior to this PR, +the kernel library required a bunch of the libraries that kernel depends on to +also be available in the file system; whereas after this PR, all of kernel's +dependencies are embedded in the kernel library itself. I'll pause there, +Murch, because I was a little bit worried that I had this wrong, because if you +didn't get it, I didn't get it. Does that make sense so far? + +**Mark Erhardt**: No, I think that's right. That's how I understood it too. +So, basically, previously the way it was set up, if you wanted to use the +libbitcoinkernel library, you had to have a few other libraries built as well. +And from reading the PR, it sounded like those instructions were not necessarily +obvious to the library consumers. And now, the libbitcoinkernel library +directly incorporates its dependency, so it's more standalone. You only have to +reference that single dependency in order to use the libbitcoinkernel, rather +than the Bitcoin kernel and the Bitcoin kernel's dependencies separately. And I +think this is basically a quality-of-life improvement for people that want to +consume the libbitcoinkernel library downstream or in other projects. But happy +to be corrected if I misunderstood that. + +**Mike Schmidt**: Yeah, Murch, maybe you can help me get back in my developer +days. There's also the risk that you were referencing the correct library, but +the incorrect version of that library, which could potentially have unintended +behavior. So, for the example, kernel referencing secp, you might have secp, +but maybe it's a different version from what kernel expected. Is that also a +valid concern? + +**Mark Erhardt**: That seems very reasonable to me. Yeah, if the interface was +the same between the dependency and libbitcoinkernel, it would just work. But +if the code had changed under the hood, it might behave differently than +expected. So, compiling everything into this monolithic static library would +prevent version clashes like that, yeah. + +**Mike Schmidt**: Well, we did mention secp in that example I just outlined, but +one of the dependencies of kernel is secp, libsecp256k1, and in order to embed +secp in the kernel, secp needed to make changes to expose its own underlying +object files, basically like the executables or the binaries, you might think +about it. And we did cover that change and discuss that in Newsletter and +Podcast #360. That was libsecp256k1 #1678 PR, which explicitly stated, as the +motivation, being able to be used in kernel. So, here we are. + +**Mark Erhardt**: Yeah, I think this was part of the change to the CMake build +process, where in libsecp, we also needed it to be built with CMake in order to +work in these sort of build processes for Bitcoin Core in that way. + +_Core Lightning #8389_ + +**Mike Schmidt**: Core Lightning #8389. This is a PR that implements the +changes in BOLTs #1232, and that was a change to the BOLT spec which updates the +channel_type feature to be assumed as opposed to optional. The channel_type +feature is used to signal support for certain LN channel features. For example, +you could signal that this channel is going to be a zero-conf channel, or you +could also signal support for different channel commitment formats. And +basically, this channel_type feature has been around for three years, and +basically all the implementations support it. So, the change was made to the +spec to make this assumed, or I guess basically required. And Core Lightning +(CLN) in this PR made the change in their implementation to support that assumed +feature. + +**Mark Erhardt**: Right, so 'assumed' in this context means that you require +other LN nodes to set the channel type when opening a channel. And this +follows, of course, the spec change. And I think all of the implementations had +been doing it for a while. So, now they changed it to 'required' and will not +open a channel with you if you don't send the channel_type. + +**Mike Schmidt**: Short one this week, Murch. + +**Mark Erhardt**: Yeah. Well, we can only do as much as there's news, right?! + +**Mike Schmidt**: All right, thank you all for listening, we're here next week. + +**Mark Erhardt**: Yeah, bye bye. {% include references.md %} From a22eda8cfba988e3a147671fd7684cd904146c4a Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sun, 24 Aug 2025 11:18:47 +0200 Subject: [PATCH 221/278] Newsletter 367 translate in French (#2474) --- .../fr/newsletters/2025-08-15-newsletter.md | 80 +++++++++++++++++++ 1 file changed, 80 insertions(+) create mode 100644 _posts/fr/newsletters/2025-08-15-newsletter.md diff --git a/_posts/fr/newsletters/2025-08-15-newsletter.md b/_posts/fr/newsletters/2025-08-15-newsletter.md new file mode 100644 index 0000000000..d74a28fc9f --- /dev/null +++ b/_posts/fr/newsletters/2025-08-15-newsletter.md @@ -0,0 +1,80 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #367' +permalink: /fr/newsletters/2025/08/15/ +name: 2025-08-15-newsletter-fr +slug: 2025-08-15-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine inclut nos sections régulières résumant les +annonces de nouvelles versions et de candidats à la publication, et les résumés des modifications +notables apportées aux logiciels d'infrastructure Bitcoin populaires. + +## Nouvelles + +_Aucune nouvelle significative n'a été trouvée cette semaine dans aucune de nos [sources][optech +sources]._ + +## Mises à jour et versions candidates + +_Nouvelles versions et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de mettre à niveau vers les nouvelles versions ou d'aider à tester les versions candidates._ + +- [LND v0.19.3-beta.rc1][] est un candidat à la sortie pour une version de maintenance pour cette + implémentation populaire de nœud LN contenant des "corrections de bugs importantes". Plus + notablement, "une migration optionnelle [...] réduit de manière significative les exigences en + disque et en mémoire pour les nœuds." + +- [Bitcoin Core 29.1rc1][] est un candidat à la sortie pour une version de maintenance du logiciel + de nœud complet prédominant. + +## Changements notables dans le code et la documentation + +_Changements notables récents dans [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Interface de Portefeuille Matériel (HWI)][hwi +repo], [Rust Bitcoin][rust bitcoin repo], [Serveur BTCPay][btcpay server repo], [BDK][bdk repo], +[Propositions d'Amélioration de Bitcoin (BIPs)][bips repo], [BOLTs Lightning][bolts repo], +[BLIPs Lightning][blips repo], [Inquisition Bitcoin][bitcoin inquisition +repo], et [BINANAs][binana repo]._ + +- [Bitcoin Core #33050][] supprime la découragement des pairs (voir le [Bulletin + #309][news309 peer]) pour les transactions invalides selon le consensus car sa protection DoS était + inefficace. Un attaquant pourrait contourner la protection en + spammant des transactions invalides selon la politique sans pénalité. Cette mise à jour élimine + le besoin de double validation de script car il n'est plus nécessaire de + distinguer entre les échecs de consensus et de standard, économisant ainsi des coûts CPU. + +- [Bitcoin Core #32473][] introduit un cache par entrée pour la pré-computation de sighash + à l'interpréteur de script pour les entrées legacy (par exemple, baremultisig), + P2SH, P2WSH (et par incidence P2WPKH) pour réduire l'impact des attaques de hachage quadratique dans + les transactions standard. Core met en cache un hash presque fini + calculé juste avant d'ajouter le byte de sighash pour réduire le hachage répété pour + les transactions multisig standard et des motifs similaires. Une autre signature dans la + même entrée avec le même mode de sighash qui s'engage sur la même portion du + script peut réutiliser la plupart du travail. Il est activé à la fois dans la politique (mempool) et + la validation de consensus (bloc). Les entrées [Taproot][topic taproot] ont déjà + ce comportement par défaut, donc cette mise à jour n'a pas besoin d'être appliquée à elles. + +- [Bitcoin Core #33077][] crée une bibliothèque statique monolithique + [`libbitcoinkernel.a`][libbitcoinkernel project] qui regroupe tous les fichiers objet + de ses dépendances privées dans une seule archive, permettant aux projets en aval + de se lier juste à ce fichier unique. Voir le [Bulletin #360][news360 kernel] + pour les travaux préparatoires liés à `libsecp256k1`. + +- [Core Lightning #8389][] rend le champ `channel_type` obligatoire lors de l'ouverture + d'un canal, en accord avec une récente mise à jour de la spécification (voir le [Bulletin + #364][news364 spec]). Les commandes RPC `fundchannel` et `fundchannel_start` + indiquent désormais un type de canal avec l'option [canal zero-conf][topic zero-conf + channels] lorsque un `minimum_depth` nul le suggère. + +{% include snippets/recap-ad.md when="2025-08-19 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="33050,32473,33077,8389" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[lnd v0.19.3-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta.rc1 +[news309 peer]: /fr/newsletters/2024/06/28/#bitcoin-core-29575 +[news360 kernel]: /fr/newsletters/2025/06/27/#libsecp256k1-1678 +[libbitcoinkernel project]: https://github.com/bitcoin/bitcoin/issues/27587 +[news364 spec]: /fr/newsletters/2025/07/25/#bolts-1232 \ No newline at end of file From a9a7523470b5c781bf410b1344776452fe548408 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sun, 24 Aug 2025 11:33:07 +0200 Subject: [PATCH 222/278] Newsletter 368 translate in French (#2475) --- .../fr/newsletters/2025-08-22-newsletter.md | 222 ++++++++++++++++++ 1 file changed, 222 insertions(+) create mode 100644 _posts/fr/newsletters/2025-08-22-newsletter.md diff --git a/_posts/fr/newsletters/2025-08-22-newsletter.md b/_posts/fr/newsletters/2025-08-22-newsletter.md new file mode 100644 index 0000000000..a0be095ec6 --- /dev/null +++ b/_posts/fr/newsletters/2025-08-22-newsletter.md @@ -0,0 +1,222 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #368' +permalink: /fr/newsletters/2025/08/22/ +name: 2025-08-22-newsletter-fr +slug: 2025-08-22-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine résume un projet de BIP pour le partage de modèles de bloc entre les +nœuds complets et annonce une bibliothèque qui permet la délégation de confiance de l'évaluation de +script (y compris pour les fonctionnalités non disponibles dans les langages de script natifs de +Bitcoin). Sont également incluses nos sections régulières résumant les changements récents apportés +aux clients et services, les annonces de nouvelles versions et de candidats à la publication, et les +résumés des modifications notables apportées aux logiciels d'infrastructure Bitcoin populaires. + +## Nouvelles + +- **Projet de BIP pour le partage de modèles de bloc :** Anthony Towns a [posté][towns bipshare] sur + la liste de diffusion Bitcoin-Dev le [projet][towns bipdraft] d'un BIP sur la manière dont les nœuds + peuvent communiquer à leurs pairs les transactions qu'ils tenteraient de miner dans leur prochain + bloc (voir le [Bulletin #366][news366 templshare]). Cela permet au nœud de partager les transactions + qu'il acceptera via son mempool et sa politique de minage que ses pairs pourraient normalement + rejeter selon leur propre politique, permettant à ces pairs de mettre en cache ces transactions au + cas où elles seraient minées (ce qui améliore l'efficacité du [relais de bloc compact][topic + compact block relay]). Les transactions dans un modèle de bloc d'un nœud sont généralement les + transactions non confirmées les plus rentables connues de ce nœud, donc les pairs qui ont + précédemment rejeté ces transactions pour des raisons de politique pourraient également les trouver + dignes d'une considération supplémentaire. + + Le protocole spécifié dans le projet de BIP est simple. Peu après l'initiation d'une connexion avec + un pair, le nœud envoie un message `sendtemplate` indiquant au pair qu'il est prêt à envoyer des + modèles de blocs. À tout moment ultérieur, le pair peut demander un modèle avec un message + `gettemplate`. En réponse à la demande, le nœud répond avec un message `template` qui contient une + liste d'identifiants de transactions courts utilisant le même format qu'un message de bloc compact + [BIP152][]. Le pair peut alors demander les transactions qu'il souhaite en incluant l'identifiant + court dans un message `sendtransactions` (également comme dans BIP152). Le projet de BIP permet aux + modèles d'être jusqu'à un peu plus de deux fois la taille de la limite de poids de bloc maximum + actuelle. + + Un [║fil de discussion Bitcoin][delshare] sur le partage de modèles a vu cette semaine une + discussion supplémentaire sur la manière d'améliorer l'efficacité de la bande passante de la + proposition. Les idées discutées incluaient l'envoi uniquement de la [différence][towns templdiff] + depuis le modèle précédent (une économie de bande passante estimée à 90%), l'utilisation d'un + protocole de [réconciliation de l'ensemble][jahr templerlay] tel que celui permis par + [minisketch][topic minisketch] (permettant de partager efficacement des modèles beaucoup plus + grands), et l'utilisation du [codage Golomb-Rice][wuille templgr] sur les modèles + similaires aux [filtres de bloc compact][topic compact block filters] (une efficacité estimée à + 25%). + +- **Délégation de confiance pour l'évaluation de script :** Josh Doman a [posté][doman tee] sur + Delving Bitcoin à propos d'une bibliothèque qu'il a écrite qui utilise un _environnement d'exécution + de confiance_ ([TEE][]) qui ne signera une dépense de chemin de clé [taproot][topic taproot] que si + la transaction contenant + cette dépense satisfait un script. Le script peut contenir des opcodes qui ne sont actuellement pas + actifs sur Bitcoin aujourd'hui ou une forme complètement différente de script (par exemple, + [Simplicity][topic simplicity] ou [bll][topic bll]). + + Cette approche nécessite que ceux qui reçoivent des fonds vers le script fassent confiance au TEE---à + la fois qu'il sera encore disponible pour signer à l'avenir et qu'il ne signera qu'une dépense qui + satisfait son script d'encumbrance---mais elle permet une expérimentation rapide avec de nouvelles + fonctionnalités proposées pour Bitcoin avec une valeur monétaire réelle. Pour réduire la confiance + dans la disponibilité future du TEE, un chemin de dépense de secours peut être inclus; par exemple, + un chemin [timelocked][topic timelocks] qui permet à un participant de dépenser unilatéralement ses + fonds un an après les avoir confiés au TEE. + + La bibliothèque est conçue pour être utilisée avec l'enclave Nitro d'Amazon Web Services (AWS). + +## Changements dans les services et logiciels clients + +*Dans cette rubrique mensuelle, nous mettons en lumière des mises à jour intéressantes des +portefeuilles et services Bitcoin.* + +- **ZEUS v0.11.3 publié :** + La version [v0.11.3][zeus v0.11.3] inclut des améliorations de la gestion des pairs, [BOLT12][topic + offers], et des fonctionnalités de [submarine swap][topic submarine swaps]. + +- **Ressources Rust Utreexo :** + Abdelhamid Bakhta a [publié][abdel tweet] des ressources basées sur Rust pour [Utreexo][topic + utreexo], incluant des [matériaux éducatifs][rustreexo webapp] interactifs et des [liaisons + WASM][rustreexo wasm]. + +- **Outils d'observation des pairs et appel à l'action :** + 0xB10C a [publié][b10c blog] sur la motivation, l'architecture, le code, les bibliothèques de + soutien, et les découvertes de son projet [peer-observer][peer-observer github]. Il cherche à + construire "Un groupe décentralisé de personnes qui partagent l'intérêt de surveiller le Réseau + Bitcoin. Un collectif pour permettre le partage d'idées, de discussions, de données, d'outils, + d'aperçus, et plus encore." + +- **Nœud basé sur le noyau Bitcoin Core annoncé :** + Le backbone Bitcoin a été [annoncé][bitcoin backbone] comme une démonstration de l'utilisation de la + bibliothèque [Bitcoin Core Kernel][kernel blog] comme fondation d'un nœud Bitcoin. + +- **SimplicityHL publié :** + [SimplicityHL][simplcityhl github] est un langage de programmation semblable à Rust qui compile vers + le langage [Simplicity][simplicity] de niveau inférieur [récemment activé][simplicity post] sur + Liquid. Pour plus de lecture, voir le [fil de discussion lié][simplicityhl delving]. + +- **Plugin LSP pour BTCPay Server :** + Le [plugin LSP][lsp btcpay github] implémente les fonctionnalités côté client de [BLIP51][], la + spécification pour les canaux entrants, dans BTCPay Server. + +- **Matériel et logiciel de minage Proto annoncés :** + Proto a [annoncé][proto blog] un nouveau matériel de minage Bitcoin et un logiciel de minage open + source, construit avec les [retours de la communauté][news260 mdk] précédents. + +- **Démonstration de résolution d'oracle utilisant CSFS :** + Abdelhamid Bakhta a [publié][abdel tweet2] une démonstration d'un oracle utilisant [CSFS][topic + op_checksigfromstack], nostr, et MutinyNet pour signer une attestation du résultat d'un événement. + +- **Relai ajoute le support de taproot :** Relai a ajouté le support pour l'envoi vers des adresses + [taproot][topic taproot]. + +## Mises à jour et versions candidates + +_Nouvelles versions et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de mettre à niveau vers les nouvelles versions ou d'aider à tester les versions candidates._ + +- [LND v0.19.3-beta][] est une version de maintenance pour cette implémentation populaire de nœud LN + contenant des "corrections de bugs importantes". Plus notablement, "une migration optionnelle [...] + réduit significativement les besoins en disque et en mémoire pour les nœuds." + +- [Bitcoin Core 29.1rc1][] est un candidat à la sortie pour une version de maintenance du logiciel + de nœud complet prédominant. + +- [Core Lightning v25.09rc2][] est un candidat à la sortie pour une nouvelle version majeure de + cette implémentation populaire de nœud LN. + +## Changements notables dans le code et la documentation + +_Changements notables récents dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core +lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], +[libsecp256k1][libsecp256k1 repo], [Interface de Portefeuille Matériel (HWI)][hwi repo], [Rust +Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Propositions +d'Amélioration de Bitcoin (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips +repo], [Inquisition Bitcoin][bitcoin inquisition repo], et [BINANAs][binana repo]._ + +- [Bitcoin Core #32896][] introduit le support pour la création et la dépense de transactions + Topologically Restricted Until Confirmation ([TRUC][topic v3 transaction relay]) non confirmées en + ajoutant un paramètre `version` aux RPCs suivants : `createrawtransaction`, `createpsbt`, `send`, + `sendall`, et `walletcreatefundedpsbt`. Le portefeuille applique les restrictions de transaction + TRUC pour la limite de poids, le conflit entre frères, et l'incompatibilité entre les transactions + TRUC non confirmées et non-TRUC. + +- [Bitcoin Core #33106][] abaisse le `blockmintxfee` par défaut à 1 sat/kvB (le minimum possible), + et le [`minrelaytxfee`][topic default minimum transaction relay feerates] par défaut et + `incrementalrelayfee` à 100 sat/kvB (0.1 sat/vB). Bien que ces valeurs puissent être configurées, il + est conseillé aux utilisateurs d'ajuster les valeurs `minrelaytxfee` et `incrementalrelayfee` + ensemble. Les autres feerates minimum restent inchangées, mais les feerates minimum par défaut du + portefeuille sont attendues pour être abaissées dans une version future. Les motivations pour ce + changement vont de la croissance considérable du nombre de blocs minés avec des transactions sous 1 + sat/vB et du nombre de pools minant ces transactions à une augmentation du taux de change du + Bitcoin. + +- [Core Lightning #8467][] étend `xpay` (voir le [Bulletin #330][news330 xpay]) en ajoutant le + support pour le paiement de noms lisibles par l'homme [BIP353][] (HRN) (par exemple, + satoshi@bitcoin.com) et en lui permettant de payer directement les [offres BOLT12][topic offers], + éliminant le besoin d'exécuter la commande `fetchinvoice` d'abord. + Sous le capot, `xpay` récupère les instructions de paiement en utilisant la commande RPC + `fetchbip353` du plugin `cln-bip353` introduit dans [Core Lightning #8362][]. + +- [Core Lightning #8354][] commence à publier des notifications d'événements `pay_part_start` et + `pay_part_end` pour le statut de parties de paiement spécifiques envoyées avec [MPP][topic multipath + payments]. La notification `pay_part_end` indique la durée du paiement et si celui-ci a été réussi + ou échoué. Si le paiement échoue, un message d'erreur est fourni et, si l'oignon d'erreur n'est pas + corrompu, des informations supplémentaires sur l'échec sont données, telles que la source de + l'erreur et le code d'échec. + +- [Eclair #3103][] introduit le support pour [simple taproot channels][topic simple taproot + channels], exploitant le [MuSig2][topic musig] de [multisignature][topic multisignature] + sans script pour réduire la consommation de poids de transaction de 15% et améliorer la + confidentialité des transactions. Les transactions de financement et les fermetures coopératives + sont indiscernables des autres transactions [P2TR][topic taproot]. Cette PR inclut également le + support pour le [dual funding][topic dual funding] et le [splicing][topic splicing] dans les canaux + taproot simples, et active les [mises à niveau d'engagement de canal][topic channel commitment + upgrades] au nouveau format taproot lors d'une transaction de splice. + +- [Eclair #3134][] remplace le multiplicateur de poids de pénalité pour les [HTLCs][topic htlc] + bloqués par le [CLTV expiry delta][topic cltv expiry delta] lors de l'évaluation de la réputation + des pairs pour l'[endorsement HTLC][topic htlc endorsement] (voir le [Bulletin #363][news363 + reputation]), pour mieux refléter combien de temps un HTLC bloqué immobilisera la liquidité. Pour + atténuer la pénalité disproportionnée des HTLCs bloqués avec un delta d'expiration CLTV maximum, + cette PR ajuste le paramètre de dégradation de la réputation (`half-life`) de 15 à 30 jours et le + seuil de paiement bloqué (`max-relay-duration`) de 12 secondes à 5 minutes. + +- [LDK #3897][] étend son implémentation de [stockage de pairs][topic peer storage] en détectant la + perte de l'état du canal lors de la récupération de sauvegarde, en désérialisant la copie du pair et + en la comparant à l'état local. + +{% include snippets/recap-ad.md when="2025-08-26 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32896,33106,8467,8354,3103,3134,3897,8362" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[lnd v0.19.3-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta +[core lightning v25.09rc2]: https://github.com/ElementsProject/lightning/releases/tag/v25.09rc2 +[towns bipshare]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aJvZwR_bPeT4LaH6@erisian.com.au/ +[towns bipdraft]: https://github.com/ajtowns/bips/blob/202508-sendtemplate/bip-ajtowns-sendtemplate.md +[news366 templshare]: /fr/newsletters/2025/08/08/#partage-de-modele-de-bloc-entre-pairs-pour-attenuer-les-problemes-lies-aux-politiques-de-mempool-divergentes +[delshare]: https://delvingbitcoin.org/t/sharing-block-templates/1906/13 +[towns templdiff]: https://delvingbitcoin.org/t/sharing-block-templates/1906/7 +[jahr templerlay]: https://delvingbitcoin.org/t/sharing-block-templates/1906/6 +[wuille templgr]: https://delvingbitcoin.org/t/sharing-block-templates/1906/9 +[doman tee]: https://delvingbitcoin.org/t/confidential-script-emulate-soft-forks-using-stateless-tees/1918/ +[tee]: https://en.wikipedia.org/wiki/Trusted_execution_environment +[news330 xpay]: /fr/newsletters/2024/11/22/#core-lightning-7799 +[news363 reputation]: /fr/newsletters/2025/07/18/#eclair-2716 +[zeus v0.11.3]: https://github.com/ZeusLN/zeus/releases/tag/v0.11.3 +[abdel tweet]: https://x.com/dimahledba/status/1951213485104181669 +[rustreexo webapp]: https://rustreexo-playground.starkwarebitcoin.dev/ +[rustreexo wasm]: https://github.com/AbdelStark/rustreexo-wasm +[b10c blog]: https://b10c.me/projects/024-peer-observer/ +[peer-observer github]: https://github.com/0xB10C/peer-observer +[bitcoin backbone]: https://mailing-list.bitcoindevs.xyz/bitcoindev/9812cde0-7bbb-41a6-8e3b-8a5d446c1b3cn@googlegroups.com +[kernel blog]: https://thecharlatan.ch/Kernel/ +[simplcityhl github]: https://github.com/BlockstreamResearch/SimplicityHL +[simplicity]: https://blockstream.com/simplicity.pdf +[simplicityhl delving]: https://delvingbitcoin.org/t/writing-simplicity-programs-with-simplicityhl/1900 +[simplicity post]: https://blog.blockstream.com/simplicity-launches-on-liquid-mainnet/ +[lsp btcpay github]: https://github.com/MegalithicBTC/BTCPayserver-LSPS1 +[proto blog]: https://proto.xyz/blog/posts/proto-rig-and-proto-fleet-a-paradigm-shift +[news260 mdk]: /fr/newsletters/2023/07/19/#appel-a-commentaires-sur-le-mining-development-kit-mdk +[abdel tweet2]: https://x.com/dimahledba/status/1946223544234659877 From 252a544ebd257b37c4cb4c0f5608aaa6ad2f29ef Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Thu, 28 Aug 2025 22:56:43 +0200 Subject: [PATCH 223/278] newsletter-368-into-german (#2476) Co-authored-by: garfiel-d --- .../de/newsletters/2025-08-22-newsletter.md | 236 ++++++++++++++++++ 1 file changed, 236 insertions(+) create mode 100644 _posts/de/newsletters/2025-08-22-newsletter.md diff --git a/_posts/de/newsletters/2025-08-22-newsletter.md b/_posts/de/newsletters/2025-08-22-newsletter.md new file mode 100644 index 0000000000..36d88b5780 --- /dev/null +++ b/_posts/de/newsletters/2025-08-22-newsletter.md @@ -0,0 +1,236 @@ +--- +title: 'Bitcoin Optech Newsletter #368' +permalink: /de/newsletters/2025/08/22/ +name: 2025-08-22-newsletter-de +slug: 2025-08-22-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- + +Der Newsletter dieser Woche fasst einen BIP-Entwurf zum Austausch von Block-Templates +zwischen Full Nodes zusammen und stellt eine Bibliothek vor, die eine vertrauenswürdige +Delegation der Skriptauswertung ermöglicht (auch für Funktionen, die in Bitcoins +nativen Skriptsprachen nicht verfügbar sind). Außerdem enthalten sind unsere +regelmäßigen Abschnitte mit aktuellen Updates zu Services und Client-Software, +Ankündigungen neuer Releases und Release-Kandidaten sowie einer Zusammenfassung +Änderungen an wichtiger Bitcoin-Infrastruktur-Software. + + +## Nachrichten + +- **BIP-Entwurf zum Teilen von Block-Templates:** Anthony Towns + [veröffentlichte][towns bipshare] in der Bitcoin-Dev-Mailingliste den + [Entwurf][towns bipdraft] eines BIPs, wie Knoten ihren Peers die + Transaktionen mitteilen können, die sie im nächsten Block schürfen + würden (Mining) (siehe [Newsletter #366][news366 templshare]). Dadurch kann + ein Knoten Transaktionen teilen, die er laut Mempool- und Mining- + Policy akzeptiert, die seine Peers aber normalerweise ablehnen + würden. Diese Peers können die Transaktionen für den Fall cachen, + dass sie gemint werden (was die Effizienz des + [Compact Block Relay][topic compact block relay] verbessert). + Die Transaktionen im Block-Template eines Knotens sind meist + die profitabelsten unbestätigten Transaktionen, sodass Peers, + die sie zuvor aus Policy-Gründen abgelehnt haben, sie erneut + bewerten können. + + Das im Entwurf spezifizierte Protokoll ist einfach: kurz nach + Verbindungsaufbau sendet der Knoten eine `sendtemplate`-Nachricht, + um die Bereitschaft zum Senden von Block-Templates zu signalisieren. + Später kann der Peer mit einer `gettemplate`-Nachricht ein Template + anfordern. Der Knoten antwortet mit einer `template`-Nachricht, die + eine Liste von kurzen Transaktions-IDs im [BIP152][]-Format enthält. + Der Peer kann dann gewünschte Transaktionen per `sendtransactions`- + Nachricht anfordern (ebenfalls wie in BIP152). Der Entwurf erlaubt + Templates, die bis etwas mehr als doppelt so groß sind wie das aktuelle + Blockgewichtslimit. + + In einem Delving-Bitcoin-[Thread][delshare] gab es weitere + Diskussionen zur Verbesserung der Bandbreiteneffizienz. Vorgeschlagen + wurden: nur die [Differenz][towns templdiff] zum vorherigen Template + zu senden (ca. 90% Ersparnis), ein [Set-Reconciliation][jahr templerlay] + -Protokoll wie [minisketch][topic minisketch] (ermöglicht + effizientes Teilen großer Templates) und Golomb-Rice + [Kodierung][wuille templgr] ähnlich wie bei + [Compact Block Filters][topic compact block filters] (ca. 25% Ersparnis). + +- **Vertrauenswürdige Delegation der Skriptauswertung:** Josh Doman + [stellte][doman tee] in Delving Bitcoin eine Bibliothek vor, die ein + _Trusted Execution Environment_ ([TEE][]) nutzt. Dieses signiert + einen [Taproot][topic taproot]-Keypath-Spend nur, wenn die + Transaktion ein Skript erfüllt. Das Skript kann Opcodes enthalten, + die aktuell in Bitcoin nicht aktiv sind, oder eine ganz andere + Skriptsprache (z. B. [Simplicity][topic simplicity] oder [bll][topic + bll]). + + Empfänger von Geldern müssen dem TEE vertrauen – sowohl dass es + zukünftig verfügbar bleibt, als auch dass es nur dann signiert, wenn + das Skript erfüllt ist. Dies ermöglicht schnelle Experimente mit + neuen Bitcoin-Features mit echtem Wert. Um das Vertrauen ins TEE zu + reduzieren, kann ein Backup-Spend-Pfad eingebaut werden, z. B. ein + [timelocked][topic timelocks] Pfad, der nach einem Jahr eine + einseitige Ausgabe erlaubt. + + Die Bibliothek ist für die Nutzung mit Amazon Web Services (AWS) + Nitro Enclave konzipiert. + + +## Änderungen bei Services und Client-Software + +*In dieser monatlichen Rubrik stellen wir interessante Updates zu Bitcoin- +Wallets und Services vor.* + +- **ZEUS v0.11.3 veröffentlicht:** + Das [v0.11.3][zeus v0.11.3] Release bringt Verbesserungen beim Peer-Management, + bei [BOLT12][topic offers] und den [Submarine Swap][topic submarine swaps]-Funktionen. + +- **Rust-Utreexo-Ressourcen:** + Abdelhamid Bakhta [veröffentlichte][abdel tweet] Rust-basierte Ressourcen für + [Utreexo][topic utreexo], darunter interaktive [Lernmaterialien][rustreexo webapp] + und [WASM-Bindings][rustreexo wasm]. + +- **Peer-Observer-Tooling und Aufruf zur Mitarbeit:** + 0xB10C [stellte][b10c blog] Motivation, Architektur, Code, unterstützende + Bibliotheken und Erkenntnisse seines [Peer-Observer][peer-observer github]-Projekts vor. + Ziel ist eine lose, dezentrale Gruppe von Menschen, die das Bitcoin-Netzwerk + überwachen und gemeinsam Ideen, Daten, Tools und Erkenntnisse teilen. + +- **Bitcoin Core Kernel-basierter Knoten angekündigt:** + Bitcoin Backbone wurde [angekündigt][bitcoin backbone] als Demonstration für + die Nutzung der [Bitcoin Core Kernel][kernel blog]-Bibliothek als Basis eines Bitcoin-Nodes. + +- **SimplicityHL veröffentlicht:** + [SimplicityHL][simplcityhl github] ist eine Rust-ähnliche Programmiersprache, + die in die Low-Level-[Simplicity][simplicity]-Sprache [kürzlich aktiviert][simplicity post] + auf Liquid kompiliert. Weitere Infos im [Delving-Thread][simplicityhl delving]. + +- **LSP-Plugin für BTCPay Server:** + Das [LSP-Plugin][lsp btcpay github] implementiert Client-Funktionen von + [BLIP51][], der Spezifikation für eingehende Kanäle, in BTCPay Server. + +- **Proto Mining-Hardware und -Software angekündigt:** + Proto [stellte][proto blog] neue Bitcoin-Mining-Hardware und Open-Source- + Mining-Software vor, entwickelt mit vorherigem [Community-Feedback][news260 mdk]. + +- **Oracle-Resolution-Demo mit CSFS:** + Abdelhamid Bakhta [zeigte][abdel tweet2] eine Oracle-Demo mit + [CSFS][topic op_checksigfromstack], nostr und MutinyNet zur Signierung + einer Ereignisbestätigung. + +- **Relai unterstützt Taproot:** + Relai hat die Unterstützung für das Senden an [Taproot][topic taproot]-Adressen hinzugefügt. + + +## Releases und Release-Kandidaten + +_Neue Releases und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. +Bitte erwägen Sie, auf neue Versionen zu aktualisieren oder bei der Testung von +Release-Kandidaten zu helfen._ + +- [LND v0.19.3-beta][] ist ein Release für eine Wartungsversion dieser beliebten + LN-Knoten-Implementierung, das "wichtige Bugfixes" enthält. Besonders + erwähnenswert ist "eine optionale Migration [...], die Festplatten- und + Speicheranforderungen für Knoten erheblich senkt." + +- [Bitcoin Core 29.1rc1][] ist ein Release-Kandidat für eine Wartungsversion der + führenden Full-Node-Software. + +- [Core Lightning v25.09rc2][] ist ein Release-Kandidat für eine neue Hauptversion + dieser beliebten LN-Knoten-Implementierung. + + +## Wichtige Code- und Dokumentationsänderungen + +_Wichtige aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], +[Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], +[Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], +[BIPs][bips repo], [BOLTs][bolts repo], [BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] +und [BINANAs][binana repo]._ + +- [Bitcoin Core #32896][] ermöglicht das Erstellen und Ausgeben unbestätigter + Topologically Restricted Until Confirmation ([TRUC][topic v3 transaction relay])-Transaktionen + durch Hinzufügen eines `version`-Parameters zu den folgenden RPCs: + `createrawtransaction`, `createpsbt`, `send`, `sendall` und `walletcreatefundedpsbt`. + Die Wallet erzwingt die TRUC-Beschränkungen für Gewichtslimit, Konflikte mit + Geschwister-Transaktionen und die Unvereinbarkeit zwischen unbestätigten TRUC- + und Nicht-TRUC-Transaktionen. + +- [Bitcoin Core #33106][] senkt die Standardwerte für `blockmintxfee` auf 1 sat/kvB (Minimum) + sowie für [`minrelaytxfee`][topic default minimum transaction relay feerates] und + `incrementalrelayfee` auf 100 sat/kvB (0,1 sat/vB). Diese Werte sind konfigurierbar, + Nutzer sollten `minrelaytxfee` und `incrementalrelayfee` gemeinsam anpassen. + Andere Mindest-Feerates bleiben unverändert, aber die Standardwerte für Wallet-Feerates + werden voraussichtlich in einer zukünftigen Version gesenkt. Gründe für die Änderung sind + das starke Wachstum von Blöcken mit Transaktionen unter 1 sat/vB, die Anzahl der Pools, + die solche Transaktionen minen, und der gestiegene Bitcoin-Kurs. + +- [Core Lightning #8467][] erweitert `xpay` (siehe [Newsletter #330][news330 xpay]) + um die Unterstützung für Zahlungen an [BIP353][] Human Readable Names (HRN) + (z. B. satoshi@bitcoin.com) und ermöglicht direkte Zahlungen an + [BOLT12 offers][topic offers], ohne vorher den Befehl `fetchinvoice` ausführen zu müssen. + Intern holt sich `xpay` die Zahlungsanweisungen über den RPC-Befehl `fetchbip353` + aus dem `cln-bip353`-Plugin, das in [Core Lightning #8362][] eingeführt wurde. + +- [Core Lightning #8354][] beginnt mit der Veröffentlichung von + `pay_part_start`- und `pay_part_end`-Event-Benachrichtigungen zum Status + einzelner Zahlungsteile, die mit [MPP][topic multipath payments] gesendet wurden. + Die `pay_part_end`-Benachrichtigung zeigt die Dauer der Zahlung und ob sie + erfolgreich war oder fehlgeschlagen ist. Bei Fehlschlag wird eine Fehlermeldung + und, falls der Error-Onion nicht beschädigt ist, zusätzliche Information zur + Ursache und zum Fehlercode bereitgestellt. + +- [Eclair #3103][] führt Unterstützung für [Simple Taproot Channels][topic simple taproot channels] + ein und nutzt [MuSig2][topic musig] scriptless [Multisignature][topic multisignature]-Signaturen, + um das Transaktionsgewicht um 15% zu reduzieren und die Privatsphäre zu verbessern. + Funding-Transaktionen und kooperative Schließungen sind von anderen [P2TR][topic taproot]-Transaktionen + nicht zu unterscheiden. Dieser PR enthält auch Unterstützung für [Dual Funding][topic dual funding] + und [Splicing][topic splicing] in Simple Taproot Channels und ermöglicht + [Channel Commitment Upgrades][topic channel commitment upgrades] auf das neue Taproot-Format + während einer Splice-Transaktion. + +- [Eclair #3134][] ersetzt den Strafgewicht-Multiplikator für hängende [HTLCs][topic htlc] + durch das [CLTV expiry delta][topic cltv expiry delta] bei der Bewertung der + [HTLC endorsement][topic htlc endorsement]-Peer-Reputation (siehe [Newsletter #363][news363 reputation]), + um besser abzubilden, wie lange ein hängender HTLC Liquidität bindet. Um die übermäßige Strafe + für HTLCs mit maximalem CLTV expiry delta zu mildern, werden die Reputation-Decay-Parameter + (`half-life`) von 15 auf 30 Tage und der Schwellenwert für hängende Zahlungen + (`max-relay-duration`) von 12 Sekunden auf 5 Minuten angepasst. + +- [LDK #3897][] erweitert die [Peer Storage][topic peer storage]-Implementierung, + indem verlorener Channel-State beim Wiederherstellen von Backups erkannt wird: + Die Kopie des Peers wird deserialisiert und mit dem lokalen Zustand verglichen. + +{% include snippets/recap-ad.md when="2025-08-26 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32896,33106,8467,8354,3103,3134,3897,8362" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[lnd v0.19.3-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta +[core lightning v25.09rc2]: https://github.com/ElementsProject/lightning/releases/tag/v25.09rc2 +[towns bipshare]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aJvZwR_bPeT4LaH6@erisian.com.au/ +[towns bipdraft]: https://github.com/ajtowns/bips/blob/202508-sendtemplate/bip-ajtowns-sendtemplate.md +[news366 templshare]: /de/newsletters/2025/08/08/#peer-block-template-sharing-zur-milderung-von-mempool-richtlinien-problemen +[delshare]: https://delvingbitcoin.org/t/sharing-block-templates/1906/13 +[towns templdiff]: https://delvingbitcoin.org/t/sharing-block-templates/1906/7 +[jahr templerlay]: https://delvingbitcoin.org/t/sharing-block-templates/1906/6 +[wuille templgr]: https://delvingbitcoin.org/t/sharing-block-templates/1906/9 +[doman tee]: https://delvingbitcoin.org/t/confidential-script-emulate-soft-forks-using-stateless-tees/1918/ +[tee]: https://en.wikipedia.org/wiki/Trusted_execution_environment +[news330 xpay]: /en/newsletters/2024/11/22/#core-lightning-7799 +[news363 reputation]: /de/newsletters/2025/07/18/#eclair-2716 +[zeus v0.11.3]: https://github.com/ZeusLN/zeus/releases/tag/v0.11.3 +[abdel tweet]: https://x.com/dimahledba/status/1951213485104181669 +[rustreexo webapp]: https://rustreexo-playground.starkwarebitcoin.dev/ +[rustreexo wasm]: https://github.com/AbdelStark/rustreexo-wasm +[b10c blog]: https://b10c.me/projects/024-peer-observer/ +[peer-observer github]: https://github.com/0xB10C/peer-observer +[bitcoin backbone]: https://mailing-list.bitcoindevs.xyz/bitcoindev/9812cde0-7bbb-41a6-8e3b-8a5d446c1b3cn@googlegroups.com +[kernel blog]: https://thecharlatan.ch/Kernel/ +[simplcityhl github]: https://github.com/BlockstreamResearch/SimplicityHL +[simplicity]: https://blockstream.com/simplicity.pdf +[simplicityhl delving]: https://delvingbitcoin.org/t/writing-simplicity-programs-with-simplicityhl/1900 +[simplicity post]: https://blog.blockstream.com/simplicity-launches-on-liquid-mainnet/ +[lsp btcpay github]: https://github.com/MegalithicBTC/BTCPayserver-LSPS1 +[proto blog]: https://proto.xyz/blog/posts/proto-rig-and-proto-fleet-a-paradigm-shift +[news260 mdk]: /en/newsletters/2023/07/19/#mining-development-kit-call-for-feedback +[abdel tweet2]: https://x.com/dimahledba/status/1946223544234659877 From 8c9257b8daec61c502457bded1997c8396cce091 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Wed, 27 Aug 2025 12:35:29 -1000 Subject: [PATCH 224/278] Newsletters: add 369 (2025-08-29) --- .../en/newsletters/2025-08-29-newsletter.md | 99 +++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 _posts/en/newsletters/2025-08-29-newsletter.md diff --git a/_posts/en/newsletters/2025-08-29-newsletter.md b/_posts/en/newsletters/2025-08-29-newsletter.md new file mode 100644 index 0000000000..994823cdee --- /dev/null +++ b/_posts/en/newsletters/2025-08-29-newsletter.md @@ -0,0 +1,99 @@ +--- +title: 'Bitcoin Optech Newsletter #369' +permalink: /en/newsletters/2025/08/29/ +name: 2025-08-29-newsletter +slug: 2025-08-29-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter shares an update on differential fuzzing of +Bitcoin and LN implementations and links to a new paper about garbled +locks for accountable computing contracts. Also included are our +regular sections summarizing popular questions and answers from the +Bitcoin Stack Exchange, announcing new releases and release candidates, +and describing notable changes to popular Bitcoin infrastructure +software. + +## News + +- **Update on differential fuzzing of Bitcoin and LN implementations:** + Bruno Garcia [posted][garcia fuzz] to Delving Bitcoin to describe + recent progress and accomplishments of [bitcoinfuzz][], a library and + related data for [fuzz testing][] Bitcoin-based software and + libraries. Accomplishments include the discovery of "over 35 bugs in + projects such as btcd, rust-bitcoin, rust-miniscript, Embit, Bitcoin + Core, Core Lightning, [and] LND." Discovered discrepancies between LN + implementations has not only revealed bugs but has also driven + clarifications to the LN specification. Developers of Bitcoin + projects are encouraged to investigate making their software a + supported target for bitcoinfuzz. + +- **Garbled locks for accountable computing contracts:** Liam Eagen + [posted][eagen glock] to the Bitcoin-Dev mailing list about a + [paper][eagen paper] he's written about a new mechanism for creating + [accountable computing contracts][topic acc] but based on [garbled + circuits][]. This is similar (but distinct) from other recent + independent work on using garbled circuits for BitVM (see [Newsletter + #359][news359 delbrag]). Eagen's post claims "the first (in his + opinion) practical garbled lock whose fraud proof is a single + signature, which represent over a 550x reduction of onchain data + compared to BitVM2." As of this writing, his post has not received + any public replies. + +## Selected Q&A from Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] is one of the first places Optech +contributors look for answers to their questions---or when we have a +few spare moments to help curious or confused users. In +this monthly feature, we highlight some of the top-voted questions and +answers posted since our last update.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +FIXME:bitschmidty + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [Bitcoin Core 29.1rc2][] is a release candidate for a maintenance + version of the predominant full node software. + +- [Core Lightning v25.09rc4][] is a release candidate for a new major + version of this popular LN node implementation. + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [Bitcoin Core #31802][] Add bitcoin-{node,gui} to release binaries for IPC + +- [LDK #3979][] Add splice-out support + +- [LND #10102][] Catch bad gossip peer and fix `UpdatesInHorizon` + +- [Rust Bitcoin #4907][] Introduce script tagging + +{% include snippets/recap-ad.md when="2025-09-02 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31802,3979,10102,4907" %} +[bitcoin core 29.1rc2]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[core lightning v25.09rc4]: https://github.com/ElementsProject/lightning/releases/tag/v25.09rc4 +[garcia fuzz]: https://delvingbitcoin.org/t/the-state-of-bitcoinfuzz/1946 +[bitcoinfuzz]: https://github.com/bitcoinfuzz +[fuzz testing]: https://en.wikipedia.org/wiki/Fuzzing +[eagen glock]: https://mailing-list.bitcoindevs.xyz/bitcoindev/Aq_-LHZtVdSN5nODCryicX2u_X1yAQYurf9UDZXDILq6s4grUOYienc4HH2xFnAohA69I_BzgRCSKdW9OSVlSU9d1HYZLrK7MS_7wdNsLmo=@protonmail.com/ +[eagen paper]: https://eprint.iacr.org/2025/1485 +[garbled circuits]: https://en.wikipedia.org/wiki/Garbled_circuit +[news359 delbrag]: /en/newsletters/2025/06/20/#improvements-to-bitvm-style-contracts From 57220304385061e1d22203436a0f32ae24bc92eb Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 28 Aug 2025 06:56:36 -0500 Subject: [PATCH 225/278] News369: add stack exchange --- .../en/newsletters/2025-08-29-newsletter.md | 30 +++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/_posts/en/newsletters/2025-08-29-newsletter.md b/_posts/en/newsletters/2025-08-29-newsletter.md index 994823cdee..72bb15fe47 100644 --- a/_posts/en/newsletters/2025-08-29-newsletter.md +++ b/_posts/en/newsletters/2025-08-29-newsletter.md @@ -52,7 +52,32 @@ answers posted since our last update.* {% comment %}{% endcomment %} {% assign bse = "https://bitcoin.stackexchange.com/a/" %} -FIXME:bitschmidty +- [Is it possible to recover a private key from an aggregate public key under strong assumptions?]({{bse}}127723) + Pieter Wuille explains current and hypothetical security assumptions around + [MuSig2][topic musig] scriptless [multisignatures][topic multisignature]. + +- [Are all taproot addresses vulnerable to quantum computing?]({{bse}}127660) + Hugo Nguyen and Murch point out that even [taproot][topic taproot] outputs + constructed to be spent only using script paths are [quantum][topic quantum + resistance] vulnerable. Murch goes on to note "Interestingly, the party that + generated the output script would be able to show that the internal key was a + NUMS point and thus prove that a Quantum Decryption has occurred." + +- [Why cant we set the chainstate obfuscation key?]({{bse}}127814) + Ava Chow highlights that the key that obfuscates on-disk contents of the + `blocksdir` (see [Newsletter #339][news339 blocksxor]) is not the + same key that obfuscates the `chainstate` contents (see [Bitcoin Core + #6650][]). + +- [Is it possible to revoke a spending branch after a block height?]({{bse}}127683) + Antoine Poinsot points to a [previous answer]({{bse}}122224) confirming that + expiring spending conditions, or "inverse timelocks", are not possible and + perhaps not even desirable. + +- [Configure Bitcoin Core to use onion nodes in addition to IPv4 and IPv6 nodes?]({{bse}}127727) + Pieter Wuille clarifies that setting the `onion` configuration option only + applies to outbound peer connections. He goes on to outline how to configure + [Tor][topic anonymity networks] and `bitcoind` for inbound connections. ## Releases and release candidates @@ -87,7 +112,7 @@ repo], and [BINANAs][binana repo]._ {% include snippets/recap-ad.md when="2025-09-02 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="31802,3979,10102,4907" %} +{% include linkers/issues.md v=2 issues="31802,3979,10102,4907,6650" %} [bitcoin core 29.1rc2]: https://bitcoincore.org/bin/bitcoin-core-29.1/ [core lightning v25.09rc4]: https://github.com/ElementsProject/lightning/releases/tag/v25.09rc4 [garcia fuzz]: https://delvingbitcoin.org/t/the-state-of-bitcoinfuzz/1946 @@ -97,3 +122,4 @@ repo], and [BINANAs][binana repo]._ [eagen paper]: https://eprint.iacr.org/2025/1485 [garbled circuits]: https://en.wikipedia.org/wiki/Garbled_circuit [news359 delbrag]: /en/newsletters/2025/06/20/#improvements-to-bitvm-style-contracts +[news339 blocksxor]: /en/newsletters/2025/01/31/#how-does-the-blocksxor-switch-that-obfuscates-the-blocks-dat-files-work From fde07c6359e9ef4808c5c48526c98a02413a7894 Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 28 Aug 2025 21:18:31 +0000 Subject: [PATCH 226/278] News369: merge summaries --- .../en/newsletters/2025-08-29-newsletter.md | 43 +++++++++++++++---- 1 file changed, 35 insertions(+), 8 deletions(-) diff --git a/_posts/en/newsletters/2025-08-29-newsletter.md b/_posts/en/newsletters/2025-08-29-newsletter.md index 72bb15fe47..d04f4aac11 100644 --- a/_posts/en/newsletters/2025-08-29-newsletter.md +++ b/_posts/en/newsletters/2025-08-29-newsletter.md @@ -102,17 +102,39 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Bitcoin Core #31802][] Add bitcoin-{node,gui} to release binaries for IPC - -- [LDK #3979][] Add splice-out support - -- [LND #10102][] Catch bad gossip peer and fix `UpdatesInHorizon` - -- [Rust Bitcoin #4907][] Introduce script tagging +- [Bitcoin Core #31802][] enables inter-process communication (IPC) by default + (`ENABLE_IPC`), adding the `bitcoin-node` and `bitcoin-gui` multiprocess + binaries to the release builds on all systems except Windows. This allows an + external [Stratum v2][topic pooled mining] mining service that creates, + manages and submits block templates to experiment with the multiprocess layout + without custom builds. For additional context on the multiprocess project and + the `bitcoin-node` binary, see Newsletters [#99][news99 ipc], [#147][news147 + ipc], [#320][news320 ipc], [#324][news324 ipc]. + +- [LDK #3979][] adds splice-out support, enabling an LDK node to both initiate a + splice-out transaction, and accept requests from a counterparty. This + completes LDK’s [splicing][topic splicing] implementation, as [LDK #3736][] + already added splice-in support. This PR adds a `SpliceContribution` enum that + covers both in and out scenarios and ensures that the output values of a + splice-out transaction don’t exceed the user’s channel balance after + accounting for fees and reserve requirements. + +- [LND #10102][] adds a `gossip.ban-threshold` option (100 is the default, 0 + disables it) that allows users to configure the score threshold at which a + peer is banned for sending invalid [gossip][topic channel announcements] + messages. The peer banning system was previously introduced and covered in + [Newsletter #319][news319 ban]. This PR also resolves an issue where + unnecessary node and [channel announcement][topic channel announcements] + messages were sent in response to a backlog gossip query request. + +- [Rust Bitcoin #4907][] introduces script tagging by adding a new generic tag + parameter `T` to `Script` and `ScriptBuf`, and defines the type aliases + `ScriptPubKey`, `ScriptSig`, `RedeemScript`, `WitnessScript`, and `TapScript` + which are backed by a sealed `Tag` trait for compile-time role safety. {% include snippets/recap-ad.md when="2025-09-02 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="31802,3979,10102,4907,6650" %} +{% include linkers/issues.md v=2 issues="31802,3979,10102,4907,6650,3736" %} [bitcoin core 29.1rc2]: https://bitcoincore.org/bin/bitcoin-core-29.1/ [core lightning v25.09rc4]: https://github.com/ElementsProject/lightning/releases/tag/v25.09rc4 [garcia fuzz]: https://delvingbitcoin.org/t/the-state-of-bitcoinfuzz/1946 @@ -123,3 +145,8 @@ repo], and [BINANAs][binana repo]._ [garbled circuits]: https://en.wikipedia.org/wiki/Garbled_circuit [news359 delbrag]: /en/newsletters/2025/06/20/#improvements-to-bitvm-style-contracts [news339 blocksxor]: /en/newsletters/2025/01/31/#how-does-the-blocksxor-switch-that-obfuscates-the-blocks-dat-files-work +[news99 ipc]: /en/newsletters/2020/05/27/#bitcoin-core-18677 +[news147 ipc]: /en/newsletters/2021/05/05/#bitcoin-core-19160 +[news320 ipc]: /en/newsletters/2024/09/13/#bitcoin-core-30509 +[news324 ipc]: /en/newsletters/2024/10/04/#bitcoin-core-30510 +[news319 ban]: /en/newsletters/2024/09/06/#lnd-9009 From 46fc20ef38bfdd8877eecfd3f667e421826cf72f Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Fri, 29 Aug 2025 05:11:37 -0500 Subject: [PATCH 227/278] News369: add topics --- _posts/en/newsletters/2025-08-29-newsletter.md | 4 ++-- _topics/en/acc.md | 3 +++ _topics/en/splicing.md | 3 +++ 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/_posts/en/newsletters/2025-08-29-newsletter.md b/_posts/en/newsletters/2025-08-29-newsletter.md index d04f4aac11..ac88e8d4a7 100644 --- a/_posts/en/newsletters/2025-08-29-newsletter.md +++ b/_posts/en/newsletters/2025-08-29-newsletter.md @@ -109,7 +109,7 @@ repo], and [BINANAs][binana repo]._ manages and submits block templates to experiment with the multiprocess layout without custom builds. For additional context on the multiprocess project and the `bitcoin-node` binary, see Newsletters [#99][news99 ipc], [#147][news147 - ipc], [#320][news320 ipc], [#324][news324 ipc]. + ipc], [#320][news320 ipc], [#323][news323 ipc]. - [LDK #3979][] adds splice-out support, enabling an LDK node to both initiate a splice-out transaction, and accept requests from a counterparty. This @@ -148,5 +148,5 @@ repo], and [BINANAs][binana repo]._ [news99 ipc]: /en/newsletters/2020/05/27/#bitcoin-core-18677 [news147 ipc]: /en/newsletters/2021/05/05/#bitcoin-core-19160 [news320 ipc]: /en/newsletters/2024/09/13/#bitcoin-core-30509 -[news324 ipc]: /en/newsletters/2024/10/04/#bitcoin-core-30510 +[news323 ipc]: /en/newsletters/2024/10/04/#bitcoin-core-30510 [news319 ban]: /en/newsletters/2024/09/06/#lnd-9009 diff --git a/_topics/en/acc.md b/_topics/en/acc.md index da58c519dc..80199b71b0 100644 --- a/_topics/en/acc.md +++ b/_topics/en/acc.md @@ -73,6 +73,9 @@ optech_mentions: - title: "Continued discussion about CTV+CSFS advantages for BitVM" url: /en/newsletters/2025/07/04/#continued-discussion-about-ctv-csfs-advantages-for-bitvm + - title: "Garbled locks for efficient accountable computing contracts" + url: /en/newsletters/2025/08/29/#garbled-locks-for-accountable-computing-contracts + ## Optional. Same format as "primary_sources" above see_also: - title: "Merklize All The Things (MATT)" diff --git a/_topics/en/splicing.md b/_topics/en/splicing.md index dc5dc028ba..cc592e56b9 100644 --- a/_topics/en/splicing.md +++ b/_topics/en/splicing.md @@ -104,6 +104,9 @@ optech_mentions: - title: "Eclair #3103 adds support for dual funding and splicing in simple taproot channels" url: /en/newsletters/2025/08/22/#eclair-3103 + - title: "LDK #3979 adds splice-out support, completing LDK's splicing support" + url: /en/newsletters/2025/08/29/#ldk-3979 + ## Optional. Same format as "primary_sources" above see_also: - title: Interactive transaction construction protocol From 4a7c0fa4f15d04e3322026a66945434ce1acf0d0 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Fri, 29 Aug 2025 05:10:00 -0500 Subject: [PATCH 228/278] News361: fixme cleanups --- _posts/en/newsletters/2025-07-04-newsletter.md | 2 +- _posts/fr/newsletters/2025-07-04-newsletter.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/_posts/en/newsletters/2025-07-04-newsletter.md b/_posts/en/newsletters/2025-07-04-newsletter.md index eb15ad3e3d..28dbd9f6bb 100644 --- a/_posts/en/newsletters/2025-07-04-newsletter.md +++ b/_posts/en/newsletters/2025-07-04-newsletter.md @@ -207,7 +207,7 @@ Bitcoin's consensus rules._ in the onchain transactions themselves (see [Newsletter #255][news255 presig vault state]). Optech believes more advanced vaults could also be recovered from static state, but we had not - verified this by press time. + verified this by press time. - *Responses from Bitcoin Core contributors:* as of this writing, four individuals Optech recognizes as currently active Bitcoin Core diff --git a/_posts/fr/newsletters/2025-07-04-newsletter.md b/_posts/fr/newsletters/2025-07-04-newsletter.md index 28bf26db51..db13a98f2c 100644 --- a/_posts/fr/newsletters/2025-07-04-newsletter.md +++ b/_posts/fr/newsletters/2025-07-04-newsletter.md @@ -183,7 +183,7 @@ règles de consensus de Bitcoin._ parties non déterministes de l'état signé à l'avance dans les transactions onchain elles-mêmes (voir le [Bulletin #255][news255 presig vault state]). Optech croit que les coffres plus avancés pourraient également être récupérés à partir d'un état statique, mais nous n'avions pas vérifié cela avant la - publication. + publication. - *Réponses des contributeurs de Bitcoin Core :* à l'heure où nous écrivons ces lignes, quatre individus qu'Optech reconnaît comme contributeurs actifs de Bitcoin Core ont répondu à la lettre sur @@ -281,7 +281,7 @@ règles de consensus de Bitcoin._ 2. Un hash de la clé publique et du txid de la transaction que le dépensier souhaite éventuellement diffuser, `h(pubkey, txid)`. Cela s'appelle la _preuve dépendante de la séquence_. - 3. Le txid de la transaction éventuelle. Cela s'appelle le _txid d'engagement_. + 3. Le txid de la transaction éventuelle. Cela s'appelle le _txid d'engagement_. Aucune de ces informations ne révèle la clé publique sous-jacente, qui dans ce schéma est supposé être connu uniquement de la personne contrôlant le UTXO. From eddd316d45b2410fe9a24fc76b5b320bf329126b Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 29 Aug 2025 19:51:44 +0900 Subject: [PATCH 229/278] Newsletter-369:Translate into Japanese --- .../ja/newsletters/2025-08-29-newsletter.md | 131 ++++++++++++++++++ 1 file changed, 131 insertions(+) create mode 100644 _posts/ja/newsletters/2025-08-29-newsletter.md diff --git a/_posts/ja/newsletters/2025-08-29-newsletter.md b/_posts/ja/newsletters/2025-08-29-newsletter.md new file mode 100644 index 0000000000..057239208e --- /dev/null +++ b/_posts/ja/newsletters/2025-08-29-newsletter.md @@ -0,0 +1,131 @@ +--- +title: 'Bitcoin Optech Newsletter #369' +permalink: /ja/newsletters/2025/08/29/ +name: 2025-08-29-newsletter-ja +slug: 2025-08-29-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、BitcoinとLN実装の差分ファジングに関する最新情報の共有と、 +アカウンタブルコンピューティングコントラクト用のGarbled Lockに関する新しい論文のリンクを掲載しています。 +また、Bitcoin Stack Exchangeで人気の質問とその回答や、 +新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき更新など +恒例のセクションも含まれています。 + +## ニュース + +- **BitcoinとLN実装の差分ファジングに関する最新情報:** Bruno Garciaは、 + Bitcoinベースのソフトウェアおよびライブラリの[ファジングテスト][fuzz testing]用のライブラリと関連データである + [bitcoinfuzz][]の最新の進捗と成果についてDelving Bitcoinに[投稿しました][garcia fuzz]。 + 成果には、「btcd、rust-bitcoin、rust-miniscript、Embit、Bitcoin Core、 + Core Lightning、[および] LNDなどのプロジェクトで35件以上のバグの発見」が含まれています。 + LN実装間の矛盾の発見は、バグの発見だけでなく、LN仕様の明確化にもつながりました。 + Bitcoinプロジェクトの開発者は、自身のソフトウェアをbitcoinfuzzのサポート対象とすることを検討することをお勧めします。 + +- **アカウンタブルコンピューティング用のGarbled Lock:** + Liam Eagenは、[Garbled Circuit][garbled circuits]に基づく + [アカウンタブルコンピューティングコントラクト][topic acc]を作成するための新しい仕組みに関する + [論文][eagen paper]をBitcoin-Devメーリングリストに[投稿しました][eagen glock]。 + これはBitVMでGarbled Circuitを使用する最近の他の独立した研究（[ニュースレター + #359][news359 delbrag]参照）と類似していますが、異なるものです。 + Eagenの投稿では、「（彼の見解では）単一の署名で不正を証明する初の実用的なGarbled Lockであり、 + BitVM2と比較してオンチェーンデータを550分の1以上削減できる」と主張しています。 + 本稿執筆時点では、この投稿に対する返信はありませんでした。 + +## Bitcoin Stack Exchangeから選ばれたQ&A + +*[Bitcoin Stack Exchange][bitcoin.se]はOptech Contributor達が疑問に対して答えを探しに（もしくは他のユーザーの質問に答える時間がある場合に）アクセスする、 +数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [強力な仮定の下で、集約公開鍵から秘密鍵を復元することは可能ですか？]({{bse}}127723) + Pieter Wuilleは、[MuSig2][topic musig]スクリプトレス[マルチシグ][topic multisignature]に関する + 現状および仮設的なセキュリティ仮定について説明しています。 + +- [すべてのTaprootアドレスは量子コンピューターに対して脆弱ですか？]({{bse}}127660) + Hugo NguyenとMurchは、スクリプトパスのみで使用可能なように構築された[Taproot][topic taproot]アウトプットであっても、 + [量子コンピューター][topic quantum resistance]に対して脆弱であると指摘しています。 + Murchはさらに、「興味深いことに、アウトプットスクリプトを生成した当事者は、 + 内部鍵がNUMSポイントであることを示すことができ、量子コンピューターで復号されたことが証明できるでしょう」と述べています。 + +- [chainstateの難読化鍵はなぜ設定できないのですか？]({{bse}}127814) + Ava Chowは、`blocksdir`のディスク上の内容を難読化する鍵（[ニュースレター #339][news339 blocksxor]参照）は、 + `chainstate`の内容を難読化する鍵（[Bitcoin Core #6650][]参照）とは異なることを指摘しています。 + +- [あるブロック高以降に使用条件を取り消すことは可能ですか？]({{bse}}127683) + Antoine Poinsotは、期限切れの支払い条件、つまり「逆タイムロック」は不可能であり、 + おそらく望ましくさえないことを確認する[以前の回答]({{bse}}122224)を指摘しています。 + +- [IPv4およびIPv6のノードに加えて、Onionノードを使用するようにBitcoin Coreを設定するにはどうしたらいいですか？]({{bse}}127727) + Pieter Wuilleは、`onion`設定オプションの設定はアウトバウンドピア接続にのみ適用されることを明確にしています。 + さらに、インバウンド接続用に[Tor][topic anonymity networks]と`bitcoind`を設定する方法についても概説しています。 + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [Bitcoin Core 29.1rc2][]は、主要なフルノードソフトウェアのメンテナンスバージョンのリリース候補です。 + +- [Core Lightning v25.09rc4][]は、この人気のLNノード実装の新しいメジャーバージョンのリリース候補です。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Bitcoin Core #31802][]は、プロセス間通信（IPC）をデフオルトで有効化（`ENABLE_IPC`）し、 + Windowsを除くすべてのシステムのリリースビルドに`bitcoin-node`および + `bitcoin-gui`マルチプロセスバイナリを追加しました。これにより、 + ブロックテンプレートを作成、管理、送信する外部の[Stratum v2][topic pooled mining]マイニングサービスが、 + カスタムビルドなしでマルチプロセスレイアウトを試すことができます。 + マルチプロセスプロジェクトと`bitcoin-node`バイナリの詳細については、 + ニュースレター[#99][news99 ipc]、[#147][news147 ipc]、[#320][news320 ipc]、 + [#323][news323 ipc]をご覧ください。 + +- [LDK #3979][]は、スプライス・アウトのサポートを追加しました。 + これにより、LDKノードはスプライス・アウトトランザクションを開始するだけでなく、 + 相手方からの要求を受け入れることも可能になります。 + [LDK #3736][]で既にスプライス・インがサポートされているため、 + これでLDKの[スプライシング][topic splicing]実装は完了です。 + このPRでは、`SpliceContribution`列挙型を追加しています。 + これはインとアウトの両方のシナリオをカバーし、手数料とチャネルリザーブ要件を考慮した後の + スプライスアウトトランザクションのアウトプットの金額がユーザーのチャネル残高を超えないことを保証します。 + +- [LND #10102][]は、`gossip.ban-threshold`オプション（デフォルトは100、無効化は0）を追加します。 + これにより、無効な[ゴシップ][topic channel announcements]メッセージを送信したピアを禁止するスコアの閾値を設定できます。 + ピアの禁止システムは以前導入され、[ニュースレター #319][news319 ban]で取り上げています。 + このPRは、バックログゴシップクエリ要求への応答として不要なノードおよび + [チャネルアナウンス][topic channel announcements]メッセージが送信される問題も解決します。 + +- [Rust Bitcoin #4907][]は、`Script`と`ScriptBuf`に新しい汎用タグパラメーター`T`を追加することで + スクリプトのタグ付けを導入し、コンパイル時のロールの安全性のためにシールされた`Tag` + traitでサポートされている型エイリアス `ScriptPubKey`、`ScriptSig`、`RedeemScript`、 + `WitnessScript`および`TapScript`を定義します。 + +{% include snippets/recap-ad.md when="2025-09-02 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31802,3979,10102,4907,6650,3736" %} +[bitcoin core 29.1rc2]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[core lightning v25.09rc4]: https://github.com/ElementsProject/lightning/releases/tag/v25.09rc4 +[garcia fuzz]: https://delvingbitcoin.org/t/the-state-of-bitcoinfuzz/1946 +[bitcoinfuzz]: https://github.com/bitcoinfuzz +[fuzz testing]: https://en.wikipedia.org/wiki/Fuzzing +[eagen glock]: https://mailing-list.bitcoindevs.xyz/bitcoindev/Aq_-LHZtVdSN5nODCryicX2u_X1yAQYurf9UDZXDILq6s4grUOYienc4HH2xFnAohA69I_BzgRCSKdW9OSVlSU9d1HYZLrK7MS_7wdNsLmo=@protonmail.com/ +[eagen paper]: https://eprint.iacr.org/2025/1485 +[garbled circuits]: https://en.wikipedia.org/wiki/Garbled_circuit +[news359 delbrag]: /ja/newsletters/2025/06/20/#bitvm +[news339 blocksxor]: /ja/newsletters/2025/01/31/#blocks-dat-blocksxor +[news99 ipc]: /en/newsletters/2020/05/27/#bitcoin-core-18677 +[news147 ipc]: /ja/newsletters/2021/05/05/#bitcoin-core-19160 +[news320 ipc]: /ja/newsletters/2024/09/13/#bitcoin-core-30509 +[news323 ipc]: /ja/newsletters/2024/10/04/#bitcoin-core-30510 +[news319 ban]: /ja/newsletters/2024/09/06/#lnd-9009 \ No newline at end of file From 9fe68b63abb29cf1a0995cf86a8760e8cce1f4b5 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sat, 30 Aug 2025 14:24:25 +0200 Subject: [PATCH 230/278] Newsletter 369 translate in French (#2479) --- .../fr/newsletters/2025-08-29-newsletter.md | 141 ++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 _posts/fr/newsletters/2025-08-29-newsletter.md diff --git a/_posts/fr/newsletters/2025-08-29-newsletter.md b/_posts/fr/newsletters/2025-08-29-newsletter.md new file mode 100644 index 0000000000..6ce2bb1098 --- /dev/null +++ b/_posts/fr/newsletters/2025-08-29-newsletter.md @@ -0,0 +1,141 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #369' +permalink: /fr/newsletters/2025/08/29/ +name: 2025-08-29-newsletter-fr +slug: 2025-08-29-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine partage une mise à jour sur le fuzzing différentiel des +implémentations de Bitcoin et LN et propose des liens vers un nouveau papier sur les verrous +chiffrés pour les contrats de calcul responsables. +Sont également incluses nos sections régulières résumant les récentes questions et réponses de Bitcoin +Stack Exchange, annoncant de nouvelles versions et des candidats à la publication, ainsi que les +résumés des modifications notables apportées aux logiciels d'infrastructure Bitcoin populaires. + +## Nouvelles + +- **Mise à jour sur le fuzzing différentiel des implémentations de Bitcoin et LN :** + Bruno Garcia a [publié][garcia fuzz] sur Delving Bitcoin pour décrire + les progrès récents et les accomplissements de [bitcoinfuzz][], une bibliothèque et + des données associées pour le [fuzz testing][] de logiciels et + bibliothèques basés sur Bitcoin. Les accomplissements incluent la découverte de "plus de 35 bugs + dans des projets tels que btcd, rust-bitcoin, rust-miniscript, Embit, Bitcoin + Core, Core Lightning, [et] LND." La découverte de divergences entre les implémentations LN n'a pas + seulement révélé des bugs mais a également conduit à des clarifications de la spécification LN. Les + développeurs de projets Bitcoin sont encouragés à envisager de rendre leur logiciel une cible prise + en charge par bitcoinfuzz. + +- **Verrous chiffrés pour les contrats de calcul responsables :** Liam Eagen + a [posté][eagen glock] sur la liste de diffusion Bitcoin-Dev à propos d'un + [papier][eagen paper] qu'il a écrit sur un nouveau mécanisme pour créer + des [contrats de calcul responsables][topic acc] mais basé sur les [circuits chiffrés][]. Cela + est similaire (mais distinct) d'autres travaux récents indépendants sur l'utilisation de circuits + chiffrés pour BitVM (voir le [Bulletin #359][news359 delbrag]). Le post d'Eagen affirme "le premier (à son + avis) verrou chiffré pratique dont la preuve de fraude est une unique + signature, ce qui représente une réduction de plus de 550x des données onchain + comparé à BitVM2." À l'heure actuelle, son post n'a pas reçu de réponses publiques. + +## Questions et réponses sélectionnées de Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] est l'un des premiers endroits où les contributeurs d'Optech +cherchent des réponses à leurs questions---ou quand nous avons quelques moments libres pour aider +les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous mettons en lumière certaines +des questions et réponses les mieux votées postées depuis notre dernière mise à jour.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Est-il possible de récupérer une clé privée à partir d'une clé publique agrégée sous de fortes hypothèses ?]({{bse}}127723) + Pieter Wuille explique les hypothèses de sécurité actuelles et hypothétiques autour + de [MuSig2][topic musig] des [multisignatures][topic multisignature] sans script. + +- [Toutes les adresses taproot sont-elles vulnérables au calcul quantique ?]({{bse}}127660) + Hugo Nguyen et Murch soulignent que même les sorties [taproot][topic taproot] + construites pour être dépensées uniquement en utilisant des chemins de script sont vulnérables + [quantiques][topic quantum resistance]. Murch note ensuite "de façon intéressante, la partie qui + a déjà ajouté le support pour les transactions de splicing permet aux nœuds du réseau + Lightning de rajouter ou de retirer des fonds d'un canal Lightning sans avoir à fermer et à rouvrir + un nouveau canal, rendant ainsi les canaux plus flexibles et moins coûteux à gérer. + +- [Pourquoi ne pouvons-nous pas définir la clé d'obfuscation chainstate ?]({{bse}}127814) + Ava Chow souligne que la clé qui obfusque le contenu sur disque du `blocksdir` (voir le [Bulletin + #339][news339 blocksxor]) n'est pas la même clé qui obfusque le contenu du `chainstate` (voir + [Bitcoin Core #6650][]). + +- [Est-il possible de révoquer une branche de dépense après une hauteur de bloc ?]({{bse}}127683) + Antoine Poinsot pointe vers une [réponse précédente]({{bse}}122224) confirmant que les conditions de + dépense expirantes, ou "inverse timelocks", ne sont pas possibles et peut-être même pas souhaitables. + +- [Configurer Bitcoin Core pour utiliser des nœuds onion en plus des nœuds IPv4 et IPv6 ?]({{bse}}127727) + Pieter Wuille clarifie que la configuration de l'option `onion` s'applique uniquement aux connexions + de pairs sortantes. Il explique ensuite comment configurer [Tor][topic anonymity networks] et + `bitcoind` pour les connexions entrantes. + +## Mises à jour et versions candidates + +_Nouvelles versions et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de mettre à niveau vers les nouvelles versions ou d'aider à tester les versions candidates._ + +- [Bitcoin Core 29.1rc2][] est un candidat à la sortie pour une version de maintenance du logiciel + de nœud complet prédominant. + +- [Core Lightning v25.09rc4][] est un candidat à la sortie pour une nouvelle version majeure de + cette implémentation populaire de nœud LN. + +## Changements notables dans le code et la documentation + +_Changements notables récents dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning +repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], +[Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Propositions d'Amélioration de Bitcoin (BIPs)][bips +repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Inquisition Bitcoin][bitcoin +inquisition repo], et [BINANAs][binana repo]._ + +- [Bitcoin Core #31802][] active par défaut la communication inter-processus (IPC) (`ENABLE_IPC`), + ajoutant les binaires multiprocess `bitcoin-node` et `bitcoin-gui` aux builds de sortie sur tous les + systèmes sauf Windows. Cela permet à un service de minage externe [Stratum v2][topic pooled mining] + qui crée, gère et soumet des modèles de blocs d'expérimenter avec la disposition multiprocess sans + builds personnalisés. Pour plus de contexte sur le projet multiprocess et le binaire `bitcoin-node`, + voir les Bulletins [#99][news99 ipc], [#147][news147 ipc], [#320][news320 ipc], [#323][news323 + ipc]. + +- [LDK #3979][] ajoute le support de splice-out, permettant à un nœud LDK d'initier une transaction + de splice-out, et d'accepter les demandes d'une contrepartie. Ceci complète l'implémentation du + [splicing][topic splicing] par LDK, comme [LDK #3736][] avait + déjà ajouté le support de l'ajout de séquence (splice-in). Cette PR ajoute une énumération + `SpliceContribution` qui couvre les scénarios d'ajout et de retrait de séquence et garantit que les + valeurs de sortie d'une transaction de retrait de séquence (splice-out) ne dépassent pas le solde du + canal de l'utilisateur après avoir pris en compte les frais et les exigences de réserve. + +- [LND #10102][] ajoute une option `gossip.ban-threshold` (100 est la valeur par défaut, 0 le + désactive) qui permet aux utilisateurs de configurer le seuil de score à partir duquel un pair est + banni pour avoir envoyé des messages de [gossip][topic channel announcements] invalides. Le système + d'exclusion de pairs avait été introduit précédemment et décrit dans le [Bulletin #319][news319 ban]. + Cette PR résout également un problème où des messages d'annonce de nœud et de [canal][topic channel + announcements] inutiles étaient envoyés en réponse à une demande de requête de gossip en attente. + +- [Rust Bitcoin #4907][] introduit le marquage de script en ajoutant un nouveau paramètre générique + de tag `T` à `Script` et `ScriptBuf`, et définit les alias de type `ScriptPubKey`, `ScriptSig`, + `RedeemScript`, `WitnessScript`, et `TapScript` qui sont soutenus par un trait `Tag` scellé pour la + sécurité des rôles à la compilation. + +{% include snippets/recap-ad.md when="2025-09-02 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31802,3979,10102,4907,6650,3736" %} +[bitcoin core 29.1rc2]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[core lightning v25.09rc4]: https://github.com/ElementsProject/lightning/releases/tag/v25.09rc4 +[garcia fuzz]: https://delvingbitcoin.org/t/the-state-of-bitcoinfuzz/1946 +[bitcoinfuzz]: https://github.com/bitcoinfuzz +[fuzz testing]: https://en.wikipedia.org/wiki/Fuzzing +[eagen glock]: https://mailing-list.bitcoindevs.xyz/bitcoindev/Aq_-LHZtVdSN5nODCryicX2u_X1yAQYurf9UDZXDILq6s4grUOYienc4HH2xFnAohA69I_BzgRCSKdW9OSVlSU9d1HYZLrK7MS_7wdNsLmo=@protonmail.com/ +[eagen paper]: https://eprint.iacr.org/2025/1485 +[circuits chiffrés]: https://en.wikipedia.org/wiki/Garbled_circuit +[news359 delbrag]: /fr/newsletters/2025/06/20/#ameliorations-des-contrats-de-style-bitvm +[news339 blocksxor]: /fr/newsletters/2025/01/31/#comment-fonctionne-l-interrupteur-blocksxor-qui-obscurcit-les-fichiers-blocks-dat +[news99 ipc]: /en/newsletters/2020/05/27/#bitcoin-core-18677 +[news147 ipc]: /en/newsletters/2021/05/05/#bitcoin-core-19160 +[news320 ipc]: /fr/newsletters/2024/09/13/#bitcoin-core-30509 +[news323 ipc]: /fr/newsletters/2024/10/04/#bitcoin-core-30510 +[news319 ban]: /fr/newsletters/2024/09/06/#lnd-9009 \ No newline at end of file From b038cdf5f834217574c371070edabe9cbf51fbbb Mon Sep 17 00:00:00 2001 From: Octoshi <125779328+cryptozyu@users.noreply.github.com> Date: Mon, 1 Sep 2025 09:33:20 +0800 Subject: [PATCH 231/278] newsletter-366: translate into Chinese (#179) * newsletter-366: translate into Chinese * update format * Apply suggestions from code review Co-authored-by: editor-Ajian <34365188+editor-Ajian@users.noreply.github.com> --------- Co-authored-by: Zhiwei(Jeffrey) Hu Co-authored-by: editor-Ajian <34365188+editor-Ajian@users.noreply.github.com> --- .../zh/newsletters/2025-08-08-newsletter.md | 130 ++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 _posts/zh/newsletters/2025-08-08-newsletter.md diff --git a/_posts/zh/newsletters/2025-08-08-newsletter.md b/_posts/zh/newsletters/2025-08-08-newsletter.md new file mode 100644 index 0000000000..64945b8766 --- /dev/null +++ b/_posts/zh/newsletters/2025-08-08-newsletter.md @@ -0,0 +1,130 @@ +--- +title: 'Bitcoin Optech Newsletter #366' +permalink: /zh/newsletters/2025/08/08/ +name: 2025-08-08-newsletter-zh +slug: 2025-08-08-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的周报公布了 Utreexo 的草案 BIP，总结了关于降低最低交易中继费率的持续讨论，并描述了一个允许节点共享其区块模板以缓解不同交易池策略问题的提案。此外还包括我们的常规部分：总结了 Bitcoin Core PR 审核俱乐部会议、新版本和候选版本的公告，以及对热门比特币基础设施项目的重大变更介绍。我们还包括了对上周周报的更正和对读者的推荐。 + +## 新闻 + +- ******为 Utreexo 提出的草案 BIP：** Calvin Kim 在 Bitcoin-Dev 邮件列表上[发布][kim bips]了他与 Tadge Dryja 和 Davidson Souza 共同撰写的关于 [Utreexo][topic utreexo] 验证模型的三个草案 BIP。[第一个 BIP][ubip1] 指定了 Utreexo 累加器的结构，它允许节点在“仅几千字节”的空间内存储对完整 UTXO 集的易于更新的承诺。[第二个 BIP][ubip2] 指定了全节点如何使用累加器而不是传统的已花费交易输出集（STXO，在早期 Bitcoin Core 和当前 libbitcoin 中使用）或未花费交易输出集（UTXO，在当前 Bitcoin Core 中使用）来验证新区块和交易。[第三个 BIP][ubip3] 指定了对比特币 P2P 协议的更改，以允许传输 Utreexo 验证所需的额外数据。 + + 作者正在寻求概念性审核，并将根据进一步的发展更新草案 BIP。 + +- **关于降低最低中继费率的持续讨论：** Gloria Zhao 在 Delving Bitcoin 上[发布][zhao minfee]了关于将[默认最低中继费率][topic default minimum transaction relay feerates]降低 90% 至 0.1 sat/vbyte 的讨论。她鼓励就这个想法以及它可能如何影响其他软件进行概念性讨论。对于 Bitcoin Core 的具体关注，她链接到了一个 [PR][bitcoin core #33106]。 + +- **对等节点区块模板共享以缓解不同交易池策略的问题：** Anthony Towns 在 Delving Bitcoin 上[发布][towns tempshare]建议全节点对等节点偶尔使用[致密区块中继][topic compact block relay]编码向彼此发送其下一个区块的最新模板。接收对等节点随后可以请求模板中缺失的任何交易，要么将它们添加到本地交易池，要么将它们存储在缓存中。这将允许具有不同交易池策略的对等节点尽管存在差异仍能共享交易。它为之前建议使用_弱区块_的提案提供了替代方案（参见[周报 #299][news299 weak blocks]）。Towns 发布了一个[概念验证实现][towns tempshare poc]。 + +## Bitcoin Core PR 审核俱乐部 + +*在这个月度栏目中，我们总结了最近的 [Bitcoin Core PR 审核俱乐部][Bitcoin Core PR Review Club]会议，重点介绍了一些重要的问题和答案。点击下面的问题可以看到会议中答案的总结。* + +[添加 exportwatchonlywallet RPC 以导出钱包的仅观察版本][review club 32489]是 [achow101][gh achow101] 的一个 PR，它减少了创建仅观察钱包所需的手动工作量。在此更改之前，用户必须通过输入或脚本化 `importdescriptors` RPC 调用、复制地址标签等来完成此操作。 + +除了公共[描述符][topic descriptors]外，导出还包含： +- 必要时包含派生 xpub 的缓存，例如在强化派生路径的情况下 +- 地址簿条目、钱包标志和用户标签 +- 所有历史钱包交易，因此无需重新扫描 + +然后可以使用 `restorewallet` RPC 导入导出的钱包数据库。 + +{% include functions/details-list.md + q0="为什么现有的 `IsRange()`/`IsSingleType()` 信息不能告诉我们描述符是否可以在仅观察端扩展？解释 `CanSelfExpand()` 对于 a）强化 `wpkh(xpub/0h/*)` 路径和 b）`pkh(pubkey)` 描述符的逻辑。" + a0="`IsRange()` 和 `IsSingleType()` 不足够，因为它们不检查强化派生，这需要仅观察钱包中不可用的私钥。添加了 `CanSelfExpand()` 来递归搜索强化路径；如果找到一个，它返回 `false`，表示必须为仅观察钱包导出预填充的缓存以派生地址。`pkh(pubkey)` 描述符不带有范围且没有派生，因此它总是可以自扩展。" + a0link="https://bitcoincore.reviews/32489#l-27" + + q1="`ExportWatchOnlyWallet` 只有在 `!desc->CanSelfExpand()` 时才复制描述符缓存。该缓存中确切存储了什么？不完整的缓存如何影响仅观察钱包上的地址派生？" + a1="缓存存储具有强化派生路径的描述符的 `CExtPubKey` 对象，这些对象在支出钱包上预派生。如果此缓存不完整，仅观察钱包无法派生缺失的地址，因为它缺乏必要的私钥。这将导致它无法看到发送到这些地址的交易，从而导致余额不正确。" + a1link="https://bitcoincore.reviews/32489#l-52" + + q2="导出器设置 `create_flags = GetWalletFlags() | WALLET_FLAG_DISABLE_PRIVATE_KEYS`。为什么要保留原始标志（例如 `AVOID_REUSE`）而不是清除所有内容并重新开始？" + a2="保留标志确保支出钱包和仅观察钱包之间的行为一致性。例如，`AVOID_REUSE` 标志影响哪些币被认为可用于支出。不保留它会导致仅观察钱包报告与主钱包不同的可用余额，从而导致用户困惑。" + a2link="https://bitcoincore.reviews/32489#l-68" + + q3="为什么导出器从源钱包读取定位器并将其逐字写入新钱包，而不是让新钱包从区块 0 开始？" + a3="复制区块定位器是为了告诉新的仅观察钱包从哪里恢复扫描区块链以寻找新交易，防止需要完整重新扫描。" + a3link="https://bitcoincore.reviews/32489#l-93" + + q4="考虑多重签名描述符 `wsh(multi(2,xpub1,xpub2))`。如果一个共同签名者导出仅观察钱包并与第三方共享，与仅给他们描述符字符串相比，该第三方学到了什么新信息？" + a4="仅观察钱包数据包括额外的元数据，如地址簿、钱包标志和币控制标签。对于具有强化派生的钱包，第三方只能通过仅观察钱包导出获得有关历史和未来交易的信息。" + a4link="https://bitcoincore.reviews/32489#l-100" + + q5="在 `wallet_exported_watchonly.py` 中，为什么测试在检查在线/离线对之间的可支出性之前调用 `wallet.keypoolrefill(100)`？" + a5="`keypoolrefill(100)` 调用强制离线（支出）钱包为其强化描述符预派生 100 个密钥，填充其缓存。然后将此缓存包含在导出中，允许在线仅观察钱包生成这 100 个地址。它还确保离线钱包在收到要签名的 PSBT 时会识别这些地址。" + a5link="https://bitcoincore.reviews/32489#l-122" +%} + + +## Optech 推荐 + +[Bitcoin++ Insider][] 已开始发布由读者资助的关于比特币技术主题的新闻。他们的两个免费周报，_Last Week in Bitcoin_ 和 _This Week in Bitcoin Core_，对 Optech 周报的常规读者可能特别有趣。 + +## 新版本和候选版本 + +*热门比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本。* + +- [LND v0.19.3-beta.rc1][] 是这个热门闪电网络节点实现的维护版本的候选版本，包含“重要的错误修复”。最值得注意的是，“一个可选的迁移[...]显著降低了节点的磁盘和内存需求。” + +- [BTCPay Server 2.2.0][] 是这个热门自托管支付解决方案的发布版本。它添加了对钱包策略和 [miniscript][topic miniscript] 的支持，提供了对交易费用管理和监控的额外支持，并包括其他几个新改进和错误修复。 + +- [Bitcoin Core 29.1rc1][] 是主流全节点软件维护版本的候选版本。 + +## 重大的代码和文档变更 + +*本周的重大变更有：[Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface（HWI）][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement Proposals（BIPs）][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo]。* + +- [Bitcoin Core #32941][] 通过在超出限制时启用孤儿池的自动修剪，完成了对 `TxOrphanage` 的全面改革（参见[周报 #364][news364 orphan]）。它为 `maxorphantx` 用户添加了警告，告知他们该选项已过时。此 PR 巩固了机会性一父一子（1p1c）[包中继][topic package relay]。 + +- [Bitcoin Core #31385][] 放宽了 `submitpackage` RPC 的 `package-not-child-with-unconfirmed-parents` 规则，以改进 1p1c [包中继][topic package relay]的使用。包不再需要包含已在节点交易池中的父交易。 + +- [Bitcoin Core #31244][] 实现了 [BIP390][] 中定义的 [MuSig2][topic musig] [描述符][topic descriptors]的解析，这是从具有 MuSig2 聚合密钥的 [taproot][topic taproot] 地址接收和支出输入所必需的。 + +- [Bitcoin Core #30635][] 开始在帮助命令响应中显示 `waitfornewblock`、`waitforblock` 和 `waitforblockheight` RPC，表明它们是为普通用户设计的。此 PR 还向 `waitfornewblock` RPC 添加了一个可选的 `current_tip` 参数，通过指定当前链尖端的区块哈希来缓解竞争条件。 + +- [Bitcoin Core #28944][] 通过在未指定时添加偏移量为随机小数值的[锁定时间][topic timelocks]，为使用 `send` 和 `sendall` RPC 命令发送的交易添加了反[费用狙击][topic fee sniping]保护。 + +- [Eclair #3133][] 将其 [HTLC 背书][topic htlc endorsement]本地对等节点声誉系统（参见[周报 #363][news363 reputation]）扩展到对传出对等节点进行评分，就像对传入对等节点一样。Eclair 现在在转发 HTLC 时会考虑双向的良好声誉，但尚未实施惩罚。对传出对等节点进行评分对于防止沉没攻击（参见[周报 #322][news322 sink]）是必要的，这是一种特定类型的[通道阻塞攻击][topic channel jamming attacks]。 + +- [LND #10097][] 为积压的[gossip][topic channel announcements]请求（`GossipTimestampRange`）引入了异步的、每个对等节点的队列，以消除对等节点一次发送太多请求时的死锁风险。如果对等节点在前一个请求完成之前发送请求，额外的消息会被静默丢弃。添加了新的 `gossip.filter-concurrency` 设置（默认为 5）来限制所有对等节点的并发工作者数量。PR 还添加了解释所有流言速率限制配置设置如何工作的文档。 + +- [LND #9625][] 添加了 `deletecanceledinvoice` RPC 命令（及其 `lncli` 等效命令），允许用户通过提供支付哈希来删除已取消的 [BOLT11][] 发票（参见[周报 #33][news33 canceled]）。 + +- [Rust Bitcoin #4730][] 为[最终警报][final alert]消息添加了 `Alert` 类型包装器，该消息通知运行易受攻击的 Bitcoin Core 版本（0.12.1 之前）的对等节点其警报系统不安全。中本聪引入了警报系统来通知用户重要的网络事件，但它在版本 0.12.1 中已经[退役][retired]了，只留下了最终警报消息。 + +- [BLIPs #55][] 添加了 [BLIP55][] 来指定移动客户端如何通过端点注册 webhook 以从 LSP 接收推送通知。此协议对于客户端在接收[异步支付][topic async payments]时获得通知很有用，最近在 LDK 中实现了（参见[周报 #365][news365 webhook]）。 + +## 更正 + +在[上周的周报][news365 p2qrh]中，我们错误地描述了 [BIP360][]（_支付到抗量子哈希_）的更新版本“完全做出了” Tim Ruffing 在其[最近论文][ruffing paper]中显示安全的更改。BIP360 实际做的是将对基于 SHA256 的默克尔根（加上密钥路径替代选项）的椭圆曲线承诺替换为直接对默克尔根的 SHA256 承诺。Ruffing 的论文显示，如果将抗量子签名方案添加到 [tapscript][topic tapscript] 语言中并禁用密钥路径支出，taproot 在当前使用中是安全的。BIP360 实际要求钱包升级到 taproot 的变体（尽管是一个微不足道的变异），从其变体中消除密钥路径机制，并描述了向其 tapleaf 中使用的脚本语言添加量子抗性签名方案。虽然 Ruffing 的论文不适用于 BIP360 中提出的 taproot 变体，但这个变体的安全性（视作一种承诺时）直接来自默克尔树的安全性。 + +我们为错误道歉，并感谢 Tim Ruffing 通知我们的错误。 + +{% include references.md %} +{% include linkers/issues.md v=2 issues="33106,32941,31385,31244,30635,28944,3133,10097,9625,4730,55" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[bitcoin++ insider]: https://insider.btcpp.dev/ +[news365 p2qrh]: /zh/newsletters/2025/08/01/#security-against-quantum-computers-with-taproot-as-a-commitment-scheme +[zhao minfee]: https://delvingbitcoin.org/t/changing-the-minimum-relay-feerate/1886/ +[towns tempshare]: https://delvingbitcoin.org/t/sharing-block-templates/1906 +[towns tempshare poc]: https://github.com/ajtowns/bitcoin/commit/ee12518a4a5e8932175ee57c8f1ad116f675d089 +[news299 weak blocks]: /zh/newsletters/2024/04/24/#weak-blocks-proof-of-concept-implementation +[ruffing paper]: https://eprint.iacr.org/2025/1307 +[kim bips]: https://mailing-list.bitcoindevs.xyz/bitcoindev/3452b63c-ff2b-4dd9-90ee-83fd9cedcf4an@googlegroups.com/ +[ubip1]: https://github.com/utreexo/biptreexo/blob/7ae65222ba82423c1a3f2edd6396c0e32679aa37/utreexo-accumulator-bip.md +[ubip2]: https://github.com/utreexo/biptreexo/blob/7ae65222ba82423c1a3f2edd6396c0e32679aa37/utreexo-validation-bip.md +[ubip3]: https://github.com/utreexo/biptreexo/blob/7ae65222ba82423c1a3f2edd6396c0e32679aa37/utreexo-p2p-bip.md +[btcpay server 2.2.0]: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.2.0 +[lnd v0.19.3-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta.rc1 +[review club 32489]: https://bitcoincore.reviews/32489 +[gh achow101]: https://github.com/achow101 +[news363 reputation]: /zh/newsletters/2025/07/18/#eclair-2716 +[news322 sink]: /zh/newsletters/2024/09/27/#hybrid-jamming-mitigation-testing-and-changes +[news33 canceled]: /zh/newsletters/2019/02/12/#lnd-2457 +[final alert]: https://bitcoin.org/en/release/v0.14.0#final-alert +[retired]: https://bitcoin.org/en/alert/2016-11-01-alert-retirement#updates +[news365 webhook]: /zh/newsletters/2025/08/01/#ldk-3662 +[news364 orphan]: /zh/newsletters/2025/07/25/#bitcoin-core-31829 From b074c7fb74d144c76f3d63fa8a05e6330e273ec5 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Tue, 2 Sep 2025 14:20:49 -0500 Subject: [PATCH 232/278] Podcast: add 369 recap --- .../en/newsletters/2025-08-29-newsletter.md | 26 +++++++++---------- .../en/podcast/2025-09-02-newsletter-recap.md | 23 ++++++++++++++++ 2 files changed, 36 insertions(+), 13 deletions(-) create mode 100644 _posts/en/podcast/2025-09-02-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-08-29-newsletter.md b/_posts/en/newsletters/2025-08-29-newsletter.md index ac88e8d4a7..f54e9cd49d 100644 --- a/_posts/en/newsletters/2025-08-29-newsletter.md +++ b/_posts/en/newsletters/2025-08-29-newsletter.md @@ -27,7 +27,7 @@ software. implementations has not only revealed bugs but has also driven clarifications to the LN specification. Developers of Bitcoin projects are encouraged to investigate making their software a - supported target for bitcoinfuzz. + supported target for bitcoinfuzz. {% assign timestamp="24:56" %} - **Garbled locks for accountable computing contracts:** Liam Eagen [posted][eagen glock] to the Bitcoin-Dev mailing list about a @@ -39,7 +39,7 @@ software. opinion) practical garbled lock whose fraud proof is a single signature, which represent over a 550x reduction of onchain data compared to BitVM2." As of this writing, his post has not received - any public replies. + any public replies. {% assign timestamp="0:58" %} ## Selected Q&A from Bitcoin Stack Exchange @@ -54,30 +54,30 @@ answers posted since our last update.* - [Is it possible to recover a private key from an aggregate public key under strong assumptions?]({{bse}}127723) Pieter Wuille explains current and hypothetical security assumptions around - [MuSig2][topic musig] scriptless [multisignatures][topic multisignature]. + [MuSig2][topic musig] scriptless [multisignatures][topic multisignature]. {% assign timestamp="39:45" %} - [Are all taproot addresses vulnerable to quantum computing?]({{bse}}127660) Hugo Nguyen and Murch point out that even [taproot][topic taproot] outputs constructed to be spent only using script paths are [quantum][topic quantum resistance] vulnerable. Murch goes on to note "Interestingly, the party that generated the output script would be able to show that the internal key was a - NUMS point and thus prove that a Quantum Decryption has occurred." + NUMS point and thus prove that a Quantum Decryption has occurred." {% assign timestamp="41:24" %} - [Why cant we set the chainstate obfuscation key?]({{bse}}127814) Ava Chow highlights that the key that obfuscates on-disk contents of the `blocksdir` (see [Newsletter #339][news339 blocksxor]) is not the same key that obfuscates the `chainstate` contents (see [Bitcoin Core - #6650][]). + #6650][]). {% assign timestamp="45:20" %} - [Is it possible to revoke a spending branch after a block height?]({{bse}}127683) Antoine Poinsot points to a [previous answer]({{bse}}122224) confirming that expiring spending conditions, or "inverse timelocks", are not possible and - perhaps not even desirable. + perhaps not even desirable. {% assign timestamp="52:09" %} - [Configure Bitcoin Core to use onion nodes in addition to IPv4 and IPv6 nodes?]({{bse}}127727) Pieter Wuille clarifies that setting the `onion` configuration option only applies to outbound peer connections. He goes on to outline how to configure - [Tor][topic anonymity networks] and `bitcoind` for inbound connections. + [Tor][topic anonymity networks] and `bitcoind` for inbound connections. {% assign timestamp="53:45" %} ## Releases and release candidates @@ -86,10 +86,10 @@ projects. Please consider upgrading to new releases or helping to test release candidates._ - [Bitcoin Core 29.1rc2][] is a release candidate for a maintenance - version of the predominant full node software. + version of the predominant full node software. {% assign timestamp="54:22" %} - [Core Lightning v25.09rc4][] is a release candidate for a new major - version of this popular LN node implementation. + version of this popular LN node implementation. {% assign timestamp="56:45" %} ## Notable code and documentation changes @@ -109,7 +109,7 @@ repo], and [BINANAs][binana repo]._ manages and submits block templates to experiment with the multiprocess layout without custom builds. For additional context on the multiprocess project and the `bitcoin-node` binary, see Newsletters [#99][news99 ipc], [#147][news147 - ipc], [#320][news320 ipc], [#323][news323 ipc]. + ipc], [#320][news320 ipc], [#323][news323 ipc]. {% assign timestamp="57:37" %} - [LDK #3979][] adds splice-out support, enabling an LDK node to both initiate a splice-out transaction, and accept requests from a counterparty. This @@ -117,7 +117,7 @@ repo], and [BINANAs][binana repo]._ already added splice-in support. This PR adds a `SpliceContribution` enum that covers both in and out scenarios and ensures that the output values of a splice-out transaction don’t exceed the user’s channel balance after - accounting for fees and reserve requirements. + accounting for fees and reserve requirements. {% assign timestamp="1:04:46" %} - [LND #10102][] adds a `gossip.ban-threshold` option (100 is the default, 0 disables it) that allows users to configure the score threshold at which a @@ -125,12 +125,12 @@ repo], and [BINANAs][binana repo]._ messages. The peer banning system was previously introduced and covered in [Newsletter #319][news319 ban]. This PR also resolves an issue where unnecessary node and [channel announcement][topic channel announcements] - messages were sent in response to a backlog gossip query request. + messages were sent in response to a backlog gossip query request. {% assign timestamp="1:06:19" %} - [Rust Bitcoin #4907][] introduces script tagging by adding a new generic tag parameter `T` to `Script` and `ScriptBuf`, and defines the type aliases `ScriptPubKey`, `ScriptSig`, `RedeemScript`, `WitnessScript`, and `TapScript` - which are backed by a sealed `Tag` trait for compile-time role safety. + which are backed by a sealed `Tag` trait for compile-time role safety. {% assign timestamp="1:07:04" %} {% include snippets/recap-ad.md when="2025-09-02 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-09-02-newsletter-recap.md b/_posts/en/podcast/2025-09-02-newsletter-recap.md new file mode 100644 index 0000000000..e126253882 --- /dev/null +++ b/_posts/en/podcast/2025-09-02-newsletter-recap.md @@ -0,0 +1,23 @@ +--- +title: 'Bitcoin Optech Newsletter #369 Recap Podcast' +permalink: /en/podcast/2025/09/02/ +reference: /en/newsletters/2025/08/29/ +name: 2025-09-02-recap +slug: 2025-09-02-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt are joined by Bruno Garcia and Liam Eagen to discuss [Newsletter #369]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-8-2/406746775-44100-2-88a2598fae782.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From aa0c76b2933d051ef894cff638b1dd0b300437e5 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Wed, 3 Sep 2025 23:19:23 +0200 Subject: [PATCH 233/278] German translation for Newsletter #369 (#2482) * German translation for Newsletter #369 * fix broken link * Update _posts/de/newsletters/2025-08-29-newsletter.md Co-authored-by: garfiel-d * Update _posts/de/newsletters/2025-08-29-newsletter.md Co-authored-by: garfiel-d --------- Co-authored-by: garfiel-d --- .../de/newsletters/2025-08-29-newsletter.md | 144 ++++++++++++++++++ 1 file changed, 144 insertions(+) create mode 100644 _posts/de/newsletters/2025-08-29-newsletter.md diff --git a/_posts/de/newsletters/2025-08-29-newsletter.md b/_posts/de/newsletters/2025-08-29-newsletter.md new file mode 100644 index 0000000000..d3d6c151b3 --- /dev/null +++ b/_posts/de/newsletters/2025-08-29-newsletter.md @@ -0,0 +1,144 @@ +--- +title: 'Bitcoin Optech Newsletter #369' +permalink: /de/newsletters/2025/08/29/ +name: 2025-08-29-newsletter-de +slug: 2025-08-29-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche enthält ein Update zum differenziellen Fuzzing +von Bitcoin- und LN-Implementierungen und verweist auf eine neue Arbeit +zu "garbled locks" für nachvollziehbare Computing-Verträge. Außerdem +enthalten sind unsere regelmäßigen Abschnitte mit beliebten Fragen und +Antworten aus Bitcoin Stack Exchange, Ankündigungen neuer Releases und +Release-Kandidaten sowie einer Zusammenfassung bedeutender Änderungen +an wichtiger Bitcoin-Infrastruktur-Software. + +## Nachrichten + +- **Update zum differenziellen Fuzzing von Bitcoin- und LN-Implementierungen:** + Bruno Garcia [berichtete][garcia fuzz] in Delving Bitcoin über aktuelle + Fortschritte und Ergebnisse von [bitcoinfuzz][], einer Bibliothek und + zugehörigen Daten für [fuzz testing][] von Bitcoin-basierter Software und + Bibliotheken. Zu den Erfolgen zählt die Entdeckung von "über 35 Bugs in + Projekten wie btcd, rust-bitcoin, rust-miniscript, Embit, Bitcoin Core, + Core Lightning und LND". Gefundene Unterschiede zwischen LN-Implementierungen + haben nicht nur Fehler aufgedeckt, sondern auch zu Klarstellungen in der + LN-Spezifikation geführt. Entwickler von Bitcoin-Projekten werden ermutigt, + ihre Software als unterstütztes Ziel für bitcoinfuzz zu prüfen. + +- **Garbled Locks für nachvollziehbare Computing-Verträge:** Liam Eagen + [stellte][eagen glock] in der Bitcoin-Dev-Mailingliste eine + [Arbeit][eagen paper] zu einem neuen Mechanismus für die Erstellung von + [nachvollziehbaren Computing-Verträgen][topic acc] vor, der auf + [garbled circuits][] basiert. Dies ähnelt (ist aber verschieden von) + anderen aktuellen Arbeiten zu Garbled Circuits für BitVM (siehe + [Newsletter #359][news359 delbrag]). Eagen behauptet, dass sein Ansatz + "das erste (seiner Meinung nach) praktische Garbled Lock ist, dessen + Betrugsnachweis eine einzelne Signatur ist, was eine über 550-fache + Reduktion der Onchain-Daten gegenüber BitVM2 bedeutet." Zum Zeitpunkt + des Schreibens gab es noch keine öffentlichen Antworten auf seinen Post. + +## Ausgewählte Fragen & Antworten von Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] ist eine der ersten Anlaufstellen für +Optech-Mitwirkende, wenn sie Antworten auf ihre Fragen suchen – oder wenn wir +ein paar freie Minuten haben, um neugierigen oder ratlosen Nutzern zu helfen. +In dieser monatlichen Rubrik heben wir einige der am höchsten bewerteten Fragen +und Antworten hervor, die seit unserem letzten Update gepostet wurden.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + + - [Ist es möglich, einen privaten Schlüssel aus einem aggregierten öffentlichen Schlüssel unter starken Annahmen wiederherzustellen?]({{bse}}127723) + Pieter Wuille erläutert aktuelle und hypothetische Sicherheitsannahmen rund um + [MuSig2][topic musig] scriptless [Multisignaturen][topic multisignature]. + + - [Sind alle Taproot-Adressen anfällig für Quantencomputing?]({{bse}}127660) + Hugo Nguyen und Murch weisen darauf hin, dass selbst [Taproot][topic taproot]-Outputs, + die nur über Skriptpfade ausgegeben werden können, gegenüber [Quanten][topic quantum resistance] + verwundbar sind. Murch merkt an: "Interessanterweise könnte die Partei, die das Output-Skript + erzeugt hat, zeigen, dass der interne Schlüssel ein NUMS-Punkt war und damit beweisen, + dass eine Quantenentschlüsselung stattgefunden hat." + + - [Warum kann man den Chainstate-Verschlüsselungsschlüssel nicht setzen?]({{bse}}127814) + Ava Chow hebt hervor, dass der Schlüssel, der die Inhalte des `blocksdir` auf der Festplatte + verschleiert (siehe [Newsletter #339][news339 blocksxor]), nicht derselbe ist wie der Schlüssel, + der die Inhalte von `chainstate` verschleiert (siehe [Bitcoin Core #6650][]). + + - [Ist es möglich, einen Ausgabepfad nach einer Blockhöhe zu widerrufen?]({{bse}}127683) + Antoine Poinsot verweist auf eine [frühere Antwort]({{bse}}122224), die bestätigt, + dass auslaufende Ausgabebedingungen oder "inverse Timelocks" nicht möglich und + vielleicht auch nicht wünschenswert sind. + + - [Bitcoin Core so konfigurieren, dass Onion-Nodes zusätzlich zu IPv4- und IPv6-Nodes verwendet werden?]({{bse}}127727) + Pieter Wuille stellt klar, dass die Einstellung der Option `onion` nur für ausgehende Peer-Verbindungen gilt. + Er beschreibt außerdem, wie [Tor][topic anonymity networks] und `bitcoind` für eingehende Verbindungen + konfiguriert werden können. + +## Releases und Release-Kandidaten + +_Neue Releases und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. +Bitte erwägen Sie, auf neue Versionen zu aktualisieren oder bei der Testung von +Release-Kandidaten zu helfen._ + + - [Bitcoin Core 29.1rc2][] ist ein Release-Kandidat für eine Wartungsversion + der führenden Full-Node-Software. + + - [Core Lightning v25.09rc4][] ist ein Release-Kandidat für eine neue Hauptversion + dieser beliebten LN-Knoten-Implementierung. + +## Wichtige Code- und Dokumentationsänderungen + +_Wichtige aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], +[Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], +[Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], +[BDK][bdk repo], [BIPs][bips repo], [BOLTs][bolts repo], [BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] +und [BINANAs][binana repo]._ + + - [Bitcoin Core #31802][] aktiviert standardmäßig die Interprozesskommunikation (IPC) + (`ENABLE_IPC`) und fügt die Multiprozess-Binaries `bitcoin-node` und `bitcoin-gui` + zu den Release-Builds auf allen Systemen außer Windows hinzu. Dadurch kann ein externer + [Stratum v2][topic pooled mining]-Mining-Service, der Block-Templates erstellt, verwaltet und + einreicht, mit dem Multiprozess-Layout experimentieren, ohne eigene Builds zu benötigen. + Weitere Informationen zum Multiprozess-Projekt und zum `bitcoin-node`-Binary finden sich in den + Newslettern [#99][news99 ipc], [#147][news147 ipc], [#320][news320 ipc] und [#323][news323 ipc]. + + - [LDK #3979][] fügt Unterstützung für Splice-Out hinzu und ermöglicht einem LDK-Knoten, + sowohl eine Splice-Out-Transaktion zu initiieren als auch Anfragen von Gegenparteien zu akzeptieren. + Damit ist die [Splicing][topic splicing]-Implementierung in LDK abgeschlossen, da [LDK #3736][] + bereits Splice-In-Unterstützung hinzugefügt hat. Der PR führt ein `SpliceContribution`-Enum ein, + das sowohl In- als auch Out-Szenarien abdeckt und sicherstellt, dass die Output-Werte einer + Splice-Out-Transaktion nach Abzug von Gebühren und Reserven den Kanal-Saldo nicht überschreiten. + + - [LND #10102][] fügt eine Option `gossip.ban-threshold` hinzu (Standardwert 100, 0 deaktiviert), + mit der Nutzer den Schwellenwert konfigurieren können, ab dem ein Peer für das Senden ungültiger + [Gossip][topic channel announcements]-Nachrichten gebannt wird. Das Peer-Banning-System wurde + zuvor eingeführt und in [Newsletter #319][news319 ban] behandelt. Der PR behebt außerdem ein + Problem, bei dem unnötige Node- und [Kanal Announcement][topic channel announcements]-Nachrichten + als Antwort auf eine Backlog-Gossip-Abfrage gesendet wurden. + + - [Rust Bitcoin #4907][] führt Script-Tagging ein, indem ein generischer Tag-Parameter `T` + zu `Script` und `ScriptBuf` hinzugefügt wird. Es werden die Typ-Aliase `ScriptPubKey`, + `ScriptSig`, `RedeemScript`, `WitnessScript` und `TapScript` definiert, die durch ein + versiegeltes `Tag`-Trait für Kompilierzeit-Rollensicherheit abgesichert sind. + +{% include snippets/recap-ad.md when="2025-09-02 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31802,3979,10102,4907,6650,3736" %} +[bitcoin core 29.1rc2]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[core lightning v25.09rc4]: https://github.com/ElementsProject/lightning/releases/tag/v25.09rc4 +[garcia fuzz]: https://delvingbitcoin.org/t/the-state-of-bitcoinfuzz/1946 +[bitcoinfuzz]: https://github.com/bitcoinfuzz +[fuzz testing]: https://en.wikipedia.org/wiki/Fuzzing +[eagen glock]: https://mailing-list.bitcoindevs.xyz/bitcoindev/Aq_-LHZtVdSN5nODCryicX2u_X1yAQYurf9UDZXDILq6s4grUOYienc4HH2xFnAohA69I_BzgRCSKdW9OSVlSU9d1HYZLrK7MS_7wdNsLmo=@protonmail.com/ +[eagen paper]: https://eprint.iacr.org/2025/1485 +[garbled circuits]: https://en.wikipedia.org/wiki/Garbled_circuit +[news359 delbrag]: /de/newsletters/2025/06/20/#verbesserungen-bei-bitvm-artigen-vertragen +[news339 blocksxor]: /de/newsletters/2025/01/31/#wie-funktioniert-der-blocksxor-schalter-der-die-blocks-dat-dateien-verschleiert +[news99 ipc]: /en/newsletters/2020/05/27/#bitcoin-core-18677 +[news147 ipc]: /en/newsletters/2021/05/05/#bitcoin-core-19160 +[news320 ipc]: /en/newsletters/2024/09/13/#bitcoin-core-30509 +[news323 ipc]: /en/newsletters/2024/10/04/#bitcoin-core-30510 +[news319 ban]: /en/newsletters/2024/09/06/#lnd-9009 From 59c47f8c9c1ebafc31c6b9bc8f5f49e86ecd1783 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Wed, 3 Sep 2025 14:30:16 -1000 Subject: [PATCH 234/278] Newsletters: add 370 (2025-09-05] --- .../en/newsletters/2025-09-05-newsletter.md | 112 ++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 _posts/en/newsletters/2025-09-05-newsletter.md diff --git a/_posts/en/newsletters/2025-09-05-newsletter.md b/_posts/en/newsletters/2025-09-05-newsletter.md new file mode 100644 index 0000000000..d7f41b4cae --- /dev/null +++ b/_posts/en/newsletters/2025-09-05-newsletter.md @@ -0,0 +1,112 @@ +--- +title: 'Bitcoin Optech Newsletter #370' +permalink: /en/newsletters/2025/09/05/ +name: 2025-09-05-newsletter +slug: 2025-09-05-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter includes our regular sections summarizing +discussion about changing Bitcoin's consensus rules, announcing new +release and release candidates, and describing notable changes to +popular Bitcoin infrastructure software. + +## News + +_No significant news this week was found in any of our [sources][optech sources]._ + +## Changing consensus + +_A monthly section summarizing proposals and discussion about changing +Bitcoin's consensus rules._ + +- **Details about the design of Simplicity:** Russell O'Connor made + three posts ([1][sim1], [2][sim2], [3][sim3]) so far to Delving + Bitcoin about "the philosophy and design of the [Simplicity + language][topic simplicity]." The posts examine "the three major + forms of composition for transforming basic operations into complex + operations," "Simplicity’s type system, combinators, and basic + expressions," and "how to build logical operations starting from bits + [...up to...] cryptographic operations, such as SHA-256 and Schnorr + signature validation, using just our computational Simplicity + combinators." + + The most recent post indicates further entries in the series are + expected. + +- **Draft BIP for adding elliptic curve operations to tapscript:** + Olaoluwa Osuntokun [posted][osuntokun ec] to the Bitcoin-Dev mailing + list a link to a [draft BIP][osuntokun bip] for adding several opcodes + to [tapscript][topic tapscript] that will allow elliptic curve + operations to be performed on the script evaluation stack. The + opcodes are intended to be used in combination with introspection + opcodes to create or enhance [covenant][topic covenants] protocols in + addition to other advances. + + Jeremy Rubin [replied][rubin ec1] to suggest additional opcodes to + enable additional features, as well as [other opcodes][rubin ec2] that + would make it more convenient to use some features provided by the + base proposal. + +- **Draft BIP for OP_TWEAKADD:** Jeremy Rubin [posted][rubin ta1] to the + Bitcoin-Dev mailing list a link a [draft BIP][rubin bip] to add + `OP_TWEAKADD` to [tapscript][topic tapscript]. He separately + [posted][rubin ta2] notable examples of scripts enabled by the + addition of the opcode, which include a script to reveal a + [taproot][topic taproot] tweak, proof of order of signing a + transaction (e.g., Alice must have signed before Bob), and [signing + delegation][topic signer delegation]. + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [Core Lightning v25.09][] is a release of a new major + version of this popular LN node implementation. It adds support to + the `xpay` command for paying [BIP353][] addresses and simple + [offers][topic offers], offers improved bookkeeper support, provides + better plugin dependency management, and includes other new features + and bug fixes. + +- [Bitcoin Core 29.1rc2][] is a release candidate for a maintenance + version of the predominant full node software. + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [LDK #3726][] Improve privacy for Blinded Message Paths using Dummy Hops + +- [LDK #4019][] Integrate Splicing with Quiescence + +- [LND #9455][] discovery+lnwire: add support for DNS host name in NodeAnnouncement msg + +- [LND #10103][] Rate limit outgoing gossip bandwidth by peer + +- [HWI #795][] Fix CI + +{% include snippets/recap-ad.md when="2025-09-09 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="3726,4019,9455,10103,795" %} +[bitcoin core 29.1rc2]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[core lightning v25.09]: https://github.com/ElementsProject/lightning/releases/tag/v25.09 +[sim1]: https://delvingbitcoin.org/t/delving-simplicity-part-three-fundamental-ways-of-combining-computations/1902 +[sim2]: https://delvingbitcoin.org/t/delving-simplicity-part-combinator-completeness-of-simplicity/1935 +[sim3]: https://delvingbitcoin.org/t/delving-simplicity-part-building-data-types/1956 +[osuntokun ec]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAO3Pvs-Cwj=5vJgBfDqZGtvmoYPMrpKYFAYHRb_EqJ5i0PG0cA@mail.gmail.com/ +[osuntokun bip]: https://github.com/bitcoin/bips/pull/1945 +[rubin ec1]: https://mailing-list.bitcoindevs.xyz/bitcoindev/f118d974-8fd5-42b8-9105-57e215d8a14an@googlegroups.com/ +[rubin ec2]: https://mailing-list.bitcoindevs.xyz/bitcoindev/1c2539ba-d937-4a0f-b50a-5b16809322a8n@googlegroups.com/ +[rubin ta1]: https://mailing-list.bitcoindevs.xyz/bitcoindev/bc9ff794-b11e-47bc-8840-55b2bae22cf0n@googlegroups.com/ +[rubin ta2]: https://mailing-list.bitcoindevs.xyz/bitcoindev/c51c489c-9417-4a60-b642-f819ccb07b15n@googlegroups.com/ +[rubin bip]: https://github.com/bitcoin/bips/pull/1944 From 03df1b2754f2beee7a4eed1f56761a32fe27da1b Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 4 Sep 2025 21:12:11 +0000 Subject: [PATCH 235/278] News370: add merge summaries --- .../en/newsletters/2025-09-05-newsletter.md | 46 +++++++++++++++---- 1 file changed, 36 insertions(+), 10 deletions(-) diff --git a/_posts/en/newsletters/2025-09-05-newsletter.md b/_posts/en/newsletters/2025-09-05-newsletter.md index d7f41b4cae..c0268c846f 100644 --- a/_posts/en/newsletters/2025-09-05-newsletter.md +++ b/_posts/en/newsletters/2025-09-05-newsletter.md @@ -85,19 +85,40 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [LDK #3726][] Improve privacy for Blinded Message Paths using Dummy Hops - -- [LDK #4019][] Integrate Splicing with Quiescence - -- [LND #9455][] discovery+lnwire: add support for DNS host name in NodeAnnouncement msg - -- [LND #10103][] Rate limit outgoing gossip bandwidth by peer - -- [HWI #795][] Fix CI +- [LDK #3726][] adds support for dummy hops on [blinded paths][topic rv + routing], enabling receivers to add arbitrary hops that serve no routing + purpose but act as decoys. A randomized number of dummy hops is added each + time, but is capped at 10 as defined by `MAX_DUMMY_HOPS_COUNT`. Adding + additional hops makes it significantly harder to determine the distance to or + the identity of the receiver node. + +- [LDK #4019][] integrates [splicing][topic splicing] with the [quiescence + protocol][topic channel commitment upgrades] by requiring a quiescent channel + state before initializing a splicing transaction, as mandated by the + specification. + +- [LND #9455][] adds support for associating a valid DNS domain name with a + Lightning node's IP address and public key in its announcement message, as + allowed by the specification and supported by other implementations such as + Eclair and Core Lightning (see Newsletters [#212][news212 dns], [#214][news214 + dns], and [#178][news178 dns]). + +- [LND #10103][] introduces a new `gossip.peer-msg-rate-bytes` option (default + 51200), which limits the outgoing bandwidth used by each peer for outbound + [gossip messages][topic channel announcements]. This value limits the average + bandwidth speed in bytes per second, and if a peer exceeds it, LND will start + queuing and delaying messages sent to that peer. This new option prevents a + single peer from consuming all the global bandwidth defined by + `gossip.msg-rate-bytes` introduced in [LND #10096][]. See Newsletters + [#366][news366 gossip] and [#369][news369 gossip] for related LND work on + gossip requests resource management. + +- [HWI #795][] adds support for the BitBox02 Nova by updating the `bitbox02` + library to version 7.0.0. It also makes several CI updates. {% include snippets/recap-ad.md when="2025-09-09 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="3726,4019,9455,10103,795" %} +{% include linkers/issues.md v=2 issues="3726,4019,9455,10103,795,10096" %} [bitcoin core 29.1rc2]: https://bitcoincore.org/bin/bitcoin-core-29.1/ [core lightning v25.09]: https://github.com/ElementsProject/lightning/releases/tag/v25.09 [sim1]: https://delvingbitcoin.org/t/delving-simplicity-part-three-fundamental-ways-of-combining-computations/1902 @@ -110,3 +131,8 @@ repo], and [BINANAs][binana repo]._ [rubin ta1]: https://mailing-list.bitcoindevs.xyz/bitcoindev/bc9ff794-b11e-47bc-8840-55b2bae22cf0n@googlegroups.com/ [rubin ta2]: https://mailing-list.bitcoindevs.xyz/bitcoindev/c51c489c-9417-4a60-b642-f819ccb07b15n@googlegroups.com/ [rubin bip]: https://github.com/bitcoin/bips/pull/1944 +[news212 dns]: /en/newsletters/2022/08/10/#bolts-911 +[news214 dns]: /en/newsletters/2022/08/24/#eclair-2234 +[news178 dns]: /en/newsletters/2021/12/08/#c-lightning-4829 +[news366 gossip]: /en/newsletters/2025/08/08/#lnd-10097 +[news369 gossip]: /en/newsletters/2025/08/29/#lnd-10102 From d719c485dbc1a786409b243d27f0666bb7575264 Mon Sep 17 00:00:00 2001 From: "Zhiwei(Jeffrey) Hu" Date: Mon, 1 Sep 2025 09:35:27 +0800 Subject: [PATCH 236/278] Newsletter-367: translate into Chinese (#180) --- .../zh/newsletters/2025-08-15-newsletter.md | 44 +++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 _posts/zh/newsletters/2025-08-15-newsletter.md diff --git a/_posts/zh/newsletters/2025-08-15-newsletter.md b/_posts/zh/newsletters/2025-08-15-newsletter.md new file mode 100644 index 0000000000..3d9bc3c502 --- /dev/null +++ b/_posts/zh/newsletters/2025-08-15-newsletter.md @@ -0,0 +1,44 @@ +--- +title: 'Bitcoin Optech Newsletter #367' +permalink: /zh/newsletters/2025/08/15/ +name: 2025-08-15-newsletter-zh +slug: 2025-08-15-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周周报包含我们的常规部分，宣布新的候选发布版本，并总结流行比特币基础设施软件的值得注意的变更。 + +## 新闻 + +_本周在我们的[消息来源][optech sources]中未发现值得注意的新闻。_ + +## 发布与候选发布 + +_流行比特币基础设施项目的新版本与候选版本。请考虑升级至新版本，或帮助测试候选版本。_ + +- [LND v0.19.3-beta.rc1][] 是这个流行闪电网络节点实现的维护版本候选发布，包含“重要的错误修复”。最值得注意的是，“一个可选的迁移[...] 显著降低了节点的磁盘和内存需求。” + +- [Bitcoin Core 29.1rc1][] 是这个主流全节点软件的维护版本的候选发布。 + +## 值得注意的代码与文档变更 + +_[Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案 (BIPs)][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo] 中值得注意的最近变更。_ + +- [Bitcoin Core #33050][] 移除了对共识无效交易的对等节点的阻拦（见[周报 #309][news309 peer]），因为其 DoS 保护是无效的。攻击者可以通过大量发送在转发策略上属于无效的垃圾交易来绕过该保护而不受惩罚。此更新消除了双重脚本验证的需要，因为不再需要把交易失败是从共识还是标准性上进行区分，从而节省 CPU 成本。 + +- [Bitcoin Core #32473][] 为脚本解释器引入了针对传统（例如裸多签）、P2SH、P2WSH（以及偶尔出现的 P2WPKH）输入的每输入签名哈希预计算缓存，以减少标准交易中二次哈希攻击的影响。Core 缓存了一个几乎完成的哈希，该哈希在附加签名哈希字节之前计算，以减少标准多重签名交易和类似模式的重复哈希。同一输入中具有相同签名哈希模式且提交到脚本相同部分的另一个签名可以重用大部分工作。它在策略（交易池）和共识（区块）验证中都启用。[Taproot][topic taproot] 输入默认已具有此行为，因此此更新不需要应用于它们。 + +- [Bitcoin Core #33077][] 创建了一个单体静态库 [`libbitcoinkernel.a`][libbitcoinkernel project]，将其私有依赖项的所有目标文件打包到单个存档中，允许下游项目仅链接到此一个文件。有关相关的 `libsecp256k1` 基础工作，请参见[周报 #360][news360 kernel]。 + +- [Core Lightning #8389][] 在打开通道时使 `channel_type` 字段成为强制性的，与最近的规范更新保持一致（见[周报 #364][news364 spec]）。RPC 命令 `fundchannel` 和 `fundchannel_start` 现在通过零值的 `minimum_depth` 来隐含地告知一个具有[零确认通道][topic zero-conf channels]选项的通道类型。 + +{% include snippets/recap-ad.md when="2025-08-19 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="33050,32473,33077,8389" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[lnd v0.19.3-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta.rc1 +[news309 peer]: /zh/newsletters/2024/06/28/#bitcoin-core-29575 +[news360 kernel]: /zh/newsletters/2025/06/27/#libsecp256k1-1678 +[libbitcoinkernel project]: https://github.com/bitcoin/bitcoin/issues/27587 +[news364 spec]: /zh/newsletters/2025/07/25/#bolts-1232 From fd02748bc83f70155414cbf11d1f696f80368003 Mon Sep 17 00:00:00 2001 From: editor-Ajian <34365188+editor-Ajian@users.noreply.github.com> Date: Fri, 5 Sep 2025 10:42:07 +0800 Subject: [PATCH 237/278] translate #368 into ZH-CN (#181) * translate #368 into ZH-CN * update format * fix typo --------- Co-authored-by: Zhiwei(Jeffrey) Hu --- .../zh/newsletters/2025-08-22-newsletter.md | 108 ++++++++++++++++++ 1 file changed, 108 insertions(+) create mode 100644 _posts/zh/newsletters/2025-08-22-newsletter.md diff --git a/_posts/zh/newsletters/2025-08-22-newsletter.md b/_posts/zh/newsletters/2025-08-22-newsletter.md new file mode 100644 index 0000000000..08608e89ec --- /dev/null +++ b/_posts/zh/newsletters/2025-08-22-newsletter.md @@ -0,0 +1,108 @@ +--- +title: 'Bitcoin Optech Newsletter #368' +permalink: /zh/newsletters/2025/08/22/ +name: 2025-08-22-newsletter-zh +slug: 2025-08-22-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- + +本周的新闻部分总结一份关于在全节点之间分享区块模板的 BIP 草稿，并宣布了一个允许脚本求值的受信任委托的代码库（包含了比特币原生的脚本语言无法使用的特性）。此外是我们的常规栏目：服务和客户端软件的近期更新介绍、新发行版和候选发行版的公告、流行的比特币基础设施软件的显著变更介绍。 + +## 新闻 + +- **** **区块模板分享的 BIP 草稿**：Anthony Towns 在 Bitcoin-Dev 邮件组中[发帖][towns bipshare]，链接了一份关于让节点能跟对等节点们沟通自己会在尝试挖掘的下一个区块中包含哪些交易的 BIP 的[草稿][towns bipdraft]（关于这个想法，可见[周报 #366][news366 templshare]）。这让节点可以分享自己会在交易池中和挖矿策略中接受、对等节点却（根据其自身的策略）通常会拒绝的交易，从而这些对等节点可以缓存这些交易（最终提高 “[致密区块中继][topic compact block relay]” 的效率）。包含在一个节点的区块模板中的交易通常是该节点已知的最为有利可图的未确认交易，所以之前因为策略原因而拒绝了其中一些交易的对等节点可能也会发现它们值得多加考虑。 + + 这份 BIP 草稿所描述的协议是比较简单的。在初始化一个对等节点连接之后，节点立即发送一条 `sendtemplate` 消息，向对等节点表示自己愿意发送区块模板。此后任何时间，这个对等节点都可以用一条 `gettemplate` 消息来请求一个模板。在响应请求时，该节点回复一条 `template` 消息，包含了一个短交易标识符的列表，这些标识符使用跟 [BIP152][] “致密区块消息” 相同的格式。随后，该对等节点可以在一条 `sendtransactions` 消息中包含交易的短标识符（同样由 BIP 152 规定），从而请求自己想要的交易。这份 BIP 草稿允许模板的大小超出当前区块重量上限的两倍多一些。 + + 一个关于区块模板分享的 Delving Bitcoin [帖子][delshare] 在本周出现了更多的讨论，关于如何提升这一提议的带宽效率。得到讨论的想法包括：仅发送自上一次模板分享以来的[差异][towns templdiff]部分（预计可节约 90% 的带宽）、使用一种[集合调解][jahr templerlay]协议（就像 “[minisketch][topic minisketch]” 所带来的那样，允许高效分享大得多的模板），以及，对模板使用 Golomb-Rice [编码][wuille templgr]（就像 “[致密区块过滤器][topic compact block filters]” 那样，预计可节约 25% 的带宽）。 + +- **脚本求值的受信任委托**：Josh Doman 在 Delving Bitcoin 论坛[发布][doman tee]了一个他编写的代码库，使用一种 *受信任的执行环境* （[TEE][]）、仅在包含 [taproot][topic taproot] 密钥路径的交易满足一个脚本时才签名它。这里的脚本可以包含在当前的比特币上没有激活的操作码，甚至是完全不同形式的脚本（例如 [Simplicity][topic simplicity] 或 [bll][topic bll]）。 + + 这一方法要求用这种脚本接收资金的人信任这个 TEE —— 相信它未来可以签名，并且只会在花费交易满足其承担的脚本时才签名 —— 但这允许使用真实的货币对提议中的比特币新特性运行快速的实验。为了减少对 TEE 的信任同时保持可用，可以包含一个后备花费路径；比如说，一个[时间锁][topic timelocks]花费路径，允许参与者在将资金委托给 TEE 的一年之后单方面花费自己的资金。 + + 这个库设计成使用亚马逊网络服务（AWS）的 Nitro 飞地。 + +## 服务和客户端软件的变更 + +*在这个月度栏目中，我们列出比特币钱包和服务的有趣更新。* + +- **** **ZEUS v0.11.3 发布**：这个 [v0.11.3][zeus v0.11.3] 版本包括了对对等节点管理、[BOLT12][topic offers] 和 “[潜水艇互换][topic submarine swaps]” 特性的提升。 + +- **** **Rust 语言的 Utreexo 资源**：Abdelhamid Bakhta [发布][abdel tweet] 了 “[Utreexo][topic utreexo]” 的 Rust 语言资源，包括非交互的[教育材料][rustreexo webapp]和[WASM 绑定][rustreexo wasm]。 + +- **对等节点观察员工具和行动号召**：0xB10C [公开][b10c blog]了他的 “[peer-observer][peer-observer github]” 项目的动机、架构、代码、支持库和研究成果。他尝试建立 “一个松散的、去中心化的个人团体，分享对观察比特币网络的兴趣。希望是一个能够分享想法、讨论、数据、工具、洞见等等的团体。” + +- **** **基于 Bitcoin Core Kernel 的节点发布**：Bitcoin backbone [发布][bitcoin backbone]，演示了一个使用 [Bitcoin Core Kernel][kernel blog] 作为基础的比特币节点。 + +- **** **SimplicityHL 发布**：[SimplicityHL][simplcityhl github] 是一个类似于 Rust 的变成语言，可以编译成更低层次的 [Simplicity][simplicity] 语言代码（刚刚在 Liquid 侧链上 [激活][simplicity post]）。想了解更多，请看 [相关的 Delving Bitcoin 帖子][simplicityhl delving]。 + +- **** **BTCPay Server 的 LSP 插件**：这个 [LSP 插件][lsp btcpay github] 在 BTCPay Server 中实现了 [BLIP51][] （入账通道规范）的客户端验证特性。 + +- **** **Proto 的挖矿软硬件发布**：Proto [发布][proto blog]新的比特币挖矿硬件和开源的挖矿软件，吸收了[社区反馈][news260 mdk]。 + +- **** **使用 CSFS 的断言机解析演示**：Abdelhamid Bakhta [发布][abdel tweet2]了一个使用 [CSFS][topic op_checksigfromstack]、nostr 和 MutinyNet 来签名一个事件的结果的见证消息的断言机。 + +- **** **Relai 添加了 taproot 支持**：Relai 现在支持发送到 [taproot][topic taproot] 地址。 + +## 发行和候选发行 + +*热门的比特币基础设施项目的新版本和候选版本。请考虑升级到新版本，或帮助测试候选版本。* + +- [LND v0.19.3-beta][] 是这个热门的闪电节点实现的一个维护版本的候选发行，包含了 “重要的 bug 修复”。最重要的是，“一个可选的迁移选项 …… 显著降低了节点的磁盘和内存要求”。 + +- [Bitcoin Core 29.1rc1][] 是这个主流全节点软件的维护版本的候选发行。 + +- [Core Lightning v25.09rc2][] 是这个流行的闪电节点实现的一个新的主要版本的候选发行。 + +## 显著的代码和说明书变更 + +*本周出现重大变更的有：[Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement Proposals (BIPs)][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo]。* + +- [Bitcoin Core #32896][] 向下列 RPC 添加了一个 `version` 参数：`createrawtransaction`、`createpsbt`、`send`、`sendall` 、 `walletcreatefundedpsbt`；从而支持创建和花费未确认的 “拓扑受限直至确认（[TRUC][topic v3 transaction relay]）” 交易。钱包软件会强制实施 TRUC 交易在重量上限、手足冲突上的限制，并处理未确认 TRUC 交易和非 TRUC 交易之间的不兼容性。 + +- [Bitcoin Core #33106][] 将默认的 `blockmintxfee` 降低到 1 聪/kvB（也是可能的最低值），而默认的 [`minrelaytxfee`][topic default minimum transaction relay feerates]（最低转发费率）和 `incrementalrelayfee`（手续费追加最低幅度） 则降低到 100 聪/kvB（0.1 聪/vB）。不过，这些数值是可以配置的，用户得到的建议是同时调整 `minrelaytxfee` 和 `incrementalrelayfee` 这两个数值。其他最低费率保持不变，但默认的钱包最低费率预计会在下一个版本中调降。这一变更的动机有：包含低于 1 聪/vB 费率交易的区块的数量显著增加、挖掘这些交易的矿池的数量显著增加，以及比特币对其他货币汇率的上升。 + +- [Core Lightning #8467][] 延申了 `xpay`（详见 [周报 #330][news330 xpay]），支持支付给 [BIP353][] “人类可读域名（HRN）”（例如 satoshi@bitcoin.com），并使之能够直接支付 [BOLT12 offer][topic offers]，消除了需要先运行 `fetchinnoice` 命令的需要。在这背后，`xpay` 会使用来自 `cln-bip353` 插件（在 [Core Lightning #8362][] 引入）的 `fetchbip353` RPC 命令来获取支付指令。 + +- [Core Lightning #8354][] 开始为使用 “多路径支付（[MPP][topic multipath payments]）” 的具体支付碎片的状态发布 `pay_part_start` 和 `pay_part_end` 事件通知。`pay_part_end` 通知说明支付的持续时间，以及它是成功还是失败。如果支付失败，会提供一条报错消息；而且，如果报告错误的洋葱消息没有损害，会给出关于失败的额外信息，例如错误的源头和错误码。 + +- [Eclair #3103][] 加入对 “[简单 taproot 通道][topic simple taproot channels]” 的支持，该特性利用了 [MuSig2][topic musig] 无脚本式[多签名][topic multisignature]来降低交易的重量（节约 15%）并提升交易的隐私性。注资交易和合作式关闭交易将跟其他 [P2TR][topic taproot] 交易没有区别。该 PR 也引入对简单 taproot 通道的 “[双向注资][topic dual funding]” 和 “[通道拼接][topic splicing]” 的支持，并允许启用 “[通道承诺更新][topic channel commitment upgrades]” 特性的通道利用通道拼接交易升级到这种新的 taproot 格式。 + +- [Eclair #3134][] 在给 “[HTLC 背书][topic htlc endorsement]” 下的对等节点声誉评分时，将卡住 [HTLC][topic htlc] 的惩罚权重乘数换成 [CLTV 过期时间差值][topic cltv expiry delta]（详见 [周报 #363][news363 reputation]），以更好地反映一个卡住的 HTLC 会将流动性绑定多长时间。为了缓解使用最大的 CLTV 过期差值的 HTLC 卡住所带来的巨额惩罚，这个 PR 将声誉降级参数（`half-life`）从 15 天变成了 30 天，并将卡住支付的门槛（`max-relay-duration`）从 12 秒变成了 5 分钟。 + +- [LDK #3897][] 拓展了其 “[对等节点存储][topic peer storage]” 实现：通过反序列化对等节点的备份并与本地状态相比较，在备份检索期间探测丢失的通道状态。 + +{% include references.md %} +{% include linkers/issues.md v=2 issues="32896,33106,8467,8354,3103,3134,3897,8362" %} +[bitcoin core 29.1rc1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[lnd v0.19.3-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.3-beta +[core lightning v25.09rc2]: https://github.com/ElementsProject/lightning/releases/tag/v25.09rc2 +[towns bipshare]: https://mailing-list.bitcoindevs.xyz/bitcoindev/aJvZwR_bPeT4LaH6@erisian.com.au/ +[towns bipdraft]: https://github.com/ajtowns/bips/blob/202508-sendtemplate/bip-ajtowns-sendtemplate.md +[news366 templshare]: /zh/newsletters/2025/08/08/#peer-block-template-sharing-to-mitigate-problems-with-divergent-mempool-policies +[delshare]: https://delvingbitcoin.org/t/sharing-block-templates/1906/13 +[towns templdiff]: https://delvingbitcoin.org/t/sharing-block-templates/1906/7 +[jahr templerlay]: https://delvingbitcoin.org/t/sharing-block-templates/1906/6 +[wuille templgr]: https://delvingbitcoin.org/t/sharing-block-templates/1906/9 +[doman tee]: https://delvingbitcoin.org/t/confidential-script-emulate-soft-forks-using-stateless-tees/1918/ +[tee]: https://zh.wikipedia.org/wiki/%E5%8F%AF%E4%BF%A1%E5%9F%B7%E8%A1%8C%E7%92%B0%E5%A2%83 +[news330 xpay]: /zh/newsletters/2024/11/22/#core-lightning-7799 +[news363 reputation]: /zh/newsletters/2025/07/18/#eclair-2716 +[zeus v0.11.3]: https://github.com/ZeusLN/zeus/releases/tag/v0.11.3 +[abdel tweet]: https://x.com/dimahledba/status/1951213485104181669 +[rustreexo webapp]: https://rustreexo-playground.starkwarebitcoin.dev/ +[rustreexo wasm]: https://github.com/AbdelStark/rustreexo-wasm +[b10c blog]: https://b10c.me/projects/024-peer-observer/ +[peer-observer github]: https://github.com/0xB10C/peer-observer +[bitcoin backbone]: https://mailing-list.bitcoindevs.xyz/bitcoindev/9812cde0-7bbb-41a6-8e3b-8a5d446c1b3cn@googlegroups.com +[kernel blog]: https://thecharlatan.ch/Kernel/ +[simplcityhl github]: https://github.com/BlockstreamResearch/SimplicityHL +[simplicity]: https://blockstream.com/simplicity.pdf +[simplicityhl delving]: https://delvingbitcoin.org/t/writing-simplicity-programs-with-simplicityhl/1900 +[simplicity post]: https://blog.blockstream.com/simplicity-launches-on-liquid-mainnet/ +[lsp btcpay github]: https://github.com/MegalithicBTC/BTCPayserver-LSPS1 +[proto blog]: https://proto.xyz/blog/posts/proto-rig-and-proto-fleet-a-paradigm-shift +[news260 mdk]: /zh/newsletters/2023/07/19/#mining-development-kit-call-for-feedback +[abdel tweet2]: https://x.com/dimahledba/status/1946223544234659877 From 17f19683a6093737dba76a54fcff7b4773092049 Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 5 Sep 2025 21:17:36 +0900 Subject: [PATCH 238/278] Newsletter-370:Translate into Japanese --- .../ja/newsletters/2025-09-05-newsletter.md | 117 ++++++++++++++++++ 1 file changed, 117 insertions(+) create mode 100644 _posts/ja/newsletters/2025-09-05-newsletter.md diff --git a/_posts/ja/newsletters/2025-09-05-newsletter.md b/_posts/ja/newsletters/2025-09-05-newsletter.md new file mode 100644 index 0000000000..fa7b611c9e --- /dev/null +++ b/_posts/ja/newsletters/2025-09-05-newsletter.md @@ -0,0 +1,117 @@ +--- +title: 'Bitcoin Optech Newsletter #370' +permalink: /ja/newsletters/2025/09/05/ +name: 2025-09-05-newsletter-ja +slug: 2025-09-05-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- + +今週のニュースレターでは、Bitcoinのコンセンサスルールの変更に関する議論のまとめと、 +新しいリリースとリリース候補の発表、人気のBitcoinインフラストラクチャソフトウェアの注目すべき更新など +恒例のセクションを掲載しています。 + +## ニュース + +_今週は、どの[情報源][optech sources]からも重要なニュースは見つかりませんでした。_ + +## コンセンサスの変更 + +_Bitcoinのコンセンサスルールの変更に関する提案と議論をまとめた月次セクション_ + +- **Simplicityの設計に関する詳細:** Russell O'Connorは、 + 「[Simplicity言語][topic simplicity]の哲学と設計」について、 + これまで3つの投稿（[1][sim1]、[2][sim2]、[3][sim3]）をDelving Bitcoinに投稿しています。 + これらの投稿では、「基本的な演算を複雑な演算に変換するための3つの主要な合成形式」、 + 「Simplicityの型システム、コンビネーター、基本式」、 + そして「計算可能なSimplicityコンビネーターのみを使用して、 + bitからSHA-256やSchnorr署名検証などの暗号演算に至るまでの論理演算を構築する方法」について考察しています。 + + 最新の投稿では、このシリーズの今後の投稿が予定されていることを示しています。 + +- **Tapscriptに楕円曲線の演算を追加するためのBIPドラフト:** + Olaoluwa Osuntokunは、スクリプトの評価スタック上で楕円曲線の演算を実行できるようにする + いくつかのopcodeを[Tapscript][topic tapscript]に追加するための[BIPドラフト][osuntokun bip]のリンクを + Bitcoin-Devメーリングリストに[投稿しました][osuntokun ec]。これらのopcodeは、 + イントロスペクション系のopcodeと組み合わせて使用することで[コベナンツ][topic covenants]プロトコルの作成や強化、 + その他の進化を目的としています。 + + Jeremy Rubinは、追加機能を有効にするための追加opcodeと、 + 提案で提供される機能の一部をより便利にする[他のopcode][rubin ec2]の提案を[しました][rubin ec1]。 + +- **OP_TWEAKADD用のBIPドラフト:** Jeremy Rubinは、 + [Tapscript][topic tapscript]に`OP_TWEAKADD`を追加するための[BIPドラフト][rubin bip]を + Bitcoin-Devメーリングリストに[投稿しました][rubin ta1]。 + また、このopcodeの追加によって有効化されるスクリプトの注目すべきサンプルも[投稿しました][rubin ta2]。 + これには、[Taproot][topic taproot]のtweakを明らかにするスクリプト、 + トランザクションの署名順序の証明（例：アリスはボブより前に署名する必要がある）、 + [署名の委任][topic signer delegation]などが含まれます。 + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [Core Lightning v25.09][]は、この人気のLNノード実装の新しいメジャーバージョンのリリースです。 + このリリースには、[BIP353][]アドレスおよびシンプルな[オファー][topic offers]への支払い用の + `xpay`コマンドのサポートが追加され、ブックキーパーのサポート、 + プラグインの依存関係の管理が改善され、その他の新機能とバグ修正も含まれています。 + +- [Bitcoin Core 29.1rc2][]は、この主要なフルノード実装のメンテナンスバージョンのリリース候補です。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [LDK #3726][]は、[ブラインドパス][topic rv routing]上のダミーホップのサポートを追加しました。 + これにより、受信者はルーティング目的ではなくデコイとして機能する任意のホップを追加できます。 + ダミーホップの数は毎回ランダムに追加されますが、`MAX_DUMMY_HOPS_COUNT`で定義されている10個までに制限されます。 + ホップ数を増やすと、受信者ノードまでの距離やIDの特定が著しく困難になります。 + +- [LDK #4019][]は、仕様で義務付けられているとおり、 + [スプライシング][topic splicing]トランザクションを初期化する前にチャネル状態の静止を要求することで、 + スプライシングと[静止プロトコル][topic channel commitment upgrades]を統合します。 + +- [LND #9455][]は、仕様で許可され、EclairやCore Lightningなどの他の実装でもサポートされているとおり（ + ニュースレター[#212][news212 dns]、[#214][news214 dns]、[#178][news178 dns]参照）、 + 有効なDNSドメイン名をライトニングノードのIPアドレスと公開鍵に関連付ける機能をアナウンスメッセージでサポートしました。 + +- [LND #10103][]では、新しい`gossip.peer-msg-rate-bytes`オプション（デフォルト値は51200）が導入されまました。 + これは、各ピアが送信[ゴシップメッセージ][topic channel announcements]に使用する送信帯域幅を制限します。 + この値は平均帯域幅速度（byte/秒）を制限し、ピアがこの閾値を超過した場合、 + LNDはそのピアへのメッセージをキューに入れて遅延させます。この新しいオプションにより、 + [LND #10096][]で導入された、`gossip.msg-rate-bytes`で定義されたグローバル帯域幅を単一のピアがすべて消費するのを防止します。 + ゴシップリクエストのリソース管理に関するLNDの関連作業については、 + ニュースレター[#366][news366 gossip]および[#369][news369 gossip]をご覧ください。 + +- [HWI #795][]では、`bitbox02`ライブラリをバージョン 7.0.0にアップグレードすることで + BitBox02 Novaをサポートしました。またいくるかのCLIの更新も行われています。 + +{% include snippets/recap-ad.md when="2025-09-09 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="3726,4019,9455,10103,795,10096" %} +[bitcoin core 29.1rc2]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[core lightning v25.09]: https://github.com/ElementsProject/lightning/releases/tag/v25.09 +[sim1]: https://delvingbitcoin.org/t/delving-simplicity-part-three-fundamental-ways-of-combining-computations/1902 +[sim2]: https://delvingbitcoin.org/t/delving-simplicity-part-combinator-completeness-of-simplicity/1935 +[sim3]: https://delvingbitcoin.org/t/delving-simplicity-part-building-data-types/1956 +[osuntokun ec]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAO3Pvs-Cwj=5vJgBfDqZGtvmoYPMrpKYFAYHRb_EqJ5i0PG0cA@mail.gmail.com/ +[osuntokun bip]: https://github.com/bitcoin/bips/pull/1945 +[rubin ec1]: https://mailing-list.bitcoindevs.xyz/bitcoindev/f118d974-8fd5-42b8-9105-57e215d8a14an@googlegroups.com/ +[rubin ec2]: https://mailing-list.bitcoindevs.xyz/bitcoindev/1c2539ba-d937-4a0f-b50a-5b16809322a8n@googlegroups.com/ +[rubin ta1]: https://mailing-list.bitcoindevs.xyz/bitcoindev/bc9ff794-b11e-47bc-8840-55b2bae22cf0n@googlegroups.com/ +[rubin ta2]: https://mailing-list.bitcoindevs.xyz/bitcoindev/c51c489c-9417-4a60-b642-f819ccb07b15n@googlegroups.com/ +[rubin bip]: https://github.com/bitcoin/bips/pull/1944 +[news212 dns]: /ja/newsletters/2022/08/10/#bolts-911 +[news214 dns]: /ja/newsletters/2022/08/24/#eclair-2234 +[news178 dns]: /ja/newsletters/2021/12/08/#c-lightning-4829 +[news366 gossip]: /ja/newsletters/2025/08/08/#lnd-10097 +[news369 gossip]: /ja/newsletters/2025/08/29/#lnd-10102 +[optech sources]: /ja/internal/sources \ No newline at end of file From b2aad59993831abaa8daa789851031bd655f5acb Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sat, 6 Sep 2025 10:59:09 +0200 Subject: [PATCH 239/278] Create 2025-09-05-newsletter.md --- .../fr/newsletters/2025-09-05-newsletter.md | 122 ++++++++++++++++++ 1 file changed, 122 insertions(+) create mode 100644 _posts/fr/newsletters/2025-09-05-newsletter.md diff --git a/_posts/fr/newsletters/2025-09-05-newsletter.md b/_posts/fr/newsletters/2025-09-05-newsletter.md new file mode 100644 index 0000000000..a882e4441d --- /dev/null +++ b/_posts/fr/newsletters/2025-09-05-newsletter.md @@ -0,0 +1,122 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #370' +permalink: /fr/newsletters/2025/09/05/ +name: 2025-09-05-newsletter-fr +slug: 2025-09-05-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine inclut nos sections régulières résumant les récentes discussions sur +la modification des règles de consensus de Bitcoin, annonçant des mises à jour et des versions candidates, +et décrivant les changements notables dans les projets d'infrastructure Bitcoin populaires. + +## Nouvelles + +_Aucune nouvelle significative n'a été trouvée cette semaine dans aucune de nos [sources][optech +sources]._ + +## Modification du consensus + +_Une nouvelle section mensuelle résumant les propositions et discussions sur la modification des +règles de consensus de Bitcoin._ + +- **Détails sur la conception de Simplicity :** Russell O'Connor a fait trois publications + ([1][sim1], [2][sim2], [3][sim3]) jusqu'à présent sur Delving Bitcoin à propos de "la philosophie et + la conception du langage [Simplicity][topic simplicity]." Les posts examinent "les trois formes + principales de composition pour transformer des opérations basiques en opérations complexes," "le + système de types de Simplicity, les combinateurs, et les expressions basiques," et "comment + construire des opérations logiques à partir de bits [...jusqu'à...] des opérations cryptographiques, + telles que SHA-256 et la validation de signature Schnorr, en utilisant juste nos combinateurs + computationnels de Simplicity." + + Le post le plus récent indique que d'autres entrées dans la série sont attendues. + +- **Brouillon de BIP pour ajouter des opérations sur courbes elliptiques à tapscript :** Olaoluwa + Osuntokun a [publié][osuntokun ec] sur la liste de diffusion Bitcoin-Dev un lien vers un [brouillon + de BIP][osuntokun bip] pour ajouter plusieurs opcodes à [tapscript][topic tapscript] qui permettront + d'effectuer des opérations sur courbes elliptiques sur la pile d'évaluation du script. Les opcodes + sont destinés à être utilisés en combinaison avec des opcodes d'introspection pour créer ou + améliorer les protocoles de [covenant][topic covenants] en plus d'autres avancées. + + Jeremy Rubin a [répondu][rubin ec1] pour suggérer des opcodes supplémentaires pour activer des + fonctionnalités supplémentaires, ainsi que [d'autres opcodes][rubin ec2] qui rendraient plus + pratique l'utilisation de certaines fonctionnalités fournies par la proposition de base. + +- **Brouillon de BIP pour OP_TWEAKADD :** Jeremy Rubin a [publié][rubin ta1] sur la liste de + diffusion Bitcoin-Dev un lien vers un [brouillon de BIP][rubin bip] pour ajouter `OP_TWEAKADD` à + [tapscript][topic tapscript]. Il a séparément [publié][rubin ta2] des exemples notables de scripts + rendus possibles par l'ajout de l'opcode, qui incluent un script pour révéler une modification de + [taproot][topic taproot], une preuve de l'ordre de signature d'une transaction (par exemple, Alice + doit avoir signé avant Bob), et la [délégation de signature][topic signer delegation]. + +## Mises à jour et versions candidates + +_Nouvelles versions et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de mettre à niveau vers les nouvelles versions ou d'aider à tester les versions candidates._ + +- [Core Lightning v25.09][] est une version d'une nouvelle version majeure de cette implémentation + populaire de nœud LN. Elle ajoute le support à la commande `xpay` pour payer les adresses [BIP353][] + et les [offres][topic offers] simples, offre un meilleur support de comptabilité, fournit une + meilleure gestion des dépendances des plugins, et inclut d'autres nouvelles fonctionnalités. + et corrections de bugs. + +- [Bitcoin Core 29.1rc2][] est un candidat à la version pour une version de maintenance du logiciel + de nœud complet prédominant. + +## Changements notables dans le code et la documentation + +_Changements notables récents dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning +repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], +[Interface de Portefeuille Matériel (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [Serveur +BTCPay][btcpay server repo], [BDK][bdk repo], [Propositions d'Amélioration de Bitcoin (BIPs)][bips +repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Inquisition Bitcoin][bitcoin +inquisition repo], et [BINANAs][binana repo]._ + +- [LDK #3726][] ajoute le support pour les sauts fictifs sur les [chemins aveuglés][topic rv + routing], permettant aux récepteurs d'ajouter des sauts arbitraires qui ne servent aucun but de + routage mais agissent comme leurres. Un nombre aléatoire de sauts fictifs est ajouté à chaque fois, + mais est limité à 10 comme défini par `MAX_DUMMY_HOPS_COUNT`. L'ajout de sauts supplémentaires rend + significativement plus difficile la détermination de la distance ou de l'identité du nœud récepteur. + +- [LDK #4019][] intègre le [splicing][topic splicing] avec le [protocole de quiescence][topic + channel commitment upgrades] en exigeant un état de canal quiescent avant d'initialiser une + transaction de splicing, comme le mandate la spécification. + +- [LND #9455][] ajoute le support pour associer un nom de domaine DNS valide à l'adresse IP et à la + clé publique d'un nœud Lightning dans son message d'annonce, comme le permet la spécification et + supporté par d'autres implémentations telles qu'Eclair et Core Lightning (voir les Bulletins + [#212][news212 dns], [#214][news214 dns], et [#178][news178 dns]). + +- [LND #10103][] introduit une nouvelle option `gossip.peer-msg-rate-bytes` (par défaut 51200), qui + limite la bande passante sortante utilisée par chaque pair pour les [messages de gossip][topic + channel announcements] sortants. Cette valeur limite la vitesse moyenne de la bande passante en + octets par seconde, et si un pair la dépasse, LND commencera à mettre en file d'attente et à + retarder les messages envoyés à ce pair. Cette nouvelle option empêche un seul pair de consommer + toute la bande passante globale définie par `gossip.msg-rate-bytes` introduite dans [LND #10096][]. + Voir les Bulletins [#366][news366 gossip] et [#369][news369 gossip] pour les travaux liés de LND + sur la gestion des ressources des demandes de gossip. + +- [HWI #795][] ajoute le support pour le BitBox02 Nova en mettant à jour la bibliothèque `bitbox02` + à la version 7.0.0. Il effectue également plusieurs mises à jour de CI. + +{% include snippets/recap-ad.md when="2025-09-09 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="3726,4019,9455,10103,795,10096" %} +[bitcoin core 29.1rc2]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[core lightning v25.09]: https://github.com/ElementsProject/lightning/releases/tag/v25.09 +[sim1]: https://delvingbitcoin.org/t/delving-simplicity-part-three-fundamental-ways-of-combining-computations/1902 +[sim2]: https://delvingbitcoin.org/t/delving-simplicity-part-combinator-completeness-of-simplicity/1935 +[sim3]: https://delvingbitcoin.org/t/delving-simplicity-part-building-data-types/1956 +[osuntokun ec]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAO3Pvs-Cwj=5vJgBfDqZGtvmoYPMrpKYFAYHRb_EqJ5i0PG0cA@mail.gmail.com/ +[osuntokun bip]: https://github.com/bitcoin/bips/pull/1945 +[rubin ec1]: https://mailing-list.bitcoindevs.xyz/bitcoindev/f118d974-8fd5-42b8-9105-57e215d8a14an@googlegroups.com/ +[rubin ec2]: https://mailing-list.bitcoindevs.xyz/bitcoindev/1c2539ba-d937-4a0f-b50a-5b16809322a8n@googlegroups.com/ +[rubin ta1]: https://mailing-list.bitcoindevs.xyz/bitcoindev/bc9ff794-b11e-47bc-8840-55b2bae22cf0n@googlegroups.com/ +[rubin ta2]: https://mailing-list.bitcoindevs.xyz/bitcoindev/c51c489c-9417-4a60-b642-f819ccb07b15n@googlegroups.com/ +[rubin bip]: https://github.com/bitcoin/bips/pull/1944 +[news212 dns]: /en/newsletters/2022/08/10/#bolts-911 +[news214 dns]: /en/newsletters/2022/08/24/#eclair-2234 +[news178 dns]: /en/newsletters/2021/12/08/#c-lightning-4829 +[news366 gossip]: /fr/newsletters/2025/08/08/#lnd-10097 +[news369 gossip]: /fr/newsletters/2025/08/29/#lnd-10102 From 313d6caadd6a18f8c85887db36f0120046c9abd0 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Mon, 8 Sep 2025 14:09:19 -0500 Subject: [PATCH 240/278] Podcast: add 369 transcription --- .../en/podcast/2025-09-02-newsletter-recap.md | 851 +++++++++++++++++- 1 file changed, 850 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-09-02-newsletter-recap.md b/_posts/en/podcast/2025-09-02-newsletter-recap.md index e126253882..554ff8cd9b 100644 --- a/_posts/en/podcast/2025-09-02-newsletter-recap.md +++ b/_posts/en/podcast/2025-09-02-newsletter-recap.md @@ -18,6 +18,855 @@ Mark “Murch” Erhardt and Mike Schmidt are joined by Bruno Garcia and Liam Ea ## Transcription -_transcription coming soon_ +**Mike Schmidt**: Welcome everyone to Bitcoin Optech Newsletter #369 Recap. +Today, we're going to be talking about the Bitcoin fuzz project; garbled locks +for Bitcoin; and we have Stack Exchange questions touching on quantum, +obfuscating data on disk, and other topics. Murch and I are joined this week by +Bruno, soon to be here. But Liam's with us now. Liam, you want to give a quick +introduction for folks? + +**Liam Eagen**: Sure, yeah. I recently published this paper called, "Glock, +Garbled Locks on Bitcoin". It's kind of like the evolution of the BitVM style +protocols that replaces a lot of onchain complexity with this cryptographic +primitive called a garbled circuit. + +**Mike Schmidt**: And it's got a cool name. + +**Liam Eagen**: Yeah. + +_Garbled locks for accountable computing contracts_ + +**Mike Schmidt**: Well, let's just jump right into it. So, for folks following +along, it's the second news item in the newsletter, which is, "Garbled locks for +accountable computing contracts". And, Liam, you posted this paper to the +Bitcoin-Dev mailing list and you introduced garbled locks, which is a twist on +garbled circuits. And at Optech, we've been referring to this in our Topics as +categorized as accountable computing contracts, including things like BitVM, and +we've spoken a bit about some of the related projects in previous shows. But I +think it would be helpful for you, given this set of topics can be easily lost +on folks, including myself, maybe you can help us understand, what is the big +picture; what are we trying to achieve here; what are these optimistic smart +contract verifications; and how can it be used? And I think we can zoom in from +there, because I think, at least for me, sometimes these things get jumbled up +and there's a new version every so often, thanks to you guys doing all this +research. But maybe you can kind of hone in on it for us so we know what we're +looking at. + +**Liam Eagen**: Yeah, for sure. So, as people may know, probably know, Bitcoin +Script is fairly limited in what it's possible to verify. So, wherein with a +more powerful scripting system, you might be able to sort of directly verify a +zero-knowledge proof on chain, in Bitcoin you cannot. We don't have +zero-knowledge-proof systems that are simple enough to verify within the +constraints of Bitcoin Script. So, I would attribute this to sort of BitVM and +Robin Linus introduced this alternative paradigm where instead of having a smart +contract or a script that's verified directly by the L1, you have a kind of +script that's optimistically executed, meaning we assume that it is run +correctly, and then it's possible for another party to provide a fraud proof. +They can prove that the computation was run incorrectly. + +So, this kind of asymmetry between the complexity of proving something was run +correctly versus something was run incorrectly opens up a lot of possibilities. +And one style of this is BitVM, and then another one is Glock, or these +garbled-circuit-based protocols. So, you can prove that something was run +incorrectly more efficiently than you can check it directly. + +**Mike Schmidt**: I hear these things in the context of bridges and locking +coins and then unlocking them on some higher layer or sidechain or something. +Is that the sort of canonical use case, or are there other use cases? + +**Liam Eagen**: Yeah, I mean in some sense, the bridge use case kind of +encapsulates everything else generically. You could sort of bridge to any +environment where you could do any subset of things. Due to the limitations of +the way the tech works now, there are other interesting use cases. So, in a +bridge, you have to, because of the lack of covenants, use a presigning kind of +federation to sign all of the transactions for the Glock or BitVM game. But in +other applications, this might not be necessary. So, for example, if you were +doing a lending protocol and it was just between a designated borrower and +lender, you wouldn't need a separate presigning committee. You could just have +the borrower and lender co-sign everything themselves. So, in narrow cases +where all the parties are known in advance, you can do a little bit better than +a bridge security. But I would say the bridge is sort of the application +everybody has in mind when they're working on this stuff. + +**Mike Schmidt**: Okay. That's helpful for my high-level questions. Maybe you +want to dig into some of the interesting tech work that you guys have been +working on, or maybe Murch has a question as well. + +**Mark Erhardt**: I mean, maybe to put it into context a little further. So, +generally on Bitcoin, we like to do our smart contracts in a way that we only +prove that they've been run correctly. We don't compute them onchain. So, +Glock is one of these approaches where you put out all of the complexity +offchain and you simply can prove that something was run incorrectly. So, how +much data footprint do we still have? I saw that it was a huge improvement. +The fraud proof is only a single-signature now, which you described as a 550x +smaller, or previously it was 550x bigger, the fraud proof. But how big is the +setup? What's the other part of it? + +**Liam Eagen**: Yeah, there's a bunch of different components. And when you +really start to dig into the system or the schemes, like when you want to make +something, things become more complicated. But just focusing on Glock, you have +to sort of lamport sign essentially a proof, a SNARK, and you have to provide a +fraud proof. So, in the case of BitVM, lamport signing the SNARK, you also have +to lamport sign intermediate states of the computation, which is where a lot of +the savings comes from. And then, in order to provide the fraud proof, you give +this big blob of Bitcoin Script. So, I don't have the numbers on hand, because +they're a bit sensitive to the precise way you instantiate the scheme. + +But you can think of a lamport signature, like we propose in the paper a variant +of lamport signatures that uses adaptor signatures that I think is kind of neat. +And it saves a lot over what people were using previously. But it's like tens +of kilobytes probably to sign a proof, depending on the specifics, and then you +have a fraud proof, it becomes a signature. So, you're replacing in that case, +4 MB with 64 bytes. And if you count all of that, I don't have the calculation +on hand, but then there's a bunch of other additional costs. So, you have to +presign these transaction graphs, because all of these protocols, Glock or +BitVM, have kind of multi-step games that are carried out between, at least in +games like Glock, it'd be like a garbler and an evaluator, or a prover and a +verifier. And that cost, yeah, I don't know, I don't have it on hand. But I +mean, in my opinion, it's manageable, but it's not something you should just +ignore. + +**Mark Erhardt**: So, if you're saying that one part is in the tens of kilobytes +and then there's multiple other parts, it's probably on the range of around a +tenth of a block at least to do one of these? + +**Liam Eagen**: Yeah. Okay, I see. So, the presigning stuff is all offchain. +That doesn't incur onchain costs. So, I think the question is really about the +bridge, like how much data do you actually put onchain if you're going to do a +bridge. And this depends, in the case of Glock, on the number of watchtowers +you have. So, I'll say it like this. When you make a bridge, you are providing +a proof of something. So, the proof has two parts, the proof itself and the +public inputs to the proof, meaning what you're making a proof about. In BitVM, +we can do permissionless challenging for the validity of the proof. So, the +proof itself we can check, it's just like a syntactic property of the proof. +Whether the public inputs are correct is a more complicated question. And right +now, the only way we know how to do this is with a permission set of +challengers. So, in Glock, we have a permission set of challengers for both. +We have a permission set of challengers for the public inputs to the proof, and +we have a permission set of challengers for the proof validity itself. + +The total onchain cost scales with the number of what we call watchtowers, +people who are eligible to challenge for the validity of the proof and the +public inputs. So, I think your estimate is roughly correct. It's like 100-ish +kB, because we have, let's say, 16 watchtowers and, say, 10-ish kB per +watchtower, because they're each lamport signing a proof. So, in the worst +case, this would be the onchain costs, because the fraud proof is negligible, +it's just one signature. But I don't know. I mean, it's also maybe worth +emphasizing that this is in the so-called unhappy path. Like, this only happens +in the case that some party is behaving maliciously. And empirically, this +tends not to be the case with these types of systems. But yeah. + +**Mark Erhardt**: All right. Sorry for the big tangent. Did you want to dive +into more details of how it works and whatever Mike asked? + +**Liam Eagen**: Oh, sorry, I don't know, I think it's fine. So, the BitVM2 +style of protocol as well as Glock, we make this observation that SNARKs are the +universal verification primitive. So, it's sufficient to be able to verify a +SNARK to be able to verify anything. And so, Glock in particular is very, very +tightly coupled with a particular SNARK. The SNARK that we use is a variant of +this SNARK called Pari. And our variant is actually smaller than Pari and is +the smallest known SNARK, which is kind of cool, like an interesting theoretical +development. And so, we have this SNARK and we then instantiate it in what is a +so-called designated verifier paradigm. So, normal SNARKs can be verified by +anyone, but a designated verifier SNARK can only be verified by a designated +verifier. Concretely, this means there's some secret information the verifier +has to know in order to verify the SNARK. And this allows us to get rid of +pairings, which Pari and Groth and the sort of SNARKs people might have heard +of, all require pairings. Because we can get rid of pairings, we can simplify +the verifier circuit quite a bit. + +So, there's a parallel effort by the BitVM Alliance to do a garbled circuit for +Groth. And this is ongoing, but at the moment is quite a bit larger, like +several orders of magnitude more expensive than Glock, in part because they +require pairings. And so, we get rid of pairings, and we're also able to use a +different type of curve that is not pairing-friendly, that arithmetizes better +into a kind of garbled circuit. So, you could kind of imagine by kind of +fiddling with the parameters, we make all the pieces fit together better. And +by making the pieces fit together better, you have maybe four or five levels of +abstraction. And so, you save a factor of 10 at each level and it multiplies up +pretty fast. + +**Mark Erhardt**: Sorry, to jump in briefly. You said Grug is the alternative +approach. I don't think I'm familiar. Could you maybe elaborate in one or two +sentences what that's about? + +**Liam Eagen**: Oh, sure. Yeah. So, Jeremy Rubin has this note on Delbrag, +which introduced the garbled circuits kind of paradigm. And there's this +problem in garbled circuits generally where the garbler, the person who produces +the garbled circuit, might be malicious. So, I, a malicious garbler, might give +you a malformed garbling table so that when you try to evaluate it, you just +fail. And in order for the protocol to be secure, you must succeed. So, we +have to make the protocol maliciously secure. There are a few ways to do this, +and one of them is Grug. And the way Grug works is Inside a garbled circuit, +you have a bunch of logic gates. And if the circuit is malformed, then one of +these gates has to be malformed. And so Grug uses a sort of Bitcoin Script +basically, in a similar way to BitVM2 to slash for malformed gates. So, if +there's a bad gate, you can slash for that. The cost of this is that the +worst-case slashing complexity goes from a single-signature to tens of kilobytes +of Bitcoin Script. So, like, ideally, we would be able to avoid this. +Unfortunately, previous approaches, it was not feasible to do that. + +The other two approaches just worth mentioning for malicious security are +SNARKs, like you can just run a proof that you constructed the garbling table +correctly, but this is too expensive for all of the current approaches. And +then the other one is called Cut and Choose, which is what we use for Glock. +And the heuristic here is you, the garbler, garble about n times; and then me, +the evaluator, I open half of them. And if I detect any faults, then you're +cheating; and if I don't detect any faults, then as long as one of the remaining +ones is valid, I can succeed. So, kind of like you cut a sandwich in half and +then I get to pick your half, or something. + +**Mark Erhardt**: Okay, let me try to break it down a little simpler to show +whether I've understood it correctly. The alternative approach previously did +not depend on a set of watchtowers or otherwise privileged verifier group anyone +would be able to challenge. You're basically introducing a group that have +privileged information and that is required to verify that the setup was +correct, but that allows you to make it magnitudes more efficient because you +can get rid of pairings, which is a property of elliptic curves -- yeah, I think +it's only elliptic curves, right -- that is not used in Bitcoin usually, and +that has cool properties in some ways, but obviously has other downsides. Let's +not dive into that more. Anyway, you get rid of pairings, that makes it much +more efficient, but the trade-off is you require information in order to verify. +So, you have a pre-chosen set of verifiers, which you call watchtowers, and this +makes it much more efficient, and that's pretty cool. + +**Liam Eagen**: Yeah. The one thing I would add, this is like a 'yes and', but +the previous system also requires permissioned watchtowers. So, because you +need permissioned watchtowers to challenge for the public parameters, concretely +this is because the longest chain rule can't be verified objectively. You need +somebody to be able to come in and say, "No, I have a heavier chain", right? +The BitVM2 approaches also require this. So, I would argue that in fact both +systems have permissioned watchtowers. + +**Mark Erhardt**: Right. In the other system, one of the two aspects requires +the pre-chosen verifiers. You're like, "Well, if we have pre-chosen verifiers +anyway, let's just use it for both". That way you get rid of pairings and make +it magnitudes more efficient. I get it. I think I get it, roughly. + +**Mike Schmidt**: Liam, you mentioned there's this new SNARK, this smallest one. +It sounds like there's some novel things going on here. What has the feedback +been from the community? And also maybe, what is the process to vet these or +harden these or get more eyes on these? Maybe talk a little bit about the next +steps after the paper. + +**Liam Eagen**: Yeah, I don't know. I mean, I think I've been pretty happy with +the feedback. I think people have been nice. There's a lot of interest, which +is always really fun for this kind of work. Next steps? So, we're in the +process of implementing it. That's important. The cryptographic work. I think +there's enough novelty in the paper probably for a conference submission, which +is always good to get peer review. I think that, well, I don't know. I mean, +the kind of applied cryptography space for SNARKs and cryptocurrency type stuff +is sort of interesting, because often you get even more eyes on something that +people care about than you would in a conference submission. But yeah, I think +it doesn't hurt to do both. So, that's that. And then, I don't know, I think +of this as a part of a longer chain of work. + +**Mark Erhardt**: Right. If we look at somewhat comparable efforts, MuSig was a +paper first, and then it had an implementation, then there was a bug found in +the paper. There was a second version of it. Ultimately, it took several years +to get fully specced out. It's still being implemented in Bitcoin Core, it's +released in some other Bitcoin clients. So, if this is in process, and I'm not +saying they're super-comparable, but the timeline is in a similar magnitude, +then this is probably a couple of years away or so from a BIP, or maybe a year +away from a BIP and being implemented. Is that roughly right? What would your +gut say? + +**Liam Eagen**: I don't know exactly how this would fit into a BIP. But yeah, +always degrees, right, but fully hardened so to speak, yes, probably at least a +year of continued work. There are a lot of parts, but they're fairly modular, +which makes it I think a bit easier to analyze. And, yeah, the implementation, +I mean it's not even done yet. So, we're going to have the research +implementation and then it'll be like, I don't know, a production quality type +implementation, and then there'll be audits of the implementation and conference +submission of the paper. And so, yeah, I think that's probably right. It's +hard to compare these types of things, but that's probably the right order of +magnitude. + +**Mark Erhardt**: You say you don't know how it would fit into a BIP. Why are +you saying that? Would you say it's not necessary to specify it because it +doesn't require any consensus changes, or do you think it's far enough from +regular Bitcoin Script because it's like tying other systems into Bitcoin, or +what's the connection to it maybe not fitting into a BIP? + +**Mike Schmidt**: Keep in mind, this is a BIP maintainer asking this! + +**Liam Eagen**: I don't know. I mean, yeah, I guess I would defer to you. But +it doesn't touch consensus almost conspicuously, like this whole line of work is +designed to work around, or accommodate the existing consensus structure. And I +don't know. I mean, I also personally suspect this is probably not the final +form that this work will take. It's very, very hot, like it's ongoing. There +will be more improvements and hopefully they sort of build on each other, but I +don't know. I'm not sure it's even really ready. + +**Mark Erhardt**: Yeah. I mean, I wasn't expecting you to write a BIP next +week, but anyway, this is maybe still pie-in-the-sky. All right, I think that's +my questions. Mike or Bruno, did you have something else? + +**Mike Schmidt**: I had something else. Liam, what is the culture around these +different companies and organizations working on similar things like this? Is +it cooperative, like are your peer orgs and other -- you're at Alpen, right? +So, are the other companies excited about this and they're going to do their own +version? What's the IP like here? Is everybody working together? Maybe just +give us a little bit of vibe there. + +**Liam Eagen**: Yeah, so I would say it's very collaborative. There's this +organization called the BitVM Alliance, which was working on a collaborative +implementation of BitVM. Alpen was a part of that, Citrea, a bunch of other +companies in the space, and it still exists. And prior to Glock, they were +working on this Groth16 implementation of garbled circuits. But I don't know, I +mean in terms of IP, I'm a very strong believer in permissive intellectual +property for cryptography especially, but things in general. So, all of this is +like anybody can use it, anybody can work on it, anybody can develop on it, or +trying as much as possible to develop in the open, all open-sourced, as +everything should be. And will other people use this? I don't know. So, this +this also comes down to some sort of complicated trade-off questions, right? +So, I don't know if everybody will use this, but I would like to see that, and I +think there's a lot of interest in it. But yeah, I would say good vibes all +around. + +**Mike Schmidt**: Good to hear. Liam, we've taken up a good chunk of your time. +We appreciate you joining and explaining this for us and answering our +questions. Thanks for joining. + +**Liam Eagen**: Thank you. + +_Update on differential fuzzing of Bitcoin and LN implementations_ + +**Mike Schmidt**: Jumping back up to the previous news item, "Update on +differential fuzzing of Bitcoin and LN implementations", we have another special +guest who has arrived. Bruno, can you introduce yourself briefly, and then I'll +introduce your news item? + +**Bruno Garcia**: Yeah, I'm Bruno, I am a Bitcoin Core Contributor and I'm the +creator of this project, bitcoinfuzz, that does differential fuzzing of Bitcoin +LN implementations. + +**Mike Schmidt**: Awesome. So, specifically, this news item that we covered +this week was around differential fuzzing across Bitcoin and LN implementations +of the Bitcoin LN Protocol. You, Bruno, just recently shared some progress on +bitcoinfuzz, and some of the results are impressive. Over 35 bugs, I think, +were found across things like btcd, Rust Bitcoin, Rust Miniscript, Embit, +Bitcoin Core, Core Lightning (CLN) and LND, if I have those right. Maybe we can +get into some of those bugs and how they were found, but maybe you can just +remind us, what is this differential fuzzing technique? + +**Bruno Garcia**: Differential fuzzing is basically feeding two or more +implementations with the same inputs, and then we can compare the outputs to see +if there's something wrong. So basically, for example, Bitcoin Core has a +miniscript parser and Rust Miniscript has a miniscript parser, so we can send +the same miniscripts for both implementations and we can compare the outputs, +like for example, if the miniscripts are valid or not valid. So, if Bitcoin +Core says that a miniscript is valid, and with the same miniscript, Rust's +miniscript says it's not valid, so something's wrong, basically. + +**Mike Schmidt**: Okay, that makes sense. Are you testing, for example, like +Bitcoin Core's RPC against another node implementation RPC, or are you going +right into the code to test it that way? + +**Bruno Garcia**: No, we don't test RPC. Bitcoinfuzz is more source-code level. +So, compared to, for example, Fuzzamoto, Fuzzamoto is more high level. So, we +run Bitcoin nodes and we call RPC or send P2P messages. And bitcoinfuzz is more +low level, I would say. So, basically, it's source-code level; we call a +function from the code of Bitcoin Core, we call a function from Rust Miniscript, +or other implementations using wrappers. + +**Mike Schmidt**: And this is distinct. We've had you on and folks may remember +you or think of you as the mutation-testing guy. Is this completely separate, +or do you reuse some of the components for each of these approaches? + +**Bruno Garcia**: Yeah, mutation testing is completely different from this +approach. One of the things that I use differential fuzzing with mutation +testing is when I want to know if a mutation is equivalent or not. So, for +example, I change the code, I create a mutator for a code, then I realize that +it wasn't killed; there's no test that killed that mutant. So, I have to +understand, if that mutant should be killed, so we have to improve our tests, or +we can ignore it because it's an equivalent mutant. An equivalent mutant is +basically a mutant that has the same behavior as the original code. It's one of +the challenges of mutation testing. And one of the ways that I found to +understand if a mutant is equivalent or not is basically running differential +fuzzing between the original code and the mutant. So, if I run it for one hour +and I don't find any discrepancy, so okay, it's equivalent. So, it's a paper +that I work at that basically proved that we can use differential fuzzing for +this. But there are different parts, by the way. + +**Mike Schmidt**: Now, what about different versions, like different versions of +Bitcoin Core? Do you do differential fuzzing across implementation versions? +And I guess if you can do that, what about between PRs and the code before that +PR, you know, these sorts of things? + +**Bruno Garcia**: Yeah, this is great. We don't do this right now. I think +Rust Bitcoin does it, if I'm not wrong. But now, bitcoinfuzz has models, so +Rust Bitcoin, Rust Miniscript, Bitcoin Core, btcd. And we build these models +based on commits. So, it's not fixed on a specific release, it's based on +commits. So, we can build bitcoinfuzz using, for example, based on a specific +PR because I want to test that PR. But for now, we don't have this or we don't +have an easy way to, for example, test the same implementation, but different +versions. + +**Mike Schmidt**: Okay, makes sense. We referenced some of the accomplishments. +I think we should give you a quick opportunity to do a victory lap and maybe +highlight a couple, like what are a couple of bugs that you found doing this? +Maybe some interesting ones for the audience. + +**Bruno Garcia**: Yeah, we found over 35 bugs. So, for example, we found many +implementations using the incorrect type for the key type value for PSBTs +(Partially Signed Bitcoin Transaction). This is great, because we realized that +only Bitcoin Core was doing this right. So, every other implementation was +using the wrong type, not following the BIP. And we found a CVE vulnerability +on Rust Miniscript, a panic on btcd's PSBT parser, and many other LN bugs. +However, we found many bugs, not because of the differential fuzzing, but only +because of the fuzzing, because many implementations in the ecosystem don't have +fuzz testing. So, for example, we found a panic on btcd's PSBT parser, or we +found the CVE on Rust Miniscript because of basically fuzzing, not because of +the differential fuzzing. And so, I wrote in, "The state of Bitcoinfuzz", that +we do differential fuzzing of projects that do not have fuzz testing and we +found bugs with it. And there are some projects, like Rust Bitcoin and Rust +Miniscript, they have fuzz testing, but this is not enough. When you have fuzz +testing, we have to run it continuously. So, if you don't run it, of course, +you won't find any bugs. So, you can have many targets, but if you don't run +them, of course, you won't find anything. + +I started the project basically focused on Bitcoin implementations. So, I +started basically with Bitcoin Core, btcd, Rust Bitcoin. But then, Erick and +Morehouse joined the project because they think it's important to have the same +work for LN implementations. And we found many bugs across different LN +implementations. And another thing that is funny, it's because doing +differential fuzzing of specific Bitcoin implementations is hard, because we +don't have a specification. So, when we have a crash, for example, between btcd +and Bitcoin Core, who is wrong? Who is correct? So, we have it to investigate. +But in case of LN implementations, we have the BOLTs, so we can basically +compare their behavior. + +**Mark Erhardt**: The specification against the behavior, and that they all +match up. Actually, I have a question about that. It seems to me that you're +mostly focused on differential fuzzing, but how does this differ from the +fuzzing that, for example, Bitcoin Core does internally? You said you found a +bunch of bugs on other projects because they're being fuzzed for the first time, +and that's sort of what Bitcoin Core does already with the QA assets. So, could +you highlight maybe the difference between those two approaches? + +**Bruno Garcia**: Yeah, for example, the Bitcoin Core fuzz testing is basically +we use, for example, libFuzzer or AFL. And bitcoinfuzz is not different, it's +basically libFuzzer. So, we have a PR to integrate AFL, but it's basically +libFuzzer. So, it's the same approach of Bitcoin Core, but we have this +comparison between implementations. But the way we create inputs, the way we +have our corpora it's all similar to Bitcoin Core. We use libFuzzer and, yeah, +we have some custom mutators, for example, for some LN targets. But yeah, +Bitcoin Core also has some custom mutators for some targets and, yeah, it's +basically the same approach. + +**Mark Erhardt**: So, would you be able to use some of the inputs from Bitcoin +Core on other projects? + +**Bruno Garcia**: Yeah. If the targets are compatible, yeah. For example, in +the case of miniscript and descriptor parsers, the inputs are basically the +miniscripts for the descriptors. And I think that 90% of the bugs that I found +for these things were using the corpora from Bitcoin Core. Because I know that +Bitcoin Core has a well-maintained and completed corpora that we have all the +edge cases for these things. So, we basically ran, started to run in +bitcoinfuzz using the corpora from Bitcoin Core for these targets, and we found +many bugs with it. + +**Mike Schmidt**: I know we had Matt Morehouse on recently and he was quite +adamant about wanting more testing and fuzz testing, specifically in his domain +of LN implementations. So, it sounds like you're echoing that sentiment as +well. + +**Bruno Garcia**: Yeah, I was mentioning that for the Bitcoin protocol, we don't +have a specification. We have a specification for LN, the BOLTs, but we found +that sometimes the specifications are not clear. So, we found some bugs that we +analyzed and basically, "Okay, the BOLT doesn't say anything about this specific +case, so I have to improve the specification". So, this is great because of +course we find bugs that implementations should fix, but we also find things +that we know that the specification should be improved. + +**Mark Erhardt**: Wait, so you can fix bugs by fixing the specification? You +don't have to answer that! But yes, obviously, sometimes things are +under-specified, and sometimes the code is buggy. This is a meta comment. + +**Bruno Garcia**: For example, we have to update a BIP because we have a target +for the addrv2, and we realized that we got a crash between Bitcoin Core and +Rust Bitcoin because Bitcoin Core deleted support for Torv2, but Rust Bitcoin +was skipping support for Torv2. If you see the BIP, BIP has many things about +Torv2. Okay, there is a specification about the field, and whatever, but Torv2 +is basically not used anymore. So, should we delete from the BIP? Should we +mark it as not used anymore? But then I opened a PR on Rust Bitcoin removing +the support for Torv2 and, yeah, that's fine. It's another example. + +**Mike Schmidt**: A couple of calls to action here that I can think about. One +is actually from the newsletter write-up itself saying, "Developers of Bitcoin +projects are encouraged to investigate making their software a supported target +for bitcoinfuzz". So, that's my first call to action for the audience. My +second one is, and maybe, Bruno, you can elaborate on this, the collective of +you and others that are working on Bitcoin fuzz and related projects, I assume +you're looking for contributors and maybe people to run some of this or adding +testing targets in specific libraries, things like that. If that's true, maybe +you can elaborate on that, so some of our tech enthusiasts, listeners who want +to contribute in some way can maybe take a look at this? + +**Bruno Garcia**: Yeah, we need more contributors because bitcoinfuzz is a huge +project. And for example, we integrate projects with different programming +languages. So, of course, I'm not an expert on C++ and Rust and Python and +Kotlin, but we have to deal with these languages. So, more reviewers would be +great. And we need to improve our build system, the way we build the models. +We have some conflicts and we should improve it. So, if people want to +contribute on this thing, it would be very valuable. And we need more targets +and more people running it. + +**Mike Schmidt**: Bruno, anything else you'd say in closing? + +**Bruno Garcia**: No, it's fine. Thank you. Thanks for having me. + +**Mike Schmidt**: All right. Thank you for your time, Bruno. + +**Bruno Garcia**: Thank you. + +_Is it possible to recover a private key from an aggregate public key under strong assumptions?_ + +**Mike Schmidt**: Moving to our monthly segment on the Bitcoin Stack Exchange. +First question, "Is it possible to recover a private key from an aggregate +public key under strong assumptions?" Pieter Wuille answered this. He answered +it briefly and then went on to explain a bit. But he said, "Yes, absolutely". +Go ahead, Murch. + +**Mark Erhardt**: I think it's important to explain what he said 'of course' to. +So, the base assumption of the asker here is, if we can calculate private keys +from public keys, is MuSig in any way more secure than a single public key to a +private key relationship? And to that, Pieter says, "No, of course not. If you +can calculate private keys from public keys, you can calculate the private key +from the aggregate public key". So, I think it's important to understand that +the strong assumption here is secp256k1 is already insecure, and then MuSig2 is +also broken. + +**Mike Schmidt**: Yeah, I had a quote from him as well that I saw him hint at, +and then get explicitly at the end of his answer on the Stack Exchange question, +which is, "If you are concerned about the security of secp256k1 for whatever +reason, you shouldn't use it at all. No multisignature scheme, aggregated or +not, is going to save you if the cryptography beneath it all is broken". + +**Mark Erhardt**: Well done. Sorry for jumping in so quickly! + +_Are all taproot addresses vulnerable to quantum computing?_ + +**Mike Schmidt**: No, I appreciate that. Next question, "Are taproot addresses +vulnerable to quantum computing?" So, Hugo, you and Murch highlighted answers +here that even if a scriptpath-only taproot output exists, they aren't quantum +safe, partially because there's no such thing as a scriptpath-only spending +option in taproot. There's always a keypath, even if you don't know the private +key to spend it. Is that correct so far, Murch, and then we can get into the +wrinkle? + +**Mark Erhardt**: Yeah, let me jump in right away. So, the construction of +taproot allows two ways of spending. One is by keypath, which basically means I +know the private key directly with which I can sign, and therefore I just +provide a signature that corresponds to the internal public key that is tweaked +with the merkle root of the script tree. Sorry, I'll say that again. You just +sign with the key that you've basically committed to and that works. That's the +single-sig case or also the MuSig case, when multiple people together have an +aggregate public key. In the scriptpath case, you show, "Hey, wait, there's +more here than just the public key that I committed to. Let me show that there +is a script tree here. I'll show you the path to the leaf, I'll show you the +leaf and then I satisfy the conditions that are encoded in the script leaf". +And now, there might be cases in which you want to make it impossible to use the +keypath. Like, if there's only complex conditions under which a UTXO should be +spent, you would use a point that there is no known relationship to. And this +is called a NUMS point or nothing-up-my-sleeve point. So, if you use a NUMS +point, it can only be spent by scriptpath by you. + +But now, someone has a quantum computer and can do exactly what we were talking +about in the last question: find the private key from a public key. There is a +private key to the tweaked public key that was derived from the NUMS point. +Even if there's no private key to the NUMS point itself, the tweaked key does +have one. Even if you don't know it, it can be calculated, and then you can +make a signature and spend from that UTXO. So, the funny thing here is if +someone created an output with a NUMS point, which by them is only spendable by +using the scriptpath and revealing a leaf and satisfying that leaf's conditions, +if another person uses a quantum computer to quantum decrypt a private key from +the public key and then signs with that, makes a keypath spend from this output +that is thought to be only scriptpath spendable, then the person that created +the output in the first place can prove that a quantum description happened, +because they can show that the output was originally built with the NUMS key +under the hood. So, that's the interesting part there. + +**Mike Schmidt**: Yeah. That was the interesting wrinkle that I think it was +you, Murch, in the answer had pointed out. So, we can get proof of quantum +computing if they choose to point it at some such output. + +_Why cant we set the chainstate obfuscation key? _ + +"Why can't we set the chainstate obfuscation key?" Ava Chow explained that the +blocksdir obfuscation key and chainstate obfuscation are separate. And I +believe that the blocksdir key is configurable, Murch, but the chainstate one is +derived and thus not configurable. Am I right so far, and then I have probably +a few more questions for you after that? + +**Mark Erhardt**: The blocksdir obfuscation was added much more recently, so +maybe someone built it with that together. But the chainstate obfuscation is PR +#6650, which sounds like ten years ago, roughly, or so. Maybe not ten years, +but very old. 2015, exactly ten years, actually. September 7th, 2015. Yeah, +so presumably when people did a similar thing now, they just thought a little +more holistically about it then. And sorry, what was your question? + +**Mike Schmidt**: Oh, well, one of them was the mempool can also be persisted to +disk, right? And it also has obfuscation as well. Is that correct? + +**Mark Erhardt**: Possibly. I'm not sure, actually. + +**Mike Schmidt**: Okay, we'll dog ear that for our listeners to do their own +homework. There's been a lot of talk of obfuscation these last few days. I +think, Murch, if I have it right, the idea is that with OP_RETURN limits being +relaxed at the policy layer, that it could be abused to put in illegal content, +or some such thing, and that the fact that it would be an OP_RETURN would mean +that it could be contiguous and potentially not interrupted with separators, +like data push things, and therefore it is more likely to be targeted by either +antivirus or law enforcement. Am I getting the gist of that concern that is on +social media? And then, if not, correct me and then maybe we can talk about if +that is true, or the response. + +**Mark Erhardt**: So, the software we're using does not actually read data as +any other format than just script. So, if someone else puts in data blobs, yes, +they would be in the blockchain and potentially, something that looks for a +specific sequence of bytes would not see them in the obfuscated blocks data, +because basically what we do is we create a byte pattern and then we XOR the +entire block content with that. So, basically we encrypt it with a very weak +encryption that is just switching around some of the bytes. And then, when you +read the blocks again, your software knows where to find the key, which is +stored in a specific location in the Bitcoin directory itself, and then just +applies this mask back on. And then, in memory, you can read it and process it. +But Bitcoin Core itself doesn't interpret the content of inscriptions or +OP_RETURNS. It wouldn't read out the text of the Genesis block to you. You +have to apply second-hand processing in order to get this sort of data out of +the blockchain. + +So, we already have a bunch of illegal content in the blockchain. This has been +a problem before. I believe that it has been previously rejected. Essentially, +there's no way to filter for all of this sort of stuff, because you don't know +what someone might want to put in, so you can't write a filter that searches for +it and rejects it. And therefore, it being committed to by the blockchain and +maybe buried a few blocks already before anyone notices what's in there, it +seems I just don't think that there's a legal case here. It seems absurd to me. +And I don't think that there's a huge difference between it being stored in +OP_RETURN in a complex data encoding that we don't interpret on the Bitcoin +level versus it being stored in an inscription where it's encoded in a complex +format that is stored in 520-byte chunks. There's just, I don't think there's a +big distinction here. Either way, this is not data that Bitcoin uses. And if +someone else wants to get that data out and do something with them, that's +another story. + +**Mike Schmidt**: So, similar to the discussions we've had before about people +can come up with whatever scheme they want to embed data into Bitcoin, and then +it's on this sort of separate software, like client software, like whatever the +ordinals or inscription software is, to know what the scheme is and then pull +that data out and stitch it together, and then somehow know that it's a JPEG and +then it's a JPEG file. That all had existed, exists today, and that all that's +changing is that maybe someone's going to come up with a new scheme using +OP_RETURN, which will also require software to find those bytes, organize those +bytes, interpret those bytes into whatever scheme that person is using, right? +So, it seems like it's a different scheme, but it's the exact same thing that +we've dealt with previously, right? Am I interpreting that right? + +**Mark Erhardt**: Well, exact same? People might disagree on absolutes here, +but it is negligibly different, in my opinion. + +_Is it possible to revoke a spending branch after a block height?_ + +**Mike Schmidt**: All right. I think we covered that one pretty good. Hot news +topic. Next question, "Is it possible to revoke a spending branch after a +certain block height?" And Antoine answered this pointing out that inverse time +lots, which are spending conditions that can be revoked based on the height of +the blockchain, aren't something that's feasible with Bitcoin's current design. +And he goes on to note that maybe that's a good thing that that feature is not +available. Murch, what is the canonical reason that that could be a bad thing +to have spending conditions revoked? + +**Mark Erhardt**: Imagine a transaction that decides the fate of tens of +thousands of bitcoin being locked to expire at a specific block height, and then +it is included exactly one block before it's no longer includable. Suddenly, a +reorg has a huge financial incentive to happen. So, there's just been a +longstanding approach that people do not want transactions to become invalid +after they have been valid. We do have transactions that are only valid after a +specific point, like timelocks, but the opposite introduces some different +scenarios and game theory that make it kind of iffy. + +_Configure Bitcoin Core to use onion nodes in addition to IPv4 and IPv6 nodes?_ + +**Mike Schmidt**: "How to configure Bitcoin Core for onion nodes beyond IPv4 or +IPv6?" Pieter Wuille answered this one as well, clarifying that that onion +config option only affects outbound connections, and that inbound Tor setup +would still require your node to be reachable over Tor. And he goes on to point +out how you might do that as well. + +**Mark Erhardt**: I think basically what you would do on Linux is you install +Tor, and then when you run Bitcoin, it automatically does the things you expect +it to do. + +_Bitcoin Core 29.1rc2_ + +**Mike Schmidt**: Releases. We have Bitcoin Core 29.1rc2, which is a new RC for +Bitcoin Core. This is out and ready for testing. If you're running Bitcoin +Core, now would be a great time to test for any regressions or test with your +deployment scripts and provide any feedback to the team. Didn't have anything +else to add there, Murch. I think we sort of talked about some of the items +that were in the first RC a couple times. I don't know if there's anything new. + +**Mark Erhardt**: Well, due to the public interest, I think it's fair to say +again, because of the latency that we see in block propagation ever since +minrelayfee filters have apparently not been broadly enforced anymore, the 29.1 +release will backport the mempool policy change regarding minrelaytxfee and +incrementalrelaytxfee. So, if this is a very important topic to you, upgrading +from 29.0 to 29.1, by default, your minimum relay transaction feerate will be +reduced by a factor 10 to 0.1 sat/vB (satoshi per vbyte). So, if this is the +sort of thing that keeps you awake at night, if you want to upgrade, you totally +can upgrade, but you might want to configure your minrelaytxfee to your +preferred amount because the default changed, or will change when it's released. +Also, if you run on a 32-bit system, which I don't know if there's that many +around still, and you were playing around with your maxmempool and dbcache, they +are now capped because if you set it to high, it'll actually not work on a +32-bit system. And that was the interesting ones I think that I saw. + +There's a bunch of bug fixes. There's usually no new features. Well, there are +no new features in point releases, but in this case, there is a policy change +due to the issues that the policy was creating on the network. + +_Core Lightning v25.09rc4_ + +**Mike Schmidt**: Core Lightning v25.09rc4. I actually noticed a few hours ago +the release for this RC was published, so you can not just download the RC, but +the full version. CLN now includes bookkeeper in CLN itself. I believe that +was a plugin previously; xpay can now pay BIP353 human-readable Bitcoin payment +instructions; there is that log viewer tool that we covered previously, which I +think was a web-based tool to interact with the logs a little bit more +user-friendly way; there's improvements to package management; there are +splicing improvements and better interop with splicing with Eclair; and there's +other features and improvements. Please check out the release notes if you're a +CLN user. + +_Bitcoin Core #31802_ + +Notable code and documentation changes, Bitcoin Core #31802, which adds +bitcoin-node and bitcoin-gui to release binaries for IPC. Murch, this seems +like a big one. What's going on here? + +**Mark Erhardt**: So, we've talked before about the multiprocess project, which +has been going on for a very long time. And we've also been talking about +Stratum v2, of course, which will hopefully help miners that participate in +mining pools build their own template locally, and then work on that template +locally, and only prove to the mining pool operator that they're doing useful +work, rather than following the template of the mining pool operator. So, Sjors +has been working on this for I think a couple of years now to put support for +Stratum v2 into Bitcoin Core. This entails that we need to be able to build +block templates in Bitcoin Core and update the provided template frequently. +Originally, he was trying to put Stratum v2 support directly into Bitcoin Core, +but that was a very large code change that people felt was maybe a little too +big for a feature that only a small portion of the users would be using. So, +the approach changed over time a little bit to make it into an interface, where +the mining information can be got and then a sidecar that translates it to the +Stratum v2 format. + +So, this has been out as a concept proof I think for a while. And one of the +big concerns that people trying to implement Stratum v2 support on their end had +was that essentially they're running Sjors' private, one-developer release with +the Stratum v2 support, and it would be much nicer if they could instead run +vanilla Bitcoin Core with a command line option or something to get that +instead. So, what this code change does is it enables a CMake option, called +ENABLE_IPC, by default, which means if you build Bitcoin Core, it will create +the two binaries, bitcoin-node and bitcoin-gui, which are the multiprocess +binaries. And these binaries talk to each other using something called the +inter-process communication, IPC. It will also then support this mining IPC +that the sidecar of Sjors is using. + +This was merged a couple of weeks ago. This is before the feature freeze, so it +will be in the 30.0 release. And what it will allow is that the people that are +working on implementing Stratum v2 on their end will be able to run the Bitcoin +Core binary and work against that, instead of Sjors' private branch. And I +think that's it. + +**Mike Schmidt**: Murch, was this Stratum integration not possible with +something like the existing RPCs or other ways to interact with Bitcoin Core +previously? Or it was possible, but this is a more performant way to do it? + +**Mark Erhardt**: I think the biggest difference is that RPCs are only when you +pull data, like you call it as the data receiver. You ask the node, "Give me +that data", and then it gives you the data back. With the IPC, you can have +push notifications. So, for example, the node in this case could be set up to +build a new block template every 30 seconds, and to automatically push that data +out to the mining IPC. And then, the sidecar would update the Stratum v2 +template and push that out to the mining operation. + +**Mike Schmidt**: Okay, that makes sense. One more follow-up question. So, +this will be in the v30 release. Are these binaries in any way experimental, or +are there asterisks by these binaries in any way, or are these considered +production-ready? + +**Mark Erhardt**: Please don't nail me down on this. I think that they are +considered pretty mature. They've been tested a lot. So, usually we like to +merge features early in the release cycle. In this case, the request came +specifically from the people working on Stratum v2, that they would prefer to +work against Bitcoin Core directly. You could have run with the multiprocess +way of building the binaries before, but now, in addition to the regular way the +binary is built with bitcoind, It is now built as two separate binaries too that +can run in their own processes. So, by default, you're not going to use this +unless you opt in. You don't have to change anything about your setup unless +you're specifically interested in this IPC stuff. If you want to help testing +with multiprocess, I'm sure that the people working on multiprocess would +appreciate that a lot. So, yeah, I would actually have to go back to my notes +and the description of the multiprocess overview to double-down on exactly how +ready this is and everything, but I think it's basically fine to use. Maybe +don't hook up your several-billion-dollar company to it yet, but you know. + +**Mike Schmidt**: Okay. Yeah, that makes sense, Murch. Didn't mean to put you +on the spot there. I was just curious. + +_LDK #3979_ + +We can move to LDK #3979, which adds splice-out support for LDK. So, in +Lightning, you can now add funds to an existing channel that would be via a +splice-in, and this was in LDK in their main branch as of last month. But with +this PR this week, LDK users are able to splice funds out of a channel. For +example, if they want those funds onchain for another purpose, this is part of +LDK's dual-funded channel and splicing project, tracking issue #1621 on the LDK +repository, if you want to follow along. I think in the newsletter, we put that +this wraps up their support for splicing. There are other items on that +dual-funded channels and splicing project tracking. There are some items that +look like they're still remaining. If you're curious about this kind of +low-level stuff, check out that #1621 tracking issue. Murch, do you know, I +don't know, can I splice-out of one channel and into an existing channel with +the current tooling all at once, do you know? + +**Mark Erhardt**: I think that Phoenix can do that. I'm not sure if LDK can +yet. That was definitely something that the Lightning developers talked about. + +**Mike Schmidt**: That seems like for these LSPs and other Lightning liquidity +folks to be a killer feature. So, I assume it's coming if it's not here +already. + +_LND #10102_ + +LND #10102 titled, "Catch bad gossip peer and fix UpdatesInHorizon". This PR to +LND makes two changes. One is it starts recording bad peers when they make +invalid channel update announcements, and there is a scoring and threshold +system now in place for that. And the second thing is that it also updates LND, +some of their internals to be more robust around handling invalid announcements. +These changes follow on some other recent PRs to LND that we've covered around +LND's effort to, I'll use the word 'fortify', fortify their handling of gossip +to be more resilient. + +_Rust Bitcoin #4907_ + +Last PR this week, Rust Bitcoin #4907, which introduces script tagging. And if +I'm understanding this correctly, Rust Bitcoin previously had a generic script, +I'll use the word 'data type'. And after this PR, Rust Bitcoin has types for +different types of scripts. So, instead of just that generic script, they've +pulled out things into categories of scripts, including ScriptPubKey, ScriptSig, +RedeemScript, WitnessScript, and TapScript. So, you can imagine stronger script +typing that can be useful in Rust Bitcoin or client software using Rust Bitcoin +to have these more specific data types, and potentially there's even +restrictions on their usage in different parts of the codebase. + +Well, that's it. We want to thank our guests for joining for the news segment, +Bruno and Liam, this week. And I want to thank Murch for co-hosting as always, +and for you all for listening. Cheers. + +**Mark Erhardt**: Cheers. {% include references.md %} From 30e5a591fc9eb3070acba721c930540c474fa39a Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Mon, 8 Sep 2025 14:30:55 -0500 Subject: [PATCH 241/278] Podcast: add 368 recap --- .../en/newsletters/2025-08-22-newsletter.md | 42 +++++++++---------- .../en/podcast/2025-08-26-newsletter-recap.md | 23 ++++++++++ 2 files changed, 44 insertions(+), 21 deletions(-) create mode 100644 _posts/en/podcast/2025-08-26-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-08-22-newsletter.md b/_posts/en/newsletters/2025-08-22-newsletter.md index b5f3b40b02..a0c29056fd 100644 --- a/_posts/en/newsletters/2025-08-22-newsletter.md +++ b/_posts/en/newsletters/2025-08-22-newsletter.md @@ -52,7 +52,7 @@ changes to popular Bitcoin infrastructure software. minisketch] (allowing much larger templates to be shared efficiently), and using Golomb-Rice [encoding][wuille templgr] on the templates similar to [compact block filters][topic compact block filters] (an - estimated 25% efficiency). + estimated 25% efficiency). {% assign timestamp="0:30" %} - **Trusted delegation of script evaluation:** Josh Doman [posted][doman tee] to Delving Bitcoin about a library he's written that uses a @@ -74,7 +74,7 @@ changes to popular Bitcoin infrastructure software. TEE. The library is designed for use with the Amazon Web Services (AWS) - Nitro enclave. + Nitro enclave. {% assign timestamp="28:07" %} ## Changes to services and client software @@ -84,45 +84,45 @@ wallets and services.* - **ZEUS v0.11.3 released:** The [v0.11.3][zeus v0.11.3] release includes improvements to peer management, [BOLT12][topic offers], and [submarine swap][topic submarine swaps] - features. + features. {% assign timestamp="33:07" %} - **Rust Utreexo resources:** Abdelhamid Bakhta [posted][abdel tweet] Rust-based resources for [Utreexo][topic utreexo], including interactive [educational - materials][rustreexo webapp] and [WASM bindings][rustreexo wasm]. + materials][rustreexo webapp] and [WASM bindings][rustreexo wasm]. {% assign timestamp="33:25" %} - **Peer-observer tooling and call to action:** 0xB10C [posted][b10c blog] about the motivation, architecture, code, supporting libraries, and findings of his [peer-observer][peer-observer github] project. He seeks to build "A loose, decentralized group of people who share the interest of monitoring the Bitcoin Network. A collective to enable - sharing of ideas, discussion, data, tools, insights, and more." + sharing of ideas, discussion, data, tools, insights, and more." {% assign timestamp="34:11" %} - **Bitcoin Core Kernel-based node announced:** Bitcoin backbone was [announced][bitcoin backbone] as a demonstration of using - the [Bitcoin Core Kernel][kernel blog] library as the foundation of a Bitcoin node. + the [Bitcoin Core Kernel][kernel blog] library as the foundation of a Bitcoin node. {% assign timestamp="37:22" %} - **SimplicityHL released:** [SimplicityHL][simplcityhl github] is a Rust-like programming language that compiles to the lower-level [Simplicity][simplicity] language [recently activated][simplicity post] on Liquid. For further reading, see the [related - Delving thread][simplicityhl delving]. + Delving thread][simplicityhl delving]. {% assign timestamp="38:23" %} - **LSP plugin for BTCPay Server:** The [LSP plugin][lsp btcpay github] implements client-side features of - [BLIP51][], the specification for inbound channels, into BTCPay Server. + [BLIP51][], the specification for inbound channels, into BTCPay Server. {% assign timestamp="39:17" %} - **Proto mining hardware and software announced:** Proto [announced][proto blog] new Bitcoin mining hardware and open source - mining software, built with previous [community feedback][news260 mdk]. + mining software, built with previous [community feedback][news260 mdk]. {% assign timestamp="39:42" %} - **Oracle resolution demo using CSFS:** Abdelhamid Bakhta [posted][abdel tweet2] a demonstration of an oracle using [CSFS][topic op_checksigfromstack], nostr, and MutinyNet to sign an - attestation of an event's outcome. + attestation of an event's outcome. {% assign timestamp="40:46" %} - **Relai adds taproot support:** - Relai added support for sending to [taproot][topic taproot] addresses. + Relai added support for sending to [taproot][topic taproot] addresses. {% assign timestamp="41:11" %} ## Releases and release candidates @@ -133,13 +133,13 @@ release candidates._ - [LND v0.19.3-beta][] is a release for a maintenance version for this popular LN node implementation containing "important bug fixes". Most notably, "an optional migration [...] lowers disk - and memory requirements for nodes significantly." + and memory requirements for nodes significantly." {% assign timestamp="43:09" %} - [Bitcoin Core 29.1rc1][] is a release candidate for a maintenance - version of the predominant full node software. + version of the predominant full node software. {% assign timestamp="43:29" %} - [Core Lightning v25.09rc2][] is a release candidate for a new major - version of this popular LN node implementation. + version of this popular LN node implementation. {% assign timestamp="43:55" %} ## Notable code and documentation changes @@ -158,7 +158,7 @@ repo], and [BINANAs][binana repo]._ following RPCs: `createrawtransaction`, `createpsbt`, `send`, `sendall`, and `walletcreatefundedpsbt`. The wallet enforces the TRUC transaction restrictions for weight limit, sibling conflict, and incompatibility between - unconfirmed TRUC and non-TRUC transactions. + unconfirmed TRUC and non-TRUC transactions. {% assign timestamp="44:33" %} - [Bitcoin Core #33106][] lowers the default `blockmintxfee` to 1 sat/kvB (the minimum possible), and the default [`minrelaytxfee`][topic default minimum @@ -169,14 +169,14 @@ repo], and [BINANAs][binana repo]._ expected to be lowered in a future version. The motivations for this change range from considerable growth in the number of blocks mined with sub 1 sat/vB transactions and the number of pools mining these transactions to an increase - in the Bitcoin exchange rate. + in the Bitcoin exchange rate. {% assign timestamp="46:57" %} - [Core Lightning #8467][] extends `xpay` (see [Newsletter #330][news330 xpay]) by adding support for paying [BIP353][] Human Readable Names (HRN) (e.g. satoshi@bitcoin.com) and enabling it to pay [BOLT12 offers][topic offers] directly, removing the need to run the `fetchinvoice` command first. Under the hood, `xpay` fetches the payment instructions using the `fetchbip353` RPC - command from the `cln-bip353` plugin introduced in [Core Lightning #8362][]. + command from the `cln-bip353` plugin introduced in [Core Lightning #8362][]. {% assign timestamp="1:02:49" %} - [Core Lightning #8354][] starts publishing `pay_part_start` and `pay_part_end` event notifications for the status of specific payment parts sent with @@ -184,7 +184,7 @@ repo], and [BINANAs][binana repo]._ duration of the payment and whether it was successful or failed. If the payment fails, an error message is provided and, if the error onion isn’t corrupted, additional information on the failure is given, such as the source - of the error and the failure code. + of the error and the failure code. {% assign timestamp="1:03:26" %} - [Eclair #3103][] introduces support for [simple taproot channels][topic simple taproot channels], leveraging [MuSig2][topic musig] scriptless @@ -194,7 +194,7 @@ repo], and [BINANAs][binana repo]._ transactions. This PR also includes support for [dual funding][topic dual funding] and [splicing][topic splicing] in simple taproot channels, and enables [channel commitment upgrades][topic channel commitment upgrades] to - the new taproot format during a splice transaction. + the new taproot format during a splice transaction. {% assign timestamp="1:04:07" %} - [Eclair #3134][] replaces the penalty weight multiplier for stuck [HTLCs][topic htlc] with the [CLTV expiry delta][topic cltv expiry delta] when @@ -203,11 +203,11 @@ repo], and [BINANAs][binana repo]._ HTLC will tie up liquidity. To mitigate the outsized penalty of stuck HTLCs with a maximum CLTV expiry delta, this PR adjusts the reputation decay parameter (`half-life`) from 15 to 30 days and the stuck payment threshold - (`max-relay-duration`) from 12 seconds to 5 minutes. + (`max-relay-duration`) from 12 seconds to 5 minutes. {% assign timestamp="1:04:43" %} - [LDK #3897][] extends its [peer storage][topic peer storage] implementation by detecting lost channel state during backup retrieval, by deserializing the - peer’s copy and comparing it to the local state. + peer’s copy and comparing it to the local state. {% assign timestamp="1:05:56" %} {% include snippets/recap-ad.md when="2025-08-26 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-08-26-newsletter-recap.md b/_posts/en/podcast/2025-08-26-newsletter-recap.md new file mode 100644 index 0000000000..c98e19b3bc --- /dev/null +++ b/_posts/en/podcast/2025-08-26-newsletter-recap.md @@ -0,0 +1,23 @@ +--- +title: 'Bitcoin Optech Newsletter #368 Recap Podcast' +permalink: /en/podcast/2025/08/26/ +reference: /en/newsletters/2025/08/22/ +name: 2025-08-26-recap +slug: 2025-08-26-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt discuss [Newsletter #368]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-8-8/407136571-44100-2-6635c69c8e92b.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From 53afc91ca30d0786ed225d4ad3bff258487e0914 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Wed, 10 Sep 2025 05:21:31 -0500 Subject: [PATCH 242/278] Podcast: add 370 recap --- .../en/newsletters/2025-09-05-newsletter.md | 20 ++++++++-------- .../en/podcast/2025-09-09-newsletter-recap.md | 24 +++++++++++++++++++ 2 files changed, 34 insertions(+), 10 deletions(-) create mode 100644 _posts/en/podcast/2025-09-09-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-09-05-newsletter.md b/_posts/en/newsletters/2025-09-05-newsletter.md index c0268c846f..701c5eb5c1 100644 --- a/_posts/en/newsletters/2025-09-05-newsletter.md +++ b/_posts/en/newsletters/2025-09-05-newsletter.md @@ -33,7 +33,7 @@ Bitcoin's consensus rules._ combinators." The most recent post indicates further entries in the series are - expected. + expected. {% assign timestamp="37:56" %} - **Draft BIP for adding elliptic curve operations to tapscript:** Olaoluwa Osuntokun [posted][osuntokun ec] to the Bitcoin-Dev mailing @@ -47,7 +47,7 @@ Bitcoin's consensus rules._ Jeremy Rubin [replied][rubin ec1] to suggest additional opcodes to enable additional features, as well as [other opcodes][rubin ec2] that would make it more convenient to use some features provided by the - base proposal. + base proposal. {% assign timestamp="1:52" %} - **Draft BIP for OP_TWEAKADD:** Jeremy Rubin [posted][rubin ta1] to the Bitcoin-Dev mailing list a link a [draft BIP][rubin bip] to add @@ -56,7 +56,7 @@ Bitcoin's consensus rules._ addition of the opcode, which include a script to reveal a [taproot][topic taproot] tweak, proof of order of signing a transaction (e.g., Alice must have signed before Bob), and [signing - delegation][topic signer delegation]. + delegation][topic signer delegation]. {% assign timestamp="19:23" %} ## Releases and release candidates @@ -69,10 +69,10 @@ release candidates._ the `xpay` command for paying [BIP353][] addresses and simple [offers][topic offers], offers improved bookkeeper support, provides better plugin dependency management, and includes other new features - and bug fixes. + and bug fixes. {% assign timestamp="59:40" %} - [Bitcoin Core 29.1rc2][] is a release candidate for a maintenance - version of the predominant full node software. + version of the predominant full node software. {% assign timestamp="1:00:24" %} ## Notable code and documentation changes @@ -90,18 +90,18 @@ repo], and [BINANAs][binana repo]._ purpose but act as decoys. A randomized number of dummy hops is added each time, but is capped at 10 as defined by `MAX_DUMMY_HOPS_COUNT`. Adding additional hops makes it significantly harder to determine the distance to or - the identity of the receiver node. + the identity of the receiver node. {% assign timestamp="1:00:55" %} - [LDK #4019][] integrates [splicing][topic splicing] with the [quiescence protocol][topic channel commitment upgrades] by requiring a quiescent channel state before initializing a splicing transaction, as mandated by the - specification. + specification. {% assign timestamp="1:02:24" %} - [LND #9455][] adds support for associating a valid DNS domain name with a Lightning node's IP address and public key in its announcement message, as allowed by the specification and supported by other implementations such as Eclair and Core Lightning (see Newsletters [#212][news212 dns], [#214][news214 - dns], and [#178][news178 dns]). + dns], and [#178][news178 dns]). {% assign timestamp="1:03:09" %} - [LND #10103][] introduces a new `gossip.peer-msg-rate-bytes` option (default 51200), which limits the outgoing bandwidth used by each peer for outbound @@ -111,10 +111,10 @@ repo], and [BINANAs][binana repo]._ single peer from consuming all the global bandwidth defined by `gossip.msg-rate-bytes` introduced in [LND #10096][]. See Newsletters [#366][news366 gossip] and [#369][news369 gossip] for related LND work on - gossip requests resource management. + gossip requests resource management. {% assign timestamp="1:04:00" %} - [HWI #795][] adds support for the BitBox02 Nova by updating the `bitbox02` - library to version 7.0.0. It also makes several CI updates. + library to version 7.0.0. It also makes several CI updates. {% assign timestamp="1:05:20" %} {% include snippets/recap-ad.md when="2025-09-09 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-09-09-newsletter-recap.md b/_posts/en/podcast/2025-09-09-newsletter-recap.md new file mode 100644 index 0000000000..be6757765d --- /dev/null +++ b/_posts/en/podcast/2025-09-09-newsletter-recap.md @@ -0,0 +1,24 @@ +--- +title: 'Bitcoin Optech Newsletter #370 Recap Podcast' +permalink: /en/podcast/2025/09/09/ +reference: /en/newsletters/2025/09/05/ +name: 2025-09-09-recap +slug: 2025-09-09-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt are joined by Russell O’Connor, Olaoluwa +Osuntokun, and Jeremy Rubin to discuss [Newsletter #370]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-8-10/407235643-44100-2-9d5fc4052114d.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From e289d7984e17a4b0ccf2391ce0c63fe6fd3b0322 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Thu, 11 Sep 2025 01:34:00 -1000 Subject: [PATCH 243/278] Newsletters: add 371 (2025-09-12) --- .../en/newsletters/2025-09-12-newsletter.md | 80 +++++++++++++++++++ 1 file changed, 80 insertions(+) create mode 100644 _posts/en/newsletters/2025-09-12-newsletter.md diff --git a/_posts/en/newsletters/2025-09-12-newsletter.md b/_posts/en/newsletters/2025-09-12-newsletter.md new file mode 100644 index 0000000000..0070d4fc6f --- /dev/null +++ b/_posts/en/newsletters/2025-09-12-newsletter.md @@ -0,0 +1,80 @@ +--- +title: 'Bitcoin Optech Newsletter #371' +permalink: /en/newsletters/2025/09/12/ +name: 2025-09-12-newsletter +slug: 2025-09-12-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter announces the availability of a workbook +dedicated to provable cryptography. Also included are our regular +sections with links to new releases and release candidates, plus +descriptions of notable changes to popular Bitcoin infrastructure +software. + +## News + +- **Provable Cryptography Workbook:** Jonas Nick [posted][nick workbook] + to Delving Bitcoin to announce a short workbook he created for a four + day event to "teach developers the basics of provable cryptography, + [...] consisting of cryptographic definitions, propositions, proofs + and exercises." The workbook is available as a [PDF][workbook pdf] + with freely licensesd [source][workbook source]. + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [Bitcoin Core 29.1][] is the release of a maintenance + version of the predominant full node software. + +- [Eclair v0.13.0][] is the release of this LN node implementation. It + "s release contains a lot of refactoring, an initial implementation of + taproot channels, [...] improvements to splicing based on recent + specification updates, and better Bolt 12 support." The taproot + channels and splicing features are still being fully specified, so + they should not be used by regular users. The release notes also + warn: "This is the last release of eclair where channels that don't + use anchor outputs will be supported. If you have channels that don't + use anchor outputs, you should close them." + +- [Bitcoin Core 30.0rc1][] is a release candidate for the next major + version of this full verification node software. + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [Bitcoin Core #30469][] index: Fix coinstats overflow + +- [Eclair #3163][] Add high-S signature Bolt 11 test vector + +- [Eclair #2308][] Use balance estimates from past payments in path-finding + +- [Eclair #3021][] Allow non-initiator RBF for dual funding + +- [Eclair #3142][] Allow overriding `max-closing-feerate` with `forceclose` API + +- [LDK #4053][] tankyleo/2025-09-p2a-anchor + +- [LDK #3886][] Update `channel_reestablish` for splicing + +{% include snippets/recap-ad.md when="2025-09-16 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="30469,3163,2308,3021,3142,4053,3886" %} +[bitcoin core 29.1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[bitcoin core 30.0rc1]: https://bitcoincore.org/bin/bitcoin-core-30.0/ +[nick workbook]: https://delvingbitcoin.org/t/provable-cryptography-for-bitcoin-an-introduction-workbook/1974 +[workbook pdf]: https://github.com/cryptography-camp/workbook/releases +[workbook source]: https://github.com/cryptography-camp/workbook +[Eclair v0.13.0]: https://github.com/ACINQ/eclair/releases/tag/v0.13.0 From d17e52c6e2fa9348b3ba01245a7afec3576f3afa Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Fri, 12 Sep 2025 00:07:52 +0000 Subject: [PATCH 244/278] News371: add merge summaries --- .../en/newsletters/2025-09-12-newsletter.md | 58 ++++++++++++++----- 1 file changed, 44 insertions(+), 14 deletions(-) diff --git a/_posts/en/newsletters/2025-09-12-newsletter.md b/_posts/en/newsletters/2025-09-12-newsletter.md index 0070d4fc6f..7d6a4a8c04 100644 --- a/_posts/en/newsletters/2025-09-12-newsletter.md +++ b/_posts/en/newsletters/2025-09-12-newsletter.md @@ -55,23 +55,53 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -- [Bitcoin Core #30469][] index: Fix coinstats overflow - -- [Eclair #3163][] Add high-S signature Bolt 11 test vector - -- [Eclair #2308][] Use balance estimates from past payments in path-finding - -- [Eclair #3021][] Allow non-initiator RBF for dual funding - -- [Eclair #3142][] Allow overriding `max-closing-feerate` with `forceclose` API - -- [LDK #4053][] tankyleo/2025-09-p2a-anchor - -- [LDK #3886][] Update `channel_reestablish` for splicing +- [Bitcoin Core #30469][] updates the types of the + `m_total_prevout_spent_amount`, `m_total_new_outputs_ex_coinbase_amount` and + `m_total_coinbase_amount` values from `CAmount` (64 bit) to `arith_uint256` + (256 bit) to prevent a value overflow bug that has already been observed on + the default [signet][topic signet]. The new version of the coinstats index is + stored in `/indexes/coinstatsindex/` and an upgraded node will need to sync + from scratch to rebuild the index. The old version is kept for downgrade + protection, but may be removed in a future update. + +- [Eclair #3163][] adds a test vector to ensure that a payee’s public key can be + recovered from a [BOLT11][] invoice with a high-S signature, in addition to + already allowing low-S signatures. This aligns with the behaviour of + libsecp256k1 and the proposed [BOLTs #1284][]. + +- [Eclair #2308][] introduces a new `use-past-relay-data` option that when set + to true (default false), uses a probabilistic approach based on past + payment attempt history to improve pathfinding. This replaces a prior method + that assumed uniformity in channel balances. + +- [Eclair #3021][] allows the non-initiator of a [dual-funded channel][topic + dual funding] to [RBF][topic rbf] the funding transaction, which is already + allowed in [splicing][topic splicing] transactions. However, an exception + applies to [liquidity advertisement][topic liquidity advertisements] purchase + transactions. This has been proposed in [BOLTs #1236][]. + +- [Eclair #3142][] adds a new `maxClosingFeerateSatByte` parameter to the + `forceclose` API endpoint that overrides the global feerate configuration + for non-urgent force close transactions on a per-channel basis. The global + setting `max-closing-feerate` was introduced in [Eclair #3097][]. + +- [LDK #4053][] introduces zero-fee commitment channels by replacing the two + anchor outputs with one shared [Pay-to-Anchor (P2A)][topic ephemeral anchors] + output, capped at a value of 240 sats. Additionally, it switches [HTLC][topic + htlc] signatures in zero-fee commitment channels to + `SIGHASH_SINGLE|ANYONECANPAY` and bumps HTLC transactions to [version 3][topic + v3 transaction relay]. + +- [LDK #3886][] extends `channel_reestablish` for [splicing][topic splicing] with + two `funding_locked_txid` TLVs (what a node last sent and received) so that + peers can reconcile the active funding transaction upon reconnecting. + Additionally, it streamlines the reconnection process by resending + `commitment_signed` before `tx_signatures`, handling implicit `splice_locked`, + adopting `next_funding`, and requesting announcement signatures as needed. {% include snippets/recap-ad.md when="2025-09-16 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="30469,3163,2308,3021,3142,4053,3886" %} +{% include linkers/issues.md v=2 issues="30469,3163,2308,3021,3142,4053,3886,1284,1236,3097" %} [bitcoin core 29.1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ [bitcoin core 30.0rc1]: https://bitcoincore.org/bin/bitcoin-core-30.0/ [nick workbook]: https://delvingbitcoin.org/t/provable-cryptography-for-bitcoin-an-introduction-workbook/1974 From fb96d5da1de3c3cc119ef285a8f1872eadd78d84 Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 12 Sep 2025 20:53:01 +0900 Subject: [PATCH 245/278] Newsletter-371:Translate into Japanese --- .../ja/newsletters/2025-09-12-newsletter.md | 97 +++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 _posts/ja/newsletters/2025-09-12-newsletter.md diff --git a/_posts/ja/newsletters/2025-09-12-newsletter.md b/_posts/ja/newsletters/2025-09-12-newsletter.md new file mode 100644 index 0000000000..2688d67179 --- /dev/null +++ b/_posts/ja/newsletters/2025-09-12-newsletter.md @@ -0,0 +1,97 @@ +--- +title: 'Bitcoin Optech Newsletter #371' +permalink: /ja/newsletters/2025/09/12/ +name: 2025-09-12-newsletter-ja +slug: 2025-09-12-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、証明可能な暗号に特化したワークブックを掲載しています。 +また、新しいリリースとリリース候補や、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき更新など +恒例のセクションも含まれています。 + +## ニュース + +- **証明可能な暗号のワークブック:** + Jonas Nickは、4日間のイベント用に作成した短いワークブックの発表を + Delving Bitcoinに[投稿しました][nick workbook]。このワークブックは、 + 「開発者に証明可能な暗号の基礎を教えるためのもので[...]暗号学の定義、命題、証明および演習で構成されています」。 + ワークブックは[PDF][workbook pdf]で提供され、[ソース][workbook source]はフリーライセンスで公開されています。 + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [Bitcoin Core 29.1][]は、主要なフルノードソフトウェアのメンテナンスバージョンのリリースです。 + +- [Eclair v0.13.0][]は、このLNノード実装のリリースです。このリリースには、 + 「多くのリファクタリング、Taprootチャネルの初期実装、[...] + 最近の仕様の更新に基づいたスプライシングの改善、BOLT12のサポート強化が含まれています。」 + Taprootチャネルとスプライシング機能はまだ仕様策定段階であるため、 + 一般のユーザーは使用しないでください。リリースノートには、 + 「これはアンカーアウトプットを使用しないチャネルをサポートするEclairの最後のリリースです。 + アンカーアウトプットを使用しないチャネルがある場合は、そのチャネルを閉じてください」という警告も記載されています。 + +- [Bitcoin Core 30.0rc1][]は、この完全な検証ノードソフトウェアの次期メジャーバージョンのリリース候補です。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Bitcoin Core #30469][]は、`m_total_prevout_spent_amount`、 + `m_total_new_outputs_ex_coinbase_amount`および`m_total_coinbase_amount`の値の型を + `CAmount`（64 bit）から`arith_uint256`（256 bit）に更新し、 + デフォルト[signet][topic signet]で既に確認されている値のオーバーフローによるバグを防止します。 + coinstatsインデックスの新バージョンは、`/indexes/coinstatsindex/`に保存され、 + アップグレードしたノードはインデックスを再構築するために最初から同期する必要があります。 + 旧バージョンはダウングレード保護のために保持されますが、将来のアップデートで削除される可能性があります。 + +- [Eclair #3163][]は、既に許可されているlow-S署名に加えて、 + high-S署名を持つ[BOLT11][]インボイスから受取人の公開鍵を復元できることを確認するためのテストベクトルを追加しました。 + これは、libsecp256k1および提案中の[BOLTs #1284][]の動作と一致します。 + +- [Eclair #2308][]は、新しい`use-past-relay-data`オプションを導入します。 + これをtrue（デフォルトはfalse）に設定すると、過去の試行履歴に基づく確率的アプローチを使用して経路探索を改善します。 + これは、チャネル残高の均一性を前提としていた従来の手法に代わるものです。 + +- [Eclair #3021][]は、[デュアルファンドチャネル][topic dual funding]の非開始者が + ファンディングトランザクションを[RBF][topic rbf]できるようにします。これは既に + [スプライシング][topic splicing]トランザクションで許可されています。ただし、 + [Liquidity Ads][topic liquidity advertisements]の購入トランザクションには例外が適用されます。 + この機能は、[BOLTs #1236][]で提案されているものです。 + +- [Eclair #3142][]は、`forceclose` APIエンドポイントに新しい`maxClosingFeerateSatByte`パラメーターを追加します。 + このパラメーターは、チャネル毎に、緊急でない強制クローズトランザクションのグローバルな手数料率設定を上書きします。 + グローバル設定`max-closing-feerate`は、[Eclair #3097][]で導入されました。 + +- [LDK #4053][]は、2つのアンカーアウトプットを1つの共有 + [P2A（Pay-to-Anchor）][topic ephemeral anchors]アウトプットに置き換え、 + その金額を240 satsに設定することで、手数料ゼロのコミットメントチャネルを導入します。 + さらに、手数料ゼロのコミットメントチャネルの[HTLC][topic htlc]署名を + `SIGHASH_SINGLE|ANYONECANPAY`に切り替え、 + HTLCトランザクションを[バージョン3][topic v3 transaction relay]にアップグレードします。 + +- [LDK #3886][]では、2つの`funding_locked_txid` TLV（ノードが最後に送受信した情報）を使用して + [スプライシング][topic splicing]用の`channel_reestablish`を拡張し、 + ピアが再接続時にアクティブなファンディングトランザクションを照合できるようにしました。 + さらに、`tx_signatures`の前に`commitment_signed`を再送信し、 + 暗黙的な`splice_locked`を処理し、`next_funding`を適用し、必要に応じてアナウンス署名を要求することで、 + 再接続プロセスを効率化します。 + +{% include snippets/recap-ad.md when="2025-09-16 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="30469,3163,2308,3021,3142,4053,3886,1284,1236,3097" %} +[bitcoin core 29.1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[bitcoin core 30.0rc1]: https://bitcoincore.org/bin/bitcoin-core-30.0/ +[nick workbook]: https://delvingbitcoin.org/t/provable-cryptography-for-bitcoin-an-introduction-workbook/1974 +[workbook pdf]: https://github.com/cryptography-camp/workbook/releases +[workbook source]: https://github.com/cryptography-camp/workbook +[Eclair v0.13.0]: https://github.com/ACINQ/eclair/releases/tag/v0.13.0 From d90b4472e01dea924703c87ba16df3a4bf98dfc7 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 11 Sep 2025 04:44:29 -0500 Subject: [PATCH 246/278] Podcast: add 368 transcription --- .../en/podcast/2025-08-26-newsletter-recap.md | 840 +++++++++++++++++- 1 file changed, 839 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-08-26-newsletter-recap.md b/_posts/en/podcast/2025-08-26-newsletter-recap.md index c98e19b3bc..8c4c4440c2 100644 --- a/_posts/en/podcast/2025-08-26-newsletter-recap.md +++ b/_posts/en/podcast/2025-08-26-newsletter-recap.md @@ -18,6 +18,844 @@ Mark “Murch” Erhardt and Mike Schmidt discuss [Newsletter #368]({{page.refer ## Transcription -_transcription coming soon_ +**Mike Schmidt**: Welcome everyone to Bitcoin Optech Newsletter #368 Recap. +Today, Murch and I are going to be talking about block template sharing and the +new BIP, emulating soft forks with trusted execution environments; and then we +have some highlights to ecosystem software, including items about a Bitcoin +kernel-based node, Utreexo, and the Simplicity programming language, among other +topics. We'll jump right into the News section. + +_Draft BIP for block template sharing_ + +First news item this week is titled, "Draft BIP for block template sharing". +Murch, you and I had AJ on a few weeks ago to talk about, I think it was a +Delving post, in which AJ outlined his idea for peers to be able to share what +they would consider their block template with their peers, what they would be +mining for the next block. Murch, maybe you could help remind me and the +audience, why would we want to do that? + +**Mark Erhardt**: Well, so recently, we've seen that people's mempools diverge a +lot more than they used to, both because there's a divergence in the policies +that node operators predominantly run, and because there is some small subset of +nodes that run more lenient mempool policies, and these have been adopted by a +majority of the hashrate. So, we're now seeing somewhere over 40% of +transactions being below the previous min fee rate, which means that while these +transactions are at the top of the mempool, blocks propagate much slower because +instead of getting essentially what is a recipe to how to recreate the block +from a compact block announcement with the short IDs of the transaction that are +contained in the block, after receiving the recipe, nodes notice, Oh, wait, I'm +missing something like 30% or 40% of these transactions. Could you give me this +list of items? Sending that back, and then there's round trips to retrieve that +data, there is a limit on how much data TCP will provide per round trip. + +So, with this amount of data, there's a significant delay in how quickly blocks +propagate between nodes that are missing a lot of the data. We've been seeing +that the block propagation is slightly elevated for 50% of the listening nodes; +but for 90% of the listening nodes, it's gone up multiple seconds. And this is, +of course, already a subset of the node population. The listening nodes are +nodes that have up to 125 connections by default, they're very well-connected. +If even the tail end of that is so slow, the non-listening nodes, the nodes that +only depend on this backbone of the Bitcoin Network will receive blocks even +slower. + +So, essentially the idea is, as I understand it, unfortunately I had AJ on last +week when we were trying to record this podcast, but he couldn't make it today, +my understanding is AJ's thought is, "What if we allow nodes to exchange more +often what they consider their top of the mempool with each other?" This would, +for example, allow new nodes that had been offline and rejoined a network, to +quickly catch up what's maybe on people's radar to be included in blocks soon. +It would also potentially allow nodes to build support for keeping the top of +the mempool of some of their peers around. So, when a node has a few peers that +have vastly different mempool policies, they could ask them every few minutes, I +think AJ was thinking about every two minutes, "Hey, what's your top 2 +mega-vbytes of the mempool?" And then, per AJ's sendtemplate proposal -- let me +take a step back. + +So, AJ has a concrete idea now that he proposes here. This is already open in +the BIPs repository and my spies are reporting that it might get a BIP number +soon! So, the idea is basically a few new P2P messages where you announce a +service to your peers, "Hey, I can share templates", which is basically a table +of contents of the top of your mempool, and the other peer might then use a +sendtemplate message which -- sorry, no, sendtemplate is the one that announces +the service; gettemplate is, "Could you please give me the top of your mempool?" +and then the reply would be a template message where the serving node provides +basically a compact block formatted recipe, "Here is what I have in my top 2 +MB". Then, maybe in the future some nodes would put aside a little bit of RAM +to keep the top of the mempool around -- well, they would try to put it in their +own mempool. But whatever doesn't pass their mempool policies might live in +another data structure where you might maintain that for three of your peers, +and just have an overview of what they consider the best transactions at the top +of their mempool. And then, you would occasionally update that, ask again. + +There's been a little bit of discussion how it might be a little more +bandwidth-efficient. You could only send a difference between the previous +announcement, or you could use other formats to encode it more efficiently. But +generally, it's just a way for sort of looking over the rim of your plate to see +what other people are doing in their mempool. It might also be an interesting +way to get transactions that had been in people's mempools for a long time +rebroadcast, because if someone gets a transaction through these announcements, +they would consider it freshly added to their mempool and would re-announce it +to their peers. So, where previously there really wasn't a mechanism by which +transactions that had been in the mempool for a long time would get rebroadcast +by Bitcoin Core nodes, with the sendtemplate scheme, these transactions that had +been around for a long time might get reintroduced to other people's mempools +and get rebroadcast at that point. + +So, overall, there's a few nice little benefits to that. The encoding of just +sending the short IDs of the transactions wouldn't make it extremely big, it's +probably around 40 kB or so. You would only do it with a small subset of your +peers. The proposal here is only for the messages. And so, the recommendations +on how it would be implemented or used by node implementations are not nailed +down in this document at all. But that's sort of the state of where this topic +is at from my perspective. + +**Mike Schmidt**: There's a couple of things that I pulled up here that are I +think relevant to what you said. One is actually the PR that we're going to be +getting to later, #33106, which makes some changes to relay fee rates. There is +a response in that thread, a comment by 0xB10C, and he actually has a screenshot +of his mainnet observer, and he's got a chart on share of compact block +reconstructions over time. And if you look, you can see very clearly that +there's basically a bunch of green over time, and then all of a sudden it turns +yellow, and all of a sudden it turns this dark orange, meaning that, well, I can +quantify it here in what he says, "In June, we were requesting less than 10 kB +worth of transactions per block on average for about 40% to 50% of blocks. Now, +we are requesting close to almost 1 MB, 0.8 MB worth of transactions per block +on average for about 70% of blocks". So, you now have the visual here, the +green to orange, but you also have those example data points. + +So, when Murch is saying that block reconstruction is slower, this is a way that +someone is monitoring this information. And we'll actually get to that later, +also his monitoring call to action later, and actually seeing this in real data. + +**Mark Erhardt**: Yeah, this is especially interesting in the context of the +engineering that's gone into enabling miners to build their own templates at +home. We want blocks to propagate as quickly as possible to all participants in +the network, because miners are participants in the network and they should +switch to the new best chain tip as fast as possible. We expect an interval +between blocks of 600 seconds. So, if it takes them six seconds to switch +between a block being found and them mining on top of this new block, that's +roughly 1% of revenue lost, right? And it's a 6-second interval in which miners +are working on the old chain tip, and it's more likely for stale blocks to +appear. So, of course, with the delay, very likely most of the other miners +have already received the prior announced block, the first block that was found. +So, it increases the window in which people waste work. And it is my opinion +that this especially affects nodes that are less well-connected. + +So, if people are building their block templates at home, I think that they +would have a significantly higher delay than large mining operations that +centrally organize block templates. To make mining as fair as possible, where +people receive close to exactly their proportion of the hashrate in revenue, +requires that the delays are small, that people can quickly learn about new +blocks and switch and not waste work. And especially when stale blocks occur, +larger mining operations have a big advantage in winning that race because they, +of course, mine on their own blocks. So, if someone has, say, 30% of the +hashrate, 30% of the hashrate is going to work on their own template to build +the best blockchain from that. The rest of the 70% of the hashrate is split +between whoever found the competing block when they learn about it, because +usually the miners always mine on whatever block they first hear about. So, a +well-connected, big mining operation that has 30% of the hashrate will very +likely push out on many different nodes, quickly make that first hop to many +different peers, and smaller miners tend to just lose that stale block race much +more often. + +So, this delay makes the advantage that bigger mining operations have already +worse. And that's one of the reasons why block propagation is a concern for +Bitcoin Core contributors. + +**Mike Schmidt**: Murch, am I thinking about it right that if you have this +delay, where let's say the larger miners are well-connected and are able to push +out blocks to each other fairly quickly, maybe they know who each other are via +contractual agreements, or maybe they know just from spying or some other such +analytics, that they get to each other quickly. But I think what you're saying +is that these blocks then get to the smaller miners slowly, which somewhat has a +similar effect as selfish mining, right, because whether the miner is purposely +not disclosing the block to the broader network or whether it's just an artifact +of the P2P network that the block is delayed, the effect is the same, that you +have large miners that are able to immediately start building on the new chain +tip, whereas the smaller miners are disadvantaged, and all the negatives that +come with that that you pointed out. + +**Mark Erhardt**: Yeah, that's exactly what I'm saying. + +**Mike Schmidt**: Okay, that makes sense. This reminded me when we spoke with +AJ, and I'll just insert it again here for the audience, it reminded me of the +weak blocks proposal that Greg Sanders came out with. And I'll remind people, +as I reminded myself a second ago when I brought up the transcript of our +discussion, why not weak blocks? Don't I want to see what the miners are going +to mine, because they are the ones who are mining? And AJ pointed out two +downsides to that approach. One is, you're going to get biased; only the big +miners are probably the ones you're going to get these weak blocks from. The +bigger the miner, the more weak blocks you're going to get from them, so that's +one downside. Whereas if it's truly P2P nodes, then you're going to get a more +diverse set of potential block templates. And then the other disadvantage was +just timing. If you can choose every so often to ping one of your peers, you +get a more refreshed version of block templates than you would if maybe six +minutes ago, you had a weak block from a minor and that data becomes stale after +a short period of time. So, you sort of want more regular refreshes. Was that +your takeaway as well? Do you remember that? + +**Mark Erhardt**: Yes. So, weak blocks would work by basically setting a lower +threshold for making an announcement what you're working on, right? So, you +might at 20% or 10% of the current actual difficulty. If you surpass that, you +announce a weak block. So, we would expect roughly 10 weak blocks per block. +But just like a large miner is very likely to find the next block proportionally +to the hashrate they bring to the table, if we're doing things right, they would +also be much more likely to offer the weak blocks. So, a smaller mining +operation with just a few rigs would be much less likely to announce their +perspective of the network. So, we wouldn't get this sort of, "What do my peers +think? What would my peers be able to relay immediately?" We can't ask just at +random times whenever we want that data, we would get it randomly whenever a +weak block is found. And potentially, depending on what difficulty you set, it +would be a lot more data floating around, because if weak blocks diverge +drastically, we would perhaps get several of these and store them. + +So, I think this proposal makes sense in the amount of control the node has in +how often they want to request it, how much of that they want to store, what +they do with it, do they add it to their mempool or just keep it in a side data +structure. So, yeah, the advantage of weak blocks would be, of course, that +it's proof-of-work protected. So, it would be hard to spam it because you +actually have to do the work. But yeah, that's roughly the overview. + +**Mike Schmidt**: I think it was you that had brought it up in our discussion +with AJ, but we noted it here at the bottom of the write-up, about this idea of +using set reconciliation, potentially using something like minisketch, which +people have talked about with Erlay for transaction relay, to do that here. Is +that something that's in the BIP or in consideration at this point, or just it's +easier to use compact block messages as they are today and don't mess with +minisketch? + +**Mark Erhardt**: Right, so minisketch is used in Erlay and maybe it's also good +to draw a comparison with Erlay. Erlay is proposing to reconcile what you would +be announcing to your peer with what the peer would announce to you. So, +instead of what you have in the mempool, these are the new things that you would +be announcing to each other. And because you're both online at the same time +and you hear network messages from peers, these sets should be largely +overlapping, and reconciling them takes only a very little amount of data. You +only have to send as much as the difference between the two sets for Erlay to +work well. The approach here is potentially sending the entire top 2 +mega-vbytes of the mempool. For example, when a node just came back online and +he asked his first peer, "Hey, what do you have in your mempool? Can you give +me the top of the mempool?" they don't have anything, so you would have to send +all of the data anyway. There is no big overlap already that makes minisketch +very efficient. + +With this, it might be 100% difference. Or, let's say a node that accepts +low-feerate transactions talks to one that doesn't, or a node that accepts +inscriptions talks to one that doesn't accept inscriptions; they might diverge +on 20% to 40% of the top of their mempool because we have roughly 20% +inscription transactions and 40% low-feerate transactions right now, right? So, +these are huge differences and reconciling them would be not very efficient with +minisketch, is my understanding. + +**Mike Schmidt**: Okay. Maybe one more question. If this was deployed today +and then the network started mining, let's say I want to have 1 sat/vB (satoshi +per vbyte) as my min relay, and the network, in conjunction with a lot of the +miners, decides we're going to start mining 0.1 sat/vB transactions, so all of a +sudden I would start seeing these block templates coming to me that are being +shared with that lower feerate. And so, that would not go into my mempool in +this mechanism, right? It would go to a separate data structure and that would +be stored there. So, just if I'm getting this right, we would then have the +mempool, the orphanage, the vExtra, and then this block template sharing as +holding pens for transactions that are unconfirmed. Do I have that right? + +**Mark Erhardt**: Well, as I said, the proposal doesn't really specify a new +data structure yet. It just talks about these messages. But there has been a +lot of talk about something called the extrapool, which Bitcoin Core uses to +keep some of the recently removed transactions. So, for example, when you see +an RBF, like one transaction is replaced by another transaction that pays a +higher fee, but they both spend the same inputs RBF, then it very much depends +on when the next block comes in and whether the miner already saw that +replacement for the block template or didn't. So, very often, the prior version +of a transaction before it got replaced is in the block instead of the +replacement, if the template was built a few seconds ago, or something like +that. So, the idea behind the extrapool was to have a place where you can cache +some of the latest changes in your mempool in case a block comes in right after +the mempool changed. + +So, some people discussing recent matters on the internet have been arguing that +this would also help with other things that are rejected from their mempool. +But maybe just to explain how the extrapool is set up in Bitcoin Core, it's a +very small, simple data structure that in Bitcoin Core by default only holds 100 +transactions. It will, however, keep transactions that take up to 100 kB of +memory. So, with all the overhead of deserializing it and the context and the +UTXOs that were loaded in order to test the inputs and the whole data structure +for storing the transaction in their mempool, it's not about the serialized +size, but the size of what the mempool spends, or what the mempool data +structure takes in memory, right? So, Bitcoin Core will store 100 times 100,000 +memory bytes. And so, if you drastically increase that, the data structure is +not really designed for that. There is no DoS protection, there is no cycling +or anything. It just probably lets first in, first out. + +**Mike Schmidt**: And would that happen now? Is that where policy-violating +transactions go now, including low feerate? + +**Mark Erhardt**: I think that is the case, but well low feerate you would never +get anyway. When you start up a reasonably recent version of Bitcoin Core, and +I think we're referring to any since 0.13, it will communicate with its peers a +min fee filter, and the min fee filter will indicate to the peer what the lowest +feerate transaction is that you're interested in. So, your peers will simply +not send you transactions below that. It's basically pre-emptive rather than +reactive. So, yeah, you'll actually not have low-feerate transactions in the +extrapool because you shouldn't be getting them in the first place. This might +work for something like an inscription transaction if your node rejects an +inscription transaction though. But for context, a block has usually around +3,000 to 4,500 transactions, and by count I think 20% of the transactions have +inscriptions still. So, we're talking about 900 transactions here missing. And +by default, the extrapool stores 100 of all of the transactions that recently +dropped from the mempool, not the top mempool, right, not the next block. So, +it might help a little bit, but it doesn't solve the issue with the delay. You +will not have all of what you're missing from a block in your extrapool, even if +you blow up the limit very drastically. + +**Mike Schmidt**: So, back to AJ's template sharing, the fee filter would have +to be ignored for purposes of block template sharing, so that you could get in +this hypothetical scenario the low-feerate transactions that are below your +limit? + +**Mark Erhardt**: Right. However, reminder here, it gives you the top two +blocks of data. So, your mempool would basically be empty at that point because +you don't accept these lower-feerate transactions. Your peer thinks that these +lower-feerate transactions are in the top of the mempool and likely to be mined +in the next couple blocks, and is just giving you the short IDs of those +transactions. Then your node could still say, "Okay, do I want them? Do I not +want them? Do I request that inventory?" And then in that case, your node +might store the top two blocks' worth of transactions in a separate data +structure. So, currently looking at the mempool, for example, the top two +blocks do not have transactions below 1 sat/vB. So, you wouldn't get them in +that case, right? In that case, you would only hear about transactions you'd be +accepting anyway. + +**Mike Schmidt**: Yeah, unless someone just hijacks this sendtemplate to send +things that aren't in the top two blocks. + +**Mark Erhardt**: Sure, but then you'd probably stop requesting their templates. + +**Mike Schmidt**: Yeah, I was thinking if there's a scoring mechanism or +something, if someone's just sending you a bunch of it. + +**Mark Erhardt**: Again, this is just about the new sendtemplate P2P message and +how the data structure for the template might work. How this new peer service +would be used by implementations is not currently part of the discussion yet, +and I don't think there's a draft for that yet. Most certainly, it's not +deployed anywhere yet. + +**Mike Schmidt**: Well, hopefully we'll have AJ on if we get to that point, +answering all my questions. But I think we did pretty well on this news item. +I think we can wrap it up. + +**Mark Erhardt**: Sure. + +_Trusted delegation of script evaluation_ + +**Mike Schmidt**: The second and last news item this week is, "Trusted +delegation of script evaluation". News item was inspired by Josh Doman's post +to Delving Bitcoin about something that he wrote, a library that would use TEE, +which is a Trusted Execution Environment. I think in this example, it was an +Amazon Web Services enclave that would only sign keypath spends if the +transaction containing that spend satisfies a particular script. And I think in +his scheme, that script could be things that include opcodes that are not in +Bitcoin potentially, and that that TEE would contain the logic to execute that +opcode and sign accordingly. + +**Mark Erhardt**: Or even completely different languages. + +**Mike Schmidt**: Yeah. + +**Mark Erhardt**: So, your TEE could evaluate a Simplicity Script and check +whether you can satisfy the Simplicity Script. And if so, it would return you a +keypath signature so you can spend the thing. So, yeah, I didn't get a chance +to talk much to Josh last week about this, but my understanding is that it's +sort of a way how you could experiment on these potential future changes to +Bitcoin's consensus engine. And you both get a fee savings, because presumably +the script that the TEE is evaluating would be much bigger and more complicated, +but then the onchain footprint would only be a simple keypath spend, a P2TR +single-sig spend. And you can set up your TEE to work however you want your TEE +to work, and you could make it run opcodes already that aren't present yet, or +make it run languages that haven't been forked in yet. And that way you could, +on mainnet, have wallets that have this TEE set up in the background and check +whether you're able to satisfy these future potential hypothetical changes to +Bitcoin and execute the transaction based on that. + +Now, the downside, the very obvious downside to this is you trust the TEE that +it actually does what it's supposed to do; and then, you also trust that the TEE +is going to continue to be available, because if the TEE is gone, your script +will not execute on the chain proper rather. So, you might set it up with a +fallback so it can be spent after some time with other security assumptions, +just regular Bitcoin Script. I like the idea as a way out of the box, "Hey, how +could we play around with these things people have been talking about for the +last five years?" + +**Mike Schmidt**: It comes down to 'trusted', the name, 'trusted', right? + +**Mark Erhardt**: I mean, yeah, sure. But you're setting up the TEE for your +service and whoever wants to start doing that. It's pretty obvious you're doing +something else than vanilla Bitcoin there. So, I very much assume that people +are in the picture of what trust trade-offs they're making there. + +**Mike Schmidt**: It reminds me, Murch, of Green wallet, for example, that I +think would co-sign your transaction. I think it was a 2-of-2. You had one key +and then Green or Blockstream, or whomever, had the other, and then you would do +a transaction. But you would have to do some form of 2FA or some other way to +verify that. + +**Mark Erhardt**: Yeah, out-of-band authentication too. + +**Mike Schmidt**: Yeah, exactly. So, this is basically out-of-band execution of +Bitcoin Script or other languages, as opposed to just sending a four-digit code, +or whatever it may be. I think it sounds like the difference here is that the +TEE would be the sole signer, or there some sort of a MuSig here? + +**Mark Erhardt**: Yeah, I think it's the sole signer, but I guess you could set +it up in various ways, right? You could do a MuSig. I don't know if it's +implemented yet, but yeah, that's a pretty good simile. + +_ZEUS v0.11.3 released_ + +**Mike Schmidt**: Moving on to our monthly segment on Changes to services and +client software, we have a handful this week. We have Zeus v0.11.3 being +released, which includes improvements to its peer management, LN peers, +improvements to its BOLT12 support, and also additional submarine swap features. + +_Rust Utreexo resources_ + +Rust Utreexo resources. Abdel was here twice this week. This is the first one +where he posted this Rust-based resource for Utreexo. So, there's interactive +educational materials, he's got some WASM bindings, and he's got a website that +puts it all together as well. So, there's, I think, three different +repositories for this that you can check in to learn more about Utreexo and play +around with it a bit. So, good to see, along with the Utreexo BIPs. + +**Mark Erhardt**: And the Utreexo BIPs getting numbers. + +**Mike Schmidt**: Getting numbers, yeah. + +**Mark Erhardt**: Yeah, they're #181 through #183. + +_Peer-observer tooling and call to action_ + +**Mike Schmidt**: Peer-observer tooling and call to action. So, I sort of +mentioned 0xB10C earlier and some of the research he was able to timely put out +to the community on a PR that was open. Well, he posted a quite comprehensive +blogpost on his blog about the motivation for peer-observer, which is one of his +tools. He had an overview of the architecture, the code, the supporting +libraries that he uses, and also findings that have come out of this +peer-observer project. And he didn't push it hard that I've seen, but I did see +that there was a call to action here. 0xB10C wants to build, "A loose, +decentralized group of people who share the interests of monitoring the Bitcoin +Network. A collective to enable sharing of ideas, discussion, data, tools, +insights, and more". + +I wanted to put that along with the post because my feeling is that listeners +and readers of the transcript to this podcast are the type of people who would +think that that would be fun to do and might want to contribute to something +like that. So, this is a call to you who are listening. If you think that a +lot of this stuff that 0xB10C has come up with is cool, maybe you don't love +jumping and splunking into C++, but you want to contribute to Bitcoin in some +way, maybe trying to figure out this peer-observer thing would be cool, and +spinning up some of those and logging some of that data and collaborating in a +decentralized way with 0xB10C and some other folks would be a cool way to +contribute. + +**Mark Erhardt**: Yeah. And as a callback to the news items earlier, his data +has been instrumental for us to know what sort of stuff is going on. He has +been talking about nodes that monitor, like other node operations that monitor +traffic on the Bitcoin Network. He described forking events; he's found out +that AntPool & Friends is a thing; he has also all the data on the block +reconstruction, and so forth. This is super-valuable information for Bitcoin +developers to make decisions and be informed about what's going on in the +network. + +**Mike Schmidt**: Yeah, so if you see people on social media talking about what +activity is or is not happening on the network, obviously you can look at things +like mempool.space to get some idea, but there's people running several nodes, +different versions, different settings, to see how the network is behaving under +certain situations. And so, if you don't want to just pontificate on social +media about what's happening on the Bitcoin Network, but you want to be more +rigorous in your data and analysis, maybe check this out. + +_Bitcoin Core Kernel-based node announced_ + +Bitcoin Core Kernel-based node announced. So, this is Bitcoin backbone, which +was announced. It's announced as a demonstration of using the Bitcoin Core +Kernel library, also known as the libbitcoinkernel. + +**Mark Erhardt**: Not to be confused with the implementation, Libbitcoin. This +is a library in Bitcoin Core that has a lot of the P2P stuff and the consensus +code. + +**Mike Schmidt**: And so, someone took that library and used it as the basis of +building a different node implementation as a demonstration. I think it's in +Rust. So, I think it's cool that we're even at the point where this could be +done. And so, I guess that's a little signpost along the way for folks who are +following the kernel project, that it's at the point where someone can do a demo +node. + +_SimplicityHL released_ + +SimplicityHL released, which is a Rust-like programming language. I think it's +just higher level, I think at HL, but it compiles down to the lower-level +Simplicity language that folks have maybe heard about, that has been researched +for many years over at Blockstream and was recently activated on the Liquid +Network sidechain. And there is a Delving thread that jumps into SimplicityHL +and has jumping off points for you to learn more about Simplicity, and whatnot. + +**Mark Erhardt**: If you're familiar with miniscript, this is sort of how +miniscript policy can be written to compile down to miniscript. So, a more +high-level, logical description of what you want, or in a language that's easier +to reason about, that then compiles down to the machine language. + +_LSP plugin for BTCPay Server_ + +**Mike Schmidt**: LSP plugin for BTCPay Server. So, this is an LSP plugin that +you can put into your BTCPay Server that implements BLIP51, which is the +specification for requesting inbound channels for liquidity. So now, if you're +running BTCPay Server and you need liquidity, you can request channels using +BLIP51. + +_Proto mining hardware and software announced_ + +Proto mining hardware and software announced. I think a lot of folks who are +probably listeners of this podcast are already aware of that. But we did cover +a few years ago that sort of feedback that the Mining Development Kit was +looking for back in the day. That was in Newsletter #260, just over two years +ago, looking for community feedback on this thing that they were building. They +wanted to hear the community's needs. Well, that's been announced. It's now +not the Mining Development Kit, it's called Proto, and it has mining hardware +and open-source mining software. And there is an announcement that we link to +in the write-up that we have in the newsletter that will have all the details +for the mining nerds to geek out on. + +**Mark Erhardt**: Yeah, and I mean I'm not super-plugged into the mining +community, but my understanding is that miners are very excited for a little +more competition in the hardware market there. + +_Oracle resolution demo using CSFS_ + +**Mike Schmidt**: Seems like it. Oracle resolution demo using CSFS. This is +Abdel's second reference in this segment this week. He posted the demonstration +of an Oracle using CSFS (CHECKSIGFROMSTACK). He used nostr and MutinyNet to +sign an attestation of a particular event's outcome. + +_Relai adds taproot support_ + +And our last item, Relai adds taproot support. I remember doing these quite +frequently in years past, but there's still some folks integrating taproot. +This integration is for sending to taproot addresses. And, Murch, I think I +stole this from When Taproot? I think I saw it on your repo getting merged, and +I think I added that. + +**Mark Erhardt**: Yeah, and to be fair, I think this happened quite a few months +ago, it's just not been reported to us. People have not been paying as much +attention to the laggards that still don't support sending to taproot addresses. + +**Mike Schmidt**: Who's left? + +**Mark Erhardt**: Oh, you want me to jump in? + +**Mike Schmidt**: Just give me the top couple. + +**Mark Erhardt**: The top couple? Okay. My understanding is that Binance still +can't send to taproot, Crypto.com, Paxful, PayPal, Robinhood, and Venmo can't +send to taproot addresses. So, yeah, we mostly keep the biggest names on there +still. We're not going after every single little one, but is it the four-year +anniversary of taproot is coming up soon? So, we have had over 50% of outputs +be paid to taproot outputs in blocks. So, I don't know, maybe you want to send +to it! + +**Mike Schmidt**: Well, I don't know how much transaction volume they do +onchain, those services, but they're definitely big names and it would be great +to have them adopt for you. + +**Mark Erhardt**: I mean, at some point it is no longer a question of whether +they have already adopted it, but just on them. + +_LND v0.19.3-beta_ + +**Mike Schmidt**: Yeah. Releases and release candidates. LND v0.19.3 beta. We +actually covered the RC for this release pretty well in Podcast #366. So, I +would refer listeners back to that episode for the details, or of course check +out the release notes. + +_Bitcoin Core 29.1rc1_ + +Bitcoin Core 29.1rc1. RC2 is actually out now, and I would refer to previous +episodes where we discussed features in this RC with Murch and also with Gloria +in previous podcasts. + +**Mark Erhardt**: And it looks like RC2 is probably going to be the final. So, +29.1 will be released pretty soon probably. + +_Core Lightning v25.09rc2_ + +**Mike Schmidt**: Great. Core Lightning v25.09rc2. Well, for this RC, I'm +actually going to refer listeners to an already recorded future episode of our +Optech podcast, where we covered the final version of this release. That was in +Optech Podcast #369. You're listening to #368. And for various technical +issues, we happened to record that episode before this one. And the RC was +dropped and it's a full release, and we went through some of the features in +#369. + +_Bitcoin Core #32896_ + +Notable code and documentation changes. Bitcoin Core #32896, which adds v3 +transaction creation and wallet support. Murch? + +**Mark Erhardt**: Yeah, so we got TRUC as a paradigm or idea a while back. TRUC +stands for Topologically Restricted Until Confirmation. TRUC transactions are +only allowed to have either an unconfirmed parent transaction or one unconfirmed +child transaction, so they at most come in packages of two transactions, and +they are restricted in the size. So, a parent transaction may only have 10 kvB +(kilo-vbytes) and a child transaction may not have more than 1,000 vB. So, with +those restrictions, coin selection becomes a little funky because if you have +confirmed funds, they're fine. You can use any confirmed funds that you want to +spend, but you can only have unconfirmed outputs from a single parent +transaction. And if you're relying on unconfirmed UTXOs to build a TRUC +transaction, the coin selection, or rather, which coins are even available for +coin selection, are restricted. And you can't use unconfirmed outputs from +multiple transactions at the same time. + +So, what this PR does is it addresses all of these concerns and adds support for +several of the send RPC commands, which is createrawtransaction, createpsbt, +send, sendall and walletcreatefundedpsbt, so that if you're building a +transaction that spends unconfirmed UTXOs, it would manage to keep within the +restrictions of TRUC transactions if you're building a TRUC transaction. And +you can use these opcodes with the TRUC restriction by parsing the transaction +version in a parameter now, and then it'll hopefully just work. + +_Bitcoin Core #33106_ + +**Mike Schmidt**: Bitcoin Core #33106, we referenced it earlier when we talked +about 0xB10C's chart showing block reconstructions not going well recently. +This PR lowers the default blockmintxfee, incrementalrelayfee and minrelaytxfee. + +**Mark Erhardt**: Let me first jump in here already. Pet peeve of mine is that +all of these variables are named '... fee'. But really they're referring to +feerates, as you can see from the numbers that are presented afterwards and +their units. So, blockmintxfee, which should be feerate, is the feerate at +which we consider transactions for the block template. So, if you are running a +miner that might want to accept lower feerate transactions into their mempool +for building blocks, but for some reason does not want to include them in your +block template, you can use this configuration option to change what you build +your templates from, even if you do allow them into your mempool. Other than +this, minrelaytxfee is the feerate that you use as the minimum feerate for what +you accept into your mempool; and incrementalrelayfee is the feerate that you +require a replacement to pay more in order to replace the original. So, these +two used to be even the same configuration option. They got split a few years +ago because some people might want to set them separately. But generally, the +minrelaytxfee is what we think of as a minimum cost that someone has to put up +in order to get the data transmitted across the network. So, if you replace +something with a higher-feerate-paying transaction, this is also what we require +you to pay again in order to replace stuff and transmit data across the whole +network again. + +I think early July maybe, don't quote me on this yet, but I think early July, we +started seeing the first significant amount of transactions below the +minrelaytxfee be included in blocks. And as we discussed earlier already, +people started reporting that the compact block reconstruction rate was +cratering. We can see that in various other monitors, for example, there's a +university in Germany that has been monitoring block and transaction propagation +on the Bitcoin Network for a long time, and you can just see that the delays by +which blocks get distributed to listening nodes have gone up. So, with now over +40% of transactions in blocks being below the previous min transaction fee, this +PR changes the minrelaytxfee and the incrementalrelayfee to a 10th of the +previous value, to 0.1 sat/vB, and the default for a blockmintxfee is lowered to +the minimum, because blockmintxfee, I think it was introduced before the +minrelaytxfee and when we still had the coin-age priority. That's a callback. + +So, there was a way of selecting, I think it was a 10th of the block, by +basically assigning nobility to all UTXOs. You would multiply the amount of +money that was being spent with the number of confirmations that UTXO had. And +then, you'd fill a 10th of the block just with really old UTXOs and large +amounts. So, if you had really big UTXOs, they would also have coin-age +priority much quicker than smaller UTXOs, but then after that, also the age +would contribute. So, that was a really strange, weird way of composing blocks +that was present until, I think, 0.12, which is about ten years ago now. +Anyway, blockmintxfee was introduced so miners could require a minimum fee for +what they put in their block templates and basically not do this. Oh yeah, +coin-age priority was used to accept zero-fee transactions that had really old +coin-age priority. So, anyway, this is a little old stuff. + +Our idea is, if something gets in your mempool and you expect that to be mined +frequently, you source from your mempool, which is already filtered for what you +expect to be the acceptable transactions. That's what you use to build your +template. So, blockmintxfee is essentially no longer a more constrained +variable than the minrelayfee and takes a bit of a secondary role there. +Obviously, you can still configure it differently if that's what you want to do. + +**Mike Schmidt**: Murch, can you help me understand why incrementalrelayfee also +changed? I understand the minrelay motivation per our discussion, but that's +sort of like where you start your bidding for blockspace; whereas incremental +feerate is the granularity at which you can increase the fee. And it seems like +I don't understand why we want to change the granularity of fee bumping along +with where we start our bids. + +**Mark Erhardt**: Right, okay. So, let's think of a situation. We have two +nodes, Alice and Bob. Alice accepts 0.1 sat/vB and has an incrementalrelayfee +of 1 sat/vB, the old incrementalrelayfee. Bob has not updated yet and both +values are 1 sat/vB. Now, if someone broadcasts a transaction at 0.1 sat/vB, +Alice accepts it, Bob doesn't, and then they RBF it, and they RBF it to 1.1 +sat/vB, because they have to RBF it by at least 1 sat/vB. Now, Bob will get it +and Alice will get it and everybody has the same mempool again. Now, if the +sender of the transaction instead bumped it to replace it with a 1 sat/vB +transaction, only Bob would accept it and Alice wouldn't accept the replacement. +So, if minrelaytxfee is the feerate that we expect people to put up in order to +relay data across the network, it makes sense for the increment to also be +lowered to this point. + +**Mike Schmidt**: Okay, I see. And is there a point where that changes? You +know, obviously we had the feerate spike a few years ago, like we were at 500 +sat/vB. And so now, is it still incremental bumping of 0.1 all the way up to, +let's say, 600 sat/vB? + +**Mark Erhardt**: Yeah, the incremental is flat. I found it extremely strange +that miners actually started accepting low-feerate transactions, because they +sort of had a minimum cost people were willing to pay and until very recently, +more than willing to pay for blockspace. And not only did they sort of, for a +pittance, remove this very, very stable gentleman's agreement that had been in +place for over a decade; but also, previously when replacements came in, +replacements would increase by 1 sat/vB. And with the minrelaytxfee being +undermined, also I think it was pretty obvious, especially since those two +values were essentially the same thing before, that the incrementalrelayfee is +also going to change. So, not only did they reduce the minimum feerate that +people are going to bid on blockspace, they also reduced the spikiness of +mempool peaks, because now people will replace with only bidding 0.1 sat/vB +more. So, this seems like such a very odd, not considering your own incentives, +that this is a total own goal on miners in my opinion. + +**Mike Schmidt**: So, if I'm a user, I have more granularity in my fee bumping +now, if I'm a normal user, I guess I would say. I can just slowly ratchet up +the feerate and just see what happens, as opposed to bigger jumps, for example. +So, I'm happy. Now, if we're going from 400 or 500 up 100 sats in a bidding +war, I now have 10 times more relay that is going on on the network then, right? +So, instead of going from 400 to 500 and that being 100 placements, now it's +1,000 replacements, right? Do I have that right? + +**Mark Erhardt**: Yeah, I mean, the question is whether people are going to +replace 10 times more often. I think people are going to roughly replace as +often as before. They check back a minute later, "Oh, I've dropped out of the +top 70 of the next block and I want to be in the next block, so I should bump", +and then they bump back to, I don't know, the median of the next block. So, I +don't think that necessarily the frequency with which replacements will be seen +goes up, but the feerate growth from the replacements will be going down. +Perhaps it's not a full 10th that the peaks have been reduced. Maybe people are +willing to bid up higher because they're still used to the prior feerate +considerations. They are still willing to pay a certain amount of money to get +their transaction in, like the value of the fee that they are willing to pay +might still be higher. + +So, yeah, we'll have to see how it plays out in detail, but yeah, there's more +granularity. That's great for users and maybe also to be clear though, so it +looks like maybe there's a few hundred nodes, on the order of 500-ish or so +listening nodes, that currently relay low-feerate transactions. At least at +some point in the recent history, about 80% of the hashrate was including these +transactions. So, there's a bit of an odd situation here where people that do +want to send these transactions can very easily peer up with some nodes that +already accept them, and then they will relay fairly reliably among this sort of +backbone in the Bitcoin Network that has found itself. And they will get to +miners and they will be included in blocks when such feerates make it into +blocks. But if you're a light client, or if you maybe don't have a ton of +peers, a non-listening node or so, it is much more likely that all of your peers +do not accept these transactions. So, you might be blackholed. + +If you create a transaction, someone experimented recently, I saw this on +Twitter, it took them about 72 hours for their node to peer with another node +that accepted low-feerate transactions, and for it to get in. And now, of +course, that they have this peer connection, this peer is sending them a lot of +transactions that are now acceptable to both of these nodes. And when blocks +come in, they might have a functioning compact block reconstruction because they +have all of these missing transactions. So, this peer will be considered +valuable to the node because it is one of the first nodes that gives them the +new block, right? So, once the relationship between nodes is formed, he is now +part of the backbone that relays these transactions. So, what I'm trying to say +is, it might be a little early to set wallet behavior down to lower feerates, +because they might have a bad experience, be eclipsed by peers that don't accept +these transactions, and then their transaction will just linger and not get to +the miners. But for people that are connected to this small portion of the +whole network that relays the transactions, it works perfectly fine. + +So, Bitcoin Core will only change the mempool policy, but the Bitcoin Core +wallet's feerate remains at the 1 sat/vB at this time. And if you do want to +manually create these transactions, you do have to manually configure your +wallet feerate to be lower so your wallet will build this, accept a feerate +below 1 sat/vB. So, anyway, it's an interesting phenomenon to watch right now, +especially because the feerate had been stable so long for over ten years. +Obviously, the exchange rate has gone up a magnitude since then. So, dropping +the cost of a transaction a little bit doesn't seem particularly bad. There's +this surprising aspect that miners went along with it. And then, of course, in +the last two years, blockspace was almost entirely demanded. So, I wasn't +really expecting lower feerates to come into play. It just seemed unnecessary, +because people were willing to pay more anyway. Yeah, that's an interesting +thing to look at right now. + +_Core Lightning #8467_ + +**Mike Schmidt**: Yeah, interesting development. Core Lightning #8467. This PR +adds BIP353 Human Readable Name support to Core Lightning's (CLN's) xpay +feature. So, now you can use an email-address-looking identifier, like +mike@bitcoinops.org, to make a BOLT12 offer payment to someone like me! + +**Mark Erhardt**: Well, obviously, once these people have set up the information +in their DNS for their domain and provide payment instruction there. + +_Core Lightning #8354_ + +**Mike Schmidt**: Which I haven't, so don't try this. Core Lightning #8354. +This PR adds events for when a payment or part of a payment begins, and another +event for when that part of the payment ends, along with the success or failure +status with the end notification. So, these two notifications are now emitted +from CLN's xpay function, and these changes were partially motivated by a CLN +user that suggests, "Xpay needs to tell us about what it is doing so we can set +biases in created layers and tune the pathfinding behavior". + +_Eclair #3103_ + +Eclair #3103 adds support for simple taproot channels, which are channels that +use taproot and MuSig2 in the cooperative case, and has benefits of smaller +sizes and improved privacy. Included in this PR is also, "Support for dual +funding and splicing has also been implemented through extensions to the +interactive transaction construction protocol". Seems like a cool PR, important +PR, lots of buzzwords, 'simple taproot channels', 'MuSig2', 'dual-funding', +'splicing', and 'interactive transaction construction'. + +_Eclair #3134_ + +Eclair #3134. This is a PR titled, "Use CLTV expiry when computing reputation". +This is part of the reputation and HTLC (Hash Time Locked Contract) endorsement +efforts that we've covered this past year, including Eclair research and other +implementations, implementing various versions of this endorsement. Eclair is +changing their scoring here to get away from their previously fixed multiplier +approach, and they moved instead towards using the CLTV (CHECKLOCKTIMEVERIFY) +expiry. of the HTLC. I'm not sure I understood all that, but I will quote from +the PR, "The reason for the fixed multiplier was that an HTLC with the maximum +CLTV delta could stay pending for several orders of magnitude longer than a +regular HTLC, and would have an oversized impact on the reputation. We mitigate +this by increasing the expected settlement time (from a few seconds to a few +minutes), using more historical data, (increasing the half-life), and counting +on the fact that most HTLCs will have a CLTV expiry a lot lower than the +maximum". + +_LDK #3897_ + +Last PR this week is to LDK, LDK #3897, which is part 3 of LDK's peer storage +project. Peer storage, as a reminder, is a Lightning feature where a node can +store state data for its peers, and then provide that data back as a backup in +case the data is lost on its peers' side. This particular PR adds features to +LDK to determine if the user has lost channel state so that LDK can do something +about it. "The main idea here is just enable node to figure out that it has +lost some data using peer storage backups". So, it seems like it's just +identifying that state has been lost and not necessarily any mitigations within +this PR. The fact that this is called part 3 and it references a couple of +future works, maybe the mitigations are done elsewhere in the future. + +Murch, anything else on your side? + +**Mark Erhardt**: That's all I had. + +**Mike Schmidt**: All right. Well, Murch, I'm sorry to you and our guests that +were unable to complete this recording last week. I'm glad you were able to +join me today to go through #368 with me this time. Thank you all for +listening. We'll hear you next week. + +**Mark Erhardt**: Hear you soon. {% include references.md %} From af9d1b433b8b69da509bdb28876057a03616ae00 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sat, 13 Sep 2025 09:33:19 +0200 Subject: [PATCH 247/278] Create 2025-09-12-newsletter.md --- .../fr/newsletters/2025-09-12-newsletter.md | 103 ++++++++++++++++++ 1 file changed, 103 insertions(+) create mode 100644 _posts/fr/newsletters/2025-09-12-newsletter.md diff --git a/_posts/fr/newsletters/2025-09-12-newsletter.md b/_posts/fr/newsletters/2025-09-12-newsletter.md new file mode 100644 index 0000000000..9d11056688 --- /dev/null +++ b/_posts/fr/newsletters/2025-09-12-newsletter.md @@ -0,0 +1,103 @@ +--- +title: 'Bulletin Hebdomadaire Optech #371' +permalink: /fr/newsletters/2025/09/12/ +name: 2025-09-12-newsletter-fr +slug: 2025-09-12-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine annonce la disponibilité d'un cahier d'exercices dédié à la +cryptographie prouvable. Sont également incluses nos sections régulières résumant les +changements récents apportés aux clients et services, les annonces de nouvelles versions +et de candidats à la publication, et les résumés des modifications +notables apportées aux logiciels d'infrastructure Bitcoin populaires. + +## Nouvelles + +- **Cahier d'exercices sur la Cryptographie Prouvable :** Jonas Nick a [publié][nick workbook] sur + Delving Bitcoin pour annoncer un court cahier d'exercices qu'il a créé pour un événement de quatre + jours visant à "enseigner aux développeurs les bases de la cryptographie prouvable, [...] comprenant + des définitions cryptographiques, des propositions, des preuves et des exercices." Le cahier + d'exercices est disponible en tant que [PDF][workbook pdf] avec une [source][workbook source] + sous licence libre. + +## Mises à jour et versions candidates + +_Nouvelles versions et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de mettre à niveau vers les nouvelles versions ou d'aider à tester les versions candidates._ + +- [Bitcoin Core 29.1][] est la sortie d'une version de maintenance du logiciel de nœud complet + prédominant. + +- [Eclair v0.13.0][] est la sortie de cette implémentation de nœud LN. Sa sortie contient beaucoup + de refactorisation, une implémentation initiale des canaux taproot, [...] des améliorations au + splicing basées sur des mises à jour récentes de spécification, et un meilleur support de Bolt 12." + Les fonctionnalités de canaux taproot et de splicing sont encore en cours de spécification, donc + elles ne devraient pas être utilisées par les utilisateurs réguliers. Les notes de version + avertissent également : "Ceci est la dernière sortie d'eclair où les canaux qui n'utilisent pas les + anchor outputs seront supportés. Si vous avez des canaux qui n'utilisent pas les anchor outputs, + vous devriez les fermer." + +- [Bitcoin Core 30.0rc1][] est une candidate à la sortie pour la prochaine version majeure de ce + logiciel de nœud de vérification complète. + +## Changements notables dans le code et la documentation + +_Changements notables récents dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning +repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], +[Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Propositions d'Amélioration de Bitcoin (BIPs)][bips +repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin +inquisition repo], et [BINANAs][binana repo]._ + +- [Bitcoin Core #30469][] met à jour les types des valeurs `m_total_prevout_spent_amount`, + `m_total_new_outputs_ex_coinbase_amount` et `m_total_coinbase_amount` de `CAmount` (64 bits) à + `arith_uint256` (256 bits) pour prévenir un bug de dépassement de valeur par défaut qui a déjà été + observé sur le [signet][topic signet]. La nouvelle version de l'index des statistiques de pièces est + stockée dans `/indexes/coinstatsindex/` et un nœud mis à niveau devra se synchroniser à partir de + zéro pour reconstruire l'index. L'ancienne version est conservée pour une protection de la rétrogradation, + mais pourrait être retirée dans une future mise à jour. + +- [Eclair #3163][] ajoute un vecteur de test pour s'assurer que la clé publique d'un bénéficiaire + peut être récupérée à partir d'une facture [BOLT11][] avec une signature high-S, en plus de + permettre déjà les signatures low-S. Cela s'aligne sur le comportement de libsecp256k1 et la + proposition [BOLTs #1284][]. + +- [Eclair #2308][] introduit une nouvelle option `use-past-relay-data` qui, lorsqu'elle est définie + sur vrai (par défaut faux), utilise une approche probabiliste basée sur l'historique des tentatives + de paiement passées pour améliorer la recherche de chemin. Cela remplace une méthode antérieure qui + supposait une uniformité dans les soldes des canaux. + +- [Eclair #3021][] permet au non-initiateur d'un [canal à double financement][topic dual funding] de + [RBF][topic rbf] la transaction de financement, ce qui est déjà autorisé dans les transactions de + [splicing][topic splicing]. Cependant, une exception s'applique aux transactions d'achat de + [publicité de liquidité][topic liquidity advertisements]. Cela a été proposé dans [BOLTs #1236][]. + +- [Eclair #3142][] ajoute un nouveau paramètre `maxClosingFeerateSatByte` à l'endpoint API + `forceclose` qui remplace la configuration globale de feerate pour les transactions de fermeture + forcée non urgentes sur une base par canal. Le paramètre global `max-closing-feerate` a été + introduit dans [Eclair #3097][]. + +- [LDK #4053][] introduit des canaux d'engagement sans frais en remplaçant les deux sorties d'ancre + par une sortie [Pay-to-Anchor (P2A)][topic ephemeral anchors] partagée, plafonnée à une valeur de + 240 sats. De plus, il passe les signatures HTLC dans les canaux d'engagement sans frais à + `SIGHASH_SINGLE|ANYONECANPAY` et augmente les transactions HTLC à [version 3][topic v3 transaction + relay]. + +- [LDK #3886][] étend `channel_reestablish` pour le [splicing][topic splicing] avec deux TLVs + `funding_locked_txid` (ce qu'un nœud a envoyé et reçu en dernier) afin que les pairs puissent + concilier la transaction de financement active lors de la reconnexion. De plus, il rationalise le + processus de reconnexion en renvoyant `commitment_signed` avant `tx_signatures`, en gérant + `splice_locked` de manière implicite, en adoptant `next_funding`, et en demandant des signatures + d'annonce au besoin. + +{% include snippets/recap-ad.md when="2025-09-16 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="30469,3163,2308,3021,3142,4053,3886,1284,1236,3097" %} +[bitcoin core 29.1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[bitcoin core 30.0rc1]: https://bitcoincore.org/bin/bitcoin-core-30.0/ +[nick workbook]: https://delvingbitcoin.org/t/provable-cryptography-for-bitcoin-an-introduction-workbook/1974 +[workbook pdf]: https://github.com/cryptography-camp/workbook/releases +[workbook source]: https://github.com/cryptography-camp/workbook +[Eclair v0.13.0]: https://github.com/ACINQ/eclair/releases/tag/v0.13.0 \ No newline at end of file From d076e5ef80c6e252c19bac92bcee8166106cd899 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Mon, 15 Sep 2025 11:16:25 +0200 Subject: [PATCH 248/278] german-newsletter-370 (#2497) Co-authored-by: garfiel-d --- .../de/newsletters/2025-09-05-newsletter.md | 141 ++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 _posts/de/newsletters/2025-09-05-newsletter.md diff --git a/_posts/de/newsletters/2025-09-05-newsletter.md b/_posts/de/newsletters/2025-09-05-newsletter.md new file mode 100644 index 0000000000..7f80924647 --- /dev/null +++ b/_posts/de/newsletters/2025-09-05-newsletter.md @@ -0,0 +1,141 @@ +--- +title: 'Bitcoin Optech Newsletter #370' +permalink: /de/newsletters/2025/09/05/ +name: 2025-09-05-newsletter-de +slug: 2025-09-05-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche enthält unsere regelmäßigen Abschnitte, die +Diskussionen über die Änderung der Konsensregeln von Bitcoin zusammenfassen, +neue Releases und Release-Kandidaten ankündigen und wichtige Änderungen an +beliebter Bitcoin-Infrastruktur-Software beschreiben. + +## Nachrichten + +_Diese Woche wurden in keiner unserer [Quellen][optech sources] wichtige Nachrichten gefunden._ + +## Konsensänderungen + +_Ein monatlicher Abschnitt, der Vorschläge und Diskussionen über die Änderung +der Konsensregeln von Bitcoin zusammenfasst._ + +- **Details zum Design von Simplicity:** Russell O'Connor hat bisher + drei Beiträge ([1][sim1], [2][sim2], [3][sim3]) in Delving Bitcoin + über "die Philosophie und das Design der [Simplicity-Sprache][topic simplicity]" + veröffentlicht. Die Beiträge untersuchen "die drei Hauptformen der + Komposition zur Umwandlung grundlegender Operationen in komplexe + Operationen", "das Typsystem, die Kombinatoren und die grundlegenden + Ausdrücke von Simplicity" und "wie man logische Operationen von Bits + bis hin zu kryptografischen Operationen wie SHA-256 und der + Validierung von Schnorr-Signaturen nur mit unseren rechnerischen + Simplicity-Kombinatoren aufbaut." + + Der jüngste Beitrag deutet darauf hin, dass weitere Einträge in der + Serie erwartet werden. + +- **BIP-Entwurf zur Hinzufügung von Elliptic-Curve-Operationen zu Tapscript:** + Olaoluwa Osuntokun [veröffentlichte][osuntokun ec] in der Bitcoin-Dev-Mailingliste + einen Link zu einem [BIP-Entwurf][osuntokun bip] zur Hinzufügung mehrerer + Opcodes zu [Tapscript][topic tapscript], die es ermöglichen, Elliptic-Curve-Operationen + auf dem Skript-Auswertungs-Stack durchzuführen. Die Opcodes sollen in + Kombination mit Introspektions-Opcodes verwendet werden, um [Covenant][topic covenants]-Protokolle + zu erstellen oder zu verbessern, zusätzlich zu anderen Fortschritten. + + Jeremy Rubin [antwortete][rubin ec1] mit Vorschlägen für zusätzliche + Opcodes, um weitere Funktionen zu ermöglichen, sowie [andere Opcodes][rubin ec2], + welche die Nutzung einiger Funktionen des Basisvorschlags bequemer machen würden. + +- **BIP-Entwurf für OP_TWEAKADD:** Jeremy Rubin [veröffentlichte][rubin ta1] + in der Bitcoin-Dev-Mailingliste einen Link zu einem [BIP-Entwurf][rubin bip] + zur Hinzufügung von `OP_TWEAKADD` zu [Tapscript][topic tapscript]. Er + [veröffentlichte][rubin ta2] separat bemerkenswerte Beispiele für Skripte, + die durch die Hinzufügung des Opcodes ermöglicht werden, darunter ein + Skript zur Aufdeckung eines [Taproot][topic taproot]-Tweaks, ein Nachweis + der Reihenfolge der Signierung einer Transaktion (z. B. muss Alice vor + Bob signiert haben) und die [Delegierung von Signaturen][topic signer delegation]. + +## Releases und Release-Kandidaten + +_Neue Releases und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. +Bitte erwägen Sie, auf neue Versionen zu aktualisieren oder bei der Testung von +Release-Kandidaten zu helfen._ + +- [Core Lightning v25.09][] ist ein Release einer neuen Hauptversion + dieser beliebten LN-Knoten-Implementierung. Es fügt dem `xpay`-Befehl + Unterstützung für die Bezahlung von [BIP353][]-Adressen und einfachen + [Offers][topic offers] hinzu, bietet verbesserte Buchhaltungsunterstützung, + ein besseres Plugin-Abhängigkeitsmanagement und enthält weitere neue + Funktionen und Fehlerbehebungen. + +- [Bitcoin Core 29.1rc2][] ist ein Release-Kandidat für eine Wartungsversion + der führenden Full-Node-Software. + +## Wichtige Code- und Dokumentationsänderungen + +_Wichtige aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], +[Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], und [BINANAs][binana repo]._ + +- [LDK #3726][] fügt Unterstützung für Dummy-Hops auf [verdeckten Pfaden][topic rv routing] + hinzu, sodass Empfänger beliebige Hops hinzufügen können, die keinem + Routing-Zweck dienen, sondern als Täuschung fungieren. Eine zufällige + Anzahl von Dummy-Hops wird jedes Mal hinzugefügt, ist aber auf 10 begrenzt, + wie durch `MAX_DUMMY_HOPS_COUNT` definiert. Das Hinzufügen zusätzlicher + Hops erschwert es erheblich, die Entfernung zum oder die Identität des + Empfängerknotens zu bestimmen. + +- [LDK #4019][] integriert [Splicing][topic splicing] mit dem + [Quiescence-Protokoll][topic channel commitment upgrades], indem ein + ruhiger Kanalzustand vor der Initialisierung einer Splicing-Transaktion + erforderlich ist, wie von der Spezifikation vorgeschrieben. + +- [LND #9455][] fügt Unterstützung für die Zuordnung eines gültigen + DNS-Domainnamens zur IP-Adresse und zum öffentlichen Schlüssel eines + Lightning-Knotens in seiner Ankündigungsnachricht hinzu, wie es die + Spezifikation erlaubt und von anderen Implementierungen wie Eclair und + Core Lightning unterstützt wird (siehe Newsletter [#212][news212 dns], + [#214][news214 dns] und [#178][news178 dns]). + +- [LND #10103][] führt eine neue Option `gossip.peer-msg-rate-bytes` + (Standard 51200) ein, die ausgehende Bandbreite begrenzt, die jeder + Peer für ausgehende [Gossip-Nachrichten][topic channel announcements] + verwendet. Dieser Wert begrenzt die durchschnittliche Bandbreitengeschwindigkeit + in Bytes pro Sekunde, und wenn ein Peer sie überschreitet, beginnt LND, + Nachrichten an diesen Peer in eine Warteschlange zu stellen und zu + verzögern. Diese neue Option verhindert, dass ein einzelner Peer die + gesamte globale Bandbreite verbraucht, die durch `gossip.msg-rate-bytes` + in [LND #10096][] eingeführt wurde. Siehe Newsletter [#366][news366 gossip] + und [#369][news369 gossip] für verwandte LND-Arbeiten zum Ressourcenmanagement + von Gossip-Anfragen. + +- [HWI #795][] fügt Unterstützung für die BitBox02 Nova hinzu, indem die + `bitbox02`-Bibliothek auf Version 7.0.0 aktualisiert wird. Es werden + auch mehrere CI-Aktualisierungen vorgenommen. + +{% include snippets/recap-ad.md when="2025-09-09 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="3726,4019,9455,10103,795,10096" %} +[bitcoin core 29.1rc2]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[core lightning v25.09]: https://github.com/ElementsProject/lightning/releases/tag/v25.09 +[sim1]: https://delvingbitcoin.org/t/delving-simplicity-part-three-fundamental-ways-of-combining-computations/1902 +[sim2]: https://delvingbitcoin.org/t/delving-simplicity-part-combinator-completeness-of-simplicity/1935 +[sim3]: https://delvingbitcoin.org/t/delving-simplicity-part-building-data-types/1956 +[osuntokun ec]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAO3Pvs-Cwj=5vJgBfDqZGtvmoYPMrpKYFAYHRb_EqJ5i0PG0cA@mail.gmail.com/ +[osuntokun bip]: https://github.com/bitcoin/bips/pull/1945 +[rubin ec1]: https://mailing-list.bitcoindevs.xyz/bitcoindev/f118d974-8fd5-42b8-9105-57e215d8a14an@googlegroups.com/ +[rubin ec2]: https://mailing-list.bitcoindevs.xyz/bitcoindev/1c2539ba-d937-4a0f-b50a-5b16809322a8n@googlegroups.com/ +[rubin ta1]: https://mailing-list.bitcoindevs.xyz/bitcoindev/bc9ff794-b11e-47bc-8840-55b2bae22cf0n@googlegroups.com/ +[rubin ta2]: https://mailing-list.bitcoindevs.xyz/bitcoindev/c51c489c-9417-4a60-b642-f819ccb07b15n@googlegroups.com/ +[rubin bip]: https://github.com/bitcoin/bips/pull/1944 +[news212 dns]: /de/newsletters/2022/08/10/#bolts-911 +[news214 dns]: /de/newsletters/2022/08/24/#eclair-2234 +[news178 dns]: /en/newsletters/2021/12/08/#c-lightning-4829 +[news366 gossip]: /de/newsletters/2025/08/08/#lnd-10097 +[news369 gossip]: /de/newsletters/2025/08/29/#lnd-10102 From 4bc6d548d9d7620436ee2950417d6617820991cb Mon Sep 17 00:00:00 2001 From: Walpurga03 Date: Sat, 13 Sep 2025 11:47:54 +0200 Subject: [PATCH 249/278] german-newsletter-371 --- .../de/newsletters/2025-09-12-newsletter.md | 116 ++++++++++++++++++ 1 file changed, 116 insertions(+) create mode 100644 _posts/de/newsletters/2025-09-12-newsletter.md diff --git a/_posts/de/newsletters/2025-09-12-newsletter.md b/_posts/de/newsletters/2025-09-12-newsletter.md new file mode 100644 index 0000000000..a5fb65347a --- /dev/null +++ b/_posts/de/newsletters/2025-09-12-newsletter.md @@ -0,0 +1,116 @@ +--- +title: 'Bitcoin Optech Newsletter #371' +permalink: /de/newsletters/2025/09/12/ +name: 2025-09-12-newsletter-de +slug: 2025-09-12-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche kündigt die Verfügbarkeit eines Arbeitsbuchs an, +das sich der beweisbaren Kryptographie widmet. Außerdem enthalten sind unsere +regelmäßigen Abschnitte mit Links zu neuen Releases und Release-Kandidaten sowie +Beschreibungen wichtiger Änderungen an beliebter Bitcoin-Infrastruktur-Software. + +## Nachrichten + +- **Arbeitsbuch zur beweisbaren Kryptographie:** Jonas Nick [veröffentlichte][nick workbook] + in Delving Bitcoin die Ankündigung eines kurzen Arbeitsbuchs, das er für eine + viertägige Veranstaltung erstellt hat, um "Entwicklern die Grundlagen der + beweisbaren Kryptographie zu vermitteln, [...] bestehend aus kryptographischen + Definitionen, Sätzen, Beweisen und Übungen." Das Arbeitsbuch ist als + [PDF][workbook pdf] mit frei lizenzierter [Quelle][workbook source] verfügbar. + +## Releases und Release-Kandidaten + +_Neue Releases und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. +Bitte erwägen Sie, auf neue Versionen zu aktualisieren oder bei der Testung von +Release-Kandidaten zu helfen._ + +- [Bitcoin Core 29.1][] ist die Veröffentlichung einer Wartungsversion + der führenden Full-Node-Software. + +- [Eclair v0.13.0][] ist die Veröffentlichung dieser LN-Knoten-Implementierung. + Sie "enthält eine Menge Refactoring, eine erste Implementierung von + Taproot-Kanälen, [...] Verbesserungen am Splicing basierend auf den + jüngsten Spezifikations-Updates und eine bessere Bolt-12-Unterstützung." + Die Taproot-Kanal- und Splicing-Funktionen werden noch vollständig + spezifiziert, daher sollten sie von normalen Benutzern nicht verwendet + werden. Die Versionshinweise warnen auch: "Dies ist die letzte Version + von Eclair, in der Kanäle, die keine Anchor-Outputs verwenden, unterstützt + werden. Wenn Sie Kanäle haben, die keine Anchor-Outputs verwenden, sollten + Sie diese schließen." + +- [Bitcoin Core 30.0rc1][] ist ein Release-Kandidat für die nächste Hauptversion + dieser Full-Verification-Node-Software. + +## Wichtige Code- und Dokumentationsänderungen + +_Wichtige aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], +[Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], und [BINANAs][binana repo]._ + +- [Bitcoin Core #30469][] aktualisiert die Typen der Werte + `m_total_prevout_spent_amount`, `m_total_new_outputs_ex_coinbase_amount` und + `m_total_coinbase_amount` von `CAmount` (64 Bit) auf `arith_uint256` + (256 Bit), um einen Wertüberlauffehler zu verhindern, der bereits auf dem + Standard-[Signet][topic signet] beobachtet wurde. Die neue Version des + Coinstats-Index wird in `/indexes/coinstatsindex/` gespeichert, und ein + aktualisierter Knoten muss von Grund auf neu synchronisieren, um den Index + neu zu erstellen. Die alte Version wird zum Schutz vor Downgrades beibehalten, + könnte aber in einem zukünftigen Update entfernt werden. + +- [Eclair #3163][] fügt einen Testvektor hinzu, um sicherzustellen, dass der + öffentliche Schlüssel eines Zahlungsempfängers aus einer [BOLT11][]-Rechnung + mit einer High-S-Signatur wiederhergestellt werden kann, zusätzlich zur + bereits erlaubten Low-S-Signatur. Dies entspricht dem Verhalten von + libsecp256k1 und dem vorgeschlagenen [BOLTs #1284][]. + +- [Eclair #2308][] führt eine neue Option `use-past-relay-data` ein, die bei + Aktivierung (Standard: false) einen probabilistischen Ansatz basierend auf + vergangenen Zahlungsversuchen verwendet, um die Pfadfindung zu verbessern. + Dies ersetzt eine frühere Methode, die von einer gleichmäßigen Verteilung + der Kanalguthaben ausging. + +- [Eclair #3021][] ermöglicht es dem Nicht-Initiator eines [beidseitig + finanzierten Kanals][topic dual funding], die Finanzierungstransaktion + mittels [RBF][topic rbf] zu ersetzen, was bei [Splicing][topic splicing]-Transaktionen + bereits erlaubt ist. Eine Ausnahme gilt jedoch für Kauftransaktionen von + [Liquiditätsanzeigen][topic liquidity advertisements]. Dies wurde in + [BOLTs #1236][] vorgeschlagen. + +- [Eclair #3142][] fügt dem API-Endpunkt `forceclose` einen neuen Parameter + `maxClosingFeerateSatByte` hinzu, der die globale Gebührenkonfiguration + für nicht dringende Force-Close-Transaktionen pro Kanal überschreibt. + Die globale Einstellung `max-closing-feerate` wurde in [Eclair #3097][] + eingeführt. + +- [LDK #4053][] führt gebührenfreie Commitment-Kanäle ein, indem die beiden + Anchor-Outputs durch einen gemeinsamen [Pay-to-Anchor (P2A)][topic ephemeral anchors]-Output + ersetzt werden, der auf einen Wert von 240 Sats begrenzt ist. Zusätzlich + werden die [HTLC][topic htlc]-Signaturen in gebührenfreien Commitment-Kanälen + auf `SIGHASH_SINGLE|ANYONECANPAY` umgestellt und die HTLC-Transaktionen + auf [Version 3][topic v3 transaction relay] angehoben. + +- [LDK #3886][] erweitert `channel_reestablish` für [Splicing][topic splicing] + um zwei `funding_locked_txid`-TLVs (was ein Knoten zuletzt gesendet und + empfangen hat), damit Peers die aktive Finanzierungstransaktion bei + Wiederverbindung abgleichen können. Zusätzlich wird der Wiederverbindungsprozess + optimiert, indem `commitment_signed` vor `tx_signatures` erneut gesendet, + implizites `splice_locked` gehandhabt, `next_funding` übernommen und bei + Bedarf Ankündigungssignaturen angefordert werden. + +{% include snippets/recap-ad.md when="2025-09-16 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="30469,3163,2308,3021,3142,4053,3886,1284,1236,3097" %} +[bitcoin core 29.1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[bitcoin core 30.0rc1]: https://bitcoincore.org/bin/bitcoin-core-30.0/ +[nick workbook]: https://delvingbitcoin.org/t/provable-cryptography-for-bitcoin-an-introduction-workbook/1974 +[workbook pdf]: https://github.com/cryptography-camp/workbook/releases +[workbook source]: https://github.com/cryptography-camp/workbook +[Eclair v0.13.0]: https://github.com/ACINQ/eclair/releases/tag/v0.13.0 From 59ecb2a0c0ae6994efb355b6c97dc567d55b9846 Mon Sep 17 00:00:00 2001 From: Octoshi <125779328+cryptozyu@users.noreply.github.com> Date: Tue, 16 Sep 2025 13:38:31 +0800 Subject: [PATCH 250/278] newsletter-369: translate into Chinese (#182) * newsletter-369: translate into Chinese * fix links * Apply suggestions from code review Co-authored-by: editor-Ajian <34365188+editor-Ajian@users.noreply.github.com> --------- Co-authored-by: Zhiwei(Jeffrey) Hu Co-authored-by: editor-Ajian <34365188+editor-Ajian@users.noreply.github.com> --- .../zh/newsletters/2025-08-29-newsletter.md | 76 +++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 _posts/zh/newsletters/2025-08-29-newsletter.md diff --git a/_posts/zh/newsletters/2025-08-29-newsletter.md b/_posts/zh/newsletters/2025-08-29-newsletter.md new file mode 100644 index 0000000000..666eb03b74 --- /dev/null +++ b/_posts/zh/newsletters/2025-08-29-newsletter.md @@ -0,0 +1,76 @@ +--- +title: 'Bitcoin Optech Newsletter #369' +permalink: /zh/newsletters/2025/08/29/ +name: 2025-08-29-newsletter-zh +slug: 2025-08-29-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的周报分享了关于比特币和闪电网络实现差分模糊测试的更新，并链接到一篇关于用于可问责计算合约的混淆锁的新论文。此外还包括我们的常规部分：总结了 Bitcoin Stack Exchange 的热门问题和答案、新版本和候选版本的公告，以及对热门比特币基础设施软件的重大变更介绍。 + +## 新闻 + +- **比特币和闪电网络实现差异化模糊测试的更新：** Bruno Garcia 在 Delving Bitcoin 上[发布][garcia fuzz]了关于 [bitcoinfuzz][] 最近进展和成就的描述，这是一个用于对基于比特币的软件和库进行[模糊测试][fuzz testing]的库和相关数据。成就包括发现了“btcd、rust-bitcoin、rust-miniscript、Embit、Bitcoin Core、Core Lightning [和] LND 等项目中的超过 35 个错误”。发现的闪电网络实现之间的差异不仅揭示了错误，还推动了对闪电网络规范的澄清。鼓励比特币项目的开发者调查使其软件成为 bitcoinfuzz 支持的目标。 + +- **用于可问责计算合约的混淆锁：** Liam Eagen 在 Bitcoin-Dev 邮件列表上[发布][eagen glock]了关于他撰写的一篇[论文][eagen paper]，该论文描述了一种基于[混淆电路][garbled circuits]创建[可问责计算合约][topic acc]的新机制。这与最近其他将混淆电路用于 BitVM 的独立工作类似（但不同）（参见[周报 #359][news359 delbrag]）。Eagen 的帖子自称“（在他看来）第一个实用的混淆锁，其欺诈证明是单个签名，与 BitVM2 相比，链上数据减少了超过 550 倍”。截至撰写本文时，他的帖子尚未收到任何公开回复。 + +## Bitcoin Stack Exchange 精选问答 + +*[Bitcoin Stack Exchange][bitcoin.se] 是 Optech 贡献者寻找问题答案的首选之地，也是我们有闲暇时会给好奇和困惑的用户帮忙的地方。在这个月度栏目中，我们会列举自上次出刊以来出现的一些高票的问题和答案。* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [是否可能在强假设下从聚合公钥中恢复私钥？]({{bse}}127723) + Pieter Wuille 解释了围绕 [MuSig2][topic musig] 无脚本[多重签名][topic multisignature]的当前和理论安全假设。 + +- [所有 taproot 地址都容易受到量子计算攻击吗？]({{bse}}127660) + Hugo Nguyen 和 Murch 指出，即使是构造为仅使用脚本路径支出的 [taproot][topic taproot] 输出也容易受到[量子][topic quantum resistance]攻击。Murch 继续指出“有趣的是，生成输出脚本的一方能够证明内部密钥是 NUMS 点，从而证明发生了量子解密。” + +- [为什么我们不能设置链状态混淆密钥？]({{bse}}127814) + Ava Chow 强调，混淆 `blocksdir` 磁盘内容的密钥（参见[周报 #339][news339 blocksxor]）与混淆 `chainstate` 内容的密钥不同（参见 [Bitcoin Core #6650][]）。 + +- [是否可能在区块高度后撤销支出分支？]({{bse}}127683) + Antoine Poinsot 指向[之前的答案]({{bse}}122224)，确认过期支出条件或“反向时间锁”是不可能的，甚至可能不是理想的。 + +- [配置 Bitcoin Core 除了使用 IPv4 和 IPv6 节点外还使用洋葱节点？]({{bse}}127727) + Pieter Wuille 澄清设置 `onion` 配置选项仅适用于出站对等连接。他继续概述了如何为入站连接配置 [Tor][topic anonymity networks] 和 `bitcoind`。 + +## 新版本和候选版本 + +*热门比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本。* + +- [Bitcoin Core 29.1rc2][] 是主流全节点软件维护版本的候选版本。 + +- [Core Lightning v25.09rc4][] 是这个热门闪电网络节点实现新主要版本的候选版本。 + +## 重大的代码和文档变更 + +*本周的重大变更有：[Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface（HWI）][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement Proposals（BIPs）][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo]。* + +- [Bitcoin Core #31802][] 默认启用进程间通信（IPC）（`ENABLE_IPC`），在除 Windows 外的所有系统上将 `bitcoin-node` 和 `bitcoin-gui` 多进程二进制文件添加到发布构建中。这允许创建、管理和提交区块模板的外部 [Stratum v2][topic pooled mining] 挖矿服务在不需要自定义构建的情况下试验多进程布局。有关多进程项目和 `bitcoin-node` 二进制文件的更多背景信息，请参见周报 [#99][news99 ipc]、[#147][news147 ipc]、[#320][news320 ipc]、[#323][news323 ipc]。 + +- [LDK #3979][] 添加了拼接输出支持，使 LDK 节点既能发起拼接输出交易，也能接受来自对手方的请求。这完成了 LDK 的[通道拼接][topic splicing]实现，因为 [LDK #3736][] 已经添加了拼接输入支持。此 PR 添加了一个涵盖输入和输出场景的 `SpliceContribution` 枚举，并确保拼接输出交易的输出值在考虑费用和储备要求后不超过用户的通道余额。 + +- [LND #10102][] 添加了 `gossip.ban-threshold` 选项（默认为 100，0 为禁用该特性），允许用户配置禁用发来无效[gossip][topic channel announcements]消息的对等节点的分数阈值。对等节点禁止系统之前已引入并在[周报 #319][news319 ban]中介绍。此 PR 还解决了一个问题，即解决了响应积压 gossip 查询请求时发送了不必要的节点和[通道公告][topic channel announcements]消息的问题。 + +- [Rust Bitcoin #4907][] 通过向 `Script` 和 `ScriptBuf` 添加新的通用标签参数 `T` 来引入脚本标记，并定义了类型别名 `ScriptPubKey`、`ScriptSig`、`RedeemScript`、`WitnessScript` 和 `TapScript`，这些别名由密封的 `Tag` 特征支持，用于编译时角色安全。 + +{% include references.md %} +{% include linkers/issues.md v=2 issues="31802,3979,10102,4907,6650,3736" %} +[bitcoin core 29.1rc2]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[core lightning v25.09rc4]: https://github.com/ElementsProject/lightning/releases/tag/v25.09rc4 +[garcia fuzz]: https://delvingbitcoin.org/t/the-state-of-bitcoinfuzz/1946 +[bitcoinfuzz]: https://github.com/bitcoinfuzz +[fuzz testing]: https://zh.wikipedia.org/wiki/%E6%A8%A1%E7%B3%8A%E6%B5%8B%E8%AF%95 +[eagen glock]: https://mailing-list.bitcoindevs.xyz/bitcoindev/Aq_-LHZtVdSN5nODCryicX2u_X1yAQYurf9UDZXDILq6s4grUOYienc4HH2xFnAohA69I_BzgRCSKdW9OSVlSU9d1HYZLrK7MS_7wdNsLmo=@protonmail.com/ +[eagen paper]: https://eprint.iacr.org/2025/1485 +[garbled circuits]: https://en.wikipedia.org/wiki/Garbled_circuit +[news359 delbrag]: /zh/newsletters/2025/06/20/#improvements-to-bitvmstyle-contracts +[news339 blocksxor]: /zh/newsletters/2025/01/31/#how-does-the-blocksxor-switch-that-obfuscates-the-blocks-dat-files-work-blocksxor-blocks-dat +[news99 ipc]: /zh/newsletters/2020/05/27/#bitcoin-core-18677 +[news147 ipc]: /zh/newsletters/2021/05/05/#bitcoin-core-19160 +[news320 ipc]: /zh/newsletters/2024/09/13/#bitcoin-core-30509 +[news323 ipc]: /zh/newsletters/2024/10/04/#bitcoin-core-30510 +[news319 ban]: /zh/newsletters/2024/09/06/#lnd-9009 From bf2318d94b5d393f01b5df31a1b810e5ef2c4d18 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Tue, 16 Sep 2025 13:28:31 -0500 Subject: [PATCH 251/278] Podcast: add 371 recap --- .../en/newsletters/2025-09-12-newsletter.md | 22 ++++++++--------- .../en/podcast/2025-09-16-newsletter-recap.md | 24 +++++++++++++++++++ 2 files changed, 35 insertions(+), 11 deletions(-) create mode 100644 _posts/en/podcast/2025-09-16-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-09-12-newsletter.md b/_posts/en/newsletters/2025-09-12-newsletter.md index 7d6a4a8c04..563328c57a 100644 --- a/_posts/en/newsletters/2025-09-12-newsletter.md +++ b/_posts/en/newsletters/2025-09-12-newsletter.md @@ -20,7 +20,7 @@ software. day event to "teach developers the basics of provable cryptography, [...] consisting of cryptographic definitions, propositions, proofs and exercises." The workbook is available as a [PDF][workbook pdf] - with freely licensesd [source][workbook source]. + with freely licensesd [source][workbook source]. {% assign timestamp="0:48" %} ## Releases and release candidates @@ -29,7 +29,7 @@ projects. Please consider upgrading to new releases or helping to test release candidates._ - [Bitcoin Core 29.1][] is the release of a maintenance - version of the predominant full node software. + version of the predominant full node software. {% assign timestamp="10:48" %} - [Eclair v0.13.0][] is the release of this LN node implementation. It "s release contains a lot of refactoring, an initial implementation of @@ -39,10 +39,10 @@ release candidates._ they should not be used by regular users. The release notes also warn: "This is the last release of eclair where channels that don't use anchor outputs will be supported. If you have channels that don't - use anchor outputs, you should close them." + use anchor outputs, you should close them." {% assign timestamp="11:17" %} - [Bitcoin Core 30.0rc1][] is a release candidate for the next major - version of this full verification node software. + version of this full verification node software. {% assign timestamp="25:27" %} ## Notable code and documentation changes @@ -62,42 +62,42 @@ repo], and [BINANAs][binana repo]._ the default [signet][topic signet]. The new version of the coinstats index is stored in `/indexes/coinstatsindex/` and an upgraded node will need to sync from scratch to rebuild the index. The old version is kept for downgrade - protection, but may be removed in a future update. + protection, but may be removed in a future update. {% assign timestamp="33:18" %} - [Eclair #3163][] adds a test vector to ensure that a payee’s public key can be recovered from a [BOLT11][] invoice with a high-S signature, in addition to already allowing low-S signatures. This aligns with the behaviour of - libsecp256k1 and the proposed [BOLTs #1284][]. + libsecp256k1 and the proposed [BOLTs #1284][]. {% assign timestamp="33:18" %} - [Eclair #2308][] introduces a new `use-past-relay-data` option that when set to true (default false), uses a probabilistic approach based on past payment attempt history to improve pathfinding. This replaces a prior method - that assumed uniformity in channel balances. + that assumed uniformity in channel balances. {% assign timestamp="40:27" %} - [Eclair #3021][] allows the non-initiator of a [dual-funded channel][topic dual funding] to [RBF][topic rbf] the funding transaction, which is already allowed in [splicing][topic splicing] transactions. However, an exception applies to [liquidity advertisement][topic liquidity advertisements] purchase - transactions. This has been proposed in [BOLTs #1236][]. + transactions. This has been proposed in [BOLTs #1236][]. {% assign timestamp="45:18" %} - [Eclair #3142][] adds a new `maxClosingFeerateSatByte` parameter to the `forceclose` API endpoint that overrides the global feerate configuration for non-urgent force close transactions on a per-channel basis. The global - setting `max-closing-feerate` was introduced in [Eclair #3097][]. + setting `max-closing-feerate` was introduced in [Eclair #3097][]. {% assign timestamp="48:08" %} - [LDK #4053][] introduces zero-fee commitment channels by replacing the two anchor outputs with one shared [Pay-to-Anchor (P2A)][topic ephemeral anchors] output, capped at a value of 240 sats. Additionally, it switches [HTLC][topic htlc] signatures in zero-fee commitment channels to `SIGHASH_SINGLE|ANYONECANPAY` and bumps HTLC transactions to [version 3][topic - v3 transaction relay]. + v3 transaction relay]. {% assign timestamp="50:30" %} - [LDK #3886][] extends `channel_reestablish` for [splicing][topic splicing] with two `funding_locked_txid` TLVs (what a node last sent and received) so that peers can reconcile the active funding transaction upon reconnecting. Additionally, it streamlines the reconnection process by resending `commitment_signed` before `tx_signatures`, handling implicit `splice_locked`, - adopting `next_funding`, and requesting announcement signatures as needed. + adopting `next_funding`, and requesting announcement signatures as needed. {% assign timestamp="58:12" %} {% include snippets/recap-ad.md when="2025-09-16 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-09-16-newsletter-recap.md b/_posts/en/podcast/2025-09-16-newsletter-recap.md new file mode 100644 index 0000000000..5275b2f122 --- /dev/null +++ b/_posts/en/podcast/2025-09-16-newsletter-recap.md @@ -0,0 +1,24 @@ +--- +title: 'Bitcoin Optech Newsletter #371 Recap Podcast' +permalink: /en/podcast/2025/09/16/ +reference: /en/newsletters/2025/09/12/ +name: 2025-09-16-recap +slug: 2025-09-16-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt are joined by Jonas Nick and Bastien +Teinturier to discuss [Newsletter #370]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-8-16/407600787-44100-2-853167a259869.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From 696c516794900c6f5d85a676ea11531d01108d24 Mon Sep 17 00:00:00 2001 From: "Zhiwei(Jeffrey) Hu" Date: Tue, 16 Sep 2025 13:41:26 +0800 Subject: [PATCH 252/278] Newsletter-370: translate into Chinese (#183) * Newsletter-370: translate into Chinese * Apply suggestions from code review Co-authored-by: editor-Ajian <34365188+editor-Ajian@users.noreply.github.com> --------- Co-authored-by: editor-Ajian <34365188+editor-Ajian@users.noreply.github.com> --- .../zh/newsletters/2025-09-05-newsletter.md | 72 +++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 _posts/zh/newsletters/2025-09-05-newsletter.md diff --git a/_posts/zh/newsletters/2025-09-05-newsletter.md b/_posts/zh/newsletters/2025-09-05-newsletter.md new file mode 100644 index 0000000000..835cc9e8f2 --- /dev/null +++ b/_posts/zh/newsletters/2025-09-05-newsletter.md @@ -0,0 +1,72 @@ +--- +title: 'Bitcoin Optech Newsletter #370' +permalink: /zh/newsletters/2025/09/05/ +name: 2025-09-05-newsletter-zh +slug: 2025-09-05-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- + +本周的周报包括我们的常规栏目：总结关于更改比特币共识规则的讨论、宣布新版本和候选版本，以及描述流行的比特币基础设施软件的显著变更。 + +## 新闻 + +_本周在我们的[消息来源][optech sources]中没有发现重大新闻。_ + +## 共识变更 + +_一个月度栏目，总结关于更改比特币共识规则的提议和讨论。_ + +- **** **关于 Simplicity 设计的详细信息**：Russell O'Connor 在 Delving Bitcoin 上发布了三篇帖子（[1][sim1]、[2][sim2]、[3][sim3]），介绍了“[Simplicity 语言][topic simplicity]的哲学和设计”。这些帖子探讨了“将基本操作转换为复杂操作的三种主要组合形式”、“Simplicity 的类型系统、组合子和基本表达式”，以及“如何从位开始构建逻辑操作[...直到...]加密操作，例如 SHA-256 和 Schnorr 签名验证，仅使用我们的计算 Simplicity 组合子”。 + + 最新的帖子表明该系列预计还会有更多条目。 + +- **** **向 tapscript 添加椭圆曲线操作的 BIP 草稿**：Olaoluwa Osuntokun 在 Bitcoin-Dev 邮件列表中[发帖][osuntokun ec]，链接到了一个[BIP 草稿][osuntokun bip]，用于向 [tapscript][topic tapscript] 添加几个操作码，这些操作码将允许在脚本求值堆栈上执行椭圆曲线操作。这些操作码旨在与内省操作码结合使用，以创建或增强[限制条款][topic covenants]协议以及其他进展。 + + Jeremy Rubin [回复][rubin ec1]建议添加额外的操作码以启用更多功能，以及[其他操作码][rubin ec2]，这些操作码将使基础提议提供的某些功能使用起来更加方便。 + +- **** **OP_TWEAKADD 的 BIP 草稿**：Jeremy Rubin 在 Bitcoin-Dev 邮件列表中[发帖][rubin ta1]，链接到了一个 [BIP 草稿][rubin bip]，用于将 `OP_TWEAKADD` 添加到 [tapscript][topic tapscript]。他单独[发帖][rubin ta2]介绍了通过添加该操作码启用的脚本的示例，包括揭示 [taproot][topic taproot] 调整的脚本、交易签名顺序证明（例如，Alice 必须在 Bob 之前签名）和[签名委托][topic signer delegation]。 + +## 发行和候选发行 + +_流行的比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本。_ + +- [Core Lightning v25.09][] 是这个流行的闪电网络节点实现的新主要版本发行。它为 `xpay` 命令添加了对支付 [BIP353][] 地址和简单 [offer][topic offers] 的支持，提供了改进的簿记支持，提供了更好的插件依赖管理，并包含其他新功能和错误修复。 + +- [Bitcoin Core 29.1rc2][] 是主流全节点软件维护版本的候选发行。 + +## 显著的代码和文档变更 + +_本周出现重大变更的有：[Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement Proposals (BIPs)][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo]。_ + +- [LDK #3726][] 为[盲化路径][topic rv routing]添加了虚拟跳跃支持，使接收者能够添加不起路由作用但充当诱饵的任意跳跃。每次都会添加随机数量的虚拟跳跃，但上限为 10（由 `MAX_DUMMY_HOPS_COUNT` 定义）。添加额外的跳跃使确定到接收者节点的距离和接收者节点的身份变得更加困难。 + +- [LDK #4019][] 按照规范所要求的，通过在初始化拼接交易之前要求静默通道状态，将[拼接][topic splicing]与[静默协议][topic channel commitment upgrades]集成。 + +- [LND #9455][] 添加了对在闪电网络节点的公告消息中将有效的 DNS 域名与节点的 IP 地址和公钥关联的支持，这是规范允许的，并且得到了 Eclair 和 Core Lightning 等其他实现的支持（参见周报 [#212][news212 dns]、[#214][news214 dns] 和 [#178][news178 dns]）。 + +- [LND #10103][] 引入了一个新的 `gossip.peer-msg-rate-bytes` 选项（默认值 51200），它限制了每个对等节点用于出站 [gossip 消息][topic channel announcements]的出站带宽。这个值限制了平均带宽速度（以每秒字节数为单位），如果对等节点超过了这个限制，LND 将开始对发送给该对等节点的消息进行排队和延迟。这个新选项防止单个对等节点消耗由 [LND #10096][] 中引入的 `gossip.msg-rate-bytes` 定义的所有全局带宽。有关 LND 在 gossip 请求资源管理方面的工作，请参见周报 [#366][news366 gossip] 和 [#369][news369 gossip]。 + +- [HWI #795][] 通过将 `bitbox02` 库更新到版本 7.0.0 来添加对 BitBox02 Nova 的支持。它还进行了几项 CI 更新。 + +{% include snippets/recap-ad.md when="2025-09-09 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="3726,4019,9455,10103,795,10096" %} +[bitcoin core 29.1rc2]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[core lightning v25.09]: https://github.com/ElementsProject/lightning/releases/tag/v25.09 +[sim1]: https://delvingbitcoin.org/t/delving-simplicity-part-three-fundamental-ways-of-combining-computations/1902 +[sim2]: https://delvingbitcoin.org/t/delving-simplicity-part-combinator-completeness-of-simplicity/1935 +[sim3]: https://delvingbitcoin.org/t/delving-simplicity-part-building-data-types/1956 +[osuntokun ec]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAO3Pvs-Cwj=5vJgBfDqZGtvmoYPMrpKYFAYHRb_EqJ5i0PG0cA@mail.gmail.com/ +[osuntokun bip]: https://github.com/bitcoin/bips/pull/1945 +[rubin ec1]: https://mailing-list.bitcoindevs.xyz/bitcoindev/f118d974-8fd5-42b8-9105-57e215d8a14an@googlegroups.com/ +[rubin ec2]: https://mailing-list.bitcoindevs.xyz/bitcoindev/1c2539ba-d937-4a0f-b50a-5b16809322a8n@googlegroups.com/ +[rubin ta1]: https://mailing-list.bitcoindevs.xyz/bitcoindev/bc9ff794-b11e-47bc-8840-55b2bae22cf0n@googlegroups.com/ +[rubin ta2]: https://mailing-list.bitcoindevs.xyz/bitcoindev/c51c489c-9417-4a60-b642-f819ccb07b15n@googlegroups.com/ +[rubin bip]: https://github.com/bitcoin/bips/pull/1944 +[news212 dns]: /zh/newsletters/2022/08/10/#bolts-911 +[news214 dns]: /zh/newsletters/2022/08/24/#eclair-2234 +[news178 dns]: /zh/newsletters/2021/12/08/#c-lightning-4829 +[news366 gossip]: /zh/newsletters/2025/08/08/#lnd-10097 +[news369 gossip]: /zh/newsletters/2025/08/29/#lnd-10102 From 11d703c0bcc054813f8cabeb1e93d36fd20d74d4 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Wed, 17 Sep 2025 09:01:01 -0500 Subject: [PATCH 253/278] News371: fixup and podcast timestamp --- _posts/en/newsletters/2025-09-12-newsletter.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_posts/en/newsletters/2025-09-12-newsletter.md b/_posts/en/newsletters/2025-09-12-newsletter.md index 563328c57a..d02b5c3ff3 100644 --- a/_posts/en/newsletters/2025-09-12-newsletter.md +++ b/_posts/en/newsletters/2025-09-12-newsletter.md @@ -20,7 +20,7 @@ software. day event to "teach developers the basics of provable cryptography, [...] consisting of cryptographic definitions, propositions, proofs and exercises." The workbook is available as a [PDF][workbook pdf] - with freely licensesd [source][workbook source]. {% assign timestamp="0:48" %} + with freely licensed [source][workbook source]. {% assign timestamp="0:48" %} ## Releases and release candidates @@ -62,7 +62,7 @@ repo], and [BINANAs][binana repo]._ the default [signet][topic signet]. The new version of the coinstats index is stored in `/indexes/coinstatsindex/` and an upgraded node will need to sync from scratch to rebuild the index. The old version is kept for downgrade - protection, but may be removed in a future update. {% assign timestamp="33:18" %} + protection, but may be removed in a future update. {% assign timestamp="31:45" %} - [Eclair #3163][] adds a test vector to ensure that a payee’s public key can be recovered from a [BOLT11][] invoice with a high-S signature, in addition to From 5ef6aeef1ad669663512664283cb546870f101d4 Mon Sep 17 00:00:00 2001 From: editor-Ajian <34365188+editor-Ajian@users.noreply.github.com> Date: Thu, 18 Sep 2025 09:08:46 +0800 Subject: [PATCH 254/278] newsletter371 translate into ZH-CN (#184) * newsletter371 translate into ZH-CN * update format --------- Co-authored-by: Zhiwei(Jeffrey) Hu --- .../zh/newsletters/2025-09-12-newsletter.md | 52 +++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 _posts/zh/newsletters/2025-09-12-newsletter.md diff --git a/_posts/zh/newsletters/2025-09-12-newsletter.md b/_posts/zh/newsletters/2025-09-12-newsletter.md new file mode 100644 index 0000000000..942a9eb6f6 --- /dev/null +++ b/_posts/zh/newsletters/2025-09-12-newsletter.md @@ -0,0 +1,52 @@ +--- +title: 'Bitcoin Optech Newsletter #371' +permalink: /zh/newsletters/2025/09/12/ +name: 2025-09-12-newsletter-zh +slug: 2025-09-12-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- + +本周的新闻部分宣布了一本专论可证明的密码学的手册的问世。此外是我们的常规栏目：软件的新版本和候选版本的发行，以及热门的比特币基础设施软件的显著变更描述。 + +## 新闻 + +- **可证明的密码学手册**：Jonas Nick 在 Delving Bitcoin 论坛中[公开][nick workbook]了他为一场为期四天的活动而撰写的手册，旨在 “教导开发者们可证明的密码学的基础知识，……，包含了密码学的定义、命题、证据和练习。”该手册的[PDF][workbook pdf]版本已经公开，且有免费许可的[源代码][workbook source]。 + +## 发行和候选发行 + +*热门的比特币基础设施项目的新版本和候选版本。请考虑升级到新版本，或帮助测试候选版本。* + +- [Bitcoin Core 29.1][] 是这个主流全节点实现的一个维护版本的候选发行。 + +- [Eclair v0.13.0][] 是这个闪电节点实现的发行版。该发行版 “包含了大量的重构（refactoring）、taproot 通道的一个初步实现，……，基于近期的规范更新优化了通道拼接，以及对 BOLT12 的更好支持。”Taproot 通道和通道拼接特性的完整详述尚未完成，所以普通用户不应该使用。发行公告也警告：“这是最后一个依然支持非锚点输出通道的 eclair 版本。如果你有不使用锚点输出的通道，你应该关闭它。” + +- [Bitcoin Core 30.0rc1][] 是这个全验证节点实现软件的下一个主要版本的候选发行。 + +## 重大的代码和文档变更 + +*本周出现重大变更的有：[Bitcoin Core 30.0rc1][]、[Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement Proposals (BIPs)][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo]。* + +- [Bitcoin Core #30469][] 将 `m_total_prevout_spent_amount`、`m_total_new_outputs_ex_coinbase_amount` 和 `m_total_coinbase_amount` 的值从 `CAmount` 类型（64 位）变为 `arith_uint256` 类型（256 位），以防止在默认的 [signet][topic signet] 上已经观察到的数值溢出故障。新版本的 coinstats 索引会存储在 `/indexes/coinstatsindex/`，而一个升级后的节点将需要从头同步来重建这个索引。旧版本保留，用于降级保护，但可能会在未来的更新中移除。 + +- [Eclair #3163][] 添加了一个测试向量，以保证一个收款方的公钥可以从带有高 S 签名的 [BOLT11][] 发票中复原（原本已允许从低 S 签名中复原）。这跟 libsecp256k1 的动作和 [BOLTs #1284][] 提议保持一致。 + +- [Eclair #2308][] 加入了新的 `use-past-relay-data` 选项（默认为假），当该选项设为真时，使用一个基于过往支付尝试的概率方法来提升选路效果。这取代了以往假设通道余额均匀分布的方法。 + +- [Eclair #3021][] 允许一条[双向注资通道][topic dual funding]的非发起方 [RBF][topic rbf] 注资交易（相同的效果在[通道拼接][topic splicing]交易中已经实现）。不过，[流动性广告][topic liquidity advertisements]的购买交易将是例外。该特性已在 [BOLTs #1236][] 中提出。 + +- [Eclair #3142][] 为 `forceclose` API 端点加入了新的 `maxClosingFeerateSatByte` 参数，它将为不紧急的强制关闭交易覆盖全局的费率配置，转变为按通道配置。全局设定 `max-closing-feerate` 在 [Eclair #3097][] 中引入。 + +- [LDK #4053][] 通过将两个锚点输出替代为一个共享的 [Pay-to-Anchor (P2A)][topic ephemeral anchors] 输出、引入了承诺交易零费率的通道（P2A 输出的数值上限为 240 聪）。此外，它将承诺交易零费率通道中的 [HTLC][topic htlc] 交易的签名切换为 `SIGHASH_SINGLE|ANYONECANPAY` 模式，并将 HTLC 交易的版本号改为[版本 3][topic v3 transaction relay]。 + +- [LDK #3886][] 使用两个 `funding_locked_txid` TLV 字段（节点最后发送和收到的东西）延申了用于[通道拼接][topic splicing]的 `channel_reestablish`，从而对等节点可以在重新连接后重新协调激活的注资交易。此外，它还通过重新发送 `commitment_signed` （早于 `tx_signatures`）、处理隐式的 `splice_locked`、接受 `next_funding` 并按需重新请求宣告消息签名，将重新连接的流程平滑化了。 + +{% include references.md %} +{% include linkers/issues.md v=2 issues="30469,3163,2308,3021,3142,4053,3886,1284,1236,3097" %} +[bitcoin core 29.1]: https://bitcoincore.org/bin/bitcoin-core-29.1/ +[bitcoin core 30.0rc1]: https://bitcoincore.org/bin/bitcoin-core-30.0/ +[nick workbook]: https://delvingbitcoin.org/t/provable-cryptography-for-bitcoin-an-introduction-workbook/1974 +[workbook pdf]: https://github.com/cryptography-camp/workbook/releases +[workbook source]: https://github.com/cryptography-camp/workbook +[Eclair v0.13.0]: https://github.com/ACINQ/eclair/releases/tag/v0.13.0 From 4d39cb7ce6ca0ffb784ce402294f426e1052cdea Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Mon, 15 Sep 2025 10:42:18 -0500 Subject: [PATCH 255/278] Newsletters: add 372 (2025-09-19) --- .../en/newsletters/2025-09-19-newsletter.md | 50 +++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 _posts/en/newsletters/2025-09-19-newsletter.md diff --git a/_posts/en/newsletters/2025-09-19-newsletter.md b/_posts/en/newsletters/2025-09-19-newsletter.md new file mode 100644 index 0000000000..686e306155 --- /dev/null +++ b/_posts/en/newsletters/2025-09-19-newsletter.md @@ -0,0 +1,50 @@ +--- +title: 'Bitcoin Optech Newsletter #372' +permalink: /en/newsletters/2025/09/19/ +name: 2025-09-19-newsletter +slug: 2025-09-19-newsletter +type: newsletter +layout: newsletter +lang: en +--- +FIXME:harding + +## News + +FIXME:harding + +## Changes to services and client software + +*In this monthly feature, we highlight interesting updates to Bitcoin +wallets and services.* + +FIXME:bitschmidty + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +- [Bitcoin Core 30.0rc1][] is a release candidate for the next major + version of this full verification node software. + +FIXME:Gustavojfe + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +FIXME:Gustavojfe + +{% include snippets/recap-ad.md when="2025-09-23 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="" %} +[bitcoin core 30.0rc1]: https://bitcoincore.org/bin/bitcoin-core-30.0/ From 34818651989dc861643eeffea796d0afa5524a73 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Mon, 15 Sep 2025 14:39:25 -0500 Subject: [PATCH 256/278] News372: add client services --- _posts/en/newsletters/2025-09-19-newsletter.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2025-09-19-newsletter.md b/_posts/en/newsletters/2025-09-19-newsletter.md index 686e306155..8c97b91714 100644 --- a/_posts/en/newsletters/2025-09-19-newsletter.md +++ b/_posts/en/newsletters/2025-09-19-newsletter.md @@ -18,7 +18,14 @@ FIXME:harding *In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.* -FIXME:bitschmidty +- **Zero-knowledge proof of reserve tool:** + [Zkpoor][zkpoor github] generates [proof of reserves][topic proof of reserves] + using STARK proofs without revealing the owner's addresses or UTXOs. + +- **Alternative submarine swap protocol proof of concept:** + The [Papa Swap][papa swap github] protocol proof of concept achieves + [submarine swap][topic submarine swaps] functionality by requiring one + transaction instead of two. ## Releases and release candidates @@ -48,3 +55,5 @@ FIXME:Gustavojfe {% include references.md %} {% include linkers/issues.md v=2 issues="" %} [bitcoin core 30.0rc1]: https://bitcoincore.org/bin/bitcoin-core-30.0/ +[zkpoor github]: https://github.com/AbdelStark/zkpoor +[papa swap github]: https://github.com/supertestnet/papa-swap From a2dd49fa8c3d37c8d8ae8a5523d288f23aa39737 Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Wed, 17 Sep 2025 01:52:54 +0000 Subject: [PATCH 257/278] News372: add merge summaries and releases --- .../en/newsletters/2025-09-19-newsletter.md | 70 ++++++++++++++++++- 1 file changed, 67 insertions(+), 3 deletions(-) diff --git a/_posts/en/newsletters/2025-09-19-newsletter.md b/_posts/en/newsletters/2025-09-19-newsletter.md index 8c97b91714..5e735706bf 100644 --- a/_posts/en/newsletters/2025-09-19-newsletter.md +++ b/_posts/en/newsletters/2025-09-19-newsletter.md @@ -36,7 +36,10 @@ release candidates._ - [Bitcoin Core 30.0rc1][] is a release candidate for the next major version of this full verification node software. -FIXME:Gustavojfe +- [BDK Chain 0.23.2][] is a release of this library for building wallet + applications that introduces improvements to transaction conflict handling, + redesigns the `FilterIter` API to enhance [BIP158][] filtering capabilities, + and improves anchor and block reorg management. ## Notable code and documentation changes @@ -49,11 +52,72 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -FIXME:Gustavojfe +- [Bitcoin Core #33268][] changes how transactions are recognized as part of a + user’s wallet by removing the requirement that the total amount of a + transaction's inputs exceeds zero sats. As long as a transaction spends at least + one output from a wallet, it will be recognized as part of that wallet. This + allows transactions with zero-value inputs, such as spending a [P2A ephemeral + anchor][topic ephemeral anchors], to appear in a user’s transaction list. + +- [Eclair #3157][] updates the way it signs and broadcasts remote commitment + transactions upon reconnection. Instead of resending the previously signed + commitment, it resigns with the latest nonces from `channel_reestablish`. + Peers that do not use deterministic nonces in [simple taproot channels][topic + simple taproot channels] will have a new nonce upon reconnection, rendering + the previous commitment signature invalid. + +- [LND #9975][] adds [P2TR][topic taproot] fallback on-chain address support to + [BOLT11][] invoices, following the test vector added in [BOLTs #1276][]. + BOLT11 invoices have an optional `f` field that allows users to include a + fallback on-chain address in case a payment cannot be completed over the LN. + +- [LND #9677][] adds the `ConfirmationsUntilActive` and `ConfirmationHeight` + fields to the `PendingChannel` response message returned by the + `PendingChannels` RPC command. These fields inform users of the number of + confirmations required for channel activation and the block height + at which the funding transaction was confirmed. + +- [LDK #4045][] implements the reception of an [async payment][topic async + payments] by an LSP node by accepting an incoming [HTLC][topic htlc] on behalf + of an often-offline recipient, holding it, and releasing it to the recipient + later when signaled. This PR introduces an experimental `HtlcHold` feature + bit, adds a new `hold_htlc` flag on `UpdateAddHtlc`, and defines the release + path. + +- [LDK #4049][] implements the forwarding of [BOLT12][topic offers] invoice + requests from an LSP node to an online recipient, who then replies with a + fresh invoice. If the recipient is offline, the LSP node can reply with a + fallback invoice, as enabled by the server-side logic implementation for + [async payments][topic async payments] (see Newsletter [#363][news363 async]). + +- [BDK #1582][] refactors the `CheckPoint`, `LocalChain`, `ChangeSet`, and + `spk_client` types to be generic and take a `T` payload instead of being fixed + to block hashes. This prepares `bdk_electrum` to store full block headers in + checkpoints, which avoids header redownloads and enables cached merkle proofs + and Median Time Past (MTP). + +- [BDK #2000][] adds block reorg handling to a refactored `FilterIter` struct + (see Newsletter [#339][news339 filters]). Rather than splitting its flow + across multiple methods, this PR ties everything to the `next()` function, + thus avoiding timing risks. A checkpoint is emitted at every block height to + ensure that the block isn't stale and that BDK is on the valid chain. + `FilterIter` scans all blocks and fetches those containing transactions + relevant to a list of script pubkeys, using [compact block filters][topic + compact block filters] as specified in [BIP158][]. + +- [BDK #2028][] adds a `last_evicted` timestamp field to the `TxNode` struct to + indicate when a transaction was excluded from the mempool after being replaced + through [RBF][topic rbf]. This PR also removes the `TxGraph::get_last_evicted` + method (See Newsletter [#346][news346 evicted]) because the new field replaces + it. {% include snippets/recap-ad.md when="2025-09-23 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="" %} +{% include linkers/issues.md v=2 issues="33268,3157,9975,1276,9677,4045,4049,1582,2000,2028" %} [bitcoin core 30.0rc1]: https://bitcoincore.org/bin/bitcoin-core-30.0/ [zkpoor github]: https://github.com/AbdelStark/zkpoor [papa swap github]: https://github.com/supertestnet/papa-swap +[news363 async]: /en/newsletters/2025/07/18/#ldk-3628 +[news339 filters]: /en/newsletters/2025/01/31/#bdk-1614 +[news346 evicted]: /en/newsletters/2025/03/21/#bdk-1839 +[BDK Chain 0.23.2]: https://github.com/bitcoindevkit/bdk/releases/tag/chain-0.23.2 From 3bf36d9eb6118f0b8adae8c15a91b1d386fd824b Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Tue, 16 Sep 2025 22:27:21 -0500 Subject: [PATCH 258/278] News372: add news stories --- .../en/newsletters/2025-09-19-newsletter.md | 49 ++++++++++++++++++- 1 file changed, 47 insertions(+), 2 deletions(-) diff --git a/_posts/en/newsletters/2025-09-19-newsletter.md b/_posts/en/newsletters/2025-09-19-newsletter.md index 5e735706bf..10fc429085 100644 --- a/_posts/en/newsletters/2025-09-19-newsletter.md +++ b/_posts/en/newsletters/2025-09-19-newsletter.md @@ -7,11 +7,54 @@ type: newsletter layout: newsletter lang: en --- -FIXME:harding +This week's newsletter summarizes a proposal to enhance LN redundant +overpayments and links to a discussion about potential partitioning +attacks against full nodes. Also included are our regular sections +describing recent changes to services and client software, announcing +new releases and release candidates, and summarizing notable changes to +popular Bitcoin infrastructure software. ## News -FIXME:harding +- **LSP-funded redundant overpayments:** developer ZmnSCPxj + [posted][zmnscpxj lspstuck] to Delving Bitcoin a proposal to allow + LSPs to provide the additional funding (liquidity) required for + [redundant overpayments][topic redundant overpayments]. In the + original proposals for redundant overpayments, Alice pays Zed by + sending multiple payments through multiple routes in a way that only + allows Zed to claim one of the payments; the rest of the payments are + refunded to Alice. The upside of this approach is that the first + payment attempts to reach Zed can succeed while other attempts are + still traveling through the network, increasing the speed of payments + on LN. + + Downsides of this approach are that Alice must have extra capital + (liquidity) to make the redundant payments, Alice must remain online + until the redundant overpayment completes, and any payment that becomes + stuck prevents Alice from being able to spend that money until the + payment attempt times out (up to two weeks with commonly used + settings). + + ZmnSCPxj's proposal allows Alice to pay only the actual payment amount + (plus fees) and her Lightning service providers (LSPs) supply the + liquidity for sending the redundant payments, providing the speed + advantage of redundant overpayments without requiring her to have + extra liquidity either briefly or until timeout. The LSPs are also + able to finalize the payment while Alice is offline, so the payment + can be completed even if Alice has poor connectivity. + + Downsides of the new proposal are that Alice loses some privacy to her + LSPs and that the proposal requires several changes to the LN protocol + in addition to support for redundant overpayments. + +- **Partitioning and eclipse attacks using BGP interception:** developer + cedarctic [posted][cedarctic bgp] to Delving Bitcoin about using flaws + in the Border Gateway Protocol (BGP) to prevent full nodes from being + able to connect to peers, which can be used to partition the network + or execute [eclipse attacks][topic eclipse attacks]. Several + mitigations were described by cedarctic, with other developers in the + discussion describing other mitigations and ways to monitor for use of + the attack. ## Changes to services and client software @@ -121,3 +164,5 @@ repo], and [BINANAs][binana repo]._ [news339 filters]: /en/newsletters/2025/01/31/#bdk-1614 [news346 evicted]: /en/newsletters/2025/03/21/#bdk-1839 [BDK Chain 0.23.2]: https://github.com/bitcoindevkit/bdk/releases/tag/chain-0.23.2 +[zmnscpxj lspstuck]: https://delvingbitcoin.org/t/multichannel-and-multiptlc-towards-a-global-high-availability-cp-database-for-bitcoin-payments/1983/ +[cedarctic bgp]: https://delvingbitcoin.org/t/eclipsing-bitcoin-nodes-with-bgp-interception-attacks/1965/ From 8daa3394d9f2e21751ad20ce000c38046d943a70 Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 19 Sep 2025 18:56:44 +0900 Subject: [PATCH 259/278] Newsletter-372:Translate into Japanese --- .../ja/newsletters/2025-09-19-newsletter.md | 144 ++++++++++++++++++ 1 file changed, 144 insertions(+) create mode 100644 _posts/ja/newsletters/2025-09-19-newsletter.md diff --git a/_posts/ja/newsletters/2025-09-19-newsletter.md b/_posts/ja/newsletters/2025-09-19-newsletter.md new file mode 100644 index 0000000000..2679ba13b2 --- /dev/null +++ b/_posts/ja/newsletters/2025-09-19-newsletter.md @@ -0,0 +1,144 @@ +--- +title: 'Bitcoin Optech Newsletter #372' +permalink: /ja/newsletters/2025/09/19/ +name: 2025-09-19-newsletter-ja +slug: 2025-09-19-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、LNの冗長的な過払いを強化するための提案と、 +フルノードに対する潜在的な分断攻撃に関する議論のリンクを掲載しています。また、 +サービスとクライアントソフトウェアの最近のアップデートや、 +人気のBitcoinインフラストラクチャソフトウェアの注目すべき更新など、 +恒例のセクションも含まれています。 + +## ニュース + +- **LSPが資金提供する冗長的な過払い:** 開発者のZmnSCPxjは、 + LSPが[冗長的な過払い][topic redundant overpayments]に必要な追加資金（流動性）を提供できるようにする提案を + Delving Bitcoinに[投稿しました][zmnscpxj lspstuck]。冗長的な過払いの元々の提案では、 + アリスがゼッドに支払う際に、複数の経路を使って複数の支払いを送信し、 + ゼッドはその内1つの支払いのみを請求できるようにします。残りの支払いはアリスに返金されます。 + このアプローチの利点は、他の支払いの試行がネットワークを通過中であっても、 + ゼッドへの支払いの試行が1つでも到着すれば成功できることで、LN上での支払い速度が向上することです。 + + このアプローチの欠点は、アリスが冗長的な支払いをするための追加資本（流動性）を持っている必要があること、 + 冗長的な過払いが完了するまでアリスはオンラインであり続ける必要があること、 + そしてスタックした支払いがある場合、その支払いの試行がタイムアウトするまで（一般的な設定では最大2週間） + アリスがそのお金を使用できなくなることです。 + + ZmnSCPxjの提案では、アリスは実際の支払額（手数料を含む）のみを支払い、 + LSP（Lightning service provider）が冗長な支払いの送信に必要な流動性を提供します。 + これにより、アリスは一時的にも、タイムアウトまでも追加の流動性を確保することなく、 + 冗長的な過払いによるスピードメリットを得られます。また、 + LSPはアリスがオフラインの場合でも支払いを確定できるため、 + アリスの接続状態が悪くても支払いを完了できます。 + + この新しい提案の欠点は、アリスがLSPに対してある程度のプライバシーを失うこと、 + そして冗長的な過払いのサポートに加えて、LNプロトコルに複数の変更が必要になることです。 + +- **BGPインターセプションを使用した分断とエクリプス攻撃:** 開発者のcedarcticは、 + BGP（Border Gateway Protocol）の欠陥を利用してフルノードがピアに接続できないようにする方法について + Delving Bitcoinに[投稿しました][cedarctic bgp]。これはネットワークの分断や + [エクリプス攻撃][topic eclipse attacks]の実行に使用される可能性があります。 + cedarcticによっていくつかの緩和策が説明され、議論に参加した他の開発者たちも + 他の緩和策や攻撃の使用を監視する方法について議論しました。 + +## サービスとクライアントソフトウェアの変更 + +*この毎月の特集では、Bitcoinのウォレットやサービスの興味深いアップデートを取り上げています。* + +- **準備金のゼロ知識証明ツール:** + [Zkpoor][zkpoor github]は、所有者のアドレスやUTXOを明かすことなく、 + STARK証明を使用して[準備金の証明（Proof of Reserves）][topic proof of reserves]を生成します。 + +- **代替サブマリンスワッププロトコルの概念実証:** + [Papa Swap][papa swap github]プロトコルの概念実証は、 + 2つのトランザクションではなく1つのトランザクションで[サブマリンスワップ][topic submarine swaps]機能を実現します。 + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [Bitcoin Core 30.0rc1][]は、この完全な検証ノードソフトウェアの次期メジャーバージョンのリリース候補です。 + +- [BDK Chain 0.23.2][]は、ウォレットアプリケーションを構築するためのこのライブラリのリリースで、 + 競合トランザクション処理の改善や、[BIP158][]のフィルタリング機能を強化するための`FilterIter` APIの再設計、 + アンカーとブロックの再編成管理の改善が導入されています。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Bitcoin Core #33268][]は、トランザクションインプットの合計が0 satを超える必要があるという要件を削除することで、 + トランザクションがユーザーのウォレットの一部として認識される方法を変更します。 + トランザクションがウォレットから少なくとも1つのアウトプットを使用する限り、 + そのトランザクションはウォレットの一部として認識されます。これにより、 + [P2Aエフェメラルアンカー][topic ephemeral anchors]の使用など、 + ゼロ値のインプットを持つトランザクションがユーザーのトランザクションリストに表示されるようになります。 + +- [Eclair #3157][]は、再接続時にリモートコミットメントトランザクションに署名してブロードキャストする方法を更新します。 + 以前署名されたコミットメントを再送信する代わりに、`channel_reestablish`で取得した最新のナンスで再署名します。 + [Simple Taproot Channel][topic simple taproot channels]で、決定論的ナンスを使用しないピアは、 + 再接続時に新しいナンスを持つことになり、以前のコミットメントの署名を無効にします。 + +- [LND #9975][]は、[BOLTs #1276][]で追加されたテストベクターに従って、 + [BOLT11][]インボイスに[P2TR][topic taproot]フォールバックオンチェーンアドレスのサポートを追加します。 + BOLT11インボイスには、オプションの`f`フィールドがあり、 + LN経由で支払いが完了できない場合にフォールバック用のオンチェーンアドレスを含めることができます。 + +- [LND #9677][]は、`PendingChannels` RPCコマンドで返される`PendingChannel`応答メッセージに、 + `ConfirmationsUntilActive`と`ConfirmationHeight`フィールドを追加します。 + これらのフィールドは、チャネルのアクティベーションに必要な承認回数と、 + ファンディングトランザクションが承認されたブロック高をユーザーに通知します。 + +- [LDK #4045][]は、LSPノードによる[非同期支払い][topic async payments]の受信を実装します。 + これは、頻繁にオフラインになる受信者に代わって着信[HTLC][topic htlc]を受け入れ、保持し、 + 後でシグナルが通知された際に受信者にリリースすることで実現されます。 + このPRでは、実験的な`HtlcHold`機能ビットを導入し、`UpdateAddHtlc`に新しい`hold_htlc`を追加し、 + リリースパスを定義します。 + +- [LDK #4049][]は、LSPノードからオンラインの受信者への[BOLT12][topic offers]インボイス要求の転送を実装します。 + 受信者は新しいインボイスで返信します。受信者がオフラインの場合、 + LSPノードは[非同期支払い][topic async payments]用のサーバーサイドロジック実装で有効になった（ + ニュースレター [#363][news363 async]参照）フォールバックインボイスで返信できます。 + +- [BDK #1582][]は、`CheckPoint`、`LocalChain`、`ChangeSet`および`spk_client`型をジェネリックにリファクタリングし、 + ブロックハッシュに固定されていたペイロードを`T`ペイロードとして扱うようにしました。 + これにより、`bdk_electrum`はチェックポイントにブロックヘッダー全体を保存できるようになり、 + ブロックヘッダーの再ダウンロードが回避され、マークルプルーフとMTP（Median Time Past）がキャッシュできるようになります。 + +- [BDK #2000][]は、リファクタリングされた`FilterIter`構造体（ニュースレター + [#339][news339 filters]参照）にブロックの再編成処理を追加します。 + このPRでは、フローを複数のメソッドに分割するのではなく、 + すべてを`next()`関数に結びつけることでタイミングリスクを回避します。 + ブロックが古くないこと、BDKが有効なチェーン上にあることを確認するために、 + 各ブロック高でチェックポイントが発行されます。`FilterIter`は、 + [BIP158][]で定義された[コンパクトブロックフィルター][topic compact block filters]を使用して、 + すべてのブロックをスキャンし、scriptPubkeyのリストに関連するトランザクションを含むブロックを取得します。 + +- [BDK #2028][]は、トランザクションが[RBF][topic rbf]によって置き換えられた後、 + mempoolから除外された日時を示す`last_evicted`タイムスタンプフィールドを`TxNode`構造体に追加します。 + このPRではまた、新しいフィールドに置き換わるため、 + `TxGraph::get_last_evicted`メソッド（ニュースレター[#346][news346 evicted]参照）が削除されます。 + +{% include snippets/recap-ad.md when="2025-09-23 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="33268,3157,9975,1276,9677,4045,4049,1582,2000,2028" %} +[bitcoin core 30.0rc1]: https://bitcoincore.org/bin/bitcoin-core-30.0/ +[zkpoor github]: https://github.com/AbdelStark/zkpoor +[papa swap github]: https://github.com/supertestnet/papa-swap +[news363 async]: /ja/newsletters/2025/07/18/#ldk-3628 +[news339 filters]: /ja/newsletters/2025/01/31/#bdk-1614 +[news346 evicted]: /ja/newsletters/2025/03/21/#bdk-1839 +[BDK Chain 0.23.2]: https://github.com/bitcoindevkit/bdk/releases/tag/chain-0.23.2 +[zmnscpxj lspstuck]: https://delvingbitcoin.org/t/multichannel-and-multiptlc-towards-a-global-high-availability-cp-database-for-bitcoin-payments/1983/ +[cedarctic bgp]: https://delvingbitcoin.org/t/eclipsing-bitcoin-nodes-with-bgp-interception-attacks/1965/ From 3a7bbfbaeac871e0e3145d6d54282ccb6110a470 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Mon, 22 Sep 2025 15:48:31 +0200 Subject: [PATCH 260/278] newsletter 372 translate in german (#2507) Co-authored-by: garfiel-d --- .../de/newsletters/2025-09-19-newsletter.md | 114 ++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 _posts/de/newsletters/2025-09-19-newsletter.md diff --git a/_posts/de/newsletters/2025-09-19-newsletter.md b/_posts/de/newsletters/2025-09-19-newsletter.md new file mode 100644 index 0000000000..b291f0b606 --- /dev/null +++ b/_posts/de/newsletters/2025-09-19-newsletter.md @@ -0,0 +1,114 @@ +--- +title: 'Bitcoin Optech Newsletter #372' +permalink: /de/newsletters/2025/09/19/ +name: 2025-09-19-newsletter-de +slug: 2025-09-19-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +Der Newsletter dieser Woche fasst einen Vorschlag zur Verbesserung redundanter LN-Überzahlungen zusammen und verlinkt zu einer Diskussion über potenzielle +Partitionierungsangriffe gegen Full Nodes. Außerdem enthalten sind unsere regelmäßigen Abschnitte, die aktuelle Änderungen an Diensten und Client-Software +beschreiben, neue Releases und Release-Kandidaten ankündigen und bemerkenswerte Änderungen an beliebter Bitcoin-Infrastruktursoftware zusammenfassen. + +## Nachrichten + +- **LSP-finanzierte redundante Überzahlungen:** Entwickler ZmnSCPxj [veröffentlichte][zmnscpxj lspstuck] auf Delving Bitcoin einen Vorschlag, LSPs die + zusätzliche Finanzierung (Liquidität) bereitstellen zu lassen, die für [redundante Überzahlungen][topic redundant overpayments] erforderlich ist. In den + ursprünglichen Vorschlägen für redundante Überzahlungen zahlt Alice an Zed, indem sie mehrere Zahlungen über mehrere Routen sendet, wobei nur Zed eine der + Zahlungen beanspruchen kann; die restlichen Zahlungen werden an Alice zurückerstattet. Der Vorteil dieses Ansatzes ist, dass die ersten Zahlungsversuche + Zed erreichen können, während andere Versuche noch durch das Netzwerk reisen, was die Geschwindigkeit von Zahlungen im LN erhöht. + + Nachteile dieses Ansatzes sind, dass Alice zusätzliches Kapital (Liquidität) für die redundanten Zahlungen haben muss, Alice online bleiben muss, bis die + redundante Überzahlung abgeschlossen ist, und jede festsitzende Zahlung verhindert, dass Alice dieses Geld ausgeben kann, bis der Zahlungsversuch abläuft + (bis zu zwei Wochen bei häufig verwendeten Einstellungen). + + ZmnSCPxjs Vorschlag ermöglicht es Alice, nur den tatsächlichen Zahlungsbetrag (plus Gebühren) zu zahlen, während ihre Lightning Service Provider (LSPs) die + Liquidität für das Senden der redundanten Zahlungen bereitstellen, wodurch der Geschwindigkeitsvorteil redundanter Überzahlungen erreicht wird, ohne dass + sie zusätzliche Liquidität kurzzeitig oder bis zum Timeout benötigt. Die LSPs können auch die Zahlung abschließen, während Alice offline ist, sodass die + Zahlung auch bei schlechter Verbindung von Alice abgeschlossen werden kann. + + Nachteile des neuen Vorschlags sind, dass Alice etwas Privatsphäre gegenüber ihren LSPs verliert und dass der Vorschlag mehrere Änderungen am + LN-Protokoll zusätzlich zur Unterstützung redundanter Überzahlungen erfordert. + +- **Partitionierungs- und Eclipse-Angriffe durch BGP-Abfangen:** Entwickler cedarctic [schrieb][cedarctic bgp] auf Delving Bitcoin über die Nutzung + von Schwächen im Border Gateway Protocol (BGP), um Full Nodes daran zu hindern, sich mit Peers zu verbinden, was zur Partitionierung des Netzwerks oder + zur Ausführung von [Eclipse-Angriffen][topic eclipse attacks] verwendet werden kann. Mehrere Gegenmaßnahmen wurden von cedarctic beschrieben, wobei + andere Entwickler in der Diskussion weitere Gegenmaßnahmen und Wege zur Überwachung der Angriffserkennung beschrieben. + +## Änderungen an Diensten und Client-Software + +*In diesem monatlichen Feature heben wir interessante Updates zu Bitcoin-Wallets und -Diensten hervor.* + +- **Zero-Knowledge-Proof-of-Reserve-Tool:** [Zkpoor][zkpoor github] generiert [Proof of Reserves][topic proof of reserves] mit STARK-Beweisen, ohne die + Adressen oder UTXOs des Besitzers preiszugeben. + +- **Alternative Submarine-Swap-Protokoll-Proof-of-Concept:** Der [Papa Swap][papa swap github] Protokoll-Proof-of-Concept erreicht + [Submarine-Swap][topic submarine swaps]-Funktionalität, indem er eine Transaktion anstatt zwei erfordert. + +## Releases und Release-Kandidaten + +_Neue Releases und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie ein Upgrade auf neue Releases oder helfen Sie beim +Testen von Release-Kandidaten._ + +- [Bitcoin Core 30.0rc1][] ist ein Release-Kandidat für die nächste Hauptversion dieser Full Verification Node Software. + +- [BDK Chain 0.23.2][] ist ein Release dieser Bibliothek zum Erstellen von Wallet-Anwendungen, das Verbesserungen beim Umgang mit Transaktionskonflikten + einführt, die `FilterIter`-API neu gestaltet, um [BIP158][]-Filterfähigkeiten zu verbessern, und das Anchor- und Block-Reorg-Management verbessert. + +## Wichtige Code- und Dokumentationsänderungen + +_Wichtige aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ + +- [Bitcoin Core #33268][] ändert, wie Transaktionen als Teil einer Benutzer-Wallet erkannt werden, indem die Anforderung entfernt wird, dass der Gesamtbetrag der Inputs einer Transaktion null Sats übersteigt. Solange eine Transaktion mindestens einen Output einer Wallet ausgibt, wird sie als Teil dieser Wallet erkannt. Dies ermöglicht es, Transaktionen mit null-wertigen Inputs, wie das Ausgeben eines [P2A ephemeral Anchor][topic ephemeral anchors], in der Transaktionsliste eines Benutzers zu erscheinen. + +- [Eclair #3157][] aktualisiert die Art, wie es Remote-Commitment-Transaktionen bei Wiederverbindung signiert und sendet. Anstatt das zuvor signierte + Commitment erneut zu senden, signiert es mit den neuesten Nonces aus `channel_reestablish` neu. Peers, die keine deterministischen Nonces in + [Simple Taproot Channels][topic simple taproot channels] verwenden, haben bei Wiederverbindung eine neue Nonce, wodurch die vorherige + Commitment-Signatur ungültig wird. + +- [LND #9975][] fügt [P2TR][topic taproot] Fallback-On-Chain-Adress-Unterstützung zu [BOLT11][]-Rechnungen hinzu, entsprechend dem in + [BOLTs #1276][] hinzugefügten Test-Vektor. BOLT11-Rechnungen haben ein optionales `f`-Feld, das es Benutzern ermöglicht, eine Fallback-On-Chain-Adresse + einzuschließen, falls eine Zahlung nicht über das LN abgeschlossen werden kann. + +- [LND #9677][] fügt die Felder `ConfirmationsUntilActive` und `ConfirmationHeight` zur `PendingChannel`-Response-Message hinzu, die vom + `PendingChannels`-RPC-Befehl zurückgegeben wird. Diese Felder informieren Benutzer über die Anzahl der Bestätigungen, die für die Channel-Aktivierung + erforderlich sind, und die Blockhöhe, bei der die Finanzierungstransaktion bestätigt wurde. + +- [LDK #4045][] implementiert den Empfang einer [Async Payment][topic async payments] durch einen LSP-Knoten, indem er ein eingehendes + [HTLC][topic htlc] im Namen eines oft-offline Empfängers akzeptiert, es hält und später bei Signalisierung an den Empfänger weitergibt. Dieser PR + führt ein experimentelles `HtlcHold`-Feature-Bit ein, fügt ein neues `hold_htlc`-Flag zu `UpdateAddHtlc` hinzu und definiert den Freigabepfad. + +- [LDK #4049][] implementiert die Weiterleitung von [BOLT12][topic offers]-Rechnungsanfragen von einem LSP-Knoten an einen online Empfänger, der dann + mit einer neuen Rechnung antwortet. Wenn der Empfänger offline ist, kann der LSP-Knoten mit einer Fallback-Rechnung antworten, wie durch die + serverseitige Logik-Implementierung für [Async Payments][topic async payments] ermöglicht (siehe [Newsletter #363][news363 async]). + +- [BDK #1582][] refaktoriert die Typen `CheckPoint`, `LocalChain`, `ChangeSet` und `spk_client`, um generisch zu sein und eine `T`-Payload zu + akzeptieren, anstatt auf Block-Hashes fixiert zu sein. Dies bereitet `bdk_electrum` darauf vor, vollständige Block-Header in Checkpoints zu speichern, + was Header-Redownloads vermeidet und gecachte Merkle-Beweise sowie Median Time Past (MTP) ermöglicht. + +- [BDK #2000][] fügt Block-Reorg-Behandlung zu einer refaktorierten `FilterIter`-Struktur hinzu (siehe [Newsletter #339][news339 filters]). Anstatt + ihren Ablauf über mehrere Methoden zu verteilen, verknüpft dieser PR alles mit der `next()`-Funktion und vermeidet so Timing-Risiken. Ein Checkpoint + wird bei jeder Blockhöhe ausgegeben, um sicherzustellen, dass der Block nicht veraltet ist und das BDK auf der gültigen Chain ist. `FilterIter` + scannt alle Blöcke und holt diejenigen, die Transaktionen enthalten, die für eine Liste von Script-Pubkeys relevant sind, unter Verwendung von + [Compact Block Filters][topic compact block filters] wie in [BIP158][] spezifiziert. + +- [BDK #2028][] fügt ein `last_evicted`-Timestamp-Feld zur `TxNode`-Struktur hinzu, um anzuzeigen, wann eine Transaktion aus dem Mempool + ausgeschlossen wurde, nachdem sie durch [RBF][topic rbf] ersetzt wurde. Dieser PR entfernt auch die `TxGraph::get_last_evicted`-Methode (siehe + [Newsletter #346][news346 evicted]), da das neue Feld sie ersetzt. + +{% include snippets/recap-ad.md when="2025-09-23 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="33268,3157,9975,1276,9677,4045,4049,1582,2000,2028" %} +[bitcoin core 30.0rc1]: https://bitcoincore.org/bin/bitcoin-core-30.0/ +[zkpoor github]: https://github.com/AbdelStark/zkpoor +[papa swap github]: https://github.com/supertestnet/papa-swap +[news363 async]: /de/newsletters/2025/07/18/#ldk-3628 +[news339 filters]: /de/newsletters/2025/01/31/#bdk-1614 +[news346 evicted]: /de/newsletters/2025/03/21/#bdk-1839 +[BDK Chain 0.23.2]: https://github.com/bitcoindevkit/bdk/releases/tag/chain-0.23.2 +[zmnscpxj lspstuck]: https://delvingbitcoin.org/t/multichannel-and-multiptlc-towards-a-global-high-availability-cp-database-for-bitcoin-payments/1983/ +[cedarctic bgp]: https://delvingbitcoin.org/t/eclipsing-bitcoin-nodes-with-bgp-interception-attacks/1965/ From c92b921dc0005c76785c8646f1845c60f1c74ce3 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Mon, 22 Sep 2025 20:11:31 +0200 Subject: [PATCH 261/278] Newsletter 372 translate in French (#2508) --- .../fr/newsletters/2025-09-19-newsletter.md | 158 ++++++++++++++++++ 1 file changed, 158 insertions(+) create mode 100644 _posts/fr/newsletters/2025-09-19-newsletter.md diff --git a/_posts/fr/newsletters/2025-09-19-newsletter.md b/_posts/fr/newsletters/2025-09-19-newsletter.md new file mode 100644 index 0000000000..02e529a789 --- /dev/null +++ b/_posts/fr/newsletters/2025-09-19-newsletter.md @@ -0,0 +1,158 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #372' +permalink: /fr/newsletters/2025/09/19/ +name: 2025-09-19-newsletter-fr +slug: 2025-09-19-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine résume une proposition visant à améliorer les surpaiements redondants +sur LN et renvoie à une discussion sur les attaques de partitionnement potentielles contre les nœuds +complets. Sont également incluses nos sections régulières résumant les changements récents apportés aux clients et services, les +annonces de nouvelles versions et de candidats à la publication, et les résumés des modifications +notables apportées aux logiciels d'infrastructure Bitcoin populaires. + +## Nouvelles + +- **Surpaiements redondants financés par LSP :** le développeur ZmnSCPxj + [a posté][zmnscpxj lspstuck] sur Delving Bitcoin une proposition permettant + aux LSP (Lightning Service Providers) de fournir le financement (liquidité) supplémentaire requis + pour les [surpaiements redondants][topic redundant overpayments]. Dans les + propositions originales pour les surpaiements redondants, Alice paie Zed en + envoyant plusieurs paiements par plusieurs itinéraires de manière à ce que seul + Zed puisse réclamer l'un des paiements ; le reste des paiements est + remboursé à Alice. L'avantage de cette approche est que les premières + tentatives de paiement pour atteindre Zed peuvent réussir tandis que d'autres tentatives + sont encore en cours dans le réseau, augmentant la vitesse des paiements + sur LN. + + Les inconvénients de cette approche sont qu'Alice doit avoir un capital + supplémentaire (liquidité) pour effectuer les paiements redondants, Alice doit rester en ligne + jusqu'à ce que le surpaiement redondant soit complet, et tout paiement qui devient + bloqué empêche Alice de pouvoir dépenser cet argent jusqu'à ce que la + tentative de paiement expire (jusqu'à deux semaines avec les paramètres + couramment utilisés). + + La proposition de ZmnSCPxj permet à Alice de payer uniquement le montant réel du + paiement (plus les frais) et ses fournisseurs de services Lightning (LSP) fournissent la + liquidité pour envoyer les paiements redondants, offrant l'avantage de vitesse des surpaiements + redondants sans exiger qu'elle ait + une liquidité supplémentaire, que ce soit brièvement ou jusqu'à l'expiration. Les LSP peuvent + également finaliser le paiement alors qu'Alice est hors ligne, donc le paiement + peut être complété même si Alice a une mauvaise connectivité. + + Les inconvénients de la nouvelle proposition sont qu'Alice perd une partie de sa vie privée + vis-à-vis de ses LSP et que la proposition nécessite plusieurs changements dans le protocole LN + en plus du support pour les surpaiements redondants. + +- **Attaques de partitionnement et d'éclipse utilisant l'interception BGP :** le développeur + cedarctic [a posté][cedarctic bgp] sur Delving Bitcoin à propos de l'utilisation des failles + dans le protocole Border Gateway Protocol (BGP) pour empêcher les nœuds complets de pouvoir + se connecter à des pairs, ce qui peut être utilisé pour partitionner le réseau + ou exécuter des [attaques d'éclipse][topic eclipse attacks]. Plusieurs + atténuations ont été décrites par cedarctic, avec d'autres développeurs dans la + discussion décrivant d'autres atténuations et des moyens de surveiller l'utilisation + de l'attaque. + +## Changements dans les services et logiciels clients + +*Dans cette rubrique mensuelle, nous mettons en lumière des mises à jour intéressantes des +portefeuilles et services Bitcoin.* + +- **Outil de preuve de réserve à connaissance nulle :** + [Zkpoor][zkpoor github] génère une [preuve de réserves][topic proof of reserves] + utilisant des preuves STARK sans révéler les adresses ou UTXOs du propriétaire. + +- **Preuve de concept d'un protocole alternatif de swap sous-marin :** + Le protocole en preuve de concept [Papa Swap][papa swap github] atteint la fonctionnalité de + [swap sous-marin][topic submarine swaps] en n'exigeant qu'une transaction au lieu de deux. + +## Mises à jour et versions candidates + +_Nouvelles versions et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de mettre à niveau vers les nouvelles versions ou d'aider à tester les versions candidates._ + +- [Bitcoin Core 30.0rc1][] est un candidat à la version pour la prochaine version majeure de ce + logiciel de nœud de vérification complète. + +- [BDK Chain 0.23.2][] est une version de cette bibliothèque pour la construction d'applications de + portefeuille qui introduit des améliorations dans la gestion des conflits de transactions, redessine + l'API `FilterIter` pour améliorer les capacités de filtrage [BIP158][], et améliore la gestion des + ancres et des réorganisations de blocs. + +## Changements notables dans le code et la documentation + +_Changements notables récents dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core +lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], +[libsecp256k1][libsecp256k1 repo], [Interface de Portefeuille Matériel (HWI)][hwi repo], [Rust +Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Propositions +d'Amélioration de Bitcoin (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips +repo], [Inquisition Bitcoin][bitcoin inquisition repo], et [BINANAs][binana repo]._ + +- [Bitcoin Core #33268][] change la manière dont les transactions sont reconnues comme faisant + partie du portefeuille d'un utilisateur en supprimant l'exigence que le montant total des entrées + d'une transaction dépasse zéro sats. Tant qu'une transaction dépense au moins une sortie d'un + portefeuille, elle sera reconnue comme faisant partie de ce portefeuille. Cela permet aux + transactions avec des entrées de valeur nulle, telles que dépenser une [ancre éphémère P2A][topic + ephemeral anchors], d'apparaître dans la liste des transactions d'un utilisateur. + +- [Eclair #3157][] met à jour la manière dont il signe et diffuse les transactions d'engagement à + distance lors d'une reconnexion. Au lieu de renvoyer l'engagement précédemment signé, il signe à + nouveau avec les derniers nonces de `channel_reestablish`. Les pairs qui n'utilisent pas de nonces + déterministes dans les [canaux taproot simples][topic simple taproot channels] auront un nouveau nonce + lors de la reconnexion, rendant la signature d'engagement précédente invalide. + +- [LND #9975][] ajoute le support de l'adresse on-chain de secours [P2TR][topic taproot] aux + factures [BOLT11][], suivant le vecteur de test ajouté dans [BOLTs #1276][]. Les factures BOLT11 ont + un champ optionnel `f` qui permet aux utilisateurs d'inclure une adresse on-chain de secours au cas + où un paiement ne pourrait pas être complété sur le LN. + +- [LND #9677][] ajoute les champs `ConfirmationsUntilActive` et `ConfirmationHeight` au message de + réponse `PendingChannel` retourné par la commande RPC `PendingChannels`. Ces champs informent les + utilisateurs du nombre de confirmations requises pour l'activation du canal et de la hauteur de bloc + à laquelle la transaction de financement a été confirmée. + +- [LDK #4045][] implémente la réception d'un [paiement asynchrone][topic async payments] par un nœud + LSP en acceptant un [HTLC][topic htlc] entrant au nom d'un destinataire souvent hors ligne, en le + retenant, et en le libérant au destinataire plus tard lorsqu'il est signalé. Cette PR introduit une + fonctionnalité expérimentale `HtlcHold`, ajoute un nouveau drapeau `hold_htlc` sur `UpdateAddHtlc`, + et définit le chemin de libération. + +- [LDK #4049][] implémente la transmission des demandes de facture [BOLT12][topic offers] d'un nœud + LSP à un destinataire en ligne, qui répond ensuite avec une nouvelle facture. Si le destinataire est + hors ligne, le nœud LSP peut répondre avec une facture de secours, comme permis par l'implémentation + de la logique côté serveur pour les [paiements asynchrones][topic async payments] (voir le Bulletin + [#363][news363 async]). + +- [BDK #1582][] refactorise les types `CheckPoint`, `LocalChain`, `ChangeSet`, et `spk_client` pour + être génériques et prendre un payload `T` au lieu d'être fixés aux hashes de blocs. Cela prépare + `bdk_electrum` à stocker les entêtes de blocs complets dans les points de contrôle, ce qui évite les + téléchargements répétés d'entêtes et permet les preuves de Merkle mises en cache et le Median Time + Past (MTP). + +- [BDK #2000][] ajoute la gestion des réorganisations de blocs à une structure `FilterIter` + refactorisée (voir le Bulletin [#339][news339 filters]). Plutôt que de diviser son flux à travers + plusieurs méthodes, ce PR lie tout à la fonction `next()`, évitant ainsi les risques de timing. Un + point de contrôle est émis à chaque hauteur de bloc pour s'assurer que le bloc n'est pas obsolète et + que BDK est sur la chaîne valide. `FilterIter` scanne tous les blocs et récupère ceux contenant des + transactions pertinentes à une liste de script pubkeys, en utilisant [les filtres de blocs + compacts][topic compact block filters] comme spécifié dans [BIP158][]. + +- [BDK #2028][] ajoute un champ de timestamp `last_evicted` à la structure `TxNode` pour indiquer + quand une transaction a été exclue du mempool après avoir été remplacée par [RBF][topic rbf]. Ce PR + supprime également la méthode `TxGraph::get_last_evicted` (Voir le Bulletin [#346][news346 evicted]) + car le nouveau champ la remplace. + +{% include snippets/recap-ad.md when="2025-09-23 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="33268,3157,9975,1276,9677,4045,4049,1582,2000,2028" %} +[bitcoin core 30.0rc1]: https://bitcoincore.org/bin/bitcoin-core-30.0/ +[zkpoor github]: https://github.com/AbdelStark/zkpoor +[papa swap github]: https://github.com/supertestnet/papa-swap +[news363 async]: /fr/newsletters/2025/07/18/#ldk-3628 +[news339 filters]: /fr/newsletters/2025/01/31/#bdk-1614 +[news346 evicted]: /fr/newsletters/2025/03/21/#bdk-1839 +[BDK Chain 0.23.2]: https://github.com/bitcoindevkit/bdk/releases/tag/chain-0.23.2 +[zmnscpxj lspstuck]: https://delvingbitcoin.org/t/multichannel-and-multiptlc-towards-a-global-high-availability-cp-database-for-bitcoin-payments/1983/ +[cedarctic bgp]: https://delvingbitcoin.org/t/eclipsing-bitcoin-nodes-with-bgp-interception-attacks/1965/ From 72611f45d1ec1ff958d9d7682487ec0f37dfe194 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Mon, 22 Sep 2025 13:22:08 -0500 Subject: [PATCH 262/278] Podcast: add 371 transcription --- .../en/podcast/2025-09-16-newsletter-recap.md | 862 +++++++++++++++++- 1 file changed, 861 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-09-16-newsletter-recap.md b/_posts/en/podcast/2025-09-16-newsletter-recap.md index 5275b2f122..5da2728ef3 100644 --- a/_posts/en/podcast/2025-09-16-newsletter-recap.md +++ b/_posts/en/podcast/2025-09-16-newsletter-recap.md @@ -19,6 +19,866 @@ Teinturier to discuss [Newsletter #370]({{page.reference}}). ## Transcription -_transcription coming soon_ +**Mike Schmidt**: Welcome to Optech 371 Recap. We're going to talk about a +workbook for learning cryptography, the Eclair 0.13 release, the release +candidate for Bitcoin Core 30, and our Notable code segment, including a bunch +of Eclair PRs that t-bast is going to walk us through, amongst some other +things. Murch and I are joined this week by two guests. First, Jonas. Jonas, +you want to say hi? + +**Jonas Nick**: Hello everyone, I'm Jonas, I work at Blockstream's research +group, and mainly focused on cryptography. + +**Mike Schmidt**: And then, we're also joined by Bastien, or t-bast. + +**Bastien Teinturier**: Hi, I'm Bastien, I'm working on Lightning at ACINQ on +the spec and implementations. + +_Provable Cryptography Workbook_ + +**Mike Schmidt**: Well, thank you both for joining us. We're going to jump into +the News segment. One news item, this week, "Provable Cryptography Workbook." +Jonas, you posted to Delving Bitcoin, and you provided a summary of the goals +and contents of a workbook that you released on GitHub, that focuses on teaching +developers the basics of provable cryptography. What did you set out to do with +this workbook, and also the Crypto Camp event? + +**Jonas Nick**: Yeah, so this workbook was actually developed for this Crypto +Camp event that you mentioned. It was an interactive, in-person workshop, and +the workbook was kind of the basis for that. The workbook itself is something +that cannot only be used for this workshop, but also for self-study, or maybe +even in groups, after this event. The workbook contains mathematical +definitions, propositions, lemmas, theorems and exercises, and there's also a +solutionbook with solutions to these exercises. And the workbook, it covers +selected topics in Bitcoin cryptography. I think that's also one of the +advantages of this workbook over a standard cryptography textbook, which of +course also exists and people can work through those as well. But for example, +what we cover in the workbook is very focused on Bitcoin, onchain consensus +mainly, and for example, there's, I believe, almost no mention of encryption, +which is usually a fundamental part of cryptography textbooks. So, we skipped +that part, because in the Bitcoin consensus protocol, we don't make use of that. + +When we wrote this workbook, we had two primary goals. One was once someone +would have worked through the workbook, they would have sufficient understanding +for reading state-of-the-art papers in the cryptography space, mainly around +signatures, multiparty signatures like DahLIAS Interactive Aggregate Signature +Scheme, MuSig, FROST, etc, and not only read the introduction, but also be able +to understand the meat of these papers, like the security definitions and the +proofs. And the second goal was to learn the skills that are necessary to +formalize security notions for various cryptographic primitives. and I think +this skill is helpful when designing, proposing cryptographic protocols, and +also when reviewing that, because then you can really precisely define what you +mean when you say, "The scheme is secure", or, "I need this primitive with +fulfilling this property XYZ. + +**Mike Schmidt**: What is the mechanics of the workbook? It's not one of these +Python notebooks that I've seen, is it? Is it something different? + +**Jonas Nick**: No, the workbook is a PDF, which looks a little bit like your +cryptographic paper. And the notation is also very similar to what we're using, +for example, in MuSig2 and DahLIAS. + +**Mike Schmidt**: So, this is a pipeline, Jonas, you want more review on your +work, so you're getting a pipeline of cryptographers to be educated on how to +read these materials and provide review, huh? + +**Jonas Nick**: Yes, I think, as I said, it's helpful for reviewing BIPs, +writing BIPs, and things like that. Because if someone were to propose, let's +say, using interactive signature creation for Bitcoin, then if you had worked +through the workbook, you would understand why the scheme is secure and what it +means to be secure and under what conditions it is secure. And I think that's +helpful knowledge in the Bitcoin space overall. And the way this is set up is, +it starts with kind of trying to develop an intuition for what it means for a +thing to be secure. What do we mean by security? And perhaps a lot of people +have some background in cryptography, at least on the practical side, but +they've often not seen how to properly mathematically formalize it. But we need +to formalize it if we want to write proofs, right? So, the first section is +about that, and there are some things that seem to be weird. For example, under +the definitions that we give in this first section, SHA256, for example, is not +secure and it's not even a hash function. + +**Mike Schmidt**: I think you're going to have to elaborate on that one. + +**Jonas Nick**: Yeah, so I would refer to the workbook for that. + +**Mike Schmidt**: Oh, I see. + +**Jonas Nick**: It appears in the very first section. The prerequisites, +perhaps that's also important to mention, is that some basic understanding of +probability theory you would need, like conditional probabilities, sometimes you +need to apply what we call the union bound, and other than that, modular +arithmetic that we've seen, if you add some numbers and you take the modulus +after that, and that gives you a new number. And the kind of approach that +we're trying to take is that cryptography is, in some sense, really close to +programming, because all you're doing in cryptography is writing algorithms and +analyzing algorithms. That's where the probability theory comes in, because you +need to analyze what is the probability that this algorithm will give the +correct result; also, what is its runtime? And programmers, they already have a +good understanding for how to write code, because that's what they're doing. + +**Mike Schmidt**: Now, you mentioned that the focus is cryptography primitives +related to onchain. Would you say that folks working on LN would still benefit +from understanding that sort of base level understanding of the cryptography? +And obviously, there's things then that are maybe in addition in the LN world. + +**Jonas Nick**: Yeah, I think there are some things that definitely also appear +in the LN world, like chapter 3 is about commitments that is also a basic thing +in the LN world. And also, on a higher level, if you look at cryptographic +papers in this field of LN, then there are proofs that would look similar to +what we're doing in the workbook overall. So, this would definitely also help +you understanding these kinds of papers. + +**Mike Schmidt**: Is there anything you learned from putting on the Crypto Camp +that influenced the current iteration of the workbook, or did that basically go +well and this is the material that you used for it? + +**Jonas Nick**: I think, so what I learned when doing the workbook was I think I +did a lot of basic stuff again that I had forgotten about. If you really think +through the foundations of why this all works, I think this is really +interesting and very beautiful even, I would say, at its core, so that was just +really fun to work on. The one other thing I learned was that LLMs these days, +the AI, they're really good. So, if you want to work through the workbook and +you're getting stuck, you can take a picture of the page with the exercise and +ask the LLM to give you hints. Most of the time, it will give you very sensible +hints. So, I think that's a good idea to work through. If you want to work +through the workbook and don't find a group, I think that's a good way to get +unstuck. As for future learnings, this is currently a project on GitHub, it's +all open source, it's licensed under CC0. So, if there are any mistakes or +anything, I accept PRs. There's also a branch for an additional section that +I'm not sure we're going to merge, but it's like sort of work in progress. And +yeah, this only covers the basics. Maybe someone wants to do a second edition +of this as well. + +**Mike Schmidt**: Murch, did you have any questions or comments? + +**Mark Erhardt**: Sounds great. + +**Mike Schmidt**: All right. Well, Jonas, thanks for joining us. You're +welcome to stay on if you want to hear about the rest of the items from the +newsletter. Otherwise, we appreciate your time and your work on putting this +out to the community. + +**Jonas Nick**: Yeah, great. Thanks. + +**Mike Schmidt**: There was no PR Review Club, which would have been our normal +segment this month to cover. I don't think there were any meetings for the Peer +Review Club since we last did it, for whatever reason. So, that, if you're +looking for it, is not present this week. So, we'll move to the Releases and +release candidates segment. + +_Bitcoin Core 29.1_ + +We have Bitcoin Core 29.1, which is the maintenance release that we had actually +spoken about last week, that includes changes to the default min_relay_fee_rate +as well as safety caps on resources, on 32-bit systems, and obviously all of +that is in addition to bug fixes that are in there as well. Murch, did you have +anything else you wanted to add on that this week? + +**Mark Erhardt**: No, we covered that last week already, right? + +_Eclair v0.13.0_ + +**Mike Schmidt**: Yeah. Eclair v0.13.0. We have t-bast on to walk us through +this one. Talk to us about v0.13. + +**Bastien Teinturier**: Okay, so this new release doesn't ship so many features, +but it prepares shipping many new ones basically, because we are at a stage in +LN where a lot of the things we had been discussing for the past three to four +years are nearing completion, and most features, we have them implemented in one +implementation and are waiting for other implementations to also finalize their +implementation so that we can officially ship them. But most of the things are +already there. And interesting, for example, splicing is something that we +shipped two years ago in Phoenix and we're just waiting for another +implementation to finalize their work. And CLN (Core Lightning) and LDK are +actually quite close to that. So, I hope that by the next release or the +release after that, we're going to be able to ship a splicing implementation +that works across the network. Same thing for dual-funding, same thing for +eventually liquidity ads. So, there's a lot of things that have been +progressing quite well. + +But the things that we would like to really focus on and that will matter a lot +for most node operators today is upgrading the transactions we create for LN +channels, and benefiting from, first of all, taproot, for example, and this is +something that LND had started working on a long time ago and we have started +working on as well. And so, in that release, we are almost complete on taproot. +We're just not activating it yet because there are small incompatibilities with +LND that we need to resolve, and the spec is lacking on some of those +incompatibilities. But we had to do a lot of basically refactoring to make sure +that we were able to support all the channel types, the type of channel +transactions that we support today, plus the one for taproot, and then more +importantly, the next ones that are going to use v3 transactions without taproot +and v3 transactions with taproot, the end goal being preparing our codebase and +our end nodes to gradually evolve towards using v3 taproot transactions, which +is going to be the final form, at least for the next year of LN channels. You +had a question, Murch? + +**Mark Erhardt**: Yeah, I wanted to jump in quickly. I was aware that Lightning +Labs had been working on a concept called simple taproot channels, then there +were several iterations, I think something called taproot channels 1.5 and 1.75. +Can you walk us through what the final version of the taproot channels that +you're rolling out will be now? + +**Bastien Teinturier**: Okay, so those 1.5 and 1.75 were mostly for the gossip, +for what we announce, what we change in the gossip, especially to fix one big +privacy issue we have on LN, which is that we gossip. One of the interests of +using taproot and MuSig2 for the channels is that the channel output is just +going to be a standard P2TR output that is spent by single-signature, and people +don't have to know that it is actually using MuSig 2 and is an LN channel. But +then, so when we start using that in LN, it looks like we are gaining privacy, +but then we are losing everything by just revealing to the world in the LN +gossip network, "Hey, by the way, this is my channel. Please route payments +over this". + +So, the first step is to change the structure of the LN transactions to actually +use taproot and use MuSig2, and this is what is in the simple taproot BOLT. +It's just changing the transactions used in LN channels to use MuSig2 for the +funding output. And then we said, "Yeah, but this is not enough. We need to +fix the privacy leak in the gossip network". And so, for updating the gossip, +there are several proposals: 1.5, which doesn't fix anything related to privacy, +but changes the format so that we're more flexible in the future and we can +improve more things in the future; then 1.75, I don't even remember exactly what +we changed in that one; and 2.0 is the eventual end goal, where we don't reveal +the outpoints of the channel, the UTXOs of the channel, but instead some kind of +zero-knowledge proof that we have a channel somewhere among a set of UTXOs that +has maybe some capacity, and it should allow us to advertise virtual channels +basically. + +But what we've been working on so far mainly is only the simple taproot thing, +which is only updating the LN transactions, and first only supports private +channels, unannounced channels so far. And what has been implemented in LND and +Eclair doesn't support announcing those channels yet, and this will come in a +second phase. It's only working on the transaction layer so that we have better +usage of our transactions and better fee management, and then gossip will come +afterwards. + +**Mark Erhardt**: Could you remind me, the channels that the Eclair node makes +with the Phoenix customers, are those private channels or are those public +channels? + +**Bastien Teinturier**: Yeah, those are private channels. So, that's why we +have started working on taproot because we're going to be able to ship quickly +because those are channels that we don't announce to the network. So, as soon +as we have compatibility with LND on these taproot transactions, we're going to +be able to immediately roll it out to Phoenix users and opportunistically +update, upgrade their existing channels whenever there's a splice. So, +basically, whenever there's a splice on the Phoenix channel, that was previously +using just anchor outputs, we're going to take this opportunity of making an +onchain transaction to actually move it to a MuSig2 output. So, slowly we will +be able to upgrade Phoenix users to use MuSig2 as their funding output. + +**Mark Erhardt**: Very cool, very cool. + +**Bastien Teinturier**: And then the end goal in that big refactoring, we also, +in that release, announced that we are going to stop supporting channels that do +not use anchor outputs and use previous versions of LN channels, so what was +called static remote key and the even older just plain legacy channel. The +issues with those type of channels is that since they didn't use anchor outputs, +they didn't have any way to do CPFP and we had to just predict the feerate and +update regularly the feerate of a commitment transaction. So, it's been at +least two years, I think, that every implementation has shipped support for +anchor outputs. But some people have channels that are older than that. + +So, I spent the past year encouraging people to take the opportunity of an empty +mempool to close all those legacy channels and open new ones that use anchor +outputs. And this release of Eclair is going to be the last one where we +support these old channels. We're going to remove the code for those in the +next release. So, people have to close them now if they want to be able to +upgrade to the 0.14 release later. So far, all node operators have told me that +they had already closed those channels a long time ago and only have anchor +outputs channels. But there are still channels on the network that are not +using anchor outputs. So, people should really update because before adding +even more transaction types, when we start using v3 as well, we need to be able +to clean up some technical debt and to clean up some old code so that we can +manage the complexity and still get a good coverage of everything. + +**Mark Erhardt**: Cool. So, there's basically two migrations going on at the +same time, just getting people into anchor output channels, which is ancient +history already; and now also, with TRUC (Topologically Restricted Until +Confirmation) and ephemeral anchors, the idea of having zero-fee commitment +transactions finally is here, or the idea was here for a long time, the +implementation is here now too. Maybe just to recap it quickly again, the big +problem with the LN channels is that whenever you update the channel, so for +example, when you fold an HTLC (Hash Time Locked Contract) back into the channel +or create an HTLC or splice, you predicted in the past the feerate at which the +transaction would confirm. And that, of course, you have no information when +you'll actually want to do a unilateral close, you have no idea what the +feerates then might be. So, these had to be fairly conservative and tended to +overshoot a lot. And then, with anchor outputs, this got better because now the +fee only had to predict correctly the minimum of the mempool so that the +transaction could propagate. So, it had to be high enough to be above the +dynamic minimum of mempools, so it would get into mempools, and then it would be +bumped by the anchor output. + +But now, with TRUC transactions, we're getting to a point where the parent +transaction can have a fee of zero, have an ephemeral anchor, and then the fee +is determined by the child that you create at the moment where you want to do a +unilateral close. This means that all of the balance in the channel, as defined +per the commitment transaction, is available for the channel. There is no +channel reserve because you don't have to spend from the channel directly to pay +the fees, and you bring the fees at the moment that you make a unilateral close. + +**Bastien Teinturier**: Since v3 restricts the packages that are used and has +less pinning issues than v2 transactions, we can also relax some outputs where +we previously had CSV-1 (CHECKSEQUENCEVERIFY), which means that we can actually +use some funds that are inside the channel, inside the commitment transaction to +pay the fees, which is really nice and is the endgame, to be able to actually +pay the onchain fees just based on money that is already inside the channel, +instead of having to use another external UTXO to bump the fees, especially for +mobile wallet users who usually don't have UTXOs available to do some fee +bumping. So, once we use TRUC transactions, since mobile wallet users have a +smaller attack surface than routing nodes, because they don't route payments, +there are ways to make sure that they have a way to pay the onchain fees by +using the outputs of the actual LN channel. And this is something I started +discussing on Delving Bitcoin a while ago, and we have a protocol that we think +is going to work well enough and we are going to actually implement it once we +move to TRUC transactions. + +**Mark Erhardt**: Sorry, could you explain that a little more? So, usually the +commitment transaction outputs are of course fixed. How would the funds come +out of the commitment transaction and become available for fees? + +**Bastien Teinturier**: It's just that when you spend the ephemeral anchor, you +would also spend, for example, your main output of a channel, so that you have +funds coming from the main output of a channel, and you can just decrease your +change output to consume those funds to pay the fees, basically. And if you +also have HTLCs that are pending, you can do the same thing. And also, all the +dust HTLCs that are currently pending on the channel are going to be +automatically added to the onchain fees. So, there are multiple ways you can +actually pay some of the onchain fees using funds that are actually inside the +channel. + +**Mark Erhardt**: Cool, thank you. + +**Mike Schmidt**: T-bast, it sounds like you share some of BlueMatt's +enthusiasm. I think I heard him on a podcast earlier this year saying +optimistic things about LN, which he doesn't always do. It sounds like you're +optimistic as well. I know you guys have had some ability, given the +architecture of Phoenix, to roll some of these things out sooner, but it sounds +like you're excited for it to be more broadly disseminated, some of this +technology. + +**Bastien Teinturier**: Yeah, definitely, because I've had to write the annoying +code that is imperfect and has to walk around the fact that we are unable to +correctly predict the feerate, that there are cases where if we don't use TRUC +or we don't use package relay, there were cases where we knew that potentially +we were at risk of not being able to get a commitment transaction confirmed in +time. So, I'm really happy to see that now, I'm able to remove that code. It +removes a lot of code from the codebase, so a smaller attack surface as well on +the codebase, which is really nice. And the protocol becomes simpler than what +we had before. So, basically, what we see is that as we roll out those things, +the LN protocol actually becomes simpler, which is a very good thing as well. +So, the end goal is to be able to have channel transactions that are easier to +understand, that have less edge cases or less weirdness that is here just to fix +some nasty attack scenarios, and make it more accessible to everyone basically, +and more efficient onchain as well. + +**Mike Schmidt**: Anything else that you'd like to say about v0.13? + +**Bastien Teinturier**: No, just update your node if you have an Eclair node +that isn't updated yet, because it's just going to get better. + +_Bitcoin Core 30.0rc1_ + +**Mike Schmidt**: All right. T-bast, thanks for walking us through that +release. There's a few Eclair PRs later that hopefully we can get to in short +order. But we'll wrap up the Releases section first with Bitcoin Core 30.0rc1. +Release notes are currently under draft for this RC in this release. Murch, how +deep do you want to get today on 30? + +**Mark Erhardt**: I think that we might not want to get too deep yet. The +release notes, it's just RC1, the testing is starting. This is already pretty +long, but I'm sure there'll be a few amendments still and improvements. I don't +know. Did you want to jump into what's in there? I think a lot of the policy +changes, for example, are already in the public eye. + +**Mike Schmidt**: Maybe what we can do is we can just do a quick, as if this +were a movie, we can give sort of the trailer release. And if folks are looking +for the details and the work in progress of the release notes draft, that's on +GitHub. It's in the Bitcoin-Dev wiki right now. So, you can look at sort of +what I have up on my screen that I'm looking at, along with a bunch of other +details. Murch sort of gave away the punchline, which I think everybody knows +about these policy changes in terms of, well, one that we've talked about on the +show, and I'm simply going in order of the policy segment here, but limiting +legacy sigops in a single transaction to 2,500 from a standardness perspective. +Everyone's been talking about data carrier size default changing to 100,000 by +default, but there's also the multi-data carrier, multiple outputs in a +transaction as well, which is sort of part of that change, but conceptually +different. There's also the minimum block feerate that we talked about a couple +weeks ago, that PR on the show, and then the minrelaytxfee and +-incrementalRelayFee default changes, based on a lot of the sub-satoshi summer +that we've seen and a lot of those transactions confirming, and we referenced +0xB10C's research on this showing compact block reconstruction, the cells in his +chart turning red, which is bad for compact block reconstruction. Go ahead, +Murch. + +**Mark Erhardt**: Yeah, I wanted to point out that the minimum relay feerate +change already shipped also in 29.1, as we mentioned last week. So, what we saw +was that something like 80% of all blocks had a lot of transactions on the order +of 800 kB of data that we would download from our peers when a new block got +announced, and we just found that this delays the block propagation quite a bit. +So, the change is that the minimum relay fee is adjusted to what some miners +include, and since then some miners have adjusted their minimums a little bit, +but currently we see transactions quite often confirming at 0.26 sats/vB +(satoshis per vbyte), so I think this seems to be here to stay. + +**Mike Schmidt**: There are some changes to the P2P network, improvements to +1p1c (one-parent-one-child) package relay, some changes in the orphanage. We +can get into those maybe in a future show, once these release notes get a little +bit more solidified. We talked about the new Bitcoin command at some point, +which is related to these separate binaries that will be available if you choose +to run them separately. And thus, we also talked about the IPC, the +Inter-Process Communication, I believe, interface between those binaries, +including the mining interface, which is sort of the catalyst for pulling the +trigger on these multiple binaries actually being released. + +One thing that I didn't see in here, which I think is pretty funny, and I +mentioned it to you, Murch, is there doesn't seem to be reference to the +speed-up in IBD (Initial Block Download). Maybe that's in here. I looked for +IBD. I looked for the word 'download' and I didn't see it, which is kind of +funny that that's kind of a major benefit, but didn't make it in just yet. So, +for listeners that are curious, I did see something from Lawrence, I think, on +Twitter that showed something like 17% to 20% or more improvement in IBD, based +on a slew of PRs that were made to Bitcoin Core, that made subtle and good +improvements that resulted in this aggregate speed-up in IBD, which is good to +see. I think that should be in the release notes somewhere. + +The other things, the RPCs, we can get into a little bit more and maybe, as in +the past, we've had folks who did a testing guide based on the release so that +folks can walk through a testing guide. Maybe we'll have somebody from that +team who drafts that come on and we can get a little bit deeper into this. But, +Murch, is there anything else that you want to highlight in our trailer edition? + +**Mark Erhardt**: Maybe just there's a bunch of changes all over. Also, for +example, TRUC support in the wallet and the removal of the legacy wallet. The +release cycle for the prior release was a little short because we went on a +fixed schedule, and now this one is a little longer again. And I think some of +the things that got bumped out of the last release are now additionally in this +release. So, yeah, I think we'll have a pretty long conversation about this +next time. + +_Bitcoin Core #30469_ + +**Mike Schmidt**: Moving to Notable code and documentation changes, Bitcoin Core +#30469 is a PR titled, "Fix coinstats overflow". Murch, what's going on here? + +**Mark Erhardt**: So, apparently someone discovered that the coinstats index on +signet had an overflow because, well, the values that got summed up could go out +of bound of the type of integer that was being used to represent them. So, it +was fixed on signet and mainnet. Of course, it's not broken on mainnet, only on +signet. So, it's more like a no-op for you right now. When you start up +Bitcoin Core the first time after this patch, it will rebuild the coinstats +index and keep a copy of the old one next to the new one. Start using the new +one going forward, but the old one is there in case you decide to downgrade to +an older version. Other than that, yeah, that's pretty much it. + +**Mike Schmidt**: And so, how does this manifest itself if there was an overflow +on signet? Is that just an error; is that a note in a log; is that a crash, do +we know? + +**Mark Erhardt**: I don't, sorry. + +_Eclair #3163_ + +**Mike Schmidt**: Okay, I don't either. Okay, onto our Eclair PR parade. We +have Eclair #3163 PR titled, "Add high-S signature BOLT11 test vector". That +sounds not super interesting to have t-bast explain, but we have him here to +explain it anyways. So, what's going on with that one? + +**Bastien Teinturier**: It is actually interesting, because it is somewhat +related to the fact that we discussed cryptography earlier about the crypto +book. There's something slightly weird that everyone usually gets surprised by. +There's this concept of high-S and low-S signatures for ECDSA, and there's one +thing that's interesting. So, basically, Bitcoin Core uses low-s signatures +everywhere. But there's something interesting in the secp256k1 API, is that +when there are two ways to basically consume an ECDSA signature, if you have the +public key and the signature, you can verify that this was a signature made with +that public key. And in that case, the secp256k1 API will only accept it if the +signature is actually using low-s not high-s. But if you don't have the public +key and you only have a signature, there's one thing you can do with ECDSA that +you cannot do with schnorr, but you can do with ECDSA, is that based on the +signature, you can recover the public key if the signature was valid for that +public key. But this will work in both cases where the signature is low-s and +high-s. + +So, you could start with a signature that you use the pubkey recovery API on it. +It's going to tell you, "Perfect, this is a valid signature for that public +key". And then if you call the verify signature API with that public key and +the signature, it's going to say, "Oh, this is not a valid signature". So, this +is a bit weird, but this is also because using pubkey recovery is a bit weird. +And the only reason we do that is because it saves space in the invoice. You +basically just include the signature and not the node ID. So, you save 33 +bytes, which is interesting in the QR codes. And we didn't think about it much +when we wrote BOLT11. So, we didn't think about whether we should accept or not +accept high-S signatures for when doing pubkey recovery. So, since it wasn't +specified, there's just a divergence here and some implementations accept it and +some don't. And what we decided is to just do the same thing as what secp256k1 +does. And if you are also providing the node ID, then we only accept low-S +signatures. And if you are using a public key recovery, we accept everything +because we want to make sure that we don't break backwards compatibility. But +this is something that we should specify better. + +Now, we won't have this issue because we are using schnorr sigs everywhere. But +if we had to do it over, we should have specified it better. + +**Mark Erhardt**: Wouldn't you be able to just convert the S-value and then use +the regular approach? Maybe we can ask our present cryptographer if he knows. + +**Jonas Nick**: Well, the problem with these signatures is that you don't have +the corresponding public key, right? You get the signature, then you call the +recover function to recover the public key. And then, you don't know if the +signature had low-S or high-S. So, what you can do would be to what we call +normalize the signature. There's a function for that in libsecp. And then, you +can give it to ECDSA verify to verify it again and actually check if it had low- +or high-S. But that seems to be overkill. + +So, first of all, I want to say this wasn't properly documented in libsecp. So, +there's a PR that I just reviewed today that improves the documentation on that. +But the guarantee that you have is that if this recovery succeeds, then the +signature is valid for this public key. But that doesn't mean that ECDSA verify +passes in libsecp. It only passes after you've normalized it. But usually, +that shouldn't matter and you shouldn't need to additionally verify anything. +You can just call recover, signature is valid. If you care about malleability, +well then it's an issue. If there is a use case where you care about +malleability in recovery, then we should add it to libsecp to provide a recovery +function that actually checks whether the signature is low-s or high-s, and +rejects high-s signatures same way as ECDSA verify. + +**Mark Erhardt**: Sorry to double-down, but ECDSA signatures are an R value and +an S value. Both of them can be high and low, which just means whether they're +in the upper half or lower half of the available values. So, wouldn't you be +able to just look at the signature and immediately see whether it's high-S? + +**Jonas Nick**: Yeah, I guess that should work. + +**Mark Erhardt**: Okay, all right. + +**Jonas Nick**: But we don't have a function right now in the libsecp to do +that. + +**Mark Erhardt**: All right. + +**Jonas Nick**: I think it's perhaps easier just to encapsulate all the +functionality in one function, recover low-S, or something. + +**Mark Erhardt**: Right, but so you say you could normalize it and then the +verification would pass. So, you will apparently get the same public key +whether you do it from the high-S or the low-S to recover, right? + +**Jonas Nick**: Yeah. + +**Mark Erhardt**: So, if you first normalize, you could just... right. Okay. +No, I think I get it. Cool. So, basically, just check whether it's high-S and +then use the low-S function and it should all work? + +**Jonas Nick**: I think the fix that Bastien was talking about just accepts +high-S and low-S, because that's backwards compatible. + +**Bastien Teinturier**: Yeah, because if there's an implementation out there +that produces high-S signatures for BOLT11 invoices in a wallet that people +actually use, we don't want to start rejecting them, because there's just no +reason to reject them. We don't care about malleability issues here. And the +only thing is that you cannot just change them automatically because there's a +checksum in the BOLT11 invoices, so you would break that checksum, but it just +doesn't matter. There's no reason to reject the high-S one. + +**Mark Erhardt**: Right. Of course, you wouldn't want to break the checksum, +but for the check for the public key, you can totally just use the low-S. +Anyway, I think we've dived in quite enough here. + +**Mike Schmidt**: Well, it's kind of funny. I thought this was going to be the +boring one, but I guess when you have a bunch of smart guests and a smart +co-host, that even the test vector for BOLT11 high-S signatures can be +interesting. All right. + +_Eclair #2308_ + +Eclair #2308, "Use balance estimates from past payments in path-finding". + +**Bastien Teinturier**: Oh, yeah, so this is something that has been discussed +for basically years among LN implementations, is that you could, whenever you +are choosing a path in the network to send your payment, basically you know the +balances of the channels that you have, but you don't know the balances of the +channels that other people have. So, maybe you are trying to send a payment, +but there's not going to be enough balance in the direction you want in one of +the remote channels that you're using. So, basically, every LN implementation +uses a lot of heuristics to score each channel, each pair of nodes, to try to +evaluate whether they are likely to be able to relay that payment or not. And +it's been years that we realized and we knew that we just had to write the code +to record data from past payments, because based on past payments, you can see +that if a payment was rejected somewhere along a path with an error that tells +you that this was rejected because there's not enough balance, you know that at +some point there was not enough balance in that channel. And you also know that +there was enough balance on the channels before that one, because it got to that +node. So, all the channels before that had enough balance for that payment. + +So, based on that, you can start to record data about some places where you know +that at some point in time, there was enough balance or not enough balance for +that size of payments. And you could use that to score the channels that you +use in your pathfinding algorithm. And I think that all implementations right +now have some implementation for that with divergences, basically, on how they +make the data they collected expire. Because at some point, if you knew that +two days ago a payment was able to go through that channel, the balance could +have changed entirely since then, so maybe that data is stale. But in Eclair, +we had, I think, yeah, we shipped the first version of that two years ago, but +we just didn't activate it by default, because we wanted to just use it in +shadow mode on our node to verify that it seemed to work well or not. And so, +now, we are introducing that flag because it seems to be working well. So, we +don't turn it on by default, but probably we're going to turn it on by default +in the next release, but people can start experimenting with that and see if it +affects their pathfinding and if they get better success rates than before. + +**Mark Erhardt**: Right. I just wanted to highlight again, when you make a +payment attempt, you basically learn how many of the hops succeeded at that +attempt. Most of the LN payments are multi-attempt, or maybe more of them are a +single attempt now, but they used to be quite a few tries. So, basically, on +every hop that forwarded the multi-hop contract, you learn a lower bound on what +it has at least, and then the one that rejects it due to insufficient balance, +you learn an upper bound of how much it has at most. So, if you remember that, +you can use that information for future pathfinding, especially future attempts +in the same payment. You wouldn't want to try the same channel over and over +again when you already know it doesn't have enough money. + +**Bastien Teinturier**: Yeah, exactly. So, this saves on latency because you +can avoid paths that you know most likely don't have enough balance throughout +the payments. And this becomes especially useful when you are running an LSP or +wallet providers, because you will, in most cases, use something like Trampoline +to compute paths for all of your users. So, you are actually converting way +more paths than just for a single user. So, you are constantly trying to send +out payments, so you are constantly learning data about channels. And this is +something that all of your mobile wallet users benefit from, because the +payments from other people improve the reliability of your payments. + +**Mike Schmidt**: T-bast, do you have metrics on this, on improved latency or +improved success rates using or not using this? + +**Bastien Teinturier**: Not yet, because to get those, we needed to actually +turn it on by default, because before that we were only shadowing it and +comparing the results, but not actually using it to select the paths. But now, +we have deployed on our node, using it for I think 20% of payments are going to +use this, so we'll be able to collect data on actually really using that saves +that much compared to payments that don't use it and use the other heuristics +instead. + +_Eclair #3021_ + +**Mike Schmidt**: Cool. Thanks, t-bast. Eclair #3021, "Allow non-initiator RBF +for dual-funding". + +**Bastien Teinturier**: Okay, so this one is actually quite trivial. It really +just looks like this is something we had kind of missed in the initial +dual-funding specification. So, when we introduced dual-funding, basically the +two nodes in the channel are able to contribute to the funding transaction by +adding inputs and outputs. And another benefit of dual-funding is that if the +transaction doesn't confirm, you are able to RBF it. You just restart creating +that transaction and you change some of the inputs and outputs. But before +that, I think that the specification explicitly said that only the initial +opener was allowed to initiate RBF, but it actually doesn't make sense, because +if the other guy also decides to contribute to the transaction and it doesn't +confirm, maybe they're fine with doing RBF on their side and putting more fees +in that channel because it matters to them. So, we just allow them to also +initiate RBF. Basically, both sides are able to initiate RBF whenever they want +to. + +The only small details in that case is that since we have also implemented +liquidity purchases, liquidity advertisement, when one side can open a channel +to another side and say, "Please, I want you to put that amount on your side so +that I can receive payments, and I'm willing to pay you for this liquidity that +you are going to allocate to me", in that case, it can only be the node that +starts the protocol that purchases this liquidity, because I am initiating a +liquidity purchase. So, if I RBF, then there's no issue. I can RBF and +renegotiate that liquidity purchase or potentially even remove it. But if you +initiate RBF, then you won't know. Basically, we change who initiates the +protocol, so there's no way to handle that liquidity purchase. So, this is just +one small edge case where in that case, if someone is opening a channel to you +and they are willing to pay you to allocate funds, then you're going to let them +RBF because they have more at stake basically in that channel than you do. + +So, yeah, it's basically just an edge case that you have to handle. But apart +from that, everything just made sense. You just need to make sure that people +don't try to cheat you by saying, "Okay, I want to open a channel to you and I'm +gonna pay you for the liquidity", and then if you don't pay attention and you +RBF, you're going to offer that liquidity without getting paid for it. So, +basically you would be screwed. So, it's just an implementation culture. + +_Eclair #3142_ + +**Mike Schmidt**: And Eclair #3142, PR titled, "Allow overriding +max-closing-feerate with forceclose API". + +**Bastien Teinturier**: Okay, so this one is also linked to RBF, because +whenever a channel gets forced closed, there are some transactions that you +really have to get confirmed quickly, because HTLCs, for example, or if this is +a revoke commit, there's a race between both channel participants to get the +funds back. So, for those, Eclair will automatically use a feerate that ensures +that these get confirmed before the other side can steal money from you. But +there are also transactions where the other side cannot steal anything from you, +and you are not potentially in a rush to get those funds back. And so, what +we've done is that we've given more knobs here so that people can say, "I'm not +in a rush to get those non-urgent transactions back to me. I'd rather wait more +and save on fees". And so, this is basically what this allows you to do, to +decide on a per-channel basis, especially for example in that case, when we +decide to close a lot of channels that we have with people who have just +disappeared and stayed offline for one year, and we know we will never see them +again, then we save a lot on fees by deciding to just be patient and make sure +that we cap the feerate and disable automatic RBF. And we're basically just +able to wait to get our funds back, instead of paying more fees. + +Otherwise, without this parameter, Eclair would automatically try to RBF +regularly to get your funds back, which can potentially become expensive. So, +here you just configure your max-closing-feerate according to what you want to +pay at most, and Eclair will RBF up to that feerate and then otherwise it's just +going to stop. And if you want to get those funds back because this is not +confirming and now you actually need the funds, then you can just call the API +again to change the value for the max feerate. + +**Mike Schmidt**: That wraps up the Eclair PRs. We have two other LN PRs, both +to LDK, one of which, well, probably both of which, t-bast, maybe you can help +narrate as well, even though that's not the implementation you work on. + +_LDK #4053_ + +LDK 4053 is a PR titled, "Create a single P2A on commitment transactions and 0FC +Channels". We at Optech also sometimes refer to these as v3 Commitments. This +is part of LDK's zero-fee commitments project with the tracking issue #3789, if +you're curious about the broader effort in LDK, that allows LN commitment +transactions to use TRUC, P2A outputs, ephemeral dust, sibling replacement +techniques together to allow for zero fees in the commitment transaction. I +think we kind of touched on this earlier, t-bast, but obviously you don't know +the implementation details. + +**Bastien Teinturier**: I do, don't worry. This is based on the spec PR I wrote +for that commitment format. And I'm working closely with the LDK team on that +one and also on the next one. So, basically, it is the v3 commitment format, +the one that doesn't use taproot. So, yeah, we had, I think six months ago, LDK +and Eclair prototyped an implementation of that. But we put it on hold because +we needed bitcoind 29 to be out to support relaying those ephemeral anchors. +And now that bitcoind 29 has enough nodes on the network, it's a good time to +resume that effort. Because we cannot ship that thing if those commitments +don't relay to the miners. So, we had to wait for enough of a network to +upgrade the Bitcoin node. And now, we are at the point where I know that the +LDK team wants to move fast on this commitment format, which I love, because +this means that we'll be able to get cross compatibility quickly and we'll be +able to get the specification PR merged as well. + +So, on Eclair, I basically need to rebase my implementation and we'll be able to +test those things. So, it's what we discussed earlier, as you said, where a +commitment transaction uses zero fees, we use a single anchor, it removes some +burdens on the other outputs that don't need a CSV-1 anymore. And HTLC +transactions are also going to use v3, and this protects against pinning and +makes it easier to set the right feerate for your package, basically. So, this +is really important. Whenever this is available, people should upgrade and +should start using that type of channel on their nodes. + +**Mike Schmidt**: You mentioned the importance of waiting for adoption and then +the relay of these transactions. I saw something online that someone was +pointing out, that potentially the default settings in Knots and potentially the +latest Bitcoin Knots version will filter transactions that maybe don't have zero +fee, but have something above zero fee. Obviously, if that is the case, that +would hurt propagation of those transactions. But also, if someone is an LN +user and using their Knots node, there's concerns there as well. Murch, did you +have a comment? + +**Mark Erhardt**: Yeah, I wanted to point out not just propagation, but if you +run an LN node yourself and your own mempool doesn't accept it, it will not go +out to the network. So, my understanding is that by default, Knots 29.1 will +only relay ephemeral dust with zero amounts, not non-zero amounts, and it will +also not enforce TRUC rules. So, this is going to be an issue for LN. So, if +you do that, this is going to be an issue for the next type of LN channels we're +going to use. So, I hope this gets changed in the future, because this is +payment, so this is what we want. We want to make sure that Bitcoin is used for +payments, so we should definitely relay those transactions. Otherwise, we're +going to prevent people from making LN payments. + +**Mark Erhardt**: Just to be clear, I've been looking at the code a little bit, +I believe the defaults are that it does accept v3 transactions and will relay +them, it just doesn't enforce the restrictions on topology that v3 introduces or +the TRUC rules; it treats them like any other transaction. And for the +ephemeral dust or the anchors, it only accepts zero amounts, if I understand it +correctly. So, specifically, if you have a non-zero amount, which I'm not sure, +why do you need non-zero amounts in this potentially? + +**Bastien Teinturier**: We do need non-zero amounts, because when there are +pending HTLCs in the channel that are below dust, we need to put their amount +somewhere. So, what we do, if I remember correctly -- I need to check. If I +remember correctly, what we do is that we put them inside the ephemeral anchor +until it reaches 240 sats, and once it reaches 240 sats we instead let them go +to minor fees and we fix the ephemeral anchor at 240 sats. And I remember it +was instagibbs who proposed this capping mechanism and there was a good reason +for it. I don't remember it, but it is written down in my spec PR somewhere. + +**Mark Erhardt**: I'd be curious, because just dropping it to minor fees would +make more sense for the smaller amount rather than the bigger amount. So, it +kind of feels surprising to me that the smaller amount gets put into the +ephemeral anchor and the bigger amount gets dropped to the fees. So, anyway. + +**Bastien Teinturier**: I think it was related to standardless rules somehow. + +**Mark Erhardt**: I mean, I think you wouldn't want the ephemeral anchor to be +too big, because then it would encourage the transaction to ... + +**Bastien Teinturier**: Yeah, even if it is too big, everything will be consumed +by miners, basically. So, if you end up with an ephemeral anchor output that is +like 50,000 sats and you try to only consume part of that with your TRUC +transaction, rational miners will just replace your TRUC transaction by one that +consumes everything, because … + +**Mark Erhardt**: Oh, right, yes. + +**Bastien Teinturier**: … it doesn't need a signature, so it will be replaced. +So, it doesn't make sense to let the amount of the ephemeral anchor become large +because anyone can steal it. So, that's why we cap it. But I don't remember +why we have to gradually go from 0 to 240 sats. + +**Mark Erhardt**: Yeah. Also, we don't want a fee on the parent transaction +because we don't want the parent transaction to be mined without the child that +spends the dust output, right? Anyway, maybe we'll have to have you back or +someone else that can explain that to us. We'll figure it out until next time +and double-click on that. + +**Bastien Teinturier**: This was detailed, discussed in a Delving post, so I can +find it and I can tweet it in response for people who are interested. + +**Mark Erhardt**: Thank you, that would be lovely. + +_LDK #3886_ + +**Mike Schmidt**: Thank you. Last PR this week, LDK #3886 titled, "Update +channel_reestablish for splicing". "The splicing spec extends the +channel_reestablish meshes with two more TLVs, indicating which funding txid the +sender has sent/received. This also allows peers to detect if a splice_locked +was lost during disconnection and must be retransmitted". T-bast, you probably +have some familiarity with this. What is LDK changing here? + +**Bastien Teinturier**: Yeah, so basically, we've been working a lot on the +channel_reestablish requirements for splicing, because basically some of the +things we've done in violating protocol, regarding what we retransmit when we +reconnect, were somewhat hacky. And we realized that for splicing, we had to +have more cases where we retransmit some stuff on reconnection. And it was a +good opportunity to do it in a less hacky way. And we had a first version that +I had written down, and then Jeff pointed out that it was a bit misleading in +many ways and could be improved. So, thanks to Jeff's suggestion, we've been +able to basically simplify the spec and simplify the protocol, by just changing +what we put in when we reconnect which data we need from the other side. So, +this PR is just basically implementing the latest changes we made to the +specification. And I think that with this PR, LDK and Eclair should have the +same implementation of splicing. And I think, once this is merged, we're going +to be able to start cross-compat tests for splicing between Eclair and LDK, +which is really, really nice. + +**Mike Schmidt**: That's awesome. Great to hear. And folks who are curious +about the link that t-bast mentioned, look for some response in some of the +Optech Twitter handle, and you can find it there. That wraps up the newsletter +this week. T-bast, thanks for hanging on for the whole thing and walking us +through a bunch of segments. It was mostly the t-bast show, which is kind of +fun. It's been a while. We had Jonas on earlier talking about cryptography, we +thank him for his time. And, Murch, thank you for co-hosting and for everybody +for listening. Cheers. + +**Bastien Teinturier**: Thanks for having me. Bye. + +**Mark Erhardt**: Thanks. Good to have you. It's nice to get so many details +on LN. We were definitely missing that. + +**Bastien Teinturier**: I'm happy to join anytime. Thanks. {% include references.md %} From e5e69d272505c29f6293ee6abd143696fec5e910 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Tue, 23 Sep 2025 14:32:55 -0500 Subject: [PATCH 263/278] Podcast: add 372 recap --- .../en/newsletters/2025-09-19-newsletter.md | 30 +++++++++---------- .../en/podcast/2025-09-23-newsletter-recap.md | 23 ++++++++++++++ 2 files changed, 38 insertions(+), 15 deletions(-) create mode 100644 _posts/en/podcast/2025-09-23-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-09-19-newsletter.md b/_posts/en/newsletters/2025-09-19-newsletter.md index 10fc429085..b4f56b68d0 100644 --- a/_posts/en/newsletters/2025-09-19-newsletter.md +++ b/_posts/en/newsletters/2025-09-19-newsletter.md @@ -45,7 +45,7 @@ popular Bitcoin infrastructure software. Downsides of the new proposal are that Alice loses some privacy to her LSPs and that the proposal requires several changes to the LN protocol - in addition to support for redundant overpayments. + in addition to support for redundant overpayments. {% assign timestamp="16:24" %} - **Partitioning and eclipse attacks using BGP interception:** developer cedarctic [posted][cedarctic bgp] to Delving Bitcoin about using flaws @@ -54,7 +54,7 @@ popular Bitcoin infrastructure software. or execute [eclipse attacks][topic eclipse attacks]. Several mitigations were described by cedarctic, with other developers in the discussion describing other mitigations and ways to monitor for use of - the attack. + the attack. {% assign timestamp="1:02" %} ## Changes to services and client software @@ -63,12 +63,12 @@ wallets and services.* - **Zero-knowledge proof of reserve tool:** [Zkpoor][zkpoor github] generates [proof of reserves][topic proof of reserves] - using STARK proofs without revealing the owner's addresses or UTXOs. + using STARK proofs without revealing the owner's addresses or UTXOs. {% assign timestamp="13:49" %} - **Alternative submarine swap protocol proof of concept:** The [Papa Swap][papa swap github] protocol proof of concept achieves [submarine swap][topic submarine swaps] functionality by requiring one - transaction instead of two. + transaction instead of two. {% assign timestamp="15:12" %} ## Releases and release candidates @@ -77,12 +77,12 @@ projects. Please consider upgrading to new releases or helping to test release candidates._ - [Bitcoin Core 30.0rc1][] is a release candidate for the next major - version of this full verification node software. + version of this full verification node software. {% assign timestamp="39:14" %} - [BDK Chain 0.23.2][] is a release of this library for building wallet applications that introduces improvements to transaction conflict handling, redesigns the `FilterIter` API to enhance [BIP158][] filtering capabilities, - and improves anchor and block reorg management. + and improves anchor and block reorg management. {% assign timestamp="1:16:28" %} ## Notable code and documentation changes @@ -100,44 +100,44 @@ repo], and [BINANAs][binana repo]._ transaction's inputs exceeds zero sats. As long as a transaction spends at least one output from a wallet, it will be recognized as part of that wallet. This allows transactions with zero-value inputs, such as spending a [P2A ephemeral - anchor][topic ephemeral anchors], to appear in a user’s transaction list. + anchor][topic ephemeral anchors], to appear in a user’s transaction list. {% assign timestamp="1:17:19" %} - [Eclair #3157][] updates the way it signs and broadcasts remote commitment transactions upon reconnection. Instead of resending the previously signed commitment, it resigns with the latest nonces from `channel_reestablish`. Peers that do not use deterministic nonces in [simple taproot channels][topic simple taproot channels] will have a new nonce upon reconnection, rendering - the previous commitment signature invalid. + the previous commitment signature invalid. {% assign timestamp="1:18:56" %} - [LND #9975][] adds [P2TR][topic taproot] fallback on-chain address support to [BOLT11][] invoices, following the test vector added in [BOLTs #1276][]. BOLT11 invoices have an optional `f` field that allows users to include a - fallback on-chain address in case a payment cannot be completed over the LN. + fallback on-chain address in case a payment cannot be completed over the LN. {% assign timestamp="1:19:52" %} - [LND #9677][] adds the `ConfirmationsUntilActive` and `ConfirmationHeight` fields to the `PendingChannel` response message returned by the `PendingChannels` RPC command. These fields inform users of the number of confirmations required for channel activation and the block height - at which the funding transaction was confirmed. + at which the funding transaction was confirmed. {% assign timestamp="1:20:21" %} - [LDK #4045][] implements the reception of an [async payment][topic async payments] by an LSP node by accepting an incoming [HTLC][topic htlc] on behalf of an often-offline recipient, holding it, and releasing it to the recipient later when signaled. This PR introduces an experimental `HtlcHold` feature bit, adds a new `hold_htlc` flag on `UpdateAddHtlc`, and defines the release - path. + path. {% assign timestamp="1:20:41" %} - [LDK #4049][] implements the forwarding of [BOLT12][topic offers] invoice requests from an LSP node to an online recipient, who then replies with a fresh invoice. If the recipient is offline, the LSP node can reply with a fallback invoice, as enabled by the server-side logic implementation for - [async payments][topic async payments] (see Newsletter [#363][news363 async]). + [async payments][topic async payments] (see Newsletter [#363][news363 async]). {% assign timestamp="1:21:32" %} - [BDK #1582][] refactors the `CheckPoint`, `LocalChain`, `ChangeSet`, and `spk_client` types to be generic and take a `T` payload instead of being fixed to block hashes. This prepares `bdk_electrum` to store full block headers in checkpoints, which avoids header redownloads and enables cached merkle proofs - and Median Time Past (MTP). + and Median Time Past (MTP). {% assign timestamp="1:22:18" %} - [BDK #2000][] adds block reorg handling to a refactored `FilterIter` struct (see Newsletter [#339][news339 filters]). Rather than splitting its flow @@ -146,13 +146,13 @@ repo], and [BINANAs][binana repo]._ ensure that the block isn't stale and that BDK is on the valid chain. `FilterIter` scans all blocks and fetches those containing transactions relevant to a list of script pubkeys, using [compact block filters][topic - compact block filters] as specified in [BIP158][]. + compact block filters] as specified in [BIP158][]. {% assign timestamp="1:23:13" %} - [BDK #2028][] adds a `last_evicted` timestamp field to the `TxNode` struct to indicate when a transaction was excluded from the mempool after being replaced through [RBF][topic rbf]. This PR also removes the `TxGraph::get_last_evicted` method (See Newsletter [#346][news346 evicted]) because the new field replaces - it. + it. {% assign timestamp="1:24:17" %} {% include snippets/recap-ad.md when="2025-09-23 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-09-23-newsletter-recap.md b/_posts/en/podcast/2025-09-23-newsletter-recap.md new file mode 100644 index 0000000000..967ca080b3 --- /dev/null +++ b/_posts/en/podcast/2025-09-23-newsletter-recap.md @@ -0,0 +1,23 @@ +--- +title: 'Bitcoin Optech Newsletter #372 Recap Podcast' +permalink: /en/podcast/2025/09/23/ +reference: /en/newsletters/2025/09/19/ +name: 2025-09-23-recap +slug: 2025-09-23-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt are joined by ZmnSCPxj and Constantine Doumanidis to discuss [Newsletter #372]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-8-23/408017213-44100-2-7f963665feb36.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From 02d829f669504c993a8eab21f74db472ce0d0488 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Mon, 22 Sep 2025 08:40:32 -0500 Subject: [PATCH 264/278] Newsletters: add 373 (2025-09-26) --- .../en/newsletters/2025-09-26-newsletter.md | 56 +++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 _posts/en/newsletters/2025-09-26-newsletter.md diff --git a/_posts/en/newsletters/2025-09-26-newsletter.md b/_posts/en/newsletters/2025-09-26-newsletter.md new file mode 100644 index 0000000000..4f4a94c6ec --- /dev/null +++ b/_posts/en/newsletters/2025-09-26-newsletter.md @@ -0,0 +1,56 @@ +--- +title: 'Bitcoin Optech Newsletter #373' +permalink: /en/newsletters/2025/09/26/ +name: 2025-09-26-newsletter +slug: 2025-09-26-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter summarizes a vulnerability affecting old versions of +Eclair and summarizes research into full node feerate settings. Also included +are our regular sections summarizing popular questions and answers on the +Bitcoin Stack Exchange, announcing new releases and release candidates, and +describing notable changes to popular Bitcoin infrastructure software. + +## News + +FIXME:harding + +## Selected Q&A from Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] is one of the first places Optech +contributors look for answers to their questions---or when we have a +few spare moments to help curious or confused users. In +this monthly feature, we highlight some of the top-voted questions and +answers posted since our last update.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +FIXME:bitschmidty + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +FIXME:Gustavojfe + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +FIXME:Gustavojfe + +{% include snippets/recap-ad.md when="2025-09-30 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="" %} From 1262acd95dcc6cb196ec67305f11c645ca7ecbed Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Wed, 24 Sep 2025 15:01:42 -0500 Subject: [PATCH 265/278] News373: add news to harding section --- .../en/newsletters/2025-09-26-newsletter.md | 32 ++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2025-09-26-newsletter.md b/_posts/en/newsletters/2025-09-26-newsletter.md index 4f4a94c6ec..75289c81f3 100644 --- a/_posts/en/newsletters/2025-09-26-newsletter.md +++ b/_posts/en/newsletters/2025-09-26-newsletter.md @@ -15,7 +15,34 @@ describing notable changes to popular Bitcoin infrastructure software. ## News -FIXME:harding +- **Eclair vulnerability:** Matt Morehouse [posted][morehouse eclair] to + Delving Bitcoin to announce the [responsible disclosure][topic + responsible disclosures] of a vulnerability affecting older versions + of Eclair. All Eclair users are recommended to upgrade to version + 0.12 or greater. The vulnerability allowed an attacker to broadcast + an old commitment transaction to steal all current funds from a + channel. In addition to fixing the vulnerability, Eclair developers + added a comprehensive testing suite designed to catch similar problems. + +- **Research into feerate settings:** Daniela Brozzoni [posted][brozzoni + feefilter] to Delving Bitcoin the results of a scan of almost 30,000 + full nodes that were accepting incoming connections. Each node was + queried for its [BIP133][] fee filter, which indicates the lowest + feerate at which it will currently accept relayed unconfirmed + transactions. When node mempools aren't full, this is + the node's [default minimum transaction relay feerate][topic default + minimum transaction relay feerates]. Her results indicate most nodes + used the default of 1 sat/vbyte (s/v), which has long been the default + in Bitcoin Core. About 4% of nodes used 0.1 s/v, the default for the + upcoming 30.0 version of Bitcoin Core, and about 8% of nodes didn't + respond to the query---indicating that they might be spy nodes. + + A small percentage of the nodes used a feefilter value of 9,170,997 + (10,000 s/v), which developer 0xB10C [noted][0xb10c feefilter] is the + value Bitcoin Core sets, through rounding, when the node is more than + 100 blocks behind the tip of the chain and is focused on receiving + block data rather than transactions that might be confirmed in later + blocks. ## Selected Q&A from Bitcoin Stack Exchange @@ -54,3 +81,6 @@ FIXME:Gustavojfe {% include snippets/recap-ad.md when="2025-09-30 16:30" %} {% include references.md %} {% include linkers/issues.md v=2 issues="" %} +[morehouse eclair]: https://delvingbitcoin.org/t/disclosure-eclair-preimage-extraction-exploit/2010 +[brozzoni feefilter]: https://delvingbitcoin.org/t/measuring-minrelaytxfee-across-the-bitcoin-network/1989 +[0xb10c feefilter]: https://delvingbitcoin.org/t/measuring-minrelaytxfee-across-the-bitcoin-network/1989/3 From 71d41cbffe75012a014bb154310294769a5c786d Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 25 Sep 2025 07:07:43 +0000 Subject: [PATCH 266/278] News373: adds merge summaries --- .../en/newsletters/2025-09-26-newsletter.md | 74 ++++++++++++++++++- 1 file changed, 71 insertions(+), 3 deletions(-) diff --git a/_posts/en/newsletters/2025-09-26-newsletter.md b/_posts/en/newsletters/2025-09-26-newsletter.md index 75289c81f3..7877e63d5c 100644 --- a/_posts/en/newsletters/2025-09-26-newsletter.md +++ b/_posts/en/newsletters/2025-09-26-newsletter.md @@ -63,7 +63,9 @@ _New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates._ -FIXME:Gustavojfe +- [Bitcoin Core 30.0rc1][] is a release candidate for the next major version of + this full verification node software. Please see the [version 30 release + candidate testing guide][bcc30 testing]. ## Notable code and documentation changes @@ -76,11 +78,77 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -FIXME:Gustavojfe +- [Bitcoin Core #33333][] emits a startup warning message if a node's `dbcache` + setting exceeds a cap derived from the node's system RAM, to prevent + out-of-memory errors or heavy swapping. For systems with less than 2GB of RAM, + the `dbcache` warning threshold is 450MB; otherwise, the threshold is 75% of + the total RAM. The `dbcache` 16GB limit was removed in September 2024 (see + Newsletter [#321][news321 dbcache]). + +- [Bitcoin Core #28592][] increases the per-peer transaction relay rate from 7 + to 14 for inbound peers due to an increased presence of smaller transactions on + the network. The rate for outbound peers is 2.5 times higher, increasing to 35 + transactions per second. The transaction relay rate limits the number of + transactions a node sends to its peers. + +- [Eclair #3171][] removes `PaymentWeightRatios`, a pathfinding method that + assumed uniformity in channel balances, and replaces it with a newly + introduced probabilistic approach based on past payment attempt history (see + Newsletter [#371][news371 path]). + +- [Eclair #3175][] starts rejecting unpayable [BOLT12][] [offers][topic offers] + where the fields `offer_chains`, `offer_paths`, `invoice_paths`, and + `invoice_blindedpay` are present but empty. + +- [LDK #4064][] updates its signature verification logic to ensure that if the + `n` field (payee’s pubkey) is present, the signature is verified against it. + Otherwise, the payee’s pubkey is extracted from the [BOLT11][] invoice with + either a high-S or low-S signature. This PR aligns signature checks with the + proposed [BOLTs #1284][] and with other implementations such as Eclair (See + Newsletter [#371][news371 pubkey]). + +- [LDK #4067][] adds support for spending [P2A ephemeral anchor][topic + ephemeral anchors] outputs from [zero-fee commitment][topic v3 commitments] transactions, ensuring + that channel peers can claim their funds back on-chain. See Newsletter + [#371][news371 p2a] for LDK’s implementation of zero-fee commitment channels. + +- [LDK #4046][] enables an often-offline sender to send [async payments][topic + async payments] to an often-offline recipient. The sender sets a flag in the + `update_add_htlc` message to indicate that the [HTLC][topic htlc] should be + held by the LSP until the recipient comes back online and sends a + `release_held_htlc` [onion message][topic onion messages] to claim the + payment. + +- [LDK #4083][] deprecates the `pay_for_offer_from_human_readable_name` endpoint + to remove duplicate [BIP353][] HRN payment APIs. Wallets are encouraged to use + the `bitcoin-payment-instructions` crate to parse and resolve payment + instructions before calling `pay_for_offer_from_hrn` to pay an [offer][topic + offers] from a [BIP353][] HRN (e.g. satoshi@nakamoto.com). + +- [LND #10189][] updates its `sweeper` system (see Newsletter [#346][news346 + sweeper]) to properly recognize the `ErrMinRelayFeeNotMet` error code and + retry failed transactions by [fee bumping][topic rbf] until the broadcast is + successful. Previously, the error would be mismatched, and the transaction + wouldn't be retried. This PR also improves weight estimation by accounting for + a possible extra change output, which is relevant in [taproot][topic taproot] + overlay channels used to enhance LND’s [Taproot Assets][topic client-side + validation]. + +- [BIPs #1963][] updates the status of the BIPs that specify [compact block + filters][topic compact block filters], [BIP157][] and [BIP158][], from `Draft` + to `Final` as they’ve been deployed in Bitcoin Core and other software since + 2020. {% include snippets/recap-ad.md when="2025-09-30 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="" %} +{% include linkers/issues.md v=2 issues="33333,28592,3171,3175,4064,4067,4046,4083,10189,1963,1284" %} [morehouse eclair]: https://delvingbitcoin.org/t/disclosure-eclair-preimage-extraction-exploit/2010 [brozzoni feefilter]: https://delvingbitcoin.org/t/measuring-minrelaytxfee-across-the-bitcoin-network/1989 [0xb10c feefilter]: https://delvingbitcoin.org/t/measuring-minrelaytxfee-across-the-bitcoin-network/1989/3 +[bitcoin core 30.0rc1]: https://bitcoincore.org/bin/bitcoin-core-30.0/ +[bcc30 testing]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/30.0-Release-Candidate-Testing-Guide/ +[news321 dbcache]: /en/newsletters/2024/09/20/#bitcoin-core-28358 +[news371 path]: /en/newsletters/2025/09/12/#eclair-2308 +[news371 pubkey]: /en/newsletters/2025/09/12/#eclair-3163 +[news371 p2a]: /en/newsletters/2025/09/12/#ldk-4053 +[news346 sweeper]: /en/newsletters/2025/03/21/#discussion-of-lnd-s-dynamic-feerate-adjustment-system \ No newline at end of file From 8ccb5a6d4fd8976b7d5f4670f3c115f228085470 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 25 Sep 2025 12:53:34 -0500 Subject: [PATCH 267/278] News373: add stack exchange --- .../en/newsletters/2025-09-26-newsletter.md | 59 ++++++++++++++++++- 1 file changed, 57 insertions(+), 2 deletions(-) diff --git a/_posts/en/newsletters/2025-09-26-newsletter.md b/_posts/en/newsletters/2025-09-26-newsletter.md index 7877e63d5c..039f6684bd 100644 --- a/_posts/en/newsletters/2025-09-26-newsletter.md +++ b/_posts/en/newsletters/2025-09-26-newsletter.md @@ -55,7 +55,60 @@ answers posted since our last update.* {% comment %}{% endcomment %} {% assign bse = "https://bitcoin.stackexchange.com/a/" %} -FIXME:bitschmidty +- [Implications of OP_RETURN changes in upcoming Bitcoin Core version 30.0?]({{bse}}127895) + Pieter Wuille describes his perspectives on the effectiveness and drawbacks of + using [mempool and relay policy][policy series] to affect the contents of mined blocks. + +- [If OP_RETURN relay limits are ineffective, why remove the safeguard instead of keeping it as a default discouragement?]({{bse}}127904) + Antoine Poinsot explains the malincentive created by the current OP_RETURN + default limit value in Bitcoin Core and the rationale for removing it. + +- [What are the worst-case stress scenarios from uncapped OP_RETURNs in Bitcoin Core v30?]({{bse}}127914) + Vojtěch Strnad and Pieter Wuille respond to a list of extreme scenarios that + might occur with the OP_RETURN limit policy default setting changing. + +- [If OP_RETURN needed more room, why was the 80-byte cap removed instead of being raised to 160?]({{bse}}127915) + Ava Chow and Antoine Poinsot outline considerations against a 160-byte default + OP_RETURN value including an aversion to continually setting the cap, existing + large miners already bypassing the cap, and risks of not anticipating future + on-chain activity. + +- [If arbitrary data is inevitable, does removing OP_RETURN limits shift demand toward more harmful storage methods (like UTXO-inflating addresses)?]({{bse}}127916) + Ava Chow points out that dropping the OP_RETURN limit provides incentives + to use a less harmful alternative for output data storage in certain situations. + +- [If OP_RETURN uncapping doesn’t increase the UTXO set, how does it still contribute to blockchain bloat and centralization pressure?]({{bse}}127912) + Ava Chow explains how increased use of OP_RETURN outputs affects the resource + utilization of Bitcoin nodes. + +- [How does uncapping OP_RETURN impact long-term fee-market quality and security budget?]({{bse}}127906) + Ava Chow answers a series of questions about hypothetical OP_RETURN usage and + its impact on future Bitcoin mining revenues. + +- [Assurance blockchain will not suffer from illegal content with 100KB OP_RETURN?]({{bse}}127958) + User jb55 provides several examples of potential encoding schemes for data + concluding "So no, in general you can't really stop these kinds of things in a + censorship resistant, decentralized network." + +- [What analysis shows OP_RETURN uncapping won’t harm block propagation or orphan risk?]({{bse}}127905) + Ava Chow points out that while there is no dataset specifically isolating + large OP_RETURNs, previous analyses of [compact blocks][topic compact block + relay] and stale blocks indicate there is no reason to expect them to behave + differently. + +- [Where does Bitcoin Core keep the XOR obfuscation keys for both block data files and level DB indexes?]({{bse}}127927) + Vojtěch Strnad notes the chainstate key is stored in LevelDB under the + "\000obfuscate_key" key and the block and undo data key is stored in the blocks/xor.dat file. + +- [How robust is 1p1c transaction relay in bitcoin core 28.0?]({{bse}}127873) + Glozow clarifies that the non-robustness referred to in the original + opportunistic [one parent one child (1P1C) relay][28.0 1p1c] pull request means "not + guaranteed to work, particularly in the presence of adversaries or when volume + is really high so we miss things." + +- [How can I allow getblocktemplate to include sub 1 sat/vbyte transactions?]({{bse}}127881) + User inersha discovers the settings required to not only relay sub 1 sat/vbyte + transactions but also have them included in a candidate block template. ## Releases and release candidates @@ -151,4 +204,6 @@ repo], and [BINANAs][binana repo]._ [news371 path]: /en/newsletters/2025/09/12/#eclair-2308 [news371 pubkey]: /en/newsletters/2025/09/12/#eclair-3163 [news371 p2a]: /en/newsletters/2025/09/12/#ldk-4053 -[news346 sweeper]: /en/newsletters/2025/03/21/#discussion-of-lnd-s-dynamic-feerate-adjustment-system \ No newline at end of file +[news346 sweeper]: /en/newsletters/2025/03/21/#discussion-of-lnd-s-dynamic-feerate-adjustment-system +[policy series]: /en/blog/waiting-for-confirmation/ +[28.0 1p1c]: /en/bitcoin-core-28-wallet-integration-guide/#one-parent-one-child-1p1c-relay From 15ce606e9862ef6a865ba39101f64e9302bff24e Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 26 Sep 2025 19:46:34 +0900 Subject: [PATCH 268/278] Newsletter-373:Translate into Japanese --- .../ja/newsletters/2025-09-26-newsletter.md | 181 ++++++++++++++++++ 1 file changed, 181 insertions(+) create mode 100644 _posts/ja/newsletters/2025-09-26-newsletter.md diff --git a/_posts/ja/newsletters/2025-09-26-newsletter.md b/_posts/ja/newsletters/2025-09-26-newsletter.md new file mode 100644 index 0000000000..da19286f15 --- /dev/null +++ b/_posts/ja/newsletters/2025-09-26-newsletter.md @@ -0,0 +1,181 @@ +--- +title: 'Bitcoin Optech Newsletter #373' +permalink: /ja/newsletters/2025/09/26/ +name: 2025-09-26-newsletter-ja +slug: 2025-09-26-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、Eclairの旧バージョンに影響を与える脆弱性と、 +フルノードの手数料率設定に関する調査結果に関するまとめを掲載しています。 +また、Bitcoin Stack Exchangeで人気の質問とその回答や、新しいリリースとリリース候補の発表、 +人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき更新など、恒例のセクションも含まれています。 + +## ニュース + +- **Eclairの脆弱性:** Matt Morehouseは、Eclairの旧バージョンに影響する脆弱性の + [責任ある開示][topic responsible disclosures]をDelving Bitcoinで[発表しました][morehouse eclair]。 + すべてのEclairユーザーは、バージョン0.12以降へのアップグレードが推奨されます。 + この脆弱性により、攻撃者は古いコミットメントトランザクションをブロードキャストすることで、 + チャネルから現在の資金をすべて盗むことができました。この脆弱性の修正に加えて、 + Eclairの開発者は、同様の問題を検出するための包括的なテストスイートを追加しました。 + +- **手数料率設定の調査:** + Daniela Brozzoniは、着信接続を受け付けている約3万台のフルノードをスキャンした結果を + Delving Bitcoinに[投稿しました][brozzoni feefilter]。各ノードに対して、 + [BIP133][]のfeefilterをクエリし、リレーされる未承認トランザクションを受け入れる現在の最低手数料率を取得します。 + ノードのmempoolがいっぱいになっていない場合、これはノードの + [デフォルト最小トランザクションリレー手数料率][topic default minimum transaction relay feerates]です。 + 彼女の調査結果によると、ほとんどのノードは、Bitcoin Coreで長年デフォルトとなっている + 1 sat/vbyte (s/v)というデフォルト値を使っていました。約4%のノードが、 + Bitcoin Coreの次期バージョン30.0のデフォルト値である0.1 s/vを使っていました。 + また、約8%のノードはクエリに応答しませんでした。これらは、スパイノードである可能性があります。 + + 少数のノードが9,170,997（10,000 s/v）という、feefilter値を使用していましたが、 + 開発者の0xB10Cに[よると][0xb10c feefilter]、これはノードがチェーンの先端から100ブロック以上遅れており、 + 後のブロックで承認される可能性のあるトランザクションよりも、ブロックデータの受信にフォーカスしている場合に、 + Bitcoin Coreの内部処理によって設定される値です。 + +## Bitcoin Stack Exchangeから選ばれたQ&A + +*[Bitcoin Stack Exchange][bitcoin.se]はOptech Contributor達が疑問に対して答えを探しに（もしくは他のユーザーの質問に答える時間がある場合に）アクセスする、 +数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Bitcoin Coreバージョン30.0におけるOP_RETURNの変更の影響は？]({{bse}}127895) + Pieter Wuilleは、マイニングされるブロックの内容に影響を与えるために + [mempoolとリレーポリシー][policy series]を使用することの有効性と欠点について、彼の見解を説明しています。 + +- [OP_RETURNリレー制限が効果的でないなら、なぜデフォルトの抑止策として残すのではなく、安全策を削除するのでしょうか？]({{bse}}127904) + Antoine Poinsotは、Bitcoin Coreにおける現在のOP_RETURNのデフォルト制限値によって生じる悪影響と、 + それを削除した理由について説明しています。 + +- [Bitcoin Core v30でOP_RETURNの上限が設定されていない場合、最悪のストレスシナリオとはどのようなものですか？]({{bse}}127914) + Vojtěch StrnadとPieter Wuilleは、OP_RETURN制限ポリシーのデフォルト設定の変更によって発生する可能性のある + 一連の極端なシナリオを回答しています。 + +- [OP_RETURNがより多くの容量を必要とするなら、なぜ80 byteの上限を160 byteに引き上げるのではなく削除したのですか？]({{bse}}127915) + Ava ChowとAntoine Poinsotは、OP_RETURNのデフォルト値を160 byteにした場合の考慮事項を概説しています。 + 具体的には、上限を継続的に設定し続けることへの抵抗、既に上限を回避している大規模マイナーの存在、 + 将来のオンチェーン活動を予測できないリスクなどが含まれます。 + +- [任意のデータが避けられないなら、OP_RETURN制限の削除は需要をより有害な保存方法（UTXOを膨張させるアドレスなど）にシフトさせるのでは？]({{bse}}127916) + Ava Chowは、OP_RETURN制限を撤廃することで、特定の状況において、 + アウトプットデータの保存により害の少ない代替手段を使用するインセンティブを与えると指摘しています。 + +- [OP_RETURNの上限解除によってUTXOセットが増加しない場合、ブロックチェーンの肥大化と中央集権化の圧力にどのような影響を与えますか？]({{bse}}127912) + Ava Chowは、OP_RETURNの使用の増加がBitcoinノードのリソース利用にどのように影響するかを説明しています。 + +- [OP_RETURNの上限解除は、長期的な手数料市場の品質とセキュリティ予算にどのような影響を与えますか？]({{bse}}127906) + Ava Chowは、OP_RETURNの仮定的な使用と将来のBitcoinマイニング収益への影響について、 + 一連の質問に回答しています。 + +- [100KBのOP_RETURNでブロックチェーンが違法コンテンツに悩まされないという保証はありますか？]({{bse}}127958) + ユーザーjb55は、データのエンコード方式の例をいくつか挙げ、「つまり、 + 検閲耐性のある分散型ネットワークでは、一般的にこのような行為を実際に阻止することはできない」と結論づけています。 + +- [OP_RETURNの上限撤廃がブロックの伝播やオーファンリスクに悪影響を与えないことを示す分析はありますか？]({{bse}}127905) + Ava Chowは、大きなOP_RETURNを具体的に分離したデータセットは存在しないものの、 + [コンパクトブロック][topic compact block relay]とステイルブロックに関する過去の分析では、 + それらが異なる動作をすると予想する理由はないと指摘しています。 + +- [Bitcoin Coreは、ブロックデータファイルとLevelDBインデックスの両方のXOR難読化鍵をどこに保管していますか？]({{bse}}127927) + Vojtěch Strnadは、chainstateの鍵はLevelDB内の"\000obfuscate_key"キーの下に保管され、 + ブロックとundoデータの鍵は、blocks/xor.datファイルに保管されていると述べています。 + +- [Bitcoin Core 28.0における1P1Cトランザクションリレーはどの程度堅牢ですか？]({{bse}}127873) + Glozowは、オリジナルの楽観的な[1P1C（one parent one child）リレー][28.0 1p1c]のプルリクエストで言及されている非堅牢性は、 + 「特に敵対者が存在する場合や、トランザクション量が非常に多いために見逃してしまうような場合には、 + 動作が保証されない」という意味だと明確に述べています。 + +- [getblocktemplateで1 sat/vbyte未満のトランザクションを含めるためにはどうすればいいですか？]({{bse}}127881) + ユーザーinershaは、1 sat/vbyte未満のトランザクションをリレーするだけでなく、 + 候補ブロックテンプレートに含めるために必要な設定を発見しました。 + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [Bitcoin Core 30.0rc1][]は、この完全な検証ノードソフトウェアの次期メジャーバージョンのリリース候補です。 + [バージョン30リリース候補のテストガイド][bcc30 testing]をご覧ください。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Bitcoin Core #33333][]は、ノードの`dbcache`設定がノードのシステムRAMから算出された上限を超えた場合、 + メモリ不足エラーや過剰なスワップを防止するために、起動時に警告メッセージを出力します。 + RAMが2GB未満のシステムの場合、`dbcache`警告の閾値は450MBです。それ以外の場合、 + 閾値はRAMの総容量の75%です。`dbcache`の16GB制限は、2024年9月に撤廃されました（ニュースレター[#321][news321 dbcache]参照）。 + +- [Bitcoin Core #28592][]は、ネットワーク上で小さなトランザクションが増加したことに伴い、 + インバウンドピアのピア毎のトランザクションリレーレートを7から14に増やしました。 + アウトバウンドピアのレートは、2.5倍の1秒あたり35トランザクションになりました。 + トランザクションリレーのレート制限は、ノードがピアに送信するトランザクション数を制限します。 + +- [Eclair #3171][]は、チャネル残高の均一性を前提とする経路探索手法である`PaymentWeightRatios`を削除し、 + 過去の支払いの試行履歴に基づく新たに導入した確率的アプローチ（ニュースレター[#371][news371 path]参照）に置き換えます。 + +- [Eclair #3175][]は、`offer_chains`、`offer_paths`、`invoice_paths`および + `invoice_blindedpay`の各フィールドが存在するものの空の場合、 + 支払い不可能な[BOLT12][][オファー][topic offers]を拒否するようになりました。 + +- [LDK #4064][]は、署名検証ロジックを更新し、`n`フィールド（受取人の公開鍵）が存在する場合は、 + 署名がそのフィールドに対して検証されるようにします。そうでない場合は、 + 受取人の公開鍵は、high-Sまたはlow-S署名を持つ[BOLT11][]インボイスから抽出されます。 + このPRは、署名チェックを[BOLTs #1284][]やEclair（ニュースレター[#371][news371 pubkey]参照）などの他の実装と合わせます。 + +- [LDK #4067][]は、[手数料ゼロのコミットメントトランザクション][topic v3 commitments]の + [P2Aエフェメラルアンカー][topic ephemeral anchors]アウトプットの使用をサポートし、 + チャネルピアがオンチェーンで資金の返還を請求できるようにします。 + ゼロ手数料コミットメントチャネルのLDKの実装については、ニュースレター[#371][news371 p2a]をご覧ください。 + +- [LDK #4046][]は、頻繁にオフラインになる送信者が、頻繁にオフラインになる受信者に + [非同期支払い][topic async payments]を送信できるようにします。送信者は、 + 受信者がオンラインに戻り、支払いを請求するための`release_held_htlc` + [オニオンメッセージ][topic onion messages]を送信するまで、 + LSPが[HTLC][topic htlc]を保持することを示すフラグを`update_add_htlc`メッセージにセットします。 + +- [LDK #4083][]は、重複する[BIP353][] HRN支払いAPIを削除するため、 + `pay_for_offer_from_human_readable_name`を非推奨にします。 + ウォレットは、[BIP353][] HRN（例：satoshi@nakamoto.com）からの[オファー][topic + offers]に支払うために、`pay_for_offer_from_hrn`を呼び出す前に、 + `bitcoin-payment-instructions`クレートを使用して支払い指示をパースし解決することが推奨されます。 + +- [LND #10189][]は、`sweeper`システムを更新し（ニュースレター[#346][news346 sweeper]参照）、 + `ErrMinRelayFeeNotMet`エラーコードを正しく認識し、ブロードキャストが成功するまで[手数料を引き上げる][topic rbf]ことで、 + ブロードキャストに失敗したトランザクションを再試行します。これまでは、 + エラーが一致せず、トランザクションは再試行されませんでした。 + このPRには、LNDの[Taproot Assets][topic client-side validation]を強化するために使用される + [Taproot][topic taproot]オーバーレイチャネルに関連する、追加のお釣りアウトプットを考慮することで、 + ウェイトの推定も改善します。 + +- [BIPs #1963][]は、[コンパクトブロックフィルター][topic compact block filters]を定義する + BIP（[BIP157][]および[BIP158][]）のステータスを、`Draft`から`Final`に更新します。 + これは2020年以降、Bitcoin Coreおよびその他のソフトウェアで展開されたことを受けたものです。 + +{% include snippets/recap-ad.md when="2025-09-30 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="33333,28592,3171,3175,4064,4067,4046,4083,10189,1963,1284" %} +[morehouse eclair]: https://delvingbitcoin.org/t/disclosure-eclair-preimage-extraction-exploit/2010 +[brozzoni feefilter]: https://delvingbitcoin.org/t/measuring-minrelaytxfee-across-the-bitcoin-network/1989 +[0xb10c feefilter]: https://delvingbitcoin.org/t/measuring-minrelaytxfee-across-the-bitcoin-network/1989/3 +[bitcoin core 30.0rc1]: https://bitcoincore.org/bin/bitcoin-core-30.0/ +[bcc30 testing]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/30.0-Release-Candidate-Testing-Guide/ +[news321 dbcache]: /ja/newsletters/2024/09/20/#bitcoin-core-28358 +[news371 path]: /ja/newsletters/2025/09/12/#eclair-2308 +[news371 pubkey]: /ja/newsletters/2025/09/12/#eclair-3163 +[news371 p2a]: /ja/newsletters/2025/09/12/#ldk-4053 +[news346 sweeper]: /ja/newsletters/2025/03/21/#lnd +[policy series]: /ja/blog/waiting-for-confirmation/ +[28.0 1p1c]: /ja/bitcoin-core-28-wallet-integration-guide/#1p1cone-parent-one-childリレー From fd8f813bbf4edd18933879a886e9bda572f3c70c Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Mon, 29 Sep 2025 12:29:42 -0500 Subject: [PATCH 269/278] Podcast: add 372 transcription --- .../en/podcast/2025-09-23-newsletter-recap.md | 1144 ++++++++++++++++- 1 file changed, 1143 insertions(+), 1 deletion(-) diff --git a/_posts/en/podcast/2025-09-23-newsletter-recap.md b/_posts/en/podcast/2025-09-23-newsletter-recap.md index 967ca080b3..b790452d1c 100644 --- a/_posts/en/podcast/2025-09-23-newsletter-recap.md +++ b/_posts/en/podcast/2025-09-23-newsletter-recap.md @@ -18,6 +18,1148 @@ Mark “Murch” Erhardt and Mike Schmidt are joined by ZmnSCPxj and Constantine ## Transcription -_transcription coming soon_ +**Mike Schmidt**: Welcome to Optech #372 Recap. Today, we're going to be +talking about LSP-funded redundant overpayments; we have a potential eclipse +attack that cedarctic is going to talk to us about; we have a couple of changes +to Clients and service software, including some zero-knowledge proof of reserves +and a submarine swap tool; and then, we have a couple of Releases that we'll get +into including the RC for Bitcoin Core v30 that Murch is going to run us +through. This week, Murch and I are joined by two folks, one who is here now, +one who can introduce themselves in a minute. Cedarctic, you want to introduce +yourself to the group? + +**Constantine Doumanidis:** Yeah, sure thing. Thank you for having me on. So, +my name is Constantine Doumanidis, I'm a security researcher with the NetΣyn Lab +at Princeton University. I spent the summer looking into the BGP attack that +Mike alluded to earlier. Yeah, happy to chat all about it. + +_Partitioning and eclipse attacks using BGP interception_ + +**Mike Schmidt**: Awesome. Thanks for joining us. We're going to go a little +bit out of order until we get ZmnSCPxj for the first news item. So, we'll jump +to the second news item. Cedarctic, you authored a Delving post titled, +"Eclipsing Bitcoin Nodes with BGP Interception Attacks". In that post, you +outlined how an attacker could potentially eclipse Bitcoin nodes. What did you +find? + +**Constantine Doumanidis:** Yeah, so this is a particularly insidious attack. +It's quite targeted. What we found out was that it is quite possible to eclipse +a single Bitcoin node that you target using BGP hijacks. Previously, so just as +a bit of a quick background to what a BGP hijack does, is that it allows an +attacker to redirect traffic from one source to another destination, usually to +a specific destination, and route it through their own autonomous system, +through their own network, and then either forward it or keep it for themselves +and manipulate the connections this way. Previously, BGP hijack attacks have +been used to partition Bitcoin, essentially just split the network in two, maybe +have two competing chains and also achieve other attacks, but they were not +really considered for eclipsing a Bitcoin node, because they're a very noisy +attack, it's something that can be observed by network monitors. However, +recently researchers have figured out that there are ways to kind of make this +attack more stealthy and more targeted. And these kind of BGP hijacks are known +as interception attacks. And over the summer, I looked into how you can +potentially use these interception attacks in order to target a specific Bitcoin +node while also remaining stealthy. + +What I found was that this can be successfully done for quite a few Bitcoin +nodes. In particular, if I recall correctly from what I also wrote in the post, +around 42% of the IP prefixes that public-facing Bitcoin nodes currently exist +under are vulnerable to this. So, regardless of where the attacker is in the +network, the attack can't succeed this way. And also, even for the rest of +these prefixes, like the other 59%, these are not necessarily safe, because if +an attacker can position themselves favorably in the network, they can also +succeed in performing this attack. So, essentially, once I as an attacker, for +instance, start this attack, I iteratively slowly go through all Bitcoin node +addresses, hijacking their prefixes, and eventually just settle on the prefixes +of the connections that a node has. And then, at will, I can intercept all of +this traffic and either cut it or delay it, and kind of manipulate network +traffic that way. + +**Mark Erhardt**: Let's briefly take a step back and look at BGP. So, the +Border Gateway Protocol, you use this protocol to announce that you want to get +traffic for a certain IP address area, like an autonomous system, right? So, +what does it mean to go over all the nodes and redirect them? So, you're +basically saying, "Hey, if you have traffic for this IP, route it for me", or am +I understanding that right? + +**Constantine Doumanidis**: That is a good question, yes. So, you're right. +The BGP protocol, what it does is, it's the protocol that routers use to say +that, "Hey, I have this IP address and if anybody sends traffic to that IP +address, send it over to me". So, let's say that, Murch, you're hosting a node +under Comcast. Comcast would advertise your IP prefix so that when I want to +contact you, that traffic goes to you. Now, the issue with BGP is that BGP, on +its inception, was unauthenticated. So if, let's say, that I started announcing +the prefix for your IP, then other people might send the traffic that was +intended for you, they might send it over to me. That is the basics of a BGP +hijack. There have been security measures that have tried to compliment this +and fix these security holes, but these can still be exploited as outlined in +the Delving post. + +**Mark Erhardt**: Thanks. I'm not sure everybody has that background on BGP. +Okay, let's jump back in. So, this attacker would stealthily redirect traffic +through themselves, and then at a later time, they could start intercepting +traffic for a specific node. If all the traffic goes through you, basically +independently can decide to eclipse a node by just removing the messages that +you don't want to send. What are the mitigations that you found? + +**Constantine Doumanidis:** So, over the summer we looked into a few mitigations +that are also sketched out in the post. So, one of them, the first, is to +actually rotate your peers, because as people who are familiar with Bitcoin's +P2P stack might know, is that once a node settles on a set of connections, +there's no reason for these connections to change, unless for some reason a node +goes offline. What the attacker does in this attack is that they iterate +through these IP prefixes, because they don't essentially know who your peers +are. So, they have to do this process to figure out who your peers are and then +intercept them. Once they've intercepted them, they're good to go, you're +essentially eclipsed. But it's very costly for the attacker to continuously be +doing this operation of going through all prefixes and hijacking them one by +one. It's a very high-noise operation, which will eventually get them spotted. +So, by rotating your peers, you kind of prevent the attacker from settling on a +set of prefixes and being comfortable that they're capable of eclipsing you. +So, you have to keep them guessing, quite literally, and that's expensive for +them and high risk for them. So, peer rotation could be an effective +countermeasure. + +On the other hand, as also discussed by, I think Fabian brought it up in the +Delving forum, was that by doing this, you are potentially opening yourself up +to the classic eclipse attack, where you might be sampling your node table and +eventually settle on peers that are controlled by the adversary. So, it's again +a bit of a trade-off. + +**Mark Erhardt**: Right. I would imagine that it would also help to be active +on multiple networks. So, this attack would probably be in the clearnet on IPv4 +or IPv6. But if you have both IPv4 and IPv6, or maybe even Tor connections +additionally, that should help, right? + +**Constantine Doumanidis:** Yes, most definitely. So, a very good mitigation is +to be active on multiple networks, ideally also have Tor or I2P peers. That +definitely makes the attack a bit harder. Also, I think G Maxwell brought this +up, that a very good solution is to also multi-home your node. So, if you have +two, let's say if you have a Comcast connection and also an AT&T connection, and +you have multiple physical networks that you can access, it's much harder for +the attacker to pin you down on both sides. So, you always have an unaffected +route to the internet. + +**Mark Erhardt**: Sure, common setup to have two internet connections at home! + +**Constantine Doumanidis:** Yeah, there's also other countermeasures, for +instance dynamically negotiating port numbers that will make it bit harder for +the attacker to know if they're actually intercepting Bitcoin traffic, +especially if you're using the encrypted v2 transport. There's also the idea +that you would want to prefer new peers that are under prefixes that are +protected by countermeasures, like ROA or RPKI, which essentially dictate who +can announce these prefixes. It's not a perfect system, but it definitely does +help your chances of not being eclipsed. And then, there's also other +countermeasures, like selecting peers that are very close to you physically, as +the attacker will have a harder time in competing with a legitimate route. And +finally, something that is a bit more abstract maybe, but also complements +perhaps the efforts from the ASMap project, is selecting your peers based off +routing diversity. So, let's say that you and I, Murch, have a path between our +two Bitcoin nodes, and I also have a very distinct path between myself and +Mike's node. It's favorable because the attacker will have to consolidate these +two connections onto a common path, which is then more easily spottable. + +**Mark Erhardt**: Yeah, that makes sense. You briefly mentioned v2 transport. +Wouldn't v2 transport generally make it harder for peers to spot who you're +talking to or what you're talking about at least? + +**Constantine Doumanidis:** For sure. Again, plug for the v2 transport, it +should be used by default wherever possible. V2 transport encrypts the +connection, so it definitely makes it harder to understand what data is being +transmitted. So, an attacker that intercepts v2 traffic cannot see that traffic +per se, they cannot read in clear text. However, so long as the attacker can +spot, let's say, the default Bitcoin port, they can kind of guess that this is +Bitcoin traffic. But again, it does make it much harder on the attacker's end. +This was also brought up by Fabian. I think it's a good thing to have. + +**Mark Erhardt**: And just to be clear, of course, the v2 transport is encrypted +but not authenticated. So, if the attacker watches the initial connection, they +can man-in-the-middle it. + +**Constantine Doumanidis:** Yes, that is true. I think Greg Maxwell brought up +that when we have countersign, that could also be solved potentially, since +we'll have a silent authentication, if you will, which will be great. + +**Mark Erhardt**: Sure, sure. The magically fabled countersign that we've been +all waiting for seven years or so. That would be lovely if that picked up speed +again. + +**Mike Schmidt**: Maybe just, we probably should have done this earlier, and +maybe you guys did and I missed it, but in terms of the outcome here being +eclipse attack, I think we've sort of thrown that out, but maybe just for +listeners, that's when your Bitcoin note is isolated from honest peers, and +you're really only connected to either one or more malicious peers that could +slow down propagation of blocks to you. If you're broadcasting transactions, +obviously they could just hold those. And obviously there's a whole slew. If +you're than running an LN node on top of that Bitcoin node, there's a whole +other class of things that can happen to you that are bad if you're not +connected to the honest P2P network. + +**Mark Erhardt**: Right, so an eclipse attack is basically the special case of a +sybil attack, sybil being a lot of duplicate nodes. Eclipse means all of your +peers are controlled by a malicious entity, and the malicious entity +specifically can lie to you by omission. They'll just not send you some of the +information, transactions or blocks, which can force you to either consider a +shorter chain that the attacker feeds you, or just not hear about unconfirmed +transactions or even confirmed transactions if they do not send you the latest +chain tip. + +**Mike Schmidt**: Cedarctic, I'm a little bit curious. You mentioned, I think, +that this work was done through Princeton and some of the research you've been +doing there. Can you talk a little bit about how formal or informal this sort +of Bitcoin research work is there? + +**Constantine Doumanidis**: Yeah, sure. So, work on Bitcoin in academic circles +like Princeton, and especially with regards to routing attack, is quite active. +Some of the papers that have come out of such research, I've already also linked +on Delving, and I'm also happy to chat about those a bit more. This work in +particular has been done in collaboration with Chaincode. I was working with +the amazing people over there over the summer. And potentially we're looking +into what further steps can be done, both in identifying any potential +vulnerabilities that can be exploited through routing attacks, and any similar +attack vectors on the network level to manipulate Bitcoin, and also looking into +solutions like, for instance, some of the countermeasures that I brought up, +like how do we evaluate them, how do we know that these cannot be gamed further, +and so on. So, it is a very interesting topic and there's definitely many +people working on it. + +**Mike Schmidt**: Thank you for taking the time and joining us today to explain +this research. You're welcome to stay on. We have other things we're going to +talk about, but obviously you're free to drop if you have other things you're +working on. + +_Zero-knowledge proof of reserve tool_ + +We're going to move to the Changes to services and client software in deference +to our hopeful second guest, which we'll reference back to the first news item. +But in the meantime, "Zero-knowledge proof of reserve tool". This is yet +another tool from Abdel from StarkWare, who's been doing a bunch of interesting +stuff recently. I think last month, we covered a few different things that he +worked on as proof of concept. This week, we cover zkpoor, which is +Zero-Knowledge Proof Of Outstanding Reserves. This is a tool that lets users +prove that they hold some quantity of Bitcoin. That's broadly known as proof of +reserves, "Hey, I have control over this pile of Bitcoin". But with this tool, +users can actually prove that they can control those bitcoins, some quantity of +bitcoins, without actually revealing the individual bitcoin addresses or +individual UTXOs, which is pretty cool obviously from a privacy perspective. + +This tool uses fancy STARK proof cryptography to do the proof of reserves, so +that's pretty interesting stuff there. I didn't dig into that, that's not my +forte, but there is a live demo website and also set of slides for listeners to +check out if you're interested in pursuing more. + +_Alternative submarine swap protocol proof of concept_ + +And our second and last ecosystem software highlight is, "Alternative submarine +swap protocol for --" it's a proof of concept in this case. And as a reminder, +submarine swap is this idea of swapping offchain or LN bitcoins for onchain +bitcoins in a sort of atomic way. They already exist, submarine swaps are out +there. They use HTLCs (Hash Time Locked Contracts) and they use two +transactions, but this Papa Swap proof of concept actually just uses one +transaction. So, you can imagine that saves on speed, it's a little bit faster, +saves on fees. It also uses taproot. I think maybe some of the other protocols +use just segwit v0, so it could save on fees even more that way. I would stress +that this is a proof of concept. So, if you're an engineer kind of person or +someone who likes to tinker, take a look at it. If you're someone looking to +actively do these swaps in large quantities, this is a proof of concept. I +think there're still being discussions about it. So, please proceed as if it is +a proof of concept. Excellent. + +**Mark Erhardt**: So, it sounds like ZmnSCPxj is here now. + +**Mike Schmidt**: Great, thanks Murch. Okay, we're going to jump back up to the +News section. First, ZmnSCPxj, why don't you introduce yourself and then I'll +introduce this news item and you can take it from there? + +**ZmnSCPxj**: Hi, I'm ZmnSCPxj, I'm just some random guy from the internet. +Actually, I am an indie game dev developer who got suckered into buying +bitcoins. And apparently, thinking about how to exploit game rules maps very +well to thinking about how to exploit protocols. + +**Mike Schmidt**: I actually didn't know that you were previously a game +developer, so that's a new piece of information for me. + +**ZmnSCPxj**: No, I'm just a wannabe indie game dev. I haven't even released +anything, man, come on. + +_LSP-funded redundant overpayments_ + +**Mike Schmidt**: Lightning is a big game in itself. Well, the news item is, +"LSP-funded redundant overpayments", that's what we titled it in the newsletter +this week. ZmnSCPxj, you posted to Delving. The post was actually titled, +"MultiChannel and MultiPTLC: Towards a Global High-Availability +Consistent/Partition-Tolerant Database for Bitcoin Payments". That is very much +a ZmnSCPxj-titled post. I wrote a little elevator pitch, I wasn't sure if you +were going to be joining us, but why don't you give the high-level one, what is +being achieved here, and then we can get into the how? + +**ZmnSCPxj**: Okay, let's say you're an ordinary LN user. You have an LN wallet +and that LN wallet connects to one LSP. The LSP goes down. How are you going +to receive payments? How are you going to send payments? So, maybe you can use +a more sophisticated wallet, one that allows you to have multiple channels to +different LSPs. But now, you have an issue here that your funds are split up +into smaller pieces, which is supposed to be fixed by multipath payments, but +nobody has a decent multipath implementation. Maybe CLN (Core Lightning), but +it's probably over-engineered and probably doesn't do what you want anyway. And +that's multiple channels, that's multiple UTXOs that you're keeping in the UTXO +set. It's not ideal, right? + +**Mark Erhardt**: Yeah, my understanding is that when you try to settle payments +through multipath, of course you get many smaller payments, which are easier to +route through all the channels. But of course, you have way more things that +all need to work, so some of them will fail. And I think that's where your +stuff comes in, right? + +**ZmnSCPxj**: Well, that's one of the things, yes, of course. So, the insight +here is that basically I was looking into YugabyteDB, which is a +high-availability, consistent-partition-tolerant database. And then, I realized +that there's a common trend among these high-availability CP databases, which is +basically that all of them tell you, you need to have at least three nodes in +this database. And that's when I realized that what you actually do with the +current LN Poon-Dryja thing is that you actually have a synchronous replication +scheme, where you are the master of the transaction that is on the other side, +the unilateral closed transaction of your counterparty. So, you're the master +of that and then you replicate it there. And then they say, "Okay, I've got it +on my end. I want you to replicate it on your copy, on your side". So, that's +a synchronous replication thing. But the synchronous replication thing, there's +a master, there's a slave. If one of them goes down, the other can't continue, +and that's also part of the signing thing on the backing channel. It's a +2-of-2; any changes to the channel need both of them to be live. And that's +part of the issue of why it's a CP database. It's +consistent-partition-tolerant, but it's not high availability. + +So, that's just one problem in that the thing is, this channel is a local +entity. It's between you and your counterparty. Now, how we are able to +leverage this basic, consistent-partition-tolerant database into a global one is +to create HTLCs. And those HTLCs are basically row-level locks on an amount of +coin. And they have a condition where you can roll it back, which is basically +failing this payment; or you can commit it, and that commit is conditional on +receiving a preimage from your counterparty. So, it's already a row-level lock +on some amount of coin. And then, because we have multiple row-level locks on +different local databases, we are able to then achieve this consistency and +partition-tolerance across the globe, into the global space, not just local CP. +We have global CP, right? + +So, that's how I started thinking about it. And then I realized that again, if +there is, for example, this chain of locks that you are doing, this payment that +is ongoing, and then one of the nodes along the way has to drop, shuts down, it +falls, whatever, then the lock chain has to be kept until it goes back up or +until the timeouts trigger and people have to start unilaterally closing their +channels. And that's not good for the end user, because if you're sending and +then suddenly one of the nodes along the pack, you happen to have it sent out, +drops, then you have this stop payment that's going to be staying on your +channel for potentially up to two weeks. And that's again, another availability +issue. You want your funds to be available on that. + +So, those are two related issues that reduce the availability of LN in practice. +That's why we can say that it is a consistent-partition-tolerant database, and +you can even say that it's global in practice because of these HTLC locks, but +it's not high availability. There are times when you can't pay because your LSP +is down, because there's a vulnerability, there's a CVE somewhere and they have +to shut down and upgrade everything. Or maybe they just need to upgrade because +there's new tools, like what's new on LN anyway? Stuff on LN, new stuff, right? + +**Mark Erhardt**: Right, so setting up multipath payments, some nodes that are +on the routes could become unavailable… + +**ZmnSCPxj**: And that impedes also your ability to recover your funds. + +**Mark Erhardt**: Right, and it might get your funds stuck. So, I think you are +using stuckless payments and you're introducing redundancy somewhere. Do you +want to tell us about the redundancy? + +**ZmnSCPxj**: Okay, so I'm assuming that you know that stuckless is not actually +stuckless. It just happens to be the name of the protocol, but it's not +stockless. It does get stuck. It's just that it's okay to get stuck in +parallel, because in the current scheme we have with HTLCs, if the lock gets +stuck, it's not safe for you to send another payment. With stuckless, which is +stuckless by name only, it's safe for you, even if one payment is stuck, to send +out multiple parallel payments. And of course, you can still do that with any +scheme. But the problem still is that if one of those payments does get stuck, +the money that's in there is still locked up. So, stuckless is not truly +stuckless. It's more like parallel stuck is okay now. + +**Mark Erhardt**: Right, you can overpay and they can only collect as much as +you were intending to pay them. But if something is stuck along the way, the +payment goes through, you can even add more attempts to make more funds +available. You're not stuck in the sense that the payment process can proceed, +but your funds could still be stuck, or not all of them, just a portion +probably. + +**ZmnSCPxj**: Yeah. But basically, the issue still here is that there are still +some funds that get stopped and it's not a good UX, it's not a good user +experience. Like, okay, maybe you can lie in your user interface and say, +"Yeah, the payment went through", and you just silently hope that this stuck +payment gets returned before the user actually says, "I want to send all of my +funds to my cold storage", and now you're dead because you lied to them and you +didn't admit that you had some funds that were stuck. And now, they can't send +this out and they're going to have lots of big issues like, "Hey this wallet +says it's, blah blah blah, and it doesn't spend my money, blah blah blah", then +that's a big issue. + +Okay, so first, we have this base thing called multichannel, which allows a +single client to have a single construction that connects to multiple LSPs +simultaneously. And the only drawback here is that the LSPs need to kind of +trust a quorum of the LSPs, right? So, it's not the user that has to trust the +LSPs, it is the LSPs who have to trust each other. And the LSPs also don't have +to trust the user. Well, at least they don't have to trust the user for fund +safety. The user can still always do channel-jamming and that sort of attack on +those LSPs. But at least for fund safety, they can just force you to hold but +they can't make you lose money. So, it can be your channel jammed which forces +you to hold your funds, but it doesn't actually steal your money. + +**Mark Erhardt**: So, what do the LSPs trust each other for, because that sounds +like a bigger drawback? + +**ZmnSCPxj**: Okay, so the reason why they have to trust each other is because +they are signing using a k-of-n, so that even if some of them are down, the user +can still send out payments on the LSPs that are up, and they can still receive +payments via the LSPs that are still up. So, that's the reason why we have this +k-of-n reduction of the security of the LSPs. So, that's the first design I +showed there, was basically a sketch for a Poon-Dryja-based multichannel. And I +also sent over another link, which reduces the trust a little bit in the sense +that, okay, with the previous proposal, we have this k-of-n that protects the +funds, the liquidity, the inbound liquidity coming from the LSPs to the user. +And now, with this alternate construction, which is based on top of +Decker-Wattenhofer, we can reduce the trust so that the LSPs don't have to trust +the main inbound liquidity, but they do have to trust the funds that were +already sent by the user to them. + +So, the hope here is that this is a smaller trust issue, because the individual +payments are smaller in amount and we can time-box those so that periodically we +can clean up those issues, so that the funds are moved to the more secure scheme +where the LSP protects its own money without having to trust the k-of-n of the +other LSPs. So, that's a smaller trust requirement on the LSPs. + +**Mark Erhardt**: It sounds like a construction similar to the channel factories +would make this potentially completely safe if there were multiple virtual +channels between the user and the LSPs. And then, you could use and update just +any of them while one of the LSPs is down. Of course, we expect LSPs to +generally have better availability than, say, end user nodes on mobile phones. + +**ZmnSCPxj**: Yes, definitely. So, that's part of the design, is that the +assumption is that the LSPs have high uptime. However, if they find a +vulnerability in their software, they have to go down because they are putting a +lot of funds in a hot wallet that is permanently online. So, there will +definitely be times that they have to go down. So, the user is probably the +opposite, in that most of the time they are offline, and then when they actually +say, "Look, there's a shop that supports Lightning payments. I should go there +and buy stuff", that they need to be online and they have to do the payment +while they are online. So, our goal here is that we want to let the LSP to go +down, or at least one of them to go down or less than half of them to go down +simultaneously, so that the user can still send whenever the user needs it; and +also to allow the LSP to go down when they need it to protect their own money. + +**Mark Erhardt**: Right. So, it sounds like you're extending the idea of +stuckless payments, which you said is misnamed, but to make it so that you have +perfect availability for the end user by introducing a shared scheme for the +LSPs to sort of provide service as a conglomerate, or a quorum, rather than +individual LSPs. Do I get the drift right? + +**ZmnSCPxj**: Yes, that is an acceptable summary of the thing. + +**Mike Schmidt**: I have an even more pleb, maybe unacceptable summary. You +mentioned you are or were an aspiring game developer. I was a web developer in +my past life. And is it safe to say this is something like a load balancer for +LSPs, where instead of using one LSP that has these concerns that you outlined, +you sort of balance your usage between several LSPs, and that your protocol is +the thing that sort of -- + +**ZmnSCPxj**: I think it's more apt to say it's like automatic failover rather +than load balancing. + +**Mike Schmidt**: Okay, that makes sense. + +**ZmnSCPxj**: So, okay, so these are two parts. Like I said, I identified two +issues that cause low availability, and one is the local database, the channel +itself, which is two party. And because it's only two party, it can't do +updates if one of them is down. Because if you do updates, that would then +violate the CP, the consistency requirements. And as much as possible, we want +to have the consistency really nailed down because this is money, man, come on. +And the other part is that a remote node can go down while you have an HTLC +going out, and that's the second issue, that's the second availability issue. +So, the full solution requires both of these to be solved in practice. So, the +multichannel that I described is basically solving the local availability issue. +But now we have the global availability issue, and what I'm proposing is that +the LSPs should probe on the behalf of the user. + +Okay, so my initial proposal was to use a multi-PTLC (Point Time Locked +Contract). But actually, in practice, if you look at the custodians currently +running custodial wallets, what they do is that they send a probe payment out +and then they keep sending probe payments on behalf of their users in order to +have a path that they are kind of sure is working. And while it's true that +there is a TOCTOU there's a time-of-check versus time-of-update issue here, it +can be pretty small in practice, so that if 100 milliseconds ago this path +worked, it's very likely that it will still work now, right? + +**Mark Erhardt**: Yeah, and then generally LSPs will be participating in so many +more payments that they will generally have a pretty good latest state of the +network even before probing. So, they're just backfilling the little specific +path that they might want to use, and are already corroborating that with a lot +of other data they have. + +**ZmnSCPxj**: Yes. So, that's a thing. What we can actually do is to have the +LSPs send out HTLCs to the destination that the user expects. And we can do +this even if the user is not a custodial user, actually. We can just add this +service as an additional request from a non-custodial user to a big LSP node. +It's something that you can actually implement now, as opposed to my multi-PTLC +proposal, which requires not just PTLCs, but also a stuckless payments actual +protocol, and it requires specific things from that stuckless payments protocol. +Like, it requires that there is a nonce that the receiver shows in order to +request the receiver-can-claim scaler and to also be able to give an address or +a location on the network that is different from the actual sender in this case. +So, the multi-PTLC, you can probably say it's a bit over-engineered and a +practical solution is simply to have this HTLC probing be done by the LSPs on +behalf of the user. + +If you want, we can still discuss multi-PTLCs. It's an interesting bit. For +example, if the LSPs find multiple viable paths to the receiver, you can still +provide a multi-PTLC that also sends along all of those paths, and you just let +the LSPs compete on who gets to the receiver first, and that's something we can +also discuss. But basically, if you just want something that you can implement +reasonably soon, then what we probably should do is just this allowing the +client to ask the LSP, "Hey, can you probe this receiver for me?" Like, you can +even do source routing there by just giving them the onion and then they just +try to send it out. Though obviously, if they are giving them the onion, the +LSP can't get insights on how good the various paths are because they just have +the onion. But at least that gives privacy to the user, because it doesn't also +reveal to the LSP who the user is paying to. + +**Mark Erhardt**: Right, but then there's the general issue of how much an +intermittently-online node knows about the network, right? So, I think that LDK +had a synchronization mechanism to quickly get a download on some of the latest, +the rapid gossip sync. I am not sure how other LSP implementations would handle +this. So, I think most LSPs actually route for their clients, and then this +would mean zero privacy reduction compared to that. Of course, if the LSP +doesn't route for you, asking them to do a probe for you would not help. + +**ZmnSCPxj**: Well, you can always give them the onions to probe. You don't +actually need to give them the actual destination. It's just that if you give +them onions to probe, they don't really have any insights on which remote nodes, +they can't really give you that insight that, "Hey, that remote node isn't +really good". Just they don't know that they're going through that remote node +anyway. + +**Mark Erhardt**: Right. + +**Mike Schmidt**: Well, ZmnSCPxj, I think we covered this pretty well. It +sounds like there's other things that we could talk about perhaps in the future, +and maybe there'll be further posting on that on Delving. For folks that are +listening along and interested in this and want to go deeper, check out the +Delving post and the dialogue there. I'm sure ZmnSCPxj would welcome feedback +to the proposal as well. Anything else, ZmnSCPxj? + +**ZmnSCPxj**: Yeah, that's it. Anyway, I have to go soon. + +**Mike Schmidt**: All right, yeah, you're free to drop, but we'll move on with +the newsletter. Thank you for your time again. Cheers. + +**ZmnSCPxj**: Okay, bye. + +_Bitcoin Core 30.0rc1_ + +**Mike Schmidt**: Cheers.** **Moving to the Releases and release candidates +segment, this week it might be a little beefier than previous weeks. We are +going to do the Bitcoin Core v30.0rc1 deep dive. Master educator, Bitcoin Core +developer, Murch. Murch, we punted on it last week. It's time. What's in this +release? + +**Mark Erhardt**: Yeah, there's a bunch of stuff. So, generally, maybe we'll +talk a sentence or two about process in Bitcoin Core, as I think has been a +topic lately again. There is not actually a hierarchy in Bitcoin Core where +someone sets goals and assigns tasks or anything like that. Bitcoin Core is a +loosely-organized group of people that happen to be interested in contributing +to a shared project. Many people simply work on new things that they find +interesting, other people tend to work more on the things that they find +interesting and important. So, whatever makes it in before the feature freeze +is in a release. After the feature freeze, no new features get added to the +release branch. There's a branch-off and the release gets tested and bug fixes +get added to the release branch, if there's anything found on the features to be +released. And other than that, whatever is ready to go goes out in a release. +So, it's not like, "We'll ship this feature in the next version", and then +everybody works on it. No, the people decide what they work on. So, this is +just for context. + +Let's look a little bit at what is in the release. So, very notably, there are +a few policy changes. I don't know, I think we've covered most of them pretty +well already. There is the policy change that prepares for the great consensus +cleanup, which forbids legacy transactions that have more than 2,500 signature +operations, forbids in the sense that we will not admit them to our mempool. +They are still consensus-valid, but the great consensus cleanup is trying to +make them consensus-invalid. This is an odd construction that wouldn't usually +appear in transactions and is concerning, because you can use it to create +transactions that are very heavy to validate. I think we've talked plenty about +data carrier size. But just to recap, if people are not in the loop, the data +carrier size policy by default has been increased to 100,000 bytes, or will be +in the release. We're on, I think, RC2 now, right? + +**Mike Schmidt**: I think that may have been very recently, if it is. + +**Mark Erhardt**: Well, RC1 or 2. So, data carrier size regulates the size of +OP_RETURN outputs that a node will permit in its mempool. That was previously +limited to 83 bytes and is now limited to 100,000 bytes, which means that the +transaction size is the upper limit for OP_RETURNS. Do you want me to talk +about why that happened at all? + +**Mike Schmidt**: Yeah, give a headline. We don't need to go too deep if you +don't want to. + +**Mark Erhardt**: Well, as many people should be aware, there has been some data +transactions on the Bitcoin Network lately, and specifically the inscription +construction, which puts data in an unexecuted scriptpath. A leaf script in +taproot allows you to put 400,000 bytes. So, having 100,000 bytes in an +OP_RETURN is strictly less than that, and it's not attractive to use OP_RETURN +for data, because the inscription data is part of the witness stack and the +witness stack is discounted by segwit by a factor 4, whereas OP_RETURN outputs +are in the output data and output data is not discounted. So, for every byte +that you are trying to embed into a Bitcoin transaction, putting it into an +OP_RETURN output is 4x more expensive than putting it in the witness stack. +There's a little bit of an overhead with inscriptions, because you have to make +an output first that then gets spent where you reveal the data that you wanted +to embed in the input. So, it works out that at around, I think 160 bytes, +inscriptions become cheaper for data. + +So, it seemed there were some examples found in the wild. Both there's a +protocol where people are trying to create another colored-coin scheme with +OP_RETURNs and payment data outputs. And there was famously the Citrea example, +where they wanted to embed more than 80 bytes and they would put the first 80 +bytes in an OP_RETURN and then the rest of them in payment outputs. So, the +observation is putting data in payment outputs is the worst method out of the +three. And it is preferable, if people were going to put data in outputs, if +they just put it in OP_RETURN. OP_RETURNs are slightly cheaper than payment +outputs. Inscriptions are still cheaper for bigger data. So, it is unlikely +that people who are using inscriptions for data right now will move to +OP_RETURN, but people that would have instead stuffed them into payment outputs, +that live in the UTXO set forever, would be more likely to put them into +OP_RETURN outputs if that were standard, aka accepted into mempools and +propagated among nodes. + +So, we had a little bit of a hiccup, I think it's a couple months ago now, when +there was a discussion of whether OP_RETURN outputs that are bigger get accepted +into blocks or not. And some people created some OP_RETURN outputs and we had, +I think it was 30,000 OP_RETURN outputs in a week that were bigger than the +limit. So, it seems like there's already miners accepting these and overall, +with people working on schemes that might put more data in payment outputs, it +seems preferable to have a dedicated garbage bin where this stuff can go, +instead of forcing them to use payment outputs simply for the payment outputs to +OP_RETURN data trade-off. + +**Mike Schmidt**: Which of course is not an endorsement. Almost nobody wants +this. All those sort of caveats, this is just strictly speaking in the +technicals. + +**Mark Erhardt**: Yeah, exactly. I mean, just full disclosure, I've never owned +an inscription, I've never been interested in that. I just would prefer that +people put stuff in OP_RETURN outputs over payment outputs. And I also haven't +received any money for this, as some people have suggested. It's just Bitcoin +transactions are a form of data that is being sent around. We specifically want +this data to be used for payments, but there are many fields in Bitcoin +transactions that can be used to embed data and we can't control and prevent +this. So, with recently the last two years, a renewed interest of people +putting data on Bitcoin because Bitcoin is a very successful payment network and +a global network, and so it's more attractive to have their crap on Bitcoin than +on other networks, it seems unlikely that we will be able to fully prevent this. +And if they continue doing it and don't have enough space the way we currently +permit, they may bloat the UTXO set further with unspendable UTXOs. While we +have a huge UTXO set growth right now, I believe that most of those UTXOs are, +in principle, spendable, whereas writing data to payment outputs is, in +principle, completely unspendable. + +Anyway, if there is a very mixed mempool policy on the network, the problem with +that is that it reduces the fairness of mining. Optimally, we'd like mining to +be as fair as possible. Just, if something happens on a network, some people +don't include transactions, it is necessary for censorship-resistance that +people can just get some ASICs, start mining at home and include those +transactions. And we do want transactions to generally be available on the +mempools for anyone to stand up and start mining. If we instead go and start +restricting who we show transactions to in the beginning, or build out tools to +hand transactions out-of-band to miners that will include them, this is a +slippery slope to the mempool not working for miners as a source of information +and reducing our censorship-resistance. So, a lot of ink has been spilled on +this in the past few months already, but the decision was basically, we would +expect hopefully OP_RETURN to be preferred over putting data in payment outputs. +We would not really expect OP_RETURN to be preferred over inscriptions. People +are doing inscriptions already, and it seems unlikely to be able to squash that +without a consensus change. And consensus changes are pretty slow and +heavy-handed to squash a protocol that spent something along the lines of 30% of +all fees in the last two years, maybe more. + +So, yeah, that's where we're at. I haven't practised this. I hope I said some +good stuff here! + +**Mike Schmidt**: Yeah, that was good. A little bit more in depth than just an +overview, but probably something that folks are curious about. + +**Mark Erhardt**: Well, anyway, so given that data carrier transactions already +propagate on the network and get included and the default has been increased to +100,000, people felt that would be a bit disingenuous to not deprecate this +setting to set it lower. But that's currently being reviewed, right, Mike? + +**Mike Schmidt**: Indeed. No comment. + +**Mark Erhardt**: Okay, anyway. The second change to OP_RETURN is that instead +of just allowing a single OP_RETURN output, Bitcoin Core 30.0 will allow +multiple data carrier outputs. The sum of the output scripts is what is limited +by the data carrier size configuration option. So, if you choose to set data +carrier size to 83 bytes, it will behave very similar to before, in that it +limits the overall output scripts to 83 bytes, but they might be split across +more than one OP_RETURN output. + +The other big thing we saw was the sub-1-sat/vB (satoshi per virtual byte) +summer, where suddenly some miners decided to accept transactions below their +previously stable minimum relay transaction feerate of 1 sat/vB. So, with +thousands, well, with I think lately up to 80% of transactions in blocks being +below 1 sat/vB, Bitcoin Core 30.0, like 29.1, will propagate transactions paying +0.1 sat/vB. So, this is a 10x reduction in the minimum feerate. Corresponding, +the incremental relay fee is also reduced by a factor 10, because it doesn't +make sense to allow a first transaction to be sent at 0.1 sat/vB and then to +require the replacement to pay 1 sat/vB; 10x to replace the same amount of data. +So, both of these are lowered together. Okay, that was the policy section. I +have six more sections. Do we have enough time for this, Mike? + +**Mike Schmidt**: Yeah, let's do it. + +**Mark Erhardt**: To be honest, most of the other sections are probably not +long. So, let's look at P2P and network changes. There is an improvement to +the opportunistic 1p1c (one-parent-one-child) package relay. Previously, we +would literally only accept two transaction packages when they were offered. +Now, if there is other transactions in the cluster of the 1p1c, we also accept +it. So, for example, if a grandparent transaction is already in the mempool and +now we get offered parent and child, we will be able to accept that into our +mempools. Same if there's multiple parents and the other parents are already in +our mempool, and now we receive one parent and one child, we will be able to +process these and accept them into our mempool. You can also, if you have any +questions or comments, jump in. + +**Mike Schmidt**: Okay, yeah, I was trying let you do your thing. But, I have a +few things I made notes on that I want to make sure we cover, but I'm going to +let you do your thing for now. + +**Mark Erhardt**: Okay. Well, just let me know if you have something. The +orphanage was re-architected. Previously, the transaction orphanage, where we +keep transactions for which we don't know the parents, was limited to simply 100 +transactions. With the opportunistic 1p1c package relay, we anticipate that the +orphanage will be used more. So, it was changed to have limits per peer in +order to prevent that we throw away useful data. We now track every +announcement from our peers of orphan transactions by the entries of the wtxid +and the peer that sent it to us. So, basically, when multiple peers tell us +about a transaction, we will have multiple entries for that, just remembering +who announced stuff for us. And if any one peer floods us with stuff, we will +just simply start by removing their announcements, not their transactions. So, +if other people announced the same transactions to us, they remain in our +orphanage. + +This is a drastic improvement over the previous approach where we simply had a +first in, first out orphanage with 100 entries. So, if someone spammed us, we +would just cycle through it and lose those orphans. Now we would just cycle +through the spammer's entries. So, the announcements would get deleted, but if +other people also send us the same announcements, we would keep the +transactions. So, the overall orphanage has now a limit of 404,000 weight units +per peer, and this can be filled by any peer, but it's limited by the total +number. And if there's too much stuff, we keep 100 announcements per peer I +think at most. + +**Mike Schmidt**: And I'll point listeners as well, if you're curious about the +orphanage discussion, we did cover a few different PRs in the newsletter, which +I'll let you find on your own. But we also had Gloria on twice for +orphanage-related discussion. One was in our show, #362 Recap, where there was +a Bitcoin Core PR Review Club on the topic. And then, the second one was when +Gloria co-hosted with me for #366, and one of the notable PRs was around the +orphanage as well. So, check into that if you're curious about the orphanage +discussion. + +**Mark Erhardt**: Actually, let me correct myself right away. I don't think +there's a 100-transaction limit per peer. There's a global limit now that the +total number of entries plus unique transaction inputs is limited, and we allow +anyone to add to the global data. But then, when we have to remove stuff +because we have too much, I think we start with the peer that has the most +entries. In conjunction with that, maxorphantx configuration option no longer +works, because we don't really have a simple number of limits for the orphanage. +Okay. There's also, if people want to follow along on this, there is a draft in +the Bitcoin-Dev wiki on Bitcoin Core and GitHub where you can see all the +release notes in detail before the release. + +**Mike Schmidt**: Murch, is there a draft of a testing guide at all for this +release, do you know? + +**Mark Erhardt**: I have not seen one yet, but maybe I was just unobservant. + +**Mike Schmidt**: Yeah, I haven't seen it either. But for listeners, I think +we've promoted going through those guides in the past and also testing things on +your own and providing feedback. It sort of gives a little blueprint for how +you might test certain features, especially some of these ones that Murch is +outlining. Given that this is a decentralized project, it's quite possible that +no one's picked that up for this particular release, and it's also possible that +Murch and I just aren't aware of it. So, if we find it, we'll talk about it. + +**Mark Erhardt**: I think I saw someone volunteer to do it. I just haven't +seen. Maybe there is a testing guide. I haven't seen the announcement though. +All right. We've talked a bunch about multiprocess in the past. The idea is to +be able to run separate parts of the Bitcoin Core binary in, well, separate +processes. And in conjunction with this, we introduce a new Bitcoin command on +the command line. Instead of calling bitcoind, you can now also use a synonym, +which is “bitcoin node”. To start Bitcoin-Qt, you can instead also call +“bitcoin gui”. And if you want to use bitcoin-cli-named, you can use “bitcoin +rpc” instead. And I'll talk about the IPC mining interface in conjunction with +this right away. + +So, one of the things that goes hand in hand with the multiprocess splitting-up +of the binary is that we now surface an inter-process communication interface, +IPC mining interface. This is one of the applications of this new Bitcoin +command. You can start it with the ipcbind=unix. You can start the node with +that. And this will make a Unix socket that you can use with Stratum v2 nodes +to request block templates and you can submit mined blocks. This is in +conjunction with the Stratum v2 support. So, if you run a regular Bitcoin Core +30.0, you can start it in this mode and then you can have your Stratum v2 +software pull for new block templates through this IPC, and if you find a block, +submit it. + +**Mike Schmidt**: Nothing to add there. I think you emphasized that this is +motivated by specifically the Stratum v2 initiative. + +**Mark Erhardt**: Yeah, and this is very experimental, just to be clear. But +the background was this was in the works. Sjors has been working on this for a +while. People were requesting that it be in this release, so they could run it +against a regular Bitcoin Core release instead of Sjors' private development +branch. So, this is I think a solid step forward to rolling out Stratum v2 +support eventually. + +**Mike Schmidt**: And this is also sort of this idea of multiple binaries. +Multiprocess has been in the works for, like, a decade. So, while Murch is +rightfully pointing out that this is sort of the first potentially experimental +version of it, it's actually been a long-running project. So, it's good to even +see it in that state at this point. + +**Mark Erhardt**: Right. There's a change with external signing. External +signing on Windows has been re-enabled. So, if you want to use your hardware +signer with Bitcoin Core on Windows, that should work in 30.0. All right. I +skip over install changes, I think that's not super-interesting. I also skip +over indexes. There is a bug fix or an attack-vector fix for logging. If you +have a lot of logging, it's limited now and it suppresses excessive logging and +puts in a message of how much logging was skipped. + +Talking about RPCs next. The paytxfee startup option, and settxfee RPC, they +both allowed you to set a standard feerate that you use for all of your +transactions in the very dynamic fee environments we've had in the past few +years. That was removed now. If you want to force your feerate to be a +specific feerate for a transaction, please use the fee_rate argument on +fundrawtransaction, sendtoaddress, send, sendall and sendmany. Yeah, +deprecated; will be removed in the next. So, it still works in this one. + +What else do I have here? The PSBT bump fee and bump fee. RPCs now allow +full-RBF replacement. So, where previously you did have to signal BIP125 in +order to replace a transaction, we now also allow replacement of all +transactions per these RPCs. And there is a new /rest/api/endpoint, +/rest/spenttxouts/BLOCKHASH that returns spent tx outs from the undo data, so +for every block we have an undo data, if we have to roll back in order to, for +example, reorganize to a better chain tip; and we can read that out to see which +UTXOs were spent. And you can get all spent txos for a specific block by the +blockhash from this new /rest/api/endpoint. There is also waitfornewblock, +waitforblock, and waitforblockheight RPCs that have been unhidden. They were +present previously, but hidden. These are also interesting in the context of +Stratum v2. All right. + +**Mike Schmidt**: You need a half-time show? + +**Mark Erhardt**: Half-time show, yeah! On build system stuff, maxmempool and +dbcache are now capped for 32-bit systems. 32-bit systems have generally a +limit on how much RAM they can have. So, maxmempool is now limited to 500 MB +and dbcache is limited to 1 GB. The NAT-PMP option is enabled by default now. +This is a mechanism, or a feature, that will punch a connection through routers +that permit it. The UPnP option that previously existed has been removed fully +now after being deprecated before. There were several security issues with that +before. NAT-PMP is a self-written, homegrown replacement that is now on by +default in Bitcoin Core 30.0. So, if you previously had issues getting your +node to listen on the network, maybe it'll work now with this new release. + +**Mike Schmidt**: Most routers don't support it out of the box, right? They +don't default have that setting on, but you can if you turn it on in your +router, then your Bitcoin Core node will, by default, start allowing those +connections. + +**Mark Erhardt**: Right, so if your node was previously a listening node and now +it doesn't work, maybe check your router settings. But also, very possible that +previously it didn't work and now it'll work, because we changed the mechanism +by which we open ports for listening. Okay, wallet. There's a lot of changes +in the wallet this time because the legacy wallet has been fully removed now. +This is a five-year project, or so. We've talked a bunch about descriptors, +output script descriptors, and wallet descriptors, all the same thing. But the +descriptor wallet was introduced some, I think, five years ago. And this new +version will be the first version where you cannot create or load the legacy +wallets that were reliant on Berkeley DB. One thing in this context is Berkeley +DB had been unmaintained for 12 years or something, and it's high time that we +get rid of it. Descriptors are generally also more powerful in their backup +capability than xpubs. So, this is just a better wallet throughout. You cannot +load or create the legacy wallets anymore with Bitcoin Core 30, but you can +migrate them to descriptor wallet format. Please check out the migratewallet +RPC if you want to do that. I think it also works in the GUI. + +So, because the legacy wallet is removed, there is a bunch of options for the +Bitcoin wallet that have been removed because they were only for the legacy +wallet. For example, importaddress, importmulti, importprivkey, dumpprivkey, +and so forth, don't work anymore. Where it is sensible, there are replacements +with importdescriptor, and so forth. And yes, you can absolutely import a +single private key as a descriptor. + +**Mike Schmidt**: I saw that on the internet earlier. + +**Mark Erhardt**: Yeah, I saw some people complain that they can't. So, that's +why I'm saying it. Yes, you can import private keys. You just have to use the +descriptor instead. + +**Mike Schmidt**: Well, in the migration project more broadly, this is one of +those, I mentioned the ten-year project, this is a five-year project that's +finally wrapping up. And I know Optech and Murch, you've pointed this out to +people, but make sure that, listeners, you know and that the projects you're +working on know that this is going away. Now, the wallet is not going away, +right? It's the legacy wallet that is going away. There's migration features. +It probably won't be a ton of work, but if you are relying on a certain legacy, +aspects of the legacy wallet, then you should look into putting tooling towards +migrating, so that in the future you can continue to use Bitcoin Core's wallet. +So, for folks who aren't aware, please raise that attention, because I saw some +people that were sort of caught off guard with that. + +**Mark Erhardt**: Well, to be fair, it had been deprecated for several versions. +So, the deprecation warning is specifically to make people aware that it is in +the process of being removed. The big upside is a lot of the very complicated +old wallet code could be removed now. We have a clean separation of watch-only +wallets and non-watch-only wallets. Either you have private keys or you don't +in a wallet. A lot of the handling of where we didn't know whether it was watch +only or we could spend it became a lot simpler. So, a lot of the wallet code is +much simpler and better now. + +**Mike Schmidt**: And Berkeley as a dependency is gone as well. + +**Mark Erhardt**: Correct, the Berkeley DB dependency is finally gone. So, +yeah, I already jumped into this a little bit. Yeah, includewatchonly has been +removed because wallets are now either watch-only or non-watch-only. Yeah, and +there-is-watch-only field is also removed because it doesn't make sense anymore. +Additionally, we now support TRUC (Topologically Restricted Until Confirmation) +transactions in the wallet so we can create v3 transactions. This creating of +transactions will respect the TRUC parameters, so you can't have more than one +unconfirmed parent, you have to be within the limit of the sizes that are +permitted to be a standard transaction, and it will automatically notice if +you're trying to spend v2 inputs for every v3 transaction, which is only allowed +if they're confirmed. Unconfirmed, it doesn't work. So, coin selection for +that has been updated. It'll just behave as the TRUC BIP describes. And yeah, +the version parameter is now available for a bunch of the transaction creation +RPCs, createrawtransaction, createpsbt, send, sendall and walletcreatefundedpsbt +now have a version parameter that allows you to set v1, v2 or v3. + +**Mike Schmidt**: I'll let you catch your breath a second and just interlude. +Murch mentioned, I think last week, "Hey, if it seems like there's more in this +release, part of that is because of the just timing of the releases". I think +maybe there was something like five months between the previous release and the +release before it, whereas this release and 29 had something like maybe seven +months in between it. So, there's some things that got bumped into this +release, and obviously there's more time then too that resulted in a bigger +Murch monologue than the normal for the release. + +**Mark Erhardt**: Yeah. On the GUI front, the GUI has been migrated from Qt5 to +Qt6. There is still ongoing work to revamp the whole look of the wallet. If +you want to get a preview of what the new GUI for Bitcoin Core should look like +eventually, you can go to bitcoincore.app where they have a very beautiful +preview and demo of the wallet. The GUI work has been ongoing for a long time +too, so this is, I think, one of the first things that surface from this. This +is a collaboration between the Bitcoin design community and some front-end +developers working on the GUI update. + +This is not in the release notes, we don't usually cover performance in that, +but I want to also point out that v29 to v30, IBD (Initial Block Download) has +been measured to be about 20% faster with v30, and the re-index is about 17% +faster than in v29. + +**Mike Schmidt**: Yeah, that was on my list too, because I knew it wasn't on the +release note, so I'm glad you brought it up. I think it's okay to pat yourself +on the back for these sorts of things. So, I wish that was in there, but I'm +glad you mentioned it. + +**Mark Erhardt**: Right. Oh, yeah, the last thing I wanted to mention is some +people pointed out that the compatibility section changed. It used to say that +there was support for Windows 7. The v30 release does not support Windows 7. I +think there was a build issue. Windows 10 has been out for ten years, 11 years +or so. So, the Windows support has been moved to Windows 10-plus instead of +Windows 7. + +**Mike Schmidt**: I don't have the notes up in front of me, but I assume there's +assorted sort of bug fixes in here. But in terms of vulnerability disclosures, +if there are any that would happen at some point after the release, correct? + +**Mark Erhardt**: Right, so we have a four-tier vulnerability reporting scheme +for minor issues. They get reported, I think, two weeks after a release fix +system, medium- and high-level severity issues. Right, OK, so there's four +different severities, low, medium, high, and severe, I think. Or I don't +remember what, very high? Anyway, the smallest category is revealed two weeks +after it has been fixed in any release; the medium and high are revealed when +the last maintained version goes end of life; and the extreme severity is +handled on a case-by-case basis, depending. It might be revealed very quickly +to get everyone updated quickly, or it might be revealed later when there's +really very few nodes running the version, and maybe also other related projects +have been informed and had a chance to fix bugs,, because we have a lot of +downstream copycats. + +**Mike Schmidt**: Low, medium, high, and critical. And for folks who want to +see some examples of those, go to bitcoincore.org. If you go to the development +dropdown, there's a security advisories area. + +**Mark Erhardt**: Thank you, yes, that's what I meant. Critical. Okay, this +covers the 30.0 release to some degree, I guess. + +_BDK Chain 0.23.2_ + +**Mike Schmidt**: Yeah, great job, Murch. We do have a second release that +we'll not dive nearly as deep into, but BDK Chain. So, as a reminder, BDK sort +of re-architected their repository. So, I believe there's a BDK wallet, there's +a BDK chain, which is sort of the guts of the thing. This is BDK Chain 0.23.2. +It has improvements for handling transaction conflicts. It redesigns this +filter iterator API, which actually is a PR later that we'll get to, and I can +jump into that a little bit. It improves its compact block filtering +essentially for Electrum. And there's also improvements to reorg management and +also anchors. So, if you're a BDK Chain user, check out the release. + +_Bitcoin Core #33268_ + +And Murch and, we're right back to you for a Notable code segment. We're in +Bitcoin Core #33268, how transactions are recognized as part of a user's wallet. + +**Mark Erhardt**: Right, so we recently introduced ephemeral anchors and they +specifically are designed to be allowed to have an amount of zero. The wallet +previously would recognize transactions as belonging to the wallet if any input +spent wallet funds. And now, with the outputs being allowed to have an amount +of zero, those would not have been discovered. So, there's a slight change +here. Transaction outputs that are tracked by the wallet and spent by a +transaction cause this transaction to be tracked by the wallet, which makes +sense. So, when we create ephemeral anchors and spend them, they make the child +transaction tracked by the wallet. So, also, if someone else spends your +ephemeral anchor, I think it should be tracked now, which is something you +probably want to see because with transaction siblings are mempool conflicts, +you can only have packages of two transactions. So, if another child spends the +parent while they're both unconfirmed, the other child will replace the first +child, given that it has more juicy fees. Yeah, so you would see that in your +wallet if it spends the ephemeral anchor. + +_Eclair #3157_ + +**Mike Schmidt**: Moving to our LN PRs, have Eclair #3157. This is a PR that is +titled, "Resign next remote commitment on reconnection". And for this one, I +thought t-bast had a good description, so I'm going to quote the first couple of +sentences of that for summary of what he's talking about here, "We previously +retransmitted our last commit_sig on reconnection if it hadn't been received by +our peer, without changing it. This can be an issue for taproot channels when +remote nodes don't use deterministic nonce derivation, because their nonce may +be different on reconnection, and our previous commit_sig would thus not be +valid anymore". So, now they will resign that next remote commit when they +reconnect. He also notes, "We now re-sign the next commitment on reconnection, +using the latest nonces we receive from channel_reestablish message". + +_LND #9975_ + +LND #9975. This PR adds support for taproot fallback addresses. In BOLT11, a +fallback address is an onchain Bitcoin address that the recipient includes as an +alternate way to pay if the payer cannot or does not want to pay via LN. LND +already supported segwit fallback addresses, but now taproot fallback addresses +are supported with this PR. + +_LND #9677_ + +LND #9677 updates the PendingChannel response message in LND by adding two +pieces of new information to that existing message. It adds the number of +confirmations required for a new LN channels activation, and it also adds the +block height at which that funding transaction was confirmed. + +_LDK #4045_ + +LDK #4045 is part of LDK's async payments project that we've talked about on and +off. I thought that there was actually a comment in one of the code files that +did a good job of explaining this, "LDK supports a feature for always-online +nodes, such that these nodes can hold on to an HTLC from an often-offline +channel peer until the often-offline payment recipient sends an onion message +telling the always-online node to release the HTLC. This is set to true. Our +node will carry out this feature for channel peers that request it". And I +think that the write up this week also has something similar, but I thought that +that was an interesting comment direct from the source, literally from the +source code. + +_LDK #4049_ + +LDK #4049 is also part of LDK's async payments project. This PR is titled, +"Always-online node forward invoice request". As an always-online LDK node, if +that LDK node receives an invoice request on behalf of an async payment +recipient, this adds support for forwarding that request to the recipient in +case that recipient is online and can actually respond to that request. So, a +lot of async work in LDK here. I think we saw some similar work on other +implementations recently. So, good for often-offline LN transactors. + +_BDK #1582_ + +BDK #1582, this is actually just, well, I don't want to say just, but it's a +refactor PR. It's part of a larger effort in BDK to support header checkpoints +when using the Electrum backend. So, without these header checkpoints, BDK has +to re-download block headers in certain situations. So, this particular PR +adds, from a refactor perspective, adds generic types for a few BDK data types, +which is a step toward that effort to store the whole headers and prevent the +need to redownload block headers. And in addition to avoiding that +redownloading of those headers, it also enables caching of merkle proofs and +Median Time Past (MTP), which I'm not sure what they will use that for, but +that's probably just my ignorance, Murch. I don't know if you have anything +that comes top of mind? No. + +_BDK #2000_ + +BDK #2000 makes changes to BDK's FilterIter API. This filter iterator scans +Bitcoin blocks and then uses compact block filters looking for transactions +relevant to a particular wallet. The PR description outlines the issue with +that particular API in the way that it's architected before this PR, which is, +"Previously FilterIter did not detect or handle reorgs between next calls, +meaning that if a reorg occurred, we might process blocks from a stale fork, +potentially resulting in an invalid wallet state. This PR aims to fix that by +adding logic to explicitly check for and respond to a reorg on every call to +next". So, I assume there that next is the way that they're iterating and +processing these filter responses. And so, now it is reorg-friendly, which I +think hearkens back to the release that mentioned that earlier. + +_BDK #2028_ + +Last PR this week, BDK #2028, which adds a last evicted from the mempool +timestamp for a transaction to the TxNode data type. Previously, that +last_evicted field was on the TxGraph data type, and that field indicates when a +transaction was removed from the mempool, for example, being replaced through +RBF. So, the field moved data types, which is actually a breaking change. And +that's noted in the PR as well. We did cover the TxGraph, adding the +last_evicted timestamp back in Newsletter and Podcast #346, where we got into +more detail around the specifics of that. But this particular one is just +moving where that field is to a new data type. + +**Mark Erhardt**: I have an uninformed question here. If you evict something +from the mempool, where do you store that last_evicted timestamp field on? Is +this transactions that are relevant to the wallet attached to it or something? +Because otherwise, dropping stuff from the mempool means, in Bitcoin Core at +least, that we drop it completely. So, I'm kind of curious, where is that +last_evicted field? + +**Mike Schmidt**: Yeah, I'm not sure. Maybe that's part of why they moved data +structures from the TxGraph to the TxNode. + +**Mark Erhardt**: Oh, I see. I think it's generally just the timestamp when any +transaction was last evicted. It's not on a specific transaction, maybe. Does +that make more sense? + +**Mike Schmidt**: It could. Yeah, I would actually probably scan back the +transcript of you and I talking about this in #346 as it probably is similar +now, but I can't answer firsthand with that. + +**Mark Erhardt**: Yeah, well, I don't know. Okay. + +**Mike Schmidt**: Well, that's it. I guess we can wrap up. Murch, thank you +for taking the time to prepare all of the release notes summary from Bitcoin +Core RC v30, or I guess v30, but this happens to be RC1. I did check, I did not +see RC2 yet. And obviously we want to thank our guests, ZmnSCPxj, who had to +drop earlier. Great of him to join. Cedarctic, thank you for hanging on. +Great of you to join as well. Thank you for doing that research and being here +to represent that for us. And, Murch, thanks for co-hosting. We'll hear you +next week. + +**Mark Erhardt**: Thank you Mike, hear you soon. + +**Mike Schmidt**: Cheers. {% include references.md %} From 3e241acdccdbe3b07e8975894d6f48b53cde2227 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Wed, 1 Oct 2025 11:49:01 -0500 Subject: [PATCH 270/278] Podcast: add 373 recap --- .../en/newsletters/2025-09-26-newsletter.md | 54 +++++++++---------- .../en/podcast/2025-09-30-newsletter-recap.md | 24 +++++++++ 2 files changed, 51 insertions(+), 27 deletions(-) create mode 100644 _posts/en/podcast/2025-09-30-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-09-26-newsletter.md b/_posts/en/newsletters/2025-09-26-newsletter.md index 039f6684bd..e38813eb59 100644 --- a/_posts/en/newsletters/2025-09-26-newsletter.md +++ b/_posts/en/newsletters/2025-09-26-newsletter.md @@ -22,7 +22,7 @@ describing notable changes to popular Bitcoin infrastructure software. 0.12 or greater. The vulnerability allowed an attacker to broadcast an old commitment transaction to steal all current funds from a channel. In addition to fixing the vulnerability, Eclair developers - added a comprehensive testing suite designed to catch similar problems. + added a comprehensive testing suite designed to catch similar problems. {% assign timestamp="18:50" %} - **Research into feerate settings:** Daniela Brozzoni [posted][brozzoni feefilter] to Delving Bitcoin the results of a scan of almost 30,000 @@ -42,7 +42,7 @@ describing notable changes to popular Bitcoin infrastructure software. value Bitcoin Core sets, through rounding, when the node is more than 100 blocks behind the tip of the chain and is focused on receiving block data rather than transactions that might be confirmed in later - blocks. + blocks. {% assign timestamp="0:35" %} ## Selected Q&A from Bitcoin Stack Exchange @@ -57,58 +57,58 @@ answers posted since our last update.* - [Implications of OP_RETURN changes in upcoming Bitcoin Core version 30.0?]({{bse}}127895) Pieter Wuille describes his perspectives on the effectiveness and drawbacks of - using [mempool and relay policy][policy series] to affect the contents of mined blocks. + using [mempool and relay policy][policy series] to affect the contents of mined blocks. {% assign timestamp="28:27" %} - [If OP_RETURN relay limits are ineffective, why remove the safeguard instead of keeping it as a default discouragement?]({{bse}}127904) Antoine Poinsot explains the malincentive created by the current OP_RETURN - default limit value in Bitcoin Core and the rationale for removing it. + default limit value in Bitcoin Core and the rationale for removing it. {% assign timestamp="42:12" %} - [What are the worst-case stress scenarios from uncapped OP_RETURNs in Bitcoin Core v30?]({{bse}}127914) Vojtěch Strnad and Pieter Wuille respond to a list of extreme scenarios that - might occur with the OP_RETURN limit policy default setting changing. + might occur with the OP_RETURN limit policy default setting changing. {% assign timestamp="43:25" %} - [If OP_RETURN needed more room, why was the 80-byte cap removed instead of being raised to 160?]({{bse}}127915) Ava Chow and Antoine Poinsot outline considerations against a 160-byte default OP_RETURN value including an aversion to continually setting the cap, existing large miners already bypassing the cap, and risks of not anticipating future - on-chain activity. + on-chain activity. {% assign timestamp="50:39" %} - [If arbitrary data is inevitable, does removing OP_RETURN limits shift demand toward more harmful storage methods (like UTXO-inflating addresses)?]({{bse}}127916) Ava Chow points out that dropping the OP_RETURN limit provides incentives - to use a less harmful alternative for output data storage in certain situations. + to use a less harmful alternative for output data storage in certain situations. {% assign timestamp="59:48" %} - [If OP_RETURN uncapping doesn’t increase the UTXO set, how does it still contribute to blockchain bloat and centralization pressure?]({{bse}}127912) Ava Chow explains how increased use of OP_RETURN outputs affects the resource - utilization of Bitcoin nodes. + utilization of Bitcoin nodes. {% assign timestamp="1:00:17" %} - [How does uncapping OP_RETURN impact long-term fee-market quality and security budget?]({{bse}}127906) Ava Chow answers a series of questions about hypothetical OP_RETURN usage and - its impact on future Bitcoin mining revenues. + its impact on future Bitcoin mining revenues. {% assign timestamp="1:02:11" %} - [Assurance blockchain will not suffer from illegal content with 100KB OP_RETURN?]({{bse}}127958) User jb55 provides several examples of potential encoding schemes for data concluding "So no, in general you can't really stop these kinds of things in a - censorship resistant, decentralized network." + censorship resistant, decentralized network." {% assign timestamp="1:04:34" %} - [What analysis shows OP_RETURN uncapping won’t harm block propagation or orphan risk?]({{bse}}127905) Ava Chow points out that while there is no dataset specifically isolating large OP_RETURNs, previous analyses of [compact blocks][topic compact block relay] and stale blocks indicate there is no reason to expect them to behave - differently. + differently. {% assign timestamp="1:05:25" %} - [Where does Bitcoin Core keep the XOR obfuscation keys for both block data files and level DB indexes?]({{bse}}127927) Vojtěch Strnad notes the chainstate key is stored in LevelDB under the - "\000obfuscate_key" key and the block and undo data key is stored in the blocks/xor.dat file. + "\000obfuscate_key" key and the block and undo data key is stored in the blocks/xor.dat file. {% assign timestamp="1:06:10" %} - [How robust is 1p1c transaction relay in bitcoin core 28.0?]({{bse}}127873) Glozow clarifies that the non-robustness referred to in the original opportunistic [one parent one child (1P1C) relay][28.0 1p1c] pull request means "not guaranteed to work, particularly in the presence of adversaries or when volume - is really high so we miss things." + is really high so we miss things." {% assign timestamp="1:06:34" %} - [How can I allow getblocktemplate to include sub 1 sat/vbyte transactions?]({{bse}}127881) User inersha discovers the settings required to not only relay sub 1 sat/vbyte - transactions but also have them included in a candidate block template. + transactions but also have them included in a candidate block template. {% assign timestamp="1:10:37" %} ## Releases and release candidates @@ -116,9 +116,9 @@ _New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates._ -- [Bitcoin Core 30.0rc1][] is a release candidate for the next major version of - this full verification node software. Please see the [version 30 release - candidate testing guide][bcc30 testing]. +- [Bitcoin Core 30.0rc1][] is a release candidate for the next major version of + this full verification node software. Please see the [version 30 release + candidate testing guide][bcc30 testing]. {% assign timestamp="1:13:00" %} ## Notable code and documentation changes @@ -136,47 +136,47 @@ repo], and [BINANAs][binana repo]._ out-of-memory errors or heavy swapping. For systems with less than 2GB of RAM, the `dbcache` warning threshold is 450MB; otherwise, the threshold is 75% of the total RAM. The `dbcache` 16GB limit was removed in September 2024 (see - Newsletter [#321][news321 dbcache]). + Newsletter [#321][news321 dbcache]). {% assign timestamp="1:15:26" %} - [Bitcoin Core #28592][] increases the per-peer transaction relay rate from 7 to 14 for inbound peers due to an increased presence of smaller transactions on the network. The rate for outbound peers is 2.5 times higher, increasing to 35 transactions per second. The transaction relay rate limits the number of - transactions a node sends to its peers. + transactions a node sends to its peers. {% assign timestamp="1:18:36" %} - [Eclair #3171][] removes `PaymentWeightRatios`, a pathfinding method that assumed uniformity in channel balances, and replaces it with a newly introduced probabilistic approach based on past payment attempt history (see - Newsletter [#371][news371 path]). + Newsletter [#371][news371 path]). {% assign timestamp="1:22:33" %} - [Eclair #3175][] starts rejecting unpayable [BOLT12][] [offers][topic offers] where the fields `offer_chains`, `offer_paths`, `invoice_paths`, and - `invoice_blindedpay` are present but empty. + `invoice_blindedpay` are present but empty. {% assign timestamp="1:26:41" %} - [LDK #4064][] updates its signature verification logic to ensure that if the `n` field (payee’s pubkey) is present, the signature is verified against it. Otherwise, the payee’s pubkey is extracted from the [BOLT11][] invoice with either a high-S or low-S signature. This PR aligns signature checks with the proposed [BOLTs #1284][] and with other implementations such as Eclair (See - Newsletter [#371][news371 pubkey]). + Newsletter [#371][news371 pubkey]). {% assign timestamp="1:29:36" %} - [LDK #4067][] adds support for spending [P2A ephemeral anchor][topic ephemeral anchors] outputs from [zero-fee commitment][topic v3 commitments] transactions, ensuring that channel peers can claim their funds back on-chain. See Newsletter - [#371][news371 p2a] for LDK’s implementation of zero-fee commitment channels. + [#371][news371 p2a] for LDK’s implementation of zero-fee commitment channels. {% assign timestamp="1:31:04" %} - [LDK #4046][] enables an often-offline sender to send [async payments][topic async payments] to an often-offline recipient. The sender sets a flag in the `update_add_htlc` message to indicate that the [HTLC][topic htlc] should be held by the LSP until the recipient comes back online and sends a `release_held_htlc` [onion message][topic onion messages] to claim the - payment. + payment. {% assign timestamp="1:32:43" %} - [LDK #4083][] deprecates the `pay_for_offer_from_human_readable_name` endpoint to remove duplicate [BIP353][] HRN payment APIs. Wallets are encouraged to use the `bitcoin-payment-instructions` crate to parse and resolve payment instructions before calling `pay_for_offer_from_hrn` to pay an [offer][topic - offers] from a [BIP353][] HRN (e.g. satoshi@nakamoto.com). + offers] from a [BIP353][] HRN (e.g. satoshi@nakamoto.com). {% assign timestamp="1:35:27" %} - [LND #10189][] updates its `sweeper` system (see Newsletter [#346][news346 sweeper]) to properly recognize the `ErrMinRelayFeeNotMet` error code and @@ -185,12 +185,12 @@ repo], and [BINANAs][binana repo]._ wouldn't be retried. This PR also improves weight estimation by accounting for a possible extra change output, which is relevant in [taproot][topic taproot] overlay channels used to enhance LND’s [Taproot Assets][topic client-side - validation]. + validation]. {% assign timestamp="1:38:23" %} - [BIPs #1963][] updates the status of the BIPs that specify [compact block filters][topic compact block filters], [BIP157][] and [BIP158][], from `Draft` to `Final` as they’ve been deployed in Bitcoin Core and other software since - 2020. + 2020. {% assign timestamp="1:41:17" %} {% include snippets/recap-ad.md when="2025-09-30 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-09-30-newsletter-recap.md b/_posts/en/podcast/2025-09-30-newsletter-recap.md new file mode 100644 index 0000000000..3606671b01 --- /dev/null +++ b/_posts/en/podcast/2025-09-30-newsletter-recap.md @@ -0,0 +1,24 @@ +--- +title: 'Bitcoin Optech Newsletter #373 Recap Podcast' +permalink: /en/podcast/2025/09/30/ +reference: /en/newsletters/2025/09/26/ +name: 2025-09-30-recap +slug: 2025-09-30-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt are joined by Matt Morehouse, Daniela +Brozzoni, and Gustavo Flores Echaiz to discuss [Newsletter #373]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-9-1/408486171-44100-2-4df39d090aa21.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %} From e2c31ac34273ed537b4b4669d5e5900d644a78bd Mon Sep 17 00:00:00 2001 From: Neil Woodfine Date: Fri, 3 Oct 2025 00:08:44 +0700 Subject: [PATCH 271/278] Topics: update Ark entry (#2503) * Updated the Ark protocol excerpt and description to improve accuracy and clarity. Updated primary sources to reflect the two implementations and their documentation. Co-authored-by: nwoodfine Co-authored-by: Mike Schmidt --- _topics/en/ark.md | 80 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 54 insertions(+), 26 deletions(-) diff --git a/_topics/en/ark.md b/_topics/en/ark.md index 447187d643..3539c82f35 100644 --- a/_topics/en/ark.md +++ b/_topics/en/ark.md @@ -1,9 +1,9 @@ --- -title: Ark +title: Ark protocol ## Optional. Shorter name to use for reference style links e.g., "foo" ## will allow using the link [topic foo][]. Not case sensitive -# shortname: foo +shortname: ark ## Optional. An entry will be added to the topics index for each alias #title-aliases: @@ -17,8 +17,18 @@ topic-categories: ## Optional. Produces a Markdown link with either "[title][]" or ## "[title](link)" primary_sources: - - title: "Basis Of Ark Technology (BOATs)" - link: https://github.com/ark-network/boats + + - title: "Arkade implementation" + link: https://github.com/arkade-os + + - title: "Arkade technical documentation" + link: https://docs.arkadeos.com + + - title: "Second implementation" + link: https://codeberg.org/ark-bitcoin + + - title: "Second technical documentation" + link: https://docs.second.tech/ ## Optional. Each entry requires "title" and "url". May also use "feature: ## true" to bold entry and "date" @@ -58,30 +68,48 @@ see_also: ## Required. Use Markdown formatting. Only one paragraph. No links allowed. ## Should be less than 500 characters excerpt: > - **Ark** is a trustless joinpool-style protocol where a large number - of users share a UTXO by accepting a counterparty as a co-signer on - all transactions within a certain time period. This spreads the cost - of onchain fees from using that UTXO across many users, minimizing - their individual costs. + In the **Ark protocol**, a large number of users trustlessly share onchain UTXOs + using trees of pre-signed, offchain transactions. By sharing UTXOs and transacting + offchain, Ark users can spread the cost of onchain fees across multiple participants, + minimizing individual transaction costs while maintaining self-custody of their bitcoin. --- -The users can either unilaterally withdraw their bitcoins onchain -after the expiry of the time period or instantly and trustlessly -transfer them offchain to the counterparty before the end of the time -period. Normally, a user will simply roll their bitcoins into another -contract with the counterparty, which can be highly fee efficient when -done with many other users at the same time. Alternatively, the -counterparty may help the user make a payment onchain, through LN, or -through any other protocol supported by the counterparty. Presumably, -the counterparty would pass along to the user any fees the -counterparty had to pay for using the payment protocol, e.g. -forwarding fees if LN was used. - -Ark can be implemented on Bitcoin with no consensus changes required, -but it will support a larger number of users---making it much more fee -efficient---if a [covenant][topic covenants] feature like -[OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] is added to -Bitcoin. +Ark transaction trees are constructed periodically through an interactive +process known as "rounds". Each round involves multiple users and a counterparty +(an Ark operator), who together construct and sign the transaction tree, then +broadcast the root transaction onchain. Users securely store their branch and +leaf transactions offchain. This package of offchain transactions is known as a +VTXO (virtual UTXO), which serves as the core unit of value on Ark. + +To unilaterally withdraw bitcoin from Ark, a user broadcasts their branch and +leaf transactions in sequence, ultimately releasing their portion of the shared +UTXO to an onchain output under their sole control. However, under normal +operations, users will typically prefer cooperative exits, where they spend +their VTXO to receive an onchain UTXO from the Ark operator. + +VTXOs "expire" according to an absolute timelock. After this timelock expires, +both the Ark operator and users can unilaterally spend the bitcoin. To maintain +trustlessness, users must ensure their VTXOs are spent into a new transaction +tree before expiry. This expiry mechanism allows the Ark operator to efficiently +recover liquidity that has been allocated to previous rounds and external +spending operations. + +Payments between Ark users are handled as offchain, pre-signed extensions of the +transaction tree. Each payment transaction requires co-signatures from both the +sender and the Ark operator, meaning receivers must trust that the sender will +not collude with the operator to double-spend. + +Users can chain these payments by spending a received VTXO before it's included +in a new round. In payment chains, any sender in the chain could collude with +the operator to double-spend the entire chain. + +Upon receiving a VTXO, users can either roll it into a new round to regain +trustlessness, or spend it to another user before the expiry deadline. + +Ark can be implemented on Bitcoin without requiring consensus changes, but would +support significantly more users—and achieve greater fee efficiency—if covenant +features like [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] were added +to Bitcoin. {% include references.md %} {% include linkers/issues.md issues="" %} From 59f2adbd385887975c5663b6b6f7eacd3218bc72 Mon Sep 17 00:00:00 2001 From: Walpurga03 <101062312+Walpurga03@users.noreply.github.com> Date: Thu, 2 Oct 2025 19:11:44 +0200 Subject: [PATCH 272/278] Newsletter-373:Translate into German (#2513) Co-authored-by: Walpurga03 Co-authored-by: garfiel-d --- .../de/newsletters/2025-09-26-newsletter.md | 211 ++++++++++++++++++ 1 file changed, 211 insertions(+) create mode 100644 _posts/de/newsletters/2025-09-26-newsletter.md diff --git a/_posts/de/newsletters/2025-09-26-newsletter.md b/_posts/de/newsletters/2025-09-26-newsletter.md new file mode 100644 index 0000000000..3e428fd801 --- /dev/null +++ b/_posts/de/newsletters/2025-09-26-newsletter.md @@ -0,0 +1,211 @@ +--- +title: 'Bitcoin Optech Newsletter #373' +permalink: /de/newsletters/2025/09/26/ +name: 2025-09-26-newsletter-de +slug: 2025-09-26-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- + +Dieser Newsletter fasst eine Sicherheitslücke in älteren Eclair-Versionen sowie +Forschungsergebnisse zu Feerate-Einstellungen von Full Nodes zusammen. Außerdem +finden Sie wie gewohnt unsere Abschnitte mit ausgewählten Fragen & Antworten +von Bitcoin Stack Exchange, Ankündigungen zu neuen Releases und Release +Kandidaten sowie bemerkenswerte Änderungen an verbreiteter Bitcoin-Infrastruktur-Software. + +## Nachrichten + +- **Eclair-Sicherheitslücke:** Matt Morehouse [postete][morehouse eclair] + auf Delving Bitcoin eine verantwortungsvolle Offenlegung + ([responsible disclosure][topic responsible disclosures]) einer + Sicherheitslücke in älteren Eclair-Versionen. Allen Eclair-Nutzern wird + empfohlen, auf Version 0.12 oder neuer zu aktualisieren. Die Lücke ermöglichte + es einem Angreifer, eine alte Commitment-Transaktion zu veröffentlichen und so + alle aktuellen Mittel eines Kanals zu stehlen. Neben der Behebung der Lücke + haben die Eclair-Entwickler eine umfangreiche Test-Suite hinzugefügt, um + ähnliche Fehler künftig früher zu erkennen. + +- **Untersuchung zu Feerate-Einstellungen:** Daniela Brozzoni [veröffentlichte][brozzoni feefilter] + auf Delving Bitcoin die Ergebnisse eines Scans von fast 30.000 Full Nodes, + die eingehende Verbindungen akzeptierten. Jeder Knoten wurde nach dem + [BIP133][] Fee-Filter befragt, der die niedrigste Feerate angibt, bei welcher + der Knoten aktuell unbestätigte, weitergeleitete Transaktionen akzeptiert. + Solange die Mempools nicht voll sind, entspricht dies dem [standardmäßigen + minimalen Relay-Feerate][topic default minimum transaction relay feerates] + des Knotens. Die Auswertung zeigt, dass die meisten Knoten den bisherigen + Standard von 1 sat/vbyte (s/v) verwenden. Etwa 4 % der Knoten nutzten 0,1 s/v, + den Standard der kommenden Bitcoin Core 30.0, und rund 8 % antworteten gar + nicht auf die Abfrage – was auf sogenannte Spy-Nodes hindeuten kann. + + Ein kleiner Anteil der Knoten gab den Wert 9.170.997 (10.000 s/v) als + Feefilter an; Entwickler 0xB10C [merkte an][0xb10c feefilter], dass Bitcoin + Core diesen, durch Rundung entstandenen, Wert setzt, wenn der Knoten mehr als + 100 Blöcke hinter dem Tip liegt und sich auf den Empfang von Blockdaten statt + auf Transaktionen konzentriert, die in späteren Blöcken bestätigt werden könnten. + +## Ausgewählte Fragen & Antworten von Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] ist eine der ersten Anlaufstellen für +Optech-Beitragende, wenn sie nach Antworten suchen – oder um in kurzen Pausen +fragenden Nutzern zu helfen. In diesem monatlichen Beitrag heben wir einige +der am besten bewerteten Fragen und Antworten seit unserem letzten Update hervor.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Auswirkungen der OP_RETURN-Änderungen in der kommenden Bitcoin Core-Version 30.0?]({{bse}}127895) + Pieter Wuille erläutert seine Sicht auf Vor- und Nachteile der Nutzung von + Mempool- und Relay-Policy, um den Inhalt geminter Blöcke zu beeinflussen + ([policy series]). + +- [Wenn OP_RETURN-Relay-Limits unwirksam sind: Warum das Schutzmittel entfernen statt es als Standardabschreckung zu belassen?]({{bse}}127904) + Antoine Poinsot erklärt den Fehlanreiz, den der aktuelle Standardwert für + OP_RETURN in Bitcoin Core erzeugt, und die Gründe für dessen Entfernung. + +- [Was sind Worst-Case-Stress-Szenarien durch unbeschränkte OP_RETURNs in Bitcoin Core v30?]({{bse}}127914) + Vojtěch Strnad und Pieter Wuille gehen auf eine Liste extremer Szenarien ein, + die durch die Änderung der Standard-Policy für OP_RETURN entstehen könnten. + +- [Wenn OP_RETURN mehr Platz gebraucht hätte: Warum wurde das 80-Byte-Limit entfernt statt auf 160 erhöht?]({{bse}}127915) + Ava Chow und Antoine Poinsot führen Gründe gegen einen Standardwert von 160 + Bytes an, darunter die Abneigung, das Limit ständig anheben zu müssen, dass + große Miner das Limit ohnehin umgehen, und Risiken, künftige On-Chain-Aktivität + nicht ausreichend zu antizipieren. + +- [Wenn beliebige Daten unvermeidlich sind: Führt das Entfernen des OP_RETURN-Limits zu mehr schädlichen Speicherpraktiken (z. B. UTXO-aufblähende Adressen)?]({{bse}}127916) + Ava Chow weist darauf hin, dass das Entfernen des OP_RETURN-Limits Anreize + schafft, für bestimmte Anwendungsfälle eine weniger schädliche Alternative zur + Speicherung von Ausgabedaten zu nutzen. + +- [Wenn OP_RETURN-Uncapping das UTXO-Set nicht vergrößert: Wie trägt es trotzdem zu Blockchain-Bloat und Zentralisierungsdruck bei?]({{bse}}127912) + Ava Chow erklärt, wie vermehrte Nutzung von OP_RETURN-Ausgaben die + Ressourcenbelastung von Bitcoin-Knoten erhöht. + +- [Wie beeinflusst das Aufheben der OP_RETURN-Begrenzung die langfristige Qualität des Fee-Markts und das Security-Budget?]({{bse}}127906) + Ava Chow beantwortet mehrere Fragen zu hypothetischer OP_RETURN-Nutzung und + deren Auswirkungen auf zukünftige Mining-Einnahmen. + +- [Ist die Blockchain vor illegalen Inhalten bei 100KB OP_RETURN geschützt?]({{bse}}127958) + Nutzer jb55 liefert mehrere Beispiele möglicher Kodierschemata und kommt zu + dem Schluss: "Nein, im Allgemeinen kann man solche Dinge in einem zensurresistenten, + dezentralen Netzwerk nicht wirklich verhindern." + +- [Welche Analyse zeigt, dass OP_RETURN-Uncapping die Block-Propagation oder das Orphan-Risiko nicht verschlechtert?]({{bse}}127905) + Ava Chow weist darauf hin, dass es zwar keinen Datensatz gibt, der speziell + große OP_RETURNs isoliert, frühere Analysen zu [compact blocks][topic compact block + relay] und Stale-Blocks jedoch keinen Grund liefern, ein anderes Verhalten zu erwarten. + +- [Wo speichert Bitcoin Core die XOR-Obfuskationsschlüssel für Blockdaten-Dateien und LevelDB-Indizes?]({{bse}}127927) + Vojtěch Strnad erklärt, dass der Chainstate-Schlüssel in LevelDB unter dem + Schlüssel "\000obfuscate_key" liegt, während der Schlüssel für Block- und + Undo-Daten in der Datei blocks/xor.dat gespeichert wird. + +- [Wie robust ist der 1p1c-Transaction-Relay in Bitcoin Core 28.0?]({{bse}}127873) + Glozow stellt klar, dass mit "nicht robust" in dem ursprünglichen PR zum + opportunistischen "one parent one child (1P1C) relay" gemeint ist, dass das + Verhalten nicht garantiert funktioniert, besonders in Gegenwart von + Angreifern oder bei sehr hohem Transaktionsaufkommen. + +- [Wie kann ich getblocktemplate erlauben, Transaktionen unter 1 sat/vbyte einzuschließen?]({{bse}}127881) + Nutzer inersha beschreibt die nötigen Einstellungen, um nicht nur sub-1-sat/vbyte + Transaktionen weiterzuleiten, sondern diese auch in einem Kandidatenblock-Template + aufzunehmen. + +## Releases und Release-Kandidaten + +_Neue Releases und Release-Kandidaten für verbreitete Bitcoin-Infrastrukturprojekte. +Bitte erwägen Sie ein Upgrade auf neue Releases oder helfen Sie beim Testen von Release-Candidates._ + +- [Bitcoin Core 30.0rc1][] ist ein Release Candidate für die nächste + Hauptversion der vollständigen Verifikations-Knoten-Software. Siehe bitte den + [Testing-Guide für Version 30][bcc30 testing]. + +## Wichtige Code- und Dokumentationsänderungen + +_Bemerkenswerte Änderungen in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning +BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und +[BINANAs][binana repo]._ + +- [Bitcoin Core #33333][] gibt nun eine Startwarnung aus, wenn die `dbcache` + Einstellung eines Knotens einen Schwellenwert überschreitet, der aus dem + verfügbaren Arbeitsspeicher des Systems abgeleitet wird. Das soll + Out-of-Memory-Fehler oder intensives Swapping verhindern. Für Systeme mit + weniger als 2 GB RAM liegt die `dbcache`-Warnschwelle bei 450 MB; andernfalls + beträgt die Schwelle 75 % des gesamten RAM. Das frühere `dbcache`-Limit von + 16 GB wurde im September 2024 entfernt (siehe [Newsletter #321][news321 dbcache]). + +- [Bitcoin Core #28592][] erhöht die pro-Peer-Transaktions-Relay-Rate für + eingehende Verbindungen von 7 auf 14, um der gestiegenen Präsenz kleinerer + Transaktionen im Netzwerk Rechnung zu tragen. Für ausgehende Peers ist die + Rate 2,5-mal höher und steigt auf 35 Transaktionen pro Sekunde. Die Relay-Rate + begrenzt, wie viele Transaktionen ein Knoten seinen Peers sendet. + +- [Eclair #3171][] entfernt `PaymentWeightRatios`, eine Pfadfindungsmethode, + die Uniformität in Kanal-Balances annahm, und ersetzt sie durch einen + neu eingeführten probabilistischen Ansatz, der auf vergangenen Zahlungsversuchen + basiert (siehe [Newsletter #371][news371 path]). + +- [Eclair #3175][] lehnt nun unbezahllbare [BOLT12][] [Offers][topic offers] + ab, bei denen die Felder `offer_chains`, `offer_paths`, `invoice_paths` und + `invoice_blindedpay` vorhanden, aber leer sind. + +- [LDK #4064][] aktualisiert die Signaturprüfungslogik, sodass, wenn das Feld + `n` (Payee-Pubkey) vorhanden ist, die Signatur gegen diesen Wert verifiziert + wird. Andernfalls wird der Pubkey des Empfängers aus der [BOLT11][] Invoice + extrahiert; sowohl High-S- als auch Low-S-Signaturen werden berücksichtigt. + Dieser PR bringt die Prüfungen in Einklang mit dem vorgeschlagenen [BOLTs #1284][] + und anderen Implementierungen wie Eclair (siehe [Newsletter #371][news371 pubkey]). + +- [LDK #4067][] fügt Unterstützung dafür hinzu, [P2A ephemeral anchor][topic + ephemeral anchors] Ausgaben aus [zero-fee commitment][topic v3 commitments] + Transaktionen auszugeben, sodass Kanalpartner ihre Mittel on-chain zurückfordern + können. Siehe [Newsletter #371][news371 p2a] für LDKs Implementierung von + Zero-Fee-Commitment-Kanälen. + +- [LDK #4046][] ermöglicht es einem häufig offline befindlichen Sender, [async payments][topic + async payments] an einen häufig offline befindlichen Empfänger zu senden. Der Sender setzt + ein Flag in der `update_add_htlc` Nachricht, damit das [HTLC][topic htlc] + beim LSP gehalten wird, bis der Empfänger wieder online ist und eine + `release_held_htlc` [Onion-Nachricht][topic onion messages] sendet, um die + Zahlung zu beanspruchen. + +- [LDK #4083][] markiert den Endpoint `pay_for_offer_from_human_readable_name` + als veraltet, um doppelte [BIP353][] HRN-Zahlungs-APIs zu entfernen. Wallets + sollten die `bitcoin-payment-instructions`-Crate verwenden, um Zahlungsanweisungen + zu parsen und aufzulösen, bevor sie `pay_for_offer_from_hrn` aufrufen (z. B. + satoshi@nakamoto.com). + +- [LND #10189][] aktualisiert sein `sweeper`-System (siehe [Newsletter #346][news346 + sweeper]), sodass der Fehlercode `ErrMinRelayFeeNotMet` korrekt erkannt wird + und fehlgeschlagene Transaktionen durch erneutes Senden mit erhöhter Gebühr + ([Fee Bumping][topic rbf]) solange neu versucht werden, bis die Übertragung + erfolgreich ist. Zuvor wurde der Fehler falsch zugeordnet, sodass kein Retry + erfolgte. Außerdem verbessert der PR die Gewichtsschätzung, indem ein mögliches + zusätzliches Change-Output berücksichtigt wird; relevant für Taproot-Overlay-Kanäle + und LNDs [Taproot Assets][topic client-side validation]. + +- [BIPs #1963][] ändert den Status der BIPs, die kompakte Blockfilter spezifizieren + ([BIP157][] und [BIP158][]) von `Draft` zu `Final`, da sie seit 2020 in + Bitcoin Core und anderer Software eingesetzt werden. + +{% include snippets/recap-ad.md when="2025-09-30 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="33333,28592,3171,3175,4064,4067,4046,4083,10189,1963,1284" %} +[morehouse eclair]: https://delvingbitcoin.org/t/disclosure-eclair-preimage-extraction-exploit/2010 +[brozzoni feefilter]: https://delvingbitcoin.org/t/measuring-minrelaytxfee-across-the-bitcoin-network/1989 +[0xb10c feefilter]: https://delvingbitcoin.org/t/measuring-minrelaytxfee-across-the-bitcoin-network/1989/3 +[bitcoin core 30.0rc1]: https://bitcoincore.org/bin/bitcoin-core-30.0/ +[bcc30 testing]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/30.0-Release-Candidate-Testing-Guide/ +[news321 dbcache]: /en/newsletters/2024/09/20/#bitcoin-core-28358 +[news371 path]: /de/newsletters/2025/09/12/#eclair-2308 +[news371 pubkey]: /de/newsletters/2025/09/12/#eclair-3163 +[news371 p2a]: /de/newsletters/2025/09/12/#ldk-4053 +[news346 sweeper]: /de/newsletters/2025/03/21/#diskussion-zum-dynamischen-feerate-anpassungssystem-in-lnd +[policy series]: /en/blog/waiting-for-confirmation/ +[28.0 1p1c]: /en/bitcoin-core-28-wallet-integration-guide/#one-parent-one-child-1p1c-relay From 3785e04ddd9c27f2b3665a3a4969efa2f719cf54 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Mon, 29 Sep 2025 09:51:04 -0500 Subject: [PATCH 273/278] Newsletters: add 374 (2025-10-03) --- .../en/newsletters/2025-10-03-newsletter.md | 46 +++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 _posts/en/newsletters/2025-10-03-newsletter.md diff --git a/_posts/en/newsletters/2025-10-03-newsletter.md b/_posts/en/newsletters/2025-10-03-newsletter.md new file mode 100644 index 0000000000..164c232242 --- /dev/null +++ b/_posts/en/newsletters/2025-10-03-newsletter.md @@ -0,0 +1,46 @@ +--- +title: 'Bitcoin Optech Newsletter #374' +permalink: /en/newsletters/2025/10/03/ +name: 2025-10-03-newsletter +slug: 2025-10-03-newsletter +type: newsletter +layout: newsletter +lang: en +--- +FIXME:schmidty + +## News + +FIXME:harding + +## Changing consensus + +_A monthly section summarizing proposals and discussion about changing +Bitcoin's consensus rules._ + +FIXME:harding + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +FIXME:Gustavojfe + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +FIXME:Gustavojfe + +{% include snippets/recap-ad.md when="2025-10-07 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="" %} From 13210425237ebaa3b36d5304c321bf9cf4b9cfa0 Mon Sep 17 00:00:00 2001 From: Brandon Black Date: Mon, 29 Sep 2025 21:46:31 -0700 Subject: [PATCH 274/278] News374: add changing consensus GSR BIPs --- .../en/newsletters/2025-10-03-newsletter.md | 65 ++++++++++++++++++- 1 file changed, 64 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2025-10-03-newsletter.md b/_posts/en/newsletters/2025-10-03-newsletter.md index 164c232242..f087093f60 100644 --- a/_posts/en/newsletters/2025-10-03-newsletter.md +++ b/_posts/en/newsletters/2025-10-03-newsletter.md @@ -18,7 +18,61 @@ FIXME:harding _A monthly section summarizing proposals and discussion about changing Bitcoin's consensus rules._ -FIXME:harding +- **Draft BIPs for Script Restoration:** Rusty Russell posted to the Bitcoin-Dev mailing list a [summary][rr0] + and four BIPs ([1][rr1], [2][rr2], [3][rr3], [4][rr4]) in various stages of + draft relating to a proposal to restore Script's capabilities in a new + [tapscript][topic tapscript] version. Russell has previously [spoken][rr atx] and [written][rr + blog] about these ideas. Briefly, this proposal aims to restore enhanced programmability + (including [covenant][topic covenants] functionality) to Bitcoin while avoiding some + of the trade-offs required in more narrowly scoped proposals. + + - _Varops budget for script runtime constraint:_ The [first BIP][rr1] is + fairly complete and proposes assigning a cost metric to nearly all Script + operations, similar to the SegWit sigops budget. For most operations in + Script the cost is based on the number of bytes written to the node's RAM + during execution of the opcode by a naive implementation. Unlike the sigops + budget, the cost for each opcode depends on the size of its inputs - hence + the name "varops". With this unified cost model, many limits currently used + to protect nodes from excessive Script validation cost can be raised to the + point that they are impossible or nearly impossible to hit in practical + scripts. + + - _Restoration of disabled script functionality (tapscript v2):_ The [second BIP][rr2] + is also fairly complete (aside from a reference implementation) and + details the restoration of opcodes [removed][misc changes] from Script back + in 2010, as required to protect the Bitcoin network from excessive Script + validation cost. With the varops budget in place, all of these opcodes (or + updated versions of them) can be restored, limits can be raised, and numbers + can be made arbitrary length. + + - _OP_TX:_ The [third BIP][rr3] is a proposal for a new general + introspection opcode. `OP_TX` allows the caller to get nearly any item or + items from the transaction into the script stack. By providing direct access to the + spending transaction, this opcode enables any covenant + functionality possible with opcodes such as `OP_TEMPLATEHASH` or + [`OP_CHECKTEMPLATEVERIFY`][topic op_checktemplateverify]. + + - _New opcodes for tapscript v2:_ The [final BIP][rr4] proposes new + opcodes which round out the functionality that was either missing or not + needed when Bitcoin was first launched. For example, adding the ability to + manipulate taptrees and taproot outputs was not necessary at Bitcoin's + introduction, but in a world with restored Script it makes sense to have + these capabilities as well. Brandon Black [noted][bb1] an omission in the + specified opcodes needed to fully construct taproot outputs. Two of the + proposed opcodes seem likely to require their own full BIPs: `OP_MULTI` and + `OP_SEGMENT`. + + `OP_MULTI` modifies the subsequent opcode to operate on more than its standard + number of stack items, enabling (for example) a script to add up a variable + number of items. This avoids the need for a looping construct in Script or for + an `OP_VAULT` style deferred check while enabling value flow control and + similar logic. + + `OP_SEGMENT` (if present) modifies the behavior of `OP_SUCCESS` such that + instead of the whole script succeeding if an `OP_SUCCESS` is present, only the + segment succeeds (bounded by script start, `OP_SEGMENT`, ..., and script end). + This enables the possibility of scripts with a required prefix, including + `OP_SEGMENT`, and an untrusted suffix. ## Releases and release candidates @@ -44,3 +98,12 @@ FIXME:Gustavojfe {% include snippets/recap-ad.md when="2025-10-07 16:30" %} {% include references.md %} {% include linkers/issues.md v=2 issues="" %} +[rr0]: https://gnusha.org/pi/bitcoindev/877bxknwk6.fsf@rustcorp.com.au/ +[rr1]: https://gnusha.org/pi/bitcoindev/874isonniq.fsf@rustcorp.com.au/ +[rr2]: https://gnusha.org/pi/bitcoindev/871pnsnnhh.fsf@rustcorp.com.au/ +[rr3]: https://gnusha.org/pi/bitcoindev/87y0q0m8vz.fsf@rustcorp.com.au/ +[rr4]: https://gnusha.org/pi/bitcoindev/87tt0om8uz.fsf@rustcorp.com.au/ +[rr atx]: https://www.youtube.com/watch?v=rSp8918HLnA +[rr blog]: https://rusty.ozlabs.org/2024/01/19/the-great-opcode-restoration.html +[bb1]: https://gnusha.org/pi/bitcoindev/aNsORZGVc-1_-z1W@console/ +[misc changes]: https://github.com/bitcoin/bitcoin/commit/6ac7f9f144757f5f1a049c059351b978f83d1476 From a61c6a3e941a3f8b5df4d6548c95d34f60437db9 Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 2 Oct 2025 04:35:13 +0000 Subject: [PATCH 275/278] News374: add merge summaries --- .../en/newsletters/2025-10-03-newsletter.md | 98 ++++++++++++++++++- 1 file changed, 93 insertions(+), 5 deletions(-) diff --git a/_posts/en/newsletters/2025-10-03-newsletter.md b/_posts/en/newsletters/2025-10-03-newsletter.md index f087093f60..19bbd5ac7c 100644 --- a/_posts/en/newsletters/2025-10-03-newsletter.md +++ b/_posts/en/newsletters/2025-10-03-newsletter.md @@ -7,11 +7,14 @@ type: newsletter layout: newsletter lang: en --- -FIXME:schmidty +This week's newsletter includes our regular sections summarizing +discussion about changing Bitcoin's consensus rules, announcing new +release and release candidates, and describing notable changes to +popular Bitcoin infrastructure software. ## News -FIXME:harding +_No significant news this week was found in any of our [sources][optech sources]._ ## Changing consensus @@ -80,7 +83,21 @@ _New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates._ -FIXME:Gustavojfe +- [Bitcoin Core 30.0rc2][] is a release candidate for the next major version of + this full verification node software. Please see the [version 30 release + candidate testing guide][bcc30 testing]. + +- [bdk-wallet 2.2.0][] is a minor release of this library used for building + wallet applications that introduces a new feature that returns events upon + applying an update, new test facilities for test persistence, and + documentation improvements. + +- [LND v0.20.0-beta.rc1][] is a release candidate for a new version of this + popular LN node implementation that introduces multiple bug fixes, persistence + of node announcement settings across restarts, a new `noopAdd` [HTLC][topic + htlc] type, support for [P2TR][topic taproot] fallback addresses on [BOLT11][] + invoices, and an experimental `XFindBaseLocalChanAlias` endpoint, among many + other changes. ## Notable code and documentation changes @@ -93,11 +110,68 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -FIXME:Gustavojfe +- [Bitcoin Core #33229][] implements automatic multiprocess selection for + inter-process communication (IPC) (see [Newsletter #369][news369 ipc]), + allowing users to skip specifying the `-m` startup option when IPC arguments + are passed or IPC configurations are set. This change simplifies the + integration of Bitcoin Core with an external [Stratum v2][topic pooled mining] + mining service that creates, manages and submits block templates. + +- [Bitcoin Core #33446][] fixes a bug introduced when the `target` field was + added to the responses of the `getblock` and `getblockheader` commands (see + [Newsletter #339][news339 target]). Instead of always incorrectly returning + the chain tip’s target, it now returns the requested block’s target. + +- [LDK #3838][] adds support for the `client_trusts_lsp` model for [JIT + channels][topic jit channels], as specified in [BLIP52][] (LSPS2) (see + [Newsletter #335][news335 blip]), on top of already supporting the + `lsp_trusts_client` model. With the new model, the LSP will not broadcast the + on-chain funding transaction until the receiver reveals the preimage required + to claim the [HTLC][topic htlc]. + +- [LDK #4098][] updates the implementation of the `next_funding` TLV in the + `channel_reestablish` flow for [splicing][topic splicing] transactions, to + align with the proposed specification change in [BOLTs #1289][]. This PR + follows the recent work on `channel_reestablish` covered in [Newsletter + #371][news371 splicing]. + +- [LDK #4106][] fixes a race condition in which an [HTLC][topic htlc] held by an + LSP on behalf of an [async payment][topic async payments] recipient would fail + to be released because the LSP could not locate it. This occurred when the LSP + received the `release_held_htlc` [onion message][topic onion messages] (see + Newsletters [#372][news372 async] and [#373][news373 async]) before the HTLC + was moved from the pre-decode map to the `pending_intercepted_htlcs` map. LDK + now checks both maps, rather than just the latter one, to ensure the HTLC is + found and released properly. + +- [LDK #4096][] changes the per-peer outbound [gossip][topic channel + announcements] queue from a 24-message limit to a 128 KB size limit. If the + total number of bytes currently queued for a given peer exceeds this limit, + new gossip forwards to that peer are skipped until the queue drains. This new + limit significantly reduces missed forwards, and is particularly relevant + because when messages vary in size. + +- [LND #10133][] adds the experimental `XFindBaseLocalChanAlias` RPC endpoint, + which returns a base SCID for a specified SCID alias (see [Newsletter + #203][news203 alias]). This PR also extends the alias manager to persist the + reverse mapping when aliases are created, enabling the new endpoint. + +- [BDK #2029][] introduces the `CanonicalView` struct, which performs a one-time + canonicalization of a wallet’s `TxGraph` at a given chaintip. This snapshot + powers all subsequent queries, eliminating the need for re-canonicalization + with every call. Methods that required canonicalization now have + `CanonicalView` equivalents, and `TxGraph` methods that took a fallible + `ChainOracle` are removed. See Newsletters [#335][news335 txgraph] and + [#346][news346 txgraph] for previous canonicalization work on BDK. + +- [BIPs #1911][] marks [BIP21][] as replaced by [BIP321][] and updates + [BIP321][]’s status from `Draft` to `Proposed`. [BIP321][] proposes a modern + URI scheme for describing bitcoin payment instructions, see [Newsletter + #352][news352 bip321] for more details. {% include snippets/recap-ad.md when="2025-10-07 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="" %} +{% include linkers/issues.md v=2 issues="33229,33446,3838,4098,4106,4096,10133,2029,1911,1289" %} [rr0]: https://gnusha.org/pi/bitcoindev/877bxknwk6.fsf@rustcorp.com.au/ [rr1]: https://gnusha.org/pi/bitcoindev/874isonniq.fsf@rustcorp.com.au/ [rr2]: https://gnusha.org/pi/bitcoindev/871pnsnnhh.fsf@rustcorp.com.au/ @@ -107,3 +181,17 @@ FIXME:Gustavojfe [rr blog]: https://rusty.ozlabs.org/2024/01/19/the-great-opcode-restoration.html [bb1]: https://gnusha.org/pi/bitcoindev/aNsORZGVc-1_-z1W@console/ [misc changes]: https://github.com/bitcoin/bitcoin/commit/6ac7f9f144757f5f1a049c059351b978f83d1476 +[bitcoin core 30.0rc2]: https://bitcoincore.org/bin/bitcoin-core-30.0/ +[bcc30 testing]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/30.0-Release-Candidate-Testing-Guide/ +[bdk-wallet 2.2.0]: https://github.com/bitcoindevkit/bdk_wallet/releases/tag/wallet-2.2.0 +[LND v0.20.0-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.20.0-beta.rc1 +[news369 ipc]: /en/newsletters/2025/08/29/#bitcoin-core-31802 +[news339 target]: /en/newsletters/2025/01/31/#bitcoin-core-31583 +[news335 blip]: /en/newsletters/2025/01/03/#blips-54 +[news371 splicing]: /en/newsletters/2025/09/12/#ldk-3886 +[news372 async]: /en/newsletters/2025/09/19/#ldk-4045 +[news373 async]: /en/newsletters/2025/09/26/#ldk-4046 +[news203 alias]: /en/newsletters/2022/06/08/#bolts-910 +[news335 txgraph]: /en/newsletters/2025/01/03/#bdk-1670 +[news346 txgraph]: /en/newsletters/2025/03/21/#bdk-1839 +[news352 bip321]: /en/newsletters/2025/05/02/#bips-1555 \ No newline at end of file From 2d1786606d40ca0dc91777f799fb6550cf5c7adf Mon Sep 17 00:00:00 2001 From: azuchi Date: Fri, 3 Oct 2025 20:56:01 +0900 Subject: [PATCH 276/278] Newsletter-374:Translate into Japanese --- .../ja/newsletters/2025-10-03-newsletter.md | 172 ++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 _posts/ja/newsletters/2025-10-03-newsletter.md diff --git a/_posts/ja/newsletters/2025-10-03-newsletter.md b/_posts/ja/newsletters/2025-10-03-newsletter.md new file mode 100644 index 0000000000..ef6be4cac4 --- /dev/null +++ b/_posts/ja/newsletters/2025-10-03-newsletter.md @@ -0,0 +1,172 @@ +--- +title: 'Bitcoin Optech Newsletter #374' +permalink: /ja/newsletters/2025/10/03/ +name: 2025-10-03-newsletter-ja +slug: 2025-10-03-newsletter-ja +type: newsletter +layout: newsletter +lang: ja +--- +今週のニュースレターでは、Bitcoinのコンセンサスルールの変更に関する議論の要約や、 +新しいリリースとリリース候補の発表、人気のBitcoinインフラストラクチャソフトウェアの注目すべき更新など、 +恒例のセクションが含まれています。 + +## ニュース + +_今週は、どの[情報源][optech sources]からも重要なニュースは見つかりませんでした。_ + +## コンセンサスの変更 + +_Bitcoinのコンセンサスルールの変更に関する提案と議論をまとめた月次セクション_ + +- **スクリプトを復元するためのBIPドラフト:** Rusty Russellは、 + 新しい[Tapscript][topic tapscript]バージョンで、スクリプトの機能を復元する提案の[概要][rr0]と、 + 様々な段階にある４つのBIP（[1][rr1]、[2][rr2]、[3][rr3]、[4][rr4]）を + Bitcoin-Devメーリングリストに投稿しました。Russellは以前にもこれらのアイディアについて + [講演][rr atx]や[記事を書いています][rr blog]。この提案は、簡単に言うと、 + より範囲を限定した提案で必要とされるトレードオフの一部を回避しながら、 + Bitcoinに（[コベナンツ][topic covenants]の機能を含む）プログラムの拡張を取り戻すことを目的としています。 + + - _スクリプト実行時制約用のvaropsバジェット:_ [最初のBIP][rr1]はかなり完成度が高く、 + Segwitのsigopsバジェットに似たコストメトリクスをほぼすべてのスクリプト操作に割り当てることを提案しています。 + スクリプトのほとんどの操作では、コストは単純な実装により + opcode実行中にノードのRAMに書き込まれるデータのバイト数に基づきます。sigopsバジェットとは異なり、 + 各opcodeのコストは、入力のサイズに依存します。これが「varops」と名付けられた理由です。 + この統一コストモデルにより、現在ノードを過剰なスクリプト検証コストから保護するために使われている多くの制限を、 + 実用的なスクリプトでは到達不可能またはほぼ不可能なレベルまで引き上げることができます。 + + - _無効化されたスクリプト機能の復元（Tapscript v2）:_ [2つめのBIP][rr2]も、 + （参照実装を除いて）かなり完成度が高く、Bitcoinネットワークを過度なスクリプト検証コストから保護するために + 2010年に[削除された][misc changes]opcodeの復元について記述しています。 + varopsバジェットが導入されることで、これらのopcode（またはその更新版）をすべて復元でき、 + その制限を引き上げることができ、数値を任意の長さにすることができます。 + + - _OP_TX:_ [3つめのBIP][rr3]は、新しい汎用イントロスペクションopcodeの提案です。 + `OP_TX`により、呼び出し元はトランザクションのほぼすべての要素をスクリプトスタックに取得できるようになります。 + 支払いトランザクションへの直接のアクセスを可能にすることで、 + このopcodeは`OP_TEMPLATEHASH`や[`OP_CHECKTEMPLATEVERIFY`][topic op_checktemplateverify]などの + opcodeで可能なあらゆるコベナンツ機能を実現します。 + + - _Tapscript v2用の新しいopcode:_ [最後のBIP][rr4]は、Bitcoinが最初にローンチされた際に欠けていた、 + またはその時点では必要なかった機能を補完するする新しいopcodeを提案しています。たとえば、 + TaptreeやTaprootアウトプットを操作する機能を追加することは、Bitcoin導入時には必要ありませんでしたが、 + スクリプトが復元された世界では、これらの機能を持つことも理にかなっています。Brandon Blackは、 + Taprootアウトプットを完全に構築するために必要なopcodeが不足していることを[指摘しました][bb1]。 + 提案されたopcodeのうち2つ（`OP_MULTI`と`OP_SEGMENT`）は、専用の完全なBIPが必要になりそうです。 + + `OP_MULTI`は、標準のスタックアイテム数よりも多くのアイテムで動作できるように、後続のopcodeを変更します。 + たとえばスクリプトで可変数のアイテムを加算することが可能になります。これにより、 + スクリプト内でループ構造や`OP_VAULT`スタイルの遅延チェックの必要性を回避しながら、 + 値のフロー制御や同様のロジックが可能になります。 + + `OP_SEGMENT`（が登場した場合）は、`OP_SUCCESS`の動作を変更します。 + `OP_SUCCESS`が登場した場合、スクリプト全体が成功するのではなく、 + セグメント（スクリプトの開始から`OP_SEGMENT`が登場し、スクリプトの終了）で区切られた部分のみが成功します。 + これにより、`OP_SEGMENT`を含む必須のプレフィックスと、信頼できないサフィックスを持つスクリプトが可能になります。 + +## リリースとリリース候補 + +_人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 +新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。_ + +- [Bitcoin Core 30.0rc2][]は、この完全な検証ノードソフトウェアの次期メジャーバージョンのリリース候補です。 + [バージョン30リリース候補のテストガイド][bcc30 testing]をご覧ください。 + +- [bdk-wallet 2.2.0][]は、ウォレットアプリケーション構築に使用されるこのライブラリのマイナーリリースです。 + アップデート適用時にイベントを返す新機能や、永続性テストのための新しいテスト機能の導入および + ドキュメントの改善が含まれています。 + +- [LND v0.20.0-beta.rc1][]は、この人気のLNノード実装の新バージョンのリリース候補です。 + 複数のバグ修正、再起動時のノードアナウンス設定の永続化、新しい`noopAdd`[HTLC][topic + htlc]タイプ、[BOLT11][]インボイスでの[P2TR][topic taproot]フォールバックアドレスのサポート、 + 実験的な`XFindBaseLocalChanAlias`エンドポイントおよび、その他多くの変更が導入されています。 + +## 注目すべきコードとドキュメントの変更 + +_最近の[Bitcoin Core][bitcoin core repo]、[Core +Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、 +[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet +Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay +Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement +Proposals（BIP）][bips repo]、[Lightning BOLTs][bolts repo]、 +[Bitcoin Inquisition][bitcoin inquisition repo]および[BINANAs][binana repo]の注目すべき変更点。_ + +- [Bitcoin Core #33229][]は、プロセス間通信（IPC）（[ニュースレター + #369][news369 ipc]参照）における自動マルチプロセス選択を実装し、 + IPC引数が渡されたり、IPC設定がされた場合に、ユーザーが起動時に`-m`オプションを指定する必要がなくなりました。 + この変更により、ブロックテンプレートの作成、管理、送信を行う + 外部の[Stratum v2][topic pooled mining]サービスとBitcoin Coreの統合が簡単になります。 + +- [Bitcoin Core #33446][]は、`getblock`コマンドと`getblockheader`コマンドの応答に + `target`フィールドを追加した際（[ニュースレター #339][news339 target]参照）に発生したバグを修正しました。 + これまでは常に先端のターゲットを誤って返していましたが、要求されたブロックのターゲットを返すようになりました。 + +- [LDK #3838][]は、既にサポートしている`lsp_trusts_client`モデルに加えて、 + [BLIP52][] (LSPS2)（[ニュースレター #335][news335 blip]参照）で定義されている + [JITチャネル][topic jit channels]用の`client_trusts_lsp`モデルもサポートするようになりました。 + 新しいモデルでは、LSPは、受信者が[HTLC][topic htlc]の請求に必要なプリイメージを公開するまで、 + オンチェーンファンディングトランザクションをブロードキャストしません。 + +- [LDK #4098][]は、[BOLTs #1289][]で提案された仕様変更に合わせて、 + [スプライシング][topic splicing]トランザクションの`channel_reestablish`フローにおける + `next_funding` TLVの実装を更新します。このPRは、 + [ニュースレター #371][news371 splicing]で取り上げられた`channel_reestablish`に関する作業に続くものです。 + +- [LDK #4106][]は、[非同期支払い][topic async payments]の受信者に代わってLSPが保持する[HTLC][topic htlc]が、 + LSPがHTLCを検出できないために開放されないという競合状態を修正します。これは、 + HTLCがpre-decodeマップから`pending_intercepted_htlcs`マップに移動される前に、 + LSPが`release_held_htlc`[オニオンメッセージ][topic onion messages]（ニュースレター + [#372][news372 async]および[#373][news373 async]参照）を受信した場合に発生していました。 + LDKは、HTLCが適切に検出され開放されることを確実にするために、 + 後者のマップだけでなく両方のマップをチェックするようになりました。 + +- [LDK #4096][]は、ピア毎のアウトバウンド[ゴシップ][topic channel + announcements]キューのサイズ制限を24メッセージから128KBに変更しました。 + 特定のピアのキューに現在格納されているバイト数の合計がこの制限を超える場合、 + そのピアへの新しいゴシップの転送はキューが空になるまでスキップされます。 + この新しい制限により、転送の失敗が大幅に減少します。特に、メッセージのサイズが変化する場合に有効です。 + +- [LND #10133][]は、指定されたSCIDエイリアス（[ニュースレター #203][news203 alias]参照）の + ベースSCIDを返す実験的な`XFindBaseLocalChanAlias` RPCエンドポイントを追加します。 + このPRはまた、エイリアスの作成時に逆マッピングを永続化するようにエイリアスマネージャーを拡張し、 + 新しいエンドポイントを有効にします。 + +- [BDK #2029][]は、`CanonicalView`構造体を導入しました。これは、 + 特定のチェーンの先端におけるウォレットの`TxGraph`を一度だけ正規化します。 + このスナップショットは、後続のすべてのクエリに適用され、呼び出しのたびに再度正規化を行う必要がなくなります。 + 正規化を必要としていたメソッドには現在`CanonicalView`と同等のものがあり、 + 誤りのある`ChainOracle`を引数とする`TxGraph`メソッドは削除されました。 + BDKにおける以前の正規化の作業については、ニュースレター[#335][news335 txgraph]および[#346][news346 txgraph]をご覧ください。 + +- [BIPs #1911][]では、[BIP21][]が[BIP321][]に置き換えられたことが示され、 + [BIP321][]のステータスが`Draft`から`Proposed`に更新されました。 + [BIP321][]は、Bitcoinの支払い指示を記述するための最新のURIスキームを提案しています。 + 詳細は、[ニュースレター #352][news352 bip321]をご覧ください。 + +{% include snippets/recap-ad.md when="2025-10-07 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="33229,33446,3838,4098,4106,4096,10133,2029,1911,1289" %} +[rr0]: https://gnusha.org/pi/bitcoindev/877bxknwk6.fsf@rustcorp.com.au/ +[rr1]: https://gnusha.org/pi/bitcoindev/874isonniq.fsf@rustcorp.com.au/ +[rr2]: https://gnusha.org/pi/bitcoindev/871pnsnnhh.fsf@rustcorp.com.au/ +[rr3]: https://gnusha.org/pi/bitcoindev/87y0q0m8vz.fsf@rustcorp.com.au/ +[rr4]: https://gnusha.org/pi/bitcoindev/87tt0om8uz.fsf@rustcorp.com.au/ +[rr atx]: https://www.youtube.com/watch?v=rSp8918HLnA +[rr blog]: https://rusty.ozlabs.org/2024/01/19/the-great-opcode-restoration.html +[bb1]: https://gnusha.org/pi/bitcoindev/aNsORZGVc-1_-z1W@console/ +[misc changes]: https://github.com/bitcoin/bitcoin/commit/6ac7f9f144757f5f1a049c059351b978f83d1476 +[bitcoin core 30.0rc2]: https://bitcoincore.org/bin/bitcoin-core-30.0/ +[bcc30 testing]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/30.0-Release-Candidate-Testing-Guide/ +[bdk-wallet 2.2.0]: https://github.com/bitcoindevkit/bdk_wallet/releases/tag/wallet-2.2.0 +[LND v0.20.0-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.20.0-beta.rc1 +[news369 ipc]: /ja/newsletters/2025/08/29/#bitcoin-core-31802 +[news339 target]: /ja/newsletters/2025/01/31/#bitcoin-core-31583 +[news335 blip]: /ja/newsletters/2025/01/03/#blips-54 +[news371 splicing]: /ja/newsletters/2025/09/12/#ldk-3886 +[news372 async]: /ja/newsletters/2025/09/19/#ldk-4045 +[news373 async]: /ja/newsletters/2025/09/26/#ldk-4046 +[news203 alias]: /ja/newsletters/2022/06/08/#bolts-910 +[news335 txgraph]: /ja/newsletters/2025/01/03/#bdk-1670 +[news346 txgraph]: /ja/newsletters/2025/03/21/#bdk-1839 +[news352 bip321]: /ja/newsletters/2025/05/02/#bips-1555 +[optech sources]: /ja/internal/sources \ No newline at end of file From e04bffca517f05d3e83198247f47ba23187b17fe Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Mon, 6 Oct 2025 16:34:20 +0200 Subject: [PATCH 277/278] Newsletter 373 translate in French (#2519) --- .../fr/newsletters/2025-09-26-newsletter.md | 191 ++++++++++++++++++ 1 file changed, 191 insertions(+) create mode 100644 _posts/fr/newsletters/2025-09-26-newsletter.md diff --git a/_posts/fr/newsletters/2025-09-26-newsletter.md b/_posts/fr/newsletters/2025-09-26-newsletter.md new file mode 100644 index 0000000000..fb0a37d06a --- /dev/null +++ b/_posts/fr/newsletters/2025-09-26-newsletter.md @@ -0,0 +1,191 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #373' +permalink: /fr/newsletters/2025/09/26/ +name: 2025-09-26-newsletter-fr +slug: 2025-09-26-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine résume une vulnérabilité affectant les anciennes versions d'Eclair et +résume les recherches sur les paramètres de taux de frais des nœuds complets. +Sont également incluses nos sections régulières résumant les récentes questions et réponses de Bitcoin +Stack Exchange, annoncant de nouvelles versions et des candidats à la publication, ainsi que les +résumés des modifications notables apportées aux logiciels d'infrastructure Bitcoin populaires. + +## Nouvelles + +- **Vulnérabilité Eclair :** Matt Morehouse a [posté][morehouse eclair] sur Delving Bitcoin pour + annoncer la [divulgation responsable][topic responsible disclosures] d'une vulnérabilité affectant + les anciennes versions d'Eclair. Il est recommandé à tous les utilisateurs d'Eclair de mettre à + niveau vers la version 0.12 ou supérieure. La vulnérabilité permettait à un attaquant de diffuser + une ancienne transaction d'engagement pour voler tous les fonds actuels d'un canal. En plus de + corriger la vulnérabilité, les développeurs d'Eclair ont ajouté une suite de tests complète conçue + pour détecter des problèmes similaires. + +- **Recherche sur les paramètres de taux de frais :** Daniela Brozzoni a [posté][brozzoni feefilter] + sur Delving Bitcoin les résultats d'un scan de près de 30 000 nœuds complets acceptant des + connexions entrantes. Chaque nœud a été interrogé sur son filtre de frais [BIP133][], qui indique le + taux de frais minimum auquel il acceptera actuellement de relayer des transactions non confirmées. + Lorsque les mémoires tampons des nœuds ne sont pas pleines, il s'agit du [taux de frais minimum de + relais de transaction par défaut du nœud][topic default minimum transaction relay feerates]. Ses + résultats indiquent que la plupart des nœuds utilisent le défaut de 1 sat/vbyte (s/v), qui est + depuis longtemps le défaut dans Bitcoin Core. Environ 4 % des nœuds utilisaient 0.1 s/v, le défaut + pour la version 30.0 à venir de Bitcoin Core, et environ 8 % des nœuds n'ont pas répondu à la + requête, indiquant qu'ils pourraient être des nœuds espions. + + Un petit pourcentage des nœuds utilisait une valeur de feefilter de 9 170 997 (10 000 s/v), valeur + que le développeur 0xB10C a [noté][0xb10c feefilter] être celle que Bitcoin Core définit, par + arrondissement, lorsque le nœud est à plus de 100 blocs derrière la pointe de la chaîne et se + concentre sur la réception de données de bloc plutôt que sur des transactions qui pourraient être + confirmées dans des blocs ultérieurs. + +## Questions et réponses sélectionnées de Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] est l'un des premiers endroits où les contributeurs d'Optech +cherchent des réponses à leurs questions---ou quand nous avons quelques moments libres pour aider +les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous mettons en lumière certaines +des questions et réponses les mieux votées postées depuis notre dernière mise à jour.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Implications des changements OP_RETURN dans la prochaine version 30.0 de Bitcoin Core ?]({{bse}}127895) + Pieter Wuille décrit ses perspectives sur l'efficacité et les inconvénients de l'utilisation de la + [politique de mempool et de relais][policy series] pour affecter le contenu des blocs minés. + +- [Si les limites de relais OP_RETURN sont inefficaces, pourquoi supprimer la protection au lieu de la conserver comme découragement par défaut ?]({{bse}}127904) + Antoine Poinsot explique le mauvais incitatif créé par la valeur limite par défaut actuelle + d'OP_RETURN dans Bitcoin Core et la raison de sa suppression. + +- [Quels sont les pires scénarios de stress pour les OP_RETURN non plafonnés dans Bitcoin Core v30 ?]({{bse}}127914) + Vojtěch Strnad et Pieter Wuille répondent à une liste de scénarios extrêmes qui + pourraient se produire avec le changement de politique de limite par défaut d'OP_RETURN. + +- [Si OP_RETURN avait besoin de plus d'espace, pourquoi le plafond de 80 octets a-t-il été supprimé au lieu d'être augmenté à 160 ?]({{bse}}127915) + Ava Chow et Antoine Poinsot exposent les considérations contre une valeur par défaut d'OP_RETURN + de 160 octets, incluant une aversion à fixer continuellement le plafond, les grands mineurs existants + contournant déjà le plafond, et les risques de ne pas anticiper l'activité future sur la chaîne. + +- [Si les données arbitraires sont inévitables, est-ce que supprimer les limites d'OP_RETURN déplace la demande vers des méthodes de stockage plus nuisibles (comme les adresses gonflant l'UTXO) ?]({{bse}}127916) + Ava Chow souligne que la suppression de la limite d'OP_RETURN offre des incitations à utiliser une + alternative moins nuisible pour le stockage des données de sortie dans certaines situations. + +- [Si le déplafonnement d'OP_RETURN n'augmente pas l'ensemble UTXO, comment contribue-t-il encore au gonflement de la blockchain et à la pression de centralisation ?]({{bse}}127912) + Ava Chow explique comment l'utilisation accrue des sorties OP_RETURN affecte l'utilisation des + ressources des nœuds Bitcoin. + +- [Comment le déplafonnement d'OP_RETURN impacte-t-il la qualité du marché des frais à long terme et le budget de sécurité ?]({{bse}}127906) + Ava Chow répond à une série de questions sur l'utilisation hypothétique d'OP_RETURN et son impact + sur les revenus futurs de minage de Bitcoin. + +- [Assurance que la blockchain ne souffrira pas de contenu illégal avec OP_RETURN de 100KB ?]({{bse}}127958) + L'utilisateur jb55 fournit plusieurs exemples de schémas d'encodage possibles pour + les données, concluant "Donc non, en général, vous ne pouvez pas vraiment arrêter ce genre de choses + dans un réseau décentralisé résistant à la censure." + +- [Quelle analyse montre que le déplafonnement d'OP_RETURN ne nuira pas à la propagation des blocs ou au risque d'orphelins ?]({{bse}}127905) + Ava Chow souligne que bien qu'il n'existe pas de jeu de données isolant spécifiquement les grands + OP_RETURN, les analyses précédentes des [blocs compacts][topic compact block relay] et des blocs + obsolètes indiquent qu'il n'y a pas de raison de s'attendre à ce qu'ils se comportent différemment. + +- [Où Bitcoin Core conserve-t-il les clés d'obfuscation XOR pour les fichiers de données de blocs et les index de bases de données LevelDB ?]({{bse}}127927) + Vojtěch Strnad note que la clé chainstate est stockée dans LevelDB sous la clé "\000obfuscate_key" + et la clé de données de blocs et d'annulation est stockée dans le fichier blocks/xor.dat. + +- [Quelle est la robustesse de la transmission de transaction 1p1c dans bitcoin core 28.0 ?]({{bse}}127873) + Glozow clarifie que le manque de robustesse mentionné dans la PR originale de relai opportuniste + [one parent one child (1P1C)][28.0 1p1c] signifie "pas garanti de fonctionner, particulièrement + en présence d'adversaires ou lorsque le volume est vraiment élevé donc nous manquons des choses." + +- [Comment puis-je permettre à getblocktemplate d'inclure des transactions sous 1 sat/vbyte ?]({{bse}}127881) + L'utilisateur inersha découvre les paramètres requis non seulement pour relayer des transactions + sous 1 sat/vbyte mais aussi pour les inclure dans un modèle de bloc candidat. + +## Mises à jour et versions candidates + +_Nouvelles versions et versions candidates pour des projets d'infrastructure Bitcoin populaires. +Veuillez envisager de mettre à niveau vers les nouvelles versions ou d'aider à tester les versions candidates._ + +- [Bitcoin Core 30.0rc1][] est un candidat à la version pour la prochaine version majeure de ce + logiciel de nœud de vérification complète. Veuillez consulter le [guide de test du candidat à la + version 30][bcc30 testing]. + +## Changements notables dans le code et la documentation + +_Changements notables récents dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core +lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], +[libsecp256k1][libsecp256k1 repo], [Interface de Portefeuille Matériel (HWI)][hwi repo], [Rust +Bitcoin][rust bitcoin repo], [Serveur BTCPay][btcpay server repo], [BDK][bdk repo], [Propositions +d'Amélioration de Bitcoin (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips +repo], [Inquisition Bitcoin][bitcoin inquisition repo], et [BINANAs][binana repo]._ + +- [Bitcoin Core #33333][] émet un message d'avertissement au démarrage si le paramètre `dbcache` + d'un nœud dépasse un plafond dérivé de la RAM système du nœud, pour prévenir les erreurs de manque + de mémoire ou un swapping intensif. Pour les systèmes avec moins de 2GB de RAM, le seuil + d'avertissement `dbcache` est de 450MB ; autrement, le seuil est de 75% de la RAM totale. La limite + de 16GB pour `dbcache` a été supprimée en septembre 2024 (voir le Bulletin [#321][news321 dbcache]). + +- [Bitcoin Core #28592][] augmente le taux de relais de transactions par pair de 7 à 14 pour les + pairs entrants en raison d'une présence accrue de transactions plus petites sur le réseau. Le taux + pour les pairs sortants est 2,5 fois plus élevé, passant à 35 transactions par seconde. Le taux de + relais de transactions limite le nombre de transactions qu'un nœud envoie à ses pairs. + +- [Eclair #3171][] supprime `PaymentWeightRatios`, une méthode de recherche de chemin qui supposait + une uniformité dans les soldes des canaux, et la remplace par une approche probabiliste nouvellement + introduite basée sur l'historique des tentatives de paiement passées (voir le Bulletin [#371][news371 + path]). + +- [Eclair #3175][] commence à rejeter les [offres][topic offers] [BOLT12][] impayables où les champs + `offer_chains`, `offer_paths`, `invoice_paths`, et `invoice_blindedpay` sont présents mais vides. + +- [LDK #4064][] met à jour sa logique de vérification de signature pour s'assurer que si le champ + `n` (clé publique du bénéficiaire) est présent, la signature est vérifiée contre celui-ci. Sinon, la + clé publique du bénéficiaire est extraite de la facture [BOLT11][] avec une signature high-S ou + low-S. Cette PR aligne les vérifications de signature avec les propositions [BOLTs #1284][] et avec + d'autres implémentations telles qu'Eclair (Voir le Bulletin [#371][news371 pubkey]). + +- [LDK #4067][] ajoute le support pour dépenser les sorties d'[ancres éphémères P2A][topic ephemeral + anchors] des transactions [d'engagement sans frais][topic v3 commitments], assurant + les pairs de canal peuvent récupérer leurs fonds onchain. Voir le Bulletin [#371][news371 + p2a] pour l'implémentation par LDK des canaux d'engagement sans frais. + +- [LDK #4046][] permet à un expéditeur souvent hors ligne d'envoyer des [paiements + asynchrones][topic async payments] à un destinataire souvent hors ligne. L'expéditeur définit un + drapeau dans le message `update_add_htlc` pour indiquer que le [HTLC][topic htlc] doit être retenu + par le LSP jusqu'à ce que le destinataire revienne en ligne et envoie un `release_held_htlc` + [message onion][topic onion messages] pour réclamer le paiement. + +- [LDK #4083][] déprécie le point de terminaison `pay_for_offer_from_human_readable_name` pour + supprimer les API de paiement HRN [BIP353][] en double. Les portefeuilles sont encouragés à utiliser + le crate `bitcoin-payment-instructions` pour analyser et résoudre les instructions de paiement avant + d'appeler `pay_for_offer_from_hrn` pour payer une [offre][topic offers] à partir d'un HRN [BIP353][] + (par exemple, satoshi@nakamoto.com). + +- [LND #10189][] met à jour son système `sweeper` (voir le Bulletin [#346][news346 sweeper]) pour + reconnaître correctement le code d'erreur `ErrMinRelayFeeNotMet` et réessayer les transactions + échouées par [augmentation des frais][topic rbf] jusqu'à ce que la diffusion soit réussie. + Auparavant, l'erreur serait mal appariée, et la transaction ne serait pas réessayée. Cette PR + améliore également l'estimation du poids en tenant compte d'une sortie de changement supplémentaire + possible, ce qui est pertinent dans les canaux d'overlay [taproot][topic taproot] utilisés pour + améliorer les [Taproot Assets][topic client-side validation] de LND. + +- [BIPs #1963][] met à jour le statut des BIPs qui spécifient les [filtres de blocs compacts][topic + compact block filters], [BIP157][] et [BIP158][], de `Draft` à `Final` car ils ont été déployés dans + Bitcoin Core et d'autres logiciels depuis 2020. + +{% include snippets/recap-ad.md when="2025-09-30 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="33333,28592,3171,3175,4064,4067,4046,4083,10189,1963,1284" %} +[morehouse eclair]: https://delvingbitcoin.org/t/disclosure-eclair-preimage-extraction-exploit/2010 +[brozzoni feefilter]: https://delvingbitcoin.org/t/measuring-minrelaytxfee-across-the-bitcoin-network/1989 +[0xb10c feefilter]: https://delvingbitcoin.org/t/measuring-minrelaytxfee-across-the-bitcoin-network/1989/3 +[bitcoin core 30.0rc1]: https://bitcoincore.org/bin/bitcoin-core-30.0/ +[bcc30 testing]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/30.0-Release-Candidate-Testing-Guide/ +[news321 dbcache]: /fr/newsletters/2024/09/20/#bitcoin-core-28358 +[news371 path]: /fr/newsletters/2025/09/12/#eclair-2308 +[news371 pubkey]: /fr/newsletters/2025/09/12/#eclair-3163 +[news371 p2a]: /fr/newsletters/2025/09/12/#ldk-4053 +[news346 sweeper]: /fr/newsletters/2025/03/21/#discussion-sur-le-systeme-de-reajustement-dynamique-du-taux-de-frais-de-lnd +[policy series]: /fr/blog/waiting-for-confirmation/ +[28.0 1p1c]: /fr/bitcoin-core-28-wallet-integration-guide/#relais-un-parent-un-enfant-1p1c From fad39778708b629c6841afbb03f52910e7fd075b Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Tue, 7 Oct 2025 13:20:03 -0500 Subject: [PATCH 278/278] Podcast: add 374 recap --- .../en/newsletters/2025-10-03-newsletter.md | 26 +++++++++---------- .../en/podcast/2025-10-07-newsletter-recap.md | 23 ++++++++++++++++ 2 files changed, 36 insertions(+), 13 deletions(-) create mode 100644 _posts/en/podcast/2025-10-07-newsletter-recap.md diff --git a/_posts/en/newsletters/2025-10-03-newsletter.md b/_posts/en/newsletters/2025-10-03-newsletter.md index 19bbd5ac7c..24da5ee8ca 100644 --- a/_posts/en/newsletters/2025-10-03-newsletter.md +++ b/_posts/en/newsletters/2025-10-03-newsletter.md @@ -75,7 +75,7 @@ Bitcoin's consensus rules._ instead of the whole script succeeding if an `OP_SUCCESS` is present, only the segment succeeds (bounded by script start, `OP_SEGMENT`, ..., and script end). This enables the possibility of scripts with a required prefix, including - `OP_SEGMENT`, and an untrusted suffix. + `OP_SEGMENT`, and an untrusted suffix. {% assign timestamp="0:40" %} ## Releases and release candidates @@ -85,19 +85,19 @@ release candidates._ - [Bitcoin Core 30.0rc2][] is a release candidate for the next major version of this full verification node software. Please see the [version 30 release - candidate testing guide][bcc30 testing]. + candidate testing guide][bcc30 testing]. {% assign timestamp="19:19" %} - [bdk-wallet 2.2.0][] is a minor release of this library used for building wallet applications that introduces a new feature that returns events upon applying an update, new test facilities for test persistence, and - documentation improvements. + documentation improvements. {% assign timestamp="23:39" %} - [LND v0.20.0-beta.rc1][] is a release candidate for a new version of this popular LN node implementation that introduces multiple bug fixes, persistence of node announcement settings across restarts, a new `noopAdd` [HTLC][topic htlc] type, support for [P2TR][topic taproot] fallback addresses on [BOLT11][] invoices, and an experimental `XFindBaseLocalChanAlias` endpoint, among many - other changes. + other changes. {% assign timestamp="24:15" %} ## Notable code and documentation changes @@ -115,25 +115,25 @@ repo], and [BINANAs][binana repo]._ allowing users to skip specifying the `-m` startup option when IPC arguments are passed or IPC configurations are set. This change simplifies the integration of Bitcoin Core with an external [Stratum v2][topic pooled mining] - mining service that creates, manages and submits block templates. + mining service that creates, manages and submits block templates. {% assign timestamp="25:03" %} - [Bitcoin Core #33446][] fixes a bug introduced when the `target` field was added to the responses of the `getblock` and `getblockheader` commands (see [Newsletter #339][news339 target]). Instead of always incorrectly returning - the chain tip’s target, it now returns the requested block’s target. + the chain tip’s target, it now returns the requested block’s target. {% assign timestamp="26:55" %} - [LDK #3838][] adds support for the `client_trusts_lsp` model for [JIT channels][topic jit channels], as specified in [BLIP52][] (LSPS2) (see [Newsletter #335][news335 blip]), on top of already supporting the `lsp_trusts_client` model. With the new model, the LSP will not broadcast the on-chain funding transaction until the receiver reveals the preimage required - to claim the [HTLC][topic htlc]. + to claim the [HTLC][topic htlc]. {% assign timestamp="28:11" %} - [LDK #4098][] updates the implementation of the `next_funding` TLV in the `channel_reestablish` flow for [splicing][topic splicing] transactions, to align with the proposed specification change in [BOLTs #1289][]. This PR follows the recent work on `channel_reestablish` covered in [Newsletter - #371][news371 splicing]. + #371][news371 splicing]. {% assign timestamp="30:40" %} - [LDK #4106][] fixes a race condition in which an [HTLC][topic htlc] held by an LSP on behalf of an [async payment][topic async payments] recipient would fail @@ -142,19 +142,19 @@ repo], and [BINANAs][binana repo]._ Newsletters [#372][news372 async] and [#373][news373 async]) before the HTLC was moved from the pre-decode map to the `pending_intercepted_htlcs` map. LDK now checks both maps, rather than just the latter one, to ensure the HTLC is - found and released properly. + found and released properly. {% assign timestamp="33:40" %} - [LDK #4096][] changes the per-peer outbound [gossip][topic channel announcements] queue from a 24-message limit to a 128 KB size limit. If the total number of bytes currently queued for a given peer exceeds this limit, new gossip forwards to that peer are skipped until the queue drains. This new limit significantly reduces missed forwards, and is particularly relevant - because when messages vary in size. + because when messages vary in size. {% assign timestamp="35:43" %} - [LND #10133][] adds the experimental `XFindBaseLocalChanAlias` RPC endpoint, which returns a base SCID for a specified SCID alias (see [Newsletter #203][news203 alias]). This PR also extends the alias manager to persist the - reverse mapping when aliases are created, enabling the new endpoint. + reverse mapping when aliases are created, enabling the new endpoint. {% assign timestamp="37:24" %} - [BDK #2029][] introduces the `CanonicalView` struct, which performs a one-time canonicalization of a wallet’s `TxGraph` at a given chaintip. This snapshot @@ -162,12 +162,12 @@ repo], and [BINANAs][binana repo]._ with every call. Methods that required canonicalization now have `CanonicalView` equivalents, and `TxGraph` methods that took a fallible `ChainOracle` are removed. See Newsletters [#335][news335 txgraph] and - [#346][news346 txgraph] for previous canonicalization work on BDK. + [#346][news346 txgraph] for previous canonicalization work on BDK. {% assign timestamp="39:08" %} - [BIPs #1911][] marks [BIP21][] as replaced by [BIP321][] and updates [BIP321][]’s status from `Draft` to `Proposed`. [BIP321][] proposes a modern URI scheme for describing bitcoin payment instructions, see [Newsletter - #352][news352 bip321] for more details. + #352][news352 bip321] for more details. {% assign timestamp="42:15" %} {% include snippets/recap-ad.md when="2025-10-07 16:30" %} {% include references.md %} diff --git a/_posts/en/podcast/2025-10-07-newsletter-recap.md b/_posts/en/podcast/2025-10-07-newsletter-recap.md new file mode 100644 index 0000000000..24c23240a3 --- /dev/null +++ b/_posts/en/podcast/2025-10-07-newsletter-recap.md @@ -0,0 +1,23 @@ +--- +title: 'Bitcoin Optech Newsletter #374 Recap Podcast' +permalink: /en/podcast/2025/10/07/ +reference: /en/newsletters/2025/10/03/ +name: 2025-10-07-recap +slug: 2025-10-07-recap +type: podcast +layout: podcast-episode +lang: en +--- +Mark “Murch” Erhardt and Mike Schmidt are joined by Gustavo Flores Echaiz to discuss [Newsletter #374]({{page.reference}}). + +{% include functions/podcast-links.md %} + +{% include functions/podcast-player.md url="https://d3ctxlq1ktw2nl.cloudfront.net/staging/2025-9-7/408836702-44100-2-7efee2f0dfaf6.m4a" %} + +{% include newsletter-references.md %} + +## Transcription + +_transcription coming soon_ + +{% include references.md %}