Meeting Notes
From March 4th, 2020
Interactive construction of lightning network funding transactions
- Problems to be solved:
- Duel-funded channels
- Batch closing of channels
- Splicing in/out funds to/from an existing channel
- During discussion a substitute version of BIP-69 has been proposed
- BIP-69 - standard way to order transactions - to prevent app fingerprinting
Hosted Channels
- Trying to solve a similar UX problem as “Turbo Channels” and fully custodial wallets: Newly installed lightning-enabled wallet app with no open channels takes time and knowledge to setup (minimum 2 hours)
- Goal is to allow newbies to install an app and within a minute be able to receive payments via lightning
- Turbo channels does this by opening a channel with 0 confirmations on the funding channel transaction with a remote balance that allows the user to receive payments
- Hosted channels does this by having a “hosted channel provider” instantly open a pseudo channel on behalf of the user without a funding channel transaction
- Features of hosted channels:
- Custodial, but verifiable/auditable by the user’s app
- User’s app still acts as a lightning node - creating its own preimages and encrypted onion blobs so that the hosted channel provider cannot track or analyze payments made by the user
- Fees paid by the user to the hosted channel provider are minimal (only routing fees) - turbo channels are likely going to be more expensive (see Phoenix implementation)
- Hosted channels are deterministically generated - so it is possible for the user’s wallet app to restore previous hosted channels from the user’s seed
- Both the wallet software of the user and the node software of the provider need to support the hosted channels protocol:
- Currently only BLW (Bitcoin Lightning Wallet) and a forked version of Eclair support hosted channels
- overview and comparisons with other solutions
- hosted-channel specification