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.

Action items

None this week.

News

  • ● 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 objectives.

    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:

  • ● The Lightning Protocol - an Application Developers Perspective - Alex Bosworth, infrastructure lead at Lightning Labs, gives a comprehensive overview of the Lightning protocol, explaining all of the BOLTs, and how they are relevant for developers building on top of the protocol. This talk should be useful for any developers wanting to integrate Lightning into products or services.

  • ● 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 meeting.

  • ● 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.

Notable code changes

Notable code changes this week in Bitcoin Core, LND, C-lightning, and libsecp256k1.

  • ● Bitcoin Core #14410 adds an ischange field to the getaddressinfo RPC indicating whether the wallet used the address in a change output.

  • ● 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.