This week’s newsletter announces the release of the newest version of Eclair and describes a potential routing improvement for LN. Also included are our regular sections about bech32 sending support and notable code changes in popular Bitcoin infrastructure projects.

Action items

None this week.

News

  • ● Eclair 0.3.1 released: the newest version of this LN software includes new and improved API calls as well as other changes that allow it to perform faster and use less memory. Upgrading is recommended.

  • ● Brainstorming just-in-time routing and free channel rebalancing: sometimes LN nodes receive a routed payment that they reject because their outbound channel for that payment doesn’t currently have a high enough balance to support it. Rene Pickhardt previously proposed Just-In-Time (JIT) routing where the node would attempt to move funds into that channel from one or more of its other channel balances. If successful, the payment could then be routed; otherwise, it would be rejected like normal. Because the routed payment might fail for other reasons and prevent the routing node from earning any fees, any JIT rebalance operations need to be free or they could end up costing the node money in a way that attackers could exploit.

    In a new post to the Lightning-Dev mailing list, pseudonymous LN developer ZmnSCPxj describes two situations in which other profit-maximizing nodes might allow free rebalances. The first case is the observation that the next hop in the route will receive its own routing fee paid by the spender if the payment succeeds. ZmnSCPxj describes a method by which the next hop’s node can make their part of the rebalance contingent on receipt of the routing income, ensuring that they either get paid or the rebalance doesn’t happen. This would require additional communication between nodes and so it’s a change that probably needs further discussion in order to be considered for addition to the LN specification.

    The second case ZmnSCPxj describes is other nodes along the rebalance path who themselves want to rebalance one or more of their channels in the same direction as the routing node. These nodes can allow free routing in that direction to encourage someone to perform that rebalancing. This second case doesn’t require any changes to the LN specification: nodes can already set their routing fees to zero, allowing any other nodes to attempt JIT routing with free rebalances. The worst case would be that a payment that would’ve failed anyway will take a bit longer to return a failure message to the spender, a delay equal to the amount of time any routing nodes spent attempting to rebalance their channels in order to support the payment.

Bech32 sending support

Week 17 of 24 in a series about allowing the people you pay to access all of segwit’s benefits.

As we’ve shown in earlier parts of this series, bech32 addresses are better in almost every way than legacy addresses—they allow users to save fees, they’re easier to transcribe, address typos can be located, and they’re more efficient in QR codes. However, there is one feature that legacy P2PKH addresses support that is not widely supported by native segwit wallets—message signing support. In the spirit of full disclosure and the hopes of spurring wallet developers into action, we’ll take a look at this missing piece of bech32 address support.

For background, many wallets allow a user with a legacy P2PKH address to sign an arbitrary text message using the private key ultimately associated with that address:

$ bitcoin-cli getnewaddress "" legacy
125DTdGU5koq3YfAnA5GNqGfC8r1AZR2eh

$ bitcoin-cli signmessage 125DTdGU5koq3YfAnA5GNqGfC8r1AZR2eh Test
IJPKKyC/eFmYsUxaJx9yYfnZkm8aTjoN3iv19iZuWx7PUToF53pnQFP4CrMm0HtW1Nn0Jcm95Le/yJeTrxJwgxU=

Unfortunately, there’s no widely-implemented method for creating signed messages for legacy P2SH, P2SH-wrapped segwit, or native segwit addresses. In Bitcoin Core and many other wallets, trying to use anything besides a legacy P2PKH address will fail:

$ bitcoin-cli getnewaddress "" bech32
bc1qmhtn8x34yq9t7rvw9x6kqx73vutqq2wrxawjc8

$ bitcoin-cli signmessage bc1qmhtn8x34yq9t7rvw9x6kqx73vutqq2wrxawjc8 Test
error code: -3
error message:
Address does not refer to key

Some wallets do support message signing for segwit addresses—but in a non-standardized way. For example, the Trezor and Electrum wallets each provide message signing support for P2WPKH and P2SH-wrapped P2WPKH addresses. Yet both implementations were made independently and use slightly different protocols, so they’re unable to verify signatures produced by the other system. Additionally, the algorithms used by all wallets we’re aware of can’t be easily adapted to P2SH and P2WSH scripts used for multisig and other advanced encumbrances. That means message signing today is universally limited to users of single-sig addresses.

There is a proposed standard that should allow any address type or script to be used to create a signed message, BIP322. The protocol should even be forward compatible with future segwit versions, such as bip-taproot and bip-tapscript (with some unresolved limitations related to time locks). Unfortunately, even though the proposal was first made more than a year ago (see Newsletter #13), there’s no implementation for it—not even a proposed implementation under review.

This leaves users of segwit without the same level of message signing support available to users of legacy addresses, and it may represent a reason some users are unwilling to move to segwit addresses. The only solutions, besides wallets abandoning message signing support, are for wallet developers to agree on a standard and then widely implement it.

Notable code and documentation changes

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

  • ● Bitcoin Core #15427 extends the utxoupdatepsbt RPC with a descriptors parameter that takes an output script descriptor and uses it to update a BIP174 Partially Signed Bitcoin Transaction (PSBT) with information about the scripts (addresses) involved in the transaction. This is in addition to the RPC’s previous behavior of adding information to the PSBT from the node’s mempool and UTXO set. This new feature is especially useful for hardware wallets and other paired wallets as it makes it possible to add HD key-path information to the PSBTs so that wallets asked to sign a PSBT can easily derive the keys needed for signing or verify that a change output does indeed pay back into the wallet.

  • ● Bitcoin Core #16257 aborts adding funds to an unsigned transaction if its feerate is above the maximum amount set by the maxtxfee configuration option (default: 0.1 BTC). Previously, the funding code would silently reduce the fee to the maximum, which could lead to users with typos in their transactions overpaying as much as $1,200 USD in fees (at current prices). The new behavior gives users a chance to fix typos and eliminate any loss of funds.

  • ● Eclair #1045 adds support for Tag-Length-Value (TLV) message encoding. LN implementations plan to move most of their messages to this format in the future. LND and C-Lightning have previously implemented TLV support.