Files
specs/02.md
2023-01-13 00:42:48 +03:00

2.4 KiB

BDS-02

Expiring Channel Addresses

draft mandatory author:brqgoo

This BDS defines a non-interactive channel opening scheme.

Rationale

Today, funding outpoints must be known before establishing a new channel to craft a refund from the 2-of-2 multisig. This has three main drawbacks:

On-chain footprint

Cannot allow batch openings, consuming more on-chain footprint. A third party (i.e. on-ramp exchange) cannot open a channel for two other parties (between the user and LSP), among other outputs. Note that Vortex enables batch openings as a side result but requires interactivity pre-channel formation.

On-chain privacy

In comparison to batch openings, regular channel establishments are less privacy-preserving. Funding transaction consumes one or more inputs, a channel output, and a probabilistic change. It might have two changes if dual-funded. On-chain observers MAY have an idea whether this might be a funding transaction.

Convenience

Inconvenient for onboarding new users who have no UTXO possession in the beginning.

Specification

Channel addresses, as seen here and here, make it possible to craft on-chain bitcoin addresses such that whenever funded by someone, becomes a payment channel between the user and the channel partner (LSP), where the channel funds are initially kept on the user's side. Channel address require new additions to the bitcoin scripting system, and planned as a future extension under BDS-19.

Expiring channel addresses proposes a much more primitive version of channel addresses that can be built on Bitcoin today. If we add to the 2-of-2 musig inner key a single-leaf script path after a relative locktime to the user, similar to pre-segwit timeout channel design, it becomes no longer necessary to craft a refund transaction in advance of funding the output. If the channel partner (LSP) is non-collaborative in exchanging signatures for a refund once the address is funded, the user can exit from the script path after the expiry. Ultimately, it's LSP's responsibility to close the channel shortly before its expiry. While this may seem a bad idea from an on-chain footprint standpoint, we anticipate users to mostly receive funds over silent swaps and only rarely receive on-chain through expiring channel addresses.