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..e2df7bb351 --- /dev/null +++ b/_posts/en/newsletters/2021-12-08-newsletter.md @@ -0,0 +1,170 @@ +--- +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 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 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 + 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 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. + +## 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.* + +[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 + 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][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 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." + 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 + +*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][] 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 + 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. + +- [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][] 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 + 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. + +- [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 +[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 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/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 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