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.
None this week.
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.
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
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
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.
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:
Test sending bitcoin to each lowercase address
using your software’s or service’s usual spending or withdrawal forms.
Test again with the uppercase form of each address (these are useful
with QR codes).
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
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