aljaz/specs
1
1
Fork 0
mirror of https://github.com/bits-wallet/specs.git synced 2025-12-17 05:34:21 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update 02.md

Browse Source
This commit is contained in:
brqgoo
2023-01-13 00:33:33 +03:00
committed by GitHub
parent 0fd84a0ee4
commit 5e43a8eaed
1 changed files with 9 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
02.md
View File

@@ -10,13 +10,16 @@ This BDS defines a non-interactive channel opening scheme.
## Rationale
Building a lightning client is challenging. What is more challenging is building a non-interactive lightning client. Due to the interactive nature of lightning, clients face two main challenges:
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:
### Uptime monitoring
Clients must remain online to monitor the network for channel breaches and act accordingly when needed. Running uptime software is unlikely for non-interactive clients such as mobile wallets and web clients.
### 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.
### Channel backups
Lightning clients must back up old channel states to be able to broadcast penalty transactions in case of a breach. Channel backup size grows in proportion to the number of payments. This is a huge drawback for web clients that have limited IndexedDB resources.
### 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
BDS-01 proposes to establish BitsApp a send-only lightning wallet and restrict the receiving part on-chain. A send-only lightning design makes payment channels operate one-way-only, making previous channel states in favor of the user at all times. This way, users don't need to back-up old channel states as they are all in their favor. The most favorable outcome for the channel partner (LSP) is to broadcast the latest-state-only. For the same reasons, users don't need to make periodic penalty checks with the bitcoin network and remain offline for a long period.
Expiring channel addresses make it possible to craft on-chain bitcoin addresses such that whenever funded by someone, it becomes a payment channel between the user and the channel partner (LSP), where the channel funds are initially kept on the user's side. 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.