This week’s “wumbo-sized” newsletter provides a note about Bitcoin hash rate related to forks on other coins, summarizes several accepted goals for the Lightning Network protocol version 1.1 specification, and lists several notable commits in popular Bitcoin infrastructure projects.

Action items

  • ● Monitor feerates: due to activity associated with Bitcoin Cash, which can use the same mining equipment used for Bitcoin, blocks on Bitcoin may appear less frequently than expected, raising feerates and causing other effects. However, these conditions may suddenly reverse, providing a period of fast blocks and low fee rates. See the News section below for more information and recommended actions for Bitcoin businesses.

Feature News: Lightning Network protocol 1.1 goals

LN protocol developers met in Adelaide last weekend to determine which changes to adopt for the forthcoming Lightning Protocol Specification 1.1. Thirty proposals were accepted at a high-level—meaning full specifications for each proposal are not necessarily defined or agreed upon yet—but the basic outline of the new features is available. Some highlights from the meeting include:

  • ● Multi-path payments: the current normal way to make a payment over LN is using a single path. Alice pays Charlie through her channel to Bob and Bob’s channel to Charlie. This works well for small payments where each participant has enough capacity to support the payment. But if we use this mechanism when Alice has 10 open channels each containing a maximum of 10% of her total hot wallet balance, Alice can only spend at most 10% of her funds at a time.

    Multipath payments provide a solution to this problem: if Alice wants to send 15% of her funds, she can send 7.5% to Charlie through her channel with Bob and 7.5% through her channel with Dan (who also has a channel with Charlie). Although the partial payments are routed through separate paths, they can each commit to the same hash Alice would’ve used to send a single-path payment. If Charlie receives multiple payments within a reasonable time period that equal or exceed the expected amount, he can guarantee that he’ll receive all of them by simply revealing the single preimage used by all of the hashes. This reuses the same proven security mechanism currently used for single-path payments and so doesn’t introduce any new security assumptions. The same mechanism also works if some other party along the path with sufficient channel capacity merges together the partial payments and forwards a single payment along the remainder of the path to Charlie.

    For more information, see the following Lightning-Dev threads which often call this feature Atomic Multi-path Payments (AMP): an early proposal with separate hashes/preimages, something like the currently favored proposal, a possibly too optimistic proposal.

  • ● Dual-funded channels: a nice feature of the current implementation is that only one party to the channel needs to initially commit any funds to it. For example, Alice opens a channel to Bob with 0.1 BTC of her money and none of Bob’s money. This makes it very easy for users to accept new incoming channels, but it also means that channels can only be used in one direction initially—Alice can pay Bob or route payments through Bob, but Alice can’t receive payments from Bob or from any routing path including Bob until Alice has sent Bob some money. This creates a bootstrapping problem: if Alice wants to receive payments via LN, she has to get people to open new channels to her node—which requires they pay onchain transaction fees and wait for onchain confirmations that can take hours.

    A proposed solution to this problem is to allow dual-funded channels. Alice agrees to put 0.1 BTC into a channel with Bob if Bob agrees to open the channel with 0.1 BTC of his own funds. This can cost Bob money—namely onchain transaction fees and the opportunity cost of having his funds committed for some time—but Bob also receives the opportunity to earn LN routing fees for any payments sent to Alice.

    The basic implementation of dual-funding is probably simple (LN nodes already handle bidirectional payments) but creating an incentive mechanism that can reward capital providers like Bob is still being discussed. For more information, see the following threads: 1, 2, 3. Also see the section on advertising node liquidity in Newsletter #21.

  • ● Splicing: you can’t currently increase a channel’s maximum balance or send some of the channel’s funds onchain to another person without closing the whole channel and opening another between the same parties. Closing one channel and opening another requires completely stopping all payments between the two parties until an appropriate number of onchain confirmations have been received for the close-and-reopen transaction.

    Splicing provides a solution where parties cooperatively create an onchain transaction that adds to or subtracts from the channel. When adding funds (splicing in), the funds previously in the channel can continue to be used offchain without interruption while the new funds are being confirmed. When spending funds onchain (splicing out), the remaining funds can also continue to be used offchain without interruption while the onchain recipient sees no difference from a normal transaction. This allows the wallet UI to make in-channel funds part of the total available balance for spending in onchain transactions so that users don’t need to manually manage offchain and onchain balances separately. Combined with multipath payments that allow funds from multiple channels to be intermixed in payments, this greatly simplifies spending: users will just click a link, review the invoice, and click Pay—letting the wallet automatically use any of its available balance for either an onchain payment or an offchain payment using any number of paths.

    For more information, see the following threads: 1, 2, 3. Also see the news item about channel splicing in Newsletter #17.

  • ● Wumbo: by agreement among early LN implementations, currently each channel’s capacity is limited by default to about 0.168 BTC (about $40 USD when defined; currently about $750). This was chosen to help prevent users from putting too much money into unproven software.

    Several years later, LN has matured significantly and some participants want to signal that they’re willing to open higher value channels. The 1.1 spec proposal will allow such participants to set a bit named “wumbo” (jumbo) to indicate their willingness to accept larger channels and larger in-channel payments.

    For more information, see the following threads: 1, 2. For etymological reference, the name wumbo appears to come from a segment in the SpongeBob SquarePants cartoon where an “M” is interpreted as standing for Mini, is inverted into a “W”, and redefined as standing for wumbo.

  • ● Hidden destinations: LN payments currently route payments using an onion method similar to sending data to a Tor exit node. Alice wants to ultimately pay Zed, so she finds a path to him through Bob, Charlene, and Dan. To prevent the intermediaries from learning about anything but the two channels they route though (e.g. Charlene knows about Bob and Dan), Alice encrypts each step of the path so that only the next step in disclosed to each recipient. When Zed ultimately receives the payment, he can simply return the success preimage to Dan, who returns it to Charlene, and so forth back to Alice.

    However, Tor also has a hidden service mode where both the sender and the recipient each choose part of the path so that neither of them can determine exactly where the packets came from or went—providing significantly improved privacy. This proposal for LN mirrors that mode. Alice will still choose Bob, Charlene, and Dan, but Zed can prevent Alice from learning about his routes by choosing Edmond, Fran, and George. Zed provides information about how to find Edmond to Alice—but the information about Fran, George, and Zed’s own node is encrypted so that Alice can’t see it. This can allow hidden channels—a current feature of several LN implementations—to stay hidden even when routing payments from arbitrary spenders.

    This feature is also called rendez-vous routing. For more information, see the description on the LN protocol documentation wiki. See also the following mailing list threads: 1, 2, 3.

