This week’s newsletter announces the newest release of C-Lightning, briefly describes several proposals related to LN, and provides our usual sections about bech32 sending support and notable changes to popular Bitcoin infrastructure projects.

Action items

None this week.

Dashboard items

  • ● Mempool variability: over the past week, the mempool tracked by various nodes has varied in size from almost 100,000 transactions to fewer than 1,000 transactions. Because most fee estimation algorithms lag behind changes in mempool state, high variability in mempool size may create more stuck transactions or overpaying transactions than normal. High-frequency spenders such as exchanges may want to monitor mempool state themselves (e.g. using Bitcoin Core’s getmempoolinfo RPC) in order to tweak their feerates for the current mempool conditions.

News

  • ● LND 0.7.0-beta released: this new major version is the first to contain a watchtower implementation that allows third parties to help defend the in-channel funds of offline users. Also included are bug fixes, improvements to the API for payment tracking, and faster initial syncs. Upgrading is recommended.

  • ● C-Lightning 0.7.1 released: this new version contains new plugins and RPCs as well as numerous improvements to its handling of the channel gossip protocol that reduce the use of memory and bandwidth. Upgrading is recommended.

  • ● Stuckless payments: Hiroki Gondo proposed an alternative way to route payments across LN channels with a two-step protocol for releasing payment. In the first phase, money is transferred using HTLCs locked to a preimage not known to the receiver. When the receiver acknowledges that the money is available, the spender releases the information necessary for the receiver to claim the money. The advantage of this method is that it allows the spender to prevent a payment from succeeding up until the last moment, allowing them to unilaterally cancel stuck payments or even try sending the same payment over multiple routes simultaneously to see which succeeds the fastest (before canceling the slower payments). The proposal would require substantial revision of the current LN protocol, so it’s something developers will need to consider for future upgrades.

  • ● Standardized atomic data delivery following LN payments: Nadav Kohen posted a proposal to the Lightning-Dev mailing list for a standardized way to deliver data paid for via LN, the same method already used on Alex Bosworth’s Y’alls site. Data would be encrypted by a payment request’s pre-image so that the encrypted data could be given to the buyer before any payment was made. The buyer would then send a payment, the merchant would accept that payment by releasing the pre-image, and the buyer would then use the pre-image to decrypt the data. The system still requires the buyer trust the merchant, as the merchant could deliver encrypted junk instead of the actual data (i.e., this proposal isn’t trustless like a zero-knowledge contingent payment), but the proposed protocol can allow the buyer to begin downloading data while the payment is still being processed.

  • ● Lightning Loop supports user loop-ins: as described in Newsletter #39, Lightning Loop uses submarine swaps to allow a user to exchange bitcoins in an offchain LN payment channel for bitcoins in a normal onchain transaction, called a loop out. This is done without opening or closing any channels. An update to the system now allows users to do the opposite: exchange bitcoins in a regular onchain UTXO for bitcoins in one of their LN channels, called a loop in. Both loop in and loop out are trustless except for the need for one party to pay a transaction fee if the other party backs out of the swap. With the new loop in feature, LN users can conveniently refill their exhausted channels without using a custodial service. The Loop software is compatible with recent versions of LND.

Bech32 sending support

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

Recently, an Optech contributor surveyed many popular wallets and Bitcoin exchanges to see what technical features they supported. For one of the exchanges, he initially recorded it as supporting sending to bech32 addresses—but later he discovered its support wasn’t entirely complete.

The problem was that the exchange supported P2WPKH bech32 addresses (single-sig addresses) but not P2WSH bech32 addresses (multisig and complex script addresses). Another problem was accepting all-lowercase bech32 addresses but not all-uppercase bech32 addresses. A different exchange limited the length of address form fields so that they couldn’t fit all valid bech32 addresses.

With these problems in mind, we’ve created a short checklist for testing basic bech32 sending support. Only perform these tests with small amounts of bitcoin that you can afford to lose if something goes wrong.

  1. Generate two addresses of your own, one for P2WPKH and one for P2WSH. For example, using Bitcoin Core, the jq JSON parser, and the Bash shell, you can run the following commands:

      $ p2wpkh=$( bitcoin-cli getnewaddress "bech32 test" bech32 )
  $ p2wsh=$(
    bitcoin-cli addmultisigaddress 1 \[$(
      bitcoin-cli getaddressinfo $p2wpkh | jq .pubkey
    )\] "bech32 test" bech32 | jq -r .address
  )
  $ echo $p2wpkh $p2wsh
  $ echo $p2wpkh $p2wsh | tr '[a-z]' '[A-Z]'

  2. Test sending bitcoin to each lowercase address using your software’s or service’s usual spending or withdrawal forms.

  3. Test again with the uppercase form of each address (these are useful with QR codes).

  4. Ensure that you received the funds by checking either the wallet you used to create the addresses or a block explorer. If that worked, your software fully supports current bech32 spending addresses.

    If you created addresses using a temporary Bitcoin Core wallet, you can wait for the transactions to confirm and then send all the money to your regular wallet using the following command: bitcoin-cli sendtoaddress YOUR_ADDRESS $( bitcoin-cli getbalance ) '' '' true

For unit tests where you don’t actually attempt to send money, or for integration tests where you send money on testnet or in regression testing mode, BIP173 provides a more comprehensive set of test vectors.

Notable code and documentation changes

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

  • ● C-Lightning #2767 disables the listtransactions RPC described in code changes section of Newsletter #51. That RPC currently has several issues open, so it was disabled for the 0.7.1 release. Developers plan to re-enable it shortly after the release.

  • ● Eclair #962 adds a balances method that prints the balances of each channel.