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.

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.