Although discussed at the summit, the proposed 1.1 goals don’t directly address watchtowers that help protect channels for users that are currently offline, autopilots that help users open their initial payment channels, or deterministic preimage generation that allow private keys to stay offline while an online component simply completes acceptance of payments. These are services that can be built on top of the protocol and so don’t currently require any coordination between implementations.

News

  • ● Slowed block production, increased fees: as widely reported, several miners and mining pools are producing blocks for competing forks of Bitcoin Cash when they could likely earn greater revenues by creating blocks for Bitcoin. This is the likely cause of the approximately 7% reduction in Bitcoin difficulty over the retarget period ending Friday (UTC) and may mean additional decreases in Bitcoin hash rate and difficulty for an unknown length of time. Relevant consequences for Bitcoin businesses include:

    • ● Slower confirmation times: the average time between blocks may increase moderately to 11 or 12 minutes and the chance of there being a long wait between blocks will increase significantly in relative percentages (e.g. with historically typical 9 minute average block intervals, about 0.7% of blocks take more than 45 minutes; with a 12 minute interval, 2.3% take more than 45 minutes). Recommendation: Bitcoin users are already familiar with occasional long delays, so likely no action is needed.

    • ● Possibly increased fees: a longer time between finding blocks means less space for transactions, which can cause fee increases. Occasional long waits between blocks also tend to create sudden fee spikes that can persist for hours afterwards. Recommendation: ensure your fee estimation is working correctly and consider preparing any fee-reduction measures you’re willing to use such as payment batching.

    • ● Increased revenues for profit-maximizing miners: miners not only profit from increased fees, but each time Bitcoin’s difficulty adjusts downwards, mining becomes more profitable for Bitcoin miners (all other things being equal). Recommendation: do the math on reactivating slightly-old miners and overclocking current miners. With the recent price drop, this might instead mean you don’t need to turn off a miner that would’ve otherwise been unprofitable to operate.

    • ● Possible sudden end: it’s possible a large set of ideological miners producing blocks for Bitcoin Cash will all return to mining for the most profitable chain at roughly the same time. Combined with any past difficulty decreases, this could produce a series of Bitcoin blocks with shorter average time between blocks than normal. This will likely wipe out any moderate backlog and allow fees to drop to their default minimums. Recommendation: consider preparing to perform fee-reducing input consolidations if fees drop to their minimums.

  • ● Lightning protocol discussion: over 75 emails have been posted to the Lightning-Dev mailing list in the past week, representing almost 10% of the list’s traffic in the past 365 days. Many of the threads continue conversations started at the protocol developers summit. If you’re interested in Lightning protocol development, we suggest reading each of this month’s threads.

  • ● LND enters release cycle for version 0.5.1: experienced users of the LND implementation may wish to test this pre-release to help find any last-minute problems before the final release of this maintenance update.

Optech News

  • ● Second Optech workshop held in Paris: as announced in Newsletter #12, we held our second workshop in Paris last week. There were 24 engineers from Bitcoin companies and open source projects in attendance, and we had great discussions about wallet descriptors, Partially Signed Bitcoin Transactions (PSBTs), Lightning integration, taproot, coin selection, and fee bumping. Huge thanks to Ledger for hosting and helping with organization.

    If you work at a member company and have any requests or suggestions for future Optech events (such as location, venue, dates, format, topics, or anything else), please contact us. We’re here to help our member companies!

Notable code changes

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

  • ● C-Lightning #2075 adds support for plugins. As their documentation describes, “plugins are a simple yet powerful way to extend the functionality provided by c-lightning. They are subprocesses that are started by the main lightningd daemon and can interact with lightningd in a variety of ways.” At present, plugins can add command-line options to the main process, but there are plans to allow them to add new JSON-RPC commands, receive events, and insert code to be called by hooks in the main process. A helloworld plugin written in Python is provided with C-Lightning as an example.

  • ● Bitcoin Core #14411 The listtransactions RPC has its filter parameter partly restored, making it possible to retrieve a list of the transactions sent to addresses or scripts with a particular label. This has been backported to the 0.17 branch as PR #14441 and is expected to be distributed in the next maintenance release.

  • ● LND #2124 adds another essential portion of watchtower support, specifically the ability to detect that an attacker has made an onchain attempt steal from one of the watchtower’s users. The watchtower can use the information from the onchain transaction to decrypt a breach remedy transaction previously provided by the victim in order to both negate the attack and penalize the attacker by claiming any funds the attacker legitimately owned in the channel. In the current implementation, the watchtower receives a percentage of the recovered funds to compensate it for its diligent monitoring. This merge is an extension of PRs #1535 and #1512 described in Newsletter #19 and is a major step towards making LN safer for everyday users.

Special thanks

We thank Christian Decker, practicalswift, and René Pickhardt for providing suggestions or answering questions related to the content of this newsletter. Any remaining errors are entirely the fault of the newsletter’s author.