From 38756d6a3ad189e78490dcff1d3e9289a699def4 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Fri, 3 Dec 2021 15:17:27 -1000 Subject: [PATCH 01/10] Newsletters: add 178 (2021-12-08) --- .../en/newsletters/2021-12-08-newsletter.md | 108 ++++++++++++++++++ 1 file changed, 108 insertions(+) create mode 100644 _posts/en/newsletters/2021-12-08-newsletter.md diff --git a/_posts/en/newsletters/2021-12-08-newsletter.md b/_posts/en/newsletters/2021-12-08-newsletter.md new file mode 100644 index 0000000000..cf67a3f917 --- /dev/null +++ b/_posts/en/newsletters/2021-12-08-newsletter.md @@ -0,0 +1,108 @@ +--- +title: 'Bitcoin Optech Newsletter #178' +permalink: /en/newsletters/2021/12/08/ +name: 2021-12-08-newsletter +slug: 2021-12-08-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter describes a post about fee-bumping research and +contains our regular sections with the summary of a Bitcoin Core PR +Review Club meeting, the latest releases and RCs of Bitcoin software, +and notable changes to popular infrastructure projects. + +## News + +- **Fee bumping research:** Antoine Poinsot [posted][darosior bump] to + the Bitcoin-Dev mailing list a detailed description several concerns + developers need to consider when choosing how to fee-bump presigned + transactions used in [vaults][topic vaults] and contract protocols + such as LN. In particular, Poinsot looked at schemes for multiparty + protocols with more than two participants, for which the current [CPFP + carve out][topic cpfp carve out] transaction relay policy doesn't + work, requiring them to use [transaction replacement][topic rbf] + mechanisms that may be vulnerable to [transaction pinning][topic + transaction pinning]. Also included in his post is the result of + [research][revault research] into some of the ideas described earlier. + + Ensuring that fee bumping works reliability is a requirement for the + safety of most contract protocols, and it remains a problem without any + comprehensive solution yet. It is encouraging to see continuing + research into the problem. + +## 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:glozow + +{% include functions/details-list.md + q0="FIXME" + a0="FIXME" + a0link="https://bitcoincore.reviews/23173#l-FIXME" +%} + +## 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.* + +- [BDK 0.14.0][] is the latest release of this library for wallet + developers. It simplifies adding an `OP_RETURN` output to a + transaction and contains improvements for sending payments to + [bech32m][topic bech32] addresses for [taproot][topic taproot]. + +## Notable code and documentation changes + +*Notable changes this week in [Bitcoin Core][bitcoin core repo], +[C-Lightning][c-lightning repo], [Eclair][eclair repo], [LND][lnd repo], +[Rust-Lightning][rust-lightning 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], and +[Lightning BOLTs][bolts repo].* + +- [Bitcoin Core #23155][] rpc: various fixups for dumptxoutset FIXME:jnewbery + +- [Bitcoin Core #22513][] rpc: Allow walletprocesspsbt to sign without finalizing FIXME:adamjonas + +- [C-Lightning #4921][] updates the implementation of [onion + messages][topic onion messages] to match the latest updates to the + draft specifications for [route blinding][bolts #765] and [onion + messages][bolts #759]. + +- [C-Lightning #4829][] adds experimental support for the proposed + LN protocol change in [BOLTs #911][] that will allow nodes to advertise + their DNS address rather than their IP address or Tor onion service + address. + +- [Eclair #2061][] Relay onion messages FIXME:dongcarl + +- [Eclair #2073][] adds support for the optional channel type negotiation + feature bit as specified in draft [BOLTs #906][]. This corresponds + to LND's implementation of the same draft feature [last week][news177 + lnd6026]. + +- [Rust-Lightning #1163][] allows the remote party to set their channel + reserve below the dust limit, even all the way down to zero. In the + worst case, this allows the local node to costlessly attempt to steal + funds from a fully-spent channel---although such a theft attempt will + still fail if the remote party is monitoring their channels. By + default, most remote nodes discourage such attempts by setting a + reasonable channel reserve, but some Lightning Service Providers + (LSPs) use low or zero channel reserves order to provide users with a + better experience---allowing them to spend 100% of the funds in the + channel. Since only the remote node is taking any risk, there's no + problem allowing the local node to accept such channels. + + +{% include references.md %} +{% include linkers/issues.md issues="23155,22513,4921,4829,2061,2073,906,1163,765,759,911" %} +[bdk 0.14.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.14.0 +[news177 lnd6026]: /en/newsletters/2021/12/01/#lnd-6026 +[darosior bump]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019614.html +[revault research]: https://github.com/revault/research From 33a52f20f55073f6986937f99b697b4a21c37b93 Mon Sep 17 00:00:00 2001 From: glozow Date: Mon, 6 Dec 2021 14:07:21 +0000 Subject: [PATCH 02/10] news178: add review club summary --- .../en/newsletters/2021-12-08-newsletter.md | 52 +++++++++++++++++-- 1 file changed, 47 insertions(+), 5 deletions(-) diff --git a/_posts/en/newsletters/2021-12-08-newsletter.md b/_posts/en/newsletters/2021-12-08-newsletter.md index cf67a3f917..579f8f4b96 100644 --- a/_posts/en/newsletters/2021-12-08-newsletter.md +++ b/_posts/en/newsletters/2021-12-08-newsletter.md @@ -37,12 +37,49 @@ and notable changes to popular infrastructure projects. 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:glozow +[Treat Taproot as always active][review club #23512] is a PR by Marco Falke to +make transactions spending taproot outputs standard, regardless of taproot +deployment status. {% include functions/details-list.md - q0="FIXME" - a0="FIXME" - a0link="https://bitcoincore.reviews/23173#l-FIXME" + q0="Which areas in the codebase use the status of taproot deployment? Which of + them are policy related?" + a0="Prior to this PR, there are 4 areas: + [GetBlockScriptFlags()][GetBlockScriptFlags tap] (consensus), + [AreInputsStandard()][AreInputsStandard tap] (policy), + [getblockchaininfo()][getblockchaininfo tap] (rpc), and + [isTaprootActive()][isTaprootActive tap] (wallet)." + a0link="https://bitcoincore.reviews/23512#l-21" + + q1="What mempool validation function checks if a transaction spends a taproot + input? How does this PR change the function?" + a1="The function is [`AreInputsStandard()`][AreInputsStandard def]. The PR + removes the last argument, `bool taproot_active`, from the signature and returns + `true` for v1 segwit (taproot) spends regardless of taproot activation status. + Previously, the function would return false if it found a taproot output but + `taproot_active` was false, e.g. if the node were still in Initial Block + Download and syncing blocks before taproot activation." + a1link="https://bitcoincore.reviews/23512#l-40" + + q2="Are there any theoretical issues with the change? For wallet users, is + it possible to lose money?" + a2="With this change, the wallet allows importing taproot descriptors at any + time, i.e., even when taproot is not active and v1 segwit outputs can be spent + by anyone). This means it's possible to receive bitcoin at a taproot address + without taproot being active yet; if the chain also reorgs to a block prior to + 709,632, miners (or someone who can get a nonstandard transaction confirmed) can + steal those UTXOs." + a2link="https://bitcoincore.reviews/23512#l-82" + + q3="Theoretically, is it possible for a mainnet chain that has taproot + never-active or active at a different block height to exist?" + a3="Both are possible. If a very large reorg happened (forking off prior to + taproot lock-in), the deployment process would be repeated. In this new chain, + if the number of taproot-signaling blocks never met the threshold, the (still + valid) chain would never activate taproot. If the threshold were reached after + the min activation height but before the timeout, taproot could also activate + at a later height." + a3link="https://bitcoincore.reviews/23512#l-130" %} ## Releases and release candidates @@ -101,8 +138,13 @@ repo], [Hardware Wallet Interface (HWI)][hwi repo], {% include references.md %} -{% include linkers/issues.md issues="23155,22513,4921,4829,2061,2073,906,1163,765,759,911" %} +{% include linkers/issues.md issues="23155,22513,4921,4829,2061,2073,906,1163,765,759,911,23512" %} [bdk 0.14.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.14.0 [news177 lnd6026]: /en/newsletters/2021/12/01/#lnd-6026 [darosior bump]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019614.html [revault research]: https://github.com/revault/research +[GetBlockScriptFlags tap]: https://github.com/bitcoin/bitcoin/blob/dca9ab48b80ff3a7dbe0ae26964a58e70d570618/src/validation.cpp#L1616 +[AreInputsStandard tap]: https://github.com/bitcoin-core-review-club/bitcoin/blob/15d109802ab93b0af9647858c9d8adcd8a2db84a/src/validation.cpp#L726-L729 +[getblockchaininfo tap]: https://github.com/bitcoin/bitcoin/blob/dca9ab48b80ff3a7dbe0ae26964a58e70d570618/src/rpc/blockchain.cpp#L1537) +[isTaprootActive tap]: https://github.com/bitcoin-core-review-club/bitcoin/blob/15d109802ab93b0af9647858c9d8adcd8a2db84a/src/interfaces/chain.h#L292 +[AreInputsStandard def]: https://github.com/bitcoin/bitcoin/blob/dca9ab48b80ff3a7dbe0ae26964a58e70d570618/src/policy/policy.h#L110 From 41a21e36b4ae9e801a00cb952fe21ca50d960663 Mon Sep 17 00:00:00 2001 From: Jonas Date: Mon, 6 Dec 2021 15:06:16 -0500 Subject: [PATCH 03/10] news178: add bitcoin core #22513 --- _posts/en/newsletters/2021-12-08-newsletter.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2021-12-08-newsletter.md b/_posts/en/newsletters/2021-12-08-newsletter.md index 579f8f4b96..9533dabf2d 100644 --- a/_posts/en/newsletters/2021-12-08-newsletter.md +++ b/_posts/en/newsletters/2021-12-08-newsletter.md @@ -105,7 +105,16 @@ repo], [Hardware Wallet Interface (HWI)][hwi repo], - [Bitcoin Core #23155][] rpc: various fixups for dumptxoutset FIXME:jnewbery -- [Bitcoin Core #22513][] rpc: Allow walletprocesspsbt to sign without finalizing FIXME:adamjonas +- [Bitcoin Core #22513][] allows `walletprocesspsbt` to sign without + finalizing the [PSBT][topic psbt] workflow. This is useful for + complex scripts, for example, in a [tapscript][topic tapscript] + where a fallback script path requires only signer Alice along with + a normal path with multiple signers, including Alice. When Alice + signs, it is best to wait to finalize the PSBT with the fallback + script path and instead construct a PSBT containing all of Alice’s + signatures and then pass the PSBT to the other signers and wait for + them to sign. In this scenario, the ultimate path is determined after + all signatures are produced. - [C-Lightning #4921][] updates the implementation of [onion messages][topic onion messages] to match the latest updates to the From e4d1ffbff839ac22150febe80cc93057e124dd50 Mon Sep 17 00:00:00 2001 From: Jonas Date: Mon, 6 Dec 2021 15:13:26 -0500 Subject: [PATCH 04/10] news178: add bitcoin core 22513 to PSBT topic --- _topics/en/psbt.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/_topics/en/psbt.md b/_topics/en/psbt.md index 071671f52f..bfbd65c302 100644 --- a/_topics/en/psbt.md +++ b/_topics/en/psbt.md @@ -159,6 +159,9 @@ optech_mentions: - title: "LND #5363 allows PSBTs to be finalized by external software" url: /en/newsletters/2021/10/13/#lnd-5363 + - title: "Bitcoin Core #22513 allows walletprocesspsbt to sign without finalizing" + url: /en/newsletters/2021/12/08/#bitcoin-core-22513 + ## Optional. Same format as "primary_sources" above see_also: - title: Output Script Descriptors From cc5bbdb93abab856244fbdd4ead7dc8099156836 Mon Sep 17 00:00:00 2001 From: Carl Dong Date: Mon, 6 Dec 2021 15:32:55 -0500 Subject: [PATCH 05/10] News178: Add Eclair #2061 description --- _posts/en/newsletters/2021-12-08-newsletter.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2021-12-08-newsletter.md b/_posts/en/newsletters/2021-12-08-newsletter.md index 9533dabf2d..001826d691 100644 --- a/_posts/en/newsletters/2021-12-08-newsletter.md +++ b/_posts/en/newsletters/2021-12-08-newsletter.md @@ -126,7 +126,10 @@ repo], [Hardware Wallet Interface (HWI)][hwi repo], their DNS address rather than their IP address or Tor onion service address. -- [Eclair #2061][] Relay onion messages FIXME:dongcarl +- [Eclair #2061][] adds initial support for [onion messages][bolts #759]. Users + can enable the `option_onion_messages` feature to relay onion messages and + send onion messages with the `sendonionmessage` RPC. Handling incoming onion + messages and [route blinding][bolts #765] are not yet implemented. - [Eclair #2073][] adds support for the optional channel type negotiation feature bit as specified in draft [BOLTs #906][]. This corresponds From 4ebb79320ad51417e73b389ec0260c9232c211b3 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Tue, 7 Dec 2021 13:39:20 -0600 Subject: [PATCH 06/10] News178: Bitcoin Core 23155 --- _posts/en/newsletters/2021-12-08-newsletter.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2021-12-08-newsletter.md b/_posts/en/newsletters/2021-12-08-newsletter.md index 001826d691..e2b3789edd 100644 --- a/_posts/en/newsletters/2021-12-08-newsletter.md +++ b/_posts/en/newsletters/2021-12-08-newsletter.md @@ -103,7 +103,10 @@ repo], [Hardware Wallet Interface (HWI)][hwi repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], and [Lightning BOLTs][bolts repo].* -- [Bitcoin Core #23155][] rpc: various fixups for dumptxoutset FIXME:jnewbery +- [Bitcoin Core #23155][] adds additional output to the `dumptxoutset` RPC as + part of the [AssumeUTXO][topic assumeutxo] project: `txoutset_hash` (the UTXO set hash), + `nchaintx` (a count of transactions in the chain), and the path of the + serialized UTXO set on disk. - [Bitcoin Core #22513][] allows `walletprocesspsbt` to sign without finalizing the [PSBT][topic psbt] workflow. This is useful for From 640be31166fe3ae03a47228d0c9d7a0606f2b471 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Tue, 7 Dec 2021 10:30:05 -1000 Subject: [PATCH 07/10] News178: edit harding sections --- _posts/en/newsletters/2021-12-08-newsletter.md | 17 +++++++++-------- _topics/en/assumeutxo.md | 3 +++ _topics/en/cpfp-carve-out.md | 3 +++ _topics/en/onion-messages.md | 6 ++++++ _topics/en/soft-fork-activation.md | 3 +++ 5 files changed, 24 insertions(+), 8 deletions(-) diff --git a/_posts/en/newsletters/2021-12-08-newsletter.md b/_posts/en/newsletters/2021-12-08-newsletter.md index e2b3789edd..3125e895d6 100644 --- a/_posts/en/newsletters/2021-12-08-newsletter.md +++ b/_posts/en/newsletters/2021-12-08-newsletter.md @@ -9,13 +9,13 @@ lang: en --- This week's newsletter describes a post about fee-bumping research and contains our regular sections with the summary of a Bitcoin Core PR -Review Club meeting, the latest releases and RCs of Bitcoin software, +Review Club meeting, the latest releases and release candidates for Bitcoin software, and notable changes to popular infrastructure projects. ## News - **Fee bumping research:** Antoine Poinsot [posted][darosior bump] to - the Bitcoin-Dev mailing list a detailed description several concerns + the Bitcoin-Dev mailing list a detailed description of several concerns developers need to consider when choosing how to fee-bump presigned transactions used in [vaults][topic vaults] and contract protocols such as LN. In particular, Poinsot looked at schemes for multiparty @@ -26,7 +26,7 @@ and notable changes to popular infrastructure projects. transaction pinning]. Also included in his post is the result of [research][revault research] into some of the ideas described earlier. - Ensuring that fee bumping works reliability is a requirement for the + Ensuring that fee bumping works reliably is a requirement for the safety of most contract protocols, and it remains a problem without any comprehensive solution yet. It is encouraging to see continuing research into the problem. @@ -103,10 +103,12 @@ repo], [Hardware Wallet Interface (HWI)][hwi repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], and [Lightning BOLTs][bolts repo].* -- [Bitcoin Core #23155][] adds additional output to the `dumptxoutset` RPC as - part of the [AssumeUTXO][topic assumeutxo] project: `txoutset_hash` (the UTXO set hash), - `nchaintx` (a count of transactions in the chain), and the path of the - serialized UTXO set on disk. +- [Bitcoin Core #23155][] extends the `dumptxoutset` RPC with the hash + of the chainstate snapshot (UTXO set) along with the number of + transactions in the entire chain up until that point. This + information can be published alongside the chainstate so that others + can verify it using the `gettxoutsetinfo` RPC, allowing it to be used + with the proposed [assumeUTXO][topic assumeutxo] node bootstrapping. - [Bitcoin Core #22513][] allows `walletprocesspsbt` to sign without finalizing the [PSBT][topic psbt] workflow. This is useful for @@ -151,7 +153,6 @@ repo], [Hardware Wallet Interface (HWI)][hwi repo], channel. Since only the remote node is taking any risk, there's no problem allowing the local node to accept such channels. - {% include references.md %} {% include linkers/issues.md issues="23155,22513,4921,4829,2061,2073,906,1163,765,759,911,23512" %} [bdk 0.14.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.14.0 diff --git a/_topics/en/assumeutxo.md b/_topics/en/assumeutxo.md index d5cefaa115..a30d0fab91 100644 --- a/_topics/en/assumeutxo.md +++ b/_topics/en/assumeutxo.md @@ -40,6 +40,9 @@ optech_mentions: - title: "Bitcoin Core #19521 simplifies generating UTXO set hashes for old blocks" url: /en/newsletters/2021/05/05/#bitcoin-core-19521 + - title: "Bitcoin Core #23155 extends the `dumptxoutset` RPC with new information" + url: /en/newsletters/2021/12/08/#bitcoin-core-23155 + ## Optional. Same format as "primary_sources" above see_also: - title: "Bitcoin Core issue #15605: AssumeUTXO discussion" diff --git a/_topics/en/cpfp-carve-out.md b/_topics/en/cpfp-carve-out.md index 7c7e4a829c..efd7409e9a 100644 --- a/_topics/en/cpfp-carve-out.md +++ b/_topics/en/cpfp-carve-out.md @@ -52,6 +52,9 @@ optech_mentions: - title: Bitcoin Core 0.19 released with CPFP carve-out url: /en/newsletters/2019/11/27/#cpfp-carve-out + - title: Research into alternatives to CPFP carve-out for fee bumping in multiparty contract protocols + url: /en/newsletters/2021/12/08/#fee-bumping-research + ## Optional. Same format as "primary_sources" above see_also: - title: Transaction pinning diff --git a/_topics/en/onion-messages.md b/_topics/en/onion-messages.md index 2b0077693c..993e090373 100644 --- a/_topics/en/onion-messages.md +++ b/_topics/en/onion-messages.md @@ -32,6 +32,12 @@ optech_mentions: - title: "Eclair #1957 adds basic support for onion messages" url: /en/newsletters/2021/11/17/#eclair-1957 + - title: "C-Lightning #4921 updates the implementation of onion messages" + url: /en/newsletters/2021/12/08/#c-lightning-4921 + + - title: "Eclair #2061 adds initial support for onion messages" + url: /en/newsletters/2021/12/08/#eclair-2061 + ## Optional. Same format as "primary_sources" above # see_also: # - title: diff --git a/_topics/en/soft-fork-activation.md b/_topics/en/soft-fork-activation.md index c50688bd81..de4a1c9a99 100644 --- a/_topics/en/soft-fork-activation.md +++ b/_topics/en/soft-fork-activation.md @@ -121,6 +121,9 @@ optech_mentions: - title: "BIPs #1104 adds activation parameters to the BIP341 taproot specification" url: /en/newsletters/2021/05/05/#bips-1104 + - title: Analysis of treating taproot outputs as always usable post-activation + url: /en/newsletters/2021/12/08/#bitcoin-core-pr-review-club + ## Optional. Same format as "primary_sources" above see_also: - title: BIP activation heights, times, and thresholds From bbd0dafcfad574d40069dbfe0d8165e82ddf7306 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Tue, 7 Dec 2021 10:30:25 -1000 Subject: [PATCH 08/10] News178: edits to glozow section --- _posts/en/newsletters/2021-12-08-newsletter.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/_posts/en/newsletters/2021-12-08-newsletter.md b/_posts/en/newsletters/2021-12-08-newsletter.md index 3125e895d6..7708e936a4 100644 --- a/_posts/en/newsletters/2021-12-08-newsletter.md +++ b/_posts/en/newsletters/2021-12-08-newsletter.md @@ -37,8 +37,8 @@ and notable changes to popular infrastructure projects. meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.* -[Treat Taproot as always active][review club #23512] is a PR by Marco Falke to -make transactions spending taproot outputs standard, regardless of taproot +[Treat taproot as always active][review club #23512] is a PR by Marco Falke to +make transactions spending [taproot][topic taproot] outputs standard, regardless of taproot deployment status. {% include functions/details-list.md @@ -63,9 +63,9 @@ deployment status. q2="Are there any theoretical issues with the change? For wallet users, is it possible to lose money?" - a2="With this change, the wallet allows importing taproot descriptors at any + a2="With this change, the wallet allows importing taproot [descriptors][topic descriptors] at any time, i.e., even when taproot is not active and v1 segwit outputs can be spent - by anyone). This means it's possible to receive bitcoin at a taproot address + by anyone. This means it's possible to receive bitcoin to a taproot output without taproot being active yet; if the chain also reorgs to a block prior to 709,632, miners (or someone who can get a nonstandard transaction confirmed) can steal those UTXOs." From ddf906eaab19bc8a0b3889c111d466dbfc3bf04f Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Tue, 7 Dec 2021 10:31:22 -1000 Subject: [PATCH 09/10] News178: edits to adamjonas section --- _posts/en/newsletters/2021-12-08-newsletter.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/_posts/en/newsletters/2021-12-08-newsletter.md b/_posts/en/newsletters/2021-12-08-newsletter.md index 7708e936a4..1d4ffa64a5 100644 --- a/_posts/en/newsletters/2021-12-08-newsletter.md +++ b/_posts/en/newsletters/2021-12-08-newsletter.md @@ -112,12 +112,12 @@ repo], [Hardware Wallet Interface (HWI)][hwi repo], - [Bitcoin Core #22513][] allows `walletprocesspsbt` to sign without finalizing the [PSBT][topic psbt] workflow. This is useful for - complex scripts, for example, in a [tapscript][topic tapscript] - where a fallback script path requires only signer Alice along with - a normal path with multiple signers, including Alice. When Alice - signs, it is best to wait to finalize the PSBT with the fallback - script path and instead construct a PSBT containing all of Alice’s - signatures and then pass the PSBT to the other signers and wait for + complex scripts, for example, in a [tapscript][topic tapscript] with + two paths: a fallback script path that requires only signer Alice, + plus a normal path with multiple signers including Alice. When Alice + signs, it is best to delay finalizing the PSBT with the fallback + script path and instead construct a PSBT containing both of Alice’s + signatures, pass the PSBT to the other signers, and wait for them to sign. In this scenario, the ultimate path is determined after all signatures are produced. From 80b475e77f7ab8ebfabea69e99dfa3252b43d3fd Mon Sep 17 00:00:00 2001 From: lightning-developer <95319454+lightning-developer@users.noreply.github.com> Date: Wed, 8 Dec 2021 00:22:21 +0100 Subject: [PATCH 10/10] Include The deprecation of TOR v2 Onions --- _posts/en/newsletters/2021-12-08-newsletter.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/_posts/en/newsletters/2021-12-08-newsletter.md b/_posts/en/newsletters/2021-12-08-newsletter.md index 1d4ffa64a5..e2df7bb351 100644 --- a/_posts/en/newsletters/2021-12-08-newsletter.md +++ b/_posts/en/newsletters/2021-12-08-newsletter.md @@ -153,6 +153,10 @@ repo], [Hardware Wallet Interface (HWI)][hwi repo], channel. Since only the remote node is taking any risk, there's no problem allowing the local node to accept such channels. +- [Lightning BOLTs #940][] deprecates the announcement and parsing of TOR + v2 onions in `node_announcements`. [Rust-Lightning #1204][] has already + updated this. + {% include references.md %} {% include linkers/issues.md issues="23155,22513,4921,4829,2061,2073,906,1163,765,759,911,23512" %} [bdk 0.14.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.14.0