This week’s newsletter contains our regular sections with announcements of new releases and release candidates, plus notable changes to popular Bitcoin infrastructure projects.
No noteworthy news to report this week.
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.
Notable code and documentation changes
Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.
● Bitcoin Core #20286 removes the fields
reqSigsfrom the responses of the RPCs
gettransaction, and the REST endpoints
/rest/block. When a well-defined address exists, the responses now include the optional field
addressinstead. The deprecated fields had been used in the context of bare multisig which has no substantial use on the network today. The deprecated fields can be output via the configuration option
-deprecatedrpc=addressesuntil the option is removed in Bitcoin Core 23.0.
● Bitcoin Core #20197 improves the diversity of peer connections by updating the inbound peer eviction logic to protect the longest-running onion peers. It also adds unit test coverage for the current eviction protection logic. Onion peers have historically been disadvantaged by the eviction criteria due to their higher latency relative to IPv4 and IPv6 peers, leading to users filing multiple issues. An initial response to the issue began reserving slots for localhost peers as a proxy for onion peers. Later, explicit detection of inbound onion connections was added.
With the updated logic, half of the protected slots are allocated to any onion and localhost peers, with onion peers receiving precedence over localhost peers. Now that support for the I2P privacy network has been added to Bitcoin Core (see Newsletter #139), a next step will be to extend eviction protection to I2P peers, as they generally have higher latency than onion peers.
● Eclair #1750 removes support for Electrum and the corresponding 10,000 lines of code. Electrum was previously used by Eclair for mobile wallets. However, a new implementation, Eclair-kmp, is now recommended for use by mobile wallets, making Electrum support for Eclair unnecessary.
● Eclair #1751 adds a
blockingoption to the
payinvoicecommand which causes calls to
payinvoiceto block until the payment is completed. Previously, inefficiently polling the
getsentinfoAPI was required for users to know when payments completed.