3.2 KiB
BDS-04
Silent Swaps
draft mandatory author:brqgoo
This BDS defines a privacy-preserving, footprint-minimal, offline swap-in mechanism to be used for BitsApp receiving.
Rationale
BDS-01 mandates BitsApp channels to operate one-way-only for the interactivity benefits. This means inbound payments are not allowed for TBD wallet channels. Sending on TBD Wallet is off-chain only, and receiving is on-chain-only. The only way to receive on-chain liquidity through lightning is submarine swaps. However, submarine swaps have many 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.
Receiver privacy
Offline receiving is not possible without compromising privacy.
Scalibility
Submarine swaps don't scale. Each swap consumes >182 vBytes per channel opening:
43 HTLC out + 40 HTLC outpoint + 56 HTLC redeem + 43 channel out
PTLCs doesn't help either, as it consumes still too much >142 vBytes;
43 PTLC out + 40 PTLC outpoint + 16 PTLC redeem + 43 channel out
Onboarding
| Type | HTLC output | HTLC outpoint | HTLC redeem | Channel output | Total |
|---|---|---|---|---|---|
| HTLC-based Submarine Swaps | 43 vBytes | 40 vBytes | 56 vBytes | 43 vBytes | 182 vBytes |
| PTLC-based Submarine Swaps | 43 vBytes | 40 vBytes | 16 vBytes | 43 vBytes | 142 vBytes |
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.