Bitcoin Optech #142: Lightning Network Path Selection And Bitcoin Stack Exchange

Bitcoin Optech #142: Lightning Network Path Selection And Bitcoin Stack Exchange

This week’s Bitcoin Optech newsletter discusses the Lightning Network, Q&A from Bitcoin Stack Exchange and other notable updates.

The 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.

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.

  • BTCPay Server 1.0.7.1 fixes several security vulnerabilities. It also includes a number of improvements and non-security bug fixes. is a bugfix release that addresses minor issues with Trezor T passphrase entry and keyboard shortcuts in the hwi-qt user interface.
  • HWI 2.0.1 is a bugfix release that addresses minor issues with Trezor T passphrase entry and keyboard shortcuts in the hwi-qt user interface.
  • C-Lightning 0.10.0-rc2 is a release candidate for the next major version of this LN node software.

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 #17227 adds a new make apk target to the build system which packages bitcoin-qt for the Android operating system. This continues previous work which added support for packaging the Android NDK. Also included are documentation for building Bitcoin Core for Android and a continuous integration job to test the Android build system.
  • Rust-Lightning #849 makes a channel’s cltv_expiry_delta configurable and reduces the default value from 72 blocks to 36 blocks. This parameter sets the deadline by which a node must settle a payment attempt with its upstream peer after learning from its downstream peer whether that payment succeeded; it must be long enough to confirm a transaction onchain if necessary but should be short enough that it’s competitive with other nodes that are trying to minimize possible delays. See also Newsletter #40 where LND reduced its value to 40 blocks.
  • C-Lightning #4427 makes it possible to experiment with dual funded payment channels by using the configuration option –experimental-dual-fund. Dual funding allows funds for the initial channel balance to be contributed by both the node initiating the channel and the node accepting the channel, which can be useful for merchants and other users who want to begin receiving payments as soon as the channel finishes opening.
  • Eclair #1738 updates the penalty enforcement mechanism for revoked HTLCs when anchor outputs are being used. A change unrelated to anchor outputs, but introduced at the same time they were added to the protocol, created the possibility to combine multiple SIGHASH_SINGLE|SIGHASH_ANYONECANPAY HTLC outputs into a single transaction (see Newsletter #128. This PR ensures that all outputs that are spendable with the revocation key are claimed in the same transaction instead of claiming only one per transaction.
  • BIPs #1080 updates BIP8 with a minimum_activation_height parameter that delays the time nodes begin enforcing a locked-in soft fork until after the specified height. This makes BIP8 compatible with the Speedy Trial proposal (see Newsletter #139) that would allow miners to activate taproot but would not begin enforcing taproot’s rules until roughly six months after the release of software implementing Speedy Trial.

Find the original post here.

Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month.

Sending
User Review
0 (0 votes)