This week’s newsletter summarizes an update to a proposed standard for LN and includes our regular sections about notable changes to services, client software, and popular Bitcoin infrastructure projects.

Action items

None this week.

News

  • ● Proposed watchtower BOLT has been updated: Sergi Delgado Segura emailed the Lightning-Dev mailing list an updated version of a suggested protocol for watchtower communication. See Newsletter #75 for our original description of this proposal. According to Segura, the update includes details about “user accounts, payment methods, and message signing.” His email also provides a list of features he would like to add, with discussion about each near the end of the email.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

  • ● Coinbase withdrawal transactions now using batching: Coinbase has rolled out batch withdrawals that they estimate will reduce their load on the Bitcoin network by 50%. Instead of each withdrawal payment generating a single onchain transaction, multiple payments will be combined into a single transaction once every 10 minutes.

  • ● Bitstamp supports bech32: Bitstamp users can now benefit from using native bech32 addresses after the exchange announced support for both bech32 deposits and withdrawals.

  • ● Deribit supports bech32 withdrawals: Deribit announced that its exchange users can now withdraw bitcoins to bech32 native addresses.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, libsecp256k1, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • ● Bitcoin Core #16902 changes consensus code to fix an inefficiency in the parsing of OP_IF and related opcodes. In legacy and segwit v0 script, the inefficiency isn’t believed to cause any significant problems. However, the proposal for tapscript would make it possible for an attacker to use the inefficiency to create blocks with transactions that could take a large amount of CPU to verify. Fixing the inefficiency now reduces the number of changes that need to be made in the proposed schnorr, taproot, and tapscript soft fork. For more information, see the Bitcoin Core PR Review Club meeting notes about this PR.

  • ● LND #3821 adds anchor commitments for LN channels and enables them by default if both participating nodes of a channel signal support. Anchor commitment transactions can be fee bumped unilaterally by either party, which is useful because commitment transactions might be broadcast a long time after they commit to their on-chain feerate.

  • ● LND #3963 adds detailed documentation about how to use LND safely.

  • ● Eclair #1319 implements the same solution as described in Newsletter #85 for a rare stuck-channels problem where payments are rejected for insufficient funds when the channel funder is receiving the money but doesn’t have enough balance to afford the payment’s commitment (HTLC) cost.