Channel Addresses

Imagine you can create a bitcoin address, and give it to a third party such as a friend, a bitcoin exchange, or a payroll service where they make you an on-chain payment where the payment is a lightning channel in and of itself. Here’s where the channel addresses come in.

Channel addresses make it possible to craft a bech32m address such that whenever it’s funded by someone, it becomes a payment channel between you and your channel partner (LSP) where the channel funds are initially kept on your side. This makes the onboarding UX frictionless, significantly reduces on-chain footprint, and allows for batched transactions for opening channels. The Bitcoin network can theoretically open up to ~38 channels per second.

Channel addresses should not be confused with “Lightning Addresses,” which is an abstraction over sending lightning payments post-channel-formation. “Channel address” is a way to open lightning channels non-interactively.

Today two if not more approaches exist to potentially enabling non-interactive channels;
1. SIGHASH_NOINPUT can solely enable non-interactive channels by crafting a refund transaction in advance of a funding transaction that has unpredictable outpoints.
2. Jeremy Rubin has pointed out an approach to enabling non-interactive channels using OP_CTV.

However, both approaches require determinism in that refund closure must have outputs with pre-determined values, and so is the channel capacity. For example, a non-interactive channel with an expected total channel capacity of 1 BTC must be coordinated in advance to refund the user 1 BTC. This channel must be explicitly funded 1 BTC since the exceeding values are not bound to refund outputs and therefore might be burnt as transaction fees. The requirement for paying a bitcoin address an explicit amount cannot be safely fulfilled since BIP70-payment protocol URIs are not widely recognized and standardized by most wallets and exchanges. Accidentally reusing the same address twice might also result in a loss of funds in both approaches.

Enabling channel addresses requires three new additions to the Bitcoin scripting language under a new TapLeaf version. Namely; OP_TXHASH, OP_CHECKSIGFROMSTACK and OP_SUB64.

Logic flow for eltoo-compatible channel addresses

A channel address is a p2tr output with a single-leaf script path and a MuSig2 key path. The key path is a 2-of-2 common pubkey of user and LSP which is used for everything except a refund; channel updates, uniliteral settlements, and collaborative settlements. The script path initiates refund:trigger — a window period for the user to claim a refund. This is triggered if the channel partner (LSP) becomes unresponsive or non-collaborative once the channel is funded so that the user can exit from the channel without requiring a signature from the channel partner.

If the channel partner is responsive, and therefore exchanges signatures for eltoo:initiator > eltoo:trigger > Settle:0, the refund path must be revoked by the user as a next step. To revoke this, the user signs transaction IDs of ten different versions of refund:trigger, and gives those signatures to the channel partner as revocation signatures.

refund:trigger comes with one input and one output; spending F and funding R. Additional inputs such as fee supplier-inputs are not permitted in this transaction to make the transaction ID deterministic (preventing unknown outpoints from committing to txid). This is so that nValue gap between F and R must pay the transaction fees. Ten different versions of refund:trigger is required to create ten different variations on how much this nValue gap is. These ten fee tiers are subsequent powers of two of refund:trigger virtual size (189 vBytes).

All transaction fields within refund:trigger except nValues and the F outpoint are constrained to pre-determined values:

To calculate the nValue gap, F and R values must be introspected and subtracted from each other. Here’s how F value can be introspected:

And here’s how R value can be introspected:

Taking the above txhash flags into consideration, the script path that initiates the refund:trigger has this final construction:

If a revoked refund:trigger is initiated by the user, the channel partner can then take all the funds by triggering refund:breach immediately.

Since refund:breach is the child of refund:trigger, the message that commits to revocation signature is its outpoint, and it can be inspected as follows:

The script path that triggers refund:breach has the following script:

The script path that triggers refund:claim has the following script:

Reusing a channel address twice could have resulted in losing funds given Eltoo path. To prevent this, an extra step called eltoo:initiator to the beginning of Eltoo path is added. This initial step must always be signed with SIGHASH_ALL while subsequent parts are signed with SIGHASH_NONE.



Bitcoin hustler

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store