This week’s newsletter summarizes a few discussions on the Lightning-Dev
mailing list, suggests an opportunity to develop a new tool some users would
find helpful, and provides summaries and links to some of the talks at the
recent Chaincode Lightning Applications residency. Several notable code
changes in popular Bitcoin infrastructure projects are also described.
None this week.
LN developer summit and mailing list activity: before, during, and
after a planned meeting among Lightning Network protocol developers,
the Lightning-Dev mailing list saw a surge of new proposals and
discussion about earlier proposals. Below are some highlights:
Advertising node liquidity: Lisa Neigut proposes allowing LN nodes advertise that they’re willing to
provide incoming capacity in exchange for a certain level of fees.
Merchants need their payment channels to have incoming capacity in
order to be able receive secure offchain payments from
customers—the current alternatives are either requiring some of
their customers to wait for several onchain confirmations to open
a new channel or making manual channel liquidity arrangements with
other merchants. Although solving this problem would be highly
advantageous for merchant adoption of LN, it does pose some
technical challenges that discussion participants attempt to solve
both in this thread and in a related thread.
Making path probing more convenient: Anthony Towns
proposes a method for allowing all the nodes along
a path to forget about a small-value payment if one of the nodes
on the path is offline. This reduces the resources required in
the case of a routing failure by a node that proactively probes
its available payment paths to determine which are the fastest and
most reliable for sending payments.
Opportunity available for providing utility functions outside of
Bitcoin Core: Bitcoin Core’s RPC interface currently provides over
100 methods and there are often proposals to add even more for utility
functions that don’t require access to the internal state of the node
or wallet. During last week’s developer IRC meeting, members of the project reaffirmed their commitment to not
provide any new utility functions for things that can just as easily
be done outside Bitcoin Core and that are unrelated to normal user
workflows. This will help keep the project focused on its main
This does provide a nice opportunity for an independent developer or
other third-party to create a separate project for a library, local
program, or RPC interface that provides a stable interface to
utility functions that work well in conjunction with Bitcoin Core,
and which perhaps even provides some of the utility functions that
Bitcoin Core already supports for users not running a node. Some
ideas for how to implement such a tool were discussed both during
and after the meeting.
Lightning Application Residency Videos
As reported previously in newsletter #19, Chaincode Labs recently hosted a
five-day residency program for developing applications on the Lightning
Network, including presentations from experts in the space. Videos of the
presentations and resident demos have now been posted online, along
with the slide decks for the expert presentations. The following
talks may be of particular interest to members:
Lightning ≈ Bitcoin - Christian Decker, Core Tech
Engineer at Blockstream, describes the similarities and differences between
Bitcoin and Lightning payments, highlighting where on-chain transactions are
more appropriate then off-chain (and vice versa). He finishes with a summary
of enhancements that may be proposed at the November 2018 Lightning protocol
Integrating Lightning into Bitrefill - Justin
Camarena, infrastructure engineer at bitrefill, explains how
bitrefill integrated lightning payments into their store. Bitrefill was
one of the first Bitcoin merchants to start accepting mainnet Lightning
payments, and Justin shows us how they integrated Lightning into their
infrastructure, and the challenges they met and overcame along the way.
For those interested in a high level overview of bitrefill’s experience
with Lightning, the talk by Sergej Kotliar at Building on Bitcoin, covered in newsletter #3 will also be of interest.
Zap - UX, Design and Product approach -
Jack Mallers, founder of Zap, explains his approach to product
design and user experience. Lightning can potentially solve a lot of user
experience issues associated with using Bitcoin, but also brings up some user
experience challenges of its own. Jack explains how he thinks about user
experience in Zap, the UX challenges he’s faced building the product and how
he’s solved them.
Bitcoin Core #14060 makes configurable the maximum number of
messages the ZeroMQ (ZMQ) interface will queue for a client. The
default High-Water Mark (HWM) allows up to 1,000 messages to be queued
before some messages are dropped. A new HWM may be chosen by setting
one of the following configuration options to the desired maximum
number of queued messages (or the maximum queue size may be made
unlimited by setting it to 0): zmqpubhashtxhwm,
zmqpubhashblockhwm, zmqpubrawblockhwm, and zmqpubrawtxhwm.
The greater the queue size, the more memory the program will use.
LND #1782 adds a num_inactive_channels field to the getinfo RPC
with the number of the node’s inactive channels (similar to the
existing counts of pending and active channels).
LND #1944 adds a pub_key field to the sendtoroute RPC so that
LND doesn’t need to get the pubkey from an external source. This
allows routing payments through private channels that are not listed
on the public network.