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:40:12 +03:00
committed by GitHub
parent aa3fe4d3e5
commit 4c306654a4
1 changed files with 3 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
02.md
View File

@@ -22,5 +22,6 @@ In comparison to batch openings, regular channel establishments are less privacy
Inconvenient for onboarding new users who have no UTXO possession in the beginning.
## Specification
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.
`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. Channel address require new additions to the bitcoin scripting system, and therefore planned as a future extension under [BDS-19](https://github.com/bits-wallet/specs/blob/main/19.md).
`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.