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:35:57 +03:00
committed by GitHub
parent 5e43a8eaed
commit aa3fe4d3e5
1 changed files with 2 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
02.md
View File

@@ -22,4 +22,5 @@ In comparison to batch openings, regular channel establishments are less privacy
Inconvenient for onboarding new users who have no UTXO possession in the beginning. Inconvenient for onboarding new users who have no UTXO possession in the beginning.
## Specification ## Specification
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. Channel addresses, as seen [here](https://burakkeceli.medium.com/channel-addresses-bd85e9ab8fe1) and [here](https://rubin.io/bitcoin/2021/12/11/advent-14/), 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. Both approaches require new additions to the bitcoin scripting system. However, we can build a primitive version of channel addresses called expiring channel addresses with what we have 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.